Internet Draft                                 Don Fedyk, Nortel Alcatel-Lucent
Category: Standards Track                Himanshu Shah, Ciena Force10 Networks
Expiration Date: August 25, 2009 April 14, 2010                     Nabil Bitar, Verizon
                                                 Attila Takacs, Ericsson

                                                       February 25,

                                                        October 14, 2009

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

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

             draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.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 document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the Internet community.  It
      does not specify an Internet standard of any kind.  Distribution
   copyright in some 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 material may not have been or will granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be disclosed, modified outside the IETF Standards Process, and any
   derivative works of which he or she becomes
      aware will it may not be disclosed, in accordance with BCP 78 and BCP 79. created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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 August 25, 2009. April 14, 2010.

Copyright and License Notice

   Copyright (c) 2009 IETF Trust 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. document (http://trustee.ietf.org/license-info).
   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 Label
   Switching Architecture and Framework [ARCH] and describes the
   technology specific aspects of GMPLS control for Provider Backbone
   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  ..............................................  ...........................................   4
    1.1    Co-authors  ................................................  .............................................   4
    2      Terminology  ...............................................  ............................................   5
    2.1    PBB-TE and GMPLS Terminology  ..............................  ...........................   5
    3      Creation and Maintenance of PBB-TE paths using GMPLS  ......  ...   6
 4      Specific Procedures  .......................................   9
 4.1    P2P Ethernet LSPs   ........................................   9
 4.1.1
    3.1    Shared Forwarding  .........................................  10
 4.1.2  ......................................   9
    3.2    P2P connections procedures for shared forwarding  ..........  11
 4.1.3  .......  10
    4      Specific Procedures  ....................................  10
    4.1    P2P Ethernet LSPs   .....................................  10
    4.1.1  P2P Path Maintenance  ......................................  11  ...................................  12
    4.2    P2MP Ethernet-LSPs  ........................................  12
 4.2.1  Maintenance Procedures  ....................................  .....................................  12
    4.3    PBB-TE Ethernet Label  .....................................  ..................................  12
    4.4    Protection Paths  ..........................................  .......................................  13
    4.5    Service Instance Identification   ..........................   .......................  13
    5      Error conditions  ..........................................  .......................................  15
    5.1     ESP-VID related errors   ...............................  15
    5.1.1   Invalid ESP-VID value for in the PBB-TE  ......................... Ethernet Label  ....  15
    5.1.2   Allocated ESP-VID range is exhausted  ..................  15
    5.2    Invalid MAC Address  .......................................  15
 5.3    Switch is not ESP P2MP capable  ............................  ....................................  15
    6      Security Considerations  ...................................  15  ................................  16
    7      IANA Considerations  .......................................  16
 7.1    Error Codes  ...............................................  ....................................  16
    8      References  ................................................  .............................................  16
    8.1    Normative References  ......................................  ...................................  16
    8.2    Informative References  ....................................  16  .................................  17
    9      Acknowledgments  ...........................................  17  ........................................  18
   10      Author's Address  ..........................................  17  .......................................  18

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 Provider Backbone Bridge Traffic Engineering (PBB-TE)
   [IEEE 802.1Qay] standard supports the establishment of explicitly
   routed traffic engineered paths within Provider Backbone Bridged
   (PBB) networks. PBB-TE allows disabling: the Spanning Tree Protocol,
   unknown destination address forwarding and source address learning
   for administratively selected VLAN Identifiers.  With PBB-TE an
   external provisioning system or control plane can be used to
   configure static entries in the managed objects of bridges and so
   establish traffic engineered paths 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 explicitly routed traffic
   engineered paths. This draft specification is complementary to with the
   GMPLS Ethernet Label Switching Architecture and Framework [ARCH]. [ARCH]
   document.

1.1. Co-authors

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

      Don Fedyk (Nortel) (Alcatel-Lucent)
      David Allan  (Nortel)  (Ericsson)
      Himanshu Shah (Ciena) (Force10 Networks)
      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  [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
     - CNP                 Customer 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
     - MAC                 Media Access Control
     - MMAC                Multicast or Group MAC address
     - PBB                 Provider Backbone Bridges
     - PBB-TE              Provider Backbone Bridges Traffic Engineering
     - PIP                 Provider Instance Port
     - PNP                 Provider Network Port
     - P2P                 Point to Point
     - P2MP                Point to Multipoint
     - SVL                 Shared VLAN Learning
     - TESI                TE Service Instance
     - VID                 VLAN ID
     - VLAN                Virtual LAN

2.1. PBB-TE and GMPLS Terminology

   The PBB-TE specification [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>. An
       ESP is point-to-point (P2P) or point-to-multipoint (P2MP). An ESP
       is analogous to a (unidirectional) point-to-point or point-to-
       multipoint LSP. We use the term Ethernet-LSP (Eth-LSP) for GMPLS
       established ESPs.

     - Point-to-point ESP:
       An 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 instance (P2P TESI):
       A service instance supported by two point-to-point ESPs where the
       ESPs' endpoints have the same CBP MAC addresses. The two
       unidirectional ESP are forming a bidirectional service. The PBB-
       TE standard [IEEE 802.1Qay] notes the following: for reasons
       relating to TE service monitoring diagnostics, operational
       simplicity, etc. the IEEE PBB-TE standard assumes that the point-
       to-point ESPs associated with a point-to-point TESI are co-
       routed.  Support for a point-to-point TE services which comprises
       non co-routed ESPs is problematic, and is not defined in this
       standard.  Hence, a GMPLS bidirectional LSP is analogous to a P2P
       TE Service instance. We use the term bidirectional Ethernet-LSP
       (Eth-LSP)
       for GMPLS established P2P PBB-TE Service instances.

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

   IEEE PBB-TE is a connection oriented Ethernet technology. PBB-TE ESPs
   are created switch by switch by simple configuration of Ethernet
   forwarding entries. This document describes the use of GMPLS as a
   valid control plane for the set-up, teardown,  protection and
   recovery of  ESPs and TESIs and specifies the required RSVP-TE
   extensions for the control of PBB-TE service instances.

   PBB-TE ESP and services are always originated and terminated on IB-
   Backbone Edge Bridges (IB-BEBs). IB-BEBs are constituted of I and B
   components, this is illustrated in Figure 1.

   An Ethernet service supported by a PBB-TE TESI is always attached to
   a Customer Network Port (CNP) of the I-component. A Service Instance
   Identifier (I-SID) is assigned for the service. The I and 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 the CNP by adding an I-SID and a
   complete Ethernet MAC header with an ESP-MAC DA and ESP-MAC SA. The
   B-Component adds the ESP-VID.

   GMPLS is being defined here to establish ESPs and TESIs. As it can be
   seen from the above this requires configuration of both the I and B
   components of the IB-BEBs connected by the ESPs.

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

   Note that since multiple internal CBPs may exit exist an IB-BEB receiving
   a PATH message must MUST be able to determine the appropriate CBP that is
   the termination point of the ESP. Eth-LSP. To this end, IB-BEBs SHOULD
   advertises
   advertise the CNP TE Links in the GMPLS control plane and RSVP-TE
   signaling SHOULD use the CNP TE Links to identify the termination
   point of Eth-LSPs. An IB-BEB receiving a PATH message specifying one
   of its CNPs can locally determine which CBPs have internal
   connectivity to the I-component supporting the given CNP. In the case
   there are more than one suitable CBPs, and no I-SID information is
   provided in the PATH message or previously in the associated Call
   setup, then the IB-BEB can decide freely which CBP to assign to the
   requested connection.  On the other hand, if there is information on
   the service (I-SID) that the given ESP will support, then the IB-BEB
   MUST first determine which PIP and CBP is configured with the I-SID
   and MUST assign that CBP to the ESP.

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

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

                  Figure 1 IB-BEBs and GMPLS identifiers

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

             Figure 2 Ethernet/GMPLS Addressing & Label Space

   PBB-TE defines the tuple of <ESP-MAC DA, ESP-MAC SA, ESP-VID> as a
   unique connection identifier in the data plane but the forwarding
   operation only uses the ESP-MAC DA and the ESP-VID in each direction.
   The ESP-VID typically comes from a small number of 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 the same.

   When configuring a an ESP with GMPLS, the ESP-MAC DA and ESP-VID are
   carried in a generalized label object and are assigned hop by hop but
   are invariant within a domain. This invariance is similar to GMPLS
   operation in transparent optical networks. As is typical with other
   technologies controlled by GMPLS, the data plane receiver must MUST
   accept, and usually assigns, labels from its available label pool.
   This, together with the label invariance requirement mentioned above,
   result in each PBB-TE Ethernet Label being a domain wide unique
   label, with a unique ESP-VID + ESP-MAC DA, for each direction.

   The following illustrates PBB-TE Ethernet Labels and ESPs for a P2P
   TESI.

   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

4. Specific Procedures

4.1. P2P

3.1. Shared Forwarding

   One capability of a connectionless Ethernet LSPs

   Note, PBB-TE is designed to be bidirectional and symmetrically routed
   just like Ethernet. That is, complete and proper functionality of
   Ethernet protocols data plane is only guaranteed to reuse
   destination forwarding entries for bidirectional Eth-LSPs.

      To initiate packets from any source within a bidirectional Eth-LSP, the initiator of the PATH
   message uses procedures outlined in [RFC3473], it:

   1) Sets the LSP encoding type to Ethernet.

   2) Sets the LSP switching type
   VLAN to 802_1 a destination. When setting up P2P PBB-TE suggested value 40
   [IANA to define].

   3) Sets the GPID to service type.

   4) Sets the UPSTREAM_LABEL connections for
   multiple sources sharing a common destination this capability MAY be
   preserved provided certain requirements are met. We refer to the ESP-VID1/ESP-MAC1 tuple where the
      ESP-VID1 this
   capability as Shared Forwarding.  Shared forwarding is administered locally for the invoked based
   on policy when conditions are met.  It is a local MAC address: MAC1

   5) Optionally sets decision by label
   allocation at each end plus the LABEL_SET or SUGGESTED_LABEL if path constraints.  Shared forwarding
   has no impact on the actual paths that are setup, but it chooses to
      influence allows the choice
   reduction of ESP-VID/ESP-MAC DA.

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

   Intermediate and egress forwarding entries. Shared forwarding paths are
   identical in function to independently routed paths that share a path
   from an intersecting switch processing or link except they share a single
   forwarding entry.

   The forwarding memory savings from shared forwarding can be quite
   dramatic in some topologies where a high degree of meshing is not modified by this
   document, i.e.,
   required however it is per [RFC3473]. Note, as previously stated
   intermediate bridges supporting typically easier to achieve when the 802_1 PBB-TE switching type MUST
   NOT modify LABEL values.

   The ESP-VID1/ESP-MAC1 tuple contained
   connectivity is known in advance.  Normally the originating GMPLS
   switch will not have knowledge of the set of shared forwarding paths
   rooted on the source or destination switch.

   Use of a Path Computation Server [PATHCOMP] or other planning style
   of tool with more complete knowledge of the UPSTREAM_LABEL network configuration is used
   a way to create impose pre-selection of shared forwarding with multiple
   paths using a static single forwarding entry in the Filtering Database of
   bridges at each hop and optimizing for both
   directions.  In this scenario the upstream direction. This behavior is
   inferred from the switching type which is 802_1 PBB-TE.  The port
   derived from the RSVP_HOP object and originating switch uses the ESP-VID1
   LABEL_SET and ESP- MAC1
   included in the PBB-TE Ethernet Label constitute the static entry.

   At UPSTREAM_LABEL objects to indicate selection of the destination, an ESP-VID2 is allocated
   shared forwarding labels at both ends.

