RFC 4666
Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
Network Working Group K. Morneault, Ed. Request for Comments: 4666 Cisco Systems Obsoletes: 3332 J. Pastor-Balbas, Ed. Category: Standards Track Ericsson September 2006 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).Abstract
This memo defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database, or between two IP- based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. This document obsoletes RFC 3332.
Table of Contents
1. Introduction ....................................................6 1.1. Scope ......................................................6 1.2. Terminology ................................................6 1.3. M3UA Overview ..............................................9 1.3.1. Protocol Architecture ...............................9 1.3.2. Services Provided by the M3UA Layer ................10 1.3.2.1. Support for the Transport of MTP3-User Messages ........................10 1.3.2.2. Native Management Functions ...............11 1.3.2.3. Interworking with MTP3 Network Management Functions ......................11 1.3.2.4. Support for the Management of SCTP Associations between the ..................11 1.3.2.5. Support for the Management of Connections to Multiple SGPs ..............12 1.4. Functional Areas ..........................................12 1.4.1. Signalling Point Code Representation ...............12 1.4.2. Routing Contexts and Routing Keys ..................14 1.4.2.1. Overview ..................................14 1.4.2.2. Routing Key Limitations ...................15 1.4.2.3. Managing Routing Contexts and Routing Keys ..............................15 1.4.2.4. Message Distribution at the SGP ...........15 1.4.2.5. Message Distribution at the ASP ...........16 1.4.3. SS7 and M3UA Interworking ..........................16 1.4.3.1. Signalling Gateway SS7 Layers .............16 1.4.3.2. SS7 and M3UA Interworking at the SG .......17 1.4.3.3. Application Server ........................17 1.4.3.4. IPSP Considerations .......................18 1.4.4. Redundancy Models ..................................18 1.4.4.1. Application Server Redundancy .............18 1.4.5. Flow Control .......................................18 1.4.6. Congestion Management ..............................19 1.4.7. SCTP Stream Mapping ................................19 1.4.8. SCTP Client/Server Model ...........................19 1.5. Sample Configuration ......................................20 1.5.1. Example 1: ISUP Message Transport ..................20 1.5.2. Example 2: SCCP Transport between IPSPs ............21 1.5.3. Example 3: SGP Resident SCCP Layer, with Remote ASP .........................................22 1.6. Definition of M3UA Boundaries .............................23 1.6.1. Definition of the Boundary between M3UA and an MTP3-User .......................................23 1.6.2. Definition of the Boundary between M3UA and SCTP ...23 1.6.3. Definition of the Boundary between M3UA and Layer Management ...................................24
2. Conventions ....................................................27 3. M3UA Protocol Elements .........................................28 3.1. Common Message Header .....................................28 3.1.1. M3UA Protocol Version: 8 bits (unsigned integer) ...28 3.1.2. Message Classes and Types ..........................28 3.1.3. Reserved: 8 Bits ...................................30 3.1.4. Message Length: 32-Bits (Unsigned Integer) .........30 3.2. Variable-Length Parameter Format ..........................30 3.3. Transfer Messages .........................................33 3.3.1. Payload Data Message (DATA) ........................33 3.4. SS7 Signalling Network Management (SSNM) Messages .........36 3.4.1. Destination Unavailable (DUNA) .....................36 3.4.2. Destination Available (DAVA) .......................39 3.4.3. Destination State Audit (DAUD) .....................40 3.4.4. Signalling Congestion (SCON) .......................40 3.4.5. Destination User Part Unavailable (DUPU) ...........43 3.4.6. Destination Restricted (DRST) ......................45 3.5. ASP State Maintenance (ASPSM) Messages ....................45 3.5.1. ASP Up .............................................45 3.5.2. ASP Up Acknowledgement (ASP Up Ack) ................46 3.5.3. ASP Down ...........................................47 3.5.4. ASP Down Acknowledgement (ASP Down Ack) ............48 3.5.5. Heartbeat (BEAT) ...................................48 3.5.6. Heartbeat Acknowledgement (BEAT Ack) ...............49 3.6. Routing Key Management (RKM) Messages [Optional] ..........49 3.6.1. Registration Request (REG REQ) .....................49 3.6.2. Registration Response (REG RSP) ....................54 3.6.3. Deregistration Request (DEREG REQ) .................56 3.6.4. Deregistration Response (DEREG RSP) ................57 3.7. ASP Traffic Maintenance (ASPTM) Messages ..................59 3.7.1. ASP Active .........................................59 3.7.2. ASP Active Acknowledgement (ASP Active Ack) ........60 3.7.3. ASP Inactive .......................................61 3.7.4. ASP Inactive Acknowledgement (ASP Inactive Ack) ....62 3.8. Management (MGMT) Messages ................................63 3.8.1. Error ..............................................63 3.8.2. Notify .............................................67 4. Procedures .....................................................70 4.1. Procedures to Support the M3UA-User .......................70 4.1.1. Receipt of Primitives from the M3UA-User ...........70 4.2. Receipt of Primitives from the Layer Management ...........71 4.2.1. Receipt of M3UA Peer Management Messages ...........72 4.3. AS and ASP/IPSP State Maintenance .........................73 4.3.1. ASP/IPSP States ....................................74 4.3.2. AS States ..........................................76 4.3.3. M3UA Management Procedures for Primitives ..........78 4.3.4. ASPM Procedures for Peer-to-Peer Messages ..........79 4.3.4.1. ASP Up Procedures .........................79
4.3.4.2. ASP-Down Procedures .......................81
4.3.4.3. ASP Active Procedures .....................82
4.3.4.4. ASP Inactive Procedures ...................86
4.3.4.5. Notify Procedures .........................88
4.3.4.6. Heartbeat Procedures ......................89
4.4. Routing Key Management Procedures [Optional] ..............90
4.4.1. Registration .......................................90
4.4.2. Deregistration .....................................92
4.4.3. IPSP Considerations (REG/DEREG) ....................93
4.5. Procedures to Support the Availability or
Congestion Status of SS7 Destination ......................93
4.5.1. At an SGP ..........................................93
4.5.2. At an ASP ..........................................94
4.5.2.1. Single SG Configurations ..................94
4.5.2.2. Multiple SG Configurations ................94
4.5.3. ASP Auditing .......................................94
4.6. MTP3 Restart ..............................................96
4.7. NIF Not Available .........................................97
4.8. M3UA Version Control ......................................97
4.9. M3UA Termination ..........................................97
5. Examples of M3UA Procedures ....................................98
5.1. Establishment of Association and Traffic between
SGPs and ASPs .............................................98
5.1.1. Single ASP in an Application Server ("1+0"
sparing), No Registration ..........................98
5.1.1.1. Single ASP in an Application
Server ("1+0" Sparing), No Registration ...98
5.1.1.2. Single ASP in Application Server
("1+0" Sparing), Dynamic Registration .....99
5.1.1.3. Single ASP in Multiple
Application Servers (Each with "1+0"
Sparing), Dynamic Registration (Case 1
- Multiple Registration Requests) ........100
5.1.1.4. Single ASP in Multiple
Application Servers (each with "1+0"
sparing), Dynamic Registration (Case 2
- Single Registration Request) ...........101
5.1.2. Two ASPs in Application Server ("1+1" Sparing) ....102
5.1.3. Two ASPs in an Application Server ("1+1"
Sparing, Loadsharing Case) ........................103
5.1.4. Three ASPs in an Application Server ("n+k"
Sparing, Loadsharing Case) ........................104
5.2. ASP Traffic Failover Examples ............................105
5.2.1. 1+1 Sparing, Withdrawal of ASP, Backup Override ...105
5.2.2. 1+1 Sparing, Backup Override ......................105
5.2.3. n+k Sparing, Loadsharing Case, Withdrawal of ASP ..106
5.3. Normal Withdrawal of an ASP from an Application Server ...106
5.4. Auditing Examples ........................................107
5.4.1. SG State: Uncongested/Available ...................107
5.4.2. SG State: Congested (Congestion Level=2) /
Available .........................................107
5.4.3. SG State: Unknown/Available .......................107
5.4.4. SG State: Unavailable .............................108
5.5. M3UA/MTP3-User Boundary Examples .........................108
5.5.1. At an ASP .........................................108
5.5.1.1. Support for MTP-TRANSFER
Primitives at the ASP ....................108
5.5.2. At an SGP .........................................109
5.5.2.1. Support for MTP-TRANSFER Request
Primitive at the SGP .....................109
5.5.2.2. Support for MTP-TRANSFER
Indication Primitive at the SGP ..........110
5.5.2.3. Support for MTP-PAUSE,
MTP-RESUME, MTP-STATUS Indication
Primitives ...............................110
5.6. Examples for IPSP Communication ..........................112
5.6.1. Single Exchange ...................................112
5.6.2. Double Exchange ...................................113
6. Security Considerations .......................................113
7. IANA Considerations ...........................................114
7.1. SCTP Payload Protocol Identifier .........................114
7.2. M3UA Port Number .........................................114
7.3. M3UA Protocol Extensions .................................114
7.3.1. IETF-Defined Message Classes ......................115
7.3.2. IETF Defined Message Types ........................115
7.3.3. IETF-Defined Parameter Extension ..................115
8. Acknowledgements ..............................................115
9. Document Contributors .........................................116
10. References ...................................................116
10.1. Normative References ....................................116
10.2. Informative References ..................................117
Appendix A .......................................................119
A.1. Signalling Network Architecture .............................119
A.2. Redundancy Models ...........................................121
A.2.1. Application Server Redundancy ........................121
A.2.2. Signalling Gateway Redundancy ........................122
1. Introduction
This memo defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol [18]. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database [12], or between two IP-based applications.1.1. Scope
There is a need for Switched Circuit Network (SCN) signalling protocol delivery from an SS7 Signalling Gateway (SG) to a Media Gateway Controller (MGC) or IP-resident Database as described in the Framework Architecture for Signalling Transport [12]. The delivery mechanism should meet the following criteria: * Support for the transfer of all SS7 MTP3-User Part messages (e.g., ISUP [1,2,3], SCCP [4,5,6], TUP [13], etc.) * Support for the seamless operation of MTP3-User protocol peers * Support for the management of SCTP transport associations and traffic between an SG and one or more MGCs or IP-resident Databases * Support for MGC or IP-resident database process failover and load sharing * Support for the asynchronous reporting of status changes to management In simplistic transport terms, the SG will terminate SS7 MTP2 and MTP3 protocol layers [7,8,9] and deliver ISUP, SCCP, and/or any other MTP3-User protocol messages, as well as certain MTP network management events, over SCTP transport associations to MTP3-User peers in MGCs or IP-resident databases.1.2. Terminology
Application Server (AS) - A logical entity serving a specific Routing Key. An example of an Application Server is a virtual switch element handling all call processing for a signalling relation, identified by an SS7 DPC/OPC. Another example is a virtual database element, handling all HLR transactions for a particular SS7 SIO/DPC/OPC combination. The AS contains a set of one or more unique Application Server Processes, of which one or more is normally actively processing traffic. Note that there is a 1:1 relationship between an AS and a Routing Key.
Application Server Process (ASP) - A process instance of an Application Server. An Application Server Process serves as an active or backup process of an Application Server (e.g., part of a distributed virtual switch or database). Examples of ASPs are processes (or process instances) of MGCs, IP SCPs, or IP HLRs. An ASP contains an SCTP endpoint and may be configured to process signalling traffic within more than one Application Server. Association - An association refers to an SCTP association. The association provides the transport for the delivery of MTP3-User protocol data units and M3UA adaptation layer peer messages. IP Server Process (IPSP) - A process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses M3UA in a point-to-point fashion. Conceptually, an IPSP does not use the services of a Signalling Gateway node. Failover - The capability to reroute signalling traffic as required to an alternate Application Server Process, or group of ASPs, within an Application Server in the event of failure or unavailability of a currently used Application Server Process. Failover also applies upon the return to service of a previously unavailable Application Server Process. Host - The computing platform that the process (SGP, ASP or IPSP) is running on. Layer Management - Layer Management is a nodal function that handles the inputs and outputs between the M3UA layer and a local management entity. Linkset - A number of signalling links that directly interconnect two signalling points, which are used as a module. MTP - The Message Transfer Part of the SS7 protocol. MTP3 - MTP Level 3, the signalling network layer of SS7. MTP3-User - Any protocol normally using the services of the SS7 MTP3 (e.g., ISUP, SCCP, TUP, etc.). Network Appearance - The Network Appearance is a M3UA local reference shared by SG and AS (typically an integer) that, together with an Signaling Point Code, uniquely identifies an SS7 node by indicating the specific SS7 network to which it belongs. It can be used to distinguish between signalling traffic associated with different networks being sent between the SG and the ASP over a common SCTP association. An example scenario is where an SG appears as an
element in multiple separate national SS7 networks and the same Signaling Point Code value may be reused in different networks. Network Byte Order - Most significant byte first, a.k.a Big Endian. Routing Key - A Routing Key describes a set of SS7 parameters and parameter values that uniquely define the range of signalling traffic to be handled by a particular Application Server. Parameters within the Routing Key cannot extend across more than a single Signalling Point Management Cluster. Routing Context - A value that uniquely identifies a Routing Key. Routing Context values are configured either using a configuration management interface, or by using the routing key management procedures defined in this document. Signaling End Point (SEP) - A node in the SS7 network associated with an originating or terminating local exchange (switch) or a gateway exchange. Signalling Gateway Process (SGP) - A process instance of a Signalling Gateway. It serves as an active, backup, load-sharing, or broadcast process of a Signalling Gateway. Signalling Gateway (SG) - An SG is a signaling agent that receives/sends SCN native signaling at the edge of the IP network [12]. An SG appears to the SS7 network as an SS7 Signalling Point. An SG contains a set of one or more unique Signalling Gateway Processes, of which one or more is normally actively processing traffic. Where an SG contains more than one SGP, the SG is a logical entity, and the contained SGPs are assumed to be coordinated into a single management view to the SS7 network and to the supported Application Servers. Signalling Process - A process instance that uses M3UA to communicate with other signalling processes. An ASP, an SGP, and an IPSP are all signalling processes. Signalling Point Management Cluster (SPMC) - The complete set of Application Servers represented to the SS7 network under a single MTP entity (Signalling Point) in one specific Network Appearance. SPMCs are used to aggregate the availability, congestion, and user part status of an MTP entity (Signalling Point) that is distributed in the IP domain, for the purpose of supporting MTP3 management procedures towards the SS7 network. In some cases, the SG itself may also be a member of the SPMC. In this case, the SG availability/congestion/User_Part status should also be taken into account when considering any supporting MTP3 management actions.
Signaling Transfer Point (STP) - A node in the SS7 network that provides network access and performs message routing, screening and transfer of signaling messages. Stream - An SCTP stream; a unidirectional logical channel established from one SCTP endpoint to another associated SCTP endpoint, within which all user messages are delivered in-sequence except for those submitted to the unordered delivery service.1.3. M3UA Overview
1.3.1. Protocol Architecture
The framework architecture that has been defined for SCN signalling transport over IP [12] uses multiple components, including a common signalling transport protocol and an adaptation module to support the services expected by a particular SCN signalling protocol from its underlying protocol layer. Within the framework architecture, this document defines an MTP3-User adaptation module suitable for supporting the transfer of messages of any protocol layer that is identified to the MTP Level 3 as an MTP User. The list of these protocol layers includes but is not limited to ISDN User Part (ISUP) [1,2,3], Signalling Connection Control Part (SCCP) [4,5,6], and Telephone User Part (TUP) [13]. TCAP [14,15,16] or RANAP [16] messages are transferred transparently by the M3UA protocol as SCCP payload, as they are SCCP-User protocols. It is recommended that M3UA use the services of the Stream Control Transmission Protocol (SCTP) [18] as the underlying reliable common signalling transport protocol. This is to take advantage of various SCTP features, such as: - Explicit packet-oriented delivery (not stream-oriented) - Sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages - Optional multiplexing of user messages into SCTP datagrams - Network-level fault tolerance through support of multi-homing at either or both ends of an association - Resistance to flooding and masquerade attacks - Data segmentation to conform to discovered path MTU size Under certain scenarios, such as back-to-back connections without redundancy requirements, the SCTP functions above might not be a requirement, and TCP MAY be used as the underlying common transport protocol.
1.3.2. Services Provided by the M3UA Layer
The M3UA Layer at an ASP or IPSP provides the equivalent set of primitives at its upper layer to the MTP3-Users as provided by the MTP Level 3 to its local MTP3-Users at an SS7 SEP. In this way, the ISUP and/or SCCP layer at an ASP or IPSP is unaware that the expected MTP3 services are offered remotely from an MTP3 Layer at an SGP, and not by a local MTP3 layer. The MTP3 layer at an SGP may also be unaware that its local users are actually remote user parts over M3UA. In effect, the M3UA extends access to the MTP3 layer services to a remote IP-based application. The M3UA layer does not itself provide the MTP3 services. However, in the case where an ASP is connected to more than one SG, the M3UA layer at an ASP should maintain the status of configured SS7 destinations and route messages according to the availability and congestion status of the routes to these destinations via each SG. The M3UA layer may also be used for point-to-point signalling between two IP Server Processes (IPSPs). In this case, the M3UA layer provides the same set of primitives and services at its upper layer as the MTP3. However, in this case the expected MTP3 services are not offered remotely from an SGP. The MTP3 services are provided, but the procedures to support these services are a subset of the MTP3 procedures, due to the simplified point-to-point nature of the IPSP- to-IPSP relationship.1.3.2.1. Support for the Transport of MTP3-User Messages
The M3UA layer provides the transport of MTP-TRANSFER primitives across an established SCTP association between an SGP and an ASP or between IPSPs. At an ASP, in the case where a destination is reachable via multiple SGPs, the M3UA layer must also choose via which SGP the message is to be routed or support load balancing across the SGPs, thereby minimizing missequencing. The M3UA layer does not impose a 272-octet signalling information field (SIF) length limit as specified by the SS7 MTP Level 2 protocol [7,8,9]. Larger information blocks can be accommodated directly by M3UA/SCTP, without the need for an upper layer segmentation/ re-assembly procedure as specified in recent SCCP or ISUP versions. However, in the context of an SG, the maximum 272-octet block size must be followed when interworking to a SS7 network that does not support the transfer of larger information blocks to the final destination. This avoids potential ISUP or SCCP fragmentation requirements at the SGPs. The provisioning and configuration of the SS7 network determines the restriction placed on the maximum block
size. Some configurations (e.g., Broadband MTP [19,20,22]) may permit larger block sizes.1.3.2.2. Native Management Functions
The M3UA layer provides the capability to indicate errors associated with received M3UA messages and to notify, as appropriate, local management and/or the peer M3UA.1.3.2.3. Interworking with MTP3 Network Management Functions
At the SGP, the M3UA layer provides interworking with MTP3 management functions to support seamless operation of the user SCN signalling applications in the SS7 and IP domains. This includes - providing an indication to MTP3-Users at an ASP that a destination in the SS7 network is not reachable; - providing an indication to MTP3-Users at an ASP that a destination in the SS7 network is now reachable; - providing an indication to MTP3-Users at an ASP that messages to a destination in the SS7 network are experiencing SS7 congestion; - providing an indication to the M3UA layer at an ASP that the routes to a destination in the SS7 network are restricted; and - providing an indication to MTP3-Users at an ASP that a MTP3-User peer is unavailable. The M3UA layer at an ASP keeps the state of the routes to remote SS7 destinations and may initiate an audit of the availability and the restricted or the congested state of remote SS7 destinations. This information is requested from the M3UA layer at the SGP. The M3UA layer at an ASP may also indicate to the SG that the M3UA layer itself or the ASP or the ASP's Host is congested.1.3.2.4. Support for the Management of SCTP Associations between the SGP and ASPs
The M3UA layer at the SGP maintains the availability state of all configured remote ASPs, to manage the SCTP Associations and the traffic between the M3UA peers. Also, the active/inactive and congestion state of remote ASPs is maintained. The M3UA layer MAY be instructed by local management to establish an SCTP association to a peer M3UA node. This can be achieved using the
M-SCTP_ESTABLISH primitives (see Section 1.6.3 for a description of management primitives) to request, indicate, and confirm the establishment of an SCTP association with a peer M3UA node. In order to avoid redundant SCTP associations between two M3UA peers, one side (client) SHOULD be designated to establish the SCTP association, or M3UA configuration information maintained to detect redundant associations (e.g., via knowledge of the expected local and remote SCTP endpoint addresses). Local management MAY request from the M3UA layer the status of the underlying SCTP associations using the M-SCTP_STATUS request and confirm primitives. Also, the M3UA MAY autonomously inform local management of the reason for the release of an SCTP association, determined either locally within the M3UA layer or by a primitive from the SCTP. Also, the M3UA layer MAY inform the local management of the change in status of an ASP or AS. This MAY be achieved using the M-ASP_STATUS request or M-AS_STATUS request primitives.1.3.2.5. Support for the Management of Connections to Multiple SGPs
As shown in Figure 1, an ASP may be connected to multiple SGPs. In such a case, a particular SS7 destination may be reachable via more than one SGP and/or SG; i.e., via more than one route. As MTP3 users only maintain status on a destination and not on a route basis, the M3UA layer must maintain the status (availability, restriction, and/or congestion of route to destination) of the individual routes, derive the overall availability or congestion status of the destination from the status of the individual routes, and inform the MTP3 users of this derived status whenever it changes.
(page 12 continued on part 2)
