OpenFlow may be one of the hotter buzzwords in bleeding-edge networking technologies these days, but getting past the emotional exuberance and down to brass tacks in this area can be difficult. Why? First,the OpenFlow protocol is a sort of infrastructure-of-infrastructure that can be applied many places. Second, OpenFlow continues to pop up in new contexts as the ecosystem around the technology expands. This is a story of an engineering achievement built to solve one problem that has become the root of a veritable family tree of solutions for problems in the networking space.
How OpenFlow got here
If you look at the OpenFlow v1.0 spec – a scant 27-page-long document – it isn’t immediately obvious that this is going to be useful, much less revolutionary. At its most basic level, OpenFlow is a protocol for server software (a “controller”) to send instructions to OpenFlow-enabled switches, where these instructions give direct control over how those switches forward traffic through the network.
I think of OpenFlow like an x86 instruction set for the network – it’s low-level, but it’s very powerful. Continuing that analogy, if you read the x86 instruction set for the first time, you might walk away thinking it could be useful if you need to build a fancy calculator, but using it to build Linux, Apache, Microsoft Word or World of Warcraft wouldn’t exactly be obvious. Ditto for OpenFlow. It isn’t the protocol that is interesting by itself, but rather all of the layers of software that are starting to emerge on top of it, similar to the emergence of operating systems, development environments, middleware and applications on top of x86.
The evolution of OpenFlow … for now.
From where I sit, OpenFlow got its first traction outside of academia in the super-large data centers of companies trying to solve really big data problems. Several years ago, these teams were faced with the daunting task of building a network for map-reduce/Hadoop clusters that could scale to the hundreds of thousands of servers.
Full cross-sectional bandwidth is a must-have requirement for these big data applications, and it doesn’t take much back-of-the-envelope calculating to come to the conclusion that a tree-based architecture will require throughput on core switches/routers that simply can’t be bought at any price right now. Furthermore, the networks in these clusters are no longer so cleanly distinguishable from the application software. Instead, they are just one component in an overall big, big data system, and they need programmatic interfaces that play nicely with other parts of the system. From these early efforts to support big data apps came a new generation of non-tree architectures, all closely tied to concepts that we see in OpenFlow such as flexible forwarding and the ability to really program the network to meet specific application needs.
R&D in this area started in earnest a few years ago – roughly coinciding with the formation of the first few OpenFlow startups and the beginnings of the academia-meets-industry Tuesday OpenFlow meetings back at Stanford. Motivated by the big data problem, that group planted the seeds of the OpenFlow protocol. With the Open Networking Foundation forming this year and talk of large-scale production builds underway, these seeds are starting to bear (commercial) fruit.
OpenFlow goes webscale and then to the cloud
As with many scientific achievements, solving this massive-scale big data problem has generated solutions to many related problems. For example, large-scale public Infrastructure-as-a-Service (IaaS) cloud providers realized this new network architecture better serves their needs. However, there were still some unaddressed problems, such as needing to isolate each customer/tenant into its own network.
Nick McKeown, who helped develop OpenFlow at Stanford.
Further, each tenant is constantly submitting requests to add/remove VMs, and servicing these dynamic requests often requires spreading VMs all throughout a data center and then trying to move them back closer to each other. Solving these problems requires some very fancy and often custom Layer 2 and Layer 3 gymnastics — new problems to solve, and OpenFlow turns out to be a great fit there because it allows the network designers to more easily deploy the custom forwarding policy they need across the portions of the network that need it.
Who knows what tomorrow will bring
That brings us up to the R&D happening today where we see a new branch of OpenFlow solutions emerging in trials for private IaaS clouds. While not ‘multi-tenant’ in quite the same sense as the public clouds, these deployments have a lot of issues in common with public clouds. The cross-section bandwidth problem still exists, of course, but now the virtualization, isolation, delegated administration and co-existence with classic network architectures have become key problems to solve. OpenFlow allows the network to be programmed directly to solve these problems with the same speed that IaaS providers have become accustomed to with server virtualization.
Are there more of these branches of the OpenFlow family tree blossoming? Of course. One short blog post is not quite enough to talk about OpenFlow in the campus LAN environment starting to get traction in some of the original research universities or the early interest in OpenFlow as “the new stackable” for small/medium business networking. I’ll leave those for future posts.
Net-net, is OpenFlow going to be useful? Absolutely yes. What is it going to be used for? I don’t think that there is any one answer, but rather a family tree that is growing new branches, blossoming and bearing new fruit as we speak.
Kyle Forster is the VP of sales and marketing and co-founder of BigSwitch Networks.
Image courtesy of Flickr user flickrohit.
Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.
- Infrastructure Q1: IaaS Comes Down to Earth; Big Data Takes Flight
- Infrastructure Overview, Q2 2010
- Infrastructure Q2: Big data and PaaS gain more momentum
