OpenFlow: Proactive vs Reactive Flows

OpenFlow: Proactive vs Reactive Flows

Bad Decision1

OpenFlow: Proactive vs Reactive

As more people begin entering the Software Defined Networking conversation, there is still only one wire protocol that has a reasonably good chance at becoming the de-facto open SDN southbound messaging standard, OpenFlow. There is quite a bit of debate around whether or not OpenFlow can scale. Most claims that OpenFlow does not scale are probably grounded in misconception. That is not to say we do not have a long way to go, but spending the next 5-10 years debating a hardware abstraction layer would be counterproductive in the face of unmanageable networks, with exponential growth occurring annually. As forwarding abstractions in hardware continue to become more flexible, the scale debate should not be whether OpenFlow can scale as a messaging protocol, but be focused on when and if to use reactive flow based rules as opposed to proactive instantiation.

Recap of Why OpenFlow is Important

Today we have switches that operate at L2, routers that operate at L3 and firewalls that operate at L4. Some of those functions are blended together in purpose-built hardware such L3 switches. An access-list is a common function that uses TCAM (ternary content addressable memory) to have the flexibility to match on various layers of a packets L2-L4 headers. That TCAM memory has the ability to match (0), not match(1) (the binary is counterintuitive there) or not care (wildcard). Each field or tuple is searched in parallel all in one clock cycle. So, very quickly and at “line rate” in hardware.

OpenFlow TCAM

Figure 1. TCAM matching

The simplicity of OpenFlow is it was merely a mechanism to exploit TCAM tables in existing vendor switches in order instantiate whatever flows a programmer wants to push. Now with OpenFlow, one can tell a switch to match on any field and apply an action. For network operators and engineers this is policy based routing, on steroids. We can decouple logic and push a set of flow policy from off board the switch, through a TCP socket, using a structured messaging protocol to describe the policy and flow rules to put in TCAM.

OpenFlow Proactive vs. Reactive

When using OpenFlow to populate TCAM in switches there are essentially three modes of operation:

  1. Reactive flow instantiation – When a new flow comes into the switch, the OpenFlow agent SW on the switch, does a lookup in the flow tables, either in a search ASIC if in hardware or a software flow table in the case of a vSwitch. If no match for the flow is found, the switch creates an OFP packet-in packet and fires it off to the controller for instructions. Reactive mode reacts to traffic, consults the OpenFlow controller and creates a rule in the flow table based on the instruction. The problem with reactive is today’s hardware has laughable amounts of CPU in it. Think iPhone 5 or PowerPC circa 2001 amount. That little guy then must do a DMA copy to replicate and encapsulate the packet. HW switches outside of NPUs or general purpose CPU vSwitches don’t do this over a few thousand packet per second. Most in the hundred and some in the 10’s from some rather large expensive chassis.
  2. Proactive flow instantiation – Rather than reacting to a packet, an OpenFlow controller could populate the flow tables ahead of time for all traffic matches that could come into the switch. Think of a typical routing table today. You have longest prefix matching that will match the most granular route to a destination prefix in a prefix tree lookup. By pre-defining all of your flows and actions ahead of time in the switches flow tables, the packet-in event never occurs. The result is all packets are forwarded at line rate, if the flow table is in TCAM, by merely doing a flow lookup in the switches flow tables. That is the same hardware that populates its forwarding tables today from “routing by rumor” in todays routing protocols and “flood and spray” layer2 learning standards. Proactive OpenFlow flow tables eliminates any latency induced by consulting a controller on every flow.
  3. Hybrid flow instantiation – A combination of both would allow for flexibility of reactive for particular sets a granular traffic control that while still preserving low-latency forwarding for the rest of your traffic. Low-latency financial markets operate in the nano seconds, that would not be a good place for reactive forwarding today but granular security in an enterprise would possibly be reasonable if the policy was important.


There are several proactive flow based products with proprietary protocols that have been around for a while. Hearing arguments that one scales, while OpenFlow doesn’t is misleading. Rules in TCAM perform the exact same regardless of the method of instantiation. The majority of early OpenFlow deployments (at least ones I am designing) are going to be almost all proactive combined with granular selections of traffic for specific use cases being reactive. This is not to say there will never be a place for reactive forwarding with solid performance, but I think that will come in the form of embedded systems and more hardware distribution at the edge. All networks are not low-latency trading floors and Hadoop racks in data centers. I cannot tell the difference when I am surfing the Internet on a fully centralized wireless controller, to when I am wired in at 1Gb. The human brain does not register microseconds.

As the disruption that SDN represents to the way we have always done networking continues, those who prefer todays primitives over programmatic abstraction will make claims that SDN, OpenFlow and flow based forwarding doesn’t scale. Ask them if the proactive access-lists in their networking hardware TCAM today scale, or if their proactive QOS policies implemented in their networking gears TCAM operate at line rate. OpenFlow is not grounded in reactive flow policy, but a protocol to exploit TCAM tables for programmatic L2-L4 forwarding flexibility, nothing more. The value will be in abstraction layers, services and applications.

Additional Resources
OpenFlow: Design Considerations Series
Part 1 OpenFlow: Proactive vs. Reactive
Part 2 OpenFlow: Course vs. Fine Flows
Part 3 OpenFlow: Hybrid Deployments
Part 4 OpenFlow: SDN Looking Ahead (Pending)

For additional insight into how the forwarding abstractions are being adjusted to be more than just TCAM take a listen to this podcast with Curt Beckmann of the ONF discuss his work as the chairman of the forwarding abstraction working group (FAWG).

Thanks for stopping by!

About the Author

Brent SalisburyI have over 15 years of experience wearing various hats from, network engineer, architect, devops and software engineer. I currently have the pleasure of working at the company that develops my favorite software I have ever used, Docker. My comments here are my personal thoughts and opinions. More at Brent's BioView all posts by Brent Salisbury →

1 year 8 months ago

Hi there! Quick question that’s completely off topic. Do you know
how to make your site mobile friendly? My site looks weird when browsing from my iphone.
I’m trying to find a theme or plugin that might be able to resolve this problem.
If you have any recommendations, please share. Appreciate it!

2 years 3 months ago

All large purchases are always intimidating, especially if you
are uninformed about the industry. One of the scariest purchases is buying cars.
Many people fear they are getting ripped off and you surely don’t want that. Avoid buying a lemon by looking through these great tips and tricks regarding car purchases.

2 years 8 months ago


While I totally agree with you, please do keep in mind that:

A) some of the more popular open-source OF controllers use reactive mode (ex: Floodlight);
B) per-flow session state in the network core (or in TCAM entries) will never scale (ex: Intserv);
C) number of TCAM entries in typical ToR switch is severely limited. Large TCAM, wire-speed forwarding, low-price: you get at most two out of three (usually you don’t even get two).
D) TCAM update rate in current hardware OF switches is ridiculously low, further limiting the usability of reactive or hybrid models.

Until the OF aficionados admit there are lessons to be learned from the last 30+ years of networking failures (including numerous scalability failures, many of them caused by per-session state in network core), we won’t be moving anywhere.

Fortunately at least some of the thought leaders figured out MPLS designers were not overly stupid 😉 (see


2 years 8 months ago

IMO the real scalability issue is the number of entries. Some controllers create one entry per host and some create 1,000 entries per host. How big is your TCAM?