x

MPLS Will Outgun ATM, Says Poll

In five years' time, Multiprotocol Label Switching (MPLS) will play a more important role in metro networks than Asynchronous Transfer Mode (ATM), and Ethernet will be more pervasive than Sonet/SDH, according to this month's Light Reading Research Poll.

The poll asks respondents to forecast the relative importance of different protocols in metro networks in 2007. And the results so far, from just over 150 users, make interesting reading.

Ethernet has a rosy future, according to survey respondents. 37 percent of them say it will be "crucial" in metro networks, and another 36 percent say it will be "very important."

This exceeds support for Sonet/SDH. Only 14 percent say that it will be "crucial" in metro networks in five years' time, while 35 percent say it will be "very important."

As already noted, MPLS gets more support than ATM, the two protocols associated with being able to guarantee quality of service. MPLS will be "very important" by 2007 according to 28 percent of respondents. The comparable figure for ATM is a mere seven percent.

Resilient Packet Ring (RPR) technology gets a resounding "don't know" with votes split evenly across "very important," "important," "fairly unimportant," and "unimportant."

In reality, all of these protocols are likely to coexist in different parts of carrier networks, as Light Reading's recent report on metro technologies explains (see Metro Multiservices Evolution).

Other results of Light Reading's Research Poll show that most respondents (60 percent) think boosting revenue should be the top priority for carriers building metro networks. Just 39 percent believe cutting costs is more important.

The best way to boost revenue in metro networks is to reach new customers, according to 37 percent of respondents. That could mean extending geographic coverage or offering a wider range of services. The next-best ways to generate revenue are to speed up provisioning times (21 percent) or offer higher-bandwidth services (20 percent). The most effective way to cut costs is to use bandwidth more efficiently, according to 45 percent of respondents. Next comes cutting equipment costs (29 percent), followed by cutting maintenance staff requirements (20 percent).

Want more details? Take Light Reading's Research Poll yourself by clicking here. — Peter Heywood, Founding Editor, Light Reading
http://www.lightreading.com
<<   <   Page 34 / 35   >   >>
sgan201 12/4/2012 | 10:38:46 PM
re: MPLS Will Outgun ATM, Says Poll Hi trepanne,
Please look at section 26.2.4 Buffer impact on TCP/IP performance on the book "ATM Theory and Application" Signature edition by David McDysan and Darren Spohn.
You can inferred from that section if an ATM switch or Router does not have enough buffer, it will not give good utilization.
Before someone frame me, this is in regards to the edge again. This is for the situation that the trunk is OC-12 or lower.
Most ATM switches that was originally designed for LAN do not include enough buffer to handle the WAN situation...
sntwk 12/4/2012 | 10:38:45 PM
re: MPLS Will Outgun ATM, Says Poll I'm not at all convinced that leased lines will win this one.

Sure prices for leased lines have fallen dramatically, but:

1. You still need one physical interface per remote destination with SONET/SDH (though sure, channelised interfaces are an option - albeit a rather less flexible one than FR DLCIs, ATM PVCs or 802.1Q VLAN tags.)
Not necessary. You yourselves said that customers are using switches. The switch if it supports SONET/SDH channelized transport, it could be setup with multiple destinations. For instance if the switch has OC-48, it can have a OC-3 going to City-1, a OC-3 going to city-2, and OC-12 going to city-4 and the remaining bandwidth going nowhere. I don't if any switch vendors supports channelized WAN access.

3. The physical interface you use to connect IP equipment to SONET/SDH has to be on a router - so it costs an order of magnitude more than a switch port. Many of the customers on the network I run connect with switches (or even Linux boxen) for economic reasons.
Is it possible that they want to share the WAN link by multiple routers on their LAN and that is they layer they put a switch? A Dump L2 gateway , if you will, so that the WAN can be shared: not channel basis but packet by packet basis the WAN link is shared. I think that is the best solution. I known some smart WAN PHYs etc but this is the best solution I think to let arbitrary bandwidth sharing of the WAN-link. The switch if it can implement SONET/SDH channelized then dynamic bandwidth allocation might be possible.

5. You typically have to buy leased lines in powers of 4 granularity. With Ethernet delivered services you typically buy by the meg.

