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.