Network Working Group L. Andersson Internet-Draft Acreo AB Expires: March 20, 2006 D. Papadimitriou Alcatel September 16, 2005 Use of the Gnerealized Multi-Protocol Label Switching control plane for point-to-point Ethernet Label Switching draft-andersson-gels-bof-prep-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. This Internet-Draft will expire on March 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document proposes starting a work within the IETF to apply the Generalized Multi-Protocol Label Switching (GMPLS) control plane to Ethernet Label Switching and to make extensions to the GMPLS control plane protocols as necessary for this application. This will be done based on the protocols developed by the MPLS and CCAMP working groups in the IETF. Ethernet Label Switching will use the data plane Andersson & Papadimitriou Expires March 20, 2006 [Page 1] Internet-Draft Ethernet Label Switching September 2005 encodings as specified by the IEEE 802 standards. This document intends to gather the information necessary to have a "GMPLS Ethernet Label Switching" BoF in Vancouver. 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 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Objectives and scope . . . . . . . . . . . . . . . . . . . . . 6 2.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Out of Scope . . . . . . . . . . . . . . . . . . . . . . . 7 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Core Ethernet . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Ethernet transport . . . . . . . . . . . . . . . . . . . . 9 3.4. Ethernet Label Switching Concepts . . . . . . . . . . . . 10 3.4.1. Modeling concepts . . . . . . . . . . . . . . . . . . 10 3.4.2. Deployment concepts . . . . . . . . . . . . . . . . . 10 3.4.3. Packets and Frames . . . . . . . . . . . . . . . . . . 11 3.4.4. Ethernet Labels . . . . . . . . . . . . . . . . . . . 11 3.4.5. IEEE 802.1Q terminology . . . . . . . . . . . . . . . 14 3.5. Related work in IETF . . . . . . . . . . . . . . . . . . . 15 3.5.1. RFC 3032 (MPLS over Ethernet) . . . . . . . . . . . . 15 3.5.2. RFC 3916 (Ethernet over Pseudo-Wire (PW)) . . . . . . 15 3.5.3. TRILL Approach . . . . . . . . . . . . . . . . . . . . 16 3.5.4. Positioning of Ethernet Label Switching . . . . . . . 16 4. General requirements . . . . . . . . . . . . . . . . . . . . . 19 5. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Data plane requirements . . . . . . . . . . . . . . . . . 20 5.2. Relationship to IEEE 802 . . . . . . . . . . . . . . . . . 20 6. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Control Plane requirements . . . . . . . . . . . . . . . . 22 6.1.1. Link management requirments . . . . . . . . . . . . . 22 6.1.2. Routing requirements . . . . . . . . . . . . . . . . . 22 6.1.3. Signalling requirements . . . . . . . . . . . . . . . 22 6.1.4. Control channel requirements . . . . . . . . . . . . . 22 6.2. Cooperation with CCAMP WG . . . . . . . . . . . . . . . . 22 6.3. Cooperation with other Working Groups . . . . . . . . . . 23 6.3.1. Common review . . . . . . . . . . . . . . . . . . . . 23 6.3.2. Working groups . . . . . . . . . . . . . . . . . . . . 23 Andersson & Papadimitriou Expires March 20, 2006 [Page 2] Internet-Draft Ethernet Label Switching September 2005 6.3.3. Potential overlap with other working groups . . . . . 23 7. Expected outcome . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Milestones . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2. Documents . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2.1. Framework . . . . . . . . . . . . . . . . . . . . . . 25 7.2.2. Routing Extensions . . . . . . . . . . . . . . . . . . 25 7.2.3. Signaling Extensions . . . . . . . . . . . . . . . . . 25 7.2.4. Routing Applicability . . . . . . . . . . . . . . . . 25 7.2.5. Signaling Applicability . . . . . . . . . . . . . . . 25 7.2.6. OAM features . . . . . . . . . . . . . . . . . . . . . 25 7.2.7. Ethernet Label switching MIB . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9.1. Attacks on the Data Plane . . . . . . . . . . . . . . . . 27 9.2. Attacks on the Control Plane . . . . . . . . . . . . . . . 27 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 32 Andersson & Papadimitriou Expires March 20, 2006 [Page 3] Internet-Draft Ethernet Label Switching September 2005 1. Introduction This document proposes that the IETF undertakes a work to extend the existing protocols that constitute the Generalized Multi-Protocol Label Switching (GMPLS) control plane in such a way that this control plane may be used for Ethernet Label Switching. It also proposes that the extension of the GMPLS control plane SHALL be done is such a way that it is possible to create a multi-layer network dynamically controlled by a common control plane. For the scope of this document at least one of the layer must be Ethernet, but a there is nothing that precludes that the same approach is used in non-Ethernet networks. The information collected in this document is intended for an "Ethernet Label Switching" BoF in Vancouver at the 64th IETF. During this BOF we seek consensus for one of two alternatives: 1. that a new working group is started to undertake the work described here or 2. that the work we describe here is allocated to an existing working group The MPLS and CCAMP working groups have defined the use of MPLS and GMPLS protocols for control of several L2 technologies, e.g. ATM and FR, and for circuit-oriented technologies such as SONET/SDH. This has been done by extending the IETF signaling protocols e.g. RSVP-TE and routing protocols e.g. OSPF and IS-IS while their respective data plane has been left unchanged (see e.g. RFC 3946 [RFC3946]). The same approach will be used when extending the GMPLS control plane for Ethernet Label Switching. However, the choice of how to specify an Ethernet label is not as straightforward as for other L2 technologies. There is no designated VPI/VCI information field as in ATM or a DLCI information field as in Frame Relay that we can use. There are however several options that can be considered and need to be compared before taking a decision, e.g. the Q-tag as specified in IEEE 802.1Q, the I-tag that currently is specified in IEEE 802.1ah or if we should go for a new "G-tag" ("GMPLS-tag") especially allocated for Ethernet Label Switching. This is further discussed in Section 3.4.4. Control of Ethernet networks by the control plane technologies as specified in GMPLS RFCs has been within the scope of the CCAMP working group since the start, at least to the extent that Ethernet Andersson & Papadimitriou Expires March 20, 2006 [Page 4] Internet-Draft Ethernet Label Switching September 2005 is used in transport and core networks (see Section 1.2 of [RFC3945]). Part of this discussion was captured in [I-D.papadimitriou-ccamp-gmpls-ethernet-framework]. The work proposed in this document could be viewed both as a consolitdation and a continuation of the work started in [I-D.papadimitriou-ccamp- gmpls-ethernet-framework]. Andersson & Papadimitriou Expires March 20, 2006 [Page 5] Internet-Draft Ethernet Label Switching September 2005 2. Objectives and scope This section outlines the objectives and scope of the proposed work on Ethernet Label Switching. A set of high level requirements are detailed in Section 4, Section 5.1 and Section 6.1. 2.1. Objectives The objectives for the proposed work are listed below. The list is not intended to be exhaustive, but to catch the major objectives. o The key objective of the proposed work is to enable control of point-to-point connectivity through Ethernet networks by the GMPLS control plane as standardized by the IETF. The standards are based on the work done in the CCAMP working group. o It is an objective of the proposed work to contribute to the goal of making it possible to configure and operate multi-layer networks (MLNs). This type of network is called multi-region network (MRN) in [I-D.shiomoto-ccamp-gmpls-mrn-requirements] and [I-D.papadimitriou-ccamp-gmpls-mrn-extensions]. o It is an objective of the work to build on the work done by other working groups within the IETF, in particular, the CCAMP WG. o It is an objective of the proposed work to enable constraint based routing and explicit routing. o It is an objective of the work to build on the work done by other Standards Developing Organizations (SDO), in particular the IEEE 802. o It is an objective of the proposed work to use the structure of the existing encoding of the Ethernet framing, number of bits and size of fields are left unchanged, though the coding of Ethernet label may add new semantics to one or more fields. o It is an objective of the proposed work to achieve interoperabilitiy with legacy Ethernet switches o It is an objective of the proposed work to retain the legacy functionality, e.g. VLANs of Ethernet switches o It is an objective of the proposed work that switches that are GMPLS Ethernet enabled support unlabeled frames Andersson & Papadimitriou Expires March 20, 2006 [Page 6] Internet-Draft Ethernet Label Switching September 2005 2.2. Scope o The scope of the proposed work includes point-to-point (P2P) Ethernet LSPs. o Traffic engineered P2P Ethernet LSPs are within scope for the proposed work. o The scope of the proposed work includes setting up, removing, managing and operating Ethernet LSPs in core and transport networks. o Defining format and value space for Ethernet labels (see Section 7.2) are within scope for the proposed work. Support for more than one label format is discussed in Section 3.4.4 2.3. Out of Scope o GMPLS Ethernet LSPs to the customer premises and/or to hosts are out of scope for the proposed work. o GMPLS Ethernet Label Switching in access networks is out of scope for the proposed work. o GMPLS Ethernet Label Switching in campus networks is out of scope for the proposed work. o GMPLS Ethernet Label Switching in mobile and wireless networks is out of scope for the proposed work. o Multicast and point-to-multipoint LSPs, both Traffic Engineered and non-Traffic Engineered are out of scope for the proposed work. o Changes to the Ethernet data plane are not planned within the proposed work. To the extent such changes are necessary they need to be achieved through the mechanisms and methods defined by the IEEE. Andersson & Papadimitriou Expires March 20, 2006 [Page 7] Internet-Draft Ethernet Label Switching September 2005 3. Description This section includes a brief description of the positioning of Ethernet Label Switching, and its relationship with respect to MPLS and GMPLS. The original MPLS architecture (defined in RFC 3031 [rfc3031] and RFC 3032 [rfc3032]) has been extended in RFC 3945 [rfc3945] to include LSRs whose forwarding plane recognizes neither packet, nor cell boundaries, and therefore, cannot forward data based on the information carried in either packet, or cell headers. Specifically, such LSRs include devices where the switching decision is based on the L2 frame header. Interfaces on these LSRs recognize frame boundaries (i.e. frame delimitation) and can switch data based on the content of the MAC frame header. Such interfaces are referred to as Layer-2 Switch Capable (L2SC) interfaces. The Ethernet MAC frame header includes the EtherType, the different TAGs, and the MAC_DA/SA addresses. In this context, a GMPLS Ethernet labeled frame is defined as an Ethernet MAC frame whose header encodes the label value. Per the GMPLS architecture, a label's interpretation depends on the type of the link over which the label is used. Therefore, GMPLS Ethernet switches need be able to correctly handle all types of Ethernet MAC frames, including the GMPLS labeled frames, to ensure inter-working with 802.1 bridges. An extensive description of label distribution concepts are found in RFC 3036 [rfc3036]. Ethernetlabel assignment , following the GMPLS choicie of signalling protocols RFC 3473 [rfc3473], mandates a downstream-on-demand label allocation and distribution, with ingress initiated ordered control, see RFC 3945 [rfc3945]. 3.1. Scenarios In the CCAMP working a design team was chartered to look into different Ethernet GMPLS scenarios. In the report from the design team [I-D.papadimitriou-ccamp-gmpls-ethernet-framework] four different scenarios were discussed. The four different scenarios addressed the problem space from very separate starting points. While the discussion in this section of what is in and out of scope, stricly only applies to the CCAMP working group charter, we have not indications that the scope will radically change even if we were to take the work to another working group. It is therefore assumed that what is within scope for the CCAMP working group is also within scope for any working group working on GMPLS controlled Ethernet, and vice versa. Scenario 1, GMPLS for access and aggregation networks, were Andersson & Papadimitriou Expires March 20, 2006 [Page 8] Internet-Draft Ethernet Label Switching September 2005 considered to be out of scope. The reason for this is that the scope of the present any work on Ethernet Label Switching needs to follows the guidelines in the CCAMP working group charter i.e. "The CCAMP working group coordinates the work within the IETF defining a common control plane and a separate common measurement plane for physical path and core tunneling technologies of Internet and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation with the MPLS WG." It is not that given access and aggregation networks are are environments where GMPLS controlled label swtiching is suitable. An assessment of GMPLS applicability in access and aggregation networks should be the first step. Once we have this assessment , given that it is positive, a decision if this something IETF wants to undertake could be taken. It is however not within scope for the proposed work. Scenario 2, GMPLS for Metro and Metro Core networks are within scope, but the scenario as described focused on use of the VLAN-id as Ethernet label. For a number of reasons this were considered creating a solution before we've addressed the requirements. The solution proposed in scenario 2 should be revisisted when a solution is discussed, to assess if it is possible and beneficial to use, partly use or accomodate the solution proposed for Metro and Metro core networks in the approach discussed in this document. Scenario 3 and 4 are similar the difference lies more in applicability than requirements. Scenario 3 addresses the case where a common control plane is used for all dynamically controlled network layers, while scenario 4 addresses transport networks only. Scenario 4 might be considered a subset of scenario 3, while scenario 2 could be considered a subset of both or either of scenario 3 and 4. 3.2. Core Ethernet Ethernet Label Switching for core Ethernet aligns closely with scenario 3 as it was describe in the report from the design team [I-D.papadimitriou-ccamp-gmpls-ethernet-framework], i.e. the model with a common control plane (common routing and signaling protocols) for IP (packet), Ethernet (frame) and optical parts of a network. 3.3. Ethernet transport The Ethernet Label Switching for Transport networks aligns closely with scenario 4 as it was describe in the report from the design team [I-D.papadimitriou-ccamp-gmpls-ethernet-framework]. This model is Andersson & Papadimitriou Expires March 20, 2006 [Page 9] Internet-Draft Ethernet Label Switching September 2005 limited to scenarios where the Ethernet LSP is carried over circuits (e.g. SDH/Sonet). 3.4. Ethernet Label Switching Concepts 3.4.1. Modeling concepts When modeling an MPLS network, we talk about two different types of nodes, a Label Edge Router (LER) and a Label Switching Router (LSR) and the links between them. In GMPLS controlled Ethernet networks we might talk about Ethernet LERs and Ethernet LSRs. o Ethernet LER - an Ethernet LER is a function that can take an incoming Ethernet frame and add or remove the Ethernet label. o Ethernet LSR - an Ethernet LSR is a function that can take an incoming labeled Ethernet frame and swap the Ethernet label. A more comprehensive MPLS terminology is found in RFC 3031 [rfc3031]. 3.4.2. Deployment concepts In actual deployments the LER and LSR concepts is not that useful. This is because both function could very well be co-located in the same "box". o A switch could take an incoming un-labeled packet and switch to an interface that is not labeled controlled, i.e. "normal" Ethernet switching. o The switch could also take the incoming frame from a non-labeled controlled interface (or an Ethernet frame that originates within the switch) and switch it to a labeled controlled interface while adding the Ethernet label, i.e. the LER function. o The switch could also take the incoming frame from a labeled controlled interface and switch it to a non-labeled controlled interface while removing the Ethernet label, i.e. the LER function. It is concievable that the non-label control interface is an internal interface within the switch and that the frame is destined to the switch. o The switch could also take the incoming frame from a labeled controlled interface and switch it to a labeled controlled interface while swapping the Ethernet label, i.e. the LSR function. In a deployment an LSP originates on an ingress LSR and terminates on Andersson & Papadimitriou Expires March 20, 2006 [Page 10] Internet-Draft Ethernet Label Switching September 2005 a egress LSR, for point-to-point bi-directional LSPs the same pair LSRs acts both as ingress and egress LSRs. 3.4.3. Packets and Frames Multi-layer GMPLS potentially crosses the border between the IP layer and the Ethernet layer. In both layer information encapsulated (layer specific information added before and/or after the payload) is carried from one node to another. In Ethernet we talk about such entities as "frames" while they are called "packets" in the IP layer. Ethernet Label Switching intends to use a label inserted in the Ethernet encapsulation. Note need to reformulate the last sentence! 3.4.4. Ethernet Labels In this section some of the proposals on how to define an Ethernet label are outlined and discussed. Some of the arguments for and against, though it is unlikely that it is exhaustive list, are given. It is too early to take a decision, but some alternatives has been discussed at some length, e.g. in the L2SC design team and the CCAMP working group. The proposals listed here are possibly not the only proposals, but at least they cover the main ideas that have been discussed. Two key questions that is unresolved is the size of the of the label space, and if we need a TTL or not (in a source initiated ordered label control assignment using a loop detection mechanism such as the RRO a is TTL normally not needed). o use the MPLS shim header This approach makes use of the shim header label as specified in RFC 3032 [rfc3032]. The good thing is that this is proven to work and since we are talking about Ethernet it is always possible to introduce a new label stack between the L3 payload and the Ethernet encapsulation. However this would require the Ethernet switch to swap, push and pop labels as well as re-write source and destination MAC-addresses at each hop. When switching on the shim header this is strictly not GMPLS controlled Ethernet Label Switching, it is the Label Switching as it was defined for the packet part of the network. In this mode of operation the Ethernet frame starts/terminates at each hop, and the destination and source address is changed in each hop. o use the Q-tag and switch on the VLAN ID Andersson & Papadimitriou Expires March 20, 2006 [Page 11] Internet-Draft Ethernet Label Switching September 2005 This approach has been discussed over some time. One argument that have been put forward in favor of this approach is that VLAN ID processing can be handled by "all" Ethernet switches. There are two drawbacks that has been put forward: the label space is relatively small (12 bits) and it makes it impossible to simultaneously use normal VLAN IDs in GMPLS controlled Ethernet Label Switching networks as the semantic of the VLAN ID is modified. From a conceptual point of view a VLAN ID is not something an Ethernet switch takes a switching decision on, what happens is rather that the domain over which the MAC-address learning is done is limited (by definition, a VLAN delimits a broadcast domain). A classical Ethernet switch performs MAC address learning using the unknown unicast frame forwarding. When a frame with an Q-tag/VLAN ID arrives to a switch over an interface with that VLAN configured and the switch doesn't have the destination MAC-address cached, that frame will be forwarded (flooded) over all interfaces with that VLAN configured. When the switch sees traffic in the other direction coming in over one of the interfaces over which the traffic was flooded, the switch learns the combination of source address and interface and places it in the MAC-address cache. As long as the MAC-address remains in the MAC-address cache incoming frame will be forwarded over a single interface only. VLANid is not the switching criteria, but a limitation of the switching domain. The implication is that enabling VLAN ID switching would require disabling MAC learning and MAC_DA based forwarding. o use a proprietary MAC-address space To create unique MAC-addresses the IEEE assigns three bytes OUIs (Organizational Unit Identifier). This OUI can be used to create unique MAC-addresses that can be assigned to equipment manufactured by a vendor. The OUI is used as the first three bytes of the six byte MAC-address. The idea here is that IETF should apply for an OUI and use it to indicate that the rest of the MAC-address is the Ethernet label. The good thing about this proposal is that it leaves a comparatively large space for the label value (three bytes). It is even possible that the label space is large enough to make "label swapping" necessary, if this is the case an estimate of the n-squared problem and the amount of state in the switches. On the negative side is that requires re-writing of source and destination MAC-addresses once the frame enters/leaves the GMPLS controlled Label Switching Ethernet network. If the destination is only modified this leaves asymmetric encoding between the MAC_SA and MAC_DA. It also changes completely processing of this field compared to its current usage. Note also that this encoding Andersson & Papadimitriou Expires March 20, 2006 [Page 12] Internet-Draft Ethernet Label Switching September 2005 is not extensible since based on a fragmentation of an existing information field. There are number of issues that needs to be discussed with this proposal, e.g. introperability with existing switches and with switches that is both GMPLS and non-GMPLS controlled. o use a new TPID (tag protocol identifier) A Q-tag is structured the following way. The first two bytes is a "tag protocol identifier" with the value 0x8100 that indicates a (C-)VLAN tag in the next two bytes including 3 priority bits (Priority Code-Points), a 1-bit Canonical Format Indicator and a 12-bit VLAN id. The idea here is to apply for a new TPID, and use the 13 bits of the last two bytes as a label and keep the 3 priority bits. The label space would be 8192 labels. The strength with this proposals is two-fold. First there is no change in semantic from already existing and defined TAGs. Then, forwarding based on MAC- address or re-writing is not necessary, on the other hand there are certain effects on the Ethernet forwarding plane. Use of the IEEE802.1 Q-tag will apply to IEEE802.1ad switches. In this mode of operation the source and destination MAC-addresses of the MAC frames remain unchanged over the entire length of the Ethernet LSP, the same as for the Ethertype.. o use the I-tag that will be specified in IEEE802.1ah There is currently not enough information available on this, but it is certainly worth investigating since it will give us a label space of 20 bits. 3.4.4.1. Label stack encoding A label stack is defined as an ordered set of labels, this means that for each of the proposed solution here above a "label stacking" method could be defined: o when using the Q-tag and switch on the VLAN ID: techniques for nesting Q-tags ("Q-in-Q") will work for the Ethernet Labels make a two-level label stacking possible o when using the new TPID a similar method could be considered with a larger flexibility in terms of number of levels o when using MAC-address space a two level stack of labels could be considered in analogy to the MAC-in-MAC approach currently under development by the IEEE (802.1ah) Andersson & Papadimitriou Expires March 20, 2006 [Page 13] Internet-Draft Ethernet Label Switching September 2005 However, the need of several entries in the label stack is still an open issue for GMPLS controlled Ethernet Label Switching. Also, the number of aggregation levels such environment would have to support (i.e. nesting) is also a related open discussion point. 3.4.5. IEEE 802.1Q terminology Below the terminology related to IEEE 802.1Q is oulined, e.g. naming of the different fields and sub-fields. TAG Format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCI | TPID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IEEE 802.1 Q-tag format Figure 1 TPID (16 bits): TAG Protocol Identification TCI (16 bits): TAG Control Information For C-VLAN TAG Control Information (TCI): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VID |C| PCP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C-VLAN TAG Control Information Figure 2 PCP (3 bits): Priority Code Point conveying priority & drop_eligibility C (1 bit): Canonical Format Indicator (CFI) VID (12 bits): VLAN Identifier For S-VLAN TAG Control Information (TCI): Andersson & Papadimitriou Expires March 20, 2006 [Page 14] Internet-Draft Ethernet Label Switching September 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VID |D| PCP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S-VLAN TAG Control Information Figure 3 PCP (3 bits): Priority Code Point conveying priority & drop_eligibility parameters D (1 bits): Drop Eligible Indicator (DEI) bit VID (12 bits): VLAN Identitifer 3.5. Related work in IETF GMPLS control of Ethernet switches (as described in this document) is based on the Ethernet MAC frame header. The difference with other approaches currently worked in the context of other IETF working groups are briefly described in the following paragraphs. 3.5.1. RFC 3032 (MPLS over Ethernet) The difference between GMPLS control of Ethernet switches (as described in this document) and MPLS transport over Ethernet links as described in [RFC3032] is that in the latter packets are labeled using MPLS shim headers. Labeled packets are then encapsulated in Ethernet frames and targeted at the next IP/MPLS LSR along the path of the LSP. At the incoming LSR interface, the Ethernet header is stripped and forwarding takes place based on the encapsulated MPLS label. At each hop, forwarding operation of native L3 packets is done using labels and consists in looking up an incoming label to determine the outgoing label, encapsulation, port, and other data handling information. When the Ethernet header is stripped of it also implies that a new Ethernet header has to be created to carry the packet between each MPLS hop. It should also be noted that one hop on an MPLS LSP could correspond to several hops through the Ethernet network. 3.5.2. RFC 3916 (Ethernet over Pseudo-Wire (PW)) In [RFC3916], Ethernet frames are encapsulated and transported over a packet-switched network using PSN tunnels (e.g. IP or MPLS tunnels). Therefore, the forwarding is based on packet headers. In single segment PW, the PW label is used a mux/demux label and does not enter into forwarding at intermediate LSRs through which the PSN Andersson & Papadimitriou Expires March 20, 2006 [Page 15] Internet-Draft Ethernet Label Switching September 2005 tunnel is established. For multi-segment PW, the PW label is inserted at the PE originating the PW i.e. the source PE, and is switched at each intermediate PE until it reaches the PE terminating the MS-PW, i.e. the destination PE. By definition, a PW starts and ends on a PE, comparatively the Ethernet Label Switching solution is meant to run in soft-permanent mode (i.e. between PEs) but also in a switched mode i.e. between CEs. An Ethernet pseudowire is indistinguishable from a point-to-point Ethernet link, the fact MPLS is one of the techniques that is used to implement PWs is of no consequence for the work on GMPLS controlled Ethernet Label Switching, the Ethernet PWs are listed for reference purposes only. 3.5.3. TRILL Approach The TRILL working group has been recently formed to address the shortages of Ethernet networks using the spanning tree protocol. As such, the TRILL WG is intended to deliver a solution to this problem for "CAMPUS" networks (even if its scope could be larger) by defining an "intermediate" technology between IP and Ethernet MAC layer to circumvent the drawbacks of the latter (in particular wrt to 802.1d and related). A specific difference compared to the TRILL WG is that the latter has been chartered to provide a solution without explicitly being able to run on existing IP routers as a software upgrade. On the other hand, it is expected that a GMPLS capable LSR (acting as Ethernet LER) would be able to initiate/terminate Ethernet LSPs across an Ethernet LSR network. A further difference between TRILL, at least as it is currently chartered, is that TRILL aims for shortest-path routing of frames (connectionless) in multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary topologies while GMPLS controlled Ethernet Label Switching aims for constraint based routing and explicit routing. 3.5.4. Positioning of Ethernet Label Switching The positioning of the present approach compared to the approaches detailed in the present section depicted in the following figure: Andersson & Papadimitriou Expires March 20, 2006 [Page 16] Internet-Draft Ethernet Label Switching September 2005 +--------------+ +---------------+ +---------------+ | Payload | | Payload | | Payload | +--------------+ +---------------+ +---------------+ | Ethernet MAC | | MPLS Label | | TRILL header | -------------- --------------- --------------- | PW Label | | Ethernet MAC | | Ethernet MAC | -------------- --------------- --------------- | PSN Tunnel | | PHY | | PHY | +--------------+ +---------------+ +---------------+ PW Approach MPLS Approach TRILL Approach +---------------+ | Payload | --------------- | Ethernet MAC | --------------- | PHY | +---------------+ ELS Approach Ethernet Label Switching in context Figure 4 Compared to other approaches, Ethernet Label Switching provides an integrated label encoding as part of the Ethernet MAC frame header. No introduction of additional switching layer or forwarding layer is considered. Compared to the PW approach however, Ethernet label switching is positioned as a tunneling technology. This observation becomes even more important when considering Ethernet LSR interfacing classical Ethernet environment i.e. in order to avoid supporting complex interaction(s) between IEEE 802.1 protocols at Ethernet LERs the latter are expected to behave transparently. This means that Ethernet IEEE 802.1 control frames are processed as any other user frame. On the other hand, the Ethernet Label switching approach provides a simple mean for extending the Ethernet data plane capabilities with the "well accepted" carried functionalities such as automated provisioning, traffic-engineering, QoS parameter signaling, differentiated routing and re-routing. It has to be emphasized that the major difference between the TRILL approach is that the data Andersson & Papadimitriou Expires March 20, 2006 [Page 17] Internet-Draft Ethernet Label Switching September 2005 plane functionality is only enhanced such as to provide a "label switching" behavior, all other capabilities are inherited from the use of the associated GMPLS control plane. Another remarkable property of the Ethernet label switching is that it is able to work in both Switched (i.e. equivalent to ATM SVC mode) and Soft-permanent mode (i.e. equivalent to ATM SPVC mode). Compared to the other approaches only the MPLS one is able to deliver a similar behavior between routers (or more generally when the labeled packets carry a L3 payload). All other approaches are meant to work on SPVC mode only i.e. between PEs (or their equivalent). As such the Ethernet label switching capability would be gradually deployable by first considering SPVC network capability and further consider extension of the GMPLS control plane deployment on CEs. In brief, the Ethernet label switching approach can be seen as a way to position Ethernet as a carrier-grade tunneling technology without modifying the relationship with the carried payload or the layers over which Ethernet payload can be transported. Andersson & Papadimitriou Expires March 20, 2006 [Page 18] Internet-Draft Ethernet Label Switching September 2005 4. General requirements 1. For Ethernet Label Switching it SHALL be possible to use traffic engineering methods defined for MPLS and GMPLS. 2. For Ethernet Label Switching it SHALL be possible to use recovery methods defined for MPLS and GMPLS. 3. GMPLS is based on the IP routing and addressing models, in part. IPv4 and/or IPv6 addresses are used to identify L2SC interfaces. As it is not viable to associate an IP address with each end of each L2SC interface, GMPLS scalability enhancement to addressing must be re-usable: unnumbered links and link bundling. 4. GMPLS control plane information exchange between adjacent Ethernet LSRs and control plane information processing MUST be independent of the control channel implementation. 5. Control plane resilience mechanisms defined for GMPLS control plane (e.g. RSVP engine graceful restart) SHALL be re-usable for Ethernet LSR Andersson & Papadimitriou Expires March 20, 2006 [Page 19] Internet-Draft Ethernet Label Switching September 2005 5. Data plane Note: This section should include a discussion of the relevant Ethernet standards, at least IEEE 802.1Q, 802.1p, 802.1ad and 802.1ah. Note: It also should include a discussion of the any data plane issues within scope. 5.1. Data plane requirements 1. In current IEEE 802.1Q networks it is possible to create Virtual LANs, by adding a VLAN-id to the Ethernet frame. The effect of the VLAN-id is that the scope of the broadcast domain will be limited and broadcast frames will only be sent to a subset of the hosts connected to the network. This functionality MUST remain unchanged when the GMPLS control plane is introduced. 2. The Ethernet MAC frame structure must be left unchanged i.e. composed by Ethernet MAC frame header; a Payload and an FCS. The former must remain structured such as to include the MAC_DA, MAC_SA one or more TAGs and the EtherType. Ethernet TAG must still include a TPID (TAG Protocol ID) and a TCI (TAG Control Information). 802.1Q and 802.1ad include as part of the former an Ethertype value. 3. It is assumed that the current physical medium (known as Ethernet PHY) over which Ethernet labeled frames could be transmitted are left unchanged and be forward compatible with the 802.3 specifications. 4. The MAC address space, size (6 bytes), format and semantic are left unchanged and must still support unicast, multicast and broadcast format and semantic. 5. The proposed Ethernet label format and switching must be such as to leave IEEE 802.1ag CFM operations independent 6. MTU size: the size of the Ethernet labeled frame falls into the revision of the IEEE P802.3as Ethernet Frame Expansion. 7. Note: Do we need to add further requirements? 5.2. Relationship to IEEE 802 The relationship between other SDOs and the IETF is managed by the Internet Architecture Board (IAB). There is a long-standing liaison relationship between the IETF and the IEEE 802. The proposed work Andersson & Papadimitriou Expires March 20, 2006 [Page 20] Internet-Draft Ethernet Label Switching September 2005 will leverage this relationship. However, it might be necessary to form even closer cooperation in this area. We don't see that this needs to take the form of establishing a new formal liaison relationship between the two organizations, but could very well be managed as part of the existing relationship. Note: The IETF liaison to the IEEE is Bernard Aboba, and we will bring the issues around the IETF/IEEE relationship and the proposed work to him and discuss whether it is necessary to appoint further people to work with the liaison relationship. If and when the IETF undertake the proposed work, we will need to coordinate closely with some of the IEEE 802.1 projects, especially 802.1ad and 802.1ah. The preliminary and informal contacts taken so far are very promising. Note: We had a very short discussion with Paul Condon (chairman of the 802.1) and he indicated that the necessary channels are available. Note: IEEE liaison (suggested Bernard Adoba) Andersson & Papadimitriou Expires March 20, 2006 [Page 21] Internet-Draft Ethernet Label Switching September 2005 6. Control Plane - 6.1. Control Plane requirements Note: This section is for further study. 6.1.1. Link management requirments Note: For further study 6.1.2. Routing requirements Note: For further study 6.1.3. Signalling requirements Note: For further study 6.1.4. Control channel requirements Note: For further study 6.2. Cooperation with CCAMP WG Note: Cooperation with CCAMP (suggested Kireeti and Adrian) The IETF Common Control and Measurement Plane (CCAMP) working group coordinates the work within the IETF for defining a common control plane and a measurement plane for ISP and SP core tunneling technologies. This includes, but is not limited to, defining signaling protocols and measurement protocols such that they support multiple physical path and tunnel technologies using input from technology- specific working groups such as the MPLS working group; protocol-independent metrics and parameters for describing links and paths that can be carried in protocols. The CCAMP Working group addresses, among others, a generalized technology, referred to as GMPLS, where labels are defined in such a way that they will be compatible with the technology they are transported over. The CCAMP working group work focuses on common methods across a broad spectrum of switching technologies. Base GMPLS signaling (RFC 3471 [rfc3471] and RFC 3473 [rfc3473]) and routing ([I-D.ietf-ccamp-gmpls-routing], and [I-D.ietf-ccamp-ospf- gmpls-extensions]) are output of the CCAMP WG. [I-D.ietf-isis-gmpls- extensions] is the product of the IS-IS Working Group. Documents that propose extensions or changes to protocols that have been Andersson & Papadimitriou Expires March 20, 2006 [Page 22] Internet-Draft Ethernet Label Switching September 2005 specified by the CCAMP working group, e.g., documents that specify new GMPLS methods or extensions and new GMPLS encapsulations MUST be handled by the CCAMP working group. One exception to this rule is when other IETF working group has been appointed, with the prerequisite CCAMP WG agreement, to handle extensions and/or changes to the protocols specified by the CCAMP working group. The present work falls into this category. This implies that any GMPLS protocol extension, or enhancement proposed in the context of this item must be revisited by the by the CCAMP WG such that the appropriate level of technical review is ensured. To avoid extra delays and ensure right level of collaboration the review process must be conducted earlier before WG Last Call process. 6.3. Cooperation with other Working Groups 6.3.1. Common review Cooperation with other working groups, in particular protocol- specific WG (e.g. IS-IS or OSPF) MUST involve the same review process. This implies that any protocol extension, or enhancement proposed in the context of this work item must be revisited by the protocol-specific WGs such that the appropriate level of technical review is ensured. To avoid extra delays and ensure right level of collaboration the review process must be conducted earlier before WG Last Call process. 6.3.2. Working groups Cooperation is foreseen with the following Working Groups (in addition to the CCAMP WG): OSPF WG, IS-IS WG, MPLS WG and TRILL WG. Note: The specific list of working groups we need to co-ordinate and co-operate with needs to be finalized. 6.3.3. Potential overlap with other working groups Note: This section is for further study. Potentially the we that we need to discuss the relationship with TRILL further. Andersson & Papadimitriou Expires March 20, 2006 [Page 23] Internet-Draft Ethernet Label Switching September 2005 7. Expected outcome - 7.1. Milestones Milestones are obviously related to progressing documents, we list the set of documents we think is necessary for completion of the proposed work see Section 3.4.4. o milestone 0 - decision on the Ethernet label(s) format o milestone 1 (possibly the Framework draft as working group document Section 7.2.1) o milestone 2 (possibly the Signaling and Routing Extensions drafts as working ggroup documents Section 7.2.3 and Section 7.2.2) o milestone 3 (possibly the Framework draft sent to the IESG to be published as an informational RFC, Section 7.2.1). o milestone 4 (possibly OAM features and MIB drafts as working group document Section Section 7.2.6 and Section Section 7.2.7). o milestone 5 (possibly the Signaling and Routing Applicability drafts as wg documents Section Section 7.2.5 and Section Section 7.2.4) o milestone 6 (possibly the Signaling and Routing Extensions drafts sent to IESG to be published as PS RFC) o milestone 7 (possibly OAM features and MIB drafts sent to IESG to be published as PS RFC) o milestone 8 (possibly the Signaling and Routing Applicability drafts sent to the IESG to be published as an informational RFC,) Note: Dimitri is working on a first cut of the charter. 7.2. Documents This section list documents that we believe should be included in the output from the proposed work. The documents are listed here tentatively, as the work progresses it might turn out that we want to re-arrange the content between the documents, merge or split documents. Andersson & Papadimitriou Expires March 20, 2006 [Page 24] Internet-Draft Ethernet Label Switching September 2005 7.2.1. Framework Note: Framework (incl. data plane aspects) The framework is intended to capture terminology, architechture and requirements for GMPLS controlled Ethernet Label Switching. The framework will also be the place where the format of the Ethernet label(s) will be documented. 7.2.2. Routing Extensions Note: Routing extensions 7.2.3. Signaling Extensions Note: Signaling extensions 7.2.4. Routing Applicability Note: Routing applicability 7.2.5. Signaling Applicability Note: Signaling applicability 7.2.6. OAM features Note: OAM features 7.2.7. Ethernet Label switching MIB Note: Ethernet Label Switching MIB Andersson & Papadimitriou Expires March 20, 2006 [Page 25] Internet-Draft Ethernet Label Switching September 2005 8. IANA Considerations Note: This section placed here tentatively. Andersson & Papadimitriou Expires March 20, 2006 [Page 26] Internet-Draft Ethernet Label Switching September 2005 9. Security Considerations The BOF preparation document does not in itself add any new security aspects to the Internet. However, below we list that reflects our current understanding of the security aspects we would have to consider if we were to undertake the proposed work. The document raises similar security issues such as with any other type of LSPs. However, additional security threats have been identified: o Possibility for the network to control the traffic injected by the client in the data plane (BPDU, Multicast, Broadcasts, etc.) o Entry points induced by the possible coexistence of the two technologies (L2LSPs and usual Broadcast Ethernet mode) 9.1. Attacks on the Data Plane Attacks on the data plane can be of the following form: o modification of data traffic o insertion of non-authentic data traffic o Denial of Service (DoS) attacks o traffic snooping Introduction of GMPLS signaling fro Ethernet LSP MUST prevent these attacks. Moreover, as an Ethernet LSP is by nature a point-to-point tunnel, with a single entry point (head-end LSR) and exit point (tail-end LSR). Policing (rate limit) and filtering is required only on the head-end LSR. 9.2. Attacks on the Control Plane 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. Existing RSVP security mechanisms RFC 2207 [RFC2207] and RFC 3097 [RFC3097] should also be analyzed/ evaluated in this context. Andersson & Papadimitriou Expires March 20, 2006 [Page 27] Internet-Draft Ethernet Label Switching September 2005 10. Acknowledgements We would like to thank the CCAMP working group L2SC design team, which joine3d the discussion on GMPLS controlled Ethernet Label Switching with great enthusiasm. We would also like to thanks Adrian Farrel for insightful major technical comments and extensive nit-picking. Andersson & Papadimitriou Expires March 20, 2006 [Page 28] Internet-Draft Ethernet Label Switching September 2005 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [I-D.ietf-ccamp-gmpls-routing] Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp-gmpls-routing-09 (work in progress), October 2003. [I-D.ietf-ccamp-ospf-gmpls-extensions] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp-ospf-gmpls-extensions-12 (work in progress), October 2003. [I-D.ietf-isis-gmpls-extensions] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls-extensions-19 (work in progress), October 2003. [I-D.papadimitriou-ccamp-gmpls-ethernet-framework] Papadimitriou, D. and J. Choi, "A Framework for Generalized MPLS (GMPLS) Ethernet", draft-papadimitriou-ccamp-gmpls-ethernet-framework-00 (work in progress), July 2005. [I-D.papadimitriou-ccamp-gmpls-mrn-extensions] Papadimitriou, D., "Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Region Networks (MRN)", draft-papadimitriou-ccamp-gmpls-mrn-extensions-01 (work in progress), February 2005. [RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. Andersson & Papadimitriou Expires March 20, 2006 [Page 29] Internet-Draft Ethernet Label Switching September 2005 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001. [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001. [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. [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC3946] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004. Andersson & Papadimitriou Expires March 20, 2006 [Page 30] Internet-Draft Ethernet Label Switching September 2005 Authors' Addresses Loa Andersson Acreo AB Email: loa@pi.se Dimitri Papadimitriou Alcatel Email: dpapadimitriou@psg.com Andersson & Papadimitriou Expires March 20, 2006 [Page 31] Internet-Draft Ethernet Label Switching September 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Andersson & Papadimitriou Expires March 20, 2006 [Page 32]