Network Working Group                     D. Papadimitriou (Alcatel)
   Internet Draft                            N. Sprecher      (Siemens)
                                             J. Cho              (ETRI)
   Expires: July 2006                        L. Andersson    (Acreo AB)
                                             D. Fedyk, D.Allan (Nortel)
                                             P. Busschbach     (Lucent)
                                             A. Takács       (Ericsson)
                                             T. Eriksson  (TeliaSonera)
                                             D. Caviglia      (Marconi)

                                                          February 2006

         A Framework for GMPLS-controlled Ethernet Label Switching

                    draft-dimitri-gels-framework-00.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/ietf/1id-abstracts.txt

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

   For potential updates to the above required-text see:
   http://www.ietf.org/ietf/1id-guidelines.txt

Abstract

   This framework introduces the service models that should be
   supported. It describes the architecture and the information exchange
   between the different elements that sustain the reference models. It
   defines the Ethernet label. The framework also specifies the changes/
   extensions that are required to the GMPLS in order to support the
   service models.


D.P. GELS                Expires - July 2006                 [Page 1]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006


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 RFC-2119 [1].

1. Terminology

   L2SC Label Switch Router (LSR): LSR whose interfaces are capable to
   recognize Layer 2 frame boundaries and can switch data based on the
   content of the Layer 2 frame header. In the context of this document,
   L2SC interfaces are limited to Ethernet interfaces.

   Ethernet Label Edge Router (E-LER): LER that resides either at the
   edge of the provider's GMPLS network (a.k.a. Provider Edge or PE) or
   at the edge to customer's network (a.k.a. Customer Edge or CE). In
   the former case, the Ethernet LER interfaces the customer’s network
   equipment. The E-LER has the functionality required for initiating
   and terminating point-to-point and point-to-multipoint Ethernet
   connectivity across the GMPLS network.

   Ethernet Label Switching Router (E-LSR): LSR that either resides at
   the core of the provider's GMPLS network (a.k.a. Provider node or P)
   or at the edge to provider's GMPLS network (a.k.a. Provider Edge or
   PE). In the former case, the Ethernet LSRs have no direct interfaces
   towards the customers' networks. The Ethernet LSR performs Ethernet
   label switching operation by means of a LIB configured by GMPLS.

   Ethernet Label Switched Path (LSP): Label Switched Path established
   between two Ethernet LERs using GMPLS signaling.

   Label Information Base (LIB): table that specifies associations
   between incoming and outgoing Ethernet Labels included in Layer 2
   frame headers and outgoing ports. If different to the incoming label
   it also specifies the outgoing label.

2. Motivations

2.1 Motivation for connection-oriented Ethernet

   Ethernet has become widely used within the Service Provider networks,
   in particular as part of their metro/aggregation infrastructure. The
   Ethernet brings high-speed interfaces, cost-saving efficiency and
   flexibility to the carrier market, together with a reduction in CAPEX
   (Capital Expenditure).

   While the traditional Ethernet, which is a connectionless, broadcast
   technology that relies on Spanning Tree Protocols (and variations
   such as Rapid Spanning Tree Protocol, RSTP) to create loop free


D.P. GELS                Expires - July 2006                 [Page 2]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006


   topologies, is appropriate for services like Residential Multicast
   (Broadband TV), and Ethernet Transparent LAN services, it does not
   properly address the increasing demand of the service providers for
   scalability, fast recovery time, Traffic Engineering and end-to-end
   QoS for the different service requirements. These are required for
   business-critical services associated with stringent Service Level
   Agreements (SLAs). The deployment of Ethernet in the core and in the
   transport networks changes the intrinsic nature of Ethernet
   technology, from a connectionless to a connection-oriented
   technology.

   For example, with traditional/legacy IEEE 802.1 bridged Ethernet
   equipment, service providers can implement traffic differentiation on
   a per-switch basis. However, due to the Spanning Tree topology and
   reconfiguration upon failures, it is difficult to predict the exact
   traffic flows and to manage QoS on an end-to-end basis. Service
   providers require advanced traffic management capabilities to enforce
   and guarantee the QoS parameters of customers’ SLAs. Service
   providers can increase profitability with an assortment of higher
   margin differentiated services. With "connection-oriented" Ethernet
   (CO-Ethernet), it is possible to set up paths based on the service
   definition, and to enforce the SLAs. Apart from its cost-saving
   effects and flexibility, service providers will allow network
   providers to offer new services that can be tailored to the
   individual needs of the customer.

   By eliminating the need for Spanning Tree Protocol and gaining route
   freedom for configured Ethernet paths, service providers can use more
   comprehensive forms of traffic engineering to optimize network usage
   through load sharing and switching paths around bottlenecks to less
   congested links.

   Network resiliency plays a critical factor in delivering reliable
   services. Network availability is a significant contributor to
   revenue and profit. Service guarantee in the form of SLAs requires a
   resilient network that instantaneously detects facility or node
   failures and restores network operation immediately to meet the terms
   of the SLA. Network restoration through the use of IEEE
   Rapid/Spanning Tree Protocol 802.1d/w – being a Distance Vector
   protocol – has inherent limitations that make fast restoration time
   performance objectives difficult to accomplish. Connection-oriented
   Ethernet can provide the required availability to ensure guaranteed
   services. Through mechanisms like OAM, dedicated backup routes and/or
   fast reroute mechanisms, the transport Ethernet network can provide
   the tens of milliseconds fail over times needed to meet stringent SLA
   obligations. Connection-oriented Ethernet also addresses the
   carriers' needs for MAC scalability and VLAN scalability. It
   eliminates the MAC scalability problem in case switching operation is
   independent of the destination MAC address.


