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 the following main components:

The following image shows a simplified view of the typical OpenDaylight architecture. In this chapter, the basic functionality of the main components are described. A detailed description of particular OpenDaylight components is out of the scope of this guide.

Figure 3.1. OpenDaylight Platform Architecture

OpenDaylight Platform Architecture

3.1. 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.2. Authentication, Authorization and Accounting (AAA)

The platform provides a framework for Authentication, Authorization and Accounting (AAA), and enables automatic identification and hardening of network devices and controllers.

3.3. 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, plugin APIs and northbound APIs. These YANG models are used by the OpenDaylight YANG Tools to 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.4. Services and Applications

The business logic of the controller is defined in Services and Applications. You can find a basic overview of services and applications available with the Oxygen release on the OpenDaylight Oxygen release web page. The OpenDaylight project offers a variety of applications, but usually only a limited number of the applications is used in a production deployment.

3.5. Southbound Interfaces and Protocol plugins

Applications use the services of southbound plugins to communicate with other devices, virtual or physical. The basic overview of southbound plugins available with the Oxygen release is on the OpenDaylight Oxygen release web page. The Project list shows them in more details.

3.6. Red Hat OpenDaylight components

The Red Hat OpenDaylight solution consists of several main components. The selection of applications and plugins is limited. The Controller platform is based on the NetVirt application. This is the only application currently supported by Red Hat.

Most applications only use a small subset of the available southbound plugins 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

OpenDaylight Operational Model