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