Skip to content 
Network Function Virtualization (NFV) promises agility and OPEX reduction through dynamic scale-up and scale-out. Many Tier-1 operators are conducting POCs using multiple VNFs and different architectures. So far, these POCs focused on automating service provisioning. However, the next challenge is to ensure Service Assurance in the NFV deployments.
With the physical infrastructure, industry has well-defined Service Level Agreements (SLAs) and robust mechanisms to implement them. In the NFV world, the expectations are even higher.
Just like you would expect lot more from an electric car than a gasoline powered car, you would expect lot more information and assurance in the virtual world.
A typical SLA consists of multiple criteria including service definition as well as metrics for performance, availability, scalability, mean time to troubleshoot, disaster recovery etc.
Challenges for Service Assurance in NFV:
In the current form, Service Assurance in NFV is extremely manual and OPEX intensive.
1. Scale: Compared to physical infrastructure, Service Assurance tools in NFV must monitor exceedingly high number of end points. For instance, one physical Cisco ASR 9922 router supports 8000 customers. When you virtualize that router, you now must manage 8000 CSR 1000v virtual routers, one for each customer.
2. Vendor Compatibility: The individual VNFs are simpler, but they are often sourced from multiple vendors’ at large-scale. And, the compatibility among various layers of NFV (VIM, NFVI, OSS/BSS) is often overlooked. It is also extremely challenging to keep the documentation correct in a virtual world.
3. PNF Integration: Some of the VNFs can’t match performance and reliability with physical device characteristics. Further, many network elements are still physical. So, the service assurance tools need to work with some information in physical infrastructure and some in the virtual infrastructure.
4. Lack of Instrumentation: In the physical infrastructure, vendors instrumented probes within the hardware to monitor service availability. However, such mechanisms are yet to be defined in NFV.
5. Lack of Unified Service View: Currently, we don’t have a single pane of glass to understand the entire service status including service definition, provisioned operations, current configuration and match up with the SLAs.
6. Field Extensibility: Considering the breadth of use-cases and vendors, it is not practical for an out of the box solution that works for all domains in NFV. The System Integrators (SI) who truly understand the customer use-case need a flexible platform that can be easily extended using open standards or data models.
These challenges can’t be resolved by individual VNF vendors. The SDN and SD-WAN controllers provide better visibility for the L2-L3 fabric, but what about the rest of the network services? Once again, we will end-up with islands of visibility.
In the next blog post, we will discuss why a Network Service Orchestrator is best equipped to support service assurance for NFV.
– Kiran Sirupa, December 14th, 2016
