Connection Oriented Ethernet - InfoVista

FierceTelecom.com 

3 

COE Still 

Looking to Thrive 

in a Carrier- 

Grade World 

ConneCtionoriented 

ethernet 

5 

One COE 

Standard 

Down, One 

to Go 

6 

Seeing the Forest 

through the Trees 

*Sponsored 

Content* 

7 

Level 3 

Makes its 

Point with 

Ethernet 

9 

Connection- 

Oriented Ethernet 

Strategies for Next- 

Gen Networks 

12 

Q&A: David 

Sinicrope, 

Broadband 

Forum 

14 

Q&A: Ralph 

Santitoro, 

Metro Ethernet 

Forum 

� Offering the deterministic qualities that traditional service providers love 

about SONET and the flexibility of Ethernet, Connection-Oriented Ethernet 

(COE) has emerged as a high performance version of point-to-point Carrier 

Ethernet (CE). However, COE is not just one standard, but a collection of 

implementations that leverage Metro Ethernet Forum (MEF), IEEE, IETF and 

ITU-T standards. 

Since no two service providers’ networks are the same, COE can be 

implemented using either Ethernet or MPLS (Multiprotocol Label Switching) 

technologies. 

There are two implementations to COE: Ethernet-centric COE and MPLScentric 

COE. Ethernet-Centric COE is supported by the IEEE’s 802.1Qay 

standard, which can leverage either PBB-TE (Provider Backbone Bridging- 

Transport Engineering) or ETS (Ethernet Tag Switching). 

Driven by the IETF and the Broadband Forum, the MPLS-centric approach 

to Ethernet transport focuses on two key technologies: T-MPLS (Transport- 

MPLS) and MPLS-TP (MPLS-Transport Profile). These approaches are set on 

providing interconnection of PE (Provider Edge) routers in a service provider’s 

inter-metro core network. 

Of course, the decision to leverage approach to COE depends on the specific 

issue you’re trying to solve. Those in the MPLS-centric camp argue that 

their approach is the most optimal because it allows a service provider to 

converge multiple protocols, including TDM, Frame Relay, ATM, Ethernet and 

IP onto the same network. MPLS-centric COE is optimized for multiservice 

(ATM, FR, TDM, Ethernet, and IP) transport. 

Alternatively, native Ethernet-centric COE, which leverages existing Carrier 

Ethernet standards, is best suited for optimized for Ethernet and IP service 

delivery and transport. 

COE has been touted by supporters as an ideal technology to deliver a host 

of services, including retail Ethernet Virtual Private Line (EVPL) services, DSL 

backhaul and wholesale wireless backhaul. 

While the jury may be out on where and how service providers will use 

MPLS and Ethernet-centric COE, in this eBook we discuss the options COE 

offers to the large service provider community. We also feature the perspectives 

of a wide range of players representing both implementations of COE, 

including vendors, industry forums (Broadband Forum and the MEF) and 

service providers. l 

By Sean Buckley /// Editor /// FierceTelecom 

�plaTinum SponSor 

�Gold SponSor 

1 April 2012 April 2012 

2


3 April 2012 

COE Still Looking to Thrive in a Carrier-Grade World 

BY DAN O’SHEA 

� Ethernet has been looking 

to shake the “best-effort” tag 

for more than a decade. Giving 

it your best effort is great for 

little leaguers, but carriers run 

in more competitive circles. In 

recent years, Metro Ethernet 

Forum (MEF) specifications, 

other new standards and new 

technology models from vendors 

have made much progress 

in helping Ethernet acquire a 

new tag: “Carrier-grade.” 

However, some in the 

industry think Ethernet still 

can do better, particularly in 

situations where it would be 

applied in transport networks 

on a connection-oriented, 

point-to-point basis, and that’s 

where Connection-Oriented 

Ethernet (COE) comes in. COE 

approaches represent the 

latest attempt to bring even 

more deterministic qualities 

to Ethernet, to make it more 

closely resemble the legacy 

technologies it is succeeding, 

like ATM and Frame Relay. 

“Carriers want the look and 

feel of TDM, but the lower 

cost and greater simplicity of 

the packet world, while still 

having all the determinism and 

low-latency qualities of TDM,” 

said Andy Walker, director of 

portfolio solutions at Ciena. 

Deployment of Ethernet 

technology in transport 

networks to support 

applications like mobile 

and wireline broadband 

backhaul have become more 

frequent, and while some of 

these deployments do meet the 

MEF’s carrier-grade benchmarks, 

some still don’t, Walker said. 

COE is not a brand new concept 

for addressing these deployments, 

as it was first developed more 

than a decade ago. It has yet to 

be widely deployed, but could 

become more central to network 

strategies as carrier progress on 

building out packet optical platforms 

in the core networks. 

COE comes in different flavors. 

Provider backbone bridgetraffic 

engineering (PBB-TE, also 

previously known as PBT) is the 

Ethernet-centric standard, while 

multiprotocol label switchingtransport 

profile (MPLS-TP) is 

the MPLS-centric approach. 

Vendors also may deliver their 

own variations, such as Fujitsu’s 

Ethernet Tag Switching, similar to 

the concept of VLAN tag switching. 

“COE is a broad term and makes 

Ethernet in general a more point- 

to-point friendly technology, but 

the implementations of it are more 

specific,” said Ralph Santitoro, 

director of carrier Ethernet market 

development at Fujitsu. “If a Tier 

