The telco world has been good all year. We’ve behaved, more or less. We only have one ask, and that is to get to a standard based NFV environment, such that all vendors can contribute and we can finally get the cost savings and flexibility we were promised. As such, can we please have a MANO stack that follows the ETSI NFV spec.
One such option, which is promising and pretty close, is Open Source Mano; OSM for short. OSM is an ETSI-hosted initiative to develop a software stack aligned with the ETSI NFV-architecture and realize the components needed for the architecture. The MANO layer is a combination of entities with the functions to manage and orchestrate the cloud infrastructure, its resources and services. In OSM the Service Orchestrator portion realizes the NFV-Orchestrator at the Network Service layer. The VNF-Manager comes to life through the Resource Orchestrator; both communicating with the Virtual Infrastructure Manager, which provides the interfaces between the ETSI-standard and the proprietary functions.
One thing we really like about OSM is that it interchangeably supports both OpenStack and VMWare vCloud Director cloud environments (as well as some public clouds). This makes it easy for us as a VNF-vendor; maturing our role in NFV, we can focus on our interface to OSM and OSM takes care of the complexities of dealing with the VIM.
Standard is key
We’re continuously improving our work and expect nothing less from the systems we’re supposed to rely on. The same goes for our work with OSM – errors and flaws discovered along the way are reported back and are corrected on an on-going basis. We are happy that ETSI is poised to make the OSM VNF Descriptor (Yang based) a standard. However, it is troubling that ETSI is then supporting two conflicting standards for VNF Descriptors, since VNF vendors will now have to develop, release and support two different universes.You could argue that OSM comes with a generic VNF-M, which we like, but it’s not clear how this VNF-M would use the ETSI SOL-002 interface (i.e communicating to the VNF and the EM).
They say it’s the inside that counts
Despite being in its infancy, we think OSM has great potential – open source and the fact that anyone can contribute to the code is a major asset. The downside is that the number of meaningful contributors is limited which creates sensitivity to disruption and delays, even though critical mass is within reach.
Recently, the public cloud giant AWS joined the OSM; it will be interesting to see what their vast cloud experience and software base can bring to the table. OSM is also relatively lean in code and footprint. To run the latest release, you need a minimum of 4 vCPU, 16 GB RAM, 40GB storage and a single interface with internet access. By way of comparison, ONAP requires a minimum of 29 VM, 148 vCPU, 336GB RAM, 3TB storage and 29 floating IPs. Of course, the scope of ONAP is larger, but if “simple” orchestration is what you need, it’s still the better fit.
Even though it is lean, OSM does support the fundamentals of a structured and automatable process to move from images and templates to orchestrated virtual network functions in a network service. Although that does not sound convincing, it is the first full MANO stack that we have encountered where NFV theory and standards have been replaced with legitimate functionality, such as:
- Descriptors - There is a VNF descriptor format, and you can write what you need using them.
- Network Service(s) - There is a concept of a Network Service, and you can instantiate one with the virtual networks and VNF you define.
- VIM Support - It can deploy this on OpenStack or VMWare vCloud director,
- Day Zero config – It can give VNF instances a day-zero configuration using Cloud-Init.
When we believe in a project, we want to help it along, which is why we are dedicating engineers to work with OSM and take an active role in its development. Prior to, and since, the very successful ETSI Plugfest at 5Tonic last January, we’ve been actively contributing to the project, validating VNFs and testing the OSM releases. Sandvine engineers have been active contributors in OSM since 2016, contributing to the Module Development Group (MDG), DevOps support, and ensuring verification and reviews prior to merging new contributions. There is also focus on the implementation of Continuous Integration and Delivery (CI/CD) practices in this work.
Given our Standards Body participation, Sandvine is in a position to contribute to both OSM and ONAP and we’ll do everything in our power to help both of these projects along.
If you want to play with this, you can download the PacketLogic OSM release from our download site. Contact your Sandvine sales representative to receive a licence.