OpenFlow continues to be a point of discussion when the topic of SDN comes up; even now, 6+ years after it initially came to market. The specification for OpenFlow is now at v1.5+; as published by the Open Networking Foundation (ONF), with rumors of v1.6 coming out sometime in 2016. However, it’s worth noting that the industry has converged on OpenFlow v1.3 and this is what is currently deployed.
There continues to be many use cases that are possible with the inventive functionality that is provided by OpenFlow. And use cases matter. Some of these are well known and deployed, such as the Google B4 Inter-DC backbone, while many other use cases are either not well known or not deployed. I talked about one example of an OpenFlow-enabled use case in a previous blog titled: “SDN-Based Network Analytics is here … Now.”
So, what’s my point? Recently, I have been hearing some uncertainty within the industry about whether OpenFlow will ever be widely deployed and some folks have been openly questioning what OpenFlow is really good for. Hence the title of this blog! I believe some of this misconception comes from the blending and blurring of the OpenFlow-enabled use cases. This led me to write this blog; in hopes of clarifying some of this perceived confusion.
I believe it’s fair to put OpenFlow-enabled use cases into two general buckets: a network transport bucket and a network service bucket.
OpenFlow for Network Transport
The original intent of OpenFlow, as many in the industry continue to perceive, was to provide network transport; in other words, provide the basic plumbing for network connectivity. This basically means you move the control plane intelligence from the routers into a logically centralized controller and let the controller application determine the paths required for network connectivity. Then use OpenFlow to program rules into the network devices that ultimately builds the actual forwarding tables of each network device. While that is an oversimplified description, this is basically how the Google B4 SDN network is built. OpenFlow is used to build the paths that provide network connectivity; although their deployment is clearly much more complex and feature rich than what I’ve described here.
This leads some network engineers to ask the question: “Where are all the other OpenFlow-enabled network transport deployments?”
This is a fair question to ask.
However, that is not the focus of this particular blog. I can cover that question in a future blog. Having said that, Brocade does support this type of network deployment and we have the OpenFlow hardware switches, the SDN controller, and the software application for this type of network transport deployment.
OpenFlow for Network Value Added Service
Using OpenFlow to provide a value-added network service is quite different than using OpenFlow to provide network transport. This distinction is the primary point of this blog. There is more industry traction and practical deployments of using OpenFlow for providing value-added services. OpenFlow solves real network and operational problems; and there are many relevant use cases to demonstrate this.
Let’s start with the basic architecture components that enable value-added network services and then briefly touch on a few deployed use cases. The diagram below shows the basic architecture.
This is an IP hybrid network consisting of routers that also support OpenFlow. Hybrid is a key feature here, but that’s worth another blog in itself.
This is the sFlow collector component, which is integrated with the SDN application.
The SDN application receives sFlow samples from the routers; this provides visibility into the traffic flows in the network. Within the SDN application GUI, the operator inputs flow parameters into profile templates. These flow parameters define which flows are “interesting” to the operator and upon detection of a matching flow, the operator defines which specific action to take. There are also a set of default profiles in the application which identify well-known L3/L4 volumetric attack traffic, such as NTP Reflection DDoS traffic. Once a sFlow sampled traffic flow matches the criteria that is defined in the SDN application profile, then the specified OpenFlow action is taken. This action is taken by sending OpenFlow rules into the hybrid routers.
A few example use cases for this type of solution are targeted toward L3/L4 volumetric traffic. For example, upon a sFlow match of a default or configured DDoS profile, the OpenFlow action that is programmed into the router is a simple “discard” action. This provides an L3/L4 volumetric DDoS attack mitigation service. Another example use case is for per-flow mirroring. For example, an operator may desire to mirror a specific application flow to an analytics device for further inspection. This solution will use a “mirror + normal” action to mirror the flow from the router to an offline device while not interrupting the normal forwarding of the flow through the router.
Or perhaps an operator wants to enforce QoS policies on its edge ingress ports. This solution can push OpenFlow rules into the network edge routers to “meter” (eg. rate-limit) flows on the ingress edge interfaces while also modifying the IP DSCP bits of those flows.
Another example use case is to use this solution to classify flows at the edge of the network into MPLS LSPs. This provides a very granular 12-tuple edge classification policy on the PE routers; with the resulting action being to “redirect” specific flows into a particular traffic-engineered LSP. Oh, and you could combine this classification with an additional “meter” action to provide an admission control function. Think about how powerful this is; to be able to use 12-tuple matching criteria to rate-limit and redirect flows into RSVP-signaled LSPs! High priority traffic goes into the Gold traffic-engineered LSP, medium priority traffic goes into the Silver traffic-engineered LSP, and so on. You get the idea.
These are just a few example use cases where OpenFlow-based SDN is used to provide a real value-added service. These solutions solve real operational problems; they are not theoretical nor academic use cases. Again, use cases matter!
So, back to the question in the title of this blog – OpenFlow: What’s it good for? As described briefly here, OpenFlow solves real operational problems and these types of solutions are deployed. So, OpenFlow is good for plenty of reasons! The interest level and uptick amongst network operators is very high for these innovative SDN solutions. These operators are very keen to use SDN to solve known operational problems and to provide value-added services in an automated and innovative manner.
Well, I hope this blog provides a glimpse into a few examples of how OpenFlow is being used today out in the wild. As usual, please ask questions or provide comments in the comment section of this blog. If you’d like to hear more about a specific SDN use case, please let me know in the comment section and I will do my best to oblige. And stay tuned for further updates in subsequent blogs!