One document matched: draft-ietf-pppext-l2tpmsgext-00.txt

PPP Working Group                                         Richard Shea
INTERNET DRAFT                                         Nortel Networks
Category: Internet Draft
Title: draft-ietf-pppext-l2tpmsgext-00.txt
Date: November 1998


                 Framework for L2TP Message Extensions


Status of this Memo

   This document is an Internet-Draft.  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.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ftp.ietf.org, nic.nordu.net, ftp.nisc.sri.com, or
   munnari.oz.au.

Abstract

   The Layer Two Tunneling Protocol (L2TP) defines mechanisms for
   extensibility.  The mechanisms provided are for Attribute-Value
   Pair (AVP) fields received in control messages to be set as
   Mandatory or not.  This document specifies a mechanism whereby an
   L2TP implementation can signal its support of the set of L2TP
   extensions that it supports.  This then allows the L2TP
   implementations to use extensions such as L2TP message types not
   defined in [1], the presence of existing AVPs in messages they are
   not currently defined to be in, and the definition of new AVPs that
   can be marked as Mandatory, beyond those defined in [1].

1. Introduction

   In the L2TP protocol AVPs include a bit specifying whether or not
   the AVP is mandatory.  To do this, a bit in the AVP called the M
   bit is used.  If the M bit is set in a received AVP and the AVP is


Shea                        expires May 1999                 [Page  1]


INTERNET DRAFT                                           November 1998



   unrecognized then the receiving implementation either tears down
   the tunnel or a call, depending on the value of the Call ID field
   in the control message.  If the M bit is not set in a received AVP
   and the AVP is unrecognized then the receiving implementation
   ignores the AVP as if it hadn't appeared in the control message.

   Since the Message Type AVP found first in a control message must
   have the M bit set, an L2TP implementation cannot safely send a
   control message not defined in [1] without first determining that
   the peer will understand the message.  A signaling mechanism must
   therefore be defined which allows this information to be known.

   There may also be the need for extensions of L2TP to define new
   AVPs that are defined to be sent with the M bit set.  Again, this
   cannot be safely done unless the implementation first determines
   that the peer should be able to handle the AVP.  In this case a
   signaling mechanism is required.

   Another behavior that can be enabled by the signaling of supported
   extensions is the presence of previously defined AVPs in control
   messages that they are not currently defined to be found in.

   By providing a predefined signaling mechanism future extensions can
   specify the use of AVPs with mandatory and optional AVPs defined
   and the use of message types not defined in [1].  This in turn
   should make extensions to L2TP easier to implement and operate
   under a common framework.

   This document does not attempt to limit the design of future
   extensions to the mechanisms defined within.  The purpose is to
   provide a common framework for extensions that optionally add new
   message types and that require AVPs with the M bit set, but only if
   the both peers support the extension.  For example, it is
   completely acceptable for an extension to specify the sending of a
   new AVP with the M bit set without knowing if the peer supports the
   option.  In this case it would be understood that the nature of the
   extension is such that the desired behavior for a receiving peer
   that did not understand the new AVP would be to close the tunnel or
   the call as appropriate.

1.1 Conventions

   The following language conventions are used in the items of
   specification in this document:

      o   MUST, SHALL, or MANDATORY -- This item is an absolute
         requirement of the specification.



Shea                        expires May 1999                 [Page  2]


INTERNET DRAFT                                           November 1998



      o   SHOULD or RECOMMEND -- This item should generally be followed
         for all but exceptional circumstances.

      o   MAY or OPTIONAL -- This item is truly optional and may be
         followed or ignored according to the needs of the implementor.

1.2 Terminology

   This draft assumes the reader is knowledgable about terms found in
   [1].

2. Protocol additions

   This document specifies the use of a new AVP called the Extensions
   AVP that can be sent in the Start-Control-Channel-Request (SCCRQ)
   and Start-Control-Channel-Reply (SCCRP) control messages.  The
   purpose of this new AVP is to signal to the peer the extensions
   supported by the sending implementation.

   Extensions

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0|   6 + value len   |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            [TBD]              |   Bit string of supported
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              extensions                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Extensions AVP encodes the L2TP extensions supported by the
   sending implementation.  This AVP is not marked as Mandatory.  The
   AVP itself is optional in the SCCRQ and SCCRP control messages.
   The value field of this AVP is a bit string of the supported
   options.  The bits will be assigned to extensions starting with the
   most significant bit of the first octet of the value field.  If the
   bit corresponding to an extension is set to one (1) the extension
   is supported by the sender.  If the bit is set to zero (0) the
   extension is not supported by the sender.  The value field can
   essentially be right-padded with zero bit values in order to make
   the number of octets making up the value field produce reasonable
   data alignment in the control message.  It is expected that until
   more than 16 extensions are defined the value field will most
   commonly be 2 octets.

   Extensions Value



Shea                        expires May 1999                 [Page  3]


INTERNET DRAFT                                           November 1998



    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |W|       0 (unassigned)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   W (Dynamic Data Window) Extension

   The most significant bit of the first byte of the Extensions AVP
   value field signals whether or not the L2TP dynamic data window
   adjustment [2] extension is supported.


3. Protocol Operation

   An L2TP implementation can signal the L2TP extensions it supports
   using the Extensions AVP.  For the tunnel initiator this AVP MAY be
   sent in the SCCRQ.  For the tunnel responder this AVP MAY be found
   in the SCCRP.

   The SCCRQ MUST NOT contain any AVPs that would require the peer to
   support a particular extension that would be signaled using the
   Extensions AVP.  Depending on the requirements of the extension,
   AVPs NOT marked as Mandatory that are specific to a particular
   extension MAY be included in the SCCRQ.

   An implementation MUST NOT include an AVP in a control message that
   it is not previously defined to be included in, even if the AVP
   itself is previously defined, without first signaling the support
   of such an extension with the Extensions AVP.

4. Security Considerations

   Security is not addressed in this document.

References

   [1] A. Valencia, et al, "Layer Two Tunneling Protocol", Work In
       Progress: draft-ietf-pppext-l2tp-12.txt, October 1998

   [2] R. Shea, "L2TP Dynamic Data Window Adjustment", Work In
       Progress: draft-ietf-pppext-l2tpdwin-01.txt, November 1998

Author's Address

   Richard Shea
   Nortel Networks


Shea                        expires May 1999                 [Page  4]


INTERNET DRAFT                                           November 1998



   125 Nagog Park
   Acton, Massachusetts 01720
   rshea@BayNetworks.com















































Shea                        expires May 1999                 [Page  5]


INTERNET DRAFT                                           November 1998