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

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 4719

Network Working Group                               Rahul Aggarwal
Internet Draft                                      Juniper Networks
Expiration Date: November 2006                      W. Mark Townsley
                                                    Maria A. Dos Santos
                                                    Cisco Systems
                                                    Editors
                                                    May 2006

                Transport of Ethernet Frames over L2TPv3

                draft-ietf-l2tpext-pwe3-ethernet-06.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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/1id-abstracts.html

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

Abstract

   This document describes transport of Ethernet frames over Layer 2
   Tunneling Protocol (L2TPv3). This includes the transport of Ethernet
   port to port frames as well as the transport of Ethernet VLAN frames.
   The mechanism described in this document can be used in the creation
   of Pseudo Wires to transport Ethernet frames over an IP network.









Aggarwal, Townsley, et al.  Standards Track                     [Page 1]

INTERNET DRAFT  draft-ietf-l2tpext-pwe3-ethernet-06.txt         May 2006


Contributors

   Following is the complete list of contributors to this document.

   Rahul Aggarwal
   Juniper Networks
   Xipeng Xiao
   Riverstone Networks
   W. Mark Townsley
   Stewart Bryant
   Maria Alice Dos Santos
   Cisco Systems
   Cheng-Yin Lee
   Alcatel
   Tissa Senevirathne
   Consultant
   Mitsuru Higashiyama
   Anritsu Corporation

Table of Contents


   Status of this Memo..........................................    1

   1. Introduction..............................................    3
      1.1 Abbreviations.........................................    3
      1.2 Requirements..........................................    3

   2. PW Establishment..........................................    4
      2.1 LCCE-LCCE Control Connection Establishment............    4
      2.2 PW Session Establishment..............................    5
      2.3 PW Session Monitoring.................................    5

   3. Packet Processing.........................................    7
      3.1 Encapsulation.........................................    7
      3.2 Sequencing............................................    7
      3.3 MTU Handling..........................................    7

   4. Applicability Statement...................................    8

   5. Congestion Control........................................    9

   6. Security Considerations...................................   10

   7. IANA Considerations.......................................   10

   8. Acknowledgements..........................................   10




Aggarwal, Townsley, et al.  Standards Track                     [Page 2]

INTERNET DRAFT  draft-ietf-l2tpext-pwe3-ethernet-06.txt         May 2006


   9. References................................................   11
      9.1 Normative References..................................   11
      9.2 Informative References................................   11

   10. Author Information.......................................   11


Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  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].


1. Introduction

   L2TPv3 can be used as a control protocol and for data encapsulation
   to set up Pseudo Wires (PW) for transporting layer 2 Packet Data
   Units across an IP network [RFC3931]. This document describes the
   transport of Ethernet frames over L2TPv3 including the PW
   establishment and data encapsulation.


1.1 Abbreviations


   CE      Customer Edge. (Typically also the L2TPv3 Remote System)
   LCCE    L2TP Control Connection Endpoint (See [RFC3931])
   PE      Provider Edge (Typically also the LCCE).
   PSN     Packet Switched Network
   PW      Pseudo-Wire
   PWE3    Pseudo-Wire Emulation Edge to Edge (Working Group)
   NSP     Native Service Processing



1.2 Requirements

   An Ethernet PW emulates a single Ethernet link between exactly two
   endpoints. The following figure depicts the PW termination relative
   to the NSP and PSN tunnel within a LCCE [RFC3985]. The Ethernet
   interface may be connected to one or more Remote Systems (an L2TPv3
   Remote System is referred to as Customer Edge (CE) in this and
   associated PWE3 documents). The LCCE may or may not be a PE.





Aggarwal, Townsley, et al.  Standards Track                     [Page 3]

INTERNET DRAFT  draft-ietf-l2tpext-pwe3-ethernet-06.txt         May 2006


                 +---------------------------------------+
                 |                 LCCE                  |
                 +-+   +-----+   +------+   +------+   +-+
                 |P|   |     |   |PW ter|   | PSN  |   |P|
   Ethernet  <==>|h|<=>| NSP |<=>|minati|<=>|Tunnel|<=>|h|<==> PSN
   Interface     |y|   |     |   |on    |   |      |   |y|
                 +-+   +-----+   +------+   +------+   +-+
                 |                                       |
                 +---------------------------------------+
                       Figure 1: PW termination


   The PW termination point receives untagged (also referred to as
   'raw') or tagged Ethernet frames and delivers them unaltered to the
   PW termination point on the remote LCCE. Hence it can provide
   untagged or tagged Ethernet link emulation service.

   The "NSP" function includes packet processing needed to translate the
   Ethernet packets that arrive at the CE-LCCE interface to/from the
   Ethernet packets that are applied to the PW termination point. Such
   functions may include stripping, overwriting or adding VLAN tags.
   The NSP functionality can be used in conjunction with local
   provisioning to provide heterogeneous services where the CE-LCCE
   encapsulations at the two ends may be different.

   The physical layer between the CE and LCCE, and any adaptation (NSP)
   functions between it and the PW termination, are outside of the scope
   of PWE3 and are not defined here.


2. PW Establishment

   With L2TPv3 as the tunneling protocol, Ethernet PWs are L2TPv3
   sessions. An L2TP control connection has to be set up first between
   the two LCCEs. Individual PWs can then be established as L2TP
   sessions.


2.1 LCCE-LCCE Control Connection Establishment

   The two LCCEs that wish to set up Ethernet PWs MUST establish a L2TP
   control connection first as described in [RFC3931]. Hence an Ethernet
   PW type must be included in the Pseudo Wire Capabilities List as
   defined in [RFC3931]. The type of PW can be either "Ethernet port" or
   "Ethernet VLAN". This indicates that the control connection can
   support the establishment of Ethernet PWs. Note that there are two
   Ethernet PW types required.  For connecting an Ethernet port to
   another Ethernet port, the PW Type MUST be "Ethernet port"; for



Aggarwal, Townsley, et al.  Standards Track                     [Page 4]

INTERNET DRAFT  draft-ietf-l2tpext-pwe3-ethernet-06.txt         May 2006


   connecting an Ethernet VLAN to another Ethernet VLAN, the PW Type
   MUST be "Ethernet VLAN".


2.2 PW Session Establishment

   The provisioning of an Ethernet port or Ethernet VLAN and its
   association with a PW triggers the establishment of an L2TP session
   as described in [RFC3931]. The following are the signaling elements
   needed for the PW establishment:

   a) Pseudo Wire Type: The type of a Pseudo Wire can be either
   "Ethernet port" or "Ethernet VLAN". Each LCCE signals its Pseudo Wire
   type in the Pseudowire Type AVP [RFC3931]. The assigned values for
   "Ethernet port" and "Ethernet VLAN" Pseudo Wire types are captured in
   the "IANA Considerations" of this document. The Pseudowire Type AVP
   MUST be present in the ICRQ.

   b) Pseudo Wire ID: Each PW is associated with a Pseudo Wire ID. The
   two LCCEs of a PW have the same Pseudo Wire ID for it. The Remote End
   Identifier AVP [RFC3931] is used to convey the Pseudo Wire ID. The
   Remote End Identifier AVP MUST be present in the ICRQ in order for
   the remote LCCE to determine the PW to associate the L2TP session
   with.  An implementation MUST support a Remote End Identifier of four
   octets known to both LCCEs either by manual configuration or some
   other means. Additional Remote End Identifier formats which MAY be
   supported are outside the scope of this document.

   c) The Circuit Status AVP [RFC3931] MUST be included in ICRQ and ICRP
   to indicate the circuit status of the Ethernet port or Ethernet VLAN.
   The N (New) bit of the Circuit Status AVP in ICRQ and ICRP MUST be
   set to 1 indicating that the status is for a new circuit while the A
   (Active) bit is set to 0 (INACTIVE) or 1 (ACTIVE) to reflect the
   circuit operational status.  Subsequent circuit status change of the
   Ethernet port or Ethernet VLAN MUST be conveyed in the Circuit Status
   AVP in ICCN or SLI control messages.  In ICCN and SLI, the Circuit
   Status AVP N bit MUST be set to 0 indicating that the status is for
   an existing circuit.  The A bit should be set to 0 or 1 to reflect
   the circuit operational status at that point in time.


