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

Versions: 00 01

Network Working Group                                    Danny McPherson
INTERNET DRAFT                                      Amber Networks, Inc.
Category: Internet Draft                                    Suhail Nanji
Title: draft-ietf-l2tpext-svctype-01.txt          Redback Networks, Inc.
Date: April 2001



                           L2TP Service Type
                  <draft-ietf-l2tpext-svctype-01.txt>


1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of 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.


2. Abstract

   The Layer Two Tunneling Protocol (L2TP) [RFC 2661] provides a
   standard method for tunneling PPP [RFC 1661] packets.  This document
   describes an extension to L2TP which provides a mechanism to support
   tunneling of additional payload types over individual sessions within
   an L2TP tunnel.  These extensions provide added functionality which
   is optional and preserves backwards compatibility.








McPherson, Nanji                                        [Page 1]


INTERNET DRAFT                                              April 2001


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


4. Introduction

   The Layer Two Tunneling Protocol defines a mechanism for tunneling
   PPP PDUs only.  This document describes an extension which enables
   L2TP to support additional payload types.  This extension allows
   sessions to carry different payloads within the same tunnel. The
   normal operation of L2TP is not modified if the attributes described
   below are not implemented.


5. Tunnel Establishment

   The basic tunnel establishment procedures defined in [RFC 2661] are
   unchanged.  The only addition is that of a new AVP, the Service
   Capabilities List AVP, which is used for indicating which payload
   type(s) are supported on sessions of this tunnel.


5.1. Service Capabilities List (SCCRP, SCCRQ)

   The Service Capabilities List AVP is encoded as Vendor ID 311, and
   the Attribute Value is the 16-bit quantity 999 (the ID 311 reflects
   Microsoft, it should be changed to 0 and an official Attribute Value
   chosen should this specification advance on as standards track).  The
   Value is a list of supported Service Types.

   The AVP has the following format:

     Vendor ID = 311
     Attribute = 999

      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|0|0|0|0|      Length       |             311               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              999              |        Service Type 0         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              ...              |        Service Type N         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




McPherson, Nanji                                        [Page 2]


INTERNET DRAFT                                              April 2001


   The AVP MUST be present if the sender can place calls employing the
   Service Type when requested.  Presence of a given Service Type is not
   a guarantee that a given call will be placed by the sender if
   requested, just that the capability to terminate the indicated
   Service Type(s) exists.

   The AVP MAY be hidden (the H-bit may be 0 or 1). The Length (before
   hiding) of this AVP MUST be 8 octets with one Service Type specified,
   plus 2 octets for each additional Service Type.

   The Service Type and Service Capabilities AVPs described in this
   document provide the base mechanisms for other PDUs other than PPP to
   be tunneled via L2TP. In order to facilitate this in a backwards
   compatible manner, the M-bit MUST NOT be set on the Service
   Capabilities AVP unless RFC 2661 PPP tunneling is NOT supported.
   Thus, if RFC 2661 PPP tunneling is NOT supported by a particular
   implementation (or disallowed by configuration or policy), the M-bit
   MUST be set on the Service Capabilities AVP in order to ensure that
   an implementation unaware of Service Types other than PPP and/or
   requiring a Service Type for PPP tunneling would disallow
   establishment of the L2TP tunnel.

   If the sessions on this tunnel MUST use the Service Type AVP, then
   the M-bit MUST be set to 1 for the Service Capabiliites List AVP.
   This mode of operation explicitly eliminates backwards comptability
   with PPP payload sessions which do not employ the Service Type AVP.
   In this mode, sessions carrying a PPP payload MUST use the PPP
   Service Type AVP value detailed below.

   If the sessions on this tunnel MAY use the Service Type AVP, the the
   M-bit MUST be set to 0 for the Service Capabilities List AVP.  This
   mode of operation maintains backwards comptability with PPP payload
   sessions which do not employ the Service Type AVP.  In this mode,
   sessions carrying a PPP payload MAY use the PPP Service Type AVP
   value detailed below.

   If a LAC or LNS requires use of the Service Type AVP for every
   session and it receives a Service Capabilities List AVP without the
   M-bit set to 0, then the tunnel MUST be torn down.  If a LAC or LNS
   does not support the Service Type Extensions AVPs and it receives a
   Service Capabilities List AVP with the M-bit set to 1, then a tunnel
   MUST be torn down.









McPherson, Nanji                                        [Page 3]


INTERNET DRAFT                                              April 2001


6. Session Establishment

   The basic call establishment procedures defined in [RFC 2661] are
   unchanged.  A new AVP for indicating the payload type the session
   will support is defined.


