rfc-4233

Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer

K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom
date2006-01 streamIETF arearai wgsigtran statusPROPOSED STANDARD pages73 canonicalhttps://www.rfc-editor.org/rfc/rfc4233 doi10.17487/RFC4233
This document defines a protocol for backhauling of Integrated Services Digital Network (ISDN) Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface. This document obsoletes RFC 3057. [STANDARDS-TRACK]

obsoletes

updated by

Extracted elements (32)

design-rationale §1.5.3

A separate SCTP stream is recommended for each D channel to minimize transmission and buffering delay, improving overall performance and reliability. SCTP stream management is the IUA layer's responsibility because SCTP streams are unidirectional and each peer is unaware of the other's stream-to-Interface Identifier mapping.

sctp

design-rationale §1.3.1

SCTP is recommended over TCP as the underlying transport because it provides explicit packet-oriented delivery, multi-stream sequencing, multi-homing for network-level fault tolerance, resistance to flooding and masquerade attacks, and data segmentation. TCP MAY be used only in scenarios without redundancy requirements.

sctp

design-rationale §3.3.2.9

The Heartbeat message is optional and recommended only when IUA runs over a transport other than SCTP, because SCTP already has its own heartbeat mechanism. This avoids redundant keepalive overhead on native SCTP deployments.

sctp

interoperability-note §3.3.2.5

When an SG receives an ASPAC with an unsupported Traffic Mode Type for a particular Interface Identifier, it MUST respond with an Error Message (Cause: Unsupported Traffic Handling Mode). Text-formatted Interface Identifiers trigger an 'Unsupported Interface Identifier Type' error if the SG only supports integer format, requiring the ASP to resend with integer format.

sctp

normative-requirement §3.1 MUST

All fields in an IUA message MUST be transmitted in network byte order (most significant byte first, big endian), unless otherwise stated.

sctp

normative-requirement §3.3.3.1 MUST NOT

Error messages MUST NOT be generated in response to other Error messages.

sctp

normative-requirement §3.1.5 MUST

Mandatory parameters MUST be placed before optional parameters in an IUA message.

sctp

normative-requirement §3.2 MUST

The integer-formatted Interface Identifier MUST be supported; the text-formatted Interface Identifier MAY optionally be supported.

sctp

normative-requirement §1.5.1 MUST

The IUA layer MUST maintain a map of the Interface Identifier to a physical interface on the Signaling Gateway (e.g., T1, E1 line including TDM timeslot), and the SG MUST be able to identify the associated signaling channel for a given interface.

sctp

normative-requirement §1.5.2 MUST

The IUA layer on the SG MUST maintain the state of the ASPs it is supporting; state changes occur due to reception of ASPM peer-to-peer messages or SCTP association indications.

sctp

normative-requirement §3.1.4 MUST

The Message Length field MUST include parameter padding bytes, if any. A receiver SHOULD accept the message whether or not the final parameter padding is included in the message length.

sctp

normative-requirement §3.3.2.9 MUST

The receiver of a Heartbeat (BEAT) message MUST respond with a Heartbeat Ack message; the Heartbeat Ack MUST include all parameters of the received Heartbeat unchanged.

sctp

normative-requirement §1.3.4 SHOULD

The SG and ASP SHOULD be configured so one always takes the role of client and the other server; ASPs SHOULD initiate the SCTP association to the SG, which defaults to server role.

sctp

normative-requirement §1.5.1 MUST

The SG MUST maintain the states of AS/ASP and reference them during routing of messages; the mapping from Interface Identifier to SCTP association/stream is dynamic and could change at any time.

sctp

normative-requirement §3.1.5 MUST

The total length of a TLV parameter (including Tag, Parameter Length, and Value fields) MUST be a multiple of 4 bytes; the sender pads at the end with zero bytes and MUST NOT pad with more than 3 bytes. The receiver MUST ignore padding bytes.

sctp

normative-requirement §3.3.3.1 MUST

When the 'Invalid Interface Identifier' error is sent, the Diagnostic Information MUST contain enough of the offending message to identify the invalid Interface Identifier (at minimum, the Common and IUA message headers for QPTM and TEI Status messages).

sctp

protocol-element §3.1.2

Management (MGMT) messages include TEI Status Request (type 2), TEI Status Confirm (type 3), and TEI Status Indication (type 4), used to request and report assignment status of ISDN Terminal Endpoint Identifiers.

sctp

protocol-element §3.1.2

