SDN Series Part Six: OpenDaylight, the Most Documented Controller
Editor’s note: This is part six of a multi-part series about software defined networking. Other posts in the series can be found here.
Modular application development, in which a set of loosely coupled modules can be integrated into one large application, has been one of the most successful software development practices. The term “loosely coupled” highlights the fact that the modules are both independent and can communicate with one another. OSGI (the Open Services Gateway Initiative), a dynamic module system for Java, defines one such architecture for modular application development. The SDN controller OpenDaylight (ODL), which we will be discussing in this article, is one such controller (apart from Beacon/Floodlight) that is based on the OSGi architecture. ODL is an open-source collaborative project that focuses on building a multi-vendor, multi-project ecosystem to encourage innovation and an open/transparent approach toward SDN. We need to look at these terms, “open,” “multi-vendor,” “multi-project,” “innovation,” etc., in detail to really appreciate the strengths of ODL.
ODL is managed by the Linux Foundation and boasts broad industry support, with memberships covering over 40 companies, such as Cisco, IBM, NEC, etc. Projects focus on adding specific features to the controller. ODL is often touted as an open-source framework designed to “shape the future of SDN” – mainly because it provides an open platform for developers to contribute, use, and, in fact, even build commercial products. As put nicely by David Meyer of Brocade:
OpenDaylight can do for networking what Linux has done for the computing industry.
There is no doubt that ODL is the most successful open-source SDN controller, thanks to the successful collaborations among member companies and excellent commitment from the existing members. Member companies’ commitment in terms of funding and human resources has been the main reason for the project’s success. To highlight the commitment of the members involved in ODL, a dedicated official security-response team was recently set up to create a formal internal process to handle security following the disclosure of a serious vulnerability. It is also true that OpenDaylight is the most well-documented controller, with numerous mediums such as wiki, IRC, listservs, meetup groups, hackfests, summits, and video tutorials that are out there for anybody to understand and use and to start contributing to the ODL. For a beginner, the video tutorials and wiki can serve as an excellent starting point.
Similar to other controllers we have seen, ODL also supports network programmability via southbound protocols, a bunch of programmable network services, a collection of northbound APIs, and a set of applications. However, as we will see in the following sections, ODL is arguably better than other controllers in all these respects.
ODL Architecture
Considering that OpenDaylight includes multiple components and projects, it may help the reader if we first take a look at the simplified architecture, as shown in Figure 1, and then a detailed architecture, as shown in Figure 2. As shown in Figure 1, the architecture mainly comprises three layers:
- Southbound plugins and protocols forming the network device layer.
- Service adaptation and network functions forming the coordination and control layer.
- Northbound APIs and applications forming the application layer
Figure 1: Simplified ODL Architecture
Figure 2: Detailed Architecture of ODL
The controller acts like middleware in the OpenDaylight ecosystem. It is the framework that glues together the applications requiring services of the network devices and the protocols that talk to the network devices for extracting services. The controller allows the applications to be agnostic about the network device specifications, thereby allowing the application developers to concentrate on the development of application functionality rather than writing device-specific drivers.
Figure 2 gives a detailed picture of the ODL architecture. In the remaining part of this section, we’ll describe all the important components of the architecture.
Southbound Protocols
The southbound interface is capable of supporting multiple protocols (as separate plugins), e.g. OpenFlow 1.0, OpenFlow 1.3, BGP-LS, LISP, SNMP, etc. These modules are dynamically linked to a service abstraction layer (SAL), which determines how to fulfill the service requested (by applications) irrespective of the underlying protocol used between the controller and the network devices.
For example, an OpenFlow plugin will include the following: (a) connection, session, and state managers to manage the connection with the switches, (b) an error handing mechanism, (c) a packet handler to handle incoming packets from the switches, and (d) a set of basic services such as flow, stats, and topology. This OpenFlow plugin, along with the OpenFlow protocol libraries, will constitute the southbound OF 1.0/1.3 module.
Service Abstraction Layer
In OpenDaylight, the service abstraction layer (SAL) is the key design that enables the abstraction of services between the services’ consumers and producers. SAL acts like a large registry of services advertised by various modules and binds them to the applications that require them. Modules providing services, or producers, can register their APIs with the registry. When an application, or a consumer, requests a service via a generic API, SAL is responsible for assembling the request by binding producer and consumer into a contract, brokered and serviced by SAL. SAL has two architecturally different ways of implementing this registry: application-driven SAL and module-driven SAL. In Section III, we will describe this service abstraction in detail.
Service Functions
The controller has various basic network functions included as part of the shipped base. This includes services for topology discovery and dissemination, a forwarding manager for managing basic forwarding rules, and a switch manager for identifying networking elements in the underlying physical topology. SAL acts as an active registry for brokering contracts between service providers, such as protocol plugins and basic network function plugins, and the service consumers, such as the applications. These contracts are honored by the SAL without any direct dependency on the respective plugins. For example, a topology service plugin is responsible for discovering nodes and physical paths between them to generate a graph. This plugin exposes functions that can be used by an application to get a complete view of the physical layer. Thereafter, the application can use the flow programmer service to create flows across all the network devices, without worrying about their make or model, to implement an end-to-end flow logic.
Figure 3 summarizes various basic network functions of ODL.
Figure 3 – Basic Network Services and Some of Its Components
Vendor Components (Platform Services)
The controller platform itself contains a collection of dynamically pluggable modules to perform needed network tasks. In addition to basic network services, platform-oriented services and other extensions are also added into the controller platform for enhanced SDN functionality. Some of the platform-oriented services are (a) a VTN component to realize a multi-tenant network virtualization application using OpenFlow, (b) affinity services that expose APIs to express workload relationships and service levels, (c) BGP-LS/PCEP to support traffic engineering with BGP-LS (BGP protocol library and topology model) and PCEP (path programming model), (d) an Openstack neutron to provide Neutron API handling for multiple implementations, (e) a group-based policy (GBP) that introduces a novel notion of groups of endpoints and policy (application-focused) abstractions that govern communication between these groups, (f) service function chaining (SFC), which provides the ability to define an ordered list (a chain) of network services, mainly for network function virtualization (NFV), (g) a LISP mapping service that can be used to implement virtual networks, and (h) an SDNi aggregator that collects various information, such as topology, statistics, etc., to enable inter-SDN controller communication.
As we can see, various services have been contributed to OpenDaylight. While many, such as VTN Manager, SDNI, etc., are specifically designed to service their northbound applications, others, such as the OVSDB manager, provide generic features for other applications to utilize. All the services use the SAL layer to register the functionalities implemented in them by exposing their interfaces. SAL is responsible for gluing together calls originating from northbound applications for a specific functionality into the implementation in the modules.
Northbound APIs
The primary architectural principle of the OpenDaylight controller includes of application and service modularity, managed by the implementation of a service abstraction layer (SAL). The controller exposes open northbound APIs, which are used by applications. OpenDaylight, interestingly, supports both the OSGi framework and the bidirectional REST APIs in the northbound layer. The OSGi framework is mainly used by applications that will run in the same address space as the controller, whereas the REST (Web-based) API is used by applications that can run on same machine as the controller or on a different machine. These applications typically realize a business logic and may include all the necessary algorithms. As we have seen in other controllers, the northbound applications use the controller to gather network intelligence, run algorithms to perform analytics, and then use the controller to orchestrate the new rules, if any, throughout the network.
ODL Applications
The top layer of OpenDaylight consists of business and network logic applications that control and monitor network behavior. As shown in Figure 2, most of the applications are mapped to the corresponding platform services, such as a VTN coordinator and VTN Manager, an SDNI wrapper and aggregator, etc. In addition, the northbound applications include more complex orchestration applications that engineer network traffic in accordance with the needs of environments such as the cloud and NFV.
Service Abstraction Concept in ODL
Abstraction is part of the key philosophies on which OpenDaylight has been modeled. SAL distinguishes among various plugins based on the services they provide (service providers or producers) and consume (service consumers) and the abstractions to interface between them. On the basis of how these services are registered, discovered, and consumed, the SAL framework allows for two distinct ways of implementing the plugins – application-driven SAL (AD-SAL) and model-driven SAL (MD-SAL).
AD-SAL or Application-Driven SAL
As a framework, the key thing that OpenDaylight aspires to provide an application developer is independence from device specifications. For a developer, it would be invaluable to be able to focus only on the application logic and business problems rather than focusing on how a particular device behaves and what mechanism is used to interact with it.
This is the primary problem that AD-SAL was designed to solve – to provide abstraction through use of a generic set of APIs that provide all device functions. Devices talk to the OpenDaylight controller through their respective protocol modules. The protocol plugins in turn communicate with the SAL layer’s exposed API. SAL converts the language spoken by the protocol plugins into application-specific APIs – all the while upholding the functionality required by the application’s business logic.
Figure 4 – AD-SAL Architecture for a Plugin
Let’s consider the example of an SNMP southbound plugin – if developed using AD-SAL methodology, it would implement various basic functions expected by the controller, including the extraction of port state information, switch health, and OSPF topology. These basic functions are then exposed to the northbound plugin developers. It is possible that a SNMP protocol plugin may not implement a flow install/delete method, in which case the application using the plugin would have to consider an error response. Further, a SNMP plugin can export some specific functions, such as bandwidth monitoring, which is not part of controller’s lowest common denominator set – in which case the northbound plugin developer would have to implement directly the abstract Java APIs for importing functionality.
MD-SAL or Model-Driven SAL
If AD-SAL gives a developer independence from handling device-level complexities, MD-SAL goes a step further and allows the developer to work in a silo, agnostic to the specifications of the service interfaces exposed by the modules providing services. While AD-SAL was designed for north-south transparency, MD-SAL was designed to glue together the modules horizontally by allowing the developer to use generic interfaces for service discovery and consumption.
The key differences lie in how the APIs are used by the provider and consumer plugins. In the case of MD-SAL, the providers (generally southbound plugins) create a model of the data or services they expose. Models are in form of YANG definitions. Thereafter, a YANG compiler is used to create uniform APIs for the consumers that then are made part of the plugin. These APIs are tool generated, allowing a very high level of uniformity between them in terms of definitions and usage.
Figure 5 – MD-SAL Controller Architecture for a Plugin
Thus, an OpenFlow plugin would be defined using YANG models that contain a description of services, such as packet_in, packet_out, and packet data delivery. Thereafter, on compiling the models, APIs would be generated for the OpenFlow plugin to interact with the OpenFlow switches and extract data. APIs for accessing the extracted data from the northbound plugin side would also be generated, including RPCs, RESTful interfaces, DOM APIs, and notification listening APIs.
SAL helps MD-SAL-generated plugins to register interested consumers for the events and notifications generated by the devices (and handled by southbound plugins).
Writing ODL Applications
Only a detailed description that considers different possibilities can do proper justice to this section. Hence, a separate post will be published on this topic.
Acknowledgements
I would like to thank Shreyansh Jain and Swarvanu Sengupta for sharing nice descriptions of service adaption and example applications, respectively.
Sridhar received his Ph.D. in computer science from the National University of Singapore in 2007, his M.Tech. degree in computer science from KREC, Suratkal, India in 2000, and his B.E. degree in instrumentation and electronics from SIT, Tumkur, Bangalore University, India, in 1997. He worked as a research lead at the SRM Research Institute, India, a post-doctoral fellow at the Microsoft Innovation Center, Politecnico Di Torino, Turin, Italy, and as a research fellow at the Institute for Infocomm Research (I2R), Singapore. He has worked on various development and deployment projects involving ZigBee, Wi-Fi, and WiMax. Sridhar is currently working as a Group Technical Specialist with NEC Technologies India Limited. Sridhar’s research interests are mainly in the domain of next-generation wired and wireless networking, such as OpenFlow, software-defined networking, software-defined radio-based systems for cognitive networks, Hotspot 2.0, and the Internet of things.
