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

Versions: 00 01 02 03 04 05 06 RFC 6060

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

                                                           July 14, 2008

                    GMPLS control of Ethernet PBB-TE

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

Status of this Memo

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

Copyright Notice

   Copyright (C) The IETF Trust (2008).

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








Fedyk, et. al.               Standards Track                    [Page 1]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


Table of Contents

 1      Introduction  ..............................................   3
 1.1    Co-authors  ................................................   3
 2      Terminology  ...............................................   4
 2.1    PBB-TE Terminology  ........................................   5
 3      Creation and Maintenance of PBB-TE Service Instances  ......   6
 3.1    Ethernet Service  ..........................................   7
 3.2    Addresses, Interfaces, and Labels  .........................   7
 4      Specific Procedures  .......................................  10
 4.1    P2P connections  ...........................................  10
 4.1.1  Shared Forwarding  .........................................  11
 4.1.2  P2P connections with shared forwarding  ....................  12
 4.1.3  Dynamic P2P symmetry with shared forwarding  ...............  13
 4.1.4  Planned P2P symmetry  ......................................  13
 4.1.5  P2P Path Maintenance  ......................................  13
 4.2    P2MP Signaling  ............................................  14
 4.3    P2MP ESP-MAC DA Connections  ...............................  14
 4.3.1  Setup procedures  ..........................................  14
 4.3.2  Maintenance Procedures  ....................................  14
 4.4    Ethernet Label  ............................................  15
 4.5    OAM MEP ID and MA ID synchronization  ......................  16
 4.6    Protection Paths  ..........................................  16
 5      Error conditions  ..........................................  17
 5.1    Invalid ESP-VID value for PBB-TE MSTI range  ...............  17
 5.2    Invalid MAC Address  .......................................  17
 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
 6      Deployment Scenarios  ......................................  18
 7      Security Considerations  ...................................  18
 8      IANA Considerations  .......................................  18
 9      References  ................................................  19
 9.1    Normative References  ......................................  19
 9.2    Informative References  ....................................  19
10      Acknowledgments  ...........................................  21
11      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



Fedyk, et. al.               Standards Track                    [Page 2]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


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

   IEEE 802.1 is specifying Traffic Engineered Ethernet paths in the
   Provider Backbone Bridged network (PBB-TE) [IEEE 802.1Qay] based on
   managed objects that can be separated from the Spanning Tree Control
   Plane and statically configured or managed by another control plane.
   These paths have minor changes to Ethernet data plane specified in
   the IEEE. IEEE 802 termed these paths "PBB-TE service instances".


   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. This
   draft is aligned 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)



Fedyk, et. al.               Standards Track                    [Page 3]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


      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:

     - 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                 Customer Instance Port
     - C-MAC               Customer MAC
     - C-VID               Customer VLAN ID
     - C-VLAN              Customer VLAN
     - DMAC                Destination MAC Address
     - ESP                 Ethernet Switched Path
     - Eth-LSP             Ethernet Label Switched Path
     - 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 MAC
     - MSTID               Multiple Spanning Tree Identifier
     - MP2MP               Multipoint to multipoint
     - 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






Fedyk, et. al.               Standards Track                    [Page 4]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


     - SVL                 Shared VLAN Learning
     - TE-MSTID            Traffic Engineering MSTID
     - VID                 VLAN ID
     - VLAN                Virtual LAN


2.1. PBB-TE Terminology

   The PBB-TE specification has defined 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 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.) An ESP is analogous to a GMPLS LSP.


     - Point-to-Point PBB-TE service instance:
       An instance of the MAC service provided by two unidirectional co-
       routed ESPs forming a bidirectional service. A GMPLS
       bidirectional path is analogous to a P2P PBB-TE Service instance.

     - Point-to-Multipoint PBB-TE service instance:
       An instance of the MAC service provided by a set of ESPs which
       comprises one point-to-multipoint ESP plus n unidirectional
       point-to-point ESPs.  The n P2P ESPs are co-routed but 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 is different to 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 bidirectional trees.














Fedyk, et. al.               Standards Track                    [Page 5]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


3. Creation and Maintenance of PBB-TE Service Instances

   PBB-TE is an Ethernet 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 by switch by
   simple configuration of Ethernet logical ports and assignment of PBB-
   TE labels or by a control plane. This document describes 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 teardown,
   protection and recovery of PBB-TE ESPs and specifies the specific
   TLVs for control of PBB-TE service instances.

   When configuring a PBB-TE 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
   accept, and usually assigns, labels from its available label pool.
   This, together with the label invariance requirement mentioned above,
   result in each PBB-TE label being a domain wide unique label, with a
   unique ESP-VID + ESP-MAC DA, for each direction.

   The following illustrates the identifiers for Labels and ESPs.

   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 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 (DMAC) and the ESP-VID in each direction. Note that
   the MAC addresses for PBB-TE are part of the Backbone Component
   Relay (B-Component) and are associated with Provider addresses
   corresponding to the Customer Backbone ports (CBP) of the Backbone
   Component (B-Component) as described in section 3.2.
   The ESP-VID (VID) typically comes from a small number 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 the same.

   Several attributes may be associated with an Eth-LSP.  These are
   reviewed in Section 3 of [ARCH]. Several other aspects of GMPLS



Fedyk, et. al.               Standards Track                    [Page 6]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   covered by [ARCH] also apply equally to PBB-TE.  This includes the
   GMPLS routing and addressing model, link management, path
   computation and selection, and multiple domains.


3.1. Ethernet Service

   Ethernet Switched Paths that are setup either by configuration or
   signaling can be used to provide an Ethernet service to customers of
   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 of this specification.


3.2. Addresses, Interfaces, and Labels

   This specification uses an addressing scheme and a label space for
   the ingress/egress connection; the hierarchical TE Router
   ID/Interface ID and 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 and Routing [ARCH].

   PBB-TE is defined for a PBB Network.  As with PBB services, PBB-TE is
   typically implemented in the Service and Backbone components of an
   IB-Backbone Edge Bridge (BEB). This is illustrated 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 the I-Component Relay to a Virtual instance port (VIP) 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 to a single PIP.) The CBP has a B-MAC that
   defines the MAC for the PBB-TE Service Instance.  That source B-MAC
   address is the PIP MAC address which in the case of backbone service
   instances that are supported by TE service instances is configured to
   take the same value as 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 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



Fedyk, et. al.               Standards Track                    [Page 7]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   is defined.

   The diagram also shows the addition of a TE Router ID to the PBB
   switch and the TE Link identifier 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]

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

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


             Figure 2 Ethernet/GMPLS Addressing & Label Space


















Fedyk, et. al.               Standards Track                    [Page 8]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


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


             Figure 3 Ethernet/GMPLS Addressing & Label Space

   For a GMPLS based system, the TE Router ID/logical port is the
   logical signaling identifier for the control 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 the switch
   forwarding tables identifies the upstream and downstream egress ESP-
   VID/ESP-MAC DA of the PBB-TE ESP (see Figure 3).

   GMPLS uses identifiers in the form of 32 bit numbers which are in the
   IP address notation which may or may not be IP addresses.  The
   provider MAC port addresses are exchanged by the LLDP [IEEE 802.1AB]
   and by LMP [RFC4204] if supported. However these identifiers are
   merely for link control and legacy Ethernet support and have local
   link scope. Actual label assignment is performed by the ingress 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 a 32 bit
     interface Identifier also call an unnumbered link.
   - One (or more) Mnemonic String Identifiers

   This multiple naming convention leaves the issue of resolving the set
   given one of the port identifiers. On a particular switch, mapping is
   relatively straightforward.  Per [ARCH], standard GMPLS mechanisms
   are used for signaling resolution. In so doing, the problem of
   setting up a path is reduced to figuring out what switch supports an
   egress CBP MAC address and then finding the corresponding egress IP
   address and performing all signaling and routing with respect to the
   egress.

   There are several options to achieve this:



Fedyk, et. al.               Standards Track                    [Page 9]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   - 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 in a subsequent version
     of this document.


4. Specific Procedures

4.1. P2P connections

   The PBB-TE Service Instance is defined by the ESP 3-tuples for each
   of the unidirectional ESPs. From a 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 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 and ESP-MAC DA
   respectively.  PBB-TE is designed to be bidirectional and
   symmetrically routed just like Ethernet. Therefore in PBB-TE, the
   packet ESP-MAC SA and ESP- MAC DA pair is same in the forwarding path
   and the associated reverse path except they are flipped in the
   reverse direction.

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

   1) Sets the LSP encoding type to Ethernet.

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

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

   4) Sets the UPSTREAM_LABEL to the ESP-VID/ESP-MAC SA tuple where the
   ESP-VID is administered from the configured ESP-VID/ESP-MAC DA range.



Fedyk, et. al.               Standards Track                   [Page 10]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   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]. Note, as previously stated intermediate
   bridges supporting the 802_1 switching type may not modify LABEL
   values.

   The ESP-VID/ESP-MAC SA 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].
   The port derived from the RSVP_HOP object and the ESP-VID and ESP-
   MAC DA included in the label constitute the static entry.

   At the destination, a ESP-VID is allocated in the local MAC range for
   the ESP-MAC DA and the ESP-VID/ESP-MAC DA tuple is passed in a LABEL
   object in the RESV message.  As with the PATH message, intermediate
   switch processing is per [RFC3473] and [RFC4875], and the LABEL
   object is passed on unchanged, upstream.  The ESP-VID/ESP-MAC DA
   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. Shared forwarding has no impact on the actual
   paths setup, but it allows the reduction of forwarding entries.
   Shared forwarding paths are identical to independently routed paths
   with the exception that they share the same labels and same 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 a path satisfies the consistency check, the



Fedyk, et. al.               Standards Track                   [Page 11]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   upstream end of the signaling may chose to share an existing ESP-
   VID/ESP-MAC DA for the upstream traffic with an existing Eth-LSP.
   The criteria for shared forwarding is the Eth-LSPs must share the
   same destination port and the paths 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, shared forwarding is possible when paths share
   segments either from the source or the destination. There is no
   requirement that the paths share reservations or other attributes.
   For the source, the UPSTREAM_LABEL is chosen to be the same as an
   existing path that shares the ERO for some number of hops.  Similarly
   for the destination, shared forwarding is possible when an existing
   path that shares segments with the new paths ERO, viewed from the
   destination switch.  The downstream label in this case is chosen to
   be the same as 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 at the end points of the path.


