HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 06:39:43 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 21 Aug 1997 13:54:00 GMT ETag: "304d80-371c5-33fc4878" Accept-Ranges: bytes Content-Length: 225733 Connection: close Content-Type: text/plain PPP Working Group Kory Hamzeh INTERNET DRAFT Ascend Communications Category: Internet Draft Tim Kolar Title: draft-ietf-pppext-l2tp-05.txt Cisco Systems Date: August 1997 Morgan Littlewood Cisco Systems Gurdeep Singh Pall Microsoft Corporation Bill Palter Cisco Systems Jeff Taarud Copper Mountain Networks W. Mark Townsley IBM Andrew J. Valencia Cisco Systems William Verthein U.S. Robotics Layer Two Tunneling Protocol "L2TP" Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. RFC1661 specifies multiprotocol dial-up via PPP [1]. This document describes the Layer Two Tunneling Protocol (L2TP) which permits the tunneling of the link layer (i.e., HDLC, async HDLC) of PPP. Using such tunnels, it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided. Valencia expires February 1998 [Page 1] INTERNET DRAFT August 1997 Table of Contents 1.0 Introduction 1.1 Conventions 1.2 Terminology 2.0 Problem Space Overview 2.1 Initial Assumptions 2.2 Topology 2.3 Providing Virtual Dial-up Services--a walk-through 3.0 Service Model Issues 3.1 Security 3.2 Address Allocation 3.3 Authentication 3.4 Accounting 4.0 Protocol Overview 4.1 Control Message Overview 4.2 Payload Packet Overview 5.0 Message Format and Protocol Extensibility 5.1 AVP 5.2 Control Message Format 5.3 Payload Message Format 5.4 Control Message Types 5.5 AVP Summary 5.6 Result and Error Code Summary 5.7 Hiding of AVP values 6.0 Control Connection Protocol Specification 6.1 Start-Control-Connection-Request 6.2 Start-Control-Connection-Reply 6.3 Start-Control-Connection-Connected 6.4 Stop-Control-Connection-Request 6.5 (reserved) 6.6 Hello 6.7 Outgoing-Call-Request 6.8 Outgoing-Call-Reply 6.9 Outgoing-Call-Connected 6.10 Incoming-Call-Request 6.11 Incoming-Call-Reply 6.12 Incoming-Call-Connected 6.13 (reserved) 6.14 Call-Disconnect-Notify 6.15 WAN-Error-Notify 6.16 Set-Link-Info 7.0 Control Connection State Machines 7.1 Control Connection Protocol Operation 7.2 Control Connection States 7.2.1 Control Connection Originator 7.2.2 Control connection Receiver 7.3 Timing considerations 7.4 Incoming Calls 7.4.1 LAC Incoming Call States 7.4.2 LNS Incoming Call States 7.5 Outgoing calls 7.5.1 LAC Outgoing Call States 7.5.2 LNS Outgoing Call States Valencia expires February 1998 [Page 2] INTERNET DRAFT August 1997 8.0 L2TP Over Specific Media 8.1 IP/UDP 8.2 IP 9.0 Security Considerations 9.1 Tunnel Endpoint Security 9.2 Client Security 10.0 Acknowledgments 11.0 Contacts 12.0 References Appendix A: Acknowledgment Time-Outs Appendix B: Acknowledgment Time-Out and Window Adjustment Appendix C: Handling of out-of-order packets Appendix D: Transport Layer Adaptive Time-Outs and Window Adjustment Appendix E: Examples of L2TP sequence numbering E.1 Lock-step tunnel establishment E.2 Multiple packets acknowledged E.3 Lost packet with retransmission 1.0 Introduction The traditional dial-up network service on the Internet is for registered IP addresses only. A new class of virtual dial-up application which allows multiple protocols and unregistered IP addresses is also desired on the Internet. Examples of this class of network application are support for privately addressed IP, IPX, and AppleTalk dial-up via PPP across existing Internet infrastructure. The support of these multiprotocol virtual dial-up applications is of significant benefit to end users, enterprises, and Internet Service providers as it allows the sharing of very large investments in access and core infrastructure and allows local calls to be used. It also allows existing investments in non-IP protocol applications to be supported in a secure manner while still leveraging the access infrastructure of the Internet. It is the purpose of this draft to identify the issues encountered in integrating multiprotocol dial-up services into an existing Internet Service Provider's Point of Presence (hereafter referred to as ISP and POP, respectively), and to describe the L2TP protocol which permits the leveraging of existing access protocols. This protocol may also be used to solve the "multilink hunt-group splitting" problem. Multilink PPP, often used to aggregate ISDN B channels, requires that all channels composing a multilink bundle be grouped at a single NAS. Because L2TP makes a PPP session appear at a location other than the physical point at which the session was physically received, it can be used to make all channels appear at a single NAS, allowing multilink operation even when the physical calls are spread across distinct physical NAS's. 1.1 Conventions The following language conventions are used in the items of specification in this document: Valencia expires February 1998 [Page 3] INTERNET DRAFT August 1997 o MUST, SHALL, or MANDATORY -- This item is an absolute requirement of the specification. o SHOULD or RECOMMEND -- This item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- This item is truly optional and may be followed or ignored according to the needs of the implementor. 1.2 Terminology Analog Channel A circuit-switched communication path which is intended to carry 3.1 Khz audio in each direction. Digital Channel A circuit-switched communication path which is intended to carry digital information in each direction. Call A connection or attempted connection between two terminal endpoints on a PSTN or ISDN--for example, a telephone call between two modems. CHAP Challenge Authentication Protocol, a PPP cryptographic challenge/response authentication protocol in which the cleartext password is not passed in the clear over the line. CLID Calling Line ID, an indication to the receiver of a call as to the phone number of the caller. Control Messages Control messages are exchanged between LAC, LNS pairs, and operate in-band within the tunnel protocol. Control messages govern aspects of the tunnel and sessions within the tunnel. Dial User An end-system or router attached to an on-demand PSTN or ISDN which is either the initiator or recipient of a call. DNIS Dialed Number Information String, an indication to the receiver of a call as to what phone number the caller used to reach it. EAP Valencia expires February 1998 [Page 4] INTERNET DRAFT August 1997 Extensible Authentication Protocol, a framework for a family of PPP authentication protocols, including cleartext, challenge/response, and arbitrary dialog sequences. L2TP Access Concentrator (LAC) A device attached to one or more PSTN or ISDN lines capable of PPP operation and of handling the L2TP protocol. The LAC needs only implement the media over which L2TP is to operate to pass traffic to one or more LNS's. It may tunnel any protocol carried within PPP. L2TP Network Server (LNS) An LNS operates on any platform capable of PPP termination. The LNS handles the server side of the L2TP protocol. Since L2TP relies only on the single media over which L2TP tunnels arrive, the LNS may have only a single LAN or WAN interface, yet still be able to terminate calls arriving at any LAC's full range of PPP interfaces (async, synchronous ISDN, V.120, etc.). Network Access Server (NAS) A device providing temporary, on-demand network access to users. This access is point-to-point using PSTN or ISDN lines. PAP Password Authentication Protocol, a simple PPP authentication mechanism in which a cleartext username and password are transmitted to prove identity. Session L2TP is connection-oriented. The LNS and LAC maintain state for each user that is attached to an LAC. A session is created when an end-to-end PPP connection is attempted between a dial user and the LNS, or when a outbound call is initiated. The datagrams related to a session are sent over the tunnel between the LAC and LNS. Quality of Service (QOS) A given Quality of Service level is sometimes required for a given user being tunneled between an LNS-LAC pair. For this scenario, a unique L2TP tunnel is created (generally on top of a new SVC) and encapsulated directly on top of the media providing the indicated QOS. Switched Virtual Circuit (SVC) An L2TP-compatible media on top of which L2TP is directly encapsulated. SVC's are dynamically created, permitting tunnel media to be created dynamically in response to desired LNS-LAC Valencia expires February 1998 [Page 5] INTERNET DRAFT August 1997 connectivity requirements. Tunnel A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP datagrams between the LAC and the LNS; many sessions can be multiplexed over a single tunnel. A control connection operating in-band over the same tunnel controls the establishment, release, and maintenance of sessions and of the tunnel itself. 2.0 Problem Space Overview In this section we describe in high level terms the scope of the problem that will be explored in more detail in later sections. 2.1 Initial Assumptions We begin by assuming that Internet access is provided by an ISP and that the ISP wishes to offer services other than traditional registered IP address based services to dial-up users of the network. We also assume that the user of such a service wants all of the security facilities that are available to him in a dedicated dial-up configuration. In particular, the end user requires: + End System transparency: Neither the remote end system nor his home site hosts should require any special software to use this service in a secure manner. + Authentication as provided via dial-up PPP CHAP, PAP, EAP, or through other dialogs, for instance, a textual exchange on V.120 before starting PPP. This will include TACACS+ [7] and RADIUS [8] solutions as well as support for smart cards and one-time passwords. The authentication should be manageable by the user independently of the ISP. + Addressing should be as manageable as dedicated dial-up solutions. The address should be assigned by the home site and not the ISP. + Authorization should be managed by the home site as it would in a direct dial-up solution. + Accounting should be performed both by the ISP (for billing purposes) and by the user (for charge-back and auditing). 2.2 Topology Shown below is a generic Internet with Public switched Telephone Network (PSTN) access (i.e., async PPP via modems) and Integrated Services Digital Network (ISDN) access (i.e., synchronous PPP access). Remote users (either async or ISDN PPP) will access the Home LAN as if they were dialed into the L2TP Network Server (LNS), although their physical dial-up is via the ISP Network Access Server. Valencia expires February 1998 [Page 6] INTERNET DRAFT August 1997 ...----[L]----+---[L]-----... | | [H] | ________|________________________ | | ________|__ ______|________ | | | | | PSTN [R] [R] ISDN | | Cloud | | Cloud [N]__[U] | | Internet | | | | [R] | [N]______[R] |_____________| | | | | | | [U] |________________________________| [H] = LNS [L] = Home LAN(s) [R] = Router [U] = Remote User [N] = ISP Network Access Server 2.3 Providing Virtual dial-up Services--a walk-through To motivate the following discussion, this section walks through an example of what might happen when a Virtual dial-up client initiates access. The remote user initiates a PPP connection to an ISP via either the PSTN or ISDN. The Network Access Server (NAS) accepts the connection and the PPP link is established (L2TP also permits the NAS to check with an LNS after call indication prior to accepting the call--this is useful where DNIS or CLID information is available in the incoming call notification). The ISP may now undertake a partial authentication of the end system/user. Only the username field would be interpreted to determine whether the user requires a Virtual dial-up service. It is expected--but not required--that usernames will be structured (e.g. username@company.com). Alternatively, the ISP may maintain a database mapping users to services. In the case of Virtual dial-up, the mapping will name a specific endpoint, the LNS. Alternatively, the ISP may have already determined the target LNS from DNIS. If the LNS is willing to accept tunnel creation without any authentication of the caller, the NAS may tunnel the PPP connection without ever having communicated with the remote user. If a virtual dial-up service is not required, standard access to the Internet may be provided. Valencia expires February 1998 [Page 7] INTERNET DRAFT August 1997 If no tunnel connection currently exists to the desired LNS, one is initiated. L2TP is designed to be largely insulated from the details of the media over which the tunnel is established; L2TP requires only that the tunnel media provide packet oriented point-to-point connectivity. Obvious examples of such media are UDP, Frame Relay PVC's, or X.25 VC's. Once the tunnel exists, an unused slot within the tunnel, a "Call ID", is allocated, and a connect indication is sent to notify the LNS of this new dial-up session. The LNS either accepts the connection, or rejects it. Rejection may include a reason indication, which may be displayed to the dial-up user, after which the call should be disconnected. The initial setup notification may include the authentication information required to allow the LNS to authenticate the user and decide to accept or decline the connection. In the case of CHAP, the set-up packet includes the challenge, username and raw response. For PAP or text dialog, it includes username and clear text password. The LNS may choose to use this information to complete its authentication, avoiding an additional cycle of authentication. If the LAC negotiated PPP LCP before initiating the tunnel, the initial setup notification may also include a copy of the LCP CONFREQ's sent in each direction which completed LCP negotiation. The LNS may use this information to initialize its own PPP state (thus avoiding an additional LCP negotiation), or it may choose to initiate a new LCP CONFREQ exchange. If the LNS accepts the connection, it creates a "virtual interface" for PPP in a manner analogous to what it would use for a direct- dialed connection. With this "virtual interface" in place, link layer frames may now pass over this tunnel in both directions. Frames from the remote user are received at the POP, stripped of CRC, link framing, and transparency bytes, encapsulated in L2TP, and forwarded over the appropriate tunnel. The LNS accepts these frames, strips L2TP, and processes them as normal incoming frames for the appropriate interface and protocol. The "virtual interface" behaves very much like a hardware interface, with the exception that the hardware in this case is physically located at the ISP POP. The other direction behaves analogously, with the LNS encapsulating the packet in L2TP, and the NAS stripping L2TP before transmitting it out the physical interface to the remote user. For the remainder of this document, a NAS operating as a peer to an LNS will be referred to as an L2TP Access Concentrator, or "LAC". At this point, the connectivity is a point-to-point PPP session whose endpoints are the remote user's networking application on one end and the termination of this connectivity into the LNS's PPP support on the other. Because the remote user has become simply another dial-up client of the LNS, client connectivity can now be managed using traditional mechanisms with respect to further authorization, Valencia expires February 1998 [Page 8] INTERNET DRAFT August 1997 protocol access, and packet filtering. Accounting can be performed at both the LAC as well as the LNS. This document illustrates some Accounting techniques which are possible using L2TP, but the policies surrounding such Accounting are outside the scope of this specification. L2TP offers optional facilities which maximize compatibility with legacy client requirements; L2TP connect notifications for PPP clients can contain sufficient information for an LNS to authenticate and initialize its LCP state machine. With these facilities, the remote user need not be queried a second time for PPP authentication, nor undergo multiple rounds of LCP negotiation and convergence. These techniques are intended to optimize connection setup, and are not intended to deprecate any functions required by the PPP specification. 3.0 Service Model Issues There are several significant differences between the standard Internet access service and the Virtual dial-up service with respect to authentication, address allocation, authorization and accounting. The details of the differences between these services and the problems presented by these differences are described below. The mechanisms used for Virtual Dial-up service are intended to coexist with more traditional mechanisms; it is intended that an ISP's POP can simultaneously service ISP clients as well as Virtual dial-up clients. 3.1 Security For the Virtual dial-up service, the ISP pursues authentication only to the extent required to discover the user's apparent identity (and by implication, their desired LNS). This may involve no more than detecting DNIS information when a call arrives, or may involve full LCP negotiation and initiation of PPP authentication. As soon as the apparent identity is determined, a connection to the LNS is initiated with any authentication information gathered by the ISP. The LNS completes the authentication by either accepting the connection, or rejecting it. The LNS may need to protect against attempts by third parties to establish tunnels to the LNS. Tunnel establishment can include authentication to protect against such attacks. 3.2 Address Allocation For an Internet service, the user accepts that the IP address may be allocated dynamically from a pool of ISP addresses. This model often means that the remote user has little or no access to their home network's resources, due to firewalls and other security policies applied by the home network to accesses from external IP addresses. For the Virtual dial-up service, the LNS can exist behind the home Valencia expires February 1998 [Page 9] INTERNET DRAFT August 1997 firewall, allocating addresses which are internal (and, in fact, can be RFC1918 addresses, or non-IP addresses). Because L2TP tunnels exclusively at the frame layer, the actual policies of such address management are irrelevant to correct Virtual dial-up service; for all purposes of PPP protocol handling, the dial-in user appears to have connected at the LNS. 3.3 Authentication The authentication of the user occurs in three phases; the first at the ISP, and the second and optional third at the LNS. The ISP uses DNIS, CLID, or username to determine that a Virtual dial-up service is required and initiates the tunnel connection to the appropriate LNS. Once a tunnel is established, The ISP NAS allocates a new Call ID and initiates a session by forwarding the gathered authentication information. The LNS undertakes the second phase by deciding whether or not to accept the connection. The connection indication may include CHAP, PAP, EAP, or textual authentication information. Based on this information, the LNS may accept the connection, or may reject it (for instance, it was a PAP request and the username/password are found to be incorrect). Once the connection is accepted, the LNS is free to pursue a third phase of authentication at the PPP layer. These activities are outside the scope of this specification, but might include an additional cycle of LCP authentication, proprietary PPP extensions, or textual challenges carried via a TCP/IP telnet session. 3.4 Accounting It is a requirement that both the LAC and the LNS be capable of providing accounting data and hence both may count packets, octets and connection start and stop times. Since Virtual dial-up is an access service, accounting of connection attempts (in particular, failed connection attempts) is of significant interest. The LNS can reject new connections based on the authentication information gathered by the LAC, with corresponding logging. For cases where the LNS accepts the connection and then continues with further authentication, the LNS might subsequently disconnect the client. For such scenarios, the disconnection indication back to the LAC may also include a reason. Because the LNS can decline a connection based on the authentication information collected by the LAC, accounting can easily draw a distinction between a series of failed connection attempts and a series of brief successful connections. Lacking this facility, the LNS must always accept connection requests, and would need to exchange a number of PPP packets with the remote system. Note that the LNS could use this information to decide to accept the connection (which protects against most invalid connection attempts) while still Valencia expires February 1998 [Page 10] INTERNET DRAFT August 1997 insisting on running its own CHAP authentication (for instance, to protect against CHAP replay attacks). 4.0 Protocol Overview There are two parallel components of L2TP operating over a given tunnel: control messages between each LAC-LNS pair, and payload packets between the same LAC-LNS pair. The latter are used to transport L2TP encapsulated PPP packets for user sessions between the pair. The Nr (Next Received) and Ns (Next Sent) fields are always present in control messages, and are optionally present in payload messages. A single sequence number state is maintained for all control messages, and a distinct state is maintained for the payload of each user session within the tunnel. Each state is initialized so the first packet is sent with an Ns of 0. Nr is sent reflecting one more than the last in-order received packet; if sent before any packet is received it would be 0, indicating that it expects the next new Ns value received to be 0. The sequence number state is maintained and updated as packets are sent. A message (control or payload) with a zero-length body indicates that the packet is only used to communicate Nr and Ns fields. The Nr and Ns fields are filled in as above, but the sequence number state remains the same. For non-zero-length body messages, the sequence number state is incremented (modulo 2**16) after it is copied to the packet's Ns field. Thus a zero-length message's Ns field will reflect one more than the Ns of the last non-zero-length message sent. Upon receipt of a non-zero-length message, the receiving peer must acknowledge the message by sending back the latest Nr value. This updated Nr value can be piggybacked in any non-zero-length outgoing messages that the peer may happen to send back. However, if the peer does not have a non-zero-length message to transmit for a period of 1/4 of the timeout interval after receiving a non-zero-length message then it should send a zero-length message containing the latest sequence number state, as described above. See Appendix E for some examples of how sequence numbers progress. 4.1 Control Message Overview Before PPP tunneling can occur between an LAC and LNS, control messages must be exchanged between them. Control messages are exchanged over the same tunnel which will be used to forward payload data once L2TP call control and management information have been passed. The control messages are responsible for establishment, management, and release of sessions carried through the tunnel, as well as status on the tunnel itself. It is the means by which an LNS is notified of an incoming call at an associated LAC, as well as the means by which an LAC is instructed to place an outgoing call. Valencia expires February 1998 [Page 11] INTERNET DRAFT August 1997 A tunnel may be established by either an LAC (for incoming calls) or an LNS (for outgoing calls). Following the establishment of the tunnel, the LNS and LAC configure the tunnel by exchanging Start-Control-Connection-Request and -Reply messages. These messages are also used to exchange information about basic operating capabilities of the LAC and LNS. Once the control message exchange is complete, the LAC may initiate sessions by indicating inbound requests, or the LNS by requesting outbound calls. If both ends of the tunnel have the ability to act as an LAC and LNS concurrently, then nothing prohibits establishing incoming or outgoing calls from both sides of the same tunnel. Control messages may indicate changes in operating characteristics of an individual user session with a Set-Link-Info message. Individual sessions may be released by either the LAC or LNS, also through control messages. Independent Call ID values are established for each end of a user session. The sender of a packet associated with a particular session places the Call ID established by its peer in the Call ID header field of all outgoing packets. For the cases where a Call ID has not yet been assigned from the peer (i.e., during call establishment of a new session), the Call ID field is sent as 0, and further fields within the message are used to identify the session. The Call ID value of 0 is thus special and MUST NOT be used as an Assigned Call ID. A mechanism for detection of tunnel connectivity problems is provided by the reliable transport layer of L2TP. The transport layer of L2TP performs control message retransmission. If the number of retransmission attempts for a given control message exceeds a configured maximum value, the tunnel is reset. This retransmission mechanism exists in both the LNS and LAC ends of the tunnel. A keepalive mechanism is employed by the L2TP higher layer in order to differentiate tunnel outages from extended periods of no control or data activity on a tunnel. This is accomplished by the higher injecting Hello control messages into the control stream after a specified period of time elapses since the last data or control was received on the tunnel. As for any other control message, if the transport does not receive an ACK for the Hello message after the normal number of retransmissions the tunnel is declared down and is reset. The transport layer reset mechanism along with the injection of Hello messages ensures that a connectivity failure between the LNS and the LAC will be detected at both ends of a tunnel in a timely manner. It is intended that control messages will also carry management related information in the future, such as a message allowing the LNS to request the status of a given LAC; these message types are not defined in this document. 4.2 Payload Packet Overview Valencia expires February 1998 [Page 12] INTERNET DRAFT August 1997 Once a tunnel is established and control messages have completed tunnel setup, the tunnel can be used to carry user session PPP packets for sessions involving a given LNS-LAC pair. The "Call ID" field in the L2TP header indicates to which session a particular PPP packet belongs. In this manner, PPP packets are multiplexed and demultiplexed over a single tunnel between a given LNS-LAC pair. The "Call ID" field value is established during the exchange of call setup control messages. It is legal for multiple tunnels to exist between a given LNS-LAC pair. This is useful where each tunnel is used for a single user session, and the tunnel media (an SVC, for instance) has specific QOS attributes dedicated to a given user. L2TP provides a tunnel identifier so that individual tunnels can be identified, even when arriving from a single source LAC or LNS. The L2TP header also contains optional acknowledgment and sequencing information that can be used to perform congestion and flow control over the tunnel. Control messages are used to determine rate and buffering parameters that are used to regulate the flow of PPP packets for a particular session over the tunnel. The receiving peer indicates whether flow-control is to be performed for payload packets sent to it. If a peer issues a Receive Window Size AVP with a non-zero value during session establishment then the sending peer must abide by the indicated window size value. If a receiving peer does not wish to flow control the payload messages sent to it, it should not issue the Receive Window Size AVP with a non-zero value. Issuing a Receive Window Size AVP with a zero value has special significance. It indicates that the receiver does not want to perform flow-control but it does want the sending peer to provide Ns values in payload packets so that it can detect (and perhaps reorder) packets received out of order. In the case where neither peer issues a Receive Window Size AVP during session establishment, the optional Nr and Ns fields are absent in all payload messages for that session. In the case where either peer wishes to perform flow-control or to detect out-of-order receive messages (as indicated by the sending of the Receive Window Size AVP with non-zero or zero value, respectively) the Nr and Ns fields MUST be present in payload messages sent by both peers. Both MUST provide proper Nr and Ns values in all messages transmitted. A proper Ns value starts at 0 and increments by one for each transmitted payload message and a proper Nr value is the current value of the receive sequence number state variable. If a receiving peer offers a non-zero receive window size to a sending peer then the sending peer SHOULD abide by this window size value. The sending peer should stop sending payload messages when the window is full; i.e., x consecutive messages have been Valencia expires February 1998 [Page 13] INTERNET DRAFT August 1997 sent but have not been acknowledged, where x is the value of the Receive Window Size AVP. Implementors should take care to avoid the situation where loss of an ACK by a sending peer with a full transmit window causes a session to hang forever, due to the fact there are no retransmissions of payload messages. Steps must be taken to reopen the transmit window (at least to a value of 1) upon expiration of an ACK wait timeout. See Appendix B for more details. L2TP does not specify the particular algorithms to use for congestion control. Suggested algorithms for the determination of adaptive time-outs to recover from dropped data or acknowledgments on the tunnel are included in Appendix A of this document. L2TP does not include a "Receive-Not-Ready" function. It is expected that the flow-control mechanism used will provide an adequate "pacing" mechanism so that the sender does not overflow the receiver's allotted receive window and receive buffers. It is permissible for the receiving peer to withhold Acks if it is unable to accept more data for a connection. Thus, unlike for the Control Message session, the sending peer MUST NOT clear a session (or the whole tunnel) as a result of not receiving timely acknowledgments for transmitted packets. The job of detecting a non-functioning tunnel lies solely with the Control Message functions of L2TP. 5. Message Format and Protocol Extensibility L2TP defines a set of control messages sent in packets over the tunnel between an LNS and a given LAC. The exact technique for initiating a tunnel between an LNS-LAC pair is specific to the tunnel media, and specific media are described in section 8.0. Once media-level connectivity is reached, L2TP message formats define the protocol for an LAC and LNS to manage the tunnel and its associated sessions. In each case where a field is optional, if the field is not present, its space does not exist in the packet. Existing fields are placed back-to-back to form the packet. 5.1 AVP To maximize extensibility while still permitting interoperability, a uniform method for encoding message types and bodies is used throughout L2TP. This encoding will be termed an AVP (Attribute- Value Pair) in the remainder of this document. Each AVP is encoded as: Valencia expires February 1998 [Page 14] INTERNET DRAFT August 1997 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0| Overall Length | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [until Overall Length is reached]... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first six bits are a bit mask, describing the general attributes of the AVP. The M bit, known as the "mandatory" bit, controls the behavior required of an implementation which receives an AVP which it does not recognize. If M is set on an AVP associated call management, any session associated with this AVP MUST be terminated. If the AVP is associated with the overall tunnel, the entire tunnel (and all sessions within) MUST be terminated. If M is not set, an unrecognized AVP should be ignored. The H bit, known as the "hidden" bit, controls the hiding of the data in the value field of an AVP. This capability can be used to avoid the passing of sensitive data, such as user passwords, as cleartext in an AVP. Section 5.7 describes the procedure for performing AVP value hiding. Overall Length encodes the number of octets (including the Overall Length field itself) contained in this AVP. It is 10 bits, permitting a maximum of 1024 bytes of data in a single AVP. Vendor ID is the IANA assigned "SMI Network Management Private Enterprise Codes" value, encoded in network byte order. The value 0, reserved in this table, corresponds to IETF adopted Attribute values, defined within this document. Any vendor wishing to implement L2TP extensions can use their own Vendor ID along with private Attribute values, guaranteeing that they will not collide with any other vendor's extensions, nor with future IETF extensions. Attribute is the actual attribute, a 16-bit value with a unique interpretation across all AVP's defined under a given Vendor ID. Value follows immediately after the Attribute field, and runs for the remaining octets indicated in the Overall Length (i.e., Overall Length minus six octets of header). AVP's should be kept compact; the combined AVP's within a control message MUST NOT ever cause a control message's total length to exceed 1500 bytes in length. 5.2 Control Message Format Each L2TP control message begins with a 16 octet header portion Valencia expires February 1998 [Page 15] INTERNET DRAFT August 1997 followed by zero or more AVP's. This header is formatted: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|1|0|0|1|0|0|0| | Ver | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ns | Nr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type AVP... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... (8 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The T bit MUST be 1, indicating a control message. The following seven bits MUST be set to 1001000, making the header more compatible in encoding with the payload message (defined in the next section). Ver MUST be the value 2, indicating a version 1 L2TP message (values 0 and 1 are reserved to permit detection of L2F [2] and PPTP [3] packets if they arrive intermixed). Length is the overall length of the message, including header, message type AVP, plus any additional AVP's associated with a given control message type. Tunnel ID and Call ID identify the tunnel and user session within the tunnel to which a control message applies. If a control message does not apply to a single user session within the tunnel (for instance, a Stop-Control-Connection-Notification message), Call ID MUST be set to 0. If an Assigned Tunnel ID has not yet been received from the peer, Tunnel ID MUST be set to 0. Once an Assigned Tunnel ID is received, all further packets MUST be sent with Tunnel ID set to the indicated value. Nr and Ns reflect the currently transmitted packet and latest received packet respectively. See section 4.0. 5.3 Payload Message Format PPP payload packets tunneled within L2TP have a smaller encapsulation than the L2TP control message header, reducing overhead of L2TP during the life of a tunneled PPP session. The MTU for the user data packets encapsulated in L2TP is expected to be 1500 octets, not including L2TP and media encapsulation. The smallest L2TP encapsulation is 2 octets; the largest is 14 octets (plus padding bytes, if present). See section 8.1 for further MTU considerations. Valencia expires February 1998 [Page 16] INTERNET DRAFT August 1997 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|L|I|C|F|K|O|0|0|0|0|0|0| Ver | Length (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ns (opt) | Nr (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset Size (opt) | Offset pad... (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The T bit MUST be 0, indicating payload. Ver MUST be 2, indicating version 1 of the L2TP protocol. If the L bit is set, the Length field is present, indicating the total length of the received packet. The I and C bits are reserved and MUST be set to 0. These bit positions represent options no longer present in L2TP. If the F bit is set, both the Nr and Ns fields are present. Ns indicates indicates the sequence number of the packet being sent. The Ns value of a message being transmitted is copied from the current value of the send sequence number state variable. The send sequence number state variable is incremented by one after copying to the Ns field only if the payload size of the message being sent is non-zero. Nr indicates the next packet sequence number to be received (if the last non-zero-length data packet had Ns set to 1, the Nr sent back would be 2). Together, these fields can be used to handle out-of-order packets, and to provide flow control for the connection. An L2TP peer setting the F bit, and placing Nr and Ns fields in its messages, MUST have previously received or sent a Receive Window Size AVP during establishment of the session. The Nr and Ns fields are present and updated as described in section 4.0 if either side has specified an intention to do payload flow control. The K bit is reserved MUST be set to 0. This bit position represents a function no longer present in L2TP. The bits following the K bit MUST all be 0. The Offset Size field is present if the O bit is set in the header flags. This field specifies the number of bytes past the L2TP header at which the payload data is expected to start. It is recommended that data thus skipped be initialized to 0's. If Offset Size is 0, or the O bit is not set, the first byte following the last byte of L2TP header is the first byte of payload data. An implementation that does not support an extension which might make use of a particular reserved bit MUST not Valencia expires February 1998 [Page 17] INTERNET DRAFT August 1997 attempt to process a packet received with such reserved bit set. 5.4 Control Message Types Control message and AVP types defined in this specification exist under Vendor ID 0, indicating IETF defined behavior. The actual message and AVP semantics are defined in the next section. This section includes tables that summarize all currently defined message and AVP types. Each message type entry in the table below indicates: the integer value assigned to the message type; the message type abbreviation used in the AVP Summary Table of Sec. 5.5; and the full name of the message type. The integer value assigned to each message type is placed in the Value field of the Message Type AVP. This AVP MUST be the first AVP in a message. The currently defined control message types, grouped by function, are: Control Connection Management 1 (SCCRQ) Start-Control-Connection-Request 2 (SCCRP) Start-Control-Connection-Reply 3 (SCCCN) Start-Control-Connection-Connected 4 (StopCCN) Stop-Control-Connection-Notification 5 (reserved) 6 Hello Call Management 7 (OCRQ) Outgoing-Call-Request 8 (OCRP) Outgoing-Call-Reply 9 (OCCN) Outgoing-Call-Connected 10 (ICRQ) Incoming-Call-Request 11 (ICRP) Incoming-Call-Reply 12 (ICCN) Incoming-Call-Connected 13 (reserved) 14 (CDN) Call-Disconnect-Notify Error Reporting 15 (WEN) WAN-Error-Notify PPP Session Control 16 (SLI) Set-Link-Info 5.5 AVP Summary The following table lists all standard L2TP attributes currently defined. The "Attr" column indicates the integer value assigned to this attribute. The "M" column indicates the setting of the Valencia expires February 1998 [Page 18] INTERNET DRAFT August 1997 "Mandatory" bit of the AVP header for each attribute. The "Len" field indicates the size of the AVP including the AVP header. A "+" in this column indicates that the length varies depending upon the length of the actual contents of the value field. The "(usage)" list for each entry indicates the message types that utilize each AVP (See command table of Sec. 5.4). An abbreviation shown in mixed or upper case letters indicates that the corresponding AVP MUST be present in this message type; All lower case indicates that the AVP may optionally appear in this message type. A "+" appended to a message type abbreviation indicates that the AVP is only mandatory in a "positive" (non-error) condition -- The AVP is optional in a message indicating an error condition. A brief summary of the type and contents of the value field for each attribute is also given for each entry. Refer to the individual message type descriptions that appear in Section 6 for further details about the use of a particular AVP in a particular message type. Attr M Len Attribute Name (usage) 0 1 8 Message Type (ALL MESSAGES) 16 bit integer value indicating the message type, as defined in table above. MUST be the first AVP in each message 1 1 10+ Result Code (CDN, ICRP, OCCN, OCRP, SCCRP, StopCCN) 16 bit Integer value indicating result of corresponding request or reason for issuing a request, 16 bit integer General Error code and an optional ASCII string error message. See Result and General Error code tables below. 2 1 8 Protocol Version (SCCRP, SCCRQ) 8 bit L2TP Protocol and Revision numbers 3 1 10 Framing Capabilities (SCCRP, SCCRQ) 32 bit bitmask indicating supported framing types (e.g., synchronous and asynchronous) 4 1 10 Bearer Capabilities (SCCRP, SCCRQ) 32 bit bitmask indicating supported bearer types (e.g., analog and digital) 5 0 14 Tie Breaker (sccrq) 8 byte value used to break control connection establishment collisions 6 0 8 Firmware Revision (SCCRP, SCCRQ) 16 bit integer representing vendor's firmware revision 7 0 6+ Host Name (SCCRP, SCCRQ) ASCII string name (e.g., DNS name) of issuer Valencia expires February 1998 [Page 19] INTERNET DRAFT August 1997 8 0 6+ Vendor Name (SCCRP, SCCRQ) ASCII string describing issuing device 9 1 8 Assigned Tunnel ID (SCCRP+, SCCRQ, StopCCN) 16 bit integer tunnel ID assigned by sender 10 1 8 Receive Window Size (ICCN, ICRP, OCCN, OCRQ, SCCRP, SCCRQ) 16 bit integer receive window size offered by sender for a given call or control session 11 1 6+ Challenge (SCCRP, SCCRQ) 1 or more octet value issued by sender wishing to authenticate control session peer 12 0 9+ Q.931 Cause Code (CDN, OCCN) 16 bit cause code, 1 octet cause message, and optional ASCII advisory message 13 1 22 Challenge Response (SCCCN, SCCRP) 16 octet CHAP type response to peer's Challenge 14 1 8 Assigned Call ID (CCRQ, CDN, ICRP+, ICRQ, OCRP+, OCRQ) 16 bit integer ID assigned to a call by sender 15 1 6+ Call Serial Number (ICRQ, OCRQ) 1 or more octet identifier assigned to a call 16 1 10 Minimum BPS (OCRQ) 32 bit integer indicating lowest acceptable line speed for call 17 1 10 Maximum BPS (OCRQ) 32 bit integer indicating highest acceptable line speed for call 18 1 10 Bearer Type (ICRQ, OCRQ) Indicates bearer type (i.e., analog or digital) for call 19 1 10 Framing Type (ICCN, OCCN+, OCRQ) Indicates framing type (i.e., synchronous or asynchronous) for call 20 1 8 Packet Processing Delay (ICCN, ICRP, OCCN, OCRQ) 16 bit integer estimate of processing time of full window of received packets by sender 21 1 6+ Dialed Number (ICRQ, OCRQ) ASCII string phone number called or to be called 22 1 6+ Dialing Number (ICRQ) ASCII string phone number of caller 23 1 6+ Sub-Address (ICRQ, OCRQ) ASCII string containing additional dialing information Valencia expires February 1998 [Page 20] INTERNET DRAFT August 1997 24 1 10 Connect Speed (ICCN, OCCN+, OCRP+) 16 bit integer actual line speed of connection 25 1 10 Physical Channel ID (ICRQ, OCRP) 16 bit vendor specific physical device identifier used for call 26 0 6+ Initial LCP Confreq (ICCN) Octet string containing initial CONFREQ received from client 27 0 6+ Last Sent LCP Confreq (ICCN) Octet string containing final CONFREQ sent to client 28 0 6+ Last Received LCP Confreq (ICCN) Octet string containing final CONFREQ received from client 29 1 8 Proxy Authen Type (ICCN) 16 bit integer code indicating client authentication type negotiated (e.g., PAP, CHAP) 30 0 6+ Proxy Authen Name (ICCN) ASCII string containing name returned by client in authentication response 31 0 6+ Proxy Authen Challenge (ICCN) Octet string Challenge presented by LAC to client 32 0 8 Proxy Authen ID (ICCN) 16 bit integer of which low order octet is ID presented to client with Challenge. High order octet must be 0. 33 1 6+ Proxy Authen Response (ICCN) Octet string CHAP response or ASCII string password depending on authentication type used 34 1 32 Call Errors (WEN) A reserved 16 bit word set to 0 followed by 6 32 bit integer connection error counters 35 1 16 ACCM (SLI) A reserved 16 bit word set to 0 followed by 2 32 bit bitmasks containing Send and Receive ACCM values respectively 36 1 6+ Random Vector (all messages) Variable length octet string containing a random sequence of values used to accomplish the optional "hiding" of other AVP values (See "H" bit description in Sec. 5.7). 37 1 6+ Private Group ID (ICRQ, ICCN, OCRQ) Variable length octet value used by the LAC or LNS to indicate that this call is to be associated with a particular customer group. 5.6 Result and Error Code Summary Valencia expires February 1998 [Page 21] INTERNET DRAFT August 1997 In general, all Reply Message types contain a Result Code AVP which indicates the result of the requested operation. The Result Code can indicate that additional information pertaining to an error situation can be found in the Error Code field of the Result Code AVP. The meaning of the result code is tabulated under the specific type of message containing the result. Each 16-bit Result Code is immediately followed (in the same AVP) by a 16-bit General Error code value. General error codes pertain to types of errors which are not specific to any particular L2TP request, but rather to protocol or message format errors. If an L2TP reply indicates in its Result Code that a general error occurred, the General Error value should be examined to determine what the error was. The currently defined General Error codes and their meanings are: 0 - No general error 1 - No control connection exists yet for this LAC-LNS pair 2 - Length is wrong 3 - One of the field values was out of range or reserved field was non-zero 4 - Insufficient resources to handle this operation now 5 - The Call ID is invalid in this context 6 - A generic vendor-specific error occurred in the LAC 7 - Try another. If LAC is aware of other possible LNS destinations, it should try one of them. This can be used to guide an LAC based on LNS policy, for instance, the existence of multilink PPP bundles. If the length of the Result Code AVP specifies that the Value field is more than four octets in length, the remaining bytes after the General Error Code field are an arbitrary string providing further (possibly human readable) text associated with the condition. Generally, when a General Error Code of 6 is used, additional information about the error will be included in the Optional Message field that follows the Error Code field in the Result Code AVP. 5.7 Hiding of AVP values The H ("Hidden") bit in the header of each AVP in a control message provides a mechanism to indicate to the receiving peer whether the contents of the AVP are hidden or present in cleartext. This feature can be used to hide sensitive control message data such as user passwords or user ID's. The H bit MUST NOT be set in the Random Vector AVP. The H bit MUST only be set if tunnel authentication was used and, therefore, a shared secret exists between the peers on either end of the tunnel. Therefore, the H bit MUST NOT be set in AVP's contained within the Start-Control-Connection-Request, -Reply, and -Connected messages. If the H bit is set in any AVP(s) in a given command message, a Random Vector AVP must also be present in the message and MUST precede the first AVP having an H-bit of 1. Valencia expires February 1998 [Page 22] INTERNET DRAFT August 1997 The following mechanism is applied to the contents of the value field of each AVP to which hiding is to be applied. An MD5 hash is performed on the concatenation of: - the 2 octet Attribute number of the AVP - the shared authentication secret - and an arbitrary length random vector The value of the random vector used in this hash is passed in the value field of a Random Vector AVP. This Random Vector AVP must be placed in the message by the sender before any hidden AVPs. The same random vector can be used for more than one hidden AVP in the same message. If a different random vector is used for the hiding of subsequent AVPs then a new Random Vector AVP must be placed in the command message before the first AVP to which it applies. A value to be hidden MAY be padded with additional octets to obscure its actual length. The subformat of the AVP's value is indicated below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Padding ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length This is length of the Value to be obscured in octets. This is Value Value to be obscured Padding Random additional bytes used to obscure length of Value. The MD5 hash value is then XORed with the first 16 octet or less segment of the Value and placed in the Value field of the AVP. If the Value is less than 16 octets, the Value is transformed as if the Value field had been padded to 16 octets before the XOR, but only the actual bytes present in the Value are modified, and the length of the AVP is not altered. If the value is longer than 16 octets, a second one-way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the result of the first XOR. That hash is XORed with the second 16 octet or less segment of the value and placed in the corresponding octets of the Value field of the AVP. If necessary, this operation is repeated, with each XOR result being used along with the shared secret to generate the next hash to XOR the next segment of the value with. This technique results in the content of the AVP being obscured, although the length of the AVP is still known. On receipt, the random vector is taken from the last Random Vector AVP encountered in the message prior to the AVP to be unhidden. Valencia expires February 1998 [Page 23] INTERNET DRAFT August 1997 The above process is then reversed to yield the original value. For more details on this hiding method, consult the RADIUS [8] RFC. The Random Vector AVP has the following format: Random Vector 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 6 + String length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 36 | Random Octet String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Random Vector AVP may be used in any message type. The Attribute value is 36 and it is marked mandatory. It is used to enable the hiding of the values of arbitrary AVPs. It MUST precede any AVP containing an AVP with the H-bit set but it MUST NOT itself have the H-bit set. More than one Random Vector AVP may appear in a message, in which case the one most closely preceding an AVP with the H-bit set pertains to that AVP. The Random Octet String is the random vector value to use in computing the MD5 hash to retrieve the original value of a hidden AVP. This string can be of arbitrary length, although a random vector of at least 16 octets is recommended. 6.0 Control Connection Protocol Specification Control Connection messages are used to establish and clear user sessions. The first set of Control Connection messages are used to maintain the control connection itself. The control connection is initiated by an LAC or LNS after establishing the underlying tunnel- over-media connection. 6.0.1 Control Connection Collision For the case where an LAC and LNS both initiate tunnels to each other concurrently, and where the LAC and LNS both determine that a single tunnel suffices (generally because of media characteristic considerations, for instance, whether individual tunnels are needed to gain QOS guarantees for each tunnel), a "tie breaker" may be undertaken. The details of breaking a tie are documented with the tunnel establishment messages (Sec. 6.1). 6.0.2 Reliable Delivery of Control Messages Since L2TP may run across media where packets may be lost, an L2TP peer sending a control message will retransmit the control message after deciding that its remote peer has not received it. The reliable transport mechanism built into L2TP is essentially a lower layer transport service; the Nr and Ns fields of the control message header belong to this transport layer. The higher layer Valencia expires February 1998 [Page 24] INTERNET DRAFT August 1997 functions of L2TP are not concerned with retransmission or ordering of control messages. Each tunnel maintains a queue of control messages to be transmitted to the peer. The message at the front of the queue is sent with a given Ns value, and is held until a control message arrives from the peer in which the Nr field indicates receipt of this message. After a fixed (recommended default is 1 second) or adaptive (see Appendix D) timeout interval expires without receiving such an acknowledgment, the control message packet is retransmitted. The retransmitted packet contains the same Ns value, but the Nr value MUST be updated to reflect any packets received in the interim. If no peer response is detected after several retransmissions (a recommended default is 5, but may be altered due to media considerations), the tunnel and all sessions within MUST be cleared. When a tunnel is being shut down for reasons other than loss of connectivity, the state and reliable delivery mechanisms MUST be maintained and operated for the full retransmission interval after the final message exchange has occurred. This permits reliable delivery of closing messages in environments where these closing messages might be dropped. Unlike payload traffic, a peer MUST NOT withhold acknowledgment of packets as a technique for flow controlling control messages. An L2TP implementation is expected to be able to keep up with incoming control messages, possibly responding to some with errors reflecting an inability to honor the requested action. A sliding window mechanism is used, by default, for control message transmission. The default is to permit four control messages to be outstanding on a given tunnel. If a peer specifies a Receive Window Size AVP in the Start-Control-Connection-Request and -Reply packets, up to the indicated number of control messages may be sent and held outstanding. An implementation may only support a receive window of 1, but MUST accept at least a window of 4 from its peer. Unlike payload sessions, a value of 0 for the Receive Window Size AVP is invalid for a control session. The transport layer at a receiving peer is responsible for making sure that control messages are delivered in order to the higher layer and that duplicate messages are not delivered to the higher layer. Messages arriving out of order may be queued for in-order delivery when the missing messages are received or they may be discarded, requiring a retransmission. 6.0.3 Control Message Format The following Control Connection messages are all sent as packets on the established tunnel connection between a given LNS-LAC pair. All data is sent in network order (high order octets first). Any Valencia expires February 1998 [Page 25] INTERNET DRAFT August 1997 "reserved" or "empty" fields MUST be sent as 0 values to allow for protocol extensibility. Each control message has a header, specified in section 5.2, including an AVP indicating the type of control message, followed by zero or more AVP's appropriate for the given type of control message. Each control message is described first at a block level, and then with details of each AVP. 6.1 Start-Control-Connection-Request (SCCRQ) The Start-Control-Connection-Request is an L2TP control message used to initialize the tunnel between an LNS and an LAC. The tunnel must be initialized through the exchange of these control messages before any other L2TP messages can be issued. The establishment of the control connection is started by the initiator of the underlying tunnel. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start-Control-Connection-Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Version | | Framing Capabilities | | Bearer Capabilities | | Tie Breaker | | Firmware Revision | | Host Name | | Vendor Name | | Assigned Tunnel ID | | Receive Window Size | | Challenge | +-+-+-+-+-+-+-+-+-+-+-+-+ Start-Control-Connection-Request 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 1, indicating Start- Control-Connection-Request. The Flags indicate a mandatory option. Details associated with this tunneled session follow in additional AVP's within the packet. Valencia expires February 1998 [Page 26] INTERNET DRAFT August 1997 Protocol Version 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | 0x01 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Protocol Version AVP within a Start-Control-Connection-Request packet indicates the L2TP protocol version available. The Attribute value is 2, indicating Protocol Version, and is marked mandatory. This AVP MUST be present. The Value field is a 16-bit hexadecimal value 0x100, indicating L2TP protocol version 1, revision 0. Framing Capabilities 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 |0|0|0|0|0|0|A|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Framing Capabilities AVP within a Start-Control-Connection- Request indicates the type of framing that the sender of this message can provide. The Attribute value is 3, indicating Framing Capabilities, and is marked mandatory. This AVP MUST be present. The Value field is a 32-bit quantity, with two bits defined. If bit A is set, asynchronous framing is supported. If bit S is set, synchronous framing is supported. Bearer Capabilities 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 |0|0|0|0|0|0|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Bearer Capabilities AVP within a Start-Control-Connection- Request indicates the bearer capabilities that the sender of this message can provide. The Attribute value is 4, indicating Bearer Capabilities, and is marked mandatory. This AVP MUST be present. The Value field is a 32-bit quantity with two bits defined. If Valencia expires February 1998 [Page 27] INTERNET DRAFT August 1997 bit A is set, analog access is supported. If bit D is set, digital access is supported. Tie Breaker 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 14 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | Tie Break Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...(64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Tie Breaker AVP within a Start-Control-Connection-Request contains a 64-bit Value used to break ties in tunnel establishment between an LAC-LNS pair. The Attribute value is 5, indicating Tie Breaker, and is marked optional. This AVP itself is optional. The 8 byte Value is used as a 64-bit tie breaker value. If present, it indicates the sender wishes a single tunnel to exist between the given LAC-LNS pair, and this value will be used to choose a single tunnel where both LAC and LNS initiate a tunnel concurrently. The recipient of a Start-Control-Connection-Request must check to see if a Start-Control-Connection-Request has been sent to the peer, and if so, must compare its Tie Breaker value with the received one. The lower value "wins", and the "loser" MUST initiate a tunnel disconnect for their outstanding tunnel. In the case where a tie breaker is present on both sides, and the value is equal, both sides MUST initiate tunnel disconnects. If a tie breaker is received, and the outstanding Start-Control- Connection-Request had no tie breaker value, the initiator which included the Tie Breaker AVP "wins". It is recommended that the Value be set to the MAC address of a LAN interface on the sender. If no MAC address is available, a 64-bit random number should be used instead. Firmware Revision 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | Firmware Revision | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Firmware Revision AVP within a Start-Control-Connection- Request indicates the firmware revision of the issuing device. Valencia expires February 1998 [Page 28] INTERNET DRAFT August 1997 The Attribute value is 6, indicating Firmware Revision, and is marked optional. This AVP itself is optional. The Value field is a 16-bit integer encoded in a vendor specific format. For devices which do not have a firmware revision (general purpose computers running L2TP software modules, for instance), the revision of the L2TP software module may be reported instead. Host Name 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 6 + Host name length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | Host name... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Host Name AVP within a Start-Control-Connection-Request indicates the name of the issuing LAC or LNS. The Attribute value is 7, indicating Host Name, and is marked mandatory. This AVP itself MUST be present. This name should be as broadly unique as possible; for hosts participating in DNS [4], a hostname with fully qualified domain would be appropriate. Vendor Name 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|6 + vendor name length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 8 | Vendor name... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Vendor Name AVP within a Start-Control-Connection-Request contains a vendor specific string describing the type of LAC or LNS being used. The Attribute value is 8, indicating Vendor Name, and is marked optional. This AVP itself is optional. The Value is the indicated number of bytes representing the vendor string. Assigned Tunnel ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Assigned Tunnel ID AVP within a Start-Control-Connection- Request specifies the Tunnel ID which the receiving peer MUST use in the Tunnel ID field of all subsequent packets. The Attribute value is 9, indicating Assigned Tunnel ID, and is marked Valencia expires February 1998 [Page 29] INTERNET DRAFT August 1997 mandatory. This AVP MUST be present. Before the Assigned Tunnel ID AVP is received, packets MUST be sent with a Tunnel ID value of 0. The Value is a 16-bit non-zero Tunnel ID value. Receive Window Size 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10 | Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Receive Window Size AVP within a Start-Control-Connection- Request specifies the receive window size being offered to the remote peer. The Attribute value is 10, indicating Receive Window Size, and is mandatory. This AVP itself is optional. Value is a 16-bit word indicating the offered window size. If absent, the peer must assume a value of 4 for its transmit window. The remote peer may send the specified number of control messages before it must wait for an acknowledgment. Challenge 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 6 + Challenge length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 11 | Challenge... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Challenge AVP within a Start-Control-Connection-Request indicates that the issuing peer wishes to authenticate the tunnel endpoints using a CHAP-style authentication mechanism. The Attribute value is 11, indicating Challenge, and is marked mandatory. This AVP is optional. The Value is one or more octets of challenge value. 6.2 Start-Control-Connection-Reply (SCCRP) The Start-Control-Connection-Reply is an L2TP control message sent in reply to a received Start-Control-Connection-Request message. This message contains a result code indicating the result of the control connection establishment attempt. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start-Control-Connection-Reply | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Version | | Result Code | Valencia expires February 1998 [Page 30] INTERNET DRAFT August 1997 | Framing Capabilities | | Bearer Capabilities | | Firmware Revision | | Host Name | | Vendor Name | | Assigned Tunnel ID | | Receive Window Size | | Challenge | | Challenge Response | +-+-+-+-+-+-+-+-+-+-+-+-+ Start-Control-Connection-Reply 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 2, indicating Start- Control-Connection-Reply. The Flags indicate a mandatory option. Protocol Version 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | 0x01 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Protocol Version AVP within a Start-Control-Connection-Reply packet indicates the L2TP protocol version available. The Attribute value is 2, indicating Protocol Version, and the Value field is a 16-bit hexadecimal value 0x100, indicating L2TP protocol version 1, revision 0. This AVP MUST be present. Framing Capabilities 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 |0|0|0|0|0|0|A|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Framing Capabilities AVP within a Start-Control-Connection- Reply indicates the type of framing that the sender of this Valencia expires February 1998 [Page 31] INTERNET DRAFT August 1997 message can provide. The Attribute is 3, it is a mandatory AVP, the Value field is a 32-bit quantity, with two bits defined. If bit A is set, asynchronous framing is supported. If bit S is set, synchronous framing is supported. This AVP MUST be present if the Result AVP indicates success. Bearer Capabilities 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 |0|0|0|0|0|0|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Bearer Capabilities AVP within a Start-Control-Connection- Reply indicates the bearer capabilities that the sender of this message can provide. The Attribute is 4, it is a mandatory AVP, the Value field is a 32-bit quantity with two bits defined. If bit A is set, analog access is supported. If bit D is set, digital access is supported. This AVP MUST be present if the Result AVP indicates success. Firmware Revision 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | Firmware Revision | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Firmware Revision AVP within a Start-Control-Connection-Reply indicates the firmware revision of the issuing device. The Attribute is 6, it is not a mandatory AVP, the Value field is a 16-bit integer encoded in a vendor specific format. For devices which do not have a firmware revision (general purposes computers running L2TP software modules, for instance), the revision of the L2TP software module may be reported instead. This AVP is optional. Host Name 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 6 + Host name length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | Host name... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires February 1998 [Page 32] INTERNET DRAFT August 1997 The Host Name AVP within a Start-Control-Connection-Reply indicates the name of the issuing LAC or LNS. See the notes in section 6.1 concerning Host Name contents. It is encoded as the Attribute 7, mandatory, with the indicated number of bytes representing the host name string. This AVP MUST be present. Vendor Name 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|6 + Vendor name length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 8 |Vendor name... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Vendor Name AVP within a Start-Control-Connection-Reply contains a vendor specific string describing the type of LAC or LNS being used. It is encoded as the Attribute 8, not mandatory, with the indicated number of bytes representing the vendor string. This AVP is optional. Assigned Tunnel ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Assigned Tunnel ID AVP within a Start-Control-Connection-Reply specifies the Tunnel ID which the receiving peer MUST use in all subsequent packets. It is encoded as the Attribute 9, mandatory, with a 16-bit non-zero Tunnel ID value. This AVP MUST be present if the Result Code indicates "Successful channel establishment". Receive Window Size 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10 | size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Receive Window Size AVP within a Start-Control-Connection- Reply specifies the receive window size being offered to the remote peer. The Attribute value is 10, indicating Receive Window Size, and is mandatory. This AVP itself is optional. Value is a 16-bit word indicating the offered window size. If absent, the peer must assume a value of 4 for its transmit window. The remote Valencia expires February 1998 [Page 33] INTERNET DRAFT August 1997 peer may send the specified number of control messages before it must wait for an acknowledgment. Result Code 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 + Message length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | Optional Message ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Result Code AVP within a Start-Control-Connection-Reply packet indicates the result of the control channel establishment attempt. It is encoded as Attribute 1, indicating a Result Code AVP. This AVP is mandatory and MUST be present. The Result Code is a 16-bit word. The 16-bit word following the Result Code field contains the Error Code value. The Result Code value indicates whether the Error Code value is meaningful or not. If it is not meaningful it MUST be set to a value of 0. An optional error message can follow the Error Code field. Its presence and length is indicated by the value of the AVP length field. Result code values are: 1 - Successful channel establishment 2 - General error--Error Code indicates the problem 3 - Control channel already exists 4 - Requester is not authorized to establish a control channel 5 - The protocol version of the requester is not supported Challenge 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 6 + Challenge length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 11 | Challenge... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Challenge AVP within a Start-Control-Connection-Reply indicates that the peer wishes to authenticate the tunnel initiator using a CHAP-style authentication mechanism. It is encoded as the Attribute 11, mandatory, with at least one byte of challenge value embedded. If this AVP is not present, it indicates to the receiving peer that the sender does not wish to authenticate that peer. Challenge Response 0 1 2 3 Valencia expires February 1998 [Page 34] INTERNET DRAFT August 1997 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 22 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 13 | Response... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response... (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Response AVP within a Start-Control-Connection-Reply packet provides a response to a challenge received. The Attribute value is 13, indicating Response, and the Value field is a 128-bit value reflecting the CHAP-style response to the challenge. This AVP marked mandatory, and MUST be present if a challenge was received and this Start-Control-Connection-Reply indicates success. For purposes of the ID value in the CHAP response calculation, the value 2 (corresponding to the Value field of the Start-Control- Connection-Reply AVP) MUST be used. 6.3 Start-Control-Connection-Connected (SCCCN) The Start-Control-Connection-Connected message is an L2TP control message sent in reply to a received Start-Control-Connection-Reply message. This message provides closure to the tunnel establishment process, and includes a challenge response if the peer sent a challenge in the Start-Control-Connection-Reply message. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start-Control-Connection-Connected | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge Response | +-+-+-+-+-+-+-+-+-+-+-+-+ Start-Control-Connection-Connected 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 3, indicating Start- Control-Connection-Connected. The Flags indicate a mandatory option. Challenge Response 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires February 1998 [Page 35] INTERNET DRAFT August 1997 |1|0|0|0| 22 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 13 | Response... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response... (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Challenge Response AVP within a Start-Control-Connection- Connected packet provides a response to a challenge received. The Attribute value is 13, indicating Response, and the Value field is a 128-bit value reflecting the CHAP-style response to the challenge. This AVP is marked mandatory, and MUST be present if a challenge was received, otherwise MUST be omitted. For purposes of the ID value in the CHAP response calculation, the value 3 (corresponding to the Value field of the Start-Control- Connection-Connected AVP) MUST be used. 6.4 Stop-Control-Connection-Notification (StopCCN) The Stop-Control-Connection-Notification is an L2TP control message sent by one peer of an LAC-LNS control connection to inform the other peer that the control connection should be closed. In addition to closing the control connection, all active user calls are implicitly cleared. The reason for issuing this request is indicated in the Result Code AVP. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stop-Control-Connection-Notification| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Tunnel ID | | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+ Stop-Control-Connection-Notification AVP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 4, indicating Stop- Control-Connection-Notification. The Flags indicate a mandatory option. Assigned Tunnel ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires February 1998 [Page 36] INTERNET DRAFT August 1997 |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute value is 9, indicating Assigned Tunnel ID, and is marked mandatory. This AVP MUST be present. The Value MUST be the same Assigned Tunnel ID first sent to the receiving peer. This AVP permits the peer to identify the appropriate tunnel even if Stop-Control-Connection-Notification must be sent before an Assigned Tunnel ID is received. Result Code 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 + Message length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | Optional Message ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Result Code AVP within a Stop-Control-Connection-Notification packet indicates the reason for terminating the control channel. It is encoded as Attribute 1, indicating a Result Code AVP. This AVP is mandatory and MUST be present. The Result Code is a 16-bit word. The 16-bit word following the Result Code field contains the Error Code value, which for a Stop-Control-Connection- Notification is always 0. An optional message can follow the Error Code field. Its presence and length is indicated by the value of the AVP length field. Defined Result Code values are: 1 - General request to clear control connection 2 - General error--Error Code indicates the problem 3 - Control channel already exists 4 - Requester is not authorized to establish a control channel 5 - The protocol version of the requester is not supported Error Code indicates highest version supported 6 - Requester is being shut down 7 - Finite State Machine error 6.5 (reserved) The function previously described here has been deleted from L2TP. 6.6 Hello The Hello message is an L2TP control message sent by either peer of a LAC-LNS control connection. This control message is used as a "keepalive" for the tunnel. Keepalives should be implemented by sending a Hello once every 60 Valencia expires February 1998 [Page 37] INTERNET DRAFT August 1997 seconds if 60 seconds have passed without receiving any message (payload or control, including zero-length messages) from the peer. When a Hello is received, it MUST be silently discarded (after updating any effects of the indicated Nr/Ns values). Because a Hello is a control message, and control messages are reliably sent by the lower level transport, this keepalive function operates by causing the transport level to reliably deliver a message. If a media interruption has occurred, the reliable transport will be unable to deliver the Hello across, and will clean up the tunnel. Hello messages are global to the tunnel; the Call ID field of these control messages MUST be 0. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hello | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hello 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 6, indicating Hello The Flags indicate a mandatory option. 6.7 Outgoing-Call-Request (OCRQ) The Outgoing-Call-Request is an L2TP control message sent by the LNS to the LAC to indicate that an outbound call from the LNS is to be established. This request provides the LAC with information required to make the call. It also provides information to the LAC that is used to regulate the transmission of data to the LNS for this session once it is established. This message is the first in the "three-way handshake" used by L2TP for establishing outgoing calls. The first message requests the call; the second indicates that the call was successfully initiated. The third and final message indicates that the call was established. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outgoing-Call-Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Call ID | Valencia expires February 1998 [Page 38] INTERNET DRAFT August 1997 | Call Serial Number | | Minimum BPS | | Maximum BPS | | Bearer Type | | Framing Type | | Receive Window Size | | Packet Processing Delay | | Dialed Number | | Sub-Address | | Private Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+ Outgoing-Call-Request 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 7, indicating Outgoing- Call-Request. The Outgoing-Call-Request encodes a request to an LAC to establish an outgoing call. The flags indicate a mandatory option. Assigned Call ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 14 | Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Assigned Call ID AVP encodes the ID being assigned to this call by the LNS. The Attribute value is 14, indicating Assigned Call ID, and is marked mandatory. This AVP MUST be present. The LAC places this value in the Call ID header field of all command and payload packets that it subsequently transmits over the tunnel that belong to this call. The Call ID value is an identifier assigned by the LNS to this session. It is used to multiplex and demultiplex data sent over that tunnel between the LNS and LAC. Call Serial Number 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 6 + Number length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 15 | Number... Valencia expires February 1998 [Page 39] INTERNET DRAFT August 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Call Serial Number AVP encodes an identifier assigned by the LNS to this call. Attribute is 15, indicating Call Serial Number, and is marked mandatory. This AVP MUST be present. The Call Serial Number is intended to be an easy reference for administrators on both ends of a tunnel to use when investigating call failure problems. Call Serial Numbers should be set to progressively increasing values, which are likely to be unique for a significant period of time across all interconnected LNS and LACs. Other identification information may also be prepended. Minimum BPS 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16 | BPS (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BPS (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Minimum BPS AVP encodes the lowest acceptable line speed for this call. Attribute is 16, Minimum BPS, and is marked mandatory. This AVP MUST be present. The BPS value indicates the speed in bits/second. Maximum BPS 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 17 | BPS (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BPS (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum BPS AVP encodes the highest acceptable line speed for this call. Attribute is 17, indicating Maximum BPS, and is marked mandatory. This AVP MUST be present. The BPS value indicates the speed in bits/second. Bearer Type 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires February 1998 [Page 40] INTERNET DRAFT August 1997 | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bearer Type AVP encodes the bearer type for the requested call. The value bit field Attribute is 18, indicating Bearer Type, and is marked mandatory. This AVP MUST be present. The Value is a 32-bit quantity indicating the bearer capability required for this outgoing call. If set, bit A indicates that the call should be on an analog channel. If set, bit D indicates that the call should be on a digital channel. Both may be set, indicating that the call can be of either type. Framing Type 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Framing Type AVP encodes the framing type for the requested call. Attribute is 19, indicating Framing Type, and is marked mandatory. This AVP MUST be present. The 32-bit field indicates the type of PPP framing to be used for the outgoing call. Bit A if set indicates that asynchronous framing should be used. Bit S is set indicates that synchronous framing should be used. Receive Window Size 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10 | Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Receive Window Size AVP encodes the window size being advertised by the LNS for this call. Attribute is 10, indicating Receive Window Size, and is marked mandatory. This AVP is optional. The Size value indicates the number of received data packets the LNS will buffer for this call, which is also the maximum number of data packets the LAC should send before waiting for an acknowledgment. The absence of this AVP indicates that Sequence and Acknowledgment Numbers are not to be used in the payload session for this call. Packet Processing Delay Valencia expires February 1998 [Page 41] INTERNET DRAFT August 1997 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 20 | Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Packet Processing Delay AVP encodes the delay LNS has for processing a window full of packets sent by the LAC. Attribute is 20, indicating Packet Processing Delay, and is marked mandatory. This AVP is optional. The Delay value is specified in units of 1/10 seconds. Refer to Appendix A for a description of how this value is determined and used. Dialed Number 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|6 + Phone Number length| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 21 | Phone Number.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Phone Number AVP encodes the phone number to be called. Attribute is 21, indicating Phone Number, and is marked mandatory. This AVP MUST be present. The Phone Number value is an ASCII string. Sub-Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|6 + Sub-Address length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 23 |Sub-Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Address AVP encodes additional dialing information. Attribute is 23, indicating Sub-Address, and is marked mandatory. This AVP is optional. The Sub-Address value is an ASCII string. Private Group ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 6 + Private Group ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 37 | Private Group ID ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Private Group ID AVP is sent by the LNS to the LAC to indicate Valencia expires February 1998 [Page 42] INTERNET DRAFT August 1997 that a particular call is to be treated specially, for example, to select a particular port group or exchange carrier. The Attribute is 37, Private Group ID, and is marked optional. The presence of this AVP is optional. The Private Group ID is a string corresponding to a table in the LAC that defines the particular characteristics of the selected group. 6.8 Outgoing-Call-Reply (OCRP) The Outgoing-Call-Reply is an L2TP control message sent by the LAC to the LNS in response to a received Outgoing-Call-Request message. The reply indicates whether or not the LAC is able to attempt the outbound call and also returns certain parameters regarding the call attempt. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outgoing-Call-Reply | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Call ID | | Result Code | | Connect Speed | | Physical Channel Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Outgoing-Call-Reply 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 8, indicating Outgoing- Call-Reply. The Outgoing-Call-Reply message encodes the immediate result of attempting an outgoing call request. The flags indicate a mandatory option. Assigned Call ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 14 | Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Assigned Call ID AVP encodes the ID being assigned to this call by the LAC. Attribute is 14, indicating Assigned Call ID, and is Valencia expires February 1998 [Page 43] INTERNET DRAFT August 1997 marked mandatory. This AVP MUST be present if the Result Code indicates a call is in progress. Call ID value is an identifier, unique within the tunnel, assigned by the sender to this session. The remote peer MUST place this Call ID in the Call ID portion of all future packets it sends associated with this session. It is used to multiplex and demultiplex data sent over that tunnel between the LNS and LAC. Result Code 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 + Message length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | Optional Message ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Result Code AVP within an Outgoing-Call-Request indicates the result of the outgoing call establishment attempt. It is encoded as Attribute 1, indicating a Result Code AVP. This AVP is mandatory and MUST be present. The Result Code is a 16-bit word. The 16-bit word following the Result Code field contains the Error Code value. The Result Code value indicates whether the Error Code value is meaningful or not. If it is not meaningful it should be set to a value of 0. An optional error message can follow the Error Code field. Its presence and length is indicated by the value of the AVP length field. Defined Result Code values are: 1 - Call attempt in progress 2 - Outgoing Call not attempted for the reason indicated in Error Code 3 - No appropriate facilities are available (temporary condition) 4 - No appropriate facilities are available (permanent condition) 5 - Invalid destination 6 - Outgoing Call administratively prohibited Connect Speed 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 24 | BPS (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BPS (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Connect Speed BPS AVP encodes the speed of the facility chosen for the connection attempt. The Attribute value is 24, indicating Valencia expires February 1998 [Page 44] INTERNET DRAFT August 1997 Connect Speed, and is marked mandatory. This AVP MUST be present if the Result indicates a call is in progress. The BPS is a 32- bit value indicating the speed in bits/second. Physical Channel ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 25 | ID (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Physical Channel ID AVP encodes the vendor specific physical channel number used for the call. The Attribute value is 25, indicating Physical Channel ID, and is marked optional. This AVP itself is optional. ID is a 32-bit value in network byte order. The value is used for logging purposes only. 6.9 Outgoing-Call-Connected (OCCN) Outgoing-Call-Connected is an L2TP control message sent by the LAC to the LNS to indicate the result of a requested outgoing call. The LAC MUST send the corresponding Outgoing-Call-Reply to the LNS before sending this message. This message provides information to the LNS about the particular parameters used for the call. It provides information to allow the LNS to regulate the transmission of data to the LAC for this session. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outgoing-Call-Connected | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | | Q.931 Cause Code | | Connect Speed | | Framing Type | | Receive Window Size | | Packet Processing Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Outgoing-Call-Connected 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires February 1998 [Page 45] INTERNET DRAFT August 1997 The Message Type AVP contains a Value of 9, indicating Outgoing- Call-Connected. The Outgoing-Call-Connected message encodes the final result of an outgoing call request. The flags indicate a mandatory option. Result Code 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 + Message length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | Optional Message ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Result Code AVP within an Outgoing-Call-Connected message indicates the final result of the outgoing call establishment attempt. It is encoded as Attribute 1, indicating a Result Code AVP. This AVP is mandatory and MUST be present. The Result Code is a 16-bit word. The 16-bit word following the Result Code field contains the Error Code value. The Result Code value indicates whether the Error Code value is meaningful or not. If it is not meaningful it should be set to a value of 0. An optional error message can follow the Error Code field. Its presence and length is indicated by the value of the AVP length field. Defined Result Code values are: 1 - Call established with no errors 2 - Outgoing Call not established for the reason indicated in Error Code 3 - Outgoing Call failed due to no carrier detected 4 - Outgoing Call failed due to detection of a busy signal 5 - Outgoing Call failed due to lack of a dial tone 6 - Outgoing Call was not established within time allotted by LAC 7 - Outgoing Call was connected but no appropriate framing was detected Q.931 Cause Code 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|9 + Advisory Msg length| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 12 | Cause Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Msg |Advisory Msg... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Q.931 Cause Code AVP is used to give additional information in cases of call failure. The Attribute value is 12, indicating Cause Code, and is marked mandatory. This AVP is optional. It is only relevant when the LAC uses Q.931/DSS1 for the outbound call attempt. Cause Code is the returned Q.931 Cause code and Cause Valencia expires February 1998 [Page 46] INTERNET DRAFT August 1997 Msg is the returned Q.931 message code (e.g., DISCONNECT) associated with the Cause Code. Both values are returned in their native ITU encodings. An additional ASCII text Advisory Message may also be included (presence indicated by the AVP length) to further explain the call failure. Connect Speed 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 24 | BPS (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BPS (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Connect Speed BPS AVP encodes the final negotiated speed for the connection. The Attribute value is 24, indicating Connect Speed, and is marked mandatory. This AVP MUST be present if the call attempt is successful. The BPS value indicates the speed in bits/second. Framing Type 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Framing Type AVP encodes the framing type for the call. The Attribute value is 19, indicating Framing Type, and is marked mandatory. This AVP MUST be present if the call attempt is successful. The value bit field indicates the type of PPP framing is used for the call. If set, bit A indicates that asynchronous framing is being used. If set, bit S indicates that synchronous framing is being used. Receive Window Size 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10 | Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires February 1998 [Page 47] INTERNET DRAFT August 1997 Receive Window Size AVP encodes the window size being offered by the LNS for this call. The Attribute value is 10, indicating Receive Window Size, and is marked mandatory. The Size is a 16- bit value indicating the number of received data packets the LAC will buffer for this call, which is also the maximum number of data packets the LNS should send before waiting for an acknowledgment. This AVP MUST be present if and only if Sequence and Acknowledgment Numbers are to be used in the payload session for this call. Packet Processing Delay 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 20 | Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet Processing Delay AVP encodes the delay the LAC expects for processing a window full of packets sent by the LNS. The Attribute value is 20, indicating Packet Processing Delay, and is marked mandatory. This AVP is optional. The Delay value is specified in units of 1/10 seconds. Refer to Appendix A to see a description of how this value is determined and used. 6.10 Incoming-Call-Request (ICRQ) Incoming-Call-Request is an L2TP control message sent by the LAC to the LNS to indicate that an inbound call is to be established from the LAC. This request provides the LNS with parameter information for the incoming call. This message is the first in the "three-way handshake" used by L2TP for establishing incoming calls. The LAC may defer answering the call until it has received an Incoming-Call-Reply from the LNS indicating that the call should be established. This mechanism allows the LNS to obtain sufficient information about the call before it is answered to determine whether the call should be answered or not. Alternatively, the LAC may answer the call, negotiate LCP and PPP authentication, and use the information gained to choose the LNS. In this case, the call has already been answered by the time the Incoming-Call-Reply message is received; the LAC simply spoofs the "call indication/answer call" phase in this case. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Incoming-Call-Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Call ID | | Call Serial Number | | Bearer Type | Valencia expires February 1998 [Page 48] INTERNET DRAFT August 1997 | Physical Channel ID | | Dialed Number | | Dialing Number | | Sub-Address | | Private Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Incoming-Call-Request 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 10, indicating Incoming- Call-Request. The Incoming-Call-Request message encodes an incoming call being indicated by the LAC. The flags indicate a mandatory option. Assigned Call ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 14 | Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Assigned Call ID AVP encodes the Call ID being assigned to call by the LAC. The Attribute value is 14, indicating Call ID, and is marked mandatory. This AVP MUST be present. The LNS places this value in the Call ID header field of all command and payload packets that it subsequently transmits over the tunnel that belong to this call. The Call ID value is an identifier assigned by the LAC to this session. It is used to multiplex and demultiplex data sent over that tunnel between the LNS and LAC. Call Serial Number 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 6 + Number length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 15 | Number... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Call Serial Number AVP encodes an identifier assigned by the LAC to this call. The Attribute value is 15, Call Serial Number, and is marked mandatory. This AVP MUST be present. Please refer to the Valencia expires February 1998 [Page 49] INTERNET DRAFT August 1997 description of this field from section 6.8. Bearer Type 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 18 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bearer Type AVP encodes the bearer type for the incoming call. The Attribute value is 18, Bearer Type, and is marked mandatory. This AVP MUST be present. The Value is a 32-bit field indicating the bearer capability being used by the incoming call. If set, bit A indicates that the call is on an analog channel. If set, bit D indicates that the call is on a digital channel. Physical Channel ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 25 | ID (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Physical Channel ID AVP encodes the vendor specific physical channel number used for the call. The Attribute value is 25, Physical Channel ID, and is marked mandatory. The presence of this AVP is optional. ID is a 32-bit value in network byte order. The value is used for logging purposes only. Dialed Number 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|6 + Phone Number length| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 21 | Phone Number.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dialed Number AVP encodes the dialed number for the incoming call, that is, DNIS. The Attribute value is 21, Dialed Number, and is marked mandatory. The presence of this AVP is optional. The value is an ASCII string. Valencia expires February 1998 [Page 50] INTERNET DRAFT August 1997 Dialing Number 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|6 + Phone Number length| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 22 |Phone Number... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dialing Number AVP encodes the originating number for the incoming call, that is, CLID. The Attribute value is 22, Dialing Number, and is marked mandatory. The presence of this AVP is optional. The value is an ASCII string. Sub-Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0|6 + Sub-Address length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 23 |Sub-Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Address AVP encodes additional dialing information. The Attribute value is 23, Sub-Address, and is marked mandatory. The presence of this AVP is optional. The Sub-Address value is an ASCII string. Private Group ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 6 + Private Group ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 37 | Private Group ID ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The PrivateGroup ID AVP is used by the LAC to indicate that this call is to be associated with a particular customer group. The Attribute is 37, Private Group ID, and is marked optional. The presence of this AVP is optional. The LNS MAY treat the PPP session as well as network traffic through this session specially in a manner determined by the peer. For example, if the LNS is individually connected to several private networks using unregistered addresses, this AVP may be included by the LAC to indicate that a given call should be associated with one of the private networks. The Private Group ID is a string corresponding to a table in the LNS that defines the particular characteristics of the selected group. A LAC MAY determine the Private Group ID from a RADIUS response containing the PrivateGroupID attribute. Valencia expires February 1998 [Page 51] INTERNET DRAFT August 1997 The Private Group ID AVP MAY be included in either incoming call request or incoming call connected messages. This AVP SHOULD NOT be included in both messages. 6.11 Incoming-Call-Reply (ICRP) The Incoming-Call-Reply is an L2TP control message sent by the LNS to the LAC in response to a received Incoming-Call-Request message. The reply indicates the result of the incoming call attempt. It also provides information to allow the LAC to regulate the transmission of data to the LNS for this session. This message is the second in the three-way handshake used by L2TP for establishing incoming calls. It indicates to the LAC whether the call should be answered or not. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Incoming-Call-Reply | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Call ID | | Result Code | | Receive Window Size | | Packet Processing Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Incoming-Call-Reply 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 11, indicating Incoming- Call-Reply. The Incoming-Call-Reply message encodes a response by the LNS to the incoming call indication given by the LAC. The flags indicate a mandatory option. Assigned Call ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 14 | Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Assigned Call ID AVP encodes the ID being assigned to call by the LNS. The Attribute value is 14, Assigned Call ID, and is marked Valencia expires February 1998 [Page 52] INTERNET DRAFT August 1997 mandatory. This AVP MUST be present if the Result Code indicates the call was successful. The LAC places this value in the Call ID header field of all command and payload packets that it subsequently transmits over the tunnel that belong to this call. The Call ID value is an identifier assigned by the LNS to this session. It is used to multiplex and demultiplex data sent over that tunnel between the LNS and LAC. Result Code 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 + Message length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | Optional Message ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Result Code AVP within an Incoming-Call-Reply message indicates the result of the incoming call establishment attempt. It is encoded as Attribute 1, indicating a Result Code AVP. This AVP is mandatory and MUST be present. The Result Code is a 16-bit word. The 16-bit word following the Result Code field contains the Error Code value. The Result Code value indicates whether the Error Code value is meaningful or not. If it is not meaningful it should be set to a value of 0. An optional error message can follow the Error Code field. Its presence and length is indicated by the value of the AVP length field. Defined Result Code values are: 1 - The LAC should answer the incoming call 2 - The Incoming Call should not be established due to the reason indicated in Error Code 3 - The LAC should not accept the incoming call. It should hang up or issue a busy indication Receive Window Size 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10 | Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Message... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Receive Window Size AVP encodes the receive window size being offered by the LNS for this call. The Attribute value is 10, Receive Window Size, and is marked mandatory. The Size value indicates the number of received data packets the LNS will buffer Valencia expires February 1998 [Page 53] INTERNET DRAFT August 1997 for this call, which is also the maximum number of data packets the LAC should send before waiting for an acknowledgment. This AVP is optional if Sequence and Acknowledgment Numbers are not to be used in the payload session for this call, or if the Result AVP indicates failure. Packet Processing Delay 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 20 | Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet Processing Delay AVP encodes the delay the LNS expects for processing a window full of packets sent by the LAC. The Attribute value is 20, Packet Processing Delay AVP, and is marked mandatory. The presence of this AVP is optional. The Delay value is specified in units of 1/10 seconds. Refer to Appendix A to see a description of how this value is determined and used. 6.12 Incoming-Call-Connected (ICCN) The Incoming-Call-Connected message is an L2TP control message sent by the LAC to the LNS in response to a received Incoming-Call-Reply. It provides information to the LNS about particular parameters used for the call. It also provides information to allow the LNS to regulate the transmission of data to the LAC for this session. This message is the third in the three-way handshake used by L2TP for establishing incoming calls. It provides a mechanism for providing the LNS with additional information about the call that cannot, in general, be obtained at the time the Incoming-Call-Request is issued by the LAC. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Incoming-Call-Connected | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connect Speed | | Framing Type | | Receive Window Size | | Packet Processing Delay | | Initial LCP Confreq | | Last Sent LCP Confreq | | Last Received LCP Confreq | | Proxy authen type | | Proxy authen name | | Proxy authen challenge | | Proxy authen ID | | Proxy authen response | Valencia expires February 1998 [Page 54] INTERNET DRAFT August 1997 | Private Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Incoming-Call-Connected 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 12, indicating Incoming- Call-Connected. The Incoming-Call-Connected message encodes a response by the LAC to the Incoming-Call-Reply message sent by the LAC. The flags indicate a mandatory option. Connect Speed 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 24 | BPS (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BPS (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Connect Speed BPS AVP encodes the speed for the connection. The Attribute value is 24, Connect Speed, and is marked mandatory. This AVP MUST be present. The value is a 32-bit quantity indicating the speed in bits/second. Framing Type 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 19 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Framing Type AVP encodes the framing type for the call. The Attribute value is 19, Framing Type, and is marked mandatory. This AVP MUST be present. The value is a 32-bit bit field indicating the type of PPP framing used for the call. If set, bit A indicates that asynchronous framing is being used. If set, bit S indicates that synchronous framing is being used. Valencia expires February 1998 [Page 55] INTERNET DRAFT August 1997 Receive Window Size 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10 | Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Receive Window Size AVP encodes the window size being offered by the LAC for this call. The Attribute value is 10, Receive Window Size, and is marked mandatory. This AVP is optional if Sequence and Acknowledgment Numbers are not to be used in the payload session for this call. The 16-bit Size value indicates the number of received data packets the LAC will buffer for this call, which is also the maximum number of data packets the LNS should send before waiting for an acknowledgment. Packet Processing Delay 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 20 | Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet Processing Delay AVP encodes the delay the LAC expects for processing a window full of packets sent by the LNS. The Attribute value is 20, Packet Processing Delay, and is marked mandatory. The presence of this AVP is optional. The 16-bit Delay value is specified in units of 1/10 seconds. Refer to Appendix A to see a description of how this value is determined and used. Initial LCP Confreq 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|6 + LCP confreq length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 26 | LCP confreq... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LAC may have answered the phone call and negotiated LCP with the dial-in client in order to establish the client's apparent identity. In this case, this option may be included to indicate the link properties the client requested in its initial LCP CONFREQ request. The Attribute value is 26, Initial LCP Confreq, and is marked optional. The presence of this AVP is optional. The Value field is a copy of the body of the initial CONFREQ received, starting at the first option within this packet's body. Valencia expires February 1998 [Page 56] INTERNET DRAFT August 1997 Last Sent LCP Confreq 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|6 + LCP confreq length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 27 | LCP confreq... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See Initial LCP Confreq above for rationale. The Attribute value is 27, Last Sent LCP Confreq, and is marked optional. The presence of this AVP is optional. The Value field is a copy of the body of the final CONFREQ sent to the client to complete LCP negotiation, starting at the first option within this packet's body. Last Received LCP Confreq 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|6 + LCP confreq length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 28 | LCP confreq... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See Initial LCP Confreq above for rationale. The Attribute value is 28, Last Received LCP Confreq, and is marked optional. The presence of this AVP is optional. The Value field is a copy of the body of the final CONFREQ received from the client to complete LCP negotiation, starting at the first option within this packet's body. Proxy Authen Type 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 29 | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute value is 29, Proxy Authen Type, and is marked mandatory. This AVP MUST be present. The value Type is a 16-bit word, holding a value: 1 - Textual username/password exchange 2 - PPP CHAP 3 - PPP PAP 4 - None Associated AVP's for each type of authentication follow. Proxy Authen Name Valencia expires February 1998 [Page 57] INTERNET DRAFT August 1997 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 6 + Name length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 30 | Name... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute value is 30, Proxy Authen Name, and is marked mandatory. This AVP MUST be present for Proxy Authen Type values 1, 2, and 3. The Name field contains the name specified in the client's authentication response. Note that the AVP H bit may be desirable for obscuring the cleartext name. Proxy Authen Challenge 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 6 + Challenge length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 31 | Challenge... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute value is 31, Proxy Authen Challenge, and is marked mandatory. The AVP itself MUST be present for Proxy authen type 2. The Challenge field contains the value presented to the client by the LAC. Proxy Authen ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32 | ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute value is 32, Proxy Authen ID, and is marked mandatory. The AVP itself MUST be present for Proxy authen types 2 and 3. For CHAP, the ID field contains the byte ID value presented to the client by the LAC in its Challenge. For PAP, it is the Identifier value of the Authenticate-Request. The most significant 8 bits of ID MUST be 0, and are reserved. Proxy Authen Response 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 6 + Response length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 33 | Response... Valencia expires February 1998 [Page 58] INTERNET DRAFT August 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute value is 33, Proxy Authen Response, and is marked mandatory. The AVP itself MUST be present for Proxy authen types 1, 2, and 3. The Response field contains the client's response to the challenge. For Proxy authen type 2, this field contains the response value received by the LAC. For types 1 or 3, it contains the clear text password received from the client by the LAC. In the case of cleartext passwords, use of the AVP H bit is recommended. Private Group ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 6 + Private Group ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 37 | Private Group ID ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PrivateGroup ID AVP is used by the LAC to indicate that this call is to be associated with a particular customer group. The Attribute is 37, Private Group ID, and is marked optional. The presence of this AVP is optional. The LNS MAY treat the PPP session as well as network traffic through this session specially in a manner determined by the peer. For example, if the LNS is individually connected to several private networks using unregistered addresses, this AVP may be included by the LAC to indicate that a given call should be associated with one of the private networks. The Private Group ID is a string corresponding to a table in the LNS that defines the particular characteristics of the selected group. A LAC MAY determine the Private Group ID from a RADIUS response containing the PrivateGroupID attribute. The Private Group ID AVP MAY be included in either incoming call request or incoming call connected messages. This AVP SHOULD NOT be included in both messages. 6.13 (reserved) The function previously described here has been deleted from L2TP. 6.14 Call-Disconnect-Notify (CDN) The Call-Disconnect-Notify message is an L2TP control message sent to request disconnection of a specific call within the tunnel. Its purpose is to inform the peer of the disconnection and the reason why the disconnection occurred. The peer MUST clean up any resources, and does not send back any indication of success or failure for such cleanup. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | Valencia expires February 1998 [Page 59] INTERNET DRAFT August 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call-Disconnect-Notify | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | | Q.931 Cause Code | | Assigned Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+ Call-Disconnect-Notify 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 14 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 14, indicating Call- Disconnect-Notify. The Call-Disconnect-Notify message encodes a disconnect indication for a specific call within the tunnel. The flags indicate a mandatory option. Result Code 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 10 + Message length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | Optional Message ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Result Code AVP within a Call-Disconnect-Notify message indicates the reason for the call disconnect. It is encoded as Attribute 1, indicating a Result Code AVP. This AVP is mandatory and MUST be present. The Result Code is a 16-bit word. The 16- bit word following the Result Code field contains the Error Code value. The Result Code value indicates whether the Error Code value is meaningful or not. If Error Code is not meaningful it MUST be set to 0. An optional error message can follow the Error Code field; its presence and length is indicated by the value of the AVP length field. Defined Result Code values are: 1 - Call disconnected due to loss of carrier 2 - Call disconnected for the reason indicated in Error Code. 3 - Call disconnected for administrative reasons 4 - Call failed due to no appropriate facilities being available (temporary condition) 5 - Call failed due to no appropriate facilities being available (permanent condition) 6 - Invalid destination Valencia expires February 1998 [Page 60] INTERNET DRAFT August 1997 7 - Call failed due to no carrier detected 8 - Call failed due to detection of a busy signal 9 - Call failed due to lack of a dial tone 10 - Call was not established within time allotted by LAC 11 - Call was connected but no appropriate framing was detected Q.931 Cause Code 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|9 + Advisory Msg length| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 12 | Cause Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Msg |Advisory Msg...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Q.931 Cause Code AVP is used to give additional information in case of unsolicited call disconnection. The Attribute value is 12, Cause Code, and is marked mandatory. The presence of this AVP is optional. The Cause Code AVP is used to give additional information about the reason for disconnecting. It is only relevant when the LAC is using Q.931/DSS1 for the call. This AVP is optional. Cause Code is the returned Q.931 Cause code and Cause Msg is the returned Q.931 message code (e.g., DISCONNECT) associated with the Cause Code. Both values are returned in their native ITU encodings. An additional Ascii text Advisory Message may also be included (presence indicated by the AVP length) to further explain the reason for disconnecting. Assigned Call ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 14 | Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Assigned Call ID which was provided to the LNS from this LAC is included in the Call-Disconnect-Notify message. This permits a connection to be terminated even before the LNS has provided its own Assigned Call ID to this LAC (the Call ID field in the control message header is 0). The Attribute value is 14, Assigned Call ID, and is marked mandatory. This AVP MUST be present. 6.15 WAN-Error-Notify (WEN) The WAN-Error-Notify message is an L2TP control message sent by the LAC to the LNS to indicate WAN error conditions (conditions that occur on the interface supporting PPP). The counters in this message are cumulative. This message should only be sent when an error Valencia expires February 1998 [Page 61] INTERNET DRAFT August 1997 occurs, and not more than once every 60 seconds. The counters are reset when a new call is established. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WAN-Error-Notify | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WAN-Error-Notify 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 15, indicating WAN-Error- Notify. The WAN-Error-Notify message encodes information about line and other errors detected on the LAC's physical interface to the client. This message is sent by the LAC to the LNS. The flags indicate a mandatory option. Call Errors 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 32 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 34 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Framing Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hardware Overruns | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Buffer Overruns | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time-out Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Alignment Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Call Errors AVP is used by the LAC to send error information to the LNS. The Attribute value is 34, WAN-Error-Notify, and is marked mandatory. This AVP MUST be present. The value contains the following fields: Valencia expires February 1998 [Page 62] INTERNET DRAFT August 1997 Reserved - Not used, MUST be 0 CRC Errors - Number of PPP frames received with CRC errors since session was established Framing Errors - Number of improperly framed PPP packets received Hardware Overruns - Number of receive buffer over-runs since session was established Buffer Overruns - Number of buffer over-runs detected since session was established Time-out Errors - Number of time-outs since call was established Alignment Errors - Number of alignment errors since call was established 6.16 Set-Link-Info (SLI) The Set-Link-Info message is an L2TP control message sent by the LNS to the LAC to set PPP-negotiated options. Because these options can change at any time during the life of the call, the LAC MUST be able to update its internal call information dynamically and update its behavior on an active PPP session. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set-Link-Info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACCM | +-+-+-+-+-+-+-+-+-+-+-+-+-+ Set-Link-Info 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Value of 16, indicating Set-Link- Info. The Set-Link-Info message encodes ACCM information sent from the LNS to the LAC after it is negotiated in LCP. The flags indicate a mandatory option. ACCM 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|0| 32 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 35 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Send ACCM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires February 1998 [Page 63] INTERNET DRAFT August 1997 | Receive ACCM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ACCM AVP is used by the LNS to inform LAC of the ACCM to the LNS. The Attribute value is 35, ACCM, and is marked mandatory. This attribute MUST be present. The value contains Send ACCM and Receive ACCM fields. The send ACCM value should be used by the LAC to process packets it is sends on the connection. The receive ACCM value should be used by the LAC to process incoming packets on the connection. The default values used by the LAC for both these fields are 0xFFFFFFFF. The LAC should honor these fields unless it has specific configuration information to indicate that the requested mask must be modified to permit operation. 7.0 Control Connection State Machines The control messages defined in section 6 are exchanged by way of state tables defined in this section. Tables are defined for incoming call placement, outgoing call placement, as well as for initiation of the tunnel itself. The state tables do not encode timeout and retransmission behavior, as this is handled in the underlying semantics defined in 6.0.2. 7.1 Control Connection Protocol Operation This section describes the operation of various L2TP control connection functions and the Control Connection messages which are used to support them. Receipt of an invalid or malformed Control Connection message should be logged appropriately, and the control connection should be closed and restarted to ensure recovery into a known state. In several cases in the following tables, a protocol message is sent, and then a "clean up" occurs. Note that regardless of the initiator of the tunnel destruction, the reliable delivery mechanism must be allowed to run (see 6.0.2) before destroying the tunnel. This permits the tunnel management messages to be reliably delivered to the peer. 7.2 Control Connection States Control messages are carried over the same media as the payload messages which are carried following successful connection establishment. The L2TP control connection protocol is not distinguishable between the LNS and LAC, but is distinguishable between the originator and receiver. The originating peer is the one which first establishes the tunnel. Since either LAC or LNS can be the originator, a collision can occur. See Section 6.0.1 for a description of this and its resolution. 7.2.1 Control Connection Establishment State Event Action New State Valencia expires February 1998 [Page 64] INTERNET DRAFT August 1997 ----- ----- ------ --------- idle Local Send SCCRQ wait-ctl-reply Open request idle Receive SCCRQ, Send SCCRP wait-ctl-conn acceptable idle Receive SCCRQ, Send StopCCN, idle not acceptable Clean up wait-ctl-reply Receive SCCRP, Send SCCCN, established acceptable Send tunnel-open event to waiting sessions wait-ctl-reply Receive SCCRP, Send StopCCN, idle not acceptable Clean up wait-ctl-reply Receive SCCRQ, Clean up, idle lose tie-breaker Re-queue SCCRQ for idle state wait-ctl-conn Receive SCCCN, Send tunnel-open established acceptable event to waiting sessions wait-ctl-conn Receive SCCCN, Send StopCCN, idle not acceptable Clean up established Local Send tunnel-open established Open request event to waiting (new client) sessions established Admin Send StopCCN idle Tunnel Close Clean up wait-ctl-reply, wait-ctl-conn, established Receive StopCCN Clean up idle idle Both initiator and recipient start from this state. An initiator transmits a SCCRQ, while a recipient remains in the idle state until receiving a SCCRQ. wait-ctl-reply The originator checks to see if another connection has been requested from the same peer, and if so, handles the collision situation described in Section 6.0.1. When a SCCRP is received, it is examined for a compatible version. If the version of the reply is lower than the version sent in the request, the older (lower) version should be used provided it is supported. If the version in the reply is earlier and supported, Valencia expires February 1998 [Page 65] INTERNET DRAFT August 1997 the originator moves to the established state. If the version is earlier and not supported, a StopCCN MUST be sent to the peer and the originator cleans up and terminates the tunnel. wait-ctl-conn This is where an SCCCN is awaited; upon receipt, protocol version compatibility is checked. The tunnel is either established, or is torn down if a protocol mismatch is detected. established An established connection may be terminated by either a local condition or the receipt of a Stop-Control-Connection- Notification. In the event of a local termination, the originator MUST send a Stop-Control-Connection-Notification and clean up the tunnel. If the originator receives a Stop-Control-Connection-Notification it MUST also clean up the tunnel. 7.3 Timing considerations Because of the real-time nature of telephone signaling, both the LNS and LAC should be implemented with multi-threaded architectures such that messages related to multiple calls are not serialized and blocked. The call and connection state figures do not specify exceptions caused by timers. These are addressed in Section 6.0.2. 7.4 Incoming calls An Incoming-Call-Request message is generated by the LAC when an associated telephone line rings. The LAC selects a Call ID and serial number and indicates the call bearer type. Modems should always indicate analog call type. ISDN calls should indicate digital when unrestricted digital service or rate adaption is used and analog if digital modems are involved. CLID, DNIS, and subaddress may be included in the message if they are available from the telephone network. Once the LAC sends the Incoming-Call-Request, it waits for a response from the LNS but it does not necessarily answer the call from the telephone network yet. The LNS may choose not to accept the call if: - No resources are available to handle more sessions - The dialed, dialing, or subaddress fields do not correspond to an authorized user - The bearer service is not authorized or supported If the LNS chooses to accept the call, it responds with an Incoming- Call-Reply which may also indicate window sizes (see Appendix B). When the LAC receives the Incoming-Call-Reply, it attempts to connect the call. A final call connected message from the LAC to the LNS indicates that the call states for both the LAC and the LNS should enter the established state. If the call terminated before the LNS could accept it, a Call-Disconnect-Notify is sent by the LAC to Valencia expires February 1998 [Page 66] INTERNET DRAFT August 1997 indicate this condition. When the dialed-in client hangs up, the call is cleared normally and the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to clear a call, it sends a Call-Disconnect-Notify message and cleans up its session. 7.4.1 LAC Incoming Call States State Event Action New State ----- ----- ------ --------- idle Bearer Ring or Initiate local wait-tunnel Ready to indicate tunnel open incoming conn. wait-tunnel tunnel-open Send ICRQ wait-reply wait-reply Receive ICRP, Answer call, established accepting Send ICCN wait-reply Receive ICRP, Send CDN, idle not accepting Clean up wait-reply Receive CDN Clean up idle wait-reply Local Send CDN, idle Close request Clean up established Receive CDN Hang up bearer, idle Clean up established Local Hang up bearer, idle Close request Send CDN, Clean up established Bearer Send CDN, idle Line drop Clean up The states associated with the LAC for incoming calls are: idle The LAC detects an incoming call on one of its interfaces. Typically this means an analog line is ringing or an ISDN TE has detected an incoming Q.931 SETUP message. The LAC initiates its tunnel establishment state machine, and moves to a state waiting for confirmation of the existence of a tunnel. wait-tunnel In this state the session is waiting for either the control tunnel to be opened or for verification that the tunnel is already open. Once an indication that the tunnel has/was opened, session control messages may be exchanged. The first of these is the Incoming-Call- Request. Valencia expires February 1998 [Page 67] INTERNET DRAFT August 1997 wait-reply The LAC receives an Incoming-Call-Reply message indicating non- willingness to accept the call (general error or don't accept) and moves back into the idle state. If the reply message indicates that the call is accepted, the LAC sends an Incoming-Call-Connected message and enters the established state. established Data is exchanged over the tunnel. The call may be cleared following: An event on the connected interface. The LAC sends a Call- Disconnect-Notify message Receipt of a Call-disconnect-Notify message. The LAC cleans up, disconnecting the call. A local reason. The LAC sends a Call-Disconnect-Notify message. 7.4.2 LNS Incoming Call States State Event Action New State ----- ----- ------ --------- idle Receive ICRQ, Send ICRP wait-connect acceptable idle Receive ICRQ, Send CDN, idle not acceptable Clean up wait-connect Receive ICCN Prepare for established acceptable data wait-connect Receive ICCN Send CDN, idle not acceptable Clean up wait-connect, established Receive CDN Clean up idle established Local Send CDN, idle Close request Clean up The states associated with the LNS for incoming calls are: idle An Incoming-Call-Request message is received. If the request is not acceptable, a Call-Disconnect-Notify is sent back to the LAC and the LNS remains in the idle state. If the Incoming-Call- Request message is acceptable, an Incoming-Call-Reply is sent. The session moves to the wait-connect state. wait-connect If the session is still connected on the LAC, the LAC sends an Incoming-Call-Connected message to the LNS which then moves into established state. The LAC may send a Call-Disconnect-Notify to indicate that the incoming caller could not be connected. This could happen, for example, if a telephone user accidentally places Valencia expires February 1998 [Page 68] INTERNET DRAFT August 1997 a standard voice call to an LAC resulting in a handshake failure on the called modem. established The session is terminated either by receipt of a Call-Disconnect- Notify message from the LAC or by sending a Call-Disconnect- Notify. Clean up follows on both sides regardless of the initiator. 7.5 Outgoing calls Outgoing calls are initiated by an LNS and instruct an LAC to place a call. There are three messages for outgoing calls: Outgoing-Call- Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS sends an Outgoing-Call-Request specifying the dialed party phone number and subaddress as well as speed and window parameters. The LAC MUST respond to the Outgoing-Call-Request message with an Outgoing-Call-Reply message once the LAC determines that the proper facilities exist to place the call and the call is administratively authorized. For example, is this LNS allowed to dial an international call? Once the outbound call is connected the LAC sends an Outgoing-Call-Connected message to the LNS indicating the final result of the call attempt: 7.5.1 LAC Outgoing Call States State Event Action New State ----- ----- ------ --------- idle Receive OCRQ, Send OCRP, wait-cs-answer acceptable Open bearer idle Receive OCRQ, Send CDN, idle not acceptable Clean up wait-cs-answer Bearer answer, Send OCCN established framing detected wait-cs-answer Bearer failure Send CDN, idle Clean up wait-cs-answer, established Receive CDN Hang up bearer, idle Clean up The states associated with the LAC for outgoing calls are: idle Received Outgoing-Call-Request. If this is received in error, respond with a Call-Disconnect-Notify. Otherwise, allocate a physical channel and send an Outgoing-Call-Reply. Place the outbound call and move to the wait-cs-answer state. wait-cs-answer If the call is not completed or a timer expires waiting for the Valencia expires February 1998 [Page 69] INTERNET DRAFT August 1997 call to complete, send a Call-Disconnect-Notify with the appropriate error condition set and go to idle state. If a circuit switched connection is established and framing is detected, send an Outgoing-Call-Connected indicating success and go to established state. established If a Call-Disconnect-Notify is received, the telco call MUST be released via appropriate mechanisms and the session cleaned up. If the call is disconnected by the client or the called interface, a Call-Disconnect-Notify message MUST be sent to the LNS. Return to idle state after sending the Call-Disconnect-Notify. 7.5.2 LNS Outgoing Call States State Event Action New State ----- ----- ------ --------- idle Local Initiate local wait-tunnel Open request tunnel-open wait-tunnel tunnel-open Send OCRQ wait-reply wait-reply Receive OCRP, none wait-connect acceptable wait-reply Receive OCRP, Send CDN idle not acceptable wait-connect Receive OCCN none established established, wait-connect Receive CDN Clean up idle wait-reply, wait-connect, established Local Send CDN idle Close request The states associated with the LNS for outgoing calls are: idle, wait-tunnel When an outgoing call is initiated, a tunnel is first created, much as the idle and wait-tunnel states for an LAC incoming call. Once a tunnel is established, an Outgoing-Call-Request message is sent to the LAC and the session moves into the wait-reply state. wait-reply If a Call-Disconnect-Notify is received, an error occurred, and the session is cleaned up and returns to idle. If an Outgoing- Call-Reply is received, the call is in progress and the session moves to the wait-connect state. wait-connect If a Call-Disconnect-Notify is received, the call failed; the Valencia expires February 1998 [Page 70] INTERNET DRAFT August 1997 session is cleaned up and returns to idle. If an Outgoing-Call- Connected is received, the call has succeeded and the session may now exchange data. established If a Call-Disconnect-Notify is received, the call has been terminated for the reason indicated in the Result and Cause Codes; the session moves back to the idle state. If the LNS chooses to terminate the session, it sends a Call-Disconnect-Notify to the LAC and then cleans up and idles its session. 8.0 L2TP Over Specific Media L2TP tries to be self-describing, operating at a level above the particular media over which it is carried. However, some details of its connection to media are required to permit interoperable implementations. The following sections describe details needed to permit interoperability over specific media. 8.1 IP/UDP L2TP uses the well-known UDP port 1701 [3]. The entire L2TP packet, including payload and L2TP header, is sent within a UDP datagram. The initiator of an L2TP tunnel picks an available source UDP port, and sends to the desired destination at port 1701. The recipient picks a free port on its own system, and sends its reply to the initiator's UDP port, setting its own UDP source port set to the free port it found. All subsequent packets exchanged will use these UDP ports. It is legal for a peer's IP address used for a given tunnel to change over the life of a connection; this may correspond to a peer with multiple IP interfaces responding to a network topology change. Responses should reflect the last source IP address for that Tunnel ID. IP fragmentation may occur as the L2TP packet travels over the IP substrate. L2TP makes no special efforts to optimize this. A LAC implementation MAY cause its LCP to negotiate for a specific MRU, which could optimize for LAC environments in which the MTUs of the path over which the L2TP packets are likely to travel have a consistent value. When operating over UDP, both the I and C bits MUST be present, and are used to permit correct demultiplexing and tunnel identification. The default for any L2TP implementation is that UDP checksums MUST be enabled for both control and payload messages. An L2TP implementation MAY provide an option to disable UDP checksums for payload packets. It is recommended that UDP checksums always be enabled on control packets. Port 1701 is used for both L2F [5] and L2TP packets. The two types of packets may be detected by their headers; L2TP has a Vers field of 2, L2F has a 1 in this field instead. An L2TP implementation running on a system which does not support L2F MUST silently discard all Valencia expires February 1998 [Page 71] INTERNET DRAFT August 1997 packets whose Vers field is set to 1. 8.2 IP When operating in IP environments, L2TP MUST offer the UDP encapsulation described in 8.1 as its default configuration for IP operation. Other configurations (perhaps corresponding to a compressed header format) may be defined, and made available as a configurable option. 9.0 Security Considerations L2TP encounters several security issues in its operation. The general approach of L2TP to these issues is documented here. 9.1 Tunnel Endpoint Security The tunnel endpoints may authenticate each other during tunnel establishment. This authentication has the same security attributes as CHAP, and has reasonable protection against replay and snooping. In environments where some L2TP peers will be authenticated, but others not, a mechanism should be provided to control when tunnel endpoint authentication will be active. The LAC and LNS MUST share a single secret for authentication of both ends of the tunnel. Each side uses this same secret when acting as authenticatee as well as authenticator. Since a single secret it used, the tunnel authentication AVPs include differentiating values in the CHAP ID fields for each message digest calculation to guard against replay attacks. For L2TP tunnels over IP, IP-level packet security provides very strong protection of the tunnel. This requires no modification to the L2TP protocol, and leverages extensive IETF work in this area. For L2TP tunnels over Frame Relay or other switched networks, current practice indicates that these media are much less likely to experience attacks of in-transit data. If these attacks became prevalent, either the media or the L2TP packets would have to be encrypted. Because the shared secret used for endpoint authentication is the same shared secret used to obscure AVP contents using the H (Hidden) bit, tunnel authentication must be used in all cases where the H bit will be used. Proxy authentication involving PAP may be usable without the H bit if PAP is only carrying one-time passwords; if clear text passwords are carried in the proxy authentication, the H bit (and, by implication, tunnel authentication) should be used. To protect against exhaustive attack during tunnel authentication, no tunnel authentication response should ever be accepted if it corresponds to a challenge more than one minute old. Valencia expires February 1998 [Page 72] INTERNET DRAFT August 1997 9.2 Client Security A more systematic method of protection in tunneled PPP environments may be achieved through client security. PPP layer encryption would provide end-to-end security for both direct dial-in clients as well as PPP clients carried within a tunnel. With this level of client security, sessions are protected against attacks against the carrying tunnel, as well as attacks on the LAC itself. Because both encryption and compression can occur at the PPP layer, the two can be coordinated, permitting compression to precede encryption. 9.3 Proxy Authentication The optional proxy CHAP function of L2TP can permit an entirely transparent PPP tunnel, with a single LCP and CHAP sequence being seen by the client. For cases where the LAC and the entire path to the LNS are operated by a single entity, this function may provide acceptable security. For cases where LNS-initiated authentication is required, proxy CHAP still permits an initial access decision to be made before accepting the tunnel, permitting the LNS in most cases to reject tunnel initiations rather than accept them and later disconnect. The optional proxy PAP may result in the cleartext password traversing the tunnel. Where PAP is being used in conjunction with static passwords, this may pose a significant security issue. Where PAP is only used to transport one-time passwords, such issues may be greatly mitigated. The H bit of the carrying AVP may be used to protect against this. All implementations MUST accept proxy authentication AVP's, but are free to silently discard them and initiate an entirely new authentication with the PPP client. 10.0 Acknowledgments The AVP construct comes from Glen Zorn, who thought up the framework for permitting multiple vendors to contribute to a common attribute space in a relatively orderly fashion. Dory Leifer and Allan Rubens of Ascend Communications made valuable refinements to the protocol definition of L2TP and contributed to the editing of this document. Steve Cobb and Evan Caves redesigned the state machine tables. Barney Wolff provided a great deal of design input on the endpoint authentication mechanism. 11.0 Contacts Kory Hamzeh Ascend Communications Valencia expires February 1998 [Page 73] INTERNET DRAFT August 1997 1275 Harbor Bay Parkway Alameda, CA 94502 kory@ascend.com Tim Kolar, Morgan Littlewood, Bill Palter, Andrew J. Valencia Cisco Systems 170 West Tasman Drive San Jose CA 95134-1706 tkolar@cisco.com littlewo@cisco.com palter@cisco.com vandys@cisco.com Gurdeep Singh Pall Microsoft Corporation Redmond, WA gurdeep@microsoft.com Jeff Taarud Copper Mountain Networks jtaarud@coppermountain.com W. Mark Townsley IBM Corporation 700 Park Office Dr. Raleigh, NC 27709 wmt@raleigh.ibm.com William Verthein U.S. Robotics 12.0 References [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 07/21/1994 [2] A. Valencia, M. Littlewood, T. Kolar, "Layer 2 Forwarding", Internet draft, April 1996 [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, "Point-to-Point Tunneling Protocol", Internet draft, June 1996 [4] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC1034, November 1987 [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. [6] Sally Floyd, Van Jacobson, "Random Early Detection Gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, August 1993 [7] D. Carrel, L. Grant, "The TACACS+ Protocol", draft-grant-tacacs-00.txt, Valencia expires February 1998 [Page 74] INTERNET DRAFT August 1997 October 1996 [8] C. Rigney, A. Rubens, W. A. Simpson, S. Willens. "Remote Authentication Dial In User Service (RADIUS)." draft-ietf-radius-radius-05.txt, Livingston, Merit, Daydreamer, July 1996. Appendix A: Acknowledgment Time-Outs L2TP uses sliding windows and time-outs to provide both user session flow-control across the underlying medium (which may be an internetwork) and to perform efficient data buffering to keep the LAC-LNS data channels full without causing receive buffer overflow. L2TP requires that a time-out be used to recover from dropped data or acknowledgment packets. The exact implementation of the time-out is vendor-specific. It is suggested that an adaptive time-out be implemented with backoff for congestion control. The time-out mechanism proposed here has the following properties: Independent time-outs for each session. A device (LAC or LNS) will have to maintain and calculate time-outs for every active session. An administrator-adjustable maximum time-out, MaxTimeOut, unique to each device. An adaptive time-out mechanism that compensates for changing throughput. To reduce packet processing overhead, vendors may choose not to recompute the adaptive time-out for every received acknowledgment. The result of this overhead reduction is that the time-out will not respond as quickly to rapid network changes. Timer backoff on time-out to reduce congestion. The backed-off timer value is limited by the configurable maximum time-out value. Timer backoff is done every time an acknowledgment time-out occurs. In general, this mechanism has the desirable behavior of quickly backing off upon a time-out and of slowly decreasing the time-out value as packets are delivered without time-outs. Some definitions: Packet Processing Delay, "PPD", is the amount of time required for each peer to process the maximum amount of data buffered in its offered receive packet window. The PPD is the value exchanged between the LAC and LNS when a call is established. For the LNS, this number should be small. For an LAC supporting modem connections, this number could be significant. "Sample" is the actual amount of time incurred receiving an acknowledgment for a packet. The Sample is measured, not calculated. Round-Trip Time, "RTT", is the estimated round-trip time for an Valencia expires February 1998 [Page 75] INTERNET DRAFT August 1997 Acknowledgment to be received for a given transmitted packet. When the network link is a local network, this delay will be minimal (if not zero). When the network link is the Internet, this delay could be substantial and vary widely. RTT is adaptive: it will adjust to include the PPD and whatever shifting network delays contribute to the time between a packet being transmitted and receiving its acknowledgment. Adaptive Time-Out, "ATO", is the time that must elapse before an acknowledgment is considered lost. After a time-out, the sliding window is partially closed and the ATO is backed off. Packet Processing Delay (PPD) The PPD parameter is a 16-bit time value exchanged during the Call Control phase expressed in units of tenths of a second (64 means 6.4 seconds). The protocol only specifies that the parameter is exchanged, it does not specify how it is calculated. The way values for ATO are calculated is implementation-dependent and need not be variable (static time-outs are allowed). IF adaptive time-outs are to be used then the PPD should be exchanged in the call connect sequences. A possible way to calculate the PPD is: PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate + LACFudge (for an LAC) or PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate + LNSFudge (for an LNS) Header is the total size of the L2TP and media dependent headers. MTU is the overall MTU for the link between the LAC and LNS. WindowSize represents the number of packets in the sliding window, and is implementation-dependent. The latency of the underlying connection path between the LAC and LNS could be used to pick a window size sufficient to keep the current session's pipe full. The constant 8 converts octets to bits (assuming ConnectRate is in bits per second). If ConnectRate is in bytes per second, omit the 8. LACFudge and LNSFudge are not required but can be used to take overall processing overhead of the LAC or LNS into account. In the case of the computed PPD for an LNS, AvePathRate is the average bit rate of the path between the LNS and LAC. Given that this number is probably very large and WindowSize is relatively small, LNSFudge will be the dominant factor in the computation of PPD. It is recommended that the minimum value of PPD be on the order of 0.5 second. The value of PPD is used to seed the adaptive algorithm with the initial RTT[n-1] value. A.1 Calculating Adaptive Acknowledgment Time-Out We still must decide how much time to allow for acknowledgments to return. If the time-out is set too high, we may wait an Valencia expires February 1998 [Page 76] INTERNET DRAFT August 1997 unnecessarily long time for dropped packets. If the time-out is too short, we may time out just before the acknowledgment arrives. The acknowledgment time-out should also be reasonable and responsive to changing network conditions. The suggested adaptive algorithm detailed below is based on the TCP 1989 implementation and is explained in Richard Steven's book TCP/IP Illustrated, Volume 1 (page 300). 'n' means this iteration of the calculation, and 'n-1' refers to values from the last calculation. DIFF[n] = SAMPLE[n] - RTT[n-1] DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) RTT[n] = RTT[n-1] + (alpha * DIFF[n]) ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) DIFF represents the error between the last estimated round-trip time and the measured time. DIFF is calculated on each iteration. DEV is the estimated mean deviation. This approximates the standard deviation. DEV is calculated on each iteration and stored for use in the next iteration. Initially, it is set to 0. RTT is the estimated round-trip time of an average packet. RTT is calculated on each iteration and stored for use in the next iteration. Initially, it is set to PPD. ATO is the adaptive time-out for the next transmitted packet. ATO is calculated on each iteration. Its value is limited, by the MIN function, to be a maximum of the configured MaxTimeOut value. Alpha is the gain for the average and is typically 1/8 (0.125). Beta is the gain for the deviation and is typically 1/4 (0.250). Chi is the gain for the time-out and is typically set to 4. To eliminate division operations for fractional gain elements, the entire set of equations can be scaled. With the suggested gain constants, they should be scaled by 8 to eliminate all division. To simplify calculations, all gain values are kept to powers of two so that shift operations can be used in place of multiplication or division. The above calculations are carried out each time an acknowledgment is received for a packet that was not retransmitted (no time-out occurs). A.2 Congestion Control: Adjusting for Time-Out This section describes how the calculation of ATO is modified in the case where a time-out does occur. When a time-out occurs, the time- out value should be adjusted rapidly upward. Although L2TP payload packets are not retransmitted when a time-out occurs, the time-out should be adjusted up toward a maximum limit. To compensate for shifting internetwork time delays, a strategy must be employed to increase the time-out when it expires. A simple formula called Karn's Algorithm is used in TCP implementations and may be used in Valencia expires February 1998 [Page 77] INTERNET DRAFT August 1997 implementing the backoff timers for the LNS or the LAC. Notice that in addition to increasing the time-out, we also shrink the size of the window as described in the next section. Karn's timer backoff algorithm, as used in TCP, is: NewTIMEOUT = delta * TIMEOUT Adapted to our time-out calculations, for an interval in which a time-out occurs, the new time-out interval ATO is calculated as: RTT[n] = delta * RTT[n-1] DEV[n] = DEV[n-1] ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) In this modified calculation of ATO, only the two values that contribute to ATO and that are stored for the next iteration are calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is not carried forward and is not used in this scenario. A value of 2 for Delta, the time-out gain factor for RTT, is suggested. Appendix B: Acknowledgment Time-Out and Window Adjustment B.1 Initial Window Size Although each side has indicated the maximum size of its receive window, it is recommended that a slow start method be used to begin transmitting data. The initial maximum window size on the transmitter is set to half the maximum size the receiver requested, with a minimum size of one packet. The transmitter stops sending packets when the number of packets awaiting acknowledgment is equal to the current maximum window size. As the receiver successfully digests each window, the maximum window size on the transmitter is bumped up by one packet until the maximum specified by the receiver is reached. This method prevents a system from flooding an already congested network because no history has been established. When for any reason an LAC or LNS receives more data than it can queue for the tunnel, a packet must be discarded. In this case, it is recommended that a "random early discard" algorithm [6] be used rather than the obvious "drop last" algorithm. B.2 Closing the Window When a time-out does occur on a packet, the sender adjusts the size of the transmit window down to one half its maximum value when it failed. Fractions are rounded up, and the minimum window size is one. B.3 Opening the Window With every successful transmission of a window's worth of packets without a time-out, the maximum transmit window size is increased by one packet until it reaches the maximum window size that was sent by its peer when the call was connected. As stated earlier, no Valencia expires February 1998 [Page 78] INTERNET DRAFT August 1997 retransmission is done on a time-out. After a time-out, transmission resumes with the maximum transmit window starting at one half the size of the maximum transmit window when the time-out occurred (with a minimum window size of 1) and adjusting upward by one each time the current maximum transmit window is filled with packets that are all acknowledged without time-outs. B.4 Window Overflow When a receiver's window overflows with too many incoming packets, excess packets are thrown away. This situation should not arise if the sliding window procedures are being properly followed by the transmitter and receiver. It is assumed that, on the transmit side, packets are buffered for transmission and are no longer accepted from the packet source when the transmit buffer fills. Appendix C: Handling of out-of-order packets When the Sequence Number and Acknowledgment Number fields are present in payload packets, they are used to manage packet rate. In addition, they may be used to handle out-of-order arrival of packets. A simple L2TP client would simply discard any packet other than a packet with a sequence greater than that last received; if packets 1, 2, 3 arrived as 1, 3, 2, this would result in packet 2 being discarded. Such behavior does not affect the L2TP protocol itself, but significantly improved throughput in such environments may be attained by queueing and reordering packets when they arrive out of order. The number of packets to be queued is a function of memory resources on the L2TP implementation, but should never be more than 1/4 of the total sequence number space (i.e., 16384 packets), to avoid aliasing. An implementation which queues packets in this way must also employ an algorithm for deciding that a given sequence number corresponds to a packet which is lost, rather than one which is out of order but still in transit. Such a decision would likely be based upon timing, buffering conditions, and packet arrival characteristics. The details of such a tradeoff are outside the scope of this specification, but it is recommended a packet should be afforded an interval at least twice the estimated RTT from the L2TP peer. Appendix D: Transport Layer Adaptive Time-outs and Window Adjustment Appendixes A, B, and C dealt with operation of the payload packet sessions of L2TP. This Appendix explains how these three algorithms pertain to the transport layer for L2TP control sessions. Appendix B, Time-out Window Management, directly applies to the Transport Layer except in the case where a window size of 1 is being used. Appendix C, does not really apply because, for the Control Session, control messages MUST always be processed by the receiver in order. Also, there are no lost control packets because they are retransmitted by the L2TP Transport Layer. Thus, the main topic of this Appendix is Valencia expires February 1998 [Page 79] INTERNET DRAFT August 1997 how to adapt the example adaptive time-out algorithm of Appendix A to the Control Session Transport Layer. There are two main differences between the Control Session and payload sessions: 1) Unlike lost payload packets, lost control messages are retransmitted and 2) There is no Packet Processing Delay value provided in the control session setup messages. The latter affects the manner in which the initial value of the RTT estimate is determined. The former really doesn't affect the algorithm at all, except that upon a time-out, retransmission of unacknowledged control messages should be attempted, up to the number that fit in the sliding window with size computed as in Appendix B. Using the symbol definitions of Appendix A, the calculation of the value for the PPD of the remote peer can be estimated as: PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate + Fudge This is simply the number of bits in a full control session window divided by the average speed of the path between the LAC and LNS with a fudge factor added on to make it work. In cases where the average rate of the connection between LAC and LNS isn't known, it is suggested that some value be configured that is associated with each possible peer. Because Control Session windows will most likely be small and the connection speed will be quite high, fudge will be the dominant factor in this calculation. For this reason, just configuring a single fixed initial PPD estimate to be used for all possible peers will probably provide adequate results. This fudge factor should probably be at least 0.5 second. Appendix E: Examples of L2TP sequence numbering Although sequence numbers serve distinct purposes for control and data messages, both types of messages use identical techniques for assigning sequence numbers. This appendix shows several common scenarios, and illustrates how sequence number state progresses and is interpreted. E.1: Lock-step tunnel establishment In this example, an LAC establishes a tunnel, with the exchange involving each side alternating in sending messages. This example is contrived, in that the final acknowledgment in the example is explicitly sent within a zero-length message, although most typically the acknowledgment would have been included in the processing of the Incoming-Call-Request which had prompted the LAC to initiate the tunnel in the first place. LAC LNS -> Start-Control-Connection-Request Nr: 0, Ns: 0 Start-Control-Connection-Reply <- Valencia expires February 1998 [Page 80] INTERNET DRAFT August 1997 Nr: 1, Ns: 0 -> Start-Control-Connection-Connected Nr: 1, Ns: 1 (delay) (zero-length) <- Nr: 2, Ns: 1 E.2: Multiple packets acknowledged This example shows a flow of payload packets from the LNS to the LAC, with the LAC having no traffic of its own. The LAC is waiting 1/4 of its timeout interval, and then acknowledging all packets seen since the last interval. (previous packet flow precedes this) LAC LNS -> (zero-length) Nr: 7000, Ns: 1000 (payload) <- Nr: 1000, Ns: 7000 (payload) <- Nr: 1000, Ns: 7001 (payload) <- Nr: 1000, Ns: 7002 (LAC's timer indicates it should acknowledge pending traffic) -> (zero-length) Nr: 7003, Ns: 1000 E.3: Lost packet with retransmission As a final example, an existing tunnel has a new session requested by the LAC. The Incoming-Call-Reply is lost and must be retransmitted by the LNS. This example continues from the sequence state reached at the end of example E.1. Note that loss of the -Reply has two impacts: not only does it keep the upper level state machine from progressive, but it also keeps the LAC from seeing a timely lower level acknowledgment of its -Request packet. LAC LNS -> Incoming-Call-Request Nr: 1, Ns: 2 Incoming-Call-Reply <- Nr: 3, Ns: 1 (pause; LAC's timer started first, so fires first) Valencia expires February 1998 [Page 81] INTERNET DRAFT August 1997 -> Incoming-Call-Request Nr: 1, Ns: 2 (LNS realizes it has already seen this packet) (LNS might use this as a cue to retransmit, as in this example) Incoming-Call-Reply <- Nr: 3, Ns: 1 -> Incoming-Call-Connected Nr: 2, Ns: 3 (delay) (zero-length) <- Nr: 4, Ns: 2 Valencia expires February 1998 [Page 82]