Subject: draft-ietf-pwe3-control-protocol-02.txt

From: Luca Martini <[email-masked]>
Date: Wed, 19 Mar 2003 11:24:45 -0700

Network Working Group                                       Luca Martini
Internet Draft                                           Nasser El-Aawar
Expiration Date: August 2003                Level 3 Communications, LLC.

Toby Smith                                                 Eric C. Rosen
Laurel Networks, Inc.                                Cisco Systems, Inc.
Giles Heron
PacketExchange Ltd.

                                                            February 2003

                Pseudowire Setup and Maintenance using LDP

                 draft-ietf-pwe3-control-protocol-02.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

    Layer 2 services (such as Frame Relay, ATM, ethernet) can be
    "emulated" over an IP and/or MPLS backbone by encapsulating the layer
    2 PDUs and then transmitting them over "pseudowires".  It is also
    possible to use pseudowires to provide SONET circuit emulation over
    an IP and/or MPLS network. This document specifies a protocol for
    establishing and maintaining the pseudowires, using extensions to
    LDP.  Procedures for encapsulating layer 2 PDUs are specified in a
    set of companion documents.

Martini, et al.                                                 [Page 1]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

Table of Contents

     1      Specification of Requirements  ..........................   3
     2      Introduction  ...........................................   3
     3      The Pseudowire Label  ...................................   5
     4      Details Specific to Particular Emulated Services  .......   6
     4.1    Frame Relay  ............................................   6
     4.2    ATM  ....................................................   6
     4.2.1  ATM AAL5 SDU VCC Transport  .............................   6
     4.2.2  ATM Transparent Cell Transport  .........................   7
     4.2.3  ATM n-to-one VCC and VPC Cell Transport  ................   7
     4.2.4  OAM Cell Support  .......................................   7
     4.2.5  ILMI Support  ...........................................   8
     4.2.6  IP Layer2 Transport  ....................................   8
     4.2.7  ATM AAL5 PDU VCC Transport  .............................   8
     4.2.8  ATM one-to-one VCC and VPC Cell Transport  ..............   9
     4.3    Ethernet VLAN  ..........................................   9
     4.4    Ethernet  ...............................................   9
     4.5    HDLC and PPP  ...........................................   9
     5      LDP  ....................................................  10
     5.1    The PWid FEC Element  ...................................  10
     5.2    The Generalized ID FEC Element  .........................  12
     5.2.1  Attachment Identifiers  .................................  12
     5.2.2  Encoding the Generalized ID FEC Element  ................  14
     5.2.3  Procedures  .............................................  15
     5.3    Interface Parameters Field  .............................  16
     5.3.1  PW types for which the control word is REQUIRED  ........  18
     5.3.2  PW types for which the control word is NOT mandatory  ...  18
     5.3.3  Status codes  ...........................................  19
     5.4    LDP label Withdrawal procedures  ........................  20
     5.5    Sequencing Considerations  ..............................  20
     5.5.1  Label Mapping Advertisements  ...........................  20
     5.5.2  Label Mapping Release  ..................................  21
     6      IANA Considerations  ....................................  21
     7      Security Considerations  ................................  21
     8      References  .............................................  22
     9      Author Information  .....................................  23
    10      Additional Contributing Authors  ........................  24
    11      Appendix A - C-bit Handling Procedures Diagram  .........  27

Martini, et al.                                                 [Page 2]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

1. Specification of Requirements

    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.

2. Introduction

    In [7], [10], and [12] it is explained how to encapsulate a layer 2
    Protocol Data Unit (PDU) for transmission over an IP and/or MPLS
    network.  Those specifications that a "pseudowire header", consisting
    of a demultiplexor field, will be prepended to the encapsulated PDU.
    The pseudowire demultiplexor field is put on before transmitting a
    packet on a pseudowire.  When the packet arrives at the remote
    endpoint of the pseudowire, the demultiplexor is what enables the
    receiver to identify the particular pseudowire on which the packet
    has arrived.  To actually transmit the packet from one pseudowire
    endpoint to another, the packet may need to travel through a "PSN
    tunnel header"; this will require an additional header to be
    prepended to the packet.

    An accompanying document [8] also describes a method for transporting
    time division multiplexed (TDM) digital signals (TDM circuit
    emulation) over a packet-oriented MPLS network. The transmission
    system for circuit-oriented TDM signals is the Synchronous Optical
    Network (SONET)[5]/Synchronous Digital Hierarchy (SDH) [6]. To
    support TDM traffic, which includes voice, data, and private leased
    line service, the pseudowires must emulate the circuit
    characteristics of SONET/SDH payloads. The TDM signals and payloads
    are encapsulated for transmission over pseudowires.  To this
    encapsulation is prepended a pseudowire demultiplexor and a PSN
    tunnel header.

    In this document, we specify the use of the MPLS Label Distribution
    Protocol, LDP [RFC3036], as a protocol a protocol for setting up and
    maintaining the pseudowires.  In particular, we define new TLVs for
    LDP, which enable LDP to identify pseudowires and to signal
    attributes of pseudowires.  We specify how a pseudowire endpoint uses
    these TLVs in LDP to bind a demultiplexor field value to a
    pseudowire, and how it informs the remote endpoint of the binding.
    We also specify procedures for reporting pseudowire status changes,
    passing additional information about the pseudowire as needed, and
    for releasing the bindings.

    In the protocol specified herein, the pseudowire demultiplexor field
    is an MPLS label.  Thus the packets which are transmitted from one
    end of the pseudowire to the other are MPLS packets.  Unless the
    pseudowire endpoints are immediately adjacent, these MPLS packets

Martini, et al.                                                 [Page 3]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

    must be transmitted through a PSN tunnel.  Any sort of PSN tunnel can
    be used, as long as it is possible to transmit MPLS packets through
    it.  The PSN tunnel can itself be an LSP, but it could equally well
    be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of
    tunnel which can carry MPLS packets. Procedures for setting up and
    maintaining the PSN tunnels are outside the scope of this document.

    This document deals only with the setup and maintenance of point-to-
    point pseudowires.   Neither point-to-multipoint nor multipoint-to-
    point pseudowires are discussed.

    QoS related issues are not discussed in this document.

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

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

       Figure 1: PWE3 Reference Model

    +-------------+                                +-------------+
    |  Layer2     |                                |  Layer2     |
    |  Emulated   |                                |  Emulated   |
    |  Services   |         Emulated Service       |  Services   |
    |             |<==============================>|             |
    +-------------+           Pseudo Wire          +-------------+
    |Demultiplexor|<==============================>|Demultiplexor|
    +-------------+                                +-------------+
    |    PSN      |            PSN Tunnel          |    PSN      |
    |   MPLS      |<==============================>|   MPLS      |
    +-------------+                                +-------------+
    |  Physical   |                                |  Physical   |
    +-----+-------+                                +-----+-------+

Martini, et al.                                                 [Page 4]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

       Figure 2: Ethernet PWE3 Protocol Stack Reference Model

    For the purpose of this document, PE1 will be defined as the ingress
    router, and PE2 as the egress router. A layer 2 PDU will be received
    at PE1, encapsulated at PE1, transported, decapsulated at PE2, and
    transmitted out of PE2.

