One of the more popular misconceptions about SDN is that this new model of networking moves the control plane from a device to a controller.  As much as it sounds like a network controller would be the control plane for a network, it simply isn’t true.  For some, I believe this mistake is simply a lack of attention to terminology.  For others, it’s a fundamental misunderstanding of the way that controller based networking works.  Either way, it’s important that we, as network engineers, understand the concept as we move into the brave new world of orchestrated networks.

Before diving in to how SDN is changing the way your network works, we need to have a common understanding of the different levels, or planes, in your network.  There are others that have been defined, but for the purposes of this conversation these three are the important ones.

  • Data Plane:  This is the physical path that a frame or packet takes while traversing the network.  It includes SFPs, interfaces, ASICs, internal fabrics, etc…  These are the purpose built networking components of a switch or a router.
  • Control Plane:  This is the part of the switch or router that decides how to move frames and packets to their destinations.  The processor on a network device is usually the central arbiter of the control plane, distributing instruction sets to the data plane for how to move packets effectively.
  • Management Plane:  This is the part of the network that a network engineer is going to be interacting with.  Traditionally this has been a CLI or a GUI that exists on the device for the purposes of being able to program the control plane to match the intent of your network design.

The Problem

So what’s the big deal?  Adding a controller to your network is moving the control plane to a centralized device, right?  Not really.  The control plane is the logic center of any network device.  It is the place where decisions get made about how to forward traffic.  Those decisions are then given directly to the data plane to carry out.  In SDN networks this does not change. Each and every device retains its own control plane and programs the individual data planes directly.  If we removed the control plane from the device, the controller would be responsible for directly programming FIBs, managing TCAM, etc… 

Why does it matter?  There are two main reasons.  First, removing the control plane from individual devices would make all of them fully dependent on the centralized controller.  If that controller were to go down, or become unavailable for any reason, the network would cease to function.  As it is, with localized control planes, a network would be able to continue on without controller availability but would be unable to facilitate any changes to traffic flows.  Second, it would be wildly inefficient.  The processors on networking devices are constantly working at managing all sorts of things.  Adding latency for centralized control would slow this management down considerably.  It’s been tried.  It doesn’t work well.

What Does SDN Change

Ultimately, an SDN controller orchestrates each of the independent control planes of your network devices to act in unison.  Is the controller making decisions about who can talk to who?  Absolutely.  However, it is not directly telling your network devices how to carry out that plan.  Instead, the controller feeds each networking device’s control plane with the information it needs to forward as desired, and the localized control plane translates that into a data plane instruction set that matches the provided intent.  This means each and every device, when presented with a frame or packet, is making a wholly internalized decision about how to forward it, utilizing the centralized view of the network that it has received from the controller.

So what has moved?  Well the management plane has moved.  In an orchestrated network, we shouldn’t be managing each device individually.  We will program the controller with our intent, the controller will then translate that to each of the networking devices control planes, which then program the data plane to act accordingly.  Many solutions leave a reduced management interface on the device for simple troubleshooting, but configuration of policy will always be done at the controller.

Final Thoughts

Whether in the datacenter or the WAN, centrally orchestrated networks are going to be playing a larger role in our environments.  Understanding how this orchestration changes things is the best way to understand how you can leverage it to improve the overall performance of your network.  I know it can feel a bit pedantic to nit-pick on control plane vs management plane, but the distinction matters and it is an important one to understand.

CloudGenix is one of the sponsor companies presenting at Network Field Day 9. They are the very definition of a startup being less than 2 years old and coming out of stealth mode in April of 2014. The founders of the company are all former colleagues from Cisco.

The Product: Well, that’s an interesting question as there isn’t much information out there about it. Their website claims that they are developing a SDN solution for the WAN that is currently in private beta. I couldn’t find anything online that showed any technical description beyond the typical flowery wording about mapping business process/priority to network traffic flows.

SDN WAN technology is very interesting to me as I believe it is likely going to be the real driver for mass adoption of SDN. Most of the hype around SDN has had a focus in the datacenter, supporting large and complicated implementations of cloud or distributed applications. SDN in the datacenter is solving many problems that large organizations are having, but most mid-tier organizations just aren’t fighting those same battles. However, just about every organization I have encountered has had to make decisions around routing, security, resiliency and prioritization of their WAN circuits. Any technology that makes this process easier, and is capable of mapping business objectives to technical implementation, has the potential to be a catalyst of change in how WANs are deployed.

Conclusion: CloudGenix has the potential to be a very interesting product but with so little information out there about them it’s hard to tell. I imagine their presentation at NFD9 has the potential to be something that leaves us excited about the possibilities but there are just too many question marks to have a solid opinion going in. Either way, I am looking forward to hearing more about what CloudGenix is working on.