Metro Ethernet Quality of Services - Semantic Scholar · 2015-07-28 · Metro Ethernet Quality of...

Metro Ethernet Quality of Services

T E C H N O L O G Y W H I T E P A P E R

We describe steps required for realizing QoS

for the metro Ethernet services, including

classification of Customer-VLAN (C-VLAN) traffic,

relevant traffic contract specifications per C-

VLAN at the User to Network Interface (UNI),

appropriate buffer management and scheduling

of the queues at the nodes, and admission

control and traffic engineering geared towards

multipoint services. General functional

requirements such as provider edge

classification, mapping of traffic management

fields, scheduling, shaping, buffer management,

congestion control, and performance monitoring

and OAM are also addressed.

A framework for quality of services in metro Ethernet networks: the essential functional blocks and handling of packets in the core and at the provider and customer edges.

B. Raahemi, G. Chiruvolu, A. Ge, M. Ali

METRO ETHERNET QUALITY OF SERVICES

2 | Alcatel Telecommunications Review - 4th Quarter 2004

Introduction Following the dominance of Ethernet in local area,

campus and enterprise networks, efforts are underway inthe Institute of Electrical and Electronics Engineers(IEEE), the Metro Ethernet Forum (MEF), and theInternational Telecommunications Union (ITU) to extendEthernet into metro networks. Service providers arealready starting to deploy scalable, cost-effective value-added metro services. Although Ethernet technology nowsupports different traffic priorities (voice, video, data) inenterprise networks, the major challenge for deployingthis technology in metro networks and Wide AreaNetworks (WAN) is to guarantee the Quality of Services(QoS). Other challenges include scalability (Ethernet flataddressing), traffic engineering(load balancing), reliability, andOperations, Administration andMaintenance (OAM) features.

A number of basic buildingblocks are required to guaranteeQoS in metro Ethernet networks,including provider edgeclassification, mapping of trafficmanagement fields, scheduling,shaping, buffer management,congestion control, andperformance monitoring and OAM.

Network ScenariosSeveral architectures can be used

to carry Ethernet frames acrossmetro networks:

• Using Multi Protocol Label

Switching (MPLS) as thetransport technology in themetro network.

• Extending the native

Ethernet protocol, currentlyunder consideration in IEEE802.1 [1].

• Transporting Ethernet using Synchronous

Optical NETwork / Synchronous Digital

Hierarchy (SONET/SDH) via Generic FramingProcedure (GFP) encapsulation and Link CapacityAdjustment Scheme (LCAS) rate adaptation at theedge of the transport network.

• Using generalized MPLS to control Ethernetswitches in the metro network.

The first two are the focus of this article.

MPLS metro networksAs illustrated in Figure 1, the metro network comprises

Provider Edge (PE) routers, Label Switching Routers

PE

PE

PE

CE-B

CE-A

CE-C

LSP2 LSP3

LSP1

LSR2

LSR1

LSR3

UNI-A

UNI-C

UNI-B

Metro EthernetNetwork

Frame Format

TunnelLabel

VCLabel

MACDA

MACDA

VLANTag

EthType Data CRC

Fig. 1 Network scenario 1: MPLS metro network

CRC: Cyclic Redundancy CheckDA: Destination AddressSA: Source Address

(LSR) and Label Switched Paths(LSP) between the two PE routers.The PEs are connected to CustomerEquipment (CE) via the User toNetwork Interface (UNI).

In this scenario, MPLS layer 2encapsulation (also known asMartini encapsulation) facilitatesthe transportation of layer 2 framesacross an MPLS service providerdomain [2,3]. Two MPLS labels areinserted into the customer Ethernetframes based on destination MediaAccess Control (MAC) address/port/802.1Q information at theingress nodes. The first label at thetop of the stack is the tunnel label,which is used to carry the frameacross the provider network. Thecore LSRs only look at the top labelto switch the labeled frame acrossthe MPLS domain. The top tunnellabel is typically removed by thepenultimate hop, that is, the hopbefore the egress Label EdgeRouter (LER). The second label atthe bottom of the stack is theVirtual Circuit (VC) label, which isused by the egress LER todetermine how to process the frameand where to deliver it on thedestination network. The egressLER infers from the VC label how toprocess the frame and thenforwards it to the appropriateoutgoing port. As the VC label isnot visible until the frame reachesthe egress LER because of theMPLS tunneling hierarchy, both thetunnel and VC labels are required inthe case of MPLS encapsulation.

