view Side-By-Side changes

PPP
Network Working Group                                     W. M. Townsley
Internet-Draft                                               A. Valencia
INTERNET DRAFT                                              Cisco Systems
Category: Internet Draft                             K. Hamzeh, Standards Track                                  cisco Systems
<draft-ietf-pppext-l2tp-13.txt>                                A. Rubens
Title: draft-ietf-pppext-l2tp-12.txt
                                                   Ascend Communications
Date: October 1998                                T. Kolar, M. Littlewood
                                                           W. M. Townsley
                                                            Cisco Systems
                                                                J. Taarud
                                                 Copper Mountain Networks
                                                              G. S. Pall
                                                                 G. Zorn
                                                   Microsoft Corporation
                                                               B. Palter
                                                          Network Alchemy
                                                              W. Verthein
                                                         3COM Corporation
                                                        Redback Networks
                                                           February 1999


                  Layer Two Tunneling Protocol "L2TP"


Status of this Memo

   This document is an Internet-Draft. Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts. Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months.  Internet-Drafts months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is not appropriate inappropriate to use Internet-
   Drafts Internet-Drafts as reference
   material or to cite them other than as a
   ``working draft'' or ``work in progress.'' progress''.

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.ietf.org, nic.nordu.net, ftp.nisc.sri.com, ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
   ftp.isi.edu (US West Coast), or
   munnari.oz.au.

Abstract

   Virtual dial-up allows many separate munnari.oz.au (Pacific Rim).

   The distribution of this memo is unlimited.  It is filed as <draft-
   ietf-pppext-l2tp-13.txt> and autonomous protocol domains expires August 8, 1999.  Please send
   comments to share common access infrastructure including modems, Access
   Servers, and ISDN routers.  RFC 1661 specifies multi-protocol dial-up
   via PPP [1]. the L2TP mailing list (l2tp@ipsec.org).

Abstract

   This document describes the Layer Two Tunneling Protocol (L2TP) which permits (L2TP).  RFC
   1661 specifies multi-protocol access via PPP [RFC1661].  L2TP
   facilitates the tunneling of the link layer (i.e.,
   HDLC, async HDLC) of PPP.  Using such tunnels, it PPP packets across an intervening
   network in a way that is as transparent as possible to
   divorce the location of the initial dial-up server from the location
   at which the dial-up protocol connection is terminated both end-users
   and access to
   the network provided.








Valencia                   expires June 1999 applications.




Townsley, et al.            Standards Track                     [Page 1]


INTERNET DRAFT                                              October 1998                    L2TP                     February 1999


Table of Contents

   1.0   Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   Conventions  . . . . . . . . . . . . . . . . . . . . . . .  4
   1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.0   Problem Space Overview   Topology . . . . . . . . . . . . . . . . . .  6
   2.1   Initial Assumptions . . . . . . .  7
   3.0   Protocol Overview  . . . . . . . . . . . .  6
   2.2   Topology . . . . . . . .  8
   3.1   L2TP Header Format . . . . . . . . . . . . . . . . .  7
   2.3   Providing Virtual Dial-up Services--a walk-through . . .  9
   3.2   Control Message Types  .  7
   3.0   Service Model Issues . . . . . . . . . . . . . . . . . 11
   4.0   Control Message Attribute Value Pairs  . .  9
   3.1   Security . . . . . . . . 12
   4.1   AVP Format . . . . . . . . . . . . . . . . . 10
   3.2   Address Allocation . . . . . . . 12
   4.2   Hiding of AVP Values . . . . . . . . . . . . . 10
   3.3   Authentication . . . . . . 13
   4.3   AVP Summary  . . . . . . . . . . . . . . . . 10
   3.4   Accounting . . . . . . . 15
   4.3.1 AVPs Applicable To All Control Messages  . . . . . . . . . 16
   4.3.2 Result and Error Codes . . . . . . . . 11
   4.0   Protocol Overview . . . . . . . . . . 17
   4.3.3 Control Connection Management AVPs . . . . . . . . . . 11
   4.1   Control Message Overview . . 19
   4.3.4 Call Management AVPs . . . . . . . . . . . . . . . 13
   4.2   Payload Packet Overview . . . . 25
   4.3.5 Proxy LCP and Authentication AVPs  . . . . . . . . . . . . 31
   4.3.6 Call Status AVPs . 13
   4.3   Flow Control . . . . . . . . . . . . . . . . . . . . 36
   5.0   Protocol Operation . . . 16
   5.0   Message Format and Protocol Extensibility  . . . . . . . . 18
   5.1   AVP . . . . . . . . . . 39
   5.1   Control Connection Establishment . . . . . . . . . . . . . 39
   5.1.1 Tunnel Authentication  . . . . 18
   5.2   Control Message Format . . . . . . . . . . . . . . 40
   5.2   Session Establishment  . . . . 20
   5.3   Payload Message Format . . . . . . . . . . . . . . 40
   5.2.1 Incoming Call Establishment  . . . . 21
   5.4   Control Message Types . . . . . . . . . . . 40
   5.2.2 Outgoing Call Establishment  . . . . . . . 22
   5.5   AVP Summary . . . . . . . . 41
   5.3   Forwarding PPP Frames  . . . . . . . . . . . . . . . 23
   5.6   Result and Error Code Summary . . . 41
   5.4   Using Sequence Numbers on the Data Channel . . . . . . . . 42
   5.5   Keepalive (Hello)  . . . 25
   5.7   Hiding of AVP values . . . . . . . . . . . . . . . . . 42
   5.6   Session Teardown . . 27
   6.0   Control Connection Protocol Specification . . . . . . . . 30
   6.0.1   Control Connection Collision . . . . . . . . . . . 43
   5.7   Control Connection Teardown  . . . 30
   6.0.2   Reliable Delivery of Control Messages . . . . . . . . . 30
   6.0.3   Control Message Format . . . 43
   5.8   Reliable Delivery of Control Messages  . . . . . . . . . . 43
   6.0   Control Connection Protocol Specification  . . . . 31
   6.1   Start-Control-Connection-Request . . . . 45
   6.1   Start-Control-Connection-Request (SCCRQ) . . . . . . . . . 31 45
   6.2   Start-Control-Connection-Reply (SCCRP) . . . . . . . . . . . . . . 37 46
   6.3   Start-Control-Connection-Connected (SCCCN) . . . . . . . . . . . . 41 46
   6.4   Stop-Control-Connection-Notification (StopCCN) . . . . . . . . . . . 42 47
   6.5   Hello (HELLO)  . . . . . . . . . . . . . . . . . . . . . . . . . . 43 47
   6.6   Outgoing-Call-Request  . . .   Incoming-Call-Request (ICRQ) . . . . . . . . . . . . . . . 44 48
   6.7   Outgoing-Call-Reply  . . .   Incoming-Call-Reply (ICRP) . . . . . . . . . . . . . . . . 49 48
   6.8   Outgoing-Call-Connected  . . .   Incoming-Call-Connected (ICCN) . . . . . . . . . . . . . . 50 49
   6.9   Incoming-Call-Request  . . .   Outgoing-Call-Request (ICRQ) . . . . . . . . . . . . . . . 53 49
   6.10   Incoming-Call-Reply . . .  Outgoing-Call-Reply (ICRP) . . . . . . . . . . . . . . . . 57 50
   6.11   Incoming-Call-Connected . . .  Outgoing-Call-Connected (OCCN) . . . . . . . . . . . . . . 58 50
   6.12  Call-Disconnect-Notify (CDN) . . . . . . . . . . . . . . . . . 65 51
   6.13  WAN-Error-Notify (WEN) . . . . . . . . . . . . . . . . . . . . 67 51
   6.14  Set-Link-Info (SLI)  . . . . . . . . . . . . . . . . . . . . . . 68 52
   7.0   Control Connection State Machines  . . . . . . . . . . . . 69 52
   7.1   Control Connection Protocol Operation  . . . . . . . . . . 70 52



Townsley, et al.            Standards Track                     [Page 2]


INTERNET DRAFT                    L2TP                     February 1999


   7.2   Control Connection States  . . . . . . . . . . . . . . . . 70 52
   7.2.1 Control Connection Establishment . . . . . . . . . . . . 70 . 53
   7.3   Timing considerations  . . . . . . . . . . . . . . . . . . 72 55
   7.4   Incoming Calls . . . . . . . . . . . . . . . . . . . . . . 72 55
   7.4.1 LAC Incoming Call States . . . . . . . . . . . . . . . . 72 . 56
   7.4.2 LNS Incoming Call States . . . . . . . . . . . . . . . . 74 . 57
   7.5   Outgoing calls . . . . . . . . . . . . . . . . . . . . . . 74 58
   7.5.1 LAC Outgoing Call States . . . . . . . . . . . . . . . . 75



Valencia                   expires June 1999                     [Page 2]

INTERNET DRAFT                                              October 1998 . 59
   7.5.2 LNS Outgoing Call States . . . . . . . . . . . . . . . . 76 . 60
   7.6   Tunnel Disconnection . . . . . . . . . . . . . . . . . . . 77 61
   8.0   L2TP Over Specific Media . . . . . . . . . . . . . . . . . 77 62
   8.1   IP/UDP . . . . .   L2TP over UDP/IP . . . . . . . . . . . . . . . . . . . . . 77 62
   8.2   IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 63
   9.0   Security Considerations  . . . . . . . . . . . . . . . . . 79 64
   9.1   Tunnel Endpoint Security . . . . . . . . . . . . . . . . . 79 64
   9.2   Client Security  . . . . . . . . . . . . . . . . . . . . . 79
   9.3   Proxy PPP Authentication . . . . . . . . . . . . . . . . . . . 80 64
   10.0  IANA Considerations  . . . . . . . . . . . . . . . . . . . 80 65
   10.1  AVP Attribute Type Values  . . . . . . . . . . . . . . . . 80 65
   10.2  Message type values AVP Values . . . . . . . . . . . . . . . . . . . 80
   10.3   Result code values . 65
   10.3  Result Code AVP Values . . . . . . . . . . . . . . . . . . 80 65
   10.4  Framing Capabilities & Bearer Capabilitities Capabilities . . . . . . . 80 . 65
   10.5  Proxy Authen Type values  . AVP Values . . . . . . . . . . . . . . . 81 66
   10.6  AVP Header bits . . . . . Bits  . . . . . . . . . . . . . . . . 81
   10.7   Message (Payload and Control) Header bits . . . . . . . . 81 66
   11.0   Acknowledgments  References . . . . . . . . . . . . . . . . . . . . . 81
   12.0   Contacts . . . 66
   12.0  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 81 68
   13.0   References  . .  Author's Addresses . . . . . . . . . . . . . . . . . . . . . 82 68
   Appendix A:   Acknowledgment Time-Outs . . . . . . . . . . . . . 83
   Appendix B:   Acknowledgment Time-Out Control Channel Slow Start and Window Adjustment  . . 87
   Appendix C:   Handling of out-of-order packets . . Congestion
               Avoidance  . . . . . . . 88
   Appendix D:   Transport Layer Adaptive Time-Outs
                 and Window Adjustment . . . . . . . . . . . . . . 89 69
   Appendix E: B: Control Message Examples of L2TP sequence numbering . . . . . . . 90
   Appendix F:   Flow Control and Sequencing Negotiation . . . . . 93 . . 70

1.0 Introduction

   The traditional dial-up network service on the Internet is

   PPP [RFC1661] defines an encapsulation mechanism for
   registered IP addresses only.  A new class transporting
   multiprotocol packets across layer 2 (L2) point-to-point links.
   Typically, a user obtains a L2 connection to a Network Access Server
   (NAS) using one of virtual dial-up
   application which allows multiple protocols a number of techniques (e.g., dialup POTS, ISDN,
   ADSL, etc.)  and unregistered IP
   addresses is also desired then runs PPP over that connection. In such a
   configuration, the L2 termination point and PPP session endpoint
   reside on the Internet.  Examples of this class of
   network application are support for privately addressed IP, IPX, same physical device (i.e., the NAS).

   L2TP extends the PPP model by allowing the L2 and
   AppleTalk dial-up via PPP across existing Internet infrastructure.

   The support of these multi-protocol virtual dial-up applications is
   of significant benefit endpoints to end users, enterprises, and Internet
   Service providers as it allows the sharing of very large investments
   in
   reside on different devices interconnected by a packet-switched
   network.  With L2TP, a user has an L2 connection to an access
   concentrator (e.g., modem bank, ADSL DSLAM, etc.), and core infrastructure and allows local calls the
   concentrator then tunnels individual PPP frames to be used.
   It also the NAS. This
   allows existing investments in non-IP protocol applications the actual processing of PPP packets to be supported in a secure manner while still leveraging the access
   infrastructure of the Internet.

   It is divorced from the purpose
   termination of this document to identify the issues encountered
   in integrating multi-protocol dial-up services into an existing
   Internet Service Provider's Point of Presence (hereafter referred to



Valencia                   expires June 1999 L2 circuit.




Townsley, et al.            Standards Track                     [Page 3]


INTERNET DRAFT                                              October 1998


   as ISP and POP, respectively), and to describe the                    L2TP protocol                     February 1999


   One obvious benefit of such a separation is that instead of requiring
   the L2 connection terminate at the NAS (which may require a long-
   distance toll charge), the connection may terminate at a (local)
   circuit concentrator, which permits then extends the leveraging of existing access protocols.

   This protocol logical PPP session over
   a shared infrastructure such a frame relay circuit or the Internet.
   From the user's perspective, there is no functional difference
   between having the L2 circuit terminate in a NAS directly or using
   L2TP.

   L2TP may also solve the "multilink multilink hunt-group splitting" splitting problem.
   Multilink PPP [9], often used to aggregate ISDN B channels, [RFC1990] requires that all channels composing a
   multilink bundle be grouped at a single
   NAS.  Because L2TP makes Network Access Server (NAS).
   Due to its ability to project a PPP session terminate at to a location other than
   the point at which the session it was physically received, it L2TP can be used to
   make all channels terminate at a single NAS, allowing NAS. This allows multilink
   operation even when the physical calls are spread across distinct physical NAS's.

1.1 Conventions

   The following language conventions are used in
   NASs.

   This document defines the necessary control protocol for on-demand
   creation of tunnels between two nodes and the items accompanying
   encapsulation for multiplexing multiple, tunneled PPP sessions.

1.1 Specification of
   specification in this document: Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [15]. [RFC2119].

1.2 Terminology

   Analog Channel

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

   Control Connection

      A control connection operates in-band over

   Attribute Value Pair (AVP)

      The variable length concatenation of a tunnel to control unique Attribute
      (represented by an integer) and a Value containing the actual
      value identified by the attribute. Multiple AVPs make up Control
      Messages which are used in the establishment, release, and maintenance of sessions maintenance, and
      teardown of the
      tunnel itself. tunnels.

   Call

      A connection or (or attempted connection connection) between two terminal
      endpoints. a Remote System and
      LAC.  For example, a telephone call through the PSTN PSTN. A Call
      (Incoming or Outgoing) which is successfully established between
      two modems. (See also: Session).

   CHAP

      Challenge Authentication Protocol, a PPP cryptographic



Townsley, et al.            Standards Track                     [Page 4]


INTERNET DRAFT                    L2TP                     February 1999


      Remote System and LAC results in a corresponding L2TP Session
      within a previously established Tunnel between the LAC and LNS.
      (See also: Session, Incoming Call, Outgoing Call).

   Called Number

      An indication to the receiver of a call as to what telephone
      number the caller used to reach it.

   Calling Number

      An indication to the receiver of a call as to the telephone number
      of the caller.

   CHAP

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

   CLID

      Calling Line ID, an indication to the receiver of

   Control Connection

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

   Control Messages

      Control messages are exchanged between LAC and LNS pairs,



Valencia                   expires June 1999                     [Page 4]

INTERNET DRAFT                                              October 1998
      operating 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. Also
      referred to as a dial-up or Virtual dial-up client.

   DNIS

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

   Digital Channel

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

   EAP

      Extensible Authentication Protocol, a framework for

   DSLAM

      Digital Subscriber Line (DSL) Access Module. A network device used
      in the deployment of DSL service. This is typically a family concentrator
      of
      PPP authentication protocols, including cleartext,
      challenge/response, and arbitrary dialog sequences. individual DSL lines located in a central office (CO) or local
      exchange.

   Incoming Call

      A Call received at an LAC to be tunneled to an LNS (see Call,
      Outgoing Call).



Townsley, et al.            Standards Track                     [Page 5]


INTERNET DRAFT                    L2TP                     February 1999


   L2TP Access Concentrator (LAC)

      A Network Access Server (NAS) or host co-located with a PPP end
      system capable node that acts as one side of handling an L2TP tunnel endpoint and is a
      peer to the L2TP protocol. Network Server (LNS).  The LAC needs only
      implement the media over which L2TP is to operate sits between an
      LNS and a remote system and forwards packets to pass traffic and from each.
      Packets sent from the LAC to one or more LNS's.  It may tunnel any the LNS requires tunneling with the
      L2TP protocol carried within
      PPP. as defined in this document.  The LAC is connection from
      the initiator of incoming calls and LAC to the receiver
      of outgoing calls. remote system is either local (see: Client LAC) or
      a PPP link.

   L2TP Network Server (LNS)

      An LNS operates on any platform capable

      A node that acts as one side of PPP termination. an L2TP tunnel endpoint and is a
      peer to the L2TP Access Concentrator (LAC).  The LNS handles is the server side
      logical termination point of a PPP session that is being tunneled
      from the L2TP protocol.  Since L2TP
      relies only on remote system by the single media over which L2TP tunnels arrive, LAC.

   Management Domain (MD)

      A network or networks under the LNS may have only control of a single LAN
      administration, policy or WAN interface, yet still system. For example, an LNS's Management
      Domain might be
      able to terminate calls arriving at any the corporate network it serves. An LAC's full range of PPP
      interfaces (async, synchronous ISDN, V.120, etc.).  The LNS is
      Management Domain might be the
      initiator of outgoing calls Internet Service Provider that owns
      and the receiver of incoming calls. manages it.

   Network Access Server (NAS)

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

   PAP

      Password Authentication Protocol, a simple PPP authentication
      mechanism in which a cleartext username and password are



Valencia                   expires June 1999                     [Page 5]

INTERNET DRAFT                                              October 1998


      transmitted to prove identity.

   POP

      An Internet Service Provider's Point of Presence.

   Quality of Service (QOS)

   Outgoing Call

      A given Quality Call placed by an LAC on behalf of Service level is sometimes required for a given
      user being tunneled between an LNS-LAC pair.  For this scenario, a
      unique L2TP tunnel LNS (see Call, Incoming
      Call).

   Peer

      When used in context with L2TP, peer refers to either the LAC or
      LNS. An LAC's Peer is created an LNS and encapsulated directly on top vice versa. When used in context
      with PPP, a peer is either side of the media providing PPP connection.

   POTS

      Plain Old Telephone Service.

   Remote System




Townsley, et al.            Standards Track                     [Page 6]


INTERNET DRAFT                    L2TP                     February 1999


      An end-system or router attached to a remote access network (i.e.
      a PSTN), which is either the indicated QOS. initiator or recipient of a call.
      Also referred to as a dial-up or virtual dial-up client.

   Session

      L2TP is connection-oriented. The LNS and LAC maintain state for
      each user Call that is attached to initiated or answered by an LAC.  A session An L2TP Session
      is created between the LAC and LNS when an end-to-end PPP
      connection is attempted established between a dial user Remote System and the LNS, or when an outbound call is initiated.  The datagrams LNS.
      Datagrams related to a session the PPP connection are sent over the tunnel Tunnel
      between the LAC and LNS. There is a one to one relationship
      between established L2TP Sessions and their associated Calls. (See
      also: Call).

   Tunnel

      A tunnel is defined by an LNS-LAC Tunnel exists between a LAC-LNS pair. The tunnel Tunnel consists of a
      Control Connection and zero or more L2TP Sessions. The Tunnel
      carries encapsulated PPP datagrams and Control Messages between
      the LAC and the LNS; many sessions can be
      multiplexed over a single tunnel.  A control connection operating
      in-band over the same tunnel controls the establishment, release,
      and maintenance of sessions and of the tunnel itself. A tunnel is
      sometimes referred to as a control connection. LNS.

   Zero-Length Body (ZLB) Message

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

2.0 Problem Space Overview

   In this section we describe in high level terms Topology

   The following diagram depicts a typical L2TP scenario. The goal is to
   tunnel PPP frames between the scope of the
   problem that will be explored in more detail in later sections.

2.1 Initial Assumptions

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

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

   +  End Remote System transparency: Neither the remote end system nor his



Valencia                   expires June 1999                     [Page 6]

INTERNET DRAFT                                              October 1998


   home site hosts should require any special software to use this
   service in a secure manner.

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

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

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

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

2.2 Topology

   Shown below is an LNS
   located at a generic Internet with Public switched Telephone
   Network (PSTN) access (i.e., async PPP via modems) and Integrated
   Services Digital Network (ISDN) access (i.e., synchronous PPP
   access).  Remote users (either async or ISDN PPP) will access the Home LAN as if they were dialed into the LAN.


















Townsley, et al.            Standards Track                     [Page 7]


INTERNET DRAFT                    L2TP Network Server (LNS),
   although their physical dial-up is via the ISP Network Access Server
   (acting as the LAC).


                                                          [LAN]                     February 1999


                                                    [Home LAN]
            [LAC Client]----------+                     |
                                   __________
                              ____|_____                +--[Host]
                             |          |               |
               [LAC]---------| Internet |-----[LNS]-----+
                 |           |__________|               |
            _____|_____                                 :
           |           |
           |  PSTN     |
        [User]--|  or ISDN
 [Remote]--|  Cloud    |
 [System]  |  Cloud           |                              [LAN]                            [Home LAN]
           |___________|                                |
                 |          ______________              +---[Host]
                 |         |              |             |
               [LAC]-------| Frame Relay  |---[LNS]-----+
                           | or ATM Cloud |             |
                           |______________|             :


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

   To motivate


   The Remote System initiates a PPP connection across the following discussion, this section walks through an
   example of what might happen when a Virtual dial-up client initiates
   access.



Valencia                   expires June 1999                     [Page 7]

INTERNET DRAFT                                              October 1998


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

   The remote user initiates a PPP connection PSTN Cloud to
   an ISP via either the
   PSTN or ISDN. LAC. The LAC accepts the connection and then tunnels the PPP link is
   established (L2TP also permits connection across the LAC Internet,
   Frame Relay, or ATM Cloud to check with an LNS after
   call indication prior whereby access to accepting the call. This a Home LAN is useful where
   DNIS or CLID information
   obtained. The Remote System is available in provided addresses from the incoming call
   notification).

   The ISP HOME LAN
   via PPP NCP negotiation. Authentication, Authorization and Accounting
   may now undertake a partial authentication of the end
   system/user.  Only the username field would be interpreted to
   determine whether provided by the Home LAN's Management Domain as if the user requires
   were connected to a Virtual dial-up service.  It is
   expected, but not required, that usernames will be structured (e.g.
   username@company.com).  Alternatively, the ISP Network Access Server directly.

   A LAC Client (a Host which runs L2TP natively) may maintain a
   database mapping users also participate
   in tunneling to services.  In the case Home LAN without use of Virtual dial-up,
   the mapping will name a specific endpoint, separate LAC. In this
   case, the LNS.

   Alternatively, Host containing the ISP may have LAC Client software already determined the target LNS
   from DNIS.  If the LNS is willing has a
   connection to accept tunnel creation without
   any authentication of the caller, the LAC may tunnel the public Internet. A "virtual" PPP connection without ever having communicated with the remote user.

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

   If no tunnel connection currently exists to then
   created and the desired LNS, one is
   initiated. local L2TP is designed LAC Client software creates a tunnel to be largely insulated from
   the details
   of LNS. As in the media over which above case, Addressing, Authentication,
   Authorization and Accounting will be provided by the tunnel is established; Home LAN's
   Management Domain.

3.0 Protocol Overview

   L2TP requires only
   that the tunnel media provide packet oriented point-to-point
   connectivity.  Obvious examples utilizes two types of such media messages, control messages and data
   messages. Control messages are UDP, Frame Relay
   PVC's, or X.25 VC's.

   Once the tunnel exists, an unused slot within used in the tunnel, a "Call
   ID", is allocated, establishment, maintenance
   and clearing of tunnels and calls. Data messages are used to
   encapsulate PPP frames being carried over the tunnel. Control
   messages utilize a connect indication is sent reliable Control Channel within L2TP to notify guarantee
   delivery (see section 5.1 for details). Data messages are not
   retransmitted when packet loss occurs.






Townsley, et al.            Standards Track                     [Page 8]