1 carrier is expanding right now 

from their legacy network, it 

depends on whether the SONET 

people or the Ethernet people are 

in charge. The decision could be 

made on a case-by-case basis 

or application by application.” 

Santitoro argued that the 

Ethernet-centric approach is the 

more cost-effective one over 

the long term, and pointed out 

that Ethernet-centric COE is the 

model with the fully approved 

standard behind it, while the 

MPLS-derived version awaits 

the completion of operations, 

administration and maintenance 

standards. However, some in 

the market have observed that 

MPLS-TP also will be supported 

by many vendors, and Santitoro 

acknowledged that there will be 

different implementations. “With 

any technology, there are different 

ways of implementing to solve 

different problems and address 

different preferences,” he said. 

“It is good to have both 

approaches in the quiver,” said 

John Hawkins, senior advisor 

for product marketing at Ciena. 

He added that COE has started 

to more frequently enter into 

discussions Ciena is having with 

carriers, sometimes when the 

carrier generally talks about the 

need to bring more determinism 

to Ethernet, and other times 

when the carrier wants to satisfy 

a particular need, such as scaling 

a customer’s enterprise network 

by creating tunnels to keep their 

traffic together, or enabling 

backhaul for a mobile carrier. 

Mobile backhaul is probably the 

COE application that is getting 

the most attention right now, but 

Ciena’s Walker said that is likely 

to change when carriers start 

deploying COE links in greater 

numbers to address business 

broadband. “The carriers are under 

so much pressure right now to 

get backhaul right, and make sure 

the traffic gets from the cell site 

to the switching center in good 

shape,” he said. “But, the business 

market has 10 times the end 

points of the backhaul market.” 

How soon COE becomes more 

broadly adopted remains to be 

seen. For now, many carriers 

continue to use Carrier Ethernet. 

“There is not a lot of demand for 

COE today,” said Prayson Pate, 

chief technology officer at Overture 

Networks. “Some carriers are 

more focused on Carrier Ethernet, 

which they believe already has 

the quality of service attributes 

they’re looking for,” he said. 

“Some companies are positioning 

COE as a way to improve the 

ability to carry Carrier Ethernet, 

which makes it an alternative to 

MPLS, so it depends on whether 

your organization is focused on 

pushing MPLS further out.” 

Pate said Overture is not 

supporting COE now, but has not 

closed the book on it. “If our carrier 

customers want to use COE in the 

future, then that’s what we’ll build 

for them,” he said. 

Though wide-scale COE 

deployment may not be a reality 

just yet, it is clear that COE 

features are going to be important 

aspects of vendors’ next-generation 

packet optical platforms. As carriers 

get further away from their legacy 

technologies and more toward 

full packet optical migrations, 

COE naturally will become more 

common in networks. 

“People like Ethernet because 

it is multi-point, but its multi-point 

nature also makes it really hard to 

use in the WAN,” Santitoro said. 

“COE resolves that issue. The use 

of ATM and frame relay is declining 

in networks. If you built a new 

network today, you would not be 

using those technologies at all. You 

would use IP and Ethernet.” l 

April 2012 

4


5 April 2012 

One COE Standard Down, One to Go 


� Whether or not a technology 

is fully standardized is 

sometimes almost as much a 

gating factor for carrier adoption 

as cost is. As with their 

adoption of many other technologies, 

carriers looking at 

Connection-Oriented Ethernet 

for solving various problems 

in their networks will want to 

know they can rely on standard 

methods of implementing 

and managing Connection- 

Oriented Ethernet (COE). 

That begs the question: Is 

there a single COE standard 

that carriers can fall back on? 

Like everything with COE, 

the answer depends on what 

sort of organization you come 

from, which technology you are 

planning on using and how soon. 

Anyone from an Ethernet-centric 

organization who is looking for any 

Ethernet-centric approach to COE 

to deploy right now does have 

a fully developed and approved 

standard to guide them. “There is 

a common misunderstanding that 

there is no single standard for COE 

today, but there is,” said Ralph 

Santitoro, director of Carrier Ethernet 

market development at Fujitsu. 

Provider backbone bridgingtraffic 

engineering (PBB-TE), which 

is based on the original concept for 

provider backbone transport, an 

Ethernet-centric approach which 

was developed by BT and Nortel 

Networks, has been standard- 

ized by the IEEE in the 

form of IEEE 802.1qay. 

That standard, which was 

approved by the IEEE back 

in 2009, is actually an 

amendment to the 802.1ah 

Provider Backbone Bridging 

(PBB) standard, with the 

amended aspects addressing 

how carriers can control 

or eliminate various connectionless 

Ethernet features. 

The Ethernet-centric 

approach also relies on the 

IEEE 802.1ag connectivity 

fault management standard 

for some operations, 


recommendations, 

as well as IEEE 802.3ad 

for link aggregation. It also 

draws from ITU Operations 

Administration and 

Maintenance (OAM) specifications 

like ITU-T G.8031 

and ITU-T Y.1731, which 

governs performance quality. 

Meanwhile, the MPLS-TP 

(multi-protocol label switchingtransport 

profile) standard remains 

a work in progress, specifically 

with unfinished business around 

the OAM aspects of MPLS-TP. 

A T-MPLS standard was once 

being worked on by the ITU-T, 

and more than two years ago, 

the ITU-T and the IETF decided 

to merge their efforts, mainly so 

that the IETF could be sure that 

existing IP MPLS configurations 

