Ethernet equipment

PBT: Alive 'n' Kicking

BERLIN -- Carrier Ethernet World Congress -- When independent analyst Mark Lum told the audience here Tuesday morning that the "heat of the technology wars has dissipated," he clearly hadn't consulted his crystal ball, as the rest of the day was replete with verbal battles between the Provider Backbone Transport (PBT or PBB-TE) and Multiprotocol Label Switching (MPLS) camps, just as it was a year ago. (See Vendors Clash Over PBT.)

The MPLS camp is determined to write PBT's obituary. Even former supporters of the controversial Ethernet technology, such as Huawei Technologies Co. Ltd. and Nokia Networks , are keen to dig PBT's grave now that they are no longer championing the still pre-standards flavor of Ethernet. (See Nokia Siemens Gets Ruthless on R&D Focus and Huawei Joins PBT Fan Club.)

On numerous occasions in conference presentations and one-to-one briefings in Berlin, PBT's relevance was called into question or dismissed.

The MPLS camp's alternative to PBT, of course, is MPLS-TP (transport profile), another pre-standards technology that is being pushed hard here by the likes of Nokia Siemens, Cisco Systems Inc. (Nasdaq: CSCO), and Alcatel-Lucent (NYSE: ALU). (See Transport MPLS Gets a Makeover.)

But PBT is alive, and even kicking: The news that Sprint Corp. (NYSE: S), widely regarded as a Cisco shop, is deploying equipment from Ciena Corp. (NYSE: CIEN) to use PBT for WiMax traffic backhaul was a boost for the technology's supporters, who say there are more such announcements to come. (See Sprint Joins PBT Club, Tejas Launches PBT Platform, and Extreme Goes for Ethernet Glory.)

