PPP Working Group                                       W. Mark Townsley
INTERNET DRAFT                                             Cisco Systems
Category: Internet Draft                               William L. Palter
Title: draft-ietf-pppext-l2tp-link-00.txt                Network Alchemy
Date: November 1998


                          L2TP Link 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 physical separation of the LAC and LNS with L2TP[2] and logical
   separation of the responsibilities of each with respect to negotiated
   link parameters introduces a lack of awareness between the tunnel
   endpoints that does not exist in a typical PPP dialup device. When
   possible, Proxy LCP provides a manner in which to negotiate link
   parameters at the LAC and communication of these in full to the LNS.
   If these options can be made acceptable to the LNS, then there should
   not be any insurmountable difficulty with regard to mismatch of link
   expectations. However, given that there are instances where
   negotiation of LCP[1] must take place at the LNS, some direction by
   the LAC as to what parameters are acceptable, as well as some
   communication from the LNS as to what parameters have been
   negotiated, is desirable.

Table of Contents

   1.0  Introduction
   2.0  Communicating desired link parameters from the LAC to the LNS
   2.1  LCP Want Options
   2.2  LCP Allow Options
   2.4  Communicating negotiated link parameters from the LNS to the LAC






Townsley, Palter            expires May 1999                     [Page 1]


INTERNET DRAFT                                             November 1998


1.0 Introduction

   For the majority of topologies today, the Bearer Type, Bearer
   Capabilities, Framing Type, ACCM, and Framing Capabilities AVPs
   defined in the L2TP base specification communicate sufficient
   information between the LAC and LNS for a typical analog or digital
   dialup link with HDLC-like framing[3]. Defaults for PPP LCP options
   such as MRU, ACFC and PFC are well understood for various bearer and
   framing types and are utilized in the event that LCP negotiation by
   the LNS must occur.

   For some L2TP applications and, specifically, some PPP media types,
   particular link capabilities and requirements may need to be sent
   from the LAC to the LNS in order for the LNS to properly initialize
   negotiation of LCP. Further, the LCP options negotiated may need to
   be transmitted back to the LAC so that it may make allowances at the
   physical link if necessary.

   LCP options may be classified into roughly three different categories
   with respect to their affect on L2TP; (1) options which affect
   framing in a way that the LAC may need to know about or handle
   specifically (e.g., ALT-FCS, ACCM, MRU), (2) options that are
   transparent to the LAC (e.g., AUTH-TYPE), and (3) options that the
   LAC may wish to influence because they are dependent on the media
   type (ACFC, PFC). We are most concerned about options which fall into
   category (1) and (3).

   This document defines new AVPs to allow the LAC and the LNS to
   communicate complete LCP information in order to react accordingly.
   LCP option information is structured in the same way as the Proxy LCP
   AVPs are in the base L2TP specification. This essentially involves
   encapsulation of a PPP LCP Configure- Request or Configure-Ack packet
   within an L2TP AVP.

1.1 Conventions

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

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

2.0 Communicating desired link parameters from the LAC to the LNS

   The LAC may utilize the following AVPs within an ICCN or OCCN message
   in order to influence the LNS to negotiate LCP in a specific manner.
   If these AVPs are supported by the LNS, they should override any
   suggestions for LCP options implied by all other AVPs received.

   These AVPs may coexist with the Proxy AVPs defined in the base L2TP
   specification. If Proxy AVPs are received, the LNS may choose to
   accept these parameters, or renegotiate LCP with the options
   suggested by these AVPs. If the LAC wishes to force negotiation of



Townsley, Palter            expires May 1999                     [Page 2]


INTERNET DRAFT                                             November 1998


   LCP by the LNS, it should simply omit all Proxy AVPs during call
   initialization.

   By default, the AVPs defined in 2.1 and 2.2 are not mandatory (M-bit
   is set to zero). However, if an LAC implementation needs to strongly
   enforce adherence to the options defined within the AVPs, it MAY set
   the M-bit to 1, thus forcing the LNS to discontinue the session if it
   does not support this AVP.

   If the AVPs in sections 2.1 and 2.2 are sent to the LNS, the LAC MUST
   be prepared to accept the AVPs as defined in section 2.3.

2.1 LCP Want Options

    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|0|0|0|0|0| 6+LCP Confreq len |               9               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              3                | LCP confreq...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   This AVP contains a list of options that the LAC would like to see
   negotiated by the LNS. In some cases this maps to a desired value
   (e.g., MRU) and in some cases it maps to a specific option that is
   desired to be enabled (e.g., ACFC). The LNS should use these
   suggestions when building its initial Configure- Request. Presence of
   this AVP is optional.

   The following chart defines some of the more common LCP options that
   may be included in this AVP with guidance of how to handle them at
   the LAC and LNS. This table is provided for some of the more common
   or problematic LCP options. It is not intended to be an exhaustive
   representation of all LCP options available.

