[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

INTERNET DRAFT                                            W. M. Townsley
draft-townsley-pwe3-l2tpv3-01.txt                          cisco Systems
Category: Informational                                        June 2003
Expires: December 2003


                         Pseudowires and L2TPv3
Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
              http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
              http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document provides an overview of the Layer 2 Tunneling Protocol
   (L2TPv3), presented in a manner which highlights its applicability
   for Pseudo Wire Emulation Edge to Edge (PWE3). It is intended as a
   guide for architects, new implementers, and those adding
   functionality to L2TPv3 in support of new pseudowire types.












Townsley                     Informational                      [Page 1]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


   Contents

   Status of this Memo..........................................    1
      1.0 Introduction..........................................    2
      1.2  L2TPv2 and L2TPv3....................................    3

   2.  L2TP Tunneling Reference Models and Terminology..........    3
      2.1 LAC to LAC Reference Model............................    4
      2.2 LAC to LNS Reference Model............................    4
      2.3 The LAC and LNS in L2TP...............................    5

   3.  L2TP Control Plane Overview and General Applicability....    5
      3.1  L2TP Control Connection Establishment................    6
      3.2  L2TP Session Establishment...........................    7
      3.3  Summary of Status and Maintenance Messages...........    7
      3.4  Control Message Composition..........................    9
      3.5  Creating New Control Messages........................    9
      3.6  Advertising Support for Optional Features............   10
      3.7  Summary of Selected PWE3-Related Control Message AVPs   10
         3.7.1 Session Establishment AVPs.......................   10
         3.7.2 Control Connection Establishment AVPs............   11

   4.  L2TP Data Packet Encapsulation...........................   11
      4.1  L2TP over various PSNs...............................   11
      4.2  L2TPv3 over IP.......................................   12

   5.  Security Considerations..................................   14

   6.  IANA Considerations......................................   15

   7.  Acknowledgements.........................................   15

   8.  Author's Address.........................................   15

   9.  References...............................................   15

   Appendix A: L2TPv2 and L2TPv3................................   16

   Appendix B: "Incoming Calls" and "Outgoing Calls"............   17

1.0 Introduction

   L2TPv3 [L2TPv3] defines a protocol for setup, maintenance and
   transport of individual pseudowires (PWs) across an IP network.  A
   collection of PWs may be employed to provide a full Layer 2 VPN
   (L2VPN) service for a variety of circuit types types, including
   Ethernet, Frame Relay, HDLC, PPP, ATM, AAL5, and others.




Townsley                     Informational                      [Page 2]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


   L2TPv3 consists of a control protocol and associated state machines
   for dynamic establishment, maintenance and release of PWs, together
   with the necessary encapsulation to carry multiple PWs between two
   tunnel endpoints. In most cases, a given PW-type will operate over
   L2TPv3 with very few additional protocol constructs beyond that
   defined in [L2TPv3]. When significant additional PW-type-specific
   protocol constructs are necessary, they should be defined in brief
   companion documents.

   This document focuses solely on how L2TPv3 is used to support
   individual Pseudowires.  Full L2VPN services including various
   provisioning methods, auto-discovery, etc. is outside the scope of
   this specific document.

1.2  L2TPv2 and L2TPv3

   L2TP (Layer 2 Tunneling Protocol) [RFC2661] defines a method for
   offloading layer 2 PPP frames from a circuit-switched network to a
   packet-switched network (e.g. IP), while providing emulation of as
   many of the characteristics of the native point-to-point link as
   possible.

   L2TP as defined in [RFC2661] is sometimes referred to now as
   "L2TPv2," while the extended version supporting mutliple PW types
   defined in [L2TPv3] is referred to as "L2TPv3" (for more information
   on the similarities and differences between L2TPv2 and L2TPv3, see
   Appendix A). The remainder of this document will refer simply to L2TP
   in general unless contrasting specific features of L2TPv3 or L2TPv2
   which may differ in function.

   New L2TPv3 implementations with no intention of supporting PPP over
   L2TPv2 may ignore RFC 2661 as the L2TPv3 specification is complete on
   its own. However, there may be advantages to starting with an
   available L2TPv2 implementation, and specific advice is given for
   migration and coexistence with L2TPv2 in [L2TPv3].

2.  L2TP Tunneling Reference Models and Terminology

   Section 2 of [L2TPv3] identifies several reference models for Layer 2
   tunneling, and refers to L2TP-specific terminology for these.  Two
   important pieces of L2TP terminology to be aware of are the L2TP
   Access Concentrator (LAC) and L2TP Network Server (LNS). This section
   provides an overview of two of these reference models and terminology
   in specific relation to support of PWs for PWE3.







Townsley                     Informational                      [Page 3]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


2.1 LAC to LAC Reference Model

   An L2TP LAC looks like a PWE3 PE. That is, there are "native"
   circuits physically connected to the equipment, and pseudowires
   extending from the LAC over a Packet Switched Network (PSN) for these
   circuits. For L2TPv3, the default PSN is an IP network.

   Following is a diagram of the "LAC to LAC" service model defined in
   L2TPv3. This is very similar to the PWE3 Network Reference Model
   [PWE3-REQ], though utilizing L2TP-specific nomenclature which
   abstracts the protocol terminology from the deployment location.

      +-----+  L2  +-----+                      +-----+  L2  +-----+
      |     |------| LAC |...[Packet Network]...| LAC |------|     |
      +-----+      +-----+                      +-----+      +-----+
      Remote                                                 Remote
      System                                                 System
                         |<- Emulated Service ->|
            |<----------------- L2 Service ----------------->|


                Figure 1: L2TP LAC to LAC Reference Model

   LAC - L2TP Access Concentrator, analogous to the PWE3 PE.

   Remote System - Analogous to the PWE3 CE.

   Emulated Service - Analogous to the PWE3 pseudowire.

2.2 LAC to LNS Reference Model

   An LNS is different from an LAC in that it does not have native
   Attachment Circuits on which to directly forward pseudowire frames
   to. Instead, the pseudowire frames are received and processed on a
   virtual interface as if received on a local AC as a CE. A convenient
   way to think of this is to imagine a PWE3 CE and PE collapsed into a
   single piece of equipment. The LNS MAY support virtual routing or
   bridging instances for groups of sessions.

   An LNS may be used with an LAC to provide access to a network via
   emulated L2 circuits. This is the most commonly used model in L2TPv2
   deployments for PPP tunneling at the time of this writing.









Townsley                     Informational                      [Page 4]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


      +-----+  L2  +-----+                        +-----+
      |     |------| LAC |....[Packet Network]....| LNS |...[Home Network]
      +-----+      +-----+                        +-----+
      Remote
      System
                         |<-- Emulated Service -->|
            |<----------- L2 Service ------------>|


                Figure 2: L2TP LAC to LNS Reference Model

   LAC - L2TP Access Concentrator, analogous to the PWE3 PE.

   Remote System - Analogous to the PWE3 CE.

   LNS - L2TP Network Server, a PWE3 PE and CE collapsed into the same
   device.

   Emulated Service - Analogous to the PWE3 pseudowire.

2.3 The LAC and LNS in L2TP

   From an encapsulation perspective, and during Control Connection
   setup (described in section 4), L2TPv3 does not distinguish between
   whether an LAC or LNS is on either side of the PW. During session
   setup, there are some differences with regard to identification of
   attachment circuits and the like as an LNS does not contain physical
   circuits to attach to.  For session setup, L2TPv2 makes more
   reference to the LAC and LNS as very separate different devices,
   while these differences were minimized in L2TPv3.

   The remainder of this document will refer to the PWE3 terms "PE" and
   "CE" when discussing PWE3 applicability, though it is important to
   remember what an LAC, LNS, and Remote System are when reading the
   L2TP Protocol Documents.

3.  L2TP Control Plane Overview and General Applicability

   The L2TP Control Plane is divided into two parts, (1) a reliable
   Control Connection for sending control messages between PEs, and (2)
   state machines for establishing, maintaining, and tearing down the
   Control Connections and L2TP Sessions between each PE.

   One L2TP Session is established for each pseudowire, and each Control
   Connection governs a group of Sessions as well as the common
   association between two PEs. There may be one or more Control
   Connections between two PEs, and typically are many Sessions within
   each Control Connection. It is important to note that L2TPv2 parlance



Townsley                     Informational                      [Page 5]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


   commonly referred to each established Control Connection as a
   "Tunnel" which is somewhat different than the definition in PWE3.
   L2TPv3 does away with "Tunnel" in its terminology to avoid obvious
   confusion, referring only to "Sessions" and "Control Connections."

3.1  L2TP Control Connection Establishment

   The L2TP Control Connection is the primary association between two
   L2TP tunnel endpoints (PEs). A Control Connection must be established
   before any L2TP Sessions (and hence pseudowires) may be established.

   A successful Control Connection establishment looks like this:

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

      SCCRQ: Start Control Connection Request
      SCCRP: Start Control Connection Reply
      SCCCN: Start Control Connection Connected

   Note that each of these messages is transported by the reliable
   control channel (i.e., there is an additional transport-level ack to
   the SCCCN that will occur, but this is a layer below the L2TP state
   machine).  Either side of a connection may initiate the Control
   Connection by sending an SCCRQ, and a tie-breaker facility exists in
   the event that both sides attempt connection establishment at the
   same time.

   During Control Connection establishment, PEs establish their identity
   and exchange capability information with one another. Identity may be
   confirmed via an optional challenge-handshake authentication exchange
   built into the control connection setup. Capability and relevant
   configuration information is advertised via AVPs in the SCCRQ or
   SCCRP messages.

   The protocol constructs described in this section provide the basis
   for the following PWE3 requirements as identified in [PWE3-REQ]:

      Misconnection and Payload Mistype (Section 3.3.2.)
      Collective Status Notification (3.3.5.)
      Tunnel Hierarchy (Scalability, Section 6.)







Townsley                     Informational                      [Page 6]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


3.2  L2TP Session Establishment

   Once the Control Connection is established, L2TP sessions
   (pseudowires) may be established. L2TP has two state machines, and
   two different sets of messages depending on the type of session to be
   established. We will limit the discussion in this document to the
   "Incoming Call" state machine and message exchange, as this is the
   commonly used case in PWE3 (see Appendix B for a discussion of the
   term "Call" and the "Outgoing Call" state machine and message
   exchange).

   A successful L2TP session establishment looks like this:

             PE A        PE B
            ------      ------
            ICRQ ->
                        <- ICRP
            ICCN ->

      ICRQ: Incoming Call Request
      ICRP: Incoming Call Reply
      ICCN: Incoming Call Connected

   During session establishment, characteristics of the individual
   pseudowire, interfaces, etc. may be exchanged, as well as ephemeral
   session attributes such as the Session ID used for data packet
   switching. In the event that both sides of the connection attempt to
   send an ICRQ at the same time, a tie-breaker AVP is used to determine
   which side "wins."

   The protocol constructs described in this section provide the basis
   for the following PWE3 requirements as identified in [PWE3-REQ]

      Setup and Teardown of Pseudo-Wires (Section 3.1.)
      Misconnection and Payload Mistype (Section 3.3.2.)

3.3  Summary of Status and Maintenance Messages

   All messages referred to here are sent as single independent
   messages, requiring no explicit state machine to operate above the
   reliable Control Connection. This section is intended to provide a
   summary of available messages in the L2TPv3 specification. For more
   details of each message, including AVPs used in the construction of
   each, etc. please refer to [L2TPv3].







Townsley                     Informational                      [Page 7]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


   Hello Message

      The Hello message is used as a simple "keepalive" to ensure that
      the peer is still active. If control and data operate over the
      same path (as is the default for L2TPv3 over IP), then the
      delivery of this message may be used as a general indicator that a
      valid data path exists as well. This message is sent periodically
      by either peer, based on a configured time period, and may back
      off during periods of congestion or when other information (e.g.
      receipt of another control message) is available to indicate that
      a peer is still active. Thus, the Hello message is never
      "expected" by either side of the link. Instead, the Hello
      mechanism relies only on the generic Control Connection transport
      for delivery. For added scalability, the Hello message acts as a
      collective keepalive for all sessions associated with a given
      Control Connection.

      The Hello message MUST NOT be used to carry status notification
      events, or other purposes beyond the scope of a simple peer and
      path detection facility.

   Set Link Info (SLI) Message

      The Set Link Info message is used to identify link status changes
      at a PE interface associated with a pseudowire. The most basic
      link status change is simply a circuit going up or down, which is
      advertised via the base Circuit Status AVP. Additional AVPs for
      each service type may be defined if additional information
      associated with an interface needs to be updated over the life of
      a connection. These AVPs MUST be defined in separate service-
      specific documents.

   WAN Error Notify (WEN) Message

      This message is used to identify any link interface or pseudowire
      errors that may occur and be of interest to the operator on the
      other side of the L2TP connection.  This includes statistics on
      packet loss, out-of-order delivery (if sequencing is enabled) and
      packet corruption (if some form of CRC or Checksum is available).
      These values MAY be reported on a periodic interval, and are for
      logging and troubleshooting purposes.  Any necessary values for a
      given service beyond those defined in [L2TPv3] MUST be defined in
      separate service-specific documents.

   The protocol constructs described in this section provide the basis
   for the following PWE3 requirements as identified in [PWE3-REQ]:

      Status Monitoring (Section 3.2.)



Townsley                     Informational                      [Page 8]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


      Up/Down Notification (Section 3.3.1.)
      Keep-alive (Section 3.4.)
      Packet Loss, Corruption, and Out-of-order Delivery (Section 3.3.3.)

3.4  Control Message Composition

   Control Messages are sent with the L2TP Control Connection header to
   ensure proper delivery between PEs, followed by a list of Attribute
   Value Pairs (AVPs). AVPs in L2TP are of a similar form to the "Type
   Length Value" (TLV) constructs in other control protocols. The
   Message Type itself is an AVP, as is the specific Session ID or
   Control Connection ID for which the message applicable for. Please
   refer to [L2TPv3] for the specific format of these AVPs and the
   Control Message header.

3.5  Creating New Control Messages

   Adding additional control messages to L2TP is a natural extension
   that may be utilized to signal events and information between
   pseudowire endpoints. Most line events and status notifications may
   be sent with a single, independent control message. Additional
   complexity via req/ack messages and state machines should be avoiding
   when a single reliably delivered message will suffice.

   A new message may be created by simply assigning a new Message Type
   AVP value. The Message Type AVP is present at the beginning of the
   body of all L2TP Control Messages. This AVP may be vendor-specific,
   rendering the control message itself as vendor-specific.

   The Vendor ID is zero for IETF defined messages, and set to the IANA
   assigned "SMI Network Management Private Enterprise Codes" [RFC1700]
   value for vendor-specific messages. IANA also assigns the Message
   Type value for IETF Control Messages, but vendor-specific messages
   must maintain their own number space.

   L2TP Message Type AVP:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|0| rsvd  |    Length = 8     |    Vendor ID (0 for IETF)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Attribute Type = 0        |          Message Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3: L2TP Message Type AVP





Townsley                     Informational                      [Page 9]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


3.6  Advertising Support for Optional Features

   The SCCRQ, SCCRP, and SCCCN messages should be utilized to advertise
   availability of a specific optional feature available for the Control
   Connection or the group of sessions within a Control Connection. This
   may be as simple as the presence of a single AVP, or a set of AVPs
   listing multiple parameters.

   Support for a given pseudowire type MUST be advertised via the
   Pseudowire Capabilities List AVP.

3.7  Summary of Selected PWE3-Related Control Message AVPs

   This section will highlight some more pertinent AVPs used in the
   setup and maintenance of pseudowires with L2TP.

3.7.1 Session Establishment AVPs

   The following AVPs are among those exchanged during L2TP Session
   establishment. For a complete list and full details, refer to section
   5.4.4 of [L2TPv3].

   End Identifier AVP

      The End Identifier AVP is of arbitrary length, and is used to
      identify the interface, circuit, or other entity to tie the L2TP
      session to. The field may be a simple 4-octet binary value, an
      ASCII string, or any other agreed-upon format for the given
      pseudowire type or application.

   Pseudowire Type

      The Pseudowire Type indicates the type of pseudowire for this L2TP
      session.

   Assigned Cookie

      The 0, 32, or 64-bit random value to be sent in each data packet
      for sanity checking the session context lookup. A 0-bit value is
      used to indicate that the Cookie field is not present.

   Local Session ID

      Used to exchange the pair of 32-bit Session IDs that are to be
      used in all data packet headers to identify an L2TP Session (and
      hence a pseudowire).





Townsley                     Informational                     [Page 10]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


3.7.2 Control Connection Establishment AVPs

   The following AVPs are exchanged during Control Connection
   establishment. For a complete list and full details, refer to section
   5.4.3 of [L2TPv3].

   Pseudowire Capabilities List (SCCRP, SCCRQ)

      List of pseudowire types that this node is capable of receiving
      packets for. Used to advertise peer PE capabilities before
      initiating a session.

   Host Name (SCCRP, SCCRQ)

      The Host Name AVP carries a unique identifier, possible a fully
      qualified domain name, for the originator of the control
      connection.

   Challenge (SCCRP, SCCRQ)

      Random data hashed with a shared password to perform a simple
      Control Connection (PE to PE) authentication.

   Challenge Response (SCCCN, SCCRP)

      Result of the hash used for Control Connection (PE to PE)
      authentication.

4.  L2TP Data Packet Encapsulation

4.1  L2TP over various PSNs

   L2TP was designed from its inception to be able to operate over any
   packet-switched network (PSN). While UDP/IP is by far the most
   popular PSN for L2TPv2 tunneling PPP, specifications for other PSNs
   have been deployed [RFC3070], [L2TPAAL5] and is explicitly allowed in
   [RFC2661].

   The L2TP control plane may also be used to setup alternate data
   encapsulations. For example, [L2TPHC] defines a header format for a
   specific application where the size of the L2TP and PPP header is of
   primary importance. L2TPv3 takes advantage of this as well, signaling
   its extended header format by the presence of the 32-bit Session ID
   as opposed to the 16-bit Session ID for L2TPv2. Other PW Multiplexing
   formats could be exchanged here as well, including an MPLS label, or
   GRE Key.





Townsley                     Informational                     [Page 11]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


4.2  L2TPv3 over IP

   Following is the format of the L2TPv3 data header defined for
   operation over IP Protocol ID 115.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Session ID                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Cookie                      (opt) |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Cookie                      (opt) |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |P|S|x|x|x|x|x|x|         Sequence Number                 (opt) |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 4: An L2TPv3 over IP Data Packet

   The first four octets contain the L2TPv3 Session ID. The Session ID
   is used as a pseudowire identifier/multiplexing field. It contains
   32-bits assigned by the receiver during session establishment. The
   expectation is that the receiver will optimize the bits in this
   Session ID for whatever context lookup mechanism may be available on
   the specific platform. For example, the context lookup mechanism for
   the pseudowire could be a simple index with the low-order bits used
   as a direct lookup, or specific bits could be used to distribute a
   packet to parallel processing paths in a distributed engine,
   platform, or cluster. If the following optional Cookie is utilized,
   the Session ID may be selected without concern for choosing a value
   which has been recently expired. The Session ID of 0 is reserved for
   L2TPv3 control traffic.

   The remainder of L2TPv3 header beyond the Session ID is optional, and
   may even vary from what is shown above based upon the PW-type in
   operation. The L2TP control channel signals the presence of (and in
   many cases the values contained within) each field during session
   establishment. In order to ensure interoperability while still
   allowing some flexibility over what fields an implementation is
   required to know how to process, L2TP uses a simple governing
   principle for its variant header. This principle states that the
   receiver of a data packet always identifies the format it expects,
   and the sender MUST strictly comply. This is the case not only for
   presence of optional fields such as the Cookie or L2-specific
   sublayer, but for the contents of the Session ID and Cookie as well,
   i.e., one side always informs the other exactly what it expects to be
   present in a header.




Townsley                     Informational                     [Page 12]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


   The optional Cookie (0, 4 or 8 octets) is designed to be an
   efficient, lightweight, packet validation mechanism. Like the Session
   ID, it contains bits assigned by the receiver during session
   establishment for insertion in each packet. Unlike the Session ID,
   these bits do not serve as a context lookup mechanism, but rather as
   a simple check to see if the value in the data packets matches the
   value advertised for that Session.  Also, unlike the Session ID, the
   value selected for a Cookie MUST be unpredictable and unique across
   current and recently-expired sessions.

   Thus, while the form of the Session ID is free to be optimized for a
   local lookup mechanism, the Cookie provides an added degree of
   certainty that the arriving packet does in fact match the context
   obtained by the Session ID resolution. For example, if the Session ID
   context lookup for an arriving data packet was implemented as a
   simple index, a single bit error in the range of bits being used for
   the index could rather easily cause a packet to be sent to the wrong
   PW or interface. Since there is no network-level checksum available
   for the L2TP Session ID running directly over IP, this may be of
   concern depending on the potential for unchecked bit errors of the
   underlying data link.  The Cookie provides up to a full 64 bits of
   additional guarantee that a packet is definitively intended for a
   given destination in face of such bit errors, as well as a way of
   detecting the arrival of any stale data packets after a Session ID
   has been released and reallocated. The Cookie also provides
   protection against simple brute force or blind data insertion attacks
   by a rogue entity.

   The next four bytes in Figure 4 depict of the default L2-specific
   sublayer for L2TPv3. These fields contain pseudowire-specific values,
   and as such may vary among pseudowire types (e.g. RTP has its own
   sequencing, thus a given timing-dependent pseudowire type may choose
   to not use the default header defined here).

   The P bit is a "priority" bit which SHOULD be set for end-to-end
   signaling packets traversing the session data path. This allows the
   PE to provide a higher priority to these packets when processing as
   they may be important for the health of the overall end-to-end link.
   This may be of particular concern during periods of congestion at the
   PE if the native service being emulated has an end-to-end keepalive
   method enabled.

   The S bit indicates whether the following sequence number is valid or
   not.

   The Sequence number is a 24-bit free running counter (0 is a valid
   sequence number).




Townsley                     Informational                     [Page 13]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


   The x bits are reserved for future use.

   For further details of how these fields are used, please consult
   [L2TPv3].

   The protocol constructs described in this section provide the basis
   for the following PWE3 requirements as identified in [PWE3-REQ]:

      Handling Control Messages of the Native Services (Section 2.5.)
      Frame Duplication (Section 2.3.)
      Frame Ordering (Section 2.2.)
      Support of Multiplexing and Demultiplexing (Section 2.1.3)
      Support of Variable Length PDUs (Section 2.1.2.)

5.  Security Considerations

   L2TP provides a number of security features which may be used
   depending on the needs of a given deployment. Details of these are
   provided in [L2TPv3].

   L2TP acts much like a client/server application operating between two
   nodes on a network. Thus, the pseudowire which L2TP operates with
   inherits many of the security properties of the underlying PSN (for
   good or for ill). In cases where the PSN is protected, physically,
   cryptographically, or otherwise, the pseudowire itself is also
   protected. This is discussed further in [PWE3-PLD].

   [RFC3193] provides details on how to protect L2TPv2 with IPsec
   transport mode. This is applicable to L2TPv3 over IPsec as well,
   though the sections on UDP port "floating" may be ignored for the
   IP-only encapsulation. When running over IP, L2TP with IPsec provides
   cryptographic security for all data traffic within and control
   traffic in support of the L2TP pseudowires. Running IPsec beneath
   L2TP in this manner does not require any extensions to IPsec, and
   does not rely on IPsec for Tunnel Mode encapsulation or any
   extensions to the IPsec suite of protocols.

   In the event that IPsec is not available, L2TP also provides a simple
   shared-secret Control Connection Authentication method to ensure that
   only authorized PE are permitted to establish a Control Connection
   (and hence any pseudowire connections within).

   L2TPv3 includes an optional 64-bit Cookie in the header of each L2TP
   data packet which contains a random value identified at session
   start.  While not its only functional purpose, the cookie field may
   be used to protect against blind insertion attacks for a given
   tunnel. This is not intended as a replacement for proper traffic
   filtering, nor for cryptographic security with IPsec when warranted.



Townsley                     Informational                     [Page 14]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


   However, in the absence of advanced traffic snooping, this field does
   provide a reasonable defense against brute force packet insertion
   attacks, and certainly provides for protection against
   misconfiguration or other potential means of inadverdent packet
   misdirection.

6.  IANA Considerations

   There are no new numbers defined in this document for IANA to
   maintain.

7.  Acknowledgements

   I would like to acknowledge the author of the first Ethernet over
   L2TP internet draft, Suhail Nanji, the first Frame Relay over L2TP
   authors, Nishit Vasavada, Jim Boyle, Chris Garner, Serge Maskalik,
   Vijay Gill, and the original "Encapsulation Services" authors for
   L2TP, Nishit Vasavada, Danny McPherson, Ravi Bail Bhat, Andy
   Koscinski, Chi Fai Ho. These individuals were among the original
   purveyors of non-PPP encapsulations over L2TP before L2TPv3 and the
   PWE3 Working Group was created.

   Stewart Bryant, Eric Rosen, Lloyd Wood, and Wei Luo provided helpful
   review of this document.

8.  Author's Address

   W. Mark Townsley
   cisco Systems
   7025 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC 27709
   mark@townsley.net

9.  References

[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
          1700, October 1994.  See also:
          http://www.iana.org/numbers.html

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", RFC 2119, March 1997.

[RFC2661]  Townsley, Valencia, Rubens, Pall, Zorn, Palter, "Layer
           Two Tunneling Protocol 'L2TP'", RFC 2661, June 1999.

[RFC2434]  Alvestrand, H. and Narten, T., "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 2434,



Townsley                     Informational                     [Page 15]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


           October 1998.

[RFC3070]  V. Rawat, R. Tio, S. Nanji, R. Verma, "Layer Two Tunneling
           Protocol (L2TP) over Frame Relay," RFC 3070, February 2001.

[PWE3-REQ] XiPeng Xiao, Danny McPherson, Prayson Pate, Craig White,
           Kireeti Kompella, Vijay Gill, Thomas D. Nadeau,
           "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3),"
           work in progress, draft-ietf-pwe3-requirements-02.txt,
           May 2002.

[PWE3-PLD] Stewart Bryant, Lloyd Wood, Mark Townsley, Danny McPherson,
           "Protocol Layering in PWE3," work in progress,
            draft-bryant-pwe3-protocol-layer-01.txt, February 2002.

[L2TPv3]   J. Lau, M. Townsley, A. Valencia, G. Zorn, I. Goyret,
            G. Pall, A. Rubens, B. Palter, "Layer Two Tunneling Protocol
            (Version 3) 'L2TPv3'" work in progress,
            draft-ietf-l2tpext-l2tp-base-02.txt, February 2002.

[L2TP-PPP] J. Lau, M. Townsley, A. Valencia, G. Zorn, M. Verma,
           I. Goyret, G. Pall, A. Rubens, B. Palter, "PPP Tunneling
           Using Layer Two Tunneling Protocol" work in progress,
           draft-ietf-l2tpext-l2tp-ppp-01.txt, November 2001.

[L2TPAAL5] Mike Davison, Arthur Lin, Ajoy Singh, John Stephens,
           Rollins Turner, Rene Tio, Suhail Nanji, "L2TP over AAL5,"
           work in progress, draft-ietf-l2tpext-l2tp-atm-02.txt,
           August 2001.

[L2TPHC]   A. Valencia, "L2TP Header Compression ('L2TPHC'),"
           work in progress, draft-ietf-l2tpext-l2tphc-04.txt,
           October 2001.


Appendix A: L2TPv2 and L2TPv3


   L2TPv2 [RFC2661] was first deployed as a method for bypassing
   expensive PSTN (Public Switching Telephone Network) networks with
   faster, cheaper, IP networks. L2VPNs were created by tunneling point
   to point PPP connections over IP (and to a lesser extent, Frame Relay
   and ATM) networks to multiple service providers. As broadband DSL was
   deployed, L2TP was used to offload PPP from ATM PVC networks, again
   utilizing the ability to dynamically create emulated point-to-point
   connections between any L2TP-enabled IP connected endpoint. More
   recently, L2TP has been used to tunnel Ethernet and Frame Relay,
   utilizing the familiar L2TP constructs for tunneling of PPP.



Townsley                     Informational                     [Page 16]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


   To provide specification modularity for tunneling pseudowire types
   other than PPP, RFC 2661 was split into a base specification [L2TPv3]
   and an accompanying PPP over L2TP specification [L2TP-PPP]. This base
   specification also introduced a new encapsulation format for
   transport directly over IP protocol ID 115 (as opposed to only UDP),
   an expanded Session ID space from 16 to 32 bits, an extended sequence
   number space from 16 to 32 bits, and other changes based on past
   implementation experience. These changes required an L2TP version
   field increment to 3, thus the name "L2TPv3" that has been adopted.
   The L2TPv2 header over UDP port 1701 may still be used for tunneling
   PPP as defined in [RFC2661], and likely will be for some time. Layer
   2 tunneling other than PPP, MUST use the improved encapsulation
   method defined in the L2TPv3 specification.

   The L2TPv2 state machines, reliable transport for message delivery,
   maintenance and status messages, etc. remain largely unchanged in
   L2TPv3 beyond the separation of PPP-specific AVPs (Attribute Value
   Pairs) from the base specification, and the addition of new AVPs to
   support the negotiation of pseudowire types and their associated
   connection to attached circuits.

   For more information on the differences between L2TPv2 and L2TPv3,
   please see Section 1.1, "Changes from RFC 2661" and Section 4.7,
   "L2TPv2/v3 Interoperability and Migration" in [L2TPv3].

Appendix B: "Incoming Calls" and "Outgoing Calls"


   The term "Call" used in L2TP is a holdover from the action of
   receiving a call on a dialup line. PWE3 was not the first to make
   this original choice of wording seem a bit out of place; the very
   common use of L2TP in broadband applies this same "call" action to an
   ATM PVC. In this light, an L2TP "Incoming Call" becomes the action of
   a circuit being provisioned and transitioning to the "Up" or "Active"
   state. When looked at this way, it becomes a bit less awkward. The
   choice to keep the "Call" name was made to be consistent with the
   large installed base of existing implementations using this
   terminology.

   An "Outgoing Call" is very different from an "Incoming Call" in L2TP.
   An "Outgoing Call" is SVC-type connection attempted in response to an
   L2TP Outgoing Call Request (OCRQ), directed to an arbitrary location
   identified by information contained in the L2TP message, and may take
   some time to be completed.  For example, the classic L2TPv2 Outgoing
   Call application is dialing a modem on a PSTN based on a telephone
   number. The node establishing the SVC connection acts as a slave to
   the other side of the L2TP connection, establishing the SVC wherever
   indicated (within policy bounds which may be applied if necessary).



Townsley                     Informational                     [Page 17]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002


   The Outgoing Call message exchange has a very clear initiator and
   responder, incapable of a "tie" as is the case in an Incoming Call
   exchange.  Also, instead of three messages sent in response to one
   another in a handshake fashion as with an Incoming Call, an Outgoing
   Call is established by sending a single message from the initiator,
   and two messages sent from the responder in return. The first
   Outgoing Call message, the OCRQ, is sent to request the Outgoing Call
   to be made with the identified SVC method.  The subsequent two
   messages, the Outgoing Call Reply (OCRQ) and Outgoing Call Connected
   (OCRP) messages signal that the SVC connection is being attempted,
   and that the SVC connection was completed, respectivly.

   Thus, an Outgoing Call is essentially a method of controlling the
   originating point of an SVC, allowing it to be established from any
   reachable L2TP-enabled device able to perform outgoing calls.  PWE3
   has largely identfied incorporation of various SVC methods as "left
   for future study."  Until said future study is completed, the
   Outgoing Call model may not find use outside of the dial arena where
   it is deployed with L2TPv2 today.

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."




Townsley                     Informational                     [Page 18]

INTERNET DRAFT              PWE3 and L2TPv3               September 2002





















































Townsley                     Informational                     [Page 19]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/