D.P. GELS                Expires - July 2006                 [Page 3]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006



   In addition, service providers require network architectures that
   enable services to scale effectively as the customer base grows, in
   order to minimize capital expenditures and drive down operational
   costs.

   Scalable services require the separation of traffic from different
   users, with no limitations on the number or locations of customers
   connected to the network. With connection-oriented Ethernet the cost
   effectiveness is achieved.

   Due to its connectionless nature, especially its use of self-learning
   bridges, traditional Ethernet is vulnerable to unwanted connectivity
   (either through mis-configuration or malicious attacks). In the case
   of connection-oriented Ethernet switches are explicitly provisioned
   and therefore provide enhanced security.

2.2 Motivation to improve Ethernet Control Plane

   In order to enable fast, dynamic and reliable service provisioning in
   multi-vendor and multi-domain environments through standardized
   protocols that guarantee interoperability, a control plane is
   required. Managed by a standard-based distributed control plane and
   augmented with Ethernet specific data plane OAM features currently
   being specified by the IEEE (see 802.1ag), the dynamic transport
   network will support Ethernet traffic with carrier-grade reliability,
   optimal network efficiency, multiple QoS levels, cross-vendor
   provisioning and scalability. The control plane will facilitate the
   service goal of providing seamless connectivity and service assurance
   end-to-end.

   Using the control plane the reliable service provisioning and
   management will be automatic. The control-plane protocols will make
   the provisioning and the management operations more efficient,
   thereby offering the potential of lowering network operation
   expenses, or at least limiting their rate of increase as the size of
   the service provider’s network increases. As the networks change, and
   get larger and more complex with increased dynamics, the network
   operation becomes increasingly complex and resource intensive to
   operate.

   The control plane can also optimize network usage through load
   sharing by switching paths around bottlenecks to less congested
   links. Using a control plane that provides Traffic Engineering,
   constraint based routing and explicit path control will minimize
   capital expense by making efficient use of network resources, hence
   helping to avoid unnecessary additional investments. These are
   requirements of the core/transport networks.



D.P. GELS                Expires - July 2006                 [Page 4]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006


   The use of a control plane that has the inherent ability to setup
   paths based on the service definition, with capabilities for quality-
   of-service (QoS) and Traffic Engineering will enforce the SLAs.
   Traffic Engineering is accomplished by addressing traffic oriented
   performance requirements (like throughput, delay, packet loss, etc.),
   while utilizing network resources economically and reliably.
   The control plane can enable resiliency and reliability to be built
   into service providers’ networks, increasing the availability and
   value of the network to their customers. When outages occur, traffic
   can be automatically rerouted around failed facilities.

   This framework proposes to use the Generalized Multi-Protocol Label
   Switching (GMPLS) as the control plane of choice for the Ethernet
   networks. The GMPLS protocol suite [RFC3945] has been standardized by
   the IETF CCAMP WG. GMPLS extends MPLS to support four new classes of
   interfaces including L2SC (L2 Switch Capable) interfaces. It
   facilitates the transport of client Ethernet flows without additional
   intermediate packet layer LSPs (which require pre-provisioning as
   network trunks).

   The GMPLS control plane provides Traffic Engineering (including
   support for Differentiated service-TE), provisioning and maintenance
   of (unidirectional and bi-directional) Ethernet LSPs in core and
   transport networks including multi-layer networks (MLNs).

   GMPLS has inherent support for fast recovery mechanisms. It delivers
   a range of control plane driven recovery capabilities. GMPLS
   protection and re-routing techniques (both end-to-end and segment)
   and can be reused for GMPLS Ethernet LSPs and LSP segments.

   GMPLS capabilities support the carriers' requirements for control
   plane resiliency, like graceful restart of the control plane (with no
   traffic interruption) and graceful deletion of Ethernet LSPs.

   Having a homogenous/unified set of signaling and Traffic Engineering
   mechanisms for controlling Ethernet network resources, will ease the
   integration towards a common carrier-grade network control
   infrastructure. The CCAMP WG is currently envisaging a single
   instance of control plane between IP/MPLS, Ethernet, SDH/SONET and
   optical networks. Henceforth, GMPLS controlled Ethernet label
   switching approach positions Ethernet as a carrier-grade packet-
   switching connection-oriented technology.

