[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                                             Kory Hamzeh
INTERNET-DRAFT                                      Ascend Communications
Category: Internet Draft                                        Tim Kolar
Title: draft-ietf-pppext-l2tp-01.txt                        Cisco Systems
Date: December 1996                                     Morgan Littlewood
                                                            Cisco Systems
                                                       Gurdeep Singh Pall
                                                    Microsoft Corporation
                                                              Jeff Taarud
                                             formerly of 3COM Corporation
                                                       Andrew J. Valencia
                                                            Cisco Systems
                                                         William Verthein
                                                            U.S. Robotics


                  Layer Two Tunneling Protocol "L2TP"


Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working doc-
   uments of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute work-
   ing 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 ``work-
   ing draft'' or ``work in progress.''

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

Abstract

   Virtual dial-up allows many separate and autonomous protocol domains
   to share common access infrastructure including modems, Access
   Servers, and ISDN routers.  RFC1661 specifies multiprotocol dial-up
   via PPP [1].  This document describes the Layer Two Tunneling Proto-
   col (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 net-
   work provided.

Table of Contents

   1.0 Introduction
   1.1 Conventions
   1.2 Terminology



Valencia                    expires May 1997                     [Page 1]

INTERNET DRAFT                                             December 1996


   2.0 Problem Space Overview
   2.1 Initial Assumptions
   2.2 Topology
   2.3 Providing Virtual Dial-up Services--a walk-through
   3.0 Service Model Issues
   3.1 Security
   3.2 Address Allocation
   3.3 Authentication
   3.4 Accounting
   4.0 Protocol Overview
   4.1 Control Message Overview
   4.2 Payload Packet Overview
   5.0 Message Format and Protocol Extensibility
   5.1 AVP
   5.2 Control Message Format
   5.3 Payload Message Format
   5.4 Control Message Types
   5.5 General Error Codes
   6.0 Control Connection Protocol Specification
   6.1 Start-Control-Connection-Request
   6.2 Start-Control-Connection-Reply
   6.3 Start-Control-Connection-Connected
   6.4 Stop-Control-Connection-Request
   6.5 Stop-Control-Connection-Reply
   6.6 Hello
   6.7 (deleted)
   6.8 Outgoing-Call-Request
   6.9 Outgoing-Call-Reply
   6.10 Outgoing-Call-Connected
   6.11 Incoming-Call-Request
   6.12 Incoming-Call-Reply
   6.13 Incoming-Call-Connected
   6.14 Call-Clear-Request
   6.15 Call-Disconnect-Notify
   6.16 WAN-Error-Notify
   6.17 Set-Link-Info
   7.0 Control Connection State Machines
   7.1 Control Connection Protocol Operation
   7.2 Control Connection States
   7.2.1 Control Connection Originator
   7.2.2 Control connection Receiver
   7.3 Timing considerations
   7.4 Incoming Calls
   7.4.1 LAC Incoming Call States
   7.4.2 LNS Incoming Call States
   7.5 Outgoing calls
   7.5.1 LAC Outgoing Call States
   7.5.2 LNS Outgoing Call States
   8.0 L2TP Over Specific Media
   8.1 IP/UDP
   8.2 IP
   9.0 Security Considerations
   9.1 Tunnel Endpoint Security
   9.2 Client Security



Valencia                    expires May 1997                     [Page 2]

INTERNET DRAFT                                             December 1996


   10.0 Acknowledgments
   11.0 Contacts
   12.0 References
   Appendix A: Acknowledgment Time-Outs
   Appendix B: Acknowledgment Time-Out and Window Adjustment
   Appendix C: Handling of out-of-order packets
   Appendix D: Transport Layer Adaptive Time-Outs and Window Adjustment

1.0 Introduction

   The traditional dial-up network service on the Internet is for regis-
   tered 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 applica-
   tion are support for privately addressed IP, IPX, and AppleTalk dial-
   up via PPP across existing Internet infrastructure.

   The support of these multiprotocol 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 draft to identify the issues encountered in
   integrating multiprotocol 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 per-
   mits the leveraging of existing access protocols.

   This protocol may also be used to solve the "multilink hunt-group
   splitting" problem. Multilink PPP, 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 appear at
   a location other than the physical point at which the session was
   physically received, it can be used to make all channels appear 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 specifi-
   cation in this document:

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

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

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




Valencia                    expires May 1997                     [Page 3]

INTERNET DRAFT                                             December 1996


1.2 Terminology

   Analog Channel

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

   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 end-
      points on a PSTN or ISDN--for example, a telephone call between
      two modems.

   CHAP

      Challenge Authentication Protocol, a PPP cryptographic chal-
      lenge/response authentication protocol in which the cleartext
      password is not passed in the clear 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, LNS pairs, and operate
      in-band within the tunnel protocol.  Control messages govern
      aspects of the tunnel and sessions within the tunnel.

   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.

   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, chal-
      lenge/response, and arbitrary dialog sequences.

   L2TP Access Concentrator (LAC)

      A device attached to one or more PSTN or ISDN lines capable of PPP
      operation and of handling the L2TP protocol.  The LAC needs only



Valencia                    expires May 1997                     [Page 4]

INTERNET DRAFT                                             December 1996


      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.

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

   Network Access Server (NAS)

      A device providing temporary, on-demand network access to users.
      This access is point-to-point using PSTN or ISDN lines.

   PAP

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

   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 a outbound call is initiated.  The datagrams
      related to a session are sent over the tunnel between the LAC and
      LNS.

   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.

   Switched Virtual Circuit (SVC)

      An L2TP-compatible media on top of which L2TP is directly encapsu-
      lated.  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 multi-
      plexed over a single tunnel.  A control connection operating in-
      band over the same tunnel controls the establishment, release, and



Valencia                    expires May 1997                     [Page 5]

INTERNET DRAFT                                             December 1996


      maintenance of sessions and of the tunnel itself.

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 regis-
   tered 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 secu-
   rity facilities that are available to him in a dedicated dial-up con-
   figuration.  In particular, the end user requires:

   +  End System transparency: Neither the remote end system nor his
   home site hosts should require any special software to use this ser-
   vice 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 pur-
   poses) and by the user (for charge-back and auditing).

2.2 Topology

   Shown below is a generic Internet with Public switched Telephone Net-
   work (PSTN) access (i.e., async PPP via modems) and Integrated Ser-
   vices 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.












Valencia                    expires May 1997                     [Page 6]

INTERNET DRAFT                                             December 1996


           ...----[L]----+---[L]-----...
                         |
                         |
                        [H]
                         |
                 ________|________________________
                 |                                |
         ________|__                        ______|________
         |         |                        |             |
         |  PSTN  [R]                      [R]  ISDN      |
         |  Cloud  |                        |   Cloud    [N]__[U]
         |         |             Internet   |             |
         |         |                       [R]            |
         [N]______[R]                       |_____________|
          |      |                                |
          |      |                                |
         [U]     |________________________________|


      [H] = LNS
      [L] = Home LAN(s)
      [R] = Router
      [U] = Remote User
      [N] = ISP Network Access Server


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.

   The remote user initiates a PPP connection to an ISP via either the
   PSTN or ISDN.  The Network Access Server (NAS) accepts the connection
   and the PPP link is established (L2TP also permits the NAS 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 sys-
   tem/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 NAS may tunnel the PPP connec-
   tion 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.



Valencia                    expires May 1997                     [Page 7]

INTERNET DRAFT                                             December 1996


   If no tunnel connection currently exists to the desired LNS, one is
   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 connec-
   tivity.  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 may include a reason indication, which may
   be displayed to the dial-up user, after which the call should be dis-
   connected.

   The initial setup notification may include the authentication infor-
   mation 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 ini-
   tial setup notification may also include a copy of the LCP CONFACKs
   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 any
   link framing or transparency bytes, encapsulated in L2TP, and for-
   warded over the appropriate tunnel.

   The LNS accepts these frames, strips L2TP, and processes them as nor-
   mal 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 NAS stripping L2TP before
   transmitting it out the physical interface to the remote user.  For
   the remainder of this document, a NAS operating as a peer to an LNS
   will be referred to as an L2TP Access Concentrator, or "LAC".

   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 tra-
   ditional mechanisms with respect to further authorization, protocol
   access, and packet filtering.



Valencia                    expires May 1997                     [Page 8]

INTERNET DRAFT                                             December 1996


   Accounting can be performed at both the LAC as well as the LNS.  This
   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 specifi-
   cation.

3.0 Service Model Issues

   There are several significant differences between the standard Inter-
   net 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 prob-
   lems presented by these differences are described below.  The mecha-
   nisms 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 connection to the LNS is initiated
   with any authentication information gathered by the ISP.  The LNS
   completes the authentication by either accepting the connection, 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 an Internet service, the user 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 net-
   work'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
   firewall, allocating addresses which are internal (and, in fact, can
   be RFC1918 addresses, or non-IP addresses).  Because L2TP tunnels



Valencia                    expires May 1997                     [Page 9]

INTERNET DRAFT                                             December 1996


   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 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 allo-
   cates a new Call ID and initiates a session by forwarding the gath-
   ered authentication information.

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

   Once the connection is accepted, the LNS is free to pursue a third
   phase of authentication at the PPP layer.  These activities are out-
   side 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 pro-
   viding 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 signifi-
   cant 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 indica-
   tion 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 dis-
   tinction between a series of failed connection attempts and a series
   of brief successful connections.  Lacking this facility, the LNS must
   always accept connection requests, and would need to exchange a num-
   ber of PPP packets with the remote system.  Note that the LNS could
   use this information to decide to accept the connection (which pro-
   tects against most invalid connection attempts) while still insisting
   on running its own CHAP authentication (for instance, to protect
   against CHAP replay attacks).



Valencia                    expires May 1997                    [Page 10]

INTERNET DRAFT                                             December 1996


4.0 Protocol Overview

   There are two parallel components of L2TP operating over a given tun-
   nel: 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.

   The Nr (Next Received) and Ns (Next Sent) fields are always present
   in control messages, and are optionally present in payload messages.
   Distinct sequence number state is maintained for control messages
   related to the tunnel (Call ID is 0), and for each distinct user ses-
   sion within the tunnel.  Sequence number state is also distinct for
   control and for payload messages within a particular session.  Each
   distinct state is initialized so the first packet is sent with an Ns
   of 0.  Nr is sent reflecting one more than the last in-order received
   packet; if sent before any packet is received it would be 0, indicat-
   ing that it expects the next new Ns value received to be 0.

   The sequence number state is maintained and updated as packets are
   sent.  A message (control or payload) with a zero-length body indi-
   cates 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 remains the same.  For non-zero-length body messages, the
   sequence number state is incremented (modulo 2**16) after it is
   copied to the packet's Ns field.

   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 pay-
      load data once L2TP call control and management information have
      been passed.  The control messages are responsible for establish-
      ment, management, and release of sessions carried through the tun-
      nel, 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 dial 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 mes-
      sages 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.  Con-
      trol messages may indicate changes in operating characteristics of
      an individual user session with a Set-Link-Info message.  Individ-
      ual 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



Valencia                    expires May 1997                    [Page 11]

INTERNET DRAFT                                             December 1996


      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.

      Two mechanisms provide for detection of tunnel connectivity prob-
      lems, one by the reliable transport layer of L2TP and another by
      the higher layer.  The transport layer of L2TP performs control
      message retransmission.  If the number of retransmission attempts
      for a given control message exceeds a configured maximum value,
      the tunnel is reset.  This retransmission mechanism exists in both
      the LNS and LAC ends of the tunnel.  In addition, keepalive con-
      trol echo messages are injected into the control stream by the
      higher L2TP layer after a certain duration of inactivity on a
      given tunnel is detected.  A response to the sent keepalive is
      expected within a configured time interval.  If not received
      within the allowed time interval, the tunnel is reset.  These two
      mechanisms ensure that a connectivity failure between the LNS and
      the LAC can be detected at either end of a tunnel in a timely man-
      ner.

      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 particu-
      lar PPP packet belongs.  In this manner, PPP packets are multi-
      plexed 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 sequenc-
      ing information that can be used to perform congestion control
      over the tunnel.  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.  All implementa-
      tions MUST implement flow control, but may indicate that flow con-
      trol is not desired by omitting the Packet Window Size and Packet
      Processing Delay AVP's during call setup.  L2TP does not specify



Valencia                    expires May 1997                    [Page 12]

INTERNET DRAFT                                             December 1996


      the particular algorithms to use for congestion and flow control.
      Suggested algorithms for the determination of adaptive time-outs
      to recover from dropped data or acknowledgments on the tunnel are
      included in Appendix A of this document.

      L2TP does not include a "Receive-Not-Ready" function.  It is
      expected that the flow-control mechanism used will provide an ade-
      quate "pacing" mechanism so that the sender does not overflow the
      receiver's allotted receive window and receive buffers.  It is
      permissible for the receiving peer to withhold Acks if it is
      unable to accept more data for a connection.  Thus, unlike for the
      Control Message session, the sending peer MUST NOT clear a session
      (or the whole tunnel) as a result of not receiving timely acknowl-
      edgments for transmitted packets.  The job of detecting a non-
      functioning tunnel lies solely with the Control Message functions
      of L2TP.

5. Message Format and Protocol Extensibility

   L2TP defines a set of control messages sent in packets over the tun-
   nel between an LNS and a given LAC.  The exact technique for initiat-
   ing 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 associ-
   ated 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 four bits are a bit mask, describing the general
      attributes of the AVP.  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, any session



Valencia                    expires May 1997                    [Page 13]

INTERNET DRAFT                                             December 1996


      associated with this AVP MUST be terminated.  If the AVP is asso-
      ciated with the overall tunnel, the entire tunnel (and all ses-
      sions within) MUST be terminated.  If M is not set, an unrecog-
      nized AVP should be ignored.

      The H bit, known as the "hidden" bit, controls the encryption of
      the contents of the AVP.  This bit MUST only be set if tunnel
      authentication was used and, therefore, a shared secret exists
      between the peers on either end of the tunnel.  If the H bit is
      set in an AVP, the following mechanism is applied to the contents
      of the AVP, starting with the first byte beyond the Attribute
      field:

         The contents is first padded at the end with nulls to a multi-
         ple of 16 octets.  A one-way MD5 hash is calculated over a
         stream of octets consisting of the shared secret followed by a
         16 octet random vector, referred to as the Authenticator.  The
         sender computes the random Authenticator and passes it in the
         first 16 octets of the AVP value.  The MD5 hash value is XORed
         with the first 16 octet segment of the password and placed in
         the next 16 octets of the Value field of the Proxy-Authen AVP.

         If the password is longer than 16 characters, 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 segment of the
         password and placed in the next 16 octets of the Value field of
         the AVP.

         If necessary, this operation is repeated, with each XOR result
         being used along with the shared secret to generate the next
         hash to XOR the next segment of the password, to no more than
         128 characters.

         On receipt, the Authenticator is taken from the first 16 octets
         of the received AVP value field and the process is reversed to
         yield the original password.  For more details on this hiding
         method, consult the RADIUS [8] specification.

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

      Vendor ID is the IANA assigned "SMI Network Management Private
      Enterprise Codes" 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 exten-
      sions.

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



Valencia                    expires May 1997                    [Page 14]

INTERNET DRAFT                                             December 1996


      Value follows immediately after the Attribute field, and runs for
      the remaining octets indicated in the Overall Length (i.e., Over-
      all 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 bytes in length.

   5.2 Control Message Format

      Each L2TP control message begins with a 20 octet fixed header por-
      tion followed by zero or more AVP's.  This fixed header is format-
      ted:

       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|1|1|1|1|K|0|           | Ver |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tunnel ID           |            Call ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Ns              |               Nr              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Key (opt)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Message Type AVP                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The T bit MUST be 1, indicating a control message.  The next four
      bits MUST be set to 1, making the header more compatible in encod-
      ing with the payload message (defined in the next section).  The K
      bit is optional, documented below.  The bit following the K bit
      MUST be 0.

      Ver MUST be the value 002, indicating a version 1 L2TP message
      (values 000 and 001 are reserved to permit detection of L2F [2]
      and PPTP [3] packets if 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 mes-
      sage does not apply to a single user session within the tunnel
      (for instance, a Stop-Control-Connection-Request 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.

      Nr and Ns reflect the currently transmitted packet and latest
      received packet respectively.  See section 4.0.

      If the K bit is set, the Key field is present.  The K bit MUST be
      set if a Challenge value was received during tunnel setup, and the



Valencia                    expires May 1997                    [Page 15]

INTERNET DRAFT                                             December 1996


      Key reflects the challenge response of this authentication, with
      the resulting MD5 hash value broken into successive 32-bit fields
      which are XOR'ed together and this value put in the Key field.

   5.3 Payload Message Format

      PPP payload packets tunneled within L2TP have a smaller encapsula-
      tion than the L2TP control message header, reducing overhead of
      L2TP during the life of a tunneled PPP session.  The MTU for the
      user data packets encapsulated in L2TP is expected to be 1500
      octets, not including L2TP and media encapsulation.  The smallest
      L2TP encapsulation is 2 octets; the largest is 18 octets (plus
      padding bytes, if present).  See section 8.1 for further MTU con-
      siderations.

       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|I|C|F|K|O|           | Ver |          Length (opt)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Tunnel ID (opt)        |         Call ID (opt)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Ns (opt)          |               Nr (opt)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Key (opt)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Offset Size        |    Offset bytes of pad...     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The T bit MUST be 0, indicating payload.

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

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

      The I and C bits indicate the presence of Tunnel ID and Call ID,
      respectively.  The interpretation of these fields, if present, is
      described in section 5.2.

      If the F bit is set, both the Nr and Ns fields are present.  Ns
      indicates the sequence number of the packet being sent.  The cur-
      rent packet will be this sequence number if the payload size is
      non-zero, otherwise this packet is only an acknowledgment
      (sequence number does not advance).  Nr indicates the next packet
      sequence number to be received (if the last data packet had Ns set
      to 1, the Nr sent back would be 2).  Together, these fields can be
      used to handle out-of-order packets, and to provide flow control
      for the connection.

      If the K bit is set, the Key field is present.  Refer to the
      description in 5.2.

      The Offset Size field is present if the O bit is set in the header



Valencia                    expires May 1997                    [Page 16]

INTERNET DRAFT                                             December 1996


      flags.  This field specifies the number of bytes past the L2TP
      header at which the payload data is expected to start.  It is rec-
      ommended that data thus skipped be initialized to 0's.  If Offset
      Size is 0, or the O bit is not set, the first byte following the
      last byte of L2TP header is the first byte of payload data.

   5.4 Control Message Types

      Control message types defined in this specification exist under
      Vendor ID 0, indicating IETF defined behavior.  The actual message
      semantics are defined in the next section.  The currently defined
      control messages types, grouped by function, are:

         Control Message                        Message Code

         (Control Connection Management)

         Start-Control-Connection-Request            1
         Start-Control-Connection-Reply              2
         Start-Control-Connection-Connected          17
         Stop-Control-Connection-Request             3
         Stop-Control-Connection-Reply               4
         Hello                                       5
         (deleted)                                   6

         (Call Management)

         Outgoing-Call-Request                       7
         Outgoing-Call-Reply                         8
         Outgoing-Call-Connected                    16
         Incoming-Call-Request                       9
         Incoming-Call-Reply                        10
         Incoming-Call-Connected                    11
         Call-Clear-Request                         12
         Call-Disconnect-Notify                     13

         (Error Reporting)

         WAN-Error-Notify                           14

         (PPP Session Control)
         Set-Link-Info                              15


   5.5 General Error Codes

      General error codes pertain to types of errors which are not spe-
      cific 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 determined what the error was.  The currently
      defined General Error codes and their meanings are:

         0 - No general error



Valencia                    expires May 1997                    [Page 17]

INTERNET DRAFT                                             December 1996


         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.

         Generally, when a value of 6 is used, a vendor-specific AVP
         will be present also, providing further detail for that vendor
         implementation.

         If the length of an AVP indicating a General Error specifies
         that the Value field is more than two bytes in length, the
         remaining bytes are an arbitrary string providing further (pos-
         sibly human readable) text associated with the condition.

6.0 Control Connection Protocol Specification

   Control Connection messages are used to establish and clear user ses-
   sions.  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 characteris-
      tic 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.

   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 order-
      ing of control messages.

      Each tunnel maintains a queue of control messages to be transmit-
      ted 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 this



Valencia                    expires May 1997                    [Page 18]

INTERNET DRAFT                                             December 1996


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

      If no peer response is detected after several retransmissions (a
      recommended default is 5, but may be altered due to media consid-
      erations), the tunnel and all sessions within MUST be cleared.

      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.

      Unlike payload traffic, 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 incom-
      ing control messages, possible responding to some with errors
      reflecting an inability to honor the requested action.

      A sliding window mechanism is used, by default, for control mes-
      sage transmission.  The default is to permit four control message
      to be outstanding on a given tunnel.  If a peer specifies a con-
      trol message window in the Start-Control-Connection-Request and
      -Reply packets, up to the indicated number of control messages may
      be sent and held outstanding.  An implementation may only support
      a receive window of 1, but MUST accept at least a window of 4 from
      its peer.

      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.

   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.




Valencia                    expires May 1997                    [Page 19]

INTERNET DRAFT                                             December 1996


6.1 Start-Control-Connection-Request

   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 con-
   trol 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    |
   | Control Message Window|
   | Challenge             |
   +-+-+-+-+-+-+-+-+-+-+-+-+

   Start-Control-Connection-Request 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|        6              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                1              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Attribute field is 1, indicating Start-Control-Connection-
      Request.  The Flags indicate a mandatory option.  Details associ-
      ated with this tunneled session follow in additional AVP's within
      the packet.

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

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



Valencia                    expires May 1997                    [Page 20]

INTERNET DRAFT                                             December 1996


      hexadecimal value 0x100, indicating L2TP protocol version 1, revi-
      sion 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|       10              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               102             |     0x00      |     0x00      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x00      |0|0|0|0|0|0|S|A|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Framing Capabilities AVP within a Start-Control-Connection-
      Request indicates the type of framing that the sender of this mes-
      sage can provide.  The Attribute value is 102, 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.

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

      The Bearer Capabilities AVP within a Start-Control-Connection-
      Request indicates the bearer capabilities that the sender of this
      message can provide.  The Attribute value is 103, indicating
      Bearer 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, analog access is supported.  If bit D
      is set, digital access is supported.

   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|       14              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               104             | Tie Break Value...            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Value...                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Valencia                    expires May 1997                    [Page 21]

INTERNET DRAFT                                             December 1996


      |    ...(64 bits)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Tie Breaker AVP within a Start-Control-Connection-Request con-
      tains a 64-bit Value used to break ties in tunnel establishment
      between an LAC-LNS pair.  The Attribute value is 104, indicating
      Tie Breaker, and is marked optional.  This AVP itself is optional.
      The 8 byte 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 initiate a tunnel disconnect for their outstanding tunnel.
      In the case where a tie breaker is present on both sides, and the
      value is equal, both sides MUST initiate tunnel disconnects.

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

      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|        8              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               105             |    Max (H)    |   Max (L)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Firmware Revision AVP within a Start-Control-Connection-
      Request indicates the firmware revision of the issuing device.
      The Attribute value is 105, 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|0|0| 6 + Host name length  |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Valencia                    expires May 1997                    [Page 22]

INTERNET DRAFT                                             December 1996


      |               106             |Host name...   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Host Name AVP within a Start-Control-Connection-Request indi-
      cates the name of the issuing LAC or LNS.  The Attribute value is
      106, indicating Host Name, and is marked optional.  This AVP
      itself is optional.  This name should be as broadly unique as pos-
      sible; 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|0|0|  6 + vendor name len  |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              107              |Vendor name... |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Vendor Name AVP within a Start-Control-Connection-Request con-
      tains a vendor specific string describing the type of LAC or LNS
      being used.  The Attribute value is 107, indicating Vendor Name,
      and is marked optional.  This AVP itself is optional.  The Value
      is the indicated number of bytes 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|        8              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               108             |         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 108, indicating Assigned Tunnel ID, and is marked manda-
      tory.  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.

   Control Message Window

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




Valencia                    expires May 1997                    [Page 23]

INTERNET DRAFT                                             December 1996


      The Control Message Window AVP within a Start-Control-Connection-
      Request specifies the receive window size being offered to the
      remote peer.  The Attribute value is 109, indicating Control Mes-
      sage Window, 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| 6 + Challenge length  |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              110              | Challenge...  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Challenge AVP within a Start-Control-Connection-Request indi-
      cates that the issuing peer wishes to authenticate the tunnel end-
      points.  The Attribute value is 110, 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

   The Start-Control-Connection-Reply is an L2TP control message sent in
   reply to a received Start-Control-Connection-Request message.  This
   message contains a result code indicating the result of the control
   connection establishment attempt.

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

   Start-Control-Connection-Reply AVP

       0                   1                   2                   3



Valencia                    expires May 1997                    [Page 24]

INTERNET DRAFT                                             December 1996


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

      The Attribute field is 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|        8              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               201             |     0x01      |     0x00      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Protocol Version AVP within a Start-Control-Connection-Reply
      packet indicates the L2TP protocol version available.  The
      Attribute value is 201, indicating Protocol Version, and the Value
      field is a 16-bit hexadecimal value 0x100, indicating L2TP proto-
      col 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|       10              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               202             |     0x00      |     0x00      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x00      |0|0|0|0|0|0|S|A|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Framing Capabilities AVP within a Start-Control-Connection-
      Reply indicates the type of framing that the sender of this mes-
      sage can provide.  The Attribute is 202, 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.

   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|       10              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               203             |     0x00      |     0x00      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Valencia                    expires May 1997                    [Page 25]

INTERNET DRAFT                                             December 1996


      |     0x00      |0|0|0|0|0|0|D|A|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Bearer Capabilities AVP within a Start-Control-Connection-
      Reply indicates the bearer capabilities that the sender of this
      message can provide.  The Attribute is 203, 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, digi-
      tal access is supported.  This AVP MUST be present.

   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|        8              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               204             |    Max (H)    |   Max (L)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Firmware Revision AVP within a Start-Control-Connection-Reply
      indicates the firmware revision of the issuing device.  The
      Attribute is 204, 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 purposes 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|0|0| 6 + Host name length  |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               205             |Host name...   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Host Name AVP within a Start-Control-Connection-Reply indi-
      cates the name of the issuing LAC or LNS.  See the notes in sec-
      tion 6.1 concerning Host Name contents.  It is encoded as the
      Attribute 205, not mandatory, with the indicated number of bytes
      representing the host name string.  This AVP is optional.

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



Valencia                    expires May 1997                    [Page 26]

INTERNET DRAFT                                             December 1996


      The Vendor Name AVP within a Start-Control-Connection-Reply con-
      tains a vendor specific string describing the type of LAC or LNS
      being used.  It is encoded as the Attribute 206, not mandatory,
      with the indicated number of bytes 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|    6 + length         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               207             |               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 207, manda-
      tory, with a 16-bit non-zero Tunnel ID value.  This AVP MUST be
      present.

   Control Message Window

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

      The Control Message Window AVP within a Start-Control-Connection-
      Reply specifies the number of control messages which may be
      received without waiting for an acknowledgment.  It is encoded as
      the Attribute 208, not mandatory, with a 16-bit word indicating
      the number of such messages.  If absent, the peer MUST use a value
      of 4 for the Window.

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

      The Result Code AVP within a Start-Control-Connection-Reply packet
      indicates the result of the control channel establishment attempt.
      The Value field is 209, indicating a Result Code.  The code is a
      16-bit word, and this AVP is mandatory.  This AVP MUST be present.
      Result code values are:



Valencia                    expires May 1997                    [Page 27]

INTERNET DRAFT                                             December 1996


         1 - Successful channel establishment
         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

       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|        8              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               210             |             Error             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Optional Message...           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This AVP is present only if a "General Error" exists, in which
      case Result Code was set to 2 and this AVP encodes the general
      error value as documented in section 5.5.  It has a Value of 210,
      and is marked mandatory.

   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|     6 + length        |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              211              | Challenge...  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Challenge AVP within a Start-Control-Connection-Reply indi-
      cates that the peer wishes to authenticate the tunnel initiator.
      It is encoded as the Attribute 211, mandatory, with at least one
      byte 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.

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

      The Response AVP within a Start-Control-Connection-Reply packet
      provides a response to a challenge received.  The Attribute value



Valencia                    expires May 1997                    [Page 28]

INTERNET DRAFT                                             December 1996


      is 212, 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 suc-
      cess.  For purposes of the ID value in the CHAP response calcula-
      tion, the low order byte of the Sequence number of the challenge
      is used.

6.3 Start-Control-Connection-Connected

   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 chal-
   lenge in the Start-Control-Connection-Reply message.

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

   Start-Control-Connection-Connected 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|        6              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                17             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Attribute field is 17, indicating Start-Control-Connection-
      Connected.  The Flags indicate a mandatory option.

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

      The Response AVP within a Start-Control-Connection-Connected
      packet provides a response to a challenge received.  The Attribute
      value is 1701, 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



Valencia                    expires May 1997                    [Page 29]

INTERNET DRAFT                                             December 1996


      was received, otherwise MUST be omitted.  For purposes of the ID
      value in the CHAP response calculation, the low order byte of the
      Sequence number of the challenge are used.

6.4 Stop-Control-Connection-Request

   The Stop-Control-Connection-Request 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 Reason field.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    L2TP Control Message Header      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Stop-Control-Connection-Request    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Assigned Tunnel ID    |
   | Reason                |
   +-+-+-+-+-+-+-+-+-+-+-+-+

   Stop-Control-Connection-Request 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|        6              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                3              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Attribute field is 3, indicating Stop-Control-Connection-
      Request.  The Flags indicate a mandatory option.  The Flags indi-
      cate a mandatory option.  The single Reason AVP MUST follow this.

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

      The Attribute value is 301, 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-Request must be sent before an Assigned
      Tunnel ID is received.

   Reason




Valencia                    expires May 1997                    [Page 30]

INTERNET DRAFT                                             December 1996


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

      The Attribute value is 302, indicating Reason, and is marked
      mandatory.  This AVP MUST be present.  The Value is a 16-bit word
      indicates the reason for the control connection closure.  Values
      are:

         1 - General request to clear control connection
         2 - Can't support peer's version of the protocol
         3 - Requester is being shut down

6.5 Stop-Control-Connection-Reply

   The Stop-Control-Connection-Reply is an L2TP control message sent by
   one peer of an LAC-LNS control connection upon receipt of a Stop-
   Control-Connection-Request from the other peer.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    L2TP Control Message Header      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Stop-Control-Connection-Reply    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Result Code           |
   | Error Code            |
   +-+-+-+-+-+-+-+-+-+-+-+-+

   Stop-Control-Connection-Reply 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|        8              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                4              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Attribute field is 4, indicating Stop-Control-Connection-
      Reply.  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|        8              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               401             |            Result             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Valencia                    expires May 1997                    [Page 31]

INTERNET DRAFT                                             December 1996


      The Attribute value is 401, indicating Result Code, and is marked
      mandatory.  This AVP MUST be present.  The Value is a 16-bit word
      indicating the result of the attempt to close the control connec-
      tion.  Values are:

         1 - Control connection closed
         2 - Control connection not closed for reason indicated in Error Code

   Error 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|        8              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               402             |             Error             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Optional Message...           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Attribute value is 402, indicating Error Code, and is marked
      mandatory.  This AVP is present only if a "General Error" exists,
      in which case the Value encodes the general error value as docu-
      mented in section 5.5.

6.6 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 control connection.

   Keepalives should be implemented by sending a Hello once every 60
   seconds if 60 seconds have passed without sending a message to the
   peer.  When a Hello is received, it MUST be silently discarded (after
   updating any effects of the indicated Nr/Ns values).

   Because a Hello is a control message, and control messages are reli-
   ably sent by the lower level transport, this keepalive function oper-
   ates 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.

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

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

   Hello AVP

       0                   1                   2                   3



Valencia                    expires May 1997                    [Page 32]

INTERNET DRAFT                                             December 1996


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

      The The Attribute value is 5, indicating Hello, and is marked
      optional.

6.7 (Deleted)

   This section has been deleted.

6.8 Outgoing-Call-Request

   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.

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

   Outgoing-Call-Request 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|   6                   |                0              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           7                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Valencia                    expires May 1997                    [Page 33]

INTERNET DRAFT                                             December 1996


      The Outgoing-Call-Request AVP encodes a request to an LAC to
      establish an outgoing call.  The flags indicate a mandatory
      option.

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

      The Assigned Call ID AVP encodes the ID being assigned to this
      call by the LNS.  The Attribute value is 701, 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|   6 + length          |              0                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             702               |   Number...   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Call Serial Number AVP encodes an identifier assigned by the LNS to
      this call.
      Attribute is 702, indicating Call Serial Number, and is marked mandatory.
      This AVP MUST be present.
      The Number value
      is an identifier used by the LNS and the LAC
      for identifying the call.  Unlike the Call ID, both the LNS and LAC
      associate the same Call Serial Number with a given call.  This AVP
      MUST be present, and the Number MUST be at least one octet in length.

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



Valencia                    expires May 1997                    [Page 34]

INTERNET DRAFT                                             December 1996


      Minimum BPS AVP encodes the lowest acceptable line speed for this
      call.  Attribute is 703, 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|   10                  |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             704               |           BPS (H)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            BPS (L)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

      Bearer Type 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|   10                  |                0              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            705                |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 value bit field Attribute is 705, 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
      be on a digital channel.  Both may be set, indicating that the
      call can be of either type.

      Framing Type 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|   10                  |              0                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             706               |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|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Valencia                    expires May 1997                    [Page 35]

INTERNET DRAFT                                             December 1996


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

      Packet Receive Window Size 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|      8                |              0                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             707               |   Size (H)    |  Size (L)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Packet Receive Window Size AVP encodes the window size being
      advertised by the LNS for this call.  Attribute is 707, indicating
      Packet Receive Window, 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 maxi-
      mum 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 pay-
      load session for this call.

      Packet Processing Delay 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|    8                  |              0                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           708                 |   Delay (H)   |    Delay (L)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Packet Processing Delay AVP encodes the delay LNS has for pro-
      cessing a window full of packets sent by the LAC.  Attribute is
      708, 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.

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




Valencia                    expires May 1997                    [Page 36]

INTERNET DRAFT                                             December 1996


      Phone Number AVP encodes the phone number to be called.  Attribute
      is 709, indicating Phone Number, and is marked mandatory.  This
      AVP MUST be present.  The Phone Number value is an ASCII string.

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

      Sub-Address AVP encodes additional dialing information.  Attribute
      is 710, indicating Sub-Address, and is marked mandatory.  This AVP
      is optional.  The Sub-Address value is an ASCII string.

6.9 Outgoing-Call-Reply

   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 whether or not the LAC is able to attempt the out-
   bound call and also returns certain parameters regarding the call
   attempt.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          L2TP Control Message Header        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Outgoing-Call-Reply             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Assigned Call ID      |
   |        Result Code        |
   |        Error Code         |
   |      Connect Speed        |
   |    Physical Channel Id    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   The Outgoing-Call-Reply AVP encodes an immediate result of attempting
   an outgoing call request.  The flags indicate a mandatory option.

   Assigned Call ID AVP

    0                   1                   2                   3



Valencia                    expires May 1997                    [Page 37]

INTERNET DRAFT                                             December 1996


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

   The Assigned Call ID AVP encodes the ID being assigned to this call
   by the LAC.  Attribute is 801, 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 por-
   tion 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.

   Result Code 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|     8                 |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            802                |         Result Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Result Code AVP encodes the result of the Outgoing-Call-Request.
   Attribute is 802, indicating Result Code, and is marked mandatory.
   This AVP MUST be present.  The Result Code is a 16-bit value indicat-
   ing:

      1 - Call attempt in progress
      2 - Outgoing Call not attempted for the reason indicated in Error Code
      3 - No appropriate facilities are available (temporary condition)
      4 - No appropriate facilities are available (permanent condition)
      5 - Invalid destination
      6 - Outgoing Call administratively prohibited


   Error Code 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|     8                 |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            803                |          Error Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Optional Message...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Error Code AVP is used to encode a specific error code in case
   the result AVP indicates a General Error.  Attribute is 803, indicat-
   ing Error Code, and is marked mandatory.  This AVP is present only if



Valencia                    expires May 1997                    [Page 38]

INTERNET DRAFT                                             December 1996


   the Result Code indicates a value of 2.  The value can be one of the
   general error IDs specified in Section 5.5.

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

   Connect Speed BPS AVP encodes the speed for the connection.  The
   Attribute value is 804, indicating Connect Speed, and is marked
   mandatory.  This AVP MUST be present if the Result indicates a call
   is in progress.  The BPS is a 16-bit value indicating the speed in
   bits/second.

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

   Physical Channel ID AVP encodes the vendor specific physical channel
   number used for the call.  The Attribute value is 805, 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.10 Outgoing-Call-Connected

   Outgoing-Call-Connected is an L2TP control message sent by the LAC to
   the LNS to indicate the result of a requested outgoing call.  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          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Valencia                    expires May 1997                    [Page 39]

INTERNET DRAFT                                             December 1996


   |        Result Code        |
   |        Error Code         |
   |        Cause Code         |
   |      Connect Speed        |
   |       Framing Type        |
   |  Packet Recv. Window      |
   |  Packet Processing Delay  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Outgoing-Call-Connected 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|      6                |                0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           16                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Outgoing-Call-Connected AVP encodes the final result of an outgo-
   ing call request.  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|       8               |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              1601             |          Result Code          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Result Code indicates the result of the call attempt.  The
      Attribute value is 1601, indicating Result Code, and is marked
      mandatory.  This AVP MUST be present.  The Result Code is a 16-bit
      value:

         1 - Call established with no errors
         2 - Outgoing Call not established for the reason indicated in Error Code
         3 - Outgoing Call failed due to no carrier detected
         4 - Outgoing Call failed due to detection of a busy signal
         5 - Outgoing Call failed due to lack of a dial tone
         6 - Outgoing Call was not established within time allotted by LAC
         7 - Outgoing Call was connected but no appropriate framing was detected

      Error Code 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|     8                 |              0                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           1602                |          Error Code           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Valencia                    expires May 1997                    [Page 40]

INTERNET DRAFT                                             December 1996


      | Optional Message...           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Error Code AVP is used to encode a specific error code.
      Attribute is 1602, indicating Error Code, and is marked mandatory.
      This AVP is present only if the Result Code indicates a value of
      2.  The value is encoded as specified in Section 5.5.

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

      The Cause Code AVP is used to give additional information in cases
      of call failure.  The Attribute value is 1603, indicating Cause
      Code, and is marked mandatory.  This AVP is optional.  It is only
      relevant when the LAC uses Q.931/DSS1 for the outbound call
      attempt.  Cause Code is the returned Q.931 Cause code and Cause
      Msg is the returned Q.931 message code (e.g., DISCONNECT) associ-
      ated with the Cause Code.  Both values are returned in their
      native ITU encodings.  An additional ASCII text Advisory Message
      may also be included (presence indicated by the AVP length) to
      further explain the call failure.

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

      Connect Speed BPS AVP encodes the final negotiated speed for the
      connection.  The Attribute value is 1604, indicating Connect
      Speed, and is marked mandatory.  This AVP MUST be present if the
      call attempt is successful.  The BPS value indicates the speed in
      bits/second.

      Framing Type 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Valencia                    expires May 1997                    [Page 41]

INTERNET DRAFT                                             December 1996


      |1|0|0|0|     10                |              0                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            1605               |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 1605, indicating Framing Type, and is marked
      mandatory.  This AVP MUST be present if the call attempt is suc-
      cessful.  The value bit field indicates the type of PPP framing is
      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.

      Packet Receive Window Size 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|     8                 |              0                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            1606               |             Size              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Packet Receive Window Size AVP encodes the window size being
      offered by the LNS for this call.  The Attribute value is 1606,
      indicating Packet 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 maxi-
      mum number of data packets the LNS should send before waiting for
      an acknowledgment.  This AVP MUST be present if and only if
      Sequence and Acknowledgment Numbers are to be used in the payload
      session for this call.

      Packet Processing Delay 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|      8                |              0                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             1607              |            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 1607, 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.




Valencia                    expires May 1997                    [Page 42]

INTERNET DRAFT                                             December 1996


6.11 Incoming-Call-Request

   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 it is
   answered to determine 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     |
   |     Call Bearer Type      |
   |    Physical Channel Id    |
   |       Dialed Number       |
   |      Dialing Number       |
   |       Sub-Address         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Incoming-Call-Request 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|     7                 |                0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             9                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Incoming-Call-Request AVP encodes an incoming call being indi-
   cated by the LAC.  The flags indicate a mandatory option.

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



Valencia                    expires May 1997                    [Page 43]

INTERNET DRAFT                                             December 1996


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Assigned Call ID AVP encodes the Call ID being assigned to call
   by the LAC.  The Attribute value is 901, indicating 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 it subsequently transmits over the tunnel that belong to this
   call.  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 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| 6 + Number length     |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            902                |   Number...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Call Serial Number AVP encodes an identifier assigned by the LAC to
   this call.  The Attribute value is 902, Call Serial Number, and is
   marked mandatory.  This AVP MUST be present.  The Number value is an
   identifier assigned by the LAC and used by the LNS and the LAC for
   identifying the call.  Unlike the Call ID, both the LNS and LAC asso-
   ciate the same Call Serial Number with a given call.

   Call Bearer Type 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|     10                |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            903                |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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Call Bearer Type AVP encodes the bearer type for the incoming call.
   The Attribute value is 903, Call Bearer Type, and is marked manda-
   tory.  This AVP MUST be present.  The Value is a 32-bit field indi-
   cating 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.

   Physical Channel ID 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|     10                |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Valencia                    expires May 1997                    [Page 44]

INTERNET DRAFT                                             December 1996


   |            904                |            ID (H)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           ID (L)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Physical Channel ID AVP encodes the vendor specific physical channel
   number used for the call.  The Attribute value is 904, Physical Chan-
   nel 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 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|   6 + Number len      |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            905                |    Number...  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Dialing Number 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|      6 + length       |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             906               |    Number...  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Dialing Number AVP encodes the originating number for the incoming
   call, that is, CLID.  The Attribute value is 906, Dialing Number, and
   is marked mandatory.  The presence of this AVP is optional.  The
   value is an ASCII string.

   Sub-Address 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|     6 + length        |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              907              | Sub-Address...|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Sub-Address AVP encodes additional dialing information.  The
   Attribute value is 907, Sub-Address, and is marked mandatory.  The
   presence of this AVP is optional.  The Sub-Address value is an ASCII



Valencia                    expires May 1997                    [Page 45]

INTERNET DRAFT                                             December 1996


   string.

6.12 Incoming-Call-Reply

   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 the result of the incoming call attempt.  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 whether the
   call should be answered or not.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          L2TP Control Message Header        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Incoming-Call-Reply             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Assigned Call ID       |
   |           Result Code         |
   |          Error Code           |
   |    Packet Recv. Window Size   |
   |    Packet Processing Delay    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Incoming-Call-Reply 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|     6                 |                0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             10                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Incoming-Call-Reply AVP encodes a response by the LNS to the
   incoming call indication given by the LAC.  The flags indicate a
   mandatory option.

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

   The Assigned Call ID AVP encodes the ID being assigned to call by the
   LNS.  The Attribute value is 1001, 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



Valencia                    expires May 1997                    [Page 46]

INTERNET DRAFT                                             December 1996


   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.

   Result Code 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|     8                 |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           1002                |         Result Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Result Code AVP encodes the result of the Incoming-Call-Request.  The
   Attribute value is 1002, Result Code, and is marked mandatory.  This
   AVP MUST be present.  The Result Code value is a 16-bit value:

      1 - The LAC should answer the incoming call
      2 - The Incoming Call should not be established due to the reason
         indicated in Error Code
      3 - The LAC should not accept the incoming call.  It should hang
         up or issue a busy indication

   Error Code 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|     8                 |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           1003                |          Error Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Optional Message...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This AVP is present only if a "General Error" exists, in which case
   Result Code was set to 2 and this AVP encodes the general error value
   as documented in section 5.5.  It has a Value of 1003, and is marked
   mandatory.

   Packet Receive Window Size 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|     8                 |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            1004               |    Size (H)   |  Size (L)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet Receive Window Size AVP encodes the receive window size being
   offered by the LNS for this call.  The Attribute value is 1004,



Valencia                    expires May 1997                    [Page 47]

INTERNET DRAFT                                             December 1996


   Packet 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
   optional if Sequence and Acknowledgment Numbers are not to be used in
   the payload session for this call.

   Packet Processing Delay 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|      8                |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             1005              |   Delay (H)   |    Delay (L)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet Processing Delay AVP encodes the delay the LNS expects for
   processing a window full of packets sent by the LAC.  The Attribute
   value is 1005, 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.13 Incoming-Call-Connected

   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 regu-
   late 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         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Connect Speed        |
   |       Framing Type        |
   |  Packet Recv. Window      |
   |  Packet Processing Delay  |
   |  Initial LCP Conf         |
   |  Last Sent LCP Conf       |
   |  Last Received LCP Conf   |
   |  Proxy authen type        |
   |  Proxy authen name        |
   |  Proxy authen challenge   |
   |  Proxy authen ID          |



Valencia                    expires May 1997                    [Page 48]

INTERNET DRAFT                                             December 1996


   |  Proxy authen response    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Incoming-Call-Connected 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|     6                 |                0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             11                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Incoming-Call-Connected AVP encodes a response by the LAC to the
   Incoming-Call-Reply message sent by the LAC.  The flags indicate a
   mandatory option.

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

   Connect Speed BPS AVP encodes the speed for the connection.  The
   Attribute value is 1101, Connect Speed, and is marked mandatory.
   This AVP MUST be present if the call attempt is successful.  The
   value is a 32-bit quantity indicating the speed in bits/second.

   Framing Type 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|     10                |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            1102               |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 1102, Call Serial Number, and is marked mandatory.
   This AVP MUST be present if the call attempt is successful.  The
   value is a 32-bit bit field indicating 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.




Valencia                    expires May 1997                    [Page 49]

INTERNET DRAFT                                             December 1996


   Packet Receive Window Size 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|      8                |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            1103               |             Size              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet Receive Window Size AVP encodes the window size being offered
   by the LAC for this call.  The Attribute value is 1103, Packet
   Receive Window Size, and is marked mandatory.  This AVP is optional
   if Sequence and Acknowledgment Numbers are not to be used in the pay-
   load session for this call.  The 16-bit Size value indicates the num-
   ber 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 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|      8                |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            1104               |            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 1104, Packet Processing Delay, and is marked mandatory.  The
   presence of this AVP is optional.  The 16-bit Delay value is speci-
   fied in units of 1/10 seconds.  Refer to Appendix A to see a descrip-
   tion of how this value is determined and used.

   Initial LCP Conf

    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| 6 + LCP confreq len   |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            1105               | LCP confreq...|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 prop-
   erties the client requested in its initial LCP CONFREQ request.  The
   Attribute value is 1105, Initial LCP Conf, 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.



Valencia                    expires May 1997                    [Page 50]

INTERNET DRAFT                                             December 1996


   Last Sent LCP Conf

    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| 6 + LCP confreq len   |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             1106              | LCP confreq...|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   See Initial LCP Conf above for rationale.  The Attribute value is
   1106, Last Sent LCP Conf, 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, start-
   ing at the first option within this packet's body.

   Last Received LCP Conf

    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| 6 + LCP confreq len   |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           1107                | LCP confreq...|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   See Initial LCP Conf above for rationale.  The Attribute value is
   1107, Last Received LCP Conf, 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 negotia-
   tion, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|     8                 |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            1108               |            Type               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Attribute value is 1108, Proxy Authen Type, and is marked manda-
   tory.  This AVP MUST be present.  The value Type is a 16-bit word,
   holding a value:

      1 - Textual username/password exchange
      2 - PPP CHAP
      3 - PPP PAP
      4 - None

   Associated AVP's for each type of authentication follow.

   Proxy Authen Name



Valencia                    expires May 1997                    [Page 51]

INTERNET DRAFT                                             December 1996


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

   The Attribute value is 1109, Proxy Authen Name, and is marked manda-
   tory.  This AVP MUST be present for Proxy Authen Type values 1, 2,
   and 3.  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|        6 + length     |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             1110              | Challenge...  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Attribute value is 1110, Proxy Authen Challenge, and is marked
   mandatory.  The AVP itself MUST be present for Proxy authen type 2.
   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|       8               |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             1111              |             ID                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Attribute value is 1111, Proxy Authen ID, and is marked manda-
   tory.  The AVP itself MUST be present for Proxy authen type 2.  The
   ID field contains the byte ID value presented to the client by the
   LAC in its associated CHAP challenge.  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|        6 + length     |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             1112              | Response...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Valencia                    expires May 1997                    [Page 52]

INTERNET DRAFT                                             December 1996


   The Attribute value is 1112, Proxy Authen Response, and is marked
   mandatory.  The AVP itself MUST be present for Proxy authen types 1,
   2, and 3.  The Response field contains the client's response to the
   challenge.  For Proxy authen type 2, 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.

6.14 Call-Clear-Request

   The Call-Clear-Request is an L2TP control message sent by the LNS to
   the LAC indicating that a particular call is to be disconnected.  The
   call being cleared can be either an incoming or outgoing call, in any
   state.  The LAC responds to this message with a Call-Disconnect-
   Notify message.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          L2TP Control Message Header        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Call-Clear-Request              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Assigned Call ID    |
   +-+-+-+-+-+-+-+-+-+-+-+-+

   Call-Clear-Request 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|       6               |                0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             12                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Call-Clear-Request AVP encodes a request by the LNS to the LAC to
   disconnect the call.  The flags indicate a mandatory option.

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

   This attribute is used to provide the LAC with the Call ID assigned
   by the LNS for the call to be cleared in the case where the LNS has
   not yet learned the LAC's Call ID for the call.  The Attribute value
   is 1201, Assigned Call ID, and is marked mandatory.  This AVP MUST be
   present.  The value Call ID MUST be the same value sent from the LNS
   to the LAC in the initial call setup exchange.




Valencia                    expires May 1997                    [Page 53]

INTERNET DRAFT                                             December 1996


6.15 Call-Disconnect-Notify

   The Call-Disconnect-Notify message is an L2TP control message sent by
   the LAC to the LNS.  It is issued whenever a call is disconnected,
   due to the receipt by the LAC of a Call-Clear-Request or for any
   other reason.  Its purpose is to inform the LNS of the disconnection
   and the reason why the disconnection occurred.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          L2TP Control Message Header        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Call-Disconnect-Notify          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Result Code         |
   |     Error Code          |
   |     Cause Code          |
   |     Assigned Call ID    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Call-Disconnect-Notify 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|     6                 |                0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             13                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Call-Disconnect-Notify AVP encodes a disconnect indication from
   the LAC to the LNS.  The flags indicate a mandatory option.

   Result Code 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|     8                 |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           1301                |         Result Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Result Code AVP encodes the reason for disconnect.  The Attribute
   value is 1301, Result Code, and is marked mandatory.  This AVP MUST
   be present.  The Result Code value can be one of:

      1 (Lost Carrier) - Call disconnected due to loss of carrier
      2 (General Error) - Call disconnected for the reason indicated in
         Error Code.
      3 (Admin Shutdown) - Call disconnected for administrative reasons
      4 (Request) - Call disconnected due to received Call-Clear-Request

   Error Code AVP




Valencia                    expires May 1997                    [Page 54]

INTERNET DRAFT                                             December 1996


    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|     8                 |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           1302                |         Error Code            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Optional Message...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This AVP is present only if a "General Error" exists, in which case
   Result Code was set to 2 and this AVP encodes the general error value
   as documented in section 5.5.  The Attribute value is 1302, Error
   Code, and is marked mandatory.  This AVP MUST be present if Result
   Code was 2.

   Cause Code 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|     8                 |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           1303                |          Cause Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Optional message...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Cause Code AVP is used to give additional information in case of
   unsolicited call disconnection.  The Attribute value is 1303, 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.  This AVP is optional.  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.  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 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|      8                |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            1304               |            Call ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Assigned Call ID which was provided to the LNS from this LAC is
   included in the Call-Disconnect-Notify message.  This permits a con-
   nection to be terminated even before the LNS has provided its own
   Assigned Call ID to this LAC (the Call ID field in the control



Valencia                    expires May 1997                    [Page 55]

INTERNET DRAFT                                             December 1996


   message header is 0).  The Attribute value is 1304, Assigned Call ID,
   and is marked mandatory.  This AVP MUST be present.

6.16 WAN-Error-Notify

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

   The WAN-Error-Notify AVP encodes line and other errors sent by the
   LAC to the LNS.  The flags indicate a mandatory option.

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



Valencia                    expires May 1997                    [Page 56]

INTERNET DRAFT                                             December 1996


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

      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 ses-
         sion was established
      Buffer Overruns - Number of buffer over-runs detected since ses-
         sion was established
      Time-out Errors - Number of time-outs since call was established
      Alignment Errors - Number of alignment errors since call was
         established

6.17 Set-Link-Info

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

   The Set-Link-Info AVP encodes ACCM information sent from the LNS to
   the LAC after it is negotiated in LCP.  The flags indicate a manda-
   tory option.

   ACCM 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|     32                |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Valencia                    expires May 1997                    [Page 57]

INTERNET DRAFT                                             December 1996


   |            1501               |          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 1501, ACCM, and is marked mandatory.  The
   presence of this AVP is optional.  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 spe-
   cific 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 retransmis-
sion 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 connec-
   tion 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.

7.2 Control Connection States

   Control messages are carried over the same media as the payload mes-
   sages which are carried following successful connection establish-
   ment.  The L2TP control connection protocol is not distinguishable
   between the LNS and LAC, but is distinguishable between the origina-
   tor and receiver.  The originating peer is the one which first estab-
   lishes the tunnel.  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 situation.

7.2.1 Control Connection Originator

   State           Event             Action               New State
   -----           -----             ------               ---------

   idle            Open request      Send                 wait-ctl-reply



Valencia                    expires May 1997                    [Page 58]

INTERNET DRAFT                                             December 1996


                                     Start-Control-
                                     Connection-Request

   wait-ctl-reply  Collision         If terminating,      idle
                                     clean-up.

   wait-ctl-reply  Collision         If not terminating,  wait-stop-reply
                         Send Stop-Control-
                         Connection-Request

   wait-ctl-reply  Receive           If version OK        established
                   Start-Control-    Send Start-Control-
                   Connection-Reply  Connection-Connected

   wait-ctl-reply  Receive           If version not OK    wait-stop-reply
                   Start-Control-    or bad auth, Send
                   Connection-Reply  Stop-Control-
                                     Connection-Request

   established     Local terminate   Send                 wait-stop-reply
                                     Stop-Control-
                                     Connection-Request

   established     Receive           Send                 idle
                   Stop-Control-     Stop-Control-
                   Connection-       Connection-Reply
             Request          and clean-up

   wait-stop-reply Receive           Clean-up             idle
                   Stop-Control-
                   Connection-Reply

   idle
      The control connection originator attempts to open a connection to
      the peer during idle state.  When the connection is open, the
      originator transmits a send Start-Control-Connection-Request and
      then enters the wait-ctl-reply state.

   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 Start-Control-Connection-Reply 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 estab-
      lished state.  If the version is earlier and not supported, a
      Stop-Control-Connection-Request SHOULD be sent to the peer and the
      originator moves into the wait-stop-reply state.

   established
      An established connection may be terminated by either a local



Valencia                    expires May 1997                    [Page 59]

INTERNET DRAFT                                             December 1996


      condition or the receipt of a Stop-Control-Connection-Request.  In
      the event of a local termination, the originator MUST send a Stop-
      Control-Connection-Request and enter the wait-stop-reply state.

      If the originator receives a Stop-Control-Connection-Request it
      SHOULD send a Stop-Control-Connection-Reply and close the connec-
      tion.

   wait-stop-reply
      If a Stop-Control-Connection-Reply is received, the connection
      SHOULD be closed and the control connection becomes idle.

7.2.2 Control connection Receiver

   State           Event              Action                 New State
   -----           -----              ------                 ---------
   idle            Receive            If version not OK      idle
                   Start-Control-     send
                   Connection-Request Start-Control-
                                      Connection-Reply
                                      with error

   idle            Receive            Version OK, send       wait-ctl-reply
                   Start-Control-     Start-Control-
                   Connection-Request Connection-Reply

   wait-ctl-reply  Receive            Clean-up, send         idle
                   Stop-Control-      Stop-Control-
                   Connection-Request Connection-Reply

   wait-ctl-reply  Receive            If auth OK             established
                   Start-Control-
                   Connection-Connected

   wait-ctl-reply  Receive            If auth not OK         wait-stop-reply
                   Start-Control-     Send Stop-Control-
                   Connection-        Connection-Request
                   Connected

   established     Receive            Clean-up, send         idle
                   Stop-Control-      Stop-Control-
                   Connection-Request Connection-Reply

   established     Local terminate    Send                   wait-stop-reply
                                      Stop-Control-
                                      Connection-Request

   wait-stop-reply Receive            Clean-up               idle
                   Stop-Control-
                   Connection-Reply

   idle
      The control connection receiver waits for an incoming connection
      attempt.  When notified of a new connection, it should prepare to



Valencia                    expires May 1997                    [Page 60]

INTERNET DRAFT                                             December 1996


      receive L2TP messages.  When a Start-Control-Connection-Request is
      received its version field MUST be examined.  If the version is
      earlier than the receiver's version and the earlier version can be
      supported by the receiver, the receiver SHOULD send a
      Start-Control-Connection-Reply.

      If the version is earlier than the receiver's
      version and the version cannot be supported, the receiver SHOULD send
      a Start-Connection-Reply message indicating this error and remain in
      the idle state.  If the receiver's version is the same as
      or earlier than the peer's, the receiver SHOULD send a
      Start-Control-Connection-Reply with the receiver's version and enter the
      wait-ctl-reply state.

   wait-ctl-reply

      The peer waits in this state after sending a Start-Control-Connection-Reply.
      If it receives a Start-Control-Connection-Reply, it checks to see if the
      message is properly authenticated and, if so, it enters the established
      state.
      If authentication fails, a Stop-Control-Connection-Request with the reason
      code set appropriately is sent and wait-stop-reply state is entered.
      if a Stop-Control-Connection-Request is received, a
      Stop-Control-Connection-Reply. is issued and idle state is entered.

   established
      An established connection may be terminated by either a local
      condition or the reception of a Stop-Control-Connection-Request.  In
      the event of a local termination, the originator MUST send a
      Stop-Control-Connection-Request
      and enter the wait-stop-reply state.

      If the originator receives a Stop-Control-Connection-Request it
      SHOULD send a Stop-Control-Connection-Reply and close the
      connection.

   wait-stop-reply
      If a Stop-Control-Connection-Reply is received, the connection
      SHOULD be closed and the control connection becomes idle.

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



Valencia                    expires May 1997                    [Page 61]

INTERNET DRAFT                                             December 1996


   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
   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 are not indicative of
         an authorized user
      -  The bearer service is not authorized or supported

   If the LNS chooses to accept the call, it responds with an
   Outgoing-Call-Reply
   which also indicates window sizes (see Appendix B).  When
   the LAC receives the Outgoing-Call-Reply, it attempts to connect the
   call, assuming the calling party has not hung up.  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.

   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-Clear-Request message and then waits
   for a Call-Disconnect-Notify.

7.4.1 LAC Incoming Call States

   State       Event               Action                   New State
   -----       -----               ------                   ---------
   idle        Ring OR             Send                     wait-reply
               Ready to indicate   Incoming-Call-Request
               incoming conn.

   wait-reply  Receive             Clean-up                 idle
               Incoming-Call-Reply
               Not Accepting

   wait-reply  Receive             Answer call              established
               Incoming-Call-Reply Send
               Accepting           Incoming-Call-Connected

   wait-reply  Abort               Clean-up                 idle
                                   Send Call-Disconnect-
                                   Notify

   established Receive             Hang-up and send         idle
               Call-Clear-Request  Call-Disconnect-Notify

   established telco line drop     Send                     idle
                                   Call-Disconnect-Notify



Valencia                    expires May 1997                    [Page 62]

INTERNET DRAFT                                             December 1996


   established local disconnect    Send                     idle
                                   Call-Disconnect-Notify

The states associated with the LAC for incoming calls are:

idle

   The LAC detects an incoming call on one of its telco interfaces.
   Typically this means an analog line is ringing or an ISDN TE has
   detected an incoming Q.931 SETUP message.  The LAC sends an Incoming-
   Call-Request message and moves to the wait-reply state.

wait-reply

   The LAC receives an Incoming-Call-Reply message indicating non- will-
   ingness to accept the call (general error or don't accept) and moves
   back into the idle state.  If the reply message indicates that 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 follow-
   ing:
      An event on the telco connection.  The LAC sends a Call-
         Disconnect-Notify message
      Receipt of a Call-Clear-Request.  The LAC sends a Call-Disconnect-
         Notify message
      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                If not accepting      idle
                Incoming-Call-Request  Send
                                       Incoming-Call-Reply
                                       with Error

   idle         Receive                If accepting          wait-connect
                Incoming-Call-Request  Send
                                       Incoming-Call-Reply

   wait-connect Receive                Clean-up              idle
                Call-Disconnect-Notify

   wait-connect Receive                Get ready for data    established
                Incoming-Call-Connect

   established  Receive                Clean-up              idle
                Call-Disconnect-Notify

   established  Local terminate        Send                  wait-



Valencia                    expires May 1997                    [Page 63]

INTERNET DRAFT                                             December 1996


                                       Call-Clear-Request    disconnect

   wait-        Receive                Clean-up              idle
   disconnect   Call-Disconnect-Notify

   The states associated with the LNS for incoming calls are:

   idle

      An Incoming-Call-Request message is received.  If the request is
      not acceptable, an Incoming-Call-Reply 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 indicating
      accept in the result code.  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 connect 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-Clear-Request.
      Once a Call-Clear-Request has been sent, the session enters the
      wait-disconnect state.

   wait-disconnect

      Once a Call-Disconnect-Notify is received the session moves back
      to the idle state.

7.5 Outgoing calls

Outgoing calls are initiated by an LNS and instruct an LAC to place a
call on a telco interface.  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 mes-
sage to the LNS indicating the final result of the call attempt:

7.5.1 LAC Outgoing Call States




Valencia                    expires May 1997                    [Page 64]

INTERNET DRAFT                                             December 1996


   State       Event              Action                        New State
   -----       -----              ------                        ---------
   idle        Receive            If cannot service,            idle
               Outgoing-Call-     send Outgoing-Call-Reply
               Request            with Error

   idle        Receive            If can service,               wait-cs-ans
               Outgoing-Call-     send
               Request            Outgoing-Call-Reply

   wait-cs-ans Telco answer       Send                          established
               and framing        Outgoing-Call-Connected
               detected

   wait-cs-ans Call failure       Send
                                  Outgoing-Call-Connected       idle
                                  with Error

   wait-cs-ans Receive            Hang-up, send                 idle
               Call-Clear-Request Call-Disconnect-Notify

   established Receive            Hang-up, send                 idle
               Call-Clear-Request Call-Disconnect-Notify
               or detect call
               disconnected

   The states associated with the LAC for outgoing calls are:

   idle

      Received Outgoing-Call-Request.  If this is received in error,
      respond with an Outgoing-Call-Reply with error condition set.
      Otherwise, allocate physical channel to dial on and send an Outgo-
      ing-Call-Reply.  Place the outbound call and move to the wait-cs-
      ans state.

   wait-cs-ans

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

   established

      If a Call-Clear-Request is received, the telco call SHOULD be
      released via appropriate mechanisms and a Call-Disconnect-Notify
      message SHOULD BE sent to the LNS.  If the call is disconnected by
      the client or by the telco interface, a Call-Disconnect-Notify
      message MUST be sent to the LNS.  Return to idle state after send-
      ing the Call-Disconnect-Notify.




Valencia                    expires May 1997                    [Page 65]

INTERNET DRAFT                                             December 1996


7.5.2 LNS Outgoing Call States

   State         Event                  Action                  New State
   -----         -----                  ------                  ---------
   idle          Open request           Send                    wait-reply
                                        Outgoing-Call-Request

   wait-reply    Receive                Clean-up                idle
                 Outgoing-Call-Reply
                 with Error

   wait-reply    Receive                Null                    wait-connect
                 Outgoing-Call-Reply

   wait-reply    Abort request          Send                    wait-disconnect
                                        Call-Clear-Request

   wait-connect  Abort request          Send
                                        Call-Clear-Request      wait-disconnect

   wait-connect  Receive                Get ready for data      established
                 Outgoing-Call-Connected
                 no Error

   wait-connect  Receive                Clean-up                idle
                 Outgoing-Call-Connected
                 with Error

   established   Receive                Clean-up                idle
                 Call-Disconnect-Notify

   established   Local terminate        Send                    wait-disconnect
                                        Call-Clear-Request

   wait-disconnect Receive              Clean-up                idle
                 Call-Disconnect-
                 Notify

   The states associated with the LNS for outgoing calls are:

   idle
      An Outgoing-Call-Request message is sent to the LAC and the ses-
      sion moves into the wait-reply state.

   wait-reply
      An Outgoing-Call-Reply is received which indicates an error.  The
      session returns to idle state.  If the Outgoing-Call-Reply does
      not indicate an error, the telco call is connected and the session
      moves to the established state.

   wait-connect
      An Outgoing-Call-Connected is received which indicates an error.
      The session returns to idle state.  No telco call is active.  If
      the Outgoing-Call-Connected does not indicate an error, the telco



Valencia                    expires May 1997                    [Page 66]

INTERNET DRAFT                                             December 1996


      call is

   established
      If a Call-Disconnect-Notify is received, the telco 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-Clear-Request to the LAC
      and then enters the wait-disconnect state.

   wait-disconnect
      A session disconnection is waiting to be confirmed by the LAC.
      Once the LNS receives the Call-Disconnect-Notify message, the ses-
      sion enters idle state.

8.0 L2TP Over Specific Media

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

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 source and destination ports are the same (1701), with demulti-
   plexing being achieved using Tunnel ID values.  It is legal for the
   source IP address of a given Tunnel ID to change over the life of a
   connection, as this may correspond to a peer with multiple IP inter-
   faces responding to a network topology change.  Responses should
   reflect the last source IP address 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 MTUs of the
   path over which the L2TP packets are likely to travel have a consis-
   tent value.

   Because a single UDP port is used for all packets, both the I and C
   bits MUST be used to permit correct demultiplexing.

   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 1 in this field instead.

8.2 IP

   When operating directly over IP, protocol number TBD [3] is used to
   encode the packet as L2TP-over-IP.  IP source address and MTU issues
   are identical to 8.1, except that the lack of a UDP header makes the
   packet more compact.  As in IP/UDP, the I and C bits MUST be present.




Valencia                    expires May 1997                    [Page 67]

INTERNET DRAFT                                             December 1996


9.0 Security Considerations

   L2TP encounters several security issues in its operation.  The gen-
   eral 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 reply
      and snooping.

      Once the tunnel endpoints have authenticated, a derived Key may be
      carried in subsequent packets, which provides mild protection
      against brief or "accidental" attacks.  There is no cryptographic
      strength to these Keys, and any attacker which can snoop packets
      can take control of the tunnel.

      For L2TP tunnels over IP, IP-level packet security provides very
      strong protection of the tunnel.  This requires no modification to
      the L2TP protocol, and leverages extensive IETF work in this area.

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

   9.2 Client Security

      A more systematic method of protection in tunneled PPP environ-
      ments may be achieved through client security.  PPP layer encryp-
      tion 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 pre-
      cede 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 pro-
      vide acceptable security.  For cases where LNS-initiated authenti-
      cation 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



Valencia                    expires May 1997                    [Page 68]

INTERNET DRAFT                                             December 1996


      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.

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 and Allan Rubens of Ascend Communications made valuable
   refinements to the protocol definition of L2TP and contributed to the
   editing of this document.

11.0 Contacts

   Kory Hamzeh
   Ascend Communications
   1275 Harbor Bay Parkway
   Alameda, CA 94502
   kory@ascend.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

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

   Jeff Taarud
   (formerly of 3COM Corporation, no current contact)

   William Verthein
   U.S. Robotics

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", Internet
      draft, April 1996

   [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, "Point-to-Point
      Tunneling Protocol", Internet draft, June 1996




Valencia                    expires May 1997                    [Page 69]

INTERNET DRAFT                                             December 1996


   [4] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC1034,
      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)." draft-ietf-radius-radius-05.txt,
      Livingston, Merit, Daydreamer, July 1996.

Appendix A: Acknowledgment Time-Outs

   L2TP uses sliding windows and time-outs to provide both user session
   flow-control across the underlying medium (which may be an internet-
   work) and to perform efficient data buffering to keep the LAC-LNS
   data channels full without causing receive buffer overflow.  L2TP
   requires that a time-out be used to recover from dropped data or
   acknowledgment packets.  The exact implementation of the time-out is
   vendor-specific.  It is suggested that an adaptive time-out be imple-
   mented with backoff for congestion control.  The time-out mechanism
   proposed here has the following properties:

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

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

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

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

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

   Some definitions:

      Packet Processing Delay, "PPD", is the amount of time required for



Valencia                    expires May 1997                    [Page 70]

INTERNET DRAFT                                             December 1996


      each peer to process the maximum amount of data buffered in their
      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 connec-
      tions, this number could be significant.

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

      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 mini-
      mal (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 Time-Out, "ATO", is the time that must elapse before an
      acknowledgment is considered lost.  After a time-out, the sliding
      window is partially closed and the ATO is backed off.

Packet Processing Delay (PPD)

   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 time-outs are allowed).  IF adaptive time-outs 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.  Window-
   Size 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 suf-
   ficient to keep the current session's pipe full.  The constant 8 con-
   verts octets to bits (assuming ConnectRate is in bits per second).
   If ConnectRate is in bytes per second, omit the 8.  LACFudge and LNS-
   Fudge 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 aver-
   age bit rate of the path between the LNS and LAC.  Given that this
   number is probably very large and WindowSize is relatively small,



Valencia                    expires May 1997                    [Page 71]

INTERNET DRAFT                                             December 1996


   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 ini-
   tial RTT[n-1] value.

A.1 Calculating Adaptive Acknowledgment Time-Out

   We still must decide how much time to allow for acknowledgments to
   return.  If the time-out is set too high, we may wait an unnecessar-
   ily long time for dropped packets.  If the time-out is too short, we
   may time out just before the acknowledgment arrives.  The acknowledg-
   ment time-out 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)

      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 stan-
      dard 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 itera-
      tion.  Initially, it is set to PPD.

      ATO is the adaptive time-out 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 average 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 time-out 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 con-
   stants, 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 divi-
   sion.  The above calculations are carried out each time an acknowl-
   edgment is received for a packet that was not retransmitted (no time-
   out occurs).



Valencia                    expires May 1997                    [Page 72]

INTERNET DRAFT                                             December 1996


A.2 Congestion Control: Adjusting for Time-Out

   This section describes how the calculation of ATO is modified in the
   case where a time-out does occur.  When a time-out occurs, the time-
   out value should be adjusted rapidly upward.  Although L2TP payload
   packets are not retransmitted when a time-out occurs, the time-out
   should be adjusted up toward a maximum limit.  To compensate for
   shifting internetwork time delays, a strategy must be employed to
   increase the time-out 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 time-out, 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 time-out calculations, for an interval in which a
   time-out occurs, the new time-out interval ATO is calculated as:

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

   In this modified calculation of ATO, only the two values that con-
   tribute to ATO and that are stored for the next iteration are calcu-
   lated.  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 time-out gain factor for RTT, is suggested.

Appendix B:  Acknowledgment Time-Out and Window Adjustment

B.1 Initial Window Size

   Although each side has indicated the maximum size of its receive win-
   dow, it is recommended that a slow start method be used to begin
   transmitting data.  The initial 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 window
   size.  As the receiver successfully digests each window, the window
   size on the transmitter is bumped up by one packet until the maximum
   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 time-out does occur on a packet, the sender adjusts the size
   of the transmit window down to one half its value when it failed.



Valencia                    expires May 1997                    [Page 73]

INTERNET DRAFT                                             December 1996


   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 time-out, the transmit window size is increased by one
   packet until it reaches the maximum window size that was sent by the
   other side when the call was connected.  As stated earlier, no
   retransmission is done on a time-out.  After a time-out, the trans-
   mission resumes with the window starting at one half the size of the
   transmit window when the time-out occurred and adjusting upward by
   one each time the transmit window is filled with packets that are all
   acknowledged without time-outs.

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
   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 addi-
   tion, they may be used to handle out-of-order arrival of packets.  A
   simple L2TP client would simply discard any packet other than a
   packet with a sequence greater than that last received; if packets 1,
   2, 3 arrived as 1, 3, 2, this would result in packet 2 being dis-
   carded.

   Such behavior does not affect the L2TP protocol itself, but signifi-
   cantly improved throughput in such environments may be attained by
   queueing 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 aliasing.

   An implementation which queues packets in this way must also employ
   an algorithm for deciding that a given sequence number corresponds to
   a packet which is lost, rather than one which is out of order but
   still in transit.  Such a decision would likely be based upon timing,
   buffering conditions, and packet arrival characteristics.  The
   details of such a tradeoff are outside the scope of this specifica-
   tion, but it is recommended a packet should be afforded an interval
   at least twice the estimated RTT from the L2TP peer.

Appendix D: Transport Layer Adaptive Time-outs and Window Adjustment

   Appendixes A, B, and C dealt 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



Valencia                    expires May 1997                    [Page 74]

INTERNET DRAFT                                             December 1996


   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 retransmit-
   ted by the L2TP Transport Layer.  Thus, the main topic of this
   Appendix is how to adapt the example adaptive time-out algorithm of
   Appendix A to the Control Session Transport Layer.

   There are two main differences between the Control Session and pay-
   load 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 deter-
   mined.  The former really doesn't affect the algorithm at all, except
   that upon a time-out, retransmission of unacknowledged control mes-
   sages 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 sug-
   gested 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 configur-
   ing a single fixed initial PPD estimate to be used for all possible
   peers will probably provide adequate results.  This fudge factor
   should probably be at least 0.5 second.





















Valencia                    expires May 1997                    [Page 75]


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