Carrier Ethernet Services - The Future - EANTC€¦ · Nokia Siemens Networks hiD 6650 Flexi WCDMA BTS FlexiHybrid RACEL Nortel Metro Ethernet Routing Switch (MERS) 8600 RAD Data

Carrier Ethernet Services -The Future

Public Multi-VendorInteroperability Test

Berlin, September 2008

2

Carrier Ethernet World Congress 2008 Multi-Vendor Interoperability Test

EDITOR’S NOTE

This year the interoperabilityhot staging test for theCarrier Ethernet WorldCongress took place inparallel to the BeijingOlympics.80 engineers from 28 parti-cipating vendors with over100 systems attended ourtest. According to data fromHeavy Reading, more than

90% of the Carrier Ethernet switch and router marketshare were represented in this test.The participating vendors verified 34 test areas inany-to-any combinations in ten days, trulychallenging the Olympic motto “Faster, Higher,Stronger“. Carrier Ethernet implementations supportmore functions and cover more markets today —ranging from core to microwave to access, E-Lines toE-Trees, triple play to mobile backhaul.It was an outstanding experience to witness themassive testing feast, a unique get-together ofvirtually all leading playerswith one single goal:To improve multi-vendorinteroperability of advancedCarrier Ethernet implementa-tions.An EANTC panel of serviceproviders worldwide includingexperts from COLT, GVTBrazil, PT TELKOM Indonesia,T-Systems and Metanoia Increviewed the test planthoroughly to ensure the event’sscenarios are realistic andsound.Interestingly, market forces areoperating at full strength. Thisyear, we once again testedthree transport technologies inthe test event’s metro/aggre-gation networks: MPLS, PBB-TEand T-MPLS. These threecompete to some extent — atour test, they all proved beingwell suited for the transport of Carrier Ethernetservices.Service OAM support is becoming mandatory foraggregation and CPE devices; the Ethernetmicrowave market flourishes; mobile backhaulpushes support for backwards compatibility (ATMpseudowires, circuit emulation) and new features(clock synchronization, IEEE 1588v2, E-Tree, amongothers).This white paper summarizes in detail themonumental effort that the participating vendors andEANTC team underwent. Enjoy the read.

INTRODUCTION

This year’s interoperability event focused on theFuture of Carrier Ethernet Services. While eachprevious event concentrated on specific topics suchas mobile backhaul or service creation, this eventaimed to congregate the knowledge and experiencethe industry gained in the last four years into a singlemodern, converged network showing all that a tier-one service provider is likely to encounter. Wetherefore tested:

• Converged residential, business and MobileBackhaul services

• Clock synchronization

• Business services realized using E-Line, E-LANand for the first time E-Tree services

• The leading access, transport and aggregationtechnologies

• Microwave access and transport

• Ethernet OAM: Fault management and perfor-mance monitoring

• High availability

• Management and SLA reportingIn order to construct such a large testnetwork and cover all the above testareas a ten day, closed doors hotstaging event was conducted atEANTC’s lab in Berlin, Germany.Since the first Carrier Ethernet WorldCongress in 2005, EANTC hasorganized interoperability test eventswhich are then showcases at thecongress.Our interoperability showcases aredriven by three main goals:Technical – Through participation inthe event, vendors have the oppor-tunity to verify the interoperability oftheir devices and protocol implementa-tions against the majority of theindustry’s leading vendors.Marketing – The participants canshowcase the interoperability of theirlatest solutions on a unique, large-scale platform.

Standards – When fundamental issues are foundduring the hot staging event EANTC reports thediscoveries to the standard bodies. These in turnupdate the standards.EANTC started the preparation for the event byinviting interested vendors to weekly conferencecalls during which the technical and marketing goalsfor the event were discussed and agreed. The testplan, created by EANTC based on the test topicssuggested by the vendors, expanded on theexperience gained from previous events and waslined up with recent IEEE, IETF, ITU-T and MEFstandards.

Carsten RossenhoevelManaging Director

TABLE OF CONTENTS

Participants and Devices ..............3Network Design..........................4Interoperability Test Results ...........4Ethernet Service Types .................4Diverse Access Technologies ........6Diverse Transport ........................7MPLS Core .................................8E-NNI........................................9Mobile Backhaul.......................10Clock Synchronization...............14Ethernet OAM ..........................15Resilience and Fault Detection.....18Management and SLA Reporting.21Acronyms.................................22References ...............................23

3

Participants and Devices

PARTICIPANTS AND DEVICES

Service Provider Test Plan ReviewThe draft test plan was reviewed by a panel ofglobal service providers in July this year. Theirfeedback and comments were reflected in the finalversion of the test plan. EANTC and the partici-pating vendors would like to thank: COLT, GVTBrazil, PT TELKOM Indonesia, T-Systems andMetanoia Inc.

Vendor Participating Devices

Actelis Networks ML658

ADVA OpticalNetworking

FSP 150CC-825

Alcatel-Lucent 1850 TSS-405650 CPAM7450 ESS-67705 SAR7750 SR79500 MPR

Calnex Solutions Paragon Sync

CambridgeBroadband Networks

VectaStar

Ceragon Networks FibeAir IP-MAX2

FibeAir IP-10

Ciena LE-311vLE-3300

Cisco Systems 76067604ME4500Catalyst 3750-MEME-3400-2CSME-3400-12CS

ECI Telecom SR9705

Ericsson Marconi OMS 2400

Foundry Networks NetIron XMR 8000

Harris StratexNetworks

Eclipse (Gigabit) Radio

Huawei Technologies NE5000E Cluster SystemNE40E-4CX600-4

InfoVista VistaInsight for Networks

Ixia XM2 IxNetwork

Juniper Networks M10iMX240MX480

NEC Corporation CX2600PASOLINK NEOPASOLINK NEO TE

Nokia SiemensNetworks

hiD 6650Flexi WCDMA BTSFlexiHybridRACEL

Nortel Metro Ethernet RoutingSwitch (MERS) 8600

RAD DataCommunications

ACE-3205ACE-3200ACE-3400ASMi-54Egate-100ETX-202AETX-202A/MiRICiETX-202A/MiTOPIPMUX-216/24LA-210OP-1551RICi-16RICi-155GE

Redback Networks —an Ericsson Company

SmartEdge 400

Rohde & Schwarz SIT SITLine ETH

SIAEMICROELETTRONICA

ALSALFO

SpirentCommunications

Spirent TestCenter

Symmetricom TimeProvider 5000 PTPGrand MasterTimeCesium 4000

Tejas Networks TJ2030

Telco Systems —a BATM Company

T5C-XGT5C-24FT5C-24GT-Marc-250T-Marc-254T-Marc-340T-Marc-380T-Metro-200

Tellabs 8830 Multiservice Router

Vendor Participating Devices

4


NETWORK DESIGN

As in previous events we set off to construct anetwork that would allow all participating vendors toestablish end-to-end Ethernet services with any of theother vendors. One of the central design consider-ations for the network was to enable any devicepositioned in the access network to reach any otheraccess network device regardless of the otherdevice’s point of attachment to the network. Thisproved to be especially useful for such end-to-endtests as Service OAM or Mobile Backhaul. Thespecifics of these tests can be found in the test casesections.We also aimed to build a network that would lookfamiliar to service providers. It is perhaps unrealisticto expect that service providers will incorporate allcurrent transport technologies into their network.Nevertheless the familiar network domains are likelyto exist: access, aggregation, metro and core,regardless of the chosen transport technology. It isrealistic, however, to expect service providers to useMPLS in the core.Looking at the network from a customer’sperspective, we used the following network areas:

• Access: The devices that normally exist at thecustomer premise or by NodeBs or base stationswere positioned here. We were lucky to see adiverse number of access technologies for trans-porting Ethernet such as microwave links,copper, and fiber. These devices implementedthe UNI-C construct as defined by the MEF.

• Aggregation: The aggregation area of a networkconsisted of a variety of solutions meant toaggregate customer premise devices. Thisincluded Provider Bridges and H-VPLS Multi-Tenant Unit Switches (MTU-s). When applicablethese devices performed the UNI-N role in thenetwork.

• Metro: Three different transport technologieswere used in each of the three metro areanetworks: MPLS, PBB-TE and T-MPLS. Thisallowed each transport technology to test its ownresiliency and Network-to-Network Interface(NNI) solutions.

• Core: As stated above, IP/MPLS was used tosupport connectivity between the different metroarea networks in order to realize end-to-endservices. In addition, MPLS Layer 3 VPNs asdefined in RFC 4364 were tested in the core ofthe network.

The physical network topology presented heredepicts the roles of all the devices and theirrespective placement in the network. Please note thatmany tests required logical connectivity between thedevices, often at an end-to-end nature, which will beshown, where applicable, using logical topologiesin each test section.

INTEROPERABILITY TEST RESULTS

In the next sections of the white paper we describethe test areas and results of the interoperabilityevent. The document generally follows the structureof the test plan.Please note that we use the term »tested« whenreporting on multi-vendor interoperability tests. Theterm »demonstrated« refers to scenarios where aservice or protocol was terminated by equipmentfrom a single vendor on both ends.

ETHERNET SERVICE TYPES

The Metro Ethernet Forum (MEF) has defined threeEthernet service types in order to allow the industryand specifically the customers interested in theservices to have a common language to discuss suchEthernet based services. The three service types aredefined in terms of the Ethernet Virtual Connection(EVC) construct:

• E-Line – Point-to-point EVC

• E-LAN – Multipoint-to-multipoint EVC

