TESTING MPLS-TP DEPLOYMENTS IN THE MOBILE BACKHAUL

June 2011

Rev. A 06/11

SPIRENT
1325 Borregas Avenue Sunnyvale, CA 94089 USA Email: Web: [email protected] www.spirent.com

AMERICAS 1-800-SPIRENT +1-818-676-2683 [email protected] EUROPE AND THE MIDDLE EAST +44 (0) 1293 767979 [email protected] ASIA AND THE PACIFIC +86-10-8518-2539 [email protected]

2011 Spirent. All Rights Reserved. All of the company names and/or brand names and/or product names referred to in this document, in particular, the name Spirent and its logo device, are either registered trademarks or trademarks of Spirent plc and its subsidiaries, pending registration in accordance with relevant national laws. All other registered trademarks or trademarks are the property of their respective owners. The information contained in this document is subject to change without notice and does not represent a commitment on the part of Spirent. The information in this document is believed to be accurate and reliable; however, Spirent assumes no responsibility or liability for any errors or inaccuracies that may appear in the document.

Testing MPLS-TP Deployments in the Mobile Backhaul

CONTENTS
Executive Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Why MPLS-TP? Why Now? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 The problem with TDM and SONET/SDH transport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 MPLS-TP: The best of both worlds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 MPLS-TP supports both static and dynamically signaled connections . . . . . . . . . . . . . . . . . . . 3 MPLS-TP OAM procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 MPLS-TP protection switching and restoration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Why is it important to test MPLS-TP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Testing IP/MPLS & MPLS-TP Interoperability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Testing OAM procedures and fault detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Testing MPLS-TP Protection Switching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

LIST OF FIGURES
Figure 1. Testing IP/MPLS and MPLS-TP interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Figure 2. Testing MPLS-TP OAM procedures and fault detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Figure 3. Testing MPLS-TP Linear protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

SPIRENT WHITE PAPER i

Testing MPLS-TP Deployments in the Mobile Backhaul

EXECUTIVE OVERVIEW
The trends have been clear for some time the growth of IP and mobile data traffic, low-cost Ethernet ports, the revenue shift from voice to data and the packet video explosion. Network convergence, a topic of conversation for over two decades, is finally a reality. Or is it? True, these days its mostly all packets, all the time, but were still shy of the finish line. Most voice, mobile data and video are now inside packets, but in many cases, they are still running over TDM transport, such as SDH, SONET or OTN. Taking the last step means clearing away a few hurdles. The most recent focus of this convergence is the effort to bring the strengths of legacy transport networks to the new packet world. Things like path-level monitoring and fault detection, simple provisioning, fast protection switching, and robust timing and synchronization. And the solution in the spotlight is MPLS Transport Profile (MPLS-TP), a joint effort of the ITU-T and the IETF to simplify an existing label-switching protocol to address those capabilities. This white paper explores why MPLS-TP is now emerging at this stage in the convergence journey, the applicability of MPLS-TP in the mobile backhaul and access networks and the importance of testing new MPLS-TP deployments.

WHY MPLS-TP? WHY NOW?

In 2011, after years of joint development between the ITU-T and IETF, MPLS-TP has emerged as the technology of choice for next-generation transport networks and is being put to the test in multi-vendor interoperability trials. Why is a transport protocol the focus of attention at this stage in the converged network game?

The problem with TDM and SONET/SDH transport

The current TDM transport has a lot going for it. It provides operators the ability to provision bi-directional connections with guaranteed bandwidth, supports OAM procedures and enforces service level agreements (SLAs). However, the disadvantages far outweigh the advantages. Driven by smartphones and new services, global mobile data traffic nearly tripled in 2010 and global IP traffic will quadruple between 2009 and 2014. Such a dramatic increase in mobile backhaul traffic is stretching the traditional TDM transport beyond its capabilities. The T1/E1 and SONET/SDH circuits are not only inefficient for transporting packet based traffic, they are also significantly more expensive (per-port and per-bit) than packet based alternatives such as Ethernet. Persisting with TDM is untenable for operators, in the long run. The answer was to define a set of protocols and procedures that inherit all the efficiencies of the packet networks and at the same time can be extended to meet the OAM requirements of the transport world.

SPIRENT WHITE PAPER

Testing MPLS-TP Deployments in the Mobile Backhaul

MPLS-TP: The best of both worlds

MPLS has been running over Ethernet for over a decade. It is a creature of the packet network, designed to optimize packet transport through tunnels via label switching. There was no question that it would work well in a packet-based environment. In addition, MPLS was designed to set up end-to-end circuits in large-scale networks. It knew about discovering and recovering from path failure. It knew about QoS. It was already a good way down the path to the requirements it would need to satisfy. And, perhaps best of all, MPLS is a mature, standards-based technology deployed in almost every service provider network worldwide. Adapting it for use in the transport network meant developing a simplified version of IP/MPLS--a subset of the existing capabilities-- and tuning it to support some additional capabilities. What are the needed additional capabilities? MPLS had to be enhanced to support static provisioning, in-band OAM, fault detection and switchover to backup path within 50 ms, and a network management system (NMS) interface to configure and manage the network. By adapting MPLS to handle the special needs of transport networks, designers ensured seamless integration between layers in existing production networks, making possible a single end-toend OAM architecture across the OSI model. The work actually began in the ITU in Study Group 15 under the project name T-MPLS and in 2008 the IEFT joined forces with the ITU and took the lead. In the IETF, the project was renamed MPLS-TP.

HOW IT WORKS
RFC 5654 defines 115 requirements for MPLS-TP in the areas of layering, data plane, control plane, recovery and QoS. It also references requirements for network management, OAM, performance monitoring and security in other documents. This document specifies the required behavior, not a required implementation.
Acronyms of Interest ACH: Associated Channel Header G-ACh: Generic Associated Channel GAL: G-ACh Label

The most basic element for implementing MPLS-TP is use of the associated channel header (ACH), previously limited to pseudowires, to create a generic associated channel (G-ACh) by assigning one of the reserved MPLS label values (13) to the generic associated channel label (GAL), as defined in RFC 5586. The G-ACh does not carry user traffic. RFC 5586 generalizes the ACH to apply to LSPs and sections to create a label-based exception mechanism to address the requirements in RFC 5654 for transport-network performance monitoring, automatic protection switching, and support for management and signaling communication channels. It is an in-band management channel on a PW or LSP that does not rely on routing, user traffic, or dynamic control plane functions.

SPIRENT WHITE PAPER

Testing MPLS-TP Deployments in the Mobile Backhaul

The GAL provides an alert-based exception mechanism to differentiate G-ACh packets from others, such as user-plane packets, and to indicate that the ACH appears immediately after the bottom of the label stack. The GAL is used only where both these purposes apply. For LSPs, the GAL is at the bottom of the label stack and identifies the packet as belonging to the G-Ach. For PWs, the PWE3 control word, as defined in RFC 4385, is used to identify a packet belonging to the G-ACh with a value of 1 in the first four bits. The first 32 bits following the bottom of the stack label carries the GAL.

MPLS-TP supports both static and dynamically signaled connections

MPLS-TP can operate in two modes: Through a network management system for static provisioning of primary and backup connections with fast protection switching. Provisioning a static MPLS-TP connection typically involves selecting the port and VLAN (if interface is Ethernet) and manually assigning incoming and outgoing labels for the connection. This action is independently performed on both ends of the connection. Through a GMPLS control plane for dynamic provisioning of primary and recovery paths with fast reroute. To meet transport-network compatibility requirements, MPLS-TP restricts LSPs to bidirectional paths that are co-routed, meaning both directions follow the same path.

MPLS-TP OAM procedures

MPLS-TP provides mechanisms to support in-band OAM functions such as continuity check, connectivity verification, loss measurement, delay measurement, remote defect indication and alarm indication signal. Like legacy transport networks, these mechanisms allows for fault localization, performance monitoring, remote indications and alarm suppression. Rather than define new OAM protocols, the MPLS-TP IETF drafts specify mechanisms (via G-Al/ G-Ach) to reuse traditional MPLS and Carrier Ethernet OAM procedures such as BFD and Y.1731. The BFD and Y.1731 procedures can be used to monitor LSPs, Sections, or PWs. In addition, recent IETF drafts also define Fault OAMs (AIS, RDI and LKR) for signal failure detection, propagation of the signal fail condition across layers and for alarm suppression.

MPLS-TP protection switching and restoration

An operator typically provisions the primary and backup paths (LSPs) of an MPLS-TP connection, statically. OAM protocols running at either end of the MPLS-TP connection monitor its liveliness and quickly detect the presence of faults. Upon loss of connectivity or fault detection, both ends of the MPLS-TP connection switchover to the backup LSP (independently or coordinated by a per-hop-behavior scheduling class) and bi-directional traffic is exchanged on the backup LSP as soon as the switchover is complete. The high frequency of the OAM heartbeats (for example, BFD messages are exchanged as frequently as once every 3.3 ms) ensures failure detection within 10-15 ms and switchover within 50 ms.

SPIRENT WHITE PAPER

Testing MPLS-TP Deployments in the Mobile Backhaul

Several levels of recovery are defined.

RECOVERY LEVEL Dedicated Protection Shared Protection Reversion DESCRIPTION Resources for the recovery entity are pre-assigned for the sole use of the protected transport path (1:1 protection) Resources for the recovery entities of several services are shared (1:N protection) Traffic is directed back to the original LSP after the impairment is resolved.

WHY IS IT IMPORTANT TO TEST MPLS-TP?

NEMs from all over the world have been racing to incorporate MPLS-TP functionality in their devices and to keep up with the rapidly evolving IETF drafts and RFCs. For service providers, it is not a matter of if, but when, they will replace the aging TDM backhaul with MPLS-TP based Ethernet backhaul. The pace of deployment of MPLS-TP will ultimately depend on the reliability and completeness of the MPLS-TP implementations. Without TDM-like reliability, service providers will not risk the migration to MPLS-TP and will not risk customer churn owing to quality issues. Establishing the reliability and completeness of an MPLS-TP implementation can only be accomplished by thorough testing of the following aspects of MPLS-TP: 1. IP/MPLS and MPLS-TP interoperability a. Static provisioning of PW in MPLS-TP domain and LDP signaled PW in IP/MPLS domain b. Forwarding across MS-PW 2. OAM procedures and fault detection 3. Protection switching

Testing IP/MPLS & MPLS-TP Interoperability

MPLS-TP networks dont exist in a vacuum. One of the most crucial tests for MPLS-TP is interoperability with widely deployed IP/MPLS networks. A typical mobile backhaul scenario is shown in the diagram below, where a router speaks IP/MPLS on one side to the core and MPLSTP on the other side to the access/cell site. On such routers, it is important to verify the ability to a) create LDP signaled PWs on the core facing port, b) create static PWs on cell-site facing port, c) stitch together a multi-segment pseudowire containing the signaled and the static components, d) forward traffic and BFD based OAM end-to-end and e) perform all of the above steps for thousands on PWs on a single port. In the scenario described in Figure 1, Spirent TestCenter Port 2 emulates a cell site serving thousands of subscribers and all the L2-L7 traffic originating from those subscribers. Spirent TestCenter Port 1 emulates the edge/core network and the associated control and data plane traffic. Both of the Spirent ports create thousands of PWs (either MPLS-TP based or IP/LDP based) with the DUT (S-PE router) and exchange traffic with each other via the DUT. Using such a configuration, the DUT can be completely tested for its ability to support static MPLS-TP connections and all aspects of IP/MPLS & MPLS-TP interoperability.

SPIRENT WHITE PAPER

Testing MPLS-TP Deployments in the Mobile Backhaul

Test Port 2

Provider #2 MPLS-TP Domain MS-PW-Seg1

DUT 1

Provider #1 MPLS-TP Domain MS-PW-Seg2

Test Port 1

Cell-site device

S-PE

S-PE

Static PW
Figure 1. Testing IP/MPLS and MPLS-TP interoperability

Static PW stitching

LDP signaled PW

Testing OAM procedures and fault detection

Another step toward attaining TDM-like reliability is for MPLS-TP enabled routers to support OAM procedures. It is imperative for NEMs to ensure that MPLS-TP enabled routers are capable of detecting continuity and connectivity verification failures. A good MPLS-TP implementation not only detects such failures, but does so quickly by using OAM heartbeat frequencies of 3.3 ms. Signal failures should also be detected as soon as they occur and should be propagated by the appropriate Fault OAM (AIS/LKR/RDI) mechanisms.

Cell site 3G/4G Base station Cell site 3G/4G Base station

Test Port 1

DUT 1

DUT 2

Test Port 2

PE

PE

CE

BFD/LSP Ping over G-Ach for LSP BFD/LSP Ping over G-Ach for PW
Figure 2. Testing MPLS-TP OAM procedures and fault detection

In the scenario described in Figure 2, Spirent TestCenter Port 1 emulates a Provider Edge router serving hundreds of cell sites and another Spirent TestCenter port emulates the core network. Thousands of LSPs and PWs are created between Spirent Port 1 and a DUT (PE router) and BFD/ LSP Ping are enabled on these connections. Spirent TestCenter verifies the DUTs compliance with BFD/LSP Ping OAM procedures and its abilities to quickly and correctly detect connectivity failures. Compliance with Fault OAM procedures is also tested. In addition, Spirent TestCenter brings realism to testing by hitting the DUT with line-rate L2-L7 traffic originating from thousands of hosts/endpoints behind the emulated cell-sites.

SPIRENT WHITE PAPER

Testing MPLS-TP Deployments in the Mobile Backhaul

Testing MPLS-TP Protection Switching

The litmus test for an MPLS-TP deployment will be the ability to switch over to a backup path within 50 ms of the occurrence of a failure condition in the primary path. Such a quick switchover is necessary to ensure that end customers dont suffer from dropped mobile calls and poor quality of experience. Failure conditions can be triggered by loss of continuity, signal failure or by manual action at either end of a connection.
G-ACH PSC messages
Cell site 3G/4G Base station Cell site 3G/4G Base station

Test Port 1

DUT

DUT

Test Port 2

PE

P
Working LSP Protection LSP

PE

Figure 3. Testing MPLS-TP Linear protection

In the scenario depicted in Figure 3, Spirent TestCenter Port 1 emulates a PE router and creates thousands of primary and backup LSP connections with a DUT PE router. Spirent triggers LSP switchover (manual, by injecting signal failure, or by causing loss of continuity) and tests the DUTs ability to detect the failure conditions and switch over traffic to the backup path. The test is performed simultaneously on hundreds of LSPs to verify the DUTs ability to perform the switchover under high scale and stress conditions.

CONCLUSION
MPLS-TP builds on the highly successful and widely adopted IP/MPLS and makes it even stronger by enhancing its OAM capabilities. The MPLS-TP enhancements will allow service providers to provision and monitor their packet-based backhaul in a TDM-like fashion. Spirent is committed to addressing the testing requirements of the mobile backhaul, with an emphasis on MPLS-TP and timing and synchronization. Spirent already provides comprehensive support for the various IP/MPLS protocols and a number of the IETF standardized MPLSTP protocols. It is committed to keeping up with the MPLS-TP advances in the IETF and the roadmaps of key network equipment manufacturers.

SPIRENT WHITE PAPER

Testing MPLS-TP Deployments in the Mobile Backhaul

REFERENCES
RFC 5654 Requirements of an MPLS Transport Profile RFC 5860 Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks RFC 5921 A Framework for MPLS in Transport Networks draft-ietf-mpls-tp-oam-framework-10 Operations, Administration and Maintenance Framework for MPLS-based Transport Networks RFC 5586 MPLS Generic Associated Channel draft-ietf-mpls-tp-ach-tlv-02 Definition of ACH TLV Structure draft-bhh-mpls-tp-oam-y1731-06 MPLS-TP OAM based on Y.1731 draft-ietf-mpls-tp-lsp-ping-bfd-procedures-01 LSP-Ping and BFD encapsulation over ACH draft-ietf-mpls-tp-cc-cv-rdi-02 Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile draft-ietf-mpls-tp-on-demand-cv-01 MPLS On-demand Connectivity Verification and Route Tracing draft-ietf-mpls-tp-fault-03 MPLS Fault Management OAM draft-ietf-mpls-tp-identifiers-03 MPLS-TP Identifiers

SPIRENT WHITE PAPER