What if I told you, that there is an out-of-the-box pre-packaged microservice-ready application you can easily use for managing network elements in your SDN use case? And that it is open-sourced and you can try it for free? Yep, you heard it right.

The application consists of lighty.io modules packed together within various technologies – ready to be used right away.

Do you have a more complex deployment, and are using Helm to deploy into Kubernetes? Or you just need to use Docker images? Or you want to handle everything by yourself and the only thing you need is a runnable application? We got you covered.

lighty.io RESTCONF-NETCONF Application

The most common use case we see at our customers is for an SDN controller to handle NETCONF devices via REST endpoints. This is due to ease of integration to e.g. OSS and BSS systems, or ITSM systems, as these already have REST API interfaces and adapters.

This is where our first lighty.io application comes in – the lighty.io RNC application, where RNC stands for RESTCONF-NETCONF-controller.

Use Cases: Facilitate & Translate Network Device Communication

Imagine a scenario, where the ONAP Controller Design Studio (CDS) component needs to communicate with both RESTCONF & NETCONF devices.

lighty.io RESTCONF-NETCONF Controller enables and facilitates communication to both RESTCONF/NETCONF devices while translating communication both ways!

Its usability and features can save you time and resources in a variety of telco related scenarios:

Data-Centers
OSS/BSS Integration (w/ NETCONF speaking devices & appliances)
Service Provider Networks (Access, Edge, etc.)
Central Office

Components

As the name suggests, it includes the RESTCONF northbound plugin and NETCONF southbound plugin at the bottom of the lighty.io controller.

At the heart of the application is the lighty.io controller. It provides core OpenDaylight services like MD-SAL, datastores, YANG Tools, handles global schema context, and more.

NETCONF southbound plugin serves as an adapter for NETCONF devices. It allows lighty.io to connect and communicate with them, execute RPCs, and read/write configuration.

RESTCONF northbound plugin is responsible for RESTCONF endpoints. These are used for communication between a user (or another application, like the aforementioned OSS/BSS systems, workflow managers, or ServiceNow for example) and the lighty.io application. RESTCONF gives us access to the so-called mount points serving as a proxy to devices.

These three mentioned components make up the core of the lighty.io RNC Application. Together, they form a base of the application. But of course, there is no such thing as one solution to rule them all.

Oftentimes, there is a need for side-car functionalities to the RNC, that is best built bespoke, that fulfill some custom business logic. Or enhance the RESTCONF API endpoints with side-load data.

We provide the means to customize and configure the lighty.io RNC application via configuration files to better fit your needs.

And if there is something we didn’t cover, do not hesitate to contact us or create a Pull Request or issue in our GitHub repository. We provide commercial custom development, developer, and operational support to enhance your efforts.

Configuration

You can find some common options in the JSON configuration file, like:

what address and port is RESTCONF listening to
what is the base URL of the RC endpoints to RESTCONF endpoints
what is the name of the network topology where NETCONF is listening
which YANG models should be available in the lighty.io app itself
and more

But wait! There is more!

There are some special configurations too with a bit bigger impact

One of them is an option to enable HTTPS for RESTCONF endpoints. When useHttps is set to true, HTTPS will be enabled. It is possible to specify a custom key-store too and we recommend doing so. But just for some tests default keystore should be more than enough.

The option enableAAA is used to enable the lighty-aaa module. This module is responsible for authorization, authentication, and accounting which for example enables to use Basic Authentication for RESTCONF northbound interface.

Generally, it’s a good practice to consider SDN controllers like this one as a stateless service. Especially in a complex and dynamic deployment with a bigger amount of services.

But if you want to initialize configurational datastore with some data right after startup, it’s possible with the “initialConfigData“ part of the configuration. For example, you insert connection information about a NETCONF device, so the lighty.io application will connect to it right after it starts.

Examples and a bit more explanation of these configuration options can be found in a lighty.io RESTCONF-NETCONF application README.md file.

Deployment

As mentioned in the beginning, we provide three main types of deployment: Helm chart for deployment in Kubernetes, Docker image, and a “zip” distribution containing all necessary jar files to run the application.

A step-by-step guide on how to build these artifacts from code can be found in a lighty.io RNC README.md file. It also contains steps on how to start and configure it.

Helm chart and Docker image can be also downloaded from public repositories.

Docker image can be downloaded from our GitHub Packages or via command:

docker pull ghcr.io/pantheontech/lighty-rnc:latest

Helm chart can be downloaded from our GitHub helm-charts repository and you can add it into your Helm environment via these commands:

helm repo add pantheon-helm-repo https://pantheontech.github.io/helm-charts/ 
helm repo update

Give lighty.io RNC a try

In case you need an SDN controller for NETCONF devices providing RESTCONF endpoints, give lighty.io RNC a try. The guides linked above should be pretty straightforward.

And if you need any help, got some cool ideas, or want to use our solutions, you can contact us here!

by Samuel Kontriš | Leave us your feedback on this post!

You can contact us here.

Explore our PANTHEON.tech GitHub.

Watch our YouTube Channel.