3. The Pseudowire Label

    Suppose it is desired to transport layer 2 PDUs from ingress LSR PE1
    to egress LSR PE2, across an intervening PSN. We assume that there is
    a PSN tunnel from PE1 to PE2. That is, we assume that PE1 can cause a
    packet to be delivered to PE2 by encapsulating the packet in a "PSN
    tunnel header" and sending the result to one of its adjacencies.  If
    the PSN tunnel is an MPLS Label Switched Path (LSP), then putting on
    a PSN tunnel encapsulation is a matter of pushing on an additional
    MPLS label; if the PSN tunnel is, e.g., a GRE tunnel, then putting on
    the tunnel encapsulation requires prepending an IP header and a GRE
    header.

    We presuppose that an arbitrary number of pseudowires can be carried
    through a single PSN tunnel.  Thus it is never necessary to maintain
    state in the network core for individual pseudowires.  We do not
    presuppose that the PSN tunnels are point-to-point; although the
    pseudowires are point-to-point, the PSN tunnels may be multipoint-
    to-point.  We do not presuppose that PE 2 will even be able to
    determine the PSN tunnel through which a received packet was
    transmitted.  (E.g., if the PSN tunnel is an LSP, and penultimate hop
    popping is used, when the packet arrives at PE2 it will contain no
    information identifying the tunnel.)

    When PE2 receives a packet over a pseudowire, it must be able to
    determine that the packet was in fact received over a pseudowire, and
    it must be able to associate that packet with a particular
    pseudowire.  PE2 is able to do this by examining the MPLS label which
    serves as the pseudowire demultiplexor field.  Call this label the
    "PW label".

    So when PE1 sends a layer 2 PDU to PE2, it first pushes a PW label on
    its label stack, thereby creating an MPLS packet.  It then (if PE1 is
    not adjacent to PE2) encapsulates that MPLS packet in a PSN tunnel
    header.  (If the PSN tunnel is an LSP, this is just a matter of
    pushing on a second label.)  The PW label is not visible again until
    the MPLS packet reaches PE2. PE2's disposition of the packet is based
    on the PW label.

Martini, et al.                                                 [Page 5]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

    Note that the PW label must always be at the bottom of the packet's
    label stack.

    This document specifies a protocol for assigning and distributing the
    PW label.  This protocol is LDP, extended as specified in the
    remainder of this document.  An LDP session must be set up between
    the pseudowire endpoints.  LDP MUST be used in its "downstream
    unsolicited" mode.  LDP's "liberal label retention" mode SHOULD be
    used.

    In addition to the protocol specified herein, static assignment of PW
    labels MAY be used, and implementations of this protocol SHOULD
    provide support for static assignment.

    This document specifies all the procedures necessary to set up and
    maintain the pseudowires needed to support "unswitched" point-to-
    point services, where each endpoint of the pseudowire is provisioned
    with the identify of the other endpoint.  There are also  protocol
    mechanisms specified herein which can be used to support switched
    services, and which can be used to support other provisioning models.
    However, the use of the protocol mechanisms to support those other
    models and services is not described in this document.

4. Details Specific to Particular Emulated Services

4.1. Frame Relay

    When emulating a frame relay service, the Frame Relay PDUs are
    encapsulated according to the procedures defined in [7]. The PE MUST
    provide Frame Relay PVC status signaling to the Frame Relay network.
    If the PE detects a service affecting condition for a particular
    DLCI, as defined in [2] Q.933 Annex A.5 sited in IA FRF1.1, PE MUST
    withdraw the PW label that corresponds to the frame relay DLCI. The
    Egress PE SHOULD generate the corresponding errors and alarms as
    defined in [2] on the egress Frame relay VC.

4.2. ATM

4.2.1. ATM AAL5 SDU VCC Transport

    ATM AAL5 CSPS-SDUs are encapsulated according to [10] ATM AAL5 CPCS-
    SDU mode. This mode allows the transport of ATM AAL5 CSPS-SDUs
    traveling on a particular ATM PVC across the network to another ATM
    PVC.

Martini, et al.                                                 [Page 6]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

4.2.2. ATM Transparent Cell Transport

    This mode is similar to the Ethernet port mode. Every cell that is
    received at the ingress ATM port on the ingress PE, PE1, is
    encapsulated according to [10], ATM cell mode n-to-one, and sent
    across the PW to the egress PE, PE2. This mode allows an ATM port to
    be connected to only one other ATM port. [10] ATM cell n-to-one mode
    allows for grouping of multiple cells into a single MPLS frame.
    Grouping of ATM cells is OPTIONAL for transmission at the ingress PE,
    PE1. If the Egress PE PE2 supports cell concatenation the ingress PE,
    PE1, should only concatenate cells up to the "Maximum Number of
    concatenated ATM cells" parameter received as part of the FEC
    element.

4.2.3. ATM n-to-one VCC and VPC Cell Transport

    This mode is similar to the ATM AAL5 VCC transport except that cells
    are transported. Every cell that is received on a pre-defined ATM
    PVC, or ATM PVP, at the ingress ATM port on the ingress PE, PE1, is
    encapsulated according to [10], ATM cell mode, and sent across the
    LSP to the egress PE PE2. Grouping of ATM cells is OPTIONAL for
    transmission at the ingress PE, PE1. If the Egress PE PE2 supports
    cell concatenation the ingress PE, PE1, MUST only concatenate cells
    up to the "Maximum Number of concatenated ATM cells in a frame"
    parameter received as part of the FEC element.

4.2.4. OAM Cell Support

    OAM cells MAY be transported on the VC LSP. When the PE is operating
    in AAL5 CPCS-SDU transport mode if it does not support transport of
    ATM cells, the PE MUST discard incoming MPLS frames on an ATM VC LSP
    that contain a VC label with the T bit set [10]. When operating in
    AAL5 SDU transport mode an PE that supports transport of OAM cells
    using the T bit defined in [7], or an PE operating in any of the
    three cell transport modes MUST follow the procedures outlined in [9]
    section 8 for mode 0 only, in addition to the applicable procedures
    specified in [6].

4.2.4.1. OAM Cell Emulation Mode

    AN PE that does not support transport of OAM cells across an LSP MAY
    provide OAM support on ATM PVCs using the following procedures:

    A pair of PEs MAY emulate a bi-directional ATM VC by two uni-
    directional LSPs.  If an F5 end-to-end OAM cell is received from a

Martini, et al.                                                 [Page 7]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

    ATM VC, by either PE that is transporting this ATM VC, with a
    loopback indication value of 1, and the PE has a label mapping for
    the ATM VC, then the PE MUST decrement the loopback indication value
    and loop back the cell on the ATM VC. Otherwise the loopback cell
    MUST be discarded by the PE.

    The ingress PE, PE1, may also optionally be configured to
    periodically generate F5 end-to-end loopback OAM cells on a VC. If
    the PE fails to receive a response to an F5 end-to-end loopback OAM
    cell for a pre-defined period of time it MUST withdraw the label
    mapping for the VC.

    If an ingress PE, PE1, receives an AIS F5 OAM cell, fails to receive
    a pre-defined number of the End-to-End loop OAM cells, or a physical
    interface goes down, it MUST withdraw the label mappings for all VCs
    associated with the failure. When a PW label mapping is withdrawn,
    the egress PE, PE2, MUST generate AIS F5 OAM cells on the VC
    associated with the withdrawn label mapping. In this mode it is very
    useful to apply a unique group ID to each interface. In the case
    where a physical interface goes down, a wild card label withdraw can
    be sent to all LDP neighbors, greatly reducing the signaling response
    time.

4.2.5. ILMI Support

    An MPLS edge PE MAY provide an ATM ILMI to the ATM edge switch. If an
    ingress PE receives an ILMI message indicating that the ATM edge
    switch has deleted a VC, or if the physical interface goes down, it
    MUST withdraw the label mappings for all VCs associated with the
    failure. When a PW label mapping is withdrawn, the egress PE SHOULD
    notify its client of this failure by deleting the VC using ILMI.

4.2.6. IP Layer2 Transport

    This mode switches IP packets into a Peudo-Wire. the encapsulation
    used is according to [3]. IP interworking is implementation specific,
    part of the NSP function [13], and is outside the scope of this
    document.

4.2.7. ATM AAL5 PDU VCC Transport

    ATM AAL5 CSPS-PDUs are encapsulated according to [10] ATM AAL5 CPCS-
    PDU mode. This mode allows the transport of ATM AAL5 CSPS-PDUs
    traveling on a particular ATM PVC across the network to another ATM
    PVC. This mode supports fragmentation of the ATM AAL5 CPCS-PDU in

Martini, et al.                                                 [Page 8]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

    order to maintain the position of the OAM cells with respect to the
    user cells. Fragmentation may also be performed to maintain the size
    of the packet carrying the AAL5 PDU within the MTU of the link.

4.2.8. ATM one-to-one VCC and VPC Cell Transport

    This mode is similar to the ATM AAL5 n-to-one cell transport except
    an encapsulation method that maps one ATM VCC or one ATM VPC to one
    Pseudo-Wire is used. Every cell that is received on a pre-defined ATM
    PVC, or ATM PVP, at the ingress ATM port on the ingress PE, PE1, is
    encapsulated according to [10], ATM one-to-one cell mode, and sent
    across the LSP to the egress PE PE2. Grouping of ATM cells is
    OPTIONAL for transmission at the ingress PE, PE1. If the Egress PE
    PE2 supports cell concatenation the ingress PE, PE1, MUST only
    concatenate cells up to the "Maximum Number of concatenated ATM cells
    in a frame" parameter received as part of the FEC element.

4.3. Ethernet VLAN

    The Ethernet frame will be encapsulated according to the procedures
    in [12] tagged mode. It should be noted that if the VLAN identifier
    is modified by the egress PE, according to the procedures outlined
    above, the Ethernet spanning tree protocol might fail to work
    properly. If the PE detects a failure on the Ethernet physical port,
    or the port is administratively disabled, it MUST withdraw the label
    mappings for all PWs associated with the port.

4.4. Ethernet

    The Ethernet frame will be encapsulated according to the procedures
    in [12].  If the PE detects a failure on the Ethernet physical port,
    or the port is administratively disabled, the corresponding PW label
    mapping MUST be withdrawn.

4.5. HDLC and PPP

    HDLC and PPP frames are encapsulated according to the procedures in
    [11]. If the MPLS edge PE detects that the physical link has failed,
    or the port is administratively disabled, it MUST withdraw the label
    mapping that corresponds to the HDLC or PPP link.

Martini, et al.                                                 [Page 9]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

5. LDP

    The PW label bindings are distributed using the LDP downstream
    unsolicited mode described in [1]. The PEs will establish an LDP
    session using the Extended Discovery mechanism described in [1,
    section 2.4.2 and 2.5].

    An LDP Label Mapping message contains a FEC TLV, a Label TLV, and
    zero or more optional parameter TLVs.

    The FEC TLV is used to indicate the meaning of the label.  In the
    current context, the FEC TLV would be used to identify the particular
    pseudowire that a particular label is bound to.  In this
    specification, we define two new FEC TLVs to be used for identifying
    pseudowires.  When setting up a particular pseudowire, only one of
    these FEC TLVs is used.  The one to be used will depend on the
    particular service being emulated and on the particular provisioning
    model being supported.

    LDP allows each FEC TLV to consist of a set of FEC elements.  For
    setting up and maintaining pseudowires, however, each FEC TLV MUST
    contain exactly one FEC element.

    LDP has several kinds of label TLVs.  For setting up and maintaining
    pseudowires, the Generic Label TLV MUST be used.

5.1. The PWid FEC Element

    The PWid FEC element may be used whenever both pseudowire endpoints
    have been provisioned with the same 32-bit identifier for the
    pseudowire.

    For this purpose a new type of FEC element is defined. The FEC
    element type is 128 [note1], and is defined as follows:

Martini, et al.                                                [Page 10]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    VC tlv     |C|         PW type             |VC info Length |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Group ID                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           PW ID                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Interface parameters                    |
    |                              "                                |
    |                              "                                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      - PW type

        A 15 bit quantity containing a value which represents the type of
        PW. Assigned Values are specified in "IANA Allocations for pseudo
        Wire Edge to Edge Emulation (PWE3)" [14].

      - Control word bit (C)

        The  highest  order bit (C) of the PW type is used to flag the
        presence  of  a  control  word  ( defined in [7] ) as follows:

                bit 15 = 1 control word present on this VC.
                bit 15 = 0 no control word present on this VC.

        Please see the section "C-Bit Handling Procedures" for further
        explanation.

      - VC information length

        Length of the PW ID field and the interface parameters field in
        octets. If this value is 0, then it references all PWs using the
        specified group ID and there is no PW ID present, nor any
        interface parameters.

      - Group ID

        An arbitrary 32 bit value which represents a group of PWs that is
        used to create groups in the VC space. The group ID is intended
        to be used as a port index, or a virtual tunnel index. To
        simplify configuration a particular PW ID at ingress could be
        part of the virtual tunnel for transport to the egress router.
        The Group ID is very useful to send wild card label withdrawals
        to remote PEs upon physical port failure.

Martini, et al.                                                [Page 11]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

      - PW ID

        A non-zero 32-bit connection ID that together with the PW type,
        identifies a particular PW.  Note that the PW ID and the PW type
        must be the same at both endpoints.

      - Interface parameters

        This variable length field is used to provide interface specific
        parameters, such as interface MTU.

        Note that as the "interface parameters" are part of the FEC, the
        rules of LDP make it impossible to change the interface
        parameters once the pseudowire has been set up.  Thus the
        interface parameters field must not be used to pass information,
        such as status information, which may change during the life of
        the pseudowire.  Optional parameter TLVs should be used for that
        purpose.

    Using the PWid FEC, each of the two pseudowire endpoints
    independently initiates the set up of a unidirectional LSP.  An
    outgoing LSP and an incoming LSP are bound together into a single
    pseudowire if they have the same PW ID  and PW type.

5.2. The Generalized ID FEC Element

    There are cases where the PWid FEC element cannot be used, because
    both endpoints have not been provisioned with a common 32-bit PWid.
    In such cases, the "Generalized ID FEC Element" is used instead.
    This is FEC type 129 (provisionally, subject to assignment by IANA).
    It differs from the PWid FEC element in that the PWid and the group
    id are eliminated, and their place is taken by a generalized
    identifier field as described below.  The Generalized ID FEC element
    includes a PW type field, a C bit, and an interface parameters field;
    these three fields are identical to those in the PWid FEC, and are
    used as discussed in the previous section.

5.2.1. Attachment Identifiers

    As discussed in [13], a pseudowire can be thought of as connecting
    two "forwarders".  The protocol used to setup a pseudowire must allow
    the forwarder at one end of a pseudowire to identify the forwarder at
    the other end.  We use the term "attachment identifier", or "AI", to
    refer to the field which the protocol uses to identify the
    forwarders.  In the PWid FEC, the PWid field serves as the AI.  In
    this section we specify a more general form of AI which is structured

Martini, et al.                                                [Page 12]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

    and of variable length.

    Every Forwarder in a PE must be associated with an Attachment
    Identifier (AI), either through configuration or through some
    algorithm.  The Attachment Identifier must be unique in the context
    of the PE router in which the Forwarder resides.  The combination <PE
    router, AI> must be globally unique.

    It is frequently convenient to a set of Forwarders as being members
    of a particular "group", where PWs may only be set up among members
    of a group.  In such cases, it is convenient to identify the
    Forwarders relative to the group, so that an Attachment Identifier
    would consist of  an Attachment Group Identifier (AGI) plus an
    Attachment Individual Identifier (AII).

    An Attachment  Group Identifier  may be thought  of as  a VPN-id, or
    a VLAN identifier, some  attribute which  is shared by  all the
    Attachment  VCs (or pools thereof) which are allowed to be connected.

    The details of how to construct the AGI and AII fields identifying
    the pseudowire endpoints are outside the scope of this specification.
    Different pseudowire application, and different provisioning models,
    will require different sorts of AGI and AII fields.  The
    specification of each such application and/or model must include the
    rules for constructing the AGI and AII fields.

    As previously discussed, a (bidirectional) pseudowire consists of a
    pair of unidirectional LSPs, one in each direction. If a particular
    pseudowire connects PE1 with PE2, the LSP in the PE1-->PE2 direction
    can be identified as:

            <PE1, <AGI, AII1>, PE2, <AGI, AII2>>,

    and the LSP in the PE2--PE1 direction can be identified by:

            <PE2, <AGI, AII2>, PE1, <AGI, AII1>>.

    Note that the AGI must be the same at both endpoints, but the AII
    will in general be different at each endpoint.  Thus from the
    perspective of a particular PE, each pseudowire has a local or
    "Source AII", and a remote or "Target AII".  The pseudowire setup
    protocol can carry all three of these quantities:

      - Attachment Group Identifier (AGI).

