Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires
draft-ietf-l2tpext-tdm-07

TDM over L2TPv3                 April 2009 
 
 
   Network Working Group                                  A. Vainshtein 
   Internet Draft                                           ECI Telecom 
   Document: draft-ietf-l2tpext-tdm-07.txt                   S. Galtzur 
                                                              Rebellion 
                                                                        
   Creation Date:                                        April 14, 2009 
   Intended Status:                                   Proposed Standard 
   Expires:                                                October 2009 
    
    
      Layer Two Tunneling Protocol version 3 - Setup of Time-Division 
                       Multiplexing (TDM) Pseudowires 
    
Status of this Memo 
    
   This Internet-Draft is submitted to IETF in full conformance with the 
   provisions of BCP 78 and BCP 79. 
    
   Internet-Drafts are working documents of the Internet Engineering  
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-   
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months  
   and may be updated, replaced, or obsoleted by other documents at any   
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at    
   http://www.ietf.org/ietf/1id-abstracts.txt. 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
   This Internet-Draft will expire on October 14, 2009. 
    
    
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. 
 
 
Vainshtein and Galtzur  Expires - October 2009                [Page 1] 

                           TDM over L2TPv3                 April 2009 
 
 
    
   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. 
    
Abstract 
    
   This document defines extensions to the Layer Two Tunneling Protocol 
   version 3 (L2TPv3) for support of structure-agnostic and structure-
   aware (CESoPSN style) Time-Division Multiplexing (TDM) pseudowires. 
   Support of structure-aware (TDMoIP style) pseudowires over L2TPv3 is 
   left for further study. 
    
    
Legal 
 
   This documents and the information contained therein are provided on    
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE    
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE    
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL    
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY    
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE    
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS    
   FOR A PARTICULAR PURPOSE. 
 
Conventions used in this document 
    
   In this document we refer to control plane as the packets that 
   contain control information (via Attribute-Value pairs (AVP)) and the 
   mechanism that handles these packets.  
   In this document we refer to the data plane as 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]. 
    
Table of Contents 
    
   1. Introduction...................................................3 
   2. L2TPv3 Extension...............................................3 
 
 
Vainshtein and Galtzur  Expires - October 2009                [Page 2] 

                           TDM over L2TPv3                 April 2009 
 
 
      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 AVPs.....................7 
      2.4 Changes in the Session Connection AVPs.....................7 
   3. Creation of the TDM Pseudowire Session.........................7 
   4. IANA Considerations............................................8 
   5. Congestion Control.............................................9 
   6. Security Considerations........................................9 
   7. Acknowledgements...............................................9 
   Normative references..............................................9 
   Informative references...........................................10 
   Authors' Addresses...............................................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, and 
   Circuit Emulation Service  over packet-Switched Networks (CESoPSN) 
   structure-aware encapsulation - 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 encapsulations 
   described in [RFC5087] has been left for further study.  
    
   Setup and maintenance of TDM PWs in MPLS networks using LDP is 
   described in [RFC5287]. 
    
    
2. L2TPv3 Extension 
    
   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 session for a TDM pseudowire performed as described 
   in [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. 
    
 
 
Vainshtein and Galtzur  Expires - October 2009                [Page 3] 

                           TDM over L2TPv3                 April 2009 
 
 
   [RFC3931] specifies that the Circuit Status Attribute-Value Pair 
   (AVP) MUST be present in the ICRQ/ICRP 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.  
    
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 (AVP-TBA-1)   |         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) Only the following values MUST be specified for structure-
     agnostic emulation (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.  
 
 
Vainshtein and Galtzur  Expires - October 2009                [Page 4] 

                           TDM over L2TPv3                 April 2009 
 
 
    
   Note: The semantics of the Bit Rate field defined above are 
   consistent with those of the Bit Rate Interface Attribute as defined 
   in [RFC5287]. 
    
   The Payload Bytes field contains the value representing the number of 
   the 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 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 following: 
  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 e CESoPSN PW carrying both TDM data and 
     signaling packets 
  4) Set to '00' for 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: 
  1) For trunk-specific CESoPSN with CAS these bits MUST be set to: 
     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) MUST be set to '00' for all the other TDM pseudowire types.  
 
 
 
