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

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

Network Working Group                                   Rahul Aggarwal
Internet Draft                                          XiPeng Xiao
Expiration Date: May 2003                               Redback Networks

                                                        W. Mark Townsley
                                                        Stewart Bryant
                                                        Cisco Systems

                                                        Cheng-Yin Lee
                                                        Alcatel

                                                        Tissa Senevirathne
                                                        Consultant

                                                        Mitsuru Higashiyama
                                                        Anritsu Corporation


              Transport of Ethernet Frames over L2TPv3

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


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


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

Internet Draft draft-ietf-l2tpext-pwe3-ethernet-00.txt        October 2002


Table of Contents

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

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 L2TPv 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-LAYER]. The
   CE in this figure is typically also the L2TPv3 Remote System. The LCCE
   may or may not be a PE.







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

Internet Draft draft-ietf-l2tpext-pwe3-ethernet-00.txt        October 2002


                +---------------------------------------+
                |                 LCCE                  |
      +----+    +-+   +-----+   +------+   +------+   +-+
      |    |    |P|   |     |   |PW ter|   | PSN  |   |P|
      | C  |<==>|h|<=>| NSP |<=>|minati|<=>|Tunnel|<=>|h|<==> PSN
      | E  |    |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. A 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 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.





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

Internet Draft draft-ietf-l2tpext-pwe3-ethernet-00.txt        October 2002


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 AVP
      [L2TPv3] Attribute Type TBA.

   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
      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 session keep-alive mechanism
   of L2TPv3 can serve as a link status monitoring mechanism for the PW
   (i.e. session).

2.3.1 SLI Message

   In addition to the session 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.

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

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





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

Internet Draft draft-ietf-l2tpext-pwe3-ethernet-00.txt        October 2002


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

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.







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

Internet Draft draft-ietf-l2tpext-pwe3-ethernet-00.txt        October 2002


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, where

    N=8,  L2TPv3 data messages are over IP;
    N=16, 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

    For generic security issues regarding PWs and Ethernet PWs, this document
    will eventually refer to documents from the PWE3 WG. L2TP-specific
    Security Considerations are TBD.

5. IANA Considerations

    The signaling mechanisms defined in this document rely upon the
    assignment of a Ethernet port mode and an Ethernet VLAN mode Pseudowire
    Type. IANA assignment of this value should take place within the PWE3 WG.

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

    [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-03.txt

    [L2TP-IANA]  Townsley, M., "L2TP IANA Considerations Update", Internet
                 Draft, draft-ietf-l2tpext-rfc2661-iana-00.txt

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





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

Internet Draft draft-ietf-l2tpext-pwe3-ethernet-00.txt        October 200


    [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",
                 draft-ietf-pwe3-requirements-03.txt

8. Author Information

Rahul Aggarwal
Redback Networks
350 Holger Way
San Jose, CA 95134
e-mail: rahul@redback.com

XiPeng Xiao
Redback Networks
300 Holger Way
San Jose, CA 95134
e-mail: xipeng@redback.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

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

Internet Draft draft-ietf-l2tpext-pwe3-ethernet-00.txt        October 200


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
















































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


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