Martini, et al.                                                [Page 13]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

      - Source Attachment Individual Identifier (SAII)

      - Target Attachment Individual Identifier (TAII)

    If the AGI is non-null, then the Source AI (SAI) consists of the AGI
    together with the SAII, and the Target AI (TAI) consists of the TAII
    together with the AGI.  If the AGI is null, then the SAII and TAII
    are the SAI and TAI respectively.

    The interpretation of the SAI and TAI is a local matter at the
    respective endpoint.

    The association of two unidirectional LSPs into a single
    bidirectional pseudowire depends on the SAI and the TAI.  Each
    application and/or provisioning model which uses the Generalized ID
    FEC element must specify the rules for performing this association.

5.2.2. Encoding the Generalized ID FEC Element

    FEC element type 129 is used.   The FEC element is encoded 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     129       |C|         VC Type             |VC info Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Parameters                           |
       |                              "                                |
       |                              "                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    additional Parameters are:

      - SAII, encoded as a one byte length field followed by the SAI.

      - TAII, encoded as a one byte length field followed by the TAI.

      - AGI, encoded as a one byte length field followed by the AGI.

        The SAII, TAII, and AGI are simply carried as octet strings.  The
        length byte specifies the size of the field, excluding the length
        byte itself. The null string can be sent by setting the length

Martini, et al.                                                [Page 14]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

        byte to 0.

5.2.3. Procedures

    In order for PE1 to begin signaling PE2, PE1 must know the address of
    the remote PE2, and a TAI.  This information may have been configured
    at PE1, or it may have been learned dynamically via some
    autodiscovery procedure.

    To begin the signaling procedure, a PE (PE1) that has knowledge of
    the other endpoint (PE2) initiates the setup of the LSP in the
    incoming (PE2-->PE1) direction by sending a Label Mapping message
    containing the FEC type 129.  The FEC element includes the SAII, AGI,
    and TAII.

    What happens when PE2 receives such a Label Mapping message?

    PE2 interprets the message as a request to set up a PW whose endpoint
    (at PE2) is the Forwarder identified by the TAI.  From the
    perspective of the signaling protocol, exactly how PE2 maps AIs to
    Forwarders is a local matter.  In some VPWS provisioning models, the
    TAI might, e.g., be a string which identifies a particular Attachment
    Circuit, such as "ATM3VPI4VCI5", or it might, e.g., be a string such
    as "Fred" which is associated by configuration with a particular
    Attachment Circuit.  In VPLS, the TAI would be a VPN-id, identifying
    a particular VPLS instance.

    If PE2 cannot map the TAI to one of its Forwarders, then PE2 sends a
    Label Release message to PE1, with a Status Code meaning "invalid
    TAI", and the processing of the Mapping message is complete.

    If the Label Mapping Message has a valid TAI, PE2 must decide whether
    to accept it or not. The procedures for so deciding will depend on
    the particular type of Forwarder identified by the TAI. Of course,
    the Label Mapping message may be rejected due to standard LDP error
    conditions as detailed in [LDP].

    If PE2 decides to accept the Label Mapping message, then it has to
    make sure that an LSP is set up in the opposite (PE1-->PE2)
    direction.  If it has already signaled for the corresponding LSP in
    that direction, nothing more need be done.  Otherwise, it must
    initiate such signaling by sending a Label Mapping message to PE1.
    This is very similar to the Label Mapping message PE2 received, but
    with the SAI and TAI reversed.

Martini, et al.                                                [Page 15]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

5.3. Interface Parameters Field

    This field specifies interface specific parameters. When applicable,
    it MUST be used to validate that the PEs, and the ingress and egress
    ports at the edges of the circuit, have the necessary capabilities to
    interoperate with each other. The field structure is defined 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Parameter ID |    Length     |    Variable Length Value      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Variable Length Value                 |
    |                             "                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The parameter ID Values are specified in "IANA Allocations for pseudo
    Wire Edge to Edge Emulation (PWE3)" [14].

    The Length field is defined as the length of the interface parameter
    including the parameter id and length field itself. Processing of the
    interface parameters should continue when encountering unknown
    interface parameters and they MUST be silently ignored.

      - Interface MTU

        A 2 octet value indicating the MTU in octets. This is the Maximum
        Transmission Unit, excluding encapsulation overhead, of the
        egress packet interface that will be transmitting the
        decapsulated PDU that is received from the MPLS network. This
        parameter is applicable only to PW types 1, 2, 4, 5, 6, and 7,
        and is REQUIRED for these PW types. If this parameter does not
        match in both directions of a specific PW, that PW MUST NOT be
        enabled.

      - Maximum Number of concatenated ATM cells

        A 2 octet value specifying the maximum number of concatenated ATM
        cells that can be processed as a single PDU by the egress PE. An
        ingress PE transmitting concatenated cells on this PW can
        concatenate a number of cells up to the value of this parameter,
        but MUST NOT exceed it. This parameter is applicable only to PW
        types 3, 9, and 0x0a, and is REQUIRED for these PWC types. This
        parameter does not need to match in both directions of a specific
        PW.

Martini, et al.                                                [Page 16]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

      - Optional Interface Description string

        This arbitrary, OPTIONAL, interface description string is used to
        send a human-readable administrative string describing the
        interface to the remote. This parameter is OPTIONAL, and is
        applicable to all PW types.  The interface description parameter
        string length is variable, and can be from 0 to 80 octets.
        Human-readable text MUST be provided in the UTF-8 charset using
        the Default Language [RFC2277].

      - Payload Bytes

        A 2 octet value indicating the number of TDM payload octets
        contained in all packets on the CEM stream, from 48 to 1,023
        octets. All of the packets in a given CEM stream have the same
        number of payload bytes. Note that there is a possibility that
        the packet size may exceed the SPE size in the case of an STS-1
        SPE, which could cause two pointers to be needed in the CEM
        header, since the payload may contain two J1 bytes for
        consecutive SPEs. For this reason, the number of payload bytes
        must be less than or equal to 783 for STS-1 SPEs.

      - CEP Options.  An optional 16 Bit value of CEM Flags. See [8] for
        the definition of the bit values.

      - Requested VLAN ID.  An Optional 16 bit value indicating the
        requested VLAN ID. This parameter MAY be used by an PE that is
        incapable of rewriting the 802.1Q ethernet VLAN tag on output. If
        the ingress PE receives this request it MAY rewrite the VLAN ID
        tag in input to match the requested VLAN ID. If this is not
        possible, and the VLAN ID does not already match configured
        ingress VLAN ID the PW should not be enabled.This parameter is
        applicable only to PW type 4.

      -  CEP/TDM bit rate.  This 32-bit integer is mandatory for CEP. For
        other PWs carrying TDM traffic it is mandatory if the bit-rate
        cannot be directly inferred from the service type. If present, it
        expresses the bit rate of the attachment circuit as known to the
        advertizing PE in "units" of 64 kbit/s. I.e., the value 26 must
        be used for CEP carrying VT1.5 SPE, 35 - for CEP carrying a VT2
        SPE, 99 - for VT6 SPE, 783 - for STS-1 SPE and n*783 - for STS-
        nc, n = 3, 12, 48, 192.  Attempts to establish a PWC between a
        pair of TDM ports with different bit-rates MUST be rejected with
        the appropriate status code (see section "Status codes" below).

Martini, et al.                                                [Page 17]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

5.3.1. PW types for which the control word is REQUIRED

    The Label Mapping messages which are sent in order to set up these
    PWs MUST have c=1. When a Label Mapping message for a PW of one of
    these types is received, and c=0, a Label Release MUST be sent, with
    an "Illegal C-bit" status code. In this case, the PW will not be
    enabled.