in the market were given proper 

consideration in the new standard. 

“MPLS still needs OAM standardization 

to be worked out 

before it is a complete standard,” 

continued on page 7 

Seeing the Forest through the Trees 

BY CHriStOpHEr CullAN, prODuCt MArkEtiNg MANAgEr, iNfOViStA 

The Transparency of Carrier 

Networks and the Cloud 

� With service revenues estimated 

to be $30-$40 billion in 

2012, Carrier Ethernet is the 

fastest-growing carrier network 

technology domain. The mechanisms 

used to deliver these 

services are varied, presenting 

opportunities and challenges for 

each carrier in terms of successful 

delivery. 

As with most technology 

debates, there’s an amount of hard 

evidence indicating what’s better 

and best, and then there’s another, 

sometimes more powerful force: 

the market itself. Adoption is often 

driven by more than just the consideration 

of the “best technology” 

- additional factors include current 

investments and the time to 

deliver, among others. Regardless 

of technology debates, it’s important 

to take a step back to look at 

the “big picture” -the technology 

itself, including its maturity, deployment 

and management challenges. 

Today, many professionals in 

the carrier industry are discussing 

the impact of mobility on network 

traffic. However, another equal 

and possibly greater influencer on 

carrier networks is emerging: cloud 

computing. 

Increasing amounts of data and 

control traffic are being moved 

from globally and nationally distributed 

data centers and enterprise 

end users to cloud providers. This 

trend has not gone unnoticed by 

network or IT standard bodies, but 

there seems to be an awareness 

gap between the two. This gap 

was one of the primary reasons 

the Metro Ethernet Forum (MEF) 

recently published its white paper 

“Carrier Ethernet for the Delivery 

of Private Cloud Services.” 

This paper aims to open a dialogue 

between networking and 

IT (more specifically the carrier 

and cloud communities) to ensure 

that Connection-Oriented Ethernet 

continues to evolve to handle 

the major shift in telecommunications 

needs driven by the cloud. 

This first effort demonstrates how 

the current Carrier Ethernet constructs 

such as Ethernet Virtual 

Private Lines (EVPL) can be used 

to address different network use 

cases, such as having multiple, 

private lines to different cloud consumers 

connecting to a particular 

cloud providers’ data center multiplexed 

on one UNI. 

In essence, more local area network 

(LAN) traffic will be migrated 

to the wide area network (WAN) 

and the differences in cost and 

scale can drastically impact the 

quality of service if not properly 

addressed. The simplicity that 

cloud computing promises the 

enterprise causes added complexity 

for the providers of those 

services, making management all 

the more critical. 

Assuring that the application 

needs are mapped to the network, 

Sponsored Content 

and that the COE performs up to 

and above the requirements that 

cloud consumers like the enterprise 

demand, is necessary for the 

enterprise to achieve the benefits 

of cloud computing. Ensuring that 

enterprise customers are able to 

visualize the end-to-end usage and 

the performance of their Ethernet 

services, in the context of cloud 

computing, is critical. The ability to 

provide the verification (i.e. SLA) 

of application quality across the 

