Upload
nguyendung
View
224
Download
0
Embed Size (px)
Citation preview
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
Carrier Ethernet World Congress 2012 Multi-Vendor Interoperability Test
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
Carrier Ethernet World Congress 2012 Multi-Vendor Interoperability Test
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
Aviat EclipsePacket Node
Aviat EclipsePacket Node
OmnitronGM4
Aviat EclipsePacket Node
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
Aviat EclipsePacket Node
SpirentTestCenter
Ericsson MINI-LINK SP310
Ericsson MINI-LINK SP310
NEC iPASO-LINK 400
SpirentTestCenter
Ericsson MINI-LINK SP310
SIAEALCplus2e
IxiaIxNetwork
RF Attenuator
8
Carrier Ethernet World Congress 2012 Multi-Vendor Interoperability Test
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
EricssonMINI-LINK SP210
EricssonMINI-LINK SP310
NEC iPASOLINK400 IDU
AlbisACCEED 1416
SpirentParagon-X
AlbisACCEED 1104
IxiaIxNetwork
10
Carrier Ethernet World Congress 2012 Multi-Vendor Interoperability Test
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
Aviat EclipsePacket Node
Ericsson MINI-LINK SP310
Ericsson MINI-LINK SP310
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
Carrier Ethernet World Congress 2012 Multi-Vendor Interoperability Test
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
Ericsson MINI-LINK SP310
IxiaAnue 3500
SpirentParagon-X
12:50:00
OmnitronGM4
Ericsson MINI-LINK SP210
Ericsson MINI-LINK SP310
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
1 Gbit Ethernet link
ACCEED 2202Ericsson
MINI-LINK TN
Microwave systemsupporting SyncE
SpirentTestCenter
SymmetricomTimeProvider
IxiaAnue 3500
SIAEALCplus2e
EricssonSPO1460
NECiPASOLINK 400
Aviat EclipsePacket Node
5000
SymmetricomTimeProvider
5000
Clock link
Frequency+PacketEmulatorAnalyzer
SpirentTestCenter
NECiPASOLINK 400
NECiPASOLINK 400
SIAEALCplus2e
EricssonMINI-LINK TN
IxiaAnue 3500
SpirentParagon-X
Messaging Channel
PRC SEC SSU
SymmetricomTimeProvider
5000
SymmetricomTimeProvider
5000
Figure 8: SyncE over LAG
SpirentParagon-X
LAG
Aviat EclipsePacket Node
AlbisACCEED 2202
AlbisACCEED 2202
SyncE NodeReferenceClock
1 Gbit Ethernet link
Microwave systemsupporting SyncE
Clock link
Master Slave
IxiaAnue 3500
SymmetricomTimeProvider
5000
Impairment Tool andFrequency/Packet Analyzer
Ericsson MINI-LINK SP210
SpirentParagon-X
14
Carrier Ethernet World Congress 2012 Multi-Vendor Interoperability Test
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
12:50:00PTP Grandmaster
HFRCET-10216
Ericsson MINI-LINK SP310
IxiaAnue 3500
Ericsson MINI-LINK SP310
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
1 Gbit Ethernet link
Impairment tool
12:50:00PTP Grandmaster
PTP node
IxiaImpairNet
PTP Domain A
Emulator
PTP Domain B
NECiPASOLINK 400
HFRCET-10216
IxiaIxNetwork
IxiaIxNetwork
SpirentTestCenter
EricssonMINI-LINK TN
IxiaImpairNet
IxiaIxNetwork
NECiPASOLINK 400
SpirentParagon-X
SpirentTestCenter
EricssonMINI-LINK TN
SpirentTestCenter
12:50:00SymmetricomTimeProvider
5000
12:50:00SymmetricomTimeProvider
5000
Carrier Ethernet World Congress 2012 Multi-Vendor Interoperability Test
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