Issues and Approaches on Extending Ethernet Beyond LANs

Transcription

1 ETHERNET TRANSPORT OVER WIDE AREA NETWORKS Issues and Approaches on Extending Ethernet Beyond LANs Girish Chiruvolu, An Ge, David Elie-Dit-Cosaque, Maher Ali, and Jessy Rouyer, Alcatel USA ABSTRACT Currently, LAN technology is predominantly Ethernet-based and offers packet-optimized switched technology. With more than 90 percent of Internet traffic originating from Ethernetbased LANs, efforts are underway to extend Ethernet beyond LANs into MANs and further into WANs. However, native Ethernet protocols need extensions or support from other technologies in order to succeed as MAN technology in terms of scalability, QoS, resiliency, OAM, and so on. The two emerging trends to carry Ethernet traffic across the MAN can be classified into native Ethernet (IEEE) protocol extensions, and encapsulation by another transportation technology such as MPLS networks. The goal is to offer new and challenging services such as virtual private LAN service, also known as transparent LAN service (TLS). This article presents a comprehensive overview of the required extensions/support of the Ethernet with an emphasis on the emerging provider bridge technology. INTRODUCTION Ethernet has evolved over the past decade from a simple shared medium access protocol to a full-duplex switched network. Ethernet dominates current local area network (LAN) realizations. It has been estimated that more than 90 percent of IP traffic originates from Ethernet LANs. Efforts are underway to make Ethernet an end-to-end technology spanning across LANs, metropolitan area networks (MANs), and possibly wide area networks (WANs). Fast and Gigabit Ethernet have brought more bandwidth to the technology. The required quality of service (QoS) features are under development for emerging new services, thus enabling Ethernet to make inroads toward backbone networks. Service providers are on the lookout for supporting technologies that enable newer Ethernet-based services such as transparent LAN service (TLS) connecting various customer sites across a metropolitan domain (metro Ethernet). In the context of metro Ethernet/WAN, a customer virtual LAN (C-VLAN) is a collection of multiple LANs that are physically connected to a shared service provider network (SPN) as shown in Fig. 1. The SPN is transparent to the customer s LAN segments, and the C-VLAN segments operate as a single VLAN. In this article we consider the SPNs that can be realized as an Ethernet bridged network (IEEE switches) or multiprotocol label switching (MPLS)-based network. The IEEE 802.1ad group is currently in the process of defining appropriate extensions to the existing Ethernet to realize a provider network (P- VLAN) [1] with the emphasis on interoperability and cost effectiveness. On the other hand, the Martini encapsulation scheme [2] facilitates transportation of layer 2 frames across a switched (MPLS cloud) network and thus forms a basic building block of the virtual private LAN service (VPLS) [3]. Typically, a P-VLAN shall run the IEEE protocols (with appropriate extensions) such as Spanning Tree Protocol (STP), and the forwarding is based on self-learning of medium access control (MAC) addresses in the participating Ethernet switches. On the other hand, a VPLS relies on both psuedo-wires (label switched paths [LSPs]) across the edge nodes of an MPLS domain, and routing along with horizon techniques (a route/frame is never advertised on the links from which it was learnt). An Ethernet virtual connection (EVC) is defined as a logical connection between various SPN edge nodes (customer sites) [4]. It should be noted that an EVC can be either point-to-point (P2P) or point-to-multipoint (P2MP) and is applicable to both VPLS and P-VLAN networks. A brief overview of the working details of an Ethernet switch is presented next [1]. An Ethernet switch learns the MAC addresses of end hosts and associates them with appropriate ports on which the end host frames arrive. It can bridge different segments of a LAN, thus providing connectivity between all the end hosts and in turn essentially defining a broadcast domain on which the end hosts can communicate unsolicited with each other [1]. Ethernet relies on STP [1] to seamlessly operate with selflearning of MAC addresses, and the spanning tree (ST) provides loop-free connectivity across the participating Ethernet bridges. Furthermore, the IEEE 802.1Q standard (referred to as Q /04/$ IEEE

2 Std) enables the realization of VLANs that are logical LANs (or equivalently broadcast domains) over a shared (physical) network (Ethernet). The standard was developed to break large networks into smaller parts so that broadcast and multicast traffic would not consume more bandwidth than necessary for various VLAN realizations. The Q-Std specifies a method for tagging (with Q-tags) Ethernet frames with VLAN membership. A 12-bit VLAN identifier (VID) in the Q-tag identifies the VLANs to which a frame belongs in a shared network. In addition, VIDs facilitate optimal pruning and reduce the size of the broadcast domain over a given ST. The tagged frames belonging to a given VLAN will be forwarded across the network only to the end hosts of the VLAN, thereby improving bandwidth utilization and providing implicit VLAN segregation. In addition to the VID field, the Q-tag also contains the following fields: A 3-bit priority field that can be used to determine the class of service (CoS) A canonical format identifier (CFI) field An Ethertype field that indicates the protocol to which the payload of the frame belongs A metro Ethernet provider network shall support a large number of C-VLANs, and in turn thousands of end hosts in these C-VLANs. If the current IEEE 802.1D [1] Ethernet switches are to be deployed in order to realize an SPN, a number of issues must be addressed, summarized as follows: Containment of MAC address table explosion in the provider switches Expansion of the limited VID space (due to 12-bit size) and support for more than 4096 C-VLANs across the SPN Design of schemes for isolation as well as interaction of the provider and customer control protocols Realization of various traffic management functions, such as multipoint QoS, to meet contracted service level agreements (SLAs) Design of efficient OAM tools Several aspects of these issues are analyzed in this article along with possible solutions addressing the limitations of the current Ethernet such that it can be extended to the MAN. Additional issues such as security and multicast/broadcast radiation (e.g., efficient VLAN pruning) are important, but they are beyond the scope of this article. The remainder of this article is organized as follows. We deal with various relevant encapsulation schemes and the issues in layer 2 control protocol handling for TLS. Key components of QoS such as multipoint traffic engineering (TE), fast traffic protection against failures, and evolving Ethernet operation, administration, and maintenance (OAM) functions are addressed. Finally, we conclude the article. CUSTOMER FRAMES TRANSPORT/ENCAPSULATION The IEEE 802.1D Ethernet switches deployed at the core of a metro domain would have to learn all active end host MAC addresses in every C- Provider core functions Core provider network site A Edge functions (C-VLAN) Figure 1. Metro Ethernet architecture. (SPN) site B VLAN attached to that domain. As the number of hosts attached to a metro domain increases, this may result in large MAC address tables (MAC address table explosion) that must be maintained by the core metro switches. Moreover, the metro service provider may run out of Q-tag space as determined by the 12-bit VID. Furthermore, two or more C-VLANs may choose the same VID; thus, the service provider needs to differentiate between them within the metro domain. The above problems are broadly referred to as metro Ethernet scalability issues. The encapsulation methods (e.g., VLAN stacking, MPLS-based Ethernet encapsulation) for C- VLAN segregation/scaling and MAC address table containment shall be explored next. LAYER 2 MAC ENCAPSULATION Several encapsulation schemes have been proposed to address the above issues and facilitate metro Ethernet services. These schemes insert additional tags/fields in the customer Ethernet frames at the ingress nodes and are stripped off at the egress nodes before the frames are handed over to the appropriate C-VLAN segments (sites). VLAN Stacking Since the Ethernet is inherently a broadcast network, it is necessary that the broadcast traffic of one VLAN not be flooded onto other VLANs. The Q-tag inserted in the frames can be used to limit flooding to the switches that participate in the VLAN. The Q- tag can only support 4096 unique VIDs, and several approaches address this shortcoming. One approach is to insert an additional provider Q- tag into the customer frames at the ingress switch of a domain, as shown in Fig. 2. This stacked Q- tag scheme is referred to as Q-in-Q/QiQ. In the QiQ scheme there are two possible ways of interpreting the stacked Q-tags by the provider switches. In the first one, only the VID of the outer tag (inserted at an ingress node) is used by the core Ethernet switches to identify the C-VLAN across the metro domain. The other variant is to combine both the VID fields Customer 2 81

3 It is worth noting that QiQ is currently investigated by the standard bodies and is applicable to a bridged provider network. Combining the VLAN stacking and MAS is equivalent to the MiM scheme. Schemes for MPLS-based Metro-Ethernet for addressing the same issues are described below p (3 bits) MAC DA MAC SA 0X8100 (ethertype) Figure 2. Stacked Q-tag. CFI (1 bit) Stacked Q-tag VLAN ID (12 bits) of the stacked Q-tags (customer and provider assigned) and thus be able to support a larger number of C-VLANs (more than 4096). The first scheme is backward compatible with the Q- Std; the latter is not. Other nonstandard tags have been proposed using more VID bits [3]. The VLAN stacking schemes can also address the scalability of MAC address tables in the core switches in a limited manner. For example, in the case where only two ports of an Ethernet switch forward frames of a C-VLAN, the learning of individual MAC addresses of the C-VLAN can be avoided. The switch only needs to learn about the VIDs to forward frames [5]. However, for the cases where C-VLAN frames arrive on more than two ports, all the end host MAC addresses of the C-VLAN have to be learned by the Ethernet switch. The issue of containing MAC address tables, especially in the core metro switches, is discussed next. MAC Address Stacking The MAC address stacking (MAS) scheme explicitly addresses MAC address table explosion. As shown in Fig. 3, an ingress node inserts two additional fields into the customer frames: source and destination MAC addresses of the provider edge nodes. These fields have local significance within the metro domain. The provider domain transports the user (C-VLAN) frames based on provider edge nodes MAC addresses. Furthermore, the end users MAC addresses are associated with the corresponding ingress node s MAC address. As a result, each of the core switches learns only the edge switch MAC addresses and avoids large end-user MAC addresses. The MAS is independent of the Q-tag schemes used and can be supported by existing switches with appropriate extensions (e.g., a new Ethertype). It is worth noting that QiQ is currently being investigated by the standard bodies [1] and is applicable to a bridged provider network. Combining VLAN stacking and MAS is equivalent to the MAC-in-MAC (MiM) scheme [3]. Schemes for MPLS-based metro Ethernet to address the same issues are described below. MPLS LAYER-2 ENCAPSULATION MPLS encapsulation (aka Martini encapsulation) facilitates transportation of layer 2 frames across an MPLS service provider domain [2]. The metro domain in this case comprises MPLS label switch routers (LSRs). Two MPLS labels are added onto the customer Ethernet frames based on destination MAC address/port/q-tag information at the Customer frame Q-tag 802.1Q Original Ethertype Q-tag Ethernet type Data CRC ingress node, as shown in Fig. 4. The first label at the top of the stack is the tunnel label, which is used to carry the frame across the provider network. The tunnel label is typically removed by the penultimate hop (i.e., the hop prior to the egress label edge router, LER). The second label at the bottom of the stack is the VC label, which is used by the egress LER to determine how to process the frame and deliver it to the destination network. Thus, in the case of MPLS encapsulation, two labels are necessary (tunnel and VC). As described above, Martini encapsulation enables transportation of layer 2 (Ethernet) frames and thus forms a basic building block of the VPLS. The VPLS supports the connection of multiple customer sites emulating a single bridged domain over a managed IP/MPLS network. Therefore, all the services in a VPLS appear to be on the same LAN regardless of location. Note that Ethernet frames can be transported over most layer 1 transport networks with Martini encapsulation. The edge nodes of any VPLS architecture are responsible for: Ethernet bridging (e.g., MAC address learning and interaction with customer STP) Associating the MAC addresses and VIDs with LSPs and LSP-based MPLS forwarding A decoupled-vpls scheme realizes the two edge node functions in separate entities. Moreover, in order to avoid full mesh connectivity across the edge nodes of the metro domain, a hierarchical VPLS (H-VPLS) scheme comprises a two-tier structure: core and access. The number of nodes in the core tier is typically small, and the nodes are fully connected in a mesh. The nodes in the access tier are the aggregation points for the customer VLAN sites and are in turn connected to the core tier by P2P LSPs, thus avoiding a large number of LSPs in the metro domain. These methods facilitate the realization of a scalable and efficient VPLS [3]. Table 1 summarizes various aspects of the QiQ, MAS, MiM, and MPLS encapsulation schemes. The QiQ scheme addresses VLAN scalability, while the MAS solves MAC address table explosion. It should be noted that MAS per se does not address the customer segregation issue. MiM, a combination of MAS and VLAN stacking schemes, can be implemented to limit the broadcast regions of the corresponding C-VLANs. In the absence of MAS, the standalone QiQ schemes may incur more penalties in terms of MAC address flushing and relearning when the customer ST reconverges. 82

