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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 2661

PPP Working Group                                             A. Valencia
INTERNET DRAFT                                              Cisco Systems
Category: Internet Draft                             K. Hamzeh, A. Rubens
Title: draft-ietf-pppext-l2tp-11.txt                Ascend Communications
Date: May 1998                                    T. Kolar, M. Littlewood
                                                           W. M. Townsley
                                                            Cisco Systems
                                                                J. Taarud
                                                 Copper Mountain Networks
                                                               G. S. Pall
                                                    Microsoft Corporation
                                                                B. Palter
                                                          Network Alchemy
                                                              W. Verthein
                                                         3COM Corporation


                  Layer Two Tunneling Protocol "L2TP"


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 view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).

Abstract

   Virtual dial-up allows many separate and autonomous protocol domains
   to share common access infrastructure including modems, Access
   Servers, and ISDN routers.  RFC 1661 specifies multi-protocol dial-up
   via PPP [1].  This document describes the Layer Two Tunneling
   Protocol (L2TP) which permits the tunneling of the link layer (i.e.,
   HDLC, async HDLC) of PPP.  Using such tunnels, it is possible to
   divorce the location of the initial dial-up server from the location
   at which the dial-up protocol connection is terminated and access to
   the network provided.








Valencia                 expires November 1998                   [Page 1]

INTERNET DRAFT                                                  May 1998


Table of Contents

   1.0   Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   Conventions  . . . . . . . . . . . . . . . . . . . . . . .  4
   1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.0   Problem Space Overview . . . . . . . . . . . . . . . . . .  6
   2.1   Initial Assumptions  . . . . . . . . . . . . . . . . . . .  6
   2.2   Topology . . . . . . . . . . . . . . . . . . . . . . . . .  7
   2.3   Providing Virtual Dial-up Services--a walk-through . . . .  7
   3.0   Service Model Issues . . . . . . . . . . . . . . . . . . .  9
   3.1   Security . . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.2   Address Allocation . . . . . . . . . . . . . . . . . . . . 10
   3.3   Authentication . . . . . . . . . . . . . . . . . . . . . . 10
   3.4   Accounting . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.0   Protocol Overview  . . . . . . . . . . . . . . . . . . . . 11
   4.1   Control Message Overview . . . . . . . . . . . . . . . . . 13
   4.2   Payload Packet Overview  . . . . . . . . . . . . . . . . . 14
   4.3   Flow Control . . . . . . . . . . . . . . . . . . . . . . . 16
   5.0   Message Format and Protocol Extensibility  . . . . . . . . 18
   5.1   AVP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   5.2   Control Message Format . . . . . . . . . . . . . . . . . . 20
   5.3   Payload Message Format . . . . . . . . . . . . . . . . . . 21
   5.4   Control Message Types  . . . . . . . . . . . . . . . . . . 22
   5.5   AVP Summary  . . . . . . . . . . . . . . . . . . . . . . . 23
   5.6   Result and Error Code Summary  . . . . . . . . . . . . . . 26
   5.7   Hiding of AVP values . . . . . . . . . . . . . . . . . . . 27
   6.0   Control Connection Protocol Specification  . . . . . . . . 30
   6.0.1   Control Connection Collision . . . . . . . . . . . . . . 30
   6.0.2   Reliable Delivery of Control Messages  . . . . . . . . . 30
   6.0.3   Control Message Format . . . . . . . . . . . . . . . . . 31
   6.1   Start-Control-Connection-Request . . . . . . . . . . . . . 31
   6.2   Start-Control-Connection-Reply . . . . . . . . . . . . . . 37
   6.3   Start-Control-Connection-Connected . . . . . . . . . . . . 41
   6.4   Stop-Control-Connection-Notification . . . . . . . . . . . 42
   6.5   Hello  . . . . . . . . . . . . . . . . . . . . . . . . . . 43
   6.6   Outgoing-Call-Request  . . . . . . . . . . . . . . . . . . 44
   6.7   Outgoing-Call-Reply  . . . . . . . . . . . . . . . . . . . 49
   6.8   Outgoing-Call-Connected  . . . . . . . . . . . . . . . . . 50
   6.9   Incoming-Call-Request  . . . . . . . . . . . . . . . . . . 53
   6.10   Incoming-Call-Reply . . . . . . . . . . . . . . . . . . . 57
   6.11   Incoming-Call-Connected . . . . . . . . . . . . . . . . . 58
   6.12   Call-Disconnect-Notify  . . . . . . . . . . . . . . . . . 65
   6.13   WAN-Error-Notify  . . . . . . . . . . . . . . . . . . . . 67
   6.14   Set-Link-Info . . . . . . . . . . . . . . . . . . . . . . 68
   7.0   Control Connection State Machines  . . . . . . . . . . . . 69
   7.1   Control Connection Protocol Operation  . . . . . . . . . . 70
   7.2   Control Connection States  . . . . . . . . . . . . . . . . 70
   7.2.1   Control Connection Establishment . . . . . . . . . . . . 70
   7.3   Timing considerations  . . . . . . . . . . . . . . . . . . 72
   7.4   Incoming Calls . . . . . . . . . . . . . . . . . . . . . . 72
   7.4.1   LAC Incoming Call States . . . . . . . . . . . . . . . . 72
   7.4.2   LNS Incoming Call States . . . . . . . . . . . . . . . . 74
   7.5   Outgoing calls . . . . . . . . . . . . . . . . . . . . . . 74
   7.5.1   LAC Outgoing Call States . . . . . . . . . . . . . . . . 75



Valencia                 expires November 1998                   [Page 2]

INTERNET DRAFT                                                  May 1998


   7.5.2   LNS Outgoing Call States . . . . . . . . . . . . . . . . 76
   7.6   Tunnel Disconnection . . . . . . . . . . . . . . . . . . . 77
   8.0   L2TP Over Specific Media . . . . . . . . . . . . . . . . . 77
   8.1   IP/UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 77
   8.2   IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
   9.0   Security Considerations  . . . . . . . . . . . . . . . . . 79
   9.1   Tunnel Endpoint Security . . . . . . . . . . . . . . . . . 79
   9.2   Client Security  . . . . . . . . . . . . . . . . . . . . . 79
   9.3   Proxy Authentication . . . . . . . . . . . . . . . . . . . 80
   10.0   Acknowledgments . . . . . . . . . . . . . . . . . . . . . 80
   11.0   Contacts  . . . . . . . . . . . . . . . . . . . . . . . . 80
   12.0   References  . . . . . . . . . . . . . . . . . . . . . . . 81
   Appendix A:   Acknowledgment Time-Outs . . . . . . . . . . . . . 82
   Appendix B:   Acknowledgment Time-Out and Window Adjustment  . . 86
   Appendix C:   Handling of out-of-order packets . . . . . . . . . 87
   Appendix D:   Transport Layer Adaptive Time-Outs
                 and Window Adjustment  . . . . . . . . . . . . . . 88
   Appendix E:   Examples of L2TP sequence numbering  . . . . . . . 89
   Appendix F:   Flow Control and Sequencing Negotiation  . . . . . 92







1.0 Introduction

   The traditional dial-up network service on the Internet is for
   registered IP addresses only.  A new class of virtual dial-up
   application which allows multiple protocols and unregistered IP
   addresses is also desired on the Internet.  Examples of this class of
   network application are support for privately addressed IP, IPX, and
   AppleTalk dial-up via PPP across existing Internet infrastructure.

   The support of these multi-protocol virtual dial-up applications is
   of significant benefit to end users, enterprises, and Internet
   Service providers as it allows the sharing of very large investments
   in access and core infrastructure and allows local calls to be used.
   It also allows existing investments in non-IP protocol applications
   to be supported in a secure manner while still leveraging the access
   infrastructure of the Internet.

   It is the purpose of this document to identify the issues encountered
   in integrating multi-protocol dial-up services into an existing
   Internet Service Provider's Point of Presence (hereafter referred to
   as ISP and POP, respectively), and to describe the L2TP protocol
   which permits the leveraging of existing access protocols.

   This protocol may solve the "multilink hunt-group splitting" problem.
   Multilink PPP [9], often used to aggregate ISDN B channels, requires
   that all channels composing a multilink bundle be grouped at a single
   NAS.  Because L2TP makes a PPP session terminate at a location other
   than the point at which the session was physically received, it can



Valencia                 expires November 1998                   [Page 3]

INTERNET DRAFT                                                  May 1998


   be used to make all channels terminate at a single NAS, allowing
   multilink operation even when the physical calls are spread across
   distinct physical NAS's.

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

1.2 Terminology

   Analog Channel

      A circuit-switched communication path which is intended to carry
      3.1 kHz audio in each direction.

   Control Connection

      A control connection operates in-band over a tunnel to control the
      establishment, release, and maintenance of sessions and of the
      tunnel itself.

   Digital Channel

      A circuit-switched communication path which is intended to carry
      digital information in each direction.

   Call

      A connection or attempted connection between two terminal
      endpoints. For example, a telephone call through the PSTN between
      two modems. (See also: Session).

   CHAP

      Challenge Authentication Protocol, a PPP cryptographic
      challenge/response authentication protocol in which the cleartext
      password is not passed over the line.

   CLID

      Calling Line ID, an indication to the receiver of a call as to the
      phone number of the caller.

   Control Messages

      Control messages are exchanged between LAC and LNS pairs,
      operating in-band within the tunnel protocol.  Control messages
      govern aspects of the tunnel and sessions within the tunnel.




Valencia                 expires November 1998                   [Page 4]

INTERNET DRAFT                                                  May 1998


   Dial User

      An end-system or router attached to an on-demand PSTN or ISDN
      which is either the initiator or recipient of a call. Also
      referred to as a dial-up or Virtual dial-up client.

   DNIS

      Dialed Number Information String, an indication to the receiver of
      a call as to what phone number the caller used to reach it.

   EAP

      Extensible Authentication Protocol, a framework for a family of
      PPP authentication protocols, including cleartext,
      challenge/response, and arbitrary dialog sequences.

   L2TP Access Concentrator (LAC)

      A device attached to the switched network fabric (e.g. PSTN or
      ISDN) or co-located with a PPP end system capable of handling the
      L2TP protocol.  The LAC needs only implement the media over which
      L2TP is to operate to pass traffic to one or more LNS's.  It may
      tunnel any protocol carried within PPP. The LAC is the initiator
      of incoming calls and the receiver of outgoing calls.

   L2TP Network Server (LNS)

      An LNS operates on any platform capable of PPP termination.  The
      LNS handles the server side of the L2TP protocol.  Since L2TP
      relies only on the single media over which L2TP tunnels arrive,
      the LNS may have only a single LAN or WAN interface, yet still be
      able to terminate calls arriving at any LAC's full range of PPP
      interfaces (async, synchronous ISDN, V.120, etc.).  The LNS is the
      initiator of outgoing calls and the receiver of incoming calls.

   Network Access Server (NAS)

      A device providing temporary, on-demand network access to users.
      This access is point-to-point typically using PSTN or ISDN lines.
      A NAS may also serve as an LAC, LNS or both.

   PAP

      Password Authentication Protocol, a simple PPP authentication
      mechanism in which a cleartext username and password are
      transmitted to prove identity.

   POP

      An Internet Service Provider's Point of Presence.






Valencia                 expires November 1998                   [Page 5]

INTERNET DRAFT                                                  May 1998


   Quality of Service (QOS)

      A given Quality of Service level is sometimes required for a given
      user being tunneled between an LNS-LAC pair.  For this scenario, a
      unique L2TP tunnel is created (generally on top of a new SVC) and
      encapsulated directly on top of the media providing the indicated
      QOS.

   Session

      L2TP is connection-oriented.  The LNS and LAC maintain state for
      each user that is attached to an LAC.  A session is created when
      an end-to-end PPP connection is attempted between a dial user and
      the LNS, or when an outbound call is initiated.  The datagrams
      related to a session are sent over the tunnel between the LAC and
      LNS. (See also:  Call).

   Switched Virtual Circuit (SVC)

      An L2TP-compatible media on top of which L2TP is directly
      encapsulated.  SVC's are dynamically created, permitting tunnel
      media to be created dynamically in response to desired LNS-LAC
      connectivity requirements.

   Tunnel

      A tunnel is defined by an LNS-LAC pair.  The tunnel carries PPP
      datagrams between the LAC and the LNS; many sessions can be
      multiplexed over a single tunnel.  A control connection operating
      in-band over the same tunnel controls the establishment, release,
      and maintenance of sessions and of the tunnel itself. A tunnel is
      sometimes referred to as a control connection.

   Zero-Length Body (ZLB) Message

      A control or payload packet with only an L2TP header, and no
      control message information or PPP payload. ZLB messages are used
      for explicitly acknowledging packets on the control or data
      channel.

2.0 Problem Space Overview

   In this section we describe in high level terms the scope of the
   problem that will be explored in more detail in later sections.

2.1 Initial Assumptions

   We begin by assuming that Internet access is provided by an ISP and
   that the ISP wishes to offer services other than traditional
   registered IP address based services to dial-up users of the network.

   We also assume that the user of such a service wants all of the
   security facilities that are available to him or her in a dedicated
   dial-up configuration.  In particular, the end user requires:



Valencia                 expires November 1998                   [Page 6]

INTERNET DRAFT                                                  May 1998


   +  End System transparency: Neither the remote end system nor his
   home site hosts should require any special software to use this
   service in a secure manner.

   + Authentication as provided via dial-up PPP CHAP, PAP, EAP, or
   through other dialogs, for instance, a textual exchange on V.120
   before starting PPP.  This will include TACACS+ [7] and RADIUS [8]
   solutions as well as support for smart cards and one-time passwords.
   The authentication should be manageable by the user independently of
   the ISP.

   + Addressing should be as manageable as dedicated dial-up solutions.
   The address should be assigned by the home site and not the ISP.

   + Authorization should be managed by the home site as it would in a
   direct dial-up solution.

   + Accounting should be performed both by the ISP (for billing
   purposes) and by the user (for charge-back and auditing).

2.2 Topology

   Shown below is a generic Internet with Public switched Telephone
   Network (PSTN) access (i.e., async PPP via modems) and Integrated
   Services Digital Network (ISDN) access (i.e., synchronous PPP
   access).  Remote users (either async or ISDN PPP) will access the
   Home LAN as if they were dialed into the L2TP Network Server (LNS),
   although their physical dial-up is via the ISP Network Access Server
   (acting as the LAC).




























Valencia                 expires November 1998                   [Page 7]

INTERNET DRAFT                                                  May 1998


           ...----[LAN]----+---[LAN]-----...
                         |
                         |
                        [LNS]
                         |
                 ________|________________________
                 |                                |
         ________|__                        ______|________
         |         |                        |             |
         |  PSTN  [R]                      [R]  ISDN      |
         |  Cloud  |                        |   Cloud    [LAC]--[User]
         |         |             Internet   |             |
         |         |                       [R]            |
         [LAC]____[R]                       |_____________|
          |      |                                |
          |      |                                |
         [User]  |________________________________|




2.3 Providing Virtual dial-up Services--a walk-through

   To motivate the following discussion, this section walks through an
   example of what might happen when a Virtual dial-up client initiates
   access.

   A Network Access Server (NAS)  operating as a peer to an LNS is
   referred to as an L2TP Access Concentrator, or "LAC".

   The remote user initiates a PPP connection to an ISP via either the
   PSTN or ISDN.  The LAC accepts the connection and the PPP link is
   established (L2TP also permits the LAC to check with an LNS after
   call indication prior to accepting the call. This is useful where
   DNIS or CLID information is available in the incoming call
   notification).

   The ISP may now undertake a partial authentication of the end
   system/user.  Only the username field would be interpreted to
   determine whether the user requires a Virtual dial-up service.  It is
   expected, but not required, that usernames will be structured (e.g.
   username@company.com).  Alternatively, the ISP may maintain a
   database mapping users to services.  In the case of Virtual dial-up,
   the mapping will name a specific endpoint, the LNS.

   Alternatively, the ISP may have already determined the target LNS
   from DNIS.  If the LNS is willing to accept tunnel creation without
   any authentication of the caller, the LAC may tunnel the PPP
   connection without ever having communicated with the remote user.

   If a virtual dial-up service is not required, standard access to the
   Internet may be provided.

   If no tunnel connection currently exists to the desired LNS, one is



Valencia                 expires November 1998                   [Page 8]

INTERNET DRAFT                                                  May 1998


   initiated.  L2TP is designed to be largely insulated from the details
   of the media over which the tunnel is established; L2TP requires only
   that the tunnel media provide packet oriented point-to-point
   connectivity.  Obvious examples of such media are UDP, Frame Relay
   PVC's, or X.25 VC's.

   Once the tunnel exists, an unused slot within the tunnel, a "Call
   ID", is allocated, and a connect indication is sent to notify the LNS
   of this new dial-up session.  The LNS either accepts the connection,
   or rejects it.  Rejection MUST include a result condition and MAY
   include an error indication, which may be displayed to the dial-up
   user, after which the call should be disconnected.

   The initial connect notification may include the authentication
   information required to allow the LNS to authenticate the user and
   decide to accept or decline the connection.  In the case of CHAP, the
   set-up packet includes the challenge, username and raw response.  For
   PAP or text dialog, it includes username and clear text password.
   The LNS may choose to use this information to complete its
   authentication, avoiding an additional cycle of authentication.

   If the LAC negotiated PPP LCP before initiating the tunnel, the
   initial connect notification may also include a copy of the LCP
   CONFREQ's sent in each direction which completed LCP negotiation.
   The LNS may use this information to initialize its own PPP state
   (thus avoiding an additional LCP negotiation), or it may choose to
   initiate a new LCP CONFREQ exchange.

   If the LNS accepts the connection, it creates a "virtual interface"
   for PPP in a manner analogous to what it would use for a direct-
   dialed connection.  With this "virtual interface" in place, link
   layer frames may now pass over this tunnel in both directions.
   Frames from the remote user are received at the POP, stripped of CRC,
   link framing, and transparency bytes, encapsulated in L2TP, and
   forwarded over the appropriate tunnel.

   The LNS accepts these frames, strips L2TP, and processes them as
   normal incoming frames for the appropriate interface and protocol.
   The "virtual interface" behaves very much like a hardware interface,
   with the exception that the hardware in this case is physically
   located at the ISP POP.  The other direction behaves analogously,
   with the LNS encapsulating the packet in L2TP, and the LAC stripping
   L2TP before transmitting it out the physical interface to the remote
   user.

   At this point, the connectivity is a point-to-point PPP session whose
   endpoints are the remote user's networking application on one end and
   the termination of this connectivity into the LNS's PPP support on
   the other.  Because the remote user has become simply another dial-up
   client of the LNS, client connectivity can now be managed using
   traditional mechanisms with respect to further authorization,
   protocol access, and packet filtering.

   Accounting can be performed at both the LAC as well as the LNS.  This



Valencia                 expires November 1998                   [Page 9]

INTERNET DRAFT                                                  May 1998


   document illustrates some Accounting techniques which are possible
   using L2TP, but the policies surrounding such Accounting are outside
   the scope of this specification.

   L2TP offers optional facilities which maximize compatibility with
   legacy client requirements; L2TP connect notifications for PPP
   clients can contain sufficient information for an LNS to authenticate
   and initialize its LCP state machine.  With these facilities, the
   remote user need not be queried a second time for PPP authentication,
   nor undergo multiple rounds of LCP negotiation and convergence.
   These techniques are intended to optimize connection setup, and are
   not intended to deprecate any functions required by the PPP
   specification.

3.0 Service Model Issues

   There are several significant differences between the standard
   Internet access service and the Virtual dial-up service with respect
   to authentication, address allocation, authorization and accounting.
   The details of the differences between these services and the
   problems presented by these differences are described below.  The
   mechanisms used for Virtual Dial-up service are intended to coexist
   with more traditional mechanisms; it is intended that an ISP's POP
   can simultaneously service ISP clients as well as Virtual dial-up
   clients.

3.1 Security

   For the Virtual dial-up service, the ISP pursues authentication only
   to the extent required to discover the user's apparent identity (and
   by implication, their desired LNS).  This may involve no more than
   detecting DNIS information when a call arrives, or may involve full
   LCP negotiation and initiation of PPP authentication.  As soon as the
   apparent identity is determined, a call request to the LNS is
   initiated with any authentication information gathered by the ISP. If
   the LNS receives proxy authentication information (see section 6.11),
   it SHOULD assume that the PPP peer is in the authentication phase,
   awaiting an indication of success or failure.  The LNS completes the
   authentication by either accepting the call, or rejecting it.

   The LNS may need to protect against attempts by third parties to
   establish tunnels to the LNS.  Tunnel establishment can include
   authentication to protect against such attacks.

3.2 Address Allocation

   For a traditional Internet service, the user typically accepts that
   the IP address may be allocated dynamically from a pool of ISP
   addresses.  This model often means that the remote user has little or
   no access to their home network's resources, due to firewalls and
   other security policies applied by the home network to accesses from
   external IP addresses.

   For the Virtual dial-up service, the LNS can exist behind the home



Valencia                 expires November 1998                  [Page 10]

INTERNET DRAFT                                                  May 1998


   firewall, allocating addresses which are internal (and, in fact, can
   be RFC 1918 addresses, or non-IP addresses).  Because L2TP tunnels
   exclusively at the frame layer, the actual policies of such address
   management are irrelevant to correct Virtual dial-up service; for all
   purposes of PPP protocol handling, the dial-in user appears to have
   connected at the LNS.

