Acronym soup or super network? * What? * Why? * Vendor roundup

April 3, 2008

59 Min Read
A Guide to PBT/PBB-TE

For Light Reading's ongoing coverage of PBT and PBB-TE, click here.

Provider Backbone Transport (PBT) is a new, rapidly evolving, and highly controversial development in Ethernet technology. But for all its controversy, the technology has the potential to revolutionize the construction of carrier access and metro transport networks.

It promises to combine traditional Sonet/SDH-like connection capabilities and operational features with the lower costs and packet-oriented advantages of carrier-grade Ethernet. That gets loads of attention because PBT represents a huge break with the long-established orthodoxy that sees Multiprotocol Label Switching (MPLS) technology playing the central role of providing transport connections in carrier packet-based networks. (See MPLS in Access Networks.)

Add to this that PBT is only just beginning to become a commercial product, that standardization is still ongoing, that there is limited evidence of the real benefits to carriers, and that vendors in the PBT space are not all singing from the same hymn sheet. Given all that conflict, we found it hard to resist publishing this guide to the key issues and views on the technology, as a follow-up to last year’s initial report "PBT: New Kid on the Metro Block."Additionally, this guide is supplemented by a survey of vendor and component maker views, a second report called "PBT/PBB-TE Guide: Vendor Talk."What's in a name?
Although some use it as a generic term, PBT (Provider Backbone Transport) is strictly an informal moniker introduced by Nortel Networks Ltd. and BT Group plc (NYSE: BT; London: BTA) for this relatively new flavor of carrier-class, connection-oriented Ethernet that has recently ruffled a lot of feathers in the industry.

PBB-TE (Provider Backbone Bridge – Traffic Engineering), on the other hand, is an ongoing standardization and extension of the basic PBT idea, but it is still some time away from producing the first products based on that technology standard. Since the first (PBT) is technically a proprietary network solution and includes things that the other (PBB-TE) doesn’t, while PBB-TE technically doesn’t yet exist, and will include things (some as yet unknown) that PBT doesn’t, it’s difficult to come up with a simple generic term to cover both.

"We regard PBT as an informal and more general term," says John Hawkins, senior marketing manager for carrier Ethernet at Nortel. "It simply rolls off the tongue more easily than PBB-TE."

Whatever you call it, carrier interest in PBT and PBB-TE is growing, and companies that have committed to using the technology in their networks include BT (in the U.K. and in Italy, where it is up and running), CNC, Dakota Carrier Network LLC , Frontier (an ILEC that's part of Citizens Communications Co. (NYSE: CZN)), groupe-e (a Swiss utility), Highland Telephone Cooperative, Mumbai International Airport, Promigas Telecomunicaciones (Colombia), Silk telecom , and Southern Light.

Another batch, which includes BCE Inc. (Bell Canada) (NYSE/Toronto: BCE), Deutsche Telekom AG (NYSE: DT), Orange (NYSE: FTE), NTT Group (NYSE: NTT), Swisscom AG (NYSE: SCM), Telefónica SA (NYSE: TEF), Telia Company , and Verizon Communications Inc. (NYSE: VZ), is either trialing the technology or rumored to be looking at it closely.

Underlining this interest was the big carrier Ethernet interoperability test run by European Advanced Networking Test Center AG (EANTC) at the Carrier Ethernet World Congress in Geneva in September 2007. Nine of the 24 vendors involved participated in a PBT network, compared to four with T-MPLS, the MPLS-derived analogue to PBT/PBB-TE.

“To have that many vendors with working implementations – it was evident that PBT had a serious momentum behind it, and was a real technology that people were considering,” says Mike Haugh, Ixia (Nasdaq: XXIA)'s senior product line manager. (Ixia provided some test equipment for the event.) He added that major service providers in the U.S. and Europe are asking vendors for some sort of PBB-TE support within "a year or two years."

"We really see PBT as a shift in the market," says Peter Lunk, director of service provider marketing for Extreme Networks. "The MPLS market has been winnowed down to a couple of big players, and I think that this is really a chance for other vendors to move back in and say: 'Hey, the metro piece and the edge of the network really ought to be built out using a lower-cost technology.'"

But, as Light Reading has widely reported (for example: AlcaLu's Alwan: PBT Will Lose Its Shine , 2007 Top Ten: Technologies to Watch, PBT Cost Claims Questioned, and BT Counters PBT Claims), PBT/PBB-TE remains controversial. This report aims to look at the problems PBT/PBB-TE addresses, make a tally of where different vendors stand, and indicate some of the things they are doing to develop and implement the technology.Like Gaul, our consideration of this topic is divided roughly into three big parts. First, there is a very quick rundown on what PBT/PBB-TE is, followed by an overview of why the technology has generated so much fuss, and how it relates to other technologies and carrier needs.

The report then moves onto more dangerous ground by looking at some vendor attitudes to the technology, its development, and its leading MPLS alternatives. It is no secret that the industry is going through one of its periodic philosophical (soon to be commercial) squabbles over PBT/PBB-TE versus MPLS. It is curious how an industry ultimately based mostly on optics manages to generate so much heat and so little light on such issues.

The third part of this editorial effort required a completely separate report: PBT/PBB-TE Guide: Vendor Talk. That report presents a summarized survey of some of the vendors either in, or near to, the PBT/PBB-TE market, giving more detailed information on their views on the technology, its role and applications, their approach to the market, and its possible development.

Here’s a hyperlinked list of this report's contents:

Note: This report is not designed to be completely comprehensive, so the company listings that appear in Tables 3 and 4 are very modest and are for purposes of illustration only. If you feel that your company should appear, but does not, please contact [email protected], as we want to make new reports as useful as possible.

— Tim Hills is a freelance telecom writer and journalist. He's a regular author of Light Reading reports.

Next Page: PBT/PBB-TE RecapPBT was famously kicked off by BT and Nortel in 2004 as an idea for a potentially simpler and cheaper alternative to MPLS for providing carrier connection-oriented Ethernet in the metro environment. Initially, it didn’t carry much weight because everyone was pretty much enamored with Internet Protocol (IP)/MPLS, and felt that MPLS-enabled devices and routers would support everyone for everything. However, BT’s subsequent backing of PBT for its next-generation network, the 21CN, and push for standardizing the technology through the IEEE PBB-TE project sparked a flurry of development and activity. Every major vendor wanted a piece of the 21CN businesses, and other carriers began to pick up on the PBT idea for its own potential merits.

Technology basics
The Light Reading report "PBT: New Kid on the Metro Block" overviews the rationale and technology of PBT/PBB-TE in some detail, and readers new to the topic should refer to it. Several of the Vendor Summaries later in this report also give more detailed snapshots of PBT/PBB-TE characteristics. This page gives only a summary of some of the key aspects, and indicates how PBT/PBB-TE fits into the seemingly endless development of Ethernet.

The basic point is that PBT/PBB-TE is Ethernet, but in an extended form that also removes some usual features and limitations to produce a somewhat Sonet/SDH-like carrier transport mechanism, but without the latter’s specific TDM/ring technology for recovery and QOS mechanisms. That is, it provides point-to-point connections set up through predetermined network paths by an external network management system (NMS), and thereby provides traffic engineering and deterministic behavior. Further, paths are protected on an end-to-end basis with a predefined backup path that is switched over by using OAM Continuity Check Messages (CCMs) sent every 3.3 milliseconds. In the event of the primary path failing, the secondary can be switched within the 50 millisecond Sonet/SDH norm -- below 20 milliseconds has been achieved -- and some QOS mechanisms are available. At the Carrier Ethernet World Congress in 2007, for example, ANDA Networks Inc. , Hammerhead Systems Inc. , Nortel, and World Wide Packets Inc. demonstrated 50ms failover using PBB-TE.

All this is contrary to normal bridged/switched Ethernet behavior, where Ethernet switches dynamically interact and explore the network by mechanisms such as Spanning Tree and Flooding to learn and establish paths to destination addresses. Such behavior, although effective at producing flexible and easy-to-build enterprise networks, lacks the deterministic and predetermined characteristics that carriers need if they are to use Ethernet as the network Layer 2 for handling large numbers of traffic flows to tight service-level agreements (SLAs).

PBT/PBB-TE disables Ethernet Spanning Tree and address learning, and manages switch forwarding tables externally from a central point. It also uses an extension to the Ethernet frame known as Provider Backbone Bridging (PBB), which is the most recent in a series of extensions of the original Ethernet 10 Mbit/s LAN frame that have propelled Ethernet toward becoming a carrier networking technology. As Table 1 shows, the Ethernet frame has been successively tagged, or wrapped, to support such key carrier-type requirements as virtualization, separation of customer, and carrier domains, and greater hierarchical classification for scalability and security. The result is vaguely similar to the MPLS stacked-tagging idea, but applied in a very specific way just to Ethernet (although, other than PBB and PBT using MAC addresses, there is conceptually no reason why this same frame format could not be used to transport other protocols). MPLS, in contrast, is a perfectly general technique, applicable to any packet technology -- hence the name, Multiprotocol Label Switching.

Table 1: Simplified Schematic of Parts of the Developing Ethernet Frame

(1) Basic Ethernet

(2) VLAN tagging (802.1Q)

(3) Provider Bridges (802.1ad) -- Q-in-Q

(4) Provider Backbone Bridges (802.1ah) -- MAC-in-MAC

DA -- destination MAC address

DA

DA

[B-DA -- Backbone DA]

SA -- source MAC address

SA

SA

[B-SA -- Backbone SA]

PAYLOAD etc.

VID -- VLAN identifier

S-VID -- Service VID

[B-VID -- Backbone VID]

PAYLOAD etc.

C-VID -- Customer VID

[I-SID -- Service identifier]

PAYLOAD etc.

DA

SA

S-VID -- Service VID

C-VID -- Customer VID

PAYLOAD etc.

[ ] indicates the provider Ethernet encapsulation of the customer Ethernet subnetworks. Source: Light Reading, 2008





It’s worth pointing out that, although Table 1 suggests that PBB introduces a lot of overhead, comparison of the full details with a PWE3 MPLS pseudowire frame (used for transporting Ethernet over MPLS) shows that the overhead is the same size.

Standards and initiatives
PBB was invented by Nortel in 2004, and is subject to ongoing standardization by the Institute of Electrical and Electronics Engineers Inc. (IEEE) (starting in 2005) as 802.1ah -- aka MAC-in-MAC. As the MAC-in-MAC name suggests, it puts a second MAC wrapper around the original Ethernet frame, and this second MAC is used by the provider edge and transport bridges to convey the frame to the correct egress provider bridge. PBB offers what might be termed "normal" Ethernet capabilities, and can thus support point-to-point, point-to-multipoint, and multipoint-to-multipoint networks. A final standard is not expected to emerge before mid-to-late 2008.

PBB provides only the data plane of PBT/PBB-TE. The control plane is also still a work in progress, and is subject to some debate, as it can be argued that there is actually no need for a specific PBB-TE control plane, if PBB-TE is used only for point-to-point services configured by an external OSS, and PBB, with a protocol to replace Spanning Tree Protocol (STP), is used for all the other service topology types. The situation is further obscured by the industry’s tendency to sometimes also lump OAM capabilities under the term "control plane".

"There is clearly a debate heating up regarding PBT/PBB-TE control plane -- centralized versus MPLS signaled control plane," says Ken Davison, Meriton's VP of marketing and business development. "From the perspective of PBT/PBB-TE as an infrastructure enabler for Ethernet access aggregation and backhaul, the bulk of the network topology tends to be quite static. The drivers for a control plane are quite different than those at the services layer. For example, traffic engineering at the transport layer often takes into account physical realities that are not easily visible in the logical network -- like using a shared-risk-group database to avoid routing redundant paths through the same fiber or even fiber duct. Given the slow dynamics of the network at this level and the relative closeness of the physical (fiber) plant, an off-board OSS-based management scheme with a consistent view of the infrastructure as a whole seems more appropriate than a signaled control plane. Why should node processors incorporate databases and distributed algorithms to take these kinds of things into account?"

PBB-TE OAM capabilities include two important standards. The IEEE’s Ethernet OAM management specifications (802.1ag) provides Connectivity Fault Management, covering proactive alarms for service faults, and the detection, verification, and isolation of connectivity failures, while the ITU-T’s Y.1731 adds performance measurement and monitoring capabilities.

“With respect to 802.1ag and Y.1731, portions of these are implemented in PBT today, specifically those portions related to CCM and protection switching,” says Daniel Barry, Tpack A/S 's director of marketing. "The discussion for PBB-TE is whether to implement the full set of Y.1731, the full set of 802.1ag (which is itself a subset of Y.1731), or an even smaller subset. Y.1731 is fully comprehensive with every monitoring feature you could wish for, both for connection-oriented and connectionless operation. However, many carriers agree that a full implementation would be overkill. Therefore the discussion is what the minimum necessary set of functions should be."

Pulling all this together is Provider Backbone Bridge Traffic Engineering (PBB-TE) itself, which is being standardized in the IEEE 802.1Qay project, and, as already indicated, is essentially a connection-oriented modification to PBB. A standard is unlikely to emerge before sometime in 2009. Figures 1 and 2 indicate in general terms the arrangement of the PBT/PBB-TE data plane and the OAM.

2695.gif

2696.gif

Inevitably, PBT has its own industry vendor initiative – the Carrier Ethernet Ecosystem – founded by Nortel in June 2007, and still very much promoted by that company. By early 2008 there were over 20 vendor members. Formally, the CEE is not restricted to just PBT technology, and is open to vendors producing “Ethernet solutions for use by service providers in a variety of carrier-class environments," but PBT/PBB is clearly a major interest. As with most initiatives of this type, a big aim is to develop and demonstrate practical interoperability and interoperability testing -- obviously a crucial point with a new carrier technology like PBT. Other aims are also standard: to promote carrier Ethernet generally, and to aid the development of standards relating to it.

Next Page: Why PBT/PBB-TE?The why of PBT/PBB-TE can be broken down in various ways. Obviously, there is a simple commercial angle, as with any new approach to network technology. The Tier 1 carrier IP/MPLS market is heavily dominated (alphabetically) by Alcatel-Lucent (NYSE: ALU), Cisco Systems Inc. (Nasdaq: CSCO), and Juniper Networks Inc. (NYSE: JNPR), so Nortel Networks Ltd. had nothing to lose, and much potentially to gain, by suggesting PBT as a possibly simpler and cheaper alternative to MPLS for certain areas of carrier Ethernet infrastructure. And there are many other vendors espousing various forms of carrier Ethernet – especially for Tier 2 and Tier 3 service providers – that naturally welcome a potentially attractive extension to the technology.

Much of the current industry hysterics noted in this report's introduction are between the pro-PBT/PBB-TE and pro-MPLS camps. But there is an engineering angle, too. The nature of telecom traffic is changing, and end users – enterprise and consumer – increasingly want, or need, broadband services and applications using Ethernet at Layer 2 alongside IP at Layer 3. And this need is likely to become both very heavy and very pervasive when mass market applications such as IPTV delivered via FTTH/FTTN become mainstream over the next few years or so. (See GPON Driving Worldwide Growth of FTTH.)

The consequent enormous growth in Ethernet traffic, especially in the metro and access networks, is concentrating carriers’ minds on how best to handle it within their networks. Infonetics Research, for example, found in its recent "Service Provider Plans for IP/MPLS" study that service providers reported 90 percent to 100 percent increases in Ethernet traffic in 2006 and in 2007, and 70 percent to 80 percent for IP/MPLS traffic.

Networks and carrier requirements
All this is taking place within the context of a global move by carriers to reconstruct their networks around a new simplified integrated service layer running over an even more simplified packet-optical transport infrastructure. The new service layer is already heavily IP/MPLS, and Ethernet is increasingly appearing there. That leaves the transport infrastructure and, in particular, what will provide the Layer 2 functions to ride over the Wavelength Division Multiplexing (WDM) Layer 1 optics. It could be MPLS/GMPLS, but there is increasing interest in using Ethernet in a native connection-oriented form to provide the necessary transport tunnels and datalink capabilities.

“Tellabs sees the marriage of optical transport and Ethernet packet switching as very promising," says John Sauer, senior principal engineer at Tellabs. "For example, the use of ROADM technology and switching in combination will enable both optical and Ethernet optimization."

It’s worth stressing that there is a lot of effort being put into developing the necessary silicon to enable Ethernet to run directly over transport optics. For example, AMCC claimed in January 2008 that its new PEMAQUID 10-Gbit/s ENET/OTN Framer/Mapper was the first physical-layer device on the market to allow metro Ethernet equipment to connect directly to 10-Gigabit Ethernet Optical Networks, rather than requiring the back-ending of carrier Ethernet and switch router platforms with DWDM equipment in to enter or exit optical transport networks.

Further big motives for moving to an all-packet optical infrastructure are the perceived advantages in scale, aggregation, and costs. The question is how to replace the well trusted Sonet/SDH infrastructure, which underlies the majority of router networks today and provides the reliable transport infrastructure needed for secure delivery of packet services. A vocal segment of industry opinion believes that MPLS taking over this responsibility would be a suboptimal solution and could possibly increase operating cost because of complexity. They argue that MPLS wasn’t conceived for this job and is too closely linked to the IP services layer to provide a reliable, decoupled, transparent transport mechanism.

MPLS critics also point to the operational consideration that many carrier transport groups are used to Sonet/SDH and network management control of networks. Introducing a new paradigm, such as IP/MPLS, would be a major organizational challenge, whereas PBT/PBB-TE (and T-MPLS for that matter) looks and feels very similar to what these organizations are using already.

Also, it’s important to be clear on what is at issue here: The end user wants an Ethernet service – what he plugs into from the carrier looks and behaves just like any other normal form of Ethernet (say, an Ethernet LAN or an Ethernet point-to-point connection). But the carrier doesn’t have to use Ethernet to provide the Layer 2 functionality within its transport network – and usually doesn’t, to date. Instead, that Ethernet service will ride on a stack of protocols and network layers. Table 2 shows some common examples in schematic form.

Table 2: Some Ways of Providing Ethernet Services Over Carrier Packet Networks

Approach 1

Approach 2

Approach 3

Approach 4

Ethernet service

Ethernet service

Ethernet service

Ethernet service

IP-VPN

VPWS, VPLS, Pseudowires

VLAN, VLAN stacking

PBB-TE Ethernet

IP

MPLS

Ethernet

Optics

MPLS

Optics

Optics

Optics

Note: This Table, being concerned only with next-generation carrier packet networks, omits the very important approach of Ethernet over Sonet/SDH. Source: Light Reading, 2008



As Table 2 emphasizes, there are currently different approaches to providing end-to-end Ethernet services within a packet environment. Approach No. 1 uses combined carrier Layer 2 and 3 capabilities (MPLS and IP) to support IP-VPN services effectively via Layer 3 tunnels. Approach No. 2, in contrast, uses only carrier Layer 2 capabilities (MPLS) to support, for example, Virtual Private Wire Services (VPWS), which in turn creates tunnels (at Layer 2) across the carrier packet network to support Ethernet point-to-point connections.

Approach No. 3, on the other hand, does use conventional Ethernet in its carrier switched form to support Layer 2 VLANs using IEEE 802.1Q or its stacked Q-in-Q form for greater scalability. But, unlike Approach No. 2, for example, this isn’t a connection-oriented tunneling method, as the VLAN essentially just creates a separate Ethernet broadcast domain within the carrier switches for each VLAN instance.

Additionally, there are arguments favoring carrier Layer 2 VPN techniques (whether MPLS or Ethernet based) over Layer 3 ones, despite the latter’s continuing popularity. This is essentially because Layer 2 VPNs tend to be simpler to provide and are transparent to the higher levels of the customer’s network – routing and encoding, for example. Figure 3 gives an example of how such Layer 2 VPN techniques can be used in a WDM environment, where the Layer 2 VPN can be configured as a discrete service/interconnect or as an aggregate of multiple services, such as business VOIP, intranet, and Internet access.

2697.gifWithin this maze of technology choices, it’s important not to lose sight of some high-level goals.

"We think carriers want networks that are simple and cost-effective to operate using management tools and techniques that provide them a similar level of assurance that they are used to with traditional transport networks," says Jeremy Brayley, ECI Telecom Ltd. 's director of technology strategy. "They also want to see support for mature standards so they are not locked into a particular vendor’s solution."

Dig for victory
The subject quickly becomes very tangled for non-experts because there are different ways of providing the tunneling used in Approaches Nos. 1 and 2, for example, and different ways of combining tunnels -- VPWS tunnels can be meshed to support a Layer-2 MPLS LAN service, for example. All this leads to lots of different protocols, often promoted by different commercial interests. But a point to note in the PBT/PBB-TE debate is the central role that MPLS plays in Approaches Nos. 1 and 2, and that in Approach No. 1 it can be described as supporting Layer 3 tunneling (Layer 3 MPLS), whereas in Approach No. 2 it is supporting Layer 2 tunneling (Layer 2 MPLS).

Nortel points out that Approaches Nos. 1 and 2 increasingly rely on an (not shown) Ethernet layer between the MPLS and optics layers shown. Increasingly, this is implemented using PBB headers (as opposed to the older Packet Over Sonet), which leads to the argument that much of the functionality provided by the MPLS label is redundant, since PBB is imbued with similar functionality. In Approaches Nos. 3 and 4, this redundancy is eliminated.

Approach No. 4 should make the point of PBB-TE very clear, as it is basically running Ethernet service over native Ethernet connection-oriented transport tunnels, thereby achieving delayering and simplification, and potentially pointing toward a future merged Ethernet and optics carrier transport infrastructure.

Break it down
At the risk of some oversimplification, much of the debate is thus around the best way of tunneling through a carrier packet network. The basic requirements for carrier packet-based transport are fairly severe.

"Any packet link-layer technology, in order to be adequate for carrier transport, must be able to support predictable connectivity (connection-oriented), classify users, support SLAs, adhere to carrier OAM schemes and be controllable enough to support the carrier business model," says Adam Dunsky, founder of Ethos Networks. "Plain Ethernet is a flat, connectionless, broadcast-based, non-QOS oriented technology. The importance of PBT is in introducing these required characteristics into an Ethernet networking environment."

This is potentially interesting to carriers for immediate practical reasons outside long-term network evolution. Many carriers worldwide use simple Layer 2 Ethernet switches to aggregate enterprise multi-tenant campus traffic, for example, onto their core networks. If a customer there should require a high-CIR (Committed Information Rate) Ethernet leased-line, the carrier will often make a brute-force and excessive overprovisioning of the Sonet backhaul link as the only way of meeting the CIR. In other words, it wastes bandwidth in order to keep the simple Ethernet switch. This is just the situation that MPLS will handle well, but the carrier may not want what it views as the additional cost and complication of adding MPLS in situation where the customer revenues may not justify it. PBT/PBB-TE, in contrast, would provide a native upgrade to the Ethernet switch that would support the necessary CIR tunnel without the inefficient overprovisioning.

The further hopes are that, because we are talking Ethernet, PBT/PBB-TE ought to be fairly cheap (ahem, low cost is the technical term) in carrier terms, while working with nailed-up point-to-point connections ought to be simple and fit well with existing circuit-oriented carrier cultures and operations. And some service providers do seem to think that standards developed in the IEEE are more robust and more interoperable than those developed in the IETF, where MPLS, for example, was primarily derived.

What's our position? Right now, we're lying on the floor and ready for a stiff drink. Join us on the next page, won't you?

Next Page: PBT/PBB-TE Selling PointsBefore we get completely off track, here is a summary of the key characteristics of PBT/PBB-TE as seen by the technology’s proponents. They include:

  • Ethernet technology

  • Ability to support other service layers, such as MPLS

  • Traffic engineering and resiliency, with ability to provision deterministic paths similar to Sonet/SDH, and centralized manageability also similar to that or Sonet/SDH

  • Fast protection switching

  • OAM monitoring capabilities

  • Scaleability from the use of tunneling, which is used to multiplex EVCs at edges

  • Security from customer/carrier separation and hierarchical structure

  • Looks and feel of Sonet/SDH, allowing easier introduction into carrier transport groups

  • Potentially lower costs from Ethernet technology, the use of an edge/core approach with existing Ethernet core switches, and an external control plane.



It is the potential capital and operational expenditure savings, especially, that PBT/PBB-TE’s proponents are keen to emphasize.

"The order of savings that we have seen in network designs where we have built out using a PBT solution versus an MPLS solution out to the edge is a 30 to 40 percent cost saving. But the even bigger piece tends to be the operational expense,” says Lunk of Extreme Networks. "If you keep the transport layer simple, like this, you don’t need a team of network architects just to manage your network on a day to day basis."

Of course, the separate Network Management System (NMS) for the control plane is an additional cost, but Lunk estimates that this can be kept to about 10 percent of the of the overall cost of the network equipment hardware – roughly in line with what was experienced with Sonet/SDH. And Nortel argues that providers with an existing heavy optical investment will have already incurred the major NMS expense, so, if implemented in a complementary fashion, the PBB/PBB-TE portion of the NMS should be a relatively small increment.

However, all this talk about Ethernet’s low costs needs to be kept in proportion. Carrier Ethernet is by definition a much bigger beast than is enterprise Ethernet, and port costs are not going to drop to enterprise levels, despite what carriers might hope.

"Carriers have their own enterprise Ethernet data centers and networks, and in many cases are looking for a similar price point for carrier-grade Ethernet on a per-port basis,” says Steve Christo, director of product marketing at Lightstorm Networks , which has introduced the industry’s first PBT ASIC (though not the first PBT chipset). "It is definitely unrealistic at this point, based on the solutions that are out there, but they are definitely driving the manufacturers to meet those numbers. Will it ever get there? I don’t think so, but it is not going to be double or triple what an Ethernet port is in the enterprise, it’s probably going to be 20 to 40 percent more."

Next Page: MPLS & PBT/PBB-TEAll this talk of MPLS leads to the central question surrounding PBT/PBB-TE: Is it really needed? That is, will it become a major tunneling technology, or will it occupy a niche? Is it merely re-inventing the MPLS wheel?

MPLS is an established and mature technology that has been used extensively since the early 2000s to provide connection orientation to carrier core networks. It is entirely general in its scope and allows label switching to be applied to any kind of packet or frame, so it can be used at both Layer 2 or Layer 3 of the carrier network. In particular, it supports VPWS, VPLS, and IP-VPN services. Further, labels can be stacked ad lib, so it has terrific hierarchical scalability, and it has been greatly extended to become highly functional. In its MPLS-TE (Traffic Engineering) form, for example, it handles much more that just connectivity – for example, bandwidth control and quality of service (QOS).

Yet, detractors say that, as extensions were added to support new services and capabilities, MPLS became increasingly expensive, complex, and costly to operate. For example, it requires the carrier to implement other protocols and standards, such as LDP, RSVP-TE, OSPF, BFD, and FRR. This is less of an issue in the core network – where the number of network elements is small, there is a huge amount of processing power available, and vast traffic volumes over which to amortize costs – but it does matter in the metro and access networks, where there is a huge number of network elements, and processing power and cost will often be at a premium.

One company that does argue that MPLS is too complex for the access network is Ethernet access specialist Ceterus Networks. Mark McDonald, Ceterus's VP of product management, says: "What drives this perspective is the concept of matching performance to the requirements of the network architecture. At the moment, it appears that PBT is entirely adequate for the access network for connection and traffic management. It is also the simplest and least expensive to implement. Although PBT is not fully worked out, it appears to be vectoring in a direction that is more compatible with wide-scale deployment in the access portion of the network."

MPLS’s proponents – which naturally tend to be the larger router vendors – argue that many complaints are overdone, and that MPLS is largely sufficient for most purposes and offers considerable benefits.

"We can do Ethernet-over-MPLS tunnels for point-to-point and can traffic engineer those with MPLS-TE. So these things already exist,” says Ian Hood, market manager for Service Provider Routing and Switching at Cisco Systems. "A lot of our customers are actually driving MPLS all the way through the metro to the edge. From the edge of the MPLS aggregation network, some choose to go Ethernet outwards, and some actually take MPLS all the way to the CPE. There are many customers that do that because they want the consistent, reliable recovery schemes that exist today in MPLS."

He points out further that MPLS ensures flexibility. A carrier may start by thinking that point-to-point Ethernet is all that is going to be required, but could then face difficulties if it later realized that it needed to offer, say, multipoint services such as peer-to-peer or to transport other protocols besides Ethernet.

However, all is not sweetness and light within the MPLS world, and there are disagreements over its latest offshoot, T-MPLS. Transport MPLS (T-MPLS) uses a purely connection-oriented MPLS packet network to provide managed point-to-point connections to various client services, such as Ethernet. Essentially, it is motivated along similar lines to PBT/PBB-TE. Just as PBT/PBB-TE simplifies carrier Ethernet, T-MPLS simplifies MPLS. Some of the characteristics of T-MPLS include:

  • No connectionless operation

  • Removal of IP or other Layer 3 capabilities

  • Essentially point-to-point operation, but point-to-multipoint is possible

  • OAM is based on a combination of Y.1711 and Y.1731 in two new (approved) standards from the ITU-T – G.8113 and G.8114

  • Protection mechanisms started with Y.1720 for linear protection, but have been replaced by G.8131 (also approved); work is ongoing on G.8132 for ring protection switching

  • Naturally supports MPLS and IP, but uses pseudowires to support Ethernet, Asynchronous Transfer Mode (ATM), FR, and TDM currently.

T-MPLS is an ITU-T standards initiative and is finished, with the exception being that the interface to IP/MPLS for OAM and ring protection mechanisms still needs to be defined. However, interoperability with IP/MPLS is an issue between the IETF (producer of the MPLS definition) and the ITU-T SG15 (producer of T-MPLS), and a committee has been formed to harmonize the two. For an introduction to the gory details, start at https://datatracker.ietf.org/documents/LIAISON/file470.txt.

The motivations for T-MPLS appear the same as for PBT/PBB-TE, and the features offered are almost identical. The controversy is whether T-MPLS is actually needed. Cisco, for example, says it isn’t, and therefore won’t support it because MPLS already does everything that T-MPLS will do. "Really, there is no news here in T-MPLS," says Hood. "In effect, it is what I would call a raw Ethernet pseudowire, without any of the control plane, and again with a manually provisioned NMS-based system. The people behind it are likely to be the people who have a transport platform that are attempting to emulate what is available with MPLS – the same thing in reality as in the PBB-TE case."

Other vendors wonder whether T-MPLS will bring any cost savings over PBT/PBB-TE, anyway. Mitch Auster, senior director of solutions marketing at Ciena adds: "We’ve had an RFI response with a moderate-size PTT who had a very controlled RFI in what they were looking for. Many of their responses were based on connection-oriented Ethernet, be it VLAN crossconnect or PBB-TE, as well as on T-MPLS. Although they didn't give us precise numbers, in their feedback they said that all the connection-oriented Ethernet solutions came in a lot less expensive than the T-MPLS ones."

Next Page: Early Application Drivers & ExperiencesInterest in PBT/PBB-TE is being driven also by its obvious fit with several early applications of potentially high importance. Generally, of course, there is the work by the Metro Ethernet Forum to establish and standardize some major types of carrier Ethernet service:

  • E-Line – dedicated point-to-point Ethernet connectivity

  • E-LAN – Ethernet LAN multipoint-to-multipoint connectivity

  • E-Tree – point-to-multipoint Ethernet connectivity.



Traditional leased-line replacement through E-Line services looks like a no-brainer, since it is not a huge leap for a carrier and is effectively what PBT/PBB-TE connections are, anyway. By extension, mobile base-station backhaul looks like a big application, with much reported growing industry interest. BT, for example, has already announced a big contract with T-Mobile (UK) to provide such backhaul in future via PBT in its 21CN, and followed this with an announcement in January 2008 that it had developed a new set of wholesale next-generation Ethernet services that it was starting to market to mobile operators and enterprise customers. An economical connection-oriented packet network, with QOS and reliability, including sub-50ms restoration, is just what mobile operators need for backhauling voice and broadband services from thousands of scattered base stations.

World Wide Packets Inc. (recently acquired by Ciena) says that its carrier customer requirements and experiences pointed it in the direction of using PBB-TE for mobile backhaul. Customers had evaluated MPLS and were deterred by the costs (both capex and higher opex, owing to the sophistication and carrier experience required). Further, some customers had deployed traditional Ethernet-based technologies and were struggling with very large RSTP domains that could not converge and were extremely difficult to maintain. For example, the addition of new base stations caused problematic and error-prone manual reconfigurations in neighboring devices.

"We spent quite a bit of time understanding the operator challenges. In late 2006, we decided to take a hard look at PBB-TE to see if it could address these customer challenges,” says Kevin Daines, the former CTO of World Wide Packets. "We decided to implement PBB-TE in our solution based on (a) the inherent benefits of the connection-oriented technology and (b) the progress within the IEEE 802.1 working group to standardize the technology. As a standards-based network equipment vendor, it was imperative for us that PBB-TE was on a standardization track, so customers would not be stranded with proprietary technology and investments."

In addition, Daines points out that mobile backhaul is often dominated by microwave links interconnecting towers and points of presence (POPs). Interference and environmental changes affect the connectivity (for example, bandwidth, latency, and frame loss) of the infrastructure. PBB-TE’s Connectivity Fault Management (CFM) capability provides excellent mechanisms for adapting and responding to the underlying microwave backhaul and failover to alternate paths to quickly minimize service impacts.

Similarly, the Ethernet Virtual Connections (EVCs) provided by PBT/PBB-TE have obvious applications for customer backhaul generally and for supporting residential service aggregation.

"Probably 95% of all IP traffic is coming from a video headend or from the Internet at large – so it’s more of a hub-and-spoke or backhaul type of environment within the metro," says Ciena’s Auster. "PBT sells very well to create a much more efficient and cost-effective way to aggregate the traffic from those endpoints back to a service edge router, or to distribute from a service-edge router to the endpoints."

Extreme Networks’s Lunk points out that PBT/PBB-TE has potential as an upgrade for Frame Relay networks, still widely used to support Transparent LAN Services, usually connecting one or two central sites multiple peripheral sites. "Those are running out of bandwidth, and service providers we have been talking to would like to offer something with the same price but higher bandwidth," he says. "Service providers are not too interested in offering just lower-priced services, but if they can provide the customer with more scale and bandwidth for the same price, it looks like a good deal. So I think that is an obvious area for us to focus on and expand the PBT front."

The other big types of Ethernet service – E-LAN and E-Tree – are currently less straightforward applications of PBT/PBB-TE, as they involve multipoint capabilities, which this report bills under "Technology challenges."

What carriers are doing
PBT technology and products have already gained some acceptance in the carrier marketplace. As listed in this report's introduction, a number of carriers have committed to using the technology, and others are evaluating it. Generally, there appears to be growing interest PBT/PBB-TE’s potential: At least one vendor reports that larger carriers in particular are beginning to stipulate a PBB-TE requirement in their RFQs, and so it is working with customers to meet it.

"A number of carriers are weighing and evaluating the merits of extending MPLS deployments versus implementing PBB-TE in certain parts of their networks," says World Wide Packets’s Daines. "Most are taking an open approach to determine if and where some economies can be realized – such as potentially lower overall capex. Many carriers believe PBB-TE can play a role. But I haven’t talked to any that believe either technology [PBB-TE and MPLS] is a one-size-fits-all answer."

Ciena’s Auster largely agrees: "I think we are probably just on the edge of a pretty strong movement. Most of the Tier 1s are still in the kick-the-tire stage, but I do see more and more interest in kicking those tires."

ANDA Networks's VP of marketing and business development, Greg Gum, says that behind some of this tire-kicking is an inbuilt penchant for transport-oriented networks: "Most carriers historically like to transport when they can, and switch when and where they must, for services to end customers – for example, POTS, X.25, and Frame Relay architectures," he says. "We talk to and provide gear to several of the Tier 1s, and many are evaluating PBT as a migration option as they do not want to deploy MPLS end-to-end through to the customers’ premises (e.g. core, metro, edge, access network elements). Tier 1s like Verizon, Bell Canada, and BT are already considering or testing PBT/PBB-TE options for potential cost savings, but continue to support and use their MPLS cores."

Carriers are also becoming much more interested in the higher aspects of PBT/PBB-TE as a possible solution – how it could integrate with the rest of their networks, for example. All this is moving the technology from a theoretical solution to feasible product offerings that carriers learn about and trial. According to some vendors, this has also led to a much more pragmatic feedback on PBT/PBB-TE over its advantages and drawbacks than was available previously.

"Because PBT makes sense economically, carriers are now really looking into it, thus causing them to ask practical questions as opposing to theoretical ones – such as about MPLS interoperability, service continuity across hybrid domains, PBT QOS support, PBT real-time applications support, and PBT multipoint support," says Ethos Networks’s Dunsky. "Carriers love the simplicity of the external control plane, but, at the same time, they are concerned that there is no standard for control-plane software, and that, in time, the complexity saved at the data plane might reappear at the control plane – as it did in ATM networks."

Dunsky argues that this closer look at PBT solutions has revealed that, while vendors do have a certain span of features that are appealing to carriers, to truly succeed in this market, PBT solutions will eventually have to present better QOS and optimization capabilities.

So PBT/PBB-TE is still work in progress, as Extreme Networks’s Lunk concedes: "There are certainly some questions, and we are working with partners on things like how do we support E-LAN services – so multipoint-to-multipoint connectivity – over PBT. Those are a little trickier to solve. I think we have some good plans in that area, and it is a good way to expand the reach of PBT. But even the leased-line-replacement application alone I think is enough to support a whole industry."

Next Page: Philosophical WarfareThere’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

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

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 IAll new technologies face challenges. Ethos Networks, for example, lists the following challenges for PBT/PBB-TE:

  • Development of external control mechanism with strong optimization, protection, restoration, TE, and provisioning tools

  • Achieving feature-rich yet simple QOS mechanisms

  • Adding efficient robust multipoint support

  • Matching MPLS feature-rich capabilities, such as traffic engineering, natural support for IP applications, and dynamic bandwidth control, while keeping the technology simple

However, even here, vendors differ somewhat in their assessments. Tpack, for example, gives us the following list:

  • Achieving seamless interoperability with IP/MPLS networks as a transport or peer-level service

  • Agreement on the level of OAM and QOS support based on 802.1ag and Y.1731 that should be implemented

  • Determination of the level of automation and control-plane support required for cost-effective operation of large scale PBT networks

  • Ensuring that the simplicity of PBT is not compromised by feature creep

As already mentioned, because PBT/PBT-TE is still work in progress, there is thus the danger of bloating, in which the technology’s basic simplicity, which is its rationale, is lost under layers of additional capabilities and complications that are added as the result of carrier and vendor inputs and agendas.

Vendor differentiation is likely to occur here, too, as different vendors will take different approaches, for which there will be room within the developing standards. And there is likely to be a transition period from PBT to PBB-TE when the latter is completed, in a similar way to which Cisco’s tag switching evolved into the standardized MPLS. However, so far vendors are generally satisfied that interoperability has proved to be good.

Ethos Networks’s Dunsky points out that QOS in carrier networks is obtained, for the most part, by using similar techniques, and this remains true for PBB-TE, where the common technique is to employ class-based queuing using the classic DiffServ model. MPLS has acquired a good reputation for QOS, partly due to the use of RSVP-TE for bandwidth reservation in the network enabling a more dynamic response to traffic changes and, consequently, better QOS.

"PBB-TE has great potential for more powerful QOS," Dunksy says. "Because of its deterministic nature, the traffic is much more predictable, and QOS mechanisms are therefore more efficient. In PBB-TE, bandwidth reservation is handled by the external control plane and its efficiency depends on different vendor approaches."

PBT/PBB-TE provides many features required for QOS. It can separate customer, provider, and operator domains. The Service Instance ID (I-SID) identifies each and every service, and, when coupled with the Backbone MAC Address (B-MAC) and Backbone V-LAN ID (B-VID), shows which service is being provided to which customer no matter where they are in the network.

“Another nice feature is that you can extract a PBT frame anywhere in the network and by looking at these fields, you know exactly where that frame is coming from, where it is going, what path it is taking, and what service it is delivering,” says Tpack's Barry.

In the Service Instance Tag (I-TAG), which includes the I-SID, the Service Instance Priority Code Point (I-PCP) field is a 3-bit Priority Code Point, which can be used to encode the priority and drop eligibility of the service, and is accompanied by the Service Instance Drop Eligible Indicator (I-DEI) bit, which indicates the drop eligibility of the service. The S-VLAN (service VLAN identifier) for the provider also includes a drop eligibility bit.

"So now you have mechanisms for prioritizing individual service instances (of which there can be 16 million) and the provider providing them," Tpack's Barry says.

Multipoint is still a challenge, although there are vendors that question the need for PBT/PBB-TE to have this capability, suggesting instead that other approaches – such as PBB with PLSB – are more appropriate, and that PBT/PBB-TE should be kept as simple as possible. It is a matter of standardization, as the frame format of PBB-TE is not natively multipoint (but neither was MPLS). There are ways to circumvent this – Ethos Networks, for example, proposes to replicate multipoint frames within switches. And it is also possible to produce a version of native multipoint by using many separate point-to-point links in a many-point-to-many-point configuration.

However, Hammerhead Systems is already using PBT/PBB-TE to support multipoint through its Carrier Multicast Ethernet Framework, and doesn’t see the need for immediate work on native PBT/PBB-TE multipoint capabilities. The basic approach is similar to the way VPLS uses Virtual Switch Instances (VSIs) as MAC-learning bridges meshed by MPLS label switched path (LSP) tunnels. Only PBT/PBB-TE trunks replace the LSP tunnels, and support what the company terms service instances, which are analogous to pseudowires. So the external control plane sets up both simple PBT/PBB-TE point-to-point connections for E-Line services, and point-to-point trunks between the VSIs for E-LAN services.

"We don’t expect the IEEE standard for PBB-TE to address E-LAN – it’s not in the scope of the current project. We also don’t expect the IETF to address E-LAN with PBB-TE – this is not in the scope of the IETF,” says Rob Keil, Hammerhead's VP of marketing and business development. "This is an advantage of Hammerhead’s approach for E-LAN over PBB-TE, because a carrier does not need to wait for a standard to basically support an E-LAN service. It just uses a centralized control plane to build a service using existing building blocks that are already well defined in the standards."

Different vendors have different approaches to resiliency in PBT/PBB-TE – and so will carriers, either for technical, economic, or historical reasons. For example, a key issue is to know when a link has been lost because of a fault. Some vendors will rely on the 802.1ag Ethernet OAM standard for fault detection and on providing restoration at Layer 2 – the CCM facilities defined by 802.1ag make end-to-end 50ms protection possible in a multivendor environment, as has been demonstrated in public interoperability events. Others will use the optical layer as well as 802.1ag to enhance resiliency in certain parts of the network, such as the metro core. This approach can complement PBT/PBB-TE very well, because the optical layer can have excellent resiliency and link-identification qualities that PBT/PBB-TE currently lacks. This is one argument for integrating PBT/PBB-TE closely with optical transport platforms, and is exemplified by the acquisition of World Wide Packets by Ciena.

Extreme Networks points out that, even if carriers don’t intend to use resilience at Layer 2 as the prime agent, it will still be a necessary checkbox item for equipment, and there are circumstances when certain failures might not be detected when DWDM transport is used – for example, the failure of an optical transceiver within an Ethernet switch. So multilayer protection is likely to be quite common.

Next Page: Technology Challenges, Part II

The interworking of PBT/PBB-TE and MPLS is obviously going to be crucial since MPLS is already widely implemented, so most carriers seeking to adopt PBT/PBB-TE would have to construct a hybrid network, or at least face the prospect of interworking with MPLS-based carriers. Essentially, there are two main approaches to such interworking. One is to use Ethernet VLANs as the common interworking medium, so the interworking process terminates both PBT/PBB-TE trunks and MPLS pseudowires, and maps these into VLANs, which are then remapped into the appropriate PBT/PBB-TE trunks or MPLS pseudowires.

This approach, which is currently the most common, has the advantage that a carrier Ethernet PBT/PBB-TE switch doesn’t need to know anything about MPLS, as it can simply swap VLANs via direct optical interfaces with an MPLS router running, say, VPLS. However, doing this results in a potential scaling and cost issue because of the 4096 per-port VLAN limit, which means that multiple interfaces and associated optical links must be used when very large numbers of VLANs are involved.

The second main approach is to have the PBT/PBB-TE switch support MPLS itself, so that it can work with the protocol direct without using VLAN interconnect. One way of doing this, supported in particular by Hammerhead Systems and Tpack, is to use a software add-on to provide a service gateway between the two protocols.

"Having a service gateway dramatically reduces the cost to interwork between the disparate PBT and MPLS/VPLS networks," says Hammerhead’s Keil. "Because we support all the draft Martini pseudowire capabilities, our device can sit at the edge of an MPLS/VPLS network and talk directly to routers through pseudowires, and be treated as just another router. However, it is not acting as a Layer 3 peer to them in that sense, rather it is an MPLS peer, from a pseudowire standpoint."

Finally, there is the challenge for commercial silicon. Current PBT/PBB-TE designs use either network processors or field-programmable gate arrays (FPGAs), which is common for new technologies, but Lightstorm Networks has launched the industry’s first commercial PBT ASIC, the Brooklyn-10. This is billed as an integrated 20 Gbit/s traffic manager and carrier-grade Layer 2 switch with low power consumption, providing a complete PBB, PBB-TE, Virtual Private LAN Service (VPLS), VPWS, and H-VPLS solution for carrier Ethernet. So it supports Layer 2 MPLS VPNs as well. The company argues that PBT/PBB-TE is now mature enough for an ASIC approach to drive volumes and shorten product time to market, as opposed to one based on network processors or FGPAs.

"Although those kind of solutions get you through this first generation, I think that they are either costly, typically power hungry, and do not provide all the carrier-class features that people are looking for," says Maurice Gleeson, Lightstorm's CTO.

However, proponents of the other approaches have not yet thrown in the towel in supporting PBT. In fall 2007, for example, Bay Microsystems announced the Provider Backbone Transport (PBT) application for its Chesapeake 40G Network Processor. And not all systems vendors are persuaded that ASICs will necessarily sweep the market, citing, for example, the flexibility that microcoding gives network-processor designs in an evolving technology where vendors may be seeking both functional competitive advantage and the ability to retrofit via software upgrades, rather than the highest volumes at the lowest cost.

Vendors of FPGAs also can argue that this approach has advantages: "We provide a Softsilicon solution, which is a standard chip product, like an ASIC, but based on an FPGA that allows adaptation and customization, like an NPU [network processing unit]," says Tpack's Barry. "So it combines the best of both worlds without the disadvantages of either... This makes us the only chip provider to support MPLS, VPLS, T-MPLS, and PBB-TE/PBT in a single-chip solution."

Barry argues also that PBT has not yet as reached a point where one can confidently make silicon because of the continuing development of this and other technologies. "We expect a lot of turmoil over the next two years in PBB-TE, and also in all of the other protocols involved, such as MPLS and T-MPLS, as well as in the requirements that the new converged packet optical platforms will place on Layer 2 silicon," he says. "Some telecom equipment manufacturers are trying to solve this problem themselves by using NPUs as development platforms, but we don’t think that is the lowest risk and most effective option for vendors who wish to remain leaders in this area."

Next Page: PBT/PBB-TE's FuturePredicting the future of a telecom technology is perilous, as anyone who remembers teletex will admit. But here are a few pointers that may help:

  • Everyone wants Ethernet and IP. Extending their capabilities and increasing carriers’ options for network infrastructure technologies can't be a bad idea. Who wants an engineering monoculture? (No names, please.)

  • PBT/PBB-TE is more of an add-on to carrier Ethernet than a purely new product category in itself. Since carrier Ethernet is not going to go away, PBT/PBB-TE has a long-term environment that can potentially support at least niche applications. And some niches can be very big.

  • Coexistence with MPLS seems most likely, but mainly in different parts of the network – MPLS in the core, working outward, meets PBT/PBB-TE in the access/metro, working inward. The precise details will depend on the network operator’s requirements and circumstances. Some smaller operators might go the whole hog and put PBT/PBB-TE into the core as well.

  • PBT/PBB-TE's fundamental rationale is to fuse Ethernet's traditional simplicity, robustness, and cheapness with the familiarity and directness of Sonet/SDH A-to-B circuit provisioning. It is not clear how much of this can be maintained as efforts are made to make it more like MPLS in its capabilities and to turn it into a fully fledged traffic-engineering technology. It may be that some vendors, for some markets, prefer to keep to the cheap and cheerful aspects in order to develop workarounds where needed, and eschew the further elaborations.

  • In the same vein, it is still not completely clear just how sophisticated PBT/PBB-TE needs to become. Viewed just as a transport solution, if it were to offer exactly the same point-to-point capabilities and features as Sonet/SDH (the carriers' current gold-standard point-to-point technology), existing MPLS/IP services could run over it in the same way as they do today over Sonet/SDH. No one complains that Sonet/SDH isn't a sophisticated service layer in its own right, with, say, multipoint capabilities. It may be that PBB, rather than PBB-TE, is the place to develop such capabilities – as the current work of 802.1aq exemplifies.

  • The heated controversy between the pro and anti camps may have more to say about the nature of the telecom industry than the technology. Bits and packets of bits can be either moved from A to B (transport) or processed (routing/switching). The demise of the former big integrated infrastructure vendors that did everything from microwave links to PSTN digital switches has largely left vendors focused on the moving or processing sides, and therefore with potentially a lot to win or lose according to whether a transport-oriented or a processing-oriented paradigm becomes fashionable. But it is a poor design philosophy that insists that one paradigm is the best under all circumstances.

  • There may be some interesting relationships with the underlying optical transport technology, exploitable by PBT/PBB-TE integration. Meriton Networks’s approach is one example, where the company has integrated Layers 2/1/0 transport and used PBB-TE at the edge, and employs a combination of wavelength, Gigabit Ethernet Layer 1 circuit, and PBB-TE tunnels in the core, depending on the capacity and destination of the traffic. Meriton argues that this approach results in the lowest cost (for example, by reducing a metro hub port explosion) while optimizing the QOS for transit traffic. Another is Matisse Networks 's optical burst switching (OBS). (See Matisse Primes Metro Ethernet Makeovers.)

Overall, the PBB/PBT-TE vendors appear increasingly confident that they have started a movement that is going to last.

"The support environment is progressing. Soapstone and Aria are quickly developing management functionality, and silicon vendors are beginning to offer devices supporting the technology," says Ciena's Daines. "So, in general, the technology has moved from proprietary/nascent to a full-fledged alternative to traditional Q-in-Q Ethernet in the access and MPLS in the metro."

And, inevitably, the last word has to go to Nortel:

"We believe PBT is one step along the way of the evolution of carrier Ethernet, just as PBB was before it – and already [provide link state bridging] PLSB is emerging as another key step along the way, and there will be others," says Nortel’s Hawkins. "Ultimately we believe the market will be divided between the IP/MPLS infrastructure proponents and those like us who advocate a carrier Ethernet infrastructure. We will continue to target our products, across the portfolio towards the sweet spot which accommodates MPLS services, interworks with IP/MPLS infrastructures in the core, but capitalizes on the inherent cost advantages of Ethernet."

— Tim Hills, Special to Light Reading
Edited by Phil Harvey, Editor-in-Chief, Light Reading

Return to Introduction

Read more about:

Omdia
Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like