Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Crossroads for OpenFlow?

Ethan Banks | Jan. 8, 2016
Does OpenFlow have a significant role to play in SDN, long-term?

In SDN’s early days, possibility abounded. The thought of what could be excited practitioners and tantalized developers. OpenFlow was an early SDN star, a proof of concept from Stanford that demonstrated a new way to program a network. Many even conflated SDN and OpenFlow, as if one could not exist without the other.

That’s not the case, but early in the SDN hype cycle, it was an understandable perception. OpenFlow progressed quickly, as the Open Networking Foundation drove OpenFlow development ahead, publishing several iterations of the OpenFlow specification in rapid succession.

Lately, OpenFlow progress seems to have stalled. Industry fervor over OpenFlow has quieted. ONF releases of major OpenFlow specifications have slowed. Vendors making SDN announcements don’t emphasize OpenFlow terribly much these days.

SDN has created an industry of its own with several classes of products, some of which don’t leverage OpenFlow at all. At the spring 2015 Open Networking User Group meeting in NYC, OpenFlow was not a major topic of discussion. Some vendors have shown little interest in, and even an aversion to, adding OpenFlow support to their products — notably Cisco and Juniper. While others, like HP and Brocade, have made OpenFlow an important part of their ecosystem.

OpenFlow seems to be at a crossroads. Depending on your point of view, this might seem surprising, and it leads to a question: Does OpenFlow have a significant role to play in SDN, long-term?

The answer to that question lies in understanding what OpenFlow is really for. OpenFlow is simply a tool for programming forwarding tables in network devices.
But … that’s it.  OpenFlow is simply a tool. That said, don’t sell OpenFlow short. OpenFlow may be a tool, but it is both a useful and powerful tool. OpenFlow is compelling in that it offers the following:

  • A standardized interface that abstracts vendor-specific hardware away. A controller that speaks OpenFlow should be able to
    program a device that supports OpenFlow.
  • A means to program the network centrally.
  • An easy way to do “exception programming,” the handling of unusual traffic flows that cannot follow the normal best path through the network.

Those who keep up with OpenFlow’s use will rightly point out that OpenFlow isn’t exactly standardized, in the sense that some vendors have extended OpenFlow to give it additional capabilities. This is true, but it’s worth pointing out that vendors (including Big Switch, NEC, and VMware) are working with the ONF to bake these extensions into standard OpenFlow. This process is similar to how other vendors have handled proprietary extensions to standards in the past. It seems unlikely that the industry will fracture when it comes to OpenFlow. Vendors using OpenFlow are trying to stay on the same page as their industry peers.

 

1  2  3  4  Next Page 

Sign up for CIO Asia eNewsletters.