Network Working Group Brian Bidulock INTERNET DRAFT OpenSS7 Corporation Tolga Asveren SS8 Networks Inc. Expires in six months September 04, 2002 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 Bidulock/Asveren 1 Bidulock/Asveren Internet Draft M3UA SG-SG Communication September, 2002 This Internet-Draft describes a protocol to support communication of M3UA[2] 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 Possible Uses of SG-SG Communication . . . . . . . . 4 2. Functional Areas. . . . . . . . . . . . . . . . . . . . . 6 2.1 Signalling Point Code Representation . . . . . . . . 6 2.2 Routing Context and Routing Keys . . . . . . . . . . 6 2.3 Network Appearance . . . . . . . . . . . . . . . . . 6 2.4 SCTP Association Establishment . . . . . . . . . . . 6 2.5 Point Code Status Information Exchange . . . . . . . 7 2.6 Message Distribution . . . . . . . . . . . . . . . . 7 2.7 Congestion Handling. . . . . . . . . . . . . . . . . 8 2.8 Restricted Destinations. . . . . . . . . . . . . . . 8 3. Message Types and Parameters. . . . . . . . . . . . . . . 8 4. Protocol Messages . . . . . . . . . . . . . . . . . . . . 8 4.1 Destination User Part Unavailable Message. . . . . . 8 4.2 Signalling Congestion. . . . . . . . . . . . . . . . 9 4.3 Congestion Test Message. . . . . . . . . . . . . . . 9 4.4 Changeover Mechanism Related Messages. . . . . . . . 11 4.4.1 Changeover Request Message. . . . . . . . . . 11 4.4.2 Changeover Request Acknowledgement Message. . 12 5. Examples. . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1 M3UA Availability Declaration. . . . . . . . . . . . 14 5.2 PC Status Announcement . . . . . . . . . . . . . . . 13 6. Security. . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements. . . . . . . . . . . . . . . . . . . . . 15 8. References. . . . . . . . . . . . . . . . . . . . . . . . 15 7.1 Normative References . . . . . . . . . . . . . . . . 15 7.2 Informative References . . . . . . . . . . . . . . . 15 9. Author's Addresses. . . . . . . . . . . . . . . . . . . . 15 1. Introduction 1.1. Scope This Internet-Draft describes a protocol to support communication of M3UA SGs in IP domain. The additional functionality, which is necessary for such nodes to act as relay nodes between SS7 entities is also addressed. 2 Bidulock/Asveren Internet Draft M3UA SG-SG Communication September, 2002 1.2. Terminology SG-SG communication draft uses the terminology used in the M3UA RFC[..] 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 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 [3]. 1.4. Overview The purpose of SG-SG protocol is to increase intra-IP communication capabilities of M3UA peers and to allow SS7 signalling backhauling between SS7 nodes over IP. ----- ----- // \\ // \\ | ASP | | ASP | | Cloud 1| | Cloud 2| \\ // \\ // --+-- --+-- | | | | +--+--+ +--+--+ | SG1 +------------+ SG2 | +--+--+ +--+--+ | | | | | | | +-----+ | +-----+ SG3 +------+ +--+--+ | | --+-- // \\ | ASP | | Cloud 2| \\ // ----- 3 Bidulock/Asveren Internet Draft M3UA SG-SG Communication September, 2002 Figure 1. Intra-IP communication using SG-SG communication In the configuration in Figure 1 SGs act as transfer points between ASP clouds. Their functionality is similar to the STP functionality in SS7 network. The communication between ASPs and SGs is as defined in M3UA protocol. +---------+ +---------+ | SG1 +--------------+ SG2 | +----+----+ +----+----+ | | | | +----+----+ +----+----+ |SS7 node1| |SS7 node2| +---------+ +---------+ Figure 2. SS7 signalling backhauling using SG-SG communication In the configuration in Figure 2 SGs act as relay points for SS7 nodes. 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. 1.5 Possible Uses of SG-SG Communication Below, some cases, where SG-SG communication might be used is given. 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 | 4 Bidulock/Asveren Internet Draft M3UA SG-SG Communication September, 2002 | Operator1 +----------+ Operator2 | +------------+ +------------+ Figure 3. 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 CIC=0-100 CIC=101-200 +--------+ +--------+ +--------+ +--------+ | | | | | | | | | ASP1 | | ASP2 | | ASP3 | | ASP4 | +-------++ +-+------+ +-------++ +-+------+ | | | | | | | | ++-----+-+ +-+----+-+ | | | | | SG1 +--------------------+ SG2 | +--------+ +--------+ Figure 4. Asymmetric Traffic Ranges with SG-SG communication To build hybrid networks: 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, SG4 functions both as IP-STP and IP-SEP. +--------+ +--------+ +--------+ | ASP1 | | ASP10 | | SS7 | | | | | | node4 |----+ +---+----+ ..... +-+------+ +--------+ | | | | +--+ +-----+ +--------+ | | | | SS7 +--+ | ++------++ | node5 | | +-------+ SG3 | +--------+ +---------+ | +----+-+-+ | | | | +--------+ | | |SS7 User| | | |Parts | +--------+ | | +--------+ +--------+ | SS7 | | | | SG4 | | ASP11 | 5 Bidulock/Asveren Internet Draft M3UA SG-SG Communication September, 2002 +-----+ node3 +------+ | | +------+ | | +--------+ | +---+----+ +--------+ | | | | | | | | +-------+ | | | +--+-----+ | +---+----+ | SG1 | +--------------+ SG2 | | +--------------------------------+ | +--+-----+ +---+----+ | | | | | | +--+-----+ +---+----+ | SS7 | | SS7 | | node1 | | node2 | +--------+ +--------+ Figure 5. 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 RFC. 2.4 SCTP Association Establishment There is no client/server relationship between SGs. 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 SGs are allowed to have more than one SCTP association between them, such a configuration is NOT RECOMMENDED. 6 Bidulock/Asveren Internet Draft M3UA SG-SG Communication September, 2002 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. 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 sent to the same SGP. In case, the destination to which messages are to be sent changes (failover, new active SGP etc...), Timer Procedure as described in CORID[3] draft (1.4.1.4. SPP Restoring Traffic) SHOULD be followed, to decrease possibility of missequencing. 7 Bidulock/Asveren Internet Draft M3UA SG-SG Communication September, 2002 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. By following those procedures, SCON instead of TFC and CGT instead of RCT MUST be used. 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 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 | 8 Bidulock/Asveren Internet Draft M3UA SG-SG Communication September, 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 Bidulock/Asveren Internet Draft M3UA SG-SG Communication September, 2002 | Tag = 0x0200 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. 10 Bidulock/Asveren Internet Draft M3UA SG-SG Communication September, 2002 4.4 Changeover Mechanism Related Messages 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 6. 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) 11 Bidulock/Asveren Internet Draft M3UA SG-SG Communication September, 2002 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 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: 12 Bidulock/Asveren Internet Draft M3UA SG-SG Communication September, 2002 Network Appearance: 32 bit (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 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. Examples of SG-SG communication procedures 5.1 M3UA availability declaration In the following scenario, SG1 consists of SGP1/SGP2 and SG2 consists of SGP3/SGP4. ASPUP/ASPUP- SGP1 SGP2 SGP3 SGP4 | | | | +------ASPUP----------->| | | | | | +------ASPUP------------+------->| | | | | |<-----ASPUP-ACK--------| | | | | | |<-----ASPUP------------+--------| | | | | |<-----ASPUP-ACK--------+--------| | | | | |------ASPUP-ACK--------+------->| | | | | 13 Bidulock/Asveren Internet Draft M3UA SG-SG Communication September, 2002 |<-----ASPUP------------| | | | | | |------ASPUP-ACK------->| | | | | | |------ASPUP------------+------->| | | | | |<-----ASPUP-ACK--------+--------| | | | | | | | | 5.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)------>| | | | | | |-------DRST(PC2)------>| | | | | | |-------ASPAC---------->| | | | | | |<------DATA(PC3)-------+--------| | | | | | |<---DUNA(PC4)-| | | | | | | |<---ASPAC-----| | | | | | |--------+-DATA(PC5)----+------->| | | | | | | | | | | | | 6. 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 14 Bidulock/Asveren Internet Draft M3UA SG-SG Communication September, 2002 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. 7. Acknowledgements The authors would like to thank Manfred Angermayr, Javier Pastor- Balbas, Vaibhav Madan and Kutluk Uslu for their valuable comments and suggestions. 8. References 8.1 Normative References [1] ITU-T Recommendation Q.704 "Specifications of Signalling System No. 7 - Message transfer part Signalling network functions and messages" [2] RFC[..] "SS7 MTP3 - User Adaptation Layer (M3UA)" [3] draft-bidulock-sigtran-corid-00.txt "Correlation Id and Heartbeat Procedures (CORID) Supporting Lossless Fail-Over between SCTP Associations for Signalling User Adaptation Layers" 8.2 Informative References [4] RFC[2119] "Key words for use in RFCs to Indicate Requirement Levels" 9. Author's Addresses Brian Bidulock OpenSS7 Corporation 1469 Jeffreys Crescent Edmonton, AB T6L 6T1 EMail : bidulock@openss7.org Tolga Asveren SS8 Networks Inc. 2 Enterprise Drive Shelton, CT USA 06484 Email : tolga.asveren@ss8.com 15