A sustained effort to improve the OpenDaylight codebase was focused on restructuring and modularizing the RESTCONF server architecture. What started, according to Robert Varga in 2021,

has been completed, and we can start reaping its benefits.

By modularizing the RESTCONF server architecture, our team was able to achieve a heightened separation of concerns. In simpler terms – greater flexibility and extensibility. For example, unit tests can target specific modules, ensuring each part works as intended.

This shift aims to simplify several parts of the OpenDaylight project and increase flexibility – particularly in how data is managed and how the system interacts with network devices.

State persistence in lighty.io RNC

Particularly, future lighty.io RNC instances will benefit from decoupling the state persistence from the application container itself. By leveraging external systems like ONAP CPS, we can achieve reduced complexity within the RNC container but also allow for more specialized and robust state management solutions.

Statelessness is a crucial property for systems deployed in cloud environments, where resources can dynamically scale in response to demand. This would enable, for example, Kubernetes autoscaling of RNC (download the package here) against an instance of ONAP CPS – or other, similar services, like sysrepo.

MD-SAL Independence

The Model-Driven Service Abstraction Layer (MD-SAL) is a core component in OpenDaylight that provides a common data store and messaging infrastructure. Recent changes allow the RESTCONF server to operate independently of MD-SAL, which was not previously possible.

MD-SAL and RESTCONF communication example

MD-SAL & RESTCONF communication example

This decoupling enables the implementation of a RESTCONF server that can interface directly with various data stores or backend services, without relying on MD-SAL. For example, data from gNMi (gRPC Network Management Interface) devices can be accessed directly, through the same RESTCONF server interface.

For users who continue to use MD-SAL, a dedicated integration layer has been preserved and will soon be separated into its own component. This layer handles the specific wiring needed to integrate MD-SAL with the new RESTCONF server architecture. By isolating this functionality, the system remains modular, allowing users to opt-in or -out of using MD-SAL, as needed.

Separation of Basic RESTCONF Concepts

The RESTCONF API module serves as the foundation for RESTCONF operations. By isolating these core concepts into a dedicated module, developers can build RESTCONF clients and servers without being tied to specific implementations or underlying infrastructure.
The RestconfServer Interface supports multiple server implementations, such as the current JAX-RS and a newer, lighter implementation using Netty – a high-performance, non-blocking I/O framework for Java. This allows for flexibility in choosing the appropriate server technology based on performance needs or deployment constraints.
RESTCONF Server SPI (Server Provider Interface) module provides the necessary interfaces and classes for implementing and integrating various components into the RESTCONF server. This layer ensures that different data stores or backend services can be plugged into the system, facilitating a wide range of use cases and integrations.

The Future is Modular

These recent updates to OpenDaylight have significantly improved the RESTCONF server architecture, making it more modular, flexible, and scalable. These changes do not only simplify the system but also prepare it for future enhancements and integrations, making it a more robust and versatile platform for network management.

Whether handling configuration, monitoring network state, or integrating with various data sources – the new architecture offers a solid and adaptable foundation for diverse networking needs.

Leave us your feedback on this post!

You can contact us here.

Explore our PANTHEON.tech GitHub.

Watch our YouTube Channel.