5.3.2. PW types for which the control word is NOT mandatory

    If a system is capable of sending and receiving the control word on
    PW types for which the control word is not mandatory, then each such
    PW endpoint MUST be configurable with a parameter that specifies
    whether the use of the control word is PREFERRED or NOT PREFERRED.
    For each PW, there MUST be a default value of this parameter. This
    specification does NOT state what the default value should be.

    If a system is NOT capable of sending and receiving the control word
    on PWC types for which the control word is not mandatory, then it
    behaves as exactly as if it were configured for the use of the
    control word to be NOT PREFERRED.

    If a Label Mapping message for the PW has already been received, but
    no Label Mapping message for the PW has yet been sent, then the
    procedure is the following:

         -i. If the received Label Mapping message has c=0, send a Label
             Mapping message with c=0, and the control word is not used.
        -ii. If the received Label Mapping message has c=1, and the PW is
             locally configured such that the use of the control word is
             preferred, then send a Label Mapping message with c=1, and
             the control word is used.
       -iii. If the received Label Mapping message has c=1, and the PW is
             locally configured such that the use of the control word is
             not preferred or the control word is not supported, then act
             as if no Label Mapping message for the PW had been received
             (i.e., proceed to the next paragraph).

    If a Label Mapping message for the PW has not already been received
    (or if the received Label Mapping message had c=1 and either local
    configuration says that the use of the control word is not preferred
    or the control word is not supported), then send a Label Mapping
    message in which the c bit is set to correspond to the locally
    configured preference for use of the control word.  (I.e., set c=1 if
    locally configured to prefer the control word, set c=0 if locally
    configured to prefer not to use the control word or if the control
    word is not supported).

Martini, et al.                                                [Page 18]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

    The next action depends on what control message is next received for
    that PW.  The possibilities are:

         -i. A Label Mapping message with the same c bit value as
             specified in the Label Mapping message that was sent. PW
             setup is now complete, and the control word is used if c=1
             but not used if c=0.
        -ii. A Label Mapping message with c=1, but the Label Mapping
             message that was sent has c=0. In this case, ignore the
             received Label Mapping message, and continue to wait for the
             next control message for the PW.
       -iii. A Label Mapping message with c=0, but the Label Mapping
             message that was sent has c=1. In this case, send a Label
             Withdraw message with a "Wrong c-bit" status code, followed
             by a Label Mapping message that has c=0. PW setup is now
             complete, and the control word is not used.
        -iv. A Label Withdraw message with the "Wrong c-bit" status code.
             Treat as a normal Label Withdraw, but do not respond.
             Continue to wait for the next control message for the PW.

    If at any time after a Label Mapping message has been received, a
    corresponding Label Withdraw or Release is received, the action taken
    is the same as for any Label Withdraw or Release that might be
    received at any time. Note that receiving a Label Withdraw should not
    cause a corresponding Label Release to be sent.

    If both endpoints prefer the use of the control word, this procedure
    will cause it to be used. If either endpoint prefers not to use the
    control word, or does not support the control word, this procedure
    will cause it not to be used. If one endpoint prefers to use the
    control word but the other does not, the one that prefers not to use
    it is has no extra protocol to execute, it just waits for a Label
    Mapping message that has c=0.

    The diagram in Appendix A illustrates the above procedure.

5.3.3. Status codes

    RFC 3036 has a range of Status Code values which are assigned by IANA
    on a First Come, First Served basis. These additional status codes,
    and  assigned Values are specified in "IANA Allocations for pseudo
    Wire Edge to Edge Emulation (PWE3)" [14].

Martini, et al.                                                [Page 19]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

5.4. LDP label Withdrawal procedures

    As mentioned above the Group ID field can be used to withdraw all PW
    labels associated with a particular group ID. This procedure is
    OPTIONAL, and if it is implemented the LDP label withdraw message
    should be as follows: the PW information length field is set to 0,
    the PW ID field is not present, and the interface parameters field is
    not present. For the purpose of this document this is called the
    "wild card withdraw procedure", and all PEs implementing this design
    are REQUIRED to accept such a withdraw message, but are not required
    to send it.

    The interface parameters field MUST NOT be present in any LDP PW
    label withdrawal message or release message. A wildcard release
    message MUST include only the group ID. A Label Release message
    initiated from the imposition router must always include the PW ID.

5.5. Sequencing Considerations

    In the case where the router considers the sequence number field in
    the control word, it is important to note the following when
    advertising labels

5.5.1. Label Mapping Advertisements

    After a label has been withdrawn by the disposition router and/or
    released by the imposition router, care must be taken to not re-
    advertise (re-use) the released label until the disposition router
    can be reasonably certain that old packets containing the released
    label no longer persist in the MPLS network.

    This precaution is required to prevent the imposition router from
    restarting packet forwarding with sequence number of 1 when it
    receives the same label mapping if there are still older packets
    persisting in the network with sequence number between 1 and 32768.
    For example, if there is a packet with sequence number=n where n is
    in the interval[1,32768] traveling through the network, it would be
    possible for the disposition router to receive that packet after it
    re-advertises the label. Since the label has been released by the
    imposition router, the disposition router SHOULD be expecting the
    next packet to arrive with sequence number to be 1. Receipt of a
    packet with sequence number equal to n will result in n packets
    potentially being rejected by the disposition router until the
    imposition router imposes a sequence number of n+1 into a packet.
    Possible methods to avoid this is for the disposition router to
    always advertise a different PW label, or for the disposition router

Martini, et al.                                                [Page 20]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

    to wait for a sufficient time before attempting to re-advertised a
    recently released label. This is only an issue when sequence number
    processing at the disposition router is enabled.

5.5.2. Label Mapping Release

    In situations where the imposition router wants to restart forwarding
    of packets with sequence number 1, the router shall 1) Send to
    disposition router a label mapping release, and 2) Send to
    disposition router a label mapping request. When sequencing is
    supported, advertisement of a PW label in response to a label mapping
    request MUST also consider the issues discussed in the section on
    Label Mapping Advertisements.

6. IANA Considerations

    As specified in this document, a Virtual Circuit FEC element contains
    the PW Type field. PW type value 0 is reserved. PW type values 1
    through 10 are defined in this document. PW type values 11 through 63
    are to be assigned by IANA using the "IETF Consensus" policy defined
    in [RFC2434]. PW type values 64 through 127 are to be assigned by
    IANA, using the "First Come First Served" policy defined in [RFC
    2434]. PW type values 128 through 32767 are vendor-specific, and
    values in this range are not to be assigned by IANA.

    As specified in this document, a Pseudo Wire FEC element contains the
    Interface Parameters field, which is a list of one or more
    parameters, and each parameter is identified by the Parameter ID
    field. Parameter ID value 0 is reserved. Parameter ID values 1
    through 6 are defined in this document.  Parameter ID values 7
    through 63 are to be assigned by IANA using the "IETF Consensus"
    policy defined in RFC2434. Parameter ID values 64 through 127 are to
    be assigned by IANA, using the "First Come First Served" policy
    defined in RFC2434. Parameter ID values 128 through 255 are vendor-
    specific, and values in this range are not to be assigned by IANA.

7. Security Considerations

    This document does not affect the underlying security issues of MPLS.

Martini, et al.                                                [Page 21]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

8. References

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

    [2] ITU-T Recommendation Q.933, and Q.922 Specification for Frame
    Mode Basic call control, ITU Geneva 1995

    [3] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, D. Tappan, G.
         Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032

    [4] "IEEE 802.3ac-1998" IEEE standard specification.

    [5] American National Standards Institute, "Synchronous Optical
    Network Formats," ANSI T1.105-1995.

    [6] ITU Recommendation G.707, "Network Node Interface For The
    Synchronous Digital Hierarchy", 1996.

    [7] "Encapsulation Methods for Transport of Frame-Relay Over IP and
    MPLS Networks", draft-ietf-pwe3-frame-encap-01.txt. ( work in
    progress )

    [8] "SONET/SDH Circuit Emulation Service Over Packet (CEP)",
       draft-ietf-pwe3-sonet-01.txt ( Work in progress )

    [9] ATM Forum Specification fb-fbatm-0151.000 (2000) ,Frame Based ATM
    over SONET/SDH Transport (FAST)

    [10] "Encapsulation Methods for Transport of ATM Cells/Frame Over IP
    and MPLS Networks", draft-ietf-pwe3-atm-encap-00.txt ( work in
    progress )

    [11] "Encapsulation Methods for Transport of PPP/HDLC Frames Over IP
    and MPLS Networks", draft-martini-ppp-hdlc-encap-mpls-00.txt. ( work
    in progress )

    [12] "Encapsulation Methods for Transport of Ethernet Frames Over
    IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-01.txt. ( work in
    progress )

    [13] "Protocol Layering in PWE3" Bryant, et al., draft-ietf-pwe3-
    protocol-layer-00.txt ( work in progress ), November 2002.

    [14] "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)"
    Martini, Townsley, draft-ietf-pwe3-iana-allocation-00.txt ( work in
    progress ), February 2003