Message Classes defined: 0=Management (MGMT), 3=ASP State Maintenance (ASPSM), 4=ASP Traffic Maintenance (ASPTM), 5=Q.921/Q.931 Boundary Primitives Transport (QPTM). Values 9-127 reserved by IETF; 128-255 reserved for IETF-defined extensions.

sctp, registry

protocol-element §3.1.2

QPTM messages transport Q.921/Q.931 boundary primitives: Data Request/Indication (types 1-2), Unit Data Request/Indication (3-4), Establish Request/Confirm/Indication (5-7), Release Request/Confirm/Indication (8-10).

sctp

protocol-element §3.3.2.5

The ASP Active (ASPAC) message carries a mandatory Traffic Mode Type parameter (Over-ride=0x1 or Load-share=0x2) and optional Interface Identifiers. Integer (0x1) and Integer Range (0x8) types may be mixed; text (0x3) cannot be mixed with integer types.

sctp

protocol-element §3.1

The Common Message Header is an 8-byte structure containing: Version (8 bits), Reserved (8 bits, set to 0), Message Class (8 bits), Message Type (8 bits), and Message Length (32 bits). All IUA messages begin with this header.

sctp

protocol-element §3.3.3.1

The Error (ERR) message carries a mandatory Error Code parameter (Tag=0x000c) with 15 defined values (0x01-0x0f), including Invalid Version, Invalid Interface Identifier, Unsupported Traffic Handling Mode, Unassigned TEI, and Invalid ASP Identifier, plus optional Diagnostic Information.

sctp

protocol-element §3.2

The IUA Message Header, present in QPTM and TEI Status MGMT messages immediately after the Common Header, carries the Interface Identifier (integer Tag=0x1 or text Tag=0x3) and DLCI (Tag=0x5, Length=8), which together identify the physical ISDN channel at the SG.

sctp

protocol-element §3.3.3.2

The Notify (NTFY) message provides autonomous indication of IUA events with a mandatory Status parameter (Tag=0x000d, containing Status Type and Status Identification) and optional ASP Identifier, Interface Identifiers, and INFO String.

sctp

registry §7.1

Section 7.1 registers an SCTP Payload Protocol Identifier for IUA. The assigned port number for both SCTP and TCP for IUA is 9900.

registry, sctp

registry §7.2

Section 7.2 defines IUA Protocol Extensions: Message Class values 128-255 and Parameter Tag value 65535 are reserved for IETF-defined extensions; values 9-127 for Message Classes and other unassigned tags are reserved by the IETF.

registry, sctp

security-consideration §6

IUA relies on SCTP's built-in security mechanisms including resistance to flooding and masquerade attacks. Use of SCTP is recommended over TCP partly for these security properties; TCP MAY be used only in scenarios without redundancy requirements or where redundancy is handled below the transport layer.

security, sctp

state-machine §4.3.1

ASP states: DOWN (initial), INACTIVE (after ASP Up / ASPUP acknowledged), ACTIVE (after ASP Active / ASPAC acknowledged). Transitions: DOWN→INACTIVE via ASPUP/UP-ACK; INACTIVE→ACTIVE via ASPAC/ACTIVE-ACK; ACTIVE→INACTIVE via ASPIA/INACTIVE-ACK; any state→DOWN via ASPDN/DOWN-ACK or SCTP failure.

sctp

wire-format §3.1

Common Header: Version (8 bits, value 1 for Release 1.0), Reserved (8 bits), Message Class (8 bits, unsigned), Message Type (8 bits, unsigned), Message Length (32 bits, includes header, octets).

sctp

wire-format §3.2

DLCI field (Tag=0x5, Length=8): octet 1 = SAPI (6 bits) | SPR (1 bit) | 0; octet 2 = TEI (7 bits) | 1. Coded in accordance with Q.921. Example: SAPI=0, TEI=64, SPR=0 encodes as 0x00 0x81.

sctp

wire-format §3.2

Integer-based Interface Identifier parameter: Tag=0x0001, Length=8 (fixed), followed by a 32-bit integer value. Integer Range parameter (Tag=0x0008) encodes pairs of 32-bit Start/Stop values for compact representation.

sctp

wire-format §3.1.5

TLV Parameter format: Parameter Tag (16-bit unsigned, 0x0000-0xFFFE), Parameter Length (16-bit unsigned, includes Tag+Length+Value, excludes padding), Parameter Value (variable). Total must be 4-byte aligned with zero-byte padding.

sctp