Connection Oriented Ethernet - InfoVista
Connection Oriented Ethernet - InfoVista
Connection Oriented Ethernet - InfoVista
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
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