It’s easy to say “SDN is the physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices,” handwave over the details, and let someone else figure them out. Implementing that concept in a reliable manner is a totally different undertaking.

2013-12-12: Inserted description of in-band control plane in OVS.

OpenFlow Control Plane 101

In an OpenFlow-based network architecture, the controller (or a cluster of redundant controllers) implements control-plane functionality: discovering the network topology and external endpoints (or adjacent network devices), computing the forwarding entries that have to be installed into individual network devices, and downloading them into controlled network devices using OpenFlow protocol.

OpenFlow is an application-level protocol running on top of TCP (and optionally TLS) – the controller and controlled device are IP hosts using IP connectivity services of some unspecified control plane network. Does that bring back fond memories of SDH/SONET days? It should.

Who Will Build the Control Plane Network?

The answer you’ll get from academic-minded OpenFlow zealots is likely “that’s out of scope, let’s focus on the magic new stuff the separation of control- and data plane brings you.” Pretty useless, right? We need a more detailed answer before we start building OpenFlow-based solutions.

As always, history is our best teacher: similar architectures commonly used out-of-band control-plane networks.

Out-of-Band OpenFlow Control Plane

The easiest (but not necessarily the most cost effective) approach to OpenFlow control plane network is to build a separate network connecting management ports of OpenFlow switches with OpenFlow controller. NEC is using this approach in their ProgrammableFlow solution, as is Juniper in its QFabric architecture. There’s something slightly ironic in this approach: you have to build a traditional L2 or L3 network to control the new gear.

You could (in theory) build another OpenFlow-controlled network to implement control-plane network you need, but you’d quickly end with turtles all the way down.

On the other hand, out-of-band control plane network is safe: we know how to build a robust L3 network with traditional gear, and a controller bug cannot disrupt the control-plane communication. I would definitely use this approach in data center environment, where the costs of implementing a dedicated 1GE control-plane network wouldn’t be prohibitively high.

Would the same approach work in WAN/Service Provider environments? Of course it would – after all, we’ve been using it forever to manage traditional optical gear. Does it make sense? It definitely does if you already have an out-of-band network, less so if someone asks you to build a new one to support their bleeding-edge SDN solution.

In-Band Control Plane

It’s possible (in theory) to get OpenFlow switches working with in-band control plane, but it’s a complex and potentially risky undertaking. To get an understanding of the complexities involved, read the relevant Open vSwitch documentation, which succinctly explains the challenges and the OVS solution.

That solution would work under optimal circumstances on properly configured switches, but would still use an out-of-band control plane in networks with transit OpenFlow-controlled switches (a transit switch being a switch passing control-plane traffic between controller and another switch).

But Google Got It to Work

No, they didn’t. They use OpenFlow within the data center edge to control low-cost fixed-configuration switches they used to implement a large-scale routing device. They still run IS-IS and BGP between data centers, and use something functionally equivalent to PCEP to download centrally computed traffic-engineering tunnels into the data center edge routers.