NFV Orchestration about more than infrastructure

One key NFV goal for 2016 is to achieve clarity on how NFV elements will be managed and orchestrated within the network to create multi-use-case services.

When it comes to managing the infrastructure and the deployment, integration and orchestration of VNFs, the existing management and orchestration (MANO) models are as yet incomplete, and/or overlapping.

This matters because unless operators can assemble network services from multiple VNFs running over NFV infrastructure without a heavy integration effort, then NFV’s key proposition – to deploy more money-raising network services quickly and easily – gets diluted.

So the issue of NFV MANO is directly related to service deployment, which is directly related to making money. Recently, there’s growing evidence that the industry has recognised the issue, and is addressing it.

For example, there was an announcement of one new approach at MWC, known as OpenSource MANO, launched by Intel and with Telefonica as one of its lead operator sponsors. That approach highlighted additional areas it was addressing, on top of ETSI MANO’s existing framework. Its launch white paper said these include:

“The higher-level issue of end-to-end service orchestration and also the current state of play in the open-source community with respect to cultivating possible management and end to end service orchestration solutions… the currently missing piece from the picture is the component required to deploy and manage the coherent end-to-end service. This allows the service providers to connect the world of software (VNFs) onto their open NFVI infrastructure. Open source creates the opportunity of enabling true end-to-end open NFV deployments, while also ensuring that true telco-grade SLAs are achieved.”

Industry analyst Tom Nolle of CIMI Corp wrote that the OS MANO whitepaper “demonstrates that operators are recognising the key things that NFV needs and the ETSI ISG hasn’t provided.  These things include full-scope service orchestration, inclusion of legacy network components, and multiple VIMs per implementation.”

Additionally, there was the announcement that Ericsson has been appointed as a provider to Phase II of Telefonica’s Unica project, with the operator remaining tight-lipped on the fortunes and progress of HPE’s involvement, following the IT giant’s appointment to lead Phase I. Some judges have proposed that one of the issues with the HPE trial was the inability to provide truly open multi-vendor management. (It must be stated that nobody outside of Telefonica and HPE actually knows if this was in fact an issue, and those two parties are not for telling.)

Service Orchestration meets VNFs and NFV Infrastructure

One company that is working away at the issues involved in putting together a service orchestration layer in particular is Amdocs. Notably, Amdocs is the only non-NEP  that AnalysysMason thinks is taking a leading position in NFV network orchestration. Amdocs, sitting in the industry as an OSS and BSS software provider, is naturally keen to harness a role as a service orchestrator – ie, going beyond managing infrastructure into making sure that operators can deploy and manage networks services that take advantage of  NFV infrastructure.

Amdocs’ OSS marketing lead Justin Paul, says that one of the targets for NFV deployment is to be able to radically cut down deployment time for new services – and this is where services level orchestration comes in. It is a view that considers network service deployment and configuration as something for the orchestrator to take control of, as part of a defined workflow.

Retreading the pitch Amdocs gave last autumn when it launched its Service Design and Create (SDC) model, Paul highlighted four key aspects that the SDC model packages together as a service deployment workflow.

  1. The onboarding by vendors of VNFs – described by Paul as “really quite critical” for the success of NFV programmes as it makes features and functionalities available within the service for anyone to build a service.
  2. The definition of policies and workflow around a service – for example the ability to instantiate a DDOS server when firewalls become overwhelmed by a DDOS attack (instead of just spinning up new firewalls), and then to reinstantiate the firewalls once the attack is contained.
  3. The automation of the test process for a new service – not so that services can be launched in an entirely automated way but so that the workload of lab test engineers can be reduced. Currently the test labs are, through no fault of their own, a bottleneck in getting new services onto the network, Paul said.
  4. The creation of a single, active centralised master catalogue – with apps being published to the common inventory and made available for use to OSS and BSS and to NFV orchestrators. Paul: “Once it’s available in the catalogue it’s packaged into the orchestrator to deliver the physical fulfilment of the package.”

Paul describes these four elements – onboarding, policy definition, testing automation and publishing to the catalogue – as a service development flow. The end goal is to transform the engineering operations function in the network operator from its current tendency to be a bottleneck to being the quickest element within a new service introduction.

NFV deployments must give operators the means to assemble network services much faster from pre-tested, centrally-managed features within the network, but also taking into account any legacy elements the service must touch

Beyond the ETSI MANO model

Amdcos NFV orchestration POC with Vodafone

Amdocs has a five partner NFV demo with Vodafone in a live deployment in its datacentre in Newbury, providing VPN instantiation from the datacentre. Amdocs is the lead integrator and provider of billing, with Red Hat providing its OpenStack tech, Aria Networks its AI-based predictive analytics for SDN and orchestration, with Juniper and Fortinet providing VNFs and Adva Optical Network providing vCPE.

Paul echoed some of Nolle’s gap analysis in saying that currently there is a need to go further than the current definitions of ETSI MANO, which were formed as an early outline of how NFV elements (the Virtualised infrastructure itself, and the VNFs) could be managed and orchestrated together. He also said there is still overlap between the ETSI MANO definitions – in that, for example, Amdocs’ Orchestrator could also be regarded, within the model, as an over-engineered NFV infrastructure manager.

For Paul, like Nolle, there is also a requirement to recognise the hybrid nature of the service landscape – with virtualised and non-virtual functions working in combination. Added to that is the ability to add in certain capabilities such as monitoring and self-healing, with an active inventory taking in analytics and enabling decision to be made in the network based on that. In the Vodafone demo Aria Networks is providing that analytics function to Amdocs’ service orchestrator.

So when you read or hear about service orchestration, think of it as “monetising NFV”.  For Amdocs, that means NFV deployments must give operators the means to assemble network services much faster from pre-tested, centrally-managed features within the network, but also taking into account any legacy elements the service must touch.