Table 3: Some Vendor Support for Different Connection-Oriented Technologies
|Vendor||Layer-2 MPLS||Layer-3 MPLS||T-MPLS||PBT/PBB-TE||COMMENTS|
|Accedian Networks||Transparent||Transparent||No||On roadmap||Working on future PBT/PBB-TE support|
|ANDA Networks||Yes||No||No||Yes||Considering T-MPLS|
|Cisco Systems||Yes||Yes||No||No||Supports PBB; monitoring PBB-TE|
|ECI Telecom||Yes||Yes||Yes||No||Supports PBB|
|Ethos Networks||No||No||Maybe||Yes||Considering T-MPLS, VPLS|
|Hitachi Cable||No||No||No||On roadmap||Providing EoE (Ethernet over Ethernet) Working on future PBT/PBB-TE support|
|Meriton Networks||No||No||(Yes)||Yes||T-MPLS is supported but not productized in initial release -- monitoring progress with standards and service providers|
|MRV Communications||Yes||No||Yes||On roadmap||Software upgrade for T-MPLS|
|Nokia Siemens Networks||Yes||Yes||No||Yes|
|World Wide Packets||Yes||No||No||Yes|
|Zhone Networks||No||No||No||On roadmap||Working on future PBT/PBB-TE support|
|Note: A "Yes" against several technologies does not necessarily mean that the vendor has a single platform that supports all the technologies (although this may be the case), but only that the vendor has, or plans to have, products that do, or will. Sources: Light Reading, 2008|
Nevertheless, it’s clear that PBT/PBB-TE has garnered support across a spectrum of different types of vendor, from established major infrastructure players to smaller specialists and startups. Also, what might be termed the support environment – the chipsets, NMS/OSS, and test and management, for example – is strengthening. (See Table 4.)
Table 4: Some Vendors in the PBT/PBT-TE Support Environment
|Vendor||PBT product areas|
|Amdocs||OSS -- planning, activation, operation|
|Aria Networks||OSS -- planning, activation, operation|
|Bay Microsystems||Network processors|
|Gridpoint Systems||OSS -- traffic engineering|
|InfoVista||Network performance monitoring|
|Ixia||Test and measurement|
|JDSU||Test and measurement|
|Lightstorm Networks||PBT-optimised Ethenet switch ASICs|
|Spirent Communications||Test and measurement|
|TPACK Systems||VPLS/PBT/T-MPLS switch chips based on FPGA for flexible upgrade|
|TranSwitch||Ethernet switch ASICs|
|Source: Light Reading, 2008|
At root, much of this disagreement stems from whether a vendor has – from commercial, historical, technology, or product reasons – a largely transport- or router-oriented view of the market. However, even the most hardened PBT/PBB-TE protagonists don’t see carrier Ethernet and MPLS as an either/or decision. Nortel's Hawkins goes on to stress that the relationship between MPLS and carrier Ethernet is likely to be symbiotic for some time. MPLS as a service (for example, pseudowire services) can transparently traverse a carrier Ethernet network through, for example, PBT-defined tunnels to create an end-to-end service for the end user.
"And currently deployed MPLS core infrastructures aren’t going anywhere," says Hawkins. "Surrounding such cores with carrier Ethernet MAN deployments avoids the complexity and allows seamless and straightforward interworking, which maintains the carrier’s investment in the core and avoids the added cost of extending MPLS infrastructure in the metro."
Big router vendors, such as Cisco and Juniper, tend to be lukewarm. Obviously, if the technology really takes off, they will have to support it, but for the moment it seems to be a matter of watching developments, supporting various aspects of carrier Ethernet (such as PBB itself), and heavily promoting business as usual with MPLS.
Cisco’s Hood points out that his company is seeing customers wanting to tie Ethernet at the very edge of the network into their MPLS network, and to do so in a scalable way. This is why Cisco does support technologies such as PBB and 802.1aq and works to find ways to do standards-based protection for Ethernet. However, he wonders if PBT/PBB-TE has wider applicability than just providing basic native Ethernet transport tunnels for specific, simple uses such as backhaul.
"We are not against this thing – it is an evolutionary process of getting Ethernet to do things and be traffic engineered in the WAN space," Hood says. "We have emulated Ethernet over just about everything already – over Frame Relay, ATM, MPLS, and VPLS – so the question is whether we can do it in its native form in a better fashion than we have with MPLS. We think we will at some point, but it will likely take some additional technologies that don’t exist at the moment."
For example, he says that current platforms that combine transport and packet functions typically perform packet forwarding on the blade, rather than on the backplane as with a dedicated router, and so inherently face a scalability issue. Similarly, PBB-TE could well evolve into a full multipoint traffic-engineering standard, which means that it would have to include the data plane, the forwarding plane, path computation, signaling, and traffic engineering – all of which exist within MPLS today. In contrast, the IEEE has not yet launched a project to cover PBB-TE signaling and topology aspects (although there are proposals, such as provider link state bridging [PLSB]).
Lurking behind the divergent transport and routing/switching views is perhaps a fundamental issue of modern telecom architectures: At root, how separate should the service and transport planes be? There will be disagreements over something that so closely interweaves engineering theory and practice.
"PBT, T-MPLS, and MPLS are actually compatible, if one subscribes to the view that service and transport networks should be separate, independently scaleable, intelligent networks," says Tpack's Barry. "This is not a view supported by all. Router vendors in particular see IP/MPLS providing both service and transport capabilities in a single network. However, many carriers agree that separation is necessary for scalable deployment of multiple, dynamic packet-based services – so a dynamic IP/MPLS services network with autonomous routing capabilities but supported by a reliable, deterministic transport layer."
In another direction, David Boland, senior product marketing manager for Juniper's MX-Series Ethernet Services Switches, questions the cost savings promised by PBT/PBT-TE. "PBT proponents claim that it can offer significant operational-expenditure savings compared to MPLS, which is unproven and questionable considering the increased cost associated with an OSS-driven control plane, as well as the additional cost to add services via a different service layer like MPLS," he says.
And, as Light Reading has reported, MPLS itself can be improved in capabilities for network performance monitoring and performance management, for example, making the OSS aspect of comparison even more critical.
The question remains: Do PBT/PBB-TE’s cost efficiency claims really stack up, especially as they affect operations? That's the latest bugbear, and the one that is being stirred up by the anti-PBT camp, since many cost comparisons so far have been based mainly on a comparison of the switch and router capital expenditures. It looks, so far, as if no one really knows for sure, so we'll end this page with a few vendor views:
- "The PBT camp has claimed that the forwarding plane itself is much cheaper to build, therefore driving down capex cost. We don’t believe this is true today, and definitely not in the medium term. It’s no harder for a network processor to process an Ethernet over MPLS frame than it is for it to process a MAC-in-MAC frame," says ECI Telecom’s Brayley.
- "Cost and efficiency are very strong motivators in this market and much of PBT’s success would rely on whether it would succeed in remaining simple and low-cost. Another very important aspect of PBT is its management style," says Ethos Networks’s Dunsky.
- "The cost/efficiency claims are one of the major considerations, though as long as it continues to be cheaper than pure routed MPLS architectures there will be at least a niche for PBT," says ANDA's Gum.
- "The key issue is what you need to support at each node to implement a carrier Ethernet network," says Tpack's Barry. "If you deploy a router, you need to pay for all of the features available at every point in the network, whether you use them or not, whereas PBT and T-MPLS do not need signaling at these nodes. This is also the case with the network management system, which is deployed once centrally no matter the size of the network. In this regard it scales very well, whereas an autonomous router network requires signaling at each node, and also at those that are added later."
- "With the emergence of connection-oriented Ethernet (PBT/PBB-TE) and its integration into flexible multiplexing and grooming at the Ethernet and optical layers, the optical industry is now able to deliver significant capex and more importantly opex savings across a new packet optical transport network," says Meriton Networks’s Davison. "Add to this carrier-grade predictability, traffic engineering and fast restoration, and service providers have a more intelligent and flexible alternative architecture to big dumb pipes over IP."