Network function virtualization

Network functions virtualization (NFV) is a network architecture concept that proposes using IT virtualization related technologies to virtualize entire classes of network node functions into building blocks that may be connected, or chained, to create communication services.

NFV relies upon, but differs from, traditional server virtualization techniques such as those used in enterprise IT. A virtualized network function, or VNF, may consist of one or more virtual machines running different software and processes, on top of industry standard high volume servers, switches and storage, or even cloud computing infrastructure, instead of having custom hardware appliances for each network function.

For example, a virtualized session border controller function could be deployed to protect a network without the typical cost and complexity of obtaining and installing physical units. Other examples of NFV include virtualized load balancers, firewalls, intrusion detection devices and WAN accelerators.

Background

Product development within the telecommunications industry has traditionally followed rigorous standards for stability, protocol adherence and quality. While this model worked well in the past, it inevitably led to long product cycles, a slow pace of development and reliance on proprietary or specialist hardware. The rise of significant competition in communications services, from fast-moving organizations operating at large scale on the public Internet (such as Google Talk), have spurred service providers to look for ways to disrupt the status quo.

History

In October 2012, an industry specifications group, "Network Functions Virtualisation", published a white paper at a conference in Darmstadt, Germany on software-defined networking and OpenFlow. The group, part of the European Telecommunications Standards Institute (ETSI), was made up of representatives from the telecommunications industry from both Europe and beyond.

Since the publication of the white paper, the group has produced several more in-depth materials, including a standard terminology definition and use cases for NFV that act as references for vendors and operators considering implementing NFV.

NFV Framework

The NFV framework consists of three main components:

