For some time now, transport network operators have been striving to migrate gracefully from circuit-switched modes of operations to include more packet-switching technology, for the potential bandwidth utilization and network performance gains that can be achieved. As IP/MPLS and Ethernet technologies have become the de-facto packet-based technologies of choice, transport network operators have sought to evolve their networks with either the implementation of or interoperation with these technologies (or both).
However, the operations of packet-based and circuit-based architectures differ greatly. IP/MPLS-based networks have developed over time a planning and engineering tool set required to manage the more dynamic resiliency capabilities available in packet networks. Yet transport networks tend to be more static in their configuration, with re-engineering typically undertaken much less frequently. This has resulted in a significantly different skill set owned by transport network operations staff, one more attuned to the capabilities of the transport network. The objective of the MPLS-Transport Profile is to bridge this gap, from a technological as well as an operational perspective.
MPLS-TP provides a harmonizing paradigm spanning IP/MPLS-based and optical transport networks. While based on the IP/MPLS forwarding paradigm, MPLS-TP extends IP/MPLS capabilities by adding transport-based OAM enhancements more like those of SONET/SDH and OTN. MPLS-TP pursues the goal of providing resiliency and OAM capabilities similar to SONET/SDH and OTN networks, while maintaining the benefits associated with packet-based networking.
MPLS-TP is therefore a profile – or a specific subset – of an MPLS functionality set that is being extended to meet the key design parameters identified. The diagram shown below illustrates the relationship between the Transport Profile and the existing and expanded MPLS toolset.
Prior to the definition of the MPLS-TP requirements in RFC5654, there existed a set of MPLS functions that have been widely deployed in IP networks. Some of these meet the requirements in RFC5654 and are thus suitable for a transport network operational environment. These include the MPLS and PWE3 (pseudowire emulation edge-to-edge) architectures, the MPLS forwarding paradigm, and the Generalized MPLS (GMPLS) and pseudowire control planes. Hence these form a part of the transport profile. However, some functions do not meet these requirements, and are thus excluded. These include Equal Cost Multi-Path (ECMP), the mandatory use of IP forwarding in the data path, and LDP signaling that specifically creates multipoint-to-point paths (which thus causes LSPs to arbitrarily merge and lose the association of a label to an individual source).
In addition to these existing functions, some of the requirements outlined above will be met by adding a limited range of new functions to MPLS. These new functions also fall within the transport profile and form an inherent part of an extended set of MPLS functions – specifically the OAM, protection, and provisioning capabilities listed.
MPLS-TP is being standardized by the Internet Engineering Task Force (IETF) and International Telecommunication Union (ITU-T). Many MPLS-TP standards already have been ratified, while the bulk of the work remaining revolves around the OAM toolset. Upon full ratification of all related standards, MPLS-TP will enable connection-oriented, packet-optical transport, based on widely deployed MPLS protocols with the performance and operations characteristic of today’s transport networks, while also ensuring compatibility with today’s IP/MPLS-based networks.