INTERNET DRAFT                    L2TP                     February 1999


   +-------------------+
   | PPP Frames        |
   +-------------------+    +-----------------------+
   | L2TP Data Messages|    | L2TP Control Messages |
   +-------------------+    +-----------------------+
   | L2TP Data Channel |    | L2TP Control Channel  |
   | (unreliable)      |    | (reliable)            |
   +------------------------------------------------+
   |      Packet Transport (UDP, FR, ATM, etc.)     |
   +------------------------------------------------+

   Figure 3.0 L2TP Protocol Structure

   Figure 3.0 depicts the LNS relationship of this new dial-up session.  The LNS either accepts PPP frames and Control
   Messages over the connection,
   or rejects it.  Rejection MUST include a result condition L2TP Control and MAY
   include Data Channels. PPP Frames are
   passed over an error indication, which may be displayed to the dial-up
   user, after unreliable Data Channel encapsulated first by an L2TP
   header and then a Packet Transport such as UDP, Frame Relay, ATM,
   etc. Control messages are sent over a reliable L2TP Control Channel
   which transmits packets in-band over the call should be disconnected.

   The initial connect notification may include the authentication
   information same Packet Transport.

   Sequence numbers are required to allow the LNS to authenticate the user be present in all control messages
   and
   decide are used to accept or decline provide reliable delivery on 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 [1] before initiating the tunnel, the
   initial connect notification may also include a copy of the LCP
   CONFREQ's sent in each direction which completed LCP negotiation.
   The LNS Control Channel.
   Data Messages 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.



Valencia                   expires June 1999                     [Page 8]

INTERNET DRAFT                                              October 1998


   If the LNS accepts the connection, it creates a "virtual interface"
   for PPP in a manner analogous sequence numbers 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 reorder packets and detect
   lost packets.

   All values are received at the POP, stripped of CRC,
   link framing, placed into their respective fields and transparency bytes, encapsulated sent in L2TP, and
   forwarded over the appropriate tunnel.

   The LNS accepts these frames, strips L2TP, and processes them as
   normal incoming frames
   network order (high order octets first).

3.1 L2TP Header Format

   L2TP packets for the appropriate interface control channel and protocol.
   The "virtual interface" behaves very much like data channel share a hardware interface,
   with the exception that the hardware in this common
   header format. In each case where a field is physically
   located at the ISP POP.  The other direction behaves analogously,
   with the LNS encapsulating the packet optional, its space does
   not exist in L2TP, and the LAC stripping
   L2TP before transmitting it out the physical interface to the remote
   user.

   At this point, message if the connectivity field 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 marked not present. This
   header is formatted:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T|L|x|x|S|x|O|P|x|x|x|x|  Ver  |          Length (opt)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tunnel ID           |           Session ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Ns (opt)          |             Nr (opt)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Offset Size (opt)        |    Offset pad... (opt)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3.1 L2TP Message Header



Townsley, et al.            Standards Track                     [Page 9]


INTERNET DRAFT                    L2TP                     February 1999


   The Type (T) bit indicates the remote user has become simply another dial-up
   client type of the LNS, client connectivity can now be managed using
   traditional mechanisms with respect message. It is set to further authorization,
   protocol access, 0 for a
   data message and packet filtering.

   Accounting can be performed at both 1 for a control message.

   If the LAC as well as Length (L) bit is 1, the LNS. Length field is present. 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 bit
   MUST be set to 1 for PPP
   clients can contain sufficient information control messages.

   The x bits are reserved for an LNS future extensions. All reserved bits MUST
   be set to authenticate 0 on outgoing messages and initialize its LCP state machine.  With these facilities, ignored on incoming messages.

   If 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 Sequence (S) bit is set to optimize connection setup, 1 the Ns and Nr fields are
   not intended present.
   The S bit MUST be set to deprecate any functions required by 1 for control messages.

   If the PPP
   specification.

3.0 Service Model Issues

   There are several significant differences between Offset (O) bit is 1, the standard
   Internet access service Offset Size field is present. The O
   bit MUST be set to 0 (zero) for control messages.

   If the Priority (P) bit is 1, this data message should receive
   preferential treatment in its local queuing and transmission.  LCP
   echo requests used as a keepalive for the Virtual dial-up service link, for instance, should
   generally be sent with respect this bit set to authentication, address allocation, authorization 1. Without it, a temporary
   interval of local congestion could result in interference with
   keepalive messages and accounting.
   The details unnecessary loss of the differences between these services and link. This feature is
   only for use with data messages. The P bit MUST be set to 0 for all
   control messages.

   Ver MUST be 2, indicating the
   problems presented by these differences are version of the L2TP data message header
   described below. in this document. The
   mechanisms used for Virtual Dial-up service are intended value 1 is reserved to coexist permit
   detection of L2F [RFC2341] packets should they arrive intermixed with
   L2TP packets. Packets received with more traditional mechanisms; it is intended that an ISP's POP
   can simultaneously service ISP clients as well as Virtual dial-up
   clients.






Valencia                   expires June 1999                     [Page 9]

INTERNET DRAFT                                              October 1998


3.1 Security

   For unknown Ver field MUST be
   discarded.

   The Length field indicates the Virtual dial-up service, total length of the ISP pursues authentication only
   to message in octets.

   Tunnel ID indicates the extent required to discover identifier for the user's apparent identity (and
   by implication, their desired LNS).  This may involve no more than
   detecting DNIS information when a call arrives, or may involve full
   LCP negotiation and initiation of PPP authentication.  As soon as the
   apparent identity is determined, a call request to the LNS is
   initiated with any authentication information gathered control connection. L2TP
   tunnels are named by the ISP. If
   the LNS receives proxy authentication information (see section 6.11),
   it SHOULD assume identifiers that have local significance only.
   That is, the PPP peer is in the authentication phase,
   awaiting an indication same tunnel will be given different Tunnel IDs by each
   end of success or failure.  The LNS completes the
   authentication by either accepting tunnel. Tunnel ID in each message is that of the call, or rejecting it.

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

3.2 Address Allocation

   For a traditional Internet service, IDs are selected and exchanged as
   Assigned Tunnel ID AVPs during the user typically accepts that creation of a tunnel.

   Session ID indicates the IP address may be allocated dynamically from identifier for a pool of ISP
   addresses.  This model often means session within a tunnel.
   L2TP sessions are named by identifiers that have local significance
   only. That is, the remote user has little or
   no access to their home network's resources, due to firewalls and
   other security policies applied same session will be given different Session IDs
   by each end of 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, session. Session ID in fact, can
   be RFC 1918 addresses, or non-IP addresses).  Because L2TP tunnels
   exclusively at each message is that of the frame layer,
   intended recipient, not the actual policies of such address
   management sender. Session IDs are irrelevant to correct Virtual dial-up service; for all
   purposes selected and
   exchanged as Assigned Session ID AVPs during the creation 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; a
   session.

   Ns indicates the first sequence number for this data or control message,



Townsley, et al.            Standards Track                    [Page 10]


INTERNET DRAFT                    L2TP                     February 1999


   beginning at
   the ISP, zero and the second incrementing by one (modulo 2**16) for each
   message sent. See Section 5.8 and optional third at 5.4 for more information on using
   this field.

   Nr indicates the LNS.

   The ISP uses DNIS, CLID, or a username to determine that a Virtual
   dial-up service is required and initiates sequence number expected in the tunnel connection next control message
   to
   the appropriate LNS.  Once a tunnel be received.  Thus, Nr is established, The ISP NAS
   allocates a new Call ID and initiates a session by forwarding set to the
   gathered authentication information.

   The LNS undertakes Ns of the second phase last in-order
   message received plus one (modulo 2**16). In data messages, Nr is
   reserved and, if present (as indicated by deciding whether or not to
   accept the call.  The call start indication may include CHAP, PAP,
   EAP, or textual authentication information.  Based S-bit), MUST be ignored
   upon receipt. See section 5.8 for more information on using this
   information,
   field in control messages.

   The Offset Size field, if present, specifies the LNS may accept number of octets
   past the call request, or may reject it
   (for instance, it was a PAP request and L2TP header at which the username/password are
   found payload data is expected to be incorrect).

   Once start.
   Actual data within the call offset padding is accepted, undefined. If the LNS offset
   field is free to pursue a third phase of



Valencia                   expires June 1999                    [Page 10]

INTERNET DRAFT                                              October 1998


   authentication at present, the PPP layer.  These activities are outside L2TP header ends after the
   scope last octet of this specification, but might include an additional cycle the
   offset padding.

3.2 Control Message Types

   The Message Type AVP (see section 4.3.1) defines the type of
   LCP authentication, proprietary message
   being sent. L2TP defines the following control message types:

      Control Connection Management


      0  (reserved)

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

   Call Management

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

   Error Reporting

      15 (WEN)      WAN-Error-Notify



Townsley, et al.            Standards Track                    [Page 11]


INTERNET DRAFT                    L2TP                     February 1999


   PPP extensions, or textual challenges
   carried via a TCP/IP TELNET session.

3.4 Accounting

   It is Session Control

      16 (SLI)      Set-Link-Info

4.0 Control Message Attribute Value Pairs

   To maximize extensibility while still permitting interoperability, a requirement that both the LAC
   uniform method for encoding message types and the LNS bodies is used
   throughout L2TP.  This encoding will be capable termed AVP (Attribute-Value
   Pair) in the remainder of
   providing accounting data and hence both may count packets, octets
   and connection start and stop times.

   Since Virtual dial-up this document.

4.1 AVP Format

   Each AVP is an access service, accounting of connection
   attempts (in particular, failed connection attempts) 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| rsvd  |      Length       |           Vendor ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Attribute Type        |        Attribute Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       [until Length is of
   significant interest. reached]...                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The LNS can reject new connections based on
   the authentication information gathered by first six bits are a bit mask, describing the LAC, with
   corresponding logging.  For cases where general attributes
   of the LNS accepts AVP.

   Two bits are defined in this document, the
   connection and then continues remaining are reserved for
   future extensions.  Reserved bits MUST be set to 0. An AVP received
   with further authentication, the LNS
   might subsequently disconnect the client.  For such scenarios, the
   disconnection indication back a reserved bit set to 1 MUST be treated as an unrecognized AVP.

   Mandatory (M) bit: Controls the LAC may also include a reason.

   Because behavior required of an
   implementation which receives an AVP which it does not recognize. If
   the LNS can decline a connection based M bit is set on the authentication
   information collected by the LAC, accounting can easily draw a
   distinction between an unrecognized AVP within a series of failed call attempts and message associated
   with a series of
   brief successful connections.  Lacking this facility, particular session, the LNS must
   always accept connection requests, and would need to exchange a
   number of PPP packets session associated with the remote system.  Note that the LNS
   could use this information to decide to accept message
   MUST be terminated. If the connection (which
   protects against most invalid connection attempts) while still
   insisting M bit is set on running its own CHAP authentication (for instance, to
   protect against CHAP replay attacks).

4.0 Protocol Overview

   There are two parallel components of L2TP operating over an unrecognized AVP within
   a given
   tunnel: control messages between each LAC-LNS pair, and payload
   packets between message associated with the same LAC-LNS pair.  The latter are used to
   transport L2TP encapsulated PPP packets for user overall tunnel, the entire tunnel (and
   all sessions between within) MUST be terminated. If the
   pair.

   Two fields important to M bit is not set, an
   unrecognized AVP MUST be ignored.

   Hidden (H) bit: Identifies the operation hiding of L2TP are the Nr (Next
   Received) and Ns (Next Sent) fields which are always present data in
   control messages, and are optionally present in payload packets.  A
   single sequence number state is maintained for all control messages,
   and a distinct state is maintained for the payload Attribute Value
   field of each user
   session within the tunnel. The Sequence number starts at 0, Each
   subsequent packet is sent with an AVP.  This capability can be used to avoid the next increment passing of the sequence
   number.  The sequence number is thus a free running counter
   represented modulo 65536. The sequence number
   sensitive data, such as user passwords, as cleartext in an AVP.
   Section 4.2 describes the header of a
   received packet is considered less   than or equal to procedure for performing AVP hiding.

   Length: Encodes the last
   received number if its value lies in the range of octets (including the last received
   number and the preceeding 32767 values, inclusive.  For example, if
   the last received sequence number was 15, then packets with sequence
   numbers 0 through 15, as well as 32753 through 65536, would be
   considered less than or equal to, Overall Length
   and would bitmask fields) contained in this AVP. The Length may be silently discarded.



Valencia                   expires June 1999



Townsley, et al.            Standards Track                    [Page 11] 12]


INTERNET DRAFT                                              October 1998


   Otherwise it would be accepted.

   In this document, the sequence number state for a control connection
   and each user session is represented for clarity in the following
   discussions by distinct pairs of state variables, Sr and Ss.  Sr
   represents                    L2TP                     February 1999


   calculated as 6 + the value length of the next in-sequence message expected to be
   received for a given session by a peer. Ss represents the sequence
   number to be placed Attribute Value field in the Ns octets.
   The field of the next message sent for itself is 10 bits, permitting a
   given session by the sending peer.  Each state is initialized such
   that the first message sent and the first message expected to be
   received for each session has an Ns value maximum of 0.  This corresponds to
   initializing Ss and Sr 1023 octets of
   data in both peers to 0 for each new session.

   As messages are sent for a given session, Nr is set in these messages
   to reflect one more than the Ns value single AVP. The minimum Length of the highest (modulo 2**16)
   in-order message received for that session; if sent before any packet an AVP is received Nr will be 0, indicating that 6. If the peer expects
   length is 6, then the next
   new Ns Attribute Value field is absent.

   Vendor ID: The IANA assigned "SMI Network Management Private
   Enterprise Codes" [RFC1700] value.  The value received 0, corresponding to be 0.  When a non-ZLB message
   IETF adopted attribute values, is received used for all AVPs defined within
   this document. Any vendor wishing to implement their own L2TP
   extensions can use their own Vendor ID along with an Ns value private Attribute
   values, guaranteeing that they will not collide with any other
   vendor's extensions, nor with future IETF extensions. Note that matches there
   are 16 bits allocated for the session's current Sr value, Sr is
   incremented by 1 (modulo 2**16). It is important Vendor ID, thus limiting this feature
   to note that, for
   both control and payload sessions, Sr is not modified if a message is
   received the first 65,535 enterprises.

   Attribute Type: A 2 octet value with a value of Ns greater than unique interpretation across
   all AVPs defined under a given Vendor ID.

   Attribute Value: This is the current Sr actual value
   (exceptions to this rule being the permitted handling of out-of-order
   payload packets as indicated by the "simple receiver" discussed in Appendix C Vendor
   ID and
   handling Attribute Type. It follows immediately after the Attribute
   Type field, and runs for the remaining octets indicated in the Length
   (i.e., Length minus 6 octets of payload packets with header). This field is absent if the R
   Length is 6.

4.2 Hiding of AVP Attribute Values

   The H bit set).  For in the control
   session, retransmission header of outgoing messages should eventually
   provide each AVP provides a mechanism to indicate
   to the receiving peer with the expected message.  For payload
   sessions, however, lost messages are never retransmitted so a
   mechanism involving whether the use contents of the "Reset Sr" (R bit) indicator AVP are hidden or
   present in an
   outgoing message is cleartext.  This feature can be used to update the peer's value of Sr to hide sensitive
   control message data such as user passwords or user IDs.

   The H bit MUST only be set if a shared secret exists between the
   value of Ns contained in LAC
   and LNS. The shared secret is the message.  See Sec.  4.2 same secret that is used for details of
   this mechanism.

   Every time tunnel
   authentication (see Section 5.1.1).  If the H bit is set in any
   AVP(s) in a peer sends given control message, a non-ZLB Random Vector AVP must also be
   present in the message it increments its
   corresponding Ss value for that session by 1 (modulo 2**16).  This
   increment takes place after and MUST precede the current Ss first AVP having an H bit
   of 1.

   Hiding an AVP value is copied to Ns done in
   the message several steps. The first step is to be sent.  Outgoing messages always include
   take the current length and value fields of Sr for the corresponding session in their Nr field.

   A message (control or payload) with a zero-length body indicates that the packet is only used to communicate Nr original (cleartext) AVP and Ns fields.  The Nr and
   Ns fields are filled in
   encode them into a Hidden AVP Subformat as above, but follows:










Townsley, et al.            Standards Track                    [Page 13]


INTERNET DRAFT                    L2TP                     February 1999


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Length of Original Value    |   Original Attribute Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ...                          |             Padding ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length of Original Attribute Value:  This is length of the sequence number state, Ss, Original
   Attribute Value to be obscured in octets. This is not incremented.  Thus a ZLB message sent after a non-ZLB message
   will contain a new Ns value while a non-ZLB message sent after a ZLB
   message will contain necessary to
   determine the same value original length of Ns as the preceding zero- Attribute Value which is lost
   when the additional Padding is added.

   Original Attribute Value:  Attribute Value that is to be obscured.

   Padding:  Random additional octets used to obscure length message. Unless of the Rbit (Reset Sr)
   Attribute Value that is set, a peer receiving a
   zero-length message does not update its Sr variable.

   Upon receipt being hidden.

   To mask the size of an in-order non-ZLB message, the receiving peer must
   acknowledge data being hidden, the message by sending back resulting subformat
   MAY be padded as shown above. Padding does NOT alter the updated value of Sr placed
   in the Nr field Length of Original Attribute Value field, but does alter the next outgoing message.  This updated Sr value can
   be piggybacked in the Nr field
   length of any non-ZLB outgoing messages that the peer may happen to send back.




Valencia                   expires June 1999                    [Page 12]

INTERNET DRAFT                                              October 1998 resultant AVP that is being created. For example, If the peer does not have a message an
   Attribute Value to transmit for a short period be hidden is 4 octets in length, the unhidden AVP
   length would be 10 octets (6 + Attribute Value length). After hiding,
   the length of
   time after receiving a non-ZLB message then it should send a ZLB
   message containing the latest values AVP will become 6 + Attribute Value length + size
   of Sr and Ss, as described
   above. the Length of Original Attribute Value field + Padding. Thus, if
   Padding is 12 octects, the AVP length will be 6 + 4 + 2 + 12 = 24
   octets.

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

      + the 2 octet Attribute number of the AVP
      + the shared secret
      + an arbitrary length random vector

   The suggested value for of the random vector used in this time interval hash is 1/4 passed in the
   receiving peer's
   value field of Round-Trip-Time (RTT - see Appendix A), if
   it computes RTT, or a maximum of 1/2 of its fixed timeout interval
   otherwise. Random Vector AVP. This timeout should provide a reasonable opportunity for Random Vector AVP must be
   placed in the receiving peer to obtain a payload message destined for its peer,
   upon which the ACK of by the received message can be piggybacked.

   This timeout value should sender before any hidden AVPs. The same
   random vector may be treated as a suggested maximum; an
   implementation could make this timeout quite small without adversely
   affecting used for more than one hidden AVP in the protocol.  To provide same
   message. If a different random vector is used for better throughput, the
   receiving peer should skip this timeout entirely and send hiding of
   subsequent AVPs then a ZLB
   message immediately new Random Vector AVP must be placed in the case where its receive window fills and it
   has no queued data
   command message before the first AVP to send for this connection or which it can't send
   queued data because the transmit window applies.

   The MD5 hash value is closed.

   A suggested implementation then XORed with the first 16 octet (or less)
   segment of this timer is as follows:  Upon
   receiving a non-ZLB message, the receiver starts a timer that will
   expire Hidden AVP Subformat and placed in the recommended time interval.  A variable, Lr (Last Nr
   value sent), Attribute Value
   field of the Hidden AVP.  If the Hidden AVP Subformat is used by less than 16
   octets, the Subformat is transformed as if the transmitter Attribute Value field
   had been padded to store 16 octets before the last value sent XOR, but only the actual



Townsley, et al.            Standards Track                    [Page 14]


INTERNET DRAFT                    L2TP                     February 1999


   octets present in the Nr field of a transmitted payload message for this connection.
   Upon expiration Subformat are modified, and the length of this timer, Sr the
   AVP is compared to Lr and, if they are not equal, altered.

   If the Subformat is longer than 16 octets, a ZLB ACK second one-way MD5 hash
   is issued. If they are equal, then no ACK's are
   outstanding and no action needs to be taken.

   This timer should not be reinitialized if calculated over a new message stream of octets consisting of the shared secret
   followed by the result of the first XOR.  That hash is received
   while it XORed with the
   second 16 octet (or less) segment of the Subformat and placed in the
   corresponding octets of the Value field of the Hidden AVP.

   If necessary, this operation is active since such messages will be acknowledged when repeated, with the
   timer expires.  This ensures that periodic ACK's are issued shared secret used
   along with a
   maximum period equal each XOR result to generate the recommended timeout interval. This
   interval should be short enough next hash to not cause false acknowledgment
   timeouts at XOR the transmitter when payload messages are being sent in
   one direction only.  Since such ACK's are being sent on what would
   otherwise be an idle data path, their affect on performance should be
   small, if not negligible.

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

   4.1 Control Message Overview

      Before PPP tunneling can occur between an LAC and LNS, control
      messages must be exchanged between them.  Control messages are
      exchanged over the same tunnel which will be used to forward
      payload data once L2TP call control and management information
      have been passed. value with.

   The control messages are responsible for
      establishment, management, and release of sessions carried through
      the tunnel, as well as status on hiding method was adapted from RFC 2138 [RFC2138] which was taken
   from from the tunnel itself.  It is "Mixing in the
      means by which an LNS is notified of an incoming call at an
      associated LAC, as well as Plaintext" section in the means book "Network
   Security" by which an LAC is instructed
      to place an outgoing call. Kaufman, Perlman and Speciner [KPS].  A tunnel may be established by either an LAC (for incoming calls)
      or an LNS (for outgoing calls).  Following the establishment detailed
   explanation of



Valencia                   expires June 1999                    [Page 13]

INTERNET DRAFT                                              October 1998 the tunnel, method follows:

   Call the LNS and LAC configure shared secret S, the tunnel by exchanging
      Start-Control-Connection-Request Random Vector RV, and -Reply messages.  These
      messages are also used to exchange information about basic
      operating capabilities of the LAC and LNS.  Once Attribute
   Value AV. Break the control
      message exchange is complete, value field into 16-octet chunks p1, p2, etc.
   with the LAC may initiate sessions by
      indicating inbound requests, or last one padded at the LNS by requesting outbound
      calls. If both ends of the tunnel have the ability to act as an
      LAC and LNS concurrently, then nothing prohibits establishing
      incoming or outgoing calls from both sides of the same tunnel.
      Control messages may indicate changes in operating characteristics
      of an individual user session end with random data to a Set-Link-Info message.
      Individual sessions may be released by either 16-octet
   boundary.  Call the LAC or LNS, ciphertext blocks c(1), c(2), etc.  We will also
      through control messages.

      Independent Call ID
   define intermediate values are established for each end of a user
      session. b1, b2, etc.

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

   The sender of a packet associated with a particular
      session places String will contain c(1)+c(2)+...+c(i) where + denotes
   concatenation.

   On receipt, the Call ID established by its peer random vector is taken from the last Random Vector
   AVP encountered in the Call ID
      header field of all outgoing packets.  For message prior to the cases where AVP to be unhidden.  The
   above process is then reversed to yield the original value.

4.3 AVP Summary

   The following sections contain a Call
      ID has not yet been assigned from list of all L2TP AVPs defined in
   this document.

   Following the peer (i.e., during call
      establishment name of a new session), the Call ID field AVP is sent as 0,
      and further fields within a list indicating the message are used to identify types
   that utilize each AVP. After each AVP title follows a short
   description of the
      session.  The Call ID value purpose of 0 is thus special the AVP, a detail (including a graphic)
   of the format for the Attribute Value, and MUST NOT be
      used as an Assigned Call ID.

      A mechanism any additional information
   needed for detection proper use of tunnel connectivity problems is
      provided by the reliable transport layer of L2TP.  The transport
      layer of avp.



Townsley, et al.            Standards Track                    [Page 15]


INTERNET DRAFT                    L2TP performs control message retransmission.  If                     February 1999


   4.3.1 AVPs Applicable To All Control Messages

   Message Type (All Messages)

      The Message Type AVP, Attribute Type 0, identifies the
      number of retransmission attempts for a given control
      message
      exceeds a configured maximum value, herein and defines the tunnel is reset.  This
      retransmission mechanism exists context in both which the LNS and LAC ends exact meaning
      of the tunnel.

      A keepalive mechanism following AVPs will be determined.

      The Attribute Value field for this AVP has the following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Message Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Message Type is employed by a 2 octet unsigned integer.

      The Message Type AVP MUST be the L2TP higher layer first AVP in
      order to differentiate tunnel outages from extended periods of no
      control or data activity on a tunnel. This is accomplished by message,
      immediately following the
      higher layer injecting Hello control messages into message header (defined in
      section 3.1). See Section 3.2 for the control
      stream after a specified period list of time elapses since the last
      data or defined control
      message was received on the tunnel.  As for any
      other control message, if types and their identifiers.

      The Mandatory (M) bit within the transport does not receive Message Type AVP has special
      meaning. Rather than an ACK
      for indication as to whether the Hello message after AVP itself
      should be ignored if not recognized, it is an indication as to
      whether the normal number of retransmissions control message itself should be ignored. Thus, if the tunnel
      M-bit is declared down set within the Message Type AVP and is reset.  The transport layer
      reset mechanism along with the injection of Hello messages ensures
      that a connectivity failure between Message Type is
      unknown to the LNS and implementation, the LAC will be
      detected at both ends of a tunnel in a timely manner.

      It MUST be cleared.  If the
      M-bit is intended that control messages will also carry management
      related information in not set, then the future, such as a implementation may ignore an unknown
      message allowing the
      LNS type. The M-bit MUST be set to request the status of a given LAC; these 1 for all 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 This AVP may not be used to carry user session PPP