• E-Tree – Rooted-multipoint EVCWhile the E-Line service type provides a service toexactly two customer sites, the E-LAN and E-Treeservice types allow the connection of more than twocustomer sites. In contrast to the E-LAN service typewhich allows an any-to-any connectivity betweencustomer sites, E-Tree introduces two different rolesfor customer sites: leaf and root. An E-Tree servicefacilitates communication between leaves and roots,however, leaves can not communicate with eachother directly. An E-Tree service implemented by arooted-multipoint EVC can be used to providemulticast traffic distribution and hub-and-spoketopologies (e.g. DSL customers to BRAS).In the test network we instantiated three specificdefinitions of service types: Ethernet Virtual PrivateLine (EVPL), Ethernet Virtual Private LAN (EVP-LAN),and Ethernet Virtual Private Tree (EVP-Tree). Allservices were configured manually in the network.Due to the increasingly large amount of devices andvendors we had present at the hot staging, thisprocess was time consuming and prone to mistakes.A multi-vendor provisioning tool would have beenideal for the testing and is recommended for anyservice provider planning to deploy Carrier Ethernetservices.The services created in the network were configuredin two ways:

• EVCs that remained within the same metro areanetwork

• EVCs that crossed the network coreThe sections below describe the services in thenetwork in detail.

5

Ethernet Service Types

E-TreeFor the first time at an EANTC interoperability event,an E-Tree service instantiation was established. OneEVP-Tree was configured with one root node withinthe MPLS metro area and leaves throughout allnetwork areas. The MEF defines an E-Tree service tobe a rooted Ethernet service where the roots areable to communicate with all leaves, and all leavesare able to communicate with the roots, but not witheach other.This service utilized each metro technology in aunique way. The MPLS metro used a separate VPLSinstance to create this service, using different splithorizon groups to ensure that leaf UNIs could onlycommunicate with the root UNI, but could notestablish communication between each other. TheCisco ME4500 implemented the root UNI-N andhanded the service off to the Nokia SiemensNetworks hiD 6650 which propagated the tree intothe MPLS metro. The Juniper MX480 configured aleaf using MPLS towards the Cisco 7606 whichtreated this connection as the root for the corenetwork. Three leaves were configured within the

core, two of which provided E-NNI leaf connectivityto the other metros - the Alcatel-Lucent 7750 SR7 toT-MPLS and the ECI SR9705 to PBB-TE. The TejasTJ2030 interpreted this E-NNI connection as the rootconnectivity for the PBB-TE metro, and the EricssonMarconi OMS 2400 did the same for the T-MPLSmetro.The diagram in figure 1 shows all points whereE-Tree traffic was verified. The logical connectionsrepresent something different in each area: Ethernetpseudowires in the MPLS, PBB-TE trunks in thePBB-TE, and TMCs in the T-MPLS networks.

E-LANOne EVP-LAN was configured in the network withcustomer ports in all three metro areas. Theconstruction of the EVP-LAN service used differentmechanisms in each metro area. These mechanismsare described in details in the diverse transportsection.

Cisco ME-3400-2CS

Cisco ME4500

ADVAFSP 150CC-825

Tejas TJ2030ECI

SR9705

Logical Path

EricssonMarconi OMS

Telco Systems

HuaweiCX600-4

JuniperMX480

ECISR9705

Telco SystemsT-Metro-200

MTU-s

Cisco7604

MTU-s


MTU-s

CienaLE-311v

Telco SystemsT-Metro-200MTU-s

Tellabs8830

CeragonFibeAir IP-10

MTU-s

2400

Tejas TJ2030

Propagation

AccessDevice

AggregationDevice

MTUSwitch

Metro/CoreDevice

Root UNI

Root/Leaf

Leaf UNI

E-NNI

T-Marc-340

MPLS

PBB-TET-MPLS

FoundryNetIron XMR 8000

Alcatel-Lucent7750 SR7

EricssonMarconi OMS

2400

EricssonMarconi OMS

2400

RedbackSmartEdge

400

Nokia Siemens Networks

JuniperMX480

Cisco7606

Alcatel-Lucent1850 TSS-40

Figure 1: E-Tree logical connections

CambridgeVectaStar

Harris StratexEclipse

ADVAFSP 150CC-825

Telco SystemsT-Marc-380

CienaLE-3300

NortelMERS 8600

hiD 6650

6


E-LineThe E-Line service type configured in the networkused Virtual LAN (VLAN) IDs to distinguish betweenthe various services. In some cases, much like realworld networks, a switch positioned at the customersite would add a Service VLAN tag (S-VLAN) to theEthernet traffic provided by the customer, therefore,allowing the customer to maintain its private VLANaddressing scheme and separate the customer VLANspace from the provider’s.

Figure 2: E-Line service creation

All vendor devices successfully participated increation of E-Line services. From the number ofcombinations tested, we are confident that an any-to-any combination of endpoints is possible.Three of the E-Line services created between thethree metro clouds were encrypted using Rohde &Schwarz SITLine ETH. The encryption device wassituated between the UNI-C (which was emulated bySpirent TestCenter) and Alcatel-Lucent 7705 SAR,Telco Systems T-Marc-380 and Telco SystemsT-Metro-200 all of which were serving as UNI-Ndevices. Once the encryption connections wereestablished we verified that the EVCs were indeedencrypted and that the connection remained stable.

DIVERSE ACCESS TECHNOLOGIES

The different services in the test network used avariety of access technologies to reach the simulatedlast mile customer access device. Most services usedfiber (multi-mode) and copper based GigabitEthernet. One UNI was implemented over a singlestrand fiber cable using IEEE 802.3ah defined1000BASE-BX10 between the Cisco ME4500 andthe Cisco ME-3400-2CS. Two Actelis ML658devices used G.SHDSL.bis to connect the aggre-gation area to the access. RAD demonstrated a widevariety of access technologies including EFMbonding of four G.SHDSL.bis pairs between theASMi-54 and LA-210. In addition, RAD demon-strated Ethernet over PDH connectivity with theETX-202A with MiRICi E1/T1 over a single E1 linkand the RICi-16 over 16 bonded E1 links, bothaggregated by the Egate-100. The PDH tochannelized STM-1 was performed by the OP-1551.Several Ethernet access links comprised of twoEthernet links with a microwave signal in between.These systems are described in more detail below.

Microwave for Access andTransportIn recent years we have seen an increased interest inour interoperability events from vendors offeringmicrowave connectivity and network solutions.Microwave solutions alleviate the need to roll outphysical wire infrastructure and are especiallyprevalent in such areas as cellular backhaul,emerging markets, large corporation networks,hospitals, and mobile-fixed operators.This event enjoyed the participation of the followingmicrowave products: Alcatel-Lucent 9500 MPR,Cambridge VectaStar, Ceragon FibeAir IP-10 andFibeAir IP-MAX2, Harris Stratex Eclipse, NECPASOLINK NEO, Nokia Siemens Networks Flexi-Hybrid, and SIAE MICROELETTRONICA ALS andALFO. In addition, Cambridge Broadband Networksprovided a point-to-multipoint microwave systemwith which providers can connect either multiplecustomer offices or multiple base stations viaEthernet or E1 lines.Since the radios rely on a signal through the airsome weather events such as rain and heavy fogcan cause the signal to degrade effectivelydecreasing the range or capacity of the link. Radiodevices can recognize the decrease in air-linkcapacity and some solutions can distinguish whichframes should be prioritized and further transportedversus which frames will be dropped. The Alcatel-Lucent 9500 MPR, Cambridge VectaStar, CeragonFibeAir IP-10, Harris Statex Eclipse, and SIAEMICROELETTRONICA ALFO showed this function-ality by decreasing the modulation scheme inQuadrature Amplitude Modulation (QAM) whichcaused traffic loss only to best effort frames and noor minimal loss to prioritized traffic with unaffectedlatency.

MPLS

User Network Interface (UNI)

UNI-N Metro Device

PBB-TE

UNI-N Aggregation Device

UNI-C Access Device

UNI-C Microwave Access Device

T-MPLS

7

Diverse Transport

Services relying on microwave equipment will needto be made aware when the microwave signal is tooweak to transmit traffic. The link state propagationfunction disables the Ethernet link state for all portsassociated with the microwave link. This function-ality was demonstrated by the Ceragon FibeAirIP-10, Harris Stratex Eclipse and the SIAEMICROELETTRONICA ALFO. These devices alsoshowed their capability to propagate an incomingloss of signal on a tributary Ethernet port across themicrowave link and switching off the appropriatephysical port on the other side of the radioconnection.Cambridge Broadband Networks demonstratedtheir ability to share point-to-multipoint link capacitybetween several end stations. In the demonstrationthree end stations were defined to share a 45 Mbpswireless link to a central controller. CambridgeBroadband Networks showed that when capacitybetween one base station and controller was notused, the remaining base stations could use theextra capacity.Over the last few years we have seen an impressiveincrease in the features built into microwavetransport. While historically microwave solutionswere used to provide a virtual wire, we see moreand more intelligence built into the solutions — onseveral products a complete Ethernet switchfunctionality.

DIVERSE TRANSPORT

The Carrier Ethernet architecture specified by theMEF is agnostic to the underlying technology used toprovide Carrier Ethernet services. The creation andsupport of such services is, however, an essentialcomponent of the interoperability test event. Mainlythree technologies compete for Carrier EthernetTransport: MPLS, PBB-TE and T-MPLS. During thisevent we had the opportunity to verify all threetechnologies. The following sections describe testresults for each technology in detail.

MPLSMPLS is defined in a set of protocols standardizedby the Internet Engineering Task Force (IETF) and theIP/MPLS Forum. MPLS is positioned to deliver layer2 and layer 3 services including Ethernet services asdefined by the MEF while being agnostic to theunderlying transport technology.The tests in this area were based on previousexperience gained from EANTC’s Carrier EthernetWorld Congress and MPLS World Congress interop-erability test events and reached a larger number ofparticipants than in previous events, including a totalof 12 vendors testing MPLS implementations. TheMPLS metro domain operated independently fromthe MPLS core network.The MPLS metro network was built solely for thepurpose of Carrier Ethernet services. Multipoint-to-multipoint services were facilitated with the creation

