PANTHEON.tech continues to develop its Cloud-Native Network Functions portfolio with the recent inclusion of Intermediate System-to-Intermediate System (IS-IS) routing support, based on FRRouting. This inclusion complements and augments our current Stonework Enterprise routing offerings, providing customers with a choice of the usual networking vendors’ solutions.

Leveraging FRRouting, a Linux Foundation, open-source, industry-leading project, PANTHEON.tech provides a comprehensive suite of routing options. These include OSPF, BGP, and now IS-IS, which can fully integrate and interoperate with existing, or new, networking requirements.

As a cloud-native network function, our solution is designed to maximize container-based technologies and micro-services architecture.

We provide IS-IS feature to our customers with the following options:

• IS-IS CNF – Standalone CNF appliance with IS-IS support
• Stonework Enterprise – Security, switching, and routing features, now with IS-IS support

StoneWork Enterprise & IS-IS Integration

The control plane is based on a Ligato agent, which configures every aspect of FRR. The two protocols, OSPF & IS-IS, are running on separate daemons. Information (routes) are stored in Zebra (FRR IP routing manager), which translates these routes to the Linux kernel, towards the default Linux routing table.

The data plane forwards this information via a TAP tunnel, towards a VPP instance (supporting IS-IS & OSPF), which together with another Ligato agent in the StoneWork container enables OSPF & IS-IS functionality in a FRRouting, cloud-native network function.

With the power of containerization and enterprise-grade routing protocols, StoneWork Enterprise enables network service providers to easily get on board with cloud-native acceleration and enjoy all of its benefits.

What is FRRouting?

FRRouting (FRR) is a completely open-source internet routing protocol suite, with support for BGP, OSPF, OpenFabric, and more. FRR provides IP routing services, routing & policy decisions, and general exchange of routing information with other routers. Its incredible speed is achieved by installing routing decisions directly into the OS kernel. FRR supports a wide range of L3 configurations and dynamic routing protocols, making it a flexible and lightweight choice for a variety of deployments.

The magic of FRR lies within its natural ability to integrate with the Linux/Unix IP networking stack. This in turn allows for the development of networking use-cases – be it LAN switching & routing, internet access routers or peering, and even connecting hosts/VMs/containers to a network. It is hosted as a Linux Foundation collaborative project.

What is the IS-IS protocol?

The Intermediate System to Intermediate System is one of the most commonly deployed routing protocols across large network service providers and enterprises.

Specifically, it is an interior gateway protocol (IGP), used for exchanging router information within an autonomous system. IS-IS operates over L2 and doesn’t require IP connectivity and provides more security. It is more flexible and scalable than the OSPF protocol.

While different use-cases might require a substitution for IS-IS, our StoneWork Enterprise solution has recently enabled IS-IS integration as part of FRRouting, including a possible IS-IS CNF (Cloud Native Network Function) – standalone appliance.

Buy StoneWork Enterprise today!

If you are interested in StoneWork Enterprise, make sure to contact us today for a free, introductory consultation!

StoneWork is a high-performance, all-(CNFs)-in-one network solution.

Thanks to its modular architecture, StoneWork dynamically integrates all CNFs from our portfolio. A configuration-dependent startup of modules provides feature-rich control plane capabilities by preserving a single, high-performance data plane.

This way, StoneWork achieves the best-possible resource utilization, unified declarative configuration, and re-use of data paths for packet punting between cloud-native network functions. Due to utilizing the FD.io VPP data plane and container orchestration, StoneWork shows excellent performance, both in the cloud and bare-metal deployments.

by PANTHEON.tech | Leave us your feedback on this post!

You can contact us here!

Explore our PANTHEON.tech GitHub.

Watch our YouTube Channel.

Join us in reminiscing and reminding you, what PANTHEON.tech has managed to create and participate in 2021.

Most significantly, PANTHEON.tech has celebrated 20 years of its existence.

We have participated in two conferences this year, validated our position within the OpenDaylight community, and expanded our product portfolio!

lighty.io: Releases & Tools