LCP Want Option    LAC Action               LNS Action

  MRU               LAC provides a          LNS SHOULD begin negotiation
                    maximum value           with this value. However,
                                            it MAY reduce it if
                                            necessary.

  ACCM              LAC Provides a mask     LNS SHOULD begin negotiation
                                            with this value. LNS may
                                            add bit(s) while negotiating

  PFC               LAC provides PFC        LNS SHOULD being negotiation
                    if it is desired on     with this value.
                    the link type
                    (e.g. AHDLC)

  ACFC              LAC provides ACCOMP     LNS SHOULD begin negotiation
                    if it is desired on     with this value.



Townsley, Palter            expires May 1999                     [Page 3]


INTERNET DRAFT                                             November 1998


                    the link type
                    (e.g. AHDLC)

  FCS-ALT           LAC indicates required  LNS SHOULD begin negotiation
                    values for the link     with this value. Note
                    type                    that this value is of
                                            no consequence to the LNS
                                            as FCS is stripped at the
                                            LAC, however some PPP
                                            media types require this
                                            option.

2.2 LCP Allow Options

    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|0|0|0|0|0| 6+LCP Confack len |               9               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              3                | LCP confack...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This AVP contains a list of options that the LAC will allow to be
   negotiated by the LNS. In some cases this maps to a maximum value
   (e.g., MRU) and in others it maps to an option that is permitted by
   the LAC (e.g., ACFC). If the option is not included here, it can be
   assumed by the LNS that the LAC does not understand how to perform
   that particular option at the link layer. This may or may not affect
   operation of the tunneled session. Information in this AVP should be
   utilized when building PPP Configure-Ack, Configure-Reject and
   Configure-Nak messages. Presence of this AVP is optional.

   The following chart defines some of the more common LCP options that
   may be included in this AVP with guidance of how to handle them at
   the LAC and LNS. This table is provided for illutration purposes for
   some of the more common or problematic LCP options. It is not
   intended to be an exhaustive representation of all LCP options
   available.

LCP Allow Option    LAC Action              LNS Action

  MRU               LAC provides a          LNS may accept reduction
                    maximum value           of this value as requested

  ACCM              LAC Provides a mask     LNS may accept bit(s)
                                            defined here. Note that
                                            if ACCM is missing it is
                                            assumed that it is not
                                            applicable to the link type


  PFC               LAC provides PFC        LNS may accept PFC
                    if it is allowed on
                    the link type



Townsley, Palter            expires May 1999                     [Page 4]


INTERNET DRAFT                                             November 1998


                    (e.g. AHDLC)

  ACFC              LAC provides ACFC       LNS may accept ACFC
                    if it is allowed on
                    the link type
                    (e.g. AHDLC)

  FCS-ALT           LAC indicates valid     Negotiation this option
                    values for the link     is of no consequence to the
                    type                    LNS as the FCS is stripped
                                            at the LAC. However, the
                                            LNS SHOULD only accept
                                            FCS-ALT types listed here
                                            (more than one value may be
                                            present).

2.3 Communicating negotiated link parameters from the LNS to the LAC

   There are no new AVPs defined for communication of negotiated
   parameters from the LNS to the LAC. Instead, two AVPs that are
   defined in the base L2TP specification are simply included in a new
   location.

   When LCP negotiation is complete by the LNS, a Set-Link-Info control
   message may be sent with the the Last Sent LCP Confreq (IETF L2TP
   Attribute 27) and Last Received LCP Confreq (IETF L2TP Attribute 28)
   included in the list of AVPs. These AVPs should contain the last sent
   and last received (with respect to the LNS) LCP packets. For AVP
   format details, refer to the L2TP base specification.

   If LCP negotiation occurs at the LNS and the new AVPs defined in
   section 2.1 and 2.2 of this document are utilized, then a Set-Link-
   Info control message MUST be sent on completion of the LCP
   negotiation, and the Last Sent and Last Received LCP Confreq packets
   MUST be included.

3.0 Contacts

   W. Mark Townsley
   Cisco Systems
   7025 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC 27709
   townsley@cisco.com

   Bill Palter
   Network Alchemy, Inc
   1521.5 Pacific Ave
   Santa Cruz, CA 95060
   palter@zev.net







Townsley, Palter            expires May 1999                     [Page 5]


INTERNET DRAFT                                             November 1998


4.0 References


   [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661,
       07/21/1994

   [2] A. Valencia, W. M. Townsley, W. Palter, et. al. "Layer Two Tunneling Protocol",
       ''work in progress'', October 1998

   [3] W. Simpson, "PPP in HDLC-like framing", RFC 1662,
       07/21/1994














































Townsley, Palter            expires May 1999                     [Page 6]