tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3931

 Errata 
Proposed STD
Pages: 94
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: L2TPEXT

Layer Two Tunneling Protocol - Version 3 (L2TPv3)

Part 1 of 5, p. 1 to 16
None       Next RFC Part

Updated by:    5641


Top       ToC       Page 1 
Network Working Group                                        J. Lau, Ed.
Request for Comments: 3931                              M. Townsley, Ed.
Category: Standards Track                                  Cisco Systems
                                                          I. Goyret, Ed.
                                                     Lucent Technologies
                                                              March 2005


           Layer Two Tunneling Protocol - Version 3 (L2TPv3)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes "version 3" of the Layer Two Tunneling
   Protocol (L2TPv3).  L2TPv3 defines the base control protocol and
   encapsulation for tunneling multiple Layer 2 connections between two
   IP nodes.  Additional documents detail the specifics for each data
   link type being emulated.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  Changes from RFC 2661. . . . . . . . . . . . . . . . . .  4
       1.2.  Specification of Requirements. . . . . . . . . . . . . .  4
       1.3.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Topology . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.  Protocol Overview. . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.  Control Message Types. . . . . . . . . . . . . . . . . . 10
       3.2.  L2TP Header Formats. . . . . . . . . . . . . . . . . . . 11
             3.2.1.  L2TP Control Message Header. . . . . . . . . . . 11
             3.2.2.  L2TP Data Message. . . . . . . . . . . . . . . . 12
       3.3.  Control Connection Management. . . . . . . . . . . . . . 13
             3.3.1.  Control Connection Establishment . . . . . . . . 14
             3.3.2.  Control Connection Teardown. . . . . . . . . . . 14
       3.4.  Session Management . . . . . . . . . . . . . . . . . . . 15
             3.4.1.  Session Establishment for an Incoming Call . . . 15
             3.4.2.  Session Establishment for an Outgoing Call . . . 15

Top      ToC       Page 2 
             3.4.3.  Session Teardown . . . . . . . . . . . . . . . . 16
   4.  Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16
       4.1.  L2TP Over Specific Packet-Switched Networks (PSNs) . . . 16
             4.1.1.  L2TPv3 over IP . . . . . . . . . . . . . . . . . 17
             4.1.2.  L2TP over UDP. . . . . . . . . . . . . . . . . . 18
             4.1.3.  L2TP and IPsec . . . . . . . . . . . . . . . . . 20
             4.1.4.  IP Fragmentation Issues. . . . . . . . . . . . . 21
       4.2.  Reliable Delivery of Control Messages. . . . . . . . . . 23
       4.3.  Control Message Authentication . . . . . . . . . . . . . 25
       4.4.  Keepalive (Hello). . . . . . . . . . . . . . . . . . . . 26
       4.5.  Forwarding Session Data Frames . . . . . . . . . . . . . 26
       4.6.  Default L2-Specific Sublayer . . . . . . . . . . . . . . 27
             4.6.1.  Sequencing Data Packets. . . . . . . . . . . . . 28
       4.7.  L2TPv2/v3 Interoperability and Migration . . . . . . . . 28
             4.7.1.  L2TPv3 over IP . . . . . . . . . . . . . . . . . 29
             4.7.2.  L2TPv3 over UDP. . . . . . . . . . . . . . . . . 29
             4.7.3.  Automatic L2TPv2 Fallback. . . . . . . . . . . . 29
   5.  Control Message Attribute Value Pairs. . . . . . . . . . . . . 30
       5.1.  AVP Format . . . . . . . . . . . . . . . . . . . . . . . 30
       5.2.  Mandatory AVPs and Setting the M Bit . . . . . . . . . . 32
       5.3.  Hiding of AVP Attribute Values . . . . . . . . . . . . . 33
       5.4.  AVP Summary. . . . . . . . . . . . . . . . . . . . . . . 36
             5.4.1.  General Control Message AVPs . . . . . . . . . . 36
             5.4.2.  Result and Error Codes . . . . . . . . . . . . . 40
             5.4.3.  Control Connection Management AVPs . . . . . . . 43
             5.4.4.  Session Management AVPs. . . . . . . . . . . . . 48
             5.4.5.  Circuit Status AVPs. . . . . . . . . . . . . . . 57
   6.  Control Connection Protocol Specification. . . . . . . . . . . 59
       6.1.  Start-Control-Connection-Request (SCCRQ) . . . . . . . . 60
       6.2.  Start-Control-Connection-Reply (SCCRP) . . . . . . . . . 60
       6.3.  Start-Control-Connection-Connected (SCCCN) . . . . . . . 61
       6.4.  Stop-Control-Connection-Notification (StopCCN) . . . . . 61
       6.5.  Hello (HELLO). . . . . . . . . . . . . . . . . . . . . . 61
       6.6.  Incoming-Call-Request (ICRQ) . . . . . . . . . . . . . . 62
       6.7.  Incoming-Call-Reply (ICRP) . . . . . . . . . . . . . . . 63
       6.8.  Incoming-Call-Connected (ICCN) . . . . . . . . . . . . . 63
       6.9.  Outgoing-Call-Request (OCRQ) . . . . . . . . . . . . . . 64
       6.10. Outgoing-Call-Reply (OCRP) . . . . . . . . . . . . . . . 65
       6.11. Outgoing-Call-Connected (OCCN) . . . . . . . . . . . . . 65
       6.12. Call-Disconnect-Notify (CDN) . . . . . . . . . . . . . . 66
       6.13. WAN-Error-Notify (WEN) . . . . . . . . . . . . . . . . . 66
       6.14. Set-Link-Info (SLI). . . . . . . . . . . . . . . . . . . 67
       6.15. Explicit-Acknowledgement (ACK) . . . . . . . . . . . . . 67
   7.  Control Connection State Machines. . . . . . . . . . . . . . . 68
       7.1.  Malformed AVPs and Control Messages. . . . . . . . . . . 68
       7.2.  Control Connection States. . . . . . . . . . . . . . . . 69
       7.3.  Incoming Calls . . . . . . . . . . . . . . . . . . . . . 71
             7.3.1.  ICRQ Sender States . . . . . . . . . . . . . . . 72

