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

Versions: 00

Network Working Group                                    Nishit Vasavada
INTERNET DRAFT                                      Amber Networks, Inc.
                                                               Jim Boyle
                                            Level 3 Communications, LLC.
                                                            Chris Garner
                                                    Qwest Communications
                                                          Serge Maskalik
                                                              iVMG, Inc.
                                                              Vijay Gill
                                          Metromedia Fiber Network, Inc.

                                                           February 2001



                   Frame Relay Service Type for L2TP
              <draft-vasavada-l2tpext-fr-svctype-00.txt>


1. Status of this Memo

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

   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.

2. Abstract

   The Layer Two Tunneling Protocol (L2TP) [1] provides a standard
   method for tunneling PPP [2] packets.  In accordance with the L2TP
   Service Type specification [3], this document provides a solution
   for transporting Frame Relay (FR) [4] over a session in an L2TP
   tunnel.

3. Specification of Requirements

   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 [5].

4. Introduction

   The Layer Two Tunneling Protocol (L2TP) [1] provides a standard
   method for tunneling PPP [2] packets.  The L2TP Service Type [3]

Vasavada, et al.                                                [Page 1]

INTERNET DRAFT                                             February 2001


   allows layer 1 and layer 2 traffic to be tunneled through an L2TP
   tunnel.

   This document presents a solution to carry the ever popular Frame
   Relay circuit traffic over the IP network through the features
   offered by L2TP and the Service Type attribute.

   It talks about the use of [3] for setting up an L2TP tunnel and
   session containing FR traffic, and the signaling of some of the
   Frame Relay parameters.

5. FR Service Type

   A FR Service Type value of [TBD] MUST be used.  The encoding of the
   Service Type AVP remains as specified in [3].

6. Tunnel Establishment

   The basic tunnel establishment procedures defined in [1] and [3] are
   unchanged.  The FR Service Type value [TBD] MUST be included in the
   Service Capabilities List AVP.

7. Session Establishment

   The basic call establishment procedures defined in [1] and [3] remain
   unchanged.  The FR Service Type value [TBD] MUST be used in the
   Service Type AVP of an ICRQ or OCRQ.

7.1. Use of the Sub-Address AVP

   As specified in [1], the Sub-Address AVP, Attribute Type 23, is
   included in ICRQ or OCRQ and is used to encode additional dialing
   information.  For the purpose of this specification, the Sub-Address
   AVP will be used to encode the source and destination DLCI numbers,
   and interface information.

   Additional non-addressing information is discussed in the following
   sections.

   The Sub-Address AVP is encoded as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|H| rsvd  |      Length       |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           23                  |        Attribute Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          [until Length is reached]...                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The attribute value may be a simple ASCII string.  For example, a
   source interface serial 1/1 and DLCI 100, and a destination interface
   serial 1/1 with DLCI 200 could be represented as "serial 1/1 DLCI
   100, serial 1/1 DLCI 200".  The format of the information contained

Vasavada, et al.                                                [Page 2]

INTERNET DRAFT                                             February 2001


   in this AVP should be agreed on by the administrators at the two L2TP
   peers.

   When employing the Sub-Address AVP for this purpose, the AVP is
   mandatory (the M-bit MUST be set to 1).  The AVP MAY be hidden (the
   H-bit set to 0 or 1).

