Network Working Group N. Sprecher Internet-Draft D. Berechya Expires: September 17, 2006 Siemens AG F. Lingyuan Huawei Technologies J. Liu Guangzhou Telecom March 16, 2006 GMPLS Control of Ethernet VLAN Cross Connect Switches draft-sprecher-gels-ethernet-vlan-xc-01.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 September 17, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document complements the 'GELS framework for GMPLS-controlled Ethernet Label Switching' paper ([GELS-FRAMEWORK]). It is based on the architecture and the control plane operations which are defined in the framework. Specifically, this document explains how Ethernet Sprecher, et al. Expires September 17, 2006 [Page 1] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 switches employing the VLAN Cross Connect method use the link local labels defined in the GELS framework document to establish Connection Oriented point-to-point Ethernet services. An additional document will be written to describe the natural extension to support multipoint services. Sprecher, et al. Expires September 17, 2006 [Page 2] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 1. Terminology The following terminology is introduced in addition to the terminology defined in the framework. VLAN Cross Connect: A method for providing Connection Oriented Ethernet. Using this method, frames are forwarded according to the ingress port on which they enter a network element and the VLAN Identifier(s) that appears in the frame. VXC Connection: An end-to-end Ethernet connection created by the VLAN Cross Connect method. VLAN-XC: A virtual channel that cross connects ingress and egress points of an Ethernet VLAN-XC network element. VLAN-XC Domain: The partition of the Ethernet provider network that provides the VLAN Cross Connect. Selector ID: The VID field of the outer 802.1Q tag of the Ethernet frame. VXC-Identifier: An identifier of the VLAN-XC. This is a 12-bit or 24-bit identifier, depending on the value of the Selector ID. VXC-TAG: VLAN Cross Connect TAG, the 802.1Q Tag, identifying the VXC Connection. The VXC-Identifier is the standard 12-bit VID field of the tag. EVXC-TAG: Extended VLAN Cross Connect Tag: Double 802.1Q tags concatenating the standard outer VLAN tag and the standard subsequent inner VLAN tag. The Extended VLAN-XC Identifier is the concatenation of the 12-bit VID of the outer VLAN tag and the 12-bit VID of the subsequent inner VLAN tag. Combined, they create a 24-bit wide VXC- Identifier. Provider Edge Node: An Ethernet network element at the edge of the VLAN-XC Domain creating and terminating VLAN-XC connections. Provider Node: An Ethernet network element within the VLAN-XC Domain that performs the VLAN cross-connect function. Sprecher, et al. Expires September 17, 2006 [Page 3] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 2. Introduction Ethernet has become widely used within Service Provider networks. With the evolution from LAN Ethernet to Carrier Ethernet through the addition of new mechanisms like VLAN stacking (IEEE802.1ad), OAM (Y.1731, IEEE802.1ag) and MAC stacking (IEEE802.1ah), Ethernet now provides the carrier market with high-speed interfaces, cost-saving efficiency and flexibility, in addition to a reduction in CAPEX. This evolution, however, preserves the basic characteristics of Ethernet switching (e.g. MAC learning and forwarding, xSTP, etc.) and the connectionless nature of Ethernet, and does not properly address the increasing demand of Service Providers for scalability, fast recovery time, Traffic Engineering and guaranteed end-to-end QoS for different service requirements. For point-to-point and point-to-multipoint services, MAC address learning is not required, as frames do not have to be directed to different outputs based on their MAC address. They are all sent to the same output ports. The IEEE802 has recognized this and the latest IEEE802.1q allows MAC address learning to be disabled for point-to-point VLANs in a bridge. By removing the need for MAC address learning, the VLAN Cross Connect method resolves the MAC scalability issues associated with bridging networks. In the VLAN Cross Connect method, the frames are forwarded according to the ingress port and the VXC-Identifier (i.e. Ethernet label) of the ingress frames, regardless of the MAC addresses. The VXC-Identifiers (i.e. Ethernet labels) are only significant on the local links, where they simplify the VLAN-XC domain-wide provisioning task and improve its scalability. A maximum of 16 million services per port can be delivered using the VLAN Cross Connect method. The VLAN Cross Connect method supports end-to-end QoS and Traffic Engineering with guaranteed BW, and controlled jitter and delay. The GMPLS control plane can be used to setup the end-to-end path throughout the network and to reserve the resources along the path appropriately. The VLAN Cross Connect method can provide high availability to ensure guaranteed services. Through mechanisms like OAM, global/centralized and/or local/distributed protection mechanisms, the Ethernet network can provide failover times defined in tens of milliseconds that are needed to meet stringent SLA obligations. A sub-50ms recovery time can be enabled through the comprehensive set of GMPLS resiliency mechanisms, providing a solution to the convergence time issues of traditional Ethernet mechanisms (xSTP). The VLAN Cross Connect method resolves security issues. Sprecher, et al. Expires September 17, 2006 [Page 4] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 The VLAN Cross Connect method supports both uni-directional and bi- directional VXC connections. The VLAN Cross Connect method maintains the standard Ethernet frame (as defined in IEEE 802.1Q and IEEE 802.1ad). Bridging and VLAN Cross Connect can coexist on the same network infrastructure (even on the same port) to provide the most appropriate method for a particular service, depending on its specific requirements. While the bridging method may be applied for residential multicast services and basic Ethernet transparent LAN services (e.g. Business MPtMP VPN, IP TV, etc.), the VLAN Cross Connect method may be applied for business-critical services with associated SLAs, such as business and residential voice services, residential video-on-demand, etc. More detailed descriptions on the VLAN Cross Connect method can be found in [ITU-T VLAN Switching] and in [IEEE VLAN-XC]. Sprecher, et al. Expires September 17, 2006 [Page 5] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 3. VLAN Cross Connect Functional Overview The VLAN Cross Connect method complies with the framework and architecture defined by the GELS framework for GMPLS-controlled Ethernet Label Switching. End-to-end VLAN-XC connectivity (i.e. VXC Connection) may be established between two Ethernet label-controlled interfaces belonging to E-LERs. These interfaces are capable of recognizing the Ethernet frame boundaries and can switch data based on the content of the standard IEEE 802.1 Ethernet frame. End-to-end VLAN-XC connectivity originates on an ingress E-LER and terminates on an egress E-LER. For point-to-point bi-directional VLAN-XC connectivity, the same pair of E-LERs acts as both ingress and egress E-LERs. The VLAN Cross Connect method makes use of two kinds of identifiers (i.e. Ethernet labels), the 12-bit VLAN Cross Connect Identifier (VXC-Identifier) and the 24-bit Extended VLAN Cross Connect Identifier (EVXC-Identifier). 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 specification. The pre-processed frame is then presented to the ingress E-LER function that (1) maps the incoming frame to a particular end-to-end VXC Connection (i.e. Ethernet LSP) according to different criteria (such as the MAC address(es), the VID, the 1.Q priority, the standard 5-tuple, etc.), and (2) adds an Ethernet (E)VXC-Identifier (i.e. Ethernet label) to the frame and forwards it via the appropriate label-controlled interface along the VXC Connection (Ethernet LSP). Throughout the provider Ethernet network, the frames are switched via the appropriate interface based on the ingress port and the (E)VXC- Identifier (i.e. Ethernet label), which is encoded in the standard IEEE 802.1 frame header. The switching operation replaces the (E)VXC-Identifier (i.e. Ethernet label) before the frame is transmitted. Hybrid switching may be supported to switch a VXC- tagged Ethernet frame to an Extended VXC-tagged Ethernet frame or vice versa. Frames that are received with an unknown (E)VXC- Identifier are silently discarded. The forwarding decision is based on the information residing in the forwarding table. This table may be configured by the GMPLS control plane. The egress E-LER terminates the VXC Connection (i.e. Ethernet LSP) by removing the (E)VXC-Identifier (i.e. Ethernet label) from Sprecher, et al. Expires September 17, 2006 [Page 6] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 incoming frames. The PE then performs post-processing operations on the incoming frame and forwards it on the appropriate CE-PE interface. Post-processing may include, for example, VID translation, VID insertion/ stripping, etc. These operations are beyond the scope of this specification. 3.1. VLAN Cross Connect Frame Semantic The (E)VXC-Identifier (i.e. Ethernet label) is part of the Ethernet MAC frame header and has local port scope. The same (E)VXC- Identifier value can be reused on different ports. The coding of the (E)VXC-Identifier (i.e. 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 (E)VXC-Identifiers (i.e. Ethernet label) are assigned and interpreted locally and have local significance. This does not preclude the assignment of the same (E)VXC-Identifier value (i.e. Ethernet label) by consecutive hops. The (E)VXC-Identifiers (i.e. Ethernet labels) are extensible for the establishment and the support of VXC Connections (i.e. Ethernet LSPs) over multiple domains and for the support of point-to-multipoint VXC Connections (i.e. point- to-multipoint Ethernet LSPs) to carry Ethernet multicast traffic. These natural extensions will be described in a complementary document. 3.2. (E)VXC-Identifiers As described above, two kinds of identifiers are supported by the VLAN Cross Connect method: (1) the 12-bit VXC-Identifier which enables the support of up to 4k VLAN-XCs per interface, and (2) the 24-bit Extended VXC-Identifier (EVXC-Identifier) which enables the support of 16M VLAN-XCs per interface. For hybrid switching, the provider internal switches (i.e. E-LSRs) can switch VXC tagged Ethernet frames by replacing the VXC identifier with the Extended VXC (EVXC) identifier and vice versa. 3.2.1. VXC-Identifier The IEEE 802.1ad S-VID, defined in the amendment to IEEE Std 802.1Q- 1998, is used as the VXC-Identifier. Figure 1 depicts the format of the standard IEEE 802.1Q Ethernet frame which is referred to as a 'VXC Tagged Frame' by the VLAN Cross Connect method. Sprecher, et al. Expires September 17, 2006 [Page 7] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 TAG --------- | | +-----------+------------+----+----+----+---------------+------+ | | | | | | | | | Dest MAC | SRC MAC |TPID|TCI |LEN\| Payload | FCS | | Address | Address | | |TYPE| | | +-----------+------------+----+----+----+---------------+------+ Figure 1: Standard IEEE 802.1Q Frame Format TPID: The TAG protocol Identifier (TPID) is a 16-bit length field which is defined with a value of 0x88A8 to identify the frame as an IEEE 802.1Q tagged frame. TCI: The S-VID encoded in the TAG Control Information (TCI) field of the S-TAG is used as the VXC-Identifier (as depicted in Figure 2). The length of the VXC Identifier is 12 bits, providing for a space of 4k VLAN-XCs per link. VXC-Identifier ----------------------- | | Oct: 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCP |D| VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bit: 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 Figure 2: TCI Format PCP: 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 802.1p priority. D: The D bit (1 bit) is the Drop Eligible Indicator (DEI) bit. S_VID: The S_VLAN Identifier (VID) is a 12-bit length field uniquely identifying the VLAN to which the frame belongs. In the VLAN Cross Connect method, it encodes the VXC-Identifier. Its value can be between 0 and 4,095. The S-VID translation mechanism (defined by the IEEE 802.1ad) is used for the switching operation. MAC address learning and flooding should be inhibited (as supported the IEEE802.1q for point-to-point VLANs in a bridge). Sprecher, et al. Expires September 17, 2006 [Page 8] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 GMPLS may be used to configure the 12-bit VXC-Identifier (i.e. Ethernet label). 3.2.2. Extended VXC Identifier In cases where the 4K link local identifier space is too small, an Extended VXC Identifier (EVXC-Identifier) can be used. The Extended VXC Identifier is created by 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), thus providing a 24-bit length identifier. This technique makes use of the standard IEEE 802.1ad Stacked VLAN (QinQ) frame. Figure 3 depicts the format of the IEEE 802.1ad Ethernet frame with Stacked VLAN (QinQ). S-TAG C-TAG -------- ------- / \ / \ +---------+----------+----+----+----+----+----+--------------+------+ | | | | | | | | | | |Dest MAC | SRC MAC |TPID|TCI |TPID|TCI |LEN\| Payload | FCS | | Address | Address | | | | |Type| | | +---------+----------+----+----+----+----+----+--------------+------+ Figure 3: Standard IEEE 802.1ad Format with Stacked VLAN. This technique makes use of VID translation, as currently discussed in the IEEE 802.1. Neither MAC-learning nor flooding for the range of VIDs are required. GMPLS may be used to configure the 24-bit EVXC-Identifier (i.e. Ethernet label). 3.3. Ethernet Services End-to-end VLAN-XC connectivity can be used to provide any service that is supported by standard Ethernet. These services are mapped in the Provider Edge Nodes (i.e. the E-LERs) to an appropriate VXC Connection. The Ethernet frame is extended with the (E)VXC-TAG when it is sent over the VXC Connection. The original client VLAN TAG (i.e. the CE-TAG) may, as an option, be transmitted transparently over the VXC Connection (i.e. preserved over the network), depending on the service definition. A single VXC connection may support a set of customer VLANs (bundling). All the various service mappings defined in ITU-T G.8011 can be supported. The ITU-T definitions are aligned with the definitions of the MEF. A future work will be undertaken relating to the capability of the VLAN Cross Connect to enable Ethernet to provide a transport layer for multiple services, such as TDM, FR, etc. Sprecher, et al. Expires September 17, 2006 [Page 9] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 4. Interworking with Ethernet Legacy Bridging As specified above, hybrid Bridging and VLAN Cross Connect services can co-exist on the same provider network. The hybrid network may contain both legacy bridges and hybrid (bridge and VLAN-XC) network elements. While legacy bridges only handle bridge traffic, hybrid network elements may handle both bridge and VLAN-XC traffic. The provider network can be optimized by applying the most appropriate method (VLAN Cross Connect or bridging) for a particular service, according to its specific requirements. The VLAN Cross Connect method may coexist with the standard bridging method on the same port on the node. Based on the Selector ID value that appears in the Ethernet frame, the network elements determine whether the bridging or VLAN Cross Connect method should be applied to a frame. Traffic segregation between VLAN Cross Connect and bridging is performed according to the characteristics and the requirements of the services that are to be provided. Traffic segregation enables the advanced services offered by the VLAN Cross Connect method to be fully exploited while maintaining legacy bridging services. 4.1. Method Selector The value of the VID field of the Ethernet frame's outer VLAN tag acts as the method selector (Selector ID). Depending on the value of the VID, it is determined whether the bridging method should be applied to the frame (where switching is performed according to the MAC addresses and the VLANs), or whether the VLAN Cross Connect method should be applied (where switching is performed according to the ingress port and the (E)VXC-Identifier, regardless of the MAC addresses). Figure 4 illustrates the co-existence of both methods in hybrid networks. The 'S' function depicted in the figure represents the method selector function. Sprecher, et al. Expires September 17, 2006 [Page 10] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 Hybrid Provider Hybrid Provider Hybrid Provider Edge Node Node Edge Node +--------+ +--------+ +--------+ | |VLAN-XC | | VLAN-XC Services | | |VLAN-XC |------->|VLAN-XC | ---------------------> |VLAN-XC | \ |Services\ | \ | ==>S-------+ S--------+ Legacy Bridge S -------+ ==> / |Bridging/ | +----------+ / | |Bridging|------->|Bridging| ---> | Bridging | ---> |Bridging| | |Services| |\ +----------+ ->| | +--------+ +--------+ \ ^ / +--------+ \ Legacy | Bridge | \ +---------+ / -> | Bridging |/ +----------+ Figure 4: Hybrid Bridging and VLAN Cross Connect The address range of the outer VLAN tag, which is split between the switching and bridging ranges (e.g. 1-100 for VLAN Cross Connect and the remainder for bridging), should be configurable. A future work will be undertaken to automate this configuration process and to extend the RSVP-TE protocol to include a 'Label Request with VLAN Label Range' Object. This Object will specify the lower and the higher limits of a block of the identifiers that are supported on the originating switch. Note that when the Extended VXC Identifier is used for the VLAN Cross Connect, only a small address range belonging to the outer VLAN tag has to be assigned to the VLAN Cross Connect. The available VLAN address range for bridging services is therefore hardly affected, while the VLAN Cross Connect can use the full address range of the inner tag. 4.2. Hybrid Bridging and VLAN Cross Connect Networks A provider Ethernet network incorporating both the bridging and VLAN Cross Connect methods is better equipped to address some of the fundamental challenges of Ethernet provider networks than the standalone traditional bridging method. The reasons for this are as follows: Ethernet Services: The VLAN Cross Connect method is applicable for both point-to-point and point-to-multipoint multicast services, while bridging can only be used for multipoint-to-multipoint services. Sprecher, et al. Expires September 17, 2006 [Page 11] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 Traffic Engineering: The VLAN Cross Connect method allows for full support of end-to-end Traffic Engineering. Fast Recovery: Following failure, The 'VLAN Cross Consent' services can be recovered in sub-50 ms. When hybrid networks are used correctly, the Forwarding Database (FDB) remains small, resulting in improved recovery time for bridging services. MAC Scalability: When the VLAN Cross Connect method is applied for services that consume a large number of MAC addresses in hybrid networks, the FDB size (used for bridging services) is remains small due to the insignificance of MAC addresses in the VLAN Cross Connect method. VLAN Scalability: Unlike the bridging method in which VLAN identifiers have global scope, the identifiers in the VLAN Cross Connect method only have local port scope. Correct segregation between the VLAN Cross Connect and bridging methods results in optimized VLAN scalability. While in the bridging method only the outer VLAN tag is significant, both the outer VLAN tag and the next VLAN tag could be significant in the VLAN Cross Connect method. User Isolation and Identification: In order to provide user isolation in pure bridge networks, an additional method should be applied, such as private VLAN or port isolation. These mechanisms are, however, targeted at specific applications and do not provide general solutions. In the VLAN Cross Connect method, users are inherently isolated and identified by the end-to-end VXC connection. Security: The VLAN Cross Connect method does not rely on MAC addresses, and MAC address learning is inhibited. Hence, the potential threats of MAC spoofing and MAC attacks are significantly reduced. Bridging services should apply a MAC limiter per port or a VLAN to protect the network. Sprecher, et al. Expires September 17, 2006 [Page 12] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 5. Hierarchical Networks The VLAN Cross Connect method can be naturally extended to provide trunk services (e.g. for backbone applications). The (E)VXC-TAGs can be stacked to create hierarchical VLAN Cross Connect Domains. Figure 5 depicts how the Level N+1 domain can provide tunnelling transport for VXC connections between two level N clouds. This will be described in a future document. <--------------- End to End VLAN XC services ---------------> CE PE PE P PE PE CE +--+ +---+ +------+ +-----+ +-----+ +---+ +--+ | | | | | | | | | | | | | | | |---| |---| | | | | |---| |---| | +--+ +---+ | |======| |======| | +---+ +--+ | |. . . . . . . . . .| | +--+ +---+ | |. . . . . . . . . .| | +---+ +--+ | |---| |---| |======| |======| |---| |---| | | | | | | | | | | | | | | | +--+ +---+ +------+ +-----+ +-----+ +---+ +--+ CE PE PE CE | | | | -------------- -------------- Level N Domain Level N Domain | | --------------------------- Level N+1 Domain Figure 5: VXC Connections over Multiple Domains Sprecher, et al. Expires September 17, 2006 [Page 13] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 6. Control Plane As defined in the 'GELS framework for a GMPLS-enabled Ethernet network', the GMPLS control plane can be used to enable fast, dynamic and reliable VLAN-XC service provisioning in multi-vendor and multi- domain environments. See the 'GELS framework' for details of the control plane elements and operations. Sprecher, et al. Expires September 17, 2006 [Page 14] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 7. OAM Robustness is enhanced with the addition of OAM in the data plane to provide both fault and performance management. The OAM functions and frames defined in Y.1731 and in IEEE 802.1ag can be used. Sprecher, et al. Expires September 17, 2006 [Page 15] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 8. VLAN Cross Connect Network 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 Service Level Agreements (SLAs) requires a resilient network that instantaneously detects facility or node failures and immediately restores network operations to meet the terms of the SLA. Through mechanisms such as pre-provisioned, end-to-end backup VXC Connections and fast failure detection using OAM mechanisms, the provider Ethernet network can match the sub-50 ms failover times required to maintain time-bounded services, even when thousands of services are simultaneously affected by a failure. Using an end-to-end alternative path, an Ethernet VXC Connection is protected between the ingress Provider Edge node and the egress Provider Edge node over the Ethernet domain. When a failure occurs, data traffic is switched in the ingress Provider Edge node from the failed VXC Connection to its backup VXC Connection. The backup VXC Connection is provisioned in advance to protect the primary VXC Connection and is ready for immediate use (1:1 hot standby). When the protected XVC Connection cannot be sustained, the ingress Provider Edge node switches the data traffic from the failed VXC Connection to the pre-provisioned backup VXC Connection. In order to guarantee in advance that the backup VXC Connection would be able to protect a VXC Connection, both protected and backup VXC Connections have to be totally separate from one another, meaning that they have to be conducted through geographically diverse network elements (without sharing any resources). This can be accomplished using the GMPLS control plane or via a domain-wide provisioning tool. The resources of the backup VXC Connection may be used by low- priority traffic which can be discarded when the protected VXC Connection fails (1:1 hot standby with extra traffic). Revertive and non-revertive switching modes are supported. In revertive operation, traffic is restored to the primary VXC Connection after the problem causing the switchover has been cleared. It is recommended that the revertive mode be used when the path of the backup VXC Connection is of inferior quality, or when extra traffic is carried on the backup VXC Connection, so that traffic can be restored when the problem causing the switchover has been resolved. In addition, it should be possible to use the GMPLS re-routing mechanisms to recover VLAN-XC Connections (i.e. Ethernet LSPs), Sprecher, et al. Expires September 17, 2006 [Page 16] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 including end-to-end and segment VLAN-XC Connections (i.e. Ethernet LSPs). Sprecher, et al. Expires September 17, 2006 [Page 17] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 9. Security Considerations MAC spoofing and MAC attacks are inherently eliminated in the VLAN Cross Connect method due to the insignificance of MAC addresses and the inhibition of the MAC learning process. For a description of other relevant issues, see the section on the 'Security Considerations' in [GELS-FRAMEWORK]. Sprecher, et al. Expires September 17, 2006 [Page 18] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 10. References 10.1. Normative References [RFC 3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3471] Berger, L. et.al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", January 2003, RFC 34713. 10.2. Informative References [GELS-FRAMEWORK] "A Framework for GMPLS-controlled Ethernet Label Switching", draft-papadimitriou-gels-framework-01.txt (Work In Progress). [IEEE 802.1Q-Consolidated/D0.0] "Virtual Bridged Local Area Networks, Consolidated edition", October 2005. [Y.17ethoam] ITU-T Recommendation, "Draft Recommendation Y.17ethoam- OAM Functions and Mechanisms for Ethernet based Networks" (work in progress), May 2005 [IEEE 802.1ag] "IEEE standard for Connectivity Fault Management" (Work in progress), December 2005 [MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services Definitions - Phase I" (Work in progress), 2004 [MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet Services Attributes Phase 1" (Work in progress), 2004 [MEF.11] The Metro Ethernet Forum MEF 11 (2004), "User Network Interface (UNI) Requirements and Framework" (Work in progress), 2004 [ITU-T VLAN Switching] "VLAN Switching (Cross Connect)" Contribution Number 547, Q12/SG15, January 2006 [IEEE VLAN-XC] "Provider Ethernet VLAN Cross Connect" new-sprecher- vlan-xc-ieee-0106.pdf, January 2006 Sprecher, et al. Expires September 17, 2006 [Page 19] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 Authors' Addresses Nurit Sprecher Siemens AG (Seabridge Networks) 3 Hanagar St. Neve Ne'eman B Hod Hasharon 45241 ISRAEL Phone: +972 9 775-1229 Email: nurit.sprecher@seabridgenetworks.com David Berechya Siemens AG (Seabridge Networks) 3 Hanagar St. Neve Ne'eman B Hod Hasharon 45241 ISRAEL Phone: +972 9 775-1210 Email: David.Berechya@seabridgenetworks.com Fan Lingyuan Huawei Technologies Co., Ltd. Huawei Industrial Base Bantian, Longgang District Shenzhen P.R.C. Phone: +86-755-28976446 Email: fanlingyuan@huawei.com Junmin Liu Guangzhou Prefecture Brance, China Telecom Co., Ltd. 20/F, No. 128, Tiyudong Rd. Guangzhou 510620 P.R.C. Phone: +86-20-38816508 Email: liujm@gztelecom.com Sprecher, et al. Expires September 17, 2006 [Page 20] Internet-Draft GMPLS Control of VLAN-XC Switches March 2006 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sprecher, et al. Expires September 17, 2006 [Page 21]