rfc-3807

V5.2-User Adaptation Layer (V5UA)

E. Weilandt, N. Khanchandani, S. Rao
date2004-06 streamIETF arearai wgsigtran statusPROPOSED STANDARD pages24 canonicalhttps://www.rfc-editor.org/rfc/rfc3807 doi10.17487/RFC3807
This document defines a mechanism for the backhauling of V5.2 messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol may be used between a Signaling Gateway (SG) and a Media Gateway controller (MGC). It is assumed that the SG receives V5.2 signaling over a standard V5.2 interface. This document builds on the ISDN User Adaptation Layer Protocol (RFC 3057). It defines all necessary extensions to the IUA Protocol needed for the V5UA protocol implementation. [STANDARDS-TRACK]

updates

Extracted elements (29)

design-rationale §1.6.1

New MPH primitives (Link Status Start/Stop Reporting, Sa-Bit messages) were introduced because V5.2 system management must interact directly with V5.2 Layer 1, but in the backhaul architecture these entities are physically separated across MGC and SG, requiring explicit IP-based signaling to bridge them.

design-rationale §4.2

The Interface Identifier naming convention was mandated because IUA identifies C-channels by endpoints without link association, yet V5 System Management requires full knowledge of signaling and bearer channels per link for protection switching and bearer channel allocation. Without the convention, there is no guarantee a C-channel is on the link it claims.

design-rationale §1.6.1

V5UA replaces the IUA DL-Establish/DL-Release primitives with MDL-ESTABLISH and MDL-RELEASE because in V5 (unlike ISDN), system management—not the data link layer itself—is responsible for establishing and releasing data links, per the V5 standard definitions.

interoperability-note §4.2

The text-formatted Interface Identifier, when used, SHALL be coded as the hex representation of the integer-formatted Interface Identifier written as a variable-length string, ensuring interoperability with implementations that use text-format identifiers.

interoperability-note §1

V5UA builds on IUA (RFC 3057) and everything defined in RFC 3057 is also valid for V5UA unless otherwise specified. V5UA updates RFC 3057 by introducing new message class 14 (V5PTM) and extending the IUA message header with the EFA field.

normative-requirement §4.2 MUST

A naming convention MUST be used for V5UA Interface Identifiers to ensure a clear association between E1 links and channels, since V5 System Management requires knowledge of link status and the IUA protocol alone provides no guarantee that a C-channel is on the link it claims.

normative-requirement §3 SHOULD

A single SCTP stream SHOULD be used for BCC, Link Control, Control, and PSTN protocols together on a specific C-channel. A separate SCTP stream SHOULD be used for the Protection protocol per C-channel. One stream SHOULD carry all ISDN user ports on a C-channel. One stream SHOULD NOT carry data of more than one C-channel. One additional stream SHOULD carry all MPH (link-related) messages.

sctp

normative-requirement §5.1 SHALL

In the backhaul architecture, on V5 Layer 1 failure, V5 Layer 2 SHALL be notified directly by V5 Layer 1 on the SG (not via V5 System Management). V5 Layer 1 SHALL report the outage to system management via a Link Status Indication (NON-OPERATIONAL). V5 system management SHALL NOT send an MPH-Layer_1 Failure Ind to V5 Layer 2.

normative-requirement §4.4 SHALL

On receiving a Link Status Start Reporting message, the SG SHALL respond immediately with a Link Status Indication and SHALL continue sending Link Status Indication messages on all subsequent link status changes. System Management SHALL send this message on interface activation for all links.

normative-requirement §4.4 MUST NOT

On receiving a Link Status Stop Reporting message, the SG MUST NOT respond in any way, SHALL immediately stop reporting link status, SHALL take L2 down on the link, and SHALL assume the link to be out of service. This message SHALL be sent on interface deactivation for all links.

normative-requirement §4.5 MUST

The SG MUST answer a Sa-Bit Set Request message with a Sa-Bit Set Confirm message when the bit setting is complete.

normative-requirement §4.6, 5.3 SHOULD

The SG SHOULD send an Error Indication message with reason Overload if it cannot process all Layer 3 messages on a C-channel in a timely manner. The SG SHALL resend this message while the overload persists; a resend interval of 120 seconds is RECOMMENDED. The MGC SHOULD take appropriate actions to clear the overload.

normative-requirement §1.4 SHALL

V5 System Management SHALL be located on the MGC; the V5 L1 Functional State Machine (FSM) SHALL be located on the SG; Dynamic TEI Management for V5 BRI SHALL be located on the MGC.

protocol-element §4.4

Link Status Messages (Start Reporting msg 11, Stop Reporting msg 12, Indication msg 13) are used between V5 System Management on the MGC and the L1 FSM on the SG to track E1 link operational status. They apply to all links on a V5 interface regardless of whether the link carries C-channels.