3.3 Authentication

   The authentication of the user occurs in three phases; the first at
   the ISP, and the second and optional third at the LNS.

   The ISP uses DNIS, CLID, or a username to determine that a Virtual
   dial-up service is required and initiates the tunnel connection to
   the appropriate LNS.  Once a tunnel is established, The ISP NAS
   allocates a new Call ID and initiates a session by forwarding the
   gathered authentication information.

   The LNS undertakes the second phase by deciding whether or not to
   accept the call.  The call start indication may include CHAP, PAP,
   EAP, or textual authentication information.  Based on this
   information, the LNS may accept the call request, or may reject it
   (for instance, it was a PAP request and the username/password are
   found to be incorrect).

   Once the call is accepted, the LNS is free to pursue a third phase of
   authentication at the PPP layer.  These activities are outside the
   scope of this specification, but might include an additional cycle of
   LCP authentication, proprietary PPP extensions, or textual challenges
   carried via a TCP/IP TELNET session.

3.4 Accounting

   It is a requirement that both the LAC and the LNS be capable of
   providing accounting data and hence both may count packets, octets
   and connection start and stop times.

   Since Virtual dial-up is an access service, accounting of connection
   attempts (in particular, failed connection attempts) is of
   significant interest.  The LNS can reject new connections based on
   the authentication information gathered by the LAC, with
   corresponding logging.  For cases where the LNS accepts the
   connection and then continues with further authentication, the LNS
   might subsequently disconnect the client.  For such scenarios, the
   disconnection indication back to the LAC may also include a reason.

   Because the LNS can decline a connection based on the authentication
   information collected by the LAC, accounting can easily draw a
   distinction between a series of failed call attempts and a series of
   brief successful connections.  Lacking this facility, the LNS must
   always accept connection requests, and would need to exchange a
   number of PPP packets with the remote system.  Note that the LNS
   could use this information to decide to accept the connection (which
   protects against most invalid connection attempts) while still



Valencia                 expires November 1998                  [Page 11]

INTERNET DRAFT                                                  May 1998


   insisting on running its own CHAP authentication (for instance, to
   protect against CHAP replay attacks).

4.0 Protocol Overview

   There are two parallel components of L2TP operating over a given
   tunnel: control messages between each LAC-LNS pair, and payload
   packets between the same LAC-LNS pair.  The latter are used to
   transport L2TP encapsulated PPP packets for user sessions between the
   pair.

   Two fields important to the operation of L2TP are the Nr (Next
   Received) and Ns (Next Sent) fields which are always present in
   control messages, and are optionally present in payload packets.  A
   single sequence number state is maintained for all control messages,
   and a distinct state is maintained for the payload of each user
   session within the tunnel. The Sequence number starts at 0, Each
   subsequent packet is sent with the next increment of the sequence
   number.  The sequence number is thus a free running counter
   represented modulo 65536. For purposes of detecting duplication, a
   received sequence value is considered less than or equal to the last
   received value if its value lies in the range of the last value and
   its 32767 successor values. For example, if the last received
   sequence number was 15, then packets with sequence numbers 0 through
   15, as well as 32753 through 65536, would be considered less than or
   equal to, and would be silently discarded.  Otherwise it would be
   accepted.

   In this document, the sequence number state for a control connection
   and each user session is represented for clarity in the following
   discussions by distinct pairs of state variables, Sr and Ss.  Sr
   represents the value of the next in-sequence message expected to be
   received for a given session by a peer. Ss represents the sequence
   number to be placed in the Ns field of the next message sent for a
   given session by the sending peer.  Each state is initialized such
   that the first message sent and the first message expected to be
   received for each session has an Ns value of 0.  This corresponds to
   initializing Ss and Sr in both peers to 0 for each new session.

   As messages are sent for a given session, Nr is set in these messages
   to reflect one more than the Ns value of the highest (modulo 2**16)
   in-order message received for that session; if sent before any packet
   is received Nr will be 0, indicating that the peer expects the next
   new Ns value received to be 0.  When a non-ZLB message is received
   with an Ns value that matches the session's current Sr value, Sr is
   incremented by 1 (modulo 2**16). It is important to note that, for
   both control and payload sessions, Sr is not modified if a message is
   received with a value of Ns greater than the current Sr value
   (exceptions to this rule being the permitted handling of out-of-order
   payload packets by the "simple receiver" discussed in Appendix C and
   handling of payload packets with the R bit set).  For the control
   session, retransmission of outgoing messages should eventually
   provide the receiving peer with the expected message.  For payload
   sessions, however, lost messages are never retransmitted so a



Valencia                 expires November 1998                  [Page 12]

INTERNET DRAFT                                                  May 1998


   mechanism involving the use of the "Reset Sr" (R bit) indicator in an
   outgoing message is used to update the peer's value of Sr to the
   value of Ns contained in the message.  See Sec.  4.2 for details of
   this mechanism.

   Every time a peer sends a non-ZLB message it increments its
   corresponding Ss value for that session by 1 (modulo 2**16).  This
   increment takes place after the current Ss value is copied to Ns in
   the message to be sent.  Outgoing messages always include the current
   value of Sr for the corresponding session in their Nr field.

   A message (control or payload) with a zero-length body indicates that
   the packet is only used to communicate Nr and Ns fields.  The Nr and
   Ns fields are filled in as above, but the sequence number state, Ss,
   is not incremented.  Thus a ZLB message sent after a non-ZLB message
   will contain a new Ns value while a non-ZLB message sent after a ZLB
   message will contain the same value of Ns as the preceding zero-
   length message. Unless the Rbit (Reset Sr) is set, a peer receiving a
   zero-length message does not update its Sr variable.

   Upon receipt of an in-order non-ZLB message, the receiving peer must
   acknowledge the message by sending back the updated value of Sr in
   the Nr field of the next outgoing message.  This updated Sr value can
   be piggybacked in the Nr field of any non-ZLB outgoing messages that
   the peer may happen to send back.

   If the peer does not have a message to transmit for a short period of
   time after receiving a non-ZLB message then it should send a ZLB
   message containing the latest values of Sr and Ss, as described
   above.  The suggested value for this time interval is 1/4 the
   receiving peer's value of Round-Trip-Time (RTT - see Appendix A), if
   it computes RTT, or a maximum of 1/2 of its fixed timeout interval
   otherwise.  This timeout should provide a reasonable opportunity for
   the receiving peer to obtain a payload message destined for its peer,
   upon which the ACK of the received message can be piggybacked.

   This timeout value should be treated as a suggested maximum; an
   implementation could make this timeout quite small without adversely
   affecting the protocol.  To provide for better throughput, the
   receiving peer should skip this timeout entirely and send a ZLB
   message immediately in the case where its receive window fills and it
   has no queued data to send for this connection or it can't send
   queued data because the transmit window is closed.

   A suggested implementation of this timer is as follows:  Upon
   receiving a non-ZLB message, the receiver starts a timer that will
   expire in the recommended time interval.  A variable, Lr (Last Nr
   value sent), is used by the transmitter to store the last value sent
   in the Nr field of a transmitted payload message for this connection.
   Upon expiration of this timer, Sr is compared to Lr and, if they are
   not equal, a ZLB ACK is issued. If they are equal, then no ACK's are
   outstanding and no action needs to be taken.

   This timer should not be reinitialized if a new message is received



Valencia                 expires November 1998                  [Page 13]

INTERNET DRAFT                                                  May 1998


   while it is active since such messages will be acknowledged when the
   timer expires.  This ensures that periodic ACK's are issued with a
   maximum period equal to the recommended timeout interval. This
   interval should be short enough to not cause false acknowledgment
   timeouts at the transmitter when payload messages are being sent in
   one direction only.  Since such ACK's are being sent on what would
   otherwise be an idle data path, their affect on performance should be
   small, if not negligible.

   See Appendix E for some examples of how sequence numbers progress.

   4.1 Control Message Overview

      Before PPP tunneling can occur between an LAC and LNS, control
      messages must be exchanged between them.  Control messages are
      exchanged over the same tunnel which will be used to forward
      payload data once L2TP call control and management information
      have been passed.  The control messages are responsible for
      establishment, management, and release of sessions carried through
      the tunnel, as well as status on the tunnel itself.  It is the
      means by which an LNS is notified of an incoming call at an
      associated LAC, as well as the means by which an LAC is instructed
      to place an outgoing call.

      A tunnel may be established by either an LAC (for incoming calls)
      or an LNS (for outgoing calls).  Following the establishment of
      the tunnel, the LNS and LAC configure the tunnel by exchanging
      Start-Control-Connection-Request and -Reply messages.  These
      messages are also used to exchange information about basic
      operating capabilities of the LAC and LNS.  Once the control
      message exchange is complete, the LAC may initiate sessions by
      indicating inbound requests, or the LNS by requesting outbound
      calls. If both ends of the tunnel have the ability to act as an
      LAC and LNS concurrently, then nothing prohibits establishing
      incoming or outgoing calls from both sides of the same tunnel.
      Control messages may indicate changes in operating characteristics
      of an individual user session with a Set-Link-Info message.
      Individual sessions may be released by either the LAC or LNS, also
      through control messages.

      Independent Call ID values are established for each end of a user
      session.  The sender of a packet associated with a particular
      session places the Call ID established by its peer in the Call ID
      header field of all outgoing packets.  For the cases where a Call
      ID has not yet been assigned from the peer (i.e., during call
      establishment of a new session), the Call ID field is sent as 0,
      and further fields within the message are used to identify the
      session.  The Call ID value of 0 is thus special and MUST NOT be
      used as an Assigned Call ID.

      A mechanism for detection of tunnel connectivity problems is
      provided by the reliable transport layer of L2TP.  The transport
      layer of L2TP performs control message retransmission.  If the
      number of retransmission attempts for a given control message



Valencia                 expires November 1998                  [Page 14]

INTERNET DRAFT                                                  May 1998


      exceeds a configured maximum value, the tunnel is reset.  This
      retransmission mechanism exists in both the LNS and LAC ends of
      the tunnel.

      A keepalive mechanism is employed by the L2TP higher layer in
      order to differentiate tunnel outages from extended periods of no
      control or data activity on a tunnel. This is accomplished by the
      higher layer injecting Hello control messages into the control
      stream after a specified period of time elapses since the last
      data or control message was received on the tunnel.  As for any
      other control message, if the transport does not receive an ACK
      for the Hello message after the normal number of retransmissions
      the tunnel is declared down and is reset.  The transport layer
      reset mechanism along with the injection of Hello messages ensures
      that a connectivity failure between the LNS and the LAC will be
      detected at both ends of a tunnel in a timely manner.

      It is intended that control messages will also carry management
      related information in the future, such as a message allowing the
      LNS to request the status of a given LAC; these message types are
      not defined in this document.

   4.2 Payload Packet Overview

      Once a tunnel is established and control messages have completed
      tunnel setup, the tunnel can be used to carry user session PPP
      packets for sessions involving a given LNS-LAC pair.  The "Call
      ID" field in the L2TP header indicates to which session a
      particular PPP packet belongs.  In this manner, PPP packets are
      multiplexed and demultiplexed over a single tunnel between a given
      LNS-LAC pair.  The "Call ID" field value is established during the
      exchange of call setup control messages.

      It is legal for multiple tunnels to exist between a given LNS-LAC
      pair.  This is useful where each tunnel is used for a single user
      session, and the tunnel media (an SVC, for instance) has specific
      QOS attributes dedicated to a given user.  L2TP provides a tunnel
      identifier so that individual tunnels can be identified, even when
      arriving from a single source LAC or LNS.

      The L2TP header also contains optional acknowledgment and
      sequencing information that can be used to provide flow-control
      across the underlying medium (which may be an internetwork) as
      well as congestion control in the network itself (see section
      4.3). In this document, these mechanisms will be referred to
      collectively as "flow control".  Control messages are used to
      determine rate and buffering parameters that are used to regulate
      the flow of PPP packets for a particular session over the tunnel.

      The receiving peer indicates whether flow control is to be
      performed for payload packets sent to it.  If a peer issues a
      Receive Window Size AVP with a non-zero value during session
      establishment, then the sending peer MUST abide by the indicated
      window size value as long as sequence numbers are provided.  If a



Valencia                 expires November 1998                  [Page 15]

INTERNET DRAFT                                                  May 1998


      receiving peer does not wish to flow control the payload packets
      sent to it, it should not issue the Receive Window Size AVP with a
      non-zero value.  Issuing a Receive Window Size AVP with a zero
      value has special significance.  It indicates that the receiver
      does not want to perform flow-control but it does want the sending
      peer to provide Ns values in payload packets so that it can detect
      lost packets or packets received out of order.  A receiver SHOULD
      NOT send any ZLB ACK's to the sender who advertizes a Receive
      Window of zero, nor should the sender expect to receive such
      explicit acknowledgements.

      In the case where neither peer issues a Receive Window Size AVP
      during session establishment, the optional Nr and Ns fields are
      absent in all payload packets for that session.  In the case where
      either peer wishes to perform flow-control or to detect out-of-
      order receive messages (as indicated by the sending of the Receive
      Window Size AVP with non-zero or zero value, respectively) the Nr
      and Ns fields MUST be present in payload packets sent by both
      peers.  A proper Ns value starts at 0 and increments by one for
      each transmitted payload message and a proper Nr value is the
      current value of the receive sequence number state variable, Sr.
      See Appendix F for a table detailing when to send sequence numbers
      with regard to the Receive Window AVP.

      Unless the LAC sends the Sequencing Required AVP (see section 6.7
      and 6.8) in the ICCN or OCCN message, the LNS has the authority to
      dynamically enable or disable sending of Ns/Nr and hence
      controlling the capability of loss detection, reordering and flow
      control over the link.  To disable sequence numbers, the LNS sends
      a packet with the F bit set to 0 and Ns/Nr fields not present. The
      LAC, upon receiving such a data packet, MUST process the packet
      and discontinue inclusion of Ns/Nr fields in any subsequent data
      packets.  Any packets which have been received by L2TP but are
      being held in queue for reordering SHOULD be flushed without
      waiting for an ACK from the peer (as if an R bit packet with Ns
      equal to the current Sr value was received). Ss and Sr should be
      updated and saved accordingly.

      All data packets will continue to be exchanged without sequence
      numbers until the end of the session or until the LNS resumes
      sequence numbers by sending a packet with the F bit set and Ns/Nr
      present. The LAC, upon receiving a packet with the F bit set, MUST
      resume sending sequence numbers in further packets. In order to
      properly resume, the LNS and LAC MUST preserve the state of Ss and
      Sr between periods of disabled sequencing.

      While the LNS may initiate disabling of sequencing at any time
      during the session (including the first data packet sent), it is
      recommended that for links where reordering or packet loss may
      occur, sequence numbers always be enabled during the initial
      negotiation stages of PPP and disabled only when and if the risk
      is considered acceptable. For instance, if the PPP session being
      tunneled is not utilizing any stateful compression or encryption
      protocols and is only carrying IP (as determined by the NCP's that



Valencia                 expires November 1998                  [Page 16]

INTERNET DRAFT                                                  May 1998


      are established), then the LNS might decide to disable sequencing,
      thus allowing higher level protocols to perform necessary flow
      control end to end and reducing the per packet L2TP processing
      burden on the LNS substantially. Further discussion of some of the
      tradeoffs associated with disabling sequencing over media which
      may reorder or silently drop packets is given in section 8.2.

   4.3 Flow Control

      If a receiving peer offers a non-zero receive window size to a
      sending peer then the sending peer MUST abide by this window size
      value as long as sequence numbers are being exchanged (See
      Appendix F for details of when flow control is enabled in relation
      to sending of the receive window AVP).  The sending peer MUST stop
      sending payload packets when the window is full; i.e., x
      consecutive messages have been sent but have not been
      acknowledged, where x is the value of the Receive Window Size AVP.
      Implementors should take care to avoid the situation where loss of
      an ACK by a sending peer with a full transmit window causes a
      session to hang forever, due to the fact there are no
      retransmissions of payload packets.  Steps must be taken to reopen
      the transmit window (at least to a value of 1) upon expiration of
      an ACK wait timeout.  See Appendix B for more details.

      When sending to a peer that has issued a non-zero receive window
      size, the sending peer is responsible for resetting the receiver's
      Sr value when a sent payload message is lost during transmission.
      When a sent message is lost, the receiving peer's Sr value (and
      hence the Nr value it sends) will "stick" at the Ns value of the
      first missing payload message.  The "Reset Sr" (R bit) in the
      payload message header (see Section 5.3) provides a mechanism for
      the sending peer to indicate to the receiver that it (the sending
      peer) recognizes that at least one payload message has been lost
      and that the receiving peer should now reset its Sr value beyond
      the lost message(s). If the sending peer is performing adaptive
      window adjustment (see Appendix B.1) then it is this recognition
      of a lost message that is used to indicate that a window
      adjustment at the sending peer should be performed.

      The sender may use a timer mechanism similar to that used to
      retransmit lost control messages to determine when transmitted
      payload packets have been lost.  When the timer expires, a payload
      message (zero or non-zero length) with the R bit set can be issued
      to indicate to the receiver that it needs to reset its Sr value.
      Upon receipt of a payload message with the R bit set, the receiver
      resets Sr to the value of Ns contained in the message, or, if
      highly congested, to a value between its current value and the
      value of Ns contained in the message.

      Upon receipt of a payload message with R bit set, the receiver
      takes the following actions: First, the receiver checks for the
      presence of the R bit in a received payload message before
      comparing the message's Ns value to its Sr value.  If the R bit is
      set, the receiver will typically set its Sr value equal to that of



Valencia                 expires November 1998                  [Page 17]

INTERNET DRAFT                                                  May 1998


      Ns contained in the message and fall through to normal receive
      message processing in which Sr will be incremented (modulo 2**16)
      if the message is non-ZLB and will remain the same if it is ZLB.
      However, if the receiver is known to be heavily congested, it MAY
      choose to not update or set its new Sr value between (modulo
      2**16) the current Sr value and that of Ns contained in the
      message. This effectively spoofs the transmitter into believing
      that the R bit packets that have been sent are not being received,
      ultimately causing the transmitter to backoff more quickly.

      In order to prevent an R bit message received out of order from
      setting Sr to an old value, the receiving peer should compare the
      value of Ns in an R bit message to its current value of Sr. The
      receiving peer should reset its Sr value only if Ns is greater
      than (modulo 2**16) its current value of Sr.

      The sender of the R bit can decide whether it wishes to advance
      the receiver's Sr value to the value just past the highest (modulo
      2**16) Nr value received (the Ns value of the message just past
      that of the first lost message) or to its current value of Ss.
      Resetting it to that just past the first lost message enables the
      sender to determine if other messages in the same transmit window
      were also lost.  Setting it to the current Ss value of the sender
      treats losses of multiple messages in the same window the same as
      the loss of a single message.  An implementation may use either,
      or a combination of both methods. If the transmitter detects that
      the receiver is heavily congested, piggybacking the R bit on data
      packets should be refrained in favor of a ZLB with the R bit set
      for resetting the receiver's Sr.

      It is permissible for a sending peer to set the R bit (and hence
      reset the transmit window) in all transmitted payload packets as
      an indication that flow control has been disabled at the
      transmitter.

      Receipt of an R bit is NOT an explicit indication to immediately
      flush all packets which might be in queue to PPP for processing.
      There are a number of tradeoffs as to precisely when a receiver
      should decide to pass packets from L2TP to PPP, many dependent on
      what protocols are being carried by PPP.  In general, packets
      should be declared lost and passed to PPP in a timely enough
      manner so as to not cause retransmissions by reliable higher layer
      protocols due to packets that are held in queue by l2tp.

      L2TP does not specify the particular timeout algorithms to use for
      flow control.  Suggested algorithms for the determination of
      adaptive timeouts to recover from dropped data or acknowledgments
      on the tunnel are included in Appendix A of this document.
      Additional examples for sequencing and flow control are included
      in Appendix E.







Valencia                 expires November 1998                  [Page 18]

INTERNET DRAFT                                                  May 1998


5.0 Message Format and Protocol Extensibility

   L2TP defines a set of control messages sent in packets over the
   tunnel between an LNS and a given LAC.  The exact technique for
   initiating a tunnel between an LNS-LAC pair is specific to the tunnel
   media, and specific media are described in section 8.0.

   Once media-level connectivity is reached, L2TP message formats define
   the protocol for an LAC and LNS to manage the tunnel and its
   associated sessions.

   In each case where a field is optional, if the field is not present,
   its space does not exist in the packet.  Existing fields are placed
   back-to-back to form the packet.

   5.1 AVP

      To maximize extensibility while still permitting interoperability,
      a uniform method for encoding message types and bodies is used
      throughout L2TP.  This encoding will be termed an AVP (Attribute-
      Value Pair) in the remainder of this document.  Each AVP is
      encoded as:

       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|  Overall Length   |           Vendor ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Attribute            | Value...                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | [until Overall Length is reached]...                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The first six bits are a bit mask, describing the general
      attributes of the AVP.

      The 0 bits indicate reserved bit fields and MUST be set to 0. An
      AVP received with a reserved bit set to 1 MUST be treated as an
      unrecognized AVP, unless the reserved bit is defined for an
      extension that is known to the implementation.

      The M bit, known as the "mandatory" bit, controls the behavior
      required of an implementation which receives an AVP which it does
      not recognize. If M is set on an unrecognized AVP associated with
      call (session) management, any session associated with this AVP
      MUST be terminated. If M is set on an unrecognized AVP associated
      with the overall tunnel, the entire tunnel (and all sessions
      within) MUST be terminated. If M is not set, an unrecognized AVP
      should be ignored.

      The H bit, known as the "hidden" bit, controls the hiding of the
      data in the value field of an AVP.  This capability can be used to
      avoid the passing of sensitive data, such as user passwords, as
      cleartext in an AVP.  Section 5.7 describes the procedure for



