PBT vs. MPLS: What if nobody wins?

PBT (or PBB-TE if you're a purist) has been a technology darling in the media for a year, but it suffered a setback when it was reported that both Verizon and BT had decided not to use it. (PBT stands for "provider backbone transport," and PBB-TE is "provider bridging backbone -- transport engineering.")

Then, almost the next day, Verizon said it was using PBB (which is the superstandard that PBT derives from) after all. Who wins the PBT/MPLS wars? Quite likely neither, because the fight may change how networks move data.

Networks are about connection relationships, and forwarding tables create them. These tables are just lists of destinations and routes, with the "destination" part in the form of some sort of address. IP routing uses IP addresses, Ethernet routing uses media-access-control (MAC) addresses, and so forth. The gadget that routes traffic reads a message, looks up the destination address in the forwarding table and forwards accordingly. It's like a single handler in a bucket brigade; not much more than a brute-force process. All the real intelligence of any network protocol goes into populating the table, and the current PBT wars have made everybody think of that function as something above the network in the "control plane," more than inside it. That's pretty transforming in itself.

How long now will it be before somebody builds a "forwarder" that is neither a switch nor a router but could function as both? If we look at the PBT and Transport MPLS (T-MPLS) pictures, they differ mostly in what does the packet-forwarding. PBT guys think that's an Ethernet switch, router guys an MPLS router. Both are wrong, however; it's a bunch of simple handlers pushing buckets around. Such a forwarder can be a T-MPLS device, a PBT device or both.

Or neither. We also can think of this as routing sessions, or flows, or traffic routes, or calls or anything else. As long as you extract some sort of "address" and look it up properly, you know what to do with the traffic. You can use IP addresses, MAC addresses, phone numbers, session IDs, anything you like -- as long as you can make a forwarding table out of it. And you can do it with optical or electrical technology or whatever you like because the basic engine is always the same: Look up an address and handle accordingly. Sure, it has to scale, but we'll get to that in a minute.

The second impact here is that the separation of the control plane means you can have control-plane competition, which is a lot easier to create than competition in forwarding terabits of traffic. There are already two start-ups (GridPoint and Soapstone Networks) in the control-plane space. When was the last time you saw a start-up router vendor? Competition here is possible and maybe even profitable, because there are a lot of opportunities for differentiation.

Now to the issue of scale and overall architecture. In the network of the future, a forwarder doesn't have to know about everything else in the network, or even much at all. Let's suppose that every metro area has a giant aggregation network that hands traffic off to a single central point. All these central points are linked to each other using mesh optical trunks. This is practical even now with dense wavelength division multiplexing; there are about 250 standard metropolitan statistical areas in the United States, for example.

Now envision "IP forwarding." The giant aggregation boxes have to know which access link reaches the subnets on them, and which other metro area contains the other subnets. I can populate that kind of forwarding table pretty easily because while IP address come and go, their subnets aren't as dynamic. A control plane can update the subnet assignments to each of the "superboxes," and the rest of the network just works on the simple subnet-to-metro linkage.

If we want to make the forwarding tables very dynamic, we can set up a new entry for a session, a special FTP flow or whatever we like. Any control-plane activity can create an update to the forwarding tables, and because we don't have to propagate these tables adaptively from device to device (the control plane is pressing them down to all), we don't have to worry about flaps and delays in getting a network-topology picture into all the nodes that matches and works together Applications that control the control plane control the network, and forwarding (the major capital cost of networking) is largely insulated from any changes that new applications and services bring about.

Obviously, multiple providers makes the real picture more complicated; what works for one can be made to work for many. My point here is that the modern conception of networks is based on connection relationships, not on protocols; and anything that can create connection relationships can create forwarding rules in an independent control plane. Services and networks are bound, not by forwarding behavior but by control-plane rules and policies. All the innovation in networking polarizes to chips at the bottom and software at the top.

This is a future that a lot of people are going to love to hate and will dispute, but they're wrong. It's inevitable because it is already happening, one control-plane-independent step at a time. In fact, at the same time that Juniper Networks was separating IP forwarding from IP control, Ipsilon Networks (remember it?) was proposing something very much like this and calling it "IP switching." That was too much of a leap in the mid '90s (and it later morphed into MPLS), but it seems to be the direction we're heading -- whether vendors like it or not.

Learn more about this topic

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2008 IDG Communications, Inc.

IT Salary Survey 2021: The results are in