of a single Virtual Private LAN Services (VPLS)instance utilizing both VPLS PEs and H-VPLS MTUswitches established between the following devices:Alcatel-Lucent 7450 ESS-6, Ciena LE-311v, Cisco7604 and Catalyst 3750-ME, ECI SR9705, HuaweiCX600-4, Ixia XM2 IxNetwork, Juniper MX240 andMX480, Nokia Siemens Networks hiD 6650,Redback SmartEdge 400, Tellabs 8830, and TelcoSystems T-Metro-200. This VPLS instance used LDPfor signaling statically configured peers asdescribed in RFC 4762. These devices also estab-lished Ethernet pseudowires using LDP to facilitatepoint-to-point Ethernet services.A separate VPLS instance was used to test BGP-based Auto-Discovery, which was successfully estab-lished between the Cisco 7606 and the ECISR9705. A total of four vendors were interested intesting BGP-based Auto-Discovery, one of whichuncovered an interoperability issue during the testswhere packets captures were taken to be furtherstudied in their labs.In order to test the interoperability of VPLS implemen-tations which use BGP for signaling as described inRFC 4761, another separate VPLS instance wasconfigured. This was tested between the followingdevices with BGP-based Auto-Discovery enabled:Huawei CX600-4 and Huawei NE40E-4, andJuniper MX240 and Juniper MX480. The JuniperMX480 performed an interworking functionbetween this BGP signaled VPLS domain and an LDPsignaled VPLS domain with the Cisco 7604.

Provider Backbone BridgeTraffic Engineering (PBB-TE)One of the potential solutions to delivering MEFdefined services using Ethernet technologies only isthe IEEE defined Provider Backbone Bridge TrafficEngineering (PBB-TE). The technical specification isdefined in 802.1Qay which is working its waythrough the standard process and is in draft version3.0 at the time of the testing. The standard extendsthe functionality of the Provider Backbone Bridges(802.1ah) adding a connection-oriented forwardingmode by creating point-to-point trunks. These trunksdeliver resiliency mechanisms and a configurablelevel of performance.The vendors participating in the PBB-TE transportdomain included Ciena LE-311v2, Ciena LE-3300,Ixia XM2 IxNetwork, Nortel MERS 8600, and TejasTJ2030.In the PBB-TE Metro network we were able to test theestablishment of E-Line, E-LAN, and E-Tree services.The establishment of E-Line services was straight-forward as we tested it in several previous events.E-LAN and E-Tree services creation was tested testedfor the first time within the PBB-TE cloud. For theE-LAN service Ciena LE-3300 and Tejas TJ2030switches established bridging instances per PBB-TEtrunk and C-VLAN/S-VLAN IDs. Every PBB-TE edgedevice established a trunk for each particular UNI toone of the bridges. A few issues related to usage ofdifferent Ethertype values in CFM messages,

8


padding, and different interpretation of CCMintervals were discovered in the initial configurationphase of PBB-TE trunks, however, these issues wereresolved quickly.In addition, the Nortel MERS 8600 and the SpirentTestCenter tested one of the latest additions toEthernet - Provider Link State Bridging (PLSB) – a pre-standard implementation of the IEEE 802.1aq(Shortest Path Bridging) which is in draft version 0.3.The protocol uses the IETF defined IS-IS protocol fordistributing Backbone MAC addresses and ServiceIDs of participating nodes across the network. Oncethe network topology has been learned, IS-IS is usedto establish loop-free multipoint-to-multipoint services.The forwarding plane uses PBB (802.1ah), howeversince the other devices in the PBB-TE network did notsupport PLSB the three Nortel MERS 8600 deviceswere able to use a re-encapsulation of either PBB-TEtrunks or VLAN tags to peer within the PBB-TEnetwork. The Nortel MERS 8600 devices and theSpirent TestCenter emulated nodes successfullylearned the appropriate B-MAC addresses, andforwarded the respective traffic accordingly.Tejas Networks demonstrated a logical Ethernet LANnetwork with an IEEE 802.1ad based Ethernet RingProtection Switching (ERPS). This ring based controlprotocol being standardized under ITU-T G.8032 isa protection mechanism which offers carriers adeterministic sub-50 ms network convergence on afiber failure as opposed to the conventional loop-breaking mechanisms like Rapid Spanning TreeProtocol (RSTP). ERPS convergence time isindependent to the number of nodes in the network,thereby vastly enhancing the scalability of a carriernetwork. We measured failover and restoration ofbelow 35 ms for the demonstrated ERPS.

Transport MPLS (T-MPLS)This test marked the third T-MPLS interoperabilitytesting at EANTC. The following devices successfullyparticipated in the T-MPLS area during the event:Alcatel-Lucent TSS-40, Ericsson Marconi OMS2400, and Ixia XM2 IxNetwork.The T-MPLS standards specify the networking layerfor packet transport networks based on MPLS dataplane and designed for providing SONET/SDH-likeOAM and resiliency for packet transport networks.Alcatel-Lucent and Ericsson successfully tested thecreation of E-Line, E-LAN and E-Tree services, the lastof which was a first at an EANTC interoperabilityevent. Both participants constructed T-MPLS paths(TMP) which are end-to-end tunnels that aggregateT-MPLS channels (TMC) representing the services.The TMPs and TMCs were transported over differentphysical layer types including 1 Gbit Ethernet,10 Gbit Ethernet, ITU-T G.709, and SDH STM-16.The Alcatel-Lucent 7705 SAR was used as a non-T-MPLS switch in the aggregation area, interfacing tothe T-MPLS domain by means of statically configuredMPLS labels.The E-LAN and E-Tree services were configured

using a multipoint architecture similar to VPLS. Onone particular E-Line service, both Alcatel-Lucent1850 TSS-40 and Ericsson Marconi OMS 2400were able to successfully test Quality of Service(QoS) by distinguishing between three differentclasses of service within the same Ethernet serviceand only drop low priority traffic when interfaceswere oversubscribed.Since the T-MPLS standards do not define a controlplane protocol, the T-MPLS connections betweenvendors were manually configured. Ericsson usedtwo proprietary management tools (ENEA andDiToNe) to setup the T-MPLS network configurationon their devices.

MPLS CORE

Since MPLS is used by the majority of serviceproviders as core technology it is only logical thatwhen providers add Carrier Ethernet services to theirproduct offering the MPLS core will be used. Wefollowed this approach and used the MPLS core toconnect between three different Ethernet transportmetro areas. The core area was constructed usingthe following edge devices, all of which successfullyestablished multiple VPLS domains and CVirtualPrivate Wire Services (VPWS) using LDP for variousEthernet services: Alcatel-Lucent 7750 SR7, Cisco7606, ECI SR9705, Foundry NetIron XMR 8000,Huawei NE40E-4, Juniper M10i, and Tellabs 8830.All devices were physically connected to HuaweiNE5000E cluster system P router (P for Provider, asopposed to PE for Provider Edge) through which allservices were tunneled through by default.

T-MPLS to MPLS-TP MigrationFollowing the approval of the first version of theITU recommendations on T-MPLS, the IETF andITU-T jointly agreed to work together to extendMPLS protocols to meet transport networkrequirements in order to ensure a smoothconvergence of MPLS-based packet transporttechnology. A Joint Working Group (JWT) wasformed between the IETF and the ITU to achievemutual alignment of requirements and protocolsand to analyse the different options for T-MPLSstandard progress. On the basis of the JWTactivity, it was agreed that the future standard-ization work will focus on defining a transportprofile of MPLS (named MPLS-TP) within IETFand in parallel aligning the existing T-MPLSRecommendations within ITU-T to the MPLS-TPwork in IETF.At their Dublin meeting in July 2008, the IETFhas initiated the work on MPLS-TP. Due to thefact that IETF MPLS-TP standard or drafts do notexist yet, we tested the implementations basedon the T-MPLS ITU-T Recommendations currentlyin force and its relevant drafts.It is our intention also to include the first imple-mentations of MPLS-TP drafts at our next event.

9

External Network to Network Interface (E-NNI)

In addition to providing transport for Ethernetservices, all edge devices in the core established anIP/MPLS L3VPN service using BGP (based on RFC4364). The Alcatel-Lucent 7750 SR7 and Cisco7606 terminated Ethernet pseudowires into this VPNproviding the potential to offer layer 3 services tocustomers which are not reachable otherwise.

EXTERNAL NETWORK TONETWORK INTERFACE (E-NNI)

Figure 3: E-NNI to the core

As we described above three different technologieswere used in the metro areas. The problem thatevery service provider then faces is to connect themetro area with the existing network core. In our testnetwork, much like in most service providernetworks, the core used MPLS for transport andservices. Therefore, we required mechanisms toallow services originating on one metro area tocross the core and be received on other metroareas.The following subsections describe the specificNetwork to Network Interface (E-NNI) solutions usedin the network.

MPLS Metro Connectivity to the CoreSeveral options exist to allow connectivity betweentwo MPLS areas. The preferred options were MPLSbased, but one option used IEEE 802.1ad ProviderBridging tags, or simply 802.1Q VLAN tags totransport services between the two areas. The LabelEdge Router (LER) in the MPLS core would strip theMPLS header from traffic before it forwarded theEthernet frames to the LER in the MPLS metro. TheS-Tag or VLAN tag would then signal to the MPLSmetro device which pseudowire to forward theframes onto. Devices using VLAN tags were Alcatel-Lucent 7450 ESS-6, ECI SR9705, and FoundryNetIron XMR 8000.The other option used to connect between adminis-tratively separated MPLS core and metros is referredto as pseudowire (PW) stitching. This involves thecreation of two pseudowires, one in each domain,and then interconnecting them either within onedevice, or with a third pseudowire between the twoedge devices. Vendors who took this approachchose the latter. In this case two MPLS labels must besignaled: the inner label (PW label) signaled byLDP, and the transport label (PSN label) signaled byeither eBGP (IPv4+label) or LDP. To facilitate thetransmission of LDP sessions, either a separate OSPFarea was enabled between the two edge devices ora static route was used. Devices taking the PWstitching approach were Cisco 7606, Juniper M10i,Juniper MX480, and Redback SmartEdge 400.

