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

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

fully agree with you!

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.&nbsp; My VPN'ed bandwidth is way more under control than that as it enters and leaves the data centers.&nbsp; Within the data centers themselves, there are two more issues:&nbsp; Within a colo cage and between colo cages.&nbsp; Within a cage - not required.&nbsp; Between cages maybe.


&nbsp;


seven


&nbsp;

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 &lsquo;L1 VPNs&rsquo; 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.



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

&nbsp;


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: &nbsp;Nope - that is going to be over layer 3.


Internal User connectivity: &nbsp;Maybe - a VPN setup but it means the enterprise has spare transport capacity out of the office. &nbsp;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: &nbsp;These are generally lots of huge pipes. &nbsp;Maybe a connection between data centers would be VPNed this way. &nbsp;Again for it to be dynamic this would mean that spare capacity would have to be prebuilt. &nbsp;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: &nbsp;Normally done via Ethernet Switches. &nbsp;Can be done via wavelength, but Ethernet is a LOT cheaper.


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


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


&nbsp;


seven


&nbsp;

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

Northern,


to your point, and I quote: "&nbsp;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."


&nbsp;


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. &nbsp;But I was taught that layer zero was the physical medium, e.g., copper, fiber, spectrum in the air for wireless, etc. &nbsp;layer 1 is the basic framing and encoding.... both layer 0 and layer 1 are subject to the analog issues of physics. &nbsp;


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


sailboat

<<   <   Page 2 / 2
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE