PWE3 Working Group                                           Tricci So
Internet Draft                                        Caspian Networks
Expiration Date: March 2002                                XiPeng Xiao
                                                         Photuris Inc.
Raj Sharma                                                Loa Anderson
Luminous Networks                                            Utfors AB
David Zelig                                               Chris Flores
Corrigent Systems                                          Nick Tingle
Giles Heron                                            Sunil Khandekar
PacketExchange Ltd.                                   TiMetra Networks



            Ethernet Pseudo Wire Emulation Edge-to-Edge (PWE3)

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

   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 the Psuedo Wire (PW) [Pate][Xiao] service
   specific implementation for Ethernet. An Ethernet PW allows
   Ethernet Protocol Data Units (PDUs) to be carried over Packet
   Switched Networks (PSNs) using IP, L2TP or MPLS transport. This
   will enable Service Providers to leverage their existing PSN to
   offer Ethernet services.

Conventions Used In This Document



So et al                  Expires April 2002                  [Page 1]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   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.

                            Table Of Contents

   1. Introduction...................................................4

   2. Terminology....................................................5

   3. Requirements For Ethernet Pseudo-Wire Emulation................7
      3.1. Point-to-Point Mode.......................................7
      3.2. Multi-point Mode..........................................8
      3.3. Packet Processing.........................................8
         3.3.1. Encapsulation........................................9
         3.3.2. MTU Management.......................................9
         3.3.3. Frame Ordering.......................................9
         3.3.4. Frame Error Processing...............................9
         3.3.5. IEEE 802.3x Flow Control Interworking...............10
         3.3.6. IEEE 802.1Q User Priority Interworking..............10
      3.4. Maintenance..............................................10
         3.4.1. Pseudo-wire Establishment...........................10
         3.4.2. Link State Monitoring...............................11
         3.4.3. Fault Detection & Recovery..........................11
      3.5. Management...............................................12
      3.6. Security.................................................12
      3.7. QoS Consideration........................................13
      3.8. Inter-domain PW Support Consideration....................14
         3.8.1. PSN tunnel establishment............................14
         3.8.2. PW establishment....................................14
         3.8.3. Security Considerations.............................14

   4. Ethernet PW Over MPLS.........................................14
      4.1. Packet Processing........................................15
         4.1.1. Encapsulation.......................................15
         4.1.2. Frame Ordering......................................15
      4.2. Maintenance..............................................15
         4.2.1. Link State Monitoring...............................15
      4.3. Management...............................................15
      4.4. Security.................................................15

   5. Ethernet PW Over IP/GRE.......................................15
      5.1. Packet Processing........................................16
         5.1.1. Encapsulation.......................................16
         5.1.2. Frame Ordering......................................17
         5.1.3. MTU Management......................................17
      5.2. Maintenance..............................................17
         5.2.1. Link State Monitoring...............................18
      5.3. Management...............................................18
      5.4. Security.................................................18
         5.4.1. Forwarding Plane....................................18
         5.4.2. Control Plane.......................................18
      5.5. QoS Consideration........................................18

So et al                  Expires April 2002                  [Page 2]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   6. Ethernet PW Over L2TP.........................................18
      6.1. Packet Processing........................................19
         6.1.1. Encapsulation.......................................19
         6.1.2. Frame Ordering......................................20
         6.1.3. MTU Handling........................................20
      6.2. Maintenance..............................................21
         6.2.1. Pseudo-wire Establishment...........................21
         6.2.2. PW Status Monitoring................................24
         6.2.3. Fault Detection & Recovery..........................24
      6.3. Management...............................................24
      6.4. Security.................................................24
      6.5. QoS Consideration........................................24

   7. Security Considerations.......................................25

   8. Conclusion....................................................25

   9. IANA Consideration............................................25

   10. References...................................................25

   11. Authors' Addresses...........................................28

   Appendix A - Interoperability Guidelines.........................30






























So et al                  Expires April 2002                  [Page 3]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001


1. Introduction

   There is growing interest in using high speed and high performance
   IP and MPLS-enabled IP networks to transport legacy L2
   technologies, such as Ethernet, Frame Relay and ATM as described in
   [Martini-encap], [Martini-trans], [Kompella] and [Rosen].

   This draft defines encapsulation mechanisms to transport Ethernet
   traffic over the Packet Switched Networks (PSNs) using MPLS[MPLS],
   L2TP [L2TPv3] and GRE [GRE-encap][GRE-IPv4] tunnels
   This document defines the PDU processing, maintenance and
   encapsulation behaviors when emulating Ethernet services based on
   the PWE3 architecture[Pate]over a PSN. The scope of the document
   includes:

     - Pseudo-wire (PW) requirements for emulating the Ethernet
        trunking and switching behavior.
     - Setup of the Ethernet PW between PE devices over the PSN
        tunnel
     - Ingress and egress packet processing of Ethernet PDUs
     - Encapsulation of Ethernet PDUs over MPLS, IP/GRE and L2TP
        tunneling mechanisms
     - Transport and delivery of encapsulated packets over
        Ethernet PW
     - Maintenance function and interactions with the PSN tunnel
        for the Ethernet PW
     - QoS and security considerations
     - Inter-domain transport considerations for Ethernet PW

   It is not within the scope of the document to specify how and when
   the PSN tunnel be set up. However, information needed to establish
   PWs over PSN  is specified, as well as suggestions on how such PWs
   are maintained.

   The following two figures describe the reference models which are
   derived from [Pate][Xiao] to support the Ethernet PW emulated
   services.
















So et al                  Expires April 2002                  [Page 4]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

           Native    |<----- Pseudo Wire ---->|  Native
          Ethernet   |                        |  Ethernet
             or      |  |<-- PSN Tunnel -->|  |    or
           VLAN      V  V                  V  V   VLAN
          Service  +----+                  +----+ Service
   +----+    |     | PE1|==================| PE2|     |    +----+
   |    |----------|............PW1.............|----------|    |
   | CE1|    |     |    |                  |    |     |    |CE2 |
   |    |----------|............PW2.............|----------|    |
   +----+    |     |    |==================|    |     |    +----+
        ^          +----+                  +----+     |    ^
        |      Provider Edge 1         Provider Edge 2     |
        |                                                  |
        |<-------------- Emulated Service ---------------->|

      Figure 1: PWE3 Ethernet/VLAN Interface Reference Configuration

    +-------------+                                +-------------+
    |  Emulated   |                                |  Emulated   |
    |  Ethernet   |                                |  Ethernet   |
    | (including  |         Emulated Service       | (including  |
    |  VLAN)      |<==============================>|  VLAN)      |
    |  Services   |                                |  Services   |
    +-------------+           Pseudo Wire          +-------------+
    |Encapsulation|<==============================>|Encapsulation|
    +-------------+                                +-------------+
    |    PSN      |            PSN Tunnel          |    PSN      |
    |IP/MPLS/L2TP |<==============================>|IP/MPLS/L2TP |
    +-------------+                                +-------------+
    |  Physical   |                                |  Physical   |
    +-----+-------+                                +-----+-------+
          |                                              |
          |                IP/MPLS/L2TP Network          |
          |             ____     ___       ____          |
          |           _/    \___/   \    _/    \__       |
          |          /               \__/         \_     |
          |         /                               \    |
          +========/                                 |===+
                   \                                 /
                    \                               /
                     \   ___      ___     __      _/
                      \_/   \____/   \___/  \____/

          Figure 2: Ethernet PWE3 Protocol Stack Reference Model


2. Terminology

   CE
        Customer Edge device, this could be a Customer Edge-Router
        (CE-R) or a Customer Edge-Switch (CE-S).



