Multi-protocol Label Switching (MPLS) has become one of the hot new technologies - a darling of IP and ATM vendors, espoused by edge and core players alike. It even has its own forum, a sure sign of success in this marketplace. But MPLS may be at a fork in the road to dominating the future of networking, and it may have already taken the wrong turn.
When MPLS arose in 1996, an offshoot of Cisco Systems Inc.'s Tag Switching and other IP-switch protocols of the time, it was given to the Internet Engineering Task Force (IETF) for standardization. In the framework document published that year, MPLS was presented as a label-switching architecture suitable for any protocol. This universality was to be achieved by having the label-switching process take place without referencing the content of the data packet (so there's no protocol-specific handling) and by having the data-handling layer of MPLS separate from the control layer. That way, multiple control layers (one for each protocol) could be supported. Great concept.
Lousy execution, though. The IETF, not surprisingly, has focused almost entirely on MPLS as a subset of IP networking. Having an IP bias for MPLS may have been acceptable in the past. But now that the dot-com frenzy has collapsed, capital markets are questioning the revenue basis for the Internet and Cisco stock is dropping to the teens, shouldn't MPLS be looking for a broader constituency?
Case in point: The regional Bell operating companies are eventually going to build a toll network to support their entry into the long-distance market. Not surprisingly, the RBOC plans for these networks seem uniformly based on ATM, not IP. Can MPLS fit into that scheme?
Sure, you say. MPLS was supposed to be the big mediating technology between IP and ATM, after all. The problem is that the MPLS folks have neglected the strategy for evolving an ATM network into an MPLS network. When you stick an MPLS label switch router (LSR) - the MPLS name for a node or device - into an ATM network, the rest of the network expects the LSR to speak ATM's signaling and addressing language. However, the LSR, if it follows the IETF specs, expects to speak IP. Where is the ATM control plane that MPLS was supposed to be able to support? Where are the MPLS mechanisms to create label-switch paths using ATM addresses?
Some vendors have provided at least partial relief for this problem. Cisco's MGX ATM switches can use IP procedures to support MPLS path setup even in an ATM network - if you want IP-based addressing in the network. Lucent Technologies Inc.'s new 25000 switch is a true MPLS switch that can serve as an IP or ATM core device. But how either would work in a multivendor network, without supporting standards, is anyone's guess.
So here's the bottom line: MPLS might well become a casualty in a market where the Internet isn't perceived as the big revenue opportunity driving infrastructure deployment. Such a market would tend to install non-IP gear (such as ATM switches), and MPLS' value as an upgrade path in the deep core of an ATM network isn't supported by the way standards are developing.
The problem of ATM/MPLS compatibility might affect some of the emerging MPLS-based equipment vendors, whose products are based on the standards but lack specific ways of creating an ATM service framework across ATM and MPLS devices. The ATM part of the network won't talk IP, and MPLS demands it. It might also affect carriers and users, whose expectations for MPLS could flounder on the simple fact that the promise of the original framework documents defining MPLS direction weren't really met by the standards that have developed since.
ATM/MPLS interworking is real, but interworking with another network technology isn't the same thing as integrating with it. If we expect to really benefit from MPLS under all the possible scenarios for the evolution of network infrastructure, we'll have to get the non-IP portion of the standards up to par.
Nolle is president of CIMI Corp., a technology assessment firm in Voorhees, N.J. He can be reached at firstname.lastname@example.org