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