Martini, et al.                                                [Page 22]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

    [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
    IANA Considerations section in RFCs", BCP 26, RFC 2434, October 1998.

    [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
    Languages", BCP 18, RFC 2277, January 1998.

    [note1] FEC element type 128 is pending IANA approval.

    [note2] Status codes assigment is pending IANA approval.

9. Author Information

    Luca Martini
    Level 3 Communications, LLC.
    1025 Eldorado Blvd.
    Broomfield, CO, 80021
    e-mail: [email-masked]

    Nasser El-Aawar
    Level 3 Communications, LLC.
    1025 Eldorado Blvd.
    Broomfield, CO, 80021
    e-mail: [email-masked]

    Giles Heron
    PacketExchange Ltd.
    The Truman Brewery
    91 Brick Lane
    LONDON E1 6QL
    United Kingdom
    e-mail: [email-masked]

    Eric Rosen
    Cisco Systems, Inc.
    250 Apollo Drive
    Chelmsford, MA, 01824
    e-mail: [email-masked]

Martini, et al.                                                [Page 23]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

    Dan Tappan
    Cisco Systems, Inc.
    250 Apollo Drive
    Chelmsford, MA, 01824
    e-mail: [email-masked]

10. Additional Contributing Authors

    Dimitri Stratton Vlachos
    Mazu Networks, Inc.
    125 Cambridgepark Drive
    Cambridge, MA 02140
    e-mail: [email-masked]

    Jayakumar Jayakumar,
    Cisco Systems Inc.
    225, E.Tasman, MS-SJ3/3,
    San Jose, CA, 95134
    e-mail: [email-masked]

    Alex Hamilton,
    Cisco Systems Inc.
    285 W. Tasman, MS-SJCI/3/4,
    San Jose, CA, 95134
    e-mail: [email-masked]

    Steve Vogelsang
    Laurel Networks, Inc.
    Omega Corporate Center
    1300 Omega Drive
    Pittsburgh, PA 15205
    e-mail: [email-masked]

    John Shirron
    Omega Corporate Center
    1300 Omega Drive
    Pittsburgh, PA 15205
    Laurel Networks, Inc.
    e-mail: [email-masked]

Martini, et al.                                                [Page 24]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

    Toby Smith
    Omega Corporate Center
    1300 Omega Drive
    Pittsburgh, PA 15205
    Laurel Networks, Inc.
    e-mail: [email-masked]

    Andrew G. Malis
    Vivace Networks, Inc.
    2730 Orchard Parkway
    San Jose, CA 95134
    Phone: +1 408 383 7223
    Email: [email-masked]

    Vinai Sirkay
    Vivace Networks, Inc.
    2730 Orchard Parkway
    San Jose, CA 95134
    e-mail: [email-masked]

    Vasile Radoaca
    Nortel Networks
    600  Technology Park
    Billerica MA 01821
    e-mail: [email-masked]

    Chris Liljenstolpe
    Cable & Wireless
    11700 Plaza America Drive
    Reston, VA 20190
    e-mail: [email-masked]

    Dave Cooper
    Global Crossing
    960 Hamlin Court
    Sunnyvale, CA 94089
    e-mail: [email-masked]

Martini, et al.                                                [Page 25]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

    Kireeti Kompella
    Juniper Networks
    1194 N. Mathilda Ave
    Sunnyvale, CA 94089
    e-mail: [email-masked]

Martini, et al.                                                [Page 26]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

11. Appendix A - C-bit Handling Procedures Diagram

                    ------------------
                Y   | Received Label |       N
             -------|  Mapping Msg?  |--------------
             |      ------------------             |
         --------------                            |
         |            |                            |
      -------      -------                         |
      | C=0 |      | C=1 |                         |
      -------      -------                         |
         |            |                            |
         |    ----------------                     |
         |    | Control Word |     N               |
         |    |    Capable?  |-----------          |
         |    ----------------          |          |
         |          Y |                 |          |
         |            |                 |          |
         |   ----------------           |          |
         |   | Control Word |  N        |          |
         |   |  Preferred?  |----       |          |
         |   ----------------   |       |          |
         |          Y |         |       |          |
         |            |         |       |   ----------------
         |            |         |       |   | Control Word |
         |            |         |       |   |  Preferred?  |
         |            |         |       |   ----------------
         |            |         |       |     N |     Y |
         |            |         |       |       |       |
       Send         Send      Send    Send    Send    Send
        C=0          C=1       C=0     C=0     C=0     C=1
                                |       |       |       |
                             ----------------------------------
                             | If receive the same as sent,   |
                             | PW setup is complete. If not:  |
                             ----------------------------------
                                |       |       |       |
                               ------------------- -----------
                               |     Receive     | | Receive |
                               |       C=1       | |   C=0   |
                               ------------------- -----------
                                        |               |
                                  Wait for the        Send
                                  next message     Wrong C-Bit
                                                        |
                                                   Send Label
                                                Mapping Message

Martini, et al.                                                [Page 27]
^L
Internet Draft  draft-ietf-pwe3-control-protocol-02.txt    February 2003

Martini, et al.                                                [Page 28]

Network Working Group                                       Luca Martini
Internet Draft                                           Nasser El-Aawar
Expiration Date: August 2003                Level 3 Communications, LLC.

Giles Heron                                                Eric C. Rosen
PacketExchange Ltd.                                  Cisco Systems, Inc.

                                                           February 2003

Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Networks

                 draft-ietf-pwe3-ethernet-encap-02.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

   An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 Protocol
   Data Units over an IP or MPLS network. This enables service providers
   to offer "emulated" ethernet services over existing IP or MPLS
   networks. This document specifies the encapsulation of Ethernet/802.3
   PDUs within a pseudowire. It also specifies the procedures for using
   a PW to provide a "point-to-point ethernet" service.

Martini, et al.                                                 [Page 1]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

Table of Contents

    1      Specification of Requirements  ..........................   2
    2      Introduction  ...........................................   2
    3      Requirements for Ethernet Pseudo-Wires Emulating Point-to-Point Ethernet Links  4
    3.1    Frame Processing at the PW Endpoints  ...................   6
    3.1.1  Encapsulation  ..........................................   6
    3.1.2  Tagged Mode  ............................................   6
    3.1.3  MTU Management on the PE/CE Links  ......................   6
    3.1.4  Frame Ordering  .........................................   6
    3.1.5  Frame Error Processing  .................................   7
    3.1.6  IEEE 802.3x Flow Control Interworking  ..................   7
    3.2    PW Setup and Maintenance  ...............................   7
    3.3    Management  .............................................   7
    3.4    The Control Word  .......................................   8
    3.4.1  Setting the sequence number  ............................   8
    3.4.2  Processing the sequence number  .........................   9
    3.5    QoS Considerations  .....................................   9
    3.6    Security Considerations  ................................  10
    3.7    PSN MTU Requirements  ...................................  10
    4      Intellectual Property Disclaimer  .......................  11
    5      References  .............................................  11
    6      Author Information  .....................................  12
           Appendix A - Interoperability Guidelines  ...............  15
           Appendix B - QoS Details  ...............................  16

1. Specification of Requirements

   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

2. Introduction

   An Ethernet Pseudowire (PW) allows Ethernet/802.3 Protocol Data Units
   (PDUs) to be carried over an IP network or an MPLS network. In
   addressing the issues associated with carrying an Ethernet PDU over a
   PSN, this document assumes that a Pseudowire (PW) has been set up by
   some means outside the scope of this document. This may be via manual
   configuration, or a signaling protocol such as that defined in
   [PWE3-CTRL] or [L2TPv3]. As described in [PWE3-FRAME], this PW may be

Martini, et al.                                                 [Page 2]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

   tunneled through an MPLS, IPv4 or IPv6 PSN.

   In addition to the Ethernet PDU format used within the pseudowire,
   this document discusses:

     - Procedures for using a PW in order to provide a pair of CEs with
       an emulated (point-to-point) ethernet service, including the
       procedures for the processing of PE-bound and CE-bound ethernet
       PDUs. [PWE3-FRAME]

     - Ethernet-specific QoS and security considerations

     - Inter-domain transport considerations for Ethernet PW

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

           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

   The "emulated service" shown in Figure 1 is, strictly speaking, a
   bridged LAN; the PEs have MAC interfaces, consume MAC control frames,
   etc. However, the procedures specified herein only support the case
   in which there are two CEs on the "emulated LAN". Hence we refer to
   this service as "emulated point-to-point ethernet". Specification of
   the procedures for using pseudowires to emulate LANs with more than
   two CEs are out of scope of the current document.

Martini, et al.                                                 [Page 3]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

   +-------------+                                +-------------+
   |  Emulated   |                                |  Emulated   |
   |  Ethernet   |                                |  Ethernet   |
   | (including  |         Emulated Service       | (including  |
   |  VLAN)      |<==============================>|  VLAN)      |
   |  Services   |                                |  Services   |
   +-------------+           Pseudo Wire          +-------------+
   |Demultiplexer|<==============================>|Demultiplexor|
   +-------------+                                +-------------+
   |    PSN      |            PSN Tunnel          |    PSN      |
   | MPLS or IP  |<==============================>| MPLS or IP  |
   +-------------+                                +-------------+
   |  Physical   |                                |  Physical   |
   +-----+-------+                                +-----+-------+

      Figure 2: Ethernet PWE3 Protocol Stack Reference Model

   For the purpose of this document, PE1 will be defined as the ingress
   router, and PE2 as the egress router. A layer 2 PDU will be received
   at PE1, encapsulated at PE1, transported, decapsulated at PE2, and
   transmitted out of PE2.

3. Requirements for Ethernet Pseudo-Wires Emulating Point-to-Point
   Ethernet Links

   An Ethernet PW emulates a single Ethernet link between exactly two
   endpoints. The mechanisms described in this document are agnostic to
   that which is beneath the "Pseudo Wire" level in Figure 2, concerning
   itself only with the "Emulated Service" portion of the stack.

   The following reference model describes the termination point of each
   end of the PW within the PE:

Martini, et al.                                                 [Page 4]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

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

           Figure 3: 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 frame that is received at point A,
   unaltered, to the point A in the corresponding PE at the other end of
   the PW.

   The "NSP" function includes frame processing that is required for the
   Ethernet frames that are forwarded to the PW termination point. Such
   functions may include stripping, overwriting or adding VLAN tags,
   physical port multiplexing and 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 (NSP) 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 frames according to the PSN type in use.

   An ethernet PW can operate in one of two modes: "raw mode" or "tagged
   mode".  In tagged mode, each frame MUST contain an 802.1Q VLAN tag,
   and the tag value is meaningful to the NSPs at the two PW endpoints.
   That is, the two endpoints must have some agreement (signaled or
   manually configured) on how to process the tag. On a raw mode PW, a
   frame MAY contain an 802.1Q VLAN tag, but if it does, the tag is not

Martini, et al.                                                 [Page 5]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

   meaningful to the NSPs, and passes transparently through them.

3.1. Frame Processing at the PW Endpoints

3.1.1. Encapsulation

   The entire Ethernet frame without any preamble or FCS is transported
   as a single frame over the Pseudowire.  Note that when using the
   signaling procedures defined in [PWE3-CRTL] or [L2TPv3], a "Raw Mode"
   PW should be signaled as being of type "Ethernet".

3.1.2. Tagged Mode

   The ethernet frame may contain an 802.1Q tag, in this case the PE
   MUST signal that the PW will is transporting ethernet frames
   including 802.1Q tags. In this case all frames in a PW MUST have the
   same 802.1Q tag value.  Note that the tag may be overwritten by the
   NSP function at ingress or at egress. Note that when using the
   signaling procedures defined in [PWE3-CRTL] or [L2TPv3], a "Tagged
   Mode" PW should be signaled as being of type "Ethernet VLAN".

3.1.3. MTU Management on the PE/CE Links

   The Ethernet PW MUST NOT be enabled unless it is known that the MTUs
   of the CE-PE links are the same at both ends of the PW.

3.1.4. 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.  An ethernet PW can, through use of
   the control word, provide strict frame ordering. If this option is
   enabled, any frames which get misordered by the PSN will be dropped
   by the receiving PW endpoint. If strict frame ordering is a
   requirement for a particular PW, this option MUST be enabled.

Martini, et al.                                                 [Page 6]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

3.1.5. Frame Error Processing

   An encapsulated Ethernet frame traversing a psuedo-wire may be
   dropped, corrupted or delivered out-of-order. As described in [PWE3-
   REQ], frame-loss, corruption, and out-of-order delivery is considered
   to be a "generalized bit error" of the psuedo-wire. PW frames that
   are corrupted will be detected at the PSN layer and dropped.

   At the ingress of the PW the native Ethernet frame error processing
   mechanisms MUST be enabled. Therefore, if a PE device receives an
   Ethernet frame containing hardware level CRC errors, framing errors,
   or a runt condition, the frame MUST be discarded on input. Note that
   defining this processing is part of the NSP function and is outside
   the scope of this draft.

3.1.6. IEEE 802.3x Flow Control Interworking

   In a standard gigabit 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.2. PW Setup and Maintenance

   This document assumes that a mechanism exists to set up the ethernet
   PW.  Maintenance of the PW (e.g. keepalives, status updates, etc) is
   generally tied closely to the PW Setup mechanisms. [PWE3-CTRL] and
   [L2TPv3] define two mechanisms for setup and maintenance of Ethernet
   PWs.

3.3. Management

   The Ethernet PW management model follows the general management
   defined in [PWE3-FRAME] and [PWE3-MIB]. Many common PW management
   facilities are provided here, with no additional Ethernet specifics
   necessary.  Ethernet-specific parameters are defined in an additional
   MIB module, [PW-ENET-MIB].

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

Martini, et al.                                                 [Page 7]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

3.4. The Control Word

   When carrying Ethernet over an IP or MPLS backbone sequentiality may
   need to be preserved.  The OPTIONAL control word defined here
   addresses this requirement.  Implementations MUST support sending no
   control word, and MAY support sending a control word.

   In all cases the egress router must be aware of whether the ingress
   router will send a control word over a specific virtual circuit.
   This may be achieved by configuration of the routers, or by
   signaling, for example as defined in [PWE3-CRTL].

   The control word is defined 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |       Sequence Number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In the above diagram the first 16 bits are reserved for future use.
   They MUST be set to 0 when transmitting, and MUST be ignored upon
   receipt.

   The next 16 bits provide a sequence number that can be used to
   guarantee ordered frame delivery. The processing of the sequence
   number field is OPTIONAL.

   The sequence number space is a 16 bit, unsigned circular space. The
   sequence number value 0 is used to indicate an unsequenced frame.

3.4.1. Setting the sequence number

   For a given PW, and a pair of routers PE11 and PE2, if PE11 supports
   frame sequencing then the following procedures should be used:

     - the initial frame transmitted on the PW MUST use sequence number
       1
     - subsequent frames MUST increment the sequence number by one for
       each frame
     - when the transmit sequence number reaches the maximum 16 bit
       value (65535) the sequence number MUST wrap to 1

   If the transmitting router PE1 does not support sequence number
   processing, then the sequence number field in the control word MUST
   be set to 0.

Martini, et al.                                                 [Page 8]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

3.4.2. Processing the sequence number

   If a router PE2 supports receive sequence number processing, then the
   following procedures should be used:

   When a PW is initially set up, the "expected sequence number"
   associated with it MUST be initialized to 1.

   When a frame is received on that PW, the sequence number should be
   processed as follows:

     - if the sequence number on the frame is 0, then the frame passes
       the sequence number check

     - otherwise if the frame sequence number >= the expected sequence
       number and the frame sequence number - the expected sequence
       number < 32768, then the frame is in order.

     - otherwise if the frame sequence number < the expected sequence
       number and the expected sequence number - the frame sequence
       number >= 32768, then the frame is in order.

     - otherwise the frame is out of order.

   If a frame passes the sequence number check, or is in order then, it
   can be delivered immediately. If the frame is in order, then the
   expected sequence number should be set using the algorithm:

   expected_sequence_number := frame_sequence_number + 1 mod 2**16
   if (expected_sequence_number = 0) then expected_sequence_number := 1;

   Packets which are received out of order MAY be dropped or reordered
   at the discretion of the receiver.

   If a router PE2 does not support receive sequence number processing,
   then the sequence number field MAY be ignored.

3.5. QoS Considerations

   The ingress PE MAY consider the user priority (PRI) field [802.1Q] of
   the VLAN tag header when determining the value to be placed in a QoS
   field of the encapsulating protocol (e.g., the EXP fields of the MPLS
   label stack or the DSCP of an IP packet).  In a similar way, the
   egress PE MAY consider the QoS field of the PSN's encapsulating
   protocol when queuing the frame for CE-bound.

   A PE MUST support the ability to carry the Ethernet PW as a best

Martini, et al.                                                 [Page 9]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

   effort service over the PSN.  PRI bits are kept transparent between
   PE devices, regardless of the QoS support of the PSN.

   If an 802.1Q VLAN field is added at the PE, a default PRI setting of
   zero MUST be supported, a configured default value is recommended, or
   the value may be mapped from the QoS field of the PSN, as referred to
   above.

   A PE may support additional QoS support by means of one or more of
   the following methods:

        -i. One COS per PW End Service (PWES), mapped to a single COS PW
            at the PSN.
       -ii. Multiple COS per PWES mapped to a single PW with multiple
            COS at the PSN.
      -iii. Multiple COS per PWES mapped to multiple PWs at the PSN.

   Examples of the cases above and details of the service mapping
   considerations 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.

3.6. Security Considerations

   The ethernet pseudowire type is subject to all of the general
   security considerations discussed in [PWE3-ARCH].

   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) environment are not discussed
   here as they are not within the scope of this draft.

3.7. PSN MTU Requirements

   The PSN MUST be configured with an MTU that is large enough to
   transport a maximum sized ethernet frame which has been encapsulated
   with a control word, a pseudowire demultiplexor, and a tunnel
   encapsulation.  If MPLS is used as the tunneling protocol, for
   example, this is likely to be 8 or more bytes greater than the
   largest frame size. Other tunneling protocols may have longer headers
   and require larger MTUs. If the ingress router determines that an
   encapsulated layer 2 PDU exceeds the MTU of the tunnel through which
   it must be sent, the PDU MUST be dropped. If an egress router
   receives an encapsulated layer 2 PDU whose payload length (i.e., the

Martini, et al.                                                [Page 10]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

   length of the PDU itself without any of the encapsulation headers),
   exceeds the MTU of the destination layer 2 interface, the PDU MUST be
   dropped.

4. Intellectual Property Disclaimer

   This document is being submitted for use in IETF standards
   discussions.

5. References

   [PWE3-CRTL] "Transport of Layer 2 Frames Over MPLS",
        Martini, L., et al., draft-ietf-pwe3-control-protocol-01.txt,
        ( work in progress ), February 2003.

   [PWE3-ARCH] "Protocol Layering in PWE3"
        Bryant, et al., draft-ietf-pwe3-protocol-layer-00.txt
        ( work in progress ), November 2002.

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

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

   [PW-MIB] "Pseudo Wire (PW) Management Information Base using SMIv2",
        Zelig, D., Mantin, S., Nadeau, T., Danenberg, D.,
        draft-zelig-pw-mib-02.txt, ( work in progress), February 2002.

   [PW-ENET-MIB] "Ethernet Pseudo Wire (PW) Management Information
        Base", Zelig, D., Nadeau, T., draft-zelig-pw-enet-mib-00.txt,
        ( work in progress ) February 2002.

   [802.3] IEEE, ISO/IEC 8802-3: 2000 (E), "IEEE Standard for
        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.

   [802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and

Martini, et al.                                                [Page 11]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

        Metropolitan Area Networks: Virtual Bridged Local Area
        Networks", 1998.

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

6. Author Information

   Luca Martini
   Level 3 Communications, LLC.
   1025 Eldorado Blvd.
   Broomfield, CO, 80021
   e-mail: [email-masked]

   Nasser El-Aawar
   Level 3 Communications, LLC.
   1025 Eldorado Blvd.
   Broomfield, CO, 80021
   e-mail: [email-masked]

   Giles Heron
   PacketExchange Ltd.
   The Truman Brewery
   91 Brick Lane
   LONDON E1 6QL
   United Kingdom
   e-mail: [email-masked]

   Dan Tappan
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824
   e-mail: [email-masked]

   Eric Rosen
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824
   e-mail: [email-masked]

Martini, et al.                                                [Page 12]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

   Steve Vogelsang
   Laurel Networks, Inc.
   Omega Corporate Center
   1300 Omega Drive
   Pittsburgh, PA 15205
   e-mail: [email-masked]

   Andrew G. Malis
   Vivace Networks, Inc.
   2730 Orchard Parkway
   San Jose, CA 95134
   e-mail: [email-masked]

   Vinai Sirkay
   Vivace Networks, Inc.
   2730 Orchard Parkway
   San Jose, CA 95134
   e-mail: [email-masked]

   Vasile Radoaca
   Nortel Networks
   600  Technology Park
   Billerica MA 01821
   e-mail: [email-masked]

   Chris Liljenstolpe
   Cable & Wireless
   11700 Plaza America Drive
   Reston, VA 20190
   e-mail: [email-masked]

   Kireeti Kompella
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089
   e-mail: [email-masked]

   Tricci So
   e-mail: [email-masked]

Martini, et al.                                                [Page 13]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

   XiPeng Xiao
   Redback Networks
   300 Holger Way,
   San Jose, CA 95134
   e-mail: [email-masked]

   Chris Flores
   Austin, Texas
   e-mail: [email-masked]

   David Zelig
   Corrigent Systems
   126, Yigal Alon St.
   Tel Aviv, ISRAEL
   e-mail: [email-masked]

   Raj Sharma
   Luminous Netwokrs, Inc.
   10460 Bubb Road
   Cupertino, CA 95014
   e-mail: [email-masked]

   Nick Tingle
   TiMetra Networks
   274 Ferguson Drive
   Mountain View, CA 94043
   e-mail: [email-masked]

   Sunil Khandekar
   TiMetra Networks
   274 Ferguson Drive
   Mountain View, CA 94043
   email: [email-masked]

   Loa Andersson
   Utfors
   P.O. Box 525,
   SE-169 29 Solna, Sweden
   e-mail: [email-masked]

Martini, et al.                                                [Page 14]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

Appendix A - Interoperability Guidelines

Configuration Options

   The following is a list of the configuration options for a point-to-
   point Ethernet PW 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 |               |
                 | 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 i)
                 |               |               |
   --------------|---------------|---------------|------------------
   4) Tag        | No Tag        |Remove/add Tag | (note ii)
                 |               |field          |
                 |               |               |
                 |               |               |
   --------------|---------------|---------------|------------------

                Figure 4: Configuration Options

   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:

        -i. Mode #3 MAY be limited to adding VLAN NULL only, since
            change of VLAN or association to specific VLAN can be done
            at the PW CE-bound side.

Martini, et al.                                                [Page 15]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

       -ii. Mode #4 exists in layer 2 switches, but is not recommended
            when operating with PW since it may not preserve the user's
            PRI bits.  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.

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.  Optionally, the PE MAY
   simply discard PAUSE frames.

   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.

Appendix B - QoS Details

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

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

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

     - The classification to the PW is based on VLAN field and the PRI
       bits, and frames with different PRI bits are mapped to different
       PWs. An example is to map a PWES to different L-LSPs in MPLS PSN
       in order to support multiple COS over an L-LSP capable network,
       or to multiple L2TPv3 sessions [L2TPv3].

Martini, et al.                                                [Page 16]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

       The specific value to be assigned at the PSN for various COS is
       out of scope for this document.

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 COS
   is application specific and depends on the agreement between the
   customer and the PW provider.  However, the following principles
   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 |
   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 5: IEEE 802.1Q COS Service Mapping

Martini, et al.                                                [Page 17]

Internet Draft   draft-ietf-pwe3-ethernet-encap-02.txt     February 2003

Drop precedence

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

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

Martini, et al.                                                [Page 18]