Metro Ethernet Networks - A Technical Overview


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Metro Ethernet Networks - A Technical Overview

  1. 1. Metro Ethernet Networks - A Technical Overview Metr Ether etro thernet For orum hitepap epaper A Metro Ethernet Forum Whitepaper July 2002 © Copyright Metro Ethernet Forum 2002
  2. 2. A Metro Ethernet Forum Whitepaper Metro Ethernet Networks A Technical Overview Disclaimer This white paper reflects work in progress within the Metro Ethernet Forum (MEF) and represents a 75% member majority consensus, as voted by the 70+ members in the May, 2002 New Orleans Technical meeting. Some technical details may change in due course (by 75% vote), and it will be updated as necessary to reflect such changes. This paper does not necessarily represent the views of the authors or their commercial affiliations. Summary The target audience for this comprehensive white paper is broad, and includes analysts as well as experienced technologists unfamiliar with Ethernet deployment in the Metro context. The paper presents an overview of key issues pertaining to deployment of Ethernet in the Metro arena, and is structured as follows: • What’s a Metro Ethernet Network (MEN)? Provides a conceptual definition from a topological and service perspective. • Why use Ethernet in the Metro anyway? Presents technological, commercial, and operational justifications. • What are the current limitations of using Ethernet in a Metro Network? Outlines some technical arguments against Metro Ethernet deployment. • What are possible solutions to these limitations? Outlines solutions currently being deployed or under consideration. • The role of the MEF in addressing these limitations. Summarizes the MEF technical committee objectives and scope. • MEF technical work areas as at July, 2002. Summarizes the work items in draft status (i.e., voted) as of this date. • Conclusion.
  3. 3. A Metro Ethernet Forum Whitepaper What is a Metro Ethernet Network (MEN)? Ethernet is a widely deployed technology, renowned for its robustness and cost-effectiveness. Standards- compliant interfaces are available on a plethora of data communication/telecommunication devices at line rates of 10/100/1000 Mbps, and the draft-standard for 10 Gbps has recently been ratified. In Metropolitan Area Networks (MANs), Ethernet has the potential to increase network capacity cost- effectively and offer a wide range of services in a simple, scalable, and flexible manner. An Ethernet-based MAN is generally termed a Metro Ethernet Network (MEN), although some European service providers have also introduced MEN-like technology for Wide Area Networks (WANs). In enterprise networks, Metro Ethernet is used primarily for two purposes: connectivity to the public Internet and connectivity between geographically separate corporate sites — an application that extends the functionality and reachability of corporate networks. Figure 1 illustrates the key areas of interest in a MEN and sets the scene for the balance of this white paper. B A D D C MEN1 MEN2 E F Figure 1: Connecting enterprise MENs A. Links are primarily point-to-point and can be any speed of Ethernet. B. Nodes can be either switches or routers, depending on their location in the MEN, the nature of the services being provisioned, and the level of service resilience (network protection). Nodes are meshed to whatever degree necessary to provide the desired connectivity, services, and protection. C. WAN links connect MENs together across large distances. D. Ethernet services can be topologically classified into point-to-point (as shown in this illustration), multipoint-to-multipoint, or point-to-multipoint. Services are then further classified according to the bandwidth provisioned and used. This bandwidth usage can be exclusive or shared across multiple users. Bandwidth is provisioned on demand from 1 Mbps to 1 Gbps, in increments as fine as 1 Mbps. E. Varying degrees of service resilience are obtained by implementing a combination of network protection techniques. Protection can be end-to-end (as shown in this illustration) or node-to-node. F. Quality of Service (QoS) is realized using a combination of various techniques to provide both ‘hard’ and ‘soft’ bandwidth and packet-loss guarantees. QoS can be end-to-end (as shown in this illustration) or node- to-node. From an enterprise end-customer perspective, QoS is visible as a technical/operational Service Level Specification (SLS), which is underwritten by a commercial Service Level Agreement (SLA). Metro Ethernet Networks — A Technical Overview 2
  4. 4. A Metro Ethernet Forum Whitepaper Why use Ethernet in the Metro anyway? A bottleneck can be created when many corporate networks are connected to a MAN, or interconnected within one. Indeed, the so-called “bandwidth glut” of which analysts often speak is difficult to find in the Metro, where connections are dominated by often inadequate T1/E1, T3/E3, or ATM links. Deploying Gigabit Ethernet-based platforms in Metropolitan areas is a compelling and commercially proven approach to break this bandwidth bottleneck for the following reasons. Cost-effectiveness. Infrastructure equipment costs for Ethernet are significantly less than for Frame Relay (FR) or ATM. This is due both to Ethernet’s relative technical simplicity and the economies of scale from the existing Ethernet installed base that ensure lower material and development costs. Furthermore, these economies have consistently held true over Ethernet’s 20-year lifetime, where the pricing rule of thumb has been “roughly ten times the performance of the preceding generation at about three times the cost.” Provisioning costs (mainly operational and planning related) are also significantly less than for TDM (T1/E1, T3/E3, SONET/SDH). Ethernet’s comparatively effortless adoption and higher available data rates are added bonuses. Rapid provisioning on demand. From a service provider perspective, service velocity is a key competitive differentiator. The present lack of customer-centric flexibility, as well as the coarseness of bandwidth granularity for TDM and ATM legacy systems, are considered major impediments to providing promising, revenue-generating services. The prevalent connection choices today are DS1, DS3, OC-3, etc., and the flexibility and finer granularity required by many IT managers running corporate networks is often simply not available. On the other hand, Ethernet access services offer a wide range of speeds from 1 Mbps to 1 Gbps, in increments of 1 Mbps or less. These rates can be provided quickly and on-demand, possibly even by customers themselves through a web-based tool. Packet-based technology. Ethernet is an asynchronous frame-based technology that has certain flexibility advantages over its more rigid cell-based or synchronous competitors. With suitable rate-limiting functions to manage the available resources, and with sufficiently large trunk capacity, Ethernet can provide rapid bandwidth on demand. Ease of interworking. Removing the interworking issues between different platforms and environments makes service provisioning and activation simpler. Ethernet eliminates a layer of complexity (e.g., ATM and SONET) from WAN access, thus reducing configuration requirements. Ethernet’s plug-and-play feature also enables a simple migration path from low to high speeds. Consequently, integrating and interfacing end- customer IT systems is relatively simple with Ethernet Metro services. Ubiquitous adoption. Ethernet has been the dominant technology in enterprise and campus LANs for many years. Standard interfaces are readily available for 10/100/1000 Mbps Ethernet, and the 10 Gbps Ethernet standard will also follow suit, given its formal IEEE ratification in June, 2002. The implications of this wide deployment extend beyond economies of scale to less obvious benefits. For example, Ethernet is much easier to learn than SONET and ATM technologies, which has an important impact on employee hiring and availability. Many of the above advantages result from Ethernet’s inherent simplicity. However, fundamental laws of conservation apply as well, and these benefits are not without their price. In the next section, the shortcomings of deploying Ethernet in the Metro are discussed. Metro Ethernet Networks — A Technical Overview 3
  5. 5. A Metro Ethernet Forum Whitepaper What are the current limitations of using Ethernet in a Metro Network? When speaking of Ethernet in the Metro, there is a justifiable tendency to draw comparisons with familiar ATM and SONET services. It is important to note that, although Ethernet has certain limitations (outlined below), many incumbent and new-entrant service providers are nevertheless providing Ethernet-based services today on a profitable basis to a wide range of satisfied customers. Furthermore, various workarounds and solutions to many of these limitations are being devised. This section discusses the main advantages provided by legacy ATM/SONET technologies and outlines the potential limitations of using ‘pure’ or ‘native’ Ethernet as a replacement transport medium in the Metro. Some possible solutions to these limitations are described in the following section. End-to-end QoS guarantees. The key words here are ‘end-to-end’, since any intermediate element affects a customer’s perception of service at the end-point. Ethernet’s lack of inherent QoS raises the following questions and issues: • Connection admission for new service requests. On short time scales, can a demand request with a specific QoS requirement be admitted without compromising the service performance of already accepted demands? • Scheduling or policing to maintain fair access. Can fair access to the available bandwidth be ensured at the packet level in the face of competing demands? Can it be guaranteed during times of congestion? • Optimal path establishment through the network. Ethernet’s path establishment via the spanning tree algorithm means non-optimal paths exist, which could introduce packet loss, jitter, and delay. • Packet coloring. Although IEEE 802.1Q specifies three priority bits, Ethernet has no true class of service provision, such as DiffServ, and therefore cannot mark packets for prioritization, scheduling, and policing. Protection mechanisms. Given its origins in the LAN space, Ethernet has limited protection mechanisms in the event of network disruptions, and exhibits constraints such as the following. • Slow failure recovery. Link breaks in an Ethernet environment are handled via the spanning tree algorithm, which can take up to tens of seconds to converge, depending on the size of the network. Compared to SONET’s 50 ms automatic protection switching (APS), Ethernet’s failure recovery time is orders of magnitude too long for voice, video, and other mission-critical applications. • Lack of fault isolation capability. Similarly, Ethernet has no built-in alarms, such as SONET’s Loss of Signal (LOS) and Remote Defect Indicator (RDI), which allow fault isolation to the malfunctioning section, line, or path. In-service performance monitoring and OA&M. Ethernet has no overhead capability to monitor in- service bit error rate (BER). Such capability is particularly useful at service demarcation points, where it is used for loop-back and reachability testing. Scalability and network resource utilization. One of the advantages of Ethernet in an enterprise domain is the ability to logically partition distinct user groups over the same physical network by using the virtual LAN (VLAN) concept. However, scaling VLANs to the Metro, where user groups could potentially be different companies, poses the following challenges: • Limited VLAN tag space. The IEEE 801.Q standard defines an address space of only 4096 available tags. This is insufficient for a large service provider. • Spanning tree issues. A single spanning tree allows only one loop-free path, which can result in uneven load distribution and potential bottlenecks. Multiple spanning trees are under consideration by the IEEE 802.1s working group in an attempt to address this shortcoming. Metro Ethernet Networks — A Technical Overview 4
  6. 6. A Metro Ethernet Forum Whitepaper What are possible solutions to these limitations? It is important to reiterate that Ethernet-based services are already being successfully offered in the Metro, as network equipment manufacturers (NEMs) and service providers find innovative ways around many of Ethernet’s inherent limitations. Because these possible solutions may have various implementations, this section provides only a general description of some proposed solutions for each of the limitations outlined in the previous section. End-to-end QoS guarantees. Currently one of the easiest ways to provide reasonable service guarantees is to over-provision a best-effort service. Although this is may be an attractive solution in some respects, given the economies of Ethernet infrastructure compared to SONET, it is not economically viable as the customer base expands. A promising long-term solution today is Multi-Protocol Label Switching (MPLS), which can provide traffic engineering (TE) capabilities (via the Explicit Route Object), guaranteed bandwidth pipes, and inherent packet coloring (via the EXP bits) seamlessly on Ethernet transport. Protection mechanisms. • Slow failure recovery. Depending on the nature of the data and the terms of the SLA, different degrees of protection may be warranted. Several (possibly co-existent) technologies are being implemented in the industry or proposed in the standards bodies, as outlined below. IEEE 802.1s (Multiple Spanning Trees) is a proposal to allow more than one loop-free path in a VLAN environment. From a protection viewpoint, the benefit is a redundant path at the expense of management complexity. IEEE 802.1w (Rapid Reconfiguration of Spanning Tree) implements a faster convergence algorithm. At a convergence rate of about one second, it may indeed be suitable for certain service classes. However, it still does not approach the SONET-like restoration times of 50 ms, which may be required for other classes of service. IEEE 802.3ad (Link Aggregation) provides sub-second fail-over on trunk groups — an approach with merit in applications where geographic path diversity is required. This technology also has the added benefit of allowing the use of load balancing techniques. IEEE 802.17 (Resilient Packet Ring working group) advocates a ring protection protocol that provides sub-50 ms failover. MPLS offers flexible and scalable solutions through capabilities such as backup LSPs, fast reroute, and LSP preemption. This flexibility paves the way for service providers to sell different levels of protection at different price points. • Lack of fault isolation capability. Currently this aspect is receiving only minimal attention and requires further study. In-service performance monitoring and OA&M. This aspect has also received only minimal attention. Two alternative proposals are under discussion within the IEEE 802.3ah Ethernet in the First Mile (EFM) working group. One proposal suggests use of the Ethernet preamble and the other offers a frame-based approach. Each has relative merits. Scalability and network resource utilization. Some network equipment manufacturers currently supply equipment that increases the available VLAN tag space through various ‘tag-stacking’ schemes. This approach works to a degree, but introduces certain network management and interoperability considerations. For example, what does a non-tag-stacking switch do when it receives stacked frames? Given the limitations of spanning tree implementations, various MPLS techniques currently in draft within the IETF hold the best promise as long-term scalable solutions that maximize network resource utilization. Metro Ethernet Networks — A Technical Overview 5
  7. 7. A Metro Ethernet Forum Whitepaper The role of the MEF in addressing these limitations With the number of initiatives and working groups proposing MEN solutions, it is not surprising that an industry body such as the Metro Ethernet Forum has emerged to provide some alignment among the proponents of the various solutions. The role and current efforts of the MEF is discussed in the following section. As already mentioned, service providers have compelling economic and operational reasons to deploy Ethernet in the Metro, especially when possible solutions exist to address some of the identified technical limitations. The role of the Metro Ethernet Forum is to ensure alignment and technical interoperability among the various implementations currently being used or considered, and to investigate ways to address those limitations receiving minimal or no attention. To facilitate these imperatives, the MEF has structured the technical committee as illustrated in Figure 2 below. Technical Committee Protocols and Architecture Services Management Transport Sub-committee Sub-committee Sub-committee Sub-committee Figure 2: MEF technical committee • Architecture sub-committee. Mandated to develop an architectural reference model and set of common linguistic tools for the technical committee. • Services sub-committee. Mandated to define Ethernet services models, definitions, and service performance metrics. • Protocols and Transport sub-committee. Mandated to define methods, procedures, and protocols to support the defined services. • Management sub-committee. Mandated to develop Metro Ethernet operations, administration, and maintenance (OA&M) requirements, models, and definitions. Note that the MEF is an industry forum, not a standards body. It will draw on work developed in other standards organizations as far as possible, defining its own standards only as a last resort. Metro Ethernet Networks — A Technical Overview 6
  8. 8. A Metro Ethernet Forum Whitepaper MEF technical work areas as at July, 2002 As outlined in the previous section, the technical committee has organized the work areas under four different sub-committees. Considerable progress has been made in reaching consensus, as is evident from many work areas moving to MEF working draft status. This section describes the activities of the four sub-committees. Architecture sub-committee work areas The two architecture work areas that have progressed to MEF working draft status are the layered MEN Architecture Reference Model and MEN UNI Framework. Layered MEN Architecture Reference Model. Illustrated in Figure 3, the MEF Ethernet Architecture Reference Model describes a recursive layered model based on the ITU-T G.805 specification, and allows the functional architecture of a MEN to be specified in a technology-independent way. It specifies three layers applicable for MENs: Transport, Ethernet Services, and Application Services. Application Layer(s) MPLS IP DS1 E1 Other Other App App Trail Trail Trail Trail Trail Trail Trail Trail Term Term Term Term Term Term Term Term Application Functional Element ETH ETH ETH ETH ETH ETH ETH ETH Adp Adp Adp Adp Adp Adp Adp Adp ETH ETH ETH ETH ETH ETH ETH ETH Trail Trail Trail Trail Trail Trail Trail Trail ETH Layer Term Term Term Term Term Term Term Term ETH Functional Element Eth PHY LOVC HOVC ATM MPLS ODUk MPLS Other Adp Adp Adp Adp Adp Adp Adp Adp Transport Layer(s) Eth PHY LOVC HOVC ATM VC MPLS ODUk MPLS Other Trail Trail Trail Trail Trail Trail Trail Trail Term Term Term Term Term Term Term Term Transport Functional Element Figure 3: Layered MEN Architecture Reference Model • Transport. There may be multiple transport layers for Ethernet Services layer; e.g., IEEE 802.3 PHY, SDH, ATM VC, OTN ODUk, MPLS VC, etc. These transport layers may be carried over other transport layers; e.g., SDH STM-N Multiplex Section, ATM VP, OTN OTUk, MPLS, IP, etc. This downwards stack continues until the medium (fiber, copper, coax, wireless) is reached. • Ethernet Services. This is a single-layer network known as the Ethernet MAC (ETH) layer network. • Application Services. Many application service layers are supported by the Ethernet services layer (MPLS, IP, PDH DS1, 2 Mbps, etc.) These application service layers may support other application service layers, with this upward stack continuing until the user application service layer (e.g., voice, data, video) is reached. Metro Ethernet Networks — A Technical Overview 7
  9. 9. A Metro Ethernet Forum Whitepaper The Layered MEN Architecture Reference Model also introduces several building blocks that can be used to represent a MEN and its services. Each layer can be decomposed and represented using the three functional elements of Adaptation, Connection, and Termination. • Adaptation. Represents the conversion process between server and client layers. One or more processes may be present in an adaptation function, such as encapsulation, multiplexing/demultiplexing, rate adaption, etc. • Connection. Provides flexibility within a layer. May be used to offer routing, grooming, protection, and restoration, as well as connectivity between the inputs and outputs. For example, at the Ethernet Service layer, the connection function could be an 802.1 repeater or 802.1D bridge. • Termination. Performs the integrity supervision of the layer, including connectivity supervision, continuity supervision, insertion or extraction of layer-specific information, and processing of maintenance information. MEN UNI Framework. This work area provides a framework and functional model describing how the UNI reference point will function in a MEN. (The UNI reference point demarcates the MEN boundary, or point to which a user connects.) The UNI Functional Model consists of three planes, illustrated in Figure 4. UNI Data Plane UNI Control Plane UNI Management Plane QoS management Ethernet frame flow Static service discovery OAM 802.1Q tagging Dynamic connection setup Protection & restoration Provisioning Figure 4: UNI Functional Model • Data plane. Defines how information is transported across the reference point. • Control plane. Defines how users and MEN providers utilize the data plane. • Management plane. Controls the operation of the UNI data and control planes. The UNI Framework complements the Architecture Reference model, and together they provide a common set of MEN linguistic tools. Metro Ethernet Networks — A Technical Overview 8
  10. 10. A Metro Ethernet Forum Whitepaper Services sub-committee work areas One of the primary priorities of the MEF is to define Ethernet services for Metro transport networks. To this end, the Services sub-committee has also made significant progress moving three work areas to MEF working draft status, specifically, the Ethernet Services Model, Metro Ethernet Service Definitions, and Bandwidth Profile Parameters work areas. Ethernet Service Model. The Ethernet Service Model document specifies a model to build precise technical descriptions of Ethernet services that can be offered in a MEN. Such a model provides important benefits. It will promote the availability of common services, independent of the MEN involved, which greatly simplifies the work required by an end customer to connect to the network and use the services. The model will also facilitate implementation of customer equipment, such as routers, so they can access the services with a high probability of success. The document also specifies an Ethernet service framework that provides the definitions and relationships between the attributes and associated parameters that are used to create an Ethernet service. Illustrated in Figure 5, Ethernet services comprise one Ethernet Service Type, one or more Ethernet Service Attributes, and one or more parameters associated with each Ethernet Service Attribute. Ethernet Ethernet Service Ethernet Service Type Service Attribute Attribute Parameter Figure 5: Ethernet Service Characterization Metro Ethernet Service Definitions. The Metro Ethernet Services Definitions document proposes a phased approach to Ethernet service definitions in a MEF and specifies the building blocks of Ethernet services (i.e., connection types and attributes). Because these building blocks have different possible permutations, a large number of services is allowed. In practice, however, it is desirable to select services that meet the needs of the customers in a MEN. Three Ethernet service types specified in the document are as follows. • EVPL — Ethernet Virtual Private Line Service. A class of point-to-point connectivity service that provides an Ethernet connection between two UNIs. The service may include a configured Committed Information Rate (CIR), Peak Information Rate (PIR), and Maximum Burst Size (MBS) as part of the UNI bandwidth profile. • EPLn — Ethernet Private LAN Service. A class of multipoint connectivity service that provides an Ethernet connection between two or more UNIs. The service may include a configured CIR, PIR, and MBS as part of the UNI bandwidth profile. • CES — Ethernet Circuit Emulation Service. Provides TDM circuit emulation to support TDM traffic, such as T1/E1, T3/E3, and OC-3, OC-12, etc. The CES is based on point-to-point connection between Interworking Functions (IWF). Metro Ethernet Networks — A Technical Overview 9
  11. 11. A Metro Ethernet Forum Whitepaper Bandwidth Profile Parameters. This work item specifies the bandwidth profile parameters to be used for Ethernet Service definitions. These proposed parameters include the following. • CIR — Committed Information Rate. The amount of bandwidth guaranteed for an Ethernet service. The specified CIR is the guaranteed rate that the network shall deliver under normal conditions to the service. • PIR— Peak Information Rate. The maximum rate at which service traffic can egress the service queue on the Provider Edge (PE) device. The specified PIR is the rate at which service traffic will be allowed to egress the network element, and must be equal to or greater than the CIR. • MBS — Maximum Burst Size. The maximum amount of buffering allocated to the PE device for the service. Service traffic offered over the PIR is buffered up to the specified MBS. The MBS may be expressed in units of bytes, kilobytes, or megabytes. Referring to Figure 5, EVPL, EPLn, and CES are service types; bandwidth is an attribute; and CIR, PIR, and MBS are parameters of this attribute. Protocols & Transport sub-committee work areas The work areas under the Protocol and Transport sub-committee that have progressed to MEF working draft status are Protection Requirements, Protection Framework, and QoS Framework. Protection Requirements. The Protection Requirements document describes a set of requirements for providing protection schemes in MENs. The scope of these requirements includes protection control and signaling, QoS during protection, interaction of such mechanisms with transport, and application-specific protection mechanisms Protection Framework. The Protection Framework document specifies a layered protection model that makes provision for both existing transport protection mechanisms and evolving MPLS protection mechanisms to realize a unified protection approach. This model is illustrated in Figure 6 below. Application Protection Constraint Policy End-to-End Aggregated Line Path Protection and Node Protection MEF Protection Mechanism Topology Transport Figure 6: Protection Model • Transport Layer. Enables reliable transfer of data between MEF network elements by providing error checking mechanisms and data flow controls. The model leverages any native mechanisms that the transport technology uses to provide protection — for example, SONET protection switching. • Topology. A MEN may consist of many sub-network topologies (full mesh, ring, hub-and-spoke, etc.). The model leverages the use of any native protection mechanisms that the topology offers, such as SONET UPSR/BLSR ring networks. Metro Ethernet Networks — A Technical Overview 10
  12. 12. A Metro Ethernet Forum Whitepaper • MEF Protection Mechanism. Two styles of transport network protection services are currently under consideration in this layer: Aggregated Line and Node Protection (ALNP) service and End-to-end Path Protection (EEPP) service. The ALNP layer provides protection against local link and nodal failure by using local path detour mechanisms. In this case, local ‘backup’ or ‘detour’ paths are created along the primary path that bypass the immediate downstream network element or logical link, then immediately merge back to the primary path. Protection with short reaction times is possible with ALNP because failure events can be instantaneously detected without long, end-to-end feedback loops. The EEPP provides a redundant end-to-end path for the primary path, and can be used to augment the ALNP layer. • Application Protection Constraint Policy (APCP). Allows applications (i.e., the service using the protection layer) to specify the protection constraints, such as level of protection, protection reaction time, and protection time QoS, that are reflected in the protection policy used in a MEN. QoS Framework. The QoS Framework document examines the underlying QoS mechanisms for MENs, such as DiffServ, IntServ, MPLS, 802.1Q/p, and network traffic engineering extensions. It also defines a QoS model to successfully deliver Service Level Agreements (SLAs) based on the functions and features required to enforce and maintain such an SLA. This model is illustrated in Figure 7. Objective Functions Sub-Functions Admission Control QoS Policy Management Directory and Policy Services QoS Signaling QoS Reservation Service Level Agreement QoS Routing Constraint-Based Routing Layer 4 Classification Classification Layer 3 Classification Layer 2 Classification Layer 3 Marking Marking Layer 2 Marking Shaping Bandwidth Control Policing Layer 4 Flow Control Congestion Avoidance Layer 2 Flow Control Selective Discard Congestion Control Queue Scheduling Queue Buffers Queues Figure 7: QoS Functional Model Metro Ethernet Networks — A Technical Overview 11
  13. 13. A Metro Ethernet Forum Whitepaper • Congestion Control. Controls how packets will be stored and managed on a given outgoing link when contention for the available bandwidth occurs. • Congestion Avoidance. Techniques to feed network congestion information back to traffic sources. This allows the sources to slow down, and eventually results in the removal of congestion from the network. • Bandwidth Control. Allows the limiting and shaping of bandwidth. • Marking. Indicates specific classifications to be performed on packets. • Classification. Identifies traffic via a field or attribute, classifying it so that a policy-based action can be applied (e.g., queuing, marking, policing, shaping, or filtering). • QoS Routing. Assists in the implementation of SLAs in the network by controlling the path taken by specific flows through the network and avoiding congestion where possible — a process typically called traffic engineering. MPLS is a key technology in realizing QoS routing. • QoS Signaling. Allows information on the needed QoS level to be propagated from an ingress device to an egress device so that it can be applied to the entire network infrastructure. • QoS Policy Management. An umbrella layer that validates and approves all requested QoS services. Management sub-committee work areas This sub-committee is addressing specifically identified OAM&P issues in MENs. Work areas that have moved to draft status are Element Management System (EMS) Requirements, EMS-NMS (Network Management System) Interface Model, and End-to-end OAM Requirements and Framework. EMS Requirements. The EMS Requirements document specifies requirements to be met by a MEN Element Management System (EMS) that will be deployed by MEN service providers. Instead of the more traditional requirements style, these requirements have been presented with representative use cases. General system use cases are augmented by configuration, fault, performance, security, and accounting management use cases. EMS-NMS Interface Model. The EMS-NMS Interface Model document defines a protocol-neutral (and thus vendor-independent) model for information exchange between a service provider’s MEN and the MEN EMS. The model proposes a set of relationship diagrams in Unified Modeling Language (UML) format and associated managed object descriptions. This approach allows an open multi-supplier environment, where MEN Network Elements (NEs) can be readily integrated into existing operational NMSs. The functional areas of MEN network management addressed by this document include transport network configuration provisioning, transport network connection management, network fault management, and network performance management. End-to-end OAM Requirements and Framework. The End-to-end OAM Requirements and Framework document specifies requirements and a framework for end-to-end Ethernet services OAM. The framework is based on a layered model, where Ethernet services can be offered over a tunneling layer, which itself could exist over a transport layer. For example, Ethernet service can be offered over MPLS tunnels running over an ATM network. The focus of this document is OAM functionality within the Ethernet Service Layer, such that the functionality is independent of underlying tunneling and/or transports. Such a framework allows significant flexibility in providing Ethernet services using different technologies, without compromising troubleshooting and monitoring capabilities. The OAM capabilities of each layer can augment each other and provide more fine-grained troubleshooting and monitoring capabilities. Metro Ethernet Networks — A Technical Overview 12
  14. 14. A Metro Ethernet Forum Whitepaper Conclusion The MEF has clearly targeted the limitations of Ethernet as a carrier-class service technology and is addressing them in a coherent fashion. This is accomplished by making use of existing technologies wherever possible and defining new approaches only when necessary. This white paper is the first in a series that will ultimately expose greater details of most of the working documents identified here. It is the task of the MEF marketing committee to expose the MEF work to the larger public through such white papers and other means. The ultimate intention (as per the MEF mission statement) is to education the market, thereby accelerating the adoption of optical Ethernet as the technology of choice in Metro networks worldwide. Acknowledgements This paper has drawn upon a large number of contributions presented to the MEF technical committee, and the efforts of the respective authors, reviewers, and technical writers are acknowledged. Authors Mark Whalley Dinesh Mohan Tove Madsen Loa Anderson Agilent Technologies Nortel Networks Utfors Utfors Australia Canada Sweden Sweden Glossary ALNP Aggregated Line and Node Protection APCP Application Protection Constraint Policy ATM Asynchronous Transfer Mode BLSR Bidirectional Line Switched Ring CES Circuit Emulation Services CIR Committed Information Rate EEPP End-to-end Path Protection EFM Ethernet in the First Mile EMS Element Management System EVPL Ethernet Virtual Private Line (Service) EPLn Ethernet Private LAN (Service) Metro Ethernet Networks — A Technical Overview 13
  15. 15. A Metro Ethernet Forum Whitepaper IETF Internet Engineering Task Force IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol IWF Interworking Functions LAN Local Area Network LOS Loss of Signal LSP Label Switched Path MAC Media Access Control MAN Metropolitan Area Network MBS Maximum Burst Size MEF Metro Ethernet Forum MEN Metro Ethernet Network MPLS Multi-Protocol Label Switching NE Network Element NEM Network Equipment Manufacturer OAM Operations, Administration and Maintenance OAM&P Operations, Administration, Maintenance and Provisioning OTN Optical Transport Network OTUk Optical Channel Transport Unit of level k PDH Plesiochronous Digital Hierarchy PE Provider Edge PIR Peak Information Rate QoS Quality of Service RDI Remote Defect Indicator Metro Ethernet Networks — A Technical Overview 14
  16. 16. A Metro Ethernet Forum Whitepaper RPR Resilient Packet Ring SDH Synchronous Digital Hierarchy SLA Service Level Agreement SLS Service Level Specification SONET Synchronous Optical Network UPSR Unidirectional Path Switched Ring UML Unified Modelling Language UNI User-Network Interface VC Virtual Channel VLAN Virtual LAN WAN Wide Area Network Copyright 2002 © Metro Ethernet Forum 15