RFC 2661
Layer Two Tunneling Protocol "L2TP"
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 PPP5.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 Name6.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
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 ID6.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 Required6.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
6.14 Set-Link-Info (SLI)
The Set-Link-Info message is an L2TP control message sent by the LNS
to the LAC to set PPP-negotiated options. 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
7.0 Control Connection State Machines
The control messages defined in section 6 are exchanged by way of
state tables defined in this section. Tables are defined for incoming
call placement, outgoing call placement, as well as for initiation of
the tunnel itself. The state tables do not encode timeout and retransmission behavior, as this is handled in the underlying semantics defined in Section 5.8.7.1 Control Connection Protocol Operation
This section describes the operation of various L2TP control connection functions and the Control Connection messages which are used to support them. Receipt of an invalid or 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 a message which contains a Message Type that is marked mandatory (see Section 4.4.1) and is unknown to the implementation, or a control message that is received in an improper sequence (e.g. an SCCCN sent in reply to an SCCRQ). Examples of a malformed control message include one that has an invalid value in its header, contains an AVP that is formatted incorrectly or whose value is out of range, or a message that is missing a required AVP. A control message with a malformed header should be discarded. A control message with an invalid AVP should look to the M-bit for that AVP to determine whether the error is recoverable or not. A malformed yet recoverable non-mandatory (M-bit is not set) AVP within a control message should be treated in a similar manner as an unrecognized non-mandatory AVP. Thus, if a malformed AVP is received with the M-bit set, the session or tunnel should be terminated with a proper Result or Error Code sent. If the M-bit is not set, the AVP should be ignored (with the exception of logging a local error message) and the message accepted. This MUST NOT be considered a license to send malformed AVPs, but simply 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. That said, one example of a recoverable, malformed AVP might be if the Rx Connect Speed AVP, attribute 38, is received with a length of 8 rather than 10 and the BPS given in 2 octets rather than 4. Since the Rx Connect Speed is non-mandatory, this condition should not be considered catastrophic. As such, the control message should be accepted as if the AVP had not been received (with the exception of a local error message being 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 tunnel destruction, the reliable delivery mechanism must be allowed to run (see Section 5.8) before destroying the tunnel. This permits the tunnel management messages to be reliably delivered to the peer. Appendix B.1 contains an example of lock-step tunnel establishment.7.2 Control Connection States
The L2TP control connection protocol is not distinguishable between the LNS and LAC, but is distinguishable between the originator and receiver. The originating peer is the one which first initiates establishment of the tunnel (in a tie breaker situation, this is the winner of the tie). Since either LAC or LNS can be the originator, a collision can occur. See the Tie Breaker AVP in Section 4.4.3 for a description of this and its resolution.7.2.1 Control Connection Establishment
State Event Action New State ----- ----- ------ --------- idle Local Send SCCRQ wait-ctl-reply Open request idle Receive SCCRQ, Send SCCRP wait-ctl-conn acceptable idle Receive SCCRQ, Send StopCCN, idle not acceptable Clean up idle Receive SCCRP Send StopCCN idle Clean up idle Receive SCCCN Clean up idle wait-ctl-reply Receive SCCRP, Send SCCCN, established acceptable Send tunnel-open event to waiting sessions wait-ctl-reply Receive SCCRP, Send StopCCN, idle not acceptable Clean up wait-ctl-reply Receive SCCRQ, Clean up, idle lose tie-breaker Re-queue SCCRQ for idle state
wait-ctl-reply Receive SCCCN Send StopCCN idle
Clean up
wait-ctl-conn Receive SCCCN, Send tunnel-open established
acceptable event to waiting
sessions
wait-ctl-conn Receive SCCCN, Send StopCCN, idle
not acceptable Clean up
wait-ctl-conn Receive SCCRP, Send StopCCN, idle
SCCRQ Clean up
established Local Send tunnel-open established
Open request event to waiting
(new call) sessions
established Admin Send StopCCN idle
Tunnel Close Clean up
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 the LNS or LAC for control connection
establishment are:
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.8.
When an SCCRP is received, it is examined for a compatible
version. If the version of the reply is lower than the version
sent in the request, the older (lower) version should be used
provided it is supported. If the version in the reply is earlier
and supported, the originator moves to the established state. If
the version is earlier and not supported, a StopCCN MUST be sent
to the peer and the originator cleans up and terminates the
tunnel.
wait-ctl-conn
This is where an SCCCN is awaited; upon receipt, the challenge
response is checked. The tunnel either is established, or is torn
down if an authorization failure is detected.
established
An established connection may be terminated by either a local
condition or the receipt of a Stop-Control-Connection-
Notification. In the event of a local termination, the originator
MUST send a Stop-Control-Connection-Notification and clean up the
tunnel.
If the originator receives a Stop-Control-Connection-Notification
it MUST also clean up the tunnel.
7.3 Timing considerations
Due to the real-time nature of telephone signaling, both the LNS and
LAC should be implemented with multi-threaded architectures such that
messages related to multiple calls are not serialized and blocked.
The call and connection state figures do not specify exceptions
caused by timers. These are addressed in Section 5.8.
7.4 Incoming calls
An Incoming-Call-Request message is generated by the LAC when an
incoming call is detected (for example, an associated telephone line
rings). The LAC selects a Session ID and serial number and indicates
the call bearer type. Modems should always indicate analog call type.
ISDN calls should indicate digital when unrestricted digital service
or rate adaption is used and analog if digital modems are involved.
Calling Number, Called Number, and Subaddress may be included in the
message if they are available from the telephone network.
Once the LAC sends the Incoming-Call-Request, it waits for a response
from the LNS but it does not necessarily answer the call from the
telephone network yet. The LNS may choose not to accept the call if:
- No resources are available to handle more sessions
- The dialed, dialing, or subaddress fields do not correspond to
an authorized user
- The bearer service is not authorized or supported
If the LNS chooses to accept the call, it responds with an Incoming- Call-Reply. When the LAC receives the Incoming-Call-Reply, it attempts to connect the call. A final call connected message from the LAC to the LNS indicates that the call states for both the LAC and the LNS should enter the established state. If the call terminated before the LNS could accept it, a Call-Disconnect-Notify is sent by the LAC to indicate this condition. When the dialed-in client hangs up, the call is cleared normally and the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to clear a call, it sends a Call-Disconnect-Notify message and cleans up its session.
7.4.1 LAC Incoming Call States
State Event Action New State ----- ----- ------ --------- idle Bearer Ring or Initiate local wait-tunnel Ready to indicate tunnel open incoming conn. idle Receive ICCN, Clean up idle ICRP, CDN wait-tunnel Bearer line drop Clean up idle or local close request wait-tunnel tunnel-open Send ICRQ wait-reply wait-reply Receive ICRP, Send ICCN established acceptable wait-reply Receive ICRP, Send CDN, idle Not acceptable Clean up wait-reply Receive ICRQ Send CDN idle Clean up wait-reply Receive CDN Clean up idle ICCN wait-reply Local Send CDN, idle close request or Clean up Bearer line drop established Receive CDN Clean up idle established Receive ICRQ, Send CDN, idle ICRP, ICCN Clean up established Bearer line Send CDN, idle drop or local Clean up close request
The states associated with the LAC for incoming calls are:
idle
The LAC detects an incoming call on one of its interfaces.
Typically this means an analog line is ringing or an ISDN TE has
detected an incoming Q.931 SETUP message. The LAC initiates its
tunnel establishment state machine, and moves to a state waiting
for confirmation of the existence of a tunnel.
wait-tunnel
In this state the session is waiting for either the control
connection to be opened or for verification that the tunnel is
already open. Once an indication that the tunnel has/was opened,
session control messages may be exchanged. The first of these is
the Incoming-Call-Request.
wait-reply
The LAC receives either a CDN message indicating the LNS is not
willing to accept the call (general error or don't accept) and
moves back into the idle state, or an Incoming-Call-Reply message
indicating the call is accepted, the LAC sends an Incoming-Call-
Connected message and enters the established state.
established
Data is exchanged over the tunnel. The call may be cleared
following:
+ An event on the connected interface: The LAC sends a Call-
Disconnect-Notify message
+ Receipt of a Call-Disconnect-Notify message: The LAC cleans
up, disconnecting the call.
+ A local reason: The LAC sends a Call-Disconnect-Notify
message.
7.4.2 LNS Incoming Call States
State Event Action New State ----- ----- ------ --------- idle Receive ICRQ, Send ICRP wait-connect acceptable idle Receive ICRQ, Send CDN, idle not acceptable Clean up 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 Send CDN, idle established Close request Clean up established Receive ICRQ, Send CDN idle ICRP, ICCN Clean up The states associated with the LNS for incoming calls are: idle An Incoming-Call-Request message is received. If the request is not acceptable, a Call-Disconnect-Notify is sent back to the LAC and the LNS remains in the idle state. If the Incoming-Call- Request message is acceptable, an Incoming-Call-Reply is sent. The session moves to the wait-connect state. wait-connect If the session is still connected on the LAC, the LAC sends an Incoming-Call-Connected message to the LNS which then moves into established state. The LAC may send a Call-Disconnect-Notify to indicate that the incoming caller could not be connected. This
could happen, for example, if a telephone user accidentally places
a standard voice call to an LAC resulting in a handshake failure
on the called modem.
established
The session is terminated either by receipt of a Call-Disconnect-
Notify message from the LAC or by sending a Call-Disconnect-
Notify. Clean up follows on both sides regardless of the
initiator.
7.5 Outgoing calls
Outgoing calls are initiated by an LNS and instruct an LAC to place a
call. There are three messages for outgoing calls: Outgoing-Call-
Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS
sends an Outgoing-Call-Request specifying the dialed party phone
number, subaddress and other parameters. The LAC MUST respond to the
Outgoing-Call-Request message with an Outgoing-Call-Reply message
once the LAC determines that the proper facilities exist to place the
call and the call is administratively authorized. For example, is
this LNS allowed to dial an international call? Once the outbound
call is connected, the LAC sends an Outgoing-Call-Connected message
to the LNS indicating the final result of the call attempt:
7.5.1 LAC Outgoing Call States
State Event Action New State ----- ----- ------ --------- idle Receive OCRQ, Send OCRP, wait-cs-answer acceptable Open bearer idle Receive OCRQ, Send CDN, idle not acceptable Clean up idle Receive OCRP Send CDN idle Clean up idle Receive OCCN, Clean up idle CDN wait-cs-answer Bearer answer, Send OCCN established framing detected wait-cs-answer Bearer failure Send CDN, idle 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 established Bearer line drop, Send CDN, idle Local close Clean up request The states associated with the LAC for outgoing calls are: idle If Outgoing-Call-Request is received in error, respond with a Call-Disconnect-Notify. Otherwise, allocate a physical channel and send an Outgoing-Call-Reply. Place the outbound call and move to the wait-cs-answer state. wait-cs-answer If the call is not completed or a timer expires waiting for the call to complete, send a Call-Disconnect-Notify with the appropriate error condition set and go to idle state. If a circuit
switched connection is established and framing is detected, send
an Outgoing-Call-Connected indicating success and go to
established state.
established
If a Call-Disconnect-Notify is received by the LAC, the telco call
MUST be released via appropriate mechanisms and the session
cleaned up. If the call is disconnected by the client or the
called interface, a Call-Disconnect-Notify message MUST be sent to
the LNS. The sender of the Call-Disconnect-Notify message returns
to the idle state after sending of the message is complete.
7.5.2 LNS Outgoing Call States
State Event Action New State ----- ----- ------ --------- idle Local Initiate local wait-tunnel open request tunnel-open idle Receive OCCN, Clean up idle OCRP, CDN wait-tunnel tunnel-open Send OCRQ wait-reply wait-reply Receive OCRP, none wait-connect acceptable wait-reply Receive OCRP, Send CDN idle not acceptable Clean up wait-reply Receive OCCN, Send CDN idle OCRQ Clean up 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 Send CDN idle wait-connect, Close request Clean up established wait-tunnel Local Clean up idle Close request The states associated with the LNS for outgoing calls are: idle, wait-tunnel When an outgoing call is initiated, a tunnel is first created, much as the idle and wait-tunnel states for an LAC incoming call. Once a tunnel is established, an Outgoing-Call-Request message is sent to the LAC and the session moves into the wait-reply state.
wait-reply
If a Call-Disconnect-Notify is received, an error occurred, and
the session is cleaned up and returns to idle. If an Outgoing-
Call-Reply is received, the call is in progress and the session
moves to the wait-connect state.
wait-connect
If a Call-Disconnect-Notify is received, the call failed; the
session is cleaned up and returns to idle. If an Outgoing-Call-
Connected is received, the call has succeeded and the session may
now exchange data.
established
If a Call-Disconnect-Notify is received, the call has been
terminated for the reason indicated in the Result and Cause Codes;
the session moves back to the idle state. If the LNS chooses to
terminate the session, it sends a Call-Disconnect-Notify to the
LAC and then cleans up and idles its session.
7.6 Tunnel Disconnection
The disconnection of a tunnel consists of either peer issuing a
Stop-Control-Connection-Notification. The sender of this Notification
should wait a finite period of time for the acknowledgment of this
message before releasing the control information associated with the
tunnel. The recipient of this Notification should send an
acknowledgment of the Notification and then release the associated
control information.
When to release a tunnel is an implementation issue and is not
specified in this document. A particular implementation may use
whatever policy is appropriate for determining when to release a
control connection. Some implementations may leave a tunnel open for
a period of time or perhaps indefinitely after the last session for
that tunnel is cleared. Others may choose to disconnect the tunnel
immediately after the last user connection on the tunnel disconnects.
8.0 L2TP Over Specific Media
L2TP is self-describing, operating at a level above the media over
which it is carried. However, some details of its connection to media
are required to permit interoperable implementations. The following
sections describe details needed to permit interoperability over
specific media.
8.1 L2TP over UDP/IP
L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP packet, including payload and L2TP header, is sent within a UDP datagram. The initiator of an L2TP tunnel picks an available source UDP port (which may or may not be 1701), and sends to the desired destination address at port 1701. The recipient picks a free port on its own system (which may or may not be 1701), and sends its reply to the initiator's UDP port and address, setting its own source port to the free port it found. Once the source and destination ports and addresses are established, they MUST remain static for the life of the tunnel. It has been suggested that having the recipient choose an arbitrary source port (as opposed to using the destination port in the packet initiating the tunnel, i.e., 1701) may make it more difficult for L2TP to traverse some NAT devices. Implementors should consider the potential implication of this before before choosing an arbitrary source port. IP fragmentation may occur as the L2TP packet travels over the IP substrate. L2TP makes no special efforts to optimize this. A LAC implementation MAY cause its LCP to negotiate for a specific MRU, which could optimize for LAC environments in which the MTU's of the path over which the L2TP packets are likely to travel have a consistent value. The default for any L2TP implementation is that UDP checksums MUST be enabled for both control and data messages. An L2TP implementation MAY provide an option to disable UDP checksums for data messages. It is recommended that UDP checksums always be enabled on control packets. Port 1701 is used for both L2F [RFC2341] and L2TP packets. The Version field in each header may be used to discriminate between the two packet types (L2F uses a value of 1, and the L2TP version described in this document uses a value of 2). An L2TP implementation running on a system which does not support L2F MUST silently discard all L2F packets. To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP link has the characteristic of being able to reorder or silently drop packets. The former may break non-IP protocols being carried by PPP, especially LAN-centric ones such as bridging. The latter may break protocols which assume per-packet indication of error, such as TCP header compression. Sequencing may be handled by using L2TP data message sequence numbers if any protocol being transported by the PPP
tunnel cannot tolerate reordering. The sequence dependency characteristics of individual protocols are outside the scope of this document. Allowing packets to be dropped silently is perhaps more problematic with some protocols. If PPP reliable delivery [RFC1663] is enabled, no upper PPP protocol will encounter lost packets. If L2TP sequence numbers are enabled, L2TP can detect the packet loss. In the case of an LNS, the PPP and L2TP stacks are both present within the LNS, and packet loss signaling may occur precisely as if a packet was received with a CRC error. Where the LAC and PPP stack are co-resident, this technique also applies. Where the LAC and PPP client are physically distinct, the analogous signaling MAY be accomplished by sending a packet with a CRC error to the PPP client. Note that this would greatly increase the complexity of debugging client line problems, since the client statistics could not distinguish between true media errors and LAC-initiated ones. Further, this technique is not possible on all hardware. If VJ compression is used, and neither PPP reliable delivery nor sequence numbers are enabled, each lost packet results in a 1 in 2**16 chance of a TCP segment being forwarded with incorrect contents [RFC1144]. Where the combination of the packet loss rate with this statistical exposure is unacceptable, TCP header compression SHOULD NOT be used. In general, it is wise to remember that the L2TP/UDP/IP transport is an unreliable transport. As with any PPP media that is subject to loss, care should be taken when using protocols that are particularly loss-sensitive. Such protocols include compression and encryption protocols that employ history.8.2 IP
When operating in IP environments, L2TP MUST offer the UDP encapsulation described in 8.1 as its default configuration for IP operation. Other configurations (perhaps corresponding to a compressed header format) MAY be defined and made available as a configurable option.
(page 69 continued on part 4)
