Network Working Group Vipin Gupta INTERNET-DRAFT Hughes Software Systems Kamesh Kaul Hughes Software Systems Expires in six months Jan 2002 SIGTRAN Inter Signaling Process Communication 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/1id-abstracts.html 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). Gupta [Page 1] Internet Draft Inter Signaling Process Communication Dec 2001 Abstract This Internet Draft explains the need of Inter Signaling process communication in the systems making use of SIGTRAN protocol. It also proposes procedures and various interface primitives for inter signaling process communication. This draft mainly focuses on Signaling Gateway Processes and Application Server Processes as defined in SIGTRAN. Kaul [Page 2] Internet Draft Inter Signaling Process Communication Dec 2001 TABLE OF CONTENTS 1. Introduction.......................................................4 1.1 Scope.........................................................4 1.2 Terminology...................................................5 1.3 Assumptions...................................................8 2. Need for Inter SP communication....................................8 2.1 Example Scenarios.............................................9 2.2 Traffic Forwarding between SPs...............................11 2.3 Mis-Sequencing Problem and its Solution......................12 2.4 Sequence Numbers.............................................13 2.5 Information sharing between SPs..............................13 2.5.1 Information sharing between SGPs.......................14 2.5.2 Information sharing between ASPs.......................14 3. Inter-SP Interface................................................14 4. Support from SIGTRAN UA Protocols.................................15 4.1 Parameters required in DATA Messages.........................15 4.1.1 Sequence Number........................................16 4.1.2 SP ID..................................................16 4.2 Messages Required in SIGTRAN UA protocols....................16 5. Example of Inter SP Coordination..................................17 6. Acknowledgements..................................................19 7. References........................................................19 8. Author's Addresses................................................19 Gupta [Page 3] Internet Draft Inter Signaling Process Communication Dec 2001 1. Introduction This draft explains the need of inter signaling process communication and proposes procedures and interfaces to support inter signaling process communication between various signaling processes supporting the same logical entity. These logical entities are Application Server and Signaling Gateway as defined in the SIGTRAN. It mainly focuses on how multiple Signaling Processes can coordinate with each other to provide high availability of SIGTRAN for the SS7 traffic. The main focus is to maximize: (a) availability of logical SS7 nodes in the IP domain served by Application Server Processes (b) accessibility to SS7 network using Signaling Gateway Processes. 1.1 Scope There is a need for networks using SIGTRAN to meet the high availability requirements imposed by the SS7 standards. One of the most effective methods to achieve this is by supporting multiple Signaling processes in the same logical entity and providing Inter Signaling Process communication between them. The scope of this draft is to: (a) explain the need of Inter Signaling process communication (b) propose procedures and interface primitives for Inter Signaling Process communication. Kaul [Page 4] Internet Draft Inter Signaling Process Communication Dec 2001 1.2 Terminology Application Server (AS) - A logical entity serving a specific Routing Key. An example of an Application Server is a virtual switch element handling all call processing for a unique range of PSTN trunks, identified by an SS7 SIO/DPC/OPC/CIC_range. Another example is a virtual database element, handling all HLR transactions for a particular SS7 DPC/OPC/SCCP_SSN combination. The AS contains a set of one or more unique Application Server Processes, of which one or more is normally actively processing traffic. Note that there is a 1:1 relationship between an AS and a Routing Key. Application Server Process (ASP) - A process instance of an Application Server. An Application Server Process serves as an active or backup process of an Application Server (e.g., part of a distributed virtual switch or database). Examples of ASPs are processes (or process instances) of MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP endpoint and may be configured to process signalling traffic within more than one Application Server. Association - An association refers to an SCTP association. The association provides the transport for the delivery of SIGTRAN UA protocol data units. IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses SIGTRAN UA in a point-to-point fashion. Conceptually, an IPSP does not use theservices of a Signalling Gateway node. Failover - The capability to reroute signalling traffic as required to an alternate Application Server Process, or group of ASPs, within an Application Server in the event of failure or unavailability of a currently used Application Server Process. Failover also applies upon the return to service of a previously unavailable Application Server Process. Host - The computing platform that the process (SGP, ASP or IPSP) is running on. Gupta [Page 5] Internet Draft Inter Signaling Process Communication Dec 2001 Layer Management - Layer Management is a nodal function that handles the inputs and outputs between the SIGTRAN UA layer and a local management entity. Linkset - A number of signalling links that directly interconnect two signalling points, which are used as a module. MTP - The Message Transfer Part of the SS7 protocol. MTP3 - MTP Level 3, the signalling network layer of SS7 MTP3-User - Any protocol normally using the services of the SS7 MTP3 (e.g., ISUP, SCCP, TUP, etc.). Network Appearance - The Network Appearance is a local reference shared by SG and AS (typically an integer) that together with an Signaling Point Code uniquely identifies an SS7 node by indicating the specific SS7 network it belongs to. It can be used to distinguish between signalling traffic associated with different networks being sent between the SG and the ASP over a common SCTP association. An example scenario is where an SG appears as an element in multiple separate national SS7 networks and the same Signaling Point Code value may be reused in different networks. Network Byte Order: Most significant byte first, a.k.a Big Endian. Routing Key: A Routing Key describes a set of SS7 parameters and parameter values that uniquely define the range of signalling traffic to be handled by a particular Application Server. Parameters within the Routing Key cannot extend across more than a single Signalling Point Management Cluster. Routing Context - A value that uniquely identifies a Routing Key. Routing Context values are either configured using a configuration management interface, or by using the routing key management procedures defined in this document. Kaul [Page 6] Internet Draft Inter Signaling Process Communication Dec 2001 Signalling Gateway Process (SGP) - A process instance of a Signalling Gateway. It serves as an active, backup, loadsharing or broadcast process of a Signalling Gateway. Signalling Gateway - An SG is a signaling agent that receives/sends SCN native signaling at the edge of the IP network [1]. An SG appears to the SS7 network as an SS7 Signalling Point. An SG contains a set of one or more unique Signalling Gateway Processes, of which one or more is normally actively processing traffic. Where an SG contains more than one SGP, the SG is a logical entity and the contained SGPs are assumed to be coordinated into a single management view to the SS7 network and to the supported Application Servers. Signalling Process (SP) - A process instance that uses SIGTRAN UA to communicate with other signalling processes. An ASP, an SGP and an IPSP are all signalling processes. Signalling Point Management Cluster (SPMC) - The complete set of Application Servers represented to the SS7 network under a single MTP entity (Signalling Point) in one specific Network Appearance. SPMCs are used to aggregate the availability, congestion, and user part status of an MTP entity (Signalling Point) that is distributed in the IP domain, for the purpose of supporting MTP3 management procedures towards the SS7 network. In some cases, the SG itself may also be a member of the SPMC. In this case, the SG availability /congestion /User_Part status should also be taken into account when considering any supporting MTP3 management actions. Stream - A stream refers to an SCTP stream; a unidirectional logical channel established from one SCTP endpoint to another associated SCTP endpoint, within which all user messages are delivered in-sequence except for those submitted to the unordered delivery service. SIGTRAN UA - It refers to any SIGTRAN User Adaptation Layer like M3UA, SUA or M2UA. Gupta [Page 7] Internet Draft Inter Signaling Process Communication Dec 2001 1.3 Assumptions This draft assumes the following: (a) The IP network used by the SIGTRAN is well designed and available all the time, i.e., if communication lost primitive is received from SCTP then it is not due to any failures in the underlying IP network. (b) Method of communication between two coordinating SPs is reliable and no messages are lost. SPs communicating with each other use a mechanism which ensures no loss and mis-sequencing of messages. 2. Need for Inter SP Communication SIGTRAN is designed to transport the SS7 signaling over the IP network. This implies that the systems supporting SIGTRAN should be highly reliable. Considering a complete SIGTRAN system, it consists of IP network and Signaling Processes running over it. Properly designed networks will certainly ensure less failures but improper configurations and local failures in SPs may become a source of overall failure in a SIGTRAN system. Inter Signaling Process communication can be utilised in order to overcome some of the deficiencies arising due to improper configurations or local failures in an SP. Even if a single SP in a logical entity is available then no SS7 traffic on that logical entity should be discarded. When an SP becomes inactive and other active SP takes over all the traffic of the inactive SP then mis-sequencing of SS7 traffic can take place unless some sort of inter SP coordination is present.Similarly if a SP becomes newly active and takes over some part of the traffic from the other active SPs then again mis-sequencing can take place if inter SP coordination is absent. Kaul [Page 8] Internet Draft Inter Signaling Process Communication Dec 2001 2.1 Example Scenarios Take an example where an SG consists of three SGPs and the AS consists of one ASP. +---------------------+ | SG1 | | +----------------+ | | | | | | | SGP1 +--+------+ | | | | | | +----------------+ | | | | | +--------------------+ | | | | AS1 | | +----------------+ | +------+ | | | | | | | | +---------------+ | | | SGP2 | | +--+--+ | | | | +--+----------------+--+ ASP1 | | | +----------------+ | +--+--+ | | | | | | +---------------+ | | +----------------+ | +------+ | | | | | | | | | | | SGP3 | | | +--------------------+ | | +--+------+ | +----------------+ | | | +---------------------+ Consider the case when ASP1 is ACTIVE in all the SGPs. All the SGPs are sending/receiving data to/from the ASP1. SG is operating in loadsharing mode. Now ASP1 becomes INACTIVE in SGP2. In normal case if the SGPs are not coordinating with each other then SS7 traffic at SGP2 is buffered for pending time period and after that it will be rejected. Even though the AS is reachable via SGP1 and SGP3, SG is rejecting a portion of SS7 traffic which is responsibility of SGP2. Here it is assumed that the distribution mechanism at SG, which is distributing the traffic received from the SS7 network between the SGPs is not aware of the state of AS in SGPs. Even if the distribution mechanism is intelligent enough to re-distribute the traffic, it cannot Gupta [Page 9] Internet Draft Inter Signaling Process Communication Dec 2001 avoid mis-sequencing of traffic. The mis-sequencing problem is discussed in detail later in this draft. If ASP1 has become DOWN in SGP2 due to some local failure in SGP2 or SCTP CDI then there are chances of loss of data that has been sent from SGP2 to ASP1. If SCTP supports then this data can be retrieved from SCTP. To avoid above mentioned problems it is recommended that the distribution mechanism should not re-distribute the traffic and SPs should communicate with each other to avoid mis-sequencing and traffic rejection or loss. Consider the case where an AS consists of 3 ASPs and SG consists of single SGP. +---------------------+ | AS1 | | +----------------+ | | | | | | | ASP1 +--+------| | | | | | | +----------------+ | | | | | +--------------------+ | | | | SG1 | | +----------------+ | -------| | | | | | | | | ----------------+ | | | ASP2 | | ---+--| | | | | +--+----------------+--+ SGP1 | | | +----------------+ | ---+--| | | | | | | +---------------+ | | | | | | | +----------------+ | -------| | | | | | | | | | | | ASP3 | | | +--------------------+ | | +--+------| | +----------------+ | | | +---------------------+ Kaul [Page 10] Internet Draft Inter Signaling Process Communication Dec 2001 All the ASPs are active in the SGP and sending SS7 traffic to the SGP. Now Association between ASP2 and SGP1 goes down, then the ASP User at the ASP2 will not be able to send the data to the SG even though the SS7 network is reachable via the SG. To avoid this problem ASPs can coordinate with each other and hence provide uninterrupted service to their users. 2.2 Traffic Forwarding between SPs As explained in section 2.1 that if Inter SP communication is present and any association is ACTIVE between an AS and a SG then continous flow of SS7 traffic can be ensured. In case an SP is unable to send messages to the peer SP, then traffic forwarding can be put in use to provide uninterrupted flow of SS7 traffic between AS and SG. This forwarding of traffic certainly requires SPs to share some information between them. This information is discussed in detail in the subsequent sections. Gupta [Page 11] Internet Draft Inter Signaling Process Communication Dec 2001 2.3 Mis-Sequencing Problem and its Solution If an SP starts forwarding data through another SP as discussed in section 2.2 then mis-sequencing can take place. To avoid this problem coordination between SP(s) of the same logical entity and coordination between the peer SPs serving same peer logical entity is required. Consider the following figure with AS consisting of two ASPs and SG consisting of two SGPs. +-------------------+ +--------------------+ | SG1 | | AS1 | | +---------------+ | | +----------------+ | | | | | (a)| | | | | | SGP1 |--------------| ASP1 | | | | |-------| | | | | | +---------------+ | | | +----------------+ | | | | | | | | | | | | +---------------+ | | (b)| +----------------+ | | | | | -------| | | | | SGP2 |--------------| ASP2 | | | | | | (c)| | | | | +---------------+ | | +----------------+ | | | | | +-------------------+ +--------------------+ All the associations are active between the SG and AS. Now their is some local failure in the SGP1 and associations from it to ASP1 and ASP2 goes down. Before SGP1 starts forwarding data to SGP2 it is necessary that all the data sent from SGP1 on its associations (a) and (b) must reach the AS otherwise mis-sequencing of data can take place. In short if any traffic from one association is moved to another association then mis-sequencing can take place. The solution to this problem is to attach sequence number with the data messages. Following are the steps which will help preventing mis-sequencing if SGP1 wishes to forward data through SGP2. While Kaul [Page 12] Internet Draft Inter Signaling Process Communication Dec 2001 this procedure takes place all the data arriving at SGP2 for associations (a) and (b) should be buffered. 1) SGP1 will request SGP2 to retrieve the sequence number of the last data message received by ASP1 and ASP2. 2) SGP2 sends request for sequence number of last data message from SGP1 to ASP2. 3) ASP2 will collect the information from all the ASP(s) in the same AS (AS1), in this case ASP1, about the sequence number of the last data message received by them from SGP1. 4) These sequence numbers received from all the other ASP(s) are sent to the SGP2 from ASP2. 5) SGP2 will then return these sequence numbers to SGP1. 6) Now based on these numbers SGP1 will decide whether or not all the data sent from it to AS1 (ASP1 and ASP2) before AS1 became DOWN in SGP1 has been received by the AS1. The above solution can easily be generalised and should be used if Data message forwarding is supported by the SPs. Same logic can be applied for the ASPs which are part of the same AS. 2.4 Sequence Numbers Sequence numbers should be attached to all the data messages. Each SP will have its own sequence numbering. Sequence numbers should be maintained by an SP on local and remote SP pair. Sequence numbers for each AS should be maintained separately. For example SGP1 will maintain a sequence number for SGP1 and ASP1 pair and SGP1 and ASP2 pair separately. This implies that while sequence numbers are assigned to a data message, destination SP to which data message will be sent is known. 2.5 Information sharing between SPs There is a need for information sharing between the SPs as mentioned before in this draft. The information which has to be shared between the SGPs and ASPs is different. The information to be shared is discussed in the following sub sections. There is also a need to uniquely identify all the logical entities (ASs and SGs). This unique id should be same in all the ASP(s) and SGP(s). Gupta [Page 13] Internet Draft Inter Signaling Process Communication Dec 2001 2.5.1 Information sharing between SGPs Information that is required to be shared between the SGPs is state of all the ASs configured in the SGPs. If an SGP receives data for an AS which is not ACTIVE in it, then it can forward data via some other coordinating SGP which has AS ACTIVE in it. 2.5.2 Information sharing between ASPs Information that is required to be shared between the ASPs is state of Point Codes which are reachable through the SG. If an ASP receives data for a DPC which is reachable through some SG in which the ASP is not ACTIVE, then it can forward data via some other coordinating ASP which is ACTIVE in the SG. 3.0 Inter-SP Interface The Primitives for Inter SP interface are: RETR_LAST_SEQ_NO_FROM_PEER_REQ A SP requests a coordinating SP to retrieve the sequence number of the last data message received by the SP of the peer logical entity. RETR_LAST_SEQ_NO_FROM_PEER_RSP Response to RETR_LAST_SEQ_NO_FROM_PEER_REQ. LAST_SEQ_NO_RECVD_FROM_PEER_REQ A SP requests for the last sequence number received from a peer SP to a coordinating SP. LAST_SEQ_NO_RECVD_FROM_PEER_RSP Response to LAST_SEQ_NO_RECVD_FROM_PEER_REQ. AS_STATE_CHANGE_IND Kaul [Page 14] Internet Draft Inter Signaling Process Communication Dec 2001 An SGP informs all the coordinating SGPs about the AS state change in it. AS_STATE_REQ An SGP requests for the AS state to a coordinating SGP. AS_STATE_RSP Response to AS_STATE_REQ. DPC_STATE_CHANGE_IND An ASP informs all the coordinating ASPs about the state change of a DPC through an SG. If this DPC state change is due to DUNA/DAVA/SCON/DRST etc., then state of the DPC is changed in the AS. If the DPC state change is due to the ASP becoming INACTIVE/DOWN in the SG then the state change is marked only for that particular ASP. DPC_STATE_REQ An ASP requests for the DPC state to a coordinating ASP. DPC_STATE_RSP Response to DPC_STATE_REQ. DATA_FORWARD_REQ An SP requests another coordinating SP to send traffic on its behalf to the remote logical entity. DATA_RETR_REQ An SP requests a coordinating SP to return all its data messages. 4. Support from SIGTRAN UA Protocols 4.1 Parameters required in DATA Messages Some parameters are required to be added in the DATA messages in order to support inter SP communication. The parameters required are described in the following sub sections. These parameters are required to be present as TLV's in the DATA messages. Gupta [Page 15] Internet Draft Inter Signaling Process Communication Dec 2001 4.1.1 Sequence Number Sequence number TLV is required to be attached to each of the DATA message. A Sequence number should be maintained for each pair of Logical Entities (SG and AS). 4.1.2 SP ID The SP ID of the SP from which message has originated is also required in the DATA messages. This ID should uniquely identify an SP. This TLV will help the peer SP in maintaining the sequence number of the last DATA message from the originating SP. If message forwarding takes place between coordinating SPs then the SP ID of the SP which forwarded the message to another coordinating SP should be present in the DATA message. For example if SGP1 is unable to send DATA to AS1 and SGP2 has AS1 ACTIVE, then messages forwarded from SGP1 to SGP2 will have ID of SGP1 in them. 4.2 Messages Required in SIGTRAN UA protocols Messages are required to be exchanged between the SPs of peer logical entities. These messages are used to exchange Sequence numbers which is explained earlier in the draft. These messages are explained below with parameters. These messages can be sent as normal SIGTRAN UA messages. LAST_SEQ_NO_REQ This message is sent by a SP to a peer SP to retrieve the sequence number of the last data message of a coordinating SP from the peer logical entity. Parameters required in this message are: Local SP ID of the SP for which sequence number is requested Routing Context of the AS (optional) Kaul [Page 16] Internet Draft Inter Signaling Process Communication Dec 2001 LAST_SEQ_NO_RSP This message is sent in response to LAST_SEQ_NO_REQ. The parameters for this message are: SP ID of the SP for which sequence number was requested Sequence Number with SP ID of the SP at the receiving end, this parameter may be present multiple times. 5. Example of Inter SP Coordination Consider an SG with two SGPs and AS with two ASPs as depicted below in the figure. All the Associations are ACTIVE. +---------------+ +---------------+ | SG1 | | AS1 | | +-----------+ | | +-----------+ | | | SGP1 |-+------------------+-| ASP1 | | | | |-+---------- | | | | | +-----------+ | | | +-----------+ | | | | | | | +-----------+ | | | +-----------+ | | | SGP2 | | |--------+-| ASP2 | | | | |-+------------------+-| | | | +-----------+ | | +-----------+ | | | | | +---------------+ +---------------+ Now AS1 becomes DOWN in the SGP1. Now following sequence of events will take place: 1) SGP1->SGP2: AS_STATE_REQ 2) SGP2->SGP1: AS_STATE_RSP, If AS state is ACTIVE, then, 3) SGP1->SGP2: RETR_LAST_SEQ_NO_FROM_PEER_REQ 4) SGP2->ASP2: LAST_SEQ_NO_REQ with SP ID of SGP1 5) ASP2->ASP1: LAST_SEQ_NO_RECVD_FROM_PEER_REQ for SGP1 6) ASP1->ASP2: LAST_SEQ_NO_RECVD_FROM_PEER_RSP 7) ASP2->SGP2: LAST_SEQ_NO_RSP 8) SGP2->SGP1: RETR_LAST_SEQ_NO_FROM_PEER_RSP 9) SGP1->SGP2: DATA_FORWARD_REQ 10) SGP2->ASP2: DATA Gupta [Page 17] Internet Draft Inter Signaling Process Communication Dec 2001 Now AS1 (ASP1) again becomes ACTIVE in the SGP1. Following sequence of events will take place: 1) SGP1->ASP1: LAST_SEQ_NO_REQ with SP ID of SGP1 2) ASP1->ASP2: LAST_SEQ_NO_RECVD_FROM_PEER_REQ 3) ASP2->ASP1: LAST_SEQ_NO_RECVD_FROM_PEER_RSP 4) ASP1->SGP1: LAST_SEQ_NO_RSP 5) SGP1->ASP1: DATA Consider all the Associations are ACTIVE. Now due to some local failure in the ASP1, SG1 becomes unreachable for ASP1. All the point codes are now unreachable through ASP1. Now following sequence of events will take place: 1) ASP1->ASP2: DPC_STATE_REQ 2) ASP2->ASP1: DPC_STATE_RSP, If DPC state is AVAILABLE, then, 3) ASP1->ASP2: RETR_LAST_SEQ_NO_FROM_PEER_REQ 4) ASP2->SGP2: LAST_SEQ_NO_REQ with SP ID of ASP1 5) SGP2->SGP1: LAST_SEQ_NO_RECVD_FROM_PEER_REQ for ASP1 6) SGP1->SGP2: LAST_SEQ_NO_RECVD_FROM_PEER_RSP 7) SGP2->ASP2: LAST_SEQ_NO_RSP 8) ASP2->ASP1: RETR_LAST_SEQ_NO_FROM_PEER_RSP 9) ASP1->ASP2: DATA_FORWARD_REQ 10) ASP2->SGP2: DATA Now SG1 again becomes available to ASP1, then the following sequence of events will take place: 1) ASP1->SGP1: LAST_SEQ_NO_REQ with SP ID of ASP1 2) SGP1->SGP2: LAST_SEQ_NO_RECVD_FROM_PEER_REQ for ASP1 3) SGP2->SGP1: LAST_SEQ_NO_RECVD_FROM_PEER_RSP 4) SGP1->ASP1: LAST_SEQ_NO_RSP 5) ASP1->SGP1: DATA Kaul [Page 18] Internet Draft Inter Signaling Process Communication Dec 2001 6. Acknowledgements The authors are grateful to: Dipak Aggarwal for motivating the authors to write this draft Sandeep Mahajan and Anshoo Sharma for providing valuable comments and suggestions. R.C.Monee and Harsh Bhondwe for providing all the required resources and support. 7. References [1] RFC 2719, "Framework Architecture for Signaling Transport", L. Ong [2] RFC 2960, "Stream Control Transport Protocol", R. Stewart et al, October 2000. [3] RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. [4] , "MTP2-User Adaptation Layer", K. Morneault et al, Sept 2001 8. Author's Addresses Vipin Gupta vkgupta@hss.hns.com Hughes Software Systems Plot 31 Sector 18 Electronic City Gurgaon Haryana India 122015 Kamesh Kaul kakaul@hss.hns.com Hughes Software Systems Plot 31 Sector 18 Electronic City Gurgaon Haryana India 122015 Gupta [Page 19]