VOLTHA, SEBA, OSAM and ONAP with Cloudify for End-to-End Provisioning and Lifecycle Management of Access Devices

Introduction

The industry is pushing to make the access world simple with “Access as a service.” Today, each access vendor has its own implementation and many silos exist on dedicated hardware. The motivation is to introduce an access architecture which is open, that potentially runs on commodity servers and whitebox switches, and is based on SDN/NFV technologies.

Read about ONAP use cases and its rise to the top of the open networking automation industry!   Download

CORD

As a result, the CORD project from ONF is focused on disaggregation of functions, and specifically the VOLTHA project, which stands for Virtual OLT Hardware Abstractions, on disaggregation of the Passive Optical Network (PON) to functional modules and creation of an abstraction layer to which every vendor will be able to map. This means that upper layers will have common APIs and are not impacted by changes introduced to the hardware or vendor-specific drivers.

PON/GPON

This trend started with PON/GPON which is an optical access network and can provide fast internet and has a vast range of content applications.

SEBA

The next move, which happened very recently, was to move one step further and generalize all access technologies – and so SEBA emerged. SEBA stands for SDN Enabled Broadband Access. Here is how the SEBA architecture looks.

The SEBA and VOLTHA projects are both part of CORD, which itself is an ONF project that many vendors and telcos are involved in. Both VOLTHA and SEBA are designed to manage one access “box”. Each box could be considered a virtual switch as well as an edge device. We will discuss managing multiple access edges in just a bit. First, let’s talk about the lifecycle management of SEBA,

SEBA lifecycle management

Creating the architecture and even writing the software packages (open source) is mandatory, but not the final stage. You need an edge environment to run on, and to provision all the software packages as well as the HAL (hardware abstraction layer), the ONOS SDN controller, the NEM XOS, etc. And of course, there are dependencies to account for between the components.
For the access edge platform there are a couple of options: one is to use Akraino to define the edge blueprint and the other is to use bare metal. Many Telcos prefer the second option, but both are viable.
So, what does the access edge stack look like? Very simple – Kubernetes on bare metal machines.

Cloud Native Edge Controller

Provisioning Kubernetes on bare-metal machines is the basis for the access edge platform. A typical installation would be a few bare-metal machines in the Central Office (CO) and Cloudify can provision Kubernetes on top of it.
See this Cloudify blueprint that can be used to provision K8s. You provide the IP addresses in a static way.
If you need a more dynamic way to manage the bare-metal machines, including scaling / adding more nodes to K8s, Cloudify has implemented a “host pool” which could be utilized for this purpose as can be found in this blueprint.
In order for those blueprint to run you have to first install Cloudify Manager.
The next step is to use Helm Charts to provision the SEBA components. For that we use a TOSCA Helm type created for the purpose of provisioning Helm Chart packages on top of Kubernetes. Here is the blueprint that provisions the VOLTHA abstraction layer component, and it has a prerequisite of having the SEBA repo installed and pointed to by the ‘cwd’ input variable of the voltha.yaml blueprint. The SEBA Helm Charts repo can be found here as part of the open CORD project.
LCM includes provisioning, startup in a certain dependency order, and configuration of the different components, ensuring everything is validated and configured correctly.
Now, after the access SEBA device is provisioned, you can collect KPIs from its platform or from its applications. You can run Day-2 scenarios like upgrade or reconfigure components as well as heal the device or scale some of its components if needed. Bear in mind that you can distribute the components over multiple Kubernetes nodes if required.

Managing multiple distributed SEBA devices

A great way to start with managing multiple SEBA access device assets would be by visually displaying them on a map or in a tabular view. Below is an example of one such set up where each SEBA device is discovered and presented on a Google map.

Users can drill down to each location/device and see the OLTs status in a traffic light (green, yellow, or red) fashion. On the upper right side there are newly discovered SEBA devices.
Drilling down to each one of the locations you can visualize more KPIs and FCAPS statistics for that specific location.
Using Cloudify, you can create policies based on multiple events and KPIs, which in turn invoke a workflow that can traverse the TOSCA nodes that represent the SEBA devices in real-time and apply operations like healing, scaling, reconfigure, restart upgrading, etc.

ONAP / OSAM Orchestration

There is a special project called OSAM, which stands for Open Source Access Manager, and its intent is to integrate with ONAP for orchestration. For the sake of simplicity, each SEBA device is considered a “black-box”, or a PNF.
OSAM defines the flows and scenarios, such as adding a subscriber or activating an OLT, in a SEBA device. OSAM still needs additional work and could use Cloudify as its main vehicle for orchestrating such scenarios.

Cloudify is already part of ONAP, being used to provision ONAP as part of the ONAP Operational Manager (OOM). Cloudify is also being used as part of the Service Orchestrator (SO) as follows: when you create artifacts in SDC it produces a TOSCA CSAR file, which in turn is used by the ONAP SO to call one of the VDU plugins, in this case Cloudify, which in turn invokes the provisioning of Kubernetes on bare-metal machines in the CO and the provisioning of SEBA on top of Kubernetes. You can provision multiple SEBA devices and play with the PONSIM to simulate activity.

Cloudify is also the DCAE controller in ONAP.

The end-to-end operational picture

The end-to-end operational picture is more complex and includes connections to multiple backend services like a Portal, Subscriber Management, Billing and other systems. I will elaborate more on this topic and how Cloudify can connect them all in an upcoming blog post.
Cloudify comes with a UI with widgets (you can also customize widgets) that can visualize KPIs collected from the SEBA devices.

Cloudify Labs

We have built a bare-metal lab or rather, a VM-based lab that simulates bare-metal, and can provide access to vendors and telcos to provision and play with a SEBA provisioned device on top of Kubernetes, simulate activity using the PONSIM module and basically have your own controlled SEBA lab with a click of a button.
Check out the Cloudify Labs to start free testing in a live environment.