Valencia                 expires November 1998                  [Page 19]

INTERNET DRAFT                                                  May 1998


      performing AVP value hiding.

      Overall Length encodes the number of octets (including the Overall
      Length field itself) contained in this AVP.  It is 10 bits,
      permitting a maximum of 1024 octets of data in a single AVP.

      Vendor ID is the IANA assigned "SMI Network Management Private
      Enterprise Codes" [12] value, encoded in network byte order.  The
      value 0, reserved in this table, corresponds to IETF adopted
      Attribute values, defined within this document.  Any vendor
      wishing to implement L2TP extensions can use their own Vendor ID
      along with private Attribute values, guaranteeing that they will
      not collide with any other vendor's extensions, nor with future
      IETF extensions.

      Attribute is the actual attribute, a 16-bit value with a unique
      interpretation across all AVP's defined under a given Vendor ID.

      Value follows immediately after the Attribute field, and runs for
      the remaining octets indicated in the Overall Length (i.e.,
      Overall Length minus six octets of header).

      AVP's should be kept compact; the combined AVP's within a control
      message MUST NOT ever cause a control message's total length to
      exceed 1500 octets in length.

   5.2 Control Message Format

      Each L2TP control message begins with a 12 octet header portion
      followed by an 8 octet Message Type AVP and zero or more AVP's.
      This header is formatted:

       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|0|0|F|0|0|0|0|0|0|0|0| Ver |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tunnel ID           |            Call ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Ns              |               Nr              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Message Type AVP...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ... (8 octets)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The 0 bits indicate reserved bit fields and MUST be set to 0.  A
      control message received with a reserved bit set to 1 in the
      header MUST be treated as an unrecognized control message, unless
      the bit is defined for an extension that is known to the
      implementation.

      The L and F bits must be 1, indicating that the length, Ns and Nr
      fields are present.



Valencia                 expires November 1998                  [Page 20]

INTERNET DRAFT                                                  May 1998


      The T bit MUST be 1, indicating a control message.

      Ver MUST be the value 2, indicating a version 1 L2TP message (the
      value 0 is reserved to permit detection of L2F [2] packets should
      they arrive intermixed).

      Length is the overall length of the message, including header,
      message type AVP, plus any additional AVP's associated with a
      given control message type.

      Tunnel ID and Call ID identify the tunnel and user session within
      the tunnel to which a control message applies.  If a control
      message does not apply to a single user session within the tunnel
      (for instance, a Stop-Control-Connection-Notification message),
      Call ID MUST be set to 0.  If an Assigned Tunnel ID has not yet
      been received from the peer, Tunnel ID MUST be set to 0.  Once an
      Assigned Tunnel ID is received, all further packets MUST be sent
      with Tunnel ID set to the indicated value. Note that the Assigned
      Tunnel ID and Call ID MAY be selected in an unpredictable manner
      rather than sequentially or otherwise.  Doing so will help to
      deter hijacking of a session by a malicious user who does not have
      access to packet traces between the LAC and LNS.

      Ns is copied from the send sequence number state variable, Ss, at
      the time the message is transmitted.  Ss is incremented after
      copying if the control message is not a ZLB ACK.  Nr is copied
      from the receive sequence number state variable, Sr, and indicates
      the sequence number, Ns, + 1 of the highest (modulo 2**16) in-
      sequence message received.  See section 4.0.

   5.3 Payload Message Format

      PPP payload packets tunneled within L2TP have a smaller
      encapsulation than the L2TP control message header, reducing
      overhead of L2TP during the life of a tunneled PPP session.  The
      LNS is expected to be able to process user data packets of at
      least the default MRU for PPP, not including L2TP and media
      encapsulation.  The smallest L2TP encapsulation is 6 octets; the
      largest is 14 octets (plus padding octets, if present).  See
      section 8.1 for further MTU considerations.

       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|R|0|F|0|S|P|0|0|0|0|0| Ver |          Length (opt)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tunnel ID           |             Call ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Ns (opt)          |               Nr (opt)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Offset Size (opt)        |    Offset pad... (opt)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The 0 bits indicate reserved bit fields and MUST be set to 0.  A



Valencia                 expires November 1998                  [Page 21]

INTERNET DRAFT                                                  May 1998


      packet received with a reserved bit set to 1 in the payload
      message header MUST be silently discarded, unless the bit is
      defined for an extension that is known to the implementation.

      The T bit MUST be 0, indicating payload.

      Ver MUST be 2, indicating version 1 of the L2TP protocol.

      If the L bit is set, the Length field is present, indicating the
      total length of the packet sent.

      The R bit, "Reset Sr", is used for flow control and indicates that
      the receiver SHOULD reset its receive state variable, Sr, for this
      session to the value contained in the Ns field of this message
      header.  Sr is reset to the value of Ns only if Ns is greater than
      (modulo 2**16) the receiver's current value of Sr.  Normal receive
      processing of the message is performed after the value of Sr is
      reset.  Note that if the F bit is not set, then this bit MUST be
      0.  See section 4.2 for a detailed discussion of the use of this
      bit for flow control on the data channel. See Appendix E for
      examples of proper R bit usage.

      If the F bit is set, both the Nr and Ns fields MUST be present.
      Ns indicates the sequence number of the packet being sent.  The Ns
      value of a message being transmitted is copied from the current
      value of the send sequence number state variable, Ss.  Ss is
      incremented by one (modulo 2**16) after copying to the Ns field
      only if the message being sent is not a ZLB ACK.  Nr indicates the
      sequence number of the next in-order message sequence number to be
      received (if the last in-order non-ZLB data packet had Ns set to
      1, the Nr sent back would be 2).  The value of Nr is copied from
      the current receive state variable, Sr.  Together, Nr and Ns can
      be used to handle out-of-order packets and, together with the R
      bit, to provide flow control for the connection.

      An L2TP peer setting the F bit, and placing Nr and Ns fields in
      its messages, MUST have previously received or sent a Receive
      Window Size AVP during establishment of the session.  The Nr and
      Ns fields are present and updated as described in section 4.0 if
      either side has specified an intention to do payload flow control.

      The Offset Size field is present if the S bit is set in the header
      flags.  This field specifies the number of octets past the L2TP
      header at which the payload data is expected to start.  It is
      recommended that data thus skipped be initialized to 0's.  If
      Offset Size is 0, or the S bit is not set, the first octet
      following the last octet of L2TP header is the first octet of
      payload data.

      If the P bit is set, this packet should receive preferential
      treatment at the LAC in its queuing for transmission to the
      client.  LCP echo requests used as a keepalive for the link, for
      instance, should generally be sent from the LNS with this bit set.
      Without it, a temporary interval of congestion of the transmission



Valencia                 expires November 1998                  [Page 22]

INTERNET DRAFT                                                  May 1998


      queues could result in the interference with keepalive messages
      and unnecessary loss of the link.

   5.4 Control Message Types

      Control message and AVP types defined in this specification exist
      under Vendor ID 0, indicating IETF defined behavior.  The actual
      message and AVP semantics are defined in the next section.  This
      section includes tables that summarize all currently defined
      message and AVP types.  Note that while an AVP may legally occur
      under more than one type of control message, an AVP's specific
      interpretation is unique to the specific control message.

      Each message type entry in the table below indicates: the integer
      value assigned to the message type; the message type abbreviation
      used in the AVP Summary Table of Sec. 5.5; and the full name of
      the message type.

      The integer value assigned to each message type is placed in the
      Value field of the Message Type AVP.  This AVP MUST be the first
      AVP in a message.  The currently defined control message types,
      grouped by function, are:

      Control Connection Management

         1  (SCCRQ)    Start-Control-Connection-Request
         2  (SCCRP)    Start-Control-Connection-Reply
         3  (SCCCN)    Start-Control-Connection-Connected
         4  (StopCCN)  Stop-Control-Connection-Notification
         5  (reserved)
         6             Hello

      Call Management

         7  (OCRQ)     Outgoing-Call-Request
         8  (OCRP)     Outgoing-Call-Reply
         9  (OCCN)     Outgoing-Call-Connected
         10 (ICRQ)     Incoming-Call-Request
         11 (ICRP)     Incoming-Call-Reply
         12 (ICCN)     Incoming-Call-Connected
         13 (reserved)
         14 (CDN)      Call-Disconnect-Notify

      Error Reporting

         15 (WEN)      WAN-Error-Notify

      PPP Session Control

         16 (SLI)      Set-Link-Info







Valencia                 expires November 1998                  [Page 23]

INTERNET DRAFT                                                  May 1998


   5.5 AVP Summary

      The following table lists all standard L2TP attributes currently
      defined.  The "Attr" column indicates the integer value assigned
      to this attribute.  The "M" column indicates the setting of the
      "Mandatory" bit of the AVP header for each attribute.  The "Len"
      field indicates the size of the AVP including the AVP header.  A
      "+" in this column indicates that the length varies depending upon
      the length of the actual contents of the value field.

      The "(usage)" list for each entry indicates the message types that
      utilize each AVP (See command table of Sec. 5.4).  An abbreviation
      shown in mixed or upper case letters indicates that the
      corresponding AVP MUST be present in this message type; All lower
      case indicates that the AVP may optionally appear in this message
      type. Some AVPs MUST be present only when a corresponding optional
      AVP is present, these AVPs are shown in lower case as well.

      A brief summary of the type and contents of the value field for
      each attribute is also given for each entry.  Refer to the
      individual message type descriptions that appear in Section 6 for
      further details about the use of a particular AVP in a particular
      message type. This table is provided only as a convenient overview
      of AVPs, individual message AVP descriptions always enjoy priority
      to summary descriptions provided in this table.

      Attr M Len            Attribute Name (usage)

        0  1 8   Message Type (ALL MESSAGES)
         16-bit integer value indicating the message type, as defined in
         table above.  MUST be the first AVP in each message

        1  1 10+ Result Code (CDN, StopCCN)
         16-bit Integer value indicating result of corresponding request
         or reason for issuing a request, 16-bit integer General Error
         code and an optional ASCII string error message.  See Result
         and General Error code tables below.

        2  1 8   Protocol Version (SCCRP, SCCRQ)
         8-bit L2TP Protocol and Revision numbers

        3  1 10  Framing Capabilities (SCCRP, SCCRQ)
         32-bit bitmask indicating supported framing types (e.g.,
         synchronous and asynchronous)

        4  1 10  Bearer Capabilities (sccrp, sccrq)
         32-bit bitmask indicating supported bearer types (e.g., analog
         and digital)

        5  0 14  Tie Breaker (sccrq)
         8 octet value used to break control connection establishment
         collisions

        6  0 8   Firmware Revision (sccrp, sccrq)



Valencia                 expires November 1998                  [Page 24]

INTERNET DRAFT                                                  May 1998


         16-bit integer representing vendor's firmware revision

        7  1 6+  Host Name (SCCRP, SCCRQ)
         ASCII string name (e.g., DNS name) of issuer

        8  0 6+  Vendor Name (sccrp, sccrq)
         ASCII string describing issuing device

        9  1 8   Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN)
         16-bit integer tunnel ID assigned by sender

       10  1 8   Receive Window Size (iccn, icrp, occn, ocrq, sccrp,
               sccrq)
         16-bit integer receive window size offered by sender for a
         given call or control session

       11  1 6+  Challenge (sccrp, sccrq)
         1 or more octet value issued by sender wishing to authenticate
         control session peer

       12  1 9+  Q.931 Cause Code (cdn)
         16-bit cause code, 1 octet cause message, and optional ASCII
         advisory message

       13  1 22  Challenge Response (scccn, sccrp)
         16 octet CHAP type response to peer's Challenge

       14  1 8   Assigned Call ID (CDN, ICRP, ICRQ, OCRP, OCRQ)
         16-bit integer ID assigned to a call by sender

       15  1 10  Call Serial Number (ICRQ, OCRQ)
         1 or more octet identifier assigned to a call

       16  1 10  Minimum BPS (OCRQ)
         32-bit integer indicating lowest acceptable line speed for call

       17  1 10  Maximum BPS (OCRQ)
         32-bit integer indicating highest acceptable line speed for
         call

       18  1 10  Bearer Type (icrq, OCRQ)
         Indicates bearer type (i.e., analog or digital) for call

       19  1 10  Framing Type (ICCN, OCCN, OCRQ)
         Indicates framing type (i.e., synchronous or asynchronous) for
         call

       20  1 8   Packet Processing Delay (iccn, icrp, occn, ocrq)
         16-bit integer estimate of processing time of full window of
         received packets by sender

       21  1 6+  Dialed Number (icrq, OCRQ)
         ASCII string phone number called or to be called




Valencia                 expires November 1998                  [Page 25]

INTERNET DRAFT                                                  May 1998


       22  1 6+  Dialing Number (icrq)
         ASCII string phone number of caller

       23  1 6+  Sub-Address (icrq, ocrq)
         ASCII string containing additional dialing information

       24  1 10  (Tx) Connect Speed (ICCN, OCCN)
         32-bit integer representing actual (or transmit) line speed of
         connection

       25  0 10  Physical Channel ID (icrq, ocrp)
         32-bit vendor specific physical device identifier used for call

       26  0 6+  Initial Received LCP CONFREQ (iccn)
         Octet string containing initial CONFREQ received from client

       27  0 6+  Last Sent LCP CONFREQ (iccn)
         Octet string containing final CONFREQ sent to client

       28  0 6+  Last Received LCP CONFREQ (iccn)
         Octet string containing final CONFREQ received from client

       29  0 8   Proxy Authen Type (iccn)
         16-bit integer code indicating client authentication type
         negotiated (e.g., PAP, CHAP)

       30  0 6+  Proxy Authen Name (iccn)
         ASCII string containing name returned by client in
         authentication response

       31  0 6+  Proxy Authen Challenge (iccn)
         Octet string Challenge presented by LAC to client

       32  0 8   Proxy Authen ID (iccn)
         16-bit integer of which low order octet is ID presented to
         client with Challenge.  High order octet must be 0.

       33  1 6+  Proxy Authen Response (iccn)
         Octet string CHAP response or ASCII string password depending
         on authentication type used

       34  1 32  Call Errors (WEN)
         A reserved 16-bit word set to 0 followed by 6 32-bit integer
         connection error counters

       35  1 16  ACCM (SLI)
         A reserved 16-bit word set to 0 followed by 2 32-bit bitmasks
         containing Send and Receive ACCM values respectively

       36  1 6+  Random Vector (all messages)
         Variable length octet string containing a random sequence of
         values used to accomplish the optional "hiding" of other AVP
         values (See "H" bit description in Sec. 5.7).




Valencia                 expires November 1998                  [Page 26]

INTERNET DRAFT                                                  May 1998


       37  0 6+ Private Group ID (iccn)
         Variable length octet value used by the LAC or LNS to indicate
         that this call is to be associated with a particular customer
         group.

       38  0 10  Rx Connect Speed (iccn, occn)
         32-bit integer representing actual receive line speed of
         connection. Suggests possibility of asymmetric connection.

       39  1 6  Sequencing Required (iccn, occn)
         If present, indicates to the LNS that it MUST NOT dynamically
         disable sequencing.

   5.6 Result and Error Code Summary

   The StopCCN and CDN message types contain a Result Code AVP which
   indicates the result of the previously requested operation.  The
   Result Code can indicate that additional information pertaining to an
   error situation can be found in the Error Code field of the Result
   Code AVP.  The meaning of the result code is tabulated under the
   specific type of message containing the result.  Each 16-bit Result
   Code is immediately followed (in the same AVP) by a 16-bit General
   Error code value.

   General error codes pertain to types of errors which are not specific
   to any particular L2TP request, but rather to protocol or message
   format errors.  If an L2TP reply indicates in its Result Code that a
   general error occurred, the General Error value should be examined to
   determine what the error was.  The currently defined General Error
   codes and their meanings are:

      0 - No general error
      1 - No control connection exists yet for this LAC-LNS pair
      2 - Length is wrong
      3 - One of the field values was out of range or reserved field was
         non-zero
      4 - Insufficient resources to handle this operation now
      5 - The Call ID is invalid in this context
      6 - A generic vendor-specific error occurred in the LAC
      7 - Try another.  If LAC is aware of other possible LNS
         destinations, it should try one of them.  This can be used to
         guide an LAC based on LNS policy, for instance, the existence
         of multilink PPP bundles.

   If the length of the Result Code AVP specifies that the Value field
   is more than four octets in length, the remaining octets after the
   General Error Code field are an arbitrary string providing further
   (possibly human readable) text associated with the condition. Human
   readable text in all error messages MUST be provided in the UTF-8
   charset using the Default Language [18].

   Generally, when a General Error Code of 6 is used, additional
   information about the error will be included in the Optional Message
   field that follows the Error Code field in the Result Code AVP.



Valencia                 expires November 1998                  [Page 27]

INTERNET DRAFT                                                  May 1998


   5.7 Hiding of AVP values

   The H ("Hidden") bit in the header of each AVP in a control message
   provides a mechanism to indicate to the receiving peer whether the
   contents of the AVP are hidden or present in cleartext.  This feature
   can be used to hide sensitive control message data such as user
   passwords or user ID's. The H bit MUST NOT be set in the Random
   Vector AVP or Message Type AVP.

   The H bit MUST only be set if a shared secret exists between the
   peers on either end of the tunnel. AVPs involved in the establishment
   of the tunnel, or reporting errors involved in the establishment of
   the tunnel MUST NOT be hidden. These AVPs are the "Host Name" AVP in
   the SCCRQ and SCCRP message, the "Assigned Tunnel ID" in the SCCRQ,
   SCCRP, and StopCCN  message and the "Result Code" in the StopCCN
   message. If the H bit is set in any AVP(s) in a given command
   message, a Random Vector AVP must also be present in the message and
   MUST precede the first AVP having an H bit of 1.

   The length of the AVP value to be hidden is first encoded in the form
   of a Hidden AVP Subformat 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length of Original Value    |          Original Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ...                          |             Padding ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length
      This is length of the Original Value to be obscured in octets.

   Original Value
      Value of hidden AVP that is to be obscured.

   Padding
      Random additional octets used to obscure length of the Original
      Value.

   The resulting subformat MAY be padded to a multiple of 16 octets in
   length. For example, if the Original Value to be obscured is a string
   containing 6 characters (e.g. password 'foobar'), then 8 + n * 16
   octets of padding would be applied. Padding does NOT alter the value
   placed in the Length of the Original Value, only the length of the
   AVP itself.

   Next, An MD5 hash is performed on the concatenation of:

      - the 2 octet Attribute number of the AVP (in network order)
      - the shared authentication secret
      - an arbitrary length random vector

   The value of the random vector used in this hash is passed in the



Valencia                 expires November 1998                  [Page 28]

INTERNET DRAFT                                                  May 1998


   value field of a Random Vector AVP.  This Random Vector AVP must be
   placed in the message by the sender before any hidden AVPs.  The same
   random vector may be used for more than one hidden AVP in the same
   message.  If a different random vector is used for the hiding of
   subsequent AVPs then a new Random Vector AVP must be placed in the
   command message before the first AVP to which it applies.

   The MD5 hash value is then XORed with the first 16 octet or less
   segment of the Hidden AVP Subformat and placed in the Value field of
   the Hidden AVP.  If the Hidden AVP Subformat is less than 16 octets,
   the Subformat is transformed as if the Value field had been padded to
   16 octets before the XOR, but only the actual octets present in the
   Subformat are modified, and the length of the AVP is not altered.

   If the Subformat is longer than 16 octets, a second one-way MD5 hash
   is calculated over a stream of octets consisting of the shared secret
   followed by the result of the first XOR.  That hash is XORed with the
   second 16 octet or less segment of the Subformat and placed in the
   corresponding octets of the Value field of the Hidden AVP.

   If necessary, this operation is repeated, with the shared secret used
   along with  each XOR result to generate the next hash to XOR the next
   segment of the value with.

   The method is taken from the book "Network Security" by Kaufman,
   Perlman and Speciner [4] pages 109-110.  A more precise explanation
   of the method follows:

   Call the shared secret S, the Random Vector RV, and the Attribute
   Value AV, Break the value field into 16-octet chunks p1, p2, etc.
   with the last one padded at the end with random data to a 16-octet
   boundary.  Call the ciphertext blocks c(1), c(2), etc.  We'll need
   intermediate values b1, b2, etc.

             b1 = MD5(AV + S + RA)   c(1) = p1 xor b1
             b2 = MD5(S  + c(1))     c(2) = p2 xor b2
                         .                       .
                         .                       .
                         .                       .
             bi = MD5(S  + c(i-1))   c(i) = pi xor bi

   The String will contain c(1)+c(2)+...+c(i) where + denotes
   concatenation.

   On receipt, the random vector is taken from the last Random Vector
   AVP encountered in the message prior to the AVP to be unhidden.  The
   above process is then reversed to yield the original value.  For more
   details on this hiding method, consult RFC 2058 [8].

   The Random Vector AVP has the following format:

   Random Vector





Valencia                 expires November 1998                  [Page 29]

