Internet Draft                                         Don Fedyk, Nortel
Category: Standards Track                           Himanshu Shah, Ciena
Expiration Date: January 14, August 25, 2009                    Nabil Bitar, Verizon
                                                 Attila Takacs, Ericsson

                                                           July 14, 2008

                    GMPLS

                                                       February 25, 2009

      Generalized Multiprotocol Label Switching (GMPLS) control of
                            Ethernet PBB-TE

             draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txt

             draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt

Status of this Memo

      This Internet-Draft is submitted to IETF in full conformance with
      the provisions of BCP 78 and BCP 79.

      This memo provides information for the Internet community.  It
      does not specify an Internet standard of any kind.  Distribution
      of this memo is unlimited.

      By submitting this Internet-Draft, each author represents that any
      applicable patent or other IPR claims of which he or she is aware
      have been or will be disclosed, and any of which he or she becomes
      aware will be disclosed, in accordance with Section 6 of BCP 78 and BCP 79.

      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/1id-abstracts.html

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html

      This Internet-Draft will expire on January 14, August 25, 2009.

Copyright and License Notice

      Copyright (C) The (c) 2009 IETF Trust (2008). and the persons identified as the
      document authors.  All rights reserved.

      This document is subject to BCP 78 and the IETF Trust's Legal
      Provisions Relating to IETF Documents
      (http://trustee.ietf.org/license-info) in effect on the date of
      publication of this document. Please review these documents
      carefully, as they describe your rights and restrictions with
      respect to this document.

Abstract

   This specification is complementary to the GMPLS controlled Ethernet
   architecture document [ARCH] and describes the technology specific
   aspects of GMPLS control for Provider Backbone Bridging Bridge Traffic
   Engineering (PBB-TE) [IEEE 802.1Qay].  The necessary GMPLS extensions
   and mechanisms are described to establish Ethernet PBB-TE point to
   point (P2P) and point to multipoint (P2MP) connections. This document
   supports, but does not modify, the standard IEEE data plane.

Table of Contents

 1      Introduction  ..............................................   3   4
 1.1    Co-authors  ................................................   3   4
 2      Terminology  ...............................................   4   5
 2.1    PBB-TE and GMPLS Terminology  ........................................  ..............................   5
 3      Creation and Maintenance of PBB-TE Service Instances paths using GMPLS  ......   6
 3.1    Ethernet Service  ..........................................   7
 3.2    Addresses, Interfaces, and Labels  .........................   7
 4      Specific Procedures  .......................................  10   9
 4.1    P2P connections  ...........................................  10 Ethernet LSPs   ........................................   9
 4.1.1  Shared Forwarding  .........................................  11  10
 4.1.2  P2P connections with procedures for shared forwarding  ....................  12  ..........  11
 4.1.3  Dynamic P2P symmetry with shared forwarding  ...............  13
 4.1.4  Planned P2P symmetry  ......................................  13
 4.1.5  P2P Path Maintenance  ......................................  13  11
 4.2    P2MP Signaling  ............................................  14
 4.3    P2MP ESP-MAC DA Connections  ...............................  14
 4.3.1  Setup procedures  ..........................................  14
 4.3.2 Ethernet-LSPs  ........................................  12
 4.2.1  Maintenance Procedures  ....................................  14
 4.4  12
 4.3    PBB-TE Ethernet Label  ............................................  15
 4.5    OAM MEP ID and MA ID synchronization  ......................  16
 4.6  .....................................  12
 4.4    Protection Paths  ..........................................  16  13
 4.5    Service Instance Identification   ..........................  13
 5      Error conditions  ..........................................  17  15
 5.1     Invalid ESP-VID value for PBB-TE MSTI range  ...............  17  .........................  15
 5.2    Invalid MAC Address  .......................................  17  15
 5.3    Invalid ERO for UPSTREAM_LABEL Object  .....................  17
 5.4    Invalid ERO for LABEL_SET Object  ..........................  18
 5.5    Switch is not ESP P2MP capable  ............................  18
 5.6    Invalid ESP-VID in UPSTREAM_LABEL object  ..................  18  15
 6      Deployment Scenarios  ......................................  18
 7      Security Considerations  ...................................  18
 8  15
 7      IANA Considerations  .......................................  18
 9  16
 7.1    Error Codes  ...............................................  16
 8      References  ................................................  19
 9.1  16
 8.1    Normative References  ......................................  19
 9.2  16
 8.2    Informative References  ....................................  19
10  16
 9      Acknowledgments  ...........................................  21
11  17
10      Author's Address  ..........................................  21
 A.     Rational and mechanism for PBB_TE Ethernet Forwarding  .....  22
 A.1.   Overview of configuration of VID/DMAC tuples  ..............  25
 A.2    Overview of configuration of VID port membership  ..........  28
 A.3    OAM Aspects  ...............................................  28
 A.4    QOS Aspects  ...............................................  29
 A.5    Resiliency Aspects  ........................................  29
 A.5.1  E2E Path protection  .......................................  29
12      Full Copyright Statement  ..................................  30
13      Intellectual Property  .....................................  30  17

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1. Introduction

   The IEEE 802.1 is specifying Traffic Engineered Ethernet paths in the Provider Backbone Bridged network Bridge Traffic Engineering (PBB-TE)
   [IEEE 802.1Qay] based on
   managed objects that can be separated from standard supports the establishment of explicitly
   routed traffic engineered paths within Provider Backbone Bridged
   (PBB) networks. PBB-TE allows disabling: the Spanning Tree Control
   Plane Protocol,
   unknown destination address forwarding and statically configured source address learning
   for administratively selected VLAN Identifiers.  With PBB-TE an
   external provisioning system or managed by another control plane.
   These paths have minor changes to Ethernet data plane specified can be used to
   configure static entries in the IEEE. IEEE 802 termed these managed objects of bridges and so
   establish traffic engineered paths "PBB-TE service instances". in the network.

   Generalized MPLS (GMPLS) [RFC3945] is a family of control plane
   protocols designed to operate in connection oriented and traffic
   engineering transport networks. GMPLS is applicable to a range of
   network technologies including Layer 2 Switching capable networks
   (L2SC).  The purpose of this document is to specify extensions for a
   GMPLS based control plane to manage PBB-TE service instances. explicitly routed traffic
   engineered paths. This draft is aligned complementary to with the GMPLS
   Ethernet Label Switching Architecture and Framework [ARCH].

   It should be noted that due to the changes in the separation of the
   Spanning Tree Control plane and PBB-TE forwarding, the behavior of
   PBB-TE for the specified VLAN range is a new behavior. (It does not
   default to conventional Ethernet forwarding with learning at any
   time).  Note, currently PBB-TE is under specification in the
   Interworking Task Group of the IEEE 802.1 Working Group (WG), the
   actual draft has version 3.5. Appendix A summarizes the rational for
   this data plane technology until the IEEE specification is released
   for Working Group Ballot in the IEEE 802.1 WG.

1.1. Co-authors

   This document is the result the a large team of authors and
   contributors.  The following is a list of the co-authors:

      Don Fedyk (Nortel)
      David Allan  (Nortel)
      Himanshu Shah (Ciena)
      Nabil Bitar (Verizon)
      Attila Takacs (Ericsson)
      Diego Caviglia (Ericsson)
      Alan McGuire (BT)
      Nurit Sprecher (Nokia Siemens Networks)
      Lou Berger (LabN)

2. Terminology

   In addition to well understood GMPLS terms, this memo uses
   terminology from IEEE 802.1 and introduces a few new terms:  [IEEE 802.1Qah] [IEEE 802.1Qay]:

     - BCB                 Backbone Core Bridge
     - BEB                 Backbone Edge Bridge
     - B-MAC               Backbone MAC
     - B-VID               Backbone VLAN ID
     - B-VLAN              Backbone VLAN
     - CBP                 Customer Backbone Port
     - CCM                 Continuity Check Message
     - COS                 Class of Service
     - CLI                 Command Line Interface
     - CIP CNP                 Customer Instance Network Port
     - C-MAC               Customer MAC
     - C-VID               Customer VLAN ID
     - C-VLAN              Customer VLAN
     - DMAC                Destination MAC Address
     - ESP                 Ethernet Switched Path
     - ESP-MAC SA          ESP Source MAC Address
     - ESP-MAC DA          ESP Destination MAC Address
     - ESP-VID             ESP VLAN ID
     - Eth-LSP             Ethernet Label Switched Path
     - IB-BEB              A BEB comprising of both I and B components
     - I-SID               Ethernet Service Instance Identifier
     - LBM                 Loopback Message
     - LBR                 Loopback Reply
     - LLDP                Link Layer Discovery Protocol
     - LMM                 Loss Measurement Message
     - LMR                 Loss Measurement Reply
     - MAC                 Media Access Control
     - MMAC                Multicast or Group MAC
     - MSTID               Multiple Spanning Tree Identifier
     - MP2MP               Multipoint to multipoint address
     - PBB                 Provider Backbone Bridges
     - PBB-TE              Provider Backbone Bridges Traffic Engineering
     - PIP                 Provider Instance Port
     - PCP                 Priority Code Points
     - PNP                 Provider Network Port
     - P2P                 Point to Point
     - P2MP                Point to Multipoint
     - QOS                 Quality of Service
     - ESP-MAC SA          Source MAC Address
     - S-VID               Service VLAN ID
     - SVL                 Shared VLAN Learning
     - TE-MSTID            Traffic Engineering MSTID TESI                TE Service Instance
     - VID                 VLAN ID
     - VLAN                Virtual LAN

2.1. PBB-TE and GMPLS Terminology

   The PBB-TE specification has defined [IEEE 802.1Qay] defines some additional
   terminology to clarify the PBB-TE functions. We repeat these here in
   expanded context to translate from IEEE to GMPLS terminology.

     - Ethernet Switched Path (ESP):
       A provisioned traffic engineered unidirectional connectivity path
       between two or more Customer Backbone Ports (CBPs) which extends
       over a Provider Backbone Bridge Network (PBBN). The path is
       identified by the 3-tuple <ESP-MAC DA, ESP-MAC SA, ESP-VID> where
       the ESP-VID value ESP-VID>. An
       ESP is allocated to the PBB-TE Multiple Spanning
       Tree Identifier (MSTID). (A set of VIDs for PBB-TE is allocated
       to the new TE-MSTID.) point-to-point (P2P) or point-to-multipoint (P2MP). An ESP
       is analogous to a GMPLS (unidirectional) point-to-point or point-to-
       multipoint LSP. We use the term Ethernet-LSP (Eth-LSP) for GMPLS
       established ESPs.

     - Point-to-Point PBB-TE service instance: Point-to-point ESP:
       An instance ESP between two CBPs. The ESP-DA and the ESP-SA in the ESP's
       3- tuple identifier are the individual MAC addresses of the two
       CBPs.

     - Point-to-multipoint ESP:
       An ESP among one root CBP and n leaf CBPs.  The ESP-DA in the
       ESP's 3-tuple identifier is a group MAC address identifying the n
       leaf CBPs, and the ESP-SA is the individual MAC address of the
       root.
     - Point-to-Point PBB-TE service provided instance (P2P TESI):
       A service instance supported by two unidirectional co-
       routed point-to-point ESPs where the
       ESPs' endpoints have the same CBP MAC addresses. The two
       unidirectional ESP are forming a bidirectional service. A GMPLS
       bidirectional path is analogous The PBB-
       TE standard [IEEE 802.1Qay] notes the following: for reasons
       relating to a P2P PBB-TE Service instance.

     - Point-to-Multipoint PBB-TE TE service instance:
       An instance of monitoring diagnostics, operational
       simplicity, etc. the MAC service provided by a set of IEEE PBB-TE standard assumes that the point-
       to-point ESPs which
       comprises one point-to-multipoint ESP plus n unidirectional associated with a point-to-point ESPs.  The n P2P ESPs TESI are co-
       routed.  Support for a point-to-point TE services which comprises
       non co-routed but ESPs is problematic, and is not defined in the
       opposite direction from the root-to-leaf sub-ESPs comprising the
       P2MP ESP.  Note that due to traditional Ethernet data plane
       design this definition
       standard.  Hence, a GMPLS bidirectional LSP is different analogous to a P2P
       TE Service instance. We use the way P2MP connections
       are generally defined. That is, while P2MP connections are
       generally root-to-leaves unidirectional trees, P2MP PBB-TE
       services can be regarded as term bidirectional trees. Ethernet-LSP
       (Eth-LSP) for GMPLS established P2P PBB-TE Service instances.

3. Creation and Maintenance of PBB-TE Service Instances paths using GMPLS

   IEEE PBB-TE is an Ethernet a connection oriented technology, being specified
   in the IEEE, which can be controlled by configuration of static
   filtering entries (see Appendix A for some details on the rational
   for the data plane). PBB-TE ESPs are created switch Ethernet technology. PBB-TE ESPs
   are created switch by switch by simple configuration of Ethernet logical ports and assignment of PBB-
   TE labels or by a control plane.
   forwarding entries. This document describes the use of GMPLS as a
   valid control plane for Eth-LSPs that are based on PBB-TE ESPs. A
   Point-to-Point PBB-TE service instance is a form of Ethernet LSP
   (Eth-LSP) which is more broadly defined in [ARCH].  This memo
   describes GMPLS as a mechanism to automate set-up the set-up, teardown,  protection and
   recovery of PBB-TE  ESPs and TESIs and specifies the specific
   TLVs required RSVP-TE
   extensions for the control of PBB-TE service instances.

   When configuring a

   PBB-TE ESP with GMPLS, the ESP-MAC DA and ESP-VID services are carried in a generalized label object always originated and terminated on IB-
   Backbone Edge Bridges (IB-BEBs). IB-BEBs are assigned hop constituted of I and B
   components, this is illustrated in Figure 1.

   An Ethernet service supported by hop
   but are invariant within a domain. This invariance PBB-TE TESI is similar always attached to
   GMPLS operation in transparent optical networks. As
   a Customer Network Port (CNP) of the I-component. A Service Instance
   Identifier (I-SID) is typical with
   other technologies controlled by GMPLS, assigned for the data plane receiver must
   accept, service. The I and usually assigns, labels B
   components have internal ports which are connected via an internal
   LAN. These internal ports are the Provider Instance Ports (PIPs) and
   Customer Backbone Ports (CBPs). PIPs and CBPs are not visible outside
   the IB-BEB. ESPs are always originated and terminated on CBP ports
   and use the MAC address of that port.  The I-Component encapsulates
   the service frames arriving from its available label pool.
   This, together with the label invariance requirement mentioned above,
   result in each PBB-TE label being CNP by adding an I-SID and a domain wide unique label,
   complete Ethernet MAC header with a
   unique ESP-VID + an ESP-MAC DA, for each direction. DA and ESP-MAC SA. The following illustrates
   B-Component adds the identifiers for Labels and ESPs. ESP-VID.

   GMPLS Upstream Label          <ESP:MAC1(DA), VID1> (60 bits)
   GMPLS Downstream Label        <ESP:MAC2(DA), VID2> (60 bits)
   Upstream PBB-TE ESP 3-tuple   <ESP:MAC1, MAC2, VID1> (108 bits)
   Downstream PBB-TE ESP 3-tuple <ESP:MAC2, MAC1, VID2> (108 bits)

                          Table 1 Labels and ESPs
   The MAC is domain wide unique in the network. PBB-TE defines being defined here to establish ESPs and TESIs. As it can be
   seen from the
   tuple above this requires configuration of <ESP-MAC DA, ESP-MAC SA, ESP-VID> as a unique connection
   identifier in the data plane but the forwarding operation only uses both the ESP-MAC DA (DMAC) I and B
   components of the ESP-VID in each direction. Note that IB-BEBs connected by the MAC addresses for PBB-TE ESPs.

   In the GMPLS control plane TE Router IDs are part of used to identify the IB-
   BEBs and Backbone Component
   Relay (B-Component) Core Bridges (BCBs), and TE Links that describes
   links connected to PNPs and CNPs.  TE Links are not associated with Provider addresses
   corresponding
   CBPs or PIPs.

   Note that since multiple internal CBPs may exit an IB-BEB receiving a
   PATH message must be able to determine the Customer Backbone ports (CBP) of appropriate CBP that is
   the Backbone
   Component (B-Component) as described in section 3.2.
   The ESP-VID (VID) typically comes from a small number termination point of VIDs
   dedicated to PBB-TE MSTID. The ESP-VID (VID) can be reused across
   ESPs. There is no requirement the ESP-VID for two ESPs that form a
   PBB-TE Service instance be ESP. To this end, IB-BEBs SHOULD
   advertises the same.

   Several attributes may be associated with an Eth-LSP.  These are
   reviewed CNP TE Links in Section 3 of [ARCH]. Several other aspects of GMPLS
   covered by [ARCH] also apply equally to PBB-TE.  This includes the GMPLS routing and addressing model, link management, path
   computation and selection, control plane and multiple domains.

3.1. Ethernet Service

   Ethernet Switched Paths that are setup either by configuration or RSVP-TE
   signaling can be used to provide an Ethernet service SHOULD use the CNP TE Links to customers of identify the Ethernet network.  The Metro Ethernet Forum has defined some
   services in [MEF.6] (e.g., Ethernet Private Line), and these are also
   aligned with ITU-T G.8011-x Recommendations.  Of particular interest
   are the bandwidth profile parameters in [MEF.10] and whose associated
   bandwidth profile algorithm are based on [RFC4115] [RFC3270].
   Consideration should be given to supporting these in any signaling
   extensions for Ethernet LSPs. This will be addressed in a future
   version termination
   point of this specification.

3.2. Addresses, Interfaces, and Labels

   This specification uses an addressing scheme and Eth-LSPs. An IB-BEB receiving a label space for PATH message specifying one
   of its CNPs can locally determine which CBPs have internal
   connectivity to the ingress/egress connection; I-component supporting the hierarchical TE Router
   ID/Interface ID and given CNP. In the Ethernet ESP-VID/ESP-MAC DA tuple or ESP-
   VID/Multicast MAC as a label space. This draft is intended to be
   consistent with GMPLS addressing case
   there are more than one suitable CBPs, and Routing [ARCH].

   PBB-TE is defined for a PBB Network.  As with PBB services, PBB-TE no I-SID information is
   typically implemented
   provided in the Service and Backbone components of an
   IB-Backbone Edge Bridge (BEB). This is illustrated PATH message or previously in Figure 1.  The
   Ethernet service is attached to a Customer Instance Port (CIP) of the
   Backbone Service Instance (I-component) Relay. The CIP is connected
   via associated Call
   setup, then the I-Component Relay to a Virtual instance port (VIP) IB-BEB can decide freely which is
   identified with a configured service instance (I-SID) and attached to
   a Provider Instance Port (PIP). The PIP is configured to be attached
   to a customer Backbone port (CBP). (A point to point service instance
   is illustrated. A point to multipoint service could allow more than
   one CBP to be attached assign to a single PIP.) The CBP has a B-MAC that
   defines the MAC for
   requested connection.  On the PBB-TE Service Instance.  That source B-MAC
   address other hand, if there is information on
   the PIP MAC address which in the case of backbone service
   instances (I-SID) that are supported by TE service instances is configured to
   take the same value as given ESP will support, then the CBP B-MAC of the internally connected CBP
   on the B-component.  As a result, the backbone MAC addresses of
   frames associated with traffic engineered services, the ESP-MACs, are
   always equal to the CBP B-MAC.  The I-Component IB-BEB
   MUST first determine which PIP adds the ESP-MAC
   DA and the ESP-MAC SA. The B-Component CBP adds the ESP-VID.  GMPLS
   is being defined here to connect CBP MACs to signal the PBB-TE
   service Instance before the association of ESP-MAC DA and ESP-MAC SA is defined.

   The diagram also shows the addition of a TE Router ID to configured with the PBB
   switch I-SID
   and the TE Link identifier MUST assign that CBP to enable GMPLS. TE Links are not
   associated with CBPs. TE Links are associated with PNPs. TE links are
   associated with bridge identifiers of backbone edge bridges (BEB) and
   backbone core bridges (BCB). CBPs are also associated with these
   bridge ids.  For GMPLS the bridge IDs are expressed as IP addresses
   as TE- Router IDs. [RFC4990] ESP.

                      Backbone Edge Bridge (BEB)
     +------------------------------------------------------+
     |                    <TE - Router ID >                 |
     |                                                      |
     |  I-Component Relay             B-Component Relay     |
     | +-----------------------+    +---------------------+ |
     | |          +---+        |    |         B-VID       | |
     | |          |VIP|        |    | +---+         +---+ | | <TE Link>
     | |          +---+        |  +---|CBP|         |PNP|------
     | |                       |  | | +---+         +---+ | |
     | |  +---+          +---+ |  | |                     | |
    ------|CIP|
    ------|CNP|          |PIP|----+ |                     | |
     | |  +---+          +---+ |    |                     | |
     | +-----------------------+    +---------------------+ |
     |                                                      |
     |                   PBB Edge Bridge                    |
     +------------------------------------------------------+

     ^--------Configured--------------^
                                      ^-GMPLS
                            ^-----------GMPLS or Configured-^ Configured------^

                  Figure 2 Ethernet/GMPLS Addressing & Label Space 1 IB-BEBs and GMPLS identifiers

   Control  TE Router ID                     TE Router ID
   Plane       |  (TE Link)                       |
               V     |                            V          N=named port
             +----+  |                         +-----+         <port index>
   Data      |    |  |    label=ESP:VID/MAC DA |     |         <MAC>
   Plane     | PB    |  V    label=ESP:VID/MMAC   |     |         <string>
        -----N    N----------------------------N PBB     N----------
             |    |                            |(MAC)|          PBB-TE            |     |   \ Network
             |    |                            /     |     Customer     Or
             +----+                           /+-----+     Facing     Customer
              BCB                       ESP:MAC  BEB IB-BEB     Facing
                                                           Ethernet
                                                     Ports

             Figure 3 2 Ethernet/GMPLS Addressing & Label Space

   For a GMPLS based system, the TE Router ID/logical port is

   PBB-TE defines the
   logical signaling tuple of <ESP-MAC DA, ESP-MAC SA, ESP-VID> as a
   unique connection identifier for in the control data plane via which Ethernet
   layer label bindings are solicited. In order to create a P2P path an
   association must be made between the ingress and egress switch.  The
   actual label distributed via signaling and instantiated in but the switch forwarding tables identifies
   operation only uses the upstream and downstream egress ESP-
   VID/ESP-MAC ESP-MAC DA of and the PBB-TE ESP (see Figure 3).

   GMPLS uses identifiers ESP-VID in the form each direction.
   The ESP-VID typically comes from a small number of 32 bit numbers which are in the
   IP address notation which may or may not VIDs dedicated to
   PBB-TE. ESP-VIDs can be reused across ESPs. There is no requirement
   that ESP-VIDs for two ESPs that form a P2P TESI be IP addresses.  The
   provider MAC port addresses are exchanged by the LLDP [IEEE 802.1AB] same.

   When configuring a ESP with GMPLS, the ESP-MAC DA and by LMP [RFC4204] if supported. However these identifiers ESP-VID are
   merely for link control and legacy Ethernet support and have local
   link scope. Actual
   carried in a generalized label assignment is performed by the ingress object and
   egress switches using CBP MAC addresses.

   A particular PNP would have:

   - A VID/MAC
   - An IP address, which is typically the TE router ID, plus are assigned hop by hop but
   are invariant within a 32 bit
     interface Identifier also call an unnumbered link.
   - One (or more) Mnemonic String Identifiers domain. This multiple naming convention leaves the issue of resolving the set
   given one of the port identifiers. On a particular switch, mapping invariance is
   relatively straightforward.  Per [ARCH], standard similar to GMPLS mechanisms
   are used for signaling resolution. In so doing, the problem of
   setting up a path
   operation in transparent optical networks. As is reduced to figuring out what switch supports an
   egress CBP MAC address and then finding typical with other
   technologies controlled by GMPLS, the corresponding egress IP
   address and performing all signaling data plane receiver must
   accept, and routing usually assigns, labels from its available label pool.
   This, together with respect to the
   egress.

   There are several options to achieve this:

   - Provisioning - Auto discovery protocols that carry MAC address
   - Augmenting Routing TE with MAC Addresses
   - Name Servers with identifier/address registration
     The specific procedures will be clarified label invariance requirement mentioned above,
   result in each PBB-TE Ethernet Label being a subsequent version
     of this document.

4. Specific Procedures

4.1. P2P connections domain wide unique
   label, with a unique ESP-VID + ESP-MAC DA, for each direction.

   The following illustrates PBB-TE Service Instance is defined by the ESP 3-tuples Ethernet Labels and ESPs for each
   of the unidirectional ESPs. From a P2P
   TESI.

   GMPLS control plane point of view
   an Ethernet LSP is also identified as any other LSP using the 5-
   tuple [Ip_Source_Sddr, Ip_Dest_Addr, LSP_Id, Tunnel_ID,
   Extended_Tunnel_ID]. The ESP-VID and ESP-MAC DA tuple identifies the
   forwarding multiplex at transit switches and a simple degenerate form
   of the multiplex is a single P2P connection.

   This results in unique labels end to end. The data streams MAY merge,
   the forwarding entries MAY be shared but the headers are still unique
   allowing the connection to be de-multiplexed downstream.  Note that
   in addition to the Upstream Label          <ESP:MAC1(DA), VID1> (60 bits)
   GMPLS Downstream Label        <ESP:MAC2(DA), VID2> (60 bits)
   Upstream PBB-TE ESP 3-tuples the I-SID in the I-TAG also provides
   for unambiguous identification of frames belonging to a certain
   service. This adds further protection against misconfiguration and
   misconnectivity errors, by allowing simple detection and immediate
   squelching of unintended traffic.

   On the initiating and terminating switches, a function administers
   the ESP-VIDs associated with the ESP-MAC SA 3-tuple   <ESP:MAC1, MAC2, VID1> (108 bits)
   Downstream PBB-TE ESP 3-tuple <ESP:MAC2, MAC1, VID2> (108 bits)

                          Table 1 Labels and ESP-MAC DA
   respectively. ESPs

4. Specific Procedures

4.1. P2P Ethernet LSPs

   Note, PBB-TE is designed to be bidirectional and symmetrically routed
   just like Ethernet. Therefore in PBB-TE, the
   packet ESP-MAC SA That is, complete and ESP- MAC DA pair proper functionality of
   Ethernet protocols is same in the forwarding path
   and the associated reverse path except they are flipped in the
   reverse direction. only guaranteed for bidirectional Eth-LSPs.

      To initiate a bidirectional ESP-VID/ESP-MAC DA P2P or P2MP path, Eth-LSP, the initiator of the PATH
   message uses procedures outlined in [RFC3473]
   possibly augmented with [RFC4875], [RFC3473], it:

   1) Sets the LSP encoding type to Ethernet.

   2) Sets the LSP switching type to 802_1 PBB-TE suggested value 40
   [IANA to define].

   3) Sets the GPID to service type [IANA to define]. type.

   4) Sets the UPSTREAM_LABEL to the ESP-VID/ESP-MAC SA ESP-VID1/ESP-MAC1 tuple where the
   ESP-VID
      ESP-VID1 is administered from locally for the configured ESP-VID/ESP-MAC DA range. local MAC address: MAC1

   5) Optionally sets the LABEL_SET or SUGGESTED_LABEL if it chooses to
      influence the choice of ESP-VID/ESP-MAC DA.

   6) Optionally look at Call / Connection ID for Carrying I-SID.

   Intermediate and egress switch processing is not modified by this
   document, i.e., is per [RFC3473] and, in the case of P2MP, as
   extended in [RFC4875]. [RFC3473]. Note, as previously stated
   intermediate bridges supporting the 802_1 PBB-TE switching type may not MUST
   NOT modify LABEL values.

   The ESP-VID/ESP-MAC SA ESP-VID1/ESP-MAC1 tuple contained in the UPSTREAM_LABEL is used
   to create a static forwarding entry in the Filtering Database of
   bridges at each hop for the upstream direction. This behavior is
   inferred from the switching type which is 802_1 [IANA to define]. PBB-TE.  The port
   derived from the RSVP_HOP object and the ESP-VID ESP-VID1 and ESP-
   MAC DA MAC1
   included in the label PBB-TE Ethernet Label constitute the static entry.

   At the destination, a ESP-VID an ESP-VID2 is allocated in for the local MAC range for
   the ESP-MAC DA and
   address: MAC2, the ESP-VID/ESP-MAC DA ESP-VID2/ESP-MAC2 tuple is passed in a the LABEL
   object in the RESV message.  As with the PATH message, intermediate
   switch processing is per [RFC3473] and [RFC4875], [RFC3473], and the LABEL object is passed on
   unchanged, upstream.  The ESP-VID/ESP-MAC DA ESP-VID2/ESP-MAC2 tuple contained in the
   LABEL Object is installed in the forwarding table as a static
   forwarding entry at each hop. This creates a bidirectional path as
   the PATH and RESV messages follow the same path.

