Public Multi-Vendor Mobile Backhaul Interoperability Test ... · PDF filePublic Multi-Vendor...

Public Multi-VendorMobile Backhaul

Interoperability Test

Mobile World CongressBarcelona, February 2008

METRO ETHERNET FORUM

Mobile World Congress 2008 Mobile Backhaul Interoperability Event

DoPaNPhMMMEtReQEn

A few words from the Metro Ethernet ForumThe market for new mobile applications is growing at afast pace. Significant enhancements to the mobile back-haul infrastructure will be required. Unfortunately, growthis severely constrained by the costs and scalability issuesof legacy TDM (E1/T1) and ATM networks.This is where Carrier Ethernet comes in. It provides aviable solution to handle the technical and financial issuesof the growth. Carrier Ethernet services enable virtuallyunlimited scalability and uniformity across the end-to-endinfrastructure. Until networks have migrated to Ethernet,legacy services for backhaul migration can be providedas part of the Carrier Ethernet solutions as well. Theconcurrent rapid growth of Carrier Ethernet for wire-lineservices creates dramatic cost savings, as networks canbe integrated.

These are thefactors that createthe compellingreason for thevery rapid transi-tion to CarrierEthernet basedmobile backhaulnetworks. Further-more, CarrierEthernet networkswill be easier tomaintain andincreasing band-width will becomeno more than acentralized soft-

ware reconfigura-tion instead of remote hardware reconfiguration. Finally,mobile applications being broadband/IP centric, lendthemselves perfectly to Carrier Ethernet. It provides thenecessary reliability with full SLA support and full OAMcapabilities.

Editor’s NoteThe European AdvancedNetworking Test Center (EANTC)has been organizing interopera-bility events for transport technol-ogy solutions like ATM, MPLSand Carrier Ethernet for morethan 15 years. Based on theinsight into the market we gainedconducting regular vendorquality assurance tests and proofof concept tests with service

providers, we decided to enter into a new area of interop-erability testing - Mobile Backhaul.To assess the state of the art, we invited all vendors to testthe interoperability of their infrastructure solutions in ajoint test network. In a unique scenario that has been setup for public demonstration the first time ever worldwide,we verified solutions for an issue many carriers are nowfacing: Backhauling mobile applications over packetnetworks. As consumers worldwide are demanding higherdata rates, premium data services and expect to pay lessand less for these services, mobile carriers are facing withincredible challenges: Reduce the cost of data transfers,upgrade to new mobile standards, and at the same timemaintain or increase the service levels.These challenges and the work of the Metro EthernetForum (MEF) and IP/MPLS Forum set the scene for ourlatest interoperability test event. Our lab setup resembleda major service providers network, implementing an inte-grated, multi-service, next-generation core, aggregationand access network supporting high quality mobile back-haul services. Mobile equipment vendors attached realGSM and WCDMA base stations to test the backhaulservice quality.After four months of careful preparation, we were pleasedto welcome more than 85 devices from 15 participatingvendors to our lab in Berlin, Germany. 50 engineers fromthe participating vendors installed more than six tons ofequipment mounted in 16 racks.

Hot-staging Test Setup at EANTC, Berlin

Carsten RossenhoevelManaging Director

cument Structurerticipants Page 3etwork Design Page 4ysical Topology Page 6obile Backhaul Tests Page 8etro Technology Tests Page 10PLS Backbone Tests Page 12hernet OAM Tests Page 13siliency Tests Page 15uality of Service Tests Page 16d-to-End Services Page 18

2


The EANTC technical team, complemented by engineersfrom the University of New Hampshire Interoperability Laband from T-Systems (Deutsche Telekom Group), found reas-suring progress in interoperability. Not only did implemen-tations of the three major aggregation technologies(MPLS, PBB-TE, T-MPLS) interwork really well within theirrespective areas, they also interfaced well with the MPLScore once the MPLS, PBB-TE, and T-MPLS vendors hadagreed on a common interface. (The E-NNI interface is inneed of better definitions, though. See section below).Furthermore, resiliency test results met our expectationsacross the vendor combinations we tested. ATM and TDMservices across the packet networks and the diverse clock-ing methods worked very well in most cases.We were able to verify the functionality and performanceof the multi-vendor network when real HSDPA downloadswere able to achieve the expected bandwidth to streambroadband videos to a laptop, and phone calls werecarried at excellent speech quality.The fine art of mobile backhaul seems to be the knowl-edge of how to put the pieces together. Vendors also usedquite a few ITU-T and IETF standards for mobile backhaultransport and services. There is a wealth of solutions andoptions out there. The major upcoming work for the stan-dards organizations will be to streamline and condensethe specifications in collaboration with each other.This report summarizes the test areas and our findings indetail. We hope you will find it beneficial.

Participants and Devices

Vendor Participating Devices

Alcatel-Lucent 1850 TSS-31850 TSS-51850 TSS-401850 TSS-3207450 ESS-17450 ESS-7

Ceragon Networks FibeAir IP-MAX2

Ciena CN 3106CN 5060

Cisco 76067604CRS-1 [4 slot]

Ericsson Marconi OMS 2400RBS2409

Harris StratexNetworks

Eclipse (Gigabit) Radio

HuaweiTechnologies

SmartAX MA5600TOptiX OSN1900 (OptiXPTN1900)OptiX OSN3900 (OptiXPTN3900)Quidway CX600Quidway CX380Quidway CX300B (OptiXPTN1920)Quidway CX200B (OptiXPTN952)Quidway NE5000EQuidway NE40E

Ixia XM12

Lightstorm Networks Brooklyn-10

MRVCommunications

OptiSwitch OS304OptiSwitch OS910-MOptiSwitch OS9024-M

Nokia SiemensNetworks

hiD 6650Flexi WCDMA BTSRNC and Core NetworkEmulator (Racel)

Nortel Metro Ethernet RoutingSwitch 8600Multiservice Switch 15000

RAD DataCommunications

ACE-3200ACE-3400ETX-202

SpirentCommunications

TestCenterAX/4000

Telco Systems, aBATM Company

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

Vendor Participating Devices

3


Network DesignWe designed the test network with the target to build onthe services and technologies tested during EANTC’sMPLS World Congress and Carrier Ethernet WorldCongress interoperability events last year, and to addnext-generation mobile backhaul services to the mix.In all EANTC interoperability events we aim to constructnetworks that will resemble real world deployment asmuch as possible. This time, the addition of Mobile Back-haul to the application mix heightened scalability, resil-iency and flexibility requirements.Our lab network design resembles a number of currentcarrier topology scenarios:

• Access: The fixed network area adjacent to thecustomer site. Business and residential devices areterminated at the access. A range of access technolo-gies such as Ethernet over SONET/SDH, Ethernetover microwave radio links and Ethernet over copperwere evaluated.

• Radio Access Network (RAN): The wireless networkreaching out to mobile end-systems, providing voiceand data services (where mobile video can be a partof the data service). In contrast to the fixed accessnetwork, the RAN uses completely different transporttechnologies like 3GPP (GSM, WCDMA,CDMA2000), 4G (LTE) or WiMax. We used GSMand WCMDA as part of the mobile applicationdemonstrations.

• Metro/Aggregation: The network area in whichmany different services and access technologies areaggregated. We verified diverse technical solutionsto implement metro networks for Carrier Ethernetservices. On the access facing devices, MEF-definedUNI interfaces were tested while in the core facingdevices Network to Network (NNI) connections wererealized. Three metro/aggregation clouds wereconstructed: MPLS, Provider Backbone Bridge TrafficEngineering (PBB-TE) and T-MPLS.

• Core: We tested an MPLS-based backbone infrastruc-ture, transporting multiple packet-based services. Thecore supported connectivity between the differentaggregation clouds and end-to-end services.

The three metro areas were connected over the core. Eachemulated a separate metro service provider administrativedomain. The backbone itself was administratively dividedfrom the metro areas, resembling a longhaul inter-carriernetwork.

