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]