So et al                  Expires April 2002                  [Page 5]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   COS mark

        The COS field marking at the PSN tunnel level or the VC level.
        For example: TOS field in IP, EXP bits in MPLS shim.

   Multi-point Mode

        A PW that contains an internal switching device to support
        multi-point services, for example TLS.

   PE

        Provider Edge router, the L3 device that interfaces customer
        L3 devices, the PE is the device originating and terminating
        PW's. in an MPLS enabled IP network the PE is the Label Edge
        Router (LER).

   Point-to-Point Mode

        A point-to-point Ethernet PW emulates a single Ethernet link
        between exactly two endpoints.

   PSN

        Packet Switched Network.

   PSN Label

        One or more labels that are pushed on to a packet or frame
        carrying a VC label, when the PSN is MPLS-enabled. PSN labels
        are negotiated hop-by-hop across the PSN. The protocol used to
        negotiated the PSN labels are outside the scope of this
        specification. The bottom of stack bit will always be zero in
        the MPLS shim header of any PSN label.

   PSN tunnel

        A tunnel set up through a PSN to carry Pseudo-wire (PW).

   PW

        Pseudo Wire, a set of tunnels that are used to emulate
        physical or logical wires.

   PWES

        Pseudo Wire End System, an entity within a PE that implements
        the end points of a PW.

   TLS

        Transparent LAN Service is the synonym of  Virtual Private LAN
        Service (VPLS) [VPLS].

So et al                  Expires April 2002                  [Page 6]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001


   VC Label

        The label that will be pushed onto a packet or a frame that
        will be sent from one PE to another. This label is negotiated
        between the PEs. For example, if the MPLS label syntax is used
        for the VC label, this can be done by means of LDP. The bottom
        of stack bit will be set to one in an MPLS shim header that
        includes a VC label.

   VC Tunnel

        A tunnel that reside inside a PSN tunnel and is used to carry
        PW's.


3. Requirements For Ethernet Pseudo-Wire Emulation

3.1. Point-to-Point Mode

   A point-to-point Ethernet PW emulates a single Ethernet link
   between exactly two endpoints. The following reference model
   describes the termination point of each end of the PW within the
   PE:

              +-----------------------------------+
              |                PE                 |
      +---+   +-+  +-----+  +------+  +------+  +-+
      |   |   |P|  |Adapt|  |PW ter|  | PSN  |  |P|
      |   |<==|h|<=|ation|<=|minati|<=|Tunnel|<=|h|<== From PSN
      |   |   |y|  |     |  |on    |  |      |  |y|
      | C |   +-+  +-----+  +------+  +------+  +-+
      | E |   |                                   |
      |   |   +-+  +-----+  +------+  +------+  +-+
      |   |   |P|  |Adapt|  |PW ter|  | PSN  |  |P|
      |   |==>|h|=>|ation|=>|minati|=>|Tunnel|=>|h|==> To PSN
      |   |   |y|  |     |  |on    |  |      |  |y|
      +---+   +-+  +-----+  +------+  +------+  +-+
              |                                   |
              +-----------------------------------+
                          ^        ^
                          |        |
                          A        B

              Figure 3: Point-to-point PW reference diagram

   The PW terminates at a logical port within the PE, defined at point
   A in the above diagram. This port provides an Ethernet MAC service
   that will deliver each Ethernet packet that is received at point A,
   unaltered, to the point A in the corresponding PE at the other end
   of the PW.