With SONET/SDH virtual concatenation ( I don't how many actually support) it is possible to get the granularity down to 50Mbps. If you are using 50 and you want another 50, without virtual concatenation you will be offered 150. If you are at 150 and you want another 50, you will be offered 600 and not 200. But virtual concatenation allows provider to offer in increments of 50 and not 4 times.

6. Usage pricing isn't really an option for SONET/SDH. I often see customers who would have bought (say) a DS3 buying Ethernet bandwidth and only using 10 or 15 megs - so even if the price per bit is higher for Ethernet services the overall cost is lower.

Usage based cost , is not an option with SONET/SDH private lines. You bought your private property and you paid for it. Nobody checking whether you are staying in private property or not. It might be possible if there are some smart sonet/sdh framers that process every service passing through them and identify the application traffic within the service and keep some counters.

However unless there is a business case why would vendors develop such framers and why would carriers bother with such offerings which is more a head ache than solution. Who cares, just blanket charge for private line on monthly or 6-months contracts bais is good enough I think. Remember there is no competetion any more. All CLECS/DLECs are dead and OC-48 coast-to-cast is a fat earner for the transport providers. I know 2 years back it was costing 2.5 Million $/year to have a private OC-48 coast to coast. Any one provide guess on how much it costs now? So why would the same carrier offer the same service for less when there is no fear that the customer go with someone else?
sgan201 12/4/2012 | 10:38:45 PM
re: MPLS Will Outgun ATM, Says Poll Hi Lopez,
Just to compare:
A Cisco 12K series OC-192 port support 2048 queues.
A CBX 500's OC-12 port support 8000 queues..
OC-12 is 16 times slower..

I would say that a Router support two order of magnitude less queues than ATM switches..

Won't you agree??
giles0 12/4/2012 | 10:38:43 PM
re: MPLS Will Outgun ATM, Says Poll ------
Not necessary. You yourselves said that customers are using switches. The switch if it supports SONET/SDH channelized transport, it could be setup with multiple destinations. For instance if the switch has OC-48, it can have a OC-3 going to City-1, a OC-3 going to city-2, and OC-12 going to city-4 and the remaining bandwidth going nowhere. I don't if any switch vendors supports channelized WAN access.
------

I don't know of any Ethernet switch offering channelised OCn ports. And even if such a beast exists I suspect these ports are orders of magnitude more expensive than GigE ports...

------
Is it possible that they want to share the WAN link by multiple routers on their LAN and that is they layer they put a switch? A Dump L2 gateway , if you will, so that the WAN can be shared: not channel basis but packet by packet basis the WAN link is shared. I think that is the best solution. I known some smart WAN PHYs etc but this is the best solution I think to let arbitrary bandwidth sharing of the WAN-link. The switch if it can implement SONET/SDH channelized then dynamic bandwidth allocation might be possible.
------

I'm not quite sure what you are trying to say here :(

In any case the reason customers want to connect a switch (Ethernet) to the WAN is that switch ports are cheap and readily available (since they tend to be bought in blocks of 8 or more). This may either be a L2 switch front-ending a router (so the router can access links to multiple providers/destinations) or a L3 switch (in which case no discrete "router" is required as the L3 switch performs the routing function).

------
With SONET/SDH virtual concatenation ( I don't how many actually support) it is possible to get the granularity down to 50Mbps. If you are using 50 and you want another 50, without virtual concatenation you will be offered 150. If you are at 150 and you want another 50, you will be offered 600 and not 200. But virtual concatenation allows provider to offer in increments of 50 and not 4 times.
------

Sure, virtual concatenation allows you to do 50mbps increments. But I don't think many carriers offer this yet - and it is still rather less granular than 1mbps increments as typically offered by Ethernet-based providers.

------
Usage based cost , is not an option with SONET/SDH private lines. You bought your private property and you paid for it. Nobody checking whether you are staying in private property or not. It might be possible if there are some smart sonet/sdh framers that process every service passing through them and identify the application traffic within the service and keep some counters.

However unless there is a business case why would vendors develop such framers and why would carriers bother with such offerings which is more a head ache than solution. Who cares, just blanket charge for private line on monthly or 6-months contracts bais is good enough I think. Remember there is no competetion any more. All CLECS/DLECs are dead and OC-48 coast-to-cast is a fat earner for the transport providers. I know 2 years back it was costing 2.5 Million $/year to have a private OC-48 coast to coast. Any one provide guess on how much it costs now? So why would the same carrier offer the same service for less when there is no fear that the customer go with someone else?
------

I wasn't saying that anyone would develop usage-priced SONET/SDH.

I was saying that one disadvantage of SONET/SDH is that it can't offer usage-pricing.

Typically (and I admit this is a vast genersalisation/over-simplification) data circuits run at around 20% utilisation. Why pay for the 80% you don't use?

In any case, as you say, the main issue is the lack of surviving DLECs to deliver Ethernet links to the customer (at least in the US).

Eventually corporates may start to discover a business case for taking matters into their own hands and buying/leasing dark fibre to colo sites where they can buy services from multiple providers without paying exorbitant prices for the local loop of each circuit they require...

Giles
LightSeeking 12/4/2012 | 10:38:42 PM
re: MPLS Will Outgun ATM, Says Poll Giles:

Could you tell us what bandwidths you are seeing for interconnecting POPs? OC12, OC48, or OC192 and/or their ethernet equivalents? And what is the distant range that connects these POPs?

I'd be surprised if the bandwidth to interconnect POPs is higher than OC48 in today's networks; I think most are at the OC12 rates.

LightSeeking
giles0 12/4/2012 | 10:38:41 PM
re: MPLS Will Outgun ATM, Says Poll In my network STM-16c (OC-48) between PoPs a few hundred miles apart.

Many larger SPs use OC-192 inter-city and GigE intra-city...
sntwk 12/4/2012 | 10:38:27 PM
re: MPLS Will Outgun ATM, Says Poll

If the cell size had been 128 bytes, then the cell tax would have increased. This is because most IP packets are short. I would guess that this would have killed off ATM more quickly.
-----------------------------------
Probably no.

I remember many years ago a presentation that said european proposal called for 69 byte cell (5+64) and USA proposal called for (5+32). If USA proposal was accepted every 40 byte TCP packet would have been sent as two ATM cells i.e 74 bytes in total, wich represents a overhead of 34 bytes for every 40 bytes of TCP packet. This overhead only at the ATM layer , not including the SONET layer.

Even assuming that ATM cell size was 128, it would have been impossible to think that, because for IP traffic it represents too much overhead, ATM would have died.

What happened is slow and gradual deployment of ATM from late 80's to mid nineties during which time the predominent data traffic was FR/X.25 and Voice traffic. RBOCs and others built their data transport network with ATM not to support internet traffic but to support FR/X.25 and Voice with CircuitEmulation.

Bluebeam 12/4/2012 | 10:38:26 PM
re: MPLS Will Outgun ATM, Says Poll Author: sntwk Number: 337
Subject: Re: That 'ATM Cell tax' Date: 4/9/2002 8:31:17 AM

If the cell size had been 128 bytes, then the cell tax would have increased. This is because most IP packets are short. I would guess that this would have killed off ATM more quickly.
-----------------------------------
Probably no.


Agreed. A 40 byte packet needs two 53 bytes cells anyway, so the impact is not that big (around 20%). For bigger packets, the improvement is around 50%. While half the total of IP packets are small ones (40-44), these only amount for 5% of the bandwidth. See
http://www.lucent.com/minds/te...

Bluebeam
ps: in these journal there is also an IP vs IP/ATM comparison. Not surprisingly coming from Lucent, the conclusion is in favour of IP/ATM (that was in 1998)
broadbandboy 12/4/2012 | 10:38:22 PM
re: MPLS Will Outgun ATM, Says Poll LightSeeking: "Does anyone know whether the announcement from Qwest today regarding the Mellon network uses MPLS or ATM in the backbone? Thanks."

Without knowing any more than reading the press release, I doubt that services including inbound/outbound voice, frame, ATM and private line would be provided over a router-based MPLS backbone due to the difficulty in guaranteeing customer SLA commitments for frame and ATM.

That is just a guess based on past experience, and I could be wrong.

It is worth noting that again, the big money making services are, once again, voice, PL, frame and ATM.

BBboy
broadbandboy 12/4/2012 | 10:38:22 PM
re: MPLS Will Outgun ATM, Says Poll sntwk: "I remember many years ago a presentation that said european proposal called for 69 byte cell (5+64) and USA proposal called for (5+32). If USA proposal was accepted every 40 byte TCP packet would have been sent as two ATM cells i.e 74
bytes in total, wich represents a overhead of 34 bytes for every 40 bytes of TCP packet."

I'm sorry to say that, as I the story, you have it exactly backwards. The euro-PTTs were pushing for a 32 byte payload to minimize latency for voice. The US, being more data centric, wanted the larger 64 byte payload for greater efficiency in data transport. The committee-style compromise was to add 32+64=96 and divide by two. The result was a 48 byte payload + a small 5 byte header = 53 bytes.

What a stupid way to design a protocol that was supposed to provide the support for all modern communications! This "compromise" resulted in a cell size that was too big for voice, too small for data. It was the worst of both worlds!

The reason UUnet was reluctant to migrate from frame to ATM was that now two cells would be required to carry one ack packet which is the worst case scenario. Talk about wasted bandwidth!

BBboy
<<   <   Page 34 / 35   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE