You are on page 1of 11

www.idc.com

F.508.935.4015

P.508.872.8200

Global Headquarters: 5 Speen Street Framingham, MA 01701 USA

Global Headquarters: 5 Speen Street Framingham, MA 01701 USA TECHNOLOGY ASSESSMENT PBT: The Hype and the

TECHNOLOGY ASSESSMENT

PBT: The Hype and the Reality

Eve Griliches

IDC OPINION

Service providers have made significant investments in their networks in order to manage traffic, avoid network congestion, and offer new services. Investment in MPLS networks has effectively delivered business services over the past 10 years. With extensions to MPLS (MPLS-TE) and T-MPLS (a derivative of MPLS), new options now enable connection-oriented packet transport for Ethernet services. The T-MPLS approach has been joined by a new protocol, Provider Backbone Transport (PBT), which is supported by Nortel and various other vendors in the market. PBT (PBB, PBT, PBB-TE) and T-MPLS share similar feature sets: connection-oriented transport configured using a centralized provisioning methodology. T-MPLS is slightly ahead of PBT in the standards bodies but is still far from delivering the maturity that an MPLS network does today. Carriers who invested in their SONET/SDH infrastructure and are looking to migrate their networks onto single IP platforms are interested in new approaches that might be simpler than the existing MPLS offerings today. IDC notes the following:

! The telecommunications industry tends to be difficult in nature in that providers have wrestled with wanting their edge networks to be simple and cost effective, and yet they demand intelligence and high performance in order to deliver multiple services. Overlay this with the latest technology changes and it seems we have entered yet a new cycle: a cycle where providers are trying to deliver multiple IP services with a level of multi-layer flexibility. This requires intelligence to reside as close to the provider edge as possible. At the same time, Ethernet has been adopted outside the LAN as a viable alternative to legacy Layer 2 technologies (ATM and frame relay) and as a transport alternative to SONET/SDH.

! The ultimate goal of any service provider is to offer multiple profitable services. Customers do not care what technology their service is delivered on, they merely care that their service is reliable and of reasonable quality. Providers have focused on delivering IP services to their customers over whatever layer of transport their customer has chosen. But they have not been able to reduce the complexity in their own networks or truly realize cost benefits.

! Tier 1 providers that already have MPLS cores, and in many cases MPLS metropolitan networks, are unlikely to adopt more restrictive protocols because they need to deliver multiple services to multiple points on their network, preempt network congestion, and provide intelligence at the edge to deliver revenue- generating services.

Filing Information: May 2007, IDC #206653, Volume: 1 Telecommunications Equipment: Technology Assessment

IN THIS STUDY

 

In this study, IDC discusses Provider Backbone Transport (PBT) as a protocol and new technology, which has garnered huge amounts of press and analysis to date. How widely spread PBT will become and who the likely natural adopters of PBT are will be under discussion.

For the sake of this paper's discussion, we address PBT with a centralized network management system as the control plane (in contrast to the option to employ a distributed control plane, e.g., GMPLS). All further discussion pertains to both PBT and PBB-TE with a centralized control plane.

SITUATION OVERVIEW

 

PBT has been wildly overhyped as the next major protocol to deliver capex and opex reductions. We will examine each of the claims that PBT makes: simplicity, scalability, reliability, and most importantly lower capex and opex costs. But first, we define PBT.

PBT,

PBB,

and

PBB-TE

Defined

If you follow the general assumption that transport networks today are moving toward replacing or overlaying their SONET/SDH infrastructure with packet-based technology, then you are in the majority of the market. PBT proponents generally believe the metro/access area is the most likely market for PBT to be deployed, but there is some discussion that it can be applied to the core transport networks as well.

Provider Backbone Transport was created to use Ethernet for connection-oriented purposes, similar to connection-oriented networks such as SONET/SDH, ATM, and optical networks. PBT strips the complexity out of Ethernet by removing spanning tree, flooding, and broadcasting. Where improvements can be made, PBT enhances Ethernet technology for use in carrier-class transport networks.

