Management, Control, and What?
In the last post on SDNs, I spent a little time discussing just a bare minimum of some internal router architecture—specifically the difference between the RIB and the FIB, and thinking a little about management. In this post, I want to add one more dividing point to the mix, and then start thinking about how we can classify various “software defined” solutions in a way that makes more sense out of the field of options.
First, there is the question of which specific parts of the control plane are centralized, or rather how much of the control plane is centralized. This might seem, at first, to be an odd distinction—the control plane is the control plane, after all, it just builds a set of forwarding entries used to actually switch packets through a network device, right? It’s actually not quite that simple.
Consider these situations:
- A BGP community (say a flowspec community) is used to set the next hop for traffic of a certain protocol to a specific next hop, so the traffic does not follow the shortest path. Is this instruction to change the next hop part of the control plane, because its carried in BGP, or is it part of the management plane, because the modification of the next hop information is actually set up through a policy configured someplace else, and BGP is simply used as a “carrier pigeon?”
- A route map is configured on a particular forwarding device that changes the next hop for traffic matching a particular protocol number to a next hop that is different than the shortest path. Is this a part of the management plane, because it’s a local configuration, or is it a part of the control plane, because it impacts the actual forwarding decision made by the device?
Both of these are hard cases. I happen to believe both of these cases also illustrate why the control plane/management plane is insufficient to actually describe how a network device actually makes decisions, and hence how the network actually works. To make the description of forwarding more complete, I would add in a third “plane,” something I would call the “policy plane.” To go back to these two examples:
- While the base BGP protocol is discovering the topology and reachability needed to build a forwarding table, the policy carried in the protocol—part of the “policy plane—overrides this information. In this case, BGP is acting both as a routing protocol and as a policy carrying mechanism, where the policy is read from data that’s somewhat unrelated to BGP’s original purpose, and implemented as a change to the forwarding table in a specific device.
- While the configuration of the route map is clearly a part of the management plane, the expression of the route map, as it’s applied to the actual routing and forwarding tables, is an expression of the “policy plane,” as it interacts with the forwarding information calculated by the network device.
This idea of a policy plane as a sort of “ephemeral overlay” can be useful for untangling many of the messes we find ourselves in. How can this help us with the software defined thicket? By allowing us to separate the concepts of policy and reachability (and/or topology discovery). To give a concrete example… Suppose you have the small network below—
Now assume you are calculating the route from A to B. The shortest path, of course, is directly between the two routers (assuming all the link metrics are the same). What about that path through C, though?
If that path is used for some traffic as a matter of controlling the bandwidth utilization across the A->B path, this would be policy. It is moving some of the traffic from the shortest path to a longer path in order to better utilize network resources.
If, however, the path through C is used as a backup path for traffic flowing from A to B, this would be a control plane function. Here the path is being used as the shortest path in the case of a topology change.
In short, anything that relates to discovering or reacting to changes in reachability or topology would be consider part of the control plane, while anything that overrides the topology and reachability discovered by the control plane would be considered part of the policy plane. Anything that configures either the control or policy plane so they operate correctly, or from which operational parameters for either is drawn, is part of the management plane.
Okay—so now we have the control and policy planes separated out, and we have the RIB separated from the FIB. Are we eventually going to see how to use all these ideas to understand SDNs better than we do today? Certainly!
Tune in next time for the next post in this series.