If you’ve been building to the ETSI NFVI model, you probably think you’re ready to deliver NFVI services. But you’re not. You’re ready to build the services, but not ready to deliver them to customers.
The ETSI model is working right now, and that’s got you confident. It’s wonderful for eliminating the need to ship, unpack, cable and configure custom networking hardware to hundreds of locations. It allows you to quickly configure service chains to provide new services. There are third parties validating VNFs against multiple vendors’ NFV infrastructures. And OpenStack is finally working, giving you the deep technical access you need to deliver telecommunications over virtualization.
But our telecom customers are telling us that the carefully crafted ETSI model isn’t enough.
The wild differences between VNFs (Recompiled appliance code! Hardware disaggregated across multiple VMs! Brand new code!) makes understanding a service chain practically impossible. Every element manager looks at only its tiny picture, and no one has a comprehensive service view.
The OSS and BSS systems aren’t even close to being ready to deal with the core capability of VNF systems, the ability to define and redefine services to meet customer needs, even to cope with adjusting infrastructure capacity delivery.
And the compute and networking teams now need total understanding of what the other team is doing, because VNFs rely on computing.
These are the obstacles we’re helping telecom customers overcome.
What Successful NFV Service Assurance Means
What our telecom customers are finding is that they need to extend the ETSI model with a service assurance stack — log management, performance management and fault management — tied into the NFVO, VNF Managers, and VIM. They call it the vNMS.
The vNMS is tasked with maintaining awareness of the successful function of each service chain, end to end across all the different vendor VNFs — a consistent understanding even when the VNFs change or the service chain is redefined.
With that understanding, they can operate the NFV in the fast recovery mode of a cloud service, quickly replacing or working around cloud components and maintaining service-level agreements (SLAs).
The view has to extend from the service chain through the VNFs, their secure connections, and into the VIM where they run. This gives the networking and cloud teams the unified view of the customer’s service and lets them cooperate effectively.
Driving every aspect of what the vNMS does is tight coupling with the MANO, the VNF Manager and the VIM. You never want to provision device or VNF monitoring or deal with alerts from a decommissioned service.
And it means that OSS and BSS systems can consume these dynamically defined NFV services easily. You’ll know whether your customers are being successful, bring the right people in to fix problems quickly, and be aware of whether you’re actually meeting SLAs and be able to take action ahead of time to avoid contract misses.
Turning the vNMS Dream Into Reality
Zenoss is working with our telecom customers to deliver the vNMS today.
Our partners are developing ZenPacks to let them handle the differences in VNF architectures and protocols. They love the way that they can communicate to a VNF native agent or to an EMS using SNMP, REST APIs, SFTP even corba. Our ZenPack development library makes it straightforward to support fault performance, and logs regardless of the VNF and EMS protocols.
They’re connecting into maturing orchestration systems using the simple, fast Zenoss JSON API to automate device and VNF provisioning and deprovisioning. And, they’re importing and exporting inventory information from the orchestrator to register VNFs as they are activated.
They’re letting IT run the NFVI and the network team run the VNFs from the same system while giving each complete visibility over what the other team sees. As a vNMS, Zenoss delivers automatic mapping of the dynamic relationships between VNFs and the NFVI and integrates with the VIM with its provisioning and deprovisioning tasks, too.
And they’re able to decide if the Zenoss vNMS deployment should be just another VNF or deliberately separated using the robust and scalable Zenoss deployment system.
Our lead NFV sales engineer calls Zenoss and NFV “a match made in heaven!”
David Stevenson, SOPRIS Technologies and Laszlo Bojtos, Zenoss contributed to this article.