PBB-TE Connectivity to the CoreAs PBB-TE and 802.1ad are both part of the IEEEProvider Bridging domain of technologies, it is notsurprising that Provider Bridging tags weresupported across the board in the PBB-TE metrodomain. All services crossing the core into thePBB-TE cloud used S-Tags (Service Tags) to distin-guish each service between a core edge router anda PBB-TE switch. These devices included CienaLE-3300, ECI SR9705, Nortel MERS 8600, TejasTJ2030, and Tellabs 8830. One PBB-TE trunk wasconfigured between Nortel MERS 8600 and TejasTJ2030 and traversed the MPLS core.

T-MPLS Connectivity to the CoreTwo options were used to establish services over anMPLS core into a T-MPLS network. The first was touse 802.1ad S-Tags, similarly to the MPLS metro.The second option used was pseudowire stitching.The T-MPLS edge device terminated TMCs comingfrom the edges of the network and stitched them toan MPLS Ethernet pseudowire which was estab-lished with the neighboring core edge device. Thiswas done using LDP for both MPLS labels, which ranover a separate OSPF area than the core. Thisoption was tested between Alcatel-Lucent 1850TSS-40 and the Alcatel-Lucent 7750 SR7, which alsohad some services configured over staticallyconfigured MPLS pseudowires.

T-MPLS

Provider Bridging (802.1ad)LDP-based E-NNIeBGP (IPv4+label)-based E-NNIVLAN (802.1Q)

ECI

TejasTJ2030 Ciena

LE-3300

Tellabs 8830

NortelMERS 8600

Alcatel-Lucent7450 ESS-6

ECISR9705

JuniperM10i

Cisco7606

JuniperMX480 Redback

SmartEdge 400

FoundryNetIron XMR 8000

MPLS

PBB-TE

SR9705

HuaweiNE40E-4

EricssonMarconi

OMS 2400

Metro/Core Device

Static MPLS Configuration



10


MOBILE BACKHAUL

Traditionally, the interface between mobile basestations and base station controllers has been basedon a number of parallel TDM circuits (for GSM,CDMA) or ATM connections (for the first versions ofUMTS and CDMA 2000) carried on E1 or T1 links.Several market studies show that the transportnetwork costs account for 20–30% of a mobileoperator’s operational expenditure (OPEX).

Figure 4: Mobile Backhaul scope

With the advent of high-speed data transport (HSPA)in 3G networks, with WiMAX and LTE on thehorizon, the amount of data traffic in mobilenetworks has vastly grown and will continue to doso. Mobile operators are considering mobilebackhaul over Carrier Ethernet networks, as theseprovide enough bandwidth for any predictedincrease in data traffic and are more cost effectivethan the current TDM networks.

The main issue and test focus for Mobile Backhaultransport is the migration path from TDM/ATM toconverged packet based services. Thousands ofbase stations will not be upgraded immediately ornot at all. Migration paths vary widely dependingon the specific service provider environment.In this test event, we verified a number of migrationscenarios, focusing TDM and ATM transport overCarrier Ethernet as well as clock synchronization.The following table provides an overview of thetransport requirements imposed by different mobilenetwork technologies.

Circuit Emulation Services (CES)There is a number of specifications defining circuitemulation services which could be used to supportMobile Backhaul services. During our event wetested implementations and observed demonstrationsof MEF8 and RFC 4553 specification for E1 inter-faces.During the tests and demonstrations the devices wereconnected either back-to-back, back-to-back with animpairment generator of Calnex Paragon Syncemulating a network behavior between the twodevices under test, or over the whole test network.We accepted a test or a demonstration if the twodevices performing circuit emulation were able topass E1 data over the packet based network and thedeviation of the E1 signal received from the networkcompared to its input signal was within 50 parts permillion (ppm) over 10 minutes.As shown in the CES tests back-to-back figure in total5 products from three different vendors passed thetests: Alcatel-Lucent 9500 MPR, NEC CX2600, NECPASOLINK NEO TE, RAD IPMUX-216/24, and RADMiTOP-E1/T1 hosted by the RAD ETX-202A. All testswere performed using MEF8 for encapsulation andadaptive clocking for clock synchronization. The testbetween Alcatel-Lucent 9500 MPR and RADIPMUX-216/24 was performed once with and oncewithout the optional RTP (Real Time Protocol) header.All other tests were performed without RTP. Asdescribed in RFC 4197 section 4.3.3, the usage ofRTP relaxes the tolerance requirement for the internalclocks of the devices performing CES and therefore

MobileBackhaul

CoreNetwork

RNC

BSCMSC

GGSN

SGSN

Radio Access Network

MSC — Mobile Service Switching CenterSGSN — Serving GPRS Support NodeGGSN — Gateway GPRS Support NodeBSC — Base Station ControllerRNC — Radio Network Controller

Mobile NetworkService Types

Carrier EthernetNetworkRequirements

TDM

Circ

uitE

mul

atio

n

ATM

Pseu

dow

ires

E-Lin

esSe

rvic

es

E-LA

NSe

rvic

es

E-Tr

eeSe

rvic

es

Sub

50-m

sRe

silie

ncy

Sub-

seco

ndRe

silie

ncy

Traditional GSM X X

Traditional 3G (UMTSRel. 99 / CDMA2000)

X X

Hybrid 3G offload(ATM-based voice; IPtunneled data)

X X X

Full packet-based 3G a X X

Long-Term Evolution(LTE, 4G)

X X

Mobile WiMAX a X X

a. Can be used as a fallback

11

Mobile Backhaul

decreases the probability of jitter buffer overflow orunderflow.In addition, CES was demonstrated over the wholetest network as shown in the diagram ., and testedback-to-back with the Calnex Peragon Syncimpairment tool, as shown in Figure 6: CES testsacross the network. The Calnex Paragon Syncemulated the jitter of a network path with 10 nodesand 40% traffic utilization for a more realisticscenario.

Figure 5: CES tests back-to-back

A number of microwave solutions participated in thisevent and have demonstrated their ability totransport E1 TDM data over their microwave links,namely Alcatel-Lucent 9500 MPR, Ceragon FibeAirIP-10, and NEC PASOLINK NEO. The Alcatel-Lucent9500 MPR microwave solution performed at thesame time circuit emulation service.RAD Data Communications demonstrated IETF circuitemulation (SAToP, RFC 4553) over MPLS which isvery similar to the MEF8 specification. In one casethe Circuit Emulation Service was demonstratedbetween RAD ACE-3200 and RAD ACE-3205 inMPLS metro network. The Ceragon FibeAir IP-10microwave solution was connected both betweenthe RAD ACE-3200 and E1 source, and alsobetween the RAD ACE-3200 and an MPLS metroedge device. Ceragon Networks and RAD DataCommunications demonstrated a hybrid mobilebackhaul network operation, effectively combiningnative TDM transport and Ethernet encapsulatedCES. In another test case SAToP CES was demon-strated between RAD ACE-3400 and RADACE-3205 in PBB-TE network.

Alcatel-Lucent demonstrated MEF8 CES with differ-ential clocking by using RTP (Real Time Protocol)header between Alcatel-Lucent 9500 MPR andAlcatel-Lucent 9500 MPR devices over T-MPLS metronetwork. In the same demonstration Alcatel-Lucentshowed its proprietary solution to synchronize twomicrowave endpoints over the air by transportingthe clock information from the Alcatel-Lucent 9500MPR performing the CES to another Alcatel-Lucent9500 MPR over the airFigure 6: CES Across theNetwork..

Figure 6: CES tests across the network

ATM Transport over MPLSAs described in the introduction, ATM transportservices over a Packet Switched Network (PSN) isanother key requirement for the migration of MobileBackhaul to packet switched networks. During theevent two implementations of ATM transport overMPLS as specified in RFC 4714 were tested anddemonstrated.Successful interoperability was tested betweenNokia Siemens Networks Flexi WCDMA BTS andRAD ACE-3200. The two devices encapsulated ATMdata into a statically configured MPLS pseudowireand sent the resulting MPLS packets over an IP tunnelacross the PSN. The ATM pseudowire was used totransport an ATM circuit configured between NokiaSiemens Networks RACEL, a Radio NetworkController (RNC) and mobile core network emulator,and Nokia Siemens Networks Flexi WCDMA BTS.In addition, RAD Data Communications demon-strated a statically configured ATM pseudowirebetween the RAD ACE-3205 and RAD ACE-3400devices. This pseudowire was tunneled over thePBB-TE network.

NEC CX2600Alcatel-Lucent

Alcatel-LucentRAD

NEC CX2600RAD

CalnexParagon Sync

NEC PASOLINKAlcatel-Lucent

RADAlcatel-Lucent

RAD ETX202AAlcatel-Lucent

9500 MPR

9500 MPR

9500 MPR

9500 MPR

9500 MPR NEO TE

TDM service

TDM link

Access Device

CalnexParagon Sync

CalnexParagon Syncwith MiTOP E1/T1

IPMUX-216/24

IPMUX-216/24

IPMUX-216/24

Access network

UNI

Metro network

TDM service

TDM link

RAD ACE-3205RAD ACE-3400

RAD ACE-3205RAD ACE-3200

NEC CX2600NEC CX2600

Alcatel-LucentAlcatel-Lucent9500 MPR 9500 MPR

Access Device

12




IXIA XM2IxNetwork

SIAE MICROELETTRONICA ALS

Rohde & Schwarz

NEC PASOLINK NEO

HuaweiNE5000E

Cluster System

Cisco

RADRICi-155GE

T-MPLS Metro


RADETX-202A

IXIA XM2IxNetwork

RADRICi-155GE

RADRICi-155GE



Telco SystemsT5C-24F

RAIPMUX-

HuaweiCX600-4

SpirentTestCenter

SIAECeragonFibeAir IP-10

Telco SystemsT5C-24G

MICROELETTRONICA ALS

Alcatel-Lucent1850 TSS-40 Tejas

TJ2030

Tellabs8830

RedbackSmartEdge 400

JuniperMX480

Cisco 7604

