From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4666.txt | 6947 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 6947 insertions(+) create mode 100644 doc/rfc/rfc4666.txt (limited to 'doc/rfc/rfc4666.txt') diff --git a/doc/rfc/rfc4666.txt b/doc/rfc/rfc4666.txt new file mode 100644 index 0000000..0c3bb73 --- /dev/null +++ b/doc/rfc/rfc4666.txt @@ -0,0 +1,6947 @@ + + + + + + +Network Working Group K. Morneault, Ed. +Request for Comments: 4666 Cisco Systems +Obsoletes: 3332 J. Pastor-Balbas, Ed. +Category: Standards Track Ericsson + September 2006 + + + Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - + User Adaptation Layer (M3UA) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This memo defines a protocol for supporting the transport of any SS7 + MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the + services of the Stream Control Transmission Protocol. Also, + provision is made for protocol elements that enable a seamless + operation of the MTP3-User peers in the SS7 and IP domains. This + protocol would be used between a Signalling Gateway (SG) and a Media + Gateway Controller (MGC) or IP-resident Database, or between two IP- + based applications. It is assumed that the SG receives SS7 + signalling over a standard SS7 interface using the SS7 Message + Transfer Part (MTP) to provide transport. This document obsoletes + RFC 3332. + + + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 1] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +Table of Contents + + 1. Introduction ....................................................6 + 1.1. Scope ......................................................6 + 1.2. Terminology ................................................6 + 1.3. M3UA Overview ..............................................9 + 1.3.1. Protocol Architecture ...............................9 + 1.3.2. Services Provided by the M3UA Layer ................10 + 1.3.2.1. Support for the Transport of + MTP3-User Messages ........................10 + 1.3.2.2. Native Management Functions ...............11 + 1.3.2.3. Interworking with MTP3 Network + Management Functions ......................11 + 1.3.2.4. Support for the Management of SCTP + Associations between the ..................11 + 1.3.2.5. Support for the Management of + Connections to Multiple SGPs ..............12 + 1.4. Functional Areas ..........................................12 + 1.4.1. Signalling Point Code Representation ...............12 + 1.4.2. Routing Contexts and Routing Keys ..................14 + 1.4.2.1. Overview ..................................14 + 1.4.2.2. Routing Key Limitations ...................15 + 1.4.2.3. Managing Routing Contexts and + Routing Keys ..............................15 + 1.4.2.4. Message Distribution at the SGP ...........15 + 1.4.2.5. Message Distribution at the ASP ...........16 + 1.4.3. SS7 and M3UA Interworking ..........................16 + 1.4.3.1. Signalling Gateway SS7 Layers .............16 + 1.4.3.2. SS7 and M3UA Interworking at the SG .......17 + 1.4.3.3. Application Server ........................17 + 1.4.3.4. IPSP Considerations .......................18 + 1.4.4. Redundancy Models ..................................18 + 1.4.4.1. Application Server Redundancy .............18 + 1.4.5. Flow Control .......................................18 + 1.4.6. Congestion Management ..............................19 + 1.4.7. SCTP Stream Mapping ................................19 + 1.4.8. SCTP Client/Server Model ...........................19 + 1.5. Sample Configuration ......................................20 + 1.5.1. Example 1: ISUP Message Transport ..................20 + 1.5.2. Example 2: SCCP Transport between IPSPs ............21 + 1.5.3. Example 3: SGP Resident SCCP Layer, with + Remote ASP .........................................22 + 1.6. Definition of M3UA Boundaries .............................23 + 1.6.1. Definition of the Boundary between M3UA and + an MTP3-User .......................................23 + 1.6.2. Definition of the Boundary between M3UA and SCTP ...23 + 1.6.3. Definition of the Boundary between M3UA and + Layer Management ...................................24 + + + +Morneault & Pastor-Balbas Standards Track [Page 2] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + 2. Conventions ....................................................27 + 3. M3UA Protocol Elements .........................................28 + 3.1. Common Message Header .....................................28 + 3.1.1. M3UA Protocol Version: 8 bits (unsigned integer) ...28 + 3.1.2. Message Classes and Types ..........................28 + 3.1.3. Reserved: 8 Bits ...................................30 + 3.1.4. Message Length: 32-Bits (Unsigned Integer) .........30 + 3.2. Variable-Length Parameter Format ..........................30 + 3.3. Transfer Messages .........................................33 + 3.3.1. Payload Data Message (DATA) ........................33 + 3.4. SS7 Signalling Network Management (SSNM) Messages .........36 + 3.4.1. Destination Unavailable (DUNA) .....................36 + 3.4.2. Destination Available (DAVA) .......................39 + 3.4.3. Destination State Audit (DAUD) .....................40 + 3.4.4. Signalling Congestion (SCON) .......................40 + 3.4.5. Destination User Part Unavailable (DUPU) ...........43 + 3.4.6. Destination Restricted (DRST) ......................45 + 3.5. ASP State Maintenance (ASPSM) Messages ....................45 + 3.5.1. ASP Up .............................................45 + 3.5.2. ASP Up Acknowledgement (ASP Up Ack) ................46 + 3.5.3. ASP Down ...........................................47 + 3.5.4. ASP Down Acknowledgement (ASP Down Ack) ............48 + 3.5.5. Heartbeat (BEAT) ...................................48 + 3.5.6. Heartbeat Acknowledgement (BEAT Ack) ...............49 + 3.6. Routing Key Management (RKM) Messages [Optional] ..........49 + 3.6.1. Registration Request (REG REQ) .....................49 + 3.6.2. Registration Response (REG RSP) ....................54 + 3.6.3. Deregistration Request (DEREG REQ) .................56 + 3.6.4. Deregistration Response (DEREG RSP) ................57 + 3.7. ASP Traffic Maintenance (ASPTM) Messages ..................59 + 3.7.1. ASP Active .........................................59 + 3.7.2. ASP Active Acknowledgement (ASP Active Ack) ........60 + 3.7.3. ASP Inactive .......................................61 + 3.7.4. ASP Inactive Acknowledgement (ASP Inactive Ack) ....62 + 3.8. Management (MGMT) Messages ................................63 + 3.8.1. Error ..............................................63 + 3.8.2. Notify .............................................67 + 4. Procedures .....................................................70 + 4.1. Procedures to Support the M3UA-User .......................70 + 4.1.1. Receipt of Primitives from the M3UA-User ...........70 + 4.2. Receipt of Primitives from the Layer Management ...........71 + 4.2.1. Receipt of M3UA Peer Management Messages ...........72 + 4.3. AS and ASP/IPSP State Maintenance .........................73 + 4.3.1. ASP/IPSP States ....................................74 + 4.3.2. AS States ..........................................76 + 4.3.3. M3UA Management Procedures for Primitives ..........78 + 4.3.4. ASPM Procedures for Peer-to-Peer Messages ..........79 + 4.3.4.1. ASP Up Procedures .........................79 + + + +Morneault & Pastor-Balbas Standards Track [Page 3] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + 4.3.4.2. ASP-Down Procedures .......................81 + 4.3.4.3. ASP Active Procedures .....................82 + 4.3.4.4. ASP Inactive Procedures ...................86 + 4.3.4.5. Notify Procedures .........................88 + 4.3.4.6. Heartbeat Procedures ......................89 + 4.4. Routing Key Management Procedures [Optional] ..............90 + 4.4.1. Registration .......................................90 + 4.4.2. Deregistration .....................................92 + 4.4.3. IPSP Considerations (REG/DEREG) ....................93 + 4.5. Procedures to Support the Availability or + Congestion Status of SS7 Destination ......................93 + 4.5.1. At an SGP ..........................................93 + 4.5.2. At an ASP ..........................................94 + 4.5.2.1. Single SG Configurations ..................94 + 4.5.2.2. Multiple SG Configurations ................94 + 4.5.3. ASP Auditing .......................................94 + 4.6. MTP3 Restart ..............................................96 + 4.7. NIF Not Available .........................................97 + 4.8. M3UA Version Control ......................................97 + 4.9. M3UA Termination ..........................................97 + 5. Examples of M3UA Procedures ....................................98 + 5.1. Establishment of Association and Traffic between + SGPs and ASPs .............................................98 + 5.1.1. Single ASP in an Application Server ("1+0" + sparing), No Registration ..........................98 + 5.1.1.1. Single ASP in an Application + Server ("1+0" Sparing), No Registration ...98 + 5.1.1.2. Single ASP in Application Server + ("1+0" Sparing), Dynamic Registration .....99 + 5.1.1.3. Single ASP in Multiple + Application Servers (Each with "1+0" + Sparing), Dynamic Registration (Case 1 + - Multiple Registration Requests) ........100 + 5.1.1.4. Single ASP in Multiple + Application Servers (each with "1+0" + sparing), Dynamic Registration (Case 2 + - Single Registration Request) ...........101 + 5.1.2. Two ASPs in Application Server ("1+1" Sparing) ....102 + 5.1.3. Two ASPs in an Application Server ("1+1" + Sparing, Loadsharing Case) ........................103 + 5.1.4. Three ASPs in an Application Server ("n+k" + Sparing, Loadsharing Case) ........................104 + 5.2. ASP Traffic Failover Examples ............................105 + 5.2.1. 1+1 Sparing, Withdrawal of ASP, Backup Override ...105 + 5.2.2. 1+1 Sparing, Backup Override ......................105 + 5.2.3. n+k Sparing, Loadsharing Case, Withdrawal of ASP ..106 + 5.3. Normal Withdrawal of an ASP from an Application Server ...106 + 5.4. Auditing Examples ........................................107 + + + +Morneault & Pastor-Balbas Standards Track [Page 4] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + 5.4.1. SG State: Uncongested/Available ...................107 + 5.4.2. SG State: Congested (Congestion Level=2) / + Available .........................................107 + 5.4.3. SG State: Unknown/Available .......................107 + 5.4.4. SG State: Unavailable .............................108 + 5.5. M3UA/MTP3-User Boundary Examples .........................108 + 5.5.1. At an ASP .........................................108 + 5.5.1.1. Support for MTP-TRANSFER + Primitives at the ASP ....................108 + 5.5.2. At an SGP .........................................109 + 5.5.2.1. Support for MTP-TRANSFER Request + Primitive at the SGP .....................109 + 5.5.2.2. Support for MTP-TRANSFER + Indication Primitive at the SGP ..........110 + 5.5.2.3. Support for MTP-PAUSE, + MTP-RESUME, MTP-STATUS Indication + Primitives ...............................110 + 5.6. Examples for IPSP Communication ..........................112 + 5.6.1. Single Exchange ...................................112 + 5.6.2. Double Exchange ...................................113 + 6. Security Considerations .......................................113 + 7. IANA Considerations ...........................................114 + 7.1. SCTP Payload Protocol Identifier .........................114 + 7.2. M3UA Port Number .........................................114 + 7.3. M3UA Protocol Extensions .................................114 + 7.3.1. IETF-Defined Message Classes ......................115 + 7.3.2. IETF Defined Message Types ........................115 + 7.3.3. IETF-Defined Parameter Extension ..................115 + 8. Acknowledgements ..............................................115 + 9. Document Contributors .........................................116 + 10. References ...................................................116 + 10.1. Normative References ....................................116 + 10.2. Informative References ..................................117 + Appendix A .......................................................119 + A.1. Signalling Network Architecture .............................119 + A.2. Redundancy Models ...........................................121 + A.2.1. Application Server Redundancy ........................121 + A.2.2. Signalling Gateway Redundancy ........................122 + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 5] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +1. Introduction + + This memo defines a protocol for supporting the transport of any SS7 + MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the + services of the Stream Control Transmission Protocol [18]. Also, + provision is made for protocol elements that enable a seamless + operation of the MTP3-User peers in the SS7 and IP domains. This + protocol would be used between a Signalling Gateway (SG) and a Media + Gateway Controller (MGC) or IP-resident Database [12], or between two + IP-based applications. + +1.1. Scope + + There is a need for Switched Circuit Network (SCN) signalling + protocol delivery from an SS7 Signalling Gateway (SG) to a Media + Gateway Controller (MGC) or IP-resident Database as described in the + Framework Architecture for Signalling Transport [12]. The delivery + mechanism should meet the following criteria: + + * Support for the transfer of all SS7 MTP3-User Part messages (e.g., + ISUP [1,2,3], SCCP [4,5,6], TUP [13], etc.) + * Support for the seamless operation of MTP3-User protocol peers + * Support for the management of SCTP transport associations and + traffic between an SG and one or more MGCs or IP-resident + Databases + * Support for MGC or IP-resident database process failover and load + sharing + * Support for the asynchronous reporting of status changes to + management + + In simplistic transport terms, the SG will terminate SS7 MTP2 and + MTP3 protocol layers [7,8,9] and deliver ISUP, SCCP, and/or any other + MTP3-User protocol messages, as well as certain MTP network + management events, over SCTP transport associations to MTP3-User + peers in MGCs or IP-resident databases. + +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 signalling relation, identified by + an SS7 DPC/OPC. Another example is a virtual database element, + handling all HLR transactions for a particular SS7 SIO/DPC/OPC + 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. + + + + +Morneault & Pastor-Balbas Standards Track [Page 6] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + 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 MTP3-User + protocol data units and M3UA adaptation layer peer messages. + + 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 M3UA in a point-to-point fashion. Conceptually, an IPSP does + not use the services 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. + + Layer Management - Layer Management is a nodal function that handles + the inputs and outputs between the M3UA 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 M3UA 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 to which it belongs. 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 + + + +Morneault & Pastor-Balbas Standards Track [Page 7] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + 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 configured either using a configuration + management interface, or by using the routing key management + procedures defined in this document. + + Signaling End Point (SEP) - A node in the SS7 network associated with + an originating or terminating local exchange (switch) or a gateway + exchange. + + Signalling Gateway Process (SGP) - A process instance of a Signalling + Gateway. It serves as an active, backup, load-sharing, or broadcast + process of a Signalling Gateway. + + Signalling Gateway (SG) - An SG is a signaling agent that + receives/sends SCN native signaling at the edge of the IP network + [12]. 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 - A process instance that uses M3UA 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. + + + + +Morneault & Pastor-Balbas Standards Track [Page 8] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Signaling Transfer Point (STP) - A node in the SS7 network that + provides network access and performs message routing, screening and + transfer of signaling messages. + + Stream - 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. + +1.3. M3UA Overview + +1.3.1. Protocol Architecture + + The framework architecture that has been defined for SCN signalling + transport over IP [12] uses multiple components, including a common + signalling transport protocol and an adaptation module to support the + services expected by a particular SCN signalling protocol from its + underlying protocol layer. + + Within the framework architecture, this document defines an MTP3-User + adaptation module suitable for supporting the transfer of messages of + any protocol layer that is identified to the MTP Level 3 as an MTP + User. The list of these protocol layers includes but is not limited + to ISDN User Part (ISUP) [1,2,3], Signalling Connection Control Part + (SCCP) [4,5,6], and Telephone User Part (TUP) [13]. TCAP [14,15,16] + or RANAP [16] messages are transferred transparently by the M3UA + protocol as SCCP payload, as they are SCCP-User protocols. + + It is recommended that M3UA use the services of the Stream Control + Transmission Protocol (SCTP) [18] as the underlying reliable common + signalling transport protocol. This is to take advantage of various + SCTP features, such as: + + - Explicit packet-oriented delivery (not stream-oriented) + - Sequenced delivery of user messages within multiple streams, + with an option for order-of-arrival delivery of individual + user messages + - Optional multiplexing of user messages into SCTP datagrams + - Network-level fault tolerance through support of multi-homing + at either or both ends of an association + - Resistance to flooding and masquerade attacks + - Data segmentation to conform to discovered path MTU size + + Under certain scenarios, such as back-to-back connections without + redundancy requirements, the SCTP functions above might not be a + requirement, and TCP MAY be used as the underlying common transport + protocol. + + + + +Morneault & Pastor-Balbas Standards Track [Page 9] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +1.3.2. Services Provided by the M3UA Layer + + The M3UA Layer at an ASP or IPSP provides the equivalent set of + primitives at its upper layer to the MTP3-Users as provided by the + MTP Level 3 to its local MTP3-Users at an SS7 SEP. In this way, the + ISUP and/or SCCP layer at an ASP or IPSP is unaware that the expected + MTP3 services are offered remotely from an MTP3 Layer at an SGP, and + not by a local MTP3 layer. The MTP3 layer at an SGP may also be + unaware that its local users are actually remote user parts over + M3UA. In effect, the M3UA extends access to the MTP3 layer services + to a remote IP-based application. The M3UA layer does not itself + provide the MTP3 services. However, in the case where an ASP is + connected to more than one SG, the M3UA layer at an ASP should + maintain the status of configured SS7 destinations and route messages + according to the availability and congestion status of the routes to + these destinations via each SG. + + The M3UA layer may also be used for point-to-point signalling between + two IP Server Processes (IPSPs). In this case, the M3UA layer + provides the same set of primitives and services at its upper layer + as the MTP3. However, in this case the expected MTP3 services are + not offered remotely from an SGP. The MTP3 services are provided, + but the procedures to support these services are a subset of the MTP3 + procedures, due to the simplified point-to-point nature of the IPSP- + to-IPSP relationship. + +1.3.2.1. Support for the Transport of MTP3-User Messages + + The M3UA layer provides the transport of MTP-TRANSFER primitives + across an established SCTP association between an SGP and an ASP or + between IPSPs. + + At an ASP, in the case where a destination is reachable via multiple + SGPs, the M3UA layer must also choose via which SGP the message is to + be routed or support load balancing across the SGPs, thereby + minimizing missequencing. + + The M3UA layer does not impose a 272-octet signalling information + field (SIF) length limit as specified by the SS7 MTP Level 2 protocol + [7,8,9]. Larger information blocks can be accommodated directly by + M3UA/SCTP, without the need for an upper layer segmentation/ + re-assembly procedure as specified in recent SCCP or ISUP versions. + However, in the context of an SG, the maximum 272-octet block size + must be followed when interworking to a SS7 network that does not + support the transfer of larger information blocks to the final + destination. This avoids potential ISUP or SCCP fragmentation + requirements at the SGPs. The provisioning and configuration of the + SS7 network determines the restriction placed on the maximum block + + + +Morneault & Pastor-Balbas Standards Track [Page 10] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + size. Some configurations (e.g., Broadband MTP [19,20,22]) may + permit larger block sizes. + +1.3.2.2. Native Management Functions + + The M3UA layer provides the capability to indicate errors associated + with received M3UA messages and to notify, as appropriate, local + management and/or the peer M3UA. + +1.3.2.3. Interworking with MTP3 Network Management Functions + + At the SGP, the M3UA layer provides interworking with MTP3 management + functions to support seamless operation of the user SCN signalling + applications in the SS7 and IP domains. This includes + + - providing an indication to MTP3-Users at an ASP that a destination + in the SS7 network is not reachable; + + - providing an indication to MTP3-Users at an ASP that a destination + in the SS7 network is now reachable; + + - providing an indication to MTP3-Users at an ASP that messages to a + destination in the SS7 network are experiencing SS7 congestion; + + - providing an indication to the M3UA layer at an ASP that the routes + to a destination in the SS7 network are restricted; and + + - providing an indication to MTP3-Users at an ASP that a MTP3-User + peer is unavailable. + + The M3UA layer at an ASP keeps the state of the routes to remote SS7 + destinations and may initiate an audit of the availability and the + restricted or the congested state of remote SS7 destinations. This + information is requested from the M3UA layer at the SGP. + + The M3UA layer at an ASP may also indicate to the SG that the M3UA + layer itself or the ASP or the ASP's Host is congested. + +1.3.2.4. Support for the Management of SCTP Associations between the + SGP and ASPs + + The M3UA layer at the SGP maintains the availability state of all + configured remote ASPs, to manage the SCTP Associations and the + traffic between the M3UA peers. Also, the active/inactive and + congestion state of remote ASPs is maintained. + + The M3UA layer MAY be instructed by local management to establish an + SCTP association to a peer M3UA node. This can be achieved using the + + + +Morneault & Pastor-Balbas Standards Track [Page 11] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + M-SCTP_ESTABLISH primitives (see Section 1.6.3 for a description of + management primitives) to request, indicate, and confirm the + establishment of an SCTP association with a peer M3UA node. In order + to avoid redundant SCTP associations between two M3UA peers, one side + (client) SHOULD be designated to establish the SCTP association, or + M3UA configuration information maintained to detect redundant + associations (e.g., via knowledge of the expected local and remote + SCTP endpoint addresses). + + Local management MAY request from the M3UA layer the status of the + underlying SCTP associations using the M-SCTP_STATUS request and + confirm primitives. Also, the M3UA MAY autonomously inform local + management of the reason for the release of an SCTP association, + determined either locally within the M3UA layer or by a primitive + from the SCTP. + + Also, the M3UA layer MAY inform the local management of the change in + status of an ASP or AS. This MAY be achieved using the M-ASP_STATUS + request or M-AS_STATUS request primitives. + +1.3.2.5. Support for the Management of Connections to Multiple SGPs + + As shown in Figure 1, an ASP may be connected to multiple SGPs. In + such a case, a particular SS7 destination may be reachable via more + than one SGP and/or SG; i.e., via more than one route. As MTP3 users + only maintain status on a destination and not on a route basis, the + M3UA layer must maintain the status (availability, restriction, + and/or congestion of route to destination) of the individual routes, + derive the overall availability or congestion status of the + destination from the status of the individual routes, and inform the + MTP3 users of this derived status whenever it changes. + +1.4. Functional Areas + +1.4.1. Signalling Point Code Representation + + For example, within an SS7 network, a Signalling Gateway might be + charged with representing a set of nodes in the IP domain into the + SS7 network for routing purposes. The SG itself, as a signalling + point in the SS7 network, might also be addressable with an SS7 Point + Code for MTP3 Management purposes. The SG Point Code might also be + used for addressing any local MTP3-Users at the SG such as a local + SCCP layer. + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 12] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + An SG may be logically partitioned to operate in multiple SS7 network + appearances. In such a case, the SG could be addressable with a + Point Code in each network appearance, and it represents a set of + nodes in the IP domain into each SS7 network. Alias Point Codes [8] + may also be used within an SG network appearance. + + Where an SG contains more than one SGP, the MTP3 routeset, SPMC, and + remote AS/ASP states of each SGP SHOULD be coordinated across all the + SGPs. Rerouting of traffic between the SGPs MAY also be supported. + + Application Servers can be represented under the same Point Code of + the SG, under their own individual Point Codes, or grouped with other + Application Servers for Point Code preservation purposes. A single + Point Code may be used to represent the SG and all the Application + Servers together, if desired. + + If an ASP or group of ASPs is available to the SS7 network via more + than one SG, each with its own Point Code, the ASP(s) will typically + be represented by a Point Code that is separate from any SG Point + Code. This allows, for example, these SGs to be viewed from the SS7 + network as "STPs", each having an ongoing "route" to the same ASP(s). + Under failure conditions where the ASP(s) become(s) unavailable from + one of the SGs, this approach enables MTP3 route management messaging + between the SG and SS7 network, allowing simple SS7 rerouting through + an alternate SG without changing the Destination Point Code Address + of SS7 traffic to the ASP(s). + + Where a particular AS can be reached via more than one SGP, the + corresponding Routing Keys in the SGPs should be identical. (Note: + It is possible for the SGP Routing Key configuration data to be + temporarily out of sync during configuration updates). + + +--------+ + | | + +------------+ SG 1 +--------------+ + +-------+ | SS7 links | "STP" | IP network | ---- + | SEP +---+ +--------+ +---/ \ + | or | |* | ASPs | + | STP +---+ +--------+ +---\ / + +-------+ | | | | ---- + +------------+ SG 2 +--------------+ + | "STP" | + +--------+ + + Figure 1. Example with mated SGs + + * Note: SG-to-SG communication (i.e., "C-links") is recommended + for carrier grade networks, using an MTP3 linkset or an + + + +Morneault & Pastor-Balbas Standards Track [Page 13] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + equivalent, to allow rerouting between the SGs in the event of + route failures. Where SGPs are used, inter-SGP communication + might be used. Inter-SGP protocol is outside of the scope of this + document. + + The following example shows a signalling gateway partitioned into + two network appearances. + + SG + +-------+ +---------------+ + | SEP +--------------| SS7 Ntwk.|M3UA| ---- + +-------+ SS7 links | "A" | | / \ + |__________| +-----------+ ASPs | + | | | \ / + +-------+ | SS7 Ntwk.| | ---- + | SEP +--------------+ "B" | | + +-------+ +---------------+ + + Figure 2. Example with multiple network + +1.4.2. Routing Contexts and Routing Keys + +1.4.2.1. Overview + + The distribution of SS7 messages between the SGP and the Application + Servers is determined by the Routing Keys and their associated + Routing Contexts. A Routing Key is essentially a set of SS7 + parameters used to filter SS7 messages, whereas the Routing Context + parameter is a 4-octet value (integer) that is associated to that + Routing Key in a 1:1 relationship. The Routing Context therefore can + be viewed as an index into a sending node's Message Distribution + Table containing the Routing Key entries. + + Possible SS7 address/routing information that comprise a Routing Key + entry includes, for example, the OPC, DPC, and SIO found in the MTP3 + routing label. Some example Routing Keys are: the DPC alone, the + DPC/OPC combination, or the DPC/OPC/SI combination. The particular + information used to define an M3UA Routing Key is application and + network dependent, and none of the above examples are mandated. + + An Application Server Process may be configured to process signalling + traffic related to more than one Application Server, over a single + SCTP Association. In ASP Active and ASP Inactive management + messages, the signalling traffic to be started or stopped is + discriminated by the Routing Context parameter. At an ASP, the + Routing Context parameter uniquely identifies the range of signalling + traffic associated with each Application Server that the ASP is + configured to receive. + + + +Morneault & Pastor-Balbas Standards Track [Page 14] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +1.4.2.2. Routing Key Limitations + + Routing Keys SHOULD be unique in the sense that each received SS7 + signalling message SHOULD have a full or partial match to a single + routing result. An example of a partial match would be a default + Routing Key that would be the result if there are no other Routing + Keys to which the message belongs. It is not necessary for the + parameter range values within a particular Routing Key to be + contiguous. + +1.4.2.3. Managing Routing Contexts and Routing Keys + + There are two ways to provision a Routing Key at an SGP. A Routing + Key may be configured statically using an implementation dependent + management interface, or dynamically using the M3UA Routing Key + registration procedure. + + When using a management interface to configure Routing Keys, the + message distribution function within the SGP is not limited to the + set of parameters defined in this document. Other implementation- + dependent distribution algorithms may be used. + +1.4.2.4. Message Distribution at the SGP + + To direct messages received from the SS7 MTP3 network to the + appropriate IP destination, the SGP must perform a message + distribution function using information from the received MTP3-User + message. + + To support this message distribution, the SGP might, for example, + maintain the equivalent of a network address translation table, + mapping incoming SS7 message information to an Application Server for + a particular application and range of traffic. This could be + accomplished by comparing elements of the incoming SS7 message to + currently defined Routing Keys in the SGP. + + These Routing Keys could in turn map directly to an Application + Server that is enabled by one or more ASPs. These ASPs provide + dynamic status information regarding their availability, traffic- + handling capability and congestion to the SGP using various + management messages defined in the M3UA protocol. + + The list of ASPs in an AS is assumed to be dynamic, taking into + account the availability, traffic-handling capability, and congestion + status of the individual ASPs in the list, as well as configuration + changes and possible failover mechanisms. + + + + + +Morneault & Pastor-Balbas Standards Track [Page 15] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Normally, one or more ASPs are active (i.e., currently processing + traffic) in the AS, but in certain failure and transition cases it is + possible that there may be no active ASP available. Broadcast, + loadsharing, and backup scenarios are supported. + + When there is no matching Routing Key entry for an incoming SS7 + message, a default treatment MAY be specified. Possible solutions + are to provide a default Application Server at the SGP that directs + all unallocated traffic to a (set of) default ASPs, or to drop the + message and provide a notification to layer management. The + treatment of unallocated traffic is implementation dependent. + +1.4.2.5. Message Distribution at the ASP + + The ASP must choose an SGP to direct a message to the SS7 network. + This is accomplished by observing the Destination Point Code (and + possibly other elements of the outgoing message, such as the SLS + value). The ASP must also take into account whether the related + Routing Context is active or not (see Section 4.3.4.3). + + Implementation Note: Where more than one route (or SGP) is possible + for routing to the SS7 network, the ASP could, for example, maintain + a dynamic table of available SGP routes for the SS7 destinations, + taking into account the SS7 destination + availability/restricted/congestion status received from the SGP(s), + the availability status of the individual SGPs, and configuration + changes and failover mechanisms. There is, however, no M3UA + messaging to manage the status of an SGP (e.g., SGP- + Up/Down/Active/Inactive messaging). + + Whenever an SCTP association to an SGP exists, the SGP is assumed to + be ready for the purposes of responding to M3UA ASPSM messages (refer + to Section 3). + +1.4.3. SS7 and M3UA Interworking + + In the case of SS7 and M3UA interworking, the M3UA adaptation layer + is designed to provide an extension of the MTP3-defined user + primitives. + +1.4.3.1. Signalling Gateway SS7 Layers + + The SG is responsible for terminating MTP Level 3 of the SS7 + protocol, and offering an IP-based extension to its users. + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 16] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + From an SS7 perspective, it is expected that the Signalling Gateway + transmits and receives SS7 Message Signalling Units (MSUs) over a + standard SS7 network interface, using the SS7 Message Transfer Part + (MTP) [7,8,9]. + + As a standard SS7 network interface, the use of MTP Level 2 + signalling links is not the only possibility. ATM-based High Speed + Links can also be used with the services of the Signalling ATM + Adaptation Layer (SAAL) [19,20]. + + Note: It is also possible for IP-based interfaces to be present, + using the services of the MTP2-User Adaptation Layer (M2UA) [24] or + M2PA [25]. + + These could be terminated at a Signalling Transfer Point (STP) or + Signalling End Point (SEP). Using the services of MTP3, the SG could + be capable of communicating with remote SS7 SEPs in a quasi- + associated fashion, where STPs may be present in the SS7 path between + the SEP and the SG. + +1.4.3.2. SS7 and M3UA Interworking at the SG + + The SGP provides a functional interworking of transport functions + between the SS7 network and the IP network by also supporting the + M3UA adaptation layer. It allows the transfer of MTP3-User + signalling messages to and from an IP-based Application Server + Process where the peer MTP3-User protocol layer exists. + + For SS7 user part management, it is required that the MTP3-User + protocols at ASPs receive indications of SS7 signalling point + availability, SS7 network congestion, and remote User Part + unavailability, as would be expected in an SS7 SEP node. To + accomplish this, the MTP-PAUSE, MTP-RESUME, and MTP-STATUS indication + primitives received at the MTP3 upper layer interface at the SG need + to be propagated to the remote MTP3-User lower layer interface at the + ASP. + + MTP3 management messages (such as TFPs or TFAs received from the SS7 + network) MUST NOT be encapsulated as Data message Payload Data and + sent either from SG to ASP or from ASP to SG. The SG MUST terminate + these messages and generate M3UA messages, as appropriate. + +1.4.3.3. Application Server + + A cluster of application servers is responsible for providing the + overall support for one or more SS7 upper layers. From an SS7 + standpoint, a Signalling Point Management Cluster (SPMC) provides + complete support for the upper layer service for a given point code. + + + +Morneault & Pastor-Balbas Standards Track [Page 17] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + As an example, an SPMC providing MGC capabilities could provide + complete support for ISUP (and any other MTP3 user located at the + point code of the SPMC) for a given point code. + + In the case where an ASP is connected to more than one SGP, the M3UA + layer must maintain the status of configured SS7 destinations and + route messages according to the availability/congestion/restricted + status of the routes to these SS7 destinations. + +1.4.3.4. IPSP Considerations + + Since IPSPs use M3UA in a point-to-point fashion, there is no concept + of routing of messages beyond the remote end. Therefore, SS7 and + M3UA interworking is not necessary for this model. + +1.4.4. Redundancy Models + +1.4.4.1 Application Server Redundancy + + All MTP3-User messages (e.g., ISUP, SCCP) that match a provisioned + Routing Key at an SGP are mapped to an Application Server. + + The Application Server is the set of all ASPs associated with a + specific Routing Key. Each ASP in this set may be active, inactive, + or unavailable. Active ASPs handle traffic; inactive ASPs might be + used when active ASPs become unavailable. + + The failover model supports an "n+k" redundancy model, where "n" ASPs + is the minimum number of redundant ASPs required to handle traffic + and "k" ASPs are available to take over for a failed or unavailable + ASP. Traffic SHOULD be sent after "n" ASPs are active. "k" ASPs MAY + be either active at the same time as "n" or kept inactive until + needed due to a failed or unavailable ASP. + + A "1+1" active/backup redundancy is a subset of this model. A + simplex "1+0" model is also supported as a subset, with no ASP + redundancy. + +1.4.5. Flow Control + + Local Management at an ASP may wish to stop traffic across an SCTP + association to temporarily remove the association from service or to + perform testing and maintenance activity. The function could + optionally be used to control the start of traffic on to a newly + available SCTP association. + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 18] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +1.4.6. Congestion Management + + The M3UA layer is informed of local and IP network congestion by + means of an implementation-dependent function (e.g., an + implementation-dependent indication from the SCTP of IP network + congestion). + + At an ASP or IPSP, the M3UA layer indicates IP network congestion to + local MTP3-Users by means of an MTP-STATUS primitive, as per current + MTP3 procedures, to invoke appropriate upper-layer responses. + + When an SG determines that the transport of SS7 messages to a + Signalling Point Management Cluster (SPMC) is encountering IP network + congestion, the SG MAY trigger SS7 MTP3 Transfer Controlled + management messages to originating SS7 nodes, per the congestion + procedures of the relevant MTP3 standard. The triggering of SS7 MTP3 + Management messages from an SG is an implementation-dependent + function. + + The M3UA layer at an ASP or IPSP MAY indicate local congestion to an + M3UA peer with an SCON message. When an SG receives a congestion + message (SCON) from an ASP and the SG determines that an SPMC is now + encountering congestion, it MAY trigger SS7 MTP3 Transfer Controlled + management messages to concerned SS7 destinations according to + congestion procedures of the relevant MTP3 standard. + +1.4.7. SCTP Stream Mapping + + The M3UA layer at both the SGP and ASP also supports the assignment + of signalling traffic into streams within an SCTP association. + Traffic that requires sequencing SHOULD be assigned to the same + stream. To accomplish this, MTP3-User traffic may be assigned to + individual streams based on, for example, the SLS value in the MTP3 + Routing Label, subject of course to the maximum number of streams + supported by the underlying SCTP association. + + The following rules apply (see Section 3.1.2): + + 1. The DATA message MUST NOT be sent on stream 0. + 2. The ASPSM, MGMT, RKM classes SHOULD be sent on stream 0 (other + than BEAT, BEAT ACK and NTFY messages). + 3. The SSNM, ASPTM classes and BEAT, BEAT ACK and NTFY messages can + be sent on any stream. + +1.4.8. SCTP Client/Server Model + + It is recommended that the SGP and ASP be able to support both client + and server operation. The peer endpoints using M3UA SHOULD be + + + +Morneault & Pastor-Balbas Standards Track [Page 19] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + configured so that one always takes on the role of client and the + other the role of server for initiating SCTP associations. The + default orientation would be for the SGP to take on the role of + server while the ASP is the client. In this case, ASPs SHOULD + initiate the SCTP association to the SGP. + + In the case of IPSP to IPSP communication, the peer endpoints using + M3UA SHOULD be configured so that one always takes on the role of + client and the other the role of server for initiating SCTP + associations. + + The SCTP and TCP Registered User Port Number Assignment for M3UA is + 2905. + +1.5. Sample Configuration + +1.5.1. Example 1: ISUP Message Transport + + ******** SS7 ***************** IP ******** + * SEP *---------* SGP *--------* ASP * + ******** ***************** ******** + + +------+ +---------------+ +------+ + | ISUP | | (NIF) | | ISUP | + +------+ +------+ +------+ +------+ + | MTP3 | | MTP3 | | M3UA | | M3UA | + +------| +------+-+------+ +------+ + | MTP2 | | MTP2 | | SCTP | | SCTP | + +------+ +------+ +------+ +------+ + | L1 | | L1 | | IP | | IP | + +------+ +------+ +------+ +------+ + |_______________| |______________| + + SEP - SS7 Signalling End Point + SCTP - Stream Control Transmission Protocol + NIF - Nodal Interworking Function + + In this example, the SGP provides an implementation-dependent nodal + interworking function (NIF) that allows the MGC to exchange SS7 + signalling messages with the SS7-based SEP. The NIF within the SGP + serves as the interface within the SGP between the MTP3 and M3UA. + This nodal interworking function has no visible peer protocol with + either the MGC or SEP. It also provides network status information + to one or both sides of the network. + + For internal SGP modeling purposes, at the NIF level, SS7 signalling + messages that are destined to the MGC are received as MTP-TRANSFER + indication primitives from the MTP Level 3 upper layer interface, + + + +Morneault & Pastor-Balbas Standards Track [Page 20] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + translated to MTP-TRANSFER request primitives, and sent to the local + M3UA-resident message distribution function for ongoing routing to + the final IP destination. Messages received from the local M3UA + network address translation and mapping function as MTP-TRANSFER + indication primitives are sent to the MTP Level 3 upper-layer + interface as MTP-TRANSFER request primitives for ongoing MTP Level 3 + routing to an SS7 SEP. For the purposes of providing SS7 network + status information, the NIF also delivers MTP-PAUSE, MTP-RESUME, and + MTP-STATUS indication primitives received from the MTP Level 3 + upper-layer interface to the local M3UA-resident management function. + In addition, as an implementation and network option, restricted + destinations are communicated from MTP network management to the + local M3UA-resident management function. + +1.5.2. Example 2: SCCP Transport between IPSPs + + ******** IP ******** + * IPSP * * IPSP * + ******** ******** + + +------+ +------+ + |SCCP- | |SCCP- | + | User | | User | + +------+ +------+ + | SCCP | | SCCP | + +------+ +------+ + | M3UA | | M3UA | + +------+ +------+ + | SCTP | | SCTP | + +------+ +------+ + | IP | | IP | + +------+ +------+ + |________________| + + This example shows an architecture where no Signalling Gateway is + used. In this example, SCCP messages are exchanged directly between + two IP-resident IPSPs with resident SCCP-User protocol instances, + such as RANAP or TCAP. SS7 network interworking is not required; + therefore, there is no MTP3 network management status information for + the SCCP and SCCP-User protocols to consider. Any MTP-PAUSE, MTP- + RESUME, or MTP-STATUS indications from the M3UA layer to the SCCP + layer should consider the status of the SCTP Association and + underlying IP network and any congestion information received from + the remote site. + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 21] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +1.5.3. Example 3: SGP Resident SCCP Layer, with Remote ASP + + ******** SS7 ***************** IP ******** + * SEP *---------* *--------* * + * or * * SGP * * ASP * + * STP * * * * * + ******** ***************** ******** + + +------+ +---------------+ +------+ + | SCCP-| | SCCP | | SCCP-| + | User | +---------------+ | User | + +------+ | _____ | +------+ + | SCCP | | | | | | SCCP | + +------+ +------+-+------+ +------+ + | MTP3 | | MTP3 | | M3UA | | M3UA | + +------| +------+ +------+ +------+ + | MTP2 | | MTP2 | | SCTP | | SCTP | + +------+ +------+ +------+ +------+ + | L1 | | L1 | | IP | | IP | + +------+ +------+ +------+ +------+ + |_______________| |______________| + + STP - SS7 Signalling Transfer Point + + In this example, the SGP contains an instance of the SS7 SCCP + protocol layer that may, for example, perform the SCCP Global Title + Translation (GTT) function for messages logically addressed to the SG + SCCP. If the result of a GTT for an SCCP message yields an SS7 DPC + or DPC/SSN address of an SCCP peer located in the IP domain, the + resulting MTP-TRANSFER request primitive is sent to the local M3UA- + resident network address translation and mapping function for ongoing + routing to the final IP destination. + + Similarly, the SCCP instance in an SGP can perform the SCCP GTT + service for messages logically addressed to it from SCCP peers in the + IP domain. In this case, MTP-TRANSFER indication primitives are sent + from the local M3UA-resident network address translation and mapping + function to the SCCP for GTT. If the result of the GTT yields the + address of an SCCP peer in the SS7 network, then the resulting MTP- + TRANSFER request primitive is given to the MTP3 for delivery to an + SS7-resident node. + + It is possible that the above SCCP GTT at the SGP could yield the + address of an SCCP peer in the IP domain, and that the resulting + MTP-TRANSFER request primitive would be sent back to the M3UA layer + for delivery to an IP destination. + + + + + +Morneault & Pastor-Balbas Standards Track [Page 22] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + For internal SGP modeling purposes, this may be accomplished with the + use of an implementation-dependent nodal interworking function within + the SGP that effectively sits below the SCCP and routes MTP-TRANSFER + request/indication messages to/from both the MTP3 and the M3UA layer, + based on the SS7 DPC or DPC/SI address information. This nodal + interworking function has no visible peer protocol with either the + ASP or SEP. + + Note that the services and interface provided by the M3UA layer are + the same as in Example 1 and that the functions taking place in the + SCCP entity are transparent to the M3UA layer. The SCCP protocol + functions are not reproduced in the M3UA protocol. + +1.6. Definition of M3UA Boundaries + + This section provides a definition of the boundaries of the M3UA + protocol. They consist of SCTP, Layer Management, and the MTP3-User. + + +-----------+ + | MTP3-User | + +-----------+ + | + | + +-----------+ +------------+ + | M3UA |-----| Layer Mgmt | + +-----------+ +------------+ + | + | + +-----------+ + | SCTP | + +-----------+ + +1.6.1. Definition of the Boundary between M3UA and an MTP3-User + + From ITU Q.701 [7]: + + MTP-TRANSFER request + MTP-TRANSFER indication + MTP-PAUSE indication + MTP-RESUME indication + MTP-STATUS indication + +1.6.2. Definition of the Boundary between M3UA and SCTP + + An example of the upper-layer primitives provided by the SCTP are + provided in Reference [18], Section 10. + + + + + +Morneault & Pastor-Balbas Standards Track [Page 23] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +1.6.3. Definition of the Boundary between M3UA and Layer Management + + M-SCTP_ESTABLISH request + Direction: LM -> M3UA + Purpose: LM requests that ASP establish an SCTP association with its + peer. + + M-SCTP_ESTABLISH confirm + Direction: M3UA -> LM + Purpose: ASP confirms to LM that it has established an SCTP + association with its peer. + + M-SCTP_ESTABLISH indication + Direction: M3UA -> LM + Purpose: M3UA informs LM that a remote ASP has established an SCTP + association. + + M-SCTP_RELEASE request + Direction: LM -> M3UA + Purpose: LM requests that ASP release an SCTP association with its + peer. + + M-SCTP_RELEASE confirm + Direction: M3UA -> LM + Purpose: ASP confirms to LM that it has released SCTP association + with its peer. + + M-SCTP_RELEASE indication + Direction: M3UA -> LM + Purpose: M3UA informs LM that a remote ASP has released an SCTP + Association or that the SCTP association has failed. + + M-SCTP_RESTART indication + Direction: M3UA -> LM + Purpose: M3UA informs LM that an SCTP restart indication has been + received. + + M-SCTP_STATUS request + Direction: LM -> M3UA + Purpose: LM requests that M3UA report the status of an SCTP + association. + + M-SCTP_STATUS confirm + Direction: M3UA -> LM + Purpose: M3UA responds with the status of an SCTP association. + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 24] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + M-SCTP STATUS indication + Direction: M3UA -> LM + Purpose: M3UA reports the status of an SCTP association. + + M-ASP_STATUS request + Direction: LM -> M3UA + Purpose: LM requests that M3UA report the status of a local or remote + ASP. + + M-ASP_STATUS confirm + Direction: M3UA -> LM + Purpose: M3UA reports the status of local or remote ASP. + + M-AS_STATUS request + Direction: LM -> M3UA + Purpose: LM requests that M3UA report the status of an AS. + + M-AS_STATUS confirm + Direction: M3UA -> LM + Purpose: M3UA reports the status of an AS. + + M-NOTIFY indication + Direction: M3UA -> LM + Purpose: M3UA reports that it has received a Notify message + from its peer. + + M-ERROR indication + Direction: M3UA -> LM + Purpose: M3UA reports that it has received an Error message from + its peer or that a local operation has been unsuccessful. + + M-ASP_UP request + Direction: LM -> M3UA + Purpose: LM requests that ASP start its operation and send an ASP Up + message to its peer. + + M-ASP_UP confirm + Direction: M3UA -> LM + Purpose: ASP reports that it has received an ASP UP Ack message from + its peer. + + M-ASP_UP indication + Direction: M3UA -> LM + Purpose: M3UA reports that it has successfully processed an incoming + ASP Up message from its peer. + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 25] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + M-ASP_DOWN request + Direction: LM -> M3UA + Purpose: LM requests that ASP stop its operation and send an ASP Down + message to its peer. + + M-ASP_DOWN confirm + Direction: M3UA -> LM + Purpose: ASP reports that it has received an ASP Down Ack message + from its peer. + + M-ASP_DOWN indication + Direction: M3UA -> LM + Purpose: M3UA reports that it has successfully processed an incoming + ASP Down message from its peer, or the SCTP association has + been lost/reset. + + M-ASP_ACTIVE request + Direction: LM -> M3UA + Purpose: LM requests that ASP send an ASP Active message to its peer. + + M-ASP_ACTIVE confirm + Direction: M3UA -> LM + Purpose: ASP reports that it has received an ASP Active + Ack message from its peer. + + M-ASP_ACTIVE indication + Direction: M3UA -> LM + Purpose: M3UA reports that it has successfully processed an incoming + ASP Active message from its peer. + + M-ASP_INACTIVE request + Direction: LM -> M3UA + Purpose: LM requests that ASP send an ASP Inactive message to its + peer. + + M-ASP_INACTIVE confirm + Direction: LM -> M3UA + Purpose: ASP reports that it has received an ASP Inactive + Ack message from its peer. + + M-ASP_INACTIVE indication + Direction: M3UA -> LM + Purpose: M3UA reports that it has successfully processed an incoming + ASP Inactive message from its peer. + + M-AS_ACTIVE indication + Direction: M3UA -> LM + Purpose: M3UA reports that an AS has moved to the AS-ACTIVE state. + + + +Morneault & Pastor-Balbas Standards Track [Page 26] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + M-AS_INACTIVE indication + Direction: M3UA -> LM + Purpose: M3UA reports that an AS has moved to the AS-INACTIVE state. + + M-AS_DOWN indication + Direction: M3UA -> LM + Purpose: M3UA reports that an AS has moved to the AS-DOWN state. + + If dynamic registration of RK is supported by the M3UA layer, the + layer MAY support the following additional primitives: + + M-RK_REG request + Direction: LM -> M3UA + Purpose: LM requests that ASP register RK(s) with its peer by sending + an REG REQ message + + M-RK_REG confirm + Direction: M3UA -> LM + Purpose: ASP reports that it has received REG RSP message with a + registration status of successful from its peer. + + M-RK_REG indication + Direction: M3UA -> LM + Purpose: M3UA informs LM that it has successfully processed an + incoming REG REQ message. + + M-RK_DEREG request + Direction: LM -> M3UA + Purpose: LM requests that ASP deregister RK(s) with its peer by + sending a DEREG REQ message. + + M-RK_DEREG confirm + Direction: M3UA -> LM + Purpose: ASP reports that it has received DEREG REQ message with a + deregistration status of successful from its peer. + + M-RK_DEREG indication + Direction: M3UA -> LM + Purpose: M3UA informs LM that it has successfully processed an + incoming DEREG REQ from its peer. + +2. Conventions + + In this document, the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL + NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and + OPTIONAL are to be interpreted as described in [21]. + + + + + +Morneault & Pastor-Balbas Standards Track [Page 27] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +3. M3UA Protocol Elements + + The general M3UA message format includes a Common Message Header + followed by zero or more parameters as defined by the Message Type. + For forward compatibility, all Message Types may have attached + parameters even if none are specified in this version. + +3.1. Common Message Header + + The protocol messages for MTP3-User Adaptation require a message + header that contains the adaptation layer version, the message type, + and message length. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version | Reserved | Message Class | Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / / + + All fields in an M3UA message MUST be transmitted in network byte + order, unless otherwise stated. + +3.1.1. M3UA Protocol Version: 8 bits (unsigned integer) + + The version field contains the version of the M3UA adaptation layer. + + The supported versions are as follows: + + 1 Release 1.0 + +3.1.2. Message Classes and Types + + The following list contains the valid Message Classes: + + Message Class: 8 bits (unsigned integer) + + The following list contains the valid Message Type Classes: + + 0 Management (MGMT) Messages + 1 Transfer Messages + 2 SS7 Signalling Network Management (SSNM) Messages + 3 ASP State Maintenance (ASPSM) Messages + 4 ASP Traffic Maintenance (ASPTM) Messages + 5 Reserved for Other SIGTRAN Adaptation Layers + + + +Morneault & Pastor-Balbas Standards Track [Page 28] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + 6 Reserved for Other SIGTRAN Adaptation Layers + 7 Reserved for Other SIGTRAN Adaptation Layers + 8 Reserved for Other SIGTRAN Adaptation Layers + 9 Routing Key Management (RKM) Messages + 10 to 127 Reserved by the IETF + 128 to 255 Reserved for IETF-Defined Message Class extensions + + Message Type: 8 bits (unsigned integer) + + The following list contains the message types for the defined + messages. + + Management (MGMT) Messages (see Section 3.8) + + 0 Error (ERR) + 1 Notify (NTFY) + 2 to 127 Reserved by the IETF + 128 to 255 Reserved for IETF-Defined MGMT extensions + + Transfer Messages (see Section 3.3) + + 0 Reserved + 1 Payload Data (DATA) + 2 to 127 Reserved by the IETF + 128 to 255 Reserved for IETF-Defined Transfer extensions + + SS7 Signalling Network Management (SSNM) Messages (see Section + 3.4) + + 0 Reserved + 1 Destination Unavailable (DUNA) + 2 Destination Available (DAVA) + 3 Destination State Audit (DAUD) + 4 Signalling Congestion (SCON) + 5 Destination User Part Unavailable (DUPU) + 6 Destination Restricted (DRST) + 7 to 127 Reserved by the IETF + 128 to 255 Reserved for IETF-Defined SSNM extensions + + ASP State Maintenance (ASPSM) Messages (see Section 3.5) + + 0 Reserved + 1 ASP Up (ASPUP) + 2 ASP Down (ASPDN) + 3 Heartbeat (BEAT) + 4 ASP Up Acknowledgement (ASPUP ACK) + 5 ASP Down Acknowledgement (ASPDN ACK) + 6 Heartbeat Acknowledgement (BEAT ACK) + + + +Morneault & Pastor-Balbas Standards Track [Page 29] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + 7 to 127 Reserved by the IETF + 128 to 255 Reserved for IETF-Defined ASPSM extensions + + ASP Traffic Maintenance (ASPTM) Messages (see Section 3.7) + + 0 Reserved + 1 ASP Active (ASPAC) + 2 ASP Inactive (ASPIA) + 3 ASP Active Acknowledgement (ASPAC ACK) + 4 ASP Inactive Acknowledgement (ASPIA ACK) + 5 to 127 Reserved by the IETF + 128 to 255 Reserved for IETF-Defined ASPTM extensions + + Routing Key Management (RKM) Messages (see Section 3.6) + + 0 Reserved + 1 Registration Request (REG REQ) + 2 Registration Response (REG RSP) + 3 Deregistration Request (DEREG REQ) + 4 Deregistration Response (DEREG RSP) + 5 to 127 Reserved by the IETF + 128 to 255 Reserved for IETF-Defined RKM extensions + +3.1.3. Reserved: 8 Bits + + The Reserved field SHOULD be set to all '0's and ignored by the + receiver. + +3.1.4. Message Length: 32-Bits (Unsigned Integer) + + The Message Length defines the length of the message in octets, + including the Common Header. The Message Length MUST include + parameter padding octets, if there are any. + + Note: A receiver SHOULD accept the message whether or not the final + parameter padding is included in the message length. + +3.2. Variable-Length Parameter Format + + M3UA messages consist of a Common Header followed by zero or more + variable-length parameters, as defined by the message type. All the + parameters contained in a message are defined in a Tag Length-Value + format, as shown below. + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 30] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Parameter Tag | Parameter Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Parameter Value / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Where more than one parameter is included in a message, the + parameters may be in any order, except where explicitly mandated. A + receiver SHOULD accept the parameters in any order. + + Unless explicitly stated or shown in a message format diagram, only + one parameter of the same type is allowed in a message. + + Parameter Tag: 16 bits (unsigned integer) + + The Tag field is a 16-bit identifier of the type of parameter. It + takes a value of 0 to 65534. Common parameters used by adaptation + layers are in the range of 0x00 to 0x3f. M3UA-specific parameters + have Tags in the range 0x0200 to 0x02ff. The parameter Tags + defined are as follows: + + Common Parameters. These TLV parameters are common across the + different adaptation layers: + + Parameter Name Parameter ID + ============== ============ + Reserved 0x0000 + Not Used in M3UA 0x0001 + Not Used in M3UA 0x0002 + Not Used in M3UA 0x0003 + INFO String 0x0004 + Not Used in M3UA 0x0005 + Routing Context 0x0006 + Diagnostic Information 0x0007 + Not Used in M3UA 0x0008 + Heartbeat Data 0x0009 + Not Used in M3UA 0x000a + Traffic Mode Type 0x000b + Error Code 0x000c + Status 0x000d + Not Used in M3UA 0x000e + Not Used in M3UA 0x000f + Not Used in M3UA 0x0010 + ASP Identifier 0x0011 + + + +Morneault & Pastor-Balbas Standards Track [Page 31] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Affected Point Code 0x0012 + Correlation ID 0x0013 + + M3UA-Specific parameters. These TLV parameters are specific to the + M3UA protocol: + + Network Appearance 0x0200 + Reserved 0x0201 + Reserved 0x0202 + Reserved 0x0203 + User/Cause 0x0204 + Congestion Indications 0x0205 + Concerned Destination 0x0206 + Routing Key 0x0207 + Registration Result 0x0208 + Deregistration Result 0x0209 + Local Routing Key Identifier 0x020a + Destination Point Code 0x020b + Service Indicators 0x020c + Reserved 0x020d + Originating Point Code List 0x020e + Reserved 0x020f + Protocol Data 0x0210 + Reserved 0x0211 + Registration Status 0x0212 + Deregistration Status 0x0213 + Reserved by the IETF 0x0214 to 0xffff + + The value of 65535 is reserved for IETF-defined extensions. + Values other than those defined in specific parameter descriptions + are reserved for use by the IETF. An RFC is required to make use + of parameter values "Reserved by the IETF". + + Parameter Length: 16 bits (unsigned integer) + + The Parameter Length field contains the size of the parameter in + octets, including the Parameter Tag, Parameter Length, and + Parameter Value fields. Thus, a parameter with a zero-length + Parameter Value field would have a Length field of 4. The + Parameter Length does not include any padding octets. If the + parameter contains subparameters, the Parameter Length field will + include all the octets of each subparameter, including + subparameter padding octets (if there are any). + + Parameter Value: variable length + + The Parameter Value field contains the actual information to be + transferred in the parameter. + + + +Morneault & Pastor-Balbas Standards Track [Page 32] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The total length of a parameter (including Tag, Parameter Length, + and Value fields) MUST be a multiple of 4 octets. If the length + of the parameter is not a multiple of 4 octets, the sender pads + the Parameter at the end (i.e., after the Parameter Value field) + with all zero octets. The length of the padding is NOT included + in the parameter length field. A sender MUST NOT pad with more + than 3 octets. The receiver MUST ignore the padding octets. + +3.3. Transfer Messages + + The following section describes the Transfer messages and parameter + contents. + +3.3.1. Payload Data Message (DATA) + + The DATA message contains the SS7 MTP3-User protocol data, which is + an MTP-TRANSFER primitive, including the complete MTP3 Routing Label. + The DATA message contains the following variable-length parameters: + + Network Appearance Optional + Routing Context Conditional + Protocol Data Mandatory + Correlation Id Optional + + The following format MUST be used for the Data Message: + + 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 = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network Appearance | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0006 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Routing Context | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0210 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Protocol Data / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0013 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Correlation Id | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Morneault & Pastor-Balbas Standards Track [Page 33] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Network Appearance: 32 bits (unsigned integer) + + The Network Appearance parameter identifies the SS7 network + context for the message and implicitly identifies the SS7 Point + Code format used, the SS7 Network Indicator value, and the MTP3 + and possibly the MTP3-User protocol type/variant/version used + within the specific SS7 network. Where an SG operates in the + context of a single SS7 network, or if individual SCTP + associations are dedicated to each SS7 network context, the + Network Appearance parameter is not required. In other cases, the + parameter may be configured to be present for the use of the + receiver. + + The Network Appearance parameter value is of local significance + only, coordinated between the SGP and ASP. Therefore, in the case + where an ASP is connected to more than one SGP, the same SS7 + network context may be identified by different Network Appearance + values, depending on which SGP a message is being transmitted/ + received. + + Where the optional Network Appearance parameter is present, it + MUST be the first parameter in the message, as it defines the + format of the Protocol Data field. + + IMPLEMENTATION NOTE: For simplicity of configuration, it may be + desirable to use the same NA value across all nodes sharing a + particular network context. + + Routing Context: 32 bits (unsigned integer) + + The Routing Context parameter contains the Routing Context value + associated with the DATA message. Where a Routing Key has not + been coordinated between the SGP and ASP, sending of Routing + Context is not required. Where multiple Routing Keys and Routing + Contexts are used across a common association, the Routing Context + MUST be sent to identify the traffic flow, assisting in the + internal distribution of Data messages. + + Protocol Data: variable length + + The Protocol Data parameter contains the original SS7 MTP3 + message, including the Service Information Octet and Routing + Label. + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 34] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The Protocol Data parameter contains the following fields: + + Service Indicator + Network Indicator + Message Priority + + Destination Point Code + Originating Point Code + + Signalling Link Selection Code (SLS) + + User Protocol Data, which includes + + MTP3-User protocol elements (e.g., ISUP, SCCP, or TUP + parameters) + + The Protocol Data parameter is encoded 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Originating Point Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination Point Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SI | NI | MP | SLS | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / User Protocol Data / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Originating Point Code: 32 bits (unsigned integer) + + Destination Point Code: 32 bits (unsigned integer) + + The Originating and Destination Point Code fields contains the OPC + and DPC from the routing label of the original SS7 message in Network + Byte Order, justified to the least significant bit. Unused bits are + coded `0'. + + Service Indicator: 8 bits (unsigned integer) + + The Service Indicator field contains the SI field from the original + SS7 message justified to the least significant bit. Unused bits are + coded `0'. + + + + + +Morneault & Pastor-Balbas Standards Track [Page 35] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Network Indicator: 8 bits (unsigned integer) + + The Network Indicator contains the NI field from the original SS7 + message justified to the least significant bit. Unused bits are + coded `0'. + + Message Priority: 8 bits (unsigned integer) + + The Message Priority field contains the MP bits (if any) from the + original SS7 message, both for ANSI-style and TTC-style [26] message + priority bits. The MP bits are aligned to the least significant bit. + Unused bits are coded `0'. + + Signalling Link Selection: 8 bits (unsigned integer) + + The Signalling Link Selection field contains the SLS bits from the + routing label of the original SS7 message justified to the least + significant bit and in Network Byte Order. Unused bits are coded + `0'. + + User Protocol Data: variable-length octet string + + The User Protocol Data field contains an octet string of MTP-User + information from the original SS7 message, starting with the first + octet of the original SS7 message following the Routing Label + [7][8][26]. + + Correlation Id: 32 bits (unsigned integer) + + The Correlation Id parameter uniquely identifies the MSU carried in + the Protocol Data within an AS. This Correlation Id parameter is + assigned by the sending M3UA. + +3.4. SS7 Signalling Network Management (SSNM) Messages + +3.4.1. Destination Unavailable (DUNA) + + The DUNA message is sent from an SGP in an SG to all concerned ASPs + to indicate that the SG has determined that one or more SS7 + destinations are unreachable. It is also sent by an SGP in response + to a message from the ASP to an unreachable SS7 destination. As an + implementation option, the SG may suppress the sending of subsequent + "response" DUNA messages regarding a certain unreachable SS7 + destination for a certain period to give the remote side time to + react. If there is no alternate route via another SG, the MTP3-User + at the ASP is expected to stop traffic to the affected destination + via the SG as per the defined MTP3-User procedures. + + + + +Morneault & Pastor-Balbas Standards Track [Page 36] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The DUNA message contains the following parameters: + + Network Appearance Optional + Routing Context Conditional + Affected Point Code Mandatory + INFO String Optional + + The format for DUNA 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 = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network Appearance | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0006 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Routing Context / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0012 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask | Affected PC 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / ... / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask | Affected PC n | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0004 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / INFO String / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Network Appearance: 32-bit unsigned integer + + The description of Network Appearance in Section 3.3.1 applies, + with the exception that Network Appearance does not have to be the + first parameter in this message. + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 37] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Routing Context: n x 32 bits (unsigned integer) + + The conditional Routing Context parameter contains the Routing + Context values associated with the DUNA message. Where a Routing + Key has not been coordinated between the SGP and ASP, sending of + Routing Context is not required. Where multiple Routing Keys and + Routing Contexts are used across a common association, the Routing + Context(s) MUST be sent to identify the concerned traffic flows + for which the DUNA message applies, assisting in outgoing traffic + management and internal distribution of MTP-PAUSE indications to + MTP3-Users at the receiver. + + Affected Point Code: n x 32 bits + + The Affected Point Code parameter contains a list of Affected + Destination Point Code fields, each a three-octet parameter to + allow for 14-, 16-, and 24-bit binary formatted SS7 Point Codes. + Affected Point Codes that are less than 24 bits are padded on the + left to the 24-bit boundary. The encoding is shown below for ANSI + and ITU Point Code examples. + + ANSI 24-bit Point Code + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask | Network | Cluster | Member | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + |MSB-----------------------------------------LSB| + + ITU 14-bit Point Code + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + |MSB--------------------LSB| + + It is optional to send an Affected Point Code parameter with more + than one Affected PC, but it is mandatory to receive it. + Including multiple Affected PCs may be useful when receipt of an + MTP3 management message or a linkset event simultaneously affects + the availability status of a list of destinations at an SG. + + + + + +Morneault & Pastor-Balbas Standards Track [Page 38] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Mask: 8 bits (unsigned integer) + + The Mask field can be used to identify a contiguous range of + Affected Destination Point Codes. Identifying a contiguous range + of Affected DPCs may be useful when receipt of an MTP3 management + message or a linkset event simultaneously affects the availability + status of a series of destinations at an SG. + + The Mask parameter is an integer representing a bit mask that can + be applied to the related Affected PC field. The bit mask + identifies how many bits of the Affected PC field are significant + and which are effectively "wildcarded". For example, a mask of + "8" indicates that the last eight bits of the PC are "wildcarded". + For an ANSI 24-bit Affected PC, this is equivalent to signalling + that all PCs in an ANSI Cluster are unavailable. A mask of "3" + indicates that the last three bits of the PC are "wildcarded". + For a 14-bit ITU Affected PC, this is equivalent to signaling that + an ITU Region is unavailable. A mask value equal (or greater + than) the number of bits in the PC indicates that the entire + network appearance is affected; this is used to indicate network + isolation to the ASP. + + INFO String: variable length + + The optional INFO String parameter can carry any meaningful UTF-8 + [10] character string along with the message. Length of the INFO + String parameter is from 0 to 255 octets. No procedures are + presently identified for its use, but the INFO String MAY be used + for debugging purposes. An INFO String with a zero-length + parameter is not considered an error (a zero length parameter is + one in which the Length field in the TLV will be set to 4). + +3.4.2. Destination Available (DAVA) + + The DAVA message is sent from an SGP to all concerned ASPs to + indicate that the SG has determined that one or more SS7 destinations + are now reachable (and not restricted), or in response to a DAUD + message, if appropriate. If the ASP M3UA layer previously had no + routes to the affected destinations, the ASP MTP3-User protocol is + informed and may now resume traffic to the affected destination. The + ASP M3UA layer now routes the MTP3-user traffic through the SG + initiating the DAVA message. + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 39] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The DAVA message contains the following parameters: + + Network Appearance Optional + Routing Context Conditional + Affected Point Code Mandatory + INFO String Optional + + The format and description of the Network Appearance, Routing + Context, Affected Point Code, and INFO String parameters are the same + as for the DUNA message (See Section 3.4.1). + +3.4.3. Destination State Audit (DAUD) + + The DAUD message MAY be sent from the ASP to the SGP to audit the + availability/congestion state of SS7 routes from the SG to one or + more affected destinations. + + The DAUD message contains the following parameters: + + Network Appearance Optional + Routing Context Conditional + Affected Point Code Mandatory + INFO String Optional + + The format and description of DAUD Message parameters are the same as + for the DUNA message (See Section 3.4.1). + + It is recommended that during normal operation (traffic handling) the + mask field of the Affected Point Code parameter in the DAUD message + be kept to a zero value in order to avoid SG overloading. + +3.4.4. Signalling Congestion (SCON) + + The SCON message can be sent from an SGP to all concerned ASPs to + indicate that an SG has determined that there is congestion in the + SS7 network to one or more destinations, or to an ASP in response to + a DATA or DAUD message, as appropriate. For some MTP protocol + variants (e.g., ANSI MTP) the SCON message may be sent when the SS7 + congestion level changes. The SCON message MAY also be sent from the + M3UA layer of an ASP to an M3UA peer, indicating that the congestion + level of the M3UA layer or the ASP has changed. + + IMPLEMENTATION NOTE: An M3UA node may maintain a timer to control + congestion notification validity, if desired. This timer will be + useful in cases where the peer node fails to indicate congestion + abatement. + + + + + +Morneault & Pastor-Balbas Standards Track [Page 40] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The SCON message contains the following parameters: + + Network Appearance Optional + Routing Context Conditional + Affected Point Code Mandatory + Concerned Destination Optional + Congestion Indications Optional + INFO String Optional + + 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 = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network Appearance | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0006 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Routing Context / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0012 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask | Affected PC 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / ... / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask | Affected PC n | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0206 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | reserved | Concerned DPC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0205 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Cong. Level | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0004 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / INFO String / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Morneault & Pastor-Balbas Standards Track [Page 41] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The format and description of the Network Appearance, Routing + Context, Affected Point Code, and INFO String parameters are the + same as for the DUNA message (see Section 3.4.1). + + The Affected Point Code parameter can be used to indicate + congestion of multiple destinations or ranges of destinations. + + Concerned Destination: 32 bits + + The optional Concerned Destination parameter is only used if the + SCON message is sent from an ASP to the SGP. It contains the + point code of the originator of the message that triggered the + SCON message. The Concerned Destination parameter contains one + Concerned Destination Point Code field, a three-octet parameter to + allow for 14-, 16-, and 24-bit binary formatted SS7 Point Codes. + A Concerned Point Code that is less than 24 bits is padded on the + left to the 24-bit boundary. Any resulting Transfer Controlled + (TFC) message from the SG is sent to the Concerned Point Code + using the single Affected DPC contained in the SCON message to + populate the (affected) Destination field of the TFC message + + Congested Indications: 32 bits + + The optional Congestion Indications parameter contains a + Congestion Level field. This optional parameter is used to + communicate congestion levels in national MTP networks with + multiple congestion thresholds, such as in ANSI MTP3. For MTP + congestion methods without multiple congestion levels (e.g., the + ITU international method) the parameter is not included. + + Congestion Level field: 8 bits (unsigned integer) + + The Congestion Level field, associated with all of the Affected + DPC(s) in the Affected Destinations 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 [7,8]. + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 42] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +3.4.5. Destination User Part Unavailable (DUPU) + + The DUPU message is used by an SGP to inform concerned ASPs that a + remote peer MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is + unavailable. + + The DUPU message contains the following parameters: + + Network Appearance Optional + Routing Context Conditional + Affected Point Code Mandatory + User/Cause Mandatory + INFO String Optional + + 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 = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network Appearance | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0006 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Routing Context / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0012 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask = 0 | Affected PC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0204 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cause | User | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0004 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / INFO String / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 43] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + User/Cause: 32 bits + + The Unavailability Cause and MTP3-User Identity fields, associated + with the Affected PC in the Affected Point Code parameter, are + encoded as follows: + + Unavailability Cause field: 16 bits (unsigned integer) + + The Unavailability Cause parameter provides the reason for the + unavailability of the MTP3-User. The valid values for the + Unavailability Cause parameter are shown in the following table. + The values agree with those provided in the SS7 MTP3 User Part + Unavailable message. Depending on the MTP3 protocol used in the + Network Appearance, additional values may be used; the + specification of the relevant MTP3 protocol variant/version + recommendation is definitive. + + 0 Unknown + 1 Unequipped Remote User + 2 Inaccessible Remote User + + MTP3-User Identity field: 16 bits (unsigned integer) + + The MTP3-User Identity describes the specific MTP3-User that is + unavailable (e.g., ISUP, SCCP, etc.). Some of the valid values + for the MTP3-User Identity are shown below. The values align with + those provided in the SS7 MTP3 User Part Unavailable message and + Service Indicator. Depending on the MTP3 protocol variant/version + used in the Network Appearance, additional values may be used. + The relevant MTP3 protocol variant/version recommendation is + definitive. + + 0 to 2 Reserved + 3 SCCP + 4 TUP + 5 ISUP + 6 to 8 Reserved + 9 Broadband ISUP + 10 Satellite ISUP + 11 Reserved + 12 AAL type 2 Signalling + 13 Bearer Independent Call Control (BICC) + 14 Gateway Control Protocol + 15 Reserved + + The format and description of the Affected Point Code parameter + are the same as for the DUNA message (see Section 3.4.1.) except + that the Mask field is not used and only a single Affected DPC is + + + +Morneault & Pastor-Balbas Standards Track [Page 44] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + included. Ranges and lists of Affected DPCs cannot be signaled in + a DUPU message, but this is consistent with UPU operation in the + SS7 network. The Affected Destinations parameter in an MTP3 User + Part Unavailable message (UPU) received by an SGP from the SS7 + network contains only one destination. + + The format and description of the Network Appearance, Routing + Context, and INFO String parameters are the same as for the DUNA + message (see Section 3.4.1). + +3.4.6. Destination Restricted (DRST) + + The DRST message is optionally sent from the SGP to all concerned + ASPs to indicate that the SG has determined that one or more SS7 + destinations are now restricted from the point of view of the SG, + or in response to a DAUD message, if appropriate. The M3UA layer + at the ASP is expected to send traffic to the affected destination + via an alternate SG with a route of equal priority, but only if + such an alternate route exists and is available. If the affected + destination is currently considered unavailable by the ASP, The + MTP3-User should be informed that traffic to the affected + destination can be resumed. In this case, the M3UA layer should + route the traffic through the SG initiating the DRST message. + + This message is optional for the SG to send, and it is optional + for the ASP to act on any information received in the message. It + is for use in the "STP" case described in Section 1.4.1. + + The DRST message contains the following parameters: + + Network Appearance Optional + Routing Context Conditional + Affected Point Code Mandatory + INFO String Optional + + The format and description of the Network Appearance, Routing + Context, Affected Point Code, and INFO String parameters are the + same as for the DUNA message (see Section 3.4.1). + +3.5. ASP State Maintenance (ASPSM) Messages + +3.5.1. ASP Up + + The ASP Up message is used to indicate to a remote M3UA peer that + the adaptation layer is ready to receive any ASPSM/ASPTM messages + for all Routing Keys that the ASP is configured to serve. + + + + + +Morneault & Pastor-Balbas Standards Track [Page 45] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The ASP Up message contains the following parameters: + + ASP Identifier Optional + INFO String Optional + + The format for ASP Up 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 = 0x0011 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ASP Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0004 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / INFO String / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + ASP Identifier: 32-bit unsigned integer + + The optional ASP Identifier parameter contains a unique value that + is locally significant among the ASPs that support an AS. The SGP + should save the ASP Identifier to be used, if necessary, with the + Notify message (see Section 3.8.2). + + The format and description of the optional INFO String parameter + are the same as for the DUNA message (see Section 3.4.1). + +3.5.2. ASP Up Acknowledgement (ASP Up Ack) + + The ASP UP Ack message is used to acknowledge an ASP Up message + received from a remote M3UA peer. + + The ASP Up Ack message contains the following parameters: + + ASP Identifier Optional + INFO String Optional + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 46] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The format for ASP Up Ack 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 = 0x0011 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ASP Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag =0x0004 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / INFO String / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The optional ASP Identifier parameter is specifically useful for IPSP + communication. In that case, the IPSP answering the ASP Up message + MAY include its own ASP Identifier value. + + The format and description of the optional INFO String parameter are + the same as for the DUNA message (see Section 3.4.1). The INFO + String in an ASP Up Ack message is independent from the INFO String + in the ASP Up message (i.e., it does not have to echo back the INFO + String received). + +3.5.3. ASP Down + + The ASP Down message is used to indicate to a remote M3UA peer that + the adaptation layer is NOT ready to receive DATA, SSNM, RKM, or + ASPTM messages. + + The ASP Down message contains the following parameter: + + INFO String Optional + + The format for the ASP Down 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 =0x0004 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / INFO String / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Morneault & Pastor-Balbas Standards Track [Page 47] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The format and description of the optional INFO String parameter are + the same as for the DUNA message (see Section 3.4.1). + +3.5.4. ASP Down Acknowledgement (ASP Down Ack) + + The ASP Down Ack message is used to acknowledge an ASP Down message + received from a remote M3UA peer. + + The ASP Down Ack message contains the following parameter: + + INFO String Optional + + The format for the ASP Down Ack 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 = 0x0004 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / INFO String / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The format and description of the optional INFO String parameter are + the same as for the DUNA message (See Section 3.4.1). + + The INFO String in an ASP Down Ack message is independent from the + INFO String in the ASP Down message (i.e., it does not have to echo + back the INFO String received). + +3.5.5. Heartbeat (BEAT) + + The BEAT message is optionally used to ensure that the M3UA peers are + still available to each other. It is recommended for use when the + M3UA runs over a transport layer other than the SCTP, which has its + own heartbeat. + + The BEAT message contains the following parameter: + + Heartbeat Data Optional + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 48] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The format for the BEAT message 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 = 0x0009 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Heartbeat Data / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Heartbeat Data parameter contents are defined by the sending + node. The Heartbeat Data could include, for example, a Heartbeat + Sequence Number and/or Timestamp. The receiver of a BEAT message + does not process this field, as it is only of significance to the + sender. The receiver MUST respond with a BEAT Ack message. + +3.5.6. Heartbeat Acknowledgement (BEAT Ack) + + The BEAT Ack message is sent in response to a received BEAT message. + It includes all the parameters of the received BEAT message, without + any change. + +3.6. Routing Key Management (RKM) Messages [Optional] + +3.6.1. Registration Request (REG REQ) + + The REG REQ message is sent by an ASP to indicate to a remote M3UA + peer that it wishes to register one or more given Routing Keys with + the remote peer. Typically, an ASP would send this message to an SGP + and expect to receive a REG RSP message in return with an associated + Routing Context value. + + The REG REQ message contains the following parameter: + + Routing Key Mandatory + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 49] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + One or more Routing Key parameters MAY be included. The format for + the REG REQ message 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 = 0x0207 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Routing Key 1 / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / ... / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0207 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Routing Key n / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Routing Key: variable length + + The Routing Key parameter is mandatory. The sender of this + message expects that the receiver of this message will create a + Routing Key entry and assign a unique Routing Context value to it, + if the Routing Key entry does not already exist. + + The Routing Key parameter may be present multiple times in the + same message. This is used to allow the registration of multiple + Routing Keys in a single message. + + + + + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 50] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The format of the Routing Key parameter 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local-RK-Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Routing Context (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Traffic Mode Type (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination Point Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network Appearance (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Service Indicators (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Originating Point Code List (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / ... / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination Point Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Service Indicators (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Originating Point Code List (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: The Destination Point Code, Service Indicators, and + Originating Point Code List parameters MAY be repeated as a + grouping within the Routing Key parameter, in the structure shown + above. + + Local-RK-Identifier: 32-bit unsigned integer + + The mandatory Local-RK-Identifier field is used to uniquely + identify the registration request. The Identifier value is + assigned by the ASP and used to correlate the response in an REG + RSP message with the original registration request. The + Identifier value must remain unique until the REG RSP message is + received. + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 51] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The format of the Local-RK-Identifier field 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 = 0x020a | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local-RK-Identifier value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Traffic Mode Type: 32-bit (unsigned integer) + + The optional Traffic Mode Type parameter identifies the traffic mode + of operation of the ASP(s) within an Application Server. The format + of the Traffic Mode Type Identifier 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 = 0x000b | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Traffic Mode Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The valid values for Traffic Mode Type are shown in the following + table: + + 1 Override + 2 Loadshare + 3 Broadcast + + Destination Point Code + + The Destination Point Code parameter is mandatory, and it + identifies the Destination Point Code of incoming SS7 traffic + for which the ASP is registering. For an alias point code + configuration, the DPC parameter would be repeated for each + point code. The format is the same as described for the + Affected Destination parameter in the DUNA message (see Section + 3.4.1). Its format is: + + 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 = 0x020b | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask = 0 | Destination Point Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Morneault & Pastor-Balbas Standards Track [Page 52] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Network Appearance + + The optional Network Appearance parameter field identifies the SS7 + network context for the Routing Key, and it has the same format as + in the DATA message (see Section 3.3.1) with the exception that it + does not have to be the first parameter in the message. If the + Network Appearance is not specified and the Routing Key applies to + all Network Appearances, then this Routing Key MUST be the only + one registered for the association; that is, Routing Context is + implied, and DATA and SSNM messages are discriminated on Network + Appearance rather than on Routing Context. Where Network + Appearance is not specified and there is only one Network + Appearance, then Network Appearance is implied. Its format is: + + 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 = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network Appearance | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Service Indicators (SI): n X 8-bit integers + + The optional SI [7,8] field contains one or more Service + Indicators from the values described in the MTP3-User Identity + field of the DUPU message. The absence of the SI parameter in the + Routing Key indicates the use of any SI value, excluding of course + MTP management. Where an SI parameter does not contain a multiple + of four SIs, the parameter is padded out to 32-byte alignment. + + The SI format is: + + 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 = 0x020c | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SI #1 | SI #2 | SI #3 | SI #4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / ... / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SI #n | 0 Padding, if necessary | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 53] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + OPC List + + The Originating Point Code List parameter contains one or more SS7 + OPC entries, and its format is the same as for the Destination + Point Code parameter. The absence of the OPC List parameter in + the Routing Key indicates the use of any OPC value. + + 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 = 0x020e | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask | Origination Point Code #1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask | Origination Point Code #2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / ... / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask | Origination Point Code #n | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +3.6.2. Registration Response (REG RSP) + + The REG RSP message is used as a response to the REG REQ message from + a remote M3UA peer. It contains indications of success/failure for + registration requests and returns a unique Routing Context value for + successful registration requests, to be used in subsequent M3UA + Traffic Management protocol. + + The REG RSP message contains the following parameter: + + Registration Result Mandatory + + One or more Registration Result parameters MUST be included. The + format for the REG RSP message is as follows: + + + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 54] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + 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 = 0x0208 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Registration Result 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / ... / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0208 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Registration Result n | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Registration Results + + The Registration Result parameter contains the registration result + for a single Routing Key in an REG REQ message. The number of + results in a single REG RSP message MUST be anywhere from one to + the total number of number of Routing Key parameters found in the + corresponding REG REQ message. Where multiple REG RSP messages + are used in reply to REG REQ message, a specific result SHOULD be + in only one REG RSP message. The format of each result 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 = 0x020a | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local-RK-Identifier value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0212 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Registration Status | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0006 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Routing Context | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Local-RK-Identifier: 32-bit integer + + The Local-RK-Identifier contains the same value as found in the + matching Routing Key parameter found in the REG REQ message (See + Section 3.6.1). + + + +Morneault & Pastor-Balbas Standards Track [Page 55] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Registration Status: 32-bit integer + + The Registration Result Status field indicates the success or the + reason for failure of a registration request. + + Its values may be: + + 0 Successfully Registered + 1 Error - Unknown + 2 Error - Invalid DPC + 3 Error - Invalid Network Appearance + 4 Error - Invalid Routing Key + 5 Error - Permission Denied + 6 Error - Cannot Support Unique Routing + 7 Error - Routing Key not Currently Provisioned + 8 Error - Insufficient Resources + 9 Error - Unsupported RK parameter Field + 10 Error - Unsupported/Invalid Traffic Handling Mode + 11 Error - Routing Key Change Refused + 12 Error - Routing Key Already Registered + + Routing Context: 32-bit integer + + The Routing Context field contains the Routing Context value for + the associated Routing Key if the registration was successful. It + is set to "0" if the registration was not successful. + +3.6.3. Deregistration Request (DEREG REQ) + + The DEREG REQ message is sent by an ASP to indicate to a remote M3UA + peer that it wishes to deregister a given Routing Key. Typically, an + ASP would send this message to an SGP and expects to receive a DEREG + RSP message in return with the associated Routing Context value. + + The DEREG REQ message contains the following parameters: + + Routing Context Mandatory + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 56] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The format for the DEREG REQ message 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 = 0x0006 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Routing Context / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Routing Context: n X 32-bit integers + + The Routing Context parameter contains (a list of) integers + indexing the Application Server traffic that the sending ASP is + currently registered to receive from the SGP but now wishes to + deregister. + +3.6.4. Deregistration Response (DEREG RSP) + + The DEREG RSP message is used as a response to the DEREG REQ message + from a remote M3UA peer. + + The DEREG RSP message contains the following parameter: + + Deregistration Result Mandatory + + One or more Deregistration Result parameters MUST be included. The + format for the DEREG RSP message 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 = 0x0209 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Deregistration Result 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / ... / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0209 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Deregistration Result n | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + +Morneault & Pastor-Balbas Standards Track [Page 57] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Deregistration Results + + The Deregistration Result parameter contains the deregistration + status for a single Routing Context in a DEREG REQ message. The + number of results in a single DEREG RSP message MAY be anywhere + from one to the total number of number of Routing Context values + found in the corresponding DEREG REQ message. + + Where multiple DEREG RSP messages are used in reply to DEREG REQ + message, a specific result SHOULD be in only one DEREG RSP + message. The format of each result 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 = 0x0006 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Routing Context | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0213 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Deregistration Status | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Routing Context: 32-bit integer + + The Routing Context field contains the Routing Context value of + the matching Routing Key to deregister, as found in the DEREG REQ + message. + + Deregistration Status: 32-bit integer + + The Deregistration Result Status field indicates the success or + the reason for failure of the deregistration. + + Its values may be: + + 0 Successfully Deregistered + 1 Error - Unknown + 2 Error - Invalid Routing Context + 3 Error - Permission Denied + 4 Error - Not Registered + 5 Error - ASP Currently Active for Routing Context + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 58] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +3.7. ASP Traffic Maintenance (ASPTM) Messages + +3.7.1. ASP Active + + The ASP Active message is sent by an ASP to indicate to a remote M3UA + peer that it is ready to process signalling traffic for a particular + Application Server. The ASP Active message affects only the ASP + state for the Routing Keys identified by the Routing Contexts, if + present. + + The ASP Active message contains the following parameters: + + Traffic Mode Type Optional + Routing Context Optional + INFO String Optional + + The format for the ASP Active message 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 = 0x000b | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Traffic Mode Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0006 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Routing Context / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0004 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / INFO String / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Traffic Mode Type: 32-bit (unsigned integer) + + The Traffic Mode Type parameter identifies the traffic mode of + operation of the ASP within an AS. The valid values for Traffic + Mode Type are shown in the following table: + + 1 Override + 2 Loadshare + 3 Broadcast + + + + +Morneault & Pastor-Balbas Standards Track [Page 59] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Within a particular Routing Context, Override, Loadshare, and + Broadcast SHOULD NOT be mixed. The Override value indicates that + the ASP is operating in Override mode, in which the ASP takes over + all traffic in an Application Server (i.e., primary/backup + operation), overriding any currently active ASPs in the AS. In + Loadshare mode, the ASP will share in the traffic distribution + with any other currently active ASPs. In Broadcast mode, the ASP + will receive the same messages as any other currently active ASP. + + Routing Context: n X 32-bit integers + + The optional Routing Context parameter contains (a list of) + integers indexing the Application Server traffic that the sending + ASP is configured/registered to receive. + + There is a one-to-one relationship between an index entry and an + SGP Routing Key or AS Name. Because an AS can only appear in one + Network Appearance, the Network Appearance parameter is not + required in the ASP Active message. + + An Application Server Process may be configured to process traffic + for more than one logical Application Server. From the + perspective of an ASP, a Routing Context defines a range of + signalling traffic that the ASP is currently configured to receive + from the SGP. For example, an ASP could be configured to support + signalling for multiple MTP3-Users, identified by separate SS7 + DPC/OPC/SI ranges. + + The format and description of the optional INFO String parameter are + the same as for the DUNA message (see Section 3.4.1). + +3.7.2. ASP Active Acknowledgement (ASP Active Ack) + + The ASP Active Ack message is used to acknowledge an ASP Active + message received from a remote M3UA peer. + + The ASP Active Ack message contains the following parameters: + + Traffic Mode Type Optional + Routing Context Optional + INFO String Optional + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 60] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The format for the ASP Active Ack message 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 = 0x000b | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Traffic Mode Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0006 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Routing Context / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0004 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / INFO String / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The format and description of the optional INFO String parameter are + the same as for the DUNA message (see Section 3.4.1). + + The INFO String in an ASP Active Ack message is independent from the + INFO String in the ASP Active message (i.e., it does not have to echo + back the INFO String received). + + The format of the Traffic Mode Type and Routing Context parameters is + the same as for the ASP Active message. (See Section 3.7.1.) + +3.7.3. ASP Inactive + + The ASP Inactive message is sent by an ASP to indicate to a remote + M3UA peer that it is no longer an active ASP to be used from within a + list of ASPs. The ASP Inactive message affects only the ASP state in + the Routing Keys identified by the Routing Contexts, if present. + + The ASP Inactive message contains the following parameters: + + Routing Context Optional + INFO String Optional + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 61] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The format for the ASP Inactive 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 = 0x0006 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Routing Context / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0004 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / INFO String / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The format and description of the optional Routing Context and INFO + String parameters are the same as for the ASP Active message (see + Section 3.5.5.) + +3.7.4. ASP Inactive Acknowledgement (ASP Inactive Ack) + + The ASP Inactive Ack message is used to acknowledge an ASP Inactive + message received from a remote M3UA peer. + + The ASP Inactive Ack message contains the following parameters: + + Routing Context Optional + INFO String Optional + + + + + + + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 62] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The format for the ASP Inactive Ack message 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 = 0x0006 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Routing Context / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0004 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / INFO String / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The format and description of the optional INFO String parameter are + the same as for the DUNA message (see Section 3.4.1). + + The INFO String in an ASP Inactive Ack message is independent from + the INFO String in the ASP Inactive message (i.e., it does not have + to echo back the INFO String received). + + The format of the Routing Context parameter is the same as for the + ASP Inactive message. (see Section 3.7.3.) + +3.8. Management (MGMT) Messages + +3.8.1. Error + + The Error message is used to notify a peer of an error event + associated with an incoming message. For example, the message type + might be unexpected given the current state, or a parameter value + might be invalid. Error messages MUST NOT be generated in response + to other Error messages. + + The Error message contains the following parameters: + + Error Code Mandatory + Routing Context Mandatory* + Network Appearance Mandatory* + Affected Point Code Mandatory* + Diagnostic Information Conditional + + * Only mandatory for specific Error Codes. + + + + +Morneault & Pastor-Balbas Standards Track [Page 63] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The format for the Error message 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 = 0x000c | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Error Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0006 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Routing Context / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag - 0x0012 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask | Affected Point Code 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / ... / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask | Affected Point Code n | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0200 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network Appearance | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0007 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Diagnostic Information / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Error Code: 32 bits (unsigned integer) + + The Error Code parameter indicates the reason for the Error + Message. The Error parameter value can be one of the following + values: + + 0x01 Invalid Version + 0x02 Not Used in M3UA + 0x03 Unsupported Message Class + 0x04 Unsupported Message Type + 0x05 Unsupported Traffic Mode Type + 0x06 Unexpected Message + + + +Morneault & Pastor-Balbas Standards Track [Page 64] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + 0x07 Protocol Error + 0x08 Not Used in M3UA + 0x09 Invalid Stream Identifier + 0x0a Not Used in M3UA + 0x0b Not Used in M3UA + 0x0c Not Used in M3UA + 0x0d Refused - Management Blocking + 0x0e ASP Identifier Required + 0x0f Invalid ASP Identifier + 0x10 Not Used in M3UA + 0x11 Invalid Parameter Value + 0x12 Parameter Field Error + 0x13 Unexpected Parameter + 0x14 Destination Status Unknown + 0x15 Invalid Network Appearance + 0x16 Missing Parameter + 0x17 Not Used in M3UA + 0x18 Not Used in M3UA + 0x19 Invalid Routing Context + 0x1a No Configured AS for ASP + + The "Invalid Version" error is sent if a message with an unsupported + version is received. The receiving end responds with an Error + message, indicating the version the receiving node supports, and + notifies layer management. + + The "Unsupported Message Class" error is sent if a message with an + unexpected or unsupported Message Class is received. For this error, + the Diagnostic Information parameter MUST be included with the first + 40 octets of the offending message. + + The "Unsupported Message Type" error is sent if a message with an + unexpected or unsupported Message Type is received. For this error, + the Diagnostic Information parameter MUST be included with the first + 40 octets of the offending message. + + The "Unsupported Traffic Mode Type" error is sent by a SGP if an ASP + sends an ASP Active message with an unsupported Traffic Mode Type or + a Traffic Mode Type that is inconsistent with the presently + configured mode for the Application Server. An example would be a + case in which the SGP did not support loadsharing. + + The "Unexpected Message" error MAY be sent if a defined and + recognized message is received that is not expected in the current + state (in some cases, the ASP may optionally silently discard the + message and not send an Error message). For example, silent discard + is used by an ASP if it received a DATA message from an SGP while it + was in the ASP-INACTIVE state. If the Unexpected message contained + + + +Morneault & Pastor-Balbas Standards Track [Page 65] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Routing Contexts, the Routing Contexts SHOULD be included in the + Error message. + + The "Protocol Error" error is sent for any protocol anomaly (i.e., + receipt of a parameter that is syntactically correct but unexpected + in the current situation). + + The "Invalid Stream Identifier" error is sent if a message is + received on an unexpected SCTP stream (e.g., a Management message was + received on a stream other than "0"). + + The "Refused - Management Blocking" error is sent when an ASP Up or + ASP Active message is received and the request is refused for + management reasons (e.g., management lockout). If this error is in + response to an ASP Active message, the Routing Context(s) in the ASP + Active message SHOULD be included in the Error message. + + The "ASP Identifier Required" error is sent by an SGP in response to + an ASP Up message that does not contain an ASP Identifier parameter + when the SGP requires one. The ASP SHOULD resend the ASP Up message + with an ASP Identifier. + + The "Invalid ASP Identifier" error is sent by an SGP in response to + an ASP Up message with an invalid (i.e., non-unique) ASP Identifier. + + The "Invalid Parameter Value" error is sent if a message is received + with an invalid parameter value (e.g., a DUPU message was received + with a Mask value other than "0". + + The "Parameter Field Error" would be sent if a message is received + with a parameter having a wrong length field. + + The "Unexpected Parameter" error would be sent if a message contains + an invalid parameter. + + The "Destination Status Unknown" error MAY be sent if a DAUD is + received at an SG enquiring of the availability/congestion status of + a destination and the SG does not wish to provide the status (e.g., + the sender is not authorized to know the status). For this error, + the invalid or unauthorized Point Code(s) MUST be included along with + the Network Appearance and/or Routing Context associated with the + Point Code(s). + + The "Invalid Network Appearance" error is sent by an SGP if an ASP + sends a message with an invalid (unconfigured) Network Appearance + value. For this error, the invalid (unconfigured) Network Appearance + MUST be included in the Network Appearance parameter. + + + + +Morneault & Pastor-Balbas Standards Track [Page 66] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The "Missing Parameter" error would be sent if a mandatory parameter + were not included in a message. This error is also sent if a + conditional parameter is not included in the message but is required + in the context of the received message. + + The "Invalid Routing Context" error is sent if a message is received + from a peer with an invalid (unconfigured) Routing Context value. + For this error, the invalid Routing Context(s) MUST be included in + the Error message. + + The "No Configured AS for ASP" error is sent if a message is received + from a peer without a Routing Context parameter and it is not known + by configuration data which Application Servers are referenced. + + Diagnostic Information: variable length + + When included, the optional Diagnostic Information can be any + information germane to the error condition, to assist in + identification of the error condition. The Diagnostic Information + SHOULD contain the offending message. A Diagnostic Information + parameter with a zero length parameter is not considered an error + (this means that the Length field in the TLV will be set to 4). + +3.8.2. Notify + + The Notify message used to provide an autonomous indication of M3UA + events to an M3UA peer. + + The Notify message contains the following parameters: + + Status Mandatory + ASP Identifier Conditional + Routing Context Optional + INFO String Optional + + The format for the Notify message is as follows: + + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 67] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + 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 = 0x000d | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Status Type | Status Information | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0011 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ASP Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0006 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / Routing Context / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Tag = 0x0004 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / INFO String / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Status Type: 16 bits (unsigned integer) + + The Status Type parameter identifies the type of the Notify + message. The following are the valid Status Type values: + + 1 Application Server State Change (AS-State_Change) + 2 Other + + Status Information: 16 bits (unsigned integer) + + The Status Information parameter contains more detailed + information for the notification, based on the value of the Status + Type. If the Status Type is AS-State_Change the following Status + Information values are used: + + 1 Reserved + 2 Application Server Inactive (AS-INACTIVE) + 3 Application Server Active (AS-ACTIVE) + 4 Application Server Pending (AS-PENDING) + + These notifications are sent from an SGP to an ASP upon a change + in status of a particular Application Server. The value reflects + the new state of the Application Server. + + + + +Morneault & Pastor-Balbas Standards Track [Page 68] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + If the Status Type is Other, then the following Status Information + values are defined: + + 1 Insufficient ASP Resources Active in AS + 2 Alternate ASP Active + 3 ASP Failure + + These notifications are not based on the SGP reporting the state + change of an ASP or AS. In the Insufficient ASP Resources case, + the SGP is indicating to an ASP_INACTIVE ASP in the AS that + another ASP is required to handle the load of the AS (Loadsharing + or Broadcast mode). For the Alternate ASP Active case, an ASP is + informed when an alternate ASP transitions to the ASP-ACTIVE state + in Override mode. The ASP Identifier (if available) of the + Alternate ASP MUST be placed in the message. For the ASP Failure + case, the SGP is indicating to ASPs in the AS that one of the + ASPs has failed. The ASP Identifier (if available) of the failed + ASP MUST be placed in the message. + + The format and description of the conditional ASP Identifier is the + same as for the ASP Up message (see Section 3.5.1). The format and + description of the Routing Context and Info String parameters are the + same as for the ASP Active message (See Section 3.7.1) + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 69] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +4. Procedures + + The M3UA layer needs to respond to various local primitives it + receives from other layers, as well as to the messages that it + receives from the peer M3UA layer. This section describes the M3UA + procedures in response to these events. + +4.1. Procedures to Support the M3UA-User + +4.1.1. Receipt of Primitives from the M3UA-User + + On receiving an MTP-TRANSFER request primitive from an upper layer at + an ASP/IPSP, or the nodal interworking function at an SGP, the M3UA + layer sends a corresponding DATA message (see Section 3) to its M3UA + peer. The M3UA peer receiving the DATA message sends an MTP-TRANSFER + indication primitive to the upper layer. + + The M3UA message distribution function (see Section 1.4.2.1) + determines the Application Server (AS) by comparing the information + in the MTP-TRANSFER request primitive with a provisioned Routing Key. + + From the list of ASPs within the AS table, an ASP in the ASP-ACTIVE + state is selected and a DATA message is constructed and issued on the + corresponding SCTP association. If more than one ASP is in the ASP- + ACTIVE state (i.e., traffic is to be loadshared across more than one + ASP), one of the ASPs in the ASP-ACTIVE state is selected from the + list. If the ASPs are in Broadcast Mode, all active ASPs will be + selected, and the message will be sent to each of the active ASPs. + The selection algorithm is implementation dependent but could, for + example, be round robin or based on the SLS or ISUP CIC. The + appropriate selection algorithm must be chosen carefully, as it is + dependent on application assumptions and understanding of the degree + of state coordination between the ASP-ACTIVE ASPs in the AS. + + In addition, the message needs to be sent on the appropriate SCTP + stream, again taking care to meet the message sequencing needs of the + signalling application. DATA messages MUST be sent on an SCTP stream + other than stream '0'. + + When there is no Routing Key match, or only a partial match, for an + incoming SS7 message, a default treatment MAY be specified. Possible + solutions are to provide a default Application Server at the SGP that + directs all unallocated traffic to a (set of) default ASP(s), or to + drop the message and provide a notification to Layer Management in an + M-ERROR indication primitive. The treatment of unallocated traffic + is implementation dependent. + + + + + +Morneault & Pastor-Balbas Standards Track [Page 70] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +4.2. Receipt of Primitives from the Layer Management + + On receiving primitives from the local Layer Management, the M3UA + layer will take the requested action and provide an appropriate + response primitive to Layer Management. + + An M-SCTP_ESTABLISH request primitive from Layer Management at an ASP + or IPSP will initiate the establishment of an SCTP association. The + M3UA layer will attempt to establish an SCTP association with the + remote M3UA peer by sending an SCTP-ASSOCIATE primitive to the local + SCTP layer. + + When an SCTP association has been successfully established, the SCTP + will send an SCTP-COMMUNICATION_UP notification primitive to the + local M3UA layer. At the SGP or IPSP that initiated the request, the + M3UA layer will send an M-SCTP_ESTABLISH confirm primitive to Layer + Management when the association setup is complete. At the peer M3UA + layer, an M-SCTP_ESTABLISH indication primitive is sent to Layer + Management upon successful completion of an incoming SCTP association + setup. + + An M-SCTP_RELEASE request primitive from Layer Management initiates + the teardown of an SCTP association. The M3UA layer accomplishes a + graceful shutdown of the SCTP association by sending an SCTP-SHUTDOWN + primitive to the SCTP layer. + + When the graceful shutdown of the SCTP association has been + accomplished, the SCTP layer returns an SCTP-SHUTDOWN_COMPLETE + notification primitive to the local M3UA layer. At the M3UA Layer + that initiated the request, the M3UA layer will send an M- + SCTP_RELEASE confirm primitive to Layer Management when the + association shutdown is complete. At the peer M3UA Layer, an M- + SCTP_RELEASE indication primitive is sent to Layer Management upon + abort or successful shutdown of an SCTP association. + + An M-SCTP_STATUS request primitive supports a Layer Management query + of the local status of a particular SCTP association. The M3UA layer + simply maps the M-SCTP_STATUS request primitive to an SCTP-STATUS + primitive to the SCTP layer. When the SCTP responds, the M3UA layer + maps the association status information to an M-SCTP_STATUS confirm + primitive. No peer protocol is invoked. + + Similar LM-to-M3UA-to-SCTP and/or SCTP-to-M3UA-to-LM primitive + mappings can be described for the various other SCTP Upper Layer + primitives in RFC2960 [18], such as INITIALIZE, SET PRIMARY, CHANGE + HEARTBEAT, REQUEST HEARTBEAT, GET SRTT REPORT, SET FAILURE THRESHOLD, + SET PROTOCOL PARAMETERS, DESTROY SCTP INSTANCE, SEND FAILURE, and + NETWORK STATUS CHANGE. Alternatively, these SCTP Upper Layer + + + +Morneault & Pastor-Balbas Standards Track [Page 71] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + primitives (and Status as well) can be considered, for modeling + purposes, as a Layer Management interaction directly with the SCTP + Layer. + + M-NOTIFY indication and M-ERROR indication primitives indicate to + Layer Management the notification or error information contained in a + received M3UA Notify or Error message, respectively. These + indications can also be generated based on local M3UA events. + + An M-ASP_STATUS request primitive supports a Layer Management query + of the status of a particular local or remote ASP. The M3UA layer + responds with the status in an M-ASP_STATUS confirm primitive. No + M3UA peer protocol is invoked. + + An M-AS_STATUS request supports a Layer Management query of the + status of a particular AS. The M3UA responds with an M-AS_STATUS + confirm primitive. No M3UA peer protocol is invoked. + + M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE, and M-ASP_INACTIVE request + primitives allow Layer Management at an ASP to initiate state + changes. Upon successful completion, a corresponding confirm + primitive is provided by the M3UA layer to Layer Management. If an + invocation is unsuccessful, an Error indication primitive is provided + in the primitive. These requests result in outgoing ASP Up, ASP + Down, ASP Active, and ASP Inactive messages to the remote M3UA peer + at an SGP or IPSP. + +4.2.1. Receipt of M3UA Peer Management Messages + + Upon successful state changes resulting from reception of ASP Up, ASP + Down, ASP Active, and ASP Inactive messages from a peer M3UA, the + M3UA layer MAY invoke corresponding M-ASP_UP, M-ASP_DOWN, M- + ASP_ACTIVE, M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M-AS_DOWN + indication primitives to the local Layer Management. + + M-NOTIFY indication and M-ERROR indication primitives indicate to + Layer Management the notification or error information contained in a + received M3UA Notify or Error message. These indications can also be + generated based on local M3UA events. + + All non-Transfer and non-SSNM messages, except BEAT and BEAT Ack, + SHOULD be sent with sequenced delivery to ensure ordering. ASPTM + messages MAY be sent on one of the streams used to carry the data + traffic related to the Routing Context(s), to minimize possible + message loss. BEAT and BEAT Ack messages MAY be sent using out-of- + order delivery and MAY be sent on any stream. + + + + + +Morneault & Pastor-Balbas Standards Track [Page 72] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +4.3. AS and ASP/IPSP State Maintenance + + The M3UA layer on the SGP maintains the state of each remote ASP, in + each Application Server that the ASP is configured to receive + traffic, as input to the M3UA message distribution function. + Similarly, where IPSPs use M3UA in a point-to-point fashion, the M3UA + layer in an IPSP maintains the state of remote IPSPs. + + Two IPSP models are defined as follows: + + 1. IPSP Single Exchange (SE) model. Only a single exchange of ASPTM + and ASPSM messages is needed to change the IPSP states. This + means that a set of requests from one end and acknowledgements + from the other will be enough. The RK must define both sides of + the traffic flow. Each exchange of ASPTM or ASPSM messages can be + initiated by either IPSP. For this exchange, the initiating IPSP + follows the procedures described in Section 4.3.1. + + 2. IPSP Double Exchange (DE) model. A double exchange of ASPTM and + ASPSM messages is normally needed (ASPSM single exchange is + optional as a simplification). Each exchange of ASPTM or ASPSM + messages can be initiated by either IPSP. The RKs define the + traffic to be directed to the peer as in the AS-SG model. + Therefore, two different RKs are usually used, one installed on + each peer. + + When using double exchanges for ASPSM messages, the management of + the connection in the two directions is considered independent. + This means that connections from IPSP-A to IPSP-B is handled + independently of connections from IPSP-B to IPSP-A. Therefore, it + could happen that only one of the two directions is activated or + closed, while the other remains in the same state as it was. + + When using single exchange of ASPSM, what is seen as a + simplification, only the activation phase (ASPTM messages) is + independent for each of the two directions. In this case, it + could happen that the sending of the ASPSM from IPSP-A or IPSP-B + could have an effect in the whole communication, as it is defined + in the standard SG-AS communication. + + Because of these differences, there should be an agreement on the + way ASPSM messages are being handled before starting DE-IPSP + communication. + + In order to ensure interoperability, an M3UA implementation + supporting IPSP communication MUST support the IPSP SE model and MAY + implement the IPSP DE model. + + + + +Morneault & Pastor-Balbas Standards Track [Page 73] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + In Section 4.3.1, ASP/IPSP States are described. + + In Section 4.3.2, only the SGP-ASP scenario is described. All of the + procedures referring to an AS served by ASPs are also applicable to + ASes served by IPSPs. + + In Section 4.3.3, only the Management procedures for the SGP-ASP + scenario are described. The corresponding Management procedures for + IPSPs are directly implied. + + The remaining sections contain specific IPSP Considerations + subsections. + +4.3.1. ASP/IPSP States + + The state of each remote ASP/IPSP, in each AS that it is configured + to operate, is maintained in the peer M3UA layer (i.e., in the SGP or + peer IPSP, respectively). The state of a particular ASP/IPSP in a + particular AS changes due to events. The events include: + + * Receipt of messages from the peer M3UA layer at the ASP/IPSP; + * Receipt of some messages from the peer M3UA layer at other + ASPs/IPSPs in the AS (e.g., ASP Active message indicating + "Override"); + * Receipt of indications from the SCTP layer; and + * Local Management intervention. + + The ASP/C-IPSP/D-IPSP state transition diagram is shown in Figure 3. + The possible states of an ASP/D-IPSP/C-IPSP are: + + ASP-DOWN: The remote M3UA peer at the ASP/IPSP is unavailable, and/or + the related SCTP association is down. Initially, all ASPs/IPSPs will + be in this state. An ASP/IPSP in this state SHOULD NOT be sent any + M3UA messages, with the exception of Heartbeat, ASP Down Ack, and + Error messages. + + ASP-INACTIVE: The remote M3UA peer at the ASP/IPSP is available (and + the related SCTP association is up), but application traffic is + stopped. In this state, the ASP/IPSP SHOULD NOT be sent any DATA or + SSNM messages for the AS for which the ASP/IPSP is inactive. + + ASP-ACTIVE: The remote M3UA peer at the ASP/IPSP is available and + application traffic is active (for a particular Routing Context or + set of Routing Contexts). + + SCTP CDI: The SCTP CDI denotes the local SCTP layer's Communication + Down Indication to the Upper Layer Protocol (M3UA) on an SGP. The + local SCTP layer will send this indication when it detects the loss + + + +Morneault & Pastor-Balbas Standards Track [Page 74] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + of connectivity to the ASP's peer SCTP layer. SCTP CDI is understood + as either a SHUTDOWN_COMPLETE notification or a COMMUNICATION_LOST + notification from the SCTP layer. + + SCTP RI: The local SCTP layer's Restart indication to the upper-layer + protocol (M3UA) on an SG. The local SCTP will send this indication + when it detects a restart from the peer SCTP layer. + + +--------------+ + | | + +----------------------| ASP-ACTIVE | + | Other ASP/ +-------| | + | IPSP in AS | +--------------+ + | Overrides | ^ | + | | ASPAC/ | | ASPIA/ + | |[ASPAC-Ack]| | [ASPIA-Ack] + | | | v + | | +--------------+ + | | | | + | +------>| ASP-INACTIVE | + | | | + | +--------------+ + | ^ | + ASPDN/ | | | ASPDN / + [ASPDN-Ack/]| ASPUP/ | | [ASPDN-Ack /] + SCTP CDI/ | [ASPUP-Ack] | | SCTP CDI/ + SCTP RI | | | SCTP RI + | | v + | +--------------+ + | | | + +--------------------->| ASP-DOWN | + | | + +--------------+ + + Figure 3: ASP State Transition Diagram, per AS + + The transitions are depicted as a result of the reception of ASP*M + messages or other events. In some of the transitions, there are some + messages in brackets. They mean that for a given node the state + transition will be different, depending on its role: whether or not + it is generating the ASP*M request message (i.e., ASPUP, ASPAC, ASPIA + or ASPDN) or simply receiving it. In a peer-to-peer based + architecture (IPSP), this role may change between the peers. + + The transitions not in brackets are valid to track the states of ASPs + and IPSPs that send an ASP*M request message at the peer node. + + + + + +Morneault & Pastor-Balbas Standards Track [Page 75] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The transition in brackets may be used in an ASP or in the IPSP that + receives an ASP*M request to track the peer SGP/IPSP states, + respectively. There may be an SGP per AS state machine at ASPs. + + Then, the transitions in brackets can be used for the IPSP DE model + communication (DE-IPSPs) and are related to the special cases when + just one ASP*M messages exchange is needed, as follows: + + - ASPSM messages. When ASPSM messages are exchanged using only a + single exchange (only one request and one acknowledgement). + Example (see Section 5.6.2): Whenever a DE-IPSP is taking the + leading role to start communication to a peer DE-IPSP, it sends an + ASP Up message to the peer DE-IPSP. The peer MAY consider the + initiating DE-IPSPs to be in ASP-INACTIVE state, as it already sent + a message, and answer back with ASP Up Ack. Upon receipt of this + answer by the initiating DE-IPSP, it also MAY consider the peer to + be in ASP-INACTIVE state, since it did respond. Therefore, a + second ASP Up message exchange to be started by the peer DE-IPSP + could be avoided. In this case, the receipt of ASP Up Ack will + turn into a state change. + + - ASPTM messages. When sending ASPTM messages to activate/deactivate + all the traffic independently of routing keys by not specifying any + RC, a single exchange could be sufficient. + +4.3.2. AS States + + The state of the AS is maintained in the M3UA layer on the SGPs. The + state of an AS changes due to events. These events include: + + * ASP state transitions + * Recovery timer triggers + + The possible states of an AS are: + + AS-DOWN: The Application Server is unavailable. This state implies + that all related ASPs are in ASP-DOWN state for this AS. Initially + the AS will be in this state. An Application Server is in the AS- + DOWN state when it is removed from a configuration. + + AS-INACTIVE: The Application Server is available, but no application + traffic is active. One or more related ASPs are in ASP-INACTIVE + state, and/or the number of related ASPs in ASP-ACTIVE state has not + reached n (n is the number of ASPs required to be in ASP-ACTIVE state + before AS can transition to AS-ACTIVE; n = 1 for Override Traffic + Mode) for this AS. The recovery timer T(r) is not running or has + expired. + + + + +Morneault & Pastor-Balbas Standards Track [Page 76] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + AS-ACTIVE: The Application Server is available and application + traffic is active. The AS moves to this state after being in AS- + INACTIVE and getting n ASPs (n is the number of ASPs required to be + in ASP-ACTIVE state before AS can transition to AS-ACTIVE; n = 1 for + Override Traffic Mode) in ASP-ACTIVE state or after reaching AS- + ACTIVE and keeping one or more ASPs in ASP-ACTIVE state. When one + ASP is considered enough to handle traffic (smooth start), the AS in + AS-INACTIVE MAY reach the AS-ACTIVE as soon as the first ASP moves to + the ASP-ACTIVE state. + + AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP + DOWN and it was the last remaining active ASP in the AS. A recovery + timer T(r) SHOULD be started, and all incoming signalling messages + SHOULD be queued by the SGP. If an ASP becomes ASP-ACTIVE before + T(r) expires, the AS is moved to the AS-ACTIVE state, and all the + queued messages will be sent to the ASP. + + If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no + alternative, the SGP may stop queuing messages and discard all + previously queued messages. The AS will move to the AS-INACTIVE + state if at least one ASP is in ASP-INACTIVE; otherwise, it will move + to AS-DOWN state. + + Figure 4 shows an example AS state machine for the case where the + AS/ASP data is preconfigured and is an n+k redundancy model. In + other cases where the AS/ASP configuration data is created + dynamically, there would be differences in the state machine, + especially at creation of the AS. + + +----------+ IA2AC +-------------+ + | AS- |---------------------------->| AS- | + | INACTIVE | | ACTIVE | + | |<----------- | | + +----------+ \ +-------------+ + ^ | \ ^ | + | | IA2DN \ PN2IA | | AC2PN + | | \ | | + DN2IA | | \ PN2AC | | + | v \ | v + +----------+ \ +-------------+ + | | ----------| | + | AS-DOWN | | AS-PENDING | + | | PN2DN | (queueing) | + | |<----------------------------| | + +----------+ +-------------+ + + Figure 4: AS State Transition Diagram + + + + +Morneault & Pastor-Balbas Standards Track [Page 77] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + DN2IA: One ASP moves from ASP-DOWN to ASP-INACTIVE state. + + IA2DN: The last ASP in ASP-INACTIVE moves to ASP-DOWN, causing all + the ASPs to be in ASP-DOWN state. + + IA2AC: One ASP moves to ASP-ACTIVE, causing the number of ASPs in the + ASP-ACTIVE state to be n. In a special case of smooth start, this + transition MAY be done when the first ASP moves to ASP-ACTIVE state. + + AC2PN: The last ASP in ASP-ACTIVE state moves to ASP-INACTIVE or + ASP-DOWN states, causing the number of ASPs in ASP-ACTIVE to drop + below 1. + + PN2AC: One ASP moves to ASP-ACTIVE. + + PN2IA: T(r) expiry; an ASP is in ASP-INACTIVE state but no ASPs are + in ASP-ACTIVE state. + + PN2DN: T(r) expiry; all the ASPs are in ASP-DOWN state. + + An AS becomes AS-ACTIVE right after n ASPs reach the ASP-ACTIVE state + during the startup phase (except for smooth start). Once the traffic + is flowing, an AS keeps the AS-ACTIVE state till the last ASP turns + to another state different from ASP-ACTIVE, avoiding unnecessary + traffic disturbances as long as there are ASPs available (this + assumes that the system will not always be exposed to the maximum + load). + + There are other cases where the AS/ASP configuration data is created + dynamically. In those cases there would be differences in the state + machine, especially at creation of the AS. For example, where the + AS/ASP configuration data is not created until Registration of the + first ASP, the AS-INACTIVE state is entered directly upon the nth + successful REG REQ from an ASP belonging to that AS. Another example + is where the AS/ASP configuration data is not created until the nth + ASP successfully enters the ASP-ACTIVE state. In this latter case, + the AS-ACTIVE state is entered directly. + +4.3.3. M3UA Management Procedures for Primitives + + Before the establishment of an SCTP association, the ASP state at + both the SGP and ASP is assumed to be in the state ASP-DOWN. + + Once the SCTP association is established (see Section 4.2), assuming + that the local M3UA-User is ready, the local M3UA ASP Maintenance + (ASPM) function will initiate the relevant procedures, using the ASP + Up/ASP Down/ASP Active/ASP Inactive messages to convey the ASP state + to the SGP (see Section 4.3.4). + + + +Morneault & Pastor-Balbas Standards Track [Page 78] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + If the M3UA layer subsequently receives an SCTP-COMMUNICATION_DOWN or + SCTP-RESTART indication primitive from the underlying SCTP layer, it + will inform the Layer Management by invoking the M-SCTP_STATUS + indication primitive. The state of the ASP will be moved to ASP- + DOWN. At an ASP, the MTP3-User will be informed of the + unavailability of any affected SS7 destinations through the use of + MTP-PAUSE indication primitives. + + In the case of SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to + re-establish the SCTP Association. This MAY be done by the M3UA + layer automatically, or Layer Management MAY reestablish using the + M-SCTP_ESTABLISH request primitive. + + In the case of an SCTP-RESTART indication at an ASP, the ASP is now + considered to be in the ASP-DOWN state by its M3UA peer. The ASP, if + it is to recover, must begin any recovery with the ASP-Up procedure. + +4.3.4. ASPM Procedures for Peer-to-Peer Messages + +4.3.4.1. ASP Up Procedures + + After an ASP has successfully established an SCTP association to an + SGP, the SGP waits for the ASP to send an ASP Up message, indicating + that the ASP M3UA peer is available. The ASP is always the initiator + of the ASP Up message. This action MAY be initiated at the ASP by an + M-ASP_UP request primitive from Layer Management or MAY be initiated + automatically by an M3UA management function. + + When an ASP Up message is received at an SGP and, internally, the + remote ASP is in the ASP-DOWN state and is not considered locked out + for local management reasons, the SGP marks the remote ASP in the + state ASP-INACTIVE and informs Layer Management with an M-ASP_Up + indication primitive. If the SGP is aware, via current configuration + data, which Application Servers the ASP is configured to operate in, + the SGP updates the ASP state to ASP-INACTIVE in each AS that it is a + member. + + Alternatively, the SGP may move the ASP into a pool of Inactive ASPs + available for future configuration within Application Servers, + determined in a subsequent Registration Request or ASP Active + procedure. If the ASP Up message contains an ASP Identifier, the SGP + should save the ASP Identifier for that ASP. The SGP MUST send an + ASP Up Ack message in response to a received ASP Up message even if + the ASP is already marked as ASP-INACTIVE at the SGP. + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 79] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + If for any local reason (e.g., management lockout) the SGP cannot + respond with an ASP Up Ack message, the SGP responds to an ASP Up + message with an Error message with the reason "Refused - Management + Blocking". + + At the ASP, the ASP Up Ack message received is not acknowledged. + Layer Management is informed with an M-ASP_UP confirm primitive. + + When the ASP sends an ASP Up message, it starts timer T(ack). If the + ASP does not receive a response to an ASP Up message within T(ack), + the ASP MAY restart T(ack) and resend ASP Up messages until it + receives an ASP Up Ack message. T(ack) is provisionable, with a + default of 2 seconds. Alternatively, retransmission of ASP Up + messages MAY be put under control of Layer Management. In this + method, expiry of T(ack) results in an M-ASP_UP confirm primitive + carrying a negative indication. + + The ASP must wait for the ASP Up Ack message before sending any other + M3UA messages (e.g., ASP Active or REG REQ). If the SGP receives any + other M3UA messages before an ASP Up message is received (other than + ASP Down; see Section 4.3.4.2), the SGP MAY discard them. + + If an ASP Up message is received and, internally, the remote ASP is + in the ASP-ACTIVE state, an ASP Up Ack message is returned, as well + as an Error message ("Unexpected Message"). In addition, the remote + ASP state is changed to ASP-INACTIVE in all relevant Application + Servers, and all registered Routing Keys are considered deregistered. + + If an ASP Up message is received and, internally, the remote ASP is + already in the ASP-INACTIVE state, an ASP Up Ack message is returned, + and no further action is taken. + + If the ASP receives an unexpected ASP Up Ack message, the ASP should + consider itself in the ASP-INACTIVE state. If the ASP was not in the + ASP-INACTIVE state, it SHOULD send an Error message and then initiate + procedures to return itself to its previous state. + +4.3.4.1.1. M3UA Version Control and ASP Up + + If an ASP Up message with an unsupported version is received, the + receiving end responds with an Error message, indicating the version + the receiving node supports and notifies Layer Management. See + Section 4.8 for more on this issue. + +4.3.4.1.2. IPSP Considerations (ASP Up) + + An IPSP may be considered in the ASP-INACTIVE state after an ASP Up + or ASP Up Ack has been received from it. An IPSP can be considered + + + +Morneault & Pastor-Balbas Standards Track [Page 80] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + in the ASP-DOWN state after an ASP Down or ASP Down Ack has been + received from it. The IPSP may inform Layer Management of the change + in state of the remote IPSP using M-ASP_UP or M-ASP_DN indication or + confirmation primitives. + + Alternatively, when using the IPSP DE model, an interchange of ASP Up + messages from each end MUST be performed. Four messages are needed + for completion. + + If for any local reason (e.g., management lockout) an IPSP cannot + respond to an ASP Up message with an ASP Up Ack message, it responds + to an ASP Up message with an Error message with the reason "Refused + Management Blocking" and leaves the remote IPSP in the ASP-DOWN + state. + +4.3.4.2. ASP-Down Procedures + + The ASP will send an ASP Down message to an SGP when the ASP wishes + to be removed from service in all Application Servers that it is a + member and no longer receive any DATA, SSNM or, ASPTM messages. This + action MAY be initiated at the ASP by an M-ASP_DOWN request primitive + from Layer Management or MAY be initiated automatically by an M3UA + management function. + + Whether the ASP is permanently removed from any AS is a function of + configuration management. In the case where the ASP previously used + the Registration procedures (see Section 4.4.1) to register within + Application Servers but has not deregistered from all of them prior + to sending the ASP Down message, the SGP MUST consider the ASP + Deregistered in all Application Servers that it is still a member. + + The SGP marks the ASP as ASP-DOWN, informs Layer Management with an + M-ASP_Down indication primitive, and returns an ASP Down Ack message + to the ASP. + + The SGP MUST send an ASP Down Ack message in response to a received + ASP Down message from the ASP even if the ASP is already marked as + ASP-DOWN at the SGP. + + At the ASP, the ASP Down Ack message received is not acknowledged. + Layer Management is informed with an M-ASP_DOWN confirm primitive. + If the ASP receives an ASP Down Ack without having sent an ASP Down + message, the ASP should now consider itself to be in the ASP-DOWN + state. + + If the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE state, + the ASP should then initiate procedures to return itself to its + previous state. + + + +Morneault & Pastor-Balbas Standards Track [Page 81] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + When the ASP sends an ASP Down message, it starts timer T(ack). If + the ASP does not receive a response to an ASP Down message within + T(ack), the ASP MAY restart T(ack) and resend ASP Down messages until + it receives an ASP Down Ack message. T(ack) is provisionable, with a + default of 2 seconds. Alternatively, retransmission of ASP Down + messages MAY be put under control of Layer Management. In this + method, expiry of T(ack) results in an M-ASP_DOWN confirm primitive, + carrying a negative indication. + +4.3.4.3. ASP Active Procedures + + Anytime after the ASP has received an ASP Up Ack message from the SGP + or IPSP, the ASP MAY send an ASP Active message to the SGP, + indicating that the ASP is ready to start processing traffic. This + action MAY be initiated at the ASP by an M-ASP_ACTIVE request + primitive from Layer Management or MAY be initiated automatically by + an M3UA management function. In the case where an ASP wishes to + process the traffic for more than one Application Server across a + common SCTP association, the ASP Active message(s) SHOULD contain a + list of one or more Routing Contexts to indicate for which + Application Servers the ASP Active message applies. It is not + necessary for the ASP to include all Routing Contexts of interest in + a single ASP Active message, thus requesting to become active in all + Routing Contexts at the same time. Multiple ASP Active messages MAY + be used to activate within the Application Servers independently, or + in sets. + + In the case where an ASP Active message does not contain a Routing + Context parameter, the receiver must know, via configuration data, + which Application Server(s) the ASP is a member. + + For the Application Servers for which the ASP can be successfully + activated, the SGP or IPSP responds with one or more ASP Active Ack + messages, including the associated Routing Context(s) and reflecting + any Traffic Mode Type value present in the related ASP Active + message. The Routing Context parameter MUST be included in the ASP + Active Ack message(s) if the received ASP Active message contained + any Routing Contexts. Depending on any Traffic Mode Type request in + the ASP Active message, or local configuration data if there is no + request, the SGP moves the ASP to the correct ASP traffic state + within the associated Application Server(s). Layer Management is + informed with an M-ASP_Active indication. If the SGP or IPSP + receives any Data messages before an ASP Active message is received, + the SGP or IPSP MAY discard them. By sending an ASP Active Ack + message, the SGP or IPSP is now ready to receive and send traffic for + the related Routing Context(s). The ASP SHOULD NOT send Data or SSNM + messages for the related Routing Context(s) before receiving an ASP + Active Ack message, or it will risk message loss. + + + +Morneault & Pastor-Balbas Standards Track [Page 82] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Multiple ASP Active Ack messages MAY be used in response to an ASP + Active message containing multiple Routing Contexts, allowing the SGP + or IPSP to independently acknowledge the ASP Active message for + different (sets of) Routing Contexts. + + The ASP Active message will be responded to in the following way as a + function of the presence/need of the RC parameter: + + - If the RC parameter is included in the ASP Active message and the + corresponding RK has been previously defined (by either static + configuration or dynamic registration), the peer node MUST respond + with an ASP Active Ack message. If for any local reason (e.g., + management lockout) the SGP responds to an ASP Active message with + an Error message with reason "Refused Management Blocking". + + - If the RC parameter is included in the ASP Active message and a + corresponding RK has not been previously defined (by either static + configuration or dynamic registration), the peer MUST respond with + an ERROR message with the Error Code "No configured AS for ASP". + + - If (1) the RC parameter is not included in the ASP Active message, + (2) there are RKs defined (by either static configuration or + dynamic registration) and (3) RC is not mandatory, the peer node + SHOULD respond with an ASP Active Ack message and activate all the + RKs it has defined for that specific ASP. + + - If (!) the RC parameter is not included in the ASP Active message, + (2) there are RKs defined (by either static configuration or + dynamic registration), (3) and RC is mandatory, the peer node MUST + respond with an ERROR message with the Error Code "Missing + Parameter". + + - If (1) the RC parameter is not included in the ASP Active message, + (2) there are RKs defined (by either static configuration or + dynamic registration) and (3) RC is not mandatory, the peer node + MUST respond with an ASP Active Ack message if it is ready to + handle traffic; otherwise, it will send an ERROR message with the + Error Code "No Configured AS for ASP" (meaning that it is not ready + to become active). + + - If the RC parameter is not included in the ASP Active message and + there are no RKs defined, the peer node SHOULD respond with and + ERROR message with the Error Code "Invalid Routing Context". + + Independently of the RC, the SGP MUST send an ASP Active Ack message + in response to a received ASP Active message from the ASP, if the ASP + is already marked in the APS-ACTIVE state. + + + + +Morneault & Pastor-Balbas Standards Track [Page 83] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + At the ASP, the ASP Active Ack message received is not acknowledged. + Layer Management is informed with an M-ASP_ACTIVE confirm primitive. + It is possible for the ASP to receive Data messages before the ASP + Active Ack message as the ASP Active Ack and Data messages from an SG + or IPSP may be sent on different SCTP streams. Message loss is + possible, as the ASP does not consider itself in the ASP-ACTIVE state + until receipt of the ASP Active Ack message. + + When the ASP sends an ASP Active message, it starts the timer T(ack). + If the ASP does not receive a response to an ASP Active message + within T(ack), the ASP MAY restart T(ack) and resend ASP Active + messages until it receives an ASP Active Ack message. T(ack) is + provisionable, with a default of 2 seconds. Alternatively, + retransmission of ASP Active messages MAY be put under control of + Layer Management. In this method, expiry of T(ack) results in an M- + ASP_ACTIVE confirm primitive carrying a negative indication. + + There are three modes of Application Server traffic handling in the + SGP M3UA layer: Override, Loadshare and Broadcast. When included, + the Traffic Mode Type parameter in the ASP Active message indicates + the traffic handling mode to be used in a particular Application + Server. If the SGP determines that the mode indicated in an ASP + Active message is unsupported or incompatible with the mode currently + configured for the AS, the SGP responds with an Error message + ("Unsupported / Invalid Traffic Handling Mode"). If the traffic + handling mode of the Application Server is not already known via + configuration data, then the traffic handling mode indicated in the + first ASP Active message causing the transition of the Application + Server state to AS-ACTIVE MAY be used to set the mode. + + In the case of an Override mode AS, receipt of an ASP Active message + at an SGP causes the (re)direction of all traffic for the AS to the + ASP that sent the ASP Active message. Any previously active ASP in + the AS is now considered to be in the state ASP-INACTIVE and SHOULD + no longer receive traffic from the SGP within the AS. The SGP or + IPSP then MUST send a Notify message ("Alternate ASP_Active") to the + previously active ASP in the AS and SHOULD stop traffic to/from that + ASP. The ASP receiving this Notify MUST consider itself now in the + ASP-INACTIVE state, if it is not already aware of this via inter-ASP + communication with the Overriding ASP. + + In the case of a Loadshare mode AS, receipt of an ASP Active message + at an SGP or IPSP causes direction of traffic to the ASP sending the + ASP Active message, in addition to all the other ASPs that are + currently active in the AS. The algorithm at the SGP for loadsharing + traffic within an AS to all the active ASPs is implementation + dependent. The algorithm could, for example, be round-robin or based + on information in the Data message (e.g., the SLS, SCCP SSN, or ISUP + + + +Morneault & Pastor-Balbas Standards Track [Page 84] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + CIC value). An SGP or IPSP, upon receipt of an ASP Active message + for the first ASP in a Loadshare AS, MAY choose not to direct traffic + to a newly active ASP until it determines that there are sufficient + resources to handle the expected load (e.g., until there are "n" ASPs + in state ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD + withhold the Notify (AS-ACTIVE) until there are sufficient resources. + + For the n+k redundancy case, ASPs that are in that AS should + coordinate among themselves the number of active ASPs in the AS and + should start sending traffic only after n ASPs are active. All ASPs + within a loadsharing mode AS must be able to process any Data message + received for the AS, to accommodate any potential failover or + rebalancing of the offered load. + + In the case of a Broadcast mode AS, receipt of an ASP Active message + at an SGP or IPSP causes direction of traffic to the ASP sending the + ASP Active message, in addition to all the other ASPs that are + currently active in the AS. The algorithm at the SGP for + broadcasting traffic within an AS to all the active ASPs is a simple + broadcast algorithm, where every message is sent to each of the + active ASPs. + + At startup or restart phases, an SGP or IPSP, upon receipt of an ASP + Active message for the first ASP in a Loadshare AS, SHOULD NOT direct + traffic to a newly active ASP until it determines that there are + sufficient resources to handle the expected load (e.g., until there + are "n" ASPs in state ASP-ACTIVE in the AS). In this case, the SGP + or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are + sufficient resources. + + An SGP or IPSP, upon receipt of an ASP Active message for the first + ASP in a Broadcast AS, MAY choose not to direct traffic to a newly + active ASP until it determines that there are sufficient resources to + handle the expected load (e.g., until there are "n" ASPs in state + ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold + the Notify (AS-ACTIVE) until there are sufficient resources. + + For the n+k redundancy case, ASPs that are in that AS should + coordinate among themselves the number of active ASPs in the AS and + should start sending traffic only after n ASPs are active. + + Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP + MUST tag the first DATA message broadcast in each traffic flow with a + unique Correlation Id parameter. The purpose of this Id is to permit + the newly active ASP to synchronize its processing of traffic in each + traffic flow with the other ASPs in the broadcast group. + + + + + +Morneault & Pastor-Balbas Standards Track [Page 85] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +4.3.4.3.1. IPSP Considerations (ASP Active) + + Either of the IPSPs can initiate communication. When an IPSP + receives an ASP Active, it should mark the peer as ASP-ACTIVE and + return an ASP Active Ack message. An ASP receiving an ASP Active Ack + message may mark the peer as ASP-Active, if it is not already in the + ASP-ACTIVE state. + + Alternatively, when using the IPSP DE model, an interchange of ASP + Active messages from each end MUST be performed. Four messages are + needed for completion. + +4.3.4.4. ASP Inactive Procedures + + When an ASP wishes to withdraw from receiving traffic within an AS or + the ASP wants to initiate the process of deactivation, the ASP sends + an ASP Inactive message to the SGP or IPSP. + + An ASP Inactive message MUST always be responded to by the peer + (although other messages may be sent in the middle) in the following + way: + + - If the received ASP Inactive message contains an RC parameter + and the corresponding RK is defined (by either static + configuration or dynamic registration), the SGP/IPSP MUST + respond with an ASP Inactive Ack message. + + - If the received ASP Inactive message contains an RC parameter + that is not defined (by either static configuration or dynamic + registration), the SGP/IPSP MUST respond with an ERROR message + with the Error Code "Invalid Routing Context". + + - If the received ASP Inactive message does not contain an RC + parameter and the RK is defined (by either static configuration + or dynamic registration), the SGP/IPSP must turn the ASP/IPSP to + ASP-INACTIVE state in all the ASes it serves and MUST respond + with an ASP Inactive Ack message. + + - If the received ASP Inactive message does not contain an RC + parameter and the RK is not defined (by either static + configuration or dynamic registration), the SGP/IPSP MUST + respond with an ERROR message with the Error Code "No configured + AS for ASP". + + The action of sending the ASP Inactive message MAY be initiated at + the ASP by an M-ASP_INACTIVE request primitive from Layer Management + or MAY be initiated automatically by an M3UA management function. In + the case where an ASP is processing the traffic for more than one + + + +Morneault & Pastor-Balbas Standards Track [Page 86] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Application Server across a common SCTP association, the ASP Inactive + message contains one or more Routing Contexts to indicate for which + Application Servers the ASP Inactive message applies. + + In the case where an ASP Inactive message does not contain a Routing + Context parameter, the receiver must know, via configuration data, + which Application Servers the ASP is a member of and then move the + ASP to the ASP-INACTIVE state in all Application Servers. + + In the case of an Override mode AS, where another ASP has already + taken over the traffic within the AS with an ASP Active ("Override") + message, the ASP that sends the ASP Inactive message is already + considered to be in ASP-INACTIVE state by the SGP. An ASP Inactive + Ack message is sent to the ASP, after ensuring that all traffic is + stopped to the ASP. + + In the case of a Loadshare mode AS, the SGP moves the ASP to the + ASP-INACTIVE state, and the AS traffic is reallocated across the + remaining ASPs in the state ASP-ACTIVE, as per the loadsharing + algorithm currently used within the AS. A Notify message + ("Insufficient ASP resources active in AS") MAY be sent to all + inactive ASPs, if required. An ASP Inactive Ack message is sent to + the ASP after all traffic is halted, and Layer Management is informed + with an M-ASP_INACTIVE indication primitive. + + In the case of a Broadcast mode AS, the SGP moves the ASP to the + ASP-INACTIVE state, and the AS traffic is broadcast only to the + remaining ASPs in the state ASP-ACTIVE. A Notify message + ("Insufficient ASP resources active in AS") MAY be sent to all + inactive ASPs, if required. An ASP Inactive Ack message is sent to + the ASP after all traffic is halted, and Layer Management is informed + with an M-ASP_INACTIVE indication primitive. + + Multiple ASP Inactive Ack messages MAY be used in response to an ASP + Inactive message containing multiple Routing Contexts, allowing the + SGP or IPSP to independently acknowledge for different (sets of) + Routing Contexts. The SGP or IPSP sends an Error message ("Invalid + Routing Context") message for each invalid or unconfigured Routing + Context value in a received ASP Inactive message. + + The SGP MUST send an ASP Inactive Ack message in response to a + received ASP Inactive message from the ASP; the ASP is already marked + as ASP-INACTIVE at the SGP. + + At the ASP, the ASP Inactive Ack message received is not + acknowledged. Layer Management is informed with an M-ASP_INACTIVE + confirm primitive. If the ASP receives an ASP Inactive Ack without + having sent an ASP Inactive message, the ASP should now consider + + + +Morneault & Pastor-Balbas Standards Track [Page 87] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + itself to be in the ASP-INACTIVE state. If the ASP was previously in + the ASP-ACTIVE state, the ASP should then initiate procedures to + return itself to its previous state. + + When the ASP sends an ASP Inactive message, it starts the timer + T(ack). If the ASP does not receive a response to an ASP Inactive + message within T(ack), the ASP MAY restart T(ack) and resend ASP + Inactive messages until it receives an ASP Inactive Ack message. + T(ack) is provisionable, with a default of 2 seconds. Alternatively, + retransmission of ASP Inactive messages MAY be put under control of + Layer Management. In this method, expiry of T(ack) results in an M- + ASP_Inactive confirm primitive carrying a negative indication. + + If no other ASPs in the Application Server are in the state ASP- + ACTIVE, the SGP MUST send a Notify message ("AS-Pending") to all ASPs + in the AS that are in the state ASP-INACTIVE. The SGP SHOULD start + buffering the incoming messages for T(r) seconds, after which + messages MAY be discarded. T(r) is configurable by the network + operator. If the SGP receives an ASP Active message from an ASP in + the AS before expiry of T(r), the buffered traffic is directed to + that ASP, and the timer is cancelled. If T(r) expires, the AS is + moved to the AS-INACTIVE state. + +4.3.4.4.1. IPSP Considerations (ASP Inactive) + + An IPSP may be considered in the ASP-INACTIVE state by a remote IPSP + after an ASP Inactive or ASP Inactive Ack message has been received + from it. + + Alternatively, when using IPSP DE model, an interchange of ASP + Inactive messages from each end MUST be performed. Four messages are + needed for completion. + +4.3.4.5. Notify Procedures + + A Notify message reflecting a change in the AS state MUST be sent to + all ASPs in the AS, except those in the ASP-DOWN state, with + appropriate Status Information and any ASP Identifier of the failed + ASP. At the ASP, Layer Management is informed with an M-NOTIFY + indication primitive. The Notify message must be sent whether the AS + state change was a result of an ASP failure or receipt of an ASP + State management (ASPSM) / ASP Traffic Management (ASPTM) message. + In the second case, the Notify message MUST be sent after any related + acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active + Ack, or ASP Inactive Ack). + + When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular + AS, a Notify message SHOULD be sent, by the ASP-UP receptor, after + + + +Morneault & Pastor-Balbas Standards Track [Page 88] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + sending the ASP-UP-ACK, in order to inform the ASP of the current AS + state. + + In the case where a Notify message ("AS-PENDING") message is sent by + an SGP that now has no ASPs active to service the traffic, or where a + Notify ("Insufficient ASP resources active in AS") message is sent in + the Loadshare or Broadcast mode, the Notify message does not + explicitly compel the ASP(s) receiving the message to become active. + The ASPs remain in control of what (and when) traffic action is + taken. + + In the case where a Notify message does not contain a Routing Context + parameter, the receiver must know, via configuration data, of which + Application Servers the ASP is a member and take the appropriate + action in each AS. + +4.3.4.5.1. IPSP Considerations (NTFY) + + Notify works in the same manner as in the SG-AS case. One of the + IPSPs can send this message to any remote IPSP that is not in the + ASP-DOWN state. + +4.3.4.6. Heartbeat Procedures + + The optional Heartbeat procedures MAY be used when operating over + transport layers that do not have their own heartbeat mechanism for + detecting loss of the transport association (i.e., other than SCTP). + Either M3UA peer may optionally send Heartbeat messages periodically, + subject to a provisionable timer, T(beat). Upon receiving a + Heartbeat message, the M3UA peer MUST respond with a Heartbeat Ack + message. + + If no Heartbeat Ack message (or any other M3UA message) is received + from the M3UA peer within 2*T(beat), the remote M3UA peer is + considered unavailable. Transmission of Heartbeat messages is + stopped, and the signalling process SHOULD attempt to re-establish + communication if it is configured as the client for the disconnected + M3UA peer. + + The Heartbeat message may optionally contain an opaque Heartbeat Data + parameter that MUST be echoed back unchanged in the related Heartbeat + Ack message. The sender, upon examining the contents of the returned + Heartbeat Ack message, MAY choose to consider the remote M3UA peer as + unavailable. The contents/format of the Heartbeat Data parameter is + implementation-dependent and only of local interest to the original + sender. The contents may be used, for example, to support a + Heartbeat sequence algorithm (to detect missing Heartbeats), and/or a + timestamp mechanism (to evaluate delays). + + + +Morneault & Pastor-Balbas Standards Track [Page 89] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Note: Heartbeat-related events are not shown in Figure 3 "ASP state + transition diagram". + +4.4. Routing Key Management Procedures [Optional] + +4.4.1. Registration + + An ASP MAY dynamically register with an SGP as an ASP within an + Application Server using the REG REQ message. A Routing Key + parameter in the REG REQ message specifies the parameters associated + with the Routing Key. + + The SGP examines the contents of the received Routing Key parameter + and compares it with the currently provisioned Routing Keys. If the + received Routing Key matches an existing SGP Routing Key entry and + the ASP is not currently included in the list of ASPs for the related + Application Server, the SGP MAY authorize the ASP to be added to the + AS. Or, if the Routing Key does not currently exist and the received + Routing Key data is valid and unique, an SGP supporting dynamic + configuration MAY authorize the creation of a new Routing Key and + related Application Server and add the ASP to the new AS. In either + case, the SGP returns a Registration Response message to the ASP, + containing the same Local-RK-Identifier as provided in the initial + request, and a Registration Result "Successfully Registered". A + unique Routing Context value assigned to the SGP Routing Key is + included. The method of Routing Context value assignment at the SGP + is implementation dependent but must be guaranteed to be unique for + each Application Server or Routing Key supported by the SGP. + + If the SGP does not support the registration procedure, the SGP + returns an Error message to the ASP, with an error code of + "Unsupported Message Class". + + If the SGP determines that the received Routing Key data is invalid, + or contains invalid parameter values, the SGP returns a Registration + Response message to the ASP, containing a Registration Result "Error + Invalid Routing Key", "Error - Invalid DPC", or "Error - Invalid + Network Appearance", as appropriate. + + If the SGP determines that the requested RK partially, but not + exactly, matches an existing RK, and that an incoming signalling + message received at an SGP could possibly match both the requested + and the existing RK, the SGP returns a Registration Response message + to the ASP, with a Registration Status of "Error - "Cannot Support + Unique Routing". An incoming signalling message received at an SGP + should not match against more than one Routing Key. + + + + + +Morneault & Pastor-Balbas Standards Track [Page 90] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + If the SGP determines that the received RK was already registered, + fully and exactly, either statically or dynamically, by the sending + ASP, the SGP returns a Registration Response message to the ASP, + containing a Registration Result "Error - Routing Key Already + Registered". This error applies whether the sending ASP/IPSP is in + ASP-ACTIVE or ASP-INACTIVE for the corresponding AS. For this error + code, the RC field in the Registration Response message MUST be + populated with the actual value of RC in SGP corresponding to the + specified RK in the Registration Request message. + + An ASP MAY request modification of an existing Routing Key by + including a Routing Context parameter in a Registration Request + message. Upon receipt of a Registration Request message containing a + Routing Context, if the SGP determines that the Routing Context + applies to an existing Routing Key, the SGP MAY adjust the existing + Routing Key to match the new information provided in the Routing Key + parameter. A Registration Response "ERR Routing Key Change Refused" + is returned if the SGP does not support this re-registration + procedure or RC does not exist. Otherwise, a Registration Response + "Successfully Registered" is returned. + + If the SGP does not authorize an otherwise valid registration + request, the SGP returns a REG RSP message to the ASP containing the + Registration Result "Error - Permission Denied". + + If an SGP determines that a received Routing Key does not currently + exist, and that the SGP does not support dynamic configuration, the + SGP returns a Registration Response message to the ASP, containing a + Registration Result "Error - Routing Key not Currently Provisioned". + + If an SGP determines that a received Routing Key does not currently + exist and that the SGP supports dynamic configuration but does not + have the capacity to add new Routing Key and Application Server + entries, the SGP returns a Registration Response message to the ASP, + containing a Registration Result "Error - Insufficient Resources". + + If an SGP determines that a received Routing Key does not currently + exist, and the SGP supports dynamic configuration but requires that + the Routing Key first be manually provisioned at the SGP, the SGP + returns a Registration Response message to the ASP, containing a + Registration Result "Error - Routing Key not Currently Provisioned". + + If an SGP determines that one or more of the Routing Key parameters + are not supported for the purpose of creating new Routing Key + entries, the SGP returns a Registration Response message to the ASP, + containing a Registration Result "Error - Unsupported RK parameter + field". + + + + +Morneault & Pastor-Balbas Standards Track [Page 91] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + A Registration Response "Error - Unsupported Traffic Handling Mode" + is returned if the Routing Key in the REG REQ contains an Traffic + Handling Mode that is inconsistent with the presently configured mode + for the matching Application Server. + + An ASP MAY register multiple Routing Keys at once by including a + number of Routing Key parameters in a single REG REQ message. The + SGP MAY respond to each registration request in a single REG RSP + message, indicating the success or failure result for each Routing + Key in a separate Registration Result parameter. Alternatively the + SGP MAY respond with multiple REG RSP messages, each with one or more + Registration Result parameters. The ASP uses the Local-RK-Identifier + parameter to correlate the requests with the responses. + + Upon successful registration of an ASP in an AS, the SGP can now send + related SS7 Signalling Network Management messaging, if this did not + previously start upon the ASP transitioning to state ASP-INACTIVE + +4.4.2. Deregistration + + An ASP MAY dynamically deregister with an SGP as an ASP within an + Application Server using the DEREG REQ message. A Routing Context + parameter in the DEREG REQ message specifies which Routing Keys to + deregister. An ASP SHOULD move to the ASP-INACTIVE state for an + Application Server before attempting to deregister the Routing Key + (i.e., deregister after receiving an ASP Inactive Ack). Also, an ASP + SHOULD deregister from all Application Servers of which it is a + member before attempting to move to the ASP-Down state. + + The SGP examines the contents of the received Routing Context + parameter and validates that the ASP is currently registered in the + Application Server(s) related to the included Routing Context(s). If + validated, the ASP is deregistered as an ASP in the related + Application Server. + + The deregistration procedure does not necessarily imply the deletion + of Routing Key and Application Server configuration data at the SG. + + Other ASPs may continue to be associated with the Application Server, + in which case the Routing Key data SHOULD NOT be deleted. If a + Deregistration results in no more ASPs in an Application Server, an + SG MAY delete the Routing Key data. + + The SGP acknowledges the deregistration request by returning a DEREG + RSP message to the requesting ASP. The result of the deregistration + is found in the Deregistration Result parameter, indicating success + or failure with cause. + + + + +Morneault & Pastor-Balbas Standards Track [Page 92] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + An ASP MAY deregister multiple Routing Contexts at once by including + a number of Routing Contexts in a single DEREG REQ message. The SGP + MAY respond to each deregistration request in a single DEREG RSP + message, indicating the success or failure result for each Routing + Context in a separate Deregistration Result parameter. + +4.4.3. IPSP Considerations (REG/DEREG) + + The Registration/Deregistration procedures work in the IPSP cases in + the same way as in AS-SG cases. An IPSP may register an RK in the + remote IPSP. An IPSP is responsible for deregistering the RKs that + it has registered. + +4.5. Procedures to Support the Availability or Congestion Status of + SS7 Destination + +4.5.1. At an SGP + + On receiving an MTP-PAUSE, MTP-RESUME or MTP-STATUS indication + primitive from the nodal interworking function at an SGP, the SGP + M3UA layer will send a corresponding SS7 Signalling Network + Management (SSNM) DUNA, DAVA, SCON, or DUPU message (see Section 3.4) + to the M3UA peers at concerned ASPs. The M3UA layer must fill in + various fields of the SSNM messages consistently with the information + received in the primitives. + + The SGP M3UA layer determines the set of concerned ASPs to be + informed based on the specific SS7 network for which the primitive + indication is relevant. In this way, all ASPs configured to + send/receive traffic within a particular Network Appearance are + informed. If the SGP operates within a single SS7 Network + Appearance, then all ASPs are informed. + + For the particular case that an ASP becomes active for an AS and + destinations normally accessible to the AS are inaccessible, + restricted, or congested, the SG MAY send DUNA, DRST, or SCON + messages for the inaccessible, restricted, or congested destinations + to the ASP newly active for the AS to prevent the ASP from sending + traffic for destinations that it might not otherwise know that are + inaccessible, restricted, or congested. For the newly activating ASP + from which the SGP has received an ASP Active message, these DUNA, + DRST, and SCON messages MAY be sent before sending the ASP Active Ack + that completes the activation procedure. + + DUNA, DAVA, SCON, and DRST messages may be sent sequentially and + processed at the receiver in the order sent. + + + + + +Morneault & Pastor-Balbas Standards Track [Page 93] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Sequencing is not required for the DUPU or DAUD messages, which MAY + be sent unsequenced. + +4.5.2. At an ASP + +4.5.2.1. Single SG Configurations + + At an ASP, upon receiving an SS7 Signalling Network Management (SSNM) + message from the remote M3UA Peer, the M3UA layer invokes the + appropriate primitive indications to the resident M3UA-Users. Local + management is informed. + + In the case where a local event has caused the unavailability or + congestion status of SS7 destinations, the M3UA layer at the ASP + SHOULD pass up appropriate indications in the primitives to the M3UA + User, as though equivalent SSNM messages were received. For example, + the loss of an SCTP association to an SGP may cause the + unavailability of a set of SS7 destinations. MTP-PAUSE indication + primitives to the M3UA User are appropriate. + +4.5.2.2. Multiple SG Configurations + + At an ASP, upon receiving a Signalling Network Management message + from the remote M3UA Peer, the M3UA layer updates the status of the + affected route(s) via the originating SG and determines whether or + not the overall availability or congestion status of the affected + destination(s) has changed. If so, the M3UA layer invokes the + appropriate primitive indications to the resident M3UA-Users. Local + management is informed. + + Implementation Note: To accomplish this, the M3UA layer at an ASP + maintains the status of routes via the SG, much like an MTP3 layer + maintains route-set status. + +4.5.3. ASP Auditing + + An ASP may optionally initiate an audit procedure to enquire of an + SGP the availability and (if the national congestion method with + multiple congestion levels and message priorities is used) congestion + status of an SS7 destination or set of destinations. A Destination + Audit (DAUD) message is sent from the ASP to the SGP, requesting the + current availability and congestion status of one or more SS7 + Destination Point Codes. + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 94] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + The DAUD message MAY be sent unsequenced. The DAUD MAY be sent by + the ASP in the following cases: + + - Periodic. A Timer originally set upon receipt of a DUNA, SCON, + or DRST message has expired without a subsequent DAVA, DUNA, + SCON, or DRST message updating the availability/congestion + status of the affected Destination Point Codes. The Timer is + reset upon issuing a DAUD. In this case, the DAUD is sent to + the SGP that originally sent the SSNM message. + + - Isolation. The ASP is newly ASP-ACTIVE or has been isolated + from an SGP for an extended period. The ASP MAY request the + availability/congestion status of one or more SS7 destinations + to which it expects to communicate. + + Implementation Note: In the first of the cases above, the auditing + procedure must not be invoked for the case of a received SCON + message containing a congestion level value of "no congestion" or + "undefined" (i.e., congestion Level = "0"). + + The SGP SHOULD respond to a DAUD message with the MTP3 + availability/congestion status of the routeset associated with each + Destination Point Codes in the DAUD message. The status of each SS7 + destination requested is indicated in a DUNA message (if + unavailable), a DAVA message (if available), or a DRST (if restricted + and the SGP supports this feature in national networks). For + national networks, the SGP SHOULD additionally respond with a SCON + message (if the destination is congested) before the DAVA or DRST. + + Where the SGP does not maintain the congestion status of the SS7 + destination, the response to a DAUD message should always only be a + DAVA, DRST, or DUNA message, as appropriate. + + Any DUNA or DAVA message in response to a DAUD message MAY contain a + list of Affected Point Codes. + + An SG MAY refuse to provide the availability or congestion status of + a destination if, for example, the ASP is not authorized to know the + status of the destination. The SG MAY respond with an Error Message + (Error Code = "Destination Status Unknown"). + + An SG SHOULD respond with a DUNA message when DAUD was received with + an unknown Signalling Point Code. + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 95] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +4.6. MTP3 Restart + + In the case where the MTP3 in the SG undergoes an MTP restart, event + communication SHOULD be handled as follows: + + When the SG discovers SS7 network isolation, the SGPs send an + indication to all concerned available ASPs (i.e., ASPs in the ASP- + ACTIVE state), using DUNA messages for the concerned destinations. + + When the SG has completed the MTP Restart procedure, the M3UA layers + at the SGPs inform all concerned ASPs in the ASP-ACTIVE state of any + available/restricted SS7 destinations, using the DAVA/DRST messages. + No message is necessary for those destinations still unavailable + after the restart procedure. + + When the M3UA layer at an ASP receives a DUNA message indicating SS7 + destination unavailability at an SG, MTP Users will receive an MTP- + PAUSE indication and will stop any affected traffic to this + destination. When the M3UA receives a DAVA/DRST message, MTP Users + will receive an MTP-RESUME indication and can resume traffic to the + newly available SS7 destination, provided that the ASP is in the + ASP-ACTIVE state towards this SGP. + + The ASP MAY choose to audit the availability of unavailable + destinations by sending DAUD messages. This would be the case when, + for example, an AS becomes active at an ASP and does not have current + destination statuses. If MTP restart is in progress at the SG, the + SGP returns a DUNA message for that destination, even if it received + an indication that the destination became available or restricted. + + When an ASP becomes active for an AS and the SG is experiencing SS7 + network isolation or is performing the MTP Restart procedure for the + AS, the SG MAY send a DUNA message for the concerned destinations to + the newly active ASP to prevent the ASP from sending traffic. These + messages can be sent after receiving the ASP Active, and before + sending the ASP Active Ack, to ensure that traffic is not initiated + by the ASP to these destinations before the SSNM are received. In + addition to DUNA messages, SCON, DRST, and DAVA can also be sent. + + In the IPSP case, MTP restart could be considered if the IPSP also + has connection to an SS7 network. In that case, the same behavior as + described above for the SGP would apply to the restarting IPSP. This + would also be the case if the IPSPs were perceived as exchanging MTP + Peer PDUs, instead of MTP primitives between MTP User and MTP + Provider. In other words, M3UA does not provide the equivalent to + Traffic Restart Allowed messages indicating the end of the restart + procedure between peer IPSPs that would also be connected to an SS7 + network. + + + +Morneault & Pastor-Balbas Standards Track [Page 96] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +4.7. NIF Not Available + + Implementation Note: Although the NIF is decided to be an + implementation dependent function, here are some guidelines that may + be useful to follow: + + - If an SGP is isolated entirely from the NIF, the SGP should send + ASP Down Ack to all its connected ASPs. Upon receiving an ASP Up + message while isolated from the NIF, the SGP should respond with an + Error ("Refused - Management Blocking"). + + - If an SGP suffers a partial failure (where an SGP can continue to + service one or more active AS but due to a partial failure it is + unable to service one or more other active AS), the SGP should send + ASP Inactive Ack to all its connected ASPs for the affected AS. + Upon receiving an ASP Active message for an affected AS while still + partially isolated from the NIF, the SGP should respond with an + Error ("Refused - Management Blocking"). + + - If SG is isolated from NIF, it means that each SGP within an SG + should follow the procedure mentioned above. + +4.8. M3UA Version Control + + If a message with an unsupported version is received, the receiving + end responds with an Error message indicating the version the + receiving node supports and notifies Layer Management. + + This is useful when protocol version upgrades are being performed in + a network. A node upgraded to a newer version should support the + older versions used on other nodes it is communicating with. Because + ASPs initiate the ASP Up procedure, it is likely that the message + having an unsupported version is an ASP Up message and therefore that + the Error message would normally come from the SGP. + +4.9. M3UA Termination + + Whenever a M3UA node wants to stop the communication with the peer + node, it MAY use one of the following procedures: + + a) Send the sequence of ASP-INACTIVE, DEREG (optionally whenever + dynamic registration is used), and ASP-DOWN messages and perform + the SCTP Shutdown procedure after that. + + b) Just do the SCTP Shutdown procedure. + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 97] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +5. Examples of M3UA Procedures + +5.1. Establishment of Association and Traffic between SGPs and ASPs + + These scenarios show examples of M3UA message flows for the + establishment of traffic between an SGP and an ASP or between two + IPSPs. In all cases it is assumed that the SCTP association is + already set up. + +5.1.1. Single ASP in an Application Server ("1+0" sparing), + No Registration + + These scenarios show examples of M3UA message flows for the + establishment of traffic between an SGP and an ASP where only one ASP + is configured within an AS (no backup). + +5.1.1.1. Single ASP in an Application Server ("1+0" Sparing), + No Registration + + SGP ASP1 + | | + |<-------------ASP Up-----------| + |-----------ASP Up Ack--------->| + | | + |-----NTFY(AS-INACTIVE)(RCn)--->| + | | + |<------- ASP Active(RCn)-------| RC: Routing Context + |-----ASP Active Ack (RCn)----->| (optional) + | | + |-----NTFY(AS-ACTIVE)(RCn)----->| + | | + + Note: If the ASP Active message contains an optional Routing Context + parameter, the ASP Active message only applies for the specified RC + value(s). For an unknown RC value, the SGP responds with an Error + message. + + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 98] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +5.1.1.2. Single ASP in Application Server ("1+0" Sparing), + Dynamic Registration + + This scenario is the same as for 5.1.1.1 but with the optional + exchange of registration information. In this case, the Registration + is accepted by the SGP. + + SGP ASP1 + | | + |<------------ASP Up------------| + |----------ASP Up Ack---------->| + | | + | | + |<----REGISTER REQ(LRCn,RKn)----| LRC: Local Routing + | | Key Id + |----REGISTER RESP(LRCn,RCn)--->| RK: Routing Key + | | RC: Routing Context + |----NTFY(AS-INACTIVE)(RCn)---->| + | | + | | + |<------- ASP Active(RCn)-------| + |-----ASP Active Ack (RCn)----->| + | | + |-----NTFY(AS-ACTIVE)(RCn)----->| + | | + + Note: In the case of an unsuccessful registration attempt (e.g., + invalid RKn), the Register Response message will contain an + unsuccessful indication, and the ASP will not subsequently send an + ASP Active message. + + + + + + + + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 99] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +5.1.1.3. Single ASP in Multiple Application Servers (Each + with "1+0" Sparing), Dynamic Registration (Case 1 - Multiple + Registration Requests) + + SGP ASP1 + | | + |<------------ASP Up------------| + |----------ASP Up Ack---------->| + | | + |<----REGISTER REQ(LRC1,RK1)----| LRC: Local Routing + | | Key Id + |----REGISTER RESP(LRC1,RC1)--->| RK: Routing Key + | | RC: Routing Context + |---NOTIFY(AS-INACTIVE)(RC1)--->| + | | + | | + |<------- ASP Active(RC1)-------| + |-----ASP Active Ack (RC1)----->| + | | + |----NOTIFY(AS-ACTIVE)(RC1)---->| + | | + ~ ~ + | | + |<----REGISTER REQ(LRCn,RKn)----| + | | + |----REGISTER RESP(LRCn,RCn)--->| + | | + |---NOTIFY(AS-INACTIVE)(RCn)--->| + | | + |<------- ASP Active(RCn)-------| + |-----ASP Active Ack (RCn)----->| + | | + |----NOTIFY(AS-ACTIVE)(RCn)---->| + | | + + Note: In the case of an unsuccessful registration attempt (e.g., + invalid RKn), the Register Response message will contain an + unsuccessful indication, and the ASP will not subsequently send an + ASP Active message. Each LRC/RK pair registration is considered + independently. + + It is not necessary to follow a Registration Request/Response message + pair with an ASP Active message before sending the next Registration + Request. The ASP Active message can be sent at any time after the + related successful registration. + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 100] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +5.1.1.4. Single ASP in Multiple Application Servers (each + with "1+0" sparing), Dynamic Registration (Case 2 - Single + Registration Request) + + SGP ASP1 + | | + |<------------ASP Up------------| + |----------ASP Up Ack---------->| + | | + | | + |<---REGISTER REQ({LRC1,RK1}, | + | ..., | + | {LRCn,RKn}),--| + | | + |---REGISTER RESP({LRC1,RC1},-->| + | ..., | + | (LRCn,RCn}) | + | | + |--NTFY(AS-INACTIVE)(RC1..RCn)->| + | | + | | + |<------- ASP Active(RC1)-------| + |-----ASP Active Ack (RC1)----->| + | | + |----NOTIFY(AS-ACTIVE)(RC1)---->| + | | + : : + : : + | | + |<------- ASP Active(RCn)-------| + |-----ASP Active Ack (RCn)----->| + | | + |----NOTIFY(AS-ACTIVE)(RCn)---->| + | | + + Note: In the case of an unsuccessful registration attempt (e.g., + Invalid RKn), the Register Response message will contain an + unsuccessful indication, and the ASP will not subsequently send an + ASP Active message. Each LRC/RK pair registration is considered + independently. + + The ASP Active message can be sent at any time after the related + successful registration and may have more than one RC. + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 101] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +5.1.2. Two ASPs in Application Server ("1+1" Sparing) + + This scenario shows example M3UA message flows for the establishment + of traffic between an SGP and two ASPs in the same Application + Server, where ASP1 is configured to be in the ASP-ACTIVE state and + ASP2 is to be a "backup" in the event of communication failure or the + withdrawal from service of ASP1. ASP2 may act as a hot, warm, or + cold backup, depending on the extent to which ASP1 and ASP2 share + call/transaction state or can communicate call state under + failure/withdrawal events. The example message flow is the same + whether the ASP Active messages indicate "Override", "Loadshare", or + "Broadcast" mode, although typically this example would use an + Override mode. + + SGP ASP1 ASP2 + | | | + |<--------ASP Up---------| | + |-------ASP Up Ack------>| | + | | | + |--NOTIFY(AS-INACTIVE)-->| | + | | | + |<----------------------------ASP Up----------------| + |----------------------------ASP Up Ack------------>| + | | | + |--------------------------NOTIFY(AS-INACTIVE)----->| + | | | + | | | + |<-------ASP Active------| | + |------ASP Active Ack--->| | + | | | + |---NOTIFY(AS-ACTIVE)--->| | + |--------------------------NOTIFY(AS-ACTIVE)------->| + | | | + + + + + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 102] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +5.1.3. Two ASPs in an Application Server ("1+1" Sparing, + Loadsharing Case) + + This scenario shows a case similar to Section 5.1.2, but where the + two ASPs are brought to the state ASP-ACTIVE and subsequently + loadshare the traffic. In this case, one ASP is sufficient to handle + the total traffic load. + + SGP ASP1 ASP2 + | | | + |<---------ASP Up--------| | + |--------ASP Up Ack----->| | + | | | + |--NOTIFY(AS-INACTIVE)-->| | + | | | + |<-----------------------------ASP Up---------------| + |----------------------------ASP Up Ack------------>| + | | | + |--------------------------NOTIFY(AS-INACTIVE)----->| + | | | + |<--ASP Active (Ldshr)---| | + |-----ASP-Active Ack---->| | + | | | + |---NOTIFY (AS-ACTIVE)-->| | + |-----------------------------NOTIFY(AS-ACTIVE)---->| + | | | + |<---------------------------ASP Active (Ldshr)-----| + |------------------------------ASP Active Ack------>| + | | | + + + + + + + + + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 103] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +5.1.4. Three ASPs in an Application Server ("n+k" Sparing, + Loadsharing Case) + + This scenario shows example M3UA message flows for the establishment + of traffic between an SGP and three ASPs in the same Application + Server, where two of the ASPs are brought to the state ASP-ACTIVE and + subsequently share the load. In this case, a minimum of two ASPs are + required to handle the total traffic load (2+1 sparing). + + SGP ASP1 ASP2 ASP3 + | | | | + |<------ASP Up------| | | + |-----ASP Up Ack--->| | | + | | | | + |NTFY(AS-INACTIVE)->| | | + | | | | + |<-------------------------ASP Up-------| | + |------------------------ASP Up Ack---->| | + | | | | + |------------------NOTIFY(AS-INACTIVE)->| | + | | | | + |<--------------------------------------------ASP Up--------| + |--------------------------------------------ASP Up Ack---->| + | | | | + |--------------------------------------NOTIFY(AS-INACTIVE)->| + | | | | + | | | | + |<--ASP Act (Ldshr)-| | | + |----ASP Act Ack--->| | | + | | | | + | | | | + |<-------------------ASP Act. (Ldshr)---| | + |----------------------ASP Act Ack----->| | + | | | | + |--NTFY(AS-ACTIVE)->| | | + |--------------------NOTIFY(AS-ACTIVE)->| | + |----------------------------------------NOTIFY(AS-ACTIVE)->| + | | | | + | | | | + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 104] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +5.2. ASP Traffic Failover Examples + +5.2.1. 1+1 Sparing, Withdrawal of ASP, Backup Override + + Following from the example in Section 5.1.2, ASP1 withdraws from + service: + + SGP ASP1 ASP2 + | | | + |<-----ASP Inactive------| | + |----ASP Inactive Ack--->| | + | | | + |----NTFY(AS-PENDING)--->| | + |-----------------------NTFY(AS-PENDING)----------->| + | | | + |<----------------------------- ASP Active----------| + |-----------------------------ASP Active Ack------->| + | | | + |----NTFY(AS-ACTIVE)---->| | + |-----------------------NTFY(AS-ACTIVE)------------>| + + Note: If the SGP M3UA layer detects the loss of the M3UA peer (e.g., + M3UA heartbeat loss or detection of SCTP failure), the initial ASP + Inactive message exchange (i.e., SGP to ASP1) would not occur. + +5.2.2. 1+1 Sparing, Backup Override + + Following on from the example in Section 5.1.2, ASP2 wishes to + Override ASP1 and take over the traffic: + + SGP ASP1 ASP2 + | | | + |<----------------------------- ASP Active----------| + |------------------------------ASP Active Ack------>| + |----NTFY(Alt ASP-Act)-->| | + | | | + + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 105] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +5.2.3. n+k Sparing, Loadsharing Case, Withdrawal of ASP + + Following from the example in Section 5.1.4, ASP1 withdraws from + service: + + SGP ASP1 ASP2 ASP3 + | | | | + |<----ASP Inact.----| | | + |---ASP Inact Ack-->| | | + | | | | + |--NTFY(Ins. ASPs)->| | | + |---------------------------------------NOTIFY(Ins. ASPs)-->| + | | | | + | | | | + |<----------------------------------------ASP Act (Ldshr)---| + |------------------------------------------ASP Act (Ack)--->| + | | | | + |-NTFY(AS-ACTIVE)-->| | | + |-------------------NOTIFY(AS-ACTIVE)-->| | + |---------------------------------------NOTIFY(AS-ACTIVE)-->| + | | | | + | | | | + + For the Notify message to be sent, the SG maintains knowledge of the + minimum ASP resources required (e.g., if the SG knows that "n+k" = + "2+1" for a Loadshare AS and "n" currently equals "1"). + + Note: If the SGP detects loss of the ASP1 M3UA peer (e.g., M3UA + heartbeat loss or detection of SCTP failure), the initial ASP + Inactive message exchange (i.e., SGP-ASP1) would not occur. + +5.3. Normal Withdrawal of an ASP from an Application Server + and Teardown of an Association + + An ASP that is now confirmed in the state ASP-INACTIVE (i.e., the ASP + has received an ASP Inactive Ack message) may now proceed to the + ASP-DOWN state, if it is to be removed from service. Following from + Section 5.2.1 or 5.2.3, where ASP1 has moved to the "Inactive" state: + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 106] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + SGP ASP1 + | | + |<-----ASP Inactive (RCn)------| RC: Routing Context + |----ASP Inactive Ack (RCn)--->| + | | + |<-----DEREGISTER REQ(RCn)-----| See Notes + | | + |---DEREGISTER RESP(LRCn,RCn)->| + | | + : : + | | + |<-----------ASP Down----------| + |---------ASP Down Ack-------->| + | | + + Note: The Deregistration procedure will typically be used if the ASP + previously used the Registration procedures for configuration within + the Application Server. ASP Inactive and Deregister messages + exchanges may contain multiple Routing Contexts. + + The ASP should be in the ASP-INACTIVE state and should have + deregistered in all its Routing Contexts before attempting to move to + the ASP-DOWN state. + +5.4. Auditing Examples + +5.4.1. SG State: Uncongested/Available + + ASP SGP + --- --- + | -------- DAUD ---------> | + | <------ SCON(0) -------- | + | <------- DAVA ---------- | + +5.4.2. SG State: Congested (Congestion Level=2) / Available + + ASP SGP + --- --- + | -------- DAUD ---------> | + | <------ SCON(2) -------- | + | <------- DAVA ---------- | + +5.4.3. SG State: Unknown/Available + + ASP SGP + --- --- + | -------- DAUD ---------> | + | <------- DAVA ---------- | + + + +Morneault & Pastor-Balbas Standards Track [Page 107] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +5.4.4. SG State: Unavailable + + ASP SGP + --- --- + | -------- DAUD ---------> | + | <------- DUNA ---------- | + +5.5. M3UA/MTP3-User Boundary Examples + +5.5.1. At an ASP + + This section describes the primitive mapping between the MTP3 User + and the M3UA layer at an ASP. + +5.5.1.1. Support for MTP-TRANSFER Primitives at the ASP + +5.5.1.1.1. Support for MTP-TRANSFER Request Primitive + + When the MTP3-User on the ASP has data to send to a remote MTP3-User, + it uses the MTP-TRANSFER request primitive. The M3UA layer at the + ASP will do the following when it receives an MTP-TRANSFER request + primitive from the M3UA user: + + - Determine the correct SGP. + + - Determine the correct association to the chosen SGP. + + - Determine the correct stream in the association (e.g., + based on SLS). + + - Determine whether to complete the optional fields of the DATA + message. + + - Map the MTP-TRANSFER request primitive into the Protocol Data + field of a DATA message. + + - Send the DATA message to the remote M3UA peer at the SGP, + over the SCTP association. + + SGP ASP + | | + |<-----DATA Message-------|<--MTP-TRANSFER req. + | | + +5.5.1.1.2. Support for the MTP-TRANSFER Indication Primitive + + When the M3UA layer on the ASP receives a DATA message from the M3UA + peer at the remote SGP, it will do the following: + + + +Morneault & Pastor-Balbas Standards Track [Page 108] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + - Evaluate the optional fields of the DATA message, if present. + + - Map the Protocol Data field of a DATA message into the + MTP-TRANSFER indication primitive. + + - Pass the MTP-TRANSFER indication primitive to the user part. In + case of multiple user parts, the optional fields of the Data + message are used to determine the concerned user part. + + SGP ASP + | | + |------Data Message------>|-->MTP-Transfer ind. + | | + +5.5.1.1.3. Support for ASP Querying of SS7 Destination States + + There are situations such as temporary loss of connectivity to the + SGP that may cause the M3UA layer at the ASP to audit SS7 destination + availability/congestion states. Note: there is no primitive for the + MTP3-User to request this audit from the M3UA layer, as this is + initiated by an internal M3UA management function. + + SGP ASP + | | + |<----------DAUD-----------| + |<----------DAUD-----------| + |<----------DAUD-----------| + | | + | | + +5.5.2. At an SGP + + This section describes the primitive mapping between the MTP3-User + and the M3UA layer at an SGP. + +5.5.2.1. Support for MTP-TRANSFER Request Primitive at the SGP + + When the M3UA layer at the SGP has received DATA messages from its + peer destined to the SS7 network, it will do the following: + + - Evaluate the optional fields of the DATA message, if present, to + determine the Network Appearance. + + - Map the Protocol data field of the DATA message into an + MTP-TRANSFER request primitive. + + - Pass the MTP-TRANSFER request primitive to the MTP3 of the + concerned Network Appearance. + + + +Morneault & Pastor-Balbas Standards Track [Page 109] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + SGP ASP + | | + <---MTP-TRANSFER req.|<---------DATA -----------| + | | + +5.5.2.2. Support for MTP-TRANSFER Indication Primitive at the SGP + + When the MTP3 layer at the SGP has data to pass its user parts, it + will use the MTP-TRANSFER indication primitive. The M3UA layer at + the SGP will do the following when it receives an MTP-TRANSFER + indication primitive: + + - Determine the correct AS, using the distribution function; + + - Select an ASP in the ASP-ACTIVE state. + + - Determine the correct association to the chosen ASP. + + - Determine the correct stream in the SCTP association (e.g., + based on SLS). + + - Determine whether to complete the optional fields of the DATA + message. + + - Map the MTP-TRANSFER indication primitive into the Protocol Data + field of a DATA message. + + - Send the DATA message to the remote M3UA peer in the ASP, over + the SCTP association. + + SGP ASP + | | + --MTP-TRANSFER ind.->|-----------DATA --------->| + | | + +5.5.2.3. Support for MTP-PAUSE, MTP-RESUME, MTP-STATUS Indication + Primitives + + The MTP-PAUSE, MTP-RESUME, and MTP-STATUS indication primitives from + the MTP3 upper layer interface at the SGP need to be made available + to the remote MTP3 User Part lower-layer interface at the concerned + ASP(s). + +5.5.2.3.1. Destination Unavailable + + The MTP3 layer at the SGP will generate an MTP-PAUSE indication + primitive when it determines locally that an SS7 destination is + unreachable. The M3UA layer will map this primitive to a DUNA + + + +Morneault & Pastor-Balbas Standards Track [Page 110] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + message. The SGP M3UA layer determines the set of concerned ASPs to + be informed based on internal SS7 network information associated with + the MTP-PAUSE indication primitive indication. + + SGP ASP + | | + --MTP-PAUSE ind.-->|---------DUNA----------->|--MTP-PAUSE ind.--> + | | +5.5.2.3.2. Destination Available + + The MTP3 at the SGP will generate an MTP-RESUME indication primitive + when it determines locally that an SS7 destination that was + previously unreachable is now reachable. The M3UA layer will map + this primitive to a DAVA message. The SGP M3UA determines the set of + concerned ASPs to be informed based on internal SS7 network + information associated with the MTP-RESUME indication primitive. + + SGP ASP + | | + --MTP-RESUME ind.-->|-----------DAVA--------->|--MTP-RESUME ind.--> + | | + +5.5.2.3.3. SS7 Network Congestion + + The MTP3 layer at the SGP will generate an MTP-STATUS indication + primitive when it determines locally that the route to an SS7 + destination is congested. The M3UA layer will map this primitive to + a SCON message. It will determine which ASP(s) to send the SCON + message to, based on the intended Application Server. + + SGP ASP + | | + --MTP-STATUS ind.-->|-----------SCON--------->|--MTP-STATUS ind.--> + | | + +5.5.2.3.4. Destination User Part Unavailable + + The MTP3 layer at the SGP will generate an MTP-STATUS indication + primitive when it receives an UPU message from the SS7 network. The + M3UA layer will map this primitive to a DUPU message. It will + determine which ASP(s) to send the DUPU to based on the intended + Application Server. + + SGP ASP + | | + --MTP-STATUS ind.-->|----------DUPU---------->|--MTP-STATUS ind.--> + | | + + + + +Morneault & Pastor-Balbas Standards Track [Page 111] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +5.6. Examples for IPSP Communication + + These scenarios show a basic example for IPSP communication for the + three phases of the connection (establishment, data exchange, + disconnection). It is assumed that the SCTP association is already + set up. Both single exchange and double exchange behavior are + included for illustrative purposes. + +5.6.1. Single Exchange + + IPSP-A IPSP-B + | | + |-------------ASP Up------------>| + |<----------ASP Up Ack-----------| + | | + |<------- ASP Active(RCb)--------| RC: Routing Context + |-----ASP Active Ack (RCb)------>| (optional) + | | + | | + |<========= DATA (RCb) ========>| + | | + |<-----ASP Inactive (RCb)--------| RC: Routing Context + |----ASP Inactive Ack (RCb)----->| (optional) + | | + |<-----------ASP Down------------| + |---------ASP Down Ack---------->| + | | + + Routing Context is previously agreed to be the same in both + directions. + + + + + + + + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 112] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +5.6.2. Double Exchange + + IPSP-A IPSP-B + | | + |<-------------ASP Up------------| + |-----------ASP Up Ack---------->| + | | + |-------------ASP Up------------>| (optional) + |<----------ASP Up Ack-----------| (optional) + | | + |<------- ASP Active(RCb)--------| RC: Routing Context + |-----ASP Active Ack (RCb)------>| (optional) + | | + |------- ASP Active(RCa)-------->| RC: Routing Context + |<-----ASP Active Ack (RCa)------| (optional) + | | + |<========= DATA (RCa) =========| + |========== DATA (RCb) ========>| + | | + |<-----ASP Inactive (RCb)--------| RC: Routing Context + |----ASP Inactive Ack (RCb)----->| + | | + |------ASP Inactive (RCa)------->| RC: Routing Context + |<----ASP Inactive Ack (RCa)-----| + | | + |<-----------ASP Down------------| + |---------ASP Down Ack---------->| + | | + |------------ASP Down----------->| (optional) + |<--------ASP Down Ack-----------| (optional) + | | + + In this approach, only one single exchange of ASP Up message can be + considered sufficient since the response by the other peer can be + considered a notice that it is in ASP_UP state. + + For the same reason, only one ASP Down message is needed, since once + an IPSP receives ASP_Down ack message it is itself considered to be + in the ASP_Down state and not allowed to receive ASPSM messages. + +6. Security Considerations + + Implementations MUST follow the normative guidance of RFC3788 [11] on + the integration and usage of security mechanisms in SIGTRAN + protocols. + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 113] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +7. IANA Considerations + + This document contains no new actions for IANA. The subsections + below are retained for historical purposes. + +7.1. SCTP Payload Protocol Identifier + + IANA has assigned an M3UA value for the Payload Protocol Identifier + in the SCTP DATA chunk. The following SCTP Payload Protocol + Identifier has been registered: + + M3UA "3" + + The SCTP Payload Protocol Identifier value "3" SHOULD be included in + each SCTP DATA chunk, to indicate that the SCTP is carrying the M3UA + protocol. The value "0" (unspecified) is also allowed but any other + values MUST not be used. This Payload Protocol Identifier is not + directly used by SCTP but MAY be used by certain network entities to + identify the type of information being carried in a DATA chunk. + + The User Adaptation peer MAY use the Payload Protocol Identifier as a + way of determining additional information about the data being + presented to it by SCTP. + +7.2. M3UA Port Number + + IANA has registered SCTP (and UDP/TCP) Port Number 2905 for M3UA. It + is recommended that SGPs use this SCTP port number for listening for + new connections. SGPs MAY also use statically configured SCTP port + numbers instead. + +7.3. M3UA Protocol Extensions + + This protocol may also be extended through IANA in three ways: + + - Through definition of additional message classes. + - Through definition of additional message types. + - Through definition of additional message parameters. + + The definition and use of new message classes, types, and parameters + is an integral part of SIGTRAN adaptation layers. Thus, these + extensions are assigned by IANA through an IETF Consensus action as + defined in Guidelines for Writing an IANA Considerations Section in + RFCs [23]. + + The proposed extension must in no way adversely affect the general + working of the protocol. + + + + +Morneault & Pastor-Balbas Standards Track [Page 114] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +7.3.1. IETF-Defined Message Classes + + The documentation for a new message class MUST include the following + information: + + (a) A long and short name for the new message class. + (b) A detailed description of the purpose of the message class. + +7.3.2. IETF Defined Message Types + + The documentation for a new message type MUST include the following + information: + + (a) A long and short name for the new message type. + (b) A detailed description of the structure of the message. + (c) A detailed definition and description of intended use for each + field within the message. + (d) A detailed procedural description of the use of the new + message type within the operation of the protocol. + (e) A detailed description of error conditions when receiving this + message type. + + When an implementation receives a message type that it does not + support, it MUST respond with an Error (ERR) message ("Unsupported + Message Type"). + +7.3.3. IETF-Defined Parameter Extension + + Documentation of the message parameter MUST contain the following + information: + + (a) Name of the parameter type. + (b) Detailed description of the structure of the parameter field. + This structure MUST conform to the general type-length-value + format described in Section 3.2. + (c) Detailed definition of each component of the parameter value. + (d) Detailed description of the intended use of this parameter + type, and an indication of whether and under what + circumstances multiple instances of this parameter type may be + found within the same message. + +8. Acknowledgements + + The authors would like to thank Antonio Roque Alvarez, Joyce + Archibald, Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes, + Antonio Canete, Nikhil Jain, Roland Jesske, Joe Keller, Kurt Kite, + Ming Lin, Steve Lorusso, Naoto Makinae, Howard May, Francois + Mouillaud, Barry Nagelberg, Neil Olson, Heinz Prantner, Shyamal + + + +Morneault & Pastor-Balbas Standards Track [Page 115] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Prasad, Mukesh Punhani, Selvam Rengasami, John Schantz, Ray Singh, + Michael Tuexen, Nitin Tomar, Gery Verwimp, Tim Vetter, Kazuo + Watanabe, Ben Wilson, and many others for their valuable comments and + suggestions. + +9. Document Contributors + + Ian Rytina - Ericsson + Guy Mousseau - Nortel Networks + Lyndon Ong - Ciena + Hanns Juergen Schwarzbauer - Siemens + Klaus Gradischnig - Detecon Inc. + Mallesh Kalla - Telcordia + Normand Glaude - Performance Technologies + Brian Bidulock - OpenSS7 + John Loughney - Nokia + Greg Sidebottom - Signatus Technologies + +10. References + +10.1. Normative References + + [1] ITU-T Recommendations Q.761 to Q.767, "Signalling System No.7 + (SS7) - ISDN User Part (ISUP)" + + [2] ANSI T1.113 - "Signaling System Number 7 - ISDN User Part" + + [3] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN); + Signalling System No.7; ISDN User Part (ISUP) version 2 for the + international interface; Part 1: Basic services" + + [4] ITU-T Recommendations Q.711 to Q.715, "Signalling System No. 7 + (SS7) - Signalling Connection Control Part (SCCP)" + + [5] ANSI T1.112 "Signaling System Number 7 - Signaling Connection + Control Part" + + [6] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN); + Signalling System No.7; Signalling Connection Control Part + (SCCP) (connectionless and connection-oriented class 2) to + support international interconnection; Part 1: Protocol + specification" + + [7] ITU-T Recommendations Q.700 to Q.705, "Signalling System No. 7 + (SS7) - Message Transfer Part (MTP)" + + [8] ANSI T1.111 "Signaling System Number 7 - Message Transfer Part" + + + + +Morneault & Pastor-Balbas Standards Track [Page 116] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + [9] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN); + Signalling System No.7; Message Transfer Part (MTP) to support + international interconnection; Part 1: Protocol specification" + + [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD + 63, RFC 3629, November 2003. + + [11] Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security + Considerations for Signaling Transport (SIGTRAN) Protocols", RFC + 3788, June 2004. + +10.2. Informative References + + [12] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., + Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework + Architecture for Signaling Transport", RFC 2719, October 1999. + + [13] ITU-T Recommendation Q.720, "Telephone User Part" + + [14] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7 + (SS7) - Transaction Capabilities (TCAP)" + + [15] ANSI T1.114 "Signaling System Number 7 - Transaction + Capabilities Application Part" + + [16] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); + Signalling System No.7; Transaction Capabilities (TC) version 2; + Part 1: Protocol specification" + + [17] 3G TS 25.410 V4.0.0 (2001-04) "Technical Specification - 3rd + Generation partnership Project; Technical Specification Group + Radio Access Network; UTRAN Iu Interface: General Aspects and + Principles" + + [18] 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. + + [19] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer - + Service Specific Coordination Function for signalling at the + Network Node Interface (SSCF at NNI)" + + [20] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer - + Service Specific Connection Oriented Protocol (SSCOP)" + + [21] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + +Morneault & Pastor-Balbas Standards Track [Page 117] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + [22] ITU-T Recommendation Q.2210 "Message Transfer Part Level 3 + functions and messages using the services of ITU Recommendation + Q.2140" + + [23] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [24] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B., and J. + Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) + - User Adaptation Layer", RFC 3331, September 2002. + + [25] George, T., Bidulock, B., Dantu, R., Schwarzbauer, H., and K. + Morneault, "Signaling System 7 (SS7) Message Transfer Part 2 + (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)", RFC 4165, + September 2005. + + [26] Telecommunication Technology Committee (TTC) Standard JT-Q704, + "Message Transfer Part Signaling Network Functions", April 28, + 1992. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 118] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +Appendix A + +A.1. Signalling Network Architecture + + A Signalling Gateway is used to support the transport of MTP3-User + signalling traffic received from the SS7 network to multiple + distributed ASPs (e.g., MGCs and IP Databases). Clearly, the M3UA + protocol is not designed to meet the performance and reliability + requirements for such transport by itself. However, the conjunction + of distributed architecture and redundant networks provides support + for reliable transport of signalling traffic over IP. The M3UA + protocol is flexible enough to allow its operation and management in + a variety of physical configurations, enabling Network Operators to + meet their performance and reliability requirements. + + To meet the stringent SS7 signalling reliability and performance + requirements for carrier grade networks, Network Operators might + require that no single point of failure is present in the end-to-end + network architecture between an SS7 node and an IP-based application. + This can typically be achieved through the use of redundant SGPs or + SGs, redundant hosts, and the provision of redundant QOS-bounded IP + network paths for SCTP Associations between SCTP End Points. + Obviously, the reliability of the SG, the MGC, and other IP-based + functional elements also needs to be taken into account. The + distribution of ASPs and SGPs within the available Hosts MAY also be + considered. As an example, for a particular Application Server, the + related ASPs could be distributed over at least two Hosts. + + One example of a physical network architecture relevant to SS7 + carrier grade operation in the IP network domain is shown in Figure + A-1, below: + + + + + + + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 119] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + SGs MGCs + + Host#1 ************** ************** Host#3 + * ********__*__________________________*__******** * = + * *SGP1.1*__*_____ _______________*__* ASP1 * * MGC1 + * ******** * \ / * ******** * + * ********__*______\__/________________*__******** * + * *SGP2.1*__*_______\/______ _____*__* ASP2 * * + * ******** * /\ | | * ******** * + * : * / \ | | * : * + * ******** * / \ | | * ******** * + * * SGPn * * | | | | * * ASPn * * + * ******** * | | | | * ******** * + ************** | | | | ************** + | | \ / + Host#2 ************** | | \ / ************** Host#4 + * ********__*_____| |______\/_______*__******** * = + * *SGP1.2*__*_________________/\_______*__* ASP1 * * MGC2 + * ******** * / \ * ******** * + * ********__*_______________/ \_____*__******** * + * *SGP2.2*__*__________________________*__* ASP2 * * + * ******** * * ******** * + * : * SCTP Associations * : * + * ******** * * ******** * + * * SGPn * * * * ASPn * * + * ******** * * ******** * + ************** ************** + + SGP1.1 and SGP1.2 are part of SG1 + SGP2.1 and SGP2.2 are part of SG2 + + Figure A-1 - Physical Model + + In this model, each host may have many application processes. In the + case of the MGC, an ASP may provide service to one or more + Application Servers, and is identified as an SCTP end point. One or + more Signalling Gateway Processes make up a single Signalling + Gateway. + + This example model can also be applied to IPSP-IPSP signalling. In + this case, each IPSP may have its services distributed across 2 or + more hosts, and may have multiple server processes on each host. + + In the example above, each signalling process (SGP, ASP, or IPSP) is + the end point to more than one SCTP association, leading to more than + one other signalling processes. To support this, a signalling + process must be able to support distribution of M3UA messages to many + simultaneous active associations. This message distribution function + + + +Morneault & Pastor-Balbas Standards Track [Page 120] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + is based on the status of provisioned Routing Keys, the status of the + signalling routes to signalling points in the SS7 network, and the + redundancy model (active-standby, load sharing, broadcast, n+k) of + the remote signalling processes. + + For carrier grade networks, the failure or isolation of a particular + signalling process should not cause stable calls or transactions to + be lost. This implies that signalling processes need, in some cases, + to share the call/transaction state or be able to pass the call state + information between each other. In the case of ASPs performing call + processing, coordination may also be required with the related Media + Gateway to transfer the MGC control for a particular trunk + termination. However, this sharing or communication of + call/transaction state information is outside the scope of this + document. + + This model serves as an example. M3UA imposes no restrictions as to + the exact layout of the network elements, the message distribution + algorithms, and the distribution of the signalling processes. + Instead, it provides a framework and a set of messages that allow for + a flexible and scalable signalling network architecture, aiming to + provide reliability and performance. + +A.2. Redundancy Models + +A.2.1. Application Server Redundancy + + At the SGP, an Application Server list contains active and inactive + ASPs to support ASP broadcast, loadsharing, and failover procedures. + The list of ASPs within a logical Application Server is kept updated + in the SGP to reflect the active Application Server Process(es). + + For example, in the network shown in Figure 1, all messages to DPC x + could be sent to ASP1 in Host3 or ASP1 in Host4. The AS list at SGP1 + in Host 1 might look like the following: + + Routing Key {DPC=x) - "Application Server #1" + ASP1/Host3 - State = Active + ASP1/Host4 - State = Inactive + + In this "1+1" redundancy case, ASP1 in Host3 would be sent any + incoming message with DPC=x. ASP1 in Host4 would normally be brought + to the "active" state upon failure of, or loss of connectivity to, + ASP1/Host1. + + The AS List at SGP1 in Host1 might also be set up in loadshare mode: + + + + + +Morneault & Pastor-Balbas Standards Track [Page 121] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + Routing Key {DPC=x) - "Application Server #1" + ASP1/Host3 - State = Active + ASP1/Host4 - State = Active + + In this case, both the ASPs would be sent a portion of the traffic. + For example, the two ASPs could together form a database, where + incoming queries may be sent to any active ASP. + + Care might need to be exercised by a Network Operator in the + selection of the routing information to be used as the Routing Key + for a particular AS. + + In the process of failover, it is recommended that, in the case of + ASPs supporting call processing, stable calls do not fail. It is + possible that calls in "transition" may fail, although measures of + communication between the ASPs involved can be used to mitigate this. + + For example, the two ASPs may share call state via shared memory, or + may use an ASP to ASP protocol to pass call state information. Any + ASP-to-ASP protocol to support this function is outside the scope of + this document. + +A.2.2. Signalling Gateway Redundancy + + Signalling Gateways may also be distributed over multiple hosts. + Much like the AS model, SGs may comprise one or more SG Processes + (SGPs), distributed over one or more hosts, using an active/backup or + a loadsharing model. Should an SGP lose all or partial SS7 + connectivity and other SGPs exist, the SGP may terminate the SCTP + associations to the concerned ASPs. + + It is therefore possible for an ASP to route signalling messages + destined to the SS7 network using more than one SGP. In this model, + a Signalling Gateway is deployed as a cluster of hosts acting as a + single SG. A primary/backup redundancy model is possible, where the + unavailability of the SCTP association to a primary SGP could be used + to reroute affected traffic to an alternate SGP. A loadsharing model + is possible, where the signalling messages are loadshared between + multiple SGPs. A broadcast model is also possible, where signalling + messages are sent to each active SGP in the SG. The distribution of + the MTP3-user messages over the SGPs should be done in such a way to + minimize message missequencing, as required by the SS7 User Parts. + + It may also be possible for an ASP to use more than one SG to access + a specific SS7 end point, in a model that resembles an SS7 STP mated + pair. Typically, SS7 STPs are deployed in mated pairs, with traffic + loadshared between them. Other models are also possible, subject to + the limitations of the local SS7 network provisioning guidelines. + + + +Morneault & Pastor-Balbas Standards Track [Page 122] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + + From the perspective of the M3UA layer at an ASP, a particular SG is + capable of transferring traffic to a provisioned SS7 destination X if + an SCTP association with at least one SGP of the SG is established, + the SGP has returned an acknowledgement to the ASP to indicate that + the ASP is actively handling traffic for that destination X, the SGP + has not indicated that the destination X is inaccessible, and the SGP + has not indicated MTP Restart. When an ASP is configured to use + multiple SGPs for transferring traffic to the SS7 network, the ASP + must maintain knowledge of the current capability of the SGPs to + handle traffic to destinations of interest. This information is + crucial to the overall reliability of the service, for active/backup, + loadsharing, and broadcast models, in the event of failures and + recovery and maintenance activities. The ASP M3UA may also use this + information for congestion avoidance purposes. The distribution of + the MTP3-user messages over the SGPs should be done in such a way as + to minimize message missequencing, as required by the SS7 User Parts. + +Editors' Addresses + + Ken Morneault + Cisco Systems Inc. + 13615 Dulles Technology Drive + Herndon, VA, USA 20171 + + EMail: kmorneau@cisco.com + + + Javier Pastor-Balbas + Ericsson Espana S.A. + C/ Retama 1 + 28045 Madrid - Spain + + EMail: j.javier.pastor@ericsson.com + + + + + + + + + + + + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 123] + +RFC 4666 SS7 MTP3-User Adaptation Layer September 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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. + + 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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Morneault & Pastor-Balbas Standards Track [Page 124] + -- cgit v1.2.3