Mobile Backhaul IntroductionMobile Backhaul is a term used to describe connectivitybetween mobile base stations and radio controllers. In 3Gservices, a base station is called a NodeB. Individualnames for radio controllers also vary — GSM: basestation Controller (BSC), 3G: Radio Network Controller(RNC). We will use base station and base station control-lers as generic terms in this white paper.Traditionally, the interface between 2G base stations andradio controllers was based on a number of parallel TDMcircuits utilizing E1 or T1 links. Since cell phones’ mainusage was voice communication, such a decision waslogical as TDM was the standard way to transport voice.Since managing a large bundle of E1 circuits (typicallydelivered as channelized STM-1) was cumbersome at theradio controllers, the transport protocol was changed toATM in the 3G world to facilitate better multiplexing andscalability. E1 bundles were used, but they carried voiceservices over ATM inverse multiplexing (IMA) instead ofdirectly using E1 channels. Data and voice services wereseparated only at the radio controller, traveling the lastmile together.The amount of data traffic in 3G networks has grownfurther, so E1-ATM bundles became insufficient. Basestation vendors invented hybrid uplinks (E1-ATM for voice,Ethernet/IP for data). In some of today’s mobile networks,data traffic is handed to the packet switched network(PSN) already at the base station.Several market studies show that the transport networkcosts account for 20–30% of a mobile operator’s opera-tional expenditure (OPEX). The service revenue growth is,however, not matched by service growth rate. Theaverage revenue per user (ARPU) has decreased by 25%in the last two years for European mobile operators.

Figure 1: Mobile Backhaul Scope

Clearly hybrid offload will not be the end of mobile back-haul development. The amount of base stations per area is

AggregationNetwork

CoreNetwork

RNC

BSCMSC

GGSN

SGSN

Mobile Backhaul Focus

AccessNetwork

Radio

SGSN — Serving GPRS Support NodeGGSN — Gateway GPRS Support Node

MSC — Mobile Service Switching Center

BSC — Base Station ControllerRNC — Radio Network Controller

AccessNetwork

Radio

4


growing and new standards like LTE (»4G«) or WiMaXwill require even more bandwidth (in these standardsTDM interfaces are not even an option). In order tosupport all these, the number of E1/T1 links must befurther increased and for WiMAX and LTE new interfacesmust be supported. As a result service providers areconsidering mobile backhaul over packet switchednetworks (e.g. MPLS, PBB-TE and T-MPLS), as theseprovide enough bandwidth for the predicted increase indata traffic and are more cost effective than the currentTDM networks.To test mobile backhaul properly, not only the end goal(voice and data over packet networks) needs to be veri-fied; the migration paths are even more important. Thou-sands of base stations will not be upgraded immediately(some never). So in addition to the increase of bandwidthrequirements, new types of interfaces must be supportedbetween the new base stations and the new base stationcontrollers while still supporting the older interfaces thatare already in use.In this interoperability test event, we investigated a widerange of solutions to meet the requirements facing mobileoperators. These requirements and solutions are summa-rized in the table below and are expanded on in thiswhite paper.

Table 1: Mobile Backhaul Service Aspects

Mobile operators looking to connect base stations withtheir respective network controllers over a packet networkare facing several options:

• Splitting the real time traffic (typically voice andcontrol traffic) at the base station using a GenericInterworking Function (GIWF). This method, calledmixed mode transport, allows operators to keep theircurrent network operation using TDM for backhaulwhile off-loading the additional traffic generated byHSDPA or WiMax systems to a packet basednetwork. This solution allows the timing and synchro-nization to be provided by the original TDM trans-port.

• The second option uses a Generic Interworking Func-tion (GIWF) to transport all traffic over the MetroEthernet Network. This option requires that the GIWFis able to perform at least one of the encapsulationmethods transporting TDM or ATM traffic across theMEN and is able to provide clock synchronization tothe base station. The GIWF can either be located atthe base station site or at the edge router (centraloffice) site.

• When cell sites include base stations equipped withlegacy and Ethernet interfaces, the legacy interfacecould be used to deliver voice and clock synchroniza-tion, while the Ethernet interfaces could be used tooffload broadband data applications from the legacynetwork.

• New base stations are being introduced to themarket equipped with native Ethernet interfaces thatare able to transport all traffic over the Metro Ether-net Network. This is enabled by standardized (3GPPIub over IP) and proprietary (Abis over IP) interfacesbetween the base station and radio controllers.

Mobile OperatorRequirements Solutions / Test Areas

Support bandwidthgrowth and acompetitive costmodel

Packet services in the RadioAccess Network (RAN)

Support a diverse setof interface types atcell site

MPLS ATM and TDMPseudowires, Ethernet andIP

Implement network-based clocksynchronization

IEEE 1588v2, Real TimeProtocol (RTP), SynchronousEthernet, Network TimeProtocol Version 3 (NTPv3),external reference clock

Resiliency on parwith TDM network

MPLS, PBB-TE, T-MPLS andnative Ethernet resiliencymechanisms

5


Telco SyT-Marc

EricssonBSC

ork Co

Metro

T

HuQuidwa

Cisco7604

HuQuidwa

Quid

Telco SystemT-Marc-380

Cisco

M12

40ent

i OptiX1900

Telco ST-Met

ucentS-40

Physical Network Topology

RAD ACE-3200

7450 ESS-1Alcatel-Lucent

Telco SystemsT5C-XG

Harris StratexEclipse(Gigabit) Radio

Huawei SmartAXMA5600T

Netw

1850 TSS-3Alcatel-Lucent

MPLS

Telco SystemsT-Marc-340

Ixia XM12

RAD LA-110

T-MPLS Metro

Alcatel-Lucent7450 ESS-7

CiscoCRS-1

Ixia X

Alcatel-Lucent1850 TSS-320

Quidway NE40EHuawei

Cisco 7606

MRV OptiSwitchOS910-M

HuaweiOptiX OSN 3900

Telco SystemsT-Metro-200

Ixia XM12

Marconi OMS 2400Ericsson

1850 TSS-Alcatel-Luc

Ciena CN 5060

LightstormBrooklyn-10

SpirentTestCenter



EricssonMarconi OMS 2400

HuaweOSN

CeragonFibeAir IP-MAX2

RAD ACE-3200

HuaweiOptiX OSN 1900


Harris StratexEclipse(Gigabit) Radio



Ixia XM12



SpirentTestCenter

HuaweiQuidway CX200B

RAD ACE-3400

EricssonMarconi OMS 2400

HuaweiQuidway CX300B

Alcatel-L1850 TS

6


PBB

o SystemsMarc-250

onlation

Core

tro

E

SpirentTestCenter

SpTest

Huaweidway NE5000E

Huaweidway CX380

HuaweiQuidway CX600

N

RA

NSNFlex

tems380

HuawOptiX OSN

isco 7606

co SystemsMetro-200

CienaCN 506

MRVOptiSwitch OS30

MSS 15000Nortel


-TE Metro


RAD ETX-202

RAD ETX-202

EricssonRBS2409


Ixia XM12


Harris Stratexclipse(Gigabit) Radio

Ixia XM12

T5C-24GTelco Systems

SpirentTestCenter


Spirent

SpirentTestCenter

irentCenter

NSNhiD 6650


Ixia XM12

CN 3106Ciena

ortel MERS 8600

Nortel MERS 8600

D ACE-3200

i WCDMA

T5C-24FTelco Systems


Huawei OptiXOSN 1900


ei3900

0

NSNRacel Emulator

4

TestCenterHuawei

Quidway CX300B

Metro Network Device

Gigabit Ethernet

Access Network Edge Device

Metro Network

Access Network

UNI Metro Edge Device

Tester

Device Functionality in the Test

Network Areas

Connection Types

RAN BS

User-Network

Network-Network

Core Network

Fast EthernetTDMoNxE1/STM-1ATMoNxE1/STM-1

Wireless/Microwave10 Gbit/s G.709

RAN NC

Core Device

Radio Transmission System

SHDSL

Interworking Function

STM-16EoPDH10Gbit Ethernet

NC Emulator

BS Emulator

(Base Station)

(NetworkController)

Interface (E-NNI)

Interface (UNI)

7


Mobile Backhaul Test ResultsWe started by testing the migration path options asmentioned in the introduction above. Circuit emulationcapabilities were tested in several different areas in theinteroperability test network:

Figure 3: Circuit Emulation Tests

Circuit emulation refers to the process of encapsulatinganother signal or connection types, as TDM, ATM, andEthernet, for transmission over a Packet Switched Network(PSN).A Spirent AX/4000 was used to offer bidirectional trafficin addition to providing a reference clock source. Theinterfaces involved were STM-1, ATM IMA, T1, and E1.

