Software defined networking using OpenFlow has worked so well for Google's inter-data center network it's going to adopt it elsewhere

October 23, 2012

3 Min Read
Google: SDN Works for Us

DARMSTADT, Germany -- SDN & OpenFlow World Congress -- Google (Nasdaq: GOOG) is so impressed with the benefits of software defined networking (SDN) that it's going to extend its current international SDN-based inter-data center network and build other new networks using the same capabilities, stated Jim Wanderer, the Web services giant's director of engineering, Platforms Networking.

Google has talked publicly already about its use of the OpenFlow SDN protocol in its internal network that hooked up data centers in North America, Europe and Asia/Pacific and the associated cost benefits. (See Google Uses OpenFlow Massively.)

Wanderer explained here that the inter-data center network was needed and could have been built using legacy technology, but the problem is that those systems "do not behave in a deterministic way, are hard to configure and operate at scale, are error-prone [and] are expensive."

Wanderer and his team wanted to optimize routing and centralize traffic engineering. So they deployed "commodity hardware," with OpenFlow as the SDN protocol alongside the Quagga software routing suite, which was compatible with Google's existing network and known to the operations team.

The team soon found that, using multiple OpenFlow controllers (for low latency and reliable connectivity with the devices being connected) and centralized traffic engineering, the network met requirements and went into production in early 2011.

Among the key benefits were: being able to leverage massive computing power and scale, making it quick and easy to add new applications; the ability to simulate network functionality, including the ability to use the OpenFlow agents to simulate network devices in order to test new applications; the ability to mix simulated test environments with the production network, so that test scenarios could be examined in the live network; high network availability and the ability to engineer "low-impact upgrades"; easier configuration, as the team is configuring a network and a number of fabrics rather than a large number of network elements, though it's still a tough challenge; and very fast failure response and very high network utilization from having centralized traffic engineering.

Of course there are still many challenges. The Google team still has to write code and make decisions about how it wants the network to behave. Also, Wanderer noted that network management was a challenge: "It's different ... [dealing with] run-state status information [from] ... the controllers, APIs" and so on. There were also issues with priority queuing over TCP stream connections that needed to be addressed.

Overall, though, "SDN has worked really well -- it's going into all our projects. There have been big dividends from using high-compute devices in the control plane," stated Wanderer. "We couldn't have achieved the results we have without SDN. We would have built something else to do this but it wouldn't have been as effective."

Now the Google man wants to see SDN taken further to deliver "a better, faster, cheaper Internet." He also wants "carrier-class OpenFlow-enabled hardware" and a great deal more innovation in the SDN sector.

That sounds like a challenge for the vendor community....

— Ray Le Maistre, International Managing Editor, Light Reading

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like