Provider bridged networksThis scenario, which is an extension of the native

Ethernet protocol into metro networks, is currently beingconsidered in IEEE 802.1 [1]. As shown in Figure 2, themetro network comprises Ethernet switches/bridges. Aspanning tree protocol is used to establish a path betweenthe PEs for each customer Virtual Local Area Network(VLAN). An encapsulation scheme, such as Q-in-Q (VLANstacking) or Mac-in-Mac [4], is used to transport customertraffic across the metro domain.

Metro Ethernet ServicesThe MEF has defined a number of new metro Ethernet

services based on the network architecture of Figure 3

[5]. The customer equipment is connected to the metroEthernet network via its Ethernet port. This UNI acts asthe physical demarcation point between the serviceprovider and subscriber domains. Inside metro networks,the connectivity between UNIs is provided by an EthernetVirtual Connection (EVC). A transport layer, such asSDH, Ethernet, MPLS or Asynchronous Transfer Mode(ATM), provides this virtual connection. From thecustomer’s viewpoint, the metro network looks like anEthernet wire.

E-Line and E-LAN servicesTwo types of services are defined based on the

network connectivity: Ethernet Line (E-Line) andEthernet LAN (E-LAN) services [6]. The E-Line


Alcatel Telecommunications Review - 4th Quarter 2004 | 3

PE

PE

PE

CE-B

CE-A

CE-C

CES

CES

CES

UNI-A

UNI-C

UNI-B

MetroEthernetNetwork

MetroEthernetNetwork

Frame Format

Spanning Tree

MACDA

MACSA

Eth. Type0x8100

1Q p-VLAN

ID(3 bits)

CFI(1 bit)

VLAN ID(12 bits)

1Q EthType

VLANTag

Orig.Eth. Type Data CRC

Fig. 2 Network scenario 2: Provider bridged network

CES: Core Ethernet Switch / BridgeCFI: Canonical Format IndicatorID: IDentifierP-VLAN: Provider VLAN

PE CECE

UNI UNIPoint-to-Point EVC

Metro EthernetNetwork PE

Fig. 3 E-Line service type using point-to-point EVC

service, which provides a point-to-point EVC betweentwo UNIs, can be used to create a broad range of point-to-point services, such as Ethernet Private Line (EPL)services and Ethernet Virtual Private Line (EVPL)services. There are more sophisticated forms of E-Lineservice [6].

Service multiplexing of more than one EVC mayoccur at none, one or both of the UNIs. Figure 4 showsan example of the EVPL service in which one physicalport at customer A (UNI A) supports connectivity fortwo Ethernet services. Some service frames may besent to EVC1 (Customer B) while other service framesmay be sent to EVC2 (Customer C).

To connect three or more sites, the subscriber coulduse the E-LAN service for which the carrier networkperforms switching/bridging functions. Figure 5

illustrates LAN extension using an E-LAN service. Theedge nodes perform a bridging/switching function, while aspanning tree protocol is used to prevent loops in theprovider network.

Essential Building Blocks for Metro Ethernet QoS

Quality of service is an important aspect of Ethernetservices. Ethernet traffic is carried over an EVC, whichmight use a tunneling technology, such as MPLS or Q-in-Q, with the tunnels being set up a priori or on-demand. Therefore, the QoS requirements should bemet separately for the tunnels and the traffic that isbeing carried through these tunnels. Depending on thenetwork design, the tunnel QoS requirements can differbetween E-Line and E-LAN services. It is assumed thatthe QoS requirements for the tunnels and specificationare met separately from the customer traffic. Based on

[7], this article elaborates on theminimum set of functions requiredto support QoS in metro Ethernetnetworks.

Several steps need to be taken torealize QoS for Ethernet services,including: classification ofCustomer VLAN (C-VLAN) traffic;specification of suitable trafficcontracts per C-VLAN at the UNI;buffer management and schedulingof the queues at the nodes; andadmission control and trafficengineering geared towardsmultipoint services.

Provider edge classification Several C-VLAN configurations

