Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2661

Layer Two Tunneling Protocol "L2TP"

Pages: 80
Proposed Standard
Errata
Part 3 of 4 – Pages 41 to 69
First   Prev   Next

Top   ToC   RFC2661 - Page 41   prevText

5.0 Protocol Operation

The necessary setup for tunneling a PPP session with L2TP consists of two steps, (1) establishing the Control Connection for a Tunnel, and (2) establishing a Session as triggered by an incoming or outgoing call request. The Tunnel and corresponding Control Connection MUST be established before an incoming or outgoing call is initiated. An L2TP Session MUST be established before L2TP can begin to tunnel PPP frames. Multiple Sessions may exist across a single Tunnel and multiple Tunnels may exist between the same LAC and LNS. +-----+ +-----+ | |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| | | LAC | | LNS | | #######Control Connection######## | [Remote] | | | | [System]------Call----------*============L2TP Session=============* | PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | | | | | [Remote] | | | | [System]------Call----------*============L2TP Session=============* | PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | | | | | | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | +-----+ +-----+ Figure 5.1 Tunneling PPP

5.1 Control Connection Establishment

The Control Connection is the initial connection that must be achieved between an LAC and LNS before sessions may be brought up. Establishment of the control connection includes securing the identity of the peer, as well as identifying the peer's L2TP version, framing, and bearer capabilities, etc. A three message exchange is utilized to setup the control connection. Following is a typical message exchange: LAC or LNS LAC or LNS ---------- ---------- SCCRQ -> <- SCCRP SCCCN -> <- ZLB ACK The ZLB ACK is sent if there are no further messages waiting in queue for that peer.
Top   ToC   RFC2661 - Page 42

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.
Top   ToC   RFC2661 - Page 43

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.
Top   ToC   RFC2661 - Page 44

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
Top   ToC   RFC2661 - Page 45
   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.
Top   ToC   RFC2661 - Page 46

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.
Top   ToC   RFC2661 - Page 47
   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.
Top   ToC   RFC2661 - Page 48

6.0 Control Connection Protocol Specification

The following control connection messages are used to establish, clear and maintain L2TP tunnels. All data is sent in network order (high order octets first). Any "reserved" or "empty" fields MUST be sent as 0 values to allow for protocol extensibility.

6.1 Start-Control-Connection-Request (SCCRQ)

Start-Control-Connection-Request (SCCRQ) is a control message used to initialize a tunnel between an LNS and an LAC. It is sent by either the LAC or the LNS to being the tunnel establishment process. The following AVPs MUST be present in the SCCRQ: Message Type AVP Protocol Version Host Name Framing Capabilities Assigned Tunnel ID The Following AVPs MAY be present in the SCCRQ: Bearer Capabilities Receive Window Size Challenge Tie Breaker Firmware Revision Vendor Name

6.2 Start-Control-Connection-Reply (SCCRP)

Start-Control-Connection-Reply (SCCRP) is a control message sent in reply to a received SCCRQ message. SCCRP is used to indicate that the SCCRQ was accepted and establishment of the tunnel should continue. The following AVPs MUST be present in the SCCRP: Message Type Protocol Version Framing Capabilities Host Name Assigned Tunnel ID
Top   ToC   RFC2661 - Page 49
   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.
Top   ToC   RFC2661 - Page 50
   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.
Top   ToC   RFC2661 - Page 51
   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
Top   ToC   RFC2661 - Page 52
   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
Top   ToC   RFC2661 - Page 53

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
Top   ToC   RFC2661 - Page 54
   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
Top   ToC   RFC2661 - Page 55
   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).
Top   ToC   RFC2661 - Page 56
   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
Top   ToC   RFC2661 - Page 57
   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
Top   ToC   RFC2661 - Page 58
      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
Top   ToC   RFC2661 - Page 59
   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.
Top   ToC   RFC2661 - Page 60

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
Top   ToC   RFC2661 - Page 61
   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.
Top   ToC   RFC2661 - Page 62

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
Top   ToC   RFC2661 - Page 63
      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:
Top   ToC   RFC2661 - Page 64

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
Top   ToC   RFC2661 - Page 65
      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.
Top   ToC   RFC2661 - Page 66

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.
Top   ToC   RFC2661 - Page 67
   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.
Top   ToC   RFC2661 - Page 68

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
Top   ToC   RFC2661 - Page 69
   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)

Next Section