EANTC TEST REPORT: Cisco MPLS-TP Architecture Test --- Page 1 of 6

CiscoMPLS Transport Profile (MPLS-TP) Solution

Protocol Architecture and Functionality Verification Test Report

Introduction

In February 2011, Cisco commissioned EANTC withan in-depth review of Cisco’s new MPLS-TP implemen-tation across three switching platforms and a manage-ment solution.

We took a look at how Cisco answers the main ques-tions related to MPLS-TP: How are connection-orientedEthernet services configured and provisioned? Howare services monitored and managed? What is themaximum outage expected in the case of a failure?What Operation, Administration and Maintenance(OAM) tools are available for localizing failures? Thisreport outlines the results of our rigorous tests whichCisco‘s products undertook.

Tested Devices and Architecture

Cisco constructed the test bed to represent a carriernetwork with an IP/MPLS core and an MPLS-TP trans-port/aggregation network area. Two test scenarioswere defined, each with a different logical aggrega-tion topology. Cisco brought to the test the 7604,7606, ASR 9006, ASR 9010, and CPT 600. A singlephysical topology was used for both logical scenariosfor simplicity. All devices used pre-release software.No rebooting or software upgrades took place on anyCisco equipment during the test.

We ran through each test twice — once for each of thetwo logical scenarios configured by Cisco. Bothscenarios included an IP/MPLS domain and an MPLS-TP domain — the difference being the logical roles byeach device. Please see figure 2 for details. In the firstscenario, for example, the Cisco ASR 9010 intercon-nected the two domains while the Cisco 7604 playedthis role in the second scenario. In both cases theCisco ASR 9006 was the only other device in the IP/MPLS domain, the rest being in the MPLS-TP domain.

EANTC Validation Highlights Unified service configuration across

MPLS-TP and IP/MPLS using existing pseudowire technology

Comprehensive fault management including tools for fault verification and isolation

1:1 linear protection with hitless restoration and hitless manual switchover with sub-second protection switching

Integrated monitoring of packet transport technology using Cisco Prime Network

Standards based solution

IP/MPLS Network

MPLS-TP Network

CiscoCPT600

CiscoASR9010

Cisco7606

Cisco7604

CiscoASR9006

Cisco7606

Cisco7604

CiscoASR9006

CiscoCPT600

CiscoASR9010

Ethernet Link

“Scenario B”

“Scenario A”

Figure 1: Test Setup and Logical Scenarios

Access Aggregation Core

EANTC TEST REPORT: Cisco MPLS-TP Architecture Test --- Page 2 of 6

The two domains (MPLS-TP and IP/MPLS) had thefollowing differences:

1. No signaling protocols were used in the MPLS-TPdomain. All Pseudowires and their Label SwitchedPaths (LSPs) were entered manually into theForwarding Information Base (FIB) by configuringincoming and outgoing labels and interfaces ineach case via the respective device’s commandline interface (CLI). The IP/MPLS domain usedOSPF-TE and RSVP-TE for computation of labelswitched paths (LSP) and the signaling of labels. Inaddition, it used LDP for pseudowire signaling.

2. The MPLS-TP domain implemented a set of newOAM protocols and features being discussed anddefined at the IETF. (e.g. continuity check,connectivity verification, route tracing, faultmanagement). The IP/MPLS network used theOAM mechanism for fault verification and isolationusing LSP Ping/Trace which have been defined forsome years now.

EANTC verified that the appropriate configuration was found on each device, that such labels and forwarding was used for both data plane traffic and OAM, and ensured that the tester emulating customer traffic had no IP configured at all. Interface identifiers were configured together with subnet masks as defined in draft-ietf-mpls-tp-identifiers.

Cisco PrimeTM Network

Throughout the tests, Cisco demonstrated theirmanagement system - Cisco Prime Network. Thesystem provided monitoring and assurance of packetand transport devices from a device view (physicaland logical) up to a topology and service view. Theapplication monitored all devices under test usingSNMP and automated command-line inference (CLI).The software run on a  server connected to themanagement network.

To simplify operation and facilitate monitoring, twomain views were used throughout the testing:

1. Cisco Prime Network topology view, where thedevice and topological link were reported.

2. Cisco Prime Network service view, where the usercan drill down on the information of a selectedservice (pseudowire, MPLS-TP tunnel, etc.)

Figure 2: Cisco Prime Network - Topology View

Cisco Prime Network reported and summarized allalarms in both the topological as well as in the serviceview. Moreover, the service view automaticallyupdated informing the user of the current alarmeddevices as well as of the path switching whenhappening.

Figure 3: Cisco Prime Network - Service View

Cisco Prime Network was able to detect and displaychanges in the network services thereby enablingrapid fault isolation and restoration of services. ForMPLS-TP services these management capabilities arecritical for delivering high-quality services.

Operation, Administration and Main-tenance (OAM) Tests

An important component of a transport profile forMPLS consists of defining OAM tools that will enablethe same level of operational control, troubleshootingand Service Level Agreement (SLA) validation thatservice providers have in their legacy transportnetworks. As the requirements for OAM in MPLS trans-port profile IETF request for comments (RFC 5860)specifies these OAM mechanisms must operate inband, must be applicable to all services and must notrely on a control plane.

EANTC TEST REPORT: Cisco MPLS-TP Architecture Test --- Page 3 of 6

In all the OAM tests we preformed, we verified that theOAM tools were using the Generic AssociatedChannel and Generic Associated Label (GACh/GAL)as described in RFC 5586.

MPLS-TP Trouble Shooting Tools – LSP Ping and Traceroute

LSP Ping and Traceroute provide the on-demandconnectivity verification (CV) and path tracing func-tions as part of the MPLS-TP OAM toolkit. These toolsfacilitate the detection and isolation of unexpectedconnectivity (e.g. merging, mis-connection) across anMPLS-TP LSP.

LSP Ping and Traceroute have been standardized,implemented and deployed for some years in IP/MPLSnetworks. For MPLS-TP, new extensions have beenstandardized to support the use of the GACH, intro-duce support for static LSP and PW, and introduce anon-IP encapsulation option. These new extensions aredefined in draft-ietf-mpls-tp-on-demand-cv.

In all test scenarios Cisco executed LSP ping and trac-eroute commands from both ends of the MPLS-TPdomain using both the CLI, and Cisco Prime Networkmanagement solution. Both functions were executedon working and protection paths in active and standbystate. In the case of an emulated link failure, asdescribed later in this report, LSP Ping was re-executedto show that the tool was unable to reach the remotepeer as planned, and LSP Traceroute was used toverify that the correct number of hops responded, andthe Traceroute was interrupted where expected. LSPPing and Traceroute commands were also executedwithin the IP/MPLS domain.

Fault Management

Fault Management defines new OAM extensions toautomatically indicate a disruption on a link or nodealong the path to an MPLS-TP LSP end point. Theseindications are important to suppress alarms and toactivate protection and are being defined as part ofdraft-ietf-mpls-tp-fault. In a traditional IP/MPLS network,the control plane typically signals such disruptions.

Cisco demonstrated two different fault managementtools, Link Down Indication (LDI) and Locked Report(LKR). LDI is sent, as the name indicates, when a linkwithin the MPLS-TP network is disrupted. On the otherhand, LKR is generated when a link along the path isadministratively shut down. Both are actions of a mid-point (or Label Switched Router / LSR) within thenetwork, which signals the respective case to the endpoint which could not otherwise immediately notice

the failure before further alarms occur (alarm suppres-sion).

In order to verify that the devices are able to correctlysignal link down, we disrupted the link between themid-point and the impairment device (sitting betweenthe mid-point and the node interconnecting the twodomains) and verified that a) the network switchedover and made the backup path the active path, andb) the appropriate (LDI) status was shown on the MPLS-TP ingress. In the case of LKR, we administratively shutdown the same link and similarly verified that a) theexpected LSP switchover occurred, and b) the appro-priate (LKR) status was displayed on the LSP end point.

Continuity Check (CC) and Remote Defect Indication (RDI)