The lighty.io team at PANTHEON.tech has gone through several releases in 2021, as well as a bunch of tools to accompany it along the way!

lighty.io RESTCONF-NETCONF Controller

• Out-of-the-box
• Pre-packaged
• Microservice-ready application

Easily use for managing network elements in your SDN use case.

You can read more about the project on our dedicated GitHub readme, or in the in-depth article below:

lighty.io YANG Validator

Create, validate and visualize the YANG data model of their application, without the need to call any other external tool – just by using the lighty.io framework.

YANGinator | Validate YANG files in IntelliJ

Built for one of the most popular IDEs, YANGinator is a plugin for validating YANG files without leaving your IDEs window!

Visit the project on GitHub, or on the official marketplace.

Conferences & Events

PANTHEON.tech has sponsored and attended two conferences this year. Broadband World Forum in Amsterdam, and Open Networking & Edge Summit + Kubernetes on Edge Day, which was ultimately held in a virtual environment.

Our network controller SDK, lighty.io, was mentioned during the OCP Global Summit, as part of a SONiC Automation use-case.

lighty.io was also part of the first-ever, production deployment of ONAP by Orange.

News, Blogs & Use-Cases

We encourage you to read through over 28 original posts on our webpage. The topics range from explanations of recent network trends to interesting use-cases for enterprises.

Lanner Inc. has established a partnership with PANTHEON.tech to successfully validate StoneWork’s all-in-one Cloud-Native Functions solution on Lanner’s NCA-1515 uCPE Platforms.

PANTHEON.tech has been recognized as a member of the Intel Network Builders program Winners Circle. 

Pantheon Fellow and one of the elite experts on OpenDaylight, Robert Varga, was invited for a podcast episode with the Broadband Bunch!

CDNF.io | A cloud-native portfolio

Our cloud-native network functions portfolio, CDNF.io, includes a combined data/control plane – StoneWork – and 18 CNFs.

Learn more about this expanding project by visiting its homepage, CDNF.io, or contact us directly to explore your options.

SandWork| Automate & Orchestrate Your Network

The ultimate network orchestration tool for your enterprise network. This Smart Automated Net/Ops & Dev/Ops platform orchestrates your networks with a user-friendly UI. Manage hundreds to thousands of individual nodes with open-source tech and enterprise support & integration.

Contact us to learn more about SandWork!

On the 11th of November, Orange hosted a webinar with The Linux Foundation, showcasing their production deployment of ONAP to automate their IP/MPLS transport network infrastructure.

Learn how to containerize and deploy your own lighty.io RNC instance in this tutorial!

PANTHEON.tech is extremely proud to see their OpenDaylight based lighty.io project, included in this, Orange’s first, successful production ONAP deployment. lighty.io is an open-source project developed and supported by PANTHEON.tech.

Open-Source Matters

Orange’s vision and target are to move from a closed IT architecture to an open platform architecture based on the Open Digital Framework, a blueprint produced by members of TMForum. ONAP provides ODP compliant functional blocks to cover the delivery of many use-cases like service provisioning of 5G transport, IP, fixed access, microwave, optical networks services, as well as CPE management, OS upgrades, and many others.

Why lighty.io?

The SDN-C is the network controller component of ONAP – managing, assigning, and provisioning network resources. It is based on OpenDaylight, with additional Directed Graph Execution capabilities. However, lighty.io, PANTHEON.tech’s enhanced OpenDaylight based software, offers significant benefits in performance, agility, and availability, taking SDN-C to another level.

OpenDaylight vs. lighty.io

As the ongoing lead contributor to Linux Foundation’s OpenDaylight, PANTHEON.tech develops lighty.io, with the ultimate goal of enhancing the network controller experience for a variety of use-cases.

With increased functionality to upgrade dependencies and packaged use-case-based applications, lighty.io brings Software-Defined Networking to a Cloud-Native environment.

lighty.io offers a modular and scalable architecture, allowing dev-ops greater flexibility to deploy only those modules and libraries that are required for each use-case. This means that lighty.io is not only more lightweight at run time, but also more agile at development and deployment time.

And since only the minimum required set of components and libraries is present in a deployment at runtime, stability is enhanced as well.

Due to its modular capability, lighty.io provides a stable & scalable network controller experience, ideal for production deployments, enabling the burgeoning multitude of 5G/Edge use cases.

A reduced codebase footprint and packaging makes lighty.io more:

• Lightweight
• Agile
• Stable
• Secure
• Scalable

PANTHEON.tech also provides other complementary tools, plugins, and additional features, like:

• Java Protocol libraries
• Network Simulators
• YANG Validators
• Pre-packaged, container use-case driven application, with Helm charts
  • lighty.io RESTCONF-NETCONF Application
  • lighty.io RESTCONF-gNMI Application

 Orange Egypt: ONAP Production Deployment

Orange Egypt uses ONAP as a northbound, higher-level orchestration, for L3VPN service provisioning.

The user leverages a GUI to enter network service parameters. The request is then submitted to the ONAP Service Orchestrator (SO), powered by Camunda‘s BPMN workflow engine, through a REST API and custom-designed workflow is executed.

Afterward, an instantiated ONAP SO workflow triggers the ONAP Controller Design Studio (CDS) using a REST API to run custom blueprint packages to start the provisioning of L3VPN network services.

In this production deployment, lighty.io is used for communication between CDS and Cisco NSO. The application used in the ONAP production deployment is lighty-RNC – a pre-packaged container image, providing a RESTCONF-NETCONF bridge.

CDS assigns required resources (IP + VLAN) from NETBOX and lighty.io secret from Vault. After successful allocation of needed resources by CDS, lighty.io then sends the information to Cisco NSO to configure devices via a NETCONF session.

Source: YouTube, LFN Webinar: Orange Deploys ONAP In Production

Future of ONAP

Orange demonstrated ONAP in an IP/MPLS backbone automation use-case, but that is just the beginning. ONAP is already starting to look into automation and SDN control of microwave and optical networks, paving the way for other operators to deploy ONAP in their use cases.

You can watch the entire webinar here:

by PANTHEON.tech | Leave us your feedback on this post!

You can contact us here!

Explore our PANTHEON.tech GitHub.

Watch our YouTube Channel.

The 15th release of lighty.io is here, bringing a bunch of new features and even more improvements for you to create your SDN controller.

Parallel to working on OpenDaylight – PANTHEON.tech being the largest contributor to the OpenDaylight Phosphorus release – our team was working hard on releasing the newest version of lighty.io.

Of course, lighty.io adopted the latest Phosphorus upstream. So let’s have a look at what else is new in lighty.io 15!

[Feature] lighty.io gNMI Module – Simulator

The latest addition to lighty.io modules is the gNMI module for device simulation. This simulator simulates gNMI devices driven by gNMI proto files, with a datastore defined by a set of YANG models. gNMI is used for the configuration manipulation and state retrieval of gNMI devices.

The gNMI Simulator supports SONiC gNOI, to the extent of the following gNOI gRPCs:

• file.proto:
  • get – downloads dummy file
  • stat – returns stats of file on path
• system.proto:
  • time – returns current time
• and these RPCs

Furthermore, we introduced the gNMI Force Capability, for overwriting used capabilities of gNMI devices in the gNMI SouthBound plugin.

[Use-Case] lighty.io gNMI/RESTCONF & Simulator

Our team also prepared a guide for quick-starting a pre-prepared gNMI/RESTCONF application with the gNMI device simulator.

Hand-in-hand, the lighty.io RESTCONF gNMI App now provides Docker & Helm support, for deployment via Kubernetes.

The example shows a gNMI south-bound interface, utilized with a RESTCONF north-bound interface to manage gNMI devices on the network.

This example works as a standalone SDN controller and is capable of connecting to gNMI devices and exposing connected devices over RESTCONF north-bound APIs.

[Improvements] Deprecations & Fixes

