Transport wars: MPLS-TP vs PBB-TE

It's never a dull moment in the ongoing quest to transform the world's TDM grid into sleek, efficient packet-based networks - particularly when it comes to transport. Sonet/SDH may be from the circuit-switched old school, but it has set the standard for reliability, manageability and scalability that carriers need to run their networks at 'five nines' level reliability - a benchmark that packet-based technologies have struggled to match.

Take Ethernet, which has long been championed as the most cost-efficient and simplest architecture for the packet-based future. But getting even carrier-grade Ethernet to perform its magic at the transport layer has been a struggle. Ethernet by nature is a connectionless technology - to beat Sonet/SDH, it needs to be connection-oriented.

'With Ethernet or any sort of packet-based technology, the advantages you get with it are statistical multiplexing, and you can look at multiple flows of information, which is acceptable for data traffic,' explains Tom Goodwin, marcoms VP for the optics division of Alcatel-Lucent's carrier business group. 'But when you get more delay- or jitter-intolerant apps like video and voice, you really need that connection-oriented parameters that you get with the TDM control plane parameters that can better deliver quality of service, but have flexibility to pack more packet traffic more efficiently into the network.'

As usual, telecoms vendors have rallied around two competing standards to make this happen.

On the one side has been the ITU-T, whose Study Group 15 took MPLS - the technology standard created by the IETF over a decade ago that's running on networks worldwide - as a starting point and has labored to develop Transport MPLS (T-MPLS), a stripped down version suitable for connection-oriented transport.

On the other side has been the IEEE, the industry group behind Ethernet's evolution from a technology suited for office LANs to an increasingly preferred technology for metro networks and backhaul links. Their technology, PBB-TE (Provider Backbone Bridge - Traffic Engineering), is a native Ethernet approach that comes with the usual Ethernet promises of greater simplicity and lower cost.

Both have their pros and cons, but one con that they have shared is lack of standardization. By that measure, PBB-TE (whose draft standard nomenclature is 802.1Qay) was at the biggest disadvantage, as work on T-MPLS was expected to be completed sooner. On the other hand, T-MPLS had one distinct problem of its own: it was completely incompatible with existing MPLS.

Now there's a new twist in the saga. In April this year, the ITU-T - realizing that T-MPLS with compatibility problems was going to be a hard sell - set up a joint working team with the IETF to come up with another approach. Result: T-MPLS was officially scrapped in June in favor of MPLS - Transport Profile (MPLS-TP), and some vendors are claiming that it's so good that PBB-TE now doesn't stand a chance.

The death of T-MPLS

To understand the case for MPLS-TP, it's worth looking a little more closely as to what was wrong with T-MPLS.

'Basically, T-MPLS was an attempt to enhance MPLS but it was done by a different body [the ITU-T],' says Pekka Viirola, head of technology for the IP transport business unit of Nokia Siemens Networks.

 

'The unfortunate result was that T-MPLS was not compatible with MPLS.'

The problem, Viirola says, was that T-MPLS disabled some MPLS features, such as label switched path merging, which helps to identify traffic streams so that operators know what traffic what is going where, and equal cost multipath (a routing strategy where next-hop packet forwarding to a single destination can occur over multiple 'best paths') so operators know where their routers are going to send packets.

'The assumption was that transport and service networks would be separate, and you'd have separate data planes for each, so it wouldn't matter,' he says. 'The concern about this assumption was that if by chance T-MPLS networks connected to MPLS networks, it would cause major disturbances.'

Monique Morrow, distinguished consulting engineer and Asia-Pacific service provider CTO for Cisco Systems, puts it more bluntly.

'Had T-MPLS gone forward, the results would have been breaking the MPLS forwarding paradigm, jeopardizing the value and function of the large scale of deployed MPLS networks and equipment, and the potential to destroy a multibillion dollar industry as a whole,' she says.

Consequently, the ITU-T/IETF team decided to work within the existing IETF MPLS architecture and extend it via a transport profile to cover transport functionality, the goal of which is 'to provide what has been termed as a unified OAM for MPLS and pseudowire,' says Morrow.

'Under the transport profile, MPLS would be extended to cover forwarding, OAM, server viability and network management as well as control plane protocols,' adds Viirola of NSN. 'The upside is that interoperability with MPLS can be guaranteed.'

The downside, according to Telecom Strategy Partners, is that MPLS-TP sets back the standardization process for the pro-MPLS camp even further. 'It will likely take 18-24 months to get an official standard for MPLS-TP in place,' the firm said in a recent report, which could mean 'potential delays in market availability.'