Top      ToC       Page 3 
             7.3.2.  ICRQ Recipient States. . . . . . . . . . . . . . 73
       7.4.  Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 74
             7.4.1.  OCRQ Sender States . . . . . . . . . . . . . . . 75
             7.4.2.  OCRQ Recipient (LAC) States. . . . . . . . . . . 76
       7.5.  Termination of a Control Connection. . . . . . . . . . . 77
   8.  Security Considerations. . . . . . . . . . . . . . . . . . . . 78
       8.1.  Control Connection Endpoint and Message Security . . . . 78
       8.2.  Data Packet Spoofing . . . . . . . . . . . . . . . . . . 78
   9.  Internationalization Considerations. . . . . . . . . . . . . . 79
   10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 80
       10.1. Control Message Attribute Value Pairs (AVPs) . . . . . . 80
       10.2. Message Type AVP Values. . . . . . . . . . . . . . . . . 81
       10.3. Result Code AVP Values . . . . . . . . . . . . . . . . . 81
       10.4. AVP Header Bits. . . . . . . . . . . . . . . . . . . . . 82
       10.5. L2TP Control Message Header Bits . . . . . . . . . . . . 82
       10.6. Pseudowire Types . . . . . . . . . . . . . . . . . . . . 83
       10.7. Circuit Status Bits. . . . . . . . . . . . . . . . . . . 83
       10.8. Default L2-Specific Sublayer bits. . . . . . . . . . . . 84
       10.9. L2-Specific Sublayer Type. . . . . . . . . . . . . . . . 84
       10.10 Data Sequencing Level. . . . . . . . . . . . . . . . . . 84
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
       11.1. Normative References . . . . . . . . . . . . . . . . . . 85
       11.2. Informative References . . . . . . . . . . . . . . . . . 85
   12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 87
   Appendix A: Control Slow Start and Congestion Avoidance. . . . . . 89
   Appendix B: Control Message Examples . . . . . . . . . . . . . . . 90
   Appendix C: Processing Sequence Numbers. . . . . . . . . . . . . . 91
   Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 94

1.  Introduction

   The Layer Two Tunneling Protocol (L2TP) provides a dynamic mechanism
   for tunneling Layer 2 (L2) "circuits" across a packet-oriented data
   network (e.g., over IP).  L2TP, as originally defined in RFC 2661, is
   a standard method for tunneling Point-to-Point Protocol (PPP)
   [RFC1661] sessions.  L2TP has since been adopted for tunneling a
   number of other L2 protocols.  In order to provide greater
   modularity, this document describes the base L2TP protocol,
   independent of the L2 payload that is being tunneled.

   The base L2TP protocol defined in this document consists of (1) the
   control protocol for dynamic creation, maintenance, and teardown of
   L2TP sessions, and (2) the L2TP data encapsulation to multiplex and
   demultiplex L2 data streams between two L2TP nodes across an IP
   network.  Additional documents are expected to be published for each
   L2 data link emulation type (a.k.a. pseudowire-type) supported by
   L2TP (i.e., PPP, Ethernet, Frame Relay, etc.).  These documents will

Top      ToC       Page 4 
   contain any pseudowire-type specific details that are outside the
   scope of this base specification.

   When the designation between L2TPv2 and L2TPv3 is necessary, L2TP as
   defined in RFC 2661 will be referred to as "L2TPv2", corresponding to
   the value in the Version field of an L2TP header.  (Layer 2
   Forwarding, L2F, [RFC2341] was defined as "version 1".)  At times,
   L2TP as defined in this document will be referred to as "L2TPv3".
   Otherwise, the acronym "L2TP" will refer to L2TPv3 or L2TP in
   general.

1.1.  Changes from RFC 2661

   Many of the protocol constructs described in this document are
   carried over from RFC 2661.  Changes include clarifications based on
   years of interoperability and deployment experience as well as
   modifications to either improve protocol operation or provide a
   clearer separation from PPP.  The intent of these modifications is to
   achieve a healthy balance between code reuse, interoperability
   experience, and a directed evolution of L2TP as it is applied to new
   tasks.

   Notable differences between L2TPv2 and L2TPv3 include the following:

      Separation of all PPP-related AVPs, references, etc., including a
      portion of the L2TP data header that was specific to the needs of
      PPP.  The PPP-specific constructs are described in a companion
      document.

      Transition from a 16-bit Session ID and Tunnel ID to a 32-bit
      Session ID and Control Connection ID, respectively.

      Extension of the Tunnel Authentication mechanism to cover the
      entire control message rather than just a portion of certain
      messages.

   Details of these changes and a recommendation for transitioning to
   L2TPv3 are discussed in Section 4.7.

1.2.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Top      ToC       Page 5 
1.3.  Terminology

   Attribute Value Pair (AVP)

      The variable-length concatenation of a unique Attribute
      (represented by an integer), a length field, and a Value
      containing the actual value identified by the attribute.  Zero or
      more AVPs make up the body of control messages, which are used in
      the establishment, maintenance, and teardown of control
      connections.  This basic construct is sometimes referred to as a
      Type-Length-Value (TLV) in some specifications.  (See also:
      Control Connection, Control Message.)

   Call (Circuit Up)

      The action of transitioning a circuit on an L2TP Access
      Concentrator (LAC) to an "up" or "active" state.  A call may be
      dynamically established through signaling properties (e.g., an
      incoming or outgoing call through the Public Switched Telephone
      Network (PSTN)) or statically configured (e.g., provisioning a
      Virtual Circuit on an interface).  A call is defined by its
      properties (e.g., type of call, called number, etc.) and its data
      traffic.  (See also: Circuit, Session, Incoming Call, Outgoing
      Call, Outgoing Call Request.)

   Circuit

      A general term identifying any one of a wide range of L2
      connections.  A circuit may be virtual in nature (e.g., an ATM
      PVC, an IEEE 802 VLAN, or an L2TP session), or it may have direct
      correlation to a physical layer (e.g., an RS-232 serial line).
      Circuits may be statically configured with a relatively long-lived
      uptime, or dynamically established with signaling to govern the
      establishment, maintenance, and teardown of the circuit.  For the
      purposes of this document, a statically configured circuit is
      considered to be essentially the same as a very simple, long-
      lived, dynamic circuit.  (See also: Call, Remote System.)

   Client

      (See Remote System.)

   Control Connection

      An L2TP control connection is a reliable control channel that is
      used to establish, maintain, and release individual L2TP sessions
      as well as the control connection itself.  (See also: Control
      Message, Data Channel.)

