diff options
Diffstat (limited to 'doc/rfc/rfc3332.txt')
| -rw-r--r-- | doc/rfc/rfc3332.txt | 6723 |
1 files changed, 6723 insertions, 0 deletions
diff --git a/doc/rfc/rfc3332.txt b/doc/rfc/rfc3332.txt new file mode 100644 index 0000000..9ecf84c --- /dev/null +++ b/doc/rfc/rfc3332.txt @@ -0,0 +1,6723 @@ + + + + + + +Network Working Group G. Sidebottom +Request for Comments: 3332 Signatus Technologies +Category: Standards Track K. Morneault + Cisco + J. Pastor-Balbas + Ericsson + Editors + September 2002 + + + 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 (2002). All Rights Reserved. + +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. + +Table of Contents + + 1. Introduction..................................................3 + 1.1 Scope.........................................................3 + 1.2 Terminology...................................................4 + 1.3 M3UA Overview.................................................6 + 1.4 Functional Areas.............................................10 + 1.5 Sample Configurations........................................18 + 1.6 Definition of M3UA Boundaries................................21 + 2. Conventions..................................................25 + + + +Sidebottom, et. al. Standards Track [Page 1] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 3. M3UA Protocol Elements.......................................25 + 3.1 Common Message Header........................................26 + 3.2 Variable Length Parameter....................................29 + 3.3 Transfer Messages............................................31 + 3.4 SS7 Signalling Network Management (SSNM) Messages............35 + 3.5 ASP State Maintenance (ASPSM) Messages.......................45 + 3.6 Routing Key Management (RKM) Messages........................48 + 3.7 ASP Traffic Maintenance (ASPTM) Messages.....................59 + 3.8 Management (MGMT) Messages...................................63 + 4. Procedures...................................................69 + 4.1 Procedures to Support the M3UA-User .........................69 + 4.2 Procedures to Support the Management of SCTP Associations ...70 + 4.3 AS and ASP State Maintenance.................................72 + 4.4 Routing Key Management Procedures............................87 + 4.5 Procedures to Support the Availability or Congestion Status + of SS7 Destination...........................................89 + 4.6 MTP3 Restart.................................................92 + 5. Examples of M3UA Procedures..................................93 + 5.1 Establishment of Association and Traffic + Between SGs and ASPs.........................................93 + 5.2 ASP traffic Failover Examples................................99 + 5.3 Normal Withdrawal of an ASP from an Application Server + and Teardown of an Association..............................100 + 5.4 M3UA/MTP3-User Boundary Examples............................101 + 5.5 Examples of IPSP communication..............................105 + 6. Security Considerations.....................................108 + 6.1 Introduction................................................108 + 6.2 Threats.....................................................108 + 6.3 Protecting Confidentiality..................................108 + 7. IANA Considerations.........................................109 + 7.1 SCTP Payload Protocol Identifier............................109 + 7.2 M3UA Port Number............................................109 + 7.3 M3UA Protocol Extensions....................................109 + 8. References...................................................111 + 8.1 Normative References........................................111 + 8.2 Informative References......................................111 + 9. Acknowledgements.............................................113 + 10. Document Contributors.......................................113 + Appendix A......................................................114 + A.1 Signalling Network Architecture.............................114 + A.2 Redundancy Models...........................................117 + Editors' Addresses..............................................119 + Full Copyright Statement........................................120 + + + + + + + + +Sidebottom, et. al. Standards Track [Page 2] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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 [17]. 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 + Gaway Controller (MGC) or IP-resident Database [11], 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 [11]. 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 [12], 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. + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 3] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +1.2 Terminology + + Application Server (AS) - A logical entity serving a specific Routing + Key. An example of an Application Server is a virtual switch element + handling all call processing for a unique range of PSTN trunks, + identified by an SS7 SIO/DPC/OPC/CIC_range. Another example is a + virtual database element, handling all HLR transactions for a + particular SS7 DPC/OPC/SCCP_SSN combination. The AS contains a set + of one or more unique Application Server Processes, of which one or + more is normally actively processing traffic. Note that there is a + 1:1 relationship between an AS and a Routing Key. + + Application Server Process (ASP) - A process instance of an + Application Server. An Application Server Process serves as an active + or backup process of an Application Server (e.g., part of a + distributed virtual switch or database). Examples of ASPs are + processes (or process instances) of MGCs, IP SCPs or IP HLRs. An ASP + contains an SCTP endpoint and may be configured to process signalling + traffic within more than one Application Server. + + Association - An association refers to an SCTP association. The + association provides the transport for the delivery of 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. + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 4] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 it belongs to. It can be used to distinguish + between signalling traffic associated with different networks being + sent between the SG and the ASP over a common SCTP association. An + example scenario is where an SG appears as an element in multiple + separate national SS7 networks and the same Signaling Point Code + value may be reused in different networks. + + Network Byte Order: Most significant byte first, a.k.a Big Endian. + + Routing Key: A Routing Key describes a set of SS7 parameters and + parameter values that uniquely define the range of signalling traffic + to be handled by a particular Application Server. Parameters within + the Routing Key cannot extend across more than a single Signalling + Point Management Cluster. + + Routing Context - A value that uniquely identifies a Routing Key. + Routing Context values are either configured using a configuration + management interface, or by using the routing key management + procedures defined in this document. + + 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 - An SG is a signaling agent that receives/sends + SCN native signaling at the edge of the IP network [11]. 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. + + + + + + +Sidebottom, et. al. Standards Track [Page 5] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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. + + Stream - A stream refers to an SCTP stream; a unidirectional logical + channel established from one SCTP endpoint to another associated SCTP + endpoint, within which all user messages are delivered in-sequence + except for those submitted to the unordered delivery service. + +1.3 M3UA Overview + +1.3.1 Protocol Architecture + + The framework architecture that has been defined for SCN signalling + transport over IP [11] 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) [12]. TCAP [13,14,15] + 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) [17] as the underlying reliable common + signalling transport protocol. This is to take advantage of various + SCTP features such as: + + + + + + + + +Sidebottom, et. al. Standards Track [Page 6] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + - 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, and + - 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. + +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. + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 7] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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, 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 + size. Some configurations (e.g., Broadband MTP [21]) 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. + + + + + + +Sidebottom, et. al. Standards Track [Page 8] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + - Providing an indication to the M3UA layer at an ASP that the routes + to a destination in the SS7 network are restricted. + + - 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, 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. As well, 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 + 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. + + + + + + + + +Sidebottom, et. al. Standards Track [Page 9] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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. + + 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 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, 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 + + + +Sidebottom, et. al. Standards Track [Page 10] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 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 + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 11] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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-byte 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, SIO found in the MTP3 + routing label, or MTP3-User specific fields (such as the ISUP CIC, + SCCP subsystem number). Some example Routing Keys are: the DPC + alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or the + DPC/SSN 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. + +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. It is not necessary for the parameter range values + within a particular Routing Key to be contiguous. For example, an AS + could be configured to support call processing for multiple ranges of + PSTN trunks that are not represented by contiguous CIC values. + +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. + + + + + +Sidebottom, et. al. Standards Track [Page 12] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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. + + 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 ASP(s), or to drop the + message and provide a notification to layer management. The + treatment of unallocated traffic is implementation dependent. + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 13] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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. + + From an SS7 perspective, it is expected that the Signalling Gateway + transmits and receives SS7 Message Signalling Units (MSUs) to and + from the PSTN over a standard SS7 network interface, using the SS7 + Message Transfer Part (MTP) [7,8,9] to provide reliable transport of + the messages. + + 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) [18,19]. + + Note: It is also possible for IP-based interfaces to be present, + using the services of the MTP2-User Adaptation Layer (M2UA) [27] or + M2PA [28]. + + + + +Sidebottom, et. al. Standards Track [Page 14] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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. + 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 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. + + + +Sidebottom, et. al. Standards Track [Page 15] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +1.4.4 Redundancy Models + +1.4.4.1 Application Server Redundancy + + All MTP3-User messages (e.g., ISUP, SCCP) which 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. 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. + +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 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 + 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. + + + + + + +Sidebottom, et. al. Standards Track [Page 16] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 or the ISUP CIC assignment, subject of course to the + maximum number of streams supported by the underlying SCTP + association. + +1.4.8 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 + 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. + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 17] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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, + 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. + + + +Sidebottom, et. al. Standards Track [Page 18] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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. + + + + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 19] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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 the resulting MTP- + TRANSFER request primitive would be sent back to the M3UA layer for + delivery to an IP destination. + + + + + +Sidebottom, et. al. Standards Track [Page 20] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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/SSN 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 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 + +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 [17] Section 10. + +1.6.3 Definition of the Boundary between M3UA and Layer Management + + M-SCTP_ESTABLISH request + Direction: LM -> M3UA + Purpose: LM requests ASP to establish an SCTP association with its + peer. + + M-STCP_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. + + + + + +Sidebottom, et. al. Standards Track [Page 21] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + M-SCTP_RELEASE request + Direction: LM -> M3UA + Purpose: LM requests ASP to 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 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 M3UA to report the status of an SCTP + association. + + M-SCTP_STATUS confirm + Direction: M3UA -> LM + Purpose: M3UA responds with the status of an SCTP association. + + + 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 M3UA to report the status of a local or remote + ASP. + + M-ASP_STATUS confirm + Direction: M3UA -> LM + Purpose: M3UA reports status of local or remote ASP. + + M-AS_STATUS request + Direction: LM -> M3UA + Purpose: LM requests M3UA to report the status of an AS. + + + + + +Sidebottom, et. al. Standards Track [Page 22] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 ASP to start its operation and send an ASP Up + message to its peer. + + M-ASP_UP confirm + Direction: M3UA -> LM + Purpose: ASP reports that is has received an ASP UP Ack message from + its peer. + + M-ASP_UP indication + Direction: M3UA -> LM + Purpose: M3UA reports it has successfully processed an incoming ASP + Up message from its peer. + + M-ASP_DOWN request + Direction: LM -> M3UA + Purpose: LM requests ASP to stop its operation and send an ASP Down + message to its peer. + + M-ASP_DOWN confirm + Direction: M3UA -> LM + Purpose: ASP reports that is has received an ASP Down Ack message + from its peer. + + M-ASP_DOWN indication + Direction: M3UA -> LM + Purpose: M3UA reports it has successfully processed an incoming ASP + Down message from its peer, or the SCTP association has + been lost/reset. + + + + + + + +Sidebottom, et. al. Standards Track [Page 23] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + M-ASP_ACTIVE request + Direction: LM -> M3UA + Purpose: LM requests ASP to send an ASP Active message to its peer. + + M-ASP_ACTIVE confirm + Direction: M3UA -> LM + Purpose: ASP reports that is has received an ASP Active + Ack message from its peer. + + M-ASP_ACTIVE indication + Direction: M3UA -> LM + Purpose: M3UA reports it has successfully processed an incoming ASP + Active message from its peer. + + M-ASP_INACTIVE request + Direction: LM -> M3UA + Purpose: LM requests ASP to send an ASP Inactive message to its + peer. + + M-ASP_INACTIVE confirm + Direction: LM -> M3UA + Purpose: ASP reports that is has received an ASP Inactive + Ack message from its peer. + + M-ASP_INACTIVE indication + Direction: M3UA -> LM + Purpose: M3UA reports 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. + + 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 ASP to register RK(s) with its peer by sending + REG REQ message + + + +Sidebottom, et. al. Standards Track [Page 24] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + M-RK_REG confirm + Direction: M3UA -> LM + Purpose: ASP reports that it has received REG RSP message with + registration status as 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 ASP to deregister RK(s) with its peer by + sending DEREG REQ message. + + M-RK_DEREG confirm + Direction: M3UA -> LM + Purpose: ASP reports that it has received DEREG REQ message with + deregistration status as 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 + + The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, + SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when + they appear in this document, are to be interpreted as described in + [20]. + +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. + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 25] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +3.1 Common Message Header + + The protocol messages for MTP3-User Adaptation require a message + header which 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 the 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 the following: + + 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 + 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 + + + + +Sidebottom, et. al. Standards Track [Page 26] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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) + 7 to 127 Reserved by the IETF + 128 to 255 Reserved for IETF-Defined ASPSM extensions + + + + + + + + +Sidebottom, et. al. Standards Track [Page 27] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 bytes, if any. + + Note: A receiver SHOULD accept the message whether or not the final + parameter padding is included in the message length. + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 28] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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. + + 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. + + 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 + + + +Sidebottom, et. al. Standards Track [Page 29] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + Not Used in M3UA 0x000e + Not Used in M3UA 0x000f + Not Used in M3UA 0x0010 + ASP Identifier 0x0011 + 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 + Circuit Range 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 description + are reserved for use by the IETF. + + Parameter Length: 16 bits (unsigned integer) + + The Parameter Length field contains the size of the parameter in + bytes, 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 bytes. + + + + + + + +Sidebottom, et. al. Standards Track [Page 30] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + Parameter Value: variable length. + + The Parameter Value field contains the actual information to be + transferred in the parameter. + + The total length of a parameter (including Tag, Parameter Length + and Value fields) MUST be a multiple of 4 bytes. If the length of + the parameter is not a multiple of 4 bytes, the sender pads the + Parameter at the end (i.e., after the Parameter Value field) with + all zero bytes. The length of the padding is NOT included in the + parameter length field. A sender SHOULD NOT pad with more than 3 + bytes. The receiver MUST ignore the padding bytes. + +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 Optional + Protocol Data Mandatory + Correlation Id Optional + + + + + + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 31] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 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 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 over 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. + + + + + +Sidebottom, et. al. Standards Track [Page 32] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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. + + 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. Includes: + + MTP3-User protocol elements (e.g., ISUP, SCCP, or TUP + parameters). + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 33] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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'. + + 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 [29] message + priority bits. The MP bits are aligned to the least significant bit. + Unused bits are coded `0'. + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 34] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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: (byte string) + + The User Protocol Data field contains a byte string of MTP-User + information from the original SS7 message starting with the first + byte of the original SS7 message following the Routing Label. + + 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. + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 35] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + The DUNA message contains the following parameters: + + Network Appearance Optional + Routing Context Optional + 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 + + See Section 3.3.1 + + Routing Context: n x 32-bits (unsigned integer) + + The optional 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 + + + +Sidebottom, et. al. Standards Track [Page 36] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 reception of an MTP3 + management message or a linkset event simultaneously affects the + availability status of a list of destinations at an SG. + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 37] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 reception 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 is "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 is "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. + +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. + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 38] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + The DAVA message contains the following parameters: + + Network Appearance Optional + Routing Context Optional + Affected Point Code Mandatory + INFO String Optional + + The format and description of the Network Appearance, Routing + Context, Affected Point Code and INFO String parameters is 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 Optional + Affected Point Code Mandatory + INFO String Optional + + The format and description of DAUD Message parameters is the same as + for the DUNA message (See Section 3.4.1). + +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 M3UA layer + or the ASP is congested. + + The SCON message contains the following parameters: + + Network Appearance Optional + Routing Context Optional + Affected Point Code Mandatory + Concerned Destination Optional + Congestion Indications Optional + INFO String Optional + + + + + +Sidebottom, et. al. Standards Track [Page 39] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 40] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + The format and description of the Network Appearance, Routing + Context, Affected Point Code, and INFO String parameters is 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 + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 41] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + The congestion levels are defined in the congestion method in the + appropriate national MTP recommendations [7,8]. + +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 Optional + 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 / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + +Sidebottom, et. al. Standards Track [Page 42] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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, ...). 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 is + 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 + + + +Sidebottom, et. al. Standards Track [Page 43] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 is 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 route(s) 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 Optional + Affected Point Code Mandatory + INFO String Optional + + The format and description of the Network Appearance, Routing + Context, Affected Point Code and INFO String parameters is the same + as for the DUNA message (See Section 3.4.1). + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 44] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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. + + 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 + is the same as for the DUNA message (See Section 3.4.1). + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 45] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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: + + INFO String (optional) + + 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 =0x0004 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / INFO String / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The format and description of the optional INFO String parameter is + 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 parameters: + + INFO String Optional + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 46] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The format and description of the optional INFO String parameter is + 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 parameters: + + 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 is + 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). + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 47] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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 parameters: + + Heartbeat Data Optional + + 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 expects to receive a REG RSP message in return with an + associated Routing Context value. + + + + + + + +Sidebottom, et. al. Standards Track [Page 48] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + The REG REQ message contains the following parameters: + + Routing Key Mandatory + + 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. + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 49] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Traffic Mode Type (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination Point Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network Appearance (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Service Indicators (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Originating Point Code List (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Circuit Range List (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + \ \ + / ... / + \ \ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination Point Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Service Indicators (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Originating Point Code List (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Circuit Range List (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Note: The Destination Point Code, Service Indicators, Originating + Point Code List and Circuit Range 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 is 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. + + + + + + +Sidebottom, et. al. Standards Track [Page 50] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 identifies + the Destination Point Code of incoming SS7 traffic for which the + ASP is registering. 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + +Sidebottom, et. al. Standards Track [Page 51] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + Network Appearance: + + The optional Network Appearance parameter field identifies the SS7 + network context for the Routing Key, and has the same format as in + the DATA message (See Section 3.3.1). The absence of the Network + Appearance parameter in the Routing Key indicates the use of any + Network Appearance value. 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 as 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + OPC List: + + The Originating Point Code List parameter contains one or more SS7 + OPC entries, and its format is the same as the Destination Point + Code parameter. The absence of the OPC List parameter in the + Routing Key indicates the use of any OPC value, + + + + + + +Sidebottom, et. al. Standards Track [Page 52] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 = 0 | Origination Point Code #1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask = 0 | Origination Point Code #2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / ... / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask = 0 | Origination Point Code #n | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Circuit Range: + + An ISUP controlled circuit is uniquely identified by the SS7 OPC, + DPC and CIC value. For the purposes of identifying Circuit Ranges + in an M3UA Routing Key, the optional Circuit Range parameter + includes one or more circuit ranges, each identified by an OPC and + Upper/Lower CIC value. The DPC is implicit as it is mandatory and + already included in the DPC parameter of the Routing Key. The + absence of the Circuit Range parameter in the Routing Key + indicates the use of any Circuit Range values, in the case of + ISUP/TUP traffic. The Origination Point Code is encoded the same + as the Destination Point Code parameter, while the CIC values are + 16-bit integers. + + + + + + + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 53] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + The Circuit Range format 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 = 0x020f | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask = 0 | Origination Point Code #1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Lower CIC Value #1 | Upper CIC Value #1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask = 0 | Origination Point Code #2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Lower CIC Value #2 | Upper CIC Value #2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / ... / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Mask = 0 | Origination Point Code #n | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Lower CIC Value #n | Upper CIC Value #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 parameters: + + Registration Result Mandatory + + One or more Registration Result parameters MUST be included. The + format for the REG RSP message is as follows: + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 54] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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). + + + +Sidebottom, et. al. Standards Track [Page 55] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 + + 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 + + The format for the DEREG REQ message is as follows: + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 56] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 parameters: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Sidebottom, et. al. Standards Track [Page 57] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 + + + + + + + + +Sidebottom, et. al. Standards Track [Page 58] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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 + + + + +Sidebottom, et. al. Standards Track [Page 59] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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, and 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 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 + call processing for multiple ranges of PSTN trunks and therefore + receive related signalling traffic, identified by separate SS7 + DPC/OPC/CIC ranges. + + The format and description of the optional INFO String parameter is + 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 + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 60] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 is + 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 + + + + + + + + +Sidebottom, et. al. Standards Track [Page 61] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 is 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 + + + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 62] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 is + 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. + + The Error message contains the following parameters: + + Error Code Mandatory + Routing Context Mandatory* + Network Appearance Mandatory* + Affected Point Code Mandatory* + Diagnostic Information Optional + + (*) Only mandatory for specific Error Codes + + + + + +Sidebottom, et. al. Standards Track [Page 63] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 + + + +Sidebottom, et. al. Standards Track [Page 64] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 Stream Identifier" error is sent if a message is + received on an unexpected SCTP stream (e.g., a MGMT message was + received on a stream other than "0"). Error messages MUST NOT be + generated in response to other Error messages. + + The "Unsupported Message Class" error is sent if a message with an + unexpected or unsupported Message Class is received. + + The "Unsupported Message Type" error is sent if a message with an + unexpected or unsupported Message Type is received. + + 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 + Routing Context(s), the Routing Context(s) SHOULD be included in the + Error message. + + + + + +Sidebottom, et. al. Standards Track [Page 65] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + The "Protocol Error" error is sent for any protocol anomaly (i.e., + reception 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" is sent by a SGP in response to an ASP + Up message which 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" 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 a 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. + + + + + + + +Sidebottom, et. al. Standards Track [Page 66] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + The "Missing Parameter" error would be sent if a mandatory parameter + were not included in a 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. + +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 Optional + Routing Context Optional + INFO String Optional + + + + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 67] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + The format for the Notify 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 = 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) + + + + + + +Sidebottom, et. al. Standards Track [Page 68] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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. + + 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 + ASP(s) in the AS that one of the ASPs has transitioned to ASP-DOWN. + The ASP Identifier (if available) of the failed ASP MUST be placed in + the message. + + The format and description of the optional 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 is the + same as for the ASP Active message (See Section 3.7.1) + +4. Procedures + + The M3UA layer needs to respond to various local primitives it + receives from other layers as well as 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. + + + + + + + +Sidebottom, et. al. Standards Track [Page 69] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + The M3UA message distribution function (see Section 1.4.2.1) + determines the Application Server (AS) based on 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 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. + +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 + + + +Sidebottom, et. al. Standards Track [Page 70] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 [17] 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 + 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. + + + + + + + +Sidebottom, et. al. Standards Track [Page 71] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 request, M-ASP_DOWN request, M-ASP_ACTIVE request 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 and + 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. + +4.3 AS and ASP 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. For the + purposes of the following procedures, only the SGP/ASP case is + described but the SGP side of the procedures also apply to an IPSP + sending traffic to an AS consisting of a set of remote IPSPs. + + + + + + + + +Sidebottom, et. al. Standards Track [Page 72] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +4.3.1 ASP States + + The state of each remote ASP, in each AS that it is configured to + operate, is maintained in the M3UA layer in the SGP. The state of a + particular ASP in a particular AS changes due to events. The events + include: + + * Reception of messages from the peer M3UA layer at the ASP; + * Reception of some messages from the peer M3UA layer at other ASPs + in the AS (e.g., ASP Active message indicating "Override"); + * Reception of indications from the SCTP layer; or + * Local Management intervention. + + The ASP state transition diagram is shown in Figure 3. The possible + states of an ASP are: + + ASP-DOWN: The remote M3UA peer at the ASP is unavailable and/or the + related SCTP association is down. Initially all ASPs will be in this + state. An ASP 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 is available (and the + related SCTP association is up) but application traffic is stopped. + In this state the ASP SHOULD NOT be sent any DATA or SSNM messages + for the AS for which the ASP is inactive. + + ASP-ACTIVE: The remote M3UA peer at the ASP 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 + of connectivity to the ASP's peer SCTP layer. SCTP CDI is understood + as either a SHUTDOWN_COMPLETE notification or 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 ASP's peer SCTP layer. + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 73] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + Figure 3: ASP State Transition Diagram, per AS + + +--------------+ + | | + +----------------------| ASP-ACTIVE | + | Other +-------| | + | ASP in AS | +--------------+ + | Overrides | ^ | + | | ASP | | ASP + | | Active | | Inactive + | | | v + | | +--------------+ + | | | | + | +------>| ASP-INACTIVE | + | +--------------+ + | ^ | + ASP Down/ | ASP | | ASP Down / + SCTP CDI/ | Up | | SCTP CDI/ + SCTP RI | | v SCTP RI + | +--------------+ + | | | + +--------------------->| ASP-DOWN | + | | + +--------------+ + +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 the 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 (i.e., one or more related ASPs are in the ASP- + INACTIVE state, but none in the ASP-ACTIVE state). The recovery + timer T(r) is not running or has expired. + + + + + + + +Sidebottom, et. al. Standards Track [Page 74] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + AS-ACTIVE: The Application Server is available and application + traffic is active. This state implies that at least one ASP is in + 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 stops queuing messages and discards all + previously queued messages. The AS will move to the AS-INACTIVE + state. + + If at least one ASP is in ASP-INACTIVE state, 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. For 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 75] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + Figure 4: AS State Transition Diagram + + +----------+ one ASP trans to ACTIVE +-------------+ + | AS- |---------------------------->| AS- | + | INACTIVE | | ACTIVE | + | |<--- | | + +----------+ \ +-------------+ + ^ | \ Tr Expiry, ^ | + | | \ at least one | | + | | \ ASP in ASP-INACTIVE | | + | | \ | | + | | \ | | + | | \ | | + one ASP | | all ASP \ one ASP | | Last ACTIVE + trans | | trans to \ trans to | | ASP trans to + to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE + ASP- | | \ ACTIVE | | or ASP-DOWN + INACTIVE| | \ | | (start Tr) + | | \ | | + | | \ | | + | v \ | v + +----------+ \ +-------------+ + | | --| | + | AS-DOWN | | AS-PENDING | + | | | (queuing) | + | |<----------------------------| | + +----------+ Tr Expiry and no ASP +-------------+ + in ASP-INACTIVE state) + + Tr = Recovery Timer + + 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 first successful REG REQ from an ASP. Another + example is where the AS/ASP configuration data is not created until + the first ASP successfully enters the ASP-ACTIVE state. In this 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) and + 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). + + + +Sidebottom, et. al. Standards Track [Page 76] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 re-establish using the + M-SCTP_ESTABLISH request primitive. + + In the case of an SCTP-RESTART indication at an ASP, the ASP is now + considered by its M3UA peer to be in the ASP-DOWN state. 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 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 Server(s), + 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. + + + + + + + +Sidebottom, et. al. Standards Track [Page 77] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 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), and the remote ASP state is + changed to ASP-INACTIVE in all relevant Application Servers. + + 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. + +4.3.4.1.1 M3UA Version Control + + 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. + + 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 assumed that the Error + message would normally come from the SGP. + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 78] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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 + 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, an interchange of ASP Up messages from each end can be + performed. This option follows the ASP state transition diagram. It + would need four messages 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 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 as + 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 as in the ASP-DOWN state. + + + + +Sidebottom, et. al. Standards Track [Page 79] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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. + + 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 that 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 + + + + +Sidebottom, et. al. Standards Track [Page 80] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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. + + 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 SGP or IPSP MUST send an + Error message ("Invalid Routing Context") for each Routing Context + value that the ASP cannot be successfully activated . + + In the case where an "out-of-the-blue" ASP Active message is received + (i.e., the ASP has not registered with the SG or the SG has no static + configuration data for the ASP), the message MAY be silently + discarded. + + 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 + ASP-ACTIVE state at the SGP. + + 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 message(s) 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 reception of the ASP Active Ack message. + + When the ASP sends an ASP Active message it starts 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 + + + + + +Sidebottom, et. al. Standards Track [Page 81] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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, reception 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 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, reception of an ASP Active + message at an SGP or IPSP causes the 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, ISUP CIC value). + + An SGP or IPSP, upon reception 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 which 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, reception of an ASP Active + message at an SGP or IPSP causes the 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. + + + + + +Sidebottom, et. al. Standards Track [Page 82] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + An SGP or IPSP, upon reception 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 which 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. + +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, an interchange of ASP Active messages from each end + can be performed. This option follows the ASP state transition + diagram and gives the additional advantage of selecting a particular + AS to be activated from each end. It is especially useful when an + IPSP is serving more than one AS. It would need four messages for + completion. + +4.3.4.4 ASP Inactive Procedures + + When an ASP wishes to withdraw from receiving traffic within an AS, + the ASP sends an ASP Inactive message to the SGP or IPSP. This + action 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 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 and + 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 + + + +Sidebottom, et. al. Standards Track [Page 83] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + over the traffic within the AS with an ASP Active ("Override") + message, the ASP that sends the ASP Inactive message is already + considered by the SGP to be in state ASP-INACTIVE. 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 and 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 + itself as 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 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, + + + + +Sidebottom, et. al. Standards Track [Page 84] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + retransmission of ASP Inactive messages MAY be put under control of + Layer Management. In this method, expiry of T(ack) results in a 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 of + the ASPs in the AS which 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, an interchange of ASP Inactive messages from each end + can be performed. This option follows the ASP state transition + diagram and gives the additional advantage of selecting a particular + AS to be deactivated from each end. It is especially useful when an + IPSP is serving more than one AS. It would need four messages 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 reception 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). + + 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. + + + + +Sidebottom, et. al. Standards Track [Page 85] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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). + + Note: Heartbeat related events are not shown in Figure 3 "ASP state + transition diagram". + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 86] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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 Type". + + 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", "Error - Invalid Network + Appearance" as appropriate. + + If the SGP determines that a unique Routing Key cannot be created, + 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. + + 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". + + + + + + +Sidebottom, et. al. Standards Track [Page 87] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + If an SGP determines that a received Routing Key does not currently + exist and 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 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 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". This result MAY be used if, for example, the SGP does not + support RK Circuit Range Lists in a Routing Key because the SGP does + not support ISUP traffic, or does not provide CIC range granularity. + + 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 that it is a member + before attempting to move to the ASP-Down state. + + + + +Sidebottom, et. al. Standards Track [Page 88] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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. + + 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 + + + + +Sidebottom, et. al. Standards Track [Page 89] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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. + + DUNA, DAVA, SCON, and DRST messages may be sent sequentially and + processed at the receiver in the order sent. + + 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 effected + 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 + + + + +Sidebottom, et. al. Standards Track [Page 90] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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. + + 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 reception 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"). This is because the value indicates + either congestion abatement or that the ITU MTP3 international + congestion method is being used. In the international congestion + method, the MTP3 layer at the SGP does not maintain the congestion + status of any destinations and therefore the SGP cannot provide any + congestion information in response to the DAUD. For the same reason, + in the second of the cases above a DAUD message cannot reveal any + congested destination(s). + + The SGP SHOULD respond to a DAUD message with the MTP3 + availability/congested status of the routeset associated with each + Destination Point Code(s) 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). Where the SGP maintains the + congestion status of the SS7 destination, and the SS7 destination is + congested, the SGP MUST additionally respond with an SCON message + before the DAVA or DRST message. If the SS7 destination is available + and congested, the SGP MUST respond with an SCON message and then a + DAVA message. If the SS7 destination is restricted and congested, + the SGP MUST respond with an SCON message immediately followed by a + DRST message. If the SGP has no information on the availability + + + + + +Sidebottom, et. al. Standards Track [Page 91] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + status of the SS7 destination, the SGP responds with a DUNA message, + as it has no routing information to allow it to route traffic to this + destination. + + 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") + +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 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 for example the + case when 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. + + 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 + + + +Sidebottom, et. al. Standards Track [Page 92] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + Traffic Restart Allowed messages indicating the end of the restart + procedure between peer IPSPs that would also be connected to an SS7 + network. + +5. Examples of M3UA Procedures + + NOTE: Not all the Notify messages that are appropriate per the Notify + procedures are shown in these examples. + +5.1 Establishment of Association and Traffic between SGPs and ASPs + + These scenarios show the example 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), + + These scenarios show the example 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--------->| + | | + |<------- 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. + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 93] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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 + | | Context + |----REGISTER RESP(LRCn,RCn)--->| RK: Routing Key + | | RC: Routing Context + | | + |<------- 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. + + + + + + + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 94] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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 + | | Context + |----REGISTER RESP(LRC1,RC1)--->| RK: Routing Key + | | RC: Routing Context + | | + |<------- ASP Active(RC1)-------| + |-----ASP Active Ack (RC1)----->| + | | + | | + |<----REGISTER REQ(LRCn,RKn)----| + | | + |----REGISTER RESP(LRCn,RCn)--->| + | | + | | + |<------- ASP Active(RCn)-------| + |-----ASP Active Ack (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. + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 95] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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}) | + | | + |<------- ASP Active(RC1)-------| + |-----ASP Active Ack (RC1)----->| + | | + : : + : : + | | + |<------- ASP Active(RCn)-------| + |-----ASP Active Ack (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. + +5.1.2 Two ASPs in Application Server ("1+1" sparing) + + This scenario shows the 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 + + + + + +Sidebottom, et. al. Standards Track [Page 96] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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------>| | + | | | + |<----------------------------ASP Up----------------| + |----------------------------ASP Up Ack------------>| + | | | + | | | + |<-------ASP Active------| | + |------ASP Active Ack--->| | + | | | + +5.1.3 Two ASPs in an Application Server ("1+1" sparing, + loadsharing case) + + This scenario shows a similar case 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----->| | + | | | + |<-----------------------------ASP Up---------------| + |----------------------------ASP Up Ack------------>| + | | | + | | | + |<--ASP Active (Ldshr)---| | + |-----ASP-Active Ack---->| | + | | | + |---NOTIFY (AS-ACTIVE)-->| | + |---------------------------NOTIFY (AS-ACTIVE------>| + | | | + |<---------------------------ASP Active (Ldshr)-----| + |------------------------------ASP Active Ack------>| + | | | + + + + + + + + +Sidebottom, et. al. Standards Track [Page 97] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +5.1.4 Three ASPs in an Application Server ("n+k" sparing, + loadsharing case) + + This scenario shows the 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--->| | | + | | | | + |<-------------------------ASP Up-------| | + |------------------------ASP Up Ack---->| | + | | | | + |<--------------------------------------------ASP Up--------| + |--------------------------------------------ASP Up Ack---->| + | | | | + | | | | + |<--ASP Act (Ldshr)-| | | + |----ASP Act Ack--->| | | + | | | | + | | | | + |<-------------------ASP Act. (Ldshr)---| | + |----------------------ASP Act Ack----->| | + | | | | + |---------Notify (AS-ACTIVE)----------->| | + |----------------------Notify (AS-ACTIVE)------------------>| + + + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 98] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +5.2 ASP Traffic Failover Examples + +5.2.1 (1+1 Sparing, Withdrawal of ASP, Backup Override) + + Following on from the example in Section 5.1.2, and 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)-->| + | | | + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 99] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +5.2.3 (n+k Sparing, Loadsharing case, Withdrawal of ASP) + + Following on from the example in Section 5.1.4, and ASP1 withdraws + from service: + + SGP ASP1 ASP2 ASP3 + | | | | + |<----ASP Inact.----| | | + |---ASP Inact Ack-->| | | + | | | | + |--------------------------------NTFY(Ins. ASPs)----------->| + | | | | + |<----------------------------------------ASP Act (Ldshr)---| + |------------------------------------------ASP Act (Ack)--->| + | | | | + + 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 which 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 on + from Section 5.2.1 or 5.2.3, where ASP1 has moved to the "Inactive" + state: + + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 100] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 M3UA/MTP3-User Boundary Examples + +5.4.1 At an ASP + + This section describes the primitive mapping between the MTP3 User + and the M3UA layer at an ASP. + +5.4.1.1 Support for MTP-TRANSFER Primitives at the ASP + +5.4.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); + + + + + +Sidebottom, et. al. Standards Track [Page 101] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + - 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.4.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: + + - 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.4.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. + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 102] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + SGP ASP + | | + |<----------DAUD-----------| + |<----------DAUD-----------| + |<----------DAUD-----------| + | | + | | + +5.4.2 At an SGP + + This section describes the primitive mapping between the MTP3-User + and the M3UA layer at an SGP. + +5.4.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. + + SGP ASP + | | + <---MTP-TRANSFER req.|<---------DATA -----------| + | | + +5.4.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); + + + + +Sidebottom, et. al. Standards Track [Page 103] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + - 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.4.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.4.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 + 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.4.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. + + + + + + + +Sidebottom, et. al. Standards Track [Page 104] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + SGP ASP + | | +--MTP-RESUME ind.-->|-----------DAVA--------->|--MTP-RESUME ind.--> + | | + +5.4.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.4.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 based on the intended + Application Server. + + SGP ASP + | | + --MTP-STATUS ind.-->|----------DUPU---------->|--MTP-STATUS ind.--> + | | + +5.5 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. + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 105] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +5.5.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 are previously agreed to be the same in both + directions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 106] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +5.5.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 as enough since the response by the other peer can be + considered as a notice that it is in ASP_UP state. + + For the same reason, only one ASP Down message is needed since once + that an IPSP receives ASP_Down ack message it is itself considered as + being in the ASP_Down state and not allowed to receive ASPSM + messages. + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 107] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +6. Security Considerations + +6.1 Introduction + + M3UA is designed to carry signalling messages for telephony services. + As such, M3UA must involve the security needs of several parties: the + end users of the services; the network providers and the applications + involved. Additional requirements may come from local regulation. + While having some overlapping security needs, any security solution + should fulfill all of the different parties' needs. + +6.2 Threats + + There is no quick fix, one-size-fits-all solution for security. As a + transport protocol, M3UA has the following security objectives: + + * Availability of reliable and timely user data transport. + * Integrity of user data transport. + * Confidentiality of user data. + + M3UA is recommended to be transported on SCTP. SCTP [17] provides + certain transport related security features, such as some protection + against: + + * Blind Denial of Service Attacks + * Flooding + * Masquerade + * Improper Monopolization of Services + + When M3UA is running in professionally managed corporate or service + provider network, it is reasonable to expect that this network + includes an appropriate security policy framework. The "Site + Security Handbook" [22] should be consulted for guidance. + + When the network in which M3UA runs in involves more than one party, + it may not be reasonable to expect that all parties have implemented + security in a sufficient manner. In such a case, it is recommended + that IPSEC is used to ensure confidentiality of user payload. + Consult [23] for more information on configuring IPSEC services. + +6.3 Protecting Confidentiality + + Particularly for mobile users, the requirement for confidentiality + may include the masking of IP addresses and ports. In this case + application level encryption is not sufficient; IPSEC ESP [24] SHOULD + be used instead. Regardless of which level performs the encryption, + the IPSEC ISAKMP [25] service SHOULD be used for key management. + + + + +Sidebottom, et. al. Standards Track [Page 108] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +7. IANA Considerations + +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 is 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, and + -- 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 (25] + + The proposed extension must in no way adversely affect the general + working of the protocol. + + + + + + + +Sidebottom, et. al. Standards Track [Page 109] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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 which 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. + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 110] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +8. References + +8.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.701 to Q.705, "Signalling System No. 7 + (SS7) - Message Transfer Part (MTP)" + + [8] ANSI T1.111 "Signaling System Number 7 - Message Transfer Part" + + [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", RFC + 2279, January 1998. + +8.2 Informative References + + [11] Ong, L., Rytina, M., Garcia, H., Schwarzbauer, L., Coene, H., + Lin, I., Juhasz, M. and C. Holdrege, "Framework Architecture for + Signaling Transport", RFC 2719, October 1999. + + [12] ITU-T Recommendation Q.720, "Telephone User Part" + + + + + + + +Sidebottom, et. al. Standards Track [Page 111] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + [13] ITU-T Recommendations Q.771 to Q.775 "Signalling System No. 7 + (SS7) - Transaction Capabilities (TCAP)" + + [14] ANSI T1.114 "Signaling System Number 7 - Transaction + Capabilities Application Part" + + [15] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN); + Signalling System No.7; Transaction Capabilities (TC) version 2; + Part 1: Protocol specification" + + [16] 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" + + [17] Stewart, R., Xie, Q., Mornmeault, K., Sharp, H., Taylor, T., + Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control + Transport Protocol", RFC 2960, October 2000. + + [18] ITU-T Recommendation Q.2140 "B-ISDN ATM Adaptation Layer - + Service Specific Coordination Function for signalling at the + Network Node Interface (SSCF at NNI)" + + [19] ITU-T Recommendation Q.2110 "B-ISDN ATM Adaptation Layer - + Service Specific Connection Oriented Protocol (SSCOP)" + + [20] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [21] ITU-T Recommendation Q.2210 "Message Transfer Part Level 3 + functions and messages using the services of ITU Recommendation + Q.2140" + + [22] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September + 1997. + + [23] Ramakrishnan, S., Floyd, S. and D. Black, "Security Architecture + for the Internet Protocol", RFC 3168, November 1998. + + [24] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload + (ESP)", RFC 2406, November 1998. + + [25] Maughan, D., Schertler, M., Schneider, M. and J. Turner, + "Internet Security Association and Key Management Protocol", RFC + 2408, November 1998. + + [26] Narten, T. and H. Alverstrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + + +Sidebottom, et. al. Standards Track [Page 112] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + [27] 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, August 2002. + + [28] George, T., et. al., "SS7 MTP2-User Peer-to-Peer Adaptation + Layer", Work in Progress. + + [29] Telecommunication Technology Committee (TTC) Standard JT-Q704, + "Message Transfer Part Signaling Network Functions", April 28, + 1992. + +9. Acknowledgements + + The authors would like to thank Antonio Roque Alvarez, Joyce + Archibald, Tolga Asveren, Maria-Cruz Bartolome-Rodrigo, Dan Brendes, + Antonio Caete, 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 + 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. + +10. 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 + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 113] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 114] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + One example of a physical network architecture relevant to SS7 + carrier grade operation in the IP network domain is shown in Figure 5 + below: + + 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 5 - 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 hosts + or more, and may have multiple server processes on each host. + + + + + +Sidebottom, et. al. Standards Track [Page 115] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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 + 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. + + + + + + + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 116] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +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: + + 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. + + For example, where Application Servers are defined using ranges of + ISUP CIC values, the Operator is implicitly splitting up control of + the related circuit groups. Some CIC value range assignments may + interfere with ISUP circuit group management procedures. + + 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 + + + + + +Sidebottom, et. al. Standards Track [Page 117] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + + 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. + + 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, 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 to + minimize message missequencing, as required by the SS7 User Parts. + + + +Sidebottom, et. al. Standards Track [Page 118] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +Editors' Addresses + + Greg Sidebottom + Signatus Technologies + Kanata, Ontario, Canada + + EMail: greg@signatustechnologies.com + + + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 119] + +RFC 3332 SS7 MTP3-User Adaptation Layer September 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other + than English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Sidebottom, et. al. Standards Track [Page 120] + |