Circuit Emulation in AccessWe successfully verified Circuit Emulation Service (CES) inthe access between MRV OptiSwitch OS910-M and TelcoSystems T-Marc-254 devices by using the Metro EthernetForum (MEF 8) specification to encapsulate TDM trafficarriving at an E1 interface over the packet switchednetwork (PSN). The circuit used an MEF-defined E-Linetransport service across the PBB-TE metro, the MPLS coreand the MPLS metro networks.Emulated ATM services in the access were tested in twocombinations: Between Nortel Multiservice Switch 15000and RAD ACE-3200 and between Nortel Multiservice

Switch 15000 and Nokia Siemens Networks FlexiWCDMA BTS. Both CES services used ATMoMPLS asdescribed in RFC 4717 to encapsulate the ATM circuits.The circuits were transported over the PBB-TE metro area.For the circuit emulation service between Nortel and RAD,Nortel terminated the service via ATM STM-1 interfaces,while RAD terminated it using ATM IMA n x E1 interfaces.On the E1 connection between RAD ACE-3200 and theTDM tester, the Eclipse (Gigabit) Radio from Harris Stratexprovided wireless transport.The circuit emulation service between Nokia SiemensNetworks and Nortel showed the evolution of new basestations, as the Flexi WCDMA BTS (a UMTS base station)is equipped with a Fast Ethernet and Gigabit Ethernetuplink to the network, providing the interworking functioninternally. The base station was connected to the MRVOptiSwitch OS304 which acted as a cell site CPE andprovided connectivity towards the aggregation network.

In addition, RAD demonstrated1 CES for TDM E1 circuitsbetween two RAD ACE-3200 devices, and Alcatel-Lucentdemonstrated CES using the SAToP encapsulation (IETFRFC 4553) over MPLS for TDM T1 circuits on the Alcatel-Lucent 1850 TSS-5 devices in the T-MPLS area.

Circuit Emulation in MetroCircuit emulation in the metro refers to the scenario inwhich the base station is connected using traditional TDMcircuits to a router which is responsible for encapsulatingthe circuits and forwarding the traffic to the base stationcontroller.Huawei demonstrated TDM circuit emulation servicesbetween the Huawei OptiX OSN 1900 and OptiX OSN3900 in the T-MPLS metro area for E1 physical interface.ATM circuit emulation service in the MPLS metro area wassuccessfully tested between Huawei Quidway CX300Band Ciena CN 5060. An E1 interface was terminated onthe Ciena router and an STM-1 interface on the Huaweiside. Some other vendors met interoperability challengeswith circuit emulation services. One service could not beestablished since the two implementations for signaling ofcircuit emulation services were incompatible. The issuecould have been identified by mapping protocol supportmentioned in the two data sheets. The second interopera-bility issue encountered was between two systems termi-nating an ATM pseudowire using a targeted LDP session.We identified the issue as a "malformed TLV" error whichwas caused by a pseudowire FEC mapping.Huawei also demonstrated ATM circuit emulation betweentheir systems, the Quidway CX300B and the OptiX OSN

ATM Service TDM Service

Ethernet Based(MEF-8)

MPLS Based

MRV

HuaweiOptiX OSN

HuaweiOptiX OSN39001900

HuaweiQuidwayCX300B

CienaCN 5060

HuaweiQuidwayCX300B

HuaweiSmartAXMA5600T

NortelMSS 15000

RADACE-3200



Cisco7606

RADACE-3200

RADACE-3200

RADACE-3200

NortelMSS 15000

Nokia

Flexi

TelcoSystemsT-Marc-254

OptiSwitchOS910-M

SiemensNetworks

WCDMA BTS

1.Please note that we use the term »tested« when reporting onmulti-vendor interoperability tests. The term »demonstrated«refers to scenarios where a service or protocol was termi-nated by equipment from a single vendor on both ends.

8


3900 as well as between the OptiX OSN 3900 andOptiX OSN 1900. Both demonstrations were performedin the T-MPLS metro using STM-1 interfaces.

Inter-Domain Circuit EmulationServicesAs was discussed above, one of the deployment scenariosinvolves a Generic Interworking Function (GIWF). Theseunits are commonly installed by the mobile operator at thecell site. The mobile operator then manages these GIWFdevices and hands over the emulated circuits to a packet-based metro network which aggregates the circuitstowards the base station controller.ATM E1 and TDM E1 circuit emulation was testedbetween Cisco 7606 and RAD ACE-3200. The RADdevice was located in the access while the Cisco devicewas located in the metro aggregation. The two deviceswere connected using a microwave link provided byCeragon Networks FibeAir IP-MAX2 and used LDP-signalled MPLS pseudowires to provide the circuit emula-tion service. Cisco and RAD tested three types of circuitemulation over MPLS: SAToP (RFC 4553), ATMoMPLS(RFC 4717) and CESoPSN (RFC 5086).Huawei Technologies demonstrated ATM CES betweentheir devices SmartAX MA5600T acting as a cell siterouter, Quidway CX300B and OptiX OSN 3900, both ofwhich were positioned in the MPLS metro area. ATM E1CES was configured on the SmartAX MA 5600T side andATM STM-1 CES on the OptiX OSN 3900 side.Huawei Technologies also demonstrated TDM E1 CESbetween their OptiX OSN 3900 and Quidway CX200B.In all demonstrations Huawei used LDP for signalling ofMPLS CES pseudowires. The Huawei Quidway CX200Band SmartAX MA 5600T devices were located in theaccess, while the Huawei OptiX OSN 3900 andQuidway CX300B devices were located in metro. Thetransport was realized by MPLS tunnels, statically config-ured on the UNI and dynamically signalled over the MPLSmetro network.

Clock SynchronizationThe base stations within a mobile operator’s domain mustoperate using a common clock. This clock synchronizationrequirement is set according to the various mobile technol-ogies (e.g. GSM, CDMA, UMTS etc). A mobile backhaulnetwork transporting a certain mobile technology must beable to fulfill the requirements associated with said tech-nology at the radio interface.When a time or frequency reference is carried across thenetwork, other requirements apply. These requirementsare not yet standardized. ITU-T G.8261 mentions in itsmost recent version (WD11, September 2007) a goal for

accuracy of the reference frequency of significantly below50 ppb, if possible around 16 ppb. The value of 16 ppbis derived from ITU-T G.812 Type II frequency accuracy.We measured the frequency accuracy at the networkegress and compared it to these requirements.At our interoperability event two solutions were tested foradaptive service clock synchronization. In general, adap-tive clock synchronization regenerates the clock informa-tion from the data stream. Assuming that the transmittersends packets at a known rate and precise intervals, theadaptive mode is usually accomplished on slaves byeither measuring packets inter-arrival time or monitoring abuffer fill level (some adaptive clock recovery mechanismsmay also use timetamps). Adaptive clock works only forconstant bit rate services.One test was performed between MRV OS910-M andTelco Systems T-Marc-254. The clock synchronization solu-tions of MRV and Telco Systems are based on the linetiming method described in MEF3/MEF8, which is anadaptive clock recovery method. The slave recovered theservice clock based on the received E1 data rate, derivingthe master’s transmission rate.Another test was performed between Cisco 7606 andRAD ACE-3200. In this test scenario the Cisco 7606 wasconfigured to be the master clock while the RAD ACE-3200 recovered the clock from a CESoPSN MPLSpseudowire provisioned with a single DS0.The external reference clock method (as defined in MEF 8)was used in two tests: Between RAD ACE-3200 andNortel Multiservice Switch 15000, and between NokiaSiemens Networks Flexi WCDMA BTS and Nortel Multi-service Switch 15000. In this method, an external refer-ence clock was recovered from the legacy TDM network.The Spirent AX/4000 supplied the external referenceclock source to the devices under test using a legacy E1interface.Alcatel-Lucent 1850 TSS-5 demonstrated differentialservice clock recovery for circuit emulation services usingIEEE 1588 version 2 to distribute the reference clock.

Figure 4: Sample Jitter/Wander Measurement

Huawei demonstrated a clock synchronization methodbased on synchronous Ethernet using their SmartAX

9


