Network Working Group T. Asveren Internet-Draft Ulticom Inc. Expires: June 3, 2006 B. Bidulock OpenSS7 Corporation J. Pastor-Balbas Ericsson Espana S.A. November 30, 2005 M3UA SG-SG Communication draft-asveren-sigtran-m3uasgsg-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on June 3, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a protocol to support the communication between M3UA SGs in IP domain. The functionality needed by SGs to act as relay points between SS7 nodes is also addressed. Asveren, et al. Expires June 3, 2006 [Page 1] Internet-Draft M3UA SG-SG Communication November 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 3 2. Functional Areas . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Signaling Point Code Representation . . . . . . . . . . . 4 2.2. Routing Keys and Routing Context . . . . . . . . . . . . . 4 2.3. Network Appearence . . . . . . . . . . . . . . . . . . . . 4 2.4. SCTP Associations . . . . . . . . . . . . . . . . . . . . 5 2.5. Communication Initiation . . . . . . . . . . . . . . . . . 5 2.6. Message Distribution . . . . . . . . . . . . . . . . . . . 5 2.7. Congestion Handling . . . . . . . . . . . . . . . . . . . 6 2.8. Restricted Destinations . . . . . . . . . . . . . . . . . 6 3. Message Types and Parameters . . . . . . . . . . . . . . . . . 6 4. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Destiantion User Part Available(DUPU) . . . . . . . . . . 7 4.2. Signaling Congestion (SCON) . . . . . . . . . . . . . . . 7 4.3. Congestion Test Message (CGT) . . . . . . . . . . . . . . 8 4.4. Changeover Mechanism Related Messages . . . . . . . . . . 10 4.4.1. Changeover Request Message (COR) . . . . . . . . . . . 10 4.4.2. Changeover Request Acknowledgement Message (CORA) . . 11 5. SG and SGP State Machines . . . . . . . . . . . . . . . . . . 12 5.1. SGP State Machine . . . . . . . . . . . . . . . . . . . . 12 5.2. SG State Machine . . . . . . . . . . . . . . . . . . . . . 13 6. Management Procedures . . . . . . . . . . . . . . . . . . . . 14 6.1. ASPUP Procedures . . . . . . . . . . . . . . . . . . . . . 14 6.2. ASP Down Procedures . . . . . . . . . . . . . . . . . . . 15 6.3. ASP Active Procedures . . . . . . . . . . . . . . . . . . 15 7. Examples of SG-SG Communication Procedures . . . . . . . . . . 15 7.1. M3UA Availability Declaration . . . . . . . . . . . . . . 15 7.2. PC Status Announcement . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 11. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Asveren, et al. Expires June 3, 2006 [Page 2] Internet-Draft M3UA SG-SG Communication November 2005 1. Introduction This document describes a protocol to support the communication between M3UA[1] SGs in IP domain. 1.1. Terminology This document uses the terminology in RFC3332 [1] 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 Relaying Relaying is used throughout this document with the meaning of providing transfering functionality for messages, which are not destined for the own PC, like a STP does in SS7 network. TFC Transfer Controlled MTP3 message 1.2. Scope This document defines a communication mechanism between M3UA SGs. The main motivation for such a mechanism is allowing message relaying on SGs. This relaying could happen between two nodes in TDM based domain, between two nodes in IP based domain or between a node in TDM based domain and a node in IP based domain. M3UA SG-SG communication could be utilized for different reasons: o To offload SS7 traffic over IP network o To replace TDM based C-links between two SGs o To build a hierarchical network topology for easier provisioning o To provode security gateway functionality between different administrative domains ( ) ( ) ( SS7 ) +-----+ +-----+ ( SS7 ) ( segment )---+ SG1 +----+ SG2 +---( segment ) ( 1 ) +-----+ +-----+ ( 2 ) ( ) ( ) Figure 1. Connecting two SS7 segments with SG-SG communication 1.3. Architecture The goal of SG-SG communication is to define a peer-to-peer relationship between two M3UA IP doamin entities, which can be used both for direct communication and for message relaying. For that reason SG-SG communication model mimics the relationship between two Asveren, et al. Expires June 3, 2006 [Page 3] Internet-Draft M3UA SG-SG Communication November 2005 MTP3[3] signaling points. This allows inheritance of necessary MTP3 procedures without any modeling problems. In the context of SG-SG communication, a SG MAY be controlling one or more SPMCs. 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 controling SG MAY be based on the ASP/SGP realtionship as defined by M3UA or MAY be implementation dependent. SG-SG communication management is based mainly on SSNM as defined in M3UA. Communication of peers is in PC granularity. Each SG MAY consist of multiple SGPs. It should be noted that all MTP3 related logic for own PC, for SPMCs directly connected and for remote PCs function as a signle entity in the whole SG. SG ************************************ * +------------------------------+ * * | MTP3 Logic | * * +----+---+----+---+----+--+----+ * * |SGP1| |SGP2| |SGP3| |SGP4| * * +----+ +----+ +----+ +----+ * ************************************ | | | | Figure 2. SG consisting of multiple SGPs 2. Functional Areas 2.1. Signaling Point Code Representation If a SG controls a SPMC, it SHOULD control it as a whole. When a SPMC becomes available, SG will broadcast DAVA to all adjacent SGs. Similarly when a SPMC becomes unavailable DUNA and when SPMC becomes restricted DRST SHOULD be sent. 2.2. Routing Keys and Routing Context There is no Routing Context/Routing Key concept present in SG-SG communication. 2.3. Network Appearence Network Appearence is used in the messages as described in M3UA. Asveren, et al. Expires June 3, 2006 [Page 4] Internet-Draft M3UA SG-SG Communication November 2005 2.4. SCTP Associations SCTP[2] with multihoming feature MUST be used as transport protocol for SG-SG communication. There is no client/server relationship between SGPs. SCTP associations MAY be initiated by any SG. A collision, which might happen if both sides try to establish SCTP association concurrently is handled by SCTP protocol itself. Although SGPs are allowed to have more than one SCTP association between them, such a configuration is NOT RECOMMENDEDr, as SCTP multihoming provides an excellent way to achieve redundnacy in a trnsparent way to upper layers with no message loss/duplication/ missequencing. For that reason, equivalent of MTP3 changeover and changeback procedures are not defined for SG-SG communication. 2.5. Communication Initiation After a SCTP association is established, peers MUST declare the availability of their M3UA layer with ASPUP message. A received ASPUP is replied with ASPUP-ACK. If one peer receives ASPUP message before sending ASPUP, it MAY send ASPUP message. A received ASPUP or ASPUP-ACK message declares availability of the peer. A SGP can declare its unavailability with ASPDN message. ASPDN is acknowledged with ASPDN-ACK message. After the availability of M3UA layers is confirmed, SGs will exchange SSNM to update to update the remore peer about the status of 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 DUAN for unavailable PCs and DRST for restricted PCs. The end of this of this unavailable/restricted PC announcement is marked with an ASPAC message. A received ASPAC is replied wit an ASPAC-ACK message. SSNM and ASPAC/ASPAC-ACK are sent per SG. A SG SHOULD NOT start sending DATA messages to a peer, unless ASPAC and ASPAC-ACK are received. SSNM, which are sent for point code status information exchange procedure and ASPAC/ASPAC-ACK SHOULD be sent via stream 0, to prevent problems which may arise due to missequencing. 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. If there is no such peer SG, DATA messages SHOULD be sent to SGs, which declared the destination as restricted. If no such SG exists, the Asveren, et al. Expires June 3, 2006 [Page 5] Internet-Draft M3UA SG-SG Communication November 2005 message SHOULD be dropped. Message distribution among remote SGs is implementation dependent. Message distribution among SGPs belonging to the same SG is determined by the sender of the message. A SG SHOULD be preprared to receive messages by any of its SGPs in UP state. Messages, for which sequencing has to be preserved SHOULD be sent via the same SCTP association using the same stream. In case, the destination to which a certain group of messages changes ,e.g due to a new SGP becoming UP, procedures similiar to time- controlled diversion and time-controlled changeover as decribed by MTP3 SHOULD be followed to reduce the possibility of message missequencing. 2.7. Congestion Handling Congestion handling procedures as defined in relevant MTP3 standards SHOULD be followed. It is responsibility of a SG to follow those procedures on behalf of the SPMCs it 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 or via an adjacent SG. 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 defined as new SSNM in addition to existing ones in M3UA: 128 Congestion Test Message (CGT) 129 Changeover Request Message (COR) 130 Changeover Request Acknowledgement Message (CORA) The following parameters are added in addition to the ones defined in M3UA: Forward Sequence Number 0x0214 Signaling Link Code 0x0215 4. Protocol Messages Asveren, et al. Expires June 3, 2006 [Page 6] Internet-Draft M3UA SG-SG Communication November 2005 DATA, SSNM messages, ERROR, ASPUP/ASPUP-ACK, ASPAC/ASPAC-ACK messages are used for SG-SG communication. RC field in the messages is not used, i.e. it MUST not be filled. 4.1. Destiantion User Part Available(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. Signaling Congestion (SCON) For SG-SG communication, Concerned DPC parameter is mandatory. It contains the point code for the signaling point, which originated the message causing SCON to be generated. There will be two Affected PC fields present. The first one contains the point code of the originator of the SCON -or the corresponding Asveren, et al. Expires June 3, 2006 [Page 7] Internet-Draft M3UA SG-SG Communication November 2005 TFC- message and the second one contains the point code for the congested destination. Those two Affected PC fields MUST be sent in this order. The format for SCON 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 Signaling Route Set Congestion Test(National Option) procedures as defined by MTP3. It is used instead of RCT MTP3 message. The CGT message contains the following parameters: Affected PC Mandatory Concerned DPC Mandatory Congestion Level Mandatory Info String Optional Asveren, et al. Expires June 3, 2006 [Page 8] Internet-Draft M3UA SG-SG Communication November 2005 The format for the 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 Appearence: 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. Congestion Levels: 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 When sending CGT message, procedures defined for Signaling Route Set Congestion Test in Q.704 Clause 13.9 SHOULD be followed. Asveren, et al. Expires June 3, 2006 [Page 9] Internet-Draft M3UA SG-SG Communication November 2005 4.4. Changeover Mechanism Related Messages SG-SG communication does not rely on a mechanism similar to M3UA changeover mechanism for redundancy purposes , but a SG may relay MTP3 changeover mechanism related messages. +-------+ +-------+ | SS7 | | SG2 | | node1 +--------X-------+ | COO(1)+---+---+ ^ +----+--+ CORA(3) | ^ | | | ^ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V | | | +-------+ | | V COA(4)| | | SG1 | | COR(2) +-----+-+ +---------+ ^ | +-------+ ^ | | | | | | | | | | | | TDM IP Figure 3. 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 peer in TDM domain. There are two cases, where it can be used: either it is received from a SG peer, where a corresponding COO/ECM is sent to a conventional SS7 peer or it can be sent to a SG, after COO/ECM has been received from a conventional SS7 node. COR message contains the following parameters: Network Appearence: 32 bits (semi-mandatory) See M3UA Section 3.1.1 SLC: 5 bits (mandatory) The signaling link code of the failed link. FSN: 24-bits (semi-mandatory) Forward sequence number of the last message signal unit accepted from the unavailable signalink link by the sender of the message. If COR Asveren, et al. Expires June 3, 2006 [Page 10] Internet-Draft M3UA SG-SG Communication November 2005 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 conventional SS7 peer, FSN MUST be filled in COR. When ECM is received from a conventioanal 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 send COO/ECM message. Concerned Point Code: 32 bits (mandatory) Concerned Point Code parameter contains he 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 inforamtion for the last accepted MSU on a failed link between a peer SG and a conventional SS7 node as an answer to COR. COR message contains the following parameters: Asveren, et al. Expires June 3, 2006 [Page 11] Internet-Draft M3UA SG-SG Communication November 2005 Network Appearence: 32-bit (semi-mandatory) See M3UA Section 3.1.1 SLC: 5 bits (mandatory) The signaling link code of the failed link. FSN: 24 bits (semi-mandatory) Forward sequence number of the last message signal unit accepted from the unavailable signalink 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 conventional SS7 node, FSN MUST be filled in CORA. When ECA is received from a conventional SS7 node, 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 COA/ECA 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. 5. SG and SGP State Machines 5.1. SGP State Machine The state of each remote SGP is maintened 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 SGP M3UA layer. * Reception of indications from the SCTP layer. * Local management intervention. The SGP state transition diagram is shown below. 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 ASPDN-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. Asveren, et al. Expires June 3, 2006 [Page 12] Internet-Draft M3UA SG-SG Communication November 2005 +--------+ |SGP UP | +-+----+-+ ASPUP or ^ | ASPDOWN/ASPDOWN-ACK ASPUP-ACK | | SCTP CDI/SCTP RI | | | v +-+----+-+ |SGP DOWN| +--------+ Figure 4. SGP State Machine 5.2. SG State Machine The state machine of each remote SG is maintained in the SGP. SGPs belonging to the same SG MUST have a uniqie view of a remote SG. The state of a particular SG changes due to the events. The events include: * Reception of messages from the peer SG/SGP. * State changes of local SGPs. * Local management intervention. The SG state transition diagram is shown below. Possible states of a 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, DATA messages SHOULD NOT be sent to the remote SG. SG ACTIVE: There is at least one SGP belonging to this SG in SGP UP state and SG has finished PC announcement phase. Asveren, et al. Expires June 3, 2006 [Page 13] Internet-Draft M3UA SG-SG Communication November 2005 +--------+ | SG | |ACTIVE +---+ +---+----+ | ^ | ASPAC and| |Last SGP in SGP UP state ASPAC-ACK | |transitions to SGP DOWN state received from | | peer SG +---+----+ | | SG | | | UP | | +-+-----++ | one SGP ^ | | transitions| |Last SGP in SGP UP state to SGP UP | |transitions to SGP DOWN state state | | | | v | +-+-----++ | | SG +<--+ | DOWN | +--------+ Figure 5. SG State Machine 6. Management Procedures 6.1. ASPUP Procedures After a SGP successfully establishes a SCTP association with a peer SGP, it needs to declare availability of its M3UA layer to its peer. This is done either by sending ASPUP or by acknowledging a received ASPUP with ASPUP-ACK or with both of them. Because there is no client/server relationship between peers, each of them can send ASPUP. If for any local reason, e.g. management blocking, the SGP cannot respond with an ASPUP-ACK message, the SGP responds with an Error message with reason "Refused - Management Blocking". Otherwise, a received ASPUP message SHOULD be acknowledged with ASPUP-ACK. When ASPUP message is received while the SGP is in SGP-UP state, SGP stays in SGP-UP state and an ASPUP-ACK message is sent. In such a situation, if the SGP sending ASPUP message was the only SGP in SGP-UP state and if the SG is in SG-ACTIVE state, SG state is chnaged to SG-UP state. Asveren, et al. Expires June 3, 2006 [Page 14] Internet-Draft M3UA SG-SG Communication November 2005 When ASPUP-ACK message is received without sending an ASPUP message, remote SGP is put to SGP-DOWN state and an Error message with reason "Unexpected Message" is sent. 6.2. ASP Down Procedures When a SGP does not want to send/receive DATA messages to/from a SGP, for which it was already in SGP-UP state, it sends ASPDN message. When ASPDN message is received while the peer SGP is already in SGP- DOWN state, an Error message with reason "Unexpected message" is sent. When the SGP sends an ASPDN message, it starts timer T(ack). If the SGP does not receive a response to ASPDN message within T(ack), the SGP MAY restart T(ack) and resend ASPDN. 6.3. ASP Active Procedures ASPAC message MUST be sent to mark the end of SSNM, intiially sent to report PCs, which are configured as reachable via the SGP, but currently are not accessible or restricted. A received ASPAC message SHOULD be acknowledged with ASPAC-ACK message. When the SGP sends an ASPAC message, it starts timer T(ack). If the SGP does not receive a response to ASPAC message within T(ack), the SGP MAY restart T(ack) and resend ASPAC. A SGP SHOULD NOT start sending DATA to a peer SGP before receiving both ASPAC and ASPAC-ACK from the peer SGP. 7. Examples of SG-SG Communication Procedures 7.1. M3UA Availability Declaration In the following scenario, SG1 consists of SGP1/SGP2 and SG2 consists of SGP3/SGP4. After establishmnet of SCTP association between SGPs, each SGP should make its peers aware that its own M3UA layer is ready. Asveren, et al. Expires June 3, 2006 [Page 15] Internet-Draft M3UA SG-SG Communication November 2005 SGP1 SGP2 SGP3 SGP4 | | | | +------ASPUP----------->| | | | | | +------ASPUP------------+------->| | | | | |<-----ASPUP-ACK--------| | | | | | |<-----ASPUP------------+--------| | | | | |<-----ASPUP-ACK--------+--------| | | | | |------ASPUP-ACK--------+------->| | | | | | |<---ASPUP-----| | | | | | | |--ASPUP-ACK-->| | | | | | | |-----ASPUP----+------->| | | | | | |<------ASPUP-ACK-------| | | | | | | | | 7.2. PC Status Announcement In the following scenario, SG1 consists of SGP1/SGP2 and SG2 consists of SGP3/SGP4. The scenario shows message exchange after M3UA availability declaration is performed. Pc1/PC2/PC3 are configured as reachable via SG2 in SG1 and PC4/PC5 are configured as reachable via SG1 in SG2. During PC Status Announcement procedure, PC1 is unavailable in SG1 and PC2 is restricted. PC4 is unavailable in SG2. Asveren, et al. Expires June 3, 2006 [Page 16] Internet-Draft M3UA SG-SG Communication November 2005 SGP1 SGP2 SGP3 SGP4 | | | | |-------DUNA(PC1)--------->| | | | | | |-------DRST(PC2)--------->| | | | | | |------ASPAC-------------->| | | | | | |<-----ASPAC-ACK-----------| | | | | | |<--------+----DUNA(PC4)---+---------| | | | | |<--------+----ASPAC-------+---------| | | | | |---------+----ASPAC-ACK---+-------->| | | | | |<------DATA(PC3)----------| | | | | | | |----DATA(PC5)-->| | | | | | 8. IANA Considerations 9. Security Considerations 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 places 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 networks more vulnerable to intentioanl 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 or a combination of them. Other more sophisticated message syntax, message type and content based screening could also be implemented to improve security. Asveren, et al. Expires June 3, 2006 [Page 17] Internet-Draft M3UA SG-SG Communication November 2005 10. Acknowledgments The authors would like to thank Manfred Angermayr, Vaibhav Madan, Ken Morneault and Kutluk Uslu for their valuable comments and suggestions. 11. Normative References [1] Sidebottom, G., Morneault, K., and J. Pastor-Balbas, "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)", RFC 3332, September 2002. [2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [3] ITU, "Q.704 (07/96) Specifications of Signalling System No. 7 - Message transfer part". Asveren, et al. Expires June 3, 2006 [Page 18] Internet-Draft M3UA SG-SG Communication November 2005 Authors' Addresses Tolga Asveren Ulticom Inc. 1020 Briggs Road Mount Laurel, NJ, 08054 USA Email: asveren@ulticom.com Brian Bidulock OpenSS7 Corporation 1469 Jeffreys Crescent Edmonton, AB T6L 6T1 Canada Email: bidulock@openss7.org Javier Pastor-Balbas Ericsson Espana S.A. C/ Retama1 28045 Madrid Spain Email: j.javier.pastor@ericsson.com Asveren, et al. Expires June 3, 2006 [Page 19] Internet-Draft M3UA SG-SG Communication November 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Asveren, et al. Expires June 3, 2006 [Page 20]