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.
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
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
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
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
Proxy Authen Name
Proxy Authen Challenge
Proxy Authen ID
Proxy Authen Response
Private Group ID
Rx Connect Speed
Sequencing Required
6.9. Outgoing-Call-Request (OCRQ)
Outgoing-Call-Request (OCRQ) is a control message sent by the LNS to
the LAC to indicate that an outbound call from the LAC is to be
established. It is the first in a three message exchange used for
establishing a session within an L2TP tunnel.
OCRQ is used to indicate that a session is to be established between
the LNS and LAC for this call and provides the LAC with parameter
information for both the L2TP session, and the call that is to be
placed
An LNS MUST have received a Bearer Capabilities AVP during tunnel
establishment from an LAC in order to request an outgoing call to
that LAC.
The following AVPs MUST be present in the OCRQ:
Message Type
Assigned Session ID
Call Serial Number
Minimum BPS
Maximum BPS
Bearer Type
Framing Type
Called Number
The following AVPs MAY be present in the OCRQ:
Sub-Address
6.10. Outgoing-Call-Reply (OCRP)
Outgoing-Call-Reply (OCRP) is a control message sent by the LAC to
the LNS in response to a received OCRQ message. It is the second in a
three message exchange used for establishing a session within an L2TP
tunnel.
OCRP is used to indicate that the LAC is able to attempt the outbound
call and returns certain parameters regarding the call attempt.
The following AVPs MUST be present in the OCRP:
Message Type
Assigned Session ID
The following AVPs MAY be present in the OCRP:
Physical Channel ID
6.11. Outgoing-Call-Connected (OCCN)
Outgoing-Call-Connected (OCCN) is a control message sent by the LAC
to the LNS following the OCRP and after the outgoing call has been
completed. It is the final message in a three message exchange used
for establishing a session within an L2TP tunnel.
OCCN is used to indicate that the result of a requested outgoing call
was successful. It also provides information to the LNS about the
particular parameters obtained after the call was established.
The following AVPs MUST be present in the OCCN:
Message Type
(Tx) Connect Speed
Framing Type
The following AVPs MAY be present in the OCCN:
Rx Connect Speed
Sequencing Required
6.12. Call-Disconnect-Notify (CDN)
The Call-Disconnect-Notify (CDN) message is an L2TP control message
sent by either the LAC or LNS to request disconnection of a specific
call within the tunnel. Its purpose is to inform the peer of the
disconnection and the reason why the disconnection occurred. The peer
MUST clean up any resources, and does not send back any indication of
success or failure for such cleanup.
The following AVPs MUST be present in the CDN:
Message Type
Result Code
Assigned Session ID
The following AVPs MAY be present in the CDN:
Q.931 Cause Code
6.13. WAN-Error-Notify (WEN)
The WAN-Error-Notify message is an L2TP control message sent by the
LAC to the LNS to indicate WAN error conditions (conditions that
occur on the interface supporting PPP). The counters in this message
are cumulative. This message should only be sent when an error
occurs, and not more than once every 60 seconds. The counters are
reset when a new call is established.
The following AVPs MUST be present in the WEN:
Message Type
Call Errors
The Set-Link-Info message is an L2TP control message sent by the LNS
to the LAC to set PPP-negotiated options. These options can change
at any time during the life of the call, thus the LAC MUST be able to
update its internal call information and behavior on an active PPP
session.
The following AVPs MUST be present in the SLI:
Message Type
ACCM