INTERNET DRAFT                                                  May 1998


       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|0|0|0|   6 + String length   |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              36               | Random Octet String ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Random Vector AVP may be used in any message type.  The Attribute
   value is 36 and it is marked mandatory. It is used to enable the
   hiding of the values of arbitrary AVPs.  It MUST precede any AVP
   containing an AVP with the H bit set but it MUST NOT itself have the
   H bit set.  More than one Random Vector AVP may appear in a message,
   in which case the one most closely preceding an AVP with the H bit
   set pertains to that AVP.  The Random Octet String is the random
   vector value to use in computing the MD5 hash to retrieve the
   original value of a hidden AVP.  This string can be of arbitrary
   length, although a random vector of at least 16 octets is
   recommended. The only AVP that the Random Vector AVP MUST NOT precede
   is the Message Type AVP (which is always the first AVP in a message).

6.0 Control Connection Protocol Specification

   Control Connection messages are used to establish and clear user
   sessions.  The first set of Control Connection messages are used to
   maintain the control connection itself.  The control connection is
   initiated by an LAC or LNS after establishing the underlying tunnel-
   over-media connection.

   6.0.1 Control Connection Collision

      For the case where an LAC and LNS both initiate tunnels to each
      other concurrently, and where the LAC and LNS both determine that
      a single tunnel suffices (generally because of media
      characteristic considerations, for instance, whether individual
      tunnels are needed to gain QOS guarantees for each tunnel), a "tie
      breaker" may be undertaken.  The details of breaking a tie are
      documented with the tunnel establishment messages (Sec. 6.1).

   6.0.2 Reliable Delivery of Control Messages

      Since L2TP may run across media where packets may be lost, an L2TP
      peer sending a control message will retransmit the control message
      after deciding that its remote peer has not received it.  The
      reliable transport mechanism built into L2TP is essentially a
      lower layer transport service; the Nr and Ns fields of the control
      message header belong to this transport layer.  The higher layer
      functions of L2TP are not concerned with retransmission or
      ordering of control messages.

      Each tunnel maintains a queue of control messages to be
      transmitted to the peer.  The message at the front of the queue is
      sent with a given Ns value, and is held until a control message
      arrives from the peer in which the Nr field indicates receipt of



Valencia                 expires November 1998                  [Page 30]

INTERNET DRAFT                                                  May 1998


      this message.  After a fixed (a recommended default is 1 second)
      or adaptive (see Appendix D) timeout interval expires without
      receiving such an acknowledgment, the control message packet is
      retransmitted.  The retransmitted packet contains the same Ns
      value, but the Nr value MUST be updated with the current value of
      Sr to reflect any packets received in the interim.

      If no peer response is detected after several retransmissions (a
      recommended default is 5), the tunnel and all sessions within MUST
      be cleared.  One important class of media which deserves special
      consideration is public networks such as the Internet.  Because
      the latency across this type of network may be greater, and
      because transient interruptions may span longer periods of time,
      more appropriate values in this environment would be a timeout of
      2 seconds, and a permitted number of retransmissions of 30.  A
      product may default to either the 1/5 or 2/30 values as deemed
      appropriate for its primary use, but both the timeout interval and
      retransmission count MUST be configurable across a range which
      spans all possible defaults.

      When a tunnel is being shut down for reasons other than loss of
      connectivity, the state and reliable delivery mechanisms MUST be
      maintained and operated for the full retransmission interval after
      the final message exchange has occurred.  This permits reliable
      delivery of closing messages in environments where these closing
      messages might be dropped.

      A peer MUST NOT withhold acknowledgment of packets as a technique
      for flow controlling control messages.  An L2TP implementation is
      expected to be able to keep up with incoming control messages,
      possibly responding to some with errors reflecting an inability to
      honor the requested action.

      A sliding window mechanism is used, by default, for control
      message transmission.  The default is to permit four control
      messages to be outstanding on a given tunnel.  Consider two peers
      A & B. Suppose A specifies a Receive Window Size AVP with a value
      of N in the Start-Control-Connection-Request or -Reply packets. B
      is now allowed to have up to N outstanding control messages. Once
      N have been sent, however, it must wait for an acknowledgment that
      advances the window before sending new control messages.  An
      implementation may support a receive window of only 1 (i.e., by
      sending out a Receive Window Size AVP with a value of 1), but MUST
      accept a window of up to 4 from its peer.  Unlike payload
      sessions, a value of 0 for the Receive Window Size AVP is invalid
      for a control session.

      The transport layer at a receiving peer is responsible for making
      sure that control messages are delivered in order to the higher
      layer and that duplicate messages are not delivered to the higher
      layer.  Messages arriving out of order may be queued for in-order
      delivery when the missing messages are received or they may be
      discarded, requiring a retransmission.




Valencia                 expires November 1998                  [Page 31]

INTERNET DRAFT                                                  May 1998


   6.0.3 Control Message Format

      The following Control Connection messages are all sent as packets
      on the established tunnel connection between a given LNS-LAC pair.
      All data is sent in network order (high order octets first).  Any
      "reserved" or "empty" fields MUST be sent as 0 values to allow for
      protocol extensibility.

      Each control message has a header, specified in section 5.2,
      including an AVP indicating the type of control message, followed
      by zero or more AVP's appropriate for the given type of control
      message.  Each control message is described first at a block
      level, and then with details of each AVP.

6.1 Start-Control-Connection-Request (SCCRQ)

   The Start-Control-Connection-Request is an L2TP control message used
   to initialize the tunnel between an LNS and an LAC.  The tunnel must
   be initialized through the exchange of these control messages before
   any other L2TP messages can be issued.  The establishment of the
   control connection is started by the initiator of the underlying
   tunnel.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    L2TP Control Message Header      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Start-Control-Connection-Request   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Protocol Version      |
   | Framing Capabilities  |
   | Bearer Capabilities   |
   | Tie Breaker           |
   | Firmware Revision     |
   | Host Name             |
   | Vendor Name           |
   | Assigned Tunnel ID    |
   | Receive Window Size   |
   | Challenge             |
   +-+-+-+-+-+-+-+-+-+-+-+-+

   Start-Control-Connection-Request

       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|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                0              |               1               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Message Type AVP contains a Value of 1, indicating Start-
      Control-Connection-Request.  The Flags indicate a mandatory
      option.  Details associated with this tunneled session follow in
      additional AVP's within the packet.



Valencia                 expires November 1998                  [Page 32]

INTERNET DRAFT                                                  May 1998


   Protocol Version

       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|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               2               |     0x01      |     0x00      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Protocol Version AVP within a Start-Control-Connection-Request
      packet indicates the L2TP protocol version available.  The
      Attribute value is 2, indicating Protocol Version, and is marked
      mandatory.  This AVP MUST be present.  The Value field is a 16-bit
      hexadecimal value 0x100, indicating L2TP protocol version 1,
      revision 0.

   Framing Capabilities

       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|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               3               |     0x00      |     0x00      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x00      |0|0|0|0|0|0|A|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Framing Capabilities AVP within a Start-Control-Connection-
      Request indicates the type of framing that the sender of this
      message can provide.  The Attribute value is 3, indicating Framing
      Capabilities, and is marked mandatory.  This AVP MUST be present.
      The Value field is a 32-bit quantity, with two bits defined.  If
      bit A is set, asynchronous framing is supported.  If bit S is set,
      synchronous framing is supported.

      This AVP provides the peer with an indication of the types of
      framing that will be accepted or initiated by the sender.  A peer
      should not initiate an incoming or outgoing call with a Framing
      Type AVP specifying a value not advertised in the Framing
      Capabilities AVP it received during control connection
      establishment.  Attempts to do so will result in the call being
      rejected.













Valencia                 expires November 1998                  [Page 33]

INTERNET DRAFT                                                  May 1998


   Bearer Capabilities

       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|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               4               |     0x00      |     0x00      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x00      |0|0|0|0|0|0|A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Bearer Capabilities AVP within a Start-Control-Connection-
      Request indicates the bearer capabilities that the sender of this
      message can provide for outgoing calls.  The Attribute value is 4,
      indicating Bearer Capabilities, and is marked mandatory.  This AVP
      MUST be present if the sender can place outgoing calls when
      requested.  The Value field is a 32-bit quantity with two bits
      defined.  If bit A is set, analog access is supported.  If bit D
      is set, digital access is supported.

      This AVP provides the peer with an indication of the bearer device
      types supported by the hardware interfaces of the sender for
      outgoing calls.  An LNS should not initiate an outgoing call
      specifying a value in the Bearer Type AVP for a device type not
      advertised in the Bearer Capabilities AVP it received from the LAC
      during control connection establishment.  Attempts to do so will
      result in the call being rejected.

      Note that an LNS that cannot act as an LAC as well will not
      support hardware devices for handling incoming and outgoing calls
      and should therefore set the A and D bits in the Value field of
      this AVP to 0, or should not send the AVP at all.  An LNS that can
      also act as an LAC and place outgoing calls should set the
      appropriate bits in the Value field of this AVP. Presence of this
      message is not a guarantee that a given outgoing call will be
      placed by the sender if requested, just that the physical
      capability exists.

   Tie Breaker

       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|        14         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               5               | Tie Break Value...            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Value...                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    ...(64 bits)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Tie Breaker AVP within a Start-Control-Connection-Request



Valencia                 expires November 1998                  [Page 34]

INTERNET DRAFT                                                  May 1998


      contains a 64-bit Value used to break ties in tunnel establishment
      between an LAC-LNS pair.  The Attribute value is 5, indicating Tie
      Breaker, and is marked optional.  This AVP itself is optional.
      The 8 octet Value is used as a 64-bit tie breaker value.

      If present, it indicates the sender wishes a single tunnel to
      exist between the given LAC-LNS pair, and this value will be used
      to choose a single tunnel where both LAC and LNS initiate a tunnel
      concurrently.  The recipient of a Start-Control-Connection-Request
      must check to see if a Start-Control-Connection-Request has been
      sent to the peer, and if so, must compare its Tie Breaker value
      with the received one.  The lower value "wins", and the "loser"
      MUST silently discard its tunnel.  In the case where a tie breaker
      is present on both sides, and the value is equal, both sides MUST
      discard their tunnels.

      If a tie breaker is received, and the outstanding Start-Control-
      Connection-Request had no tie breaker value, the initiator which
      included the Tie Breaker AVP "wins". If neither side issues a Tie
      breaker, then two separate tunnels are opened.

      It is recommended that the Value be set to the MAC address of a
      LAN interface on the sender.  If no MAC address is available, a
      64-bit random number should be used instead.

   Firmware Revision

       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|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               6               |       Firmware Revision       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Firmware Revision AVP within a Start-Control-Connection-
      Request indicates the firmware revision of the issuing device.
      The Attribute value is 6, indicating Firmware Revision, and is
      marked optional.  This AVP itself is optional.  The Value field is
      a 16-bit integer encoded in a vendor specific format.  For devices
      which do not have a firmware revision (general purpose computers
      running L2TP software modules, for instance), the revision of the
      L2TP software module may be reported instead.

   Host Name

       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|0|0|0|0|0| 6 + Host name len |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               7               | Host name...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Valencia                 expires November 1998                  [Page 35]

INTERNET DRAFT                                                  May 1998


      The Host Name AVP within a Start-Control-Connection-Request
      indicates the name of the issuing LAC or LNS.  The Attribute value
      is 7, indicating Host Name, and is marked mandatory.  This AVP
      itself MUST be present.  This name should be as broadly unique as
      possible; for hosts participating in DNS [4], a hostname with
      fully qualified domain would be appropriate.

   Vendor Name

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      3|0|0|0|0|0|0| 6+Vendor Name len|               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               8               | Vendor name...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Vendor Name AVP within a Start-Control-Connection-Request
      contains a vendor specific string describing the type of LAC or
      LNS being used.  The Attribute value is 8, indicating Vendor Name,
      and is marked optional.  This AVP itself is optional.  The Value
      is the indicated number of octets representing the vendor string.

   Assigned Tunnel ID

       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|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               9               |           Tunnel ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Assigned Tunnel ID AVP within a Start-Control-Connection-
      Request specifies the Tunnel ID which the receiving peer MUST use
      in the Tunnel ID field of all subsequent packets.  The Attribute
      value is 9, indicating Assigned Tunnel ID, and is marked
      mandatory.  This AVP MUST be present.  Before the Assigned Tunnel
      ID AVP is received, packets MUST be sent with a Tunnel ID value of
      0.  The Value is a 16-bit non-zero Tunnel ID value.

   Receive Window Size

       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|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              10               |             Size              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Receive Window Size AVP within a Start-Control-Connection-
      Request specifies the receive window size being offered to the
      remote peer.  The Attribute value is 10, indicating Receive Window



Valencia                 expires November 1998                  [Page 36]

INTERNET DRAFT                                                  May 1998


      Size, and is mandatory.  This AVP itself is optional.  Value is a
      16-bit word indicating the offered window size.  If absent, the
      peer must assume a value of 4 for its transmit window.  The remote
      peer may send the specified number of control messages before it
      must wait for an acknowledgment.

   Challenge

       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|0|0|0|0|0| 6 + Challenge len |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              11               | Challenge...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Challenge AVP within a Start-Control-Connection-Request
      indicates that the issuing peer wishes to authenticate the tunnel
      endpoints using a CHAP-style authentication mechanism.  The
      Attribute value is 11, indicating Challenge, and is marked
      mandatory.  This AVP is optional.  The Value is one or more octets
      of challenge value.

6.2 Start-Control-Connection-Reply (SCCRP)

   The Start-Control-Connection-Reply is an L2TP control message sent in
   reply to a received Start-Control-Connection-Request message. Sending
   this message indicates that the request was successful.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    L2TP Control Message Header      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Start-Control-Connection-Reply     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Protocol Version      |
   | Framing Capabilities  |
   | Bearer Capabilities   |
   | Firmware Revision     |
   | Host Name             |
   | Vendor Name           |
   | Assigned Tunnel ID    |
   | Receive Window Size   |
   | Challenge             |
   | Challenge Response    |
   +-+-+-+-+-+-+-+-+-+-+-+-+












Valencia                 expires November 1998                  [Page 37]

INTERNET DRAFT                                                  May 1998


   Start-Control-Connection-Reply

       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|0|0|0|0|0|      8            |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                0              |               2               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Message Type AVP contains a Value of 2, indicating Start-
      Control-Connection-Reply.  The Flags indicate a mandatory option.

   Protocol Version

       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|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               2               |     0x01      |     0x00      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Protocol Version AVP within a Start-Control-Connection-Reply
      packet indicates the L2TP protocol version available.  The
      Attribute value is 2, indicating Protocol Version, and the Value
      field is a 16-bit hexadecimal value 0x100, indicating L2TP
      protocol version 1, revision 0.  This AVP MUST be present.

   Framing Capabilities

       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|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               3               |     0x00      |     0x00      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x00      |0|0|0|0|0|0|A|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Framing Capabilities AVP within a Start-Control-Connection-
      Reply indicates the type of framing that the sender of this
      message can provide.  The Attribute is 3, it is a mandatory AVP,
      the Value field is a 32-bit quantity, with two bits defined.  If
      bit A is set, asynchronous framing is supported.  If bit S is set,
      synchronous framing is supported.  This AVP MUST be present.

      More details on the use of this AVP can be found in Sec. 6.1.








Valencia                 expires November 1998                  [Page 38]

INTERNET DRAFT                                                  May 1998


   Bearer Capabilities

       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|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               4               |     0x00      |     0x00      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x00      |0|0|0|0|0|0|A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Bearer Capabilities AVP within a Start-Control-Connection-
      Reply indicates the bearer capabilities that the sender of this
      message can provide for outgoing calls.  The Attribute is 4, it is
      a mandatory AVP, the Value field is a 32-bit quantity with two
      bits defined.  If bit A is set, analog access is supported.  If
      bit D is set, digital access is supported.  This AVP MUST be
      present if outgoing calls can be placed by the sender of this
      message.

      More details on the use of this AVP can be found in Sec. 6.1.

   Firmware Revision

       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|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               6               |       Firmware Revision       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Firmware Revision AVP within a Start-Control-Connection-Reply
      indicates the firmware revision of the issuing device.  The
      Attribute is 6, it is not a mandatory AVP, the Value field is a
      16-bit integer encoded in a vendor specific format.  For devices
      which do not have a firmware revision (general purpose computers
      running L2TP software modules, for instance), the revision of the
      L2TP software module may be reported instead.  This AVP is
      optional.

   Host Name

       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|0|0|0|0|0| 6 + Host Name len |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               7               | Host Name...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Host Name AVP within a Start-Control-Connection-Reply
      indicates the name of the issuing LAC or LNS.  See the notes in



Valencia                 expires November 1998                  [Page 39]

INTERNET DRAFT                                                  May 1998


      section 6.1 concerning Host Name contents.  It is encoded as the
      Attribute 7, mandatory, with the indicated number of octets
      representing the host name string.  This AVP MUST be present.

   Vendor Name

       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+Vendor Name len |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               8               |Vendor Name...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Vendor Name AVP within a Start-Control-Connection-Reply
      contains a vendor specific string describing the type of LAC or
      LNS being used.  It is encoded as the Attribute 8, not mandatory,
      with the indicated number of octets representing the vendor
      string.  This AVP is optional.

   Assigned Tunnel ID

       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|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               9               |           Tunnel ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Assigned Tunnel ID AVP within a Start-Control-Connection-Reply
      specifies the Tunnel ID which the receiving peer MUST use in all
      subsequent packets.  It is encoded as the Attribute 9, mandatory,
      with a 16-bit non-zero Tunnel ID value.  This AVP MUST be present.

   Receive Window Size

       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|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              10               |             size              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Receive Window Size AVP within a Start-Control-Connection-
      Reply specifies the receive window size being offered to the
      remote peer.  The Attribute value is 10, indicating Receive Window
      Size, and is mandatory.  This AVP itself is optional.  Value is a
      16-bit word indicating the offered window size.  If absent, the
      peer must assume a value of 4 for its transmit window.  The remote
      peer may send the specified number of control messages before it
      must wait for an acknowledgment.




Valencia                 expires November 1998                  [Page 40]

INTERNET DRAFT                                                  May 1998


   Challenge

       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|0|0|0|0|0| 6 + Challenge len |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              11               | Challenge...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Challenge AVP within a Start-Control-Connection-Reply
      indicates that the peer wishes to authenticate the tunnel
      initiator using a CHAP-style authentication mechanism.  It is
      encoded as the Attribute 11, mandatory, with at least one octet of
      challenge value embedded.  If this AVP is not present, it
      indicates to the receiving peer that the sender does not wish to
      authenticate that peer.

   Challenge Response

       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|0|0|0|0|0|        22         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              13               |   Response...                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Response... (128 bits)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Response AVP within a Start-Control-Connection-Reply packet
      provides a response to a challenge received.  The Attribute value
      is 13, indicating Response, and the Value field is a 128-bit value
      reflecting the CHAP-style response to the challenge.  This AVP
      marked mandatory, and MUST be present if a challenge was received
      and this Start-Control-Connection-Reply indicates success.  For
      purposes of the ID value in the CHAP response calculation, the
      value 2 (corresponding to the Value field of the Start-Control-
      Connection-Reply AVP) MUST be used.

6.3 Start-Control-Connection-Connected (SCCCN)

   The Start-Control-Connection-Connected message is an L2TP control
   message sent in reply to a received Start-Control-Connection-Reply
   message.  This message provides closure to the tunnel establishment
   process, and includes a challenge response if the peer sent a
   challenge in the Start-Control-Connection-Reply message.










Valencia                 expires November 1998                  [Page 41]

INTERNET DRAFT                                                  May 1998


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    L2TP Control Message Header      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Start-Control-Connection-Connected |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Challenge Response    |
   +-+-+-+-+-+-+-+-+-+-+-+-+

   Start-Control-Connection-Connected

       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|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               0               |               3               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Message Type AVP contains a Value of 3, indicating Start-
      Control-Connection-Connected.  The Flags indicate a mandatory
      option.

   Challenge Response

       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|0|0|0|0|0|        22         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              13               |   Response...                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Response... (128 bits)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Challenge Response AVP within a Start-Control-Connection-
      Connected packet provides a response to a challenge received.  The
      Attribute value is 13, indicating Response, and the Value field is
      a 128-bit value reflecting the CHAP-style response to the
      challenge.  This AVP is marked mandatory, and MUST be present if a
      challenge was received, otherwise MUST be omitted.  For purposes
      of the ID value in the CHAP response calculation, the value 3
      (corresponding to the Value field of the Start-Control-
      Connection-Connected AVP) MUST be used.

6.4 Stop-Control-Connection-Notification (StopCCN)

   The Stop-Control-Connection-Notification is an L2TP control message
   sent by one peer of an LAC-LNS control connection to inform the other
   peer that the control connection should be closed.  In addition to
   closing the control connection, all active user calls are implicitly
   cleared.  The reason for issuing this request is indicated in the
   Result Code AVP.





Valencia                 expires November 1998                  [Page 42]

INTERNET DRAFT                                                  May 1998


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    L2TP Control Message Header      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Stop-Control-Connection-Notification|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Assigned Tunnel ID    |
   | Result Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+

   Stop-Control-Connection-Notification AVP

       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|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               0               |               4               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Message Type AVP contains a Value of 4, indicating Stop-
      Control-Connection-Notification.  The Flags indicate a mandatory
      option.

   Assigned Tunnel ID

       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|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               9               |           Tunnel ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Attribute value is 9, indicating Assigned Tunnel ID, and is
      marked mandatory.  This AVP MUST be present.  The Value MUST be
      the same Assigned Tunnel ID first sent to the receiving peer.
      This AVP permits the peer to identify the appropriate tunnel even
      if Stop-Control-Connection-Notification must be sent before an
      Assigned Tunnel ID is received.

   Result Code

       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|0|0|0|0|0|  10 + Message len |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               1               |          Result Code          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Error Code          |      Optional Message ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Result Code AVP within a Stop-Control-Connection-Notification
      packet indicates the reason for terminating the control channel.



