ETSI-based open source NFV platform tips OSM Releases 4 and 5 that bring more stability, testing and convenience.
The Open Source Management and Operations (OSM) project, an initiative hosted by the standards group ETSI, gave workshop attendees at NFV-Zero Touch World Congress a sneak peek into Releases 4 and 5 of OSM in San Jose, Calif., last week. Release 4 is in production readiness and will be released in next few weeks, according to OSM’s chairperson.
Ninety-five companies are part of OSM today, said Francisco Javier Ramón Salguero, ETSI-OSM chair and head of virtualization at Telefónica, who presented about OSM at NFV-Zero Touch World Congress. “How come so many people are using this? Because it works and provides a lot of functionality already. Release 2 and 3 already brought a lot of functionality.”
OSM will add catalogs of VNFs, sweat tests, telemetry monitoring, better documentation, and containers for VNFs (Rel. 5), among other features.
OSM is an open source management and orchestration (MANO) stack free for the industry to use in setting up and managing virtual networks. The platform is aligned with ETSI NFV Information Models and is still in development, via an open source community. The people leading the efforts have day jobs in the telecom industry but are passionate about creating this standards-based, open source platform for virtualizing network functions. ETSI and OSM hold OSM plugtests several times a year that get OSM community meeting and testing the platform.
The goal is to automate certain cumbersome network tasks, stop reinventing the wheel and help the industry ease the burden of managing complex networks as it ramps up for 5G.
The components of OSM are designed to be as generic as possible so network operators can switch out more specific components as needed. “An important thing to note is that all MANO platforms included a generic VNF manager,” says Gianpietro Lavado, a telecommunications specialist, writing on LinkedIn. “This means that even though there is room for specific VNF managers at the standards, where a VNF brings its own manager.“
Many telecom companies create their own methods and software for NFV, but some companies such as Telefónica are supportive of standardizing and want to use open-source MANOs across industry to save money and increase production.
OSM efforts started in 2016 and are now at Release 3.
The architecture has evolved so it now includes modules such as resource orchestrators, monitoring, VNR configuration and abstraction, user interface. OSM divides the tasks into design-time and run-time components. Dev Ops, a design-time component, is where the testing is done. The main components of the system map back to ETSI standards.
“We also have a service orchestrator module,”explained Vanessa Little, OSM technical steering committee member and director of ecosystem architecture, VMware. She reviewed OSM’s architecture and Release 4 updates in a presentation at NFV-Zero Touch World Congress. “This is where the catalog management, the VNF onboarding and the network service description and modeling happens. And this is where this is maintained and executed.”
The monitoring tool will collect telemetry from the other modules.
The user interface module can be implemented in several ways as UI. “We also have the OSM client which is a command line interface as well as that SOL05 compliant northbound API,” said Little.
Here are the highlights from the presentations at NFV-Zero Touch World Congress.
Release 4 brings telemetry, stress tests
“Consistent themes that you will see in all our releases are service assurance, usability, security, and resiliency as well as improving our CI/CD pipeline,” said Little.
She summed up the Release 4 highlights:
Ecosystem development
“We are trying to build catalogs of validated VNFs with published descriptors that are available to the public so that that job and that task of building those Yang models and those Jama files to create the onboarding scripts and packages is no longer that difficult,” said Little. “We are building a library of pre-validated ones that can just be downloaded and used.”
Automated regression tests that occur only at final stages
“The code base is growing larger and larger and so doing complete manual regression tests at the end of each release is getting more and more cumbersome for the community to do.” said Little in her presentation. “It became very more important for us to build the CI/CD pipeline, automate those tasks so we are not doing a complete manual regression test at the end of every release but that we are doing spot tests of each feature as they are added, each component it is added. And then a complete regression test that is totally automated at the end. This is making it a lot easier for us to accelerate our development and add more features more quickly.”
Documentation
“We are also shoring up all the documentation. As with all open source communities, the early stages of this project had sub-optimal documentation. Now that we are coming up to Release 4 we are really recognize the requirement of having to validate documentation that describes the entire platform not only at the code level but from the user perspective how to operate the platform once it is deployed,” said Little.
Data models vs. information models
“The information versus the data model: when we mentioned this component is SOL05 compliant, this is X-MANO compliant, what we mean is that we are consuming the standards as they are coming out of ETSI where they are appropriate to this project and implementing those standards as are feasible. So, when you look at the information model, what we mean here is the ETSI NVF, Phase 1 MANO, the Phase 2, the IFA standards, IFA011 and IFA014,” explained Little. “But when you move down to the data models, when you actually look at the Yang models that build the descriptors for our VNFs and for our network services, those are data models. In the case of OSM, those are implemented in Yang. But other data models are the models coming out of Oasis — Tosca or heat templates that are currently being used by ONAP.” Eventually OSM will move to the ETSI-NFV SOL01 data model, which Little called the Holy Grail of all data models.
“We are hoping that the community ratifies that specification as soon as possible, because everyone would love to adopt it. It is currently the most robust data model and we at OSM are leaning toward adopting that as our defacto standard data model going forward,” she said.