So et al                  Expires April 2002                  [Page 7]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   The "Adaptation" function includes packet processing needed to
   translate the Ethernet packets that arrive at the CE-PE interface
   to/from the Ethernet packets that are applied to the PW termination
   point. Such functions may include VLAN-tag stripping, overwriting
   or adding, physical port multiplexing/demultiplexing, PW-PW
   bridging, L2 encapsulation, shaping, policing, etc.

   The points to the left of A, including the physical layer between
   the CE and PE, and any adaptation functions between it and the PW
   terminations, are outside of the scope of PWE3 and are not defined
   here.

   "PW Termination", between A and B, represents the operations for
   setting up and maintaining the PW, and for encapsulating and
   decapsulating the Ethernet packets according to the PSN type in
   use. This document defines these operations, and the services
   offered and required at points A and B.

   "PSN Tunnel" denotes the PSN tunneling technology that is being
   used: either IP/GRE, MPLS or L2TP.

   A point-to-point pseudo wire can be one of the two types: raw and
   tagged. This is a property of virtual Ethernet link and indicates
   whether the pseudo wire MUST contain an 802.1Q VLAN field (i.e.
   tagged mode or may/may not contain a tag (i.e. raw mode).

   The rest of this chapter describes the service at A and the PW
   Termination behavior that are common to all PSN types. Subsequent
   chapters describe the specific mechanisms unique to each PSN type.

3.2. Multi-point Mode

   A multi-point Ethernet PW would emulate a whole Ethernet segment.
   This segment could be broadcast (like a piece of coax) or switched
   (like an 802.1D bridge [802.1D]). The reference diagram of section
   3.1 would still apply, with the following additions:

     - There would be more PSN destinations to the right, to
        represent the additional endpoints of the PW.

     - The PW termination function would have to include
        mechanisms for selecting the correct egress PE(s)     (and
        hence PSN tunnel(s)) for each Ethernet packet presented to the
        PW. This could involve replication and/or MAC address
        learning.

   As there are alternative mechanisms for providing virtual Ethernet
   segments using multiple point-to-point Ethernet PWs and a suitable
   Adaptation function (e.g. see [Vkompella]), the multipoint Ethernet
   PW is not addressed further in this document.

3.3. Packet Processing


So et al                  Expires April 2002                  [Page 8]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

3.3.1. Encapsulation

   The entire Ethernet frame without the preamble or FCS is
   transported as a single packet. PSN-specific tunnel identifiers are
   prepended to this.

   In the multi-point case where the egress PE needs to know which
   ingress PE forwarded the packet this information must be derived
   from the PW-specific tunnel identifiers. In the MPLS case this
   implies that a separate VC label be assigned to each ingress PE.
   With such consideration, the following implications shall be
   examined, i.e.

     - It implies the use of the global VC label pool per node, and

     - It may limit the selection of the VC label distribution
        approach.

   In the IP case this information can be derived from the source IP
   address of the packet. In the L2TP case this can be derived from
   the Session ID in the received packet.

3.3.2. MTU Management

   Ingress and egress PWESes MUST agree on their maximum MTU size to
   be transported over the PSN. The consideration of the MTU size
   management can be referred to Appendix-A. Each PSN-specific PWE
   approach will determine if the Segmentation and Reassembly (SAR)
   will be supported, and if so, what the mechanism should be.

3.3.3. Frame Ordering

   In general, applications running over Ethernet do not require
   strict frame ordering. However the IEEE definition of 802.3 [802.3]
   requires that frames from the same conversation are delivered in
   sequence. Moreover, the PSN cannot (in the general case) be assumed
   to provide or to guarantee frame ordering. Therefore if frame
   ordering is required, a sequence number MUST be implemented and
   utilized.

   The sequence number mechanism is PSN-specificand will be described
   in the PSN-specific section, if supported.

3.3.4. Frame Error Processing

   An encapsulated Ethernet frame traversing a psuedo-wire can be
   dropped, corrupted or delivered out-of-order. Per [Xiao], packet-
   loss, corruption, and out-of-order delivery is considered to be a
   "generalized bit error" of the psuedo-wire. Therefore, the native
   Ethernet frame error processing mechanisms MUST be extended to the
   corresponding psuedo-wire service. Meaning, if an ingress device
   receives a standard Ethernet frame containing hardware level CRC


So et al                  Expires April 2002                  [Page 9]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   errors, framing errors, or a runt condition, the frame MUST be
   discarded on input.

3.3.5. IEEE 802.3x Flow Control Interworking

   In a standard Ethernet network, the flow control mechanism is
   optional and typically configured between the two nodes on a point-
   to-point link (e.g. between the CE and the PE). IEEE 802.3x PAUSE
   frames MUST NOT be carried across the PW. See Appendix A for notes
   on CE-PE flow control.

3.3.6. IEEE 802.1Q User Priority Interworking

   The ingress router MAY consider the user priority field [802.1Q] of
   the VLAN tag header when determining the value to be placed in the
   Quality of Service field of the encapsulating protocol (e.g., the
   EXP fields of the MPLS label stack). In a similar way, the egress
   router MAY consider the Quality of Service field of the
   encapsulating protocol when queuing the packet for egress.

3.4. Maintenance

   This section describes the PW link maintenance requirements in a
   point-to-point configuration.

   For the requirements described below, if possible, it is desirable
   to have a common mechanism (e.g. signaling protocol) to meet those
   requirement objectives across various PSN types (i.e. MPLS, IP/IP,
   GRE, L2TP etc.) regardless of the type of maintenance functions
   such as link establishment or auto-discovery etc. One example is to
   use MP-BGP [MP-BGP] to auto-discover various PWESs at each PE and
   to distribute the PSN tunnel label; and to use LDP to distribute
   the PW's label across each PSN.

3.4.1. Pseudo-wire Establishment

   An Ethernet PW can be established over a PSN either via
   configuration or via some sort of signaling mechanism, e.g. LDP,
   MP-BGP etc., whichever is applicable to the underlying PSN.

   If available, an auto-discovery mechanism, which may be associated
   with some signaling mechanism (e.g. LDP, MP-BGP) or some server
   based solution (e.g. DNS), can be used to identify the Ethernet PW
   types (e.g. native Ethernet or VLAN type) among the PE peers across
   the PSN. It is expected that when a PW is established between the
   PEs, the Ethernet PW types are compatible at each end of the PW,
   i.e. tagged to tagged or raw to raw.

   Multiple PWs can be set up within the same PSN tunnel and
   therefore, the PE/PWES is required to have an ability to support a
   mechanism to multiplex and de-multiplex the various PW instances.
   The VC label for an Ethernet PW instance shall be unique at least


So et al                  Expires April 2002                 [Page 10]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   within the same PSN tunnel so that misrouting of the Ethernet
   packet can be prevented.

   In the case when 802.1p [802.1p] support is required, a COS mapping
   mechanism (e.g. MPLS EXP field and IP Diffserv DSCP mapping) shall
   be configured at each PE. The policy of the service mapping between
   the PW and the PSN tunnel is outside the scope of this
   specification.

3.4.2. Link State Monitoring

   It is desirable to detect Ethernet PW failure at the PE which is
   caused either by the PW itself or by the PSN in a timely manner.
   The performance monitoring objective is a network policy and is not
   within the scope of this specification.

   Since Ethernet provides a bi-directional link, Ethernet PWs are bi-
   directional PWs. Note that the Ethernet PW may be carried over
   unidirectional PSN tunnels.

   The PW is considered to be active if all the following are true:

   1. The local PWES is active.
   2. The remote PWES is active.
   3. The PSN tunnel used to transport the PW to the remote PE is
       up.
   4. The PSN tunnel used to transport the PW from the remote PE
       is up.

   In order to enable the remote PE to know the status of the local
   PWES, a PE which is using a maintenance mechanism to establish PWs
   MUST use its maintenance channel to the remote PE to gracefully
   withdraw the PW label prior to the local PWES goes down. In the
   case of manually configured PWs there is no such maintenance
   channel and thus the remote PE will be unaware of the local PWES
   status - and must assume it to be active.

   The status of the PSN tunnels to and from the remote PE is not
   always known. PSN-specific considerations are detailed in the
   relevant sections below.

   In the case when there is a high volume of Ethernet PWs across the
   PSN, a bundling approach can be used to enhance the scalability of
   the PW link state monitoring and error reporting.

   Another aspect of the link state monitoring is to detect mis-
   routing, i.e. routing traffic from one PW to another PW, due to the
   corruption of forwarding table. This is especially essential when
   the PSN tunneling mechanism is connectionless based. Mechanism like
   Trace Route would be very useful for detecting failure condition.

3.4.3. Fault Detection & Recovery


So et al                  Expires April 2002                 [Page 11]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   Unlike some other transmission technologies, e.g. SONET/SDH,
   Ethernet does not have a specific standard performance requirement
   for fault detection and recovery. The requirement on an Ethernet PW
   is that its reliability performance is identical to standard
   Ethernet, the performance indicators for this is for further study.

   It is important to be able to detect failures that have an impact
   on the Ethernet PW. There are three types of failures that needs to
   be detected:

     1. PSN tunnel failures
     2. VC tunnel failures
     3. PWES failures

   The detection and diagnostics of these failures requires a co-
   ordination between the PSN tunnel, the VC-tunnel and the PWES.

   When triggering recovery mechanisms for tunnels that carries an
   Ethernet PW, one must consider the bi-directional nature of the
   Ethernet PW, and therefore, even if the PSN tunnel is uni-
   directional, it shall be transparent to the Ethernet PW.

   It is possible that network may provide primary and secondary PSN
   tunnels to ensure fast recovery. In such case, the expected
   behavior shall be described of how to perform the failover for the
   Ethernet PW.

3.5. Management

   The PW management model of Ethernet PW follows the general
   management guidelines for PW management as appear in [PW-MIB] and
   defined in [Xiao][Pate]. It is composed of 3 components. [PW-MIB]
   defines the parameters common to all types of PW and PSNs, for
   example common counters, error handling, some maintenance protocol
   parameters etc. For each type of PSN there is a separate module
   that defines the association of the PW to the PSN tunnel, see
   example in [PW-MPLS-MIB] for the MPLS PSN. For Ethernet PW,
   additional MIB module defines the Ethernet specific parameters
   required to be configured or monitored. A MIB module for Ethernet
   service will be available soon.

   The above modules enable both manual configuration and the use of
   maintenance algorithm to set up the Ethernet PW and monitor PW
   state where applicable.

   As specified in [Xiao][Pate], an implementation SHOULD support the
   relevant PW MIB modules for PW set-up and monitoring. Other
   mechanisms for PW set up (command line interface for example) MAY
   be supported.

3.6. Security



So et al                  Expires April 2002                 [Page 12]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   This document specifies the security consideration regarding the
   encapsulations and maintenance (signaling) for setting up the PW.
   In terms of encapsulation, security of the encapsulated packets
   depends on the nature of the protocol that is carried by these
   packets, while the encapsulation itself shall not affect the
   related security issues. The signaling extensions as the result of
   the PW support shall not change nor introduce any security issue
   related to the existing protocols.

   Nevertheless, the security limitations of the PE and/or the PW MUST
   not restrict the security implementation choices of the user of the
   PWE3 (i.e. users should be able to implement IPSEC or any other
   appropriate security mechanism in addition to the security inherent
   in the PW)".

   It is required that PEs will have user separation between different
   PW and different virtual ports that the PWs are connected to. For
   example: if two PWs are connected to the same physical port and
   associated to different virtual ports (i.e. VLANs), it is required
   that packets from one VC will not be forwarded to the VLAN that is
   associated to the second VCs.

   A received packet is associated with a PW by means of the VC label.
   However this mechanism provides no guarantee that the packet was
   sent by the peer PE. Further checks may be useful to protect
   against mis-configuration and connection hijacking.

   The PE must be able to be protected from malformed, or maliciously
   altered, customer traffic. This includes, but is not limited to,
   illegal VLAN use, short packets, long packets, etc.

   Security achieved by access control of MAC addresses is out of
   scope of this document.

   Additional security requirements related to the use of PW in a
   switching (virtual bridging)is not discussed here.

3.7. QoS Consideration

   A PE MUST support the ability to carry the Ethernet PW as a best
   effort service over the PSN. Transparency of PRI bits (if exist
   originally) between edges MUST be preserved, regardless of the COS
   support at the PSN. In case of adding VLAN field at the edges, a
   default PRI setting of zero MUST be supported, configured default
   value is recommended.

   A PE may support additional QOS support by means of one or more of
   the following method:

     1. One COS per PW end service (PWES), mapped to a single COS PW
        at the PSN.



So et al                  Expires April 2002                 [Page 13]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

     2. Multiple COS per PWES mapped to a single PW with multiple COS
        at the PSN.

     3. Multiple COS per PWES mapped to multiple PWs at the PSN.

   Examples of the cases above and details of the service mapping
   consideration are described in Appendix-B.

   The PW guaranteed rate at the PSN level is PW provider policy based
   on agreement with the customer, and may be different from the
   Ethernet physical port rate. Consideration of Ethernet flow control
   was discussed in 3.3.5.  The mechanism to coordinate the
   transmission rate between the two PWESs will be discussed in more
   details in the PSN specific session, if supported.

3.8. Inter-domain PW Support Consideration

   In the inter-domain case the requirements above all continue to
   apply.

3.8.1. PSN tunnel establishment

   In the GRE and L2TP cases the PSN tunnel is implicitly formed from
   a (source, destination) IP address pair (as mentioned above.)  For
   inter-domain operation both these IP addresses SHOULD be globally-
   unique (i.e. NIC assigned) addresses.

   In the MPLS case the PSN tunnel is explicitly signaled, using a
   label distribution protocol. In order to support inter-domain
   operation the FEC for the PE SHOULD correspond to a globally-unique
   address. Furthermore a label distribution protocol suitable for
   inter-domain operation (e.g MP-BGP) should be used at edge of each
   autonomous system in the path.

3.8.2. PW establishment

   If a signaling mechanism is used to establish the PW then the
   protocol chosen MUST be suitable for inter-domain operation.
   Furthermore, the identifier used for the PW SHOULD be globally
   unique.

3.8.3. Security Considerations

   In the case of a PW crossing from one autonomous system to another,
   through a private interconnection, security considerations are much
   the same as in the intra-domain case. However in some cases the PW
   may travel through a third-party autonomous system, or across a
   public interconnection point. In these cases there may be a
   requirement to encrypt the user data using a method appropriate to
   the PSN tunneling mechanism.

4. Ethernet PW Over MPLS


So et al                  Expires April 2002                 [Page 14]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   Ethernet PW packets are encapsulated over an MPLS network using the
   mechanisms defined in [Martini-encap].


4.1. Packet Processing

4.1.1. Encapsulation

   Ethernet PW packets are encapsulated in the "Ethernet VLAN" mode of
   [Martini-encap] for tagged PWs, and in the "Ethernet" mode of
   [Martini-encap] for raw PWs.

4.1.2. Frame Ordering

   If frame ordering must be preserved then the control word defined
   in [Martini-encap] is used. Since the minimum length of an Ethernet
   frame is 60 octets, and since the control word length field
   includes the length fo the control word itself (4 octets), the
   length field of the control word will always be set to zero (as
   will the reserved and flag bits.)

   The default case for Ethernet PW is to operate without a control
   word.

4.2. Maintenance

   The procedures defined in [Martini-trans] MUST be used for
   maintenance of Ethernet PWs carried over MPLS.

4.2.1. Link State Monitoring

   The PSN tunnel to the remote PE is considered to be up if there is
   a valid label to reach the remote PE.

   If LDP is being used to distribute the PSN tunnel label then there
   is no way to know if the PSN tunnel from the remote PE is up.
   However is RSVP-TE or CR-LDP is used to distribute the PSN tunnel
   label then the status of this tunnel is known.

4.3. Management

   The management procedures are as defined above. Note that [PW-MPLS-
   MIB] defines the mapping from the PW to the MPLS tunnel.

4.4. Security

   This draft does not affect the underlying security issues of MPLS
   (as specified in [MPLS]). Additional security measures MAY be used
   if the lookup process of the PW will include both PSN label and VC
   label in case of global VC labels. See [PW-MPLS-MIB] for more
   details.

5. Ethernet PW Over IP/GRE

So et al                  Expires April 2002                 [Page 15]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001


   Ethernet PW packets are encapsulated over an IP network using the
   Generic Routing Encapsulation protocol as specified in [GRE-encap,
   GRE-IPv4].

   Note: an alternative method of encapsulating Ethernet PW packets
   over IP is to use the MPLS encapsulation (see chapter 4) and an
   MPLS-in-IP protocol  as described in [Rekhter][Worster].

5.1. Packet Processing

5.1.1. Encapsulation

   An Ethernet packet is encapsulated into a single IP packet as shown
   below:

                    ---------------------------------
                    |                               |
                    |       IP Header               |
                    |                               |
                    ---------------------------------
                    |                               |
                    |       GRE Header              |
                    |                               |
                    ---------------------------------
                    |                               |
                    |       Ethernet Packet         |
                    |                               |
                    ---------------------------------

                      Figure 5: Ethernet Over IP/GRE

   The IP header is constructed as follows:

           IP Protocol     47h (GRE)
           IP Source       Source PE
           IP Dest         Dest PE
           IP Flags (v4)   DF (don't fragment)
           IP DSCP/CoS     Mapped from PW CoS

   The Source Address in the IP header can be used to identify the
   sending PE, if necessary.

   The GRE header MUST NOT have the optional Checksum field, MUST
   contain the optional Key field, and MAY have the optional Sequence
   Number field, as follows:








So et al                  Expires April 2002                 [Page 16]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C| |K|S| Reserved0       | Ver |         Protocol Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Key                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Sequence Number (Optional)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 6: IP/GRE Header

   Thus
                   C = 0
                   K = 1
                   S = 0 (sequence number not present)
                       1 (sequence number present)

   The Protocol Type field is set to a number to be allocated by IEEE
   for this purpose.
   The Key field contains the PW label that is assigned by the
   destination PE. The field is right-aligned and padded with zeros if
   necessary. The PW label is used as a demultiplexing field to allow
   multiple PWs between pairs of PEs. The egress PE should assign a PW
   label that will allow it to determine which PW an arriving packet
   belongs to.

   The Sequence Number field (if present) is used as described in
   RFC2890 to maintain or guarantee packet ordering within a
   particular PW.

5.1.2. Frame Ordering

   The normative statements in RFC2890 apply as written to the sending
   and receiving PEs. In particular a receiving PE MUST correctly
   parse a GRE packet containing a sequence number,
   even if it is unable to provide sequencing.

5.1.3. MTU Management

   Techniques such as Path MTU Discovery [MTU] may be used to
   determine the MTU of the IP/GRE Tunnel. Alternatively the MTU may
   be statically configured, or configured per destination PE.

   The sending PE MUST NOT fragment an IPv4 packet containing an
   Ethernet PW PDU, and MUST set the DF bit in the IPv4 header.

5.2. Maintenance

   Any Ethernet PW maintenance protocol that allows the distribution
   of PW labels may be used. Other generic attributes that may be
   validated include MTU, sequencing preference, trunking mode, etc.
   The specific maintenance protocols and procedures are not defined
   here.

So et al                  Expires April 2002                 [Page 17]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001


   IP protocols such as ICMP ping may be used to verify PW
   connectivity for all the PWs between a pair of PEs.

5.2.1. Link State Monitoring

   The PSN tunnel to the remote PE is considered to be up if there is
   a valid route to reach the remote PE. There is, however, no way to
   determine if the PSN tunnel from the remote PE is up.

5.3. Management

   Generic management procedures apply.

5.4. Security

5.4.1. Forwarding Plane

   The nature of the IP/GRE encapsulation means that it would be
   relatively easy for an external intruder to spoof packets that
   appeared to belong to a particular PW. The receiving PE SHOULD
   verify that the source PE IP address corresponds to the expected
   source IP address for the PW, and filtering of source-spoofed
   packets from outside a trusted domain may be necessary.

   Another issue is the ability of IP/GRE PW packets to escape from a
   trusted domain due to transient routing changes/errors or an attack
   on the routing protocols themselves. To protect this it may be
   necessary to install filters to prevent IP/GRE Ethernet
   PW packets from leaving the domain.

   Additionally or alternatively, IP security procedures such as IPSec
   may be used to further enhance the security of all PWs between a
   pair of PEs. This most likely be a requirement
   for inter-domain PWs.

5.4.2. Control Plane

   In the control plane, generic maintenance security procedures
   apply.

5.5. QoS Consideration

   The IP Diffserv model is used to provide differential class of
   service to different PWs, or to different packets within the PW.
   The mapping of Ethernet CoS markings to/from Diffserv codepoints is
   a local configuration matter, but must follow the requirements in
   section 3.7.

6. Ethernet PW Over L2TP

   This section describes how to provide Ethernet PWE over L2TPv3.


So et al                  Expires April 2002                 [Page 18]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   [L2TP] was originally designed for tunneling PPP sessions. [L2TPv3]
   separates out mechanisms designed specifically for PPP and provides
   new extensions for tunneling generic layer-2 protocols such as
   Ethernet, ATM and Frame Relay.

   To provide Ethernet PWE between two PEs, an L2TPv3 control
   connection can be established first. Individual L2TPv3 sessions can
   then be established via signaling. Alternatively, L2TPv3 sessions
   can be manually configured without requiring a control connection.
   Each session can be used as a PW to connect two Ethernet ports or
   VLANs.

6.1. Packet Processing

6.1.1. Encapsulation

   The entire Ethernet frame without the preamble or FCS is
   encapsulated in L2TPv3 and is sent as a single packet. This is done
   regardless of whether an 802.1Q tag is present in the Ethernet
   frame or not.

                    +-------------------------------+
                    |       L2TPv3 Header           |
                    +-------------------------------+
                    |       Ethernet frame          |
                    +-------------------------------+

                      Figure 7: Ethernet over L2TPv3

   An L2TPv3 data packet can be sent as over UDP or directly over IP.
   The selection of UDP vs. IP is beyond scope of this document.

   L2TPv3 data channels do not provide reliable or in-order delivery.
   There is no sequence number field in an L2TPv3 header. If in-order
   delivery for Ethernet frames is desired, an optional 4-octet
   control word can be inserted between the L2TPv3 header and the
   encapsulated Ethernet frame. The format of the control word is
   identical to the control word defined in [Martini-encap]. The usage
   of the control word fields is identical to what is defined in
   [Martini-encap], except that the length field MUST be set to zero
   at the ingress PE and be ignored at the egress PE. The
   presence/non-presence of the control word for a particular PW
   session is signaled during setup of the PW. The signaling process
   is described in Section 6.2.

   After the encapsulation, the whole packet is as follows:

    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 (optional, up to 64 bits)           |

So et al                  Expires April 2002                 [Page 19]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Control word (optional)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Tunneled Ethernet Frame                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 8: Encapsulation of Ethernet frames over L2TPv3

   A session ID uniquely identifies a PW. It is used to multiplex and
   de-multiplex PWs between two PEs. Session IDs only have local
   significance. That is, the same PW will be given different Session
   IDs by each PE. The Session ID specified in each message is that of
   the intended recipient, not the sender [L2TPv3].

   A cookie field is used to check the association of a received data
   packet with the PW identified by the Session ID. The cookie guards
   against the misrouting of data packets, which could result if the
   incorrect Session ID is specified in received packets (due to mis-
   configuration, header corruption, or otherwise) [L2TPv3].

6.1.2. Frame Ordering

   In cases where in-order delivery of Ethernet frames is critical,
   the control word can be used. The sequence number field in the
   control word can be used to detect out-of-order delivery. The
   generation and processing of the sequence number at the ingress and
   egress PEs, respectively, are identical to what are defined in
   [Martini-encap]. The presence of a control word is signaled during
   setup of the L2TPv3 session for this PW. The signaling process is
   described in Section 6.2.

6.1.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, without a control word and L2TPv3 data messages are over IP;
   N=12, with a control word and L2TPv3 data messages are over IP;
   N=16, without a control word and L2TPv3 data messages are over UDP;
   N=20, with a control word and L2TPv3 data messages are over UDP;
   (N does not include the IP header).

   In order to avoid fragmentation, ideally the PSN should be
   configured with an MTU that is larger than or equal to the largest
   Ethernet frame size (without the preamble or FCS) plus 20 bytes. If
   the PSN cannot support such a MTU, another option is to set the MTU
   size of the two Ethernet ports between the PEs and the CEs to
   (network_MTU - 20). This may imply that Ethernet jumbo frame cannot
   be used.




So et al                  Expires April 2002                 [Page 20]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   If the PSN cannot be configured with a sufficiently large MTU to
   avoid fragmentation, Ethernet PWE over L2TPv3 can rely on IP
   fragmentation.

6.2. Maintenance

6.2.1. Pseudo-wire Establishment

   With L2TPv3 as the tunneling protocol, Ethernet PWs are L2TPv3
   sessions. There are two ways to set up L2TPv3 sessions:

   (1)  Manual configuration;
   (2)  Establishing an L2TPv3 control connection first and then
        establishing of individual sessions via signaling. The
        procedure is defined in [L2TPv3]. In order for an L2TPv3
        control connection to support Ethernet PWs, it must be
        signaled to support Ethernet VLAN and Ethernet ports. This is
        done using the "Pseudo-wire capability list" Attribute-Value
        Pair (AVP).

6.2.1.1. Control Connection Establishment

   If a control connection is to be established, the possible types of
   PW sessions associated with this control connection MUST be
   negotiated first. This is done using the Pseudo Wire Capabilities
   List AVP that indicates the L2 payload types that will be accepted
   by the PE that originates this control message. The Attribute Value
   field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Pseudo Wire Type 0       |             ...               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              ...              |      Pseudo Wire Type N       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Defined Pseudo Wire Types that may be included in the Pseudo Wire
   Capabilities List are as follows (pending IANA approval):

   Legal "Pseudo Wire Types" that may be included in the Pseudo Wire
   Capabilities List are defined below (pending IANA approval):

      0x0004 - Sessions without control word for connecting Ethernet
               VLANs are allowed
      0x0005 - Sessions without control word for connecting Ethernet
               ports are allowed
      0x8004 - Sessions with control word for connecting Ethernet VLANs
               are allowed
      0x8005 - Sessions with control word for connecting Ethernet ports
               are allowed



So et al                  Expires April 2002                 [Page 21]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   Note that the most significant bit of the "Pseudo-Wire Type" field
   is used to indicate the presence/non-presence of a control word in a
   PW session. If the bit is set, a control word is present. Otherwise,
   it is not.

6.2.1.2. PW session establishment

   Pieces of information needed for each PW session are described
   below. Such information is either manually configured at the
   ingress and egress PEs, or dynamically signaled with L2TPv3 AVPs.

   - Pseudo Wire Type

   The type of a PW can be either "Ethernet port" or "Ethernet VLAN".

   If signaling is used, the "Pseudo Wire Type" AVP, Attribute Type
   TBA, indicates the payload type for a PW.

   The Attribute Value field for this AVP has the following format:

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Pseudo Wire Type        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   "Pseudo wire type" values are defined in Section 6.2.1.1.

   A PE MUST NOT request to set up a PW with a "Pseudo wire type" AVP
   specifying a value not advertised in the "Pseudo Wire Capabilities
   List" AVP it received during control connection establishment.
   Attempts to do so will result in the failure of PW setup.

   - Presence/non-presence of control word

   If the presence/non-presence of control word for a PW session is to
   be signaled, then:

     - If the two Pseudo-Wire End Services (PWES's) are Ethernet
        VLANs, the presence/non-presence of control word can be
        signaled by using the value 0x0004 or 0x8004, respectively.

     - If the two PWES's are Ethernet ports, the presence/non-
        presence of control word can be signaled by using the value
        0x0005 or 0x8005, respectively.

   That is, the most significant bit, i.e. the C bit, of the "Pseudo-
   Wire Type" field is used to indicate the presence/non-presence of
   the control word in a PW. If the bit is set, the control word is
   present. Otherwise, it is not.




So et al                  Expires April 2002                 [Page 22]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   - PW ID

   Each PW is associated with a PW ID. The two PEs of a PW have the
   same PW ID for it. Together with the Pseudo-Wire Type, a PW ID
   uniquely identifies a PW session at every PE. A new L2TPv3 AVP will
   be defined for signaling the PW ID.

   - Group ID

   A Group ID is used for referring to a group of PWs so that they can
   be signaled down collectively. The L2TPv3 "Private Group ID" AVP
   can be used for signaling the Group ID.

   - PWES parameters

   Three parameters are defined for each Ethernet PWES. They can be
   used for detecting mismatch between the two PWES's of a PW.

        + Description string

        This is an informational description string for a PWES. For
        example, if the local PWES is VLAN 100 of interface GE 1/1 on
        PE1, then the description string of the PW can be "PE1-GE1/1-
        VLAN100")

        A new L2TPv3 AVP will be defined for signaling this
        description string.

        + MTU

        This parameter specifies the MTU size of the local PWES. It
        can be used for detecting MTU mismatch of the two PWES's of a
        PW. MTU mismatch SHOULD be logged if identified.

        A new L2TPv3 AVP will be defined for signaling the MTU of a
        PWES.

        + Speed

        This parameter specifies the Send and Receive speed of the
        PWES. That is, speed of an Ethernet PW is assumed to be
        symmetric. The speed of a PWES should not be higher than the
        speed of the physical port. The speed specification is mainly
        for informational purpose, e.g., for detecting speed mismatch
        of the two PWES's. An example of speed mismatch is: one PWES,
        a VLAN, is specified to have speed 20Mbps (possibly via rate-
        limiting) and the other PWES, another VLAN, is specified to
        have speed 40Mbps. Speed mismatch SHOULD be logged if
        identified.

        The L2TPv3 "Connect Speed" AVP can be used for signaling the
        speed of a PWES.


So et al                  Expires April 2002                 [Page 23]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

6.2.2. PW Status Monitoring

   The working status of a PW is reflected by the state of the L2TPv3
   session. If the corresponding L2TPv3 session is down, both PWES's
   associated with it MUST be shut down.

   If a control connection is used, and the control channel and the
   data channels operate in-band, the keep-alive mechanism of L2TPv3
   can serve as a link status monitoring mechanism for the PWs (i.e.
   sessions) associated with that control connection. If the control
   channel and the data channels operate out-of-band, an L2TPv3 data
   session may be dedicated for sending keep-alive information
   [Editor's note: details will be provided in the next version of the
   draft].

   If one of the PWES is down, Ethernet PWE MUST treat it as an L2TPv3
   "local close request" and tear down the PW associated with that
   PWES. When the remote PE cleans the state for the PW, it MUST shut
   down the PWES associated with it.

6.2.3. Fault Detection & Recovery

   An Ethernet PW can incur loss, corruption, and out-of-order delivery
   of data packets. Packet loss, corruption, and out-of-order delivery
   can be considered as "generalized packet error" of an Ethernet PW.
   If the "generalized packet error" rate is higher than a configurable
   threshold, the PW MUST be signaled down with this reason explained
   in the "Result Code" AVP. The two PWES's MUST also be shut down.

6.3. Management

   An Ethernet pseudo-wire emulation MIB will be defined in a
   companion draft.

6.4. Security

   Ethernet pseudo-wire emulation does not affect the underlying
   security issues of L2TPv3 [Section 9, L2TPv3].

6.5. QoS Consideration

   L2TPv3 provides reliable delivery for control messages. This
   reliable delivery mechanism is provided at the two L2TPv3 endpoints
   (i.e., L2TPv3 Control Connection Endpoint, or LCCE). More
   specifically, this is done by:

     1. Each L2TPv3 will acknowledge receipt of a control message;

     2. If the sender of a control message does not receive an
        acknowledgement, it will retransmit.

   This reliable delivery mechanism does not rely on any QoS mechanism
   of the PSN.

So et al                  Expires April 2002                 [Page 24]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001


   There is no reliable delivery mechanism for data messages.

   By default, the control and data messages will receive best effort
   service inside the PSN. It is possible to use DiffServ and other
   traffic management mechanisms to provide better service quality to
   these messages. It is also possible to provide better service
   quality to the control messages than to the data message. What
   service quality to provide inside the PSN for the control messages
   and data messages depends on the domain policy of the PSN and is
   outside scope of this document.

7. Security Considerations

   To Be Completed


8. Conclusion

   To Be Completed


9. IANA Consideration

   This section defined four Pseudo-Wire Types. The specific values
   used for these types are pending IANA approval. The PWE3 WG needs
   to work with the L2TP WG to agree on these numbers as well.

      0x0004 - Ethernet VLAN, without a control word
      0x0005 - Ethernet port, without a control word
      0x8004 - Ethernet VLAN, with a control word
      0x8005 - Ethernet port, with a control word


10. References

   IETF RFC

   [MP-BGP]       Bates, T., Rekhter, Y., Chandra, R., and Katz, D.,
                  "Multiprotocol Extensions for BGP-4", RFC 2858, June
                  2000

   [GRE-encap]    Hanks, S., Li, T., Farinacci, D., "Generic Routing
                  Encapsulation (GRE)", RFC 1701, October 1994.

   [GRE-IPv4]     Hanks, S., Li, T., Farinacci, D., Traina, P.,
                  "Generic Routing Encapsulation over IPv4 networks",
                  RFC 1702, October 1994.

   [L2TP]         Townsley, W., Valencia, A., Rubens, A., Singh Pall,
                  G., Zorn, G., Palter, B., "Layer Two Tunneling
                  Protocol (L2TP)", RFC 2661 August 1999


So et al                  Expires April 2002                 [Page 25]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   [LDP]          Andersson, L., Doolan, P., Feldman, N., Fredette,
                  A., Thomas, B., "LDP Specification", RFC 3036,
                  January 2001.

   [MPLS]         Rosen, E., Viswanathan, A., Callon, R.,
                  "Multiprotocol Label Switching Architecture", RFC
                  3031, January 2001.

   [MTU]          Mogul, J., Deering, S., "Path MTU Discovery", RFC
                  1191, November 1990.

   IETF Drafts

   [ATM]          T.B.D.

   [CEM]          Pate, P., Cohen, R., Zelig, D., "TDM Service
                  Specification for Pseudo-Wire Emulation Edge-to-edge
                  (PWE3)", (draft-pate-pwe3-tdm-00.txt), work in
                  progress, March 2002.

   [FR]           Kawa, C., Malis, A., Pate, P., Bhat, R., Vasavada,
                  N., "Frame relay over Pseudo-Wire Emulation Edge-to-
                  Edge", (draft-kamapabhava-fr-pwe3-00.txt), work in
                  progress, March 2002.

   [Heron]        Heron, G., Wilder, R., Heinanen, J., Soon, T.,
                  Martini, L., Kompella, V., Regan, J., Khandekar, S.,
                  "Requirements for Virtual Private Switched
                  Networks", (draft-heron-ppvpn-vpsn-reqmts-00.txt),
                  work in progress, July 2001.

   [Kompella]     Kompella, K., Leelanivas, M., Vohra, Q., Bonica, R.,
                  Metz, E., Ould-Brahim, H., Achirica, J.,
                  Liljenstolpe, C., Sargor, C., Srinivasan, V., Zhang,
                  Z., "MPLS-based Layer 2 VPNs", (draft-kompella-
                  ppvpn-l2vpn-00.txt), work in progress, July 2001.

   [L2TPv3]       Lau, J., Townsley, M., Valencia, A., Zorn, G.,
                  Goyret, I., Pall, G., Rubens, A., Palter, B., "Layer
                  Two Tunneling Protocol "L2TP"", (draft-ietf-l2tpext-
                  l2tp-base-01.txt), work in progress, July 2001.

   [Martini-encap]
                  Martini, L., El-Aawar, N., Tappan, D., Rosen, E.,
                  Jayakumar, J., Vlachos, D., Liljenstolpe, C., Heron,
                  G., Kompella, K., Vogelsang, S., Shirron, J., Smith,
                  T., Radoaca, V., Malis, A., Sirkay, V., Cooper, D.,
                  "Encapsulation Methods for   Transport of Layer 2
                  Frames Over IP and MPLS Networks", (draft-martini-
                  l2circuit-encap-mpls-03.txt), work in progress, July
                  2001.



So et al                  Expires April 2002                 [Page 26]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   [Martini-trans]
                  Martini, L., El-Aawar, N., Tappen, D., Rosen, E.,
                  Hamilton, A., Jayakumar, J., Vlachos, D.,
                  Liljenstolpe, C., Heron, G., Kompella, K.,
                  Vogelsang, S., Shirron, J., Smith, T., Radoaca, V.,
                  Malis, A., Sirkay, V., Cooper, D., "Transport of
                  Layer 2 Frames      Over MPLS", (draft-martini-
                  l2circuit-trans-mpls-08.txt), work in progress, July
                  2001.

   [Pate]         Pate, P., Xiao, X., So, T., Malis, A., Nadeau, T.,
                  White, C., Kompella, K., Johnson, T., "Framework for
                  Pseudo Wire Emulation Edge-to-Edge (PWE3)" (draft-
                  pate-pwe3-framework-02.txt), work in progress, July
                  2001.

   [PW-MIB]       Zelig, D., Mantin, S., Nadeau, T., Danenbert, D.,
                  Malis, A., "Pseudo Wire (PW) Management Information
                  Base Using SMIv2", (draft-zelig-pw-mib-00.txt), work
                  in progress, July 2001.

   [PW-MPLS-MIB]  Danenberg, D., Park, S., Nadeau, T., Zelig, D.,
                  Malis, A., , "SONET/SDH Circuit Emulation Service
                  Over MPLS (CEM) Management Information Base Using
                  SMIv2", (draft-danenberg-pw-cem-mib-00.txt), work in
                  progress, July 2001.

   [Rekhter]      Rekhter, Y., Tappen, D., Rosen, E., " MPLS Label
                  Stack Encapsulation in GRE", (draft-rekhter-mpls-
                  over-gre-03.txt), work in progress, February 2002.

   [Rosen]        Rosen, E., Filsfils, C., Malis, A., Vogelsang, S.,
                  Heron, G., Martini, L., "An Architecture for
                  L2VPNs", (draft-ietf-ppvpn-l2vpn-00.txt), work in
                  progress, July 2001.

   [Vkompella]    Kompella, V., Khandekar, S., Heron, G., Heinanen,
                  J., Soon, T., Wilder, R., Martini, L., "Requirements
                  for Virtual Private Switched Networks", (draft-
                  heron-ppvpn-vpsn-reqmts-00.txt), work in progress,
                  July 2001.

   [Worster]      Worster et al, "MPLS Label Stack Encapsulation in
                  IP", (draft-worster-mpls-in-ip-05.txt), work in
                  progress, February 2002.

   [Xiao]         Xiao, X., McPherson, D., Pate, P., White, C.,
                  Kompella, K., Gill, V., Nadeau, T., "Requirements
                  for Pseudo Wire Emulation Edge-to-Edge (PWE3)"
                  (draft-pwe3-requirements-01.txt), work in progress,
                  July 2001.