4 Customer frame P-MAC DA P-MAC SA Original MAC DA MAC SA Q-tag Ethertype Data CRC Provider MAC fields (a) of PE1->outgoing PE2->outgoing... Pcore port number port number table of ) outgoing port number ->M4...M7 Pcore1 Pcore2 table of PE2 ) outgoing port number ->M1...M3 PE2 Provider edge switch VLAN1 PE1 Rest of Eth fields M1 M4 PE 1 PE 2 VLAN1 M3 M2 M1 Rest of Eth fields M1 (b) M4 M4 M5 M6 Customer frame M7 Figure 3. a) A provider MAC encapsulated Ethernet frame; b) a typical sequence of encapsulation/decapsulation of user frames. In general, tunneling schemes such as MPLS/MiM do not suffer from MAC table explosion due to the fact that the C-VLAN MAC addresses are learned/managed at the edge nodes. In a rough comparison between MPLS encapsulation and Ethernet extensions, a VC label corresponds to a Q-tag and the tunnel label corresponds to the MAS extensions (SA/DA). A label distribution protocol (LDP) is required to distribute the labels. LSRs are necessary to determine the routes in order to establish the required LSPs. The stacked Q-tag has the same purpose as the MPLS label, but has the advantage that no MPLS control plane needs to be introduced. Moreover, the approaches of VLAN stacking/mas and MPLS are different in the sense that the former relies on self-learning and the latter on routing. From the perspective of signaling overhead, MAS needs no such signaling. An automated version of QiQ might need some signaling between metro nodes; however, the existing IEEE Generic Attribute Registration Protocol (GARP) can be reused with minor extensions. Another interesting aspect is localization of the impact of any erroneous control operation at C-VLAN sites on the provider domain. A C- VLAN with a couple of duplicate end host MAC addresses can impact the metro Ethernet switches in terms of frequent MAC movement across the ports. MAS/MPLS encapsulations shield core Ethernet switches from such duplication as the switching is done based on uniquely assigned outer MAC addresses. Thus, the impact of duplicate MAC addresses is moved to the edge nodes. ISSUES IN CUSTOMER CONTROL PROTOCOLS HANDLING IN THE PROVIDER NETWORK In addition to the encapsulation schemes for transportation of customer data frames, appropriate methods are also necessary for the separation of Ethernet control protocols of the provider and customer networks. Moreover, the Customer frame VC label Tunnel label MAC DA MAC SA VLAN tag Original Ethernet type Data CRC Encapsulation fields Figure 4. MPLS layer 2 encapsulation. 83