3.2. P2P connections procedures for shared forwarding

   The ESP-VID/ESP-MAC DA can be considered to be a shared forwarding
   identifier or label consisting of some number of P2P connections
   distinctly identified by the local MAC
   address: MAC2, the ESP-VID2/ESP-MAC2 tuple ESP-VID/ESP-MAC DA/ESP- MAC SA
   tuple. This is passed analogous to an LDP label merge but in the LABEL
   object in shared
   forwarding case the RESV message.  As with original ESP header still identifies the PATH message, intermediate
   switch processing is complete
   path.  Resources can continue to be allocated per [RFC3473], and the LABEL object is passed on
   unchanged, upstream.  The 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 LSP with Shared
   forwarding.

   VLAN tagged Ethernet packets include priority marking. Priority bits
   MAY be used to indicate class of Service (COS) and RESV messages follow drop priority.
   Thus, traffic from multiple COSs could be multiplexed on the same path.

4.1.1. Shared Forwarding

   One capability of
   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 connectionless Ethernet data plane per flow (i.e., Eth-LSP + priority) basis and is to reuse
   destination forwarding entries for packets
   decoupled from the actual steering of the packet at any source within a
   VLAN to a destination. When setting up P2P PBB-TE connections given switch.

   A switch terminating an Eth-LSP will frequently have more than one
   suitable candidate 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. entry (common ESP-
   VID/ESP-MAC DA, unique ESP-MAC SA). It is a local decision by label
   allocation at each end plus the path constraints.  Shared forwarding
   has no impact on the actual paths setup, of how
   this is performed but it allows the reduction
   of forwarding entries. Shared forwarding paths are identical in
   function to independently routed paths that share best choice is a path from that maximizes the
   shared forwarding.

   The concept of bandwidth management still applies equally well with
   shared forwarding. As an
   intersecting switch or link except they share example consider a single forwarding
   entry.

   Share forwarding savings 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 quite dramatic in some topologies
   where a high degree accepted provided there is
   sufficient link capacity remaining.

4. Specific Procedures

4.1. P2P Ethernet LSPs

   Note, PBB-TE is designed to be bidirectional and symmetrically routed
   just like Ethernet. That is, complete and proper functionality of meshing
   Ethernet protocols is required only guaranteed for bidirectional Eth-LSPs.  In
   the following we discuss the establishment of bidirectional Eth-LSPs.

   Note however that it is typically
   easier also possible to achieve when use RSVP-TE to configure
   unidirectional ESPs, if the connectivity UPSTREAM_LABEL is know not included in advance.  Normally the originating GMPLS switch will not have knowledge of
   PATH message.     To initiate a bidirectional Eth-LSP, the set initiator
   of
   shared forwarding paths rooted on the source or destination switch.

   Use of a Path Computation Server [PATHCOMP] or other planning style
   of tool PATH message MUST use the procedures outlined in [RFC3473]
   with more complete knowledge of the network configuration following specifics:

   1) MUST set the LSP encoding type to Ethernet (2) [RFC3471].

   2) MUST set the LSP switching type to 802_1 PBB-TE suggested value 40
   IANA to define, assigned by this document].

   3) SHOULD set the GPID to Ethernet (33) [RFC3471].

   4) MUST set the UPSTREAM_LABEL to the ESP-VID1/ESP-MAC1 tuple where
   the
      ESP-VID1 is
   a way administered locally for the local MAC address: MAC1

   5) SHOULD set the LABEL_SET or SUGGESTED_LABEL if it chooses to impose pre-selection
      influence the choice of shared forwarding multiplexes to use ESP-VID/ESP-MAC DA.

   6) SHOULD look at Call / Connection ID for both directions.  In Carrying I-SID.

   Intermediate and egress switch processing is not modified by this scenario
   document, i.e., is per [RFC3473]. However, as previously stated
   intermediate bridges supporting the originating switch uses 802_1 PBB-TE switching type MUST
   NOT modify LABEL values.

   The ESP-VID1/ESP-MAC1 tuple contained in the LABEL_SET and UPSTREAM_LABEL objects to indicate selection of the
   shared forwarding multiplexes at both ends.

4.1.2. P2P connections procedures for shared forwarding

   The ESP-VID/ESP-MAC DA MAY be considered are used
   to be create a shared static forwarding
   identifier or label for a multiplex consisting of some number entry in the Filtering Database of P2P
   connections distinctly identified by
   bridges at each hop for the MAC ESP-VID/ESP-MAC DA/ESP-
   MAC SA tuple. upstream direction. This behavior is analogous to an LDP label merge but
   inferred from the switching type which is 802_1 PBB-TE.  The port
   derived from the RSVP_HOP object and the ESP-VID1 and ESP-MAC1
   included in the
   shared forwarding case PBB-TE Ethernet Label constitute the original ESP header still identifies static entry.

   At the
   complete path.  Resources can continue to be destination, an ESP-VID (ESP-VID2) is allocated per 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 for the same
   Eth-LSP (i.e., similar to E-LSPs) and queuing and drop decisions are
   made based on local
   MAC address: MAC2, the p-bits. This means that ESP-VID2/ESP-MAC2 tuple is passed in the queue selection can be
   done based on a LABEL
   object in the RESV message.  As with the PATH message, intermediate
   switch processing is per flow (i.e., Eth-LSP + priority) basis [RFC3473], and is
   decoupled from the actual steering of LABEL object MUST be
   passed on unchanged, upstream.  The ESP-VID2/ESP-MAC2 tuple contained
   in the packet at any given switch.

   A switch terminating an Eth-LSP will frequently have more than one
   suitable candidate for sharing LABEL Object is installed in the forwarding table as a static
   forwarding entry (common ESP-
   VID/ESP-MAC DA, unique ESP-MAC SA). It is a local decision of how
   this is performed but the best choice is at each hop. This creates a path that maximizes bidirectional Eth-LSP as
   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 PATH and RESV messages follow 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. same path.