So et al                  Expires April 2002                 [Page 27]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   IEEE

   [802.1D]       IEEE, "ISO/IEC 15802-3:1998,(802.1D, 1998 Edition),
                  Information technology --Telecommunications and
                  information exchange between systems --IEEE standard
                  for local and metropolitan area networks --Common
                  specifications-Media access control (MAC) Bridges",
                  June, 1998.

   [802.1Q]       ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local
                  and Metropolitan Area Networks: Virtual Bridged
                  Local Area Networks", 1998 .

   [802.3]        IEEE, "ISO/IEC 8802-3: 2000 (E), Information
                  technology--Telecommunications and information
                  exchange between systems --Local and metropolitan
                  area networks --Specific requirements --Part 3:
                  Carrier Sense Multiple Access with Collision
                  Detection (CSMA/CD) Access Method and Physical Layer
                  Specifications", 2000.


11. Authors' Addresses

   Tricci So                        XiPeng Xiao
   Caspian Networks                 Photuris, Inc.
   170 Baytech Drive                2025 Stierlin Court
   San Jose, CA, USA 95134          Mountain View, CA 94043
   Email:                           Email: xxiao@photuris.com
   tso@caspiannetworks.com

   Giles Heron                      Chris Flores
   PacketExchange Ltd.              Austin, Texas
   The Truman Brewery               Email:
   91 Brick Lane                    chris_flores@hotmail.com
   LONDON E1 6QL,
   United Kingdom
   Email:
   giles@packetexchange.net

   David Zelig                      Raj Sharma
   Corrigent Systems                Luminous Networks, Inc.,
   126, Yigal Alon st.              10460 Bubb Road
   Tel Aviv, ISRAEL                 Cupertino, CA 95014
   Email:  davidz@corrigent.com     Email: raj@luminous.com


   Nick Tingle                      Sunil Khandekar
   TiMetra Networks                 TiMetra Networks
   274 Ferguson Drive               274 Ferguson Drive
   Mountain View, CA, USA 94043     Mountain View, CA, USA
   Email: nick@timetra.com          94043
                                    Email: sunil@timetra.com

So et al                  Expires April 2002                 [Page 28]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001


   Loa Andersson
   Utfors
   P.O.Box 525,
   SE-169 29 Solna, Sweden
   Email:
   loa.andersson@utfors.se















































So et al                  Expires April 2002                 [Page 29]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

Appendix A - Interoperability Guidelines

   Point to point services.

   The following is a list of the configuration options for a point
   to point service, based on the reference points of Figure 3:

   --------------|---------------|---------------|------------------
   Service and   |  Encap on C   |Operation at B | Remarks
   Encap on A    |               |ingress/egress |
   --------------|---------------|---------------|------------------
   1) Raw        | Raw - Same as |               | (note 1)
                 | A             |               |
                 |               |               |
   --------------|---------------|---------------|------------------
   2) Tag1       | Tag2          |Optional change| VLAN can be
                 |               |of VLAN value  | 0-4095
                 |               |               | Change allowed in
                 |               |               | both directions
   --------------|---------------|---------------|------------------
   3) No Tag     | Tag           |Add/remove Tag | Tag can be
                 |               |field          | 0-4095
                 |               |               | (note 5)
                 |               |               |
   --------------|---------------|---------------|------------------
   4) Tag        | No Tag        |Remove/add Tag |  (note 4)
                 |               |field          |
                 |               |               |
                 |               |               |
   --------------|---------------|---------------|------------------
   5) Tag1-Tag2  | Tag1-Tag2     |               | VLAN can be
                 |               |               | 0-4095
                 |               |               | Change of VLAN
                 |               |               | is not allowed
   --------------|---------------|---------------|------------------

   Allowed combinations:

   Raw and other services are not allowed on the same physical port
   (A). All other combinations are allowed, except that conflicting
   VLANs on (A) are not allowed.

   Notes:

   1) This mode is equivalent to port mode in [Martini-trans] since
   any packet on the physical port is transmitted as is on the PW and
   vice versa.

   2) The VLAN mode in [Martini-trans] is an example of service #2.
   According to the default specification, it does not change the VLAN
   field.



