Cloud-Native VNFs: A Demo of Voice over LTE
Cloud-Native VNFs: A Demo of Voice over LTE
Now that hardware has begun its mass migration to the cloud, it's time to see where the next move is. Here's a demo of a cloud-native Virtualized Network Function.
Join the DZone community and get the full member experience.Join For Free
Many existing network functions have only recently undergone the transition from being physical appliances to being delivered virtually, which was a revolution unto itself. That transition required mostly performance optimization to accommodate the additional I/O overhead of the hypervisor and some configuration changes to accommodate the fact that VMs can be more dynamic in nature.
Before this transition has even been fully realized, the NFV market is undergoing yet another and possibly even more disruptive revolution, of virtual network functions that are now transitioning to cloud-native VNFs. (This is not surprising, based on this excellent piece: The Disruption Cycle).
“The main requirements that differentiate a cloud native network function from the traditional network function is centered around self-management, and scale. A cloud-native VNF also needs to fit within a DevOps environment and expose APIs for controlling all of the aspects of the VNF by other software, and not just by an human operator. That includes DevOps processes to allow continuous upgrades of the service without any downtime.” Nati Shalom
In a world where the only constant is change, the real challenge isn't supporting a specific technology, but rather being so flexible that you are able to support any technology without compromising on the benefits that technology provides — i.e. offering such a thick abstraction layer that you cannot realize the benefits of the technology underneath. Or what is called “the least common denominator” effect. Read more on Achieving Hybrid Cloud Without Compromising On The Least Common Denominator.
We have decided to create a real-world demo of what it really means for today’s VNFs to be cloud-native, including:
- Policy Management.
- Security and Multi-Tenancy.
What you’ll see in the demo:
VoLTE — Voice over LTE is based on the IP Multimedia Subsystem (IMS) network, with specific profiles for control and media planes of voice service on LTE, which is enabled by an EPC (Evolved Packet Core), which unifies voice and data on an Internet Protocol (IP) transport.
This demo will show the full orchestration and management of Athonet IMS and EPC services using a TOSCA blueprint executed by the Cloudify NFVO & VNFM on top of a VMware vCloud environment, running on commodity Intel hardware.
In just a few simple steps, Cloudify creates and uploads a TOSCA blueprint that describes the VolTLE solution topology and deployment, as a catalog item, and then binds the specific parameters to a specific environment. This creates a dependency graph for this topology. Next, Cloudify executes the INSTALL workflow that instructs Cloudify to traverse the dependency graph and execute the relevant provisioning operations of the TOSCA nodes and their relationships, including:
- Viewing the topology status changes as the installation is progressing.
- Viewing the vCloud Director UI for the changes to the actual cloud environment.
In this case, two VMs are created, one for the vIMS and another for the vEPC. Afterward, you can see how Cloudify configures the different network connections for each VM. Next, once deployment is completed successfully (all nodes in the Cloudify UI are green), the VoLTE solution is deployed and VOIP calls can be placed using the newly deployed services.
At this point, when the service is available and in steady state, we can demo a Day 2 operations scenario of scaling. Scaling is performed in pairs of vIMS and vEPC nodes working together as one scaling unit. In Cloudify terminology this is called a scaling group.
How this is done:
- We execute a scale workflow and provide as parameters the node we would like to scale — in our case, it is the group node which contains the vIMS and vEPC.
- The scale workflow adds a new pair of vIMS and vEPC VMS, installs the VNF software and configure the new instance
- As soon as the scaling workflow completes its execution, the additional instances will be utilized to service new call sessions.
This is a common real-world scenario we encounter all of the time the demonstrates the true Day 0 through Day 2 operations VNF providers, alongside operators require these days. Being able to provide cloud-native VNFs is the benchmark — until the next disruption.
Published at DZone with permission of Sharone Zitzman , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.