EricssonMarconi OMS 2400

TejasTJ2030


ECI SRAlcatel-Lucent7750 SR7

HuaweiNE40E-4

JuniperM10i

SpirentTestCenter

MTU-s

Telco SystemsT-Metro 200


RADLA-210

I

RADACE-3205

Alcatel-Luc7705 SA

RADASMi-54

JuniperMX480

ADVA FSP150CC-825

ActelisML658


CiscoME3400-12CS

MTU-s

JuniperMX240 NEC

CX2600


Alcatel-Lucent7705 SAR

Alcatel-Lucent9500 MPR

RADACE-3200 RAD

IPMUX-216/24

SymmetricomTimeCesium 4000

EC

FlexiHybrid

ADVA FSP150CC-825

Symmetricom TimeProvider5000 PTP Grand Master

RADETX-202A

FounNetIron XM

CambridgeVectaStar


ActelisML658

InfoVistaVistaInsight for Networks

Video Client

G

Gaming Client

7606

MPLS Metro


Alcatel-Lucent5650 CPAM

SITLine ETH

+MiRICi E1/T1

MTU-s

CienaLE-311vSpirent

TestCenter

RADETX-202A

+MiRICi E1/T1

Physical Network Topology

12


13

Mobile Backhaul

PBB-TE Metro

Metro/Core Network Device

Gigabit Ethernet

Access Device

Metro network

Access network

Aggregation Device

Network Areas

Connection Types

UNI

E-NNI

Core network

Fast Ethernet

TDMoNxE1/STM-1

ATMoNxE1/STM-1

Wireless

10 Gbit G709

RAN NC

G.SHDSL.bis

STM-16

10 Gbit Eth

Tester

Device Types

RAN BS

P Router

Aggregation network

Radio Transmission Device

SHDSL


RADETX-202A

RADETX-202A


ADVA FSP150CC-825

NECPASOLINK NEO TE

RADACE-3205

RADRICi-16

RADOP-1551

RADACE-3400

Rohde & Schwarz

IXIA XM2IxNetwork

6/24


CambridgeVectaStar

Telco SystemsT5C-XG

NEC PASOLINK NEO

HuaweiCX600-4

IXIA XM2IxNetwork

CiscoME4500

SpirentTestCenter

RADETX-202A

InfoVistaVistaInsight for Networks


MTU-s


Tellabs8830

NortelMERS 8600

Tejas2030

Tejas2030

Ciena LE-3300

SpirentTestCenter

IXIA XM2IxNetwork


SIAE MICROELETTRONICA ALFO


Nokia Siemens NetworksFlexi WCDMA BTS

NEC PASOLINK NEO

RADEgate-100

05

Rohde & SchwarzA XM2etwork

NECPASOLINK NEO TE

NortelMERS 8600 Ciena LE-311v

NortelMERS 8600

CeragonFibeAir IP-MAX2

MTU-s

CiscoCatalyst 3750-ME

MTU-s


Telco SystemsT-Marc 380

NECCX2600

RADACE-3200

10 MHz Clock

CalnexParagon Sync

SR9705hiD 6650

RACEL

y8000


CiscoME-3400-2CS

ADVA FSP150CC-825

Gaming Clients

Video Source

Video Client

ApplicationDemonstrations

Video Source

Video Client

ming Client

Gaming Client

SITLine ETH

SITLine ETH

Cluster System

running onE-Tree}

running onE-LAN}

13

14


Clock Synchronization IntroductionAcross all mobile network technologies, clocksynchronization is a topic of interest and majorconcern today. Base stations within a mobileoperator’s domain require a common clock for threereasons:

• General operation and frequency stability. Basestations need to keep their transmit frequenciesand time slots very stable to avoid interferences.

• Base station hand over. Voice calls shall notdrop when the cell phone is moving from onecell’s coverage area to the next. Clockfrequencies of the two base stations need to besynchronous to ensure that the phone cancontinue sending within its pre-assigned mobilenetwork slots nearly uninterruptedly.

• Common frequency transmission. In some mobiletechnologies, adjacent base stations transmitusing identical frequencies, leading to a largecommon frequency coverage area and allowingthe communication of end systems with multiplebase stations at the same time (MIMO). Thisnetwork service requires phase synchronizationof base station clocks to ensure that their signalsdo not extinguish each other.

The easiest way of providing a common clock is touse GPS. However, mobile operators do not alwaysprefer this solution due to technical or politicalreasons. Sometimes base stations do not havevisibility of the sky (pico cells in buildings, tunnels) orthe GPS receiver installation would be toocumbersome (femtocells at home).

Vendors offer a number of network-based clocksynchronization mechanisms. They can be selecteddepending on the precision requirements. Formobile backhaul, the base station frequency needsto be accurate to below 50 ppb (ITU-T G.812). Thenetwork clock needs to be three times more accurateto reach this goal — 16 ppb (ITU-T G.8261 draft).

Clock Synchronization Test Results

IEEE1588v2. For the first time in a public MobileBackhaul test, we verified interoperability of IEEE1588v2 based clock synchronization implementa-tions at this event. Symmetricom provided a TimePro-vider 5000 PTP Grand Master implementing the

Precision Time Protocol (PTP); Nokia SiemensNetworks’ Flexi WCDMA BTS received the PTPpackets as a slave clock over an E-Line across thebackhaul network. Calnex Solutions connected theirParagon Sync in between the master and slaveclock, witnessing the protocol exchange and inten-tionally dropping packets.

Figure 7: 1588v2 Synchronizationmeasurement

The master and slave clocks interoperated success-fully using the subset of IEEE 1588v2 Precision TimeProtocol required for frequency synchronization —the unidirectional SYNC messages. Via an E1 outputof the base station and using a Symmetricomsoftware, we examined the frequency accuracy ofthe base station. Figure 7 shows the first 85 minutesof a clock deviation measurement of the NokiaSiemens Networks Flexi WCDMA BTS synchronizedvia IEEE 1588v2 to the Symmetricom TimeProvider5000 PTP Grand Master clock. We started themeasurement after the first five minutes of deviceoperation — the amount of time the devices requirefor the initial clock synchronization. As shown in thediagram there is a peak of frequency deviation inthe first two minutes of the measurement, andanother peak at around 20–30 minutes. In any case,the deviation never exceeded 3.6 ppb (parts-per-billion). The deviation was most often measured ataround 0.6 ppb. The measured results demonstratesthe accurate synchronization of the Flexi WCDMABTS, and the test goal to achieve a frequencydeviation of below 16 ppb was fulfilled. Althoughwe did not conduct long term measurements asrequired in ITU standards due to a lack of time at thehot staging; the same test will be conducted live atCEWC for visitors to witness the clock accuracymaintained throughout the conference.For the same reasons, PTP impairments generated bythe Calnex Paragon Sync did not show visibleeffects. The base station has an internal temperature-controlled quartz as a fallback clock when theincoming IEEE 1588v2 signal is lost. This clock isaccurate enough for a couple of days of operation;we lacked the time to wait for it to degrade.

Adaptive Clocking. Another solution for somefrequency synchronization scenarios is adaptiveclocking. In this solution, the clock is regeneratedfrom the frequency of bits arriving on an emulatedTDM circuit. Assuming that the transmitter sendspackets at a known rate and precise intervals, the

Network Type

Freq

uenc

ySy

nchr

oniz

atio

n

Phas

eSy

nchr

oniz

atio

n

GSM X

3G (UMTS, CDMA2000) X

4G (LTE including MBMS) X X

4G (Mobile WiMAX) X X

15

Ethernet OAM

adaptive mode is usually accomplished on slaves byeither measuring packets inter-arrival time ormonitoring a buffer fill level (some adaptive clockrecovery mechanisms may also use timestamps).Adaptive clock works only for constant bit rateservices.As described in the "Circuit Emulation Service"chapter, the Alcatel-Lucent 9500 MPR, NECCX2600, NEC PASOLINK NEO TE, RADIPMUX-216/24, and RAD MiTOP-E1/T1 hosted bythe ETX-202A have successfully demonstrated andtested adaptive clocking.In addition we measured the value of the frequencydeviation as demonstrated between the RADACE-3200 and RAD ACE-3205 over a longmeasurement time. We connected the SymmetricomTimeCesium 4000 Master Clock to the RADACE-3200, and verified that the frequency accuracywas better than 16 ppb.

ETHERNET OAMEANTC interoperability events have integratedEthernet Operations, Administration andManagement (OAM) testing since 2006. Severaldifferent protocols fall under the category of EthernetOAM. In this event we have tested Ethernet in the

First Mile (EFM), and Connectivity FaultManagement (CFM), standardized by the IEEEunder 802.3ah and 802.1ag respectively, Y.1731,standardized by ITU-T, and E-LMI, specified by MEF.Over the past years we have seen a significantincrease in support in this area – in the first eventfour vendors tested their CFM implementations andfive vendors tested their EFM code. At our currentevent 12 vendors tested their EFM and CFM imple-mentations.Our service provider panel placed a high value onboth Ethernet OAM test areas and with the inclusionof both EFM and CFM in the new MEF 20 “UserNetwork Interface (UNI) Type 2 ImplementationAgreement” technical specifications a clearcontinuous need for testing has been established

Link OAMLink OAM is the name used by the Metro EthernetForum (MEF) to refer to clause 57 of the IEEE 802.3standards where OAM is defined for Ethernet in theFirst Mile. The protocol monitors the health andoperations of the UNI’s physical layer. The MEFrequires the usage of Link OAM between the UNI-Nand UNI-C starting from UNI type 2.2 and recom-

Discovery followed by

Dying Gasp Messages



Tellabs8830


HuaweiCX600-4

ActelisML658

ADVA FSP150CC-825

Loopback Mode


JuniperMX240

MTU-s

Cisco7604 Cisco

ME-3400-12CS

SpirentTestCenter

IXIA XM2IxNetwork

RADLA-210

RADETX-202A


FoundryNetIron

XMR 8000

MTU-s

CienaLE-311v

Telco SystemsT5C-24F


MTU-sRADRICi

155GE

RADRICi 16

JuniperMX480

MTU-sAccessDevice

AggregationDevice

MTUSwitch

Tester

Metro/CoreDevice

Figure 8: Ethernet Link OAM test results

16


mends the use of the protocol starting from UNItype 2.1.The idea behind the protocol is to assist operators inlocalizing last mile physical layer errors. The mostlogical location in the network where the protocolcould be used is between the Provider Edge device(a router or a switch) and the customer premisesdevice. Both devices can identify themselves to eachother and communicate problems with each other.The Provider Edge device can use a palette of toolsto verify that it can reach the customer premisesdevice therefore saving the provider the extreme costof sending engineers to the customer site to verifyphysical link issues.The following products successfully participated inthe Link OAM tests discovering and setting eachother in loopback mode: Actelis ML658, ADVA FSP150CC-825, Alcatel-Lucent 7450 ESS-6, CeragonFibeAir IP-10, Cisco 7604, Cisco Catalyst 3750-MEand Cisco ME-3400-2CS, Ciena LE-311v, FoundryNetIron XMR 8000, Huawei CX600-4, Ixia XM2IxNetwork, Juniper MX240, RAD RICi155GE, RADETX-202A, RAD LA-210 and RAD RICi-16, SpirentTestCenter, Telco Systems T-Marc-250, TelcoSystems T-Marc-380, Telco Systems T-Marc-340,Telco Systems T5C-24F, and Tellabs 8830.We performed an additional test within this areaverifying that a device, usually on the customerpremises is able to notify the Provider Edge device

that the loss of signal is due to the customer premisedevice being shut down. The message carried in theLink OAM frame is aptly called Dying Gasp. Threevendor pairs successfully performed this test: ADVAFSP 150CC-825 and Juniper MX240, Cisco 7604and Juniper MX480 and Ciena LE-311v with TelcoSystems T5C-24F.

Service OAMThe IEEE 802.1ag standard defines end-to-endEthernet based OAM mechanisms which arereferred to by the MEF as Service OAM. The supportfor Service OAM is mandatory starting from UNItype 2.1. In contrast to link OAM the major use ofCFM for service providers and enterprises is to verifyconnectivity across different management domains.A carrier can define a management domain level tobe used internally while allowing their customers toverify end-to-end connectivity over the network usinga different CFM level.Since the 802.1ag standard has been published inDecember 2007 this has been the first interopera-bility event where we could specify a finishedversion of the standards for testing which simplifiedthe testing. From 12 vendors who participated in thetesting, 11 had standards based implementations.For this interoperability event we added a test at therequest of the participating vendors to the Service

Continuity Check, Linktrace, Loopback Tests


NECPASOLINK

NortelMERS 8600


ActelisML658

ADVA FSP150CC-825


JuniperMX240

MTU-s

ECISR9705 Cisco

ME-3400-12CS

SpirentTestCenter

IXIA XM2IxNetwork

RADLA-210

RADETX-202A


FoundryNetIron

XMR 8000

NECCX2600



MTU-s

RADRICi

155GE

JuniperMX480

NEO TE

Continuity Check, Linktrace, Loopback Tests

Continuity Check, Loopback Tests, RDI

MTU-sAccessDevice

AggregationDevice

MTUSwitch

Metro/CoreDevice

Tester

and Remote Defect Indication (RDI)

Figure 9: Service OAM Test Results

TejasTJ2030

Cisco7604

CiscoME4500

17

Ethernet OAM

OAM area: Ethernet Remote Defect Indication(ETH-RDI). This message type, integrated into theContinuity Check Messages (CCMs), communicatesto a remote Maintenance End Point (MEP) that adefect condition has been encountered. When adefect condition is encountered on a MEP, that MEPwill set the RDI bit in CCMs for all MaintenanceEntity Group (MEG) levels affected. When the defectcondition is repaired or removed, the MEP will resetthe RDI bit in the appropriate CCMs. This messagetype is particularly useful as a way to notify a remoteMEP about MAC layer problems, changes to theconfigurations and such error conditions as suddenunidirectional connectivity.The following vendors successfully tested ServiceOAM’s Continuity Check, Linktrace and Loopbackfeatures as well as Remote Defect Indication: ActelisML658, ADVA FSP 150CC-825, Alcatel-Lucent7450 ESS-6, Ceragon FibeAir IP-10, ECI SR9705,Foundry NetIron XMR 8000, Ixia XM2 IxNetwork,Juniper MX240 and Juniper XM480, NEC CX2600and PASOLINK NEO TE, Nortel MERS 8600, RADRICi155GE, RAD ETX-202A, RAD LA-210, RADRICi-16, Spirent TestCenter, Telco SystemsT-Marc-254, Telco Systems T-Marc-250, TelcoSystems T-Marc-340, and Tellabs 8830.Cisco Systems demonstrated its pre-standard CFMimplementation between its Catalyst 3400-12CS,7604, ME4500, Catalyst 3750-ME, and theME-3400-2CS. All devices were able to use CFM todiscover each other, exchange Continuity CheckMessages, recognize and signal failure conditionsusing Remote Defect Indicator (RDI) and AlarmIndication Signal (AIS) when failure were simulatedin the demonstration topology and use loopbackand linktrace messages.

Performance MonitoringThe ITU-T specification Y.1731 defines two messagetypes for calculating loss and delay between twoEthernet OAM endpoints. Loss MeasurementMessages (LMMs) are sent which should be repliedto on arrival with Loss Measurement Replies (LMRs).The initiating device can make a calculation ofaverage loss by comparing the number of framessent by the initiating end with those received at thefar end. Delay is measured in a similar way, calcu-lating the time it takes for a Delay MeasurementReply (DMR) to come back for each DelayMeasurement Message (DMM). Similar to CFM, thistool helps both customers to learn about the servicethey are receiving, and operators to learn about theservice they are providing.These tests were performed using the Paragon Syncimpairment device provided by Calnex Solutions.First, messages were exchanged without anyimpairment to show a baseline interoperability.Then, loss and delay impairments were made to testthe accuracy of the calculations.The following devices tested their implementations ofthe two protocols: Ciena LE-3300, NEC CX2600,Nortel MERS 8600, RAD ETX-202A, and RAD

LA-210. In all cases LMMs and DMMs were repliedto with LMRs and DMRs. Despite this, many devicesdid not properly calculate frame loss. Delay calcula-tions on the other hand showed a high degree ofaccuracy between the different devices.

Figure 10: Performance Monitoring tests

While Performance Monitoring as specified in ITU-Tstandard Y.1731 has made its way into the test planfor previous EANTC interoperability events, this yearmarked the first set of results. This is underlined bythe amount of issues found in the implementationsunder test.

E-LMIThe current UNI Type 2 Implementation Agreement(MEF 20) states in section 9 that all UNI-C andUNI-N of type 2.2 must support Ethernet LinkManagement Interface (E-LMI). MEF 16 technicalspecification defines procedures and protocols usedfor enabling automatic configuration of the customerequipment to support Metro Ethernet services inaddition to relaying UNI and EVC status informationto the customer equipment.In the test case designed to test interoperabilitybetween E-LMI implementations we incorporated anadditional step in which metro devices willpropagate remote status indication over the EVCsand will use E-LMI to relay the information to the CEdevice. We were able to test the first half of the testcase between Alcatel-Lucent 7450 ESS-6 and Cisco7604 showing that the Alcatel-Lucent router wasable to notify the Cisco router using LDP TLVs aboutits Access Circuit (AC) being down. Due to lack oftime we did not verify the propagation of themessage to the CE device using E-LMI.

Loss Measurement Messages Exchanged

Delay Measurement Messages Exchanged

Impairment Device

Aggregation Device

Access Device

Metro Device

CienaLE-3300

RADETX-202A

NortelMERS 8600

NECCX2600

RADLA-210

CalnexParagon Sync

18


RESILIENCE AND FAULTDETECTION

One of the key aspects of carrier grade transporttechnologies is SONET/SDH-like resiliency mecha-nisms and fault detection. Based on historicalprecedence, SONET/SDH’s 50 ms restorationcapabilities has been used as the measurement stickfor all transport technologies to follow and thesedays, with Voice over IP (VoIP) and Mobile Backhaulwe see a real need for 50 ms restoration time.The sections to follow depict several failover andrestoration tests that were performed during theevent. We tested each transport technology’sresilience protocols interoperability and augmentedthese by native fault detection mechanisms (CFM forPBB-TE and T-MPLS and Bidirectional Fault Detection(BFD) for MPLS). We focused our Link Aggregationtests on the UNI therefore providing a complete end-to-end resilience and fault detection story.

Link AggregationSeveral physical Ethernet ports of Ethernet switchescan be bundled into a single logical Ethernetinterface. This capability is used to increase theamount of bandwidth and/or to provide a linkprotection mechanism. The capability is specified inIEEE 802.3 clause 43, and commonly known as802.3ad or just LAG (Link Aggregation Group). Inorder to create or change the members of a LAGgroup dynamically, Link Aggregation ControlProtocol (LACP) has been standardized and is usedbetween two Ethernet devices providing LAG.The MEF specified LAG as a protection mechanismon the UNI. Devices supporting MEF UNI type 2.2must support LAG and LACP which led us to require,as opposed to previous years, that vendorsparticipating in this test will use LACP and not thestatic configuration of link aggregation groups.In our lab we successfully tested LAG implementa-tions of 10 vendors in total, two of them wereanalyzer vendors. As the test was defined fordevices that implement UNI functionality weseparated the participants into UNI-C and UNI-Ndevices. At the UNI-C were ADVA FSP 150CC-825,Ceragon FibeAir IP-10, Ixia XM2 IxNetwork andSpirent TestCenter, while on the UNI-N Alcatel-Lucent 7450 ESS-6, Ciena LE-3300, ECI SR9705,Nokia Siemens Networks hiD 6650, RedbackSmartEdge 400, Telco Systems T5C-24G, and TelcoSystems T-Metro-200. We first verified that the linkaggregation groups were established between thetwo devices and then measured the failover time bypulling out of the primary link, followed by ameasurement of the restoration time by reconnectingthe primary link. In almost all cases we measuredfailover time below 31 ms, and restoration timebelow 25 ms. In one case we measured failover timeof 550 ms and around two seconds restoration time.Apart from the UNI, Link Aggregation can be used

in the core of the network at the External Network toNetwork Interfaces (E-NNI) or to provided addedlink capacity. In addition to the LAG tests at the UNI,we performed some LAG tests between directlyconnected devices within the metro and core areanetworks. The test pairs included: Alcatel-Lucent7750 SR7 and Ericsson Marconi OMS 2400, CiscoME-3400-12CS and Juniper MX480, NokiaSiemens Networks hiD 6650 and Telco SystemsT-Metro-200, and Spirent TestCenter with FoundryNetIron XMR 8000.

MPLS ProtectionSeveral resilience mechanisms exist in MPLS andmost have been tested in previous EANTC interoper-ability events. MPLS Fast Reroute (FRR) is one suchmechanism that was tested in 2006 and 2007 (thewhite papers are available on EANTC’s web site).MPLS Fast Reroute provides link and node protectionfor Label Switched Paths (LSPs), therefore, protectingthe services running within the LSPs. Since 12vendors participated in the MPLS metro area, someof which for the first time, the event provided themwith the opportunity to test their implementationsagainst others that were not previously tested.

AccessAggregation

Ixia XM2Nokia Siemens

ADVA FSPAlcatel-Lucent

Ixia XM2Ciena LE-3300

SpirentECI SR9705

Ixia XM2Telco Systems

Ixia XM2Telco Systems

Networks hiD 6650 IxNetwork

IxNetwork

7450 ESS-6 150CC-825

TestCenter

IxNetwork

IxNetwork

CeragonRedbackSmartEdge 400

T5C-24G

T-Metro-200

Access Device

Aggregation Device

FibeAir IP-10

LAG Members

Figure 11: LACP test pairs

19

Resilience and Fault Detection

In total 14 different MPLS Fast Reroute tests wereperformed during the interoperability test event. In12 of the combinations the MPLS Fast Reroute wastriggered on the Point of Local Repair (PLR) by a Lossof Signal (LOS) which was simulated by pulling theactive link from the PLR. The following devices partic-ipated in the role of the Point of Local Repair (PLR):Alcatel-Lucent 7450 ESS-6, Alcatel-Lucent 7750SR7, Cisco Catalyst 3750-ME, ECI SR9705,Foundry NetIron XMR 8000, Huawei CX600-4,Huawei NE40E-4, Nokia Siemens Networks hiD6650, Redback SmartEdge 400, and Telco SystemsT-Metro-200. The Merge Point (MP) is the routerwhich merges the backup and primary segments ofan MPLS tunnel. The following devices participatedas MPs: Alcatel-Lucent 7450 ESS-6, Cisco 7604,Huawei CX600-4, Huawei NE40E-4, NokiaSiemens Networks hiD 6650, Redback SmartEdge400, Telco Systems T-Metro-200, and Tellabs 8830.In 8 test combinations we measured failover timesbelow 30 ms. In one test combination we measuredfailover time below 100 ms, and in 3 test combina-tions we measured failover times below 380 ms andabove 100 ms. The importance of the test, however,was the protocol interoperability between the PLRs

and the MPs therefore we spent no time on trying toreconfigure the devices for faster failover times.In two MPLS Fast Reroute test combinations thetunnel failure was recognized by Bidirectional FaultDetection protocol (BFD). BFD allows the routers todetect failures of non-directly attached links andsignal the failure to its neighbors quicker than theIGP used in the network. In both tests the BFD trans-mission interval was configured to 50 ms.In the test combination between Cisco 7604 (actingas PLR) and Juniper MX480 (acting as MP) the BFDfailure detection was bound to the MPLS RSVP-TEtunnels configured for MPLS Fast Reroute. In this testout of service time of 154 ms was achieved.In the test combination between Foundry NetIronXMR 8000 and Tellabs 8830 the BFD failuredetection was bound to the OSPF routing process.The failure triggered by BFD caused the rerouting inOSPF process. This result in rerouting of RSVP-TEmessages and creation of a new segment of MPLStunnel. We measured 207 ms out of service time forthis test.

PLR Mid-Point MP

MPLS Metro/Core

PLR Mid-Point MP

MPLS Metro/Core

Huawei NE40E-4Alcatel-Lucent

7750 SR7

Huawei NE5000E

Tellabs 8830Cisco

Catalyst 3750-ME

Huawei CX600-4Telco SystemsT-Metro-200

NSN hiD 6650



Alcatel-Lucent

NSN hiD 6650

Alcatel-Lucent

Telco SystemsT-Metro-200NSN hiD 6650


Juniper MX480

Cisco 7604


Tellabs 8830


7450 ESS-6

7450 ESS-6

MPLS switch Working tunnelProtection tunnel


Redback

Tellabs 8830


Telco Systems

NSN hiD 6650

Telco SystemsTellabs 8830

Foundry NetIronXMR 8000

Huawei NE5000E

SmartEdge 400

T-Metro-200

T-Metro-200

ECI SR9705

Redback SmartEdge 400

NSN hiD 6650

Huawei CX600-4Redback

SmartEdge 400

Tellabs 8830


Huawei NE5000E

Huawei NE40E-4

Alcatel-Lucent7450 ESS-6NSN hiD 6650

Huawei CX600-4

Tellabs 8830


Figure 12: MPLS Fast Reroute test pairs

20


Figure 13: BFD test participants

Dual Homed MTU-sIn VPLS networks a hierarchical model can beinstalled by using Multi-Tenant Unit Switches (MTU-s)to offload the learning of MAC addresses and cutdown drastically the MAC tables on the VPLS PEs.However, as these spoke MTU-s connections are nota complete part of the MPLS network, inherent MPLSresiliency mechanisms may not be available.Therefore, the VPLS RFC (4762) describes a dualhomed model, which was successfully tested by theCiena LE-311v versus the Cisco 7604 and JuniperMX480 PEs, and by the Telco Systems T-Metro-200versus the ECI SR9705 and Nokia SiemensNetworks hiD 6650 PEs.

PBB-TE ProtectionResiliency in the PBB-TE domain was accomplishedby defining a protection PBB-TE trunk for a workingtrunk. In case of the single homed access devices theworking and protection trunks had the sameendpoints, but different mid-point PBB-TE switches. Incase of the dual homing, a single access device wasconnected to two different PBB-TE switches, so thatone endpoint of the working and protection trunkswas different.In both cases, the detection was done by trunkendpoint switches using CFM (CFM is described inthe Service OAM section). In almost all cases theContinuity Check Messages (CCM) transmissioninterval was configured to 10 milliseconds (ms), andin one case to 3.3 ms.The four vendors participating in the PBB-TE cloudwere able to show PBB-TE protection interoperability,as shown in the figure 14. In most cases the failovertime was below 51 ms, and restoration time below5 ms. In one case the restoration time was 718 ms.The high restoration time was explained by differ-ences between implementations. Some vendorsshutdown traffic on a trunk when they revert over tothe restored primary trunk and drop any traffic stillrunning on the backup trunk. Other vendors continue

to receive traffic on both trunks, but only transmit onone trunk. This ensures that the traffic is still receivedand reaches the destination.

T-MPLS ProtectionMultiple protection mechanisms exist in T-MPLS. BothT-MPLS path (T-MPLS path is equivalent to an MPLStunnel) and T-MPLS channel (a T-MPLS channel isequivalent to an MPLS pseudowire) can beprotected. During this event we demonstrated onlythe per path protection mechanisms.The T-MPLS linear 1:1 and 1+1 path protectionschemes were demonstrated by three EricssonMarconi OMS 2400 devices for 10 GigabitEthernet, STM-16 and 10 Gigabit G.709 interfaces.The protection schemes required two paths to bebuild to the same destination. In the 1:1 protection

Cisco 7604 Juniper MX480

Juniper MX480

PLR Mid-Point MP

Tellabs 8830Foundry NetIron

XMR 8000

Huawei NE5000E

MPLS Metro/Core

MPLS switch Working tunnelProtection tunnelBFD session

Ixia XM2 IxNetworkTejas TJ2030PBB-TE Metro

Working pathProtection path

PBB-TE Switch

Tejas TJ2030Tejas TJ2030

Nortel

Nortel MERS 8600

Ciena LE-311v2MERS 8600

Nortel MERS 8600

Nortel

Ciena LE-3300

MERS 8600Tejas TJ2030

Tejas TJ2030

Ixia XM2 IxNetwork

Nortel

Nortel MERS 8600

Ciena LE-311v2MERS 8600

Ciena LE-3300

Ciena LE-311v2

Tejas TJ2030

Nortel

Ciena LE-311v2

Nortel

Ciena LE-3300

NortelMERS 8600MERS 8600

Ixia XM2 IxNetwork

Ciena LE-311v2

Ciena LE-3300

NortelMERS 8600

MERS 8600

Figure 14: PBB-TE protection results

21

Management and SLA Reporting

one path is declared as active and the other is set inbackup mode. When the active path fails traffic isswitched to the backup path. The second scheme,1+1 protection, replicate all frames across bothactive and backup paths such that when the primarypath fails, the backup path is already carrying thelost frames. In almost all cases Ericsson demon-strated the failover and restoration times below35 ms for 1+1 protection and failover times below30 ms for 1:1 protection. The restoration time for1:1 protection was under 0.5 ms. In one test run wemeasured 76 ms failover time over 10 GigabitEthernet link for 1+1 protection.Alcatel-Lucent demonstrated with the TSS-40 devicesa pre-standard G.8132 T-MPLS ring protectionimplementation over STM-16 interfaces. In itsdemonstration Alcatel-Lucent showed failover timesbelow 30 ms and restoration time below 16 ms. Thetwo vendors already showed T-MPLS protectioninteroperability during EANTC’s Mobile Backhaulevent in January 2008 (report available onEANTC’s web site).The T-MPLS demonstration results are summarized inthe figure above.

