Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
Chapter 3. What are the components of OpenDaylight?
The typical OpenDaylight solution consists of five main components: the OpenDaylight APIs, Authentication, Authorization and Accounting (AAA), Model-Driven Service Abstraction Layer (MD-SAL), Services and Applications, and various southbound plug-ins. The following diagram picture shows a simplified view of the typical OpenDaylight architecture. In this chapter, the basic functionality of the main components will be described. However, a detailed description of particular OpenDaylight components is out of scope of this guide.
Figure 3.1. OpenDaylight Platform Architecture
3.1. Authentication, Authorization and Accounting (AAA)
The platform also provides a framework for Authentication, Authorization and Accounting (AAA), and enables automatic identification and hardening of network devices and controllers.
3.2. OpenDaylight APIs
The northbound API, which is used to communicate with the OpenStack Networking service (neutron), is primarily based on REST. The Model-Driven Service Abstraction Layer (described later) renders the REST APIs according to the RESTCONF specification based on the YANG models defined by the applications communicating over the northbound protocol.
3.3. Services and Applications
The business logic of the controller is defined in Services and Applications. The basic overview of services and applications available with the Boron release can be found on the OpenDaylight Boron release web page. A more detailed view can be obtained from the Project list. The OpenDaylight project offers a variety of applications, but usually only a limited number of the applications is used in a production deployment.
3.4. Model-Driven Service Abstraction Layer
The Model-Driven Service Abstraction Layer (MD-SAL) is the central component of the Red Hat OpenDaylight platform. It is an infrastructure component that provides messaging and data storage functionality for other OpenDaylight components based on user-defined data and interface models.
MD-SAL, in MD-SAL based applications, uses the YANG models to define all required APIs, including inter-component APIs, plug-in APIs and northbound APIs. These YANG models are used by the OpenDaylight YANG Tools to instantly generate Java-based APIs. These are then rendered according to the RESTCONF specification into the REST APIs and provided to applications communication over the northbound protocol.
Using YANG and YANG Tools to define and render the APIs greatly simplifies the development of new applications. The code for the APIs is generated automatically which ensures that provided interfaces are always consistent. As a result, the models are easily extendable.
3.5. Southbound Interfaces and Protocol Plug-ins
Applications typically use the services of southbound plug-ins to communicate with other devices, virtual or physical. The basic overview of southbound plug-ins available with the Boron release can be found on the OpenDaylight Boron release web page. The Project list shows them in more details.
3.6. Red Hat OpenDaylight components
The Red Hat OpenDaylight solution (part of the Red Hat OpenStack Platform) consists of the five main parts, but the selection of applications and plug-ins is limited to a certain number only. The Controller platform is based on the NetVirt application. This is the only application currently supported by Red Hat. In the future releases, more applications will be added.
Most applications will only use a small subset of the available southbound plug-ins to control the data plane. The NetVirt application of the Red Hat OpenDaylight solution uses OpenFlow and Open vSwitch Database Management Protocol (OVSDB).
The overview of the Red Hat OpenDaylight architecture is shown in the following diagram.
Figure 3.2. Red Hat OpenDaylight architecture
