carrier ethernet world congress 2012 public multi-vendor ... · achieved in optical link failure...

Public Multi-Vendor Interoperability EventCarrier Ethernet World Congress 2012

White Paper

2

Carrier Ethernet World Congress 2012 Multi-Vendor Interoperability Test

EDITOR’S NOTE

What are the hot topics forCarrier Ethernet business,wholesale and mobilebackhaul services this year?The agenda of the CarrierEthernet World Congressnames quite a few areas —but which of these are readyfor testing?In our interoperability tests,we aim to evaluate innovativepacket transport technologies,

physically available solutions, and areas that aremost relevant for service provider deployments in thefuture. While a conference agenda can be formedas the union of these three goals, we have to findtheir intersection to facilitate testing.That’s why we reserved tests of software-definednetworking and specifically OpenFlow for futureevents — it is too early for interoperability testing inthe context of Carrier Ethernet services today. Cloudtests stayed out because standards-based innovationhappens mostly in the data center these days, not inCarrier Ethernet networks. MPLS-TP focused onspecific tests (see below) due to the limited numberof actually available, interoperable implementations.I am happy that this allowed usto focus on a couple of veryrelevant and factual test areas:

• Mobile backhaul remains akey driver for CarrierEthernet network design anddeployment. Indeed it is oftenthe driver for the serviceprovider to upgrade a packetnetwork. We evaluatedadvances in packet-basedclock synchronization for LTE-TDD scenarios includingboundary clocks — with verypositive outcome: Eight testcases were successfully evaluated in 17 testcombinations.The clock synchronization tests included a newmetric, called “Floor Packet Population” whichenables service providers to measure theirnetwork’s readiness to transport packet-basedclocking easily — without the need to install thefull backhaul solution in the first place.In addition, we were excited to test four trans-parent clocks as well as a clock recoverymechanism that uses a hybrid method to provideboth frequency and phase signal.

• Two of our test areas are in line with the MEF’snew campaign of “Carrier Ethernet 2.0.” CE 2.0 is a group of MEF specifications andimplementation agreements released in therecent past that the MEF packaged in a release.The benefit is that most of the underlying industrystandards from IEEE, ITU and others have beenaround for a while so the industry is mostly ready

for CE 2.0 today. This allowed us to implementelaborate scenarios.In this event, we successfully tested hierarchicalService OAM at multiple protocol levels — atopic where interoperability is specificallyimportant, as service providers will almostalways use equipment from multiple vendors inthe access, aggregation and core network areas.We even included Management InformationBase (MIB) objects in accordance with MEF 31and 35 in our tests.As another aspect of CE 2.0, we tested thesupport for multiple classes of service (“multi-CoS”) in our service activation test as well as inour microwave prioritization test. While Ethernethas supported CoS for ages, it may be difficultfor service providers to implement it consistentlyacross all equipment and manage CoS correctlyover time. Service activation tests enable afactual check at provisioning time, for each newvirtual circuit.

• Our multi-vendor resiliency testing campaigncontinued with more advanced scenarios aswell. Dual-homing of Ethernet rings attached toan MPLS or MPLS-TP core was tested successfully:Sub-50 millisecond recovery times wereachieved in optical link failure cases.

The test areas and results showthat Carrier Ethernet solutions arereliable these days, as expected; itis important for manufacturers,specifically in the areas of(microwave and wireline) aggre-gation and access, to continueinnovate. Service providers aim touse Carrier Ethernet solutions todifferentiate from their competition,and to provide more versatile andeasier to manage services withstringent service-level agreements.To this end, the vendors partici-

pating in our showcase proved that serviceproviders can rely on multi-vendor interoperability.After two weeks of intense testing at EANTC’s lab inBerlin, Germany, we are proud to present the resultsof the joint work of all participating vendors and theEANTC team in this white paper.

INTEROPERABILITY TEST RESULTS

The following sections of the white paper describethe test areas and results of the interoperabilityevent. We use the term “tested” when reporting onmulti-vendor interoperability tests. The term “demon-strated” refers to scenarios where a service orprotocol was terminated by equipment from a singlevendor on both ends.In order to perform our tests we had to generate,measure, impair, and analyze traffic and performsynchronization analysis. We thank Ixia and SpirentCommunications for their support.

Carsten RossenhövelManaging Director

EANTC

TABLE OF CONTENTS

Service Activation .......................3Hierarchical Service OAM...........5Microwave MPLS-TP QoS Support .7Topology....................................8ERPSv2 and VPLS Interworking ...10Clock Synchronization...............11IEEE 1588v2 Boundary Clocks ...12

3

Service Activation

PARTICIPANTS AND DEVICES

MANAGED SERVICES

The topic of managed services has become a staplein our events. Here we cover test areas which shouldprovide service providers the means to roll outservices as well as monitor them efficiently. As suchwe looked at several new implementations of serviceactivation testing performed on access devices aswell as hierarchical service OAM and performancemonitoring.

Service ActivationIn last year’s Carrier Ethernet World CongressInteroperability Event we tested, for the first time, aset of methodologies to verify that a service hasbeen configured and is performing correctly. Theseare grouped under a standard, defined by the ITU-T,called Y.1564 – “Ethernet service activation testmethodology”. In 2011 one test vendor was able to

demonstrate an implementation of the standard. Thisyear, several access device vendors were ready withan implementation. The standard describes in detailsthe test methodologies and test steps for differenttype of services such as color aware and color blindservices, for different service parameters likeCommitted Information Rate (CIR), Excess Infor-mation Rate (EIR), Committed Burst Size (CBS) andExcess Burst Size (EBS). The test methodology also evaluates the serviceobjective performance parameters defined inService Level Agreement (SLA). These parametersinclude Information Rate (IR), Frame Loss Ratio (FLR),Frame Transfer Delay (FTD), Frame Delay variation(FDV) and Availability (AVAIL). With these para-meters a service provider can verify that the serviceis correctly configured and is functioning in accor-dance to the SLA before the service is handed overto the customer. Should issues with the service ariseat a later time, the service provider can at leastprove that the service was working correctly when itwas set up for the customer.So in order to create a test case that is as realistic aspossible, we asked the participating vendors tocreate two Ethernet Virtual Private Line (EVPL)services. We then treated the two EVPLs as newservices that a service provider would like toactivate. The first service, EVPL 1, was defined tooperate in a color-aware mode. The second service,EVPL 2, was configured in color blind mode.