5600T and OptiX OSN 3900 and a combination of twosynchronization methods for a single circuit emulation:Proprietary adaptive clock with Synchronous Ethernet. Thecircuit emulation was configured between Huawei devicesQuidway CX200B and OptiX OSN 3900 as described inthe previous section. The transport was realized viaHuawei OptiX OSN 1900. The clocks on the HuaweiOptiX OSN 1900 and the OptiX OSN 3900 weresynchronized using Synchronous Ethernet while the clockson the OptiX OSN 1900 and Quidway CX200 weresynchronized by proprietary adaptive solution.We measured wander according to the ITU-T G.823 stan-dard over a duration of 900 seconds between: Cisco7606 and RAD ACE-3200; Huawei TechnologiesSmartAX 5600T and OptiX OSN 3900; MRV OS910-Mand Telco Systems T-Marc-254. During the wandermeasurements, we observed frequency deviation belowthe expected 16 ppb which meant that all participants inthe test could deliver the required frequency accuracy.

Mobile Application DemonstrationsTwo scenarios between real Radio Access Network basestations and Radio Access Network controllers weresuccessfully demonstrated. The first scenario demonstrateda packet based mobile backhaul for WCDMA technologybetween Nokia Siemens Networks devices, a FlexiWCDMA base station and a Racel network emulator. Thetransport service was provided by the PBB-TE metronetwork by Nortel Metro Ethernet Routing Switch 8600and Nokia Siemens Networks hiD 6650. The NortelMultiservice Switch 15000 configured an MPLS basedATM CES in the access network for Racel Emulator. TheATM CES was terminated on the Flexi WCDMA basestation. The Racel device emulated a WCDMA Networkcontroller along with an entire mobile operator corenetwork. The common clock source was provided bySpirent AX/4000. Nokia Siemens Networks were able todemonstrate a mobile host receiving video over a radioconnection.The second scenario demonstrated a packet based mobilebackhaul for GSM using an Ericsson RBS 2409 basestation at EANTC facilities and a live Ericsson BSC andcore network in Sweden. The RBS 2409 uses Ericsson’snative Abis IP interface for GSM and was connectedthrough EANTC’s metro network to the BSC in Sweden viathe Internet. The metro transport was realized in the PBB-TE metro network by Nortel Metro Ethernet Routing Switch8600 and Huawei Quidway CX600 and CX380. In theaccess network the base station was connected over theRAD ETX-202 and the Ceragon FibeAir IP-MAX2. The Eric-sson GSM base station uses standard Ethernet interfaceswith IP communication for all backhaul traffic to the metrotransport. At the other end, the Telco Systems T-Marc-380provided connectivity to the Ericsson BSC using an IP/VPN tunnel over the Internet. The synchronization between

the base station and the BSC used standard NTPv3 proto-col. Ericsson demonstrated live phone calls betweenmobile phones attached to the base station and to exter-nal mobile networks. In addition, this connection main-tained a constant data stream for video using Edge.Alcatel-Lucent 1850 TSS-3 demonstrated Ethernet overPDH (EoPDH) using the standardized ITU-T G.7041 GFPwith G.7043 for PDH virtual concatenation. EoPDH is astandard defining the transport of Ethernet frames overcopper infrastructure.

Metro Transport TestsWe tested application services (mostly Carrier Ethernetbased) across three different types of metro transportnetworks:

• MPLS – A set of protocols defined by the IETF and theIP/MPLS Forum; positioned to deliver layer 2 andlayer 3 services including Ethernet services asdefined by the MEF; fairly agnostic to the underlyingtransport technology.

• PBB-TE – Focuses on transport using Ethernet as thetransport medium; aiming to offer a similar connec-tion oriented model and resiliency capabilities asSONET/SDH networks; IEEE draft is in version 1.1and is making its way through the standards process.

• T-MPLS – ITU-T standardized networking layer forpacket transport networks, based on MPLS dataplane, designed for providing SONET/SDH-likeOAM and resiliency for packet transport networks.

We assigned all participating aggregation devices to thethree groups based on the transport technology of thevendors’ choice. The physical layer was realized using adiverse set of technologies dominated mostly by GigabitEthernet links, in addition to point-to-point microwavelinks, OTU2 (ITU-T G.709) and STM-16.The different metro/aggregation cloud tests are describedin detail below.

MPLS for AggregationThe tests in this area were based on previous experiencelargely gained from EANTC’s Carrier Ethernet WorldCongress and MPLS World Congress interoperability testevents. Many carriers are considering MPLS as a maturetechnology with well defined standards and a wide installbase. Still, the question was, in just how far is MPLS readyto support Mobile Backhaul transport?The MPLS metro/aggregation cloud included equipmentfrom seven vendors and operated independently from thecore network (where MPLS was used as well). MPLSrouters participating in this area included Alcatel-Lucent7450 ESS-1, Ciena CN 5060, Cisco 7606 and CRS-1,Huawei Technologies Quidway NE40E, OptiX OSN

10


1900, OptiX OSN 3900 and Quidway CX300B, MRVOptiSwitch OS9024-M and Telco Systems T-Metro-200.The Eclipse Gigabit Radio from Harris Stratex providedan adaptive modulation microwave link between theAlcatel 7450 ESS-1 and Cisco CRS-1. The Cisco CRS-1,physically a core router, was put in the MPLS aggregationto provide more test opportunities and more connectionsto other vendors' systems.A VPLS domain implementing multipoint-to-multipoint trans-port services was established between the followingrouters without any issues: Alcatel-Lucent 7450 ESS-1;Cisco 7606 and CRS-1; Huawei Technologies QuidwayNE40E. Ixia XM12 participated as a partially meshed PEin the MPLS metro by emulating a VPLS PE with a fullprotocol stack implementation, forming an adjacency withone other PE. A few pseudowires between a VPLS PEdevice and MTU devices required longer time to configurethan expected since the VPLS PE device did not support anH-VPLS spoke function initially. The problem, however,was quickly solved through a code downgrade and thespokes were established.The following devices participated as Multi-Tenant Units(MTUs) in an H-VPLS domain: Ciena CN 5060; Cisco7606; Huawei Technologies OptiX OSN 1900 andQuidway CX300B; MRV OptiSwitch OS9024-M andTelco Systems T-Metro-200.OSPF was used amongst most of the participants,however, a few devices supported only IS-IS. A routegateway was configured to link both IGP domains.Point-to-point transport services were realized usingVirtual Private Wire Services (VPWS). No problems wereencountered when activating the VPWS services.

Provider Backbone BridgeTraffic EngineeringWe had tested PBT during the Carrier Ethernet WorldCongress 2007 interoperability test event as a precursor,based on a draft version 0.0, to what is now referred toas PBB-TE. Since then the IEEE standard has movedforward and is now in draft version 1.1 (as of December21, 2007). Devices from five vendors participated in thetest of PBB-TE trunk establishment and data forwarding:Ciena CN 3106; Huawei Quidway CX380 andQuidway CX600; Lightstorm Brooklyn-10; Nokia SiemensNetworks hiD 6650; and Nortel Metro Ethernet RoutingSwitch 8600. Ixia XM12 emulated PBB-TE trunk end-points with a full protocol stack implementation. SpirentTestCenter maintained PBB-TE trunks where necessarythrough the emulation of Ethernet CFM. Between two ofNortel’s Metro Ethernet Routing Switch 8600 a micro-wave link was created using Ceragon FibeAir IP-MAX2

showing trunk level prioritization and protection withadaptive modulation.The PBB-TE standard draft recommends the use of an

external control plane/management system to configuretrunks. Two such management systems participated inEANTC’s Carrier Ethernet World Congress interoperabilitytesting in 2007 (please see EANTC’s web site for thereport). Since no PBB-TE management vendor participatedin the interoperability event, all PBB-TE trunks were config-ured manually.PBB-TE is based on existing Ethernet standards, and asexpected data forwarding worked without any problems.The draft requires the use of Connectivity Fault Manage-ment (CFM) in order to establish the PBB-TE trunks. Not allvendor implementations supported CFM and so IxiaXM12 was used to generate CFM frames on behalf ofthese switches. Furthermore, one device could not transmitCCM messages on its PBB-TE trunks. The vendor was ableto install a code update and bring the trunks up within thecourse of testing.Multiple transport services within the PBB-TE metro areawere mapped into a single PBB-TE trunk using a unique I-SID and B-VID. Services meant to cross the MPLS corenetwork originating from the same device were mappedto a single PBB-TE trunk using a different I-SID. One PBB-TEtrunk was configured between Ciena CN 3106 andNortel Metro Ethernet Routing Switch 8600, traversing theAlcatel-Lucent 7450 ESS-7 and Huawei TechnologiesQuidway NE5000 in the core network.

Figure 5: Logical Provider Backbone BridgesTraffic Engineering Trunks