Valencia                   expires June 1999                    [Page 14]

INTERNET DRAFT                                              October 1998


      packets for sessions involving a given LNS-LAC pair. hidden (the H-bit
      MUST be 0).  The "Call
      ID" field in the L2TP header indicates to which session a
      particular PPP packet belongs.  In Length of this manner, PPP packets are
      multiplexed and demultiplexed over a single tunnel between a given
      LNS-LAC pair. AVP is 8.

   Random Vector (All Messages)

      The "Call ID" field value Random Vector AVP, Attribute Type 36, is established during used to enable the
      exchange
      hiding 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 has specific QOS attributes
      dedicated to a given user.  L2TP provides a tunnel identifier so
      that individual tunnels can Attribute Value of arbitrary AVPs.

      The Attribute Value field for this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Random Octet String ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Random Octet String may be identified, even when arriving from of arbitrary length, although a single source LAC or LNS.

      The



Townsley, et al.            Standards Track                    [Page 16]


INTERNET DRAFT                    L2TP header also                     February 1999


      random vector of at least 16 octets is recommended.  The string
      contains optional acknowledgment and
      sequencing information that can be used to provide flow-control
      across the underlying medium (which may be an internetwork) as
      well as congestion control random vector for use in computing the network itself (see section
      4.3). In this document, these mechanisms will be referred to
      collectively as "flow control".  Control messages are used to
      determine rate and buffering parameters that are used MD5 hash to regulate
      retrieve or hide the flow Attribute Value of PPP packets for a particular session over the tunnel.

      The receiving peer indicates whether flow control is to be
      performed for payload packets sent to it.  If hidden AVP (see Section
      4.2).

      More than one Random Vector AVP may appear in a peer issues message, in which
      case a
      Receive Window Size hidden AVP with a non-zero value during session
      establishment, then uses the sending peer Random Vector AVP most closely
      preceeding it.  This AVP MUST abide by precede the indicated
      window size value as long as sequence numbers are provided.  If a
      receiving peer does not wish to flow control the payload packets
      sent to it, it should not issue the Receive Window Size AVP with a
      non-zero value.  Issuing a Receive Window Size first AVP with a zero
      value has special significance.  It indicates that the receiver
      does not want to perform flow-control but it does want the sending
      peer to provide Ns values in payload packets so that it can detect
      lost packets or packets received out of order.  A peer SHOULD NOT
      send ZLB ACK's when its advertised Receive Window is zero or not
      present (flow control is not requested).

      In the case where neither peer issues a Receive Window Size AVP
      during session establishment, the optional Nr and Ns fields are
      absent in all payload packets H bit
      set.

      The M-bit for that session.  In the case where
      either peer wishes to perform flow-control or this AVP MUST be set to detect out-of-
      order receive messages (as indicated by the sending of the Receive
      Window Size 1.  This AVP with non-zero or zero value, respectively) the Nr
      and Ns fields MUST NOT be present in payload packets sent by both
      peers.  A proper Ns value starts at 0 and increments by one for
      each transmitted payload message and a proper Nr value
      hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the
      current value
      length of the receive sequence number state variable, Sr.
      See Appendix F for a table detailing when to send sequence numbers
      with regard to the Receive Window AVP.

      Unless the LAC sends the Sequencing Required AVP (see section 6.7 Random Octet String.

   4.3.2 Result and 6.8) in the ICCN or OCCN message, Error Codes

   Result Code (CDN, StopCCN)

      The Result Code AVP, Attribute Type 1, indicates the LNS has reason for
      terminating the authority to
      dynamically enable or disable sending of Ns/Nr and hence



Valencia                   expires June 1999                    [Page 15]

INTERNET DRAFT                                              October 1998


      controlling the capability of loss detection, reordering and flow control over the link.  To disable sequence numbers, the LNS sends
      a packet with channel or session.

      The Attribute Value field for this AVP has the F bit set to following format:

       0 and Ns/Nr fields not present.                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Result Code          |        Error Code (opt)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Error Message (opt) ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The
      LAC, upon receiving such Result Code is a data packet, MUST process 2 octet unsigned integer.  The optional Error
      Code is a 2 octet unsigned integer.  An optional Error Message can
      follow the packet
      and discontinue inclusion Error Code field.  Presence of Ns/Nr fields in any subsequent data
      packets.  Any packets which have been received by L2TP but are
      being held in queue for reordering SHOULD be flushed without
      waiting for an ACK from the peer (as if an R bit packet with Ns
      equal to the current Sr value was received). Ss and Sr should be
      updated Error Code and saved accordingly.

      All data packets will continue to be exchanged without sequence
      numbers until the end of the session or until the LNS resumes
      sequence numbers
      Message are indicated by sending a packet with the F bit set and Ns/Nr
      present. AVP Length field. The LAC, upon receiving a packet Error Message
      contains an arbitrary string providing further (human readable)
      text associated with the F bit set, MUST
      resume sending sequence numbers condition. Human readable text in further packets. In order to
      properly resume, the LNS and LAC all
      error messages MUST preserve the state of Ss and
      Sr between periods of disabled sequencing.

      While the LNS may initiate disabling of sequencing at any time
      during be provided in the session (including UTF-8 charset using the first data packet sent), it is
      recommended that
      Default Language [RFC2277].

      This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for links where reordering or packet loss may
      occur, sequence numbers always
      this AVP MUST be enabled during the initial
      negotiation stages of PPP and disabled only when and if the risk set to 1.  The Length is considered acceptable. For instance, 8 if the PPP session being
      tunneled there is not utilizing any stateful compression no Error
      Code or encryption
      protocols and Message, 10 if there is only carrying IP (as determined by an Error Code and no Error Message
      or 10 + the NCP's that
      are established), then length of the LNS might decide to disable sequencing,
      thus allowing higher level protocols to perform necessary flow
      control end to end Error Message if there is an Error Code
      and reducing Message.

      Defined Result Code values for the per packet StopCCN message are:




Townsley, et al.            Standards Track                    [Page 17]


INTERNET DRAFT                    L2TP processing
      burden on the LNS substantially. Further discussion of some of                     February 1999


         0 - Reserved
         1 - General request to clear control connection
         2 - General error--Error Code indicates the
      tradeoffs associated with disabling sequencing over media which
      may reorder or silently drop packets is given in section 8.2.

   4.3 Flow problem
         3 - Control

      If a receiving peer offers a non-zero receive window size channel already exists
         4 - Requester is not authorized to establish a
      sending peer then the sending peer MUST abide by this window size
      value as long as sequence numbers are being exchanged (See
      Appendix F for details of when flow control is enabled in relation
      to sending of the receive window AVP). channel
         5 - The sending peer MUST stop
      sending payload packets when protocol version of the window requester is full; i.e., x
      consecutive messages have been sent but have not been
      acknowledged, where x supported
             Error Code indicates highest version supported
         6 - Requester is being shut down
         7 - Finite State Machine error

      Defined Result Code values for the value of the Receive Window Size AVP.
      Implementors should take care CDN message are:

          0 - Reserved
          1 - Call disconnected due to avoid the situation where loss of
      an ACK by a sending peer with a full transmit window causes a
      session carrier
          2 - Call disconnected for the reason indicated
              in error code
          3 - Call disconnected for administrative reasons
          4 - Call failed due to hang forever, lack of appropriate facilities being
              available (temporary condition)
          5 - Call failed due to the fact there are no
      retransmissions lack of payload packets.  Steps must be taken appropriate facilities being
              available (permanent condition)
          6 - Invalid destination
          7 - Call failed due to reopen
      the transmit window (at least no carrier detected
          8 - Call failed due to a value of 1) upon expiration detection of
      an ACK wait timeout.  See Appendix B for more details.

      When sending a busy signal
          9 - Call failed due to lack of a peer dial tone
         10 - Call was not established within time allotted by LAC
         11 - Call was connected but no appropriate framing was detected

      The Error Codes defined below pertain to types of errors that has issued a non-zero receive window
      size, the sending peer is responsible for resetting the receiver's
      Sr value when a sent payload are
      not specific to any particular L2TP request, but rather to
      protocol or message is lost during transmission.



Valencia                   expires June 1999                    [Page 16]

INTERNET DRAFT                                              October 1998


      When format errors. If an L2TP reply indicates in
      its Result Code that a sent message is lost, the receiving peer's Sr value (and
      hence the Nr value it sends) will "stick" at general error occurred, the Ns General Error
      value of should be examined to determine what the
      first missing payload message. error was. The "Reset Sr" (R bit) in the
      payload message header (see Section 5.3) provides a mechanism
      currently defined General Error codes and their meanings are:

      0 - No general error
      1 - No control connection exists yet for this LAC-LNS pair
      2 - Length is wrong
      3 - One of the sending peer to indicate field values was out of range or
          reserved field was non-zero
      4 - Insufficient resources to the receiver that it (the sending
      peer) recognizes that at least one payload message has been lost
      and that the receiving peer should handle this operation now reset its Sr value beyond
      5 - The Session ID is invalid in this context
      6 - A generic vendor-specific error occurred in the lost message(s). LAC
      7 - Try another.  If the sending peer is performing adaptive
      window adjustment (see Appendix B.1) then it LAC is this recognition aware of a lost message that is used to indicate that a window
      adjustment at the sending peer other possible LNS
          destinations, it should try one of them.  This can be performed.

      The sender may use a timer mechanism similar to that
          used to
      retransmit lost control messages to determine when transmitted
      payload packets have been lost.  When the timer expires, a payload
      message (zero or non-zero length) with the R bit set can be issued
      to indicate to guide an LAC based on LNS policy, for instance,
          the receiver that it needs to reset its Sr value.
      Upon receipt existence of multilink PPP bundles.




Townsley, et al.            Standards Track                    [Page 18]


INTERNET DRAFT                    L2TP                     February 1999


      When a payload message with the R bit set, the receiver
      resets Sr to the value General Error Code of Ns contained in the message, or, if
      highly congested, to a value between its current value and 6 is used, additional information
      about the
      value of Ns contained error SHOULD be included in the message.

      Upon receipt of a payload message with R bit set, the receiver
      takes Error Message field.

   4.3.3 Control Connection Management AVPs

   Protocol Version (SCCRP, SCCRQ)

      The Protocol Version AVP, Attribute Type 2, indicates the following actions: First, L2TP
      protocol version of the receiver checks sender.

      The Attribute Value field for this AVP has the
      presence of the R bit in following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Ver      |     Rev       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Ver field is a received payload message before
      comparing 1 octet unsigned integer containing the message's Ns value to its Sr value.  If the R bit
      1. Rev field is
      set, the receiver will typically set its Sr value equal to that of
      Ns contained in the message and fall through a 1 octet unsigned integer containing 0. This
      pertains to normal receive
      message processing in which Sr will be incremented (modulo 2**16)
      if the message L2TP protocol version 1, revision 0. Note this is non-ZLB and will remain not
      the same if it version number that is ZLB.
      However, if included in the receiver is known to be heavily congested, it MAY
      choose to not update or set its new Sr value between (modulo
      2**16) the current Sr value and that header of Ns contained in the each
      message.

      This effectively spoofs the transmitter into believing
      that the R bit packets that have been sent are not being received,
      ultimately causing the transmitter to backoff more quickly.

      In order to prevent an R bit message received out of order from
      setting Sr to an old value, the receiving peer should compare the
      value of Ns in an R bit message AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
      this AVP MUST be set to its current value of Sr. 1.  The
      receiving peer should reset its Sr value only if Ns is greater
      than (modulo 2**16) its current value Length of Sr. this AVP is 8.

   Framing Capabilities (SCCRP, SCCRQ)

      The sender of the R bit can decide whether it wishes to advance
      the receiver's Sr value to the value just past the highest (modulo
      2**16) Nr value received (the Ns value of Framing Capabilities AVP, Attribute Type 3, provides the message just past
      that peer
      with an indication of the first lost message) or to its current value types of Ss.
      Resetting it to framing that just past the first lost message enables the
      sender to determine if other messages in the same transmit window
      were also lost.  Setting it to the current Ss value of the sender
      treats losses of multiple messages in the same window the same as
      the loss of a single message.  An implementation may use either, will be accepted
      or a combination of both methods. If the transmitter detects that requested by the receiver is heavily congested, piggybacking sender.

      The Attribute Value field for this AVP has the R bit on data



Valencia                   expires June 1999                    [Page 17]

INTERNET DRAFT                                              October 1998


      packets should be refrained in favor of a ZLB with the R bit set following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Reserved for resetting the receiver's Sr.

      It future framing type definitions          |A|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Attribute Value field is permissible for a sending peer to set the R 32-bit mask, with two bits defined.
      If bit (and hence
      reset the transmit window) in all transmitted payload packets as
      an indication that flow control has been disabled at the
      transmitter.

      Receipt of an R A is set, asynchronous framing is supported. If bit S is
      set, synchronous framing is supported.

      A peer MUST NOT request an explicit indication to immediately
      flush all packets which might be in queue to PPP for processing.
      There are a number of tradeoffs as to precisely when incoming or outgoing call with a receiver
      should decide to pass packets from L2TP to PPP, many dependent on
      what protocols are being carried by PPP.  In general, packets
      should be declared lost and passed to PPP in
      Framing Type AVP specifying a timely enough
      manner so as to value not cause retransmissions by reliable higher layer
      protocols due to packets that are held advertised in queue by l2tp.

      L2TP does not specify the particular timeout algorithms Framing
      Capabilities AVP it received during control connection



Townsley, et al.            Standards Track                    [Page 19]


INTERNET DRAFT                    L2TP                     February 1999


      establishment.  Attempts to use for
      flow control.  Suggested algorithms for do so will result in the determination of
      adaptive timeouts to recover from dropped data call being
      rejected.

      This AVP may be hidden (the H-bit may be 0 or acknowledgments
      on the tunnel are included in Appendix A of this document.
      Additional examples for sequencing and flow control are included
      in Appendix E.

5.0 Message Format and Protocol Extensibility

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

   Once media-level connectivity 1.  The Length (before hiding) is reached, L2TP message formats define 10.

   Bearer Capabilities (SCCRP, SCCRQ)

      The Bearer Capabilities AVP, Attribute Type 4, provides the protocol for peer
      with an LAC and LNS to manage the tunnel and its
   associated sessions.

   In each case where a field is optional, if indication of the field is not present,
   its space does not exist in bearer device types supported by the packet.  Existing fields are placed
   back-to-back to form
      hardware interfaces of the packet.

   5.1 AVP

      To maximize extensibility while still permitting interoperability,
      a uniform method sender for encoding message types and bodies is used
      throughout L2TP.  This encoding will be termed an AVP (Attribute- outgoing calls.

      The Attribute Value Pair) in the remainder of field for this document.  Each AVP is
      encoded as:











Valencia                   expires June 1999                    [Page 18]

INTERNET DRAFT                                              October 1998 has the following format:

       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...
      |     Reserved for future bearer type definitions           |A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | [until Overall Length

      This is reached]...                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

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

      An LNS should not set, request an unrecognized AVP
      MUST be ignored.

      The H bit, known as outgoing call specifying a value in
      the "hidden" bit, controls Bearer Type AVP for a device type not advertised in the hiding of Bearer
      Capabilities AVP it received from the
      data LAC during control
      connection establishment. Attempts to do so will result in the value field of an AVP.
      call being rejected.

      This capability can AVP MUST be used to
      avoid present if the passing of sensitive data, such as user passwords, sender can place outgoing calls
      when requested.

      Note that an LNS that cannot act as
      cleartext in an AVP.  Section 5.7 describes the procedure LAC as well will not
      support hardware devices for
      performing AVP value hiding.

      Overall Length encodes handling incoming and outgoing calls
      and should therefore set the number A and D bits of octets (including the Overall
      Length field itself) contained in this AVP.  It is 10 bits,
      permitting a maximum of 1023 octets of data in a single AVP.

      Vendor ID is the IANA assigned "SMI Network Management Private
      Enterprise Codes" [12] value, encoded in network byte order.  The
      value 0, reserved in this table, corresponds to IETF adopted
      Attribute values defined within this document.  Any vendor wishing AVP to implement L2TP extensions can use their own Vendor ID along
      with private Attribute values, guaranteeing that they will 0, or
      should not
      collide with any other vendor's extensions, nor with future IETF
      extensions.  Note that there are 16 bits allocated for various
      organizations to design and define non-standard attributes.  This
      limits send the ability to define new proprietary AVP implementations
      to the first 65,535 enterprises.

      Attribute at all. An LNS that can also act as an LAC
      and place outgoing calls should set A or D as appropriate.
      Presence of this message is the actual attribute, a 16-bit value specified in
      network byte order with not a unique interpretation across all AVP's
      defined under guarantee that a given Vendor ID.

      Value follows immediately after the Attribute field, and runs for



Valencia                   expires June 1999                    [Page 19]

INTERNET DRAFT                                              October 1998 outgoing
      call will be placed by the remaining octets indicated in sender if requested, just that the Overall Length (i.e.,
      Overall Length minus six octets of header).

      AVP's should
      physical capability exists.

      This AVP may be kept compact; the combined AVP's within a control
      message hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST NOT ever cause a control message's total length be set to
      exceed 1500 octets in length.

   5.2 Control Message Format

      Each 1.  The Length (before hiding) is 10.

   Tie Breaker (SCCRQ)

      The Tie Breaker AVP, Attribute Type 5, indicates that the sender



Townsley, et al.            Standards Track                    [Page 20]


INTERNET DRAFT                    L2TP control message begins with                     February 1999


      wishes a 12 octet header portion
      followed by an 8 octet Message Type single tunnel to exist between the given LAC-LNS pair.

      The Attribute Value field for this AVP and zero or more AVP's.
      This header is formatted: has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|L|0|0|F|0|0|0|0|0|0|0|0| Ver |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tunnel ID           |            Call ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Ns              |               Nr              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Message Type AVP... Tie Break Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ... (8 octets)
                                                 ...(64 bits)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

      The L choose a
      single tunnel where both LAC and F bits LNS request a tunnel
      concurrently. The recipient of a SCCRQ must be 1, indicating that check to see if a
      SCCRQ has been sent to the length, Ns peer, and Nr
      fields are present. if so, must compare its Tie
      Breaker value with the received one. The T bit MUST be 1, indicating a control message.

      Ver lower value "wins", and
      the "loser" MUST be silently discard its tunnel. In the value 2, indicating case where a version 1 L2TP message (the
      value 1
      tie breaker is reserved to permit detection of L2F [2] packets should
      they arrive intermixed, present on both sides, and the value 0 is undefined).

      Length equal, both
      sides MUST discard their tunnels.

      If a tie breaker is received, and an outstanding SCCRQ had no tie
      breaker value, the overall length of the message specified in network
      byte order. Calculation of the length includes initiator which included the L2TP 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. Tie Breaker AVP
      "wins". If neither side issues a control
      message does not apply to a single user session within the tunnel
      (for instance, a Stop-Control-Connection-Notification message),
      Call ID tie breaker, then two separate
      tunnels are opened.

      This AVP MUST NOT be set to 0.  If an Assigned Tunnel ID has not yet
      been received from the peer, Tunnel ID hidden (the H-bit MUST be set to 0.  Once an
      Assigned Tunnel ID is received, all further packets 0). The M-bit for
      this AVP MUST be sent



Valencia                   expires June 1999                    [Page 20]

INTERNET DRAFT                                              October 1998


      with Tunnel ID set to the indicated value. Note that the Assigned
      Tunnel ID and Call ID SHOULD be selected in an unpredictable
      manner rather than sequentially or otherwise.  Doing so will help
      to deter hijacking 0.  The Length of a session by a malicious user who does not
      have access to packet traces between the LAC and LNS.

      Ns this AVP is copied from the send sequence number state variable, Ss, at 14.

   Firmware Revision (SCCRP, SCCRQ)

      The Firmware Revision AVP, Attribute Type 6, indicates the time
      firmware revision of the message is transmitted.  Ss is incremented after
      copying if issuing device.

      The Attribute Value field for this AVP has the control message following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Firmware Revision       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Firmware Revision is a 2 octet unsigned integer encoded in a
      vendor specific format.

      For devices which do not have a ZLB ACK.  Nr is copied
      from the receive sequence number state variable, Sr, and indicates firmware revision (general purpose
      computers running L2TP software modules, for instance), the sequence number, Ns, + 1
      revision of the highest (modulo 2**16) in-
      sequence message received.  See section 4.0.

   5.3 Payload Message Format

      PPP payload packets tunneled within L2TP have a smaller
      encapsulation than the L2TP control message header, reducing
      overhead of software module may be reported instead.



Townsley, et al.            Standards Track                    [Page 21]


INTERNET DRAFT                    L2TP during the life of a tunneled PPP session.                     February 1999


      This AVP may be hidden (the H-bit may be 0 or 1). The
      LNS is expected to M-bit for
      this AVP MUST be able set to process user data packets 0.  The Length (before hiding) is 8.

   Host Name (SCCRP, SCCRQ)

      The Host Name AVP, Attribute Type 7, indicates the name of at
      least the default MRU for PPP, not including L2TP and media
      encapsulation.
      issuing LAC or LNS.

      The L2TP header has an optional padding Attribute Value field to
      allow for alignment correction if desired. The smallest L2TP
      encapsulation is 6 octets; this AVP has the largest is 14 octets (plus padding
      octets, if present).  See section 8.1 for further MTU
      considerations. following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|L|R|0|F|0|S|P|0|0|0|0|0| Ver |          Length (opt)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tunnel ID           |             Call ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Ns (opt)          |               Nr (opt)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Offset Size (opt)        |    Offset pad... (opt)
      | Host Name ... (arbitrary number of octets)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The 0 bits indicate reserved bit fields and Host Name is of arbitrary length, but MUST be set to 0.  A
      packet received with a reserved bit set to at least 1
      octet.

      This name should be as broadly unique as possible; for hosts
      participating in the payload
      message header DNS [RFC1034], a hostname with fully qualified
      domain would be appropriate.

      This AVP MUST NOT be silently discarded, unless the bit is
      defined for an extension that is known to the implementation.

      The T bit hidden (the H-bit MUST be 0, indicating payload.

      Ver 0). The M-bit for
      this AVP MUST be 2, indicating version 1 of the L2TP protocol.

      If the L bit is set, the set to 1.  The Length field of this AVP is present, indicating 6 plus the
      total
      length of the packet sent. Host Name.

   Vendor Name (SCCRP, SCCRQ)

      The R bit, "Reset Sr", is used for flow control and indicates that
      the receiver SHOULD reset its receive state variable, Sr, for this
      session to the value contained in Vendor Name AVP, Attribute Type 8, contains a vendor specific
      (possibly human readable) string describing the Ns field type of LAC or LNS
      being used.

      The Attribute Value field for this message
      header.  Sr is reset to AVP has the value following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Vendor Name ...(arbitrary number of Ns only if Ns octets)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Vendor Name is greater than



Valencia                   expires June 1999                    [Page 21]

INTERNET DRAFT                                              October 1998


      (modulo 2**16) the receiver's current value of Sr.  Normal receive
      processing indicated number of octets representing the message is performed after
      vendor string. Human readable text for this AVP MUST be provided
      in the value of Sr is
      reset.  Note that if UTF-8 charset using the F bit is not set, then Default Language [RFC2277].

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this bit AVP MUST be set to 0.  See section 4.2 for a detailed discussion  The Length (before hiding) of this AVP
      is 6 plus the use length of this
      bit for flow control on the data channel. See Appendix E for
      examples of proper R bit usage.

      If the F bit is set, both Vendor Name.



Townsley, et al.            Standards Track                    [Page 22]


INTERNET DRAFT                    L2TP                     February 1999


   Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN)

      The Assigned Tunnel ID AVP, Attribute Type 9, in the Nr SCCRQ and Ns fields
      SCCRP messages specifies the Tunnel ID which the receiving peer
      MUST be present.
      Ns indicates use in the sequence number Tunnel ID field of all subsequent messages.

      The Attribute Value field for this AVP has the packet being sent. following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Assigned Tunnel ID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Ns
      value of a message being transmitted Assigned Tunnel ID is copied from the current
      value of the send sequence number state variable, Ss.  Ss a 2 octet non-zero unsigned integer.

      The Assigned Tunnel ID AVP is
      incremented by one (modulo 2**16) after copying used to multiplex and demultiplex
      multiple tunnels between the Ns field
      only if LNS and LAC. Before the message being sent Assigned
      Tunnel ID AVP is not received from a ZLB ACK.  Nr indicates the
      sequence number of the next in-order message sequence number to peer, messages MUST be
      received (if the last in-order non-ZLB data packet had Ns set to
      1, the Nr sent back would be 2).  The to
      that peer with a Tunnel ID value of Nr is copied from 0 in the current receive state variable, Sr.  Together, Nr and Ns can
      be used to handle out-of-order packets and, together with header of all control
      messages.

      In the R
      bit, to provide flow StopCCN control for message, the connection.

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

      The Offset Size field is present if the S bit is set in the header
      flags.  This field specifies Assigned Tunnel ID AVP first sent to the number of octets past receiving
      peer, permitting the L2TP
      header at which peer to identify the payload data appropriate tunnel even
      if StopCCN is expected to start.  It sent before an Assigned Tunnel ID AVP is
      recommended that data thus skipped received.

      This AVP may be initialized hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 0's.  If
      Offset Size 1.  The Length (before hiding) of this AVP
      is 0, or 8.

   Receive Window Size (SCCRQ, SCCRP)

      The Receive Window Size AVP, Attribute Type 10, specifies the S bit is not set,
      receive window size being offered to the first octet
      following remote peer.

      The Attribute Value field for this AVP has the last octet of L2TP header following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Window Size           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Window Size is the first a 2 octet of
      payload data. unsigned integer.

      If absent, the P bit is set, this packet should receive preferential
      treatment at the LAC in its queuing for transmission to the
      client.  LCP echo requests used as peer must assume a keepalive Window Size of 4 for its
      transmit window. The remote peer may send the link, for
      instance, should generally be sent from the LNS with this bit set.
      Without it, a temporary interval of congestion specified number of the transmission
      queues could result in the interference with keepalive