4.1.1. Shared Forwarding

   One capability of a connectionless Ethernet data plane is to reuse
   destination forwarding entries for packets from any source within a
   VLAN to a destination. When setting up P2P PBB-TE connections for
   multiple sources sharing a common destination this capability MAY be
   preserved provided certain requirements are met. We refer to this
   capability as Shared Forwarding.  Shared forwarding is invoked based
   on policy when conditions are met.  It is a local decision by label
   allocation at each end. end plus the path constraints.  Shared forwarding
   has no impact on the actual paths setup, but it allows the reduction
   of forwarding entries. Shared forwarding paths are identical in
   function to independently routed paths
   with the exception that they share the same labels and same a path from
   the merge point.

   To achieve shared forwarding, a Path computation engine [PATHCOMP]
   should ensure the ERO is consistent with an existing path for the
   shared segments. If
   intersecting switch or link except they share a path satisfies the consistency check, the
   upstream end single forwarding
   entry.

   Share forwarding savings can be quite dramatic in some topologies
   where a high degree of the signaling may chose meshing is required however it is typically
   easier to share an existing ESP-
   VID/ESP-MAC DA for achieve when the upstream traffic with an existing Eth-LSP.
   The criteria for shared forwarding connectivity is know in advance.  Normally
   the Eth-LSPs must share the
   same destination port and the paths originating GMPLS switch will not have knowledge of the Eth-LSP share one or more
   hops consecutively. Once the paths converge they must remain
   converged. If no existing path has this behavior when a new path is
   being created, the new path will be created without sharing either by
   using another ESP-VID or another ESP-MAC DA or both.

   In other words, set of
   shared forwarding is possible when paths share
   segments either from rooted on the source or the destination. There is no
   requirement that the paths share reservations destination switch.

   Use of a Path Computation Server [PATHCOMP] or other attributes.
   For the source, planning style
   of tool with more complete knowledge of the UPSTREAM_LABEL network configuration is chosen
   a way to be the same as an
   existing path that shares the ERO for some number impose pre-selection of hops.  Similarly
   for the destination, shared forwarding is possible when an existing
   path that shares segments with multiplexes to use
   for both directions.  In this scenario the new paths ERO, viewed from originating switch uses
   the
   destination switch.  The downstream label in this case is chosen LABEL_SET and UPSTREAM_LABEL objects to
   be the same as indicate selection of the existing path. In this manner
   shared forwarding is
   a function that is controlled primarily by policy and in combination
   with the local label allocation multiplexes at the end points of the path. both ends.

