Will Fujitsu Join PBT Parade?

An upcoming Ethernet switch could make Fujitsu Ltd. (Tokyo: 6702; London: FUJ; OTC: FJTSY) the next telecom vendor to enter the provider backbone transport (PBT) market, a source tells Light Reading.

Fujitsu would then join Nortel Networks Ltd. , Siemens AG (NYSE: SI; Frankfurt: SIE), Huawei Technologies Co. Ltd. , and other vendors in support of PBT, which lately has become the Next Big Thing (NBT) in telecom networking. (See Nortel Launches PBT, PBT Gathers Support, and Huawei Joins PBT Fan Club.)

Most famously chosen as the transport technology for the BT Group plc (NYSE: BT; London: BTA) 21st Century Network (21CN) project, PBT is aimed at providing carrier-grade transport using low-cost Ethernet gear. (See BT Likes Nortel's New Ethernet Flavor, BT Rethinks 21CN Core Strategy, and Nortel, Siemens Win PBT Deals at BT.)

Fujitsu isn't doing this just to be cool. The source, who requested anonymity, says Fujitsu's entrance into the PBT market is linked to a request for proposal (RFP) expected to be issued by a major North American operator in the coming weeks -- an RFP that Fujitsu would like to be considered for.

A Fujitsu spokesman downplayed the speculation, telling Light Reading that the PBT market is "certainly a space we're looking at, but we have no announcements at this time."

Fujitsu hasn't declared any PBT allegiance yet, but it supports PBT indirectly. The company's Flashwave 6400 box is a repackaged version of the Hammerhead Systems Inc. HSX 6000, part of a reseller deal struck in 2004. (See Hammerhead & Fujitsu Team up.) And PBT happens to be one of the features Hammerhead offers.

What are Fujitsu's chances of snagging that upcoming RFP? Heavy Reading analyst and resident Ethernet expert Stan Hubbard thinks the company has a shot.

"Fujitsu offers a number of technology options based on its own products and those of its partners, including ADVA Optical Networking , Atrica Inc. , and Hammerhead," Hubbard says. "While Nortel and Siemens may have an early lead, just keep in mind that the market is very young and PBB-TE expertise exists beyond the walls of those two companies." (PBB-TE is the Institute of Electrical and Electronics Engineers Inc. (IEEE) 's euphonius name for the technology -- Provider Backbone Bridge Traffic Engineering.)

"The market is big enough to support multiple vendors," says analyst Inder Singh of Prudential Equity Group LLC .

PBT has caught the industry's attention as a way to simplify the transport of carrier Ethernet at the edge. Multiprotocol Label Switching (MPLS) has been the accepted method to date, but it requires an IP-routing approach that some say is too expensive and complicated for edge networks. Plain Ethernet, though, lacks the resiliency required for telecom; moreover, it's got features that slow it down too much for carrier needs. PBT, which removes those Ethernet features, could be an alternative.

Plus, PBT comes cheap.

"Due to the enormous volume of Ethernet products -- over 200 million port shipments expected in 2007, versus fewer than 1 million ports for core and edge routers -- prices for Ethernet components and switching products are just a fraction of the price of core and edge routers," Singh writes in a note issued yesterday. "Nortel claims capex savings of 40%-80% over IP/MPLS using its PBT solution, with incremental opex savings on top of that."

Hubbard says he would be surprised if most major wireline equipment vendors were not looking at PBT.

"Clearly, BT is not the only one interested in PBB-TE. Multiple technology trials are already taking place with other large operators in Europe and North America, and more and more service providers will be exploring this technology as a potential means of lowering transport costs in the metro/access part of the network."

So how soon can Fujitsu -- or any other vendor -- expect to cash in on PBT? Analysts say that contracts could start rolling in as early as the second half of this year, but that it will take many years before the PBT opportunity has run its course.

Singh tells Light Reading he sees the first half of 2007 as an "experimental stage," with carriers running PBT trials and tests, and the second half beginning the technology's "commercial stage."

"Clearly we're at the beginning of something, but the overall market will take a good five years to develop and mature," he says.

— Ryan Lawler, Reporter, Light Reading

Page 1 / 2   >   >>
torivar 12/5/2012 | 3:10:52 PM
re: Will Fujitsu Join PBT Parade? BT isn't using PBT for their core transport, it's being used on the access portions of the network. The core transport network is still IP/MPLS built upon DWDM, which is a proven and mature way of doing things.

PBT isn't a competitor to IP/MPLS cores at this point, it's a competitor against technologies like VPLS at the edge, where the added complexity of MPLS and IP isn't really necessary. Alcatel is pushing VPLS all the way to the furthest edge device, and I think that's a mistake as it just adds cost to the devices, 7450 switches are more expensive than a plain L2 Ethernet switch.
mr zippy 12/5/2012 | 3:10:51 PM
re: Will Fujitsu Join PBT Parade? Further to my last post ...

I think the possible attraction of PBT is it is likely to be a cheaper "version" of MPLS.

Thinking about it a bit more broadly, we've seen the world converge towards a single layer 3 protocol of IPv4 in the last decade or so, away from mixed layer 3 multi-protocol networks (e.g. IPv4, Novell IPX, Appletalk etc). Interestingly this convergence occured towards probably the most expensive of protocols to operate - IPv4 is far harder to understand and deploy over IPX and AT, although IPv4 was the most widespread. Popularity made IPv4 the cheapest to converge to. Obviously the cost savings of a single protocol outweighed the specific complexity costs of deploying IPv4.

I think now we're seeing the same thing happen at layer two, and we're converging towards the most popular and therefore the most comodity (i.e. cheapest) of layer 2 technologies.
mr zippy 12/5/2012 | 3:10:51 PM
re: Will Fujitsu Join PBT Parade? The designers of MPLS had to make it work over many "legacy" technologies like Frame Relay, ATM, PPP as well as Ethernet. To do so, they added a shim, to both hide the differences between these different layer 2 technologies, as well as carry other information needed for MPLS to work. In a few cases, they did take advantage of a few of the layer 2 header fields in a few cases to carry label (VC) information e.g. the ATM VPI/VCI fields.

As ethernet is being used to slowly replace legacy layer 2, it is possible to invent a version of MPLS that is "optimised" for Ethernet, and that is what I think PBT is, at least at the forwarding plane. End-to-end ethernet in a network removes the abstraction layer that MPLS had to implement.

As for the control plane "issues" that people mention when talking about PBT, I think most if not all the control plane development and solutions of MPLS will be equally applyable to PBT.

dask 12/5/2012 | 3:10:50 PM
re: Will Fujitsu Join PBT Parade? The article stated that PBT is targeted at metro rather than core.
Dredgie 12/5/2012 | 3:10:49 PM
re: Will Fujitsu Join PBT Parade? The PBB-TE Gă control planeGăÍ is out-of-band G㢠using a NMS/EMS device to set-up circuits.
davallan 12/5/2012 | 3:10:49 PM
re: Will Fujitsu Join PBT Parade? mr zippy

You wrote "The designers of MPLS had to make it work over many "legacy" technologies like Frame Relay, ATM, PPP as well as Ethernet."

MPLS was designed as a L3 helper and grafted onto the bottom of L3, so HAD to run over the same link layers as L3. Link layer independence IMO was an artifact, not necessarily a design goal...

Ethernet is also defined to run over pretty much everything (ATM, GFP/SONET etc.) partially as a consequence of the limited reach of the original copper Ethernet PHYs, with glass the reach issues of native Ethernet PHYs having been eliminated.

So IMO the goal would ultimately be to NOT run ethernet over other layers as it is self sufficient, but running over other layers is not precluded and is well specified...

As for "it is possible to invent a version of MPLS that is "optimised" for Ethernet, and that is what I think PBT is", I'd not make that explicit a linkage.

In terms of the overall concepts, PBT forwarding fits more at the level of FEC than label, simply eliminating a level of indirection in the dataplane.


chechaco 12/5/2012 | 3:10:47 PM
re: Will Fujitsu Join PBT Parade? Control Plane for PBB-TE can be based on NMS (e.g. PCE) but you still need solve signaling and OAM. It is plausible and actually been tried in the lab to use GMPLS with certain extensions to control PBT network.
OldPOTS 12/5/2012 | 3:10:46 PM
re: Will Fujitsu Join PBT Parade? It seems to me as a retired operator that any solution must solve all problems that may be encountered during operations, or else OPEX becomes substantial.

The problem I always had was that those proposing solutions ususlly only solved one or a few problems they perceived, but not all those faced by 'the network' operations. They were ususually cheap with the devil in the details!

Mark Seery 12/5/2012 | 3:10:45 PM
re: Will Fujitsu Join PBT Parade? Dave,

>> Ethernet is also defined to run over pretty much everything .... <<

Ahh, yes, but can it run over the semaphore flag signaling system or even avian carriers for that matter ;-)


it should also be noted that protocols are not just judged by what they can run over, but what can run over them:


There are only two technologies guaranteed of being in NGNs. The DS0 replacement (IP), and the new SONET/SDH (Wavelengths). Everything in between those protocols is fighting for how much of the sub-wavelength aggregation, grooming, and VPN pie they can get. And thus it has always been so, with the only difference being it used to be everything between IP and SONET/SDH.

You have to find a place in between transmission and application envelope, or you have to knock off one of those.

davallan 12/5/2012 | 3:10:44 PM
re: Will Fujitsu Join PBT Parade? Hi Mark:

'tis about 6 days too late for some of those standards ;-)

Nor is there room for the "evil bit" in currently Ethernet specified headers, a "serious" shortcoming...


If there is one thing we've learned in the orgy of stacking, overlaying and recursion of the past decade is that one man's application is another man's infrastructure and it is not limited to monogamous relationships.

IMO the solution that does the requisite primitives to either "be" the application (a.k.a service) or support higher order applications with the fewest overlays & protocols is the winner.


Page 1 / 2   >   >>
Sign In