Was MPLS Necessary?

One of the objectives of the original “Computer Networks: A Systems Approach” book was to treat networking not as a series of artifacts that are handed down from on high, but rather as a design space to be explored. Jon Postel famously remarked that much of what the IETF was doing in the 1990s was filling in all the gaps in the design space that had been carefully avoided by the original designers of the Internet. MPLS was such a situation: adding a different sort of forwarding mechanism to the quite successful one on which the Internet was built, which probably accounts for much of the controversy that attended its development. So this week we’re looking back at the history of that particular design space exploration, at which we had a ringside seat.

---

One of the more satisfying conference experiences in my career was giving a presentation in the SIGCOMM 2003 Outrageous Opinions session, entitled “MPLS Considered Helpful”. The Outrageous Opinion session was at that point about 8 years old; I had chaired the first such session in 1995. (The inaugural session contained a number of memorable talks, such as David Clark’s actually-not-outrageous position that networking people should all become economists.) By this stage in its evolution the session had turned into something of a stand-up comedy show, and the idea of making a (hopefully) humorous defense of MPLS in front of an audience that either ignored or disagreed with the (admittedly controversial) technology came to me while out on a run through the German countryside. As someone with a lot of investment in shaping the MPLS architecture and getting it deployed in production, I was aware that my talk might come across as overly defensive, so I liberally scattered the message “I’m not bitter” through the talk. In the end, that was what most people remembered, and to this day I occasionally find people bringing that phrase up as I walk the corridors of networking conferences. 

Almost 20 years later I still find a fair amount of confusion (and cynicism) about what problem MPLS was supposed to solve. For example, I recently appeared on the Packet Pushers podcast, ostensibly to discuss the future of networking, and yet we ended up on a long digression about the history of MPLS. I was frankly surprised at how differently I, as someone involved in its formation, viewed MPLS compared to someone who had experienced it more as an end user. So at the risk, once again, of appearing defensive, I think it’s worth a look at how MPLS came about and why it was ultimately successful in terms of its global deployment. 

I want to point out that I am definitely not either the inventor or the “father” of MPLS. That title normally is given to Yakov Rekhter, who wrote the original ideas for Tag Switching in a 2-page memo that was circulated internally at Cisco, and is named as inventor on many of the central patents. (Yakov and I later co-authored a book on MPLS which was an excellent career move on my part.) Tag Switching formed the basis for much of MPLS when our group brought it to the IETF for standardization. However, there is plenty of credit to go around. Notably, some months before Yakov’s memo, in 1995, Chandranmenon and Varghese published a SIGCOMM paper that introduced the idea of threaded indices, which, just like tag switching, allows a fixed-length identifier to represent a variable-length destination prefix, thus simplifying the task of looking up addresses to forward IP datagrams. 

But I’m getting ahead of myself. The context in which Yakov wrote his paper (and in which threaded indices were invented) was very different from today. In fact, the 1995 Outrageous Opinion session contained several spirited debates about the merits of ATM, with its fixed-length cells and fixed-length header lookups, versus IP, with its variable-length packets and relatively complex longest-match lookup algorithms. Yakov and I both joined Cisco in 1995 as the company was trying to figure out the implications of ATM for its very IP- and Ethernet-centric business. The team that I joined was tasked with figuring out a way to somehow combine the technical approaches of ATM and IP. After a few months of kicking ideas around, the memo from Yakov struck me as plainly superior to everything we had seen before. Not only did it include the same basic idea as threaded indices (which I was unaware of), but it also introduced the idea of hierarchical tagging–something that already existed in ATM, with virtual circuit and virtual path identifiers representing a two-level “stack of labels”. And it was Eric Rosen–in my view, one of the unsung heroes of MPLS, a prolific inventor and a brilliant protocol architect–who saw that a label stack could readily be generalized to an arbitrary depth, which turned out to be one of the truly powerful additions to the MPLS architecture. 

At that time, there were half a dozen architects at Cisco, and a few more at Juniper, all trying to figure out how this idea of putting labels on packets could be useful. Many others got involved as the IETF effort took off. The idea of speeding up the lookup operation on an IP datagram turned out to have little practical impact. We even went as far as designing a router line card that could forward labeled packets only, to test this out. The line card was negligibly cheaper than a full-blown IP forwarding card, and no faster, because by this point fast IP lookups, while not trivial, were largely a solved problem. Buffering, switching among line cards, optical transceivers, etc., were all more important to cost and performance than optimizing a few percent out of the lookup engine. 

What ultimately made MPLS take off–and it did, in an under-the-radar sort of way–was enterprise VPNs. These were variously known as MPLS-VPNs, BGP/MPLS VPNs, or RFC2547 VPNs. At the time, service providers faced a significant challenge: how could they deploy VPNs for their enterprise customers without having every VPN be, in effect, a custom-built overlay per customer. This problem was presented to us by AT&T, who had a huge business building VPNs using Frame Relay–another technology mostly ignored by the academic community but one that was in such high demand that they were struggling to keep up. This was one of the first times I understood that scaling networks is as much about operational scalability as the scalability of technology. MPLS VPNs took us from a world where a new customer with N sites represented an N^2 configuration problem to one where it was order N. As we noted in our recent post, operational issues are often the most important ones to solve, and that was certainly the case here.

MPLS was just one piece of mechanism that we used to build this solution: essentially it provided a lightweight mechanism for tunneling packets across the service provider core, much as IPSEC tunnels or Frame Relay circuits were used in other approaches. Much of the real innovation was in (a) multiprotocol extensions to BGP, allowing non-unique addresses from customer sites to be handled correctly by the service provider, and (b) introduction of a large number of VRFs (virtual routing and forwarding tables) into the edge routers, a major implementation effort for the router vendors. There are too many details to cover here, but the important point was that MPLS (as part of this new VPN architecture) finally solved a real customer problem: it changed both the cost and the value of the solution for enterprise VPNs. (The technical details of BGP/MPLS VPNs are, in my admittedly biased opinion, fascinating, and you can pick them up from the very well-written RFC2547 or from the book I wrote with Yakov, MPLS: Technology and Applications.)

There was a lot more to MPLS, including traffic engineering and tunneling layer 2 traffic across the Internet. But for me the important lesson was about the interplay between customer pull and technology push. For about 3 years we really didn’t know whether the technology would even see the light of day. Eventually we solved a big operational problem for service providers, and over time the majority of service providers offered BGP/MPLS VPN services to their customers. Today, we can see ways that it might have been done differently, with software-defined WAN (SD-WAN) solving many of the same problems in a significantly less costly and less configuration-intensive manner. But that required a whole other round of technical innovations to take place first, such as the distributed systems techniques to build scalable centralized control planes. As Eric Rosen said to me more than once: all networking problems are scaling problems. For a while, MPLS was the most scalable solution to a significant networking problem.

---

The title of this article was inspired by a legendary piece of humorous writing by New Yorker authors James Thurber and E.B. White. Last week we published another episode of Coffee with Bruce featuring Ratul Mahajan, in which we took a closer look at network verification. And we’ve been updating the section on active queue management (AQM) in our TCP Congestion Control book, which we are close to committing to print. Take a look and see if you can save us from publishing any typos.