RFC 5218 defines what the Internet Architecture Board considers to be a "successful" protocol. A "successful" protocol is one that meets its original goals and is widely deployed, such as DNS, BGP, SMTP, and SIP. A "wildly successful" protocol far exceeds its original goals in terms of purpose and scale. Examples of the latter are IPv4, ARP, and HTTP. A protocol may be considered successful even if its deployment is still limited, as long as it meets its original goals.
At the technical plenary of the 74th IETF meeting in May 2009, there were presentations on the occasion of the 12th anniversary of the formation of the MPLS working group (subtitled “MPLS becoming a teenager”). This session was subtitled “Many consider MPLS a success, in the sense of RFC 5812's (sic) "What Makes for a Successful Protocol?" (see agenda and slide) .
Note the reference to 5812 instead of 5218. I find this typo enlightening. The first presentation of the session claimed that MPLS is a "wildly successful" protocol. In my opinion, MPLS can not be considered even “successful” in the sense of RFC 5218, but it may indeed be in the spirit of RFC 5812.
For those who haven’t read 5812, it is a proposed standard entitled “Forwarding and Control Element Separation (ForCES) Forwarding Element Model”. ForCES is a framework and a set of protocols that aim to standardize information exchange between the IP control and forwarding planes, enabling control elements (CEs) and Forwarding Elements (FEs) to become physically separated components. Although this was certainly not the intention of the speaker, this type of separation is indeed one of the ancillary benefits of MPLS.
The second talk at IETF-74 was an interesting presentation on the history of MPLS, but it carefully avoided stating the relevant facts. In the mid to late 90s, after opening up the Internet to the public at large and to commercial interests, the Internet started growing exponentially. This growth was exciting, but brought two main concerns, namely
1) address exhaustion - which lead to the development of IPv6 (we are still waiting for IPv6 to become a successful protocol …), and
2) slowing down of IP forwarding due to router table explosion - which lead to the development of MPLS.
The first issue was temporarily solved by the introduction of NAT, and I won’t discuss it further here. The second brought about a wave of innovation, with at least five solutions offered :
1) Cell Switching Router (Toshiba) (see RFCs 2098,2129)
2) IP Switching (Ipsilon, bought by Nokia) (see RFC 2297)
3) Tag Switching (Cisco) (see RFC 2105)
4) Aggregate Route-based IP Switching (IBM)
5) IP Navigator (Cascade acquired by Ascend which was acquired by Lucent which merged with Alcatel to become ALU)
With so many alternatives, BOFs were held in 1994-1995 and the MPLS working group chartered in 1997 with co-chairs from Cisco and IBM (which is the reason MPLS is so similar to tag switching and borrows a bit from ARIS).
However, the router manufacturers were not sitting idly waiting for MPLS to succeed, and improvements in algorithms and hardware increased the IPv4 forwarding speed to the point where MPLS was no longer needed.
So why is MPLS still being used ? There are at least two reasons. First, RSVP-TE-enabled MPLS enables hard QoS guarantees that are not possible in pure IP due to the lack of adoption of IntServ. Second, MPLS can carry non-IP packets (pseudowires).
I have heard the argument that the first reason was the true design goal of MPLS. However, a casual reading of RFC 3031, the RFC that defines MPLS, shows that QoS was considered an added advantage, not a design goal.
Some routers analyze a packet's network layer header not merely to choose the packet's next hop, but also to determine a packet's "precedence" or "class of service". They may then apply different discard thresholds or scheduling disciplines to different packets.
MPLS allows (but does not require) the precedence or class of service to be fully or partially inferred from the label.
Although MPLS is very widely deployed, the problem it was designed to solve has gone away (although it may return when IPv6 becomes more prevalent), and indeed on some platforms MPLS-based forwarding is actually slower than native IPv4 forwarding. Thus, according to 5218 MPLS is not successful. Yet.
Y(J)S
