x
Cloud enablement

Cloud Could Face Network Bottlenecks

NEW YORK -- Carrier Cloud Forum -- Cloud computing is all about delivering services in real time, but how does that jibe with a network that's built on not-so-nimble virtual private networks (VPNs) and static circuits?

The topic came up here during a panel titled, "Building the On-Demand Cloud Infrastructure." A lot of attention is being lavished on how to get carriers' back-office and OSS systems primed for cloud services. But there's a network aspect to be considered, too, and panelists seemed eager to talk about it when an audience member brought it up.

That's because they happen to be working on the problem already. Alcatel-Lucent (NYSE: ALU) is working with a couple of carriers on "building dynamic environments for VPN interconnect," said David Frattura, senior director of cloud strategy.

Cisco Systems Inc. (Nasdaq: CSCO) likewise has prototype setups running with service providers, where the orchestration layer stays informed about things like network connections and security requirements, said Simon Aspinall, a Cisco director of marketing. He expects Cisco to reveal some of this work during the next 12 months, as the vendor tries to build an environment "where the network is becoming very cloud-aware and the cloud is becoming network-aware."

This leads to an argument that the network, in the case of cloud services, can't be a dumb pipe. Kip Turco, now a senior vice president with Windstream, noted during the panel that this is why Windstream Communications Inc. (Nasdaq: WIN) bought Hosted Solutions (acquiring Turco himself in the process). (See Windstream Unwraps Cloud Strategy.)

All this orchestration could open up some upselling angles, too. "If you're a first-mile provider, and your customer wants to consume 20 virtual desktops ... shouldn't you pop up a window saying that for this period of time, they really should consume extra bandwidth?" Frattura said.

— Craig Matsumoto, West Coast Editor, Light Reading

Page 1 / 2   >   >>
paolo.franzoi 12/5/2012 | 4:51:37 PM
re: Cloud Could Face Network Bottlenecks

 


I assumed he was talking about Out of band signalling like SS#7 or an ISDN D channel.


The problem I still see is where:


External User connectivity:  Nope - that is going to be over layer 3.


Internal User connectivity:  Maybe - a VPN setup but it means the enterprise has spare transport capacity out of the office.  Maybe time shifted connectivity but not sure that this would also not run over layer 3 (Time of day connections).


Carrier to the Data Center:  These are generally lots of huge pipes.  Maybe a connection between data centers would be VPNed this way.  Again for it to be dynamic this would mean that spare capacity would have to be prebuilt.  It is still not clear to me that augmenting connectivity like this with dynamic Layer 3 VPNs is not a whole lot simpler.


Carrier Internconnect Point to the Colo Cage:  Normally done via Ethernet Switches.  Can be done via wavelength, but Ethernet is a LOT cheaper.


Colo Cage Interconnect within a facility:  See the statements directly above.


Within a Colo Cage:  Ethernet Switches are so cheap that it makes sense.


 


seven


 

^Eagle^ 12/5/2012 | 4:51:37 PM
re: Cloud Could Face Network Bottlenecks

Northern,


to your point, and I quote: " to avoid the need deal with the dynamic bandwidth allocation challenges at analog level of physics, a digital system design based solution is preferred; hence Id call the solution the 'cloud' ASPs etc are looking for their inter data center / Internet access point private backbone as L1 VPNs rather than L0 VPNs."


 


When you go digital, you are by definition back to layer 2 at a minimum or perhaps back up at layer 3 if you want to be able to determistically move and re route bandwidth.


Maybe I am old fashioned or simply old.  But I was taught that layer zero was the physical medium, e.g., copper, fiber, spectrum in the air for wireless, etc.  layer 1 is the basic framing and encoding.... both layer 0 and layer 1 are subject to the analog issues of physics.  


you get into the digital domain once you get to layer 2.


sailboat

paolo.franzoi 12/5/2012 | 4:51:38 PM
re: Cloud Could Face Network Bottlenecks

What the heck is a "multi-point interconnect pool"?


Are you suggesting on demand crossconnects at data centers so that people can turn up say a GigE and turn it down later that day?


Cuz about the only thing that I need to turn up and down that much is Internet connectivity.  My VPN'ed bandwidth is way more under control than that as it enters and leaves the data centers.  Within the data centers themselves, there are two more issues:  Within a colo cage and between colo cages.  Within a cage - not required.  Between cages maybe.


 


seven


 

joferrei 12/5/2012 | 4:51:38 PM
re: Cloud Could Face Network Bottlenecks

To clarify, I said that I dont see a business model for a network operator to keep its bandwidth in reserve for on-demand use. Instead, there appears to be a need for a service model where L1/0 bandwidth is sold by the network owner to customer (e.g. ASP) as multi-point interconnect pools rather than as fixed point-to-point circuits.


*Within* such multi-point interconnect pool based contracts, there actually should be demand driven bandwidth allocation, to avoid the need for overprovisioning (which would be needed with statically provisioned L1/0). This reduces capacity amount based CapEx factors (as well as related, facilities type Opex factors), for a contract of given revenue level.


If the demand driven bandwidth allocation is done at L1/0, also the need for more complex packet layer processing is avoided within the private pool based contract network (call it L1 VPN or whatever). This reduces OpEx, as well as equipment CapEx, again compared to revenue achievable with the contract.


Moreover, L1/0 packet transport solution avoids the QoS and security issues of L2 or higher layer VPNs that mix different customer contracts at packet layers. Therefore these ‘L1 VPNs’ provide vital performance and security benefits over packet layer VPNs. This improves the price/Gbps ie revenue generation capability of contract of given physical capacity.