2.3 PW Session Monitoring

   The working status of a PW is reflected by the state of the L2TPv3
   session. If the corresponding L2TPv3 session is down, the PW
   associated with it MUST be shut down. The control connection keep-
   alive mechanism of L2TPv3 can serve as a link status monitoring
   mechanism for the set of PWs associated with a Control Connection.



Aggarwal, Townsley, et al.  Standards Track                     [Page 5]

INTERNET DRAFT  draft-ietf-l2tpext-pwe3-ethernet-06.txt         May 2006


2.3.1. SLI Message

   In addition to the control connection keep-alive mechanism of L2TPv3,
   Ethernet PW over L2TP makes use of the Set Link Info (SLI) control
   message defined in [RFC3931]. The SLI message is used to signal
   Ethernet link status notifications between LCCEs. This can be useful
   to indicate the Ethernet interface state change without bringing down
   the L2TP session. Note that change in the Ethernet interface state
   will trigger a SLI message for each PW associated with that Ethernet
   interface.  This may be one Ethernet Port PW or more than one
   Ethernet VLAN PW.  The SLI message MUST be sent any time there is a
   status change of any values identified in the Circuit Status AVP. The
   only exception to this is the initial ICRQ, ICRP and CDN messages
   which establish and teardown the L2TP session itself.  The SLI
   message may be sent from either LCCE at any time after the first ICRQ
   is sent (and perhaps before an ICRP is received, requiring the peer
   to perform a reverse Session ID lookup).

   Ethernet PW reports Circuit Status with the Circuit Status AVP
   defined in [RFC3931]. For reference, this AVP is shown below:


    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved        |N|A|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Value is a 16 bit mask with the two least significant bits
   defined and the remaining bits reserved for future use. Reserved bits
   MUST be set to 0 when sending, and ignored upon receipt.

   The A (Active) bit indicates whether the Ethernet interface is ACTIVE
   (1) or INACTIVE (0).

   The N (New) bit SHOULD be set to one (1) if the circuit status
   indication is for a new Ethernet circuit, zero (0) otherwise.














Aggarwal, Townsley, et al.  Standards Track                     [Page 6]

INTERNET DRAFT  draft-ietf-l2tpext-pwe3-ethernet-06.txt         May 2006


3. Packet Processing


3.1 Encapsulation

   The encapsulation described in this section refers to the
   functionality performed by the PW termination point depicted in
   figure 1, unless otherwise indicated.

   The entire Ethernet frame without the preamble or FCS is
   encapsulated in L2TPv3 and is sent as a single packet by the ingress
   LCCE. This is done regardless of whether an 802.1Q tag is present in
   the Ethernet frame or not. For Ethernet port to port mode the remote
   LCCE simply decapsulates the L2TP payload and sends it out on the
   appropriate interface without modifying the Ethernet header. For
   Ethernet VLAN to VLAN, the remote LCCE MAY rewrite the VLAN tag. As
   described in section 1, the VLAN tag modification is an NSP function.

   The Ethernet PW over L2TP is homogeneous with respect to packet
   encapsulation i.e. both the ends of the PW are either untagged or
   tagged. The Ethernet PW can still be used to provide heterogeneous
   services using NSP functionality at the ingress and/or egress LCCE.
   The definition of such NSP functionality is outside the scope of this
   document.


3.2 Sequencing

   Data packet sequencing may be enabled for Ethernet PWs. The
   sequencing mechanisms described in [RFC3931] MUST be used for
   signaling sequencing support.


3.3 MTU Handling

   With L2TPv3 as the tunneling protocol, the packet resulted from the
   encapsulation is N bytes longer than Ethernet frame without the
   preamble or FCS. The value of N depends on the following fields:

      L2TP Session Header:
         Flags, Ver, Res - 4 octets (L2TPv3 over UDP only)
         Session ID      - 4 octets
         Cookie Size     - 0, 4 or 8 octets
         L2-Specific Sublayer - 0 or 4 octets (i.e., using sequencing)

      Hence the range for N in octets is:

         N = 4-16,  for L2TPv3 data messages over IP;