Transport MPLS (T-MPLS)T-MPLS was tested for the second time at an EANTCinteroperability event; several new vendors and devicesparticipated in the test this time. T-MPLS is a transport tech-nology aiming to deliver a way for carriers to virtualize awire and offer the same predictive paths as carriers areused to in the SONET/SDH world. T-MPLS is defined inseveral ITU-T draft documents either approved or underapproval (see references section). T-MPLS paths (TMP) areend-to-end tunnels which aggregate T-MPLS channels

Huawei

PBB-TE TrunkTester

IXIA

Spirent

Huawei

Metro network provider edge

Quidway

TestCenter

Quidway

NSN hiD6650

CX380

CX600 XM12Ciena

CN 3106


NortelMERS 8600

11


(TMC) representing the services. In addition, the T-MPLSprotocol family defines OAM and protection mechanisms.The T-MPLS reference standard does not define a specificcontrol plane, but the future use of the GMPLS controlplane is not precluded (e.g. RSVP-TE for signaling; OSPF-TE and ISIS-TE for routing). SInce no control plane wasused during the testing, the T-MPLS connections betweendifferent vendors were manually configured. The connec-tions between the different Alcatel-Lucent devices in the T-MPLS area were configured using a proprietary Alcatel-Lucent 1350 Management System.

Figure 6: Logical T-MPLS Channels (TMCs)

During the configuration of TMCs and TMPs we discov-ered an interoperability issue between two of the partici-pants. One vendor required the TMP labels and TMClabels to be allocated from two different label pools whileanother vendor had the opposite configuration limitations:If a TMC label came from a certain label pool its TMPsalso had to come from the same label pool. The problemwas solved by simply reconfiguring the limits of the labelpools on the first vendor’s equipment.The following devices were part of the T-MPLS metro cloudand have successfully tested and demonstrated the T-MPLSPath (TMP) and T-MPLS Channel (TMC) establishment,data forwarding over T-MPLS and T-MPLS Multiplexing inwhich a number of TMCs were transported within a TMP:Alcatel-Lucent 1850 TSS-40, 1850 TSS-320; Ciena CN5060; Ericsson-Marconi OMS 2400; Huawei OptiX OSN

3900 and OSN 1900; Ixia XM12; Lightstorm Brooklyn-10. In addition, Harris Stratex Eclipse (Gigabit) Radioprovided the UNI connection between an emulated basestation and Huawei’s OSN 1900.An addition to the devices’ capabilities in the T-MPLSmetro area was bridging instance support, which couldbe used to map a TMC or a VLAN to interfaces, and func-tionality similar to H-VPLS spoke connection. This allowedthe T-MPLS vendors to offer a multipoint-to-multipointservice much like MPLS’ Virtual Private LAN Services(VPLS) in MPLS networks. MAC learning was done usingflooding and dynamic address learning or using MACaddress static configuration. However, unlike VPLS inMPLS networks, no signalling was used. At the moment nostandards exist for native multipoint to multipoint servicesin T-MPLS networks.

MPLS CoreConnectivity between the three different transport/metroareas was facilitated using MPLS. The core area wasconstructed using an Alcatel-Lucent 7450 ESS-7, Cisco7604 and Huawei Quidway NE5000E. The coreprovided transport both point-to-point and multipoint-to-multipoint Ethernet services in addition to establishing anIP/MPLS L3VPN service between Huawei and Cisco(based on RFC 4364). Point-to-point services were imple-mented with Ethernet pseudowires while multipoint-to-multipoint services were implemented using VPLS with LDPsignaling between the three vendors.

Connecting AdministrativeDomainsPoint-to-point services over the MPLS core were realizedusing MPLS pseudowires. The services were mapped intopseudowires based on Provider Bridges tags as they wereleaving the metro areas. Each metro area terminated thepoint-to-point service using an S-VLAN (A vlan significantonly to the service provider) and handed the frames, nowwith two VLAN tags, to the core. The core used the S-VLAN tags as service delimiters and then forwarded theframes to their destination metro area.

IXIA

Ericsson MarconiAlcatel-Lucent

Ciena

Lightstorm

Huawei

Huawei

Alcatel-Lucent

OMS 2400

CN 5060

XM12

OptiXOSN 3900

1850 TSS-320

Brooklyn-10

1850 TSS-40

OptiXOSN 1900

T-MPLS TMCTester


“Spoke“ H-VPLS pseudowire

VPLS connection

VPLS provider edge

H-VPLS Multi-Tenant Unit

Cisco7606

Alcatel-Lucent7450 ESS-1

HuaweiQuidway NE40E

CiscoCRS-1



CienaCN 5060


Cisco7606

LDP VPLS(full-mesh connected)

Figure 7: Logical H-VPLS Metro Connections

12


In one case a service was transported across the T-MPLSand MPLS network boundary without Ethernet bridging. ATMC was statically configured in the T-MPLS area betweentwo Alcatel-Lucent 1850 TSS-40 devices and an MPLSpseudowire was dynamically signaled between Alcatel-Lucent 1850 TSS-40 and Cisco 7604. The TMC topseudowire interworking (stitching) between the static anddynamic segments was performed by the Alcatel-Lucent1850 TSS-40.One point-to-point Ethernet service was implementedacross two metro areas using a TMC between HuaweiOptiX OSN 3900 and Alcatel-Lucent 1850 TSS-320, andhanding off to the Ciena CN 5060 in the MPLS metro viaa static MPLS label. Unfortunately none of the corevendors found time to test the T-MPLS/MPLS inter-workingon any of the Inter-AS interfaces based on the static labelconfiguration.For multipoint-to-multipoint services, three VPLS instanceswere configured: One in the T-MPLS metro, the MPLS coreand the MPLS metro networks each. Two VPLS spokeconnections were configured in the core towards the T-MPLS network. One used a dynamically signalled MPLSpseudowire, which was configured between Alcatel-Lucent 1850 TSS-40 and Cisco 7604. The secondconnection was performed by the Alcatel-Lucent1850 TSS-40 performing the interworking between MPLSand T-MPLS.Cisco demonstrated inter-provider L3VPN connectivitybased on RFC 4364 option C. The connection was madebetween the Cisco CRS-1 positioned in the MPLS aggre-gation area and the Cisco 7604. Several solutions exist toenable an L3VPN to cross different administrativedomains. In particular, the IETF defined three optionswhere MPLS/BGP VPNs can be supported across an ASboundary using readily available protocols. To customersthe three options is transparent. To service providers, eachoption requires a different level of trust relationship at theboundary. Option C is the most integrated method inwhich the two provider networks must function as one,forming one single large end-to-end VPN domain. Eachoption has its pros and cons, as well as its value proposi-tion. All three options were tested.

Ethernet OAM TestsWe tested two Ethernet Operation, Administration andMaintenance (OAM) standards in previous Carrier Ether-net World Congress Interoperability events:

• IEEE 802.1ag – Connectivity Fault Management(CFM)

• IEEE 802.3ah – Ethernet in the First Mile (EFM),specifically section 57

For this event we added the ITU-T standard Y.1731 “OAMfunctions and mechanisms for Ethernet based networks” tothe agenda.

Native Ethernet fault management protocols are essentialfor the delivery of high quality end-to-end services to busi-ness customers, mobile base stations and increasinglyalso consumers (for example for IPTV or VoIP). The serviceavailability is key for many customer applications; it canbe managed using Ethernet OAM protocols. The testsdescribed below are a subset of the rich set of OAM toolsavailable today for Ethernet.

Ethernet Link OAMThe Ethernet in the First Mile IEEE standard extends theEthernet Media Access Control (MAC) layer to additionalphysical layers such as voice grade copper cable. As partof the standard, a set of OAM tools are defined aiming tohelp carriers monitor link operations. We tested the follow-ing three functions:

• Link OAM Discovery – Detecting the existence andconfiguration of the OAM sublayer in the neighbor-ing Ethernet equipment

• Link OAM Loopback – Configuring a loopback modefor fault localization and link performance testing

• Link OAM Dying Gasp – Notifying the neighborabout an imminent system shutdown

The following vendors participated successfully in theOAM discovery test: Alcatel-Lucent 7450 ESS-1 and7450 ESS-7; Ciena CN 3106 and CN 5060; Cisco7604 and 7606; Huawei Quidway CX380 andQuidway CX600; MRV OptiSwitch OS9024-M; RAD ETX-202; Spirent TestCenter; Telco Systems T5C-XG, T-Marc-250 and T-Marc-380. Spirent TestCenter facilitated thetesting with a full stack implementation of 802.3ah.No problems were discovered during the initial discoveryphase of the testing.

