carrier ethernet world congress 2010 multi-vendor ......zxctn 6300 huawei cx600-x1 cx600-x2 cx600-x3...

20

Upload: others

Post on 11-Feb-2021

4 views

Category:

Documents


0 download

TRANSCRIPT

  • 2

    Carrier Ethernet World Congress 2010 Multi-Vendor Interoperability Test

    EDITOR’S NOTEAs I am writing this note, ourteam prepares to ship five tonsof equipment — more than100 devices under test from24 participating vendors — toWarsaw in Poland and, later,some of it to Hong Kong.The new Eastern Europeanlocation of the CarrierEthernet World Congress andthe flourishing Carrier Ethernet

    World APAC conference in the Asia Pacific regionare symbolic for Carrier Ethernet expansion intonew markets and applications. Analysts across theboard see two thirds of the world’s Carrier Ethernetmarket volume in Europe and APAC, with double-digit cumulated annual growth rates1. More carriersthan ever before substitute legacy private lines withCarrier Ethernet offerings for businesses, consumersand mobile backhaul.In our two-week hot staging test, we noticed thatmobile backhaul solutions are driving a lot ofinnovation in the industry. It isgreat to see that the industrykeeps pace with challengingoperator requirements, even inmulti-vendor scenarios. With theadvent of Long Term Evolution(LTE), six vendors interoperatedsuccessfully in the world’s firstmulti-vendor end-to-end phaseclock synchronization test.Ethernet-based microwave andmillimeter-wave solutions —helping to overcome the fibergap in the last mile, specificallyto cell sites — are anotherimportant area of innovation.Five otherwise competitivevendors joined our test for a collaborative evaluationof their latest advances side by side, such asadaptive modulation, integration in Ethernet OAM,and clock synchronization support. The speed oftechnological advances in this sector is amazing aswell, and certainly fueled by the strong competition.A range of high availability technologies were arecurring topic this year. Enterprises and mobileoperators recognize the cost of a network outage --with IPTV deployments, highly available aggregationnetworks are even a need for consumer services.Draft and pre-draft standard MPLS-TP protection,Ethernet ring protection (ERPS) and pseudowireredundancy in the access were three main focusareas. We saw most advances with eight interop-erable solutions in ERPS (up from four last time).Management topics, specifically OAM for faultmanagement and performance monitoring, are onthe agenda for many service provider Requests forProposal (RFPs) now. At EANTC, these tests are astaple -- we have tested Ethernet OAM since 2005and Y.1731 performance monitoring since 2008. It

    is great to witness how the industry matures. Delayperformance monitoring went really well with12 implementations; there is still more workupcoming for loss performance monitoring.This year's EANTC Carrier Ethernet interoperabilitytest shows the industry in an intermediate state. Basicservices were taken up across 23 vendors in minutesrather than days this time; key technologies such asEthernet OAM, MPLS signaling, SynchronousEthernet worked like a charm; now advancedsolutions for challenging markets are being targeted.Carrier Ethernet is on the way to the next level ofenlightenment.

    INTRODUCTIONThere are several metrics with which the scale of ourevent can be recorded. In terms of two which wefind to be the most noteworthy, this was indeed ourlargest event yet — effort, and results. Over 80engineers worked together in the two week test eventin our lab, bringing what we feel is more test resultsthan we have ever had in the past.Two years since our first tests of IEEE 1588, this is

    perhaps the first event with some (notall!) virtually seamless test runs. Thesame could be said about EthernetService OAM (802.1ag) where somany link trace tests wereconducted, we could barely fit themin a single-page diagram. Thesetests were much more straight-forward than in the past.This is evidence of two factors. First,the wide-spread support acrossvendor equipment and device typeshas increased. Second the imple-mentation have grown in maturity.On the other hand, we welcomedfive first-time participants this year.This is not to say that all tests were

    seamless. In fact, we experienced as many hiccupsand interesting issues as we have in the past if notmore. Most, if not all, vendors fixed issues based onthe findings of the testing, in some cases re-runningthe test for a successful result. In this white paper, wepoint out issues we think are most relevant for thosewho standardize or deploy the technology.The test plan was divided into four main umbrellatest areas - Synchronization, Transport, Resiliency,and Management. We are open to additional topicsfor future events and encourage you to send us yoursuggestions and comments.

    1.Source: Vertical Systems Group presentation to theMEF, January 2010

    Carsten RossenhövelManaging Director

    TABLE OF CONTENTSParticipants and Devices.............. 3Interoperability Test Results .......... 4Synchronization ......................... 4Converged Transport .................. 8Managed Ethernet Services ......... 9Carrier Ethernet Resiliency ......... 15References ............................... 19Acronyms ................................ 19

  • Participants and Devices

    3

    PARTICIPANTS AND DEVICES

    Vendor Participating Devices Vendor Participating Devices

    Actus Networks Ganesh NEC iPASOLINK 200

    Alcatel-Lucent 1850 TSS-1601850 TSS-3207750 SR77210 SAS-M7705 SAR87750 SR-c129500 MPR9500 MPR-e

    Omnitron Systems iConverter GM3

    Orckit-Corrigent CM11CM4140CM4206CM4314CMview

    RAD DataCommunications

    ETX-204AIPmux-216ETX-203AACE-3220ACE-3105MITOP-E1T1/GE

    Albis Technologies ACCEED 2202ACCEED 1416

    Aviat Networks Eclipse Packet Node

    Calnex Solutions Paragon Raisecom iPN201

    Chronos Technology SyncWatch 200SyncWatch 300

    Siklu EtherHaul1200

    Spirent Spirent TestCenterXGEM/GEM

    Ciena CN3920CN3940CN3960CN5305

    Symmetricom CsIIISSU 2000eTimeMonitor (software)TimeProvider 5000TimeProvider 500

    Cisco ANAASR 9010ME3600XME3800XMWR2941

    Telco Systems T-Metro-7224T-Metro-7124ST-Metro-200T5C-XGT-Marc-380T-Marc-254H

    Ericsson MINI-LINK CN 500MINI-LINK CN 1010MINI-LINK TNOMS 1410SEA 10SEA 20

    Vitesse VTSS Caracal CE10

    Hitachi AMN1710 ZTE ZXR10 T8000ZXR10 M6000ZXR10 8905EZXR10 5928EZXR10 5128EZXR10 2928EZXCTN 9008ZXCTN 9004ZXCTN 6100ZXCTN 6200ZXCTN 6300

    Huawei CX600-X1CX600-X2CX600-X3PTN910PTN950PTN1900PTN3900

    Ixia IxNetwork (software)IxN2X

    MRV OS940OS904-DSL4OS904-MBHOS904-MBH-4OS906

  • 4

    Carrier Ethernet World Congress 2010 Multi-Vendor Interoperability Test

    INTEROPERABILITY TEST RESULTSEach section of this document covering individualtest areas includes the technical background of thetechnology, the test procedures employed, a logicaltopology diagram and a detailed review of theresults achieved. Some successful tests whichinvolved several vendors were incorporated to thedemonstration network, described in the NetworkDesign section below.The multi-vendor combinations documented detailthe successful results completed within the two-weekhot staging time. Given the time constraint, we wereable to reach fully meshed vendor combinations onlyfor some of the technologies tested. For any missingtest combinations, we encourage the reader tocontact the respective vendors to ask that the test isperformed at our next event.

    Testers. What is a test without test equipment?Without the use of some key tools, a majority — oreven all — of what was accomplished here wouldnot have been possible. We would like to thank Ixiaand Spirent for their traffic generation (useremulation), protocol emulation, and analyzing toolsmade available by Ixia’s IxNetwork, IxOS, andIxN2X, and the Spirent TestCenter. Throughout alltest areas you will find that the use of impairmenttools, the Calnex Paragon and Spirent GEM,allowed us to emulate certain network conditions.Finally, our synchronization tests were only madepossible by Symmetricom’s Cesium atomic clockCsIII, the Chronos SyncWatch 200 with TimeMonitoranalyzer software and Calnex Paragon.

    Terminology. For consistency, we use the term“tested” to describe interoperability tests betweenequipment from multiple vendors and performedaccording to the test plan. The term “demonstrated”will be used both when a test was performed withequipment from a single vendor and in cases whenfunctionality was not thoroughly tested.

    NETWORK DESIGNIn the first week of the hot staging, all vendorengineers and the EANTC support team focusedachieving test results in appropriate, dedicated smalltest configurations and topologies.In the second week of testing, we asked vendors tofreeze their configurations and connections on theway to building a fully integrated end-to-endnetwork. The end product is a snapshot of core,aggregation, and access network areas that facil-itate realistic demonstration scenarios to beshowcased at the Carrier Ethernet World Congress.

    SYNCHRONIZATION FOR LTEMOBILE BACKHAULOne of the 3GPP-Long Term Evolution (LTE) require-ments for the LTE Backhaul is support of clocksynchronisation. There are multiple ways toimplement synchronisation services in a network:Packet-based and network-based methods. Whilenetwork-based synchronisation relies on the

    synchronous signal of the physical network layer,packet-based synchronisation is based on specificcontrol protocols.We tested IEEE 1588-2008, a packet-based clocksynchronisation protocol, and Synchronous Ethernetwhich represents the network-based method. WhileSynchronous Ethernet provides frequency synchroni-sation only, IEEE 1588-2008 can provide phase ortime of day synchronisation as well. The time of daysynchronisation is required by LTE MultimediaBroadcast Multicast Service (MBMS), for example.At this event, we successfully tested multi-vendorinteroperability of IEEE 1588-2008 for phasesynchronisation in an end-to-end network for the firsttime publicly worldwide.

    Frequency and Time of DaySynchronisation overIEEE 1588-2008 (PTPv2)We identified three important evaluation scenarios:1. Precision Time Protocol (PTP) Interoperability

    between a PTP grandmaster and PTP slave clocks2. PTP Transparent Clock interoperability, where a

    transparent clock was inserted between thegrandmaster and the slave clock to improvelatency awareness and slave clock stability

    3. PTP and Synchronous Ethernet interoperabilitycombined between the PTP grandmaster, a PTPslave clock and a Synchronous Ethernet slaveclock. The PTP slave clock was connected to thePTP grandmaster over the packet network asbefore; in addition, it served as a SynchronousEthernet master and provided clock recoveredvia IEEE 1588 to the Synchronous Ethernet slave.

    Figure 1 shows the logical test topology. We usedthe Symmetricom TimeProvider 5000 as PTP grand-master and either Spirent GEM or Calnex Paragonthe as impairment tools for each of the tests. Theimpairment tools emulated reproducible conditionsof a packet-switched network, using ITU-T G.8261Test Case 12 impairment profiles.Given the number of variables still undefined by theG.8261 standard in regards to how impairmentprofiles are recorded, it is known that not all imple-mentations of a given G.8261 profile will be equiv-alent. Since this would have implications in regardsto which vendors would pass or fail a test dependingon what impairment was used, we validated TestCase 12 profile implementations of both Calnex andSpirent prior to the event. We are glad to report thatboth profile implementations resulted in comparableimpairment.PTP is a rich protocol with a range of options. In thepreparation phase, we reviewed key protocoloptions with participating vendors, resulting in thecreation of three PTP configuration profiles shown intable 1 below.We measured frequency accuracy using theChronos SyncWatch 200 frequency analyzer on theslaves via either 2048KHz or E1 clock output inter-faces. In our third scenario with SynchronousEthernet (SyncE), we connected the tester to theSyncE slaves. Otherwise the analyzer wasconnected to the PTP slaves’ clock outputs.

  • Synchronization For LTE Mobile Backhaul

    5

    In the two first scenarios we also measured phase(time of day / TOD) synchronization. The support ofphase synchronisation was optional for the basicPTP Interoperability (scenario 1). It was mandatoryfor the Transparent Clock interoperability tests(scenario 2). We used frequency counters to takephase accuracy measurements, which wereconnected to the slaves via 1 PPS (Pulse Per Second)interfaces.Measurements for all three scenarios wereperformed for at least four hours. We started testswith the PTP slaves in a “free-running” state. Weconsidered a PTP test passed as soon as the MTIEmeasurement for frequency accuracy was below theITU-T G.823 SEC (SDH equipment slave clocks)mask and the absolute phase deviation, if tested,from the reference clock was below 10 µs.Figure 1 depicts the PTP slaves that successfullytested frequency synchronization (bottom half of thediagram): Actus Ganesh, Cisco MWR2941,Huawei CX600-X1, MRV OS904-MBH, Orckit-Corrigent CM11, RAD ETX-204A, RaisecomiPN201, Telco Systems T-Marc-254H, ZTE ZXCTN 6100.The following devices were successfully tested as PTPslaves for phase (time of day) synchronization:Actus Ganesh, MRV OS904-MBH, RaisecomiPN201, and ZTE ZXCTN 6100. The tests areindicated by yellow 1PPS clock links between thePTP slave and the Phase Analyzer in the figure.

    TABLE 1. PTP Profiles

    Figure 1: PTP Test Results

    E1/2048 KHz clock link Emulated

    1PPS clock linkPTP or SyncE slave PTP Grandmaster

    Impairment toolTransparent Clock

    SpirentGEM

    CalnexParagon

    OR

    Ixia IxNetwork(PTP Grandmaster/

    Slave Emulator)RADETX-204A

    MRVOS904-MBH

    ZTEZXR10 T8000

    RaisecomiPN201

    RADETX-204A

    MRVOS904-MBH

    ZTEZXCTN 6100RaisecomiPN201

    Synchronous Ethernet Ethernet

    SymmetricomCsIII

    Symmetricom

    CiscoMWR2941

    Orckit-CorrigentCM11

    RADETX-204A

    Telco SystemsT-Marc-254H

    HuaweiCX600-X1

    RaisecomiPN201

    ChronosSyncWatch 200

    (Frequency Analyzer)

    ZTEZXCTN 6100

    ActusGanesh

    MRVOS904-MBH

    PhaseCounter

    CsIII

    SymmetricomTimeProvider

    ChronosSyncWatch 200(Frequency Analyzer)

    PacketNetwork

    5000

    RAD ETX-204A

    Parameter Profile1 Profile2 Profile3

    Address Type unicast unicast multicast

    Encapsulation IP/UDP IP/UDP IP/UDP

    Clock Modea

    a. one-way clock type can be used for frequencysynchronisation only

    one-way/two-way

    one-way two-way

    Master ClockType

    1-Step or 2-Step

    1-Step or 2-Step

    1-Step or 2-Step

    Sync/Delay_-RequestDelay_-Response rateper second

    64 32 64

    Announcemessage rate/s

    0.5 0.5 0.5

    Unicast RequestMechanismb

    b. Clause 16.1 of IEEE1588-2008

    No No No

    Pdelay Request/Pdelay Response

    No No No

    Correction Field Yes Yes Yes

    Phase OutputInterfacec

    c. Slave’s clock output interface type for phasemeasurement

    1PPS N/A 1PPS

    FrequencyOutput Interfaced

    d. Slave’s clock output interface type for frequencymeasurement

    2048 KHz E1 E1

    PTP Domain 1 1 1

    VLAN ID 10 20 30

  • 6

    Carrier Ethernet World Congress 2010 Multi-Vendor Interoperability Test

    For the “PTP Transparent Clock Interoperability”scenario we successfully verified the RAD ETX-204Awhich served as the Transparent Clock andRaisecom iPN201 as the PTP slave. For this test weused an Ixia IxNetwork which emulated a PTPGrandmaster and PTP Slave and measured theTransparent Clock correction under normal condi-tions and conditions with unidirectional traffic load.In the “PTP and Synchronous Etherent” scenario wetested successfully MRV OS904-MBH, RAD ETX-204A, Raisecom iPN201, and ZTE ZXR10 T8000as PTP slave/Synchronous Ethernet master and theMRV OS904-MBH, RAD ETX-204A, RaisecomiPN201, and ZTE ZXR10 6100 as SynchronousEthernet clients.In one test, an implementation could not receiveDelay Response messages from the grandmasterbecause it used a wrong sub-domain ID in its DelayRequest messages (10 instead of 1). In anothersituation a different implementation mixed a unicastdestination IP address and a multicast Ethernetaddress in its PTP Delay Request messages. Apartfrom these hiccups, protocol interoperability wasgreat due to the alignment of protocol implemen-tation options in advance of the test.

    Synchronous Ethernet and ESMCClearly, Synchronous Ethernet as a network-basedsynchronization mechanism is independent frompacket network utilisation and packet forwardingperformance of network elements. The disadvan-tages in comparison to the packet-based techniqueare that SyncE works in pure Ethernet environmentsonly, every active network element in a clockingchain must support Synchronous Ethernet, and itprovides frequency synchronisation only.We verified SyncE interoperability by connecting aSynchronous Ethernet master device directly to avery precise reference clock provided by Symmet-ricom and measuring the clock output signal qualityon the Synchronous Ethernet slave via a frequencyanalyzer. We used the Chronos SyncWatch 200 asa frequency analyzer connected to the slaves viaeither 2048KHz or E1 clock output interfaces; alter-natively, we used the Calnex Paragon connected toslaves via a SyncE interface.Since synchronisation quality does not depend onthe network utilisation, it was not necessary toemulate a network between SyncE master andslaves. A measurement interval of at least 1 hourwas deemed sufficient. We set the requirements topass a test higher than for PTP tests: A test wasconsidered as passed if the slave clock qualitystayed below the ITU-T G.823 SSU masks.The following systems were successfully tested asSynchronous Ethernet master: Albis Acceed, CiscoASR 9010, Cisco ME3600X, Huawei CX600-X2,MRV OS904-MBH, NEC iPasolink 200, Orckit-Corrigent CM4206, Orckit-Corrigent CM-4314,RAD ETX-204A, Raisecom iPN201, Telco Systems T-Metro-7124S, ZTE ZXR10 5928E, ZTE ZXCTN6300, ZTE ZXCTN 9008, ZTE ZXR10 M6000.During the test run between ZTE ZXR10 M6000 andActus Ganesh, we observed two unexpected jumpsin TIE values. We assume they were caused by

    Master Slave

    SyncE link

    E1/2048KHz link

    CalnexParagon

    SymmetricomCsIII

    VitesseVTSS Caracal CE10

    AlbisAcceed

    CiscoME3800X

    MRVOS904-MBH

    HuaweiCX600-X2

    CiscoME3600X

    CiscoMWR2941

    ZTEZXCTN 9008

    Alcatel-Lucent1850 TSS-160

    CiscoASR9010

    Telco SystemsT-Metro-7124S

    RADETX-204A

    AlbisAcceed

    MRVOS904-MBH

    RADETX-204A

    NECiPasolink 200

    ZTEZXR10 5928E

    FrequencyAnalyzer

    ReferenceClock

    SyncE node

    ActusGanesh

    Aviat NetworksEclipse Packet Node

    NECiPasolink 200

    Microwave systemsupporting SyncE

    SymmetricomCsIII

    ChronosSyncWatch 200ZTEZXR10 M6000

    RaisecomiPN201

    RADMITOP-E1T1/GE

    Orckit-CorrigentCM4206

    RaisecomiPN201

    Telco SystemsT-Metro-7124S

    Orckit-CorrigentCM4140

    Orckit-CorrigentCM-4314

    ZTEZXCTN 6300

    Figure 2: SyncE Test Results

  • Synchronization For LTE Mobile Backhaul

    7

    electric issues in the lab, however we had no time toeither retest or verify the assumption in detail.The following systems were successfully tested asSynchronous Ethernet slave clocks: Actus Ganesh,Albis Acceed, Alcatel-Lucent 1850 TSS-160, AviatEclipse Packet Node, Cisco ME3800X, CiscoMWR2941, MRV OS904-MBH, NEC iPasolink200, Orckit-Corrigent CM4140, RAD ETX-204A,RAD MITOP-E1T1/GE, Raisecom iPN201, TelcoSystems T-Metro-7124S, Vitesse VTSSCaracal CE10. Please refer to Figure 2 for results.

    Ethernet SynchronizationMessaging Channel (ESMC)ESMC is a protocol defined in ITU-T G.8264 forusage in Synchronous Ethernet networks with morethan one clock source. The SyncE nodes exchangeSynchronization Status Messages (SSM) thatdistribute clock quality level information to adjacentnodes. Each SSM message contains a single QL-TLVwith a QL (Quality Level) value binary-compatiblewith the SDH network definition (ITU-T G.781). TheQL information allows the receiving SyncE node toselect the best clock source available at any time.In each of our ESMC tests we verified interopera-bility between three SyncE nodes. Two nodes weredirectly connected to different external clocks andadvertised their internal quality level to the networkwhich was related to the quality level of the externalclock — one of them at primary reference clock(PRC) quality level and another at SSU quality level.A third node was connected to the first two nodesover SyncE and had no external clocks directlyattached to it. This node advertised the quality levelof its internal clock to the network, which was oftenSEC, so we call the device SEC for simplicity.During the ESMC tests we connected, disconnected,and reconnected the external clocks on PRC andSSU devices and observed the ESMC protocolexchange. The following devices successfully partici-pated in the ESMC tests: Actus Ganesh, AlbisAcceed, Alcatel-Lucent 1850 TSS-160, Cisco ASR9010, Huawei CX600-X3, Ixia IxNetwork andIxN2X, MRV OS904-MBH, Orckit-Corrigent CM11and CM4140, RAD ETX-204A, Raisecom iPN201,Telco Systems T-Metro-7124S, VitesseVTSS Caracel CE10, ZTE ZXCTN 6300 andZXR10 M6000. Please refer to figure 3 fordocumentation of each individual test combination.The tests were supported by Calnex Paragon andIxia IxN2X as ESMC packet analyzers.We discovered an issue with one implementationduring a switchover from PRC to SSU clock: The SECslave initially sent clock code EEC1 as expectedfollowed by an unexpected EEC2. Later on, thevendor resolved the issue and the device sent SSUas expected. In another combination, a device wasincompatible as it sent periodic ESMC messagesevery 2–4 seconds instead of every second asexpected. In yet another case, a device under testcould not lock on its external PRC clock after it hadbeen reconnected. The problem could be solved bya software shutdown/restart of the interface to theexternal clock. In general, interoperability was veryreassuring - SyncE ESMC support is growing. Figure 3: ESMC Results

    ESMC ESMC ESMCPRC SEC SSU

    Ethernet tap

    Calnex Paragon

    Clock source

    Orckit-CorrigentCM11

    RADETX-204A

    MRVOS904-MBH

    Calnex Paragon

    MRVOS904-MBH

    CiscoASR9010

    RaisecomiPN201

    Ixia IxN2X

    Alcatel-Lucent1850 TSS-160

    AlbisAcceed

    IxiaIxNetwork

    Ixia IxN2X

    HuaweiCX600-X3

    Orckit-CorrigentCM4140

    CiscoASR9010

    Ixia IxN2X

    RADETX-204A

    CiscoASR9010

    Orckit-CorrigentCM11

    Ixia IxN2X

    CiscoASR9010

    Telco SystemsT-Metro-7124S

    IxiaIxN2X

    SyncE link

    E1/2048KHz link

    Ixia IxN2X

    ZTEZXR10 M6000

    VitesseVTSS Caracal CE10

    ActusGanesh

    Ixia IxN2X

    Alcatel-Lucent1850 TSS-160

    AlbisAcceed

    ZTEZXCTN 6300

    ESMCPacket Analyzer/Emulator

    SyncE node

    SymmetricomCsIII

    SymmetricomCsIII

  • 8

    Carrier Ethernet World Congress 2010 Multi-Vendor Interoperability Test

    CONVERGED TRANSPORTData Center Interconnection. With the stream-lining of data center services gaining quick tractionthis year, and cloud computing, we attempted toadd this focus on our transport tests. We have testedseveral packet based transport technologies quite abit in the past, and the idea was to add somecontext. For such a concept, we thought both multi-point connectivity - for site-to-site interconnection -and jumbo frames - for performance optimization -should be required given the requirements from suchdata centers and their load balancing.

    Interworking Between TransportDomainsThe premise of this test was to ensure that servicescould interwork across the boundary of IP/MPLS andMPLS-TP domains. Unicast, broadcast, and multicastframes (in IMIX and 9000 Byte jumbo framepatterns) were transmitted into the VPLS clouds.Figure 4 depicts multipoint and point-to-pointservices were configured. In all cases a static MPLSLSP label was used to tunnel the service between thedomains.

    Figure 4: IP/MPLS and MPLS-TP Interconnect

    PBB-VPLS InterworkingIn a Virtual Private LAN Service, the provider edge(PE) nodes need to learn customer MAC addressesin order to forward customer Ethernet traffic appro-

    priately. This may often require the PE to maintainthousands of MAC addresses or more. Scaling toprovider requirements was one of the motivationswhen the IEEE designed Provider Backbone Bridging(PBB): To create an additional abstraction layer forbridges.We tested interworking between provider backbonebridges and VPLS domains in two cases: In the firsttest combination, a Cisco ASR9010 acted as anative PBB switch, connected to the Alcatel-Lucent7750 SR7 for encapsulation and forwarding into aVPLS domain. The Alcatel-Lucent SRc12 performedboth the PBB and VPLS PE functionality required forthis test case. Some full-duplex traffic was passedwith no loss.In a second test scenario, an Alcatel-Lucent 7750SR7 was configured as a VPLS PE, and an IxiaIxNetwork emulating a PBB network was attached.Ixia IxNetwork emulated VPLS/PBB devices. Alltraffic was passed back and forth with no loss.

    Ethernet Radio TransportFive microwave and millimetric wave systems joinedthis year’s EANTC event to interoperate with otherCarrier Ethernet systems and to run through ourfeature benchmarking. Such systems are importantfor operators to offer connectivity to places difficultor expensive to reach with wire-line services — thisis particularly helpful for base station deployment.All participating microwave devices demonstratedtheir adaptive modulation capabilities. Aviat startedat 256-QAM with their Eclipse Packet Node,stepping down to 64-QAM with no loss in prioritizedtraffic. NEC showed their iPasolink 200, also goingfrom 256-QAM to 128-QAM with no loss in priori-tized traffic. Alcatel-Lucent demonstrated interopera-bility between their split-mount 9500 MPR and thestand-alone 9500 MPR-e, stepping from 16-QAMdown to 4-QAM with no loss in prioritized traffic.Ericsson started at 512-QAM, stepping down to128-QAM with no loss in prioritized traffic on boththe Mini-Link TN and Mini-Link CN500. Siklu’sEtherHaul1200 stepped from QPSK-500MHz toQPSK-250MHz with no drop in prioritized traffic.Link State Propagation is a feature enabling commu-nication about link state between communicatingendpoints of the radio link. When the wirelineEthernet link goes down on one side of the radio, theradio tells the other side to also disable its Ethernetlink. The following systems demonstrated thisfeature: Aviat Eclipse Packet Node, Ericsson Mini-Link TN, Ericsson Mini-Link CN500, NEC iPasolink200, and Siklu EtherHaul1200. Alcatel-Lucentpresented a different strategy, pointing out that thisfeature also disables links by default to the provider,limiting their ability to localize the failure. It hastherefore been discussed at the ITU-T to define a“Client-Signal-Fail” within Y.1731 to allow for aspecific alarm for this case.In addition to the Synchronous Ethernet (SyncE) testsdescribed in the next section, several SyncE chainswith microwave systems included were constructed.For the following test combinations, we quicklyobserved that the running clock quality stayed wellbelow the mask at a glance: The first chain involved

    Cisco

    Orckit-Corrigent

    Orckit-Corrigent

    Alcatel-Lucent

    IP/MPLS or MPLS-TP connection

    Alcatel-Lucent

    Static MPLS label

    CX600-X1Huawei

    ME3800X

    C4314

    1850 TSS-320

    1850 TSS-160

    C4206

    HuaweiCX600-X2

    HitachiAMN1710

    Telco SystemsT-Metro-7224

    ZTEZXCTN 9008

    Ixia IxNetwork Emulated Router/Switch

    Router/Switch

    IP/MPLS Domain MPLS-TP Domain

  • Managed Ethernet Services

    9

    the Alcatel-Lucent 9500 MPR and 9500 MPR-e,Aviat Packet Eclipse Radio, Cisco ME3600X, andMRV OS904-MBH; and a second chain involved theAviat Packet Eclipse Radio, Cisco ME3600X, CiscoMWR2941, and MRV OS904-MBH.RAD demonstrated a bonding feature - traffic wasdistributed across two Ethernet links. On those twolinks sat two Siklu EtherHaul 1200 systems.Additionally, Ericsson demonstrated the radio linkutilization of their Mini-Link TN radio using statefulTCP traffic.

    ATM Pseudowire EmulationA test was performed between Huawei PTN 3900and Alcatel-Lucent 1850TSS-320. ATM cells weresuccessfully transported over MPLS-TP by usingencapsulation as described in RFC 4717. Weconfigured cell transport type 0x000A, packeti-zation delay of 10ms, and the Maximum Number ofCells Packed (MNCP) of 5.

    MANAGED ETHERNET SERVICES

    Performance MonitoringNetwork operators require toolsets that can monitorperformance of Ethernet Virtual Connections (EVC)during operation to verify Service Level Agreements(SLAs). The ITU-T specification Y.1731 provides sucha toolset by introducing techniques to measure frameloss, frame delay, and frame delay variation onpoint-to-point Ethernet services. On the IP layer, theIETF has defined IP-based performance measure-ments in RFC 5357. We evaluated both.As a baseline reference test, we first validatedperformance monitoring implementations withoutintroducing any impairment. All further tests wereperformed using either a Calnex Paragon or aSpirent GEM impairment tool that introducedartificial static delay, delay variations, or packetloss. For each specific type of impairment weverified the measurement results provided by theimplementations under test against the emulatorconfiguration. We expected the delta between theimpaired configuration and the reference test to beequivalent to the impairment tool settings.For delay measurement we added a constant delayof 20 milliseconds (ms). In order to test delayvariation, we then configured the impairment tool tointroduce packet delay of 15 ms to every secondpacket and 25 ms to the remaining packets — theaverage remained at 20 ms but with a delayvariation of 10 ms.The following devices successfully participated in theY.1731 delay/delay variation tests: Alcatel-Lucent7750 SR7 and 1850 TSS-320 and 7705 SAR8,Ciena CN5305 and CN3960, Cisco ASR9010,Huawei CX600-X3 and PTN3900, Ixia IxNetwork,MRV OS940, Omnitron iConverter GM3, Orckit-Corrigent CM11, RAD ETX-203A, RaisecomiPN201, Siklu EtherHaul1200, Spirent TestCenter,Telco Systems T-Marc-380 and ZTE ZXR10 8905Eand ZXCTN 6200.

    Cisco ASR9010 and Huawei CX600-X3 measureddelay and delay variation over a Virtual PrivateWire Service (VPWS) across an MPLS network.Using the Calnex Paragon we introduced delay anddelay variation impairment on the MPLS encapsu-lated DMM and DMR messages.Based on Y.1731 over MPLS-TP, as defined in thedraft-bhh-mpls-tp-oam-y1731, the Alcatel-Lucent1850 TSS-320 performed delay and delayvariation measurement with Huawei PTN3900 andZTE ZXCTN6200.During the measurement one implementationexhibited an incorrect delay value when the remotepeer was configured with a CCM interval of100 ms. Oddly enough, after the remote peerchanged the interval to 1 s, the implementationshowed an accurate delay measurement.

    Figure 5: Performance Monitoring Y.1731

    We also tested one way frame loss measurementsbased on Y.1731 Loss Measurement Messages andReplies (LMMs and LMRs). Using a traffic generator,we sent bidirectional Ethernet traffic over thenetwork service and introduced 10% frame loss inone direction with the impairment tool. We verifiedwhether the far-end and the near-end frame lossdisplayed on the device under test showed the sameloss values. Three participants successfully tested theframe loss measurement: Omnitron iConverter GM3,Siklu EtherHaul1200, and Telco Systems T-Marc-380.

    CalnexParagon

    SpirentGEM

    ZTEZXR10 8905E

    MPLS encapsulated

    Telco SystemsT-Marc-380

    CiscoASR9010

    MRVOS940

    CienaCN5305

    HuaweiPTN3900

    Alcatel-Lucent1850 TSS-320

    RADETX-203A

    Orckit-CorrigentCM11

    IxiaIxNetwork

    Alcatel-Lucent7705 SAR8

    ZTEZXCTN 6200

    HuaweiCX600-X3

    CienaCN3960

    SikluEtherHaul 1200

    Alcatel-Lucent7750 SR7 SpirentTestCenter

    RaisecomiPN201

    Emulated PSNDelay measurement

    Loss measurement

    OmnitroniConverter GM3

  • Carrier Ethernet World Congress 2010 Multi-Vendor Interoperability Test Physical Network Topology

    10 11

    Carrier Ethernet World Congress 2010 Multi-Vendor Interoperability Test

    Physical NetworkTopology

    Alcatel-Lucent7750-SR7

    VitesseVTSS Caracal CE10

    EricssonSEA 20

    Cisco

    Management Systems

    ANA

    SpirentGEM

    ActusGanesh

    Telco SystemsT-Metro-7124S

    SymmetricomCsIII

    MRVOS904-MBH

    RaisecomiPN201

    ChronosSyncWatch 300

    ZTEZXCTN 6100

    HuaweiPTN1900

    Orckit-CorrigentCM4314

    ZTEZXCTN 6200

    HuaweiPTN910

    CienaCN5305

    CienaCN3940

    SpirentTestCenter

    Alcatel-Lucent7705 SAR8

    RADETX-204A

    VitesseVTSS Caracal CE10

    MRVOS906

    Telco SystemsT5C-XG

    EricssonMini-Link TN6p

    EricssonMini-Link TN20p

    EricssonMini-Link CN 500

    CienaCN3920

    Telco SystemsT-Marc-380

    SpirentTestCenter

    Telco SystemsT-Marc-380

    ZTEZXR10 5928ERAD

    ETX-203A

    SpirentTestCenter

    RaisecomiPN201

    RADETX-204A

    MRVOS904-MBH-4

    ChronosSyncWatch 300

    ZTEZXR10 2928E

    IxiaIxNetwork

    OmnitroniConverter GM3

    SikluEtherhaul1200

    NECiPasolink 200

    SpirentGEM

    CalnexParagon

    AlbisAcceed 2202

    ChronosSyncWatch 200

    HuaweiCX600-X1

    IP/MPLS

    CiscoMWR 2941

    CalnexParagon

    IxiaIxNetwork

    MPLS-TP

    Alcatel-Lucent9500 MPR

    MRVOS904-MBH

    CalnexParagon

    HuaweiCX600-X2

    Telco SystemsT-Metro-7224

    CienaCN3960

    IxiaIxNetwork

    AlbisAcceed 1416

    IxiaIxNetwork

    SymmetricomTimeProvider 5000

    RaisecomiPN201

    RADETX-204A

    SymmetricomTimeProvider 500

    MRVOS940 Symmetricom

    CsIII

    Aviat NetworksEclipse Packet Node

    Orckit-CorrigentCM11

    IxiaIxNetwork

    ActusGanesh

    SpirentGEM

    Telco SystemsT-Marc-254H

    RaisecomiPN201

    NECiPasolink 200

    Orckit-CorrigentCM11

    SikluEtherhaul1200

    ZTEZXR10 5128E

    OmnitroniConverter GM3

    ZTEZXR10 8905E

    Telco SystemsT-Metro-7224

    CiscoME3600X

    Alcatel-Lucent7750 SR-c12

    IxiaIxNetwork

    Telco SystemsT-Metro-200

    Alcatel-Lucent7750 SR7

    HuaweiCX600-X3

    CiscoASR 9010

    ZTEZXR10 M6000

    Orckit-CorrigentCM4140

    CiscoME3800X

    SymmetricomCsIII

    Orckit-CorrigentCM4314

    Orckit-CorrigentCM4206

    ZTEZXCTN 6300

    ZTEZXCTN 9004

    ZTEZXCTN 9008

    HuaweiPTN3900

    Alcatel-Lucent1850 TSS-320

    HuaweiPTN950

    Alcatel-Lucent1850 TSS-160

    Orckit-CorrigentCM4206

    Alcatel-Lucent1850 TSS-320

    HitachiAMN1710

    EricssonSEA 10

    EricssonOMS 1410

    Ethernet Aggregation

    ActusGanesh

    Telco SystemsT5C-XG

    RaisecomiPN201

    EricssonOMS 1410

    RaisecomiPN201

    Orckit-CorrigentCMview

    ZTEZXR10 T8000

    Network Areas

    Connection Types

    Analyzer/Emulator

    Provider router

    TDM link

    Clock link

    Synchronous Ethernet

    Microwave Radio link

    Device Types

    ProviderEdge device

    Access device

    Reference Clock

    Management system

    Ethernet link

    Radio access

    Business access

    Data center

    Impairment tool

    IEEE1588-2008 client

    Microwave radiosystem

    IP/MPLS network

    Ethernet Aggregation network

    MPLS-TP network

    IEEE1588-2008Grandmaster

  • Carrier Ethernet World Congress 2010 Multi-Vendor Interoperability Test Physical Network Topology

    10 11

    Carrier Ethernet World Congress 2010 Multi-Vendor Interoperability Test

    Physical NetworkTopology

    Alcatel-Lucent7750-SR7

    VitesseVTSS Caracal CE10

    EricssonSEA 20

    Cisco

    Management Systems

    ANA

    SpirentGEM

    ActusGanesh

    Telco SystemsT-Metro-7124S

    SymmetricomCsIII

    MRVOS904-MBH

    RaisecomiPN201

    ChronosSyncWatch 300

    ZTEZXCTN 6100

    HuaweiPTN1900

    Orckit-CorrigentCM4314

    ZTEZXCTN 6200

    HuaweiPTN910

    CienaCN5305

    CienaCN3940

    SpirentTestCenter

    Alcatel-Lucent7705 SAR8

    RADETX-204A

    VitesseVTSS Caracal CE10

    MRVOS906

    Telco SystemsT5C-XG

    EricssonMini-Link TN6p

    EricssonMini-Link TN20p

    EricssonMini-Link CN 500

    CienaCN3920

    Telco SystemsT-Marc-380

    SpirentTestCenter

    Telco SystemsT-Marc-380

    ZTEZXR10 5928ERAD

    ETX-203A

    SpirentTestCenter

    RaisecomiPN201

    RADETX-204A

    MRVOS904-MBH-4

    ChronosSyncWatch 300

    ZTEZXR10 2928E

    IxiaIxNetwork

    OmnitroniConverter GM3

    SikluEtherhaul1200

    NECiPasolink 200

    SpirentGEM

    CalnexParagon

    AlbisAcceed 2202

    ChronosSyncWatch 200

    HuaweiCX600-X1

    IP/MPLS

    CiscoMWR 2941

    CalnexParagon

    IxiaIxNetwork

    MPLS-TP

    Alcatel-Lucent9500 MPR

    MRVOS904-MBH

    CalnexParagon

    HuaweiCX600-X2

    Telco SystemsT-Metro-7224

    CienaCN3960

    IxiaIxNetwork

    AlbisAcceed 1416

    IxiaIxNetwork

    SymmetricomTimeProvider 5000

    RaisecomiPN201

    RADETX-204A

    SymmetricomTimeProvider 500

    MRVOS940 Symmetricom

    CsIII

    Aviat NetworksEclipse Packet Node

    Orckit-CorrigentCM11

    IxiaIxNetwork

    ActusGanesh

    SpirentGEM

    Telco SystemsT-Marc-254H

    RaisecomiPN201

    NECiPasolink 200

    Orckit-CorrigentCM11

    SikluEtherhaul1200

    ZTEZXR10 5128E

    OmnitroniConverter GM3

    ZTEZXR10 8905E

    Telco SystemsT-Metro-7224

    CiscoME3600X

    Alcatel-Lucent7750 SR-c12

    IxiaIxNetwork

    Telco SystemsT-Metro-200

    Alcatel-Lucent7750 SR7

    HuaweiCX600-X3

    CiscoASR 9010

    ZTEZXR10 M6000

    Orckit-CorrigentCM4140

    CiscoME3800X

    SymmetricomCsIII

    Orckit-CorrigentCM4314

    Orckit-CorrigentCM4206

    ZTEZXCTN 6300

    ZTEZXCTN 9004

    ZTEZXCTN 9008

    HuaweiPTN3900

    Alcatel-Lucent1850 TSS-320

    HuaweiPTN950

    Alcatel-Lucent1850 TSS-160

    Orckit-CorrigentCM4206

    Alcatel-Lucent1850 TSS-320

    HitachiAMN1710

    EricssonSEA 10

    EricssonOMS 1410

    Ethernet Aggregation

    ActusGanesh

    Telco SystemsT5C-XG

    RaisecomiPN201

    EricssonOMS 1410

    RaisecomiPN201

    Orckit-CorrigentCMview

    ZTEZXR10 T8000

    Network Areas

    Connection Types

    Analyzer/Emulator

    Provider router

    TDM link

    Clock link

    Synchronous Ethernet

    Microwave Radio link

    Device Types

    ProviderEdge device

    Access device

    Reference Clock

    Management system

    Ethernet link

    Radio access

    Business access

    Data center

    Impairment tool

    IEEE1588-2008 client

    Microwave radiosystem

    IP/MPLS network

    Ethernet Aggregation network

    MPLS-TP network

    IEEE1588-2008Grandmaster

  • 12

    Carrier Ethernet World Congress 2010 Multi-Vendor Interoperability Test

    In addition the Ericsson SEA 20 and the EricssonSEA 10 demonstrated frame loss, frame delay andframe delay variation measurement.Tests of the IP-based TWAMP protocol wereperformed between Ixia IxNetwork and CienaCN3960 using Calnex Paragon as impairmentdevice. Since both DUTs supported the SERVWAITdefined by RFC 5357 to last 900 seconds, the testwas performed over a few hours with at least 15minutes spent on each step.We verified that both DUTs were able to show thebaseline delay. The DUTs tested delay measurementin the direction from the IxNetwork to the CN3960.The test in the other direction had started but unfortu-nately not completed simply due to time constraints.Based on the configuration using the Ixia IxNetworkas the TWAMP Server and the Ciena CN3960 asthe Session-Receiver, we also tested delaymeasurement based on Y.1731.

    Link OAMLink OAM is a term that the MEF uses to refer toimplementations of OAM specified for Ethernet inthe First Mile (EFM), as defined in IEEE 802.3ah-2004. Link OAM describes multiple features, ourtests verified the following Link OAM features:• Loopback operation mode, which is meant to

    assist carriers in performing fault localizationand testing link performance.

    • Link events, that signal symbol and frameerrors in terms of either the number of errors ora seconds - a specified time period witherrors.

    • Dying Gasp, which is a critical link event, thatshould be generated, when a station is aboutto reboot ar shutdown. Operators can use thisindication arriving from an Access Device tolocalize the reason a customer connection iscurrently inactive.

    During the loopback mode tests we verified that aDUT port operating in active mode was able to bringa remote port into loopback mode. The portoperating in the loopback mode was expected todiscard all incoming frames destined towards theactive mode port and loopback all frames comingfrom the active port. The active port was expected todrop frames which were received from the remoteport operating in a loopback mode, after it hasupdated its port statistics. The following devicesparticipated in the loopback test: Albis Acceed2202, Albis Acceed 1416, Alcatel-Lucent 7750SR7, Alcatel-Lucent 7750 SR-c12, Cisco ME3600X,Ericsson SEA 20, Ericsson OMS1410, HuaweiCX600-X2, Ixia IxN2X, Ixia IxNetwork, OmnitroniConverter GM3, Orckit CM11, RAD ETX-204A,Raisecom iPN201, Vitesse VTSS Caracal CE10, ZTEZXR10 5128E,ZTE ZXR10 8905E, and ZTE ZXCTN9008.During the test we observed the following issues: onevendor device did not discard the loopback trafficcoming from the peer device port that was workingin the loopback mode; two other devices (each in adifferent test pair) when operating in loopback mode

    did not discard traffic arriving on the other interfaces(destined toward the active port / remote device,from the device in loopback mode). The traffic wasunexpectedly forwarded together with the loopbacktraffic to the remote DUT.

    Figure 5: Link OAM - Dying Gasp andLoopback

    We verified the ability of the DUTs to generate thefollowing link events: the number of frame errors,and the number of errored frame seconds within aspecified time period. We verified the DUT behaviorby using CLI or a management system. Each devicewas tested using three thresholds: 10 errored framesin 10 seconds, 10 errored frames 64 Byte frames at1 Gbit/s, and 5 errored frame seconds in oneminute. In order to test link events we introducederrors via either Calnex Paragon or Spirent GEMimpairment tools on the link between the DUTs. First,a traffic generator sent traffic filling the window ofthe peered device. Then the impairment tool intro-duced CRC errors into the traffic for five seconds attwo CRC errors per second. The device receivingtraffic was then expected to send one Errored FrameEvent, one Errored Frame Event, one Errored FramePeriod Event and one Errored Frame Second Eventwith a TLV value of 10 Errored Frames and 5Errored Frame Seconds. As shown in the diagram,seven vendors passed the test: Ciena CN5305, IxiaIxNetwork, Huawei CX600-X3, Omnitron iConverterGM3, Spirent TestCenter, Telco Systems T-Marc-380, Vitesse VTSS Caracal-1 CE10 and ZTE ZXR105128E.

    Dying Gasp Loopback

    Alcatel-Lucent7750 SR-c12

    Telco SystemsT-Marc-380

    AlbisAcceed

    SpirentTestCenter

    EricssonSEA 20

    AlbisAcceed 2202

    MRVOS904-MBH

    CiscoME3600X

    RaisecomiPN201

    ZTEZXR10 8905E

    OmnitroniConverter GM3

    ZTEZXR10

    Orckit-CorrigentCM11

    HuaweiCX600-X2

    VitesseVTSS Caracal

    RADETX-204A

    IxiaIxNetwork

    IxiaIxN2X

    ZTEZXCTN 9008

    CE10

    1416

    5128E

  • Managed Ethernet Services

    13

    Figure 6: Link OAM - Events

    The following devices successfully tested thesignaling of critical link events (Dying Gasp): AlbisAcceed 1416, Alcatel-Lucent 7750 SR-c12, CiscoME3600X, Huawei CX600-X2, MRV OS904-MBH,Omnitron iConverter GM3, RAD ETX-204A, TelcoSystems T-Marc-380, Vitesse VTSS Caracal CE10,ZTE ZXR10 5128E and ZTE ZXR10 8905E. Themajority of tests were performed by powering downof the device. The Alcatel-Lucent 7750 SR-c12verified the test by disabling the EFM session. TheCisco ME3600X and the Huawei CX600-X2performed the test by rebooting the device via CLI.

    Connectivity Fault ManagementCarrier Ethernet services are often built over multiplenetworks belonging to different administrativeentities. As part of the hierarchical model providedby Connectivity Fault Management (CFM), definedin IEEE 802.1ag, the Maintenance Domain (MD)and MD levels are key components that allowmonitoring of a single service within different admin-istrative domains. The entity of a higher MD levelgenerally has no access to the connectivity infor-mation of the lower level, in order to provide cleanseparation of responsibilities and prevent customersfrom learning the internal structure of operatornetworks without consent of the operator.

    Figure 7: Connectivity Fault ManagementIEEE 802.1ag

    CalnexParagon

    CalnexParagon

    CalnexParagon

    CalnexParagon

    SpirentGEM

    Errored Frame EventErrored Frame Period EventErrored Frame Seconds EventRemote Event Statistic (TLVs verified)Local Event Statistic (TLVs verified)Remote Event StatisticLocal Event Statistic

    SpirentTestCenter

    HuaweiCX600-X3

    SpirentTestCenter

    iConverter GM3Omnitron

    iConverter GM3Omnitron

    iConverter GM3Omnitron

    EricssonSEA 20

    T-Marc-380Telco Systems

    Vitesse VTSSCaracal CE10

    CienaCN5305

    EricssonSEA 20

    IxiaIxNetwork

    ZTEZXR10 5128E

    iConverter GM3Omnitron

    SpirentGEM

    RAD RADOmnitronETX-203A ETX-204A

    IxiaIxNetwork

    RADETX-203A

    Siklu EtherHaul IxiaIxNetwork

    Ericsson Omnitron Ericsson ZTE ZXR10

    iConverter GM3

    1200Siklu

    EtherHaul 1200

    SEA 20 iConverter GM3 OMS 1410 5928E

    Network service

    Provider

    Operatorlevel

    MaintenanceUp-MEPDown-MEPAssociation

    level

    MIP

    Ericsson EricssonSikluSEA 20 OMS 1410

    Orckit

    MRV

    Cisco

    Cisco

    RAD

    NEC

    Cisco

    CM4314

    OS906

    ME3600X

    ME3800X

    ETX-204A

    iPasolink 200

    Alcatel-Lucent

    ME3600X

    Alcatel-Lucent

    Ciena

    Ciena

    Alcatel-Lucent

    Cisco

    7750 SR7

    CN3906

    Siklu

    CN5305

    7750 SR-c12

    Ciena

    ASR9010

    Siklu

    Alcatel-Lucent

    MRV

    Cisco

    RAD

    7750 SR-c12

    OS940

    NEC iPasolink

    ASR9010

    ETX-203A

    NEC

    T5C-XG

    NEC iPasolink

    Orckit

    Ciena

    Cisco

    Ciena

    Alcatel-Lucent

    Ixia

    Cisco

    Cisco

    CM4206

    CN5305

    MWR2941

    CN3960

    7705 SAR8

    IxNetwork

    ME3800X

    MWR2941

    200

    200

    Telco Systems

    ZTE ZXR105928E

    7705 SAR8

    EtherHaul1200

    CN3960 iPasolink 200

    EtherHaul1200

    EtherHaul 1200

    Telco SystemsT-Marc-380

    RaisecomiPN201

    RaisecomiPN201

    Telco SystemsT5C-XG

    Alcatel-Lucent Alcatel-LucentRaisecom7750 SR7 7705 SAR8iPN201

    RaisecomiPN201

  • 14

    Carrier Ethernet World Congress 2010 Multi-Vendor Interoperability Test

    In many cases, especially when performing pathdiscovery and fault isolation, it is however useful toprovide more fine-grained continuity information tothe higher entity. This information is provided byconfiguring a Maintenance Association IntermediatePoint (MIP) on the higher level and at the position oflower level’s MEP; loss of connectivity between apair of MIPs corresponds to a MEP connectivityfailure at a lower MD Level. The MIPs present on acertain MD level can be used to perform theLinktrace procedure which is similar to theTraceroute tool known from IP.In this test we verified the CFM Linktrace function ofthe MIPs, configured to be accessible for adminis-trative entities situated on the Provider MD Level. Thelower Operator MD level was configured betweentwo MEPs situated at the position of the Provider MDLevel’s MIPs. In each MD Level the LinktraceMessages (LTMs) were transmitted by every MEP ineach direction both to the pair MEP at that MD level,and also to all MIPs configured at that MD Level.Thirteen vendors with a total of 25 devices partici-pated successfully in the test: Alcatel-Lucent 7750SR7, Alcatel-Lucent 7750 SR-c12, Alcatel-Lucent7705 SAR8, Alcatel-Lucent 7750 SR-c12, CienaCN3960, Ciena CN5305, Cisco ME3600X, CiscoME3800X, Cisco ASR9010, Cisco MWR2941,Ericsson SEA 20, Ericsson OMS1410, IxiaIxNetwork, MRV OS906, MRV OS940, NECiPasolink 200, Omnitron iConverter GM3, OrckitCM4314, Orckit CM4206, RAD ETX-203A, RADETX-204A, Raisecom iPN201, Siklu EtherHaul1200,Telco Systems T5C-XG and ZTE ZXR10 5928E.At one point we recognized that an LTM destined toone vendors MIP was not terminated, when a devicefurther upstream responded to the LTM.Cisco demonstrated the use of their ANAmanagement tool to run through the CFM andY.1731 procedure. Some network nodes wereautomatically discovered (Alcatel-Lucent 7705 SR-c12, Ciena CN5305). Using the tool, they initiatedlink trace messages from their ASR9010, as well asSiklu’s EtherHaul1200. Additionally, Y.1731 delaymeasurements were taken from the ASR9010 andthe Ciena CN5305, where Ciena CFM errormessage traps were used for the reporting.

    Service FailureThere are a number of heartbeat-like verificationtools defined for different technologies. Such toolshave the feature in common where they verify theliveliness of network services, which can be used bythe service provider or the network operator torecognize failures on the service path. As soon as aheartbeat-like tool recognizes a failure, ping-liketools are used in order to localize failures. Supportof such tools is a typical requirement for the ProviderEdge devices.The participating vendors intended to configure twotypes of network services: the intra- and the inter-domain network services. The liveliness of thesenetwork services were verified by the “heartbeat”-like OAM session configured on the DUTs.We focused the test based on the inter-domainservices which were transported over the virtual

    tunnels, such as the MPLS tunnels or the Q-in-Q(inner Ethertype: 0x8100/ other Ethertype: 0x88a8or 0x8100 for both Ethertypes) encapsulation. Incase of intra-domain service the network service wastransported via a single C-VLAN (Ethertype:0x8100) configured between two DUTs.We verified three “heartbeat”-like OAM protocolsduring the test: the CFM Continuity Check (CCCFM), the LSP BFD and the VCCV BFD.We used theimpairment devices Calnex Paragon and the SpirentGEM for all tests.As a first step we performed a baseline test withoutany impairment to verify that the proper configu-ration of the OAM protocols. In the next step usingthe impairment tool we introduced service failure bydropping all frames carrying the C-VLAN-IDassociated with the network service in one direction,and verified that the failure was reported in thedirection in which the impairment was introduced,the Remote Defect Indication (RDI) was propagatedin the opposite direction. In addition, we verifiedthat the ping-like OAM protocol requests were notresponded by the remote peer indicating the servicefailure between both DUTs.

    Figure 8: Service Failure (Inter-DomainNetwork Services)

    In case of the inter-domain service we verified theliveliness of the tunnel when the DUT supported thesecond “heartbeat”-like OAM session for the tunnel.When performing the service failure we verified thatthe tunnel was up and the OAM ping went throughover the tunnel. Then, we introduced tunnel failureby dropping all frames associated with a tunnel IDsuch like S-VLAN-ID or the MPLS label, and verifiedthat the failure was reported at the tunnel level andat the service level. In this case the OAM ping wasnot responded at both levels by the remote peer.The following devices successfully tested the servicelevel failure using inter-domain network services:

    CienaCN5305

    AlbisHuaweiAcceedCX600-X1

    SpirentTestCenter

    MRVOS904-MBH 1416

    CienaCN3960

    EricssonSEA 20

    OmnitroniConverter

    SikluEtherHaul

    GM3

    1200

    ZTE

    ZTEZTEZXR10

    ZXR10ZXR105928E

    T80005128E

    CiscoASR9010

    CalnexParagon

    1 level OAM session2 level OAM session

    Impairment

    SpirentGEM

    IxiaIxNetwork

  • Carrier Ethernet Resiliency

    15

    Albis Acceed 1416, Albis Acceed 1416, CienaCN3960 and CN5305, Cisco ASR9010, EricssonSEA 20, Huawei CX600-X1, Ixia XM12, IxiaIxNetwork, MRV OS940, Omnitron iConverterGM3, Siklu EtherHaul1200, Spirent TestCenter, ZTEZXR10 5928E, ZXR10 T8000 and ZXR10 5128E.The Cisco ASR9010 and Huawei CX600-X1 testedthe two level service failure using CFM over an MPLSPseudowire and MPLS OAM (LSP Ping/Traceroute).The Ixia IxNetwork and the Ericsson SEA 20 testedthe two level service failure using network servicewith Q-in-Q (0x8100/0x88a8) encapsulation.In addition, the following devices successfully testedthe service level failure using intra-domain services:Albis Acceed 1416, Alcatel-Lucent 7750 SR7,Ciena CN5305, Cisco ASR9010, Ericsson SEA 20,Huawei CX600-X1, Ixia IxNetwork, MRV OS904-MBH, Omnitron iConverter GM3, Orckit-CorrigentCM4314, Orckit-Corrigent CM11, SpirentTestCenter, Telco Systems T-Marc-380, ZTE ZXR10T8000, ZTE ZXR10 8905E and ZTE ZXR10 M6000.We discovered an interoperability issue: Mostvendors supported MD names as string, two vendorsimplemented MD name using No MaintenanceDomain Name present. As a consequence, theOAM discovery failed in some cases.

    Failure PropagationFinally we verified two scenarios of OAM FailurePropagation. In one scenario (CFM level inter-working) we verified propagation of failure notifica-tions between different CFM levels. In the otherscenario (OAM protocol interworking) we verifiedOAM Failure Propagation between MPLS and CFMOAM protocols.The Alcatel-Lucent 1850 TSS-320, Alcatel-Lucent1850 TSS-160, ZTE ZXCTN9004 and ZTEZXCTN9008 successfully tested CFM level inter-working. The failure propagation was performedover MPLS-TP based on the draft-bhh-mpls-tp-oam-y1731 using AIS messages. Huawei CX600-X2,Huawei CX600-X1 and Cisco ASR9010 successfullytested OAM protocol interworking. Between HuaweiCX600-X2 and Huawei CX600-X1 MPLS VCCV BFDwas configured. Huawei CX600-X1 and CiscoASR9010 configured CC CFM at MD level 5.Huawei CX600-X1 performed failure propagationbetween CC CFM and MPLS VCCV BFD.

    LLDPLink Layer Discovery Protocol (LLDP) is used todiscover information about neighbors on a networknode. The node can obtain information such as TimeTo Live (TTL), Port Identification (Port ID), and ChassisIdentification (Chassis ID) about its neighbors byimplementing LLDP.We identified several different implementations ofLLDP. Specifically the Port ID and Chassis ID fieldshad a range of outputs, be that a string, MediaAccess Control (MAC) address, or a hexadecimalnumber. Also in several scenarios vendors did notdisplay their neighbor’s TTL field.

    There were 9 vendors who participated and a totalof 18 different devices. The following devicessuccessfully participated in tests for LLDPs excludingthe Chassis ID change: Ciena CN3960 with MRVOS906, Orckit-Corrigent CM4314; CiscoME3800X with Alcatel-Lucent 7750 SR7, CienaCN5305, MRV OS906, and Telco Systems T5C-XG;Ciena CN 5305 with Spirent TestCenter; TelcoSystems T-Marc-380 with MRV OS904-DSL4, andRaisecom iPN201 with Ciena 3920, ZTE ZXR105128E, ZTE ZXR10 5928E, ZTE ZXCTN9004 andZTE ZXR10 T8000. Spirent TestCenter tested thechanging of their Chassis ID.

    CARRIER ETHERNET RESILIENCY

    Ethernet Ring Protection Switching(ERPS)As network operators deploy Carrier Ethernetservices, they are falling a bit short on resiliencymechanisms for their access networks. SpanningTree is the old go-to, but many operators are wearyof using this enterprise protocol for their services.Ethernet Ring protection Switching (ERPS), defined inITU-T Recommendation G.8032, provides a meansof achieving such resiliency. The original version ofthe standard (commonly referred to as “version 1”)supports resilient ring topologies. The more recentversion, updated this year and referred to as“version 2” introduces a range of additional featureslike ring interconnection, and administrativeAutomatic Protection Switching (APS) commands likeForce Switch and Manual Switch for manual controlof the network.After the “version 1” rings were properly configuredwith the R-APS VLAN and service VLAN in allscenarios, bidirectional traffic flows were sentbetween the two ring nodes. We successfullyverified in all scenarios that the RPL ownerunblocked his RPL port upon physical link failurebetween two ring nodes. The observed failover timesranged from 2 – 55 ms, and the restoration timeranged from 6 – 21 ms. There were no major issues.Three multi-vendors rings based on version 1 weretested: Telco Systems T5C-XG, Raisecom iPN201and Ericsson OMS 1410; RAD ETX-204A, VitesseCaracal CE10 and MRV OS906; Vitesse VTSSCaracal CE10, MVR OS906 and Ciena CN3920.The RPL owner of each ring was TelcoSystems T5C-XG, MRV OS906 and Ciena CN3920 respectively.The Ericsson OMS 1410, implementing “version 2”of the standard demonstrated interoperabilitybetween the first “version 1” ring — a new featureof the standard, currently under development by ITU-T from SG15 Q9.The following systems took part in tests of “version2”: Telco Systems T5C-XG, Raisecom iPN201,Ericsson OMS 1410, Actus Ganesh and CienaCN3920. Figure 9 depicts the two topologies whichwere tested, and reflects how in each case therewere two interconnecting nodes between the sub-rings. Failover times did not exceed 35.5 ms and therestoration time from the Telco Systems ring was 4.5ms. In each scenario, we also verified that a failurein the one sub-ring didn’t affect the operation of the

  • 16

    Carrier Ethernet World Congress 2010 Multi-Vendor Interoperability Test

    other sub-ring.We also successfully tested administrativecommands in both rings — manual and force switch— to move the port block from Ring Protection Link(RPL) port to a port on a different ring link. Themeasured force switch times were 6.5 ms and 2 msand the measured manual switch times were 2.5 msand 6.5 ms. Manual and force switch commandwas also successfully removed by a Clear commandin all scenarios.When moving to the “version 2” tests, we initiallyencountered a difficulty of finding which multicastMAC to be used in the sub-ring for sending R-APSbecause of some ambiguity in the standard aboutinterpreting the last byte of the MAC addresses usedfor G.8032 R-APS messages communication — thestandard mandates the use 01-19-A7-00-00-[RingID] on one hand and to use 01-19-A7-00-00-01 onthe other hand. Naturally, different vendors inter-preted this differently. Vendors have taken twodifferent approaches in implementing the ETHDi/ETH_A function that extracts and generates the R-APS messages. Some require a MEP to beconfigured and running CCM, others do not. Thiscan lead to interworking problems based on CCMbehavior: In particular we observed that somevendors were not able to configure their CCMinterval below 1 s (as soon as the CCM wasconfigured below this value the CCM session failed).Moreover, some vendors could not function as theinterconnection device, though they claimed supportfor other features in “version 2”.Currently ITU-T SG15 Q9 is developing version 3 ofG.8032, where the topic of connecting non-ERPnodes into an ERP network topology is beingaddressed. To demonstrate this, Ericsson connectedtheir Mini-Link TN into a ring built using an ActusGanesh, Ericsson OMS 1410, Ericsson SEA 10.Failover times were measured as we removed the

    link between two ring nodes (Ericsson OMS 1410and Ericsson SEA 10).

    Ethernet Linear ProtectionSwitchingEthernet Linear Protection Switching (ELPS) allowscarrier networks to quickly recover from failure toensure high reliability and network survivability.ITUT G.8031 defines the specification of ELPS toprotect point-to-point ethernet service paths by usingdisjoint protection paths. Automatic ProtectionSwitching (APS) is also defined in the same standardto allow both head-end and tail-end of the protecteddomain to co-ordinate and switchover the protectionpath in the failure event.We accomplished this test in two scenarios using1:1 bidirectional architecture and revertivemechanism. Both head-ends and tail-ends wereusing APS to coordinate the switchover in the case ofa link failure event. We tested Ethernet LinearProtection among Alcatel-Lucent 7750-SR7, VitesseVTSS Caracal, RAD ETX-204A and RaisecomiPN201 in a 1:1 architecture with revertive modeenabled.The first test scenario was performed betweenAlcatel-Lucent 7750-SR7 and Vitesse VTSS Caracalusing Loss Of Signal as trigger; the second scenariowas between RAD ETX-204A and Raisecom iPN201using impaired CCMs as a trigger. CCMs were sentat 100 ms intervals to check the liveliness of the link.For both tests primary and secondary paths wereconfigured. Each path was configured with differentVLAN IDs for control traffic. After breaking down thelink on the primary, traffic was redirected to thesecondary path. Neither failover time nor restorationexceeded 50 milliseconds.

    Figure 9: ERPS Test Results

    EricssonOMS 1410

    Ethernet Network

    Backup Path

    Primary Path

    Telco SystemsT5C-XG

    Telco SystemsT5C-XG

    Traffic

    Port blocking

    Telco Systems T5C-XG

    EricssonOMS 1410

    RaisecomiPN201

    Generator

    Link Failure

    Impairment Tool

    EricssonOMS 1410

    Raisecom

    ActusGanesh

    CienaCN3920

    Calnex Paragon

    iPN201

    MRV OS906

    VitesseVTSS Caracal CE10

    RADETX-204A

    Ciena CN3920

    MRV OS906Vitesse

    VTSS Caracal CE10

    RaisecomiPN201

    Protected Service

  • Carrier Ethernet Resiliency

    17

    We also successfully tested the APS commandincluding Lockout of protection, force switch normaltraffic-to-protection and Manual switch normal traffic-to-protection. After sending Lockout of protectionand breaking down the link on the primary path100% loss was observed in both scenarios. Bysending Force switch normal traffic-to-protection andManual switch normal traffic-to-protection from bothDUT and breaking down the link on the secondarypath in both scenarios the expected behavior wasobserved, the recorded switchover time rangedbetween 3 ms and 300 ms.

    Figure 10: ELPS Results

    In another vendor pair, we discovered a section ofthe Y.1731 specification which was interpreted inmultiple ways. Section 9.1.1 talks about the MEG IDByte set and references to appendix A. In appendixA it is stated the UMC ID SHALL consist of 7-12characters with trailing NULLs. This was interpretedin two ways: a) There should only be 12 charactersand if there was less use NULL as padding in the lastcharacter; b) There is an additional character afterthe UMC ID.

    Connectivity Redundancy usingContinuity CheckIn a relatively basic test, we verified that IEEE802.1ag defined CFM could be used to detectfailure on a specific service on a given link, while aservice on the same link was still healthy.Two services were established between DUT1 andDUT2 using VLANs — two services, each with adifferent VLAN ID. CFM with a period of 3.33 mswas configured for both services to monitor theirliveliness. We first sent traffic on working path andverify that the traffic was indeed using the workingpath by capturing frames and checking the VLANID. We then used the impairment tools to drop allCCM packets on the working path for a singleservice. Traffic was then expected to move from theprimary to the secondary path and we measured thefailover time. After restoring the CCM connectivity,the traffic was returned back to the working path.This demonstration was conducted between two

    Raisecom iPN201 nodes. The Alcatel-Lucent 7750-SR7 and Cisco ME3800X performed this test usingthe CFM CC protocol to drive interface state andtrigger IP Routing reconvergence in the event offailure of the most preferred route configured withthe best administrative distance.

    MPLS-TP 1:1 LSP ProtectionThe telecommunications industry has watched theITU-T and IETF discuss and define the MPLSTransport Profile (MPLS-TP) with great interest, andseems ready to come to some conclusions. Whilethere may not be complete consensus regarding thedirection of the technology, most agree that MPLS-TPis a technology that operators can compare to theirtransmission networks — currently based on SDH/SONET lines. Resiliency is surely a key aspect, as isOAM, where the past two years of discussions havebeen heavily focused. Most recently, one of theauthor drafts for a Bidirectional ForwardingDetection (BFD) based OAM titled «ProactiveConnection Verification, Continuity Check andRemote Defect Indication for MPLS Transport Profile»has been accepted by the IETF MPLS working group.In parallel, a series of vendors registered to theinterop event ready to test their OAM solutionsbased on ITU-T Recommendation Y.1731.Members of our service provider review panelconfirmed their interest of a test of all available draftor pre-draft MPLS-TP OAM options to explore in howfar current vendor solutions can satisfy operators’requirements for superior protection, fault andperformance management in the MPLS-TP spacealready. The carriers confirmed they are activelywatching the MPLS-TP standardization, hoping for afast and comprehensive implementation of latestdrafts to progress the industry. While it would bedesirable to converge to a single protocol option inthe end, the viability of all options on the tableshould be explored at this point.The channel over which OAM should be transmittedhas been standardized for some time now by RFC5586, “MPLS Generic Associated Channel”. Thechannel specifies how OAM frames can be detectedbased on MPLS labels, as opposed to MAC or IPaddresses. The following devices established LabelSwitched Paths (LSPs) and exchanged OAMmessages over this channel: Alcatel-Lucent 1850TSS-160, Alcatel-Lucent 1850 TSS-320, HuaweiCX600-X3, Hitachi AMN1710, Huawei PTN910,Huawei PTN950, Huawei PTN3900, IxiaIxNetwork, Orckit-Corrigent CM4314, Orckit-Corrigent CM4206, and ZTE ZXCTN6300.The next step was to verify that the loss of OAMframes would cause the network to switch serviceframes over to a backup LSP. Two methodologieswere used to break connectivity — a physical linkbreak — performed between intermediate nodes sothat the end device would not experience a linkfailure — and an impairment of continuity in a singledirection. The following devices successfully partici-pated in the protection test: Alcatel-Lucent 1850TSS-320, Huawei PTN3900, Huawei CX600-X3, Orckit-Corrigent CM4206, Orckit-Corrigent CM4314, and

    Alcatel-Lucent

    Working path

    Protection path

    Ethernet linkPacket Network

    Vitesse

    RADETX-204A

    RADETX-204A

    RAD RaisecomETX-204A iPN201

    VTSS Caracal CE107750 SR7

    Link Failure

    Traffic Generator

  • 18

    Carrier Ethernet World Congress 2010 Multi-Vendor Interoperability Test

    ZTE ZXCTN6300.

    Figure 11: MPLS-TP 1:1 LSP Protection

    In order to perform this test several multi-vendorspairs were built (see diagram). The observed failovertimes ranged between 13 to 28 ms for link failure.The OAM tools from these vendors was based ondraft-bhh-mpls-tp-oam-y1731 and the linearprotection was tested according to draft-zulr-mpls-tp-linear-protection-switching-01. Besides the protectionswitching due to link failure, APS commands “forceswitch normal traffic signal-to-protection” and“manual switch normal signal-to-protection” weresuccessfully tested between all the above mentionedvendor’s devices. However in one scenario when the“Lockout of protection” command was tested, weobserved 100% loss in one direction and 24% inother direction between Huawei CX600-X3 andOrckit-Corrigent CM4206, 100% loss was observed

    between other vendors pair. Finally, we alsosuccessfully tested failure based on test parametermismatch including MEP_IG and MEG_ID andobserved that traffic was moved to protection path.Hitachi AMN1710 and Ixia IxNetwork, supportingBFD based OAM according to draft-ietf-mpls-tp-cc-cv-rdi, also interoperated at an OAM level, bringing upan MPLS-TP pseudowire and BFD session betweenthe two.

    MPLS Pseudowire Redundancy andH-VPLS Dual HomingMPLS pseudowire redundancy and multi-homedMulti Tenant Unit switches (MTU-s) in H-VPLS caneach be used to protect different parts of an MPLSnetwork - an attachment circuit failure, and a spoke-PW failure, respectively.Pseudowire Redundancy is being standardizedby the IETF in two drafts: draft-ietf-pwe3-redundancywhich defines a framework and architecture ofpseudowire redundancy, and draft-ietf-pwe3-redun-dancy-bit, which describes a mechanism for standbysignaling of a redundant pseudowire.

    Figure 12: Pseudowire Redundancy

    In all test scenarios a Telco Systems T5C-XG wasdual-homed using two attachment circuits each to aseparate PE, and each configured with apseudowire terminated at a common “switchoverPE”. Both pseudowires were operationally up but thepreferential forwarding status of one of thepseudowire was active. In all test scenarios thefailure of the attachment circuit triggered pseudowireswitchover on the “switchover PE” and traffic wasredirected to the secondary pseudowire as

    CM42061850 TSS-320

    Traffic Generator

    Impairment Tool

    Alcatel-Lucent Alcatel-Lucent1850 TSS-320 1850 TSS-160

    Alcatel-Lucent Orckit-Corrigent

    CM4314CX600-X3Huawei Orckit-Corrigent

    Spirent XGEM

    Working pathProtection pathEthernet link

    Link failure

    Customer domain

    MPLS-TP domain

    ZXCTN 63001850 TSS-320

    Alcatel-Lucent Alcatel-Lucent1850TSS-320 18850 TSS-160

    Alcatel-Lucent ZTE

    CX600-X31850TSS-320

    Alcatel-Lucent Alcatel-Lucent1850TSS-320 1850TSS-160

    Alcatel-Lucent Huawei

    CM4314PTN3900

    Huawei HuaweiPTN910 PTN950

    Huawei Orckit-CorrigentTelco SystemsT-Metro-7224

    Cisco ME3600X

    CX600-X2Huawei

    T5C-XGTelco Systems

    Ciena CN5305

    Cisco ME3600X

    T-Metro-7224Telco Systems

    T5C-XGTelco Systems

    Ciena CN5305

    Telco Systems T-Metro-200

    ASR-9010Cisco

    T5C-XGTelco Systems

    Working path

    Protection path

    Ethernet linkMPLS domain

    Customer domain

    Traffic generator

    Link failure

  • References

    19

    expected. The failover times was ranged everywherefrom 3 ms to 3400 ms depending on which vendor’sequipment was the “switchover PE” doing theswitchover. The Telco Systems T-Metro-7724,Huawei CX600-2 and Cisco ASR9010 were eachused as the «switchover PE». The Cisco ME3600Xand Ciena 5305 were used as the near end PEs,dual homing the attachment circuit and signaling thePW status to the far end PE.H-VPLS Dual Homing can be used by serviceproviders to protect the otherwise isolated customer(hence “spoke”). Since PEs can be a single point offailure, MTU-s can peer with two hub PEs using twoactive/standby spoke PWs. Since both spoke PWsare grouped under the MTU-s only one of them canbe active at any point of time and forward traffic.Upon failure of the active spoke PW MTU-s causes aswitchover from active to standby spoke-PW.Combined with the LDP feature of MAC AddressWithdraw, H-VPLS dual homing can be used toavoid a possible traffic black hole.Three vendors participated in this test: CienaCN5305, Telco Systems T-Metro-7224 and CiscoASR9010. The Ciena CN5305 was configured as aMTU-s, dual-homed to the Cisco ASR9010 and TelcoT-Metro-7724 PEs. After the active spoke PW wastorn down, the Ciena CN5305 successfully switchedthe bidirectional traffic over the secondary PW. TheCisco ASR9010 was able to send LDP MACAddress Withdraw after the recovery of the primaryspoke PW and failure of secondary spoke PWwhere the Cisco ASR9010 was connected. Sinceautomatic restoration was not supported, the PWswere reverted back to active manually.

    AcknowledgementsEditors. Jonathan Morin, Sergej Kälberer, RonsardPene, Xiao Tai Yu and Carsten Rossenhövel (allEANTC) co-authored this document.In addition, we would like to thank Joe Miller andStephen Murphy from the University of NewHampshire Interoperability Lab (UNH-IOL) forsupporting the test and contributing to the whitepaper under the EANTC/UNH-IOL collaborationprogram.

    REFERENCES“Precision Time Protocol (PTP)”, IEEE 1588-2008“Mobile Backhaul Implementation Agreement Phase 2”, MEFtechnical spec-ification, work in progress“Timing and Synchronization Aspects in Packet Networks”, ITU-TG.8261/Y.1361“Precision Time Protocol Telecom Profile for frequency synchroni-zation”, ITU-T G.8264.1, work in progress“Timing characteristics of synchronous Ethernet equipment slaveclock (EEC)”, ITU-T G.8262/Y.1362“Distribution of timing through packet networks”, ITU-T G.8264/Y.1364“Synchronization layer functions”, ITU-T G.781“Encapsulation Methods for Transport of Asynchronous TransferMode (ATM) over MPLS Networks”, RFC 4717“Ethernet ring protection switching”, ITU-T G.8032/Y.1344, March2010“Ethernet linear protection switching”, ITU-T G.8031/Y.1342,November 2009“Pseudowire (PW) Redundancy” draft-ietf-pwe3-redundancy, May2010“Pseudowire Preferential Forwarding Status Bit”, draft-ietf-pwe3-

    redundancy-bit, May 2010“Pseudowire Setup and Maintenance Using the Label DistributionProtocol (LDP)”, RFC 4447“MPLS transport Profile Data Plane Architecture”, draft-ietf-mpls-tp-data-plane“A Framework for MPLS in Transport Networks”, draft-ietf-mpls-tp-framework“MPLS-TP OAM based on Y.1731”, draft-bhh-mpls-tp-oam-y1731“Linear Protection Switching in MPLS-TP”, draft-zulr-mpls-tp-linear-protection-switching“Proactive Connection Verification, Continuity Check and RemoteDefect indication for MPLS Transport Profile”, draft-ietf-mpls-tp-cc-cv-rdi“Virtual Private LAN Service (VPLS) Using Label Distribution Protocol(LDP) Signaling” RFC 4762“Virtual Bridged Local Area Networks - Connectivity FaultManagement”, IEEE 802.1ag“OAM functions and mechanisms for Ethernet based networks”,ITU-T Y.1731

    ACRONYMSTerm Definition

    APS Automatic Protection Switching

    BFD Bidirectional Forwarding Detection

    CCM Continuity Check Message

    CLI Command Line Interface

    CFM Command Line Interface

    EEC Synchronous Ethernet Equipment clock

    ELPS Ethernet Linear Protection Switching

    ERPS Ethernet Ring Protection Switching

    ESMC Ethernet Synchronization Messaging Channel

    H-VPLS Hierarchical VPLS

    IEEE Institute of Electrical and Electronics Engineers

    IETF Internet Engineering Task Force

    ITU-T International Telecommunication Union Telecom-munication Standardization Sector

    LDP Label Distribution Protocol

    LOS Loss of Signal

    LSP Label Switching Path

    LTE 3GPP Long Term Evolution

    MBMS Multimedia Broadcast Multicast Service

    MEG Maintenance Entity Group

    MEP Maintenance Entity Point

    MIP Maintenance Domain Intermediate Point

    MNCP Maximum Number of Cells Packed

    MPLS Multi-Protocol Label Switching

    MPLS-TP MPLS Transport Profile

    MTIE Maximum Time Interval Error

    MTU-s Multi Tenant Unit - switch

    OAM Operation, Administration and Maintenance

    PE Provider Edge

    PRC Primary Reference Clock

    PTP Precision Time Protocol

    PW Pseudowire

    QL Quality Level

    RPL Ring Protection Link

    SEC SDH equipment slave clocks

    SSM Synchronization Status Messages

    SSU Synchronization Supply Unit

    SyncE Synchronous Ethernet

    TOD Time of Day

    VLAN Virtual Local Area Network

  • Test

    Authored by:EANTC AGEuropean Advanced Networking Test Center

    Hosted by: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 © 2010 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 contained herein.All brand names and logos mentioned here are registered trademarks of their respective companies in the UnitedStates and other countries.v1.0

    Setup at EANTC Lab, August 2010

    Editor’s NoteIntroductionParticipants and DevicesInteroperability Test ResultsNetwork DesignSynchronization For LTE Mobile BackhaulFrequency and Time of Day Synchronisation over IEEE 1588-2008 (PTPv2)Synchronous Ethernet and ESMCEthernet Synchronization Messaging Channel (ESMC)

    Converged TransportInterworking Between Transport DomainsPBB-VPLS InterworkingEthernet Radio TransportATM Pseudowire Emulation

    Managed Ethernet ServicesPerformance MonitoringLink OAMConnectivity Fault ManagementService FailureFailure PropagationLLDP

    Carrier Ethernet ResiliencyEthernet Ring Protection Switching (ERPS)Ethernet Linear Protection SwitchingConnectivity Redundancy using Continuity CheckMPLS-TP 1:1 LSP ProtectionMPLS Pseudowire Redundancy and H-VPLS Dual HomingAcknowledgements

    ReferencesAcronyms