Editor Note:  Harry Quakenboss is CEO of Cplane and Guest Blogger on SDxCentral.

A few weeks ago David Lenrow wrote a blog at SDN Central entitled “Who is going to finish the SDN controller?” David made an important point about several missing capabilities from the array of available OpenFlow Controllers, and also about the lack of automated development tools.

But I thought it was such a great title, I paraphrased it into:  "Who is going to invent the OpenFlow Microcontroller?"

So what’s an OpenFlow Microcontroller?

In order to answer that question, think for a moment about the Mars Rover. It’s a long way from home, yet it gives us pictures as if it were, say, in the Mohave Desert instead of on another planet. Not only that, we can make it go forward, backward, steer right or left, control the focus of the camera, and so on. How does the camera focusing mechanism work anyway? I don’t know, but here is a guess. The wireless control link between the controller on earth, and the Mars Rover makes almost any network link on earth seem like a low latency connection. It is in the neighborhood of ten minutes. Instead of sending the signal back to earth, doing a calculation, and sending the lens control commands to Mars, I am there is probably a feedback control loop right on the Mars Rover, likely not much different from an autofocus camera which handles the focus (we could call it “reconfiguration”) of the camera lens.

Now let’s talk about a simple OpenFlow firewall application: 100 Gbps firewall pipe that aggregates traffic from all over the world, and makes decisions on the fly of whether to block or pass traffic. With today’s OpenFlow Controllers, the latency of the path from the embedded OpenFlow Protocol in our firewall, starting with the TCP/IP protocol stack in the firewall, through the control/management plane switch network, up through the IP protocol stack in the OpenFlow Controller, plus the latency of the return path, could be tens to hundreds of milliseconds, not even counting the time spent on our “Software-Defined Networking” network service on the OpenFlow Controller that decides what to do with each new flow based on the firewall rules. At 100 Gbps, a lot of either good or very bad data will be blocked or passed before the firewall rules can be enforced.

You might say this is as dumb as trying to focus the camera on the Mars Rover by running the focusing algorithm at the base station on earth.

So what’s the answer? I have listened to OpenFlow naysayers say “Here’s yet another good reason not to use OpenFlow”.

Somebody else might say, “What we need is a cache!” But this is more than just a cache, because there are programmatic tasks to be executed.

Another might say, “Preload the tables in the firewall device.” But if that’s the solution, why are we bothering with OpenFlow?

Another answer we expect to see is a small-footprint OpenFlow Controller that runs right on the firewall device. In other words, an OpenFlow Microcontroller.

But wait, you say. Now we are back to where we started with the code embedded in the firewall device, which is what we are trying to get away from. Maybe not. It would be pretty easy with the coming generation of embedded processors to use a hypervisor, and have the OpenFlow Microcontroller run in its own VM, isolated from the embedded software so it can’t mess up the core switch functions if it runs amok, and greatly reducing the likelihood it will interfere with the time-critical bits in the embedded software.

There you have it. The OpenFlow Microcontroller.

While the firewall example might seem like a corner case use for OpenFlow, there are many situations where it will be important to respond to incoming flows with lower latency than the typical round trip time between the switch and the OpenFlow Controller. One area that has not received much attention is handling congestion, both inside data centers and across WAN networks. Whether it involves something as simple as detecting congestion and issuing PAUSE commands, or more sophisticated techniques, this could be a problem for OpenFlow. These events can be very short duration, often measured in a few milliseconds, which is problematic for a separate OpenFlow Controller to handle.

Oh yes. There is one important consequence of doing this. With a lot of devices each with their own OpenFlow Microcontroller, there is going to be a need for some kind of Master OpenFlow Controller, with a requirement for data synchronization across devices, and many other details.

But that’s a topic for another day.