Opendaylight Vs Openmul

Many SDN enthusiasts ask us what sets us apart from other bigger projects like OpendaylightODL is a great project no doubt and has many features but we feel ODL is not yet ready for prime time and its architecture is inherently prone to stability and performance problems related to switch and application handling. On a highly loaded and dynamic network, stability and performance are of prime importance and that is where Openmul delivers and wins. Check Openmul Vs ODL performance and find out more.

Apart from performance the major points which sets openmul apart from the competition:

1) ODL has Base Network Service Functions implemented inside single address space eg Topology manager, stats manager, switch manager, host tracker, ARP handler, REST server. It also means failure in any of these functions take the whole controller down. But that is not the case with Openmul which supports major base network functions as stand-alone and independent entities.
2) Direct integration with legacy protocols which means easy to integrate using MPLS-LDP, OSPF, BGP based inter-data center technologies.
2) Language is C/Python. Majority of networking developer community DNA is C  based. Can write base network service functions or applications either in C or python.
3) High flow download performance+latency with/without TLS. Most other controllers don’t support TLS.
5) Openmul provides the best flow, group and meter coherency between switch and controller. For example these entities are managed across switch, controller reboots/failover or when both switch or controller restart. Flows, groups & meters have strict applications ownership rather than controller itself.
6) Supports hot standby HA where controllers can run in active-standby mode. Automatic sync up of controller information between each other out-of-band.
7) OpenMUL can be easily customized. Core functionality, South-bound protocols and services can be added without affecting up-and running modules.
8)  OpenMUL has a highly distributed architecture. Base functions can be distributed/spread locally while one can use OpenMUL’s support for BGP to provide a geo-distributed controller abstraction.

openmul release v4.0.1 is available

We are glad to announce availability of openmul release v4.0.1. Highlights of this release are :

– Support for Openflow 1.4
– Support for (almost) all Openflow 1.3 features
– Backward compatibility with Openflow 1.0, Openflow 1.3
– Support for RESTapi
   * High performance Python tornado based webserver
– Improved documentation (here)
– Huge improvement in CLI features
   * Tons of configuration options
– Many security and stability fixes in infrastructure
– Support for Overlays
– SSL support (TLSv1.2)
– Python bindings/Apis for advanced scripting

(Download source-code)

Regards,

openmul development team

 

MuL’s target audience – Part 1

We have strived hard to make Open-mul (and Pro version) one of the best performing SDN platforms in the world. Control plane performance and scalability is critical for SDN as there are so many things to manage and administer. But, MuL is not only about performance and newer openflow version support. We have focused on a few areas where we believe we can excel and bring real value  :

1) Openflow based ethernet fabrics :

With advanced topology discovery and Openstack integration, it becomes very easy to have an Ethernet fabric up and running in a matter of few hours (if not minutes). Fabrics which are fast, which, are free from any vendor lockin makes a lot of sense to lot of people. It is unfortunate to see technology like TRILL still being pushed when Openflow can do far far better. Many commercial vendors (barring few) have given up  Openflow based fabric. The main reasons being a) Lack of decent OpenFlow gear b) Lack of decent Software that makes up SDN c) Solid orchestration and network visibility/tools d) Last but not the least, effort by big vendors to push Openflow off-track and promote their own version of SDN

Ok,  but how do we solve performance/scalability issues with Openflow and controllers ?? The answer is simple – By knowing what are limits of Openflow and engineering solutions based on collective understanding of Openflow and legacy systems. Control plane performance/scalability is not a problem for us because of our grounds up design to meet those requirements.  Continue reading

Mul 3.0.1-beta available now

It gives us immense pleasure to announce availability of mul-3.0.1 (beta). With this MuL has hit couple of firsts : 1) One of the first to support Openflow v1.3.x  and, 2) One of the first to support both OF v1.3.x and backward compatibility with OF v1.0

The release is deemed beta due to lack of multiple switch implementations that we could test against. We welcome any switch vendors willing to interop their hardware (with of1.3.1 support) to get in touch with us for same.

Release Notes (3.0.1-beta) :

– Support for Openflow 1.3.x
* Wire protocol implementation
* Enhanced Multiple Groups support
* Enhanced Multiple Tables support
– Backward compatibility with Openflow 1.0 (supports both openflow versions)
– Many security and stability fixes in infrastructure
– Improved documentation (inside docs folder in source code)

Regards,

MuL development team