Valencia                 expires November 1998                  [Page 43]

INTERNET DRAFT                                                  May 1998


      It is encoded as Attribute 1, indicating a Result Code AVP.  This
      AVP is mandatory and MUST be present.  The Result Code is a 16-bit
      word.  The 16-bit word following the Result Code field contains
      the Error Code value, which for a Stop-Control-Connection-
      Notification is always 0.  An optional message can follow the
      Error Code field.  Its presence and length is indicated by the
      value of the AVP length field.  Defined Result Code values are:

         1 - General request to clear control connection
         2 - General error--Error Code indicates the problem
         3 - Control channel already exists
         4 - Requester is not authorized to establish a control channel
         5 - The protocol version of the requester is not supported
             Error Code indicates highest version supported
         6 - Requester is being shut down
         7 - Finite State Machine error

6.5 Hello

   The Hello message is an L2TP control message sent by either peer of a
   LAC-LNS control connection.  This control message is used as a
   "keepalive" for the tunnel.

   The sending of Hello messages and the policy for sending them are
   left up to the implementation. A peer MUST NOT "expect" Hello
   messages at any time or interval.  When a Hello is received, it MUST
   be ignored (after updating any effects of the indicated Nr/Ns values,
   and being acknowleged).

   Since a Hello is a control message, and control messages are reliably
   sent by the lower level transport, this keepalive function operates
   by causing the transport level to reliably deliver a message.  If a
   media interruption has occurred, the reliable transport will be
   unable to deliver the Hello across, and will clean up the tunnel.

   Keepalives for the tunnel MAY be implemented by sending a Hello once
   every 60 seconds if 60 seconds have passed without receiving any
   message (payload or control, including ZLB messages) from the peer.

   Hello messages are global to the tunnel; the Call ID field of these
   control messages MUST be 0.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    L2TP Control Message Header      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Hello                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+










Valencia                 expires November 1998                  [Page 44]

INTERNET DRAFT                                                  May 1998


   Hello

       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|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               0               |               6               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Message Type AVP contains a Value of 6, indicating Hello The
      Flags indicate a mandatory option.

6.6 Outgoing-Call-Request (OCRQ)

   The Outgoing-Call-Request is an L2TP control message sent by the LNS
   to the LAC to indicate that an outbound call from the LNS is to be
   established.  This request provides the LAC with information required
   to make the call.  It also provides information to the LAC that is
   used to regulate the transmission of data to the LNS for this session
   once it is established.

   This message is the first in the "three-way handshake" used by L2TP
   for establishing outgoing calls.  The first message requests the
   call; the second indicates that the call was successfully initiated.
   The third and final message indicates that the call was established.

   An LNS MUST have received a Bearer Capabilities AVP during tunnel
   establishment from an LAC in order to request an outgoing call to
   that LAC.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          L2TP Control Message Header        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Outgoing-Call-Request            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Assigned Call ID        |
   | Call Serial Number      |
   | Minimum BPS             |
   | Maximum BPS             |
   | Bearer Type             |
   | Framing Type            |
   | Receive Window Size     |
   | Packet Processing Delay |
   | Dialed Number           |
   | Sub-Address             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+










Valencia                 expires November 1998                  [Page 45]

INTERNET DRAFT                                                  May 1998


   Outgoing-Call-Request

       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|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               0               |               7               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Message Type AVP contains a Value of 7, indicating Outgoing-
      Call-Request.  The Outgoing-Call-Request encodes a request to an
      LAC to establish an outgoing call.  The flags indicate a mandatory
      option.

      Assigned Call ID

       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|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              14               |            Call ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Assigned Call ID AVP encodes the ID being assigned to this
      call by the LNS.  The Attribute value is 14, indicating Assigned
      Call ID, and is marked mandatory.  This AVP MUST be present.  The
      LAC places this value in the Call ID header field of all command
      and payload packets that it subsequently transmits over the tunnel
      that belong to this call.  The Call ID value is an identifier
      assigned by the LNS to this session.  It is used to multiplex and
      demultiplex data sent over that tunnel between the LNS and LAC.

      Call Serial Number

       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|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              15               |           CSN (H)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            CSN (L)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Call Serial Number AVP encodes an identifier assigned by the LNS to
      this call.  Attribute is 15, indicating Call Serial Number, and is
      marked mandatory.  This AVP MUST be present.  The Call Serial Number
      is intended to be an easy reference for administrators on both ends of
      a tunnel to use when investigating call failure problems.  Call Serial
      Numbers should be set to progressively increasing values, which are
      likely to be unique for a significant period of time across all
      interconnected LNS and LACs.  Other identification information may



Valencia                 expires November 1998                  [Page 46]

INTERNET DRAFT                                                  May 1998


      also be prepended.

      Minimum BPS

       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|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              16               |           BPS (H)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            BPS (L)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Minimum BPS AVP encodes the lowest acceptable line speed for this
      call.  Attribute is 16, Minimum BPS, and is marked mandatory.
      This AVP MUST be present.  The BPS value indicates the speed in
      bits/second.

      Maximum BPS

       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|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              17               |           BPS (H)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            BPS (L)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Maximum BPS AVP encodes the highest acceptable line speed for this
      call.  Attribute is 17, indicating Maximum BPS, and is marked
      mandatory.  This AVP MUST be present.  The BPS value indicates the
      speed in bits/second.

      Bearer Type

       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|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              18               |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Bearer Type AVP encodes the bearer type for the requested call.
      The Attribute is 18, indicating Bearer Type, and is marked
      mandatory.  This AVP MUST be present.  The Value is a 32-bit
      quantity indicating the bearer capability required for this
      outgoing call.  If set, bit A indicates that the call should be on
      an analog channel.  If set, bit D indicates that the call should



Valencia                 expires November 1998                  [Page 47]

INTERNET DRAFT                                                  May 1998


      be on a digital channel.  Both may be set, indicating that the
      call can be of either type.

      A particular bit in the Value field of this AVP MAY only be set by
      the LNS if it was set in the Bearer Capabilities AVP received from
      the LAC during control session establishment.

      Framing Type

       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|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              19               |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Framing Type AVP encodes the framing type for the requested call.
      Attribute is 19, indicating Framing Type, and is marked mandatory.
      This AVP MUST be present.  The 32-bit field indicates the type of
      PPP framing to be used for the outgoing call.  If set, Bit A
      indicates that asynchronous framing should be used.  If set, Bit S
      indicates that synchronous framing should be used.  Both may be
      set, indicating that either type of framing may be used for the
      call.

      A particular bit in the Value field of this AVP MAY only be set by
      the LNS if it was set in the Framing Capabilities AVP received
      from the LAC during control session establishment.

      Receive Window Size

       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|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              10               |             Size              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Receive Window Size AVP encodes the window size being advertised
      by the LNS for this call.  Attribute is 10, indicating Receive
      Window Size, and is marked mandatory.  This AVP is optional.  The
      Size value indicates the number of received data packets the LNS
      will buffer for this call, which is also the maximum number of
      data packets the LAC should send before waiting for an
      acknowledgment.  The absence of this AVP indicates that Sequence
      and Acknowledgment Numbers are not to be used in the payload
      session for this call.






Valencia                 expires November 1998                  [Page 48]

INTERNET DRAFT                                                  May 1998


      Packet Processing Delay

       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|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              20               |             Delay             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Packet Processing Delay AVP encodes the delay that is expected
      at the LNS in processing a window full of packets sent by the LAC.
      Attribute is 20, indicating Packet Processing Delay, and is marked
      mandatory.  This AVP is optional.  The Delay value is specified in
      units of 1/10 seconds.  Refer to Appendix A for a description of
      how this value is determined and used.

      Dialed Number

       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|0|0|0|0|0| 6+Phone Number len|               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              21               | Phone Number..
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Phone Number AVP encodes the phone number to be called.  Attribute
      is 21, indicating Phone Number, and is marked mandatory.  This AVP
      MUST be present.  The Phone Number value is an ASCII string.
      Contact between the administrator of the LAC and the LNS may be
      necessary to coordinate the value needed in this AVP.

      Sub-Address

       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|0|0|0|0|0| 6+Sub-Address len |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              23               |Sub-Address ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Sub-Address AVP encodes additional dialing information.  Attribute
      is 23, indicating Sub-Address, and is marked mandatory.  This AVP
      is optional.  The Sub-Address value is an ASCII string. Contact
      between the administrator of the LAC and the LNS may be necessary
      to coordinate the value needed in this AVP.

6.7 Outgoing-Call-Reply (OCRP)

   The Outgoing-Call-Reply is an L2TP control message sent by the LAC to
   the LNS in response to a received Outgoing-Call-Request message. The
   reply indicates that the LAC is able to attempt the outbound call and



Valencia                 expires November 1998                  [Page 49]

INTERNET DRAFT                                                  May 1998


   also returns certain parameters regarding the call attempt.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          L2TP Control Message Header        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Outgoing-Call-Reply             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Assigned Call ID          |
   | Physical Channel Id       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Outgoing-Call-Reply

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |               8               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Message Type AVP contains a Value of 8, indicating Outgoing-
   Call-Reply.  The Outgoing-Call-Reply message encodes the immediate
   result of attempting an outgoing call request.  The flags indicate a
   mandatory option.

   Assigned Call ID

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              14               |            Call ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Assigned Call ID AVP encodes the ID being assigned to this call
   by the LAC.  Attribute is 14, indicating Assigned Call ID, and is
   marked mandatory.  This AVP MUST be present.  Call ID value is an
   identifier, unique within the tunnel, assigned by the sender to this
   session.  The remote peer MUST place this Call ID in the Call ID
   portion of all future packets it sends associated with this session.
   It is used to multiplex and demultiplex data sent over that tunnel
   between the LNS and LAC.













Valencia                 expires November 1998                  [Page 50]

INTERNET DRAFT                                                  May 1998


   Physical Channel ID

    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|        10         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              25               |            ID (H)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          ID (L)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Physical Channel ID AVP encodes the vendor specific physical channel
   number used for the call.  The Attribute value is 25, indicating
   Physical Channel ID, and is marked optional.  This AVP itself is
   optional.  ID is a 32-bit value in network byte order.  The value is
   used for logging purposes only.

6.8 Outgoing-Call-Connected (OCCN)

   Outgoing-Call-Connected is an L2TP control message sent by the LAC to
   the LNS to indicate that the result of a requested outgoing call was
   successful.  The LAC MUST send the corresponding Outgoing-Call-Reply
   to the LNS before sending this message.  This message provides
   information to the LNS about the particular parameters used for the
   call.  It provides information to allow the LNS to regulate the
   transmission of data to the LAC for this session.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          L2TP Control Message Header        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Outgoing-Call-Connected          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | (Tx) Connect Speed        |
   | Framing Type              |
   | Receive Window Size       |
   | Packet Processing Delay   |
   | Rx Connect Speed          |
   | Sequencing Required       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Outgoing-Call-Connected

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |               9               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Message Type AVP contains a Value of 9, indicating Outgoing-
   Call-Connected.  The Outgoing-Call-Connected message encodes the
   final result of an outgoing call request.  The flags indicate a



Valencia                 expires November 1998                  [Page 51]

INTERNET DRAFT                                                  May 1998


   mandatory option.

   (Tx) Connect Speed

    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|0|0|0|0|0|        10         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              24               |            BPS (H)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           BPS (L)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   (Tx) Connect Speed BPS AVP encodes the speed of the facility chosen
   for the connection attempt.  The Attribute value is 24, indicating
   (Tx) Connect Speed, and is marked mandatory. This AVP MUST be
   present.  BPS is a 32-bit value indicating the speed in bits/second.

   When the optional Rx Connect Speed AVP is present, the value in this
   AVP represents the transmit connect speed, from the perspective of
   the LAC (e.g. data flowing from the LAC to the client).  When the
   optional Rx Connect Speed AVP is NOT present, the connection speed
   between the client and LAC is assumed to be symmetric and is
   represented by the single value in this AVP.

   Framing Type

    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|0|0|0|0|0|        10         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              19               |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Framing Type AVP encodes the framing type for the call.  The
   Attribute value is 19, indicating Framing Type, and is marked
   mandatory.  This AVP MUST be present.  The bit field indicates the
   type of PPP framing used for the call.  If set, bit A indicates that
   asynchronous framing is being used.  If set, bit S indicates that
   synchronous framing is being used. A particular type of framing may
   be used only if it was specified in the Framing Type AVP of the
   Outgoing-Call-Request issued by the LNS. The framing type MAY be used
   as an indication to PPP on the LNS as to what link options to use for
   LCP (refer to "PPP in HDLC-like Framing" [14]).








Valencia                 expires November 1998                  [Page 52]

INTERNET DRAFT                                                  May 1998


   Receive Window Size

    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|0|0|0|0|0|         8         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              10               |            Size               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Receive Window Size AVP encodes the window size being offered by the
   LNS for this call.  The Attribute value is 10, indicating Receive
   Window Size, and is marked mandatory.  The Size is a 16-bit value
   indicating the number of received data packets the LAC will buffer
   for this call, which is also the maximum number of data packets the
   LNS should send before waiting for an acknowledgment.  This AVP is
   present only if Sequence and Acknowledgment Numbers are to be used in
   the payload session for this call.

   Packet Processing Delay

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              20               |             Delay             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet Processing Delay AVP encodes the delay the LAC expects for
   processing a window full of packets sent by the LNS.  The Attribute
   value is 20, indicating Packet Processing Delay, and is marked
   mandatory.  This AVP is optional.  The Delay value is specified in
   units of 1/10 seconds.  Refer to Appendix A to see a description of
   how this value is determined and used.

   Rx Connect Speed

    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|        10         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              38               |            BPS (H)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           BPS (L)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Rx Connect Speed BPS AVP encodes the receive speed of the facility
   chosen for the connection attempt.  The Attribute value is 38,
   indicating Rx Connect Speed, and is marked optional.  The Rx Connect
   Speed represents the speed of the connection from the perspective of
   the LAC (e.g. data flowing from the client to the LAC).  Presence of
   this AVP implies that the connection speed may be asymmetric, with



Valencia                 expires November 1998                  [Page 53]

INTERNET DRAFT                                                  May 1998


   the transmit connect speed given in the (Tx) Connect Speed AVP.  BPS
   is a 32-bit value indicating the speed in bits/second.

   Sequencing Required

    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|0|0|0|0|0|          6        |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              39               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Sequencing Required AVP indicates to the LNS that Sequence
   Numbers MUST always be present, thus the ability to dynamically drop
   sequencing as described in section 4.2 is not an available option.
   The Attribute value is 38, Sequencing Required, and is marked
   mandatory.  The presence of this AVP is optional.  This AVP MUST NOT
   be present if the Receive Window Size AVP is not present. There is no
   value field.

6.9 Incoming-Call-Request (ICRQ)

   Incoming-Call-Request is an L2TP control message sent by the LAC to
   the LNS to indicate that an inbound call is to be established from
   the LAC.  This request provides the LNS with parameter information
   for the incoming call.

   This message is the first in the "three-way handshake" used by L2TP
   for establishing incoming calls.  The LAC may defer answering the
   call until it has received an Incoming-Call-Reply from the LNS
   indicating that the call should be established.  This mechanism
   allows the LNS to obtain sufficient information about the call before
   determining whether the call should be answered or not.
   Alternatively, the LAC may answer the call, negotiate LCP and PPP
   authentication, and use the information gained to choose the LNS.  In
   this case, the call has already been answered by the time the
   Incoming-Call-Reply message is received; the LAC simply spoofs the
   "call indication/answer call" phase in this case.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          L2TP Control Message Header        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Incoming-Call-Request           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Assigned Call ID          |
   | Call Serial Number        |
   | Bearer Type               |
   | Physical Channel ID       |
   | Dialed Number             |
   | Dialing Number            |
   | Sub-Address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Valencia                 expires November 1998                  [Page 54]

INTERNET DRAFT                                                  May 1998


   Incoming-Call-Request

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |              10               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Message Type AVP contains a Value of 10, indicating Incoming-
   Call-Request.  The Incoming-Call-Request message encodes an incoming
   call being indicated by the LAC.  The flags indicate a mandatory
   option.

   Assigned Call ID

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              14               |            Call ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Assigned Call ID AVP encodes the ID being assigned to this call
   by the LAC.  The Attribute value is 14, indicating Assigned Call ID,
   and is marked mandatory.  This AVP MUST be present.  The LNS places
   this value in the Call ID header field of all command and payload
   packets that belong to this call and are subsequently transmitted
   over the tunnel.  The Call ID value is an identifier assigned by the
   LAC to this session.  It is used to multiplex and demultiplex data
   sent over that tunnel between the LNS and LAC.

   Call Serial Number

    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|0|0|0|0|0|        10         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              15               |           CSN (H)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            CSN (L)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Call Serial Number AVP encodes an identifier assigned by the LAC to
   this call.  The Attribute value is 15, Call Serial Number, and is
   marked mandatory.  This AVP MUST be present.  Please refer to section
   6.6 for a description of the contents of this AVP.







Valencia                 expires November 1998                  [Page 55]

INTERNET DRAFT                                                  May 1998


   Bearer Type

    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|0|0|0|0|0|          10       |                0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              18               |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Bearer Type AVP encodes the bearer type for the incoming call.  The
   Attribute value is 18, Bearer Type, and is marked mandatory.  This
   AVP is optional.  The Value is a 32-bit field indicating the bearer
   capability being used by the incoming call.  If set, bit A indicates
   that the call is on an analog channel.  If set, bit D indicates that
   the call is on a digital channel. It is valid to set neither the A
   nor D bits. Such a setting may indicate that the call was not
   received over a physical link (e.g if the LAC and PPP are located in
   the same subsystem).

   Physical Channel ID

    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|0|0|0|0|0|          10       |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              25               |            ID (H)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          ID (L)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Physical Channel ID AVP encodes the vendor specific physical channel
   number used for the call.  The Attribute value is 25, Physical
   Channel ID, and is marked mandatory.  The presence of this AVP is
   optional.  ID is a 32-bit value in network byte order.  The value is
   used for logging purposes only.

   Dialed Number

    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|0|0|0|0|0| 6+Phone Number len|               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              21               | Phone Number..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Dialed Number AVP encodes the dialed number for the incoming call,
   that is, DNIS.  The Attribute value is 21, Dialed Number, and is
   marked mandatory.  The presence of this AVP is optional.  The value
   is an ASCII string.



Valencia                 expires November 1998                  [Page 56]

INTERNET DRAFT                                                  May 1998


   Dialing Number

    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|0|0|0|0|0| 6+Phone Number len|               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              22               |Phone Number...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Dialing Number AVP encodes the originating number for the incoming
   call, that is, CLID.  The Attribute value is 22, Dialing Number, and
   is marked mandatory.  The presence of this AVP is optional.  The
   value is an ASCII string.  Contact between the administrator of the
   LAC and the LNS may be necessary to coordinate the value needed in
   this AVP.

   Sub-Address

    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|0|0|0|0|0| 6+Sub-Address len |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              23               |Sub-Address ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Sub-Address AVP encodes additional dialing information.  The
   Attribute value is 23, Sub-Address, and is marked mandatory.  The
   presence of this AVP is optional.  The Sub-Address value is an ASCII
   string.  Contact between the administrator of the LAC and the LNS may
   be necessary to coordinate the value needed in this AVP.

6.10 Incoming-Call-Reply (ICRP)

   The Incoming-Call-Reply is an L2TP control message sent by the LNS to
   the LAC in response to a received Incoming-Call-Request message.  The
   reply indicates that the request was successful.  It also provides
   information to allow the LAC to regulate the transmission of data to
   the LNS for this session.

   This message is the second in the three-way handshake used by L2TP
   for establishing incoming calls.  It indicates to the LAC that the
   call should be answered.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          L2TP Control Message Header        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Incoming-Call-Reply             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Assigned Call ID              |
   | Receive Window Size           |
   | Packet Processing Delay       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Valencia                 expires November 1998                  [Page 57]

INTERNET DRAFT                                                  May 1998


   Incoming-Call-Reply

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |              11               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Message Type AVP contains a Value of 11, indicating Incoming-
   Call-Reply.  The Incoming-Call-Reply message encodes a response by
   the LNS to the incoming call indication given by the LAC.  The flags
   indicate a mandatory option.

   Assigned Call ID

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              14               |            Call ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Assigned Call ID AVP encodes the ID being assigned to this call
   by the LNS.  The Attribute value is 14, indicating Assigned Call ID,
   and is marked mandatory.  This AVP MUST be present.  The LAC places
   this value in the Call ID header field of all command and payload
   packets that it subsequently transmits over the tunnel that belong to
   this call.  The Call ID value is an identifier assigned by the LNS to
   this session.  It is used to multiplex and demultiplex data sent over
   that tunnel between the LNS and LAC.

   Receive Window Size

    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|0|0|0|0|0|         8         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              10               |            Size               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Receive Window Size AVP encodes the receive window size being offered
   by the LNS for this call.  The Attribute value is 10, Receive Window
   Size, and is marked mandatory.  The Size value indicates the number
   of received data packets the LNS will buffer for this call, which is
   also the maximum number of data packets the LAC should send before
   waiting for an acknowledgment.  This AVP is present only if Sequence
   and Acknowledgment Numbers are to be used in the payload session for
   this call.