PBT builds on Provider Backbone Bridging (PBB), which is MAC-in-MAC encapsulation (IEEE 802.1ah) by adding tunneling to PBB. PBB-TE is one form of PBT (the one with support for central provisioning) currently being scoped in the standards committees. An ongoing discussion within PBB-TE proposes the use of distributed control plane based on generalized MPLS (GMPLS). GMPLS is focused on dynamic provisioning of optical wavelengths and maintains a single control plane that is integrated across multiple layers. But GMPLS is currently only supported in the optical domain and has had minimal adoption to date since dynamic wavelength provisioning is still not physically possible in long-haul and metropolitan core networks.

For this technology insight, we are addressing PBT with a centralized network management system as the control plane in contrast with the options to employ a distributed control plane (e.g., GMPLS), as is being scoped within the PBB-TE standardization efforts. All further discussion pertains to both PBT and PBB-TE with a centralized control plane.

©2007 IDC

#206653

1

How

PBT

Works

! Traditional Ethernet LAN features such as spanning tree, flooding, and broadcasting are turned off when PBT is deployed. Spanning tree is simply not suitable to the service provider environment, neither is flooding or broadcasting.

 

! PBT then adds elements of Q-in-Q (IEEE 802.1ad), MAC-in-MAC (IEEE 802.1 ah), and OAM (IEEE 802.1ag) feature sets. PBB-TE proposes additional extensions for path protection.

! When using PBT, the control plane becomes "centralized" (as opposed to a distributed control plane, as is deployed with IP/MPLS), effectively making it seem simpler by shifting it to the management layer. A centralized control plane technically eliminates the need for distributed routing and signaling protocols. In other words, there is no need to run BGP, OSPF, ISIS, or RSVP-TE or LDP signaling versions of MPLS. PBT does strip complexity out of the Ethernet control plane, but it adds complexity to the provisioning system. This effectively becomes

 

"zero sum" game, where the complexity is now shifted from one component of the system (the control plane) to the provisioning plane.

a

Is

PBT

Simple?

 

By shifting the control plane to the network management system (NMS) and eliminating routing protocols, one can argue that the network is now simpler to manage and easier to provision for Ethernet transport. And this is probably true since the network is now a static and provisioned network versus a dynamically routed network. There are many providers out there that embrace this simplicity. The question is, How much of the general market do they represent?

 

!

This is where PBT truly delivers, on simplicity. There no longer is a need to provision traffic engineering and control plane protocols on each node. There is no question that Layer 3 protocols can be intimidating and confusing, not to mention complex. The typical IP engineer relishes this complexity, but some service providers are loath to learn the issues and simply want to deliver services and manage their networks without their beeper going off in the middle of the night.

!

PBT is simpler in that it only supports point-to-point provisioned networks. And although point to multipoint and multipoint to multipoint are in design for support some time in the future, the point-to-point architecture is ultimately limiting in that

it

does not support a multi-service environment (i.e., you cannot deliver triple-play

services to residential consumers over a point-to-point network, which is a large part of the developing Ethernet market). However, the point-to-point network will suffice to aggregate and switch point-to-point Ethernet services, which is currently the largest part of the business Ethernet market. (There is one caveat: if an enterprise business service requires multicast, PBT cannot be used.)

!

PBT effectively changes the metropolitan network to a statically provisioned network, which emulates the SONET/SDH networks many transport operators are most familiar with. And here lies the major benefit of PBT: from the operator's

2

#206653

©2007 IDC

 

point of view, PBT will "look and feel" very much like its SONET/SDH network. However, it is important to keep in mind that one can get exactly the same feel with MPLS using provisioned LSPs.

 

Is

PBT

Scalable?

Scalability is directly proportional to the configurability of the network. If the network configuration becomes unmanageable, it will not scale. In order for a network to increase in size and scale, it must be configurable:

 

! Development of virtual LANs (VLANs) was created to separate departmental traffic and access within the Enterprise infrastructure. However, each Ethernet switch or router was limited to 4,096 VLANs per box, which is more than enough for an enterprise but does not scale for carrier transport networks. Two standards have been developed to address the scalability issues: IEEE 802.1ad (Q-in-Q) and IEEE 802.1ah (MAC-in-MAC). Although Q-in-Q increases one aspect of VLAN scalability, it does not address the freedom to assign more than 4,096 unique customer VLANs. Therefore, MAC-in-MAC was standardized to boost the "theoretical" number of service instances into the millions.

