Google’s next OpenFlow challenge: taking SDNs to the consumer


Urs Hölzle, SVP of technical infrastructure at Google

Google (s goog) is running all of its backbone traffic on a software-defined network built using OpenFlow, and it hopes that this year it can begin the process of extending that type of programmable network to its consumer-facing network: the network that delivers applications such as Maps and YouTube to consumers and businesses. Urs Hölzle, SVP of technical infrastructure and Google Fellow, today at the Open Networking Summit detailed how Google is using OpenFlow on its network to lower costs and reduce complexity, which I wrote about last week.

But in that talk he also said that Google hopes to build an SDN that could handle the far more complex and important types of traffic that it delivers to users. That network requires much more reliability and also has to interface with far more devices and protocols, making the task of turning it into an SDN more fraught. As an example, Hölzle told me he expects the internal WAN network to achieve a 99.95 or a 99.99 percent reliability rate (it’s not quite that yet) but any user-facing service has to achieve something closer to the telecom ideal of five nines.

Another issue associated with changing the external network to a software-defined network is the gear. In his talk, Hölzle explained the type of gear Google began building in 2010 in order to build this OpenFlow network. It was a basic switch using merchant silicon and running almost no software, just the software needed to get it up and running, and an OpenFlow agent. Everything else was handed off to a controller.

But to take such a network to the external site, Google wants someone else to build the hardware. Hölzle says it does look like firms will build the type of gear he wants that uses OpenFlow as the management API, and he expects Google to start looking at the problem of how to move the external-facing network to an SDN this year. That doesn’t mean it will happen anytime soon–although Google did manage to transfer all of its WAN traffic to an OpenFlow network in two years–but that it will happen.

And that’s important because the same cost savings that Google is seeing on its WAN network could end up helping lower the cost of delivering bits over consumer broadband networks, and thus help ISPs reduce their costs. Hölzle hopes that might reduce the need for ISP network protection schemes such as broadband caps, but I’m not as optimistic.


Ron Amadeo

Removing bandwidth caps. That’s funny.

Broadband caps are about greed and upselling, not bandwidth management.

Keith Townsend

Is there a overhead associated with running this management API over commodity network gear? It seems more vendors support some type of openflow management stack in the hardware platform.

Comments are closed.