One of the fun things about SDxCentral is the opportunity to talk to a wide variety of members in the SDN community. By engaging with traditional and cloud service providers, enterprises, network equipment vendors, labs and software developers, we hear many different points of view, learn a lot about what each constituent is experiencing in the market, their development needs, and their views about how SDN and specifically OpenFlow potentially impact their business.

A common thread that comes up in every discussion is the frustration around the amount of effort and money that every organization invests in tracking and implementing the OpenFlow standard.  Usually the conversation is about how an organization is experimenting with 1.0 (the most common version today), and looking to implement 1.3 (the recently published and frozen version) in the future.  With network equipment vendors and software developers, once in while we hear about 1.1 and 1.2, but generally, we hear is "developing to 1.0 today and planning to implement 1.3 in the future."

We've also heard from vendors that even with example OpenFlow implementations in NOX, Open vSwitch, and other projects, it can still take 90-120 days to implement and test a basic OpenFlow 1.0 agent.

An observation that we've made (and I'm sure others have as well), is the need for a standard OpenFlow library to provide both the agent and controller implementation of the protocol that everyone can utilize in building their SDN stacks. This could save vendors and other implementors significant time and money.

We propose looking at the success of OpenSSL and emulating that model. We're not going to call this OpenOpenFlow (clearly an awkward name), but for the purposes of this post, let's just call it LibOF.

I remember a long time ago when as a software vendor, we had to license the BSAFE library from RSA to implement SSL. The patents eventually expired and along came SSLeay from Eric A. Young and Tim Hudson, which subsequently morphed into OpenSSL. Whenever the question of transport-layer encryption came up, the software development community turned to implement OpenSSL regardless of whether we were working on an open-source project, or a commercial product.
IMHO, some key elements for the success of OpenSSL that we should pay attention to include:

• The library had friendly licensing - Apache license, friendly for both commercial and open-source projects
• It was robust and sufficiently complete - it was more reliable and better than what any individual organization could build with limited resources
• Its development process was relatively transparent and not controlled by any one commercial entity  - Eric and Tim were independent developers focused on building the best SSL library, and when work on SSLeay stopped after Eric and Tim were hired by RSA, the community took over, morphing it into OpenSSL, but keeping the contribution process mostly open and transparent. Key members like Mark Cox, Geoff Thorpe, Ralf Engelschall, Ben Laurie and many others are well known in the security world and many are independent of large commercial vendors. This is not to say that there has been no drama around OpenSSL and related libraries. Some of us will remember the lively Apache-SSL and mod_ssl  discussions. Nevertheless, because everyone felt safe using the library and didn't expect to be held hostage in the future, the uptake was strong and the community was vibrant.
• It became integrated into other key software projects - In the early days, OpenSSL's uptake was driven significantly by deployment of Apache web-servers. If you wanted a secure web server, you either used Apache-SSL or mod_ssl, and you needed OpenSSL to build those modules. Then came OpenSSH, OpenVPN and many more.
• It was written in C - which made porting to embedded platforms possible and helped its uptake
• This happened organically - some core developers saw the need for it and moved on it. They didn't sit around debating what kind of organization was needed or which foundation would be the ideal home for a project like this. When the original developers moved on, the community naturally picked up where the initial stewards left off because they saw value in the open source library.

In addition, the beauty of OpenSSL was that if the client and server both used it (which happened to be case quite often), then interoperability issues became minimal. Any ambiguities in the protocol were simply resolved within the library itself. Certainly, this is not a perfect model, and having one main SSL library creates similar security vulnerabilities across a wide swathe of software, but the focus on one library also ensures there's lots of pairs of eyes on it, and that it gets patched quickly.

What if we did the same for OpenFlow?  Create a reference LibOF, which provides a reference implementation of each version of the OpenFlow protocol that was usable in clients (switches & vSwitches) and servers (controllers & applications).  LibOF would accelerate the time-to-market for open-source projects and commercial vendors. For example, networking vendors building OpenFlow in to switches and vSwitches support could save months of time and effort, in both implementation as well as interoperability testing and bug fixing. Likewise, software vendors building controllers or other applications would reap similar benefits from a common set of libraries, from reduction in time to market, to reduced interoperability problems with every switch or vSwitch.  Just think about the extra millions of dollars in gained productivity that could be applied to Northbound APIs or other high value aspects of SDN!

So, let's take a look at the elements that made SSL successful and map them to LibOF:

• Friendly licensing - Vendors we've spoken to have told us they strongly favor an Apache 2.0 license, friendly for both commercial and open-source projects. Perhaps we take a dual-license approach (like jQuery and other popular projects), adding GPLv2 to allow inclusion in GPL projects as necessary.
• Robust and complete - LibOF would have to support 1.0, 1.1, 1.2 and 1.3, including both controller and agent messages. It would have to be thoroughly tested for correctness and robustness if vendors and developers are going to trust it.
• Independent - Just as OpenSSL was not attached to bigger projects or agendas, the key to LibOF success is a focus on the libraries that everyone can freely use for their physical or virtual switches and controller or OF enabled applications.  Just as OpenSSL development was never dependent on a specific web server release, neither should LibOF be dependent on a controller, vSwitch or embedded switch project.
• Transparent development, not controlled by any one commercial entity  - This will be important to the uptake of such a library. Unless vendors and project leaders trust both the transparency of the process and the openness of LibOF leaders/key contributors, it will not be accepted by the community. For LibOF to succeed, the community cannot be constantly second-guessing the intentions of the LibOF developers.
• Written in embeddable C - Switch vendors have stressed the importance of having the library  in C, and have little dependency on external libraries, to allow embedding in switches and other similar environments.
• Integrated into other software projects - To improve the uptake of LibOF, the project should include higher-level abstraction bindings for more convenient and popular languages like Python, Java and Ruby to acclerate application and controller development. These abstractions could be used to hide underlying complexity and differences between the various versions of the OpenFlow protocols. Now, we know there will always be developers who prefer "pure" native implementation of the protocol rather than load in a C-library into their higher-level languages, and that's fine. Even for them, having this reference implementation will give them a leg up as they write their code.

After LibOF is created, the core team could demonstrate the power of LibOF by integrating it into some of the existing open-source controllers, or even some vSwitches out there, perhaps enabling OF 1.2 or 1.3. Success would be defined by a physical or virtual switch vendors embedding it into their firmware to enable OpenFlow and the development of new standalone OpenFlow apps or controllers that use LibOF as their OpenFlow driver.

To kick this off, a vendor-independent group would have to come together to organize and lead this. There's an argument that networking vendors already working on OpenFlow should contribute to this, and pool their resources to invest in this effort. The timing is now, since most vendors are finishing and refining their 1.0 implementations and are standing at the crossroads deciding what to do next--1.1, 1.2, 1.3? Before everyone spends their dollars recreating the wheel over and over again (or worse, decide that implementing future versions of OpenFlow is not worth the investment), they should come together collectively and build a common library  more cost-effectively.

Collaboration between competing vendors is certainly possible since their differentiation isn't really at this level of the stack anyhow. I'm sure there'll be the usual gamesmanship in trying to align the LibOF design more favorably with each vendor's unique architecture. However, many vendors are now using merchant silicon from Broadcom, Marvell or even Intel/Fulcrum, and so I see that gamesmanship as less of an issue.

There's already a number  of projects today that implement the OpenFlow protocol in various libraries in different languages. And all our favorite controllers and vSwitches have their versions of OpenFlow libraries too, which could be used as a starting point. Or we could take lessons learned from those and build a longer-term architectural foundation for LibOF.

There's many places to start from--all that remains is: who's going to be the Eric A. Young of OpenFlow and go ahead and take the leap, and who else will join to help keep it going?