So et al                  Expires April 2002                 [Page 30]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   3) In draft-martini any change of the VLAN tag is done at the PW
   egress,in order to support equipment that cannot change the VLAN
   tag at the PW ingress. However, where possible, it is recommended
   to change the VLAN tag at the PW ingress, for compatibility with
   VPLS service requirements(see further details below).

   4) Mode #4 exists in layer 2 switches, but is not allowed when
   operating with PW since it does not preserve the user's PRI bit,
   and in order to save configuration of additional service that can
   be achieved by other set of configuration. If there is a need to
   remove the VLAN tag (for TLS at the other end of the PW) it is
   recommended to use mode #2 with tag2=0 (NULL VLAN) on the PW and
   use mode #3 at the other end of the PW.

   5) Mode #3 can be limited to adding VLAN NULL only, since change of
   VLAN or association to specific VLAN can be done at the PW outbound
   side.

   The use of PW for a TLS service is shown in the following diagram:

              +----------------------------------------+
              |                     PE                 |
      +---+   +-+ +---+ +-----+  +------+  +------+  +-+
      |   |   |P| |Swi| |Adapt|  |PW ter|  | PSN  |  |P|
      |   |<==|h|<|tch|<|ation|<=|minati|<=|Tunnel|<=|h|<== From PSN
      |   |   |y| |   | |     |  |on    |  |      |  |y|
      | C |   +-+ +---+ +-----+  +------+  +------+  +-+
      | E |   |                                        |
      |   |   +-+ +---+ +-----+  +------+  +------+  +-+
      |   |   |P| |Swi| |Adapt|  |PW ter|  | PSN  |  |P|
      |   |==>|h|>|tch|>|ation|=>|minati|=>|Tunnel|=>|h|==> To PSN
      |   |   |y| |   | |     |  |on    |  |      |  |y|
      +---+   +-+ +---+ +-----+  +------+  +------+  +-+
              |                                        |
              +----------------------------------------+
                ^               ^        ^
                |               |        |
                C               A        B
   Figure 9: Point-to-point PW reference diagram


   Switching (TLS) service (i.e. VPSN) and the allowed relations to
   the point to point encapsulations format:

   It is assumed that the switching operation requires that the switch
   ports (see figure 2) will conform to the requirement of 802.1D,
   i.e. switching and learning is based on VLAN field on the
   interfaces. Packets without VLAN field or with VLAN NULL may be
   associated to a VLAN # on a per port/PW virtual interface basis.
   Not all virtual interfaces of the same TLS instance may have the
   same VLAN values supported on them, i.e. the forwarding table shall
   be based on VLAN.


