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.
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.
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.