rfc2661.txt

第二层隧道模块l2tp源码,开发环境为linux

   POTS

      Plain Old Telephone Service.






Townsley, et al.            Standards Track                     [Page 6]

RFC 2661                          L2TP                       August 1999


   Remote System

      An end-system or router attached to a remote access network (i.e.
      a PSTN), which is either the initiator or recipient of a call.
      Also referred to as a dial-up or virtual dial-up client.

   Session

      L2TP is connection-oriented. The LNS and LAC maintain state for
      each Call that is initiated or answered by an LAC. An L2TP Session
      is created between the LAC and LNS when an end-to-end PPP
      connection is established between a Remote System and the LNS.
      Datagrams related to the PPP connection are sent over the Tunnel
      between the LAC and LNS. There is a one to one relationship
      between established L2TP Sessions and their associated Calls. (See
      also: Call).

   Tunnel

      A Tunnel exists between a LAC-LNS pair. The Tunnel consists of a
      Control Connection and zero or more L2TP Sessions. The Tunnel
      carries encapsulated PPP datagrams and Control Messages between
      the LAC and the LNS.

   Zero-Length Body (ZLB) Message

      A control packet with only an L2TP header. ZLB messages are used
      for explicitly acknowledging packets on the reliable control
      channel.






















Townsley, et al.            Standards Track                     [Page 7]

RFC 2661                          L2TP                       August 1999


2.0 Topology

   The following diagram depicts a typical L2TP scenario. The goal is to
   tunnel PPP frames between the Remote System or LAC Client and an LNS
   located at a Home LAN.

                                                    [Home LAN]
            [LAC Client]----------+                     |
                              ____|_____                +--[Host]
                             |          |               |
               [LAC]---------| Internet |-----[LNS]-----+
                 |           |__________|               |
            _____|_____                                 :
           |           |
           |  PSTN     |
 [Remote]--|  Cloud    |
 [System]  |           |                            [Home LAN]
           |___________|                                |
                 |          ______________              +---[Host]
                 |         |              |             |
               [LAC]-------| Frame Relay  |---[LNS]-----+
                           | or ATM Cloud |             |
                           |______________|             :

   The Remote System initiates a PPP connection across the PSTN Cloud to
   an LAC. The LAC then tunnels the PPP connection across the Internet,
   Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN is
   obtained. The Remote System is provided addresses from the HOME LAN

   via PPP NCP negotiation. Authentication, Authorization and Accounting
   may be provided by the Home LAN's Management Domain as if the user
   were connected to a Network Access Server directly.

   A LAC Client (a Host which runs L2TP natively) may also participate
   in tunneling to the Home LAN without use of a separate LAC. In this
   case, the Host containing the LAC Client software already has a
   connection to the public Internet. A "virtual" PPP connection is then
   created and the local L2TP LAC Client software creates a tunnel to
   the LNS. As in the above case, Addressing, Authentication,
   Authorization and Accounting will be provided by the Home LAN's
   Management Domain.










Townsley, et al.            Standards Track                     [Page 8]

RFC 2661                          L2TP                       August 1999


3.0 Protocol Overview

   L2TP utilizes two types of messages, control messages and data
   messages. Control messages are used in the establishment, maintenance
   and clearing of tunnels and calls. Data messages are used to
   encapsulate PPP frames being carried over the tunnel. Control
   messages utilize a reliable Control Channel within L2TP to guarantee
   delivery (see section 5.1 for details). Data messages are not
   retransmitted when packet loss occurs.

   +-------------------+
   | PPP Frames        |
   +-------------------+    +-----------------------+
   | L2TP Data Messages|    | L2TP Control Messages |
   +-------------------+    +-----------------------+
   | L2TP Data Channel |    | L2TP Control Channel  |
   | (unreliable)      |    | (reliable)            |
   +------------------------------------------------+
   |      Packet Transport (UDP, FR, ATM, etc.)     |
   +------------------------------------------------+

   Figure 3.0 L2TP Protocol Structure

   Figure 3.0 depicts the relationship of PPP frames and Control
   Messages over the L2TP Control and Data Channels. PPP Frames are
   passed over an unreliable Data Channel encapsulated first by an L2TP
   header and then a Packet Transport such as UDP, Frame Relay, ATM,
   etc. Control messages are sent over a reliable L2TP Control Channel
   which transmits packets in-band over the same Packet Transport.

   Sequence numbers are required to be present in all control messages
   and are used to provide reliable delivery on the Control Channel.
   Data Messages may use sequence numbers to reorder packets and detect
   lost packets.

   All values are placed into their respective fields and sent in
   network order (high order octets first).

