Network Working Group Brian Bidulock INTERNET-DRAFT OpenSS7 TomGeorge Alcatel Ram Dantu Netrake Malleswar Kalla Telcordia Hanns Juergen Schwarzbauer Siemens KenMorneault Cisco Systems GregSidebottom Expires July 2003 January 7, 2003 SS7 MTP2-User Peer-to-Peer Adaptation Layer M2PA <draft-ietf-sigtran-m2pa-07.ps> 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 anytime. Itis 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 ShadowDirectories can be accessed 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 This Internet Draft defines a protocol supporting the transport of Signalling System Number 7 (SS7) Message Transfer Part (MTP) Level3signalling messages overInternet Protocol (IP) using the services of the Stream Control Transmission Proto- col (SCTP). This protocol would be used between SS7 Signalling Points using the MTP Level 3 protocol. The SS7 Sig- nalling Points may also use standard SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 3 signalling messages. 1. Introduction 1.1. Scope There is a need for Switched Circuit Network (SCN) signalling protocol delivery overanIPnetwork. Thisincludes message transfer between the following: • aSignalling Gateway(SG) and a Media GatewayController (MGC) [Q.700] • aSG and an IP Signalling Point (IPSP) • anIPSP and an IPSP This could allow for convergence of some signalling and data networks. SCN signalling nodes would have access to databases and other devices in the IP network domain that do not use SS7 signalling links. Likewise, IP telephonyapplica- tions would have access to SS7 services. There may also be operational cost and performance advantages when traditional B. Bidulock, et al Version 0.7 Page 1 Internet-Draft M2PA January 7, 2003 signalling links are replaced by IP network “connections”. The delivery mechanism described in this document allows for full MTP3 message handling and network management capa- bilities between anytwo SS7 nodes, communicating overanIPnetwork. AnSS7 node equipped with an IP network connec- tion is called an IP Signalling Point (IPSP). The IPSPs function as traditional SS7 nodes using the IP network instead of SS7 links. The delivery mechanismSHOULD • Support seamless operation of MTP3 protocol peers overanIPnetwork connection. • Support the MTP Level2/MTP Level3interface boundary. • Support management of SCTP transport associations and traffic instead of MTP2 Links. • Support asynchronous reporting of status changes to management. 1.2. ChangeHistory This section will be removedfrom the document when the document is finalized. 1.2.1. Changesfrom Version 0.6 to Version 0.7 • added this section • reformatted document • updated references and version number • updated state transition diagrams • changed timer names to align with Q.703 [Q.703] • added proving state and procedure for timer T3 • fixednits from the mailing list • adjusted recommended timer values for alignment with Q.703 [Q.703] • adjusted language on T7 timer to match WG comments • created postscript diagrams • spelling corrections 1.3. Terminology MTP−The Message Transfer Part of the SS7 protocol [Q.701, Q.702, Q.703, Q.704..T1.111]. MTP2−MTP Level2,the MTP signalling link layer. MTP3−MTP Level3,the MTP signalling network layer. MTP2-User−Aprotocol that normally uses the services of MTP Level2. The only MTP2 user is MTP3. The MTP2 user is equivalent to the M2PAuser. Signalling End Point (SEP)−Anode in an SS7 network that originates or terminates signalling messages. One example is acentral office switch. IP Signalling Point (IPSP)−AnSS7 Signalling Point with an IP network connection used for SS7 overIP. Signalling Gateway (SG)−Asignalling agent that receives/sends SCN native signalling at the edge of the IP network [RFC 2719]. Inthis context, an SG is an SS7 Signalling Point that has both an IP network connection used for SS7 over IP,and a traditional (non-IP) link to an SS7 network. Signalling Transfer Point (STP) − A node in an SS7 network that routes signalling messages based on their destination point code in the SS7 network. Association − An association refers to a SCTP association [RFC 2960]. The association provides the transport for MTP3 protocol data units and M2PAadaptation layer peer messages. Network Byte Order−Most significant byte first, also known as “Big Endian”. See RFC 791 [RFC 791], Appendix B Data Transmission Order. Stream−Astream refers to a SCTP stream [RFC 2960]. 1.4. Abbreviations BSNT − Backward Sequence Number to be Transmitted B. Bidulock, et al Version 0.7 Page 2 Internet-Draft M2PA January 7, 2003 FSNC − Forward Sequence Number of last message accepted by remote level2 LI − Length Indicator MSU − Message Signal Unit SCCP − Signalling Connection Control Part SCN − Switched Circuit Network SCTP − Stream Control Transmission Protocol SIF − Signalling Information Field SIO − Service Information Octet SLC − Signalling Link Code SS7 − Signalling System Number 7 SSN − Stream Sequence Number STP − Signal Transfer Point 1.5. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOM- MENDED,NOTRECOMMENDED,MAY,andOPTIONAL,when theyappear in this document, are to be interpreted as described in RFC 2119 [RFC 2119]. 1.6. SignallingTransport Architecture The architecture that has been defined [RFC 2719] for Switched Circuit Network (SCN) signalling transport over IP uses multiple components, including an IP transport protocol, the Stream Control Transmission Protocol (SCTP), and an adapta- tion module to support the services expected by a particular SCN signalling protocol from its underlying protocol layer. Within this framework architecture, this document defines an SCN adaptation module that is suitable for the transport of SS7 MTP3 messages. Figure1 shows the seamless interworking at the MTP3 layer. MTP3 is adapted to the SCTP layer using the MTP2 User Peer-to-peer Adaptation Layer (M2PA). All the primitives between MTP3 and MTP2 are supported by M2PA. The SCTP association acts as one SS7 link between the IPSPs. An IPSP MAY have the Signalling Connection Control Part (SCCP) and other SS7 layers above MTP3. IP IPSP IPSP TCAP TCAP SCCP SCCP MTP3 MTP3 M2PA M2PA SCTP SCTP IP IP IP -Inter netProtocol IPSP -IPSignalling Point SCTP -Stream Control Transmission Protocol (see Reference [RFC 2960]) Figure1. M2PASymmetrical Peer-to-Peer Architecture Figure2shows an example of M2PAused in a Signalling Gateway(SG). TheSG is an IPSP equipped with both traditional SS7 and IP network connections. In effect, the Signalling Gatewayacts as a Signal Transfer Point (STP). Anyofthe nodes in the diagram could have SCCP or other SS7 layers. STPsMAYorMAYNOTbe present in the SS7 path between the SEP and the SG. B. Bidulock, et al Version 0.7 Page 3 Internet-Draft M2PA January 7, 2003 SS7 IP SEP SG IPSP TCAP TCAP SCCP SCCP MTP3 MTP3 MTP3 MTP2 MTP2 M2PA M2PA MTP1 MTP1 SCTP SCTP IP IP SEP -SS7 Signalling Endpoint Figure2. M2PAinIPSignalling Gateway Figure2 only an example. Other configurations are possible. In short, M2PA uses the SCTP association as an SS7 link. The M2PA/SCTP/IP stack can be used in place of an MTP2/MTP1 stack. 1.6.1. Point Code Representation The MTP specification requires that each node with an MTP3 layer is identified by an SS7 point code. In particular, each IPSPMUSThave its own SS7 point code. 1.7. Services Provided by M2PA The SS7 MTP3/MTP2 (MTP2-User) interface is retained in the IPSP. The M2PA protocol layer is required to provide the equivalent set of services to its user as provided by MTP Level2toMTP Level3. These services are described in the following subsections. 1.7.1. SupportforMTP Level2/MTP Level3interface boundary This interface is the same as the MTP2/MTP3 interface described in Q.701 through Q.705 [Q.701, Q.702, Q.703, Q.704..T1.111], and Q.2140 [Q.2140], with the addition of support for larger sequence numbers in T1.111 [T1.111] and Q.2210 [Q.2210]. Because M2PA uses larger sequence numbers than MTP2, the MTP3 Changeover procedure MUST use the Extended Changeover Order and Extended Changeover Acknowledgment messages described in Q.2210 [Q.2210] and T1.111 [T1.111]. Also, the following MTP3/MTP2 primitivesMUSTuse the larger sequence numbers: • BSNT Confirmation • RetrievalRequest and FSNC 1.7.2. Supportforpeer-to-peer communication In SS7, MTP Level2sends three types of messages, known as signal units: Message Signal Units (MSUs), Link Status Sig- nal Units (LSSUs), and Fill-In Signal Units (FISUs). MSUs originate at a higher levelthan MTP2, and are destined for a peer at another node. Likewise, M2PApasses these mes- sages from MTP3 to SCTP as data for transport across a link. These are called User Data messages in M2PA. LSSUs allowpeer MTP2 layers to exchange status information. Analogous messages are needed for M2PA. TheLink Sta- tus message serves this purpose. FISUs are sent when no other signal units are waiting to be sent. This purpose is served by the heartbeat messages in SCTP. FISUs also carry acknowledgment of messages. This function is performed by the M2PA User Data and Link Status mes- sages. Therefore, it is unnecessary for M2PA to provide a protocol data unit like the FISU. Furthermore, since an IP net- work is a shared resource, it would be undesirable to have a message type that is sent continuously as the FISUs are. B. Bidulock, et al Version 0.7 Page 4 Internet-Draft M2PA January 7, 2003 1.8. FunctionsProvided by M2PA 1.8.1. Supportof MTP3/MTP2 Primitives M2PAreceivesthe primitivessent from MTP3 to its lower layer. M2PAprocesses these primitivesormaps them to appro- priate primitives at the M2PA/SCTP interface. Likewise, M2PA sends primitives to MTP3 like those used in the MTP3/MTP2 interface. 1.8.2. MTP2Functionality M2PAprovides MTP2 functionality that is not provided by SCTP. This includes • Data retrievaltosupport the MTP3 changeoverprocedure • Reporting of link status changes to MTP3 • Processor outage procedure • Link alignment procedure SCTP provides reliable, sequenced delivery of messages. 1.8.3. Mappingof SS7 and IP Entities The M2PAlayerMUSTmaintain a map of each of its SS7 links to the corresponding SCTP association. 1.8.4. SCTPStream Management SCTP allows a user-specified number of streams to be opened during the initialization. It is the responsibility of the M2PA layer to ensure proper management of the streams allowed within each association. M2PAuses twostreams in each direction for each association. Stream 0 in each direction is designated for Link Status mes- sages. Stream 1 is designated for User Data messages. Separating the Link Status and User Data messages onto separate streams allows M2PAtoprioritize the messages in a manner similar to MTP2. 1.8.5. Retentionof MTP3 in the SS7 Network M2PA allows MTP3 to perform all of its Message Handling and Network Management functions with IPSPs as with other SS7 nodes. 1.9. Definitionof the M2PABoundaries 1.9.1. Definitionof the M2PA/MTP Level3boundary The upper layer primitivesprovided by M2PAare the same as those provided by MTP2 to MTP3. These primitivesare de- scribed in Q.701 through Q.705 [Q.701, Q.702, Q.703, Q.704, Q.705], and T1.111 [T1.111]. and Q.2140 [Q.2140]. Follow- ing is a list of the primitives. Primitivessent from MTP3 to M2PA: Data Request Used to send a Data Message for transmission. Start Request Used to activate a link. Stop Request Used to deactivate a link. Retrieve BSNT Request Request the BSNT for the changeoverprocedure. RetrievalRequest and FSNC Request retrieval of unacknowledged and unsent messages. This request in- cludes the FSNC receivedfrom the remote end. Local Processor Outage Request Informs M2PAofalocal processor outage condition. Local Processor Outage Recovered Informs M2PAthat a local processor outage condition has ceased. Request B. Bidulock, et al Version 0.7 Page 5 Internet-Draft M2PA January 7, 2003 Flush Buffers Request Requests that all transmit and receive buffers be emptied. Continue Request Requests that processing resume after a processor outage. EmergencyRequest Requests that M2PAuse the emergencyalignment procedure. EmergencyCeases Request Requests that M2PAuse the normal alignment procedure. Primitivessent from M2PAtoMTP3: Data Indication Used to deliverreceivedData Message to MTP3. Congestion Indication Indicates change in congestion status. The indication includes the congestion status, if the protocol is using the OPTIONAL congestion levels. The indica- tion also includes the discard status. In Service Indication Indicates that the link is in service. Out of Service Indication Indicates that the link is out of service. RetrievedMessages Indication Indicates delivery of unacknowledged and unsent messages. RetrievalComplete Indication Indicates that delivery of unacknowledged and unsent messages is complete. BSNT Confirm Replies to the BSNT Request. The confirmation includes the BSNT. BSNT Not Retrievable Confirm Replies to the BSNT Request when the BSNT cannot be determined. Remote Processor Outage Indica- Indicates processor outage at remote end. tion Remote Processor Recovered Indi- Indicates recovery from processor outage at remote end. cation 1.9.2. Definitionof the Lower Layer Boundary between M2PAand SCTP The upper layer primitives provided by SCTP are described in RFC 2960 [RFC 2960] Section 10 “Interface with Upper Layer”. 1.10. Differences Between M2PAand M2UA The MTP2 User Adaptation Layer (M2UA) [M2UA] also adapts the MTP3 layer to the SCTP/IP stack. It does so through a backhauling architecture [RFC 2719]. This section intends to clarify some of the differences between the M2PAand M2UA approaches. A possible M2PA architecture is shown in Figure3. Here the IPSPs MTP3 uses its underlying M2PA as a replacement for MTP2. Communication between the two layers MTP3/M2PA is defined by the same primitives as in SS7 MTP3/MTP2. M2PAperforms functions similar to MTP2. B. Bidulock, et al Version 0.7 Page 6 Internet-Draft M2PA January 7, 2003 SS7 IP SEP SG IPSP SCCP SCCP SCCP MTP3 MTP3 MTP3 MTP2 MTP2 M2PA M2PA MTP1 MTP1 SCTP SCTP IP IP Figure3. M2PAinIPSignalling Gateway A comparable architecture for M2UA is shown in Figure4. In M2UA, the MGCs MTP3 uses the SG’s MTP2 as its lower SS7 layer. Likewise, the SG’s MTP2 uses the MGCs MTP3 as its upper SS7 layer. In SS7, communication between the MTP3 and MTP2 layers is defined by primitives. In M2UA, the MTP3/MTP2 communication is defined as M2UA mes- sages and sent overthe IP connection. SS7 IP SEP SG IPSP SCCP SCCP MTP3 (NIF) MTP3 MTP2 MTP2 M2PA M2PA MTP1 MTP1 SCTP SCTP IP IP NIF -Nodal Interwor kingFunction Figure4. M2UAinIPSignalling Gateway M2PAand M2UAare similar in that: a. Both Transport MTP3 data messages. b. Both Present an MTP2 upper interface to MTP3. Differences between M2PAand M2UAinclude: a. M2PA: IPSP processes MTP3/MTP2 primitives. M2UA: MGC transports MTP3/MTP2 primitives between the SG’s MTP2 and the MGCs MTP3 (via the NIF) for processing. b. M2PA: SG-IPSP connection is an SS7 link. M2UA: SG-MGC connection is not an SS7 link. It is an extension of MTP to a remote entity. c. M2PA: SG is an SS7 node with a point code. M2UA: SG is not an SS7 node and has no point code. d. M2PA: SG can have upper SS7 layers, e.g., SCCP. M2UA: SG does not have upper SS7 layers since it has no MTP3. e. M2PA: relies on MTP3 for management procedures. M2UA: uses M2UAmanagement procedures. B. Bidulock, et al Version 0.7 Page 7 Internet-Draft M2PA January 7, 2003 Potential users of M2PA and M2UA SHOULD be aware of these differences when deciding how to use them for SS7 sig- nalling transport overIPnetworks. 2. Protocol Elements This section describes the format of various messages used in this protocol. All fields in an M2PAmessageMUSTbe transmitted in the network byte order,i.e., most significant byte first, unless other- wise stated. 2.1. Common Message Header The protocol messages for M2PArequire a message header structure which contains a version, message class, message type, and message length. The header structure is shown inFigure5. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Spare | Message Class | Message Type | +- - - - - - - -+- - - - - - - -+- - - - - - - -+- - - - - - - -+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure5. Common Message Header 2.1.1. Version The version field contains the version of M2PA. Thesupported versions are: Value (decimal) Version 1 Release 1.0 of M2PAprotocol 2.1.2. Spare The Spare field SHOULD be set to all zeroes (0’s) by the sender and ignored by the receiver. The Spare field SHOULD NOTbe used for proprietary information. 2.1.3. MessageClass The following List contains the valid Message Classes: Value (decimal) MessageClass 11 M2PAMessages Other values are invalid for M2PA. 2.1.4. MessageType The following list contains the message types for the defined messages. Value (decimal) MessageType 1 User Data 2 Link Status Other values are invalid. B. Bidulock, et al Version 0.7 Page 8 Internet-Draft M2PA January 7, 2003 2.1.5. MessageLength The Message Length defines the length of the message in octets, including the Common Header. 2.2. M2PAHeader All protocol messages for M2PArequire an M2PA-specific header. The header structure is shown inFigure6. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | BSN | +- - - - - - - -+- - - - - - - - - - - - - - - - - - - - - - - -+ | unused | FSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure6. M2PA-specific Message Header 2.2.1. BackwardSequence Number This is the FSN of the message last receivedfrom the peer. 2.2.2. Forward Sequence Number This is the M2PAsequence number of the User Data message being sent. 2.3. M2PAMessages The following section defines the messages and parameter contents. An M2PA message consists of a Common Message Header and M2PAHeader followed by the data appropriate to the message. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Common Message Header / \ \ +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ \ \ / M2PA-specific Message Header / \ \ +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ / / \ \ / Message Data / \ \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.3.1. UserData The User Data is the data sent from MTP3. The format for the User Data message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ \ / Data / \ \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Data field contains the following fields of the MTP Message Signal Unit (MSU): • Length Indicator (LI), including the twoundefined bits between the SIO and LI fields. • Service Information Octet (SIO) • Signalling Information Field (SIF) The MTP MSU described in Q.703 [Q.703], section 2.2 Signal Unit Format, and T1.111.3 [T1.111] section 2.2 Signal Unit Format. B. Bidulock, et al Version 0.7 Page 9 Internet-Draft M2PA January 7, 2003 M2PAdoes not add padding to the MTP3 message. Note that the Data fieldSHALL NOTcontain other components of the MTP MSU format: • Flag • Backward Sequence Number (BSN) • Backward Indicator Bit (BIB) • Forward Sequence Number (FSN) • Forward Indicator Bit (FIB) • Check bits (CK) The Data fieldSHALLbe transmitted in the byte order as defined by MTP3. It is not necessary to put the message length in the LI octet as in MTP2. The LI octet is included because the twospare bits in the LI octet are used by MTP3 in at least one national version of SS7 to carry MTP3 information. For example, the Japanese TTC standard uses these spare bits as an MTP3 Message Priority field. See JT-Q704 [JT-Q704], section 14 “Com- mon Characteristics of message signal unit formats”, section 14.2 (A) Priority Indicator (PRI). Forversions of MTP that do not use these twobits, the entire octet is spare. Therefore in M2PAthe format of the LI octet is: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |PRI| spare | (followed by SIO, SIF) +-+-+-+-+-+-+-+-+ PRI− Priority used only in national MTP defined in JT-Q704 [JT-Q704]. Sparefor other MTP versions. Since the LI octet is not used for a message length, there is no need to support the expanded LI field in Q.703 [Q.703], An- nexA. Therefore the LI field in M2PAisalways one octet. Note: In the SS7 Recommendations, the format of the messages and fields within the messages are based on bit transmission order. In these recommendations the Least Significant Bit (LSB) of each field is positioned to the right. The received SS7 fields are populated octet by octet as receivedinto the 4-octet word as shown below. As an example, in the ANSI MTP protocol, the Data field format is shown below: |MSB---------------------------------------------------------LSB| 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 .)b +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PRI| spare | SIO | SIF octet | ... | +- -+- - - - - -+- - - - - - - -+- - - - - - - -+- - - - - - - -+ \ . \ / . / \ . \ +- - - - - - - -+- - - - - - - -+- - - - - - - -+- - - - - - - -+ | ... | ... | ... | SIF octet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Within each octet the Least Significant Bit (LSB) per the SS7 Recommendations is to the right (e.g., bit 15 of SIO is the LSB). 2.3.2. LinkStatus The MTP2 Link Status message can be sent between M2PApeers to indicate link status. This message performs a function similar to the the Link Status Signal Unit in MTP2. The format for the Link Status message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The valid values for State are shown in the following table. B. Bidulock, et al Version 0.7 Page 10