are possible, depending on thetype and logical grouping of end-stations. Grouping of users can bebased on MAC addresses, IPsubnets and other criteria todetermine the C-VLANmembership. In metro Ethernets,the CE assigns the C-VLANIDentifiers (VID). The PE usesthese VIDs to determine to whichEVC the frame belongs. In turn,the EVC is determined by thestacked Q-tag VID in the case ofprovider bridges or by the tunnellabel in the case of Virtual PrivateLAN Service (VPLS) schemeswhich are based on Ethernet overMPLS (EoMPLS). In the EoMPLS

case, the Class of Service (CoS) and any otherattributes are inferred either from the label itself, orexplicitly from the EXPerimental (EXP) bits within theMPLS label. The incoming frames at the UNI areclassified at the provider edge and are thus mapped/encapsulated appropriately and transported across theappropriate EVCs.



PE

CE-B

CE-A

UNI-A

UNI-BEVC1

EVC2


PE

CE-C

UNI-C

PE

Fig. 4 EVPL service using E-Line service type

CE-B

CE-A

UNI-A

UNI-B

EVC1


Edge Bridge

Edge Bridge

EdgeBridge

CE-C

UNI-C

PE

Fig. 5 LAN extension using an E-LAN service

Ingress mapping of traffic management fields In the MPLS-based core network scenario, the edge

node maps the customer traffic (e.g. learned MACaddresses / VIDs, ports) onto an LSP that has been pre-established by the MPLS forwarder; this facilitates thetransport of the (Martini) encapsulated frames across themetro domain. Label Distribution Protocol (LDP)signaling is required to distribute the labels, while LSRsare needed to determine the routes in order to establishthe required LSPs.

In the provider bridge network scenario, the stacked.1q tag has the same function as the MPLS label (i.e.enabling the segregation of more than 4096customers). Each scheme has its own advantages anddisadvantages [4]. The ingress provider edge mayconsider the user priority (.1p field) [1] of the VLANtag header in order to determine the QoS field of theouter label of the LSP (e.g. the EXP fields of the MPLSlabel stack). Note that the customer QoS markings mayor may not be used to determine the outer QoS bits ofthe provider tag. Several such mappings are possible;the mappings should provide appropriate qualities ofservice for the various 802.1d classes of service [2]. Inthe case of provider bridge networks, the .1pinformation should be appropriately carried in the .1qtag. These methods provide appropriate CoS mappingsonto the EVCs; the EVC classification identifier is usedto map the EXP field.

The IEEE 802.1ad group is currently defining therelevant drop precedence and mapping for backwardcompatibility. Encoding drop precedence into p-bits(Ethernet VLAN priority bits) could ensure a morerobust QoS and flexible bandwidth profile in the ServiceLevel Agreement (SLA). Alcatel has presented aproposal to the MEF for a default mapping with twooptions (using 3 or 4 queues). Table 1 shows such adefault mapping using three queues and three classes ofservices. A default mapping maximizes the plug-and-playaspect of Ethernet and its backward compatibility withIEEE 802.1d switches.

Egress mapping of traffic management fieldsIn this article it is assumed that the traffic management

functions are uniquely mapped and understood amongthe customer sites. With this assumption, generally nospecial egress mapping function is needed as the coreconfigured tunnels terminate at the provider edge and,depending on what device is used at the customerpremises [Customer Equipment / Customer LocatedEquipment (CLE) / Multi-Tenant Unit (MTU), etc], inprovider bridge networks user traffic to the customer iscarried either directly or via the inner tunnel (e.g. Martinior MPLS label) that already has the traffic managementfields as marked by the source. It should be noted that ifthe CE-VID is not preserved across the metro domain, theegress node restores the original customer VIDs asnegotiated during the setup phase. Similar functions arerequired with respect to CoS.

Traffic contractsTraffic contracts for services need to be specified per-

UNI, per-EVC and per-CoS. A combination of profiles canbe specified. The traffic contract for an EVC of an E-Lineservice is specified as ingress/egress bandwidth profiles.The bandwidth profile can be specified using the MEFspecification [8] or the Internet Engineering Task Force(IETF) specification [9,10]. Frames are marked withappropriate colors indicating the priorities with the helpof “Token Bucket” [8]. Nodes in the network performdifferent congestion control schemes (e.g. WeightedRandom Early Detection; WRED) for various trafficcolors. Re-mark assumes that the service is color-awarefor the user traffic and recognizes user traffic colormarking, whereas in the case of mark it is color-blind.