4.1.2. P2P connections with 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 is analogous to an LDP label merge
   but in the shared forwarding case only the forwarding entry is
   reused. Resources can continue to be allocated per LSP.

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



Fedyk, et. al.               Standards Track                   [Page 12]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


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



Fedyk, et. al.               Standards Track                   [Page 13]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   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 PBB-TE specification [IEEE 802.1Qay].

   To initiate a P2MP VID/Multicast MAC (MMAC) path the initiator of the
   PATH message uses 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 to root in the reverse 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 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 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 a return path is required the unicast MAC corresponding to the
   originating interface 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. 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.



Fedyk, et. al.               Standards Track                   [Page 14]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


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

   The Ethernet label is a new generalized label with a suggested format
   of:


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

   This format can be used to carry P2P and P2MP labels. For P2P labels
   the fields specify ESP <VID, MAC DA>. The semantics for a P2MP label
   using a MMAC DA is that that the label is passed unchanged. This
   label is also a domain wide label.  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 for Domain wide labels is similar to other label
   switching technologies with the exception that the labels are owned
   by the switch where the path is terminated.  In Ethernet, unique MAC
   based labels can be created 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. The other option is to use
   ESP-MAC DAs out of the local admin space and ensure these labels are
   unique within the domain. Labels only have significance within the
   domain.

   In the case of local label allocation there is no need to use
   globally assigned OUIs. However when using this configuration, some
   way of ensuring label consistency should be provided to make sure



Fedyk, et. al.               Standards Track                   [Page 15]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   that labels were unique. When using GMPLS signaling it is assumed a
   unique pool of labels would be owned or assigned to each switch. The
   ESP-MAC DA addresses are domain wide unique and so is the combination
   of ESP <VID, MAC DA>. It is intended that the ESP <VID, MAC DA> 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 the first assignment
   of the label and prevent any duplicate label from colliding. If a
   collision occurs an alarm would be generated. In fact some of these
   procedures have been defined in GMPLS control of photonic networks
   where a lambda may exist as a form of domain wide label.



4.5. OAM MEP ID and MA ID synchronization

   This section is aligned with [IEEE 802.1Qay]. At present Ethernet OAM
   is signaled in Ethernet protocol data units.  Extensions to GMPLS
   [OAM-EXT] are proposed to automatically setup OAM for Ethernet LSPs.

   The Maintenance association point IDs (MEP IDs) and maintenance
   association IDs for the switched path endpoints 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 of the Ethernet LSP. Typical
   configuration associated with a MEP is Maintenance Domain Name, Short
   Maintenance Association Name, and MD Level, MEP ID, and CCM
   transmission rate (when ETH-CC functionality is desired). As part of
   the synchronization, it is verified that the Maintenance Domain Name,
   Short Maintenance Association Name, MD Level, and CCM transmission
   rate are 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

   The IEEE is currently defining protection procedures for PBB-TE [IEEE
   802.1Qay]. This section will be updated when these procedures 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



Fedyk, et. al.               Standards Track                   [Page 16]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   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.
   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 a protection group.

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


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
   of the document:


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 in conjunction with GMPLS signaling of <ESP: VID, MAC DA >
   tuples. This may be originated by any switch along the path.


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.










Fedyk, et. al.               Standards Track                   [Page 17]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


5.4. Invalid ERO for LABEL_SET Object

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


5.5. 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. IANA Considerations

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








Fedyk, et. al.               Standards Track                   [Page 18]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


9. References

9.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. 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",
      IETF RFC 4115, July 2005

   [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







Fedyk, et. al.               Standards Track                   [Page 19]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   [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
      Multipoint TE LSPs", IETF RFC 4875, May 2007

   [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 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 et.al., "RSVP-TE: Extensions to RSVP for LSP
      Tunnels, IETF RFC 3209, December 2001.

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













Fedyk, et. al.               Standards Track                   [Page 20]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


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







Fedyk, et. al.               Standards Track                   [Page 21]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   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.











Fedyk, et. al.               Standards Track                   [Page 22]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   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



Fedyk, et. al.               Standards Track                   [Page 23]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   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



Fedyk, et. al.               Standards Track                   [Page 24]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


             (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



Fedyk, et. al.               Standards Track                   [Page 25]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   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



Fedyk, et. al.               Standards Track                   [Page 26]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   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



Fedyk, et. al.               Standards Track                   [Page 27]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   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



Fedyk, et. al.               Standards Track                   [Page 28]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   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.




Fedyk, et. al.               Standards Track                   [Page 29]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


   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



Fedyk, et. al.               Standards Track                   [Page 30]


Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txtJuly 14, 2008


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







































Fedyk, et. al.               Standards Track                   [Page 31]

Generated on: Mon Jul 14 00:52:55 EDT 2008


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/