2
Carrier Ethernet World Congress 2010 Multi-Vendor Interoperability Test
EDITOR’S NOTE
As 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.
INTRODUCTION
There 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 CONTENTS
Participants 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 RESULTS
Each 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 DESIGN
In 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 BACKHAUL
One 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 6100Raisecom
iPN201
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 200ZTE
ZXR10 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 TRANSPORT
Data 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 Spirent
TestCenter
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
ACRONYMS
Term 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
Top Related