Traffic shaping depends on the capability of theequipment and need not be compulsory. It can beperformed at the network ingress, where it is used for“soft policing”. Alternatively, shaping can be performed atthe network egress towards the customer; it can be usedwhen multiplexed traffic from various EVCs (e.g. E-LANservice) exceeds the customer’s egress traffic profile.

Generally, two service models can be deployed for amultipoint service: pipe model and hose model. In thepipe model, the service contract and bandwidth profilespecification relate to each pair of communicating sites;point-to-point EVCs are set up for this purpose.

In the hose model, the bandwidth profile is specified asa whole between the customer site and the network. Thetraffic distribution between each pair of communicatingsites is not specified. This model eases the bandwidthprofile specification, but complicates network design andresource allocation within the network. Therefore, for anE-LAN service, the traffic contract specification dependson the service model. In both cases, the bandwidth profile(per-hose or per-pipe) and the treatment of bandwidthprofile violations must be included in the traffic contracts.



Forwarding class name

CoS + drop precedence identifier value

802.1d recommendemapping (3 queues)

p-bits

premium 7 7

ControlLoad

BestEffort

Voice111

gold

6 6110

standard

5 (Green color) 51014 (Yellow color) 4100

3 30110 00002 20101 1001

Tab. 1 Possible default mapping of drop precedenceand class of services into p-bits using threequeues

Ingress traffic controlAs discussed earlier, a service model associated with a

given service (E-Line or E-LAN) binds a traffic contract tothe network. The network operator may use traffic policersto check for violations in service contracts. Depending onthe traffic contract parameters, a single rate Three ColorMarker (srTCM) [9] or a two rate Three Color Marker(trTCM) [10] can be employed for the IETF specification. Inthe case of the MEF specification, a simple token bucketbased rate/burst profiler can identify conformant and non-conformant traffic [8]. The traffic policer checks forbandwidth profile violations and takes appropriate action inaccordance with the service contract. Possible actions are:drop traffic that violates the traffic contract, mark trafficwith a color of lower precedence if the network usesdifferent colors to identify different traffic priorityprecedence in a non-color-aware mode, or remark thetraffic with a color of lower precedence if the user traffic isalready colored and the traffic contract specifies that theuser coloring scheme should be recognized.

If the network equipment can shape the traffic into thenetwork, the traffic contract can also specify the shapingoption.

SchedulingTraffic belonging to multiple classes needs to be

appropriately scheduled onto the network links in order tomeet the required service guarantees. The networkequipment must be capable of supporting various trafficscheduling schemes, such as Strict Priority, WeightedRound Robin (WRR) and Weighted Fair Queuing (WFQ), toaccommodate the service guarantees. Generally, a servicethat requires strict delay guarantees is scheduled with thehighest priority. If the scheduler only implements a WFQ orWRR scheme, then the service is given the largest possibleweight. All other services are given appropriate weights inline with the traffic contract. For example, the weights canbe set proportional to the sum of the equivalent bandwidthsof all the services being transported by that particulartraffic class, where the equivalent bandwidth is computedbased on the ingress bandwidth profiles. Alternatively, theweights among the traffic classes are configured a priori inthe network and admission control ensures that theadmitted traffic is within the allocated bandwidth limits fora given traffic class. Irrespective of the admission controlscheme, nodes should include a weighted scheduler thatdifferentiates queues and schedules the traffic based on thepriority/traffic class.

In some scenarios, more flexible scheduling is required atthe service ingress and/or service egress. The Alcatel 7750Service Router and Alcatel 7670 Switch/Router supporthierarchical scheduling whereby a parent scheduler canbe created for a bundle of service queues (say gold, silver

and bronze services) that limits the overall rate of all thequeues. Customers are able to send in any combination ofgold, silver and bronze traffic conforming to their specified

Peak Information Rate (PIR) values that does not exceedthe maximum PIR for the three services.

Buffer management and congestion controlBuffer management schemes address the issues of

transient congestion and priority-based preferential packetdropping in order to achieve relative QoS. These functionsdiffer between the core and edge nodes. At the edge nodes,IEEE 802.3x Pause [11] can be deployed to alleviatecongestion. Alternatively, preferential packet drop can bedeployed utilizing p-bits or EXP bits in the tags.

