EANTC Ericsson EIN Marketing Report

Ericsson Evolved IP Network Solution

Scalability, Performance, and High Availability Test Report

IntroductionEricsson is one of the leading telecommunicationequipment vendors in the world with 40 percent ofthe world’s mobile traffic passing through Ericssonnetworks1. With integrated mobile and fixed solu-tions, the company is in a unique position to offertrue end-to-end networks to its customers. Ericsson’s‘Evolved IP Network’ solution targets convergedand mobile operators, comprising in-house devel-oped multiservice transport products and the Eric-sson IP Operating System.

Ericsson contacted the European AdvancedNetworking Test Center (EANTC) to execute a testcampaign in order to publicly validate Ericsson’s‘Evolved IP Network’ solution. Together Ericssonand EANTC agreed on the following high-level vali-dation points:

• Test the complete IP transport portfolio with singleoperating system

• Demonstrate microwave integration for evolution toall-IP backhaul

• Validate Ericsson’s performance monitoring to thebase station

This report describes the network Ericsson createdfor the test, the test cases themselves and the results.

Tested Solution

Ericsson provided a comprehensive and completenetwork environment for the tests - from multi-stan-dard indoor macro base station (Ericsson RBS6202) to the IP service core running on Ericsson'sSSR 8010 and 8020.

In the access, the Ericsson SP router family was usedto connect the radio base stations, emulated andreal, to the network. The SP 420 and SP 415,equipped with 10GigabitEthernet and GigabitEth-ernet ports, would typically be used in a largermacro cell site where many antennas are posi-tioned. The SP 110 provides a 1 rack unit solutionfor smaller macro cell sites and is also suited forsmall cell backhaul networks.

In addition, three Ericsson microwave transport solu-tions were used in the access network, these werethe MINI-LINK PT 2020 (traditional spectrum from6GHz to 42GHz), MINI-LINK PT 3060 (60GHz,also known as V-band) and MINI-LINK PT 6020(70/80GHz, also known as E-Band).

In the access network, an extensive clock synchroni-zation topology was set, with GrandMaster clockfunctions fulfilled by Microsemi TimeProvider 2700and 5000 (supplied by Ericsson and part of the‘Evolved IP Network’ solution).

1. http://www.ericsson.com/thecompany/company_facts

Figure 1: The Ericsson SSR 8020 Test Setup

Test Highlights

Tested end-to-end scope from base station to internet

Measured less than 5.3 ms service outage time using IP Fast Reroute

Confirmed solution scalability at large operator network scale

Measured phase accuracy within +/- 325.56 ns for full path timing

Verified suitability for mobile and multiservice deployments

EANTC Test Report: Ericsson Evolved IP Network solution – Page 1 of 12

The access network was then connected to theaggregation network, which was built using theEricsson SSR 8010 routers. In the aggregationnetwork we also connected several Ixia IxNetworktester ports to emulate other access networks inorder to mimic a typical large service providernetwork.

The aggregation network was attached to the IPservice core network, where typically both mobilecore, residential and enterprise services co-exist.For the purpose of some of the test cases weconnected the biggest Ericsson router in the test, theSSR 8020, to an internal Ericsson mobile packetcore.

Both the real and simulated mobile traffic in the testnetwork were routed inside IP/MPLS layer 3 virtualprivate network services (L3VPN). In the accessnetwork these services were transported to theaggregation network using two MPLS labels – onewas used to route the service to the aggregationnetwork and the other was used to reach the IPservice core using the transport layer. These threelabel-stacking principles were established by seam-less MPLS methodology (https://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-05).

Alongside the L3VPN services, Ericsson configuredvirtual private wire services (VPWS) in whichemulated residential and business subscriber trafficwas encapsulated. Figure 2 depicts the completetest topology.

Figure 2: Ericsson Evolved IP Network Test Setup

Ericsson

Clock link — Freq.1PPS link

Traffic Generator/MonitorFrequency/PhaseAnalyzer

10 GbE1 GbEMicrowave link

Core Network

Aggregation Network

Access Network Clock link — ToD

RF Attenuator

Ixia XG12

Ixia XG12

Ericsson

Ixia XG12

Radio Access Network Management Network Packet network

RADIUSServer

Ericsson Ericsson

GPS Antenna

SP 110 SP 310

Ericsson

Ericsson SSR8010

IP Probe

EricssonSP 420

PT 3060Ericsson MINI-LINK

EricssonSP 415

Ericsson MINI-LINKPT 2020

Ericsson MINI-LINKPT 6020

Ericsson SSR8010

Ericsson SSR 8010

Microsemi12:50:00

TimeProviderMicrosemi

Ericsson RBS6202

Ixia XG1212:50:00

SP 420 SP 420

8010Ericsson SSREricsson

SP 420Ericsson SSR

8010

Ixia XG12

x8

Ericsson

RouteReflector

SSR 8010

Ericsson SSR8010

TimeProvider2700 5000

EricssonEPC

Ericsson SSR 8020

IxiaAnue3500


Test Equipment

To execute the tests we used Ixia’s XG12 chassisequipped with Xcellon-Flex-AP 16-port10GigabitEthernet and LSM1000XMVDC16 cards.For our clock synchronization tests we used Ixia’sAnue 3500.

We complemented the physical access network thatEricsson provided with our testers. Based on theEricsson design, the access network would havebeen a single geographical location in which typi-cally up to 1,000 base stations reside along sidesome 5,000 residential or business services. Basedupon these guidelines, we emulated traffic sourcedat base stations.

The aggregation network, however, is expected tosupport many more such access areas. For thispurpose we used an Ixia IxNetwork tester toemulate additional 8 access networks, each oper-ating at the same scale as the physical network.This meant that the tester had to emulate basestations as well as residential subscribers. From atester point of view, in the aggregation network, thebiggest task is to emulate the control plane, suchthat the real devices, in this case the Ericsson SSR8010s, would treat the emulated traffic in the sameway that they treat the physical devices.

Test Bed Traffic Configuration

In most of the tests, we used a tester configurationwhich enabled us to emulate 8 access networks atscale. The services, as figure 3 depicts, were allterminated on the IP service core router – the Eric-sson SSR 8020.

In this configuration, the Ericsson SSR 8020 termi-nated 47,584 Virtual Private Wire Services as wellas 8,000 Layer 3 Virtual Private Networks. Themajority of the L3VPN end points were created bythe emulated access ports (em_Access in the figure),however, 64 VPN Routing and Forwarding tablesexisted on the SP devices.

em_RBSem_RBS

em_BR-1

em_BR-4

em_BR-8

Core networkAggregation network

Access network

Radio access networkPacket network

em_RBS

em_RBS

em_RBS

em_RBSem_RBS

em_RBS

em_RBS

em_RBS

2,000 x L3VPN

8,000 x L3VPN

47,584 x VPWS

5938 x VPWS40 x VPWS10 x VPWS

VPWSL3VPNVLAN (VPWS)

VLAN (L3VPN)

em_BR-7em_BR-3em_BR-6

em_BR-2em_BR-5

em_Access7

em_Access8

em_Access5

em_Access6

Ericsson

em_Access3

em_Access4

em_Access2

em_Access1

EricssonSSR 8020

64 x L3VPN

Figure 3: Ericsson Evolved IP Network Emulated Services

SP 415Ericsson SP 420


Intelligent Transport

When looking at today's complex network, we cansee many competing and diverse requirements fromthe different services that run over them. Ericsson'ssolution is aimed at networks that carry both resi-dential and business traffic, in addition to mobileservices. Such a network should be secure, supportall generations of mobile technology, and enabletransport over densely populated urban areas aswell as rural landscapes.

Typically we would also urge the vendor to allow usto test the Network Management System (NMS)solution, but given that Ericsson was in the processof launching1 a new NMS just as we were in themidst of testing, we accepted that NMS testingwould take place at a later date.

Multi-Standard Base Station

We started from the very edge of the network andworked our way to the core. This meant that Eric-sson's multi-standard indoor macro Radio BaseStation (RBS 6202) was the first observation point.Ericsson explained that the Base Station is installedwith several interfaces that allow it to operate simul-taneously using current mobile technologies: UMTS(3G using DUW card) and LTE (4G using DULcard).

Both UMTS and LTE ran natively over IP using thesame IP/MPLS L3VPNs configured in the network toreach the mobile packet core.

EANTC does not typically perform physical layertesting. The test hardware required to perform suchactivities is completely different than the testers wetypically use to emulate services or subscribers. Soin this case, we used several mobile devices, eachverified to operate using different mobile tech-nology (i.e. UMTS and LTE) to connect to theinternet. We first verified that the mobile device wasreally connected to the RBS 6202 in the test bedand not to another base station, by simply discon-necting the RF cables from the Ericsson RBS, onecard at a time, and seeing that the mobile devicewe controlled lost its connectivity and that theconnectivity only returned once we reconnected thecable.

With that we were convinced that the RBS 6202was really providing the mobile connectivity. Wethen browsed EANTC’s web site while alsostreaming videos from a local content provider. Wealso called from the UMTS phone to another phoneto verify that voice was also working. All activitieswere done in parallel, which verified Ericsson'spoint – the RBS 6202 was indeed multi-standard.

Microwave Adaptive Modulation

One of the unique challenges when using micro-wave as a packet transport medium is naturalelements. For those times when rainfall conditionsare exceptionally bad, the link capacity may betemporarily reduced due to an adaptive modulationshift that is compensating for decreased signal tonoise ratio. This changes the modulation scheme onthe microwave air interface to the maximum thatcan support the change in environmental circum-stances. Ericsson explained that their MINI-LINK PTproduct family can support a number of trafficclasses, reacting to link capacity reduction byscheduling higher-priority traffic and discardinglower-priority traffic based on configured quality ofservice settings traffic and prioritizing the rest.

Ericsson selected one of the three microwavedevices for this test – the MINI-LINK PT 2020. Theyconfigured seven different classes for typical traffictypes seen in converged networks. In the highest(most valuable) traffic class was packet clocksynchronization and radio network control. The IPcontrol plane and OAM traffic received the nextlevel of prioritization while mobile voice, as well asgaming and video, were marked as the next priorityclass. These three traffic classes were configured touse a priority scheduler.

Low priority OAM traffic and mobile, non guaran-teed bit rate (GBR) traffic, were being scheduledusing a weighted fair queueing algorithm. Thelowest class of service carried all unclassified dataand was treated as best effort.

Emulating miserable weather conditions requires anRF attenuator that allows us to reduce the capacityof the microwave link. We started with link modula-tion of 512QAM, which at a 56MHz spectrumbandwidth provided 406Mbit/s of throughput, andreduced the modulation in regular steps all the waydown to 4QAM. Using that modulation scheme theavailable air interface capacity was 94Mbit/s.

1. http://www.ericsson.com/news/1761209


The results showed that Ericsson indeed built intelli-gence into the microwave devices that allowed therouter/switch component of the MINILINK PT 2020to prioritize traffic based on classes of service andto maintain healthy operations for the most valuabletraffic, such as packet-based clock synchronization,even when the link capacity is reduced. Werecorded no loss of high-priority traffic as wedecreased the link capacity and monitored minimalchange in latency: average latency was between200 microseconds when using 512QAM. Whenwe reduced the modulation all the way to 4QAM,the average latency for the highest priority traffic(CoS 1) was still averaging 294 microseconds withmaximum latency of 876 microseconds.

Performance Monitoring Per Class of Service

Proactively identifying an issue in the network,before the customer detects any degraded perfor-mance, is a vital key to maintaining happycustomers and selling premium services. TheInternet Engineering Task Force (IETF) defined amechanism in a Two Way Active MeasurementProtocol (TWAMP) which Ericsson implemented inits SP 4151 and 420 routers as well as in the Eric-sson RBS 6202 base station. This mechanism allowsservice providers to automatically measure delay,delay variations and packet loss ratio. These are thethree parameters on which our tests focused.

The TWAMP protocol, as implemented by Ericsson,also allows the operator to monitor specific classesof services for different values. Given that delayand delay variation could significantly differbetween different traffic classes, it made sense forus to emulate delay in specific traffic classes andmake sure that the reports collected by the EricssonIP probes, were able to identify the increase delay.

We configured the Ixia Anue impairment generatorto increase one class of service delay to 10 millisec-onds and another class of traffic to suffer anincrease delay of 20 ms. We then monitored withEricsson's IP Probe and verified that the probecorrectly reported the delay increase and later,once we removed the impairment profile, on thereturn of the network delay to the normal condition.

We collected measurement information from the twodevices as shown in the figure below.

We also tested the ability of the same networkelements to detect packet loss. We used the Ixiaimpairment generator to drop 5% of the traffic forone class of service and 15% of the traffic foranother class of service. In all our measurementpoints, the monitoring devices showed the correctpacket loss ratio.

We believe that these capabilities are useful forservice providers especially in networks wherepacket-clock synchronization is used. Being able tomonitor the delay and delay variations, can providea service provider with an accurate picture ofwhere the potential pitfalls are for their IEEE 1588-2008 deployment – where delay variation is high,the network should be looked at carefully. Of coursethe same tool can also monitor SLAs and providegeneral early warning alerts when service quality isreduced. Seeing the same performance monitoringtool being used in all network elements, from thebase station itself onwards, is also an encouragingmessage to service providers.

1. Since Ericsson explained that the SP 415 and 420 only differ in the number of ports, we only executed the test with the SP 415.

Figure 4: High Priority traffic average and MaxLatency in the downstream direction

Figure 5: TWAMP Measurement Points

TWAMP session

Ixia Anue 3500 Ericsson

SP 415MINI-LINKSP 420PT 2020

SP 420

IP Probe

RBS 6202


Securing The Routers

There are several ways to secure routers. Controlplane authentication should be used to make surethat only authorized routers could establish andexchange routes. The router itself should, as a ruleof thumb, always be configured to allow onlysecure command line interface (CLI) connectionsand in the case that the router is being attacked, therouter should be able to continue forwarding trafficwithout affecting user traffic.

We put two of the Ericsson devices through the rigorof security testing. First we successfully verified thatboth SSR 8010 and the SP 420 only establishedcontrol plane sessions with neighbors using md5authentication. We tested each device in the sameway that it was configured in the test: the EricssonSP 420 with OSPF and eBGP and the Ericsson SSR8010 with IS-IS and iBGP.

We then used two well known attacks directed atthe Ericsson SSR 8010: ICMP and ARP attacks. Bothwere originating in one of our emulated accessconnections such that the Ericsson SSR 8010 wasthe first device to detect the attack. Together withour attack traffic, we sent emulated customer trafficand monitored both CPU utilization and packet losson the legitimate subscriber traffic.

The results showed that the Ericsson SSR 8010 wasable to successfully continue operating while it wasbeing attacked by both ICMP and ARP messages.The CPU remained stable and no packets were lostfrom the legitimate user streams.

Intelligent Transport Tests Summary

Security testing is of course a complete area, oneon which we could spend several months. Given thescope and the tests, we wanted to make sure thatthe solution at least meets all the functional criteriathat we believe a service provider will be lookingfor: transport flexibility, performance monitoring,and of course, multi-standard base station support.Our expectations were indeed met by the Ericsson‘Evolved IP Network.’ Having performed these baseline tests, it was prime time to move on to one of themost challenging areas in networking these days:packet-based clock synchronization.

Clock Synchronization

Mobile networks have always required frequencysynchronization, but in recent years the industry istalking more and more about the need for time ofday and phase synchronization. This is driven by anumber of radio features such as LTE Broadcast andSmall Cell co-ordination. While an operator mightnot today require time and phase synchronization,it is becoming important to understand how toevolve their network to be able to support it in thefuture. If this is not provided with sufficient accuracyand stability a base station will be degraded interms of its capabilities, and in the worst case thismay cause it to disconnect from the network

Ericsson suggested to split the clock synchronizationtests into two parts - first to focus on full-path supportin line with Ericsson's 'Evolved IP Network' designguidelines (based on the ITU-T G.8275.1), and thenadditionally test for partial-path support which is notyet standardized, but could be of interest toforward-looking service providers.

Full-path support means that every node in the clockdistribution path, from the primary reference clock(in this case a Microsemi TimeProvider 2700GrandMaster) to the base stations (Ericsson RBS6202) was in some way actively involved in main-taining the clock quality. Since Ericsson uses thestandard-based IEEE 1588-2008 (also called Preci-sion Time Protocol or PTP), the roles of the Ericssonproducts split between a Boundary Clock and Trans-parent Clock.

Freq. link1PPS link

Frequency/PhaseAnalyzer

RF linkClock sync. path

RBS

GPS Antenna

MINI LINK PT 6020

MINI LINK PT 2020 SP 415 SP 420

SP 420 SP 420

SP 420

TimeProvider 12:50:00

6202

Figure 6: Full-path Clock Synchronization

IxiaAnue3500

2700


Between the GrandMaster and Ordinary Clock(implemented as a function inside the Ericsson RBS6202 LTE base unit) were both Boundary Clocks inthe SP routers, and Transparent Clocks in the MINI-LINK PT microwave devices. In the RBS node itselftwo functions existed: the Transmission Control Unit(TCU) implemented a Transparent Clock functionand the air interface control cards implemented anOrdinary Clock.

Full-Path Clock Quality

We started our clock testing by measuring the clockquality in the access. In this topology, where theclock source is positioned somewhere within thenetwork access, all base stations could synchronizeto the same GrandMaster.

We generated load in the access network based onthe definition in ITU-T G.8261 for Test Case 12. Weused Network Traffic Model 2 which is intended tomodel traffic where the majority of the traffic isdata. The load was equivalent to 80% of the down-stream capacity (towards the base station) and 20%in the upstream direction. We then made sure thatthe Boundary Clock, to which we attached ourtester, was locked to the GrandMaster, andcaptured measurements over a whole weekend.

The results showed that the LTE base station (with itsstringent phase synchronization requirement) ransmoothly over the whole weekend. From a stan-dards perspective, the phase offset should be within1100 nanoseconds - we confirmed that the clockquality for phase was within +/- 325.56 nanosec-onds. The frequency was also confirmed to pass theG.8261 EEC Option 1 mask for the completeperiod monitored - which in itself confirms the long-term limit requirement of 16ppb or better as well.

Now that we knew that the quality of the Ericssonclock distribution solution was compliant with bothphase and frequency standards, we investigated itsrobustness by emulating various fail-over scenariosand checking if the clock quality remained withinthe accepted tolerance.

Clock Signal Robustness – Link Failure in the Access

Positioning the GrandMaster clock at the boundarybetween the Access and Aggregation networks hasseveral benefits. The clock path is shorter than whenthe clock is positioned in the IP service core andtherefore delay variation, an aspect of networks thatincreases with distance and the number of nodes inthe path, is shorter. If a path within the accessnetwork experiences a failure, the network could re-route around the failed link or node, but the Grand-Master function will be uninterrupted.

In this scenario we disconnected the link betweenthe Ericsson SP 415 and the MINI-LINK PT 2020.We then checked to see that in our monitoringpoint, the Ericsson SP 420 Boundary Clock, theclock source port changed. The SP 420 changed itsstate to “free-running” for 26 seconds and thenlocked to the GrandMaster again.

This was unexpected behavior since the natural firststate to transition into, for an Ordinary andBoundary Clock should be holdover - a state inwhich the clock is maintained locally. Ericssonexplained that phase holdover was not supported inthe software release under test, but that it is plannedfor future release.

During those 26 seconds, the 1PPS output, whichtypically will be used by the base station to receivephase signal, was turned off - by design. This indi-cates, to the base station, that it should be usingother mechanisms for phase information at thatpoint, such as its own internal oscillator or otherbackup references, to maintain phase stability.

Figure 7: Full-path

G.8261 EEC Option 1

MTIE Expected MTIETDEV Expected TDEV

MTIE and TDEV measurement over a weekend

1E0

1E1

1E2

1E3

1E-1 1E0 1E1 1E2 1E3 1E4


The next step was to measure clock quality duringrecovery - when the link which we disconnectedwas restored. Once we restored the link, the SP420 changed its primary clock port back to theoriginal port. The SP 420 reported free runningstate for 121 seconds and then re-locked.

These results show that the Ericsson full-path supportdesign guideline can deliver the frequency andphase synchronization required by LTE. For thosenetworks that are not equipped with GrandMasterclocks in every access network or use a mix ofdevices, some of which do not support PTP, apartial-path support model could be used. Partial-path, where the packet clock signal is crossingnodes that do not support PTP, was our next focus.

We evaluated two partial-path support scenarios:the first condition being a failure of the primaryGrandMaster clock (positioned in the accessnetwork) forcing the network to use a GrandMasterin the core network. The second condition was anetwork which uses a GrandMaster clock posi-tioned in the core as primary reference clock.

GrandMaster Clock Resiliency (partial path)

Clock quality may not immediately be affected bythe loss of the primary reference, owing to synchro-nization holdover. Depending on the oscillatorquality, a device can run in holdover mode for anextended period of time. It is best to return to thehealthy clock operation as quickly as possible. Inter-estingly, the duration in which a device shouldmaintain an accurate clock in a holdover state hasnot been defined by the 3GPP - this is perhaps anarea for the service providers and vendors to inves-tigate in the future.

The IEEE 1588-2008 standard describes an algo-rithm in which a Boundary or Ordinary Clock canselect the best timing source. The algorithmcompares the following parameters in this order:Priority 1, Clock Class, Accuracy, Variance, Priority2, and Identity. In this test, we disconnected theGPS antenna from the primary GrandMaster, andverified that the Boundary Clock, to which weconnected our Ixia Anue 3500 measurementdevice, switched to the secondary GrandMaster.We also measured the frequency and phase qualityduring the whole procedure in order to understandif an LTE base station will be affected by such failurecondition.

Initially the Microsemi TimeProvider 2700 Grand-Master continued providing primary reference. Fiveminutes after we disconnected its GPS source, theGrandMaster degraded its clock class and the Eric-sson SP 420 reacted by changing its state to free-running. This behavior is consistent with previoustests in the full-path support section.

Within 140 seconds of the Ericsson SP 420changing its state to free-running, it locked to thesecond GrandMaster clock – a Microsemi TimePro-vider 5000 positioned in the IP service core. Whenwe calculated the phase and frequency masks overthe complete time period we could see that theywere not being met, upon further investigation ofthe data before and after the failure we could seethat after the SP 420 has locked to the backupgrandmaster, the MTIE was met, but not the TDEV.

Ericsson explained that since the clock is nowdistributed in a partial timing network, it is muchmore noisy. In this scenario, the healthy operationof the base station will depend on alternative clocksources or its own oscillators maintain healthy oper-ations. Another alternative, recommended by Eric-sson is to filter the additional noise caused by thepartial-timing solution.

Clock Signal Robustness - Link Failure in the Aggregation

In the last failure condition, we emulated perhapsthe most difficult condition for a packet clock distri-bution network. Here Ericsson configured a singleGrandMaster clock, attached to the Ericsson SSR8020 in the IP service core. This meant that theclock distribution network was from the get-go in apartial timing mode as the SSR 8010 and 8020routers in the IP service core and aggregationnetwork were not configured with any PrecisionTime Protocol functions.

A single VPWS service was used to transport thePTP messages from the GrandMaster to theBoundary Clock in the access network. The VPWSservice was configured between Ericsson SSR 8020where the GrandMaster clock was connected, andEricsson SP 420 where the Ericsson SP 310(Boundary Clock) was connected. Ericssonexplained that the Boundary Clock on the SP 310was configured such that the upstream port wasconfigured for IP/unicast while the downstream portwas configured for Ethernet/multicast.


A backup RSVP-TE tunnel was used to provideprotection and path symmetry for PTP traffic in caseof failure on the primary path. The PTP traffic in theaccess was distributed using native Ethernet encap-sulation.

Once we verified that the clock was being recov-ered on the same Ericsson SP 420 router that wasused as Boundary Clock in all our tests, we discon-nected the link between the two SSR 8010s in theaggregation network. This caused the PTP traffic toreroute around the failed link.

During the whole duration of the test we monitoredthe 1 PPS and SyncE interfaces on the Ericsson SP420, making sure that both phase and frequencyrequirements (the phase deviation within 1100nanoseconds and the frequency within 16 pbb)were being met. The measurements showed that theabsolute phase error exceeded 1100 nanosecondson two occasions before the failure and frequencymeasurement did not pass ITU-T G.823 TDEV SECmask. Ericsson explained that this was expectedbecause the clock was distributed using partialtiming path.

Even during the emulated failure condition the Eric-sson SP 420 stayed time-locked to the GrandMasterclock. This was due to the fact that the failure wasresolved quicker than the PTP Announce MessageInterval (set to 1 packet/second). Rerouting of thePTP stream in the aggregation network added twoadditional network hops in the PTP path thus the

mean path delay increased from 56μs to 81μs. As anext step we removed the emulated failure on theworking path and after 140 seconds Ericsson SP420 entered in free-running state, before re-locking.This behavior is expected and is due to a change inthe floor packet delay as per section I.5.1.3.2 ofthe ITU-T G.8260 Amendment 1, which states thatthe packet network limit measurement should be re-started when such a floor packet delay changeoccurs.

Clock Synchronization Tests Summary

The Ericsson team undertook a monumental chal-lenge, showing not only the optimal clock condi-tions, but also degraded clock conditions that arelikely to trouble any operator. Packet-based clocksynchronization is a reality for many networks thatcan not or do not want to use GPS. Currently themain proven mechanism to distribute phase, Time ofDay and frequency information in packet networksis the IEEE 1588-2008 Precision Time Protocol.

Aside from academic discussions about theoreticalfrequency and phase quality, the important questionthat an operator should be asking himself is whetherthe base stations are going to maintain operationsand if the air interface is being used at optimal effi-ciency. The answer for the current generation forbase stations is a yes as our measurements show.The other substantial take home message for opera-tors is also that the design of a clock distribution

Figure 8: Partial-path clock distribution Test Setup

Freq. link — SyncE.1PPS link

Frequency/PhaseAnalyzer

RF link — GPSClock sync. path

RBS PT 6020

GPS Antenna

PT 6020

PT 2020 SP 415PT 2020

6202

SSR8010 SSR

8010

SP 310

SP 420

8010SSR

SP 420

SP 420

SSR 8010

SSR8010

SSR8010

SP 420

TimeProvider 12:50:00

5000

IxiaAnue3500

SSR 8020


network must be done together with detailed under-standing of the base stations capabilities andrequirements, as well as with the active support ofthe underlying IP infrastructure.

High Availability

Once we finished the clock testing we shifted ourattention to another attribute that each serviceprovider network is very concerned with: serviceavailability. After all, a service is often measured bywell defined parameters in a service level agree-ment (SLA). We already verified that the Ericssonsolution can measure delay and delay variations,two parameters that are often used in SLAs. Now itwas time to check if services are affected when fail-ures in the network occur.

Recovery from Link and Node Failure

Whether a link fails due to a backhoe diggingwhere it should not have been, or a router fails dueto mechanical fan issues, the safest way to operatea network is to let it react to sudden failures byitself. In the Ericsson ‘Evolved IP Network’ thevendor used IP Fast Reroute, as specified in RFC5286. Ericsson explained that they favour IP FastReroute over MPLS Fast Reroute since the formerprovides fast failure recovery with LDP, and hencedoes not require the complexity involved with RSVP-TE.

We picked one node and one link in the network asthe target for our failure condition: one of theconnection points in the aggregation network. Tosimulate a router failure, we simply disconnectedthe Ericsson SSR 8010 from its power source. Tosimulate the link failure we disconnected the fiberlink between two of the Ericsson SSR 8010s in theaggregation network. As can be seen in the figurebelow, none of the failover scenarios caused an outof service time larger than 5.3 milliseconds.

Recovery from Optical Transmission Failure

Another scenario that is particularly maddening isthe failure of optical transmission units. In some ofthese failure scenarios, the routers terminating thelinks do not experience loss of signal (LOS), buttraffic is no longer reaching them. Typically routingprotocols will notice that their hello messages arenot being answered, but the hello intervals are typi-cally configured in the order of seconds. Prudentservice providers typically look for more aggressivemechanism to detect such failures. Such a mecha-nism was created by the Internet Engineering TaskForce (IETF) and is called Bidirectional Fault Detec-tion or BFD.

Ericsson configured BFD on all interfaces in the testand for all routing protocols used on all devices - SPand SSR. We picked one of the links, the onebetween the access network SP 420 and the aggre-gation network SSR 8010 to insert a switch andturn off the switch’s backplane. This emulated thesame condition as a transmission device failure –both routers had their interfaces up, but no trafficwas passing through.

Given that Ericsson configured BFD hello intervalsat 100 ms and the number of missing hellos beforethe protocol was to raise the alert at 3, we expectedthat the detection time would be between 200 and300 ms. Once the failure is detected the remainingtime is due to service reconvergence. We recorded,upon triggering the failure, an out of service time of417 ms in the upstream direction and 519 ms in theother direction (upstream direction is base station tothe Internet).

Figure 9: IP Fast Reroute – Out of Service Time

Table


The next step in the test is of course the recovery –the state in which the issue is resolved and thenetwork needs to return to normal operations. Herethe potential issue is that the Internal GatewayProtocol (IGP), the protocol that helps LDP identifythe next hop in the path, will need to reconverge.This could potentially black-hole traffic until all theprotocols converged to the original path. This LDP/IGP synchronization in our test was done betweenIS-IS and LDP and was measured to be 9ms in theupstream direction and 190ms in the downstreamdirection. Ericsson explained the difference in out ofservice time as a consequence of the different hard-ware architectures between the SP 420 and SSR8010, which leads to different re-converge times inthe upstream and downstream directions.

Gracefully Restarting Routing Protocols

The Internet Engineering Task Force (IETF) definedmechanisms to allow routers to restart their controlplane without affecting the forwarding plane. Some-times BGP or IS-IS need to be restarted, but notopology changes took place. In this situation, whenthe forwarding plane is functioning and the networktopology is stable, if the process that is beingrestarted is able to communicate that fact, othernodes would continue forwarding traffic and noeffect on traffic in the network is expected.

We restarted both BGP and ISIS process on the Eric-sson SSR 8010 while sending the full traffic load. Inorder for the restart to really be graceful, the neigh-bors of the router being restarted need to operate inhelper mode. This role was taken by the Ericsson SP420. We used the CLI commands ‘process restartbgp’ and ‘process restart isis’ and measured the outof service time.

The results matched our expectations as no packetswere dropped during this operation. We also veri-fied that no re-convergence was happening in bothrouting protocols behind the scenes just to be surethat the routers were really using Graceful Restartmechanisms.

High Availability Tests Summary

We verified that the Ericsson ‘Evolved IP Network’ isequipped with high availability mechanisms to helpservice providers maintain operations duringdisaster scenarios. With mobile traffic moving to anall-IP framework, all customer traffic in a convergednetwork, be it mobile, residential or enterprise, is IP-

centric. This gives credence to Ericsson’s choice ofdepending on IP-centric resiliency mechanisms fromthe large pool of options available in the variousstandard bodies.

Scalability and Performance

It is only logical that a service provider should beconcerned with the service scalability of any solu-tion that he or she is buying. In order to provide anoverview of the service scalability and perfor-mance, we picked two of the devices – the EricssonSP 420 and the SSR 8010, and verified that eachof them can support the number of services Ericssoncommitted to supporting.

VPWS and L3VPN Service Scalability

For the remaining tests we disconnected the networkand connected the routers directly to the Ixia tester.This meant that the Ixia tester had to emulate theroles of the other Ericsson devices, a function thatthe tester had no problems executing.

The service scalability tests used the same method-ology regardless of the service tested. We firstestablished control plane connectivity with thedevice under test and verified that all services wereinstalled using the command line interface. Once allservices came up, we sent traffic close to line rate inorder to verify that the service was also usable.

In the L3VPN case we also injected 128 routes toeach of the VRFs on the SSR 8010 as well as 156routes to each of the 64 VRFs on the SP 420 for atotal of 1,025,792 unique routes. We then senttraffic to each of these routes to make sure that theywere indeed installed in the forwarding plane.

Forwarding Performance

If a network is truly successful, one can imagine thatas customers are added, more and more bandwidthwill be used and the routers will be expected todeal with an increase in forwarding requirements.As a rule of thumb, service providers do not tend torun their routers at 100% utilization – on thecontrary, normally routers only run at 50%-75% utili-zation.

Tested Network Services

# Services on SP 420

# Services on SSR 8010

L3VPN 64 8,000VPWS 250 239,844


To round up the testing we performed IPv4-focusedforwarding performance tests on two of the devices:the Ericsson SP 420 and the SSR 8010. Both werefully loaded with line cards which meant that the SP420 was tested in a configuration of 20 GigabitEth-ernet and 2 10GigabitEthernet while the SSR 8010was loaded with 10 line cards each supporting 1010GigabitEthernet ports.

We used the same methodology described by theIETF in RFC 2544 and selected frame sizes providea realistic overview relevant to service providers.Typically, the smallest frame size (64 Bytes withoutVLAN, 68 bytes with VLAN) is used to measurepacket processing performance of the solution, butare not the only packets seen in the wire. For thisreason we used a packet size mix, an Imix, which ismore typical of actual packets in the network. Wesummarize the results in the table below.

Summary

The networking market is dominated by vendorswhose roots are in the Internet. The clear separationbetween mobile and Internet has been eroded sincethe advent of the smart phone with more and moredevices accessing the Internet using radio signal asopposed to cable or wifi. We see that an indepen-dent test of a holistic converged network solution isone of the strongest statements a vendor can makein the market and the most reliable one at that.

Based on the results of the test we can confirm thatEricsson’s ‘Evolved IP Network’ solution is meetingEricsson’s claims. The solution is IP-centric, offeringmulti-standard base stations and QoS-aware micro-wave transport. We verified that performance moni-toring tools were functioning accurately and couldalready be used at the base stations as well as ontransport nodes. We verified that Ericsson’s uniqueand standards-based approach to high availabilityprovided the high availability required in modernnetworks, and that the solution scale to the designgoals Ericsson would suggest to its customers. Wemust also salute Ericsson’s courage to demonstrate,along side optimal clock synchronization topolo-gies, the more challenging partial-path setup. Weexpect future tests as the solution evolves.

About EANTC

The European AdvancedNetworking Test Center(EANTC) offers vendor-neutral network test servicesfor manufacturers, serviceproviders and enterprisecustomers. Primary busi-ness areas include interop-erability, conformance and

performance testing for IP, MPLS, Mobile Backhaul,VoIP, Carrier Ethernet, Triple Play, and IP applica-tions.

EANTC AGSalzufer 14, 10587 Berlin, [email protected], http://www.eantc.com/v1.0, 20140221, JG

Any marks and brands contained herein are the property oftheir respective owners.

Packet Size (bytes)

Line Rate forwarding MINI-LINK PT 6020

Line Rate forwarding SP 420

Line Rate forwarding SSR 8010

68 100% 100% 69.4%

128a

a. Frame size added to SSR test to measure 100% performance at small frame size

Not-relevant Not-relevant 100%

373 100% 100% 100%1518 100% 100% 100%IMIX 100% 89% 98%

Figure 10: Ericsson SSR 8010 – Performance and Scalability Setup


Documents

EANTC Ericsson EIN Marketing Report