4.1.1. P2P Path Maintenance

   Make before break procedures can be employed to modify the
   characteristics of a P2P 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 an
   associated resources resource does not occur.

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

4.2. P2MP Ethernet-LSPs

    PBB-TE supports P2MP VID/Multicast MAC (MMAC) forwarding.  In P2MP
   the whole tree in the forward direction has this
   case the same destination MMAC
   ESP-MAC-DA. PBB-TE Ethernet Label consists of a VID and a Group MAC
   address.  The procedures outlined in [RFC3473] and [RFC4875]could be adapted to
   signal P2MP LSPs for the source (point) to destination (multipoint)
   direction.  Each one of the branches of the P2MP Eth-LSP would be
   associated with a reverse path symmetric and 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
   adapted to ensure no loops are left behind as artifacts
   of tree modification. Once modifications are complete, a forced
   switch signal P2MP LSPs for the source (point) to destination
   (multipoint) direction.  Each one of the backup tree occurs and branches of the original tree may be
   similarly modified. This also suggests that 1+1 or 1:1 resilience can P2MP Eth-LSP
   would be achieved associated with a reverse path symmetric and congruent P2P
   Eth-LSP.

   Complete procedures for signaling bidirectional P2MP trees are out of scope
   for any single failure (switch on any
   failure and use restoration techniques to repair the failed tree). this document.

4.3. PBB-TE Ethernet Label

   The PBB-TE Ethernet Label is a new generalized label with 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 is MUST be used to carry for both P2P and P2MP Eth-LSPs. For P2P
   Eth-LSPs labels Eth-
   LSPs the fields specify a VID and a unicast MAC address, while for
   P2MP Eth-LSPs a VID and a group MAC address is carried in the label.
   The PBB-TE Ethernet Label is a domain wide 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].

