Service providers demonstrate a curious attitude when it comes to Multi-Protocol Label Switching (MPLS). Almost all agree they need it, yet almost none are actually using it, yet.
Part of the problem has to do with the fact that it's hard to identify precisely what MPLS can and should be used for. To some, it's primarily a way of achieving quality of service in an all-IP network. To others, it's a way of easing the transition from ATM to IP in the network backbone. Still others see it as the most efficient way of building virtual private network applications. The truth is, MPLS can do all of these, and more, which is why it's arguably the most important protocol being considered in the public network today. But unless carriers, service providers, and even enterprise users can gain a clear understanding of its capabilities, and develop concrete plans for its implementation, it risks becoming ineffectual.
Of course, as with almost any new technology at the network core, change doesn't happen overnight. While MPLS has been a part of the IETF in draft form since 1997, and has existed in proprietary implementations (notably, Cisco's "tag switching") for even longer, it is only now beginning to see the light of day in actual network deployments.
A recent Infonetics Research study showed that only two of nine (or around 22%) tier-one U.S. carriers interviewed have so far deployed MPLS in their networks, though half are planning deployments within a year (see figure 1). Of tier-two carriers surveyed, around 65% (15 of 23) said they planned to implement MPLS by next year. Kevin Mitchell, directing analyst of Service Provider Networks for Infonetics, notes that these numbers, while showing a clear trend toward greater adoption, still only reflect partial deployments in limited segments of the network. "Obviously, these carriers are not implementing MPLS throughout their networks," Mitchell said. "What we'll see is a staged rollout, spread out over multiple years. ... For the next year or year-and-a-half, the implementations will take place only in islands of the network."
This reticence can be traced in part to the inevitably drawn-out process of standards making. Indeed, most agree that MPLS standardization and interoperability has proceeded more slowly than vendors and carriers would have liked. Some have even suggested that the standard was over-engineered, and has become more complex than it was originally intended to be. But the biggest factor that seems to be keeping service providers from deploying MPLS more rapidly is related to what's in their networks already, not to what the advocates of MPLS propose to introduce there. At this point, MPLS has no direct rivals. Protocols like RSVP and DiffServ are, by and large, seen as complementary, not competitive. What MPLS must contend with, however, is the status quo: For most major carriers in this country, this means an installed base of ATM in the backbone of their networks, along with frame relay as a means of establishing connections to subscribers.
Though this could suggest that MPLS is incompatible with ATM or frame relay transport, that isn't true. While generally associated with an IP network, MPLS was, in fact, designed to be protocol agnostic at both layer 2 and layer 3, where IP resides: hence the name, multi-protocol. The "labels" that form the core of MPLS can be applied to the front-end of an IP packet header (forming what the standard calls a "shim header") just as easily as they can map onto the VPI/VCI field of an ATM cell header or the DLCI field of a frame relay address. Generally, MPLS is viewed as a merger of layer 2 and layer 3 technologies, or often as a way of introducing a "connection-oriented" switching paradigm into the fundamentally "connection-less" world of IP routing. While not inaccurate, these descriptions tell only part of the story. In reality, MPLS can serve a number of different purposes, each depending on the type of network in which it is deployed, as well as the applications that are to be carried over that network.
Between, or Beyond, Two Networks
For those who want to characterize MPLS as somewhere "between" switching and routing, the two most useful points of reference are ATM virtual circuits on the one hand, and OSPF on the other. OSPF stands for Open Shortest Path First, and describes the way IP routers determine the next hop for packets along the network, comparing the packets' destination IP addresses against large-scale forwarding tables. As the name indicates, OSPF gives priority to the shortest available path for getting a packet from point A to point B. Each router hop that a packet takes as it traverses the network will replicate this process of table lookups and forwarding. Of course, this model raises some fundamental scalability issues as the size of routing tables increases, though ASIC-based routing technology is more capable than legacy software of maintaining routing tables while still performing at wire-speed. What OSPF lacks, however, is any deterministic method for establishing routes or distinguishing between packet flows.
An ATM VC, by contrast, entails a simpler, intrinsically faster routing mechanism that reduces table sizes, eliminates complex route decision-making, and is even easier to translate to silicon. Virtual circuits are pre-determined and pre-provisioned routes, linking multiple network elements. Deciding on the path a virtual circuit should take requires more up-front network engineering than connectionless approaches, and, in many cases, some manual intervention with equipment. But once a VC is established, it's arguably less taxing on the network elements (primarily switches) involved.
MPLS draws from both approaches, and has applications in both pure ATM and pure IP environments. In each case, it offers a direct response to the network's shortcomings. When MPLS is used under IP, it can eliminate the overhead of packet-by-packet route processing in portions of the network where dynamically assigned, connection-by-connection routing or deliberate path engineering produces better results. Under ATM, it can produce better scalability and more efficient provisioning mechanisms than the more static, permanent virtual circuit configurations. It can also be used to provide a "VC aware" integration plane between IP edge networks and pure ATM cores.
The latter application - MPLS in hybrid transport and multi-protocol networks: networks comprising elements that speak pure IP, frame relay, ATM, or layered combinations of same - is what carriers are looking forward to in the immediate future. Sure, the general (or at least the most visible) trend is toward end-to-end IP; but in the meantime, and it could be a very long one, packets will be swirled around with a mixture of circuits, frames, and cells, and the network will have to negotiate between them. To avoid reduction to a "least common denominator" scenario, or a network that takes on the worst qualities of each of these elements - IP-over-ATM, though widely used, is a good example - it would be nice to have a protocol that creates some consistency and adds some efficiency into the mix. Enter MPLS.
