I have been studying and working with Software Defined Networks (SDN) since 2012. My first contact with an SDN controller was with the SDN VAN Controller from Hewlett-Packard (HP). At the time, this was considered the first era of SDN, where we were using OpenFlow-centric networks. Since then, this approach has changed a lot, especially in the last few years with the OpenDaylight project. OpenDaylight’s main goal is to accelerate the adoption of SDN and create a solid foundation for Network Function Virtualization (NFV). It’s a very ambitious project that contains more than 40 internal projects, forming a large framework for networks. In the beginning we were talking about SDN controllers; now we talk about a complete framework which aggregates very different networks functions to be used on demand. OpenDaylight provides a network ecosystem that companies can use to solve their network problems. OpenDaylight supports hybrid networks and integrates other technologies through its northbound and southbound API’s.
The most recent release, OpenDaylight Lithium, changes the way we interact. Prior versions used an API-driven SAL (AD-SAL), but with Lithium, we now rely on a Model-driven SAL (MD-SAL) architecture. This architecture has YANG models as the central focus, as the name suggests. OpenDaylight has an engine to generate Java classes from YANG models, so instead of describing our model as Java, we do it through YANG models. YANG models have become a standard in the networking industry and OpenDaylight is capable of automating the model transformation from YANG to POJOs. OpenDaylight MD-SAL handles YANG models, storing them in a tree-based data structure. A simple analogy of how this changes things is if you imagine you’re modeling your data with UML (Unified Model Language), instead of real code. The only difference is, is that UML translates the OO (object oriented) paradigm very well, while not attaching us to tree models.
The big network players, such as Cisco, HP, Huawei, Inocybe Technologies and Brocade are allocating their own developers to contribute and leverage OpenDaylight. OpenDaylight creates a very good collaboration environment where you can share your ideas with the best developers behind the largest networking companies. OpenDaylight has a board of directors which define roadmaps and choices mainly formed by these big players. The best part of it all is that it is an open source project and anyone can contribute, pushing patches upstream. Under the OpenDaylight umbrella we find several projects which we can pick up and create our own custom distribution. As we have releases every six months, documentation is something that doesn’t follow strictly all updates. However, each project has weekly meetings and an IRC chat is always available to ask or answer questions about every single OpenDaylight project.
Joining the Inocybe team has been helping me to really dive into the OpenDaylight project as well as run and develop features to our own release. Since Opendaylight is a large framework, collaborating with the internal development team at Inocybe has been easing the learning curve, we have experts that know exactly what is necessary to accomplish the client’s needs.
Finally, even though OpenDaylight is complex, it has been opening my mind to several possibilities in the networking area.