OpenFlow Driver Contest Takeaways

Will the Software-Defined Networking world finally obtain its dream middleware – the OpenFlow Driver? Participants of OpenFlow Driver Contest might know the answer.

On April 16, 2013, the Open Networking Foundation started a contest for the best Open Flow Driver. Any person or group of persons over 18 years old from all over the globe could qualify for this 4-month competition, the main purpose of which was developing universal open source OpenFlow middleware. When we got to know about the contest, it was already on for two months; and since the time machine hasn’t been invented yet (we’re working on that actually ), we decided to participate anyway and see where we can get with this. As it turns out, we can get quite far.

What, who, and why

Briefly speaking about the contest requirements, the driver in question is purposed for “translating” communication between network controllers on one side, and devices with different OpenFlow versions installed on them, on the other side. This is especially relevant for heterogeneous networks, where some devices are say OpenFlow 1.1, and some are 1.3. Constant competition of the companies and all those hasty attempts to bring device to the market fostered the diversity in supported OpenFlow versions. As a result controllers as well as system administrators will have to deal with great variety of protocol versions in mixed SDN environments.

To prevent this from happening, the OpenFlow driver must serve as a bridge, making controllers and devices of different generations “understand” each other. Apart from the “translating” function, the OpenFlow driver shall by all means provide basis for further solutions and implementations in the Software Defined Networking field. More requirement details can be found in the contest Terms and Conditions.

Working out the challenges

With the goal set, our team immediately set about untangling the OpenFlow Driver puzzle. First of all, it was quite challenging to put OpenFlow messaging for different versions under common umbrella of unified API, and then to export the interface into the environment of popular languages used for Controllers (Python, Java, C). On the other hand, our software library is written in C++ and thus can be easily installed both on Controller (Linux server) side and OpenFlow switch (embedded Linux). C++ language helped us to keep small memory footprint and reach high performance results.

Our work accentuated on modular structure of the library which provides flexibility in adapting the OF Driver to the needs of a specific environment, as well as ensures high scalability and universality. On the whole, there are following abstraction levels which serve as the basis of the modular structure:

• OpenFlow Abstraction;
• Operating System Abstraction;
• Transport Layer Abstraction (eg., TCP, TLS, UDP, DTLS);
• Programming Language Abstraction

OF Driver abstraction model

When the contest came to its end, we submitted our then-modest contribution, which has now become a fully evolved solution for facilitating SDN southbound interface implementation. From the very beginning we realized that we would probably achieve our goal beyond the contest timeframe, but participating in it was certainly fun. Events like OF driver contest are vital for keeping the Networking world in tune, and still more important for the advancement of Networking technologies.