We’ve moved from models of network protocol operation to a model that sits on the edge between network protocols and network operation at the level where it impacts design. Before moving into pure design models, it’s
important to discuss one aspect of network operation that interacts with both the control and data planes in more detail—the concepts
of reactiveness andproactiveness.
The concept of a reactive control plane is simple to understand in theory: the control plane finds the information required to forward a particular packet only when there is an actual packet to be forwarded. In a proactive control plane, information about every reachable destination is always available at every device that might be on a path toward that destination.
Reactive data planes are a bit more complex to understand, but they essentially always involve a cache of forwarding information of some type.
This cache is updated only when there is a packet presented to the control plane that needs to be forwarded. Proactive data planes are built just like proactive control planes (and require a proactive control plane to build); data plane forwarding tables are built based on information about the state of the network, rather than on traffic flows.
Combining these two concepts, we find there are four models of interaction between control and data planes:
A proactive control plane with a proactive data plane, where every reachable destination within the network is known by every node in the network (note that aggregated routing information still fits this definition) through a routing protocol (or other control plane), and this reachability information is installed in the local forwarding table of every device in the network. An example of this is a
network running OSPF to provide routing information combined with a fully populated forwarding table through Cisco Express Forwarding (CEF).
A proactive control plane with a reactive data plane, where every reachable destination within the network is known by every node in the network through a routing protocol (or other control plane), but forwarding information is installed only when a packet needs to be forwarded to a specific destination. An example of this is a network running OSPF to provide routing information combined with a cached forwarding table, such as Cisco’s fast cache. If a packet to a particular destination is received for which there is no forwarding information, the forwarding process queries the control plane, which knows all reachable destinations, for that
information. The forwarding process will cache information learned from the control plane for some period of time; some caching systems attempt to intelligently decide when forwarding information is no longer needed by examining local traffic patterns.
A reactive control plane with a reactive data plane, where
information about every reachable destination is available on some node someplace in the network, but not on any particular node in the network. When a packet is received for which there is no forwarding information, the forwarding process will query the control plane for information about this destination. The control plane, in turn, queries the other nodes on the network to discover the location of the destination, and then does whatever processing is necessary to find the best path to that destination. The
information discovered through this process is often cached in both the data and control planes until these processes determine it is no longer needed. An example of this type of implementation is the Locator Identifier Separation Protocol (LISP), where the
information required to forward packets is discovered only as packets arrive at some network edge.
A topology only control plane with a reactive data plane, a
variation on a reactive control plane with a reactive data plane. In this type of design, the control plane is only responsible for
building a single loop-free topology that connects all reachable destinations, rather than finding the best path to every reachable destination from every network device. Reachability information is discovered by examining actual traffic flows on the network itself
and is cached by the data plane’s forwarding processes until it is deemed out of date or otherwise not needed. Spanning tree is an example of this type of operation.
Why should a protocol designer or implementer choose one model over another? Why should you, as a network architect, be concerned about which model a specific protocol uses?
Reactive systems can introduce unpredictable and difficult to manage delay and jitter into the network. Although faster reaction times, and more
intelligent caching rules, can reduce the impact of the reaction time in the network, the reaction time will always remain—and because applications don’t know about this reaction time, it’s difficult for them to manage and account for it. Should the first packet’s round-trip time be taken as normal for the connection to a particular destination, or is it just an artifact of a reactive control plane? From the application’s perspective, there’s no way to know.
Reactive systems can, however, reduce the amount of state in any given network device—so long as the reactive control or data plane is properly designed and managed. Reactive state is almost always kept at the host reachability level, rather than the aggregated level. Reactive forwarding devices often must buffer the first few packets in a flow so traffic isn’t dropped while a path to the destination is being discovered through the control plane. These two factors combined often counteract any savings the control plane realizes by keeping less state information at each device.