Top      ToC       Page 6 
   Control Message

      An L2TP message used by the control connection.  (See also:
      Control Connection.)

   Data Message

      Message used by the data channel.  (a.k.a. Data Packet, See also:
      Data Channel.)

   Data Channel

      The channel for L2TP-encapsulated data traffic that passes between
      two LCCEs over a Packet-Switched Network (i.e., IP).  (See also:
      Control Connection, Data Message.)

   Incoming Call

      The action of receiving a call (circuit up event) on an LAC.  The
      call may have been placed by a remote system (e.g., a phone call
      over a PSTN), or it may have been triggered by a local event
      (e.g., interesting traffic routed to a virtual interface).  An
      incoming call that needs to be tunneled (as determined by the LAC)
      results in the generation of an L2TP ICRQ message.  (See also:
      Call, Outgoing Call, Outgoing Call Request.)

   L2TP Access Concentrator (LAC)

      If an L2TP Control Connection Endpoint (LCCE) is being used to
      cross-connect an L2TP session directly to a data link, we refer to
      it as an L2TP Access Concentrator (LAC).  An LCCE may act as both
      an L2TP Network Server (LNS) for some sessions and an LAC for
      others, so these terms must only be used within the context of a
      given set of sessions unless the LCCE is in fact single purpose
      for a given topology.  (See also: LCCE, LNS.)

   L2TP Control Connection Endpoint (LCCE)

      An L2TP node that exists at either end of an L2TP control
      connection.  May also be referred to as an LAC or LNS, depending
      on whether tunneled frames are processed at the data link (LAC) or
      network layer (LNS).  (See also: LAC, LNS.)

   L2TP Network Server (LNS)

      If a given L2TP session is terminated at the L2TP node and the
      encapsulated network layer (L3) packet processed on a virtual
      interface, we refer to this L2TP node as an L2TP Network Server

Top      ToC       Page 7 
      (LNS).  A given LCCE may act as both an LNS for some sessions and
      an LAC for others, so these terms must only be used within the
      context of a given set of sessions unless the LCCE is in fact
      single purpose for a given topology.  (See also: LCCE, LAC.)

   Outgoing Call

      The action of placing a call by an LAC, typically in response to
      policy directed by the peer in an Outgoing Call Request.  (See
      also: Call, Incoming Call, Outgoing Call Request.)

   Outgoing Call Request

      A request sent to an LAC to place an outgoing call.  The request
      contains specific information not known a priori by the LAC (e.g.,
      a number to dial).  (See also: Call, Incoming Call, Outgoing
      Call.)

   Packet-Switched Network (PSN)

      A network that uses packet switching technology for data delivery.
      For L2TPv3, this layer is principally IP.  Other examples include
      MPLS, Frame Relay, and ATM.

   Peer

      When used in context with L2TP, Peer refers to the far end of an
      L2TP control connection (i.e., the remote LCCE).  An LAC's peer
      may be either an LNS or another LAC.  Similarly, an LNS's peer may
      be either an LAC or another LNS.  (See also: LAC, LCCE, LNS.)

   Pseudowire (PW)

      An emulated circuit as it traverses a PSN.  There is one
      Pseudowire per L2TP Session.  (See also: Packet-Switched Network,
      Session.)

   Pseudowire Type

      The payload type being carried within an L2TP session.  Examples
      include PPP, Ethernet, and Frame Relay.  (See also: Session.)

   Remote System

      An end system or router connected by a circuit to an LAC.

