A Peek At Google's Software-Defined Network

CowboyRobot writes "At the recent 2013 Open Networking Summit, Google Distinguished Engineer Amin Vahdat presented 'SDN@Google: Why and How', in which he described Google's 'B4' SDN network, one of the few actual implementations of software-defined networking. Google has deployed sets of Network Controller Servers (NCSs) alongside the switches, which run an OpenFlow agent with a 'thin level of control with all of the real smarts running on a set of controllers on an external server but still co-located.' By using SDN, Google hopes to increase efficiency and reduce cost. Unlike computation and storage, which benefit from an economy of scale, Google's network is getting much more expensive each year."

Comments

centralized = fault-tolerant?

[Anonymous Coward]

"it provides logically centralized control that will be more deterministic, more efficient and more fault-tolerant."

I'll agree with deterministic and efficient, and perhaps even less likely to fault, but more fault-tolerant seems like a stretch. SDN might get you better fault-tolerance, but that is not because the control is centralized. I suspect the control has more information about non-local requirements and loads, and that can get you better responses to faults. That happens because the controllers can communicate more complex information easier, since that is pure software, not because its centralized. You can have these fault tolerance gains via non-centralized SDN too.

Re:centralized = fault-tolerant?

[bbn]

Compare it to the alternative such as the good old spanning tree protocol. You have a number of independent agents who together have to decide how to react to a fault. This is complex and requires clever algorithms that can deal with timing issues and what not.

With a centralised controller the problem is much easier. One program running on one CPU decides how to reconfigure the network. This can be faster and possibly find a better solution.

Of course you need redundant controllers and redundant paths to the controllers. Apparently Google decided you need a controller per location.

Re:centralized = fault-tolerant?

[bill_mcgonigle]

With a centralised controller the problem is much easier. One program running on one CPU decides how to reconfigure the network. This can be faster and possibly find a better solution.

I can see how centralizing the control can be easier. But if the history of Internet networking has taught us anything, we should expect somebody to come up with a more clever distributed algorithm (perhaps building on OpenFlow) that will make SDN's a footnote in history while the problem gets distributed out to the network nodes again, making it more resilient.

That's not to say that trading off resiliency for performance today isn't worthwhile in some applications.

How can you have a software defined network?

[Viol8]

A network is physical infrastructure - software isn't going to be rerouting cables or installing new wifi nodes anytime soon.

If all they mean is routing tables are dynamically updated then how is this anything new?

This isn't a troll, I genuinely don't see where the breakthrough is.

Re:How can you have a software defined network?

[DarkOx]

Its not what they are doing here exactly but there is not reason you can't have a logical topology over top of a physical one. Actually its very useful, especially when combined with a virtual machine infrastructure. Perhaps you want to have two machines in separate data-centers to participate in software NLB they need network adjacency, for example, yet I doubt you want a continuous layer two link stretched across the country. Sure if its just two DCs maybe a leased line between them will work, what if you have sites all over the place and potentially want to migrate the hosts to any of them at any time? That would allow for maintenance at a facility, or perhaps you power on facilities during off peak local electrical use, and migrate your compute there?

People are doing these things today but once you get beyond a singe VM host cluster it gets pretty manual. With admins doing lots of work to make sure all the networks are available where they need to be hard coded GRE tunnels, persistent ethernet over IP bridges, etc. They all tend to be static, minimal overhead when not in use sure, but overhead and larger attack surface non the less. A really good soup to nuts SDN might make the idea of LAN and WAN as separate entities an anarchism. Being able to have layer two topology automatic wherever needed would be very cool.

Re:How can you have a software defined network?

[bbn]

There is no routing as such. For each new "flow" the switch needs to ask a computer (controller) what to do. The controller will then program the switch with instructions for the new flow.

You claim that the flow table is just a glorified routing table. Maybe it is but much more fine grained, you can match on any fields in the IP packets, including layer 2 and 3 such as MAC, IP, port numbers, IP TCP packet types (syn packets) etc. Also you can mangle the packets, for example modify the MAC or IP address before forwarding the packet.

With this you can build some amazing things. The switch can be really dumb and yet it can do full BGP routing: RouteFlow: https://sites.google.com/site/routeflow/

The other canonical use case is virtualisation. No it will not be rerouting physical cables. But it can pretend to do so. Combine it with VMs you can have a virtual network that can change at any time. If you migrate a VM to another location, the network will automatically adapt. And still the switches are dumb. All the magic is in the controllers.

Before OpenFlow you would need to make a vlan (or MPLS). When moving the VM to a new location, you would need to reconfigure a number of switches to pass around this vlan and there is no standard protocol to do so.

OpenVSwitch supports OpenFlow so you can pretend your virtual network with virtual switches includes the VM host itself: http://openvswitch.org/

Re:How can you have a software defined network?

[swb]

Sometimes it seems that SDN is just a new dress on an old pig, sometimes it starts to make sense.

When I'm feeling enlightened or charitable about the concept I envision it as an encapsulation system for layer 2 on layer 3, allowing layer 2 networks to be created independent of the physical constraints of actual layer 1/2 topologies.

I imagine the goal is to define a layer 2 switching domain (ports, VLANs, etc) and connect systems to it regardless of how the systems are physically connected or even located. This all seems fine and dandy -- draw a network diagram, connect systems, voila!, you have a SDN.

But when you start to actually think about it seems kind of problematic...

It seems hard to separate SDN implementation from virtualization, though. If I have a SDN, how do I connect VMs to it if the SDN isn't part of the virtualization environment? Do you install a virtual network adapter in your OS to configure SDN network membership?

Or is it a switch-level system? I feel somewhat less enthusiastic about this as a concept as it just seems like more configuration for the same basic product (VLAN or VLAN trunk membership), with benefits only to really the largest and most complex networks with maximum bandwidth trying to re-solve problems sort of already solved other ways (like LAN bridging over WAN links).

Since encapsulation appears to me to be an inherent part of it, I also worry about performance but I suppose everyone in the SDN world are go-fast, low drag operators on fully meshed, aggregated 10 gig ethernet end-to-end and doesn't care about encapsulation penalties.

And then there's my inherent skepticism about the value payoff relative to the level of complexity added, as well as asking isn't that why we have layer 3 protocols? To define networks above and beyond their layer 2 memberships?

Re:How can you have a software defined network?

[swillden]

Translation: Google Big.

Yep. And there comes a point when you're scaling up that quantitative differences become qualitative differences that demand completely different solutions to the old problems.

Translation: Firmware Is Magic.

No, firmware is static, and the code it contains must fit in limited capacity storage devices and run on low-end CPUs, unless you want to pay big money for your switches. Much better to make the switch firmware simple and the switches cheap, and put your logic in a few much more powerful machines with visibility into the bigger picture.