It's impossible to talk about service provider networking today without hearing about MPLS. Certainly the role of MPLS in the network of the future is one of the most important issues facing network planners. Like all network standards, MPLS is evolving, and in some senses, "spreading." Its twists and turns expose it to new competition from other standards and new sources of planning confusion. Will MPLS play a key role in the network...
of the future? It depends on which network, and which MPLS.
MPLS, which stands for "Multi-Protocol Label Switching," evolved from a number of vendor projects in the mid-1990s that were aimed at making IP routing more efficient and more competitive with protocols like frame relay and ATM. The primary source of MPLS standards was Cisco Systems' "tag switching," a mechanism for creating what were, in effect, specific routes for traffic through IP networks. That remains the basis for the core of MPLS today.
In routed IP networks, traffic moves between routers based on adaptive topology updates based on the exchange of "reachability" information among network routers. Traffic was routed "hop by hop" from router to router, following a path that could be determined only by examining the sum of the routing tables in the network at the time the traffic was moving. This made it impossible to engineer specific quality of service by allocating resources to traffic types. The goal of MPLS was to create special entries in routing tables that combined to create label-switched paths (LSPs) or multi-hop routes.
MPLS LSPs are normally created using the IP routing tools. MPLS, like IP, has automatic adaptive routing, but MPLS LSPs can be threaded among devices and over paths in a way that supports traffic engineering. So it has become an almost-universal way of adding quality-of-service or application-specific routing support to IP networks.
The adaptive nature of MPLS routing means that it recovers automatically from network device or link failures, and so in the late 1990s, work was begun to utilize MPLS principles to route optical or circuit-switched traffic. This involved adding an IP/MPLS control plane as a layer above the optical/TDM switching network and allowing connections to be routed via IP/MPLS principles first, then "pushed down" to the data plane. This resulted in what was called Generalized MPLS or GMPLS, and it is now common to read about "GMPLS control planes" as a means of finding a path between two points using IP/MPLS principles, even if the network isn't an IP network.
The problem with MPLS, according to some network operators, is that it's a protocol over IP. First, this means it must be implemented on relatively expensive IP routers. Second, it is still subject to adaptive automatic rerouting in the event of failures, which can still create problems with QoS control and interfere with service provider policies on failover traffic handling. In short, the problems that MPLS and IP have make them less than perfect in supporting at least a class of network applications.
MPLS alternative to Carrier Ethernet's PBT
One solution to the MPLS challenges was to solve the problems at the Carrier Ethernet level by enhancing Carrier Ethernet's Provider Backbone Bridging (PBB) standard to support what were essentially Ethernet multi-hop paths. This created the Provider Backbone Transport (PBT) or PBB-TE (PBB with Traffic Engineering) standard currently being finalized. PBT eliminates the bridging discovery protocols of Ethernet, relying instead on a separate control plane to maintain the bridging tables that control traffic flow. One logical protocol to use for this is GMPLS, though any standard or proprietary mechanism to find traffic paths would be workable.
PBT created a considerable flap in the IP world, where it was seen as a threat to IP convergence, and many IP vendors are totally opposed to it. However, there is no denying that some network operators have endorsed the value proposition of PBT, and so the IP/MPLS community looked to create a counter-strategy, which it has done with an emerging variant on MPLS called "Transport MPLS" or T-MPLS. T-MPLS is a version of MPLS that also separates the control plane from the data plane and that allows operators to control rerouting and failure policies explicitly.
MPLS and the MPLS/PBT debate create some interesting challenges for network operators that according to many still require some standards work to resolve:
- MPLS is not normally considered suitable as an end-to-end or user-to-user protocol because extending it to the user would make the user a partner in the service provider control plane, something not normally considered scalable or secure.
- MPLS interworking among network operators today is a control plane process that requires what some operators call an "Open IP NNI" between the providers, a step that can limit a provider's ability to insure that premium IP resources used by another operator's customer have been paid for in some way.
- MPLS interworking with other "path-based" network technologies, especially Carrier Ethernet and PBT, requires more work.
MPLS as a service framework is often linked with another standard set called pseudowires, which are effectively IP virtual circuits that can be extended from user to user. Some work has been done to make pseudowire standards harmonize with technologies other than IP, but the pace of progress here is disappointing. It is likely that a harmonious linkage between MPLS, pseudowires, PBT, T-MPLS, IP, and legacy technologies like frame relay, ATM and even TDM would be a powerful step in addressing service provider needs.
Work is underway in a number of standards bodies, ranging from the IETF and ITU through the TMF, MEF, MFA, and IPsphere Forum, on various aspects of MPLS interworking and its harmonization with other standards. Unfortunately, it may be several years before all of these standards are finalized and the work of multiple bodies is fully reconciled. In the meantime, network operators have little choice but to deploy networks and services based on interim work and watch the trends and progress in standardization carefully to insure their networks will be compliant in the future.
About the Author: Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982. He is a member of the IEEE, ACM, Telemanagement Forum, and the IPsphere Forum, and the publisher of Netwatcher, a journal in advanced telecommunications strategy issues. Tom is actively involved in LAN, MAN and WAN issues for both enterprises and service providers and also provides technical consultation to equipment vendors on standards, markets and emerging technologies. Check out his SearchTelecom networking blog Uncommon Wisdom.