IRIS SDN Controller

The first release of commercial IRIS, IRIS-HiSA is released. IRIS-HiSA focuses on solving the scalability and availability issues of OpenFlow controllers. 

For more detailed information, please contact IRIS-HiSA development team, [email protected] .

This month, have started a project to implement OVSDB protocol, which is specified in RFC 7047. As its first outcome, we have released the project at GitHub and waiting others' responses. 

Currently it only supports list_dbs and get_schema method. Thus, we are anticipating many others' help to make it as a complete OVSDB protocol stack. If you want to join, please refer following URL.

https://github.com/bjlee72/ovsdb

Features:

OpenIRIS v2.0.0 supports Openflow 1.0.1 ~ 1.3.2 based on Loxigen library.

OpenIRIS v2.0.0 supports more than 512 concurrent connections to switches.

OpenIRIS v2.0.0 provides a recovery module from link failures (OFMNetFailover)

OpenIRIS v2.0.0 provides a firewall module (OFMFirewall) which is far enhanced from the original Floodlight 0.90 version.

OpenIRIS v2.0.0 is equipped with a Static Flow Entry Manager (OFMStaticEntryManager) which supports Openflow 1.3 switches.

Tested on

Mininet

OVS

HP and NEC ProgrammableFlow switches

EstiNet-8 Network Emulator

Windows as an OpenIRIS-running platform

Linux (Ubuntu) as an OpenIRIS-running platform

TODO

More documents and tutorials

Today we announce that we've successfully integrated Loxigen-OpenflowJ library with OpenIRIS. The integration is tested with OF 1.0/1.3 switches, and there was no problem identified. You can check the result in the loxigen branch. 

Further, we have measured the OpenIRIS-loxigen performance with cbench (loopback interface was used): The throughput was approximately 500M Flows per second. 

During ONS 2014, we have applied various feedback from users to OpenIRIS and finally have made it stable for OF 1.3 mininet tests. We have used Mininet 2.1.0+ for testing, and the lastest version of ofsoftswitch13 stack from CqPD. Beware not to use older version of Mininet and ofsoftswitch13, because the soft switches that they create crash while applying FlowMod records for various flows simultaneously.

And here come several news from ONS 2014: Floodlight announced Open Networking Linux (ONL), and Indigo 2.0 integrated with Broadcom switches, through the API 'OF-DPA' version 1.0. They have also announced that they will soon announce the next version of Floodlight that supports OF 1.3 specification using Loxigen. 

IRIS Developer Workshop was successfully held, at INTERCITY hotel located at Daejeon, Republic of Korea. In this workshop, we have presented the detail of IRIS project and the guides that developers should follow. Use cases of applying IRIS in research and real networking environment was also presented. 

Valuable discussions was also made, including the performance of IRIS. During the discussion, we have identified that the CPU usage of IRIS was mysteriously high in some of the developer's desktop, and found there was one (hopefully) 'final' bug in the ClientChannelWatcher and Connection classes. 

Those bug is now fixed in 'cpu' branch, and publicly available waiting for the responses of all the IRIS users. After thorough testing, the branch will be merged into master, and another stable release will be announced. 

Since the first release of the OpenIRIS 1.3.2, we worked very hard to make it stable. As a result, we fixed several critical bugs in Device Manager and the User Interface. Also we have updated the javadoc for the 1.3.2 release.

The 1.3.2 release has been tested against mininet to cover 1.3.2 specification, and tested against mininet, ovs, and NEC Openflow switches to cover 1.0.1 specification.

OpenIRIS UI architecture is greatly enhanced by adopting AngularJS and jQuery UI 1.10.2 (jQuery UI 1.10.4 could not be used because of the Draggable UI bug in Chrome browser).

Today, we could finally release OpenIRIS 1.3.2 version. It has compatibility layer that enables developers to write a module that supports Openflow 1.3.2 and 1.0.1 at the same time. :-)

We have tested OpenIRIS 1.3.2 against mininet, and the only problem we've found is that the mininet does not correctly reply the flow aggregate statistics.

Recently, we did performance evaluation of various open-source Openflow controllers, including Floodlight and a controller written in C (we cannot disclose the name of the controller in this article for various reasons. Sorry). For this, we purchased a new hardware (Intel Xeon E5-2650 v2 machine which has 20 physical cores, 64GB RAM, Ubuntu 12.04, JDK 1.7). 

We tested those controllers with cbench 512 virtual switches with 10K different MAC addresses. For IRIS, we have created 5 watcher threads and 15 controller threads. For Floodlight, we have created 20 worker threads. For the C-based controller, we have used 19 switching and app threads. Above graph shows how many flows (a.k.a PACKET-IN messages) per second can be handled by each controller.

One good news is that OpenIRIS shows reasonable performance when there are many cores. One sad news is that the other controllers do not seem to benefit from the increasing number of physical cores. 

Because there might be some missing factors that we did not take into account, we are doing more thorough and extensive evaluation now. And we think we can publish the evaluation result in one of the upcoming SDN-related conferences. 

Anyway, we think that the good performance is no longer a matter of programming languages. C/C++ are definitely wonderful programming languages, but they don't guarantee the good performance automatically. So, the question that really matter is, which controller platform is able to extend itself gracefully according to the increasing workload. We think that 'horizontal scalability' is the only answer, and the implementation strategy for achieving horizontal scalability is quite orthogonal to programming languages. 

Openflow 1.3.2 support of OpenIRIS is finally scheduled to be released at the end of January, 2014. Since our first fork of a new branch 'openflowgenerator', we have struggled to implement a python-based Openflow protocol stack generator, xen. 

Originally, xen did not have any compatibility layer which enables a portable programming between multiple Openflow versions. Meanwhile, Floodlight announced a newer version of Loxigen at the end of year 2013, which is also a python-based Openflow stack generator that has a compatibility layer. Thus, we started to implement a compatibility layer on xen to meet the same requirement that the Loxigen is trying to satisfy.

Key difference of xen-based automatically generated source codes from Loxigen-based codes is that they are largely compatible with OpenflowJ (which was the original protocol stack of Floodlight and OpenIRIS).