Network Working Group Brian Bidulock INTERNET-DRAFT OpenSS7 Corporation February 21, 2004 Expires in August 2004 Multiple Signalling Gateway Support 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). Copyright Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This Internet-Draft describes Load Selection for Signalling User Adaptation Protocols [M3UA, SUA..TUA], which permits an Application Server Processes (ASP) to indicate its placement within an Application Server and permits an Signalling Gateway (SG) to distribute traffic over ASPs in Application Servers under Application Server Process (ASP) control. B. Bidulock Version 0.3 Page 1 Internet Draft UA MULTI-SG February 21, 2004 Contents A complete table of contents, list of tables and illustrations, and change history appears 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 Signalling User Adaptation Layers (UAs) [M3UA, SUA..TUA], for the purpose of supporting Application Servers interworking with multiple Signalling Gateways to the SS7 Network. UA implementations with Multiple SG Support are intended to be compatible with UA implementations not supporting this configuration. MULTI-SG is only applicable to Signalling Gateway (SG)-Application Server Process (ASP) configurations in which ASP are supporting Application Server (AS) connectivity to an SS7 network via multiple SGs.[1] MULTI-SG is not applicable to configurations of IPSPs working in a point-to-point network without relay points.[2] 1.2. Terminology Multiple SG Support (MULTI-SG) supplements the terminology used in the UA documents [M3UA, SUA..TUA] by adding the following terms: Multiple SG Support (MULTI-SG) - the parameters and procedures provided in this document. Signalling User Adaptation Layer (UA) - one or more of the Stream Control Transmission Protocol (SCTP) [RFC 2960] SS7 Signalling User Adaptation Layers [M3UA, SUA..TUA] supporting the concept of a Routing Context. 1.3. Overview MULTI-SG provides procedures in addition to the UA procedures[3] that provides for seamless interworking of SS7 Network Management with Application Server Processes (ASPs) supporting Application Servers (AS) to multiple Signalling Gateways (SGs). MULTI-SG procedures provide support for the following functions not provided for in the existing UA documents: + Support for fail-over of SCTP associations between Signalling Gateways (SGs). + Support for rerouting of traffic destined to Signalling Endpoints (SEP) in SS7 Network between Signalling Gateways (SGs). + Support for seamless interworking with SS7 Changeback [Q.704] procedures towards the SS7 Network for rerouting of traffic between SGs for elminating message mis-sequencing across the interworking point between the SS7 and IP networks. B. Bidulock Version 0.3 Page 2 Internet Draft UA MULTI-SG February 21, 2004 MUTLI-SG supplements the procedures for the diversion of traffic during fail-over or restoration of ASPs, SGPs and IPSPs already provided for in "Correlation Id and Heartbeat Procedures (CORID) Supporting Lossless Fail-Over between SCTP Associations" [CORID]. The benefits of MULTI-SG can, nevertheless, be supported indepedent from CORID [CORID] 1.3.1. Multiple SGs No procedures are described which provide for reduction of message loss, duplication or mis-sequencing in multiple SG configurations in the existing UA procedures. 1.3.1.1. Fail-over of routesets between SGs 1.3.1.2. Redirection of routesets between SGs 1.4. Sample Configurations | SS7 IP Network | Network _______________ _______ ____ | | _______| ______| | / \ | | |_______| ____| ASP | | | B/D-Links | | | SGP |________ | |_______| | | ___________| STP SG|_______| | | _______ | | /| | | |__ + | | __| | | AS | / | | SGP |__ + | | __| ASP | | | \ / | | |_______| + | | |_______| | | \ / |_______________| | | _______ | | \ / C- | + | | __| | \____/ X Links| | + | | __| ASP | ____ / \ _|_____________ + | | |_______| / \ / \ | | _______| | | _______ | | / \ | | |__ + | | __| | | | \ | | | SGP |__ + | | __| ASP | | | __________\| STP SG|_______| + | | |_______| | AS | | | | |________|_| _______ | | | | SGP |_______ |_____| | | | | | |_______| |______| ASP | | | |_______________| SCTP |_______| \___ / | Associations | Figure 1. Example (A) Sample Multiple-SG Configuration A typical Example (A) configuration multiple Signalling Gateways is illustrated in Figure 1. In this configuration a number of Application Server Processes (ASPs) serving a number of Application Servers (ASs) are connected to two Signalling Gateways (SGs). The SGs appear as mated SS7 Signalling Transfer Points (STPs) [Q.705] to the B. Bidulock Version 0.3 Page 3 Internet Draft UA MULTI-SG February 21, 2004 SS7 Network. Traffic originating at Signalling Endpoints (SEP) in the SS7 network and directed toward SEP in the IP network (i.e., Application Servers) is loadshared over the STPs by the Signalling Link Selection (SLS) [Q.704] value associated with each message. Traffic originating at the SEP in the IP network (i.e, AS) is loadshared over the SGs in the same fashion. Notes for Section 1 [1] This is commonly referred to within the SIGTRAN WG as the "backhaul" case. [2] This is commonly referred to within the SIGTRAN WG as the "peer-to-peer" case. [3] See Section 4 of M3UA, SUA and TUA [M3UA, SUA..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]. 3. Protocol Elements 3.1. Parameters 3.2. Messages 4. Procedures 4.1. AS and ASP State Maintenance 4.1.1. ASP State 4.1.2. AS State 4.1.3. ASP Up Procedures 4.1.4. ASP Down Procedures 4.1.5. ASP Active Procedures 4.1.6. ASP Inactive Procedures 4.1.7. Notify Procedures 5. Examples 6. Security Load Selection does not introduce any new security risks or considerations that are not already inherent in the UA [M3UA, B. Bidulock Version 0.3 Page 4 Internet Draft UA MULTI-SG February 21, 2004 SUA..TUA] Please see the SIGTRAN Security document [SIGSEC] for security considerations and recommendations that are applicable to each of these UAs. 7. IANA Considerations 0. Change History This section will be deleted once this memo is finalized. 0.3. Changes from Version 0.2 to Version 0.3 0.2. Changes from Version 0.1 to Version 0.2 0.1. Changes from Version 0.0 to Version 0.1 R. References R.1. Normative References [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). [RFC 2960] 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). [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119 - BCP 14, The Internet Society (March 1997). [SIGSEC] Loughney, J., Tuexen, M. and Pastor-Balbas, J., "Security Considerations for SIGTRAN Protocols," , Internet Engineering Task Force - Signalling Transport Working Group (June 29, 2003). Work In Progress. R.2. Informative References [SUA] Loughney, J., Sidebottom, G., Coene, L., Verwimp, G., Keller, J. and Bidulock, B., "SS7 SCCP-User Adaptation Layer (SUA)," draft-ietf-sigtran-sua-16.txt, Internet Engineering Task Force - Signalling Transport Working Group (December 11, 2003). Work In Progress. [ISUA] Bidulock, B., "SS7 ISUP-User Adaptation Layer (ISUA)," , Internet Engineering Task Force - Signalling Transport Working Group (February 21, 2004). Work In Progress. B. Bidulock Version 0.3 Page 5 Internet Draft UA MULTI-SG February 21, 2004 [TUA] Bidulock, B., "SS7 TCAP-User Adaptation Layer (TUA)," , Internet Engineering Task Force - Signalling Transport Working Group (February 21, 2004). Work In Progress. [Q.704] ITU, "Message Transfer Part - Signalling Network Functions and Messages," ITU-T Recommendation Q.704, ITU-T Telecommunication Standardization Sector of ITU, Geneva (March 1993). (Previously "CCITT Recommendation") [CORID] Bidulock, B., "Correlation Id and Heartbeat Procedures Supporting Lossless Fail-Over," , Internet Engineering Task Force - Signalling Transport Working Group (February 21, 2004). Work In Progress. [Q.705] ITU, "Signalling System No. 7 - Signalling Network Structure," ITU-T Recommendation Q.705, ITU-T Telecommunication Standardization Sector of ITU, Geneva (March 1993). (Previously "CCITT Recommendation") Author's Addresses Brian Bidulock Phone: +1-780-490-1141 OpenSS7 Corporation Email: bidulock@openss7.org 1469 Jeffreys Crescent URL: http//www.openss7.org/ Edmonton, AB T6L 6T1 Canada This draft expires August 2004. B. Bidulock Version 0.3 Page 6 Internet Draft UA MULTI-SG February 21, 2004 List of Illustrations Figure 1. Example (A) Sample Multiple-SG Configuration .......... 3 Table of Contents Status of this Memo ............................................. 1 Copyright ....................................................... 1 Abstract ........................................................ 1 Contents ........................................................ 2 1 Introduction .................................................. 2 1.1 Scope ....................................................... 2 1.2 Terminology ................................................. 2 1.3 Overview .................................................... 2 1.3.1 Multiple SGs .............................................. 3 1.4 Sample Configurations ....................................... 3 Notes for Section 1 ............................................. 4 2 Conventions ................................................... 4 3 Protocol Elements ............................................. 4 3.1 Parameters .................................................. 4 3.2 Messages .................................................... 4 4 Procedures .................................................... 4 4.1 AS and ASP State Maintenance ................................ 4 4.1.1 ASP State ................................................. 4 4.1.2 AS State .................................................. 4 4.1.3 ASP Up Procedures ......................................... 4 4.1.4 ASP Down Procedures ....................................... 4 4.1.5 ASP Active Procedures ..................................... 4 4.1.6 ASP Inactive Procedures ................................... 4 4.1.7 Notify Procedures ......................................... 4 5 Examples ...................................................... 4 6 Security ...................................................... 4 7 IANA Considerations ........................................... 5 0 Change History ................................................ 5 0.3 Changes from Version 0.2 to Version 0.3 ..................... 5 0.2 Changes from Version 0.1 to Version 0.2 ..................... 5 0.1 Changes from Version 0.0 to Version 0.1 ..................... 5 R References .................................................... 5 R.1 Normative References ........................................ 5 R.2 Informative References ...................................... 5 Author's Addresses .............................................. 6 List of Illustrations ........................................... 7 Table of Contents ............................................... 7 B. Bidulock Version 0.3 Page 7 Internet Draft UA MULTI-SG February 21, 2004 Full Copyright Statement Copyright (C) The Internet Society (2003). 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. B. Bidulock Version 0.3 Page 8