home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-pppext-l2tp-04.txt < prev    next >
Text File  |  1997-06-26  |  223KB  |  5,344 lines
  1.  
  2.  
  3.  
  4. PPP Working Group                                             Kory Hamzeh
  5. INTERNET DRAFT                                      Ascend Communications
  6. Category: Internet Draft                                        Tim Kolar
  7. Title: draft-ietf-pppext-l2tp-04.txt                        Cisco Systems
  8. Date: June 1997                                         Morgan Littlewood
  9.                                                             Cisco Systems
  10.                                                        Gurdeep Singh Pall
  11.                                                     Microsoft Corporation
  12.                                                               Jeff Taarud
  13.                                                  Copper Mountain Networks
  14.                                                        Andrew J. Valencia
  15.                                                             Cisco Systems
  16.                                                          William Verthein
  17.                                                             U.S. Robotics
  18.  
  19.  
  20.                   Layer Two Tunneling Protocol "L2TP"
  21.  
  22.  
  23. Status of this Memo
  24.  
  25.    This document is an Internet-Draft.  Internet-Drafts are working
  26.    documents of the Internet Engineering Task Force (IETF), its areas,
  27.    and its working groups.  Note that other groups may also distribute
  28.    working documents as Internet-Drafts.
  29.  
  30.    Internet-Drafts are draft documents valid for a maximum of six
  31.    months.  Internet-Drafts may be updated, replaced, or obsoleted by
  32.    other documents at any time.  It is not appropriate to use Internet-
  33.    Drafts as reference material or to cite them other than as a
  34.    ``working draft'' or ``work in progress.''
  35.  
  36.    To learn the current status of any Internet-Draft, please check the
  37.    1id-abstracts.txt listing contained in the Internet-Drafts Shadow
  38.    Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
  39.    munnari.oz.au.
  40.  
  41. Abstract
  42.  
  43.    Virtual dial-up allows many separate and autonomous protocol domains
  44.    to share common access infrastructure including modems, Access
  45.    Servers, and ISDN routers.  RFC1661 specifies multiprotocol dial-up
  46.    via PPP [1].  This document describes the Layer Two Tunneling
  47.    Protocol (L2TP) which permits the tunneling of the link layer (i.e.,
  48.    HDLC, async HDLC) of PPP.  Using such tunnels, it is possible to
  49.    divorce the location of the initial dial-up server from the location
  50.    at which the dial-up protocol connection is terminated and access to
  51.    the network provided.
  52.  
  53. Table of Contents
  54.  
  55.    1.0 Introduction
  56.    1.1 Conventions
  57.    1.2 Terminology
  58.  
  59.  
  60.  
  61. Valencia                 expires December 1997                   [Page 1]
  62.  
  63.  
  64.  
  65.  
  66.  
  67. INTERNET DRAFT                                                 June 1997
  68.  
  69.  
  70.    2.0 Problem Space Overview
  71.    2.1 Initial Assumptions
  72.    2.2 Topology
  73.    2.3 Providing Virtual Dial-up Services--a walk-through
  74.    3.0 Service Model Issues
  75.    3.1 Security
  76.    3.2 Address Allocation
  77.    3.3 Authentication
  78.    3.4 Accounting
  79.    4.0 Protocol Overview
  80.    4.1 Control Message Overview
  81.    4.2 Payload Packet Overview
  82.    5.0 Message Format and Protocol Extensibility
  83.    5.1 AVP
  84.    5.2 Control Message Format
  85.    5.3 Payload Message Format
  86.    5.4 Control Message Types
  87.    5.5 AVP Summary
  88.    5.6 Result and Error Code Summary
  89.    5.7 Hiding of AVP values
  90.    6.0 Control Connection Protocol Specification
  91.    6.1 Start-Control-Connection-Request
  92.    6.2 Start-Control-Connection-Reply
  93.    6.3 Start-Control-Connection-Connected
  94.    6.4 Stop-Control-Connection-Request
  95.    6.5 Stop-Control-Connection-Reply
  96.    6.6 Hello
  97.    6.7 Outgoing-Call-Request
  98.    6.8 Outgoing-Call-Reply
  99.    6.9 Outgoing-Call-Connected
  100.    6.10 Incoming-Call-Request
  101.    6.11 Incoming-Call-Reply
  102.    6.12 Incoming-Call-Connected
  103.    6.13 Call-Clear-Request
  104.    6.14 Call-Disconnect-Notify
  105.    6.15 WAN-Error-Notify
  106.    6.16 Set-Link-Info
  107.    7.0 Control Connection State Machines
  108.    7.1 Control Connection Protocol Operation
  109.    7.2 Control Connection States
  110.    7.2.1 Control Connection Originator
  111.    7.2.2 Control connection Receiver
  112.    7.3 Timing considerations
  113.    7.4 Incoming Calls
  114.    7.4.1 LAC Incoming Call States
  115.    7.4.2 LNS Incoming Call States
  116.    7.5 Outgoing calls
  117.    7.5.1 LAC Outgoing Call States
  118.    7.5.2 LNS Outgoing Call States
  119.    8.0 L2TP Over Specific Media
  120.    8.1 IP/UDP
  121.    8.2 IP
  122.    9.0 Security Considerations
  123.    9.1 Tunnel Endpoint Security
  124.  
  125.  
  126.  
  127. Valencia                 expires December 1997                   [Page 2]
  128.  
  129.  
  130.  
  131.  
  132.  
  133. INTERNET DRAFT                                                 June 1997
  134.  
  135.  
  136.    9.2 Client Security
  137.    10.0 Acknowledgments
  138.    11.0 Contacts
  139.    12.0 References
  140.    Appendix A: Acknowledgment Time-Outs
  141.    Appendix B: Acknowledgment Time-Out and Window Adjustment
  142.    Appendix C: Handling of out-of-order packets
  143.    Appendix D: Transport Layer Adaptive Time-Outs and Window Adjustment
  144.    Appendix E: Examples of L2TP sequence numbering
  145.    E.1 Lock-step tunnel establishment
  146.    E.2 Multiple packets acknowledged
  147.    E.3 Lost packet with retransmission
  148.  
  149. 1.0 Introduction
  150.  
  151.    The traditional dial-up network service on the Internet is for
  152.    registered IP addresses only.  A new class of virtual dial-up
  153.    application which allows multiple protocols and unregistered IP
  154.    addresses is also desired on the Internet.  Examples of this class of
  155.    network application are support for privately addressed IP, IPX, and
  156.    AppleTalk dial-up via PPP across existing Internet infrastructure.
  157.  
  158.    The support of these multiprotocol virtual dial-up applications is of
  159.    significant benefit to end users, enterprises, and Internet Service
  160.    providers as it allows the sharing of very large investments in
  161.    access and core infrastructure and allows local calls to be used.  It
  162.    also allows existing investments in non-IP protocol applications to
  163.    be supported in a secure manner while still leveraging the access
  164.    infrastructure of the Internet.
  165.  
  166.    It is the purpose of this draft to identify the issues encountered in
  167.    integrating multiprotocol dial-up services into an existing Internet
  168.    Service Provider's Point of Presence (hereafter referred to as ISP
  169.    and POP, respectively), and to describe the L2TP protocol which
  170.    permits the leveraging of existing access protocols.
  171.  
  172.    This protocol may also be used to solve the "multilink hunt-group
  173.    splitting" problem. Multilink PPP, often used to aggregate ISDN B
  174.    channels, requires that all channels composing a multilink bundle be
  175.    grouped at a single NAS.  Because L2TP makes a PPP session appear at
  176.    a location other than the physical point at which the session was
  177.    physically received, it can be used to make all channels appear at a
  178.    single NAS, allowing multilink operation even when the physical calls
  179.    are spread across distinct physical NAS's.
  180.  
  181. 1.1 Conventions
  182.  
  183.    The following language conventions are used in the items of
  184.    specification in this document:
  185.  
  186.       o   MUST, SHALL, or MANDATORY -- This item is an absolute
  187.          requirement of the specification.
  188.  
  189.       o   SHOULD or RECOMMEND -- This item should generally be followed
  190.  
  191.  
  192.  
  193. Valencia                 expires December 1997                   [Page 3]
  194.  
  195.  
  196.  
  197.  
  198.  
  199. INTERNET DRAFT                                                 June 1997
  200.  
  201.  
  202.          for all but exceptional circumstances.
  203.  
  204.       o   MAY or OPTIONAL -- This item is truly optional and may be
  205.          followed or ignored according to the needs of the implementor.
  206.  
  207. 1.2 Terminology
  208.  
  209.    Analog Channel
  210.  
  211.       A circuit-switched communication path which is intended to carry
  212.       3.1 Khz audio in each direction.
  213.  
  214.    Digital Channel
  215.  
  216.       A circuit-switched communication path which is intended to carry
  217.       digital information in each direction.
  218.  
  219.    Call
  220.  
  221.       A connection or attempted connection between two terminal
  222.       endpoints on a PSTN or ISDN--for example, a telephone call between
  223.       two modems.
  224.  
  225.    CHAP
  226.  
  227.       Challenge Authentication Protocol, a PPP cryptographic
  228.       challenge/response authentication protocol in which the cleartext
  229.       password is not passed in the clear over the line.
  230.  
  231.    CLID
  232.  
  233.       Calling Line ID, an indication to the receiver of a call as to the
  234.       phone number of the caller.
  235.  
  236.    Control Messages
  237.       Control messages are exchanged between LAC, LNS pairs, and operate
  238.       in-band within the tunnel protocol.  Control messages govern
  239.       aspects of the tunnel and sessions within the tunnel.
  240.  
  241.    Dial User
  242.  
  243.       An end-system or router attached to an on-demand PSTN or ISDN
  244.       which is either the initiator or recipient of a call.
  245.  
  246.    DNIS
  247.  
  248.       Dialed Number Information String, an indication to the receiver of
  249.       a call as to what phone number the caller used to reach it.
  250.  
  251.    EAP
  252.  
  253.       Extensible Authentication Protocol, a framework for a family of
  254.       PPP authentication protocols, including cleartext,
  255.       challenge/response, and arbitrary dialog sequences.
  256.  
  257.  
  258.  
  259. Valencia                 expires December 1997                   [Page 4]
  260.  
  261.  
  262.  
  263.  
  264.  
  265. INTERNET DRAFT                                                 June 1997
  266.  
  267.  
  268.    L2TP Access Concentrator (LAC)
  269.  
  270.       A device attached to one or more PSTN or ISDN lines capable of PPP
  271.       operation and of handling the L2TP protocol.  The LAC needs only
  272.       implement the media over which L2TP is to operate to pass traffic
  273.       to one or more LNS's.  It may tunnel any protocol carried within
  274.       PPP.
  275.  
  276.    L2TP Network Server (LNS)
  277.  
  278.       An LNS operates on any platform capable of PPP termination.  The
  279.       LNS handles the server side of the L2TP protocol.  Since L2TP
  280.       relies only on the single media over which L2TP tunnels arrive,
  281.       the LNS may have only a single LAN or WAN interface, yet still be
  282.       able to terminate calls arriving at any LAC's full range of PPP
  283.       interfaces (async, synchronous ISDN, V.120, etc.).
  284.  
  285.    Network Access Server (NAS)
  286.  
  287.       A device providing temporary, on-demand network access to users.
  288.       This access is point-to-point using PSTN or ISDN lines.
  289.  
  290.    PAP
  291.  
  292.       Password Authentication Protocol, a simple PPP authentication
  293.       mechanism in which a cleartext username and password are
  294.       transmitted to prove identity.
  295.  
  296.    Session
  297.  
  298.       L2TP is connection-oriented.  The LNS and LAC maintain state for
  299.       each user that is attached to an LAC.  A session is created when
  300.       an end-to-end PPP connection is attempted between a dial user and
  301.       the LNS, or when a outbound call is initiated.  The datagrams
  302.       related to a session are sent over the tunnel between the LAC and
  303.       LNS.
  304.  
  305.    Quality of Service (QOS)
  306.  
  307.       A given Quality of Service level is sometimes required for a given
  308.       user being tunneled between an LNS-LAC pair.  For this scenario, a
  309.       unique L2TP tunnel is created (generally on top of a new SVC) and
  310.       encapsulated directly on top of the media providing the indicated
  311.       QOS.
  312.  
  313.    Switched Virtual Circuit (SVC)
  314.  
  315.       An L2TP-compatible media on top of which L2TP is directly
  316.       encapsulated.  SVC's are dynamically created, permitting tunnel
  317.       media to be created dynamically in response to desired LNS-LAC
  318.       connectivity requirements.
  319.  
  320.    Tunnel
  321.  
  322.  
  323.  
  324.  
  325. Valencia                 expires December 1997                   [Page 5]
  326.  
  327.  
  328.  
  329.  
  330.  
  331. INTERNET DRAFT                                                 June 1997
  332.  
  333.  
  334.       A tunnel is defined by an LNS-LAC pair.  The tunnel carries PPP
  335.       datagrams between the LAC and the LNS; many sessions can be
  336.       multiplexed over a single tunnel.  A control connection operating
  337.       in-band over the same tunnel controls the establishment, release,
  338.       and maintenance of sessions and of the tunnel itself.
  339.  
  340. 2.0 Problem Space Overview
  341.  
  342.    In this section we describe in high level terms the scope of the
  343.    problem that will be explored in more detail in later sections.
  344.  
  345. 2.1 Initial Assumptions
  346.  
  347.    We begin by assuming that Internet access is provided by an ISP and
  348.    that the ISP wishes to offer services other than traditional
  349.    registered IP address based services to dial-up users of the network.
  350.  
  351.    We also assume that the user of such a service wants all of the
  352.    security facilities that are available to him in a dedicated dial-up
  353.    configuration.  In particular, the end user requires:
  354.  
  355.    +  End System transparency: Neither the remote end system nor his
  356.    home site hosts should require any special software to use this
  357.    service in a secure manner.
  358.  
  359.    +  Authentication as provided via dial-up PPP CHAP, PAP, EAP, or
  360.    through other dialogs, for instance, a textual exchange on V.120
  361.    before starting PPP.  This will include TACACS+ [7] and RADIUS [8]
  362.    solutions as well as support for smart cards and one-time passwords.
  363.    The authentication should be manageable by the user independently of
  364.    the ISP.
  365.  
  366.    +  Addressing should be as manageable as dedicated dial-up solutions.
  367.    The address should be assigned by the home site and not the ISP.
  368.  
  369.    +  Authorization should be managed by the home site as it would in a
  370.    direct dial-up solution.
  371.  
  372.    +  Accounting should be performed both by the ISP (for billing
  373.    purposes) and by the user (for charge-back and auditing).
  374.  
  375. 2.2 Topology
  376.  
  377.    Shown below is a generic Internet with Public switched Telephone
  378.    Network (PSTN) access (i.e., async PPP via modems) and Integrated
  379.    Services Digital Network (ISDN) access (i.e., synchronous PPP
  380.    access).  Remote users (either async or ISDN PPP) will access the
  381.    Home LAN as if they were dialed into the L2TP Network Server (LNS),
  382.    although their physical dial-up is via the ISP Network Access Server.
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391. Valencia                 expires December 1997                   [Page 6]
  392.  
  393.  
  394.  
  395.  
  396.  
  397. INTERNET DRAFT                                                 June 1997
  398.  
  399.  
  400.            ...----[L]----+---[L]-----...
  401.                          |
  402.                          |
  403.                         [H]
  404.                          |
  405.                  ________|________________________
  406.                  |                                |
  407.          ________|__                        ______|________
  408.          |         |                        |             |
  409.          |  PSTN  [R]                      [R]  ISDN      |
  410.          |  Cloud  |                        |   Cloud    [N]__[U]
  411.          |         |             Internet   |             |
  412.          |         |                       [R]            |
  413.          [N]______[R]                       |_____________|
  414.           |      |                                |
  415.           |      |                                |
  416.          [U]     |________________________________|
  417.  
  418.  
  419.       [H] = LNS
  420.       [L] = Home LAN(s)
  421.       [R] = Router
  422.       [U] = Remote User
  423.       [N] = ISP Network Access Server
  424.  
  425.  
  426. 2.3 Providing Virtual dial-up Services--a walk-through
  427.  
  428.    To motivate the following discussion, this section walks through an
  429.    example of what might happen when a Virtual dial-up client initiates
  430.    access.
  431.  
  432.    The remote user initiates a PPP connection to an ISP via either the
  433.    PSTN or ISDN.  The Network Access Server (NAS) accepts the connection
  434.    and the PPP link is established (L2TP also permits the NAS to check
  435.    with an LNS after call indication prior to accepting the call--this
  436.    is useful where DNIS or CLID information is available in the incoming
  437.    call notification).
  438.  
  439.    The ISP may now undertake a partial authentication of the end
  440.    system/user.  Only the username field would be interpreted to
  441.    determine whether the user requires a Virtual dial-up service.  It is
  442.    expected--but not required--that usernames will be structured (e.g.
  443.    username@company.com).  Alternatively, the ISP may maintain a
  444.    database mapping users to services.  In the case of Virtual dial-up,
  445.    the mapping will name a specific endpoint, the LNS.
  446.  
  447.    Alternatively, the ISP may have already determined the target LNS
  448.    from DNIS.  If the LNS is willing to accept tunnel creation without
  449.    any authentication of the caller, the NAS may tunnel the PPP
  450.    connection without ever having communicated with the remote user.
  451.  
  452.    If a virtual dial-up service is not required, standard access to the
  453.    Internet may be provided.
  454.  
  455.  
  456.  
  457. Valencia                 expires December 1997                   [Page 7]
  458.  
  459.  
  460.  
  461.  
  462.  
  463. INTERNET DRAFT                                                 June 1997
  464.  
  465.  
  466.    If no tunnel connection currently exists to the desired LNS, one is
  467.    initiated.  L2TP is designed to be largely insulated from the details
  468.    of the media over which the tunnel is established; L2TP requires only
  469.    that the tunnel media provide packet oriented point-to-point
  470.    connectivity.  Obvious examples of such media are UDP, Frame Relay
  471.    PVC's, or X.25 VC's.
  472.  
  473.    Once the tunnel exists, an unused slot within the tunnel, a "Call
  474.    ID", is allocated, and a connect indication is sent to notify the LNS
  475.    of this new dial-up session.  The LNS either accepts the connection,
  476.    or rejects it.  Rejection may include a reason indication, which may
  477.    be displayed to the dial-up user, after which the call should be
  478.    disconnected.
  479.  
  480.    The initial setup notification may include the authentication
  481.    information required to allow the LNS to authenticate the user and
  482.    decide to accept or decline the connection.  In the case of CHAP, the
  483.    set-up packet includes the challenge, username and raw response.  For
  484.    PAP or text dialog, it includes username and clear text password.
  485.    The LNS may choose to use this information to complete its
  486.    authentication, avoiding an additional cycle of authentication.
  487.  
  488.    If the LAC negotiated PPP LCP before initiating the tunnel, the
  489.    initial setup notification may also include a copy of the LCP
  490.    CONFREQ's sent in each direction which completed LCP negotiation.
  491.    The LNS may use this information to initialize its own PPP state
  492.    (thus avoiding an additional LCP negotiation), or it may choose to
  493.    initiate a new LCP CONFREQ exchange.
  494.  
  495.    If the LNS accepts the connection, it creates a "virtual interface"
  496.    for PPP in a manner analogous to what it would use for a direct-
  497.    dialed connection.  With this "virtual interface" in place, link
  498.    layer frames may now pass over this tunnel in both directions.
  499.    Frames from the remote user are received at the POP, stripped of CRC,
  500.    link framing, and transparency bytes, encapsulated in L2TP, and
  501.    forwarded over the appropriate tunnel.
  502.  
  503.    The LNS accepts these frames, strips L2TP, and processes them as
  504.    normal incoming frames for the appropriate interface and protocol.
  505.    The "virtual interface" behaves very much like a hardware interface,
  506.    with the exception that the hardware in this case is physically
  507.    located at the ISP POP.  The other direction behaves analogously,
  508.    with the LNS encapsulating the packet in L2TP, and the NAS stripping
  509.    L2TP before transmitting it out the physical interface to the remote
  510.    user.  For the remainder of this document, a NAS operating as a peer
  511.    to an LNS will be referred to as an L2TP Access Concentrator, or
  512.    "LAC".
  513.  
  514.    At this point, the connectivity is a point-to-point PPP session whose
  515.    endpoints are the remote user's networking application on one end and
  516.    the termination of this connectivity into the LNS's PPP support on
  517.    the other.  Because the remote user has become simply another dial-up
  518.    client of the LNS, client connectivity can now be managed using
  519.    traditional mechanisms with respect to further authorization,
  520.  
  521.  
  522.  
  523. Valencia                 expires December 1997                   [Page 8]
  524.  
  525.  
  526.  
  527.  
  528.  
  529. INTERNET DRAFT                                                 June 1997
  530.  
  531.  
  532.    protocol access, and packet filtering.
  533.  
  534.    Accounting can be performed at both the LAC as well as the LNS.  This
  535.    document illustrates some Accounting techniques which are possible
  536.    using L2TP, but the policies surrounding such Accounting are outside
  537.    the scope of this specification.
  538.  
  539.    L2TP offers optional facilities which maximize compatibility with
  540.    legacy client requirements; L2TP connect notifications for PPP
  541.    clients can contain sufficient information for an LNS to authenticate
  542.    and initialize its LCP state machine.  With these facilities, the
  543.    remote user need not be queried a second time for PPP authentication,
  544.    nor undergo multiple rounds of LCP negotiation and convergence.
  545.    These techniques are intended to optimize connection setup, and are
  546.    not intended to deprecate any functions required by the PPP
  547.    specification.
  548.  
  549. 3.0 Service Model Issues
  550.  
  551.    There are several significant differences between the standard
  552.    Internet access service and the Virtual dial-up service with respect
  553.    to authentication, address allocation, authorization and accounting.
  554.    The details of the differences between these services and the
  555.    problems presented by these differences are described below.  The
  556.    mechanisms used for Virtual Dial-up service are intended to coexist
  557.    with more traditional mechanisms; it is intended that an ISP's POP
  558.    can simultaneously service ISP clients as well as Virtual dial-up
  559.    clients.
  560.  
  561. 3.1 Security
  562.  
  563.    For the Virtual dial-up service, the ISP pursues authentication only
  564.    to the extent required to discover the user's apparent identity (and
  565.    by implication, their desired LNS).  This may involve no more than
  566.    detecting DNIS information when a call arrives, or may involve full
  567.    LCP negotiation and initiation of PPP authentication.  As soon as the
  568.    apparent identity is determined, a connection to the LNS is initiated
  569.    with any authentication information gathered by the ISP.  The LNS
  570.    completes the authentication by either accepting the connection, or
  571.    rejecting it.
  572.  
  573.    The LNS may need to protect against attempts by third parties to
  574.    establish tunnels to the LNS.  Tunnel establishment can include
  575.    authentication to protect against such attacks.
  576.  
  577. 3.2 Address Allocation
  578.  
  579.    For an Internet service, the user accepts that the IP address may be
  580.    allocated dynamically from a pool of ISP addresses.  This model often
  581.    means that the remote user has little or no access to their home
  582.    network's resources, due to firewalls and other security policies
  583.    applied by the home network to accesses from external IP addresses.
  584.  
  585.    For the Virtual dial-up service, the LNS can exist behind the home
  586.  
  587.  
  588.  
  589. Valencia                 expires December 1997                   [Page 9]
  590.  
  591.  
  592.  
  593.  
  594.  
  595. INTERNET DRAFT                                                 June 1997
  596.  
  597.  
  598.    firewall, allocating addresses which are internal (and, in fact, can
  599.    be RFC1918 addresses, or non-IP addresses).  Because L2TP tunnels
  600.    exclusively at the frame layer, the actual policies of such address
  601.    management are irrelevant to correct Virtual dial-up service; for all
  602.    purposes of PPP protocol handling, the dial-in user appears to have
  603.    connected at the LNS.
  604.  
  605. 3.3 Authentication
  606.  
  607.    The authentication of the user occurs in three phases; the first at
  608.    the ISP, and the second and optional third at the LNS.
  609.  
  610.    The ISP uses DNIS, CLID, or username to determine that a Virtual
  611.    dial-up service is required and initiates the tunnel connection to
  612.    the appropriate LNS.  Once a tunnel is established, The ISP NAS
  613.    allocates a new Call ID and initiates a session by forwarding the
  614.    gathered authentication information.
  615.  
  616.    The LNS undertakes the second phase by deciding whether or not to
  617.    accept the connection.  The connection indication may include CHAP,
  618.    PAP, EAP, or textual authentication information.  Based on this
  619.    information, the LNS may accept the connection, or may reject it (for
  620.    instance, it was a PAP request and the username/password are found to
  621.    be incorrect).
  622.  
  623.    Once the connection is accepted, the LNS is free to pursue a third
  624.    phase of authentication at the PPP layer.  These activities are
  625.    outside the scope of this specification, but might include an
  626.    additional cycle of LCP authentication, proprietary PPP extensions,
  627.    or textual challenges carried via a TCP/IP telnet session.
  628.  
  629. 3.4 Accounting
  630.  
  631.    It is a requirement that both the LAC and the LNS be capable of
  632.    providing accounting data and hence both may count packets, octets
  633.    and connection start and stop times.
  634.  
  635.    Since Virtual dial-up is an access service, accounting of connection
  636.    attempts (in particular, failed connection attempts) is of
  637.    significant interest.  The LNS can reject new connections based on
  638.    the authentication information gathered by the LAC, with
  639.    corresponding logging.  For cases where the LNS accepts the
  640.    connection and then continues with further authentication, the LNS
  641.    might subsequently disconnect the client.  For such scenarios, the
  642.    disconnection indication back to the LAC may also include a reason.
  643.  
  644.    Because the LNS can decline a connection based on the authentication
  645.    information collected by the LAC, accounting can easily draw a
  646.    distinction between a series of failed connection attempts and a
  647.    series of brief successful connections.  Lacking this facility, the
  648.    LNS must always accept connection requests, and would need to
  649.    exchange a number of PPP packets with the remote system.  Note that
  650.    the LNS could use this information to decide to accept the connection
  651.    (which protects against most invalid connection attempts) while still
  652.  
  653.  
  654.  
  655. Valencia                 expires December 1997                  [Page 10]
  656.  
  657.  
  658.  
  659.  
  660.  
  661. INTERNET DRAFT                                                 June 1997
  662.  
  663.  
  664.    insisting on running its own CHAP authentication (for instance, to
  665.    protect against CHAP replay attacks).
  666.  
  667. 4.0 Protocol Overview
  668.  
  669.    There are two parallel components of L2TP operating over a given
  670.    tunnel: control messages between each LAC-LNS pair, and payload
  671.    packets between the same LAC-LNS pair.  The latter are used to
  672.    transport L2TP encapsulated PPP packets for user sessions between the
  673.    pair.
  674.  
  675.    The Nr (Next Received) and Ns (Next Sent) fields are always present
  676.    in control messages, and are optionally present in payload messages.
  677.    A single sequence number state is maintained for all control
  678.    messages, and a distinct state is maintained for the payload of each
  679.    user session within the tunnel.  Each state is initialized so the
  680.    first packet is sent with an Ns of 0.  Nr is sent reflecting one more
  681.    than the last in-order received packet; if sent before any packet is
  682.    received it would be 0, indicating that it expects the next new Ns
  683.    value received to be 0.
  684.  
  685.    The sequence number state is maintained and updated as packets are
  686.    sent.  A message (control or payload) with a zero-length body
  687.    indicates that the packet is only used to communicate Nr and Ns
  688.    fields.  The Nr and Ns fields are filled in as above, but the
  689.    sequence number state remains the same.  For non-zero-length body
  690.    messages, the sequence number state is incremented (modulo 2**16)
  691.    after it is copied to the packet's Ns field.  Thus a zero-length
  692.    message's Ns field will reflect one more than the Ns of the last
  693.    non-zero-length message sent.
  694.  
  695.    If a new Ns value has been received by the peer, and no packet has
  696.    been sent with an Nr value to indicate this reception within 1/4 of
  697.    the timeout interval, such a zero-length message is sent.
  698.  
  699.    See Appendix E for some examples of how sequence numbers progress.
  700.  
  701.    4.1 Control Message Overview
  702.  
  703.       Before PPP tunneling can occur between an LAC and LNS, control
  704.       messages must be exchanged between them.  Control messages are
  705.       exchanged over the same tunnel which will be used to forward
  706.       payload data once L2TP call control and management information
  707.       have been passed.  The control messages are responsible for
  708.       establishment, management, and release of sessions carried through
  709.       the tunnel, as well as status on the tunnel itself.  It is the
  710.       means by which an LNS is notified of an incoming call at an
  711.       associated LAC, as well as the means by which an LAC is instructed
  712.       to place an outgoing dial call.
  713.  
  714.       A tunnel may be established by either an LAC (for incoming calls)
  715.       or an LNS (for outgoing calls).  Following the establishment of
  716.       the tunnel, the LNS and LAC configure the tunnel by exchanging
  717.       Start-Control-Connection-Request and -Reply messages.  These
  718.  
  719.  
  720.  
  721. Valencia                 expires December 1997                  [Page 11]
  722.  
  723.  
  724.  
  725.  
  726.  
  727. INTERNET DRAFT                                                 June 1997
  728.  
  729.  
  730.       messages are also used to exchange information about basic
  731.       operating capabilities of the LAC and LNS.  Once the control
  732.       message exchange is complete, the LAC may initiate sessions by
  733.       indicating inbound requests, or the LNS by requesting outbound
  734.       calls.  Control messages may indicate changes in operating
  735.       characteristics of an individual user session with a Set-Link-Info
  736.       message.  Individual sessions may be released by either the LAC or
  737.       LNS, also through control messages.
  738.  
  739.       Independent Call ID values are established for each end of a user
  740.       session.  The sender of a packet associated with a particular
  741.       session places the Call ID established by its peer in the Call ID
  742.       header field of all outgoing packets.  For the cases where a Call
  743.       ID has not yet been assigned from the peer (i.e., during call
  744.       establishment of a new session), the Call ID field is sent as 0,
  745.       and further fields within the message are used to identify the
  746.       session.  The Call ID value of 0 is thus special and MUST NOT be
  747.       used as an Assigned Call ID.
  748.  
  749.       Two mechanisms provide for detection of tunnel connectivity
  750.       problems, one by the reliable transport layer of L2TP and another
  751.       by the higher layer.  The transport layer of L2TP performs control
  752.       message retransmission.  If the number of retransmission attempts
  753.       for a given control message exceeds a configured maximum value,
  754.       the tunnel is reset.  This retransmission mechanism exists in both
  755.       the LNS and LAC ends of the tunnel.  In addition, keepalive
  756.       control echo messages are injected into the control stream by the
  757.       higher L2TP layer after a certain duration of inactivity on a
  758.       given tunnel is detected.  A response to the sent keepalive is
  759.       expected within a configured time interval.  If not received
  760.       within the allowed time interval, the tunnel is reset.  These two
  761.       mechanisms ensure that a connectivity failure between the LNS and
  762.       the LAC can be detected at either end of a tunnel in a timely
  763.       manner.
  764.  
  765.       It is intended that control messages will also carry management
  766.       related information in the future, such as a message allowing the
  767.       LNS to request the status of a given LAC; these message types are
  768.       not defined in this document.
  769.  
  770.    4.2 Payload Packet Overview
  771.  
  772.       Once a tunnel is established and control messages have completed
  773.       tunnel setup, the tunnel can be used to carry user session PPP
  774.       packets for sessions involving a given LNS-LAC pair.  The "Call
  775.       ID" field in the L2TP header indicates to which session a
  776.       particular PPP packet belongs.  In this manner, PPP packets are
  777.       multiplexed and demultiplexed over a single tunnel between a given
  778.       LNS-LAC pair.  The "Call ID" field value is established during the
  779.       exchange of call setup control messages.
  780.  
  781.       It is legal for multiple tunnels to exist between a given LNS-LAC
  782.       pair.  This is useful where each tunnel is used for a single user
  783.       session, and the tunnel media (an SVC, for instance) has specific
  784.  
  785.  
  786.  
  787. Valencia                 expires December 1997                  [Page 12]
  788.  
  789.  
  790.  
  791.  
  792.  
  793. INTERNET DRAFT                                                 June 1997
  794.  
  795.  
  796.       QOS attributes dedicated to a given user.  L2TP provides a tunnel
  797.       identifier so that individual tunnels can be identified, even when
  798.       arriving from a single source LAC or LNS.
  799.  
  800.       The L2TP header also contains optional acknowledgment and
  801.       sequencing information that can be used to perform congestion
  802.       control over the tunnel.  Control messages are used to determine
  803.       rate and buffering parameters that are used to regulate the flow
  804.       of PPP packets for a particular session over the tunnel.  All
  805.       implementations MUST implement flow control, but may indicate that
  806.       flow control is not desired by omitting the Packet Window Size and
  807.       Packet Processing Delay AVP's during call setup.  L2TP does not
  808.       specify the particular algorithms to use for congestion and flow
  809.       control.  Suggested algorithms for the determination of adaptive
  810.       time-outs to recover from dropped data or acknowledgments on the
  811.       tunnel are included in Appendix A of this document.
  812.  
  813.       L2TP does not include a "Receive-Not-Ready" function.  It is
  814.       expected that the flow-control mechanism used will provide an
  815.       adequate "pacing" mechanism so that the sender does not overflow
  816.       the receiver's allotted receive window and receive buffers.  It is
  817.       permissible for the receiving peer to withhold Acks if it is
  818.       unable to accept more data for a connection.  Thus, unlike for the
  819.       Control Message session, the sending peer MUST NOT clear a session
  820.       (or the whole tunnel) as a result of not receiving timely
  821.       acknowledgments for transmitted packets.  The job of detecting a
  822.       non-functioning tunnel lies solely with the Control Message
  823.       functions of L2TP.
  824.  
  825. 5. Message Format and Protocol Extensibility
  826.  
  827.    L2TP defines a set of control messages sent in packets over the
  828.    tunnel between an LNS and a given LAC.  The exact technique for
  829.    initiating a tunnel between an LNS-LAC pair is specific to the tunnel
  830.    media, and specific media are described in section 8.0.
  831.  
  832.    Once media-level connectivity is reached, L2TP message formats define
  833.    the protocol for an LAC and LNS to manage the tunnel and its
  834.    associated sessions.
  835.  
  836.    In each case where a field is optional, if the field is not present,
  837.    its space does not exist in the packet.  Existing fields are placed
  838.    back-to-back to form the packet.
  839.  
  840.    5.1 AVP
  841.  
  842.       To maximize extensibility while still permitting interoperability,
  843.       a uniform method for encoding message types and bodies is used
  844.       throughout L2TP.  This encoding will be termed an AVP (Attribute-
  845.       Value Pair) in the remainder of this document.  Each AVP is
  846.       encoded as:
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853. Valencia                 expires December 1997                  [Page 13]
  854.  
  855.  
  856.  
  857.  
  858.  
  859. INTERNET DRAFT                                                 June 1997
  860.  
  861.  
  862.        0                   1                   2                   3
  863.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  864.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  865.       |M|H|0|0|0|0|  Overall Length   |           Vendor ID           |
  866.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  867.       |          Attribute            | Value...                      |
  868.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  869.       | [until Overall Length is reached]...                          |
  870.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  871.  
  872.       The first six bits are a bit mask, describing the general
  873.       attributes of the AVP.  The M bit, known as the "mandatory" bit,
  874.       controls the behavior required of an implementation which receives
  875.       an AVP which it does not recognize.  If M is set, any session
  876.       associated with this AVP MUST be terminated.  If the AVP is
  877.       associated with the overall tunnel, the entire tunnel (and all
  878.       sessions within) MUST be terminated.  If M is not set, an
  879.       unrecognized AVP should be ignored.
  880.  
  881.       The H bit, known as the "hidden" bit, controls the hiding of the
  882.       data in the value field of an AVP.  This capability can be used to
  883.       avoid the passing of sensitive data, such as user passwords, as
  884.       cleartext in an AVP.  Section 5.7 describes the procedure for
  885.       performing AVP value hiding.
  886.  
  887.       Overall Length encodes the number of octets (including the Overall
  888.       Length field itself) contained in this AVP.  It is 10 bits,
  889.       permitting a maximum of 1024 bytes of data in a single AVP.
  890.  
  891.       Vendor ID is the IANA assigned "SMI Network Management Private
  892.       Enterprise Codes" value, encoded in network byte order.  The value
  893.       0, reserved in this table, corresponds to IETF adopted Attribute
  894.       values, defined within this document.  Any vendor wishing to
  895.       implement L2TP extensions can use their own Vendor ID along with
  896.       private Attribute values, guaranteeing that they will not collide
  897.       with any other vendor's extensions, nor with future IETF
  898.       extensions.
  899.  
  900.       Attribute is the actual attribute, a 16-bit value with a unique
  901.       interpretation across all AVP's defined under a given Vendor ID.
  902.  
  903.       Value follows immediately after the Attribute field, and runs for
  904.       the remaining octets indicated in the Overall Length (i.e.,
  905.       Overall Length minus six octets of header).
  906.  
  907.       AVP's should be kept compact; the combined AVP's within a control
  908.       message MUST NOT ever cause a control message's total length to
  909.       exceed 1500 bytes in length.
  910.  
  911.    5.2 Control Message Format
  912.  
  913.       Each L2TP control message begins with a 16 octet header portion
  914.       followed by zero or more AVP's.  This header is formatted:
  915.  
  916.  
  917.  
  918.  
  919. Valencia                 expires December 1997                  [Page 14]
  920.  
  921.  
  922.  
  923.  
  924.  
  925. INTERNET DRAFT                                                 June 1997
  926.  
  927.  
  928.        0                   1                   2                   3
  929.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  930.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  931.       |T|1|1|1|1|0|0|0|         | Ver |             Length            |
  932.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  933.       |           Tunnel ID           |            Call ID            |
  934.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  935.       |               Ns              |               Nr              |
  936.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  937.       |          Message Type AVP...                                  |
  938.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  939.       |                          ... (8 bytes)                        |
  940.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  941.  
  942.       The T bit MUST be 1, indicating a control message.  The next four
  943.       bits MUST be set to 1, making the header more compatible in
  944.       encoding with the payload message (defined in the next section).
  945.       The K bit is optional, documented below.  The bit following the K
  946.       bit MUST be 0.
  947.  
  948.       Ver MUST be the value 002, indicating a version 1 L2TP message
  949.       (values 000 and 001 are reserved to permit detection of L2F [2]
  950.       and PPTP [3] packets if they arrive intermixed).
  951.  
  952.       Length is the overall length of the message, including header,
  953.       message type AVP, plus any additional AVP's associated with a
  954.       given control message type.
  955.  
  956.       Tunnel ID and Call ID identify the tunnel and user session within
  957.       the tunnel to which a control message applies.  If a control
  958.       message does not apply to a single user session within the tunnel
  959.       (for instance, a Stop-Control-Connection-Request message), Call ID
  960.       MUST be set to 0.  If an Assigned Tunnel ID has not yet been
  961.       received from the peer, Tunnel ID MUST be set to 0.  Once an
  962.       Assigned Tunnel ID is received, all further packets MUST be sent
  963.       with Tunnel ID set to the indicated value.
  964.  
  965.       Nr and Ns reflect the currently transmitted packet and latest
  966.       received packet respectively.  See section 4.0.
  967.  
  968.    5.3 Payload Message Format
  969.  
  970.       PPP payload packets tunneled within L2TP have a smaller
  971.       encapsulation than the L2TP control message header, reducing
  972.       overhead of L2TP during the life of a tunneled PPP session.  The
  973.       MTU for the user data packets encapsulated in L2TP is expected to
  974.       be 1500 octets, not including L2TP and media encapsulation.  The
  975.       smallest L2TP encapsulation is 2 octets; the largest is 14 octets
  976.       (plus padding bytes, if present).  See section 8.1 for further MTU
  977.       considerations.
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985. Valencia                 expires December 1997                  [Page 15]
  986.  
  987.  
  988.  
  989.  
  990.  
  991. INTERNET DRAFT                                                 June 1997
  992.  
  993.  
  994.        0                   1                   2                   3
  995.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  996.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  997.       |T|L|I|C|F|K|O|P|         | Ver |          Length (opt)         |
  998.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  999.       |        Tunnel ID (opt)        |         Call ID (opt)         |
  1000.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1001.       |             Ns (opt)          |               Nr (opt)        |
  1002.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1003.       |      Offset Size (opt)        |    Offset pad... (opt)        |
  1004.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1005.  
  1006.       The T bit MUST be 0, indicating payload.
  1007.  
  1008.       Ver MUST be 002, indicating version 1 of the L2TP protocol.
  1009.  
  1010.       If the L bit is set, the Length field is present, indicating the
  1011.       total length of the received packet.
  1012.  
  1013.       The I and C bits indicate the presence of Tunnel ID and Call ID,
  1014.       respectively.  The interpretation of these fields, if present, is
  1015.       described in section 5.2.
  1016.  
  1017.       If the F bit is set, both the Nr and Ns fields are present.  Ns
  1018.       indicates the sequence number of the packet being sent.  The
  1019.       current packet will be this sequence number if the payload size is
  1020.       non-zero, otherwise this packet is only an acknowledgment
  1021.       (sequence number does not advance).  Nr indicates the next packet
  1022.       sequence number to be received (if the last data packet had Ns set
  1023.       to 1, the Nr sent back would be 2).  Together, these fields can be
  1024.       used to handle out-of-order packets, and to provide flow control
  1025.       for the connection.
  1026.  
  1027.       An L2TP peer setting the F bit, and placing Nr and Ns fields in
  1028.       its messages, MUST have previously received or sent a Receive
  1029.       Window Size AVP from its peer during establishment of the session.
  1030.       The Nr and Ns fields are present and updated as described in
  1031.       section 4.0 if either side has specified an intention to do
  1032.       payload flow control.
  1033.  
  1034.       The K bit MUST be set to 0.  This bit position represents a
  1035.       function no longer present in L2TP.
  1036.  
  1037.       The Offset Size field is present if the O bit is set in the header
  1038.       flags.  This field specifies the number of bytes past the L2TP
  1039.       header at which the payload data is expected to start.  It is
  1040.       recommended that data thus skipped be initialized to 0's.  If
  1041.       Offset Size is 0, or the O bit is not set, the first byte
  1042.       following the last byte of L2TP header is the first byte of
  1043.       payload data.
  1044.  
  1045.       If the P bit is set, this packet should receive preferential
  1046.       treatment in its queueing for transmission.  LCP echo requests
  1047.       used as a keepalive for the link, for instance, should generally
  1048.  
  1049.  
  1050.  
  1051. Valencia                 expires December 1997                  [Page 16]
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057. INTERNET DRAFT                                                 June 1997
  1058.  
  1059.  
  1060.       be sent with this bit set.  Without it, a temporary interval of
  1061.       congestion of the transmission queues could result in the
  1062.       interference with keepalive messages and unnecessary loss of the
  1063.       link.
  1064.  
  1065.    5.4 Control Message Types
  1066.  
  1067.       Control message and AVP types defined in this specification exist
  1068.       under Vendor ID 0, indicating IETF defined behavior.  The actual
  1069.       message and AVP semantics are defined in the next section.  This
  1070.       section includes tables that summarize all currently defined
  1071.       message and AVP types.
  1072.  
  1073.       Each message type entry in the table below consists of 3 columns.
  1074.       The "Num."  column indicates the integer value assigned to this
  1075.       message type.  i The "(Abbrev)" column lists the abbreviation for
  1076.       each message type used in the AVP table that follows.
  1077.  
  1078.       The number in the "Value" column is placed in the Value field of
  1079.       the Message Type AVP.  This AVP MUST be the first AVP in a
  1080.       message.  The currently defined control message types, grouped by
  1081.       function, are:
  1082.  
  1083.       Control Connection Management
  1084.  
  1085.          1  (SCCRQ)    Start-Control-Connection-Request
  1086.          2  (SCCRP)    Start-Control-Connection-Reply
  1087.          3  (SCCCN)    Start-Control-Connection-Connected
  1088.          4  (StopCCRQ) Stop-Control-Connection-Request
  1089.          5  (StopCCRP) Stop-Control-Connection-Reply
  1090.          6             Hello
  1091.  
  1092.       Call Management
  1093.  
  1094.          7  (OCRQ)     Outgoing-Call-Request
  1095.          8  (OCRP)     Outgoing-Call-Reply
  1096.          9  (OCCN)     Outgoing-Call-Connected
  1097.          10 (ICRQ)     Incoming-Call-Request
  1098.          11 (ICRP)     Incoming-Call-Reply
  1099.          12 (ICCN)     Incoming-Call-Connected
  1100.          13 (CCRQ)     Call-Clear-Request
  1101.          14 (CDN)      Call-Disconnect-Notify
  1102.  
  1103.       Error Reporting
  1104.  
  1105.          15 (WEN)      WAN-Error-Notify
  1106.  
  1107.       PPP Session Control
  1108.  
  1109.          16 (SLI)      Set-Link-Info
  1110.  
  1111.    5.5 AVP Summary
  1112.  
  1113.       The following table lists all standard L2TP attributes currently
  1114.  
  1115.  
  1116.  
  1117. Valencia                 expires December 1997                  [Page 17]
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123. INTERNET DRAFT                                                 June 1997
  1124.  
  1125.  
  1126.       defined. The "Attr" column indicates the integer value assigned to
  1127.       this attribute.  The "M" column indicates the setting of the
  1128.       "Mandatory" bit of the AVP header for each attribute.  The "Len"
  1129.       field indicates the size of the AVP including the AVP header.  A
  1130.       "+" in this column indicates that the length varies depending upon
  1131.       the length of the actual contents of the value field.
  1132.  
  1133.       Under the Name column, the parenthesized lists of message type
  1134.       abbreviations indicate the message types that utilize each AVP
  1135.       (See command table above). An abbreviation shown in mixed or
  1136.       uppercase letters indicates that the corresponding AVP MUST be
  1137.       present in this message type; All lowercase indicates that the AVP
  1138.       may optionally appear in this message type.  A "+" appended to a
  1139.       message type abbreviation indicates that the AVP is only mandatory
  1140.       in a "positive" (non-error) condition -- The AVP is optional in a
  1141.       message indicating an error condition.
  1142.  
  1143.       A brief summary of the type and contents of the value field for
  1144.       each attribute is also given for each entry.  Refer to the
  1145.       individual message type descriptions that appear in Section 6 for
  1146.       further details about the use of a particular AVP in a particular
  1147.       message type.
  1148.  
  1149.       Attr M Len            Attribute Name (usage)
  1150.  
  1151.         0  1 8   Message Type (ALL MESSAGES)
  1152.          16 bit integer value indicating the message type, as defined in
  1153.          table above.  MUST be the first AVP in each message
  1154.  
  1155.         1  1 10+ Result Code (CDN, ICRP, OCCN, OCRP, SCCRP, StopCCRP,
  1156.                StopCCRQ)
  1157.          16 bit Integer value indicating result of corresponding request
  1158.          or reason for issuing a request, 16 bit integer General Error
  1159.          code and an optional ASCII string error message.  See Result
  1160.          and General Error code tables below.
  1161.  
  1162.         2  1 8   Protocol Version (SCCRP, SCCRQ)
  1163.          8 bit L2TP Protocol and Revision numbers
  1164.  
  1165.         3  1 10  Framing Capabilities (SCCRP, SCCRQ)
  1166.          32 bit bitmask indicating supported framing types (e.g.,
  1167.          synchronous and asynchronous)
  1168.  
  1169.         4  1 10  Bearer Capabilities (SCCRP, SCCRQ)
  1170.          32 bit bitmask indicating supported bearer types (e.g., analog
  1171.          and digital)
  1172.  
  1173.         5  0 14  Tie Breaker (sccrq)
  1174.          8 byte value used to break control connection establishment
  1175.          collisions
  1176.  
  1177.         6  0 8   Firmware Revision (sccrp, sccrq)
  1178.          16 bit integer representing vendor's firmware revision
  1179.  
  1180.  
  1181.  
  1182.  
  1183. Valencia                 expires December 1997                  [Page 18]
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189. INTERNET DRAFT                                                 June 1997
  1190.  
  1191.  
  1192.         7  0 6+  Host Name (sccrp, sccrq)
  1193.          ASCII string name (e.g., DNS name) of issuer
  1194.  
  1195.         8  0 6+  Vendor Name (sccrp, sccrq)
  1196.          ASCII string describing issuing device
  1197.  
  1198.         9  1 8   Assigned Tunnel ID (SCCRP+, SCCRQ, StopCCRQ)
  1199.          16 bit integer tunnel ID assigned by sender
  1200.  
  1201.        10  1 8   Receive Window Size (iccn, icrp, occn, ocrq, sccrp,
  1202.                sccrq)
  1203.          16 bit integer receive window size offered by sender for a
  1204.          given call or control session
  1205.  
  1206.        11  1 6+  Challenge (sccrp, sccrq)
  1207.          1 or more octet value issued by sender wishing to authenticate
  1208.          control session peer
  1209.  
  1210.        12  0 9+  Q.931 Cause Code (cdn, occn)
  1211.          16 bit cause code, 1 octet cause message, and optional ASCII
  1212.          advisory message
  1213.  
  1214.        13  1 22  Challenge Response (scccn, sccrp)
  1215.          16 octet CHAP type response to peer's Challenge
  1216.  
  1217.        14  1 8   Assigned Call ID (CCRQ, CDN, ICRP+, ICRQ, OCRP+, OCRQ)
  1218.          16 bit integer ID assigned to a call by sender
  1219.  
  1220.        15  1 6+  Call Serial Number (ICRQ, OCRQ)
  1221.          1 or more octet identifier assigned to a call
  1222.  
  1223.        16  1 10  Minimum BPS (OCRQ)
  1224.          32 bit integer indicating lowest acceptable line speed for call
  1225.  
  1226.        17  1 10  Maximum BPS (OCRQ)
  1227.          32 bit integer indicating highest acceptable line speed for
  1228.          call
  1229.  
  1230.        18  1 10  Bearer Type (ICRQ, OCRQ)
  1231.          Indicates bearer type (i.e., analog or digital) for call
  1232.  
  1233.        19  1 10  Framing Type (ICCN, OCCN+, OCRQ)
  1234.          Indicates framing type (i.e., synchronous or asynchronous) for
  1235.          call
  1236.  
  1237.        20  1 8   Packet Processing Delay (iccn, icrp, occn, ocrq)
  1238.          16 bit integer estimate of processing time of full window of
  1239.          received packets by sender
  1240.  
  1241.        21  1 6+  Dialed Number (icrq, OCRQ)
  1242.          ASCII string phone number called or to be called
  1243.  
  1244.        22  1 6+  Dialing Number (icrq)
  1245.          ASCII string phone number of caller
  1246.  
  1247.  
  1248.  
  1249. Valencia                 expires December 1997                  [Page 19]
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255. INTERNET DRAFT                                                 June 1997
  1256.  
  1257.  
  1258.        23  1 6+  Sub-Address (icrq, ocrq)
  1259.          ASCII string containing additional dialing information
  1260.  
  1261.        24  1 10  Connect Speed (ICCN, OCCN+, OCRP+)
  1262.          16 bit integer actual line speed of connection
  1263.  
  1264.        25  1 10  Physical Channel ID (icrq, ocrp)
  1265.          16 bit vendor specific physical device identifier used for call
  1266.  
  1267.        26  0 6+  Initial LCP Confreq (iccn)
  1268.          Octet string containing initial CONFREQ received from client
  1269.  
  1270.        27  0 6+  Last Sent LCP Confreq (iccn)
  1271.          Octet string containing final CONFREQ sent to client
  1272.  
  1273.        28  0 6+  Last Received LCP Confreq (iccn)
  1274.          Octet string containing final CONFREQ received from client
  1275.  
  1276.        29  1 8   Proxy Authen Type (ICCN)
  1277.          16 bit integer code indicating client authentication type
  1278.          negotiated (e.g., PAP, CHAP)
  1279.  
  1280.        30  0 6+  Proxy Authen Name (iccn)
  1281.          ASCII string containing name returned by client in
  1282.          authentication response
  1283.  
  1284.        31  0 6+  Proxy Authen Challenge (iccn)
  1285.          Octet string Challenge presented by LAC to client
  1286.  
  1287.        32  0 8   Proxy Authen ID (iccn)
  1288.          16 bit integer of which low order octet is ID presented to
  1289.          client with Challenge.  High order octet must be 0.
  1290.  
  1291.        33  1 6+  Proxy Authen Response (iccn)
  1292.          Octet string CHAP response or ASCII string password depending
  1293.          on authentication type used
  1294.  
  1295.        34  1 32  Call Errors (WEN)
  1296.          A reserved 16 bit word set to 0 followed by 6 32 bit integer
  1297.          connection error counters
  1298.  
  1299.        35  1 16  ACCM (SLI)
  1300.          A reserved 16 bit word set to 0 followed by 2 32 bit bitmasks
  1301.          containing Send and Receive ACCM values respectively
  1302.  
  1303.        36  1 6+  Random Vector (all messages)
  1304.          Variable length octet string containing a random sequence of
  1305.          values used to accomplish the optional "hiding" of other AVP
  1306.          values (See "H" bit description)
  1307.  
  1308.    5.6 Result and Error Code Summary
  1309.  
  1310.    In general, all Reply Message types contain a Result Code AVP which
  1311.    indicates the result of the requested operation.  The Result Code can
  1312.  
  1313.  
  1314.  
  1315. Valencia                 expires December 1997                  [Page 20]
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321. INTERNET DRAFT                                                 June 1997
  1322.  
  1323.  
  1324.    indicate that additional information pertaining to an error situation
  1325.    can be found in the Error Code field of the Result Code AVP.  The
  1326.    meaning of the result code is tabulated under the specific type of
  1327.    message containing the result.  Each 16-bit Result Code is
  1328.    immediately followed (in the same AVP) by a 16-bit General Error code
  1329.    value.
  1330.  
  1331.    General error codes pertain to types of errors which are not specific
  1332.    to any particular L2TP request, but rather to protocol or message
  1333.    format errors.  If an L2TP reply indicates in its Result Code that a
  1334.    general error occurred, the General Error value should be examined to
  1335.    determine what the error was.  The currently defined General Error
  1336.    codes and their meanings are:
  1337.  
  1338.       0 - No general error
  1339.       1 - No control connection exists yet for this LAC-LNS pair
  1340.       2 - Length is wrong
  1341.       3 - One of the field values was out of range or reserved field was
  1342.          non-zero
  1343.       4 - Insufficient resources to handle this operation now
  1344.       5 - The Call ID is invalid in this context
  1345.       6 - A generic vendor-specific error occurred in the LAC
  1346.       7 - Try another.  If LAC is aware of other possible LNS
  1347.          destinations, it should try one of them.  This can be used to
  1348.          guide an LAC based on LNS policy, for instance, the existence
  1349.          of multilink PPP bundles.
  1350.  
  1351.    If the length of the Result Code AVP specifies that the Value field
  1352.    is more than four octets in length, the remaining bytes after the
  1353.    General Error Code field are an arbitrary string providing further
  1354.    (possibly human readable) text associated with the condition.
  1355.  
  1356.    Generally, when a General Error Code of 6 is used, additional
  1357.    information about the error will be included in the Result Code AVP
  1358.    in the Optional Message field that follows the Error Code field.
  1359.  
  1360.    5.7 Hiding of AVP values
  1361.  
  1362.    The H ("Hidden") bit in the header of each AVP in a control message
  1363.    provides a mechanism to indicate to the receiving peer whether the
  1364.    contents of the AVP are hidden or present in cleartext.  This feature
  1365.    can be used to hide sensitive control message data such as user
  1366.    passwords or user ID's. The H bit MUST NOT be set in the Random
  1367.    Vector AVP.
  1368.  
  1369.    The H bit MUST only be set if tunnel authentication was used and,
  1370.    therefore, a shared secret exists between the peers on either end of
  1371.    the tunnel.  Therefore, the H bit MUST NOT be set in AVP's contained
  1372.    within the Start-Control-Connection-Request, -Reply, and -Connected
  1373.    messages.  If the H bit is set in any AVP(s) in a given command
  1374.    message, a Random Vector AVP must also be present in the message and
  1375.    MUST preceed the first AVP having an H-bit of 1.
  1376.  
  1377.    The following mechanism is applied to the contents of the value field
  1378.  
  1379.  
  1380.  
  1381. Valencia                 expires December 1997                  [Page 21]
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387. INTERNET DRAFT                                                 June 1997
  1388.  
  1389.  
  1390.    of each AVP to which hiding is to be applied.  An MD5 hash is
  1391.    performed on the concatenation of:
  1392.  
  1393.       - the 2 octet Attribute number of the AVP
  1394.       - the shared authentication secret
  1395.       - and an arbitrary length random vector
  1396.  
  1397.    The value of the random vector used in this hash is passed in the
  1398.    value field of a Random Vector AVP.  This Random Vector AVP must be
  1399.    placed in the message by the sender before any hidden AVPs.  The same
  1400.    random vector can be used for more than one hidden AVP in the same
  1401.    message. If a different random vector is used for the hiding of
  1402.    subsequent AVPs then a new Random Vector AVP must be placed in the
  1403.    command message before the first AVP to which it applies.
  1404.  
  1405.    The MD5 hash value is then XORed with the first 16 octet or less
  1406.    segment of the Value and placed in the Value field of the AVP.  If
  1407.    the Value is less than 16 octets, the Value is transformed as if the
  1408.    Value field had been padded to 16 octets before the XOR, but only the
  1409.    actual bytes present in the Value are modified, and the length of the
  1410.    AVP is not altered.
  1411.  
  1412.    If the value is longer than 16 octets, a second one-way MD5 hash is
  1413.    calculated over a stream of octets consisting of the shared secret
  1414.    followed by the result of the first XOR.  That hash is XORed with the
  1415.    second 16 octet or less segment of the value and placed in the
  1416.    corresponding octets of the Value field of the AVP.
  1417.  
  1418.    If necessary, this operation is repeated, with each XOR result being
  1419.    used along with the shared secret to generate the next hash to XOR
  1420.    the next segment of the value with.  This technique results in the
  1421.    content of the AVP being obscured, although the length of the AVP is
  1422.    still known.
  1423.  
  1424.    On receipt, the random vector is taken from the last Random Vector
  1425.    AVP encountered in the message prior to the AVP to be unhidden. The
  1426.    above process is then reversed to yield the original value. For more
  1427.    details on this hiding method, consult the RADIUS [8] RFC.
  1428.  
  1429.    The Random Vector AVP has the following format:
  1430.  
  1431.    Random Vector
  1432.  
  1433.        0                   1                   2                   3
  1434.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1435.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1436.       |1|0|0|0|   6 + String length   |               0               |
  1437.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1438.       |              36               | Random Octet String ...
  1439.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1440.  
  1441.    The Random Vector AVP may be used in any message type. The Attribute
  1442.    value is 36 and it is marked mandatory. It is used to enable the
  1443.    hiding of the values of arbitrary AVPs.  It MUST preceed any AVP
  1444.  
  1445.  
  1446.  
  1447. Valencia                 expires December 1997                  [Page 22]
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453. INTERNET DRAFT                                                 June 1997
  1454.  
  1455.  
  1456.    containing an AVP with the H-bit set but it MUST NOT itself have the
  1457.    H-bit set.  More than one Random Vector AVP may appear in a message,
  1458.    in which case the one most closely preceeding an AVP with the H-bit
  1459.    set pertains to that AVP.  The Random Octet String is the random
  1460.    vector value to use in computing the MD5 hash to retrieve the
  1461.    original value of a hidden AVP.  This string can be of arbitrary
  1462.    length, although a random vector of at least 16 octets is
  1463.    recommended.
  1464.  
  1465. 6.0 Control Connection Protocol Specification
  1466.  
  1467.    Control Connection messages are used to establish and clear user
  1468.    sessions.  The first set of Control Connection messages are used to
  1469.    maintain the control connection itself.  The control connection is
  1470.    initiated by an LAC or LNS after establishing the underlying tunnel-
  1471.    over-media connection.
  1472.  
  1473.    6.0.1 Control Connection Collision
  1474.  
  1475.       For the case where an LAC and LNS both initiate tunnels to each
  1476.       other concurrently, and where the LAC and LNS both determine that
  1477.       a single tunnel suffices (generally because of media
  1478.       characteristic considerations, for instance, whether individual
  1479.       tunnels are needed to gain QOS guarantees for each tunnel), a "tie
  1480.       breaker" may be undertaken.  The details of breaking a tie are
  1481.       documented with the tunnel establishment messages.
  1482.  
  1483.    6.0.2 Reliable Delivery of Control Messages
  1484.  
  1485.       Since L2TP may run across media where packets may be lost, an L2TP
  1486.       peer sending a control message will retransmit the control message
  1487.       after deciding that its remote peer has not received it.  The
  1488.       reliable transport mechanism built into L2TP is essentially a
  1489.       lower layer transport service; the Nr and Ns fields of the control
  1490.       message header belong to this transport layer.  The higher layer
  1491.       functions of L2TP are not concerned with retransmission or
  1492.       ordering of control messages.
  1493.  
  1494.       Each tunnel maintains a queue of control messages to be
  1495.       transmitted to the peer.  The message at the front of the queue is
  1496.       sent with a given Ns value, and is held until a control message
  1497.       arrives from the peer in which the Nr field indicates receipt of
  1498.       this message.  After a fixed (recommended default is 1 second) or
  1499.       adaptive (see Appendix D) timeout interval expires without
  1500.       receiving such an acknowledgment, the control message packet is
  1501.       retransmitted.  The retransmitted packet contains the same Ns
  1502.       value, but the Nr value MUST be updated to reflect any packets
  1503.       received in the interim.
  1504.  
  1505.       If no peer response is detected after several retransmissions (a
  1506.       recommended default is 5, but may be altered due to media
  1507.       considerations), the tunnel and all sessions within MUST be
  1508.       cleared.
  1509.  
  1510.  
  1511.  
  1512.  
  1513. Valencia                 expires December 1997                  [Page 23]
  1514.  
  1515.  
  1516.  
  1517.  
  1518.  
  1519. INTERNET DRAFT                                                 June 1997
  1520.  
  1521.  
  1522.       When a tunnel is being shut down for reasons other than loss of
  1523.       connectivity, the state and reliable delivery mechanisms MUST be
  1524.       maintained and operated for the full retransmission interval after
  1525.       the final message exchange has occurred.  This permits reliable
  1526.       delivery of closing messages in environments where these closing
  1527.       messages might be dropped.
  1528.  
  1529.       Unlike payload traffic, a peer MUST NOT withhold acknowledgment of
  1530.       packets as a technique for flow controlling control messages.  An
  1531.       L2TP implementation is expected to be able to keep up with
  1532.       incoming control messages, possible responding to some with errors
  1533.       reflecting an inability to honor the requested action.
  1534.  
  1535.       A sliding window mechanism is used, by default, for control
  1536.       message transmission.  The default is to permit four control
  1537.       message to be outstanding on a given tunnel.  If a peer specifies
  1538.       a control message window in the Start-Control-Connection-Request
  1539.       and -Reply packets, up to the indicated number of control messages
  1540.       may be sent and held outstanding.  An implementation may only
  1541.       support a receive window of 1, but MUST accept at least a window
  1542.       of 4 from its peer.
  1543.  
  1544.       The transport layer at a receiving peer is responsible for making
  1545.       sure that control messages are delivered in order to the higher
  1546.       layer and that duplicate messages are not delivered to the higher
  1547.       layer.  Messages arriving out of order may be queued for in-order
  1548.       delivery when the missing messages are received or they may be
  1549.       discarded, requiring a retransmission.
  1550.  
  1551.    6.0.3 Control Message Format
  1552.  
  1553.       The following Control Connection messages are all sent as packets
  1554.       on the established tunnel connection between a given LNS-LAC pair.
  1555.       All data is sent in network order (high order octets first).  Any
  1556.       "reserved" or "empty" fields MUST be sent as 0 values to allow for
  1557.       protocol extensibility.
  1558.  
  1559.       Each control message has a header, specified in section 5.2,
  1560.       including an AVP indicating the type of control message, followed
  1561.       by zero or more AVP's appropriate for the given type of control
  1562.       message.  Each control message is described first at a block
  1563.       level, and then with details of each AVP.
  1564.  
  1565. 6.1 Start-Control-Connection-Request
  1566.  
  1567.    The Start-Control-Connection-Request is an L2TP control message used
  1568.    to initialize the tunnel between an LNS and an LAC.  The tunnel must
  1569.    be initialized through the exchange of these control messages before
  1570.    any other L2TP messages can be issued.  The establishment of the
  1571.    control connection is started by the initiator of the underlying
  1572.    tunnel.
  1573.  
  1574.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1575.    |    L2TP Control Message Header      |
  1576.  
  1577.  
  1578.  
  1579. Valencia                 expires December 1997                  [Page 24]
  1580.  
  1581.  
  1582.  
  1583.  
  1584.  
  1585. INTERNET DRAFT                                                 June 1997
  1586.  
  1587.  
  1588.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1589.    |  Start-Control-Connection-Request   |
  1590.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1591.    | Protocol Version      |
  1592.    | Framing Capabilities  |
  1593.    | Bearer Capabilities   |
  1594.    | Tie Breaker           |
  1595.    | Firmware Revision     |
  1596.    | Host Name             |
  1597.    | Vendor Name           |
  1598.    | Assigned Tunnel ID    |
  1599.    | Receive Window Size   |
  1600.    | Challenge             |
  1601.    +-+-+-+-+-+-+-+-+-+-+-+-+
  1602.  
  1603.    Start-Control-Connection-Request
  1604.  
  1605.        0                   1                   2                   3
  1606.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1607.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1608.       |1|0|0|0|        8              |               0               |
  1609.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1610.       |                0              |               1               |
  1611.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1612.  
  1613.       The Message Type AVP contains a Value of 1, indicating Start-
  1614.       Control-Connection-Request.  The Flags indicate a mandatory
  1615.       option.  Details associated with this tunneled session follow in
  1616.       additional AVP's within the packet.
  1617.  
  1618.    Protocol Version
  1619.  
  1620.        0                   1                   2                   3
  1621.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1622.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1623.       |1|0|0|0|           8           |               0               |
  1624.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1625.       |               2               |     0x01      |     0x00      |
  1626.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1627.  
  1628.       The Protocol Version AVP within a Start-Control-Connection-Request
  1629.       packet indicates the L2TP protocol version available.  The
  1630.       Attribute value is 2, indicating Protocol Version, and is marked
  1631.       mandatory.  This AVP MUST be present.  The Value field is a 16-bit
  1632.       hexadecimal value 0x100, indicating L2TP protocol version 1,
  1633.       revision 0.
  1634.  
  1635.    Framing Capabilities
  1636.  
  1637.        0                   1                   2                   3
  1638.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1639.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1640.       |1|0|0|0|          10           |               0               |
  1641.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1642.  
  1643.  
  1644.  
  1645. Valencia                 expires December 1997                  [Page 25]
  1646.  
  1647.  
  1648.  
  1649.  
  1650.  
  1651. INTERNET DRAFT                                                 June 1997
  1652.  
  1653.  
  1654.       |               3               |     0x00      |     0x00      |
  1655.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1656.       |     0x00      |0|0|0|0|0|0|A|S|
  1657.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1658.  
  1659.       The Framing Capabilities AVP within a Start-Control-Connection-
  1660.       Request indicates the type of framing that the sender of this
  1661.       message can provide.  The Attribute value is 3, indicating Framing
  1662.       Capabilities, and is marked mandatory.  This AVP MUST be present.
  1663.       The Value field is a 32-bit quantity, with two bits defined.  If
  1664.       bit A is set, asynchronous framing is supported.  If bit S is set,
  1665.       synchronous framing is supported.
  1666.  
  1667.    Bearer Capabilities
  1668.  
  1669.        0                   1                   2                   3
  1670.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1671.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1672.       |1|0|0|0|          10           |               0               |
  1673.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1674.       |               4               |     0x00      |     0x00      |
  1675.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1676.       |     0x00      |0|0|0|0|0|0|A|D|
  1677.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1678.  
  1679.       The Bearer Capabilities AVP within a Start-Control-Connection-
  1680.       Request indicates the bearer capabilities that the sender of this
  1681.       message can provide.  The Attribute value is 4, indicating Bearer
  1682.       Capabilities, and is marked mandatory.  This AVP MUST be present.
  1683.       The Value field is a 32-bit quantity with two bits defined.  If
  1684.       bit A is set, analog access is supported.  If bit D is set,
  1685.       digital access is supported.
  1686.  
  1687.    Tie Breaker
  1688.  
  1689.        0                   1                   2                   3
  1690.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1691.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1692.       |0|0|0|0|          14           |               0               |
  1693.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1694.       |               5               | Tie Break Value...            |
  1695.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1696.       |                            Value...                           |
  1697.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1698.       |    ...(64 bits)               |
  1699.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1700.  
  1701.       The Tie Breaker AVP within a Start-Control-Connection-Request
  1702.       contains a 64-bit Value used to break ties in tunnel establishment
  1703.       between an LAC-LNS pair.  The Attribute value is 5, indicating Tie
  1704.       Breaker, and is marked optional.  This AVP itself is optional.
  1705.       The 8 byte Value is used as a 64-bit tie breaker value.
  1706.  
  1707.       If present, it indicates the sender wishes a single tunnel to
  1708.  
  1709.  
  1710.  
  1711. Valencia                 expires December 1997                  [Page 26]
  1712.  
  1713.  
  1714.  
  1715.  
  1716.  
  1717. INTERNET DRAFT                                                 June 1997
  1718.  
  1719.  
  1720.       exist between the given LAC-LNS pair, and this value will be used
  1721.       to choose a single tunnel where both LAC and LNS initiate a tunnel
  1722.       concurrently.  The recipient of a Start-Control-Connection-Request
  1723.       must check to see if a Start-Control-Connection-Request has been
  1724.       sent to the peer, and if so, must compare its Tie Breaker value
  1725.       with the received one.  The lower value "wins", and the "loser"
  1726.       MUST initiate a tunnel disconnect for their outstanding tunnel.
  1727.       In the case where a tie breaker is present on both sides, and the
  1728.       value is equal, both sides MUST initiate tunnel disconnects.
  1729.  
  1730.       If a tie breaker is received, and the outstanding Start-Control-
  1731.       Connection-Request had no tie breaker value, the initiator which
  1732.       included the Tie Breaker AVP "wins".
  1733.  
  1734.       It is recommended that the Value be set to the MAC address of a
  1735.       LAN interface on the sender.  If no MAC address is available, a
  1736.       64-bit random number should be used instead.
  1737.  
  1738.    Firmware Revision
  1739.  
  1740.        0                   1                   2                   3
  1741.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1742.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1743.       |0|0|0|0|           8           |               0               |
  1744.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1745.       |               6               |       Firmware Revision       |
  1746.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1747.  
  1748.       The Firmware Revision AVP within a Start-Control-Connection-
  1749.       Request indicates the firmware revision of the issuing device.
  1750.       The Attribute value is 6, indicating Firmware Revision, and is
  1751.       marked optional.  This AVP itself is optional.  The Value field is
  1752.       a 16-bit integer encoded in a vendor specific format.  For devices
  1753.       which do not have a firmware revision (general purpose computers
  1754.       running L2TP software modules, for instance), the revision of the
  1755.       L2TP software module may be reported instead.
  1756.  
  1757.    Host Name
  1758.  
  1759.        0                   1                   2                   3
  1760.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1761.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1762.       |1|0|0|0| 6 + Host name length  |               0               |
  1763.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1764.       |               7               | Host name...
  1765.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1766.  
  1767.       The Host Name AVP within a Start-Control-Connection-Request
  1768.       indicates the name of the issuing LAC or LNS.  The Attribute value
  1769.       is 7, indicating Host Name, and is marked mandatory.  This AVP
  1770.       itself MUST be present.  This name should be as broadly unique as
  1771.       possible; for hosts participating in DNS [4], a hostname with
  1772.       fully qualified domain would be appropriate.
  1773.  
  1774.  
  1775.  
  1776.  
  1777. Valencia                 expires December 1997                  [Page 27]
  1778.  
  1779.  
  1780.  
  1781.  
  1782.  
  1783. INTERNET DRAFT                                                 June 1997
  1784.  
  1785.  
  1786.    Vendor Name
  1787.  
  1788.        0                   1                   2                   3
  1789.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1790.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1791.       |0|0|0|0|6 + vendor name length |               0               |
  1792.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1793.       |               8               | Vendor name...
  1794.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1795.  
  1796.       The Vendor Name AVP within a Start-Control-Connection-Request
  1797.       contains a vendor specific string describing the type of LAC or
  1798.       LNS being used.  The Attribute value is 8, indicating Vendor Name,
  1799.       and is marked optional.  This AVP itself is optional.  The Value
  1800.       is the indicated number of bytes representing the vendor string.
  1801.  
  1802.    Assigned Tunnel ID
  1803.  
  1804.        0                   1                   2                   3
  1805.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1806.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1807.       |1|0|0|0|           8           |               0               |
  1808.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1809.       |               9               |           Tunnel ID           |
  1810.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1811.  
  1812.       The Assigned Tunnel ID AVP within a Start-Control-Connection-
  1813.       Request specifies the Tunnel ID which the receiving peer MUST use
  1814.       in the Tunnel ID field of all subsequent packets.  The Attribute
  1815.       value is 9, indicating Assigned Tunnel ID, and is marked
  1816.       mandatory.  This AVP MUST be present.  Before the Assigned Tunnel
  1817.       ID AVP is received, packets MUST be sent with a Tunnel ID value of
  1818.       0.  The Value is a 16-bit non-zero Tunnel ID value.
  1819.  
  1820.    Receive Window Size
  1821.  
  1822.        0                   1                   2                   3
  1823.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1824.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1825.       |1|0|0|0|           8           |               0               |
  1826.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1827.       |              10               |             Size              |
  1828.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1829.  
  1830.       The Receive Window Size AVP within a Start-Control-Connection-
  1831.       Request specifies the receive window size being offered to the
  1832.       remote peer.  The Attribute value is 10, indicating Receive Window
  1833.       Size, and is mandatory.  This AVP itself is optional.  Value is a
  1834.       16-bit word indicating the offered window size.  If absent, the
  1835.       peer must assume a value of 4 for its transmit window.  The remote
  1836.       peer may send the specified number of control messages before it
  1837.       must wait for an acknowledgment.
  1838.  
  1839.    Challenge
  1840.  
  1841.  
  1842.  
  1843. Valencia                 expires December 1997                  [Page 28]
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849. INTERNET DRAFT                                                 June 1997
  1850.  
  1851.  
  1852.        0                   1                   2                   3
  1853.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1854.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1855.       |1|0|0|0| 6 + Challenge length  |               0               |
  1856.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1857.       |              11               | Challenge...
  1858.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1859.  
  1860.       The Challenge AVP within a Start-Control-Connection-Request
  1861.       indicates that the issuing peer wishes to authenticate the tunnel
  1862.       endpoints.  The Attribute value is 11, indicating Challenge, and
  1863.       is marked mandatory.  This AVP is optional.  The Value is one or
  1864.       more octets of challenge value.
  1865.  
  1866. 6.2 Start-Control-Connection-Reply
  1867.  
  1868.    The Start-Control-Connection-Reply is an L2TP control message sent in
  1869.    reply to a received Start-Control-Connection-Request message.  This
  1870.    message contains a result code indicating the result of the control
  1871.    connection establishment attempt.
  1872.  
  1873.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1874.    |    L2TP Control Message Header      |
  1875.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1876.    |  Start-Control-Connection-Reply     |
  1877.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1878.    | Protocol Version      |
  1879.    | Result Code           |
  1880.    | Framing Capabilities  |
  1881.    | Bearer Capabilities   |
  1882.    | Firmware Revision     |
  1883.    | Host Name             |
  1884.    | Vendor Name           |
  1885.    | Assigned Tunnel ID    |
  1886.    | Receive Window Size   |
  1887.    | Challenge             |
  1888.    | Challenge Response    |
  1889.    +-+-+-+-+-+-+-+-+-+-+-+-+
  1890.  
  1891.    Start-Control-Connection-Reply
  1892.  
  1893.        0                   1                   2                   3
  1894.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1895.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1896.       |1|0|0|0|        8              |               0               |
  1897.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1898.       |                0              |               2               |
  1899.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1900.  
  1901.       The Message Type AVP contains a Value of 2, indicating Start-
  1902.       Control-Connection-Reply.  The Flags indicate a mandatory option.
  1903.  
  1904.    Protocol Version
  1905.  
  1906.  
  1907.  
  1908.  
  1909. Valencia                 expires December 1997                  [Page 29]
  1910.  
  1911.  
  1912.  
  1913.  
  1914.  
  1915. INTERNET DRAFT                                                 June 1997
  1916.  
  1917.  
  1918.        0                   1                   2                   3
  1919.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1920.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1921.       |1|0|0|0|           8           |               0               |
  1922.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1923.       |               2               |     0x01      |     0x00      |
  1924.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1925.  
  1926.       The Protocol Version AVP within a Start-Control-Connection-Reply
  1927.       packet indicates the L2TP protocol version available.  The
  1928.       Attribute value is 2, indicating Protocol Version, and the Value
  1929.       field is a 16-bit hexadecimal value 0x100, indicating L2TP
  1930.       protocol version 1, revision 0.  This AVP MUST be present.
  1931.  
  1932.    Framing Capabilities
  1933.  
  1934.        0                   1                   2                   3
  1935.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1936.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1937.       |1|0|0|0|          10           |               0               |
  1938.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1939.       |               3               |     0x00      |     0x00      |
  1940.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1941.       |     0x00      |0|0|0|0|0|0|A|S|
  1942.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1943.  
  1944.       The Framing Capabilities AVP within a Start-Control-Connection-
  1945.       Reply indicates the type of framing that the sender of this
  1946.       message can provide.  The Attribute is 3, it is a mandatory AVP,
  1947.       the Value field is a 32-bit quantity, with two bits defined.  If
  1948.       bit A is set, asynchronous framing is supported.  If bit S is set,
  1949.       synchronous framing is supported.  This AVP MUST be present if the
  1950.       Result AVP indicates success.
  1951.  
  1952.    Bearer Capabilities
  1953.  
  1954.        0                   1                   2                   3
  1955.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1956.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1957.       |1|0|0|0|          10           |               0               |
  1958.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1959.       |               4               |     0x00      |     0x00      |
  1960.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1961.       |     0x00      |0|0|0|0|0|0|A|D|
  1962.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1963.  
  1964.       The Bearer Capabilities AVP within a Start-Control-Connection-
  1965.       Reply indicates the bearer capabilities that the sender of this
  1966.       message can provide.  The Attribute is 4, it is a mandatory AVP,
  1967.       the Value field is a 32-bit quantity with two bits defined.  If
  1968.       bit A is set, analog access is supported.  If bit D is set,
  1969.       digital access is supported.  This AVP MUST be present if the
  1970.       Result AVP indicates success.
  1971.  
  1972.  
  1973.  
  1974.  
  1975. Valencia                 expires December 1997                  [Page 30]
  1976.  
  1977.  
  1978.  
  1979.  
  1980.  
  1981. INTERNET DRAFT                                                 June 1997
  1982.  
  1983.  
  1984.    Firmware Revision
  1985.  
  1986.        0                   1                   2                   3
  1987.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  1988.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1989.       |0|0|0|0|           8           |               0               |
  1990.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1991.       |               6               |       Firmware Revision       |
  1992.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1993.  
  1994.       The Firmware Revision AVP within a Start-Control-Connection-Reply
  1995.       indicates the firmware revision of the issuing device.  The
  1996.       Attribute is 6, it is not a mandatory AVP, the Value field is a
  1997.       16-bit integer encoded in a vendor specific format.  For devices
  1998.       which do not have a firmware revision (general purposes computers
  1999.       running L2TP software modules, for instance), the revision of the
  2000.       L2TP software module may be reported instead.  This AVP is
  2001.       optional.
  2002.  
  2003.    Host Name
  2004.  
  2005.        0                   1                   2                   3
  2006.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2007.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2008.       |1|0|0|0| 6 + Host name length  |               0               |
  2009.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2010.       |               7             | Host name...
  2011.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2012.  
  2013.       The Host Name AVP within a Start-Control-Connection-Reply
  2014.       indicates the name of the issuing LAC or LNS.  See the notes in
  2015.       section 6.1 concerning Host Name contents.  It is encoded as the
  2016.       Attribute 7, mandatory, with the indicated number of bytes
  2017.       representing the host name string.  This AVP MUST be present.
  2018.  
  2019.    Vendor Name
  2020.  
  2021.        0                   1                   2                   3
  2022.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2023.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2024.       |0|0|0|0|6 + Vendor name length |               0               |
  2025.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2026.       |               8               |Vendor name...
  2027.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2028.  
  2029.       The Vendor Name AVP within a Start-Control-Connection-Reply
  2030.       contains a vendor specific string describing the type of LAC or
  2031.       LNS being used.  It is encoded as the Attribute 8, not mandatory,
  2032.       with the indicated number of bytes representing the vendor string.
  2033.       This AVP is optional.
  2034.  
  2035.    Assigned Tunnel ID
  2036.  
  2037.        0                   1                   2                   3
  2038.  
  2039.  
  2040.  
  2041. Valencia                 expires December 1997                  [Page 31]
  2042.  
  2043.  
  2044.  
  2045.  
  2046.  
  2047. INTERNET DRAFT                                                 June 1997
  2048.  
  2049.  
  2050.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2051.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2052.       |1|0|0|0|           8           |               0               |
  2053.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2054.       |               9               |           Tunnel ID           |
  2055.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2056.  
  2057.       The Assigned Tunnel ID AVP within a Start-Control-Connection-Reply
  2058.       specifies the Tunnel ID which the receiving peer MUST use in all
  2059.       subsequent packets.  It is encoded as the Attribute 9, mandatory,
  2060.       with a 16-bit non-zero Tunnel ID value.  This AVP MUST be present
  2061.       if the Result Code indicates "Successful channel establishment".
  2062.  
  2063.    Receive Window Size
  2064.  
  2065.        0                   1                   2                   3
  2066.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2067.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2068.       |1|0|0|0|           8           |               0               |
  2069.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2070.       |              10               |             size              |
  2071.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2072.  
  2073.       The Receive Window Size AVP within a Start-Control-Connection-
  2074.       Reply specifies the receive window size being offered to the
  2075.       remote peer.  The Attribute value is 10, indicating Receive Window
  2076.       Size, and is mandatory.  This AVP itself is optional.  Value is a
  2077.       16-bit word indicating the offered window size.  If absent, the
  2078.       peer must assume a value of 4 for its transmit window.  The remote
  2079.       peer may send the specified number of control messages before it
  2080.       must wait for an acknowledgment.
  2081.  
  2082.    Result Code
  2083.  
  2084.        0                   1                   2                   3
  2085.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2086.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2087.       |1|0|0|0|  10 + Message length  |               0               |
  2088.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2089.       |               1               |          Result Code          |
  2090.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2091.       |           Error Code          |      Optional Message ...
  2092.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2093.  
  2094.       The Result Code AVP within a Start-Control-Connection-Reply packet
  2095.       indicates the result of the control channel establishment attempt.
  2096.       It is encoded as Attribute 1, indicating a Result Code AVP.  This
  2097.       AVP is mandatory and MUST be present.  The Result Code is a 16-bit
  2098.       word.  The 16-bit word following the Result Code field contains
  2099.       the Error Code value.  The Result Code value indicates whether the
  2100.       Error Code value is meaningful or not.  If it is not meaningful it
  2101.       MUST be set to a value of 0.  An optional error message can follow
  2102.       the Error Code field.  Its presence and length is indicated by the
  2103.       value of the AVP length field.
  2104.  
  2105.  
  2106.  
  2107. Valencia                 expires December 1997                  [Page 32]
  2108.  
  2109.  
  2110.  
  2111.  
  2112.  
  2113. INTERNET DRAFT                                                 June 1997
  2114.  
  2115.  
  2116.       Result code values are:
  2117.          1 - Successful channel establishment
  2118.          2 - General error--Error Code indicates the problem
  2119.          3 - Control channel already exists
  2120.          4 - Requester is not authorized to establish a control channel
  2121.          5 - The protocol version of the requester is not supported
  2122.  
  2123.    Challenge
  2124.  
  2125.        0                   1                   2                   3
  2126.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2127.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2128.       |1|0|0|0| 6 + Challenge length  |               0               |
  2129.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2130.       |              11               | Challenge...
  2131.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2132.  
  2133.       The Challenge AVP within a Start-Control-Connection-Reply
  2134.       indicates that the peer wishes to authenticate the tunnel
  2135.       initiator.  It is encoded as the Attribute 11, mandatory, with at
  2136.       least one byte of challenge value embedded.  If this AVP is not
  2137.       present, it indicates to the receiving peer that the sender does
  2138.       not wish to authenticate that peer.
  2139.  
  2140.    Challenge Response
  2141.  
  2142.        0                   1                   2                   3
  2143.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2144.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2145.       |1|0|0|0|          22           |               0               |
  2146.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2147.       |              13               |   Response...                 |
  2148.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2149.       | Response... (128 bits)        |
  2150.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2151.  
  2152.       The Response AVP within a Start-Control-Connection-Reply packet
  2153.       provides a response to a challenge received.  The Attribute value
  2154.       is 13, indicating Response, and the Value field is a 128-bit value
  2155.       reflecting the CHAP-style response to the challenge.  This AVP
  2156.       marked mandatory, and MUST be present if a challenge was received
  2157.       and this Start-Control-Connection-Reply indicates success.  For
  2158.       purposes of the ID value in the CHAP response calculation, the
  2159.       fixed value 0 MUST be used.
  2160.  
  2161. 6.3 Start-Control-Connection-Connected
  2162.  
  2163.    The Start-Control-Connection-Connected message is an L2TP control
  2164.    message sent in reply to a received Start-Control-Connection-Reply
  2165.    message.  This message provides closure to the tunnel establishment
  2166.    process, and includes a challenge response if the peer sent a
  2167.    challenge in the Start-Control-Connection-Reply message.
  2168.  
  2169.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2170.  
  2171.  
  2172.  
  2173. Valencia                 expires December 1997                  [Page 33]
  2174.  
  2175.  
  2176.  
  2177.  
  2178.  
  2179. INTERNET DRAFT                                                 June 1997
  2180.  
  2181.  
  2182.    |    L2TP Control Message Header      |
  2183.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2184.    |  Start-Control-Connection-Connected |
  2185.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2186.    | Challenge Response    |
  2187.    +-+-+-+-+-+-+-+-+-+-+-+-+
  2188.  
  2189.    Start-Control-Connection-Connected
  2190.  
  2191.        0                   1                   2                   3
  2192.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2193.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2194.       |1|0|0|0|           8           |               0               |
  2195.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2196.       |               0               |               3               |
  2197.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2198.  
  2199.       The Message Type AVP contains a Value of 3, indicating Start-
  2200.       Control-Connection-Connected.  The Flags indicate a mandatory
  2201.       option.
  2202.  
  2203.    Challenge Response
  2204.  
  2205.        0                   1                   2                   3
  2206.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2207.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2208.       |1|0|0|0|          22           |               0               |
  2209.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2210.       |              13               |   Response...                 |
  2211.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2212.       | Response... (128 bits)        |
  2213.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2214.  
  2215.       The Challenge Response AVP within a Start-Control-Connection-
  2216.       Connected packet provides a response to a challenge received.  The
  2217.       Attribute value is 13, indicating Response, and the Value field is
  2218.       a 128-bit value reflecting the CHAP-style response to the
  2219.       challenge.  This AVP is marked mandatory, and MUST be present if a
  2220.       challenge was received, otherwise MUST be omitted.  For purposes
  2221.       of the ID value in the CHAP response calculation, the fixed value
  2222.       0 MUST be used.
  2223.  
  2224. 6.4 Stop-Control-Connection-Request
  2225.  
  2226.    The Stop-Control-Connection-Request is an L2TP control message sent
  2227.    by one peer of an LAC-LNS control connection to inform the other peer
  2228.    that the control connection should be closed.  In addition to closing
  2229.    the control connection, all active user calls are implicitly cleared.
  2230.    The reason for issuing this request is indicated in the Result Code
  2231.    AVP.
  2232.  
  2233.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2234.    |    L2TP Control Message Header      |
  2235.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2236.  
  2237.  
  2238.  
  2239. Valencia                 expires December 1997                  [Page 34]
  2240.  
  2241.  
  2242.  
  2243.  
  2244.  
  2245. INTERNET DRAFT                                                 June 1997
  2246.  
  2247.  
  2248.    |  Stop-Control-Connection-Request    |
  2249.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2250.    | Assigned Tunnel ID    |
  2251.    | Result Code           |
  2252.    +-+-+-+-+-+-+-+-+-+-+-+-+
  2253.  
  2254.    Stop-Control-Connection-Request AVP
  2255.  
  2256.        0                   1                   2                   3
  2257.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2258.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2259.       |1|0|0|0|           8           |               0               |
  2260.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2261.       |               0               |               4               |
  2262.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2263.  
  2264.       The Message Type AVP contains a Value of 4, indicating Stop-
  2265.       Control-Connection-Request.  The Flags indicate a mandatory
  2266.       option.
  2267.  
  2268.    Assigned Tunnel ID
  2269.  
  2270.        0                   1                   2                   3
  2271.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2272.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2273.       |1|0|0|0|           8           |               0               |
  2274.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2275.       |               9               |           Tunnel ID           |
  2276.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2277.  
  2278.       The Attribute value is 9, indicating Assigned Tunnel ID, and is
  2279.       marked mandatory.  This AVP MUST be present.  The Value MUST be
  2280.       the same Assigned Tunnel ID first sent to the receiving peer.
  2281.       This AVP permits the peer to identify the appropriate tunnel even
  2282.       if Stop-Control-Connection-Request must be sent before an Assigned
  2283.       Tunnel ID is received.
  2284.  
  2285.    Result Code
  2286.  
  2287.        0                   1                   2                   3
  2288.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2289.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2290.       |1|0|0|0|  10 + Message length  |               0               |
  2291.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2292.       |               1               |          Result Code          |
  2293.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2294.       |           Error Code          |      Optional Message ...
  2295.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2296.  
  2297.       The Result Code AVP within a Stop-Control-Connection-Request
  2298.       packet indicates the reason for terminating the control channel.
  2299.       It is encoded as Attribute 1, indicating a Result Code AVP.  This
  2300.       AVP is mandatory and MUST be present.  The Result Code is a 16-bit
  2301.       word.  The 16-bit word following the Result Code field contains
  2302.  
  2303.  
  2304.  
  2305. Valencia                 expires December 1997                  [Page 35]
  2306.  
  2307.  
  2308.  
  2309.  
  2310.  
  2311. INTERNET DRAFT                                                 June 1997
  2312.  
  2313.  
  2314.       the Error Code value, which for a Stop-Control-Connection-Request
  2315.       is always 0.  An optional message can follow the Error Code field.
  2316.       Its presence and length is indicated by the value of the AVP
  2317.       length field.  Defined Result Code values are:
  2318.  
  2319.          1 - General request to clear control connection
  2320.          2 - Can't support peer's version of the protocol
  2321.          3 - Requester is being shut down
  2322.  
  2323. 6.5 Stop-Control-Connection-Reply
  2324.  
  2325.    The Stop-Control-Connection-Reply is an L2TP control message sent by
  2326.    one peer of an LAC-LNS control connection upon receipt of a Stop-
  2327.    Control-Connection-Request from the other peer.
  2328.  
  2329.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2330.    |    L2TP Control Message Header      |
  2331.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2332.    |    Stop-Control-Connection-Reply    |
  2333.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2334.    | Result Code           |
  2335.    +-+-+-+-+-+-+-+-+-+-+-+-+
  2336.  
  2337.    Stop-Control-Connection-Reply
  2338.  
  2339.        0                   1                   2                   3
  2340.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2341.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2342.       |1|0|0|0|           8           |               0               |
  2343.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2344.       |               0               |               5               |
  2345.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2346.  
  2347.       The Message Type AVP contains a Value of 5, indicating Stop-
  2348.       Control-Connection-Reply.  The Flags indicate a mandatory option.
  2349.  
  2350.    Result Code
  2351.  
  2352.        0                   1                   2                   3
  2353.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2354.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2355.       |1|0|0|0|  10 + Message length  |               0               |
  2356.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2357.       |               1               |          Result Code          |
  2358.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2359.       |           Error Code          |      Optional Message ...
  2360.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2361.  
  2362.       The Result Code AVP within a Stop-Control-Connection-Reply packet
  2363.       indicates the result of the control channel close attempt.  It is
  2364.       encoded as Attribute 1, indicating a Result Code AVP.  This AVP is
  2365.       mandatory and MUST be present.  The Result Code is a 16-bit word.
  2366.       The 16-bit word following the Result Code field contains the Error
  2367.       Code value.  The Result Code value indicates whether the Error
  2368.  
  2369.  
  2370.  
  2371. Valencia                 expires December 1997                  [Page 36]
  2372.  
  2373.  
  2374.  
  2375.  
  2376.  
  2377. INTERNET DRAFT                                                 June 1997
  2378.  
  2379.  
  2380.       Code value is meaningful or not.  If it is not meaningful it
  2381.       should be set to a value of 0.  An optional error message can
  2382.       follow the Error Code field.  Defined Values are:
  2383.  
  2384.          1 - Control connection closed
  2385.          2 - Control connection not closed for reason indicated in Error Code
  2386.  
  2387. 6.6 Hello
  2388.  
  2389.    The Hello message is an L2TP control message sent by either peer of a
  2390.    LAC-LNS control connection.  This control message is used as a
  2391.    "keepalive" for the control connection.
  2392.  
  2393.    Keepalives should be implemented by sending a Hello once every 60
  2394.    seconds if 60 seconds have passed without sending a message to the
  2395.    peer.  When a Hello is received, it MUST be silently discarded (after
  2396.    updating any effects of the indicated Nr/Ns values).
  2397.  
  2398.    Because a Hello is a control message, and control messages are
  2399.    reliably sent by the lower level transport, this keepalive function
  2400.    operates by causing the transport level to reliably deliver a
  2401.    message.  If a media interruption has occurred, the reliable
  2402.    transport will be unable to deliver the Hello across, and will clean
  2403.    up the tunnel.
  2404.  
  2405.    Hello messages are global to the tunnel; the Call ID field of these
  2406.    control messages MUST be 0.
  2407.  
  2408.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2409.    |    L2TP Control Message Header      |
  2410.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2411.    |    Hello                            |
  2412.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2413.  
  2414.    Hello
  2415.  
  2416.        0                   1                   2                   3
  2417.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2418.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2419.       |1|0|0|0|           8           |               0               |
  2420.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2421.       |               0               |               6               |
  2422.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2423.  
  2424.       The Message Type AVP contains a Value of 6, indicating Hello The
  2425.       Flags indicate a mandatory option.
  2426.  
  2427. 6.7 Outgoing-Call-Request
  2428.  
  2429.    The Outgoing-Call-Request is an L2TP control message sent by the LNS
  2430.    to the LAC to indicate that an outbound call from the LNS is to be
  2431.    established.  This request provides the LAC with information required
  2432.    to make the call.  It also provides information to the LAC that is
  2433.    used to regulate the transmission of data to the LNS for this session
  2434.  
  2435.  
  2436.  
  2437. Valencia                 expires December 1997                  [Page 37]
  2438.  
  2439.  
  2440.  
  2441.  
  2442.  
  2443. INTERNET DRAFT                                                 June 1997
  2444.  
  2445.  
  2446.    once it is established.
  2447.  
  2448.    This message is the first in the "three-way handshake" used by L2TP
  2449.    for establishing outgoing calls.  The first message requests the
  2450.    call; the second indicates that the call was successfully initiated.
  2451.    The third and final message indicates that the call was established.
  2452.  
  2453.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2454.    |          L2TP Control Message Header        |
  2455.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2456.    |            Outgoing-Call-Request            |
  2457.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2458.    | Assigned Call ID        |
  2459.    | Call Serial Number      |
  2460.    | Minimum BPS             |
  2461.    | Maximum BPS             |
  2462.    | Bearer Type             |
  2463.    | Framing Type            |
  2464.    | Receive Window Size     |
  2465.    | Packet Processing Delay |
  2466.    | Dialed Number           |
  2467.    | Sub-Address             |
  2468.    +-+-+-+-+-+-+-+-+-+-+-+-+-+
  2469.  
  2470.    Outgoing-Call-Request
  2471.  
  2472.        0                   1                   2                   3
  2473.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2474.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2475.       |1|0|0|0|           8           |               0               |
  2476.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2477.       |               0               |               7               |
  2478.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2479.  
  2480.       The Message Type AVP contains a Value of 7, indicating Outgoing-
  2481.       Call-Request.  The Outgoing-Call-Request encodes a request to an
  2482.       LAC to establish an outgoing call.  The flags indicate a mandatory
  2483.       option.
  2484.  
  2485.       Assigned Call ID
  2486.  
  2487.        0                   1                   2                   3
  2488.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2489.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2490.       |1|0|0|0|           8           |               0               |
  2491.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2492.       |              14               |            Call ID            |
  2493.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2494.  
  2495.       The Assigned Call ID AVP encodes the ID being assigned to this
  2496.       call by the LNS.  The Attribute value is 14, indicating Assigned
  2497.       Call ID, and is marked mandatory.  This AVP MUST be present.  The
  2498.       LAC places this value in the Call ID header field of all command
  2499.       and payload packets that it subsequently transmits over the tunnel
  2500.  
  2501.  
  2502.  
  2503. Valencia                 expires December 1997                  [Page 38]
  2504.  
  2505.  
  2506.  
  2507.  
  2508.  
  2509. INTERNET DRAFT                                                 June 1997
  2510.  
  2511.  
  2512.       that belong to this call.  The Call ID value is an identifier
  2513.       assigned by the LNS to this session.  It is used to multiplex and
  2514.       demultiplex data sent over that tunnel between the LNS and LAC.
  2515.  
  2516.       Call Serial Number
  2517.  
  2518.        0                   1                   2                   3
  2519.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2520.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2521.       |1|0|0|0|   6 + Number length   |               0               |
  2522.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2523.       |              15               |   Number...
  2524.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2525.  
  2526.       Call Serial Number AVP encodes an identifier assigned by the LNS to
  2527.       this call.
  2528.       Attribute is 15, indicating Call Serial Number, and is marked mandatory.
  2529.       This AVP MUST be present.
  2530.       The Call Serial Number is intended
  2531.       to be an easy reference for administrators on both ends of a tunnel to use
  2532.       when investigating call failure problems.  Call Serial Numbers should
  2533.       be set to progressively increasing values, which are likely to be unique for
  2534.       a significant period of time across all interconnected LNS and LACs.  Other
  2535.       identification information may also be prepended.
  2536.  
  2537.       Minimum BPS
  2538.  
  2539.        0                   1                   2                   3
  2540.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2541.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2542.       |1|0|0|0|          10           |               0               |
  2543.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2544.       |              16               |           BPS (H)             |
  2545.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2546.       |            BPS (L)            |
  2547.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2548.  
  2549.       Minimum BPS AVP encodes the lowest acceptable line speed for this
  2550.       call.  Attribute is 16, Minimum BPS, and is marked mandatory.
  2551.       This AVP MUST be present.  The BPS value indicates the speed in
  2552.       bits/second.
  2553.  
  2554.       Maximum BPS
  2555.  
  2556.        0                   1                   2                   3
  2557.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2558.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2559.       |1|0|0|0|          10           |               0               |
  2560.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2561.       |              17               |           BPS (H)             |
  2562.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2563.       |            BPS (L)            |
  2564.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2565.  
  2566.  
  2567.  
  2568.  
  2569. Valencia                 expires December 1997                  [Page 39]
  2570.  
  2571.  
  2572.  
  2573.  
  2574.  
  2575. INTERNET DRAFT                                                 June 1997
  2576.  
  2577.  
  2578.       Maximum BPS AVP encodes the highest acceptable line speed for this
  2579.       call.  Attribute is 17, indicating Maximum BPS, and is marked
  2580.       mandatory.  This AVP MUST be present.  The BPS value indicates the
  2581.       speed in bits/second.
  2582.  
  2583.       Bearer Type
  2584.  
  2585.        0                   1                   2                   3
  2586.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2587.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2588.       |1|0|0|0|          10           |               0               |
  2589.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2590.       |              18               |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
  2591.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2592.       |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D|
  2593.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2594.  
  2595.       Bearer Type AVP encodes the bearer type for the requested call.
  2596.       The value bit field Attribute is 18, indicating Bearer Type, and
  2597.       is marked mandatory.  This AVP MUST be present.  The Value is a
  2598.       32-bit quantity indicating the bearer capability required for this
  2599.       outgoing call.  If set, bit A indicates that the call should be on
  2600.       an analog channel.  If set, bit D indicates that the call should
  2601.       be on a digital channel.  Both may be set, indicating that the
  2602.       call can be of either type.
  2603.  
  2604.       Framing Type
  2605.  
  2606.        0                   1                   2                   3
  2607.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2608.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2609.       |1|0|0|0|          10           |               0               |
  2610.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2611.       |              19               |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
  2612.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2613.       |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S|
  2614.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2615.  
  2616.       Framing Type AVP encodes the framing type for the requested call.
  2617.       Attribute is 19, indicating Framing Type, and is marked mandatory.
  2618.       This AVP MUST be present.  The 32-bit field indicates the type of
  2619.       PPP framing to be used for the outgoing call.  Bit A if set
  2620.       indicates that asynchronous framing should be used.  Bit S is set
  2621.       indicates that synchronous framing should be used.
  2622.  
  2623.       Receive Window Size
  2624.  
  2625.        0                   1                   2                   3
  2626.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2627.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2628.       |1|0|0|0|           8           |               0               |
  2629.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2630.       |              10               |             Size              |
  2631.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2632.  
  2633.  
  2634.  
  2635. Valencia                 expires December 1997                  [Page 40]
  2636.  
  2637.  
  2638.  
  2639.  
  2640.  
  2641. INTERNET DRAFT                                                 June 1997
  2642.  
  2643.  
  2644.       Receive Window Size AVP encodes the window size being advertised
  2645.       by the LNS for this call.  Attribute is 10, indicating Receive
  2646.       Window Size, and is marked mandatory.  This AVP is optional.  The
  2647.       Size value indicates the number of received data packets the LNS
  2648.       will buffer for this call, which is also the maximum number of
  2649.       data packets the LAC should send before waiting for an
  2650.       acknowledgment.  The absence of this AVP indicates that Sequence
  2651.       and Acknowledgment Numbers are not to be used in the payload
  2652.       session for this call.
  2653.  
  2654.       Packet Processing Delay
  2655.  
  2656.        0                   1                   2                   3
  2657.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2658.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2659.       |1|0|0|0|           8           |               0               |
  2660.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2661.       |              20               |             Delay             |
  2662.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2663.  
  2664.       The Packet Processing Delay AVP encodes the delay LNS has for
  2665.       processing a window full of packets sent by the LAC.  Attribute is
  2666.       20, indicating Packet Processing Delay, and is marked mandatory.
  2667.       This AVP is optional.  The Delay value is specified in units of
  2668.       1/10 seconds.  Refer to Appendix A for a description of how this
  2669.       value is determined and used.
  2670.  
  2671.       Dialed Number
  2672.  
  2673.        0                   1                   2                   3
  2674.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2675.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2676.       |1|0|0|0|6 + Phone Number length|               0               |
  2677.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2678.       |              21               | Phone Number..
  2679.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2680.  
  2681.       Phone Number AVP encodes the phone number to be called.  Attribute
  2682.       is 21, indicating Phone Number, and is marked mandatory.  This AVP
  2683.       MUST be present.  The Phone Number value is an ASCII string.
  2684.  
  2685.       Sub-Address
  2686.  
  2687.        0                   1                   2                   3
  2688.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2689.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2690.       |1|0|0|0|6 + Sub-Address length |               0               |
  2691.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2692.       |              23               |Sub-Address ...
  2693.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2694.  
  2695.       Sub-Address AVP encodes additional dialing information.  Attribute
  2696.       is 23, indicating Sub-Address, and is marked mandatory.  This AVP
  2697.       is optional.  The Sub-Address value is an ASCII string.
  2698.  
  2699.  
  2700.  
  2701. Valencia                 expires December 1997                  [Page 41]
  2702.  
  2703.  
  2704.  
  2705.  
  2706.  
  2707. INTERNET DRAFT                                                 June 1997
  2708.  
  2709.  
  2710. 6.8 Outgoing-Call-Reply
  2711.  
  2712.    The Outgoing-Call-Reply is an L2TP control message sent by the LAC to
  2713.    the LNS in response to a received Outgoing-Call-Request message. The
  2714.    reply indicates whether or not the LAC is able to attempt the
  2715.    outbound call and also returns certain parameters regarding the call
  2716.    attempt.
  2717.  
  2718.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2719.    |          L2TP Control Message Header        |
  2720.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2721.    |             Outgoing-Call-Reply             |
  2722.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2723.    | Assigned Call ID          |
  2724.    | Result Code               |
  2725.    | Connect Speed             |
  2726.    | Physical Channel Id       |
  2727.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2728.  
  2729.    Outgoing-Call-Reply
  2730.  
  2731.     0                   1                   2                   3
  2732.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2733.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2734.    |1|0|0|0|           8           |               0               |
  2735.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2736.    |               0               |               8               |
  2737.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2738.  
  2739.    The Message Type AVP contains a Value of 8, indicating Outgoing-
  2740.    Call-Reply.  The Outgoing-Call-Reply message encodes the immediate
  2741.    result of attempting an outgoing call request.  The flags indicate a
  2742.    mandatory option.
  2743.  
  2744.    Assigned Call ID
  2745.  
  2746.     0                   1                   2                   3
  2747.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2748.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2749.    |1|0|0|0|           8           |               0               |
  2750.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2751.    |              14               |            Call ID            |
  2752.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2753.  
  2754.    The Assigned Call ID AVP encodes the ID being assigned to this call
  2755.    by the LAC.  Attribute is 14, indicating Assigned Call ID, and is
  2756.    marked mandatory.  This AVP MUST be present if the Result Code
  2757.    indicates a call is in progress.  Call ID value is an identifier,
  2758.    unique within the tunnel, assigned by the sender to this session.
  2759.    The remote peer MUST place this Call ID in the Call ID portion of all
  2760.    future packets it sends associated with this session.  It is used to
  2761.    multiplex and demultiplex data sent over that tunnel between the LNS
  2762.    and LAC.
  2763.  
  2764.  
  2765.  
  2766.  
  2767. Valencia                 expires December 1997                  [Page 42]
  2768.  
  2769.  
  2770.  
  2771.  
  2772.  
  2773. INTERNET DRAFT                                                 June 1997
  2774.  
  2775.  
  2776.    Result Code
  2777.  
  2778.        0                   1                   2                   3
  2779.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2780.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2781.       |1|0|0|0|  10 + Message length  |               0               |
  2782.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2783.       |               1               |          Result Code          |
  2784.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2785.       |           Error Code          |      Optional Message ...
  2786.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2787.  
  2788.       The Result Code AVP within an Outgoing-Call-Request indicates the
  2789.       result of the outgoing call establishment attempt.  It is encoded
  2790.       as Attribute 1, indicating a Result Code AVP.  This AVP is
  2791.       mandatory and MUST be present.  The Result Code is a 16-bit word.
  2792.       The 16-bit word following the Result Code field contains the Error
  2793.       Code value.  The Result Code value indicates whether the Error
  2794.       Code value is meaningful or not.  If it is not meaningful it
  2795.       should be set to a value of 0.  An optional error message can
  2796.       follow the Error Code field.  Its presence and length is indicated
  2797.       by the value of the AVP length field.  Defined Result Code values
  2798.       are:
  2799.  
  2800.          1 - Call attempt in progress
  2801.          2 - Outgoing Call not attempted for the reason indicated in Error Code
  2802.          3 - No appropriate facilities are available (temporary condition)
  2803.          4 - No appropriate facilities are available (permanent condition)
  2804.          5 - Invalid destination
  2805.          6 - Outgoing Call administratively prohibited
  2806.  
  2807.  
  2808.       Connect Speed
  2809.  
  2810.        0                   1                   2                   3
  2811.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2812.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2813.       |1|0|0|0|          10           |               0               |
  2814.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2815.       |              24               |            BPS (H)            |
  2816.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2817.       |           BPS (L)             |
  2818.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2819.  
  2820.       Connect Speed BPS AVP encodes the speed of the facility chosen for
  2821.       the connection attempt.  The Attribute value is 24, indicating
  2822.       Connect Speed, and is marked mandatory.  This AVP MUST be present
  2823.       if the Result indicates a call is in progress.  The BPS is a 32-
  2824.       bit value indicating the speed in bits/second.
  2825.  
  2826.       Physical Channel ID
  2827.  
  2828.        0                   1                   2                   3
  2829.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2830.  
  2831.  
  2832.  
  2833. Valencia                 expires December 1997                  [Page 43]
  2834.  
  2835.  
  2836.  
  2837.  
  2838.  
  2839. INTERNET DRAFT                                                 June 1997
  2840.  
  2841.  
  2842.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2843.       |1|0|0|0|          10           |               0               |
  2844.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2845.       |              25               |            ID (H)             |
  2846.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2847.       |          ID (L)               |
  2848.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2849.  
  2850.       Physical Channel ID AVP encodes the vendor specific physical
  2851.       channel number used for the call.  The Attribute value is 25,
  2852.       indicating Physical Channel ID, and is marked optional.  This AVP
  2853.       itself is optional.  ID is a 32-bit value in network byte order.
  2854.       The value is used for logging purposes only.
  2855.  
  2856. 6.9 Outgoing-Call-Connected
  2857.  
  2858.    Outgoing-Call-Connected is an L2TP control message sent by the LAC to
  2859.    the LNS to indicate the result of a requested outgoing call.  The LAC
  2860.    MUST send the corresponding Outgoing-Call-Reply to the LNS before
  2861.    sending this message.  This message provides information to the LNS
  2862.    about the particular parameters used for the call.  It provides
  2863.    information to allow the LNS to regulate the transmission of data to
  2864.    the LAC for this session.
  2865.  
  2866.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2867.    |          L2TP Control Message Header        |
  2868.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2869.    |            Outgoing-Call-Connected          |
  2870.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2871.    | Result Code               |
  2872.    | Q.931 Cause Code          |
  2873.    | Connect Speed             |
  2874.    | Framing Type              |
  2875.    | Receive Window Size       |
  2876.    | Packet Processing Delay   |
  2877.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2878.  
  2879.    Outgoing-Call-Connected
  2880.  
  2881.     0                   1                   2                   3
  2882.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2883.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2884.    |1|0|0|0|           8           |               0               |
  2885.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2886.    |               0               |               9               |
  2887.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2888.  
  2889.    The Message Type AVP contains a Value of 16, indicating Outgoing-
  2890.    Call-Connected.  The Outgoing-Call-Connected message encodes the
  2891.    final result of an outgoing call request.  The flags indicate a
  2892.    mandatory option.
  2893.  
  2894.    Result Code
  2895.  
  2896.  
  2897.  
  2898.  
  2899. Valencia                 expires December 1997                  [Page 44]
  2900.  
  2901.  
  2902.  
  2903.  
  2904.  
  2905. INTERNET DRAFT                                                 June 1997
  2906.  
  2907.  
  2908.        0                   1                   2                   3
  2909.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2910.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2911.       |1|0|0|0|  10 + Message length  |               0               |
  2912.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2913.       |               1               |          Result Code          |
  2914.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2915.       |           Error Code          |      Optional Message ...
  2916.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2917.  
  2918.       The Result Code AVP within an Outgoing-Call-Connected message
  2919.       indicates the final result of the outgoing call establishment
  2920.       attempt.  It is encoded as Attribute 1, indicating a Result Code
  2921.       AVP.  This AVP is mandatory and MUST be present.  The Result Code
  2922.       is a 16-bit word.  The 16-bit word following the Result Code field
  2923.       contains the Error Code value.  The Result Code value indicates
  2924.       whether the Error Code value is meaningful or not.  If it is not
  2925.       meaningful it should be set to a value of 0.  An optional error
  2926.       message can follow the Error Code field.  Its presence and length
  2927.       is indicated by the value of the AVP length field.  Defined Result
  2928.       Code values are:
  2929.  
  2930.          1 - Call established with no errors
  2931.          2 - Outgoing Call not established for the reason indicated in Error Code
  2932.          3 - Outgoing Call failed due to no carrier detected
  2933.          4 - Outgoing Call failed due to detection of a busy signal
  2934.          5 - Outgoing Call failed due to lack of a dial tone
  2935.          6 - Outgoing Call was not established within time allotted by LAC
  2936.          7 - Outgoing Call was connected but no appropriate framing was detected
  2937.  
  2938.       Q.931 Cause Code
  2939.  
  2940.        0                   1                   2                   3
  2941.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2942.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2943.       |0|0|0|0|9 + Advisory Msg length|              0                |
  2944.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2945.       |              12               |          Cause Code           |
  2946.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2947.       |   Cause Msg   |Advisory Msg...
  2948.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2949.  
  2950.       The Q.931 Cause Code AVP is used to give additional information in
  2951.       cases of call failure.  The Attribute value is 12, indicating
  2952.       Cause Code, and is marked mandatory.  This AVP is optional.  It is
  2953.       only relevant when the LAC uses Q.931/DSS1 for the outbound call
  2954.       attempt.  Cause Code is the returned Q.931 Cause code and Cause
  2955.       Msg is the returned Q.931 message code (e.g., DISCONNECT)
  2956.       associated with the Cause Code.  Both values are returned in their
  2957.       native ITU encodings.  An additional ASCII text Advisory Message
  2958.       may also be included (presence indicated by the AVP length) to
  2959.       further explain the call failure.
  2960.  
  2961.       Connect Speed
  2962.  
  2963.  
  2964.  
  2965. Valencia                 expires December 1997                  [Page 45]
  2966.  
  2967.  
  2968.  
  2969.  
  2970.  
  2971. INTERNET DRAFT                                                 June 1997
  2972.  
  2973.  
  2974.        0                   1                   2                   3
  2975.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2976.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2977.       |1|0|0|0|          10           |               0               |
  2978.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2979.       |              24               |            BPS (H)            |
  2980.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2981.       |           BPS (L)             |
  2982.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2983.  
  2984.       Connect Speed BPS AVP encodes the final negotiated speed for the
  2985.       connection.  The Attribute value is 24, indicating Connect Speed,
  2986.       and is marked mandatory.  This AVP MUST be present if the call
  2987.       attempt is successful.  The BPS value indicates the speed in
  2988.       bits/second.
  2989.  
  2990.       Framing Type
  2991.  
  2992.        0                   1                   2                   3
  2993.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2994.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2995.       |1|0|0|0|          10           |              0                |
  2996.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2997.       |              19               |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
  2998.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2999.       |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S|
  3000.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3001.  
  3002.       Framing Type AVP encodes the framing type for the call.  The
  3003.       Attribute value is 19, indicating Framing Type, and is marked
  3004.       mandatory.  This AVP MUST be present if the call attempt is
  3005.       successful.  The value bit field indicates the type of PPP framing
  3006.       is used for the call.  If set, bit A indicates that asynchronous
  3007.       framing is being used.  If set, bit S indicates that synchronous
  3008.       framing is being used.
  3009.  
  3010.       Receive Window Size
  3011.  
  3012.        0                   1                   2                   3
  3013.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3014.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3015.       |1|0|0|0|           8           |              0                |
  3016.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3017.       |              10               |            Size               |
  3018.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3019.  
  3020.       Receive Window Size AVP encodes the window size being offered by
  3021.       the LNS for this call.  The Attribute value is 10, indicating
  3022.       Receive Window Size, and is marked mandatory.  The Size is a 16-
  3023.       bit value indicating the number of received data packets the LAC
  3024.       will buffer for this call, which is also the maximum number of
  3025.       data packets the LNS should send before waiting for an
  3026.       acknowledgment.  This AVP MUST be present if and only if Sequence
  3027.       and Acknowledgment Numbers are to be used in the payload session
  3028.  
  3029.  
  3030.  
  3031. Valencia                 expires December 1997                  [Page 46]
  3032.  
  3033.  
  3034.  
  3035.  
  3036.  
  3037. INTERNET DRAFT                                                 June 1997
  3038.  
  3039.  
  3040.       for this call.
  3041.  
  3042.       Packet Processing Delay
  3043.  
  3044.        0                   1                   2                   3
  3045.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3046.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3047.       |1|0|0|0|           8           |               0               |
  3048.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3049.       |              20               |             Delay             |
  3050.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3051.  
  3052.       Packet Processing Delay AVP encodes the delay the LAC expects for
  3053.       processing a window full of packets sent by the LNS.  The
  3054.       Attribute value is 20, indicating Packet Processing Delay, and is
  3055.       marked mandatory.  This AVP is optional.  The Delay value is
  3056.       specified in units of 1/10 seconds.  Refer to Appendix A to see a
  3057.       description of how this value is determined and used.
  3058.  
  3059. 6.10 Incoming-Call-Request
  3060.  
  3061.    Incoming-Call-Request is an L2TP control message sent by the LAC to
  3062.    the LNS to indicate that an inbound call is to be established from
  3063.    the LAC.  This request provides the LNS with parameter information
  3064.    for the incoming call.
  3065.  
  3066.    This message is the first in the "three-way handshake" used by L2TP
  3067.    for establishing incoming calls.  The LAC may defer answering the
  3068.    call until it has received an Incoming-Call-Reply from the LNS
  3069.    indicating that the call should be established.  This mechanism
  3070.    allows the LNS to obtain sufficient information about the call before
  3071.    it is answered to determine whether the call should be answered or
  3072.    not.  Alternatively, the LAC may answer the call, negotiate LCP and
  3073.    PPP authentication, and use the information gained to choose the LNS.
  3074.    In this case, the call has already been answered by the time the
  3075.    Incoming-Call-Reply message is received; the LAC simply spoofs the
  3076.    "call indication/answer call" phase in this case.
  3077.  
  3078.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3079.    |          L2TP Control Message Header        |
  3080.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3081.    |             Incoming-Call-Request           |
  3082.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3083.    | Assigned Call ID          |
  3084.    | Call Serial Number        |
  3085.    | Bearer Type               |
  3086.    | Physical Channel ID       |
  3087.    | Dialed Number             |
  3088.    | Dialing Number            |
  3089.    | Sub-Address               |
  3090.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3091.  
  3092.    Incoming-Call-Request
  3093.  
  3094.  
  3095.  
  3096.  
  3097. Valencia                 expires December 1997                  [Page 47]
  3098.  
  3099.  
  3100.  
  3101.  
  3102.  
  3103. INTERNET DRAFT                                                 June 1997
  3104.  
  3105.  
  3106.     0                   1                   2                   3
  3107.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3108.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3109.    |1|0|0|0|           8           |               0               |
  3110.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3111.    |               0               |              10               |
  3112.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3113.  
  3114.    The Message Type AVP contains a Value of 10, indicating Incoming-
  3115.    Call-Request.  The Incoming-Call-Request message encodes an incoming
  3116.    call being indicated by the LAC.  The flags indicate a mandatory
  3117.    option.
  3118.  
  3119.    Assigned Call ID
  3120.  
  3121.     0                   1                   2                   3
  3122.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3123.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3124.    |1|0|0|0|           8           |               0               |
  3125.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3126.    |              14               |            Call ID            |
  3127.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3128.  
  3129.    The Assigned Call ID AVP encodes the Call ID being assigned to call
  3130.    by the LAC.  The Attribute value is 14, indicating Call ID, and is
  3131.    marked mandatory.  This AVP MUST be present.  The LNS places this
  3132.    value in the Call ID header field of all command and payload packets
  3133.    that it subsequently transmits over the tunnel that belong to this
  3134.    call.  The Call ID value is an identifier assigned by the LAC to this
  3135.    session.  It is used to multiplex and demultiplex data sent over that
  3136.    tunnel between the LNS and LAC.
  3137.  
  3138.    Call Serial Number
  3139.  
  3140.     0                   1                   2                   3
  3141.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3142.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3143.    |1|0|0|0|   6 + Number length   |              0                |
  3144.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3145.    |              15               |   Number...
  3146.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3147.  
  3148.    Call Serial Number AVP encodes an identifier assigned by the LAC to
  3149.    this call.  The Attribute value is 15, Call Serial Number, and is
  3150.    marked mandatory.  This AVP MUST be present.  Please refer to the
  3151.    description of this field from section 6.8.
  3152.  
  3153.    Bearer Type
  3154.  
  3155.     0                   1                   2                   3
  3156.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3157.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3158.    |1|0|0|0|          10           |                0              |
  3159.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3160.  
  3161.  
  3162.  
  3163. Valencia                 expires December 1997                  [Page 48]
  3164.  
  3165.  
  3166.  
  3167.  
  3168.  
  3169. INTERNET DRAFT                                                 June 1997
  3170.  
  3171.  
  3172.    |              18               |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
  3173.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3174.    |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D|
  3175.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3176.  
  3177.    Bearer Type AVP encodes the bearer type for the incoming call.  The
  3178.    Attribute value is 18, Bearer Type, and is marked mandatory.  This
  3179.    AVP MUST be present.  The Value is a 32-bit field indicating the
  3180.    bearer capability being used by the incoming call.  If set, bit A
  3181.    indicates that the call is on an analog channel.  If set, bit D
  3182.    indicates that the call is on a digital channel.
  3183.  
  3184.    Physical Channel ID
  3185.  
  3186.     0                   1                   2                   3
  3187.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3188.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3189.    |1|0|0|0|          10           |               0               |
  3190.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3191.    |              25               |            ID (H)             |
  3192.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3193.    |          ID (L)               |
  3194.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3195.  
  3196.    Physical Channel ID AVP encodes the vendor specific physical channel
  3197.    number used for the call.  The Attribute value is 25, Physical
  3198.    Channel ID, and is marked mandatory.  The presence of this AVP is
  3199.    optional.  ID is a 32-bit value in network byte order.  The value is
  3200.    used for logging purposes only.
  3201.  
  3202.    Dialed Number
  3203.  
  3204.     0                   1                   2                   3
  3205.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3206.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3207.    |1|0|0|0|6 + Phone Number length|               0               |
  3208.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3209.    |              21               | Phone Number..
  3210.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3211.  
  3212.    Dialed Number AVP encodes the dialed number for the incoming call,
  3213.    that is, DNIS.  The Attribute value is 21, Dialed Number, and is
  3214.    marked mandatory.  The presence of this AVP is optional.  The value
  3215.    is an ASCII string.
  3216.  
  3217.    Dialing Number
  3218.  
  3219.     0                   1                   2                   3
  3220.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3221.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3222.    |1|0|0|0|6 + Phone Number length|               0               |
  3223.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3224.    |              22               |Phone Number...
  3225.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3226.  
  3227.  
  3228.  
  3229. Valencia                 expires December 1997                  [Page 49]
  3230.  
  3231.  
  3232.  
  3233.  
  3234.  
  3235. INTERNET DRAFT                                                 June 1997
  3236.  
  3237.  
  3238.    Dialing Number AVP encodes the originating number for the incoming
  3239.    call, that is, CLID.  The Attribute value is 22, Dialing Number, and
  3240.    is marked mandatory.  The presence of this AVP is optional.  The
  3241.    value is an ASCII string.
  3242.  
  3243.    Sub-Address
  3244.  
  3245.     0                   1                   2                   3
  3246.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3247.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3248.    |1|0|0|0|6 + Sub-Address length |               0               |
  3249.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3250.    |              23               |Sub-Address ...
  3251.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3252.  
  3253.    Sub-Address AVP encodes additional dialing information.  The
  3254.    Attribute value is 23, Sub-Address, and is marked mandatory.  The
  3255.    presence of this AVP is optional.  The Sub-Address value is an ASCII
  3256.    string.
  3257.  
  3258. 6.11 Incoming-Call-Reply
  3259.  
  3260.    The Incoming-Call-Reply is an L2TP control message sent by the LNS to
  3261.    the LAC in response to a received Incoming-Call-Request message.  The
  3262.    reply indicates the result of the incoming call attempt.  It also
  3263.    provides information to allow the LAC to regulate the transmission of
  3264.    data to the LNS for this session.
  3265.  
  3266.    This message is the second in the three-way handshake used by L2TP
  3267.    for establishing incoming calls.  It indicates to the LAC whether the
  3268.    call should be answered or not.
  3269.  
  3270.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3271.    |          L2TP Control Message Header        |
  3272.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3273.    |             Incoming-Call-Reply             |
  3274.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3275.    | Assigned Call ID              |
  3276.    | Result Code                   |
  3277.    | Receive Window Size           |
  3278.    | Packet Processing Delay       |
  3279.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3280.  
  3281.    Incoming-Call-Reply
  3282.  
  3283.     0                   1                   2                   3
  3284.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3285.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3286.    |1|0|0|0|           8           |               0               |
  3287.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3288.    |               0               |              11               |
  3289.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3290.  
  3291.    The Message Type AVP contains a Value of 10, indicating Incoming-
  3292.  
  3293.  
  3294.  
  3295. Valencia                 expires December 1997                  [Page 50]
  3296.  
  3297.  
  3298.  
  3299.  
  3300.  
  3301. INTERNET DRAFT                                                 June 1997
  3302.  
  3303.  
  3304.    Call-Reply.  The Incoming-Call-Reply message  encodes a response by
  3305.    the LNS to the incoming call indication given by the LAC.  The flags
  3306.    indicate a mandatory option.
  3307.  
  3308.    Assigned Call ID
  3309.  
  3310.     0                   1                   2                   3
  3311.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3312.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3313.    |1|0|0|0|           8           |               0               |
  3314.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3315.    |              14               |            Call ID            |
  3316.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3317.  
  3318.    The Assigned Call ID AVP encodes the ID being assigned to call by the
  3319.    LNS.  The Attribute value is 14, Assigned Call ID, and is marked
  3320.    mandatory.  This AVP MUST be present if the Result Code indicates the
  3321.    call was successful.  The LAC places this value in the Call ID header
  3322.    field of all command and payload packets that it subsequently
  3323.    transmits over the tunnel that belong to this call.  The Call ID
  3324.    value is an identifier assigned by the LNS to this session.  It is
  3325.    used to multiplex and demultiplex data sent over that tunnel between
  3326.    the LNS and LAC.
  3327.  
  3328.    Result Code
  3329.  
  3330.        0                   1                   2                   3
  3331.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3332.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3333.       |1|0|0|0|  10 + Message length  |               0               |
  3334.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3335.       |               1               |          Result Code          |
  3336.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3337.       |           Error Code          |      Optional Message ...
  3338.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3339.  
  3340.       The Result Code AVP within an Incoming-Call-Reply message
  3341.       indicates the result of the incoming call establishment attempt.
  3342.       It is encoded as Attribute 1, indicating a Result Code AVP.  This
  3343.       AVP is mandatory and MUST be present.  The Result Code is a 16-bit
  3344.       word.  The 16-bit word following the Result Code field contains
  3345.       the Error Code value.  The Result Code value indicates whether the
  3346.       Error Code value is meaningful or not.  If it is not meaningful it
  3347.       should be set to a value of 0.  An optional error message can
  3348.       follow the Error Code field.  Its presence and length is indicated
  3349.       by the value of the AVP length field.  Defined Result Code values
  3350.       are:
  3351.  
  3352.          1 - The LAC should answer the incoming call
  3353.          2 - The Incoming Call should not be established due to the
  3354.             reason indicated in Error Code
  3355.          3 - The LAC should not accept the incoming call.  It should
  3356.             hang up or issue a busy indication
  3357.  
  3358.  
  3359.  
  3360.  
  3361. Valencia                 expires December 1997                  [Page 51]
  3362.  
  3363.  
  3364.  
  3365.  
  3366.  
  3367. INTERNET DRAFT                                                 June 1997
  3368.  
  3369.  
  3370.       Receive Window Size
  3371.  
  3372.        0                   1                   2                   3
  3373.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3374.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3375.       |1|0|0|0|           8           |              0                |
  3376.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3377.       |              10               |            Size               |
  3378.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3379.       | Optional Message...           |
  3380.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3381.  
  3382.       Receive Window Size AVP encodes the receive window size being
  3383.       offered by the LNS for this call.  The Attribute value is 10,
  3384.       Receive Window Size, and is marked mandatory.  The Size value
  3385.       indicates the number of received data packets the LNS will buffer
  3386.       for this call, which is also the maximum number of data packets
  3387.       the LAC should send before waiting for an acknowledgment.  This
  3388.       AVP is optional if Sequence and Acknowledgment Numbers are not to
  3389.       be used in the payload session for this call, or if the Result AVP
  3390.       indicates failure.
  3391.  
  3392.       Packet Processing Delay
  3393.  
  3394.        0                   1                   2                   3
  3395.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3396.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3397.       |1|0|0|0|           8           |               0               |
  3398.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3399.       |              20               |             Delay             |
  3400.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3401.  
  3402.       Packet Processing Delay AVP encodes the delay the LNS expects for
  3403.       processing a window full of packets sent by the LAC.  The
  3404.       Attribute value is 20, Packet Processing Delay AVP, and is marked
  3405.       mandatory.  The presence of this AVP is optional.  The Delay value
  3406.       is specified in units of 1/10 seconds.  Refer to Appendix A to see
  3407.       a description of how this value is determined and used.
  3408.  
  3409. 6.12 Incoming-Call-Connected
  3410.  
  3411.    The Incoming-Call-Connected message is an L2TP control message sent
  3412.    by the LAC to the LNS in response to a received Incoming-Call-Reply.
  3413.    It provides information to the LNS about particular parameters used
  3414.    for the call.  It also provides information to allow the LNS to
  3415.    regulate the transmission of data to the LAC for this session.
  3416.  
  3417.    This message is the third in the three-way handshake used by L2TP for
  3418.    establishing incoming calls.  It provides a mechanism for providing
  3419.    the LNS with additional information about the call that cannot, in
  3420.    general, be obtained at the time the Incoming-Call-Request is issued
  3421.    by the LAC.
  3422.  
  3423.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3424.  
  3425.  
  3426.  
  3427. Valencia                 expires December 1997                  [Page 52]
  3428.  
  3429.  
  3430.  
  3431.  
  3432.  
  3433. INTERNET DRAFT                                                 June 1997
  3434.  
  3435.  
  3436.    |          L2TP Control Message Header        |
  3437.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3438.    |             Incoming-Call-Connected         |
  3439.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3440.    | Connect Speed             |
  3441.    | Framing Type              |
  3442.    | Receive Window Size       |
  3443.    | Packet Processing Delay   |
  3444.    | Initial LCP Confreq       |
  3445.    | Last Sent LCP Confreq     |
  3446.    | Last Received LCP Confreq |
  3447.    | Proxy authen type         |
  3448.    | Proxy authen name         |
  3449.    | Proxy authen challenge    |
  3450.    | Proxy authen ID           |
  3451.    | Proxy authen response     |
  3452.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3453.  
  3454.    Incoming-Call-Connected
  3455.  
  3456.     0                   1                   2                   3
  3457.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3458.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3459.    |1|0|0|0|           8           |               0               |
  3460.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3461.    |               0               |              12               |
  3462.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3463.  
  3464.    The Message Type AVP contains a Value of 11, indicating Incoming-
  3465.    Call-Connected.  The Incoming-Call-Connected message encodes a
  3466.    response by the LAC to the Incoming-Call-Reply message sent by the
  3467.    LAC.  The flags indicate a mandatory option.
  3468.  
  3469.    Connect Speed
  3470.  
  3471.     0                   1                   2                   3
  3472.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3473.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3474.    |1|0|0|0|          10           |               0               |
  3475.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3476.    |              24               |            BPS (H)            |
  3477.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3478.    |           BPS (L)             |
  3479.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3480.  
  3481.    Connect Speed BPS AVP encodes the speed for the connection.  The
  3482.    Attribute value is 24, Connect Speed, and is marked mandatory.  This
  3483.    AVP MUST be present.  The value is a 32-bit quantity indicating the
  3484.    speed in bits/second.
  3485.  
  3486.    Framing Type
  3487.  
  3488.     0                   1                   2                   3
  3489.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3490.  
  3491.  
  3492.  
  3493. Valencia                 expires December 1997                  [Page 53]
  3494.  
  3495.  
  3496.  
  3497.  
  3498.  
  3499. INTERNET DRAFT                                                 June 1997
  3500.  
  3501.  
  3502.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3503.    |1|0|0|0|          10           |              0                |
  3504.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3505.    |              19               |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
  3506.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3507.    |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S|
  3508.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3509.  
  3510.    Framing Type AVP encodes the framing type for the call.  The
  3511.    Attribute value is 19, Framing Type, and is marked mandatory.  This
  3512.    AVP MUST be present.  The value is a 32-bit bit field indicating the
  3513.    type of PPP framing used for the call.  If set, bit A indicates that
  3514.    asynchronous framing is being used.  If set, bit S indicates that
  3515.    synchronous framing is being used.
  3516.  
  3517.    Receive Window Size
  3518.  
  3519.     0                   1                   2                   3
  3520.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3521.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3522.    |1|0|0|0|           8           |               0               |
  3523.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3524.    |              10               |             Size              |
  3525.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3526.  
  3527.    Receive Window Size AVP encodes the window size being offered by the
  3528.    LAC for this call.  The Attribute value is 10, Receive Window Size,
  3529.    and is marked mandatory.  This AVP is optional if Sequence and
  3530.    Acknowledgment Numbers are not to be used in the payload session for
  3531.    this call.  The 16-bit Size value indicates the number of received
  3532.    data packets the LAC will buffer for this call, which is also the
  3533.    maximum number of data packets the LNS should send before waiting for
  3534.    an acknowledgment.
  3535.  
  3536.    Packet Processing Delay
  3537.  
  3538.     0                   1                   2                   3
  3539.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3540.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3541.    |1|0|0|0|           8           |               0               |
  3542.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3543.    |              20               |             Delay             |
  3544.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3545.  
  3546.    Packet Processing Delay AVP encodes the delay the LAC expects for
  3547.    processing a window full of packets sent by the LNS.  The Attribute
  3548.    value is 20, Packet Processing Delay, and is marked mandatory.  The
  3549.    presence of this AVP is optional.  The 16-bit Delay value is
  3550.    specified in units of 1/10 seconds.  Refer to Appendix A to see a
  3551.    description of how this value is determined and used.
  3552.  
  3553.    Initial LCP Confreq
  3554.  
  3555.     0                   1                   2                   3
  3556.  
  3557.  
  3558.  
  3559. Valencia                 expires December 1997                  [Page 54]
  3560.  
  3561.  
  3562.  
  3563.  
  3564.  
  3565. INTERNET DRAFT                                                 June 1997
  3566.  
  3567.  
  3568.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3569.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3570.    |0|0|0|0|6 + LCP confreq length |               0               |
  3571.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3572.    |              26               | LCP confreq...
  3573.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3574.  
  3575.    The LAC may have answered the phone call and negotiated LCP with the
  3576.    dial-in client in order to establish the client's apparent identity.
  3577.    In this case, this option may be included to indicate the link
  3578.    properties the client requested in its initial LCP CONFREQ request.
  3579.    The Attribute value is 26, Initial LCP Confreq, and is marked
  3580.    optional.  The presence of this AVP is optional.  The Value field is
  3581.    a copy of the body of the initial CONFREQ received, starting at the
  3582.    first option within this packet's body.
  3583.  
  3584.    Last Sent LCP Confreq
  3585.  
  3586.     0                   1                   2                   3
  3587.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3588.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3589.    |0|0|0|0|6 + LCP confreq length |               0               |
  3590.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3591.    |              27               | LCP confreq...
  3592.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3593.  
  3594.    See Initial LCP Confreq above for rationale.  The Attribute value is
  3595.    27, Last Sent LCP Confreq, and is marked optional.  The presence of
  3596.    this AVP is optional.  The Value field is a copy of the body of the
  3597.    final CONFREQ sent to the client to complete LCP negotiation,
  3598.    starting at the first option within this packet's body.
  3599.  
  3600.    Last Received LCP Confreq
  3601.  
  3602.     0                   1                   2                   3
  3603.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3604.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3605.    |0|0|0|0|6 + LCP confreq length |               0               |
  3606.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3607.    |              28               | LCP confreq...
  3608.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3609.  
  3610.    See Initial LCP Confreq above for rationale.  The Attribute value is
  3611.    28, Last Received LCP Confreq, and is marked optional.  The presence
  3612.    of this AVP is optional.  The Value field is a copy of the body of
  3613.    the final CONFREQ received from the client to complete LCP
  3614.    negotiation, starting at the first option within this packet's body.
  3615.  
  3616.    Proxy Authen Type
  3617.  
  3618.     0                   1                   2                   3
  3619.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3620.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3621.    |1|0|0|0|       8               |               0               |
  3622.  
  3623.  
  3624.  
  3625. Valencia                 expires December 1997                  [Page 55]
  3626.  
  3627.  
  3628.  
  3629.  
  3630.  
  3631. INTERNET DRAFT                                                 June 1997
  3632.  
  3633.  
  3634.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3635.    |              29               |             Type              |
  3636.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3637.  
  3638.    The Attribute value is 29, Proxy Authen Type, and is marked
  3639.    mandatory.  This AVP MUST be present.  The value Type is a 16-bit
  3640.    word, holding a value:
  3641.  
  3642.       1 - Textual username/password exchange
  3643.       2 - PPP CHAP
  3644.       3 - PPP PAP
  3645.       4 - None
  3646.  
  3647.    Associated AVP's for each type of authentication follow.
  3648.  
  3649.    Proxy Authen Name
  3650.  
  3651.     0                   1                   2                   3
  3652.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3653.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3654.    |0|0|0|0|    6 + Name length    |               0               |
  3655.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3656.    |              30               |     Name...
  3657.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3658.  
  3659.    The Attribute value is 30, Proxy Authen Name, and is marked
  3660.    mandatory.  This AVP MUST be present for Proxy Authen Type values 1,
  3661.    2, and 3.  The Name field contains the name specified in the client's
  3662.    authentication response.  Note that the AVP H bit may be desirable
  3663.    for obscuring the cleartext name.
  3664.  
  3665.    Proxy Authen Challenge
  3666.  
  3667.     0                   1                   2                   3
  3668.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3669.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3670.    |0|0|0|0| 6 + Challenge length  |               0               |
  3671.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3672.    |              31               | Challenge...
  3673.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3674.  
  3675.    The Attribute value is 31, Proxy Authen Challenge, and is marked
  3676.    mandatory.  The AVP itself MUST be present for Proxy authen type 2.
  3677.    The Challenge field contains the value presented to the client by the
  3678.    LAC.
  3679.  
  3680.    Proxy Authen ID
  3681.  
  3682.     0                   1                   2                   3
  3683.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3684.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3685.    |0|0|0|0|           8           |               0               |
  3686.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3687.    |              32               |              ID               |
  3688.  
  3689.  
  3690.  
  3691. Valencia                 expires December 1997                  [Page 56]
  3692.  
  3693.  
  3694.  
  3695.  
  3696.  
  3697. INTERNET DRAFT                                                 June 1997
  3698.  
  3699.  
  3700.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3701.  
  3702.    The Attribute value is 32, Proxy Authen ID, and is marked mandatory.
  3703.    The AVP itself MUST be present for Proxy authen types 2 and 3.  For
  3704.    CHAP, the ID field contains the byte ID value presented to the client
  3705.    by the LAC in its Challenge.  For PAP, it is the Identifier value of
  3706.    the Authenticate-Request.  The most significant 8 bits of ID MUST be
  3707.    0, and are reserved.
  3708.  
  3709.    Proxy Authen Response
  3710.  
  3711.     0                   1                   2                   3
  3712.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3713.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3714.    |1|0|0|0|  6 + Response length  |               0                |
  3715.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3716.    |              33               | Response...
  3717.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3718.  
  3719.    The Attribute value is 33, Proxy Authen Response, and is marked
  3720.    mandatory.  The AVP itself MUST be present for Proxy authen types 1,
  3721.    2, and 3.  The Response field contains the client's response to the
  3722.    challenge.  For Proxy authen type 2, this field contains the response
  3723.    value received by the LAC.  For types 1 or 3, it contains the clear
  3724.    text password received from the client by the LAC.  In the case of
  3725.    cleartext passwords, use of the AVP H bit is recommended.
  3726.  
  3727. 6.13 Call-Clear-Request
  3728.  
  3729.    The Call-Clear-Request is an L2TP control message sent by the LNS to
  3730.    the LAC indicating that a particular call is to be disconnected.  The
  3731.    call being cleared can be either an incoming or outgoing call, in any
  3732.    state.  The LAC responds to this message with a Call-Disconnect-
  3733.    Notify message.
  3734.  
  3735.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3736.    |          L2TP Control Message Header        |
  3737.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3738.    |             Call-Clear-Request              |
  3739.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3740.    | Assigned Call ID      |
  3741.    +-+-+-+-+-+-+-+-+-+-+-+-+
  3742.  
  3743.    Call-Clear-Request
  3744.  
  3745.     0                   1                   2                   3
  3746.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3747.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3748.    |1|0|0|0|           8           |               0               |
  3749.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3750.    |               0               |              13               |
  3751.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3752.  
  3753.    The Message Type AVP contains a Value of 12, indicating Call-Clear-
  3754.  
  3755.  
  3756.  
  3757. Valencia                 expires December 1997                  [Page 57]
  3758.  
  3759.  
  3760.  
  3761.  
  3762.  
  3763. INTERNET DRAFT                                                 June 1997
  3764.  
  3765.  
  3766.    Request.  The Call-Clear-Request message encodes a request by the LNS
  3767.    to the LAC to disconnect the call.  The flags indicate a mandatory
  3768.    option.
  3769.  
  3770.    Assigned Call ID
  3771.  
  3772.     0                   1                   2                   3
  3773.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3774.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3775.    |1|0|0|0|           8           |               0               |
  3776.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3777.    |              14               |            Call ID            |
  3778.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3779.  
  3780.    This attribute is used to provide the LAC with the Call ID assigned
  3781.    by the LNS for the call to be cleared in the case where the LNS has
  3782.    not yet learned the LAC's Call ID for the call.  The Attribute value
  3783.    is 14, Assigned Call ID, and is marked mandatory.  This AVP MUST be
  3784.    present.  The value Call ID MUST be the same value sent from the LNS
  3785.    to the LAC in the initial call setup exchange.
  3786.  
  3787. 6.14 Call-Disconnect-Notify
  3788.  
  3789.    The Call-Disconnect-Notify message is an L2TP control message sent by
  3790.    the LAC to the LNS.  It is issued whenever a call is disconnected,
  3791.    due to the receipt by the LAC of a Call-Clear-Request or for any
  3792.    other reason.  Its purpose is to inform the LNS of the disconnection
  3793.    and the reason why the disconnection occurred.
  3794.  
  3795.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3796.    |          L2TP Control Message Header        |
  3797.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3798.    |             Call-Disconnect-Notify          |
  3799.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3800.    | Result Code             |
  3801.    | Q.931 Cause Code        |
  3802.    | Assigned Call ID        |
  3803.    +-+-+-+-+-+-+-+-+-+-+-+-+-+
  3804.  
  3805.    Call-Disconnect-Notify
  3806.  
  3807.     0                   1                   2                   3
  3808.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3809.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3810.    |1|0|0|0|           8           |               0               |
  3811.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3812.    |               0               |              14               |
  3813.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3814.  
  3815.    The Message Type AVP contains a Value of 13, indicating Call-
  3816.    Disconnect-Notify.  The Call-Disconnect-Notify message encodes a
  3817.    disconnect indication from the LAC to the LNS.  The flags indicate a
  3818.    mandatory option.
  3819.  
  3820.  
  3821.  
  3822.  
  3823. Valencia                 expires December 1997                  [Page 58]
  3824.  
  3825.  
  3826.  
  3827.  
  3828.  
  3829. INTERNET DRAFT                                                 June 1997
  3830.  
  3831.  
  3832.    Result Code
  3833.  
  3834.        0                   1                   2                   3
  3835.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3836.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3837.       |1|0|0|0|  10 + Message length  |               0               |
  3838.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3839.       |               1               |          Result Code          |
  3840.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3841.       |           Error Code          |      Optional Message ...
  3842.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3843.  
  3844.       The Result Code AVP within a Call-Disconnect-Notify message
  3845.       indicates the reason for the call disconnect.  It is encoded as
  3846.       Attribute 1, indicating a Result Code AVP.  This AVP is mandatory
  3847.       and MUST be present.  The Result Code is a 16-bit word.  The 16-
  3848.       bit word following the Result Code field contains the Error Code
  3849.       value.  The Result Code value indicates whether the Error Code
  3850.       value is meaningful or not.  If it is not meaningful it should be
  3851.       set to a value of 0.  An optional error message can follow the
  3852.       Error Code field.  Its presence and length is indicated by the
  3853.       value of the AVP length field.  Defined Result Code values are:
  3854.  
  3855.          1 (Lost Carrier) - Call disconnected due to loss of carrier
  3856.          2 (General Error) - Call disconnected for the reason indicated
  3857.             in Error Code.
  3858.          3 (Admin Shutdown) - Call disconnected for administrative
  3859.             reasons
  3860.          4 (Request) - Call disconnected due to received Call-Clear-
  3861.             Request
  3862.  
  3863.       Q.931 Cause Code
  3864.  
  3865.        0                   1                   2                   3
  3866.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3867.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3868.       |0|0|0|0|9 + Advisory Msg length|              0                |
  3869.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3870.       |              12               |          Cause Code           |
  3871.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3872.       |   Cause Msg   |Advisory Msg...
  3873.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3874.  
  3875.       The Q.931 Cause Code AVP is used to give additional information in
  3876.       case of unsolicited call disconnection.  The Attribute value is
  3877.       12, Cause Code, and is marked mandatory.  The presence of this AVP
  3878.       is optional.  The Cause Code AVP is used to give additional
  3879.       information about the reason for disconnecting.  It is only
  3880.       relevant when the LAC is using Q.931/DSS1 for the call.  This AVP
  3881.       is optional.  Cause  Code is the returned Q.931 Cause code and
  3882.       Cause Msg is the returned Q.931 message code (e.g., DISCONNECT)
  3883.       associated with the Cause Code.  Both values are returned in their
  3884.       native ITU encodings.  An additional Ascii text Advisory Message
  3885.       may also be included (presence indicated by the AVP length) to
  3886.  
  3887.  
  3888.  
  3889. Valencia                 expires December 1997                  [Page 59]
  3890.  
  3891.  
  3892.  
  3893.  
  3894.  
  3895. INTERNET DRAFT                                                 June 1997
  3896.  
  3897.  
  3898.       further explain the reason for disconnecting.
  3899.  
  3900.       Assigned Call ID
  3901.  
  3902.        0                   1                   2                   3
  3903.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3904.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3905.       |1|0|0|0|           8           |               0               |
  3906.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3907.       |              14               |            Call ID            |
  3908.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3909.  
  3910.       The Assigned Call ID which was provided to the LNS from this LAC
  3911.       is included in the Call-Disconnect-Notify message.  This permits a
  3912.       connection to be terminated even before the LNS has provided its
  3913.       own Assigned Call ID to this LAC (the Call ID field in the control
  3914.       message header is 0).  The Attribute value is 14, Assigned Call
  3915.       ID, and is marked mandatory.  This AVP MUST be present.
  3916.  
  3917. 6.15 WAN-Error-Notify
  3918.  
  3919.    The WAN-Error-Notify message is an L2TP control message sent by the
  3920.    LAC to the LNS to indicate WAN error conditions (conditions that
  3921.    occur on the interface supporting PPP).  The counters in this message
  3922.    are cumulative.  This message should only be sent when an error
  3923.    occurs, and not more than once every 60 seconds.  The counters are
  3924.    reset when a new call is established.
  3925.  
  3926.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3927.    |          L2TP Control Message Header        |
  3928.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3929.    |                   WAN-Error-Notify          |
  3930.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3931.    | Call Errors               |
  3932.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3933.  
  3934.    WAN-Error-Notify
  3935.  
  3936.     0                   1                   2                   3
  3937.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3938.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3939.    |1|0|0|0|           8           |               0               |
  3940.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3941.    |               0               |              15               |
  3942.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3943.  
  3944.    The Message Type AVP contains a Value of 14, indicating WAN-Error-
  3945.    Notify.  The WAN-Error-Notify message encodes information about line
  3946.    and other errors detected on the LAC's physical interface to the
  3947.    client. This message is sent by the LAC to the LNS.  The flags
  3948.    indicate a mandatory option.
  3949.  
  3950.    Call Errors
  3951.  
  3952.  
  3953.  
  3954.  
  3955. Valencia                 expires December 1997                  [Page 60]
  3956.  
  3957.  
  3958.  
  3959.  
  3960.  
  3961. INTERNET DRAFT                                                 June 1997
  3962.  
  3963.  
  3964.     0                   1                   2                   3
  3965.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  3966.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3967.    |1|0|0|0|          32           |               0               |
  3968.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3969.    |              34               |           Reserved            |
  3970.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3971.    |                           CRC Errors                          |
  3972.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3973.    |                        Framing Errors                         |
  3974.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3975.    |                       Hardware Overruns                       |
  3976.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3977.    |                        Buffer Overruns                        |
  3978.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3979.    |                        Time-out Errors                        |
  3980.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3981.    |                       Alignment Errors                        |
  3982.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3983.  
  3984.    The Call Errors AVP is used by the LAC to send error information to
  3985.    the LNS.  The Attribute value is 34, WAN-Error-Notify, and is marked
  3986.    mandatory.  This AVP MUST be present.  The value contains the
  3987.    following fields:
  3988.  
  3989.       Reserved - Not used, MUST be 0
  3990.       CRC Errors - Number of PPP frames received with CRC errors since
  3991.          session was established
  3992.       Framing Errors - Number of improperly framed PPP packets received
  3993.       Hardware Overruns - Number of receive buffer over-runs since
  3994.          session was established
  3995.       Buffer Overruns - Number of buffer over-runs detected since
  3996.          session was established
  3997.       Time-out Errors - Number of time-outs since call was established
  3998.       Alignment Errors - Number of alignment errors since call was
  3999.          established
  4000.  
  4001. 6.16 Set-Link-Info
  4002.  
  4003.    The Set-Link-Info message is an L2TP control message sent by the LNS
  4004.    to the LAC to set PPP-negotiated options.  Because these options can
  4005.    change at any time during the life of the call, the LAC MUST be able
  4006.    to update its internal call information dynamically and update its
  4007.    behavior on an active PPP session.
  4008.  
  4009.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4010.    |          L2TP Control Message Header        |
  4011.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4012.    |                   Set-Link-Info             |
  4013.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4014.    | ACCM                    |
  4015.    +-+-+-+-+-+-+-+-+-+-+-+-+-+
  4016.  
  4017.    Set-Link-Info
  4018.  
  4019.  
  4020.  
  4021. Valencia                 expires December 1997                  [Page 61]
  4022.  
  4023.  
  4024.  
  4025.  
  4026.  
  4027. INTERNET DRAFT                                                 June 1997
  4028.  
  4029.  
  4030.     0                   1                   2                   3
  4031.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  4032.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4033.    |1|0|0|0|           8           |               0               |
  4034.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4035.    |               0               |              16               |
  4036.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4037.  
  4038.    The Message Type AVP contains a Value of 15, indicating Set-Link-
  4039.    Info.  The Set-Link-Info message encodes ACCM information sent from
  4040.    the LNS to the LAC after it is negotiated in LCP.  The flags indicate
  4041.    a mandatory option.
  4042.  
  4043.    ACCM
  4044.  
  4045.     0                   1                   2                   3
  4046.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  4047.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4048.    |1|0|0|0|          32           |               0               |
  4049.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4050.    |              35               |          Reserved             |
  4051.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4052.    |                           Send ACCM                           |
  4053.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4054.    |                          Receive ACCM                         |
  4055.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4056.  
  4057.    The ACCM AVP is used by the LNS to inform LAC of the ACCM to the LNS.
  4058.    The Attribute value is 35, ACCM, and is marked mandatory.  This
  4059.    attribute MUST be present.  The value contains Send ACCM and Receive
  4060.    ACCM fields.  The send ACCM value should be used by the LAC to
  4061.    process packets it is sends on the connection.  The receive ACCM
  4062.    value should be used by the LAC to process incoming packets on the
  4063.    connection.  The default values used by the LAC for both these fields
  4064.    are 0xFFFFFFFF.  The LAC should honor these fields unless it has
  4065.    specific configuration information to indicate that the requested
  4066.    mask must be modified to permit operation.
  4067.  
  4068. 7.0 Control Connection State Machines
  4069.  
  4070. The control messages defined in section 6 are exchanged by way of state
  4071. tables defined in this section.  Tables are defined for incoming call
  4072. placement, outgoing call placement, as well as for initiation of the
  4073. tunnel itself.  The state tables do not encode timeout and
  4074. retransmission behavior, as this is handled in the underlying semantics
  4075. defined in 6.0.2.
  4076.  
  4077. 7.1 Control Connection Protocol Operation
  4078.  
  4079.    This section describes the operation of various L2TP control
  4080.    connection functions and the Control Connection messages which are
  4081.    used to support them.
  4082.  
  4083.    Receipt of an invalid or malformed Control Connection message should
  4084.  
  4085.  
  4086.  
  4087. Valencia                 expires December 1997                  [Page 62]
  4088.  
  4089.  
  4090.  
  4091.  
  4092.  
  4093. INTERNET DRAFT                                                 June 1997
  4094.  
  4095.  
  4096.    be logged appropriately, and the control connection should be closed
  4097.    and restarted to ensure recovery into a known state.
  4098.  
  4099. 7.2 Control Connection States
  4100.  
  4101.    Control messages are carried over the same media as the payload
  4102.    messages which are carried following successful connection
  4103.    establishment.  The L2TP control connection protocol is not
  4104.    distinguishable between the LNS and LAC, but is distinguishable
  4105.    between the originator and receiver.  The originating peer is the one
  4106.    which first establishes the tunnel.  Since either LAC or LNS can be
  4107.    the originator, a collision can occur.  See Section 6.0.1 for a
  4108.    description of this and its resolution situation.
  4109.  
  4110. 7.2.1 Control Connection Originator
  4111.  
  4112.    State           Event             Action               New State
  4113.    -----           -----             ------               ---------
  4114.  
  4115.    idle            Open request      Send                 wait-ctl-reply
  4116.                                      Start-Control-
  4117.                                      Connection-Request
  4118.  
  4119.    wait-ctl-reply  Collision         If terminating,      idle
  4120.                                      clean-up.
  4121.  
  4122.    wait-ctl-reply  Collision         If not terminating,  wait-stop-reply
  4123.                                      Send Stop-Control-
  4124.                                      Connection-Request
  4125.  
  4126.    wait-ctl-reply  Receive           If version OK        established
  4127.                    Start-Control-    Send Start-Control-
  4128.                    Connection-Reply  Connection-Connected
  4129.  
  4130.    wait-ctl-reply  Receive           If version not OK    wait-stop-reply
  4131.                    Start-Control-    or bad auth, Send
  4132.                    Connection-Reply  Stop-Control-
  4133.                                      Connection-Request
  4134.  
  4135.    established     Local terminate   Send                 wait-stop-reply
  4136.                                      Stop-Control-
  4137.                                      Connection-Request
  4138.  
  4139.    established     Receive           Acknowledge via      idle
  4140.                    Stop-Control-     reliable transport
  4141.                    Connection-
  4142.                    Request
  4143.  
  4144.    wait-stop-reply Receive           Clean-up             idle
  4145.                    Acknowledgement
  4146.                    via reliable
  4147.                    transport
  4148.  
  4149.    idle
  4150.  
  4151.  
  4152.  
  4153. Valencia                 expires December 1997                  [Page 63]
  4154.  
  4155.  
  4156.  
  4157.  
  4158.  
  4159. INTERNET DRAFT                                                 June 1997
  4160.  
  4161.  
  4162.       The control connection originator attempts to open a connection to
  4163.       the peer during idle state.  When the connection is open, the
  4164.       originator transmits a send Start-Control-Connection-Request and
  4165.       then enters the wait-ctl-reply state.
  4166.  
  4167.    wait-ctl-reply
  4168.       The originator checks to see if another connection has been
  4169.       requested from the same peer, and if so, handles the collision
  4170.       situation described in Section 6.0.1.
  4171.  
  4172.       When a Start-Control-Connection-Reply is received, it is examined
  4173.       for a compatible version.  If the version of the reply is lower
  4174.       than the version sent in the request, the older (lower) version
  4175.       should be used provided it is supported.  If the version in the
  4176.       reply is earlier and supported, the originator moves to the
  4177.       established state.  If the version is earlier and not supported, a
  4178.       Stop-Control-Connection-Request SHOULD be sent to the peer and the
  4179.       originator moves into the wait-stop-reply state.
  4180.  
  4181.    established
  4182.       An established connection may be terminated by either a local
  4183.       condition or the receipt of a Stop-Control-Connection-Request.  In
  4184.       the event of a local termination, the originator MUST send a
  4185.       Stop-Control-Connection-Request and enter the wait-stop-reply
  4186.       state.
  4187.  
  4188.       If the originator receives a Stop-Control-Connection-Request it
  4189.       MUST run its reliable delivery mechanism to acknowledge the stop
  4190.       request (see 6.0.2) before destroying the tunnel.
  4191.  
  4192.    wait-stop-reply
  4193.       Once the reliable transport has verified that the peer has
  4194.       received the stop request, the tunnel may be cleared.
  4195.  
  4196. 7.2.2 Control connection Receiver
  4197.  
  4198.    State           Event              Action                 New State
  4199.    -----           -----              ------                 ---------
  4200.    idle            Receive            If version not OK      idle
  4201.                    Start-Control-     send
  4202.                    Connection-Request Start-Control-
  4203.                                       Connection-Reply
  4204.                                       with error
  4205.  
  4206.    idle            Receive            Version OK, send       wait-ctl-reply
  4207.                    Start-Control-     Start-Control-
  4208.                    Connection-Request Connection-Reply
  4209.  
  4210.    wait-ctl-reply  Receive            Clean-up, send         idle
  4211.                    Stop-Control-      Stop-Control-
  4212.                    Connection-Request Connection-Reply
  4213.  
  4214.    wait-ctl-reply  Receive            If auth OK             established
  4215.                    Start-Control-
  4216.  
  4217.  
  4218.  
  4219. Valencia                 expires December 1997                  [Page 64]
  4220.  
  4221.  
  4222.  
  4223.  
  4224.  
  4225. INTERNET DRAFT                                                 June 1997
  4226.  
  4227.  
  4228.                    Connection-Connected
  4229.  
  4230.    wait-ctl-reply  Receive            If auth not OK         wait-stop-reply
  4231.                    Start-Control-     Send Stop-Control-
  4232.                    Connection-        Connection-Request
  4233.                    Connected
  4234.  
  4235.    established     Receive           Acknowledge via         idle
  4236.                    Stop-Control-     reliable transport
  4237.                    Connection-
  4238.                    Request
  4239.  
  4240.    established     Local terminate    Send                   wait-stop-reply
  4241.                                       Stop-Control-
  4242.                                       Connection-Request
  4243.  
  4244.    wait-stop-reply Receive            Clean-up               idle
  4245.                    Acknowledgement
  4246.                    via reliable
  4247.                    transport
  4248.  
  4249.    idle
  4250.       The control connection receiver waits for an incoming connection
  4251.       attempt.  When notified of a new connection, it should prepare to
  4252.       receive L2TP messages.  When a Start-Control-Connection-Request is
  4253.       received its version field MUST be examined.  If the version is
  4254.       earlier than the receiver's version and the earlier version can be
  4255.       supported by the receiver, the receiver SHOULD send a Start-
  4256.       Control-Connection-Reply.
  4257.  
  4258.       If the version is earlier than the receiver's version and the
  4259.       version cannot be supported, the receiver SHOULD send a Start-
  4260.       Connection-Reply message indicating this error and remain in the
  4261.       idle state.  If the receiver's version is the same as or earlier
  4262.       than the peer's, the receiver SHOULD send a Start-Control-
  4263.       Connection-Reply with the receiver's version and enter the wait-
  4264.       ctl-reply state.
  4265.  
  4266.    wait-ctl-reply
  4267.  
  4268.       The peer waits in this state after sending a Start-Control-
  4269.       Connection-Reply.  If it receives a Start-Control-Connection-
  4270.       Reply, it checks to see if the message is properly authenticated
  4271.       and, if so, it enters the established state.  If authentication
  4272.       fails, a Stop-Control-Connection-Request with the reason code set
  4273.       appropriately is sent and wait-stop-reply state is entered.  if a
  4274.       Stop-Control-Connection-Request is received, a Stop-Control-
  4275.       Connection-Reply is issued and idle state is entered.
  4276.  
  4277.    established
  4278.       An established connection may be terminated by either a local
  4279.       condition or the reception of a Stop-Control-Connection-Request.
  4280.       In the event of a local termination, the originator MUST send a
  4281.       Stop-Control-Connection-Request and enter the wait-stop-reply
  4282.  
  4283.  
  4284.  
  4285. Valencia                 expires December 1997                  [Page 65]
  4286.  
  4287.  
  4288.  
  4289.  
  4290.  
  4291. INTERNET DRAFT                                                 June 1997
  4292.  
  4293.  
  4294.       state.
  4295.  
  4296.       If the originator receives a Stop-Control-Connection-Request it
  4297.       MUST run its reliable delivery mechanism to acknowledge the stop
  4298.       request (see 6.0.2) before destroying the tunnel.
  4299.  
  4300.    wait-stop-reply
  4301.       Once the reliable transport has verified that the peer has
  4302.       received the stop request, the tunnel may be cleared.
  4303.  
  4304. 7.3 Timing considerations
  4305.  
  4306.    Because of the real-time nature of telephone signaling, both the LNS
  4307.    and LAC should be implemented with multi-threaded architectures such
  4308.    that messages related to multiple calls are not serialized and
  4309.    blocked.  The call and connection state figures do not specify
  4310.    exceptions caused by timers.  These are addressed in Section 6.0.2.
  4311.  
  4312. 7.4 Incoming calls
  4313.  
  4314. An Incoming-Call-Request message is generated by the LAC when an
  4315. associated telephone line rings.  The LAC selects a Call ID and serial
  4316. number and indicates the call bearer type.  Modems should always
  4317. indicate analog call type.  ISDN calls should indicate digital when
  4318. unrestricted digital service or rate adaption is used and analog if
  4319. digital modems are involved.  CLID, DNIS, and subaddress may be included
  4320. in the message if they are available from the telephone network.
  4321.  
  4322. Once the LAC sends the Incoming-Call-Request, it waits for a response
  4323. from the LNS but it does not necessarily answer the call from the
  4324. telephone network yet.  The LNS may choose not to accept the call if:
  4325.  
  4326.    -  No resources are available to handle more sessions
  4327.    -  The dialed, dialing, or subaddress fields are not indicative of an
  4328.       authorized user
  4329.    -  The bearer service is not authorized or supported
  4330.  
  4331. If the LNS chooses to accept the call, it responds with an Incoming-
  4332. Call-Reply which also indicates window sizes (see Appendix B).  When the
  4333. LAC receives the Incoming-Call-Reply, it attempts to connect the call,
  4334. assuming the calling party has not hung up.  A final call connected
  4335. message from the LAC to the LNS indicates that the call states for both
  4336. the LAC and the LNS should enter the established state.
  4337.  
  4338. When the dialed-in client hangs up, the call is cleared normally and the
  4339. LAC sends a Call-Disconnect-Notify message.  If the LNS wishes to clear
  4340. a call, it sends a Call-Clear-Request message and then waits for a
  4341. Call-Disconnect-Notify.
  4342.  
  4343. 7.4.1 LAC Incoming Call States
  4344.  
  4345.    State       Event               Action                   New State
  4346.    -----       -----               ------                   ---------
  4347.    idle        Ring OR             Send                     wait-reply
  4348.  
  4349.  
  4350.  
  4351. Valencia                 expires December 1997                  [Page 66]
  4352.  
  4353.  
  4354.  
  4355.  
  4356.  
  4357. INTERNET DRAFT                                                 June 1997
  4358.  
  4359.  
  4360.                Ready to indicate   Incoming-Call-Request
  4361.                incoming conn.
  4362.  
  4363.    wait-reply  Receive             Clean-up                 idle
  4364.                Incoming-Call-Reply
  4365.                Not Accepting
  4366.  
  4367.    wait-reply  Receive             Answer call              established
  4368.                Incoming-Call-Reply Send
  4369.                Accepting           Incoming-Call-Connected
  4370.  
  4371.    wait-reply  Abort               Clean-up                 idle
  4372.                                    Send Call-Disconnect-
  4373.                                    Notify
  4374.  
  4375.    established Receive             Hang-up and send         idle
  4376.                Call-Clear-Request  Call-Disconnect-Notify
  4377.  
  4378.    established telco line drop     Send                     idle
  4379.                                    Call-Disconnect-Notify
  4380.  
  4381.    established local disconnect    Send                     idle
  4382.                                    Call-Disconnect-Notify
  4383.  
  4384. The states associated with the LAC for incoming calls are:
  4385.  
  4386. idle
  4387.  
  4388.    The LAC detects an incoming call on one of its telco interfaces.
  4389.    Typically this means an analog line is ringing or an ISDN TE has
  4390.    detected an incoming Q.931 SETUP message.  The LAC sends an
  4391.    Incoming-Call-Request message and moves to the wait-reply state.
  4392.  
  4393. wait-reply
  4394.  
  4395.    The LAC receives an Incoming-Call-Reply message indicating non-
  4396.    willingness to accept the call (general error or don't accept) and
  4397.    moves back into the idle state.  If the reply message indicates that
  4398.    the call is accepted, the LAC sends an Incoming-Call-Connected
  4399.    message and enters the established state.
  4400.  
  4401. established
  4402.  
  4403.    Data is exchanged over the tunnel.  The call may be cleared
  4404.    following:
  4405.       An event on the telco connection.  The LAC sends a Call-
  4406.          Disconnect-Notify message
  4407.       Receipt of a Call-Clear-Request.  The LAC sends a Call-
  4408.          Disconnect-Notify message
  4409.       A local reason.  The LAC sends a Call-Disconnect-Notify message.
  4410.  
  4411.  
  4412. 7.4.2 LNS Incoming Call States
  4413.  
  4414.  
  4415.  
  4416.  
  4417. Valencia                 expires December 1997                  [Page 67]
  4418.  
  4419.  
  4420.  
  4421.  
  4422.  
  4423. INTERNET DRAFT                                                 June 1997
  4424.  
  4425.  
  4426.    State        Event                  Action                New State
  4427.    -----        -----                  ------                ---------
  4428.    idle         Receive                If not accepting      idle
  4429.                 Incoming-Call-Request  Send
  4430.                                        Incoming-Call-Reply
  4431.                                        with Error
  4432.  
  4433.    idle         Receive                If accepting          wait-connect
  4434.                 Incoming-Call-Request  Send
  4435.                                        Incoming-Call-Reply
  4436.  
  4437.    wait-connect Receive                Clean-up              idle
  4438.                 Call-Disconnect-Notify
  4439.  
  4440.    wait-connect Receive                Get ready for data    established
  4441.                 Incoming-Call-Connect
  4442.  
  4443.    established  Receive                Clean-up              idle
  4444.                 Call-Disconnect-Notify
  4445.  
  4446.    established  Local terminate        Send                  wait-
  4447.                                        Call-Clear-Request    disconnect
  4448.  
  4449.    wait-        Receive                Clean-up              idle
  4450.    disconnect   Call-Disconnect-Notify
  4451.  
  4452.    The states associated with the LNS for incoming calls are:
  4453.  
  4454.    idle
  4455.  
  4456.       An Incoming-Call-Request message is received.  If the request is
  4457.       not acceptable, an Incoming-Call-Reply is sent back to the LAC and
  4458.       the LNS remains in the idle state.  If the Incoming-Call-Request
  4459.       message is acceptable, an Incoming-Call-Reply is sent indicating
  4460.       accept in the result code.  The session moves to the wait-connect
  4461.       state.
  4462.  
  4463.    wait-connect
  4464.  
  4465.       If the session is still connected on the LAC, the LAC sends an
  4466.       incoming call connect message to the LNS which then moves into
  4467.       established state.  The LAC may send a Call-Disconnect-Notify to
  4468.       indicate that the incoming caller could not be connected.  This
  4469.       could happen, for example, if a telephone user accidentally places
  4470.       a standard voice call to an LAC resulting in a handshake failure
  4471.       on the called modem.
  4472.  
  4473.    established
  4474.  
  4475.       The session is terminated either by receipt of a Call-Disconnect-
  4476.       Notify message from the LAC or by sending a Call-Clear-Request.
  4477.       Once a Call-Clear-Request has been sent, the session enters the
  4478.       wait-disconnect state.
  4479.  
  4480.  
  4481.  
  4482.  
  4483. Valencia                 expires December 1997                  [Page 68]
  4484.  
  4485.  
  4486.  
  4487.  
  4488.  
  4489. INTERNET DRAFT                                                 June 1997
  4490.  
  4491.  
  4492.    wait-disconnect
  4493.  
  4494.       Once a Call-Disconnect-Notify is received the session moves back
  4495.       to the idle state.
  4496.  
  4497. 7.5 Outgoing calls
  4498.  
  4499. Outgoing calls are initiated by an LNS and instruct an LAC to place a
  4500. call on a telco interface.  There are three messages for outgoing calls:
  4501. Outgoing-Call-Request, Outgoing-Call-Reply, and Outgoing-Call-Connected.
  4502. The LNS sends an Outgoing-Call-Request specifying the dialed party phone
  4503. number and subaddress as well as speed and window parameters.  The LAC
  4504. MUST respond to the Outgoing-Call-Request message with an Outgoing-
  4505. Call-Reply message once the LAC determines that the proper facilities
  4506. exist to place the call and the call is administratively authorized.
  4507. For example, is this LNS allowed to dial an international call?  Once
  4508. the outbound call is connected the LAC sends an Outgoing-Call-Connected
  4509. message to the LNS indicating the final result of the call attempt:
  4510.  
  4511. 7.5.1 LAC Outgoing Call States
  4512.  
  4513.    State       Event              Action                        New State
  4514.    -----       -----              ------                        ---------
  4515.    idle        Receive            If cannot service,            idle
  4516.                Outgoing-Call-     send Outgoing-Call-Reply
  4517.                Request            with Error
  4518.  
  4519.    idle        Receive            If can service,               wait-cs-ans
  4520.                Outgoing-Call-     send
  4521.                Request            Outgoing-Call-Reply
  4522.  
  4523.    wait-cs-ans Telco answer       Send                          established
  4524.                and framing        Outgoing-Call-Connected
  4525.                detected
  4526.  
  4527.    wait-cs-ans Call failure       Send
  4528.                                   Outgoing-Call-Connected       idle
  4529.                                   with Error
  4530.  
  4531.    wait-cs-ans Receive            Hang-up, send                 idle
  4532.                Call-Clear-Request Call-Disconnect-Notify
  4533.  
  4534.    established Receive            Hang-up, send                 idle
  4535.                Call-Clear-Request Call-Disconnect-Notify
  4536.                or detect call
  4537.                disconnected
  4538.  
  4539.    The states associated with the LAC for outgoing calls are:
  4540.  
  4541.    idle
  4542.  
  4543.       Received Outgoing-Call-Request.  If this is received in error,
  4544.       respond with an Outgoing-Call-Reply with error condition set.
  4545.       Otherwise, allocate physical channel to dial on and send an
  4546.  
  4547.  
  4548.  
  4549. Valencia                 expires December 1997                  [Page 69]
  4550.  
  4551.  
  4552.  
  4553.  
  4554.  
  4555. INTERNET DRAFT                                                 June 1997
  4556.  
  4557.  
  4558.       Outgoing-Call-Reply.  Place the outbound call and move to the
  4559.       wait-cs-ans state.
  4560.  
  4561.    wait-cs-ans
  4562.  
  4563.       If the call is not completed or a timer expires waiting for the
  4564.       call to complete, send an Outgoing-Call-Connected with the
  4565.       appropriate error condition set and go to idle state.  If a
  4566.       circuit switched connection is established and framing is
  4567.       detected, send an Outgoing-Call-Connected indicating success and
  4568.       go to established state.
  4569.  
  4570.    established
  4571.  
  4572.       If a Call-Clear-Request is received, the telco call SHOULD be
  4573.       released via appropriate mechanisms and a Call-Disconnect-Notify
  4574.       message SHOULD BE sent to the LNS.  If the call is disconnected by
  4575.       the client or by the telco interface, a Call-Disconnect-Notify
  4576.       message MUST be sent to the LNS.  Return to idle state after
  4577.       sending the Call-Disconnect-Notify.
  4578.  
  4579. 7.5.2 LNS Outgoing Call States
  4580.  
  4581.    State         Event                  Action                  New State
  4582.    -----         -----                  ------                  ---------
  4583.    idle          Open request           Send                    wait-reply
  4584.                                         Outgoing-Call-Request
  4585.  
  4586.    wait-reply    Receive                Clean-up                idle
  4587.                  Outgoing-Call-Reply
  4588.                  with Error
  4589.  
  4590.    wait-reply    Receive                Null                    wait-connect
  4591.                  Outgoing-Call-Reply
  4592.  
  4593.    wait-reply    Abort request          Send                    wait-disconnect
  4594.                                         Call-Clear-Request
  4595.  
  4596.    wait-connect  Abort request          Send
  4597.                                         Call-Clear-Request      wait-disconnect
  4598.  
  4599.    wait-connect  Receive                Get ready for data      established
  4600.                  Outgoing-Call-Connected
  4601.                  no Error
  4602.  
  4603.    wait-connect  Receive                Clean-up                idle
  4604.                  Outgoing-Call-Connected
  4605.                  with Error
  4606.  
  4607.    established   Receive                Clean-up                idle
  4608.                  Call-Disconnect-Notify
  4609.  
  4610.    established   Local terminate        Send                    wait-disconnect
  4611.                                         Call-Clear-Request
  4612.  
  4613.  
  4614.  
  4615. Valencia                 expires December 1997                  [Page 70]
  4616.  
  4617.  
  4618.  
  4619.  
  4620.  
  4621. INTERNET DRAFT                                                 June 1997
  4622.  
  4623.  
  4624.    wait-disconnect Receive              Clean-up                idle
  4625.                  Call-Disconnect-
  4626.                  Notify
  4627.  
  4628.    The states associated with the LNS for outgoing calls are:
  4629.  
  4630.    idle
  4631.       An Outgoing-Call-Request message is sent to the LAC and the
  4632.       session moves into the wait-reply state.
  4633.  
  4634.    wait-reply
  4635.       An Outgoing-Call-Reply is received which indicates an error.  The
  4636.       session returns to idle state.  If the Outgoing-Call-Reply does
  4637.       not indicate an error, the telco call is in progress and the
  4638.       session moves to the wait-connect state.
  4639.  
  4640.    wait-connect
  4641.       An Outgoing-Call-Connected is received which indicates an error.
  4642.       The session returns to idle state.  No telco call is active.  If
  4643.       the Outgoing-Call-Connected does not indicate an error, the telco
  4644.       call is
  4645.  
  4646.    established
  4647.       If a Call-Disconnect-Notify is received, the telco call has been
  4648.       terminated for the reason indicated in the Result and Cause Codes.
  4649.       The session moves back to the idle state.  If the LNS chooses to
  4650.       terminate the session, it sends a Call-Clear-Request to the LAC
  4651.       and then enters the wait-disconnect state.
  4652.  
  4653.    wait-disconnect
  4654.       A session disconnection is waiting to be confirmed by the LAC.
  4655.       Once the LNS receives the Call-Disconnect-Notify message, the
  4656.       session enters idle state.
  4657.  
  4658. 8.0 L2TP Over Specific Media
  4659.  
  4660.    L2TP tries to be self-describing, operating at a level above the
  4661.    particular media over which it is carried.  However, some details of
  4662.    its connection to media are required to permit interoperable
  4663.    implementations.  The following sections describe details needed to
  4664.    permit interoperability over specific media.
  4665.  
  4666. 8.1 IP/UDP
  4667.  
  4668.    L2TP uses the well-known UDP port 1701 [3].  The entire L2TP packet,
  4669.    including payload and L2TP header, is sent within a UDP datagram.
  4670.    The initiator of an L2TP tunnel picks an available source UDP port,
  4671.    and sends to the desired destination at port 1701.  The recipient
  4672.    picks a free port on its own system, and sends its reply to the
  4673.    initiator's UDP port, setting its own UDP source port set to the free
  4674.    port it found.  All subsequent packets exchanged will use these UDP
  4675.    ports.  It is legal for a peer's IP address used for a given tunnel
  4676.    to change over the life of a connection; this may correspond to a
  4677.    peer with multiple IP interfaces responding to a network topology
  4678.  
  4679.  
  4680.  
  4681. Valencia                 expires December 1997                  [Page 71]
  4682.  
  4683.  
  4684.  
  4685.  
  4686.  
  4687. INTERNET DRAFT                                                 June 1997
  4688.  
  4689.  
  4690.    change.  Responses should reflect the last source IP address for that
  4691.    Tunnel ID.
  4692.  
  4693.    IP fragmentation may occur as the L2TP packet travels over the IP
  4694.    substrate.  L2TP makes no special efforts to optimize this.  A LAC
  4695.    implementation MAY cause its LCP to negotiate for a specific MRU,
  4696.    which could optimize for LAC environments in which the MTUs of the
  4697.    path over which the L2TP packets are likely to travel have a
  4698.    consistent value.
  4699.  
  4700.    When operating over UDP, both the I and C bits MUST be present, and
  4701.    are used to permit correct demultiplexing and tunnel identification.
  4702.  
  4703.    The default for any L2TP implementation is that UDP checksums MUST be
  4704.    enabled for both control and payload messages.  An L2TP
  4705.    implementation MAY provide an option to disable UDP checksums for
  4706.    payload packets.  It is recommended that UDP checksums always be
  4707.    enabled on control packets.
  4708.  
  4709.    Port 1701 is used for both L2F [5] and L2TP packets.  The two types
  4710.    of packets may be detected by their headers; L2TP has a Vers field of
  4711.    2, L2F has a 1 in this field instead.  An L2TP implementation running
  4712.    on a system which does not support L2F MUST silently discard all
  4713.    packets whose Vers field is set to 1.
  4714.  
  4715. 8.2 IP
  4716.  
  4717.    When operating in IP environments, L2TP MUST use the UDP
  4718.    encapsulation described in 8.1.
  4719.  
  4720. 9.0 Security Considerations
  4721.  
  4722.    L2TP encounters several security issues in its operation.  The
  4723.    general approach of L2TP to these issues is documented here.
  4724.  
  4725.    9.1 Tunnel Endpoint Security
  4726.  
  4727.       The tunnel endpoints may authenticate each other during tunnel
  4728.       establishment.  This authentication has the same security
  4729.       attributes as CHAP, and has reasonable protection against reply
  4730.       and snooping.
  4731.  
  4732.       For L2TP tunnels over IP, IP-level packet security provides very
  4733.       strong protection of the tunnel.  This requires no modification to
  4734.       the L2TP protocol, and leverages extensive IETF work in this area.
  4735.  
  4736.       For L2TP tunnels over Frame Relay or other switched networks,
  4737.       current practice indicates that these media are much less likely
  4738.       to experience attacks of in-transit data.  If these attacks became
  4739.       prevalent, either the media or the L2TP packets would have to be
  4740.       encrypted.
  4741.  
  4742.    9.2 Client Security
  4743.  
  4744.  
  4745.  
  4746.  
  4747. Valencia                 expires December 1997                  [Page 72]
  4748.  
  4749.  
  4750.  
  4751.  
  4752.  
  4753. INTERNET DRAFT                                                 June 1997
  4754.  
  4755.  
  4756.       A more systematic method of protection in tunneled PPP
  4757.       environments may be achieved through client security.  PPP layer
  4758.       encryption would provide end-to-end security for both direct
  4759.       dial-in clients as well as PPP clients carried within a tunnel.
  4760.       With this level of client security, sessions are protected against
  4761.       attacks against the carrying tunnel, as well as attacks on the LAC
  4762.       itself.  Because both encryption and compression can occur at the
  4763.       PPP layer, the two can be coordinated, permitting compression to
  4764.       precede encryption.
  4765.  
  4766.    9.3 Proxy Authentication
  4767.  
  4768.       The optional proxy CHAP function of L2TP can permit an entirely
  4769.       transparent PPP tunnel, with a single LCP and CHAP sequence being
  4770.       seen by the client.  For cases where the LAC and the entire path
  4771.       to the LNS are operated by a single entity, this function may
  4772.       provide acceptable security.  For cases where LNS-initiated
  4773.       authentication is required, proxy CHAP still permits an initial
  4774.       access decision to be made before accepting the tunnel, permitting
  4775.       the LNS in most cases to reject tunnel initiations rather than
  4776.       accept them and later disconnect.
  4777.  
  4778.       The optional proxy PAP may result in the cleartext password
  4779.       traversing the tunnel.  Where PAP is being used in conjunction
  4780.       with static passwords, this may pose a significant security issue.
  4781.       Where PAP is only used to transport one-time passwords, such
  4782.       issues may be greatly mitigated.  The H bit of the carrying AVP
  4783.       may be used to protect against this.
  4784.  
  4785. 10.0 Acknowledgments
  4786.  
  4787.    The AVP construct comes from Glen Zorn, who thought up the framework
  4788.    for permitting multiple vendors to contribute to a common attribute
  4789.    space in a relatively orderly fashion.
  4790.  
  4791.    Dory Leifer and Allan Rubens of Ascend Communications made valuable
  4792.    refinements to the protocol definition of L2TP and contributed to the
  4793.    editing of this document.
  4794.  
  4795. 11.0 Contacts
  4796.  
  4797.    Kory Hamzeh
  4798.    Ascend Communications
  4799.    1275 Harbor Bay Parkway
  4800.    Alameda, CA 94502
  4801.    kory@ascend.com
  4802.  
  4803.    Tim Kolar, Morgan Littlewood, Andrew J. Valencia
  4804.    Cisco Systems
  4805.    170 West Tasman Drive
  4806.    San Jose CA 95134-1706
  4807.    tkolar@cisco.com
  4808.    littlewo@cisco.com
  4809.    vandys@cisco.com
  4810.  
  4811.  
  4812.  
  4813. Valencia                 expires December 1997                  [Page 73]
  4814.  
  4815.  
  4816.  
  4817.  
  4818.  
  4819. INTERNET DRAFT                                                 June 1997
  4820.  
  4821.  
  4822.    Gurdeep Singh Pall
  4823.    Microsoft Corporation
  4824.    Redmond, WA
  4825.    gurdeep@microsoft.com
  4826.  
  4827.    Jeff Taarud
  4828.    Copper Mountain Networks
  4829.    jtaarud@coppermountain.com
  4830.  
  4831.    William Verthein
  4832.    U.S. Robotics
  4833.  
  4834. 12.0 References
  4835.  
  4836.  
  4837.    [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661,
  4838.       07/21/1994
  4839.  
  4840.    [2] A. Valencia, M. Littlewood, T. Kolar, "Layer 2 Forwarding", Internet
  4841.       draft, April 1996
  4842.  
  4843.    [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, "Point-to-Point
  4844.       Tunneling Protocol", Internet draft, June 1996
  4845.  
  4846.    [4] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC1034,
  4847.       November 1987
  4848.  
  4849.    [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
  4850.       USC/Information Sciences Institute, July 1992.
  4851.  
  4852.    [6] Sally Floyd, Van Jacobson, "Random Early Detection Gateways for
  4853.       Congestion Avoidance", IEEE/ACM Transactions on Networking,
  4854.       August 1993
  4855.  
  4856.    [7] D. Carrel, L. Grant, "The TACACS+ Protocol", draft-grant-tacacs-00.txt,
  4857.       October 1996
  4858.  
  4859.    [8] C. Rigney, A. Rubens, W. A. Simpson, S. Willens.  "Remote Authentication
  4860.       Dial In User Service (RADIUS)." draft-ietf-radius-radius-05.txt,
  4861.       Livingston, Merit, Daydreamer, July 1996.
  4862.  
  4863. Appendix A: Acknowledgment Time-Outs
  4864.  
  4865.    L2TP uses sliding windows and time-outs to provide both user session
  4866.    flow-control across the underlying medium (which may be an
  4867.    internetwork) and to perform efficient data buffering to keep the
  4868.    LAC-LNS data channels full without causing receive buffer overflow.
  4869.    L2TP requires that a time-out be used to recover from dropped data or
  4870.    acknowledgment packets.  The exact implementation of the time-out is
  4871.    vendor-specific.  It is suggested that an adaptive time-out be
  4872.    implemented with backoff for congestion control.  The time-out
  4873.    mechanism proposed here has the following properties:
  4874.  
  4875.       Independent time-outs for each session.  A device (LAC or LNS)
  4876.  
  4877.  
  4878.  
  4879. Valencia                 expires December 1997                  [Page 74]
  4880.  
  4881.  
  4882.  
  4883.  
  4884.  
  4885. INTERNET DRAFT                                                 June 1997
  4886.  
  4887.  
  4888.       will have to maintain and calculate time-outs for every active
  4889.       session.
  4890.  
  4891.       An administrator-adjustable maximum time-out, MaxTimeOut, unique
  4892.       to each device.
  4893.  
  4894.       An adaptive time-out mechanism that compensates for changing
  4895.       throughput.  To reduce packet processing overhead, vendors may
  4896.       choose not to recompute the adaptive time-out for every received
  4897.       acknowledgment.  The result of this overhead reduction is that the
  4898.       time-out will not respond as quickly to rapid network changes.
  4899.  
  4900.       Timer backoff on time-out to reduce congestion.  The backed-off
  4901.       timer value is limited by the configurable maximum time-out value.
  4902.       Timer backoff is done every time an acknowledgment time-out
  4903.       occurs.
  4904.  
  4905.    In general, this mechanism has the desirable behavior of quickly
  4906.    backing off upon a time-out and of slowly decreasing the time-out
  4907.    value as packets are delivered without time-outs.
  4908.  
  4909.    Some definitions:
  4910.  
  4911.       Packet Processing Delay, "PPD", is the amount of time required for
  4912.       each peer to process the maximum amount of data buffered in their
  4913.       offered receive packet window.  The PPD is the value exchanged
  4914.       between the LAC and LNS when a call is established.  For the LNS,
  4915.       this number should be small.  For an LAC supporting modem
  4916.       connections, this number could be significant.
  4917.  
  4918.       "Sample" is the actual amount of time incurred receiving an
  4919.       acknowledgment for a packet.  The Sample is measured, not
  4920.       calculated.
  4921.  
  4922.       Round-Trip Time, "RTT", is the estimated round-trip time for an
  4923.       Acknowledgment to be received for a given transmitted packet.
  4924.       When the network link is a local network, this delay will be
  4925.       minimal (if not zero).  When the network link is the Internet,
  4926.       this delay could be substantial and vary widely.  RTT is adaptive:
  4927.       it will adjust to include the PPD and whatever shifting network
  4928.       delays contribute to the time between a packet being transmitted
  4929.       and receiving its acknowledgment.
  4930.  
  4931.       Adaptive Time-Out, "ATO", is the time that must elapse before an
  4932.       acknowledgment is considered lost.  After a time-out, the sliding
  4933.       window is partially closed and the ATO is backed off.
  4934.  
  4935. Packet Processing Delay (PPD)
  4936.  
  4937.    The PPD parameter is a 16-bit time value exchanged during the Call
  4938.    Control phase expressed in units of tenths of a second (64 means 6.4
  4939.    seconds).  The protocol only specifies that the parameter is
  4940.    exchanged, it does not specify how it is calculated.  The way values
  4941.    for ATO are calculated is implementation-dependent and need not be
  4942.  
  4943.  
  4944.  
  4945. Valencia                 expires December 1997                  [Page 75]
  4946.  
  4947.  
  4948.  
  4949.  
  4950.  
  4951. INTERNET DRAFT                                                 June 1997
  4952.  
  4953.  
  4954.    variable (static time-outs are allowed).  IF adaptive time-outs are
  4955.    to be used then the PPD should be exchanged in the call connect
  4956.    sequences.  A possible way to calculate the PPD is:
  4957.  
  4958.    PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
  4959.            + LACFudge  (for an LAC)
  4960.    or
  4961.    PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate
  4962.            + LNSFudge  (for an LNS)
  4963.  
  4964.    Header is the total size of the L2TP and media dependent headers.
  4965.    MTU is the overall MTU for the link between the LAC and LNS.
  4966.    WindowSize represents the number of packets in the sliding window,
  4967.    and is implementation-dependent.  The latency of the underlying
  4968.    connection path between the LAC and LNS could be used to pick a
  4969.    window size sufficient to keep the current session's pipe full.  The
  4970.    constant 8 converts octets to bits (assuming ConnectRate is in bits
  4971.    per second).  If ConnectRate is in bytes per second, omit the 8.
  4972.    LACFudge and LNSFudge are not required but can be used to take
  4973.    overall processing overhead of the LAC or LNS into account.
  4974.  
  4975.    In the case of the computed PPD for an LNS, AvePathRate is the
  4976.    average bit rate of the path between the LNS and LAC.  Given that
  4977.    this number is probably very large and WindowSize is relatively
  4978.    small, LNSFudge will be the dominant factor in the computation of
  4979.    PPD.  It is recommended that the minimum value of PPD be on the order
  4980.    of 0.5 second.
  4981.  
  4982.    The value of PPD is used to seed the adaptive algorithm with the
  4983.    initial RTT[n-1] value.
  4984.  
  4985. A.1 Calculating Adaptive Acknowledgment Time-Out
  4986.  
  4987.    We still must decide how much time to allow for acknowledgments to
  4988.    return.  If the time-out is set too high, we may wait an
  4989.    unnecessarily long time for dropped packets.  If the time-out is too
  4990.    short, we may time out just before the acknowledgment arrives.  The
  4991.    acknowledgment time-out should also be reasonable and responsive to
  4992.    changing network conditions.
  4993.  
  4994.    The suggested adaptive algorithm detailed below is based on the TCP
  4995.    1989 implementation and is explained in Richard Steven's book TCP/IP
  4996.    Illustrated, Volume 1 (page 300).  'n' means this iteration of the
  4997.    calculation, and 'n-1' refers to values from the last calculation.
  4998.  
  4999.       DIFF[n] = SAMPLE[n] - RTT[n-1] DEV[n] = DEV[n-1] + (beta *
  5000.       (|DIFF[n]| - DEV[n-1])) RTT[n] = RTT[n-1] + (alpha * DIFF[n])
  5001.       ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)
  5002.  
  5003.       DIFF represents the error between the last estimated round-trip
  5004.       time and the measured time.  DIFF is calculated on each iteration.
  5005.  
  5006.       DEV is the estimated mean deviation.  This approximates the
  5007.       standard deviation.  DEV is calculated on each iteration and
  5008.  
  5009.  
  5010.  
  5011. Valencia                 expires December 1997                  [Page 76]
  5012.  
  5013.  
  5014.  
  5015.  
  5016.  
  5017. INTERNET DRAFT                                                 June 1997
  5018.  
  5019.  
  5020.       stored for use in the next iteration.  Initially, it is set to 0.
  5021.  
  5022.       RTT is the estimated round-trip time of an average packet.  RTT is
  5023.       calculated on each iteration and stored for use in the next
  5024.       iteration.  Initially, it is set to PPD.
  5025.  
  5026.       ATO is the adaptive time-out for the next transmitted packet.  ATO
  5027.       is calculated on each iteration.  Its value is limited, by the MIN
  5028.       function, to be a maximum of the configured MaxTimeOut value.
  5029.  
  5030.       Alpha is the gain for the average and is typically 1/8 (0.125).
  5031.  
  5032.       Beta is the gain for the deviation and is typically 1/4 (0.250).
  5033.  
  5034.       Chi is the gain for the time-out and is typically set to 4.
  5035.  
  5036.    To eliminate division operations for fractional gain elements, the
  5037.    entire set of equations can be scaled.  With the suggested gain
  5038.    constants, they should be scaled by 8 to eliminate all division.  To
  5039.    simplify calculations, all gain values are kept to powers of two so
  5040.    that shift operations can be used in place of multiplication or
  5041.    division.  The above calculations are carried out each time an
  5042.    acknowledgment is received for a packet that was not retransmitted
  5043.    (no time-out occurs).
  5044.  
  5045. A.2 Congestion Control: Adjusting for Time-Out
  5046.  
  5047.    This section describes how the calculation of ATO is modified in the
  5048.    case where a time-out does occur.  When a time-out occurs, the time-
  5049.    out value should be adjusted rapidly upward.  Although L2TP payload
  5050.    packets are not retransmitted when a time-out occurs, the time-out
  5051.    should be adjusted up toward a maximum limit.  To compensate for
  5052.    shifting internetwork time delays, a strategy must be employed to
  5053.    increase the time-out when it expires.  A simple formula called
  5054.    Karn's Algorithm is used in TCP implementations and may be used in
  5055.    implementing the backoff timers for the LNS or the LAC.  Notice that
  5056.    in addition to increasing the time-out, we also shrink the size of
  5057.    the window as described in the next section.
  5058.  
  5059.    Karn's timer backoff algorithm, as used in TCP, is:
  5060.  
  5061.       NewTIMEOUT = delta * TIMEOUT
  5062.  
  5063.    Adapted to our time-out calculations, for an interval in which a
  5064.    time-out occurs, the new time-out interval ATO is calculated as:
  5065.  
  5066.       RTT[n] = delta * RTT[n-1] DEV[n] = DEV[n-1] ATO[n] = MIN (RTT[n] +
  5067.       (chi * DEV[n]), MaxTimeOut)
  5068.  
  5069.    In this modified calculation of ATO, only the two values that
  5070.    contribute to ATO and that are stored for the next iteration are
  5071.    calculated.  RTT is scaled by delta, and DEV is unmodified.  DIFF is
  5072.    not carried forward and is not used in this scenario.  A value of 2
  5073.    for Delta, the time-out gain factor for RTT, is suggested.
  5074.  
  5075.  
  5076.  
  5077. Valencia                 expires December 1997                  [Page 77]
  5078.  
  5079.  
  5080.  
  5081.  
  5082.  
  5083. INTERNET DRAFT                                                 June 1997
  5084.  
  5085.  
  5086. Appendix B:  Acknowledgment Time-Out and Window Adjustment
  5087.  
  5088. B.1 Initial Window Size
  5089.  
  5090.    Although each side has indicated the maximum size of its receive
  5091.    window, it is recommended that a slow start method be used to begin
  5092.    transmitting data.  The initial window size on the transmitter is set
  5093.    to half the maximum size the receiver requested, with a minimum size
  5094.    of one packet.  The transmitter stops sending packets when the number
  5095.    of packets awaiting acknowledgment is equal to the current window
  5096.    size.  As the receiver successfully digests each window, the window
  5097.    size on the transmitter is bumped up by one packet until the maximum
  5098.    is reached.  This method prevents a system from flooding an already
  5099.    congested network because no history has been established.
  5100.  
  5101.    When for any reason an LAC or LNS receives more data than it can
  5102.    queue for the tunnel, a packet must be discarded.  In this case, it
  5103.    is recommended that a "random early discard" algorithm [6] be used
  5104.    rather than the obvious "drop last" algorithm.
  5105.  
  5106. B.2 Closing the Window
  5107.  
  5108.    When a time-out does occur on a packet, the sender adjusts the size
  5109.    of the transmit window down to one half its value when it failed.
  5110.    Fractions are rounded up, and the minimum window size is one.
  5111.  
  5112. B.3 Opening the Window
  5113.  
  5114.    With every successful transmission of a window's worth of packets
  5115.    without a time-out, the transmit window size is increased by one
  5116.    packet until it reaches the maximum window size that was sent by the
  5117.    other side when the call was connected.  As stated earlier, no
  5118.    retransmission is done on a time-out.  After a time-out, the
  5119.    transmission resumes with the window starting at one half the size of
  5120.    the transmit window when the time-out occurred and adjusting upward
  5121.    by one each time the transmit window is filled with packets that are
  5122.    all acknowledged without time-outs.
  5123.  
  5124. B.4 Window Overflow
  5125.  
  5126.    When a receiver's window overflows with too many incoming packets,
  5127.    excess packets are thrown away.  This situation should not arise if
  5128.    the sliding window procedures are being properly followed by the
  5129.    transmitter and receiver.  It is assumed that, on the transmit side,
  5130.    packets are buffered for transmission and are no longer accepted from
  5131.    the packet source when the transmit buffer fills.
  5132.  
  5133. Appendix C: Handling of out-of-order packets
  5134.  
  5135.    When the Sequence Number and Acknowledgment Number fields are present
  5136.    in payload packets, they are used to manage packet rate.  In
  5137.    addition, they may be used to handle out-of-order arrival of packets.
  5138.    A simple L2TP client would simply discard any packet other than a
  5139.    packet with a sequence greater than that last received; if packets 1,
  5140.  
  5141.  
  5142.  
  5143. Valencia                 expires December 1997                  [Page 78]
  5144.  
  5145.  
  5146.  
  5147.  
  5148.  
  5149. INTERNET DRAFT                                                 June 1997
  5150.  
  5151.  
  5152.    2, 3 arrived as 1, 3, 2, this would result in packet 2 being
  5153.    discarded.
  5154.  
  5155.    Such behavior does not affect the L2TP protocol itself, but
  5156.    significantly improved throughput in such environments may be
  5157.    attained by queueing and reordering packets when they arrive out of
  5158.    order.  The number of packets to be queued is a function of memory
  5159.    resources on the L2TP implementation, but should never be more than
  5160.    1/4 of the total sequence number space (i.e., 16384 packets), to
  5161.    avoid aliasing.
  5162.  
  5163.    An implementation which queues packets in this way must also employ
  5164.    an algorithm for deciding that a given sequence number corresponds to
  5165.    a packet which is lost, rather than one which is out of order but
  5166.    still in transit.  Such a decision would likely be based upon timing,
  5167.    buffering conditions, and packet arrival characteristics.  The
  5168.    details of such a tradeoff are outside the scope of this
  5169.    specification, but it is recommended a packet should be afforded an
  5170.    interval at least twice the estimated RTT from the L2TP peer.
  5171.  
  5172. Appendix D: Transport Layer Adaptive Time-outs and Window Adjustment
  5173.  
  5174.    Appendixes A, B, and C dealt with operation of the payload packet
  5175.    sessions of L2TP.  This Appendix explains how these three algorithms
  5176.    pertain to the transport layer for L2TP control sessions. Appendix B,
  5177.    Time-out Window Management, directly applies to the Transport Layer
  5178.    except in the case where a window size of 1 is being used.  Appendix
  5179.    C, does not really apply because, for the Control Session, control
  5180.    messages MUST always be processed by the receiver in order.  Also,
  5181.    there are no lost control packets because they are retransmitted by
  5182.    the L2TP Transport Layer.  Thus, the main topic of this Appendix is
  5183.    how to adapt the example adaptive time-out algorithm of Appendix A to
  5184.    the Control Session Transport Layer.
  5185.  
  5186.    There are two main differences between the Control Session and
  5187.    payload sessions:  1) Unlike lost payload packets, lost control
  5188.    messages are retransmitted and 2) There is no Packet Processing Delay
  5189.    value provided in the control session setup messages.  The latter
  5190.    affects the manner in which the initial value of the RTT estimate is
  5191.    determined.  The former really doesn't affect the algorithm at all,
  5192.    except that upon a time-out, retransmission of unacknowledged control
  5193.    messages should be attempted, up to the number that fit in the
  5194.    sliding window with size computed as in Appendix B.
  5195.  
  5196.    Using the symbol definitions of Appendix A, the calculation of the
  5197.    value for the PPD of the remote peer can be estimated as:
  5198.  
  5199.    PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate
  5200.            + Fudge
  5201.  
  5202.    This is simply the number of bits in a full control session window
  5203.    divided by the average speed of the path between the LAC and LNS with
  5204.    a fudge factor added on to make it work.  In cases where the average
  5205.    rate of the connection between LAC and LNS isn't known, it is
  5206.  
  5207.  
  5208.  
  5209. Valencia                 expires December 1997                  [Page 79]
  5210.  
  5211.  
  5212.  
  5213.  
  5214.  
  5215. INTERNET DRAFT                                                 June 1997
  5216.  
  5217.  
  5218.    suggested that some value be configured that is associated with each
  5219.    possible peer.  Because Control Session windows will most likely be
  5220.    small and the connection speed will be quite high, fudge will be the
  5221.    dominant factor in this calculation.  For this reason, just
  5222.    configuring a single fixed initial PPD estimate to be used for all
  5223.    possible peers will probably provide adequate results.  This fudge
  5224.    factor should probably be at least 0.5 second.
  5225.  
  5226. Appendix E: Examples of L2TP sequence numbering
  5227.  
  5228.    Although sequence numbers serve distinct purposes for control and
  5229.    data messages, both types of messages use identical techniques for
  5230.    assigning sequence numbers.  This appendix shows several common
  5231.    scenarios, and illustrates how sequence number state progresses and
  5232.    is intepreted.
  5233.  
  5234.    E.1: Lock-step tunnel establishment
  5235.  
  5236.       In this example, an LAC establishes a tunnel, with the exchange
  5237.       involving each side alternating in sending messages.  This example
  5238.       is contrived, in that the final acknowledgement in the example is
  5239.       explicitly sent within a zero-length message, although most
  5240.       typically the acknowledgement would have been included in the
  5241.       processing of the Incoming-Call-Request which had prompted the LAC
  5242.       to initiate the tunnel in the first place.
  5243.  
  5244.       LAC -> LNS: Start-Control-Connection-Request
  5245.       Nr: 0, Ns: 0
  5246.  
  5247.       LNS -> LAC: Start-Control-Connection-Reply
  5248.       Nr: 1, Ns: 0
  5249.  
  5250.       LAC -> LNS: Start-Control-Connection-Connected
  5251.       Nr: 1, Ns: 1
  5252.  
  5253.       (delay)
  5254.  
  5255.       LNS -> LAC: (zero-length)
  5256.       Nr: 2, Ns: 1
  5257.  
  5258.       E.2: Multiple packets acknowledged
  5259.  
  5260.       This example shows a flow of payload packets from the LNS to the
  5261.       LAC, with the LAC having no traffic of its own.  The LAC is
  5262.       waiting 1/4 of its timeout interval, and then acknowledging all
  5263.       packets seen since the last interval.
  5264.  
  5265.       (previous packet flow precedes this)
  5266.  
  5267.       LAC -> LNS: (zero-length)
  5268.       Nr: 7000, Ns: 1000
  5269.  
  5270.       LNS -> LAC: (payload)
  5271.       Nr: 1000, Ns: 7000
  5272.  
  5273.  
  5274.  
  5275. Valencia                 expires December 1997                  [Page 80]
  5276.  
  5277.  
  5278.  
  5279.  
  5280.  
  5281. INTERNET DRAFT                                                 June 1997
  5282.  
  5283.  
  5284.       LNS -> LAC: (payload)
  5285.       Nr: 1000, Ns: 7001
  5286.       LNS -> LAC: (payload)
  5287.       Nr: 1000, Ns: 7002
  5288.  
  5289.       (LAC's timer indicates it should acknowledge pending traffic)
  5290.  
  5291.       LAC -> LNS: (zero-length)
  5292.       Nr: 7003, Ns: 1000
  5293.  
  5294.       E.3: Lost packet with retransmission
  5295.  
  5296.       As a final example, an existing tunnel has a new session requested
  5297.       by the LAC.  The Incoming-Call-Reply is lost and must be
  5298.       retransmitted by the LNS.  This example continues from the
  5299.       sequence state reached at the end of example E.1.  Note that loss
  5300.       of the -Reply has two impacts: not only does it keep the upper
  5301.       level state machine from progressive, but it also keeps the LAC
  5302.       from seeing a timely lower level acknowledgement of its -Request
  5303.       packet.
  5304.  
  5305.       LAC -> LNS: Incoming-Call-Request
  5306.       Nr: 1, Ns: 2
  5307.  
  5308.       LNS -> LAC: Incoming-Call-Reply
  5309.       Nr: 3, Ns: 1
  5310.  
  5311.       (pause; LAC's timer started first, so fires first)
  5312.  
  5313.       LAC -> LNS: Incoming-Call-Request
  5314.       Nr: 1, Ns: 2
  5315.  
  5316.       (LNS realizes he has already seen this packet)
  5317.       (LNS might use this as a cue to retransmit, as in this example)
  5318.  
  5319.       LNS -> LAC: Incoming-Call-Reply
  5320.       Nr: 3, Ns: 1
  5321.  
  5322.       LAC -> LNS: Incoming-Call-Connected
  5323.       Nr: 2, Ns: 3
  5324.  
  5325.       (delay)
  5326.  
  5327.       LNS -> LAC: (zero-length)
  5328.       Nr: 4, Ns: 2
  5329.  
  5330.  
  5331.  
  5332.  
  5333.  
  5334.  
  5335.  
  5336.  
  5337.  
  5338.  
  5339.  
  5340.  
  5341. Valencia                 expires December 1997                  [Page 81]
  5342.  
  5343.  
  5344.