Top      ToC       Page 8 
   Session

      An L2TP session is the entity that is created between two LCCEs in
      order to exchange parameters for and maintain an emulated L2
      connection.  Multiple sessions may be associated with a single
      Control Connection.

   Zero-Length Body (ZLB) Message

      A control message with only an L2TP header.  ZLB messages are used
      only to acknowledge messages on the L2TP reliable control
      connection.  (See also: Control Message.)

2.  Topology

   L2TP operates between two L2TP Control Connection Endpoints (LCCEs),
   tunneling traffic across a packet network.  There are three
   predominant tunneling models in which L2TP operates: LAC-LNS (or vice
   versa), LAC-LAC, and LNS-LNS.  These models are diagrammed below.
   (Dotted lines designate network connections.  Solid lines designate
   circuit connections.)

                     Figure 2.0: L2TP Reference Models

   (a) LAC-LNS Reference Model: On one side, the LAC receives traffic
   from an L2 circuit, which it forwards via L2TP across an IP or other
   packet-based network.  On the other side, an LNS logically terminates
   the L2 circuit locally and routes network traffic to the home
   network.  The action of session establishment is driven by the LAC
   (as an incoming call) or the LNS (as an outgoing call).

    +-----+  L2  +-----+                        +-----+
    |     |------| LAC |.........[ IP ].........| LNS |...[home network]
    +-----+      +-----+                        +-----+
    remote
    system
                       |<-- emulated service -->|
          |<----------- L2 service ------------>|

   (b) LAC-LAC Reference Model: In this model, both LCCEs are LACs.
   Each LAC forwards circuit traffic from the remote system to the peer
   LAC using L2TP, and vice versa.  In its simplest form, an LAC acts as
   a simple cross-connect between a circuit to a remote system and an
   L2TP session.  This model typically involves symmetric establishment;
   that is, either side of the connection may initiate a session at any
   time (or simultaneously, in which a tie breaking mechanism is
   utilized).

