rfc-5611

Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires

A. Vainshtein, S. Galtzur
date2009-08 streamIETF areartg wgl2tpext statusPROPOSED STANDARD pages11 canonicalhttps://www.rfc-editor.org/rfc/rfc5611 doi10.17487/RFC5611
This document defines extensions to the Layer Two Tunneling Protocol version 3 (L2TPv3) for support of structure-agnostic and structure-aware (Circuit Emulation Service over Packet Switched Network (CESoPSN) style) Time-Division Multiplexing (TDM) pseudowires. Support of structure-aware (Time-Division Multiplexing over IP (TDMoIP) style) pseudowires over L2TPv3 is left for further study. [STANDARDS-TRACK]

Extracted elements (25)

design-rationale §2.2

The C bit in the RTP AVP was introduced to maintain backward compatibility with a legacy L2TPv3 encapsulation mode where the RTP header preceded the Control Word. The current standard mode (C=1) places RTP after the CW, matching the SAToP/CESoPSN over IPv4/IPv6 PSN encapsulations.

mpls, rtp

design-rationale §4

The PW Type values for TDM pseudowires over L2TPv3 were deliberately chosen to match the corresponding MPLS PW Type values from RFC 4446, enabling consistent identification of TDM PW types across both MPLS and L2TPv3 transport networks.

mpls

interoperability-note §5

The congestion control considerations from RFC 4553 (SAToP) and RFC 5086 (CESoPSN) apply respectively to the structure-agnostic and structure-aware modes defined by this specification; no additional congestion mechanisms are introduced.

mpls, congestion

normative-requirement §2.3 MUST

Control Connections that support TDM PWs MUST add the appropriate PW Type value(s) to the Pseudowire Capabilities List AVP.

mpls

normative-requirement §3 MUST

During session setup, Bit Rate values MUST be equal on both sides; a mismatch results in connection rejection with Result Code 30, Error Code 1. For trunk-specific CESoPSN with CAS, the trunk type encoded in the CAS bits MUST also match; mismatch yields Result Code 30, Error Code 2.

mpls

normative-requirement §2.1 MUST

For CESoPSN PWs, the Payload Bytes value MUST be an integer multiple of the number of DS0 channels. Additionally, for trunk-specific NxDS0 with CAS, the number of trunk frames per multiframe fragment MUST be an integer divisor of the number of frames per trunk multiframe.

mpls

normative-requirement §2.2 SHOULD

If the L2TPv3 cookie length is larger than 0, the SSRC field in the RTP AVP SHOULD be set to 0, because L2TPv3 cookies provide an alternative security mechanism for detecting misconnections.

mpls, rtp, security

normative-requirement §2.4 MUST

TDM pseudowires use their own Control Word, so the L2-Specific Sublayer AVP MUST either be omitted or set to 0. Similarly, TDM PWs use their own sequencing, so the Data Sequencing AVP MUST either be omitted or set to 0.

mpls

normative-requirement §2 MUST

The Circuit Status AVP, when used in ICRQ/ICRP messages for TDM PWs, MUST always have both the N bit and the A bit set, even if the specific attachment circuit cannot convey a 'new AC' indication.

mpls

normative-requirement §1 MUST

The order of the CESoPSN Control Word and RTP header (if used) MUST match between TDM data packets and CE application signaling packets within the same pseudowire.

mpls

normative-requirement §2 SHOULD NOT

The Set-Link-Info (SLI) message as defined in RFC 3931 SHOULD NOT be used for conveying attachment circuit status for TDM PWs, because RFC 4553 and RFC 5086 define AC status transfer via the data plane.

mpls

normative-requirement §2.2 MUST

Use or non-use of the RTP header MUST match for both directions of a TDM PW. The RTP AVP MUST be included in ICRQ/OCRQ if and only if the RTP header is used.

mpls, rtp

normative-requirement §3 MUST

When CE signaling for a CESoPSN basic PW is transported in a separate PW instance, both PW instances MUST use the same PW type, MUST have identical TDM AVP fields except for the SP field, and MUST both either use or not use the RTP header.

mpls

normative-requirement §3 MUST