3.1 L2TP Header Format

   L2TP packets for the control channel and data channel share a common
   header format. In each case where a field is optional, its space does
   not exist in the message if the field is marked not present. Note
   that while optional on data messages, the Length, Ns, and Nr fields
   marked as optional below, are required to be present on all control
   messages.





Townsley, et al.            Standards Track                     [Page 9]

RFC 2661                          L2TP                       August 1999


   This header is formatted:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T|L|x|x|S|x|O|P|x|x|x|x|  Ver  |          Length (opt)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tunnel ID           |           Session ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Ns (opt)          |             Nr (opt)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Offset Size (opt)        |    Offset pad... (opt)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3.1 L2TP Message Header

   The Type (T) bit indicates the type of message. It is set to 0 for a
   data message and 1 for a control message.

   If the Length (L) bit is 1, the Length field is present. This bit
   MUST be set to 1 for control messages.

   The x bits are reserved for future extensions. All reserved bits MUST
   be set to 0 on outgoing messages and ignored on incoming messages.

   If the Sequence (S) bit is set to 1 the Ns and Nr fields are present.
   The S bit MUST be set to 1 for control messages.

   If the Offset (O) bit is 1, the Offset Size field is present. The O
   bit MUST be set to 0 (zero) for control messages.

   If the Priority (P) bit is 1, this data message should receive
   preferential treatment in its local queuing and transmission.  LCP
   echo requests used as a keepalive for the link, for instance, should
   generally be sent with this bit set to 1. Without it, a temporary
   interval of local congestion could result in interference with
   keepalive messages and unnecessary loss of the link. This feature is
   only for use with data messages. The P bit MUST be set to 0 for all
   control messages.

   Ver MUST be 2, indicating the version of the L2TP data message header
   described in this document. The value 1 is reserved to permit
   detection of L2F [RFC2341] packets should they arrive intermixed with
   L2TP packets. Packets received with an unknown Ver field MUST be
   discarded.

   The Length field indicates the total length of the message in octets.




Townsley, et al.            Standards Track                    [Page 10]

RFC 2661                          L2TP                       August 1999


   Tunnel ID indicates the identifier for the control connection. L2TP
   tunnels are named by identifiers that have local significance only.
   That is, the same tunnel will be given different Tunnel IDs by each
   end of the tunnel. Tunnel ID in each message is that of the intended
   recipient, not the sender. Tunnel IDs are selected and exchanged as
   Assigned Tunnel ID AVPs during the creation of a tunnel.

   Session ID indicates the identifier for a session within a tunnel.
   L2TP sessions are named by identifiers that have local significance
   only. That is, the same session will be given different Session IDs
   by each end of the session. Session ID in each message is that of the
   intended recipient, not the sender. Session IDs are selected and
   exchanged as Assigned Session ID AVPs during the creation of a
   session.

   Ns indicates the sequence number for this data or control message,
   beginning at zero and incrementing by one (modulo 2**16) for each
   message sent. See Section 5.8 and 5.4 for more information on using
   this field.

   Nr indicates the sequence number expected in the next control message
   to be received.  Thus, Nr is set to the Ns of the last in-order
   message received plus one (modulo 2**16). In data messages, Nr is
   reserved and, if present (as indicated by the S-bit), MUST be ignored
   upon receipt. See section 5.8 for more information on using this
   field in control messages.

   The Offset Size field, if present, specifies the number of octets
   past the L2TP header at which the payload data is expected to start.
   Actual data within the offset padding is undefined. If the offset
   field is present, the L2TP header ends after the last octet of the
   offset padding.

3.2 Control Message Types

   The Message Type AVP (see section 4.4.1) defines the specific type of
   control message being sent. Recall from section 3.1 that this is only
   for control messages, that is, messages with the T-bit set to 1.













Townsley, et al.            Standards Track                    [Page 11]

RFC 2661                          L2TP                       August 1999


   This document defines the following control message types (see
   Section 6.1 through 6.14 for details on the construction and use of
   each message):

   Control Connection Management

      0  (reserved)

      1  (SCCRQ)    Start-Control-Connection-Request
      2  (SCCRP)    Start-Control-Connection-Reply
      3  (SCCCN)    Start-Control-Connection-Connected
      4  (StopCCN)  Stop-Control-Connection-Notification
      5  (reserved)
      6  (HELLO)    Hello

   Call Management

      7  (OCRQ)     Outgoing-Call-Request
      8  (OCRP)     Outgoing-Call-Reply
      9  (OCCN)     Outgoing-Call-Connected
      10 (ICRQ)     Incoming-Call-Request
      11 (ICRP)     Incoming-Call-Reply
      12 (ICCN)     Incoming-Call-Connected
      13 (reserved)
      14 (CDN)      Call-Disconnect-Notify

   Error Reporting

      15 (WEN)      WAN-Error-Notify

   PPP Session Control

      16 (SLI)      Set-Link-Info