OpenDaylight as an SDN controller

In previous sections, we went through the role of the SDN controller, and a brief history of ODL. ODL is a modular open SDN platform that allows developers to build any network or business application on top of it to drive the network in the way they want.

Currently OpenDaylight has reached its fifth release (Boron, which is the fifth element in the periodic table). ODL releases are named based on periodic table elements, started from the first release, Hydrogen. ODL has a six month release period, with many developers working on expanding the ODL, two releases per year is expected from the community.

For technical readers to understand it more clearly, the following diagram will help:

The ODL platform has a broad set of use cases for multivendor, brown field, green fields, service providers, and enterprises. ODL is a foundation for networks of the future.

Service providers are using ODL to migrate their services to a software enabled level with automatic service delivery and coming out of a circuit-based mindset of service delivery.

Also they work on providing a virtualized CPE with NFV support in order to provide flexible offerings.

Enterprises use ODL for many use cases, from data center networking, Cloud and NFS, network automation and resource optimization, visibility, control, to deploying a full SDN campus network.

ODL uses an MD-SAL, which makes it very scalable and lets it incorporate new applications and protocols faster. We will cover more details about MD-SAL in upcoming chapters where we will dive into ODL.

ODL supports multiple standard and proprietary southbound protocols, for example, with full support of OpenFlow and OVSDB, ODL can communicate with any standard hardware (or even the virtual switches such as Open vSwitch (OVS) supporting such protocols). With such support, ODL can be deployed and used in multivendor environments and control hardware from different vendors from a single console no matter what the vendor and what device it is, as long as they support standard southbound protocols.

ODL uses a micro service architecture model, which allows users to control applications, protocols, and plugins while deploying SDN applications. Also ODL is able to manage the connection between external consumers and providers.

The following diagram explains the ODL footprint and different components and projects within the ODL:

ODL stores its YANG data structure in a common data store and uses messaging infrastructure between different components to enable a model-driven approach to describe the network and functions.

In ODL MD-SAL, any SDN application can be integrated as a service and then loaded into the SDN controller. These services (apps) can be chained together in any number and ways to match the application needs.

This concept allows users to only install and enable the protocols and services they need, which makes the system light and efficient.

Also services and applications created by users can be shared among others in the ecosystem since the SDN application deployment for ODL follows a modular design.

ODL supports multiple southbound protocols. OpenFlow and OpenFlow extensions such as Table Type Patterns (TTP), as well as other protocols including NETCONF, BGP/PCEP, CAPWAP, and OVSDB. Also ODL supports the Cisco OpFlex protocol:

The ODL platform provides a framework for Authentication, Authorization, and Accounting (AAA), as well as automatic discovery and securing of network devices and controllers.

Another key area in security is to use encrypted and authenticated communication through southbound protocols with switches and routers within the SDN domain. Most southbound protocols support security encryption mechanisms.