1. Virtualized network functions (VNF') are software implementations of network functions that can be deployed on a Network Function Virtualization Infrastructure (NFVI).
2. Network function virtualization infrastructure (NFVI) is the totality of all hardware and software components which build up the environment in which VNFs are deployed. The NFV-Infrastructure can span across several locations. The network providing connectivity between these locations is regarded to be part of the NFV-Infrastructure.
3. Network functions virtualization management and orchestration architectural framework (NFV-MANO Architectural Framework) is the collection of all functional blocks, data repositories used by these functional blocks, and reference points and interfaces through which these functional blocks exchange information for the purpose of managing and orchestrating NFVI and VNFs.

The building block for both the NFVI and the NFV-MANO is the NFV platform. In the NFVI role, it consists of both virtual and physical processing and storage resources, and virtualization software. In its NFV-MANO role it consists of VNF and NFVI managers and virtualization software operating on a hardware controller. The NFV platform implements carrier-grade features used to manage and monitor the platform components, recover from failures and provide effective security - all required for the public carrier network.

Practical aspects

A service provider who follows the NFV design will implement one or more virtualized network functions, or VNFs. A VNF by itself does not automatically provide a usable product or service to the provider's customers. To build more complex services, the notion of service chaining is used, where multiple VNFs are used in sequence to deliver a service.

Another aspect of implementing NFV is the orchestration process. In order to build highly reliable and scalable services, NFV requires that the network be able to instantiate VNF instances, monitor them, repair them, and (most importantly for a service provider business) bill for the services rendered. These attributes, referred to as Carrier-Grade features, are allocated to an orchestration layer in order to achieve high availability and security, and low operations and maintenance costs. Importantly, the orchestration layer must be able to manage VNFs irrespective of what the underlying technology within the VNF is. For example, an orchestration layer must be able to manage an SBC VNF from vendor X running on VMware vSphere just as well as an IMS VNF from vendor Y running on KVM (Kernel-based Virtual Machine).

Distributed NFV

The initial perception of NFV was that virtualized capability should be implemented in data centers. This approach works in many – but not all – cases. NFV presumes and emphasizes the widest possible flexibility as to the physical location of the virtualized functions.

Ideally, therefore, virtualized functions should be located where they will be the most effective and least expensive. That means a service provider should be free to locate NFV in all possible locations, from the data center to the network node to the customer premises. This approach, known as Distributed NFV, has been emphasized from the beginning as NFV was being developed and standardized, and is prominent in the recently released NFV ISG documents.

For some cases there are clear advantages for a service provider to locate this virtualized functionality at the customer premises. These advantages range from economics to performance to the feasibility of the functions being virtualized.

The first ETSI NFV ISG-approved public multi-vendor proof of concept (PoC) of D-NFV was conducted by Cyan, Inc., RAD, Fortinet and Certes Networks in Chicago in June, 2014, ans sponsored by CenturyLink. It was based on RAD’s dedicated customer-edge D-NFV equipment running Fortinet’s Next Generation Firewall (NGFW) and Certes Networks’ virtual encryption/decryption engine as Virtual Network Functions (VNFs) with Cyan’s Blue Planet system orchestrating the entire ecosystem. RAD's D-NFV solution, a Layer 2/Layer 3 network termination unit (NTU) equipped with a D-NFV X86 server module that functions as a virtualization engine at the customer edge, became commercially available by the end of that month. During 2014 RAD also had organized a D-NFV Alliance, an ecosystem of vendors and international systems integrators specializing in new NFV applications.

NFV modularity benefits

When designing and developing the software that provides the VNFs, vendors may structure that software into software components (implementation view of a software architecture) and package those components into one or more images (deployment view of a software architecture). These vendor-defined software components are called VNF Components (VNFCs). VNFs are implemented with one or more VNFCs and it is assumed, without loss of generality, that VNFCs map 1:1 to VM Images. Scale Up and scale Out enablement: By being able to allocate flexible (virtual) CPU to each of the VNFC instance, the network management layer can scale UP & down VNFC resource to follow up with the throughput/performance and scalability expectations over a single system or a single platform. Similarly, the network management layer can scale OUT & down the VNFC instances over multiple platforms and therefore reach out to the performance and architecture specifications whilst not compromising the other VNFC function stabilities.

Early adopters of such architecture blueprints have already implemented the NFV modularity principles.

Relationship to SDN

SDN, or software-defined networking, is a concept related to NFV, but they refer to different domains.

In essence, Software-defined networking (SDN) is an approach to building data networking equipment and software that separates and abstracts elements of these systems. It does this by decoupling the control plane and data plane from each other, such that the control plane resides centrally and the forwarding components remain distributed. The control plane interacts both northbound and southbound. In the northbound direction the control plane provides a common abstracted view of the network to higher-level applications and programs using APIs. In the southbound direction the control plane programs the forwarding behavior, using device level APIs, of the physical network equipment distributed around the network.

Thus, NFV is not dependent on SDN or SDN concepts. It is entirely possible to implement a virtualized network function (VNF) as a standalone entity using existing networking and orchestration paradigms. However, there are inherent benefits in leveraging SDN concepts to implement and manage an NFV infrastructure, particularly when looking at the management and orchestration of VNFs, and that's why multivendor platforms are being defined that incorporate SDN and NFV in concerted ecosystems.

An NFV infrastructure is more than simply adapting existing network applications to run on x86 technology. It needs a central orchestration and management system that takes operator requests associated with a VNF, translates them into the appropriate processing, storage and network configuration needed to bring the VNF into operation. Once in operation, the VNF potentially needs to be monitored for capacity and utilization and adapted if necessary.

All these functions can be accomplished using SDN concepts and NFV could be considered one of the primary SDN use cases in service provider environments. It is also apparent that many SDN use-cases could incorporate concepts introduced in the NFV initiative. Examples include where the centralized controller is controlling a distributed forwarding function that could in fact be also visualized on existing processing or routing equipment.

Industry impact

NFV has proven a popular standard even in its infancy. Its immediate applications are numerous, such as virtualization of Mobile base stations, Platform as a Service (PaaS), Content Delivery Networks (CDN), fixed access and home environments. The potential benefits of NFV is anticipated to be significant. Virtualization of network functions deployed on general purpose standardized hardware is expected to reduce capital and operational expenditures, and service and product introduction times. Many major network equipment vendors have announced support for NFV. This has coincided with NFV announcements from major software suppliers who provide the NFV platforms used by equipment suppliers to build their NFV products.

However, to realize the anticipated benefits of virtualization, network equipment vendors are improving IT virtualization technology to incorporate carrier-grade attributes which are required to achieve high availability, scalability and performance, and effective network management capabilities. To minimize the total cost of ownership (TCO), carrier-grade features must be implemented as efficiently as possible. This requires that NFV solutions make efficient use of redundant resources to achieve five-nines availability (99.999%), and of computing resource without compromising performance predictability.

The NFV platform is the foundation for achieving efficient carrier-grade NFV solutions. It is a software platform running on standard multi-core hardware and built using open source software that incorporates carrier-grade features. The NFV platform software is responsible for dynamically re-assigning VNFs due to failures and changes in traffic load, and therefore plays an important role in achieving high availability. There are numerous initiatives underway to specify, align and promote NFV carrier-grade capabilities such as ETSI NFV Proof of Concept, ATIS Open Platform for NFV Project, Carrier Network Virtualization Awards and various supplier ecosystems.

MANO - Management and Orchestration

ETSI has already indicated that an important part of controlling the NFV environment should be done through automation and orchestration. There is a separate stream MANO within NFV outlining how flexibility should be controlled. Mano at network-functions-virtualization.com

See also

• OASIS TOSCA
• Hardware virtualization
• Software-defined networking
• Network virtualization
• Network management
• Shortest Path Bridging

External links

• NFV basics