So et al                  Expires April 2002                 [Page 31]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   In order to support HUB and Spoke topology where the PE at the
   spoke cannot change the VLAN field in order to comply to 802.1D
   rules, a change of VLAN value may be needed at the adaptation
   process before the switching operation.

   In most cases, port (A) can be defined as "RAW" and destination of
   packets may be selected based on the VLAN configuration on the PWs.
   However, if more than one switching instance is required for the
   same port, (A) MUST NOT be defined as "RAW" service, and
   conflicting VLAN ranges between the switching instances cannot be
   configured in this case.

   Remarks:

   1) Each PW may have different set of VLANs associated with. This
   enables to view the TLS network exactly the same as Enterprise
   switch.

   2) Mode #2 with change of VLAN value is allowed for one VLAN only
   per PW. Recommended new value is 0 (NULL VLAN) on the PW.

   IEEE 802.3x Flow Control Considerations

   If the receiving node becomes congested, it can send a special
   frame, called the PAUSE frame, to the source node at the opposite
   end of the connection. The implementation MUST provide a mechanism
   for terminating PAUSE frames locally (i.e. at the local PE). It
   MUST operate as follows:

   PAUSE frames received on a local Ethernet port SHOULD cause the PE
   device to buffer, or to discard, further Ethernet frames for that
   port until the PAUSE condition is cleared.

   If the PE device wishes to pause data received on a local Ethernet
   port (perhaps because its own buffers are filling up or because it
   has received notification of congestion within the PSN) then it MAY
   issue a PAUSE frame on the local Ethernet port, but MUST clear this
   condition when willing to receive more data.


   MTU Coordination Considerations

   All nodes comprising the PSN shall be configured such that their
   MTU is greater-than or equal-to the largest Ethernet frame plus PSN
   tunnel header. If MPLS is utilized as the tunneling mechanism, for
   example, assuming that there is no label stacking, 8 octets will be
   typically be added to the largest Ethernet frame size (4 octets for
   the tunnel label and 4 for the VC label) - creating the
   encapsulated Ethernet frame size. However, other tunneling
   mechanisms (i.e. L2TP, IP/GRE) may have longer headers and require
   larger MTUs.