Figure 8: Ethernet Link OAM Tests


Access network device

Metro UNI provider edge

Cisco

Alcatel-Lucent Core

Telco Systems

Spirent

Cisco7604

7450 ESS-7TestCenter

7604 TelcoSystems

T-Marc-380Ciena

CN 5060Cisco7606

RADETX-202Spirent

TestCenter

Aggregation

T-Marc-250

OAM DiscoveryLoopback Mode Dying Gasp Messages

Tester

AccessTelco Systems

T5C-XG

CienaCN 3106

HuaweiQuidwayCX380

MRVOptiSwitchOS9024-M

13


12 device pairs participated in the EFM loopback testing.Loopback testing varied between vendors based on themodes they supported. Passive devices supported enteringand exiting loopback state while Active devicescommanded Passive devices to enter Loopback. The testswere verified in one of two ways depending on thedevices involved in the testing. When two devices wereinvolved the roles were agreed between the vendors.When only one device was involved, Spirent TestCenteremulated either passive or active role.Some interoperability issues were discovered during theLink OAM Loopback testing. In one case a vendor wassending unexpected PDU types which caused its peer todrop the PDUs. In another case we discovered that avendor was not incrementing the TLV revisions andanother vendor could only operate in a Passive mode.OAM interoperability testing is specifically important: It isquite likely that the customer premises equipment (CPE)and the switches terminating the metro/aggregation cloudwill be supplied by different vendors in real networks.Service providers need to rely on remote fault localizationand performance verification in order to keep SLAs andoffer a profitable service. While it is positive to see agrowing number of Ethernet OAM implementations, a lotof work still needs to be done in testing compliance andinteroperability.The Dying Gasp test was performed between eight pairsof devices. Participating devices’ roles were asymmetric:The customer-side device generated the dying gasp whilethe network-side device was responsible for receiving andprocessing the message.This test was successful between almost all pairs. Oneinteroperability issue was found between two devices inwhich a vendor was sending Dying Gasp message in anOrganization Specific (OAMPDU code 0xFE) PDU typewhile the receiving vendor was expecting the PDU in theInformation type (0x00). As a result, the vendor receivingthe Dying Gasp did not detect the message.

End-to-End Ethernet Service OAMIn contrast to link OAM, Connectivity Fault Management(as defined in IEEE 802.1ag) allows up to eight layers ofend-to-end service monitoring through different manage-ment domains and can be used across logical connec-tions. This standard is referred to as Service OAM in MEF17.The major use of CFM for service providers and enter-prises is to verify connectivity across different manage-ment domains. A service provider can define a manage-ment domain level to be used internally while allowingtheir customers to verify end-to-end connectivity over thenetwork using different management domains.At EANTC, we already tested service OAM – specificallythe Continuity Check functionality – at Carrier Ethernet

Figure 9: Ethernet Service OAM Tests

World Congress 2006 and 2007. Each year we receiverequests from vendors to test this set of standards as thevendors recognize the standard as important to carriers.Although the focus of this event was to include mobilebackhaul interoperability testing, we also acknowledgedthe vendor requests to expand on Ethernet OAM tests.In the event, six vendors with a total of 11 devices partici-pated in Ethernet OAM testing: Ciena CN 3106; HuaweiOptiX OSN 1900, OptiX OSN 3900, Quidway CX380,Quidway CX600 and SmartAX MA5600T; MRVOptiSwitch OS910-M; Nortel Metro Ethernet RoutingSwitch 8600; RAD ETX-202; Telco Systems T-Marc-254and T-Marc-380. Both test vendors Ixia and Spirent partic-ipated in the CFM testing by generating test traffic andhaving a full stack protocol implementation. In addition tothe Continuity Check Messages, we also tested Link Traceand Loopback functionality. Spirent TestCenter demon-strated simulation of multi-hop CFM link trace throughemulated intermediate and end point maintenance enti-ties.As opposed to previous years we encountered almost noissues during the testing. While we had been plagued byincompatible Ethertype values, mismatches between MACaddress and hard-wired CCM intervals before, we sailedthrough the testing nicely this time. All participants wereable to configure a common Ethernet type value of0x8902 and Maintenance Domain (MD) levels 2 or 7.One vendor required a code patch, but that was providedquickly and the vendor was able to join the testing. Wewere pleased to see that careful planning and the experi-ence and results from previous interoperability eventsbrought such high level of success to the test.

RAD


IXIA XM12Metro network

LoopbackAccess network device

LinktraceContinuity check

Metro UNI provider edge

Tester

provider edge

ETX-202

Huawei

Nortel MERS8600

Huawei


SpirentTestCenter

CienaCN 3106

MRV OptiSwitch QuidwayCX600OS910-M

SmartAXMA5600T


14


ResiliencyA high degree of resiliency is expected from a packetswitched network to support mobile traffic. Mobile opera-tors are accustomed to the resiliency offered by TDMnetworks. Voice traffic is sensitive to loss which is theobvious result of a failure in the network. In order todemonstrate Ethernet and MPLS readiness to supportmobile traffic, several resilience mechanisms were config-ured and tested which are detailed below. The results arereported as the duration of service interruption (calledfailover time) and are calculated based on the number offrames lost. Restoration time (time to restore service after afailure) is reported in the same way.

Ethernet Link AggregationAs in previous events, vendors expressed interest inshowing native Ethernet resiliency mechanism. Link Aggre-gation (IEEE 802.3ad) provides such a mechanism bygrouping several Ethernet interfaces into a Link Aggrega-tion Group (LAG) which is then presented to the networkdevice as a logical interface. The interface can be used aslong as at least one of its members is still operating.Link Aggregation Control Protocol was tested betweenAlcatel-Lucent 7450 ESS-7; Ciena CN 5060 and CN3106; Cisco 7604; Ericsson Marconi OMS 2400;Huawei SmartAX MA5600T, Quidway NE40E, QuidwayNE5000E; Nortel Multiservice Switch 15000; TelcoSystems T5C-XG. All participants brought up the LAGgroups without issues.

Figure 10: Ethernet Link Aggregation Tests

Dual Homed Access. Telco Systems demonstrated theability of their T5C-XG to redundantly connect to twometro aggregation devices using a backup Ethernetconnection. The primary connection was brought up

against the Ericsson Marconi OMS 2400 and the backupconnection was configured against a second EricssonMarconi OMS 2400 device. When the primary Ethernetinterface detected a loss of signal, the T5C-XG was ableto switch to the backup path using the same VLAN ID.

Resiliency Through MPLSSeveral resilience mechanisms exist in MPLS and mosthave been tested in previous EANTC MPLS WorldCongress interoperability events. MPLS Fast Reroute (FRR)is one such mechanism that was tested in 2006 andshowed under 50 ms rerouting times (the white paper isavailable on EANTC’s web site). MPLS Fast Rerouteprovides link and node protection for Label SwitchedPaths (LSPs).

Dual Homed Multi-Tenant Units (MTUs). Dualhomed MTUs are discussed in two specifications relatedto multipoint MPLS services, RFC 4761 and RFC 4762.Since the multipoint service protocol H-VPLS is a realiza-tion of a hub and spoke design with the MTU acting as aspoke and the PE router as a hub, the standards authorssaw a need to address an inherent drawback of hub andspoke – the spoke could easily be separated from the huband, therefore, lose connectivity. In order to protect theMTU from such a disaster, an additional backup pseudow-ire can be defined to a separate provider edge (PE)router. If the primary pseudowire fails, failover to thesecondary pseudowire is facilitated by use of native MPLSprotocols or other mechanisms.MRV OptiSwitch OS910-M and Telco Systems T-Metro-200 tested Dual-Homing MTUs against Alcatel-Lucent7450 ESS-1, Cisco 7606 and Huawei Quidway NE40Ethe latter three serving as VPLS PEs for a redundant H-VPLSarchitecture. The failover times measured were under 10ms.