Aggarwal, Townsley, et al.  Standards Track                     [Page 7]

INTERNET DRAFT  draft-ietf-l2tpext-pwe3-ethernet-06.txt         May 2006


         N = 16-28, for L2TPv3 data messages over UDP;
         (N does not include the IP header).

   The MTU and fragmentation implications resulting from this are
   discussed in section 4.1.4 of [RFC3931].


4. Applicability Statement

   The Ethernet PW emulation allows a service provider to offer a "port
   to port" Ethernet based service across an IP packet switched network
   (PSN) while the Ethernet VLAN PW emulation allows an "Ethernet VLAN
   to VLAN" based service across an IP packet switched network (PSN).

   The Ethernet or Ethernet VLAN PW emulation has the following
   characteristics in relationship to the respective native service:

   o Ethernet PW connects two Ethernet ACs while Ethernet VLAN PW
     connects two Ethernet VLAN ACs, supporting bi-directional
     transport of variable length Ethernet frames.  The ingress LCCE
     strips the preamble and FCS from the Ethernet frame and transports
     the frame in its entirety across the PW.  This is done regardless
     of the presence of the 802.1Q tag in the frame.  The egress LCCE
     receives the Ethernet frame from the PW and regenerates the
     preamble or FCS before forwarding the frame to the attached Remote
     System (See Section 3.1).  Since FCS is not being transported
     across either Ethernet or Ethernet VLAN PWs, payload integrity
     transparency may be lost.  To achieve payload integrity
     transparency on Ethernet or Ethernet VLAN PWs using L2TP over IP
     or L2TP over UDP/IP, the L2TPv3 session can utilize IPSec as
     specified in Section 4.1.3 of [RFC3931].

   o For Ethernet VLAN PW, VLAN tag rewrite can be achieved by NSP at
     the egress LCCE which is outside the scope of this document (See
     Section 3.1).

   o The Ethernet or Ethernet VLAN PW only supports homogeneous Ethernet
     frame type across the PW; both ends of the PW must be either tagged
     or untagged.  Heterogeneous frame type support achieved with NSP
     functionality is outside the scope of this document (See Section
     3.1).

   o Ethernet port or Ethernet VLAN status notification is provided
     using the Circuit Status AVP in SLI message (See Section 2.3.1).
     Loss of connectivity between LCCEs can be detected by the L2TPv3
     keepalive mechanism (see Section 2.3.1 in [RFC3931]).  The LCCE
     can convey these indications back to its attached Remote System.




Aggarwal, Townsley, et al.  Standards Track                     [Page 8]

INTERNET DRAFT  draft-ietf-l2tpext-pwe3-ethernet-06.txt         May 2006


   o The maximum frame size that can be supported is limited by the PSN
     MTU minus the L2TPv3 header size, unless fragmentation and
     reassembly is used (see Section 3.3 and Section 4.1.4 of
     [RFC3931]).

   o The packet switched network may reorder, duplicate, or silently
     drop packets.  Sequencing may be enabled in the Ethernet or
     Ethernet VLAN PW for some or all packets to detect lost,
     duplicate, or out-of-order packets on a per-session basis
     (see Section 3.2).

   o The faithfulness of an Ethernet or Ethernet VLAN PW may be
     increased by leveraging Quality of Service features of the LCCEs
     and the underlying PSN.  For example for Ethernet VLAN transport,
     the ingress LCCE MAY consider the user priority field of the VLAN
     tag for traffic classification and QoS treatments, such as
     determining the TOS octet (for example, according to DSCP) of
     the encapsulating IP header.  Similarly, the egress LCCE MAY
     consider the TOS octet of the encapsulating IP header when
     rewriting the user priority field of the VLAN tag or queueing the
     Ethernet frame before forwarding the frame to the Remote System.
     The mapping between the 802.1Q COS and the IP header Qos field and
     the Quality of Service model deployed are application specific and
     are outside the scope of this document.