In the core, packet-dropping mechanisms, such as WRED,can alleviate/avoid network congestion. At the edge, theIEEE 802.3x Pause control can be useful as a congestionavoidance mechanism in VLAN services or when the ingressPE cannot process the frames arriving at the UNI at wirespeed. In 802.3x, the input buffer is constantly monitored atan Ethernet interface; when the packets/frames in thebuffer exceed a certain threshold value (i.e. congestion isdetected), the congested node sends a pause message tothe upstream node. Upon receiving the pause message, theupstream node stops transmitting packets for the durationindicated in the pause message. An extension of 802.3x,namely DiffPause [12], is proposed to provide fair, scalableand color-aware congestion control in metro Ethernet. Thescheme takes advantage of a per-link based backpressuremechanism without any bandwidth reservation; it isindependent of the number of ongoing individual sessions

Egress traffic shapingDepending upon the routing and traffic patterns, when

multiple EVCs terminate at a UNI, the total egress traffictowards the customer may exceed the egress traffic profile.In this case, the edge node may have to perform per-UNIcongestion control. Traffic can be limited either bypolicing/dropping or by shaping using buffers at an egressnode. Shaping may require large buffers (and buffermanagement schemes) in contrast to policing/dropping.However, shaping can reduce both frame loss and trafficburstiness. Profiling can be per class of service, per C-VLAN, or per aggregated bundle (group of C-VLANs).

Network traffic engineeringMultipoint traffic engineering is a key issue for efficient

resource allocation and load balancing in the metro Ethernet[13]. Each C-VLAN can access the metro domain via multiplePE nodes through pre-established multipoint EVCs. Inaddition, multiple spanning trees can provide alternateroutes for C-VLANs across the provider network.Furthermore, C-VLAN grouping makes it possible to supporta large number of C-VLANs in the provider network.Multipoint traffic engineering schemes can benefit from suchgrouping schemes in terms of reduced computation.

SLAs with the customers are translated into resourceallocation requirements. Appropriate signaling mechanismsshould be devised to meet the QoS for multipoint EVC



services. For example, the IEEEGeneral Address Registry Protocol(GARP) needs to be extended tosupport multipoint EVC services inthe case of provider bridges; eitherResource Reservation Protocol(RSVP) or LDP signaling can beused for the MPLS domain. It shouldbe noted that VPLS schemes greatlybenefit from the advanced featuresthat are traditionally associated withMPLS, such as bandwidthguarantees and traffic engineeringthrough appropriate signalingmechanisms, such as RSVP – TrafficEngineering [14].

Admission controlAdmission control is another

critical component for realizing thedesired QoS for various classes/services. It estimates the availablenetwork resources (such asbandwidth) and decides on-demandwhether a customer’s request forbandwidth can be met. In MPLS-based core networks, nodes reservethe necessary resources throughsignaling. Provisioning of newservices will be based on theavailable network resources;attempts to set up a new EVC setup may be rejected ifthere are insufficient resources.

In the case of provider bridge networks, a networkmanagement system with bandwidth broker typefunctionality may be needed to admit / reject theprovisioning of new services. As described earlier, customertraffic can be aggregated into service provider tunnels, inwhich case a hierarchical admission control function isneeded: a first level checks the bandwidth requirements forservice provider tunnels, while a second level is provided atservice multiplexing points.

Figure 6 illustrates the functions needed at each networkelement to support QoS in a metro network.

Performance monitoring and SLS verificationThe performance parameters describe the service

guarantees the network offers to the customer for thepacket stream described by the flow description. There arefour major performance parameters: delay, jitter, packetloss and throughput. Other parameters of interest areavailability, service schedule, monitoring and reporting. Theavailability of the offered network service needs to berelated to the network protection and restoration options.The service schedule indicates the start and end times.Finally, the monitoring and reporting section of the Service

Level Specification (SLS) specifies when and how the QoSperformance needs to be monitored and reported.

OAMOAM is another key element in ensuring that the provider

network meets the contracted SLA. OAM tools are currentlybeing developed by several standardization bodies,including the IETF [15], ITU [16], IEEE [17] and MEF [18].These will provide powerful diagnostic functions to supportQoS in metro Ethernet. The Ethernet OAM protocolsshould be able to determine the connectivity, measuring theround-trip delay and jitter, and providing alarm notificationand performance measurements. These OAM functionsfacilitate the collection of essential information on routing,delays and QoS [19].

ConclusionService providers need to consider a crucial revenue

