(note: this article was posted originally on Silicon Angle as part of our community outreach)
Is OpenFlow where it needs to be for 2013?
My research firm Router Analysis, Inc. has spent the last week working with both Public and Private (unreleased) products supporting OpenFlow v1.0. The goal of this exercise is to determine what vendors have delivered with regards to OpenFlow in 2012 and build realistic expectations for 2013. We are halfway into our testing phase and thought it was a good time for a testing summary.
Test Preparation
Equipment gathering for the testing started around August. We invited Pica8, HP, Juniper, Cisco and Brocade directly and all other vendors indirectly via twitter, LinkedIn and email. So far only Pica8 has publicly supported the testing. All switches used for testing have come from outside sources via loans or purchases. Router Analysis is using a Pica8 Pronto 3290 and a HP 6200yl both running the latest public code from their respective companies.
Of the five invited companies only three have public hardware and code releases supporting OpenFlow. Cisco and Juniper both have on-going early field trials with specific customers and a lot of NDA paperwork needed to get access to the OpenFlow enabled code.
Pica8 has been the most active in the OpenFlow switch space, supporting many academic, research and open source projects with hardware. HP and Brocade have done their part in marketing and pushing the agenda forwards i.e. keeping the discussions alive and interesting.
The Router Analysis State of OpenFlow 2012 report is slated to come out in early January 2013. The report will be based on OpenFlow 1.0 and the functionality of current hardware. OpenFlow 1.0 is the common version across all vendors. Pica8 supports OpenFlow 1.2 which we will be looking at but only from a research point of view.
What we have determined so far
OpenFlow works well and as expected. All vendors tested have been able to install a reasonable amount of flows i.e. greater than 1000. Each vendor has been tested against both Big Switch Networks open source Floodlight OpenFlow controller and RouteFlow a project that combines the NOX and POX OpenFlow controllers with Quagga and a product called RFServer which propagates routes into the switch forwarding table.
We have seen no issues with any vendors interoperating with either NOX or Floodlight.
The RYU OpenFlow controller which supports OpenFlow 1.2 has been confirmed as working with Pica8’s current PicaOS. For the test we used the reference documents released by Pica8 last week. We have not and do not expect to test the RYU OpenFlow controller against other vendors at this time.
What to expect in the next week of testing
Our goal at Router Analysis is to bring as much information to the public as possible. We don’t expect the report to have a big impact on purchasing decisions as we are not doing a vendor bake-off or competitive test.
In the next week we will be utilizing internal and external tools to generate traffic flows across the switches, confirming that the flows installed in the OpenFlow forwarding table are working correctly. We are also actively pursing vendors in the hopes that we can get at least one more to allow public release of their OpenFlow functionality.
We hope to be able to define a reference hardware/software controller machine which will be usable with different vendors and support multiple controllers. We as a company believe this is an important step towards OpenFlow and SDN adoption. By providing a setup where potential customers can purchase a switch with a controller, some cables and a quick start guide, we believe customers will have a better chance of learning what OpenFlow is and what it can do for their networks.
Summary
OpenFlow is here and functional. It is only one part of the larger Software Defined/Led Networking concept. OpenFlow enabled abstraction between the control plane and the forwarding plane by providing an open protocol.
OpenFlow implementations work on all vendors tested, there are a few caviots with each vendor, but those are to be expected and affect features, not base functionality or stability.
As we see it, OpenFlow is delivering on the promise of programmable networks.
Leave a Reply