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