5 Attribute MAC address Scalability Priority Transition/ Localization of impact of Signaling Min overhead Encapsulation Table w.r.t. C-VLANs bits Evolution Duplicate Provider ST (Bytes) method containtment MAC control MAS Yes Not applicable No Yes Yes Yes No 12 QiQ No For combination of VIDs: Yes Yes Yes No No Needed 2 For provider VID: No MiM Yes Yes, 16 million Yes Yes Yes Yes Optional 18 MPLS Yes Yes, 16 million Yes Partially Yes Yes Yes 8 Yes (cost) Table 1. Overview of the aspects of the schemes. current IEEE bridge PDUs (BPDUs) and GARP control messages are untagged. In order to distinguish control frames of one C-VLAN from those of another, it may be necessary to encapsulate/tag the customer control messages in the provider domain. This allows for various C-VLAN sites to transparently participate in their relevant layer 2 protocols for proper connectivity and functioning. MULTIHOMED C-VLANS A multihomed C-VLAN site connects to the metro domain via multiple edge nodes. However, only one connection is active at any instance. The customer ST provides loop-free connectivity across all C-VLAN sites. In Fig. 5, we show an example of a dual-homed C-VLAN. In case of a failure in the customer network, the customer bridges may either automatically (via STP reconfiguration) or manually activate the backdoor link in order to provide fast protection. As a result, topology change notifications (TCNs) are generated that lead to flushing of appropriate MAC address tables and relearning of MAC addresses. The provider network may be unaware of these C-VLAN topology changes and still forward frames to the failed customer site until the corresponding MAC addresses age out (on the order of minutes). This leads to an unacceptable recovery time. A possible solution is to detect customer TCNs at the provider edge in order to trigger unlearning in the provider [6]. This establishes the need for coordination between the provider network and various control protocol messages originating from C-VLANs. Furthermore, it is necessary to isolate provider control protocols from customer ones, to prevent the instability of C-VLANs (e.g., erratic behavior of the C-VLAN switches) from affecting the provider network. New Ethertypes and a reserved block of MAC addresses can facilitate such functions and are discussed next. NEW ETHERTYPES AND MULTICAST MAC ADDRESSES FOR PROVIDER BRIDGES In addition to the new fields provided by the encapsulation schemes described earlier, new Ethertypes might be required to distinguish between encapsulated frames in a provider domain from nonencapsulated frames. This can be an additional security measure in case encapsulated frames erroneously flow into C-VLANs. These stray frames would be dropped, as customer bridges do not recognize these new Ethertypes. They can also avoid potential problems arising from manual misconfiguration of provider bridges while processing encapsulated frames. Furthermore, the new Ethertypes allow redefinition of some of the existing fields in the provider encapsulation. Moreover, the current bridge s control protocols use a reserved set of multicast MAC destination addresses (MAC DAs). The customer bridge interfacing the provider network needs to interact with the provider bridges in three modes [7]: Peer mode (e.g., customer OAM may peer with provider bridges) Tunnel mode, in which customer control messages are transparently passed on (e.g., customer STP BPDUs) Discard mode, wherein control frames are dropped (e.g., customer Pause frames) In order to enable such distinct operation modes at the edge nodes, it is necessary to have a different set of reserved multicast MAC DAs from the provider MAC address set. For example, a tunneled customer control frame arriving at the provider egress node shall have the existing MAC DA, whereas a peered customer control frame (or a frame originating at a provider bridge) shall have a MAC DA from the provider MAC address set. It should be noted that the MiM scheme can also facilitate transparent handling of customer control protocols. However, depending on the protocols, appropriate actions may be triggered, thereby providing a richer set of interactions at the provider edge. QUALITY OF SERVICE Several elements such as traffic profiling, bandwidth guarantees, fast protection, and robust OAM tools are necessary to realize adequate QoS in a metro Ethernet. The building blocks of QoS in metro Ethernet can be broadly categorized as: a) traffic management, b) resilience, and c) OAM. Key issues in each of these categories and possible solutions are described next. TRAFFIC MANAGEMENT Currently, Ethernet predominantly carries best effort traffic with no QoS guarantees. The Q-Std defines certain classes of service that are represented by the three p-bits in the Q-tag. However, 84