Townsley, et al.            Standards Track                    [Page 23]


INTERNET DRAFT                    L2TP                     February 1999


      control messages
      and unnecessary loss of the link.

   5.4 Control Message Types

      Control message and AVP types defined in this specification exist
      under Vendor ID 0, indicating IETF defined behavior.  The actual
      message and AVP semantics are defined in the next section. before it must wait for an acknowledgment.

      This
      section includes tables that summarize all currently defined
      message and AVP types.  Note that while an MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
      this AVP may legally occur
      under more than one type MUST be set to 0.  The Length of control message, an AVP's specific
      interpretation this AVP is unique to the specific control message.

      Each message type entry in the table below indicates: 8.

   Challenge (SCCRP, SCCRQ)

      The Challenge AVP, Attribute Type 11, indicates that the integer
      value assigned issuing
      peer wishes to authenticate the message type; the message type abbreviation



Valencia                   expires June 1999                    [Page 22]

INTERNET DRAFT                                              October 1998


      used in the AVP Summary Table of Sec. 5.5; and the full name of
      the message type. tunnel endpoints using a CHAP-
      style authentication mechanism.

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

      Control Connection Management following format:

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

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

      Error Reporting

         15 (WEN)      WAN-Error-Notify

      PPP Session Control

         16 (SLI)      Set-Link-Info

   5.5 AVP Summary

      The following table lists all standard L2TP attributes currently
      defined.  The "Attr" column indicates the integer value assigned
      to this attribute.  The "M" column indicates the setting 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Challenge ... (arbitrary number of the
      "Mandatory" bit octets)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Challenge is one or more octets of the random data.

      This AVP header may be hidden (the H-bit may be 0 or 1). The M-bit for each attribute.
      this AVP MUST be set to 1.  The "Len"
      field indicates the size Length (before hiding) of the AVP including the AVP header.  A
      "+" in this column indicates that the length varies depending upon AVP
      is 6 plus the length of the actual contents of the value field. Challenge.

   Challenge Response (SCCCN, SCCRP)

      The "(usage)" list Response AVP, Attribute Type 13, provides a response to a
      challenge received.

      The Attribute Value field for each entry indicates the message types that
      utilize each this AVP (See command table of Sec. 5.4).  An abbreviation
      shown in mixed or upper case letters indicates that has the
      corresponding following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Response ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                              ... (16 octets)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Response is a 16 octet value reflecting the CHAP-style
      [RFC1994] response to the challenge.

      This AVP MUST be present in this message type; All lower
      case indicates that the AVP may optionally appear in this message
      type. Some AVPs MUST be present only when an SCCRP or SCCCN if a corresponding optional
      AVP is present, these AVPs are shown in lower case as well.




Valencia                   expires June 1999 challenge was



Townsley, et al.            Standards Track                    [Page 23] 24]


INTERNET DRAFT                                              October 1998


      A brief summary of                    L2TP                     February 1999


      received in the type and contents preceeding SCCRQ or SCCRP. For purposes of the ID
      value field for
      each attribute is also given for each entry.  Refer to the
      individual message type descriptions that appear in Section 6 for
      further details about the use CHAP response calculation, the value of a particular the Message
      Type AVP in a particular for this message type. This table is provided only as a convenient overview
      of AVPs, individual message used (e.g. 2 for an SCCRP, and 3 for
      an SCCCN).

      This AVP descriptions always enjoy priority may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to summary descriptions provided in 1.  The Length (before hiding) of this table.

      Attr M Len AVP
      is 22.

   4.3.4 Call Management AVPs

   Q.931 Cause Code (CDN)

      The Q.931 Cause Code AVP, Attribute Name (usage)

        0  1 8   Message Type (ALL MESSAGES)
         16-bit integer value indicating the message type, as defined 12, is used to give
      additional information in
         table above.  MUST be the first case of unsolicited call disconnection.

      The Attribute Value field for this AVP in each message has the following format:

       0                   1                   2                   3
       0 1 10+ Result Code (CDN, StopCCN)
         16-bit Integer value indicating result of corresponding request
         or reason for issuing a request, 16-bit integer General Error
         code and an optional ASCII string error message.  See Result
         and General Error code tables below. 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8   Protocol Version (SCCRP, SCCRQ)
         8-bit L2TP Protocol and Revision numbers

        3 9 0 1 10  Framing Capabilities (SCCRP, SCCRQ)
         32-bit bitmask indicating supported framing types (e.g.,
         synchronous and asynchronous) 2 3 4  1 10  Bearer Capabilities (sccrp, sccrq)
         32-bit bitmask indicating supported bearer types (e.g., analog
         and digital) 5  0 14  Tie Breaker (sccrq)
         8 octet value used to break control connection establishment
         collisions 6  0 8   Firmware Revision (sccrp, sccrq)
         16-bit integer representing vendor's firmware revision 7  1 6+  Host Name (SCCRP, SCCRQ)
         ASCII string name (e.g., DNS name) of issuer 8  0 6+  Vendor Name (sccrp, sccrq)
         ASCII string describing issuing device 9 0 1 8   Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN)
         16-bit integer tunnel ID assigned by sender

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

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



Valencia                   expires June 1999                    [Page 24]

INTERNET DRAFT                                              October 1998


         control session peer

       12  1 9+  Q.931
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Cause Code (cdn)
         16-bit cause           |   Cause Msg   | Advisory Msg...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Cause Code is the returned Q.931 Cause code, 1 octet cause message, and optional ASCII
         advisory Cause Msg is the
      returned Q.931 message

       13  1 22  Challenge Response (scccn, sccrp)
         16 octet CHAP type response code (e.g., DISCONNECT) associated with the
      Cause Code.  Both values are returned in their native ITU
      encodings [DSS1]. An additional ASCII text Advisory Message may
      also be included (presence indicated by the AVP Length) to peer's Challenge

       14  1 8 further
      explain the reason for disconnecting.

      This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
      this AVP MUST be set to 1.  The Length of this AVP is 9, plus the
      size of the Advisory Message.

   Assigned Call Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ)
         16-bit integer

      The Assigned Session ID AVP, Attribute Type 14, encodes the ID
      being assigned to a call this session by sender

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

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

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

       18  1 10  Bearer Type (icrq, OCRQ)
         Indicates bearer type (i.e., analog the LAC or digital) LNS.

      The Attribute Value field for call

       19 this AVP has the following format:

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

       20
       0 1 2 3 4 5 6 7 8   Packet Processing Delay (iccn, icrp, occn, ocrq)
         16-bit integer estimate of processing time of full window of
         received packets by sender

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

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

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

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

       25 9 0 10  Physical Channel 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Assigned Session ID (icrq, ocrp)
         32-bit vendor specific physical device identifier used for call

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

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



Valencia                   expires June 1999       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Townsley, et al.            Standards Track                    [Page 25]


INTERNET DRAFT                                              October 1998


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

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

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

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

       32  0 8   Proxy Authen                    L2TP                     February 1999


      The Assigned Session ID (iccn)
         16-bit integer of which low order octet is ID presented to
         client with Challenge.  High order a 2 octet must be 0.

       33  0 6+  Proxy Authen Response (iccn)
         Octet string CHAP response or ASCII string password depending
         on authentication type non-zero unsigned integer.

      The Assigned Session ID is used

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

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

       36  1 6+  Random Vector (all messages)
         Variable length octet string containing demultiplex data
      sent over a random sequence of
         values used to accomplish tunnel between the optional "hiding" of other AVP
         values (See "H" bit description LNS and LAC. The L2TP peer MUST
      place this value in Sec. 5.7).

       37  0 6+ Private Group the Session ID (iccn)
         Variable length octet value used by header field of all control and
      data messages that it subsequently transmits over the LAC or LNS to indicate tunnel that
      belong to this call session.  Before the Assigned Session ID AVP is to
      received from a peer, messages MUST be associated sent to that peer with a particular customer
         group.

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

       39  1 6  Sequencing Required (iccn, occn)
         If present, indicates to all control messages.

      In the LNS that it MUST NOT dynamically
         disable sequencing.

   5.6 Result and Error Code Summary

   The StopCCN and CDN message types contain a Result Code AVP which
   indicates the result of control message, the previously requested operation.  The
   Result Code can indicate that additional information pertaining same Assigned Session ID AVP first
      sent to an
   error situation can be found in the Error Code field of the Result



Valencia                   expires June 1999                    [Page 26]

INTERNET DRAFT                                              October 1998


   Code AVP.  The meaning of the result code receiving peer is tabulated under used, permitting the
   specific type of message containing peer to
      identify the result.  Each 16-bit Result
   Code appropriate tunnel even if CDN is immediately followed (in the same AVP) by a 16-bit General
   Error code value.

   General error codes pertain to types of errors which are not specific
   to any particular L2TP request, but rather to protocol or message
   format errors.  If sent before an L2TP reply indicates in its Result Code that a
   general error occurred, the General Error value should
      Assigned Session ID is received.

      This AVP may be hidden (the H-bit may be examined to
   determine what the error was.  The currently defined General Error
   codes and their meanings are: 0 - No general error
      1 - No control connection exists yet or 1). The M-bit for
      this LAC-LNS pair
      2 - AVP MUST be set to 1.  The Length is wrong
      3 - One (before hiding) of this AVP
      is 8.

   Call Serial Number (ICRQ, OCRQ)

      The Call Serial Number AVP, Attribute Type 15, encodes an
      identifier assigned by the field values was out of range LAC or reserved field was
         non-zero
      4 - Insufficient resources LNS to handle this operation now
      5 - call.

      The Call ID is invalid in Attribute Value field for this context
      6 - A generic vendor-specific error occurred in AVP has the LAC
      7 - Try another.  If LAC following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Call Serial Number                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Call Serial Number is aware of other possible LNS
         destinations, it should try one of them.  This can be used a 32 bit value.

      The Call Serial Number is intended to
         guide be an LAC based on LNS policy, easy reference for instance, the existence
         of multilink PPP bundles.

   If the length
      administrators on both ends of the Result Code AVP specifies that the Value field
   is more than four octets in length, the remaining octets after the
   General Error Code field a tunnel to use when investigating
      call failure problems. Call Serial Numbers should be set to
      progressively increasing values, which are an arbitrary string providing further
   (possibly human readable) text associated with the condition. Human
   readable text in all error messages MUST likely to be provided in the UTF-8
   charset using the Default Language [18].

   Generally, when unique for
      a General Error Code significant period of 6 is used, additional
   information about the error will time across all interconnected LNSs and
      LACs.

      This AVP may be included in the Optional Message
   field that follows the Error Code field in the Result Code AVP.

   5.7 Hiding of hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP values MUST be set to 1.  The H ("Hidden") bit in the header Length (before hiding) of each this AVP in a control message
   provides a mechanism to indicate to the receiving peer whether the
   contents of the AVP are hidden or present in cleartext.  This feature
   can be used to hide sensitive control message data such as user
   passwords or user ID's.
      is 10.

   Minimum BPS (OCRQ)

      The H bit MUST NOT be set in the Random
   Vector AVP or Message Minimum BPS AVP, Attribute Type AVP.

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



Valencia                   expires June 1999 lowest



Townsley, et al.            Standards Track                    [Page 27] 26]


INTERNET DRAFT                                              October 1998                    L2TP                     February 1999


      acceptable line speed for this call.

      The length of the Attribute Value field for this AVP value to be hidden is first encoded in has the form
   of a Hidden AVP Subformat as follows: following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Length of Original Value    |          Original Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ...                         Minimum BPS                           |             Padding ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length
      This

      The  Minimum BPS is length of a 32 bit value indicates the Original Value to be obscured speed in octets.

   Original Value
      Value of hidden bits per
      second.

      This AVP that is to may be obscured.

   Padding
      Random additional octets used to obscure length of the Original
      Value. hidden (the H-bit may be 0 or 1). The resulting subformat MAY M-bit for
      this AVP MUST be padded to a multiple of 16 octets in
   length. For example, if the Original Value set to be obscured is a string
   containing 6 characters (e.g. password 'foobar'), then 8 + n * 16
   octets of padding would be applied. Padding does NOT alter the value
   placed in the 1.  The Length (before hiding) of the Original Value, only the length of the this AVP itself.

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

      - the 2 octet 10.

   Maximum BPS (OCRQ)

      The Maximum BPS AVP, Attribute number of Type 17, encodes the highest
      acceptable line speed for this call.

      The Attribute Value field for this AVP (in network order)
      - has the shared authentication secret
      - an arbitrary length random vector following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Maximum BPS                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Maximum BPS is a 32 bit value of indicates the random vector used in this hash is passed speed in the
   value field of a Random Vector AVP. bits per
      second.

      This Random Vector AVP must may be
   placed in the message by the sender before any hidden AVPs.  The same
   random vector (the H-bit may be used 0 or 1). The M-bit for more than one hidden
      this AVP in the same
   message.  If a different random vector is used for the hiding MUST be set to 1.  The Length (before hiding) of
   subsequent AVPs then a new Random Vector this AVP must be placed in
      is 10.

   Bearer Type (ICRQ, OCRQ)

      The Bearer Type AVP, Attribute Type 18,  encodes the
   command message before bearer type
      for the first incoming or outgoing call.

      The Attribute Value field for this AVP to which it applies. has the following format:








Townsley, et al.            Standards Track                    [Page 27]


INTERNET DRAFT                    L2TP                     February 1999


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved for future Bearer Types                |A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The MD5 hash value Bearer Type is then XORed with a 32-bit bit mask, which indicates the first 16 octet or less
   segment bearer
      capability of the Hidden AVP Subformat and placed in call (ICRQ) or required for the Value field of call (OCRQ). If
      set, bit A indicates that the Hidden AVP. call refers to an analog channel. If
      set, bit D indicates that the Hidden AVP Subformat is less than 16 octets, call refers to a digital channel.
      Both may be set, indicating that the Subformat is transformed as if call was either
      indistinguishable, or can be placed on either type of channel.

      Bits in the Value field had been padded to
   16 octets before the XOR, but of this AVP MUST only be set by the actual octets present LNS
      for an OCRQ if it was set in the
   Subformat are modified, and the length of the Bearer Capabilities AVP is not altered.

   If received
      from the Subformat LAC during control connection establishment.

      It is longer than 16 octets, valid to set neither the A nor D bits in an ICRQ. Such a second one-way MD5 hash
   is calculated
      setting may indicate that the call was not received over a stream of octets consisting of
      physical link (e.g if the shared secret
   followed by LAC and PPP are located in the result same
      subsystem).

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of the first XOR.  That hash this AVP
      is XORed with 10.

   Framing Type (ICCN, OCCN, OCRQ)

      The Framing Type AVP, Attribute Type 19, encodes the
   second 16 octet framing type
      for the incoming or less segment of outgoing call.

      The Attribute Value field for this AVP has the Subformat and placed in following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved for future Framing Types               |A|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Framing Type is a 32-bit mask, which indicates the
   corresponding octets type of PPP
      framing requested for an OCRQ, or the Value field type of PPP framing
      negotiated for an OCCN or ICCN. The framing type MAY be used as an
      indication to PPP on the Hidden AVP.



Valencia                   expires June 1999 LNS as to what link options to use for
      LCP negotiation [RFC1662].

      Bit A indicates that asynchronous framing. Bit S indicates that
      synchronous framing. For an OCRQ, both may be set, indicating that
      either type of framing may be used.



Townsley, et al.            Standards Track                    [Page 28]


INTERNET DRAFT                                              October 1998


   If necessary,                    L2TP                     February 1999


      Bits in the Value field of this operation is repeated, with AVP MUST only be set by the shared secret used
   along with  each XOR result to generate the next hash to XOR the next
   segment of the value with.

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

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

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

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

   On receipt, LNS
      for an OCRQ if it was set in the random vector is taken Framing Capabilities AVP received
      from the last Random Vector LAC during control connection establishment.

      This AVP encountered in the message prior to the may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP to MUST be unhidden. set to 1.  The
   above process Length (before hiding) of this AVP
      is then reversed 10.

   Called Number (ICRQ, OCRQ)

      The Called Number AVP, Attribute Type 21, encodes the telephone
      number to yield be called for an OCRQ, and the original value.  For more
   details on this hiding method, consult RFC 2058 [8]. Called number for an
      ICRQ.

      The Random Vector Attribute Value field for this AVP has the following format:

   Random Vector

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|   6 + String length   |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              36 Called Number... (arbitrary number of octets)                 | Random Octet String ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Random Vector AVP may be used in any message type.  The Attribute
   value is 36 and it is marked mandatory. It Called Number is used to enable the
   hiding of an ASCII string. Contact between the values
      administrator of arbitrary AVPs.  It MUST precede any AVP
   containing an AVP with the H bit set but it MUST NOT itself have LAC and the
   H bit set.  More than one Random Vector AVP LNS may appear in a message,
   in which case the one most closely preceding an AVP with the H bit
   set pertains be necessary to that AVP.  The Random Octet String is
      coordinate interpretation of the random
   vector value to use needed in computing the MD5 hash to retrieve the
   original value of a hidden this AVP.

      This string can AVP may be of arbitrary
   length, although a random vector of at least 16 octets is
   recommended. hidden (the H-bit may be 0 or 1). The only AVP that the Random Vector M-bit for
      this AVP MUST NOT precede
   is the Message Type be set to 1.  The Length (before hiding) of this AVP (which
      is always 6 plus the first AVP in a message).




Valencia                   expires June 1999                    [Page 29]

INTERNET DRAFT                                              October 1998


6.0 Control Connection Protocol Specification

   Control Connection messages are used to establish and clear user
   sessions.  The first set length of Control Connection messages are used to
   maintain the control connection itself. Called Number.

   Calling Number (ICRQ)

      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 Calling Number AVP, Attribute Type 22, encodes the case where an LAC and LNS both initiate tunnels to each
      other concurrently, and where originating
      number for the LAC and LNS both determine that
      a single tunnel suffices (generally because of media
      characteristic considerations, for instance, whether individual
      tunnels are needed to gain QOS guarantees for each tunnel), a "tie
      breaker" may be undertaken. incoming call.

      The details of breaking a tie are
      documented with Attribute Value field for this AVP has the tunnel establishment messages (Sec. 6.1).

   6.0.2 Reliable Delivery following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Calling Number... (arbitrary number of Control Messages

      Since L2TP may run across media where packets may be lost, octets)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Calling Number is an L2TP
      peer sending a control message will retransmit ASCII string. Contact between 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;
      administrator of the Nr LAC and Ns fields of the control
      message header belong LNS may be necessary to
      coordinate interpretation of the value in this transport layer. AVP.

      This AVP may be hidden (the H-bit may be 0 or 1). The higher layer
      functions of M-bit for



Townsley, et al.            Standards Track                    [Page 29]


INTERNET DRAFT                    L2TP are not concerned with retransmission or
      ordering of control messages.

      Each tunnel maintains a queue of control messages to                     February 1999


      this AVP MUST be
      transmitted set to the peer. 1.  The message at the front Length (before hiding) of the queue is
      sent with a given Ns value, and this AVP
      is held until a control message
      arrives from the peer in which 6 plus the Nr field indicates receipt length of
      this message.  After a fixed (a recommended default is 1 second)
      or adaptive (see Appendix D) timeout interval expires without
      receiving such an acknowledgment, the control message packet is
      retransmitted. Calling Number.

   Sub-Address (ICRQ, OCRQ)

      The retransmitted packet contains the same Ns
      value, but the Nr value MUST be updated with the current value of
      Sr to reflect any packets received in the interim. Each subsequent
      retranmission of a packet MUST employ an exponential backoff
      interval. Thus, if Sub-Address AVP, Attribute Type 23, encodes additional dialing
      information.

      The Attribute Value field for this AVP has the first retransmission occurred after following format:

       0                   1
      second, the next retransmisssion should occur after                   2 seconds has
      elapsed, then                   3
       0 1 2 3 4 seconds, etc. An implementation MAY place a cap
      upon the maximum interval between retransmissions. This cap MUST
      be no less than 5 6 7 8 seconds per retransmission.  If no peer response
      is detected after several retransmissions (a recommended default 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Sub-Address ... (arbitrary number of octets)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Sub-Address is 5), an ASCII string. Contact between the tunnel
      administrator of the LAC and all sessions within MUST the LNS may be cleared.

      When a tunnel is being shut down for reasons other than loss necessary to
      coordinate interpretation of
      connectivity, the state and reliable delivery mechanisms MUST value in this AVP.

      This AVP may be
      maintained and operated hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 1.  The Length (before hiding) of this AVP
      is 6 plus the full retransmission interval after
      the final message exchange has occurred.  This permits reliable
      delivery length of closing messages in environments where these closing
      messages might be dropped.



Valencia                   expires June 1999                    [Page 30]

INTERNET DRAFT                                              October 1998


      A peer MUST NOT withhold acknowledgment the Sub-Address.

   (Tx) Connect Speed (ICCN, OCCN)

      The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes the
      speed of packets as a technique the facility chosen for flow controlling control messages.  An L2TP implementation is
      expected to be able to keep up with incoming control messages,
      possibly responding to some with errors reflecting an inability to
      honor the requested action.

      A sliding window mechanism is used, by default, connection attempt.

      The Attribute Value field for control
      message transmission. this AVP has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             BPS                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The default (Tx) Connect Speed BPS is to permit four control
      messages to be outstanding on a given tunnel.  Consider two peers
      A & B. Suppose A specifies a Receive Window Size AVP with a 4 octet value
      of N indicating the speed
      in bits per second.

      When the Start-Control-Connection-Request or -Reply packets. B optional Rx Connect Speed AVP is now allowed to have up to N outstanding control messages. Once
      N have been sent, however, it must wait for an acknowledgment that
      advances present, the window before sending new control messages.  An
      implementation may support a receive window of only 1 (i.e., by
      sending out a Receive Window Size AVP with a value of 1), but MUST
      accept a window of up to 4 in
      this AVP represents the transmit connect speed, from its peer.  Unlike payload
      sessions, a value the
      perspective of 0 for the Receive Window Size LAC (e.g. data flowing from the LAC to the
      remote system). When the optional Rx Connect Speed AVP is invalid
      for a control session. When transmitting control messages, an
      implementation SHOULD utilize a slow start method NOT
      present, the connection speed between the remote system and window
      adjustment procedure as described in Appendix B.

      The transport layer at a receiving peer LAC is responsible for making
      sure that control messages are delivered in order
      assumed to the higher
      layer be symmetric and that duplicate messages are not delivered to is represented by the higher
      layer.  Messages arriving out of order single value in
      this AVP.




Townsley, et al.            Standards Track                    [Page 30]


