Network Working Group Brian Bidulock INTERNET DRAFT OpenSS7 Corporation Tolga Asveren SS8 Networks Inc. Expires in six months May 02, 2002 M3UA SG-SG communication Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accesse at http://www.ietf.org/shadow.html To learn the current status of any Internet-Draft, please check the '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 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 Bidulock/Asveren 1 Bidulock/Asveren Internet Draft M3UA SG-SG Communication May, 2002 This Internet-Draft describes a protocol to support communication of M3UA[2] based SGs over IP. The additional functionality needed by SGs to act as relay points between SS7 nodes is also addressed. TABLE OF CONTENTS 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Scope. . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Terminology. . . . . . . . . . . . . . . . . . . . . 2 1.3 Conventions. . . . . . . . . . . . . . . . . . . . . 3 1.4 Overview . . . . . . . . . . . . . . . . . . . . . . 3 2. Functional Areas. . . . . . . . . . . . . . . . . . . . . 4 2.1 Signalling Point Code Representation . . . . . . . . 4 2.2 Routing Context and Routing Keys . . . . . . . . . . 4 2.3 Network Appearance . . . . . . . . . . . . . . . . . 4 2.4 SCTP Association Establishment . . . . . . . . . . . 4 2.5 Congestion Handling. . . . . . . . . . . . . . . . . 5 3. Message Types and Parameters. . . . . . . . . . . . . . . 5 4. Protocol Messages . . . . . . . . . . . . . . . . . . . . 5 4.1 Destination User Part Unavailable Message. . . . . . 5 4.2 Congestion Test Message. . . . . . . . . . . . . . . 6 4.3 Traffic Allowed Message. . . . . . . . . . . . . . . 7 4.4 Changeover Mechanism Related Messages. . . . . . . . 8 4.4.1 Changeover Request Message. . . . . . . . . . 8 4.4.2 changeover Request Acknowledgement Message. . 9 5. Security. . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . 10 7. References. . . . . . . . . . . . . . . . . . . . . . . . 10 7.1 Normative References . . . . . . . . . . . . . . . . 10 7.2 Informative References . . . . . . . . . . . . . . . 10 8. Author's Addresses. . . . . . . . . . . . . . . . . . . . 10 1. Introduction 1.1. Scope This Internet-Draft describes a protocol to support communication of M3UA SGs over IP. The additional functionality, which is necessary for such nodes to act as relay nodes between SS7 entities is also addressed. 1.2. Terminology SG-SG communication draft uses the terminology used in the M3UA RFC[..] with the following additions: COA Changeover Acknowledgement MTP3 message COO Changeover Order MTP3 message 2 Bidulock/Asveren Internet Draft M3UA SG-SG Communication May, 2002 1.3. 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 [3]. 1.4. Overview The purpose of SG-SG protocol is to increase inter-IP communication capabilities of M3UA peers and to allow SS7 signalling backhauling between SS7 nodes over IP. ----- ----- // \\ // \\ | ASP | | ASP | | Cloud 1| | Cloud 2| \\ // \\ // --+-- --+-- | | | | +--+--+ +--+--+ | SG1 +------------+ SG2 | +--+--+ +--+--+ | | | | | | | +-----+ | +-----+ SG3 +------+ +--+--+ | | --+-- // \\ | ASP | | Cloud 2| \\ // ----- Figure 1. Inter-IP communication using SG-SG communication In the configuration in Figure 1 SGs act as transfer points between ASP clouds. Their functionality is similar to the STP functionality in SS7 network. The communication between ASPs and SGs is as defined in M3UA protocol. +---------+ +---------+ | SG1 +--------------+ SG2 | +----+----+ +----+----+ 3 Bidulock/Asveren Internet Draft M3UA SG-SG Communication May, 2002 | | | | +----+----+ +----+----+ |SS7 node1| |SS7 node2| +---------+ +---------+ Figure 2. SS7 signalling backhauling using SG-SG communication In the configuration in Figure 2 SGs act as relay points for SS7 nodes. SG-SG communiation management is based mainly on SSNM as defined in M3UA protocol, with some additional messages to handle startup of associations, and changeover/congestion as defined in MTP3. Communication of peers is on PC granularity. 2. Functional Areas 2.1 Signalling Point Code Representation SGs should control SPMCs as a whole. When a SPMC becomes unavailable, SG will broadcast DUNA to all SGs, it has an association with. Similarly when a SPMC becomes available DAVA and when a SPMC becomes restricted DRST will be sent. 2.2 Routing Context and Routing Keys Unlike M3UA, there is no Routing Context/Routing Key concept present in SG-SG communication. 2.3 Network Appearance NA is used in the messages as described in M3UA RFC. 2.4 SCTP Association Establishment There is no client/server relationship between SGs. SCTP associations might be initiated from any side. After a SCTP association is established, SGs will exchange SSNM to update the remote peer about the status of the PCs, which are by configuration declared as reachable via them. Unless a corresponding message is received, all PCs are assumed as accessible via the remote peer. Each SG will send DUNA for unavailable PCs and DRST for restricted PCs after the establishment of the association. The end of this unavailable/restricted PC announcement procedure is marked with a TAL(Traffic Allowed) message. A SG SHOULD not start sending DATA to a peer, unless TAL is received. 4 Bidulock/Asveren Internet Draft M3UA SG-SG Communication May, 2002 2.5 Congestion Handling Congestion handling procedures as defined in MTP3 for signaling points should be followed between SGs. It is responsibility of a SG, to follow those procedures, on behalf of the SPMCs, that it directly controls. 3. Message Types and Parameters The following new message types are added to SSNM in addition to the ones defined in M3UA. 128 Traffic Allowed (TAL) 129 Changeover Request (COR) 130 Changeover Request Acknowledgement (CORA) The following parameters are added in addition to the ones defined in M3UA. Forward Sequence Number 0x0214 Signalling Link Code 0x0215 4. Protocol Messages Between SGs DATA and SSNM messages as defined in M3UA protocol are used. RC field in messages is not used,i.e. it MUST not be filled. 4.1 Destination User Part Unavailable (DUPU) A new field is introduced to DUPU. Concerned PC: Destination PC, which has caused DUPU to be generated. This parameter is mandatory. The format for DUPU message parameters is 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 = 0x0200 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0012 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask = 0 | Affected PC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0206 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Concerned DPC | 5 Bidulock/Asveren Internet Draft M3UA SG-SG Communication May, 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0204 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause | User | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2 Congestion Test Message (CGT) CGT is used to support Signalling-route-set-congestion-test(National Option) procedures as defined in Q.704. It is used to test the congestion status of a PC via a specific SG. The CGT message contains the following parameters: Affected PC Mandatory Concerned DPC Mandatory Congestion Level Mandatory Info String Optional The format for CGT Message parameters is 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 = 0x0200 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0012 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask | Affected PC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0206 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Concerned DPC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0205 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Cong. Level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ 6 Bidulock/Asveren Internet Draft M3UA SG-SG Communication May, 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network Appearance: 32 bits See M3UA Section 3.1.1 Affected Point Code: 32 bits Affected Point Code parameter contains the 14-, 16-, 24-bit binary formatted point code value, for which CGT message is generated. Concerned DPC: 32 bits Concerned DPC parameter contains the 14-, 16-, 24-bit binary formatted point code value, whose congestion status is to be tested. Congestion Level: 8 bits (unsigned integer) The Congestion Level parameter contains one of the following values: 0 No Congestion or Undefined 1 Congestion Level 1 2 Congestion Level 2 3 Congestion Level 3 The congestion levels are defined in the congestion method in the appropriate national MTP recommendations [. .]. When sending CGT message, procedures defined for Signalling-route- set-congestion-test in Q.704 Clause 13.9 should be followed. 4.3 Traffic Allowed Message(TAL) TAL is used to indicate to a peer the end of SSNM , which are sent to declare list of not allowed/restricted point codes, after a SCTP association is established. The TAL message contains the following parameters: Network Appearance Optional In case the same association is used to carry traffic for more than one network, Network Appearance parameter MUST be filled. The format for TAL Message parameters is as follows: 0 1 2 3 7 Bidulock/Asveren Internet Draft M3UA SG-SG Communication May, 2002 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 = 0x0200 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network Appearance: 32 bits See M3UA Section 3.1.1 . Info String: variable length See M3UA Section 3.4.1 . 4.4 Changeover Mechanism Related Messages Those messages are necessary to support changeover mechanism as defined in MTP3. It should be noted, they will be used, in case a SG is relaying corresponding MTP3 changeover messages to another SG peer. +-----+ +-----+ |STP1 +-----X------+ SG2 | +--+--+ +--+--+ | | | | | | | | | +-----+ | +-----+ SG1 +------+ +-----+ Figure 3. SG1 relaying changeover messages to and from SG2 4.4.1 Changeover Request Message(COR) COR is used to relay changeover order indicated by COO MTP3 message from a SS7 peer. COR message contains the following parameters: 8 Bidulock/Asveren Internet Draft M3UA SG-SG Communication May, 2002 Network Appearence: SLC : 5 bits The Signalling Link Code of the failed link. FSN : 7 bits Forwards sequence number of the last message signal unit accepted from the unavailable signaling link by the sender of COO. Affected Point Code: 32 bits Affected Point Code parameter contains the 14-, 16-, 24-bit binary formatted point code value, which has sent COO message. The format for COR message parameters is 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 = 0x0200 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0214 | Length =8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | FSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0215 | Length =8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | SLC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0012 | Length =8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Affected PC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.4.2 Changeover Request Acknowledgement Message (CORA) CORA is used to relay the FSN information regarding the last accepted MSUs by a failed link from a peer SG to a SS7 node. COR message contains the following parameters: SLC : 5 bits The Signalling Link Code of the failed link. 9 Bidulock/Asveren Internet Draft M3UA SG-SG Communication May, 2002 FSN : 7 bits Forwards sequence number of the last message signal unit accepted from the unavailable signaling link by the sender of CORA. Affected Point Code: 32 bits Affected Point Code parameter contains the 14-, 16-, 24-bit binary formatted point code value, to which the COA to be generated based on the received CORA, should be sent. The format for parameters for CORA is the same like COR. 5. Security SG-SG communication does not intoduce any new security risks or considerations that are not already inherent in M3UA. Please see "Security" section of M3UA for security considerations and recommendations. 6. Acknowledgements The authors would like to thank Manfred Angermayr, Javier Pastor- Balbas and Vaibhav Madan for their valuable comments and suggestions. 7. References 7.1 Normative References [1] ITU-T Recommendation Q.704 "Specifications of Signalling System No. 7 - Message transfer part Signalling network functions and messages" [2] RFC[..] "SS7 MTP3 - User Adaptation Layer (M3UA)" 7.2 Informative References [3] RFC[2119] "Key words for use in RFCs to Indicate Requirement Levels" 8. Author's Addresses Brian Bidulock OpenSS7 Corporation C/o #424, 4701 Preston Park Blvd. 10 Bidulock/Asveren Internet Draft M3UA SG-SG Communication May, 2002 Plano, TX, USA 75093 EMail : bidulock@openss7.org Tolga Asveren SS8 Networks Inc. 2 Enterprise Drive Shelton, CT USA 06484 Email : tolga.asveren@ss8.com 11