6.1. Service Type (ICRQ, OCRQ)

   The Service Type AVP encodes the Service Type for the incoming or
   outgoing call.  In order to retain backwards compatibility with [RFC
   2661], if the Service Type attribute is not present, then the session
   MUST carry a PPP payload.  If the Service Capabilities List AVP had
   only the PPP Service Type, then the PPP Service Type AVP MUST be used
   for all sessions.

   An LNS MUST NOT send an OCRQ with a Service Type AVP specifying a
   value not advertised in the Service Capabilities List AVP received
   from the LAC.  Similarly, an LAC MUST NOT send an ICRQ with a Service
   Type AVP specifying a value not advertised in the Service
   Capabilities List AVP received from the LNS.  If a Service Type AVP
   is received (in an ICRQ or OCRQ) and it contains a value that has not
   been advertised for the tunnel in the Services Capabilities List AVP,
   then the session MUST be torn down.

   The value of this attribute is one of the supported Service Types.
   The Service Type AVP is encoded as Vendor ID 311, and the Attribute
   Value is the 16-bit quantity 998 (the ID 311 reflects Microsoft, it
   should be changed to 0 and an official Attribute Value chosen if this
   specification advances on as standards track).  The Service Type AVP
   MUST be located immediately following the Message Type AVP (unless it
   is hidden, in which case the Random Vector AVP will precede it).

   The Service Type value is represented by a 16-bit quantity of the
   range 0-65535.  Assignment of values within this range are defined in
   the "Service Type AVP Values" section.

      Vendor ID = 311
      Attribute = 998

       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|0|0|0|0|      Length       |             311               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              998              |        Service Type           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




McPherson, Nanji                                        [Page 4]


INTERNET DRAFT                                              April 2001


   The AVP MAY be hidden (the H-bit may be 0 or 1).  The M-bit for this
   AVP MUST be set to 1.  The Length (before hiding) of this AVP is 8.


6.2. Service Type AVP Values

   The range of potential Service Type values is 0-65535.  This document
   defines one of those values for PPP as defined in [RFC 2661].

   Service Type AVP Values

      Payload Type          Value

      Reserved              0 (zero)
      PPP                   1
      FCFS                  2-65534
      Reserved              65535

   See Section "IANA Considerations" for additional information on
   Service Type AVP values.


7. Migration to Standard Attributes

   It is intended that both the Service Capabilities List and Service
   Type attributes will be migrated to standard attributes. As a result,
   the AVPs outlined in this draft would have a Vendor ID value of 0 and
   standard Attribute Values.  Furthermore, it is intended the drafts
   "L2TP Circuit Emulation Services Extension" and "Ethernet
   Encapsulation Extensions to L2TP" will be deprecated.


8. IANA Considerations

   The Service Type AVP namespace will be registered and maintained by
   IANA as follows:

    o Values 0 and 65535 are reserved.

    o Value 1 is reserved for PPP payloads.

    o Values between 2 and 65534 are to be assigned by IANA, using
      the "Specification Required" policy listed below [RFC 2434].








McPherson, Nanji                                        [Page 5]


INTERNET DRAFT                                              April 2001


8.1. Specification Requirements for New Service Types

   To define a new Service Type for a payload other than PPP,a new RFC
   MUST be drafted which MUST:

    o Identify any new L2TP AVPs or control messases necessary for the
      establishment, maintenance, and teardown of the non-PPP session.

    o Identify which AVPs must be present (new or existing) in each
      existing or new control message with a given service type.

    o Identify any existing AVPs which have a new or revised meaning for
      a given Service Type beyond that defined in RFC2661.


9. Security Considerations

   This extension to L2TP does not changes the inherent security of L2TP,
   nor does it introduce new security issues.


10. Acknowledgements

   Thanks to W. Mark Townsley of Cisco Systems, Bill Palter of Redback
   Networks, and Nishit Vasavada and Andy Koscinski of Amber Networks.
   Copious amounts of text were stolen from the L2TP [RFC 2661].

   Special thanks to Glen Zorn for suggesting to use Microsoft's Vendor
   ID for the new AVPs in the interim.


11. References

   [RFC 2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
              B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC2661,
              August 1999.

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

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

   [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
              an IANA Considerations section in RFCs", BCP 26, RFC
              2434, October 1998.






McPherson, Nanji                                        [Page 6]


INTERNET DRAFT                                              April 2001


12. Authors' Address

   Danny McPherson
   Amber Networks, Inc.
   48664 Milmont Drive
   Fremont, CA 94538
   Phone: +510 687-5200
   Email: danny@ambernetworks.com

   Suhail Nanji
   Redback Networks, Inc.
   350 Holger Way
   San Jose, CA  95134-1362
   Phone: +1 408 571 5413
   Email: suhail@redback.com




































McPherson, Nanji                                        [Page 7]


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