White Paper
MPLS-TP in Next-Generation
Transport Networks
Prepared by
Stan Hubbard
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
Executive Summary
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
Introduction
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 access network.
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-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.
MPLS-TP Drivers
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 bedominat-ing 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
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 5
MPLS-TP Objectives
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 transport networks.
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.
MPLS-TP Overview
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 & Standards
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.
Standards-Based Network Equipment
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
Solutions
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).
Network Equipment Tests & Demonstra-tions
Multiple MPLS-TP tests and demonstrations have been conducted with platforms using MPLS-based OAM. Tests have included interworking of MPLS-TP and MPLS.
Network Equipment Trial & Early Deploy-ment Activity
Industry feedback suggests customer trial and initial deployment activity will ramp toward the end of 2011 and take place throughout 2012.
Sources: IEEE, service providers, network equipment providers, and test & measurement companies
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 late-stage development.
Figure 4 highlights important IETF documents, and Figure 5 shares the basic framework for MPLS-TP.
Figure 3: Major Attributes of MPLS-TP
HEAVY READING | JULY 2011 | WHITE PAPER | MPLS-TP IN NEXT-GENERATION TRANSPORT NETWORKS 8
Figure 4: Key MPLS-TP Requirement & Framework Standards Documents
DOCUMENT HIGHLIGHTS
RFC 5654 MPLS-TP Requirements (Sept. 2009)
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.
RFC 5860 MPLS-TP OAM Requirements (May 2010)
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
domains.
• 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.
RFC 5921 MPLS-TP Architecture Framework (July 2010)
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-guration.
• Path protection mechanisms and control plane-based mechanisms.
• Network management functions.
Draft MPLS-TP OAM Framework (Feb. 2011)
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. Source: IETF
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 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
Fault
Management
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
Performance
Management Loss/Delay Measurement LM and DM Tools New Loss Measurement and Delay Measurement Source: Cisco
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
VENDOR ACCESS PLATFORM CARRIER ETHERNET SWITCH/ROUTER PACKET OPTICAL TRANSPORT PLATFORM SERVICE EDGE ROUTER 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?
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 Encapsulation
G-Ach/GAL encapsulation Control Word (CW) inclusion
Message exchange (correct encoding and interpretation)
Label switching LSP & PW
Establishment
Static label assignment Dynamic provisioning
Interoperability of static SS-PW and dynamic SS-PW
Label space compatible OAM: Continuity
Check (CC) & Connectivity Verification (CV)
OAM message generation at various intervals
Failure detection
On-demand LSP connectivity verifica-tion
OAM message exchange CC/CV sessions established
Ping encoding follows G-Ach Channel Type+ Echo or G-Ach Channel Type + IP/UDP/Echo? On-Demand Alarm
Generation & Fault Notification
Alarm generation and detection Generation of AIS/LDI/LCK/PW Status Auto generation of RDI
CCCV Pause/Resume
Alarm encoding and interpretation AIS suppression state
Alarm propagation Automatic
Protec-tion Switching (APS)
Ingress, Egress, and Transit Node Different protection modes
PSC interoperability
Switchover time measurements per LSP/PW MPLS-TP & MPLS
Interworking
OAM status translation CW handling
End-to-end service verification
MS-PW (mix of MPLS-TP & IP/MPLS segments) Sources: Ixia
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
configuration.
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
Traffic Performance Forwarding performance at scale, including latency and delay variation with various packet size including IMIX Management
OAM (active and on demand) and MIB support High-scale static provisioning via NMS
High-scale dynamic provisioning via GMPLS OAM
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.
EANTC (2/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 1200 boxes.
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.
Isocore (10/10)
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
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
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 backhaul
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
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
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 improveequip-ments 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 delivtogeth-er on the promise of a simple-to-optogeth-erate 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.
Conclusion
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-tional Paradigm
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.
Killer Apps
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.
Unified MPLS
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.
Summary
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 Realm
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 VLAN-based services.
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 access/aggregation networks.
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
of MPLS-TP
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
summary of key MPLS-TP implementation challenges is included below.
OAM
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.
APS
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
MS-PW
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.
Interoperability
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 Networks (ASON).
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 MPLS-TP connection.
Control planes are becoming increasingly popular in optical transport networks.
According to the Optical Internetworking Forum
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.