4.1.2. P2P connections with procedures for shared forwarding

   The ESP-VID/ESP-MAC DA MAY be considered to be a shared forwarding
   identifier or label for a multiplex consisting of some number of P2P
   connections distinctly identified by the MAC ESP-VID/ESP-MAC DA/ESP-
   MAC SA tuple. In some ways this This is analogous to an LDP label merge but in the
   shared forwarding case only the forwarding entry is
   reused. original ESP header still identifies the
   complete path.  Resources can continue to be allocated per LSP. LSP with
   Shared forwarding.

   VLAN tagged Ethernet packets include priority marking. Priority bits
   MAY be used to indicate class of Service (COS) and drop priority.
   Thus, traffic from multiple COSs could be multiplexed on the same
   Eth-LSP (i.e., similar to E-LSPs) and queuing and drop decisions are
   made based on the p-bits. This means that the queue selection can be
   done based on a per flow (i.e., Eth-LSP + priority) basis and is
   decoupled from the actual steering of the packet at any given switch.

   A switch terminating an Eth-LSP will frequently have more than one
   suitable candidate path and it may choose to share for sharing a forwarding entry (common ESP-VID/ESP-MAC ESP-
   VID/ESP-MAC DA, unique ESP-MAC SA). It is a local decision of how
   this is performed but the best choice is a path that maximizes the
   shared forwarding.

   The concept of bandwidth management still applies equally well with
   shared forwarding. As an example consider a PBB-TE edge switch that
   terminates an Ethernet LSP with the following attributes: bandwidth
   B1, ESP-MAC DA D, ESP-MAC SA S1, ESP-VID V. A request to establish an
   additional Ethernet LSP with attributes (bandwidth B2, ESP-MAC DA D,
   ESP-MAC SA S2, ESP-VID V) can be accepted provided there is
   sufficient link capacity remaining.