7.2. FR Payload Message Format

   The L2TP payload header format defined in [1] remains unchanged while
   carrying data for a Frame  Relay circuit.  Entire Frame Relay PDU
   will be carried, subject to the following requirements:

   When transporting FR frames over an L2TP session the following rules
   MUST be followed:

   o All the Frame Relay packets will be preceded by a four byte code
     [TBD] in the L2TP payload packet.  This code will allow L2TP to
     de-multiplex if additional functionality has to be added in future
     for signaling (please see the signaling and LMI sections).

   o The beginning and ending FR 'Flag' fields (one octet each) MUST be
     removed from the FR frame before it is encapsulated as L2TP
     payload.  The destination LAC/LNS MUST insert new flags when
     reconstructing the FR frame for transmission to the FRAD.

   o The FCS field MUST be removed from the FR frame before it is
     carried in L2TP  It MUST be recalculated at the other end.  This
     does create a potential problem since L2TP does not offer checksum,
     and UDP checksum is optional.  Work is needed in this area to
     guarantee integrity of the packet on the remote side.

  The encapsulated Frame Relay packet looks like this:


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|L|x|x|S|x|O|P|x|x|x|x|  Ver  |          Length (opt)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tunnel ID           |           Session ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Ns (opt)          |             Nr (opt)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Offset Size (opt)        |    Offset pad... (opt)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Four byte code [TBD]                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           FR Header
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                                      |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         FR Payload...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Vasavada, et al.                                                [Page 3]

INTERNET DRAFT                                             February 2001


   As is true for the PPP traffic carried by L2TP, the frame size should
   consider the MTU and the additional headers to avoid IP
   fragmentation.

7.3. FR Local Management Interface (LMI)

   This draft does not discuss the LMI implications.  Future work is
   necessary in this area.

8. Effects on Standard AVPs

   If FR frames are being tunneled in accordance with this document,
   then the following Call Management AVPs MAY be ignored:

     Bearer Type
     Framing Type
     Called Number
     Calling Number
     Initial Received LCP CONFREQ
     Last Sent LCP CONFREQ
     Last Received LCP CONFREQ
     Proxy Authen Type
     Proxy Authen Name
     Proxy Authen Challenge
     Proxy Authen ID
     Proxy Authen Response
     ACCM

9. Future work

   This section provides a list of things we need work on:

    o Signaling: The interface and DLCI information is conveyed through
      L2TP control packets.  However, the frame parameters such as CIR,
      Be, and Bc related information is not covered.

    o LMI through the network

    o Data integrity (as mentioned in FR Payload Message Format section,
      currently there is no way to verify the data integrity due to
      lack of FR FCS, L2TP checksum, and optional UDP checksum.

10. Security Considerations

   All the underlying L2TP Security considerations remain, though no
   'new' ones are introduced?

11. IANA Considerations

   To be completed.

12. Acknowledgments

   Many thanks to Danny McPherson, Chi Fai Ho and Himansu Sahu for
   their help in reviewing this draft.

Vasavada, et al.                                                [Page 4]

INTERNET DRAFT                                             February 2001


13. References

   [1] Townsley, et. al., "Layer Two Tunneling Protocol L2TP", RFC
       2661, February 1999.

   [2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
       RFC 1661, July 1994.

   [3] McPherson D., Nanji S., "L2TP Service Type", "Work in
       Progress", August 2000.

   [4] Frame Relay, ANSI T1.618

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

14. Authors' Addresses

   Nishit Vasavada
   Amber Networks, Inc.
   48664 Milmont Drive
   Fremont, CA 94538
   Phone: +1 510.683.8698
   Email: nishit@ambernetworks.com

   Jim Boyle
   Level 3 Communications, LLC.
   1025 Eldorado Blvd.
   Broomfield, CO 80021
   Phone: +1 720.888.1192
   Email: jboyle@level3.net

   Serge Maskalik
   iVMG, Inc.
   1020 Rincon Circle
   San Jose, CA 95131
   Phone: +1 408.468.0480
   Email: serge@ivmg.net

   Chris Garner
   Qwest Communications
   950 Seventeenth Street, 21 Floor
   Denver, CO 80202
   Email: cgarner@qwest.net

   Vijay Gill
   Metromedia Fiber Network, Inc.
   8075 Leesburg Pike
   Vienna, VA 22182
   Phone: +1 410.262.0660
   Email: vgill@mfnx.net





Vasavada, et al.                                                [Page 5]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/