Top      ToC       Page 9 
   +-----+  L2  +-----+                      +-----+  L2  +-----+
   |     |------| LAC |........[ IP ]........| LAC |------|     |
   +-----+      +-----+                      +-----+      +-----+
   remote                                                 remote
   system                                                 system
                      |<- emulated service ->|
         |<----------------- L2 service ----------------->|

   (c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs.  A
   user-level, traffic-generated, or signaled event typically drives
   session establishment from one side of the tunnel.  For example, a
   tunnel generated from a PC by a user, or automatically by customer
   premises equipment.

                   +-----+                      +-----+
  [home network]...| LNS |........[ IP ]........| LNS |...[home network]
                   +-----+                      +-----+
                         |<- emulated service ->|
                         |<---- L2 service ---->|

   Note: In L2TPv2, user-driven tunneling of this type is often referred
   to as "voluntary tunneling" [RFC2809].  Further, an LNS acting as
   part of a software package on a host is sometimes referred to as an
   "LAC Client" [RFC2661].

3.  Protocol Overview

   L2TP is comprised of two types of messages, control messages and data
   messages (sometimes referred to as "control packets" and "data
   packets", respectively).  Control messages are used in the
   establishment, maintenance, and clearing of control connections and
   sessions.  These messages utilize a reliable control channel within
   L2TP to guarantee delivery (see Section 4.2 for details).  Data
   messages are used to encapsulate the L2 traffic being carried over
   the L2TP session.  Unlike control messages, data messages are not
   retransmitted when packet loss occurs.

   The L2TPv3 control message format defined in this document borrows
   largely from L2TPv2.  These control messages are used in conjunction
   with the associated protocol state machines that govern the dynamic
   setup, maintenance, and teardown for L2TP sessions.  The data message
   format for tunneling data packets may be utilized with or without the
   L2TP control channel, either via manual configuration or via other
   signaling methods to pre-configure or distribute L2TP session
   information.  Utilization of the L2TP data message format with other
   signaling methods is outside the scope of this document.

Top      ToC       Page 10 
                       Figure 3.0: L2TPv3 Structure

             +-------------------+    +-----------------------+
             | Tunneled Frame    |    | L2TP Control Message  |
             +-------------------+    +-----------------------+
             | L2TP Data Header  |    | L2TP Control Header   |
             +-------------------+    +-----------------------+
             | L2TP Data Channel |    | L2TP Control Channel  |
             | (unreliable)      |    | (reliable)            |
             +-------------------+----+-----------------------+
             | Packet-Switched Network (IP, FR, MPLS, etc.)   |
             +------------------------------------------------+

   Figure 3.0 depicts the relationship of control messages and data
   messages over the L2TP control and data channels, respectively.  Data
   messages are passed over an unreliable data channel, encapsulated by
   an L2TP header, and sent over a Packet-Switched Network (PSN) such as
   IP, UDP, Frame Relay, ATM, MPLS, etc.  Control messages are sent over
   a reliable L2TP control channel, which operates over the same PSN.

   The necessary setup for tunneling a session with L2TP consists of two
   steps: (1) Establishing the control connection, and (2) establishing
   a session as triggered by an incoming call or outgoing call.  An L2TP
   session MUST be established before L2TP can begin to forward session
   frames.  Multiple sessions may be bound to a single control
   connection, and multiple control connections may exist between the
   same two LCCEs.

3.1.  Control Message Types

   The Message Type AVP (see Section 5.4.1) defines the specific type of
   control message being sent.

   This document defines the following control message types (see
   Sections 6.1 through 6.15 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
      20  (ACK)      Explicit Acknowledgement

Top      ToC       Page 11 
   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

   Link Status Change Reporting

      16  (SLI)      Set-Link-Info

3.2.  L2TP Header Formats

   This section defines header formats for L2TP control messages and
   L2TP data messages.  All values are placed into their respective
   fields and sent in network order (high-order octets first).

3.2.1.  L2TP Control Message Header

   The L2TP control message header provides information for the reliable
   transport of messages that govern the establishment, maintenance, and
   teardown of L2TP sessions.  By default, control messages are sent
   over the underlying media in-band with L2TP data messages.

   The L2TP control message header is formatted as follows:

                 Figure 3.2.1: L2TP Control Message Header

    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|x|x|x|x|x|x|  Ver  |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Control Connection ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Ns              |               Nr              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The T bit MUST be set to 1, indicating that this is a control
   message.

Top      ToC       Page 12 
   The L and S bits MUST be set to 1, indicating that the Length field
   and sequence numbers are present.

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

   The Ver field indicates the version of the L2TP control message
   header described in this document.  On sending, this field MUST be
   set to 3 for all messages (unless operating in an environment that
   includes L2TPv2 [RFC2661] and/or L2F [RFC2341] as well, see Section
   4.1 for details).

   The Length field indicates the total length of the message in octets,
   always calculated from the start of the control message header itself
   (beginning with the T bit).

   The Control Connection ID field contains the identifier for the
   control connection.  L2TP control connections are named by
   identifiers that have local significance only.  That is, the same
   control connection will be given unique Control Connection IDs by
   each LCCE from within each endpoint's own Control Connection ID
   number space.  As such, the Control Connection ID in each message is
   that of the intended recipient, not the sender.  Non-zero Control
   Connection IDs are selected and exchanged as Assigned Control
   Connection ID AVPs during the creation of a control connection.

   Ns indicates the sequence number for this control message, beginning
   at zero and incrementing by one (modulo 2**16) for each message sent.
   See Section 4.2 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).  See Section 4.2 for more
   information on using this field.

3.2.2.  L2TP Data Message

   In general, an L2TP data message consists of a (1) Session Header,
   (2) an optional L2-Specific Sublayer, and (3) the Tunnel Payload, as
   depicted below.

Top      ToC       Page 13 
                  Figure 3.2.2: L2TP Data Message Header

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      L2TP Session Header                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      L2-Specific Sublayer                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Tunnel Payload                      ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The L2TP Session Header is specific to the encapsulating PSN over
   which the L2TP traffic is delivered.  The Session Header MUST provide
   (1) a method of distinguishing traffic among multiple L2TP data
   sessions and (2) a method of distinguishing data messages from
   control messages.

   Each type of encapsulating PSN MUST define its own session header,
   clearly identifying the format of the header and parameters necessary
   to setup the session.  Section 4.1 defines two session headers, one
   for transport over UDP and one for transport over IP.

   The L2-Specific Sublayer is an intermediary layer between the L2TP
   session header and the start of the tunneled frame.  It contains
   control fields that are used to facilitate the tunneling of each
   frame (e.g., sequence numbers or flags).  The Default L2-Specific
   Sublayer for L2TPv3 is defined in Section 4.6.

   The Data Message Header is followed by the Tunnel Payload, including
   any necessary L2 framing as defined in the payload-specific companion
   documents.

3.3.  Control Connection Management

   The L2TP control connection handles dynamic establishment, teardown,
   and maintenance of the L2TP sessions and of the control connection
   itself.  The reliable delivery of control messages is described in
   Section 4.2.

   This section describes typical control connection establishment and
   teardown exchanges.  It is important to note that, in the diagrams
   that follow, the reliable control message delivery mechanism exists
   independently of the L2TP state machine.  For instance, Explicit
   Acknowledgement (ACK) messages may be sent after any of the control
   messages indicated in the exchanges below if an acknowledgment is not
   piggybacked on a later control message.

Top      ToC       Page 14 
   LCCEs are identified during control connection establishment either
   by the Host Name AVP, the Router ID AVP, or a combination of the two
   (see Section 5.4.3).  The identity of a peer LCCE is central to
   selecting proper configuration parameters (i.e., Hello interval,
   window size, etc.) for a control connection, as well as for
   determining how to set up associated sessions within the control
   connection, password lookup for control connection authentication,
   control connection level tie breaking, etc.

3.3.1.  Control Connection Establishment

   Establishment of the control connection involves an exchange of AVPs
   that identifies the peer and its capabilities.

   A three-message exchange is used to establish the control connection.
   The following is a typical message exchange:

      LCCE A      LCCE B
      ------      ------
      SCCRQ ->
                  <- SCCRP
      SCCCN ->

3.3.2.  Control Connection Teardown

   Control connection teardown may be initiated by either LCCE and is
   accomplished by sending a single StopCCN control message.  As part of
   the reliable control message delivery mechanism, the recipient of a
   StopCCN MUST send an ACK message 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 ACK message is lost).  The recommended time for a
   full retransmission cycle is at least 31 seconds (see Section 4.2).
   The following is an example of a typical control message exchange:

      LCCE A      LCCE B
      ------      ------
      StopCCN ->
      (Clean up)

                  (Wait)
                  (Clean up)

   An implementation may shut down an entire control connection and all
   sessions associated with the control connection by sending the
   StopCCN.  Thus, it is not necessary to clear each session
   individually when tearing down the whole control connection.

Top      ToC       Page 15 
3.4.  Session Management

   After successful control connection establishment, individual
   sessions may be created.  Each session corresponds to a single data
   stream between the two LCCEs.  This section describes the typical
   call establishment and teardown exchanges.

3.4.1.  Session Establishment for an Incoming Call

   A three-message exchange is used to establish the session.  The
   following is a typical sequence of events:

      LCCE A      LCCE B
      ------      ------
      (Call
       Detected)

      ICRQ ->
                 <- ICRP
      (Call
       Accepted)

      ICCN ->

3.4.2.  Session Establishment for an Outgoing Call

   A three-message exchange is used to set up the session.  The
   following is a typical sequence of events:

      LCCE A      LCCE B
      ------      ------
                 <- OCRQ
      OCRP ->

      (Perform
       Call
       Operation)

      OCCN ->

      (Call Operation
       Completed
       Successfully)

Top      ToC       Page 16 
3.4.3.  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).  The following is an example of a typical control
   message exchange:

      LCCE A      LCCE B
      ------      ------
      CDN ->
      (Clean up)

                  (Clean up)



(page 16 continued on part 2)

Next RFC Part