03.02.2013 Views

Connection Oriented Ethernet - InfoVista

Connection Oriented Ethernet - InfoVista

Connection Oriented Ethernet - InfoVista

SHOW MORE
SHOW LESS

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 />

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!