Tuesday, December 5, 2017

Whatever VNF manager you choose, Radiator VNF is ready for it

Interoperability and flexibility have been Radiator key features for over 20 years. When designing new Radiator VNF, these key features guided our design and implementation. Radiator VNF is designed to operate on multiple virtualisation platforms under its own, generic, or 3rd party orchestration.

Recently we have verified our design by integrating Radiator VNF with a 3rd party VNF manager just in few weeks – together with our operator customer and 3rd party vendor.

Designed for quick and flexible integration

At the very beginning of designing Radiator VNF, it was clear that we could not rely on one orchestration solution alone. Even on telco cloud there were already a multiple options for generic or 3rd party VNF manager and our vision was to be able to run Radiator VNF on top of other cloud infrastructures (Amazon, Google Cloud, etc.) as well. This lead to our decision to separate configuration management from orchestration solution.

Our own proof-of-concept orchestration solution, Radiator VNF Manager, is developed on top of Juju. Juju is also used in ETSI’s Open Source Mano reference orchestration solution. Radiator VNF Manager manages Radiator VNF when there is not a general or 3rd party orchestration solution available. We recommend that Radiator VNF is integrated with customer’s existing orchestration solution. As Radiator VNF is being deployed, we add support for more orchestration solutions according to customer needs. Our point of view is that while having several vendor-specific VNF managers is not a scalable way to orchestrate VNFs, a single well-chosen generic VNF manager is.
In the operator case, the operator chose a 3rd party VNF manager of a major infrastructure vendor, which made the case interesting for us to ensure Radiator VNF was able to integrate with this solution. Because of the Radiator VNF and Radiator VNF Manager architecture we were able to replace Juju with Heat- and Ansible based-vendor VNF manager. This image shows the architecture with Juju.

All we had to do was to ensure that vendor VNF manager managed properly creating and deleting the virtual hosts, and that its configuration management tool Ansible was able to bootstrap the configuration process on each host. The result was successful integration of Radiator VNF with vendor VNF manager within just few weeks. The following image shows the new architecture. This process can be repeated with other VNF managers and cloud infrastructures in the future.

However, technology is only one part of the process. In order to succeed with VNF manager integration, cooperation between the operator and vendors is crucial. In this example case, the operator participated in the integration testing and was able to help us to get into contact with the vendor to get the VNF manager specifications. This kind of cooperation is essential when developing interoperable products and services for NFV infrastructure. We thank all participants for cooperation in this case.

Would you like to know more?

We are happy to tell more about our way of implementing VNF projects and also about integrating Radiator VNF to your telco environment – also with 3rd party VNF managers and infrastructure.

If you would like to know, please contact info@radiatorsoftware.com.