[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ieft-l2tpext-tdm

   Network Working Group
   Internet Draft                                            S. Galtzur
   Document: draft-galtzur-l2tpext-tdm-01.txt           Axerra Networks
   Expires: April 2005                                     October 2004


          Layer Two Tunneling Protocol - Setup of TDM Pseudowires

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC-2026 [RFC2026].

   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.


Abstract

   This document defines extensions to the Layer Two Tunneling Protocol
   (L2TP) for support of structure-agnostic [PWE3-SATOP] and structure-
   aware [PWE3-CESoPSN], [PWE3-TDMoIP] pseudowires.


Conventions used in this document

   In this document we refer to control plane as the packets that
   contain control information (via AVP) and the mechanism that handle
   these packets.
   In this document we refer to the data plane as the packets that
   contain transported user data.



Galtzur                  Expires - April 2005                 [Page 1]


                                L2TP TDM                   October 2004


   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...................................................2
   2. L2TP Extension.................................................2
      2.1 TDM PW AVP  [ICRQ, OCRQ]...................................3
      2.2 RTP AVP  [ICRQ, OCRQ, ICRP, OCRP]..........................4
      2.3 Changes in the Control Connection AVPs.....................5
      2.4 Changes in the Session Connection AVPs.....................5
   3. Creation of the TDM Pseudowire Session.........................5
   4. IANA Considerations............................................6
   Security Considerations...........................................6
   References........................................................6
   Acknowledgments...................................................7
   Author's Addresses................................................7


1. Introduction

   This document defines extensions to the Layer Two Tunneling Protocol
   (L2TP) for support of structure-agnostic [PWE3-SATOP] and structure-
   aware [PWE3-CESoPSN], [PWE3-TDMoIP] pseudowires.

2. L2TP Extension

   The L2TP Control Connection is responsible for 3 main operations:
   1. Establishment and validation of session.
   2. Ending (tearing down) of session.
   3. Transferring of End Point status.

   Tearing down of session is identical to [L2TP].

   [PWE3-CESoPSN] and [PWE3-SATOP] describe how to transfer the END
   Point status via the Data Plane. This is therefore RECOMMENDED to not
   use the Set-Link-Info (SLI) described in [L2TP].

   The next sections describe the extensions to the L2TP for
   establishment and validation of TDM Pseudowire sessions.

   There are 2 new AVPs for the Session Connection Messages. One AVP
   describe the TDM Pseudowire attributes. The second AVP describe the
   RTP attributes for this TDM Pseudowire.







Galtzur                  Expires - April 2005                 [Page 2]


                                L2TP TDM                   October 2004


2.1 TDM PW 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 [TBD]  |R|T|F|   Reserved              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         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.

   Bit Rate is defined in [PWE3-IANA]. Its usage for all types of TDM
   PWs assumes the following semantics:
   1. This interface parameter MAY be omitted, if the attachment circuit
      bit-rate is unambiguously derived from the PW Type.
   2. Only the following values MUST be specified for structure-agnostic
      emulation (see [PWE3-SATOP]:
      a. Structure-agnostic E1 emulation  - 32
      b. Structure-agnostic T1 emulation:
         1. MUST be set to 24 for the basic emulation mode
         2. MUST be set to 25 for the "Octet-aligned T1" emulation mode
      c. Structure-agnostic E3 emulation  - 535
      d. Structure-agnostic T3 emulation  - 699
   3. For all kinds of structure-aware emulation, this parameter MUST be
      set to the number of DS0 channels in the corresponding attachment
      circuit.

   Note: for Structure-agnostic T1 emulation the value 24 does not
   indicate the exact bit rate, and is used for convenience only.

   Payload Bytes has been initially defined for CEP [PWE3-SONET] PWs.
   It can be used for setup of all types of TDM PWs without any changes
   in its encoding (see [PWE3-IANA]) with the following semantics:

   1. For Structure-agnostic emulation the payload type can be any
      value.
   2. For CESoPSN PWs:
      a. The specified value MUST be an integer multiple of number of
         DS0 channels in the corresponding attachment circuit.
      b. For trunk-specific NxDS0 with CAS, (Payload Bytes/number of DS0
         channels) must be an integer factor of the number of frames per
         corresponding trunk multiframe
   3. For TDMoIP the Payload Bytes must be an integer multiple of 48



Galtzur                  Expires - April 2005                 [Page 3]


                                L2TP TDM                   October 2004



   The R bit defines the present of the RTP header.  If the R bit is 1
   then the RTP header is present and the RTP AVP MUST appear.  If the R
   bit is zero then the RTP header is not used.

   The T bit is ignored and MUST be set to zero.

   The F bit indicates fragmentation when sending multiframe. The F bit
   MUST be zero for all TDM PWs Types excluding trunk-specific NxDS0
   services with CAS using the CESoPSN encapsulation. In case of these
   services, the F bit MUST be set if the payload size specified value
   differs from the number of frames per trunk multiframe.

2.2 RTP 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 [TBD]  |D|     PT      |   Reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Reserved              |   Timestamp Clock  Frequency  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              SSRC                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This AVP MUST appear only if the RTP header is used.
   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 differential time stamping in the RTP header.  If
   the D bit is set to 1 then the time stamping is differential.
   Otherwise absolute time stamping is used.  Differential mode can be
   used only if both sides use RTP and use differential time stamping.

   PT is the payload type expected in the RTP header.  Value of zero
   indicates that the payload type is ignored and will not be used to
   detect malformed packets.
   Timestamp Clock Frequency is the clock frequency used for the time
   stamping in 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
   misconnections. Since L2TP provides an alternative security mechanism
   via the cookies, if the cookie length is larger then zero the SSRC
   SHOULD be zero.



Galtzur                  Expires - April 2005                 [Page 4]


                                L2TP TDM                   October 2004


2.3 Changes in the Control Connection AVPs

   Control Connection that support TDM MUST add the appropriate PW Type
   value to the list in the Pseudowire Capabilities List AVP. The exact
   value is TBD by IANA and is 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 [PWE3-SATOP] of:
      a. E1 circuits - TBA by IANA
      b. T1 circuits - TBA by IANA
      c. E3 circuits - TBA by IANA
      d. T3 circuits - TBA by IANA
   2. Structure-aware emulation [PWE3-CESoPSN], [PWE3-TDMoIP] of:
      a. CESoPSN basic mode - TBA by IANA
      b. TDMoIP basic mode - TBA by IANA
      c. CESoPSN service with CAS - TBA by IANA
      d. TDMoIP with CAS - TBA 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.

3. Creation of the TDM Pseudowire Session

   When LCCE wants to open a Session for TDM PW it should include the
   TDM PW AVP and the RTP AVP (if needed) in the ICRQ or OCRQ message.
   The LCCE peer must validate that TDM PW AVP and make sure it can
   supply the requirements derived from the RTP AVP (if any exist).  If
   the peer agrees with the CESoPSN AVP it will send an appropriate ICRP
   or OCRP message with RTP AVP (if needed). The Initiator need 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 MUST be equal on both sides.
   2. The Flavor bit MUST be equal on both sides
   3. The Payload Bytes and the R bit MAY NOT be the same.

4. IANA Considerations

   This draft requires assignment of the following values by IANA:

   1. PW types listed in Section 2.1 above.
   2. New attribute IDs for TDM PW and and RTP AVPs.


Galtzur                  Expires - April 2005                 [Page 5]


                                L2TP TDM                   October 2004




Security Considerations

   There are no additional security considerations on top of the ones
   discussed in [L2TP]

Copyright notice

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


References

   [RFC2026]      Bradner, S., "The Internet Standards Process --
                  Revision 3", BCP 9, RFC 2026, October 1996.

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

   [L2TP]         J. Lau, M. Townsley, I. Goyret , Layer Two  Tunneling
                  Protocol (Version 3),  Work in Progress,  draft-ietf-
                  l2tpext-l2tp-base-14.txt, June 2004

   [PWE3-CESoPSN] A. Vainshtein et al, Structure-aware TDM Circuit
                  Emulation Service over Packet Switched Network
                  (CESoPSN), Work in progress, July 2004, draft-ietf-
                  pwe3-cesopsn-01.txt

    [PWE3-SATOP]  A. Vainshtein, Y. Stein, Structure-Agnostic TDM over
                  Packet (SAToP), Work in Progress, December 2003,
                  draft-ietf-pwe3-satop-01.txt

   [PWE3-TDMoIP]  Y. Stein et al, TDM over IP, Work in progress, draft-
                  ietf-pwe3-tdmoip-01.txt, February 2004.

   [PWE3-IANA]    L. Martini, M. Townsley, IANA Allocations for pseudo
                  Wire Edge to Edge Emulation (PWE3), Work in progress,
                  October 2004, draft-ietf-pwe3-iana-allocation-07.txt


Galtzur                  Expires - April 2005                 [Page 6]


                                L2TP TDM                   October 2004




Acknowledgments

   I thank Alexander ("Sasha") Vainshtein for reviewing this text.

Author's Addresses

   Sharon Galtzur
   Axerra Networks
   24 Raoul Wallenberg St.,
   Tel Aviv 69719, Israel
   Email: sharon@axerra.com







































Galtzur                  Expires - April 2005                 [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/