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 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)," , 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)," , 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)," , Internet Engineering Task Force - Signalling Transport Working Group (December 27, 2001). Work In Progress. TUA. B. Bidulock, "SS7 TCAP-User Adaptation Layer (TUA)," , 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: bidulock@openss7.org 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