PPP Working Group Kory Hamzeh
Request for Comments: DRAFT Ascend Communications
Category: Internet Draft Tim Kolar
Title: draft-ietf-pppext-l2tp-00.txt Cisco Systems
Date: August 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 expires February 1997 [Page 1]
INTERNET DRAFT April 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.6 Echo-Request
6.7 Echo-Reply
6.8 Outgoing-Call-Request
6.9 Outgoing-Call-Reply
6.10 Incoming-Call-Request
6.11 Incoming-Call-Reply
6.12 Incoming-Call-Connected
6.13 Call-Clear-Request
6.14 Call-Disconnect-Notify
6.15 WAN-Error-Notify
6.16 Set-Link-Info
6.17 No-op
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 Calls
7.5 LNS Incoming Call States
7.6 Outgoing calls
7.7 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 Security
10.0 Acknowledgments
11.0 Contacts
Valencia expires February 1997 [Page 2]
INTERNET DRAFT April 1996
12.0 References
Appendix A: Acknowledgment Time-Outs
Appendix B: Acknowledgment Time-Out 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.
1.1 Conventions
The following language conventions are used in the items of specifi-
cation in this document:
o must, SHALL, or MANDATORY -- This item is an absolute
requirement of the specification.
o SHOULD or RECOMMEND -- This item should generally be followed
for all but exceptional circumstances.
o MAY or OPTIONAL -- This item is truly optional and may be
followed or ignored according to the needs of the implementor.
1.2 Terminology
Analog Channel
A circuit-switched communication path which is intended to carry
3.1 Khz audio in each direction.
Digital Channel
A circuit-switched communication path which is intended to carry
digital information in each direction.
Call
Valencia expires February 1997 [Page 3]
INTERNET DRAFT April 1996
A connection or attempted connection between two terminal end-
points on a PSTN or ISDN--for example, a telephone call between
two modems.
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.
L2TP Access Concentrator (LAC)
A device attached to one or more PSTN or ISDN lines capable of PPP
operation and of handling the L2TP protocol. The LAC needs only
implement the media over which L2TP is to operate to pass traffic
to one or more LNS's. It may tunnel any protocol carried within
PPP.
L2TP Network Server (LNS)
An LNS operates on any platform capable of PPP termination. The
LNS handles the server side of the L2TP protocol. Since L2TP
relies only on the single media over which L2TP tunnels arrive,
the LNS may have only a single LAN or WAN interface, yet still be
able to terminate calls arriving at any LAC's full range of PPP
interfaces (async, synchronous ISDN, V.120, etc.).
Network Access Server (NAS)
A device providing temporary, on-demand network access to users.
This access is point-to-point using PSTN or ISDN lines.
Session
L2TP is connection-oriented. The LNS and LAC maintain state for
each user that is attached to a LAC. A session is created when
end-to-end PPP connection is attempted between a dial user and the
LNS, or when a outbound call is initiated. The datagrams related
to a session are sent over the tunnel between the LAC and LNS.
Quality of Service (QOS)
A given Quality of Service level is sometimes required for a given
user being tunneled between a 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 1996
An 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 by a 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
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 this service in
a secure manner.
+ Authentication as provided via dial-up PPP CHAP or PAP, or through
other dialogs, for instance, a textual exchange on V.120 before
starting PPP. This will include TACACS+ and RADIUS solutions as well
as support for smart cards and one-time passwords. The authentica-
tion 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), although
Valencia expires February 1997 [Page 5]
INTERNET DRAFT April 1996
their physical dial-up is via the ISP Network Access Server.
...----[L]----+---[L]-----...
|
|
[H]
|
________|________________________
| |
________|__ ______|________
| | | |
| PSTN [R] [R] ISDN |
| Cloud | | Cloud [N]__[U]
| | Internet | |
| | [R] |
[N]______[R] |_____________|
| | |
| | |
[U] |________________________________|
[H] = LNS
[L] = Home LAN(s)
[R] = Router
[U] = Remote User
[N] = ISP Network Access Server
2.3 Providing Virtual dial-up Services--a walk-through
To motivate the following discussion, this section walks through an
example of what might happen when a Virtual dial-up client initiates
access.
The Remote User initiates a PPP connection to an ISP via either the
PSTN or ISDN. The Network Access Server (NAS) accepts the connection
and the PPP link is established.
The ISP undertakes a partial authentication of the end system/user
via CHAP or PAP. Only the username field is 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). 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.
If a virtual dial-up service is not required, standard access to the
Internet may be provided.
If no tunnel connection currently exists to the desired LNS, one is
initiated. L2TP is designed to be largely insulated from the details
of the media over which the tunnel is established; L2TP requires only
that the tunnel media provide packet oriented point-to-point
Valencia expires February 1997 [Page 6]
INTERNET DRAFT April 1996
connectivity. Obvious examples of such media are UDP, Frame Relay
PVC's, or X.25 VC's.
Once the tunnel exists, an unused slot within the tunnel, a "Call
ID", is allocated, and a connect indication is sent to notify the LNS
of this new dial-up session. The LNS either accepts the connection,
or rejects. Rejection may include a reason indication, which may be
displayed to the dial-up user, after which the call should be discon-
nected.
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 initial setup notification may also include a copy of the the LCP
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 filtering.
Accounting can be performed at both the LAC as well as the LNS. This
document illustrates some Accounting techniques which are possible
using L2TP, but the policies surrounding such Accounting are outside
the scope of this specification.
Valencia expires February 1997 [Page 7]
INTERNET DRAFT April 1996
L2TP offers optional facilities which maximize compatibility with
legacy client requirements, L2TP connect notifications for PPP
clients can contain sufficient information for a LNS to authenticate
and initialize its LCP state machine. With these facilities, the the
remote user need not be queried a second time for CHAP authentica-
tion, 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
LCP negotation and initiation of CHAP. As soon as the apparent iden-
tity 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
be RFC1597 addresses, or non-IP addresses). Because L2TP tunnels
exclusively at the frame layer, the actual policies of such address
management are irrelevant to correct Virtual dial-up service; for all
purposes of PPP protocol handling, the dial-in user appears to have
connected at the LNS.
Valencia expires February 1997 [Page 8]
INTERNET DRAFT April 1996
3.3 Authentication
The authentication of the user occurs in three phases; the first at
the ISP, and the second and optional third at the LNS.
The ISP uses the username to determine that a Virtual dial-up service
is required and initiate the tunnel connection to the appropriate
LNS. Once a tunnel is established, a new Call ID is allocated and a
session initiated by forwarding the gathered authentication informa-
tion.
The LNS undertakes the second phase by deciding whether or not to
accept the connection. The connection indication may include CHAP,
PAP, or textual authentication information. Based on this informa-
tion, 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 LNS can provide
accounting data and hence both may count packets, octets and connec-
tion 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 most third-party connection attempts) while still
insisting on running its own CHAP authentication (to protect against
CHAP replay attacks).
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, and 2) payload
Valencia expires February 1997 [Page 9]
INTERNET DRAFT April 1996
packets between the same LAC-LNS pair which 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, control mes-
sages 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
which a LNS is notified of an incoming call at an associated LAC,
as well as the means by which a LAC is instructed to place an out-
going dial call.
A tunnel may be established by either a 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 a Set- Link-Info message. Indi-
vidual sessions may be released by either the LAC or LNS, also
through control messages.
The tunnel itself is maintained by exchanging keepalive control
echo messages. This ensures that a connectivity failure between
the LNS and the LAC can be detected in a timely manner. Other
failures can be reported via the Wan-Error-Notify control message.
It is intended that control messages will also carry management
related information in the future, such as a message allowing the
LNS to request the status of a given LAC; these message types have
not yet been defined.
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 key in the
tunnel header indicates to which session a particular PPP packet
belongs. In this manner, PPP packets are multiplexed and demulti-
plexed over a single tunnel between a given LNS-LAC pair. The key
field value is established by the call establishment control mes-
sages.
It is legal for multiple tunnels to exist between a given LNS-LAC
pair. This is useful where each tunnel is used for a single user,
and the tunnel media (an SVC, for instance) has specific QOS
attributes dedicated to a given user. L2TP provides a tunnel
Valencia expires February 1997 [Page 10]
INTERNET DRAFT April 1996
identifier so that individual tunnels can be identified, even when
arriving from a single source LAC or LNS.
The L2TP header also contains optional acknowledgment and 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 does not
specify 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.
5. Message Format and Protocol Extensibility
L2TP defines a set of control messages sent in packets over the tun-
nel between a LNS and a given LAC. The exact technique for initiat-
ing a tunnel between a LNS-LAC pair is specific to the tunnel media,
and supported media are described in section 8.0.
Once media-level connectivity is reached, L2TP message formats define
the protocol for a 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Overall Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute |0|0|0|0|0|0|0|M| [Value]... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [until Overall length 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.
The next octet is a bit mask, describing the general attributes of
the AVP. Only one bit value, M, is defined. This bit, known as
the "mandatory" bit, controls the behavior required of an imple-
mentation which receives an AVP which it does not recognize. If M
is set, any session associated with this AVP must be terminated.
If the AVP is associated with the overall tunnel, the entire tun-
nel (and all sessions within) must be terminated. If M is not
set, an unrecognized AVP should be ignored.
Value follows immediately after the Flags field, and runs for the
remaining octets indicated in the Overall Length (i.e., Overall
Length minus seven octets of header). If desired, a given AVP can
define the first octet of the Value to be a pad, permitting actual
data to be aligned on a 32-bit boundary.
AVP's should be kept compact; in no case should AVP's ever cause a
control message's total length to exceed 1532 bytes in length.
5.2 Control Message Format
Each L2TP control message begins with a 20 octet fixed header por-
tion and at 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. 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.
Ver must be the value 002, indicating a version 1 L2TP message
(values 000 and 001 are reserved to permit detection of L2F [XXX],
Valencia expires February 1997 [Page 12]
INTERNET DRAFT April 1996
GRE [XXX], and PPTP [XXX] packets if they arrive intermixed).
Length is the overall length of the message, including header,
message type AVP, plus any additional AVP's associated with a
given control message type.
Magic Cookie is always present, and has the value 0x1A2B3C4E. Its
purpose is to allow the receiver to ensure that it is synchronized
with the data stream. It should not be used as a means for resyn-
chronizing the data stream in the event that a transmitter issues
an improperly formatted message. Loss of synchronization must
result in immediate closing of the session.
Tunnel ID and Call ID identify the tunnel and caller within the
tunnel to which a control message applies. If a control message
does not apply to a single caller within the tunnel (for instance,
a Stop-Control-Connection-Request message), Call ID should be set
to 0.
Sequence Number and Acknowledgment Number reflect the currently
transmitted packet and latest received packet respectively.
If the K bit is set, the Key field is present. The K bit must be
set if a Challenge value was received during tunnel setup, and the
Key reflects the challenge response of this authentication, with
the resulting MD5 hash value broken into successive 32-bit fields
which are XOR'ed together and this value put in the Key field.
The body of a control message is an AVP indicating the type of
control message. Depending on the particular control message,
further AVPs may follow.
5.3 Payload Message Format
PPP payload packets tunneled within L2TP have a smaller encapsula-
tion, reducing overhead of L2TP during the life of a tunneled 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 largest is 12 octets.
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| | Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID (opt) | Call ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (opt) | Acknowledgment Number (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The T bit must be 0, indicating payload.
Valencia expires February 1997 [Page 13]
INTERNET DRAFT April 1996
Ver must be 002, indicating version 1 of the L2TP protocol.
If the L bit is set, the Length field is present, indicating the
total length of the received packet.
If the I bit is set, the Tunnel ID field 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, the Call ID field is present. This is used
to multiplex multiple clients within one tunnel.
If the F bit is set, both Sequence Number and Acknowledgment Num-
ber are present. Sequence Number indicates the sequence number of
the next packet to be sent. The current packet will be this
sequence number if the payload size is non-zero, otherwise this
packet is only an acknowledgement (sequence number does not
advance). Acknowledgment Number indicates the latest packet
sequence number last received. Together, these fields can be used
to handle out-of-order packets, and to provide flow control for
the connection.
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. The actual message
semantics are defined in the next 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 13
Valencia expires February 1997 [Page 14]
INTERNET DRAFT April 1996
No-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 types of errors which are not spe-
cific to any particular L2TP request, but rather to protocol or
message format errors. If a L2TP reply indicates in its Result
Code that a general error occurred, the General 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
1 - No control connection exists yet for this LAC-LNS pair
2 - Length is wrong or Magic Cookie value is incorrect
3 - One of the field values was out of range or
reserved field was non-zero
4 - Insufficient resources to handle this command now
5 - The Call ID is 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. The first set of Control Connection messages are used to
maintain the control connection itself. The control connection is
initiated by a LAC or LNS after establishing the underlying tunnel-
over-media connection.
6.0.1 Control Connection Collision
For the case where an LAC and LNS both initiate tunnels to each
other concurrently, and where the LAC and LNS both determine that
a single tunnel suffices (generally because of media 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
with the tunnel 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 that the
peer never received it. Each tunnel maintains Sequence and
Acknowledgment values for the control channel, which are global
across the tunnel. When a control message is sent, it is assigned
the current Sequence number, and the Sequence counter is
Valencia 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 reflects the
highest in-order Sequence number received from the peer.
Each tunnel maintains a queue of control messages to be transmit-
ted to the peer. The message at the front of the queue is sent
with a given sequence number, and is held until a control message
arrives from the peer in which the Acknowledgment field indicates
receipt of this message. After a timeout interval (a recommended
default is one second, but this may be altered based on media con-
siderations), the packet is retransmitted. The retransmitted
packet holds the same Sequence number, but the Acknowledgment
value should be updated to reflect any packet received in the
interim.
If no peer response is detected after several retransmissions (a
recommended default is 5, but again may be altered due to media
considerations), the tunnel and all sessions within should be
cleared.
The default is to have a single control message outstanding on a
given. If a peer specifies a control message window in the Start-
Control-Connection-Request and -Reply packets, up to the indicated
number of control messages may be sent and held outstanding.
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.
6.1 Start-Control-Connection-Request
The Start-Control-Connection-Request is a L2TP control message used
to initialize the tunnel between a LNS and a LAC. The tunnel must be
initialized through the exchange of these control messages before any
other L2TP messages can be issued. The establishment of the control
connection is started by the initiator of the underlying tunnel. The
message is structured as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Control Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Start-Control-Connection-Request AVP encodes a request to an
LNS to receive a tunneled PPP session from an LAC. The Attribute
field is 1, indicating Start-Control-Connection-Request. The
Flags indicate a mandatory option. Details associated with this
tunneled session follow in additional AVP's within the packet.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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. The
Attribute value is 1, indicating Protocol Version, and the Value
field is a 16-bit hexadecimal value 0x100, indicating L2TP proto-
col version 1, revision 0. This AVP must be present.
Framing Capabilities
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 indicates the type of framing that the sender of this mes-
sage can provide. The Attribute is 2, 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, 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 indicates the bearer capabilities that the sender of this
message can provide. The Attribute is 3, it is a mandatory AVP,
the Value field is a 32-bit quantity with two bits defined. If
bit A is set, 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 in tunnel establishment
between a LAC-LNS pair. It is encoded as the Attribute 4, not
mandatory, with the indicated number of bytes representing the
vendor string. This AVP is optional.
If present, it indicates the sender wishes a single tunnel to
exist betweeen the given LAC-LNS pair, and this value will be used
decide on 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
Valencia expires February 1997 [Page 18]
INTERNET DRAFT April 1996
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |0 0 0 0 0 0 0 0| Max (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max (L) |
+-+-+-+-+-+-+-+-+
The Firmware Revision AVP within a Start-Control-Connection-
Request indicates the firmware revision of the issuing device.
The Attribute is 5, it is not a mandatory AVP, the Value field is
a 16-bit integer encoded in a vendor specific format. For devices
which do not have a firmware revision (general purpose computers
running L2TP software modules, for instance), the revision of the
L2TP software module may be reported instead. This AVP is
optional.
Host Name
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 + length of host name | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 |0 0 0 0 0 0 0 0|Host name... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Host Name AVP within a Start-Control-Connection-Request indi-
cates the DNS name of the issuing LAC or LNS. It is encoded as
the Attribute 6, not mandatory, with the indicated number of bytes
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 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (7 + vendor length) | 0 |
Valencia expires February 1997 [Page 19]
INTERNET DRAFT April 1996
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 |0 0 0 0 0 0 0 0|Vendor name... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor Name AVP within a Start-Control-Connection-Request con-
tains a vendor specific string describing the type of LAC or LNS
being used. It is encoded as the Attribute 7, not mandatory, with
the indicated number of bytes representing the vendor string.
This AVP is optional.
Assigned Tunnel ID
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 |0 0 0 0 0 0 0 1| ID (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID (L) |
+-+-+-+-+-+-+-+-+
The Assigned 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 ID is received,
packets should be sent with a Tunnel ID value of 0. It is encoded
as the Attribute 8, mandatory, with the two bytes encoded as a
16-bit non-zero Tunnel ID value. This AVP must 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 |0 0 0 0 0 0 0 0| Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Control Message Window AVP within a Start-Control-Connection-
Request specifies the number of control messages which may be
received without waiting for an acknowledgment. It is encoded as
the Attribute 9, not mandatory, with a single octet indicating the
number of such messages. If absent, the peer must use a value of
1 for the Window.
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 + length of challenge | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 |0 0 0 0 0 0 0 1| Challenge... |
Valencia expires February 1997 [Page 20]
INTERNET DRAFT April 1996
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Challenge... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Challenge AVP within a Start-Control-Connection-Request indi-
cates that the peer wishes to authenticate the tunnel endpoints.
It is encoded as the Attribute 10, mandatory, with at least one
byte of challenge value embedded.
6.2 Start-Control-Connection-Reply
The Start-Control-Connection-Reply is an L2TP control message sent in
reply to a received Start-Control-Connection-Request message. This
message contains a result code indicating the result of the control
connection establishment attempt. The message is structured as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 ID |
| Control Message Window|
| Challenge |
| Response |
+-+-+-+-+-+-+-+-+-+-+-+-+
Start-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attribute field is 2, indicating Start-Control-Connection-
Reply. The Flags indicate a mandatory option.
Protocol Version
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 0 |
Valencia expires February 1997 [Page 21]
INTERNET DRAFT April 1996
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |0 0 0 0 0 0 0 1| 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 |
+-+-+-+-+-+-+-+-+
The Protocol Version AVP within a Start-Control-Connection-Reply
packet indicates the L2TP protocol version available. The
Attribute value is 1, indicating Protocol Version, and the Value
field is a 16-bit hexadecimal value 0x100, indicating L2TP proto-
col version 1, revision 0. This AVP must be present.
Framing Capabilities
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |0 0 0 0 0 0 0 1| 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x00 | 0x00 |S|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Framing Capabilities AVP within a Start-Control-Connection-
Reply indicates the type of framing that the sender of this mes-
sage can provide. The Attribute is 2, 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, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 |0 0 0 0 0 0 0 1| 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x00 | |D|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Bearer Capabilities AVP within a Start-Control-Connection-
Reply indicates the bearer capabilities that the sender of this
message can provide. The Attribute is 3, it is a mandatory AVP,
the Value field is a 32-bit quantity with two bits defined. If
bit A is set, analog access is supported. If bit D is set, 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
Valencia expires February 1997 [Page 22]
INTERNET DRAFT April 1996
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 |0 0 0 0 0 0 0 0| Max (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max (L) |
+-+-+-+-+-+-+-+-+
The Firmware Revision AVP within a Start-Control-Connection-Reply
indicates the firmware revision of the issuing device. The
Attribute is 4, it is not a mandatory AVP, the Value field is a
16-bit integer encoded in a vendor specific format. For devices
which do not have a firmware revision (general purposes computers
running L2TP software modules, for instance), the revision of the
L2TP software module may be reported instead. This AVP is
optional.
Host Name
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 + length of host name | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |0 0 0 0 0 0 0 0|Host name... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Host Name AVP within a Start-Control-Connection-Reply indi-
cates the DNS name of the issuing LAC or LNS. It is encoded as
the Attribute 5, not mandatory, with the indicated number of bytes
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 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (7 + vendor length) | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 |0 0 0 0 0 0 0 0|Vendor name... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor Name AVP within a Start-Control-Connection-Reply con-
tains a vendor specific string describing the type of LAC or LNS
being used. It is encoded as the Attribute 6, not mandatory, with
the indicated number of bytes representing the vendor string.
This AVP is optional.
Assigned Tunnel ID
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (7 + vendor length) | 0 |
Valencia expires February 1997 [Page 23]
INTERNET DRAFT April 1996
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 |0 0 0 0 0 0 0 1| ID (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID (L) |
+-+-+-+-+-+-+-+-+
The Assigned Tunnel ID AVP within a Start-Control-Connection-Reply
specifies the Tunnel ID which the peer should use in all subse-
quent packets. It is encoded as the Attribute 7, mandatory, with
the two bytes encoded as a 16-bit non-zero Tunnel ID value. This
AVP must 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 |0 0 0 0 0 0 0 0| Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Control 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
the Attribute 8, not mandatory, with a single octet indicating the
number of such messages. If absent, the peer must use a value of
1 for the Window.
Result Code
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 |0 0 0 0 0 0 0 1| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Result Code AVP within a Start-Control-Connection-Reply packet
indicates the result of the command channel establishment attempt.
The Value field is 9, indicating a Result Code. The code is a
single octet, and this AVP is mandatory. Result code values are:
1 - Successful channel establishment
2 - General error--Error Code indicates the problem
3 - Command channel already exists
4 - Requester is not authorized to establish a command 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Valencia expires February 1997 [Page 24]
INTERNET DRAFT April 1996
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 |0 0 0 0 0 0 0 1| Error |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP is present only if a "General Error" exists, in which
case Result Code is set to 2 and this AVP encodes the general
error value as documented in section 5.5. It has a Value of 10,
and is marked mandatory.
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 + length of challenge | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 |0 0 0 0 0 0 0 1| Challenge... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 11, mandatory, with at least one
byte of challenge value embedded.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 23 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12 |0 0 0 0 0 0 0 1| Response... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response... (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response AVP within a Start-Control-Connection-Reply packet
provides a response to a challenge received. The Attribute value
is 12, indicating Response, and the Value field is a 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 calculation, the
low order byte of the Sequence number of the challenge are used.
6.3 Start-Control-Connection-Connected
The Start-Control-Connection-Connected message is an L2TP control
message sent in reply to a received Start-Control-Connection-Reply
message. This message provides closure to the tunnel establishment
process, and includes a challenge response if the peer sent a 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-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 17 |0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attribute field is 17, indicating Start-Control-Connection-
Connected. The Flags indicate a mandatory option.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 23 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |0 0 0 0 0 0 0 1| Response... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response... (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response AVP within a Start-Control-Connection-Connected
packet provides a response to a challenge received. The Attribute
value is 1, indicating Response, and the Value field is a 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, 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 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-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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 |0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attribute field is 3, indicating Stop-Control-Connection-
Request. The Flags indicate a mandatory option. The Flags indi-
cate a mandatory option. The single Reason AVP must follow this.
Reason
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |0 0 0 0 0 0 0 1| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reason octet 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 an L2TP control message sent by
one peer of a LAC-LNS control connection upon receipt of a Stop-
Control-Connection-Request from the other peer.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Control Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stop-Control-Connection-Reply |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+
Valencia expires February 1997 [Page 27]
INTERNET DRAFT April 1996
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 |0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attribute field is 4, indicating Stop-Control-Connection-
Reply. The Flags indicate a mandatory option.
Result Code
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |0 0 0 0 0 0 0 1| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Result octet indicates the result of the attempt to close the
control connection. It has a Value of 1 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |0 0 0 0 0 0 0 1| Error |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP is present only if a "General Error" exists, in which
case Result Code is set to 2 and this AVP encodes the general
error value as documented in section 5.5. It has a Value of 2,
and is marked mandatory.
6.6 Echo-Request
The Echo-Request is a L2TP control message sent by either peer of a
LAC-LNS control connection. This control message is used as a "keep
Alive" for the control connection. The receiving peer issues 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 since a message has been
Valencia expires February 1997 [Page 28]
INTERNET DRAFT April 1996
received from the peer. If an Echo-Reply has not been received in 20
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; the Call ID field of these control
messages must be 0.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Control Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Echo-Request |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+
Echo-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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attribute field is 5, indicating Echo-Request. The Flags
indicate a mandatory option.
Identifier
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |0 0 0 0 0 0 0 1| ID... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 32-bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Identifier AVP has an Attribute of 1, and the AVP is marked
mandatory. The ID set in the value of this AVP is set by the
sender of the Echo-Request and can be used to match the reply with
the corresponding request. This AVP is optional.
6.7 Echo-Reply
The Echo-Reply is a L2TP control message sent back upon receipt of an
Echo-Request.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Control Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Valencia expires February 1997 [Page 29]
INTERNET DRAFT April 1996
| Echo-Reply |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+
Echo-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 |0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attribute field is 6, indicating Echo-Reply. The Flags indi-
cate a mandatory option.
Identifier
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |0 0 0 0 0 0 0 1| ID... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... 32-bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Identifier AVP has an Attribute of 1, and the AVP is marked
mandatory. If an Echo-Request is received with this AVP, the same
AVP (with identical ID) is sent back in the Echo-Reply packet.
Otherwise this AVP is not included in the Echo-Reply.
6.8 Outgoing-Call-Request
The Outgoing-Call-Request is a L2TP control message sent by the LNS
to the LAC to indicate that an outbound call from the LNS is to be
established. This request provides the LAC with information required
to make the call. It also provides information to the LAC that is
used to regulate the transmission of data to the LNS for this session
once it is established. The message is structured as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Control Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outgoing-Call-Request |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Call ID |
| Call Serial Number |
| Minumum BPS |
| Maximum BPS |
| Bearer Type |
Valencia expires February 1997 [Page 30]
INTERNET DRAFT April 1996
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | L2TP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 |0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Outgoing-Call-Request AVP encodes a request to an LAC to
establish an outgoing 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |0 0 0 0 0 0 0 1| ID (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID (L) |
+-+-+-+-+-+-+-+-+
The Assigned Call ID AVP encodes the ID being assigned to call by
the LNS. The flags 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 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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |0 0 0 0 0 0 0 1| Number (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number (L) |
+-+-+-+-+-+-+-+-+
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 expires February 1997 [Page 31]
INTERNET DRAFT April 1996
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 |0 0 0 0 0 0 0 1| BPS (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Minimum BPS AVP encodes the lowest acceptable line speed for this
call. The flags indicate a mandatory option. The BPS value indi-
cates the speed in bits/second. This AVP must be present.
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 encodes the highest acceptable line speed for this
call. The flags indicate a mandatory option. The BPS value indi-
cates the speed in bits/second. This AVP must be present.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 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.
The flags indicate a mandatory option. The value bit field indi-
cates the bearer capability required for this outgoing call. Bit
A if set indicates that the call should be on an analog channel.
Bit D if set indicates that the call should be on a digital chan-
nel. Both bits set indicate that the call can be of either type.
Valencia expires February 1997 [Page 32]
INTERNET DRAFT April 1996
This AVP must be present.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 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 Type AVP encodes the framing type for the requested 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 |0 0 0 0 0 0 0 1| Size (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size (L) |
+-+-+-+-+-+-+-+-+
Packet Recieve Window Size AVP encodes the window size being
advertised by the LNS for this call. The flags indicate a manda-
tory option. The Size value indicates the number of received data
packets the LNS will buffer for this call. This AVP is optional.
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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 |0 0 0 0 0 0 0 1| Delay (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay (L) |
+-+-+-+-+-+-+-+-+
Packet Processing Delay AVP encodes the delay LNS has for process-
ing window full of packets sent by the LAC. The flags indicate a
mandatory option. The Delay value is specified in units of 1/10
seconds. This AVP is optional. Refer to appendix A to see a
Valencia expires February 1997 [Page 33]
INTERNET DRAFT April 1996
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 + N | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 |0 0 0 0 0 0 0 1| Phone Number..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Phone Number ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Phone Number AVP encodes the phone number to be called. The flags
indicate a mandatory option. The Phone Number value is an ASCII
string. The length of the string is the length in the AVP header
minus 7 bytes. This AVP is optional.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 + N | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 |0 0 0 0 0 0 0 1| Sub-Address ..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Address AVP encodes additional dialing information. The flags
indicate a mandatory option. The Sub-Address value is an ASCII
string. The length of the string is the length in the AVP header
minus 7 bytes. This AVP is 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. The
reply indicates the result 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 |
| Framing Type |
| Packet Recv. Window |
| Packet Processing Delay |
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 |0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Outgoing-Call-Reply AVP encodes a result of an outgoing call
request. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |0 0 0 0 0 0 0 1| ID (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID (L) |
+-+-+-+-+-+-+-+-+
The Assigned Call ID AVP encodes the ID being assigned to call by the
LAC. The flags 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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |0 0 0 0 0 0 0 1| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Valencia expires February 1997 [Page 35]
INTERNET DRAFT April 1996
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 administratively prohibited
This AVP is mandatory.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 |0 0 0 0 0 0 0 1| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Code AVP is used to encode a specific error code in case
the result AVP indicates a General Error. The flags indicate a
mandatory option. The value can be one of the general error IDs
specified in Section 5.5. This AVP is optional.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 |0 0 0 0 0 0 0 1| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Cause Code AVP is used to give additional information in case of
call failure. The flags indicate a mandatory option. The Code value
can vary depending upon the type of call attempted. For ISDN call
attempts it is the Q.931 cause code.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |0 0 0 0 0 0 0 1| BPS (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 is
Valencia expires February 1997 [Page 36]
INTERNET DRAFT April 1996
successful.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 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 Type AVP encodes the framing type for the call. The flags
indicate a mandatory option. The value bit field indicates the type
of PPP framing is used for the call. 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 if the call
attempt is successful.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 |0 0 0 0 0 0 0 1| Size (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size (L) |
+-+-+-+-+-+-+-+-+
Packet Recieve Window Size AVP encodes the window size being adver-
tised by the LAC for this call. 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 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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 |0 0 0 0 0 0 0 1| Delay (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay (L) |
+-+-+-+-+-+-+-+-+
Packet Processing Delay AVP encodes the delay LAC has for processing
window full of packets sent by the LNS. The flags indicate a
mandatory option. The Delay value is specified in units of 1/10
seconds. This AVP is optional. Please refer to appendix A to see a
Valencia expires February 1997 [Page 37]
INTERNET DRAFT April 1996
description of how this value is determined and used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 |0 0 0 0 0 0 0 1| ID (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Physical Channel ID AVP encodes the vendor specific physical channel
number used for the call. The flags indicate a mandatory option.
The value is used for logging purposes only. This AVP is optional.
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 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 indi-
cating that the call should be established. This mechanism allows
the LNS to obtain sufficient information about the call before it is
answered to determine whether the call should be answered or not.
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-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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Valencia expires February 1997 [Page 38]
INTERNET DRAFT April 1996
| 9 |0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Incoming-Call-Request AVP encodes an incoming call being indi-
cated by the LAC. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |0 0 0 0 0 0 0 1| ID (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID (L) |
+-+-+-+-+-+-+-+-+
The Assigned Call ID AVP encodes the ID being assigned to call by the
LAC. The flags 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 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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |0 0 0 0 0 0 0 1| Number (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number (L) |
+-+-+-+-+-+-+-+-+
Call Serial Number AVP encodes an identifier assigned by the LAC 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 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 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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 |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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. The value bit field indicates
the bearer capability being used by the incoming call. Bit A if set
indicates that the call is on an analog channel. Bit D if set indi-
cates that the call is on a digital channel. This AVP must be pre-
sent.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
11 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
4 |0 0 0 0 0 0 0 1| ID (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
ID (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Physical Channel ID AVP encodes the vendor specific physical channel
number used for the call. The flags indicate a mandatory option.
The value is used for logging purposes only. This AVP is optional.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 + N | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |0 0 0 0 0 0 0 1| Number... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dialed NUmber AVP encodes the dialed number for the incoming call.
The flags indicate a mandatory option. The value is an ASCII string.
The length of the number is the length in the AVP header minus 7.
This AVP is optional.
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 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 + N | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 |0 0 0 0 0 0 0 1| Number... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dialing NUmber AVP encodes the originating number for the incoming
call. The flags indicate a mandatory option. The value is an ASCII
Valencia expires February 1997 [Page 40]
INTERNET DRAFT April 1996
string. The length of the number is the length in the AVP header
minus 7. This AVP is optional.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 + N | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 |0 0 0 0 0 0 0 1| Sub-Address...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Address AVP encodes additional dialing information. The flags
indicate a mandatory option. The Sub-Address value is an ASCII
string. The length of the string is the length in the AVP header
minus 7 bytes. This AVP is optional.
6.11 Incoming-Call-Reply
The Incoming-Call-Reply is a L2TP control message sent by the LNS to
the LAC in response to a received Incoming-Call-Request message. The
reply indicates the result of the incoming call attempt. It also
provides information to allow the LAC to regulate the transmission of
data to the LNS for this session.
This message is the second in the three-way handshake used by L2TP
for establishing incoming calls. It indicates to the LAC whether the
call should be answered or not. The message is structured as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Control Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming-Call-Reply |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Call ID |
| Result Code |
| Error Code |
| Packet Recv. Window Size |
| Packet Transmit 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 |0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Valencia expires February 1997 [Page 41]
INTERNET DRAFT April 1996
The Incoming-Call-Reply AVP encodes a response by the LNS to the
incoming call indication given by the LAC. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |0 0 0 0 0 0 0 1| ID (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID (L) |
+-+-+-+-+-+-+-+-+
The Assigned Call ID AVP encodes the ID being assigned to call by the
LNS. The flags 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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |0 0 0 0 0 0 0 1| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Result Code AVP encodes the result of the Incoming-Call-Request. 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 Incoming Call should not be established due to the reason
indicated in Error Code
3 - The LAC should not accept the incoming call. It should hang
up or issue a busy indication
This AVP is mandatory.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 |0 0 0 0 0 0 0 1| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Valencia expires February 1997 [Page 42]
INTERNET DRAFT April 1996
The Error Code AVP is used to encode a specific error code in case
the result AVP indicates a General Error. The flags indicate a
mandatory option. The value can be one of the general error IDs
specified in Section 5.5. This AVP is optional.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 |0 0 0 0 0 0 0 1| Size (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size (L) |
+-+-+-+-+-+-+-+-+
Packet Recieve Window Size AVP encodes the window size being adver-
tised by the LNS for this call. The flags indicate a mandatory
option. The Size value indicates the number of received packets the
LNS will buffer for this call. This AVP is optional.
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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |0 0 0 0 0 0 0 1| Delay (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay (L) |
+-+-+-+-+-+-+-+-+
Packet Processing Delay AVP encodes the delay LNS has for processing
window full of packets sent by the LAC. The flags indicate a manda-
tory option. The Delay value is specified in units of 1/10 seconds.
This AVP is optional. Please refer to appendix A to see a descrip-
tion of how this value is determined and used.
6.12 Incoming-Call-Connected
The Incoming-Call-Connected message is a L2TP control message sent by
the LAC to the LNS in response to a received Incoming-Call-Reply. It
provides information to the LNS about particular parameters used for
the call. It also provides information to allow the LNS to regulate
the transmission of data to the LAC for this session.
This message is the third in the three-way handshake used by L2TP for
establishing incoming calls. It provides a mechanism for providing
the LNS with additional information about the call that cannot, in
general, be obtained at the time the Incoming-Call-Request is issued
by the LAC. 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 authen ID |
| 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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 |0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Incoming-Call-Connected AVP encodes a response by the LAC to the
Incoming-Call-Reply message sent by the LAC. The 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |0 0 0 0 0 0 0 1| BPS (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 is suc-
cessful.
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
Valencia expires February 1997 [Page 44]
INTERNET DRAFT April 1996
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Framing Type AVP encodes the framing type for the call. The flags
indicate a mandatory option. The value bit field indicates the type
of PPP framing is used for the call. 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 if the call
attempt is successful.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 |0 0 0 0 0 0 0 1| Size (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size (L) |
+-+-+-+-+-+-+-+-+
Packet Recieve Window Size AVP encodes the window size being adver-
tised by the LAC for this call. The flags indicate a mandatory
option. The Size value indicates the number of received packets the
LAC will buffer for this call. This AVP is optional.
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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 |0 0 0 0 0 0 0 1| Delay (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay (L) |
+-+-+-+-+-+-+-+-+
Packet Processing Delay AVP encodes the delay LAC has for processing
window full of packets sent by the LNS. The flags indicate a manda-
tory option. The Delay value is specified in units of 1/10 seconds.
This AVP is optional. Please 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
Valencia expires February 1997 [Page 45]
INTERNET DRAFT April 1996
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 + length of confreq | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |0 0 0 0 0 0 0 0| LCP confreq...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LAC may have answered the phone call and negotiated LCP with the
dial-in client in order to establish the client's apparent identity.
In this case, this option may be included to indicate the link prop-
erties the client requested in its initial LCP CONFREQ request. The
Value field is a copy of the body of the intial CONFREQ received,
starting at the first option within this packet's body. This AVP is
marked not mandatory, and the AVP itself is optional.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 + length of confreq | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 |0 0 0 0 0 0 0 0| LCP confreq...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See Initial LCP Conf above for rationale. The Value field is a copy
of the body of the final CONFREQ sent to the client to complete LCP
negotiation, starting at the first option within this packet's body.
This AVP is marked not mandatory, and the AVP itself is optional.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 + length of confreq | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 |0 0 0 0 0 0 0 0| LCP confreq...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See Initial LCP Conf above for rationale. The Value field is a copy
of the body of the final CONFREQ received from the client to complete
LCP negotiation, starting at the first option within this packet's
body. This AVP is marked not mandatory, and the AVP itself is
optional.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 |0 0 0 0 0 0 0 0| Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Valencia expires February 1997 [Page 46]
INTERNET DRAFT April 1996
This AVP is marked mandatory, and the AVP itself must be present.
Type is a byte, holding a value:
1 - Textual username/password exchange
2 - PPP CHAP
3 - PPP PAP
4 - None
Associated AVP's for each type of authentication follow.
Proxy authen name
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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 |0 0 0 0 0 0 0 0| Name... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP is marked mandatory, and the AVP itself 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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 + length of challenge | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 |0 0 0 0 0 0 0 0| Challenge... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP is marked mandatory, and the AVP itself must be present for
Proxy authen type 2. The Challenge field contains the value pre-
sented to the client by the LAC.
Proxy authen ID
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 |0 0 0 0 0 0 0 0| ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP is marked mandatory, and the AVP itself must be present for
Proxy authen type 2. The ID field contains the byte ID value pre-
sented to the client by the LAC in its associated CHAP challenge.
Proxy authen response
Valencia expires February 1997 [Page 47]
INTERNET DRAFT April 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 + length of Response | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12 |0 0 0 0 0 0 0 0| Response... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP is marked mandatory, and the AVP itself must be present for
Proxy authen types 1, 2, and 3. The Response field contains the
client's response to the challenge. For Proxy authen type 2, this
field contains the response value received by the LAC. For types 1
or 3, it contains the clear text password received from the client by
the LAC.
6.13 Call-Clear-Request
The Call-Clear-Request is a L2TP control message sent by the LNS to
the LAC indicating that a particular call is to be disconnected. The
call being cleared can be either an incoming or outgoing call, in any
state. The LAC responds to this message with a Call-Disconnect-
Notify message. The message is structured as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Control Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call-Clear-Request |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12 |0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Call-Clear-Request AVP encodes a request by the LNS to the LAC to
disconnect the call. The flags indicate a mandatory option.
6.14 Call-Disconnect-Notify
The Call-Disconnect-Notify message is a 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 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-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 13 |0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Call-Disconnect-Nofity 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |0 0 0 0 0 0 0 1| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Result Code AVP encodes the reason for disconnect. The flags indi-
cate a mandatory option. The Result Code value can be one of the
following:
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
This AVP is mandatory.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |0 0 0 0 0 0 0 1| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Code AVP is used 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. The value can be one of the general error IDs
specified in Section 5.5. This AVP is optional.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 |0 0 0 0 0 0 0 1| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Cause Code AVP is used to give additional information in case of
unsolicited call disconnection. The flags indicate a mandatory
option. The Code value can vary depending upon the type of call.
For ISDN call attempts it is the Q.931 cause code.
Call Statistics 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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 |0 0 0 0 0 0 0 1| Call Stats... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Statistics ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Call Statistics AVP is used by the LAC to send vendor specific
call statistics for logging purposes. The flags indicate a mandatory
option. The Call Statistics value is ab ASCII string containing ven-
dor specific call statistics that LNS can log for diagnostic pur-
poses. The length of the string is the length in the AVP header
minus 7. This AVP is optional.
6.15 WAN-Error-Notify
The WAN-Error-Notify message is a 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. The message is structured as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Control Message Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WAN-Error-Notify |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Valencia expires February 1997 [Page 50]
INTERNET DRAFT April 1996
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 14 |0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The WAN-Error-Nofity 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 14 |0 0 0 0 0 0 0 1| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-out Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Call Errors AVP is used by the LAC to send error information to
the LNS. The flags indicate a mandatory option. The value contains
the following fields:
Reserved - Not used
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
This AVP must be present.
6.16 Set-Link-Info
Valencia expires February 1997 [Page 51]
INTERNET DRAFT April 1996
The Set-Link-Info message is a 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 perform PPP
negotiation on an active PPP session. The message is structured 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 14 |0 0 0 0 0 0 0 1| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ACCM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive ACCM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ACCM AVP is used by the LNS to inform LAC of the ACCM to the LNS.
The flags indicate a mandatory option. 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. This AVP must be present.
6.17 No-op
The No-op message is a L2TP control message sent by either side. Its
primary purpose is to update the Acknowledgment window for the peer
Valencia expires February 1997 [Page 52]
INTERNET DRAFT April 1996
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Control 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 Value is set to 16, indicating No-op. The flags indicate a
mandatory option.
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
The control connection relies on a standard TCP connection for its
service. 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 (may be LAC or LNS)
State Event Action New State
----- ----- ------ ---------
idle Open request Send wait_ctl_reply
Valencia expires February 1997 [Page 53]
INTERNET DRAFT April 1996
Start-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- or bad 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 connection is open, the
originator transmits a send Start-Control-Connection-Request and
then enters the wait_ctl_reply state.
wait_ctl_reply
The originator checks to see if another connection has been
requested from the same peer, and if so, handles the collision
situation described in Section 6.0.1.
When a Start-Control-Connection-Reply is received, it is examined
for a compatible version. If the version of the reply is lower
than the version sent in the request, the older (lower) version
should be used provided it is supported. If the version in the
reply is earlier and supported, the originator moves to the estab-
lished state. If the version is earlier and not supported, a
Stop-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 con-
dition or the receipt of a Stop-Control-Connection-Request. In
the event of a local termination, the originator MUST send a Stop-
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
Valencia expires February 1997 [Page 54]
INTERNET DRAFT April 1996
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 (may be LAC or LNS)
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 established
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 idle
Start-Control-
Connection-
Connected
wait_ctl_reply Receive If auth not OK wait-stop-reply
Start-Control- Send Stop-Control-
Connection- Connection-Request
Connected
established Receive clean-up, send idle
Stop-Control- Stop-Control-
Connection-Request Connection-Reply
established Local terminate Send wait-stop-reply
Start-Control-
Connection-Request
wait-stop-reply Receive clean-up idle
Stop-Control-
Connection-Reply
idle
The control connection receiver waits for an incoming connection
attempt. When notified of an new connection, it should prepare to
receive L2TP messages. When a Start-Control-Connection-Request is
received its version 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 version is earlier 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, close the TCP connection and
remain in the idle state. If the receiver's version is the same as
earlier than the peer's, the receiver SHOULD send a Start-Control-
Connection-Reply with the receiver's version and enter the
established state.
established
An established connection may be terminated by either a local
condition or the reception of a Stop-Control-Connection-Request. In
the event of a local termination, the originator MUST send a Stop-
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
connection.
wait_stop_reply
If a 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 implemented with multi-threaded architectures such
that messages related to multiple calls are not serialized and
blocked.
The call and connection state figures do not specify
exceptions caused by timers. These are addressed in Section 6.0.2.
7.4 Incoming calls
An Incoming-Call-Request message is generated by the LAC when an
associated telephone line rings. The LAC selects a Call ID and serial
number and indicates the call bearer type. Modems should always
indicate analog call type. ISDN calls should indicate digital when
unrestricted digital service or rate adaption is used and analog if
digital modems are involved. Dialing number, dialed number, and
subaddress may be included in the message if they are available from
the telephone network.
Once the LAC sends the Incoming-Call-Request, it waits for a response
from the LNS but does not answer the call from the telephone network.
The LNS may choose not to accept the call 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 is not authorized or supported
If the LNS chooses to accept the call, it responds with an Outgoing-
Call-Reply which also indicates window sizes (see Appendix B). When
the LAC receives the Outgoing-Call-Reply, it attempts to connect the
call, assuming the calling party has not hung up. A final call
connected message from the LAC to the LNS indicates that the call
Valencia expires February 1997 [Page 56]
INTERNET DRAFT April 1996
states 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
----- ----- ------ ---------
idle Ring OR Send wait_reply
Ready to indicate Incoming-Call-Request
incoming conn.
wait-reply Receive clean-up idle
Incoming-Call-Reply
Not Accepting
wait-reply Receive Answer call established
Incoming-Call-Reply Send
Accepting Incoming-Call-Connected
wait-reply Abort, Send clean-up idle
Call-Disconnect-
Notify
established Receive Hang-up and send idle
Clear-Call-Request Call-Disconnect-Notify
established telco line drop Send idle
Call-Disconnect-Notify
established local disconnect Send idle
Call-Disconnect-Notify
The states associated with the LAC for incoming calls are:
idle
The LAC detects an incoming call on one of its telco interfaces.
Typically this means an analog line is ringing or an ISDN TE has
detected an incoming Q.931 SETUP message. The LAC sends an Incom-
ing- Call-Request message and moves to the wait_reply state.
wait_reply
The LAC receives an Incoming-Call-Reply message indicating non-
willingness to accept the call (general error or don't accept) and
moves back into the idle state. If the reply message indicates
that the call is accepted, the LAC sends an Incoming-Call-
Connected message and enters the established state.
established
Valencia expires February 1997 [Page 57]
INTERNET DRAFT April 1996
Data 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.5 LNS Incoming Call States
State Event Action New State
----- ----- ------ ---------
idle Receive If not accepting idle
Incoming-Call-Request Send
Incoming-Call-Reply
with Error
idle Receive If accepting 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-
Clear-Call-Request disconnect
wait- Receive clean-up idle
disconnect Call-Disconnect-Notify
The states associated with the LNS for incoming calls are:
idle
An Incoming-Call-Request message is received. If the request is
not acceptable, an Incoming-Call-Reply is sent back to the LAC and
the LNS remains in the idle state. If the Incoming-Call-Request
message is acceptable, an Incoming-Call-Reply is sent indicating
accept in the result code. The session moves to the wait_connect
state.
wait_connect
If the session is connected 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,
for example, if a telephone user accidently places a standard
voice call to a LAC resulting in a handshake failure on the called
modem.
established
The session is terminated either by receipt of a Call-Disconnect-
Notify message from the LAC or by sending a Call-Clear-Request.
Once a Call-Clear-Request has been sent, the session enters the
wait_disconnect state.
wait_disconnect
Once a Call-Disconnect-Notify is received the session moves back
to the idle state.
7.6 Outgoing calls
Outgoing messages are initiated by a LNS and instruct a LAC to place a
call on a telco interface. There are only two messages for outgoing
calls: Outgoing-Call-Request and Outgoing-Call-Reply. The LNS sends an
Outgoing-Call-Request specifying the dialed party phone number and sub-
address as well as speed and window parameters. The LAC MUST respond to
the Outgoing-Call-Request message with an Outgoing-Call- Reply message
once the LAC determines that:
The call has been successfully connected
A call failure has occurred for reasons such as: no interfaces are
available for dial-out, the called party is busy or does not
answer, or no dial tone is detected on the interface 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 idle
Valencia expires February 1997 [Page 59]
INTERNET DRAFT April 1996
Clear-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 received in error,
respond with an Outgoing-Call-Reply with error condition set.
Otherwise, allocate physical channel to dial on. Place the out-
bound call, wait for a connection, and move to the wait_cs_ans
state.
wait_cs_ans
If the call 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
If a Call-Clear-Request is received, the telco call SHOULD be
released via appropriate mechanisms and a Call-Disconnect-Notify
message SHOULD BE sent to the LNS. If the call is disconnected by
the client or by the telco interface, a Call-Disconnect-Notify
message SHOULD be sent to the 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 ready for data 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 with the LNS for outgoing calls are:
idle
An Outgoing-Call-Request message is 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. No telco call is active. If the
Outgoing-Call-Reply does not indicate an error, the telco call is
connected and the session moves to the established state.
established
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 the idle 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.
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.
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.com
Valencia expires February 1997 [Page 61]
INTERNET DRAFT April 1996
Jeff Taarud
(formerly of 3COM Corporation, no current contact)
William Verthein
U.S. Robotics
12.0 References
TBD
Appendix A: Acknowledgment Time-Outs
L2TP uses sliding windows and time-outs to provide both user session
flow-control across the internetwork and to perform efficient data
buffering to keep the LAC-LNS data channels full without causing
receive buffer overflow. L2TP requires that a time-out be used to
recover from dropped data or acknowledgment packets. The exact
implementation of the time-out is vendor-specific. It is suggested
that an adaptive time-out be implemented with backoff for congestion
control. The time-out mechanism proposed here has the following
properties:
Independent time-outs for each session. A device (LAC or LNS)
will have to maintain and calculate time-outs for every active
session.
An administrator-adjustable maximum time-out, MaxTimeOut, unique
to each device.
An adaptive time-out mechanism that compensates for changing
throughput. To reduce packet processing overhead, vendors may
choose not to recompute the adaptive time-out for every received
acknowledgment. The result of this overhead reduction is that the
time-out will not respond as quickly to rapid network changes.
Timer backoff on time-out to reduce congestion. The backed-off
timer value is limited by the configurable maximum time-out value.
Timer backoff is done every time an acknowledgment time-out
occurs.
In general, this mechanism has the desirable behavior of quickly
backing off upon a time-out and of slowly decreasing the time-out
value as packets are delivered without time-outs.
Some definitions:
Packet Processing Delay (PPD) is the amount of time required for
each side to process the maximum amount of data buffered in their
receive packet sliding window. The PPD is the value exchanged
between the LAC and LNS when a call is established. For the LNS,
this number should be small. For a LAC making modem connections,
this number could be significant.
Sample is the actual amount of time incurred receiving an
Valencia expires February 1997 [Page 62]
INTERNET DRAFT April 1996
acknowledgment for a packet. The Sample is measured, not calcu-
lated.
Round-Trip 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.
Adaptive Time-Out (ATO) is the time that must elapse before an
acknowledgment is considered lost. After a time-out, the sliding
window is partially closed and the ATO is backed off.
Packet Processing Delay (PPD)
The PPD parameter is a 16-bit word exchanged during the Call Control
phase that represents tenths of a second (64 means 6.4 seconds). The
protocol only specifies that the parameter is exchanged, it does not
specify how it is calculated. The way values for PPD are calculated
is implementation-dependent and need not be variable (static time-
outs are allowed). The PPD must be exchanged in the call connect
sequences, even if it remains constant in an implementation. One
possible way to calculate the PPD is:
PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
PPD = PPD' + LACFudge
Header is the total size of the IP and GRE headers, which is 36. The
MTU is the overall MTU for the internetwork link between the LAC and
LNS. WindowSize represents the number of packets in the sliding win-
dow, and is implementation-dependent. The latency of the internet-
work could be used to pick a window size sufficient to keep the cur-
rent session's pipe full. The constant 8 converts octets to bits
(assuming ConnectRate is in bits per second). If ConnectRate is in
bytes per second, omit the 8. LACFudge is not required but can be
used to take overall processing overhead of the LAC into account.
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-Out
Valencia expires February 1997 [Page 63]
INTERNET DRAFT April 1996
We still must decide how much time to allow for acknowledgments to
return. If the time-out is set too high, we may wait an 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.
A.2 Congestion Control: Adjusting for Time-Out
This section describes how the calculation of ATO is modified in the
case where a time-out does occur. When a time-out occurs, the time-
out value should be adjusted rapidly upward. Although the GRE pack-
ets 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 the
Valencia expires February 1997 [Page 64]
INTERNET DRAFT April 1996
backoff timers for the LNS or the LAC. Notice that in addition to
increasing the time-out, we are also shrinking 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 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 by chi, 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.
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.
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 Overflow
Valencia expires February 1997 [Page 65]
INTERNET DRAFT April 1996
When a receiver's window overflows with too many incoming packets,
excess packets are thrown away. This situation should not arise if
the sliding window procedures are being properly followed by the
transmitter and receiver. It is assumed that, on the transmit side,
packets are buffered for transmission and are no longer accepted from
the packet source when the transmit buffer fills.
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 and L2TP header, is sent within a UDP datagram.
The source and destination ports are the same (1701), with demulti-
plexing being achieved using Tunnel ID values. It is legal for the
source IP address of a given Tunnel ID to change over the life of a
connection, as this may correspond to a peer with multiple IP inter-
faces responding to a network topology change. Responses should
reflect the last source IP address for that Tunnel ID.
IP fragmentation may occur as the L2TP packet travels over the IP
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 environments in which the MTUs of the
path over which the L2TP packets are likely to travel have a consis-
tent value.
Port 1701 is used for both L2F [XXX] and L2TP packets. The two types
of packets may be detected by their headers; L2TP has a Vers field of
2, L2F has a 1 in this field instead.
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
are identical to 8.1, except that the lack of a UDP header makes the
packet more compact.
9.0 Security Considerations
L2TP encounters several security issues in its operation. The gen-
eral approach of L2TP to these issues is documented here.
9.1 Tunnel Endpoint Security
The tunnel endpoints may authenticate each other during tunnel
establishment. This authentication has the same security
attributes as CHAP, and has reasonable protection against reply
Valencia expires February 1997 [Page 66]
INTERNET DRAFT April 1996
and snooping.
Once the tunnel endpoints have authenticated, a derived Key may be
carried in subsequent packets, which provides mild protection
against brief or "accidental" attacks. There is no cryptographic
strength to these Keys, and any 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
the 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 the media or the L2TP packets would have to be
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 for both direct dial-in
clients as well as PPP clients carried within a tunnel. With this
level of client security, sessions are protected against attacks
against the carrying tunnel, as well as attacks on the LAC itself.
Because both encryption and compression can occur at the PPP
layer, the two can be coordinated, permitting compression to pre-
cede encryption.
The optional proxy CHAP function of L2TP can permit an entirely
transparent PPP tunnel, with a single LCP and CHAP sequence being
seen by the client. For cases where the LAC and the entire path
to the LNS are operated by a single entity, this function may pro-
vide acceptable security. For cases where LNS-initiated authenti-
cation is required, proxy CHAP still permits an initial access
decision to be made before accepting the tunnel, permitting the
LNS in most cases to reject tunnel initiations rather than accept
them and later disconnect.
Valencia expires February 1997 [Page 67]