Valencia                 expires November 1998                  [Page 58]

INTERNET DRAFT                                                  May 1998


   Packet Processing Delay

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              20               |             Delay             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet Processing Delay AVP encodes the expected delay that occurs at
   the LNS in processing a window full of packets sent by the LAC.  The
   Attribute value is 20, Packet Processing Delay AVP, and is marked
   mandatory.  The presence of this AVP is optional.  The Delay value is
   specified in units of 1/10 seconds.  Refer to Appendix A to see a
   description of how this value is determined and used.

6.11 Incoming-Call-Connected (ICCN)

   The Incoming-Call-Connected message is an L2TP control message sent
   by the LAC to the LNS in response to a received Incoming-Call-Reply.
   It provides information to the LNS about particular parameters used
   for the call.  It also provides information to allow the LNS to
   regulate the transmission of data to the LAC for this session.

   This message is the third in the three-way handshake used by L2TP for
   establishing incoming calls.  It provides a mechanism for providing
   the LNS with additional information about the call that cannot, in
   general, be obtained at the time the Incoming-Call-Request is issued
   by the LAC.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          L2TP Control Message Header        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Incoming-Call-Connected         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | (Tx) Connect Speed            |
   | Framing Type                  |
   | Receive Window Size           |
   | Packet Processing Delay       |
   | 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         |
   | Private Group ID              |
   | Rx Connect Speed              |
   | Sequencing Required           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Valencia                 expires November 1998                  [Page 59]

INTERNET DRAFT                                                  May 1998


   Incoming-Call-Connected

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |              12               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Message Type AVP contains a Value of 12, indicating Incoming-
   Call-Connected.  The Incoming-Call-Connected message encodes a
   response by the LAC to the Incoming-Call-Reply message sent by the
   LAC.  The flags indicate a mandatory option.

   (Tx) Connect Speed

    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|0|0|0|0|0|        10         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              24               |            BPS (H)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           BPS (L)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   (Tx) Connect Speed BPS AVP encodes the speed of the facility chosen
   for the connection attempt.  The Attribute value is 24, indicating
   (Tx) Connect Speed, and is marked mandatory. This AVP MUST be
   present.  BPS is a 32-bit value indicating the speed in bits/second.

   When the optional Rx Connect Speed AVP is present, the value in this
   AVP represents the transmit connect speed, from the perspective of
   the LAC (e.g. data flowing from the LAC to the client).  When the
   optional Rx Connect Speed AVP is NOT present, the connection speed
   between the client and LAC is assumed to be symmetric and is
   represented by the single value in this AVP.

   Framing Type

    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|0|0|0|0|0|        10         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              19               |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Framing Type AVP encodes the framing type for the call.  The
   Attribute value is 19, Framing Type, and is marked mandatory.  This
   AVP MUST be present.  The value is a 32-bit bit field indicating the



Valencia                 expires November 1998                  [Page 60]

INTERNET DRAFT                                                  May 1998


   type of PPP framing used for the call.  If set, bit A indicates that
   asynchronous framing is being used.  If set, bit S indicates that
   synchronous framing is being used. A particular type of framing may
   be used only if was specified in the Value field of the Framing
   Capabilities AVP received from the LNS during control session
   establishment.  The framing type MAY be used as an indication to PPP
   on the LNS as to what link options to use for LCP if renegotiation is
   necessary (refer to "PPP in HDLC-like Framing" [14]).

   Receive Window Size

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              10               |             Size              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Receive Window Size AVP encodes the window size being offered by the
   LAC for this call.  The Attribute value is 10, Receive Window Size,
   and is marked mandatory.  This AVP is present only if Sequence and
   Acknowledgment Numbers are to be used in the payload session for this
   call.  The 16-bit Size value indicates the number of received data
   packets the LAC will buffer for this call, which is also the maximum
   number of data packets the LNS should send before waiting for an
   acknowledgment.

   Packet Processing Delay

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              20               |             Delay             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet Processing Delay AVP encodes the delay the LAC expects for
   processing a window full of packets sent by the LNS.  The Attribute
   value is 20, Packet Processing Delay, and is marked mandatory.  The
   presence of this AVP is optional.  The 16-bit Delay value is
   specified in units of 1/10 seconds.  Refer to Appendix A to see a
   description of how this value is determined and used.

   Initial Received LCP CONFREQ

    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+LCP CONFREQ len |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              26               | LCP CONFREQ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Valencia                 expires November 1998                  [Page 61]

INTERNET DRAFT                                                  May 1998


   The LAC may have answered the phone call and negotiated LCP with the
   dial-in client in order to establish the client's apparent identity.
   In this case, this option may be included to indicate the link
   properties the client requested in its initial LCP CONFREQ request.
   The Attribute value is 26, Initial Received LCP CONFREQ, and is
   marked optional.  The presence of this AVP is optional.  The Value
   field is a copy of the body of the initial CONFREQ received, starting
   at the first option within this packet's body.

   Last Sent LCP CONFREQ

    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+LCP CONFREQ len |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              27               | LCP CONFREQ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   See Initial Received LCP CONFREQ above for rationale.  The Attribute
   value is 27, Last Sent LCP CONFREQ, and is marked optional.  The
   presence of this AVP is optional.  The Value field is a copy of the
   body of the final CONFREQ sent to the client to complete LCP
   negotiation, starting at the first option within this packet's body.

   Last Received LCP CONFREQ

    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+LCP CONFREQ len |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              28               | LCP CONFREQ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   See Initial Received LCP CONFREQ above for rationale.  The Attribute
   value is 28, Last Received LCP CONFREQ, and is marked optional.  The
   presence of this AVP is optional.  The Value field is a copy of the
   body of the final CONFREQ received from the client to complete LCP
   negotiation, starting at the first option within this packet's body.

   Proxy Authen Type

    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|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              29               |             Type              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Attribute value is 29, Proxy Authen Type, and is optional.  This
   AVP MUST be present if proxy authentication is to be utilized. If it
   is not present, then it is assumed that this peer cannot perform



Valencia                 expires November 1998                  [Page 62]

INTERNET DRAFT                                                  May 1998


   proxy authentication, perhaps requiring a restart of the
   authentication phase at the LNS if the client has already entered
   this phase with the LAC.  The value Type is a 16-bit word, holding a
   value:

      1 - Textual username/password exchange
      2 - PPP CHAP
      3 - PPP PAP
      4 - None
      5 - Microsoft CHAP (MSCHAP)

   Associated AVP's for each type of authentication follow.

   Proxy Authen Name

    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 + Name length  |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              30               |     Name...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Attribute value is 30, Proxy Authen Name, and is marked optional.
   This AVP MUST be present for Proxy Authen Type values 1, 2, 3 and 5.
   The Name field contains the name specified in the client's
   authentication response.  Note that the AVP H bit may be desirable
   for obscuring the cleartext name.

   Proxy Authen Challenge

    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 + Challenge len |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              31               | Challenge...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Attribute value is 31, Proxy Authen Challenge, and is marked
   optional.  The AVP itself MUST be present for Proxy authen types 2
   and 5.  The Challenge field contains the value presented to the
   client by the LAC.

   Proxy Authen ID

    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|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              32               |              ID               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Valencia                 expires November 1998                  [Page 63]

INTERNET DRAFT                                                  May 1998


   The Attribute value is 32, Proxy Authen ID, and is marked optional.
   The AVP itself MUST be present for Proxy authen types 2, 3 and 5.
   For CHAP and MSCHAP, the ID field contains the byte ID value
   presented to the client by the LAC in its Challenge.  For PAP, it is
   the Identifier value of the Authenticate-Request.  The most
   significant 8 bits of ID MUST be 0, and are reserved.

   Proxy Authen Response

    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|0|0|0|0|0| 6 + Response len  |               0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              33               | Response...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Attribute value is 33, Proxy Authen Response, and is marked
   mandatory.  The AVP itself MUST be present for Proxy authen types 1,
   2, 3 and 5.  The Response field contains the client's response to the
   challenge.  For Proxy authen types 2 and 5, this field contains the
   response value received by the LAC.  For types 1 or 3, it contains
   the clear text password received from the client by the LAC.  In the
   case of cleartext passwords, use of the AVP H bit is recommended.

   Private Group ID

    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+Private ID len  |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              37               | Private Group ID   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   PrivateGroup ID AVP is used by the LAC to indicate that this call is
   to be associated with a particular customer group.  The Attribute is
   37, Private Group ID, and is marked optional.  The presence of this
   AVP is optional.  The LNS MAY treat the PPP session as well as
   network traffic through this session specially in a manner determined
   by the peer. For example, if the LNS is individually connected to
   several private networks using unregistered addresses, this AVP may
   be included by the LAC to indicate that a given call should be
   associated with one of the private networks.

   The Private Group ID is a string corresponding to a table in the LNS
   that defines the particular characteristics of the selected group.  A
   LAC MAY determine the Private Group ID from a RADIUS response
   containing the PrivateGroupID attribute [13].








Valencia                 expires November 1998                  [Page 64]

INTERNET DRAFT                                                  May 1998


   Rx Connect Speed

    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|        10         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              38               |            BPS (H)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           BPS (L)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Rx Connect Speed BPS AVP encodes the receive speed of the facility
   chosen for the connection attempt.  The Attribute value is 38,
   indicating Rx Connect Speed, and is marked optional.  The Rx Connect
   Speed represents the speed of the connection from the perspective of
   the LAC (e.g. data flowing from the client to the LAC).  Presence of
   this AVP implies that the connection speed may be asymmetric, with
   the transmit connect speed given in the (Tx) Connect Speed AVP.  BPS
   is a 32-bit value indicating the speed in bits/second.

   Sequencing Required

    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|0|0|0|0|0|          6        |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              39               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Sequencing Required AVP indicates to the LNS that Sequence
   Numbers MUST always be present, thus the ability to dynamically drop
   sequencing as described in section 4.2 is not an available option.
   The Attribute value is 38, Sequencing Required, and is marked
   mandatory.  The presence of this AVP is optional.  This AVP MUST NOT
   be present if the Receive Window Size AVP is not present. There is no
   value field.

6.12 Call-Disconnect-Notify (CDN)

   The Call-Disconnect-Notify message is an L2TP control message sent to
   request disconnection of a specific call within the tunnel.  Its
   purpose is to inform the peer of the disconnection and the reason why
   the disconnection occurred.  The peer MUST clean up any resources,
   and does not send back any indication of success or failure for such
   cleanup.










Valencia                 expires November 1998                  [Page 65]

INTERNET DRAFT                                                  May 1998


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          L2TP Control Message Header        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Call-Disconnect-Notify          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Result Code             |
   | Q.931 Cause Code        |
   | Assigned Call ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+

   Call-Disconnect-Notify

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |              14               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Message Type AVP contains a Value of 14, indicating Call-
   Disconnect-Notify.  The Call-Disconnect-Notify message encodes a
   disconnect indication for a specific call within the tunnel.  The
   flags indicate a mandatory option.

   Result Code

       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|0|0|0|0|0| 10 + Message len  |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               1               |          Result Code          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Error Code          |      Optional Message ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Result Code AVP within a Call-Disconnect-Notify message
      indicates the reason for the call disconnect.  It is encoded as
      Attribute 1, indicating a Result Code AVP.  This AVP is mandatory
      and MUST be present.  The Result Code is a 16-bit word.  The 16-
      bit word following the Result Code field contains the Error Code
      value.  The Result Code value indicates whether the Error Code
      value is meaningful or not.  If Error Code is not meaningful it
      MUST be set to 0.  An optional error message can follow the Error
      Code field; its presence and length is indicated by the value of
      the AVP length field.  Defined Result Code values are:

         1 - Call disconnected due to loss of carrier
         2 - Call disconnected for the reason indicated in Error Code.
         3 - Call disconnected for administrative reasons
         4 - Call failed due to no appropriate facilities being
            available (temporary condition)
         5 - Call failed due to no appropriate facilities being



Valencia                 expires November 1998                  [Page 66]

INTERNET DRAFT                                                  May 1998


            available (permanent condition)
         6 - Invalid destination
         7 - Call failed due to no carrier detected
         8 - Call failed due to detection of a busy signal
         9 - Call failed due to lack of a dial tone
         10 - Call was not established within time allotted by LAC
         11 - Call was connected but no appropriate framing was detected

   Q.931 Cause Code

    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|0|0|0|0|0| 9+Advisory Msg len|              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              12               |          Cause Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Cause Msg   |Advisory Msg...|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Q.931 Cause Code AVP is used to give additional information in
   case of unsolicited call disconnection.  The Attribute value is 12,
   Cause Code, and is marked mandatory.  The presence of this AVP is
   optional.  The Cause Code AVP is used to give additional information
   about the reason for disconnecting.  It is only relevant when the LAC
   is using Q.931/DSS1 for the call.  Cause Code is the returned Q.931
   Cause code and Cause Msg is the returned Q.931 message code (e.g.,
   DISCONNECT) associated with the Cause Code.  Both values are returned
   in their native ITU encodings [16].  An additional ASCII text
   Advisory Message may also be included (presence indicated by the AVP
   length) to further explain the reason for disconnecting.

   Assigned Call ID

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              14               |            Call ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Assigned Call ID which was provided to the peer, included in the
   Call-Disconnect-Notify message.  This permits a connection to be
   terminated even before the peer has provided its own Assigned Call ID
   (the Call ID field in the control message header is 0).  The
   Attribute value is 14, Assigned Call ID, and is marked mandatory.
   This AVP MUST be present.

6.13 WAN-Error-Notify (WEN)

   The WAN-Error-Notify message is an L2TP control message sent by the
   LAC to the LNS to indicate WAN error conditions (conditions that
   occur on the interface supporting PPP).  The counters in this message



Valencia                 expires November 1998                  [Page 67]

INTERNET DRAFT                                                  May 1998


   are cumulative.  This message should only be sent when an error
   occurs, and not more than once every 60 seconds.  The counters are
   reset when a new call is established.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          L2TP Control Message Header        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   WAN-Error-Notify          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Call Errors               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   WAN-Error-Notify

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |              15               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Message Type AVP contains a Value of 15, indicating WAN-Error-
   Notify.  The WAN-Error-Notify message encodes information about line
   and other errors detected on the LAC's physical interface to the
   client. This message is sent by the LAC to the LNS.  The flags
   indicate a mandatory option.

   Call Errors

    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|0|0|0|0|0|        32         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              34               |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           CRC Errors                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Framing Errors                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Hardware Overruns                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Buffer Overruns                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Time-out Errors                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Alignment Errors                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Call Errors AVP is used by the LAC to send error information to
   the LNS.  The Attribute value is 34, WAN-Error-Notify, and is marked
   mandatory.  This AVP MUST be present.  The value contains the
   following fields:



Valencia                 expires November 1998                  [Page 68]

INTERNET DRAFT                                                  May 1998


      Reserved - Not used, MUST be 0
      CRC Errors - Number of PPP frames received with CRC errors since
         session was established
      Framing Errors - Number of improperly framed PPP packets received
      Hardware Overruns - Number of receive buffer over-runs since
         session was established
      Buffer Overruns - Number of buffer over-runs detected since
         session was established
      Time-out Errors - Number of time-outs since call was established
      Alignment Errors - Number of alignment errors since call was
         established

6.14 Set-Link-Info (SLI)

   The Set-Link-Info message is an L2TP control message sent by the LNS
   to the LAC to set PPP-negotiated options.  Because these options can
   change at any time during the life of the call, the LAC MUST be able
   to update its internal call information dynamically and update its
   behavior on an active PPP session.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          L2TP Control Message Header        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Set-Link-Info             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ACCM                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+

   Set-Link-Info

    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|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |              16               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Message Type AVP contains a Value of 16, indicating Set-Link-
   Info.  The Set-Link-Info message encodes ACCM information sent from
   the LNS to the LAC after it is negotiated in LCP.  The flags indicate
   a mandatory option.















Valencia                 expires November 1998                  [Page 69]

INTERNET DRAFT                                                  May 1998


   ACCM

    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|0|0|0|0|0|        16         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              35               |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Send ACCM                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Receive ACCM                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The ACCM AVP is used by the LNS to inform LAC of the ACCM to the LNS.
   The Attribute value is 35, ACCM, and is marked mandatory.  This
   attribute MUST be present.  The value contains Send ACCM and Receive
   ACCM fields.  The send ACCM value should be used by the LAC to
   process packets it is sends on the connection.  The receive ACCM
   value should be used by the LAC to process incoming packets on the
   connection.  The default values used by the LAC for both these fields
   are 0xFFFFFFFF.  The LAC should honor these fields unless it has
   specific configuration information to indicate that the requested
   mask must be modified to permit operation.

7.0 Control Connection State Machines

The control messages defined in section 6 are exchanged by way of state
tables defined in this section.  Tables are defined for incoming call
placement, outgoing call placement, as well as for initiation of the
tunnel itself.  The state tables do not encode timeout and
retransmission behavior, as this is handled in the underlying semantics
defined in 6.0.2.

7.1 Control Connection Protocol Operation

   This section describes the operation of various L2TP control
   connection functions and the Control Connection messages which are
   used to support them.

   Receipt of an invalid or malformed Control Connection message should
   be logged appropriately, and the control connection should be closed
   and restarted to ensure recovery into a known state.

   In several cases in the following tables, a protocol message is sent,
   and then a "clean up" occurs.  Note that regardless of the initiator
   of the tunnel destruction, the reliable delivery mechanism must be
   allowed to run (see 6.0.2) before destroying the tunnel.  This
   permits the tunnel management messages to be reliably delivered to
   the peer.







Valencia                 expires November 1998                  [Page 70]

INTERNET DRAFT                                                  May 1998


7.2 Control Connection States

   Control messages are carried over the same media as the payload
   messages which are carried following successful connection
   establishment.  The L2TP control connection protocol is not
   distinguishable between the LNS and LAC, but is distinguishable
   between the originator and receiver.  The originating peer is the one
   which first initiates establishment of the tunnel (in a tie breaker
   situation, this is the winner of the tie).  Since either LAC or LNS
   can be the originator, a collision can occur.  See Section 6.0.1 for
   a description of this and its resolution.

7.2.1 Control Connection Establishment

   State           Event             Action               New State
   -----           -----             ------               ---------
   idle            Local             Send SCCRQ           wait-ctl-reply
                   Open request

   idle            Receive SCCRQ,    Send SCCRP           wait-ctl-conn
                   acceptable

   idle            Receive SCCRQ,    Send StopCCN,        idle
                   not acceptable    Clean up

   wait-ctl-reply  Receive SCCRP,    Send SCCCN,          established
                   acceptable        Send tunnel-open
                                     event to waiting
                                     sessions

   wait-ctl-reply  Receive SCCRP,    Send StopCCN,        idle
                   not acceptable    Clean up

   wait-ctl-reply  Receive SCCRQ,    Clean up,            idle
                   lose tie-breaker  Re-queue SCCRQ
                                     for idle state

   wait-ctl-conn   Receive SCCCN,    Send tunnel-open     established
                   acceptable        event to waiting
                                     sessions

   wait-ctl-conn   Receive SCCCN,    Send StopCCN,        idle
                   not acceptable    Clean up

   established     Local             Send tunnel-open     established
                   Open request      event to waiting
                   (new client)      sessions

   established     Admin             Send StopCCN         idle
                   Tunnel Close      Clean up

   wait-ctl-reply,
   wait-ctl-conn,
   established     Receive StopCCN   Clean up             idle



Valencia                 expires November 1998                  [Page 71]

INTERNET DRAFT                                                  May 1998


   idle
      Both initiator and recipient start from this state.  An initiator
      transmits a SCCRQ, while a recipient remains in the idle state
      until receiving a SCCRQ.

   wait-ctl-reply
      The originator checks to see if another connection has been
      requested from the same peer, and if so, handles the collision
      situation described in Section 6.0.1.

      When a SCCRP is received, it is examined for a compatible version.
      If the version of the reply is lower than the version sent in the
      request, the older (lower) version should be used provided it is
      supported.  If the version in the reply is earlier and supported,
      the originator moves to the established state.  If the version is
      earlier and not supported, a StopCCN MUST be sent to the peer and
      the originator cleans up and terminates the tunnel.

   wait-ctl-conn
      This is where an SCCCN is awaited; upon receipt, the challenge
      response is checked.  The tunnel is either established, or is torn
      down if an authorization failure is detected.

   established
      An established connection may be terminated by either a local
      condition or the receipt of a Stop-Control-Connection-
      Notification.  In the event of a local termination, the originator
      MUST send a Stop-Control-Connection-Notification and clean up the
      tunnel.

      If the originator receives a Stop-Control-Connection-Notification
      it MUST also clean up the tunnel.

7.3 Timing considerations

   Because of the real-time nature of telephone signaling, both the LNS
   and LAC should be implemented with multi-threaded architectures such
   that messages related to multiple calls are not serialized and
   blocked.  The call and connection state figures do not specify
   exceptions caused by timers.  These are addressed in Section 6.0.2.

