Tour Google's Software Defined Net

SAN JOSE, Calif. — Google provided a glimpse into the state-of-the-art in software defined networking, a new approach aimed at breaking through bottlenecks faced by the world's biggest networks. In a keynote at the Hot Interconnects conference here, the web giant gave a virtual tour of B4, its pioneering effort to build a production software defined network (SDN).

The talk showed Google is gaining real benefits in lower costs and simpler management of its networks using SDN. However, it also revealed fundamental work is still ahead designing new protocols and hardware optimized for the approach.

SDN aims to manage large networks through C-language programs running on a central bank of standard x86 servers. That's a radical departure from today's nets based on distributed protocols running on routers and switches that require close supervision by human operators often using command-line interface (CLI) tools.

Google set up its B4 network as an SDN test bed, providing wide-area links between many of its datacenters. "B4 is pushing hard to manage the network as a single fabric, not as thousands of networking boxes -- the thought of logging into CLI is unacceptable," said Amin Vahdat, a distinguished engineer at Google, speaking in his keynote on the campus of Cisco Systems here.

As it grows, Google's biggest networking problem has become operational costs. "Real smart people need to know the interactions among the boxes, but the complexity grows like the square of the number of boxes, so we need more smart people to manage smaller and smaller parts of the network," Vahdat said.

So far, B4 has proven Google can reduce the capital and operational costs of its networks by reducing the need for hardware and management staff. It has also sped up network innovation; Google now rolls out new network features in software as often as once a week. "That’s substantially improved velocity in new functionality and traffic engineering," he said.

However SDN is "not a panacea," and Google sees substantial challenges ahead, he added. In its race toward SDN, Google had to build its own routers and customized versions of protocols including the emerging OpenFlow SDN protocol which it sees it as far from optimal. "We are in the enviable position of being able to hack OpenFlow, so if it doesn't meet our needs we change it," he said.

Running more jobs remotely in higher-level software threatens to reduce performance. Google is still experimenting with what jobs it can run on servers and what latency-intensive tasks must continue to run directly on routers and switches.

Asked what he needs in hardware, Vahdat said he wants protocol-agnostic silicon with one- or two-stage parsers. The chips must quickly find on a per-packet basis still-evolving bit patterns that will trigger hashing, forwarding or routing actions.

"Programmable logic is not fast enough," he said in response to a question after the keynote. "We are moving to multiple terabits per second and pushing the bleeding edge of silicon in response speeds," he said.