Dae Young Kim Internet Draft CNU Expires: July 2006 Jaihyung Cho ETRI January 2006 Label Switching Ethernet (LSE) Architecture draft-jaihyung-lse-architecture-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 April, 2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. J.Cho, et.al. Expires - July 2006 [Page 1] Label Switching Ethernet Architecture July 2006 Abstract A solution for GMPLS implementation using 48bits of Ethernet multicast address as label is proposed. It is claimed that Ethernet bridges supporting IEEE 802.1D-2004 and IEEE 802.1Q-2003 may implement GMPLS according to this proposal without requiring modification to data plane, hence this solution is an appropriate candidate solution for GELS (GMPLS Ethernet Label Switching) group. The LSP established in this method is intrinsically bi-directional. Ethernet bridges of this implementation provide traffic engineered frame delivery path. Any point-to-point LSP can be transformed to multi-point LSP, and vice versa. It is interoperable with 802.1D/Q bridges. This proposal allows automated setup of VLAN using GMPLS in small scale network. IEEE 802.1 controlled spanning tree path may co- exist with GMPLS controlled LSP path when VLAN is used for segregating GMPLS flows and normal Ethernet flows. Clear advantage of this proposal compared to all-router based backbone network is cost- effectiveness that it helps reducing CAPEX/OPEX of operators. With the aid of well-established IP technology, it also helps enhancing scalability and manageability of bridged backbone network. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................4 3. GMPLS Label Format.............................................4 4. GMPLS Bridge Model.............................................6 5. GMPLS Implementation Models....................................7 5.1. IP Service in Bridged Core Network....................... 8 5.2. Coexistence with Spanning Tree and Ethernet Service...... 9 5.3. MAC-in-MAC Tunnel Service............................... 9 5.4. Interoperation with GMPLS unaware bridges.............. 10 6. Inter-domain Extension and Future Work..................... 12 Security Considerations..........................................13 References.......................................................13 Author's Addresses...............................................14 J.Cho, et.al. Expires - July 2006 [Page 2] Label Switching Ethernet Architecture July 2006 1. Introduction GMPLS control over Ethernet as specified in GMPLS RFCs has been identified within the scope of the CCAMP working group. GELS (GMPLS Ethernet Label Switching) group has been proposed in this initiative to find best approach for GMPLS implementation over IEEE bridges. A strong requirement raised in the group is that any potential proposal must not assume modification of Ethernet data plane for this implementation, other than currently defined or pledged to be supported in IEEE. This document is a revision to original proposal of LSE (Label Switching Ethernet) architecture to meet the requirement. Main objective of this solution is to configure 48bits of MAC addresses in Filtering Database (FDB) using GMPLS in order to provide scalable TE path. However, this proposal also doesn't preclude use of GMPLS for configuring VLAN in limited scale of network. In order to achieve this, this proposal utilizes Extended Filtering Service defined in IEEE 802.1D-2004 [IEEE8021D], and Enhanced Internal Sublayer Service (EISS) defined in 802.1Q-2003 [IEEE8021Q]. It is allowed in [IEEE8021D] that group forwarding entry (i.e. Ethernet multicast address) can be configured either through management control or using GMRP (GARP Multicast Registration Protocol). In IEEE term, when multicast address is configured using management primitives, it is called static filtering entry. If the multicast address is configured by GMRP using control primitives, it is called dynamic group registration entry. Both types of entries are not subject to MAC learning or aging timer that once the address is configured in FDB, the frame forwarding path is fixed unless the node fails. Using this group forwarding behavior, GMPLS control entity may configure point-to-point or multi-point LSP over 802.1D network. Other useful feature defined in [IEEE8021D] is default filtering behavior of unknown group address. When it is enabled, any reception of unregistered multicast frames will be silently discarded. This behavior is very useful in preventing looping or flooding of unknown Ethernet frames. Note that Ethernet bridges usually broadcast data frames via spanning tree when the destination address is unknown. Since GMPLS may disable spanning tree or open all ports as forwarding state in order to provide shortest path via any port, broadcasting behavior of unknown frame may cause fatal result. However, when multicast address is used in destination address field, this risk can be reduced because bridges will discard unknown multicast frames. Hence it is safer for GMPLS to control multicast Ethernet frames rather than unicast Ethernet frames. Further, [IEEE8021D] defines several useful tools for controlling multicast traffic, such as selective permission or blocking of group addresses, that it will J.Cho, et.al. Expires - July 2006 [Page 3] Label Switching Ethernet Architecture July 2006 facilitate future extension of GMPLS implementation to multi-point Ethernet service. The other good reason to use multicast address for GMPLS label is that point-to-point LSP may seamlessly be converted to multi-point LSP or vice versa, because the LSP is inherently a multicast forwarding path. It only requires some port map manipulation of the group forwarding entry in FDB to transform point-to-point path to multipoint path. For these reasons, this proposal utilizes group forwarding behavior of Extended Filtering Service defined in IEEE 802.1D-2004 edition for GMPLS implementation. 2. 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]. 3. GMPLS Label Format Figure 1 below shows the proposed format of Ethernet multicast address when GMPLS label is encoded. According to IEEE 802 standard [IEEE802], 48bits of LAN MAC address consists of upper 24bits of OUI (Organizationally Unique Identifiers) field and lower 24bits of remaining part. IEEE allows individual organization generating LAN MAC address using lower 24 bits of address block when unique OUI code is obtained from IEEE. This allows exclusive use of approximately 16 million addresses for each organization. Using the addressing scheme, GMPLS may secure 24bits size of label space when an OUI number is reserved from IEEE for this protocol. This allows approximately 16 million LSPs established per administrative domain when the label is used globally in an intra- domain. When several more OUI numbers are reserved for GMPLS, the size of label space doubles. All Ethernet frames controlled by GMPLS will have identical OUI number that they can easily be classified from other Ethernet frames. In order to apply default group filtering behavior to GMPLS frames, this proposal recommends use of group prefixed OUI number for GMPLS. In IEEE address format [IEEE802], the last bit setting of the first octet in OUI number indicates that the address type is group multicast. J.Cho, et.al. Expires - July 2006 [Page 4] Label Switching Ethernet Architecture July 2006 +-------+-------+-------+-------+-------+-------+ | 1byte | 2byte | 3byte | 4byte | 5byte | 6byte | +-------+-------+-------+-------+-------+-------+ +-----------------------+-----------------------+ | OUI Prefix (=GMPLS) | DA-label (24bit) | +-----------------------+-----------------------+ | OUI Prefix (=GMPLS) | SA-label (24bit) | +---------------+-------+-----------------------+ | Length/Type | | +---------------+ | | | | Payload | | | +-----------------------------------------------+ | FCS | +-----------------------------------------------+ Figure 1. GMPLS Frame Format The GMPLS frame header shown in Figure 1 contains two group addresses, DA-label and SA-label. The DA-label is used for forwarding the frame, and the SA-label indicates LSP of backward direction. Since GMPLS supports bi-directional LSP [RFC3945], this proposal recommends inclusion of backward label in all frame header. It also aligns with semantics of Ethernet header. In future extension, the information of backward LSP may be used for sending OAM message back to ingress node when corresponding data plane entity for OAM is developed in IEEE. Use of Ethertype code or VLAN tag is orthogonal in this proposal. However when VLAN tag is attached to GMPLS prefixed frames, GMPLS controlled traffic can be separate from normal Ethernet traffic in underlying port level. This allows IEEE 802.1 spanning tree path coexists with GMPLS controlled LSP path as long as VLAN number is distinguished. This means GMPLS control entity may coexist with IEEE 802.1 control entities in control plane that bridges may provide connection oriented service using LSP, as well as connectionless service using IEEE spanning tree path. It is also noted that QoS policy can be enforced in granularity of LSP when priority tag is attached to GMPLS frames. J.Cho, et.al. Expires - July 2006 [Page 5] Label Switching Ethernet Architecture July 2006 4. GMPLS Bridge Model Figure 2 below shows a bridge model of GMPLS implementation when 802.1D/Q bridge is assumed. However, this proposal doesn't restrict the underlying hardware model that other types of data plane switch, such as IEEE 802.1ah, may also be applied. In this bridge model, GMPLS control entity can be colocated with 802.1 bridge control entities and bridge management entity. The underlying data plane switch provides necessary service primitives for configuring Filtering Database (FDB) and port state. 802.1 bridge control entities and GMPLS control entity may share resources in data plane, or GMPLS may disable 802.1 control and exclusively use the resources. When GMPLS exclusively controls bridge, all bridge ports must be open in forwarding state except administratively disabled port. As a result, IP routing protocol in control plane advertises all available links, and LSP can be established through any optimum port. Care must be taken that no unicast frame infiltrate into the network, because it may cause infinite duplication and flooding of the unknown frame. Only the group prefixed GMPLS frames must flow in the network. All GMPLS implemented bridges must set default group filtering behavior, thus any reception of unregistered multicast frame must be discarded. When GMPLS coexists with 802.1 bridge control entities, a VLAN ID must be allocated for GMPLS in order to separate GMPLS traffic from spanning tree traffic. Forwarding state of the VLAN chosen for GMPLS must be configured in all ports except administratively disabled port. Default group filtering behavior of the VLAN tagged frames should also be configured. Only the VLAN tagged multicast frames should be admitted for GMPLS service. Other VLANs can be used according to IEEE 802.1 protocols. Both types of multicast/unicast frames are allowed in such VLAN. J.Cho, et.al. Expires - July 2006 [Page 6] Label Switched Ethernet Architecture July 2006 +-----------------------------------------+ | Bridge Control & IP Forwarding Layer | | | | +-------+ +-------+ +-------+ | | | 802.1 | | GMPLS | |Routing| | | +-------+ +-------+ +-------+ | | | FDB & Port | | v Setup | +---+-----------+---------+-----------+---+ | | \ L2 / | | | | EISS(VLAN) \Relay/ EISS(VLAN) | | | +--------------+---+--------------+ | | | | | | MAC Dependant | | MAC Dependant | +------------------+ +------------------+ || || || || -------------------+ +------------------- LAN | | LAN -------------------+ +------------------- Figure 2. GMPLS Bridge Architecture 5. GMPLS Implementation Models 5.1 IP Service in Bridged Core Network Figure 3 below illustrates an IP service model where core nodes consist of homogeneous 802.1D/Q bridges. It is assumed the edge routers (R1 and R2) provide IP service to external users, and the Ethernet interfaces facing backbone are capable of promiscuous reception of multicast Ethernet frames. GMPLS control entities exist in both edge routers and core bridges, and distribute label information (i.e. multicast MAC addresses) between them. The edge routers and core bridges share common pool of label space (i.e. multicast address block reserved for GMPLS) in the administrative domain. In other words, a multicast address assigned for an LSP is used globally in the intra-domain that once it is occupied by an edge node, no other nodes in the network may use the number until the edge node releases the number. This requires global coordination of label allocation. There can be several methods for global control of label use, such as dividing the 16 million multicast addresses and pre-allocating to each edge node, or running a centralized address allocation server. Detail of label allocation scheme is beyond the scope of this document. J.Cho, et.al. Expires - July 2006 [Page 7] Label Switched Ethernet Architecture July 2006 | | Edge Router | <........ Core Network ..........> | Edge Router R1 | | R2 +------+ +------+ | IP | S1 | IP | +------+ +------+ +------+ | L2SC | | L2SC | | L2SC | +-+--+-+ +-+--+-+ +-+--+-+ | |(s1) L2-LSP | | L2-LSP (d1) | | -------->| |==============>| |==============>| |-------> [Data][IP] [Data][IP][s1:d1] [Data][IP][s1:d1] [Data][IP] Figure 3. GMPLS Controlled Bridge Network An example for establishing a point-to-point multicast path (i.e. unicast LSP in view of control plane) is explained using the figure 3. In the figure, an egress edge router R2 allocates a multicast address d1 (i.e. downstream label) for a FEC (Forwarding Equivalence Class). A multicast reception state of the address d1 must be configured in the interface of R2. The mapping information of the multicast address and the FEC is distributed using RSVP-TE. Intermediate core bridge S1 reserves resources necessary for the LSP and configures multicast forwarding entry of the address d1, hence establishes a multicast path of R1->R2 direction. The ingress edge router R1 also allocates a multicast address s1 for backward LSP and configures a multicast reception state in the Ethernet interface. The upstream label s1 also need to be distributed to S1 and R2, as a result, bi-directional multicast path is established between R1 and R2. Detail of the signaling procedure is out of the scope of this document. When the ingress edge router R1 receives a data packet belong to the FEC, R1 encapsulates the packet in an Ethernet frame of which destination address is d1, and source address is s1. R1 forwards the composed multicast frame via the established LSP, and the frame is delivered to R2. Since R2 configured the multicast address d1 in the input interface, R2 receives the frame and strips off the Ethernet header and forwards the packet to the output interface. No label swapping operation is necessary in intermediate nodes in intra-domain application. It also does not require using VLAN when the service model of the network is IP only. J.Cho, et.al. Expires - July 2006 [Page 8] Label Switched Ethernet Architecture July 2006 5.2 Coexistence with Spanning Tree and Ethernet Service In this multi-service model, a bridged core network may provide both IP service using edge routers, as well as Ethernet connectivity service as specified in IEEE 802.1D/Q, when a VLAN is used for separating edge router group from Ethernet servicing edges. The edge router group that share common bridged core network must transmit/receive frames tagged with the VLAN chosen for GMPLS. Intermediate nodes must configure forwarding state of the VLAN in all ports, as a result, LSPs can be established via any shortest path available in the network. Filtering state of the VLAN must be configured on the ports servicing external Ethernet user that no unicast frame or bogus frame may infiltrate into the VLAN group. Except the VLAN ID allocated for GMPLS, rest of 4093 VLANs can be used for providing Ethernet access service in the bridged core network. Those VLANs can be configured manually or using IEEE protocols. This document doesn't preclude use of GMPLS for automated setup of VLAN. When GMPLS is used for configuring VLAN, this may reduce operational burden. However, a serious limitation of this method is the size of VLAN ID (12bits) that it allows at most 4093 number of VLANs to be established in an administrative domain. This is far short scale compared to 16 million label space available when using MAC address for label. While doubling the VLAN size as seen in IEEE 802.1ad may enhance the scalability, it still has limitation of service-VLAN that maximum number of customers supported in a provider domain is 4094 when customer use of their own VLAN is to be supported [IEEE8021AD]. 5.3 MAC-in-MAC Tunnel Service For the scalability reason discussed in section 4.2, this document supports use of MAC-in-MAC encapsulation tunnel for Ethernet service. Edge bridges of this capability encapsulate customer frames using provider provisioned backbone MAC header. This is similar concept as edge router encapsulating IP packet in GMPLS prefixed frame, explained in section 4.1, except that the payload is now customer MAC frame. Once a customer MAC frame is encapsulated by provider MAC frame, the frame is forwarded using the provider MAC header while progressing in the core network. The provider MAC header is stripped off at egress edge bridge of the MAC-in-MAC tunnel. Currently this concept of MAC-in-MAC tunnel service is being defined in IEEE 802.1ah (Provider Backbone Bridge), although the document doesn't specifically refer use of multicast address for backbone MAC header. The MAC-in-MAC tunnel can be controlled by GMPLS when GMPLS J.Cho, et.al. Expires - July 2006 [Page 9] Label Switched Ethernet Architecture July 2006 is used for delivering edge information between 802.1ah bridges, such as B-MAC information. The proposed MAC-in-MAC tunnel shows some appropriate characteristics in servicing Ethernet user. For example, compared to the scale limitation of VLAN, this approach allows up to 16 million MAC-in-MAC tunnels being established in an administrative domain, when a block of 24bit multicast addresses is reserved for the tunnel address. In fact, there is no limitation of the number of tunnels when any private MAC address is allowed for the tunnel address. The termination point of MAC-in-MAC tunnel service can be an internal port of edge bridge, an external port, or even an abstract port. When an external port servicing an Ethernet customer is the demarcation point of MAC-in-MAC service, the customer is free to define their own VLANs up to the limit of VLAN scale. Multiple MAC-in-MAC tunnels may also be provided for each VLANs at a port. 5.4 Interoperation with GMPLS unaware bridges While the IP service model presented in section 4.1 assumes homogeneous deployment of GMPLS for convenience of description, this proposal does not mandate GMPLS being deployed in all core nodes to initiate operation. GMPLS unaware bridges may coexist in the network and participate in delivering GMPLS frames. In this case, a VLAN for GMPLS must be configured in both GMPLS implemented bridges and unaware bridges. Since GMPLS implemented bridges have ability to control multicast frames and avoid looping, the GMPLS bridges set forwarding state of the VLAN in all ports and take all ports in consideration of shortest path computation. However the GMPLS unaware bridges may not have such ability, hence, filtering state of the VLAN must be configured carefully in those bridges that unexpected looping of multicast frames is prevented. There can be several methods to prevent looping of multicast frames in legacy bridges. Figure 4 below shows an example of VLAN configuration where GMPLS implemented bridges, G1 and G2, share common LAN segment with GMPLS unaware bridges, B1 and B2. R1 and R2 describe edge routers supporting GMPLS implementation. The GMPLS implemented bridges configured the VLAN in all ports and use all ports for forwarding multicast frames. When one of the GMPLS unaware bridges configured forwarding state of the VLAN, other bridge that sharing the common LAN segment must filter the VLAN in order to prevent looping between the bridges. J.Cho, et.al. Expires - July 2006 [Page 10] Label Switched Ethernet Architecture July 2006 Figure 4 illustrates that B2 set filtering state of the VLAN in one of the ports, as a result, GMPLS frames pass only through B1. | +-+-+ | R1| +-+-+ | ========================= | | +-+-+ +-+-+ | G1| | G2| +-+-+ +-+-+ | | ========================= | | +-+-+ +-+-+ | B1| | B2| +-+-+ +-+-+ | : VLAN | x Filtered | : ========================= | +-+-+ | R2| | VLAN Configured +-+-+ : VLAN Filtered | Figure 4. VLAN Configuration in GMPLS Unaware Bridges When B1 and B2 are capable of supporting GMRP (GARP Multicast Routing Protocol) or IGMP (Internet Group Management Protocol), GMPLS implemented bridges may interact with the GMPLS unaware bridges using the protocols and precisely control LSP path in those bridges. Detail of the interoperation with GMPLS unaware bridges is out of the scope in this document. J.Cho, et.al. Expires - July 2006 [Page 11] Label Switching Ethernet Architecture July 2006 6. Inter-domain Extension and Future Work In this version of document, the proposed LSE method only applies to intra-domain case where allocation of multicast address is administered by single organization. This allows up to 16 million LSPs being established in a bridged core network which is enough in most scale of single administrative domain. When two bridged network of different administrative domains need to be interconnected, this document recommends using upper layer protocol relay, such as MPLS LSR or IP router. Layer-2 connectivity of LSP is terminated at the border of domain. Currently, work is in progress in IEEE 802.1ah to provide layer-2 connectivity in inter-domain scale. A solution being considered is extension of MAC-in-MAC tunnel across multiple inter-domain networks. Since LSE also supports MAC-in-MAC tunnel, it is expected that any inter-domain solution devised in 802.1ah may equally be applied to this proposal. J.Cho, et.al. Expires - July 2006 [Page 12] Label Switching Ethernet Architecture July 2006 Security Considerations Some security issue has been discussed in section 3 and 4.2 References [IEEE802] IEEE Computer Society, "IEEE Standard for Local and Metropolitan Area Networks:Overview and Architecture", IEEE Std 802-2001, IEEE Standard Document, 8 March 2002 [IEEE8021D] IEEE Computer Society, "Media Access Control (MAC) Bridges", IEEE Std 802.1D-2004, IEEE Standard Document, 9 June 2004 [IEEE8021Q] IEEE Computer Society, "Virtual Bridged Local Area Network", IEEE Std 802.1Q 2003 Edition, IEEE Standard Document, 7 May 2003 [IEEE8021AD] IEEE Computer Society, "Virtual Bridged Local Area Networks - Amendment 4 : Provider Bridges", P802.1ad/D6.0, Draft, Work in Progress [IEEE8021AG] IEEE Computer Society, "Virtual Bridged Local Area Networks - Amendment 5 : Connectivity Fault Management", P802.1ag/D5.2, Draft, Work in Progress [IEEE8021AG] IEEE Computer Society, "Virtual Bridged Local Area Networks - Amendment 6 : Provider Backbone Bridges", P802.1ah/D1.52, Draft, Work in Progress [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC3945, Oct 2004 J.Cho, et.al. Expires - July 2006 [Page 13] Label Switching Ethernet Architecture July 2006 Author's Addresses Jaihyung Cho (ETRI) 161 Gajung Dong, Yuseong Gu, Daejeon, Korea Phone: +82 42 860 5514 Email: jaihyung@chol.com Dae Young Kim (Chung Nam National University) Email: dykim@cnu.ac.kr 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 J.Cho, et.al. Expires - July 2006 [Page 14] Label Switching Ethernet Architecture July 2006 Copyright (C) The Internet Society (2004). 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. Full Copyright Statement Copyright (C) The Internet Society (2004). 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. J.Cho, et.al. Expires - July 2006 [Page 15]