EANTC Independent Test Report

1 EANTC Independent Test ReportHuawei 5G-Ready SDNE valuation of the Transport Network SolutionSeptember 2018 EANTC Test Report : Huawei 5G-Ready SDN Test Page 2 of 14 IntroductionHuawei commissioned EANTC to conduct anindependent test of 5G bearer network features. Thevendor selected a range of functional aspects from itsproduct portfolio for the verification. EANTC wasinvited to review the solution at Huawei globalheadquarters in Shenzhen, China, in August , engineers executed the tests in three differenttest beds, each focusing on specific aspects of thetransport is certainly approaching fast; major challenges forthe transport network are going to hit operators in 2 3years when large-scale services will be deployed:1. Service scalability: Many more cell sites thanbefore will be connected to the network the num-bers are likely to increase by a factor of five to ten,thus increasing the number of paths across thetransport network and requiring better protocolscale, automated provisioning and fault manage-ment.

2 2. Bandwidth scalability: For many consumers, thepromise of 5G services is mostly regardingthroughput. AR/VR, streaming at HD and soon4K video quality will require massive transportcapacity, starting at the cell site connection. 3. Mobile edge computing (MEC): Some cell sites willrequire service connectivity to one or more MECsites closer to the edge in addition to the defaultmobile core connections; this will increase thenumber of paths in the transport network Slicing: There will be differentiated transport net-work services for a range of services some requir-ing low delay, others high availability, again othersmassive throughput. The bearer network will haveto support these services through traffic engineer-ing, a concept that had often been proposed in thepast but not widely adopted yet, and monitor theservice quality with advanced telemetry solutions.

3 5. Transport migration: Service providers havedeployed vast backhaul infrastructures for the pre-existent LTE/4G networks; these need to be main-tained, integrated and migrated to SDN for costand deployment speed demonstrated a selected set of functionalconfigurations hinting towards these challenges. A360-degree evaluation of the whole transport networkwas left for future exercise specifically regarding theend-to-end transport network integration, real trafficengineering, performance evaluation and servicescalability testing. In any case, the functional tests wewitnessed highlight a number of key concepts thatservice providers can explore further. Executive SummaryThe ATN950C and NE40E-M2K passed interfaceforwarding performance tests of the 25GE and 50 GEcards, including 40km dual-fiber 50 GigE SFPs andsingle-fiber BiDi 50 GigE SFPs; the 50GE moduleshowed slicing isolation and 1 Gbit/s bandwidthgranularity of channelized sub-interfaces.

4 The two routers also demonstrated a range of SegmentRouting functionality, including live migration from LDPor RSVP-TE to Segment Routing, interconnection toMPLS-TP, and interconnection between MP-BGPL3 VPN and EVPN-MPLS. The hardware showedsupport of up to ten stacked labels in segment out-of-service time at hot-standby protectionremained below 50 Huawei Network Cloud Engine (NCE)demonstrated its ability to compute an optimal pathbased on multiple constraints, to provision L3 VPN andL2 EVPN services by automatically deploying SegmentRouting tunnels and to simplify the maintenance withautomation and what-if simulation. NCE showed alsostreaming Telemetry capability and path optimizationusing Highlights Forwarding Performance of 50 GigE and 25 GigE module achieved link utilization Latency below 15 s per hop 50 GigE module supports 40km dual-fiber SFPs with up to 20 dBm optical budget, as well as single-strand bi-directional SFPs In-service slicing using 50 GigE module Hitless bandwidth resizing 1 Gbit/s slice granularity of the channelized interface Proven congestion isolation between slices Less than failover time with SR-TE static path protection for L3 VPN services and zero frame loss during path restoration Proven NCE ability to perform path computation of EVPN/Segment Routing using 9 constraints Proven NCE ability to provision L3 VPN and L2 EVPN services.

5 To create bandwidth on demand per service and to simplify maintenance using what-if simulation Streaming Telemetry using gRPC and path optimization with RESTful API EANTC Test Report : Huawei 5G-Ready SDN Test Page 3 of 14 The Huawei ATN950C and NE40E-M2K routers, andthe Network Cloud Engine (NCE) can be used inmany contexts for fixed and mobile services. WhenHuawei commissioned EANTC to test the latesthardware and software aspects of these solutions, thevendor put the focus on 5G readiness. That said, theevaluated functions can be applied for other networkservice use cases as well. Test results are described indetail in the following and SoftwareTable 1: Hardware and SoftwareFigure 1: Line Card Under TestFigure 2: Device Under Test (DUT)Device Under TestChassisLine CardsSoftware VersionNE1 ATN950 CEthernet 50 GEV300R005C00 Ethernet 2x25 GENE2NE40E-M2 KEthernet 2x50 GEV800 R011C00 Ethernet 4x25 GENE3NE40E-X2-M8 AEthernet 10 GEV800R011C00NE4NE40E-X8 AEthernet 10 GEV800 R011C00NE5 PTN960 Ethernet 10 GEV100 R007C00 NCEN etwork Cloud EngineV100R018C001x50 GigE2x25 GigE2x50 GigE4x25 GigENE40E-M2K-DCNE40E-X2-M8 AATN950 CNE40E-X8 AEANTC Test Report : Huawei 5G-Ready SDN Test Page 4 of 14 Figure 3: Physical Test SetupSegment Routing and MPLSM aximum Label Stack DepthRouters are restricted with respect to the label depthsupported for a PUSH operation.

6 In this test, wedetermined the maximum depth of a segment labelstack supported on the device under test (DUT).Segment Routing does not require any changes to theoperations of the data plane compared with MPLS networks. However, deploying Segment Routing mayaffect the maximum depth of the MPLS label stackrequired. As every segment in the list is represented byan additional MPLS label, the length of the segment listdirectly correlates to the depth of the label are several ways to reduce the length of thelabel stack as discussed in the SPRING draft (spring-segment-routing-mpls-07). Implementing a long pathwith many explicit hops as a segment list may yield toa deep label stack. Thus, the operator needs to beaware of the routers limits and take them into accountin the emulated up to 10 segments using three DUTs:ATN950C, NE40E-X2-M8A and NE40E-X8A. Toreach the maximum stack depth, Huawei configuredan explicit path which passed the ingress node, thentraversed back and forth between the latter two nodesuntil all segments had been added.

7 We captured thepackets as shown in Figure sent traffic via the generated service and did notobserve any packet loss, as was 4: Packet Capture: Ten MPLS LabelsSegment Routing Path ProtectionIn this test we measured the maximum convergencetime in Segment Routing after a link failure 5: Segment Routing Path ProtectionHuawei configured hot-standby protection for SegmentRouting and established the primary path between twoPE nodes (NE1 and NE2). The endpoints of the pathinitiated BFD (Bidirectional Forwarding Detection)messages with 10 ms interval to detect networkfailures over this path. For protection, Huaweiconfigured an explicit backup path manually whichworked as RSVP-TE hot-standby-like explained that the egress node shalldetectremote network failures via asked us to send IPv4-only test traffic at a totalrate of 6 Gbit/s for the six L3 VPN services. TheEANTC team observed via the router s CLI traffictransported over the primary LSP.

8 While traffic wasrunning, we measured the out-of-service time byintroducing a link failure (pulling out the cable asshown in the figure). After the link failure we observedThe 10 GbE line cards on ATN950C and NE40 Erouters support up to 10 stacked MPLS NetworkIP/MPLS CoreSpirent NE Router50GE25 GETraffic GeneratorNE5X5X5NE40E-X2-M8 APTN960NE1 ATN 950 CNE4NE40E-X8 ANE2NE40E-M2 KSegment routing statically configured end-to-end path protection with BFD showed less than 50 ms out-of-service time on primary link failure and zero frame loss during path RoutingNE Router10 GNE1 Link FailurePrimary PathStandby PathBFDNE3NE4NE2 EANTC Test Report : Huawei 5G-Ready SDN Test Page 5 of 14that the traffic was switched over to the backup pathas expected. The out-of-service time was measured ms to ms which was as expected andbelow the 50 ms claimed by Huawei. No packet losswas observed during link recovery.

9 We performed thistest three times to validate consistent of MPLS L3 VPN and EVPN-based IP VPNH uawei demonstrated a solution to interconnectlegacy MP-BGP based L3 VPN (RFC4364) and EVPN-MPLS (RFC 7432). A vendor-specific function on theNE40E-X8A allows interconnection of the two VPNimplementations. Huawei explained that an end-to-endIP VPN service is created by a virtual router functionthrough route import. We checked that traffic wasforwarded across the different VPN types. Additionallywe verified that each pair of VPN services wereisolated from each other by using six of such end-to-end L3 VPN services (see Figure 6).Figure 6: Interconnection MP-BGP Based L3 VPN and EVPN-MPLSAs part of the evaluation, we inspected the VRF(Virtual Routing and Forwarding) table on the NE40E-X8A using the CLI. As expected, this table learned theroutes of both service types, consisting of the L3 VPNroutes as well as the EVPN routes, which wereimported into the same routing table.

10 For the lattercase, we captured the EVPN Segment Routes carriedin the MP-BGP updates to verify that the ESI (EthernetSegment Identifier) was bound per EVPN route viacapture. As expected, we observed the requested ESIfield in the BGP Network Layer ReachabilityInformation (NLRI) also checked the VRF tables on the other two PEsand observed the same set of L3 VPN routes. We sentand received 6 Gbit/s test traffic in total for six end-to-end L3 VPN services; no packet loss was ModeHuawei asked EANTC to verify the support andconnectivity of legacy MPLS-TP pseudowires on theATN 950C. Supporting MPLS-TP, Huawei explained,provides a migration solution for MPLS-TP usingmodern, fully supported hardware and software. The test scenario is depicted in Figure 7. A legacyMPLS-TP router, the Huawei PTN960, was used toterminate the MPLS-TP tunnels. Before starting theverification, we initially checked via CLI that the ATN950C was correctly configured to enter the MPLS-TPmode.