That's potentially good news for the IEEE, which is reportedly on track to have standards specs for PBB-TE ready as early as Q1 2009, although Alcatel-Lucent's Goodwin says final draft specs for MPLS-TP could be ready by the middle of next year. Viirola of NSN puts the ETA at a more conservative end of 2009.

That said, Viirola adds that this won't matter much to operators looking at pre-standard deployments, since MPLS-TP is 'an extension on an existing mature standard, and requirement specs will be available earlier.'

More to the point, adds Morrow of Cisco, it's what operators want. 'Our own customers have fundamentally been telling us that MPLS is what they want to use because it's the same technology they've deployed in their cores.'

What this means for PBB-TE is unclear. While vendors like Nortel Networks - one of the primary developers and champions of PBB-TE (which is based on Nortel's proprietary PBT technology) - have stuck to their guns on its viability, other vendors that initially jumped on the PBB-TE bandwagon - notably Huawei Technologies and NSN - have since abandoned it and are now pushing MPLS-TP as the way ahead.

Fractured landscape

 

BT - the first big-name operator to proclaim support for PBB-TE last year - also seems to have backed away from the technology. Earlier this year, the telco revamped its 21CN strategy and swung back to the MPLS camp.

However, despite claims from some vendors that the industry is now 'rallying' around MPLS-TP, some carriers (albeit few) are buying PBB-TE related equipment. Sprint recently awarded a PBB-TE contract to Ciena for its Wimax backhaul, while Verizon plans to deploy Nortel's PBB gear for its metro Ethernet backbone. (PBB isn't transport-level technology, but it's typically promoted as a 'natural first step' towards PBB-TE, which is based on PBB.)

Goodwin of Alcatel-Lucent (itself a major supporter of MPLS-TP) says that what carriers deploy at the end of the day depends largely on what they've already got installed and what they're doing with it.

'When you talk to any carrier and ask them if they want to go with MPLS or PBB-TE for transport, everyone has a different opinion on this,' Goodwin insists. 'Some carriers have MPLS and run Ethernet services through MPLS and VPNs, but some customers have MPLS networks connecting into metro Ethernet networks supporting PBB, so there's an edge point where you have to do PBB/MPLS translation. And then other carriers are doing point-to-point Ethernet over SDH that provides carrier-class Ethernet capability for corporate-branded environments across town, and they realize there are limits to MSPP when they get to 40% Ethernet data penetration.'

Some analysts also speculate that MPLS-based transport is really a short-term solution. Ovum analyst Mark Seery says that while an MPLS-centric strategy has its good points, 'it is nonetheless a path that has its roots in 20th century ideas of minimizing protocol overhead and enhancing switching performance - issues that are not as significant in the 21st century as they were in the 20th century.'

Seery says that PBB-TE has the edge over MPLS on several levels: 'It adds more information than MPLS in the traffic plane and is less ambiguous in its use of semantics in the traffic plane. PBB/PBB-TE is also better optimized for transporting Ethernet than MPLS and as a result naturally solves Ethernet scaling problems that MPLS does not.'

However, Seery points out, carriers also have to live with the current realities of running a business, and speculates that BT's decision to forsake PBB-TE - and the reason other operators will probably do likewise - is, simply put, because it's faster and easier to go with an MPLS strategy.

Indeed, according to Light Reading, Tim Hubbard, head of 21CN Technology and Platform Introduction at BT, said at the Carrier Ethernet World Congress in September that part of the strategy behind its rethink was to deploy services that our customers want 'more quickly' - especially for mobile backhaul, which BT initially intended to fortify with PBT but instead opted for Ethernet over pseudowire because 'it was the only way to deliver the service on time' to its cellco customers.

Meanwhile, at the same congress, vendors could already be seen squabbling over which way to take MPLS-TP. One area of contention: whether carriers should invest in T-MPLS now as a starting point, with the idea that they can get a head start on packetizing the transport network and evolve from there to MPLS-TP with a software upgrade. The idea will be tempting to some carriers, but as one anonymous operator executive quoted in the Telecom Strategy Partners congress report observed: 'It's never 'just a software upgrade'.'

Suggested Articles

Wireless operators can provide 5G services with spectrum bands both above and below 6 GHz—but that doesn't mean that all countries will let them.

Here are the stories we’re tracking today.

The 5G Mobile Network Architecture research project will implement two 5G use cases in real-world test beds.