• lighty.io RNC received a Postman collection for users to edit and bend for their own use.
• We removed the OpenFlow plugin (in-line with future plans for OpenFlow in OpenDaylight), as well as the NETCONF-Quarkus App for lighty.io.
• lighty-codes are now fully replaced by lighty-codecs-utils. 
• A major cleanup of modules and their references was done as well.
• Improvements were made for GitHub Workflows & SonarCloud reported issues, for code stability and hardening. 

Give lighty.io 15 a try and let us know what you think!

by the lighty.io Team| Leave us your feedback on this post!

You can contact us here!

Explore our PANTHEON.tech GitHub.

Watch our YouTube Channel.

The lighty.io gNMI RESTCONF app allows for easy manipulation of gNMI devices. PANTHEON.tech has open-sourced the gNMI RESTCONF app for lighty.io, to increase the capabilities of lighty.io for different implementations and solutions.

Imagine CRUD operation on multiple gNMI devices, managed by one application – lighty.io. All requests towards the gNMI devices are executed by RESTCONF operations, while the response is formatted in JSON.

The most important lighty.io components used in the lighty.io gNMI RESTCONF application are:

• lighty.io Controller – provides core OpenDaylight services (MD-SAL, YANG Tools, Global Schema Context & more) that are required for other services or plugins
• lighty.io RESTCONF Northbound – provides the RESTCONF interface, used for communication with the application, via the RESTCONF protocol over HTTP
• lighty.io gNMI Southbound – acts as the gNMI client. Manages connections to gNMI devices and gNMI communication. Currently supported gNMI capabilities are Get & Set

Prerequisites

To build and start the lighty.io gNMI RESTCONF application locally, you need:

•  Java 11 or later
•  Maven 3.5.4 or later

Custom Configuration

Before the lighty gNMI RESTCONF app creates a mount point for communicating with the gNMI device, it is necessary to create a schema context. This schema context is created, based on the YANG files which the device implements. These models are obtained via the gNMI Capability response, but only model names and versions are actually returned. Thus, we need some way of providing the content of the YANG model.

The way of providing content for the YANG file, so lighty.io gNMI RESTCONF can correctly create schema context, is to:

• add a parameter to the RCGNMI app .json configuration
• use upload-yang-model RPC

Both of these options will load the YANG files into the data-store, from which the ligthy.io gNMI RESTCONF reads the model, based on its name and version, obtained in the gNMI Capability response.

YANG Model Configuration as a Parameter

1. Open the custom configuration example in src/main/resources/example_config.json
2. Add custom gNMI configuration in root, next to the controller or RESTCONF configuration

 ```
      "gnmi": {
        "initialYangsPaths" : [
          "INITIAL_FOLDER_PATH"
        ]
      }
    ```
    3. Change `INITIAL_FOLDER_PATH`, from JSON block above, to folder path, which contains YANG models you wish to
    load into datastore. These models will be then automatically loaded on startup.

2) Add yang model with RPC request to running app
- 'YANG_MODEL' - Should have included escape characters before each double quotation marks character.
```
curl --request POST 'http://127.0.0.1:8888/restconf/operations/gnmi-yang-storage:upload-yang-model' \
--header 'Content-Type: application/json' \
--data-raw '{
    "input": {
        "name": "openconfig-interfaces",
        "semver": "2.4.3",
        "body": "YANG_MODEL"
    }
}'
```

Start the gNMI RESTCONF Example App

1. Build the project using:

mvn clean install

2. Go to the target directory:

cd lighty-rcgnmi-app/target

3. Unzip example application bundle:

unzip  lighty-rcgnmi-app-14.0.1-SNAPSHOT-bin.zip

4. Go to the unzipped application directory:

cd lighty-rcgnmi-app-14.0.1-SNAPSHOT

5. To start the application with a custom lighty.io configuration, use arg -c. For a custom initial log4j configuration, use the argument -l:

start-controller.sh -c /path/to/config-file -l /path/to/log4j-config-file

Using the gNMI RESTCONF Example App

Register Certificates