! PBT, which incorporates the MAC-in-MAC standard, will now scale beyond 4,096 unique VLANs. However, it should be noted that in order to terminate a PBT tunnel on a switch, more header manipulation is required because you need to know both MAC headers. This, in itself, requires about one-third more processing and memory power to be added to the switch. As usual, the tradeoffs of adding more processing power can add to the cost of the overall product.

! Because PBT only supports point-to-point Ethernet today, it does not support other services required in most networks. Triple play will become one of the most important revenue-generating services in the next five years, so PBT will have to support multicast, IPTV, or triple-play services in a point-to-multipoint fashion, as well as legacy traffic coming from ATM and frame-relay links. This multi-service access function or feature set is currently not supported by PBT, which is extremely limiting.

Is

PBT

Reliable?

It is impossible to eliminate all network failures. Most providers are looking to maintain their level of availability on the transport network (99.999%) and provide prioritized application recovery from network outages to minimize any quality issues with voice, data, or video delivery to their customers.

 

PBT has just been submitted to the IEEE (which renamed it PBB-TE) and has significant obstacles to overcome before it becomes a standard. There are several mature protocols available today such as MPLS and MPLS/VPLS that have already been deployed for Ethernet transport in metropolitan networks:

!

PBT reliability is based on the ITU G.8031 standard for Ethernet protection switching, which is similar to SONET/SDH automatic protection switching (APS). This, in essence, only covers "path protection" by statically configuring the

©2007 IDC

 

#206653

3

 

protect path, but it does not cover node failures or ring and mesh topologies. Path protection similar to SONET/SDH (1+1) requires pre-allocation of the protect bandwidth, effectively doubling the network bandwidth needs. And, in most cases, it is the node or the link that actually fails, and MPLS fast-reroute has reliably proven to reroute under node and link failure where restoration times are faster and more efficient than path protection. MPLS supports path protection as well, but it's important to note that neither node nor link protection are supported by PBT.

!

Since MPLS supports node, link, path, and Pseudowire (PWE3) redundancy, it essentially is a "superset" of redundancy features, whereas PBT provides only one of those protection schemes. This is particularly important when paths span wide area networks.

Is

PBT

a

Low-Cost

Solution?

If PBT is deployed in a point-to-point Ethernet network with a low-cost Ethernet switch, it is less expensive than using any other equipment. The low cost comes from the switch hardware where components are now commodity, which dramatically lowers the cost, especially when you compare it to an ATM switch or a router.

!

Right now there are no off-the-shelf PBT components. Commodity silicon for Ethernet does not need these new features or OAM (802.1ag). Therefore, "PBT silicon" will most likely not enjoy the volume that commodity Ethernet does for quite a while.

!

In order to support processing MAC-in-MAC header encapsulation and decapsulation in PBB/PBT implementations, additional processing and memory must be added to the low-cost switch. IDC has asked multiple design engineers how much cost would be added by migrating a simple switch to incorporate these features. On average, it is 33% more cost to the product to support the additional scalability to generate and terminate two MAC headers.

!

If PBT was to be used for triple-play services, additional bandwidth is required to propagate the same service to multiple endpoints since multicast is not supported. This is an inefficient use of last-mile networks, which are possibly the most constrained portion of any provider's network. The bandwidth and capex cost to perform point-to-point video distribution in a residential network can easily scale into the hundreds of gigabits per second. And although multicast protocols have never been the easiest to implement, sending only one copy of a video channel through a large aggregation network reduces the cost significantly compared with the PBT point-to-point scenario.

!

Quality of service is supported in current routing protocols as well as PBT. And although "hard" QoS (H-QoS) is the flavor most requested, to deliver H-QoS, the recipe is relatively the same independent of the medium on which it is delivered. IP/MPLS networks react dynamically to network congestion to maintain quality. For connection-oriented protocols, the traffic-engineered protection path must be pre-allocated, and pre-allocation of spare network bandwidth may be costly.

4

#206653

©2007 IDC

Other

Issues

! To meet response-level rates and service activation expectations, providers rely on mature management systems to provision new services quickly and accurately. Performance monitoring in most networks provides information on packet delay and packet loss. PBT uses the ITU Y.1731 standard to detect frame delay and loss, which is sufficient for PBT links. However, if an MPLS-based service were run over the PBT links (i.e., an MPLS VPN service), MPLS performance monitoring would be required in addition to Y.1731. This is true for fault management as well.