INTERNET DRAFT                    L2TP                     February 1999


      This AVP may be queued for in-order
      delivery when the missing messages are received or they hidden (the H-bit 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" 0 or "empty" fields 1). The M-bit for
      this AVP MUST be sent as 0 values set to allow for
      protocol extensibility.

      Each control message has a header, specified in section 5.2,
      including an 1.  The Length (before hiding) of this AVP indicating
      is 10.

   Physical Channel ID (ICRQ, OCRP)

      The Physical Channel ID AVP, Attribute Type 25, encodes the type of control message, followed
      by zero or more AVP's appropriate vendor
      specific physical channel number used for the given type of control
      message.  Each control message is described first at a block
      level, and then with details of each AVP.

6.1 Start-Control-Connection-Request (SCCRQ)

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






Valencia                   expires June 1999                    [Page 31]

INTERNET DRAFT                                              October 1998


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

   Start-Control-Connection-Request

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                0              |               1               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ call.

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

   Protocol Version following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               2               |     0x01      |     0x00                      Physical Channel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Protocol Version AVP within

      Physical Channel ID is a Start-Control-Connection-Request
      packet indicates the L2TP protocol version available.  The
      Attribute 4 octet value is 2, indicating Protocol Version, and is marked
      mandatory. intended to be used for
      logging purposes only.

      This AVP MUST may be present. hidden (the H-bit may be 0 or 1). The Value field is a 16-bit
      hexadecimal value 0x100, indicating L2TP protocol version 1,
      revision M-bit for
      this AVP MUST be set to 0.









Valencia                   expires June 1999  The Length (before hiding) of this AVP
      is 10.

   4.3.5 Proxy LCP and Authentication AVPs

   The LAC may have answered the call and negotiated LCP with the remote
   system, perhaps in order to establish the system's apparent identity.
   In this case, these AVPs may be included to indicate the link
   properties the remote system initially requested, properties the
   remote system and LAC ultimately negotiated, as well as PPP
   authentication information sent and received by the LAC. This
   information may be used to initiate the PPP LCP and authentication
   systems on the LNS, allowing PPP to continue without renegotiation of
   LCP. Note that the LNS policy may be to enter an additional round of
   LCP negotiation and/or authentication if the LAC is not trusted.

   Initial Received LCP CONFREQ (ICCN)

      In the Initial Received LCP CONFREQ AVP, Attribute Type 26,
      provides the LNS with the Initial CONFREQ received by the LAC from
      the PPP Peer.

      The Attribute Value field for this AVP has the following format:







Townsley, et al.            Standards Track                    [Page 32] 31]


INTERNET DRAFT                                              October 1998


   Framing Capabilities                    L2TP                     February 1999


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               3
      |     0x00      |     0x00 LCP CONFREQ... (arbitrary number of octets)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x00      |0|0|0|0|0|0|A|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Framing Capabilities AVP within

      LCP CONFREQ is a Start-Control-Connection-
      Request indicates copy of the type body of framing that the sender initial CONFREQ received,
      starting at the first option within the body of this
      message can provide.  The Attribute value is 3, indicating Framing
      Capabilities, and is marked mandatory. the LCP message.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be present. set to 0.  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 Length (before hiding) of this AVP
      is 6 plus the length of the CONFREQ.

   Last Sent LCP CONFREQ (ICCN)

      In the Last Sent LCP CONFREQ AVP, Attribute Type 26, provides the peer
      LNS with an indication of the types of
      framing that will be accepted or initiated Last CONFREQ sent by the sender.  A peer
      should not initiate an incoming or outgoing call with a Framing
      Type AVP specifying a value not advertised in LAC to the Framing
      Capabilities PPP Peer.

      The Attribute Value field for this AVP it received during control connection
      establishment.  Attempts to do so will result in has the call being
      rejected.

   Bearer Capabilities following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               4               |     0x00
      |     0x00 LCP CONFREQ... (arbitrary number of octets)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x00      |0|0|0|0|0|0|A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Bearer Capabilities AVP within LCP CONFREQ is a Start-Control-Connection-
      Request indicates copy of the bearer capabilities that body of the sender final CONFREQ sent to
      the client to complete LCP negotiation, starting at the first
      option within the body of this
      message can provide for outgoing calls.  The Attribute value is 4,
      indicating Bearer Capabilities, and is marked mandatory. the LCP message.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be present if the sender can place outgoing calls when
      requested. set to 0.  The Value field is a 32-bit quantity with two bits
      defined.  If bit A is set, analog access is supported.  If bit D
      is set, digital access is supported.

      This Length (before hiding) of this AVP provides
      is 6 plus the peer with an indication length of the bearer device
      types supported by the hardware interfaces of CONFREQ.

   Last Received LCP CONFREQ (ICCN)

      The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the sender for
      outgoing calls.  An
      LNS should not initiate an outgoing call
      specifying a value in the Bearer Type AVP for a device type not
      advertised in with the Bearer Capabilities AVP it Last CONFREQ received from the LAC



Valencia                   expires June 1999                    [Page 33]

INTERNET DRAFT                                              October 1998


      during control connection establishment.  Attempts to do so will
      result in by the call being rejected.

      Note that an LNS that cannot act as an LAC as well will not
      support hardware devices for handling incoming and outgoing calls
      and should therefore set the A and D bits in from the PPP Peer.

      The Attribute Value field of for this AVP to 0, or should not send the AVP at all.  An LNS that can
      also act as an LAC and place outgoing calls should set the
      appropriate bits in the Value field of this AVP. Presence of this
      message is not a guarantee that a given outgoing call will be
      placed by the sender if requested, just that has the physical
      capability exists.

   Tie Breaker following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|0|0|0|0|        14         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               5               | Tie Break Value...            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Value... LCP CONFREQ... (arbitrary number of octets)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    ...(64 bits)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Tie Breaker AVP within a Start-Control-Connection-Request
      contains a 64-bit Value used to break ties in tunnel establishment
      between an LAC-LNS pair.  The Attribute value is 5, indicating Tie
      Breaker, and is marked optional.  This AVP itself is optional.

      The 8 octet Value LCP CONFREQ 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 copy 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 body of the final CONFREQ



Townsley, et al.            Standards Track                    [Page 32]


INTERNET DRAFT                    L2TP                     February 1999


      received one.  The lower value "wins", and the "loser"
      MUST silently discard its tunnel.  In the case where a tie breaker
      is present on both sides, and from the value is equal, both sides MUST
      discard their tunnels.

      If a tie breaker is received, and client to complete LCP negotiation, starting at
      the outstanding Start-Control-
      Connection-Request had no tie breaker value, first option within the initiator which
      included body of the Tie Breaker LCP message.

      This AVP "wins". If neither side issues a Tie
      breaker, then two separate tunnels are opened.

      It is recommended that the Value may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
      is 6 plus the MAC address length of a
      LAN interface on the sender.  If no MAC address is available, a
      64-bit random number CONFREQ.

   Proxy Authen Type (ICCN)

      The Proxy Authen Type AVP, Attribute Type 29, determines if proxy
      authentication should be used instead.





Valencia                   expires June 1999                    [Page 34]

INTERNET DRAFT                                              October 1998


   Firmware Revision

       0                   1                   2                   3 used.

      The Attribute Value field for this AVP has the following format:

       0                   1 2 3 4 5 6 7 8 9
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               6
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Firmware Revision          Authen Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Authen Type is a 2 octet unsigned integer, holding:

      This AVP may be hidden (the H-bit may be 0 or 1). The Firmware Revision M-bit for
      this AVP within a Start-Control-Connection-
      Request indicates the firmware revision of the issuing device. MUST be set to 0.  The Attribute value is 6, indicating Firmware Revision, and Length (before hiding) of this AVP
      is
      marked optional. 8.

      Defined Authen Type values are:
         0 - Reserved
         1 - Textual username/password exchange
         2 - PPP CHAP
         3 - PPP PAP
         4 - No Authentication
         5 - Microsoft CHAP Version 1 (MSCHAPv1)

         This AVP itself MUST be present if proxy authentication is optional.  The Value field to be
         utilized. If it is
      a 16-bit integer encoded in a vendor specific format.  For devices
      which do not have present, then it is assumed that this
         peer cannot perform proxy authentication, requiring
         a firmware revision (general purpose computers
      running L2TP software modules, for instance), the revision restart of the
      L2TP software module authentication phase at the LNS if the client
         has already entered this phase with the
         LAC (which may be reported instead.

   Host determined by the Proxy LCP AVP if present)..

      Associated AVPs for each type of authentication follow.

   Proxy Authen Name (ICCN)

      The Proxy Authen Name AVP, Attribute Type 30, specifies the name
      of the authenticating client when using proxy authentication.




Townsley, et al.            Standards Track                    [Page 33]


INTERNET DRAFT                    L2TP                     February 1999


      The Attribute Value field for this AVP has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0| 6 + Host name len
      |               0 Authen Name... (arbitrary number of octets)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               7               | Host name...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Host

      Authen Name AVP within is a Start-Control-Connection-Request
      indicates the name string of octets of arbitrary length.  It
      contains the issuing LAC or LNS.  The Attribute value
      is 7, indicating Host Name, and is marked mandatory. name specified in the client's authentication
      response.

      This AVP
      itself MUST be present.  This name should be as broadly unique as
      possible; for hosts participating present in DNS [4], messages containing a hostname Proxy Authen
      Type AVP 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 an Authen Type of 1, 2, 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      3|0|0|0|0|0|0| 6+Vendor Name len|               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               8               | Vendor name...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Vendor Name or 5. It may be desirable
      to employ AVP within a Start-Control-Connection-Request
      contains a vendor specific string describing hiding for obscuring the type of LAC cleartext name.

      This AVP may be hidden (the H-bit may be 0 or
      LNS being used. 1). The Attribute value is 8, indicating Vendor Name,
      and is marked optional.  This M-bit for
      this AVP itself is optional. MUST be set to 0.  The Value Length (before hiding) is 6 plus
      the indicated number length of octets representing the vendor string.






Valencia                   expires June 1999                    [Page 35]

INTERNET DRAFT                                              October 1998


   Assigned Tunnel ID cleartext name.

   Proxy Authen Challenge (ICCN)

      The Proxy Authen Challenge AVP, Attribute Type 31, specifies the
      challenge sent by the LAC to the PPP Peer, when using proxy
      authentication.

      The Attribute Value field for this AVP has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               9
      |           Tunnel ID Challenge... (arbitrary number of octets)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Assigned Tunnel ID AVP within Challenge is a Start-Control-Connection-
      Request specifies the Tunnel ID which the receiving peer MUST use
      in the Tunnel ID field string of all subsequent packets.  The Attribute
      value is 9, indicating Assigned Tunnel ID, and is marked
      mandatory. one or more octets.

      This AVP MUST be present.  Before present for Proxy Authen Types 2 and 5. The
      Challenge field contains the Assigned Tunnel
      ID CHAP challenge presented to the
      client by the LAC.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
      this AVP is received, packets MUST be sent with a Tunnel set to 0.  The Length (before hiding) of this AVP
      is 6, plus the length of the Challenge.

   Proxy Authen ID (ICCN)

      The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value
      of
      0. the PPP Authentication that was started between the LAC and the



Townsley, et al.            Standards Track                    [Page 34]


INTERNET DRAFT                    L2TP                     February 1999


      PPP Peer, when proxy authentication is being used.

      The Attribute Value is a 16-bit non-zero Tunnel ID value.

   Receive Window Size

       0                   1                   2                   3 field for this AVP has the following format:

       0                   1 2 3 4 5 6 7 8 9
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              10   Reserved    |             Size      ID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Receive Window Size AVP within
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      ID is a Start-Control-Connection-
      Request specifies the receive window size being offered to 2 octet unsigned integer, the
      remote peer. most significant octet MUST
      be 0.

      The Attribute value is 10, indicating Receive Window
      Size, and is mandatory.  This Proxy Authen ID AVP itself is optional.  Value is a
      16-bit word indicating MUST be present for Proxy authen types 2,
      3 and 5. For 2 and 5, the offered window size.  If absent, ID field contains the
      peer must assume a byte ID value of 4 for
      presented to the client by the LAC in its transmit window.  The remote
      peer may send Challenge. For 3, it is
      the specified number Identifier value of control messages before it
      must wait the Authenticate-Request.

      This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for an acknowledgment.

   Challenge
      this AVP MUST be set to 0.

   Proxy Authen Response (ICCN)

      The Proxy Authen Response AVP, Attribute Type 33, specifies the
      PPP Authentication response received by the LAC from the PPP Peer,
      when proxy authentication is used.

      The Attribute Value field for this AVP has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0| 6 + Challenge len
      |               0 Response... (arbitrary number of octets)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              11               | Challenge...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Challenge AVP within Response is a Start-Control-Connection-Request
      indicates that string of octets.

      This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The
      Response field contains the issuing peer wishes client's response to authenticate the tunnel
      endpoints using a CHAP-style authentication mechanism.  The
      Attribute value is 11, indicating Challenge, challenge.
      For Proxy authen types 2 and 5, this field contains the response
      value received by the LAC. For types 1 or 3, it contains the clear
      text password received from the client by the LAC.  In the case of
      cleartext passwords, AVP hiding is marked
      mandatory. recommended.

      This AVP is optional. may be hidden (the H-bit may be 0 or 1). The Value M-bit for
      this AVP MUST be set to 0.  The Length (before hiding) of this AVP
      is one or more octets 6 plus the length of challenge value.




Valencia                   expires June 1999 the Response.




Townsley, et al.            Standards Track                    [Page 36] 35]


INTERNET DRAFT                                              October 1998


6.2 Start-Control-Connection-Reply (SCCRP)

   The Start-Control-Connection-Reply is an                    L2TP control message sent in
   reply to a received Start-Control-Connection-Request message. Sending                     February 1999


   4.3.6 Call Status AVPs

   Call Errors (WEN)

      The Call Errors AVP, Attribute Type 34, is used by the LAC to send
      error information to the LNS.

      The Attribute Value field for this message indicates that AVP has the request was successful.

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

   Start-Control-Connection-Reply following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|      8
      |               0         Reserved              |        CRC Errors (H)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                0         CRC Errors (L)        |               2        Framing Errors (H)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Protocol Version

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      |         Framing Errors (L)    |        Hardware Overruns (H)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|         8
      |               0         Hardware Overruns (L) |        Buffer Overruns (H)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               2         Buffer Overruns  (L)  |        Time-out Errors (H)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x01         Time-out Errors (L)   |     0x00        Alignment Errors (H)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Alignment Errors (L)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

         Reserved - Not used, MUST be present.






Valencia                   expires June 1999                    [Page 37]

INTERNET DRAFT                                              October 1998


   Framing Capabilities

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|        10         |
         CRC Errors - Number of PPP frames received with CRC errors
            since call was established
         Framing Errors - Number of improperly framed PPP packets
            received
         Hardware Overruns - Number of receive buffer over-runs since
            call was established
         Buffer Overruns - Number of buffer over-runs detected since
            call was established
         Time-out Errors - Number of time-outs since call was
            established
         Alignment Errors - Number of alignment errors since call was
            established

   This AVP may be hidden (the H-bit may be 0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               3               |     0x00      |     0x00      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x00      |0|0|0|0|0|0|A|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or 1). The Framing Capabilities M-bit for this
   AVP within a Start-Control-Connection-
      Reply indicates the type of framing that the sender MUST be set to 1.  The Length (before hiding) of this
      message can provide. AVP is 32.

   ACCM (SLI)




Townsley, et al.            Standards Track                    [Page 36]


INTERNET DRAFT                    L2TP                     February 1999


      The ACCM AVP, Attribute Type 35, is 3, it is a mandatory AVP, used by the Value field is a 32-bit quantity, LNS to inform LAC
      of the ACCM negotiated with two bits defined.  If
      bit A is set, asynchronous framing is supported.  If bit S is set,
      synchronous framing is supported.  This AVP MUST be present.

      More details on the use of PPP Peer by the LNS.

      The Attribute Value field for this AVP can be found in Sec. 6.1.

   Bearer Capabilities has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|        10
      |               0          Reserved             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Send ACCM (H)              |               4
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x00          Send ACCM   (L)      |     0x00    Receive ACCM (H)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     0x00      |0|0|0|0|0|0|A|D|          Receive ACCM  (H)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Bearer Capabilities AVP within

      Send ACCM and Receive ACCM are each 4 octet values preceeded by a Start-Control-Connection-
      Reply indicates
      2 octet reserved quantity. The send ACCM value should be used by
      the bearer capabilities that LAC to process packets it sends on the sender of this
      message can provide 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 outgoing calls. both
      these fields are 0xFFFFFFFF. The Attribute is 4, LAC should honor these fields
      unless it is
      a mandatory AVP, has specific configuration information to indicate that
      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. requested mask must be modified to permit operation.

      This AVP MUST may be
      present if outgoing calls can hidden (the H-bit MAY be placed by the sender of 1 or 0).  The M-bit for
      this
      message.

      More details on the use AVP MUST be set to 1.  The Length of this AVP can is 16.

   Private Group ID (ICCN)

      The Private Group ID AVP, Attribute Type 37, is used by the LAC to
      indicate that this call is to be found in Sec. 6.1.

   Firmware Revision associated with a particular
      customer group.

      The Attribute Value field for this AVP has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               6
      |       Firmware Revision    Private Group ID ... (arbitrary number of octets)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Valencia                   expires June 1999                    [Page 38]

INTERNET DRAFT                                              October 1998

      The Firmware Revision AVP within Private Group ID is a Start-Control-Connection-Reply
      indicates the firmware revision string of the issuing device. octets of arbitrary length.

      The
      Attribute is 6, it is not a mandatory AVP, LNS MAY treat the Value field is a
      16-bit integer encoded PPP session as well as network traffic
      through this session in a vendor specific format. special manner determined by the peer.
      For devices
      which do not have example, if the LNS is individually connected to several
      private networks using unregistered addresses, this AVP may be
      included by the LAC to indicate that a firmware revision (general purpose computers
      running given call should be



Townsley, et al.            Standards Track                    [Page 37]


INTERNET DRAFT                    L2TP software modules, for instance),                     February 1999


      associated with one of the revision private networks.

      The Private Group ID is a string corresponding to a table in the
      LNS that defines the particular characteristics of the
      L2TP software module selected
      group.  A LAC MAY determine the Private Group ID from a RADIUS
      response, local configuration, or some other source.

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

   Host Name 6 plus the length of the Private Group ID.

   Rx Connect Speed (ICCN, OCCN)

      The Rx Connect Speed AVP, Attribute Type 38, represents the speed
      of the connection from the perspective of the LAC (e.g. data
      flowing from the remote system to the LAC).

      The Attribute Value field for this AVP has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0| 6 + Host Name len |               0
      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           BPS (H)             |               7            BPS (L)            | Host Name...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Host Name AVP within
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      BPS is a Start-Control-Connection-Reply
      indicates 4 octet value indicating the name speed in bits per second.

      Presence of this AVP implies that the issuing LAC or LNS.  See the notes in
      section 6.1 concerning Host Name contents.  It is encoded as the
      Attribute 7, mandatory, connection speed may be
      asymmetric with respect to the indicated number of octets
      representing transmit connect speed given in the host name string.
      (Tx) Connect Speed AVP.

      This AVP MUST may be hidden (the H-bit MAY be present.

   Vendor Name

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|0|0|0|0| 6+Vendor Name len |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               8               |Vendor Name...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or 0).  The Vendor Name M-bit for
      this AVP within a Start-Control-Connection-Reply
      contains a vendor specific string describing the type MUST be set to 0.  The Length (before hiding) of LAC or
      LNS being used.  It this AVP
      is encoded as the 10.

   Sequencing Required (ICCN, OCCN)

      The Sequencing Required AVP, Attribute 8, not mandatory,
      with Type 39, indicates to the indicated number of octets representing
      LNS that Sequence Numbers MUST always be present on the vendor
      string. data
      channel.

      This AVP is optional.

   Assigned Tunnel ID

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               9               |           Tunnel ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ has no Attribute Value field.

      This AVP MUST NOT be hidden (the H-bit MUST be 0).  The Assigned Tunnel ID M-bit for
      this AVP within a Start-Control-Connection-Reply
      specifies the Tunnel ID which the receiving peer MUST use in all
      subsequent packets.  It is encoded as the Attribute 9, mandatory,



Valencia                   expires June 1999 be set to 1.  The Length of this AVP is 6.






Townsley, et al.            Standards Track                    [Page 39] 38]


INTERNET DRAFT                                              October 1998                    L2TP                     February 1999


5.0 Protocol Operation

   The necessary setup for tunneling a PPP session with L2TP consists of
   two steps, (1) establishing the Control Connection for a 16-bit non-zero Tunnel, and
   (2) establishing a Session as triggered by an incoming or outgoing
   call request. The Tunnel ID value.  This AVP and corresponding Control Connection MUST be present.

   Receive Window Size

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|         8
   established before an incoming or outgoing call is initiated. An L2TP
   Session MUST be established before L2TP can begin to tunnel PPP
   frames. Multiple Sessions may exist across a single Tunnel and
   multiple Tunnels may exist between the same LAC and LNS..

                            +-----+                               +-----+
                            |               0     |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~|     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            |              10 LAC |             size                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Receive Window Size AVP within a Start-Control-Connection-
      Reply specifies the receive window size being offered to the
      remote peer. LNS |
                            |     #######Control Connection########     |
   [Remote]                 |     |                               |     |
   [System]------Call----------*============L2TP Session=============*  |
     PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  |
                            |     |                               |     |
   [Remote]                 |     |                               |     |
   [System]------Call----------*============L2TP Session=============*  |
     PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  |
                            |     |                               |     |
                            |     |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|     |
                            +-----+                               +-----+

   Figure 5.1 Tunneling PPP

5.1 Control Connection Establishment

   The Attribute value is 10, indicating Receive Window
      Size, and is mandatory.  This AVP itself is optional.  Value Control Connection is a
      16-bit word indicating the offered window size.  If absent, the
      peer initial connection that must assume a value of 4 for its transmit window.  The remote
      peer be
   achieved between an LAC and LNS before sessions may send the specified number be brought up.
   Establishment of the control connection includes securing the
   identity of the peer, as well as identifying the peer's L2TP version,
   framing, and bearer capabilities, etc.

   A three message exchange is utilized to setup the control connection.
   Following is a typical message exchange:

      LAC or LNS  LAC or LNS
      ----------  ----------
      SCCRQ ->
                  <- SCCRP
      SCCCN ->
                  <- ZLB ACK

   The ZLB ACK is sent if there are no further messages before it
      must wait waiting in queue
   for an acknowledgment.

   Challenge

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0| 6 + Challenge len |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              11               | Challenge...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Challenge AVP within a Start-Control-Connection-Reply
      indicates that the peer peer.



Townsley, et al.            Standards Track                    [Page 39]


INTERNET DRAFT                    L2TP                     February 1999


   5.1.1 Tunnel Authentication

      L2TP incorporates a simple, optional, CHAP-like [RFC1994] tunnel
      authentication system during control connection establishment. If
      an LAC or LNS wishes to authenticate the tunnel
      initiator using identity of the peer it
      is contacting or being contacted by, a CHAP-style authentication mechanism.  It Challenge AVP is
      encoded as included
      in the Attribute 11, mandatory, with at least one octet of
      challenge value embedded. SCCRQ or SCCRP message. If this a Challenge AVP is not present, it
      indicates to received in
      an SCCRQ or SCCRP, a Challenge Response AVP MUST be sent in the receiving peer that
      following SCCRP or SCCCN, respectively. If the sender expected response
      and response received from a peer does not wish to
      authenticate that peer.

   Challenge Response

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|        22         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              13               |   Response...                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Response... (128 bits)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Response AVP within a Start-Control-Connection-Reply packet
      provides a response to a challenge received.  The Attribute value
      is 13, indicating Response, and match, establishment of
      the Value field is tunnel MUST be disallowed.

      To participate in tunnel authentication, a 128-bit value



Valencia                   expires June 1999                    [Page 40]

INTERNET DRAFT                                              October 1998


      reflecting the CHAP-style response to single shared secret
      MUST exist between the challenge. LAC and LNS. This is the same shared secret
      used for AVP
      marked mandatory, hiding (see Section 4.2).  See Section 4.3.3 for
      details on construction of the Challenge and MUST Response AVPs.

5.2 Session Establishment

   After successful control connection establishment, individual
   sessions may be present if a challenge was received
      and this Start-Control-Connection-Reply indicates success.  For
      purposes of created. Each session corresponds to single PPP
   stream between the ID value in LAC and LNS. Unlike control connection
   establishment, session establishment is directional with respect to
   the CHAP response calculation, LAC and LNS. The LAC requests the
      value 2 (corresponding LNS to accept a session for an
   incoming call, and the Value field of LNS requests the Start-Control-
      Connection-Reply AVP) MUST be used.

6.3 Start-Control-Connection-Connected (SCCCN)

   The Start-Control-Connection-Connected message is an L2TP control
   message sent in reply LAC to accept a received Start-Control-Connection-Reply
   message.  This session for
   placing an outgoing call.

   5.2.1 Incoming Call Establishment

      A three message provides closure exchange is employed to setup the tunnel establishment
   process, and includes session.
      Following is a challenge response if the peer typical sequence of events:

         LAC         LNS
         ---         ---
         (Call
          Detected)

         ICRQ ->
                  <- ICRP
         ICCN ->
                  <- ZLB ACK

      The ZLB ACK is sent a
   challenge if there are no further messages waiting in the Start-Control-Connection-Reply message.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
      queue for that peer.