6 the current IEEE 802.1Q scheme does not incorporate the drop precedence (DP), which is defined in the widely deployed differentiated services (DiffServ) traffic model [8]. In order to support the DiffServ traffic over metro Ethernet, appropriate extensions are necessary to map the p-bits and support the DP. When DiffServ and Q-Std-based CoS mapping schemes coexist in a domain, frame misordering may occur if the DP information in DiffServ-CoS is treated as different Q-Std classes. Thus, there is a need for standard mapping schemes and additional identifier fields. One solution is to redefine the CFI bit in the provider Q-tag in order to correctly implement the DP. In addition to prioritizing the traffic, the following key components are required to realize QoS requirements: Traffic management schemes that include token-bucket-based markers and policers (currently being defined by MEF) [4] Class-based congestion control schemes for realizing relative QoS (the IEEE Pause message can be extended to include CoS information) Furthermore, DP-aware packet dropping and buffer management schemes are also essential for congestion management. Metro Ethernet services require QoS guarantees for both P2P and P2MP EVCs. A customer may contract a certain SLA with a provider that may include, in addition to other parameters, bandwidth guarantees, delay, jitter, and packet loss. A P2P SLA can be characterized as a simple pipe model wherein the traffic guarantee is given between ingress and egress edge nodes. The bandwidth profile for the P2MP can be characterized as a hose model [9]. Mechanisms to realize the pipe model are relatively well understood, and the existing schemes are geared mainly toward P2P services. Therefore, new schemes must be designed for P2MP service guarantees. Multipoint TE is a key issue in efficient resource allocation and load balancing [9]. Admission control is another critical component in realizing the desired QoS for various classes/ services in addition to the TE. It deals with estimation of the available network resources (e.g., bandwidth) and decides, on demand, whether a request for bandwidth from a customer can be satisfied. Extensions to IEEE GARP need to be carried out in order to support such multipoint EVC service in P-VLANs. It should be noted that the VPLS schemes greatly benefit from the advanced features traditionally associated with MPLS such as bandwidth guarantees and TE through appropriate signaling mechanisms (e.g., Resource Reservation Protocol with TE, RSVP- TE, and extensions [10]). Furthermore, C-VLAN grouping can reduce the large state space; thus, resource management schemes can benefit from such grouping in terms of reduced computation. Host x site A Blocked backdoor ports Active primary link A Figure 5. Dual-homed C-VLAN. site B QiQ provider network RESILIENCE AND OAM Protection against link/node failures is a key component of successful realization of metro Ethernet. However, Ethernet was originally designed to provide shared local medium connectivity and mainly geared toward non-realtime data transfer. Accordingly, STP was designed in a manner such that the worst case network diameter is taken into account for setting up the timers for the reconstruction of ST upon failures and is typically on the order of 30 s. Upon a port/link failure, Rapid STP (RSTP) [1] strives to achieve almost instantaneous transition of the appropriate ports to the forwarding state, thereby improving the reconvergence time. The RSTP enhancements over STP include: a) additional port role/state definitions and faster transitions to the forwarding state, b) BPDUs periodically generated by all bridges, and c) more precise detection and rapid propagation of topology changes from the point of failure detection rather than from the root bridge. These techniques allow an RSTP-based bridged network to reduce the recovery time to at most few seconds. Moreover, RSTP reduces the amount of relearning of MAC addresses after a change in the topology. The IEEE 802.1s defines multiple STs (MSTs) [1], so the basic TE rules can be implemented with the alternate paths arising from the MSTs. In terms of protection capabilities, due to the fact that each VLAN is associated with a single ST only, it still lacks the capacity to perform fast protection switching (< 50 ms) by steering the traffic on the fly onto an alternate ST. To overcome these limitations, two additional enhancements can be deployed. The first enhancement requires that frames be augmented with an ST tree identifier; thus, each VLAN can now be associated with more than one ST explicitly. In case of failure, the traffic can now be switched from one to the other on the fly. The second enhancement is to encapsulate the user frames based on the MAS; thus, the link failure does not trigger relearning and VLAN reregistration is avoided. Therefore, these enhancements can realize fast protection on the order of 50 ms. On the other hand, VPLS schemes require knowledge of network topology in order to establish VCs and rely on split horizon techniques to avoid loops [11]. In VPLS-based metro Host y Active primary link B Customer 2 85