4.1.3. Dynamic P2P symmetry with shared forwarding

   Similar to how a destination switch MAY select a ESP-VID/ESP-MAC DA
   from the set of existing shared forwarding multiplexes rooted at the
   destination switch, the originating switch MAY also do so for the
   reverse path. Once the initial ERO has been computed and the set of
   existing Ethernet LSPs that include the target ESP-MAC DA have been
   pruned, the originating switch may select the optimal (by whatever
   criteria) existing shared forwarding multiplex for the new
   destination to merge with and offer its own ESP-VID/ESP-MAC DA tuple
   for itself as a destination.

4.1.4. Planned P2P symmetry

   Normally the originating switch will not have knowledge of the set of
   shared forwarding paths rooted on the destination switch.

   Use of a Path Computation Server [PATHCOMP] or other planning style
   of tool with more complete knowledge of the network configuration may
   wish to impose pre-selection of shared forwarding multiplexes to use
   for both directions.  In this scenario the originating switch uses
   the LABEL_SET and UPSTREAM_LABEL objects to indicate complete
   selection of the shared forwarding multiplexes at both ends. This may
   also result in the establishment of a new ESP-VID/ESP-MAC DA path as
   the LABEL_SET object may legitimately refer to a path that does not
   yet exist.

4.1.5. P2P Path Maintenance

   Make before break procedures can be employed to modify the
   characteristics of a P2P Ethernet Eth LSP. As described in [RFC3209], the LSP
   ID in the sender template is updated as the new path is signaled. The
   procedures (including those for shared forwarding) are identical to
   those employed in establishing a new LSP, with the extended tunnel ID
   in the signaling exchange ensuring that double booking of the
   associated resources does not occur.

   Where individual paths in a protection group are modified, signaling
   procedures may be combined with Protection Switching (PS)
   coordination to administratively force PS switching operations such
   that modifications are only ever performed on the protection path.

