RFC 3331
Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer
RFC 3331 🎀 (Part 1 of 19)
okay bestie, RFC 3331 is a Standards Track doc from September 2002 💖 It's about carrying SS7 MTP2-User signalling over IP using SCTP, and it's giving serious infrastructure energy 🦋 The authors are K. Morneault (Cisco Systems), R. Dantu (NetRake), G. Sidebottom (Signatus Technologies), B. Bidulock (OpenSS7), and J. Heitz (Lucent). The title block doesn't list anything it obsoletes or updates, so no drama there ✨
Status of this Memo 📜
so this is an Internet standards track protocol for the whole Internet community, and they're literally asking for discussion and suggestions for improvements 🫶 For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Copyright Notice ©️
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract ✨
okay so the main vibe here is backhauling Signaling System 7 Message Transfer Part 2 (SS7 MTP2) User signalling messages over IP, using the Stream Control Transmission Protocol (SCTP) 🦋 This protocol is meant to run between a Signalling Gateway (SG) and a Media Gateway Controller (MGC). The SG gets SS7 signalling over a standard SS7 interface that uses the SS7 Message Transfer Part (MTP) for transport, and the Signalling Gateway acts as a Signalling Link Terminal. iconic. 💅
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..... 75
examples
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
Authors' Addresses........................................... 92
Full Copyright Statement..................................... 941. Introduction ✨
okay here's the deal: this document defines a protocol for backhauling SS7 [1] MTP2 User [2] [3] [4] (i.e. MTP3) signalling messages over IP, using the Stream Control Transmission Protocol (SCTP) [8] 🌸 It's used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC). main character energy, honestly 👑
1.1 Scope 🎯
there's a real need for Switched Circuit Network (SCN) signalling protocol delivery from a Signalling Gateway (SG) to a Media Gateway Controller (MGC) [9] 💅 The delivery mechanism is going for these 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
so the SG terminates up to MTP Level 2, and the MGC terminates MTP Level 3 and above. In other words, the SG transports MTP Level 3 messages over an IP network to an MGC 🦋
1.2 Terminology 📖
okay, let's define our vocab, bestie 🧚
Application Server (AS) - A logical entity serving a specific application instance. An example of an Application Server is an 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 an 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, and the values 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 defined for SCN signalling transport over IP [9] has two components: a signalling common transport protocol, and an adaptation module that supports the services a particular SCN signalling protocol expects from its underlying protocol layer 💖
inside that framework, this document defines an SCN adaptation module that's suitable for transporting SS7 MTP2 User messages. The only SS7 MTP2 User is MTP3 🙈 The M2UA uses the services of the Stream Control Transmission Protocol [8] as its underlying reliable signalling common transport protocol.
in a Signalling Gateway, SS7 MTP2-User signalling is sent and received from the PSTN over a standard SS7 network interface. It uses the SS7 Message Transfer Part Level 1 and Level 2 [2,3,4] to provide reliable transport of MTP3-User signalling messages to and from an SS7 Signalling End Point (SEP) or Signalling Transfer Point (STP). The SG then interworks transport functions with IP transport, so it can move MTP2-User signalling messages to and from an Application Server Process where the peer MTP2-User protocol layer lives 🫶
1.3.1 Example - SG to MGC ✨
Okay so picture a Signalling Gateway (SG) 💅. On the SS7 side, the signalling comes in over a standard SS7 network termination, and the SG uses the SS7 Message Transfer Part (MTP) to carry SS7 signalling messages to and from a SS7 Signalling End Point (SEP) or a SS7 Signalling Transfer Point (STP). Basically, the SG is acting as a Signalling Link Terminal (SLT) [2,3] 🦋. Then it does the interworking thing, bridging transport functions with IP Signalling Transport, so the MTP3 signalling messages can get to the MGC, where the peer MTP3 protocol layer lives 🧚. Here's the whole vibe:
****** 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 ApplicationNote: STPs MAY be present in the SS7 path between the SEP and the SG. 👀
Now, it's recommended that M2UA use the Stream Control Transmission Protocol (SCTP) [8] as its underlying reliable common signalling transport protocol 🫶. SCTP is giving a whole buffet of 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
Not every setup needs all that, though 🙈. Some scenarios don't have redundancy requirements, and some have redundancy handled below the transport layer. In those 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
Main character energy: the M2UA layer supports ASP fail-over so call and transaction processing stays highly available 👑. Every MTP2-User message coming into an SGP from the SS7 network gets assigned to the unique Application Server, based on the message's Interface Identifier 🎀.
The M2UA layer supports an n+k redundancy model (active-standby, load sharing, broadcast). Here, n is the minimum number of redundant ASPs needed to handle traffic, and k ASPs are standing by to take over for a failed or unavailable ASP 🔥. Fun fact: 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's recommended that the SGP and ASP can support both client and server operation 🌈. The peer endpoints using M2UA SHOULD be configured so one always takes the client role and the other takes the server role when initiating SCTP associations. The default orientation is for the SGP to be the server and the ASP to be the client. In that setup, 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 stays intact at the termination point in the IP network 🦋. So the M2UA protocol layer is required to provide its users with the equivalent set of services that MTP Level 2 provides to MTP Level 3. Iconic consistency 💅.
1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary
M2UA supports an MTP Level 2 / MTP Level 3 interface boundary that keeps things seamless, or as seamless as possible, for the MTP2-User peers in both the SS7 and IP domains 🧚. You can find an example of the primitives that need to be supported in [10] 📚.
1.4.2 Support for communication between Layer Management modules on SG and MGC
The M2UA layer needs to provide some messages so the Layer Management modules on the SG and MGC can talk to each other 💬. To report errors caused by the backhauling MTP Level 3 scenario, this primitive is defined:
M-ERROR
The M-ERROR message is used to indicate an error with a received M2UA message (for example, an interface identifier value that the SG doesn't know) 🙈.
1.4.3 Support for management of active associations between SG and MGC
The M2UA layer on the SG keeps track of the state of the configured ASPs 👀. A set of primitives between the M2UA layer and Layer Management helps Layer Management manage the association(s) between the SG and the MGC 🫶. The M2UA layer can be told by Layer Management to establish an SCTP association to a peer M2UA node, and that's done with the M-SCTP ESTABLISH primitive 🦋.
M-SCTP_ESTABLISH
The M-SCTP_ESTABLISH primitive is used to request, indicate and confirm the establishment of an 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 an SCTP association to a peer M2UA node 🌸.
The M2UA layer MAY also need to inform Layer Management about the status of the SCTP association(s). This can be done with the following primitive 🎀.
M-SCTP_STATUS
The M-SCTP_STATUS primitive is used to request and indicate the status of the underlying SCTP association(s) ✨.
Layer Management MAY need to tell the M2UA layer about an AS/ASP status (like failure, active, etc.), so messages can be exchanged between M2UA layer peers to stop traffic to the local M2UA user 🛑. This can be done with 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, and it can also be used to indicate that status 🔥.
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, Layer Management on the ASP side uses this primitive to kick off 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, and it can also be used to indicate that status 💜.
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 could be a V.35 line, a T1 line/time slot, an E1 line/time slot, etc. 🌈. The M2UA layer MUST also maintain a map of the Interface Identifier to the SCTP association and to the related stream within that association 💖.
The SGP maps an Interface Identifier to an SCTP association/stream only when an ASP sends an ASP Active message for that particular Interface Identifier 🎀. But heads up, this mapping is dynamic and can change at any time because of a change in ASP state 😭. It could even be temporarily invalid, like during fail-over from one ASP to another 💀. That's why the SGP MUST maintain the states of AS/ASP and reference them whenever it routes any message to an AS/ASP 🫶.
Note that only one SGP SHOULD provide Signalling Link Terminal services to an SS7 link ✨. So, within an SG, an Application Server SHOULD be active for only one SGP at any given point in time 👑.
Here's the logical view of how an SS7 link, Interface Identifier, AS and ASP relate inside an SGP 🦋:
/-------------------------------------------------+
/ /----------------------------------------------|--+
/ / 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 🌸. And 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 keeps track of the availability state of all configured ASPs 🔍. This helps it manage the SCTP associations and the traffic between the SG and the ASPs 🫶. It also maintains the active/inactive state of remote ASP(s). 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 🎀. That can be done with the M-SCTP_ESTABLISH primitive, which is used 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 about 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 an SCTP association was released, whether that was decided locally within the M2UA layer or by a primitive from the SCTP 😳.
Also, the M2UA layer may need to inform local management about a change in status of an ASP or AS 🦋. This may be done with the M-ASP STATUS request or the 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 👑. An ASP's state changes because of peer-to-peer messages (ASPM messages, as described in Section 3.3.2) or because of indications from the local SCTP association 🔥. The ASP state transition procedures are described in Section 4.3.1 📖.
At an 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 so it reflects the active Application Server Process 💜.
Also, the M2UA layer MAY need to inform local management about a change in status of an ASP or AS 🫶. This can be done with the M-ASP_STATUS or M-AS_STATUS primitives 💖.
1.5.4 SCTP Specifics
1.5.4.1 SCTP Stream Management ✨
okay so SCTP lets you open a number of streams you pick when the association gets set up 🌸. Managing those streams is the M2UA layer's job 💅. Streams only go one way, so an M2UA layer has no idea what stream info its peer is working with 🙈. That's exactly why the Interface Identifier lives in the M2UA message header 🎀.
Using SCTP streams inside M2UA is recommended, because it cuts down on transmission and buffering delay. That makes the signalling elements perform better and feel more reliable 🫶. Each SS7 link can get its own SCTP stream. Or an implementation can split one SS7 link across several streams based on SLS 🦋. This is especially useful for high speed SS7 links (MTP3b), since those links have a 24-bit sequence number and the stream sequence number is only 16 bits 🔥.
SCTP Stream '0' SHOULD NOT be used for MTP2 User Adaptation (MAUP) messages (see Section 3) 🙅♀️. 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) up to the local Layer Management, if the currently active ASP moves out of the ACTIVE state 😭. Whatever M2UA on the SGP does with MTP Level 2 should follow the appropriate MTP specifications 📜.
1.5.6 Flow Control / Congestion 🌊
M2UA can be told about IP network congestion onset and abatement through an implementation dependent function (for example, an indication from SCTP) 🌈. How M2UA handles that congestion indication is up to the implementation 🧚. Still, the actions the SG takes should follow the appropriate MTP specification, and they should keep SS7 functionality (like flow control) working properly ✨.
1.5.7 Audit of SS7 Link State 🔍
after one ASP fails over to another ASP, the M2UA on the ASP may need to audit the current SS7 link state to make sure everything still matches 💅. The M2UA on the SGP responds to that audit request with the current state of the SS7 link (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 COMPLETE1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP 🌸
the upper layer and layer management primitives SCTP provides are described 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.0 Conventions 📣
the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be read as described in [RFC2119] whenever they show up in this document 🫶.
3.0 Protocol Elements 🧁
this section breaks down the format of the various messages this protocol uses 💅.
3.1 Common Message Header 💌
the MTP2-User Adaptation protocol messages need a structure that holds a version, message class, message type, message length, and message contents 🎀. This header is shared by all the signalling protocol adaptation layers 🌸:
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 | Spare | Message Class | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Common Message Headerevery field in an M2UA message MUST be sent in network byte order, unless the document says otherwise 🌐.
3.1.1 Version 🔢
the version field holds the version of the M2UA adaptation layer 💖. The supported versions are:
Value Version
----- -------
1 Release 1.03.1.2 Spare 🫧
the Spare field is 8 bits. It SHOULD be set to all '0's by the sender and ignored by the receiver 🙈.
3.1.3 Message Class 🏷️
the following List has the valid Message Classes 📋:
Message Class: 8 bits (unsigned integer)
0 Management (MGMT) Message [IUA/M2UA/M3UA/SUA]
1 Transfer Messages [M3UA]
2 SS7 Signalling Network Management (SSNM) Messages [M3UA/SUA]
3 ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA]
4 ASP Traffic Maintenance (ASPTM) Messages [IUA/M2UA/M3UA/SUA]
5 Q.921/Q.931 Boundary Primitives Transport (QPTM)
Messages [IUA]
6 MTP2 User Adaptation (MAUP) Messages [M2UA]
7 Connectionless Messages [SUA]
8 Connection-Oriented Messages [SUA]
9 Routing Key Management (RKM) Messages (M3UA)
10 Interface Identifier Management (IIM) Messages (M2UA)
11 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined Message Class extensions3.1.4 Message Type 🗂️
the following List has the Message Types for each valid Message Class 🧾:
MTP2 User Adaptation (MAUP) Messages
0 Reserved
1 Data
2 Establish Request
3 Establish Confirm
4 Release Request
5 Release Confirm
6 Release Indication
7 State Request
8 State Confirm
9 State Indication
10 Data Retrieval Request
11 Data Retrieval Confirm
12 Data Retrieval Indication
13 Data Retrieval Complete Indication
14 Congestion Indication
15 Data Acknowledge
16 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MAUP extensions
Application Server Process State Maintenance (ASPSM) messages
0 Reserved
1 ASP Up (UP)
2 ASP Down (DOWN)
3 Heartbeat (BEAT)
4 ASP Up Ack (UP ACK)
5 ASP Down Ack (DOWN ACK)
6 Heartbeat Ack (BEAT ACK)
7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPSM extensions
Application Server Process Traffic Maintenance (ASPTM) messages
0 Reserved
1 ASP Active (ACTIVE)
2 ASP Inactive (INACTIVE)
3 ASP Active Ack (ACTIVE ACK)
4 ASP Inactive Ack (INACTIVE ACK)
5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPTM extensions
Management (MGMT) Messages
0 Error (ERR)
1 Notify (NTFY)
2 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MGMT extensions
Interface Identifier Management (IIM) Messages
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 IIM extensions3.1.5 Message Length 📏
the Message Length is the length of the message in octets, header included 🧮. The Message Length MUST include any parameter padding bytes 🫧. The Message Length MUST NOT be longer than an MTP3 message [2,3,4,5] plus the length of the common and M2UA message headers 💜.
3.1.6. Variable-Length Parameter Format ✨
okay so every M2UA message is a Common Header 🎀 followed by zero or more variable-length parameters, depending on which message type it is. Each parameter comes in a Tag-Length-Value (TLV) format, which looks like this 🧚
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+bestie, the ordering rule is a must-know 💅 Mandatory parameters MUST be placed before optional parameters in a message. no skipping that one!
Parameter Tag: 16 bits (unsigned integer)
The Type field is a 16 bit identifier for the type of parameter 🌸 It can be anywhere from 0 to 65534. The common parameters that all the adaptation layers share sit in the range 0x00 to 0xff, and the M2UA-specific ones live in 0x300 to 0x3ff.
Here are the common parameter tags that M2UA uses (these are shared by every User Adaptation layer) 🦋
Parameter Value Parameter Name
--------------- --------------
0 (0x00) Reserved
1 (0x01) Interface Identifier (Integer)
2 (0x02) Unused
3 (0x03) Interface Identifier (Text)
4 (0x04) Info String
5 (0x05) Unused
6 (0x06) Unused
7 (0x07) Diagnostic Information
8 (0x08) Interface Identifier (Integer Range)
9 (0x09) Heartbeat Data
10 (0x0a) Unused
11 (0x0b) Traffic Mode Type
12 (0x0c) Error Code
13 (0x0d) Status Type/Information
14 (0x0e) Unused
15 (0x0f) Unused
16 (0x10) Unused
17 (0x11) ASP Identifier
18 (0x12) Unused
19 (0x13) Correlation Id
18-255 ReservedAnd these are the M2UA-specific parameter tags 👑
Parameter Value Parameter Name
--------------- --------------
768 (0x0300) Protocol Data 1
769 (0x0301) Protocol Data 2 (TTC)
770 (0x0302) State Request
771 (0x0303) State Event
772 (0x0304) Congestion Status
773 (0x0305) Discard Status
774 (0x0306) Action
775 (0x0307) Sequence Number
776 (0x0308) Retrieval Result
777 (0x0309) Link Key
778 (0x030a) Local-LK-Identifier
779 (0x030b) Signalling Data Terminal (SDT) Identifier
780 (0x030c) Signalling Data Link (SDL) Identifier
781 (0x030d) Registration Result
782 (0x030e) Registration Status
783 (0x030f) De-Registration Result
784 (0x0310) De-Registration StatusParameter Length: 16 bits (unsigned integer)
The Parameter Length field tells you the size of the parameter in bytes, and that includes the Parameter Tag, Parameter Length and Parameter Value fields 🍓 So a parameter with a zero-length Parameter Value field has a Length field of 4. The Parameter Length does not include any padding bytes, so keep that in mind ✨
Parameter Value: variable-length.
The Parameter Value field holds the actual info being sent in the parameter 💖
The total length of a parameter (Tag, Parameter Length and Value fields together) MUST be a multiple of 4 bytes. If it isn't, the sender pads the Parameter at the end (so after the Parameter Value field) with all zero bytes. The length of the padding is not included in the parameter length field. A sender MUST NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
3.2. M2UA Message Header 🦋
so on top of the common message header, there's also an M2UA-specific message header 🌈 It sits right after the common header, but it only gets used with MAUP messages.
This header carries the Interface Identifier, which tells you which physical interface at the SG the signalling messages are being sent or received on 🎀 The Interface Identifier parameter can be text or integer, and its values are assigned according to network operator policy. The values only mean something locally, and they're coordinated between the SG and the ASP.
The integer formatted Interface Identifier MUST be supported. The text formatted Interface Identifier MAY optionally be supported.
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 (0x1) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3 M2UA Message Header (Integer-based Interface Identifier)
The Tag value for the integer-based Interface Identifier is 0x1, and the length is always set to 8 ✨
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 (0x3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifier (text) /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4 M2UA Message Header (Text-based Interface Identifier)
The Tag value for the text-based Interface Identifier is 0x3 🌸 The encoding is ANSI X3.4-1986 [7]. The maximum string length of a text-based Interface Identifier is 255 octets. The tag length equals the string length of the Interface Identifier name plus four bytes for the Tag and Length fields.
3.3. M2UA Messages 💜
this section defines the messages and what their parameter contents look like. The M2UA messages use the common message header (Figure 2) and the M2UA message header (Figure 3 and Figure 4) 🫶
3.3.1. MTP2 User Adaptation Messages 🧚
3.3.1.1. Data 💌
The Data message carries an SS7 MTP2-User Protocol Data Unit (PDU) 🎀 It contains the following parameters:
Protocol Data (mandatory)
Correlation Id (optional)Here's the format for the Data message parameters 👀
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 (0x300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Protocol Data /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x13) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Protocol Data field holds the MTP2-User application message in network byte order, starting with the Signalling Information Octet (SIO) 🌈 The Correlation Id parameter uniquely identifies the MSU carried in the Protocol Data within an AS. The sending M2UA is the one that assigns this Correlation Id. Its whole purpose is to let the newly active ASP sync up its processing of the traffic in each ordered stream with the other ASPs in the broadcast group 💅
The format for a Data message with TTC PDU parameters looks like this ✨
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 (0x301) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ TTC Protocol Data /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x13) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Protocol Data field holds the MTP2-User application message in network byte order, starting with the Length Indicator (LI) octet. The Japanese TTC variant borrows the spare bits of the LI octet for priority 🔥
The length of the Protocol Data and the TTC Protocol Data MUST NOT exceed the length of an MTP2-User application message [2,3,5]. no going over, bestie 🙈
3.3.1.2. Data Acknowledge Message 🫧
The Data Acknowledge message carries the Correlation Id of the Data message that the sending M2UA is acknowledging as successfully processed to the peer M2UA 💖
The Data Acknowledge message contains the following parameter:
Correlation Id MandatoryThe following format MUST be used for the Data Ack 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 (0x13) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Correlation Id parameter in the Data message and the Data Ack message gives SG implementations that can use it a way to get an acknowledgment that the MSU has been transferred to the M2UA peer, before they acknowledge the MSU to the SS7 peer. That helps remove the risk of losing messages because of association failure or SCTP congestion 🌸
The Data Ack message MUST be sent if a Correlation Id parameter is received from the peer. Otherwise, the Data Ack message MUST NOT be sent.
⚠️ If the Data Acknowledge is not sent for Correlation Id(s), or is sent with Invalid Correlation Id(s), the SS7 link will eventually fail due to lack of MTP Level 2 acknowledgments of the SS7 peer's MSUs. this one is serious, so don't skip it! 💀
3.3.1.3 Establish (Request, Confirmation) 🎀
okay so the Establish Request is how the MGC says "hey, can we get this SS7 link up?" 🧚 or it's used to say "the channel is established" ✨. the MGC is the one in charge of the link state, so when it wants the link in-service, it sends the Establish Request 💅
btw the SGP MAY already have the SS7 link up at its layer 🫶 if that's the case, the SGP doesn't have to do anything when the Establish Request shows up except send back an Establish Confirm. super chill, no drama 🌸
now the MGC MAY start a timer when it sends an M2UA Establish Request 💖 the timer gets stopped when the Establish Confirm arrives. if the timer runs out, the MGC resends the Establish Request and starts the timer again 😭 so basically the MGC MAY keep asking for the data link every so often until it gets the state it wants or until it does something else (like telling the Management Layer) 🔥
the mode for bringing the SS7 link in service is Normal by default 🌈 if you want Emergency instead, you use the State Request (see Section 3.3.1.5 below) to switch it 💜
3.3.1.4 Release (Request, Indication, Confirmation) 🦋
this Release Request is used to release the channel 🍓 and the Release Confirm and Indication are how everyone finds out the channel has been released 🙈
3.3.1.5 State Request 👑
the State Request is something the MGC can send to make something happen on a specific SS7 link that the Signalling Gateway Process is handling ✨ if the action works out, the SGP sends back a State Confirm 💖 and that State Confirm echoes the state value that was in the State Request 🫶
the State Request has one parameter, State (mandatory) 🎀
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 (0x302) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+here are the valid State values 📋
Define Value Description
STATUS_LPO_SET 0x0 Request local processor outage
STATUS_LPO_CLEAR 0x1 Request local processor outage
recovered
STATUS_EMER_SET 0x2 Request emergency alignment
STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel
emergency)
STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit
and retransmit queues
STATUS_CONTINUE 0x5 Continue or Resume
STATUS_CLEAR_RTB 0x6 Clear the retransmit queue
STATUS_AUDIT 0x7 Audit state of link
STATUS_CONG_CLEAR 0x8 Congestion cleared
STATUS_CONG_ACCEPT 0x9 Congestion accept
STATUS_CONG_DISCARD 0xa Congestion discard3.3.1.6 State Confirm 💅
the SGP sends the State Confirm in response to a State Request from the MGC ✨ it reflects the state value that came in the State Request 🌸
the State Confirm has one parameter, State (mandatory) 🧚
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 (0x302) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the valid State values are in the table below 🍓 the State field SHOULD reflect the value that came in the State Request 💖
Define Value Description
STATUS_LPO_SET 0x0 Request local processor outage
STATUS_LPO_CLEAR 0x1 Request local processor outage
recovered
STATUS_EMER_SET 0x2 Request emergency alignment
STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel
emergency)
STATUS_FLUSH_BUFFERS 0x4 Flush or clear receive, transmit
and retransmit queues
STATUS_CONTINUE 0x5 Continue or Resume
STATUS_CLEAR_RTB 0x6 Clear the retransmit queue
STATUS_AUDIT 0x7 Audit state of link
STATUS_CONG_CLEAR 0x8 Congestion cleared
STATUS_CONG_ACCEPT 0x9 Congestion accept
STATUS_CONG_DISCARD 0xa Congestion discard3.3.1.7 State Indication 🌈
the MTP2 State Indication can be sent from an SGP to an ASP to flag a condition on a SS7 link 🔥
the State Indication has one parameter, Event (mandatory) 🦋
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 (0x303) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the valid Event values are in this table 📋
Define Value Description
EVENT_RPO_ENTER 0x1 Remote entered processor outage
EVENT_RPO_EXIT 0x2 Remote exited processor outage
EVENT_LPO_ENTER 0x3 Link entered processor outage
EVENT_LPO_EXIT 0x4 Link exited processor outage3.3.1.8 Congestion Indication 🚨
the Congestion Indication can be sent from a Signalling Gateway Process to an ASP to show the congestion status and discard status of a SS7 link 💜 when the MSU buffer fill goes above an Onset threshold, drops below an Abatement threshold, or crosses a Discard threshold in either direction, the SGP SHALL send a congestion indication message, but only when it supports SS7 MTP2 variants that handle multiple congestion levels 😭
the SGP SHALL send the message only when there's an actual change in the discard level or the congestion level to report, which means it's different from the message sent before 🫶 on top of that, the SGP SHALL use an implementation dependent algorithm to limit how often it sends congestion indication messages 🌸
an implementation may optionally send Congestion Indication messages on a "high priority" stream to maybe cut down on delay ⭐
the Congestion Indication has these parameters: Congestion Status (mandatory) and Discard Status (optional) 🎀
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 (0x304) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x305) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discard Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the valid values for Congestion Status and Discard Status are in this table 📋
Define Value Description
LEVEL_NONE 0x0 No congestion
LEVEL_1 0x1 Congestion Level 1
LEVEL_2 0x2 Congestion Level 2
LEVEL_3 0x3 Congestion Level 3for SS7 networks that don't support multiple congestion levels, only LEVEL_NONE and LEVEL_3 get used 🥺 for networks that do support multiple levels, all the values can be used 🌈 check out [2], [3] and [12] for more on the Congestion and Discard Status of SS7 signalling links 📚✨
3.3.1.9 Retrieval Request 🧚
the MTP2 Retrieval Request is used during the MTP Level 3 changeover procedure 🔄 it can ask for the BSN, pull PDUs out of the transmit and retransmit queues, or flush PDUs from the retransmit queue 💖 examples of Retrieval Request being used for SS7 Link Changeover are in Section 5.3.6 🍓
the Retrieval Request has these parameters: Action (mandatory) and Sequence Number (optional) 🎀
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 (0x306) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x307) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the valid values for Action are in this table 📋
Define Value Description
ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number
ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the transmit
and retransmit queuesin the Retrieval Request, the Sequence Number field SHOULD NOT be present when Action is ACTION_RTRV_BSN 🙅♀️ the Sequence Number field holds the Forward Sequence Number (FSN) of the far end when Action is ACTION_RTRV_MSGS 💜
3.3.1.10 Retrieval Confirm ✨
okay so the MTP2 Retrieval Confirm 💅 is what the Signalling Gateway sends back in reply to a Retrieval Request. it's giving answer-the-question energy 🎀 for SS7 Link Changeover examples, peep Section 5.3.6 🦋
the Retrieval Confirm carries these parameters:
- Action (mandatory)
- Result (mandatory)
- Sequence Number (optional)
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 (0x306) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x308) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x307) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the valid values for Action are the same as in Retrieval Request 🫶
here are the Result values:
Define Value Description
RESULT_SUCCESS 0x0 Action successful
RESULT_FAILURE 0x1 Action failedso when the Signalling Gateway Process replies to a Retrieval Request with a Retrieval Confirm, it echoes the Action field 🔁 if the Action was ACTION_RTRV_BSN and the SGP successfully retrieved the BSN, the SGP will put the Backward Sequence Number (BSN) in the Sequence Number field and will indicate a success in the Result field ✅ if the BSN couldn't be retrieved, the Sequence Number field won't be included and the Result field will indicate failure 💀
for a Retrieval Confirm with Action ACTION_RTRV_MSGS, the Result field tells you success or failure. failure means the buffers couldn't be retrieved 😭 and the Sequence Number field is not used with ACTION_RTRV_MSGS 🙈
3.3.1.11 Retrieval Indication 🌸
the Retrieval Indication is sent by the Signalling Gateway along with a PDU from the transmit or retransmit queue 🧚 it doesn't have the Action or Sequence Number fields, just a MTP3 Protocol Data Unit (PDU) from that queue. for SS7 Link Changeover examples, see Section 5.3.6 🦋
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 (0x300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Protocol Data /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+for TTC Data messages, this parameter shows a TTC PDU that starts at LI 🎀
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 (0x301) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ TTC Protocol Data /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the M2UA implementation MAY consider using SCTP's bundling feature for Retrieval Indication messages 🔥
3.3.1.12 Retrieval Complete Indication 👑
the MTP2 Retrieval Complete Indication is basically the same as the MTP2 Retrieval Indication, except it also tells you that retrieval is complete 🥹 it MAY contain a PDU, and if it does, that PDU MUST be the last PDU from the transmit or retransmit queue 💅
3.3.2 Application Server Process Maintenance (ASPM) Messages 🧚
the ASPM messages only use the common message header ✨
3.3.2.1 ASP Up (ASPUP) 🦋
the ASP Up (ASPUP) message tells a remote M2UA peer that the Adaptation layer is ready to receive traffic or maintenance messages 🫶
the ASPUP message carries these parameters:
- ASP Identifier (optional)
- Info String (optional)
Note: The ASP Identifier MUST be used where the SGP cannot identify the ASP by pre-configured address/port number information (e.g., where an ASP is resident on a Host using dynamic address/port number assignment). 🙈
the format for ASPUP Message parameters 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 (0x11) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the optional ASP Identifier is a unique value that's locally significant among the ASPs that support an AS 🔑 the SGP should save the ASP Identifier to use, if necessary, with the Notify message (see Section 3.3.3.2) 💅
the optional INFO String can carry any meaningful UTF-8 [6] character string along with the message 💬 its length is from 0 to 255 octets. no procedures are presently identified for its use, but the INFO String MAY be used for debugging purposes 🐛
3.3.2.2 ASP Up Ack 🎀
the ASP Up Ack message acknowledges an ASP Up message received from a remote M2UA peer 🫶
the ASPUP Ack message carries this parameter:
- INFO String (optional)
the format for ASPUP Ack Message parameters 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 (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the INFO String here works exactly like it does for the ASP Up message (see Section 3.3.2.1) 🌈
3.3.2.3 ASP Down (ASPDN) 🥀
the ASP Down (ASPDN) message tells a remote M2UA peer that the adaptation layer is not ready to receive traffic or maintenance messages 😭
the ASPDN message carries this parameter:
- INFO String (optional)
the format for the ASPDN message parameters 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 (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the INFO String here is the same as for the ASP Up message (see Section 3.3.2.1) 💖
3.3.2.4 ASP Down Ack 🍓
the ASP Down Ack message acknowledges an ASP Down message received from a remote M2UA peer 🫶
the ASP Down Ack message carries this parameter:
- INFO String (optional)
the format for the ASPDN Ack message parameters 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 (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the INFO String here is the same as for the ASP UP message (see Section 3.3.2.1) 🎀
3.3.2.5 Heartbeat (BEAT) 💓
the Heartbeat message is optionally used to make sure the M2UA peers are still around for each other 🫂
the BEAT message carries this parameter:
- Heartbeat Data (Optional)
the format for the BEAT message 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 = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the sending node defines what goes in the Heartbeat Data field 🧠 it may include a Heartbeat Sequence Number and/or time stamp, or other implementation specific details 🍭
the receiver doesn't process this field, since it only matters to the sender 🙈 the receiver echoes the content of the Heartbeat Data in a BEAT ACK message 🔁
3.3.2.6 Heartbeat Ack (BEAT ACK) 💖
okay so the BEAT ACK is the reply you send back whenever a BEAT comes in 🦋 A peer MUST send a BEAT ACK in response to a BEAT message. no skipping this one bestie 🫶 It has to include all the parameters from the Heartbeat it received, without changing any of them ✨
The BEAT ACK message contains the following parameter:
- Heartbeat Data (Optional)
The format for the BEAT 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 = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the sending node gets to decide what goes in the Heartbeat Data field 🧚 It may include a Heartbeat Sequence Number and/or time stamp, or other implementation specific details.
the receiver doesn't process this field at all, because it only matters to the sender 💅 The receiver just echoes the content of the Heartbeat Data back in a BEAT ACK message. iconic echo energy 🔁
3.3.2.7 ASP Active (ASPAC) 🌸
the ASPAC message is how an ASP tells an SGP that it is Active and ready to be used 🚀
The ASPAC message contains the following parameters:
- Traffic Mode Type (optional)
- Interface Identifier (optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
- INFO String (optional)
The format for the ASPAC message using integer formatted Interface Identifiers 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 (0xb) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifiers* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x1 or 0x8 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The format for the ASPAC message using text formatted (string) Interface Identifiers 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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifier* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x3 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Traffic Mode Type parameter tells you the traffic mode the ASP is running in within an AS 🍓 The valid values for Type are in this table:
Value Description
0x1 Override
0x2 Load-share
0x3 Broadcastwithin a particular AS, only one Traffic Mode Type can be used, so pick wisely 👑 Override means the ASP is in Override mode, where it takes over all traffic in an Application Server (aka primary/backup operation) and overrides any currently active ASPs in the AS. Load-share means the ASP shares the traffic distribution with any other currently active ASPs. And Broadcast means all of the Active ASPs receive all message traffic in the Application Server. main character energy for every mode 🌈
the optional Interface Identifiers parameter is a list of Interface Identifier integers (Type 0x1 or Type 0x8) or text strings (Type 0x3) that index the Application Server traffic the sending ASP is configured or registered to receive 🎀 If you're using integer formatted Interface Identifiers, the ASP can also send ranges of them (Type 0x8). Integer (0x1) and Integer Range (0x8) types are allowed in the same message. But text formatted Interface Identifiers (0x3) cannot be used with either Integer (0x1) or Integer Range (0x8) types, so don't mix those up 🙈
if no Interface Identifiers are included, the message is for all provisioned Interface Identifiers within the AS(s) the ASP is provisioned in. If only a subset of Interface Identifiers for an AS are included, the ASP is noted as Active for all the Interface Identifiers provisioned for that AS.
Note: If the optional Interface Identifier parameter is present, the integer formatted Interface Identifier MUST be supported, while the text formatted Interface Identifier MAY be supported.
if an SGP gets an ASPAC with an incorrect or unsupported Traffic Mode Type for a particular Interface Identifier, it will respond with an Error Message (Cause: Unsupported Traffic Handling Mode) 💀
the format and description of the optional Info String parameter is the same as for the ASP UP message (See Section 3.3.2.1) 🧚♀️
3.3.2.8 ASP Active Ack 🦋
okay so the ASP Active (ASPAC) Ack is the reply that says "got it, bestie" 💅 when a remote M2UA peer sends an ASP Active message. it's basically the acknowledgement that closes the loop ✨
the ASPAC Ack message carries these parameters:
- Traffic Mode Type (optional)
- Interface Identifier (optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
- INFO String (optional)
here's the layout when the Interface Identifiers are integers 🌸
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 (0xb) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifiers* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x1 or 0x8 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and here's the one for text formatted (string) Interface Identifiers 🎀
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 (0xb) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifier* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x3 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the INFO String parameter is optional, and its format and description are the same as for the ASP Up message (see Section 3.3.2.1).
the optional Interface Identifier parameter is formatted the same way as in the ASP Active message (see Section 3.3.2.7).
and yes, the INFO String is repeated here, same rules as the ASP Up message (see Section 3.3.2.1) 💖
3.3.2.9 ASP Inactive (ASPIA) 🧚
the ASP Inactive (ASPIA) message is how an ASP tells an SGP "hey, I'm no longer an active ASP to be used from within a list of ASPs" 🥺 the SGP replies with an ASPIA Ack message, and then it either discards incoming messages or buffers them for a timed period and then discards them. bye bye messages 👋
the ASPIA message carries these parameters:
- Interface Identifiers (optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
- INFO String (optional)
for the ASP Inactive message with integer formatted Interface Identifiers, it looks like this 🌈
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 (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifiers* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x1 or 0x8 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and for text formatted (string) Interface Identifiers 🎀
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 (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifier* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x3 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the optional Interface Identifier parameter is formatted the same way as in the ASP Active message (see Section 3.3.2.7).
the INFO String works exactly like it does for the ASP Up message (see Section 3.3.2.1).
the optional Interface Identifiers parameter holds a list of Interface Identifier integers. these index the Application Server traffic that the sending ASP is configured/registered to receive, but doesn't want to receive right now 🫶
3.3.2.10 ASP Inactive Ack 🦋
okay so the ASP Inactive (ASPIA) Ack is the reply message 🫶 It's how we say "got it, you're inactive now" to a remote M2UA peer after it sends an ASP Inactive message.
The ASPIA Ack message has these parameters:
- Interface Identifiers (optional)
- Combination of integer and integer ranges, OR
- string (text formatted)
- INFO String (optional)
Here's the format for the ASPIA Ack 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 (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifiers* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x1 or 0x8 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The format for the ASP Inactive Ack message using text formatted (string) Interface Identifiers 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 (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifier* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x3 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The optional Interface Identifier parameter works exactly the same way as it does for the ASP Active message (see Section 3.3.2.7) 🧚
The optional Info String parameter is described and formatted exactly the same as it is for the ASP Up message (see Section 3.3.2.1) 🌸
3.3.3 Layer Management (MGMT) Messages 🎀
3.3.3.1 Error (ERR) 💀
okay this one is the Error (ERR) message, and it's how a peer tells you something went wrong with an incoming message 😭 Like, the message type didn't make sense for where you are right now, or a parameter value is invalid. Literally the "wait, what??" message.
An Error message MUST not be generated in response to other Error messages. 🙈 No error-ception loops, bestie!
The ERR message has these parameters:
- Error Code (mandatory)
- Interface Identifier (optional)
- Diagnostic Information (optional)
Here's the format for the ERR 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 (0xc) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1, 0x3, or 0x8) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifier(s)* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x7) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Diagnostic Information* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Error Code parameter tells you why the Error message exists 🔥 It can be one of these values:
Invalid Version 0x1
Invalid Interface Identifier 0x2
Unsupported Message Class 0x3
Unsupported Message Type 0x4
Unsupported Traffic Handling Mode 0x5
Unexpected Message 0x6
Protocol Error 0x7
Unsupported Interface Identifier Type 0x8
Invalid Stream Identifier 0x9
Not Used in M2UA 0xa
Not Used in M2UA 0xb
Not Used in M2UA 0xc
Refused - Management Blocking 0xd
ASP Identifier Required 0xe
Invalid ASP Identifier 0xf
ASP Active for Interface Identifier(s) 0x10
Invalid Parameter Value 0x11
Parameter Field Error 0x12
Unexpected Parameter 0x13
Not Used in M2UA 0x14
Not Used in M2UA 0x15
Missing Parameter 0x16Let's go through the drama, one error at a time 👑
- "Invalid Version": this would be sent if a message came in with an invalid or unsupported version. The Error message would contain the supported version in the Common header 💖 It could also optionally put the supported version in the Diagnostic Information area.
- "Invalid Interface Identifier": this would be sent by a SGP if an ASP sends a message (i.e. an ASP Active message) with an invalid (not configured) Interface Identifier value. One of the optional Interface Identifier parameters (Integer-based, text-based or integer range) MUST be used with this error code to identify the invalid Interface Identifier(s) received.
- "Unsupported Traffic Handling Mode": this would be sent by a SGP if an ASP sends an ASP Active with a Traffic Handling Mode it doesn't support. An example would be a SGP that didn't support load-sharing ✨ One of the optional Interface Identifier parameters (Integer-based, text-based or integer range) MAY be used with this error code to identify the Interface Identifier(s).
- "Unexpected Message": this would be sent by an ASP if it received a MAUP message from an SGP while it was in the Inactive state 🦋
- "Protocol Error": this would be sent for any protocol anomaly (i.e. a bogus message) 🙈
- "Invalid Stream Identifier": this would be sent if a message was received on an unexpected SCTP stream (i.e. a MGMT message was received on a stream other than "0") 🧚
- "Unsupported Interface Identifier Type": this would be sent by a SGP if an ASP sends a Text formatted Interface Identifier and the SGP only supports Integer formatted Interface Identifiers. When the ASP gets this error, it will need to resend its message with an Integer formatted Interface Identifier 🍓
- "Unsupported Message Class": this would be sent if a message with an unexpected or unsupported Message Class is received 🌈
- "Refused - Management Blocking": this is sent when an ASP Up or ASP Active message is received and the request is refused for management reasons (e.g., management lock-out"). 🔒
- "ASP Identifier Required": this is sent by a SGP in response to an ASPUP message that doesn't contain an ASP Identifier parameter when the SGP requires one. The ASP SHOULD resend the ASPUP message with an ASP Identifier. 💅
- "Invalid ASP Identifier": this is sent by a SGP in response to an ASPUP message with an invalid (i.e. non-unique) ASP Identifier 💀
- "ASP Currently Active for Interface Identifier(s)": this is sent by a SGP when a Deregistration request is received from an ASP that is active for the Interface Identifier(s) named in that Deregistration request. One of the optional Interface Identifier parameters (Integer-based, text-based or integer range) MAY be used with this error code to identify the Interface Identifier(s) ✨
- "Invalid Parameter Value ": this is sent if a message is received with an invalid parameter value (e.g., a State Request with an an undefined State) 🎀
- "Parameter Field Error": this would be sent if a message has a parameter with a wrong length field 💜
- "Unexpected Parameter": this would be sent if a message contains an invalid parameter 🌸
- "Missing Parameter": this would be sent if a mandatory parameter wasn't included in a message 🫶
The optional Diagnostic Information can be any information that's relevant to the error condition, to help figure out what went wrong 🔍 For an Invalid Version Error Code, the Diagnostic Information includes the supported Version parameter. For the other cases, the Diagnostic Information SHOULD be the first 40 bytes of the offending message. 💖
3.3.3.2 Notify (NTFY) ✨
okay bestie, so the Notify message is how an M2UA peer gets an autonomous heads-up about M2UA events 📣💖 no asking required, it just tells you 💅
The NTFY message carries these parameters:
- Status Type (mandatory) 🎀
- Status Information (mandatory) 🎀
- ASP Identifier (optional) ✨
- Interface Identifiers (optional) ✨
- INFO String (optional) ✨
Here's the layout when the Interface Identifiers are integer-formatted 🧚
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 (0xd) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x11) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x1=integer) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifiers* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x8=integer range) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop1* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Start2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier Stop2* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StartN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier StopN* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x1 or 0x8 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And here's the layout when they're text-formatted instead 🌸
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 (0xd) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type | Status Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x11) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3=string) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Interface Identifier* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ Additional Interface Identifiers /
/ of Tag Type 0x3 \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \
\ INFO String* /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Status Type parameter tells you what kind of Notify this is 🧁 The valid Status Type values are:
Value Description
0x1 Application Server state change (AS_State_Change)
0x2 OtherThe Status Information parameter gives you the juicy details for the notification, and what it means depends on the Status Type 👀 If the Status Type is AS_State_Change, these Status Information values are used:
Value Description
1 reserved
2 Application Server Inactive (AS_Inactive)
3 Application Server Active (AS_Active)
4 Application Server Pending (AS_Pending)These notifications go from an SGP to an ASP whenever an Application Server's status changes 🔥 The value tells you the Application Server's new state. The Interface Identifiers of the AS MAY be included if you want them 💅
If the Status Type is Other, these Status Information values are defined:
Value Description
1 Insufficient ASP resources active in AS
2 Alternate ASP Active
3 ASP FailureFor Insufficient ASP Resources, the SGP is telling the ASP-INACTIVE ASP(s) in the AS that another ASP is needed to handle the AS's load (Load-sharing mode) 🫶 For Alternate ASP Active, the formerly Active ASP gets told when an alternate ASP moves to ASP Active in Override mode. The ASP Identifier of the Alternate ASP MUST be placed in the message (if available) 🦋 For ASP Failure, the SGP is letting the ASP(s) in the AS know that one of the ASPs has moved to ASP-DOWN. The ASP Identifier of the failed ASP MUST be placed in the message (if available) 😭
For each of the Status Information values under Status Type Other, the Interface Identifiers of the affected AS MAY be included if you want them ✨
The Interface Identifier parameter has the same format as in the ASP Active message (See Section 3.3.2.7) 🎀
The Info String parameter has the same format and description as in the ASP Up message (See Section 3.3.2.1) 🌈
3.3.4 Interface Identifier Management (IIM) Messages 🦋
the Interface Identifier Management messages are optional, no cap 🙈 They support the automatic allocation of Signalling Terminals or Signalling Data Links [2][3] 💜
3.3.4.1 Registration Request (REG REQ) 📝
okay bestie, so the REG REQ message is how an ASP tells its remote M2UA peer "hi, I'd like to register one or more Link Keys with you, pls and thank u" 💅 Usually the ASP sends this to an SGP and then waits for a REG RSP back, which comes with an Interface Identifier value attached. ✨
The REG REQ message carries this one parameter:
Link Key(mandatory) 🔑
The format for the REG REQ message looks like this 🦋
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 = 0x0309 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Link Key 1 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0309 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Link Key n /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Link Key: fixed length 🌸
The Link Key parameter is mandatory. The sender expects the receiver to create a Link Key entry and assign it a unique Interface Identifier value, if that Link Key entry doesn't exist yet. ✨
The Link Key parameter can show up multiple times in the same message. That's the trick that lets you register a whole bunch of Link Keys in one go 🧚
The format of the Link Key parameter 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-LK-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signalling Data Terminal Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signalling Data Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Local-LK-Identifier: 32-bit integer 🎀
The mandatory Local-LK-Identifier field is how the ASP and SGP tell registration requests apart. The ASP picks the value, and it's what lets the matching REG RSP be linked back to the original request 🫶
The Identifier value MUST remain unique until the REG RSP is received. This one is important, bestie, so don't skip it! 🚨
The format of the Local-LK-Identifier field 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 = 0x030a | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-LK-Identifier value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Signalling Data Terminal Identifier 💜
The Signalling Data Terminal Identifier parameter is mandatory. It identifies the Signalling Data Terminal tied to the SS7 link the ASP is registering for. The 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 = 0x030b | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SDT Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The SDT Identifier is a 32-bit unsigned value, but it may only be significant to 12 or 14 bits, depending on which SS7 variant the MTP Level 3 at the ASP supports. Any insignificant SDT Identifier bits are coded 0. 🤓
Signalling Data Link Identifier 🌈
The Signalling Data Link Identifier parameter is mandatory. It identifies the Signalling Data Link Identifier tied to the SS7 link the ASP is registering for. The 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 = 0x030c | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | SDL Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The SDL Identifier is a 32-bit unsigned value, but it may only be significant to 12 or 14 bits, depending on which SS7 variant the MTP Level 3 at the ASP supports. Insignificant SDLI bits are coded 0. 💖
3.3.4.2 Registration Response (REG RSP) 🎀
The REG RSP message is the reply to a REG REQ from a remote M2UA peer. It says whether each registration worked or didn't, and for the ones that worked, it hands back a unique Interface Identifier value to use in later M2UA Traffic Management protocol. 🦋
The REG RSP message carries this one parameter:
Registration Results(mandatory) ✨
The format for the REG RSP message 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 = 0x030d | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Registration Result 1 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x030d | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Registration Result n /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Registration Results: fixed length 🌷
The Registration Results parameter holds one or more results, and each one gives the registration status for a single Link Key from the REG REQ. The number of results in one REG RSP MAY match the number of Link Key parameters in the matching REG REQ. The format of each result 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local-LK-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Local-LK-Identifier: 32-bit integer 💜
This holds the same value as the matching Link Key parameter in the REG REQ, so you can match up each answer with its question. The format is the one shown in Section 3.3.4.1. 🫶
Registration Status: 32-bit integer 🔥
The Registration Status field tells you whether a registration request worked, or why it didn't. 💅
Its values may be one of the following:
0 Successfully Registered
1 Error - Unknown
2 Error - Invalid SDLI
3 Error - Invalid SDTI
4 Error - Invalid Link Key
5 Error - Permission Denied
6 Error - Overlapping (Non-unique) Link Key
7 Error - Link Key not Provisioned
8 Error - Insufficient ResourcesThe format of the Registration Status field 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 = 0x030e | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Interface Identifier: 32-bit integer 🦋
The Interface Identifier field holds the Interface Identifier for the matching Link Key if the registration worked. If it didn't work, it's set to "0". For the formats of integer-based and text-based Interface Identifier parameters, check out Section 3.2. ✨
3.3.4.3 De-Registration Request (DEREG REQ) 🎀
okay so the DEREG REQ message is how an ASP tells its remote M2UA peer "bestie, I'm done with this Interface Identifier, I wanna de-register" 💅 Usually the ASP sends it to an SGP, and then it's waiting for a DEREG RSP back that mirrors the Interface Identifier and includes a de-registration status 🦋
The DEREG REQ message has one parameter:
- Interface Identifier (mandatory)
Here's what the DEREG REQ message looks like 👀
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 = 0x1 or 0x3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifier 1 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x1 or 0x3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Interface Identifier n /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Interface Identifier ✨ This parameter holds an Interface Identifier that points at the Application Server traffic the sending ASP is currently registered to receive from the SGP, but now it wants to de-register from it. The integer-based and text-based Interface Identifier parameter formats are shown in Section 3.2 🧚
3.3.4.4 De-Registration Response (DEREG RSP) 🌸
the DEREG RSP message is the reply to a DEREG REQ from a remote M2UA peer 💖
It has one parameter:
- De-Registration Results (mandatory)
Here's the layout 🍓
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 = 0x030f | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ De-Registration Result 1 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x030f | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ De-Registration Result n /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+De-Registration Results (fixed length) 💅 This parameter carries one or more results, and each one has the de-registration status for a single Interface Identifier from the DEREG REQ message. A single DEREG RSP MAY have as many results as there were Interface Identifier parameters in the matching DEREG REQ. Each result looks like this 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| De-Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Interface Identifier (32-bit integer) 🧚 This field holds the Interface Identifier value of the matching Link Key to de-register, exactly as it appeared in the DEREG REQ. The integer-based and text-based formats are in Section 3.2 ✨
De-Registration Status (32-bit integer) 👑 This field says whether the de-registration worked, or why it didn't.
Its values can be one of these 💜
0 Successfully De-registered
1 Error - Unknown
2 Error - Invalid Interface Identifier
3 Error - Permission Denied
4 Error - Not RegisteredThe De-Registration Status field looks like this 🌈
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 = 0x0310 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| De-Registration Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.0 Procedures ✨
the M2UA layer has to respond to a bunch of primitives from other layers, plus messages from its peer. This section walks through the procedures for those events 🫶
4.1 Procedures to Support the M2UA-User Layer 💖
these procedures deliver the M2UA layer's "Transport of MTP Level 2 / MTP Level 3 boundary" service 🎀
4.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures 🦋
when the M2UA layer gets a primitive from the local upper layer, it sends the matching MAUP message (see Section 3) to its peer. The M2UA layer MUST fill in the various fields of the common and specific headers correctly. Also, the message SHOULD go out on the SCTP stream that matches the SS7 link 🧚
4.1.2 MAUP Message Procedures 🌸
when MAUP messages come in from a peer M2UA layer, the M2UA layer on an SG or MGC has to invoke the matching primitives toward the local MTP Level 2 or MTP Level 3 layer 💅
4.2 Receipt of Primitives from the Layer Management 👑
when the M2UA layer gets primitives from the local Layer Management, it takes the requested action and gives Layer Management a fitting response primitive 💜
an M-SCTP_ESTABLISH request primitive from Layer Management at an ASP kicks off setting up an SCTP association. The M2UA layer tries to establish an SCTP association with the remote M2UA peer by sending an SCTP-ASSOCIATE primitive to the local SCTP layer 🌈
once an SCTP association is successfully up, SCTP sends an SCTP-COMMUNICATION_UP notification primitive to the local M2UA layer. At the SGP that started the request, the M2UA layer sends an M-SCTP_ESTABLISH confirm primitive to Layer Management when setup is complete. At the peer M2UA layer, an M-SCTP_ESTABLISH indication primitive goes to Layer Management once an incoming SCTP association setup finishes successfully ✨
an M-SCTP_RELEASE request primitive from Layer Management starts shutting down an SCTP association. The M2UA layer does a graceful shutdown by sending an SCTP-SHUTDOWN primitive to the SCTP layer 🫶
when the graceful shutdown is done, SCTP returns an SCTP-SHUTDOWN_COMPLETE notification primitive to the local M2UA layer. At the M2UA layer that started the request, the M2UA layer sends an M-SCTP_RELEASE confirm primitive to Layer Management once the association shutdown is complete. At the peer M2UA layer, an M-SCTP_RELEASE indication primitive goes to Layer Management when an association is aborted or shuts down successfully 🦋
an M-SCTP_STATUS request primitive lets Layer Management check the local status of a particular SCTP association. The M2UA layer just maps the M-SCTP_STATUS request to an SCTP-STATUS primitive for the SCTP layer. When SCTP responds, the M2UA layer maps that association status info into an M-SCTP_STATUS confirm primitive. No peer protocol gets invoked here 🧚
there are similar LM-to-M2UA-to-SCTP and/or SCTP-to-M2UA-to-LM primitive mappings for the other SCTP Upper Layer primitives in RFC 2960 [8], like 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. Or, if you prefer, those SCTP Upper Layer primitives (Status included) can be modeled as a direct Layer Management interaction with the SCTP Layer 💅
M-NOTIFY indication and M-ERROR indication primitives tell Layer Management about the notification or error info in a received M2UA Notify or Error message, respectively. They can also be generated from local M2UA events 🌸
an M-ASP_STATUS request primitive lets Layer Management check the status of a particular local or remote ASP. The M2UA layer answers with the status in an M-ASP_STATUS confirm primitive. No M2UA peer protocol gets invoked 👑
an M-AS_STATUS request lets Layer Management check the status of a particular AS. The M2UA responds with an M-AS_STATUS confirm primitive. No M2UA peer protocol gets invoked 💖
M-ASP_UP request, M-ASP_DOWN request, M-ASP_ACTIVE request and M-ASP_INACTIVE request primitives let Layer Management at an ASP trigger state changes. When one succeeds, the M2UA layer gives Layer Management a matching confirm primitive. If it fails, an Error indication primitive comes back in the primitive instead 🌈 These requests lead to outgoing ASP Up, ASP Down, ASP Active and ASP Inactive messages to the remote M2UA peer at an SGP 🎀
4.2.1. Receipt of M2UA Peer Management Messages ✨
Okay bestie, so when the peer M2UA sends us an ASP Up, ASP Down, ASP Active or ASP Inactive message and the state actually changes successfully, the M2UA layer SHOULD invoke the matching indication primitives up to the local Layer Management: M-ASP_UP, M-ASP_DOWN, M-ASP_ACTIVE, M-ASP_INACTIVE, M-AS_ACTIVE, M-AS_INACTIVE, and M-AS_DOWN 💅
M-NOTIFY and M-ERROR indications are how Layer Management hears about the notification or error info inside a received M2UA Notify or Error message. Lowkey, these can also get generated from local M2UA events too 🔔
Now the ordering stuff, which is so important 🧠
- All MGMT messages except BEAT and BEAT Ack SHOULD be sent with sequenced delivery, so nothing gets scrambled.
- All MGMT messages except ASPTM, BEAT and BEAT Ack SHOULD be sent on SCTP stream
'0'. - All ASPTM messages SHOULD go on the stream that normally carries the data traffic the message is about.
- BEAT and BEAT Ack messages MAY be sent with out-of-order delivery, and they MAY go on any stream 🦋
4.3. AS and ASP State Maintenance 🌸
The M2UA layer on the SGP keeps track of the state of each remote ASP, in each Application Server that the ASP is set up to receive traffic from. This is the input the M2UA message distribution function uses, so it's a big deal 👑
4.3.1. ASP States 🎀
The state of each remote ASP, in each AS it's configured to operate in, lives in the M2UA layer on the SGP. A particular ASP in a particular AS changes state when events happen. Those events include:
- Reception of messages from the peer M2UA layer at the ASP;
- Reception of some messages from the peer M2UA layer at other ASPs in the AS (e.g., ASP Active message indicating "Override");
- Reception of indications from the SCTP layer; or
- Local Management intervention.
The ASP state transition diagram is shown in Figure 5. The possible states of an ASP are:
ASP-DOWN: The remote M2UA peer at the ASP is unavailable and/or the related SCTP association is down. Every ASP starts out in this state. An ASP in this state SHOULD NOT be sent any M2UA messages, except Heartbeat, ASP Down Ack and Error messages. Not me sending random stuff to a dead peer 🙈
ASP-INACTIVE: The remote M2UA peer at the ASP is available (and the related SCTP association is up), but application traffic is stopped. In this state the ASP MAY be sent any non-MAUP M2UA messages 🧚
ASP-ACTIVE: The remote M2UA peer at the ASP is available and application traffic is active (for a particular Interface Identifier or set of Interface Identifiers). ✨
Figure 5: ASP State Transition Diagram
+--------------+
| ASP-ACTIVE |
+----------------------| |
| Other +-------| |
| ASP in AS | +--------------+
| Overrides | ^ |
| | ASP | | ASP
| | Active | | Inactive
| | | v
| | +--------------+
| | | |
| +------>| ASP-INACTIVE |
| +--------------+
| ^ |
ASP Down/ | ASP | | ASP Down /
SCTP CDI/ | Up | | SCTP CDI/
SCTP RI | | v SCTP RI
| +--------------+
| | |
+--------------------->| ASP-DOWN |
| |
+--------------+SCTP CDI: This is the local SCTP layer's Communication Down Indication to the Upper Layer Protocol (M2UA) on an SGP. The local SCTP layer sends it when it spots that connectivity to the ASP's peer SCTP layer is gone. SCTP CDI counts as either a SHUTDOWN_COMPLETE notification or a COMMUNICATION_LOST notification from the SCTP layer 💔
SCTP RI: This is the local SCTP layer's Restart indication to the upper layer protocol (M2UA) on an SG. The local SCTP sends it when it detects a restart from the ASP's peer SCTP layer 🔄
4.3.2. AS States 💜
The state of the AS is kept in the M2UA layer on the SGP. The AS state changes because of events, and these include:
- ASP state transitions
- Recovery timer triggers
The possible states of an AS are:
AS-DOWN: The Application Server is unavailable. This state means all the related ASPs are in the ASP-DOWN state for this AS. The AS starts out in this state. An Application Server MUST be in the AS-DOWN state before it can be removed from a configuration. Strict bestie rule, no exceptions 🚫
AS-INACTIVE: The Application Server is available, but no application traffic is active (i.e., one or more related ASPs are in the ASP-INACTIVE state, but none are in the ASP-ACTIVE state). The recovery timer T(r) is not running or has already expired. 🌙
AS-ACTIVE: The Application Server is available and application traffic is active. This state means at least one ASP is in the ASP-ACTIVE state. 🚀
AS-PENDING: An active ASP went 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 moves to the AS-ACTIVE state and all the queued messages get sent to the ASP. Saved by the queue 🫶
If T(r) expires before an ASP becomes ASP-ACTIVE, the SGP stops queuing messages and throws away all the previously queued messages 😭. The AS moves to the AS-INACTIVE state if at least one ASP is in the ASP-INACTIVE state. Otherwise it moves to the AS-DOWN state.
Figure 6 shows an example AS state machine for the case where the AS/ASP data is pre-configured. For other cases, where the AS/ASP configuration data is created dynamically, the state machine would be different, especially when the AS is created.
For example, where the AS/ASP configuration data isn't created until Registration of the first ASP, the AS-INACTIVE state is entered directly on the first successful REG REQ from an ASP. Another example is where the AS/ASP configuration data isn't created until the first ASP successfully enters the ASP-ACTIVE state. In that case the AS-ACTIVE state is entered directly 🌈
Figure 6: AS State Transition Diagram
+----------+ one ASP trans to ACTIVE +-------------+
| AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE |
| |<--- | |
+----------+ \ +-------------+
^ | \ Tr Expiry, ^ |
| | \ at least one | |
| | \ ASP in ASP-INACTIVE | |
| | \ | |
| | \ | |
| | \ | |
one ASP | | all ASP \ one ASP | | Last ACTIVE
trans | | trans to \ trans to | | ASP trans to
to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE
ASP- | | \ ACTIVE | | or ASP-DOWN
INACTIVE| | \ | | (start Tr)
| | \ | |
| | \ | |
| v \ | v
+----------+ \ +-------------+
| | --| |
| AS-DOWN | | AS-PENDING |
| | | (queuing) |
| |<----------------------------| |
+----------+ Tr Expiry and no ASP +-------------+
in ASP-INACTIVE state
Tr = Recovery Timer4.3.3. M2UA Management Procedures for Primitives 🌷
Before an SCTP association gets established, the ASP state at both the SGP and the ASP is assumed to be ASP-DOWN.
Once the SCTP association is established (see Section 4.2.1) and assuming the local M2UA-User is ready, the local M2UA ASP Maintenance (ASPM) function starts the relevant procedures. It uses the ASP Up/ASP Down/ASP Active/ASP Inactive messages to tell the SGP what state the ASP is in (see Section 4.3.4) 📣
If the M2UA layer later gets an SCTP-COMMUNICATION_DOWN or SCTP-RESTART indication primitive from the SCTP layer underneath, it tells Layer Management by invoking the M-SCTP_STATUS indication primitive. The ASP state moves to ASP-DOWN.
For SCTP-COMMUNICATION_DOWN, the SCTP client MAY try to re-establish the SCTP association. This MAY be done by the M2UA layer automatically, or Layer Management MAY re-establish it using the M-SCTP_ESTABLISH request primitive 🔁
For an SCTP-RESTART indication at an ASP, the peer M2UA now sees the ASP as being in the ASP-DOWN state. If the ASP wants to recover, it must begin any recovery with the ASP-Up procedure. Recovery arc unlocked 🦋
4.3.4. ASPM Procedures for Peer-to-Peer Messages 💖
4.3.4.1 ASP Up Procedures 🎀
Okay so, once an ASP has successfully set up an SCTP association to an SGP, the SGP just waits for the ASP to send an ASP Up message 🦋. This is the ASP saying "hey, I'm here and available to the M2UA peer!" The ASP is always the one who starts 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 M2UA management function 💅.
When the SGP gets an ASP Up message and the remote ASP is in the ASP-DOWN state (and it's not locked out for local management reasons), the SGP marks that ASP as ASP-INACTIVE and tells Layer Management with an M-ASP_Up indication primitive ✨. If the SGP already knows, from current configuration data, which Application Servers the ASP is set up to operate in, the SGP updates the ASP state to ASP-INACTIVE in each AS it's a member of 💖.
Alternatively, the SGP may move the ASP into a pool of Inactive ASPs 🧚. That way it's ready for future configuration within Application Server(s), which gets decided in a later 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. No exceptions, bestie 🫶.
If for any local reason (e.g., management lock-out) the SGP can't respond with an ASP Up Ack message, it responds to the ASP Up message with an Error message with Reason Refused - Management Blocking 😭.
At the ASP, the ASP Up Ack message it receives is not acknowledged. Layer Management gets informed with an M-ASP_UP confirm primitive 🌈.
When the ASP sends an ASP Up message, it starts timer T(ack) ⏱️. If the ASP doesn't get a response to its 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 that 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 M2UA messages (e.g., ASP Active or REG REQ) 🙈. If the SGP receives any other M2UA 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 the remote ASP is internally in the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as an Error message ("Unexpected Message), and the remote ASP state changes to ASP-INACTIVE in all relevant Application Servers 👑.
If an ASP Up message is received and the remote ASP is already in the ASP-INACTIVE state, an ASP Up Ack message is returned and no further action is taken 🍓.
4.3.4.1.1 M2UA Version Control
If an ASP Up message with an unsupported version is received, the receiving end responds with an Error message, indicating the version the receiving node supports, and notifies Layer Management 🦋.
This is super useful when protocol version upgrades are happening in a network 🌸. A node upgraded to a newer version SHOULD support the older versions used on other nodes it talks to. Because ASPs initiate the ASP Up procedure, it's assumed that the Error message would normally come from the SGP ✨.
4.3.4.2 ASP Down Procedures 🌈
The ASP will send an ASP Down message to an SGP when it wants to be removed from service in all Application Servers it's a member of and stop receiving any MAUP 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 M2UA 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) to register within Application Servers, but hasn't unregistered from all of them before sending the ASP Down message, the SGP MUST consider the ASP as unregistered in all Application Servers it's still a member of 🫶.
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 it receives is not acknowledged. Layer Management gets 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 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 ✨.
When the ASP sends an ASP Down message, it starts timer T(ack) ⏱️. If the ASP doesn't get 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 that method, expiry of T(ack) results in an M-ASP_DOWN confirm primitive carrying a negative indication 😭.
4.3.4.3 ASP Active Procedures ✨
Okay so, bestie, once the ASP has gotten an ASP Up Ack from the SGP, it MAY send an ASP Active message to the SGP to say "hi, I'm ready to start processing traffic" 🦋 This can be kicked off by an M-ASP_ACTIVE request primitive from Layer Management, or the M2UA management function can just do it automatically 💅 Now, if the ASP wants to handle traffic for more than one Application Server over the same SCTP association, the ASP Active message(s) SHOULD carry a list of one or more Interface Identifiers so the SGP knows which Application Servers it's talking about 🎀 The ASP is totally allowed to leave all the Interface Identifiers out of a single ASP Active message, which means it's asking to become active in every Interface Identifier at once 🌈 You can also send several ASP Active messages to activate Application Servers one at a time or in little groups 🧚 And if an ASP Active message has no Interface Identifier parameter, the receiver has to already know, from configuration data, which Application Server(s) the ASP belongs to 🫶
Next up, for the Application Servers the ASP can actually activate, the SGP replies with one or more ASP Active Ack messages. These include the matching Interface Identifier(s) and reflect whatever Traffic Mode Type value was in the ASP Active message 💖 The Interface Identifier parameter MUST be included in the ASP Active Ack message(s) if the ASP Active message had any Interface Identifiers in it, no exceptions bestie 😭 Depending on the Traffic Mode Type in the request (or local config if there wasn't one), the SGP moves the ASP into the right ASP traffic state inside the Application Server(s) 🔥 Layer Management gets told with an M-ASP_Active indication. If the SGP gets any Data messages before it has received an ASP Active message, it MAY throw them away 💀 Once the SGP sends the ASP Active Ack, it's officially ready to send and receive traffic for those Interface Identifier(s) 👑 The ASP SHOULD NOT send MAUP messages for those Interface Identifier(s) before it gets an ASP Active Ack message, or it risks losing messages 🙈
Multiple ASP Active Ack messages MAY be sent in response to one ASP Active message with several Interface Identifiers, so the SGP can acknowledge different (sets of) Interface Identifiers independently 🍓 The SGP MUST send an Error message ("Invalid Interface Identifier") for every Interface Identifier value it can't successfully activate 😤
If an "out-of-the-blue" ASP Active message shows up (meaning the ASP never registered with the SG, or the SG has no static configuration data for that ASP), the message MAY be silently discarded 🫠
The SGP MUST send an ASP Active Ack message in response to a received ASP Active message from the ASP if the ASP is already marked in the ASP-ACTIVE state at the SGP 💜
At the ASP, the ASP Active Ack message it receives is not acknowledged itself. Layer Management gets informed with an M-ASP_ACTIVE confirm primitive 🌸 It's totally possible for the ASP to get Data message(s) before the ASP Active Ack, because the ASP Active Ack and Data messages from an SG may travel on different SCTP streams 🧚 Message loss is possible here, since the ASP doesn't consider itself in the ASP-ACTIVE state until it receives the ASP Active Ack message ⚠️
When the ASP sends an ASP Active message, it starts timer T(ack). If the ASP doesn't get a response to that ASP Active message within T(ack), the ASP MAY restart T(ack) and resend the ASP Active message(s) 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 the control of Layer Management. In that 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 M2UA layer: Override, Load share and Broadcast 🌈 When it's included, the Traffic Mode Type parameter in the ASP Active message says which traffic handling mode to use for a particular Application Server 💅 If the SGP decides the mode 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 isn't already known from configuration data, the mode from the first ASP Active message that moves the Application Server state to AS-ACTIVE MAY be used to set it 🫶
In Override mode, it's giving drama 👑 When an SGP gets an ASP Active message, ALL the traffic for that AS gets (re)directed to the ASP that sent it. 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 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 that gets this Notify MUST consider itself in the ASP-INACTIVE state now, if it isn't already aware of that through inter-ASP communication with the Overriding ASP 🫠
In Load-share mode, when an SGP gets an ASP Active message, traffic gets directed to the ASP that sent it, PLUS all the other ASPs that are currently active in the AS 🍓 How the SGP load-shares traffic across all the active ASPs is implementation dependent. It could be round-robin, for example, or based on information in the Data message (like the SLS in the Routing Label) 🧠
An SGP, when it gets an ASP Active message for the first ASP in a Load share AS, MAY choose not to direct traffic to that newly active ASP until it figures out there are enough resources to handle the expected load (for example, until there are "n" ASPs in state ASP-ACTIVE in the AS) 🌸
All ASPs within a load-sharing mode AS MUST be able to process any Data message received for the AS, so they can handle fail-over or balancing of the offered load 🛡️
In Broadcast mode, when an SGP gets an ASP Active message, traffic gets directed to the ASP that sent it, PLUS all the other ASPs that are currently active in the AS 📣 The SGP's algorithm for broadcasting traffic to all the active ASPs is a simple broadcast, where every message is sent to each of the active ASPs 🔊
An SGP, when it gets an ASP Active message for the first ASP in a Broadcast AS, MAY choose not to direct traffic to that newly active ASP until it figures out there are enough resources to handle the expected load (for example, until there are "n" ASPs in state ASP-ACTIVE in the AS) ✨
Whenever an ASP in a Broadcast mode AS becomes ASP-ACTIVE, the SGP MUST tag the first DATA message broadcast in each SCTP stream with a unique Correlation Id parameter 🎀 The point of this Correlation Id is to let the newly active ASP line up its processing of traffic in each ordered stream with the other ASPs in the broadcast group 🫶
4.3.4.4 ASP Inactive Procedures ⏸️
okay so when an ASP wants to stop getting traffic within an AS, it sends an ASP Inactive message to the SGP 🫶 This can be started at the ASP by an M-ASP_INACTIVE request primitive from Layer Management, or it MAY be started automatically by an M2UA management function 🧚 If one ASP is handling traffic for more than one Application Server over the same SCTP association, the ASP Inactive message holds one or more Interface Identifiers so everyone knows which Application Servers it's about 💅 If the ASP Inactive message has no Interface Identifier parameter, the receiver must know from configuration data which Application Servers the ASP belongs to, and then move the ASP to the ASP-INACTIVE state in all of them 🔥
Now the Override mode AS is giving main character energy 👑 Another ASP has already taken over the traffic with an ASP Active ("Override") message, so the ASP sending the ASP Inactive message is already treated by the SGP as being in the state ASP-INACTIVE. The SGP sends an ASP Inactive Ack message back to the ASP, but only after making sure all traffic to that ASP has stopped 🦋
For a Load-share mode AS, the SGP moves the ASP to the ASP-INACTIVE state, and the AS traffic gets re-allocated across the other ASPs that are still in the state ASP-ACTIVE, following whatever load-sharing algorithm the AS is already using 🌈 A Notify message ("Insufficient ASP resources active in AS") MAY be sent to all inactive ASPs if needed. The ASP Inactive Ack message is sent to the ASP once all traffic is halted, and Layer Management gets told with an M-ASP_INACTIVE indication primitive ✨
Broadcast mode AS is pretty similar 🍓 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 needed. The ASP Inactive Ack message goes out to the ASP after all traffic is halted, and Layer Management is informed with an M-ASP_INACTIVE indication primitive 💜
If an ASP Inactive message has several Interface Identifiers, the SGP is allowed to send multiple ASP Inactive Ack messages in response 🌸 This lets it acknowledge different sets of Interface Identifiers on its own schedule. For every invalid or not configured Interface Identifier value in a received ASP Inactive message, the SGP sends an Error message ("Invalid Interface Identifier") 🙈
The SGP MUST send an ASP Inactive Ack message in response to a received ASP Inactive message from the ASP when the ASP is already marked as ASP-INACTIVE at the SGP. No exceptions, bestie 😭
On the ASP side, the ASP Inactive Ack message it receives is not acknowledged itself 🫶 Layer Management is informed with an M-ASP_INACTIVE confirm primitive. If the ASP gets an ASP Inactive Ack without having sent an ASP Inactive message, the ASP SHOULD now consider itself to be in the ASP-INACTIVE state. And if the ASP was previously in the ASP-ACTIVE state, the ASP SHOULD then start the procedures to put itself back into its previous state 🦋
When the ASP sends an ASP Inactive message, it starts timer T(ack) ⏱️ If no response to that ASP Inactive message arrives within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive messages until it gets 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 the control of Layer Management. In that method, when T(ack) expires, you get 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 of the ASPs in the AS that are in the state ASP-INACTIVE 🚨 The SGP SHOULD start buffering the incoming messages for T(r) seconds, and after that, 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 T(r) expires, the buffered traffic is directed to that ASP and the timer is canceled. If T(r) expires, the AS is moved to the AS-INACTIVE state 😭
4.3.4.5 Notify Procedures 📣
A Notify message that reflects a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state 🔔 It carries 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 happened because of an ASP failure or because an ASP State Management (ASPSM) / ASP Traffic Management (ASPTM) message came in. In that second case, the Notify message MUST be sent after any related acknowledgment messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack) 💅
Here's the tea 🍵 If a Notify ("AS-PENDING") message is sent by an SGP that now has no ASPs active to service the traffic, or if a Notify ("Insufficient ASP resources active in AS") message MUST be sent in Load share or Broadcast mode, the Notify message does not explicitly force the receiving ASP(s) to become active. The ASPs stay in control of what traffic action gets taken, and when 👑
If a Notify message doesn't contain an Interface Identifier parameter, the receiver must know from configuration data which Application Servers the ASP belongs to, and then take the appropriate action in each AS 🧚
4.3.4.6 Heartbeat Procedures 💓
The optional Heartbeat procedures MAY be used over transport layers that don't have their own heartbeat mechanism for detecting loss of the transport association (so, anything other than SCTP) 🌊
Either M2UA peer may optionally send Heartbeat messages periodically, subject to a provisionable timer T(beat) 💜 When an M2UA peer receives a Heartbeat message, it MUST respond with a Heartbeat Ack message 🫶
If no Heartbeat Ack message (or any other M2UA message) comes in from the M2UA peer within 2*T(beat), the remote M2UA peer is considered unavailable 😭 Transmission of Heartbeat messages stops, and the signalling process SHOULD attempt to re-establish communication if it's configured as the client for the disconnected M2UA peer 🔄
The Heartbeat message may optionally include an opaque Heartbeat Data parameter, and that parameter MUST be echoed back unchanged in the related Heartbeat Ack message 🦋 When the sender looks at what came back in the Heartbeat Ack, it MAY choose to treat the remote M2UA peer as unavailable 🎀 The contents and format of the Heartbeat Data parameter are 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 time stamp mechanism (to evaluate delays) 🧠
Note: Heartbeat related events are not shown in Figure 5 "ASP state transition diagram" 👀
4.4. Link Key Management Procedures 🔑
The Interface Identifier Management procedures are optional. They can be used to support automatic allocation of Signalling Terminals or Signalling Data Links [2][3] 🌸
4.4.1. Registration 📝
An ASP MAY dynamically register with an SGP as an ASP within an Application Server for individual Interface Identifier(s) using the REG REQ message 🫶 A Link Key parameter in the REG REQ specifies the parameters associated with the Link Key.
The SGP looks at the contents of the received Link Key parameters (SDLI and SDTI) and compares them with the Interface Identifiers already provisioned 🔍 If the received Link Key matches an existing SGP Link Key entry, and the ASP is not currently 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 Link Key doesn't exist yet and the received Link Key data is valid and unique, an SGP supporting dynamic configuration MAY authorize creating a new Interface Identifier and related Application Server, and add the ASP to the new AS ✨ Either way, the SGP sends a Registration Response message back to the ASP, containing the same Local-LK-Identifier as in the initial request, a Registration Result "Successfully Registered", and the Interface Identifier. A unique method of Interface Identifier valid assignment at the SG/SGP is implementation dependent, but it MUST be guaranteed to be unique for each Application server or Link Key served by SGP 💅
If the SGP decides the received Link Key data is invalid, or contains invalid parameter values, it returns a Registration Response message to the ASP with a Registration Result "Error - Invalid Link Key", "Error - Invalid SDTI", or "Error - Invalid SDLI", as appropriate 🙅♀️
If the SGP decides the Link Key parameter overlaps with an existing Link Key entry, it returns a Registration Response message to the ASP with a Registration Status of "Error - Overlapping (Non-Unique) Link Key". An incoming signalling message received at an SGP cannot match against more than one Link Key 🚫
If the SGP doesn't authorize the registration request, it returns a REG RSP message to the ASP containing the Registration Result "Error - Permission Denied" 🙈
If the SGP determines a received Link Key doesn't currently exist and the SGP does not support dynamic configuration, it returns a Registration Response message to the ASP containing the Registration Result "Error - Link Key not Provisioned" 📭
If the SGP determines a received Link Key doesn't currently exist and the SGP supports dynamic reconfiguration but doesn't have the capacity to add new Link Key and Application Server entries, it returns a Registration Response message to the ASP containing the Registration Result "Error - Insufficient Resources" 🫠
An ASP MAY register multiple Link Keys at once by including several Link Key parameters in a single REG REQ message 🍓 The SGP MAY respond to each registration request in a single REG RSP message, with the success or failure result for each Link Key in its own Registration Result parameter. Alternatively, the SGP MAY respond with multiple REG RSP messages, each carrying one or more Registration Result parameters. The ASP uses the Local-LK-Identifier parameter to match the requests with the responses 🧚
4.4.2 Deregistration ✨
okay so an ASP MAY totally de-register itself with an SGP as an ASP inside an Application Server, for specific Interface Identifier(s), using the DEREG REQ message 💅. The Interface Identifier parameter in the DEREG REQ tells the SGP exactly which Interface Identifier to let go 🦋.
The SGP checks the Interface Identifier parameter it gets and makes sure the ASP is actually registered in the Application Server(s) linked to those Interface Identifier(s) 🔍. If that checks out, the ASP gets de-registered as an ASP in the related Application Server 🎀.
Deregistering doesn't automatically mean the Link Key and Application Server config data get deleted at the SGP, bestie 🙈. If other ASPs are still hanging out in the Application Server, the Link Key data CANNOT be deleted 🚫. But if a Deregistration leaves no ASPs in an Application Server, an SGP MAY delete the Link Key data 🧹.
The SGP confirms the de-registration by sending a DEREG RSP back to the ASP that asked 💌. The outcome lives in the Deregistration Result parameter, which shows success or failure, plus the cause if it failed 📋.
An ASP MAY de-register several Interface Identifier(s) in one go by putting multiple Interface Identifiers into a single DEREG REQ message 🍓. The SGP MUST answer each deregistration request in a single DEREG RSP message, and it gives each Interface Identifier its own Deregistration Result parameter with the success or failure result 👑.
5.0 Examples of MTP2 User Adaptation (M2UA) Procedures 🌈
5.1 Establishment of associations between SGP and MGC examples 🧚
5.1.1 Single ASP in an Application Server (1+0 sparing) ✨
this scenario is giving us the M2UA message flows for setting up traffic between an SGP and an ASP, where there's only one ASP in the AS (no backup) 💖. It's assumed the SCTP association is already set up 🫶.
SGP ASP1
|
|<---------ASP Up----------|
|--------ASP Up Ack------->|
| |
|<-------ASP Active--------|
|------ASP Active Ack----->|
| |
|------NTFY(AS-ACTIVE)---->|5.1.2 Single ASP in an Application Server (1+0 sparing) with Dynamic Registration 🦋
this one is basically the same as Section 5.1.1, except the Interface Identifier(s) get allocated automatically through dynamic registration 🪄.
SGP ASP1
|
|<---------ASP Up----------|
|--------ASP Up Ack------->|
| |
|<--------REG REQ----------|
|------REG REQ RESP------->|
| |
|<-------ASP Active--------|
|------ASP Active Ack----->|
| |
|------NTFY(AS-ACTIVE)---->|5.1.3 Two ASPs in Application Server (1+1 sparing) 👯♀️
this scenario shows the M2UA message flows for traffic between an SGP and two ASPs in the same Application Server 💅. ASP1 is set to be active, and ASP2 is set to be standby in case ASP1 has a communication failure or gets withdrawn from service 🛟. ASP2 MAY act as a hot, warm, or cold standby, depending on how much call/transaction state ASP1 and ASP2 share, or how well they can talk about call state when things fail or get withdrawn 🔥.
SGP ASP1 ASP2
| | |
|<--------ASP Up----------| |
|-------ASP Up Ack------->| |
| | |
|<-----------------------------ASP Up----------------|
|----------------------------ASP Up Ack------------->|
| | |
| | |
|<-------ASP Active-------| |
|-----ASP Active Ack----->| |
| | |
| | |
|-----NTFY(AS-ACTIVE)---->| |
| | |
|------------------NTFY(AS-ACTIVE)------------------>|5.2 ASP Traffic Fail-over Examples 🔄
5.2.1 (1+1 Sparing, withdrawal of ASP, backup Override) 💀
picking up from the example in Section 5.1.2, let's say 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)------------------>|
| | |so in this case, the SGP tells ASP2 that the AS has moved to the AS-PENDING state 🫧. ASP2 sends ASP Active to bring the AS back to the AS-ACTIVE state 🙌. But if ASP2 doesn't send the ASP Active message before T(r) expires, the SGP would send a NOTIFY (AS-DOWN) 😬.
Note: if the SGP detects loss of the M2UA peer (through detection of an SCTP failure), the initial SGP-ASP1 ASP Inactive message exchange would not happen 🙈.
SGP ASP1 ASP2
| | |
(detects SCTP failure)
|------------------NTFY(AS-PENDING)----------------->|
| | |
|<------------------------------ ASP Active----------|
|-----------------------------ASP Active Ack-------->|
| | |
|------------------NTFY(AS-ACTIVE)------------------>|
| | |5.2.2 (1+1 Sparing, backup Override) 🦹♀️
picking up from Section 5.1.2 again, now ASP2 wants to override ASP1 and take over the traffic 👑:
SGP ASP1 ASP2
| | |
|<-------------------------------ASP Active----------|
|-----------------------------ASP Active Ack-------->|
|----NTFY(Alt ASP-Act)--->| |
| | |in this case, the SGP tells ASP1 that an alternative ASP has overridden it 🥲.
5.3 SGP to MGC, MTP Level 2 to MTP Level 3 Boundary Procedures 🧩
when the M2UA layer on the ASP has a MAUP message to send to the SGP, it does the following:
- Determine the correct SGP 🎯
- Find the SCTP association to the chosen SGP 🔗
- Determine the correct stream in the SCTP association based on the SS7 link 🌊
- Fill in the MAUP message, fill in M2UA Message Header, fill in Common Header 📝
- Send the MAUP message to the remote M2UA peer in the SGP, over the SCTP association 🚀
when the M2UA layer on the SGP has a MAUP message to send to the ASP, it does the following:
- Determine the AS for the
Interface Identifier🗺️ - Determine the Active ASP (SCTP association) within the AS ⭐
- Determine the correct stream in the SCTP association based on the SS7 link 🌊
- Fill in the MAUP message, fill in M2UA Message Header, fill in Common Header 📝
- Send the MAUP message to the remote M2UA peer in the ASP, over the SCTP association 🚀
5.3.1 SS7 Link Alignment 🌸
the MGC can ask for a SS7 link to be brought into alignment using the normal or emergency procedure [2][3] 💁♀️. Here's the message flow for bringing a SS7 link in-service using the normal alignment procedure:
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
<----Start Req---|<---Establish Req----|<----Start Req------
---In Serv Ind-->|----Establish Cfm--->|----In Serv Ind---->and here's the message flow for bringing a SS7 link in-service using the emergency alignment procedure 🚨:
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
<----Emer Req----|<--State Req (STATUS_EMER_SET)----|<----Emer Req---
-----Emer Cfm--->|---State Cfm (STATUS_EMER_SET)--->|----Emer Cfm---->
<---Start Req----|<-------Establish Req-------------|<---Start Req----
---In Serv Ind-->|--------Establish Cfm------------>|---In Serv Ind-->5.3.2 SS7 Link Release 🛑
the MGC can ask for a SS7 link to be taken out-of-service 🙅♀️. It uses the Release Request message, like this:
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
<-----Stop Req-----|<---Release Req------|<-----Stop Req------
--Out of Serv Ind->|----Release Cfm----->|--Out of Serv Ind-->the SGP can also autonomously indicate that a SS7 link has gone out-of-service, like so 🫣:
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
--Out of Serv->|----Release Ind----->|--Out of Serv-->5.3.3 Set and Clear Local Processor Outage 🫠
the MGC can set a Local Processor Outage condition 🛠️. It uses the State Request message, as shown below:
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
<----LPO Req----|<---State Req (STATUS_LPO_SET)----|<----LPO Req---
-----LPO Cfm--->|----State Cfm (STATUS_LPO_SET)--->|----LPO Cfm---->and the MGC can clear a Local Processor Outage condition too 🧹. It uses the State Request message again, like this:
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
<---LPO Req---|<---State Req (STATUS_LPO_CLEAR)----|<----LPO Req---
----LPO Cfm-->|----State Cfm (STATUS_LPO_CLEAR)--->|----LPO Cfm---->5.3.4 Notification of Remote Processor Outage 📣
the SGP can indicate that the Remote has entered or exited the Processor Outage condition for a SS7 link 🌙. It uses the State Indication message, as shown below:
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
----RPO Ind---->|----State Ind (EVENT_RPO_ENTER)-->|-----RPO Ind---->
-RPO Rcvr Ind-->|----State Ind (EVENT_RPO_EXIT)--->|--RPO Rcvr Ind-->5.3.5 Notification of SS7 Link Congestion ⚠️
okay so the SGP can tell everyone when an SS7 link gets congested 🚦 it does this with the Congestion Indication message, and it's giving very clear vibes 💅
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
----Cong Ind---->|--------Cong Ind (STATUS)------->|----Cong Ind---->
-Cong Cease Ind->|--------Cong Ind (STATUS)------->|-Cong Cease Ind->5.3.6 SS7 Link Changeover 🔄
bestie, here's what an error free changeover looks like ✨ in this example there are three messages sitting in the retransmission queue that need to be fetched back 📦
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---
(seq_num = 0)
-Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm-->
(seq_num = BSN)
<-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req---
(seq_num = FSN)
-Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm-->
(seq_num = 0)
-Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind-->
-Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind-->
-Rtrv Msg Ind->|---------Retrieval Ind ------->|---Rtrv Msg Ind-->
-Rtrv Compl Ind->|----Retrieval Compl Ind ---->|-Rtrv Compl Ind-->The number of Retrieval Indications depends on how many messages from the retransmit queue got requested 🙈 Only one Retrieval Complete Indication SHOULD be sent, so don't spam it 💅
next up is what happens with an error retrieving the BSN 😬
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---
-BSN Not Rtrv->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---BSN Not Rtrv-->
(seq_num = -1)and this one is an error retrieving the messages 💀
<-Rtrv BSN Req-|<--Rtrv Req (ACTION_RTRV_BSN)--|<--Rtrv BSN Req---
-Rtrv BSN Cfm->|---Rtrv Cfm (ACTION_RTRV_BSN)->|---Rtrv BSN Cfm-->
(seq_num = BSN)
<-Rtrv Msg Req-|<-Rtrv Req (ACTION_RTRV_MSGS)--|<--Rtrv Msg Req---
(seq_num = FSN)
-Rtrv Msg Cfm->|--Rtrv Cfm (ACTION_RTRV_MSGS)->|---Rtrv Msg Cfm-->
(seq_num = -1)and finally, a request to drop messages (clear the retransmission buffers) 🧹
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
-Clr RTB Req----|<-StateReq (STATUS_CLEAR_RTB)--|<--Clr RTB Req-----
-Clr RTB Req--->|-StateCfm (STATUS_CLEAR_RTB)-->|---Clr RTB Req---->5.3.7 Flush and Continue 🌊
here's the message flow for a request to flush buffers 🫧
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
<--Flush Req----|<-State Req (STATUS_FLUSH_BUFS)--|<---Flush Req--
---Flush Cfm--->|--State Cfm (STATUS_FLUSH_BUFS)->|---Flush Cfm-->and this is the flow for a request to continue ▶️
MTP2 M2UA M2UA MTP3
SGP SGP ASP ASP
<---Cont Req----|<--State Req (STATUS_CONTINUE)---|<---Cont Req---
----Cont Cfm--->|---State Cfm (STATUS_CONTINUE)-->|----Cont Cfm-->5.3.8 Auditing of SS7 link state 🔍
sometimes the ASP needs to audit the current state of an SS7 link 👀 the flows below show the request and all the possible responses, so you're never caught off guard 💖
here's the one where the SS7 link is out-of-service 📴
MTP2 M2UA M2UA MGMT
SGP SGP ASP ASP
|<----State Req (STATUS_AUDIT)----|<----Audit-------
MTP3
ASP
|-----------Release Ind---------->|-Out of Serv Ind->
MGMT
ASP
|-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm--->and this one is in-service ✅
MTP2 M2UA M2UA MGMT
SGP SGP ASP ASP
|<----State Req (STATUS_AUDIT)----|<----Audit-------
MTP3
ASP
|-----------Establish Cfm-------->|---In Serv Ind-->
MGMT
ASP
|-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm--->here it's in-service but congested 🚦
MTP2 M2UA M2UA MGMT
SGP SGP ASP ASP
|<----State Req (STATUS_AUDIT)----|<----Audit-------
MTP3
ASP
|-----------Establish Cfm-------->|---In Serv Ind-->
|----------Congestion Ind-------->|---Cong Ind----->
MGMT
ASP
|-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm--->and last but not least, in-service but in Remote Processor Outage 🫠
MTP2 M2UA M2UA MGMT
SGP SGP ASP ASP
|<----State Req (STATUS_AUDIT)----|<---Audit Req----
MTP3
ASP
|-----------Establish Ind-------->|---In Serv Ind-->
|---State Ind (EVENT_RPO_ENTER)-->|----RPO Enter--->
MGMT
ASP
|-----State Cfm (STATUS_AUDIT)--->|----Audit Cfm--->6.0 Timer Values ⏱️
the recommended default values for M2UA timers are 🎀
T(r) 2 seconds
T(ack) 2 seconds
T(beat) Heartbeat Timer 30 seconds7.0 Security Considerations 🔐
okay, this part is serious bestie 😭 M2UA is designed to carry signalling messages for telephony services, so it has to look out for several parties at once: the end users of the services, the network providers, and the applications involved 🫶 M2UA MUST involve the security needs of all of them. Extra requirements MAY come from local regulation too. Those needs overlap a bit, but any security solution SHOULD fulfill all of the different parties' needs. no pressure 💀
7.1 Threats 🕵️
there is no quick fix or one-size-fits-all solution for security 🙅♀️ as a transport protocol, M2UA has these security objectives:
- Availability of reliable and timely user data transport.
- Integrity of user data transport.
- Confidentiality of user data.
M2UA runs on top of SCTP. SCTP [8] gives it some transport related security features, like:
- Blind Denial of Service Attacks
- Flooding
- Masquerade
- Improper Monopolization of Services
when M2UA runs in a professionally managed corporate or service provider network, it's reasonable to expect that network has an appropriate security policy framework 🏢 The "Site Security Handbook" [13] SHOULD be consulted for guidance 📖
when the network M2UA runs in involves more than one party, it MAY NOT be reasonable to expect that all of them have implemented security in a sufficient manner 😬 in that case, it is recommended that IPSEC is used to ensure confidentiality of user payload. Consult [14] for more information on configuring IPSEC services.
7.2 Protecting Confidentiality 🤫
particularly for mobile users, the confidentiality requirement MAY include masking IP addresses and ports 🎭 in that case application level encryption is not sufficient, so IPSEC ESP SHOULD be used instead. Regardless of which level does the encryption, the IPSEC ISAKMP service SHOULD be used for key management 🔑
8.0 IANA Considerations 📋
8.1 SCTP Payload Protocol Identifier 🏷️
a request will be made to IANA to assign an M2UA value for the Payload Protocol Identifier in the SCTP Payload Data chunk ✨ the following SCTP Payload Protocol Identifier has been registered:
M2UA "2"every SCTP Data chunk includes the SCTP Payload Protocol Identifier, which tells you what protocol SCTP is carrying 📦 SCTP doesn't use this identifier directly, but certain network entities MAY use it to identify the type of information in a Data chunk 👀
the User Adaptation peer MAY use the Payload Protocol Identifier to work out extra info about the data SCTP hands it 🧚
8.2 M2UA Protocol Extensions 🧩
this protocol can also be extended through IANA in three ways 💅
- through definition of additional message classes,
- through definition of additional message types, and
- through definition of additional message parameters.
defining new message classes, types and parameters is a core part of SIGTRAN adaptation layers 🌈 so IANA assigns these extensions through an IETF Consensus action, as defined in [RFC2434].
the proposed extension must in no way adversely affect the general working of the protocol 🙏
8.2.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 message class.
- (b) A detailed description of the purpose of the message class.
8.2.2 IETF Defined Message Types 🎀
documentation for the message type MUST contain 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 of 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 it doesn't support, it MUST respond with an Error (ERR) message with an Error Code of Unsupported Message Type 🫶
8.2.3 IETF-defined TLV Parameter Extension ✨
Okay bestie, so if you're documenting a message parameter, you MUST include the following info 💅:
- (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.1.5. 🎀
- (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 type. 🔥
9.0 Acknowledgments 🫶
The authors want to give a huge thank you to Tom George (Alcatel) for contributing text and effort to the specification. He's literally a legend 👑
The authors also want to thank John Loughney, Neil Olson, Michael Tuexen, Nikhil Jain, Steve Lorusso, Dan Brendes, Joe Keller, Heinz Prantner, Barry Nagelberg, Naoto Makinae, Joyce Archibald, Mark Kobine, Nitin Tomar, Harsh Bhondwe and Karen King for their valuable comments and suggestions. Everyone who helped make this happen is iconic 🌸💖
10.0 References 📚
10.1 Normative
[1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling System No. 7 (SS7)'
[2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - Message Transfer Part (MTP)'
[3] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part'
[4] Bellcore GR-246-CORE 'Bell Communications Research Specification of Signalling System Number 7', Volume 1, December 1995
[5] Telecommunication Technology Committee (TTC) Standard JT-Q704, Message Transfer Part Signaling Network Functions, April 28, 1992.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[7] Coded Character Set--7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986.
10.2 Informative
[8] 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.
[9] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Architectural Framework for Signalling Transport", RFC 2719, October 1999.
[10] ITU-T Recommendation Q.2140, 'B-ISDN ATM Adaptation Layer', February 1995
[11] ITU-T Recommendation Q.2210, 'Message transfer part level 3 functions and messages using the services of ITU-T Recommendation Q.2140', August 1995
[12] ITU-T Recommendation Q.751.1, 'Network Element Management Information Model for the Message Transfer Part', October 1995
[13] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[14] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
Appendix A: Signalling Network Architecture 🧚
A Signalling Gateway will support the transport of MTP2-User signalling traffic received from the SS7 network to one or more distributed ASPs (e.g., MGCs). Clearly, the M2UA protocol description cannot in itself meet any performance and reliability requirements for such transport. A physical network architecture is required, with data on the availability and transfer performance of the physical nodes involved in any particular exchange of information. However, the M2UA protocol is flexible enough to allow its operation and management in a variety of physical configurations that will enable Network Operators to meet their performance and reliability requirements. ✨
To meet the stringent SS7 signalling reliability and performance requirements for carrier grade networks, these Network Operators should ensure that there is no single point of failure provisioned in the end-to-end network architecture between an SS7 node and an IP ASP. 🔥
Depending of course on the reliability of the SGP and ASP functional elements, this can typically be met by spreading SS7 links in a SS7 linkset [1] across SGPs or SGs, the provision of redundant QoS-bounded IP network paths for SCTP Associations between SCTP End Points, and redundant Hosts. The distribution of ASPs within the available Hosts is also important. For a particular Application Server, the related ASPs MAY be distributed over at least two Hosts. 🌈
An example of logical network architecture relevant to carrier-grade operation in the IP network domain is shown in Figure 7 below:
************** **************
* ********__*______________________________*__******** * Host1
SG1 * * SGP1 *__*________________ _______*__* ASP1 * *
* ******** * | | * ******** *
* . * | | * *
* . * | | **************
************** | |
| |
************** | |
* ********__*______________________|
SG2 * * SGP2 *__*________ |
* ******** * | |
* . * | |
* . * | |
************** | | **************
| |_____________*__******** * Host2
|_____________________*__* ASP2 * *
. * ******** *
. SCTP Associations * *
. **************
.
.
.
Figure 7: Logical Model ExampleTo avoid a single point of failure, it is recommended that a minimum of two ASPs be configured in an AS list, resident in separate hosts and, therefore, available over different SCTP associations. For example, in the network shown in Figure 7, all messages for the Interface Identifiers could be sent to ASP1 in Host1 or ASP2 in Host2. The AS list at SGP1 might look like the following:
Interface Identifiers - Application Server #1
ASP1/Host1 - State = Active
ASP2/Host2 - State = InactiveIn this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming message for the Interface Identifiers registered. ASP2 in Host2 would normally be brought to the active state upon failure of ASP1/Host1. In this example, both ASPs are Inactive or Active, meaning that the related SCTP association and far-end M2UA peer is ready. 💜
For carrier grade networks, Operators should ensure that under failure or isolation of a particular ASP, stable calls or transactions are not lost. This implies that ASPs need, in some cases, to share the call/-transaction state or be able to pass the call/transaction state between each other. Also, in the case of ASPs performing call processing, coordination MAY be required with the related Media Gateway to transfer the MGC control for a particular trunk termination. However, this sharing or communication is outside the scope of this document. 🦋
11.0 Authors' Addresses 💌
Ken Morneault
Cisco Systems Inc.
13615 Dulles Technology Drive
Herndon, VA. 20171
USA
Phone: +1-703-484-3323
EMail: kmorneau@cisco.comRam Dantu, Ph.D.
NetRake Corporation
3000 Technology Drive
Plano, TX 75074
USA
Phone: +1-214-291-1111
EMail: rdantu@netrake.comGreg Sidebottom
Signatus Technologies
Kanata, Ontario, Canada
EMail: greg@signatustechnologies.comBrian Bidulock
OpenSS7 Corporation
1469 Jeffreys Crescent
Edmonton, AB T6L 6T1
Canada
Phone: +1-780-490-1141
EMail: bidulock@openss7.orgJacob Heitz
Lucent Technologies
1701 Harbor Bay Parkway
Alameda, CA, 94502
USA
Phone: +1-510-747-2917
EMail: jheitz@lucent.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌷
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society, you're a whole vibe 🦋
📦 where this page comes from
- ietf: rfc3331 2002-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms