PBT's next priority: Services

At first, PBT was dismissed as merely point-to-point. Now that it's branching out, anther thorny issue is coming into view

LAST YEAR, WHILE PROVIDER BACKBONE TRANSPORT was gaining attention as a simpler alternative to MPLS in metro networks, critics of the Layer 2 technology — including MPLS router vendors — sought to marginalize it by emphasizing it was merely a point-to-point technology, unproven in more complex multipoint networks.

And that was true. The technology works by setting up manually provisioned connection-oriented “tunnels” of reserved bandwidth. It was created essentially by stripping down an existing multipoint Ethernet standard, provider backbone bridging (PBB), and disabling some of PBB's automatic recovery functions to protect those tunnels. As a result, one of the downsides of PBT is that it's ill-suited for things such as multicasting. For that, you'd need to fall back on PBB.

When PBT did become a multipoint technology, critics said, the complexity PBT was designed to ease would be shifted to a software control plane, on which it would rely for provisioning and operating those tunnels. Also true.

This year, PBT vendors are beginning to introduce multipoint versions of their gear, and the lone PBT control plane vendor, Soapstone Networks, is expected to be joined by another, Gridpoint Systems (which has thus far declined interview requests), and in the near term, at least one more entrant.

So now that PBT is multipointed, there will be no more criticism of it as merely a point-to-point technology, right? Well, not exactly.

“Multipoint PBT is an oxymoron,” said Tom Nolle, president of the consultancy CIMI Corp. “PBT by definition is point-to-point. Anyone who says ‘multipoint PBT’ is using a shorthand jargon to say ‘point-to-point and multipoint and multicast services on a physical infrastructure that's a mix of PBT and PBB and other variants of Ethernet.’”

But as PBT evolves at the hands of hardware and software suppliers to shirk off last year's image, attention likely will turn to the services aspect of the technology as PBT's next potential weakness.

PBT SUPPLIERS BEGAN pushing their gear beyond point-to-point applications late last year. Hammerhead Systems — which sells a gateway to liaise between PBT and MPLS equipment — promised new versions of its gear in this year's first quarter that would support point-to-multipoint and multipoint-to-multipoint applications using protocols called, respectively, E-Tree and E-LAN. Nortel Networks echoed the move a month later, promising E-Tree support in its 8600 Metro Ethernet Routing Switch by the first quarter, along with a new processor to greatly increase its capacity (addressing another key criticism of PBT: scalability). And before the first quarter was over, Extreme Networks introduced its own PBT/MPLS gateway module for its BlackDiamond 12800 switches, adding that it hopes to add E-Tree and E-LAN capabilities in the latter half of this year.

Extreme and Hammerhead also announced partnerships with Soapstone, further signaling the growing importance of this new product category known as the PBT control plane.

Nortel, which has demonstrated its PBT gear's interoperability with Soapstone's software, is now testing its own internally developed control plane, which it expects to become generally available by midsummer. Nortel's approach is based on provider link state bridging (PLSB), a link state protocol based on existing Layer 2 standards that populates forwarding tables to construct network pathways for Ethernet services. Layer 2 standards include another link state protocol, intermediate system to intermediate system (IS-IS), a less-popular version of the “open shortest path first” protocol.

PLSB is consistent with Nortel's promotion of using PBT alongside its older sibling PBB, even in the same chassis. PLSB can operate solo or with other control planes based on the Layer 2 spanning tree protocol as “ships in the night” — independent but on the same physical interfaces. Spanning tree is one of the functions of PBB that is disabled in PBT to maintain its tunnels.

“Non-PLSB portions of the network must be able to peer with PLSB at the customer MAC layer or be surrounded by PLSB at the backbone MAC layer,” Nortel wrote in a paper on the subject early last year. “To a PLSB network, the surrounded portion of the network has the same connectivity properties allowed by PBB; it may look like a LAN segment or another type of LAN network.”

Notably, one of the more vocal critics of PBT, MPLS router vendor Juniper Networks, introduced a new control plane strategy this year that could present a competitive foil to PBT while alternately opening a door that could one day lead Juniper itself into the PBT space. In February, Juniper announced the JCS 1200, a physically discrete control plane platform wholly separate from its routers that is designed to let carriers scale their control planes as needed without having to scale the more-expensive hardware associated with data planes. But because it decouples the control plane from the routers in Juniper's portfolio, it mirrors the same division occurring in PBT and thus could ultimately, theoretically, open the door to PBT for the devout MPLS vendor, whose CEO once called PBT potentially “catastrophic.”

“It would be a handy strategy for PBT,” Nolle said of the 1200. “They're going to end up there one way or another, because customers will take them there.”

Luc Ceuppens, senior director of marketing for Juniper's high-speed business unit, said the question of whether Juniper will one day support PBT is “irrelevant” to the JCS 1200's purpose. But he admitted that it would be “technically perfectly feasible” for the 1200 to control PBT networks. “It's just a matter of software,” he said. “External parties could write applications that integrate this type of functionality into the network, just like Soapstone writes applications for PBT control.”

However, while the first task for PBT control planes is provisioning links, it's not clear what will be required of them later on. Vendors and pure-play start-ups alike eventually may be required to take on functionality that requires the expertise of a full-fledged operations support systems (OSS) supplier.

“Ultimately Soapstone, Gridpoint, Juniper and lot of other guys are going to find that the control plane is the camel's nose under the OSS tent for them,” Nolle said. “It's going to keep dragging them higher, and eventually they'll have to find solid partners in that area or be a lot more involved in OSS/[business support services] processes than they are at the moment.”

MEANWHILE, THE NEXT IMPERATIVE for PBT technology, as its proponents vie to elevate it as a true alternative to IP/MPLS, will be to make service creation as clear and straightforward in the PBT world as it is today in IP.

“The real priority with PBT is a service conception problem, service operations,” Nolle said. “If I want to create a service today, I've got to create it through automated tools. That means I've got to have some conception of an end-to-end service that I can describe in a data model and then turn a software program loose on to create it on a physical infrastructure.

“All control plane vendors can do is provision infrastructure,” he added. “They can't create services.”

Juniper can easily jump on this point. One of the benefits the router vendor is promoting in its new JCS 1200 control plane is the ability to create new services, carve out a piece of the control plane exclusively for the new service, test it independently of existing services while sharing the existing hardware, and manage the unique requirements of each service separately but on the same hardware.

In Nortel's approach, services stem from IS-IS, which handles both service discovery and topology discovery. PLSB, meanwhile, secures the network resources needed to deliver those services. “PLSB can therefore be thought of as a sophisticated computation that takes network topology and service information provided by IS-IS as input and produces forwarding tables as output,” Nortel said in a white paper on the subject.

Services are tagged with and identified by headers — bits added to the front of the data packets — that note whether the service is to be unicasted or multicasted. But even for multicast traffic, reverse pathways are provisioned along the same route as the main pathway in Nortel's PLSB network, creating what seems like a bidirectional point-to-point link. This way, Ethernet's existing operations, administration and maintenance mechanisms (OA&M) are left intact, or as Nortel put it, they “just work.”

THE IMPORTANCE OF THE SERVICES ASPECT of PBT often can be overlooked because, in enterprise applications, there's a fine line between infrastructure and services, Nolle said. But he maintained that “if you really want to make PBT and carrier Ethernet the equivalent of MPLS, you've got to have a broader conception of services than carrier Ethernet can currently support.”

One hurdle in applying such a broad conception of services to carrier Ethernet is in establishing network-to-network interfaces (NNIs) at Layer 2, he said. Using Layer 2 protocols such as Ethernet, it can be difficult to make the network control plane coexist with the user's network control. “There's never been any such thing as a Level 2 NNI,” Nolle said. “It's very difficult to create carrier Ethernet services without creating some unpleasant linkages between a user's control plane and the network's control plane that you don't want to have.”

One possible solution, from pseudowire vendors, is to use an enhanced protocol, a sort of Level 2.5, to create a network overlay for carrier Ethernet services. That overlay would operate through tunnels in the network's bandwidth, which would be provisioned by a control plane separate from the one controlling the network's physical infrastructure. Theoretically that might allow carriers to tackle things such as OA&M that have been tough nuts to crack. In fact, Nolle said, these issues overshadow the entire debate surrounding PBT.

“Ultimately the fate of the MPLS versus carrier Ethernet battle — those two rather than PBT — depends on how long it takes the carrier Ethernet people to understand the infrastructure application of Ethernet versus how long it takes for the router guys to figure out how to make a stripped-down version of T-MPLS that's roughly price-competitive with carrier Ethernet,” he said.

The Metro Ethernet Forum, which authored the definitions of the E-Line, E-LAN and E-Tree services, has generally stayed away from transport issues. But it is crossing that line for the first time with an external NNI (E-NNI) that it is currently working on: a common set of specifications that would allow carriers to hand off Ethernet services consistently, retaining all their characteristics, including service quality. And the process to create that E-NNI, still ongoing, is fraught with complex questions about where services are created and measured. At the customer premises? In the carrier network?

Rolling out end-to-end services with PBT control planes is sure to add even more complexity to those questions — more payback, perhaps, for the simplicity of PBT.