Internet DRAFT - draft-dimitri-gels-framework

draft-dimitri-gels-framework



 
 
 
   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]