RFC 5611

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

📅 published August 2009, from ietf

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

RFC 5611 · Standards Track · August 2009 🎀

This one's by A. Vainshtein (ECI Telecom) and S. Galtzur (Rebellion), and it's a Standards Track doc, so it's meant to be implemented, not just read. The title block doesn't list anything it obsoletes or updates. ✨

Abstract ✨

okay so this doc adds extensions to L2TPv3 (Layer Two Tunneling Protocol version 3) so it can carry TDM pseudowires 🦋 It covers two flavours: structure-agnostic, and structure-aware in the CESoPSN style (Circuit Emulation Service over Packet Switched Network). Structure-aware in the TDMoIP style? Not handled here. That's left for further study 🧚

Status of This Memo 🌸

this is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬 For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited.

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 💅

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Read these carefully, bestie, they spell out your rights and restrictions 🫶

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 😭

Table of Contents 🗂️

1. Introduction ....................................................2
   1.1. Conventions Used in This Document ..........................3
2. L2TPv3 Extensions ...............................................3
   2.1. TDM PW Attribute-Value Pair (AVP) (ICRQ, OCRQ) .............4
   2.2. RTP Attribute-Value Pair (AVP) (ICRQ, OCRQ, ICRP, OCRP) ....6
   2.3. Changes in the Control Connection Management AVPs ..........7
   2.4. Changes in the Session Management AVPs .....................7
3. Creation of the TDM Pseudowire Session ..........................7
4. IANA Considerations .............................................9
5. Congestion Control ..............................................9
6. Security Considerations ........................................10
7. Acknowledgements ...............................................10
8. References .....................................................10
   8.1. Normative References ......................................10
   8.2. Informative References ....................................10

1. Introduction ✨

okay so this doc extends L2TPv3 for structure-agnostic [RFC4553] and structure-aware (CESoPSN style, see [RFC5086]) TDM pseudowires 🎀 The structure-agnostic way of wrapping TDM bit-streams in L2TPv3 is in [RFC4553], Figure 2b. The CESoPSN structure-aware encapsulation is in [RFC5086], Figures 1c (TDM data packets) and 4a (CE application signaling packets) 🔥 Now the drama: the order of the CESoPSN Control Word (CW) and RTP header (if it's used) MUST match between the TDM data and CE signaling packets. No exceptions, no cap 💅

Setting up structure-aware TDM pseudowires with the encapsulations from [RFC5087] has been left for further study 🧚

Setup and maintenance of TDM pseudowires (PWs) in MPLS networks using LDP is covered in [RFC5287] 🦋

1.1. Conventions Used in This Document 📖

so here's the vocab. The "control plane" means the packets that carry control information (via Attribute-Value Pairs (AVPs)), plus the mechanism that handles them 🧠 The "data plane" means the packets that carry transported user data 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. ⭐

2. L2TPv3 Extensions 🌸

the L2TPv3 Control Connection has 3 main jobs 👑

  1. Establishment and validation of a pseudowire (PW) session.
  2. Ending (tearing down) of a pseudowire session.
  3. Transferring of End Point status.

Tearing down a TDM pseudowire session follows the L2TPv3 tear-down operations in Section 3.4.3 of [RFC3931]. Easy peasy 🧚

[RFC5086] and [RFC4553] explain how to transfer the Attachment Circuit (AC) status over the data plane 🫶 That's why the Set-Link-Info (SLI) message from [RFC3931] SHOULD NOT be used to convey this status for the PWs in question. Not the move, bestie 🙈

[RFC3931] says the Circuit Status Attribute-Value Pair (AVP) MUST be present in the ICRQ/ICRP (Incoming-Call-Request / Incoming-Call-Reply) messages 📨 It also says the N bit in this AVP should be set during PW setup, even if the specific AC has no way to convey the "new AC" indication. So for the PWs in question, the Circuit Status AVP in ICRQ/ICRP messages MUST always have both N and A bits set. Lock it in 🔒

The next sections are the extensions to L2TPv3 for establishing and validating TDM pseudowire sessions 🎀

There are two new AVPs for the Session Management messages 💖 One describes the TDM pseudowire attributes. The other describes the RTP attributes for that TDM pseudowire ✨

2.1. TDM PW Attribute-Value Pair (AVP) (ICRQ, OCRQ) 🦋

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|H| rsvd  |      Length       |           Vendor Id (IETF)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Attribute Type (99)          |         Reserved      |SP |CAS|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Bit Rate              |        Payload Bytes          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

this AVP MAY be hidden (the H bit MAY be 0 or 1) 🙈 The M bit SHOULD be set to 0 for this AVP. Its Length (before hiding) is 12 📏

The Bit Rate field holds the bit rate of the local AC in units of 64 Kbit/s, encoded as an unsigned 16-bit integer 🔢 Here's how it works for each TDM PW type:

  1. For structure-agnostic emulation, this parameter MUST be set to one of these values (see [RFC4553]):
    • a) Structure-agnostic E1 emulation - 32
    • b) Structure-agnostic T1 emulation:
      • i) MUST be set to 24 for the basic mode
      • ii) MUST be set to 25 for the "Octet-aligned T1" mode
    • c) Structure-agnostic E3 emulation - 535
    • d) Structure-agnostic T3 emulation - 699
  2. For CESoPSN PWs, this parameter MUST be set to the number of DS0 channels in the corresponding attachment circuit. 🍓

Note: For structure-agnostic T1 emulation, the values 24 and 25 don't reflect the exact bit rate. They're just for convenience 💅

Note: The Bit Rate field semantics above match the CEP/TDM Bit-Rate interface parameter in [RFC5287] ✨

The Payload Bytes field holds the number of TDM payload bytes in the PW packet 📦 Semantics:

  1. For structure-agnostic emulation, any value of Payload Bytes can be specified. Anything goes 🌈
  2. For CESoPSN PWs:
    • a) The specified value MUST be an integer multiple of the number of DS0 channels in the corresponding attachment circuit.
    • b) Plus, for trunk-specific NxDS0 with Channel-Associated Signaling (CAS), the number of trunk frames per multiframe fragment (the Payload Bytes divided by the number of DS0 channels) MUST be an integer divisor of the number of frames per corresponding trunk multiframe. Math check passed 🧮

The Reserved bits MUST be set to 0 on transmission and MUST be ignored on reception. Set them to 0 and then forget about them 🙌

The SP bits define support for CESoPSN application signaling packets (see [RFC5086]) and MUST be used as follows:

  1. Set to '01' for CESoPSN PWs carrying TDM data packets and expecting CE application signaling packets in a separate PW.
  2. Set to '10' for a PW carrying CE application signaling packets, with the data packets in a separate PW.
  3. Set to '11' for a CESoPSN PW carrying both TDM data and signaling packets.
  4. Set to '00' for Structure-Agnostic Time-Division Multiplexing over Packet (SAToP) PWs, and for CESoPSN PWs not using separate signaling packets.

The CAS bits define the trunk type for trunk-specific CESoPSN services with CAS 🎀 They MUST be set to:

  1. For trunk-specific CESoPSN with CAS:
    • a) '01' in the case of an E1 trunk
    • b) '10' in the case of a T1/ESF trunk
    • c) '11' in the case of a T1/SF trunk
  2. '00' for all the other TDM pseudowire types 🦋

2.2. RTP Attribute-Value Pair (AVP) (ICRQ, OCRQ, ICRP, OCRP) 🎀

bestie, this AVP is where the RTP header gets switched on for a TDM pseudowire 💅 Let's look at the layout first:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|H| rsvd  |      Length       |           Vendor Id (IETF)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Attribute Type (100)        |D|     PT      |C|  Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Reserved              |   Timestamp Clock  Frequency  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              SSRC                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The presence of this AVP means the RTP header is used in the TDM pseudowire encapsulation. Use or non-use of the RTP header MUST match for the two directions of a TDM PW. This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 16.

The D bit tells you the timestamping mode, absolute or differential, in the RTP header. These modes are described in, e.g., Section 4.3.2 of [RFC4553]. If D is set to 1, you're in differential timestamping mode. Otherwise you're in absolute mode. ✨ The two directions of a TDM PW can use timestamping modes independently, so they don't have to match 🫶

The C bit tells you how the RTP header and the Control Word are ordered:

  • If C is set to 1, the RTP header comes after the Control Word in the data channel of the TDM pseudowire. This is the mode described in [RFC4553] and [RFC5086] as SAToP/CESoPSN encapsulation over IPv4/IPv6 PSN with L2TPv3 demultiplexing, respectively. 💖
  • If C is set to 0, the RTP header comes before the Control Word. This is described as the old mode of the SAToP/CESoPSN encapsulation over L2TPv3 in Appendix A of [RFC4553] and Appendix C of [RFC5086], respectively. 🙈

PT is the payload type expected in the RTP header. A value of 0 means the receiver shall not check the payload type to detect malformed packets.

Timestamp Clock Frequency is the clock frequency used for timestamping, in units of 8 KHz. 🧚

SSRC is the expected value of the synchronization source (SSRC) ID in the RTP header. A 0 here means the SSRC ID will not be used for detecting misconnections. Since L2TP offers an alternative security mechanism using cookies, if the cookie length is larger than 0, the SSRC SHOULD be 0. 🦋

2.3. Changes in the Control Connection Management AVPs 🌸

Control Connections that support TDM PWs MUST add the appropriate PW Type value(s) to the list in the Pseudowire Capabilities List AVP. The valid values are listed in the next section. 💅

2.4. Changes in the Session Management AVPs 🍓

PW Type AVP should be set to one of the following values:

  1. Structure-agnostic emulation [RFC4553] of: a. E1 circuits - 0x0011 b. T1 (DS1) circuits - 0x0012 c. E3 circuits - 0x0013 d. T3 (DS3) circuits - 0x0014
  2. Structure-aware emulation [RFC5086] of: a. CESoPSN basic mode - 0x0015 b. Trunk-specific CESoPSN service with CAS - 0x0017

TDM pseudowires use their own Control Word. Therefore, the L2-Specific Sublayer AVP MUST either be omitted or set to 0. 👑

TDM pseudowires use their own sequencing. Therefore, the Data Sequencing AVP MUST either be omitted or set to 0. 🌈

Note: The Control Word (CW) used in the SAToP and CESoPSN encapsulations over L2TPv3 effectively represents a dedicated L2-Specific Sublayer. 🔥

3. Creation of the TDM Pseudowire Session ✨

When an L2TP Control Connection Endpoint (LCCE) wants to open a Session for a TDM PW, it MUST include the TDM PW AVP (in any case) and the RTP AVP (if and only if the RTP header is used) in the ICRQ or OCRQ (Outgoing-Call-Request) message. The LCCE peer must validate the TDM PW AVP and make sure it can meet the requirements derived from the RTP AVP (if it exists). If the peer agrees with the TDM AVP, it will send an appropriate ICRP or OCRP (Outgoing-Call-Reply) message with the matching RTP AVP (if needed). The initiator needs to validate that it can supply the requirements derived from the received RTP AVP. 🫶

The two peers MUST agree on the values in the TDM PW AVP:

  1. Bit Rate values MUST be equal on both sides. If they are different, the connection will be rejected with Result Code 30 and Error Code 1. 🙅‍♀️
  2. In the case of trunk-specific CESoPSN with CAS, the trunk type (as encoded in the CAS bits of the TDM AVP) MUST be the same for the two sides. Otherwise, the connection will be rejected with Result Code 30 and Error Code 2.
  3. If one side does not support the Payload Bytes value proposed by the other one, the connection will be rejected with Result Code 30 and Error Code 3.
  4. If one side cannot send the RTP header as requested by the other side, the connection will be rejected with Result Code 30 and Error Code 4.
  5. If one side can send the RTP header but not with the requested timestamp clock frequency, the connection will be rejected with Result Code 30 and Error Code 5.

If CE signaling for a CESoPSN basic PW is transported in a separate PW instance, then the two PW instances:

  1. MUST use the same PW type.
  2. MUST use the same values in all the fields of the TDM AVP excluding the SP field, which must be set to 01 for the TDM data PW and to 10 for the PW carrying CE application signaling.
  3. MUST both either use or not use the RTP header (and, accordingly, include or not include the RTP AVP).

4. IANA Considerations 🦋

IANA assigned the following values according to this document:

New L2TPv3 Pseudowire Types:

    0x0011 - Structure-agnostic E1 circuit
    0x0012 - Structure-agnostic T1 (DS1) circuit
    0x0013 - Structure-agnostic E3 circuit
    0x0014 - Structure-agnostic T3 (DS3) circuit
    0x0015 - CESoPSN basic mode
    0x0017 - CESoPSN TDM with CAS

Note that the values listed match the values defined in [RFC4446] for the MPLS Pseudowire Types.

New Attribute-Value Pair IDs:

    99 - TDM Pseudowire AVP
   100 - RTP AVP

New Result Codes for the CDN message:

   30 - Result Code to indicate connection was refused because of TDM
        PW parameters.  The Error Code indicates the problem.

New TDM PW specific Error Codes, to be used with 30 Result Code for the CDN message:

This is a new registry for IANA to maintain within the Result Code AVP (Attribute Type 1) Values. Additional values may be assigned by Expert Review [RFC5226].

    0 - Reserved.
    1 - Bit Rate values disagree.
    2 - Different trunk types in the case of trunk-specific CESoPSN
        with CAS.
    3 - Requested payload size too big or too small.
    4 - RTP header cannot be generated.
    5 - Requested timestamp clock frequency cannot be generated.

5. Congestion Control 🌊

The congestion considerations from [RFC4553] and [RFC5086] apply respectively to the structure-agnostic and CESoPSN modes of this specification. 💜

6. Security Considerations 🚨

This is serious bestie, read this part 😭

This document specifies only the L2TPv3-based control plane for setup of TDM PWs. Within this scope, there are no additional security considerations in addition to those discussed in [RFC3931].

Common data plane security considerations for the TDM PWs have been discussed in some detail in both [RFC4553] and [RFC5086]. On top of these, the L2TPv3-based data plane provides additional security mechanisms based on the usage of cookies. 🔐

7. Acknowledgements 💖

The authors want to thank Carlos Pignataro, Ignacio Goyret, and Yaakov Stein for careful review and useful suggestions. 🫶

8. References 📚

8.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3931]  Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
           "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC
           3931, March 2005.

[RFC4553]  Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-
           Agnostic Time Division Multiplexing (TDM) over Packet
           (SAToP)", RFC 4553, June 2006.

[RFC5086]  Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and
           P. Pate, "Structure-Aware Time Division Multiplexed (TDM)
           Circuit Emulation Service over Packet Switched Network
           (CESoPSN)", RFC 5086, December 2007.

8.2. Informative References

[RFC4446]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
           Emulation (PWE3)", BCP 116, RFC 4446, April 2006.

[RFC5087]  Y(J). Stein, Shashoua, R., Insler, R., and M. Anavi, "Time
           Division Multiplexing over IP (TDMoIP)", RFC 5087,
           December 2007.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           May 2008.

[RFC5287]  Vainshtein, A. and Y(J). Stein, "Control Protocol
           Extensions for the Setup of Time-Division Multiplexing
           (TDM) Pseudowires in MPLS Networks", RFC 5287, August
           2008.

Authors' Addresses 🧚

Alexander Vainshtein,
ECI Telecom,
30 ha-Sivim St. PO Box 500,
Petah-Tiqva 49517, Israel
EMail: Alexander.Vainshtein@ecitele.com


Sharon Galtzur
Rebellion Inc.
29 The Chilterns, Gloucester Green,
Oxford, OX1 2DF, UK
EMail: sharon.galtzur@rebellion.co.uk
📦 where this page comes from