To really understand Software Defined Networks (SDNs), we need to start from a place far different than the top of the current hype cycle. Instead, where we need to start is thinking about what a control plane actually does in a packet switched network. There seem to be just a few specific things involved in what a control plane does:

• Find the reachable destinations (discover reachability)
• Find the shortest path to any given destination in the network (discover topology)
• React to changes in the topology (automated reroute until repair)
• Move traffic around to more efficiently use the network and/or support application requirements (traffic engineering)

While there are some bits that seem to overlap, if we ignore the “hard cases” to build an initial definition, there are two general realms of “things to do.” The first is discovering reachability, and the second is modifying the discovered reachability for some reason. The second could be considered “outside the control plane,” really more of a “management” function, but it’s actually not so easy to pull the shaping of traffic out of the control plane in this way for several reasons.

First, shaping how traffic flows across the network is intimately tied to the metrics used in calculating the shortest path (and even in re-routing in the case of failures). Second, the data contained in the control plane, specifically forwarding information, is ephemeral, which means it isn’t carried across reboots (static routes included, as a static route is really just a configuration telling a process to insert a bit of ephemeral data into the right tables, it’s not the ephemeral data itself).

Splitting the control plane up in this way helps us understand how to understand what various flavors and options there are out there in the realm of SDNs. For instance, OpenFlow replaces the distributed computation of topology, reachability, reroute, and traffic engineering into a centralized controller. Other SDN proposals do something less than this.

In trying to understand and classify the concept of an SDN, it’s also important to have a mental model of how a networking device actually works. The illustration below might be useful in this regard.

This is not, of course, a complete model of a forwarding device—but it does show most of the bits we’re interested in to understand SDNs. Some explanation is probably in order:

• Configuration is the set of parameters that tell the processes where to learn information and how to interact with the other components of the system. For instance, a routing protocol’s configuration might include which interfaces the protocol should run on, or which other routers the protocol should attempt to form a neighbor relationship with, etc. This information would also include “static” routes, which are just routes a local process reads and creates state from.
• Processes is the set of routing protocol and other processes that collaborate through, and supply information to, the RIB. This might include an Open Shortest Path First (OSPF) process.
• The Routing Information Base (RIB) contains the set of reachable destinations in the network, and enough information about the network’s topology to provide information on how to forward any particular packet the device receives. The RIB is primarily designed for interaction with routing processes, rather than the actual forwarding hardware.
• The Forwarding Information Base (FIB) serves roughly the same purpose as the RIB, only it’s formatted to interact with the actual hardware forwarding received packets.

There may seem to be a fine line between the RIB and the FIB, but there’s really a huge difference. Each table models the data used to forward traffic differently, for instance. The RIB contains information about which process installed the reachability information, while the FIB contains information about the relationship between sets of routes the RIB doesn’t.

These two foundational concepts—the purpose of a control plane and the grounding model of how a router works—can be used to slice and dice SDNs. You’ll have to wait ‘til next time to understand how, though.