Internet Engineering Task Force Monling Liao INTERNET DRAFT Liem Le draft-liao-stiff-00.txt Rambabu Tummula March 1999 Emad Qaddoura Expires: September 1999 Don Wurch Nortel Networks Simple SS7-TCAP/IP Protocol (STIPP) <draft-liao-stiff-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. 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. Abstract This draft addresses the interworking between SS7 Transaction Capabilities Application Part (TCAP) and the Internet Protocol (IP). It describes the operations and functions of the TCAP-IP Gateway (TIPG) and the protocols between the TIPG and an IP entity to provide the TCAP-IP interworking functions between applications in PSTN/IN/Wireless & IP domains. Note Some aspects of this contribution are the subject of a provisional patent application by Nortel Networks. The contributors hereby represent that they are not personally aware of any other proprietary or intellectual property rights in this contribution. <draft-liao-stiff-00.txt> [Page 2]
Table of Contents 1.0 OVERVIEW 1.1 Functions of the TCAP-IP Gateway (TIPG) 1.1.1 SCCP Flow Control 1.1.2 Encapsulation/Decapsulation 1.1.3 Address Translation 1.1.4 Global Title Translation 1.1.5 Protocol Discrimination 1.1.6 Security 1.1.7 Mediation 1.2 Functions of the IP Entity 2.0 SIMPLE TCAP-IP PROTOCOL (STIPP) 2.1 Communication between the TIPG and the IP entity 2.2 STIP Header 2.2.1 Attribute Format 2.2.2 Protocol Messages 3.0 SYSTEM REDUNDANCY 4.0 SCENARIOS 4.1 Login Scenario 4.2 Unidirectional TCAP Message 4.2.1 SS7-Generated Unidirectional TCAP Message 4.2.2 IP Entity-generated Unidirectional TCAP Message 4.3 Simple Query/Response TCAP Messages 4.3.1 SS7-Initiated Transaction 4.3.2 IP Entity-Initiated Transaction 4.4 Erroneous TCAP Message 4.4.1 SS7-Generated Erroneous TCAP Message 4.4.2 IP Entity-Generated Erroneous TCAP Message 5.0 SECURITY 6.0 REFERENCES AND RELATED WORK 7.0 AUTHORS 1.0 Overview This document describes the operations and protocol to provide the TCAP- IP interworking functions [1]. This paper addresses the connectionless services of the Signaling Connection Control Part (SCCP)layer and a proposed convergence layer - Simple TCAP/IP Interworking Part (STIP) between TCAP and IP layer. The following diagram shows the use of the TIPG and the Simple TCAP-IP Protocol (STIPP) for the interworking of SS7-TCAP and IP. <draft-liao-stiff-00.txt> [Page 3]
PSTN IP Network +-----+ +---+ |IP | |SCP| |Entity +---+\ / +-----+ \ +---+ +----+ STIPP/ . \---|STP|------SS7-------|TIPG| ----/ . --- +---+ +----+ ---- . / TCAP/IP \ +-----+ +---+/ Interworking \ |IP | |SP | Function \ |Entity +---+ +-----+ Figure 1: TCAP/IP Interworking Reference Architecture 1.1 STIP Functions of the TCAP-IP Gateway (TIPG) The TCAP/IP Gateway (TIPG) provides an interface between the SS7 network and IP network. The TIPG has two basic hardware interfaces. The SS7 interface supports the SS7 protocols including SCCP and TCAP to connect to the SS7 network. The IP interface supports IP protocols to connect to the IP network. The TIPG communicates with each IP Entity via STIPP protocol as described in section 2. 1.1.1 SCCP Flow Control There are four SCCP messages that are used in the SCCP connectionless services: Unitdata (UDT), Extended Unitdata (XUDT), Unitdata Service (UDTS), and Extended Unitdata Service (XUDTS). The UDT message is normally used to transmit TCAP message. The XUDT message is used if the TCAP message is too big to fit into the SCCP message. When the TIPG receives an UDT or XUDT message but the destination IP Entity for this message is not properly functional, it must send back the UDTS of XUDTS to the message originator to indicated a congested or failed of the IP Entity. 1.1.2 Encapsulation/Decapsulation The TIPG must provide the encapsulation/decapsulation functions at both directions from the SS7 network to the IP network and vice versa. I. SS7 network originates a TCAP message into the IP network: +-----+-----+-----+ +----+ +----+-----+-----+ | MTP |SCCP | TCAP|-----------> |TCAP|-------------> | IP |STIP |TCAP | +-----+-----+-----+Decapsulation+----+ Encapsulation +----+-----+-----+ Figure 2: TCAP messaging from SS7 network to IP network <draft-liao-stiff-00.txt> [Page 4]
The SS7 message is decapsulated to remove the MTP and SCCP headers. The remaining TCAP message is encapsulated with the IP header and the STIP header, which contains the required information from the MTP and SCCP headers. The STIP header will be defined in section 2. II. IP network originates a TCAP message into the SS7 network: +----+-----+-----+ +----+ +-----+-----+-----+ | IP | STIP| TCAP|-----------> |TCAP|------------> | MTP | SCCP|TCAP | +----+-----+-----+Decapsulation+----+Encapsulation +-----+-----+-----+ Figure 3: TCAP messaging from IP network to SS7 network The IP message is decapsulated to remove the STIP header and the IP header. The remaining TCAP message is encapsulated with the MTP and SCCP headers with the required information from the STIP header. The STIP header will be defined in section 2. III. IP network transport a TCAP message between two SS7 networks: The TCAP message is originated from one SS7 network and is terminated to a far-end SS7 network. The IP network only provides signaling transport functions. Each TIPG in the edge of IP network performs the encapsulation/decapsulation functions to convert a TCAP/SS7 message to a TCAP/IP message and also a TCAP/IP message to a TCAP/SS7 message as described above. 1.1.3 Address Translation The TIPG must provide the address translation between the Point Code (PC)/Subsystem Number (SSN) and the IP address. On the SS7 side, the SS7 network addresses each IP entity by a PC and a SSN. The point code is identical for some of IP entities but the SSN must be different to correctly address each of the IP entity. On the IP side, each IP entity as well as the TIPG is pre-assigned with a unique IP address. Each IP entity should be pre-configured with the IP address of the TIPG. The TIPG should maintain the mapping between the PC and/or SSN and the IP address of the IP entity. 1.1.4 Global Title Translation (GTT) Global Title (GT) Address in SS7 network refers E.164 or E.214 Mobile number. The GTT function performed by SCCP is to translate GT to find a destination node in SS7 network. Since TIPG is acting as a transit signaling point to IP entities, the GTT function may be required and extended in TIPG. Possible GTT outcomes: - a destination node in SS7 network - DPC (+SSN or +GT) - a destination node in IP network - IP address + port number 1.1.5 Protocol Discrimination <draft-liao-stiff-00.txt> [Page 5]
The TIPG must provide the protocol discrimination function for all messages received from the SS7 network. A TCAP message received from SS7 network can be defined by several standards. It can be defined by the TCAP standard such as Charging, Provide Instruction, Connection Control, Network Management, etc. On the other hand, it can be defined by the upper-layer protocols such as IS-41, MAP, OMAP, etc. The messages received from the SS7 network are the TCAP messages with the Invoke Component. These messages can be discriminated by the Operational Code Identifier and the Operational Family of the Operation Code. For example, the IS-41 invoke messages have the Operational Code Identifier of Private TCAP and the Operational Family of 9. Other TCAP messages (with Return Result, Return Error, and Reject Component) are sent into the SS7 network and do not require the protocol discrimination. For these messages, the TIPG maps the source IP address of the IP packet to the corresponding SS7 PC/SSN and sends to the SS7 network. 1.1.6 Security The TIPG must provide the security for the SS7 network. The TIPG must provide the authentication of the IP entity wishing to communicate with the SS7 network. Each IP entity except other TIPG's, before allowing sending or receiving TCAP messages, must log on to the TIPG. The TIPG then sends the CHAP [4] Challenge Request to the IP Entity. If the IP Entity does not response within TBD seconds, the TIPG will delete the entry of the IP Entity from its internal table and discard any packets from that IP Entity. If the IP Entity responds with an invalid Challenge Response, the TIPG will send the Challenge Failure to the IP Entity, delete the entry of the IP Entity from its internal table, and discard any packets from that IP entity. If the IP Entity responds with a valid Challenge Response, the TIPG will send the Challenge Success to the IP Entity and allow the transferring of the TCAP messages to/from that IP Entity. Any TCAP messages receiving before the TIPG completes its CHAP authentication process will be discarded. The CHAP authentication process only authenticates the IP Entities, it does not guarantee the security of the data/messages being transferred. To provide the security of the data TIPG may implement the IP Authentication Header (AH) and/or IP Encapsulating Security Payload (ESP) to put more security on the accessing of the SS7 network. An IP Entity may optionally include the Identification attribute in its Login message to indicate to the TIPG that it wants to include the Identification attribute in the subsequent messages except the CHAP messages. The Identification attribute, along with the AH and/or ESP, will be useful to protect against replay attack. 1.1.7 Mediation The TIPG may provide mediation as a safeguard to allow SS7 network access to IP entities. Safeguards may be necessary to keep one service provider's information from being accessed and/or modified by other service providers. <draft-liao-stiff-00.txt> [Page 6]
1.2 STIP Functions of the IP Entity The IP Entity has one basic interface that supports the IP protocol to connect to the IP network. The IP Entity is the component that provides the processing of the TCAP message. The IP Entity communicates with TIPG via STIPP protocol as described in section 2. The IP Entity is responsible for providing the application functionality of one or more protocols or subsystems. If the IP Entity receives a message of TCAP Data message type that is not in its supported protocols, it should send back a message of the TCAP Data Error message type with the TCAP message in the Data portion of the message. By doing this, it will provide the TIPG enough information to send back to the originator of the message UDTS or XUDTS message. 2.0 Simple TCAP-IP Protocol (STIPP) Simple TCAP-IP Protocol (STIPP) defines the protocol to be used between the TIPG and the IP entity. 2.1 Communication between the TIPG and the IP entity The transfer of the TCAP messages between the TIPG and IP entity uses the UDP protocol to provide the real-time communication. The TIPG and the IP Entities must implement a common reliable mechanism to ensure the reliable delivery of the UDP packets. The Assigned Numbers Authority should assign the port number of which the TIPG will receive the UDP packets from the IP entities. 2.2 STIP Header The format of the STIP Header is shown below. The fields are transmitted from left to right. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--------------------------------+ |Version| Message Type | +-------+------------------------+ | Message Length | +--------------------------------+ | Data Offset | +--------------------------------+ | Attribute #1 | +--------------------------------+ .. .. +--------------------------------+ | Attribute #n | +--------------------------------+ | Data | | | +--------------------------------+ <draft-liao-stiff-00.txt> [Page 7]
* Version The Version field is four bits, and indicates the version number of the received packet. This field must set to 1 to indicate STIPP Version 1. * Message Type The Message Type field is twelve bits, and identifies the type of the STIPP packet. The STIPP Message Types are assigned as follows: 1 Login 2 Login Acknowledgment 3 CHAP Packet 4 TIPG Status 5 IP Entity Status 6 TCAP Data 7 TCAP Data Error See section 2.2.2 for more information on each message type. * Message Length The Message Length field is 16 bits, and indicates the total length of the packet excluding the length of Version, Message Type, and Message Length fields. * Data Offset The Data Offset field is 16 bits, and indicates the offset to the data portion from the first byte of the Attribute #1. * Attribute See section 2.2.1 for more information of parameter formats. * Data The format of the Data field is message-dependent and can be NULL. See section 2.2.2 for more information. 2.2.1 Attribute Format The TIPG attributes carry the information specific to each message type. The format of the attribute is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ... +---------------+---------------+------------------+ | Type | Length | Value | +---------------+---------------+------------------+ <draft-liao-stiff-00.txt> [Page 8]
* Type The Type field is one octet. The current assigned values are as follows: 1 System Name 2 Primary/Backup 3 Subsystem Number 4 Encryption Index 5 Address Mapping Option 6 Message Encryption 7 TIPG Status 8 IP Entity Status 9 Additional Status Information 10 Protocol Type 11 IP Address 12 Calling Party Address 13 Called Party Address 14 Identification 15 Error Reason * Length The Length field is one octet, and indicates the length of the Value field. * Value The Value field is zero or more octets and contains information specific to the attribute. The Type field determines the format of the Value field. 2.2.1.1 System Name This attribute contains the name of the system to be authenticated by the TIPG. It is normally used within the Login message type. Type - 1 for System Name Length - >= 3 Value - String format 2.2.1.2 Primary/Backup This attribute indicates to the TIPG that the logged-in system is a primary or backup system. It is normally used within the Login message type. Type - 2 for Primary/Backup Length - = 1 Value - 1 for primary, 2 for backup 2.2.1.3 Subsystem Number This attribute indicates to the Subsystem Number of an IP Entity. It is normally used within the Login message type. Type - 3 for Subsystem Number Length - = 1 Value - Per SS7 standard <draft-liao-stiff-00.txt> [Page 9]
2.2.1.4 Encryption Index This attribute contains the index of a pre-defined set of encryption algorithm supported by the TIPG. It is normally used within the CHAP Packet message type. The values of this field are to be defined. Type - 4 for Encryption Index Length - = 2 Value - 16-bit value with 0 for MD5 2.2.1.5 Address Mapping Option This attribute allows the IP Entity to select one of the two address mapping methods. In the first mapping method, the address information is included in the message transferring between the TIPG and the IP Entity. In the second mapping, the TIPG keeps track the mapping between Transaction ID and the Calling/Called party addresses. It is normally used within the Logon message type. The values of this field are to be defined. Type - 5 for Address Mapping Option Length - 1 Value - 0 for the first mapping method (default), 1 for the second mapping mothod. 2.2.1.6 Message Encryption This attribute contains the flags sent by the TIPG to tell the IP Entity whether or not the encryption is needed for the message transferring between the TIPG and the IP Entity. It is normally used within the Login Acknowledgment message type. The values of this field are to be defined. Type - 6 for Message Encryption Length - = 2 Value - Bit 0 for Authentication Header (AH), Bit 1 for Encapsulating Security Payload (ESP). The default is no encryption (bits 0 and 1 both are 0). 2.2.1.7 TIPG Status This attribute contains the status of the TIPG and normally used within the TIPG Status message type. The values of this field are to be defined. Type - 7 for TIPG Status Length - = 2 Value - 16-bit value 2.2.1.8 IP Entity Status This attribute contains the status of the IP Entity and normally used within the IP Entity Status message type. The values of this field are to be defined. Type - 8 for IP Entity Status Length - = 2 Value - 16-bit value <draft-liao-stiff-00.txt> [Page 10]
2.2.1.9 Additional Status Information This attribute contains the string description of the TIPG or IP Entity status. It is optionally used within either the TIPG Status or IP Entity Status message type. Type - 9 for Additional Status Information Length - >= 0 Value - String format 2.2.1.10 Protocol Type This attribute contains the protocol type of the TCAP message. The IP Entity can optionally include this attribute in its Login message to indicate to the TIPG what protocol it supports. Type - 10 for Protocol Type Length - = 2 Value - 16-bit value that has the following values: 0 - TCAP 1 - IS-41 2 - MAP 3 - TBD 2.2.1.11 IP Address This attribute contains the IP address of the IP Entity. It is optional and used within the message types that are sent from IP Entity to the TIPG. Type - 11 for IP Address Length - 4 for IPv4 and 6 for IPv6 Value - IP address 2.2.1.12 Calling/Called Party Address This attribute contains the SCCP Party Address parameters. It is normally used within the TCAP Data message type that is sent from the TIPG to the IP Entity and vice versa. Type - 12 for Calling Party Address or 13 for Called Party Address Length - = 15 Value - See SCCP Calling/Called Party Address parameter for format [3]. 2.2.1.13 Identification This attribute contains the sequential number that is used to aid in protection against replay attack. This attribute is optional for all protocol messages defined in this paper except the CHAP messages. The inclusion of this attribute in the Login and Login Acknowledgment messages is only for the synchronization purpose. The TIPG must maintain the Identification value per IP entity. If an IP entity is designed to use the identification attribute, it must include this attribute in the Login message with the high-order 16-bit set to its current value and the low-order 16-bit set to zero. <draft-liao-stiff-00.txt> [Page 11]
The TIPG must send back the Login Acknowledgment with the high-order 16- bit set to the value obtained from the Login message and low-order 16- bit set to its current value. Any messages originate from the IP Entity to the TIPG must have the high-order 16-bit set to the IP entity's last value plus one. The TIPG must record the last identification value in order to perform the check on the identification field of any messages it receives from the IP entity. If the check is failed, the message should be discarded. Any messages originate from the TIPG to the IP entity must have the low- order 16-bit set to the TIPG's last value plus one. The IP entity should also perform the check on the Identification attribute before processing the message. Type - 14 for Identification Length - = 4 Value - 32-bit value. 2.2.1.14 Error Reason This attribute contains the reason that the IP Entity or the TIPG cannot handle a TCAP message. It is normally used within the TCAP Data Error message type. The Error Reason would be mapped to Error in UDTS or XUDTS message. Type - 15 for Error Reason Length - = 2 Value - Error Code (TBD) 2.2.2 Protocol Messages This section defines what attribute is mandatory or optional in each message type. 2.2.2.1 Login This message type is sent from the IP Entity to the TIPG to begin the login process. The Subsystem number is recorded in the addressing table to be used for routing the traffic from TIPG to IP Entity. The Data field of the message must be NULL for this message type. +---------------------+--------------+--------------------------------+ | Attribute | Type | Comment | +---------------------+--------------+--------------------------------+ | System Name | Mandatory | | +---------------------+--------------+--------------------------------+ | Subsystem Number | Mandatory | | +---------------------+--------------+--------------------------------+ | Primary/Backup | Mandatory | | +---------------------+--------------+--------------------------------+ | Identification | Optional | | +---------------------+--------------+--------------------------------+ | Protocol Type | Optional | Protocol Name | +---------------------+--------------+--------------------------------+ <draft-liao-stiff-00.txt> [Page 12]
| Other System Name | Optional |System Name of the other | | | | primary/backup system | +---------------------+--------------+--------------------------------+ | Other IP Address | Optional |IP Address of the other | | | | primary/backup system | +---------------------+--------------+--------------------------------+ |Address Mapping | | | |Option | Optional | | +---------------------+--------------+--------------------------------+ 2.2.2.2 Login Acknowledgment This message type is sent from the TIPG to the IP Entity in response to a Login message. The Data field of the message must be NULL for this message type. +---------------------+--------------+--------------------------------+ | Attribute | Type | Comment | +---------------------+--------------+--------------------------------+ | TIPG Status | Mandatory | | +---------------------+--------------+--------------------------------+ | Identification | Optional | | +---------------------+--------------+--------------------------------+ | Message Encryption | Optional | | +---------------------+--------------+--------------------------------+ | Additional Status | Optional | | | Information | | | +---------------------+--------------+--------------------------------+ 2.2.2.3 CHAP Packet This message type is sent in both directions from the TIPG to the IP Entity and from the IP Entity to the TIPG depending on the CHAP code field. The Data field of the message must contain the CHAP packet as defined in RFC 1994. +---------------------+--------------+--------------------------------+ | Attribute | Type | Comment | +---------------------+--------------+--------------------------------+ | Encryption Index | Optional |If not present, MD5 will be the | | | | default | +---------------------+--------------+--------------------------------+ 2.2.2.4 TIPG Status This message type is sent from the TIPG to the IP Entity. The message type can optionally be sent periodically from the TIPG to the IP Entity. The IP Entity uses this message as an audit message to verify the TIPG is still functional. The IP Entity expects this message every TBD time from TIPG. If IP Entity does not receive this message then IP Entity marks TIPG as down and starts communicating to the inactive or mate TIPG. The Data field of the message must be NULL for this message type. <draft-liao-stiff-00.txt> [Page 13]
+---------------------+--------------+--------------------------------+ | Attribute | Type | Comment | +---------------------+--------------+--------------------------------+ | TIPG Status | Mandatory | | +---------------------+--------------+--------------------------------+ | Identification | Optional | | +---------------------+--------------+--------------------------------+ | Additional Status | Optional | | | Information | | | +---------------------+--------------+--------------------------------+ 2.2.2.5 IP Entity Status This message type is sent from the IP Entity to the TIPG. This message should be sent periodically to the TIPG as a mean for the TIPG to know that the IP Entity is still alive and functional. If TIPG does not receive this message then TIPG marks IP Entity as unreachable and starts communicating to Backup IP Entity if registered. The Data field of the message must be NULL for this message type. +---------------------+--------------+--------------------------------+ | Attribute | Type | Comment | +---------------------+--------------+--------------------------------+ | IP Entity Status | Mandatory | | +---------------------+--------------+--------------------------------+ | Identification | Optional | | +---------------------+--------------+--------------------------------+ | Additional Status | Optional | | | Information | | | +---------------------+--------------+--------------------------------+ 2.2.2.6 TCAP Data This message type is sent in both directions from the TIPG to the IP entity or from the IP Entity to the TIPG. This message is intended to carry the actual TCAP data. The Data portion contains the actual TCAP message. +---------------------+--------------+--------------------------------+ | Attribute | Type | Comment | +---------------------+--------------+--------------------------------+ | Identification | Optional | | +---------------------+--------------+--------------------------------+ | Protocol Type | Optional | | +---------------------+--------------+--------------------------------+ | Called Party | Mandatory | | | Address | | | +---------------------+--------------+--------------------------------+ | Calling Party | Mandatory | | | Address | | | +---------------------+--------------+--------------------------------+ <draft-liao-stiff-00.txt> [Page 14]
2.2.2.7 TCAP Data Error This message type is sent in both directions from the TIPG to the IP entity or from the IP Entity to the TIPG if the IP Entity or the TIPG cannot handle a TCAP message. The Data portion is a copy of the Data portion of the corresponding message of the TCAP Data message type. +---------------------+--------------+--------------------------------+ | Attribute | Type | Comment | +---------------------+--------------+--------------------------------+ | Error Reason | Mandatory | | +---------------------+--------------+--------------------------------+ | Identification | Optional | | +---------------------+--------------+--------------------------------+ | Additional Status | Optional | | | Information | | | +---------------------+--------------+--------------------------------+ | Called Party | Mandatory | | | Address | | | +---------------------+--------------+--------------------------------+ | Calling Party | | | | Address | Mandatory | | +---------------------+--------------+--------------------------------+ 3.0 System Redundancy A fully redundant system is proposed in the following figure: +----------+ +---+ A-link +-----+ IP | Primary | |SCP| +---+----------------|TIPG |-------------| IP Entity| +---+----- |STP|--------\ /-----+-----+---\ /-------+----------+ \ / +---+ / \ A-link/ +---+ -------/ \-----+-----+---/ \-------+----------+ \---|STP|----------------|TIPG |-------------| Backup | / -- +---+ +-----+ | IP Entity| / / pair +----------+ +---+ / |SP |/ +---+ Figure 4: System Redundancy This figure proposes system redundancy with two TIPG systems and the primary and backup IP Entities. This configuration will support the dual-redundancy of the SS7 standard. The STIPP message protocol has been defined to support this redundant feature. The data synchronization between the primary and the backup IP Entities is application dependent and is not the concern of this document. The STIPP requires IP Entities to login into both TIPGs to provide the redundancy at TIPG. <draft-liao-stiff-00.txt> [Page 15]
The two TIPGs may be operated in a load sharing mode. The load sharing on SS7 interfaces to the interconnection SS7 network is done by routing provisioning. The IP entities must be able to load balance outbound traffic to the TIPGs. The load sharing among the IP entities of the same applications is for future study. 4.0 Scenarios This section describes a few scenarios to illustrate how the STIPP works. It does not intend to give an exhaustive list of all scenarios. 4.1 Login Scenario This scenario describes the login sequence of both primary and backup IP Entities. The primary IP Entity logs in the TIPG and then the backup IP Entity. The primary IP Entity has the system name of "Primary", Subsystem Number of 4, and the IP address of "47.106.111.20". The backup IP Entity has the system name of "Backup", Subsystem Number of 4, and the IP address of "47.106.111.21". 1. The primary IP Entity sends the Login message to the TIPG: Message Type = 1 for Login message type, System Name = "Primary", Subsystem Number = 4, Primary/Backup = 1 for primary, Other System Name = "Backup", Other IP Address = "47.106.111.20". 2. The TIPG looks up its database for the system name of "Primary" to get some information about the primary IP Entity and then sends the CHAP Challenge Packet to the primary IP Entity: Message Type = 3 for CHAP Packet message type, Data field = contents of the CHAP Challenge packet. 3. The primary IP Entity calculates the response value from the information from the CHAP Challenge packet and sends back the CHAP Respond packet to the TIPG: Message Type = 3 for CHAP Packet message type, Data field = contents of the CHAP Respond packet. 4. The TIPG compares the CHAP Response packet against its own calculation. Assume that the CHAP Response packet is good, the TIPG sends the CHAP Success packet back to the primary Entity: Message Type = 3 for CHAP Packet message type, Data field = contents of the CHAP Success packet. The TIPG also sends the Login Acknowledgment message to the primary IP Entity: Message Type = 2 for Login Acknowledgment message type, TIPG Status = 0 for a good acknowledgment, Message Encryption (optional) = 3 for both AH and ESP. 5. The TIPG creates an entry for primary IP Entity in its address translation table with Subsystem Number, IP address and port number of the primary IP entity, Message Encryption, etc. 6. The backup IP Entity sends the Login message to the TIPG: Message Type = 1 for Login message type, System Name = "Backup", Subsystem Number = 4, Primary/Backup = 2 for backup, Other System Name = "Primary", Other IP Address = "47.106.111.21". <draft-liao-stiff-00.txt> [Page 16]
7. The TIPG validates the information of this Login message against the primary login. If at least one of the parameters does not match, it sends the Login Acknowledgment message back to the backup IP Entity with an error code in the TIPG status attribute. 8. If everything is matched, repeat steps 2 to 4 to perform the CHAP challenge procedure. 9. The TIPG modifies the table entry for the primary IP Entity to add the backup IP Entity information. 10. The Primary and Backup IP Entities repeat steps 1 to 9 to login to the Backup TIPG. All the IP Entities are configured with both Primary and Backup TIPG information. 4.2 Unidirectional TCAP Message 4.2.1 SS7-Generated Unidirectional TCAP Message This scenario describes how the TIPG and the IP Entity process a Unidirectional TCAP message received from SS7 network. 1. The TIPG receives a Unidirectional TCAP message from SS7 network. It performs the SS7 decapsulation/IP encapsulation and then sends to the IP Entity for processing using the TCAP Data message type. 2. The TIPG gets Subsystem number from Called Party Address from SCCP header and looks up the Addressing table and sends the TCAP Data Message to the IP Entity. 3. The IP Entity processes the TCAP message. 4.2.2 IP Entity-generated Unidirectional TCAP Message This scenario describes how a Unidirectional TCAP message generated by an IP Entity is transmitted into the SS7 network. 1. The IP Entity builds a Unidirectional TCAP message and sends to the TIPG using the TCAP Data message type. 2. The TIPG performs the IP decapsulation/SS7 encapsulation and builds the outgoing SS7 Message. The SCCP Calling Party Address is filled with the TIPG Point Code and the IP Entity Subsystem Number from the address table if SSN is not present. The SCCP Called Party Address is filled with the information from the Called Party Address attribute of the STIP Header. 3. The TIPG retrieves point code from Called Party Address or performs GTT to find the destination point code and sends the SS7 message to SS7 network. <draft-liao-stiff-00.txt> [Page 17]
4.3 Simple Query/Response TCAP Messages 4.3.1 SS7-Initiated Transaction This scenario describes a simple exchange of TCAP messages that is initiated by a SS7 node. 1. The TIPG receives a Query With Permission TCAP message from the SS7 node. 2. The TIPG performs the SS7 decapsulation /IP encapsulation and then sends to the IP Entity using the TCAP Data message type. The Calling Party Address attribute contains the information from the SCCP Calling Party Address. 3. The IP Entity processes the received TCAP messages and sends back a Response TCAP message to the TIPG using the TCAP Data message type. The Called Party Address attribute contains a copy of the Calling Party Address attribute of the received Query With Permission TCAP message. 4. The TIPG performs the IP decapsulation/SS7 encapsulation and sends to the SS7 network. The SCCP Calling Party Address is filled with the TIPG Point Code and the IP Entity Subsystem Number if no SSN is present in the TCAP Data Message. The SCCP Called Party Address is filled with the information from the Called Party Address attribute of the STIP Header. The DPC is set to the PC in Called Party Address. 5. The SS7 node receives the message and terminates the transaction. 4.3.2 IP Entity-Initiated Transaction This scenario describes a simple exchange of TCAP messages that is initiated by an IP Entity. 1. The IP Entity builds a Query With Permission TCAP message and sends to the TIPG using the TCAP Data message type. 2. The TIPG performs the IP decapsulation/SS7 encapsulation and sends to the destination SS7 node. The SCCP Calling Party Address is filled with the TIPG Point Code and the IP Entity Subsystem Number if Calling Party Address SSN is not present in the TCAP Data Message. The SCCP Called Party Address is filled with the information from the Called Party Address attribute of the STIP Header. 3. The TIPG retrieves point code from Called Party Address or performs GTT to find the destination point code and sends the SS7 message to SS7 network. 4. The destination SS7 node receives the TCAP message and sends back with a Respond TCAP message to the TIPG. 5. The TIPG performs the SS7 decapsulation /IP encapsulation and then sends to the IP Entity using the TCAP Data message type. <draft-liao-stiff-00.txt> [Page 18]
6. The IP Entity receives the Response TCAP message and completes the transaction. 4.4 Erroneous TCAP Message 4.4.1 SS7-Generated Erroneous TCAP Message This scenario describes an example of the IP Entity receiving an erroneous TCAP message from SS7 network. 1. The TIPG receives a TCAP message from SS7 network. It performs the SS7 decapsulation/IP encapsulation and then sends to the IP Entity for processing using the TCAP Data message type. 2. The IP Entity receives the TCAP message. It determines that it cannot process the message. It sends back to the TIPG a message of TCAP Data Error message type. The Called Party Address attribute contains the copy of the Calling Party Address from the received message. The Data field must be a copy of the Data field of the received message. 3. The TIPG sends back the UDTS (or XUDTS) message to the SS7 node. The SCCP Calling Party Address is filled with the TIPG Point Code and the IP Entity Subsystem Number. The SCCP Called Party Address is filled with the information from the Called Party Address attribute of the STIP Header. The data field of the TCAP Data Error message is copied into UDTS message. 4.4.2 IP Entity-Generated Erroneous TCAP Message This scenario describes an example of the IP Entity sending an erroneous TCAP message. 1. The IP Entity builds a TCAP message and sends to the TIPG using the TCAP Data message type. 2. The TIPG performs the IP decapsulation/SS7 encapsulation and then sends to the destination SS7 node. The SCCP Calling Party Address is filled with the TIPG Point Code and the IP Entity Subsystem Number. The SCCP Called Party Address is filled with the information from the Called Party Address attribute of the STIP Header. 3. The SS7 node receives the TCAP message. It determines that it cannot process the message. It sends back to the TIPG with an UDTS (or XUDTS) message. 4. The TIPG receives this UDTS (or XUDTS) message. It then sends to the IP Entity a message of TCAP Data Error message type. The Data field of this message must be a copy of the Data field of the UDTS (or XUDTS) message (which is the TCAP message). 5. The IP Entity receives this TCAP Data Error message and performs its own error handling. <draft-liao-stiff-00.txt> [Page 19]
5.0 Security The TIPG can be designed to protect the SS7 network from illegal access by performing the source address filtering. Implementing the IP Authentication Header (AH) and/or the IP Encapsulating Security Payload (ESP) for the links between the TIPG and the IP Entities are recommended but not required. If these links belong to a private network, implementing these IP security protocols is optional. 6.0 References and Related Work [1] M. Liao, L. Le, E. Qaddoura, and D. Wurch, "SS7-TCAP/IP Interworking" draft-liao-ss7-tcap-ip-v0.txt", March 1999, work in progress [2] ITU-T Recommendation Q.700, "Introduction to CCITT Signaling System No. 7", March, 1993 [3] ITU-T Recommendation Q.713, "SCCP Format and Codes", March, 1993 [4] W. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996 7.0 Authors Monling Liao Nortel RTP, NC Phone: (919) 991-2704 email: monling@nortelnetworks.com Emad Qaddoura Nortel Richardson, TX Phone: (972) 684-2705 Email: EmadQ@nortelnetworks.com Liem Le Nortel Richardson, TX Phone: (972) 684-0689 Email: LiemLe@nortelnetworks.com Rambabu Tummula Nortel Richardson, TX Phone: (972) 684-8970 Email: tummala@nortelnetworks.com Don Wurch Nortel Richardson, TX Phone: (972) 684-1049 Email: DWurch@nortelnetworks.com INTERNET DRAFT EXPIRES September 1999 INTERNET DRAFT