Network Functions Virtualization (NFV) is a core structural change in the way telecommunication infrastructure gets deployed. This in turn will bring significant changes in the way that applications are delivered to service providers. NFV will bring cost efficiencies, time-to-market improvements and innovation to the telecommunication industry infrastructure and applications. This disaggregation will be enabled by changing the industry’s traditional approach to delivery of applications from a closed, proprietary, and tightly integrated stack model into an open, layered model, where applications are hosted on a shared, common infrastructure base.

NFV architecture benefits

Flexibility: Service providers looking to quickly deploy new services require a much more flexible and adaptable network -- one that can be easily and quickly installed and provisioned.

Cost: Cost is a top consideration for any operator or service provider these days, even more so now that they see Google and others deploying massive datacenters using off-the-shelf merchant silicon (commoditized hardware) as a way to drive down cost. Cost is also reflected in opex -- how easy it is to deploy and maintain services in the network.

Scalability: To adapt quickly to users' changing needs and provide new services, operators must be able to scale their network architecture across multiple servers, rather than being limited by what a single box can do.

Security: Security has been, and continues to be, a major challenge in networking. Operators want to be able to provision and manage the network while allowing their customers to run their own virtual space and firewall securely within the network.

ETSI NFV Architecture

Issues and challenges

The telecom vendors are currently developing proof-of-concept for moving existing network functions to virtualized infrastructure and there are quite a few challenges during the implementation and deployment phase. Many aspects come into play when the different network functions are deployed in virtualized infrastructure.

1. Meeting Carrier-Grade availability requirements

Present day Carrier network infrastructure provides reliable service and meets the availability requirement of 5’9s. Existing high capacity servers are designed for IT services and enterprise class of application with availability of the order of 2’9s to 3’9s. NFV infrastructure based on standard off-the-shelf server will not be able to meet the carrier-grade availability expectations.

NFV architecture allows very agile life cycle management to allow just in time creation of Virtual Machines to host the Virtual Network Functions; in the event of failure. The availability approach relies on spawning new instances. This is quite different than the traditional high availability architecture used in telecom systems.

In the traditional high availability architecture, while platform redundancy is used to avoid single point of failure, all the hardware and software components are hardened to prevent failures. Application specific state replication is implemented to ensure continuity of operations. This high availability support will have to be ported to the NFV environment.

2. Limitations of existing network applications

Most of the legacy systems are designed with an assumption that the network application has exclusive access to the hardware resources (CPU, NIC, disk). Resources such as BSP and hardware accelerators are directly controlled by the application.

Examples of possible issues:

• Internal task interaction of real time applications assumes direct control of hardware resources. Sharing of the hardware platform with other applications would cause some performance degradation. The virtualization hypervisor provides some level of isolation between different virtual machines however it is not the same as running an application directly on the hardware.
• Existing network applications would mostly be scalable; however the architecture may not support dynamic scaling in response to traffic changes. The load distribution algorithm would typically be static and assume all the installed physical servers are available for use resulting in under-utilization of each of the servers. Some amount of re-engineering would be needed to make use of ‘elastic’ nature of the virtual infrastructure.

3. Management of virtualized infrastructure and network applications

Management system of traditional networks typically consists of multiple Element Managers report to a Network Management system. Each Network Element is associated with at least one Element Manager. Existing Element Managers assume tight coupling between the Network Element and the platform itself.

Issues in existing management systems:

• The operational state of the underlying platform being considered the same as that of the Network Function
• The topological view showing different Network Elements and Network Functions in their physical form in the form of hierarchy of hardware modules, rather than showing the Network Functions as being overlaid over the physical infrastructure
• The Element Manager Fault Management Function mapping the platform fault directly to the Network Function

The management model will have to be extended to separate the NFV platform and network applications.

4. Integration and testing challenges

Traditionally different network applications were deployed as distinctly visible entities with well-defined interface reference points. Integrations tools such as protocol analyzers and data probes are based on such controllable and observation reference points. Most of the integration tools assume easy access to these interface reference points; however in the NFV model one or more Network Functions related to an end-to-end service may be assigned to same high end hardware resource and the access to the reference point would be restricted. Some of the virtual switches address this issue by forwarding all the traffic on the virtual NIC to the physical NIC (using Virtual Ethernet Port Aggregator approach) to facilitate the tapping of these interface reference point.

System performance testing under load conditions in the deployment configuration will pose some challenges. In the lab, it will not be possible to create an environment equivalent that of the actual deployment as other VNFs sharing the same infrastructure is either unknown or cannot be instantiated.

Summary

In the last few years Network Functions Virtulatiozation has captured the attention of operators worldwide. NFV has been making waves as it represents the evolution of networking, promising to virtualise physical network infrastructure and create an environment that’s more adaptable than the legacy systems currently in use. Despite all challenges and issues, NFV is here to stay.