Network Services Orchestration — Challenges for Infrastructure agnostic ZTP MANO Orchestration package & current workaround package design practices

Network service orchestration has come some way now from the time when network orchestration using MANO was more of a theory concept being studied on & undergoing preliminary POC to today where it’s getting adopted in multiple large scale network transformation & modernization POCs & customers environments specially as part of 5G adoption & its associated use cases.

As the benefits of network orchestration have started getting observed, conversation has started now about possibility of having infrastructure agnostic ZTP (Zero Touch provisioning) packages i.e. having single orchestration package that can be used to implement a network service/function or application e.g. 4G,5G, SDWAN, MEC, Firewall, etc on any infrastructure (bare metal or cloud platform (public/private/hybrid)) in a totally automated manner using suitable MANO solution .

While this is something that will be highly sought after, it is something that is not possible to achieve based on the current out of the box capabilities available from MANO solutions & those provided by cloud platforms & infrastructures hosting them. In this post we will look at 1) Impact of changing infrastructure on Orchestration package 2) Approaching Orchestration package design to maximize re-usability and minimizing incremental efforts with changing infrastructure.

How is Infrastructure impacting the orchestration package:

From application implementation perspective Infrastructure plays a role in 2 main stages: a) xNF ( where x can be Virtual or Physical or Container) /Network Service Pre-requisites configuration b) xNF creation & configuration

When deployment Is required on different infrastructures some of the technical challenges which are faced that need to be incorporated as part of packages scripts/code include :

1. Each cloud platform(AWS, Azure, Red Hat Openstack/Openshift, GCP, Kubernetes etc) has different set of APIs using which its products can be accessed and configured eg: VPC setup, Networks configuration, Security groups, VM Creation etc.
2. Beside accessing and configuring each product individually if templates to provision infrastructure/VNFs and its dependencies are considered then again requirements are different eg: Heat template for Openstack, AWS Cloudformation, Azure Automation, Helm charts in Kubernetes based setup.
3. Even the xNF image formats that are understood by each platform tend to vary eg: qcow2, ova, vmdk, iso, docker etc.
4. Any pre-requisites and configurations that an application needs on another existing application will be technically independent of infrastructure w.r.t APIs used for configuration . Only the access URL for the application will vary depending on how the infrastructure exposes application access e.g. IP with port, kubernetes nodeport, Routes, etc.

However, the technical challenges associated with deployment of an application(xNF/NS) on cloud infrastructure is not limited to above factors only. Below scenarios need to be considered as well as they can impact the behaviour of existing orchestration packages for a network function/network service.

a) The underlying infrastructure/platform on which the cloud platform is hosted also plays a significant role as some of the features/functionalities of the platform/cloud solutions specially related with networking & policies(user/image config, etc) are either not supported or behave in a different way and require workarounds on either application end or infrastructure end for the feature/functionality enabling or configuration .

Also as nested cloud (Cloud platform installed on top of another cloud platform eg: Application VM installed on a KVM instance which is in turn running as a VM hosted on a server) can impact performance of the network functions validating the configurations with the product vendor becomes necessary to obtain the desired configuration setup .

b) In case of multi cloud architecture solution(e.g. the network service’s xNFs are deployed over more than 1 cloud or pre-requisite xNFs for the network service are hosted in different cloud from where the intended network service is being deployed) the connectivity between the different clouds & related configuration aspects have to be factored in as part of the application orchestration packages.

How to approach orchestration packages design to maximize reusability and minimizing efforts for deployment on new infrastructure:

Considering the importance of infrastructure(discussed above) as part of Network service deployment orchestration package the obvious question becomes how to approach the package design so that majority of it is reusable and doesn’t have to be completely rebuilt with changing infrastructure and in turn reducing development effort involved.

Below are some of the practices that can be followed to achieve the same:

1. While most network services/network functions solutions have been undergoing transformation journey over the years to get to virtual and containerized function, not all products are supported on all cloud platforms. So before beginning deployment on any cloud infrastructure it becomes critical to know whether application is supported on the platforms on which deployment is intended. Whether Network functions have only VNFs or only CNFs or both.

2. Breaking down the package into logical modules that handle different aspects of implementation cycle. Infrastructure specific steps can be kept in separate modules from the application steps. This way the modules which are not dependent on infrastructure can be reused as is by the MANO while infrastructure specific modules can be substituted depending on the desired infrastructure. Essentially stitching together of relevant modules on MANO either manually or automatically that realize the implementation cycle to form overall orchestration package.

3. Keeping a catalog of orchestration packages/modules on the MANO solution for deployment of network service on each infrastructure where it has already been deployed and tested. This way in case of need to deploy on any new cloud platform, only steps for implementation of the service on that new infrastructure using the relevant MANO will be needed to be configured in the package. Also, with help of modules discussed above, only small percentage of overall setup will require development effort.

4. Utilizing cloud native platforms as much as possible to realize the benefits of container images which enable deployment on any Kubernetes type environment with minimum amount of dev work in case of difference in underlying infrastructure or Kubernetes solution being used.

In summary Getting to single orchestration package for a MANO solution for deployment of network service on any infrastructure is not going to easily happen unless all infrastructures behave in a similar pattern. But following best practices, overall efforts can be optimized, and multiple reusable packages can be prepared that help achieve the end goal with minimum incremental effort for development.

Disclaimer: The post above expresses my sole viewpoint and not the opinion of any organization I work with presently or in the past.