HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 00:05:24 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 15 Mar 2000 16:01:00 GMT ETag: "2e9a16-99e0-38cfb3bc" Accept-Ranges: bytes Content-Length: 39392 Connection: close Content-Type: text/plain Network Working Group Tom George INTERNET-DRAFT Alcatel Ken Morneault Cisco Systems Mallesh Kalla Telcordia Greg Sidebottom Nortel Networks Ram Dantu IPmobile Expires September 2000 March 10, 2000 SS7 MTP2-User Peer-to-Peer Adaptation Layer 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/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 '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). George, et al [Page 1] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 Abstract This Internet Draft defines a protocol for adapting the SS7 MTP2 User for signaling over an IP connection using the Simple Control Transmission Protocol (SCTP). This protocol is used between SS7 Signaling Points equipped with an IP connection (IPSPs). Signaling points using this protocol are capable of MTP Level 3 routing. This protocol may be used in a Signaling Gateway (SG). The SG receives SS7 signaling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport, and has the capability to use MTP to route signaling to IPSPs. The protocol thereby retains the features of MTP Level 3, including Network Management. George, et al [Page 2] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 TABLE OF CONTENTS 1. Introduction............................................. 4 1.1 Scope................................................. 4 1.2 Terminology........................................... 4 1.3 Signaling Transport Architecture...................... 5 1.4 Services Provided by the MTP2 User Adaptation Layer... 6 1.5 Functions Provided by the MTP2 User Adaptation Layer.. 7 1.6 Definition of the M2UA Boundaries..................... 7 2. Protocol Elements........................................ 7 2.1 Common Message Header................................. 8 2.2 M2UA Messages......................................... 8 3. Procedures...............................................10 3.1 Procedures to Support MTP2 Features...................10 3.2 Procedures to Support the MTP3/MTP2 Interface.........13 4. Examples of MTP2 User Adaptation (M2UA) Procedures.......14 4.1 Link Initialization (Alignment).......................15 4.2 Message Transmission and Reception....................17 4.3 Link Status Indication................................17 4.4 Link Status Message (Processor Outage)................18 4.5 Congestion Notification to Upper layer................19 4.6 Link Deactivation.....................................20 4.7 Link Changeover.......................................21 5. Security.................................................22 6. Acknowledgements.........................................22 7. References...............................................22 8. Author's Addresses.......................................22 George, et al [Page 3] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 1. Introduction 1.1 Scope There is a need for SCN signaling protocol delivery from an Signaling Gateway (SG) to an IP Signaling Point (IPSP). In other words, the Signaling Gateway will transport MTP Level 3 messages to an IPSP. The delivery mechanism should * Support the MTP Level 2 / MTP Level 3 interface boundary * Provide for peer-to-peer communication similar to that provided by MTP Level 2. The SG and IPSP function as traditional SS7 nodes using the IP network as a new type of SS7 link. This allows for full MTP Level 3 message handling and network management capabilities. Throughout this document, M2UA is used to refer to the MTP 2 User Peer-to-Peer case. This should not be confused with the MTP 2 User Backhauling case described in [6]. 1.2 Terminology MTP - The Message Transfer Part of the SS7 protocol [2]. MTP2 - MTP Level 2, the signaling network layer. MTP3 - MTP Level 3, the MTP signaling link layer. MTP2-User - A protocol that normally uses the services of MTP Level 2. The only MTP2 user is MTP3. Signaling End Point (SEP) - A node in an SS7 network that originates or terminates signaling messages. One example is a central office switch. IP Signaling Point (IPSP) - An SS7 Signaling Point with an IP connection used for SS7 over IP. An IPSP may or may not have a traditional (non-IP) SS7 link. Signaling Gateway - An SS7 Signaling Point that has both an IP connection used for SS7 over IP, and a traditional (non-IP) link to an SS7 network. Signaling Transfer Point (STP) - A node in an SS7 network that routes signaling messages based on their destination point code in the SS7 network. Association - An association refers to a SCTP association [5]. George, et al [Page 4] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 Stream - A stream refers to a SCTP stream [5]. 1.3 Signaling Transport Architecture The architecture that has been defined [4] for SCN signaling transport over IP uses multiple components, including an IP transport protocol, the Simple Control Transmission Protocol (SCTP) and an adaptation module to support the functions expected by a particular SCN signaling protocol from its underlying protocol layer. In reference to the SIGTRAN framework architecture [4], this document defines a SCN adaptation module that is suitable for the transport of SS7 MTP2 User. The only SS7 MTP2 User is MTP3. Figure 1 shows the seamless interworking at the MTP3 layer. MTP3 is adapted to the SCTP layer using the MTP2 User Adaptation Layer (M2UA). All the primitives between MTP3 and MTP2 are supported by M2UA. The SCTP association acts as an SS7 link between the SG and the IPSP. The association contains two streams, one in each direction. In this example, the Signaling Gateway could be an STP. Any of the nodes in the diagram could have SCCP or other SS7 user parts. STPs may or may not be present in the SS7 path between the SEP and the SG. The IPSP may or may not have a termination to the SS7 network. ******** SS7 *************** IP *************** * SEP *--------* SG *--------* IPSP * ******** *************** *************** +------+ +-------------+ | TCAP | | TCAP | +------+ +-------------+ | SCCP | | SCCP | +------+ +-------------+ +-------------+ | MTP3 | | MTP3 | | MTP3 | +------+ +------+------+ +------+------+ | MTP2 | | MTP2 | M2UA | | M2UA | MTP2 | +------+ +------+------+ +------+------+ | MTP1 | | MTP1 | SCTP | | SCTP | MTP1 | | | | +------+ +------+ | | | | | IP | | IP | | +------+ +------+------+ +------+------+ SEP - SS7 Signaling Endpoint IP - Internet Protocol IPSP - IP Signaling Point SCTP - Simple Control Transmission Protocol (see Reference [5]) Figure 1: M2UA Symmetrical Peer-to-Peer Architecture George, et al [Page 5] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 Figure 1 is only an example. Other configurations are possible. For example, IPSPs without traditional SS7 links could use the protocol layers MTP3/M2UA/SCTP/IP to route SS7 messages in a network with all IP links. 1.3.1 UDP port A request will be made to IANA to assign a UDP port for M2UA peer-to-peer. 1.4 Services Provided by the MTP2 User Adaptation Layer The SS7 MTP3/MTP2 (MTP2-User) interface is retained at the termination point in the IP network. The M2UA protocol layer is required to provide the equivalent set of services to its user as provided by MTP Level 2 to MTP Level 3. These services are described in the following subsections. 1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary This interface is the same as the MTP2/MTP3 interface described in [2], with the following exception: * The interface must support the larger sequence numbers used by SCTP. Reference [7] can be used as a guide for the MTP3 changes. 1.4.2 Support for peer-to-peer communication In SS7, MTP Level 2 sends three types of messages, known as signal units: Message Signal Units (MSUs), Link Status Signal Units (LSSUs), and Fill-In Signal Units (FISUs). MSUs originate at a higher level than MTP2, and are destined for a peer at another node. Likewise, M2UA passes these messages from MTP3 to SCTP as data for transport across a link. LSSUs allow peer MTP2 layers to exchange status information. Analogous messages are needed for M2UA. FISUs are sent when no other signal units are waiting to be sent. It is unnecessary for M2UA to send FISUs, since their purpose is served by the heartbeat messages in SCTP. To perform the function of MTP2 in traditional SS7, the following protocol element is defined. Link Status Provides a means for asychronous notification of link state to an M2UA George, et al [Page 6] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 peer. An example would be the reporting of a local processor outage. 1.5 Functions Provided by the MTP2 User Adaptation Layer 1.5.1 Mapping The M2UA layer must maintain a map of an SS7 link to an SCTP association and to a stream within the association. The M2UA layer must also maintain a map of an SS7 link to its corresponding IP destination. 1.5.2 Flow Control / Congestion It is possible for the M2UA layer to be informed of IP network congestion by implementation-dependent means (e.g., an indication from SCTP). If the M2UA layer receives this indication, it notifies MTP3 so that MTP3 can invoke its congestion procedures. 1.5.3 SCTP Stream Management SCTP allows user specified number of streams to be opened during the initialization. It is the responsibility of the M2UA layer to ensure proper management of the two streams allowed within each association. 1.5.4 Retention of MTP3 in the SS7 Network M2UA allows MTP3 to perform all of its Message Handling and Network Management functions with IPSPs as with other SS7 nodes. 1.6 Definition of the M2UA Boundaries 1.6.1 Definition of the M2UA / MTP Level 3 boundary The upper layer primitives provided by M2UA are the same as those provided by MTP2 to MTP3 [2]. 1.6.2 Definition of the Lower Layer Boundary between M2UA and SCTP The upper layer and layer management primitives provided by SCTP are described in Reference [5] Section 9. 2. Protocol Elements This section describes the format of various messages used in this protocol. All fields in an M2UA message must be transmitted in the network byte order, i.e., most significant byte first, unless otherwise stated. George, et al [Page 7] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 2.1 Common Message Header The protocol messages for MTP2 User Adaptation require a message header structure which contains a version, message type and message length. This message header is common among all SCN adaptation layers. The header structure is shown in Figure 2. 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 Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Figure 2: Common Message Header 2.1.1 Version The version field (vers) contains the version of the M2UA adapation layer. The supported versions are: 01 Release 1.0 of M2UA adaptation protocol 2.1.2 Message Type The valid message types are defined below and the message contents are described in Section 2.2. Each message can contain parameters. The following list contains the message types for the defined messages. MTP2 User Adaptatation Messages Data 0601 Link Status 0602 2.1.3 Message Length The Message length defines the length of the message in octets, not including the header. 2.2 M2UA Messages The following section defines the messages and parameter contents. The George, et al [Page 8] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 M2UA messages will use the command header and the M2UA specific header. 2.2.1 Data The Data message contains an SS7 MTP2-User message. It is the equivalent of a Message Signal Unit in MTP. The format for the 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Protocol Data | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the Protocol Data field contains only the MTP2-User application message. The header transmitted by MTP2 (which includes the Flag, BSN, BIB, FSN, FIB, LI) is not included in M2UA. 2.2.2 Link Status The MTP2 Link Status message can be sent between M2UA peers to indicate link status. It is the equivalent of the Link Status Signal Unit in MTP. 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. All values defined in the MTP2 Link Status Signal Unit have an equivalent in this M2UA Link Status message. This does not imply that all values must be used by M2UA. Define Value Description STATUS_O 0x0 Status indication O - Out of alignment STATUS_N 0x1 Status indication N - Normal alignment status STATUS_E 0x2 Status indication E - Emergency alignment status STATUS_OS 0x3 Status indication OS - Out of Service STATUS_PO 0x4 Status indication PO - Processor Outage STATUS_B 0x5 Status indication B - Busy George, et al [Page 9] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 3. Procedures 3.1 Procedures to Support MTP2 Features 3.1.1 Signal Unit Format, Delimitation, Acceptance Messages for transmission across the network must follow the format described in section 2. SCTP provides message delimitation, sequence numbering, and error correction. Therefore the header transmitted by MTP2 (which includes the Flag, BSN, BIB, FSN, FIB, LI) is not needed in M2UA. 3.1.2 Link Alignment MTP3 can request that an SS7 link be brought into alignment ([2] Q.703, section 7). During alignment, communication to the other end of the link is tested for a period of time to make sure that the link is ready for traffic. Once the link is aligned, proving begins. During proving, messages are sent from both ends of the link to verify that the link is capable of sustaining traffic. Proving may take place for a Normal or (shorter) Emergency time period. MTP3 determines whether the alignment procedure is Normal or Emergency, and informs M2UA through the Emergency and Emergency Ceases commands. To begin alignment in M2UA, M2UA sends the Associate primitive to SCTP. The association shall contain one stream in each direction. If SCTP fails to establish the association, M2UA shall report to MTP3 that the link is out of service. Once the association is established, M2UA sends Link Status SIO to its peer at an implementation-dependent rate. If the remote end sends a Link Status of SIN, SIE, or SIO before time interval T2 elapses, the link is in an aligned state. If the remote end does not send one of those Link Status messages before T2, M2UA shall report to MTP3 that the link is out of service. When the link gets to an aligned state, M2UA sends Link Status SIN or SIE (for Normal or Emergency proving) at an implementation-dependent rate. If the remote end sends a Link Status of SIN, SIE, or SIO before time interval T3 elapses, the link is in proving state. If the remote end does not send one of those Link Status messages before T3, M2UA shall report to MTP3 that the link is out of service. While in the proving state, M2UA continues to send SIN/SIEs for a period of T4. If T4 elapses and the link has not failed, proving is complete. The link is ready for traffic. When proving is complete, M2UA may send a Status primitive to SCTP to determine if the smoothed round-trip time and other status data are George, et al [Page 10] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 acceptable. Sending of the Status primitive is optional. Use of the Status information is implementation dependent. 3.1.3 Processor Outage A processor outage occurs when M2UA cannot transfer messages to MTP3. When M2UA detects a local processor outage (e.g., by receiving a Local Processor Outage from MTP3), it sends a Link Status message to its peer with status PO. It discards any messages received. The peer M2UA, upon receiving the Link Status PO message, notifies its MTP3. It ceases sending Data messages. When the processor outage ceases, MTP3 sends a Local Processor Recovered indication to M2UA. The local M2UA notifies its peer by sending the next Data message. The peer notifies its MTP3 that the remote processor outage has ceased. 3.1.4 Level 2 Flow Control Congestion control is provided by SCTP. Any congestion control procedures in M2UA are implementation dependent. MTP3 expects notification of link congestion. For example, this is accomplished by two messages 1) Link Congestion Onset 2) Link Congestion Abated. For example, congestion could be detected if M2UA receives a failure response when it attempts to send a message to SCTP (this is implementation dependent, and it is assumed that the SEND Failure has an error code that indicates congestion). M2UA reports Link Congestion Onset to MTP3. Subsequently M2UA can poll the status of SCTP. When SCTP is no longer congested, M2UA reports Link Congestion Abated to MTP3. If the congestion condition should continue, the link will be taken out of service. In this case, it is possible to start the link changeover procedure. The US National version of SS7 has congestion levels [3]. For US National SS7, the Indication primitive for Congestion Onset should report the congestion level. 3.1.5 Error monitoring If M2UA loses the SCTP association for a link, M2UA shall report to MTP3 that the link is out of service. 3.1.6 MTP2 Timers in M2UA This section explains which MTP2 timers are needed in M2UA. 3.1.6.1 T2 Not Aligned, T3 Aligned Timers T2 and T3 are used to verify that the other end of the link is George, et al [Page 11] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 communicating. In MTP2, if either of timers T2 or T3 expire, alignment is not possible, so MTP2 reports to MTP3 that the link is out of service ([2] Q.703, Figures 8 and 9). Timer T2 is used to verify that the remote end responds to the initial attempt to align the link. Timer T3 is used to verify that the remote end is proving the link along with the local end. Both timers T2 Not Aligned and T3 Aligned are implemented in M2UA. Recommended value of T2 is 5-150 seconds. Recommended value of T3 is 1-2 seconds. 3.1.6.2 T4 Proving Period Since M2UA directs the Proving procedure, timer T4 Proving Period is implemented in M2UA as in MTP2. Recommended values are: normal proving period: 7.5-9.5 seconds emergency proving period: 400-600 milliseconds 3.1.6.3 T1 Alignment Ready In MTP2, timer T1 is started when alignment is complete. If T1 expires before an MSU or FISU is received, MTP2 LSC reports to MTP3 that the link is out of service ([2] Q.703, Figure 8). M2UA does not send FISUs. The purpose of FISUs is served by the Heartbeats in SCTP. SCTP uses the Heartbeats to determine if communication has been lost on the connection. M2UA does not need to verify that the link is in service. Therefore it is not necessary to implement timer T1 in M2UA. 3.1.6.4 T5 Sending SIB Since SCTP provides congestion control, it is not necessary to implement timer T5 in M2UA. 3.1.6.5 T6 Remote Congestion MTP2 uses T6 to determine if a link has been congested so long that it should be failed. Since SCTP determines when an association has failed, it is not necessary to implement timer T6 in M2UA. 3.1.6.6 T7 Excessive Delay of Acknowledgement SCTP performs acknowledgements and retransmissions. Therefore it is not necessary to implement timer T7 in M2UA. George, et al [Page 12] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 3.2 Procedures to Support the MTP3/MTP2 Interface 3.2.1 Sending/receiving messages If MTP3 sends a message for transmission to M2UA, M2UA adds the M2UA header to the message, then passes the message to SCTP using the SEND primitive. If M2UA receives a Data message from SCTP, M2UA removes the M2UA header and passes the message to MTP3. 3.2.2 Link activation and restoration If MTP3 requests that M2UA activate or restore a link by a Start command, M2UA shall follow the alignment procedure in section 3.1.2. 3.2.3 Link deactivation If MTP3 requests that M2UA deactivate a link by a Stop command, M2UA shall send a TERMINATE primitive to SCTP. 3.2.4 Flush buffers The Flush Buffers request from MTP3 is not supported by SCTP. 3.2.5 Changeover The objective of the changeover is to ensure that signaling traffic carried by the unavailable signaling link is diverted to the alternative signaling link as quickly as possible while avoiding message loss, duplication, or mis-sequencing. For this purpose, the changeover procedure includes data retrieval, which is performed before reopening the alternative signaling links to the diverted traffic. Data retrieval consists of identifying all those messages in the retransmission buffer of the unavailable signaling link which have not been received by the far end. Retrieval includes transferring the concerned messages to the transmission buffers of the alternative links. In order to support changeover in M2UA, the SCTP Stream Sequence Numbers must be used in place of the Forward and Backward Sequence Numbers (FSN/BSN) of SS7. Stream Sequence Numbers used by SCTP are 16 bits long. MTP2's Forward and Backward Sequence Numbers are only seven bits long. Hence it is necessary to modify MTP3 to accomodate the larger SSNs. Reference [7] section 9.8.1 should be used as a guide for the MTP3 changes. Only the Extended Changeover Order and Extended Changeover Acknowledgement messages from [7] are used. These messages have a 24-bit field for the sequence number. The upper 8 bits of the 24 bit field should be set to 0, and the SSN placed in the lower 16 bits. George, et al [Page 13] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 For data retrieval, MTP3 requests Backward Sequence Number (BSN) from M2UA. This is the sequence number of the last message received by the local end. During normal period, SCTP delivers ordered messages to the application. However, during congestion or failure condition, the sequence numbers of the acknowledged messages can have gaps. In particular, the SACK (selective acknowledgement message) message can have several of these gaps. Hence, it is important to scan through these gaps and find the sequence number before first gap. This is the number from which the remote end has to transmit the messages. So this is the number considered as the Backward Sequence Number and communicated to the remote end. In a similar way, the remote end also detects the BSN and indicates to the local end. As soon as the MTP3 of the local end receives this BSN, MTP3 retrieves all the unacknowledged messages starting from BSN. This is accomplished through a Retrieve FSN request. After all the messages are sent from M2UA to MTP3, a Retrieval Complete indication is sent. Note that the sequence numbers and messages requested by MTP3 are sent from SCTP to M2UA in the Communication Lost primitive. Retrieval of messages is an optional feature in SCTP. To perform data retrieval, it is necessary that this option be implemented, and that the SSNs of the messages are identified. 4. Examples of MTP2 User Adaptation (M2UA) Procedures In general, messages passed between MTP3 and M2UA are the same as those passed between MTP3 and MTP2. M2UA interprets messages from MTP3 and sends the appropriate message to SCTP. Likewise, messages from SCTP are used to generate a meaningful message to MTP3. Note that throughout this section, the primitives between MTP3 and M2UA are named using the MTP terminology [1][2]. Communications between M2UA and SCTP are named using SCTP terminology. George, et al [Page 14] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 4.1 Link Initialization (Alignment) An example of the message flow to bring an SS7 link in-service is shown below. Proving is done by both ends of the link. To simplify the diagram, proving is shown on one end only. MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Out of Service <------------ Emergency OR Emergency Ceases ------------> Start ------------> Associate ------------> (SCTP Association procedure) Communication Up Communication Up <------------ ------------> Even though the SCTP association is established, it is important that M2UA not send MTP3 data at this point. It must be confirmed that both ends of the link are ready for traffic. Otherwise, messages could be lost. Therefore proving begins at this time: George, et al [Page 15] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Link Status SIO ------------------------------------> Link Status SIN <------------------------------------ Link Status SIN ------------------------------------> Link Status SIN <------------------------------------ Link Status SIN ------------------------------------> ------------------------------------> ------------------------------------> : ------------------------------------> Link Status SIN messages are sent for M seconds (see Note A). Status ------------> Indication (Link In Service) <------------ Note A: Timer value M is implementation-dependent. At this point, MTP3 may begin sending data messages. George, et al [Page 16] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 4.2 Message Transmission and Reception Messages are transmitted using the Data Request primitive from MTP3 to M2UA. The diagram shows the case where the Link is In Service. The message is passed from MTP3 of the source to MTP3 of the destination. MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Message for transmission ------------> Send (Data Message) ------------> (SCTP sends message) Receive ------------> Received message ------------> 4.3 Link Status Indication If SCTP sends a Communication Lost primitive to M2UA, M2UA notifies MTP3 that the link is out of service. MTP3 responds in its usual way. MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Communication Lost <------------ Link Out of Service <------------ George, et al [Page 17] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 4.4 Link Status Message (Processor Outage) This example shows how M2UA responds to a local processor outage. MTP3 notifies M2UA of the outage by a Request primitive. M2UA sends a Link Status message to its peer. The peer M2UA notifies MTP3 of the outage. MTP3 can then follow the processor outage procedures in [2]. MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Local Processor Outage ------------> Link Status ------------> (SCTP sends message) Receive ------------> Remote Processor Outage ------------> George, et al [Page 18] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 4.5 Congestion Notification to Upper layer MTP3 layer expects notification of the link congestion. For example, this is accomplished by two messages 1) Link Congestion Onset 2) Link Congestion Abated. Congestion is assumed if M2UA layer notices repeated failures to send requests to SCTP (this is implementation dependent and it is assumed that the SEND Failure has an error code "life time expired"). Subsequently M2UA can start polling status of SCTP. If all the messages are successfully transmitted over a period of time (implementation dependent) then it is assumed that the congestion is abated. If the congestion condition should continue, the link will be taken out of service. In this case, it is possible to start the link changeover procedure. The US National version of SS7 has congestion levels. For US National SS7, the Indication primitive for Congestion Onset should report the congestion level. In the example below, M2UA has sent a message to SCTP. MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Implementation dependent indication of congestion <------------ Congestion Onset <------------ Status ------------> Status ------------> : : Status ------------> polled for certain time until congestion ceases - implementation dependent Congestion Abatement <------------ George, et al [Page 19] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 4.6 Link Deactivation The MTP3 can request that a SS7-IP link be taken out-of-service. It uses the Release Request message as shown below. MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Stop ------------> Terminate ------------> (SCTP performs its termination procedure) Communication Lost <------------ Link Out of Service <------------ George, et al [Page 20] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 4.7 Link Changeover In this example, MTP3 performs a changeover because the link went out of service. MTP3 selects a different link for retransmitting the unacknowledged messages. Note that the sequence numbers and messages requested by MTP3 are sent from SCTP to M2UA in the Communication Lost primitive. MTP3 M2UA SCTP SCTP M2UA MTP3 ---- ---- ---- ---- ---- ---- Communication Lost <------------ Link Out of Service <------------ Retrieve BSN ------------> (M2UA locates first gap in received messages) Indicate BSN <------------ XCO (BSN) on another link ------------------------------------------------------------> Retrieve BSN <------------ Indicate BSN ------------> XCA (BSN) <------------------------------------------------------------ Retrieve FSN ------------> (M2UA locates first gap in acknowledgements) Retrieved Message <------------ George, et al [Page 21] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 Retrieved Message <------------ Retrieval Complete <------------ Send messages on another link. 5. Security SCN adaptation layers rely on SCTP to provide security. 6. Acknowledgements The authors would like to thank Ian Rytina and HannsJuergen Schwarzbauer for their valuable comments and suggestions. 7. References [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling System No. 7 (SS7)' [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - Message Transfer Part (MTP)' [3] Bellcore GR-246-CORE 'Bell Communications Research Specification of Signaling System Number 7', Volume 1, December 1995 [4] RFC 2719, Framework Architecture for Signaling Transport, October 1999 [5] Simple Control Transmission Protocol, draft-ietf-sigtran-sctp-07.txt, March 2000 [6] SS7 MTP2-User Adaptation Layer, draft-ietf-sigtran-m2ua-00.txt, March 2000 [7] ITU-T Recommendation Q.2210, 'Message transfer part level 3 functions and messages using the services of ITU-T Recommendation Q.2140' 8. Author's Addresses Tom George Tel: +1-972-519-3168 Alcatel USA EMail: tom.george@usa.alcatel.com 1000 Coit Road Plano, TX 75075 USA George, et al [Page 22] Internet Draft SS7 MTP2-User Peer-to-Peer Adaptation Layer Mar 2000 Ken Morneault Tel: +1-703-484-3323 Cisco Systems Inc. EMail: kmorneau@cisco.com 13615 Dulles Technology Drive Herndon, VA. 20171 USA Malleswar Kalla Tel: +1-973-829-5212 Telcordia Technologies EMail: kalla@research.telcordia.com MCC 1J211R 445 South Street Morristown, NJ 07960 USA Greg Sidebottom Tel: +1-613-763-7305 Nortel Networks EMail: gregside@nortelnetworks.com 3685 Richmond Rd, Nepean, Ontario Canada K2H5B7 Ram Dantu, Ph.D. Tel: +1-972-234-6070 extension 211 IPmobile EMail: rdantu@ipmobile.com 1651 North Glenville, Suite 216 Richardson, TX 75081 USA This Internet Draft expires September 2000. George, et al [Page 23]