What's in OpenDaylight?

The momentum to recognize the OpenDaylight Project as the standard open source software-defined networking (SDN) continues to grow. Established to accelerate the adoption of SDN and Network Functions Virtualization (NFV), OpenDaylight provides an open platform for network programmability  and cloud computing designed to enable SDN and create a solid NFV foundation for all sizes of networks.

The purpose of SDN is to enable a network to adapt to the requirements of applications deployed on it, rather than having the content be constrained by network limitations. Virtualized network functions (VNFs) and applications such as Hadoop require agile, flexible networks for full functionality, and OpenDaylight offers the implementation needed.

In the first of a series of articles, we present an overview of the OpenDaylight architecture so you can see the components and how they work together to enable SDN and NFV. Future articles will present use cases and show you how to implement the technology. But before we get into technical details, let’s take a look at the growth of OpenDaylight.

What is OpenDaylight?

A Collaborative Project at the Linux Foundation, the OpenDaylight project was founded in April, 2013, and announced its first release in February, 2014. In September of that year, the Linux Foundation launched Open Platform for NFV (OPNFV), leveraging the OpenDaylight SDN controller for the BootStrap/Get Started! project with the goal of enabling flexible technologies consisting of VNFs. This project has the potential to open a huge SDN market and strengthens the push to make OpenDaylight the standard open source SDN controller and the central point for converging new and legacy networks.

That push is powered by a community of OpenDaylight developers, which is the largest among open source initiatives supporting and providing documentation for SDN controllers. It has delivered its second stable release, “Helium,” which comes with a new user interface and a customizable installation process using the Apache Karaf container. The third release, “Lithium,” is currently in the works.

In addition to community efforts towards an open source solution, well-known networking vendors such as Cisco and Brocade are building on OpenDaylight’s foundation, using its codebase to develop commercial versions of their controllers to enable SDN and NFV. Meanwhile, other vendors are proposing customization and commercial support for OpenDaylight-based SDN solutions. With these factors in mind, let’s take a look at SDN and NFV concepts and then move on to the OpenDaylight architecture.

SDN and NFV

To create a network that adapts to application requirements, SDN separates the control plane from the data plane within the network to enable central network management while abstracting the underlying physical network. Creating an adaptive network is a work in progress, with the industry standardizing protocols such as OpenFlow, and OpenDaylight looking to leverage more open source development to create industry solutions. In addition, NFV is leveraging virtual compute, storage, and networking to improve network agility and security while bringing down the cost.

OpenDaylight architecture

OpenDaylight Helium components include a fully pluggable controller, interfaces, protocol plug-ins, and applications. The Helium controller consists of three key blocks:

• The OpenDaylight controller platform

• Northbound applications and services

• Southbound plugins and protocols

Here you can see the overall architecture setup and components:

Figure 1 - OpenDaylight Helium architecture and components

Let's take a closer look at the controller.

Controller Platform

The controller platform is a modular layer (as shown in Figure 2) and has a “northbound” and “southbound” interface. The northbound interface provides controller services and a set of common REST APIs that applications can leverage to manage networking infrastructure configuration.  You can access the northbound interface using the authentication and authorization models in the AAA project shown as the top layer of the OpenDaylight architecture in Figure 1.

Figure 2: Controller components

The southbound interface implements protocols to manage and control the underlying networking infrastructure. The southbound level has multiple plugins that either implement various networking protocols or directly communicate with hardware. OpenFlow, NetConf, and SNMP are the best known and most widely used configuration and management protocols.

The controller platform communicates with the underlying network infrastructure using southbound plugins and provides basic networking services via a set of managers displayed in the Base Network Service Functions section of Figure 2, including Topology Manager, Switch Manager, and so on. Any custom application can use these network services; for example, OpenStack Networking (Neutron) can use northbound APIs and related components.

Next let's look at details of the networking services provided by the controller platform.

Base Network Service Functions

The Base Network Service Functions are provided by the following platform managers and components:

• Topology Manager - stores and handles information about the managed networking devices. When the controller starts, the Topology Manager creates the root node in the topology operational subtree. Then it listens for notifications and updates this subtree with topology details, including all discovered switches and their interconnections. Notifications from other components, such as the Switch Manager or Device Manager, may also provide relevant topology information.

• Statistics Manager - implements statistics collection, sending statistics requests to all enabled nodes (managed switches) and storing responses in the statistics operational subtree. The Statistics Manager also exposes northbound APIs to report the following information.

  
  

  • node-connector (switch port)

  • flow

  • meter

  • table

  • group statistics

In addition, the Helium release of the OpenDaylight controller allows you to configure the statistics query interval.

• Switch Manager - provides network nodes (switches) and node connectors (switch ports) details. As soon as the controller discovers network components, their parameters are saved to the Switch Manager data tree . You can use northbound APIs to get information on the discovered nodes and port devices.

• Forwarding Rules Manager (FRM) - manages basic forwarding rules (such as OpenFlow rules), resolves their conflicts, and validates them. The Forwarding Rules Manager communicates with southbound plugins and loads OpenFlow rules into the managed switches.

• Inventory Manager - queries and updates information about switches and ports managed by OpenDaylight, guaranteeing that the inventory database is accurate and up-to-date.

• Host Tracker - stores information about the end hosts (data layer address, switch type, port type, network address), and provides APIs that retrieve end node information. Host Tracker may work in a static or dynamic way. In case of dynamic operation, the Host Tracker uses ARP to track the status of the database. In static mode, the Host Tracker database is populated manually via northbound APIs.

Other services

Apart from the core network services above, a number of other services are on the same architectural layer, interact with core controller modules, and provide specific features for appropriate services and modules. Now that we’ve covered services, we turn to networking services abstractions.

Networking Services Abstractions

The central concept of the OpenDaylight controller is the Service Abstraction Layer (SAL), which connects the protocol plugins and Service Network Function Modules. Because the original API-Driven SAL (AD-SAL) approach proved ineffective, OpenDaylight and all dependent projects are migrating to Model-Driven SAL (MD-SAL), which is now our focus.

How the Model-Driven SAL works

The Model-Driven SAL provides a common approach to plugin development, enabling unification between both northbound and southbound APIs and the data structures used in various components of the controller. In MD-SAL, all status-related data is stored in the form of a document object model (DOM), known as a “data tree.” The following two types of data trees are used in the OpenDaylight Controller:

• The operational DOM tree, which controller modules use to store certain temporary runtime information

• The configuration DOM tree, used to store the current status of the controller.

MD-SAL uses YANG, a single schema language, as a modelling language for describing all network services. YANG makes it easy to develop any controller-related core module, northbound software application, or platform component providing built-in structures and types, such as containers, lists, and leaves, while a developer may specify any additional structures for certain tasks’ data types. After you define the YANG models, a compiler outputs appropriate Java interfaces, and the next step is to implement those auto-generated Java interfaces. In the next article of this series, we will focus on developing custom applications using Yang.

Now let’s look at the example of the southbound plugin and controller operations. In this case, we’ll look at the OpenFlow plugin and its interaction with MD-SAL platform services, seen in Figure 3.

Figure 3 -  Interaction between southbound plugin and controller

In this example, when the switch attempts to register with the controller, it first registers with the southbound plugin, which produces a NodeUpdated notification. All controller modules - Topology Manager, Inventory Manager, Statistics Manager - listen for the NodeUpdated notification. Actions after receiving notifications include:

• Inventory Manager adds the new node (switch) to the operational data tree

• Statistics Manager gets the updated information from the inventory database via read transactions to the operational data tree

• Topology Manager updates the corresponding topology DOM subtree.

Still to come

Here we’ve covered OpenDaylight architecture and components, and the general communication approach between MD-SAL services and the OpenDaylight Control platform. In the next installations of this series, we’ll provide further details on OpenDaylight internals and  you’ll learn how to develop custom applications using  tools like YANG and OpenDaylight for innovative SDN services for enterprise and service provider networks.