And while BT Group plc (NYSE: BT; London: BTA) famously revised its PBT-based strategy earlier this year, the technology has not been altogether abandoned by the British incumbent and is still set to be used in certain point-to-point scenarios, such as data center connectivity and data backhaul, in the future. (See PBT Sidelined at BT and Nortel: There's More to PBT Than BT.)

Tim Hubbard, head of technology and platform introduction within BT Design (which designs and builds the carrier's core and metro infrastructure), says BT continues to "explore and evaluate" new technologies. Addressing attendees here in Berlin, he said BT's decision to adopt an MPLS-based Ethernet service strategy was dictated by the need to build and launch new services quickly.

Responding to questions about whether BT would ultimately deploy PBT, MPLS-TP, or both, he stated: "We're still evaluating the technologies to see how best they might be used to meet customer needs. What we are not doing is building a platform then figuring out how to use it," something that BT had planned to do when it introduced PBT into its 21CN strategy a few years ago. (See PBT Stars at Ethernet Expo and Nortel, Siemens Win PBT Deals at BT.)

But the real coup for the PBT camp came from Dr. Alireza Mahmoodshahi, the CTO of Colt Technology Services Group Ltd , and one of the European carrier Ethernet sector's most prominent figures.

Mahmoodshahi gave a presentation outlining COLT's new network deployment, which is based on Nokia Siemens equipment and which, ultimately, will deploy MPLS-TP for packet transport. (See More Rides Coming on Colt's NGN and Colt Unveils NGN Vendors.)

But that didn't stop the CTO from noting that "there are a lot of opportunities for PBB and PBT in backhaul -- it's the cheapest way to do that, no doubt."

That cost message, along with the SDH-like management claims, is exactly what PBT's supporters, still led by Nortel Networks Ltd. , are stressing in their messaging. Mark Canepa, CEO of Extreme Networks Inc. (Nasdaq: EXTR), which has just unveiled its new high-capacity carrier Ethernet switch, says the proposition is all about lowering capex and opex in metro networks as carriers deal with the growth of data and video traffic, while his chief marketing officer, Paul Hooper, adds, "The cost factor is very important in metro networks -- there are a lot of ports." (See Extreme Goes for Ethernet Glory.)

— Ray Le Maistre, International News Editor, Light Reading

davallan 12/5/2012 | 3:31:23 PM
re: PBT: Alive 'n' Kicking Difference between PBT and MPLS-TP is PBT already had 802.1ag and Y.1731 pretty much done & dusted for OAM when it was first proposed in 2006. MPLS-TP has only requirements docs for OAM at the moment.

In other words, do not hold your breath...IETF takes a looooong time on OAM...

t.bogataj 12/5/2012 | 3:31:16 PM
re: PBT: Alive 'n' Kicking Dave, hold your breath and admit two things.

First, PBT was presented to IEEE in September 2005 (by Nortel's Allan, Bottorff, Mohan, and BT's McGuire) -- not in 2006 as you state. Does it matter? Not really, unless you note that BT "discovered" it with admiration half a year later.

Second, PBT camp largely ignored what was already done or underway in OAM (Y.1731 and .1ag) in 2006. To mention only a few changes to OAM, requested by and necessary for PBT: unicast ETH-CCM instead of multicast, (bi-)directional ETH-LBR, VID exchange in ETH-LBM, operation of ETH-LT on (bi-)directional paths, etc. In addition to OAM, APS mechanisms (e.g. G.8031) also need to be revised to work with PBT.

At the moment, PBB-TE affects at least four other standards. It will take a lot of effort and time for .1Qay to be confirmed, along with all the required changes in other standards.

In the end, use of PBT/PBB-TE will be no cheaper than any (transport) MPLS variant. The cost of data-plane PBB-TE gear (BEBs and BCBs) will indeed be comparable to PBB. But! remember to add the cost of a complex control plane, the GMPLS.

davallan 12/5/2012 | 3:31:14 PM
re: PBT: Alive 'n' Kicking Hi T

Your're right, it was fall 2005, memory fades already ;-)

I'm not sure what you mean by "ignored" with respect to OAM...Many of the gaps in 802.1ag were addressed in Y.1731 before PBT was proposed (unicast CCM for example). PS coordination be it 8031, or simpler (i beleive single phase) being about the only discussion topic. The other changes were largely self evident once the basics were agreed, e.g. the two leg transactions.

Meanwhile I think you're pessimistic on both time and cost. 802.1Qay still on track for sponsor ballot beginning of next year and interoperability has existed for some time. As for cost, you said the "use" suggesting OPEX for both will be a wash. A managed variant of PBT is substantially simpler to operate as ethernet cross connect is much simpler than MPLS or MPLS-TP. That carries over to OAM and fault finding. Only in a perfect world could one claim "close".. and only if GMPLS universally applied.

davallan 12/5/2012 | 3:31:12 PM
re: PBT: Alive 'n' Kicking Hi Maarten:

I would not rush out to reinvent PBB-TE and especially NOT to make it more like VPLS. That begs a huge **why?** and IMO a major regressive step w.r.t. the state of the art. PBT being no different to PBB-TE so exploring what it could be is similarly irrelevant. It is what it is....

IMO the combination of PBB-TE and PLSB has most of the requisite functionalities you seem to be looking for w.r.t. connectivity models/services.

As with "T", most of your complaints w.r.t. standardization are small corregenda, IMO vitually lost in the noise.

As for the rest of your complaints with respect to inadequacies, these center mainly around building a global multicarrier PBB-TE network now. I'll take the fact we are discussing that problem and that there is an understood solution space as an endorsement of how far Ethernet has come in a short time.

mvissers 12/5/2012 | 3:31:12 PM
re: PBT: Alive 'n' Kicking To build a network you need a multi-domain, multi-operator capable technology, which can support p2p, p2mp, rooted-mp and mp2mp services.

PBB-TE is not supporting multi-domain, nor multi-operator, nor rooted-mp or mp2mp services; but PBT may be multi-domain, multi-operator and supporting all service types.

PBB-TE TESI signals multi-use the B-SA/B-DA from their clients (the BSIs) as their ESP-SA/ESP-DA. This multi-use introduces the multi-domain/operator and service restrictions. PBB-TE should either get rid of the BSI as monitored entity and just keep the ISID as a larger S-VLAN identifier, or introduce independent ESP-SA/ESP-DA fields in the frames (i.e. in addition to the B-SA/B-DA fields of the BSIs). This simple change will also provide PBT-VPLS capabilities, including the full mesh connectivity. The MACinMAC function will implicitly provide the VPLS split-horizon function.

In this way you get a PBT stack which contains a Service VLAN layer with p2p, p2mp, rooted-mp and mp2mp services support and a PBT tunnel layer with p2p tunnels (TESIs) and for broadcast services possibly also p2mp tunnels. I.e. the same stack as we have in MPLS and will have in MPLS-TP.

The PBT OAM comes without DA/SA fields (i.e. just the TYPE field (89-02) and the OAM PDU. The ESP-DA/ESP-SA/ESP-VID based label is then added to this PBT OAM as a TESI demultiplex identifier (similar to the MPLS tunnel label).

The absense of DA/SA fields in the PBT OAM basic frame requires that the Y.1731/802.1ag Ethernet OAM PDUs can not simply be reused in PBT. Instead a number of the Ethernet OAM frames need to be modified before they can be deployed as PBT OAM frames (hardware/firmware changes?). Changes are not major, but still must be introduced. In this sense it has a better starting position then MPLS-TP were most of the OAM work still has to be performed. But MPLS-TP could select the Y.1731 OAM PDUs as their starting point and add an MPLS header instead of the existing Ethernet header. Such approach would allow to have a very quick MPLS-TP OAM standardization and will guarantee seamless interoperability between MPLS-TP PWs and Service VLANs.

The ESP-DA for the PBT OAM can be a unicast address (case of a p2p tunnel) or a multicast address (case of p2mp tunnel). Y.1731 does not support this. Especially, a TESI MEP at an intermediate Provider Network Port generating PBT OAM is not allowed to attach its local MAC address in the SA field; instead the unicast MAC addresses of the two CBP functions at the end of the TESI connection must be attached, or the unicast address of one CBP and the multicast address of the p2mp TESI must be attached. These are not major changes with respect to Ethernet OAM, but it are differences that must be incorportated in those interface ports. It also requires that on those PNP ports the full 108-bit ESP-DA/ESP-SA/ESP-VID labels are registered.

Protection Switching in multi-domain PBT networks should provide protection of the Service VLANs (as per G.8031) and the 802.3 physical media (can be provided as per G.8031). Protection of the PBT tunnel connections (TESIs) can be provided via S-VLAN Group protection capable of load sharing (new functionality added to G.8031) or via dedicated TESI protection (no load sharing).

It is not difficult to create an SDH like packet transport network solution, but PBB-TE (as per 802.1Qay) is still far away from the point that it can provide an SDH equivalent, world-wide, multi-operator, multi-domain, multi-service packet transport network.


Sign In