generating element in metro networks, that is, the ability toguarantee QoS in conformance with the SLAs for variousservices, such as E-Line and E-LAN services. This articlepresents a comprehensive framework for supporting QoS inmetro Ethernet networks, including an overview of the mainfunctional blocks (e.g. traffic shaping and policing,admission control, scheduling and buffer management).



PE

PE

PE

CE-B

CE-A

CE-C

Core

Core

CoreUNI-A

at CE

- Traffic Shaping- Admission Control- Frame Marking

at ingress PE

- Scheduling/Buffer Mngmnt- Admission Control- Frame Marking- Traffic Mapping

at Core P

- Scheduling/Buffer Management

at Egress PE

- Traffic Shaping- Scheduling/Buffer Mngmnt- Traffic Mapping

UNI-C

UNI-B


Fig. 6 Desired functions at different network elements to support QoS

It also describes how packets are handled at differentnetwork elements (CE, PE, and core). Table 2 summarizesthe desired functions.

Alcatel’s family of Service Routers (Alcatel 7750 and7450)[20,21], Optical Multi-Service Nodes (OMSN), MultiService Provisioning Platforms (MSPP) (Alcatel 1660 SM)[22], and multi-service system for customer premises(Alcatel 1642 Edge Multiplexer) [23], supports a widevariety of metro services and provides a comprehensiverange of OAM and provisioning features. Service providersrequire these features to implement QoS and to deliverguaranteed SLAs in their metro Ethernet networks, as wellas to provide solutions to the challenging problems thatcarriers and service providers face today.

References[1] IEEE 802.1D/Q/p Working Group: “Media access

control (MAC) bridges”, IEEE 802.1D, 1998.[2] http://www.ietf.org/internet-drafts/draft-ietf-pwe3-

ethernet-encap-04.txt.[3] M. Lasserre, V. Kompella: “Virtual Private LAN Services

over MPLS”, IETF Work in Progress, draft-ietf-l2vpn-vpls-ldp-03.txt, April 2004.

[4] G. Chiruvolu, B. Krogfoss, A. Ge: “EncapsulationSchemes to Extend Ethernet to Metropolitan AreaNetworks: A Comprehensive Analysis of Popular andEvolving Encapsulation Schemes for Metro-Ethernet”,White Paper, Alcatel 2004.

[5] “Ethernet Services Model, Phase I”, Metro EthernetForum, November 2003.

[6] “Ethernet Services Definitions – Phase I, Draft v5.5”,Metro Ethernet Forum, March 2004.

[7] “Functional Description of Quality of Services in MetroEthernet networks”, Draft 1, Alcatel Internal Document(produced by Alcatel Metro Ethernet QoS Task Force),April 2004.

[8] “Traffic Management Specification-Phase I, draft. V7.0”,Metro Ethernet Forum, March 2004.

[9] “A Single Rate Three Color Marker”, RFC 2697, IETF.[10] “A Two Rate Three Color Marker”, RFC 2698, IETF.[11] IEEE Standards 802.3x on congestion control 1997.[12] A. Ge, G. Chiruvolu: “DiffServ-Compatible Fair

Congestion Control through Extended Pause (DiffPause)for Metro-Ethernet”, IEEE ICC, 2004.

[13] H. Saito, Y. Miyao, M. Yoshida: “Traffic engineeringusing multiple multipoint-to-point LSPs “ INFOCOM 2000,Proceedings. IEEE, 26-30 March 2000, volume 2, pp894-901.

[14] D. Awduche et al: “RSVP-TE: Extensions to RSVP for LSPTunnels”, RFC 3209,http://www.ietf.org/rfc/rfc3209.txt.

[15] M. Aissoui et al: “OAM Procedures for VPWSInterworking”, IETF Draft, Work In Progress, 2004.

[16] Study Group 13, ITU, Work in Progress.[17] N. Finn: “Bridges and End-to-End OAM”, IEEE 802.1

work in progress, March 2003http://www.ieee802.org/1/files/public/docs2003/finn-e2e-oam-bridges-1.pdf.

[18] Metro Ethernet Forum,http://www.metroethernetforum.org/.

[19] A. Berthillier, A. Lardies: “Ethernet OAM status review”,Alcatel position paper (internal document), 2004.

[20] “Alcatel 7750 Service Router”,http://www.alcatel.com/products/productsummary.jhtml?repositoryID=/x/opgproduct/a7750sr.jhtml.