MPLS Fast Reroute. The core vendors – Alcatel-Lucent,Cisco and Huawei tested MPLS based resiliency usingFast Reroute and in one case using Ethernet Link Aggrega-tion Groups (according to IEEE 802.3ad). Two testscanarios were configured, one with Huawei acting as themid-point and Alcatel-Lucent and Cisco as point of localrepair/merge points. In the second test scenario the Ciscowas configured as a mid-point and Alcatel-Lucent andHuawei as point of local repair/merge points. MPLS-FRRshowed yet again its carrier grade nature measuring,through several iterations of testing, at most 85 ms out ofservice time during link failure and at best 1 ms. Duringthe restoration phase of the tests no frame loss wasrecorded. Ixia XM12 and Spirent TestCenter were used tomeasure the Fast Reroute convergence time.Huawei demonstrated Fast Reroute between their OptiXOSN 3900 and Quidway NE40E systems, with theHuawei OSN 1900 acting as an intermediate node —recording a failover time of 63 ms and a restoration time

Nortel Ciena

Huawei Huawei

Alcatel-Lucent

Ciena

Telco Systems Ericsson

Cisco

LACP LAG (Static)

CN 3106

QuidwayNE40EHuaweiQuidwayNE40E

MarconiOMS 2400

7450 ESS-7

CN 5060

MSS 15000

SmartAXMA5600T

7604

T5C-XG

EricssonMarconi

OMS 2400

Telco SystemsT5C-XG

15


of 7 ms. Telco Systems demonstrated Fast Reroutebetween two T-Metro-200 devices with an Alcatel-Lucent7450 ESS-7 acting as an intermediate node. The out ofservice time recorded at this test was 11 ms duringfailover and 30 ms during restoration.

PBB-TE ProtectionResiliency within the PBB-TE domain would have beendone by defining two PBB-TE trunks (»working path« and»protection path«) to the same destination. As the PBB-TEingress device detects that the working path has failed, itswitches traffic over to the protected path. The failuredetection is done by CFM (CFM is described in the end-to-end Ethernet Service OAM section).Out of the five vendors participating in the PBB-TE cloudtwo vendors did not support the generation of CFM Conti-nuity Check Messages which are required for failuredetection. Another vendor did not support primary andsecondary B-VIDS which were required for the testing.Huawei demonstrated PBB-TE protection between theHuawei Quidway CX380 and the Quidway CX600.No further resiliency testing was performed during thisevent, however, during EANTC’s interoperability event atCarrier Ethernet World Congress 2007, PBT resiliencyhad been verified. The CEWC 2007 report is availableon EANTC’s web site.

T-MPLS ProtectionSeveral resiliency tests, using 3.3 ms connectivity verifica-tion intervals, were performed in the T-MPLS metro cloudin accordance to the ITU-T G.8131 specification.

T-MPLS path (TMP) protection. Two path protectionschemes exist for T-MPLS. 1:1 protection requires twopaths to be built to the same destination. One path is thendeclared as active and the other is set to backup mode.When the active path fails, traffic is switched over to thebackup path. The second scheme, 1+1 protection, repli-cates all frames across both active and backup paths suchthat when the primary path fails, the backup path isalready carrying the identical frames.Alcatel-Lucent 1850 TSS-320 and Huawei OptiX OSN3900 tested T-MPLS 1:1 protection using EricssonMarconi OMS 2400 as an intermediate node. 1+1 T-MPLS protection was tested between Huawei TechnologiesOptiX OSN 1900 and Ericsson Marconi OMS 2400. Thesame pair of devices tested 1:1 T-MPLS protection withAPS signaling. Another 1:1 protection test was performedbetween Alcatel-Lucent 1850 TSS- 320 and EricssonMarconi OMS 2400. Alcatel-Lucent used their manage-ment system to configure the protection tests in which theyparticipated. The TMP protection 1+1 and 1:1 with APSsignaling tests included both uni-directional and bi-direc-tional failover scenarios. The TMP protection 1:1 (without

APS signaling) tests only included bi-directional failurescenarios. Failover times ranged between 0.8 ms and 40ms.

T-MPLS Channel (TMC) protection. Alcatel-Lucentdemonstrated TMC protection with three 1850 TSS-320devices. The working TMC was mapped over a TMPpassing through Ericsson Marconi OMS 2400. A multi-hop TMC was used for the protection channel. When abidirectional failure was simulated on the working TMC,the traffic was switched on the protecting TMC. TheAlcatel-Lucent devices were set to switch traffic back to itsprimary TMC once the TMC was brought back into opera-tion.

Quality of Service SupportQuality of Service describes the ability of the network tosupport differential treatment to network traffic based onsome identification in the packets, frames or cells. Thisidentification allows network devices such as routers andswitches to prioritize one class of traffic over another. Inthe mobile backhaul case this is an important requirementfor several reasons:

• Voice traffic is highly sensitive to loss and delay andshould be guaranteed by the network

• Data services carry a premium price tag in themobile world as compared to fixed line data services

• Communication between the base station and thecontroller is imperative to the healthy operations ofthe radio network

Under optimal network conditions where no resources areoversubscribed little can be gained from classifying trafficinto different classes. However, when network resourcesare starved and oversubscription occurs, the network mustprioritize traffic according to the operator’s Service LevelAgreements (SLA) and the type of service offered over thenetwork.Support for different QoS levels was verified in all fourtransport network areas. We defined three differentclasses of service for three different services offered by thenetwork:

• Mobile Backhaul – the characteristics of this serviceclass were low delay and jitter with relatively smallbandwidth requirements

• Video Service – this class consisted of relativelyrelaxed delay and jitter requirements, but a steady(guaranteed) amount of bandwidth

• Data Backup Service – The VPN for a data backupservice required a large amount of bandwidth thatcould vary over time. No specific requirements forjitter and delay were given in this class.

The three classes were configured across all three trans-port areas; MPLS, PBB-TE and T-MPLS metro networks and

16


in the MPLS core network. Between all networks and theMPLS core, a mapping of CoS bits to MPLS EXP bits wasperformed in order to facilitate end-to-end QoS. The CoSbits in Ethernet headers, which are limited to eight classesof service, were directly mapped to EXP bits of the samevalues.In the T-MPLS cloud, Alcatel-Lucent 1850 TSS-320 andEricsson Marconi OMS 2400 showed the expectedbehavior during the oversubscription situation. ThreeTMCs were defined to match the three classes of servicedefined above. Then, the data backup service was usedto oversubscribe one of the interfaces. We expected noloss from the Mobile Backhaul marked traffic and indeedrecorded none. On the other hand, as expected, the databackup service was showing frame loss, allowing thevideo and mobile classes to continue operating withoutany adverse effect.In the PBB-TE cloud, a similar test to the one describedabove was successfully performed between NokiaSiemens Networks hiD 6650 and Nortel Metro EthernetRouting Switch 8600. Two traffic classes were definedbetween the two devices (one as Data Backup Serviceand the second Mobile Backhaul). The test showed thatwhen a data backup service traffic was used to congestthe link, the Mobile Backhaul traffic was correctly priori-tized and did not drop any frames.

Performance MonitoringEach transport service is associated with a set of perfor-mance attributes. The MEF standard 10.1 defines theattributes of Ethernet Services observable at a UserNetwork Interface (UNI) while the ITU-T standard “OAMfunctions and mechanisms for Ethernet based networks”(Y.1731) provides automatic mechanisms for monitoringthese attributes.Two different test scenarios were defined: In the first wemeasured the performance attribute objectives. In thesecond test scenario we verified the ability of the devicesto monitor these attributes using ITU-T Y.1731. The follow-ing devices participated successfully in the first scenariomeasuring Frame Delay, Frame Delay Variation andFrame Loss Service Performances: Alcatel-Lucent1850 TSS-5, Ceragon FibeAir IP-MAX2, Ciena CN 3106,Ericsson Marconi OMS 2400, Ixia XM12, LightstormBrooklyn-10, MRV OptiSwitch OS910-M, Nokia SiemensNetworks hiD 6650 and Nortel Metro Ethernet RoutingSwitch 8600. The testing was facilitated by Ixia XM12and Spirent TestCenter.The second scenario was successfully tested between IxiaXM12 and MRV OS910-M. In a test between two othervendors, one of the devices responded with DelayMeasurement Replies (DRM), but did not properly popu-late the transmitted and received timestamps required fortime based measurements. A solution was not found

during the execution of the tests.