7 Protection against link/node failures is a key component of successful realization of Metro-Ethernet. However, Ethernet was originally designed to provide shared local medium connectivity and mainly geared towards non-realtime data transfer. Ethernet, link and node protection of virtual tunnels (VTs) can be implemented by providing preplanned and physically disjoint VTs. By utilizing a preplanned approach, there is no need to recalculate the alternate path when a failure occurs. As a result, fast reroute can be achieved. Three different schemes [12] exist for implementing such a strategy: Path protection Link protection Subpath protection These three schemes differ in terms of response time and resource utilization. OAM is another key component in ensuring that the provider network meets the contracted SLA. The Ethernet OAM protocols should provide the ability to determine the connectivity and measure the round-trip delay and jitter [13]. Furthermore, Ethernet OAM needs to provide mechanisms for alarm notification and performance measurements. Since the existing higherlayer (e.g., IP) OAM schemes are transparent to the Ethernet bridges, a new scalable Ethernet OAM is required to provide the necessary network operation and maintenance functions (e.g., layer 2 ping and traceroute) in the metro Ethernet independently. These OAM functions facilitate collection of the necessary information on routing, delay and QoS along the path. The schemes described earlier for layer 2 protocol handling by the provider network are equally applicable to the emerging Ethernet OAM. It should be noted that VPLS schemes could leverage upon relatively more advanced MPLS-based OAM tools. OAM tools are currently under development at several standard bodies such as IEEE, MEF, and ITU-T, and can provide powerful diagnostic functions to enable QoS in metro Ethernet. CONCLUSIONS Simplicity and scalability are the two key factors that make any technology successful in a MAN providing Ethernet-based VPLS/TLS. In this article, several issues in and approaches to extending Ethernet beyond LANs are discussed. In order to provide TLS, the provider edge nodes should have bridging capability and appropriate encapsulation functions. Furthermore, relevant traffic management functions are necessary to guarantee QoS and meet contracted SLAs. They also need to interact with relevant layer 2 control protocols in order to realize transparent Ethernet services. The VPLS and QiQ schemes are currently popular with standard bodies and switch vendors. While the QoS and SLA guarantees, especially for P2MP EVCs, require certain enhancements to Ethernet, there is a trade-off between the benefits and complexity of these enhancements. Evolving Ethernet OAM tools shall also play a key role in expediting the realization of such metro Ethernet services. Several heterogeneous technologies shall coexist, so interworking among such technologies must be addressed. Providers should be able to take advantage of the unique characteristics of Ethernet and offer value-added metro Ethernet services in the near future. ACKNOWLEDGMENTS The authors would like to thank the reviewers for their comments that helped improve this article. They are also thankful to Ljubisa Tancevski of Alcatel for many stimulating discussions on metro Ethernet. REFERENCES [1] IEEE 802.1D/w/s/ad, IEEE working group(s). [2] L. Martini et al., Encapsulation Methods for Transport of Ethernet Frames over IP/MPLS Networks, work in progress, Feb [3] ITU contrib. WD 14 Q12/15, Service Provider Ethernet Switching, May [4] S. Khandekar et al., Metro Ethernet Network QoS Framework, work in progress, MEF, Nov [5] M. Seaman, Large Scale Q-in-Q Scalable Address Learning, work in progress, IEEE 802.1, Sept [6] G. Chiruvolu et al., Selective Customer TCN Snooping across a Provider Domain, work in progress, IEEE, Mar [7] N. Finn, Provider Bridge Layer 2 Protocols, IEEE 802.1, work in progress, Mar [8] S. Blake et al., An Architecture for Differentiated Service, IETF RFC [9] N. Duffield et al., Resource Management with Hoses: Point-to-cloud Services for Virtual Private Networks, IEEE/ACM TON, Oct. 2002, pp [10] D. Awduche et al., RSVP-TE: Extensions to RSVP for LSP Tunnels, IETF RFC 3209, [11] M. Lassere et al., Virtual Private LAN Services over MPLS, work in progress, IETF, [12] P. Pan et al., Fast Reroute Extensions to RSVP-TE for LSP Tunnels, work in progress, IETF, [13] N. Finn, Bridges and End-to-End OAM, IEEE 802.1, work in progress, Mar BIOGRAPHIES GIRISH CHIRUVOLU (Girish.Chiruvolu@alcatel.com) is a research scientist at Research and Innovation (R&I), Alcatel, and leads a team on metro Ethernet activities in Plano, Texas. He obtained a Ph.D. in computer science from the University of South Florida. His current research interests include metro Ethernet, and modeling and performance evaluation of networks. AN GE [M] (andrew.ge@alcatel.com) is a research scientist in R&I, Alcatel. He received his B.S. and M.S. from Xidian University, Xian, China, and his Ph.D. degree in electrical engineering from the University of Texas at Dallas. His research interests include metro Ethernet, optical packet/ burst switching networks, and traffic engineering in highspeed networks. DAVID ELIE-DIT-COSAQUE (david.elie_dit_cosaque@alcatel. com) has been a research scientist at Alcatel R&I since May His research topics include storage area networks (SAN), Ethernet networks, protection/restoration and optimization of IP over WDM optical networks. Before joining Alcatel, he received his M.S. degree in computer science and telecommunications from ESIGETEL, Avon- Fontainebleau, France, in MAHER ALI [M] (maher.ali@alcatel.com) works in the general area of computer networks with a focus on the design and the control/management of optical and Ethernet-based networks. He considers the impact of transmission impairments on the next-generation optical Internet, and studies survivability and cost analysis issues of core/metro networks. In addition, he works on extending Ethernet technology to the metro and core. He is currently a research scientist at Alcatel R&I, Plano, Texas. JESSY ROUYER (Jessy.Rouyer@alcatel.com) is with Alcatel R&I, Plano, Texas. He holds B.S. and M.S. degrees in computer networks and systems from Université Henri Poincare, Nancy, France. He is currently involved in Ethernet research activities focusing on the Rapid and Multiple Spanning Tree Protocols. His interests also include metro Ethernet, integration of bridging and related protocols, and extensions for carrier-grade operation. 86