! There is no production network today that has deployed PBT. The public announcements to date on PBT have come from British Telecom (BT), which will implement a point-to-point statically configured network to backhaul traffic to its MPLS network. BT is not replacing any portion of its MPLS network; the company is simply augmenting the metro aggregation network with PBT. No other service provider to date has publicly announced it will deploy PBT, although providers such as Verizon and Bell Canada have said they are evaluating the technology, their interest is focused on a small, simple Layer 2 network add-on. There are greenfield opportunities in many provider networks where new builds are taking place, and this is an opportunity to evaluate PBT or any other protocol for aggregation, backhaul, and cost efficiencies in the transport network.

! PBT is mainly focused on the metro and access markets for Ethernet backhaul, but Nortel does claim it can be used over the core infrastructure as well. With the cost of ROADMs dropping and increased use of MPLS above the optical layer, PBT is unlikely to extend beyond the metro. Transport products are beginning to deliver extension from Ethernet switches directly into WDM transport (Ethernet over WDM), eliminating the cost of transponders and further lowering the cost of Ethernet aggregation in the metropolitan area.

! Where the Ethernet and IP/MPLS demarcation points will be is not so much a Layer 2 versus Layer 3 question (or answer), but it will be apparent in the type or character of the provider offering those services. Providers offering only point-to- point Ethernet services that have small networks and prefer to minimize the routing protocols in their networks might be early adopters of PBT. Layer 3 MPLS VPNs (rfc 2547/4364) are also a business service, but they are not supported by PBT. Therefore, the provider must be willing to limit its service offering to point- to-point Ethernet today and in the future. Even if a provider is not offering multiple services today or just needs PBT for backhaul, it is unclear why they would introduce a new technology that is limited to only point-to-point traffic.

FUTURE OUTLOOK

! Carriers worldwide interested in deploying PBT or T-MPLS tend to fit a profile:

the network in which the protocol will be deployed is small, the operators want a connection-oriented approach and want it to be as simple as possible, and the network they will deploy will unlikely scale dramatically larger than what they have plans for. All of the carriers IDC spoke with that are interested in PBT fit this

©2007 IDC

#206653

5

type of provider model. Large tier 1 providers tend to already have Layer 3 expertise and are simply looking for ways to reduce cost in their network. If a PBT adopter wants to migrate to a multi-service network, the adopter will have to run "MPLS over PBT," which is not cost effective and eliminates all of the advantages of simplicity from the network.

! PBT has just entered the standards phase for review and will mostly emerge with additional or new features, whereas MPLS is based on IETF standards and is widely deployed by service providers in their core networks as well as many metropolitan networks. MPLS provides scalability, QoS, as well as node, link, and path protection. MPLS enables VPLS to provide multipoint Ethernet services and supports transparent point-to-point Pseudowires.

! The real issues in addressing Ethernet in the carrier environment come down to the control and management planes as well as the flat addressing scheme. Most of the other challenges (VLAN limitation, spanning tree limitations, limited QoS, limited protection) have been solved by MPLS labels, routing and traffic extensions, DiffServ, backup LSPs, and fast reroute. PBT does offer one of the best features providers are looking for, which is simplicity. In essence, PBT is making Layer 2 transport look like Layer 3 without the complexity, but, IDC believes it is at the expense of flexibility and multi-service capabilities.

! Multiple vendors are claiming they will support PBT: Nortel (the originator), Siemens, Fujitsu, Huawei, Extreme, Ciena, ADVA, Meriton, and Hammerhead. As Layer 2 access/metro networks become more cost effective with Ethernet, there will be the logical push to extend that network back in the metropolitan area and even further back toward the core. From the opposite direction, many carriers are mastering their MPLS core networks and look to migrate and converge their older networks onto a single IP network, extending the Layer 3 protocols further to the edge and providing additional intelligence for new service applications.

! Vendors such as Cisco, Juniper, and Alcatel-Lucent remain "technology agnostic" and continue to evaluate PBT, but rest assured, they will support whatever their customers request. These vendors are unlikely to produce yet another PBT-like offering (T-MPLS already exists!), but they are determined to solve the next-generation issues of managing the control plane and doing it in an elegant and simple fashion.

ESSENTIAL GUIDANCE

IDC believes the holy grail for most providers is a multi-service infrastructure with switch/routers that is less expensive than traditional routers and provides the flexibility of control plane centralization. This would enable Ethernet to be transported transparently and would make it simpler, more efficient, less complex, and more cost effective. The "nirvana" may be the absence of a control plane to suit transport-centric operators, but a more realistic approach may be to deliver these features with a more "elegant" control plane. This evokes a total system approach to the problem of end- to-end quality service delivery and not a patch to one area of the network.

6

#206653

©2007 IDC

TABLE 1

Comparison of PBT, MPLS, and T-MPLS

 
 

PBT and PBB-TE

MPLS

T-MPLS

Control plane

PBT is fully centralized and operated via network management system (NMS)

MPLS supports: distributed path computation with distributed signaling, centralized path computation

Provisioned

Connection oriented

Connection oriented

with distributed signaling, and centralized path

Forwarding is

pre-engineered

Forwarding is

computation with centralized signaling

pre-engineered

Connectionless or

connection oriented

Forwarding is determined by network

Standards

PBT-TE in process

MPLS mature

T-MPLS still in process

Deployment

Not deployed in a production network

In almost all tier 1 networks worldwide

Not deployed in a production network

Services

Point to point

Point to point

Point to point

Point to multipoint (in process)

Point to multipoint

Point to multipoint (in process)

Multipoint to multipoint

Multipoint to multipoint (in process)

ATM/FR

No multipoint to multipoint

Ethernet private line

Ethernet private line

TDM

Ethernet virtual private line

Layer 3 VPNs

Wholesale Ethernet

Layer 2 Pseudowires

backhaul

Multicast

VPLS

VoIP

IPTV, VoD, PVR

Circuit emulation, mobile RAN

Fixed mobile convergence

©2007 IDC

#206653

7

 

TABLE 1

 

Comparison of PBT, MPLS, and T-MPLS

 
 

PBT and PBB-TE

MPLS

T-MPLS

 

Simple

Provisioned, point and click

MPLS terminates three layers:

Provisioned like static Pseudowires

 

link, IP, and MPLS layers

Emulates

 

SONET/SDH/WDM

Control plane disabled; moved to NMS

provisioning

Control plane disabled; moved to NMS

Terminates Ethernet layer only

Terminates Ethernet layer only

 

Reliable

ITU G.8031 Ethernet protection switching, which is similar to SONET/SDH APS

MPLS fast reroute (50ms)

Does not support fast reroute

 

PWE3 redundancy

 

1+1 path protection only, no

1+1 path protection only, no node or ring failure

Node, link, and path protection

node or ring failure

 

Quality

Traffic engineered path must be pre-provisioned to ensure quality

MPLS networks react dynamically to network congestion to maintain quality

Traffic engineered path must be pre-provisioned to ensure quality

 

Pre-allocation of network bandwidth is costly

Pre-allocation of network bandwidth is costly

 

Cost

Ethernet switches should be low cost, however MAC-in- MAC header processing is a 30% cost impact

Multicast for video services reduces bandwidth demands on network bandwidth

Without support for multicast, video services will demand more bandwidth than MPLS

 

There are no off-the-shelf PBT components

Lack of multicast support increases bandwidth requirements of network

 

Source: IDC, 2007

8

#206653

©2007 IDC

LEARN MORE

 

Related

Research

! Worldwide Carrier Ethernet 2006ñ2010 Forecast (IDC #205209, January 2007)

 

! Worldwide Service Provider Router 2007ñ2011 Forecast (IDC #205268, January

2007)

! Worldwide Telecommunications Equipment 2007ñ2011 Forecast (IDC #206468, April 2007)

 

! IDC's Worldwide Telecommunications Infrastructure Taxonomy, 2007 (IDC #205995, March 2007)

Copyright

Notice

 

This IDC research document was published as part of an IDC continuous intelligence service, providing written research, analyst interactions, telebriefings, and conferences. Visit www.idc.com to learn more about IDC subscription and consulting services. To view a list of IDC offices worldwide, visit www.idc.com/offices. Please contact the IDC Hotline at 800.343.4952, ext. 7988 (or +1.508.988.7988) or sales@idc.com for information on applying the price of this document toward the purchase of an IDC service or for information on additional copies or Web rights.

 

Copyright 2007 IDC. Reproduction is forbidden unless authorized. All rights reserved.

Published Under Services: Telecommunications Equipment

 

©2007 IDC

#206653

9