| draft-bidulock-sigtran-regext-00Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-bidulock-sigtran-regext-00.txt.
Network Working Group Brian Bidulock
INTERNET-DRAFT OpenSS7 Corporation
Expires in six months January 7, 2003
Session Identification Registration (SESSID)
for
Signalling User Adaptation Layers
<draft-bidulock-sigtran-regext-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 or RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as 'work in progress'.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
To learn the current status of any Internet-Draft, please check
the Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This memo describes Registration Extensions that provides the
ability for an Application Server Process (ASP) to modify existing
Routing Keys (RKs) with a Signalling Gateway (SG).
Current procedures in the SS7 Signalling User Adaptation Layers
(UAs) do not provide for the modification of Routing Keys (RKs)
without deactivation of the Application Server (AS). This causes
problems in making changes to live systems.
The extensions described in this memo permit modification of
Signalling Link membership in Application Servers for SS7 MTP2-User
B. Bidulock Version 0.0 Page 1
Internet Draft SESSID January 7, 2003
Adaptation Layer [M2UA], modification of Circuit Identification Code
(CIC) ranges for the SS7 MTP3-User Adaptation Layer [M3UA],
modificiation of Destination Local Reference (DLR) ranges for SS7
SCCP-User Adaptation Layer [SUA], and modification of Transaction
Identifier (TID) ranges for SS7 TCAP-User Adaptation Layer [TUA].
1. Introduction
1.1. Scope
This Internet-Draft provides parameters and procedures in
extension to the parameters and procedures of the SS7 Signalling User
Adaptation Layers (UAs) [M2UA, M3UA, SUA, TUA], for the purpose of
supporting changed to Routing Keys to be made in live systems.
UA implementations with REGEXT are intended to be compatible with
UA implementations not supporting this extension.
1.2. Terminology
REGEXT adds the following terms to the terminology presented in
the UA documents:
Registration Extension - The parameters and procedures described by
this memo.
Signalling Peer Process - refers to an ASP, SGP or IPSP.
Signalling User Adaptation Layer (UA) - one or more of the Stream
Control Transmission Protocol (SCTP) [RFC 2960] SS7 Signalling
User Adaptation Layers [M2UA, M3UA, SUA, TUA] supporting
Registration.
1.3. Overview
Existing registration mangement procedures do not provide for the
alteration of Routing Keys on live systems. This can lead to
significant operational difficulties in large scale deployments.
This memo provides extension procedures that permit this
modification.
1.3.1. Limitations of Existing Registration Management
Each of the UAs [M2UA, M3UA, SUA, TUA] provides procedures for
registration and deregistration of Routing (Link) Keys. None of
these procedures currently provides for alteration of Routing Keys
for a Application Server (AS) in the active state.
In SS7 MTP2-User Adaptation Layer [M2UA] registration of a Link
Key associates a signalling link with an Interface Identifier (IID).
However, registration does not provide a mechanism for associating
groups of Interface Identifiers (IID) together into Application
Servers (AS), nor does it provide a mechanism for altering the
membership of signalling links associated with an Application Server.
B. Bidulock Version 0.0 Page 2
Internet Draft SESSID January 7, 2003
The SS7 MTP3-User Adaptation Layer [M3UA] registration of a
Routing Key associates a range of tranffic with an Application Server
through a Routing Context. However, it does not provide procedures
for changing the range of traffic associated with an Application
Server and Routing Context without deactivating the Application
Server and deregistering the Routing Key. This can cause
difficulties when M3UA is used in support of ISUP MTP3-Users where
normal circuit management expects to add and remove specific circuits
or ranges of circuits (circuit groups) to and from Application
Servers.
The SS7 SCCP-User Adaptation Layer [SUA] registration of a Routing
Key associates a range of traffic with an Application Server through
a Routing Context and the Address Mapping Fucntion. However, it does
not provide procedures for changing the range of traffic associated
with an Application Server and Routing Context without deactivating
the Application Server and deregistering the Routing Key. This can
cause difficulties when SUA is used in the connection-oriented
environment and the ASP wishes to dynamically assign connections to
Application Servers.
The SS7 TCAP-User Adapatation Layer [TUA] registration of a
Routing Key associates a range of traffic wtih an Application Server
through a Routing Context and the Transaction Mapping Function.
However, it does not provide procedures for changing the range of
traffic associated with an Application Server and Routing Context
without deactivating the Application Server and deregistering the
Routing Key. This can cause difficulties when TUA is used in
operations class 1, 2 and 3 (dialogues) and the ASP wishes to
dynamically assign dialogues to Application Servers.
1.3.2. Registration Extension
This memo provides extensions for the UA registration and
dregistration procedures which addresses these limitations in the
existing prcoedures. REGEXT provide the following
1.3.2.1. M2UA
1.3.2.2. M3UA
1.3.2.3. SUA
1.3.2.4. TUA
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
[RFC 2119].
B. Bidulock Version 0.0 Page 3
Internet Draft SESSID January 7, 2003
3. Protocol Elements
The following subsections describe the parameters which are added
or whose use is modified by this extension, their format and the
messages in which they are used.
3.1. Parameters
Registration Extensions does not add any new parameters, but
permits the use of the Routing Context parameter within a Routing Key
parameter. It also allows the use of the Routing Key parameter
within a DEREG REQ message.
3.1.1. Routing Key
REGEXT augments the Link Key parameter of M2UA [M2UA] and the
Routing Key parameters of M3UA, SUA, and TUA [M3UA, SUA, TUA].
3.1.1.1. M2UA Link Key
3.1.1.2. M3UA Routing Key
The Routing Key parameter is used in the REG REQ and DEREG REQ
messages. It is used to identify the portion of traffic for which an
ASP is registering or deregistering.
The Routing Key parameter is formatted as follows:
B. Bidulock Version 0.0 Page 4
Internet Draft SESSID January 7, 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0207 | Length |
+-------------------------------+-------------------------------+
| Local-RK-Identifier |
+---------------------------------------------------------------+
| Traffic Mode Type (optional) |
+---------------------------------------------------------------+
| Routing Context (optional) |
+---------------------------------------------------------------+
| Network Appearance (optional) |
+---------------------------------------------------------------+
| Destination Point Code |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Service Indicators (optional) |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Originating Point Code (optional) |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Circuit Range List (optional) |
+---------------------------------------------------------------+
\ \
/ ... /
\ \
+---------------------------------------------------------------+
| Destination Point Code |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Service Indicators (optional) |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Originating Point Code (optional) |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Circuit Range List (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Routing Key parameter contains the following sub-parameters:
Local-RK-Identifier parameter: TLV
The mandatory Locak-RK-Identifier parameter is used to uniquely
identify the registration request. The Local-RK-Identifier value
is assigned by the ASP, and is used to correlate the response in an
REG RSP message with the original registration request. THe Locak-
RK-Identifier value must remain unique until the REG RSP message is
received.
The format of the Local-RK-Identifier is as follows:
B. Bidulock Version 0.0 Page 5
Internet Draft SESSID January 7, 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020a | Length = 8 |
+-------------------------------+-------------------------------+
| Local-RK-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1.3. SUA Routing Key
3.1.1.4. TUA Routing Key
Routing Key
3.2. Messages
4. Procedures
4.1. Regsitration
4.1.1. Registration Procedures
4.1.2. Deregistration Procedures
4.2. AS and ASP State Maintenance
4.2.1. ASP State
4.2.2. AS State
4.2.3. ASP Up Procedures
4.2.4. ASP Down Procedures
4.2.5. ASP Active Procedures
4.2.6. ASP Inactive Procedures
4.2.7. Notify Procedures
5. Examples
6. Security
7. IANA Considerations
Acknowledgments
The authors would like to thank for their valuable comments and
suggestions.
B. Bidulock Version 0.0 Page 6
Internet Draft SESSID January 7, 2003
Notes
References
M2UA.
K. Morneault, R. Dantu, G. Sidebottom, T. George, B. Bidulock
and J. Heitz, "SS7 MTP2-User Adaptation Layer (M2UA)," <draft-
ietf-sigtran-m2ua-12.txt>, Internet Engineering Task Force -
Signalling Transport Working Group (December, 2001). Work In
Progress.
M3UA.
G. Sidebottom, J. Pastor-Balbas, I. Rytina, G. Mousseau, L. Ong,
H. J. Schwarzbauer, K. Gradischnig, K. Morneault, M. Kalla, N.
Glaude, B. Bidulock and J. Loughney, "SS7 MTP3-User Adaptation
Layer (M3UA)," <draft-ietf-sigtran-m3ua-11.txt>, Internet
Engineering Task Force - Signalling Transport Working Group
(January, 2002). Work In Progress.
SUA.
J. Loughney, G. Sidebottom, G. Mousseau, S. Lorusso, L. Coene,
G. Verwimp, J. Keller, F. E. Gonzalez, W. Sully, S. Furniss and
B. Bidulock, "SS7 SCCP-User Adaptation Layer (SUA)," <draft-
ietf-sigtran-sua-10.txt>, Internet Engineering Task Force -
Signalling Transport Working Group (December 27, 2001). Work In
Progress.
TUA.
B. Bidulock, "SS7 TCAP-User Adaptation Layer (TUA)," <draft-
bidulock-sigtran-tua-01.txt>, Internet Engineering Task Force -
Signalling Transport Working Group (January 2, 2003). Work In
Progress.
RFC 2960.
R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer,
T. Taylor, I. Rytina, H. Kalla, L. Zhang and V. Paxson, "Stream
Control Transmission Protocol (SCTP)," RFC 2960, The Internet
Society (February 2000).
RFC 2119.
S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels," RFC 2119 - BCP 14, Internet Engineering Task Force
(March 1997).
B. Bidulock Version 0.0 Page 7
Internet Draft SESSID January 7, 2003
Author's Addresses
Brian Bidulock Phone: +1-972-839-4489
OpenSS7 Corporation Email: [email protected]
4701 Preston Park Boulevard URL: http//www.openss7.org/
Suite 424
Plano, TX 75093
USA
This Internet draft expires July, 2002.
B. Bidulock Version 0.0 Page 8
Internet Draft SESSID January 7, 2003
List of Illustrations
Table of Contents
1 Introduction ................................................ 2
1.1 Scope ..................................................... 2
1.2 Terminology ............................................... 2
1.3 Overview .................................................. 2
1.3.1 Limitations of Existing Registration Management ......... 2
1.3.2 Registration Extension .................................. 3
2 Conventions ................................................. 3
3 Protocol Elements ........................................... 4
3.1 Parameters ................................................ 4
3.1.1 Routing Key ............................................. 4
3.2 Messages .................................................. 6
4 Procedures .................................................. 6
4.1 Regsitration .............................................. 6
4.1.1 Registration Procedures ................................. 6
4.1.2 Deregistration Procedures ............................... 6
4.2 AS and ASP State Maintenance .............................. 6
4.2.1 ASP State ............................................... 6
4.2.2 AS State ................................................ 6
4.2.3 ASP Up Procedures ....................................... 6
4.2.4 ASP Down Procedures ..................................... 6
4.2.5 ASP Active Procedures ................................... 6
4.2.6 ASP Inactive Procedures ................................. 6
4.2.7 Notify Procedures ....................................... 6
5 Examples .................................................... 6
6 Security .................................................... 6
7 IANA Considerations ......................................... 6
B. Bidulock Version 0.0 Page 9
Internet Draft SESSID January 7, 2003
Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedure for
copyrights defined in the Internet Standards process must be
followed, or as required to translate into languages other than
English.
The limited permission granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MECHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
B. Bidulock Version 0.0 Page 10
| ||||||||||||||||||
| Last modified: Wed, 27 Nov 2024 11:03:18 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||||