此内容没有您所选择的语言版本。

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

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

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2026 Red Hat
返回顶部