4. Architecture

   This section presents the architectural framework for GMPLS-
   controlled Ethernet Label Switching. It defines the reference model
   for the GMPLS-enabled Ethernet network, the various protocol elements
   and their functions.


D.P. GELS                Expires - July 2006                 [Page 5]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006



   Generalized Multi-Protocol Label Switching (GMPLS) is a suite of
   protocol extensions to MPLS. The purpose of these extensions is to
   broaden the scope of MPLS applications, and to support multiple
   network layers and new services. Specifically, this specification
   describes how GMPLS can be used to dynamically setup, delete,
   maintain and operate Point-to-Point Traffic Engineered Ethernet LSPs.
   The specification must be extensible such as to support Point-to-
   Multipoint Traffic Engineered Ethernet LSPs [P2MP] and to include the
   extension of the Traffic Engineered Ethernet LSPs over multiple
   domains [ID-FRM].

4.1 GMPLS-controlled Ethernet Network Elements

   The GMPLS-controlled Ethernet network consists of the following
   network elements:

   o) Ethernet Label Edge Router (E-LER)

   The Ethernet LER either resides at the edge of the provider's GMPLS
   network (PE role) or at the edge to customer's network (CE role). In
   the former case, the Ethernet LER interfaces the customer's network
   equipment.

   The E-LER has the functionality required for initiating and
   terminating point-to-point and point-to-multipoint Ethernet
   connectivity across the GMPLS network.

   At the ingress to the GMPLS network, the Ethernet LER takes an
   incoming native frame from a non-label controlled interface, if
   necessary adapts it to an Ethernet frame, adds an Ethernet label and
   forwards it via the appropriate label-controlled interface over a
   Ethernet point-to-point or point-to-multipoint LSP.

   At the egress to the GMPLS network, the Ethernet LER removes the
   Ethernet label from a frame received on a label-controlled interface,
   if necessary extracts the payload, and forwards the native frame
   appropriately towards its destination via a non-labeled-controlled
   interface.

   o) Ethernet Label Switching Router (E-LSR)

   The Ethernet LSR either resides at the core of the provider's GMPLS
   network (P role) or at the edge to provider's GMPLS network (PE
   role). In the former case, the Ethernet LSRs have no direct
   interfaces towards the customers' networks. The Ethernet LSR takes an
   incoming labeled Ethernet frame from a labeled-controlled interface,
   switch the frame using the Ethernet label and forwards the frame



D.P. GELS                Expires - July 2006                 [Page 6]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006


   towards its destination via the appropriate label-controlled
   interface.

   Each GMPLS-enabled network element may function as an Ethernet LER
   and/or as an Ethernet LSR. This means that the path from the Ethernet
   ingress LER to the Ethernet LER might pass through another Ethernet
   LER.

4.2 Ethernet LSP

   An Ethernet point-to-point LSP is defined as an LSP established
   between two Ethernet label-controlled interfaces of E-LERs. These
   interfaces are capable of recognizing the Ethernet frame boundaries
   and can switch data based on the content of the standard IEEE 802.1
   Ethernet frame. The Ethernet LSP originates on an ingress Ethernet
   LER and terminates on an egress Ethernet LER. For a point-to-point
   bi-directional LSP, the same pair of E-LERs acts as both ingress and
   egress E-LERs.

   An Ethernet point-to-multipoint LSP is defined as a unidirectional
   LSP terminating on more than one Ethernet label-controlled interfaces
   of E-LERs.

   At the E-LER, the frame is assigned to an LSP tunnel, and no further
   header analysis is required by subsequent Ethernet LSRs. Throughout
   the GMPLS-enabled Ethernet network, the forwarding operation is
   driven by the labels which are encoded in the standard IEEE 802.1
   frame header (either 802.1ad or 802.1ah).

