[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: April 2005                         W. Mark Townsley
                                                     Maria A. Dos Santos
                                                     Cisco Systems
                                                     Editors

                 Transport of Ethernet Frames over L2TPv3

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

Status of this Memo

    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed,
    and any of which I become aware will be disclosed, in accordance with
    RFC 3668.

    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.

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.

Conventions used in this document

    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 RFC-2119 [KEYWORDS].

Contributors

    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
    Alcatel
    Tissa Senevirathne
    Consultant
    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
       7.1   Normative References................................     7
       7.2   Informative References..............................     7
       8     Author Information..................................     8



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


                  +---------------------------------------+
                  |                 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 [L2TPv3]. Hence an Ethernet
    PW type must be included in the Pseudo Wire Capabilities List as
    defined in [L2TPv3]. 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
    connecting 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 [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 Pseudo Wire
    type in the Pseudowire Type AVP [L2TPv3]. 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 [L2TPv3] 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 [L2TPv3] 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.


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


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


4. Security Considerations

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


5. 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 [L2TPv3] and L2TPv3
    Pseudowire Types in 10.6 of [L2TPv3]) by the IANA (number space
    created as part of publication of [L2TPv3]):

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

          0x0004  Ethernet VLAN Pseudowire Type
          0x0005  Ethernet Pseudowire Type


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.









7. References


7.1. Normative 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,
                 draft-ietf-l2tpext-l2tp-base-14.txt

7.2. Informative References

    [PWE3-ARCH]  Stewart Bryant, Prayson Pate, "PWE3 Architecture",
                 draft-ietf-pwe3-arch-07.txt


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

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

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

    Tissa Senevirathne
    Consultant
    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

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


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 (2004). 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.











Acknowledgement

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


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