Network Working Group Tolga Asveren INTERNET DRAFT Oksijen Teknoloji Brian Bidulock OpenSS7 Corporation Expires: July 27, 2003 January 27, 2003 M3UA SG-SG 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 accesse 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). Abstract Asveren/Bidulock 1 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 This Internet-Draft describes a protocol to support communication of M3UA[1] based SGs over IP. The additional functionality needed by SGs to act as relay points between SS7 nodes is also addressed. TABLE OF CONTENTS 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Scope. . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Terminology. . . . . . . . . . . . . . . . . . . . . 3 1.3 Conventions. . . . . . . . . . . . . . . . . . . . . 3 1.4 Overview . . . . . . . . . . . . . . . . . . . . . . 3 1.5 Architecture . . . . . . . . . . . . . . . . . . . . 5 1.6 Possible Uses of SG-SG Communication . . . . . . . . 4 2. Functional Areas. . . . . . . . . . . . . . . . . . . . . 7 2.1 Signalling Point Code Representation . . . . . . . . 7 2.2 Routing Context and Routing Keys . . . . . . . . . . 7 2.3 Network Appearance . . . . . . . . . . . . . . . . . 7 2.4 SCTP Association Establishment . . . . . . . . . . . 8 2.5 Point Code Status Information Exchange . . . . . . . 8 2.6 Message Distribution . . . . . . . . . . . . . . . . 8 2.7 Congestion Handling. . . . . . . . . . . . . . . . . 9 2.8 Restricted Destinations. . . . . . . . . . . . . . . 9 3. Message Types and Parameters. . . . . . . . . . . . . . . 9 4. Protocol Messages . . . . . . . . . . . . . . . . . . . . 9 4.1 Destination User Part Unavailable Message. . . . . . 10 4.2 Signalling Congestion. . . . . . . . . . . . . . . . 10 4.3 Congestion Test Message. . . . . . . . . . . . . . . 11 4.4 Changeover Mechanism Related Messages. . . . . . . . 12 4.4.1 Changeover Request Message. . . . . . . . . . 13 4.4.2 Changeover Request Acknowledgement Message. . 14 5. SG and SGP State Machines . . . . . . . . . . . . . . . . 15 5.1 SGP State Machine. . . . . . . . . . . . . . . . . . 15 5.2 SG State Machine . . . . . . . . . . . . . . . . . . 16 6. Examples. . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1 M3UA Availability Declaration. . . . . . . . . . . . 17 6.2 PC Status Announcement . . . . . . . . . . . . . . . 17 7. Security. . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . 18 9. References. . . . . . . . . . . . . . . . . . . . . . . . 18 9.1 Normative References . . . . . . . . . . . . . . . . 18 9.2 Informative References . . . . . . . . . . . . . . . 19 10. Author's Addresses . . . . . . . . . . . . . . . . . . . 19 1. Introduction 1.1. Scope M3UA does not have relaying capability between PCs. This might be necessary to build hybrid networks, where some part of the signaling 2 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 transport is TDM based and some part of it IP based. Relaying might be also desirable for redundancy purposes and to have a hierarchy in the network based on SS7 constructs. M2PA[2] provides a way to achieve relaying but it includes MTP2[3] procedures on top of SCTP[4] and emulates SS7 links in IP domain. An alternative approach is defined in this document: relaying with a layer3 peer-to-peer model, without the burden of layer2 procedures and within the M3UA procedure with some additional messages and procedures. For ASP/SGP relationship as defined in M3UA, SPMC logic and user parts for a PC reside on different nodes, and communication between them is defined mainly based on MTP3/MTP3[5] User relationship. This brings some difficulties for modelling and implementation, when SG acts as STP(non-backhaul scenarios), i.e. when PC boundary is crossed between SG and ASP. SG-SG communication is based on MTP3/MTP3 communication and supports such scenarios in a similar way as MTP3 does in conventional SS7 network. SG-SG communication as defined in this document does also provide a method for direct communication between M3UA nodes in IP domain, where again user part and layer3 logic are provided by the same entity. In general, when PC boundaries are crossed, providing layer3 logic on the same side of the relationship with user parts also provides an easy way to make a MTP3 stack to support M3UA SG-SG mode of communication, where some of the routes are using IP based communication instead of SS7 links. 1.2. Terminology SG-SG communication draft uses the terminology used in the M3UA RFC[3332] with the following additions: COA Changeover Acknowledgement MTP3 message COO Changeover Order MTP3 message ECA Emergency changeover acknowledgement MTP3 message ECM Emergency changeover MTP3 message IP-SP IP Signalling Point RCT Signalling route set congestion test MTP3 message TFC Transferred controlled MTP3 message 1.3. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [6]. 1.4. Overview 3 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 The purpose of SG-SG protocol is to increase IP domain communication capabilities of M3UA peers and to allow SS7 signalling backhauling between SS7 nodes over IP with M3UA protocol. ----- ----- // \\ // \\ | SPMC | | SPMC | | Cloud 1| | Cloud 2| \\ // \\ // --+-- --+-- | | | | +--+--+ +--+--+ | SG1 +------------+ SG2 | +--+--+ +--+--+ | | | | | | | +-----+ | +-----+ SG3 +------+ +--+--+ | | --+-- // \\ | SPMC | | Cloud 3 \\ // ----- Figure 1. Intra-IP communication using SG-SG communication In the configuration in Figure 1 SGs act as transfer points between SPMC clouds. Their functionality is similar to the STP functionality in SS7 network. The communication between ASPs and SGs is as defined in M3UA protocol. It should be noted that a SG can also support a local SPMC, i.e. it MAY have user parts running on it, instead of on an ASP. +---------+ +---------+ | SG1 +--------------+ SG2 | +----+----+ +----+----+ | | | | +----+----+ +----+----+ |SS7 node1| |SS7 node2| +---------+ +---------+ Figure 2. SS7 signalling backhauling using SG-SG communication 4 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 In the configuration in Figure 2 SGs act as relay points for SS7 nodes. 1.5 Architecture The goal of SG-SG communication is to define a peer-to-peer relationship between two M3UA IP domain entities, which can be used both for direct communication and for relaying. For that reason SG- SG communication model tries to mimic the relationship of two signaling points in traditional SS7 network. This allows inheritance of necessary MTP3[2] procedures without any modelling problems, to modify a MTP3 stack easily to make it work also as a M3UA SG and a smooth migration from TDM based communication to IP based communication for SS7 networks. In fact, in the context of SG-SG communication, SGs can be thought as IP Signalling Points(IP-SP). All of the SPMC(layer3) logic resides in the local node, which provides a well defined peer-to- peer model, without relying to a remote SPMC control entity for local procedures. It should be noted that user parts for a specific SPMC MAY reside on the same node with SG itself, or MAY be distributed across remote nodes, where relationship between those nodes and the controlling SG MAY be implementation dependent or MAY be based on the ASP/SGP relationship as defined in M3UA. SGs MAY also not control any SPMC directly and act only as relay points. SG-SG communication management is based mainly on SSNM as defined in M3UA protocol, with some additional messages to handle changeover and congestion as defined in MTP3. Communication of peers is in PC granularity. Each SG MAY consist of multiple SGPs. It should be noted, that all layer3 logic(both for SPMCs directly controlled and for remote PCs) functions as a single entity in the whole SG. SG ************************************ * +------------------------------+ * * | Layer3 Logic | * * +----+---+----+---+----+--+----+ * * |SGP1| |SGP2| |SGP3| |SGP4| * * +-+--+ +-+--+ +-+--+ ++---+ * ************************************ | | | | Figure 3. SG with single Layer3 Logic and with multiple SGs 1.6 Possible Uses of SG-SG Communication Below, some cases, where SG-SG communication might be used is given. 5 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 As gateway between networks of different operators: It is likely that operators would prefer to centralize interaction of their network with networks of other operators for reasons like security, management transparency, different protocols used in different networks etc... Using concentration nodes instead of a fully mesh network also reduces number of necessary SCTP associations. ----- ----- //// \\\\ //// \\\\ | Network of | | Network of | | Operator1 | | Operator2 | | | | | | | | | \\\\ //// \\\\ //// --+-- --+-- | | | | +-----+------+ +-------+----+ | SG of | | SG of | | Operator1 +----------+ Operator2 | +------------+ +------------+ Figure 4. Interaction of two networks via SG-SG communication To allow asymmetric Routekeys: In large networks and especially when multiple operators are present, it might be desirable to have asymmetric traffic ranges at the endpoints and to limit impact of configuration changes at endpoints to as few other nodes as possible. For example in the example below, endpoints are using routing keys in different granularities and changing traffic ranges will require configuration changes only on the SGs, reconfigured ASP is directly connected to. AS1: AS2: AS3: AS4: DPC=1-1-1 DPC=1-1-1 DPC=2-2-2 DPC=3-3-3 SI=3 SI=5 +--------+ +--------+ +--------+ +--------+ | | | | | | | | | ASP1 | | ASP2 | | ASP3 | | ASP4 | +-------++ +-+------+ +-------++ +-+------+ | | | | | | | | ++-----+-+ +-+----+-+ | | | | | SG1 +--------------------+ SG2 | +--------+ +--------+ Figure 5. Asymmetric Traffic Ranges with SG-SG communication To build hybrid networks: 6 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 SG-SG communication might be utilized to build networks, where TDM and IP based transport of messages is used in a mixed way. It should be noted that SGs can act as IP-STPs and/or IP-SEPs. For example in Figure 5 below, SG3 acts as IP-SEP. +------+ |SS7 | |User | |Parts | +------+ +------+ +------+ | ASP1 | | SG3 | |SS7 | | | | | |node3 | +---+--+ +-+--+-+ +---:--+ | | | : | | | : +------+ | | | : | ASP2 | +---+--+ | | +---:--+ +--+ | | SG1 +----------+ +----------+ SG2 +---+ +------+ | +------------------------+ +---+ +------+ +--:---+ +---:--+ | | ASP3 | : : +--+ | : : +------+ +--:---+ +---:--+ |SS7 | |SS7 | |node1 | |node2 | +------+ +------+ --------- IP based communication .. .. .. TDM based communication Figure 6. Hybrid network configuration with SG-SG communication 2. Functional Areas 2.1 Signalling Point Code Representation SGs should control SPMCs as a whole. When a SPMC becomes unavailable, SG will broadcast DUNA to all SGs, it has an association with. Similarly when a SPMC becomes available DAVA and when a SPMC becomes restricted DRST will be sent. 2.2 Routing Context and Routing Keys Unlike M3UA, there is no Routing Context/Routing Key concept present in SG-SG communication. 2.3 Network Appearance NA is used in the messages as described in M3UA. 7 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 2.4 SCTP Association Establishment There is no client/server relationship between SGPs. SCTP associations might be initiated from any side. A collision, which might happen if both sides try to establish SCTP association concurrently, is handled by the SCTP protocol itself. Although SGPs are allowed to have more than one SCTP association between them, such a configuration is NOT RECOMMENDED, as SCTP multihoming provides a better way to achieve redundancy in a transparent way to upper layers with no message loss/duplication and missequencing. 2.5 Point Code Status Information Exchange After a SCTP association is established, peers SHOULD declare the availability of their M3UA layer with ASPUP messages. A received ASPUP message is replied with ASPUP-ACK. If one of the peers receives ASPUP message before sending ASPUP, it MAY or MAY NOT send ASPUP message, ASPUP-ACK message declares availability of the remote peer. Each SGP should declare its availability to each SGP of the remote SGs separately. A SGP can declare its unavailability with ASPDN message. ASPDN message is acknowledged with ASPDN-ACK message. After availability of M3UA layers is confirmed, SGs will exchange SSNM to update the remote peer about the status of the PCs, which are configured as reachable on them. Unless a corresponding message is received, all configured PCs are assumed as accessible via the remote peer. Each SG will send DUNA for unavailable PCs and DRST for restricted PCs. The end of this unavailable/restricted PC announcement procedure is marked with an ASPAC message. Those SSNM are sent per SG. A SG SHOULD NOT start sending DATA to a peer, unless ASPAC is received. SSNM, which are sent for point code status information exchange procedure and ASPAC SHOULD be sent via stream 0, to prevent the remote peer to receive ASPAC before the last SSNM. 2.6 Message Distribution Data messages SHOULD be sent to SGs, via which the destination pointcode of the message to be sent is in available status. In case, when there is no such peer SG, message SHOULD be sent to SGs, from which the destination is declared as restricted. If no such SG exists, the message SHOULD be dropped. Message distribution among remote SGs is implementation dependent. 8 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 Message distribution method among SGPs belonging to the same SG can be either override or loadshare. Traffic Mode Type parameter in ASPAC shows the traffic distribution method expected by the sending SG, between SGPs belonging to it. If the receiver does not support this traffic distribution method, an Error message with Error Code "Unsupported Traffic Handling Mode" SHOULD be sent. In such a case, the SG, which initiated Error message SHOULD NOT send traffic to the peer SG. Messages, which require sequencing SHOULD be via the same SCTP association using the same stream. In case, the destination to which messages are to be sent changes (failover, new active SGP etc...), Timer Procedure as described in CORID[6] (1.4.1.4. SPP Restoring Traffic) SHOULD be followed, to decrease possibility of missequencing. 2.7 Congestion Handling Congestion handling procedures as defined in relevant MTP3 standards for signaling points should be followed between SGs. It is responsibility of a SG, to follow those procedures, on behalf of the SPMCs, that it directly controls. While following those procedures, SCON instead of TFC and CGT instead of RCT MUST be used, when the message needs to be sent to an adjacent node in IP domain. 2.8 Restricted Destinations When destinations in IP domain should be declared as restricted is implementation dependent. 3. Message Types and Parameters The following new message types are added to SSNM in addition to the ones defined in M3UA. 128 Congestion Test Message (CGT) 128 Changeover Request Message(COR) 129 Changeover Request Acknowledgement Message(CORA) The following parameters are added in addition to the ones defined in M3UA. Forward Sequence Number 0x0214 Signalling Link Code 0x0215 4. Protocol Messages Between SGs DATA and SSNM messages as defined in M3UA protocol are used. Error from MGMT, ASPUP/ASPUP-ACK from ASPSM and ASPAC from 9 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 ASPTM are also used. RC field in messages is not used,i.e. it MUST not be filled. 4.1 Destination User Part Unavailable (DUPU) A new field is introduced to DUPU. Concerned PC: Destination PC, which has caused DUPU to be generated. This parameter is mandatory. The format for DUPU message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0200 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0012 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask = 0 | Affected PC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0206 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Concerned DPC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0204 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause | User | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2 Signalling Congestion (SCON) For SG-SG communication, Concerned DPC parameter is mandatory. It contains the point code information for the signaling point, which originated the message causing SCON to be generated. In SG-SG communication, there will be two Affected PC fields present. The first one gives the PC of the originator of the SCON (or the corresponding TFC) message and the second one gives the PC for the congested destination. Those two Affected PC fields MUST be sent in this order. The format for SCON message parameters is as follows: 10 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0200 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0012 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Affected PC1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Affected PC2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0206 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Concerned DPC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0205 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Cong. Level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3 Congestion Test Message (CGT) CGT is used to support Signalling-route-set-congestion-test(National Option) procedures as defined in Q.704. It is used to test the congestion status of a PC via a specific SG. The CGT message contains the following parameters: Affected PC Mandatory Concerned DPC Mandatory Congestion Level Mandatory Info String Optional The format for CGT Message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0200 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | 11 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0012 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask | Affected PC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0206 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | Concerned DPC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0205 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Cong. Level | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Network Appearance: 32 bits (Semi-mandatory) See M3UA Section 3.1.1 Affected Point Code: 32 bits (Mandatory) Affected Point Code parameter contains the 14-, 16-, 24-bit binary formatted point code value, for which CGT message is generated. Concerned DPC: 32 bits (Mandatory) Concerned DPC parameter contains the 14-, 16-, 24-bit binary formatted point code value, whose congestion status is to be tested. Congestion Level: 8 bits (unsigned integer) (Mandatory) The Congestion Level parameter contains one of the following values: 0 No Congestion or Undefined 1 Congestion Level 1 2 Congestion Level 2 3 Congestion Level 3 The congestion levels are defined in the congestion method in the appropriate national MTP recommendations [. .]. When sending CGT message, procedures defined for Signalling-route- set-congestion-test in Q.704 Clause 13.9 should be followed. 4.4 Changeover Mechanism Related Messages 12 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 Those messages are necessary to support changeover mechanism as defined in MTP3. It should be noted that, they will be used, in case a SG is relaying corresponding MTP3 changeover messages to another SG. +-------+ +-------+ | SS7 | | SG2 | | node1 +--------X-------+ | COO(1)+---+---+ ^ +----+--+ CORA(3) | ^ | | | ^ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V | | | +-------+ | | V COA(4)| | | SG1 | | COR(2) +-----+-+ +---------+ ^ | +-------+ ^ | | | | | | | | | | | | TDM IP Figure 7. SG1 relaying changeover messages to and from SG2 4.4.1 Changeover Request Message(COR) COR is used to relay changeover order/emergency changeover order information to/from a SS7 peer. There are two scenarios, where it can be used. Either it is received from a peer SG, where a corresponding COO/ECM is sent to peer SS7 node or it can be generated to a peer SG, after receiving COO/ECM from a SS7 node. COR message contains the following parameters: Network Appearance: 32 bits (Semi-mandatory) See M3UA Section 3.1.1 SLC : 5 bits (Mandatory) The Signalling Link Code of the failed link. FSN : 24 bits (Semi-mandatory) Forwards sequence number of the last message signal unit accepted from the unavailable signaling link by the sender of message. If COR is received from a SG and if FSN is present a corresponding COO MUST be generated. If no FSN is present an ECM MUST be generated. When 13 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 COO is received from a SS7 peer, FSN MUST be filled in COR. When ECM is received from a SS7 peer, FSN MUST NOT be filled. Affected Point Code: 32 bits (Mandatory) Affected Point Code parameter contains the 14-, 16-, 24-bit binary formatted point code value, which has sent COO/ECM message. Concerned Point Code: 32 bits (Mandatory) Concerned Point Code parameter contains the 14-, 16-, 24-bit binary formatted point code value, to which COO/ECM message is sent. The format for COR message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0200 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0214 | Length =8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserve | FSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0215 | Length =8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | SLC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0012 | Length =8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Affected PC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0206 | Length =8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Concerned PC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.4.2 Changeover Request Acknowledgement Message (CORA) CORA is used to relay the FSN information regarding the last accepted MSUs by a failed link between a peer SG and a SS7 node as an answer to COR. COR message contains the following parameters: Network Appearance: 32 bit (Semi-mandatory) See M3UA Section 3.1.1 14 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 SLC : 5 bits (Mandatory) The Signalling Link Code of the failed link. FSN : 24 bits (Semi-mandatory) Forwards sequence number of the last message signal unit accepted from the unavailable signaling link by the sender of CORA. . If CORA is received from a SG and if FSN is present a corresponding COA MUST be generated. If no FSN is present an ECA MUST be generated. When COA is received from a SS7 peer, FSN MUST be filled in CORA. When ECA is received from a SS7 peer, FSN MUST NOT be filled. Affected Point Code: 32 bits (Mandatory) Affected Point Code parameter contains the 14-, 16-, 24-bit binary formatted point code value, to which the COA to be generated based on the received CORA, should be sent. Concerned Point Code: 32 bits (Mandatory) Concerned Point Code parameter contains the 14-, 16-, 24-bit binary formatted point code value, to which COO/ECM message is sent. The format for parameters for CORA is the same like COR. 5. SG and SGP state machines 5.1 SGP State Machine The state of each remote SGP is maintained in the M3UA layer in the SGP. The state of a particular SGP changes due to events. The events include: *Reception of messages from the peer M3UA layer at the SGP. *Reception of indications from the SCTP layer. *Local management intervention. The SGP state transition diagram is shown in Figure 8. The possible states of a SGP are: SGP-DOWN: The remote M3UA peer at the SGP is unavailable and/or the related SCTP association is down. Initially all SGPs will be in this state. An SGP in this state SHOULD NOT be sent any messages, with the exception of Heartbeat, ASP Down Ack and Error messages. SGP-UP: The remote M3UA peer at the SGP is available(and the related SCTP association is up). M3UA messages, which can be sent in this state are restricted only by SG state. 15 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 +--------+ |SGP UP | +-+----+-+ ASPUP/^ | ASPDOWN/ASPDOWN-ACK ASPUP-ACK | | SCTP CDI/SCTP RI | | | v +-+----+-+ |SGP DOWN| +--------+ Figure 8. SGP state machine 5.2 SG state machine The state of each remote SG is maintained in the SGP. SGPs belonging to the same SG MUST have a unique view of a remote SG. The state of a particular SG changes due to events. The events include: *Reception of messages from the peer SG. *State changes of local SGPs. *Local management intervention. The SG state transition diagram is shown in Figure 9. Possible states of SG are: SG DOWN: There is no SGP belonging to this SG in SGP UP state. Messages, which are not allowed in SGP DOWN state SHOULD NOT be sent to the SG. SG UP: There is at least one SGP belonging to this SG in SGP UP state, but PC status announcement phase is not completed yet. In this state no DATA messages SHOULD be sent to the remote SG. SG ACTIVE: There is at least one SGP belonging to this SG in ASP UP state and remote SG has finished PC announcement phase. DATA messages can be sent to the SG. +--------+ | SG | |ACTIVE +---+ +---+----+ | ^ | ASPAC | |Last SGP in SGP UP state from one| |transitions to SGP DOWN state SGP of SG | | +---+----+ | | SG | | | UP | | +-+-----++ | one SGP ^ | | transitions| |Last SGP in SGP UP state to SGP UP | |transitions to SGP DOWN state 16 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 state | | | | v | +-+-----++ | | SG +<--+ | DOWN | +--------+ Figure 9. SG state machine 6. Examples of SG-SG communication procedures 6.1 M3UA availability declaration In the following scenario, SG1 consists of SGP1/SGP2 and SG2 consists of SGP3/SGP4. After establishment of SCTP associations between SGPs, each SGP should make its peers aware that its own M3UA is ready. SGP1 SGP2 SGP3 SGP4 | | | | +------ASPUP----------->| | | | | | +------ASPUP------------+------->| | | | | |<-----ASPUP-ACK--------| | | | | | |<-----ASPUP------------+--------| | | | | |<-----ASPUP-ACK--------+--------| | | | | |------ASPUP-ACK--------+------->| | | | | |<-----ASPUP------------| | | | | | |------ASPUP-ACK------->| | | | | | |------ASPUP------------+------->| | | | | |<-----ASPUP-ACK--------+--------| | | | | | | | | 6.2 PC status announcement In the following scenario, SG1 consists of SGP1/SGP2 and SG2 consists of SGP3/SGP4. It shows the messages exchanged after M3UA availability declaration is finished. PC1/PC2/PC3 are declared as reachable via SG2 on SG1 and PC4/PC5 are declared as reachable via SG1 on SG2. SGP1 SGP2 SGP3 SGP4 | | | | |-------DUNA(PC1)------>| | | | | | 17 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 |-------DRST(PC2)------>| | | | | | |-------ASPAC---------->| | | | | | |<------DATA(PC3)-------+--------| | | | | | |<---DUNA(PC4)-| | | | | | | |<---ASPAC-----| | | | | | |--------+-DATA(PC5)----+------->| | | | | | | | | | | | | 7. Security SG-SG communication inherits security risks and considerations that are present in M3UA. Please see "Security" section of M3UA for those security considerations and recommendations. Because SG-SG communication introduces relaying capability and can be placed at network boundaries of networks belonging to different operators, additional security might be desirable. Since SS7 related outages are very costly and increased interconnections between TDM and IP domain make SS7 network more vulnerable to intentional and/or accidental disturbances, it is advisable for SGs to have capability to screen and act on SS7 messages going through it. For example, screening of messages can be made based on configurable lists of OPC, DPC, SIO values or any combination of them. Possible actions that are taken upon detection of disturbances could be informing network management entities, generation of alarms, discarding messages, modification of messages, generation of new messages or a combination of them. Other more sophisticated message syntax, message type and content screening could also be implemented to improve security. 8. Acknowledgements The authors would like to thank Manfred Angermayr, Javier Pastor- Balbas, Vaibhav Madan and Kutluk Uslu for their valuable comments and suggestions. 9. References 9.1 Normative References [1] RFC[3332] "Signalling System7 (SS7) Message Transfer Part3(MTP3) User Adaptation Layer(M3UA)" 18 Asveren/Bidulock Internet Draft M3UA SG-SG Communication January, 2003 [2] RFC[abcd] "SS7 MTP2-User Peer-to-Peer Adaptation Layer" [3] ITU-T Recommendation Q.703 "Specifications of Signalling System No. 7 û Message transfer part, Signalling link" [4] RFC[2960] "Stream Control Transmission Protocol" [5] ITU-T Recommendation Q.704 "Specifications of Signalling System No. 7 - Message transfer part Signalling network functions and messages" [6] draft-bidulock-sigtran-corid-00.txt "Correlation Id and Heartbeat Procedures (CORID) Supporting Lossless Fail-Over between SCTP Associations for Signalling User Adaptation Layers" 9.2 Informative References [7] RFC[2119] "Key words for use in RFCs to Indicate Requirement Levels" 10. Author's Addresses Tolga Asveren Oksijen Teknoloji Dunya Ticaret Merkezi A1 Istanbul, Turkey Email : tolga.asveren@o2.com.tr Brian Bidulock OpenSS7 Corporation 1469 Jeffreys Crescent Edmonton, AB T6L 6T1 EMail : bidulock@openss7.org Expires: July 27, 2003 19