Network Working Group Brian Bidulock INTERNET-DRAFT OpenSS7 Corporation June 18, 2006 Expires in December 2006 Registration Extensions (REGEXT) for Signalling User Adaptation Layers Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire in December 2006. Copyright Copyright (C) The Internet Society (2006). Abstract This memo describes Registration Extensions (REGEXT) that provides the ability for an Application Server Process (ASP) to modify existing Routing (Link) Keys with a Signalling Gateway (SG). Current procedures in the SS7 Signalling User Adaptation Layers (UAs) [M2UA], [M3UA], [ISUA], [SUA], [TUA] do not provide for the modification of Routing (Link) Keys without deactivation of the B. Bidulock Version 0.3 Page 1 Internet Draft UA REGEXT June 18, 2006 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 Adaptation Layer [M2UA], modification of Circuit Identification Code (CIC) ranges for the SS7 MTP3-User Adaptation Layer [M3UA], modification of Circuit Identification Code (CIC) ranges for the SS7 ISUP-User Adaptation Layer [ISUA], 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]. Contents A complete table of contents, list of illustrations and tables, and a change history, are included at the end of this document. 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], [ISUA], [SUA], [TUA], for the purpose of supporting changed to Routing (Link) 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. Abbreviations AS --Application Server. ASP --Application Server Process. IANA --Internet Assigned Numbers Authority I-D --Internet-Draft IETF --Internet Engineering Task Force IP --Internet Protocol. IPSP --IP Signalling Point. SCCP --Signalling Connection Control Part. SCTP --Stream Control Transmission Protocol. SG --Signalling Gateway. SGP --Signalling Gateway Process. SIGTRAN --IETF Signalling Transport WG SPP --Signalling Peer Process. SS7 --Signalling System No. 7. SUA --SS7 SCCP-User Adpatation Layer. TCAP --Transaction Capabilities Application Part. TUA --SS7 TCAP-User Adaptation Layer. UA --User Adaptation Layer. B. Bidulock Version 0.3 Page 2 Internet Draft UA REGEXT June 18, 2006 WG --Working Group 1.3. Terminology REGEXT adds the following terms to the terminology presented in the UA documents: Registration Extension (REGEXT) - The parameters and procedures described by this memo. Signalling Peer Process (SPP) - refers to an ASP, SGP or IPSP. Signalling User Adaptation Layer (UA) - one or more of the Stream Control Transmission Protocol (SCTP) [RFC2960] SS7 Signalling User Adaptation Layers [M2UA], [M3UA], [ISUA], [SUA], [TUA] supporting Registration. 1.4. Overview Existing registration management procedures do not provide for the alteration of Routing (Link) 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.4.1. Limitations of Existing Registration Management Each of the SS7 UAs [M2UA], [M3UA], [ISUA], [SUA], [TUA] provides procedures for registration and deregistration of Routing (Link) Keys. None of these procedures currently provides for alteration of Routing (Link) Keys for a Application Server (AS) in the active state. 1.4.1.1. Limitations of Registration for M2UA 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 together into Application Servers (AS), nor does it provide a mechanism for altering the membership of signalling links associated with an Application Server. 1.4.1.2. Limitations of Registration for M3UA The SS7 MTP3-User Adaptation Layer [M3UA] registration of a Routing Key associates a range of traffic 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.<1> B. Bidulock Version 0.3 Page 3 Internet Draft UA REGEXT June 18, 2006 1.4.1.3. Limitations of Registration for ISUA The SS7 ISUP-User Adaptation Layer [ISUA] registration of a Routing Key associates a range of traffic 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 where normal circuit management expects to add and remove specific circuits or ranges of circuits (circuit groups) to and from Application Servers.<2> 1.4.1.4. Limitations of Registration for SUA 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 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 SUA is used in the connection-oriented environment and the ASP wishes to dynamically assign connections to Application Servers.<2> 1.4.1.5. Limitations of Registration for TUA The SS7 TCAP-User Adaptation 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 operation class 1, 2 and 3 (dialogues) and the ASP wishes to dynamically assign dialogues to Application Servers. 1.4.2. Registration Extension This memo provides extensions for the UA registration and deregistration procedures which addresses these limitations in the existing procedures. REGEXT provides support for altering an existing Routing (Link) Key for an active Application Server. 1.4.2.1. Registration Extensions for M2UA The purpose of REGEXT for M2UA [M2UA] is to support the Dynamic Allocation of Signalling Data Links and Signalling Terminals [Q.704], and, in particular, the ability to associate a new Signalling Link as specified by the combination of Signalling Data Link Identifier (SDLI) and Signalling Data Terminal Identifier (SDTI), with an existing Application Server. This permits MTP Level 3 to perform the Level 1 Connect and Level 1 Disconnect primitives, as well as associating a new Signalling Terminal with an existing Signalling Data Link for the Dynamic Allocation of Signalling Terminals. B. Bidulock Version 0.3 Page 4 Internet Draft UA REGEXT June 18, 2006 SG ASP _________________ ___________ | ______ | | _______ | SDL0 | | | | IID0 | | | | _______|_ _ _ __| SDT0 |_|________________|_| AS0 | | | ( / |______| | | |_______| | | / ______ | | _______ | SDL1 | / | | | IID1 | | | | _______|__/ | SDT1 | | _________|_| AS1 | | | |______| | / | |_______| | | ______ | / |___________| SDL2 | | | | / _______|________| SDT2 |_|___/ | |______| | | ______ | SDL3 | | | | _______| | SDT3 | | | |______| | |_________________| Figure A. Example (A) - M2UA Configuration For example, an ASP is ASP-ACTIVE for a given Application Server and signalling data link and terminal wishes to replace the Signalling Data Link associated with a Signalling Link (under MTP Level 3 [Q.704] control). The ASP wishes to replace the Signalling Data Link (SDL1) with the Signalling Data Link (SDL0) for the Signalling Link represented by AS0/IID0 as illustrated in Figure A. REGEXT permits the ASP to perform this switch using the REG REQ message with the Interface Identifier IID0 placed in the message along with the Link Key SDT0/SDL0. Examples are provided in Section 6. 1.4.2.2. Registration Extensions for M3UA The purpose of REGEXT for M3UA [M3UA] is to support the modification of traffic to and from an active Application Server for operations, maintenance, administration and provisioning. In particular this allows an MTP-User Part (SI value), Signalling Point Code or perhaps a Circuit Identification Code (CIC) range to be added or removed from an existing Routing Key associated with an active Application Server. B. Bidulock Version 0.3 Page 5 Internet Draft UA REGEXT June 18, 2006 STP MGC ___ ____ _____ / \ signalling | /| assoc. | | | SP1 |-------/-----/---/--| SG |---------| ASP | \___/\\ / / / |/___| |_____| ___ \\===/=====/===/=====================// / \_____/ / / circuits // | SP2 | / / // \___/\\ / / // ___ \\=====/===/=====================// / \_______/ / circuits // | SP3 | / // \___/\\ / // ___ \\=====/=====================// / \_______/ circuits // | SP4 | // \___/\\ // \\+++++++++++++++++++++++// circuits Figure B. Example (B) - M3UA Configuration For example, an ISUP Application Server wishes to add new trunk group(s) to a new Signalling Point Code (i.e. MGC). The AS is currently registered against a Routing Key which includes several remote point codes, but does not include the remote point code of the switch to which the trunk group(s) are to be added (as illustrated in Figure B). REGEXT permits the Application Server to provision the new trunk group(s) by adding the new remote point code to the Routing Key with the REG REQ message. 1.4.2.3. Registration Extensions for ISUA The purpose of REGEXT for ISUA [ISUA] is to support the modification of traffic to and from an active Application Server for operations, maintenance, administration and provisioning. In particular this allows perhaps a Circuit Identification Code (CIC) range to be added or removed from an existing Routing Key associated with an active Application Server. B. Bidulock Version 0.3 Page 6 Internet Draft UA REGEXT June 18, 2006 STP MGC ___ ____ _____ / \ signalling | /| assoc. | | | SP1 |-------/-----/---/--| SG |---------| ASP | \___/\\ / / / |/___| |_____| ___ \\===/=====/===/=====================// / \_____/ / / circuits // | SP2 | / / // \___/\\ / / // ___ \\=====/===/=====================// / \_______/ / circuits // | SP3 | / // \___/\\ / // ___ \\=====/=====================// / \_______/ circuits // | SP4 | // \___/\\ // \\+++++++++++++++++++++++// circuits Figure C. Example (C) - ISUA Configuration For example, an ISUP Application Server wishes to add new trunk group(s) to a new Signalling Point Code (i.e. MGC). The AS is currently registered against a Routing Key which includes several remote point codes, but does not include the remote point code of the switch to which the trunk group(s) are to be added (as illustrated in Figure C). REGEXT permits the Application Server to provision the new trunk group(s) by adding the new remote point code to the Routing Key with the REG REQ message. 1.4.2.4. Registration Extensions for SUA The purpose of REGEXT for SUA [SUA] is to associate a newly formed connection with an Application Server that is responsible for the connection. Almost all connection-oriented interface models (STREAMS, Sockets) rely on the concept of a listening stream or socket and an independent accepting stream or socket. REGEXT permits an accepted connection to be established on an Application Server which is independent from the Application Server upon which the connection request was received. B. Bidulock Version 0.3 Page 7 Internet Draft UA REGEXT June 18, 2006 SG ASP _________ _________ | | | | _________|___ | | _____ | _________|___| RK2 | RC2 | | | | _________|___|_____|_______|_| AS2 | | _________|___| | | | | | _________|___| | | |_____| | _________|___ | | _____ | _________|___| RK1 | RC1 | | | | _________|___|_____|_______|_| AS1 | | _________|___| | | | | | _________|___| | | |_____| | | | | _____ | connections RK0 | RC0 | | | | _________|_________|_______|_| AS0 | | | | | | | | | | | |_____| | | | | | |_________| |_________| Figure D. Example (D) - SUA Configuration For example, as illustrated in Figure D, one Application Server (AS0) is configured with a Routing Key which does not contain Destination Reference Number for SSN=5. Another Application Server (AS1) processes some connections for SSN=5 and AS2 processes other connections. When a CORE is received by AS0, and before sending a COAK, the ASP would like to assign the connection to one of AS1 or AS2 for further communication associated with the newly arrived connection. REGEXT permits AS0 to modify Routing Key RK1 by sending a REG REQ message that includes Routing Context RC1 and the additional Destination Reference Number that is assigned to the connection, permitting the SCCP implementation to follow the Network Provider Interface [NPI]. REGEXT also permits AS0 to modify the Routing Key on another Signalling Gateway with the complete fail-over support of the Application Server, avoiding many of the problems associated with DRN Label approach. 1.4.2.5. Registration Extensions for TUA The purpose of REGEXT for TUA [TUA] is to associate a newly formed dialogue or transaction with an Application Server that is responsible for the dialogue or transaction. Almost all connection-oriented interface models (STREAMS, Sockets) rely on the concept of a listening stream or socket and an independent accepting stream or socket. REGEXT permits an accepted dialogue or transaction to be established B. Bidulock Version 0.3 Page 8 Internet Draft UA REGEXT June 18, 2006 on an Application Server which is independent from the Application Server upon which the dialogue or transaction initiation was received. SG ASP _________ _________ | | | | _________|___ | | _____ | _________|___| RK2 | RC2 | | | | _________|___|_____|_______|_| AS2 | | _________|___| | | | | | _________|___| | | |_____| | _________|___ | | _____ | _________|___| RK1 | RC1 | | | | _________|___|_____|_______|_| AS1 | | _________|___| | | | | | _________|___| | | |_____| | | | | _____ | dialogues RK0 | RC0 | | | | _________|_________|_______|_| AS0 | | | | | | | | | | | |_____| | | | | | |_________| |_________| Figure E. Example (E) - TUA Configuration For example, as illustrated in Figure E, one Application Server (AS0) is configured with a Routing Key which does not contain Terminating Transaction Id for a given Application Context. Another Application Server (AS1) processes some dialogues and transactions for the Application Context, and AS2 processes other dialogues and transactions. When a TBEG is received by AS0, and before sending a TCON, the ASP would list to assign the transaction to one of AS1 or AS2 for further communication associated with the newly arrived transaction. REGEXT permits AS0 to modify the Routing Key RK1 by sending a REG REQ message that includes Routing Context RC1 and the additional Terminating Transaction Id that is assigned to the transaction, permitting the TCAP implementation to follow the Transport Provider Interface [TPI], [XNS]. REGEXT also permits AS0 to modify the Routing Key on another Signalling Gateway with the complete fail-over support of the Application Server, permitting SGs to be configured as STP pairs in the SS7 network. 1.5. Limitations Although the methods for dynamic modification of Routing Keys and Load Selections presented in this document is consistent with that B. Bidulock Version 0.3 Page 9 Internet Draft UA REGEXT June 18, 2006 previously discussed on the SIGTRAN WG, it has a number of limitations. To change a Routing Key or Load Selections requires that the entire new key or selection be included in the REG REQ message. This may be especially inconvenient if the resulting Routing Key or Load Selection contains thousands of elements (as it might for CIC Ranges on large MGC). A method more amenable to this situation would be to use the REG REQ message to "add" elements to the Routing Key or Load Selection and use the DEREG REQ to "delete" elements from the Routing Key or Load Selection. A third approach would be to define two new messages, such as: Registration Add (REG ADD) and Registration Delete (REG DEL), but share the REG RSP message. This last approach would probably be more convenient. The second approach is proposed by this memo. Notes for Section 1 <1> EDITOR'S NOTE:- Text was included in the M3UA specification [M3UA] to permit this operation, however, detailed procedures and the addition of the Routing Context parameter to the Routing Key, and addition of the corresponding error code was missed. <2> EDITOR'S NOTE:- Text was include in the SUA specification [SUA] to permit this operation, however, detailed procedures and the addition of the Routing Context parameter to the Routing Key was missed. In addition, this mechanism can provide superior support for multiple SGs acting as STPs, and can replace the DRN Label and associated mechanism. The TID Label and associated mechanism is inadequate and should be removed from the SUA specification [SUA]. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 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 This memo permits the use of the Routing Context (Interface Identifier) parameter within a Routing (Link) Key parameter. It also B. Bidulock Version 0.3 Page 10 Internet Draft UA REGEXT June 18, 2006 allows the use of the Routing (Link) Key parameter within a DEREG REQ message. This memo also defines a new Reference Number Range parameter for use in the SUA [SUA] Routing Key. In addition, this memo permits the use of the Source Reference Number, Destination Reference Number and Reference Number Range parameters in the SUA [SUA] Routing Key. 3.1.1. Routing Key Parameters 3.1.1.1. SUA Reference Number Range REGEXT defines a new SUA [SUA] Reference Number Range parameter for use in the Routing Key in the REG REQ message. This parameter is used to associate a range of source or destination reference numbers with an Application Server. The Reference Number Range parameter is formatted as follows: <1> 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 = 0x0119 | Length | +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+ \ \ / Reference Number Parameter(s) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Reference Number Range parameter can contain the following fields: Reference Number field: variable (TLV parameters) The Reference Number field can contain the following parameters: Parameters ------------------------------------------------ Source Reference Number Conditional *1 Destination Reference Number Conditional *1 Note 1: The Reference Number field must contain pairs of Source Reference Numbers or Destination Reference Numbers and MUST contain one and only one pair of addresses; but, MUST NOT mix Source Reference Numbers with Destination Reference Numbers in the same Reference Number field. B. Bidulock Version 0.3 Page 11 Internet Draft UA REGEXT June 18, 2006 3.1.2. Routing (Link) Key REGEXT extends the Link Key parameter of M2UA [M2UA] and the Routing Key parameters of M3UA, SUA, and TUA [M3UA], [ISUA], [SUA], [TUA]. 3.1.2.1. M2UA Link Key The M2UA [M2UA] Link Key parameter is formatted as follows: 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 = 0x0309 | Length | +-------------------------------+-------------------------------+ | Local-LK-Identifier | +---------------------------------------------------------------+ \ \ / Key parameter(s) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ REGEXT extends the M2UA Link Key parameter by adding the following parameters to the Link Key: Extension Sub-Parameters ------------------------------------------ Interface Identifier Optional *1 Note 1: The Interface Identifier parameter is optional in the Link Key. This parameter identifies an existing Application Server for which the Link Key is to be altered. The format of the Interface Identifier consists of a single integer Interface Identifier or a single text Interface Identifier. 3.1.2.2. M3UA Routing Key The M3UA [M3UA] Routing Key parameter is formatted as follows: B. Bidulock Version 0.3 Page 12 Internet Draft UA REGEXT June 18, 2006 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 | +---------------------------------------------------------------+ \ \ / Key parameter(s) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. REGEXT extends the M3UA [M3UA] Routing Key parameter by allowing the following parameters to be used as optional sub-parameters within the Routing Key: Extension Sub-Parameters ------------------------------------------ Routing Context Optional *1 Note 1: The Routing Context parameter is optional in the Routing Key. This parameter identifies an existing Application Server for which the Routing Key is to be altered. The format of the Routing Context consists of a single Routing Context value. 3.1.2.3. ISUA Routing Key The ISUA [ISUA] Routing Key parameter is formatted as follows: 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 = 0x0522 | Length | +-------------------------------+-------------------------------+ | Local Routing Key Identifier | +---------------------------------------------------------------+ \ \ / Key parameter(s) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ REGEXT extends the ISUA Routing Key [ISUA] by adding the following optional Key parameters to the Routing Key. B. Bidulock Version 0.3 Page 13 Internet Draft UA REGEXT June 18, 2006 Extension Sub-Parameters ------------------------------------------ Routing Context Optional *1 Note 1: The Routing Context parameter is included in the Routing Key when the ASP wishes to alter an existing Routing Key which corresponds to the indicated Routing Context. The Routing Context parameter MUST only occur once in the Key parameters. 3.1.2.4. SUA Routing Key The SUA [SUA] Routing Key parameter is formatted as follows: 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 = 0x010E | Length | +-------------------------------+-------------------------------+ | Local Routing Key Identifier | +---------------------------------------------------------------+ \ \ / Key parameter(s) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ REGEXT extends the SUA Routing Key [SUA] by adding the following optional Key parameters to the Routing Key. Extension Sub-Parameters ------------------------------------------ Routing Context Optional *1 Reference Number Range Optional *2 Note 1: The Routing Context parameter is included in the Routing Key when the ASP wishes to alter an existing Routing Key which corresponds to the indicated Routing Context. The Routing Context parameter MUST only occur once in the Key parameters. Note 2: The Reference Number Range parameter is included in the Routing Key when the ASP wishes to accept or restrict connection oriented traffic within a Destination Local Reference (DLR) range for the Application Server being registered. The Reference Number Range parameter SHOULD only occur once in the Key parameters. B. Bidulock Version 0.3 Page 14 Internet Draft UA REGEXT June 18, 2006 3.1.2.5. TUA Routing Key The TUA [TUA] Routing Key parameter is formatted as follows: 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 = 0x041E | Length | +-------------------------------+-------------------------------+ | Local Routing Key Identifier | +---------------------------------------------------------------+ \ \ / Key parameter(s) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ REGEXT extends the TUA Routing Key [TUA] by adding the following optional Key parameters to the Routing Key. Extension Sub-Parameters ------------------------------------------ Routing Context Optional *1 Note 1: The Routing Context parameter is included in the Routing Key when the ASP wishes to alter an existing Routing Key which corresponds to the indicated Routing Context. The Routing Context parameter MUST only occur once in the Key parameters. 3.1.3. Load Selection 3.1.3.1. M2UA Load Selection The M2UA [M2UA] Load Selection parameter [LOADSEL] is formatted as follows: 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 = 0x0019 | Length | +-------------------------------+-------------------------------+ \ \ / Load Key parameter(s) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ REGEXT extends the M2UA Load Selection [LOADSEL] parameter by adding the following optional Load Key parameters to the Load Selection. B. Bidulock Version 0.3 Page 15 Internet Draft UA REGEXT June 18, 2006 Extension Sub-Parameters ------------------------------------------ Load Selector Optional *1 Note 1: The Load Selector parameter is included in the Load Selection when the ASP wishes to alter an existing Load Selection which corresponds to the indicated Load Selector. The Load Selector parameter MUST only occur once in the Load Selection parameter. 3.1.3.2. M3UA Load Selection The M3UA [M3UA] Load Selection parameter [LOADSEL] is formatted as follows: 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 = 0x0019 | Length | +-------------------------------+-------------------------------+ \ \ / Load Key parameter(s) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ REGEXT extends the M3UA Load Selection [LOADSEL] parameter by adding the following optional Load Key parameters to the Load Selection. Extension Sub-Parameters ------------------------------------------ Load Selector Optional *1 Note 1: The Load Selector parameter is included in the Load Selection when the ASP wishes to alter an existing Load Selection which corresponds to the indicated Load Selector. The Load Selector parameter MUST only occur once in the Load Selection parameter. 3.1.3.3. ISUA Load Selection The ISUA [ISUA] Load Selection parameter [LOADSEL] is formatted as follows: B. Bidulock Version 0.3 Page 16 Internet Draft UA REGEXT June 18, 2006 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 = 0x0019 | Length | +-------------------------------+-------------------------------+ \ \ / Load Key parameter(s) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ REGEXT extends the ISUA Load Selection [LOADSEL] parameter by adding the following optional Load Key parameters to the Load Selection. Extension Sub-Parameters ------------------------------------------ Load Selector Optional *1 Note 1: The Load Selector parameter is included in the Load Selection when the ASP wishes to alter an existing Load Selection which corresponds to the indicated Load Selector. The Load Selector parameter MUST only occur once in the Load Selection parameter. 3.1.3.4. SUA Load Selection The SUA [SUA] Load Selection parameter [LOADSEL] is formatted as follows: 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 = 0x0019 | Length | +-------------------------------+-------------------------------+ \ \ / Load Key parameter(s) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ REGEXT extends the SUA Load Selection [LOADSEL] parameter by adding the following optional Load Key parameters to the Load Selection. B. Bidulock Version 0.3 Page 17 Internet Draft UA REGEXT June 18, 2006 Extension Sub-Parameters ------------------------------------------ Load Selector Optional *1 Note 1: The Load Selector parameter is included in the Load Selection when the ASP wishes to alter an existing Load Selection which corresponds to the indicated Load Selector. The Load Selector parameter MUST only occur once in the Load Selection parameter. 3.1.3.5. TUA Load Selection The TUA [TUA] Load Selection parameter [LOADSEL] is formatted as follows: 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 = 0x0019 | Length | +-------------------------------+-------------------------------+ \ \ / Load Key parameter(s) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ REGEXT extends the TUA Load Selection [LOADSEL] parameter by adding the following optional Load Key parameters to the Load Selection. Extension Sub-Parameters ------------------------------------------ Load Selector Optional *1 Note 1: The Load Selector parameter is included in the Load Selection when the ASP wishes to alter an existing Load Selection which corresponds to the indicated Load Selector. The Load Selector parameter MUST only occur once in the Load Selection parameter. 3.1.4. Error Codes 3.1.4.1. SUA Error Codes REGEXT extends the Common mandatory Error Code parameter by removing the following Error Code values: B. Bidulock Version 0.3 Page 18 Internet Draft UA REGEXT June 18, 2006 Value Description ----------------------------------- 0x17 Routing Key Change Refused In addition, REGEXT removes the following text associated with the "Routing Key Change Refused" error code: The "Routing Key Change Refused" error is sent when the SG refuses a change in the Routing Key parameters. [SUA] 3.1.5. Registration Status REGEXT extends the Registration Status parameter by adding the following values to the Common and UA-specific mandatory Registration Status parameter<2> in the REG RSP message: Value Description ---------------------------------------------- 11 Error - Routing Key Change Refused 17 Error - Load Selection Change Refused 3.1.5.1. Common Registration Status The Common [ISUA], [SUA], [TUA] Registration Status parameter is formatted as follows: 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 = 0x0016 | Length | + - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - + | Registration Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ REGEXT extends the Common Registration Status parameter for ISUA [ISUA], SUA [SUA] and TUA [TUA] by adding the following values to the status field: Value Description ---------------------------------------------- 11 Error - Routing Key Change Refused 17 Error - Load Selection Change Refused B. Bidulock Version 0.3 Page 19 Internet Draft UA REGEXT June 18, 2006 The "Error - Routing Key Change Refused" status is returned when the ASP has included an Routing Context in the Routing Key and the SGP is either unequipped to perform dynamic modification of the Routing Key, or dynamic modification of the Routing Key is not currently permitted. The "Error - Load Selection Change Refused" status is returned when the ASP has included a Load Selector in the Load Selection and the SGP is either unequipped to perform dynamic modification of the Load Selection, or dynamic modification of the Load Selection is not currently permitted. 3.1.5.2. M2UA Registration Status The M2UA [M2UA] Registration Status parameter is formatted as follows: <3> 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 = 0x030E | Length | + - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - + | Registration Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ REGEXT extends the M2UA [M2UA] Registration Status parameter by adding the following values to the status field: <4> Value Description ---------------------------------------------- 11 Error - Link Key Change Refused 17 Error - Load Selection Change Refused The "Error - Link Key Change Refused" status is returned by and SGP when the ASP has included an Interface Identifier in the Link Key and the SGP is either unequipped to perform dynamic modification of the Link Key, or dynamic modification of the Link Key is not currently permitted. The "Error - Load Selection Change Refused" status is returned when the ASP has included a Load Selector in the Load Selection and the SGP is either unequipped to perform dynamic modification of the Load Selection, or dynamic modification of the Load Selection is not currently permitted. 3.1.5.3. M3UA Registration Status The M3UA [M3UA] Registration Status parameter is formatted as follows: <5> B. Bidulock Version 0.3 Page 20 Internet Draft UA REGEXT June 18, 2006 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 = 0x0212 | Length | + - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - + | Registration Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ REGEXT extends the M3UA [M3UA] Registration Status parameter by adding the following values to the status field: Value Description ---------------------------------------------- 11 Error - Routing Key Change Refused 17 Error - Load Selection Change Refused The "Error - Routing Key Change Refused" status is returned when the ASP has included an Routing Context in the Routing Key and the SGP is either unequipped to perform dynamic modification of the Routing Key, or dynamic modification of the Routing Key is not currently permitted. The "Error - Load Selection Change Refused" status is returned when the ASP has included a Load Selector in the Load Selection and the SGP is either unequipped to perform dynamic modification of the Load Selection, or dynamic modification of the Load Selection is not currently permitted. 3.2. Messages REGEXT extends the REG REQ and REG RSP messages. 3.2.1. Registration Request (REG REQ) REGEXT extends the Registration Request (REG REQ) message by extending the Routing Key (Link Key) parameter and permitting the Routing Context (Interface Identifier) to be included in the REG REQ message. REGEXT also extends the REG REQ message by extending the Load Selection parameter [LOADSEL] and permitting the Load Selector to be included in the REG REQ message. 3.2.2. Registration Response (REG RSP) REGEXT extends the Registration Response (REG RSP) message by adding the following values to the mandatory Registration Status parameter in the mandatory Registration Result parameter in the REG RSP message: <6> B. Bidulock Version 0.3 Page 21 Internet Draft UA REGEXT June 18, 2006 Value Description -------------------------------------------------- 11 Error - Routing (Link) Key Change Refused 17 Error - Load Selection Change Refused The new Registration Status values are interpreted as follows: "Error - Routing (Link) Key Change Refused" This Registration Status is returned in a REG RSP message by the SGP when it is either unequipped to perform Routing (Link) Key modifications described in this memo, or is otherwise unable to modify the the Routing (Link) Key as requested by the ASP. "Error - Load Selection Change Refused" This Registration Status is returned in a REG RSP message by the SGP when it is either unequipped to perform Load Selection modifications described in this memo, or is otherwise unable to modify the the Load Selection as requested by the ASP. Notes for Section 3 <1> IANA NOTE:- The parameter tag values shown as 0x0119 will be assigned by IANA within the specific parameter range of SUA [SUA] and may change its value in further versions of this document. <2> IANA Note:- Note that the Registration Status parameter has tag value 0x030e for M2UA [M2UA], tag value 0x0212 for M3UA [M3UA] and (perhaps not surprisingly) tag value 0x0016 for ISUA [ISUA], SUA [SUA] and TUA [TUA]. <3> IANA NOTE:- The Registration Status value shown as 11 and 17 will be assigned by IANA as a value of the Common Registration Status parameter for the SIGTRAN UAs and may change its value in further versions of this document. <3> EDITOR'S NOTE:- The M2UA [M2UA] Registration Result, Registration Status, Deregistration Result and Deregistration Status parameter should be altered from the M2UA-specific tag values to the Common tag values to be consistent with the other UAs. <4> IANA NOTE:- The Registration Status value shown as 11 and 17 will be assigned by IANA as a value of the M2UA-specific Registration Status parameter for M2UA [M2UA] and may change its value in further versions of this document. <5> EDITOR'S NOTE:- The M3UA [M3UA] Registration Result, Registration Status, Deregistration Result and Deregistration Status parameter should be altered from the M3UA-specific tag B. Bidulock Version 0.3 Page 22 Internet Draft UA REGEXT June 18, 2006 values to the Common tag values to be consistent with the other UAs. <6> IANA NOTE:- The Registration Status value shown as 11 and 17 will be assigned by IANA as a value of the M3UA-specific Registration Status parameter for M3UA [M3UA] and may change its value in further versions of this document. <6> IANA NOTE:- The Registration Status values shown as 11 and 17 will be assigned by IANA as a value of the Common Registration Status parameter for SIGTRAN UAs and may change its value in further versions of this document. 4. Procedures 4.1. Registration In extension to the registration procedures of M2UA [M2UA], REGEXT provides the following registration procedures: 4.1.1. Common Registration Procedures In extension to the registration procedures of Common [M3UA], [ISUA], [SUA], [TUA], REGEXT provides the following registration procedures: An ASP MAY modify an existing Routing Key by including the Routing Context in the REG REQ. If the SGP determines that the Routing Context applies to an existing Routing Key, the SG MAY adjust the existing Routing Key to match the new information provided in the Routing Key parameter. A REG RSP with Registration Status "Error - Routing Key Change Refused" is returned if the SGP does not accept the modification of the Routing Key. <1> An ASP MAY modify an existing Load Selection by including the Load Selector in the REG REQ. If the SGP supports load selection extensions [LOADSEL] and determines that the Load Selector applies to an existing Load Selection, the SGP MAY adjust the existing Load Selection to match the new information provided in the Load Selection parameter. A REG RSP with Registration Status "Error - Load Selection Change Refused" is returned if the SGP does not accept the modification of the Load Selection. 4.1.2. M2UA Registration Procedures In extension to the registration procedures of M2UA [M2UA], REGEXT provides the following registration procedures: An ASP MAY modify an existing Link Key by including the Interface Identifier in the REG REQ. If the SGP determines that the Interface Identifier applies to an existing Link Key, the SG MAY adjust the existing Link Key to match the new information provided in the Link Key parameter. A REG RSP with Registration Status "Error - Link Key B. Bidulock Version 0.3 Page 23 Internet Draft UA REGEXT June 18, 2006 Change Refused" is returned if the SGP does not accept the modification of the Link Key. An ASP MAY modify an existing Load Selection by including the Load Selector in the REG REQ. If the SGP supports load selection extensions [LOADSEL] and determines that the Load Selector applies to an existing Load Selection, the SGP MAY adjust the existing Load Selection to match the new information provided in the Load Selection parameter. A REG RSP with Registration Status "Error - Load Selection Change Refused" is returned if the SGP does not accept the modification of the Load Selection. Notes for Section 4 <1> EDITOR'S NOTE:- ISUA [ISUA], SUA [SUA] and TUA [TUA] already contains the procedures described in this paragraph. The only difference provided by REGEXT is that the Registration Status "Error - Routing Key Change Refused" is actually defined. 5. Interworking REGEXT also provides procedures for an SGP or ASP not supporting REGEXT to interwork with an ASP or SGP supporting REGEXT. 5.1. Registration Interworking An ASP that determines than an SG is unequipped to perform REGEXT SHOULD NOT send any subsequent REG REQ messages containing a Routing Context (or Interface Identifier) to that SG. An SG or ASP supporting ASPEXT [ASPEXT] will identify its ability or inability to support REGEXT using the ASP Extensions procedure [ASPEXT]. If an SG does not support dynamic registration, it also does not support REGEXT. If an SG not supporting REGEXT receives a Routing Context (Interface Identifier) in the REG REQ message, it could respond with an existing non-zero Registration Status or an ERR message. If the ASP receives a REG RSP message containing a non-zero Registration Status, or receives an ERR message with an appropriate Error Code correlating to the REG REQ message and an indication that the Routing Context (Interface Identifier) parameter was considered invalid, from an SG not supporting ASP Extensions [ASPEXT], then the ASP SHOULD mark the SG as unequipped to perform REGEXT and not place any Routing Context (Interface Identifier) in any further messages to that SG, or attempt any of the extension procedures defined in this memo. 5.1.1. Registration Status REGEXT Unsupported Examples of possible Registration Status errors returned in a REG RSP message when the peer does not support REGEXT are as follows: B. Bidulock Version 0.3 Page 24 Internet Draft UA REGEXT June 18, 2006 Value Description ------------------------------------------------------ 4 Error - Invalid Routing Key ------------------------------------------------------ 6 Error - Cannot Support Unique Routing Error - Overlapping (Non-unique) Link Key ------------------------------------------------------ 7 Error - Routing Key not Currently Provisioned Error - Link Key not Provisioned ------------------------------------------------------ 9 Error - Unsupported RK parameter field ------------------------------------------------------ 11 Error - Routing Key Change Refused Error - Link Key Change Refused ------------------------------------------------------ 5.1.2. Error Codes REGEXT Unsupported Examples of possible Error Codes returned in a ERR message when the peer does not support REGEXT are as follows: Value Description ----------------------------------------------- 0x02 Invalid Interface Identifier 0x03 Unsupported Message Class 0x04 Unsupported Message Type 0x10 ASP Active for Interface Identifier(s) 0x11 Invalid Parameter Value 0x12 Parameter Field Error 0x13 Unexpected Parameter 0x19 Invalid Routing Context ----------------------------------------------- 6. Examples 7. Security REGEXT provides adds some security risks to M2UA [M2UA], M3UA [M3UA], ISUA [ISUA], SUA [SUA] and TUA [TUA]. If the Signalling Gateway (SG) does cannot properly authenticate the peer, the peer might gain privileges to alter a Routing (Link) Key to which the peer should not have permission, or alter a Load Selection to which the peer should not have permission. B. Bidulock Version 0.3 Page 25 Internet Draft UA REGEXT June 18, 2006 However, if the peer can imitate an ASP and gain access with the privileges of an ASP, use of the Routing Context (Interface Identifier) parameter in the ASPTM message can always be used to perform denial of service on traffic destined for legitimate Application Servers. As the REGEXT extensions require the use of the Routing Context (Interface Identifier) parameter in the REG REQ message, the same levels of protection afforded the Routing Context (Interface Identifier) parameter in the REG REQ message as is experienced in the ASPAC (ACK) message. 8. IANA Considerations REGEXT adds the following parameter tag value (described in Section 3) to the SUA-Specific Parameter numbering range for SUA [SUA]: Tag Value Parameter Name -------------------------------------- 0x0119 Reference Number Range<1> Notes for Section 8 <1> IANA NOTE:- The Reference Number Range tag values shown through this document as 0x0119 will be assigned by IANA within the SUA-specific parameter range of the SUA [SUA] and may change its value in further versions of this document. B. Bidulock Version 0.3 Page 26 Internet Draft UA REGEXT June 18, 2006 0. Revision History This section provides historical information on the changes made to this draft. This section will be removed from the document when the document is finalized. 0.3. Changes from Version 0.2 to Version 0.3 + updated references, version numbers and dates. 0.2. Changes from Version 0.1 to Version 0.2 + updated first and last page to IETF boilerplate. + added list of abbreviations. + moved change history here. + updated references. + split references. + updated version numbers and dates. + updated security section. + moved notes to end of document. + fixed spelling errors and typos. 0.1. Changes from Version 0.0 to Version 0.1 + added this history section, + updated references, + updated version numbers and dates, + updated author's address. + addition of Source Reference Number, Destination Reference Number and Reference Number Range to SUA [SUA14] Routing Key. 0.0.0. Change Log $Log: draft-bidulock-sigtran-regext-04.me,v $ Revision 0.9.2.3 2005/10/17 11:53:46 brian - updated drafts for republication Revision 0.9.2.2 2005/05/14 08:33:20 brian - copyright header correction Revision 0.9.2.1 2004/03/16 05:10:45 brian - Added drafts and figures. Revision 0.8.2.4 2003/08/01 12:23:16 brian Added abbreviations, updated format. Revision 0.8.2.3 2003/07/29 00:35:09 brian Finalizing latest round of drafts. Revision 0.8.2.2 2003/07/28 13:12:21 brian Reformatting. B. Bidulock Version 0.3 Page 27 Internet Draft UA REGEXT June 18, 2006 Revision 0.8.2.1 2003/07/27 08:15:30 brian Checking in changes. R. References R.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119 - BCP 14, The Internet Society (March 1997). [M2UA] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and Heitz, J., "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer," RFC 3331, Internet Engineering Task Force - Signalling Transport Working Group (September, 2002). [M3UA] Sidebottom, G., Morneault, K. and Pastor-Balbas, J., (eds), "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)," RFC 3332, Internet Engineering Task Force - Signalling Transport Working Group (September, 2002). [SUA] Loughney, J., Sidebottom, G., Coene, L., Verwimp, G., Keller, J. and Bidulock, B., "Signalling Connection Control Part User Adaptation Layer (SUA)," RFC 3868, Internet Engineering Task Force - Signalling Transport Working Group (October, 2004). [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, H., Zhang, L. and Paxson, V., "Stream Control Transmission Protocol (SCTP)," RFC 2960, The Internet Society (February 2000). [LOADSEL] Bidulock, B., "Load Selection Extension for Signalling User Adaptation Layers (LOADSEL)," , Internet Engineering Task Force - Signalling Transport Working Group (June 18, 2006). Work In Progress. R.2. Informative References [ISUA] Bidulock, B., "SS7 ISUP-User Adaptation Layer (ISUA)," , Internet Engineering Task Force - Signalling Transport Working Group (June 18, 2006). Work In Progress. [TUA] Bidulock, B., "SS7 TCAP-User Adaptation Layer (TUA)," , Internet Engineering Task Force - Signalling Transport Working Group (June 18, 2006). Work In Progress. [Q.704] ITU, "Message Transfer Part - Signalling Network Functions and Messages," ITU-T Recommendation Q.704, ITU-T B. Bidulock Version 0.3 Page 28 Internet Draft UA REGEXT June 18, 2006 Telecommunication Standardization Sector of ITU, Geneva (March 1993). (Previously "CCITT Recommendation") [NPI] International, UNIX., "Network Provider Interface Specification," NPI Revision 2.0.0, UNIX International Publication, Parsippany, New Jersey (August 17, 1992). http://www.openss7.org/doc/npi.pdf [TPI] Open Group, "Transport Provider Interface Specification," TPI Version 2, Draft 2, Open Group Publication (1999). http://www.opengroup.org/onlinepubs/ [XNS] Open Group, "Technical Standard: Network Services (XNS)," XNS Issue 5.2 Draft 2.0 [ISBN: 1-85912-241-8], Open Group Publication (1999). http://www.opengroup.org/onlinepubs/ [ASPEXT] Bidulock, B., "Application Server Process (ASP) Extension Framework," , Internet Engineering Task Force - Signalling Transport Working Group (June 18, 2006). Work In Progress. [SUA14] Loughney, J., Sidebottom, G., Coene, L., Verwimp, G., Keller, J. and Bidulock, B., "SS7 SCCP-User Adaptation Layer (SUA)," , Internet Engineering Task Force - Signalling Transport Working Group (June 30, 2002). Work In Progress. Author's Addresses Brian Bidulock OpenSS7 Corporation 1469 Jeffreys Crescent Edmonton, AB T6L 6T1 Canada Phone: +1-780-490-1141 Email: bidulock@openss7.org URL: http//www.openss7.org/ This draft expires December 2006. B. Bidulock Version 0.3 Page 29 Internet Draft UA REGEXT June 18, 2006 List of Illustrations Figure A. Example (A) - M2UA Configuration ...................... 5 Figure B. Example (B) - M3UA Configuration ...................... 6 Figure C. Example (C) - ISUA Configuration ...................... 7 Figure D. Example (D) - SUA Configuration ....................... 8 Figure E. Example (E) - TUA Configuration ....................... 9 Table of Contents Status of this Memo ............................................. 1 Copyright ....................................................... 1 Abstract ........................................................ 1 Contents ........................................................ 2 1 Introduction .................................................. 2 1.1 Scope ....................................................... 2 1.2 Abbreviations ............................................... 2 1.3 Terminology ................................................. 3 1.4 Overview .................................................... 3 1.4.1 Limitations of Existing Registration Management ........... 3 1.4.2 Registration Extension .................................... 4 1.5 Limitations ................................................. 9 Notes for Section 1 ............................................. 10 2 Conventions ................................................... 10 3 Protocol Elements ............................................. 10 3.1 Parameters .................................................. 10 3.1.1 Routing Key Parameters .................................... 11 3.1.2 Routing (Link) Key ........................................ 12 3.1.3 Load Selection ............................................ 15 3.1.4 Error Codes ............................................... 18 3.1.5 Registration Status ....................................... 19 3.2 Messages .................................................... 21 3.2.1 Registration Request (REG REQ) ............................ 21 3.2.2 Registration Response (REG RSP) ........................... 21 Notes for Section 3 ............................................. 22 4 Procedures .................................................... 23 4.1 Registration ................................................ 23 4.1.1 Common Registration Procedures ............................ 23 4.1.2 M2UA Registration Procedures .............................. 23 Notes for Section 4 ............................................. 24 5 Interworking .................................................. 24 5.1 Registration Interworking ................................... 24 5.1.1 Registration Status REGEXT Unsupported .................... 24 5.1.2 Error Codes REGEXT Unsupported ............................ 25 6 Examples ...................................................... 25 7 Security ...................................................... 25 8 IANA Considerations ........................................... 26 Notes for Section 8 ............................................. 26 0 Revision History .............................................. 27 0.3 Changes from Version 0.2 to Version 0.3 ..................... 27 0.2 Changes from Version 0.1 to Version 0.2 ..................... 27 0.1 Changes from Version 0.0 to Version 0.1 ..................... 27 B. Bidulock Version 0.3 Page 30 Internet Draft UA REGEXT June 18, 2006 0.0.0 Change Log ................................................ 27 R References .................................................... 28 R.1 Normative References ........................................ 28 R.2 Informative References ...................................... 28 Author's Addresses .............................................. 29 List of Illustrations ........................................... 30 Table of Contents ............................................... 30 B. Bidulock Version 0.3 Page 31 Internet Draft UA REGEXT June 18, 2006 Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. B. Bidulock Version 0.3 Page 32