Connection Oriented Ethernet - InfoVista
Connection Oriented Ethernet - InfoVista
Connection Oriented Ethernet - InfoVista
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
FierceTelecom.com<br />
3<br />
COE Still<br />
Looking to Thrive<br />
in a Carrier-<br />
Grade World<br />
ConneCtionoriented<br />
ethernet<br />
5<br />
One COE<br />
Standard<br />
Down, One<br />
to Go<br />
6<br />
Seeing the Forest<br />
through the Trees<br />
*Sponsored<br />
Content*<br />
7<br />
Level 3<br />
Makes its<br />
Point with<br />
<strong>Ethernet</strong><br />
9<br />
<strong>Connection</strong>-<br />
<strong>Oriented</strong> <strong>Ethernet</strong><br />
Strategies for Next-<br />
Gen Networks<br />
12<br />
Q&A: David<br />
Sinicrope,<br />
Broadband<br />
Forum<br />
14<br />
Q&A: Ralph<br />
Santitoro,<br />
Metro <strong>Ethernet</strong><br />
Forum<br />
� Offering the deterministic qualities that traditional service providers love<br />
about SONET and the flexibility of <strong>Ethernet</strong>, <strong>Connection</strong>-<strong>Oriented</strong> <strong>Ethernet</strong><br />
(COE) has emerged as a high performance version of point-to-point Carrier<br />
<strong>Ethernet</strong> (CE). However, COE is not just one standard, but a collection of<br />
implementations that leverage Metro <strong>Ethernet</strong> Forum (MEF), IEEE, IETF and<br />
ITU-T standards.<br />
Since no two service providers’ networks are the same, COE can be<br />
implemented using either <strong>Ethernet</strong> or MPLS (Multiprotocol Label Switching)<br />
technologies.<br />
There are two implementations to COE: <strong>Ethernet</strong>-centric COE and MPLScentric<br />
COE. <strong>Ethernet</strong>-Centric COE is supported by the IEEE’s 802.1Qay<br />
standard, which can leverage either PBB-TE (Provider Backbone Bridging-<br />
Transport Engineering) or ETS (<strong>Ethernet</strong> Tag Switching).<br />
Driven by the IETF and the Broadband Forum, the MPLS-centric approach<br />
to <strong>Ethernet</strong> transport focuses on two key technologies: T-MPLS (Transport-<br />
MPLS) and MPLS-TP (MPLS-Transport Profile). These approaches are set on<br />
providing interconnection of PE (Provider Edge) routers in a service provider’s<br />
inter-metro core network.<br />
Of course, the decision to leverage approach to COE depends on the specific<br />
issue you’re trying to solve. Those in the MPLS-centric camp argue that<br />
their approach is the most optimal because it allows a service provider to<br />
converge multiple protocols, including TDM, Frame Relay, ATM, <strong>Ethernet</strong> and<br />
IP onto the same network. MPLS-centric COE is optimized for multiservice<br />
(ATM, FR, TDM, <strong>Ethernet</strong>, and IP) transport.<br />
Alternatively, native <strong>Ethernet</strong>-centric COE, which leverages existing Carrier<br />
<strong>Ethernet</strong> standards, is best suited for optimized for <strong>Ethernet</strong> and IP service<br />
delivery and transport.<br />
COE has been touted by supporters as an ideal technology to deliver a host<br />
of services, including retail <strong>Ethernet</strong> Virtual Private Line (EVPL) services, DSL<br />
backhaul and wholesale wireless backhaul.<br />
While the jury may be out on where and how service providers will use<br />
MPLS and <strong>Ethernet</strong>-centric COE, in this eBook we discuss the options COE<br />
offers to the large service provider community. We also feature the perspectives<br />
of a wide range of players representing both implementations of COE,<br />
including vendors, industry forums (Broadband Forum and the MEF) and<br />
service providers. l<br />
By Sean Buckley /// Editor /// FierceTelecom<br />
�plaTinum SponSor<br />
�Gold SponSor<br />
1 April 2012 April 2012<br />
2
FierceTelecom.com<br />
3 April 2012<br />
COE Still Looking to Thrive in a Carrier-Grade World<br />
BY DAN O’SHEA<br />
� <strong>Ethernet</strong> has been looking<br />
to shake the “best-effort” tag<br />
for more than a decade. Giving<br />
it your best effort is great for<br />
little leaguers, but carriers run<br />
in more competitive circles. In<br />
recent years, Metro <strong>Ethernet</strong><br />
Forum (MEF) specifications,<br />
other new standards and new<br />
technology models from vendors<br />
have made much progress<br />
in helping <strong>Ethernet</strong> acquire a<br />
new tag: “Carrier-grade.”<br />
However, some in the<br />
industry think <strong>Ethernet</strong> still<br />
can do better, particularly in<br />
situations where it would be<br />
applied in transport networks<br />
on a connection-oriented,<br />
point-to-point basis, and that’s<br />
where <strong>Connection</strong>-<strong>Oriented</strong><br />
<strong>Ethernet</strong> (COE) comes in. COE<br />
approaches represent the<br />
latest attempt to bring even<br />
more deterministic qualities<br />
to <strong>Ethernet</strong>, to make it more<br />
closely resemble the legacy<br />
technologies it is succeeding,<br />
like ATM and Frame Relay.<br />
“Carriers want the look and<br />
feel of TDM, but the lower<br />
cost and greater simplicity of<br />
the packet world, while still<br />
having all the determinism and<br />
low-latency qualities of TDM,”<br />
said Andy Walker, director of<br />
portfolio solutions at Ciena.<br />
Deployment of <strong>Ethernet</strong><br />
technology in transport<br />
networks to support<br />
applications like mobile<br />
and wireline broadband<br />
backhaul have become more<br />
frequent, and while some of<br />
these deployments do meet the<br />
MEF’s carrier-grade benchmarks,<br />
some still don’t, Walker said.<br />
COE is not a brand new concept<br />
for addressing these deployments,<br />
as it was first developed more<br />
than a decade ago. It has yet to<br />
be widely deployed, but could<br />
become more central to network<br />
strategies as carrier progress on<br />
building out packet optical platforms<br />
in the core networks.<br />
COE comes in different flavors.<br />
Provider backbone bridgetraffic<br />
engineering (PBB-TE, also<br />
previously known as PBT) is the<br />
<strong>Ethernet</strong>-centric standard, while<br />
multiprotocol label switchingtransport<br />
profile (MPLS-TP) is<br />
the MPLS-centric approach.<br />
Vendors also may deliver their<br />
own variations, such as Fujitsu’s<br />
<strong>Ethernet</strong> Tag Switching, similar to<br />
the concept of VLAN tag switching.<br />
“COE is a broad term and makes<br />
<strong>Ethernet</strong> in general a more point-<br />
to-point friendly technology, but<br />
the implementations of it are more<br />
specific,” said Ralph Santitoro,<br />
director of carrier <strong>Ethernet</strong> market<br />
development at Fujitsu. “If a Tier<br />
1 carrier is expanding right now<br />
from their legacy network, it<br />
depends on whether the SONET<br />
people or the <strong>Ethernet</strong> people are<br />
in charge. The decision could be<br />
made on a case-by-case basis<br />
or application by application.”<br />
Santitoro argued that the<br />
<strong>Ethernet</strong>-centric approach is the<br />
more cost-effective one over<br />
the long term, and pointed out<br />
that <strong>Ethernet</strong>-centric COE is the<br />
model with the fully approved<br />
standard behind it, while the<br />
MPLS-derived version awaits<br />
the completion of operations,<br />
administration and maintenance<br />
standards. However, some in<br />
the market have observed that<br />
MPLS-TP also will be supported<br />
by many vendors, and Santitoro<br />
acknowledged that there will be<br />
different implementations. “With<br />
any technology, there are different<br />
ways of implementing to solve<br />
different problems and address<br />
different preferences,” he said.<br />
“It is good to have both<br />
approaches in the quiver,” said<br />
John Hawkins, senior advisor<br />
for product marketing at Ciena.<br />
He added that COE has started<br />
to more frequently enter into<br />
discussions Ciena is having with<br />
carriers, sometimes when the<br />
carrier generally talks about the<br />
need to bring more determinism<br />
to <strong>Ethernet</strong>, and other times<br />
when the carrier wants to satisfy<br />
a particular need, such as scaling<br />
a customer’s enterprise network<br />
by creating tunnels to keep their<br />
traffic together, or enabling<br />
backhaul for a mobile carrier.<br />
Mobile backhaul is probably the<br />
COE application that is getting<br />
the most attention right now, but<br />
Ciena’s Walker said that is likely<br />
to change when carriers start<br />
deploying COE links in greater<br />
numbers to address business<br />
broadband. “The carriers are under<br />
so much pressure right now to<br />
get backhaul right, and make sure<br />
the traffic gets from the cell site<br />
to the switching center in good<br />
shape,” he said. “But, the business<br />
market has 10 times the end<br />
points of the backhaul market.”<br />
How soon COE becomes more<br />
broadly adopted remains to be<br />
seen. For now, many carriers<br />
continue to use Carrier <strong>Ethernet</strong>.<br />
“There is not a lot of demand for<br />
COE today,” said Prayson Pate,<br />
chief technology officer at Overture<br />
Networks. “Some carriers are<br />
more focused on Carrier <strong>Ethernet</strong>,<br />
which they believe already has<br />
the quality of service attributes<br />
they’re looking for,” he said.<br />
“Some companies are positioning<br />
COE as a way to improve the<br />
ability to carry Carrier <strong>Ethernet</strong>,<br />
which makes it an alternative to<br />
MPLS, so it depends on whether<br />
your organization is focused on<br />
pushing MPLS further out.”<br />
Pate said Overture is not<br />
supporting COE now, but has not<br />
closed the book on it. “If our carrier<br />
customers want to use COE in the<br />
future, then that’s what we’ll build<br />
for them,” he said.<br />
Though wide-scale COE<br />
deployment may not be a reality<br />
just yet, it is clear that COE<br />
features are going to be important<br />
aspects of vendors’ next-generation<br />
packet optical platforms. As carriers<br />
get further away from their legacy<br />
technologies and more toward<br />
full packet optical migrations,<br />
COE naturally will become more<br />
common in networks.<br />
“People like <strong>Ethernet</strong> because<br />
it is multi-point, but its multi-point<br />
nature also makes it really hard to<br />
use in the WAN,” Santitoro said.<br />
“COE resolves that issue. The use<br />
of ATM and frame relay is declining<br />
in networks. If you built a new<br />
network today, you would not be<br />
using those technologies at all. You<br />
would use IP and <strong>Ethernet</strong>.” l<br />
April 2012<br />
4
FierceTelecom.com<br />
5 April 2012<br />
One COE Standard Down, One to Go<br />
BY DAN O’SHEA<br />
� Whether or not a technology<br />
is fully standardized is<br />
sometimes almost as much a<br />
gating factor for carrier adoption<br />
as cost is. As with their<br />
adoption of many other technologies,<br />
carriers looking at<br />
<strong>Connection</strong>-<strong>Oriented</strong> <strong>Ethernet</strong><br />
for solving various problems<br />
in their networks will want to<br />
know they can rely on standard<br />
methods of implementing<br />
and managing <strong>Connection</strong>-<br />
<strong>Oriented</strong> <strong>Ethernet</strong> (COE).<br />
That begs the question: Is<br />
there a single COE standard<br />
that carriers can fall back on?<br />
Like everything with COE,<br />
the answer depends on what<br />
sort of organization you come<br />
from, which technology you are<br />
planning on using and how soon.<br />
Anyone from an <strong>Ethernet</strong>-centric<br />
organization who is looking for any<br />
<strong>Ethernet</strong>-centric approach to COE<br />
to deploy right now does have<br />
a fully developed and approved<br />
standard to guide them. “There is<br />
a common misunderstanding that<br />
there is no single standard for COE<br />
today, but there is,” said Ralph<br />
Santitoro, director of Carrier <strong>Ethernet</strong><br />
market development at Fujitsu.<br />
Provider backbone bridgingtraffic<br />
engineering (PBB-TE), which<br />
is based on the original concept for<br />
provider backbone transport, an<br />
<strong>Ethernet</strong>-centric approach which<br />
was developed by BT and Nortel<br />
Networks, has been standard-<br />
ized by the IEEE in the<br />
form of IEEE 802.1qay.<br />
That standard, which was<br />
approved by the IEEE back<br />
in 2009, is actually an<br />
amendment to the 802.1ah<br />
Provider Backbone Bridging<br />
(PBB) standard, with the<br />
amended aspects addressing<br />
how carriers can control<br />
or eliminate various connectionless<br />
<strong>Ethernet</strong> features.<br />
The <strong>Ethernet</strong>-centric<br />
approach also relies on the<br />
IEEE 802.1ag connectivity<br />
fault management standard<br />
for some operations,<br />
administration and maintenance<br />
recommendations,<br />
as well as IEEE 802.3ad<br />
for link aggregation. It also<br />
draws from ITU Operations<br />
Administration and<br />
Maintenance (OAM) specifications<br />
like ITU-T G.8031<br />
and ITU-T Y.1731, which<br />
governs performance quality.<br />
Meanwhile, the MPLS-TP<br />
(multi-protocol label switchingtransport<br />
profile) standard remains<br />
a work in progress, specifically<br />
with unfinished business around<br />
the OAM aspects of MPLS-TP.<br />
A T-MPLS standard was once<br />
being worked on by the ITU-T,<br />
and more than two years ago,<br />
the ITU-T and the IETF decided<br />
to merge their efforts, mainly so<br />
that the IETF could be sure that<br />
existing IP MPLS configurations<br />
in the market were given proper<br />
consideration in the new standard.<br />
“MPLS still needs OAM standardization<br />
to be worked out<br />
before it is a complete standard,”<br />
continued on page 7<br />
Seeing the Forest through the Trees<br />
BY CHriStOpHEr CullAN, prODuCt MArkEtiNg MANAgEr, iNfOViStA<br />
The Transparency of Carrier<br />
Networks and the Cloud<br />
� With service revenues estimated<br />
to be $30-$40 billion in<br />
2012, Carrier <strong>Ethernet</strong> is the<br />
fastest-growing carrier network<br />
technology domain. The mechanisms<br />
used to deliver these<br />
services are varied, presenting<br />
opportunities and challenges for<br />
each carrier in terms of successful<br />
delivery.<br />
As with most technology<br />
debates, there’s an amount of hard<br />
evidence indicating what’s better<br />
and best, and then there’s another,<br />
sometimes more powerful force:<br />
the market itself. Adoption is often<br />
driven by more than just the consideration<br />
of the “best technology”<br />
- additional factors include current<br />
investments and the time to<br />
deliver, among others. Regardless<br />
of technology debates, it’s important<br />
to take a step back to look at<br />
the “big picture” -the technology<br />
itself, including its maturity, deployment<br />
and management challenges.<br />
Today, many professionals in<br />
the carrier industry are discussing<br />
the impact of mobility on network<br />
traffic. However, another equal<br />
and possibly greater influencer on<br />
carrier networks is emerging: cloud<br />
computing.<br />
Increasing amounts of data and<br />
control traffic are being moved<br />
from globally and nationally distributed<br />
data centers and enterprise<br />
end users to cloud providers. This<br />
trend has not gone unnoticed by<br />
network or IT standard bodies, but<br />
there seems to be an awareness<br />
gap between the two. This gap<br />
was one of the primary reasons<br />
the Metro <strong>Ethernet</strong> Forum (MEF)<br />
recently published its white paper<br />
“Carrier <strong>Ethernet</strong> for the Delivery<br />
of Private Cloud Services.”<br />
This paper aims to open a dialogue<br />
between networking and<br />
IT (more specifically the carrier<br />
and cloud communities) to ensure<br />
that <strong>Connection</strong>-<strong>Oriented</strong> <strong>Ethernet</strong><br />
continues to evolve to handle<br />
the major shift in telecommunications<br />
needs driven by the cloud.<br />
This first effort demonstrates how<br />
the current Carrier <strong>Ethernet</strong> constructs<br />
such as <strong>Ethernet</strong> Virtual<br />
Private Lines (EVPL) can be used<br />
to address different network use<br />
cases, such as having multiple,<br />
private lines to different cloud consumers<br />
connecting to a particular<br />
cloud providers’ data center multiplexed<br />
on one UNI.<br />
In essence, more local area network<br />
(LAN) traffic will be migrated<br />
to the wide area network (WAN)<br />
and the differences in cost and<br />
scale can drastically impact the<br />
quality of service if not properly<br />
addressed. The simplicity that<br />
cloud computing promises the<br />
enterprise causes added complexity<br />
for the providers of those<br />
services, making management all<br />
the more critical.<br />
Assuring that the application<br />
needs are mapped to the network,<br />
Sponsored Content<br />
and that the COE performs up to<br />
and above the requirements that<br />
cloud consumers like the enterprise<br />
demand, is necessary for the<br />
enterprise to achieve the benefits<br />
of cloud computing. Ensuring that<br />
enterprise customers are able to<br />
visualize the end-to-end usage and<br />
the performance of their <strong>Ethernet</strong><br />
services, in the context of cloud<br />
computing, is critical. The ability to<br />
provide the verification (i.e. SLA)<br />
of application quality across the<br />
<strong>Ethernet</strong> service (with latency and<br />
delay measurements of a particular<br />
(CoS) and its mapped applications<br />
is important for the enterprise.<br />
Enhancing that verification with<br />
real-time visibility and performance<br />
intelligence enables the enterprise<br />
to better manage their service<br />
usage, requirements and the end<br />
user. This enhancement is the next<br />
milestone in maximizing the potential<br />
benefits that Carrier <strong>Ethernet</strong><br />
can deliver.<br />
<strong>InfoVista</strong> understands that<br />
achieving this quality verification<br />
requires a solution that can gather<br />
information and provide the visibility<br />
of the <strong>Ethernet</strong> services internal<br />
to the communications service provider.<br />
A white paper, “Accelerating<br />
Revenue through Carrier <strong>Ethernet</strong><br />
Service Differentiation” is available<br />
to learn more. l<br />
April 2012<br />
6
FierceTelecom.com<br />
continued from page 5 Level 3 Makes its Point with <strong>Ethernet</strong><br />
Santitoro said. “There are two<br />
different OAM standard drafts<br />
right now, one [G.8113.1] that<br />
is based on Y.1731, the ITU-T<br />
approach, and the other [G.8113.2]<br />
is the more MPLS-centric IETF<br />
approach. There are some incompatibilities<br />
between the two<br />
that need to be resolved.”<br />
Santitoro added that it is possible<br />
for MPLS-TP to include two<br />
different OAM models. “You could<br />
have both in the standard and say<br />
carriers may use one or the other,<br />
but that could lead to interoperability<br />
problems if carriers are<br />
interconnecting,” he said. “PBB-<br />
TE has the advantage of having<br />
a single OAM standard, and only<br />
one layer of OAM to manage.”<br />
The standards delay may appear<br />
to put MPLS-TP at a disadvantage<br />
in terms of market adoption,<br />
but COE has not been deployed<br />
widely enough yet for that to be<br />
the case. Though Overture Networks<br />
does not currently support<br />
COE, Prayson Pate, chief technology<br />
officer at Overture, said<br />
MPLS-TP still has the leverage<br />
of well-developed MPLS market<br />
behind it. “The IETF is an interest-<br />
ing group in that their standards<br />
usually reflect what people are<br />
actually using, rather than trying<br />
to define what they should<br />
use,” he said. “The IETF’s work<br />
on MPLS-TP reflects a market for<br />
MPLS that is already mature, and<br />
that the big carriers are already<br />
using this technology, and will<br />
continue to use it in the future.”<br />
The standards race may not be<br />
much of a race at all, which might<br />
be part of the reason why several<br />
COE vendors feel the need to<br />
support both standards in their<br />
future equipment platforms.<br />
Further supporting the likelihood<br />
for both standards to be<br />
viable is the tendency of the Metro<br />
<strong>Ethernet</strong> Forum, which created<br />
the specifications for supporting<br />
Carrier <strong>Ethernet</strong> services, to<br />
be agnostic when it comes to<br />
infrastructure technology architectures.<br />
“It was a great decision<br />
by the MEF to focus on service<br />
attributes rather than technology,”<br />
Santitoro said. “The MEF is technology<br />
agnostic, and they care<br />
more about <strong>Ethernet</strong> as a service.”<br />
He added that the MEF is working<br />
on its own specifications to<br />
support future cloud services. l<br />
BY DAN O’SHEA<br />
� Throughout the telecom<br />
service provider sector, the<br />
need to draft <strong>Ethernet</strong> in<br />
service of point to point transport<br />
network applications is<br />
becoming increasingly apparent.<br />
The movement toward<br />
standardized <strong>Connection</strong>-<strong>Oriented</strong><br />
<strong>Ethernet</strong> (COE) provides<br />
carriers with an architectural<br />
approach and different options<br />
for doing just that.<br />
COE is gradually making its<br />
way into transport networks,<br />
though deployment has yet<br />
to become widespread. Still,<br />
service providers are taking<br />
some of the notions inherent<br />
to COE—point-to-point<br />
connections, deterministic<br />
service quality, ease of management—and<br />
applying them<br />
to the transport services they<br />
are delivering to customers.<br />
These services include backhaul<br />
for mobile carriers, as<br />
well as backhaul for wireline<br />
broadband in business and<br />
residential markets. Another<br />
emerging application is data<br />
center interconnection for fast<br />
growing segment of cloud<br />
service providers.<br />
It turns out that COE technologies—the<br />
<strong>Ethernet</strong>-centric<br />
provider backbone bridging—<br />
traffic engineering (PBB-TE)<br />
standard, and the multi-protocol<br />
label switching-centric<br />
MPLS—transport profile<br />
(MPLS-TP) standard, which<br />
still has a couple operations,<br />
administration and maintenance<br />
kinks to be worked out—are not<br />
the only options these carriers have<br />
for addressing their point to point<br />
application needs.<br />
“We are not currently using<br />
<strong>Connection</strong>-<strong>Oriented</strong> <strong>Ethernet</strong> in<br />
our network, but we do provide<br />
COE services to our customers by<br />
doing point-to-point private virtual<br />
circuits over MPLS,” said Ted<br />
Wagner, senior director<br />
of product management<br />
at Level 3 Communications.<br />
“We also can<br />
deliver the same sort of<br />
quality <strong>Ethernet</strong> experience<br />
over SONET. For<br />
now, we can meet the<br />
needs of ourselves and<br />
our customers for point<br />
to point without using<br />
<strong>Connection</strong>-<strong>Oriented</strong><br />
<strong>Ethernet</strong> per se.”<br />
Wagner said that Level<br />
3 does not necessarily<br />
see a clear delineation<br />
between point-to-point<br />
<strong>Ethernet</strong> and other<br />
architectural methods for<br />
using <strong>Ethernet</strong>. When<br />
the company looks at<br />
using <strong>Ethernet</strong> to satisfy<br />
various applications, it is<br />
in terms of deploying it<br />
over MPLS, which eases<br />
the routing complexity<br />
between network end<br />
points. “We use <strong>Ethernet</strong><br />
over MPLS both for<br />
the flexibility it gives us,<br />
and the mix of applica-<br />
tions it can support.”<br />
Mobile backhaul, business<br />
broadband and<br />
data center interconnection<br />
are among some of Level 3’s<br />
chief applications for point to point<br />
<strong>Ethernet</strong>, according to Wagner.<br />
Level 3’s comfort level with<br />
<strong>Ethernet</strong> in transport applications<br />
may not be so typical in the service<br />
provider market, since the company<br />
probably has much less of older<br />
technologies like ATM and Frame<br />
Relay deployed in its network than<br />
some of the other Tier 1 carriers.<br />
But, its use of <strong>Ethernet</strong> is evidence<br />
of how the large service providers<br />
have been getting more accustomed<br />
to working with <strong>Ethernet</strong><br />
over the several years by putting<br />
their trust in Carrier <strong>Ethernet</strong> service<br />
guidelines from the Metro<br />
<strong>Ethernet</strong> Forum (MEF), as well as<br />
new <strong>Ethernet</strong> technology schemes<br />
from vendors.<br />
Wagner noted that some carriers,<br />
including their customers have<br />
been very quick to adopt <strong>Ethernet</strong>,<br />
but that other companies may still<br />
be moving more deliberately into<br />
the <strong>Ethernet</strong> era. “Some<br />
companies just haven’t<br />
seen a compelling reason<br />
to move that quickly,”<br />
he said. “It depends on<br />
what your needs are.”<br />
That position also<br />
pretty much explains<br />
where Level 3 is in thinking<br />
about using standard<br />
COE architectures like<br />
PBB-TE or MPLS-TP.<br />
Wagner said that while<br />
Level 3 has not deployed<br />
these technologies up to<br />
this point, the company<br />
does continue to track<br />
their evolution.<br />
“I don’t think we are<br />
going to use them anytime<br />
soon, but we are<br />
always looking for ways<br />
to improve our infrastructure<br />
and how we support<br />
our services,” Wagner<br />
said. “I’m not sure if that<br />
will happen via MPLS or<br />
something else. What<br />
we’re always looking for<br />
are new ways to scale<br />
and to lower costs.” l<br />
7 April 2012<br />
April 2012<br />
8
FierceTelecom.com<br />
<strong>Connection</strong>-<strong>Oriented</strong> <strong>Ethernet</strong><br />
Strategies for Next-Gen Networks<br />
BY MiCHAEl kENNEDY<br />
� <strong>Connection</strong>-<strong>Oriented</strong> <strong>Ethernet</strong><br />
(COE) is designed to<br />
provide packet-centric services<br />
that meet the needs of<br />
Next-Gen transport solutions<br />
while maintaining the attractive<br />
operational features of<br />
SONET/SDH designs. COE is<br />
used in the access and preaggregation<br />
portions of the<br />
network particularly where<br />
low cost, guaranteed performance<br />
and high security are<br />
required. Primary applications<br />
include mobile backhaul,<br />
<strong>Ethernet</strong> private line business<br />
services, wireline broadband<br />
backhaul, and for some<br />
peering links in wholesale<br />
networks. Operational simplicity<br />
is a high design priority<br />
because thousands or even<br />
tens of thousands of network<br />
links may be deployed.<br />
Requirements for highly<br />
skilled engineers and technicians<br />
should be minimized to<br />
achieve low cost at massive<br />
scale.<br />
COE is a fusion of connectionless<br />
<strong>Ethernet</strong> and<br />
SONET/SDH design features.<br />
<strong>Ethernet</strong> features include<br />
Layer 2 aggregation, statistical<br />
multiplexing, and flexible<br />
bandwidth granularity. These<br />
features support cost efficient<br />
aggregation of traffic flows<br />
while maintaining bandwidth<br />
guarantees for high priority<br />
traffic. Familiar concepts such<br />
as the Metro <strong>Ethernet</strong> Forum’s<br />
(MEF) Committed Information Rate<br />
(CIR) and best efforts service are<br />
maintained. This provides guaranteed<br />
quality of service (QoS)<br />
for high priority services just like<br />
SONET. However, it provides better<br />
economic performance than<br />
SONET by providing capacity for<br />
best efforts service during periods<br />
of slack capacity. Bandwidth<br />
granularity in one Mbps increments<br />
also provides more efficiency than<br />
SONET’s 50 Mbps bandwidth<br />
increments. As a variant of <strong>Ethernet</strong>,<br />
COE has the low cost of<br />
<strong>Ethernet</strong> products versus the high<br />
cost of SONET and TDM products.<br />
For example, the cost to equip and<br />
deploy a 100 Mbps <strong>Ethernet</strong> service<br />
is about the same as the cost<br />
to equip and deploy a 1.5 Mbps T1<br />
service.<br />
COE maintains some SONET-like<br />
features. QoS is deterministic and<br />
precise. Bandwidth is reserved.<br />
Service conforms to a five 9s<br />
availability requirement and the<br />
protection path is provided within<br />
50ms of a circuit failure. Security<br />
is at the highest level service runs<br />
over a point-to-point (or multipoint)<br />
Layer 1 link.<br />
COE is implemented through<br />
<strong>Ethernet</strong>-centric and MPLS-centric<br />
approaches. The <strong>Ethernet</strong>-centric<br />
approach is a high performance<br />
implementation of Carrier <strong>Ethernet</strong>.<br />
However, as its name implies<br />
it is connection-oriented. <strong>Ethernet</strong><br />
bridging is disabled. No Spanning<br />
Tree Protocol or MAC address<br />
learning/flooding are employed.<br />
<strong>Ethernet</strong> paths are static and<br />
provisioned by a management<br />
system—this makes protection<br />
path performance deterministic<br />
(predictable). Label-based frame<br />
forwarding is used and designed<br />
to eliminate the scaling limits<br />
of original VLAN schemes. This<br />
approach makes COE more like<br />
SONET which dominates metro<br />
networks today. Most importantly<br />
this approach provides a smoother<br />
transition for SONET-trained operations<br />
personnel.<br />
The MPLS-centric approach to<br />
COE employs MPLS Transport<br />
Protocol (MPLS-TP). This approach<br />
brings MPLS to access networks.<br />
In-band operation administration and<br />
maintenance (OAM) is introduced<br />
into MPLS OAM. This replicates the<br />
transport-centric operations familiar<br />
to TDM operators and provides a<br />
simple mechanism for validating<br />
that the data path is operational in<br />
the network. MPLS-TP supports<br />
restoration mechanisms based upon<br />
a static backup path. This is like<br />
the <strong>Ethernet</strong>-centric approach and<br />
differs from the dynamic control<br />
plane approach used by MPLS in<br />
core networks. MPLS-TP employs<br />
pseudowires for multiservice transport.<br />
This is particularly important<br />
in mobile backhaul applications<br />
where 2G, 3G and 4G technologies<br />
share many cell sites thus, TDM,<br />
ATM and <strong>Ethernet</strong> services must<br />
be supported in the same transport<br />
link. This is accomplished by establishing<br />
three OAM layers; one for<br />
<strong>Ethernet</strong>, ATM or TDM; a second for<br />
the pseudowire; and finally a MPLS<br />
Label Switched Path.<br />
Advocates for the <strong>Ethernet</strong> and<br />
MPLS centric approaches of course<br />
are quick to point out what they<br />
see as short comings of the other<br />
approach. My view is that the<br />
perceived short comings are primarily<br />
dependent on the approach<br />
to the market taken by the systems<br />
vendor and by the service<br />
provider’s business and operational<br />
requirements. For example,<br />
<strong>Ethernet</strong>-centric advocates point to<br />
MPLS-TP’s three OAM layers as an<br />
example of operational complexity<br />
and as being less than optimal for<br />
<strong>Ethernet</strong> service delivery and transport.<br />
MPLS-centric advocates point<br />
to the <strong>Ethernet</strong>-centric approach’s<br />
lack of multiservice capabilities and<br />
incompatibility with MPLS. Furthermore,<br />
<strong>Ethernet</strong>-centric advocates<br />
observe that many transport organizations<br />
lack MPLS expertise.<br />
Also, the lack of IP functionality<br />
in <strong>Ethernet</strong>-centric COE is seen<br />
as a strength by <strong>Ethernet</strong>-centric<br />
advocates and a weakness by<br />
MPLS-centric advocates.<br />
These differences can be<br />
resolved by evaluating each<br />
approach in the context of actual<br />
deployments. First, an avowed<br />
rationale of the MPLS-centric camp<br />
is to extend MPLS across the<br />
network end-to-end. MPLS-TP is<br />
needed to accomplish this because<br />
some aspects of MPLS are incompatible<br />
with access network<br />
requirements. For example, the<br />
large number of access nodes compared<br />
to the core network makes<br />
routing algorithm used in the core<br />
computationally infeasible in access<br />
networks. Service providers whose<br />
goal it is to extend MPLS end-toend<br />
in their networks will not see<br />
the need to train the transport<br />
organization as a barrier to adoption<br />
of the MPLS-centric approach.<br />
As a second example, many service<br />
providers are deploying packet<br />
optical transport (POT) systems in<br />
their networks to cost effectively<br />
handle TDM and <strong>Ethernet</strong> traffic.<br />
The <strong>Ethernet</strong>-centric approach’s lack<br />
of a multiservice capability is not a<br />
weakness for POT deployments.<br />
COE, despite the approach, is<br />
essential to achieving the low cost,<br />
high performance, and security<br />
required by leading edge services<br />
including mobile and broadband<br />
backhaul, and business <strong>Ethernet</strong><br />
services. l<br />
Michael Kennedy is a regular FierceTelecom<br />
columnist and is Principal Analyst at ACG<br />
Research—www.acgresearch.net. He can be<br />
reached at mkennedy@acgresearch.net.<br />
9 April 2012 April 2012<br />
10
FierceTelecom.com<br />
Mobile<br />
backhaul<br />
solutions FierceTelecom: To start, can<br />
you talk about the activity the<br />
Broadband Forum has around<br />
MPLS-based implementations<br />
for <strong>Ethernet</strong>?<br />
david Sinicrope: What we have<br />
going on is our work with MPLS<br />
The complete approach<br />
Fujitsu mobile backhaul solutions use a comprehensive<br />
methodology that meets the challenges of deploying a<br />
state-of-the-art multi-RAN backhaul network. We have<br />
the resources, expertise and technology you need to<br />
achieve success in cell-tower backhaul. You provide the<br />
fiber; we’ll do the rest.<br />
Work with Fujitsu—deliver the bandwidth wireless<br />
operators need.<br />
Fujitsu Network Communications • 2801 Telecom Parkway, Richardson, TX 75082 Tel: 800.777.FAST (3278) • us.fujitsu.com/telecom<br />
© 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.<br />
Q&A: David Sinicrope, Secretary of the Board and chairman<br />
of the IP MPLS Working group at the Broadband Forum<br />
and Carrier <strong>Ethernet</strong> (CE), which<br />
we call working text (WT-224),<br />
which basically is a standardized<br />
reference architecture on how to<br />
build and how to support Metro<br />
<strong>Ethernet</strong> Forum (MEF) Carrier<br />
<strong>Ethernet</strong> services using MPLS.<br />
What we’re finding through our<br />
membership is there’s a lot of<br />
interest in having a set of nodal<br />
requirements and a reference<br />
architecture that vendors and<br />
carriers alike can use to come<br />
to a common denominator set<br />
of functions supporting Metro<br />
<strong>Ethernet</strong> Forum (MEF) Carrier<br />
<strong>Ethernet</strong> services using MPLS.<br />
The primary focus of this is to<br />
increase interoperability. When<br />
you have a situation where<br />
everybody interprets the MEF<br />
Carrier <strong>Ethernet</strong> standards in<br />
their own way and the MPLS<br />
� Offering the ability to converge multiple traffic types, including<br />
TDM, ATM, and IP onto one network, MPLS has a strong role to play in<br />
delivering <strong>Ethernet</strong> services. The Broadband Forum, which expanded<br />
its focus on MPLS technologies when it merged with the former MPLS<br />
Forum, is an advocate of this approach. FierceTelecom caught up with<br />
David Sinicrope, Secretary of the Board and Chairman of the IP MPLS<br />
Working group at the Broadband Forum, to talk about new initiatives<br />
driving the use of MPLS in delivering <strong>Ethernet</strong> services to end users and<br />
as a wholesale mechanism for wireless backhaul.<br />
functions in their own way, you<br />
end up with a set of products<br />
that don’t support the same set<br />
of Operational Administration<br />
and Maintenance (OAM) tools.<br />
The carriers end up putting<br />
out RFPs (Request for Proposals)<br />
with this product over here<br />
supporting this set of services<br />
and another group supporting<br />
something else, but they don’t<br />
interoperate. What we’re trying<br />
to do is put down a common set<br />
of functions for providing Carrier<br />
<strong>Ethernet</strong> services with MPLS<br />
that the carriers can use in their<br />
RFPs and the vendors can use<br />
in their roadmaps and product<br />
development so that everybody<br />
will come to the table with a<br />
common set of functions that<br />
will allow them to interoperate.<br />
FT: So getting vendors and<br />
standards groups on the same<br />
page and having a common<br />
set of requirements is main<br />
challenge?<br />
dS: It’s both. To get everybody on<br />
the same page is to get them to<br />
come in with a common a subset<br />
of requirements or a subset set of<br />
common functions.<br />
FT: Along with using MPLS,<br />
there’s a lot of talk about<br />
using native <strong>Ethernet</strong> via<br />
COE (<strong>Connection</strong>-<strong>Oriented</strong><br />
<strong>Ethernet</strong>). Are there advantages<br />
to the MPLS approach or<br />
is it complementary to the<br />
<strong>Ethernet</strong>-centric approach and<br />
others out there?<br />
dS: What I found with the COE<br />
stuff is that it’s primarily based<br />
on Provider Backbone Bridging<br />
(PBB), Provider Backbone Bridging<br />
Traffic Engineering (PBB-TE),<br />
and Queue in Queue, which are<br />
all very valid technologies that<br />
work very well. I won’t presume<br />
to say which one is best because<br />
it depends on what deployment<br />
scenario you’re starting with.<br />
What we’re doing in the forum,<br />
or at least in the working group<br />
I chair, is we’ve chosen to stick<br />
with MPLS. MPLS does have<br />
some advantages. If you look at<br />
continued on page 13<br />
11 April 2012 April 2012<br />
12
FierceTelecom.com<br />
continued from page 12<br />
where the industry has been going<br />
over the past five to seven years,<br />
it’s all about network convergence,<br />
and MPLS is the only technology<br />
that allows you to converge<br />
multiple protocols, including TDM,<br />
Frame Relay, ATM, <strong>Ethernet</strong> and IP,<br />
onto the same network. If you look<br />
at PBB and if you look at Queue in<br />
Queue and <strong>Ethernet</strong> in general, you<br />
can implement <strong>Ethernet</strong> COE using<br />
<strong>Ethernet</strong> pseudowires with MPLS.<br />
But where I use the native technology,<br />
I can use the MEF 8 standard<br />
to emulate TDM over <strong>Ethernet</strong>, I<br />
can run <strong>Ethernet</strong> services itself,<br />
and run IP over <strong>Ethernet</strong>. On the<br />
MPLS side, I can do all of that plus<br />
I can get ATM emulation, Frame<br />
Relay emulation, and if I need it,<br />
High level Data Link Control (HDLC)<br />
emulation.<br />
If you look at something like the<br />
mobile backhaul topic today, they<br />
need to support multiple protocols:<br />
TDM for the 2G services,<br />
ATM for 3G services, and once<br />
you go beyond 3G you’re starting<br />
to look at <strong>Ethernet</strong> and IP. If I am<br />
using MPLS, I can get all of that<br />
off a single network and I have a<br />
lot more flexibility to transport IP.<br />
When I look at mobile backhaul for<br />
LTE, some of the data that we have<br />
seen in the past is, there’s no such<br />
thing as a pure LTE site. The sites<br />
are always going to be mixed. I can<br />
get LTE over the <strong>Ethernet</strong> or I can<br />
get it over IP and I have that flexibility<br />
to do one or the other or both.<br />
I have seen some cases where<br />
they take L2VPN, which is your<br />
<strong>Connection</strong>-<strong>Oriented</strong> <strong>Ethernet</strong> over<br />
pseudowires in a VPLS scenario,<br />
and I have seen folks ask for that<br />
to access a Layer 3 VPN. If I have<br />
a cell site that has 2G, 3G, and 4G,<br />
I have to support TDM, ATM, and<br />
<strong>Ethernet</strong> and IP. Well, there’s only<br />
“If you look at where the industry has been going over the<br />
past five to seven years, it’s all about network convergence,<br />
and MPLS is the only technology that allows you to<br />
converge multiple protocols... onto the same network.”<br />
one technology that I know of that<br />
does this and that’s MPLS. You can<br />
debate whether or not it’s MPLS,<br />
MPLS-TP, or some combination of<br />
the two as well.<br />
FT: One of the major initiatives<br />
you are driving on the MPLS<br />
end at the forum is the TR-221<br />
specification, which defines<br />
technical specifications for MPLS<br />
in mobile backhaul networks.<br />
What value does MPLS add in<br />
the wireless backhaul network?<br />
dS: TR-221 is pretty much the<br />
embodiment of everything I just<br />
mentioned. It provides the nodal<br />
requirements for MPLS gear to<br />
support the 2G TDM, 3G ATM and<br />
3.5G and 4G IP using either <strong>Ethernet</strong><br />
or L3VPN. It gives the base<br />
set of MPLS requirements for all<br />
of that. It also addresses resiliency<br />
and OAM.<br />
FT: Can you talk about how the<br />
service providers use of MPLS for<br />
<strong>Ethernet</strong>?<br />
dS: The service provider community<br />
actually has a good deal of<br />
interest in what we’re doing there<br />
on several different levels. When it<br />
comes to specifically to MPLS for<br />
Carrier <strong>Ethernet</strong> networks they’re<br />
looking at that to get a common<br />
subset of functions to deliver <strong>Ethernet</strong><br />
services. They are using those<br />
<strong>Ethernet</strong> services for mobile backhaul<br />
and broadband access, so the<br />
same document that we’re creating<br />
for Carrier <strong>Ethernet</strong> services is being<br />
picked up by another working group<br />
in the Broadband Forum to support<br />
the multiservice broadband architecture.<br />
If you look at DSL in the old<br />
days it was based on ATM, and now<br />
it’s based on <strong>Ethernet</strong>. How are<br />
you going to provide <strong>Ethernet</strong>? It’s<br />
getting to the point where the DSL<br />
link or the GPON link is the access<br />
extension to the Metro <strong>Ethernet</strong><br />
network. I am getting my <strong>Ethernet</strong><br />
services from a DSL link, a GPON<br />
link or I am getting my <strong>Ethernet</strong><br />
services over point-to-point fiber or<br />
what we think of as point-to-point<br />
copper. Everything is converging<br />
down to a common network. Being<br />
able to reuse that network for different<br />
purposes, including how you<br />
use that network to deliver triple<br />
play services, but also use the same<br />
network for mobile backhaul.<br />
FT: So, what’s next on the horizon<br />
at the forum as it relates to<br />
MPLS/<strong>Ethernet</strong>-based wireless<br />
backhaul?<br />
dS: If you look at the work from<br />
the Next Generation Mobile Networks<br />
(NGNM) industry group,<br />
they are starting to look at taking<br />
macrocells and dividing them<br />
down into smaller cells to make<br />
better use of the wireless spectrum.<br />
When you do that you don’t<br />
have a 250-foot tower, but instead<br />
have a small device hanging from<br />
a ceiling in a shopping mall. What<br />
does that architecture look like and<br />
how does that change the mobile<br />
backhaul perspective?<br />
That’s actually something<br />
we’re looking at now. We put out<br />
TR-221, which is dealing with the<br />
macrocell base stations, but now<br />
we are working on an addendum<br />
to that specification to do two<br />
things. One, there were a number<br />
of things in TR-221 that weren’t<br />
quite mature for us to reference,<br />
but those things have cleared and<br />
now we’ll put out the corresponding<br />
reference. The second thing<br />
is we’re doing is looking at this<br />
NGNM initiative around small cells<br />
and looking at how that changes<br />
mobile backhaul. Right now, we’re<br />
looking at it and seeing it as a<br />
necessary evolution to what’s happening<br />
in mobile backhaul. You’ll<br />
see things like the access used to<br />
be P2P fiber or a microwave link<br />
running <strong>Ethernet</strong> or TDM, but now<br />
it could be a VDSL2 link. You have<br />
to be able to put that thing on a<br />
light pole, so you won’t be deploying<br />
a large router next to it but<br />
rather will run a DSL link to it. I will<br />
get my <strong>Ethernet</strong> backhaul any way<br />
I can by whatever access possible<br />
that’s cost effective. That’s probably<br />
true of any <strong>Ethernet</strong> service.<br />
Whether I’m serving a house or<br />
serving an enterprise, I am going<br />
to use whatever access technology<br />
I can that’s most cost effective. l<br />
Q&A: Ralph Santitoro, founding<br />
member and Director of the Metro<br />
<strong>Ethernet</strong> Forum (MEF)<br />
� In considering a path to<br />
<strong>Connection</strong>-<strong>Oriented</strong> <strong>Ethernet</strong><br />
(COE), Ralph Santitoro,<br />
founding member and director<br />
of the Metro <strong>Ethernet</strong> Forum<br />
(MEF) is quick to point out that<br />
COE is not just based on one<br />
standard, but rather a collection<br />
of standards. Santitoro said that<br />
much like ATM, “there’s no one<br />
standard for COE, but rather<br />
a collection of standards.”<br />
This collection of standards<br />
represents both an <strong>Ethernet</strong>centric<br />
and MPLS-centric approach to COE. Sean Buckley,<br />
Senior Editor of FierceTelecom, sat down with Santitoro to<br />
discuss the merits of both approaches and their role in the<br />
next-gen telecom network.<br />
FierceTelecom: To start, can<br />
you give an overview of<br />
what’s driving the need for<br />
the <strong>Ethernet</strong>-centric approach<br />
to COE?<br />
ralph Santitoro: If you look at<br />
what the most popular <strong>Ethernet</strong><br />
services are right now, they<br />
are all point-to-point services.<br />
Those are used for lots of different<br />
things, including wireless<br />
backhaul, data center interconnect,<br />
and site-to-site VPNs. You<br />
also have infrastructure applications<br />
like broadband backhaul<br />
for telcos’ DSLAMs (digital<br />
subscriber line access multiplexers),<br />
PON (passive optical<br />
network) devices, and CMTS<br />
(cable modem termination<br />
systems) for cable operators’<br />
DOCSIS systems. The reason<br />
why I wanted to paint that picture<br />
is that point-to-point rules<br />
in WAN (Wide Area Networking)<br />
and also for infrastructure<br />
services like backhaul. COE was<br />
created to have a packet friendly<br />
version of that service.<br />
FT: What is the state of the<br />
COE market and what’s<br />
driving service providers to<br />
it?<br />
rS: Even though COE has been<br />
around for about 10 years, it’s<br />
finally starting to see a lot of<br />
continued on page 15<br />
13 April 2012 April 2012<br />
14
FierceTelecom.com<br />
continued from page 14<br />
uptake for the following reason:<br />
A lot of carriers are finally capping<br />
their SONET (synchronous<br />
optical networking) infrastructure<br />
and want to move to a full packetbased<br />
technology. A lot of those<br />
organizations had big SONET<br />
networks and these are the ones<br />
that are driving the COE market.<br />
They are delivering lots of <strong>Ethernet</strong><br />
over SONET (EoSONET) with guaranteed<br />
bandwidth delivery. They<br />
realized they needed something<br />
that has to be that good to replace<br />
SONET because the customers<br />
won’t accept anything less than<br />
that, but they are being forced to<br />
move over because they need a<br />
much more scalable, packet-centric<br />
type of service. That’s what is<br />
making COE take off. A number<br />
of service providers I met with<br />
recently said they are still going<br />
through that exact same transition<br />
where they are saying ‘we’re still<br />
going to offer SONET services to<br />
those customers that want it, but<br />
the reality is we want to do <strong>Ethernet</strong><br />
over fiber service and COE is<br />
the way to go.’ COE allows them<br />
to have a more cost-efficient, scalable<br />
infrastructure versus SONET.<br />
With SONET, service providers<br />
have to sell bandwidth in 50 Mbps<br />
increments in order to recoup their<br />
investment because every SONET<br />
channel is 50 Mbps. Customers<br />
don’t necessarily want to buy<br />
bandwidth that way, but that’s the<br />
way service providers had to offer<br />
it because that was their transport<br />
infrastructure.<br />
FT: How is the service provider<br />
community responding to COE?<br />
Is it mainly being deployed<br />
by domestic or international<br />
carriers or both?<br />
rS: I am seeing a lot of interest in<br />
both the U.S. and Canada. I know<br />
a large carrier that does broadband<br />
backhaul for their infrastructure<br />
and COE made a lot of sense for<br />
them. Even though their last mile<br />
is copper, their infrastructure is<br />
completely COE-based because<br />
it allows them to offer high performance<br />
<strong>Ethernet</strong> over Copper<br />
service. Normally, you had buy<br />
fiber to get a high performance<br />
<strong>Ethernet</strong> service, but with COE<br />
they can offer the same type of<br />
performance over copper.<br />
FT: Earlier, you mentioned<br />
wireless backhaul. How are<br />
wholesale operators that<br />
provide services to wireless<br />
operators using COE?<br />
rS: It is probably one of the biggest<br />
areas of growth. The reason<br />
for that is the wireless operations<br />
had been very stringent on backhaul<br />
even though the data traffic<br />
from the cell phones is best-effort.<br />
Normally, if the wireless operator<br />
has some T1s to a 3G base<br />
station they will backhaul those<br />
over SONET. Even if they have<br />
a SONET infrastructure they can<br />
run COE over SONET to get better<br />
efficiency on their backhaul<br />
network. Today, the vast majority<br />
of backhaul is EoSONET, and<br />
the reason why is the wireless<br />
operators don’t trust the wireline<br />
providers doing the backhaul. They<br />
said, ‘Look, I want you to give<br />
me EoSONET because I know it<br />
works.’ Some service providers<br />
will run COE over SONET and that<br />
allows them to get better bandwidth<br />
utilization over their SONET<br />
backhaul network. These carriers<br />
will do it this way because they<br />
had some T1s from the 3G base<br />
stations. Rather than using SONET<br />
in 50 Mbps chunks, they can<br />
now take multiple <strong>Ethernet</strong> ports<br />
coming from different base stations,<br />
including 3G and some 4G<br />
LTE, and run it over that SONET<br />
infrastructure and get much better<br />
bandwidth efficiency.<br />
When it comes to COE for LTE<br />
data backhaul, the carriers want<br />
to have a backhaul infrastructure<br />
that prepares them for the future.<br />
Today, LTE is all about best effort<br />
data and their voice is still 3G<br />
voice. They don’t provide voice in<br />
LTE. You can envision in a couple<br />
of years they will move over to<br />
VoIP and will not be doing circuit<br />
switched voice anymore like they<br />
do today for the voice part of LTE.<br />
When they get to that, the VoIP<br />
service will require some stringent<br />
backhaul. By putting in COE today<br />
for their best effort data backhaul,<br />
they’re preparing for the future<br />
when they introduce VoIP. It’s like<br />
planning for the future, but not<br />
really paying any additional amount<br />
because COE is just as cost competitive<br />
with other <strong>Ethernet</strong>-based<br />
backhaul technologies.<br />
FT: In the COE domain, there<br />
are a number of approaches,<br />
including the <strong>Ethernet</strong>-centric<br />
and the MPLS-centric views.<br />
What benefits or advantages<br />
does the <strong>Ethernet</strong> approach<br />
have over MPLS, or does it<br />
depend on the service provider?<br />
rS: You can implement COE<br />
with either <strong>Ethernet</strong> or MPLS. I<br />
think there are reasons for both.<br />
If you’re an equipment manufacturer<br />
that builds routers, then<br />
more likely than not you would<br />
chose an MPLS-centric approach<br />
because that’s what your product<br />
development organization is used<br />
to. If you’re coming from a pure<br />
<strong>Ethernet</strong> side as a developer of<br />
<strong>Ethernet</strong> switches or Packet Opti-<br />
cal Network Platforms (PONP) like<br />
Ciena, Fujitsu or Cyan, you would<br />
probably do an <strong>Ethernet</strong>-centric<br />
approach. It makes more sense<br />
there, not only from how they sell<br />
products, but also because the<br />
customers they sell products to<br />
are the transport organizations<br />
that know SONET. MPLS is like a<br />
foreign language to them.<br />
COE was actually designed with<br />
SONET in mind. A lot of the standards,<br />
like 50 millisecond protection<br />
switching and fault management,<br />
came from the SONET world and<br />
even uses a lot of SONET terminology.<br />
It would be very familiar<br />
for someone who knows SONET.<br />
There’s an ITU-T standard called<br />
G.8031 that defines linear path<br />
protection, which is called the<br />
same thing in SONET with a working<br />
path and a protection path. If<br />
the working path fails you switch<br />
over to the protect path within 50<br />
milliseconds. It’s very friendly for<br />
SONET/SDH transport people who<br />
are used to those terms. Most<br />
SONET people are familiar with<br />
<strong>Ethernet</strong> because they’re using<br />
<strong>Ethernet</strong> to connect their SONET<br />
devices. That’s why the <strong>Ethernet</strong>centric<br />
approach is good for that<br />
type of organization because they<br />
are switching their SONET/SDH<br />
networks over to a packet network.<br />
They are asking, ‘Should I<br />
make the leap to MPLS or should<br />
I make a leap to <strong>Ethernet</strong>? Well,<br />
all of my operational staff knows,<br />
and OSS systems know <strong>Ethernet</strong>,<br />
so let me go with <strong>Ethernet</strong>. Why<br />
add an extra layer?’ That’s been<br />
the big driver because MPLS adds<br />
another layer of technology that<br />
they are not familiar with using. l<br />
15 April 2012 April 2012<br />
16