MPLS-TP in Next-Generation
Senior Analyst, Heavy Reading
Part of the Light Reading/Heavy Reading MPLS-TP Initiative
on behalf of
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 2
Over the past several years, technology experts at leading communications
service providers and a number of network equipment suppliers have supported
the development of an MPLS Transport Profile (MPLS-TP) that will enable the
technology to be operated in a similar manner to existing transport technologies
and give it the capability to support packet transport services with a degree of
predictability that is similar to that found in existing transport networks.
After much effort and debate among members of the IETF and ITU-T, key MPLS-TP
standard pillars are largely complete, and the MPLS-TP ecosystem is beginning to
take shape. Multiple network equipment providers are in the process of testing,
trialing and beginning early deployments of standards-based MPLS-TP solutions
that make use of new MPLS-based operations, administration and maintenance
(OAM) tools. Sophisticated test and measurement solutions designed to demon-
strate that MPLS-TP is a viable and compelling technology are now available and
have been used in public interoperability tests and demonstrations.
Heavy Reading survey feedback from a large number of industry professionals
indicates that many believe MPLS-TP is poised to impact the way converged
networks are built in coming years. Two thirds of 183 service provider, vendor and
other professionals stated that they expect to see significant, strategic deploy-
ment of MPLS-TP in multiple carrier networks by the end of 2013. And feedback
from 271 professionals indicates that many consider the properties of MPLS-TP well
suited for deployment across backbone/core, metro and access networks.
Several initial applications in which MPLS-TP is likely to be deployed include: (1)
backhaul of mobile traffic over a packet network infrastructure; (2) SDH/Sonet
migration to packet transport; and (3) dynamic MPLS-TP over OTN/DWDM.
This white paper is part of Light Reading/Heavy Reading's 2011 MPLS-TP Industry
Initiative Program that includes ongoing editorial coverage of MPLS-TP related
topics, an MPLS-TP webinar and LRTV video on the MPLS-TP topic. The MPLS-TP
Briefing Center on Light Reading includes this and other important material.
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 3
Many service providers worldwide are looking for solutions that will optimize MPLS
for transport, simplify operations and management of packet-based networks,
and pave the way for more cost-effective extension of MPLS functionality into the
MPLS has already been playing an important role in transport networks, but
experts at a number of equipment suppliers and operators – including AT&T, Bharti
Airtel, BT, Comcast, NTT, Verizon, XO and others – recognize that not all of MPLS's
capabilities are needed in, or are consistent with, transport networks. They gener-
ally believe cost savings can be achieved by deploying a solution that is strictly
connection-oriented and does not rely on IP routing. These vendors and operators
have supported development of the MPLS Transport Profile (MPLS-TP) protocol that
the IETF and ITU-T Joint Working Team (JWT) has worked on since 2008.
After much effort and debate among IETF and ITU-T members, the core elements
of the MPLS-TP standard are largely complete. While a few hurdles remain to be
overcome, we can say with increasing confidence that the era of standardized
MPLS-TP technology is beginning to emerge and is poised to impact the way
converged networks are built in coming years.
The first half of this white paper identifies the key drivers and objectives for the
development of MPLS-TP technology; examines how the MPLS-TP ecosystem is
taking shape; and discusses MPLS-TP deployment expectations and potential
applications. In the ecosystem section, we describe the major components of
MPLS-TP; spotlight important standards-related developments; share examples of
the types of network equipment being developed to support the emerging MPLS-
TP standards; highlight new MPLS-TP test and measurement solutions; and summar-
ize key test and demonstration activity. We also include feedback from industry
professionals regarding the expected pace of MPLS-TP adoption and explore
some initial applications for which standardized MPLS-TP is likely to be deployed.
The second half of this paper includes two-page perspectives on MPLS-TP tech-
nology provided by Cisco, ECI, Ericsson, Ixia and Metaswitch.
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 4
MPLS-TP Key Drivers & Objectives
This section provides a brief summary of the primary drivers for carrier interest in
MPLS-TP technology and the key objectives spelled out by industry professionals
working on the standard.
Service providers have expressed interest in MPLS-TP primarily because they are
looking to control the costs of transporting packets that are increasingly dominat-
ing their traffic mix and – in many cases – are currently being carried inefficiently
over legacy Sonet/SDH networks that run at constant bit rates even when there is
no traffic. As Verizon, Ericsson and others have noted, operators seek, among
other things, to (1) replace TDM devices that are approaching end-of-life status;
(2) consolidate multiple networks onto a common MPLS-based infrastructure with
quality of service capabilities that deliver predictable behavior, control, resiliency
and scalability; (3) take advantage of more flexible data rates and statistical
multiplexing efficiencies enabled by packet technology; and (4) support fast-
growing packet/IP-based video, mobile broadband, VPN, cloud virtualization and
other new services at lower cost.
The ability to support multiple services and applications over a common MPLS-
enabled infrastructure provides flexibility to more rapidly add new offerings and to
cost-effectively scale with demand over time. While IP/MPLS is widely deployed in
carrier networks and has rich multiservice and scalability features, it generally
offers more than what is needed for transport application. Until recently, MPLS also
has lacked some important OAM capabilities familiar to the transport environ-
ment. Major operators have encouraged development of a transport-oriented
version of MPLS with a rich set of OAM features to complement IP/MPLS deployed
in their networks.
Figure 1: Shift Toward Converged MPLS/MPLS-TP Based Infrastructure
Source: Ixia, Cisco, Verizon MPLS-TP Webinar, April 2011
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 5
As noted in the IETF RFC 5921 MPLS-TP Architecture Framework document (July
2010), the primary objectives for the development of MPLS-TP are (1) to enable
MPLS to be deployed in a transport network and operated in a similar manner to
existing transport technologies; and (2) to enable MPLS to support packet trans-
port services with a similar degree of predictability to that found in existing
The idea here is to incorporate MPLS-TP functionality on carrier Ethernet
switch/routers, service edge routers, packet optical transport systems, access
platforms and other devices and to give operators the option to deploy MPLS-TP
anywhere in core, metro/aggregation and access networks. Ultimately, a key goal
is to provide a unified MPLS-based solution with end-to-end OAM.
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 6
MPLS-TP Ecosystem Is Taking Shape
In this section, we will give an overview of the major components of MPLS-TP;
review important standards-related developments and issues; share examples of
the type of network equipment becoming available that supports the emerging
MPLS-TP standards; identify available MPLS-TP test and measurement solutions; and
highlight key test and demonstration activity related to MPLS-TP.
A year after holding its first meeting in early 2008, the JWT published IETF RFC 5317,
"MPLS Architectural Considerations for a Transport Profile." This report was based on
a JWT presentation that recommended that the IETF and the ITU-T work together
to "bring transport requirements into the IETF and extend IETF MPLS forwarding,
OAM, survivability, network management and control plane protocols to meet
those requirements through the IETF standards process."
ITU-T management accepted this recommendation. In short, the two organizations
committed to establishing a single standard that would become a fully compliant
MPLS protocol and supersede the ITU-T's earlier work on T-MPLS.
Emerging MPLS-TP technology is both a subset and an extension of MPLS. It bridges
the gap between the packet and transport worlds by combining the packet
efficiency, multiservice capabilities and carrier-grade features of MPLS with the
transport reliability and OAM tools traditionally found in Sonet/SDH.
Figure 2: MPLS-TP Ecosystem Developments
ECOSYSTEM ELEMENTS IMPORTANT DEVELOPMENTS
MPLS-TP Overview &
The IETF has published about a dozen Request for Comment (RFC)
documents related to MPLS-TP since the JWT was established in
2008. The core part of the standard is nearly complete, and more
Working Group documents are in the RFC editor's queue.
Multiple vendors have introduced – or plan to introduce in the
near term – network equipment that is designed to be based on
the MPLS-TP standards supported by both the IETF and ITU-T.
Test & Measurement
Suppliers have introduced testing solutions designed to validate
functional specifications for developing MPLS-TP standards, multi-
vendor interoperability, MPLS and MPLS-TP interworking, and
performance (such as <50 ms failover).
Tests & Demonstra-
Multiple MPLS-TP tests and demonstrations have been conducted
with platforms using MPLS-based OAM. Tests have included
interworking of MPLS-TP and MPLS.
Trial & Early Deploy-
Industry feedback suggests customer trial and initial deployment
activity will ramp toward the end of 2011 and take place
Sources: IEEE, service providers, network equipment providers, and test & measurement
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 7
MPLS-TP leverages and builds upon existing MPLS forwarding, MPLS-based pseu-
dowires and dynamic Generalized MPLS (GMPLS) control plane technology
(optional in the MPLS-TP standard), and extends this with in-band active and
reactive OAM enhancements, deterministic path protection and network man-
agement-based static provisioning. To strengthen transport and management
functionality, MPLS-TP excludes certain functions of IP/MPLS, such as LSP merge,
Penultimate Hop Popping (PHP) and Equal Cost Multi Path (ECMP).
MPLS-TP is designed to interoperate with existing IP/MPLS-based networks so that
carriers can take advantage of previous infrastructure investments and avoid
forklift upgrades as they adopt the new technology.
MPLS-TP Standards Development
In addition to RFC 5317 that outlined the general approach for developing the
MPLS-TP standard, the IETF has approved 10+ requirement and framework RFCs for
MPLS-TP and has many more working group documents in the editor's queue or in
Figure 4 highlights important IETF documents, and Figure 5 shares the basic
framework for MPLS-TP.
Figure 3: Major Attributes of MPLS-TP
Source: Based on MPLS-TP RFCs and comments from Cisco, ECI, Ericsson, and Metaswitch
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 8
Figure 4: Key MPLS-TP Requirement & Framework Standards Documents
This RFC identifies more than 100 feature requirements for MPLS-TP. Among other things,
it states that MPLS-TP must:
· Support a transport-centric operational model that permits static configuration of
LSPs and pseudowires via the network management plane and not solely via a con-
trol (routing/signaling) plane – although dynamic provisioning of transport paths via
a control plan remains an option and must be supported within the standard.
· Enable protection switching to be triggered by OAM and not be dependent on
dynamic signaling or control plane liveliness. This reliability feature ensures that exist-
ing circuits will continue to work if an operator has an outage in the control plane.
· Support 1+1 protection and 1:n protection, with <50 ms restoration.
· Support transport-optimized OAM.
· Engineer traffic to permit deterministic control of the use of network resources.
· Enable MPLS-TP deployment in rings, as well as ring interconnection.
RFC 5654 also states that the MPLS-TP design should reuse existing MPLS standards as far
as reasonably possible.
This RFC specifies architectural and functional requirements for OAM related to sections,
PWs, and LSPs. These functions may be used for fault management, performance
monitoring, and/or protection switching. Among other things, RFC 5860 states that:
· It must be possible to operate OAM on a per-domain basis and across multiple
· OAM packets must run in-band and share the fate of user traffic.
· It must be possible to operate OAM with or without relying on IP capabilities.
· When MPLS-TP is used with IP forwarding and routing capabilities, it must be possible
to operate existing IP/MPLS or PW protocols.
· OAM must operate and be configurable in the absence of a control plane.
This RFC specifies the set of protocol functions that meet the requirements of RFC 5654
and that constitute the transport profile for point-to-point paths. Elements include:
· A standard MPLS data plane.
· Sections, PWs, and LSPs that provide a packet transport service for a client network.
· Continuous and on-demand OAM to monitor and diagnose the MPLS-TP network.
MPLS-TP uses a generic associated channel (G-Ach) to support Fault, Configuration,
Accounting, Performance, and Security (FCAPS) functions.
· Control planes for LSPs and PWs, as well as support for static provisioning and confi-
· Path protection mechanisms and control plane-based mechanisms.
· Network management functions.
This draft supports OAM procedures that do not rely on the presence of a control plane.
It states that existing MPLS OAM will be used wherever possible, and extensions will be
defined only when available mechanisms do not meet requirements. The goal is to
have OAM functionality similar to what exists with Sonet/SDH and OTN mechanisms.
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 9
The IETF-ITU OAM Debate
Although the IETF and ITU-T have cooperated on MPLS-TP standards work, there
has been divergence of opinion among some members of these organizations
with regard to the OAM tools. This difference has created some confusion about
what is MPLS-TP, pre-standard MPLS-TP and/or something else altogether (such as
T-MPLS, which the ITU formally suspended work on in April 2008). Below is a sum-
mary of the issue and recent developments.
RFC 5654, RFC 5680 and the draft MPLS-TP OAM Framework all state that the MPLS-
TP design should reuse existing MPLS standards as far as reasonably possible. This
includes OAM standards.
As illustrated in Figure 6, the IETF has focused on developing extensions to existing
MPLS OAM tools and creating some new loss measurement, delay measurement
and fault management tools. This effort includes extending Bidirectional Forward-
ing Detection (BFD) for proactive continuity check and connectivity verification
and extending LSP Ping for on-demand connectivity verification and traceroute.
In February 2011, ITU-T Study Group 15 held internal discussions regarding two
different approaches to MPLS-TP OAM, including: (1) a specific OAM solution
targeted for adding transport network capability to existing Sonet/SDH/OTN
networks; and (2) a common OAM solution targeted primarily for adding packet
transport capability in an MPLS environment. After debate, SG15 voted to pro-
ceed with the traditional approval process for an OAM mechanism now known as
ITU-T G.8113.1 to be deployed in Sonet/SDH/OTN-related environments. G.8113.1
draws upon key elements of Y.1731 OAM used in carrier Ethernet networks.
Figure 5: MPLS-TP Framework
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 10
It is important to note is that the general use of G.8113.1 for MPLS-TP is contingent
upon being allocated a code point from the IETF. As of mid June 2011, the Internet
Assigned Numbers Authority (IANA) has not assigned a code point for G.8113.1
because there is no IETF consensus support for it. G.8113.1 currently uses an
"experimental code" point that could create interoperability problems, according
to IETF guidelines for code point usage found in RFC 3692.
According to public information from the ITU-T, "in the case where networks that
run the IETF defined solution must be interconnected with a network that runs the
ITU solution, then the IETF solution must be used." In summary, while the ITU SG15
has started the approval process for G.8113.1 OAM, it continues to support
coexistence with the IETF-backed OAM solution, which is referred to as G.8113.2
within the ITU.
Static Configuration in NMS or Dynamic Control Plane in Nodes
The emerging MPLS-TP standard includes options for either static configuration of
LSPs and PWs via a network management system or dynamic provisioning via a
control plane because both approaches offer their own advantages, depending
on specific network environments, network expansion plans, operational expertise,
cost considerations and other factors.
A key motivation for including the ability to statically configure LSPs and PWs via a
network management system is to eliminate the cost associated with having
control-plane functionality distributed and integrated into each node across an
IP/MPLS-based network when a lighter, more affordable transport-oriented option
could be used to extend basic MPLS functionality into the access arena (see
Figure 7). Shifting control complexity to a transport-grade NMS reduces the need
for metro transport network managers to become IP experts and enables a more
seamless evolution of their role in managing networks that include a large number
of MPLS-TP-enabled devices. This also syncs well with the vision of network solutions
providers that advocate the use of a converged NMS that manages all technolo-
gies from a single application.
On the other hand, a dynamic control plane can offer important benefits in terms
of resiliency, provisioning times, multi-vendor interoperability and other advantag-
Figure 6: MPLS-Based MPLS-TP OAM Tools
OAM FUNCTIONS PROACTIVE ON DEMAND
Continuity Check (CC) Extended BFD Extended LSP Ping
Connectivity Verification (CV) Extended BFD Extended LSP Ping
Alarm Signal AIS/RDI N/A
Fault Localization LDI Extended LSP Ping
Remote Integrity Extended BFD Extended LSP Ping
Loss/Delay Measurement LM and DM Tools
New Loss Measurement
and Delay Measurement
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 11
es, especially as networks grow. Metaswitch highlights some of the key potential
benefits of using a dynamic control plane in the second half of this paper.
MPLS-TP Network Equipment
Multiple network equipment suppliers currently offer or plan to offer platforms that
support the emerging MPLS-TP standards, including MPLS-based OAM. Figure 8
highlights examples of suppliers and the type of MPLS-TP platforms they are
introducing into the market in 2011.
Test Requirements for Demonstrating MPLS-TP Is Viable & Compelling
Although the major components of MPLS-TP have already been established and
published in IETF RFCs, there are still many features and functions under active
discussion and development. New additions to the MPLS-TP standard will ensue for
the next several years. Most network equipment manufacturers are still in the
process of early MPLS-TP implementation. There are two critical milestones that
must be addressed before MPLS-TP is ready for widespread adoption: proving that
MPLS-TP is a "viable" technology and proving that it is a "compelling" technology.
Figure 8: Example of Equipment Vendors Offering Platforms Supporting MPLS-TP
Cisco g g g g
ECI g g g
Ericsson g g g g
Sources: Cisco, ECI, and Ericsson
Figure 7: Static Configuration or Dynamic Control Plane?
Source: Inputs from ECI, Ericsson, and Cisco
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 12
Test and measurement suppliers have begun announcing solutions that are
designed to assist equipment vendors and operators in validating MPLS-TP tech-
nology. Ixia, for example, released a testing solution in December 2010 that works
with both MPLS-based OAM and G.8113.1 OAM and validates the MPLS-TP
capabilities discussed below.
Proving MPLS-TP Is a Viable Technology
MPLS-TP functional validation, interoperability and MPLS-TP and MPLS interworking
must be satisfied in order to prove MPLS-TP is a viable transport technology for
deployment in many networks. With 11 MPLS-TP IETF RFCs and 16 WG documents
already in progress, there is a considerable list of features and functions that must
be tested to ensure proper implementation.
Most functional testing thus far has revolved around key OAM, APS and G-Ach/
GAL encapsulation. It is equally important to demonstrate the interoperability of
MPLS-TP features and functions across different vendor implementations. Further,
interworking between MPLS-TP and MPLS must be verified to ensure the delivery of
traffic and services that will traverse both MPLS-TP and MPLS domains. A summary
of critical functional, interoperability and MPLS/MPLS-TP interworking tests that must
be addressed to demonstrate MPLS-TP viability is included in Figure 9.
Figure 9: MPLS-TP Functional & Interoperability Test Requirements
MPLS-TP FUNCTION FUNCTIONAL VERIFICATION INTEROPERABILITY
LSP & PW
Control Word (CW) inclusion
Message exchange (correct encoding and
LSP & PW
Static label assignment
Interoperability of static SS-PW and dynamic
Label space compatible
Check (CC) &
OAM message generation at various
On-demand LSP connectivity verifica-
OAM message exchange
CC/CV sessions established
Ping encoding follows G-Ach Channel Type+
Echo or G-Ach Channel Type + IP/UDP/Echo?
Generation & Fault
Alarm generation and detection
Generation of AIS/LDI/LCK/PW Status
Auto generation of RDI
Alarm encoding and interpretation
AIS suppression state
tion Switching (APS)
Ingress, Egress, and Transit Node
Different protection modes
Switchover time measurements per LSP/PW
MPLS-TP & MPLS
OAM status translation
End-to-end service verification
MS-PW (mix of MPLS-TP & IP/MPLS segments)
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 13
Proving MPLS-TP Is a Compelling Technology
Once the viability of MPLS-TP as a transport technology has been established,
service providers will seek out performance measurements that prove its ability to
deliver carrier-grade services at scale, with guaranteed SLAs and reliability. The
performance benchmarks summarized in Figure 10 will provide service providers
with critical information to accelerate investment and deployment, including:
· Comparison of MPLS-TP against legacy transport technology
· Comparison of network equipment from different vendors
· Guidelines (performance/scalability limitations) for network planning and
MPLS-TP Network Equipment Tests & Demonstrations
Over the past eight months, multiple network equipment suppliers have partici-
pated in several tests and demonstrations of the emerging MPLS-TP standard that
uses the MPLS-based OAM. These events involved routers, switches and packet
optical platforms. The test and demonstration activity is summarized below.
As MPLS-TP development progresses, we will see more vendors participating in
public interoperability tests, as well as a wider breadth of test coverage. Public,
third-party validation is critical to establish service provider confidence in the
readiness of MPLS-TP for network deployment.
Verizon Lab (3/11)
Verizon validated <50 ms failover on statically provisioned LSPs using CPT 600s from
Cisco and Ixia test equipment. The companies demonstrated various MPLS-based
OAM capabilities, including BFD enhancements for connectivity checking, link
Figure 10: MPLS-TP Performance Verification & Benchmarking
PERFORMANCE REQUIREMENT PERFORMANCE MEASUREMENT
Service Scalability Number of supported LSPs/PWs per-port, per-card, and per-system
Service Quality Number of supported service levels to meet SLAs
Forwarding performance at scale, including latency and delay variation with
various packet size including IMIX
OAM (active and on demand) and MIB support
High-scale static provisioning via NMS
High-scale dynamic provisioning via GMPLS
Testing with full set of OAM functions across tens of thousands of LSPs and PWs
while supporting performance targets
End-to-end OAM across multiple segments of an LSP or PW (where some
segments are statically configured, and others are dynamically signaled)
Reliability Protection switching for tens of thousands of LSPs at < 50ms failover
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 14
down indication (LDI), alarm indication signals and remote defect indication. The
failover speed was about 16 ms. See Figure 11.
For MPLS and Ethernet World Congress in 2011, EANTC conducted tests related to
the interworking of MPLS-TP and IP/MPLS as well as tests of MPLS-based OAM tools.
For MPLS-TP and IP/MPLS interworking, vendors used stitching within a single device
rather than a handoff between the domains. Stitching of static MPLS-TP PWs and
dynamic LDP-signaled PWs was conducted by Cisco ASR 9010 and Metaswitch
DC-MPLS devices. Cisco CPT 600, Ericsson SE 1200 and Ixia IxNetwork equipment
set up static PWs in the MPLS-TP network. EANTC noted that more standardization
work is required to make BFD-based implementations deployable in multi-vendor
environments, due to interoperability issues related to such things as BFD slow start
procedures and fault management protocols (such as LSP ping and traceroute).
EANTC noted that successful tests of BFD continuity check (CC) were conducted
with platforms from Cisco (ASR 9010, CPT 600, 7604), Ericsson (SE 1200), Metaswitch
(DC-MPLS), Ixia (IxNetwork) and Hitachi (AMN 1710). Successful route tracing tests
were conducted with the Cisco and Ericsson products. And failure propagation
testing was performed between a dynamic LDP-signaled PW stitched to a static
PW in the MPLS-TP domain, using Cisco ASR 9010, Cisco CPT 600 and Ericsson SE
Figure 11: MPLS-TP Protection Switching Demonstration – Verizon, Cisco, Ixia
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 15
EANTC also conducted successful tests on MPLS-TP LSP protection using Cisco ASR
9010, Cisco 7604, Ericsson SE 1200 and Metaswitch DC-MPLS platforms. The goal
was to verify the ability of OAM tools defined by RFC 5654 and RFC 5921 to detect
failure and ensure that the network reacts appropriately to restore connectivity.
Failover times ranged from 270 ms to 310 ms when impairments forced traffic to
revert to backup paths. Traffic was restored to primary LSP paths within <60 ms
once impairments were removed.
For MPLS 2010, Isocore hosted the first-ever multivendor standards-based MPLS-TP
interoperability tests using equipment from Cisco (ASR 9000, 7600), Ericsson
(SE1200), Ixia (XM2), Hitachi and NEC. The tests showcased the following: (1)
statically provisioned co-routed MPLS-TP label switched paths (LSPs); (2) 1:1 linear
protection of LSPs; (3) MPLS-TP OAM, which included BFD CC and LSP Ping using
associated channel header (ACH); and (4) MPLS-TP and MPLS interoperability
using pseudowire (PW) switching between static and dynamic PWs. The testing
also verified the status of an end-to-end Ethernet service delivered over MPLS-TP
and MPLS – see Figure 12.
Figure 12: MPLS 2011 – Standards-Based MPLS-TP Public Interoperability Test
Source: Isocore white paper
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 16
MPLS-TP Deployment Expectations
This section provides survey feedback from a well-attended MPLS-TP webinar
hosted by Heavy Reading in June 2011, shedding light on industry professionals'
expectations regarding MPLS-TP in different parts of the network.
Heavy Reading asked the webinar attendees when they expect to see significant,
strategic adoption of MPLS-TP in multiple carrier networks. We received 183
responses from a mix of service provider, vendor and other professionals. About
one third expect to see significant adoption before the end of 2012, and another
third expect it in 2013. Less than one fifth are unsure about deployment prospects.
We also asked the audience for their views regarding the suitability of using MPLS-
TP in different parts of the network. We received 271 responses, showing that many
industry professionals consider the properties of MPLS-TP well suited for deployment
across backbone/core, metro and access networks. This suggests there could be
widespread opportunity for the use of MPLS-TP, and that the message of a unified
MPLS solution that includes both IP/MPLS and MPLS-TP is likely to be well received.
Figure 14: Industry Feedback – MPLS-TP Suitability for Deployment in Core, Metro & Access Network
Source: Light Reading MPLS-TP Webinar, June 2011, 271 respondents
Figure 13: Industry Feedback – Expected Pace of Significant, Strategic MPLS-TP Adoption
Source: Light Reading MPLS-TP Webinar, June 2011, 183 respondents
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 17
MPLS-TP Early Deployment Plans & Applications
In this section, we provide examples of operators planning deployment of MPLS-TP
technology and discuss several initial applications for which MPLS-TP appears well
suited. The applications include: (1) backhaul of mobile traffic over a packet
network infrastructure; (2) SDH/Sonet migration to packet transport; and (3)
dynamic MPLS-TP over OTN/DWDM.
MPLS-TP Early Deployment Plans & Activity
Heavy Reading's discussions with network operators and equipment suppliers
suggests that some of the world's largest operators will tend to be the first to test,
trial and begin initial deployment of standards-based MPLS-TP technology, while
many smaller operators are likely to monitor activity closely and join in the game
as standards progress and the technology proves itself in various applications.
Below are examples of operator plans and activities related to MPLS-TP.
MPLS-TP Application 1: Mobile Traffic Backhaul Over Packet Network
Mobile backhaul has emerged as one of the key initial applications for MPLS-TP
partly because it fits well with the transport-oriented operational model of many
mobile operators that currently use TDM-based platforms to support 2G/3G traffic
backhaul. MPLS-TP enables operators to deploy simple, inexpensive spoke devices
at cell sites, handle multiple traffic types (e.g., TDM, ATM, Ethernet, IP), support
multiple classes of service, simplify service provisioning and increase fault resiliency
via multiple protection options – including mesh topology protection for LTE.
Bharti Airtel is one of the first operators in the world implementing an end-to-end
MPLS-TP solution for mobile backhaul. It is deploying MPLS-TP functionality from ECI
at the access and aggregation layers with Ethernet pseudowire support (both
point-to-point and multipoint/VPLS).
Figure 15: MPLS-TP Deployment Plans & Activity (Examples)
OPERATOR REGION APPLICATION
Bharti Airtel India
Deploying MPLS-TP end-to-end from access to core for 3G mobile
Verizon U.S. Plan to deploy dynamic MPLS-TP over OTN/DWDM in network backbone
Tier 1 U.S. Mobile backhaul, RAN metro
Tier 1 U.S. Metro Ethernet services, metro core, metro aggregation
Tier 1 Europe SDH replacement
Tier 1 Japan Mobile backhaul, consolidation of broadband business network services
Tier 1 Hong Kong (China) Metro Ethernet services, metro aggregation
Tier 1 China Mobile backhaul, metro aggregation
Tier 1 China* Mobile backhaul, metro aggregation
Source: Select operators and network equipment suppliers; * Not IETF-standards compliant
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 18
MPLS-TP Application 2: Sonet/SDH Migration to Packet Transport
A number of service providers worldwide are looking at deploying MPLS-TP to
migrate their metro core/aggregation networks from TDM to packet transport. This
can be done in a single step or with a phased approach (e.g., introducing MPLS-
TP in the access/aggregation network and then later in the metro/metro core).
The idea is for the MPLS-TP network to have a similar look-and-feel as the existing
Sonet/SDH network, but scalability can be enhanced with a GMPLS control plane.
Figure 17: MPLS-TP Application – Sonet/SDH Migration to Packet Transport
Source: Ixia, Verizon, and Cisco
Figure 16: MPLS-TP Application – Mobile Traffic Backhaul Over Packet Network
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 19
In a typical scenario, DWDM could be used to transport MPLS-TP-based LSPs in the
metro core/aggregation network, and these LSPs would interconnect customers
on the access side with IP/MPLS-, Ethernet-, or TDM-based service cores.
MPLS-TP Application 3: Dynamic MPLS-TP Over OTN/DWDM
While a number of service providers and vendors have talked about deployment
of MPLS-TP in metro/aggregation networks, Verizon has publicly discussed its
intention to deploy dynamic MPLS-TP over OTN/DWDM in the network core, as
shown in Figure 18). According to a Principal Member of the Technical Staff in
Verizon's Network Architecture Group, "Our plan is to use completely dynamic
MPLS-TP, which means we're going to have a user network interface at the edge.
And that user network interface is used to signal dynamic setup of label switched
paths or connections through the MPLS-TP domain to provide the connectivity for
the edge services."
Verizon's goal is to have the MPLS-TP domain act as the transport backbone for all
of the company's packet services and traffic. This will be one single converged
MPLS-TP backbone with Ethernet and IP/MPLS islands interconnected via MPLS-TP.
Figure 18: MPLS-TP Application – Verizon: Dynamic MPLS-TP Over OTN/DWDM
Source: Light Reading MPLS-TP Webinar, Sept. 2010; also Ixia, Verizon, and Cisco Webinar, April 2011
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 20
Cisco Perspective: Standards-Based Unified
MPLS Across the End-To-End Network
Service providers have used MPLS for many years to efficiently manage and
control traffic in core networks. Based on this success, MPLS is now being extended
to aggregation and access networks to deliver consistent data, control and OAM
planes in IP next-generation networks (NGNs). For MPLS to scale to these new
network domains while continuing to support simple operational procedures,
changes must be made to the technology.
Cisco has embraced the challenge of delivering simple-to-operate and highly
scalable MPLS technologies to promote this evolution. These new technologies
include MPLS-TP, Fast Convergence with simplified 50ms restoration schemes and
new OAM capabilities. The following sections examine the motivations, require-
ments and solutions for operating MPLS across the end-to-end network, and
describe how network operators can employ them to realize the full benefit of
end-to-end MPLS in IP NGNs and packet transport networks.
Evolving Role of MPLS
MPLS has been widely adopted by carriers worldwide, initially in core networks,
and now in access and aggregation networks as well. Carriers continue to realize
substantial benefits from MPLS and how it supports sophisticated traffic engineer-
ing mechanisms, VPNs and Multiservice-Transport-over-Packet capabilities.
Since its introduction, more than 20 years ago, into service provider networks MPLS
technology has undergone continuous innovation and improvements in its
operating characteristics, services delivered and interoperability among equip-
ment vendors. Most recently, users have seen dramatic improvements in the
scaling properties and simplicity of operation for MPLS networks. These develop-
ments have opened up the potential to extend MPLS into access networks with
new technologies, such as MPLS-TP; ultimately providing a single end-to-end data
and management plane for next generation packet transport networks.
Unified MPLS Technology
Unified MPLS is designed to address the expanding role of MPLS within provider
networks and further promote the adoption of MPLS among operators with
accelerating traffic demands and diverse service requirements. Unified MPLS
provides an architecture that combines all the latest developments within IP/MPLS
and MPLS-TP to support simplified and highly scalable MPLS deployments. Unified
MPLS can be viewed as consisting of two domains that transparently work togeth-
er to deliver on the promise of a simple-to-operate and resilient end-to-end
packet transport network. These two domains are the core and edge aggregation
networks combined with the access network.
Operators worldwide recognize two primary approaches for bringing MPLS to
access networks: The first aligns with using a static control plane for MPLS (as
represented by the initial phase of MPLS-TP); the second uses developments in the
dynamic control plane of MPLS. The initial static phase of MPLS-TP brings a number
of benefits to MPLS operation in access networks. First, in-band OAM is introduced
into MPLS OAM. This replicates the transport-centric operations familiar to TDM
operators and provides a simple mechanism for validating that the data path is
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 21
operational in the network. MPLS-TP also supports restoration mechanisms based
on a backup path, rather than single link or node protection. While this approach
is not typically feasible in core networks, it is a viable solution for access networks
and simplifies operations.
Unified MPLS supports both the dynamic and static approach for access networks,
so operators can choose the mode of operation that most closely aligns with their
desired operational models. This is typically determined by organizational consid-
erations. For operators using an integrated operations organization that manages
the network end-to-end, it makes sense for LSPs to run end-to-end, as this provides
the simplest design to operate. Operators using segmented operations, with
separate groups managing access networks and aggregation and core networks,
will require the ability to operate these network segments independently.
MPLS-TP in Access Networks
MPLS-TP addresses concerns associated with bringing traditional IP/MPLS to access
networks – the potential for overloading the router's link-state database, and the
added complexity of having to define a separate tunnel overlay for restoration. As
the initial phase of MPLS-TP makes use of manually provisioned label-switched
paths, no /32 endpoint identifier is required. In fact, no routing protocol or label
distribution protocol for point-to-point pseudowires is required at all.
In addition, MPLS-TP does not require a separate tunnel overlay to be defined for
restoration purposes. Instead, it works on the basis of defining an end-to-end
primary and backup label-switched path. Using the BFD protocol, routers and
switches continually send fast keep-alive messages down the primary label-
switched path. Should three keep-alive messages not be received, the network
declares the primary path down and switches traffic to the backup path.
Through these mechanisms, the MPLS-TP approach eliminates the concerns over
/32 address overload, hierarchical routing protocol design complexity and fast
reroute tunnel overlay design. MPLS-TP also works for any topology in access
networks. However, the approach is not without drawbacks. Manually provisioning
all paths is, by definition, a labor-intensive task that could be done by program-
matic means with less overhead. Having only a primary and backup path also
eliminates the option to use alternative paths that may be available in the
network should both primary and backup paths fail.
Unified MPLS describes the complete end-to-end MPLS architecture that positions
MPLS in the data and control plane for every network element performing packet
switching in a provider network. Within core networks, the extensive connectivity,
relatively low number of devices and installed base argue for traditional IP/MPLS
deployment. Traditional IP/MPLS in this domain supports continued bandwidth
growth, multipoint connectivity and sophisticated quality-of-experience features.
Moving toward the access network, MPLS-TP can address challenges associated
with bringing traditional IP/MPLS to access networks. In the access domains,
operators can choose from static or dynamic control plane options to suit their
organizational structure and operational preferences. Due to the continuous
innovation of MPLS technologies exemplified by Unified MPLS, MPLS is now a valid
choice for supporting unified data, control and OAM plane deployment across all
domains within IP NGNs and packet transport networks.
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 22
ECI Telecom Perspective: A Transport Opera-
In the migration from TDM-based to packet-based transport networks, the need
for a connection-oriented layer is well understood. Ethernet has become the de
facto standard for a packet-based data-link layer that can dramatically reduce
the price per bit. However, it needs to be coupled with a connection-oriented
technology to achieve the deterministic behavior, resiliency, OAM and QoS that is
required in transport applications.
Until now, the most widely deployed connection-oriented packet technology has
been IP/MPLS. Its success and ability to enable new services in the IP edge and
core networks is widely recognized. However, when it comes to transport applica-
tions, particularly in the metro and access layers, IP/MPLS may not be the right
choice for some operators. While IP/MPLS provides many of the connection-
oriented benefits that are required, it also brings with it some "connectionless"
properties and the need to understand and manage dynamic IP protocols. This
requirement has precluded it from being used in certain deployment scenarios.
ECI views MPLS-TP as a new, complementary "profile" of MPLS that will expand its
addressable market into new applications and parts of the network. One of the
key reasons is that the operational paradigm of MPLS-TP is more consistent with
that of Sonet/SDH and optical transport networks. As shown in Figure 7 above,
"dynamic" IP/MPLS distributes control plane intelligence to the individual network
elements. As a result, the operational model also typically involves CLI configura-
tion on each network element. Because MPLS-TP standards do not mandate the
use of a dynamic control plane, the intelligence can be centralized to an NMS like
it has been with other transport technologies. This makes it attractive to the
transport departments within operators that are accustomed to provisioning and
managing services via an NMS. Furthermore, the NMS can maintain the benefits of
a distributed control plane such as the ability to perform path computation and
constraint-based routing when provisioning LSPs.
The characteristics of MPLS-TP make it very suitable for certain applications. One of
them, already mentioned above, is mobile backhaul. Since backhaul networks
have typically been operated by transport teams and have limited path diversity
(obviating the need for large table lookups), MPLS-TP is a simple, cost-effective
solution that can help operators leverage their installed base while preparing for
the next-gen. This may include leveraging MSPP products that were originally
deployed for support of 2G/3G backhaul and can now support MPLS-TP while
interoperating with newer carrier Ethernet platforms being deployed for mobile
broadband support in today's 3G or LTE networks. MPLS-TP enables a smooth
migration with its ability to carry multiservice traffic in today's 3G backhaul net-
works (Ethernet, TDM, ATM), while supporting the mesh requirements of LTE, since
multipoint technologies such as H-VPLS can be run over an MPLS-TP infrastructure.
Another useful application of MPLS-TP is in utility networks. Utilities are increasingly
turning to packet technologies as they upgrade to support SmartGrid applica-
tions, video surveillance and substation WAN access. With the move to packet
networks, security regulations such as those from NERC (North American Electric
Reliability Corporation) are addressing the need to secure utility substation and
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 23
Control Center networks against hostile attacks. The centralization of the control
plane with MPLS-TP also simplifies the approach that operators/utilities may use to
secure the network. Since many network vulnerabilities are exploited via TCP/IP
attacks, a network of MPLS-TP elements without interface IP addresses can reduce
the risk profile of these mission critical networks.
Both IP/MPLS and MPLS-TP will be deployed in service provider networks going
forward. It is not a question of one or the other, but rather where best to apply
each "profile" of MPLS based on the needs of each deployment scenario. Since
they will coexist in networks, it is important that vendors provide the ability to
interoperate between the two profiles of MPLS and enable service delivery end-to-
end across static and dynamic domains. This has been referred to as Unified MPLS.
As a provider of both MPLS-TP and IP/MPLS capabilities across our product
portfolio, we have focused extensively on providing a solution to interconnect
static MPLS-TP domains with IP/MPLS domains. This has been implemented in a
software feature we refer to as MPLS Signaling Gateway. The Signaling Gateway
solution goes beyond just extending Ethernet or TDM/CES PW services end-to-end,
but it also addresses the need for redundancy/protection at these domain
boundaries and extending OAM end-to-end as well.
Impact on Packet Optical Convergence
While the MPLS-TP standards do not mandate the use of a control plane, when a
control plane is used, it will be based on GMPLS. Having GMPLS as a single control
plane for the packet and optical layers provides benefits such as operational cost
savings and faster service activation times. A question often arises in the industry
as to the relationship between OTN and MPLS-TP and whether both will be
required. Our view is that both will exist in packet optical networks as they each
provide some distinct and necessary capabilities.
MPLS-TP offers the ability to perform statistical multiplexing and QoS – essential
elements in building a cost-effective packet network. Meanwhile, OTN/G.709
framing provides important functionality during optical transmission such as error-
detection/correction capabilities (FEC/EFEC). Never mind OTN framing, what
about OTN switching you might ask? While there may be some cases where either
OTN or MPLS-TP switching can be applied, there will remain other scenarios where
one is the logical choice over the other (e.g., inelastic/leased-line services lend
themselves toward OTN switching, while data services lend themselves toward
Ethernet/MPLS-TP switching). In any case, we expect next-generation switching
fabrics to be agnostic about whether they are switching OTN or Ethernet/MPLS
frames so the debate of deploying one or the other should become moot.
In summary, we believe MPLS-TP and our approach to applying it in network
solutions will enable operators to (1) consolidate their metro access/aggregation
networks on a common carrier Ethernet/MPLS infrastructure; (2) simplify operations
with the help of Unified MPLS technology throughout the network; (3) converge
diverse fixed and mobile services on a common high-performance infrastructure;
(4) smoothly migrate from legacy transport infrastructure to next-gen packet-
optical infrastructure; and (5) increase their flexibility in locating service-delivery
functions, rolling out new services and phasing out older services.
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 24
Ericsson Perspective: MPLS-TP Broadens the
MPLS was created to improve IP operations in the Internet core and eliminate
dependencies on "non-integrated" Layer 2 technologies, such as Frame Relay and
ATM. Over time, it has incorporated many of the functions previous "convergence
technologies" sought to deliver. MPLS is now a full-featured and widely deployed
protocol suite that offers flexible deployment models. The most recent extensions
to MPLS, referred to as MPLS-TP, have made it possible for the protocol to move
into traditionally connection-oriented areas like a TDM-based operating model.
Ericsson believes that a common, evolved and unified MPLS standard, which
incorporates interoperable OAM extensions, is essential to the widespread
adoption of MPLS as a unified packet transport technology. This emerging archi-
tecture views the network as consisting of multiple domains. Different interopera-
ble profiles of MPLS can be implemented in these domains to create a simple,
scalable, end-to-end packet transport network The following sections examine
various facets of MPLS implementations in the emerging network architecture.
Who Should Be Interested?
Large incumbent service providers are in the process of migrating their transport
networks to take advantage of the flexible data rates and statistical multiplexing
capabilities of an increasingly packet-based traffic profile. Ensuring the continuity
of revenue-generating services is an essential requirement of any network evolu-
tion. Existing transport networks are usually management plane-driven. Deploying
products that implement MPLS-TP offers a significant advantage for incumbent
service providers with large organizations dedicated to managing transport
networks. One key advantage of an MPLS-based packet transport network is that
it can reuse the transport network operating model in planning, configuration and
fault management. This allows providers to leverage their transport organization's
existing skills during the migration to a packet transport network.
Fast-growing mobile service providers frequently have challenges backhauling
mobile traffic from base stations to the mobile core. With the rapid growth in
mobile broadband services, packet (IP/Ethernet) traffic is expected to dominate
mobile backhaul; however the coexistence of TDM and ATM traffic from older 2G
and 3G technologies is inevitable. Adoption of a packet-based backhaul, using
MPLS, enables mobile operators to converge multiple networks into a common
infrastructure that can take advantage of efficient statistical multiplexing as
packet traffic grows.
MPLS-based access and aggregations networks are also well suited for "Carrier of
Carriers" and service providers that specialize in providing wholesale enterprise
Layer 2 services. MPLS pseudowires eliminate the complexity that is currently
required in these networks to overcome the scalability limitations of traditional
What Does It Offer?
MPLS is a widely adopted protocol suite that improves the efficiency and perfor-
mance of the core networks. Extending the realm of MPLS to the access and
aggregation segments of the network allows the migration to a true multiservice
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 25
architecture on a single converged packet transport network. The sheer number
of devices required in the access and aggregation segments makes it essential
that they be optimized for cost, size and power consumption. MPLS-TP allows the
execution of some components of control functions, such as resilience, monitoring
and management, to the data plane. The ability to provide resiliency, without a
complex control plane and the relatively simpler topologies, allows MPLS-based
products to be extended into the higher node density aggregation and access
segments of the network, without increasing the control plane complexity.
The adoption of cloud-based services is shifting traffic patterns in the network.
Large data centers are increasingly becoming traffic hubs. Deployments utilizing
MPLS-based transport networks in the metro access and aggregation segments
can significantly optimize the network infrastructure required to support these new
traffic patterns. Deploying MPLS-TP in these segments provides the added advan-
tage of avoiding disruptive organizational changes, since these networks can be
managed and operated in a similar fashion to many existing TDM-based
Where Does It Make Sense to Deploy?
The recent extensions to MPLS, particularly MPLS-TP, allow service providers and
equipment vendors to adopt an end-to-end architecture based on a unified MPLS
data plane and a common management structure. MPLS-TP is well suited for the
access and aggregation segments of the network for two reasons: predictability
and scalability. MPLS-based packet networks provide a connection-oriented
approach to carrying packet traffic. MPLS-TP, with its enhanced OAM techniques
and resiliency mechanisms, can offer SLAs for packet transport services similar to
current TDM services. The predictability of traffic paths also significantly cuts down
on the operating expenses associated with troubleshooting a large network.
Access and aggregation network segments, which feed the MPLS service infra-
structure in the core, often consist of thousands of nodes. It is important to have a
protocol and network architecture that can scale without significantly increasing
the complexity of the network. Network elements running MPLS-TP can be man-
agement plane driven nodes, making the complexity of these networks indepen-
dent of the number of nodes in the network. With MPLS-TP deployed in the access
and aggregation segments of the network, and IP/MPLS in the core, a unified
MPLS data plane becomes the "backbone" of a new, efficient packet network.
What Are Some Compelling Applications?
Ericsson believes that a mobile backhaul transport network is a key application
that benefits from an end-to-end MPLS architecture. The accelerated growth of
mobile broadband services makes it imperative for mobile service providers to
overhaul their backhaul networks in order to handle the explosion in data traffic
efficiently and economically. The transformation of the existing TDM-based
transport networks to a packet transport network is another compelling applica-
tion. The ability to conform to existing operation models will be an added advan-
tage to service providers adopting MPLS-TP-based network elements when
migrating to a packet transport network.
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 26
Ixia Perspective: Implementation Challenges
MPLS-TP is a new technology undergoing continued development. Test equipment
plays a critical role in overcoming the many implementation challenges for MPLS-
TP. Ixia has been working with network equipment makers, service providers and
test labs to validate MPLS-TP features and functionality, troubleshoot and resolve
implementation issues, and satisfy the milestones that will precede deployment.
Detailed test plans for MPLS-TP are available in the Ixia MPLS-TP Blackbook. A
summary of key MPLS-TP implementation challenges is included below.
BFD OAM functions need to be defined in conjunction with failure detection. New
alarm types, for example, AIS, LCK, LDI and performance monitoring functions,
such as LM and DM, are required. There is also a need to use OAM to communi-
cate static PW status to the far end in the case of Multi-Segment PW. On-demand
connectivity verification such as LSP Ping and Traceroute are popular in IP/MPLS
networks today and can be incorporated and adapted to use with BFD. A full
feature set of OAM functions, coupled with separate CC sessions (at various
detection intervals) for each working and protecting LSP and PW, while supporting
various performance targets (per port, per card, per system), brings many imple-
mentation challenges for any MPLS-TP capable device.
MPLS-TP needs to support all the different options and mechanisms for protection
switching in order to be a viable alternative to existing transport networks. A rich
set of triggers, both manual and automatic, must be defined to make APS more
robust against failure and service disruptions. APS can be applied to either an
individual LSP or PW. In the event of failure, it can be very challenging for an MPLS-
TP device to ensure each working path can switch over in sub-50ms when the
number of working and protecting paths reaches thousands to tens of thousands.
An MPLS-TP device must be tested both for switchover scalability and for different
functions when participating in different APS roles. The processing demands (and
test requirements) placed on an MPLS-TP device will vary based on whether it's
acting as an ingress P/PE router, an egress P/PE router, or a transit node. An ingress
P/PE router in a protected domain is responsible for monitoring all LSPs and PWs
and detecting any error conditions. Should an error occur, due to loss of continuity
or loss of physical signal (or other vendor-specific reasons), the ingress P/PE router is
responsible for switching over all data plane traffic to protecting paths.
The relationship between a working PW and an underlying working LSP, which is in
turn being protected by another protecting LSP, is complex and also falls into the
responsibility of an ingress P/PE node. Briefly, PWs within an LSP should be switched
over to protecting PWs if and only if both the working LSP and protecting LSP
cease to work. This requires extra processing on the ingress node to correlate
events with nested protection mechanisms. When a DUT functions as a transit
node, the processing overhead from control and data plane activities is relatively
light – similar to a P router in an MPLS network. When a DUT functions as an egress
node, it must select the right data plane traffic based on the protection type and
Protocol State Coordination (PSC) messages. In addition, the egress node must
terminate and maintain the right state for the failure detection mechanism.
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 27
Single segment PWs usually exist in a single operator and administrative domain.
For MPLS-TP to become a major transport technology for mobile backhaul and
access aggregation, it must traverse multiple domains to provide end-to-end
services. In this perspective, PWs traversing multiple domains automatically
become Multi-Segment PWs (MS-PWs). By definition, a MS-PW consists of many
Single-Segment PWs (SS-PWs) where each SS-PW could possess different properties.
For example, some segments may be statically configured, and others may be
dynamically signaled. The signaling protocol for the dynamic segments could vary
as well – there is a choice of using LDP with FEC128 or FEC 129, or even using
L2TPv3. While protocols such as LDP have the ability to propagate PW status to the
far end, a static PW has no such ability, so it must rely on other means such as
OAM to provide this. Areas of concern also exist in the interoperability of PW status
between a device running OAM and a device running LDP (or another protocol).
APS with MS-PW must work similar to the case of a SS-PW. Each segment of the PW
must be responsible for its own CC and CV operations. When a failure occurs, the
trigger to switch traffic from working to protecting LSP or PW must be end-to-end.
IP/MPLS & MPLS-TP Interworking
A MS-PW consists of multiple SS-PWs where each segment may be established by
using different methods, such as static configuration or targeted LDP for dynamic
signaling. This idea can be further extended to have some segments of an end-to-
end PW traverse an MPLS-TP enabled network while others traverse an IP/MPLS
only network. Existing MPLS networks have well established means for signaling
(LDP, RSVP-TE, MP-BGP) and fault detection (CFM, BFD, VCCV). To make an end-
to-end PW work in this case, the devices that support MPLS-TP on one end and
MPLS on the other may need to bridge the continuity check and translation of
alarms between the two networks. Additionally, the device would need to provide
mapping of APS commands from MPLS-TP to something such as FRR in IP/MPLS.
The challenge in this case is the fact that there are few open standards to guide
how the mapping or translation is done for CC, CV, Alarms, or even APS between
MPLS-TP and IP/MPLS networks. Expect continued standardization work in this area.
Apart from working functions, interoperability is the most important challenge for
many vendors. MPLS-TP has introduced new encapsulation (G-ACh and GAL) and
Channel Types, some of which are yet to be defined for many important OAM
functions, such as APS, LM, DM, LCK, AIS and LDI. Channel Type definitions are also
missing for some of the on-demand connectivity verification features, such as LSP
Ping and Traceroute. This poses issues even for basic multi-vendor interoperability.
Moreover, some of the specifications are updated frequently, which creates a
gap between vendors that started early and those that started later. Sometimes,
the specification between different drafts may not be backward compatible
even with basic message formats. This creates huge interoperability challenges.
While the majority of vendors support static configuration of LSP and PW, fewer will
likely implement the dynamic signaling of LSPs and PWs. Naturally, there is a
challenge to do an end-to-end test with multiple segments of an LSP or PW, where
some segments are statically configured, while others are dynamically signaled.
The challenges range from a simple end-to-end continuity check, or simple alarm
generation and interpretation, to a more complex case where the PW status is
statically configured on one part and dynamically exchanged on another.
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 28
Metaswitch Perspective: MPLS-TP Control Plane
MPLS-TP connections can be provisioned in two ways: through a management
agent explicitly configuring a connection at each node, or dynamically via a
control plane. Whilst management provisioning will be sufficient for simple network
scenarios, a control plane will be used for the majority of MPLS-TP deployments,
mirroring the success of the IP/MPLS control plane today.
The ability of MPLS-TP to support both static LSPs provisioned by management and
dynamic LSPs provisioned by the control plane in the same network is one of its
major strengths. The IETF standards explicitly support both modes of operation, and
also the transitioning of active connections between management and control
plane. So even if an MPLS-TP deployment does not initially require a control plane,
it can be non-disruptively added as the network evolves in complexity provided
the underlying network equipment supports it.
What Is an MPLS-TP Control Plane?
The MPLS-TP control plane is based on two layers. The GMPLS protocol is used for
the transport layer and LDP-signaled pseudowires provide Layer 2 client services
over the MPLS-TP transport layer. GMPLS is an evolution of the widely deployed
MPLS control plane and gets its name by generalizing the signaling extensions for
MPLS to make it easily extensible to an array of different data plane technologies,
such as TDM or WDM switching. This extensibility is a key reason why the IETF used
GMPLS to implement the ITU's blueprint for Automatically Switched Optical
Since its inception in the early 2000s, ASON/GMPLS-based control planes have
become mature technologies that are successfully deployed in a wide range of
transport networks worldwide. The IETF states that the MPLS-TP control plane must
meet the ASON requirements and architecture (with which some carriers are
already familiar). Therefore, GMPLS, with its packet-switching MPLS ancestry and its
success in ASON networks, is a natural choice for an MPLS-TP control plane.
Why Use an MPLS-TP Control Plane?
Adding a control plane will give significant benefits to carriers, particularly as
network managers try to address increasing capacity, more complex topologies
and less predictable traffic patterns in their networks.
· The control plane has been proven to be able to control a complex net-
work with fewer operating personnel. This leads to significant opex savings.
· The control plane facilitates much faster recovery for the case where
backup paths have not been pre-provisioned. When failures occur, the
control plane quickly instigates dynamic restoration. Without a control
plane, recovery requires management intervention – a slow process.
· The control plane allows carriers to utilize expensive network resources
more efficiently by automatically refreshing itself upon network changes,
or connection setup/tear down.
· The control plane reduces provisioning times and allows "on-demand pro-
visioning" to support new revenue opportunities and services for carriers,
such as "broadband bandwidth on demand."
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 29
· The control plane simplifies network configuration considerably. For MPLS-
TP networks, for example, the IETF is defining control plane extensions that
allow devices to negotiate diverse OAM functions available for a given
Control planes are becoming increasingly popular in optical transport networks.
According to the Optical Internetworking Forum (Controlling Tomorrow's Optical
Networks), major carriers such as AT&T (AT&T's Optical Mesh Service) and Verizon
(Verizon's Bandwidth on Demand Service) in the U.S. and Telefónica in Spain have
now successfully deployed control plane technology.
The packet-based service provided in MPLS-TP networks offers carriers the chance
to apply well-established traffic management techniques from existing packet
networks (such as statistical multiplexing or traffic conditioning) to their transport
networks. These techniques can significantly increase the capacity of the network,
but introduce operational complexity. Control plane technology, which is ubiquit-
ous in packet networks, is well-proven at helping carriers manage this complexity.
As carrier acceptance of MPLS-TP continues to take root, their network deploy-
ments will get progressively larger, more advanced and more interconnected. As
networks grow, the resiliency, flexibility, improved provisioning times and opex
savings delivered by a GMPLS control plane will become more significant. The
benefits provided by the control plane will thus become increasingly significant.