7.4 Incoming calls

   An Incoming-Call-Request message is generated by the LAC when an
   associated telephone line rings.  The LAC selects a Call ID and
   serial number and indicates the call bearer type.  Modems should
   always indicate analog call type.  ISDN calls should indicate digital
   when unrestricted digital service or rate adaption is used and analog
   if digital modems are involved.  CLID, DNIS, and subaddress may be
   included in the message if they are available from the telephone
   network.

   Once the LAC sends the Incoming-Call-Request, it waits for a response
   from the LNS but it does not necessarily answer the call from the



Valencia                 expires November 1998                  [Page 72]

INTERNET DRAFT                                                  May 1998


   telephone network yet.  The LNS may choose not to accept the call if:

      -  No resources are available to handle more sessions
      -  The dialed, dialing, or subaddress fields do not correspond to
         an authorized user
      -  The bearer service is not authorized or supported

   If the LNS chooses to accept the call, it responds with an Incoming-
   Call-Reply which may also indicate window sizes (see Appendix B).
   When the LAC receives the Incoming-Call-Reply, it attempts to connect
   the call.  A final call connected message from the LAC to the LNS
   indicates that the call states for both the LAC and the LNS should
   enter the established state.  If the call terminated before the LNS
   could accept it, a Call-Disconnect-Notify is sent by the LAC to
   indicate this condition.

   When the dialed-in client hangs up, the call is cleared normally and
   the LAC sends a Call-Disconnect-Notify message.  If the LNS wishes to
   clear a call, it sends a Call-Disconnect-Notify message and cleans up
   its session.

7.4.1 LAC Incoming Call States

   State           Event              Action            New State
   -----           -----              ------            ---------
   idle            Bearer Ring or     Initiate local    wait-tunnel
                   Ready to indicate  tunnel open
                   incoming conn.

   wait-tunnel     tunnel-open        Send ICRQ         wait-reply

   wait-reply      Receive ICRP,      Answer call,      established
                   acceptable         Send ICCN

   wait-reply      Receive ICRP,      Send CDN,         idle
                   not acceptable     Clean up

   wait-reply      Receive CDN        Clean up          idle

   wait-reply      Local              Send CDN,         idle
                   Close request      Clean up

   established     Receive CDN        Hang up bearer,   idle
                                      Clean up

   established     Local              Hang up bearer,   idle
                   Close request      Send CDN,
                                      Clean up

   established     Bearer             Send CDN,         idle
                   Line drop          Clean up

   The states associated with the LAC for incoming calls are:




Valencia                 expires November 1998                  [Page 73]

INTERNET DRAFT                                                  May 1998


   idle
      The LAC detects an incoming call on one of its interfaces.
      Typically this means an analog line is ringing or an ISDN TE has
      detected an incoming Q.931 SETUP message.  The LAC initiates its
      tunnel establishment state machine, and moves to a state waiting
      for confirmation of the existence of a tunnel.

   wait-tunnel
      In this state the session is waiting for either the control tunnel
      to be opened or for verification that the tunnel is already open.
      Once an indication that the tunnel has/was opened, session control
      messages may be exchanged.  The first of these is the Incoming-
      Call-Request.

   wait-reply
   Incoming-Call-Reply message indicating
      The LAC receives either a CDN message indicating non-willingness
      to accept the call (general error or don't accept) and moves back
      into the idle state, or an Incoming-Call-Reply message indicating
      the call is accepted, the LAC sends an Incoming-Call-Connected
      message and enters the established state.

   established
      Data is exchanged over the tunnel.  The call may be cleared
      following:
         An event on the connected interface.  The LAC sends a Call-
            Disconnect-Notify message
         Receipt of a Call-disconnect-Notify message.  The LAC cleans
            up, disconnecting the call.
         A local reason.  The LAC sends a Call-Disconnect-Notify
            message.


7.4.2 LNS Incoming Call States

   State           Event              Action            New State
   -----           -----              ------            ---------
   idle            Receive ICRQ,      Send ICRP         wait-connect
                   acceptable

   idle            Receive ICRQ,       Send CDN,         idle
                   not acceptable     Clean up

   wait-connect    Receive ICCN       Prepare for       established
                   acceptable         data

   wait-connect    Receive ICCN       Send CDN,         idle
                   not acceptable     Clean up

   wait-connect,
   established     Receive CDN        Clean up          idle

   established     Local              Send CDN,         idle
                   Close request      Clean up



Valencia                 expires November 1998                  [Page 74]

INTERNET DRAFT                                                  May 1998


   The states associated with the LNS for incoming calls are:

   idle
      An Incoming-Call-Request message is received.  If the request is
      not acceptable, a Call-Disconnect-Notify is sent back to the LAC
      and the LNS remains in the idle state.  If the Incoming-Call-
      Request message is acceptable, an Incoming-Call-Reply is sent.
      The session moves to the wait-connect state.

   wait-connect
      If the session is still connected on the LAC, the LAC sends an
      Incoming-Call-Connected message to the LNS which then moves into
      established state.  The LAC may send a Call-Disconnect-Notify to
      indicate that the incoming caller could not be connected.  This
      could happen, for example, if a telephone user accidentally places
      a standard voice call to an LAC resulting in a handshake failure
      on the called modem.

   established
      The session is terminated either by receipt of a Call-Disconnect-
      Notify message from the LAC or by sending a Call-Disconnect-
      Notify.  Clean up follows on both sides regardless of the
      initiator.

7.5 Outgoing calls

   Outgoing calls are initiated by an LNS and instruct an LAC to place a
   call.  There are three messages for outgoing calls:  Outgoing-Call-
   Request, Outgoing-Call-Reply, and Outgoing-Call-Connected.  The LNS
   sends an Outgoing-Call-Request specifying the dialed party phone
   number and subaddress as well as speed and window parameters.  The
   LAC MUST respond to the Outgoing-Call-Request message with an
   Outgoing-Call-Reply message once the LAC determines that the proper
   facilities exist to place the call and the call is administratively
   authorized.  For example, is this LNS allowed to dial an
   international call?  Once the outbound call is connected, the LAC
   sends an Outgoing-Call-Connected message to the LNS indicating the
   final result of the call attempt:

7.5.1 LAC Outgoing Call States

   State           Event              Action            New State
   -----           -----              ------            ---------
   idle            Receive OCRQ,      Send OCRP,        wait-cs-answer
                   acceptable         Open bearer

   idle            Receive OCRQ,      Send CDN,         idle
                   not acceptable     Clean up

   wait-cs-answer  Bearer answer,     Send OCCN         established
                   framing detected

   wait-cs-answer  Bearer failure     Send CDN,         idle
                                      Clean up



Valencia                 expires November 1998                  [Page 75]

INTERNET DRAFT                                                  May 1998


   wait-cs-answer,
   established     Receive CDN        Hang up bearer,   idle
                                      Clean up

   The states associated with the LAC for outgoing calls are:

   idle
      Received Outgoing-Call-Request.  If this is received in error,
      respond with a Call-Disconnect-Notify.  Otherwise, allocate a
      physical channel and send an Outgoing-Call-Reply.  Place the
      outbound call and move to the wait-cs-answer state.

   wait-cs-answer
      If the call is not completed or a timer expires waiting for the
      call to complete, send a Call-Disconnect-Notify with the
      appropriate error condition set and go to idle state.  If a
      circuit switched connection is established and framing is
      detected, send an Outgoing-Call-Connected indicating success and
      go to established state.

   established
      If a Call-Disconnect-Notify is received by the LAC, the telco call
      MUST be released via appropriate mechanisms and the session
      cleaned up.  If the call is disconnected by the client or the
      called interface, a Call-Disconnect-Notify message MUST be sent to
      the LNS.  The sender of the Call-Disconnect-Notify message returns
      to the idle state after sending of the message is complete.

7.5.2 LNS Outgoing Call States

   State           Event              Action            New State
   -----           -----              ------            ---------
   idle            Local              Initiate local    wait-tunnel
                   Open request       tunnel-open

   wait-tunnel     tunnel-open        Send OCRQ         wait-reply

   wait-reply      Receive OCRP,      none              wait-connect
                   acceptable

   wait-reply      Receive OCRP,      Send CDN          idle
                   not acceptable

   wait-connect    Receive OCCN       none              established

   established,
   wait-connect    Receive CDN        Clean up          idle

   wait-reply,
   wait-connect,
   established     Local              Send CDN          idle
                   Close request

   The states associated with the LNS for outgoing calls are:



Valencia                 expires November 1998                  [Page 76]

INTERNET DRAFT                                                  May 1998


   idle, wait-tunnel
      When an outgoing call is initiated, a tunnel is first created,
      much as the idle and wait-tunnel states for an LAC incoming call.
      Once a tunnel is established, an Outgoing-Call-Request message is
      sent to the LAC and the session moves into the wait-reply state.

   wait-reply
      If a Call-Disconnect-Notify is received, an error occurred, and
      the session is cleaned up and returns to idle.  If an Outgoing-
      Call-Reply is received, the call is in progress and the session
      moves to the wait-connect state.

   wait-connect
      If a Call-Disconnect-Notify is received, the call failed; the
      session is cleaned up and returns to idle.  If an Outgoing-Call-
      Connected is received, the call has succeeded and the session may
      now exchange data.

   established
      If a Call-Disconnect-Notify is received, the call has been
      terminated for the reason indicated in the Result and Cause Codes;
      the session moves back to the idle state.  If the LNS chooses to
      terminate the session, it sends a Call-Disconnect-Notify to the
      LAC and then cleans up and idles its session.

7.6 Tunnel Disconnection

   The disconnection of a tunnel consists of either peer issuing a
   Stop-Control-Connection-Notification.  The sender of this
   Notification should wait a finite period of time for the
   acknowledgment of this message before releasing the control
   information associated with the tunnel. The recipient of this
   Notification should send an acknowledgment of the Notification and
   then release the associated control information.

   When to release a tunnel is an implementation issue and is not
   specified in this document.  A particular implementation may use
   whatever policy is appropriate for determining when to release a
   control connection.  Some implementations may leave a tunnel open for
   a period of time or perhaps indefinitely after the last user session
   for that tunnel is cleared.  Others may choose to disconnect the
   tunnel immediately after the last user connection on the tunnel
   disconnects.

8.0 L2TP Over Specific Media

   L2TP tries to be self-describing, operating at a level above the
   particular media over which it is carried.  However, some details of
   its connection to media are required to permit interoperable
   implementations.  The following sections describe details needed to
   permit interoperability over specific media.






Valencia                 expires November 1998                  [Page 77]

INTERNET DRAFT                                                  May 1998


8.1 IP/UDP

   L2TP uses the well-known UDP port 1701 [3].  The entire L2TP packet,
   including payload and L2TP header, is sent within a UDP datagram.
   The initiator of an L2TP tunnel picks an available source UDP port,
   and sends to the desired destination at port 1701.  The recipient
   picks a free port on its own system (which may or may not be 1701),
   and sends its reply to the initiator's UDP port, setting its own UDP
   source port set to the free port it found.

   It is legal for a peer's IP address and/or UDP port used for a given
   tunnel to change over the life of a connection; this may correspond
   to a peer with multiple IP interfaces responding to a network
   topology change.  Responses should reflect the last source IP address
   and UDP port for that Tunnel ID.

   IP fragmentation may occur as the L2TP packet travels over the IP
   substrate.  L2TP makes no special efforts to optimize this.  A LAC
   implementation MAY cause its LCP to negotiate for a specific MRU,
   which could optimize for LAC environments in which the MTU's of the
   path over which the L2TP packets are likely to travel have a
   consistent value.

   The default for any L2TP implementation is that UDP checksums MUST be
   enabled for both control and payload messages.  An L2TP
   implementation MAY provide an option to disable UDP checksums for
   payload packets.  It is recommended that UDP checksums always be
   enabled on control packets.

   Port 1701 is used for both L2F [5] and L2TP packets.  The two types
   of packets may be detected by their headers; L2TP has a Vers field of
   2, L2F has a Vers field of 1.  An L2TP implementation running on a
   system which does not support L2F MUST silently discard all packets
   whose Vers field is set to 1.

   To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP media
   has the characteristics of being able to reorder or silently drop
   packets.  The former may break non-IP protocols being carried by PPP,
   especially LAN-centric ones such as bridging.  The latter may break
   protocols which assume per-packet indication of error, such as TCP
   header compression.  The former may be handled by using L2TP payload
   sequence numbers if any PPP protocol is used which cannot tolerate
   reordering.

   The latter characteristic of silently dropping packets is perhaps
   more problematic.  If RFC 1663 reliable delivery [10] is enabled, no
   upper PPP protocol will encounter lost packets.  If L2TP sequence
   numbers are enabled, L2TP can detect the packet loss.  In the case of
   an LNS, the PPP and L2TP stacks are both present within the LNS, and
   packet loss signaling may occur precisely as if a packet was received
   with a CRC error.  Where the LAC and PPP stack are co-resident, this
   technique also applies.  Where the LAC and PPP client are physically
   distinct, the analogous signaling MAY be accomplished by sending a
   packet with a CRC error to the PPP client.  Note that this would



Valencia                 expires November 1998                  [Page 78]

INTERNET DRAFT                                                  May 1998


   greatly increase the complexity of debugging client line problems,
   since the client statistics can not distinguish between true media
   errors and LAC-initiated ones.  This technique is also not possible
   on all hardware.

   If neither RFC 1663 nor sequence numbers are enabled, each lost
   packet results in a 1 in 2**16 chance of a TCP segment being
   forwarded with incorrect contents [11].  Where the combination of the
   packet loss rate with this statistical exposure is unacceptable, TCP
   header compression SHOULD NOT be used in this configuration.

   In general, it is wise to remember that the L2TP/UDP/IP transport is
   an unreliable transport. As with any PPP media which is subject to
   loss, care should be taken when using protocols which are
   particularly sensitive this. Such protocols might include stateful
   compression or encryption protocols.

8.2 IP

   When operating in IP environments, L2TP MUST offer the UDP
   encapsulation described in 8.1 as its default configuration for IP
   operation.  Other configurations (perhaps corresponding to a
   compressed header format) may be defined, and made available as a
   configurable option.

9.0 Security Considerations

   L2TP encounters several security issues in its operation.  The
   general approach of L2TP to these issues is documented here.

   9.1 Tunnel Endpoint Security

      The tunnel endpoints may authenticate each other during tunnel
      establishment.  This authentication has the same security
      attributes as CHAP, and has reasonable protection against replay
      and snooping during the tunnel establishment process. This
      mechanism is not designed to provide any authentication beyond
      tunnel establishment; it is fairly simple for a malicious user who
      can snoop and inject packets to hijack a tunnel once an
      authenticated tunnel establishment has been completed
      successfully.  In environments where some L2TP peers will be
      authenticated, but others not, a mechanism should be provided to
      control when tunnel endpoint authentication will be active.

      The LAC and LNS MUST share a single secret for authentication of
      both ends of the tunnel. Each side uses this same secret when
      acting as authenticatee as well as authenticator.  Since a single
      secret it used, the tunnel authentication AVPs include
      differentiating values in the CHAP ID fields for each message
      digest calculation to guard against replay attacks.

      For L2TP tunnels over IP, IPSEC [17] provides very strong
      protection of the tunnel.  This requires no modification to the
      L2TP protocol, and leverages extensive IETF work in this area.



Valencia                 expires November 1998                  [Page 79]

INTERNET DRAFT                                                  May 1998


      For L2TP tunnels over Frame Relay or other switched networks,
      current practice indicates that these media are much less likely
      to experience attacks of in-transit data.  If these attacks become
      prevalent, either the media or the L2TP packets would have to be
      encrypted or authenticated.

      Because the shared secret used for endpoint authentication is the
      same shared secret used to obscure AVP contents using the H
      (Hidden) bit, tunnel authentication must be used in all cases
      where the H bit will be used.  Proxy authentication involving PAP
      may be usable without the H bit if PAP is only carrying one-time
      passwords; if clear text passwords are carried in the proxy
      authentication, the H bit (and, by implication, tunnel
      authentication) should be used.

      To protect against exhaustive attack during tunnel authentication,
      no tunnel authentication response should ever be accepted if it
      corresponds to a challenge more than one minute old.

   9.2 Client Security

      A more systematic method of protection in tunneled PPP
      environments may be achieved through client security.  PPP layer
      encryption would provide end-to-end security for both direct
      dial-in clients as well as PPP clients carried within a tunnel.
      With this level of client security, sessions are protected against
      attacks against the carrying tunnel, as well as attacks on the LAC
      itself.  Because both encryption and compression can occur at the
      PPP layer, the two can be coordinated, permitting compression to
      precede encryption.

   9.3 Proxy Authentication

      The optional proxy CHAP function of L2TP can permit an entirely
      transparent PPP tunnel, with a single LCP and CHAP sequence being
      seen by the client.  For cases where the LAC and the entire path
      to the LNS are operated by a single entity, this function may
      provide acceptable security.  For cases where LNS-initiated
      authentication is required, proxy CHAP still permits an initial
      access decision to be made before accepting the tunnel, permitting
      the LNS in most cases to reject tunnel initiations rather than
      accept them and later disconnect.

      The optional proxy PAP may result in the cleartext password
      traversing the tunnel.  Where PAP is being used in conjunction
      with static passwords, this may pose a significant security issue.
      Where PAP is only used to transport one-time passwords, such
      issues may be greatly mitigated.  The H bit of the carrying AVP
      may be used to protect against this.

      All implementations MUST accept proxy authentication AVP's, but
      are free to silently discard them and initiate an entirely new
      authentication with the PPP client.




Valencia                 expires November 1998                  [Page 80]

INTERNET DRAFT                                                  May 1998


10.0 Acknowledgments

   The AVP construct comes from Glen Zorn, who thought up the framework
   for permitting multiple vendors to contribute to a common attribute
   space in a relatively orderly fashion.

   Dory Leifer of Ascend Communications made valuable refinements to the
   protocol definition of L2TP and contributed to the editing of this
   document.

   Steve Cobb and Evan Caves redesigned the state machine tables.

   Barney Wolff provided a great deal of design input on the endpoint
   authentication mechanism.

11.0 Contacts

   Kory Hamzeh, Allan Rubens
   Ascend Communications
   1275 Harbor Bay Parkway
   Alameda, CA 94502
   kory@ascend.com
   acr@del.com

   Tim Kolar, Morgan Littlewood, Andrew J. Valencia
   Cisco Systems
   170 West Tasman Drive
   San Jose CA 95134-1706
   tkolar@cisco.com
   littlewo@cisco.com
   vandys@cisco.com

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

   Gurdeep Singh Pall
   Microsoft Corporation
   Redmond, WA
   gurdeep@microsoft.com

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

   Jeff Taarud
   Copper Mountain Networks, Inc.
   3931 Sorrento Valley Blvd.
   San Diego, CA 92121



Valencia                 expires November 1998                  [Page 81]

INTERNET DRAFT                                                  May 1998


   jtaarud@coppermountain.com

   William Verthein
   3COM Corporation
   william_verthein@3com.com

12.0 References


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

    [2] A. Valencia, M. Littlewood, T. Kolar, "Layer 2 Forwarding",
        ``work in progress'', April 1996

    [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little,
        "Point-to-Point Tunneling Protocol",``work in progress'',
        June 1996

    [4] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC 1034,
        November 1987

    [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
        USC/Information Sciences Institute, July 1992.

    [6] Sally Floyd, Van Jacobson, "Random Early Detection Gateways for
        Congestion Avoidance", IEEE/ACM Transactions on Networking,
        August 1993

    [7] D. Carrel, L. Grant, "The TACACS+ Protocol", draft-grant-tacacs-00.txt,
        October 1996

    [8] C. Rigney, A. Rubens, W. A. Simpson, S. Willens,  "Remote
        Authentication Dial In User Service (RADIUS)." RFC 2058,
        January 1997.

    [9] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, RFC 1990,
        "The PPP Multilink Protocol (MP)", August 1996.

   [10] D. Rand, "PPP Reliable Transmission", RFC 1663, July, 1994

   [11] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial Links",
        RFC 1144, February, 1990

   [12] "SMI Network Management Private Enterprise Codes",
        ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers

   [13] G. Zorn, D. Leifer, A. Rubens, J. Shriver, "RADIUS Attributes for
        Tunnel Protocol Support," draft-ietf-radius-tunnel-auth-04.txt,
        November 1997

   [14] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, 07/1994

   [15] Bradner, S, "Key words for use in RFCs to Indicate Requirement



Valencia                 expires November 1998                  [Page 82]

INTERNET DRAFT                                                  May 1998


        Levels", RFC 2119, March 1997.

   [16] ITU-T Recommendation "Digital subscriber Signaling System No. 1
        (DSS 1) - ISDN user-network interface layer 3 specification for
        basic call control", Rec. Q.931(I.451), March 1993.

   [17] S. Kent, R. Atkinson, "Security Architecture for the Internet
        Protocol", ``work in progress'' draft-ietf-ipsec-arch-sec-04.txt,
        March 1998.

   [18] H. Alvestrand, "IETF Policy on Character Sets and Languages",
        RFC 2277, January 1998.

Appendix A: Acknowledgment Timeouts

   L2TP uses sliding windows and timeouts to provide session and control
   flow-control across the underlying medium (which may be an
   internetwork) and to perform efficient data buffering to keep the
   LAC-LNS data channels full without causing receive buffer overflow.
   L2TP requires that a timeout be used to recover from dropped data or
   acknowledgment packets for both control and data messages.  The only
   real difference between the flow-control mechanism used for the two
   message types is that control messages are retransmitted upon
   expiration of the acknowledgment timeout in order to assure reliable
   transport while payload messages are never retransmitted.  Because
   payload messages are not retransmitted, the action taken upon
   expiration of the acknowledgment timeout for each message type also
   differs.

   When the timeout for a control session expires the previously
   transmitted control message with Ns value equal to the highest in-
   sequence value of Nr received from the peer is retransmitted.  The
   receiving peer does not advance its value for the receive sequence
   number state, Sr, for either a control session or payload session
   until it receives a message with Ns equal to its current value of Sr
   (except for the simple receiver described in Appendix C and payload
   packets with the R bit set).  This rule assures that all subsequent
   acknowledgments for this session will contain an Nr value equal to
   the Ns value of the first missing message until a message with the
   missing Ns value is received.  This rule also assures that when a
   payload message is lost anywhere within the current transmit window,
   the payload session acknowledgment timeout will expire, allowing the
   transmitter to adjust transmission parameters such as those suggested
   in this appendix.

   According to the above rule for updating of the receiving peer's Sr
   value, the loss of a transmitted payload message (due to non-
   retransmission of payload messages) will cause Sr to remain at the
   value of the first lost payload message.  In order to cause the
   receiving peer to advance its value of Sr beyond that of a lost
   message's Ns value, upon expiration of a payload session
   acknowledgment timeout, the sending peer MUST transmit a payload
   message with R bit set and Ns value greater than or equal to Ns of
   the lost message.  Refer to Section 4 for more details on the use of



Valencia                 expires November 1998                  [Page 83]

INTERNET DRAFT                                                  May 1998


   the R bit.

   The exact implementation of the acknowledgment timeout is vendor-
   specific.  It is suggested that an adaptive timeout be implemented
   with backoff for flow control.  The timeout mechanism proposed here
   has the following properties:

      Independent timeouts for each session.  A device (LAC or LNS) will
      have to maintain and calculate timeouts for every active session.

      An administrator-adjustable maximum timeout, MaxTimeOut, unique to
      each device.

      An adaptive timeout mechanism that compensates for changing
      throughput.  To reduce packet processing overhead, vendors may
      choose not to recompute the adaptive timeout for every received
      acknowledgment.  The result of this overhead reduction is that the
      timeout will not respond as quickly to rapid network changes.

      Timer backoff on timeout to reduce congestion.  The backed-off
      timer value is limited by the configurable maximum timeout value.
      Timer backoff is done every time an acknowledgment timeout occurs.

   In general, this mechanism has the desirable behavior of quickly
   backing off upon a timeout and of slowly decreasing the timeout value
   as packets are delivered without timeouts.

   Some definitions:

      Packet Processing Delay, "PPD", is the amount of time required for
      each peer to process the maximum amount of data buffered in its
      offered receive packet window.  The PPD is the value exchanged
      between the LAC and LNS when a call is established.  For the LNS,
      this number should be small.  For an LAC supporting modem
      connections, this number could be significant.

      "Sample" is the actual amount of time incurred receiving an
      acknowledgment for a packet.  The Sample is measured, not
      calculated.

      Round-Trip Time, "RTT", is the estimated round-trip time for an
      Acknowledgment to be received for a given transmitted packet.
      When the network link is a local network, this delay will be
      minimal (if not zero).  When the network link is the Internet,
      this delay could be substantial and vary widely.  RTT is adaptive:
      it will adjust to include the PPD and whatever shifting network
      delays contribute to the time between a packet being transmitted
      and receiving its acknowledgment.

      Adaptive Timeout, "ATO", is the time that must elapse before an
      acknowledgment is considered lost.  After a timeout, the sliding
      window is partially closed and the ATO is backed off.

Packet Processing Delay (PPD)



Valencia                 expires November 1998                  [Page 84]

INTERNET DRAFT                                                  May 1998


   The PPD parameter is a 16-bit time value exchanged during the Call
   Control phase expressed in units of tenths of a second (64 means 6.4
   seconds).  The protocol only specifies that the parameter is
   exchanged, it does not specify how it is calculated.  The way values
   for ATO are calculated is implementation-dependent and need not be
   variable (static timeouts are allowed).  If adaptive timeouts are to
   be used then the PPD should be exchanged in the call connect
   sequences.  A possible way to calculate the PPD is:

   PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
           + LACFudge  (for an LAC)
   or
   PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate
           + LNSFudge  (for an LNS)

   Header is the total size of the L2TP and media dependent headers.
   MTU is the overall MTU for the link between the LAC and LNS.
   WindowSize represents the number of packets in the sliding window,
   and is implementation-dependent.  The latency of the underlying
   connection path between the LAC and LNS could be used to pick a
   window size sufficient to keep the current session's pipe full.  The
   constant 8 converts octets to bits (assuming ConnectRate is in bits
   per second).  LACFudge and LNSFudge are not required but can be used
   to take overall processing overhead of the LAC or LNS into account.

   In the case of the computed PPD for an LNS, AvePathRate is the
   average bit rate of the path between the LNS and LAC.  Given that
   this number is probably very large and WindowSize is relatively
   small, LNSFudge will be the dominant factor in the computation of
   PPD.  It is recommended that the minimum value of PPD be on the order
   of 0.5 second.

   The value of PPD is used to seed the adaptive algorithm with the
   initial RTT[n-1] value.

A.1 Calculating Adaptive Acknowledgment Timeout

   We still must decide how much time to allow for acknowledgments to
   return.  If the timeout is set too high, we may wait an unnecessarily
   long time for dropped packets.  If the timeout is too short, we may
   time out just before the acknowledgment arrives.  The acknowledgment
   timeout should also be reasonable and responsive to changing network
   conditions.

   The suggested adaptive algorithm detailed below is based on the TCP
   1989 implementation and is explained in Richard Steven's book TCP/IP
   Illustrated, Volume 1 (page 300).  'n' means this iteration of the
   calculation, and 'n-1' refers to values from the last calculation.

            DIFF[n] = SAMPLE[n] - RTT[n-1]
            DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1]))
            RTT[n] = RTT[n-1] + (alpha * DIFF[n])
            ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)