4.2. P2MP Signaling

   Note specifics for P2MP paths are being defined. This section will be
   updated to align with the Ethernet-LSPs

   PBB-TE specification [IEEE 802.1Qay].

   To initiate a supports P2MP VID/Multicast MAC (MMAC) path forwarding.  In P2MP
   the initiator of whole tree in the
   PATH message uses forward direction has the same destination MMAC
   ESP-MAC-DA.

   The procedures outlined in [RFC3473] and [RFC4875]. A
   P2MP tree consists of a VID tree forward direction (from root to
   leaves) and a set of P2P paths running on identical paths from Tree
   leaves [RFC4875]could be adapted to root in
   signal P2MP LSPs for the reverse source (point) to destination (multipoint)
   direction. The result is a composite
   path with a ESP- MMAC DA label with a single ESP-MMAC DA in the
   forward direction and a symmetric set  Each one of unidirectional ESP-VID/ESP-
   MAC DA labels in the reverse direction:

   1-4) Same points as P2P paths previously specified.

   5) Sets the downstream label as the ESP-MMAC DA.

4.3. P2MP ESP-MAC DA Connections

4.3.1. Setup procedures

   The group ESP-MMAC DA is administered from a central pool branches of
   multicast addresses and the VLAN selected from the PBB-TE VID range.
   The P2MP tree is constructed via incremental addition of leaves to
   the tree in signaling exchanges where the root is the originating
   switch (as per (RFC4875). The multicast VID/ESP-MMAC DA is encoded in
   the LABEL_SET (as a member of one) object using the Ethernet label
   encoding.

   Where Eth-LSP would be
   associated with a return reverse path is required the unicast MAC corresponding to the
   originating interface symmetric and a VID selected from the configured VID/ESP-
   MAC DA range is encoded as an Ethernet label in the UPSTREAM_LABEL
   object.

4.3.2. congruent P2P Eth-LSP.

   Complete procedures for signaling bidirectional P2MP are out of scope
   for this document.

4.2.1. Maintenance Procedures

   Maintenance and modification to a P2MP tree can be achieved by a
   number of means. The preferred technique is to modify existing VLAN
   configuration vs. assignment of a new label and completely
   constructing a new tree.

   Make before break on a live tree reusing existing label assignments
   requires a 1:1 or 1+1 construct. The protection switch state of the
   traffic is forced on the working tree and locked (PS not allowed)
   while the backup tree is modified. Explicit path tear of leaves to be
   modified is required to ensure no loops are left behind as artifacts
   of tree modification. Once modifications are complete, a forced
   switch to the backup tree occurs and the original tree may be
   similarly modified. This also suggests that 1+1 or 1:1 resilience can
   be achieved for P2MP trees for any single failure (switch on any
   failure and use restoration techniques to repair the failed tree).

4.4.

4.3. PBB-TE Ethernet Label

   The PBB-TE Ethernet label Label is a new generalized label with a suggested format
   of: the
   following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 0|      ESP VID          |    ESP MAC (highest 2 bytes)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            ESP MAC                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 3  PBB-TE Ethernet Label

   This format can be is used to carry for both P2P and P2MP labels. Eth-LSPs. For P2P
   Eth-LSPs labels the fields specify ESP <VID, a VID and a unicast MAC DA>. The semantics address,
   while for a P2MP label
   using Eth-LSPs a MMAC DA VID and a group MAC address is that that carried in
   the label is passed unchanged. This
   label label.  The PBB-TE Ethernet Label is also a domain wide label.  This has similarity to the way unique label
   and MUST be passed unchanged at each hop. This has similarity to the
   way in which a wavelength label is handled at an intermediate switch
   that cannot perform wavelength conversion, and is described in
   [RFC3473].

   Label Allocation

4.4. Protection Paths

   When protection is used for Domain wide labels path recovery it is similar required to other label
   switching technologies with the exception that the labels are owned
   by the switch where associate
   the path working and protection paths into a protection group.  This is terminated.  In Ethernet, unique MAC
   based labels can be created
   achieved as defined in [RFC4872] and [RFC4873] using one of two methods. One option is
   to allocate the ESP-MAC DAs from globally unique addresses assigned
   to the either the switch manufacturer. ASSOCIATION
   and PROTECTION objects.

4.5. Service Instance Identification

   The other option I-SID is used to use
   ESP-MAC DAs out of the local admin space and ensure these labels are
   unique uniquely identify services within the domain. Labels only have significance within network.
   Unambiguous identification is achieved by ensuring global uniqueness
   of the
   domain.

   In I-SIDs within the case network or at least between any pair of local label allocation there edge
   switches. On IB-BEBs the Backbone Service Instance Table is no need used to use
   globally assigned OUIs. However when using this configuration, some
   way of ensuring label consistency should
   configure the mapping between I-SIDs and ESPs. This configuration can
   be provided either manual or semi-automated by signaling described here.

   RSVP-TE signaling can be used to make sure
   that labels were unique. When using GMPLS automate I-SID to ESP mapping. By
   relying on signaling it is assumed a
   unique pool of labels would be owned or ensured that the same I-SID is assigned to each switch. The
   ESP-MAC DA addresses are domain wide unique
   the service and so is mapped to the same ESP. Note, by signaling the I-SID
   associated to the combination
   of ESP <VID, MAC DA>. It is intended one can ensure that IB-BEBs select the ESP <VID, MAC DA>
   appropriate CBP port.

   The CALL signaling [RFC4974] can be
   only used by one destination. However, should an error occur and a
   somehow a duplicate label be assigned to one or more destination
   switches GMPLS signaling procedures would allow create the first assignment I-SID
   association between the endpoints prior to Eth-LSP establishment.
   Alternatively, the PATH messages can carry the I-SID association at
   the time of Eth-LSP signaling.  Therefore it is possible to create I-
   SID association either when the label and prevent any duplicate label from colliding. If path is set up or at a
   collision occurs an alarm would be generated. In fact some of these
   procedures have been later time.

   A new Service ID TLV is defined in GMPLS for the CALL_ATTRIBUTES object. The
   format is depicted below.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Type (TBA)          |      Length (variable)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Reserved                    |    Flags      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          I-SID Set 1                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               :                               :
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        I-SID Set n                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Figure 4 Service ID TLV

     - Flags: are used to control properties of photonic networks
   where a lambda may exist as a form of domain wide label.

4.5. OAM MEP ID and MA ID synchronization service configuration.
       This section is aligned with [IEEE 802.1Qay]. At present Ethernet OAM document does not define flags.

     - I-SID Set TLV: is signaled in Ethernet protocol data units.  Extensions to GMPLS
   [OAM-EXT] are proposed used to automatically setup OAM for Ethernet LSPs.

   The Maintenance association point IDs (MEP IDs) and maintenance
   association IDs for the switched path endpoints define a list or range of I-SIDs.
       Multiple I-SID Set TLVs can be synchronized
   using the ETH-MCC (maintenance communication channel) transaction set
   once the switched path has been established.

   MEPs are located at the endpoints present. At least one I-SID Set
       TLV MUST be present. In most of the Ethernet LSP. Typical
   configuration associated cases a single I-SID Set with
       a MEP single I-SID value is Maintenance Domain Name, Short
   Maintenance Association Name, and MD Level, MEP ID, and CCM
   transmission rate (when ETH-CC functionality used. The I-SID Set TLV is desired). As part used to define
       a list or range of I-SIDs. The format of the synchronization, it I-SID Set TLV is verified that the Maintenance Domain Name,
   Short Maintenance Association Name, MD Level, and CCM transmission
   rate are
       based on the same. It is also determined that MEP IDs are unique for
   each MEP.

   Besides the unicast CCM functionality, the PBB-TE MEPs can also offer
   the LBM/LBR and LMM/LMR functionalities for on-demand connectivity
   verification and loss measurement purposes.

4.6. Protection Paths LABEL_SET Object:
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Action     |                    Reserved                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Reserved    |        I-SID 1                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                               :                               :
    :                               :                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Reserved    |          I-SID n                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         Figure 5 I-SID Set TLV
     - Action: 8 bits

       The IEEE is currently defining protection procedures for PBB-TE [IEEE
   802.1Qay]. This section will be updated when these procedures following actions are
   documented.

   When protection is used for path recovery it is required to associate
   the working and protection paths into a protection group.  This is
   achieved as defined in [RFC4872] and [RFC4873] using the ASSOCIATION
   and PROTECTION objects.  Protection may be used for P2P VID/ESP-MAC
   DA, P2MP VID/ESP-MMAC DA and P2MP VID configured modes of operation. defined: list (0), range (1).

     - I-SID: 24 bits

       The 'P' bit in the protection object indicates the role (working or
   protection) of the LSP currently being signaled.

   If the initiating switch wishes to use G.8031 [G-8031] data plane
   protection switching coordination (vs. control plane notifications),
   it sets the N bit to 1 in the protection object. This must be
   consistently applied for all paths associated as I-SID value identifies a protection group.

   If the terminating switch does not support G.8031, the error
   "Admission Control Failure/Unsupported Notification Type" is used. particular backbone service
       instance.

5. Error conditions

   The following errors have been identified as being unique to these
   procedures and in addition to those already defined. This will be
   addressed in a proper IANA considerations section in a future version are possible. They are extension of some base
   error types that arise due to the document: constraints on the label.

5.1.  Invalid ESP-VID value for PBB-TE MSTI range

   The originator of the error is not configured to use the ESP-VID
   value for PBB-TE in conjunction with GMPLS signaling of <ESP: VID,
   MAC DA > tuples. This may be originated by any switch along the path.

5.2. Invalid

   Note this is a refinement of the more general Unacceptable label
   value Error code.

5.2. Invalid MAC Address

   The MAC address is out of a reserved range that cannot be used by the
   switch which is processing the address. While almost all MAC
   addresses are valid there are a small number of IEEE reserved MAC
   addresses.

5.3. Invalid ERO for UPSTREAM_LABEL Object

    The ERO offered has discontinuities with the identified ESP-
    VID/ESP-MAC DA path in the UPSTREAM_LABEL object.

5.4. Invalid ERO for LABEL_SET Object

   The ERO offered has discontinuities with the identified ESP-VID/ESP-
   MAC DA path in

   Note this is a refinement of the LABEL_SET object.

5.5. more general Unacceptable label
   value Error code.

5.3. Switch is not ESP P2MP capable

   This error may arise only in P2MP Tree allocation.

5.6. Invalid ESP-VID in UPSTREAM_LABEL object

    The ESP-VID in the UPSTREAM_LABEL object for the "asymmetrical ESP-
    VID" P2MP tree did not correspond to the ESP-VID used in previous
    transactions.

6. Deployment Scenarios

   Deployment scenarios are covered in [ARCH]. This section will detail
   more specific PBB-TE deployment scenarios in a later revision of this
   document.

7. Security Considerations

   The architecture assumes that the GMPLS controlled Ethernet subnet
   consists of trusted devices and that the UNI ports or in this case
   BEB Ethernet UNI Ports to the domain are untrusted. Care is required
   to ensure untrusted access to the trusted domain does not occur.
   Where GMPLS is applied to the control of VLAN only, the commonly
   known techniques for mitigation of Ethernet DOS attacks may be
   required on UNI ports.

8.

7. IANA Considerations

   New values are required for signaling and error codes as indicated.
   This section will be completed in a later version.

9. indicated
   IANA to define.  Value are needed for:

     - Switching type: 802_1 PBB-TE suggested value 40.

7.1. Error Codes

     - Invalid ESP-VID value for PBB-TE
     - Invalid MAC Address
     - Switch is not ESP P2MP capable

8. References

9.1.

8.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
      Requirement Levels", BCP 14, RFC 2119, March 1997.

   [ARCH] Fedyk, D. Berger, L., Andersson L., "GMPLS Ethernet Label
      Switching Architecture and Framework", work in progress.

   [RFC3473] Berger, L. et.al., "Generalized Multi-Protocol Label
      Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
      Engineering (RSVP-TE) Extensions", IETF RFC 3473, January 2003.

   [RFC3945] Mannie, E. et.al., "Generalized Multi-Protocol Label
      Switching (GMPLS) Architecture", IETF RFC 3945, October 2004.

9.2.

8.2. Informative References

   [IEEE 802.1Qay] "IEEE standard for Provider Backbone Bridges Traffic
      Engineering", work in progress.

   [RFC4115] Aboul-Magd, O. et.al. "A Differentiated Service Two-Rate,
      Three-Color Marker with Efficient Handling of in-Profile Traffic",
   [G-8031] ITU-T Recommendation G.8031 (2006), Ethernet Protection
      Switching.

   [IEEE 802.1AB] "IEEE Standard for Local and Metropolitan Area
      Networks, Station and Media Access Control Connectivity
      Discovery".

   [IEEE 802.1ag] "IEEE Standard for Connectivity Fault
      Management", (2007).

   [IEEE 802.1ah] "IEEE Standard for Local and Metropolitan Area
      Networks - Virtual Bridged Local Area Networks
      - Amendment 6: Provider Backbone Bridges", (2008)

   [RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)" RFC4204,
      October 2005
   [MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services
      Definitions - Phase I".

   [MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet Services
      Attributes Phase 1".

   [RFC3270] Le Faucheur, F. et.al., "Multi-Protocol Label Switching
      (MPLS) Support of Differentiated Services" IETF RFC 3270, May
      2002.
   [RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to
   [PATHCOMP] Farrel, A. et.al., "Path Computation Element (PCE)
      Architecture", work in progress.

   [RFC3985] Bryant, S., Pate, P. et al., "Pseudo Wire Emulation Edge-
      to Edge (PWE3) Architecture", IETF RFC 3985, March 2005.

   [RFC4872] Lang Lang, J. et.al., "RSVP-TE Extensions in support of End-to-End End-to-
   End
      Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery
      ", RFC 4872, May 2007.

   [RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May
      2007.

   [RFC3209] Awduche Awduche, D. et.al., "RSVP-TE: Extensions to RSVP for LSP
      Tunnels, IETF RFC 3209, December 2001.

   [RFC4974] Papadimitriou, D. and Farrel, A. "Generalized MPLS (GMPLS)
      RSVP-TE Signaling Extensions in Support of Calls", August 2007.

   [Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM Functions
      and Mechanisms for Ethernet based Networks ", (2006).

   [RFC4990] Shimoto, K., Papneja, R., Rabbat, R., "Use of Addresses in
      Generalized Multi-Protocol Label Switching (GMPLS) Networks",
      IETF RFC4990, September 2007.

   [OAM-EXT] Takacs, A., Gero, B., "GMPLS RSVP-TE Extensions to Control
   Ethernet OAM", work in progress.

10.

9. Acknowledgments

   The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen
   Shew, Dave Martin and Sandra Ballarte for their contributions to this
   document.

11.

10. Author's Address

   Don Fedyk
   Nortel Networks
   600 Technology Park Drive
   Billerica, MA, 01821
   Email: dwfedyk@nortel.com

   David Allan
   Nortel Networks
   3500 Carling Ave.
   Ottawa, Ontario, CANADA
   Email: dallan@nortel.com
   Himanshu Shah
   Ciena
   35 Nagog Park,
   Acton, MA 01720
   Email: hshah@ciena.com

   Nabil Bitar
   Verizon,
   40 Sylvan Rd.,
   Waltham, MA 02451
   Email: nabil.n.bitar@verizon.com

   Attila Takacs
   Ericsson
   1. Laborc u.
   Budapest, HUNGARY 1037
   Email: attila.takacs@ericsson.com

   Diego Caviglia
   Ericsson
   Via Negrone 1/A
   Genoa, Italy 16153
   Email: diego.caviglia@ericsson.com

   Alan McGuire
   BT Group PLC
   OP6 Polaris House,
   Adastral Park, Martlesham Heath,
   Ipswich, Suffolk, IP5 3RE, UK
   Email: alan.mcguire@bt.com

   Nurit Sprecher
   Nokia Siemens Networks,
   GmbH & Co. KG
   COO RTP IE Fixed
   3 Hanagar St. Neve Ne'eman B,
   45241 Hod Hasharon, Israel
   Email: nurit.sprecher@nsn.com

   Lou Berger
   LabN Consulting, L.L.C.
   Phone: +1-301-468-9228
   Email: lberger@labn.net

 A. Rational and mechanism for PBB_TE Ethernet Forwarding

   This appendix describes work currently being undertaken in the 802.1
   PBB-TE [IEEE 802.1Qay] project. This information is for reference
   only and will be removed when 802.1Qay becomes mature. This text
   captures some of the original rational for changing Ethernet
   forwarding. The PBB-TE [IEEE 802.1Qay] document simply documents the
   PBB-TE data plane.

   Ethernet as specified today is a complete system consisting of a data
   plane and a number of control plane functions. Spanning tree, data
   plane flooding and MAC learning combine to populate forwarding tables
   and produce resilient any-to-any behavior in a bridged network.

   Ethernet consists of a very simple and reliable data plane that has
   been optimized and mass produced. By simply disabling some Ethernet
   control plane functionality, it is possible to employ alternative
   control planes and obtain different forwarding behaviors.

   Customer     Provider        Provider
   Bridge/      Bridge          Backbone
                                Bridge

   C-MAC/C-VID------------------802.1Q -------------------C-MAC-CVID
                S-VID-----------802.1ad------------S-VID
                        B-MAC---802.1ah---B-MAC
                        B-VID---802.1ah---B-VID

                    Figure A.1 802.1 MAC/VLAN Hierarchy

   Recent works in IETF Pseudo Wire Emulation [RFC3985] and IEEE 802 are
   defining a separation of Ethernet functions permitting an increasing
   degree of provider control. The result is that the Ethernet service
   to the customer appears the same, yet the provider components and
   behaviors have become decoupled from the customer presentation and
   the provider has gained control of all VID/B-MAC endpoints.

   One example of this is the 802.1ah work in hierarchical bridging
   whereby customer Ethernet frames are fully encapsulated into a
   provider Ethernet frame, isolating the customer VID/C-MAC space from
   the provider VID/B-MAC space. In this case, the forwarding behavior
   of the of the Backbone MAC in the provider's network is as per
   802.1Q.

   The Ethernet data plane provides protocol multiplexing via the
   Ethertype field which allows encapsulation of different protocols
   supporting various applications. More recently, the Carrier Ethernet
   effort has created provider and customer separation that enables
   another level of multiplexing. This in effect creates provider MAC
   endpoints in the Ethernet sub-network controlled by the provider. In
   this appendix we concentrate on the provider solutions and therefore
   subsequent references to VLAN, VID and MAC refer to those under
   provider control, be it in the backbone layer of 802.1ah. The
   Customer Ethernet service is the same native Ethernet service with
   functions such as bridging, learning and spanning trees all
   functioning over the provider infrastructure.

   Bridging offers a simple solution for any-to-any connectivity within
   a VLAN partition via the Spanning tree, flooding and MAC learning.
   Spanning tree provides some unnecessary capabilities for P2P services
   and since the Spanning tree must interconnect all MACs with the same
   VLAN IDs (VIDs) it consumes a scarce resource (VIDs). In this
   document we present that it is easier to modify Ethernet to scale
   engineered P2P services and this is the approach we take with PBB-TE.
   (The number of usable VLANs IDs in conventional Ethernet bridging is
   constrained to 4094, therefore the use of VLAN only configuration for
   all forwarding could be limited for some applications where large
   number of P2P connections are required.)  This is because in
   Ethernet, each Spanning tree is associated with one or more VLAN IDs.
   Also Port membership in a VLAN is configured which controls the
   connectivity of all MAC interfaces participating in the VLAN.

   The roots for PBB-TE capability exist in the Ethernet management
   plane. The management of Ethernet switches provides for static
   configuration of Ethernet forwarding. The Ethernet Control plane
   allows for forwarding entries that are statically provisioned or
   configured. In this document we are expanding the meaning of
   "configured" from an Ethernet Control plane sense to mean either
   provisioned, or controlled by GMPLS. The connectivity aspects of
   Ethernet forwarding is based upon VLANs and MAC addresses. In other
   words the VLAN + DMAC are an Ethernet Label that can be looked up at
   each switch to determine the egress link (or links in the case of
   link aggregation).

   This is a finer granularity than traditional VLAN networks since each
   P2P connection is independent. By provisioning MAC addresses
   independently of Spanning tree in a domain, both the VLAN and the
   VLAN/DMAC configured forwarding can be exploited. This greatly
   extends the scalability of what can be achieved in a pure Ethernet
   bridged sub network.

   The global/domain wide uniqueness and semantics of MAC addresses as
   interface names or multicast group addresses has been preserved. (In
   Ethernet overlap of MAC addresses across VLANs is allowed. However
   for PBB-TE MAC addresses should be unique for all VLANs assigned to
   PBB-TE. With PBB-TE it is an operational choice if the operator uses
   PBT-TE labels out of the global MAC address space or the local admin
   space.) We then redefine the semantics associated with administration
   and uses of VLAN values for the case of explicit forwarding such as
   with statically configured Ethernet.

   The PBB_TE is Ethernet Forwarding where configured VID + DMAC provide
   a forwarding table that is consistent with existing PBB and Ethernet
   switching. At the same time it provides domain wide labels that can
   be controlled by a common GMPLS control plane. This makes GMPLS
   control and resource management procedures ideal to create paths. The
   outcome is that the GMPLS control plane can be utilized to set up the
   following atomic modes of connectivity:

          1) P2P connectivity and MP2P multiplexed connectivity based
             on configuration of unicast MAC addresses in conjunction
             with a VID from a set of pre-configured VIDs.
          2) P2MP connectivity based on configuration of multicast MAC
             address in conjunction with a VID from a set of pre-
             configured VIDs. This corresponds to (Source, Group) or
             (S,G) multicast.
          3) P2MP connectivity based on configuration of VID port
             membership. This corresponds to (S,*) or (*,*) multicast
             (where * represents the extent of the VLAN Tree).
          4) MP2MP connectivity based on configuration of VID port
             membership (P2MP trees in which leaves are permitted to
             communicate). Although, we caution that this approach
             poses resilience issues (discussed in section 5) and hence
             is not recommended.

   The modes above are not completely distinct. Some modes involve
   combinations of P2P connections in one direction and MP connectivity
   in the other direction.  Also, more than one mode may be combined in
   a single GMPLS transaction. One example is the incremental addition
   of a leaf to a P2MP tree with a corresponding MP2P return path
   (analogous to a root initiated join).

   In order to realize the above connectivity modes, a partition of the
   VLAN IDs from traditional Ethernet needs to be established. The
   partition allows for a pool of Ethernet labels for manual
   configuration and/or for GMPLS control plane usage. The VID partition
   actually consists of a "configured VID/DMAC range" and "configured
   VID range" since in some instances the label is a VID/ DMAC and
   sometimes the label is a VID/Multicast DMAC.

 A.1. Overview of configuration of VID/DMAC tuples

   Statically configured MAC and VID entries are a complete 60 bit
   lookup. The basic operation of an Ethernet switch is filtering on VID
   and forwarding on DMAC. The resulting operation is the same as
   performing a full 60 bit lookup (VID (12) + DMAC(48)) for P2P
   operations, only requiring uniqueness of the full 60 bits for
   forwarding to resolve correctly. This is an Ethernet domain wide
   label.

   Complete route freedom is available for each domain wide label (60
   bit VLAN/DMAC tuple) and the ability to define multiple connectivity
   instances or paths per DMAC for each of the VIDs in the "configured
   VID/DMAC range".

   The semantics of MAC addresses are preserved, and simply broaden the
   potential interpretations of VLAN ID from spanning tree identifier to
   topology instance identifier. Therefore, operation of both standard
   bridging and configured unicast/multicast operation is available side
   by side. The VID space is partitioned and a range of VIDs is
   allocated(say 'n' VIDs) as only significant when combined with a
   configured DMAC address (the aforementioned "configured VID/DMAC
   range" of VIDs). A VID in that range is considered as an individual
   connectivity instance identifier for a configured P2P path
   terminating at the associated DMAC address. Or in the case of P2MP, a
   P2MP multicast tree corresponding to the destination multicast group
   address. Note that this is destination based forwarding consistent
   with how Ethernet works today. The only thing changed is the
   mechanism of populating the forwarding tables.

   Ethernet MAC addresses are typically globally unique since the 48
   bits consists of 24 bit Organizational Unique Identifier and a 24 bit
   serial number. There is also a bit set aside for Multicast and for
   local addresses out of the OUI field. We define domain wide as within
   a single organization, or more strictly within a single network
   within an organization. For provider MAC addresses that will only be
   used in a domain wide sense we can define MAC addresses out of a
   either the local space or the global space since they both have the
   domain wide unique property. When used in the context of GMPLS, it is
   useful to think of a domain wide pool of labels where switches are
   assigned a set of MAC addresses. These labels are assigned traffic
   that terminates on the respective switches.

   It is also worth noting that unique identification of source in the
   form of the ESP-MAC SA is carried e2e in the MAC header. So although
   we have a 60 bit domain wide unique label, it may be shared by
   multiple sources and the full connection identifier for an individual
   P2P instance is 108 bits (ESP-MAC SA, VID and DMAC). The ESP-MAC SA
   is not referenced in forwarding operations but it would allow
   additional context for tracing or other operations at the end of the
   path.

   For multicast group addresses, the VID/DMAC concatenated label can be
   distributed by the source but label assignment (as it encodes global
   multicast group information) requires coordination within the GMPLS
   controlled domain.

   As mentioned earlier, this technique results in a single unique and
   invariant identifier, in our case a VID/DMAC label associated with
   the path termination or the multicast group.  There can be up to 4094
   labels to any one MAC address.  However, practically, from an
   Ethernet network wide aspect; there would be only a handful of VLANs
   allocated for PBB-TE. In addition, all 48 bits are not completely
   available for the MAC addresses.  One way to maximize the space is to
   use the locally administered space. This is a large number for

   P2P applications and even larger when shared or multiplexed
   forwarding is leveraged. In practice, most network scaling
   requirements may be met via allocation of only a small portion of the
   VID space, to the configured VID/DMAC range. The result is minimal
   impact on the number of remaining bridging VLANs that can be
   concurrently supported.

   In order to use this unique 60 bit label, we disable the normal
   mechanisms by which Ethernet populates the forwarding table for the
   allocated range of VIDs. When a path is setup, for a specific label
   across a contiguous sequence of Ethernet switches, a unidirectional
   connection is the functional building block for an Ethernet Label
   Switched path (Eth-LSP).

   In P2P mode a bidirectional path is composed of two unidirectional
   paths that are created with a single RSVP-TE session. The technique
   does not require the VID to be common in both directions. However,
   keeping in line with regular Ethernet these paths are symmetrical
   such that a single bidirectional connection is composed of two
   unidirectional paths that have common routing (i.e. traverse the same
   switches and links) in the network and hence share the same fate.

   In P2MP mode a bidirectional path is composed of a unidirectional
   multicast tree and a number of P2P paths from the leaves of the tree
   to the root. Similarly these paths may have bandwidth and must have
   common routing as in the P2P case.

   There are a few modifications required to standard Ethernet to make
   this approach robust:

   1. In Standard Ethernet, discrepancies in forwarding table
   configuration in the path of a connection will normally result in
   packets being flooded as "unknown". For configured operation (e.g.
   PBB-TE), unknown addresses are indicative of a fault or configuration
   error and the flooding of these is undesirable in meshed topologies.
   Therefore flooding of "unknown" unicast/multicast MAC addresses must
   be disabled for the "configured VID/DMAC range".

   2. MAC learning is not required, and although it will not interfere
   with management/control population of the forwarding tables, since
   static entries are not overridden, it appears prudent to explicitly
   disable MAC learning for the configured VID/DMAC and VID range.

   3. Spanning tree is disabled for the allocated VID/DMAC and VID range
   and port blocking must be disabled to achieve complete configured
   route freedom. As noted earlier, it is a control plane requirement to
   ensure configured paths are loop free.

   All three modifications described above are within the scope of
   acceptable configuration options defined in IEEE 802.1Q
   specification.

 A.2 Overview of configuration of VID port membership

   Procedures almost identical to that for configuration of P2P VID/DMAC
   tuples can also be used for the incremental configuration of P2MP VID
   trees. For the replication of forwarding in this case the label is
   common for the multipoint destinations. The MAC field is set to
   multicast address and is common to the multicast community. The VID
   is a distinguisher common to the multicast community. The signaling
   procedures are per that for [RFC4875].

   Since VID translation is relatively new and is not a ubiquitously
   deployed capability, we consider a VID to be a domain global value.
   Therefore, the VID value to be used by the originating switch may be
   assigned by management and nominally is required to be invariant
   across the network. The ability to indicate permissibility of
   translation will be addressed in a future version of the document.

   A procedure known as "asymmetrical VID" may be employed to constrain
   connectivity (root to leaves, and leaves to root only) when switches
   also support shared VLAN learning (or SVL). This would be consistent
   with the root as a point of failure.

 A.3 OAM Aspects

   Robustness is enhanced with the addition of data plane OAM to provide
   both fault and performance management.

   For the configured VID/DMAC unicast mode of behavior, the hardware
   performs unicast packet forwarding of known MAC addresses exactly as
   Ethernet currently operates. The OAM currently defined, [802.1ag and
   Y.1731] can also be reused minor modification of the protocols.

   An additional benefit of domain wide path identifiers, for data plane
   forwarding, is the tight coupling of the 60 bit unique connection ID
   (VID/DMAC) and the associated OAM packets. It is a simple matter to
   determine a broken path or misdirected packet since the unique
   connection ID cannot be altered on the Eth-LSP. This is in fact one
   of the most powerful and unique aspects of the domain wide label for
   any type of rapid diagnosis of the data plane faults.  It is also
   independent of the control plane so it works equally well for
   provisioned or GMPLS controlled paths.

   Bidirectional transactions (e.g. ETH-LB) and reverse direction
   transactions MAY have a different VID for each direction. PBB-TE is
   specifying this aspect of CFM.

   For configured multicast VID/DMAC mode, the current versions of
   802.1ag and Y.1731] make no representation as to how PDUs which are
   not using unicast addresses or which use OAM reserved multicast

   addresses are handled. Therefore this specification makes no
   representation as to whether such trees can be instrumented.

   When configured VID mode of operation is used PBB-TE can be forced to
   use the same VID in both directions, emulating the current Ethernet
   data plane and the OAM functions as defined in the current versions
   of 802.1ag and Y.1731 can be used with no restriction.

 A.4 QOS Aspects

   Ethernet VLAN tags include priority tagging in the form of the PCP
   priority bits. When combined with configuration of the paths via
   management or control plane, priority tagging produces the Ethernet
   equivalent of an MPLS-TE E-LSPs [RFC3270]. Priority tagged Ethernet
   PDUs self-identify the required queuing discipline independent of the
   configured connectivity.

   It should be noted that the consequence of this is that there is a
   common COS model across the different modes of configured operation
   specified in this document.

   The actual QOS objects required for signaling will be in a future
   version of this memo.

 A.5 Resiliency Aspects

 A.5.1 E2E Path protection

   One plus One(1+1) protection is a primary LSP with a disjoint
   dedicated back up LSP. One for one (1:1) protection is a primary LSP
   with a disjoint backup LSP that may share resources with other LSPs.
   One plus One and One for One Automatic Protection Switching
   strategies are supported. Such schemes offer:
          1) Engineered disjoint protection paths that can protect both
             directions of traffic.
          2) Fast switchover due to tunable OAM mechanisms.
          3) Revertive path capability when primary paths are restored.
          4) Option for redialing paths under failure.

   Specific procedures for establishment of protection paths and
   associating paths into "protection groups" are TBD.

   Note that E2E path protection is able to respond to failures with a
   number of configurable intervals. The loss of CCM OAM frames in the
   data plane can trigger paths to switch. In the case of CCM OAM
   frames, the detection time is typically 3.5 times the CCM interval
   plus the propagation delay from the fault.

12. Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

13. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology
   described in this document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.  Information on the procedures with respect to rights
   in RFC documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be required
   to implement this standard.  Please address the information to the
   IETF at ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Generated on: Mon Jul 14 00:52:55 EDT 2008 Wed Feb 25 13:53:58 EST 2009