Townsley, et al.            Standards Track                    [Page 40]


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

   Start-Control-Connection-Connected

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               0               |               3               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Challenge Response

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|        22         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              13               |   Response...                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Response... (128 bits)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Challenge Response AVP within a Start-Control-Connection-
      Connected packet provides a response to a challenge received.  The
      Attribute value is 13, indicating Response, and the Value field                     February 1999


   5.2.2 Outgoing Call Establishment

      A three message exchange is
      a 128-bit value reflecting the CHAP-style response employed to setup the
      challenge.  This AVP session.
      Following is marked mandatory, and MUST be present if a



Valencia                   expires June 1999                    [Page 41]

INTERNET DRAFT                                              October 1998


      challenge was received, otherwise MUST be omitted.  For purposes
      of the ID value in the CHAP response calculation, the value 3
      (corresponding to the Value field typical sequence of the Start-Control-
      Connection-Connected AVP) MUST be used.

6.4 Stop-Control-Connection-Notification (StopCCN) events:

         LAC         LNS
         ---         ---
                  <- OCRQ
         OCRP ->

         (Perform
          Call
          Operation)

         OCCN ->
                  <- ZLB ACK

      The Stop-Control-Connection-Notification ZLB ACK 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 if there are implicitly
   cleared.  The reason no further messages waiting in
      queue for issuing this request that peer.

5.3 Forwarding PPP Frames

   Once tunnel establishment is indicated complete, PPP frames from the remote
   system are received at the LAC, stripped of CRC, link framing, and
   transparency bytes, encapsulated in L2TP, and forwarded over the
   Result Code AVP.

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

   Stop-Control-Connection-Notification AVP

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               0               |               4               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   appropriate tunnel. The Message Type AVP contains LNS receives the L2TP packet, and processes
   the encapsulated PPP frame as if it were received on a Value of 4, indicating Stop-
      Control-Connection-Notification. local PPP
   interface.

   The Flags indicate sender of a mandatory
      option.

   Assigned Tunnel message associated with a particular session and
   tunnel places the Session ID

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               9               | and Tunnel ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Attribute value is 9, indicating Assigned Tunnel ID, (specified by its peer) in
   the Session ID and is
      marked mandatory.  This AVP MUST be present.  The Value Tunnel ID header for all outgoing messages. In
   this manner, PPP frames are multiplexed and demultiplexed over a
   single tunnel between a given LNS-LAC pair. Multiple tunnels may
   exist between a given LNS-LAC pair, and multiple sessions may exist
   within a tunnel.

   For the cases where a Session ID has not yet been assigned by the
   peer (i.e., during establishment of a new session or tunnel), the
   Session ID field MUST be sent as 0, and the same Assigned Session ID AVP
   or Assigned Tunnel ID first sent to the receiving peer.
      This AVP permits within the peer message MUST be used to identify
   the appropriate session or tunnel even
      if Stop-Control-Connection-Notification must when necessary. Similarly, for cases where the
   Tunnel ID has not yet been assigned from the peer, the Tunnel ID MUST
   be sent before an
      Assigned as 0. Thus, the value of 0 for Session ID and Tunnel ID is received.




Valencia                   expires June 1999
   special and MUST NOT be used as an Assigned Session ID or Assigned
   Tunnel ID.





Townsley, et al.            Standards Track                    [Page 42] 41]


INTERNET DRAFT                                              October 1998


   Result Code

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|  10 + Message len |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               1               |          Result Code          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Error Code          |      Optional Message ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Result Code AVP within a Stop-Control-Connection-Notification
      packet indicates                    L2TP                     February 1999


5.4 Using Sequence Numbers on the reason for terminating Data Channel

   Sequence numbers are defined in the L2TP header for control channel.
      It is encoded as Attribute 1, indicating a Result Code AVP.  This
      AVP is mandatory messages
   and MUST be present.  The Result Code is a 16-bit
      word.  The 16-bit word following the Result Code field contains
      the Error Code value, which optionally for data messages (see Section 3.1). These are used to
   provide a Stop-Control-Connection-
      Notification is always 0.  An reliable control message transport (see Section 5.8) and
   optional data message can follow sequencing. Each peer maintains separate
   sequence numbers for the
      Error Code field.  Its presence control connection and length is indicated by the
      value of each individual data
   session within a tunnel.

   Unlike the AVP length field.  Defined Result Code values are:

         1 - General request to clear L2TP control connection
         2 - General error--Error Code indicates channel, the problem
         3 - Control L2TP data channel already exists
         4 - Requester is does not authorized
   retransmit lost data messages. Sequence numbers may be provided and
   used to establish a control channel
         5 - detect data message loss or to reorder messages on the data
   channel.  The protocol version of LAC may request that sequence numbers be present in
   data messages via the requester Sequencing Required AVP (see Section 4.3.6). If
   this AVP is not supported
             Error Code indicates highest version supported
         6 - Requester present during session setup, sequence numbers MUST be
   present at all times. If this AVP is being shut down
         7 - Finite State Machine error

6.5 Hello

   The Hello message not present, sequencing presence
   is an L2TP under control message sent by either peer of a
   LAC-LNS control connection.  This control message is used as a
   "keepalive" for the tunnel. LNS. The sending of Hello messages LNS controls enabling and the policy for disabling
   of sequence numbers by sending them are
   left up to the implementation. A peer MUST NOT "expect" Hello
   messages a data message with or without
   sequence numbers present at any time or interval.  When a Hello is received, it MUST
   be ignored (after updating any effects of during the indicated Nr/Ns values,
   and being acknowleged).

   Since a Hello is life of a control message, and control messages are reliably
   sent by the lower level transport, this keepalive function operates
   by causing session.
   Thus, if the transport level to reliably deliver LAC receives a message. data message without sequence numbers
   present, it MUST stop sending sequence numbers in future data
   messages. If the LAC receives a
   media interruption has occurred, data message with sequence numbers
   present, it MUST begin sending sequence numbers in future outgoing
   data messages. If the reliable transport will be
   unable to deliver LNS enables sequencing after disabling it
   earlier in the Hello across, and will clean session, the sequence number state picks up where it
   left off before.

   The LNS may initiate disabling of sequencing at any time during the tunnel.

   Keepalives for
   session (including the tunnel MAY first data message sent). It is recommended
   that for connections where reordering or packet loss may occur,
   sequence numbers always be implemented by sending a Hello once
   every 60 seconds enabled during the initial negotiation
   stages of PPP and disabled only when and if 60 seconds have passed without receiving the risk is considered
   acceptable. For example, if the PPP session being tunneled is not
   utilizing any
   message (payload stateful compression or control, including ZLB messages) from encryption protocols and is
   only carrying IP (as determined by the peer.

   Hello messages PPP NCPs that are global to the tunnel;
   established), then the Call ID field LNS might decide to disable sequencing as IP
   is tolerant to datagram loss and reordering.

5.5 Keepalive (Hello)

   A keepalive mechanism is employed by L2TP in order to differentiate
   tunnel outages from extended periods of these



Valencia                   expires June 1999                    [Page 43]

INTERNET DRAFT                                              October 1998 no control messages MUST be 0.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    L2TP Control Message Header      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Hello                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or data activity
   on a tunnel. This is accomplished by injecting Hello

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               0               |               6               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Message Type AVP contains control messages
   (see Section 6.5) after a Value specified period of 6, indicating Hello The
      Flags indicate time has elapsed since
   the last data or control message was received on a mandatory option.

6.6 Outgoing-Call-Request (OCRQ)

   The Outgoing-Call-Request is an L2TP tunnel. As for any
   other control message, if the Hello message sent by is not reliably delivered
   then the LNS
   to tunnel is declared down and is reset. The transport reset
   mechanism along with the LAC to indicate injection of Hello messages ensures that an outbound call from a



Townsley, et al.            Standards Track                    [Page 42]


INTERNET DRAFT                    L2TP                     February 1999


   connectivity failure between the LNS is to be
   established.  This request provides and the LAC with information required
   to make the call.  It also provides information to will be detected at
   both ends of a tunnel.

5.6 Session Teardown

   Session teardown may be initiated by either the LAC that or LNS and is
   used to regulate the transmission of data to
   accomplished by sending a CDN control message. After the LNS for this last session
   once it
   is established.

   This cleared, the control connection MAY be torn down as well (and
   typically is). Following is an example of a typical control message
   exchange:

      LAC or LNS  LAC or LNS

      CDN ->
      (Clean up)

                  <- ZLB ACK
                     (Clean up)

5.7 Control Connection Teardown

   Control connection teardown may be initiated by either the LAC or LNS
   and is accomplished by sending a single StopCCN control message. The
   receiver of a StopCCN MUST send a ZLB ACK to acknowledge receipt of
   the first in message and maintain enough control connection state to properly
   accept StopCCN retransmissions over at least a full retransmission
   cycle (in case the "three-way handshake" used by L2TP
   for establishing outgoing calls. ZLB ACK is lost). The first recommended time for a full
   retransmission cycle is 31 seconds (see section 5.8). Following is an
   example of a typical control message requests exchange:

      LAC or LNS  LAC or LNS

      StopCCN ->
      (Clean up)

                  <- ZLB ACK
                     (Wait)
                     (Clean up)

   An implementation may shut down an entire tunnel and all sessions on
   the
   call; tunnel by sending the second indicates that StopCCN. Thus, it is not necessary to clear
   each session individually when tearing down the call was successfully initiated. whole tunnel.

5.8 Reliable Delivery of Control Messages

   L2TP provides a lower level reliable transport service for all
   control messages. The third Nr and final message indicates that Ns fields of the call was established.

   An LNS MUST have received a Bearer Capabilities AVP during tunnel
   establishment from an LAC in order to request an outgoing call control message header
   (see section 3.1) belong to
   that LAC.



















Valencia                   expires June 1999 this transport.  The upper level



Townsley, et al.            Standards Track                    [Page 44] 43]


INTERNET DRAFT                                              October 1998


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

   Outgoing-Call-Request

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               0               |               7               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Message Type AVP contains a Value                     February 1999


   functions of 7, indicating Outgoing-
      Call-Request. L2TP are not concerned with retransmission or ordering
   of control messages. The Outgoing-Call-Request encodes reliable control message is a request to an
      LAC to establish an outgoing call.  The flags indicate sliding window
   transport that provides control message retransmission and congestion
   control.  Each peer maintains separate sequence number state for the
   control connection within a mandatory
      option.

      Assigned Call ID

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              14               |            Call ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ tunnel.

   The Assigned Call ID AVP encodes message sequence number, Ns, begins at 0. Each subsequent message
   is sent with the ID being assigned to this
      call by next increment of the LNS. sequence number.  The Attribute value sequence
   number is 14, indicating Assigned
      Call ID, and is marked mandatory.  This AVP MUST be present. thus a free running counter represented modulo 65536. The
      LAC places this value
   sequence number in the Call ID header field of all command a received message is considered
   less than or equal to the last received number if its value lies in
   the range of the last received number and payload packets that it subsequently transmits over the tunnel
      that belong to this call. preceding 32767 values,
   inclusive. For example, if the last received sequence number was 15,
   then messages with sequence numbers 0 through 15, as well as 32784
   through 65535, would be considered less than or equal. Such a message
   would be considered a duplicate of a message already received and
   dropped silently.

   All control messages take up one slot in the control message sequence
   number space, except the ZLB acknowledgement. Thus, Ns is not
   incremented after a ZLB message is sent.

   The Call ID value last received message number, Nr, is an identifier
      assigned used to acknowledge messages
   received by an L2TP peer. It contains the LNS sequence number of the
   message the peer expects to this session.  It receive next (e.g. the last Ns of a non-
   ZLB message received plus 1, modulo 65536).  While the Nr in a
   received ZLB is used to multiplex and
      demultiplex data flush messages from the local retransmit
   queue (see below), Nr of the next message sent over that tunnel between is not be updated by
   the LNS Ns of the ZLB.

   The reliable transport at a receiving peer is responsible for making
   sure that control messages are delivered in order and LAC.







Valencia                   expires June 1999                    [Page 45]

INTERNET DRAFT                                              October 1998


      Call Serial Number

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              15               |           CSN (H)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            CSN (L)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Call Serial Number AVP encodes an identifier assigned by the LNS to
      this call.  Attribute is 15, indicating Call Serial Number, and is
      marked mandatory.  This AVP MUST be present.  The Call Serial Number
      is intended without
   duplication to the upper level. Messages arriving out of order may be an easy reference
   queued for administrators on both ends of in-order delivery when the missing messages are received,
   or they may be discarded requiring a retransmission by the peer.

   Each tunnel maintains a queue of control messages to use when investigating call failure problems.  Call Serial
      Numbers should be set transmitted
   to progressively increasing values, its 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 are
      likely to be unique for the Nr field indicates receipt of this message. After a significant
   period of time across all
      interconnected LNS and LACs.  Other identification information may
      also be prepended.

      Minimum BPS

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 (a recommended default is 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              16               |           BPS (H)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            BPS (L)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Minimum BPS AVP encodes second) passes without
   acknowledgement, the lowest acceptable line speed for this
      call.  Attribute is 16, Minimum BPS, and message is marked mandatory.
      This AVP MUST be present. retransmitted. The BPS retransmitted
   message contains the same Ns value, but the Nr value indicates MUST be updated
   with 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 sequence number of the next expected message.

   Each subsequent retransmission of a message MUST employ an
   exponential backoff interval. Thus, if the first retransmission
   occurred after 1 second, the next retransmission should occur after 2 3



Townsley, et al.            Standards Track                    [Page 44]


INTERNET DRAFT                    L2TP                     February 1999


   seconds has elapsed, then 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              17               |           BPS (H)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            BPS (L)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Maximum BPS AVP encodes seconds, etc. An implementation MAY place
   a cap upon the highest acceptable line speed for this
      call.  Attribute maximum interval between retransmissions. This cap
   MUST be no less than 8 seconds per retransmission.  If no peer
   response is 17, indicating Maximum BPS, detected after several retransmissions, (a recommended
   default is 5, but SHOULD be configurable), the tunnel and all
   sessions within MUST be cleared.

   When a tunnel is marked
      mandatory.  This AVP being shut down for reasons other than loss of
   connectivity, the state and reliable delivery mechanisms MUST be present.  The BPS value indicates
   maintained and operated for the



Valencia                   expires June 1999                    [Page 46]

INTERNET DRAFT                                              October 1998


      speed in bits/second.

      Bearer Type

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              18               |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Bearer Type AVP encodes the bearer type for full retransmission interval after
   the requested call.
      The Attribute is 18, indicating Bearer Type, and final message exchange has occurred.

   A sliding window mechanism is marked
      mandatory.  This used for control message transmission.
   Consider two peers A & B. Suppose A specifies a Receive Window Size
   AVP MUST be present.  The Value is with a 32-bit
      quantity indicating value of N in the bearer capability required SCCRQ or SCCRP messages. B is now
   allowed to have up to N outstanding control messages. Once N have
   been sent, it must wait for this
      outgoing call.  If set, bit A indicates that the call should be on an analog channel.  If set, bit D indicates acknowledgment that advances the call should
      be on a digital channel.  Both
   window before sending new control messages.  An implementation may be set, indicating that the
      call can be of either type.

      A particular bit in the Value field
   support a receive window of this AVP MAY only be set 1 (i.e., by
      the LNS if it was set in the Bearer Capabilities sending out a Receive
   Window Size AVP received from
      the LAC during control session establishment.

      Framing Type

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 with a value of 1), but MUST accept a window of up to
   4 5 6 7 8 9 0 1 2 3 from its peer (e.g. have the ability to send 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|        10         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              19               |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 0 0 0 0 0 0 0 0 0 messages before
   backing off). A value of 0 0|A|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Framing Type AVP encodes the framing type for the requested call.
      Attribute Receive Window Size AVP is 19, indicating Framing Type,
   invalid.

   When retransmitting control messages, a slow start and is marked mandatory.
      This AVP MUST congestion
   avoidance window adjustment procedure SHOULD be present. utilized. The 32-bit field indicates the type of
      PPP framing to be used
   recommended procedure for the outgoing call.  If set, Bit this is described in Appendix A.

   A
      indicates that asynchronous framing should be used.  If set, Bit S
      indicates that synchronous framing should be used.  Both may be
      set, indicating that either type peer MUST NOT withhold acknowledgment of framing may be used messages as a technique
   for the
      call.

      A particular bit in the Value field of this AVP MAY only flow controlling control messages.  An L2TP implementation is
   expected to be set by
      the LNS if it was set in the Framing Capabilities AVP received
      from the LAC during able to keep up with incoming control session establishment.






Valencia                   expires June 1999                    [Page 47]

INTERNET DRAFT                                              October 1998


      Receive Window Size

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              10               |             Size              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Receive Window Size AVP encodes the window size being advertised
      by messages,
   possibly responding to some with errors reflecting an inability to
   honor the LNS requested action.

   Appendix B contains examples of control message transmission,
   acknowledgement, and retransmission.

6.0 Control Connection Protocol Specification

   The following control connection messages are used to establish,
   clear and maintain L2TP tunnels. 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 this call.  Attribute protocol extensibility.

6.1 Start-Control-Connection-Request (SCCRQ)

   Start-Control-Connection-Request (SCCRQ) is 10, indicating Receive
      Window Size, a control message used to
   initialize a tunnel between an LNS and an LAC. It is marked mandatory.  This AVP is optional.  The
      Size value indicates sent by either



Townsley, et al.            Standards Track                    [Page 45]


INTERNET DRAFT                    L2TP                     February 1999


   the number of received data packets LAC or the LNS
      will buffer for this call, which is also the maximum number of
      data packets to being the LAC should send before waiting for an
      acknowledgment. tunnel establishement process.

   The absence of this following AVPs MUST be present in the SCCRQ:

      Message Type AVP indicates that Sequence
      and Acknowledgment Numbers are not to
      Protocol Version
      Host Name
      Framing Capabilities
      Assigned Tunnel ID

   The Following AVPs MAY be used present in the payload
      session for this call.

      Packet Processing Delay

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0|         8         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              20               |             Delay             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Packet Processing Delay AVP encodes the delay that SCCRQ:

      Bearer Capabilities
      Receive Window Size
      Challenge
      Tie Breaker
      Firmware Revision
      Vendor Name

6.2 Start-Control-Connection-Reply (SCCRP)

   Start-Control-Connection-Reply (SCCRP) is expected
      at the LNS in processing a window full of packets control message sent by the LAC.
      Attribute is 20, indicating Packet Processing Delay, and is marked
      mandatory.  This AVP is optional.  The Delay value is specified in
      units of 1/10 seconds.  Refer
   reply to Appendix A for a description of
      how this value received SCCRQ message. SCCRP is determined and used.

      Dialed Number

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0| 6+Phone Number len|               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              21               | Phone Number..
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Phone Number AVP encodes the phone number used to be called.  Attribute
      is 21, indicating Phone Number, indicate that the
   SCCRQ was accepted and is marked mandatory.  This AVP establishment of the tunnel should continue.

   The following AVPs MUST be present. present in the SCCRP:

      Message Type
      Protocol Version
      Framing Capabilities
      Host Name
      Assigned Tunnel ID

   The Phone Number value following AVPs MAY be present in the SCCRP:

      Bearer Capabilities
      Firmware Revision
      Vendor Name
      Receive Window Size
      Challenge
      Challenge Response

6.3 Start-Control-Connection-Connected (SCCCN)

   Start-Control-Connection-Connected (SCCCN) is a control message sent
   in reply to an ASCII string.
      Contact between the administrator of the LAC and SCCRP. SCCCN completes the LNS may tunnel establishment
   process.




Townsley, et al.            Standards Track                    [Page 46]


INTERNET DRAFT                    L2TP                     February 1999


   The following AVP MUST be
      necessary to coordinate the value needed present in this AVP.





Valencia                   expires June 1999                    [Page 48]

INTERNET DRAFT                                              October 1998


      Sub-Address

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0| 6+Sub-Address len |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              23               |Sub-Address ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Sub-Address AVP encodes additional dialing information.  Attribute
      is 23, indicating Sub-Address, and is marked mandatory.  This AVP
      is optional. the SCCCN:

      Message Type

   The Sub-Address value is an ASCII string. Contact
      between following AVP MAY be present in the administrator of SCCCN:

      Challenge Response

6.4 Stop-Control-Connection-Notification (StopCCN)

   Stop-Control-Connection-Notification (StopCCN) is a control message
   sent by either the LAC or LNS to inform its peer that the tunnel is
   being shutdown and the LNS may control connection should be necessary closed. In
   addition, all active sessions are implicitly cleared (without sending
   any explicit call control messages). The reason for issuing this
   request is indicated in the Result Code AVP. There is no explicit
   reply to coordinate the value needed message, only the implicit ACK that is received by the
   reliable control message transport layer.

   The following AVPs MUST be present in this AVP.

6.7 Outgoing-Call-Reply (OCRP) the StopCCN:

      Message Type
      Assigned Tunnel ID
      Result Code

6.5 Hello (HELLO)

   The Outgoing-Call-Reply Hello (HELLO) message is an L2TP control message sent by the LAC to
   the LNS in response to either
   peer of a received Outgoing-Call-Request message. The
   reply indicates that the LAC LAC-LNS control connection. This control message is able to attempt used as
   a "keepalive" for the outbound call tunnel.

   The sending of HELLO messages and
   also returns certain parameters regarding the call attempt.

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

   Outgoing-Call-Reply

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |               8               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Message Type AVP contains policy for sending them are
   left up to the implementation. A peer MUST NOT expect HELLO messages
   at any time or interval. As with all messages sent on the control
   connection, the receiver will return either a Value of 8, indicating Outgoing-
   Call-Reply.  The Outgoing-Call-Reply ZLB ACK or an
   (unrelated) message encodes piggybacking the immediate
   result of attempting an outgoing call request.  The flags indicate necessary acknowledgement
   information.

   Since a
   mandatory option.











Valencia                   expires June 1999                    [Page 49]

INTERNET DRAFT                                              October 1998


   Assigned Call ID

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              14               |            Call ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Assigned Call ID AVP encodes the ID being assigned to this call
   by the LAC.  Attribute HELLO is 14, indicating Assigned Call ID, a control message, and is
   marked mandatory.  This AVP MUST be present.  Call ID value is an
   identifier, unique within the tunnel, assigned control messages are reliably
   sent by the sender to this
   session.  The remote peer MUST place lower level transport, this Call ID in keepalive function operates
   by causing the Call ID
   portion of all future packets it sends associated with this session.
   It is used transport level to multiplex and demultiplex data sent over that tunnel
   between reliably deliver a message. If a
   media interruption has occurred, the LNS reliable transport will be
   unable to deliver the HELLO across, and LAC.

   Physical Channel ID

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0|        10         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              25               |            ID (H)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          ID (L)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Physical Channel ID AVP encodes will clean up the vendor specific physical channel
   number used tunnel.

   Keepalives for the call.  The Attribute value is 25, indicating
   Physical Channel ID, and is marked optional.  This AVP itself tunnel MAY be implemented by sending a HELLO if a
   period of time (a recommended default is
   optional. 60 seconds, but SHOULD be
   configurable) has passed without receiving any message (data or
   control) from the peer.



Townsley, et al.            Standards Track                    [Page 47]


INTERNET DRAFT                    L2TP                     February 1999


   HELLO messages are global to the tunnel. The Session ID is a 32-bit value in network byte order. a HELLO
   message MUST be 0.

   The value is
   used for logging purposes only.

6.8 Outgoing-Call-Connected (OCCN)

   Outgoing-Call-Connected Following AVP MUST be present in the HELLO message:

      Message Type

6.6 Incoming-Call-Request (ICRQ)

   Incoming-Call-Request (ICRQ) is an L2TP a control message sent by the LAC to
   the LNS when an incoming call is detected. It is the first in a three
   message exchange used for establishing a session within an L2TP
   tunnel.

   ICRQ is used to indicate that the result of a requested outgoing call was
   successful.  The LAC MUST send the corresponding Outgoing-Call-Reply session is to be established between
   the LAC and LNS before sending for this message.  This message call and provides the LNS with parameter
   information to for the session.  The LAC may defer answering the call
   until it has received an ICRP from the LNS indicating that the
   session should be established.  This mechanism allows the LNS to
   obtain sufficient information about the particular parameters used for call before determining
   whether it should be answered or not. Alternatively, the LAC may
   answer the call, negotiate LCP and PPP authentication, and use the
   call.  It provides
   information gained to allow choose the LNS. In this case, the call has
   already been answered by the time the ICRP message is received; the
   LAC simply spoofs the "call indication" and "call answer" steps in
   this case.

   The following AVPs MUST be present in the ICRQ:

      Message Type
      Assigned Session ID
      Call Serial Number

   The following AVPs MAY be present in the ICRQ:

      Bearer Type
      Physical Channel ID
      Calling Number
      Called Number
      Sub-Address

