ODL supports a layered architecture with clear integration points and APIs that allow end users and networking vendors to participate in the power SDN capabilities of ODL. The southbound interface to ODL ensures that networking technologies and hardware from diverse vendors can be leveraged using ODL. The northbound interface provides APIs for end users and other cloud technologies such as OpenStack. The following block diagram captures the architecture of ODL:
Figure 1: ODL architecture overview
In a cloud deployment, other components such as compute and storage also play a critical role, in addition to networking. While ODL acts as the SDN platform while building the cloud infrastructure, it is critical for ODL to integrate with platforms such as OpenStack to provide seamless user experience while operating the cloud. Specifically, ODL needs to be integrated with OpenStack Neutron to provide an SDN-based network for the cloud.
Let's now look at some important aspects of the ODL architecture.
As part of the northbound interface, ODL supports very important APIs. These RESTful APIs are primarily meant for integrating with platforms such as OpenStack (Neutron) and also custom applications. The REST APIs are also used to build a graphical user interface or GUI for ODL. Programmability is one of the primary requirements for SDN platforms and the REST API of ODL allows very specific networking applications to be built outside ODL in order to leverage the information and capabilities available in ODL.
The purpose of the controller platform layer is to leverage the SAL data model and provide fundamental SDN capabilities and networking functions such as topology, performance monitoring, physical or virtual switch management, and ARP handling. This is the layer that acts as the glue between southbound interfaces and northbound interfaces. The REST APIs exposed by ODL are handled by components within the controller platform.
The controller platform also supports use case-specific functionality such as virtual tenant network manager. This is a useful capability while integrating with cloud platforms such as OpenStack. Similarly, for telecom service providers who use real networking devices heavily, functions such as the BGP based path computation engine is supported in ODL.
The Service Abstraction Layer (SAL) is the most critical layer of ODL. As seen earlier SDN platforms need to provide a centralized control plane while the data plane stays distributed. Being an open source project, ODL is required to support data planes from a multitude of hardware vendors. In addition to physical networking devices, ODL will also have to manage the data planes of virtual networking devices.
The main purpose of SAL is to map a diverse set of networking technologies into a common abstracted data model. All the controller services of ODL operate on this abstract data model, thus creating a vendor-neutral SDN controller. This approach also allows vendors and networking technologies to easily integrate themselves with ODL. SAL and the different protocols used to communicate with networking devices together make up the southbound interface for ODL.
ODL has built-in support for different protocols, using which it can communicate with networking devices. Using pluggable architecture support for new protocols can be easily added by writing new plugins. The most popular plugins are OVSDB, OpenFlow, and Netconf. These protocols are used for managing physical and virtual Layer 2 switching devices. BGP is a well-established protocol for communicating with routers. The following diagram shows how ODL uses OpenFlow protocol plugin to enable forwarding rules:
OpenFlow plugin interaction with physical and virtual switches for packet forwarding
The OpenFlow protocol plugin communicates with Open vSwitch (virtual switch) on the compute nodes and with the physical devices connected to the compute nodes. This allows appropriate forwarding rules to be configured to enable data flow.
The physical switches shown in the preceding diagram represent devices that support OpenFlow protocol messages.