4.3 Reference Architectures

   o) Edge-to-edge Reference model

   Figure 1depicts the "edge-to-edge" network reference model for a
   point-to-point Ethernet LSP across a GMPLS-enabled Ethernet network.
   In this model, the CE (Customer Edge) network element is attached to
   a PE (Provider Edge) network element via a CE-PE interface. The PE
   network element functions as an E-LER. The Ethernet LSP is
   established between a pair of directly connected E-LERs across the
   GMPLS-enabled Ethernet network, or via a set of P (Provider) network
   elements which function as Ethernet LSR (E-LSR) nodes.


                      ----GMPLS Ethernet Network----
                     |                              |
                     PE              P              PE
   +------+   +------+-------+   +-------+   +------+-----+   +------+
   |      |   |      |       |   |       |   |      |     |   |      |
   |  CE  |---| Pre  |Ingress|---| E-LSR |---|Egress| Post|---|  CE  |


D.P. GELS                Expires - July 2006                 [Page 7]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006


   |      |   | Proc.| E-LER |   |       |   |E-LER | Proc|   |      |
   |      |   |      |       |   |       |   |      |     |   |      |
   +------+   +------+-------+   +-------+   +------+-----+   +------+

                  Figure 1: Edge-to-edge Reference Model

   A point-to-point/point-to-multipoint Ethernet LSP is established to
   provide point-to-point/point-to-multipoint data path between E-LERs.
   When a frame/packet enters an ingress PE via a CE-PE interface, the
   PE processes the incoming traffic flow by performing a number of pre-
   processing operations on the frame. Detailed description of the pre-
   processing operations that may include, for example, VID translation,
   VID insertion/ stripping, etc. are beyond the scope of this
   specification. Note that the CE-PE interface is not restricted to any
   kind of specific interface (hence, not restricted to interfaces
   carrying Ethernet frames) and this, in order to enable to Ethernet to
   be a transport layer for multiple services.

   The pre-processed frame is then presented to the ingress E-LER
   function that 1) maps the corresponding incoming frame to a
   particular Ethernet LSP according to different criteria such as the
   destination, the class of service, etc. and 2) adds an Ethernet label
   to the frame and forwards it via the appropriate label-controlled
   interface along the Ethernet LSP.

   The egress E-LER terminates the Ethernet LSP by removing the Ethernet
   label on incoming frames. The PE then performs post-processing
   operations on the incoming frame and forwards it on the appropriate
   CE-PE interface. Detailed description of these post-processing
   operations that may include, for example, VID translation, VID
   insertion/ stripping, etc. are beyond the scope of this
   specification.

   o) "End-to-end" Reference Model

   Figure 2 depicts the "end-to-end" network reference model for a
   point-to-point Ethernet LSP across a GMPLS-enabled Ethernet network.
   In this model, the CE (Customer Edge) network element is attached to
   a PE (Provider Edge) network element via a CE-PE interface. The CE
   network element functions as an E-LER. The Ethernet LSP is
   established between a pair of directly connected E-LERs across the
   GMPLS-enabled Ethernet network, or via a set of P (Provider) network
   elements which function as Ethernet LSR (E-LSR) nodes.

            ---------------GMPLS Ethernet Network----------------
           |                                                     |
          CE              PE          P           PE             CE
   +------+-------+   +-------+   +-------+   +-------+   +------+-----+
   |      |       |   |       |   |       |   |       |   |      |     |


