Network function virtualization

Network functions virtualization (also network function virtualization or NFV)[1] is a network architecture concept that uses the technologies of IT virtualization to virtualize entire classes of network node functions into building blocks that may connect, or chain together, 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 or containers running different software and processes, on top of standard high-volume servers, switches and storage devices, or even cloud computing infrastructure, instead of having custom hardware appliances for each network function.

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

Background

Product development within the telecommunication industry has traditionally followed rigorous standards for stability, protocol adherence and quality, reflected by the use of the term carrier grade to designate equipment demonstrating this reliability.[3] 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 specific hardware, e.g., bespoke application-specific integrated circuits (ASICs). The rise of significant competition in communication services from fast-moving organizations operating at large scale on the public Internet (such as Google Talk, Skype, Netflix) has spurred service providers to look for ways to disrupt the status quo.

History

In October 2012, a group of telecom operators published a white paper[4] at a conference in Darmstadt, Germany, on software-defined networking (SDN) and OpenFlow. The Call for Action concluding the White Paper led to the creation of the Network Functions Virtualization (NFV) Industry Specification Group (ISG) [5] within the European Telecommunications Standards Institute (ETSI). The ISG was made up of representatives from the telecommunication industry from Europe and beyond.[6][7] Since the publication of the white paper, the group has produced over 100 publications.[8] In 2016, one high performance open source version of NFV is released. openNetVM is a high performance NFV platform based on DPDK and Docker containers.[9]

Framework

The NFV framework consists of three main components:[10]

1. Virtualized network functions (VNFs) are software implementations of network functions that can be deployed on a network functions virtualization infrastructure (NFVI).[11]
2. Network functions virtualization infrastructure (NFVI) is the totality of all hardware and software components that build the environment where NFVs are deployed. The NFV infrastructure can span several locations. The network providing connectivity between these locations is considered as 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 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 that follows the NFV design implements 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. To build highly reliable and scalable services, NFV requires that the network be able to instantiate VNF instances, monitor them, repair them, and (most important for a service provider business) bill for the services rendered. These attributes, referred to as carrier-grade[12] features, are allocated to an orchestration layer in order to provide high availability and security, and low operation and maintenance costs. Importantly, the orchestration layer must be able to manage VNFs irrespective of the underlying technology within the VNF. 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.

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 are 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.[13]

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.[14]

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, and was 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.[15] 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.[16] During 2014 RAD also had organized a D-NFV Alliance, an ecosystem of vendors and international systems integrators specializing in new NFV applications.[17]

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 VNFC instances map 1:1 to VM Images.

VNFCs should in general be able to scale up and/or scale out. By being able to allocate flexible (virtual) CPUs to each of the VNFC instances, the network management layer can scale up (i.e., scale vertically) the VNFC to provide the throughput/performance and scalability expectations over a single system or a single platform. Similarly, the network management layer can scale out (i.e., scale horizontally) a VNFC by activating multiple instances of such VNFC 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.[18]

Relationship to SDN

SDN, or software-defined networking, is a concept related to NFV, but they refer to different domains.[19] Network functions virtualization (NFV) and Deep Packet Inspection (DPI) could efficiently complement the SDN functions.[20]

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 of the data plane, 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.[21]

An NFV infrastructure 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 must be monitored for capacity and utilization, and adapted if necessary.[22]

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 virtualized 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.[23] 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.[24][25] Many major network equipment vendors have announced support for NFV.[26] This has coincided with NFV announcements from major software suppliers who provide the NFV platforms used by equipment suppliers to build their NFV products.[27][28]

However, to realize the anticipated benefits of virtualization, network equipment vendors are improving IT virtualization technology to incorporate carrier-grade attributes required to achieve high availability, scalability, performance, and effective network management capabilities.[29] 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%),[30] and of computing resource without compromising performance predictability.

The NFV platform is the foundation for achieving efficient carrier-grade NFV solutions.[31] 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 reassigning 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,[32] ATIS[33] Open Platform for NFV Project,[34] Carrier Network Virtualization Awards[35] and various supplier ecosystems.[36]

The vSwitch, a key component of NFV platforms, is responsible for providing connectivity both VM-to-VM (between VMs) and between VMs and the outside network. Its performance determines both the bandwidth of the VNFs and the cost-efficiency of NFV solutions. The standard Open vSwitch's (OVS) performance has shortcomings that must be resolved to meet the needs of NFVI solutions.[37] Significant performance improvements are being reported by NFV suppliers for both OVS and Accelerated Open vSwitch (AVS) versions.[38][39]

Virtualization is also changing the way availability is specified, measured and achieved in NFV solutions. As VNFs replace traditional function-dedicated equipment, there is a shift from equipment-based availability to a service-based, end-to-end, layered approach.[40][41] Virtualizing network functions breaks the explicit coupling with specific equipment, therefore availability is defined by the availability of VNF services. Because NFV technology can virtualize a wide range of network function types, each with their own service availability expectations, NFV platforms should support a wide range of fault tolerance options. This flexibility enables CSPs to optimize their NFV solutions to meet any VNF availability requirement.

Management and orchestration (MANO)

ETSI has already indicated that an important part of controlling the NFV environment be done through automation and orchestration. There is a separate stream MANO within NFV outlining how flexibility should be controlled.[42]

ETSI delivers a full set of standards enabling an open ecosystem where Virtualized Network Functions (VNFs) can be interoperable with independently developed management and orchestration systems, and where the components of a management and orchestration system are themselves interoperable. This includes a set of Restful API specifications[43] as well as the specifications of a packaging format for delivering VNFs to service providers and of the deployment templates to be packaged with the software images to enable managing the lifecycle of VNFs. Deployment templates can be based on TOSCA or YANG.[44][45]

An OpenAPI (a.k.a. Swagger) representation of the API specifications is available on the ETSI forge server, along with TOSCA and YANG definition files to be used when creating deployment templates.

The full set of published specifications is summarized in the table below.

Specification	Title
ETSI GS NFV-SOL 001	NFV descriptors based on TOSCA specification
ETSI GS NFV-SOL 002	RESTful protocols specification for the Ve-Vnfm Reference Point
ETSI GS NFV-SOL 003	RESTful protocols specification for the Or-Vnfm Reference Point
ETSI GS NFV-SOL 004	VNF Package and PNFD Archive specification
ETSI GS NFV-SOL 005	RESTful protocols specification for the Os-Ma-nfvo Reference Point
ETSI GS NFV-SOL 006	NFV descriptors based on YANG Specification
ETSI GS NFV-SOL 007	Network Service Descriptor file structure specification
ETSI GS NFV-SOL 009	RESTful protocols specification for the management of NFV-MANO
ETSI GS NFV-SOL 011	RESTful protocols specification for the Or-Or Reference Point
ETSI GS NFV-SOL 013	Specification of common aspects for RESTful NFV MANO APIs

An overview of the different versions of the OpenAPI representations of NFV-MANO APIs is available on the ETSI NFV wiki.

Performance study

Recent performance study on NFV focused on the throughput, latency and jitter of virtualized network functions (VNFs), as well as NFV scalability in terms of the number of VNFs a single physical server can support.[46] Open source NFV platforms are available, one representative is openNetVM.[47] openNetVM is a high performance NFV platform based on DPDK and Docker containers. openNetVM provides a flexible framework for deploying network functions and interconnecting them to build service chains. openNetVM is an open source version of the NetVM platform described in NSDI 2014 and HotMiddlebox 2016 papers, released under the BSD license. The source code can be found at github:openNetVM[48]

See also

• Hardware virtualization
• Network management
• Network virtualization
• OASIS TOSCA
• Open Platform for NFV
• Shortest Path Bridging
• Software-defined networking

References

1. "ETSI - Standards for NFV - Network Functions Virtualisation | NFV Solutions".
2. "Network Functions Virtualisation (NFV); Use NFV is present and SDN is future.Cases" (PDF). Retrieved 6 June 2014.
3. Opengear, Rick Stevenson (2013-03-13). "How Low-Cost Telecom Killed Five 9s in Cloud Computing". Wired. wired.com. Retrieved 2016-06-27.
4. "Network Functions Virtualization— Introductory White Paper" (PDF). ETSI. 22 October 2012. Retrieved 20 June 2013.
5. "Network Functions Virtualisation". ETSI Standards for NFV. Retrieved 30 June 2020.
6. Ray Le Maistre (22 October 2012). "Tier 1 Carriers Tackle Telco SDN". Light Reading. Retrieved 20 June 2013.
7. "Latest Agenda at SDN & OpenFlow World Congress". Layer123.com. Archived from the original on October 14, 2012. Retrieved 20 June 2013.
8. "Standards for NFV: Network Functions Virtualisation". ETSI. NFV Solutions.
9. http://faculty.cs.gwu.edu/timwood/papers/16-HotMiddlebox-onvm.pdf
10. Network-Functions Virtualization (NFV) Proofs of Concept; Framework, GS NFV-PER 002 v1.1.1 (2013-10),
11. "What is Network Function Virtualization (NFV)". blog.datapath.io. Archived from the original on 2017-02-01. Retrieved 2017-01-20.
12. Don’t Confuse ‘High Availability’ with Carrier Grade Archived 2017-07-03 at the Wayback Machine, Embedded Community, Charlie Ashton, April, 2014
13. Tom Nolle (18 September 2013). "Is "Distributed NFV" Teaching Us Something?". CIMI Corporation's Public Blog. Retrieved 2 January 2014.
14. Carol Wilson (3 October 2013). "RAD Rolls Out Distributed NFV Strategy". Light Reading. Retrieved 2 January 2014.
15. "4 Vendors Bring Distributed NFV to BTE". Light Reading. June 11, 2014. Retrieved March 3, 2015.
16. "RAD launches customer-edge distributed NFV solution based on ETX NTU platform". Optical Keyhole. June 16, 2014. Retrieved March 3, 2015.
17. "RAD adds new partners to D-NFV Alliance". Telecompaper. December 9, 2014. Retrieved March 3, 2015.
18. TMCnet News (26 June 2014). "Qosmos Awarded a 2014 INTERNET TELEPHONY NFV Pioneer Award". TMC. Retrieved 26 June 2014.
19. William, Stalling (2016). "Foundations of Modern Networking: SDN, NFV, QoE, IoT, and Cloud". Pearson Education.
20. Rowayda, A. Sadek (May 2018). "An Agile Internet of Things (IoT) based Software Defined Network (SDN) Architecture". Egyptian Computer Science Journal.
21. Platform to Multivendor Virtual and Physical Infrastructure
22. Liyanage, Madhusanka (2015). Software Defined Mobile Networks (SDMN): Beyond LTE Network Architecture. UK: John Wiley. pp. 1–438. ISBN 978-1-118-90028-4.
23. Network Functions Virtualization (NFV) Use Cases, ETSI GS NFV 001 v1.1.1 (2013-10)
24. What’s NFV – Network Functions Virtualization?, SDN Central
25. Carrier Network Virtualization, ETSI news
26. "Openwave Exec Discusses the Benefits, Challenges of NFV & SDN". Article. 12 November 2013. Archived from the original on 3 March 2016. Retrieved 22 November 2013.
27. Middleware for the NFV Generation, Service, Lee Doyle
28. Wind River Launches NFV Ecosystem Program with Five Industry Leaders, PCC Mobile Broadband, Ray Sharma
29. 'Carrier-Grade Reliability—A “Must-Have” for NFV Success', Electronic Design, Charlie Ashton, January 2015
30. '5 must-have attributes Archived 2015-05-26 at the Wayback Machine of an NFV platform', Techzine, Alcatel-Lucent, Andreas Lemke, November 2014
31. 'Why Service Providers Need an NFV Platform' Archived 2015-05-26 at the Wayback Machine, Intel Strategic paper
32. NFV Proof of Concept
33. 'New NFV Forum Focused on Interoperability', Light Reading, Carol Wilson, September 16, 2015
34. OPNFV, Linux Foundation Collaborative Projects Foundation webpage
35. Carrier Network Virtualization Awards Archived 2015-06-07 at the Wayback Machine 2014, December 2015
36. 'Wind River’s Ecosystemic Solution to NFV and Orchestration', CIMI Corporation Public Blog, Tom Nolle, June 2014
37. 'Accelerating Open vSwitch to "Ludicruos Speed", Network Heresy: Tales of the network reformation, Justin D Pettit, November 13, 2014
38. 'Wind River Delivers Breakthrough Performance for Accelerated vSwitch Optimized for NFV' Wind River News Room, May, 2014
39. '6WIND Announces Open vSwitch Acceleration for Red Hat Enterprise Linux OpenStack Platform', PRweb, April, 2014
40. 'NETWORK FUNCTIONS VIRTUALIZATION CHALLENGES AND SOLUTIONS', TMCNET webpage, Alcatel-Lucent Strategic paper, 2013
41. 'NFV: The Myth of Application-Level High Availability Archived 2015-10-05 at the Wayback Machine', Wind River White Paper, May 2015
42. Mano at network-functions-virtualization.com
43. Chatras, B. (December 2018). "On the Standardization of NFV Management and Orchestration APIs". IEEE Communications Standards Magazine. 2 (4): 66–71. doi:10.1109/MCOMSTD.2018.1800032. ISSN 2471-2825.
44. ETSI COMS TEAM. "ETSI - ETSI releases a standard for NFV Deployment Templates". ETSI. Retrieved 2019-07-09.
45. "Technology blogs, NFV, MEC, NGP, ZSM, ENI - SOL006 – NFV descriptors based on YANG Specification". www.etsi.org. Retrieved 2019-07-09.
46. Toward High-Performance and Scalable Network Functions Virtualization
47. http://faculty.cs.gwu.edu/timwood/papers/16-HotMiddlebox-onvm.pdf
48. https://github.com/sdnfv/openNetVM

External links

• NFV basics
• Open Platform for NFV (OPNFV)
• The ETSI NFV FAQ