Valencia                 expires November 1998                  [Page 85]

INTERNET DRAFT                                                  May 1998


      DIFF represents the error between the last estimated round-trip
      time and the measured time.  DIFF is calculated on each iteration.

      DEV is the estimated mean deviation.  This approximates the
      standard deviation.  DEV is calculated on each iteration and
      stored for use in the next iteration.  Initially, it is set to 0.

      RTT is the estimated round-trip time of an average packet.  RTT is
      calculated on each iteration and stored for use in the next
      iteration.  Initially, it is set to PPD.

      ATO is the adaptive timeout for the next transmitted packet.  ATO
      is calculated on each iteration.  Its value is limited, by the MIN
      function, to be a maximum of the configured MaxTimeOut value.

      Alpha is the gain for the round trip estimate error and is
      typically 1/8 (0.125).

      Beta is the gain for the deviation and is typically 1/4 (0.250).

      Chi is the gain for the timeout and is typically set to 4.

   To eliminate division operations for fractional gain elements, the
   entire set of equations can be scaled.  With the suggested gain
   constants, they should be scaled by 8 to eliminate all division.  To
   simplify calculations, all gain values are kept to powers of two so
   that shift operations can be used in place of multiplication or
   division.  The above calculations are carried out each time an
   acknowledgment is received for a packet that was not retransmitted
   (no timeout occurs).

A.2 Flow Control: Adjusting for Timeout

   This section describes how the calculation of ATO is modified in the
   case where a timeout does occur.  When a timeout occurs, the timeout
   value should be adjusted rapidly upward.  Although L2TP payload
   packets are not retransmitted when a timeout occurs, the timeout
   should be adjusted up toward a maximum limit.  To compensate for
   shifting internetwork time delays, a strategy must be employed to
   increase the timeout when it expires.  A simple formula called Karn's
   Algorithm is used in TCP implementations and may be used in
   implementing the backoff timers for the LNS or the LAC.  Notice that
   in addition to increasing the timeout, we also shrink the size of the
   window as described in the next section.

   Karn's timer backoff algorithm, as used in TCP, is:

      NewTIMEOUT = delta * TIMEOUT

   Adapted to our timeout calculations, for an interval in which a
   timeout occurs, the new timeout interval ATO is calculated as:

            RTT[n] = delta * RTT[n-1]
            DEV[n] = DEV[n-1]



Valencia                 expires November 1998                  [Page 86]

INTERNET DRAFT                                                  May 1998


            ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)

   In this modified calculation of ATO, only the two values that
   contribute to ATO and that are stored for the next iteration are
   calculated.  RTT is scaled by delta, and DEV is unmodified.  DIFF is
   not carried forward and is not used in this scenario.  A value of 2
   for Delta, the timeout gain factor for RTT, is suggested.

Appendix B:  Acknowledgment Timeout and Window Adjustment

B.1 Initial Window Size

   Although each side has indicated the maximum size of its receive
   window, it is recommended that a slow start method be used to begin
   transmitting data.  The initial maximum window size on the
   transmitter is set to half the maximum size the receiver requested,
   with a minimum size of one packet.  The transmitter stops sending
   packets when the number of packets awaiting acknowledgment is equal
   to the current maximum window size.  As the receiver successfully
   digests each window, the maximum window size on the transmitter is
   bumped up by one packet until the maximum specified by the receiver
   is reached.  This method prevents a system from flooding an already
   congested network because no history has been established.

   When for any reason an LAC or LNS receives more data than it can
   queue for the tunnel, a packet must be discarded.  In this case, it
   is recommended that a "random early discard" algorithm [6] be used
   rather than the obvious "drop last" algorithm.

B.2 Closing the Window

   When a timeout does occur on a packet, the sender adjusts the size of
   the transmit window down to one half its maximum value when it
   failed.  Fractions are rounded up, and the minimum window size is
   one.

B.3 Opening the Window

   With every successful transmission of a window's worth of packets
   without a timeout, the maximum transmit window size is increased by
   one packet until it reaches the maximum window size that was sent by
   its peer when the call was connected.  As stated earlier, no
   retransmission is done on a timeout.  After a timeout, transmission
   resumes with the maximum transmit window starting at one half the
   size of the maximum transmit window when the timeout occurred (with a
   minimum window size of 1) and adjusting upward by one each time the
   current maximum transmit window is filled with packets that are all
   acknowledged without timeouts.

B.4 Window Overflow

   When a receiver's window overflows with too many incoming packets,
   excess packets are thrown away.  This situation should not arise if
   the sliding window procedures are being properly followed by the



Valencia                 expires November 1998                  [Page 87]

INTERNET DRAFT                                                  May 1998


   transmitter and receiver.  It is assumed that, on the transmit side,
   packets are buffered for transmission and are no longer accepted from
   the packet source when the transmit buffer fills.

Appendix C: Handling of out-of-order packets

   When the Sequence Number and Acknowledgment Number fields are present
   in payload packets, they are used to manage packet rate.  In
   addition, they may be used to handle out-of-order arrival of packets.
   A simple L2TP receiver may choose to skip the test for the Ns value
   of a received message being equal to Sr, simply updating Sr if Ns is
   greater than the current value of Sr.  For example, if packets 1, 2,
   3 arrived as 1, 3, 2, this simple implementation would silently
   discard packet 2 without informing the sender in any way that packet
   2 was discarded.  Even though packet 2 is dropped by the receiver,
   the transmitter will perceive all transmitted packets as being
   received without loss by its peer.

   Such behavior does not affect the L2TP protocol itself, but
   significantly improved throughput in such environments may be
   attained by queuing and reordering packets when they arrive out of
   order.  The number of packets to be queued is a function of memory
   resources on the L2TP implementation, but should never be more than
   1/4 of the total sequence number space (i.e., 16384 packets), to
   avoid the possibility of sequence number aliasing.

   It is suggested that receiving peer implementations implement the Sr
   state variable for payload sessions and that they update Sr only when
   receiving the next in-sequence Ns value or when receiving a message
   with the R bit set.  Doing so allows a mechanism for reporting of
   lost payload messages to the transmitter, which is necessary for the
   transmitter to implement algorithms such as those suggested in
   Appendix A and B.

   Note that while payload messages received out-of-order may either be
   queued, discarded, or delivered out-of-order, queuing is preferred.
   PPP does not expect to receive packets out-of-order so, if queuing is
   not provided by a receiver, it is preferable for it to discard out-
   of-order packets rather than deliver them to PPP.

Appendix D: Transport Layer Adaptive Timeouts and Window Adjustment

   Appendixes A, B, and C deal primarily with operation of the payload
   packet sessions of L2TP.  This Appendix explains how these three
   algorithms pertain to the transport layer for L2TP control sessions.
   Appendix B, Time-out Window Management, directly applies to the
   Transport Layer except in the case where a window size of 1 is being
   used.  Appendix C, does not really apply because, for the Control
   Session, control messages MUST always be processed by the receiver in
   order.  Also, there are no lost control packets because they are
   retransmitted by the L2TP Transport Layer.  Thus, the main topic of
   this Appendix is how to adapt the example adaptive timeout algorithm
   of Appendix A to the Control Session Transport Layer.




Valencia                 expires November 1998                  [Page 88]

INTERNET DRAFT                                                  May 1998


   There are two main differences between the Control Session and
   payload sessions: 1) Unlike lost payload packets, lost control
   messages are retransmitted and 2) There is no Packet Processing Delay
   value provided in the control session setup messages.  The latter
   affects the manner in which the initial value of the RTT estimate is
   determined.  The former really doesn't affect the algorithm at all,
   except that upon a timeout, retransmission of unacknowledged control
   messages should be attempted, up to the number that fit in the
   sliding window with size computed as in Appendix B.

   Using the symbol definitions of Appendix A, the calculation of the
   value for the PPD of the remote peer can be estimated as:

   PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate
           + Fudge

   This is simply the number of bits in a full control session window
   divided by the average speed of the path between the LAC and LNS with
   a fudge factor added on to make it work.  In cases where the average
   rate of the connection between LAC and LNS isn't known, it is
   suggested that some value be configured that is associated with each
   possible peer.  Because Control Session windows will most likely be
   small and the connection speed will be quite high, fudge will be the
   dominant factor in this calculation.  For this reason, just
   configuring a single fixed initial PPD estimate to be used for all
   possible peers will probably provide adequate results.  This fudge
   factor should be at least 0.5 second.

Appendix E: Examples of L2TP sequence numbering

   Although sequence numbers serve distinct purposes for control and
   data messages, both types of messages use identical techniques for
   assigning sequence numbers.  This appendix shows several common
   scenarios, and illustrates how sequence number state progresses and
   is interpreted.

   E.1: Lock-step tunnel establishment

      In this example, an LAC establishes a tunnel, with the exchange
      involving each side alternating in sending messages.  This example
      is contrived, in that the final acknowledgment in the example is
      explicitly sent within a zero-length message, although most
      typically the acknowledgment would have been included in the
      processing of the Incoming-Call-Request which had prompted the LAC
      to initiate the tunnel in the first place.

            LAC                                           LNS
             ->    Start-Control-Connection-Request
                   Nr: 0, Ns: 0

                        Start-Control-Connection-Reply    <-
                                          Nr: 1, Ns: 0

             ->    Start-Control-Connection-Connected



Valencia                 expires November 1998                  [Page 89]

INTERNET DRAFT                                                  May 1998


                   Nr: 1, Ns: 1

            (delay)

                                         (zero-length)    <-
                                          Nr: 2, Ns: 1

      E.2: Multiple packets acknowledged

      This example shows a flow of payload packets from the LNS to the
      LAC, with the LAC having no traffic of its own.  The LAC is
      waiting 1/4 of its timeout interval, and then acknowledging all
      packets seen since the last interval.

      (previous packet flow precedes this)

            LAC                                           LNS
             ->    (zero-length)
                   Nr: 7000, Ns: 1000
                                             (payload)    <-
                                    Nr: 1000, Ns: 7000
                                             (payload)    <-
                                    Nr: 1000, Ns: 7001
                                             (payload)    <-
                                    Nr: 1000, Ns: 7002

      (LAC's timer indicates it should acknowledge pending traffic)

             ->    (zero-length)
                   Nr: 7003, Ns: 1000

      E.3: Lost packet with retransmission

      An existing tunnel has a new session requested by the LAC.  The
      Incoming-Call-Reply is lost and must be retransmitted by the LNS.
      This example continues from the sequence state reached at the end
      of example E.1.  Note that loss of the -Reply has two impacts: not
      only does it keep the upper level state machine from progressing,
      but it also keeps the LAC from seeing a timely lower level
      acknowledgment of its -Request packet.

            LAC                                           LNS
             ->    Incoming-Call-Request
                   Nr: 1, Ns: 2

                     (packet lost) Incoming-Call-Reply    <-
                                          Nr: 3, Ns: 1

            (pause; LAC's timer started first, so fires first)

             ->    Incoming-Call-Request
                   Nr: 1, Ns: 2

            (LNS realizes it has already seen this packet)



Valencia                 expires November 1998                  [Page 90]

INTERNET DRAFT                                                  May 1998


            (LNS might use this as a cue to retransmit, as in this example)

                                   Incoming-Call-Reply    <-
                                          Nr: 3, Ns: 1
             ->    Incoming-Call-Connected
                   Nr: 2, Ns: 3

            (delay)

                                         (zero-length)    <-
                                          Nr: 4, Ns: 2

      E.4: Lost payload packet with ZLB flow control

      In this example, a packet sent from Peer A to Peer B is lost. Peer
      B's receive window is 4, so after Peer A realizes that it has
      filled Peer B's window, it waits. After timing out, Peer A sends a
      ZLB with the R bit set to reset Peer B, telling it to give up on
      3001. If performing window adjustment, Peer A should now reduce
      its effective transmit window size until a full window is digested
      by Peer B.

            Peer A                             Peer B (RW=4)
             ->    Payload Packet
                   Nr: 7000, Ns: 3000

                                        Payload Packet    <-
                                          Nr: 3001, Ns: 7000

             ->    Payload packet      (packet lost)
                   Nr: 7001, Ns: 3001

                                          Payload Packet  <-
                                          Nr: 3001, Ns: 7001

             ->    Payload packet
                   Nr: 7002, Ns: 3002
             ->    Payload packet
                   Nr: 7002, Ns: 3003
             ->    Payload packet
                   Nr: 7002, Ns: 3004

            (window full, waiting)

             ->    Timeout, send ZLB w/R bit set
                   Nr: 7002 Ns: 3005

                                         Payload Packet  <-
                                         Nr: 3005 Ns: 7002

      Note that the ZLB sent with the R bit set could have been any
      value greater than that of the lost packet, 3001, and the current
      Ss value plus one. Thus, a ZLB with the R bit set to 3002, 3003 or
      3004 instead of 3005 would have had effectively the same result



Valencia                 expires November 1998                  [Page 91]

INTERNET DRAFT                                                  May 1998


      given that peer B received and queued the out of order packets.

      E.5: Lost payload packet with piggyback flow control

      In this example, two packets sent from Peer A to Peer B are lost.
      Peer B's receive window is 4, so after Peer A realizes that it has
      filled Peer B's window, it waits. After timing out, Peer A sends a
      payload packet with the R bit set to reset Peer B, telling it to
      give up on 3001 and 3002. If performing window adjustment, Peer A
      should now reduce its effective transmit window size until a full
      window is digested by Peer B. Note that in this scenario Peer A
      has no way of knowing that more than one packet was lost.

            Peer A                             Peer B (RW=4)
             ->    Payload Packet
                   Nr: 7000, Ns: 3000

                                        Payload Packet    <-
                                          Nr: 3001, Ns: 7000

             ->    Payload packet      (packet lost)
                   Nr: 7001, Ns: 3001
             ->    Payload packet      (packet lost)
                   Nr: 7001, Ns: 3002

                                          Payload Packet  <-
                                          Nr: 3001, Ns: 7001

             ->    Payload packet
                   Nr: 7002, Ns: 3003
             ->    Payload packet
                   Nr: 7002, Ns: 3004

            (window full, waiting)

             ->    Timeout, send Payload w/R bit set
                   Nr: 7002 Ns: 3005

                                         Payload Packet  <-
                                         Nr: 3006 Ns: 7002

Appendix F: Flow Control and Sequencing Negotiation

   This section provides a table of when sequence numbers are expected
   and when flow control is enabled on data packets. Note that this does
   not consider the case of dynamic disabling/enabling of sequencing by
   the LNS (see section 4.2).

   "Peer A" and "Peer B" columns contain the value of the Receive Window
   (RW) sent by the corresponding peer (e.g. if RW=0 appears in the
   "Peer A" column, then Peer A sent a RW of 0 to peer B). "RW>0" refers
   to all possible Receive Window values greater than 0, "no RW" means





Valencia                 expires November 1998                  [Page 92]

INTERNET DRAFT                                                  May 1998


   that the Receive Window AVP was not present in the message sent.


      Peer A   Peer B    Action

      no RW    no RW     Sequence numbers are absent, no flow control

      RW=0     RW=0      Sequence numbers are present, no flow control
      RW=0     no RW     Sequence numbers are present, no flow control
      no RW    RW=0      Sequence numbers are present, no flow control

      RW>0     RW=0      Sequence numbers are present, Peer B flow controls
      RW>0     no RW     packets sent to Peer A

      RW=0     RW>0      Sequence numbers are present, Peer A flow controls
      no RW    RW>0      packets sent to Peer B

      RW>0     RW>0      Sequence numbers are present, Peer A and B flow
                         packets to respective Peer






































Valencia                 expires November 1998                  [Page 93]


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