protocol-element §4.5

Sa-Bit Messages (Set Request msg 14, Set Confirm msg 15, Status Request msg 16, Status Indication msg 17) are used between V5 System Management on the MGC and the L1 FSM on the SG to set and read Sa bit values on E1 links. For V5, only the Sa7 bit (BIT ID 0x7) is used for the Link Identification procedure.

protocol-element §4.1

The Envelope Function Address (EFA) is a 13-bit number (0-8191) that uniquely identifies one of the five V5.2 protocols or an ISDN agent: ISDN_PROTOCOL (0-8175), PSTN_PROTOCOL (8176), CONTROL_PROTOCOL (8177), BCC_PROTOCOL (8178), PROT_PROTOCOL (8179), LINK_CONTROL_PROTOCOL (8180), RESERVED (8181-8191).

protocol-element §4.6

The Error Indication message (msg 18, SG -> MGC) is used to report error conditions from the V5 stack on the SG to V5 System Management on the MGC. The only valid Error Reason is OVERLOAD (0x1), indicating a C-channel overload state. Tag is 0x84.

protocol-element §4.1

The V5UA message header extends the IUA header by replacing the Spare field with the Envelope Function Address (EFA). The Tag field changes from 0x5 (IUA) to 0x81 (V5UA) to signal this extension, and the DLCI field is followed by the 13-bit EFA rather than a spare field.

sctp

protocol-element §4.3

V5PTM defines 18 message types including reused IUA messages (Data Request/Indication, Unit Data Request/Indication, Establish/Release primitives) and new V5-specific messages: Link Status Start/Stop Reporting, Link Status Indication, Sa-Bit Set Request/Confirm, Sa-Bit Status Request/Indication, and Error Indication.

protocol-element §4.3

V5UA introduces a new Message Class 14 'V5 Boundary Primitives Transport Messages (V5PTM)' for V5-specific interface boundary primitives, alongside reused IUA message classes: 0 (MGMT), 3 (ASPSM), and 4 (ASPTM).

protocol-element §1

V5UA is an extension of the IUA protocol (RFC 3057) for backhauling V5.2 signaling over IP using SCTP between a Signaling Gateway (SG) and a Media Gateway Controller (MGC). It transports V5.2 Layer 3 messages across an IP network while V5 Layer 1/2 remains on the SG and V5 Layer 3 protocols (Link Control, Control, BCC, PSTN, Protection) reside on the MGC.

sctp, security

registry §8.1

IANA assigned SCTP Payload Protocol Identifier value 6 for V5UA. This value SHOULD be included in each SCTP DATA chunk to indicate V5UA; value 0 (unspecified) is also allowed; all other values MUST NOT be used.

registry, sctp

registry §8.2

IANA registered SCTP (and UDP/TCP) port number 5675 for V5UA.

registry, sctp

security-consideration §7

The security considerations from RFC 3788 'Security Considerations for Signaling Transport (SIGTRAN) Protocols' apply to V5UA. No additional V5UA-specific security considerations are defined beyond those for the SIGTRAN protocol family.

security, sctp

state-machine §5.2

On loss of V5UA peer (SCTP failure or lost heartbeat): the ASP treats all links on the SG as NON-OPERATIONAL, continuously attempts to re-establish the SCTP connection, and upon re-establishment sends Link Status Start Reporting for all active V5 interface links. If re-established before the V5UA layer is notified, communication proceeds as usual with no additional action.

sctp

wire-format §4.5

All Sa-Bit messages carry an additional parameter with Tag 0x83, a 2-byte BIT ID field (Sa7 = 0x7), and a 2-byte Bit Value field (ZERO = 0x0, ONE = 0x1). For Sa-Bit Status Request and Set Confirm, Bit Value SHALL be set to 0 and ignored by the receiver.

wire-format §4.2

The Interface Identifier integer format encodes a 27-bit Link Identifier (identifying an E1 link on the SG, must be unique on the SG) in the high bits and a 5-bit Channel ID (time slot number: 15, 16, or 31 for C-channels) in the low bits. For Link Management Messages, Chnl ID MUST be set to 0.

wire-format §4.4

The Link Status Indication message contains a Link Status parameter with Tag 0x82, followed by a 4-byte Link Status value: OPERATIONAL (0x0) or NON-OPERATIONAL (0x1).

wire-format §4.1

The V5UA message header integer-formatted Interface Identifier uses Tag 0x1 (4 bytes), Interface Identifier (4 bytes), Tag 0x81 (2 bytes), Length=8 (2 bytes), DLCI (2 bytes), and EFA (2 bytes, 13-bit value 0-8191 identifying a V5.2 C-path or ISDN agent).

sctp