The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Challenge is one or more octets of random data.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 6 plus the length of the Challenge.
Challenge Response (SCCCN, SCCRP)
The Response AVP, Attribute Type 13, provides a response to a
challenge received.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response is a 16 octet value reflecting the CHAP-style
[RFC1994] response to the challenge.
This AVP MUST be present in an SCCRP or SCCCN if a challenge was
received in the preceding SCCRQ or SCCRP. For purposes of the ID
value in the CHAP response calculation, the value of the Message
Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for
an SCCCN).
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 22.
4.4.4 Call Management AVPs
Q.931 Cause Code (CDN)
The Q.931 Cause Code AVP, Attribute Type 12, is used to give
additional information in case of unsolicited call disconnection.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Msg | Advisory Msg...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [DSS1]. An additional ASCII text Advisory Message may
also be included (presence indicated by the AVP Length) to further
explain the reason for disconnecting.
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
this AVP MUST be set to 1. The Length of this AVP is 9, plus the
size of the Advisory Message.
Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ)
The Assigned Session ID AVP, Attribute Type 14, encodes the ID
being assigned to this session by the sender.
The Attribute Value field for this AVP has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Session ID is a 2 octet non-zero unsigned integer.
The Assigned Session ID AVP is establishes a value used to
multiplex and demultiplex data sent over a tunnel between the LNS
and LAC. The L2TP peer MUST place this value in the Session ID
header field of all control and data messages that it subsequently
transmits over the tunnel that belong to this session. Before the
Assigned Session ID AVP is received from a peer, messages MUST be
sent to that peer with a Session ID of 0 in the header of all
control messages.
In the CDN control message, the same Assigned Session ID AVP first
sent to the receiving peer is used, permitting the peer to
identify the appropriate tunnel even if CDN is sent before an
Assigned Session ID is received.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 8.
Call Serial Number (ICRQ, OCRQ)
The Call Serial Number AVP, Attribute Type 15, encodes an
identifier assigned by the LAC or LNS to this call.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Call Serial Number is a 32 bit value.
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 LNSs and
LACs.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 10.
Minimum BPS (OCRQ)
The Minimum BPS AVP, Attribute Type 16, encodes the lowest
acceptable line speed for this call.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Minimum BPS is a 32 bit value indicates the speed in bits per
second.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 10.
Maximum BPS (OCRQ)
The Maximum BPS AVP, Attribute Type 17, encodes the highest
acceptable line speed for this call.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Maximum BPS is a 32 bit value indicates the speed in bits per
second.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 10.
Bearer Type (ICRQ, OCRQ)
The Bearer Type AVP, Attribute Type 18, encodes the bearer type
for the incoming or outgoing call.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future Bearer Types |A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Bearer Type is a 32-bit bit mask, which indicates the bearer
capability of the call (ICRQ) or required for the call (OCRQ). If
set, bit A indicates that the call refers to an analog channel. If
set, bit D indicates that the call refers to a digital channel.
Both may be set, indicating that the call was either
indistinguishable, or can be placed on either type of channel.
Bits in the Value field of this AVP MUST only be set by the LNS
for an OCRQ if it was set in the Bearer Capabilities AVP received
from the LAC during control connection establishment.
It is valid to set neither the A nor D bits in an ICRQ. Such a
setting may indicate that the call was not received over a
physical link (e.g if the LAC and PPP are located in the same
subsystem).
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 10.
Framing Type (ICCN, OCCN, OCRQ)
The Framing Type AVP, Attribute Type 19, encodes the framing type
for the incoming or outgoing call.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future Framing Types |A|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Framing Type is a 32-bit mask, which indicates the type of PPP
framing requested for an OCRQ, or the type of PPP framing
negotiated for an OCCN or ICCN. The framing type MAY be used as an
indication to PPP on the LNS as to what link options to use for
LCP negotiation [RFC1662].
Bit A indicates asynchronous framing. Bit S indicates synchronous
framing. For an OCRQ, both may be set, indicating that either type
of framing may be used.
Bits in the Value field of this AVP MUST only be set by the LNS
for an OCRQ if it was set in the Framing Capabilities AVP received
from the LAC during control connection establishment.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 10.
Called Number (ICRQ, OCRQ)
The Called Number AVP, Attribute Type 21, encodes the telephone
number to be called for an OCRQ, and the Called number for an
ICRQ.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Called Number... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Called Number is an ASCII string. Contact between the
administrator of the LAC and the LNS may be necessary to
coordinate interpretation of the value needed in this AVP.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 6 plus the length of the Called Number.
Calling Number (ICRQ)
The Calling Number AVP, Attribute Type 22, encodes the originating
number for the incoming call.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Calling Number... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calling Number is an ASCII string. Contact between the
administrator of the LAC and the LNS may be necessary to
coordinate interpretation of the value in this AVP.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 6 plus the length of the Calling Number.
Sub-Address (ICRQ, OCRQ)
The Sub-Address AVP, Attribute Type 23, encodes additional dialing
information.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Address ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sub-Address is an ASCII string. Contact between the
administrator of the LAC and the LNS may be necessary to
coordinate interpretation of the value in this AVP.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 6 plus the length of the Sub-Address.
(Tx) Connect Speed (ICCN, OCCN)
The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes the
speed of the facility chosen for the connection attempt.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The (Tx) Connect Speed BPS is a 4 octet value indicating the speed
in bits per 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
remote system). When the optional Rx Connect Speed AVP is NOT
present, the connection speed between the remote system and LAC is
assumed to be symmetric and is represented by the single value in
this AVP.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 10.
Rx Connect Speed (ICCN, OCCN)
The Rx Connect Speed AVP, Attribute Type 38, represents the speed
of the connection from the perspective of the LAC (e.g. data
flowing from the remote system to the LAC).
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS (H) | BPS (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BPS is a 4 octet value indicating the speed in bits per second.
Presence of this AVP implies that the connection speed may be
asymmetric with respect to the transmit connect speed given in the
(Tx) Connect Speed AVP.
This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for
this AVP MUST be set to 0. The Length (before hiding) of this AVP
is 10.
Physical Channel ID (ICRQ, OCRP)
The Physical Channel ID AVP, Attribute Type 25, encodes the vendor
specific physical channel number used for a call.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Physical Channel ID is a 4 octet value intended to be used for
logging purposes only.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 0. The Length (before hiding) of this AVP
is 10.
Private Group ID (ICCN)
The Private Group ID AVP, Attribute Type 37, is used by the LAC to
indicate that this call is to be associated with a particular
customer group.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Group ID ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Private Group ID is a string of octets of arbitrary length.
The LNS MAY treat the PPP session as well as network traffic
through this session in a special 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, local configuration, or some other source.
This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for
this AVP MUST be set to 0. The Length (before hiding) of this AVP
is 6 plus the length of the Private Group ID.
Sequencing Required (ICCN, OCCN)
The Sequencing Required AVP, Attribute Type 39, indicates to the
LNS that Sequence Numbers MUST always be present on the data
channel.
This AVP has no Attribute Value field.
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for
this AVP MUST be set to 1. The Length of this AVP is 6.
4.4.5 Proxy LCP and Authentication AVPs
The LAC may have answered the call and negotiated LCP with the
remote system, perhaps in order to establish the system's apparent
identity. In this case, these AVPs may be included to indicate the
link properties the remote system initially requested, properties
the remote system and LAC ultimately negotiated, as well as PPP
authentication information sent and received by the LAC. This
information may be used to initiate the PPP LCP and authentication
systems on the LNS, allowing PPP to continue without renegotiation
of LCP. Note that the LNS policy may be to enter an additional
round of LCP negotiation and/or authentication if the LAC is not
trusted.
Initial Received LCP CONFREQ (ICCN)
In the Initial Received LCP CONFREQ AVP, Attribute Type 26,
provides the LNS with the Initial CONFREQ received by the LAC from
the PPP Peer.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCP CONFREQ is a copy of the body of the initial CONFREQ received,
starting at the first option within the body of the LCP message.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 0. The Length (before hiding) of this AVP
is 6 plus the length of the CONFREQ.
Last Sent LCP CONFREQ (ICCN)
In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the
LNS with the Last CONFREQ sent by the LAC to the PPP Peer.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LCP CONFREQ is a copy of the body of the final CONFREQ sent to
the client to complete LCP negotiation, starting at the first
option within the body of the LCP message.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 0. The Length (before hiding) of this AVP
is 6 plus the length of the CONFREQ.
Last Received LCP CONFREQ (ICCN)
The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the
LNS with the Last CONFREQ received by the LAC from the PPP Peer.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LCP CONFREQ is a copy of the body of the final CONFREQ
received from the client to complete LCP negotiation, starting at
the first option within the body of the LCP message.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 0. The Length (before hiding) of this AVP
is 6 plus the length of the CONFREQ.
Proxy Authen Type (ICCN)
The Proxy Authen Type AVP, Attribute Type 29, determines if proxy
authentication should be used.
The Attribute Value field for this AVP has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authen Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authen Type is a 2 octet unsigned integer, holding:
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 0. The Length (before hiding) of this AVP
is 8.
Defined Authen Type values are:
0 - Reserved
1 - Textual username/password exchange
2 - PPP CHAP
3 - PPP PAP
4 - No Authentication
5 - Microsoft CHAP Version 1 (MSCHAPv1)
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, requiring
a restart of the authentication phase at the LNS if the client
has already entered this phase with the
LAC (which may be determined by the Proxy LCP AVP if present).
Associated AVPs for each type of authentication follow.
Proxy Authen Name (ICCN)
The Proxy Authen Name AVP, Attribute Type 30, specifies the name
of the authenticating client when using proxy authentication.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authen Name... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authen Name is a string of octets of arbitrary length. It
contains the name specified in the client's authentication
response.
This AVP MUST be present in messages containing a Proxy Authen
Type AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable
to employ AVP hiding for obscuring the cleartext name.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 0. The Length (before hiding) is 6 plus
the length of the cleartext name.
Proxy Authen Challenge (ICCN)
The Proxy Authen Challenge AVP, Attribute Type 31, specifies the
challenge sent by the LAC to the PPP Peer, when using proxy
authentication.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Challenge is a string of one or more octets.
This AVP MUST be present for Proxy Authen Types 2 and 5. The
Challenge field contains the CHAP challenge presented to the
client by the LAC.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 0. The Length (before hiding) of this AVP
is 6, plus the length of the Challenge.
Proxy Authen ID (ICCN)
The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value
of the PPP Authentication that was started between the LAC and the
PPP Peer, when proxy authentication is being used.
The Attribute Value field for this AVP has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ID is a 2 octet unsigned integer, the most significant octet MUST
be 0.
The Proxy Authen ID AVP MUST be present for Proxy authen types 2,
3 and 5. For 2 and 5, the ID field contains the byte ID value
presented to the client by the LAC in its Challenge. For 3, it is
the Identifier value of the Authenticate-Request.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 0.
Proxy Authen Response (ICCN)
The Proxy Authen Response AVP, Attribute Type 33, specifies the
PPP Authentication response received by the LAC from the PPP Peer,
when proxy authentication is used.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response is a string of octets.
This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The
Response field contains the client's response to the challenge.
For Proxy authen types 2 and 5, this field contains the response
value received by the LAC. For types 1 or 3, it contains the clear
text password received from the client by the LAC. In the case of
cleartext passwords, AVP hiding is recommended.
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 0. The Length (before hiding) of this AVP
is 6 plus the length of the Response.
4.4.6 Call Status AVPs
Call Errors (WEN)
The Call Errors AVP, Attribute Type 34, is used by the LAC to send
error information to the LNS.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CRC Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC Errors (L) | Framing Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Errors (L) | Hardware Overruns (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns (L) | Buffer Overruns (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns (L) | Time-out Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-out Errors (L) | Alignment Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following fields are defined:
Reserved - Not used, MUST be 0
CRC Errors - Number of PPP frames received with CRC errors
since call was established
Framing Errors - Number of improperly framed PPP packets
received
Hardware Overruns - Number of receive buffer over-runs since
call was established
Buffer Overruns - Number of buffer over-runs detected since
call was established
Time-out Errors - Number of time-outs since call was
established
Alignment Errors - Number of alignment errors since call was
established
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for
this AVP MUST be set to 1. The Length (before hiding) of this AVP
is 32.
ACCM (SLI)
The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC
of the ACCM negotiated with the PPP Peer by the LNS.
The Attribute Value field for this AVP has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Send ACCM (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ACCM (L) | Receive ACCM (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive ACCM (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Send ACCM and Receive ACCM are each 4 octet values preceded by a 2
octet reserved quantity. The send ACCM value should be used by the
LAC to process packets it 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.
This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for
this AVP MUST be set to 1. The Length of this AVP is 16.
5.0 Protocol Operation
The necessary setup for tunneling a PPP session with L2TP consists of
two steps, (1) establishing the Control Connection for a Tunnel, and
(2) establishing a Session as triggered by an incoming or outgoing
call request. The Tunnel and corresponding Control Connection MUST be
established before an incoming or outgoing call is initiated. An L2TP
Session MUST be established before L2TP can begin to tunnel PPP
frames. Multiple Sessions may exist across a single Tunnel and
multiple Tunnels may exist between the same LAC and LNS.
+-----+ +-----+
| |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| |
| LAC | | LNS |
| #######Control Connection######## |
[Remote] | | | |
[System]------Call----------*============L2TP Session=============* |
PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| | | |
[Remote] | | | |
[System]------Call----------*============L2TP Session=============* |
PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| | | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| |
+-----+ +-----+
Figure 5.1 Tunneling PPP
5.1 Control Connection Establishment
The Control Connection is the initial connection that must be
achieved between an LAC and LNS before sessions may be brought up.
Establishment of the control connection includes securing the
identity of the peer, as well as identifying the peer's L2TP version,
framing, and bearer capabilities, etc.
A three message exchange is utilized to setup the control connection.
Following is a typical message exchange:
LAC or LNS LAC or LNS
---------- ----------
SCCRQ ->
<- SCCRP
SCCCN ->
<- ZLB ACK
The ZLB ACK is sent if there are no further messages waiting in queue
for that peer.
5.1.1 Tunnel Authentication
L2TP incorporates a simple, optional, CHAP-like [RFC1994] tunnel
authentication system during control connection establishment. If an
LAC or LNS wishes to authenticate the identity of the peer it is
contacting or being contacted by, a Challenge AVP is included in the
SCCRQ or SCCRP message. If a Challenge AVP is received in an SCCRQ or
SCCRP, a Challenge Response AVP MUST be sent in the following SCCRP
or SCCCN, respectively. If the expected response and response
received from a peer does not match, establishment of the tunnel MUST
be disallowed.
To participate in tunnel authentication, a single shared secret MUST
exist between the LAC and LNS. This is the same shared secret used
for AVP hiding (see Section 4.3). See Section 4.4.3 for details on
construction of the Challenge and Response AVPs.
5.2 Session Establishment
After successful control connection establishment, individual
sessions may be created. Each session corresponds to single PPP
stream between the LAC and LNS. Unlike control connection
establishment, session establishment is directional with respect to
the LAC and LNS. The LAC requests the LNS to accept a session for an
incoming call, and the LNS requests the LAC to accept a session for
placing an outgoing call.
5.2.1 Incoming Call Establishment
A three message exchange is employed to setup the session. Following
is a typical sequence of events:
LAC LNS
--- ---
(Call
Detected)
ICRQ ->
<- ICRP
ICCN ->
<- ZLB ACK
The ZLB ACK is sent if there are no further messages waiting in queue
for that peer.
5.2.2 Outgoing Call Establishment
A three message exchange is employed to setup the session. Following
is a typical sequence of events:
LAC LNS
--- ---
<- OCRQ
OCRP ->
(Perform
Call
Operation)
OCCN ->
<- ZLB ACK
The ZLB ACK is sent if there are no further messages waiting in queue
for that peer.
5.3 Forwarding PPP Frames
Once tunnel establishment is complete, PPP frames from the remote
system are received at the LAC, stripped of CRC, link framing, and
transparency bytes, encapsulated in L2TP, and forwarded over the
appropriate tunnel. The LNS receives the L2TP packet, and processes
the encapsulated PPP frame as if it were received on a local PPP
interface.
The sender of a message associated with a particular session and
tunnel places the Session ID and Tunnel ID (specified by its peer) in
the Session ID and Tunnel ID header for all outgoing messages. In
this manner, PPP frames are multiplexed and demultiplexed over a
single tunnel between a given LNS-LAC pair. Multiple tunnels may
exist between a given LNS-LAC pair, and multiple sessions may exist
within a tunnel.
The value of 0 for Session ID and Tunnel ID is special and MUST NOT
be used as an Assigned Session ID or Assigned Tunnel ID. For the
cases where a Session ID has not yet been assigned by the peer (i.e.,
during establishment of a new session or tunnel), the Session ID
field MUST be sent as 0, and the Assigned Session ID AVP within the
message MUST be used to identify the session. Similarly, for cases
where the Tunnel ID has not yet been assigned from the peer, the
Tunnel ID MUST be sent as 0 and Assigned Tunnel ID AVP used to
identify the tunnel.
5.4 Using Sequence Numbers on the Data Channel
Sequence numbers are defined in the L2TP header for control messages
and optionally for data messages (see Section 3.1). These are used to
provide a reliable control message transport (see Section 5.8) and
optional data message sequencing. Each peer maintains separate
sequence numbers for the control connection and each individual data
session within a tunnel.
Unlike the L2TP control channel, the L2TP data channel does not use
sequence numbers to retransmit lost data messages. Rather, data
messages may use sequence numbers to detect lost packets and/or
restore the original sequence of packets that may have been reordered
during transport. The LAC may request that sequence numbers be
present in data messages via the Sequencing Required AVP (see Section
4.4.6). If this AVP is present during session setup, sequence numbers
MUST be present at all times. If this AVP is not present, sequencing
presence is under control of the LNS. The LNS controls enabling and
disabling of sequence numbers by sending a data message with or
without sequence numbers present at any time during the life of a
session. Thus, if the LAC receives a data message without sequence
numbers present, it MUST stop sending sequence numbers in future data
messages. If the LAC receives a data message with sequence numbers
present, it MUST begin sending sequence numbers in future outgoing
data messages. If the LNS enables sequencing after disabling it
earlier in the session, the sequence number state picks up where it
left off before.
The LNS may initiate disabling of sequencing at any time during the
session (including the first data message sent). It is recommended
that for connections where reordering or packet loss may occur,
sequence numbers always be enabled during the initial negotiation
stages of PPP and disabled only when and if the risk is considered
acceptable. For example, if the PPP session being tunneled is not
utilizing any stateful compression or encryption protocols and is
only carrying IP (as determined by the PPP NCPs that are
established), then the LNS might decide to disable sequencing as IP
is tolerant to datagram loss and reordering.
5.5 Keepalive (Hello)
A keepalive mechanism is employed by L2TP in order to differentiate
tunnel outages from extended periods of no control or data activity
on a tunnel. This is accomplished by injecting Hello control messages
(see Section 6.5) after a specified period of time has elapsed since
the last data or control message was received on a tunnel. As for any
other control message, if the Hello message is not reliably delivered
then the tunnel is declared down and is reset. The transport 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.
5.6 Session Teardown
Session teardown may be initiated by either the LAC or LNS and is
accomplished by sending a CDN control message. After the last session
is cleared, the control connection MAY be torn down as well (and
typically is). Following is an example of a typical control message
exchange:
LAC or LNS LAC or LNS
CDN ->
(Clean up)
<- ZLB ACK
(Clean up)
5.7 Control Connection Teardown
Control connection teardown may be initiated by either the LAC or LNS
and is accomplished by sending a single StopCCN control message. The
receiver of a StopCCN MUST send a ZLB ACK to acknowledge receipt of
the message and maintain enough control connection state to properly
accept StopCCN retransmissions over at least a full retransmission
cycle (in case the ZLB ACK is lost). The recommended time for a full
retransmission cycle is 31 seconds (see section 5.8). Following is an
example of a typical control message exchange:
LAC or LNS LAC or LNS
StopCCN ->
(Clean up)
<- ZLB ACK
(Wait)
(Clean up)
An implementation may shut down an entire tunnel and all sessions on
the tunnel by sending the StopCCN. Thus, it is not necessary to clear
each session individually when tearing down the whole tunnel.
5.8 Reliable Delivery of Control Messages
L2TP provides a lower level reliable transport service for all
control messages. The Nr and Ns fields of the control message header
(see section 3.1) belong to this transport. The upper level
functions of L2TP are not concerned with retransmission or ordering
of control messages. The reliable control message is a sliding window
transport that provides control message retransmission and congestion
control. Each peer maintains separate sequence number state for the
control connection within a tunnel.
The message sequence number, Ns, begins at 0. Each subsequent message
is sent with the next increment of the sequence number. The sequence
number is thus a free running counter represented modulo 65536. The
sequence number in the header of a received message is considered
less than or equal to the last received number if its value lies in
the range of the last received number and the preceding 32767 values,
inclusive. For example, if the last received sequence number was 15,
then messages with sequence numbers 0 through 15, as well as 32784
through 65535, would be considered less than or equal. Such a message
would be considered a duplicate of a message already received and
ignored from processing. However, in order to ensure that all
messages are acknowledged properly (particularly in the case of a
lost ZLB ACK message), receipt of duplicate messages MUST be
acknowledged by the reliable transport. This acknowledgement may
either piggybacked on a message in queue, or explicitly via a ZLB
ACK.
All control messages take up one slot in the control message sequence
number space, except the ZLB acknowledgement. Thus, Ns is not
incremented after a ZLB message is sent.
The last received message number, Nr, is used to acknowledge messages
received by an L2TP peer. It contains the sequence number of the
message the peer expects to receive next (e.g. the last Ns of a non-
ZLB message received plus 1, modulo 65536). While the Nr in a
received ZLB is used to flush messages from the local retransmit
queue (see below), Nr of the next message sent is not be updated by
the Ns of the ZLB.
The reliable transport at a receiving peer is responsible for making
sure that control messages are delivered in order and without
duplication to the upper level. 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 by the peer.
Each tunnel maintains a queue of control messages to be transmitted
to its 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
period of time (a recommended default is 1 second) passes without
acknowledgement, the message is retransmitted. The retransmitted
message contains the same Ns value, but the Nr value MUST be updated
with the sequence number of the next expected message.
Each subsequent retransmission of a message MUST employ an
exponential backoff interval. Thus, if the first retransmission
occurred after 1 second, the next retransmission should occur after 2
seconds has elapsed, then 4 seconds, etc. An implementation MAY place
a cap upon the maximum interval between retransmissions. This cap
MUST be no less than 8 seconds per retransmission. If no peer
response is detected after several retransmissions, (a recommended
default is 5, but SHOULD be configurable), 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.
A sliding window mechanism is used for control message transmission.
Consider two peers A & B. Suppose A specifies a Receive Window Size
AVP with a value of N in the SCCRQ or SCCRP messages. B is now
allowed to have up to N outstanding control messages. Once N have
been sent, it must wait for an acknowledgment that advances the
window before sending new control messages. An implementation may
support a receive window of only 1 (i.e., by sending out a Receive
Window Size AVP with a value of 1), but MUST accept a window of up to
4 from its peer (e.g. have the ability to send 4 messages before
backing off). A value of 0 for the Receive Window Size AVP is
invalid.
When retransmitting control messages, a slow start and congestion
avoidance window adjustment procedure SHOULD be utilized. The
recommended procedure for this is described in Appendix A.
A peer MUST NOT withhold acknowledgment of messages 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.
Appendix B contains examples of control message transmission,
acknowledgement, and retransmission.
6.0 Control Connection Protocol Specification
The following control connection messages are used to establish,
clear and maintain L2TP tunnels. 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.
6.1 Start-Control-Connection-Request (SCCRQ)
Start-Control-Connection-Request (SCCRQ) is a control message used to
initialize a tunnel between an LNS and an LAC. It is sent by either
the LAC or the LNS to being the tunnel establishment process.
The following AVPs MUST be present in the SCCRQ:
Message Type AVP
Protocol Version
Host Name
Framing Capabilities
Assigned Tunnel ID
The Following AVPs MAY be present in the SCCRQ:
Bearer Capabilities
Receive Window Size
Challenge
Tie Breaker
Firmware Revision
Vendor Name
6.2 Start-Control-Connection-Reply (SCCRP)
Start-Control-Connection-Reply (SCCRP) is a control message sent in
reply to a received SCCRQ message. SCCRP is used to indicate that the
SCCRQ was accepted and establishment of the tunnel should continue.
The following AVPs MUST be present in the SCCRP:
Message Type
Protocol Version
Framing Capabilities
Host Name
Assigned Tunnel ID
The following AVPs MAY be present in the SCCRP:
Bearer Capabilities
Firmware Revision
Vendor Name
Receive Window Size
Challenge
Challenge Response
6.3 Start-Control-Connection-Connected (SCCCN)
Start-Control-Connection-Connected (SCCCN) is a control message sent
in reply to an SCCRP. SCCCN completes the tunnel establishment
process.
The following AVP MUST be present in the SCCCN:
Message Type
The following AVP MAY be present in the SCCCN:
Challenge Response
6.4 Stop-Control-Connection-Notification (StopCCN)
Stop-Control-Connection-Notification (StopCCN) is a control message
sent by either the LAC or LNS to inform its peer that the tunnel is
being shutdown and the control connection should be closed. In
addition, all active sessions are implicitly cleared (without sending
any explicit call control messages). The reason for issuing this
request is indicated in the Result Code AVP. There is no explicit
reply to the message, only the implicit ACK that is received by the
reliable control message transport layer.
The following AVPs MUST be present in the StopCCN:
Message Type
Assigned Tunnel ID
Result Code
6.5 Hello (HELLO)
The Hello (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.
The sending of HELLO messages and the policy for sending them are
left up to the implementation. A peer MUST NOT expect HELLO messages
at any time or interval. As with all messages sent on the control
connection, the receiver will return either a ZLB ACK or an
(unrelated) message piggybacking the necessary acknowledgement
information.
Since 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.
Keepalives for the tunnel MAY be implemented by sending a HELLO if a
period of time (a recommended default is 60 seconds, but SHOULD be
configurable) has passed without receiving any message (data or
control) from the peer.
HELLO messages are global to the tunnel. The Session ID in a HELLO
message MUST be 0.
The Following AVP MUST be present in the HELLO message:
Message Type
6.6 Incoming-Call-Request (ICRQ)
Incoming-Call-Request (ICRQ) is a control message sent by the LAC to
the LNS when an incoming call is detected. It is the first in a three
message exchange used for establishing a session within an L2TP
tunnel.
ICRQ is used to indicate that a session is to be established between
the LAC and LNS for this call and provides the LNS with parameter
information for the session. The LAC may defer answering the call
until it has received an ICRP from the LNS indicating that the
session should be established. This mechanism allows the LNS to
obtain sufficient information about the call before determining
whether it 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 ICRP message is received; the
LAC simply spoofs the "call indication" and "call answer" steps in
this case.
The following AVPs MUST be present in the ICRQ:
Message Type
Assigned Session ID
Call Serial Number
The following AVPs MAY be present in the ICRQ:
Bearer Type
Physical Channel ID
Calling Number
Called Number
Sub-Address
6.7 Incoming-Call-Reply (ICRP)
Incoming-Call-Reply (ICRP) is a control message sent by the LNS to
the LAC in response to a received ICRQ message. It is the second in
the three message exchange used for establishing sessions within an
L2TP tunnel.
ICRP is used to indicate that the ICRQ was successful and for the LAC
to answer the call if it has not already done so. It also allows the
LNS to indicate necessary parameters for the L2TP session.
The following AVPs MUST be present in the ICRP:
Message Type
Assigned Session ID
6.8 Incoming-Call-Connected (ICCN)
Incoming-Call-Connected (ICCN) is a control message sent by the LAC
to the LNS in response to a received ICRP message. It is the third
message in the three message exchange used for establishing sessions
within an L2TP tunnel.
ICCN is used to indicate that the ICRP was accepted, the call has
been answered, and that the L2TP session should move to the
established state. It also provides additional information to the
LNS about parameters used for the answered call (parameters that may
not always available at the time the ICRQ is issued).
The following AVPs MUST be present in the ICCN:
Message Type
(Tx) Connect Speed
Framing Type
The following AVPs MAY be present in the ICCN:
Initial Received LCP CONFREQ
Last Sent LCP CONFREQ
Last Received LCP CONFREQ
Proxy Authen Type