Onboarding and orchestrating network functions with Open Source MANO (OSM)

Do I need to orchestrate my network functions? Well, the answer depends on the price-performance assumptions of your infrastructure and workloads. 

It seems like ages that NFV is trying to fulfill the promises of reducing CAPEX (Capital Expenditure) and OPEX (operating expenses) by decoupling Network Functions (NFs) from the hardware and ensuring stability. However, despite the huge traction it has gained, there are still obstacles that must be overcome before NFV can be part of day-to-day operations in industrial deployments. Telcos need to build complex virtualized network functions while maintaining a high quality of service (QoS) so onboarding them cost-effectively and implementing the process for management and orchestration remains one of the biggest challenges. Right now, this process can take up to weeks, and operators and vendors are striving to cut it to a day.

Network function onboarding is an automated methodology for bringing new network functions into an operational NFV environment so that they can be instantiated, scaled in and out, and fully utilized to deliver features. It includes modeling the network function so that its features and interfaces can be published to any NFV environment, interoperable with the selected MANO, and other adopted deployment and testing mechanisms by multiple VNF vendors. ETSI OSM is an operator-led community that is delivering an open source Management and Orchestration (MANO) stack aligned with ETSI NFV Information Models and that meets the requirements of production NFV networks. It helps accelerate your migration to NFV with network function onboarding and then ensuring the automated orchestration of the network functions.

Onboarding Stages

OSM (Open Source MANO) supports the onboarding of all types of network functions whether it is virtualized, containerized, or physical in nature. The stages for onboarding NFs (network functions) in OSM include creating the NF package that specifies Day-0 (basic instantiation), Day-1 (service initialization), and Day-2 (runtime operations) configurations. The Day-1 and Day-2 configurations are described in scripts called charms to run operations according to the functional requirements. These charms are then integrated into the network function descriptors/package and onboarded to OSM.

Day 0:

The Day-0 configuration refers to the instantiation of the network functions and the infrastructure setup that will be needed later in the onboarding process.

• Build an initial package compliant with the ETSI SOL006 standards and generate the packages using network service descriptors (NFD). It includes the basic configurations for the interconnections of network components.
• Integrate the cloud-init scripts in the descriptors for primary configurations needed to build up a network service like the OS boot requirements, setting up a hostname, adding SSH keys, configuring network devices and users. 
• Configure the virtualized infrastructure e.g. Openstack and enable the EPA (enhanced platform awareness) capabilities in the descriptors like Hugepages, CPU pinning, SR-IOV, or any other data accelerated features depending on the functional requirements.

Day 1

OSM component VCA (VNF configuration and abstraction) is responsible for the day-1 and day-2 operations and the driver behind the VCA is Juju. Charms are the operations code inside the network function descriptors and Juju manages these charms. Day-1 configurations initiate the service and ensure the expected functionality from the network functions. 

The process includes:

• Creating a charm as an operator for the network function.
• Defining the primitives/actions in charms that need to be performed right after the instantiation of service i.e. Initial charm configuration, authentication, and actions required during the service is up and running, etc.
• Integrating the configured charm in the OSM descriptors

Day 2

Juju is also responsible for the day-2 operations following the same day-1 process. The difference will be in the nature of primitives, as the day-2 actions are more focused on the runtime operations or the configuration required after instantiations of the network service which can be the following:

• Reconfigurations needed after the service is running
• Monitoring of the specific metrics for the infrastructure
• Scaling on the basis of monitoring analysis
• Operations to enable closed-loop automation.

After the onboarding, different orchestration capabilities like auto-scaling, auto-healing, self-monitoring, etc. can be tested according to the acceptance criteria of each network function to make it ready for production deployments.

How to build and onboard your own VNFs from scratch?

Register today, and bring your own network functions to the upcoming VNF onboarding hackfest to have hands-on experience of onboarding under the full-week supervision from OSM experts.  

Learn more

Create your first charm for customized operations of your network functions and reach out to the team on slack to discuss specific use cases.

Download the whitepaper to understand the OSM onboarding process in detail for your custom deployments