Vainshtein and Galtzur  Expires - October 2009                [Page 5] 

                           TDM over L2TPv3                 April 2009 
 
 
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 (AVP-TBA-2)  |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., in [RFC4553], 
   Section 4.3.2. 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 as SAToP/CESoPSN encapsulation over 
     IPv4/IPv6 PSN with L2TPv3 demultiplexing in [RFC4553] and 
     [RFC5086] respectively.  
    o If the C bit is set to 0 the RTP header appears before the 
     control word.  This mode described as the old mode of the 
     SAToP/CESoPSN encapsulation over L2TPv3 in [RFC4553], Appendix 
     A, and [RFC5086], Annex C, respectively.   
    
   PT is the payload type expected in the RTP header.  A value of zero 
   indicates that the receiver shall not check payload type to detect 
   malformed packets. 
    
   Timestamp Clock Frequency is the clock frequency used for the time 
   stamping in units of 8 KHz. 
    
   SSRC indicates the expected value of SSRC ID in the RTP header.  A 
   zero in this field means that SSRC ID will not be used for detecting 
 
 
Vainshtein and Galtzur  Expires - October 2009                [Page 6] 

                           TDM over L2TPv3                 April 2009 
 
 
   misconnections. Since L2TP provides an alternative security mechanism 
   using cookies, if the cookie length is larger than zero the SSRC 
   SHOULD be zero. 
    
2.3 Changes in the Control Connection 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 Connection AVPs 
    
   PW Type AVP should be set to one of the following values: 
   1. Structure-agnostic emulation [RFC4553] of: 
      a. E1 circuits - TBA-SAToP-E1 by IANA  
      b. T1 circuits - TBA-SAToP-T1 by IANA  
      c. E3 circuits - TBA-SAToP-E3 by IANA  
      d. T3 circuits - TBA-SAToP-T3 by IANA  
   2. Structure-aware emulation [RFC5086] of: 
      a. CESoPSN basic mode - TBA-CESoPSN-Basic by IANA  
      b. Trunk-specific CESoPSN service with CAS - TBA-CESoPSN-
         CAS by IANA 
    
   TDM pseudowires use their own control word.  Therefore the L2-
   Specific Sublayer AVP MUST either be omitted or set to zero. 
    
   TDM pseudowires use their own sequencing.  Therefore the Data 
   Sequencing AVP MUST either be omitted or set to zero. 
    
   Note: The Control Word (CW) used in the SAToP and CESoPSN 
   encapsulations over L2TPv3 effectively represents a dedicated L2-
   Specific Sub-layer.  
    
3. Creation of the TDM Pseudowire Session 
    
   When LCCE wants to open a Session for 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 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 message with the matching 
   RTP AVP (if needed). The Initiator need to validate that it can 
   supply the requirements derived from the received RTP AVP. 
 
 
Vainshtein and Galtzur  Expires - October 2009                [Page 7] 

                           TDM over L2TPv3                 April 2009 
 
 
    
   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 return code 
      RC-TBD-1 and error code EC-TBD-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 return code RC-TBD-1 and error code EC-TBD-2. 
   3. If one side does not support the payload bytes value proposed 
      by the other one, the connection will be rejected with return 
      code RC-TBD-1 and error code EC-TBD-3. 
   4. If one side cannot send RTP header as requested by the other 
      side, the connection will be rejected with return code RC-
      TBD-1 and error code EC-TBD-4. 
   5. If one side can send RTP header but not with the requested 
      timestamp clock frequency, the connection will be rejected 
      with return code RC-TBD-1 and error code EC-TBD-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 use or not use RTP header (and accordingly, 
      include or not include the RTP AVP). 
   
    
