PBT is one of the latest must-have telecom monograms, although the Institute of Electrical and Electronics Engineers Inc. (IEEE) 802 Standards Committee – ever one for snappy monikers – seems determined to weary every journalist’s fingers by renaming it PBB-TE. But even that can’t stop Provider Backbone Transport technology from making waves in the press and definite ripples among service providers and their suppliers.

And they increasingly look to be more than ripples, following BT Group plc (NYSE: BT; London: BTA)’s well publicized endorsement in mid 2006 of the technology in its massive next-generation network project, the 21CN, and growing industry support for a standard. (See BT Likes Nortel's New Ethernet Flavor and Cisco Tracks PBT Standards Process).

So a good round 60 percent of service-provider respondents to a poll in the Light Reading Webinar on which this report is based said they would consider using PBT for two or more of the following metro applications: business E-line or E-LAN services, residential triple-play services, and wireless backhaul.

But uncertainty abounds. Only about a quarter of the respondents thought that PBT could replace Sonet/SDH equipment or enhance carrier Ethernet with traffic-engineering capabilities; and only 40 percent thought it would be cheaper than the current favorite technology for converged metro networks – MPLS.

Certainly, PBT’s protagonists are promising good things from the technology. In particular, they say that:

Perhaps most unsettlingly for service providers and carriers, PBT challenges the conventional wisdom that IP/MPLS is the way to go in next-generation networks (NGNs) – especially in the metro. So are carriers going to have to rethink their NGN strategies? That’s a huge question, and this report doesn’t aim so high. Instead, it aims to put PBT into context by looking at its development and some key questions – considering pros and cons, comparing it with alternative technologies, and considering how it might coexist with them.

Here’s a hyperlinked contents list:

Webinar

This report is based on a Webinar, Ethernet’s Core Question: The Case for PBT, moderated by Simon Sherrington, Independent Consultant, on behalf of Light Reading, and sponsored by Extreme Networks Inc. (Nasdaq: EXTR) and Nortel Networks Ltd. . An archive of the Webinar may be viewed free of charge by clicking here.

Related Webinar archives:

Light Reading Insider Report

PBT's Carrier Ethernet Appeal, Simon Sherrington, Analyst, Light Reading

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

Next Page: PBT: Why the Fuss?

Provider Backbone Transport is a new idea in carrier transport networking – or, perhaps more accurately, an old idea in a new guise. It’s a means of adapting Ethernet more closely to the circuit-oriented point-to-point service-delivery architecture of Sonet/SDH carrier transport networks. The word transport is very important here – PBT is not about Ethernet as an end service or line extension, for example. Instead, PBT is an enhancement to an Ethernet network being used by a carrier as the underlying bearer transport, and can thus transport any packetizable payload – such as ATM, Frame Relay, IP, or, indeed, an Ethernet service itself.

Essentially, PBT adapts Ethernet into a tunneling protocol that creates circuit-oriented, end-to-end Ethernet tunnels across a carrier Ethernet transport network. This is highly desirable because it promises to bring high levels of service reliability, manageability, security, and scaleability to carrier Ethernet transport. PBT’s proponents see this as taking Ethernet to the next level and offering an SDH/Sonet-like experience on a carrier Ethernet network.

“If history has taught us anything, then service scaleability comes from the ability to build a resilient, scaleable transport infrastructure,” says Ken Davison, VP of marketing at Meriton Networks Inc. “And that transport infrastructure has always been built on point-to-point connections on which you overlay your service, which could be point-to-point or point-to-multipoint or any-to-any. I think operators have now said they want a single IP infrastructure which is going to be running multiple services – and that infrastructure is going to be MPLS. But, underlying that, how do we build a transport architecture?”

In principle, PBT fits this transport role nicely. It offers an improved platform for point-to-point transport, with carrier-class scaleability and reliability, Sonet-like sub-50ms restoration, and a strong analogy with circuit-based transport networks, with which carriers have always felt comfortable. And it equips Ethernet to assume a much larger role in the network.

PBT has created a lot of fuss because it is being positioned by some of its adherents as a potential replacement for IP/MPLS within some parts of the future carrier next-generation network, and in that sense PBT is a pretty hot topic within the telecom community right now. It challenges the widely accepted view that IP/MPLS is the primary way forward within the metro network.

Another attraction is that PBT builds on existing or emerging Ethernet standards, but in a fairly modest way. PBT protagonists argue that this will not require significant new standards effort, will maintain compatibility with other Ethernet developments, and will allow PBT to share Ethernet’s long-established virtues of wide application and low costs.

And PBT appears to be gaining real support among carriers and vendors. BT’s espousal of the technology with Nortel Networks Ltd. – and its role in pushing for standards – is well known, but carrier interest (especially in Europe) is growing. And other vendors, such as Meriton, Extreme Networks Inc. (Nasdaq: EXTR), and World Wide Packets Inc. , are releasing PBT products.

“There are clearly a lot of vendors starting to get their heads around PBT,” says Davison. “I think the initial announcements outside ourselves have been vendors – basically, who are carrier Ethernet switch/routers or Ethernet switches – who are looking to upgrade their PBB implementations to PBT. Certainly, as you look at the implementation of a circuit-oriented model for Layer 2 – even T-MPLS at Layer 3 – how that integrates into an integrated transport layer will become pretty important, because that is how we are going to scale the networks.”

Next Page: PBT: Foundations

PBT technology rests on three Ethernet standards that act as building blocks for the new approach:

Provider Backbone Bridging (PBB)

PBB is the proposed IEEE 802.1ah Provider Backbone Bridging standard, also often known as MAC-in-MAC. It allows Ethernet networks to scale to millions of service instances while maintaining the established economic benefits of Ethernet. Figure 1 shows the basic approach, where PBT works with existing Q-in-Q (IEEE 802.1Q/802.1ad) VLAN stacking to run VLANs from one customer edge to another across an Ethernet core.

“PBT solves really two key problems that people have when building large carrier networks,” says Peter Lunk, director of service provider marketing for Extreme Networks. “The first is the size of the VLAN ID field. This is extended in the MAC-in-MAC approach to support millions of different service instances. The second is the need for core switches to learn millions and millions of MAC addresses as the networks grow. With the switching being done only on the MAC address that gets added in the core, the switches need to learn only the local MAC addresses and the addresses of the other switches within that core. This helps to keep table sizes and, consequently, hardware costs down.”

Ethernet Operations, Administration, and Management (OAM)

Ethernet OAM, traditionally a weak point from a carrier perspective, has made a lot of progress with the proposed IEEE 802.1ag standard, also known as Connectivity Fault Management (CFM). This provides network monitoring and maintenance tools that are very important to operators deploying carrier Ethernet – including Ping and Trace Route capabilities that can simplify the troubleshooting of large Layer 2 networks. (See Ethernet OAM & Demarcation Devices.)

But the most relevant part of the standard for a basic discussion of PBT is the Continuity Check Message (CCM), which can be used within PBT for protection switching. This is an end-to-end link-status check with a configurable message frequency. So, after missing, say, three consecutive CCMs, the affected link can be declared down and corrective action taken.

For example, if the frequency of the CCM is set to once every 10ms, a link problem can be detected within 30ms, leaving 20ms in which to perform a protection switch to a standby path and still meet the usual carrier-class failover time of 50ms. PBT’s supporters see this as a big selling point for the technology.

Performance Management

The final PBT building block is performance management. In addition to work done in the IEEE, the ITU-T has taken Ethernet performance management forward with Recommendation Y.1731, which focuses more on OAM and performance management at the service layer. This includes capabilities like device discovery, continuity checks, link trace, and loopback (intrusive and non-intrusive). It also includes AIS capabilities and a variety of statistics for use in SLA verification – things like frame loss, frame delay, average delay, and frame delay variation.

Next Page: PBT: How It Works

The overall effect of the 802.1ah, 802.1ag, and Y.1731 standards is to enhance Ethernet as a carrier transport mechanism by making it more scaleable and enhanced with the kind of OAM and performance toolsets that carriers need. However, PBB is not specifically tailored for supporting point-to-point transport connections, and so PBT (PBB-TE) further refines PBB carrier Ethernet for point-to-point transport. It does this by modifying and removing some of the key behaviors of a conventional Ethernet network, as summarized in Table 1.

Table 1: PBT (PBB-TE) Disables Selected Standard Ethernet Functions

The essential point is that PBT strips out standard Ethernet capabilities that are not needed when it is operated in a carrier-controlled, point-to-point environment. In particular, PBT replaces flooding and learning with control and configuration. Loops, for example, do not occur when a carrier is preconfiguring point-to-point connections across its own network. Essentially, PBT turns Ethernet into its own tunneling and traffic-engineering protocol.

“The key thing to understand is that today’s scoping of VLAN and Ethernet topologies under Spanning Tree is to do flood-and-learn,” says David Allan of Nortel's CTO Office. “This imposes a lot of constraints on Ethernet that are not actually required for point-to-point operation. If we can treat point-to-point as a special case, that changes the landscape quite dramatically, and Ethernet makes that comparatively easy.”

However, despite deactivating certain elements of a standard Ethernet switch, PBT is not a standalone solution, as shown in Figure 2.

“VLAN partitioning of the network is a key enabler of an Ethernet solution that can use both PBT and PBB operation,” says Allan. “It allows us to run different profiles of Ethernet forwarding side by side, while actually maximizing the common components such as the management and administration, and so on.”

So PBT, point-to-point, traffic-engineered trunks are based on existing Ethernet forwarding principles. PBT reuses the existing Ethernet forwarding plane; all that is changed is how it is populated. Instead of using flooding and learning, the MAC-in-MAC address space is entirely provider controlled, and therefore, in principle, straightforward to configure, since the provider knows in advance the MAC addresses.

“The only really subtle change is how we think about VLANs,” says Allan. “They are no longer an index of a Spanning Tree instance – they index an instance of the entire network instead. Which, if you simply unblock the ports for those VLANs, is exactly what they work. This ultimately means that we have revealed an awful lot of latent capacity that has existed for a long time in Ethernet bridges.”

Table 2 shows the basic stacked frame structure used in PBB and PBT. Essentially, the edge bridges shown in Figure 2 wrap incoming Ethernet traffic into this stacked structure. The MAC-in-MAC components are the backbone addresses – the backbone source address (B-SA) and the backbone destination address (B-DA). The backbone VLAN (B-VID) maps, among other things, to either PBB or PBT operation, depending on the forwarding paradigm being using. A key part is the MAC-in-MAC’s big service tag – the I-SID – which provides a 24-bit, globally unique service identifier. This is enough to specify about 16 million different service instances over the infrastructure.Table 2: Basic PBB/PBT Stacked Frame Structure

Switching within the backbone is based on the backbone MACs (B-SA and B-DA) and the B-VIDs. Put crudely, there is effectively lurking within Ethernet bridges a huge packet crossconnect, and PBT allows this to be manipulated independently of Spanning Trees. This allows the Ethernet bridges to be repurposed to support point-to-point path placement side by side with conventional bridged behavior.

Figure 3 shows this in operation. There is no specific PBT equipment, just provider bridges and provider backbone bridges. The provider backbone bridges are engineered to enable PBT, and point-to-point connections between locations are preconfigured. Routing within the core is based on the MAC addresses of the egress PBB switches, and one of the backbone VLAN IDs is used to decide which route through the network the traffic should take.

One backbone VLAN ID specifies the primary route through the network – in this example, shown by the solid red line – and one specifies the backup route – the dashed red line. There are essentially two ways of connecting shown in Figure 3. Either through a provider bridge as for Client 1, Site 1, or directly into the PBB network, as for Client 1, Site 3. Note that PBB4 provides onward connectivity into the carrier’s IP/MPLS backbone.

Next Page: Question 1: Is PBT Standardized?

BT and Nortel introduced PBT to the Institute of Electrical and Electronics Engineers Inc. (IEEE) as a potential candidate for a standard in September 2005. At its last meeting, in Dallas in November 2006, the IEEE 802.1 committee unanimously agreed to continue to formulate a project authorization request (PAR) proposal to go to the executive committee for the March 2007 plenary meeting. If (almost certainly when) approved, formal standards work will begin, and PBT is likely to get a new name: Provider Backbone Bridge Support for Traffic Engineering (PBB-TE).

Current guesses are that it may take about 18 months to complete the process. However, PBT’s supporters argue that the standard is likely to be technically complete well before then. PBB (802.1ah) on which PBT partially depends, is already at Draft 3.3, and a sponsor ballot is expected in the first half of 2007.

“If we look at what needs to be done, one of the amazing things about PBT is how small the changes are to existing Ethernet equipment. Not to trivialize the work that needs to be done in the standards bodies, but the changes really are pretty minor,” says Extreme’s Lunk.

According to Lunk, there are three main tasks:

Vendors are already discussing interoperability and product trials. Lunk says that an Extreme/Nortel interoperability demo can be expected at a tradeshow “later this year.” Davison says that Meriton will have its first PBT implementation “by the second half of this year.” As a further example of PBT’s growing product availability, World Wide Packets announced, in January 2007, PBT support in its LightningEdge product family.

Next Page: Question 2: What Problems Could PBT Solve?

In principle, PBT might resolve a number of issues facing network operators in their move to next-generation networks. According to PBT’s supporters, these include:

However, of course, there are always some potential downsides and criticisms.

Capex and Opex of Metro IP/MPLS

The essential argument here is the well-worn one that Ethernet itself has the potential to be cheaper than IP/MPLS (and just about any other networking technology, for that matter), while PBT levels the playing field with MPLS by adding improved point-to-point capability to Ethernet. Structurally, however, there is a key difference: IP/MPLS terminates three layers on every blade (link layer, IP, and MPLS), while PBT uses just a single (Ethernet) layer.

“Simply trivializing PBT as lowballing the capex part in my opinion is a serious mistake,” says Nortel’s Allan. “It is a key opportunity to collapse the number of layers that you need to operate to run your infrastructure that will provide recurring savings. It is also some of the fundamentals of the actual design of Ethernet itself that are actually quite advantageous from the point of view of very simple network operations.”

Hubbing in a metro Ethernet network is one area where the flatter structure of PBT compared to MPLS may make a lot of sense, according to Meriton’s Davison. He points out that in many markets in Europe, for example, sheer customer demographics determine that a large percentage of traffic originates and terminates within metro areas. So a large amount of connection-oriented traffic would be hubbed, aggregated, and switched within the metro area.

“If you look at the additional processing requirement, you are switching Ethernet and so still have to put the MAC header on there, but why add the burden of putting – even if it is a thin shim – a header for T-MPLS if it is not going anywhere near the MPLS cloud?” Davison asks.

Operating Complexity of IP/MPLS

Ethernet frames have the interesting property of always being fully self-describing, and successive developments of the standard – including PBB/PBT – have preserved this. It means that, just by looking at a frame in isolation, a carrier can see where it is going and how (from B-VID and DA); where it came from (SA); what its priority is (.1P priority marking); the service carried (802.1ah I-SID); and the payload format (Ethertype).

In contrast, the label-swapping as used in MPLS-based networks in setting up tunnels, for example, tends to be context dependent – labels by themselves have no inherent meaning, and there has to be a processing step (or steps) with lookups to correlate them with something meaningful. In principle, this means that an MPLS network is less transparent than a PBT one for troubleshooting, and involves more protocols and processing to obtain the desired behavior.

Ethernet Scaleability for Point-to-Point Networking

Point-to-point for 802.1ad (Q-in-Q) used the VLAN alone for point-to-point forwarding, but PBT (via 802.1ah MAC-in-MAC) moves the forwarding entry from 12 bits of VLAN to 60 bits of VLAN/MAC, and from Ethernet Virtual Connection (EVC) to Ethernet Virtual Path (EVP) precisely because the provider is in control of MAC forwarding.

“What this ultimately means with respect to scaleability is that I am moving from a 12-bit connection ID in the data plane to a 60-bit destination identifier and destination modifier, as Ethernet is destination-based forwarding,” says Allan. “In reality, I take the source address, the VLAN, and the destination address as my full data-plane description of a connection – that’s a 108-bit, point-to-point connection identifier. We just do not need to put all of it in the forwarding tables.”

Obviously, no real implementation can have a table that will scale to a full 60-bit label, but bridges scale to quite large tables today, and – even if Moore’s law continues to hold – Allan argues that it will be many years before the design fundamentals of the approach are exhausted.

Ethernet Security

PBT disables many risk-causing features of conventional Ethernet because switching is done only on provider-controlled information. All the user part is encapsulated, which removes many of the lines of attack that malicious or incompetent users can apply to the network. Providers do not peer with their customers.

Reuse of Familiar Sonet/SDH-Type Practices

The strong operational analogy with the long-established and familiar circuit network environment can have considerable appeal to carriers in terms of staff training and OSS development for NGNs. The TeleManagement Forum, for example, has a work item looking at the OSS requirements for PBT.

Some Criticisms

Inevitably – and healthily – PBT faces criticisms. These include:

PBT’s adherents respond to the last few points by stressing that Ethernet (and, indeed, point-to-point connections) in general isn’t rocket science – it is well understood and well tried – and the amount of standards extension PBT requires is pretty small and does not involve any new technology. On the issue of point-to-multipoint, this appears to be a misunderstanding, as PBT can also configure group multicast MAC addresses.

“PBT-style configuration of MAC addresses is also equally applicable to group multicast addresses, so it is a perfectly valid application of the PBT technique used in conjunction with normal bridging,” says Allan.

On the issue of configuration and automation, the pro-PBT response is that traditional Sonet/SDH providers actually handle the nailing-up of existing point-to-point circuits pretty efficiently, and that this is not a difficult process to add to NGN provisioning systems. Further, the use of path protection permits configuration to be a non-real-time function, so there is no real impact on restoration times in terms of how long it would take to put up a circuit.

It is also arguable whether the use of routers does indeed replace people to a significant degree, given that there are carriers that run million-circuit networks with very mature automation.

“That presupposes that somehow routers are the only form of automation that exists, and that a routed network is largely hands off,” says Allan. “I don’t think you can safely make that assertion. The reality is that the skillset for router personnel is much more demanding, and the potential problems they need to be able to deal with can be much more subtle. It is not clear to me that not using routers somehow results in increased personnel or other costs. In my opinion it is the migration from circuit to packet that has allowed carriers to re-engineer their processes, and not necessarily how automation was applied to packet.”

Next Page: Question 3: How Does PBT Compare to Alternatives?

An obvious question after looking and some of the pros and cons of PBT is how it compares technically with the main carrier alternatives, especially in the metro. These are principally the well known IP/MPLS (and its newer offspring, T-MPLS) and PVT.

IP/MPLS

Until the recent PBT-inspired debate, IP/MPLS has been pretty much the de facto choice of technology for next-generation core transport networks, and it has been heavily promoted in the metro as well. It is a highly developed and widely supported technology with an extensive and growing set of standards.

Technically, MPLS works with IP to support both Layer 3 IP VPNs and Layer 2 pseudowires – and, in particular, any-to-any Ethernet Virtual Private LAN Service (VPLS). Some of its characteristics are:

MPLS originated within the IETF as a means of improving core IP router performance, rather than specifically as a base for a future carrier-class transport architecture. This has led the International Telecommunication Union, Standardization Sector (ITU-T) – the traditional international body for standardizing carrier telecom architectures – to develop an offshoot of MPLS, dubbed T-MPLS, to address some of the particular requirements of telecom carriers.

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. Just as PBT “dumbed down” Ethernet, T-MPLS dumbs down MPLS. Some of its characteristics are:

As initially defined in G.8110.1, the service provided corresponds to that offered by PBT, but requires both T-MPLS shim and link layer. Standardization work is currently (Q1 2007) in progress in the ITU-T Study Group 15 and may take about a year to complete.

In terms of standardization progress, there does not seem to be much difference between T-MPLS and PBT/PBB-TE.

“If you look under the covers on T-MPLS, the big gaping hole is in the operations and administration standards work. That, I don’t think, is any different to what is required within PBT. So I wouldn’t see T-MPLS moving that much ahead of PBT,” says Meriton’s Davison. “I don’t think that the standards issue is the key issue.”

PVT

Provider VLAN Transport (PVT) is a method of VLAN crossconnection, and is a proposal to do Ethernet VLAN tag swapping. Effectively, it embeds two fabrics in a switch: one that does bridging and one that swaps VLAN tags or swaps VLAN tag stacks – either a 12- or 24-bit swap, depending on whether one or two VLAN tags are used. This enables VLANs to be switched across a network in a similar manner to ATM or MPLS switching, as the VLAN IDs have only local significance.

PVT was proposed by Huawei Technologies Co. Ltd. and Siemens AG (NYSE: SI; Frankfurt: SIE) to the IETF as draft-sprecher-gels-ethernet-vlan-xc (expired September 2006), and has also been proposed to the IEEE 802 committee. Like PBT, PVT builds on existing Ethernet standards – it uses the older 802.1ad (Q-in-Q) rather than the upcoming 802.1ah (MAC-in-MAC) – but there are some concerns that the currently unspecified 24-bit tag is an Ethernet architectural violation, and the specified 12-bit tag only intended for demarcation boundaries. This whiff of unresolved Ethernet compatibility suggests that PVT is unlikely to emerge very soon as a standardized challenger to PBT or T-MPLS.

Three Types of Metro Ethernet Service

So it looks as if the immediate contest will be among transport networks based on IP/MPLS, PBB/PBT Ethernet, and T-MPLS. An interesting question is: How do these three technologies compare in terms of the types of connectivity that might be required?

A good place to start is the metro connectivity required for the three MEF (MEF) service primitives: E-line, ELAN, and E-tree:

Tables 3 and 4 show how the three technologies compare for these service types in terms of general characteristics and resilience. Given the state of standards development between the ITU-T and the IETF, the situation for T-MPLS is not entirely clear, and Tables 3 and 4 are based on definitions as given in G.8110.1 – which imply, for example, a VPLS-like mesh, but done at the transport layer, for ELAN services.

Table 3: General Comparison of IP/MPLS, (PBB/PBT) Ethernet & T-MPLS for Metro Ethernet Forum Service Primitives

Table 4: Resilience Comparison of IP/MPLS, (PBB/PBT) Ethernet & T-MPLS for Metro Ethernet Forum Service Primitives

In Table 3, all three approaches have E-line well-covered. However, the any-to-any ELAN/E-tree side is more of a mixed bag. VPLS on MPLS is a split horizon for mesh and is well understood, but it has scaleability limitations, which have spawned things like H-VPLS and the notion of Q-in-Q subtending from it. Effectively, however, the architecture is a point-to-point mesh laid onto a connectionless network, with multicast replication pushed to the edge.

Ethernet for the any-to-any ELAN and E-tree has the defined multiple spanning tree and rapid spanning tree, and there is also a new class of solution now being discussed at the IEEE in the form of Shortest Path Bridging (SPB) and Shortest Path Backbone Bridging (SPBB), which look to add a routing system to Ethernet and integrate much more efficient multicast into the infrastructure layer.

T-MPLS appears to be more problematic for any-to-any services, according to Allan: “There is some initial discussion with respect to T-MPLS for any-to-any, but I believe we are currently restricted from comparisons right now to simply looking at a protection-switched full mesh when considering it.”

An implication is that T-MPLS will suffer from the N-squared scaling effect.

In Table 4, for resilience options, all the solutions can do diverse path routing for E-line. It’s worth pointing out that fast reroute is actually somewhat different from end-to-end path protection switching, as fast reroute requires a backup LSP per point of failure in the network, and is really a best-effort local-repair technique designed to maintain connectivity through network reconvergence and reduce the impact of failures during the reconvergence period. Path protection does not assume an additional reconvergence period but requires some additional path planning to ensure the backup can effectively "stunt-double" for the working path within the required SLA.

“For ELAN and E-tree, MPLS and Ethernet solutions are going to be gated by either routing system convergence or, if you are still using the spanning tree solution in Ethernet, the spanning tree and rapid spanning tree convergence times,” says Allan. “T-MPLS, being purely connection oriented, would appear to be limited to path protection as the answer in all scenarios as currently specified. So I am going to be nailing up diverse paths between any point in the any-to-any network to produce a full mesh.”

Extreme’s Lunk points out that 50ms restoration is now pretty well taken as standard among vendors supplying the carrier Ethernet market.“It’s really a matter of table stakes,” he says. “If you are going to bring out a new technology for the service provider market, you are going to need that type of resilience. I think that PBT has checked that box, and it is certainly an advantage to be able to do that on an end-to-end path basis across the network.”

Next Page: Question 4: Will There Be a Showdown With MPLS?

It’s very easy when a potentially attractive, but also potentially disruptive, new technology comes along, to go into showdown-mode hype – carriers are going to have to tear up their existing NGN plans and start again, and so on. The reality is usually much less clear-cut and much more of a compromise as carriers seek to balance existing infrastructure investments, financial resources, and business realities and goals.

There seems to be no doubt that MPLS in its T-MPLS form and Ethernet in its PBT/PBB-TE form both have circuit-mode capabilities that carriers and service providers want. As Meriton’s Davison points out, to frame a debate in terms of whether to use T-MPLS or PBT is really to ask about the use of tunnel technologies in the network – where and when?

“If a carrier has invested in IP/MPLS and packet-over-Sonet/SDH – which most have in the core/transport area – then the argument leans towards using T-MPLS,” he says. “However, if the architecture is migrating to Ethernet as the link layer of choice in the access – which most carriers are – then the argument leans towards capping MPLS (VPLS) and Sonet/SDH as transport (migrate to service layer/client) and using PBB-TE onto WDM/OTN.”

Nortel’s Allan takes a similar view that there will tend to be a mix of the two technologies, as Ethernet is going to be there regardless, and neither is best in class at everything.

“I have never liked the idea that it is an either/or question and there is only going to be one winner. To me, the more likely scenario is that the winning solution in the metro is going to have key components that have been imported from both solutions,” he says. “Ethernet links are going to be there regardless. I also believe that Ethernet for Ethernet solutions in the form of ELAN, E-line, and E-tree as defined by the MEF are going to be best in class in terms of how they work. The other key observation is that, for the stuff that is non-Ethernet clients, there isn’t really a lot of point in completely reinventing adaptations for ATM, FR, PPP, etc., and replicating the work that has already been done in PWE at the IETF.”

This suggests one possible scenario for PBT and MPLS coexistence: The combination of Ethernet, PBT, and MAC-in-MAC would cover the Ethernet service landscape, while providing a complete PSN for MPLS- and pseudowire-based services. Allan sees this as providing a cost advantage over blanket MPLS deployment, potentially combining with a sparse set of MPLS-enabled devices that view the metro as a single Layer 2 hop. Figure 4 shows how this might work in practice.

This shows widespread deployment of MPLS in the core (WAN), where it dominates for the foreseeable future, but a relatively sparse deployment of MPLS-enabled devices in the metro (MAN) that overlay an Ethernet infrastructure. So the metro, as far as the MPLS world is concerned, appears as a relatively large Layer 2 segment, which is well within MPLS’s capabilities to handle. Ethernet services are provided directly by the carrier Ethernet metro, and legacy services – circuit emulation, ATM, Frame Relay, wireless backhaul, and so on – use pseudowire adaptation mapped directly onto Ethernet.

But it is clear that handling the details of such an arrangement will present vendors with new opportunities for product typing, development, and differentiation. For example, Davison points out that it is still unclear whether T-MPLS or PBT will give a better interface into an MPLS switch. Meriton has thus added the capability to its metro 7200 platform of wrapping a PBT tunnel into a T-MPLS header for pushing into the MPLS WAN cloud.

He argues that regulatory attention, especially in Europe, is driving carriers to consider PBT as a potentially better option in the metro for local-loop unbundling and for point-to-point services – in short, for regulated wholesale services, and this affects product strategy.

“To structure your networks, you need to consider the regulatory environment, because it clearly has an impact on your business case,” says Davison. “So where do you need points of interconnect, especially if you want to drive a wholesale network? Is it off the line side or the backhaul side of the service-aware DSLAMs or MSANs? On the edge or egress of the metro from the metro hub device? And what are those points of interconnect? STM interfaces? Ethernet? Optical? If you look at all that, it has driven a lot of our strategy in terms of acting as a wholesale interconnect switch. It not only switches as the optical layer, but it switches at GigE and now at PBT, and it can do a seamless handoff between them.”