Ethernet service (with latency and 

delay measurements of a particular 

(CoS) and its mapped applications 

is important for the enterprise. 

Enhancing that verification with 

real-time visibility and performance 

intelligence enables the enterprise 

to better manage their service 

usage, requirements and the end 

user. This enhancement is the next 

milestone in maximizing the potential 

benefits that Carrier Ethernet 

can deliver. 

InfoVista understands that 

achieving this quality verification 

requires a solution that can gather 

information and provide the visibility 

of the Ethernet services internal 

to the communications service provider. 

A white paper, “Accelerating 

Revenue through Carrier Ethernet 

Service Differentiation” is available 

to learn more. l 

April 2012 

6


continued from page 5 Level 3 Makes its Point with Ethernet 

Santitoro said. “There are two 

different OAM standard drafts 

right now, one [G.8113.1] that 

is based on Y.1731, the ITU-T 

approach, and the other [G.8113.2] 

is the more MPLS-centric IETF 

approach. There are some incompatibilities 

between the two 

that need to be resolved.” 

Santitoro added that it is possible 

for MPLS-TP to include two 

different OAM models. “You could 

have both in the standard and say 

carriers may use one or the other, 

but that could lead to interoperability 

problems if carriers are 

interconnecting,” he said. “PBB- 

TE has the advantage of having 

a single OAM standard, and only 

one layer of OAM to manage.” 

The standards delay may appear 

to put MPLS-TP at a disadvantage 

in terms of market adoption, 

but COE has not been deployed 

widely enough yet for that to be 

the case. Though Overture Networks 

does not currently support 

COE, Prayson Pate, chief technology 

officer at Overture, said 

MPLS-TP still has the leverage 

of well-developed MPLS market 

behind it. “The IETF is an interest- 

ing group in that their standards 

usually reflect what people are 

actually using, rather than trying 

to define what they should 

use,” he said. “The IETF’s work 

on MPLS-TP reflects a market for 

MPLS that is already mature, and 

that the big carriers are already 

using this technology, and will 

continue to use it in the future.” 

The standards race may not be 

much of a race at all, which might 

be part of the reason why several 

COE vendors feel the need to 

support both standards in their 

future equipment platforms. 

Further supporting the likelihood 

for both standards to be 

viable is the tendency of the Metro 

Ethernet Forum, which created 

the specifications for supporting 

Carrier Ethernet services, to 

be agnostic when it comes to 

infrastructure technology architectures. 

“It was a great decision 

by the MEF to focus on service 

attributes rather than technology,” 

Santitoro said. “The MEF is technology 

agnostic, and they care 

more about Ethernet as a service.” 

He added that the MEF is working 

on its own specifications to 

support future cloud services. l 


� Throughout the telecom 

service provider sector, the 

need to draft Ethernet in 

service of point to point transport 

network applications is 

becoming increasingly apparent. 

The movement toward 

standardized Connection-Oriented 

Ethernet (COE) provides 

carriers with an architectural 

approach and different options 

for doing just that. 

COE is gradually making its 

way into transport networks, 

though deployment has yet 

to become widespread. Still, 

service providers are taking 

some of the notions inherent 

to COE—point-to-point 

connections, deterministic 

service quality, ease of management—and 

applying them 

to the transport services they 

are delivering to customers. 

These services include backhaul 

for mobile carriers, as 

well as backhaul for wireline 

broadband in business and 

residential markets. Another 

emerging application is data 

center interconnection for fast 

growing segment of cloud 

service providers. 

It turns out that COE technologies—the 

Ethernet-centric 

provider backbone bridging— 

traffic engineering (PBB-TE) 

standard, and the multi-protocol 

label switching-centric 

MPLS—transport profile 

(MPLS-TP) standard, which 

still has a couple operations, 


kinks to be worked out—are not 

the only options these carriers have 

for addressing their point to point 

application needs. 

“We are not currently using 

Connection-Oriented Ethernet in 

our network, but we do provide 

COE services to our customers by 

doing point-to-point private virtual 

circuits over MPLS,” said Ted 

Wagner, senior director 

of product management 

at Level 3 Communications. 

“We also can 

deliver the same sort of 

quality Ethernet experience 

over SONET. For 

now, we can meet the 

needs of ourselves and 

our customers for point 

to point without using 

Connection-Oriented 

Ethernet per se.” 

Wagner said that Level 

3 does not necessarily 

see a clear delineation 

between point-to-point 

Ethernet and other 

architectural methods for 

using Ethernet. When 

the company looks at 

using Ethernet to satisfy 

various applications, it is 

in terms of deploying it 

over MPLS, which eases 

the routing complexity 

between network end 

points. “We use Ethernet 

over MPLS both for 

the flexibility it gives us, 

and the mix of applica- 

tions it can support.” 

Mobile backhaul, business 

broadband and 

data center interconnection 

are among some of Level 3’s 

chief applications for point to point 

Ethernet, according to Wagner. 

Level 3’s comfort level with 

Ethernet in transport applications 

may not be so typical in the service 

provider market, since the company 

probably has much less of older 

technologies like ATM and Frame 

Relay deployed in its network than 

some of the other Tier 1 carriers. 

But, its use of Ethernet is evidence 

of how the large service providers 

have been getting more accustomed 

to working with Ethernet 

over the several years by putting 

their trust in Carrier Ethernet service 

guidelines from the Metro 

Ethernet Forum (MEF), as well as 

new Ethernet technology schemes 

from vendors. 

Wagner noted that some carriers, 

including their customers have 

been very quick to adopt Ethernet, 

but that other companies may still 

be moving more deliberately into 

the Ethernet era. “Some 

companies just haven’t 

seen a compelling reason 

to move that quickly,” 

he said. “It depends on 

what your needs are.” 

That position also 

pretty much explains 

where Level 3 is in thinking 

about using standard 

COE architectures like 

PBB-TE or MPLS-TP. 

Wagner said that while 

Level 3 has not deployed 

these technologies up to 

this point, the company 

does continue to track 

their evolution. 

“I don’t think we are 

going to use them anytime 

soon, but we are 

always looking for ways 

to improve our infrastructure 

and how we support 

our services,” Wagner 

said. “I’m not sure if that 

will happen via MPLS or 

something else. What 

we’re always looking for 

are new ways to scale 

and to lower costs.” l 

7 April 2012 

April 2012 

8



Strategies for Next-Gen Networks 

BY MiCHAEl kENNEDY 

� Connection-Oriented Ethernet 

(COE) is designed to 

provide packet-centric services 

that meet the needs of 

Next-Gen transport solutions 

while maintaining the attractive 

operational features of 

SONET/SDH designs. COE is 

used in the access and preaggregation 

portions of the 

network particularly where 

low cost, guaranteed performance 

and high security are 

required. Primary applications 

include mobile backhaul, 

Ethernet private line business 

services, wireline broadband 

backhaul, and for some 

peering links in wholesale 

networks. Operational simplicity 

is a high design priority 

because thousands or even 

tens of thousands of network 

links may be deployed. 

Requirements for highly 

skilled engineers and technicians 

should be minimized to 

achieve low cost at massive 

scale. 

COE is a fusion of connectionless 

Ethernet and 

SONET/SDH design features. 

Ethernet features include 

Layer 2 aggregation, statistical 

multiplexing, and flexible 

bandwidth granularity. These 

features support cost efficient 

aggregation of traffic flows 

while maintaining bandwidth 

guarantees for high priority 

traffic. Familiar concepts such 

as the Metro Ethernet Forum’s 

(MEF) Committed Information Rate 

(CIR) and best efforts service are 

maintained. This provides guaranteed 

quality of service (QoS) 

for high priority services just like 

SONET. However, it provides better 

economic performance than 

SONET by providing capacity for 

best efforts service during periods 

of slack capacity. Bandwidth 

granularity in one Mbps increments 

also provides more efficiency than 

SONET’s 50 Mbps bandwidth 

increments. As a variant of Ethernet, 

COE has the low cost of 

Ethernet products versus the high 

cost of SONET and TDM products. 

For example, the cost to equip and 

deploy a 100 Mbps Ethernet service 

is about the same as the cost 

to equip and deploy a 1.5 Mbps T1 

service. 

COE maintains some SONET-like 

features. QoS is deterministic and 

precise. Bandwidth is reserved. 

Service conforms to a five 9s 

availability requirement and the 

protection path is provided within 

50ms of a circuit failure. Security 

is at the highest level service runs 

over a point-to-point (or multipoint) 

Layer 1 link. 

COE is implemented through 

Ethernet-centric and MPLS-centric 

approaches. The Ethernet-centric 

approach is a high performance 

implementation of Carrier Ethernet. 

However, as its name implies 

it is connection-oriented. Ethernet 

bridging is disabled. No Spanning 

Tree Protocol or MAC address 

learning/flooding are employed. 

Ethernet paths are static and 

provisioned by a management 

system—this makes protection 

path performance deterministic 

(predictable). Label-based frame 

forwarding is used and designed 

to eliminate the scaling limits 

of original VLAN schemes. This 

approach makes COE more like 

SONET which dominates metro 

networks today. Most importantly 

this approach provides a smoother 

transition for SONET-trained operations 

personnel. 

The MPLS-centric approach to 

COE employs MPLS Transport 

Protocol (MPLS-TP). This approach 

brings MPLS to access networks. 

In-band operation administration and 

maintenance (OAM) is introduced 

into MPLS OAM. This replicates the 

transport-centric operations familiar 

to TDM operators and provides a 

simple mechanism for validating 

that the data path is operational in 

the network. MPLS-TP supports 

restoration mechanisms based upon 

a static backup path. This is like 

the Ethernet-centric approach and 

differs from the dynamic control 

plane approach used by MPLS in 

core networks. MPLS-TP employs 

pseudowires for multiservice transport. 

This is particularly important 

in mobile backhaul applications 

where 2G, 3G and 4G technologies 

share many cell sites thus, TDM, 

ATM and Ethernet services must 

be supported in the same transport 

link. This is accomplished by establishing 

three OAM layers; one for 

Ethernet, ATM or TDM; a second for 

the pseudowire; and finally a MPLS 

Label Switched Path. 

Advocates for the Ethernet and 

MPLS centric approaches of course 

are quick to point out what they 

see as short comings of the other 

approach. My view is that the 

perceived short comings are primarily 

dependent on the approach 

to the market taken by the systems 

vendor and by the service 

provider’s business and operational 

requirements. For example, 

Ethernet-centric advocates point to 

MPLS-TP’s three OAM layers as an 

example of operational complexity 

and as being less than optimal for 

Ethernet service delivery and transport. 

MPLS-centric advocates point 

to the Ethernet-centric approach’s 

lack of multiservice capabilities and 

incompatibility with MPLS. Furthermore, 

Ethernet-centric advocates 

observe that many transport organizations 

lack MPLS expertise. 

Also, the lack of IP functionality 

in Ethernet-centric COE is seen 

as a strength by Ethernet-centric 

advocates and a weakness by 

MPLS-centric advocates. 

These differences can be 

resolved by evaluating each 

approach in the context of actual 

deployments. First, an avowed 

rationale of the MPLS-centric camp 

is to extend MPLS across the 

network end-to-end. MPLS-TP is 

needed to accomplish this because 

some aspects of MPLS are incompatible 

with access network 

requirements. For example, the 

large number of access nodes compared 

to the core network makes 

routing algorithm used in the core 

computationally infeasible in access 

networks. Service providers whose 

goal it is to extend MPLS end-toend 

in their networks will not see 

the need to train the transport 

organization as a barrier to adoption 

of the MPLS-centric approach. 

As a second example, many service 

providers are deploying packet 

optical transport (POT) systems in 

their networks to cost effectively 

handle TDM and Ethernet traffic. 

The Ethernet-centric approach’s lack 

of a multiservice capability is not a 

weakness for POT deployments. 

COE, despite the approach, is 

essential to achieving the low cost, 

high performance, and security 

required by leading edge services 

including mobile and broadband 

backhaul, and business Ethernet 

services. l 

Michael Kennedy is a regular FierceTelecom 

columnist and is Principal Analyst at ACG 

Research—www.acgresearch.net. He can be 

reached at mkennedy@acgresearch.net. 


10


Mobile 

backhaul 

solutions FierceTelecom: To start, can 

you talk about the activity the 

Broadband Forum has around 

MPLS-based implementations 

for Ethernet? 

david Sinicrope: What we have 

going on is our work with MPLS 

The complete approach 

Fujitsu mobile backhaul solutions use a comprehensive 

methodology that meets the challenges of deploying a 

state-of-the-art multi-RAN backhaul network. We have 

the resources, expertise and technology you need to 

achieve success in cell-tower backhaul. You provide the 

fiber; we’ll do the rest. 

Work with Fujitsu—deliver the bandwidth wireless 

operators need. 

Fujitsu Network Communications • 2801 Telecom Parkway, Richardson, TX 75082 Tel: 800.777.FAST (3278) • us.fujitsu.com/telecom 

© Copyright 2012 Fujitsu Network Communications Inc. FUJITSU (and design)® and “shaping tomorrow with you” are trademarks of Fujitsu Limited in the United States and other countries. All Rights Reserved. 

Q&A: David Sinicrope, Secretary of the Board and chairman 

of the IP MPLS Working group at the Broadband Forum 

and Carrier Ethernet (CE), which 

we call working text (WT-224), 

which basically is a standardized 

reference architecture on how to 

build and how to support Metro 

Ethernet Forum (MEF) Carrier 

Ethernet services using MPLS. 

What we’re finding through our 

membership is there’s a lot of 

interest in having a set of nodal 

requirements and a reference 

architecture that vendors and 

carriers alike can use to come 

to a common denominator set 

of functions supporting Metro 

Ethernet Forum (MEF) Carrier 

Ethernet services using MPLS. 

The primary focus of this is to 

increase interoperability. When 

you have a situation where 

everybody interprets the MEF 

Carrier Ethernet standards in 

their own way and the MPLS 

� Offering the ability to converge multiple traffic types, including 

TDM, ATM, and IP onto one network, MPLS has a strong role to play in 

delivering Ethernet services. The Broadband Forum, which expanded 

its focus on MPLS technologies when it merged with the former MPLS 

Forum, is an advocate of this approach. FierceTelecom caught up with 

David Sinicrope, Secretary of the Board and Chairman of the IP MPLS 

Working group at the Broadband Forum, to talk about new initiatives 

driving the use of MPLS in delivering Ethernet services to end users and 

as a wholesale mechanism for wireless backhaul. 

functions in their own way, you 

end up with a set of products 

that don’t support the same set 

of Operational Administration 

and Maintenance (OAM) tools. 

The carriers end up putting 

out RFPs (Request for Proposals) 

with this product over here 

supporting this set of services 

and another group supporting 

something else, but they don’t 

interoperate. What we’re trying 

to do is put down a common set 

of functions for providing Carrier 

Ethernet services with MPLS 

that the carriers can use in their 

RFPs and the vendors can use 

in their roadmaps and product 

development so that everybody 

will come to the table with a 

common set of functions that 

will allow them to interoperate. 

FT: So getting vendors and 

standards groups on the same 

page and having a common 

set of requirements is main 

challenge? 

dS: It’s both. To get everybody on 

the same page is to get them to 

come in with a common a subset 

of requirements or a subset set of 

common functions. 

FT: Along with using MPLS, 

there’s a lot of talk about 

using native Ethernet via 

COE (Connection-Oriented 

Ethernet). Are there advantages 

to the MPLS approach or 

is it complementary to the 

Ethernet-centric approach and 

others out there? 

dS: What I found with the COE 

stuff is that it’s primarily based 

on Provider Backbone Bridging 

(PBB), Provider Backbone Bridging 

Traffic Engineering (PBB-TE), 

and Queue in Queue, which are 

all very valid technologies that 

work very well. I won’t presume 

to say which one is best because 

it depends on what deployment 

scenario you’re starting with. 

What we’re doing in the forum, 

or at least in the working group 

I chair, is we’ve chosen to stick 

with MPLS. MPLS does have 

some advantages. If you look at 



12


continued from page 12 

where the industry has been going 

over the past five to seven years, 

it’s all about network convergence, 

and MPLS is the only technology 

that allows you to converge 

multiple protocols, including TDM, 

Frame Relay, ATM, Ethernet and IP, 

onto the same network. If you look 

at PBB and if you look at Queue in 

Queue and Ethernet in general, you 

can implement Ethernet COE using 

Ethernet pseudowires with MPLS. 

But where I use the native technology, 

I can use the MEF 8 standard 

to emulate TDM over Ethernet, I 

can run Ethernet services itself, 

and run IP over Ethernet. On the 

MPLS side, I can do all of that plus 

I can get ATM emulation, Frame 

Relay emulation, and if I need it, 

High level Data Link Control (HDLC) 

emulation. 

If you look at something like the 

mobile backhaul topic today, they 

need to support multiple protocols: 

TDM for the 2G services, 

ATM for 3G services, and once 

you go beyond 3G you’re starting 

to look at Ethernet and IP. If I am 

using MPLS, I can get all of that 

off a single network and I have a 

lot more flexibility to transport IP. 

When I look at mobile backhaul for 

LTE, some of the data that we have 

seen in the past is, there’s no such 

thing as a pure LTE site. The sites 

are always going to be mixed. I can 

get LTE over the Ethernet or I can 

get it over IP and I have that flexibility 

to do one or the other or both. 

I have seen some cases where 

they take L2VPN, which is your 

Connection-Oriented Ethernet over 

pseudowires in a VPLS scenario, 

and I have seen folks ask for that 

to access a Layer 3 VPN. If I have 

a cell site that has 2G, 3G, and 4G, 

I have to support TDM, ATM, and 

Ethernet and IP. Well, there’s only 

“If you look at where the industry has been going over the 

past five to seven years, it’s all about network convergence, 

and MPLS is the only technology that allows you to 

converge multiple protocols... onto the same network.” 

one technology that I know of that 

does this and that’s MPLS. You can 

debate whether or not it’s MPLS, 

MPLS-TP, or some combination of 

the two as well. 

FT: One of the major initiatives 

you are driving on the MPLS 

end at the forum is the TR-221 

specification, which defines 

technical specifications for MPLS 

in mobile backhaul networks. 

What value does MPLS add in 

the wireless backhaul network? 

dS: TR-221 is pretty much the 

embodiment of everything I just 

mentioned. It provides the nodal 

requirements for MPLS gear to 

support the 2G TDM, 3G ATM and 

3.5G and 4G IP using either Ethernet 

or L3VPN. It gives the base 

set of MPLS requirements for all 

of that. It also addresses resiliency 

and OAM. 

FT: Can you talk about how the 

service providers use of MPLS for 

Ethernet? 

dS: The service provider community 

actually has a good deal of 

interest in what we’re doing there 

on several different levels. When it 

comes to specifically to MPLS for 

Carrier Ethernet networks they’re 

looking at that to get a common 

subset of functions to deliver Ethernet 

services. They are using those 

Ethernet services for mobile backhaul 

and broadband access, so the 

same document that we’re creating 

for Carrier Ethernet services is being 

picked up by another working group 

in the Broadband Forum to support 

the multiservice broadband architecture. 

If you look at DSL in the old 

days it was based on ATM, and now 

it’s based on Ethernet. How are 

you going to provide Ethernet? It’s 

getting to the point where the DSL 

link or the GPON link is the access 

extension to the Metro Ethernet 

network. I am getting my Ethernet 

services from a DSL link, a GPON 

link or I am getting my Ethernet 

services over point-to-point fiber or 

what we think of as point-to-point 

copper. Everything is converging 

down to a common network. Being 

able to reuse that network for different 

purposes, including how you 

use that network to deliver triple 

play services, but also use the same 

network for mobile backhaul. 

FT: So, what’s next on the horizon 

at the forum as it relates to 

MPLS/Ethernet-based wireless 

backhaul? 

dS: If you look at the work from 

the Next Generation Mobile Networks 

(NGNM) industry group, 

they are starting to look at taking 

macrocells and dividing them 

down into smaller cells to make 

better use of the wireless spectrum. 

When you do that you don’t 

have a 250-foot tower, but instead 

have a small device hanging from 

a ceiling in a shopping mall. What 

does that architecture look like and 

how does that change the mobile 

backhaul perspective? 

That’s actually something 

we’re looking at now. We put out 

TR-221, which is dealing with the 

macrocell base stations, but now 

we are working on an addendum 

to that specification to do two 

things. One, there were a number 

of things in TR-221 that weren’t 

quite mature for us to reference, 

but those things have cleared and 

now we’ll put out the corresponding 

reference. The second thing 

is we’re doing is looking at this 

NGNM initiative around small cells 

and looking at how that changes 

mobile backhaul. Right now, we’re 

looking at it and seeing it as a 

necessary evolution to what’s happening 

in mobile backhaul. You’ll 

see things like the access used to 

be P2P fiber or a microwave link 

running Ethernet or TDM, but now 

it could be a VDSL2 link. You have 

to be able to put that thing on a 

light pole, so you won’t be deploying 

a large router next to it but 

rather will run a DSL link to it. I will 

get my Ethernet backhaul any way 

I can by whatever access possible 

that’s cost effective. That’s probably 

true of any Ethernet service. 

Whether I’m serving a house or 

serving an enterprise, I am going 

to use whatever access technology 

I can that’s most cost effective. l 

Q&A: Ralph Santitoro, founding 

member and Director of the Metro 

Ethernet Forum (MEF) 

� In considering a path to 


(COE), Ralph Santitoro, 

founding member and director 

of the Metro Ethernet Forum 

(MEF) is quick to point out that 

COE is not just based on one 

standard, but rather a collection 

of standards. Santitoro said that 

much like ATM, “there’s no one 

standard for COE, but rather 

a collection of standards.” 

This collection of standards 

represents both an Ethernetcentric 

and MPLS-centric approach to COE. Sean Buckley, 

Senior Editor of FierceTelecom, sat down with Santitoro to 

discuss the merits of both approaches and their role in the 

next-gen telecom network. 

FierceTelecom: To start, can 

you give an overview of 

what’s driving the need for 

the Ethernet-centric approach 

to COE? 

ralph Santitoro: If you look at 

what the most popular Ethernet 

services are right now, they 

are all point-to-point services. 

Those are used for lots of different 

things, including wireless 

backhaul, data center interconnect, 

and site-to-site VPNs. You 

also have infrastructure applications 

like broadband backhaul 

for telcos’ DSLAMs (digital 

subscriber line access multiplexers), 

PON (passive optical 

network) devices, and CMTS 

(cable modem termination 

systems) for cable operators’ 

DOCSIS systems. The reason 

why I wanted to paint that picture 

is that point-to-point rules 

in WAN (Wide Area Networking) 

and also for infrastructure 

services like backhaul. COE was 

created to have a packet friendly 

version of that service. 

FT: What is the state of the 

COE market and what’s 

driving service providers to 

it? 

rS: Even though COE has been 

around for about 10 years, it’s 

finally starting to see a lot of 



14


continued from page 14 

uptake for the following reason: 

A lot of carriers are finally capping 

their SONET (synchronous 

optical networking) infrastructure 

and want to move to a full packetbased 

technology. A lot of those 

organizations had big SONET 

networks and these are the ones 

that are driving the COE market. 

They are delivering lots of Ethernet 

over SONET (EoSONET) with guaranteed 

bandwidth delivery. They 

realized they needed something 

that has to be that good to replace 

SONET because the customers 

won’t accept anything less than 

that, but they are being forced to 

move over because they need a 

much more scalable, packet-centric 

type of service. That’s what is 

making COE take off. A number 

of service providers I met with 

recently said they are still going 

through that exact same transition 

where they are saying ‘we’re still 

going to offer SONET services to 

those customers that want it, but 

the reality is we want to do Ethernet 

over fiber service and COE is 

the way to go.’ COE allows them 

to have a more cost-efficient, scalable 

infrastructure versus SONET. 

With SONET, service providers 

have to sell bandwidth in 50 Mbps 

increments in order to recoup their 

investment because every SONET 

channel is 50 Mbps. Customers 

don’t necessarily want to buy 

bandwidth that way, but that’s the 

way service providers had to offer 

it because that was their transport 

infrastructure. 

FT: How is the service provider 

community responding to COE? 

Is it mainly being deployed 

by domestic or international 

carriers or both? 

rS: I am seeing a lot of interest in 

both the U.S. and Canada. I know 

a large carrier that does broadband 

backhaul for their infrastructure 

and COE made a lot of sense for 

them. Even though their last mile 

is copper, their infrastructure is 

completely COE-based because 

it allows them to offer high performance 

Ethernet over Copper 

service. Normally, you had buy 

fiber to get a high performance 

Ethernet service, but with COE 

they can offer the same type of 

performance over copper. 

FT: Earlier, you mentioned 

wireless backhaul. How are 

wholesale operators that 

provide services to wireless 

operators using COE? 

rS: It is probably one of the biggest 

areas of growth. The reason 

for that is the wireless operations 

had been very stringent on backhaul 

even though the data traffic 

from the cell phones is best-effort. 

Normally, if the wireless operator 

has some T1s to a 3G base 

station they will backhaul those 

over SONET. Even if they have 

a SONET infrastructure they can 

run COE over SONET to get better 

efficiency on their backhaul 

network. Today, the vast majority 

of backhaul is EoSONET, and 

the reason why is the wireless 

operators don’t trust the wireline 

providers doing the backhaul. They 

said, ‘Look, I want you to give 

me EoSONET because I know it 

works.’ Some service providers 

will run COE over SONET and that 

allows them to get better bandwidth 

utilization over their SONET 

backhaul network. These carriers 

will do it this way because they 

had some T1s from the 3G base 

stations. Rather than using SONET 

in 50 Mbps chunks, they can 

now take multiple Ethernet ports 

coming from different base stations, 

including 3G and some 4G 

LTE, and run it over that SONET 

infrastructure and get much better 

bandwidth efficiency. 

When it comes to COE for LTE 

data backhaul, the carriers want 

to have a backhaul infrastructure 

that prepares them for the future. 

Today, LTE is all about best effort 

data and their voice is still 3G 

voice. They don’t provide voice in 

LTE. You can envision in a couple 

of years they will move over to 

VoIP and will not be doing circuit 

switched voice anymore like they 

do today for the voice part of LTE. 

When they get to that, the VoIP 

service will require some stringent 

backhaul. By putting in COE today 

for their best effort data backhaul, 

they’re preparing for the future 

when they introduce VoIP. It’s like 

planning for the future, but not 

really paying any additional amount 

because COE is just as cost competitive 

with other Ethernet-based 

backhaul technologies. 

FT: In the COE domain, there 

are a number of approaches, 

including the Ethernet-centric 

and the MPLS-centric views. 

What benefits or advantages 

does the Ethernet approach 

have over MPLS, or does it 

depend on the service provider? 

rS: You can implement COE 

with either Ethernet or MPLS. I 

think there are reasons for both. 

If you’re an equipment manufacturer 

that builds routers, then 

more likely than not you would 

chose an MPLS-centric approach 

because that’s what your product 

development organization is used 

to. If you’re coming from a pure 

Ethernet side as a developer of 

Ethernet switches or Packet Opti- 

cal Network Platforms (PONP) like 

Ciena, Fujitsu or Cyan, you would 

probably do an Ethernet-centric 

approach. It makes more sense 

there, not only from how they sell 

products, but also because the 

customers they sell products to 

are the transport organizations 

that know SONET. MPLS is like a 

foreign language to them. 

COE was actually designed with 

SONET in mind. A lot of the standards, 

like 50 millisecond protection 

switching and fault management, 

came from the SONET world and 

even uses a lot of SONET terminology. 

It would be very familiar 

for someone who knows SONET. 

There’s an ITU-T standard called 

G.8031 that defines linear path 

protection, which is called the 

same thing in SONET with a working 

path and a protection path. If 

the working path fails you switch 

over to the protect path within 50 

milliseconds. It’s very friendly for 

SONET/SDH transport people who 

are used to those terms. Most 

SONET people are familiar with 

Ethernet because they’re using 

Ethernet to connect their SONET 

devices. That’s why the Ethernetcentric 

approach is good for that 

type of organization because they 

are switching their SONET/SDH 

networks over to a packet network. 

They are asking, ‘Should I 

make the leap to MPLS or should 

I make a leap to Ethernet? Well, 

all of my operational staff knows, 

and OSS systems know Ethernet, 

so let me go with Ethernet. Why 

add an extra layer?’ That’s been 

the big driver because MPLS adds 

another layer of technology that 

they are not familiar with using. l 


16

Connection Oriented Ethernet - InfoVista

Create successful ePaper yourself

Delete template?

Save as template?