Certificates, used for connecting to a device, can be stored inside the lighty-gnmi data store. The certificate key and passphrase are encrypted before they are stored inside the data store.

After registering the certificate key and passphrase, it is not possible to get decrypted data back from the data store.

curl --request POST 'http://127.0.0.1:8888/restconf/operations/gnmi-certificate-storage:add-keystore-certificate' \
--header 'Content-Type: application/json' \
--data-raw '{
    "input": {
        "keystore-id": "keystore-id-1",
        "ca-certificate": "-----BEGIN CERTIFICATE-----
                              CA-CERTIFICATE
                          -----END CERTIFICATE-----",
        "client-key": "-----BEGIN RSA PRIVATE KEY-----
                                CLIENT-KEY
                      -----END RSA PRIVATE KEY-----",
        "passphrase": "key-passphrase",
        "client-cert": "-----BEGIN CERTIFICATE-----
                              CLIENT_CERT
                        -----END CERTIFICATE-----"
    }
}'

Remove Certificates

curl --location --request POST 'http://127.0.0.1:8888/restconf/operations/gnmi-certificate-storage:remove-keystore-certificate' \
--header 'Content-Type: application/json' \
--data-raw '{
    "input": {
        "keystore-id": "keystore-id-1"
    }
}'

Update Certificates

To update the already existing certificates, use the request for registering a new certificate with the keystore-id you wish to update.

Connecting a gNMI Device

To establish a connection and communication with the gNMI device via RESTCONF, one needs to add a new node to gnmi-topology. This is done by sending the appropriate requests (examples below) with a unique node-id.

The connection parameters are used to specify connection parameters and the client’s (lighty gNMI RESTCONF) way of authenticating.

The property connection-type is enum and can be set to two values:

• INSECURE: Skip TLS validation with certificates
• PLAINTEXT:  Disable TLS validation

When the device requires the client to authenticate with registered certificates, remove the connection-type property. Then, add the keystore-id property with the ID of the registered certificates.

If the device requires username/password validation, then fill username and password in the credentials container. This container is optional.

In case the device requires additional parameters in the gNMI request/response, there is a container called extensions-parameters, where a defined set of parameters can be optionally included in the gNMI request and response. Those parameters are:

• overwrite-data-type is used to overwrite the type field of gNMI GetRequest.
• use-model-name-prefix is used when the device requires a module prefix in the first element name of gNMI request path
• path-target is used to specify the context of a particular stream of data and is only set in prefix for a path

curl --request PUT 'http://127.0.0.1:8888/restconf/data/network-topology:network-topology/topology=gnmi-topology/node=node-id-1' \
--header 'Content-Type: application/json' \
--data-raw '{
    "node": [
        {
            "node-id": "node-id-1",
            "connection-parameters": {
                "host": "127.0.0.1",
                "port": 9090,
                "connection-type": "INSECURE",
                "credentials": {
                    "username": "admin",
                    "password": "admin"
                }
            }
        }
    ]
}'

Create a Mountpoint with Custom Certificates

curl --request PUT 'http://127.0.0.1:8888/restconf/data/network-topology:network-topology/topology=gnmi-topology/node=node-id-1' \
--header 'Content-Type: application/json' \
--data-raw '{
    "node": [
        {
            "node-id": "node-id-1",
            "connection-parameters": {
                "host": "127.0.0.1",
                "port": 9090,
                "keystore-id": "keystore-id-1",
                "credentials": {
                    "username": "admin",
                    "password": "admin"
                }
            }
        }
    ]
}'

Get State of Registered gNMI Device

curl --request GET 'http://127.0.0.1:8888/restconf/data/network-topology:network-topology/topology=gnmi-topology/node=node-id-1'

[Example] RESTCONF gNMI GetRequest

curl --location --request GET 'http://127.0.0.1:8888/restconf/data/network-topology:network-topology/topology=gnmi-topology/node=node-id-1/yang-ext:mount/openconfig-interfaces:interfaces'

[Example] RESTCONF gNMI SetRequest