MANAGEMENT AND SLAREPORTING

Since the inception of EANTC’s interoperabilityevents, we have been trying to interest managementand Service Level Agreement (SLA) reportingvendors to join the event and to answer thechallenge put forth by many service providers ofmeasuring and reporting on multivendor networkinfrastructure. Especially these days whenconverged networks are meant to support any typeof service, from residential Triple Play to sensitiveMobile Backhaul traffic, we see the need to monitor,measure and report on SLA performance in thenetwork.A customer will always be more impressed andlikely to stay with a provider when, throughproactive monitoring, problems are solved beforethey affect the end customer and SLAs are met.InfoVista, using VistaInsight for Networks, was ableto demonstrate its multivendor SLA monitoring andreporting capabilities by measuring jitter, framedelay, frame delivery ratio, interface utilizationstatistics, and Ethernet OAM measurements on theADVA FSP 150CC-825 for an EVC with another FSP150CC-825, Alcatel-Lucent SAM, and CiscoME-3400-12CS for an EVC with the Cisco Catalyst3750-ME. In addition, VistaInsight for networksidentified and monitored SNMP Management Infor-mation Base (MIB) objects on the participatingdevices from Cisco Systems, ECI Telecom, HuaweiTechnologies, Foundry Networks, Juniper Networks,Nortel, and Tellabs.Alcatel-Lucent demonstrated the 5650 Control PlaneAssurance Manger (CPAM), a vendor agnostic IP/MPLS control plane management solution, whichprovided real-time IGP topology maps, control planeconfiguration, and a look into route advertisementswithin the layer 3 services. The tool was helpfulsince many configurations were being made bymany different operators, helping to quickly identifyconfiguration issues.

EditorsThis document has been edited by Jambi Ganbar,Sergej Kaelberer, Jonathan Morin, Bionda Mueffke,Carsten Rossenhoevel and Gabriele Schrenk.

Alcatel-LucentAlcatel-Lucent

T-MPLS Metro

T-MPLS switch

T-MPLSTSS-40 TSS-40G.8132 draft protection

T-MPLS linear1+1 Protection

10 Gbit G709STM-1610 Gbit Ethernet

Ericsson MarconiOMS 2400


Ericsson MarconiOMS 2400T-MPLS linear

1+1 ProtectionEricsson Marconi

OMS 2400Ericsson Marconi

OMS 2400


T-MPLS linear1:1 Protection




Working pathProtection path

Figure 15: T-MPLS protection

19

22


ACRONYMS

Term Definition

AC Access Circuit

AIS Alarm Indication Signal

ATM Asynchronous Transfer Mode

B-MAC Backbone MAC

BFD Bidirectional Fault Detection

BGP Border Gateway Protocol

BRAS Broadband Remote Access Server

BSC Base Station Controller

CCM Continuity Check Message

CDMA Code Division Multiple Access

CE Customer Edge

CE-VLAN

Customer Edge Virtual LAN

CES Circuit Emulation Service

CFM Connectivity Fault Management

CPE Customer Premise Equipment

DMM Delay Measurement Message

DMR Delay Measurement Reply

DSL Digital Subscriber Line

E-LAN A multipoint-to-multipoint Ethernetservice. A LAN extended over a widearea

E-Line Point-to-Point Ethernet Service similarto a leased line ATM PVC or FrameRelay DLCI

E-LMI Ethernet Link Management Interface

E-NNI External Network-to-Network Interface

EFM Ethernet in the First Mile

ERPS Ethernet Ring Protection Switching

EVC Ethernet Virtual Connection

EVPL Ethernet Virtual Private Line

FRR Fast ReRoute

GSM Global System for Mobile

HSPA High-Speed Packet Access

IGP Internal Gateway Protocol

IS-IS Intermediate System to IntermediateSystem

LACP Link Aggregation Control Protocol

LAG Link Aggregation Group

LDP Label Distribution Protocol

LER Label Edge Router

LMM Loss Measurement Message

LOS Loss Of Signal

LSP Label Switched Path

LTE Long-Term Evolution (4th generation3GPP mobile services)

MAC Media Access Control

MBMS Multimedia Broadcast MulticastServices, integral part of LTE

MBMS Multimedia Broadcast MulticastService

MEG Maintenance Entity Group

MEP Maintenance End Point

MIMO Multiple-Input and Multiple-Output

MPLS Multi-Protocol Label Switching

MPLS-TP MPLS Transport Profile

MSC Mobile Switching Center

MTU-s Multi Tenant Unit Switch

OAM Operations, Administration andMaintenance

OPEX OPerating EXpenditure

OSPF Open Shortest Path First

PBB Provider Backbone Bridge

PBB-TE Provider Backbone Bridge TrafficEngineering

PE Provider Edge

PLR Point of Local Repair

PLSB Provider Link State Bridging

ppb parts-per-billion

ppm parts-per-million

PSN Packet Switched Network

PTP Precision Time Protocol

PW PseudoWire

QAM Quadrature Amplitude Modulation

QoS Quality of Service

RDI Remote Defect Indication

RFC Request For Comments

RNC Radio Network Controller

RSTP Rapid Spanning Tree Protocol

RSVP-TE Resource reSerVation Protocol TrafficEngineering

RTP Real Time Protocol

S-Tag Service Tag

SAToP Structure-Agnostic Time Division Multi-plexing (TDM) over Packet

SGSN Serving GPRS Support Node

SLA Service Level Agreement

T-MPLS Transport MPLS

TMC T-MPLS Channel

TMP T-MPLS Path

UMTS Universal Mobile Telecommunica-tions System

UNI User-Network Interface

VLAN Virtual Local Area Network

VoIP Voice over IP

VPLS Virtual Private LAN Service

VPN Virtual Private Network

VPWS Virtual Private Wire Service

Term Definition

23

References

REFERENCES

Ethernet Services Attributes Phase 2 (MEF 10.1)Requirements and Framework for Ethernet Service Protection in Metro Ethernet Networks (MEF 2)Circuit Emulation Service Definitions, Framework and Requirements in Metro Ethernet Networks (MEF 3)Metro Ethernet Network Architecture Framework - Part 1: Generic Frame-work (MEF 4)Ethernet Service Definitions (MEF 6)Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks (MEF 8)Abstract test suite for Ethernet Services at the UNI (MEF 9)User Network Interface (UNI) Requirements and Framework (MEF 11)User Network Interface (UNI) Type 1 Implementation Agreement (MEF 13)Abstract Test Suite for Traffic Management Phase 1 (MEF 14)Ethernet Local Management Interface (E-LMI) (MEF 16)User Network Interface (UNI) Type 2 Implementation Agreement (MEF Ballot)Provider Bridges (IEEE 802.1ad-2005)Provider Backbone Bridges (IEEE 802.1ah, draft 4.2)Provider Backbone Bridges Traffic Engineering (IEEE 802.1qay, draft 3)Shortest Path Bridging (IEEE 802.1aq)Media Access Control (MAC) Bridges (IEEE 802.1D)Media Access Control (MAC) Bridges Amendment 2:Rapid Reconfiguration (IEEE 802.1W)Virtual Bridged Local Area Networks (IEEE 802.1Q)Link Aggregation Control Protocol (IEEE 802.3ad)Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications.Amendment: Media Access Control Parameters, Physical Layers, and Management (IEEE Std 802.3ah-2004)Virtual Bridged Local Area Networks - Amendment 5: Connectivity Fault Management (IEEE 802.1ag-2007)Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) (RFC 4447)Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling (RFC 4761)Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling (RFC 4762)Fast Reroute Extensions to RSVP-TE for LSP Tunnels (RFC 4090)BGP/MPLS IP Virtual Private Networks (VPNs) (RFC 4364)Architecture of Transport MPLS (T-MPLS) Layer Network (ITU-T G.8110.1)Interfaces for the Transport MPLS (T-MPLS) Hierarchy (ITU-T G.8112)Characteristics of Multi Protocol Label Switched (MPLS) Equipment Func-tional Blocks (ITU-T G.8121)Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks (RFC 4717)Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) (RFC 4553)BFD For MPLS LSPs (draft-ietf-bfd-mpls-06.txt)Bidirectional Forwarding Detection (draft-ietf-bfd-base-08.txt)Generic Application of BFD (draft-ietf-bfd-generic-04.txt)BFD for IPv4 and IPv6 (Single Hop) (draft-ietf-bfd-v4v6-1hop-08.txt)Circuit Emulation Services Interoperability Specification, Version 2.0 (ATM Forum af-vtoa-0078.000, January 1997,ftp://ftp.atmforum.com/pub/approved-specs/af-vtoa-0078.000.pdf)Framework for MPLS in Mobile Backhaul Networks (IP/MPLS Forum 2007.102.03)Timing and synchronization aspects in packet networks (ITU-T G.8261/Y.1361)OAM Functions and Mechanisms for Ethernet Based Networks (ITU-T Y.1731)

EANTC AGEuropean Advanced Networking Test Center

IIR Telecoms

Einsteinufer 1710587 Berlin, GermanyTel: +49 30 3180595-0Fax: +49 30 [email protected]

29 Bressenden PlaceLondon SW1E 5DR, UKTel: +44 20 7017 7483Fax: +44 20 7017 [email protected]

This report is copyright © 2008 EANTC AG. While every reasonable effort has been made to ensure accuracy andcompleteness of this publication, the authors assume no responsibility for the use of any information containedherein.All brand names and logos mentioned here are registered trademarks of their respective companies in the UnitedStates and other countries.v1.1

Documents

Carrier Ethernet Services - The Future - EANTC€¦ · Nokia Siemens Networks hiD 6650 Flexi WCDMA BTS FlexiHybrid RACEL Nortel Metro Ethernet Routing Switch (MERS) 8600 RAD Data