Internet Engineering Task Force David Sanchez INTERNET DRAFT Ericsson November 18, 1998 Expires May 18, 1999 Connectionless SCCP over IP Adaptation Layer (CSIP) David Sanchez Version 0.0 draft November 18, 1998 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 CSIP, a protocol architecture that provides the support of TCAP user applications over an IP network. The core part of the CSIP architecture is the specification of the CSIP (Connectionless SCCP over IP) adaptation layer, that provides adaptation between the SCCP layer already defined in [2] and the IP family protocols IP, UDP, TCP and ICMP. UDP is used when SCCP class 0 is used, TCP is used when SCCP class 1 is used. CSIP provides the primitives and parameters to SCCP than MTP, and provides backward compatibility that guarantees the seamless connection between nodes implementing CSIP and classical SS7 nodes by means of a CSIP gateway. The design of CSIP 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. CSIP functionality 4.1 CSIP primitives and parameters 4.1.1. CSIP primitives 4.1.2 CSIP primitive parameters 4.2. Messages in the CSIP architecture 5. Further Studies 6. Acronyms 7. References 8. Author 1. Introduction TCAP is currently used extensively by applications to exchange user sensitive signaling 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. 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, which in the SS7 model correspond to the MTP and SCCP layer. 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 signaling transport for WAN applications. 2. Scope The scope of this document is to describe a protocol architecture that provides the support of TCAP 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 signaling gateway that provides seamless connectivity between the SS7 over IP network and the classical SS7 network. This involves support SCCP class 0 and class 1 services. 3. Network architecture CSIP provides adaptation function between SCCP and the IP family protocols. In the IP network the communications between SS7 node are end to end, which means that no STP functionality is implemented in the IP routers. It also provides mapping of functionality between ICMP and the MTP network functionality. Figure 1 shows the protocol architecture proposed by CSIP. +--------+ | App. | +--------+ | TCAP | +--------+ | SCCP | +--------+ | CSIP | +--------+ | TCP/UDP| +--------+ +--------+ | App. | | IP |----+ +--------+ +--------+ | +-----------------+ | TCAP | | | SCCP | +--------+ | +--------+--------+ | SCCP | | | CSIP | | +--------+ | +--------+ |--------| MTP | | | TCP/UDP| MTP | +--------+ | +--------+ | +----| IP | | | +--------+--------+ +--------+ | | App. | | +--------+ | | TCAP | | +--------+ | | SCCP | | +--------+ | | CSIP | | +--------+ | | TCP/UDP| | +--------+ | | IP |----+ +--------+ Figure 1. Network architecture using CSIP 4. CSIP functionality CSIP performs the functions in order to provide adaptation between SCCP and the network functions provided by the IP network. - Addressing: The network operator assigns a virtual PC to the SS7 over IP node. The Global Title translation function in SCCP is not changed. Then from the SCCP point of view introducing a new SS7 over IP node is the same as introducing an existing SS7 over MTP node (i.e. the virtual PC needs to be introduced in the GT translation function in the SCCP concerned nodes in the network). When the CSIP layer receives a PC (OPC or DPC) or an IP address, it translates to an IP address or PC respectively in order to simulate the PC information towards. - Network control: CSIP uses ICMP to control the IP network. It uses Echo Reply and Destination Unreachable messages from ICMP in order to detect failures in remote SS7 over IP nodes. It also uses Source Quench messages to detect congestion events in the IP transport network. The functionality is provided by the next primitives and parameters. 4.1. CSIP primitives and parameters 4.1.1. CSIP primitives CSIP provides the same 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. +--------------------------+--------------+ | Primitive | Parameter | +==========================+==============+ | CSIP-TRANSFER-Request | OPC | | -Indication | DPC | | | SLS | | | SIO | | | Data | +--------------------------+--------------+ | CSIP-PAUSE-Indication | Affected DPC | +--------------------------+--------------+ | CSIP-RESUME-Indication | Affected DPC | +--------------------------+--------------+ | CSIP-STATUS-Indication | Affected DPC | | | Cause | +--------------------------+--------------+ Figure 2. CSIP primitives and parameters 4.1.1.1 CSIP-TRANSFER-Request This primitive is used by SCCP to request from CSIP the transfer of an SCCP message to a destination node. 4.1.1.2 CSIP-TRANSFER-Indication This primitive is used by CSIP to indicate the reception of an SCCP message from another SCCP node. 4.1.1.3 CSIP-PAUSE-Indication This primitive is used by CSIP to indicate to SCCP the inability of sending any SCCP message to the indicated node. The CSIP layer may generate this indication upon: - Receiving a Destination Unreachable message from ICMP indicating net unreachable or host unreachable. - If the CSIP performs periodic polling to remote SS7 over IP nodes by means of ICMP, CSIP can detect a failure on the remote node if several Echo Reply messages are not answered by the remote host. When CSIP detects a failure in a remote host, it starts a polling routine towards that node in order to detect when the node becomes available again. 4.1.1.4 CSIP-RESUME-Indication This primitive is used by CSIP to indicate to SCCP the availability of sending again SCCP messages to the indicated node. The CSIP layer generates this indication when the remote SS7 over IP node starts to answer again to the echo messages. 4.1.1.5 CSIP-STATUS-Indication This primitive is used by CSIP to indicate to SCCP some special events: - Remote SCCP layer unavailability - Remote SCCP congestion - Completion of IP local layer restart: If the IP transmission layer has been temporarily unavailable due to a failure in the local hardware or software, CSIP detects when it is available again and indicates this to SCCP by means of this primitive. The value of the Affected DPC and Cause parameters are left to the implementation (these values are not specified in [2]), but in case of using an existing SCCP layer, it would be desirable that the values provided by CSIP are the same as the values used by the implementation of the existing SCCP layer. 4.1.2 CSIP primitive parameters 4.1.2.1 OPC (Originating Point Code) The OPC is used to indicate the node that originates the message. The OPC parameter is sent in the next primitives: - CSIP-TRANSFER-Request (SCCP to CSIP): When CSIP receives the OPC, it translates the PC to the local IP address. - CSIP-TRANSFER-Indication (CSIP to SCCP): When CSIP receives an IP packet, it translates the source IP address to the OPC. 4.1.2.2 DPC (Destination Point Code) The DPC is used to indicate the destination node for a message. The DPC parameter is sent in the next primitives: - CSIP-TRANSFER-Request (SCCP to CSIP): When CSIP receives the DPC, it translates the PC to the destination IP address. - CSIP-TRANSFER-Indication (CSIP to SCCP): When CSIP receives an IP packet, it translates the destination IP address to the local PC. - CSIP-PAUSE-Indication (CSIP to SCCP): In this primitive the DPC indicates that this PC is unavailable, and that any message to that PC shall be discarded. - CSIP-RESUME-Indication (CSIP to SCCP): In this primitive the DPC indicates that this PC is again available. - CSIP-STATUS-Indication (CSIP to SCCP):In this primitive the DPC indicates the PC where the reported error applies. 4.1.2.3 SLS (Signaling Link Selection) - CSIP-TRANSFER-Request (SCCP to CSIP): SCCP uses the value of 15 in order to indicate to CSIP that the SCCP message uses the class 1 service. When CSIP receives the SLS, it checks whether the value is equal to 15. If so CSIP uses an existing TCP connection to the destination node. Otherwise CSIP ignores the value of the SLS. It is recommended to use some of the load sharing techniques used by the IP routing protocols. - CSIP-TRANSFER-Indication (CSIP to SCCP): When CSIP receives an IP packet, it checks whether it is a UDP datagram or it comes from a TCP connection. If it is a UDP datagram, CSIP generates a random integer value between 0 and 15 and sends this value to SCCP. If the SCCP message comes from a TCP connection, CSIP uses a preconfigured table that links the source IP addresses (or part of it) to SLS values from the range of 0 to 15. The corresponding SLS value is sent to the SCCP layer. 4.1.2.4 SIO (Service Indication Octet) The SIO consists of: - Service Indicator - Subservice field, which consists on - Network Indicator - Spare bits - CSIP-TRANSFER-Request (SCCP to CSIP): 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. When CSIP receives the SIO: - It maps the Service Indicator to the UDP/TCP port number reserved to SCCP over IP. - It uses the network indicator to derive the IP address corresponding to that PC and network indicator. - It discards the spare bits. - CSIP-TRANSFER-Indication (CSIP to SCCP): When CSIP receives an IP packet, it has to build the SIO to be delivered to SCCP. To do this CSIP: - Maps the UDP/TCP port number to the Service Indicator. - Analyses the IP source address in order to derive the network indicator (and OPC). The part of network indicator in the result of the translation is sent to SCCP. - Sets the spare bits to 00. 4.1.2.5 Data This is the whole SCCP messages to be sent to the remote node. 4.1.2.6 Cause - CSIP-STATUS-Indication (CSIP to SCCP):In this primitive the Cause value indicates the error event reported to the SCCP layer. The next values may be sent: - Signaling network congested: The CSIP-STATUS-Indication primitive is sent with this value when receiving a Source Quench message from ICMP. - User part unavailability, inaccessible remote user: The CSIP-STATUS-Indication primitive is sent with this value when receiving a Destination Unreachable message from ICMP indicating port unreachable and port is the port reserved for SCCP over IP. 4.2. Messages in the CSIP architecture CSIP provides encapsulation of the SCCP message in an IP datagram. If SCCP class 0 is used, CSIP uses UDP to transmit the SCCP message to the destination node. If SCCP class 1 is used, CSIP uses an existing TCP connection to the destination node to transmit the SCCP message. Figure 3 shows that the SCCP messages are encapsulated as a UDP/TCP datagram. +-------------+----------------+---------------------------------+ | IP header | UDP/TCP header | SCCP message | +-------------+----------------+---------------------------------+ Figure 3. CSIP encapsulation 5. Further Studies The further studies for following issues are needed: - Provision of changeover and changeback MTP procedures in IP networks. - Provision of forced rerouting and controlled rerouting MTP procedures in IP networks. - Provision of enhanced error reporting procedures in IP networks. - Provision of link supervision procedures in IP networks. 6. Acronyms GT - Global Title GTT - Global Title Translation ICMP - Internet Control Message Protocol IP - Internet Protocol MTP - Message Transfer Part PC - Point Code SCCP - Signaling Connection Control Part SS7 - Signaling System No. 7 TCP - Transport Control Protocol TIP - TCAP over IP adaptation protocol UDP - User Datagram Protocol WAN - Wide Area Network 7. References [1] ANSI T1.114-1992, "Signaling System No. 7 (SS7) - Transaction Capabilities Application Part (TCAP)" [2] ANSI T1.112-1992, "Signaling System No. 7 (SS7) - Signaling Connection Control Part (SCCP)" [3] Postel, J.B. 1980, "Transmission Control Protocol", RFC 793 [4] Postel, J.B. 1980, "User Datagram Protocol", RFC 768 [5] Postel, J.B. 1981, "Internet Control Message Protocol" RFC 792 [6] Stevens, W.R. 1994, "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley Publication Company 8. Author David Sanchez Ericsson Retama 1 Madrid, Spain 28045 Tel: +34 91-339-3027 Email: emedasa@madrid.ericsson.se