[OpenDaylight] The Future is Modular

01/08/2024

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.

[av_hr class=’short’ icon_select=’yes’ icon=’ue808′ font=’entypo-fontello’ position=’center’ shadow=’no-shadow’ height=’50’ custom_border=’av-border-thin’ custom_width=’50px’ custom_margin_top=’30px’ custom_margin_bottom=’30px’ custom_border_color=” custom_icon_color=” id=” custom_class=” template_class=” av_uid=’av-k0eyys’ sc_version=’1.0′ admin_preview_bg=”]

Leave us your feedback on this post!

You can contact us here.

Explore our PANTHEON.tech GitHub.

Watch our YouTube Channel.

Related Articles

[What Is] LAG & MLAG

Transferring large volumes of data between your servers requires more than just a basic network connection. While a simple physical link might work in small setups, enterprise environments demand greater bandwidth, resilience, and flexibility. With our extensive...

read more

[What Are] PortChannels

Network engineers love throwing around terms like LAG, EtherChannel, MC-LAG - and somewhere in the mix, you’ll hear PortChannel. But what exactly is a PortChannel, and where does it fit into modern data center design? Let’s break it down in a way that makes sense,...

read more