We’re not selling clothes, after all.
Ivan and I have been tossing emails back and forth about Openflow over the last week (too bad y’all didn’t get to listen in!). He’s really been helping me solidify a lot of things about my thinking in the OpenFlow space, so the conversation has been fun and useful –the best kind.
In the midst of it our exchange, I posited that there are four models for the interaction between control planes and data planes. It seemed worth repeating that part of the thread here, and then putting some text behind it to talk about the concept of models in networking a bit more. So, what are the four models of interaction between the control and data planes in a network?
- Proactive control plane with a proactive data plane, where you know the destinations and you install every possible destination (or some aggregate thereof) into the data plane (forwarding hardware) as the reachability information changes.
- Proactive control plane with a reactive data plane, where you know the destinations at the control plane, and this information changes in near real time with actual topology changes, but you only install forwarding information in the data plane when you need it, like fast cache.
- Reactive control plane with a reactive data plane, where you ask someone else about destinations when you receive the first packet (like LISP and reactive MANET protocols).
- Topology only control plane with a reactive data plane, where you simply flood to everyone when you don’t know about the destination, because the control plane really doesn’t know about destinations, only the topology (like spanning tree). Here the only reachability information is in the data plane (forwarding table).
Working in the mobile ad hoc (MANET) space, combined with some serious work in understand the EIGRP/RIB interfaces in Cisco’s IOS, RIB interaction in XR, and other stuff, really solidified my understanding of the separation between the control and data planes, and the interface between the two. This is the sort of thing that might seem like such a minor detail in the bigger scheme of things, but it actually has a huge impact on the design of security and policy, understanding where protocols will break, and in a hundred other little things you encounter day-to-day.
In a more general sense, models are a bit of a hobby horse of mine, a form of abstraction that are often useful (so long as they don’t consume your thinking). When I run into a new protocol, or a new problem, I instantly think of some model that helps me think about the way things work. It’s a bit theoretical, but it’s also a good exercise in abstraction. As a result, we’re including an entire chapter on network models in the new book I’m co-authoring, The Art of Network Architecture.
The seven layer cake is fun, but it’s a bit long in the tooth, doesn’t really “fit” the world of TCP/IP, nor really all that useful for designing networks (as opposed to protocols). So we’re going beyond the OSI model in the chapter and covering the 4 layer (DoD) model, my own mental model of how networks work, the proactive/reactive model (above), Places in the Network (PINS, which I think are useful for relating business to network, but not really useful for network design), hierarchy (both horizontal/aggregation and vertical/virtualization), and an iterative/recursive model I’ve picked up from some reading a friend recommended. I’m covering another model of network operation, offline calculation and on-line reaction, in the chapter on SDNs, as well.
What model would you like to talk about, or have me put in the models chapter of a new architecture book? Did I miss one you’d really like me to talk about?
And yes, I’ll get back to the series on prepping for the CCDE soon…
About Russ White
