Testing MPLS-TP Deployments in the Mobile Backhaul Whitepaper
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?
- How it works
- Why is it important to test MPLS-TP?
Download the white paper now.
TESTING MPLS-TP DEPLOYMENTS IN THE
MOBILE BACKHAUL
June 2011
Rev. A 06/11
SPIRENT
1325 Borregas Avenue
Sunnyvale, CA 94089 USA
Email: sales@spirent.com
Web: www.spirent.com
AMERICAS 1-800-SPIRENT • +1-818-676-2683 • sales@spirent.com
EUROPE AND THE MIDDLE EAST +44 (0) 1293 767979 • emeainfo@spirent.com
ASIA AND THE PACIFIC +86-10-8518-2539 • salesasia@spirent.com
© 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
SPIRENT WHITE PAPER • i
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
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
Testing MPLS-TP Deployments in the Mobile Backhaul
1 • SPIRENT WHITE PAPER
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 it’s mostly all packets, all the time, but we’re 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.
Testing MPLS-TP Deployments in the Mobile Backhaul
SPIRENT WHITE PAPER • 2
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-to-
end 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
MPL S -T P.
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.
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.
Acronyms of Interest
ACH: Associated Channel Header
G-ACh: Generic Associated Channel
GAL: G-ACh Label
Testing MPLS-TP Deployments in the Mobile Backhaul
3 • SPIRENT WHITE PAPER
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.
Testing MPLS-TP Deployments in the Mobile Backhaul
SPIRENT WHITE PAPER • 4
Several levels of recovery are defined.
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 don’t 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 MPLS-
TP 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.
RECOVERY LEVEL DESCRIPTION
Dedicated Protection Resources for the recovery entity are pre-assigned for the sole use of the protected
transport path (1:1 protection)
Shared Protection Resources for the recovery entities of several services are shared (1:N protection)
Reversion Traffic is directed back to the original LSP after the impairment is resolved.
Testing MPLS-TP Deployments in the Mobile Backhaul
5 • SPIRENT WHITE PAPER
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.
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 DUT’s 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.
Provider #2
MPLS-TP Domain
MS-PW-Seg1
Provider #1
MPLS-TP Domain
MS-PW-Seg2
DUT 1
Test Port 1Test Port 2
Cell-site device
Static PW Static PW
stitching
LDP signaled PW
S-PES-PE
Figure 1. Testing IP/MPLS and MPLS-TP interoperability
DUT 1
PE PE CEP
Test Port 1 Test Port 2DUT 2
3G/4G
Base
station
Cell site
Cell site
3G/4G
Base
station
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
Testing MPLS-TP Deployments in the Mobile Backhaul
SPIRENT WHITE PAPER • 6
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 don’t 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.
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
DUT’s 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 DUT’s 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 MPLS-
TP protocols. It is committed to keeping up with the MPLS-TP advances in the IETF and the
roadmaps of key network equipment manufacturers.
DUT
PE PEP
Test Port 1 Test Port 2DUT
3G/4G
Base
station
Cell site
Cell site
3G/4G
Base
station
G-ACH PSC messages
Working LSP
Protection LSP
Figure 3. Testing MPLS-TP Linear protection
Testing MPLS-TP Deployments in the Mobile Backhaul
7 • SPIRENT WHITE PAPER
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
