Talking about the secondary development of OpenDaylight
As an open source SDN network controller, OpenDaylight has become the current mainstream SDN network controller development platform based on strong community support and functional features. In the relatively stable OpenDaylight Helium version, developers have been provided with a large number of network management functions and secondary development interfaces. However, due to the complex architecture of OpenDaylight and the diversification of development tools, the secondary development ideas are not clear enough. This article aims to sort out a relatively clear secondary development route of OpenDaylight for readers, and reduce the difficulty of secondary development of OpenDaylight.
1. Brief Analysis of OpenDaylight Architecture
To clearly see what OpenDaylight provides us, the most intuitive way is to sort out the OpenDaylight architecture diagram, as shown in Figure 1:
figure 1
As we all know, the structure level of OpenDaylight is divided into data plane (including physical switching equipment and virtual switching equipment, etc.), southbound interface and protocol plug-ins, and control plane (including core control part and related services) from bottom to top. , upper-layer network applications and services. The development of related technologies for data plane devices has gone beyond the scope of secondary development of OpenDaylight, so our focus is limited to the development of southbound protocols and plug-ins, controller services and upper-layer applications. In general, the secondary development of OpenDaylight can be divided into the following three levels:
- Development of upper-layer web applications based on OpenDaylight REST APIs
- Development of controller components and upper-layer network applications based on SAL kernel-related services
- Southbound protocol plug-in development and upper-layer service interface development based on SAL kernel related services
Of course, if a more specific division is made, each level can be divided into more development directions, but in terms of large development directions, the above three development modes are mainly used.
The following is a brief introduction to the data plane in Figure 1 to help readers understand the specific scenarios of our SDN network controller function implementation. In this figure, we can see that the identified devices mainly include physical devices that implement OpenFlow functions and virtual switching devices that carry Open vSwitch. The following categories are introduced:
Physical devices that implement OpenFlow functions: Generally, they are physical switches that provide multiple network interfaces. The support for the OpenFlow protocol is implemented on the switch operating system, and of course, the traditional switching and forwarding method can be implemented on the hybrid switch. Examples include Cisco's IOS switch operating system, Broadcom's ICOS switch operating system, and so on.
Virtual switching device that carries Open vSwitch: The virtual switching device referred to here can be the virtual switch we virtualize on the physical switch, or it can be the simulated switching device we build in the experimental environment. A typical application is the mininet simulation network construction tool we use in our SDN experiments. The essence is to use Python language to encapsulate the functions of Open vSwitch to provide users with functions such as network creation, deletion, update and attribute control.
2. Upper-layer network application and northbound plug-in development of OpenDaylight
For the secondary development of OpenDaylight, what is generally done is to modify the Web visualization interface of OpenDaylight, and to display more data and add functional operation controls at the same time. For the development of these requirements, we need to use the basic services provided by SAL, call the REST APIs provided by them, or use the basic services provided by SAL to develop our own service interfaces, and then use various development languages and development tools in the upper layer. Development of corresponding functions. The development framework diagram is shown in Figure 2:
figure 2
1. What is SAL?
The full name of SAL is Service Abstraction Layer (Service Abstraction Layer), which is divided into MD (Model-Driven) and AD (Application-Driven). SAL provides infrastructure services for the entire OpenDaylight project framework, including various basic functions required for OpenDaylight development, similar to the Linux kernel. There is no essential difference between AD-SAL and MD-SAL, but the query routing method between API consumers and providers is different. In AD-SAL, YANG is not used to model related requests and notification functions, but Java APIs are directly and statically used for routing and adaptation. In the MD-SAL method, you first need to use YANG to model the functions that the southbound plug-in needs to implement, and then use YangTools and Maven to generate relevant Java APIs, and dynamically perform routing and adaptation by querying the model. Related information can be found in the OpenDaylight Developer Guide :
Page 51, OpenDaylight Developer Guide Helium SR2
2. Upper-layer web application development based on OpenDaylight REST APIs
The development of upper-layer network applications based on OpenDaylight REST APIs is relatively the easiest way among the three development levels. Directly calling OpenDaylight REST APIs for development allows developers to shield the underlying complex function implementation and focus on function innovation and development. However, it is still not easy to use the API directly for development, because a large number of GET/POST operations are required. Therefore, on the basis of querying the API, similar functions can be encapsulated in a development language to make an SDK to improve development. effectiveness.
The focus of using this method is more focused on the development of Web visual interface. Let's discuss several mainstream Web development frameworks:
- Python + Django: The research I am currently engaged in is mainly the connection between OpenDaylight and OpenStack functions, so I pay more attention to the implementation of this architecture. Django is a web development framework based on MTV, and the Horizon interface project of OpenStack is developed based on this framework. In addition, the entire engineering project of OpenStack is developed in Python. Therefore, the development method using Python + Django can better realize the loading of OpenDaylight network management functions and interface additions in the OpenStack cloud platform.
- LAMP: PHP is a convenient network back-end development language with a powerful function library and a concise calling method. If the Web UI development is purely based on OpenDaylight, this choice is a good solution.
- Java Spring: Java Spring is an MVC-based web development framework. The advantage of using this solution is that the OpenDaylight core is developed in Java. When we need to develop our own plug-ins to provide interfaces for upper-layer applications, this method is more convenient to interface. connection. As shown in Application B in Figure 2.
The following is a brief list of some commonly used API modules for readers' reference. The specific API mount points will be slightly different due to different versions. They will not be listed here, and only related functions will be introduced:
Table 1 Common API modules of OpenDaylight SAL layer
The above is a brief list of commonly used API modules. For more specific information, readers can query related documents by themselves. Commonly used API mount points generally have the following form: http://127.0.0.1:8080/controller/nb/v2/topology/default. At the same time, the returned data obtained by using the API is generally in the form of XML/JSON, so it is recommended to use relevant development tools to parse the data first, and then package it as an SDK to improve development efficiency.
Practical reference: https://www.sdnlab.com/11480.html
3. Development of controller components and upper-layer network applications based on SAL kernel-related services and northbound plug-ins
In the previous section, we discussed how to use OpenDaylight's existing REST APIs to develop upper-layer network applications. This method can be said to rely on the external development of the OpenDaylight platform, rather than the application development embedded in OpenDaylight. The key to this development method is that OpenDaylight has provided us with corresponding development interfaces, but if the existing OpenDaylight does not provide us with relevant interfaces, this requires us to carry out deeper development, that is, based on SAL kernel related The service carries out the application development of the required controller components and the upper layer network.
The general application scenario of the controller components based on SAL kernel-related services and the upper-layer network application development method described in this section is that the upper-layer network application needs to use the existing SAL-related services and southbound plug-ins/protocols to achieve some specific functions. And this function is not given REST API by OpenDaylight controller, as shown in the development of application B shown in Figure 2. This method is relatively more called the secondary development of OpenDaylight. Before introducing the specific content, you first need to understand the following reserve knowledge:
- OSGi and OSGi Components: The backend of the OpenDaylight platform. Provides a modular management method for the entire engineering project, that is, OSGi components. Each component can implement some specific functions and be loaded into the project's runtime environment.
- Maven tool: Maven tool is a tool used to manage and control the entire project of OpenDaylight. Different projects, different components can be generated with Maven. Each Maven project contains a project control file pom.xml, a src folder, and a test folder. Usually the pom.xml file uses a structured document to set the property configuration, external dependencies, compilation process and external output of the entire project, which realizes the automatic management of the project. The src folder contains source programs related to projects or components, and the test folder contains related test programs. Maven is the basis of the development method described in this section. Readers can refer to the documentation on the official website for learning.
- Apache Karaf: Karaf tool is an OSGi-based OpenDaylight feature container, which is used to implement hot-plugging of OpenDaylight functional components.
The development of controller components and upper-layer network applications based on SAL kernel-related services requires the help of modules and components already implemented by the OpenDaylight development platform, and calls its Java APIs to help realize the functions we need. The following is a brief list of the related programming service interfaces that OpenDaylight provides us:
Table 2 List of OpenDaylight modules/components
A full list of components can be found here: https://wiki.opendaylight.org/view/Controller_Projects%27_Modules/Bundles_and_Interfaces
In view of the complexity of MD-SAL, we will focus on the discussion in the next subsection. In this subsection, we will mainly focus on the development of northbound application plug-ins based on AD-SAL. The flow chart is as follows:
The steps that need to be implemented in the above flow chart involve the configuration of various files and the use of tools. Interested readers are requested to refer to the relevant documents to understand the relevant settings. You can refer to the following articles.
Practical reference: https://www.sdnlab.com/11456.html
3. Southbound plug-in/protocol development for OpenDaylight
In the previous section, we discussed how to develop northbound plug-ins for specific applications based on AD-SAL and related northbound plug-in services. In this development method, AD-SAL services are mainly used. In the following chapters, we mainly introduce the development of southbound plug-ins based on MD-SAL.
The southbound plug-in of OpenDaylight, also known as the southbound protocol plug-in, mainly undertakes the following tasks:
- Handling sessions between controllers and southbound network devices
- Abstract interface that provides multiple access network setting functions
The southbound protocol plug-in development method based on MD-SAL is our implementation method to expand the OpenDaylight function horizontally, and it is a complete function development route from the bottom layer to the upper layer. Different from the first two development methods, the functions we need to implement do not provide much function implementation in the existing OpenDaylight, and must rely on industrial standards or self-developed protocol algorithms to add functions at the southbound plug-in layer. And bind the plug-in to the SAL, so that it can be transferred to the aforementioned two development methods. The specific development process is shown in Figure 4:
Figure 4
The interaction between plugins and SAL and how they work will not be introduced here. Interested readers can refer to:
Page 54, OpenDaylight Developer Guide Helium SR2
As can be seen from the above figure, the first step in the development of the entire MD-SAL southbound plug-in is derived from YANG modeling of the functions to be implemented. YANG is a tool for encapsulating the service interface of the specific function implementation of the southbound protocol plug-in. Through the cooperation of YANG modeling and Yang Tools, we can generate Java APIs that require functions, and then compile with Maven to generate JAR packages as OSGi components are plugged into the controller. At this point, the services of the southbound protocol plug-in can be developed by other plug-ins through API calls.
On the other hand, by writing the Java source code to implement the protocol or industry standard functions we want to add, the JAR package is generated by the Maven compilation tool and inserted into the controller as an OSGi component. In this way, when other plug-ins call the corresponding Java API, the API and function implementation can be mapped according to a certain routing method and query method. Implement the call of the added function by the upper-layer application.
4. Summary
In this article, we briefly introduced three ways of secondary development of OpenDaylight. For more detailed description, readers can refer to the developer manual and related source code. The three methods proposed in this paper are aimed at different application scenarios. For the selection of specific methods, please refer to the following figure:
This article helps readers sort out the secondary development route of OpenDaylight. I hope that readers will have a clearer understanding of the secondary development of OpenDaylight after reading this article. Based on the complex software architecture of OpenDaylight, it is far from enough to only understand the above content. It is necessary to combine more specific codes for practical learning, master OpenDaylight in practice and develop a good SDN controller.
postscript
This article is a phased summary after being in contact with OpenDaylight for a period of time, mainly to help myself and my friends who are in the entry stage of OpenDaylight development to have a clear understanding of what we can do in OpenDaylight and how to do it. But after all, this article is only a general introduction and combing. In the follow-up research and development, it is necessary to continuously combine the code to practice these development concepts. At the same time, when writing this article, I still feel that I have many shortcomings. Therefore, the article will inevitably have omissions. I hope readers can help correct it and make progress together.