view Side-By-Side changes
PPP Working Group Kory HamzehRequest for Comments: DRAFTINTERNET-DRAFT Ascend Communications Category: Internet Draft Tim Kolar Title:draft-ietf-pppext-l2tp-00.txtdraft-ietf-pppext-l2tp-01.txt Cisco Systems Date:AugustDecember 1996 Morgan Littlewood Cisco Systems Gurdeep Singh Pall Microsoft Corporation Jeff Taarud formerly of 3COM Corporation 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 doc- uments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing 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 ``work- ing 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 Proto- col (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 net- work provided. Table of Contents 1.0 Introduction 1.1 Conventions 1.2 Terminology Valencia expiresFebruaryMay 1997 [Page 1] INTERNET DRAFTAprilDecember 1996 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 General Error Codes 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 Stop-Control-Connection-Reply 6.6Echo-RequestHello 6.7Echo-Reply(deleted) 6.8 Outgoing-Call-Request 6.9 Outgoing-Call-Reply 6.10Incoming-Call-RequestOutgoing-Call-Connected 6.11Incoming-Call-ReplyIncoming-Call-Request 6.12Incoming-Call-ConnectedIncoming-Call-Reply 6.13Call-Clear-RequestIncoming-Call-Connected 6.14Call-Disconnect-NotifyCall-Clear-Request 6.15WAN-Error-NotifyCall-Disconnect-Notify 6.16Set-Link-InfoWAN-Error-Notify 6.17No-opSet-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(may be LAC or LNS)7.2.2 Control connection Receiver(may be LAC or LNS)7.3 Timing considerations 7.4 Incoming Calls7.57.4.1 LAC Incoming Call States 7.4.2 LNS Incoming Call States7.67.5 Outgoing calls7.77.5.1 LAC Outgoing Call States 7.5.2 LNS Outgoing Call States 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 Security10.0 Acknowledgments 11.0 ContactsValencia expiresFebruaryMay 1997 [Page 2] INTERNET DRAFTAprilDecember 1996 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 1.0 Introduction The traditional dial-up network service on the Internet is for regis- tered 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 applica- tion 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 per- mits 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 specifi- cation in this document: omust,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. Valencia expires May 1997 [Page 3] INTERNET DRAFT December 1996 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. CallValencia expires February 1997 [Page 3] INTERNET DRAFT April 1996A connection or attempted connection between two terminal end- points on a PSTN or ISDN--for example, a telephone call between two modems. CHAP Challenge Authentication Protocol, a PPP cryptographic chal- lenge/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 Extensible Authentication Protocol, a framework for a family of PPP authentication protocols, including cleartext, chal- lenge/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 Valencia expires May 1997 [Page 4] INTERNET DRAFT December 1996 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 transmit- ted to prove identity. Session L2TP is connection-oriented. The LNS and LAC maintain state for each user that is attached toaan 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 betweenaan 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)Valencia expires February 1997 [Page 4] INTERNET DRAFT April 1996An L2TP-compatible media on top of which L2TP is directly encapsu- lated. SVC's are dynamically created, permitting tunnel media to be created dynamically in response to desired LNS-LAC connectivity requirements. Tunnel A tunnel is defined byaan LNS-LAC pair. The tunnel carries PPP datagrams between the LAC and the LNS; many sessions can be multi- plexed over a single tunnel. A control connection operating in- band over the same tunnel controls the establishment, release, and Valencia expires May 1997 [Page 5] INTERNET DRAFT December 1996 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 regis- tered 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 secu- rity facilities that are available to him in a dedicated dial-up con- figuration. 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 thisserviceser- vice in a secure manner. + Authentication as provided via dial-up PPPCHAP orCHAP, 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. Theauthentica- tionauthentication 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 pur- poses) and by the user (for charge-back and auditing). 2.2 Topology Shown below is a generic Internet with Public switched Telephone Net- work (PSTN) access (i.e., async PPP via modems) and Integrated Ser- vices 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), althoughValencia expires February 1997 [Page 5] INTERNET DRAFT April 1996their physical dial-up is via the ISP Network Access Server. Valencia expires May 1997 [Page 6] INTERNET DRAFT December 1996 ...----[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. TheRemote Userremote 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 isestablished.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 ISPundertakesmay now undertake a partial authentication of the endsystem/user via CHAP or PAP.sys- tem/user. Only the username fieldiswould 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.jawadk@microsoft.com).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 connec- tion 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 May 1997 [Page 7] INTERNET DRAFT December 1996 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-pointValencia expires February 1997 [Page 6] INTERNET DRAFT April 1996 connectivity.connec- tivity. 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, orrejects.rejects it. Rejection may include a reason indication, which may be displayed to the dial-up user, after which the call should bediscon- nected.dis- connected. The initial setup notification may include the authentication infor- mation 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.The initialIf the LAC negotiated PPP LCP before initiating the tunnel, the ini- tial setup notification may also include a copy of thetheLCP CONFACKs 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 any link framing or transparency bytes, encapsulated in L2TP, and for- warded over the appropriate tunnel. The LNS accepts these frames, strips L2TP, and processes them as nor- mal 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 tra- ditional mechanisms with respect to further authorization, protocol access, and packet filtering. Valencia expires May 1997 [Page 8] INTERNET DRAFT December 1996 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.Valencia expires February 1997 [Page 7] INTERNET DRAFT April 1996L2TP offers optional facilities which maximize compatibility with legacy clientrequirements,requirements; L2TP connect notifications for PPP clients can contain sufficient information foraan LNS to authenticate and initialize its LCP state machine. With these facilities, thetheremote user need not be queried a second time forCHAP authentica- tion,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 specifi- cation. 3.0 Service Model Issues There are several significant differences between the standard Inter- net 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 prob- lems presented by these differences are described below. The mecha- nisms 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 LCPnegotationnegotiation and initiation ofCHAP.PPP authentication. As soon as the apparentiden- tityidentity 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 net- work'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 firewall, allocating addresses which are internal (and, in fact, can beRFC1597RFC1918 addresses, or non-IP addresses). Because L2TP tunnels Valencia expires May 1997 [Page 9] INTERNET DRAFT December 1996 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.Valencia expires February 1997 [Page 8] INTERNET DRAFT April 19963.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 usestheDNIS, CLID, or username to determine that a Virtual dial-up service is required andinitiateinitiates the tunnel connection to the appropriate LNS. Once a tunnel is established, The ISP NAS allo- cates a new Call IDis allocatedand initiates a sessioninitiatedby forwarding thegatheredgath- ered authenticationinforma- tion.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 thisinforma- tion,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 out- side 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 LNScan providebe capable of pro- viding accounting data and hence both may count packets, octets andconnec- tionconnection start and stop times. Since Virtual dial-up is an access service, accounting of connection attempts (in particular, failed connection attempts) is of signifi- cant 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 indica- tion 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 dis- tinction 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 num- ber of PPP packets with the remote system. Note that the LNS could use this information to decide to accept the connection (which pro- tects against mostthird-partyinvalid connection attempts) while still insisting on running its own CHAP authentication(to(for instance, to protect against CHAP replay attacks). Valencia expires May 1997 [Page 10] INTERNET DRAFT December 1996 4.0 Protocol Overview There are two parallel components of L2TP operating over a given tun- nel:1)control messages between each LAC-LNS pair, and2)payloadValencia expires February 1997 [Page 9] INTERNET DRAFT April 1996packets between the same LAC-LNSpair whichpair. The latter are used to transport L2TP encapsulated PPP packets for user sessions between the pair.4.1 Control Message Overview Before PPP tunneling can occur between a LAC and LNS,The Nr (Next Received) and Ns (Next Sent) fields are always present in controlmes- sagesmessages, and are optionally present in payload messages. Distinct sequence number state is maintained for control messages related to the tunnel (Call ID is 0), and for each distinct user ses- sion within the tunnel. Sequence number state is also distinct for control and for payload messages within a particular session. Each distinct 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, indicat- ing 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 indi- cates 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. 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 pay- load data once L2TP call control and management information have been passed. The control messages are responsible for establish- ment, management, and release of sessions carried through the tun- nel, as well as status on the tunnel itself. It is the means by whichaan LNS is notified of an incoming call at an associated LAC, as well as the means by whichaan LAC is instructed to place anout- goingoutgoing dial call. A tunnel may be established by eitheraan 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 mes- sages 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. Con- trol messages may indicate changes in operating characteristics of an individual user session with aSet- Link-InfoSet-Link-Info message.Indi- vidualIndivid- ual 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. Thetunnel itself is maintained by exchanging keepalive control echo messages. This ensures thatsender of aconnectivity failure between the LNS and the LAC can be detected inpacket associated with atimely manner. Other failures can be reported viaparticular Valencia expires May 1997 [Page 11] INTERNET DRAFT December 1996 session places theWan-Error-Notify control message. It is intended that control messages will also carry management related informationCall ID established by its peer in thefuture, suchCall 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. Two mechanisms provide for detection of tunnel connectivity prob- lems, one by the reliable transport layer of L2TP and another by the higher layer. 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. In addition, keepalive con- trol echo messages are injected into the control stream by the higher L2TP layer after a certain duration of inactivity on a given tunnel is detected. A response to the sent keepalive is expected within a configured time interval. If not received within the allowed time interval, the tunnel is reset. These two mechanisms ensure that a connectivity failure between the LNS and the LAC can be detected at either end of a tunnel in a timely man- ner. 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 typeshaveare notyet been defined.defined in this document. 4.2 Payload Packet Overview 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.A keyThe "Call ID" field in thetunnelL2TP header indicates to which session aparticularparticu- lar PPP packet belongs. In this manner, PPP packets aremultiplexed and demulti-multi- plexed and demultiplexed over a single tunnel between a givenLNS-LACLNS- LAC pair. Thekey"Call ID" field value is establishedbyduring the exchange of callestablishmentsetup controlmes- sages.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 singleuser,user session, and the tunnel media (an SVC, for instance) has specific QOS attributes dedicated to a given user. L2TP provides a tunnelValencia expires February 1997 [Page 10] INTERNET DRAFT April 1996identifier 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 sequenc- ing information that can be used to perform congestion 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.L2TP doesAll implementa- tions MUST implement flow control, but may indicate that flow con- trol is notspecifydesired by omitting theparticularPacket Window Size and Packet Processing Delay AVP's during call setup. L2TP does not specify Valencia expires May 1997 [Page 12] INTERNET DRAFT December 1996 the particular algorithms to use for congestion and flow 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 ade- quate "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 acknowl- edgments 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 tun- nel betweenaan LNS and a given LAC. The exact technique for initiat- ing a tunnel betweenaan LNS-LAC pair is specific to the tunnel media, andsupportedspecific media are described in section 8.0. Once media-level connectivity is reached, L2TP message formats define the protocol foraan LAC and LNS to manage the tunnel and its associ- ated 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: 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|0|0|0|0|0|0|0|M| [Value]...| Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [until OveralllengthLength is reached]... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Overall Length encodes the number of octets (including the Overall Length field itself) contained in this 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 Valencia expires February 1997 [Page 11] INTERNET DRAFT April 1996 private Attribute values, guaranteeing that they will not collide with any other vendor's extensions, nor with future IETF exten- sions. Attribute is the actual attribute, a 16-bit value with a unique interpretation under a given Vendor ID.Thenext octet isfirst four bits are a bit mask, describing the general attributes of the AVP.Only one bit value, M, is defined. ThisThe M bit, known as the "mandatory" bit, controls the behavior required of animple- mentationimplementation which receives an AVP which it does not recognize. If M is set, any sessionassociated with this AVP mustValencia expires May 1997 [Page 13] INTERNET DRAFT December 1996 associated with this AVP MUST be terminated. If the AVP isassociatedasso- ciated with the overall tunnel, the entiretun- neltunnel (and allsessionsses- sions within)mustMUST be terminated. If M is not set, anunrecognizedunrecog- nized AVP should be ignored.Value follows immediately afterThe H bit, known as theFlags field, and runs for"hidden" bit, controls theremaining octets indicatedencryption of the contents of the AVP. This 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. If the H bit is set in an AVP, theOverall Length (i.e., Overall Length minus sevenfollowing mechanism is applied to the contents of the AVP, starting with the first byte beyond the Attribute field: The contents is first padded at the end with nulls to a multi- ple of 16 octets. A one-way MD5 hash is calculated over a stream of octets consisting ofheader). If desired,the shared secret followed by agiven16 octet random vector, referred to as the Authenticator. The sender computes the random Authenticator and passes it in the first 16 octets of the AVPcan definevalue. The MD5 hash value is XORed with the first 16 octet segment of the password and placed in the next 16 octets of the Valueto be a pad, permitting actual data to be aligned onfield of the Proxy-Authen AVP. If the password is longer than 16 characters, a32-bit boundary. AVP's should be kept compact; in no case should AVP's ever causesecond one-way MD5 hash is calculated over acontrol message's total length to exceed 1532 bytes in length. 5.2 Control Message Format Each L2TP control message beginsstream of octets consisting of the shared secret followed by the result of the first XOR. That hash is XORed witha 20the second 16 octetfixed header por- tionsegment of the password andat least one AVP indicating message type. This fixed 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|1|1|1|K| | Ver | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type AVP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The T bit must be 1, indicating a control message. Theplaced in the nextfour bits must be set to 1, making16 octets of theheader more compatible in encod- ingValue field of the AVP. If necessary, this operation is repeated, with each XOR result being used along with thepayload message (defined inshared secret to generate the nextsection). The K bit is optional, documented below. Ver must be the value 002, indicating a version 1 L2TP message (values 000 and 001 are reservedhash topermit detectionXOR the next segment ofL2F [XXX], Valencia expires February 1997 [Page 12] INTERNET DRAFT April 1996 GRE [XXX], and PPTP [XXX] packets if they arrive intermixed). Lengththe password, to no more than 128 characters. On receipt, the Authenticator is taken from theoverall lengthfirst 16 octets of themessage, including header, message type AVP, plus any additional AVP's associated with a given control message type. Magic Cookie is always present,received AVP value field andhasthevalue 0x1A2B3C4E. Its purposeprocess is reversed toallowyield thereceiver to ensure that it is synchronized withoriginal password. For more details on this hiding method, consult thedata stream. It should not be used as a means for resyn- chronizingRADIUS [8] specification. Overall Length encodes thedata stream innumber of octets (including theevent that a transmitter issues an improperly formatted message. Loss of synchronization must resultOverall Length field itself) contained inimmediate closing of the session. Tunnel ID and Call ID identify the tunnel and caller within the tunnel to which a control message applies. Ifthis AVP. It is 10 bits, per- mitting acontrol message does not apply tomaximum of 1024 bytes of data in a singlecaller within the tunnel (for instance, a Stop-Control-Connection-Request message), CallAVP. Vendor IDshould be set to 0. Sequence Number and Acknowledgment Number reflect the currently transmitted packet and latest received packet respectively. If the K bitisset,theKey field is present.IANA assigned "SMI Network Management Private Enterprise Codes" value, encoded in network byte order. TheK bit must be set if a Challengevaluewas received during tunnel setup, and the Key reflects the challenge response of0, reserved in thisauthentication,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 exten- sions. Attribute is theresulting MD5 hashactual attribute, a 16-bit valuebroken into successive 32-bit fields which are XOR'ed togetherwith a unique interpretation across all AVP's defined under a given Vendor ID. Valencia expires May 1997 [Page 14] INTERNET DRAFT December 1996 Value follows immediately after the Attribute field, andthis value putruns for the remaining octets indicated in theKey field. The bodyOverall Length (i.e., Over- all Length minus six octets of header). AVP's should be kept compact; the combined AVP's within a control messageis an AVP indicating the type of control message. Depending on the particularMUST NOT ever cause a controlmessage, further AVPs may follow. 5.3 Payloadmessage's total length to exceed 1500 bytes in length. 5.2 Control Message FormatPPP payload packets tunneled within L2TP have a smaller encapsula- tion, reducing overhead ofEach L2TPduring the life ofcontrol message begins with atunneled PPP session. The MTU for the user data packets encapsulated in L2TP is 1532 octets, not including L2TP and media encapsulation. The smallest L2TP encapsulation is 2 octets; the largest20 octet fixed header por- tion followed by zero or more AVP's. This fixed header is12 octets.format- ted: 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||T|1|1|1|1|K|0| | Ver | Length(opt)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID(opt)| Call ID(opt)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sequence Number (opt)Ns |Acknowledgment Number (opt)Nr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type AVP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The T bitmustMUST be0,1, indicatingpayload. Valencia expires February 1997 [Page 13] INTERNET DRAFT April 1996a control message. The next four bits MUST be set to 1, making the header more compatible in encod- ing with the payload message (defined in the next section). The K bit is optional, documented below. The bit following the K bit MUST be 0. VermustMUST be the value 002, indicating a version 1of theL2TPprotocol. If the L bit is set, themessage (values 000 and 001 are reserved to permit detection of L2F [2] and PPTP [3] packets if they arrive intermixed). Lengthfieldispresent, indicatingthetotaloverall length of thereceived packet. If the I bit is set, themessage, including header, message type AVP, plus any additional AVP's associated with a given control message type. Tunnel IDfield is present. This is used to demultiplex multiple tunnels over a single media, where the media may not provide sufficient or efficient demultiplexing con- text. If the C bit is set, theand Call IDfield is present. This is used to multiplex multiple clients within one tunnel. Ifidentify theF bit is set, both Sequence Numbertunnel andAcknowledgment Num- ber are present. Sequence Number indicates the sequence number ofuser session within thenext packettunnel tobe sent. The current packet will be this sequence number ifwhich a control message applies. If a control mes- sage does not apply to a single user session within thepayload size is non-zero, otherwise this packet is onlytunnel (for instance, a Stop-Control-Connection-Request message), Call ID MUST be set to 0. If anacknowledgement (sequence number doesAssigned Tunnel ID has notadvance). Acknowledgment Number indicatesyet been received from thelatest packet sequence number last received. Together, these fields canpeer, Tunnel ID MUST beusedset tohandle out-of-order packets,0. Nr andto provide flow control forNs reflect theconnection.currently transmitted packet and latest received packet respectively. See section 4.0. If the K bit is set, the Key field is present.Refer to the description in 5.2. 5.4 Control Message Types Control message types defined in this specification exist under Vendor ID 0, indicating IETF defined behavior.Theactual message semantics are defined inK bit MUST be set if a Challenge value was received during tunnel setup, and thenext section. The currently defined control messages types, grouped by function, are: Control Message Message Code (Control Connection Management) Start-Control-Connection-Request 1 Start-Control-Connection-Reply 2 Start-Control-Connection-Connected 17 Stop-Control-Connection-Request 3 Stop-Control-Connection-Reply 4 Echo-Request 5 Echo-Reply 6 (Call Management) Outgoing-Call-Request 7 Outgoing-Call-Reply 8 Incoming-Call-Request 9 Incoming-Call-Reply 10 Incoming-Call-Connected 11 Call-Clear-Request 12 Call-Disconnect-Notify 13Valencia expiresFebruaryMay 1997 [Page14]15] INTERNET DRAFTAprilDecember 1996No-op 16 (Error Reporting) WAN-Error-Notify 14 (PPP Session Control) Set-Link-Info 15 5.5 General Error Codes General error codes pertain to typesKey reflects the challenge response oferrorsthis authentication, with the resulting MD5 hash value broken into successive 32-bit fields which arenot spe- cific to any particularXOR'ed together and this value put in the Key field. 5.3 Payload Message Format PPP payload packets tunneled within L2TPrequest, but rather to protocol or message format errors. Ifhave a smaller encapsula- tion than the L2TPreply indicates in its Result Code thatcontrol message header, reducing overhead of L2TP during the life of ageneral error occurred,tunneled PPP session. The MTU for theGeneral Error value should be examineduser data packets encapsulated in L2TP is expected todetermined what the error was. The currently defined General Error codesbe 1500 octets, not including L2TP andtheir meanings are:media encapsulation. The smallest L2TP encapsulation is 2 octets; the largest is 18 octets (plus padding bytes, if present). See section 8.1 for further MTU con- siderations. 0 1 2 3 0- No general error1- No control connection exists yet for this LAC-LNS pair2- Length is wrong or Magic Cookie value is incorrect3- One of the field values was out of range or reserved field was non-zero4- Insufficient resources to handle this command now5- The6 7 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| | Ver | Length (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID (opt) | Call IDis invalid in this contex 6 - A generic vendor-specific error occurred in the LAC 6.0 Control Connection Protocol Specification Control Connection messages are used to establish and clear user ses- sions.(opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ns (opt) | Nr (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset Size | Offset bytes of pad... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thefirst setT bit MUST be 0, indicating payload. Ver MUST be 002, indicating version 1 ofControl Connection messages are used to maintainthecontrol connection itself. The control connectionL2TP protocol. If the L bit isinitiated by a LAC or LNS after establishingset, theunderlying tunnel- over-media connection. 6.0.1 Control Connection Collision ForLength field is present, indicating thecase where an LAC and LNS both initiate tunnels to each other concurrently, and wheretotal length of theLACreceived packet. The I andLNS both determine that a single tunnel suffices (generally becauseC bits indicate the presence ofmedia characteris- tic considerations, for instance, whether individual tunnels are needed to gain QOS guarantees for each tunnel), a "tie breaker" may be undertaken.Tunnel ID and Call ID, respectively. Thedetailsinterpretation ofbreaking a tie are documented withthese fields, if present, is described in section 5.2. If thetunnel establishment messages. 6.0.2 Reliable Delivery of Control Messages Since L2TP may run across media where packets may be lost, L2TP may need to retransmit a control message after detecting thatF bit is set, both thepeer never received it. Each tunnel maintains SequenceNr andAcknowledgment values for the control channel, whichNs fields areglobal acrosspresent. Ns indicates thetunnel. When a control message is sent, it is assignedsequence number of thecurrent Sequence number, andpacket being sent. The cur- rent packet will be this sequence number if theSequence counterpayload size isValencia expires February 1997 [Page 15] INTERNET DRAFT April 1996 incremented (wrapping from its maximum 16-bit value to 0). The Acknowledgment field of a control message always reflectsnon-zero, otherwise this packet is only an acknowledgment (sequence number does not advance). Nr indicates thehighest in-order Sequencenext packet sequence number to be receivedfrom(if thepeer. Each tunnel maintains a queue of control messageslast data packet had Ns set to 1, the Nr sent back would betransmit- ted2). Together, these fields can be used to handle out-of-order packets, and to provide flow control for thepeer. The message at the front ofconnection. If thequeueK bit issent with a given sequence number, andset, the Key field isheld until a control message arrives frompresent. Refer to thepeerdescription inwhich the Acknowledgment5.2. The Offset Size fieldindicates receipt of this message. After a timeout interval (a recommended defaultisone second, but this may be altered based on media con- siderations),present if thepacketO bit isretransmitted. The retransmitted packet holdsset in thesame Sequence number, butheader Valencia expires May 1997 [Page 16] INTERNET DRAFT December 1996 flags. This field specifies theAcknowledgment value should be updated to reflect any packet received innumber of bytes past theinterim. If no peer responseL2TP header at which the payload data isdetected after several retransmissions (a recommended defaultexpected to start. It is5, but again mayrec- ommended that data thus skipped bealtered dueinitialized tomedia considerations),0's. If Offset Size is 0, or thetunnel and all sessions within should be cleared. The defaultO bit isto have a single control message outstanding on a given. If a peer specifies a control message window innot set, theStart- Control-Connection-Request and -Reply packets, up tofirst byte following theindicated numberlast byte ofcontrol messages may be sent and held outstanding. 6.0.3L2TP header is the first byte of payload data. 5.4 Control MessageFormat The followingTypes ControlConnection messages are all sent as packets on the established tunnel connection between a given LNS-LAC pair. All data is sent in network order (high order octets first). Any "reserved" or "empty" fields must be sent as 0 values to allow for protocol extensibility. Each controlmessagehas a header, specifiedtypes defined insection 5.2, including an AVPthis specification exist under Vendor ID 0, indicatingthe 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-RequestIETF defined behavior. TheStart-Control-Connection-Request is a L2TP controlactual messageused to initializesemantics are defined in thetunnel between a LNS and a LAC.next section. Thetunnel must be initialized through the exchange of thesecurrently defined control messagesbefore any other L2TP messages can be issued. The establishment of the control connection is startedtypes, grouped bythe initiator of the underlying tunnel. The message is structured as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TPfunction, are: Control MessageHeader | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Message Code (Control Connection Management) Start-Control-Connection-Request| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Version | Valencia expires February 1997 [Page 16] INTERNET DRAFT April 1996 | Framing Capabilities | | Bearer Capabilities | | Tie Breaker | | Firmware Revision | | Host Name | | Vendor Name | | Assigned Tunnel ID | | Control Message Window| | Challenge | +-+-+-+-+-+-+-+-+-+-+-+-+ Start-Control-Connection-Request 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 01 Start-Control-Connection-Reply 2 Start-Control-Connection-Connected 17 Stop-Control-Connection-Request 3 Stop-Control-Connection-Reply 4 Hello 5 (deleted) 6 (Call Management) Outgoing-Call-Request 7 Outgoing-Call-Reply 8 Outgoing-Call-Connected 16 Incoming-Call-Request 90 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 |0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Start-Control-Connection-Request AVP encodes a requestIncoming-Call-Reply 10 Incoming-Call-Connected 11 Call-Clear-Request 12 Call-Disconnect-Notify 13 (Error Reporting) WAN-Error-Notify 14 (PPP Session Control) Set-Link-Info 15 5.5 General Error Codes General error codes pertain toan LNStypes of errors which are not spe- cific toreceive a tunneled PPP session fromany particular L2TP request, but rather to protocol or message format errors. If anLAC. The Attribute field is 1, indicating Start-Control-Connection-Request. The Flags indicate a mandatory option. Details associated with this tunneled session followL2TP reply indicates inadditional AVP's withinits Result Code that a general error occurred, thepacket. 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 9General Error value should be examined to determined what the error was. The currently defined General Error codes and their meanings are: 0 - No general error Valencia expires May 1997 [Page 17] INTERNET DRAFT December 1996 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 56 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 |0 0 0 0 0 0 0 1| 0x01 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 | +-+-+-+-+-+-+-+-+ The Protocol Version AVP within a Start-Control-Connection-Request packet indicates the L2TP protocol version available.- TheAttribute valueCall ID is1, indicating Protocol Version, andinvalid in this context 6 - A generic vendor-specific error occurred in theValue fieldLAC 7 - Try another. If LAC isa 16-bit hexadecimal value 0x100, indicating L2TP proto- col version 1, revision 0.aware of other possible LNS destinations, it should try one of them. ThisAVP mustcan bepresent. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 11 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 |0 0 0 0 0 0 0 1| 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires February 1997 [Page 17] INTERNET DRAFT April 1996 | 0x00 | 0x00 |0|0|0|0|0|0|S|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Framing Capabilities AVP within a Start-Control-Connection- Request indicatesused to guide an LAC based on LNS policy, for instance, thetypeexistence offramingmultilink PPP bundles. Generally, when a value of 6 is used, a vendor-specific AVP will be present also, providing further detail for that vendor implementation. If thesenderlength ofthis mes- sage can provide. The Attribute is 2, it isan AVP indicating amandatory AVP,General Error specifies that the Value field isa 32-bit quantity, withmore than twobits defined. If bit A is set, asynchronous framing is supported. If bit S is set, syn- chronous framing is supported. This AVP must be present. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 11 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 |0 0 0 0 0 0 0 1| 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 | 0x00 |0|0|0|0|0|0|D|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Bearer Capabilities AVP within a Start-Control-Connection- Request indicatesbytes in length, thebearer capabilities thatremaining bytes are an arbitrary string providing further (pos- sibly human readable) text associated with thesendercondition. 6.0 Control Connection Protocol Specification Control Connection messages are used to establish and clear user ses- sions. The first set ofthis message can provide.Control Connection messages are used to maintain the control connection itself. TheAttribute is 3, itcontrol connection isa mandatory AVP,initiated by an LAC or LNS after establishing theValue field isunderlying 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 a32-bit quantitysingle tunnel suffices (generally because of media characteris- tic 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 withtwo bits defined. If bit A is set, analog access is supported. If bit D is set, digi- tal access is supported. This AVP must be present. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 15 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 |0 0 0 0 0 0 0 0| Tie Break... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...(64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Tie Breaker AVP within a Start-Control-Connection-Request con- tains a 64-bit Value used to break ties inthe tunnel establishmentbetweenmessages. 6.0.2 Reliable Delivery of Control Messages Since L2TP may run across media where packets may be lost, an L2TP peer sending aLAC-LNS pair. It is encoded ascontrol message will retransmit theAttribute 4,control message after deciding that its remote peer has notmandatory, with the indicated number of bytes representing the vendor string. This AVPreceived it. The reliable transport mechanism built into L2TP isoptional. If present, it indicates the sender wishesessentially asingle tunnel to exist betweeenlower layer transport service; thegiven LAC-LNS pair,Nr and Ns fields of the control message header belong to thisvalue will be used decide on a single tunnel where both LAC and LNS initiate a tunnel concurrently.transport layer. Therecipienthigher layer functions of L2TP are not concerned with retransmission or order- ing of control messages. Each tunnel maintains aStart-Control-Connection-Request must checkqueue of control messages tosee if a Start-Control-Connection-Request has been Valencia expires February 1997 [Page 18] INTERNET DRAFT April 1996 sentbe transmit- ted to thepeer, and if so, must compare its Tie Breaker value with the received one.peer. Thelower value "wins", andmessage at the"loser" must initiate a tunnel disconnect for their outstanding tunnel. If a tie breaker is received, andfront of theoutstanding Start-Control- Connection-Request had no tie breakerqueue is sent with a given Ns value, and is held until a control message arrives from theinitiatorpeer in whichincludedtheTie Breaker AVP "wins". ItNr field indicates receipt of this Valencia expires May 1997 [Page 18] INTERNET DRAFT December 1996 message. After a fixed (recommended default isrecommended that1 second) or adap- tive (see Appendix D) timeout interval expires without receiving such an acknowledgment, theValuecontrol message packet is retransmit- ted. The retransmitted packet contains the same Ns value, but the Nr value MUST besetupdated to reflect any packets received in theMAC address of a LAN interface on the sender.interim. If noMAC addresspeer response isavailable, a 64-bit random number shoulddetected after several retransmissions (a recommended default is 5, but may beused 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 |0 0 0 0 0 0 0 0| Max (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max (L) | +-+-+-+-+-+-+-+-+ The Firmware Revision AVPaltered due to media consid- erations), the tunnel and all sessions within MUST be cleared. When aStart-Control-Connection- Request indicates the firmware revisiontunnel is being shut down for reasons other than loss of connectivity, theissuing device. The Attribute is 5, it is not a mandatory AVP,state and reliable delivery mechanisms MUST be maintained and operated for theValue field is a 16-bit integer encodedfull 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, avendor specific format. For devices which do not havepeer MUST NOT withhold acknowledgment of packets as afirmware revision (general purpose computers running L2TP software modules,technique forinstance), the revision of theflow controlling control messages. An L2TPsoftware module mayimplementation is expected to bereported instead. This AVPable to keep up with incom- ing control messages, possible responding to some with errors reflecting an inability to honor the requested action. A sliding window mechanism isoptional. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 + length of host name | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 |0 0 0 0 0 0 0 0|Host name... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+used, by default, for control mes- sage transmission. TheHost Name AVP within a Start-Control-Connection-Request indi- cates the DNS name of the issuing LAC or LNS. Itdefault isencoded asto permit four control message to be outstanding on a given tunnel. If a peer specifies a con- trol message window in theAttribute 6, not mandatory, withStart-Control-Connection-Request and -Reply packets, up to the indicated number ofbytes representing the host name string. This AVP is optional. 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 3control 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 45 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (7 + vendor length) |from its peer. 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 "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. Valencia expiresFebruaryMay 1997 [Page 19] INTERNET DRAFTAprilDecember 1996+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 |0 0 0 0 0 0 0 0|Vendor name... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+6.1 Start-Control-Connection-Request TheVendor Name AVP within aStart-Control-Connection-Requestcon- tains a vendor specific string describing the type of LAC or LNS being used. Itisencoded asan L2TP control message used to initialize theAttribute 7, not mandatory, withtunnel between an LNS and an LAC. The tunnel must be initialized through theindicated numberexchange of these control messages before any other L2TP messages can be issued. The establishment ofbytes representingthevendor string. This AVPcon- trol connection isoptional.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 | | Control Message Window| | Challenge | +-+-+-+-+-+-+-+-+-+-+-+-+ Start-Control-Connection-Request 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| 6 |9 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 8 |0 000 0 0 0 1| ID (H)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ID (L)1 |+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheAssigned Tunnel ID AVP within a Start-Control-Connection- Request specifies the Tunnel ID which the peer should use in all subsequent packets. Before the Assigned Tunnel IDAttribute field isreceived, packets should be sent with1, indicating Start-Control-Connection- Request. The Flags indicate aTunnel ID value of 0. It is encoded as the Attribute 8, mandatory,mandatory option. Details associ- ated with this tunneled session follow in additional AVP's within thetwo bytes encoded as a 16-bit non-zero Tunnel ID value. This AVP must be present. Control Message Windowpacket. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |9 |0 0 0 0 0 0 0 0| Window101 | 0x01 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheControl Message WindowProtocol Version AVP within aStart-Control-Connection- Request specifiesStart-Control-Connection-Request packet indicates thenumber of control messages which may be received without waiting for an acknowledgment. ItL2TP protocol version available. The Attribute value isencoded as the Attribute 9, not mandatory, with a single octet101, indicatingthe number of such messages. If absent, the peer must useProtocol Version, and is marked mandatory. This AVP MUST be present. The Value field is a 16-bit Valencia expires May 1997 [Page 20] INTERNET DRAFT December 1996 hexadecimal valueof 1 for the Window. Challenge0x100, indicating L2TP protocol version 1, revi- sion 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7 + length of challenge|1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |10 |0 0 0 0 0 0 0 1| Challenge...102 | 0x00 | 0x00 |Valencia expires February 1997 [Page 20] INTERNET DRAFT April 1996+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Challenge...|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+0x00 |0|0|0|0|0|0|S|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheChallengeFraming Capabilities AVP within aStart-Control-Connection-Request indi- cates that the peer wishes to authenticateStart-Control-Connection- Request indicates thetunnel endpoints. It is encoded astype of framing that theAttribute 10, mandatory, with at least one bytesender ofchallenge value embedded. 6.2 Start-Control-Connection-Replythis mes- sage can provide. TheStart-Control-Connection-ReplyAttribute value isan L2TP control message sent in reply to a received Start-Control-Connection-Request message. This message contains a result code102, indicatingthe result of the control connection establishment attempt.Framing Capabilities, and is marked mandatory. This AVP MUST be present. ThemessageValue field isstructured as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+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 |L2TP Control Message Header0 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Start-Control-Connection-Reply | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Version | | Result Code | | Error Code103 | 0x00 |Framing Capabilities0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 |0|0|0|0|0|0|D|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Bearer Capabilities| | Firmware Revision | | Host Name | | Vendor Name | | Assigned Tunnel ID | | Control Message Window| | Challenge | | Response | +-+-+-+-+-+-+-+-+-+-+-+-+ Start-Control-Connection-ReplyAVP0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 |0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+within a Start-Control-Connection- Request indicates the bearer capabilities that the sender of this message can provide. The Attributefieldvalue is2,103, indicatingStart-Control-Connection- Reply.Bearer Capabilities, and is marked mandatory. This AVP MUST be present. TheFlags indicateValue field is amandatory option. Protocol Version32-bit quantity with two bits defined. If 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 9|0|0|0|0| 14 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 104 | Tie Break Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expiresFebruaryMay 1997 [Page 21] INTERNET DRAFTAprilDecember 1996+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 |0 0 0 0 0 0 0 1| 0x01|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00...(64 bits) |+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheProtocol VersionTie Breaker AVP within aStart-Control-Connection-Reply packet indicates the L2TP protocol version available.Start-Control-Connection-Request con- tains a 64-bit Value used to break ties in tunnel establishment between an LAC-LNS pair. The Attribute value is1,104, indicatingProtocol Version,Tie Breaker, andthe Value fieldisa 16-bit hexadecimal value 0x100, indicating L2TP proto- col version 1, revision 0.marked optional. This AVPmust be present. Framing Capabilitiesitself 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 9|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |2 |0 0 0 0 0 0 0 1| 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+105 |0x00Max (H) |0x00Max (L) |0x00 |S|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheFraming CapabilitiesFirmware Revision AVP within a Start-Control-Connection-ReplyRequest indicates thetypefirmware revision offraming thatthesender of this mes- sage can provide.issuing device. The Attribute value is2, it105, indicating Firmware Revision, and isa mandatory AVP, themarked optional. This AVP itself is optional. The Value field is a32-bit quantity, with two bits defined. If bit A is set, asynchronous framing is supported. If bit S is set, syn- chronous framing is supported. This AVP must16-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 bepresent. Bearer Capabilitiesreported 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 6 + Host name length |9 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 |0 0 0 000 0 1| 0x00| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires May 1997 [Page 22] INTERNET DRAFT December 1996 |0x00 | 0x00106 |Host name... ||D|A|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheBearer CapabilitiesHost Name AVP within aStart-Control-Connection- Reply indicates the bearer capabilities thatStart-Control-Connection-Request indi- cates thesendername ofthis message can provide.the issuing LAC or LNS. The Attribute value is3, it106, indicating Host Name, and isa mandatory AVP, the Value fieldmarked optional. This AVP itself is optional. This name should be as broadly unique as pos- sible; for hosts participating in DNS [4], a32-bit quantityhostname withtwo bits defined. If bit A is set, analog access is supported. If bit D is set, digi- tal access is supported. This AVP mustfully qualified domain would bepresent. Firmware Revisionappropriate. 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 1Valencia expires February 1997 [Page 22] INTERNET DRAFT April 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | 0 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 6 + vendor name len |4 |0 000 0 0 0 0| Max (H)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Max (L)107 |Vendor name... |+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheFirmware RevisionVendor Name AVP within aStart-Control-Connection-Reply indicatesStart-Control-Connection-Request con- tains a vendor specific string describing thefirmware revisiontype ofthe issuing device.LAC or LNS being used. The Attribute value is4, it107, indicating Vendor Name, and isnot a mandatory AVP, themarked optional. This AVP itself is optional. The Valuefieldisa 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),therevisionindicated number of bytes representing theL2TP software module may be reported instead. This AVP is optional. Host Namevendor 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7 + length of host name|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |5 |0 0 0 0 0 0 0 0|Host name...108 | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheHost NameAssigned Tunnel ID AVP within aStart-Control-Connection-Reply indi- cates the DNS name ofStart-Control-Connection- Request specifies theissuing LAC or LNS. It is encoded asTunnel ID which theAttribute 5, not mandatory, withreceiving peer MUST use in theindicated numberTunnel ID field ofbytes representing the host name string.all subsequent packets. The Attribute value is 108, indicating Assigned Tunnel ID, and is marked manda- tory. This AVP MUST be present. Before the Assigned Tunnel ID AVP isoptional. Vendor Namereceived, packets MUST be sent with a Tunnel ID value of 0. The Value is a 16-bit non-zero Tunnel ID value. Control Message Window 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| (7 + vendor length)|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |6 |0 0 0 0 0 0 0 0|Vendor name...109 | Window | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires May 1997 [Page 23] INTERNET DRAFT December 1996 TheVendor NameControl Message Window AVP within aStart-Control-Connection-Reply con- tains a vendor specific string describingStart-Control-Connection- Request specifies thetype of LAC or LNSreceive window size beingused. It is encoded asoffered to the remote peer. The Attribute6, not mandatory, with the indicated number of bytes representing the vendor string.value is 109, indicating Control Mes- sage Window, and is mandatory. This AVP itself is optional.Assigned Tunnel ID 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0Value 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| (7|1|0|0|0| 6 +vendor length)Challenge length | 0 |Valencia expires February 1997 [Page 23] INTERNET DRAFT April 1996+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |7 |0 0 0 0 0 0 0 1| ID (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+110 |ID (L)Challenge... |+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheAssigned Tunnel IDChallenge AVP within aStart-Control-Connection-Reply specifies the Tunnel ID whichStart-Control-Connection-Request indi- cates that the issuing peershould use in all subse- quent packets. It is encoded aswishes to authenticate the tunnel end- points. The Attribute7, mandatory, with the two bytes encoded asvalue is 110, 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 The Start-Control-Connection-Reply is an L2TP control message sent in reply to a16-bit non-zeroreceived 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 | | Error Code | | Framing Capabilities | | Bearer Capabilities | | Firmware Revision | | Host Name | | Vendor Name | | Assigned Tunnel IDvalue. This AVP must be present.| | Control MessageWindowWindow| | Challenge | | Response | +-+-+-+-+-+-+-+-+-+-+-+-+ Start-Control-Connection-Reply AVP 0 1 2 3 Valencia expires May 1997 [Page 24] INTERNET DRAFT December 1996 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 8|1|0|0|0| 6 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |8 |0 0 0 0 0 0 0 0| Window2 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheControl Message Window AVP within a Start-Control-Connection- Reply specifies the number of control messages which may be received without waiting for an acknowledgment. It is encoded as theAttribute8, not mandatory, with a single octetfield is 2, indicatingthe number of such messages. If absent, the peer must useStart-Control-Connection- Reply. The Flags indicate avalue of 1 for the Window. Result Codemandatory 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |9 |0 0 0 0 0 0 0 1| Code201 | 0x01 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheResult CodeProtocol Version AVP within a Start-Control-Connection-Reply packet indicates theresult of the command channel establishment attempt.L2TP protocol version available. TheValue fieldAttribute value is9,201, indicatinga Result Code. The code is a single octet,Protocol Version, andthis AVP is mandatory. Result code values are: 1 - Successful channel establishment 2 - General error--Error Code indicatestheproblem 3 - Command channel already exists 4 - RequesterValue field isnot authorized to establishacommand channel 5 - The protocol16-bit hexadecimal value 0x100, indicating L2TP proto- col versionof the requester is not supported Error Code1, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Valencia expires February 1997 [Page 24] INTERNET DRAFT April 1996 | 8|1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |10 |0 0 0 0 0 0 0 1| Error202 | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This| 0x00 |0|0|0|0|0|0|S|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Framing Capabilities AVPis present only ifwithin a"General Error" exists, in which case Result Code is set to 2 and this AVP encodesStart-Control-Connection- Reply indicates thegeneral error value as documented in section 5.5. It has a Valuetype of10, andframing that the sender of this mes- sage can provide. The Attribute ismarked mandatory. Challenge202, 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. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7 + length of challenge|1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |11 |0 0 0 0 0 0 0 1| Challenge...203 | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Challenge...Valencia expires May 1997 [Page 25] INTERNET DRAFT December 1996 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+0x00 |0|0|0|0|0|0|D|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheChallengeBearer Capabilities AVP within aStart-Control-Connection-Reply indi- cates thatStart-Control-Connection- Reply indicates thepeer wishes to authenticatebearer capabilities that thetunnel initiator. Itsender of this message can provide. The Attribute isencoded as203, it is a mandatory AVP, theAttribute 11, mandatory,Value field is a 32-bit quantity withat least one byte of challenge value embedded. Responsetwo bits defined. If bit A is set, analog access is supported. If bit D is set, digi- tal access is supported. This AVP MUST be present. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 23|0|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |12 |0 0 0 0 0 0 0 1| Response...204 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Max (H) |Response... (128 bits)Max (L) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheResponseFirmware Revision AVP within a Start-Control-Connection-Replypacket provides a response to a challenge received.indicates the firmware revision of the issuing device. The Attributevalueis12, indicating Response, and204, it is not a mandatory AVP, the Value field is a128-bit value reflecting the CHAP-style response to the challenge. This AVP must be present if16-bit integer encoded in achallenge was received, otherwise is omitted.vendor specific format. Forpurposes of the ID value in the CHAP response calculation, the low order byte ofdevices which do not have a firmware revision (general purposes computers running L2TP software modules, for instance), theSequence numberrevision of thechallenge are used. 6.3 Start-Control-Connection-Connected The Start-Control-Connection-Connected message is anL2TPcontrol message sent in reply to a received Start-Control-Connection-Reply message.software module may be reported instead. Thismessage provides closure to the tunnel establishment process, and includes a challenge response if the peer sent a chal- lenge in the Start-Control-Connection-Reply message. The message is Valencia expires February 1997 [Page 25] INTERNET DRAFT April 1996 structured as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start-Control-Connection-Connected | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response | +-+-+-+-+-+-+-+-+-+-+-+-+ Start-Control-Connection-ReplyAVP 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7|0|0|0|0| 6 + Host name length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |17 |0 0 0 0 0 0 0 1|205 |Host name... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Host Name AVP within a Start-Control-Connection-Reply indi- cates the name of the issuing LAC or LNS. See the notes in sec- tion 6.1 concerning Host Name contents. It is encoded as the Attributefield205, not mandatory, with the indicated number of bytes representing the host name string. This AVP is17, indicating Start-Control-Connection- Connected. The Flags indicate a mandatory option. Responseoptional. 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 len |23 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 |0 0 000 0 0 1| Response...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Response... (128 bits)206 |Vendor name... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires May 1997 [Page 26] INTERNET DRAFT December 1996 TheResponseVendor Name AVP within aStart-Control-Connection-Connected packet provides a response toStart-Control-Connection-Reply con- tains achallenge received. The Attribute value is 1, indicating Response, andvendor specific string describing theValue fieldtype of LAC or LNS being used. It isa 128-bit value reflecting the CHAP-style response to the challenge. This AVP must be present if a challenge was received, otherwise is omitted. For purposes of the ID value in the CHAP response calcu- lation,encoded as thelow order byte ofAttribute 206, not mandatory, with theSequenceindicated number of bytes representing thechallenge are used. 6.4 Stop-Control-Connection-Request The Stop-Control-Connection-Request is an L2TP control message sent by one peer of a 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 Reason field. The message is structured as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires February 1997 [Page 26] INTERNET DRAFT April 1996 | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stop-Control-Connection-Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+ Stop-Control-Connection-Requestvendor 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7|1|0|0|0| 6 + length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |3 |0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute field is 3, indicating Stop-Control-Connection- Request.207 | ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheFlags indicateAssigned Tunnel ID AVP within amandatory option. The Flags indi- cateStart-Control-Connection-Reply specifies the Tunnel ID which the receiving peer MUST use in all subsequent packets. It is encoded as the Attribute 207, manda- tory, with amandatory option. The single Reason16-bit non-zero Tunnel ID value. This AVPmust follow this. ReasonMUST be present. Control Message Window 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 |0 0 0 0 0 0 0 1| Reason208 | Window | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheReason octet indicates the reason forControl Message Window AVP within a Start-Control-Connection- Reply specifies the number of controlconnection closure. Values are: 1 - General request to clear control connection 2 - Can't support peer's versionmessages which may be received without waiting for an acknowledgment. It is encoded as the Attribute 208, not mandatory, with a 16-bit word indicating the number of such messages. If absent, theprotocol 3 - Requester is being shut down 6.5 Stop-Control-Connection-Reply The Stop-Control-Connection-Reply is an L2TP control message sent by onepeerofMUST use aLAC-LNS control connection upon receiptvalue ofa Stop- Control-Connection-Request from4 for theother peer. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stop-Control-Connection-Reply | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Window. Result Code| +-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires February 1997 [Page 27] INTERNET DRAFT April 1996 Stop-Control-Connection-Reply AVP0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |4 |0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+209 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheAttributeResult Code AVP within a Start-Control-Connection-Reply packet indicates the result of the control channel establishment attempt. The Value field is4,209, indicatingStop-Control-Connection- Reply.a Result Code. TheFlags indicatecode is amandatory option.16-bit word, and this AVP is mandatory. This AVP MUST be present. Result code values are: Valencia expires May 1997 [Page 27] INTERNET DRAFT December 1996 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 Error 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| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 |0 0 0 0 0 0 0 1| Result210 | Error | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The| Optional Message... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP is present only if a "General Error" exists, in which case Resultoctet indicates the result of the attemptCode was set toclose2 and this AVP encodes thecontrol connection.general error value as documented in section 5.5. It has a Value of1210, and is marked mandatory.Valid Result Code values are: 1 - Control connection closed 2 - Control connection not closed for reason indicated in Error Code Error CodeChallenge 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 8|1|0|0|0| 6 + length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |2 |0211 | Challenge... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Challenge AVP within a Start-Control-Connection-Reply indi- cates that the peer wishes to authenticate the tunnel initiator. It is encoded as the Attribute 211, 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. 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| 22 | 01| Error| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This| 212 | Response... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response... (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Response AVP within a Start-Control-Connection-Reply packet provides a response to a challenge received. The Attribute value Valencia expires May 1997 [Page 28] INTERNET DRAFT December 1996 is 212, 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 presentonlyif a"General Error" exists, in which case Result Code is set to 2challenge was received and thisAVP encodesStart-Control-Connection-Reply indicates suc- cess. For purposes of thegeneral errorID valueas documentedinsection 5.5. It has a Valuethe CHAP response calcula- tion, the low order byte of2, and is marked mandatory. 6.6 Echo-Requestthe Sequence number of the challenge is used. 6.3 Start-Control-Connection-Connected TheEcho-RequestStart-Control-Connection-Connected message isaan L2TP control message sentby either peer ofin reply to aLAC-LNS control connection.received Start-Control-Connection-Reply message. Thiscontrolmessageis used asprovides closure to the tunnel establishment process, and includes a"keep Alive" forchallenge response if thecontrol connection. The receivingpeerissues an Echo-Reply to each Echo-Request received. Keepalives should be implemented by sending an Echo-Request once every 5 seconds if 60 seconds have passed sincesent amessage has been Valencia expires February 1997 [Page 28] INTERNET DRAFT April 1996 received from the peer. If an Echo-Reply has not been receivedchal- lenge in20 seconds, the connection should be closed. These are guideline val- ues; actual values may need to vary based on the requirements of a particular tunnel media. Echoes are global to the tunnel;theCall ID field of these control messages must be 0.Start-Control-Connection-Reply message. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Echo-RequestStart-Control-Connection-Connected | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |IdentifierResponse | +-+-+-+-+-+-+-+-+-+-+-+-+Echo-RequestStart-Control-Connection-Connected 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7|1|0|0|0| 6 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |5 |0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+17 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute field is5,17, indicatingEcho-Request.Start-Control-Connection- Connected. The Flags indicate a mandatory option.IdentifierResponse 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 11|1|0|0|0| 22 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 |0 0 0 0 0 0 0 1| ID...1701 | Response... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |... 32-bitsResponse... (128 bits) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheIdentifierResponse AVPhas anwithin a Start-Control-Connection-Connected packet provides a response to a challenge received. The Attributeof 1,value is 1701, indicating Response, and theAVPValue field ismarked mandatory. The ID set in thea 128-bit valueof this AVP is set by the sender ofreflecting theEcho-Request and can be usedCHAP-style response tomatch the reply withthecorresponding request.challenge. This AVP isoptional. 6.7 Echo-Reply The Echo-Reply ismarked mandatory, and MUST be present if aL2TP control message sent back upon receipt of an Echo-Request. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+challenge Valencia expiresFebruaryMay 1997 [Page 29] INTERNET DRAFTAprilDecember 1996 was received, otherwise MUST be omitted. For purposes of the ID value in the CHAP response calculation, the low order byte of the Sequence number of the challenge are used. 6.4 Stop-Control-Connection-Request The Stop-Control-Connection-Request 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 Reason field. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Echo-ReplyStop-Control-Connection-Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |IdentifierAssigned Tunnel ID | | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+Echo-ReplyStop-Control-Connection-Request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7|1|0|0|0| 6 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |6 |0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute field is6,3, indicatingEcho-Reply.Stop-Control-Connection- Request. The Flags indicate a mandatory option. The Flags indi- cate a mandatory option.IdentifierThe single Reason AVP MUST follow this. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 11|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 |0 0 0 0 0 0 0 1| ID... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+301 |... 32-bitsAssigned Tunnel ID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheIdentifier AVP has anAttributeof 1,value is 301, indicating Assigned Tunnel ID, andthe AVPis marked mandatory.If an Echo-Request is received with this AVP,This AVP MUST be present. The Value MUST be the sameAVP (with identical ID) isAssigned Tunnel ID first sentback into theEcho-Reply packet. Otherwise thisreceiving peer. This AVPis not included in the Echo-Reply. 6.8 Outgoing-Call-Request The Outgoing-Call-Request is a L2TP control message sent bypermits theLNSpeer to identify theLAC to indicate thatappropriate tunnel even if Stop-Control-Connection-Request must be sent before anoutbound call from the LNSAssigned Tunnel ID isto 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. The message is structured as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outgoing-Call-Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Call ID | | Call Serial Number | | Minumum BPS | | Maximum BPS | | Bearer Type |received. Reason Valencia expiresFebruaryMay 1997 [Page 30] INTERNET DRAFTAprilDecember 1996| Framing Type | | Packet Recv. Window | | Packet Processing Delay | | Phone Number | | Sub-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Outgoing-Call-Request AVP0 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 |7 | L2TP Message Type0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |7 |0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+302 | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheOutgoing-Call-RequestAttribute value is 302, indicating Reason, and is marked mandatory. This AVPencodesMUST be present. The Value is a 16-bit word indicates the reason for the control connection closure. Values are: 1 - General request to clear control connection 2 - Can't support peer's version of the protocol 3 - Requester is being shut down 6.5 Stop-Control-Connection-Reply The Stop-Control-Connection-Reply is anLAC to establishL2TP control message sent by one peer of anoutgoing call. The flags indicateLAC-LNS control connection upon receipt of amandatory option. Assigned Call IDStop- Control-Connection-Request from the other peer. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stop-Control-Connection-Reply | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+ Stop-Control-Connection-Reply 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 |9 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 |0 0 0 000 0 1| ID (H)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ID (L)4 |+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheAssigned Call ID AVP encodes the ID being assigned to call by the LNS.Attribute field is 4, indicating Stop-Control-Connection- Reply. TheflagsFlags indicate a mandatory option.ID value is a unique identifier, unique to a tunnel, assigned by the LNS to this session. It is used to multiplex and demultiplex data sent over that tunnel between the LNS and LAC. This AVP must be present. Call Serial NumberResult 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 9|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |2 |0 0 0 0 0 0 0 1| Number (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+401 |Number (L)Result |+-+-+-+-+-+-+-+-+ Call Serial Number AVP encodes an identifier assigned by the LNS to this call. The flags indicate a mandatory option. The Number value (Call Serial Number) is an identifier used by the LNS and the LAC+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expiresFebruaryMay 1997 [Page 31] INTERNET DRAFTAprilDecember 1996for identifying the call. Unlike the Call ID, both the LNSThe Attribute value is 401, indicating Result Code, andLAC associate the same Call Serial Number with a given call.is marked mandatory. This AVPmustMUST be present.Minimum BPSThe Value is a 16-bit word indicating the result of the attempt to close the control connec- tion. Values are: 1 - Control connection closed 2 - Control connection not closed for reason indicated in Error Code Error 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 11|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |3 |0 0 0 0 0 0 0 1| BPS (H)402 | Error | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |BPS (L)Optional Message... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Minimum BPS+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute value is 402, indicating Error Code, and is marked mandatory. This AVP is present only if a "General Error" exists, in which case the Value encodes thelowest acceptable line speed for this call. The flags indicate a mandatory option. The BPSgeneral error valueindi- cates the speedas docu- mented inbits/second.section 5.5. 6.6 Hello The Hello message is an L2TP control message sent by either peer of a LAC-LNS control connection. ThisAVP mustcontrol message is used as a "keepalive" for the control connection. Keepalives should bepresent. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 11 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 |0 0 0 0 0 0 0 1| BPS (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BPS (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum BPS AVP encodesimplemented by sending a Hello once every 60 seconds if 60 seconds have passed without sending a message to thehighest acceptable line speed forpeer. 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 reli- ably sent by the lower level transport, thiscall. The flags indicatekeepalive function oper- ates by causing the transport level to reliably deliver amandatory option. The BPS value indi- catesmessage. If a media interruption has occurred, thespeed in bits/second. This AVP mustreliable transport will bepresent. Bearer Typeunable 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 AVP 0 1 2 3 Valencia expires May 1997 [Page 32] INTERNET DRAFT December 1996 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 11|0|0|0|0| 6 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5|0 0 0 0 0 0 0 1|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.| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Theflags indicate a mandatory option.The Attribute valuebit field indi- catesis 5, indicating Hello, and is marked optional. 6.7 (Deleted) This section has been deleted. 6.8 Outgoing-Call-Request The Outgoing-Call-Request is an L2TP control message sent by thebearer capabilityLNS 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 outgoingcall. Bit A if set indicates thatcalls. The first message requests thecall should be on an analog channel. Bit D if setcall; the second indicates that the callshould be on a digital chan- nel. Both bits set indicatewas successfully initiated. The third and final message indicates that the callcan be of either type. Valencia expires February 1997 [Page 32] INTERNET DRAFT April 1996 This AVP must be present.was established. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outgoing-Call-Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Call ID | | Call Serial Number | | Minimum BPS | | Maximum BPS | | Bearer Type | | Framing Type | | Packet Recv. Window | | Packet Processing Delay | | Phone Number | | Sub-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Outgoing-Call-Request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 11|1|0|0|0| 6 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |6 |0 0 0 0 0 0 0 1|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 Type7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires May 1997 [Page 33] INTERNET DRAFT December 1996 The Outgoing-Call-Request AVP encodesthe framing type for the requesteda request to an LAC to establish an outgoing call. The flags indicate a mandatory option.The value bit field indi- cates 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. This AVP must be present. Packet Receive Window SizeAssigned Call ID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 9|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |7 |0 0 0 0 0 0 0 1| Size (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+701 |Size (L)Call ID |+-+-+-+-+-+-+-+-+ Packet Recieve Window Size+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Assigned Call ID AVP encodes thewindow sizeID beingadvertisedassigned to this call by theLNS for this call.LNS. Theflags indicate a manda- tory option.Attribute value is 701, indicating Assigned Call ID, and is marked mandatory. This AVP MUST be present. TheSizeLAC places this valueindicatesin thenumberCall ID header field ofreceived dataall command and payload packets that it subsequently transmits over theLNS will buffer fortunnel that belong to this call.This AVPThe Call ID value isoptional. Packet Processing Delay AVPan 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 9|1|0|0|0| 6 + length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |8 |0 0 0 0 0 0 0 1| Delay (H)702 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delay (L)Number... |+-+-+-+-+-+-+-+-+ Packet Processing Delay+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Call Serial Number AVP encodesthe delay LNS has for process- ing window full of packets sentan identifier assigned by theLAC. The flags indicate a mandatory option. The Delay valueLNS to this call. Attribute isspecified in units of 1/10 seconds.702, indicating Call Serial Number, and is marked mandatory. This AVPis optional. Refer to appendix A to see a Valencia expires February 1997 [Page 33] INTERNET DRAFT April 1996 description of how thisMUST be present. The Number value isdeterminedan identifier used by the LNS andused. Phonethe LAC for identifying the call. Unlike the Call ID, both the LNS and LAC associate the same Call Serial Number with a given call. This AVP MUST be present, and the Number MUST be at least one octet in length. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7 + N|1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |9 |0 0 0 0 0 0 0 1| Phone Number..| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+703 |Phone Number ...BPS (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Phone Number| BPS (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires May 1997 [Page 34] INTERNET DRAFT December 1996 Minimum BPS AVP encodes thephone number tolowest acceptable line speed for this call. Attribute is 703, Minimum BPS, and is marked mandatory. This AVP MUST becalled. The flags indicate a mandatory option.present. ThePhone NumberBPS valueis an ASCII string. The length of the string isindicates thelengthspeed inthe AVP header minus 7 bytes. This AVP is optional. Sub-Address AVPbits/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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7 + N|1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |10 |0 0 0 0 0 0 0 1| Sub-Address ..| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+704 |Sub-Address ...BPS (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Sub-Address| BPS (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum BPS AVP encodesadditional dialing information. The flags indicate a mandatory option. The Sub-Address value is an ASCII string. The length ofthestringhighest acceptable line speed for this call. Attribute isthe length in the AVP header minus 7 bytes.704, indicating Maximum BPS, and is marked mandatory. This AVPis optional. 6.9 Outgoing-Call-Reply The Outgoing-Call-Reply is a L2TP control message sent by the LAC to the LNS in response to a received Outgoing-Call-Request message.MUST be present. ThereplyBPS value indicates theresult of the outgoing call attempt. It also provides information to the LNS about 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. The message is structured as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outgoing-Call-Reply | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Call ID | | Result Code | | Error Code | Valencia expires February 1997 [Page 34] INTERNET DRAFT April 1996 | Cause Code | | Connect Speed | | Framingspeed in bits/second. Bearer Type| | Packet Recv. Window | | Packet Processing Delay | | Physical Channel Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Outgoing-Call-ReplyAVP 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7|1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |8705 |0 0 0 0 0 0 01| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Outgoing-Call-Reply AVP encodes a result of an outgoing call request. The flags indicate a mandatory option. Assigned Call ID AVP01 2 301 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 |0|0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 1|0 0 0 0 0 0 01| ID (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID (L) | +-+-+-+-+-+-+-+-+ The Assigned Call ID0 0 0 0 0 0 0|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bearer Type AVP encodes theID being assigned to call bybearer type for theLAC.requested call. Theflags indicate a mandatory option. IDvalue bit field Attribute is 705, indicating Bearer Type, and is marked mandatory. This AVP MUST be present. The Value is aunique identifier, unique to a tunnel, assigned by32-bit quantity indicating theLNS tobearer capability required for thissession. It is used to multiplex and demultiplex data sent overoutgoing call. If set, bit A indicates thattunnel betweentheLNS and LAC. This AVP mustcall should bepresent. Result Codeon 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 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 8|1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |2706 |0 0 0 0 0 0 01| Result Code |0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Result Code AVP encodes the result of the Outgoing-Call-Request. The flags indicate a mandatory option. The Result Code value can be one of the following: 1 - Call established with no errors|0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expiresFebruaryMay 1997 [Page 35] INTERNET DRAFTAprilDecember 19962 - Outgoing Call not establishedFraming Type AVP encodes the framing type for thereason indicated in Error Code 3 - Outgoing Call failed due to no carrier detected 4 - Outgoing Call failed due to detectionrequested call. Attribute is 706, indicating Framing Type, and is marked manda- tory. This AVP MUST be present. The 32-bit field indicates the type ofa busy signal 5 - Outgoing Call failed duePPP framing tolack of a dial tone 6 - Outgoing Call was not established within time allotted by LAC 7 - Outgoing Call administratively prohibited This AVPbe used for the outgoing call. Bit A if set indicates that asynchronous framing should be used. Bit S ismandatory. Error Codeset indicates that synchronous framing should be used. Packet Receive Window Size 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |3 |0 0 0 0 0 0 0 1| Error Code707 | Size (H) | Size (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Error CodePacket Receive Window Size AVPis used to encode a specific error code in caseencodes theresultwindow size being advertised by the LNS for this call. Attribute is 707, indicating Packet Receive Window, and is marked mandatory. This AVPindicates a General Error. The flags indicate a mandatory option.is optional. The Size valuecan be oneindicates the number of received data packets thegeneral error IDs specified in Section 5.5. This AVPLNS will buffer for this call, which isoptional. Cause Codealso the maxi- mum 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 pay- load session for this call. Packet Processing Delay 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |4 |0 0 0 0 0 0 0 1| Error Code708 | Delay (H) | Delay (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheCause CodePacket Processing Delay AVPis used to give additional information in case of call failure. The flags indicate a mandatory option. The Code value can vary depending uponencodes thetype of call attempted. For ISDN call attempts it isdelay LNS has for pro- cessing a window full of packets sent by theQ.931 cause code. Connect SpeedLAC. Attribute is 708, 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. Phone Number 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| 6 + Phone Number len |11 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 |000 0 0 0 0 1| BPS (H)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |BPS (L)709 | Phone Number..| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Connect Speed BPS AVP encodes the speed for the connection. The flags indicate a mandatory option. The BPS value indicates the speed in bits/second. This AVP must be present if the call attempt isValencia expiresFebruaryMay 1997 [Page 36] INTERNET DRAFTAprilDecember 1996successful. Framing TypePhone Number AVP encodes the phone number to be called. Attribute is 709, indicating Phone Number, and is marked mandatory. This AVP MUST be present. The Phone Number value is an ASCII string. Sub-Address 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 11|1|0|0|0| 6 + Sub-Address len | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |6 |0 0 0 0 0 0 0 1|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|710 | Sub-Address ..| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Framing TypeSub-Address AVP encodes additional dialing information. Attribute is 710, indicating Sub-Address, and is marked mandatory. This AVP is optional. The Sub-Address value is an ASCII string. 6.9 Outgoing-Call-Reply The Outgoing-Call-Reply is an L2TP control message sent by theframing type forLAC to thecall. The flags indicateLNS in response to amandatory option.received Outgoing-Call-Request message. Thevalue bit fieldreply indicates whether or not thetype of PPP framingLAC isused forable to attempt thecall. Bit A if set indicates that Asynchronous framing is being used. Bit S is set indicates that Syn- chronous framing is being used. This AVP must be present ifout- bound call and also returns certain parameters regarding the callattempt is successful. Packet Receive Window Sizeattempt. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outgoing-Call-Reply | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Call ID | | Result Code | | Error Code | | Connect Speed | | Physical Channel Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Outgoing-Call-Reply 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| 6 |9 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 |0 0 0 0 000 1| Size (H)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Size (L)8 |+-+-+-+-+-+-+-+-+ Packet Recieve Window Size+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Outgoing-Call-Reply AVP encodesthe window size being adver- tised by the LAC for this call.an immediate result of attempting an outgoing call request. The flags indicate a mandatory option.The Size value indicates the number of received data packets the LAC will buffer for this call. This AVP is optional. Packet Processing DelayAssigned Call ID AVP 0 1 2 3 Valencia expires May 1997 [Page 37] INTERNET DRAFT December 1996 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 9|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |8 |0 0 0 0 0 0 0 1| Delay (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+801 |Delay (L)Call ID |+-+-+-+-+-+-+-+-+ Packet Processing Delay+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Assigned Call ID AVP encodes thedelay LAC has for processing window full of packets sentID being assigned to this call by theLNS. The flags indicate a mandatory option. The Delay valueLAC. Attribute isspecified in units of 1/10 seconds.801, indicating Assigned Call ID, and is marked mandatory. This AVP MUST be present. Call ID value isoptional. Please referan identifier, unique within the tunnel, assigned by the sender toappendix A to see a Valencia expires February 1997 [Page 37] INTERNET DRAFT April 1996 descriptionthis session. The remote peer MUST place this Call ID in the Call ID por- tion ofhowall future packets it sends associated with thisvaluesession. It isdeterminedused to multiplex andused. Physical Channel IDdemultiplex data sent over that tunnel between the LNS and LAC. Result Code 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 11|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |9 |0802 | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Result Code AVP encodes the result of the Outgoing-Call-Request. Attribute is 802, indicating Result Code, and is marked mandatory. This AVP MUST be present. The Result Code is a 16-bit value indicat- ing: 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 Error Code 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 | 01| ID (H)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ID (L)803 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Physical Channel IDError Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Message... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Error Code AVPencodes the vendor specific physical channel numberis usedforto encode a specific error code in case thecall. The flags indicateresult AVP indicates amandatory option. The valueGeneral Error. Attribute isused for logging purposes only.803, indicat- ing Error Code, and is marked mandatory. This AVP isoptional. 6.10 Incoming-Call-Request The Incoming-Call-Request is a 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 inpresent only if Valencia expires May 1997 [Page 38] INTERNET DRAFT December 1996 the"three-way handshake" used by L2TP for establishing incoming calls.Result Code indicates a value of 2. TheLAC may defer answering the call until it has received an Incoming-Call-Reply from the LNS indi- cating that the call shouldvalue can beestablished. This mechanism allows the LNS to obtain sufficient information about the call before it is answered to determine whetherone of thecall should be answered or not. The message is structured as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Incoming-Call-Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Call ID | | Call Serial Number | | Call Bearer Type | | Physical Channel Id | | Dialed Number | | Dialing Number | | Sub-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Incoming-Call-Requestgeneral error IDs specified in Section 5.5. Connect Speed 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7|1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Valencia expires February 1997 [Page 38] INTERNET DRAFT April 1996|9 |0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Incoming-Call-Request804 | BPS (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BPS (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Connect Speed BPS AVP encodesan incoming call being indi- cated bytheLAC.speed for the connection. Theflags indicateAttribute value is 804, indicating Connect Speed, and is marked mandatory. This AVP MUST be present if the Result indicates amandatory option. Assigned Callcall is in progress. The BPS is a 16-bit value indicating the speed in bits/second. Physical Channel ID 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 9|1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 |0 0 0 0 0 0 0 1|805 | ID (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID (L) |+-+-+-+-+-+-+-+-+ The Assigned Call+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Physical Channel ID AVP encodes theID being assigned to call byvendor specific physical channel number used for theLAC.call. Theflags indicate a mandatory option. IDAttribute value is 805, indicating Physical Channel ID, and is marked optional. This AVP itself is optional. ID is aunique identifier, unique to a tunnel, assigned32-bit value in network byte order. The value is used for logging purposes only. 6.10 Outgoing-Call-Connected 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 thissession. It ismessage. This message provides information to the LNS about the particular parameters used for the call. It provides information tomultiplex and demultiplex data sent over that tunnel betweenallow the LNSand LAC. This AVP must be present. Call Serial Numberto regulate the transmission of data to the LAC for this session. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outgoing-Call-Connected | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires May 1997 [Page 39] INTERNET DRAFT December 1996 | Result Code | | Error Code | | Cause Code | | Connect Speed | | Framing Type | | Packet Recv. Window | | Packet Processing Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Outgoing-Call-Connected 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| 6 |9 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 |0 0 0 000 0 1| Number (H)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Number (L)16 |+-+-+-+-+-+-+-+-+ Call Serial Number+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Outgoing-Call-Connected AVP encodesan identifier assigned bytheLAC to this call.final result of an outgo- ing call request. The flags indicate a mandatory option.The Number value (Call Serial Number) is an identifier used by the LNS and the LAC for identifying the call. Unlike the Call ID, both the LNS and LAC asso- ciate the same Call Serial Number with a given call. This AVP must be present. Call Bearer Type AVPResult 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 11|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |3 |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0|1601 | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires February 1997 [Page 39] INTERNET DRAFT April 1996 Call Bearer Type AVP encodes the bearer type for the incoming call. The flags indicate a mandatory option.Thevalue bit fieldResult Code indicates thebearer capability being used by the incoming call. Bit A if set indicates thatresult of the call attempt. The Attribute value ison an analog channel. Bit D if set indi- cates that the call1601, indicating Result Code, and ison a digital channel.marked mandatory. This AVPmustMUST bepre- sent. Physical Channel IDpresent. The Result Code is a 16-bit value: 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 Error Code 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 11|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |4 |0 0 0 0 0 0 0 1| ID (H)1602 | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires May 1997 [Page 40] INTERNET DRAFT December 1996 |ID (L)Optional Message... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Physical Channel ID+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Error Code AVPencodes the vendor specific physical channel numberis usedfor the call. The flags indicateto encode amandatory option. The valuespecific error code. Attribute isused for logging purposes only.1602, indicating Error Code, and is marked mandatory. This AVP isoptional. Dialed Numberpresent only if the Result Code indicates a value of 2. The value is encoded as specified in Section 5.5. Cause Code 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7|0|0|0|0| 9 +NAdvisory Msg len | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |5 |0 0 0 0 0 0 0 1| Number...1603 | Cause Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Number...Cause Msg |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dialed NUmberAdvisory Msg ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Cause Code AVPencodesis used to give additional information in cases of call failure. The Attribute value is 1603, indicating Cause Code, and is marked mandatory. This AVP is optional. It is only relevant when thedialed numberLAC uses Q.931/DSS1 for theincoming call. The flags indicate a mandatory option. The valueoutbound call attempt. Cause Code isan ASCII string. The length ofthenumberreturned Q.931 Cause code and Cause Msg is thelengthreturned Q.931 message code (e.g., DISCONNECT) associ- ated 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 AVPheader minus 7. This AVP is optional. Dialing Numberlength) to further explain the call failure. Connect Speed 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7 + N|1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |6 |0 0 0 0 0 0 0 1| Number...1604 | BPS (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Number...BPS (L) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dialing NUmber+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Connect Speed BPS AVP encodes theoriginating numberfinal negotiated speed for theincoming call. The flags indicate a mandatory option.connection. The Attribute value isan ASCII Valencia expires February 1997 [Page 40] INTERNET DRAFT April 1996 string. The length of the number1604, indicating Connect Speed, and isthe length in the AVP header minus 7.marked mandatory. This AVP MUST be present if the call attempt isoptional. Sub-Addresssuccessful. The BPS value indicates the speed in bits/second. Framing Type 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7 + NValencia expires May 1997 [Page 41] INTERNET DRAFT December 1996 |1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |71605 |0 0 0 0 0 0 01| Sub-Address...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Address ... |0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Sub-Address|0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Framing Type AVP encodesadditional dialing information. The flags indicate a mandatory option.the framing type for the call. TheSub-AddressAttribute value isan ASCII string. The length of the string1605, indicating Framing Type, and isthe length in the AVP header minus 7 bytes.marked mandatory. This AVPis optional. 6.11 Incoming-Call-Reply The Incoming-Call-Reply is a L2TP control message sent by the LNS toMUST be present if theLAC in response to a received Incoming-Call-Request message.call attempt is suc- cessful. Thereplyvalue bit field indicates theresult of the incoming call attempt. It also provides information to allow the LAC to regulate the transmissiontype ofdata to the LNS for this session. This messagePPP framing isthe second in the three-way handshakeusedby L2TPforestablishing incoming calls. It indicates to the LAC whetherthecall should be answered or not. The messagecall. If set, bit A indicates that asynchronous framing isstructured as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Incoming-Call-Reply | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Call ID | | Result Code | | Error Code | |being used. If set, bit S indicates that synchronous framing is being used. PacketRecv.Receive Window Size| | Packet Transmit Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Incoming-Call-ReplyAVP 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |10 |0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires February 1997 [Page 41] INTERNET DRAFT April 1996 The Incoming-Call-Reply1606 | Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet Receive Window Size AVP encodesa response by the LNS totheincoming call indication givenwindow size being offered by theLAC.LNS for this call. Theflags indicateAttribute value is 1606, indicating Packet Receive Window Size, and is marked mandatory. The Size is amandatory option. Assigned Call ID16-bit value indicating the number of received data packets the LAC will buffer for this call, which is also the maxi- mum 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 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 9|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 |0 0 0 0 0 0 0 1| ID (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+1607 |ID (L)Delay |+-+-+-+-+-+-+-+-+ The Assigned Call ID+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet Processing Delay AVP encodes theID being assigned to calldelay the LAC expects for processing a window full of packets sent by the LNS. Theflags indicate a mandatory option. IDAttribute value isa unique identifier, unique1607, indicating Packet Processing Delay, and is marked mandatory. This AVP is optional. The Delay value is specified in units of 1/10 seconds. Refer toa tunnel, assigned by the LNSAppendix A to see a description of how thissession. Itvalue isused to multiplexdetermined anddemultiplex dataused. Valencia expires May 1997 [Page 42] INTERNET DRAFT December 1996 6.11 Incoming-Call-Request Incoming-Call-Request is an L2TP control message sentover that tunnel betweenby the LAC to the LNSandto indicate that an inbound call is to be established from the LAC. ThisAVP mustrequest 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 bepresent. Result Codeestablished. 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 | | Call Bearer Type | | Physical Channel Id | | Dialed Number | | Dialing Number | | Sub-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Incoming-Call-Request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 8|1|0|0|0| 7 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |2 |0 0 0 0 0 0 0 1| Result Code9 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Result Code+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Incoming-Call-Request AVP encodes an incoming call being indi- cated by theresult of the Incoming-Call-Request.LAC. The flags indicate a mandatory option.The Result Code value can be one of the following: 1 - The LAC should answer the incoming call 2 - The IncomingAssigned Callshould 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 This AVP is mandatory. Error CodeID 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |3 |0 0 0 0 0 0 0 1| Error Code901 | Call ID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Valencia expiresFebruaryMay 1997 [Page42]43] INTERNET DRAFTAprilDecember 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheError CodeAssigned Call ID AVPis usedencodes the Call ID being assigned toencode a specific error code in casecall by theresult AVP indicates a General Error. The flags indicate a mandatory option.LAC. The Attribute valuecanis 901, indicating Call ID, and is marked mandatory. This AVP MUST beonepresent. The LNS places this value in the Call ID header field of all command and payload packets that it subsequently transmits over thegeneral error IDs specified in Section 5.5. This AVPtunnel that belong to this call. The Call ID value isoptional. Packet Receive Window Sizean 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 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 9|1|0|0|0| 6 + Number length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |4 |0 0 0 0 0 0 0 1| Size (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+902 |Size (L)Number... |+-+-+-+-+-+-+-+-+ Packet Recieve Window Size+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Call Serial Number AVP encodesthe window size being adver- tisedan identifier assigned by theLNS forLAC to this call. Theflags indicate a mandatory option.Attribute value is 902, Call Serial Number, and is marked mandatory. This AVP MUST be present. TheSizeNumber valueindicatesis an identifier assigned by thenumber of received packetsLAC and used by the LNSwill bufferand the LAC forthisidentifying the call.This AVP is optional. Packet Processing DelayUnlike the Call ID, both the LNS and LAC asso- ciate the same Call Serial Number with a given call. Call Bearer Type 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 9|1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |5903 |0 0 0 0 0 0 01| Delay (H) |0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Delay (L) | +-+-+-+-+-+-+-+-+ Packet Processing Delay|0 0 0 0 0 0 0 0 0 0 0 0 0 0|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Call Bearer Type AVP encodes thedelay LNS hasbearer type forprocessing window full of packets sent bytheLAC. The flags indicate a manda- tory option.incoming call. TheDelayAttribute value isspecified in units of 1/10 seconds.903, Call Bearer Type, and is marked manda- tory. This AVPis optional. Please refer to appendix A to see a descrip- tion of how this value is determined and used. 6.12 Incoming-Call-ConnectedMUST be present. TheIncoming-Call-Connected messageValue is aL2TP 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 in32-bit field indi- cating thethree-way handshakebearer capability being used byL2TP for establishing incoming calls. It provides a mechanism for providingtheLNS with additional information aboutincoming call. If set, bit A indicates that the call is on an analog channel. If set, bit D indicates thatcannot, in general, be obtained atthetime the Incoming-Call-Requestcall isissued by the LAC. The message is structured as: Valencia expires February 1997 [Page 43] INTERNET DRAFT April 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Incoming-Call-Connected | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connect Speed | | Framing Type | | Packet Recv. Window | | Packet Processing Delay | | Initial LCP Conf | | Last Sent LCP Conf | | Last Received LCP Conf | | Proxy authen type | | Proxy authen name | | Proxy authen challenge | | Proxy authenon a digital channel. Physical Channel ID| | Proxy authen response | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Incoming-Call-ConnectedAVP 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7|1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires May 1997 [Page 44] INTERNET DRAFT December 1996 |11 |0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Incoming-Call-Connected904 | ID (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Physical Channel ID AVP encodesa response by the LAC totheIncoming-Call-Reply message sent byvendor specific physical channel number used for theLAC.call. Theflags indicateAttribute value is 904, Physical Chan- nel ID, and is marked mandatory. The presence of this AVP is optional. ID is amandatory option. Connect Speed32-bit value in network byte order. The value is used for logging purposes only. Dialed Number 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 11|1|0|0|0| 6 + Number len | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 |0 0 0 0 0 0 0 1| BPS (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+905 |BPS (L)Number... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Connect Speed BPSDialed Number AVP encodes thespeeddialed number for theconnection. The flags indicate a mandatory option.incoming call, that is, DNIS. TheBPSAttribute valueindicates the speed in bits/second. Thisis 905, Dialed Number, and is marked mandatory. The presence of this AVPmust be present if the call attemptissuc- cessful. Framing Typeoptional. The value is an ASCII string. Dialing Number 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 1Valencia expires February 1997 [Page 44] INTERNET DRAFT April 1996+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 11|1|0|0|0| 6 + length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |2 |0 0 0 0 0 0 0 1|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|906 | Number... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Framing TypeDialing Number AVP encodes theframing typeoriginating number for thecall. The flags indicate a mandatory option.incoming call, that is, CLID. The Attribute valuebit field indicates the type of PPP framing is used for the call. Bit A if set indicates that Asynchronous framingisbeing used. Bit S is set indicates that Syn- chronous framing906, Dialing Number, and isbeing used. Thismarked mandatory. The presence of this AVPmust be present if the call attemptissuccessful. Packet Receive Window Sizeoptional. The value is an ASCII string. Sub-Address 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| 6 + length |11 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 |0 0 000 0 0 1| Size (H)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Size (L)907 |+-+-+-+-+-+-+-+-+ Packet Recieve Window SizeSub-Address...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Address AVP encodesthe window size being adver- tisedadditional dialing information. The Attribute value is 907, Sub-Address, and is marked mandatory. The presence of this AVP is optional. The Sub-Address value is an ASCII Valencia expires May 1997 [Page 45] INTERNET DRAFT December 1996 string. 6.12 Incoming-Call-Reply The Incoming-Call-Reply is an L2TP control message sent by the LNS to the LACfor this call. The flags indicatein response to amandatory option.received Incoming-Call-Request message. TheSize valuereply indicates thenumberresult ofreceived packetsthe incoming call attempt. It also provides information to allow the LACwill buffer for this call. This AVPto regulate the transmission of data to the LNS for this session. This message isoptional.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 | | Error Code | | Packet Recv. Window Size | | Packet Processing Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Incoming-Call-Reply 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| 6 |9 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 |0 0 0 000 0 1| Delay (H)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Delay (L)10 |+-+-+-+-+-+-+-+-+ Packet Processing Delay+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Incoming-Call-Reply AVP encodes a response by thedelay LAC has for processing window full of packets sentLNS to the incoming call indication given by theLNS.LAC. The flags indicate amanda- torymandatory option.The Delay value is specified in units of 1/10 seconds. ThisAssigned Call ID AVPis optional. Please refer to appendix A to see a descrip- tion of how this value is determined and used. Initial LCP Conf0 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 1Valencia expires February 1997 [Page 45] INTERNET DRAFT April 1996+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7 + length of confreq|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |5 |0 0 0 0 0 0 0 0| LCP confreq...|1001 | Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheLAC may have answered the phone call and negotiated LCP with the dial-in client in order to establishAssigned Call ID AVP encodes theclient's apparent identity. In this case, this option may be includedID being assigned toindicate the link prop- ertiescall by theclient requested in its initial LCP CONFREQ request.LNS. TheValue fieldAttribute value isa copy of the body of the intial CONFREQ received, starting at the first option within this packet's body.1001, 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 Valencia expires May 1997 [Page 46] INTERNET DRAFT December 1996 subsequently transmits over the tunnel that belong to this call. The Call ID value ismarked not mandatory,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 AVPitself is optional. Last Sent LCP Conf0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7 + length of confreq|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |6 |0 0 0 0 0 0 0 0| LCP confreq...|1002 | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+See Initial LCP Conf above for rationale. The Value field is a copy ofResult Code AVP encodes thebodyresult of thefinal CONFREQ sent to the client to complete LCP negotiation, starting at the first option within this packet's body.Incoming-Call-Request. The Attribute value is 1002, Result Code, and is marked mandatory. This AVP MUST be present. The Result Code value ismarkeda 16-bit value: 1 - The LAC should answer the incoming call 2 - The Incoming Call should notmandatory, andbe 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 Error Code AVPitself is optional. Last Received LCP Conf0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7 + length of confreq|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |7 |0 0 0 0 0 0 0 0| LCP confreq...|1003 | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+See Initial LCP Conf above for rationale. The Value field| Optional Message... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP is present only if acopy of the body of the final CONFREQ received from the client"General Error" exists, in which case Result Code was set tocomplete LCP negotiation, starting at the first option within2 and thispacket's body. ThisAVP encodes the general error value as documented in section 5.5. It has a Value of 1003, and is markednot mandatory, and themandatory. Packet Receive Window Size AVPitself is optional. Proxy authen type0 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |8 |0 0 0 0 0 0 0 0| Type1004 | Size (H) | Size (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet Receive Window Size AVP encodes the receive window size being offered by the LNS for this call. The Attribute value is 1004, Valencia expiresFebruaryMay 1997 [Page46]47] INTERNET DRAFTAprilDecember 1996This AVPPacket Receive Window Size, and is markedmandatory, andmandatory. 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. This AVPitself must be present. Typeisa byte, holding a value: 1 - Textual username/password exchange 2 - PPP CHAP 3 - PPP PAP 4 - None Associated AVP'soptional if Sequence and Acknowledgment Numbers are not to be used in the payload session foreach type of authentication follow. Proxy authen namethis call. Packet Processing Delay 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7 + length of name|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |9 |0 0 0 0 0 0 0 0| Name...1005 | Delay (H) | Delay (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ThisPacket Processing Delay AVPis marked mandatory, andencodes theAVP itself must be presentdelay the LNS expects forProxy authen type values 1, 2,processing a window full of packets sent by the LAC. The Attribute value is 1005, Packet Processing Delay AVP, and3.is marked mandatory. TheName field contains the namepresence 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.13 Incoming-Call-Connected 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 theclient's authentication response.LNS about particular parameters used for the call. It also provides information to allow the LNS to regu- late 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 | | Packet Recv. Window | | Packet Processing Delay | | Initial LCP Conf | | Last Sent LCP Conf | | Last Received LCP Conf | | Proxy authen type | | Proxy authen name | | Proxy authen challenge | | Proxy authen ID | Valencia expires May 1997 [Page 48] INTERNET DRAFT December 1996 | Proxy authen response | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Incoming-Call-Connected 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7 + length of challenge|1|0|0|0| 6 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |10 |0 0 0 0 0 0 0 0| Challenge...11 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP is marked mandatory, and the AVP itself must be present for Proxy authen type 2.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheChallenge field containsIncoming-Call-Connected AVP encodes a response by thevalue pre- sentedLAC to theclientIncoming-Call-Reply message sent by the LAC.Proxy authen IDThe flags indicate a mandatory option. Connect Speed 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 8|1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |11 |0 0 0 0 0 0 0 0| ID1101 | BPS (H) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This| BPS (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Connect Speed BPS AVP encodes the speed for the connection. The Attribute value ismarked mandatory,1101, Connect Speed, andtheis marked mandatory. This AVPitself mustMUST be presentfor Proxy authen type 2. The ID field containsif thebyte IDcall attempt is successful. The valuepre- sented to the client byis a 32-bit quantity indicating theLACspeed inits associated CHAP challenge. Proxy authen response Valencia expires February 1997 [Page 47] INTERNET DRAFT April 1996bits/second. Framing Type 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7 + length of Response|1|0|0|0| 10 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |121102 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|Response... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This|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 ismarked mandatory,1102, Call Serial Number, andtheis marked mandatory. This AVPitself mustMUST be presentfor Proxy authen types 1, 2, and 3.if the call attempt is successful. TheResponsevalue is a 32-bit bit fieldcontains the client's response toindicating thechallenge. For Proxy authentype2, this field containsof PPP framing used for theresponse value received by the LAC. For types 1 or 3, it contains the clear text password received from the client by the LAC. 6.13 Call-Clear-Request The Call-Clear-Request is a L2TP control message sent by the LNS to the LAC indicatingcall. If set, bit A indicates thata particular callasynchronous framing isto be disconnected. The callbeingcleared can be either an incoming or outgoing call, in any state. The LAC responds to this message with a Call-Disconnect- Notify message. The messageused. If set, bit S indicates that synchronous framing isstructured as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call-Clear-Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Call-Clear-Requestbeing used. Valencia expires May 1997 [Page 49] INTERNET DRAFT December 1996 Packet Receive Window Size 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |12 |0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Call-Clear-Request1103 | Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet Receive Window Size AVP encodesa request bytheLNS towindow size being offered by the LACto disconnect thefor this call. Theflags indicate a mandatory option. 6.14 Call-Disconnect-Notify The Call-Disconnect-Notify messageAttribute value isa L2TP control message sent by the LAC to the LNS. It1103, Packet Receive Window Size, and isissued whenever a callmarked mandatory. This AVP isdisconnected, dueoptional if Sequence and Acknowledgment Numbers are not to be used in thereceipt bypay- load session for this call. The 16-bit Size value indicates theLACnum- ber ofa Call-Clear-Request orreceived data packets the LAC will buffer forany other reason. Its purposethis call, which isto informalso theLNSmaximum number of data packets thedisconnection and the reason why the disconnection occured. The message is struc- tured as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires February 1997 [Page 48] INTERNET DRAFT April 1996 | Call-Disconnect-Notify | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | | Error Code | | Cause Code | | Call Statistics | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Call-Disconnect-NotifyLNS should send before waiting for an acknowledgment. Packet Processing Delay 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |13 |0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Call-Disconnect-Nofity1104 | Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet Processing Delay AVP encodesa disconnect indication fromthe delay the LACtoexpects for processing a window full of packets sent by the LNS. Theflags indicate a mandatory option. Result CodeAttribute value is 1104, Packet Processing Delay, and is marked mandatory. The presence of this AVP is optional. The 16-bit Delay value is speci- fied in units of 1/10 seconds. Refer to Appendix A to see a descrip- tion of how this value is determined and used. Initial LCP Conf 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 8|0|0|0|0| 6 + LCP confreq len | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 |0 0 0 0 0 0 0 1| Result Code1105 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Result Code AVP encodes the reason for disconnect.LCP confreq...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Theflags indi- cate a mandatory option.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 prop- erties the client requested in its initial LCP CONFREQ request. TheResult CodeAttribute valuecan be oneis 1105, Initial LCP Conf, and is marked optional. The presence of this AVP is optional. The Value field is a copy of thefollowing: 1 (Lost Carrier) - Call disconnected due to lossbody ofcarrier 2 (General Error) - Call disconnected forthereason indicated in Error Code. 3 (Admin Shutdown) - Call disconnected for administrative reasons 4 (Request) - Call disconnected due to received Call-Clear-Request This AVP is mandatory. Error Code AVPinitial CONFREQ received, starting at the first option within this packet's body. Valencia expires May 1997 [Page 50] INTERNET DRAFT December 1996 Last Sent LCP Conf 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 8|0|0|0|0| 6 + LCP confreq len | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |2 |0 0 0 0 0 0 0 1| Error Code1106 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+LCP confreq...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See Initial LCP Conf above for rationale. TheError Code AVPAttribute value isused to encode a specific error code in case Valencia expires February 1997 [Page 49] INTERNET DRAFT April 1996 the result AVP indicates a General Error. The flags indicate a mandatory option.1106, Last Sent LCP Conf, and is marked optional. Thevalue can be onepresence ofthe general error IDs specified in Section 5.5. Thisthis AVP is optional.Cause Code AVPThe Value field is a copy of the body of the final CONFREQ sent to the client to complete LCP negotiation, start- ing at the first option within this packet's body. Last Received LCP Conf 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 8|0|0|0|0| 6 + LCP confreq len | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |3 |0 0 0 0 0 0 0 1| Error Code1107 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+LCP confreq...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See Initial LCP Conf above for rationale. TheCause Code AVPAttribute value isused to give additional information in case1107, Last Received LCP Conf, and is marked optional. The presence ofunsolicited call disconnection.this AVP is optional. Theflags indicateValue field is amandatory option. The Code value can vary depending uponcopy of thetypebody ofcall. For ISDN call attempts it istheQ.931 cause code. Call Statistics AVPfinal CONFREQ received from the client to complete LCP negotia- tion, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7 + N|1|0|0|0| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |4 |0 0 0 0 0 0 0 1| Call Stats... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+1108 |Call Statistics ...Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheCall Statistics AVP is used by the LAC to send vendor specific call statistics for logging purposes. The flags indicate a mandatory option. The Call StatisticsAttribute value isab ASCII string containing ven- dor specific call statistics that LNS can log for diagnostic pur- poses. The length of the string1108, Proxy Authen Type, and isthe length in the AVP header minus 7.marked manda- tory. This AVPis optional. 6.15 WAN-Error-NotifyMUST be present. TheWAN-Error-Notify messagevalue Type is aL2TP control message sent by the LAC to the LNS to indicate WAN error conditions (conditions that occur on the interface supporting PPP). The counters in this message are cumulative. This message should only be sent when an error occurs, and not more than once every 60 seconds. The counters are reset when16-bit word, holding anew call is established. The message is structured as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WAN-Error-Notify | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+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 expiresFebruaryMay 1997 [Page50]51] INTERNET DRAFTAprilDecember 1996WAN-Error-Notify AVP0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 7|0|0|0|0| 6 + length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |14 |0 0 0 0 0 0 0 1|1109 | Name... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TheWAN-Error-Nofity AVP encodes lineAttribute value is 1109, Proxy Authen Name, andother errors sent by the LAC to the LNS. The flags indicate a mandatory option. Call Errorsis marked manda- tory. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 32|0|0|0|0| 6 + length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |14 |0 01110 | Challenge... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute value is 1110, 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 01| Reserved |1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 8 |CRC Errors0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Framing Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+1111 |Hardware OverrunsID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Buffer Overruns |The Attribute value is 1111, Proxy Authen ID, and is marked manda- tory. The AVP itself MUST be present for Proxy authen type 2. The ID field contains the byte ID value presented to the client by the LAC in its associated CHAP challenge. 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 + length |Time-out Errors0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Alignment Errors1112 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Response... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires May 1997 [Page 52] INTERNET DRAFT December 1996 TheCall Errors AVPAttribute value isused by the LAC to send error information to the LNS.1112, Proxy Authen Response, and is marked mandatory. Theflags indicate a mandatory option.AVP itself MUST be present for Proxy authen types 1, 2, and 3. ThevalueResponse field contains thefollowing fields: Reserved - Not used CRC Errors - Number of PPP framesclient's response to the challenge. For Proxy authen type 2, this field contains the response value receivedwith CRC errors since session was established Framing Errors - Number of improperly framed PPP packetsby the LAC. For types 1 or 3, it contains the clear text password receivedHardware Overruns - Number of receive buffer over-runs since ses- sion was established Buffer Overruns - Numberfrom the client by the LAC. In the case ofbuffer over-runs detected since ses- sion was established Time-out Errors - Numbercleartext passwords, use oftime-outs sincethe AVP H bit is recommended. 6.14 Call-Clear-Request The Call-Clear-Request is an L2TP control message sent by the LNS to the LAC indicating that a particular callwas established Alignment Errors - Number of alignment errors sinceis to be disconnected. The callwasbeing cleared can be either an incoming or outgoing call, in any state. The LAC responds to this message with a Call-Disconnect- Notify message. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call-Clear-Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+ Call-Clear-Request 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| 6 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Call-Clear-Request AVP encodes a request by the LNS to the LAC to disconnect the call. The flags indicate a mandatory option. Assigned Call ID 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1201 | Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This attribute is used to provide the LAC with the Call ID assigned by the LNS for the call to be cleared in the case where the LNS has not yet learned the LAC's Call ID for the call. The Attribute value is 1201, Assigned Call ID, and is marked mandatory. This AVP MUST be present. The value Call ID MUST be the same value sent from the LNS to the LAC in the initial call setup exchange. Valencia expires May 1997 [Page 53] INTERNET DRAFT December 1996 6.15 Call-Disconnect-Notify The Call-Disconnect-Notify message is an L2TP control message sent by the LAC to the LNS. It is issued whenever a call is disconnected, due to the receipt by the LAC of a Call-Clear-Request or for any other reason. Its purpose is to inform the LNS of the disconnection and the reason why the disconnection occurred. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call-Disconnect-Notify | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | | Error Code | | Cause Code | | Assigned Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Call-Disconnect-Notify 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| 6 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 13 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Call-Disconnect-Notify AVP encodes a disconnect indication from the LAC to the LNS. The flags indicate a mandatory option. Result Code 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1301 | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Result Code AVP encodes the reason for disconnect. The Attribute value is 1301, Result Code, and is marked mandatory. This AVP MUST be present. The Result Code value can be one of: 1 (Lost Carrier) - Call disconnected due to loss of carrier 2 (General Error) - Call disconnected for the reason indicated in Error Code. 3 (Admin Shutdown) - Call disconnected for administrative reasons 4 (Request) - Call disconnected due to received Call-Clear-Request Error Code AVP Valencia expires May 1997 [Page 54] INTERNET DRAFT December 1996 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1302 | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Message... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP is present only if a "General Error" exists, in which case Result Code was set to 2 and this AVP encodes the general error value as documented in section 5.5. The Attribute value is 1302, Error Code, and is marked mandatory. This AVP MUST be present if Result Code was 2. Cause Code 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1303 | Cause Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional message... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Cause Code AVP is used to give additional information in case of unsolicited call disconnection. The Attribute value is 1303, 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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1304 | 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 con- nection to be terminated even before the LNS has provided its own Assigned Call ID to this LAC (the Call ID field in the control Valencia expires May 1997 [Page 55] INTERNET DRAFT December 1996 message header is 0). The Attribute value is 1304, Assigned Call ID, and is marked mandatory. This AVP MUST be present. 6.16 WAN-Error-Notify The WAN-Error-Notify message is an L2TP control message sent by the LAC to the LNS to indicate WAN error conditions (conditions that occur on the interface supporting PPP). The counters in this message are cumulative. This message should only be sent when an error occurs, and not more than once every 60 seconds. The counters are reset when a new call is established. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WAN-Error-Notify | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WAN-Error-Notify 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| 6 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 14 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The WAN-Error-Notify AVP encodes line and other errors sent by the LAC to the LNS. The flags indicate a mandatory option. Call Errors 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| 32 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1401 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Framing Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hardware Overruns | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Buffer Overruns | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time-out Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Alignment Errors | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires May 1997 [Page 56] INTERNET DRAFT December 1996 The Call Errors AVP is used by the LAC to send error information to the LNS. The Attribute value is 1401, WAN-Error-Notify, and is marked mandatory. This AVP MUST be present. The value contains the following fields: Reserved - Not used, MUST be 0 CRC Errors - Number of PPP frames received with CRC errors since session was established Framing Errors - Number of improperly framed PPP packets received Hardware Overruns - Number of receive buffer over-runs since ses- sion was established Buffer Overruns - Number of buffer over-runs detected since ses- sion was established Time-out Errors - Number of time-outs since call was established Alignment Errors - Number of alignment errors since call was established 6.17 Set-Link-Info 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 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| 6 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Set-Link-Info AVP encodes ACCM information sent from the LNS to the LAC after it is negotiated in LCP. The flags indicate a manda- tory option. ACCM 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| 32 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valencia expires May 1997 [Page 57] INTERNET DRAFT December 1996 | 1501 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Send ACCM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive ACCM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ACCM AVP is used by the LNS to inform LAC of the ACCM to the LNS. The Attribute value is 1501, ACCM, and is marked mandatory. The presence of this AVP is optional. 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 spe- cific 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 retransmis- sion 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 connec- tion 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. 7.2 Control Connection States Control messages are carried over the same media as the payload mes- sages which are carried following successful connection establish- ment. The L2TP control connection protocol is not distinguishable between the LNS and LAC, but is distinguishable between the origina- tor and receiver. The originating peer is the one which first estab- lishes 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 situation. 7.2.1 Control Connection Originator State Event Action New State ----- ----- ------ --------- idle Open request Send wait-ctl-reply Valencia expires May 1997 [Page 58] INTERNET DRAFT December 1996 Start-Control- Connection-Request wait-ctl-reply Collision If terminating, idle clean-up. wait-ctl-reply Collision If not terminating, wait-stop-reply Send Stop-Control- Connection-Request wait-ctl-reply Receive If version OK established Start-Control- Send Start-Control- Connection-Reply Connection-Connected wait-ctl-reply Receive If version not OK wait-stop-reply Start-Control- or bad auth, Send Connection-Reply Stop-Control- Connection-Request establishedThis AVP must be present. 6.16 Set-Link-Info Valencia expires February 1997 [Page 51] INTERNET DRAFT April 1996Local terminate Send wait-stop-reply Stop-Control- Connection-Request established Receive Send idle Stop-Control- Stop-Control- Connection- Connection-Reply Request and clean-up wait-stop-reply Receive Clean-up idle Stop-Control- Connection-Reply idle TheSet-Link-Info message is a L2TPcontrolmessage sent by the LNSconnection originator attempts tothe LACopen a connection toset PPP-negotiated options. Because these options can change at any timethe peer during idle state. When thelife ofconnection is open, thecall,originator transmits a send Start-Control-Connection-Request and then enters theLAC must be ablewait-ctl-reply state. wait-ctl-reply The originator checks toupdate its internal call information dynamicallysee if another connection has been requested from the same peer, andperform PPP negotiation on an active PPP session. The messageif so, handles the collision situation described in Section 6.0.1. When a Start-Control-Connection-Reply isstructured as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set-Link-Info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACCM | +-+-+-+-+-+-+-+-+-+-+-+-+-+ Set-Link-Info 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 15 |0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Set-Link-Info AVP encodes ACCM informationreceived, it is examined for a compatible version. If the version of the reply is lower than the version sentfromin the request, the older (lower) version should be used provided it is supported. If the version in the reply is earlier and supported, theLNSoriginator moves to theLAC after itestab- lished state. If the version isnegotiated in LCP. The flags indicateearlier and not supported, amanda- tory option. ACCM 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 14 |0 0 0 0 0 0 0 1| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Send ACCM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive ACCM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ACCM AVP is usedStop-Control-Connection-Request SHOULD be sent to the peer and the originator moves into the wait-stop-reply state. established An established connection may be terminated by either a local Valencia expires May 1997 [Page 59] INTERNET DRAFT December 1996 condition or theLNS to inform LACreceipt of a Stop-Control-Connection-Request. In theACCM toevent of a local termination, theLNS. The flags indicateoriginator MUST send amandatory option. The value containsStop- Control-Connection-Request and enter the wait-stop-reply state. If the originator receives a Stop-Control-Connection-Request it SHOULD send a Stop-Control-Connection-Reply and close the connec- tion. wait-stop-reply If a Stop-Control-Connection-Reply is received, the connection SHOULD be closed and the control connection becomes idle. 7.2.2 Control connection Receiver State Event Action New State ----- ----- ------ --------- idle Receive If version not OK idle Start-Control- send Connection-Request Start-Control- Connection-Reply with error idle Receive Version OK, send wait-ctl-reply Start-Control- Start-Control- Connection-Request Connection-Reply wait-ctl-reply Receive Clean-up, send idle Stop-Control- Stop-Control- Connection-Request Connection-Reply wait-ctl-reply Receive If auth OK established Start-Control- Connection-Connected wait-ctl-reply Receive If auth not OK wait-stop-reply Start-Control- SendACCM andStop-Control- Connection- Connection-Request Connected established ReceiveACCM fields. TheClean-up, sendACCM 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.idle Stop-Control- Stop-Control- Connection-Request Connection-Reply established Local terminate Send wait-stop-reply Stop-Control- Connection-Request wait-stop-reply Receive Clean-up idle Stop-Control- Connection-Reply idle Thedefault values used by the LACcontrol connection receiver waits forboth these fields are 0xFFFFFFFF. This AVP must be present. 6.17 No-op The No-op message isan incoming connection attempt. When notified of aL2TP control message sent by either side. Its primary purpose isnew connection, it should prepare toupdate the Acknowledgment window for the peerValencia expiresFebruaryMay 1997 [Page52]60] INTERNET DRAFTAprilDecember 1996+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |receive L2TPControl Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | No-op | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ No-op 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16 |0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Valuemessages. When a Start-Control-Connection-Request isset to 16,received its version field MUST be examined. If the version is earlier than the receiver's version and the earlier version can be supported by the receiver, the receiver SHOULD send a Start-Control-Connection-Reply. If the version is earlier than the receiver's version and the version cannot be supported, the receiver SHOULD send a Start-Connection-Reply message indicatingNo-op. The flags indicatethis error and remain in the idle state. If the receiver's version is the same as or earlier than the peer's, the receiver SHOULD send amandatory option. 7.0 Control Connection State MachinesStart-Control-Connection-Reply with the receiver's version and enter the wait-ctl-reply state. wait-ctl-reply Thecontrol messages defined in section 6 are exchanged by way of state tables definedpeer waits in thissection. Tables are defined for incoming call placement, outgoing call placement, as well as for initiation ofstate after sending a Start-Control-Connection-Reply. If it receives a Start-Control-Connection-Reply, it checks to see if thetunnel itself. Themessage is properly authenticated and, if so, it enters the established state. If authentication fails, a Stop-Control-Connection-Request with the reason code set appropriately is sent and wait-stop-reply statetables do not encode timeoutis entered. if a Stop-Control-Connection-Request is received, a Stop-Control-Connection-Reply. is issued andretransmis- sion behavior, as thisidle state ishandled inentered. established An established connection may be terminated by either a local condition or theunderlying semantics defined in 6.0.2. 7.1 Control Connection Protocol Operation This section describesreception of a Stop-Control-Connection-Request. In theoperationevent ofvarious L2TP control connec- tion functionsa local termination, the originator MUST send a Stop-Control-Connection-Request and enter theControl Connection messages which are used to support them. Receipt of an invalid or malformed Control Connection message should be logged appropriately,wait-stop-reply state. If the originator receives a Stop-Control-Connection-Request it SHOULD send a Stop-Control-Connection-Reply and close the connection. wait-stop-reply If a Stop-Control-Connection-Reply is received, thecontrolconnectionshouldSHOULD be closed andrestarted to ensure recovery into a known state. 7.2 Control Connection States The control connection relies on a standard TCP connection for its service. The L2TPthe controlconnection protocol is not distinguishable betweenconnection becomes idle. 7.3 Timing considerations Because of the real-time nature of telephone signaling, both the LNS andLAC, but is distinguishable between the origina- torLAC should be implemented with multi-threaded architectures such that messages related to multiple calls are not serialized andreceiver.blocked. Theoriginating peercall 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 theone which first estab- lishes the tunnel. Since eitherLACor LNS can be the originator, a collision can occur. See Section 6.0.1 forwhen an associated telephone line rings. The LAC selects adescription of thisCall ID andits resolution situation. 7.2.1 Control Connection Originator (may be LAC or LNS) State Event Action New State ----- ----- ------ --------- idle Open request Send wait_ctl_replyserial number and indicates the call bearer type. Modems should always Valencia expiresFebruaryMay 1997 [Page53]61] INTERNET DRAFTAprilDecember 1996Start-Control- Connection-Request wait_ctl_reply Collision If terminating, idle clean-up. wait_ctl_reply Receive If version OK established Start-Control- Send Start-Control- Connection-Reply Connected-Connected wait_ctl_reply Receive If version not OK wait_stop_reply Start-Control-indicate analog call type. ISDN calls should indicate digital when unrestricted digital service orbad auth, Send Connection-Reply Stop-Control- -Connection-Request established Local terminate Send Stop-Control- wait_stop_reply -Connection-Request wait_stop_reply Receive clean-up idle Stop-Control- Connection-Reply idle The control connection originator attempts to open a connection to the peer during idle state. When the connectionrate adaption isopen, the originator transmits a send Start-Control-Connection-Requestused andthen entersanalog if digital modems are involved. CLID, DNIS, and subaddress may be included in thewait_ctl_reply state. wait_ctl_reply The originator checks to seemessage ifanother connection has been requestedthey are available from thesame peer, and if so, handlestelephone network. Once the LAC sends thecollision situation described in Section 6.0.1. When a Start-Control-Connection-Reply is received,Incoming-Call-Request, itis examinedwaits for acompatible version. If the version ofresponse from thereply is lower thanLNS but it does not necessarily answer theversion sent incall from therequest,telephone network yet. The LNS may choose not to accept theolder (lower) version should be used provided itcall if: - No resources are available to handle more sessions - The dialed, dialing, or subaddress fields are not indicative of an authorized user - The bearer service issupported.not authorized or supported If theversion in the reply is earlier and supported, the originator movesLNS chooses to accept theestab- lished state. Ifcall, it responds with an Outgoing-Call-Reply which also indicates window sizes (see Appendix B). When theversion is earlier and not supported, a Stop-Control-Connection- Request SHOULD be sentLAC receives the Outgoing-Call-Reply, it attempts to connect thepeer andcall, assuming theoriginator moves intocalling party has not hung up. A final call connected message from thewait_stop_reply state. established An established connection may be terminated by either a local con- dition orLAC to thereceipt of a Stop-Control-Connection-Request. InLNS indicates that theevent of a local termination,call states for both theoriginator MUST send a Stop- Control-Connection-RequestLAC and the LNS should enter thewait_stop_replyestablished state.IfWhen theoriginator receives a Stop-Control-Connection-Request it SHOULD send a Stop-Control-Connection-Replydialed-in client hangs up, the call is cleared normally andclosetheconnec- tion. wait_stop_reply Valencia expires February 1997 [Page 54] INTERNET DRAFT April 1996LAC sends a Call-Disconnect-Notify message. If the LNS wishes to clear aStop-Control-Connection-Reply is received, the connection SHOULD be closedcall, it sends a Call-Clear-Request message andthe control connection becomes idle. 7.2.2 Control connection Receiver (may bethen waits for a Call-Disconnect-Notify. 7.4.1 LACor LNS)Incoming Call States State Event Action New State ----- ----- ------ --------- idle Ring OR Send wait-reply Ready to indicate Incoming-Call-Request incoming conn. wait-reply ReceiveIf version not OK idle Start-Control- send Connection-Request Start-Control- Connection-Reply with errorClean-up idle Incoming-Call-Reply Not Accepting wait-reply ReceiveVersion OK, sendAnswer call establishedStart-Control- Start-Control- Connection-Request Connection-Reply wait_ctl_reply Receive clean-up, send idle Stop-Control- Stop-Control- Connection-Request Connection-Reply wait_ctl_reply Receive If auth OKIncoming-Call-Reply Send Accepting Incoming-Call-Connected wait-reply Abort Clean-up idleStart-Control- Connection- Connected wait_ctl_reply Receive If auth not OK wait-stop-reply Start-Control-SendStop-Control- Connection- Connection-Request ConnectedCall-Disconnect- Notify established Receiveclean-up,Hang-up and send idleStop-Control- Stop-Control- Connection-Request Connection-ReplyCall-Clear-Request Call-Disconnect-Notify establishedLocal terminatetelco line drop Sendwait-stop-reply Start-Control- Connection-Request wait-stop-reply Receive clean-upidleStop-Control- Connection-ReplyCall-Disconnect-Notify Valencia expires May 1997 [Page 62] INTERNET DRAFT December 1996 established local disconnect Send idle Call-Disconnect-Notify Thecontrol connection receiver waitsstates associated with the LAC for incoming calls are: idle The LAC detects an incomingconnection attempt. When notifiedcall on one ofan new connection, it should prepare to receive L2TP messages. When a Start-Control-Connection-Request is receiveditsversion field should be examined. If the version is earlier than the receiver's version and the earlier version can be supported by the receiver, the receiver SHOULD send a Start-Control- Connection-Reply. If the versiontelco interfaces. Typically this means an analog line isearlier than the receiver's version and the version cannot be supported, the receiver SHOULD send Valencia expires February 1997 [Page 55] INTERNET DRAFT April 1996 a Start- Connection-Reply message, closeringing or an ISDN TE has detected an incoming Q.931 SETUP message. The LAC sends an Incoming- Call-Request message and moves to theTCP connectionwait-reply state. wait-reply The LAC receives an Incoming-Call-Reply message indicating non- will- ingness to accept the call (general error or don't accept) andremain inmoves back into the idle state. If thereceiver's version is the same as earlier than the peer's,reply message indicates that thereceiver SHOULD send a Start-Control- Connection-Reply withcall is accepted, thereceiver's versionLAC sends an Incoming-Call-Connected message andenterenters the established state. establishedAn established connectionData is exchanged over the tunnel. The call may beterminated by either a local condition orcleared follow- ing: An event on thereception oftelco connection. The LAC sends aStop-Control-Connection-Request. In the eventCall- Disconnect-Notify message Receipt of a Call-Clear-Request. The LAC sends a Call-Disconnect- Notify message A localtermination, the originator MUST sendreason. The LAC sends aStop- Control-Connection-Request and enter the wait_stop_reply state.Call-Disconnect-Notify message. 7.4.2 LNS Incoming Call States State Event Action New State ----- ----- ------ --------- idle Receive Ifthe originator receives a Stop-Control-Connection-Request it SHOULD send a Stop-Control-Connection-Reply and close the connection. wait_stop_replynot accepting idle Incoming-Call-Request Send Incoming-Call-Reply with Error idle Receive Ifa Stop-Control-Connection-Reply is received, the connection SHOULD be closed and the control connection becomes idle. 7.3 Timing considerations Because of the real-time nature of telephone signaling, both the LNS and LAC should be implementedaccepting wait-connect Incoming-Call-Request Send Incoming-Call-Reply wait-connect Receive Clean-up idle Call-Disconnect-Notify wait-connect Receive Get ready for data established Incoming-Call-Connect established Receive Clean-up idle Call-Disconnect-Notify established Local terminate Send wait- Valencia expires May 1997 [Page 63] INTERNET DRAFT December 1996 Call-Clear-Request disconnect wait- Receive Clean-up idle disconnect Call-Disconnect-Notify The states associated withmulti-threaded architectures such that messages related to multiplethe LNS for incoming callsareare: idle An Incoming-Call-Request message is received. If the request is notserialized and blocked. The callacceptable, an Incoming-Call-Reply is sent back to the LAC andconnection state figures do not specify exceptions caused by timers. These are addressedthe LNS remains inSection 6.0.2. 7.4 Incoming calls Anthe idle state. If the Incoming-Call-Request message isgenerated byacceptable, an Incoming-Call-Reply is sent indicating accept in the result code. The session moves to the wait-connect state. wait-connect If the session is still connected on the LAC, the LACwhensends anassociated telephone line rings.incoming call connect message to the LNS which then moves into established state. The LACselectsmay send aCall ID and serial number and indicates the call bearer type. Modems should always indicate analog call type. ISDN calls shouldCall-Disconnect-Notify to indicatedigital when unrestricted digital service or rate adaption is used and analog if digital modems are involved. Dialing number, dialed number, and subaddress maythat the incoming caller could not beincludedconnected. This could happen, for example, if a telephone user accidentally places a standard voice call to an LAC resulting in a handshake failure on the called modem. established The session is terminated either by receipt of a Call-Disconnect- Notify messageif they are availablefrom thetelephone network.LAC or by sending a Call-Clear-Request. Once a Call-Clear-Request has been sent, theLAC sendssession enters theIncoming-Call-Request, it waits forwait-disconnect state. wait-disconnect Once aresponse from the LNS but does not answerCall-Disconnect-Notify is received thecall fromsession moves back to thetelephone network. Theidle state. 7.5 Outgoing calls Outgoing calls are initiated by an LNSmay choose notand instruct an LAC toaccept theplace a callif: - No resourceson a telco interface. There areavailable to handle more sessions -three messages for outgoing calls: Outgoing-Call-Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. Thedialed, dialing, or subaddress fields are not indicative ofLNS sends anauthorized user - The bearer service is not authorized or supported IfOutgoing-Call-Request specifying theLNS choosesdialed party phone number and subaddress as well as speed and window parameters. The LAC MUST respond toacceptthecall, it respondsOutgoing-Call-Request message with anOutgoing- Call-Reply which also indicates window sizes (see Appendix B). WhenOutgoing-Call- Reply message once the LACreceivesdetermines that theOutgoing-Call-Reply, it attemptsproper facilities exist toconnectplace thecall, assumingcall and thecalling party has not hung up. A finalcall is administratively authorized. For example, is this LNS allowed to dial an international call? Once the outbound call is connectedmessage fromthe LAC sends an Outgoing-Call-Connected mes- sage to the LNSindicates thatindicating the final result of the call attempt: 7.5.1 LAC Outgoing Call States Valencia expiresFebruaryMay 1997 [Page56]64] INTERNET DRAFTAprilDecember 1996states for both the LAC and the LNS should enter the established state. 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-Clear-Request message and then waits for a Call-Disconnect-Notify.State Event Action New State ----- ----- ------ --------- idleRing OR Send wait_reply Ready to indicate Incoming-Call-Request incoming conn. wait-replyReceiveclean-upIf cannot service, idleIncoming-Call-Reply Not Accepting wait-reply Receive Answer call established Incoming-Call-Reply Send Accepting Incoming-Call-Connected wait-reply Abort, Send clean-upOutgoing-Call- send Outgoing-Call-Reply Request with Error idleCall-Disconnect- Notify establishedReceiveHang-up andIf can service, wait-cs-ans Outgoing-Call- sendidle Clear-Call-Request Call-Disconnect-NotifyRequest Outgoing-Call-Reply wait-cs-ans Telco answer Send establishedtelco line dropand framing Outgoing-Call-Connected detected wait-cs-ans Call failure Send Outgoing-Call-Connected idle with Error wait-cs-ans Receive Hang-up, send idle Call-Clear-Request Call-Disconnect-Notify establishedlocal disconnect SendReceive Hang-up, send idle Call-Clear-Request Call-Disconnect-Notify or detect call disconnected The states associated with the LAC forincomingoutgoing calls are: idleThe LAC detects an incoming call on one of its telco interfaces. TypicallyReceived Outgoing-Call-Request. If thismeans an analog lineisringing or an ISDN TE has detectedreceived in error, respond with anincoming Q.931 SETUP message. The LAC sendsOutgoing-Call-Reply with error condition set. Otherwise, allocate physical channel to dial on and send anIncom- ing- Call-Request messageOutgo- ing-Call-Reply. Place the outbound call andmovesmove to thewait_replywait-cs- ans state.wait_reply The LAC receives an Incoming-Call-Reply message indicating non- willingness to acceptwait-cs-ans If the call(general erroris not completed ordon't accept) and moves back intoa timer expires waiting for the call to complete, send an Outgoing-Call-Connected with the appro- priate error condition set and go to idle state. If a circuit switched connection is established and framing is detected, send an Outgoing-Call-Reply indicating success and go to established state. established If a Call-Clear-Request is received, thereplytelco call SHOULD be released via appropriate mechanisms and a Call-Disconnect-Notify messageindicates thatSHOULD BE sent to the LNS. If the call isaccepted,disconnected by theLAC sends an Incoming-Call- Connectedclient or by the telco interface, a Call-Disconnect-Notify messageand entersMUST be sent to theestablished state. establishedLNS. Return to idle state after send- ing the Call-Disconnect-Notify. Valencia expiresFebruaryMay 1997 [Page57]65] INTERNET DRAFTAprilDecember 1996Data is exchanged over the tunnel. The call may be cleared fol- lowing: An event on the telco connection. The LAC sends a Call- Dis- connect-Notify message Receipt of a Call-Clear-Request. The LAC sends a Call- Disconnect- Notify message A local reason. The LAC sends a Call-Disconnect-Notify mes- sage. 7.57.5.2 LNSIncomingOutgoing Call States State Event Action New State ----- ----- ------ --------- idle Open request Send wait-reply Outgoing-Call-Request wait-reply ReceiveIf not acceptingClean-up idleIncoming-Call-Request Send Incoming-Call-ReplyOutgoing-Call-Reply with Erroridlewait-reply ReceiveIf acceptingNull wait-connectIncoming-Call-RequestOutgoing-Call-Reply wait-reply Abort request SendIncoming-Call-Replywait-disconnect Call-Clear-Request wait-connectReceive clean-up idle Call-Disconnect-NotifyAbort request Send Call-Clear-Request wait-disconnect wait-connect ReceivegetGet ready for data establishedIncoming-Call-ConnectOutgoing-Call-Connected no Error wait-connect Receive Clean-up idle Outgoing-Call-Connected with Error established Receiveclean-upClean-up idle Call-Disconnect-Notify established Local terminate Sendwait- Clear-Call-Request disconnect wait-wait-disconnect Call-Clear-Request wait-disconnect Receiveclean-upClean-up idledisconnect Call-Disconnect-NotifyCall-Disconnect- Notify The states associated with the LNS forincomingoutgoing calls are: idle AnIncoming-Call-RequestOutgoing-Call-Request message isreceived.sent to the LAC and the ses- sion moves into the wait-reply state. wait-reply An Outgoing-Call-Reply is received which indicates an error. The session returns to idle state. If therequestOutgoing-Call-Reply does not indicate an error, the telco call is connected and the session moves to the established state. wait-connect An Outgoing-Call-Connected is received which indicates an error. The session returns to idle state. No telco call is active. If the Outgoing-Call-Connected does notacceptable,indicate anIncoming-Call-Replyerror, the telco Valencia expires May 1997 [Page 66] INTERNET DRAFT December 1996 call issentestablished If a Call-Disconnect-Notify is received, the telco call has been terminated for the reason indicated in the Result and Cause Codes. The session moves back to theLACidle state. If the LNS chooses to terminate the session, it sends a Call-Clear-Request to the LAC and then enters the wait-disconnect state. wait-disconnect A session disconnection is waiting to be confirmed by the LAC. Once the LNS receives the Call-Disconnect-Notify message, the ses- sion enters idle state. 8.0 L2TP Over Specific Media L2TP tries to be self-describing, operating at a level above the par- ticular media over which it is carried. However, some details of its connection to media are required to permit interoperable implementa- tions. 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 andthe LNS remains in the idle state. If the Incoming-Call-Request message is acceptable, an Incoming-Call-ReplyL2TP header, is sentindicating accept in the result code.within a UDP datagram. Thesession moves to the wait_connect state. wait_connect Ifsource and destination ports are thesessionsame (1701), with demulti- plexing being achieved using Tunnel ID values. It isconnected on the LAC, the LAC sends an incoming call connect message to the LNS which then moves into established state. The LAC may send a Call-Disconnect-Notify to indicate that Valencia expires February 1997 [Page 58] INTERNET DRAFT April 1996 the incoming caller could not be connected. This could happen,legal forexample, if a telephone user accidently placesthe source IP address of astandard voice callgiven Tunnel ID toa LAC resulting in a handshake failure onchange over thecalled modem. established The session is terminated either by receiptlife of aCall-Disconnect- Notify message from the LAC or by sendingconnection, as this may correspond to aCall-Clear-Request. Oncepeer with multiple IP inter- faces responding to aCall-Clear-Request has been sent,network topology change. Responses should reflect thesession enterslast source IP address for that Tunnel ID. IP fragmentation may occur as thewait_disconnect state. wait_disconnect Once a Call-Disconnect-Notify is receivedL2TP packet travels over thesession moves backIP substrate. L2TP makes no special efforts tothe idle state. 7.6 Outgoing calls Outgoing messages are initiated by a LNS and instructoptimize 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 toplacetravel have acall onconsis- tent value. Because atelco interface. There are only two messagessingle UDP port is used foroutgoing calls: Outgoing-Call-Request and Outgoing-Call-Reply. The LNS sends an Outgoing-Call-Request specifyingall packets, both thedialed party phone number and sub- address as well as speedI andwindow parameters. The LACC bits MUSTrespondbe used tothe Outgoing-Call-Request message with an Outgoing-Call- Reply message once the LAC determines that:permit correct demultiplexing. Port 1701 is used for both L2F [5] and L2TP packets. Thecalltwo types of packets may be detected by their headers; L2TP hasbeen successfully connected A call failurea Vers field of 2, L2F hasoccurred for reasons such as: no interfacesa 1 in this field instead. 8.2 IP When operating directly over IP, protocol number TBD [3] is used to encode the packet as L2TP-over-IP. IP source address and MTU issues areavailable for dial-out,identical to 8.1, except that thecalled party is busy or does not answer, or no dial tone is detected onlack of a UDP header makes theinterface chosen for dialing 3.2.4.1 LAC Outgoing Call States State Event Action New State ----- ----- ------ --------- idle Receive If cannot service wait_cs_ans Outgoing-Call-Request send Outgoing-Call-Reply with Error idle Receive If can service, dial, idle Outgoing-Call- send Request Outgoing-Call-Reply wait_cs_ans Telco answer Send established Outgoing-Call-Reply wait_cs_ans Call failure Send Outgoing-Call-Reply idle with Error wait_cs_ans Receive Hang-up, send idlepacket more compact. As in IP/UDP, the I and C bits MUST be present. Valencia expiresFebruaryMay 1997 [Page59]67] INTERNET DRAFTAprilDecember 1996Clear-Call-Request Call-Disconnect-Notify established Receive Hang-up, send idle Clear-Call-Request Call-Disconnect-Notify The states associated with the LAC for outgoing calls are: idle Received Outgoing-Call-Request. If this is received9.0 Security Considerations L2TP encounters several security issues inerror, respond with an Outgoing-Call-Reply with error condition set. Otherwise, allocate physical channelits operation. The gen- eral approach of L2TP todial on. Placethese issues is documented here. 9.1 Tunnel Endpoint Security The tunnel endpoints may authenticate each other during tunnel establishment. This authentication has theout- bound call, wait for a connection,same security attributes as CHAP, andmove to the wait_cs_ans state. wait_cs_ans Ifhas reasonable protection against reply and snooping. Once thecall is incomplete, send an Outgoing-Call-Reply with a non- zero Error Code. If a timer expires on an outbound call, send back an Outgoing-Call-Reply with a non-zero Error Code. If a cir- cuit switched connection is established, send an Outgoing-Call- Reply indicating success. established Iftunnel endpoints have authenticated, aCall-Clear-Request is received, the telco call SHOULDderived Key may bereleased via appropriate mechanismscarried in subsequent packets, which provides mild protection against brief or "accidental" attacks. There is no cryptographic strength to these Keys, anda Call-Disconnect-Notify message SHOULD BE sentany attacker which can snoop packets can take control of the tunnel. For L2TP tunnels over IP, IP-level packet security provides very strong protection of the tunnel. This requires no modification to theLNS.L2TP protocol, and leverages extensive IETF work in this area. For L2TP tunnels over Frame Relay or other switched networks, cur- rent practice indicates that these media are much less likely to experience attacks of in-transit data. If these attacks became prevalent, either thecall is disconnected by the clientmedia orbythetelco interface, a Call-Disconnect-Notify message SHOULD be sentL2TP packets would have tothe LNS. 7.7 LNS Outgoing Call States State Event Action New State ----- ----- ------ --------- idle Open request Send wait-reply Outgoing-Call-Request wait-reply Receive clean-up idle Outgoing-Call-Reply with Error wait-reply Receive get readybe encrypted. 9.2 Client Security A more systematic method of protection in tunneled PPP environ- ments may be achieved through client security. PPP layer encryp- tion would provide end-to-end security fordata established Outgoing-Call-Reply wait-reply Abort request Send wait-disconnect Clear-Call-Request established Receive clean-up idle Call-Disconnect-Notify established Local terminate Send wait-disconnect Clear-Call-Request Valencia expires February 1997 [Page 60] INTERNET DRAFT April 1996 wait-disconnect Receive clean-up idle Call-Disconnect- Notify The states associated withboth 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 theLNS for outgoing calls are: idle An Outgoing-Call-Request message is sent tocarrying tunnel, as well as attacks on the LAC itself. Because both encryption and compression can occur at theses- sion moves intoPPP layer, thewait_reply state. wait_reply An Outgoing-Call-Reply is received which indicates an error. The session returnstwo can be coordinated, permitting compression toidle state. No telco call is active. If the Outgoing-Call-Reply does not indicatepre- cede encryption. 9.3 Proxy Authentication The optional proxy CHAP function of L2TP can permit anerror,entirely transparent PPP tunnel, with a single LCP and CHAP sequence being seen by thetelco call is connectedclient. For cases where the LAC and thesession movesentire path to theestablished state. established IfLNS are operated by aCall-Disconnect-Notifysingle entity, this function may pro- vide acceptable security. For cases where LNS-initiated authenti- cation isreceived,required, proxy CHAP still permits an initial access decision to be made before accepting thetelco call has been terminated fortunnel, permitting thereason indicatedLNS inthe Resultmost cases to reject tunnel initiations rather than accept them andCause Codes.later disconnect. Thesession moves back to the idle state. Ifoptional proxy PAP may result in theLNS chooses to terminatecleartext password traversing thesession, it sendstunnel. Where PAP is being used in conjunction Valencia expires May 1997 [Page 68] INTERNET DRAFT December 1996 with static passwords, this may pose aCall-Clear-Request to the LAC and then enters the wait_disconnect state. wait_disconnect A session disconnectionsignificant security issue. Where PAP iswaitingonly used to transport one-time passwords, such issues may beconfirmed by the LAC. Once the LNS receives the Call-Disconnect-Notify message,greatly mitigated. The H bit of theses- sion enters idle state.carrying AVP may be used to protect against this. 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. 11.0 Contacts Kory Hamzeh Ascend Communications 1275 Harbor Bay Parkway Alameda, CA 94502 kory@ascend.com Tim Kolar, Morgan Littlewood, Andrew J. Valencia Cisco Systems 170 West Tasman Drive San Jose CA 95134-1706 tkolar@cisco.com littlewo@cisco.com vandys@cisco.com Gurdeep Singh Pall Microsoft Corporation Redmond, WA gurdeep@microsoft.comValencia expires February 1997 [Page 61] INTERNET DRAFT April 1996Jeff Taarud (formerly of 3COM Corporation, no current contact) William Verthein U.S. Robotics 12.0 ReferencesTBD[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 Valencia expires May 1997 [Page 69] INTERNET DRAFT December 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, 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 theinternetworkunderlying medium (which may be an internet- work) 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 beimplementedimple- mented 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 ProcessingDelay (PPD)Delay, "PPD", is the amount of time required for Valencia expires May 1997 [Page 70] INTERNET DRAFT December 1996 eachsidepeer to process the maximum amount of data buffered in their offered receive packetslidingwindow. The PPD is the value exchanged between the LAC and LNS when a call is established. For the LNS, this number should be small. Foraan LACmakingsupporting modemconnections,connec- tions, this number could be significant.Sample"Sample" is the actual amount of time incurredreceiving an Valencia expires February 1997 [Page 62] INTERNET DRAFT April 1996receiving an acknowledgment for a packet. The Sample is measured, not calcu- lated. Round-TripTime (RTT)Time, "RTT", is the estimated round-trip time for an Acknowledgment to be received for a given transmitted packet. When the network link is a local network, this delay will be mini- mal (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. AdaptiveTime-Out (ATO)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-bitwordtime value exchanged during the Call Control phasethat representsexpressed 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 forPPDATO are calculated is implementation-dependent and need not be variable (statictime- outstime-outs are allowed).TheIF adaptive time-outs are to be used then the PPDmustshould be exchanged in the call connectsequences, even if it remains constant in an implementation. Onesequences. A possible way to calculate the PPD is:PPD'PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate + LACFudge (for an LAC) or PPD =PPD'((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate +LACFudgeLNSFudge (for an LNS) Header is the total size of theIPL2TP andGRE headers, which is 36. Themedia dependent headers. MTU is the overall MTU for theinternetworklink between the LAC and LNS.WindowSizeWindow- Size represents the number of packets in the slidingwin- dow,window, and is implementation-dependent. The latency of theinternet- workunderlying connection path between the LAC and LNS could be used to pick a window sizesufficientsuf- ficient to keep thecur- rentcurrent session's pipe full. The constant 8convertscon- verts octets to bits (assuming ConnectRate is in bits per second). If ConnectRate is in bytes per second, omit the 8. LACFudgeisand LNS- Fudge 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 aver- age bit rate of the path between the LNS and LAC. Given that this number is probably very large and WindowSize is relatively small, Valencia expires May 1997 [Page 71] INTERNET DRAFT December 1996 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 ini- tial RTT[n-1] value.Sample Sample is the actual measured time for a returned acknowledgment. Round-Trip Time (RTT) The RTT value represents an estimate of the average time it takes for an acknowledgment to be received after a packet is sent to the remote end of the tunnel.A.1 Calculating Adaptive Acknowledgment Time-OutValencia expires February 1997 [Page 63] INTERNET DRAFT April 1996We still must decide how much time to allow for acknowledgments to return. If the time-out is set too high, we may wait an unnecessar- ily long time for dropped packets. If the time-out is too short, we may time out just before the acknowledgment arrives. The acknowledg- ment 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 stan- dard 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 itera- tion. 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 con- stants, 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 divi- sion. The above calculations are carried out each time an acknowl- edgment is received for a packet that was not retransmitted (no time- out occurs). Valencia expires May 1997 [Page 72] INTERNET DRAFT December 1996 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. Althoughthe GRE pack- etsL2TP 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 implementing theValencia expires February 1997 [Page 64] INTERNET DRAFT April 1996backoff timers for the LNS or the LAC. Notice that in addition to increasing the time-out, wearealsoshrinkingshrink 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 con- tribute to ATO and that are stored for the next iteration are calcu- lated. RTT is scaled bychi,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 win- dow, it is recommended that a slow start method be used to begin transmitting data. The initial 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 window size. As the receiver successfully digests each window, the window size on the transmitter is bumped up by one packet until the maximum 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 value when it failed. Valencia expires May 1997 [Page 73] INTERNET DRAFT December 1996 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 transmit window size is increased by one packet until it reaches the maximum window size that was sent by the other side when the call was connected. As stated earlier, no retransmission is done on a time-out. After a time-out, the trans- mission resumes with the window starting at one half the size of the transmit window when the time-out occurred and adjusting upward by one each time the transmit window is filled with packets that are all acknowledged without time-outs. B.4 Window OverflowValencia expires February 1997 [Page 65] INTERNET DRAFT April 1996When 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.8.0 L2TP Over Specific Media L2TP tries to be self-describing, operating at a level above the par- ticular media over which it is carried. However, some detailsAppendix C: Handling ofits connection to media are required to permit interoperable implementa- tions. The following sections describe details needed to permit interoperability over specific media. 8.1 IP/UDP L2TP usesout-of-order packets When thewell-known UDP port 1701 [3]. The entire L2TP packet, including payload and L2TP header, is sent within a UDP datagram. The sourceSequence Number anddestination portsAcknowledgment Number fields arethe same (1701), with demulti- plexing being achieved using Tunnel ID values. It is legal for the source IP address of a given Tunnel IDpresent in payload packets, they are used tochange over the life of a connection, as thismanage packet rate. In addi- tion, they maycorrespondbe used to handle out-of-order arrival of packets. A simple L2TP client would simply discard any packet other than apeerpacket withmultiple IP inter- faces responding toanetwork topology change. Responses should reflect the last source IP address forsequence greater than thatTunnel ID. IP fragmentation may occurlast received; if packets 1, 2, 3 arrived asthe L2TP packet travels over the IP sub- strate. L2TP makes no special efforts to optimize this. A LAC imple- mentation MAY cause its LCP to negotiate for a specific MRU, which could optimize for LAC environments1, 3, 2, this would result inwhich the MTUs of the path over whichpacket 2 being dis- carded. Such behavior does not affect the L2TPpackets are likely to travel have a consis- tent value. Port 1701 is used for both L2F [XXX]protocol itself, but signifi- cantly improved throughput in such environments may be attained by queueing andL2TP packets.reordering packets when they arrive out of order. Thetwo typesnumber of packetsmayto bedetected by their headers; L2TP hasqueued is aVers fieldfunction of2, L2F has a 1memory 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 thisfield instead. 8.2 IP When operating directly over IP, protocolway must also employ an algorithm for deciding that a given sequence numberTBD [3] is usedcorresponds toencode thea packetas L2TP-over-IP. IP source addresswhich 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, andMTU issuespacket arrival characteristics. The details of such a tradeoff areidentical to 8.1, except thatoutside thelackscope of this specifica- tion, but it is recommended aUDP header makes thepacketmore compact. 9.0 Security Considerationsshould be afforded an interval at least twice the estimated RTT from the L2TPencounters several security issues in its operation. The gen- eral approachpeer. Appendix D: Transport Layer Adaptive Time-outs and Window Adjustment Appendixes A, B, and C dealt with operation ofL2TP to these issues is documented here. 9.1 Tunnel Endpoint Security The tunnel endpoints may authenticate each other during tunnel establishment. This authentication hasthesame security attributes as CHAP, and has reasonable protection against replypayload packet sessions of L2TP. This Appendix explains how these three algorithms pertain to the transport layer for L2TP control sessions. Appendix Valencia expiresFebruaryMay 1997 [Page66]74] INTERNET DRAFTAprilDecember 1996and snooping. OnceB, Time-out Window Management, directly applies to thetunnel endpoints have authenticated,Transport Layer except in the case where aderived Key maywindow size of 1 is being used. Appendix C, does not really apply because, for the Control Session, control messages MUST always becarriedprocessed by the receiver insubsequent packets, which provides mild protection against brief or "accidental" attacks. There isorder. Also, there are nocryptographic strength to these Keys, and any attacker which can snoop packets can takelost controlofpackets because they are retransmit- ted by thetunnel. ForL2TPtunnels over IP, IP-level packet security provides very strong protectionTransport Layer. Thus, the main topic of this Appendix is how to adapt thetunnel. This requires no modificationexample adaptive time-out algorithm of Appendix A to theL2TP protocol,Control Session Transport Layer. There are two main differences between the Control Session andleverages extensive IETF work in this area. For L2TP tunnels over Frame Relay or other switched networks, cur- rent practice indicates that these mediapay- load sessions: 1) Unlike lost payload packets, lost control messages aremuch less likely to experience attacks of in-transit data. If these attacks became prevalent, eitherretransmitted and 2) There is no Packet Processing Delay value provided in themedia orcontrol session setup messages. The latter affects theL2TP packets would have to be encrypted. 9.2 Client Security A more systematic method of protectionmanner intunneled PPP environ- ments may be achieved through client security. PPP layer encryp- tion would provide end-to-end security for both direct dial-in clients as well as PPP clients carried withinwhich the initial value of the RTT estimate is deter- mined. The former really doesn't affect the algorithm at all, except that upon atunnel. With this leveltime-out, retransmission ofclient security, sessions are protected against attacks againstunacknowledged control mes- sages should be attempted, up to thecarrying tunnel, as wellnumber that fit in the sliding window with size computed asattacks onin Appendix B. Using theLAC itself. Because both encryption and compression can occur atsymbol definitions of Appendix A, thePPP layer,calculation of thetwovalue for the PPD of the remote peer can becoordinated, permitting compression to pre- cede encryption. The optional proxy CHAP functionestimated as: PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / AvePathRate + Fudge This is simply the number ofL2TP can permit an entirely transparent PPP tunnel, withbits in asingle LCP and CHAP sequence being seenfull control session window divided by theclient. For cases where the LAC andaverage speed of theentirepathtobetween the LAC and LNSare operated bywith asingle entity, this function may pro- vide acceptable security. Forfudge factor added on to make it work. In cases whereLNS-initiated authenti- cationthe average rate of the connection between LAC and LNS isn't known, it isrequired, proxy CHAP still permits an initial access decision tosug- gested that some value bemade before acceptingconfigured that is associated with each possible peer. Because Control Session windows will most likely be small and thetunnel, permittingconnection speed will be quite high, fudge will be theLNSdominant factor inmost casesthis calculation. For this reason, just configur- ing a single fixed initial PPD estimate toreject tunnel initiations rather than accept them and later disconnect.be used for all possible peers will probably provide adequate results. This fudge factor should probably be at least 0.5 second. Valencia expiresFebruaryMay 1997 [Page67]75] ----