path: root/doc/rfc/rfc5611.txt

Network Working Group                                      A. Vainshtein
Request for Comments: 5611                                   ECI Telecom
Category: Standards Track                                     S. Galtzur
                                                               Rebellion
                                                             August 2009


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

Abstract

   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.

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the
    "Internet Official Protocol Standards" (STD 1) for the
   standardization state and status of this protocol.  Distribution of
   this memo is unlimited.

Copyright Notice

   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).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   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




Vainshtein & Galtzur        Standards Track                     [Page 1]
^L
RFC 5611                    TDM over L2TPv3                  August 2009


   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

   This document defines extensions to the Layer Two Tunneling Protocol
   Version 3 (L2TPv3) for support of structure-agnostic [RFC4553] and
   structure-aware (CESoPSN style, see [RFC5086]) Time-Division
   Multiplexing (TDM) pseudowires.  Structure-agnostic encapsulation of
   TDM bit-streams over L2TPv3 is described in [RFC4553], Figure 2b;
   Circuit Emulation Service over Packet Switched Networks (CESoPSN),
   structure-aware encapsulation is described in [RFC5086], Figures 1c
   (TDM data packets) and 4a (CE application signaling packets).
   However, the order of the CESoPSN Control Word (CW) and RTP header
   (if it is used) MUST match between the TDM data and CE signaling
   packets.

   Setup of structure-aware TDM pseudowires using the encapsulations
   described in [RFC5087] has been left for further study.

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










Vainshtein & Galtzur        Standards Track                     [Page 2]
^L
RFC 5611                    TDM over L2TPv3                  August 2009


1.1.  Conventions Used in This Document

   In this document, we refer to the "control plane" as meaning the
   packets that contain control information (via Attribute-Value Pairs
   (AVPs)) and the mechanism that handles these packets.  We also refer
   to the "data plane" as meaning the packets that contain 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 is responsible for 3 main operations:

   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 of the session for a TDM pseudowire is performed
   following the L2TPv3 tear-down operations as described in Section
   3.4.3 of [RFC3931].

   [RFC5086] and [RFC4553] describe how to transfer the Attachment
   Circuit (AC) status via the data plane.  Therefore, the Set-Link-Info
   (SLI) message described in [RFC3931] SHOULD NOT be used for conveying
   this status for the PWs in question.

   [RFC3931] specifies that the Circuit Status Attribute-Value Pair
   (AVP) MUST be present in the ICRQ/ICRP (Incoming-Call-Request /
   Incoming-Call-Reply) messages.  It also specifies that the N bit in
   this AVP should be set during the PW setup, even if the specific AC
   does not provide any way to convey the "new AC" indication.
   Accordingly, the Circuit Status AVP for the PWs in question, when
   used in the ICRQ/ICRP messages, MUST always have both N and A bits
   set.

   The next sections describe the extensions to L2TPv3 for establishment
   and validation of TDM pseudowire sessions.

   There are two new AVPs for the Session Management messages.  One AVP
   describes the TDM pseudowire attributes.  The second AVP describes
   the RTP attributes for this TDM pseudowire.





Vainshtein & Galtzur        Standards Track                     [Page 3]
^L
RFC 5611                    TDM over L2TPv3                  August 2009


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 for this
   AVP SHOULD be set to 0.  The Length (before hiding) of this AVP is
   12.

   The Bit Rate field contains the value that represents the bit rate of
   the local AC in the units of 64 Kbit/s, encoded as an unsigned 16-bit
   integer.  Its usage for all types of TDM PWs employs the following
   semantics:

   1) For structure-agnostic emulation, this parameter MUST be set to
      one of the following 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 do
   not reflect the exact bit rate and are used for convenience only.

   Note: The semantics of the Bit Rate field defined above are
   consistent with those of the CEP/TDM Bit-Rate interface parameter as
   defined in [RFC5287].






Vainshtein & Galtzur        Standards Track                     [Page 4]
^L
RFC 5611                    TDM over L2TPv3                  August 2009


   The Payload Bytes field contains the value representing the number of
   TDM payload bytes in the PW packet and is used with the following
   semantics:

   1) For structure-agnostic emulation, any value of the Payload Bytes
      can be specified.

   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) In addition to that, for trunk-specific NxDS0 with Channel-
         Associated Signaling (CAS), the number of the trunk frames per
         multiframe fragment (value resulting from the Payload Bytes
         divided by the number of DS0 channels) MUST be an integer
         divisor of the number of frames per corresponding trunk
         multiframe.

   The Reserved bits MUST be set to 0 on transmission and MUST be
   ignored on reception.

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

   1) Set to '01' for the 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.  These bits 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



Vainshtein & Galtzur        Standards Track                     [Page 5]
^L
RFC 5611                    TDM over L2TPv3                  August 2009


   2) '00' for all the other TDM pseudowire types

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

       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                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Presence of this AVP indicates that 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 indicates the timestamping mode (absolute or differential)
   in the RTP header.  These modes are described in, e.g., Section 4.3.2
   of [RFC4553].  If the D bit is set to 1, then the differential
   timestamping mode is used; otherwise, the absolute timestamping mode
   is used.  Timestamping modes can be used independently for the two
   directions of a TDM PW.

   The C bit indicates the ordering of the RTP header and the Control
   Word as following:

   o If the C bit is set to 1, the RTP header appears after the Control
     Word in the data channel of the TDM pseudowire.  This mode is
     described in [RFC4553] and [RFC5086] as SAToP/CESoPSN encapsulation
     over IPv4/IPv6 PSN with L2TPv3 demultiplexing, respectively.

   o If the C bit is set to 0, the RTP header appears before the Control
     Word.  This mode 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
   indicates that the receiver shall not check payload type to detect
   malformed packets.

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



Vainshtein & Galtzur        Standards Track                     [Page 6]
^L
RFC 5611                    TDM over L2TPv3                  August 2009


   SSRC indicates the expected value of the synchronization source
   (SSRC) ID in the RTP header.  A 0 in this field means that the SSRC
   ID will not be used for detecting misconnections.  Since L2TP
   provides 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



Vainshtein & Galtzur        Standards Track                     [Page 7]
^L
RFC 5611                    TDM over L2TPv3                  August 2009


   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).










Vainshtein & Galtzur        Standards Track                     [Page 8]
^L
RFC 5611                    TDM over L2TPv3                  August 2009


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.





Vainshtein & Galtzur        Standards Track                     [Page 9]
^L
RFC 5611                    TDM over L2TPv3                  August 2009


6.  Security Considerations

   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.



Vainshtein & Galtzur        Standards Track                    [Page 10]
^L
RFC 5611                    TDM over L2TPv3                  August 2009


   [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
































Vainshtein & Galtzur        Standards Track                    [Page 11]
^L