Vendor Devices

Albis Technologies

ACCEED 1104ACCEED 1416ACCEED 2202

Aviat Networks Eclipse Packet Node

Ericsson MINI-LINK TNMINI-LINK PT2010MINI-LINK SP210MINI-LINK SP310SPO1410SPO1460

HFR CET-10216CET-10448

Ixia Anue 3500Anue HawaiiImpairNetIxNetwork

NEC iPASOLINK 400

Omnitron iConverter GM4

SIAE ALCplus2eALFOplus80

SpirentCommunications

Spirent Paragon-XSpirent TestCenter

Symmetricom TimeProvider 500TimeProvider 1500TimeProvider 5000SSU 2000e

EVPL 1 – Color aware service

Hig

h

PCP = 5 Green CIR = 5 Mbit/sCBS = 12,176 BEIR = 0 Mbit/sEBS = 0 B

PCP = 4 Yellow

Med

ium

PCP = 3 Green CIR = 10 Mbit/sCBS = 12,176 BEIR = 10 Mbit/sEBS = 12,176 B

PCP = 2 Yellow

Low

PCP = 1 Green CIR = 0 Mbit/sCBS = 0 BEIR = 15 Mbit/sEBS = 12,176 B

PCP = 0 Yellow

EVPL 2 – Color blind service

Med

ium

PCP = 3 N/Aa

a. Not applicable

CIR = 15 Mbit/sCBS = 12,176 BEIR = 0 Mbit/sEBS = 0 B

Low

PCP = 1 N/A CIR = 20 Mbit/sCBS= 12,176 BEIR = 30 Mbit/sEBS = 12,176 B

MEF

23

serv

ice ty

pe

Colo

r ide

ntifi

catio

n

Color l

abel

SLA p

aram

eter

s

4


The test setup and parameters defined for this testcase were complex, however, we expect that thislevel of complexity will become the norm whenvirtual services from various customers will beexpected to share the same interface. The specificservice configuration is depicted in the table above.The test service frames were generated with differentPriority Code Point (PCP) values for each servicetype individually. One of the interesting aspects ofthe methodology was that the test frames weregenerated either by the service activation device, orby the access device under the test. The bandwidthprofiles for each service were applied at the UNI ofthe EVPL service. For each service type, the SLA parameters – orService Acceptance Criteria (SAC) as Y.1564 calls asimilar construct – were coordinated with the testcase participants. SAC parameters including Infor-mation Rate (IR), Frame Loss Ratio (FLR), FrameTransfer Delay (FTD), Frame Delay variation (FDV)and Availability (AVAIL) are a part of Y.1564 serviceactivation test. These are the parameters againstwhich the test is being performed.We performed Y.1564 service configuration testforeach service individually. If the test passed thisstep, we let the performance test run for 15 minutesfor both services. In the final step we included theimpairment generator in the test setup and intro-duced 20 ms delay on the service frame. We ran theperformance test for one more time expecting anegative service performance test results.The following devices participated the test: AlbisACCEED 1416, Ixia IxNetwork, and OmnitronGM4. In the first scenario, Ixia IxNetwork participated asthe device external to the network performing theservice activation test. The Omnitron GM4 served asthe access device at the customer site. It policed thetraffic and applied bandwidth profiles on the pre-marked test traffic. The Albis ACCEED 1404forwarded the traffic to another Ixia IxNetwork port.In this scenario both services, color aware and colorblind, were tested successfully. Since the measure-ments were done externally to the service (using atester) we were also able to measure CommittedInformation Rate (CIR), Excess Information Rate (EIR),Committed Burst Size (CBS) and Excess Burst Size(EBS) as per Y.1564.In the second scenario, we performed the serviceactivation test and the performance test from AlbisACCEED 1416. In this scenario, ACCEED 1416generated the test traffic, and policed the test trafficon the UNI-C (on a port toward the service providerdomain). Omnitron GM4 looped back the trafficreceived from ACCEED 1416 by swapping theMAC addresses. In this scenario we tested theservice activation test for the Information Rates (IR)and the color blind services.The last scenario set the Omnitron GM4 accessdevice in the role of the service activation andservice performance tester. Albis ACCEED 1416was setup as the other end of the service waslooping back the traffic. One difference between theservice activation test implementation on theOmnitron device was the location in which the

policer was applied. The traffic received from Albiswas policed by Omnitron GM4 on the Ingress port(on a port toward customer domain). The policerswere set to drop yellow traffic that did not conformto the SLA. The EBS and CBS were set to 12,000bytes (as opposed to 12,176 bytes) bytes sincethese parameters’ granularity in the implementationis 1,000 bytes. We ran the service activation andservice performance test successfully. The serviceactivation test measured all but Frame Loss RatioSAC parameters correctly. The Frame Loss Ratio wascalculated based on the total amount of lost framesas opposed to our expectations which were only ondropped green-marked frames. In this scenario, wetested the Information Rates (IR) for color awareservices. We did not test burst sizes nor did weverify the behavior of the solution when impairmentwas applied.

We were impressed to see three new implement-ations of Y.1564 in the testing this year. Even thoughthe standard is primarily written for specialized testinstruments the ITU-T made specific provisions forimplementations on access devices. From a serviceprovider point of view implementations on accessdevices are likely to be more economical: they donot require additional devices to be sent to thecustomer site nor do they require an engineer tooperate them. The implementations we have seen inthe interoperability event will conceivably beoperated from a network operations center as partof a service activation procedure. When such testsare available remotely, the cost of service roll-outcould significantly be reduced – a goal that everyservice provider would appreciate.

EVPL1– color aware

EVPL2– color blind

Stream direction

Figure 1: Service Activation Tests

Service activation device

IxiaIxNetwork (Rx)

IxiaIxNetwork (Tx)

AlbisACCEED 1404

OmnitronGM4

IxiaImpairNet

AlbisACCEED 1416

OmnitronGM4

IxiaImpairNet

Customer

Carrier Ethernetnetwork

domain

AlbisACCEED 1416

OmnitronGM4

5

Hierarchical Service OAM

Hierarchical Service OAMIt is entirely conceivable for Carrier Ethernetnetworks to offer native Ethernet service end-to-end.Given the recent approval of the Metro EthernetForum’s ENNI Abstract Test Suite (MEF 37) the ideaof native end-to-end services could even be tested forcompliancy. This will mean that service providerswill need to construct some hierarchies in theirOperations Administration and Maintenance (OAM)where information and objects are separated intodifferent maintenance levels. This will allow serviceproviders to manage each domain independentlyand to provide both the customers and otheroperators visibility into the health of their ownhierarchy.

MEF 30 specifies the functional requirements forFault Management in hierarchical domains. In ourinteroperability event we focused on Service OAMfunctionality between different vendor MaintenanceEntity Groups (MEGs) at multiple maintenance

levels. The test was designed to distinguish between threetypes of OAM messages defined in MEF 30:Ethernet Alarm Indication Signal (ETH-AIS), Ethernetlocked signal (ETH-LCK) and Ethernet Test Signal(ETH-Test). ETH-AIS is used to suppress alarms and tonotify the failure of the service or transport path toremote Maintenance Entity Points (MEPs). ETH-LCKfunction is defined as a communicative mean. MEPsreceiving ETH-LCK will differentiate between anadministratively locked MEP and a defect condition.Peer MEPs upon receiving of ETH-LCK from a serverMEP expecting interruption of data traffic. ETH-Testfunction is defined as an operation that runs one-way on-demand in-service or out-service and is usedfor diagnostics tests. This includes verifyingbandwidth throughput, frame loss, bit errors, etc.On the surface, the test scenario was straightforward from a testing perspective: build an Ethernetservice in a multi-vendor environment that crossestwo operator domains; remove a physical link in oneof the operator network; verify that the MEPsconfigured at operator domain (level 2) propagatethe ETH-AIS signal to service provider domain (level4), and ultimately to subscriber domain (level 6). To test the ETH-LCK signal we used the sametopology to administratively lock a MEP at a serviceprovider domain (level 4), and verify that the ETH-LCK signal is sent periodically to MEPs configured atsubscriber domain (level 6).The last message type, ETH-Test, was verified bygenerating ETH-Test frames at one of the MEPsconfigured at EVC level (level 4) – with specifiedrate, frame size and transmission patterns – andchecking to see if the remote MEP received the testframes and performs the intended measurement.As we performed the test, we created a single-tag(IEEE 802.1q) service at Customer UNI. The servicewas transported over the service provider networkbased on IEEE 802.1ad. A second tag wastherefore added on top of the service tag at ServiceProvider’s UNI. The outer tag was translated to theoperator’s network tagging scheme at ENNI. DownMEPs were configured at subscriber domain (MEFdefined default MEG level to be 6). The devicessitting on the edge of the network configured two upMEPs: one at the service provider network (level 4),and one at the operator network (level 2). ContinuityCheck messages (CCMs) were exchanged betweeneach pair of MEPs at a specific level. All mainte-nance associations were up and running.As we configured the devices based on the test setupdescribed above, we tested ETH-AIS and ETH-LCKsuccessfully in scenario 1 in Figure 2. In the secondscenario shown in the figure, scenario 2, we testedETH-AIS, ETH-LCK and ETH-Test with success. Inscenario 3, only ETH-AIS was tested. As the link was removed in the operator network,devices next to the failure propagated AIS signalaway from the failure. We observed that AIS signalwas generated by MEPs configured at level 2, andreceived by MEPs configured at level 6.As we tested ETH-LCK signal, we observed that uponreceiving ETH-LCK signal on MEPs at level 6, thetraffic was still being forwarded in one scenario,

Subscriber network

Service Provider network

Operator network

Site 1-Site 2 E-Line

Aggregation deviceEmulator

Up-MEP

Down-MEPMaintenance Association

Figure 2: Hierarchical Service OAM

IxiaIxNetwork

Ixia OmnitronGM4

AlbisACCEED

1416

AlbisACCEED

1416

ETH-AIS

ETH-LCK

ETH-Test

IxiaIxNetwork

IxiaIxNetwork

Ixia OmnitronGM4

AlbisACCEED

1416

IxiaIxNetwork

AlbisACCEED

1416

OmnitronGM4

AlbisACCEED

1416

AlbisACCEED

1416

Aviat EclipsePacket Node

IxiaIxNetwork

Subscriber ME Level

EVC ME Level

Operator ME Level

Scenario 1

Scenario 2

Scenario 3

6


whereas in a second scenario, service frames wereautomatically blocked. Our expectation was that theEthernet locked signal will interrupt data trafficforwarding towards the MEP.As we conducted one-way, on demand, in-serviceETH-Test in scenario 2, we observed that ETH-Testframes generated by MEP configured at level 4 werereceived by the remote peer MEP successfully. Weobserved that the remote MEP represented ETH-Testcount frames with no interruption of data traffic.Y.1731 explains that the tester should generate testsignal with specified throughput, frame size andtransmission pattern, and the remote MEP shouldperform the intended measurement. As the standarddoes not clearly define the mechanism of test signal,the vendors supporting ETH-Test signal representedonly the ETH-Test count frames.During the test, we noticed that the configuration ofH-OAM was quite complex. We observed that MEPsconfigured at ENNI and UNI are capable offorwarding a single tagged or double tagged ofOAM traffic. In order to have an end-to-end faultmanagement module, it is required to know thecapabilities of intermediate ENNIs capabilities.

Performance MonitoringPerformance monitoring tool is always interesting forservice providers to monitor the performance ofEthernet Virtual Connection and to verify the ServiceLevel Agreement (SLA). ITU-T Y.1731 provides thespecification of such tool. The newer version of thestandard is documented as G.8013/Y.1731 (2011)which we decided to focus in this event. We distinguished between four measurement typesfor the test: two-way average frame delay and delayvariation measurement, single-ended frame loss perEVC, and frame loss per EVC per CoS ID.As a baseline reference test, we first validatedperformance monitoring implementations andY.1731 protocol exchange per EVC without intro-ducing any impairment. Once this test procedurewas completed as a baseline, we added an artificialconstant delay, delay variations, or packet loss usingimpairment tools. We expected that the deltabetween the impaired configuration and thereference test to be equivalent to the impairment toolsettings.In order to test average frame delay measurement,we added unidirectional constant delay of20 milliseconds (ms) to all Ethernet DelayMeasurement Message (DMM) packets, andexpected that the average frame delay value wouldbe increased by 20 ms. For average frame delayvariation, we introduced 15 ms packet delay toevery second DMM packet, and 25 ms delay to theremaining DMM packets. We expected the averageframe delay variation would increase by 10 ms. For loss measurement per EVC, we sent bidirectionalEthernet traffic over the network service and intro-duced 10% frame loss in one direction using theimpairment tool. We verified whether the far-endand the near-end frame loss displayed on the deviceunder test showed the same loss values.

As we performed per EVC per CoS ID frame lossmeasurement, we added a bidirectional constantframe loss of zero, and 10% per CoS ID 5 and CoSID 3 respectively. For CoS ID 0, we added aconstant frame loss of 5% in one direction, and

Emulated PSN

AlbisACCEED 2202

SpirentTestCenter

IxiaIxNetwork

EricssonSPO1460

Impairment toolAggregation

Emulatordevice

Figure 3: Performance Monitoring

OmnitronGM4

HFRCET-10448

HFRCET-10448

Y.1731 avg frame delay

Y.1731 avg frame delay variation

Y.1731 frame loss per EVC

Y.1731 frame loss per EVC per CoS ID

Ericsson MINI-LINK SP 210

EricssonSPO1410

OmnitronGM4

AlbisACCEED 2202

OmnitronGM4

AlbisACCEED 2202

OmnitronGM4

AlbisACCEED 1104

HFRCET-10448

HFRCET-10448



OmnitronGM4


Ericsson MINI-Link PT2010

IxiaImpairNet

SpirentParagon-X

SpirentParagon-X

IxiaAnue Hawaii

IxiaImpairNet

IxiaImpairNet

IxiaAnue Hawaii

IxiaImpairNet

IxiaImpairNet

IxiaImpairNet

IxiaImpairNet

SPO 1410

7

Microwave MPLS-TP QoS Support

frame loss of 15% in the opposite direction. Weexpected the devices to observe that the far-end andnear-end frame loss stayed unchanged for CoS ID 5,increased by 10% for CoS ID 3, and increased by5% and 15% – depends on the direction ofimpairment- for CoS ID 0.All the pairs represented in Figure 3 participatedand passed the frame delay and frame delayvariation measurements successfully. During testing the frame delay variation part, weobserved two issues. One issue was that theimpairment tool could not easily apply a delayprofile of 15 ms and 25 ms to alternate packets. Theimpairment device could introduce a delay in therange of 15 ms and 25 ms. Due to this, it wasimpossible to calculate the exact expected value forthe average frame delay variation. We insteadobserved a value in the range between 3.3 ms to 5ms which was expected. We also found a bufferoverflow bug for one implementation which wasfixed in less than a day and re-tested successfully stillduring the event.The following combinations were successfully testedfor single-ended frame loss measurement per EVC:ACCEED 1104, Omnitron GM4; EricssonSPO1410, Omnitron GM4; Ericsson MINI-LINK SP210, Ixia IxNetwork.ACCEED 1104 and Omnitron GM4 were success-fully tested for frame loss measurement per EVC andper 3 CoS ID at the same time. For this pair, weobserved that Loss Measurement Messages (LMM)were exchanged within a specific MEP pair fordifferent CoS IDs. A derivative of the test was imple-mented and tested for Ericsson SPO1410 andOmnitron GM4. In this implementation, LMMmessages were exchanged for different Class ofservices, but for different MEP pairs on different MDlevels.During the test, we observed MEG ID interopera-bility issue. ITU-T Carrier Code (ICC) defines no MDname for the MEG ID. MEF 30 follows ITU-T Y.1731standard as an OAM tool, but the MEG ID specifiedin MEF 30 follows the 802.1ag string format. Weobserved that most vendors support both formats forMEG ID, but they needed to agree on the usedformat before setting up the test.In all test scenarios, we used the Ixia Anue Hawaii,Ixia IxNetwork, Spirent Paragon-X to inject therequired frame loss and delay onto the target OAMpacket streams.

CARRIER ETHERNET TRANSPORT

This event’s transport area was dominated byEthernet Ring Protection Switching (ERPS) as well asmicrowave transport solutions. This is by no meanan indication that all other transport solutions havebeen tested and are showing interoperability. It israther a result of the focus we gave the other testareas in this event. We see developments in themicrowave solutions, now able to parse MPLSheaders and prioritize traffic based on EXP bits, aswell as new ERPS implementations. The next sectionsdescribe these tests and their results.

Microwave MPLS-TP QoS SupportMicrowave links are a commonly-used substitute forlong-haul fiber in the field, especially now thatAdaptive Modulation can select the highest possiblemodulation scheme at a given point in time basedon atmospheric conditions. Since changing con-ditions can decrease the overall throughput of thelink, it is important to have a solution to ensure thatimportant traffic is not dropped due when the aircapacity is reduced. When the air-interface capacityis reduced it is paramount on the microwave solutionto offer traffic prioritization capabilities. In this testwe expected the microwave solutions to be aware ofthe MPLS-TP EXP bits, identifying packets marked ashigh-priority and prioritizing them.MPLS-TP sessions were established between EricssonMINI-LINK SP310 and either Ixia IxNetwork orSpirent TestCenter. Two EXP-marked classes weredefined: one for high-priority traffic (Traffic Class 6),and one for best effort (Traffic Class 0). Test trafficwas supplied by either Ixia IxNetwork or SpirentTestCenter.

Figure 4: MPLS-TP QoS over Microwave

MicrowaveNode

MPLS-TP LSR

MPLS-TP network

MPLS-TP LSREmulator

IxiaIxNetwork

Ericsson MINI-LINK PT2010

Ericsson MINI-LINK SP310


SpirentTestCenter



NEC iPASO-LINK 400

SpirentTestCenter


SIAEALCplus2e

IxiaIxNetwork

RF Attenuator

8


Topology

9

Topology

TOPOLOGY

Physical Network Topology

Analyzer/Traffic Generator

Device Types

Access device

Reference Clock

Multi-Vendor Carrier Ethernet Interoperability Event 2012

Impairment tool

Microwave radiosystem

Aggregation device

Emulator

12:50:00 IEEE 1588v2 Grandmaster

iPASOLINK 400

SymmetricomSSU 2000e

PackeTime PTP

LINK 400 IDU

SpirentParagon-X

IxiaIxNetworkOmnitron GM4

SpirentTestCenter

SIAEALCplus2e

SIAEALFOplus80

IxiaIxNetworkEricsson MINI-LINK

Omnitron GM4

EricssonMINI-LINK SP310

12:50:00Symmetricom

TimeProvider 5000

Ericsson MINI-LINK TN

SpirentParagon-X

NEC

IxiaIxNetwork

OmnitronGM4

AlbisACCEED 2202

12:50:00Symmetricom

TimeProvider 5000

AlbisACCEED 1416

PT2010Aviat EclipsePacket Node

EricssonSPO1410

EricssonSPO1410

IxiaImpairNet

HFRCET-10216

IxiaAnue 3500

IxiaIxNetwork

IxiaImpairNet

SpirentTestCenter

iPASOLINK 400NEC

NEC iPASO-

Aviat EclipsePacket Node Network Areas

Connection Types

Ethernet Aggregation network

MPLS-TP network

Clock link

Gigabit Ethernet link

Access network

ERPS Rings

Bonded SHDSL link

Omnitron GM4

HFRCET-10448

EricssonSPO1460

OmnitronGM4



NEC iPASOLINK400 IDU

AlbisACCEED 1416

SpirentParagon-X

AlbisACCEED 1104

IxiaIxNetwork

10


Traffic was transmitted through the topology at 80%of the microwave links throughput at its maximummodulation. All test frames were 1500 bytes, andthe traffic was divided up as follows: high-prioritywas transmitted at a rate equal to or slightly less thanthe throughput of the microwave link at its minimummodulation, and the rest was marked as best effort.After we ran the 80% traffic at maximum modulationand verified that there was no frame loss, an RFattenuator was used to decrease the modulation,simulating inclement weather or other types of inter-ference. We verified in all test scenarios that 0% ofthe high-priority traffic was dropped, and that 95%or more of the best-effort traffic was dropped,allowing for headroom in the predicted throughputof the minimum modulation. We also measured themaximum latency of the high-priority traffic in bothmodulations and observed a minimum of 122 micro-seconds and a maximum of 773 microsecondsamong the vendor spread.The microwave devices tested in this scenario were:Aviat Eclipse Packet Node, Ericsson MINI-LINKPT2010, NEC iPASOLINK 400, and SIAEALCplus2e.

ERPSv2 and VPLS InterworkingRather than having a single point of failure in theattachment of an aggregation Ethernet ring to anMPLS or MPLS-TP core, it can be useful to dual-homean Ethernet ring at the attachment point, enablingend-to-end resiliency in the event of a single inter-working device failure.This test simulates that scenario by breaking a ringlink connected to one of the interworking devices.In both test scenarios that were run, an MPLS-TP VPLSwas set up between three Ericsson devices:SPO1410, SPO1460, and MINI-LINK SP310. Twodifferent ERPS sub-rings were connected to the VPLS,distinguished by the rate of CFM messages. The firstring comprised of two Aviat Eclipse Packet Nodesand an Omnitron GM4, configured with CCMs at arate of 100 ms. The second sub-ring was made up ofan HFR CET-10448, two Omnitron GM4s, and anSIAE ALCplus2e. CCMs on this second ring weretransmitted at a rate of 3.33 ms. In the first ring, oneAviat Eclipse Packet Node was the RPL owner, andthe second was the RPL neighbor. In the second ring,the Omnitron GM4 was RPL owner and the HFR CET-10448 served as the RPL neighbor.Bidirectional traffic was supplied between the RPLowner and the end (non-interconnecting) VPLS nodeby an Ixia IxNetwork or Spirent TestCenter.First, the primary path was verified to be fullyfunctional by transmitting traffic through the ring tothe far side of the VPLS by either an Ixia IxNetworkor Spirent TestCenter, ensuring that there was noframe loss. After that, a link in the primary trafficpath was physically disconnected, causing the ringto switch to the protection path. Frame loss wasagain measured to ensure that there was no lossduring the switchover, and while traffic was runningon the protection path. Failover time was measuredat 36 milliseconds in each direction on the first (100ms CCMs) ring, and 25 milliseconds in one direction

and 6 milliseconds in the other direction on thesecond (3.33 ms CCMs) ring. The switch over timein 100 ms CCM ring was less than 100 ms since theloss of signal (link failure) was used to trigger thefault condition instead of using impairment device onCCMs. The link was re-connected, and after the Wait toRestore (WTR) timer expired, traffic loss andreversion time was again measured when the ringswitched back to the primary path. Restoration timewas measured at 47 milliseconds in one directionand 46 milliseconds in the other on the 100 ms ring,and 10 milliseconds and 1 millisecond on the 3.33ms ring. Afterwards, the backup path link was disconnectedto ensure that no path switching occurred, as anadditional confirmation that the ring indeed revertedto the primary path.

MPLS-TP Fault ManagementTwo pairs of vendors signed up for this test.However, due to interoperability issues betweenparticipating vendors, stemming from mismatchingimplementations of the ACH TLV in the GenericAssociated Channel Header, there were nosuccessful results created.

OmnitronGM4

OmnitronGM4

EricssonSPO1460

SIAEALCplus2e

EricssonSPO1410

EricssonSPO1460

Primary Path

Protection Path

DeviceUnder Test

Link Break

ERPS Network MPLS-TP VPLS

MicrowaveDUT

RPL Interface

Figure 5: ERPSv2 and VPLS Interworking

OmnitronGM4

EricssonSPO1410




HFRCET-10448

11

MPLS-TP Pseudowire Redundancy

MPLS-TP Pseudowire RedundancyDue to issues encountered with interoperabilityscenarios in the MPLS-TP Fault Management tests,Ericsson ran a demo using a topology made entirelyof their devices in the absence of compatible interoppartners with enough available devices for testing.The Ericsson MINI-LINK SP310 was set up as a UNIdevice. A primary MPLS-TP PW was configured torun through the SPO1410, and a backup onethrough the SPO1460, to another SPO1410.Bidirectional test traffic was supplied by IxiaIxNetwork. After ensuring that it was flowing downthe primary path, The link between Ericsson MINI-LINK SP310 and SPO1460 was disconnected andwe measured that the service reconverged.

