Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
obsoletes
- rfc-3332 — Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
Extracted elements (30)
M3UA deliberately does not impose the 272-octet Signalling Information Field (SIF) limit from SS7 MTP Level 2, since larger blocks can be handled natively by M3UA/SCTP without upper-layer segmentation or reassembly. However, when an SG interworks with an SS7 network that does not support larger blocks, the SG must enforce the 272-octet constraint to prevent ISUP/SCCP fragmentation.
Network Appearance has only local significance between the SGP and ASP rather than being globally meaningful. This design allows the same physical SS7 network context to be represented by different Network Appearance values at different SGPs, accommodating the common scenario where a single ASP is connected to multiple SGPs for redundancy.
SCTP is the recommended underlying transport because it provides explicit packet-oriented delivery, sequenced multi-stream delivery, optional multiplexing, network-level fault tolerance through multi-homing, resistance to flooding and masquerade attacks, and path MTU-based data segmentation. These features collectively make SCTP superior to TCP for SS7 signalling transport over IP.
Under limited scenarios — such as back-to-back connections without redundancy requirements where SCTP-specific features are unnecessary — TCP MAY be used as the underlying transport protocol instead of SCTP. In all other deployments SCTP is strongly recommended.
All fields in an M3UA message MUST be transmitted in network byte order (big-endian), unless otherwise stated.
MTP3 management messages (such as TFPs or TFAs received from the SS7 network) MUST NOT be encapsulated as Payload Data and sent between SG and ASP. The SG MUST terminate these messages and generate appropriate M3UA SSNM messages instead.
Routing Keys SHOULD be unique such that each received SS7 signalling message SHOULD have a full or partial match to a single routing result. In the n+k redundancy model, traffic SHOULD be sent only after 'n' ASPs are active.
The DATA (Payload) message MUST NOT be sent on SCTP stream 0. ASPSM, MGMT, and RKM message classes SHOULD be sent on stream 0, except for BEAT, BEAT ACK, and NTFY messages. SSNM, ASPTM classes, and BEAT, BEAT ACK, and NTFY messages can be sent on any stream.
The total length of a TLV parameter (Tag + Length + Value) MUST be a multiple of 4 octets. A sender MUST NOT pad with more than 3 octets. The receiver MUST ignore padding octets.
To avoid redundant SCTP associations, one peer (client) SHOULD be designated to initiate the SCTP association. By default, the ASP acts as SCTP client and SHOULD initiate the association to the SGP, which acts as server. In IPSP-to-IPSP communication, one IPSP SHOULD be similarly designated as the client.
When the optional Network Appearance parameter is present in the DATA message, it MUST be the first parameter in the message, because it defines the format of the Protocol Data field that follows.
Where multiple Routing Keys and Routing Contexts are used across a common SCTP association, the Routing Context MUST be included in DATA messages to identify the traffic flow and assist internal distribution. In DUNA/SSNM messages, Routing Context(s) MUST be sent to identify the concerned traffic flows when multiple Routing Contexts share an association.
ASP State Maintenance messages manage the ASP lifecycle: ASP Up (ASPUP, type 1) and its acknowledgement ASP Up Ack (type 4), ASP Down (ASPDN, type 2) and ASP Down Ack (type 5), Heartbeat (BEAT, type 3) and Heartbeat Ack (BEAT ACK, type 6) for monitoring association health. ASP Traffic Maintenance messages ASP Active (ASPAC) and ASP Inactive (ASPIA) with their acknowledgements control traffic flow.
M3UA defines nine message classes: Management/MGMT (0), Transfer (1), SS7 Signalling Network Management/SSNM (2), ASP State Maintenance/ASPSM (3), ASP Traffic Maintenance/ASPTM (4), and Routing Key Management/RKM (9). Message classes 5–8 are reserved for other SIGTRAN adaptation layers; 10–127 are reserved by IETF; 128–255 are for IETF-defined extensions.
M3UA is an adaptation layer that transports SS7 MTP3-User signalling (ISUP, SCCP, TUP, etc.) over IP using SCTP between Signalling Gateways (SGs) and Application Server Processes (ASPs), or between IP-based applications (IPSPs). It extends MTP3 service primitives to IP-resident applications while providing seamless interworking with the SS7 network.
Routing Key Management (RKM) messages provide optional dynamic provisioning of Routing Keys at an SGP: Registration Request (REG REQ, type 1) lets an ASP register a Routing Key and receive an assigned Routing Context; Registration Response (REG RSP, type 2) conveys the result; Deregistration Request (DEREG REQ, type 3) removes a Routing Key; Deregistration Response (DEREG RSP, type 4) confirms the result.
SSNM messages convey SS7 network management status from an SGP to ASPs: Destination Unavailable (DUNA, type 1), Destination Available (DAVA, type 2), Destination State Audit (DAUD, type 3), Signalling Congestion (SCON, type 4), Destination User Part Unavailable (DUPU, type 5), and Destination Restricted (DRST, type 6). These parallel MTP-PAUSE, MTP-RESUME, and MTP-STATUS primitives in an SS7 node.
The Affected Point Code parameter (Tag 0x0012) in SSNM messages encodes a list of destination point codes as 32-bit fields each consisting of an 8-bit Mask followed by a 24-bit Point Code value. Point Codes less than 24 bits (e.g., ITU 14-bit) are left-padded to the 24-bit boundary. The Mask field enables aggregate addressing of multiple Point Codes.
The Network Appearance parameter (Tag 0x0200, 32-bit unsigned integer) is a locally significant reference shared between an SG and an AS that identifies the SS7 network context, implicitly defining the Point Code format, Network Indicator value, and MTP3 variant. Different SGPs may assign different Network Appearance values to the same SS7 network context.
The Routing Context parameter (Tag 0x0006, 32-bit unsigned integer) uniquely identifies a Routing Key — a set of SS7 parameters (e.g., DPC, OPC, SI) used to filter and route traffic to a specific Application Server. There is a strict 1:1 relationship between a Routing Context and a Routing Key, and the Routing Context functions as an index into the node's Message Distribution Table.
IANA has assigned an SCTP Payload Protocol Identifier for M3UA, used in SCTP DATA chunks to identify M3UA payload at the receiving peer.
IANA has assigned TCP and SCTP port number 2905 for M3UA peer-to-peer communication.
IANA maintains three M3UA protocol extension registries: IETF-Defined Message Classes (values 10–127 reserved, 128–255 for extensions), IETF-Defined Message Types per class (values 2–127 reserved, 128–255 for extensions), and IETF-Defined Parameter Tags (0x0214 to 0xfffe reserved; 0xffff for extensions). An RFC is required to assign any IETF-reserved values.
M3UA peers SHOULD use IPsec to provide integrity, confidentiality, and mutual authentication of M3UA signalling traffic. Without transport-level security, M3UA signalling between SGs and ASPs is vulnerable to eavesdropping, spoofing, and denial-of-service attacks that could compromise SS7 signalling infrastructure accessible through the IP domain.
The M3UA architecture introduces a boundary between the SS7 and IP domains at the Signalling Gateway. Unauthorized access to ASPs or SGPs through the IP network could allow an attacker to inject, modify, or suppress SS7 signalling messages, potentially causing call disruption, fraudulent call routing, or disclosure of network topology information.
An Application Server (AS) has four states: AS-Down (no constituent ASPs are active or inactive), AS-Inactive (at least one ASP inactive, none active), AS-Active (at least one ASP active and handling traffic), and AS-Pending (previously active, all ASPs gone inactive/down, a recovery timer is running). Transitions are driven entirely by changes in the active/inactive/down status of constituent ASPs.
An ASP/IPSP operates in three states: ASP-Down (SCTP association absent or ASP not activated), ASP-Inactive (SCTP association established and ASP Up exchanged, but not processing traffic), and ASP-Active (processing traffic for one or more Application Servers). Transitions are triggered by ASP Up/Down/Active/Inactive messages and their acknowledgements, or by loss of the SCTP association.
M3UA uses a Tag-Length-Value (TLV) parameter format: Parameter Tag (16-bit unsigned integer), Parameter Length (16-bit, including Tag and Length fields but excluding padding), and Parameter Value (variable length). Total parameter length MUST be a multiple of 4 octets; up to 3 zero-byte padding octets are appended after the value but not counted in the length field.
The Common Message Header is 8 octets: Version (8-bit unsigned integer, value 1 for Release 1.0), Reserved (8-bit, set to 0 and ignored by receiver), Message Class (8-bit), Message Type (8-bit), and Message Length (32-bit unsigned integer inclusive of the header and any padding octets).
The Protocol Data parameter (Tag 0x0210) encodes the complete SS7 MTP3 message: Originating Point Code (32-bit, right-justified), Destination Point Code (32-bit, right-justified), Service Indicator (8-bit), Network Indicator (8-bit), Message Priority (8-bit), Signalling Link Selection (8-bit), followed by variable-length User Protocol Data. Unused bits in fixed fields are coded '0'.