6.7 Incoming-Call-Reply (ICRP)

   Incoming-Call-Reply (ICRP) is a control message sent by the LNS to regulate
   the
   transmission of data LAC in response to a received ICRQ message. It is the LAC second in
   the three message exchange used for this session.











Valencia                   expires June 1999 establishing sessions within an
   L2TP tunnel.




Townsley, et al.            Standards Track                    [Page 50] 48]


INTERNET DRAFT                                              October 1998


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

   Outgoing-Call-Connected

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |               9               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The                     February 1999


   ICRP is used to indicate that the ICRQ was successful and for the LAC
   to answer the call if it has not already done so. It also allows the
   LNS to indicate necessary parameters for the L2TP session.

   The following AVPs MUST be present in the ICRP:

      Message Type AVP contains
      Assigned Session ID

6.8 Incoming-Call-Connected (ICCN)

   Incoming-Call-Connected (ICCN) is a Value of 9, indicating Outgoing-
   Call-Connected.  The Outgoing-Call-Connected control message encodes the
   final result of an outgoing call request.  The flags indicate a
   mandatory option.

   (Tx) Connect Speed

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|        10         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              24               |            BPS (H)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           BPS (L)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   (Tx) Connect Speed BPS AVP encodes the speed of sent by the facility chosen
   for LAC
   to the connection attempt.  The Attribute value is 24, indicating
   (Tx) Connect Speed, and is marked mandatory. This AVP MUST be
   present.  BPS is LNS in response to a 32-bit value indicating received ICRP message. It is the speed third
   message in bits/second.

   When the optional Rx Connect Speed AVP three message exchange used for establishing sessions
   within an L2TP tunnel.

   ICCN is present, used to indicate that the value in this
   AVP represents ICRP was accepted, the transmit connect speed, from call has
   been answered, and that the perspective of
   the LAC (e.g. data flowing from L2TP session should move to the LAC
   established state.  It also provides additional information to the client).  When
   LNS about parameters used for the
   optional answered call (parameters that may
   not always available at the time the ICRQ is issued).

   The following AVPs MUST be present in the ICCN:

      Message Type
      (Tx) Connect Speed
      Framing Type

   The following AVPs MAY be present in the ICCN:

      Initial Received LCP CONFREQ
      Last Sent LCP CONFREQ
      Last Received LCP CONFREQ
      Proxy Authen Type
      Proxy Authen Name
      Proxy Authen Challenge
      Proxy Authen ID
      Proxy Authen Response
      Private Group ID
      Rx Connect Speed AVP
      Sequencing Required

6.9 Outgoing-Call-Request (OCRQ)

   Outgoing-Call-Request (OCRQ) is NOT present, a control message sent by the connection speed
   between LNS to
   the LAC to indicate that an outbound call from the client and LAC is assumed to be symmetric and
   established. It is
   represented by the single value first in this AVP.





Valencia                   expires June 1999 a three message exchange used for
   establishing a session within an L2TP tunnel.



Townsley, et al.            Standards Track                    [Page 51] 49]


INTERNET DRAFT                                              October 1998


   Framing Type

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|        10         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              19               |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Framing Type AVP encodes                    L2TP                     February 1999


   OCRQ is used to indicate that a session is to be established between
   the framing type LNS and LAC for the call.  The
   Attribute value is 19, indicating Framing Type, this call and is marked
   mandatory.  This AVP MUST be present.  The bit field indicates provides the
   type of PPP framing used LAC with parameter
   information for both the call.  If set, bit A indicates L2TP session, and the call that
   asynchronous framing is being used.  If set, bit S indicates to be
   placed

   An LNS MUST have received a Bearer Capabilities AVP during tunnel
   establishment from an LAC in order to request an outgoing call to
   that
   synchronous framing is being used. A particular type of framing may LAC.

   The following AVPs MUST be used only if it was specified present in the OCRQ:

      Message Type
      Assigned Session ID
      Call Serial Number
      Minimum BPS
      Maximum BPS
      Bearer Type
      Framing Type AVP of the
   Outgoing-Call-Request issued by the LNS.
      Called Number

   The framing type following AVPs MAY be used
   as an indication to PPP on the LNS as to what link options to use for
   LCP (refer to "PPP present in HDLC-like Framing" [14]).

   Receive Window Size

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              10               |            Size               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Receive Window Size AVP encodes the window size being offered OCRQ:

      Sub-Address

6.10 Outgoing-Call-Reply (OCRP)

   Outgoing-Call-Reply (OCRP) is a control message sent by the LAC to
   the LNS for this call.  The Attribute value is 10, indicating Receive
   Window Size, and is marked mandatory.  The Size is in response to a 16-bit value
   indicating the number of received data packets OCRQ message. It is the LAC will buffer second in a
   three message exchange used for this call, which establishing a session within an L2TP
   tunnel.

   OCRP is also the maximum number of data packets used to indicate that the
   LNS should send before waiting for an acknowledgment.  This AVP LAC is
   present only if Sequence and Acknowledgment Numbers are able to attempt the outbound
   call and returns certain parameters regarding the call attempt.

   The following AVPs MUST be used present in the payload session for this call.

   Packet Processing Delay

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              20               |             Delay             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet Processing Delay AVP encodes the delay OCRP:

      Message Type
      Assigned Session ID

   The following AVPs MAY be present in the LAC expects for
   processing OCRP:

      Physical Channel ID

6.11 Outgoing-Call-Connected (OCCN)

   Outgoing-Call-Connected (OCCN) is a window full of packets control message sent by the LNS.  The Attribute



Valencia                   expires June 1999 LAC
   to the LNS following the OCRP and after the outgoing call has been
   completed.  It is the final message in a three message exchange used



Townsley, et al.            Standards Track                    [Page 52] 50]


INTERNET DRAFT                                              October 1998


   value is 20, indicating Packet Processing Delay, and is marked
   mandatory.  This AVP is optional.  The Delay value                    L2TP                     February 1999


   for establishing a session within an L2TP tunnel.

   OCCN is specified in
   units of 1/10 seconds.  Refer to Appendix A used to see a description indicate that the result of
   how this value is determined and used.

   Rx Connect Speed

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0|        10         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              38               |            BPS (H)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           BPS (L)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Rx Connect Speed BPS AVP encodes a requested outgoing call
   was successful. It also provides information to the receive speed of LNS about the facility
   chosen for
   particular parameters obtained after the connection attempt. call was established.

   The Attribute value is 38,
   indicating Rx following AVPs MUST be present in the OCCN:

      Message Type
      (Tx) Connect Speed, and is marked optional. Speed
      Framing Type

   The following AVPs MAY be present in the OCCN:

      Rx Connect Speed represents
      Sequencing Required

6.12 Call-Disconnect-Notify (CDN)

   The Call-Disconnect-Notify (CDN) message is an L2TP control message
   sent by either the speed LAC or LNS to request disconnection of a specific
   call within the connection from tunnel. Its purpose is to inform the perspective peer of the LAC (e.g. data flowing from
   disconnection and the client to reason why the LAC).  Presence disconnection occurred. The peer
   MUST clean up any resources, and does not send back any indication of
   this AVP implies that the connection speed may
   success or failure for such cleanup.

   The following AVPs MUST be asymmetric, with present in the transmit connect speed given CDN:

      Message Type
      Result Code
      Assigned Session ID

   The following AVPs MAY be present in the (Tx) Connect Speed AVP.  BPS CDN:

      Q.931 Cause Code

6.13 WAN-Error-Notify (WEN)

   The WAN-Error-Notify message is a 32-bit value indicating an L2TP control message sent by the speed
   LAC to the LNS to indicate WAN error conditions (conditions that
   occur on the interface supporting PPP). The counters in bits/second.

   Sequencing Required

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|          6        |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              39               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Sequencing Required AVP indicates to the LNS that Sequence
   Numbers MUST always this message
   are cumulative. This message should only be present, thus the ability to dynamically drop
   sequencing as described in section 4.2 is not sent when an available option.
   The Attribute value is 38, Sequencing Required, error
   occurs, and is marked
   mandatory. not more than once every 60 seconds. The presence of this AVP counters are
   reset when a new call is optional.  This AVP established.

   The following AVPs MUST NOT be present if in the Receive Window Size AVP is not present. There is no
   value field.

6.9 Incoming-Call-Request (ICRQ)

   Incoming-Call-Request WEN:

      Message Type



Townsley, et al.            Standards Track                    [Page 51]


INTERNET DRAFT                    L2TP                     February 1999


      Call Errors

6.14 Set-Link-Info (SLI)

   The Set-Link-Info message 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 LAC to set PPP-negotiated options.  These options can change
   at any time during the LNS with parameter information
   for life of the incoming call.

   This message is call, thus the first LAC MUST be able to
   update its internal call information and behavior on an active PPP
   session.

   The following AVPs MUST be present in the "three-way handshake" used SLI:

      Message Type
      ACCM

7.0 Control Connection State Machines

   The control messages defined in section 6 are exchanged by L2TP way of
   state tables defined in this section. Tables are defined for establishing incoming calls.  The LAC may defer answering the
   call until it has received an Incoming-Call-Reply from placement, outgoing call placement, as well as for initiation of
   the LNS



Valencia                   expires June 1999                    [Page 53]

INTERNET DRAFT                                              October 1998


   indicating that tunnel itself.  The state tables do not encode timeout and
   retransmission behavior, as this is handled in the call should be established. underlying
   semantics defined in Section 5.8.

7.1 Control Connection Protocol Operation

   This mechanism
   allows the LNS to obtain sufficient information about section describes the call before
   determining whether operation of various L2TP control
   connection functions and the call Control Connection messages which are
   used to support them.

   Receipt of an invalid or malformed Control Connection message should
   be answered or not.
   Alternatively, the LAC may answer logged appropriately, and the call, negotiate LCP control connection should be closed
   and PPP
   authentication, restarted to ensure recovery into a known state.

   In several cases in the following tables, a protocol message is sent,
   and use then a "clean up" occurs.  Note that regardless of the information gained initiator
   of the tunnel destruction, the reliable delivery mechanism must be
   allowed to choose run (see Section 5.8) before destroying the LNS.  In
   this case, tunnel. This
   permits the call has already been answered by tunnel management messages to be reliably delivered to
   the time peer.

   Appendix B.1 contains an example of lock-step tunnel establishment.

7.2 Control Connection States

   The L2TP control connection protocol is not distinguishable between
   the
   Incoming-Call-Reply message LNS and LAC, but is received; distinguishable between the LAC simply spoofs originator and
   receiver. The originating peer is the
   "call indication/answer call" phase in this case.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | one which first initiates



Townsley, et al.            Standards Track                    [Page 52]


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

   Incoming-Call-Request

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |              10               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Message Type AVP contains a Value                     February 1999


   establishment of 10, indicating Incoming-
   Call-Request.  The Incoming-Call-Request message encodes an incoming
   call being indicated by the LAC.  The flags indicate tunnel (in a mandatory
   option.

   Assigned Call ID

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              14               |            Call ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Assigned Call ID AVP encodes the ID being assigned to tie breaker situation, this call
   by the LAC.  The Attribute value is 14, indicating Assigned Call ID,
   and is marked mandatory.  This AVP MUST be present.  The the
   winner of the tie). Since either LAC or LNS places
   this value in can be the Call ID header field originator, a
   collision can occur. See the Tie Breaker AVP in Section 4.3.3 for a
   description of all command and payload
   packets that belong to this call and are subsequently transmitted
   over the tunnel.  The Call ID value is an identifier assigned by the



Valencia                   expires June 1999                    [Page 54] its resolution.

7.2.1 Control Connection Establishment

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

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

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

   idle            Receive SCCRP     Send StopCCN         idle
                                     Clean up

   idle            Receive SCCCN     Clean up             idle


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

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

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

   wait-ctl-reply  Receive SCCCN     Send StopCCN         idle
                                     Clean up

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

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

   wait-ctl-conn   Receive SCCRP,    Send StopCCN,        idle
                   SCCRQ             Clean up



Townsley, et al.            Standards Track                    [Page 53]


INTERNET DRAFT                                              October 1998


   LAC                    L2TP                     February 1999


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

   established     Admin             Send StopCCN         idle
                   Tunnel Close      Clean up

   established     Receive SCCRQ,    Send StopCCN         idle
                   SCCRP, SCCCN      Clean up

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


   The states associated with the LNS or LAC for control connection
   establishment are:

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

   wait-ctl-reply
      The originator checks to multiplex and demultiplex data
   sent over that tunnel between see if another connection has been
      requested from the LNS same peer, and LAC.

   Call Serial Number

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|        10         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              15               |           CSN (H)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            CSN (L)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Call Serial Number AVP encodes an identifier assigned by if so, handles the LAC to
   this call.  The Attribute value collision
      situation described in Section 5.8.

      When an SCCRP is 15, Call Serial Number, and received, it is
   marked mandatory.  This AVP MUST be present.  Please refer to section
   6.6 examined for a description of compatible
      version. If the contents version of this AVP.

   Bearer Type

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|          10       |                0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              18               |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Bearer Type AVP encodes the bearer type for the incoming call.  The
   Attribute value is 18, Bearer Type, and is marked mandatory.  This
   AVP is optional.  The Value reply is a 32-bit field indicating lower than the bearer
   capability being used by version
      sent in the incoming call.  If set, bit A indicates
   that request, the call older (lower) version should be used
      provided it is on an analog channel. supported.  If set, bit D indicates that the call is on a digital channel. It version in the reply is valid earlier
      and supported, the originator moves to set neither the A
   nor D bits. Such a setting may indicate that established state.  If
      the call was version is earlier and not
   received over supported, a physical link (e.g if StopCCN MUST be sent
      to the LAC peer and PPP are located in
   the same subsystem).

   Physical Channel ID

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0|          10       |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              25               |            ID (H)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          ID (L)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Valencia                   expires June 1999                    [Page 55]

INTERNET DRAFT                                              October 1998


   Physical Channel ID AVP encodes the vendor specific physical channel
   number used for the call.  The Attribute value is 25, Physical
   Channel ID, originator cleans up and terminates the
      tunnel.

   wait-ctl-conn
      This is marked optional.  The presence of this AVP is
   optional.  ID is a 32-bit value in network byte order.  The value where an SCCCN is
   used for logging purposes only.

   Dialed Number

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0| 6+Phone Number len|               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              21               | Phone Number..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Dialed Number AVP encodes the dialed number for awaited; upon receipt, the incoming call,
   that is, DNIS.  The Attribute value is 21, Dialed Number, and challenge
      response is
   marked mandatory. checked. The presence of this AVP tunnel either is optional.  The value established, or is torn
      down if an ASCII string.

   Dialing Number

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0| 6+Phone Number len|               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              22               |Phone Number...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Dialing Number AVP encodes the originating number for the incoming
   call, that is, CLID.  The Attribute value is 22, Dialing Number, and
   is marked mandatory.  The presence of this AVP is optional.  The
   value authorization failure is an ASCII string.  Contact between the administrator of the
   LAC and the LNS detected.

   established
      An established connection may be necessary to coordinate terminated by either a local
      condition or the value needed in
   this AVP.

   Sub-Address

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0| 6+Sub-Address len |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              23               |Sub-Address ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Sub-Address AVP encodes additional dialing information.  The
   Attribute value is 23, Sub-Address, and is marked mandatory.  The
   presence receipt of this AVP is optional.  The Sub-Address value is an ASCII
   string.  Contact between a Stop-Control-Connection-
      Notification. In the administrator event of a local termination, the LAC originator
      MUST send a Stop-Control-Connection-Notification and clean up the LNS may
   be necessary to coordinate the value needed in this AVP.




Valencia                   expires June 1999



Townsley, et al.            Standards Track                    [Page 56] 54]


INTERNET DRAFT                                              October 1998


6.10 Incoming-Call-Reply (ICRP)

   The Incoming-Call-Reply is an                    L2TP control message sent by the LNS to                     February 1999


      tunnel.

      If the LAC in response to originator receives a received Incoming-Call-Request message.  The
   reply indicates that the request was successful.  It Stop-Control-Connection-Notification
      it MUST also provides
   information to allow clean up the LAC tunnel.

7.3 Timing considerations

   Due to regulate the transmission of data to real-time nature of telephone signaling, both the LNS for this session.

   This 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 5.8.

7.4 Incoming calls

   An Incoming-Call-Request message is the second in the three-way handshake used generated by L2TP
   for establishing incoming calls.  It indicates to the LAC that when an
   incoming call is detected (for example, an associated telephone line
   rings). The LAC selects a Session ID and serial number and indicates
   the call bearer type. Modems should always indicate analog call type.
   ISDN calls should indicate digital when unrestricted digital service
   or rate adaption is used and analog if digital modems are involved.
   Calling Number, Called Number, and Subaddress may be answered.

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

   Incoming-Call-Reply

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |              11               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Message Type AVP contains a Value of 11, indicating Incoming-
   Call-Reply.  The Incoming-Call-Reply included in the
   message encodes if they are available from the telephone network.

   Once the LAC sends the Incoming-Call-Request, it waits for a response by
   from the LNS to but it does not necessarily answer the incoming call indication given by from the LAC.
   telephone network yet.  The flags
   indicate a mandatory option.

   Assigned Call ID

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              14               |            Call ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Assigned Call ID AVP encodes the ID being assigned LNS may choose not to this call
   by accept the LNS. call if:

      -  No resources are available to handle more sessions
      -  The Attribute value is 14, indicating Assigned Call ID,
   and is marked mandatory.  This AVP MUST be present. dialed, dialing, or subaddress fields do not correspond to
         an authorized user
      -  The LAC places
   this value in bearer service is not authorized or supported

   If the Call ID header field of all command and payload
   packets that LNS chooses to accept the call, it subsequently transmits over responds with an Incoming-
   Call-Reply.  When the tunnel that belong LAC receives the Incoming-Call-Reply, it
   attempts to
   this connect the call.  The Call ID value  A final call connected message from
   the LAC to the LNS indicates that the call states for both the LAC
   and the LNS should enter the established state.  If the call
   terminated before the LNS could accept it, a Call-Disconnect-Notify
   is an identifier assigned sent by the LNS LAC to indicate this session.  It condition.

   When the dialed-in client hangs up, the call is used to multiplex cleared normally and demultiplex data sent over



Valencia                   expires June 1999                    [Page 57]

INTERNET DRAFT                                              October 1998


   that tunnel between
   the LAC sends a Call-Disconnect-Notify message. If the LNS and LAC.

   Receive Window Size

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              10               |            Size               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ wishes to
   clear a call, it sends a Call-Disconnect-Notify message and cleans up
   its session.






Townsley, et al.            Standards Track                    [Page 55]


INTERNET DRAFT                    L2TP                     February 1999


7.4.1 LAC Incoming Call States

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

   idle            Receive Window Size AVP encodes the receive window size being offered
   by the LNS for this call.  The Attribute value is 10, ICCN,      Clean up          idle
                   ICRP, CDN

   wait-tunnel     Bearer line drop   Clean up          idle
                   or local close
                   request

   wait-reply      Local              Clean up         idle
                   close request or
                   Bearer line drop

   wait-tunnel     tunnel-open        Send ICRQ         wait-reply

   wait-reply      Receive Window
   Size, and is marked mandatory. ICRP,      Send ICCN         established
                   acceptable

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

   wait-reply      Receive ICRQ       Send CDN          idle
                                      Clean up

   wait-reply      Receive CDN        Clean up          idle
                   ICCN

   wait-reply      Local              Send CDN,         idle
                   close request or   Clean up
                   Bearer line drop

   established     Receive CDN        Clean up          idle

   established     Receive ICRQ,      Send CDN,         idle
                   ICRP, ICCN         Clean up

   established     Bearer line        Send CDN,         idle
                   drop or local      Clean up
                   close request


   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 states associated with the LAC should send before
   waiting for incoming calls are:



Townsley, et al.            Standards Track                    [Page 56]


