[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: July 2004                          W. Mark Townsley
                                                    Cisco Systems

                Transport of Ethernet Frames over L2TPv3


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026, except that the right to
   produce derivative works is not granted.

   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

   The list of Internet-Draft Shadow Directories can be accessed at


   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.

draft-ietf-l2tpext-pwe3-ethernet-01.txt                         [Page 1]

Internet Draft   draft-ietf-l2tpext-pwe3-ethernet-01.txt    January 2004

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [KEYWORDS].


   Following is the complete list of contributors to this document.

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

Table of Contents

      1     Introduction........................................     3
      1.1   Abbreviations.......................................     3
      1.2   Requirements........................................     3
      2     PW Establishment....................................     3
      2.1   LCCE-LCCE Control Connection Establishment..........     4
      2.2   PW Session Establishment............................     4
      2.3   PW Session Monitoring...............................     4
      2.3.1 SLI Message.........................................     5
      3     Packet Processing...................................     6
      3.1   Encapsulation.......................................     6
      3.2   Sequencing..........................................     6
      3.3   MTU Handling........................................     6
      4     Security Considerations.............................     7
      5     IANA Considerations.................................     7
      6     Acknowledgements....................................     7
      7     References..........................................     7
      8     Author Information..................................     8

draft-ietf-l2tpext-pwe3-ethernet-01.txt                         [Page 2]

Internet Draft   draft-ietf-l2tpext-pwe3-ethernet-01.txt    January 2004

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 [L2TPv3]. 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 [L2TPv3])
   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 [PWE3-ARCH]. The Ethernet
   interface may be connected to one or more CEs i.e. one or more L2TPv3
   Remote Systems. The LCCE may or may not be a PE.

                 |                 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.

draft-ietf-l2tpext-pwe3-ethernet-01.txt                         [Page 3]

Internet Draft   draft-ietf-l2tpext-pwe3-ethernet-01.txt    January 2004

   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. A L2TP control connection has to be set up first between
   the two LCCEs. Individual PWs can then be established as L2TP

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 [L2TPv3]. Hence Ethernet PW
   type must be included in the Pseudo Wire Capabilities list. 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.
   This can be used for connecting Ethernet port to another Ethernet
   port; Ethernet VLAN to another Ethernet VLAN; or for providing
   heterogeneous connectivity using NSP processing.

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 [L2TPv3]. 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 PW type in
   a PW AVP [L2TPv3]. The Pseudo Wire type for Ethernet port is TBD1 and
   the Pseudo Wire type for Ethernet VLAN is TBD2.

   b) PW ID: Each PW is associated with a PW ID akin to the VC-ID in
   [PWE3-CRTL]. The two LCCEs of a PW have the same PW ID for it. The

draft-ietf-l2tpext-pwe3-ethernet-01.txt                         [Page 4]

Internet Draft   draft-ietf-l2tpext-pwe3-ethernet-01.txt    January 2004

   End Identifier AVP in L2TPv3 is used as the PW ID. The 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 an End Identifier of four octets known to
   both LCCEs either by manual configuration or some other means.
   Additional End Identifier formats which MAY be supported are outside
   the scope of this document.

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 PW.

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 [L2TPv3]. 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 [L2TPv3]. 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        |A|N|

   The Value is a 16 bit mask with the two least significant bits
   defined and the remaining bits reserved for future use. Reserved bits

draft-ietf-l2tpext-pwe3-ethernet-01.txt                         [Page 5]

Internet Draft   draft-ietf-l2tpext-pwe3-ethernet-01.txt    January 2004

   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 this is the first time
   this interface has transitioned to ACTIVE, zero (0) otherwise.

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 a 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

3.2. Sequencing

   Data packet sequencing may be enabled for Ethernet PWs. The
   sequencing mechanims described in [L2TPv3] 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 size of the L2TPv3
   cookie, which maybe 0, 4 or 8 bytes. Hence the range for N is:

