instagram icon
MENU menu icon
back to blogBlog

Looking at the Adoption of NFV

April 18, 2017 6:33 AM

Category: Better Services Cloud | by Damian Nowak

NFV, Network Function Virtualization, is an exciting topic. NFV means virtualizing network services to decouple network functions from hardware devices. This allows network services to be hosted on virtual machines resulting in cost reductions and additional flexibility to deploy multiple instances that are customized to serve different lines of business. The significant benefits are prompting many companies in traditional technology intensive industries such as telecommunications to deploy NFV technologies. While we are seeing more NFV deployments around the world, it has not yet been deployed on a mass scale. Many Tier 1 operators are still hesitant to commit to the new technology, with smaller operators likely to make the change once the larger players have deployed and rigorously tested the technology. 

In late November I had the opportunity to attend the Red Hat Telco Partner Summit, there were as over 60 participants from more than 25 companies worldwide. It was exciting to talk to different attendees who shared their NFV experiences and talked about the development of the technology. During the summit, we learned that, according to Red Hat, NFV adoption is currently at the following stage: 

  • 50% of the Communications Service Providers (CSPs) already execute a NFV strategy 
  • 29% are in the process of defining their strategy 
  • 16% have not yet even decided on a strategy
  • 5% are not currently considering the deployment of NFV platforms 

Figure 1 NFV world-wide adoption according to Red Hat

During the conference the most talked about topic was containers. Containerization is a lightweight mechanism for isolating running processes so that they are limited to interacting with only their designated resources. The topic was hotly debated as it significantly impacts the technology choice and Total Cost of Ownership. The debate centered on whether containers are ripe for Virtual Network Functions (VNF) consumption or if they are still relegated to web applications - are containers a good idea for everything? The reality is that containers, although a great deployment technology for cloud-native applications, are not necessarily the best deployment technology for VNFs operating in certain areas of the Telco ecosystem. Although there are some existing commercial containerized solutions available, long term VNFs packaged in containers are seen to be the natural evolution. The co-existence of containers and virtual machines is something the industry will see on the market in near future.

At the Summit we also heard from Red Hat who confirmed their commitment to supporting OpenStack / Linux technology, and the release of new product versions in their roadmap. The company also introduced a VNF certification program for VNFs running on Red Hat Linux/Red Hat OpenStack Platform (OSP) and will open up a lab in Boston, USA to support Proof of Concept (PoC) executions. The addition of a lab is not new with other companies such as Intel also announcing investments in new labs to support new eco-systems and opportunities. Lab investments are important because it means that companies like Red Hat and its partners are able to test new scenarios and product combinations to create a customer solution and successful deployment. Red Hat also announced the general availability of Red Hat OpenStack Platform 10, based on OpenStack Newton release, and Red Hat Enterprise Linux 7.3. The key feature of the OpenStack Platform, ‘OVS-DPDK’ is a technology variant which uses Intel packet processing acceleration technology (called DPDK) - a significant step for the industry.

Redknee presented its policy and charging NFV PoC at the Summit, it focused on proving interoperability in a NFV environment. The PoC was jointly performed together with Red Hat and Dell at a Latin American customer with operations in multiple countries, with the desire to outperform the competition with modern technologies. The scope and objective of the PoC was to prove the interoperability advertised by NFV platforms by deploying the Evolved Packet Core (EPC) from three different vendors in three different NFV platforms, Redknee’s Policy and Convergent Charging solution (PCRF and OCS) was then placed on top of the three NFV platforms. Redknee delivered Redknee Unified Charging vOCS, Redknee Unified vManager (specific VNF-Manager for Redknee own VNFs) and Redknee Unified Commander EMS (Element Manager). In the Policy and Charging PoC Redknee Unified Charging vOCS comprised of several VNFCs, connected via multiple networks. It was automatically deployed via Redknee Unified vManager on three different NFV-Infrastructures from three different vendors, all based on OpenStack technology, KVM hypervisor, and end-to-end functionally integrated with the virtualized Evolved Packet Core (vEPC) from three different vendors. The PoC was successful in proving interoperability as well as portability. Redknee shared its lessons learnt which are in brief: 

a) signaling-only VNFs are probably easier to place in NFV platforms than user-plane applications; 
b) an agreement is needed between the NFV platform provider and VNF provider on responsibilities and scope of work, which helps to optimize solution delivery phase and problem resolution times when the software goes into live operation;
c) It is important not to use any proprietary solutions, as they affect the solutions portability and interoperability. 
d) technically the SR-IOV technology brings certain challenges to the infrastructure, which increase the complexity to deploy VNFs. or OVS-DPDK are interesting alternatives to SR-IOV based networking solutions.

Attendees agreed that vendor-specific proprietary solutions shall not be considered for NFV deployments because these solutions are effectively limiting the openness promised by the NFV vision. In such a situation there is a need for vendor collaboration platform, which would allow each of them to offer solutions operating on standardized infrastructure and ensure the portability of the application with different NFV platforms. At this moment, the open-source software initiatives (like Linux Foundation, OpenStack Foundation) provides this collaboration platform, where multiple vendors promote certain solutions to the community and if the specific solution will be accepted as a part of the bigger software piece or not. This voting model helps to make sure that only those software solutions which match the specific open-source software vision will be promoted, and the bigger vendors are able to include solutions that require specific commercial solutions that they are offering.

In addition to that feedback on other NFV strategy front, the attendees found a match between the SR-IOV technology deployment issues mentioned by Redknee, and a new “OVS-DPDK” feature freshly introduced by Red Hat in OpenStack Platform 10. It was stated, that OVS-DPDK provides almost same performance as the SR-IOV based solution with regards to networking, and allows to unify the networking architecture among all the VNFs deployed in a certain platform. Such a statement underlines the fact, that new deliveries of Red Hat and the community are really solving real customer challenges seen within certain deployments, and they bring value by simplification of existing deployment streams.

Overall it is an exciting time for NFV technologies and with more case studies and use cases becoming available, NFV is likely to be adopted by more communications service providers in the coming years. For more information about Redknee’s case study, please click here or contact a member of the Redknee team.