Finally, as mentioned, to avoid the need deal with the dynamic bandwidth allocation challenges at analog level of physics, a digital system design based solution is preferred; hence Id call the solution the 'cloud' ASPs etc are looking for their inter data center / Internet access point private backbone as L1 VPNs rather than L0 VPNs.


Note also that there was an active IETF WG on L1VPNs a couple years back; I dont know if what Im trying to articulate here is compatible with what IETF defined.. perhaps another name is needed.



rzerockzeron 12/5/2012 | 4:51:41 PM
re: Cloud Could Face Network Bottlenecks

fully agree with you!

^Eagle^ 12/5/2012 | 4:51:42 PM
re: Cloud Could Face Network Bottlenecks

I am fully aware of SONET/SDH standards and performance.  I was one of the very first member of the Sonet Interoperability Forum and helped write the specs.  UPSR, BLSR, etc.


today, there is no real such thing as Layer 1 on demand in a "cloudy" world.  Yes, there are overprovisioned protected paths, rings and mesh.  but those are all bought and paid for with people paying for the over provisioning and redundancy.


VPN's are not a layer 1 function.  A long time for that to happen.  


And yes, I am fully aware of the work being done on "wavelengths on demand.


to do that, there are lots of architechtural changes that need to be implemented.  ROADMs help, but only in so much as they can add or drop wavelenghts that ARE ALREADY THERE.  There is no majic bullet for layer 1.  You have to massively overbuild to really have excess capacity that can be sent anywhere at any time.


And remember, all transmission at root is analog.  To really do wavelength on demand you either need complete electrical regeneration at every node (what infinera advocates) WITH overprovisioning of lots of spare capacity, OR you need fully deployed at every node dynamic gain equalization, dynamic dispersion compensation, colorless hitless directionless ROADMs, no static muxes, and a systemic network wide control plane.  Not to mention fully embedded monitoring at every node that looks down into the wavelength level performance.


So yes, folks are working on this.  And yes, we are getting closer.  But it is still a ways off.  And no one working at layer 1 for flexible network architechtures is doing it to enable bandwidth unlimited VPNs at layer 1.  


They are doing it to have lower opex costs at the transport layer


VPNs are uniqely layer 2 or layer 3 beasts at least for the foreseable future.


down the road, who knows.  But for now, not really possible without a massive investment in infrastructure.  Which no one has figured out a business model to justify and pay for.


sailboat

rzerockzeron 12/5/2012 | 4:51:42 PM
re: Cloud Could Face Network Bottlenecks

in fact, layer 1 has always been deterministic with fixed capacity/restoration. That's what SONET/SDH and OTN are for.


I'll however mention lots of work being done by a lot of equipment vendors to offer 'circuit on demand' and 'wavelength on demand' as alternatives to L2/L3 offers.

^Eagle^ 12/5/2012 | 4:51:43 PM
re: Cloud Could Face Network Bottlenecks

Northern, VPN's are layer 3/4 functions.  There is no mechanism for layer 1 VPN's.  Remember, layer 1 is the physical layer transport.


There is no mechanism to dynamically call up more physical transport bandwidth unless such bandwidth is already provisioned and standing by idle ready to be throttled up.  Such over provisioning has to be paid for by someone.  Who would that be?


in many corporate environments, the corporation buys a network connection that is more than they need at most times just to give the edge routers / switches just such possibility for the times when users need more.  


but corporations are increasingly trying to reduce costs and are resistant to overprovisioning.  Unless they are wall street trading houses.


sailboat 

paolo.franzoi 12/5/2012 | 4:51:45 PM
re: Cloud Could Face Network Bottlenecks

northernlights,


The thing is let's say we walk you over to my location.  I have a 100 Mb/s fiber optic link connected my office.  I am a cloud service provider (albeit a very small one).


Really the question is do I run a Layer 2 connection out this 100 Mb/s pipe or a Layer 3 one or mixture of the two.


The reality is that I have a Layer 2 connection to one of my data centers and my data centers are all dual homed on Layer 3 connections.  I have a Layer 3 VPN between the data centers.  The backup to my Fiber Optic connection is a wireless broadband layer 3 connection.


In the past, we had a 100 Mb/s Layer 3 connection as our primary connection.  The downside of that was that it was hard to figure of what was going on if there was route flapping in "The Internet". 


In terms of the way I would buy services at something like AWS the bandwidth is bought out of an AWS pool.  I would connect generally over layer 3.  All of that is dynamic.


Which is why I keep asking about this?  I am befuddled by what they are talking about solving.


seven


 

joferrei 12/5/2012 | 4:51:45 PM
re: Cloud Could Face Network Bottlenecks

Agreed that it does not make sense for the physical network owner to keep bandwidth 'unused', or in a reserve for on-demand use. As soon as some one is willing to make a contract to buy physical layer capacity services, I'd sell if the price exceeds the costs (incl opportunity costs).


However, for the 'cloud' applications, the contracts for network capacity services should rather be for a pool of bandwidth to interconnect the given customer's sites (eg data centers and NAPs of an ASP), rather than fixed point to point circuits. The demand for bandwidth among such customer sites will be increasingly dynamic and unpredictable, and accordingly the bandwidth allocation among the sites connected by a given bandwidth pool contract should be demand driven. 


(Ideally also the total bandwidth pool volume and reach per a contract should be more flexible, so there should be 'pools of pools', but that concept probably still needs to further development commercially as well as technically.)

Page 1 / 2   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE