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