CLOCK SYNCHRONIZATION

What can be said about clock synchronizationtesting? The topic enjoys constant interest from newvendors as well as a never ending extensions fromthe standard bodies. This year one of our suggestedtest topic was for example clock synchronization forpower systems applications, however, no implemen-tations were ready to demonstrate support. Still, wewere challenged by extending our testing programwith new precision time protocol (PTP - IEEE 1588v2)measurement metrics, impairment profiles as well asnew test cases for best master selection and hybrid-mode (PTP and synchronous Ethernet). We alsoperformed synchronous Ethernet tests focusing onmicrowave transport. We used GPS as our clocksource in our PTP and synchronous Ethernet tests.Another challenge we encountered in this area wassupport for various configuration specified in theIEEE 1588v2 standard. These included messagerates, transport mechanism (unicast or multicast) and1-step or 2-step clock mode. The ITU-T G.8265.1defines the telecom profile for frequency synchroni-zation with PTP, which we intended to use in all ofour tests. However, since not all vendors supportedthis profile (and the mechanisms for phase synchroni-zation planned in G.8275.1 are yet to be ratified),we had to divert from it and include multicast-mode,resulting in a total of four PTP profiles.The latest revision of the ITU-T G.8260 recommen-dation approved in February this year, includes adefinition of “Floor Packet Population” metrics whichaddress the measurement of PDV incurred on PTPpackets throughout the network. These metricsevaluate how many synchronization packets reachthe end point of a synchronization path close to(read: 150 s) the observed floor delay with anobservation duration of 200 seconds. Although PTPis agnostic to the constant delay throughout thesynchronization path, it is sensitive to variable delaycaused by various traffic patterns seen in productionnetworks. The floor packet population metricsprovides service providers with a mean to evaluatethe readiness of an entire network path to supportPTP. It enables services providers to measure theirnetwork delay and delay variation as a mean ofknowing if the network could transport clock signalas opposed to measuring the clock output of thenetwork which relies heavily on the ordinary clock

output. Floor packet population is considered aneutral metric.We included floor packet population measurementsin our transparent clock, boundary clock and hybridmode (PTP with synchronous Ethernet) test casesusing the FPP (floor packet percentage) thresholddescribed in G.8261.1 clause 8, which specifiesthat at the percentage packets meeting the targetdelay should exceed 1%.

IEEE 1588v2 Transparent ClocksPTP enables frequency and phase synchronizationbetween nodes over layer 2 or layer 3 transport.However, since each intermediate node introducesvariable latency into the synchronization path, thetraffic patterns may have adverse effects onaccuracy and the slave clocks may require a longerduration to acquire a lock. One possibility toalleviate this condition is to deploy devicessupporting the transparent clock function throughoutthe synchronization path. Each device supportingthis function updates the correction field in PTPmessages with an estimation of the latency itintroduced. This in turn allows the slave clock tocompensate for the latency and increase theprecision of the synchronization.In the first part of the test, we let the slave clockacquire the lock without any background traffic.After we observed successful results, we reset theslave clock and verified that it was in free runningmode. We proceeded to introduce traffic betweenthe transparent clock and the slave clock andallowed the slave clock to synchronize withbackground traffic. We used a traffic pattern basedon the G.8261 VI2.2, with bursts lasting 100 msand interburst gaps between 16 and 17 ms. After the slave reported a synchronization lock, wemeasured frequency and phase against the G.823SEC mask, as well as the floor delay packetpopulation (discussed in ITU-T G.8260 I.5) usingmore than 1% FPP limit defined in G.8261.1.An additional measurement was possible thanks tothe ability of Ixia Anue 3500 and Spirent Paragon-Xto compare the correction field values inserted bythe transparent clock against the actual latencyintroduced. The testers either directly plotted thedifference or subtracted the correction field from themeasurements. One implementation inserted aconstant value regardless of the latency. Otherimplementations accounted for the traffic, althoughwe observed variations in the microsecond range.The irony of this measurement was that bothapproach are possibly correct. The transparentclock’s job is to insert the delay through the clock’sown implementation into the correction field. Thetask of the ordinary clock is then to subtract thisvalue from the delay. Since both interpretations thatwe measured seemed to be correct, we did notactually use these measurements in the evaluation ofthe interoperability.We also observed one implementation that did notrecalculate the UDP checksum after updating thecorrection field. The vendor was able to provide anupdated software image during the testing and we

12


were able to test this fresh implementation success-fully.As in most of our clock tests Symmetricom was usedto provide a clock source. In this case theSymmetricom TimeProvider 5000 was used as thegrandmaster. Ericsson MINI-LINK SP210, HFR CET-10216 and Omnitron GM4 showed correct imple-mentation of transparent clocks. The Ericsson MINI-LINK SP310 and NEC iPASOLINK 400 acted asslave clocks.All maximum time interval error (MTIE) measure-ments passed the G.823 SEC mask. All measure-ments passed the ±1.5 s phase deviation require-ments. All floor packet population measurementspassed the 1% FPP threshold. We observed no lossfor the test traffic.

Currently, the Internet Engineering Task Force (IETF)working group TICTOC is discussing methods forMPLS nodes to deal with PTP packets. This iscertainly going to be an area of further investigationin future events.

IEEE 1588v2 Boundary ClocksBoundary clocks provide means to distributesynchronization within a network in a scalablemanner with the additional value of buffering thegrandmaster from the slave clocks.Two boundary clock implementations were includedin this year’s event – an increase from last year’s

single boundary clock test. As in last year’s event,we included an impairment tool between the grand-master and the boundary clock and another, whichdid not exist in last year’s test setup, between theboundary clock and the slave clock. The test plancreated by EANTC specified the use of G.8261 testcase 13 as the impairment profile. The participatingvendors, however, were interested in using the lesschallenging G.8261 test case 12. The impairmentdevice in the test was simultaneously creating theimpairment profile and measuring the clock output.This allowed us to verify in the first test runs that bothdevices locked within 1 hour, although the measure-ments showed that the clock output oscillated, failingthe G.823 SEC mask, and stabilized only afterapproximately 7 hours. For a second test topologywe found an incompatibility between the boundaryclock, which only supported 2-step mode and othercomponents which supported 1-step mode.At the end, we did not obtain any successful resultsfor this test.

Ethernet Synchronization Messaging Channel (ESMC)ESMC provides traceability of the clock source forsynchronous Ethernet and allows the receiver to lockonto the best available reference source. ESMC usesITU-T G.781 clock source quality levels (QLs). In thistest, we used 4 different clock QL levels, startingfrom the highest quality level QL-PRC (primaryreference clock) through QL-SSU-A (synchronizationsupply unit, ITU-T G.812 type I or type V slaveclock), QL-SEC (synchronous equipment clock) andfinally QL-DNU (do not use).In this test we concentrated on microwave devicesthat are designed to carry synchronous Ethernettransparently. This requires the two microwave unitsto maintain the semantics of a single device, recov-ering the clock from one port, conveying thefrequency and traceability over the microwave linkand utilizing it at the outputs of the peer microwaveunit.Our test topology was composed from threesuccessive synchronous Ethernet nodes with thereference clock source attached to the PrimaryReference Clock (PRC) as well as the clock slave(SSU) as depicted in the figure. We started the testwith no reference clocks connected, which promptedthe devices to send either QL-SEC or QL-DNU,according to the internal oscillator capability oradministrative configuration of each device.When a port is used as a clock recovery source, itshould signal QL-DNU on that port unless the devicehas a better quality source available to it than thereceived quality level signal. After we connected theprimary reference source, the devices propagatedQL-PRC downstream and QL-DNU upstream. Wethen connected the secondary reference source andobserved no change as expected.We proceeded with disconnecting the primaryreference clock and observed that the secondaryreference clock was propagated by signalling QL-SSU-A upstream and QL-DNU downstream viaESMC, which triggered a switching event. We

Figure 6: PTP Transparent Clock

12:50:00PTP Grandmaster

Clock link

HFRCET-10216

SymmetricomTimeProvider 5000

PTP node

Frequency+Phase+Packet Analyzer

Monitoring link

1 Gbit Ethernet link

TransparentClock

SlaveClock


IxiaAnue 3500

SpirentParagon-X

12:50:00

OmnitronGM4



NECiPASOLINK 400

Data EVC1PPS

OmnitronGM4

NECiPASOLINK 400 13

Synchronous Ethernet over Link Aggregation

connected the primary reference clock once moreand observed that the nodes reverted to the primaryreference source by signalling QL-PRC downstreamand QL-DNU upstream, again triggering a switchingevent.

In both switching events, we verified our measure-ments against the G.8262 EEC Option 1 short termtransient mask.Albis ACCEED 2202, Aviat EclipsePacket Node, Ericsson SPO1460, Ericsson MINI-LINK TN, NEC iPASOLINK 400 and SIAEALCplus2e passed the G.8262 EEC Option 1 shortterm transient mask.

Synchronous Ethernet over Link AggregationBoth at network edges and at aggregation layersLink Aggregation is often used to increase linkcapacity at smaller increments than are availableper physical interfaces capacity as well as a methodfor increase resiliency between nodes. Ifsynchronous Ethernet is also used over the samepath, its usage will impose new challenges in theevent of a link fault – when the frequency offsetbetween each link member is too wide, the clocksignal may be impaired. Additionally, there is thepossibility of a timing loop, when ESMC SSMmessages on a LAG bundle do not correspond.In order to verify that the implementations under testare able to deal with such conditions we establisheda 2-link LAG between the master and slave nodes.We allowed the devices’ clock to settle and startedmeasurements against the G.8262 EEC Option 1mask to verify that the frequency is indeed stable.We then proceeded to emulate a failure on theprimary link, followed by its restoration, after whichwe performed the same procedure for the other link.We waited at least one minute to ensure that Wait toRestore (WTR) timers expired. The failure wasemulated using an impairment tool when Link Aggre-gation Control Protocol (LACP) was used or aphysical cable disconnection when static LAG wasavailable. We continued our measurements totallingat least 60 minutes and evaluated the results againstthe G.8262 EEC Option 1 mask.

In the final step we disconnected the referencesource and verified that the slave node – nowreceiving QL-SEC instead of QL-PRC from the masternode – sent QL-DNU on both LAG links, thus

Figure 7: Ethernet Synchronization

SyncE Node

Albis

ReferenceClock


ACCEED 2202Ericsson

MINI-LINK TN

Microwave systemsupporting SyncE

SpirentTestCenter

SymmetricomTimeProvider

IxiaAnue 3500

SIAEALCplus2e

EricssonSPO1460

NECiPASOLINK 400


5000


5000

Clock link

Frequency+PacketEmulatorAnalyzer

SpirentTestCenter

NECiPASOLINK 400

NECiPASOLINK 400

SIAEALCplus2e

EricssonMINI-LINK TN

IxiaAnue 3500

SpirentParagon-X

Messaging Channel

PRC SEC SSU


5000


5000

Figure 8: SyncE over LAG

SpirentParagon-X

LAG


AlbisACCEED 2202

AlbisACCEED 2202

SyncE NodeReferenceClock


Microwave systemsupporting SyncE

Clock link

Master Slave

IxiaAnue 3500


5000

Impairment Tool andFrequency/Packet Analyzer


SpirentParagon-X

14


avoiding a timing loop.Albis ACCEED 2202, Ericsson MINI-LINK SP210and Aviat Networks Eclipse Packet Node passed theG.8262 EEC Option 1 mask. We did not observetiming loops in any of the test runs.

Precision Time Protocol and Synchronous Ethernet – Hybrid ModePTP provides both frequency and phase synchroni-zation, whilst synchronous Ethernet provides onlyfrequency synchronization. Frequency recovery withsynchronous Ethernet is claimed to be more robustand stable, since it is independent of the traffic thattraverses the devices and enables the recovery ofclocking directly from the physical layer, whichenables the acquisition of the frequency lock within ashorter time span.When creating the test plan, together with the inter-ested vendors, we received the request to show amode which the vendors referred to as hybrid –frequency was to be received using synchronousEthernet while Time of Day (ToD) was to berecovered from the Precision Time Protocolmessages. Since the challenge was interesting andthe method is potentially of interest to serviceproviders that already have a synchronous Ethernetnetworks but are now required to support phase, weaccepted the test.Our setup included a grandmaster providing PTPand SyncE over separate links, a transparent clockand an ordinary clock. We used impairment tools tointroduce packet delay variation (PDV) and wander.Frequency and phase analyzers were connected tothe slave clock’s outputs. Our goal was to verify thatwhen packet delay variations (PDV) increases, theincrease will only affect phase synchronization,while impairing frequency will affect both frequencyand phase synchronization. Since potentially thefrequency could also be gained from the PTPmessages, we also made sure to check the influenceof wander introduction on the recovered frequencysignal.First we verified the correct operation without anyform of impairment, staying within the ±1.5 sphase limit and passing the G.8262 EEC Option 1mask for frequency. We then proceeded to impairPTP by introducing PDV and verifying that thefrequency output of the slave clock was not affectedand passed the G.8262 EEC Option 1 mask. Oncethe mask measurement was declared as pass, westopped the PDV impairment and introduced wanderwith using a sinusoidal waveform. We observed thatthe slave clock’s frequency output followed thewander we introduced as expected proving that thefrequency was really recovered from thesynchronous Ethernet signal. We also observedperiodic oscillations in the 1PPS measurement, whichconfirmed that the frequency recovered fromsynchronous Ethernet is utilized to provide phaseoutput. This was not for the faint hearted!The good news was that the results of the test werepositive. The complexity introduced to the test was

really a product of our scepticism – after all weneeded proof that the implementations were reallycombining both protocols to provide accurate phaseand frequency. The following figure depicts thedevices in each test run.Symmetricom TimeProvider 5000 provided the PTPgrandmaster functionality, Ericsson MINI-LINKSP310 and HFR CET-10216 acted as transparentclocks and slaves (in two test runs), while Ixia Anue3500 and Spirent Paragon-X provided theimpairment and measurements.

Precision Time Protocol and Synchronous Ethernet - Best Master Clock SelectionThe Precision Time Protocol provides a simplemechanism for synchronization slave clocks to selectthe best master clock in their respective synchroni-zation domain. The selection is performed accordingto the information announced by the master or by itsavailability. One of the parameters used in theselection algorithm is the master’s clock class, whichdescribes the reference source. When a master losesits reference source, its clock class attribute willdegrade to reflect that it is in hold over mode.The test comprised two grandmasters, identical inthe configured priority values, a boundary clock andan ordinary clock and an impairment tool. We firstverified that the boundary clock selects the grand-master according to the tie-breaker in the form of thegrandmaster identity. We performed the verificationaccording to the clock class by either disconnectingthe clock reference source or by emulating a clockclass degradation with a tester, which caused theboundary clock to select the secondary grandmaster.

Figure 9: PTP and SyncE – Hybrid Mode

PTP+SyncE1 Gbit Ethernet link

SpirentParagon-X

Clock link

Impairment Tool andPhase/Frequency Analyzer

Node


HFRCET-10216


IxiaAnue 3500


1PPS

HFRCET-10216

SpirentParagon-X

12:50:00

SymmetricomTimeProvider5000

TransparentClock

SlaveClock

15

Acknowledgements

In the next step, we applied impairment on thesecondary grandmaster by dropping all PTPmessages, which prompted the boundary clock torevert back to the primary grandmaster. In each stepwe used the ordinary clock to verify that theboundary clock communicate its change of grand-master.Ixia IxNetwork, Spirent TestCenter and SymmetricomTimeProvider 5000 were PTP grandmasters, whileIxia ImpairNet and Spirent Paragon-X providerimpairment. Ericsson MINI-LINK TN, HFR CET-10216 and NEC iPASOLINK 400 were boundaryclocks. Ericsson MINI-LINK TN, Ixia IxNetwork, NECiPASOLINK 400 and Spirent TestCenter were slaveclocks.

DEMONSTRATION NETWORKAs in every EANTC interoperability event, oncetesting was completed between vendor pairs (orsometimes, more than pairs), we constructed ademonstration network. The amount of the devicesavailable in our lab enabled us to create an imple-mentation of the ITU-T G.8261.1 HypotheticalReference Model (HRM-2c). 6 vendors participatedin this demo: Symmetricom SSU 2000e PackeTimePTP as the packet master clock. Ericsson MINI-LINKPT2010, Ericsson MINI-LINK SP310, EricssonSPO1410, Ericsson SPO1460, HFR CET-10216,NEC iPASOLINK 400, Omnitron GM4 and SIAEALCplus2e formed the network, with SpirentParagon-X providing the measurements before theslave clock. Since the model includes microwavedevices, devices that switch modulation schemesand thus bandwidth capacity according to weatherconditions, additional prioritization to PTP packetscould be supported by some of these microwavesolutions to reduce packet delay variation (PDV)during modulation shifts.In the public showcases (in Barcelona and HongKong), selected test results will be demonstrated tothe public. We hope to see you there!

AcknowledgementsWe would like to thank Stephen Murphy from theUniversity of New Hampshire IOL for his supportduring the testing.Editors. This report has been written and edited byJambi Ganbar, Shima Sajjad, Eldad Zack andStephen Murphy.

Figure 10: PTP Best Master Clock Selection


Impairment tool


PTP node

IxiaImpairNet

PTP Domain A

Emulator

PTP Domain B

NECiPASOLINK 400

HFRCET-10216

IxiaIxNetwork

IxiaIxNetwork

SpirentTestCenter


IxiaImpairNet

IxiaIxNetwork

NECiPASOLINK 400

SpirentParagon-X

SpirentTestCenter


SpirentTestCenter

12:50:00SymmetricomTimeProvider

5000

12:50:00SymmetricomTimeProvider

5000


EANTC AGEuropean Advanced Networking Test Center

Hosted by:IIR Telecoms

Salzufer 1410587 Berlin, GermanyTel: +49 30 3180595-0Fax: +49 30 [email protected]://www.eantc.com

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

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

carrier ethernet world congress 2012 public multi-vendor ... · achieved in optical link failure...

Documents