D.P. GELS                Expires - July 2006                 [Page 8]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006


   | Pre  |Ingress|---| E-LSR |---| E-LSR |---| E-LSR |---|Egress| Post|
   | Proc.| E-LER |   |       |   |       |   |       |   |E-LER | Proc|
   |      |       |   |       |   |       |   |       |   |      |     |
   +------+-------+   +-------+   +-------+   +-------+   +------+-----+

                   Figure 2: End-to-end Reference Model

   Operations driving pre-processing/ingress E-LER function (at ingress
   CE-side), E-LSR function (at PE and P-side) and Egress E-LER/post-
   processing function (at egress CE-side) are identical of those of the
   edge-to-edge model.

   The GMPLS-enabled Ethernet network may be part of a Multi-Layer
   Network (MLN) where multiple switching technologies are supported,
   i.e. multiple regions are supported [MLN_REQ]. Figure 3 presents an
   example of a multi-regional scheme and indicates the relationships
   between the control and data plane entities in a GMPLS-enabled
   network, where the three data planes are controlled by the same GMPLS
   control plane instance. In this figure, node A corresponds to the CE
   and node B to the PE (as depicted in Figure 2).

          +-----------+       +-------------+       +-------------+
          |     A     |       |     B       |       |     C       |
          | +-------+ |       | +---------+ |       | +---------+ |
          | |  PSC  | |OSPF-TE| |  L2SC   | |OSPF-TE| |   LSC   | |
          | |  LSR  |<--------->|  LSR    |<--------->|   LSR   | |
   control| |       | |RSVP-TE| |Ethernet | |RSVP-TE| |    CP   | |
   plane
          | +-------+ |       | +---------+ |       | +---------+ |
   """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
          | +-------+ |       |             |       |             |
          | |  PSC  | |       |             |       |             |
          | |  LSR  |----+    |             |       |             |
   IP/MPLS| |       | |  |    |             |       |             |
          | |       | |  |    |             |       |             |
          | +-------+ |  |    |             |       |             |
          +-----------+  |    |             |       |             |
    ....................................................................
                         |    | +---------+ |       |             |
                         |    | |  L2SC   | |       |             |
                         +------|  LSR    |----+    |             |
   Ethernet                   | |         | |  |    |             |
                              | |Ethernet | |  |    |             |
                              | +---------+ |  |    |             |
                              +-------------+  |    |             |
    ....................................................................
                                               |    | +---------+ |
                                               |    | |   LSC   | |
                                               +------|   LSR   | |


D.P. GELS                Expires - July 2006                 [Page 9]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006


   lambda                                           | |         | |
                                                    | |  lambda | |
                                                    | +---------+ |
                                                    +-------------+

                  Figure 3: Data plane and control plane

   The aggregation of traffic into the same LSP is possible in this
   multi-regional scheme. LSP nesting may be supported as well, for
   example, packet LSPs may be nested into an Ethernet LSP and Ethernet
   LSPs may be nested into lambda LSPs.

4.4 GMPLS Control Plane Elements

   The E-LER and the E-LSR network elements implement the GMPLS control
   protocol to enable constraint-based routing and explicit routing, and
   to automatically configure the Forwarding Information Base (FIB) with
   the forwarding state.

   IPv4 and/or IPv6 addressing are used to identify the Ethernet L2SC
   interfaces. Unnumbered links and bundled links should be used to
   enhance the addressing scalability and to eliminate the need to apply
   an IP address to each Ethernet L2SC interface.

   The OSPF-TE/IS-IS TE routing protocols can be used to distribute the
   network element capabilities and to disseminate TE routing
   information over the interfaces. The bandwidth, as well as the other
   TE attributes, of each port/bundled link, or the bandwidth of each
   Ethernet LSP, can be treated as a constraint during path computation.

   The GMPLS RSVP-TE is used to support Ethernet point-to-point LSP
   setup, maintenance and tear down. In order to be compatible with the
   global GMPLS framework and provide a global unified TE framework,
   multiple switching layers may be supported and ownership/trust models
   (e.g. overlay, peer) may be applied. For details, see below the
   Multi-Layer Network (MLN) model.

4.5 Ethernet Label

   GMPLS makes use of the structure of the standard IEEE 802.1 Ethernet
   frame. The Ethernet label is inserted in the Ethernet encapsulation
   and is part of the Ethernet MAC frame header. A GMPLS Ethernet-
   labeled frame is defined as an Ethernet MAC frame whose header
   encodes the label value. The coding of the Ethernet label does not
   modify the format of the standard Ethernet frame, although it may add
   new semantics to one or more fields. The switching decision is based
   on the label part of the Ethernet frame header. Figure 4 depicts a
   logical view of the protocol layers.



D.P. GELS                Expires - July 2006                [Page 10]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006


                         +---------------------------+
                         |         Payload           |
                         +---------------------------+
                         |         Ethernet          |
                         +---------------------------+
                         |         Physical          |
                         +---------------------------+

                 Figure 4: Logical Protocol Layering Model


   The Ethernet MAC frame header includes the EtherType, different VLAN
   TAGs, and the destination and source MAC addresses.

   GMPLS Ethernet switches need to be able to correctly handle all types
   of Ethernet MAC frames, including GMPLS-labeled frames, to ensure co-
   existence with legacy Ethernet switches. GMPLS functionality can co-
   exist with IEEE 802.1 bridge control and management functionalities
   on the same network element. The common network resources should be
   either pre-partitioning or dynamically selected.

   The architecture allows different label encoding techniques. A
   specific encoding technique may be selected according to the
   capability of the GMPLS-enabled Ethernet network element and/or to
   the capability of the label-controlled Ethernet interface, etc.

   Labels are locally assigned, interpreted and have local significance.
   This does not preclude that the same label value can be assigned by
   consecutive hops. Also Ethernet label and label switching technique
   must be extensible for the establishment and support of multiple-
   domain Ethernet LSP, point-to-multipoint LSPs (carrying Ethernet
   multicast traffic) and easily support exchange of Ethernet broadcast
   traffic.

   The techniques are considered as candidate for the encoding of the
   Ethernet label.

   o) Link-local label: IEEE 802.1ad S-VID (amendment to IEEE Std
   802.1Q-1998)

   Figure 5 depicts the format of the standard IEEE 802.1ad Ethernet
   frame.

                                TAG
                             ---------
                            /         \
   +-----------+------------+----+----+----+---------------+--------+
   |           |            |    |    |    |               |        |
   | MAC Dest  |  MAC Src   |TPID|TCI |LEN\|    Payload    | FCS    |


D.P. GELS                Expires - July 2006                [Page 11]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006


   | Address   |  Address   |    |    |Type|               |        |
   |           |            |    |    |    |               |        |
   +-----------+------------+----+----+----+---------------+--------+

                Figure 5: Standard IEEE 802.1Q Frame Format

   The TAG protocol Identifier (TPID) is a 16-bit length field which is
   set a value of 0x88a8 to identify the frame as an IEEE 802.1ad tagged
   frame. The TAG Control Information (TCI) is a 16-bit length field.

   In this technique, the Ethernet label is encoded in the TCI field of
   the S-VLAN TCI (see Figure 6). The length of the Ethernet label is 12
   bits providing for a label space of 4k values per link.

   S-VID translation is used in this technique. S-VID processing is
   supported on most Ethernet switches. MAC address learning may be
   inhibited, depending on the behavior of the forwarding entity.

   GMPLS signaling is used to configure the S-VIDs along the nodes
   traversed by the Ethernet LSP.

   Figure 6 depicts the S-VLAN TAG Control Information (TCI)

                    Oct:  1               2
                         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         | PCP |D|       VID             |
                         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    bit:  8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1

   Figure 6: TCI Format

   The Priority Code Point (PCP) is a 3-bit length field, which is used
   to convey priority and drop eligibility parameters. This 3-bit field
   refers to the 802.1p priority.

   The D bit (1 bits) is the Drop Eligible Indicator (DEI) bit.

   The VLAN Identifier (VID) is a 12-bit length field uniquely
   identifying the VLAN to which the frame belongs. Its value can be
   between 0 and 4,095.

   o) Link-local label: IEEE 802.1ad Stacked VLAN (QinQ)

   Figure 7 depicts the format of the IEEE 802.1ad Ethernet frame with
   Stacked VLAN (QinQ).

                            S-TAG     C-TAG
                          --------   -------
                         /        \ /       \


D.P. GELS                Expires - July 2006                [Page 12]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006


   +----------+----------+----+----+----+----+----+---------------+---+
   |          |          |    |    |    |    |    |               |   |
   | MAC Dest |  MAC Src |TPID|TCI |TPID|TCI |LEN\|    Payload    |FCS|
   |  Address |  Address |    |    |    |    |Type|               |   |
   |          |          |    |    |    |    |    |               |   |
   +----------+----------+----+----+----+----+----+---------------+---+

         Figure 7: Standard IEEE 802.1ad Format with Stacked VLAN.

   In this technique the concatenation of the S-VID (i.e. the VID of the
   S-TAG) and the C-VID (i.e. the VID of the C-TAG) is used as the
   Ethernet label, resulting in a unique 24-bit length label.

   This technique makes use of VID translation. Neither MAC learning nor
   flooding for the range of VIDs are required. GMPLS is used to
   configure the 24-bit label.

   o) Domain-wide label: IEEE 802.1ah B-VID concatenated with B-MAC DA

   In this technique, the concatenation of the VID (encoded in the TCI
   immediately following the DA and SA MACs) and the Destination MAC
   Address (DA MAC) is used as the Ethernet label, resulting in a unique
   60-bit label. The VID can be a Q-TAG (Ethertype for TCI=0x8100), a
   802.1ad S-TAG (Ethertype for TCI=0x8a88) or a 802.1ah B-TAG
   (Ethertype TBD) depending on the network context. This technique
   provides for a private sub-network labeling solution as the MAC
   address space is "sub-network specific". This solution mandates
   enforcement of unicast only traffic exchange for the specified (pre-
   configured) VID range.

   In order to use the unique 60-bit label, the normal mechanisms by
   which Ethernet populates the forwarding table for the allocated range
   of VIDs should be disabled, for example, MAC learning and flooding
   are disabled for an allocated VID range, blocking is disabled, etc.
   GMPLS is used to configure the 60-bit label.

   Note that having a label encoding technique which uses a network wide
   label space definition requires that the support of the whole network
   in this technique, even in case of multiple domains.

5. Control Plane Operations

   The IP control channel between GMPLS L2SC nodes can be out-of-band or
   in-band. The exchange of signaling and routing information between
   adjacent GMPLS nodes and processing MUST be strictly independent of
   the control channel implementation.

5.1. TE/Routing information distribution



D.P. GELS                Expires - July 2006                [Page 13]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006


   To facilitate IGP operations, such as forming neighbor adjacencies,
   flooding link state database packets, and representing topology,
   routing should treat the Ethernet broadcast point-to-point control
   channel between adjacent E-LSRs as a point-to-point circuit.

   The routing distribution must support the exchange of TE (intra-
   domain) and reachability (intra and inter-domain) information across
   the GMPLS Ethernet network(s).

   In order to support different label-encoding techniques, it may be
   necessary to extend the TE information distribution protocols (OSPF-
   TE [RFC3630]/ISIS-TE [RFC3784]) with the following capabilities:
   Label-controlled Ethernet Interface Switching Capability Descriptors
   as an label-controlled Ethernet interface may support more than label
   switching technique.

   These capabilities will be distributed as part of the routing
   distribution and will be considered as constraints during path
   selection.

5.2. Signaling

   The signaling protocol utilizes downstream-on-demand label allocation
   and distribution, with ingress-initiated ordered control. The
   signaling mechanisms MUST apply to both the bi-directional and
   unidirectional Ethernet LSP setup.

   GMPLS RSVP-TE [RFC3473] signaling for setup/teardown of Ethernet LSPs
   (across GMPLS-enabled Ethernet network elements) should be supported
   and it must keep RSVP sessions significant on an end-to-end basis.

   The Generalized Label Request is defined in [RFC3471]. The Ethernet
   LSP encoding type and switching type to be used for requesting an
   Ethernet label are "Ethernet" and "L2SC" respectively. In order to
   support different label-encoding techniques, it may be necessary to
   extend possible values for the LSP encoding type.

   The specific label-controlled Ethernet LSP parameters should be
   described in the signaled traffic parameters (t_spec/r_spec). These
   parameters must include the L2 link type that comprises the requested
   Ethernet LSP, for example, the Ethernet port and the MTU value. They
   MUST also be capable of describing the traffic parameters for this
   Ethernet LSP, such as the Peak Rate (PIR and PBS), the Committed Rate
   (CIR and CBS), and the Excess Rate (EIR and EBS).

   Explicit and record routing must be supported for scenarios making
   use of source routing, for example, for those that provide
   constraint-based routing (for resource and/or data traffic oriented
   TE) and loop avoidance. Explicit routing, when used, must follow the


D.P. GELS                Expires - July 2006                [Page 14]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006


   procedures defined in [RFC3209], [RFC3473], and [RFC3477]. Record
   routing, when used, must follow the procedures defined in [RFC3209],
   [RFC3473], and [RFC3477].  Explicit label control should be supported
   during provisioning of Ethernet LSPs.

   The GMPLS re-routing mechanisms should be usable for the recovery of
   Ethernet LSPs, including, end-to-end and segment LSPs. Ethernet LSP
   notification and graceful deletion procedures [RFC3473] should be
   supported. Graceful restart upon a control channel and node failure
   should also be supported.

   Nesting of Ethernet LSPs or PSC LSPs into an FA LSP should be
   supported when the head/tail end-nodes provide de/multiplexing
   capabilities.

   Ethernet LSP splicing [RFC3471] and Ethernet LSP stitching [RSVP-ID]
   must be envisioned in the context of multi-domain environments. The
   solution must support both edge-to-edge and end-to-end models and
   their specific signaling operations.

5.3. Link discovery

   Nodes are inter-connected by point-to-point L2SC links. GMPLS L2SC
   nodes MUST support discovery of per-TE link capabilities.

   In addition, GMPLS link discovery SHOULD provide the following:
   - Data link property correlation to support the aggregation of
   multiple data links into a single TE link and the synchronization of
   their properties
   - Data link verification to check the data links' physical
   connectivity and to verify the mapping of the interface ID to link ID
   and their local-remote associations

   Optionally, fault management MAY be provided to suppress alarms and
   localize failures. It may be required to extend the LMP in order to
   provide this functionality for GMPLS-controlled Ethernet networks.

5.4. Security

   The introduction of Ethernet LSP signaling MUST prevent attacks by
   offering adequate filters (like ACLs or other new systems).

   The Ethernet LSP SHOULD reduce data plane threats, as the number of
   network entry points to control is reduced. An Ethernet LSP is by
   nature a hermetic tunnel with a single entry point (ingress E-LER).
   Policing and filtering is required only on the ingress E-LER.





D.P. GELS                Expires - July 2006                [Page 15]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006


   Some mechanisms MUST be provided at the network edges (on the ingress
   E-LERs) to rate limit the amount of traffic that can transit into a
   given Ethernet LSP.

5.4.1 Attacks on the Control Plane

   There are two threats that concern the control plane. The first
   relates to signaling support by the client side. As LSP tunnels MAY
   be signaled from the client site using RSVP-TE, control of such
   activity MUST be provided to prevent it from being used to fail the
   entire network. Different trust models MUST be supported.

   There MUST be a way to limit, by configuration, the number of
   Ethernet LSPs that can be signaled by a particular client. In
   addition, there must be a way to rate limit RSVP-TE client-control
   plane traffic (mainly via the refresh interval). Moreover, the
   operator MUST be able to rate limit, by configuration, the total
   amount of memory and/or CPU allocated to the RSVP engine, and to
   react appropriately when this limit is reached.

   The second threat derives from the introduction of IP control
   functions in Ethernet equipment (such as the handling of multicast).
   GMPLS Ethernet networks will inherit the security issues of IP
   networks similar to other GMPLS client networks, and the appropriate
   trust models MUST be supported.


6. Security Considerations

   See Section 5.4.1


7. References

7.1.  Normative References

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

   [RFC3209]       Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
                   V., and G. Swallow, "RSVP-TE: Extensions to RSVP
                   for LSP Tunnels", RFC 3209, December 2001.

   [RFC3477]       K.Kompella et al. "Signalling Unnumbered Links in
                   Resource ReSerVation Protocol - Traffic Engineering
                   (RSVP-TE)", RFC 3477, January 2003.

   [RFC3630]       D.Katz et al. "Traffic Engineering (TE) Extensions to
                   OSPF Version 2", RFC 3630, September 2003.


D.P. GELS                Expires - July 2006                [Page 16]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006



   [RFC3784]       H.Smit and T.Li, "Intermediate System to Intermediate
                   System (IS-IS) Extensions for Traffic
                   Engineering (TE)," RFC 3784, June 2004.

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

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

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

7.2.  Informative References

   [MRN-REQ]      K.Shiomoto et al., "Requirements for GMPLS-based
                  Multi-Region Networks (MRN)", Work in Progress, draft-
                  ietf-ccamp-gmpls-mrn-reqs-00.txt.

8. Acknowledgments

9. Author's Addresses

   Dimitri Papadimitriou
   Alcatel
   Francis Wellesplein 1,
   B-2018 Antwerpen, Belgium
   Phone: +32 3 2408491
   Email: dimitri.papadimitriou@alcatel.be

   Nurit Sprecher
   Siemens AG (Seabridge Networks)
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon, 45241 Israel
   Email: nurit.sprecher@seabridgenetworks.com

   Jaihyung Cho
   Electronics and Telecommunications Research Institute (ETRI)
   161 Gajung-dong, Yuseong-gu
   Daejeon 305-350, Korea
   Phone: +82 42 860 5514
   Email:  jaihyung@etri.re.kr

   Loa Andersson


D.P. GELS                Expires - July 2006                [Page 17]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006


   Acreo AB
   Email: loa@pi.se

   Attila Takács
   Traffic Lab, Ericsson Research
   Ericsson Hungary Ltd.
   Laborc 1.
   Budapest, Hungary, H-1037
   Email: attila.takacs@ericsson.com

   Peter Busschbach
   Lucent Technologies
   67 Whippany Rd
   Whippany, NJ 07981, USA
   Phone: +1 973 386 8244
   Email: busschbach@lucent.com

   Don Fedyk
   Nortel Networks
   600 Technology Park
   Billerica, Massachusetts
   01821 U.S.A
   Phone: +1 (978) 288 3041
   Email: dwfedyk@nortel.com

   Dave Allan
   Nortel
   3500 Carling Ave.
   Ottawa, Ontario
   K1Y 4H7
   Phone: (613) 763-6362
   Email: dallan@nortel.com

   Thomas Eriksson
   TeliaSonera AB
   Vitsandsgatan 9, Pv2
   12386 Farsta Sweden
   Email: thomas.a.eriksson@teliasonera.com

   Diego Caviglia
   Email: diego.caviglia@ericsson.com










D.P. GELS                Expires - July 2006                [Page 18]


A Framework for GMPLS-controlled Ethernet Label Switching     Feb 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

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


Intellectual Property

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

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

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











D.P. GELS                Expires - July 2006                [Page 19]