By labeling traffic at a lower network level, less processing has to happen at each waypoint between source and destination. It's analogous to color-coding cars on the highway and allowing only blue cars to enter at the Los Angeles on ramp and exit at San Francisco and vice versa. Yellow cars might share the same road from San Diego to Santa Barbara, but they would enter or exit only on ramps flagged for yellow cars.

The transit speed is unchanged -- MPLS doesn't make a 10Mbit/sec. link go to 11Mbit/sec. -- but the entry, routing and exit decisions can be made much more simply and quickly. To send someone to San Francisco, you could give them a blue car, and the network (the road) would get him there without needing to get on and off the highway to ask for directions.

The devil's in the details. RFC 3031 defines MPLS, but it takes a subsequent half-dozen requests for comments to cover the more drowsy topics of label distribution, handling, application and interfaces with other networks. MPLS configuration is, to quote Cisco Systems Inc. strategist and customer liaison Azhar Sayeed, expensive and tedious, which is why the technology has been the domain of carriers for the better part of a decade.

It's misleading, then, when uninformed LAN administrators think an MPLS connection "just works." Simply plugging two network endpoints into a carrier's MPLS cloud may allow those networks to communicate, but without some attention, anyone else connected to the cloud may also be visible.

In more than one instance, an organization with just a couple of private IP, Class C subnets (192.168.1.x and 192.168.2.x, for example) discovered dozens of other subnets (such as 192.168.50.x) with thousands of live hosts. Its MPLS router was smart enough to sort out subnet mapping when the IP traffic from other sites was "popped" out of the MPLS cloud on the their side (avoiding wholesale IP collision), but without configuration to indicate otherwise, it was just one big happy network.