RFC 3931
Layer Two Tunneling Protocol - Version 3 (L2TPv3)
6. Control Connection Protocol Specification
The following control messages are used to establish, maintain, and tear down L2TP control connections. All data packets are sent in network order (high-order octets first). Any "reserved" or "empty" fields MUST be sent as 0 values to allow for protocol extensibility. The exchanges in which these messages are involved are outlined in Section 3.3.
6.1. Start-Control-Connection-Request (SCCRQ)
Start-Control-Connection-Request (SCCRQ) is a control message used to initiate a control connection between two LCCEs. It is sent by either the LAC or the LNS to begin the control connection establishment process. The following AVPs MUST be present in the SCCRQ: Message Type Host Name Router ID Assigned Control Connection ID Pseudowire Capabilities List The following AVPs MAY be present in the SCCRQ: Random Vector Control Message Authentication Nonce Message Digest Control Connection Tie Breaker Vendor Name Receive Window Size Preferred Language6.2. Start-Control-Connection-Reply (SCCRP)
Start-Control-Connection-Reply (SCCRP) is the control message sent in reply to a received SCCRQ message. The SCCRP is used to indicate that the SCCRQ was accepted and that establishment of the control connection should continue. The following AVPs MUST be present in the SCCRP: Message Type Host Name Router ID Assigned Control Connection ID Pseudowire Capabilities List The following AVPs MAY be present in the SCCRP: Random Vector Control Message Authentication Nonce Message Digest Vendor Name Receive Window Size Preferred Language
6.3. Start-Control-Connection-Connected (SCCCN)
Start-Control-Connection-Connected (SCCCN) is the control message sent in reply to an SCCRP. The SCCCN completes the control connection establishment process. The following AVP MUST be present in the SCCCN: Message Type The following AVP MAY be present in the SCCCN: Random Vector Message Digest6.4. Stop-Control-Connection-Notification (StopCCN)
Stop-Control-Connection-Notification (StopCCN) is the control message sent by either LCCE to inform its peer that the control connection is being shut down and that the control connection should be closed. In addition, all active sessions are implicitly cleared (without sending any explicit session 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 delivery layer. The following AVPs MUST be present in the StopCCN: Message Type Result Code The following AVPs MAY be present in the StopCCN: Random Vector Message Digest Assigned Control Connection ID Note that the Assigned Control Connection ID MUST be present if the StopCCN is sent after an SCCRQ or SCCRP message has been sent.6.5. Hello (HELLO)
The Hello (HELLO) message is an L2TP control message sent by either peer of a control connection. This control message is used as a "keepalive" for the control connection. See Section 4.2 for a description of the keepalive mechanism.
HELLO messages are global to the control connection. The Session ID
in a HELLO message MUST be 0.
The following AVP MUST be present in the HELLO:
Message Type
The following AVP MAY be present in the HELLO:
Random Vector
Message Digest
6.6. Incoming-Call-Request (ICRQ)
Incoming-Call-Request (ICRQ) is the control message sent by an LCCE
to a peer when an incoming call is detected (although the ICRQ may
also be sent as a result of a local event). It is the first in a
three-message exchange used for establishing a session via an L2TP
control connection.
The ICRQ is used to indicate that a session is to be established
between an LCCE and a peer. The sender of an ICRQ provides the peer
with parameter information for the session. However, the sender
makes no demands about how the session is terminated at the peer
(i.e., whether the L2 traffic is processed locally, forwarded, etc.).
The following AVPs MUST be present in the ICRQ:
Message Type
Local Session ID
Remote Session ID
Serial Number
Pseudowire Type
Remote End ID
Circuit Status
The following AVPs MAY be present in the ICRQ:
Random Vector
Message Digest
Assigned Cookie
Session Tie Breaker
L2-Specific Sublayer
Data Sequencing
Tx Connect Speed
Rx Connect Speed
Physical Channel ID
6.7. Incoming-Call-Reply (ICRP)
Incoming-Call-Reply (ICRP) is the control message sent by an LCCE in response to a received ICRQ. It is the second in the three-message exchange used for establishing sessions within an L2TP control connection. The ICRP is used to indicate that the ICRQ was successful and that the peer should establish (i.e., answer) the incoming call if it has not already done so. It also allows the sender to indicate specific parameters about the L2TP session. The following AVPs MUST be present in the ICRP: Message Type Local Session ID Remote Session ID Circuit Status The following AVPs MAY be present in the ICRP: Random Vector Message Digest Assigned Cookie L2-Specific Sublayer Data Sequencing Tx Connect Speed Rx Connect Speed Physical Channel ID6.8. Incoming-Call-Connected (ICCN)
Incoming-Call-Connected (ICCN) is the control message sent by the LCCE that originally sent an ICRQ upon receiving an ICRP from its peer. It is the final message in the three-message exchange used for establishing L2TP sessions. The ICCN is used to indicate that the ICRP was accepted, that the call has been established, and that the L2TP session should move to the established state. It also allows the sender to indicate specific parameters about the established call (parameters that may not have been available at the time the ICRQ was issued). The following AVPs MUST be present in the ICCN: Message Type Local Session ID Remote Session ID
The following AVPs MAY be present in the ICCN:
Random Vector
Message Digest
L2-Specific Sublayer
Data Sequencing
Tx Connect Speed
Rx Connect Speed
Circuit Status
6.9. Outgoing-Call-Request (OCRQ)
Outgoing-Call-Request (OCRQ) is the control message sent by an LCCE
to an LAC to indicate that an outbound call at the LAC is to be
established based on specific destination information sent in this
message. It is the first in a three-message exchange used for
establishing a session and placing a call on behalf of the initiating
LCCE.
Note that a call may be any L2 connection requiring well-known
destination information to be sent from an LCCE to an LAC. This call
could be a dialup connection to the PSTN, an SVC connection, the IP
address of another LCCE, or any other destination dictated by the
sender of this message.
The following AVPs MUST be present in the OCRQ:
Message Type
Local Session ID
Remote Session ID
Serial Number
Pseudowire Type
Remote End ID
Circuit Status
The following AVPs MAY be present in the OCRQ:
Random Vector
Message Digest
Assigned Cookie
Tx Connect Speed
Rx Connect Speed
Session Tie Breaker
L2-Specific Sublayer
Data Sequencing
6.10. Outgoing-Call-Reply (OCRP)
Outgoing-Call-Reply (OCRP) is the control message sent by an LAC to an LCCE in response to a received OCRQ. It is the second in a three-message exchange used for establishing a session within an L2TP control connection. OCRP is used to indicate that the LAC has been able to attempt the outbound call. The message returns any relevant parameters regarding the call attempt. Data MUST NOT be forwarded until the OCCN is received, which indicates that the call has been placed. The following AVPs MUST be present in the OCRP: Message Type Local Session ID Remote Session ID Circuit Status The following AVPs MAY be present in the OCRP: Random Vector Message Digest Assigned Cookie L2-Specific Sublayer Tx Connect Speed Rx Connect Speed Data Sequencing Physical Channel ID6.11. Outgoing-Call-Connected (OCCN)
Outgoing-Call-Connected (OCCN) is the control message sent by an LAC to another LCCE after 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. OCCN is used to indicate that the result of a requested outgoing call was successful. It also provides information to the LCCE who requested the call about the particular parameters obtained after the call was established. The following AVPs MUST be present in the OCCN: Message Type Local Session ID Remote Session ID
The following AVPs MAY be present in the OCCN:
Random Vector
Message Digest
L2-Specific Sublayer
Tx Connect Speed
Rx Connect Speed
Data Sequencing
Circuit Status
6.12. Call-Disconnect-Notify (CDN)
The Call-Disconnect-Notify (CDN) is a control message sent by an LCCE
to request disconnection of a specific session. Its purpose is to
inform the peer of the disconnection and the reason for the
disconnection. 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
Local Session ID
Remote Session ID
The following AVP MAY be present in the CDN:
Random Vector
Message Digest
6.13. WAN-Error-Notify (WEN)
The WAN-Error-Notify (WEN) is a control message sent from an LAC to
an LNS to indicate WAN error conditions. 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
Local Session ID
Remote Session ID
Circuit Errors
The following AVP MAY be present in the WEN:
Random Vector
Message Digest
6.14. Set-Link-Info (SLI)
The Set-Link-Info control message is sent by an LCCE to convey link
or circuit status change information regarding the circuit associated
with this L2TP session. For example, if PPP renegotiates LCP at an
LNS or between an LAC and a Remote System, or if a forwarded Frame
Relay VC transitions to Active or Inactive at an LAC, an SLI message
SHOULD be sent to indicate this event. Precise details of when the
SLI is sent, what PW type-specific AVPs must be present, and how
those AVPs should be interpreted by the receiving peer are outside
the scope of this document. These details should be described in the
associated pseudowire-specific documents that require use of this
message.
The following AVPs MUST be present in the SLI:
Message Type
Local Session ID
Remote Session ID
The following AVPs MAY be present in the SLI:
Random Vector
Message Digest
Circuit Status
6.15. Explicit-Acknowledgement (ACK)
The Explicit Acknowledgement (ACK) message is used only to
acknowledge receipt of a message or messages on the control
connection (e.g., for purposes of updating Ns and Nr values).
Receipt of this message does not trigger an event for the L2TP
protocol state machine.
A message received without any AVPs (including the Message Type AVP),
is referred to as a Zero Length Body (ZLB) message, and serves the
same function as the Explicit Acknowledgement. ZLB messages are only
permitted when Control Message Authentication defined in Section 4.3
is not enabled.
The following AVPs MAY be present in the ACK message:
Message Type
Message Digest
7. Control Connection State Machines
The state tables defined in this section govern the exchange of
control messages defined in Section 6. Tables are defined for
incoming call placement and outgoing call placement, as well as for
initiation of the control connection itself. The state tables do not
encode timeout and retransmission behavior, as this is handled in the
underlying reliable control message delivery mechanism (see Section
4.2).
7.1. Malformed AVPs and Control Messages
Receipt of an invalid or unrecoverable malformed control message
SHOULD be logged appropriately and the control connection cleared to
ensure recovery to a known state. The control connection may then be
restarted by the initiator.
An invalid control message is defined as (1) a message that contains
a Message Type marked as mandatory (see Section 5.4.1) but that is
unknown to the implementation, or (2) a control message that is
received in the wrong state.
Examples of malformed control messages include (1) a message that has
an invalid value in its header, (2) a message that contains an AVP
that is formatted incorrectly or whose value is out of range, and (3)
a message that is missing a required AVP. A control message with a
malformed header MUST be discarded.
When possible, a malformed AVP should be treated as an unrecognized
AVP (see Section 5.2). Thus, an attempt to inspect the M bit SHOULD
be made to determine the importance of the malformed AVP, and thus,
the severity of the malformation to the entire control message. If
the M bit can be reasonably inspected within the malformed AVP and is
determined to be set, then as with an unrecognized AVP, the
associated session or control connection MUST be shut down. If the M
bit is inspected and is found to be 0, the AVP MUST be ignored
(assuming recovery from the AVP malformation is indeed possible).
This policy must not be considered as a license to send malformed
AVPs, but rather, as a guide towards how to handle an improperly
formatted message if one is received. It is impossible to list all
potential malformations of a given message and give advice for each.
One example of a malformed AVP situation that should be recoverable
is if the Rx Connect Speed AVP is received with a length of 10 rather than 14, implying that the connect speed bits-per-second is being formatted in 4 octets rather than 8. If the AVP does not have its M bit set (as would typically be the case), this condition is not considered catastrophic. As such, the control message should be accepted as though the AVP were not present (though a local error message may be logged). 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 control connection destruction, the reliable delivery mechanism must be allowed to run (see Section 4.2) before destroying the control connection. This permits the control connection management messages to be reliably delivered to the peer. Appendix B.1 contains an example of lock-step control connection establishment.7.2. Control Connection States
The L2TP control connection protocol is not distinguishable between the two LCCEs but is distinguishable between the originator and receiver. The originating peer is the one that first initiates establishment of the control connection. (In a tie breaker situation, this is the winner of the tie.) Since either the LAC or the LNS can be the originator, a collision can occur. See the Control Connection Tie Breaker AVP in Section 5.4.3 for a description of this and its resolution. State Event Action New State ----- ----- ------ --------- idle Local open Send SCCRQ wait-ctl-reply request idle Receive SCCRQ, Send SCCRP wait-ctl-conn acceptable idle Receive SCCRQ, Send StopCCN, idle not acceptable clean up idle Receive SCCRP Send StopCCN, idle clean up idle Receive SCCCN Send StopCCN, idle clean up
wait-ctl-reply Receive SCCRP, Send SCCCN, established
acceptable send control-conn
open event to
waiting sessions
wait-ctl-reply Receive SCCRP, Send StopCCN, idle
not acceptable clean up
wait-ctl-reply Receive SCCRQ, Send SCCRP, wait-ctl-conn
lose tie breaker, Clean up losing
SCCRQ acceptable connection
wait-ctl-reply Receive SCCRQ, Send StopCCN, idle
lose tie breaker, Clean up losing
SCCRQ unacceptable connection
wait-ctl-reply Receive SCCRQ, Send StopCCN for wait-ctl-reply
win tie breaker losing connection
wait-ctl-reply Receive SCCCN Send StopCCN, idle
clean up
wait-ctl-conn Receive SCCCN, Send control-conn established
acceptable open event to
waiting sessions
wait-ctl-conn Receive SCCCN, Send StopCCN, idle
not acceptable clean up
wait-ctl-conn Receive SCCRQ, Send StopCCN, idle
SCCRP clean up
established Local open Send control-conn established
request open event to
(new call) waiting sessions
established Administrative Send StopCCN, idle
control-conn clean up
close event
established Receive SCCRQ, Send StopCCN, idle
SCCRP, SCCCN clean up
idle, Receive StopCCN Clean up idle
wait-ctl-reply,
wait-ctl-conn,
established
The states associated with an LCCE for control connection
establishment are as follows:
idle
Both initiator and recipient start from this state. An initiator
transmits an SCCRQ, while a recipient remains in the idle state
until receiving an SCCRQ.
wait-ctl-reply
The originator checks to see if another connection has been
requested from the same peer, and if so, handles the collision
situation described in Section 5.4.3.
wait-ctl-conn
Awaiting an SCCCN. If the SCCCN is valid, the control connection
is established; otherwise, it is torn down (sending a StopCCN with
the proper result and/or error code).
established
An established connection may be terminated by either a local
condition or the receipt of a StopCCN. In the event of a local
termination, the originator MUST send a StopCCN and clean up the
control connection. If the originator receives a StopCCN, it MUST
also clean up the control connection.
7.3. Incoming Calls
An ICRQ is generated by an LCCE, typically in response to an incoming
call or a local event. Once the LCCE sends the ICRQ, it waits for a
response from the peer. However, it may choose to postpone
establishment of the call (e.g., answering the call, bringing up the
circuit) until the peer has indicated with an ICRP that it will
accept the call. The peer may choose not to accept the call if, for
instance, there are insufficient resources to handle an additional
session.
If the peer chooses to accept the call, it responds with an ICRP.
When the local LCCE receives the ICRP, it attempts to establish the
call. A final call connected message, the ICCN, is sent from the
local LCCE to the peer to indicate that the call states for both
LCCEs should enter the established state. If the call is terminated
before the peer can accept it, a CDN is sent by the local LCCE to
indicate this condition.
When a call transitions to a "disconnected" or "down" state, the call
is cleared normally, and the local LCCE sends a CDN. Similarly, if
the peer wishes to clear a call, it sends a CDN and cleans up its
session.
7.3.1. ICRQ Sender States
State Event Action New State ----- ----- ------ --------- idle Call signal or Initiate local wait-control-conn ready to receive control-conn incoming conn open idle Receive ICCN, Clean up idle ICRP, CDN wait-control- Bearer line drop Clean up idle conn or local close request wait-control- control-conn-open Send ICRQ wait-reply conn wait-reply Receive ICRP, Send ICCN established acceptable wait-reply Receive ICRP, Send CDN, idle Not acceptable clean up wait-reply Receive ICRQ, Process as idle lose tie breaker ICRQ Recipient (Section 7.3.2) wait-reply Receive ICRQ, Send CDN wait-reply win tie breaker for losing session wait-reply Receive CDN, Clean up idle ICCN wait-reply Local close Send CDN, idle request clean up established Receive CDN Clean up idle established Receive ICRQ, Send CDN, idle ICRP, ICCN clean up established Local close Send CDN, idle request clean up
The states associated with the ICRQ sender are as follows:
idle
The LCCE detects an incoming call on one of its interfaces (e.g.,
an analog PSTN line rings, or an ATM PVC is provisioned), or a
local event occurs. The LCCE initiates its control connection
establishment state machine and moves to a state waiting for
confirmation of the existence of a control connection.
wait-control-conn
In this state, the session is waiting for either the control
connection to be opened or for verification that the control
connection is already open. Once an indication that the control
connection has been opened is received, session control messages
may be exchanged. The first of these messages is the ICRQ.
wait-reply
The ICRQ sender receives either (1) a CDN indicating the peer is
not willing to accept the call (general error or do not accept)
and moves back into the idle state, or (2) an ICRP indicating the
call is accepted. In the latter case, the LCCE sends an ICCN and
enters the established state.
established
Data is exchanged over the session. The call may be cleared by
any of the following:
+ An event on the connected interface: The LCCE sends a CDN.
+ Receipt of a CDN: The LCCE cleans up, disconnecting the call.
+ A local reason: The LCCE sends a CDN.
7.3.2. ICRQ Recipient States
State Event Action New State
----- ----- ------ ---------
idle Receive ICRQ, Send ICRP wait-connect
acceptable
idle Receive ICRQ, Send CDN, idle
not acceptable clean up
idle Receive ICRP Send CDN idle
clean up
idle Receive ICCN Clean up idle
wait-connect Receive ICCN, Prepare for established
acceptable data
wait-connect Receive ICCN, Send CDN, idle
not acceptable clean up
wait-connect Receive ICRQ, Send CDN, idle
ICRP clean up
idle, Receive CDN Clean up idle
wait-connect,
established
wait-connect Local close Send CDN, idle
established request clean up
established Receive ICRQ, Send CDN, idle
ICRP, ICCN clean up
The states associated with the ICRQ recipient are as follows:
idle
An ICRQ is received. If the request is not acceptable, a CDN is
sent back to the peer LCCE, and the local LCCE remains in the idle
state. If the ICRQ is acceptable, an ICRP is sent. The session
moves to the wait-connect state.
wait-connect
The local LCCE is waiting for an ICCN from the peer. Upon receipt
of the ICCN, the local LCCE moves to established state.
established
The session is terminated either by sending a CDN or by receiving
a CDN from the peer. Clean up follows on both sides regardless of
the initiator.
7.4. Outgoing Calls
Outgoing calls instruct an LAC to place a call. There are three
messages for outgoing calls: OCRQ, OCRP, and OCCN. An LCCE first
sends an OCRQ to an LAC to request an outgoing call. The LAC MUST
respond to the OCRQ with an OCRP once it determines that the proper
facilities exist to place the call and that the call is
administratively authorized. Once the outbound call is connected,
the LAC sends an OCCN to the peer indicating the final result of the
call attempt.
7.4.1. OCRQ Sender States
State Event Action New State ----- ----- ------ --------- idle Local open Initiate local wait-control-conn request control-conn-open idle Receive OCCN, Clean up idle OCRP wait-control- control-conn-open Send OCRQ wait-reply conn wait-reply Receive OCRP, none wait-connect acceptable wait-reply Receive OCRP, Send CDN, idle not acceptable clean up wait-reply Receive OCCN Send CDN, idle clean up wait-reply Receive OCRQ, Process as idle lose tie breaker OCRQ Recipient (Section 7.4.2) wait-reply Receive OCRQ, Send CDN wait-reply win tie breaker for losing session wait-connect Receive OCCN none established wait-connect Receive OCRQ, Send CDN, idle OCRP clean up idle, Receive CDN Clean up idle wait-reply, wait-connect, established established Receive OCRQ, Send CDN, idle OCRP, OCCN clean up wait-reply, Local close Send CDN, idle wait-connect, request clean up established
wait-control- Local close Clean up idle
conn request
The states associated with the OCRQ sender are as follows:
idle, wait-control-conn
When an outgoing call request is initiated, a control connection
is created as described above, if not already present. Once the
control connection is established, an OCRQ is sent to the LAC, and
the session moves into the wait-reply state.
wait-reply
If a CDN is received, the session is cleaned up and returns to
idle state. If an OCRP is received, the call is in progress, and
the session moves to the wait-connect state.
wait-connect
If a CDN is received, the session is cleaned up and returns to
idle state. If an OCCN is received, the call has succeeded, and
the session may now exchange data.
established
If a CDN is received, the session is cleaned up and returns to
idle state. Alternatively, if the LCCE chooses to terminate the
session, it sends a CDN to the LAC, cleans up the session, and
moves the session to idle state.
7.4.2. OCRQ Recipient (LAC) States
State Event Action New State
----- ----- ------ ---------
idle Receive OCRQ, Send OCRP, wait-cs-answer
acceptable Place call
idle Receive OCRQ, Send CDN, idle
not acceptable clean up
idle Receive OCRP Send CDN, idle
clean up
idle Receive OCCN, Clean up idle
CDN
wait-cs-answer Call placement Send OCCN established
successful
wait-cs-answer Call placement Send CDN, idle
failed clean up
wait-cs-answer Receive OCRQ, Send CDN, idle
OCRP, OCCN clean up
established Receive OCRQ, Send CDN, idle
OCRP, OCCN clean up
wait-cs-answer, Receive CDN Clean up idle
established
wait-cs-answer, Local close Send CDN, idle
established request clean up
The states associated with the LAC for outgoing calls are as follows:
idle
If the OCRQ is received in error, respond with a CDN. Otherwise,
place the call, send an OCRP, and move to the wait-cs-answer
state.
wait-cs-answer
If the call is not completed or a timer expires while waiting for
the call to complete, send a CDN with the appropriate error
condition set, and go to idle state. If a circuit-switched
connection is established, send an OCCN indicating success, and go
to established state.
established
If the LAC receives a CDN from the peer, the call MUST be released
via appropriate mechanisms, and the session cleaned up. If the
call is disconnected because the circuit transitions to a
"disconnected" or "down" state, the LAC MUST send a CDN to the
peer and return to idle state.
7.5. Termination of a Control Connection
The termination of a control connection consists of either peer
issuing a StopCCN. The sender of this message SHOULD wait a full
control message retransmission cycle (e.g., 1 + 2 + 4 + 8 ...
seconds) for the acknowledgment of this message before releasing the
control information associated with the control connection. The
recipient of this message should send an acknowledgment of the
message to the peer, then release the associated control information.
When to release a control connection 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 control
connection open for a period of time or perhaps indefinitely after
the last session for that control connection is cleared. Others may choose to disconnect the control connection immediately after the last call on the control connection disconnects.
(page 78 continued on part 5)
