Ethernet equipment

A Guide to PBT/PBB-TE

There’s no denying that vendors are divided on whether to support PBT/PBB-TE. Table 3 gives a very high-level indicative snapshot of what might best be called directions in the support by some vendors for PBT/PBB-TE and the various flavors of MPLS. It must be stressed that 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. Also (and obviously) Table 3 is not a systematic survey of the entire industry.

Table 3: Some Vendor Support for Different Connection-Oriented Technologies
Accedian Networks Transparent Transparent No On roadmap Working on future PBT/PBB-TE support
ANDA Networks Yes No No Yes Considering T-MPLS
Alcatel-Lucent Yes Yes Yes No
Atrica Yes No No No
Ceterus Networks Yes Maybe Maybe Yes
Ciena Yes No No Yes
Cisco Systems Yes Yes No No Supports PBB; monitoring PBB-TE
Corrigent Systems Yes No Yes No
ECI Telecom Yes Yes Yes No Supports PBB
Ericsson (Redback) Yes Yes Yes No
Ethos Networks No No Maybe Yes Considering T-MPLS, VPLS
Extreme Networks Yes No No Yes
Foundry Networks Yes Yes No No
Hammerhead Systems Yes No No Yes
Hitachi Cable No No No On roadmap Providing EoE (Ethernet over Ethernet) Working on future PBT/PBB-TE support
Huawei Technologies Yes Yes Yes Yes
Juniper Networks Yes Yes No No
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
Nortel Yes Yes No Yes
Tellabs Yes Yes Yes Yes
Telco Systems Yes Yes Yes No
Telrad Networks Yes No No Yes
World Wide Packets Yes No No Yes
Zhone Networks No No No On roadmap Working on future PBT/PBB-TE support
ZTE Yes Yes Yes No
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
Broadcom Network processors
EZChip 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
Soapstone Networks OSS
Spirent Communications Test and measurement
TPACK Systems VPLS/PBT/T-MPLS switch chips based on FPGA for flexible upgrade
TranSwitch Ethernet switch ASICs
Xelerated Network processors
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."

Running costs
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."

Next Page: Technology Challenges, Part I
Previous Page
7 of 10
Next Page
xornix 12/5/2012 | 3:44:09 PM
re: A Guide to PBT/PBB-TE Is ANY retail service inherently Ethernet? I think NOT which means PBT/PBB-TE can only be used as a transport technology without any relation to the service itself.

In tier 1 ISP networks, there is probably a case for PBT backhaul as MPLS may be a bit hard to scale and operate down to the access, but that's all I can see as:
-the access needs IP aggregation
-the core needs IP routing

If you are focused on business services, this is obviously a completely different story.

What is BT focused on?
Sign In