5. Congestion Control

   As explained in [RFC3985], the PSN carrying the PW may be subject to
   congestion, with congestion characteristics depending on PSN type,
   network architecture, configuration, and loading. During congestion
   the PSN may exhibit packet loss that will impact the service carried
   by the Ethernet or Ethernet VLAN PW. In addition, since Ethernet or
   Ethernet VLAN PWs carry an variety of services across the PSN,
   including but not restricted to TCP/IP, they may or may not behave in
   a TCP-friendly manner prescribed by [RFC2914] and thus consume more
   than their fair share.

   Whenever possible, Ethernet or Ethernet VLAN PWs should be run over
   traffic-engineered PSNs providing bandwidth allocation and admission
   control mechanisms.  IntServ-enabled domains providing the Guaranteed
   Service (GS) or DiffServ-enabled domains using EF (expedited
   forwarding) are examples of traffic-engineered PSNs. Such PSNs will
   minimize loss and delay while providing some degree of isolation of
   the Ethernet or Ethernet VLAN PW's effects from neighboring streams.

   LCCEs SHOULD monitor for congestion (by using explicit congestion
   notification, or by measuring packet loss) in order to ensure that



Aggarwal, Townsley, et al.  Standards Track                     [Page 9]

INTERNET DRAFT  draft-ietf-l2tpext-pwe3-ethernet-06.txt         May 2006


   the service using the Ethernet or Ethernet VLAN PW may be maintained.
   When severe congestion is detected (for example when enabling
   Sequencing and detecting that the packet loss is higher than a
   threshold) the Ethernet or Ethernet VLAN PW SHOULD be halted by
   tearing down the L2TP session via a CDN message.  The PW may be
   restarted by manual intervention, or by automatic means after an
   appropriate waiting time.


6. Security Considerations

   Ethernet over L2TPv3 is subject to all of the general security
   considerations outlined in [RFC3931].


7. IANA Considerations

   The signaling mechanisms defined in this document rely upon the
   allocation of following Ethernet Pseudowire Types (see Pseudo Wire
   Capabilities List as defined in 5.4.3 of [RFC3931] and L2TPv3
   Pseudowire Types in 10.6 of [RFC3931]) by the IANA (number space
   created as part of publication of [RFC3931]):

         Pseudowire Types
         ----------------

         0x0004  Ethernet VLAN Pseudowire Type
         0x0005  Ethernet Pseudowire Type


8. Acknowledgements

   This draft evolves from the draft, "Ethernet Pseudo Wire Emulation
   Edge-to-Edge". We would like to thank its authors, T.So, X.Xiao, L.
   Anderson, C. Flores, N. Tingle, S. Khandekar, D. Zelig and G. Heron
   for their contribution. We would also like to thank S. Nanji, the
   author of the draft, "Ethernet Service for Layer Two Tunneling
   Protocol", for writing the first Ethernet over L2TP draft.

   Thanks to Carlos Pignataro for providing a thorough review and
   helpful input.










Aggarwal, Townsley, et al.  Standards Track                    [Page 10]

INTERNET DRAFT  draft-ietf-l2tpext-pwe3-ethernet-06.txt         May 2006


9. References


9.1 Normative References

   [RFC3931]    J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling
                Protocol (Version 3)", RFC3931, March 2005.

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


9.2 Informative References

   [RFC3985]    S. Bryant, P. Pate, "Pseudo Wire Emulation Edge-to-Edge
                (PWE3) Architecture", RFC3985, March 2005

   [RFC2914]    Floyd, S., "Congestion Control Principles", BCP 41,
                RFC 2914, September 2000.


10. Author Information


   Rahul Aggarwal
   Juniper Networks
   1194 North Mathilda Avenue
   Sunnyvale, CA 94089
   e-mail: rahul@juniper.net

   W. Mark Townsley
   Cisco Systems
   7025 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC 27709
   e-mail: mark@townsley.net

   Maria Alice Dos Santos
   Cisco Systems
   170 W Tasman Dr
   San Jose, CA 95134
   e-mail: mariados@cisco.com









Aggarwal, Townsley, et al.  Standards Track                    [Page 11]

INTERNET DRAFT  draft-ietf-l2tpext-pwe3-ethernet-06.txt         May 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.





Aggarwal, Townsley, et al.  Standards Track                    [Page 12]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/