status types. For example, HDLC primary and secondary stations
refer to a circuit as being "Receive Ready" or "Receive Not
Ready", while Frame Relay refers to a circuit as "Active" or
"Inactive". This AVP adopts the latter terminology, though the
concept remains the same regardless of the PW type for the L2TP
session.
In the simplest case, the circuit to which this AVP refers is a
single physical interface, port, or circuit, depending on the
application and the session setup. The status indication in this
AVP may then be used to provide simple ILMI interworking for a
variety of circuit types. For virtual or multipoint interfaces,
the Circuit Status AVP is still utilized, but in this case, it
refers to the state of an internal structure or a logical set of
circuits. Each PW-specific companion document MUST specify
precisely how this AVP is translated for each circuit type.
If this AVP is received with a Not Active notification for a given
L2TP session, all data traffic for that session MUST cease (or not
begin) in the direction of the sender of the Circuit Status AVP
until the circuit is advertised as Active.
The Circuit Status MUST be advertised by this AVP in ICRQ, ICRP,
OCRQ, and OCRP messages. Often, the circuit type will be marked
Active when initiated, but subsequently MAY be advertised as
Inactive. This indicates that an L2TP session is to be created,
but that the interface or circuit is still not ready to pass
traffic. The ICCN, OCCN, and SLI control messages all MAY contain
this AVP to update the status of the circuit after establishment
of the L2TP session is requested.
If additional circuit status information is needed for a given PW
type, any new PW-specific AVPs MUST be defined in a separate
document. This AVP is only for general circuit status information
generally applicable to all circuit/interface types.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for
this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 8.
Circuit Errors (WEN)
The Circuit Errors AVP, Attribute Type 34, conveys circuit error
information to the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following fields are defined:
Reserved: 2 octets of Reserved data is present (providing longword
alignment within the AVP of the following values). Reserved
data MUST be zero on sending and ignored upon receipt.
Hardware Overruns: Number of receive buffer overruns since call
was established.
Buffer Overruns: Number of buffer overruns detected since call was
established.
Timeout Errors: Number of timeouts 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 SHOULD be set to 0, but MAY vary (see Section 5.2). The
Length (before hiding) of this AVP is 32.
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 Language
6.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 Digest
6.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 ID
6.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 ID
6.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