Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)
Extracted elements (30)
Link Status messages (Alignment, Processor Outage, Busy, Out of Service) SHOULD NOT be transmitted continuously, unlike their MTP2 counterparts (SIO, SIPO, SIB, SIOS). This conserves IP network bandwidth since IP is a shared resource, and SCTP's reliable delivery removes the need for continuous repetition for reliability.
M2PA has no FISU equivalent because IP networks are shared resources where continuous fill-in transmission is undesirable, and SCTP does not require its upper layer to transmit continuously. Instead, an empty User Data message (FSN unchanged) is sent only when acknowledgement is needed but no MTP3 data is available.
M2PA uses 24-bit sequence numbers (0–16,777,215) instead of MTP2's 7-bit values to accommodate IP network latency and buffering characteristics. This necessitates Extended Changeover Order (XCO/XCA) messages in MTP3. Only one User Data stream per link direction is supported because MTP3 issues only one XCO/XCA during changeover; multiple streams would require a new multi-BSNT XCO/XCA extension.
M2PA uses two separate SCTP streams to replicate MTP2's priority of Link Status messages over User Data messages. Separation allows implementors to schedule reads and writes with appropriate priority without requiring a new priority mechanism at the SCTP layer.
The Link Status Proving message MAY optionally carry a variable-length filler field. It is RECOMMENDED that the filler be sized comparably to expected User Data messages and contain a varying pattern so that the SCTP checksum can verify transmission accuracy. This also allows the proving period to drive SCTP slow start to completion before the link enters service.
A newer M2PA version SHOULD support older versions and refrain from sending messages an older version cannot process. If a Link Status Alignment message with an unsupported version is received, the receiver SHOULD reply with Link Status Out of Service and not complete alignment.
Having multiple User Data streams per link direction is not currently supported because MTP3 provides only one XCO/XCA message during changeover, making it impossible to unambiguously perform buffer updating across streams without risk of message loss or duplication. Support would require a multi-BSNT XCO/XCA extension outside this document's scope.
M2PA differs fundamentally from M2UA: M2PA creates a true SS7 link between IPSPs (each with a point code, full MTP3, and local MTP3/MTP2 processing), while M2UA backhaults MTP3/MTP2 primitives to a remote MGC and the SG has no point code or MTP3. Users must understand these differences when choosing between protocols.
SCTP slow start may delay M2PA messages during link alignment (new association), changeover (new or idle alternate link), path failure (multi-homing path switch), or after reduced traffic volume. Sending Link Status Proving messages during the proving period can pre-warm SCTP slow start before the link enters service.
Because M2PA uses 24-bit sequence numbers vs. MTP2's 7-bit, the MTP3 Changeover procedure MUST use the Extended Changeover Order (XCO) and Extended Changeover Acknowledgement (XCA) messages from Q.2210/T1.111. The BSNT Confirmation and Retrieval Request and FSNC primitives MUST also use the larger sequence numbers.
During a local processor outage (LPO), any User Data messages received from the peer MUST NOT be acknowledged and MUST be buffered. M2PA SHOULD continue transmitting messages from MTP3 and acknowledging messages received and accepted by MTP3 before the LPO began.
During receive congestion, M2PA SHALL send a Link Status Busy message at onset (and MAY send additional ones), SHALL NOT acknowledge the triggering message or any messages before Link Status Busy Ended, and the peer MUST NOT send User Data messages after receiving Link Status Busy and before receiving Link Status Busy Ended.
Each IP Signaling Point (IPSP) MUST have its own SS7 point code, as MTP requires every node with an MTP3 layer to be identified by a point code.
Each SCTP association-to-SLC mapping MUST be consistent at both endpoints so that each endpoint knows which link is being created when the association is established. It is RECOMMENDED that each endpoint know both IP addresses and port numbers to prevent duplicate associations.
If M2PA receives a User Data message with an out-of-order FSN, M2PA SHALL discard the message. For non-User Data message types, the FSN is set to the FSN of the last User Data message sent.
If the SCTP association becomes unable to transmit or receive messages (Send Failure, Communication Lost, Communication Error, or association loss), M2PA SHALL report to MTP3 that the link is out of service and enter the OUT OF SERVICE state.
M2PA SHALL retain transmitted User Data messages in a retransmit queue until they are acknowledged, to support MTP3 data retrieval during changeover. Link Status messages and empty User Data messages SHALL NOT be placed in the retransmit buffer and SHALL NOT be retrieved during changeover.
M2PA SHALL send all messages using the ordered delivery option of SCTP. M2PA SHOULD give higher priority to messages on the Link Status stream than on the User Data stream, and higher priority to SCTP notifications than to reading either stream.
The same MTP2 standard (e.g., Q.703 or T1.111) MUST be followed on both ends of the M2PA link. Except as modified in this document, M2PA SHOULD follow the requirements of the applicable MTP2 specification.
When a message must be acknowledged, M2PA MUST do so with the next User Data message sent. If no User Data is available, M2PA SHOULD immediately send an empty User Data message (same FSN as the last data-carrying message, not incremented). Empty User Data messages SHALL NOT themselves be acknowledged.
M2PA defines two message types under Message Class 11: User Data (type 1) and Link Status (type 2). All other Message Class or Type values are invalid; messages with an invalid Message Class or unsupported Message Type SHALL be discarded.
M2PA uses two SCTP streams per direction per association. Stream 0 carries Link Status messages (Alignment, Proving, Ready during alignment, Busy, Busy Ended, Out of Service). Stream 1 carries User Data messages and Link Status messages that must remain in sequence with User Data (Processor Outage, Processor Recovered, Ready after processor outage).
This document establishes an IANA registry for M2PA Protocol Extensions (Section 7.2), enabling future registration of new M2PA message classes, message types, and other protocol extension points beyond those defined in this specification.
This document registers an SCTP Payload Protocol Identifier (PPID) for M2PA with IANA. The PPID is used in the SCTP DATA chunk to identify M2PA traffic within an SCTP association.
M2PA transports SS7 MTP3 signaling over IP using SCTP, exposing it to IP-layer threats absent in traditional SS7 networks. Security mechanisms at the IP layer (such as IPsec) should be applied to protect M2PA associations, as unauthorized access to or manipulation of SS7 signaling messages could compromise telephony network integrity and availability.
The SCTP Association state machine has three states: IDLE (initial/power-up), ASSOCIATING (after issuing SCTP Associate), and ESTABLISHED (after SCTP Comm Up). SCTP Comm Error in ASSOCIATING or ESTABLISHED causes a transition back to ASSOCIATING with re-attempt; SCTP Comm Lost in ESTABLISHED similarly transitions back to ASSOCIATING.
The Common Message Header is 8 bytes: Version (1 byte, value 1 for Release 1.0), Spare (1 byte, SHALL be zero), Message Class (1 byte), Message Type (1 byte), and Message Length (4 bytes, includes the header). All fields are transmitted in network byte order (big-endian).
The Link Status message data field is a single 32-bit State field with nine valid values: Alignment (1), Proving Normal (2), Proving Emergency (3), Ready (4), Processor Outage (5), Processor Recovered (6), Busy (7), Busy Ended (8), and Out of Service (9). The Proving variant optionally carries a variable-length filler field.
The M2PA-specific Header is 8 bytes: an unused byte followed by BSN (3 bytes, backward sequence number) and an unused byte followed by FSN (3 bytes, forward sequence number). FSN and BSN values range from 0 to 16,777,215 (24-bit unsigned).
The User Data message Data field carries MTP MSU fields: PRI (2 bits, bits 7–6 of first octet), spare (6 bits), SIO, and SIF, transmitted in MTP3 byte order. The field SHALL NOT include Flag, BSN, BIB, FSN, FIB, LI, or CK from the MTP MSU, and M2PA SHALL NOT add padding.