Internet Engineering Task Force David Sanchez INTERNET DRAFT Ericsson January 15, 1999 Miguel A. Garcia Expires July 15, 1999 Ericsson A Simple SCCP Tunneling Protocol (SSTP) David Sanchez Miguel A. Garcia Version 1.0 draft January 14, 1999 Status of this document This document is an Internet-Draft. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast) Abstract This document describes SSTP (Simple SCCP Tunneling Protocol), a protocol architecture that provides the support of SCCP and TCAP user applications over an IP network. The purpose of SSTP is to provide a standard tunneling protocol to convey SCCP messages over an IP based network. Address mapping from PSTN signalling to IP is not in the scope of this draft. Therefore SSTP only deals with IP addresses. TCP or UDP is used for SCCP class 0 messages. TCP is used for SCCP class 1, 2 or 3. SSTP provides seamless connection between nodes implementing SSTP and classical SS7 nodes by means of an SSTP gateway. The design of SSTP is oriented to fulfill the requirements of TCAP user applications running on a WAN. Table of Contents 1. Introduction 2. Scope 3. Network architecture 4. SSTP functionality 4.1. SSTP primitives and parameters 4.1.1. SSTP primitives 4.1.2. SSTP primitive parameters 4.2. Messages in the SSTP architecture 5. Procedures 5.1. Start/Restart 5.2. Supervision 5.3 Network configuration errors 6. Further Studies 7. Acronyms 8. References 9. Authors 1. Introduction TCAP is currently used extensively by applications to exchange user sensitive signalling information via the reliable SS7 network. TCAP only uses the connectionless service of SCCP. To mention some examples of applications we found INAP (Intelligent Network Application Part) in IN systems, MAP (Mobile Application Part) in GSM or IS-41 in AMPS systems. The applications on top of TCAP take advantage of the international support of SS7 system in many countries. The layer that acts as a glue by providing addressing capabilities over different SS7 networks is SCCP. There are some applications that do not use TCAP, but SCCP instead. For instance, the BSSAP (Base Station System Application Protocol). IP is a widely used transport protocol, with a big range of products available. Comparing with the OSI model, IP/UDP/TCP covers network functions up to the layer 4. in the SS7 model, the MTP and the SCCP layers conform up to the level 3. Therefore interactions between these two systems focus on that level of the protocol stack. The SCCP addressing functionality is needed to provide interconnection to existing SS7 networks. It also provides network management features to control the resources of the SS7 network(s) such congestion control or TCAP user unavailability indications. Both SCCP addressing and SCCP management functions are considered to be essential for a solution that provides SS7 over IP signalling transport for WAN applications. 2. Scope The scope of this document is to describe a protocol architecture that provides the support of TCAP and SCCP user applications over an IP network. The network would be typically a WAN, were some network parameters like traffic load, congestion, availability or network failures cannot be controlled as in a LAN. This document describes the adaptation functionality of the signalling gateway that provides seamless connectivity between the SS7 over IP network and the classical SS7 network. This involves support SCCP class 0, 1, 2 and 3 services. To easy the modelling of the protocol and to facilitate alignment with the modelling principles of ITU, this draft uses primitives to define the interactions between SSTP and SCCP. Nevertheless implementations are not required to fulfill the set of primitives described here. SCCP uses GTs and PCs to address other SS7 nodes, while IP uses IP addresses. Although there is a need for mapping between SCCP and IP addresses, it is outside the scope of this draft to solve the mapping. Therefore SSTP only deals with IP addresses. SSTP does not deal with segmentation of SCCP messages. In order to take advantage of the long message capabilities of the IP network (compared to narrow-band MTP3 which has a maximum length of 272 octets), it is recommended to use of the LUDT messages as described in reference [2]. LUDT messages supports a maximum length of 3952 octets. 3. Network architecture SSTP provides adaptation function between SCCP and the IP family protocols. In the IP network the communications between SS7 nodes are end to end, which means that no Signalling Point Relay functionality is implemented in the IP routers. It also provides mapping of functionality between ICMP and the SCCP management functionality. Figure 1 shows the protocol architecture proposed by SSTP. +------+------+ | | APP. | | APP. |------+ | | TCAP | +------+------+ | SCCP | +-------------+ | SSTP | +-------------+ | TCP/UDP | +--------+ +-------------+ | APP. | | IP |----+ +--------+ +-------------+ | +-----------------+ | TCAP | | | SCCP | +--------+ | +--------+--------+ | SCCP | | | SSTP | | +--------+ | +--------+ |--------| MTP | | | TCP/UDP| MTP | +--------+ | +--------+ | +----| IP | | | +--------+--------+ +------+------+ | | | APP. | | | APP. |------+ | | | TCAP | | +------+------+ | | SCCP | | +-------------+ | | SSTP | | +-------------+ | | TCP/UDP | | +-------------+ | | IP |----+ +-------------+ Figure 1. Network architecture using SSTP 4. SSTP functionality SSTP performs the functions in order to provide adaptation between SCCP and the network functions provided by the IP network. Among others, SSTP provides the following functionality: - Peer to peer: SSTP establishes a peer to peer communication channel between two SCCP over IP nodes. SSTP nodes are listening to the SCCP over IP port. - Encapsulation of SS7 messages: SSTP provides a standard way to encapsulate SCCP messages into IP packets, so that interworking between different vendors is guaranteed. - Use of transport protocols: SSTP uses both TCP and UDP as transport protocols on top of IP. UDP is used for SCCP class 0 messages (unsequenced). TCP is used for SCCP classes 1, 2 and 3. TCP can be used for class 0 as well. - Connection supervision: An SSTP node monitors the communication channel previously established with other SSTP nodes. - Start/restart: SSTP provides automatic restablishment of the communication channel with other SSTP nodes upon a start/restart. - Network control: SSTP uses ICMP to control the IP network. It uses Echo/Echo Reply and Destination Unreachable messages from ICMP in order to detect failures in remote SS7 over IP nodes. SSTP informs SCCP about failures in the network. The functionality is provided by the next primitives and parameters. 4.1. SSTP primitives and parameters 4.1.1. SSTP primitives SSTP provides a very similar interface towards SCCP as MTP does. This is in order to provide the information needed by SCCP in order to perform the required functionality. The primitives and the parameters associated to them are shown in figure 2. The Request primitives flow from SCCP to SSTP, whilst the Indication primitives flow from SSTP to SCCP. +-----------------------------+------------------------+ | Primitive | Parameter | +=============================+========================+ | SSTP-TRANSFER-Request | Destination IP address | | | Destination IP port | | | Protocol Class | | | SLS | | | SIO | | | Data | +-----------------------------+------------------------+ | SSTP-TRANSFER-Indication | Source IP address | | | Source IP port | | | SLS | | | SIO | | | Data | +-----------------------------+------------------------+ | SSTP-NOTICE-Indication | Source IP address | | | Source IP port | | | Error Code | | | SLS | | | SIO | | | Data | +-----------------------------+------------------------+ | SSTP-PAUSE-Indication | Affected IP address | +-----------------------------+------------------------+ | SSTP-RESUME-Indication | Affected IP address | +-----------------------------+------------------------+ | SSTP-STATUS-Indication | Affected IP address | | | Error Code | +-----------------------------+------------------------+ Figure 2. SSTP primitives and parameters 4.1.1.1 SSTP-TRANSFER-Request This primitive is used by SCCP to request from SSTP the transfer of an SCCP message to a destination node. 4.1.1.2 SSTP-TRANSFER-Indication This primitive is used by SSTP to indicate the reception of an SCCP message from another SCCP node. 4.1.1.3 SSTP-NOTICE-Indication This primitive is used by SSTP to indicate an error reported when a message was sent through the IP network. Thus, this primitive is issued as an error answer to a previous SSTP-TRANSFER-Request. Delivery errors occur upon connection broken, node failure, IP network configuration errors or similar situations. These type of errors are reported to SSTP in the ICMP Destination Unreachable message. SSTP issues then this primitive when receiving ICMP Destination Unreachable message with the error reported by the IP network encoded in the Error Code parameter with the values specified in Figure 4. The SLS and SIO are the same parameters sent in a previous SSTP-TRANSFER-Request primitive. However, the Data parameter may contain a partial copy (not a complete one) of the Data sent in the SSTP-TRANSFER-Request primitive. The SCCP is responsible to take the proper actions (i.e. in the SS7 signalling gateway generate a return message or in the end SSTP node generate an N-NOTICE-Indication primitive) upon the reception of this primitive. The Source IP address and Source IP port are those where the error message was generated. 4.1.1.4 SSTP-PAUSE-Indication This primitive is used by SSTP to indicate to SCCP the inability of sending any SCCP message to the indicated node. The SSTP layer generates as a result of remote host errors detected by the SSTP supervision mechanisms as explained in section 5.2. 4.1.1.5 SSTP-RESUME-Indication This primitive is used by SSTP to indicate to SCCP the availability of sending again SCCP messages to the indicated node. The SSTP layer generates this indication when the remote SCCP over IP node starts to answer again to the ICMP Echo messages as explained in section 5.2. Once the local SSTP reports that the remote IP & ICMP layers are working again, it is the responsibility of SCCP to check the availability of the peer SCCP layer. The primitive is also issued when the local IP layer restart is completed. If the IP transmission layer has been temporarily unavailable due to a failure in the local hardware or software, SSTP detects when it is available again and indicates this to SCCP by means of this primitive. The value of the Affected IP address and Cause parameters are left to the implementation (these values are not specified in [3]), but in case of using an existing SCCP layer, it would be desirable that the values provided by SSTP are the same as the values used by the implementation of the existing SCCP layer. 4.1.1.6 SSTP-STATUS-Indication This primitive is used by SSTP to indicate to SCCP some special events: - Remote SCCP layer unavailability: If the remote SSTP layer receives a message for SCCP, but SCCP is not working or attached to the remote SSTP, then the remote SSTP generates an ICMP Destination Unreachable message back, with the code set to value 12 (host unreachable for this type of service). The local SSTP receiving such an ICMP message reports the error to the local SCCP by means of this primitive. - Remote SCCP congestion 4.1.2 SSTP primitive parameters 4.1.2.1 Source IP address The Source IP address is used to indicate the node that originates the message. This parameter is sent in the primitives: - SSTP-TRANSFER-Indication - SSTP-NOTICE-Indication 4.1.2.2 Source IP port The Source IP port is used to indicate to SCCP the port that originates the message. This parameter is sent in the primitives: - SSTP-TRANSFER-Indication - SSTP-NOTICE-Indication 4.1.2.3 Destination IP address The Destination IP address is used to indicate the destination node for a message or TCP connection. This parameter is sent in the primitives: - SSTP-TRANSFER-Request 4.1.2.4 Affected IP address The affected IP address is used to indicate the node affected by some abnormal event. This parameter is sent in the following primitives: - SSTP-PAUSE-Indication (SSTP to SCCP): The affected IP address indicates the unavailability of the node SCCP over IP node, and that, SCCP must not send any message to that node through the SSTP layer. - SSTP-RESUME-Indication (SSTP to SCCP): The affected IP address indicates the availability of a previously unavailable SCCP over IP node. SCCP can resume to send messages to that node through the SSTP layer. - SSTP-STATUS-Indication (SSTP to SCCP): The affected IP address indicates the IP node where the reported error applies. 4.1.2.5 Destination IP port The Destination IP port is used to indicate the SSTP application in the destination node. The port number reserved for SCCP over IP is 14001. The Destination IP Port parameter is sent in the primitive: - SSTP-TRANSFER-Request 4.1.2.6 Protocol Class SSTP uses the value of Protocol Class received from SCCP to decide the layer where the message is sent (UDP or TCP). If class 0 is used, then SSTP may use either TCP or UDP as transport protocol (this is implementation dependant). If class 1, 2 or 3 is used, then SSTP shall use TCP as transport protocol. The Protocol Class parameter is sent in the primitive: - SSTP-TRANSFER-Request 4.1.2.7 SLS (Signalling Link Selection) The Signalling Link Selection is encapsulated into the SLS octet and transparently transmitted over the IP network. The SLS octet contains 4 spare bits and the actual SLS value: +------+------+ | DCBA | DCBA | +------+------+ |Spare | SLS | +------+------+-----> First bit transmitted Figure 3. SLS octect The SLS octet is sent in the following primitives: - SSTP-TRANSFER-Request - SSTP-TRANSFER-Indication - SSTP-NOTICE-Indication 4.1.2.8 SIO (Service Indication Octet) The SIO consists of: - Service Indicator - Subservice field, which consists on - Network Indicator - Spare bits (or message priority) The SIO is sent in the following primitives: - SSTP-TRANSFER-Request - SSTP-TRANSFER-Indication - SSTP-NOTICE-Indication SCCP uses the SIO to indicate the MTP user (Service Indicator which in this case will indicate SCCP) and network indicator. The SIO also contains two spare bits, used for the message priority in the United States networks. The SIO is transparently transmitted over the IP network. 4.1.2.9 Data This is the SCCP message to be sent to the remote node. The message is composed of: 1) Message type code 2) Mandatory fixed part 3) Mandatory variable part 4) Optional variable part These fields are described in reference [2] and in chapter 3 in reference [4]. The Data is sent in the following primitives: - SSTP-TRANSFER-Request - SSTP-TRANSFER-Indication - SSTP-NOTICE-Indication 4.1.2.10 Error code This parameter carries the error code generated by the IP network when a message was not properly delivered. This parameter is used in the primitives: - SSTP-NOTICE-Indication - SSTP-STATUS-Indication In most cases the primitive that includes the Error Code parameter is sent as result of an ICMP Destination unreachable message. The values of Error Code and its mapping to the ICMP Destination unreachable code is described in the following table: +-----------------+--------+---------------------+------+-----------+ | Error Code | Err. C.| ICMP Destination | ICMP | Primitive | | | value | unreachable code | value| | +=================+========+=====================+======+===========+ | Network failure | 0 | Network unreachable | 0 |Notice-Ind | +-----------------+--------+---------------------+------+-----------+ | Host failure | 1 | Host unreachable | 1 |Notice-Ind | +-----------------+--------+---------------------+------+-----------+ | IP SW failure | 2 | Protocol unreachable| 2 |Notice-Ind | +-----------------+--------+---------------------+------+-----------+ | SSTP failure | 3 | Port unreachable | 3 |Notice-Ind | +-----------------+--------+---------------------+------+-----------+ | Unqualified | 4 | Fragmentation needed| 4 |Notice-Ind | +-----------------+--------+---------------------+------+-----------+ | Unqualified | 4 | Source route failed | 5 |Notice-Ind | +-----------------+--------+---------------------+------+-----------+ | IP network | 5 | Destination network | | | | address error | | unknown | 6 |Notice-Ind | +-----------------+--------+---------------------+------+-----------+ | IP host address | 6 | Destination network | | | | error | | unknown | 7 |Notice-Ind | +-----------------+--------+---------------------+------+-----------+ | Config. error | 7 | Source host isolated| 8 |Notice-Ind | +-----------------+--------+---------------------+------+-----------+ | | | Communication with | | | | | | destination network| | | | Administrative | | administratively | | | | network barring| 8 | prohibited | 9 |Notice-Ind | +-----------------+--------+---------------------+------+-----------+ | | | Communication with | | | | | | destination network| | | | Administrative | | administratively | | | | host barring | 9 | prohibited | 10 |Notice-Ind | +-----------------+--------+---------------------+------+-----------+ | Remote SCCP net | | Network unreachable | | | | unavailable | 10 | for type of service| 11 |Notice-Ind | +-----------------+--------+---------------------+------+-----------+ | Remote SCCP host| | Host unreachable | |Status-Ind | | unavaliable | 11 | for type of service| 12 |Notice-Ind | +-----------------+--------+---------------------+------+-----------+ | Network | | | | | | congestion | 12 | | |Notice-Ind | +=================+========+=====================+======+===========+ Figure 4. Mapping of Destination Unreachable codes to Error Codes 4.2. Messages in the SSTP architecture SSTP provides encapsulation of the SCCP message in an IP datagram. If SCCP class 0 is used, SSTP uses UDP or TCP to transmit the SCCP message to the destination node. If SCCP class 1, 2 or 3 is used, SSTP uses an existing TCP connection to the destination node to transmit the SCCP message. Figure 5 shows that the SCCP messages are encapsulated as a UDP/TCP datagram. +-------------+----------------+---+---+-------------------------+ | IP header | UDP/TCP header |SIO|SLS| SCCP message | +-------------+----------------+---+---+-------------------------+ Figure 5. SSTP encapsulation 5. Procedures 5.1 Start/Restart Whenever a node is started up or restarted, the server process is launched. The server process is accepting TCP connections or UDP packets and it is listening to the SCCP over IP reserved port number, 14001. If a new TCP connection or UDP packet is received by the SSTP layer, SSTP issues asynchronously the primitive SSTP-RESUME-Indication to SCCP and aborts any ongoing supervision process to the remote node that originated the message. Once SSTP is listening to the reserved port, it starts in paralel a supervision process with all the remote SSTP nodes defined. If the remote SSTP node has defined no TCP connection to be established (only UDP will be used), when the supervision process detects that the remote SSTP node is available, SSTP issues the primitive SSTP-RESUME-Indication to SCCP. If SSTP has to establish a TCP connection with the remote SSTP node, when the supervision process detects that the remote SSTP node is available, SSTP requests a TCP connection to the SSTP node. When the connection is established, SSTP issues the primitive SSTP-RESUME-Indication to SCCP. 5.2 Supervision SSTP performs monitoring of the communications with other SSTP nodes. This implies supervision of TCP connections (if class 0, 1, 2 or 3 is supported) and supervision of the status of remote hosts (if class 0 with support of UDP is used). This supervision is performed using the services of ICMP Echo and Echo Reply messages. The supervision procedure consists on the periodic polling of remote hosts by sending ICMP Echo messages. The periodicity T1 of the polling is not specified. Each TCP connection is supervised by SSTP. In case no messages are sent for a certain period of time, ICMP Echo is sent to the remote node, waiting to receive an Echo Reply message. If the Echo Reply message is not received within a specific period of time T2, SSTP considers that the TCP connection is broken. SSTP starts then the supervision process is started. SSTP also uses the supervision process upon start/restart (see section 5.1), to check that all remote nodes are available before UDP messages are sent or TCP connections are established. SSTP may also use the supervision process to monitor the status of remote SSTP nodes that have no TCP connection established with the local SSTP. The supervision process is also started by SSTP upon reception of an ICMP Destination Unreachable message from ICMP indicating net unreachable or host unreachable. If a number of Echo Reply message is not received within a specific period of time T3, the communication is supposed to be broken, and this is indicated to SCCP by means of the primitive SSTP-PAUSE- Indication. The supervision process continues until an ICMP Echo Reply message is received from the remote host. The recovery of the remote host is indicated to SCCP by means of the primitive SSTP-RESUME-Indication. In supervision process may also be aborted (see section 5.1) in which case no primitive is sent to SCCP. 5.3 Network configuration errors Errors on local or remote configurations of the IP network are reported to SSTP by means of ICMP messages. Besides the standard procedures of error reporting to SCCP explained above, the network administrator shall be informed upon reception the ICMP messages that report configuration failures in order to take actions to solve the problem. 6. Further Studies The further studies for following issues are needed: - Provision of automatic rerouting upon IP network failure. - Provision of forced rerouting and controlled rerouting in IP networks. - Provision of enhanced error reporting procedures in IP networks. - Study the introduction of enhanced routing algorithms like OSPF. - Congestion control mechanism. - Provision of remote SSTP monitoring mechanism. 7. Acronyms AMPS - Advanced Mobile Telephone Service BSSAP - Base Station System Application Part GSM - Global System for Mobile Communication GT - Global Title ICMP - Internet Control Message Protocol IN - Intelligent Network INAP - Intelligent Network Application Part IP - Internet Protocol LAN - Local Area Network MAP - Mobile application Part MTP - Message Transfer Part OSPF - Open Shortest Path First PC - Point Code SCCP - Signalling Connection Control Part SS7 - Signalling System No. 7 SSTP - Simple SCCP Tunneling Protocol TCAP - Transaction Capabilities Application Part UDP - User Datagram Protocol WAN - Wide Area Network 8. References [1] ITU-T Recommendation Q.711: "Functional Description of the Signalling Connection Control Part" [2] ITU-T Recommendation Q.713: "Signalling Connection Control Part formats and codes" [3] ITU-T Recommendation Q.714: "Signalling Connection Control Part procedures" [4] ANSI T1.112-1996 "Signalling System Number 7 - Signalling Connection Control Part (SCCP)" [5] Postel, J.B. 1980, "Transmission Control Protocol", RFC 793 [6] Postel, J.B. 1980, "User Datagram Protocol", RFC 768 [7] Postel, J.B. 1981, "Internet Control Message Protocol" RFC 792 [8] Branden, R. 1989, "Requirements for Internet Hosts -- Communication Layers" RFC 1122 9. Authors David Sanchez Miguel A. Garcia Ericsson Ericsson Retama 1 Retama 7 Madrid, Spain 28045 Madrid, Spain 28045 Tel: +34 91 339 3027 Tel: +34 91 339 2985 Email: emedasa@madrid.ericsson.se Email: Miguel.A.Garcia@ericsson.com