[21] “Alcatel 7450 Ethernet Service Switch”,http://www.alcatel.com/products/productsummary.jhtml?repositoryID=/x/opgproduct/a7450ess.jhtml.

[22] “Alcatel 1660 SM STM-16/64 Optical Multi-ServiceNode for Metro Applications”,http://www.alcatel.com/products/productsummary.jhtml?repositoryID=/x/opgproduct/Alcatel_1660_SM.jhtml.

[23] “Alcatel 1642 Edge Multiplexer”,http://www.alcatel.com/products/productsummary.jhtml?repositoryID=/x/opgproduct/Alcatel_1642_em.jhtml.



Bijan Raahemi is a Research Scientist at the AlcatelResearch & Innovation Center in Ottawa, Canada. Hehas contributed to the Ethernet Services definition at theMetro Ethernet Forum. ([email protected])

Girish Chiruvolu is a Research Scientist in the PacketTransport and Interworking Group at the AlcatelResearch & Innovation Center in Plano, Texas, USA.([email protected])

An Ge is a Research Scientist in the Packet Transportand Interworking Group at the Alcatel Research &Innovation Center in Plano, Texas, USA.([email protected])

Maher Ali is a Research Scientist in the PacketTransport and Interworking Group at the AlcatelResearch & Innovation Center in Plano, Texas, USA.([email protected])

Attribute CE PE (ingress/egress)

Core

Traffic Shaping

Scheduling/BufferManagement

Admission Control

Frame Marking

Traffic Mapping

Yes

No

Yes

Yes

No

Yes

Yes

Yes

Yes

Yes

No

Yes

No

No

No

Tab. 2 Summary of the required functions at variousnetwork elements

AbbreviationsATM Asynchronous Transfer ModeCAC Connection Admission ControlCBS Committed Burst Size

CE Customer EquipmentCES Core Ethernet Switch / Bridge

CF Coupling FlagCIR Committed Information RateCLE Customer Located EquipmentCoS Class of ServiceCRC Cyclic Redundancy Check

C-VLAN Customer VLANDA Destination Address

EBS Excess Burst SizeEIR Excess Information Rate

E-LAN Ethernet LAN servicesE-LINE Ethernet Line services

EoMPLS Ethernet over MPLSEPL Ethernet Private LineEVC Ethernet Virtual Connection

EVPL Ethernet Virtual Private LineEXP EXPerimental

GARP General Address Registry ProtocolGFP Generic Framing ProcedureIEEE Institute of Electrical and Electronics EngineersIETF Internet Engineering Task ForceITU International Telecommunications Union

LAN Local Area NetworkLCAS Link Capacity Adjustment Scheme

LDP Label Distribution ProtocolLER Label Edge RouterLSP Label Switched PathsLSR Label Switch Routers

MAC Media Access ControlMEF Metro Ethernet Forum

MPLS Multi Protocol Label SwitchingMSPP Multi Service Provisioning Platform

MTU Maximum Transmission UnitOAM Operations, Administration and Maintenance

OMSN Optical Multi-Service NodeP Core

PE Provider EdgePIR Peak Information Rate

QoS Quality of ServicesRSVP Resource Reservation Protocol

SA Source AddressSDH Synchronous Digital HierarchySLA Service Level AgreementSLS Service Level Specification

SONET Synchronous Optical NETworksrTCM single rate Three Color MarkertrTCM two rate Three Color Marker

UNI User to Network InterfaceVC Virtual Circuit

VID VLAN IDentificationVLAN Virtual Local Area Network

VPLS Virtual Private LAN ServiceWAN Wide Area NetworksWFQ Weight Fair Queuing

WRED Weighted Random Early DiscardWRR Weight Round Robin



Alcatel and the Alcatel logo are registered trademarks of Alcatel. All other trademarks are the property of their respective owners. Alcatel assumes no responsibility for the accuracy of the information presented, which is subject to change without notice.

© 11 2004 Alcatel. All rights reserved. 3GQ 00009 0005 TQZZA Ed.01

Metro Ethernet Quality of Services - Semantic Scholar · 2015-07-28 · Metro Ethernet Quality of...

Documents

Transcript of Metro Ethernet Quality of Services - Semantic Scholar · 2015-07-28 · Metro Ethernet Quality of...