So et al                  Expires April 2002                 [Page 32]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001



   Appendix B - QOS details.

   Section 3.7 describes various modes for supporting PW QOS over the
   PSN.  Example of the above for a point to point VLAN service are:

      1) The classification to the PW is based on VLAN field only,
         regardless of the user PRI bits. The PW is assigned a
         specific COS (marking, scheduling, etc.) at the tunnel level.

      2) The classification to the PW is based on VLAN field, but the
         PRI bits of the user is mapped to different COS marking (and
         network behavior) at the PW level. Examples are DiffServ
         coding in case of IP PSN, and E-LSP in MPLS PSN.

      3) The classification to the PW is based on VLAN field and the
         PRI bits, and packets with different PRI bits are mapped to
         different PWs. An example is to map a PWES o different L-LSPs
         in MPLS PSN in order to support multiple COS service over L-
         LSP capable network.

   See the PSN specific sections for supported functionality for
   different PSN technologies.

   The specific value to be assigned at the PSN for various COS is not
   specified and is application specific.

   1. Adaptation of 802.1Q COS to PSN COS:

   It is not required that the PSN will have the same COS definition
   of COS as defined in [802.1Q], and the mapping of 802.1Q COS to PSN
   QOS is application specific and depends on the agreement between
   the customer and the PW provider. However, the following principals
   adopted from 802.1Q table 8-2 MUST be met when applying set of PSN
   COS based on user's PRI bits.

                ----------------------------------
                |#of available classes of service|
   -------------||---|---|---|---|---|---|---|---|
   User         || 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
   Priority     ||   |   |   |   |   |   |   |   |
   ===============================================
   0 Best Effort|| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 2 |
   (Default)    ||   |   |   |   |   |   |   |   |
   ------------ ||---|---|---|---|---|---|---|---|
   1 Background || 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
                ||   |   |   |   |   |   |   |   |
   ------------ ||---|---|---|---|---|---|---|---|
   2 Spare      || 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
                ||   |   |   |   |   |   |   |   |
   ------------ ||---|---|---|---|---|---|---|---|
   3 Excellent  || 0 | 0 | 0 | 1 | 1 | 2 | 2 | 3 |

So et al                  Expires April 2002                 [Page 33]


Internet Draft      draft-so-pwe3-ethernet-00.txt         October 2001

   Effort       ||   |   |   |   |   |   |   |   |
   ------------ ||---|---|---|---|---|---|---|---|
   4 Controlled || 0 | 1 | 1 | 2 | 2 | 3 | 3 | 4 |
   Load         ||   |   |   |   |   |   |   |   |
   ------------ ||---|---|---|---|---|---|---|---|
   5 Interactive|| 0 | 1 | 1 | 2 | 3 | 4 | 4 | 5 |
   Multimedia   ||   |   |   |   |   |   |   |   |
   ------------ ||---|---|---|---|---|---|---|---|
   6 Interactive|| 0 | 1 | 2 | 3 | 4 | 5 | 5 | 6 |
   Voice        ||   |   |   |   |   |   |   |   |
   ------------ ||---|---|---|---|---|---|---|---|
   7 Network    || 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
   Control      ||   |   |   |   |   |   |   |   |
   ------------ ||---|---|---|---|---|---|---|---|

                Figure 10: IEEE 802.1Q COS Service Mapping


   2. Drop precedence:

   The 802.1P standard does not support drop precedence, therefore
   from the PW ingress point of view there is no mapping required. It
   is however possible to mark different drop precedence for different
   PW packets based on the operator policy and required network
   behavior. This functionality is not discussed further here.


   3. PSN COS labels interaction with VC label COS marking

   Marking of COS bits at the VC level is not required if the PSN
   tunnel is PE to PE based, since only the PSN COS marking is visible
   to the PSN network. In cases where the VC multiplexing field is
   carried without an external tunnel (for example directly connected
   PEs in MPLS), the rules stated above for tunnel COS marking apply
   also for VC level.

   In summary, the rules for COS marking shall be as follows:

    -   If there is only a VC label then, it shall contain the
             appropriate CoS value (e.g. MPLS between PEs which are
             directly adjacent to each other).

    -   If the VC label and PSN tunnel labels are both being used,
             then the CoS marking on the PSN header shall be marked
             with the correct CoS value.

    -   If the PSN marking is stripped at a node before the PE,
             the PSN marking MUST be copied to the VC label. An
             example is MPLS PSN with the use of PHP.

   PSN QOS support and signaling of QOS is out of scope of this
   document.


So et al                  Expires April 2002                 [Page 34]