When opening a TDM PW session, an LCCE MUST include the TDM PW AVP in ICRQ or OCRQ, and MUST include the RTP AVP if and only if the RTP header is used. The peer MUST validate the TDM PW AVP and confirm it can meet the RTP AVP requirements.

mpls

protocol-element §2.4

PW Type values for TDM pseudowires: 0x0011 (structure-agnostic E1), 0x0012 (structure-agnostic T1/DS1), 0x0013 (structure-agnostic E3), 0x0014 (structure-agnostic T3/DS3), 0x0015 (CESoPSN basic mode), 0x0017 (trunk-specific CESoPSN with CAS). These values match RFC 4446 MPLS PW Type values.

mpls, registry

protocol-element §2.1

The Bit Rate field in the TDM PW AVP encodes the local AC bit rate in units of 64 Kbit/s as an unsigned 16-bit integer. For structure-agnostic emulation, specific fixed values apply: 32 for E1, 24 or 25 for T1, 535 for E3, 699 for T3. For CESoPSN PWs, the value equals the number of DS0 channels.

mpls

protocol-element §2.2

The C bit in the RTP AVP controls RTP header position: C=1 places the RTP header after the Control Word (standard SAToP/CESoPSN over L2TPv3); C=0 places the RTP header before the Control Word (legacy mode described in RFC 4553 Appendix A and RFC 5086 Appendix C).

mpls, rtp

protocol-element §2.1

The CAS bits define the trunk type for trunk-specific CESoPSN services with Channel-Associated Signaling: '01' for E1, '10' for T1/ESF, '11' for T1/SF, and '00' for all other TDM pseudowire types.

mpls

protocol-element §2.2

The D bit in the RTP AVP selects timestamping mode: D=1 enables differential timestamping; D=0 uses absolute timestamping. Timestamping modes may differ independently for the two directions of a TDM PW.

mpls, rtp

protocol-element §2.1

The SP bits in the TDM PW AVP define CESoPSN signaling packet support: '01' for a TDM data PW expecting signaling in a separate PW, '10' for a signaling-only PW, '11' for a combined data-and-signaling PW, and '00' for SAToP or CESoPSN without separate signaling.

mpls

registry §4

IANA assigned six new L2TPv3 Pseudowire Type values (0x0011–0x0015, 0x0017), two new AVP IDs (99 for TDM PW AVP, 100 for RTP AVP), a new CDN Result Code 30 for TDM PW parameter rejection, and a new registry of TDM PW-specific Error Codes (0–5) to accompany Result Code 30, with additional values assignable by Expert Review.

mpls, registry

security-consideration §6

This document covers only the L2TPv3 control plane for TDM PW setup; no additional security considerations beyond those in RFC 3931 apply to the control plane. The L2TPv3 data plane provides additional security via cookies, complementing the data plane security discussed in RFC 4553 and RFC 5086.

mpls, security

state-machine §3

TDM PW session establishment: LCCE sends ICRQ/OCRQ with TDM PW AVP (and RTP AVP if needed); peer validates and responds with ICRP/OCRP including matching RTP AVP; initiator validates received RTP AVP. Rejection states are triggered by Bit Rate mismatch (EC 1), trunk type mismatch (EC 2), unsupported payload size (EC 3), inability to generate RTP header (EC 4), or unsupported timestamp frequency (EC 5), all using Result Code 30.

mpls

wire-format §2.2

The RTP AVP (Attribute Type 100) is a 16-byte AVP carried in ICRQ/OCRQ/ICRP/OCRP messages. It encodes a D bit (timestamping mode), a 7-bit PT (payload type), a C bit (RTP/CW ordering), a 16-bit Timestamp Clock Frequency (in units of 8 KHz), and a 32-bit SSRC field.

mpls, rtp

wire-format §2.1

The TDM PW AVP (Attribute Type 99) is a 12-byte AVP carried in ICRQ/OCRQ messages. It contains a Reserved/SP/CAS flags field, a 16-bit Bit Rate field (in units of 64 Kbit/s), and a 16-bit Payload Bytes field. The M bit SHOULD be set to 0; the H bit MAY be 0 or 1.

mpls