RFC 3331
Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer
Network Working Group K. Morneault Request for Comments: 3331 Cisco Systems Category: Standards Track R. Dantu NetRake G. Sidebottom Signatus Technologies B. Bidulock OpenSS7 J. Heitz Lucent September 2002 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.Abstract
This document defines a protocol for the backhauling of Signaling System 7 Message Transfer Part 2 (SS7 MTP2) User signalling messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signalling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. The Signalling Gateway would act as a Signalling Link Terminal.
Table of Contents
1. Introduction.............................................. 2 1.1 Scope.................................................. 3 1.2 Terminology............................................ 3 1.3 M2UA Overview.......................................... 5 1.4 Services Provided by the M2UA Adaptation Layer......... 7 1.5 Functions Provided by the M2UA Layer................... 9 1.6 Definition of the M2UA Boundaries..................... 12 2. Conventions.............................................. 16 3. Protocol Elements........................................ 16 3.1 Common Message Header................................. 16 3.2 M2UA Message Header................................... 22 3.3 M2UA Messages......................................... 23 4. Procedures............................................... 58 4.1 Procedures to Support the M2UA-User Layer............. 58 4.2 Receipt of Primitives from the Layer Management....... 59 4.3 AS and ASP State Maintenance.......................... 61 4.4 Link Key Management Procedures........................ 73 5. Examples of MTP2 User Adaptation (M2UA) Procedures....... 75 5.1 Establishment of associations between SGP and MGC examples.............................................. 75 5.2 ASP Traffic Fail-over Examples........................ 77 5.3 SGP to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures............................................ 78 6. Timer Values............................................. 85 7. Security Considerations.................................. 85 7.1 Threats................................................ 85 7.2 Protecting Confidentiality............................. 86 8. IANA Considerations...................................... 86 8.1 SCTP Payload Protocol Identifier....................... 86 8.2 M2UA Protocol Extensions............................... 86 9. Acknowledgements......................................... 87 10. References............................................... 88 Appendix A: Signalling Network Architecture.................. 90 11. Authors' Addresses....................................... 92 Full Copyright Statement..................................... 941. Introduction
This document defines a protocol for the backhauling of SS7 [1] MTP2 User [2] [3] [4] (i.e. MTP3) signalling messages over IP using the Stream Control Transmission Protocol (SCTP) [8]. This protocol would be used between a Signalling Gateway (SG) and Media Gateway Controller (MGC).
1.1 Scope
There is a need for Switched Circuit Network (SCN) signalling protocol delivery from a Signalling Gateway (SG) to a Media Gateway Controller (MGC) [9]. The delivery mechanism addresses the following objectives: * Support for MTP Level 2 / MTP Level 3 interface boundary * Support for communication between Layer Management modules on SG and MGC * Support for management of SCTP active associations between the SG and MGC The SG will terminate up to MTP Level 2 and the MGC will terminate MTP Level 3 and above. In other words, the SG will transport MTP Level 3 messages over an IP network to a MGC.1.2 Terminology
Application Server (AS) - A logical entity serving a specific application instance. An example of an Application Server is a MGC handling the MTP Level 3 and call processing for SS7 links terminated by the Signalling Gateways. Practically speaking, an AS is modeled at the SG as an ordered list of one or more related Application Server Processes (e.g., primary, secondary, tertiary, ...). Application Server Process (ASP) - A process instance of an Application Server. Examples of Application Server Processes are active or standby MGC instances. Association - An association refers to a SCTP association. The association will provide the transport for the delivery of protocol data units for one or more interfaces. Backhaul - Refers to the transport of signalling from the point of interface for the associated data stream (i.e., SG function in the MGU) back to the point of call processing (i.e., the MGCU), if this is not local [9]. Fail-over - The capability to reroute signalling traffic as required to an alternate Application Server Process within an Application Server in the event of failure or unavailability of a currently used Application Server Process. Fail-back MAY apply upon the return to service of a previously unavailable Application Server Process. Host - The computing platform that the ASP process is running on.
Interface - For the purposes of this document, an interface is a SS7 signalling link. Interface Identifier - The Interface Identifier identifies the physical interface at the SG for which the signalling messages are sent/received. The format of the Interface Identifier parameter can be text or integer, the values of which are assigned according to network operator policy. The values used are of local significance only, coordinated between the SG and ASP. Layer Management - Layer Management is a nodal function in an SG or ASP that handles the inputs and outputs between the M2UA layer and a local management entity. Link Key - The link key is a locally unique (between ASP and SG) value that identifies a registration request for a particular Signalling Data Link and Signalling Terminal pair. MTP - The Message Transfer Part of the SS7 protocol MTP2 - MTP Level 2, the signalling data link layer of SS7 MTP3 - MTP Level 3, the signalling network layer of SS7 MTP2-User - A protocol that uses the services of MTP Level 2 (i.e. MTP3). Network Byte Order: Most significant byte first, a.k.a Big Endian. Signalling Data Link - An SDL refers to a specific communications facility that connects two Signalling Link Terminals. Signalling Gateway (SG) - An SG is a signalling agent at the edge of the IP network. An SG appears to the SS7 as one or more Signalling Link Terminals that are connected to one or more Signalling Data Links in the SS7 network. An SG contains a set of one or more unique Signalling Gateway Processes, on which one or more is normally actively processing traffic. Where an SG contains more than one SGP, the SG is a logical entity. Signalling Gateway Process (SGP) - A process instance that uses M2UA to communicate to and from a Signalling Link Terminal. It serves as an active, backup or load-sharing process of a Signalling Gateway. Signalling Link Terminal (SLT) - Refers to the means of performing all of the functions defined at MTP level 2 regardless of their implementation [2,3].
Stream - A stream refers to an SCTP stream; a unidirectional logical channel established from one SCTP endpoint to another associated SCTP endpoint, within which all user messages are delivered in-sequence except for those submitted to the unordered delivery service.1.3 M2UA Overview
The framework architecture that has been defined for SCN signalling transport over IP [9] uses two components: a signalling common transport protocol and an adaptation module to support the services expected by a particular SCN signalling protocol from its underlying protocol layer. Within this framework architecture, this document defines a SCN adaptation module that is suitable for the transport of SS7 MTP2 User messages. The only SS7 MTP2 User is MTP3. The M2UA uses the services of the Stream Control Transmission Protocol [8] as the underlying reliable signalling common transport protocol. In a Signalling Gateway, it is expected that the SS7 MTP2-User signalling is transmitted and received from the PSTN over a standard SS7 network interface, using the SS7 Message Transfer Part Level 1 and Level 2 [2,3,4] to provide reliable transport of the MTP3-User signalling messages to and from an SS7 Signalling End Point (SEP) or Signalling Transfer Point (STP). The SG then provides an interworking of transport functions with the IP transport, in order to transfer the MTP2-User signalling messages to and from an Application Server Process where the peer MTP2-User protocol layer exists.
1.3.1 Example - SG to MGC
In a Signalling Gateway, it is expected that the SS7 signalling is received over a standard SS7 network termination, using the SS7 Message Transfer Part (MTP) to provide transport of SS7 signalling messages to and from an SS7 Signalling End Point (SEP) or SS7 Signalling Transfer Point (STP). In other words, the SG acts as a Signalling Link Terminal (SLT) [2,3]. The SG then provides an interworking of transport functions with IP Signalling Transport, in order to transport the MTP3 signalling messages to the MGC where the peer MTP3 protocol layer exists, as shown below: ****** SS7 ****** IP ******* *SEP *-----------* SG *-------------* MGC * ****** ****** ******* +----+ +----+ |S7UP| |S7UP| +----+ +----+ |MTP + |MTP | | L3 | (NIF) |L3 | +----+ +----+----+ +----+ |MTP | |MTP |M2UA| |M2UA| | | | +----+ +----+ |L2 | |L2 |SCTP| |SCTP| |L1 | |L1 +----+ +----+ | | | |IP | |IP | +----+ +---------+ +----+ NIF - Nodal Interworking Function SEP - SS7 Signalling Endpoint IP - Internet Protocol SCTP - Stream Control Transmission Protocol (Reference [8]) Figure 1 M2UA in the SG to MGC Application Note: STPs MAY be present in the SS7 path between the SEP and the SG. It is recommended that the M2UA use the services of the Stream Control Transmission Protocol (SCTP) [8] as the underlying reliable common signalling transport protocol. The use of SCTP provides the following features: - 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 the support of multi-homing
at either or both ends of an association,
- resistance to flooding and masquerade attacks, and
- data segmentation to conform to discovered path MTU size
There are scenarios without redundancy requirements and scenarios in
which redundancy is supported below the transport layer. In these
cases, the SCTP functions above MAY NOT be a requirement and TCP can
be used as the underlying common transport protocol.
1.3.2 ASP Fail-over Model and Terminology
The M2UA layer supports ASP fail-over functions in order to support a
high availability of call and transaction processing capability. All
MTP2-User messages incoming to a SGP from the SS7 network are
assigned to the unique Application Server, based on the Interface
Identifier of the message.
The M2UA layer supports a n+k redundancy model (active-standby, load
sharing, broadcast) where n 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. Note that 1+1 active/standby redundancy
is a subset of this model. A simplex 1+0 model is also supported as
a subset, with no ASP redundancy.
1.3.3 Client/Server Model
It is recommended that the SGP and ASP be able to support both client
and server operation. The peer endpoints using M2UA SHOULD be
configured so that one always takes on the role of client and the
other the role of server for initiating SCTP associations. The
default orientation would be for the SGP to take on the role of
server while the ASP is the client. In this case, ASPs SHOULD
initiate the SCTP association to the SGP.
The SCTP and TCP Registered User Port Number Assignment for M2UA is
2904.
1.4 Services Provided by the M2UA Adaptation Layer
The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination
point in the IP network, so that the M2UA protocol layer is required
to provide the equivalent set of services to its users as provided by
the MTP Level 2 to MTP Level 3.
1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary
M2UA supports a MTP Level 2 / MTP Level 3 interface boundary that enables a seamless, or as seamless as possible, operation of the MTP2-User peers in the SS7 and IP domains. An example of the primitives that need to be supported can be found in [10].1.4.2 Support for communication between Layer Management modules on SG and MGC
The M2UA layer needs to provide some messages that will facilitate communication between Layer Management modules on the SG and MGC. To facilitate reporting of errors that arise because of the backhauling MTP Level 3 scenario, the following primitive is defined: M-ERROR The M-ERROR message is used to indicate an error with a received M2UA message (e.g., an interface identifier value is not known to the SG).1.4.3 Support for management of active associations between SG and MGC
The M2UA layer on the SG keeps the state of the configured ASPs. A set of primitives between M2UA layer and the Layer Management are defined below to help the Layer Management manage the association(s) between the SG and the MGC. The M2UA layer can be instructed by the Layer Management to establish a SCTP association to a peer M2UA node. This procedure can be achieved using the M-SCTP ESTABLISH primitive. M-SCTP_ESTABLISH The M-SCTP_ESTABLISH primitive is used to request, indicate and confirm the establishment of a SCTP association to a peer M2UA node. M-SCTP_RELEASE The M-SCTP_RELEASE primitives are used to request, indicate, and confirm the release of a SCTP association to a peer M2UA node. The M2UA layer MAY also need to inform the status of the SCTP association(s) to the Layer Management. This can be achieved using the following primitive. M-SCTP_STATUS The M-SCTP_STATUS primitive is used to request and indicate the status of underlying SCTP association(s).
The Layer Management MAY need to inform the M2UA layer of an AS/ASP status (i.e., failure, active, etc.), so that messages can be exchanged between M2UA layer peers to stop traffic to the local M2UA user. This can be achieved using the following primitive. M-ASP_STATUS The ASP status is stored inside the M2UA layer on both the SG and MGC sides. The M-ASP_STATUS primitive can be used by Layer Management to request the status of the Application Server Process from the M2UA layer. This primitive can also be used to indicate the status of the Application Server Process. M-ASP_MODIFY The M-ASP_MODIFY primitive can be used by Layer Management to modify the status of the Application Server Process. In other words, the Layer Management on the ASP side uses this primitive to initiate the ASPM procedures. M-AS_STATUS The M-AS_STATUS primitive can be used by Layer Management to request the status of the Application Server. This primitive can also be used to indicate the status of the Application Server.1.5 Functions Provided by the M2UA Layer
1.5.1 Mapping
The M2UA layer MUST maintain a map of an Interface ID to a physical interface on the Signalling Gateway. A physical interface would be a V.35 line, T1 line/time slot, E1 line/time slot, etc. The M2UA layer MUST also maintain a map of the Interface Identifier to SCTP association and to the related stream within the association. The SGP maps an Interface Identifier to an SCTP association/stream only when an ASP sends an ASP Active message for a particular Interface Identifier. It must be noted, however, that this mapping is dynamic and could change at any time due to a change of ASP state. This mapping could even temporarily be invalid, for example during fail-over of one ASP to another. Therefore, the SGP MUST maintain the states of AS/ASP and reference them during the routing of any messages to an AS/ASP. Note that only one SGP SHOULD provide Signalling Link Terminal services to an SS7 link. Therefore, within an SG, an Application Server SHOULD be active for only one SGP at any given point in time.
An example of the logical view of the relationship between an SS7
link, Interface Identifier, AS and ASP in an SGP is shown below:
/-------------------------------------------------+
/ /----------------------------------------------|--+
/ / v |
/ / +----+ act+-----+ +-------+ -+--+|-+-
SS7 link1-------->|IID |-+ +-->| ASP |-->| Assoc | v
/ +----+ | +----+ | +-----+ +-------+ -+--+--+-
/ +->| AS |--+ Streams
/ +----+ | +----+ stb+-----+
SS7 link2-------->|IID |-+ | ASP |
+----+ +-----+
where IID = Interface Identifier
A SGP MAY support more than one AS. An AS MAY support more than one
Interface Identifier.
1.5.2 Support for the management of SCTP associations between the SGPs
and ASPs
The M2UA layer at the SG maintains the availability state of all
configured ASPs, in order to manage the SCTP associations and the
traffic between the SG and ASPs. As well, the active/inactive state
of remote ASP(s) are also maintained. The Active ASP(s) are the
one(s) currently receiving traffic from the SG.
The M2UA layer MAY be instructed by local management to establish an
SCTP association to a peer M2UA node. This can be achieved using the
M-SCTP_ESTABLISH primitive to request, indicate and confirm the
establishment of an SCTP association with a peer M2UA node.
The M2UA layer MAY also need to inform local management of the status
of the underlying SCTP associations using the M-SCTP_STATUS request
and the indication primitive. For example, the M2UA MAY inform local
management of the reason for the release of an SCTP association,
determined either locally within the M2UA layer or by a primitive
from the SCTP.
Also the M2UA layer may need to 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.5.3 Status of ASPs
The M2UA layer on the SG MUST maintain the state of the ASPs it is supporting. The state of an ASP changes because of the reception of peer-to-peer messages (ASPM messages as described in Section 3.3.2) or the reception of indications from the local SCTP association. The ASP state transition procedures are described in Section 4.3.1. At a SGP, an Application Server list MAY contain active and inactive ASPs to support ASP fail-over procedures. When, for example, both a primary and a backup ASP are available, the M2UA peer protocol is required to control which ASP is currently active. The ordered list of ASPs within a logical Application Server is kept updated in the SGP to reflect the active Application Server Process. Also the M2UA layer MAY need to inform the local management of the change in status of an ASP or AS. This can be achieved using the M- ASP_STATUS or M-AS_STATUS primitives.1.5.4 SCTP Specifics
1.5.4.1 SCTP Stream Management
SCTP allows a user specified number of streams to be opened during initialization of the association. It is the responsibility of the M2UA layer to ensure proper management of these streams. Because of the unidirectional nature of streams, a M2UA layer is not aware of the stream information from its peer M2UA layer. For this reason, the Interface Identifier is in the M2UA message header. The use of SCTP streams within M2UA is recommended in order to minimize transmission and buffering delay, thereby, improving the overall performance and reliability of the signalling elements. A separate SCTP stream can be used for each SS7 link. Or, an implementation may choose to split the SS7 link across several streams based on SLS. This method may be of particular interest for high speed SS7 links (MTP3b) since high speed links have a 24-bit sequence number and the stream sequence number is 16-bits. SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP) messages (see Section 3) since stream '0' SHOULD only be used for ASP Management (ASPM) messages (see Section 4.3.3).
1.5.5 Seamless SS7 Network Management Interworking
The M2UA layer on the SGP SHOULD pass an indication of unavailability of the M2UA-User (MTP3) to the local Layer Management, if the currently active ASP moves from the ACTIVE state. The actions taken by M2UA on the SGP with regards to MTP Level 2 should be in accordance with the appropriate MTP specifications.1.5.6 Flow Control / Congestion
It is possible for the M2UA layer to be informed of the IP network congestion onset and abatement by means of an implementation dependent function (i.e. an indication from the SCTP). The handling of this congestion indication by M2UA is implementation dependent. However, the actions taken by the SG should be in accordance with the appropriate MTP specification and should enable SS7 functionality (e.g. flow control) to be correctly maintained.1.5.7 Audit of SS7 Link State
After a fail-over of one ASP to another ASP, it may be necessary for the M2UA on the ASP to audit the current SS7 link state to ensure consistency. The M2UA on the SGP would respond to the audit request with information regarding the current state of the SS7 link (i.e. in-service, out-of-service, congestion state, LPO/RPO state).1.6 Definition of the M2UA Boundaries
1.6.1 Definition of the M2UA / MTP Level 3 boundary
DATA ESTABLISH RELEASE STATE DATA RETRIEVAL DATA RETRIEVAL COMPLETE1.6.2 Definition of the M2UA / MTP Level 2 boundary
DATA ESTABLISH RELEASE STATE DATA RETRIEVAL DATA RETRIEVAL COMPLETE
1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP
The upper layer and layer management primitives provided by SCTP are provided in Reference [8] Section 10.1.6.4 Definition of Layer Management / M2UA Boundary
M-SCTP_ESTABLISH request Direction: LM -> M2UA Purpose: LM requests ASP to establish an SCTP association with an SGP. M-SCTP_ESTABLISH confirm Direction: M2UA -> LM Purpose: ASP confirms to LM that it has established an SCTP association with an SGP. M-SCTP_ESTABLISH indication Direction: M2UA -> LM Purpose: SGP informs LM that an ASP has established an SCTP association. M-SCTP_RELEASE request Direction: LM -> M2UA Purpose: LM requests ASP to release an SCTP association with SGP. M-SCTP_RELEASE confirm Direction: M2UA -> LM Purpose: ASP confirms to LM that it has released SCTP association with SGP. M-SCTP_RELEASE indication Direction: M2UA -> LM Purpose: SGP informs LM that ASP has released an SCTP association. M-SCTP_RESTART indication Direction: M2UA -> LM Purpose: M2UA informs LM that a SCTP Restart indication has been received. M-SCTP_STATUS request Direction: LM -> M2UA Purpose: LM requests M2UA to report status of SCTP association. M-SCTP_STATUS indication Direction: M2UA -> LM Purpose: M2UA reports status of SCTP association.
M-ASP_STATUS request
Direction: LM -> M2UA
Purpose: LM requests SGP to report status of remote ASP.
M-ASP_STATUS indication
Direction: M2UA -> LM
Purpose: SGP reports status of remote ASP.
M-AS_STATUS request
Direction: LM -> M2UA
Purpose: LM requests SG to report status of AS.
M-AS_STATUS indication
Direction: M2UA -> LM
Purpose: SG reports status of AS.
M-NOTIFY indication
Direction: M2UA -> LM
Purpose: ASP reports that it has received a NOTIFY message
from its peer.
M-ERROR indication
Direction: M2UA -> LM
Purpose: ASP or SGP reports that it has received an ERROR
message from its peer.
M-ASP_UP request
Direction: LM -> M2UA
Purpose: LM requests ASP to start its operation and send an ASP UP
message to the SGP.
M-ASP_UP confirm
Direction: M2UA -> LM
Purpose: ASP reports that it has received an ASP UP Acknowledgment
message from the SGP.
M-ASP_DOWN request
Direction: LM -> M2UA
Purpose: LM requests ASP to stop its operation and send an ASP DOWN
message to the SGP.
M-ASP_DOWN confirm
Direction: M2UA -> LM
Purpose: ASP reports that is has received an ASP DOWN Acknowledgment
message from the SGP.
M-ASP_ACTIVE request
Direction: LM -> M2UA
Purpose: LM requests ASP to send an ASP ACTIVE message to the SGP.
M-ASP_ACTIVE confirm
Direction: M2UA -> LM
Purpose: ASP reports that is has received an ASP ACTIVE
Acknowledgment message from the SGP.
M-ASP_INACTIVE request
Direction: LM -> M2UA
Purpose: LM requests ASP to send an ASP INACTIVE message to the SGP.
M-ASP_INACTIVE confirm
Direction: M2UA -> LM
Purpose: ASP reports that is has received an ASP INACTIVE
Acknowledgment message from the SGP.
M-LINK_KEY_REG Request
Direction: LM -> M2UA
Purpose: LM requests ASP to register Link Key with SG by sending REG
REQ message.
M-LINK_KEY_REG Confirm
Direction: M2UA -> LM
Purpose: ASP reports to LM that it has successfully received a REG
RSP message from SG.
M-LINK_KEY_REG Indication
Direction: M2UA -> LM
Purpose: SG reports to LM that it has successfully processed an
incoming REG REQ message from ASP.
M-LINK_KEY_DEREG Request
Direction: LM -> M2UA
Purpose: LM requests ASP to de-register Link Key with SG by sending
DEREG REQ message.
M-LINK_KEY_DEREG Confirm
Direction: M2UA -> LM
Purpose: ASP reports to LM that it has successfully received a
DEREG RSP message from SG.
M-LINK_KEY_DEREG Indication
Direction: M2UA -> LM
Purpose: SG reports to LM that it has successfully processed an
incoming DEREG REQ message from ASP.
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
(page 16 continued on part 2)