Bandwidth ProfilesA Bandwidth Profile is a characterization of the lengthsand arrival times for ingress Service Frames at a referencepoint. In the test network, the reference point was the UNI.When a Bandwidth Profile is applied to a given sequenceof ingress Service Frames, each Service Frame in thesequence is declared to be compliant or not compliantwith the Bandwidth Profile.The Bandwidth Profile defines the set of traffic parametersapplicable to a sequence of Service Frames. Associatedwith the Bandwidth Profile is a rate enforcement algorithmto determine Service Frame compliance with the specifiedparameters. Rate enforcement also includes the disposi-tion of non-compliant Service Frames by either droppingor marking them. Bandwidth Profiles could be applied atthe UNI, an Ethernet Virtual Channel (EVC) and a Class ofService (CoS).Five vendor combinations were tested for both BandwidthProfile per EVC and Bandwidth Profile per CoS: LightstormBrooklyn-10 and Ciena CN 3106; Lightstorm Brooklyn-10and Ericsson Marconi OMS 2400; Telco Systems T-Metro-200 and Cisco CRS-1; Telco Systems T-Metro-200 andAlcatel-Lucent 7450 ESS-7; Ixia XM12 and Ciena CN5060.In the Bandwidth Profile per EVC scenario, the devicesunder test configured two EVCs each with 5 Mbit/sCommitted Information Rate (CIR) and 2 Mbit/s ExcessInformation Rate (EIR), so that the total allowed rate was 7Mbit/s. A bidirectional traffic flow was generated forthese EVCs using both analysis devices Ixia XM12 andSpirent TestCenter. When the 5 Mbit/s stream was gener-ated, our expectations were met not to see any loss.When the second stream was generated, with more than7 Mbit/s of traffic we expected some frame loss and inalmost all test cases recorded loss. In one test case werecorded 0.5 Mbit/s more traffic in one direction thanwas allowed. Obviously, such level of inaccuracy in Band-width Profile enforcement would be problematic to acarrier network utilization plan.In the Bandwidth Profile per CoS the devices under testconfigured three different class of services: Voice, videoand best effort. The voice service was configured to128 kbit/s Committed Information Rate and 0 kbit/sExcess Information Rate. The video was configured to5 Mbit/s CIR and 1 Mbit/s EIR, so that the total allowedbandwidth for this service was 6 Mbit/s, and the besteffort class was set to 1 Mbit/s CIR and 6 Mbit/s EIR.A bidirectional traffic stream was generated for two differ-ent EVCs with different CoS markers. In most cases theresults met our expectations and Bandwidth Profiles werecorrectly enforced. In one case an unexpected amount oftraffic was dropped in one direction.

17


End-to-End ServicesTwo types of end-to-end services were implemented in thetest network, spanning all metro clouds and the core. Theservices were constructed according to the MEF EthernetService Definitions (MEF 6).

• Point-to-point Ethernet Virtual Private Line services(EVPL) were defined from UNI to UNI. EVPL servicesare the ones expected to be used to support MobileBackhaul services initially, as they allow the CarrierEthernet network operator to use UNIs for more thanone Ethernet Virtual Channel (EVC). The goal of deliv-ering identical service frames at the destination UNIas were seen in the source UNI was verified using theIxia XM12 and Spirent TestCenter.

• The second end-to-end type of service configuredwas Ethernet multipoint-to-multipoint (E-LAN).

In both cases provisioning the services across the diverseclouds was extremely time consuming. Engineers wererequired to manually configure the services on the UNIsand provide mapping configuration from the UNIs to thetransport (regardless of the transport technologies).MRV demonstrated E-Tree service according to an MEFdraft version of Ethernet Service Definitions phase 2. Thedemonstration conducted with Ixia XM12 showed thatMRV OS910-M, acting as a root in an E-Tree service, wasable to completely separate downstream ports (userfacing) from directly exchanging traffic with each other.

AcknowledgmentsWe would like to thank Thomas Kessler from T-Systemsand Kyle Price from the University of New HampshireInteroperability Lab (UNH-IOL) for their extensive supportduring the hot-staging event.Telco Systems provided two T5C-48T switches to facilitatethe joint network management subnet between allvendors. The T5Cs provided Ethernet service across alllocations during the hot-staging and the live showcases.

Editors. This document has been edited by JambiGanbar, Sergej Kaelberer, Jonathan Morin and CarstenRossenhoevel.

Acronyms

Term Definition

B-MAC Backbone MAC

B-Tag Backbone Tag

BSC Base Station Controller

BNC Broadband Network Connector

CBS Committed Burst Size

CE Customer Edge

CE-VLAN Customer Edge Virtual LAN

CFM Connectivity Fault Management

CIR Committed Information Rate

CM Color Mode

CoS Class of Service

DTE Data Terminal Equipment

EBS Excess Burst Size

EEPP End to End Path Protection

EIR Excess Information Rate

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

E-Line Point-to-Point Ethernet Service similar toa leased line ATM PVC or Frame RelayDLCI

EVC Ethernet Virtual Connection

FCS Frame check sequence (4 bytes at theend of Ethernet frame)

LAG Link aggregation Group

LSP Label Switched Path

MPLS MultiProtocol Label Switching

MTU Multi Tenant Unit

MTU Maximum Transmission Unit

MetroNPE

Metro Network Provider Edge device

OSPF Open Shortest Path First

PBB Provider Backbone Bridge

PBB-TE Provider Backbone Bridge Traffic Engi-neering

PE Provider Edge

QoS Quality of Service

RNC Radio Network Controller

RSVP-TE Resource reSerVation Protocol TrafficEngineering

SLS Service Level Specifications

STP Spanning Tree Protocol

TMP T-MPLS Path

TMC T-MPLS Channel

T-MPLS Transport MPLS

UNI User to Network Interface

MetroUPE

Metro UNI Provider Edge device

VPLS Virtual Private LAN Service

VPWS Virtual Private Wired Service

Term Definition

18


References"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 Framework", MEF 4"Ethernet Service Definitions - Phase 1", MEF 6"Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks", MEF 8"Ethernet Services Attributes Phase 2", MEF 10.1"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“Service OAM Requirements and Framework – Phase 1”, MEF 17"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"Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method & Physical Layer SpecificationsAggregation of Multiple Link Segments", IEEE 802.3-2005"Virtual Bridged Local Area Networks - Connectivity Fault Management", IEEE 802.1ag/D8.1"Provider Backbone Bridges", IEEE 802.1ah"Provider Backbone Bridges Traffic Engineering", IEEE 802.1Qay/D.1.1"Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE 1588"Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305"Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270"RTP: A Transport Protocol for Real-Time Applications", RFC 3550"Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630"Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090"Protocol extensions for support of Diffserv-aware MPLS Traffic Engineering", RFC 4124"BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364"Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447"Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553"Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717“Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)”,RFC 5086"Circuit Emulation Service Interoperability Specification Version 2.0", ATM Forum af-vtoa-0078.000, January 1997"Framework for MPLS in Mobile Backhaul Networks", IP/MPLS Forum 2007.102.03"Architecture of Transport MPLS (T-MPLS) Layer Network", G.8110.1"Interfaces for the Transport MPLS (T-MPLS) Hierarchy", G.8112"Linear protection switching for Transport MPLS (T-MPLS) networks", G.8131"Management aspects of the T-MPLS network element", G.8151"Timing and synchronization aspects in packet networks", G.8261/Y.1361"Timing characteristics of synchronous ethernet equipment slave clock (EEC)", G.8262"OAM functions and mechanisms for Ethernet based networks", Y.1731"Characteristics of Transport MPLS (T-MPLS) equipment functional blocks", G.8121

19

EANTC AGEuropean AdvancedNetworking Test Center

IP/MPLS Forum MEFMetro Ethernet Forum

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

48377 Fremont Blvd., Suite117Fremont, CA 94538, USATel: +1 510 492 [email protected]

9841 Airport Blvd, Suite1200, Los Angeles, CA90045, USATel: +1 310-258-8032info@metroethernetforum.orgwww.metroethernetforum.org

This report is copyright © 2008 EANTC AG. While every reasonable effort has beenmade to ensure accuracy and completeness of this publication, the authors assume noresponsibility for the use of any information contained herein.All brand names and logos mentioned here are registered trademarks of their respectivecompanies in the United States and other countries.

METRO ETHERNET FORUM

Public Multi-Vendor Mobile Backhaul Interoperability Test ... · PDF filePublic Multi-Vendor...

Documents

Transcript of Public Multi-Vendor Mobile Backhaul Interoperability Test ... · PDF filePublic Multi-Vendor...