INTERNET DRAFT                    L2TP                     February 1999


   idle
      The LAC detects an acknowledgment.  This AVP incoming call on one of its interfaces.
      Typically this means an analog line is present only if Sequence ringing or an ISDN TE has
      detected an incoming Q.931 SETUP message. The LAC initiates its
      tunnel establishment state machine, and Acknowledgment Numbers are moves to be used in a state waiting
      for confirmation of the existence of a tunnel.

   wait-tunnel
      In this state the payload session is waiting for
   this call.

   Packet Processing Delay

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              20               |             Delay             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Packet Processing Delay AVP encodes either the expected delay control
      connection to be opened or for verification that occurs at
   the LNS in processing a window full of packets sent by the LAC.  The
   Attribute value is 20, Packet Processing Delay AVP, and tunnel is marked
   mandatory.
      already open. Once an indication that the tunnel has/was opened,
      session control messages may be exchanged.  The presence first of this AVP these is optional.
      the Incoming-Call-Request.

   wait-reply
      The Delay value is
   specified in units of 1/10 seconds.  Refer to Appendix A to see LAC receives either a
   description of how this value CDN message indicating the LNS is determined not
      willing to accept the call (general error or don't accept) and used.

6.11 Incoming-Call-Connected (ICCN)

   The Incoming-Call-Connected
      moves back into the idle state, or an Incoming-Call-Reply message
      indicating the call is accepted, the LAC sends an L2TP control Incoming-Call-
      Connected message sent
   by and enters the LAC to the LNS in response to a received Incoming-Call-Reply.
   It provides information to the LNS about particular parameters used
   for the call.  It also provides information to allow the LNS to
   regulate the transmission of data to the LAC for this session.

   This message established state.

   established
      Data is exchanged over 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 tunnel.  The call that cannot, in
   general, may be obtained at the time the Incoming-Call-Request is issued
   by cleared
      following:
         + An event on the LAC.






Valencia                   expires June 1999                    [Page 58]

INTERNET DRAFT                                              October 1998


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          L2TP Control Message Header        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Incoming-Call-Connected         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | (Tx) Connect Speed            |
   | Framing Type                  |
   | Receive Window Size           |
   | Packet Processing Delay       |
   | Initial Received LCP CONFREQ  |
   | Last Sent LCP CONFREQ         |
   | Last Received LCP CONFREQ     |
   | Proxy authen type             |
   | Proxy authen name             |
   | Proxy authen challenge        |
   | Proxy authen ID               |
   | Proxy authen response         |
   | Private Group ID              |
   | Rx Connect Speed              |
   | Sequencing Required           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Incoming-Call-Connected

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |              12               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ connected interface:  The Message Type AVP contains LAC sends a Value of 12, indicating Incoming-
   Call-Connected.  The Incoming-Call-Connected Call-
            Disconnect-Notify message encodes
         + Receipt of a
   response by the LAC to the Incoming-Call-Reply message sent by the
   LAC.  The flags indicate a mandatory option.

   (Tx) Connect Speed

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|        10         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              24               |            BPS (H)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           BPS (L)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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




Valencia                   expires June 1999                    [Page 59]

INTERNET DRAFT                                              October 1998


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

   Framing Type

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|        10         |              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              19               |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Framing Type AVP encodes the framing type for the call.  The
   Attribute value is 19, Framing Type, and is marked mandatory.  This
   AVP MUST be present.  The value is sends 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. A particular type of framing may
   be used only if was specified in the Value field of the Framing
   Capabilities AVP received from the LNS during control session
   establishment.  The framing type MAY be used as an indication to PPP
   on the Call-Disconnect-Notify
            message.


7.4.2 LNS as to what link options to use for LCP if renegotiation is
   necessary (refer to "PPP in HDLC-like Framing" [14]). Incoming Call States

   State           Event              Action            New State
   -----           -----              ------            ---------
   idle            Receive Window Size

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              10               |             Size              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ICRQ,      Send ICRP         wait-connect
                   acceptable

   idle            Receive Window Size AVP encodes the window size being offered by the
   LAC for this call.  The Attribute value is 10, ICRQ,      Send CDN,         idle
                   not acceptable     Clean up

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








Valencia                   expires June 1999                    [Page 60]

INTERNET DRAFT                                              October 1998


   Packet Processing Delay

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              20               |             Delay             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Initial Received LCP CONFREQ

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0| 6+LCP CONFREQ len |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              26               | LCP CONFREQ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Last Sent LCP CONFREQ

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0| 6+LCP CONFREQ len |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              27               | LCP CONFREQ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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






Valencia                   expires June 1999                    [Page 61]

INTERNET DRAFT                                              October 1998


   Last Received LCP CONFREQ

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0| 6+LCP CONFREQ len |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              28               | LCP CONFREQ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Proxy Authen Type

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              29               |             Type              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Attribute value is 29, Proxy Authen Type, and is optional.  This
   AVP MUST be present if proxy authentication is to be utilized. If it
   is not present, then it is assumed that this peer cannot perform
   proxy authentication, perhaps requiring a restart of the
   authentication phase at the LNS if the client has already entered
   this phase with the LAC.  The value Type is a 16-bit word, holding a
   value:

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

   Associated AVP's for each type of authentication follow.

   Proxy Authen Name

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0|  6 + Name length  |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              30               |     Name...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Attribute value is 30, Proxy Authen Name, and is marked optional.
   This AVP MUST be present for Proxy Authen Type values 1, 2, 3 and 5.



Valencia                   expires June 1999                    [Page 62]

INTERNET DRAFT                                              October 1998


   The Name field contains the name specified in the client's
   authentication response.  Note that the AVP H bit may be desirable
   for obscuring the cleartext name.

   Proxy Authen Challenge

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0| 6 + Challenge len |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              31               | Challenge...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Proxy Authen ID

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              32               |              ID               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Proxy Authen Response

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0| 6 + Response len  |               0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              33               | Response...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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




Valencia                   expires June 1999                    [Page 63]

INTERNET DRAFT                                              October 1998


   Private Group ID

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0| 6+Private ID len  |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              37               | Private Group ID   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

   Rx Connect Speed

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|0|0|        10         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              38               |            BPS (H)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           BPS (L)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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












Valencia                   expires June 1999                    [Page 64]

INTERNET DRAFT                                              October 1998


   Sequencing Required

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|          6        |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              39               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

6.12 Call-Disconnect-Notify (CDN)

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

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

   Call-Disconnect-Notify

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |              14               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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






Valencia                   expires June 1999                    [Page 65]

INTERNET DRAFT                                              October 1998


   Result Code

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|0|0| 10 + Message len  |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               1               |          Result Code          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Error Code          |      Optional Message ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

         1 - Call disconnected due to loss of carrier
         2 - Call disconnected for the reason indicated in Error Code.
         3 - Call disconnected for administrative reasons
         4 - Call failed due to no appropriate facilities being
            available (temporary condition)
         5 - Call failed due to no appropriate facilities being
            available (permanent condition)
         6 - Invalid destination
         7 - Call failed due to no carrier detected
         8 - Call failed due to detection of a busy signal
         9 - Call failed due to lack of a dial tone
         10 - Call was not established within time allotted by LAC
         11 - Call was connected but no appropriate framing was detected

   Q.931 Cause Code

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0| 9+Advisory Msg len|              0                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              12               |          Cause Code           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Cause Msg   |Advisory Msg...|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Q.931 Cause Code AVP is used to give additional information in
   case of unsolicited call disconnection.  The Attribute value is 12,
   Cause Code, and is marked mandatory.  The presence of this AVP is
   optional.  The Cause Code AVP is used to give additional information
   about the reason for disconnecting.  It is only relevant when the LAC



Valencia                   expires June 1999                    [Page 66]

INTERNET DRAFT                                              October 1998


   is using Q.931/DSS1 for the call.  Cause Code is the returned Q.931
   Cause code and Cause Msg is the returned Q.931 message code (e.g.,
   DISCONNECT) associated with the Cause Code.  Both values are returned
   in their native ITU encodings [16].  An additional ASCII text
   Advisory Message may also be included (presence indicated by the AVP
   length) to further explain the reason for disconnecting.

   Assigned Call ID

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              14               |            Call ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

6.13 WAN-Error-Notify (WEN)

   The WAN-Error-Notify message is an L2TP control message sent by the
   LAC to the LNS to indicate WAN error conditions (conditions that
   occur on the interface supporting PPP).  The counters in this message
   are cumulative.  This message should only be sent when an error
   occurs, and not more than once every 60 seconds.  The counters are
   reset when a new call is established.

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

   WAN-Error-Notify

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |              15               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Message Type AVP contains a Value of 15, indicating WAN-Error-
   Notify.  The WAN-Error-Notify message encodes information about line
   and other errors detected on the LAC's physical interface to the



Valencia                   expires June 1999                    [Page 67]

INTERNET DRAFT                                              October 1998


   client. This message is sent by the LAC to the LNS.  The flags
   indicate a mandatory option.

   Call Errors

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|        32         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              34               |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           CRC Errors                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Framing Errors                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Hardware Overruns                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Buffer Overruns                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Time-out Errors                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Alignment Errors                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

6.14 Set-Link-Info (SLI)

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








Valencia                   expires June 1999                    [Page 68]

INTERNET DRAFT                                              October 1998


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

   Set-Link-Info

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|         8         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               0               |              16               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   ACCM

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0|0|0|0|0|        16         |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              35               |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Send ACCM                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Receive ACCM                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

7.0 Control Connection State Machines

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



Valencia                   expires June 1999                    [Page 69]

INTERNET DRAFT                                              October 1998


retransmission behavior, as this is handled in the underlying semantics
defined in 6.0.2.

7.1 Control Connection Protocol Operation

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

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

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

7.2 Control Connection States

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

7.2.1 Control Connection Establishment

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

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

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

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

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

   wait-ctl-reply  Receive SCCRQ,    Clean up,            idle



Valencia                   expires June 1999                    [Page 70]

INTERNET DRAFT                                              October 1998


                   lose tie-breaker  Re-queue SCCRQ
                                     for idle state

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

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

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

   established     Admin             Send StopCCN         idle
                   Tunnel Close      Clean up

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

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

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

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

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

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

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




Valencia                   expires June 1999                    [Page 71]

INTERNET DRAFT                                              October 1998


7.3 Timing considerations

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

7.4 Incoming calls

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

   Once the LAC sends the Incoming-Call-Request, it waits for a response
   from the LNS but it does not necessarily answer the call from the
   telephone network yet.  The LNS may choose not to accept the call if:

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

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

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

7.4.1 LAC Incoming Call States

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

   wait-tunnel     tunnel-open        Send ICRQ         wait-reply

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



Valencia                   expires June 1999                    [Page 72]

INTERNET DRAFT                                              October 1998


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

   wait-reply      Receive CDN        Clean up          idle

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

   established     Receive CDN        Hang up bearer,   idle
                                      Clean up

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

   established     Bearer             Send CDN,         idle
                   Line drop          Clean up

   The states associated with the LAC for incoming calls are:

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

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

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

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






Valencia                   expires June 1999                    [Page 73]

INTERNET DRAFT                                              October 1998


7.4.2 LNS Incoming Call States

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

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

   wait-connect    Receive ICCN       Prepare for       established
                   acceptable         data

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

   wait-connect,
   established     Receive CDN        Clean up          idle

   established     Local              Send CDN,         idle
                   Close request      Clean up

   The states associated with the LNS for incoming calls are:

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

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

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

7.5 Outgoing calls

   Outgoing calls are initiated by an LNS and instruct an LAC to place a
   call.  There are three messages for outgoing calls:  Outgoing-Call-
   Request, Outgoing-Call-Reply, and Outgoing-Call-Connected.  The LNS
   sends an Outgoing-Call-Request specifying the dialed party phone
   number and subaddress as well as speed and window parameters.  The
   LAC MUST respond to the Outgoing-Call-Request message with an



Valencia                   expires June 1999                    [Page 74]

INTERNET DRAFT                                              October 1998


   Outgoing-Call-Reply message once the LAC determines that the proper
   facilities exist to place the call and the call is administratively
   authorized.  For example, is this LNS allowed to dial an
   international call?  Once the outbound call is connected, the LAC
   sends an Outgoing-Call-Connected message to the LNS indicating the
   final result of the call attempt:

7.5.1 LAC Outgoing Call States

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

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

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

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

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

   The states associated with the LAC for outgoing calls are:

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

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

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







Valencia                   expires June 1999                    [Page 75]

INTERNET DRAFT                                              October 1998


7.5.2 LNS Outgoing Call States

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

   wait-tunnel     tunnel-open        Send OCRQ         wait-reply

   wait-reply      Receive OCRP,      none              wait-connect
                   acceptable

   wait-reply      Receive OCRP,      Send CDN          idle
                   not acceptable

   wait-connect    Receive OCCN       none              established

   established,
   wait-connect    Receive CDN        Clean up          idle

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

   The states associated with the LNS for outgoing calls are:

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

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

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

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






Valencia                   expires June 1999                    [Page 76]

INTERNET DRAFT                                              October 1998


7.6 Tunnel Disconnection

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

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

8.0 L2TP Over Specific Media

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

8.1 IP/UDP

   L2TP uses the registered UDP port 1701 [12].  The entire L2TP packet,
   including payload and L2TP header, is sent within a UDP datagram.
   The initiator of an L2TP tunnel picks an available source UDP port
   (which may or may not be 1701), and sends to the desired destination
   at port 1701.  The recipient picks a free port on its own system
   (which may or may not be 1701), and sends its reply to the
   initiator's UDP port, setting its own UDP source port set to the free
   port it found. Once the source and destination ports are established,
   they MUST remain static for the life of the tunnel.

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

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

   Port 1701 is used for both L2F [2] and L2TP packets.  The two types
   of packets may be detected by their headers; L2TP has a Vers field of



Valencia                   expires June 1999                    [Page 77]

INTERNET DRAFT                                              October 1998


   2, L2F has a Vers field of 1.  An L2TP implementation running on a
   system which does not support L2F MUST silently discard all packets
   whose Vers field is set to 1.

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

   The latter characteristic of silently dropping packets is perhaps
   more problematic.  If RFC 1663 reliable delivery [10] is enabled, no
   upper PPP protocol will encounter lost packets.  If L2TP sequence
   numbers are enabled, L2TP can detect the packet loss.  In the case of
   an LNS, the PPP and L2TP stacks are both present within the LNS, and
   packet loss signaling may occur precisely as if a packet was received
   with a CRC error.  Where the LAC and PPP stack are co-resident, this
   technique also applies.  Where the LAC and PPP client are physically
   distinct, the analogous signaling MAY be accomplished by sending a
   packet with a CRC error to the PPP client.  Note that this would
   greatly increase the complexity of debugging client line problems,
   since the client statistics can not distinguish between true media
   errors and LAC-initiated ones.  This technique is also not possible
   on all hardware.

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

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

8.2 IP

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

9.0 Security Considerations

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





Valencia                   expires June 1999                    [Page 78]

INTERNET DRAFT                                              October 1998


   9.1 Tunnel Endpoint Security

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

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

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

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

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

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

   9.2 Client Security

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



Valencia                   expires June 1999                    [Page 79]

INTERNET DRAFT                                              October 1998


      precede encryption.

   9.3 Proxy Authentication

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

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

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

10.0 IANA Considerations

   This document contains many "magic" numbers to be maintained by the
   IANA.  This section explains the criteria to be used by the IANA to
   assign additional numbers in each of these lists.  Numbers may only
   be assigned if an appropriate IETF approved document exists that
   describes how the number is to be used in an interoperable fashion.
   All values not explicitly defined in previous sections are reserved
   to IANA.

   10.1 AVP Attribute Type Values

      The Attribute type values are 16 bit values. These values define
      the type and the usage of the data in the AVP.

   10.2 Message type values

      The Message type values are 16 bit values, used in the Message
      Type AVP to define the function of the control message.

   10.3 Result code values

      The Result code values are 16 bit values that define possible
      error conditions.

   10.4 Framing Capabilities & Bearer Capabilitities

      Framing Capabilities and Bearer Capabilitities are both 32 bit
      bitmasks. These bits should only be assigned to IETF Standards



Valencia                   expires June 1999                    [Page 80]

INTERNET DRAFT                                              October 1998


      Track documents.

   10.5 Proxy Authen Type values

      The Proxy Authen Type values are 16 bit values that define the
      type of PPP authentication that is being sent as a proxy in the
      session.

   10.6 AVP Header bits

      There are four remaining reserved bits in the AVP header. These
      should only be assigned if absolutely necessary, and only to IETF
      Standards Track documents.


   10.7 Message (Payload and Control) Header bits

      The are seven remaining reserved bits in the message header. While
      the message and payload headers are distinguishable via the T-bit,
      they share the same bit field space. Thus, assigning a bit for the
      control or payload header reserves the same bit position in both
      headers.

11.0 Acknowledgments

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

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

   Steve Cobb and Evan Caves redesigned the state machine tables.

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

12.0 Contacts

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

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



Valencia                   expires June 1999                    [Page 81]

INTERNET DRAFT                                              October 1998


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

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

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

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

   William Verthein
   3COM Corporation
   william_verthein@3com.com

13.0 References


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

    [2] A. Valencia, M. Littlewood, T. Kolar, "Cisco Layer Two Forwarding
        (Protocol) L2F", RFC 2341, May 1998

    [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn,
        "Point-to-Point Tunneling Protocol (PPTP)",``work in progress'',
        October 1998

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

    [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        USC/Information Sciences Institute, October 1994.

    [6] B. Braden, D. Clark, J. Crowcroft, B. Davie, S.
        Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge,
        L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang.
        Recommendations on Queue Management and Congestion Avoidance in
        the Internet. RFC 2309 April 1998.

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



Valencia                   expires June 1999 ICRP       Send CDN          idle
                                      Clean up

   idle            Receive ICCN       Clean up          idle

   wait-connect    Receive ICCN       Prepare for       established



Townsley, et al.            Standards Track                    [Page 82] 57]


INTERNET DRAFT                                              October 1998


        October 1996

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

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

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

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

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

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

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

   [15] Bradner, S, "Key words                    L2TP                     February 1999


                   acceptable         data

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

   wait-connect    Receive ICRQ,      Send CDN          idle
                   ICRP               Clean up

   idle,           Receive CDN        Clean up          idle
   wait-connect,
   established

   wait-connect    Local              Send CDN,         idle
   established     Close request      Clean up

   established     Receive ICRQ,      Send CDN          idle
                   ICRP, ICCN         Clean up



   The states associated with the LNS for use in RFCs incoming calls are:

   idle
      An Incoming-Call-Request message is received. If the request is
      not acceptable, a Call-Disconnect-Notify is sent back to Indicate Requirement
        Levels", RFC 2119, March 1997.

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

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

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

Appendix A: Acknowledgment Timeouts

   L2TP uses sliding windows LAC
      and timeouts the LNS remains in the idle state. If the Incoming-Call-
      Request message is acceptable, an Incoming-Call-Reply is sent. The
      session moves to provide the wait-connect state.

   wait-connect
      If the session and control
   flow-control across is still connected on the underlying medium (which may be LAC, the LAC sends an
   internetwork) and to perform efficient data buffering
      Incoming-Call-Connected message to keep the
   LAC-LNS data channels full without causing receive buffer overflow.
   L2TP requires that LNS which then moves into
      established state.  The LAC may send a timeout Call-Disconnect-Notify to
      indicate that the incoming caller could not be used connected. This
      could happen, for example, if a telephone user accidentally places
      a standard voice call to recover 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 dropped data the LAC or
   acknowledgment packets for by sending a Call-Disconnect-
      Notify. Clean up follows on both control sides regardless of the
      initiator.

7.5 Outgoing calls

   Outgoing calls are initiated by an LNS and data messages. instruct an LAC to place a
   call.  There are three messages for outgoing calls:  Outgoing-Call-



Townsley, et al.            Standards Track                    [Page 58]


INTERNET DRAFT                    L2TP                     February 1999


   Request, Outgoing-Call-Reply, and Outgoing-Call-Connected.  The only
   real difference between LNS
   sends an Outgoing-Call-Request specifying the flow-control mechanism used for dialed party phone
   number, subaddress and other parameters. The LAC MUST respond to the two
   Outgoing-Call-Request message types is with an Outgoing-Call-Reply message
   once the LAC determines that control messages are retransmitted upon
   expiration of the acknowledgment timeout in order proper facilities exist to assure reliable
   transport while payload messages are never retransmitted.  Because
   payload messages are not retransmitted, place the
   call and the call is administratively authorized.  For example, is
   this LNS allowed to dial an international call?  Once the outbound
   call is connected, the LAC sends an Outgoing-Call-Connected message
   to the LNS indicating the action taken upon
   expiration final result of the acknowledgment timeout for each message type also
   differs.

   When call attempt:

7.5.1 LAC Outgoing Call States

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

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

   idle            Receive OCRP       Send CDN          idle
                                      Clean up

   idle            Receive OCCN,      Clean up          idle
                   CDN

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

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

   wait-cs-answer  Receive OCRQ,      Send CDN          idle
                   OCRP, OCCN         Clean up

   established     Receive OCRQ,      Send CDN          idle
                   OCRP, OCCN         Clean up

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

   established     Bearer line drop,  Send CDN,         idle
                   Local close        Clean up
                   request


   The states associated with the timeout LAC for a control session expires the previously



Valencia                   expires June 1999 outgoing calls are:




Townsley, et al.            Standards Track                    [Page 83] 59]


INTERNET DRAFT                                              October 1998


   transmitted control message                    L2TP                     February 1999


   idle
      If Outgoing-Call-Request is received in error, respond with Ns value equal a
      Call-Disconnect-Notify. Otherwise, allocate a physical channel and
      send an Outgoing-Call-Reply. Place the outbound call and move to
      the highest in-
   sequence value of Nr received from wait-cs-answer state.

   wait-cs-answer
      If the peer call is retransmitted.  The
   receiving peer does not advance its value for the receive sequence
   number state, Sr, for either a control session completed or payload session
   until it receives a message with Ns equal to its current value of Sr
   (except timer expires waiting for the simple receiver described in Appendix C and payload
   packets with the R bit set).  This rule assures that all subsequent
   acknowledgments for this session will contain an Nr value equal
      call to
   the Ns value of the first missing message until complete, send a message Call-Disconnect-Notify with the
   missing Ns value
      appropriate error condition set and go to idle state. If a circuit
      switched connection is received.  This rule also assures that when established and framing is detected, send
      an Outgoing-Call-Connected indicating success and go to
      established state.

   established
      If a
   payload message Call-Disconnect-Notify is lost anywhere within received by the current transmit window, LAC, the payload session acknowledgment timeout will expire, allowing telco call
      MUST be released via appropriate mechanisms and the
   transmitter to adjust transmission parameters such as those suggested
   in this appendix.

   According to session
      cleaned up. If the above rule for updating of call is disconnected by the receiving peer's Sr
   value, client or the loss of
      called interface, a transmitted payload Call-Disconnect-Notify message (due to non-
   retransmission of payload messages) will cause Sr MUST be sent to remain at
      the
   value LNS. The sender of the first lost payload message.  In order Call-Disconnect-Notify message returns
      to cause the
   receiving peer to advance its value of Sr beyond that of a lost
   message's Ns value, upon expiration idle state after sending of a payload session
   acknowledgment timeout, the sending peer MUST transmit a payload message is complete.

7.5.2 LNS Outgoing Call States

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

   idle            Receive OCCN,      Clean up          idle
                   OCRP, CDN

   wait-tunnel     tunnel-open        Send OCRQ         wait-reply

   wait-reply      Receive OCRP,      none              wait-connect
                   acceptable

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

   wait-reply      Receive OCCN,      Send CDN          idle
                   OCRQ               Clean up

   wait-connect    Receive OCCN       none              established

   wait-connect    Receive OCRQ,      Send CDN          idle
                   OCRP               Clean up




Townsley, et al.            Standards Track                    [Page 60]


INTERNET DRAFT                    L2TP                     February 1999


   idle,           Receive CDN,       Clean up          idle
   wait-reply,
   wait-connect,
   established

   established     Receive OCRQ,      Send CDN          idle
                   OCRP, OCCN         Clean up

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

   wait-tunnel     Local              Clean up          idle
                   Close request

   The states associated with R bit set and Ns value greater than or equal to Ns of the lost message.  Refer to Section 4 LNS for more details on the use of
   the R bit.

   The exact implementation of the acknowledgment timeout outgoing calls are:

   idle, wait-tunnel
      When an outgoing call is vendor-
   specific.  It initiated, a tunnel is suggested that an adaptive timeout be implemented
   with backoff for flow control.  The timeout mechanism proposed here
   has first created,
      much as the following properties:

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

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

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

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

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







Valencia                   expires June 1999                    [Page 84]

INTERNET DRAFT                                              October 1998


   Some definitions:

      Packet Processing Delay, "PPD", tunnel is the amount of time required for
      each peer to process the maximum amount of data buffered in its
      offered receive packet window.  The PPD established, an Outgoing-Call-Request message is the value exchanged
      between
      sent to the LAC and LNS when the session moves into the wait-reply state.

   wait-reply
      If a call Call-Disconnect-Notify is established.  For the LNS,
      this number should be small.  For received, an LAC supporting modem
      connections, this number could be significant.

      "Sample" is error occurred, and
      the actual amount of time incurred receiving session is cleaned up and returns to idle.  If an
      acknowledgment for a packet.  The Sample Outgoing-
      Call-Reply is measured, not
      calculated.

      Round-Trip Time, "RTT", received, the call is in progress and the estimated round-trip time for an
      Acknowledgment session
      moves to be received for a given transmitted packet.
      When the network link is wait-connect state.

   wait-connect
      If a local network, this delay will be
      minimal (if not zero).  When the network link Call-Disconnect-Notify is received, the Internet,
      this delay could be substantial and vary widely.  RTT call failed; the
      session is adaptive:
      it will adjust cleaned up and returns to include idle.  If an Outgoing-Call-
      Connected is received, the PPD call has succeeded and whatever shifting network
      delays contribute to the time between session may
      now exchange data.

   established
      If a packet being transmitted
      and receiving its acknowledgment.

      Adaptive Timeout, "ATO", Call-Disconnect-Notify is received, the time that must elapse before an
      acknowledgment is considered lost.  After a timeout, call has been
      terminated for the sliding
      window is partially closed reason indicated in the Result and Cause Codes;
      the ATO is backed off.

Packet Processing Delay (PPD)

   The PPD parameter is session moves back to the idle state.  If the LNS chooses to
      terminate the session, it sends a 16-bit time value exchanged during Call-Disconnect-Notify to the Call
   Control phase expressed in units
      LAC and then cleans up and idles its session.

7.6 Tunnel Disconnection

   The disconnection of tenths a tunnel consists of either peer issuing a second (64 means 6.4
   seconds).
   Stop-Control-Connection-Notification. The protocol only specifies that sender of this Notification
   should wait a finite period of time for the parameter is
   exchanged, it does not specify how it is calculated. acknowledgment of this
   message before releasing the control information associated with the



Townsley, et al.            Standards Track                    [Page 61]


INTERNET DRAFT                    L2TP                     February 1999


   tunnel. The way values
   for ATO are calculated recipient of this Notification should send an
   acknowledgment of the Notification and then release the associated
   control information.

   When to release a tunnel is implementation-dependent an implementation issue and need is not be
   variable (static timeouts are allowed).  If adaptive timeouts are to
   be used then the PPD should be exchanged
   specified in the call connect
   sequences. this document. 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 particular implementation may use
   whatever policy is the total size appropriate for determining when to release a
   control connection. Some implementations may leave a tunnel open for
   a period of time or perhaps indefinitely after the L2TP and media dependent headers.
   MTU last session for
   that tunnel is cleared. Others may choose to disconnect the overall MTU for tunnel
   immediately after the link between last user connection on the LAC and LNS.
   WindowSize represents tunnel disconnects.

8.0 L2TP Over Specific Media

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

8.1 L2TP over UDP/IP

   L2TP uses the sliding window, registered UDP port 1701 [RFC1700]. The entire L2TP
   packet, including payload and L2TP header, is implementation-dependent. sent within a UDP
   datagram. The latency initiator of the underlying
   connection path between the LAC and LNS could an L2TP tunnel picks an available source
   UDP port (which may or may not be used to pick a
   window size sufficient 1701), and sends to keep the current session's pipe full. desired
   destination at port 1701.  The
   constant 8 converts octets to bits (assuming ConnectRate is in bits
   per second).  LACFudge and LNSFudge are recipient picks a free port on its own
   system (which may or may not required but can be used 1701), and sends its reply to take overall processing overhead of the LAC or LNS into account.

   In
   initiator's UDP port, setting its own UDP source port to the case of free
   port it found. Once the computed PPD source and destination ports are established,
   they MUST remain static for an LNS, AvePathRate is the



Valencia                   expires June 1999                    [Page 85]

INTERNET DRAFT                                              October 1998


   average bit rate life of the path between tunnel.

   IP fragmentation may occur as the LNS and LAC.  Given that
   this number is probably very large and WindowSize is relatively
   small, LNSFudge will be L2TP packet travels over the dominant factor 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 computation MTU's of
   PPD.  It is recommended that the minimum value of PPD be on
   path over which the order
   of 0.5 second.

   The value of PPD is used L2TP packets are likely to seed the adaptive algorithm with the
   initial RTT[n-1] travel have a
   consistent value.

A.1 Calculating Adaptive Acknowledgment Timeout

   We still must decide how much time to allow for acknowledgments to
   return.  If the timeout is set too high, we may wait an unnecessarily
   long time

   The default for dropped packets.  If the timeout any L2TP implementation is too short, we may
   time out just before the acknowledgment arrives.  The acknowledgment
   timeout should also that UDP checksums MUST be reasonable
   enabled for both control and responsive to changing network
   conditions.

   The suggested adaptive algorithm detailed below is based on the TCP
   1989 data messages. An L2TP 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
   MAY provide an option 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-