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) A. Takács (Ericsson) D. Caviglia (Ericsson) February 2006 Label Encoding Solution Decoder and Analysis for GMPLS-controlled Ethernet Label Switching (GELS) draft-dimitri-gels-solution-eval-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 document introduces the functional criteria as a decoder ring for the selection of GELS label encoding. After detailing each proposed label encoding, each solution is analyzed against these criteria. D.P. GELS Expires - July 2006 [Page 1] Solution Decoder and Analysis for GELS 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 [i]. Reader is also assumed to be familiar with the GELS framework [GELS- FRM]. 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 (ingress and egress) using GMPLS signaling or between one ingress Ethernet LER and multiple egress LERs. In the former case, one refers to a point-to-point Ethernet LSP and in the latter to a point-to-multipoint Ethernet LSP. 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. Connection Oriented Ethernet: defined by LSPs having a single source (ingress Ethernet LERs) and one or multiple destinations (egress Ethernet LERs). LSPs must be created before any Ethernet PDUs can be sent, but exist independently of whether any PDUs are being sent. There is no further routing choice within the LSP. These LSPs maintain ordering of Ethernet PDUs sent from source. D.P. GELS Expires - July 2006 [Page 2] Solution Decoder and Analysis for GELS Feb 2006 2. Functional Criteria This section attempts to set functional criteria for examining, analyzing and comparing the optional solutions listed in Section 3. Naturally, the first and the most important criterion should be compliance with the GELS requirements [GELS-REQ]. At time of writing, this document was not finalized; hence, it may be thus necessary to tune and adjust this section on completion of the requirement draft. A description of the criteria follows. These functional criteria are solution independent and intended to simplify the GELS solution (in terms of label encoding) selection process for implementing connection-oriented Ethernet. Note that the order in which the criteria are specified does not imply the order of importance. 2.1 Ethernet P2P and P2MP TE LSPs Point-to-point (uni and bi-directional) and point-to-multipoint (unidirectional) connections are defined by trails, which have the property of being directed with a single source and one or multiple destinations. Traffic flows should be identified by some connection identifiers rather than by explicitly listing source and destination addresses. This makes Ethernet frame switching substantially faster (as FIDs are just simple look-up tables and are easy to implement in the hardware). In a connection-oriented Ethernet environment, p2p and p2mp connections must be used to construct all other networking services like mp2p and mp2mp services (see Section 2.3). That is, in connection-oriented Ethernet, p2p and p2mp connections are the primary focus that determines the underlying Ethernet label encoding scheme. Connection-oriented Ethernet enables the setting up of p2p and p2mp LSPs based on the service definition and the enforcement of the SLA. Connection oriented Ethernet also requires pre-provisioning of the network connections and that the required resources are pre-allocated and reserved. The solutions should enable realization of the Traffic Engineering resource-oriented (to optimize the network resource usage) and traffic-oriented (delay, jitter, loss, etc.) performance objectives based on the service definition to enforce the SLA. 2.2 Ethernet LSP Merging and LSP Multiplexing LSP merging is referred when at a network element multiple point-to- point LSP segments are joined into a single point-to-point LSP D.P. GELS Expires - July 2006 [Page 3] Solution Decoder and Analysis for GELS Feb 2006 segment in a way that no further differentiation between the original LSP segments is possible. LSP multiplexing is the case when the joined point-to-point LSP segments can be differentiated later on in particular at the common receiver. There are two cases of multiplexing: - a separate label is assigned on a per sender basis - a common label is assigned independently of the sender The GELS framework discusses local vs. domain-wide labels (identifiers). While local labels provide simple method for LSP merging and multiplexing, usage of domain-wide labels results in dependence to the structure and the nature of the label. It must be noted that merging in contrast to multiplexing does not preserve the possibility to identify the source of the corresponding LSP(s). LSP merging and multiplexing deliver a way to provide mp2p services but impact network operation and maintenance requirements: (1) ability to identify specific faulty connections (using OAM mechanisms) (2) ability to police individual senders and connections. Therefore, LSP merging and multiplexing are optional capabilities to be supported by the solution. 2.3 Services The solution should be capable of providing any connectivity service that is supported by standard Ethernet encapsulation (such as IP/MPLS, TDM, etc.). The solution should not constraint the connectivity services delivery by the network. The solution should provide efficient means to simplify the provisioning task in the following aspects: 1. The label distribution and allocation process should have a minimum effect on the network so as to reduce provisioning overhead, as well as to relieve the network synchronization process. 2. Network configuration, provisioning and adjustment should have a minimum effect on the network and services it delivers. 3. The solution should support network trunks in order to simplify the delivery of services. D.P. GELS Expires - July 2006 [Page 4] Solution Decoder and Analysis for GELS Feb 2006 2.4 OAM The solutions should provide means to simplify the network operations maintenance task. The use Ethernet OAM is required to monitor the proper operation of the network. The solutions should provide a means to minimize the number of LSPs that should be monitored. Only network trunks (nesting LSPs) should be monitored and there is no specific requirement to monitor the services within the tunnels. Services may be monitored according to specific service requirements. The solutions should enable the support for OAM (IEEE 802.1ag) messages. The following mechanisms should be supported to detect failures or problems in the network and to ensure the correct operation of the network: 1) Connectivity verification 2) Alarm communication and handling 3) Loopback tests 4) Fault diagnosis (e.g. traceroute) 2.5 Resiliency Network resiliency is the network's ability to restore traffic following failure or attack, and is a critical factor in delivering reliable services. Guaranteed service in the form of SLAs requires a resilient network that instantaneously detects facility or node failures and immediately restores network operation to meet the terms of the SLA. The solution should provide mechanisms o) to match the sub 50 ms failover times required to maintain time- bounded services. The solutions should also support recovery mechanisms that save network resources, that is, without pre- provisioning of bandwidth. For this kind of recovery mechanisms the failover time can be higher that 50 ms. o) to protect against any failure in the network (including failure of boundary nodes in case of inter-domain operation). The recovery mechanisms are categorized as end-to-end LSP recovery (global protection), LSP segment recovery, and local LSP recovery. The solutions should assure the correct inter-working between control plane and data plane (e.g. port protection) recovery mechanism. D.P. GELS Expires - July 2006 [Page 5] Solution Decoder and Analysis for GELS Feb 2006 2.6 Inter-domain The solutions should enable the provisioning of Ethernet LSPs over inter-domains. The peering and the client/server interconnection modes are considered, as follows: (i) Peering mode: Peering is a way of interconnection, where the interfacing between the domains/operators is defined by UNI/E-NNIs. Moreover, peering networks exchange traffic at the same networking layer, that is layer N traffic arriving for domain A will be forwarded in domain B as layer “N” traffic as well. It is possible to further subdivide this mode depending on which topology (addresses, resources, etc.) information are exchanged across the UNI/E-NNI interface. (ii) Client-server mode: The client/server mode of interconnection, the server operator provides a networking service that delivers the client’s traffic. Essentially, the client’s traffic resides on layer N and it transported transparently across the server layer N-1. The identifiers from the client layer and the server are independent. A natural example of this mode of operation is an Ethernet flow (layer N) transported via an SDH/SONET circuit (layer N-1). In certain scenarios, there may be a need to combine together different LSPs such that in the data plane, a single end-to-end LSP is realized and all traffic from one LSP is switched onto the other LSP. This operation is called LSP stitching [STITCHING]. The solutions should support LSP stitching. 2.7 Scalability 2.7.1 MAC Address By nature, a solution for connection-oriented Ethernet should be agnostic with regard to MAC address learning such as to eliminate the FIB flush associated with topology change and flooding operations, which lead to slow recovery and convergence. 2.7.2 VLAN ID (VID) The scalability of the solution should not be impacted by the limited space of VLAN identifier (VID). 2.7.3 Ethernet Frame Switching Ethernet frame switching should be independent of the destination MAC address and SHOULD NOT rely on the customers' destination MAC addresses. D.P. GELS Expires - July 2006 [Page 6] Solution Decoder and Analysis for GELS Feb 2006 2.7.4 Label The scalability of the label value space (and hence its encoding) constraints the number of LSPs that can be concurrently provisioned. The solutions should therefore provide label value and encoding that allow a satisfactory number of LSPs to be provisioned [GELS-REQ]. In addition, the Ethernet label is encoded in the Ethernet MAC frame header. Therefore, the size of the label affects the frame and the length of the payload. Scalability also depends on the size of the label and its implication on the Ethernet frame header size, e.g. MAC encapsulation (DA_B-MAC) in combination with B-TAG etc. or S-TAG (S-VID). 2.7.5 LSP Hierarchy LSP hierarchy can be used to improve the network scalability, the solutions should assure that label encoding is not constraining Forwarding adjacency LSP establishment [RFC 4206]. 2.8 Backward compatibility with IEEE 802.1 The label encoding techniques MUST make use of the structure of the standard IEEE 802.1 Ethernet frame and frame header. The encoding solution should not modify the format of the standard Ethernet frame or the standard Ethernet frame header but may add new semantics to one or more fields. Where the solution should co-exist with IEEE 802.1 bridge control and management functionalities on the same network element it should be backward compatible with legacy Ethernet bridges. In this case, GMPLS Ethernet switches need to be capable of handling all types of Ethernet MAC frames, including GMPLS-labeled frames, to ensure their co-existence with legacy Ethernet switches. 2.9 Applicability The solutions should be examined for each network scenario. It may be that a specific solution is found to be more appropriate for a certain network scenario while a different solution is more suitable for another type of scenario. The solutions should be examined with respect to their deployment in the following types of networks: 1) Metro access and Metro aggregation networks 2) Metro core D.P. GELS Expires - July 2006 [Page 7] Solution Decoder and Analysis for GELS Feb 2006 3) Core and transport networks These scenarios should enable services to scale effectively as the customer base grows, in order to minimize capital expenditures and drive down operational costs. 2.10 Security The solution should provide a means to protect the network from the following threats: 1) Vulnerability to unwanted connectivity (through malicious attacks). 2) MAC spoofing and MAC attacks. 3) VLAN ID attacks. The threats that concern the control plane are described in section 5.4.1 of [GELS-FRM] and are not relevant in the present context. 3. Solution Description 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. +---------------------------+ | Payload | +---------------------------+ | Ethernet | +---------------------------+ | Physical | +---------------------------+ Figure 4: Logical Protocol Layering Model The Ethernet MAC frame header includes the EtherType, different VLAN TAGs, as well as the destination and source MAC addresses. 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. D.P. GELS Expires - July 2006 [Page 8] Solution Decoder and Analysis for GELS Feb 2006 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. 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 following techniques are considered as candidate for the encoding of the Ethernet label. 3.1 S-VID Translation 3.1.1 Label Encoding This link-local label technique makes us of the IEEE 802.1ad S-VID (amendment to IEEE Std 802.1Q-1998) S-VID translation mechanism. The idea behind this solution is to prevent the control plane from dealing with any MAC address space specifics such as to ensure independence and transparency to the data plane addressing specifics. This results in a straightforward re-use of the GMPLS Unified control plane and TE mechanisms. Indeed, an Ethernet LSR behaves as any other LSR currently manageable by a GMPLS-based control plane. Figure 5 depicts the format of the standard IEEE 802.1ad Ethernet frame. TAG --------- / \ +-----------+------------+----+----+----+---------------+--------+ | | | | | | | | | MAC Dest | MAC Src |TPID|TCI |LEN\| Payload | FCS | | 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. D.P. GELS Expires - July 2006 [Page 9] Solution Decoder and Analysis for GELS Feb 2006 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. 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 PCP can be used in order to encode DiffServ parameters assuring the DiffServ support for Ethernet LSP. In other words can be used as the EXP filed of the MPLS shim header. 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. 3.1.2 Functional Behavior 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. The pre-processing operations may include, for example, VID translation, VID insertion/stripping, etc. These operations are beyond the scope of this document. The pre-processed frame is then presented to the ingress E-LER function. The latter takes an incoming pre-processed frame, 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. Throughout the GMPLS-controlled Ethernet network, Ethernet LSRs switches labeled Ethernet frames via the appropriate interface based on the ingress port and the S-VID Ethernet label, which is encoded in D.P. GELS Expires - July 2006 [Page 10] Solution Decoder and Analysis for GELS Feb 2006 the standard IEEE 802.1 frame header. The switching operation replaces the S-VID Ethernet label before the frame is transmitted. Frames that are received with an unknown S-VID Ethernet label are silently discarded. The forwarding decision is based on the information residing in the FIB. This table may be configured by the GMPLS control plane. The egress E-LER terminates the Ethernet LSP by removing the S-VID label from incoming frames received on a label-controlled interface, if necessary extracts the payload, and presents the frame for appropriate post-processing operations. Post-processing may include, for example, VID translation, VID insertion/ stripping, etc. These operations are beyond the scope of this specification. The frame is then appropriately forwarded towards its destination via the appropriate label-controlled interface. The S-VID Ethernet label is part of the Ethernet MAC frame header and has link local scope. The same S-VID Ethernet label can be reused on different interface. The coding of the S-VID Ethernet label does not modify the format of the standard Ethernet frame, although it may add new semantics to one or more fields. No modification is made to the layers over which the Ethernet payload may be transmitted. The S-VID Ethernet labels are assigned and interpreted locally and have local significance. This does not preclude the assignment of the same S-VID Ethernet label value by consecutive hops. The S-VID Ethernet labels can be used for the establishment and the support of Ethernet LSPs over multiple domains and for the support of point- to-multipoint Ethernet LSPs) to carry Ethernet multicast traffic. End-to-end Ethernet connectivity can be used to provide any service that is supported by standard Ethernet. These services are mapped in the Ethernet LERs to an appropriate Ethernet LSP. The Ethernet frame is extended with the S-VID Ethernet label when it is sent over the Ethernet LSP. With Ethernet services, the C-VID (included in the C- TAG) may, as an option, be transmitted transparently over the Ethernet LSP (i.e. preserved over the network), depending on the service definition. 3.1.3 Control Plane GMPLS signaling is used to configure the S-VIDs along the nodes traversed by the Ethernet point-to-point or point-to-multipoint LSP. The idea behind this solution is to prevent the control plane from dealing with any MAC address space specifics such as to ensure independence and transparency to the data plane addressing specifics. GMPLS is used to configure the 12-bit S-VID label during Ethernet LSP provisioning. D.P. GELS Expires - July 2006 [Page 11] Solution Decoder and Analysis for GELS Feb 2006 This results in a straightforward re-use of the GMPLS unified control plane and TE mechanisms. Indeed, an Ethernet LSR behaves as any other LSR currently manageable by a GMPLS-based control plane. This technique may coexist with Ethernet bridging in the same network or on the same network element. On the same port, GMPLS controlled Ethernet label switching method and Ethernet bridging may coexist as long as the S-VID space is configurable (to discriminate between the switching and bridging ranges). A future work will be undertaken to automate this configuration process using RSVP-TE protocol (for inst. by extending the capability of the label set object). 3.2 Stacked VLAN TAGs (QinQ) Translation 3.2.1 Label Encoding Figure 7 depicts the format of the IEEE 802.1ad Ethernet frame with Stacked VLAN TAGs (QinQ). S-TAG C-TAG -------- ------- / \ / \ +----------+----------+----+----+----+----+----+---------------+---+ | | | | | | | | | | | 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. 3.2.2 Functional Behavior The Stacked VLAN TAG translation functional behavior is the same as the S-VID translation functional behavior (see Section 3.1.1), except for the label space, which is wider (24 bits). For details about the functional behavior, refer to section 3.1.1 above, replacing the term 'S-VID Ethernet label' with the term 'Stacked VLAN TAG Ethernet label'. In cases where the 4.096 link local S-VID label space is too small, the stacked VLAN Ethernet label can be used. D.P. GELS Expires - July 2006 [Page 12] Solution Decoder and Analysis for GELS Feb 2006 Note that when the stacked VLAN Ethernet label is used for the Ethernet LSP, only a small address range belonging to the outer VLAN tag has to be assigned to the GMPLS-controlled Ethernet Label switching. The available VLAN range for bridging services is therefore hardly affected, while the GMPLS-controlled Ethernet Label switching can use the full address range of the inner tag. 3.2.3 Control Plane The idea behind this solution is to prevent the control plane from dealing with any MAC address space specifics such as to ensure independence and transparency to the data plane addressing specifics. GMPLS is used to configure the 24-bit label during Ethernet LSP provisioning. This results in a straightforward re-use of the GMPLS unified control plane and TE mechanisms. Indeed, an Ethernet LSR behaves as any other LSR currently manageable by a GMPLS-based control plane. 3.3 Concatenated VID/MAC Domain-wide labels 3.3.1 Label Encoding 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. The control plane is required to ensure loop freeness for the LSPs. 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. 3.3.2 Functional Behavior Invariant VID/MAC domain-wide labels are proposed such as to enable reuse the IEEE 802.1 compliant hardware and forwarding and provide D.P. GELS Expires - July 2006 [Page 13] Solution Decoder and Analysis for GELS Feb 2006 VLAN independent point-to-point LSPs. Aspects of the profile used are: 1) That the ether-relay filter database (forwarding tables) can be configured with static entries by a management system or control plane 2) That static entries are not tied to any internal forwarding identifier (FID) or spanning tree 3) That Ethernet LSRs may be VLAN partitioned such that a unique topology per VLAN is possible a.k.a. independent VLAN learning (IVL) 4) The ability to disable MAC learning by VLAN ID 5) The ability to disable spanning tree by VLAN ID 6) The MAC addressed interfaces in the Ethernet frame header are provider owned addresses and not related to customer MAC terminations. 7) The VLAN ID space is the provider administered VLAN ID space A pre-provisioned portion of the VLAN ID set (referred to as the connection-oriented Ethernet VLAN ID subset) is decoupled from the IEEE 802.1 spanning tree, and the use of the VIDs in this subset is confined to unicast forwarding to guard against configuration errors such that any loop free constraint for the connection-oriented Ethernet VLAN ID subset has been removed. This subset is available across the whole GMPLS-controlled Ethernet domain. The topology for each of the delegated VIDs corresponds to the complete physical mesh of the Ethernet subnetwork, and unique connectivity instance (P2P or MP2P multiplex) to each MAC address is possible per VID. One way to think of the meaning of a VID out of the pre-provisioned VLAN ID subset is as an instance identifier for unique connectivity to the specified MAC. This permits a plurality of uniquely routed paths up to the connection-oriented Ethernet VLAN ID subset size to any given MAC. Although VIDs are nominally thought of as global identifiers for a VLAN, for the purposes of labeled Ethernet frame forwarding, they behave as single modifiers bound to the destination MAC address. Since MAC addresses are unique with in the scope of the connected network, the VID-MAC tuple becomes a unique 60-bit label that can be destination administered (see Label Encoding). The ability to multiplex paths traveling to the same destination is a desirable property to conserve forwarding state. This creates MP2P connectivity as a tree of P2P connections rooted at a destination. These multiplexed paths share a common VID-DA-MAC tuple yet retain the identity of the source due to the inclusion of the SA-MAC. The SA-MAC may be interpreted at the end of the path for additional operations or when capturing packets at other points on the paths. This is a useful property from the point of view of OAM fault and performance management at the expense of performing SA-MAC address lookup on a per-interface basis. D.P. GELS Expires - July 2006 [Page 14] Solution Decoder and Analysis for GELS Feb 2006 This technique is designed such as to relax a number of constraints for the routing of MP2P connectivity: - maintains the Ethernet encoding of priority information per-packet permitting an Ethernet analogy to E-LSPs - requires uni-directional paths which share the same physical resources but allows independent VID assignments. - allows resource reservation independently in both directions. Provisioned LSPs are identified from originating to terminating provider MAC interface. The service offered to the end points of an Ethernet "connection" configured as outlined above is the ability to transport any payload that can be identified via Ethernet LLC multiplexing. A non exhaustive list would be: - client Ethernet MAC frames (802.1ah, under IEEE 802.1 definition) - MPLS - IP, IPX, etc. This technique mandates enforcement of unicast only traffic exchange for the specified (pre-configured) VID range. Meaning that server layer multicast replication of client multicast traffic is not supported, although client multicast traffic may still be encapsulated and transported P2P using this technique. 3.3.3 Control plane GMPLS is used for the control of the point-to-point paths. We recognize the requirement for a single control plane to manage the point-to-multipoint paths as well (for multicast traffic). However such objective is outside the scope of this document. Using this label encoding technique, a portion of the VLAN ID space in an IVL capable switch is delegated to a control or management plane. The control plane is used to directly populate the filter database with (VID)-(DA-MAC)-(egress port) tuples to configure unicast forwarding of Ethernet frames. A given (VID)-(DA-MAC) tuple resolving to a single egress port on a Ethernet LSR, and a connection being composed of a contiguous set of Ethernet LSRs configured this way. The goal of bringing the work to the IETF is to use GMPLS as the unified GMPLS control plane for point to point LSPs. GMPLS can take the role of the control plane that populates the Ether-relay filter database. The following GMPLS extensions are foreseen for GMPLS support: - use of the upstream label object to establish bi-directional paths - optional use of suggested label - use of the association object for signaling of protection switched paths D.P. GELS Expires - July 2006 [Page 15] Solution Decoder and Analysis for GELS Feb 2006 - definition of a new label object C-type for the VID-MAC tuple label 4. Comparison Two techniques are currently proposed as solutions for the GELS, VID/DA MAC switching (using VID/DA MAC domain wide invariant labels) and VID switching (using VID/stacked VID link local labels). The former (see Section 3.3) makes use of a 60-bit domain-wide label which is built from the concatenation of the 48-bit destination MAC address of the provider edge node (DA B-MAC) and the 12-bit provider VID (B-VID). This solution is referred to as solution 1. The latter (see section 3.1 and 3.2) makes use of one of the following local labels: the 802.1ad 12-bit S-VID, and the 24-bit label which is created from the 802.1ad stacked VLAN (Q-in-Q). The characteristics of a domain-wide label and of a local scope label are described and analyzed in the GELS framework. This solution is referred to as solution 2. This section attempts to examine, analyze and compare the candidate solutions which are described in Section 3 according to the criteria listed in Section 2. Note that for both techniques, the analysis and comparison assume the use of GMPLS for enabling the provisioning and maintenance of the Ethernet LSPs, in both techniques. Note also that the third solution class (MAC-only labels) may be considered in future version of this document. 4.1 Ethernet P2P and P2MP TE LSPs Both solutions provide for Connection Oriented Ethernet. In both techniques the network is pre-configured with the connections and the resources are allocated and preserved. In both techniques the traffic flow is identified by a connection identifier (label). Solution 1 handles unidirectional and bi-directional point-to-point Traffic Engineered Ethernet LSPs. However, it does not handle unidirectional point-to-multipoint Traffic Engineered Ethernet LSPs. The VID space is dedicated to unicast purposes due to the IVL capability, which is based on unicast forwarding corroding to the B- VID/B-MAC tuple. Note that while in general, VID spaces should be independent of the type of the traffic, here, the VID dedicated space is enforced for unicast purposes. So, multicast traffic support is to provided by the legacy connectionless Ethernet forwarding. D.P. GELS Expires - July 2006 [Page 16] Solution Decoder and Analysis for GELS Feb 2006 Solution 2 handles unidirectional and bi-directional point-to-point Traffic Engineered Ethernet LSPs and unidirectional point-to- multipoint Traffic Engineered Ethernet LSPs. Both solutions enable Traffic Engineering to optimize the network resource usage. 4.2 Ethernet LSP Merging and LSP Multiplexing In Solution 1 due to the nature of the label which is constructed from the DA B-MAC address and the B-VID, connections may be multiplexed along the way to the destination. However, due to the label structure there is no possibility to avoid data plane merging that violates the end-to-end guaranteed BW per LSP. Although the Ethernet encoding of priority information is reserved per-packet, the end-to-end guaranteed bandwidth for a specific LSP can be violated and used by other LSPs multiplexed into the same path (for example with higher priority packets). In order to avoid Ethernet LSP multiplexing and in order to guarantee end-to-end bandwidth per LSP a different label should be assigned to each LSP (e.g. either a different DA B-MAC address should be assigned to each LSP or a different B-VID should be assigned to each LSP). Solution 2 provides end-to-end QoS with guaranteed bandwidth and controlled jitter and delay based on the service definition to enforce the SLA. Solution 2 provides a simple method for multiplexing: each Ethernet LSR should assign a unique label to each particular source (label assigned on a per sender basis). 4.3 Services In Solution 1, frames are mapped at the Ethernet LER to LSPs according to the port on which the frames were received or according to the outer VID. In Solution 2, frames are mapped at the Ethernet LER to LSPs according to the port on which the frames were received and the VID of the outer VID. Both solutions are capable to provide any connectivity service that is supported by standard Ethernet encapsulation (such as IP/MPLS, TDM, etc.). The solutions are positioned as follows for what it concerns service provisioning and maintenance: o) In Solution 1, a pool of unique MAC addresses and a range of VIDs should be configured at the provider Ethernet LER. LERs should also manage VID/MAC address relation. The label has a domain wide D.P. GELS Expires - July 2006 [Page 17] Solution Decoder and Analysis for GELS Feb 2006 significance. Any modification to a label or addition of a new label is circulated across the network. In Solution 2, only a range of VIDs that should be used for switching purposes technique should be configured at each Ethernet LSR. When an Ethernet LSP is provisioned across the network, each node along the path arbitrarily allocates a free label for the LSP. The label has only link local significance. o) Both solutions provide network trunks (nesting LSPs) in order to simplify the delivery of services across the network. Theoretically the number of services that may be transmitted within the tunnels is unlimited. o) Both solutions employ OAM and provide a means to minimize the number of LSPs to be monitored. Only network trunks should be actively monitored. Services may be monitored according to specific service requirements. With Solution 2 (12-bit), up to 4K tunnels may be provisioned per port. Within each port up to 4K services can be delivered. With Solution 2 (24-bit), up to 16M tunnels may be provisioned per port. Other combinations are possible as well. Using this solution, LSPs can also be used to deliver services (with no tunneling). This capability has a benefit in particular network scenarios, where there is no need for the overhead of tunnel provisioning and superfluous encapsulation. 4.4 OAM Solution 1 requires unicast CC OAM messages which are currently not defined or implemented. Moreover, when using this solution, the SA- MAC can be captured at intermediate Ethernet LSRs or at the egress Ethernet LER to detect misconnectivity where traffic from one LSP is leaked into another LSP. Note that misconnectivity can occur due to misconfigurations. Solution 2 enables the support of OAM (IEEE 802.1ag) messages, to ensure the correct operation of the network. CC OAM frames are transmitted within the LSP and will reach their destination. Each LSP is identified by an end-to-end connection identifier (5-tuple). The customer's information may be interpreted to detect misconnectivity. OAM messages are sent along the path to detect failures or problems in the network. 4.5 Resiliency Both Solutions provide mechanisms for matching the sub 50 ms failover times required for maintaining time-bounded services. D.P. GELS Expires - July 2006 [Page 18] Solution Decoder and Analysis for GELS Feb 2006 Due to the domain-wide nature of the label used in Solution 1, certain recovery mechanisms that are provided by the GMPLS can not be applied in case of domain-wide VID/MAC label (e.g. 1:1 fast reroute which apply two different labels for the protected and the detour LSPs, etc.). In case of LSPs over multiple domains (i.e. inter-domain), Solution 1 can not protect against a failure of an edge node (which connects to other domains). This is true for each of the three recovery techniques (unless dual homing is supported, but this complicated solution should be proven to work). Solution 2 supports all three LSP recovery techniques: global (end- to-end), segment and local. This solution provides mechanism to protect against any failure in the network (including failure of boundary nodes in case of an inter-domain operation). 4.6 Inter-domain Both solutions enable the provisioning Ethernet LSPs across multiple domains (inter-domain). Both techniques support the peering and the client/server interconnection modes. In Solution 1, when peering is supported, the network trunk is terminated at the edge of a domain. The services may be processed according to one of the following VIDs: C-VID, or S-VID or I-SID. The I-SID may be translated to S-TAG, limiting to 4094 service instances across an E-NNI. It may be translated to a DMZ value, limiting to 2**24 service instances across an E-NNI. In any case, note that as the 802.1ah is not final yet, the I-SID processing is not defined. The [CCAMP-ID-FRM] defines three options for signaling TE LSPs across multiple domains, as follows: LSP nesting (client/server mode), contiguous LSP (peering mode) and LSP stitching (peering mode). In Solution 1, the contiguous LSP option will probably not be supported because of the domain-wide nature of the label. If supported, the carriers' would have to offer each other globally unique label. In such a case, the label would come from each carrier's administrative space (MAC address of the terminating interface). In Solution 2, all the three signaling options are supported. 4.7 Scalability 4.7.1 MAC Address D.P. GELS Expires - July 2006 [Page 19] Solution Decoder and Analysis for GELS Feb 2006 Both solutions disable MAC learning for the VID range that is supported for connection-oriented Ethernet purposes. Thus, the flush FIB operation associated with topology change and flooding operations, which leads to slow recovery and convergence, is eliminated. The switching operation in both techniques is independent of the destination subscriber MAC address. 4.7.2 VLAN ID (VID) In Solution 1, the VID in conjunction to the DA B-MAC is used as domain-wide label. As specified above, in order to avoid the LSP multiplexing and guarantee end-to-end BW per LSP, a different label should be assigned to each LSP. Hence, either a different B-VID or a different DA B-MAC address should be assigned to each LSP between a particular pair of source and destination Ethernet LERs. In case of a different DA B-MAC address, it requires the provisioning of a pool of MAC addresses per pair (source and destination) of Ethernet LERs dependent on the required number of LSPs that should be provisioned between this pair of Ethernet LERs. In case of a different B-VID, it violates the VLAN scalability. The space of the VID is limited per node and a certain range of VIDs should be assigned to the bridging function (in order to provide for example multicast services, etc.). In Solution 2, the VID label has link local significance and can be reused on different interface (per interface label spaces similar to ATM’s VCI/VPI or MPLS’s label space). The label space can reach a maximum of 4K VIDs per port if the 12_bit S-VID labels is used and a maximum of 16M VIDs if 24-bit labels are used. 4.7.3 Ethernet Frame Switching Both solutions do not rely on the customers' destination MAC addresses. 4.7.4 Label Both solutions encode the Ethernet label as part of the Ethernet MAC frame header. Solution 1 makes use of the 802.1ah frame format: 48 bits SA B-MAC address, 48 bits DA B-MAC address, 32 bits B-TAG and 24-bit I-SID. The label being a combination of the DA B-MAC and the B-VID is 60- bits long. Solution 2 makes use of the 802.1ad frame format. This requires a 32- bit S-TAG to encode the S-VID label or 64-bit S-TAG + C-TAG to encode the extended the 24-bit label (composed by the S-VID and C-VID). D.P. GELS Expires - July 2006 [Page 20] Solution Decoder and Analysis for GELS Feb 2006 In solution 1, the label space has a 60-bit length and has a domain wide significance. The implication on the number of LSPs that can be provisioned in the network is not trivial. Theoretically, this number is 2^60. Practically, this requires a tedious provisioning effort. Depending on the connectivity, a varying set of MAC addresses should be manually configured. In solution 2, the number of LSPs that can be provisioned depends on the label type. With S-VIDs, up to 4K LSPs per port can be provisioned. With 24-bit labels up to 16M LSPs per port can be provisioned. In addition, the label length and space size also affects the implementation of the FID's lookup table. In Solution 1, the key to the lookup table is 60-bits long. In Solution 2, it is either 12-bits or 24-bits long. 4.7.5 LSP Hierarchy TBD. 4.8 Backward compatibility with IEEE 802.1 Both label encoding techniques make use of the structure of the standard IEEE 802.1 Ethernet frame. Both solutions do not modify the format of the standard Ethernet frame, but do add new semantics to one or more fields. 4.9 Applicability 1) Metro access and Metro aggregation networks The Metro access and the metro aggregation networks by nature are small networks which are characterized by having a small number of nodes deployed at the network. The role of that metro access/metro aggregation network is to provide connectivity between a user and a service platform (e.g. BRAS, edge router, etc.). Employing Solution 1 in such environment adds a lot of overhead in the network (e.g. MAC encapsulation), and increases CAPEX, without apparent benefits. The idea behind this solution is to increase CAPEX at the edge of the network in order to reduce CAPEX at the core of the network. In typical Metro access/Metro aggregation networks there are hardly any core routers (if at all) while there are many edge nodes. In addition, both DSLAMs and BRAS do not handle IEEE 802.1ah frames. They are only capable of extracting/adding one or two VLAN TAGs. It D.P. GELS Expires - July 2006 [Page 21] Solution Decoder and Analysis for GELS Feb 2006 is thus appropriate to make use of these VLAN TAGs and perform VID switching using the same encapsulation than those provided by the DSLAM and the BRAS. Solution 2 is more appropriate for residential services, where the BRAS handle the two VLAN TAGs, which identify the customer. Hence, Solution 2 is more suitable for metro access/metro aggregation networks than Solution 1. 2) Metro-core The metro core is a larger network and its role is to connect several metro access/metro aggregation networks. Both Solutions can be deployed at the metro-core networks. Both provide connection-oriented Ethernet with tunneling mechanisms. The selection of the specific technique that should be deployed should be based on the solution analysis described in this document. 3) Core and Transport networks Same observation as for Metro-core applies. 4.10 Security In both techniques the number of network entry points is reduced. Policing and filtering are provided on the provider edge nodes. Some mechanisms may be provided at the network edges to rate limit the amount of traffic that can be transmitted into a given Ethernet LSP. Solution 1 switches on MAC addresses hence mandating the use of MAC- in-MAC encapsulation to resolve issues associated with MAC addresses. Solution 2 inherently eliminates security issues on MAC addresses (MAC spoofing and MAC attack) because it is agnostic to MAC addresses. Both solutions eliminate security issues associated with VLAN TAGs. At the provider edge, customers are attached to the provider network via particular VLANs on a particular port. Frames with other VLANs will be blocked. Across the network, only the VLAN Identifier(s) added by the provider edge node is/are inspected. Any other nested VLAN has no meaning across the provider network. 5. Conclusion The proposed solutions have been analyzed and compared according to the criteria, which were defined for this purpose. D.P. GELS Expires - July 2006 [Page 22] Solution Decoder and Analysis for GELS Feb 2006 According to the analysis, the solution that better complies to the GELS requirements, as well as better addresses the GELS motivations and objectives should be identifiable. It may be that different solutions have to be selected for example to satisfy different network scenarios or/and different applications. In such a case, a specific label encoding technique should be selected according to the capability of the GMPLS-enabled Ethernet network element and/or the capability of the label-controlled Ethernet interface. Hence, leaving the possibility for adopting different solutions for GELS. It may also be that the solutions complement each other, and for example should be deployed in different network areas. In any case, it is recommended that the GELS define an extensible solution which will leave room for future definitions, especially since the Carrier Grade Ethernet solution is currently under investigation by service providers. Please comment on the mailing list. 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. [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", D.P. GELS Expires - July 2006 [Page 23] Solution Decoder and Analysis for GELS Feb 2006 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 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 Don Fedyk D.P. GELS Expires - July 2006 [Page 24] Solution Decoder and Analysis for GELS Feb 2006 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 D.P. GELS Expires - July 2006 [Page 25] Solution Decoder and Analysis for GELS 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 26]