curl --request PUT 'http://127.0.0.1:8888/restconf/data/network-topology:network-topology/topology=gnmi-topology/node=node-id-1/yang-ext:mount/interfaces/interface=br0/ethernet/config' \
--header 'Content-Type: application/json' \
--data-raw '{
    "openconfig-if-ethernet:config": {
        "enable-flow-control": false,
        "openconfig-if-aggregate:aggregate-id": "admin",
        "auto-negotiate": true,
        "port-speed": "openconfig-if-ethernet:SPEED_10MB"
    }
}'

Disconnect gNMI Device

curl --request DELETE 'http://127.0.0.1:8888/restconf/data/network-topology:network-topology/topology=gnmi-topology/node=node-id-1'

[RESTCONF] gNMI Operations Mapping

The supported HTTP methods are listed below:

For each REST request, the lighty.io gNMI  RESTCONF app invokes the appropriate gNMI operation GnmiSet/GnmiGet to process the request.

Below is the mapping of HTTP operations to gNMI operations:

[RESTCONF] GET Method Mapping

In both cases, we will be reading data, but from different data stores.

• Reading data from the operational datastore invokes readOperationalData() in GnmiGet:

src/main/java/io/lighty/gnmi/southbound/mountpoint/ops/GnmiGet.java

• Reading data from the configuration datastore invokes readConfigurationData() in GnmiGet:

src/main/java/io/lighty/gnmi/southbound/mountpoint/ops/GnmiGet.java

[RESTCONF] PUT/POST/PATCH/DELETE Method Mapping

• Sending data to operational/configuration datastore invokes method set() in GnmiSet:

src/main/java/io/lighty/gnmi/southbound/mountpoint/ops/GnmiSet.java

A list of input parameters come from method request in the form of fields of update messages: update, replace, and delete fields.

• PUT/POST request method sends update messages through two fields: update and replaces fields
• PATCH request method sends update messages through the update field
• DELETE request method sends update messages through the delete field

Further Support & Questions

PANTHEON.tech open-sourced lighty.io a while ago, giving the community a unique chance to discover the power of lighty.io in their SDN solution.

If you require enterprise support, integration, or training, make sure to contact us so we can help you catch up with the future of networking.

by Martin Bugáň, Ivan Čaládi, Peter Šuňa & Marek Zaťko

As part of our commitment to improve & develop ONAP functionality, PANTHEON.tech has introduced Performance Testing to the ONAP Configuration Persistence Service (CPS) component.

The test flow included the following operations:

• Create a new anchor with a unique name in the given dataspace
• Create data node – full data tree upload for a given anchor
• Update data node – node fragment replacement
• Remove anchor (and associated data)

This Performance Testing will make testing deployments easier and show, whether the optimization is needed or achieved.

You can download the first-ever, CPS Performance Testing report here:

What is CPS in ONAP?

The Configuration Persistence Service component serves as a common data layer service, which preserves network-element runtime information, in form of database functionality. This runtime data, or information, needs to be persistent, so CPS provides a data repository for this data – this can include operational data.

CPS Performance Testing Environment

Businesses may rely on the ability to visualize and manage this data in their RAN network. So essentially, the goal of CPS is to improve the operation of data handling within ONAP – with better, efficient data layer services.

Use-cases for CPS are universal since the project is able to be utilized in Edge or core ONAP deployments, where a database is deployed with each installation. Proposed use-cases also include Edge-2-Edge Network Slicing. Not to mention the OPEX you will be saving on.

Our Commitment to Open-Source

Yes, we are the largest contributor to OpenDaylight. But we also contribute code to FD.io VPP or ONAP, amongst others. We see open-source as “a philosophy of freedom, meaningfulness, and the idea that wisdom should be shared”, as we mentioned in another post. And we will continue to work with the wonderful communities of projects we have close at heart.

by Ruslan Kashapov | Leave us your feedback on this post!

You can contact us here.

Explore our PANTHEON.tech GitHub.

Watch our YouTube Channel.