OpenFlow: Proactive vs Reactive Flows

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.

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.

Summary

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

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).

• Packet Pushers: PQ Show 20 –Open Network Foundation – FAWG Update

Thanks for stopping by!