draft-ietf-l2tpext-pwe3-ethernet-01.txt                         [Page 6]

Internet Draft   draft-ietf-l2tpext-pwe3-ethernet-01.txt    January 2004

    N=4-12,  L2TPv3 data messages are over IP;
    N=12-20, L2TPv3 data messages are over UDP;
    (N does not include the IP header).

   The fragmentation implications resulting from this are discussed in
   [PWE3-FRAG]. The mechanisms outlined in [PWE3-FRAG] SHOULD be
   followed with regards to handling fragmentation on an Ethernet PW
   over L2TPv3.

4. Security Considerations

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

5.  IANA Considerations

   The following value needs assignment by IANA (number space should be
   created as part of publication of [L2TPv3]):

   TBD1 - Ethernet Pseudowire Type (see Pseudo Wire Capabilities List as
   defined in 5.4.3 of [L2TPv3]).

   TBD2 - Ethernet VLAN Pseudowire Type (see Pseudo Wire Capabilities
   List as defined in 5.4.3 of [L2TPv3]).

6. 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.

draft-ietf-l2tpext-pwe3-ethernet-01.txt                         [Page 7]

Internet Draft   draft-ietf-l2tpext-pwe3-ethernet-01.txt    January 2004

7. References

   [L2TPv3]     J. Lau, M. Townsley, A. Valencia, G. Zorn, I. Goyret,
                G. Pall, A. Rubens, B. Palter, Layer Two Tunneling
                Protocol a.k.a. "L2TPv3," work in progress,

   [L2TP-IANA]  Townsley, M., "L2TP IANA Considerations Update",
                Internet Draft,

   [PWE3-CRTL]  L. Martini., et al., "Transport of Layer 2 Frames Over
                MPLS", draft-ietf-pwe3-control-protocol-00.txt

   [PWE3-FRAG]  A. Malis, W. M. Townsley, "PWE3 Fragmentation and
                Reassembly", draft-malis-pwe3-fragmentation-00.txt

   [PWE3-LAYER] S. Bryant, L. Wood, M. Townsley, D. McPherson, "Protocol
                Layering in PWE3", draft-ietf-pwe3-protocol-layer-00.txt

   [PWE3-REQ]   X. Xiao, D. McPherson, P. Pate, C. White, K. Kompella,
                V. Gill, T. D. Nadeau, "Requirements for Pseudo-Wire
                Emulation Edge-to-Edge",

8. Author Information

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

   XiPeng Xiao
   Riverstone Networks
   5200 Great America Parkway
   Santa Clara, CA 95054
   Email: xxiao@riverstonenet.com

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

draft-ietf-l2tpext-pwe3-ethernet-01.txt                         [Page 8]

Internet Draft   draft-ietf-l2tpext-pwe3-ethernet-01.txt    January 2004

   Stewart Bryant
   Cisco Systems,
   4, The Square,
   Stockley Park,
   Uxbridge UB11 1BL,
   United Kingdom.
   e-mail: stbryant@cisco.com

   Cheng-Yin Lee
   600 March Rd, Ottawa
   Ontario, Canada K2K 2E6
   e-mail: Cheng-Yin.Lee@alcatel.com

   Tissa Senevirathne
   1567 Belleville Way
   Sunnywale CA 94087
   e-mail: tsenevir@hotmail.com

   Mitsuru Higashiyama
   Anritsu Corporation
   1800 Onna, Atsugi-shi, Kanagawa-prf., 243-8555 Japan
   e-mail: Mitsuru.Higashiyama@yy.anritsu.co.jp

IPR Notice

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive

draft-ietf-l2tpext-pwe3-ethernet-01.txt                         [Page 9]

Internet Draft   draft-ietf-l2tpext-pwe3-ethernet-01.txt    January 2004

Full Copyright Notice

   Copyright (C) The Internet Society (2003).  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

   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


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

draft-ietf-l2tpext-pwe3-ethernet-01.txt                        [Page 10]

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