Bidirectional Fault Detection (BFD), originally standard-ized across several RFCs as a protocol used to monitorIP network services bidirectionally at potentially highfrequencies, was reused in the IETF to standardize theContinuity Check (CC) requirement to pro-activelymonitoring MPLS-TP LSPs. These extensions are speci-fied under draft-ietf-mpls-tp-cc-cv-rdi.

Just as in other technologies with an RDI feature likeSONET/SDH or Ethernet Connectivity Fault Manage-ment (CFM), MPLS-TP includes an RDI function so anLSP endpoint can signal a locally detected defect tothe remote endpoint. For MPLS-TP, the existing BFDdiagnostic field performs the RDI function as defined indraft-ietf-mpls-tp-cc-cv-rdi. We tested this function byblocking traffic from the node interconnecting thedomains towards the downstream direction on theprimary path. This unidirectional failure caused thenode which stopped receiving BFD packets to indicatea local timer expired event in its sent BFD packet. Thepeer in turn switched over to the backup path, andreflected the RDI in the CLI. Additionally, an alarm wasraised on Cisco Prime Network, which reflected theswitchover as well.

Protection Switching

Linear protection is an important requirement for trans-port networks. Cisco demonstrated 1:1 protection withrevertive behavior, manual switchover and multipletrigger mechanisms using BFD as a continuity checkmechanism.

In our protection tests, Cisco configured redundantLSPs with unique physical paths, and enabled BFD tomonitor each of them. We used an impairment gener-ator to disrupt the forwarding plane without affecting

EANTC TEST REPORT: Cisco MPLS-TP Architecture Test --- Page 4 of 6

the physical link. This methodology, albeit morecomplex than traditional failure scenarios, ensuredthat the loss of BFD would be the reason for thenetwork to detect an issue on the forwarding planeand switch traffic to the backup LSP. Three kinds offailure scenarios were emulated, unidirectional failuresin each direction, and bidirectional failure. In all casesphysical Ethernet link remained intact.

Figure 4: Tested Failure Scenarios

In order to measure the time taken for the network torecognize the failure, and switch traffic to the backuppath, we sent bidirectional traffic using a traffic gener-ator connected at each end of the network as shown inFigure 4. We used the amount of traffic loss observedto calculate the out of service time. For simplicity weused a rate of 1,000 packets per second, with a framesize of 128 bytes. This meant that the loss of 1 frametranslated to 1 ms of service interruption.

Figure 5: Link Protection Results1

All traffic was VLAN tagged, with no IP header config-ured on the emulator. We expected the out of servicetime to be somewhere between two and three timesthe BFD CC interval, since all devices were configuredto failover to the backup path once three ContinuityCheck (CC) messages were not received (the time-outwas set to three missing packets). One would noticethat the results between the two scenarios vary, but thisis explained by the different speeds supported by thedifferent devices. The ASR 9010 and the CPT 600

MPLS-TP Network

Working LSP Protection LSP

Packet Network Ethernet Link

Traffic Generator ImpairmentTool

CiscoCPT600

CiscoASR9010

Cisco7606

Cisco7604

CiscoASR9006

Cisco7606

Cisco7604

CiscoCPT600

CiscoASR9010

CiscoASR9006

Emulated failure(upstream, downstream,and bidirectional)

1.Figure 5 shows out of service times measured during failure events. All restoration events experienced no packet loss. In the case of Scenario B, Cisco later demonstrated an updated CC implementation on the 7604 which supported a message interval of 10 ms and resulted in sub-50 ms out of

service times.

Scenario B

Scenario A

Out

of

Serv

ice

Tim

e(m

s)O

ut

of

Serv

ice

Tim

e(m

s)

EANTC TEST REPORT: Cisco MPLS-TP Architecture Test --- Page 5 of 6

were configured with a CC interval of 15 milliseconds(ms) while the 7604 was configured with a CCinterval of 50 ms.

Reversion was enabled for all protection tests asdefined in draft-ietf-mpls-tp-survive-fwk. Traffic wasredirected back to the original working LSP once theinitial switchover trigger disappeared (e.g. faultaffecting the working LSP). A wait-to-restore timer wasconfigured such that the working LSP had to remain upfor a period of time before the protection LSP transi-tioned to standby state and the working LSP transi-tioned to active state. This mechanism prevents exces-sive switchovers between the working and protectionLSP that would result in additional traffic loss due to anintermittent fault. For all protection tests, no packet losswas experience during reversion.

Figure 6: Cisco Prime Network - Reporting LSP Lockout

In addition, we verified manual switchover initiatedfrom Cisco Prime Network. This switchover was initi-ated using a "lock-out" function on the working LSPfrom one end point. Cisco Prime Network displayedthe working LSP as locked and the protection LSP asactive after the switchover, with a color codingscheme. After the lock was removed, traffic wasrestored to the working LSP with the same revertivebehavior described above. No packet loss was experi-enced on manual switchovers when the lock was intro-duced or removed.

End-to-end Pseudowire Status Notification

In IP/MPLS networks, LDP is typically used to signalpseudowires as defined in RFC 4447. End points canuse LDP Notification messages to exchange status

information for pseudowires and the attachmentcircuits. When a pseudowire endpoint receives a“down” status notification from the remote end point, itcan perform different actions including disabling thelocal attachment circuit, propagating the failure notifi-cation on the local attachment circuit, or switching to astandby pseudowire.

In our tests, Cisco demonstrated the use of the pseu-dowire status notification across the MPLS-TP domainin addition to the IP/MPLS domains. Due to the staticnature of the pseudowire segment in the MPLS-TPnetwork, the status notification was sent using theGACh as defined in draft-ietf-pwe3-static-pw-status. Inthe IP/MPLS network, the LDP status notificationmessage was used. In both test scenarios, the ProviderEdge (PE) nodes tore down the links connected to thetraffic generators, which emulated the customer, andwatch the multi-segment pseudowire come down onesegment at a time on Cisco Prime Network. Figure 7shows the topology in an orange state since the pseu-dowire was taken down (the green backup is stillgreen) behind the window logging the specific alarms.

Figure 7: Cisco Prime Network - Pseudowire Status Notification

Cisco demonstrated different alternatives in the use ofthe pseudowire control word. Operators can use thisfield to carry Layer-2 flags for ATM and Frame Relay,to enable specific pseudowire OAM modes, or toensure in-order delivery of frames. In our tests,“Scenario A” did not use of the control word while“Scenario B” did. Pseudowire status notification wastested in both scenarios. The lack of use of the controlword on scenario A did not have any negative impacton the other functions which were verified anddescribed in this report.

EANTC TEST REPORT: Cisco MPLS-TP Architecture Test --- Page 6 of 6

Summary

Cisco‘s MPLS Transport Profile implementation,coupled with Cisco Prime Network demonstrated arobust solution aimed at service providers looking tomove into Ethernet based connection-oriented trans-port solution. Using Cisco Prime Network we wereable to visualize transport services and display failureevents to using a graphical user interface. For MPLS-TPservices these management capabilities are critical fordelivering high-quality services.

We verified that the MPLS-TP tool-kit provided by Ciscois mature, standard based and robust. An operatorused to transport network would be glad to find thetools he is used to seeing in Cisco‘s MPLS-TP solution.

For more information on the products tested:Cisco ASR 9000http://www.cisco.com/en/US/products/ps9853/index.html

Cisco 7600http://www.cisco.com/en/US/products/hw/routers/ps368/index.html

Cisco CPT 600http://www.cisco.com/en/US/products/ps11348/index.html

Cisco Prime Networkhttp://www.cisco.com/go/prime

About EANTC

The European AdvancedNetworking Test Center(EANTC) offers vendor-neutralnetwork test services for manu-facturers, service providers andenterprise customers. Primarybusiness areas include interop-erability, conformance andperformance testing for IP,MPLS, Mobile Backhaul, VoIP,

Carrier Ethernet, Triple Play, and IP applications.

EANTC AG, Einsteinufer 17, 10587 Berlin, Germanyinfo@eantc.com, http://www.eantc.com/V1.0 20110426