4. IANA Considerations 
 
   This draft requires assignment of the following values by IANA: 
    
   New L2TPv3 Pseudowire Types: 
    
       0x0011 (TBA-SAToP-E1)      - Structure-agnostic E1 circuit 
       0x0012 (TBA-SAToP-T1)      - Structure-agnostic T1 (DS1) circuit 
       0x0013 (TBA-SAToP-E3)      - Structure-agnostic E3 circuit 
       0x0014 (TBA-SAToP-T3)      - Structure-agnostic T3 (DS3) circuit 
       0x0015 (TBA-CESoPSN-Basic) - CESoPSN basic mode 
       0x0017 (TBA-CESoPSN-CAS)   - CESoPSN TDM with CAS 
       
   Note that the values listed are suggested to match with the values     
   defined in [RFC4446] for the MPLS Pseudowire Types. 
    
   New attribute value pair IDs: 
 
 
Vainshtein and Galtzur  Expires - October 2009                [Page 8] 

                           TDM over L2TPv3                 April 2009 
 
 
    
   1. AVP-TBD-1 - TDM Pseudowire AVP 
   2. AVP-TBD-2 - RTP AVP 
    
   New return codes for the CDN message: 
    
   1. RC-TBD-1 - return code to indicate connection refused 
      because of TDM PW parameters. The error code indicates the 
      problem. 
  
   TDM PW Specific error codes, to be used with the RC-TDB-1 return 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. 0 - Reserved 
   1. EC-TBD-1 - Bit Rate values disagree. 
   2. EC-TBD-2 - Different trunk types in the case of trunk-
     specific CESoPSN with CAS 
   3. EC-TBD-3 - Requested payload size too big or too small. 
   4. EC-TBD-4 - RTP header cannot be generated. 
   5. EC-TBD-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 document specifies only the L2TPv3-based control plane for setup 
   of TDM PWs. Within this scope, there are no additional security 
   considerations on top of 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 usage of cookies.  
    
7. Acknowledgements 
   The authors want to thank Carlos Pignataro, Ignacio Goyret and Yaakov 
   Stein for careful review and useful suggestions. 
 
Normative references 
    
 
 
Vainshtein and Galtzur  Expires - October 2009                [Page 9] 

                           TDM over L2TPv3                 April 2009 
 
 
   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate  
                  Requirement Levels", BCP 14, RFC 2119, March 1997 
    
   [RFC3931]      J. Lau, M. Townsley, I. Goyret, Layer Two Tunneling 
   Protocol - Version 3 (L2TPv3), March 2005 
    
   [RFC5086]   A. Vainshtein et al, Structure-aware TDM Circuit 
               Emulation Service over Packet Switched Network  
               (CESoPSN), RFC 5086, December 2007 
    
   [RFC4553]   A. Vainshtein, Y. Stein, Structure-Agnostic TDM over  
               Packet (SAToP), RFC 4553, June 2006 
    
Informative references 
  
   [RFC5087]   Y. Stein et al, TDM over IP, RFC 5087, December 2007. 
     
   [RFC4446]   L. Martini, M. Townsley, IANA Allocations for Pseudo 
               Wire Edge to Edge Emulation (PWE3), RFC 4446,  
               April 2006 
    
   [RFC5287]   A. Vainshtein, Y. Stein, Control Protocol Extensions 
               for Setup of TDM Pseudowires in MPLS Networks, RFC 5287, 
               August 2008 
    
   [RFC5226]   T. Narten, H. Alvestrand, Guidelines for Writing an IANA 
               Considerations Section in RFCs, RFC 5226, May 2008  
    
    
Authors' Addresses 
    
   Sharon Galtzur 
   Rebellion Inc. 
   29 The Chilterns, Gloucester Green,  
   Oxford, OX1 2DF, UK 
   Email: sharon.galtzur@rebellion.co.uk 
    
   Alexander Vainshtein, 
   ECI Telecom, 
   30 ha-Sivim St. PO Box 500,  
   Petah-Tiqva 49517, Israel 
   Email: Alexander.Vainshtein@ecitele.com 
     
 
 
Vainshtein and Galtzur  Expires - October 2009               [Page 10]