4.4. Protection Paths

   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.

4.5. Service Instance Identification

   The I-SID is used to uniquely identify services within the network.
   Unambiguous identification is achieved by ensuring global uniqueness
   of the I-SIDs within the network or at least between any pair of edge
   switches. On IB-BEBs the Backbone Service Instance Table is used to
   configure the mapping between I-SIDs and ESPs. This configuration can
   be either manual or semi-automated by signaling described here.

   RSVP-TE signaling can MAY be used to automate I-SID to ESP mapping. By
   relying on signaling it is ensured that the same I-SID is assigned to
   the service and mapped to the same ESP. Note, by signaling the I-SID
   associated to the ESP one can ensure that IB-BEBs select the
   appropriate CBP port.

   The CALL signaling [RFC4974] can be used to create the 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 path is set up or at a later time.

   A new Service ID TLV is defined for the CALL_ATTRIBUTES object. and
   LSP_ATTRIBUTES objects.  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 service configuration.
       This document does not define flags.

     - I-SID Set TLV: TLV(Type 1): is used to define a list or range of I-SIDs. I-
       SIDs. Multiple I-SID Set TLVs can be present. At least one I-SID
       Set TLV MUST be present. In most of the cases a single I-SID Set
       with a single I-SID value is used. The I-SID Set TLV is used to
       define a list or range of I-SIDs. The format of the I-SID Set TLV
       is based on the 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 following actions are defined: list (0), range (1).
     - I-SID: 24 bits

       The I-SID value identifies a particular backbone service
       instance.

5. Error conditions

   The following errors are possible. They are extension identify Eth-LSP specific problems.

5.1.  ESP-VID related errors

   The network operator administratively selects a
    set of some base
   error types VLAN Identifiers that arise due can be used to setup ESPs.
   Consequently, any VID outside the constraints on allocated range is invalid and an
   error MUST be generated where the label.

5.1. mismatch is discovered.

5.1.1.  Invalid ESP-VID value for PBB-TE

   The originator of in the error PBB-TE Ethernet Label

   If a bridge is not configured to use the ESP-VID
   value value, carried in
   the Label object, for PBB-TE in conjunction with GMPLS signaling ESPs, it MUST immediately generate an
   error: Routing problem (24) / Unacceptable label value (6).  Handling
   of <ESP: VID,
   MAC DA > tuples. This this error is according to [RFC3209].

   Note, this error may be originated by any switch along the path.

   Note this

5.1.2.  Allocated ESP-VID range is exhausted

   The destination bridge after receiving the PATH message has to
   allocate a refinement VID, which together with its MAC address will constitute
   the PBB-TE Ethernet Label. Depending on the size of the more general Unacceptable label
   value Error code. allocated
   VLAN range and the number of Eth-LSPs terminated on a particular
   bridge, it is possible that the available VIDs are exhausted and
   hence no PBB-TE Ethernet Label can be allocated. In this case the
   destination bridge SHOULD generate a PathErr message with error code:
   Routing problem (24) and error value: PBB-TE Ethernet Label VID
   allocation failure  (35?) [the new error sub-code to be allocated by
   IANA]

5.2. Invalid MAC Address

   The MAC address is out of

   IEEE defines a set of reserved range MAC addresses that have special
   meaning, processing and follow specific forwarding rules. These
   addresses cannot be used by for PBB-TE ESPs.  In the
   switch which is processing case the address. While almost all MAC
   addresses are valid there are PBB-TE
   Ethernet Label refers to such a small number of IEEE reserved MAC
   addresses.

   Note this is address, a refinement of bridge encountering
   the more general mismatch MUST immediately generate an error: Routing problem (24)
   / Unacceptable label value Error code.

5.3. Switch is not ESP P2MP capable

   This (6). Handling of this error may arise only in P2MP Tree allocation. is according
   to [RFC3209].

6. Security Considerations

   The architecture assumes that

   This document does not introduces new security issues; the
   considerations in [RFC4872] and [RFC4873] apply.

   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.  PBB-TE has been
   designed to interwork with legacy VLANs and the VLANs provide
   isolation from Ethernet legacy control planes.

7. IANA Considerations

   New values are required for signaling and error codes as indicated
   IANA to define.  Value are needed for:

     - Assign a new Switching type: 802_1 PBB-TE suggested Type: "802_1 PBB-TE" (suggested value 40.

7.1. 40)
       in the GMPLS Signaling Parameters / Switching Types registry.

     - Assign a new globally defined error value: "PBB-TE Ethernet Label
       VID allocation failure" (suggested value: 35?)  under the
       "Routing problem" (24) error code in the RSVP Parameters / Error
       Codes and Globally-Defined Error Value Sub-Codes registry.

     - Invalid ESP-VID Assign a new type from the Attributes TLV Space in the RSVP-TE
       Parameters registry (suggested value 2) for PBB-TE
     - Invalid MAC Address the Service ID TLV
       that is carried in the LSP_ATTRIBUTES Object (class = 197, C-Type
       = 1) [RFC5420].

     - Switch Assign a new type (suggested value 2) for the Service ID TLV that
       is not ESP P2MP capable carried in the CALL_ATTRIBUTES Object (class = 201, C-Type =
       1) [MLN-EXT].

8. References

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.

   [RFC3471] Berger, L. et.al., "Generalized Multi-Protocol Label
   Switching (GMPLS) Signaling Functional Description" IETF RFC 3471,
   January 2003.

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

   [MLN-EXT] Papadimitriou, D. et al,  "Generalized Multi-Protocol
      Label Switching (GMPLS) Protocol Extensions for Multi-Layer
      and Multi-Region Networks (MLN/MRN)", work in progress.

   [RFC5420] Farrel, A. Ed., "Encoding of Attributes for MPLS LSP
      Establishment Using Resource Reservation Protocol Traffic
      Engineering (RSVP-TE), IETF RFC 5420, February 2009.

8.2. Informative References

   [IEEE 802.1Qay] 802.1ay] "IEEE standard Standard for Local and Metropolitan Area
      Networks - Virtual Bridged Local Area Networks
      - Amendment : Provider Backbone Bridges Traffic
      Engineering", work in progress. Engineering
   (2009).

   [IEEE 802.1ag] "IEEE Standard for Local and Metropolitan Area
      Networks - Virtual Bridged Local Area Networks
      - Amendment 5: Connectivity Fault
      Management", Management (2007).

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

   [RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to
      Multipoint TE LSPs", IETF RFC 4875, May 2007

   [PATHCOMP] Farrel, A. et.al., "Path Computation Element (PCE)
      Architecture", work in progress. IETF RFC 4655, August 2006

   [RFC4872] Lang, J. et.al., "RSVP-TE Extensions in support of 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, 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).

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.

10. Author's Address

   Don Fedyk
   Nortel Networks
   600 Technology Park Drive
   Billerica,
   Alcatel-Lucent
   Groton, MA, 01821 01450
   Phone: +1-978-467-5645
   Email: dwfedyk@nortel.com donald.fedyk@alcatel-lucent.com

   David Allan
   Nortel Networks
   3500 Carling Ave.
   Ottawa, Ontario, CANADA
   Ericsson
   Email: dallan@nortel.com david.i.allan@ericsson.com

   Himanshu Shah
   Ciena
   35
   Force10 Networks
   30 Nagog Park,
   Acton, MA 01720
   Email: hshah@ciena.com hshah@force10networks.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

Generated on: Wed Feb 25 13:53:58 EST Oct 14 13:52:17 EDT 2009