Network Function Virtualization: State-of-the-Art and Research Challenges
Summary (7 min read)
Introduction
- The requirements by users for more diverse and new (short-lived) services with high data rates continue to increase.
- This way, a given service can be decomposed into a set of Virtual Network Functions (VNFs), which could then be implemented in software running on one or more industry standard physical servers.
- To achieve these benefits, NFV paves the way to a number of differences in the way network service provisioning is realized in comparison to current practice.
A. History of Network Function Virtualization
- The concept and collaborative work on NFV was born in October 2012 when a number of the world’s leading TSPs jointly authored a white paper [4] calling for industrial and research action.
- The membership of ETSI has grown to over 245 individual companies including 37 of the world’s major service providers as well as representatives from both telecoms and IT vendors [6].
- These specifications build on the first release of ETSI documents published in October 2013 and include an infrastructure overview, updated architectural framework, and descriptions of the compute, hypervisor and network domains of the infrastructure.
- They also cover Management and Orchestration (MANO), security and trust, resilience and service quality metrics.
- Since ETSI is not a standards body, its aim is to produce requirements and potential specifications that TSPs and equipment vendors can adapt for their individual environments, and which may be developed by an appropriate standards development organization (SDO).
B. NFV Examples
- The ETSI has proposed a number of use cases for NFV [9].
- In addition to saving on operational costs for the ISP, this potentially leads to cheaper CPEs if considered on a large scale.
- The EPC is the core network for Long Term Evolution (LTE) as specified by 3GPP [8].
- The same applies to cases when the capacity of the equipment has to be changed.
- Either all functions 2The chain of functions that make up a service for which the connectivity order is important is know as VNF Forwarding Graph [9].
D. Organization
- The rest of this paper is organized as follows: Section II presents the NFV architecture that has been proposed by ETSI, and discusses its limitations.
- The authors propose a reference business model and identify important design considerations in section III.
- In section IV, the authors introduce SDN and cloud computing, describing the relationship between them and NFV, as well as current efforts to implement environments involving all of them.
- In section V, the authors survey the major projects on NFV as well as early implementations, use cases and commercial products.
- Based on a qualitative analysis of the state-of-the-art, section VI identifies key research areas for further exploration, and section VII concludes this paper.
A. NFV Infrastructure (NFVI)
- The NFVI is the combination of both hardware and software resources which make up the environment in which VNFs are deployed.
- Virtual resources are abstractions of the computing, storage and network resources.
- A virtual node is a software component with either hosting or routing functionality, for example an operating system encapsulated in a VM.
- B. Virtual Network Functions and Services A NF is a functional block within a network infrastructure that has well defined external interfaces and well-defined functional behaviour [15].
- The number, type and ordering of VNFs that make it up are determined by the service’s functional and behavioral specification.
C. NFV Management and Orchestration (NFV MANO)
- According to the ETSI’s MANO framework [18], NFV MANO provides the functionality required for the provisioning of VNFs, and the related operations, such as the configuration of the VNFs and the infrastructure these functions run on.
- It includes the orchestration and lifecycle management of physical and/or software resources that support the infrastructure virtualization, and the lifecycle management of VNFs.
- Personal use is permitted, but republication/redistribution requires IEEE permission.
- The ETSI’s scope of work is rather limited, excluding aspects such as control and management of legacy equipment [5].
III. BUSINESS MODEL AND DESIGN CONSIDERATIONS
- Using the architecture represented in Fig. 4, and based on business models for network virtualization [20] and cloud computing [14], the authors identify five main players in a NFV environment and propose a reference business model that illustrates the possible business relationships between them as shown in Fig.
- We also discuss important NFV system design considerations.the authors.
A. Business Model
- InPs deploy and manage physical resources in form of data centers and physical networks, also known as 1) Infrastructure Provider (InP).
- In a more general case, TSPs may sub-lease their virtual resources to other TSPs.
- 3) VNF Providers and Server Providers (SPs): NFV splits the role of traditional network equipment vendors (such as Cisco, Huawei, HP and Alcatel-Lucent) into two: and SPs.
- In some cases, a TSP may need to purchase functions which make up a single service from multiple VNFPs, and/or to deploy and manage the resulting end-toend services running on resources from multiple InPs.
- Personal use is permitted, but republication/redistribution requires IEEE permission.
B. NFV Design Considerations
- As NFV matures, it is important to note that it is not only sufficient to deploy NFs over virtualized infrastructures.
- Finally, to make service deployment resilient, it may be necessary for functions that make up the same service not be hosted by physical resources in the same fault or security domain during deployment.
- Furthermore, service impacting outages need to be limited to a certain amount of users (e.g. a certain geography) and network wide outages are not acceptable [31].
- Personal use is permitted, but republication/redistribution requires IEEE permission.
- In order to achieve the full benefits of NFV, a scalable and responsive networking solution is necessary.
B. Software Defined Networking (SDN)
- SDN [51] is currently attracting significant attention from both academia and industry as an important architecture for the management of large scale complex networks, which may require re-policing or re-configurations from time to time.
- This allows network control to become directly programmable via an open interface (e.g., ForCES [52], OpenFlow [53], etc) and the underlying infrastructure to become simple packet forwarding devices (the data plane) that can be programmed.
- Personal use is permitted, but republication/redistribution requires IEEE permission.
- The authors discuss advances in each of these two aspects below. a).
- Finally, [73] proposes an architecture that considers the control of both SDN and NFV.
C. Summary: NFV, SDN and Cloud Computing
- To summarize the relationship between NFV, SDN, and cloud computing, the authors use Fig. 95.
- The advantages that accrue from each of them are similar; agility, cost reduction, dynamism, automation, resource scaling etc.
- It is whether the cloud will be a public one like Amazon, or if TSPs will prefer to user private ones distributed across their infrastructure.
- Finally, the modern variant of a data center (the cloud and it’s self-service aspect) relies on automated management that may be obtained from SDN and NFV.
- In particular, aspects such as network as a service, load balancing, firewall, VPN etc. all run in software instantiated via APIs.
V. STATE-OF-THE-ART
- As the ETSI continues work on NFV, several other standards organizations, academic and industrial research projects and vendors are working in parallel with diverse objectives, and some of them in close collaboration with the ETSI.
- The authors explore these NFV activities.
- 5It is worth remarking that OpenFlow is not the only SDN protocol.
- In the same way, OpenStack is not the only cloud computing platform.
- The reason the authors present only these two in Fig. 9 is that, as already mentioned, they have received more attention in general, and with regard to NFV.
A. NFV Standardization Activities
- 1) IETF Service Function Chaining Working Group: Functions in a given service have strict chaining and/or ordering requirements that must be considered when decisions to place them in the cloud are made.
- The IETF SFC WG is aimed at producing an architecture for service function chaining that includes the necessary protocols or protocol extensions to convey the service function chain (SFC) and service function path information [78] to nodes that are involved in the implementation of service functions and SFCs, as well as mechanisms for steering traffic through service functions.
- The group is aimed at developing specifications for NFV, focusing on aspects of NFV which include inter-carrier inter-operability and new service descriptions and automated processes.
- The forum also engages open source activities for the implementation of these capabilities in software.
- OVF enables the packaging and secure distribution of virtual machines or appliances, providing cross-platform portability and simplified deployment across multiple platforms including cloud environments.
B. Collaborative NFV Projects
- Zero-time Orchestration, Operations and Management (ZOOM) [85] is a TM Forum project aimed at defining an operations environment necessary to enable the delivery and management of VNFs, and identifying new security approaches that will protect NFVI and VNFs, also known as 1) Zoom.
- It aims to establish a carrier-grade, integrated, open source reference platform to advance the evolution of NFV and to ensure consistency, performance and inter-operability among multiple open source components.
- OpenMANO [88] is an open source project led by Telefonica, which is aimed at implementing ETSI’s NFV MANO framework, also known as 3) OpenMANO.
- Personal use is permitted, but republication/redistribution requires IEEE permission.
- For this purpose, T-NOVA leverages SDN and cloud management architectures to design and implement a management/orchestration platform for the automated provision, configuration, monitoring and optimization of Network Functions-as-a-Service over virtualized network/IT infrastructures.
C. NFV Implementations
- In order to demonstrate the possibility to implement the ideas proposed by NFV, and to determine performance char- 1553-877X (c) 2015 IEEE.
- The HP OpenNFV [111] is a platform, based on HP’s NFV Reference Architecture, upon which services and networks can be dynamically built, also known as 1) HP OpenNFV.
- VNF managers are responsible for the VNFs lifecycle actions, for example, by deciding to scale in or out.
- It enables service injection, consumption, automation, and orchestration across a unified operating framework of pooled resources.
VI. RESEARCH CHALLENGES
- Even with all the anticipated benefits, and despite the immense speed at which it is being accepted by both academia and industry, NFV is still in early stages.
- There still remain important aspects that should be investigated and standard practices which should be established.
- This section discusses crucial research directions that will be invaluable as NFV matures.
A. Management and Orchestration
- The deployment of NFV will greatly challenge current management systems and will require significant changes to the way networks are deployed, operated and managed.
- The challenge then will be to have an acceptable level of orchestration to make sure that on a per service (or user) level, all the required functions are instantiated in a coherent and on-demand basis, and to ensure that the solution remains manageable [129].
- Personal use is permitted, but republication/redistribution requires IEEE permission.
- Looking at the ETSI MANO framework, most effort has been on defining intra-operator interfaces, without clear guidelines on inter-operability.
- Finally, while the ETSI-proposed NFV MANO framework considers the management and orchestration requirements of both virtualized and non-virtualized functions via interfaces to traditional network management functions OSS/BSS, the relationship between them is yet to be fully defined [142].
B. Energy Efficiency
- Since energy bills represent more than 10% of TSPs’ OPEX [143], reduced energy consumption is one of the strong selling points of NFV.
- In addition, Shehab et al. [149] analyzed the technical potential for energy savings associated with shifting U.S. business software to the cloud.
- The tool is able to show the effect of virtualizing different network functions based on forecasts for traffic growth.
- For the same use case, the tool showed that the total energy savings over a five year period (using 2013 as baseline) would be 5.0×109 GJ, and that the energy efficiency of the core network 1.86393 MBITS/J. Personal use is permitted, but republication/redistribution requires IEEE permission.
C. NFV Performance
- The concept of NFV is to run NFs on industry standard servers.
- In the same way, VNF providers should ensure that the functions will be able to run on commodity server.
- The specification gives performance test results on NFV use cases such as DPI, C-RAN, BRAS, etc.
- In a related effort, results from China Mobile’s C-RAN deployment [148] indicated that the Common Public Radio Interface (CPRI) [152] over a wavelength-division multiplexing (WDM) front-haul transport solution gives ideal performance, with no impact on radio performance.
- Ge et. al [28] determine that for some functions (e.g. DPI, Dedup and NAT), industry standard servers may not achieve the required levels of performance.
D. Resource Allocation
- To achieve the economies of scale expected from NFV, physical resources should be used efficiently.
- This calls for efficient algorithms to determine on to which physical resources network functions are placed, and be able to move functions from one server to another for such objectives as load balancing, energy saving, recovery from failures, etc.
- Xia et. al [163] formulate the placement and chaining problem as binary integer programming (BIP), and propose a greedy heuristic to improve computational efficiency.
- The use of containers avoids the overhead of starting and maintaining virtual machines since they do not require a complete duplication of an operating system.
- Unlike the functions in NFV, the tasks in Borg are run directly on hardware not in a virtualized environment.
E. Security, Privacy and Trust
- Consumer uncertainty and concern regarding issues of privacy, security and trust remain a major barrier to the switch to cloud models [183].
- In the case where the functions are deployed in third party clouds, users and Telecom service providers would not have access to the physical security system of data centers.
- Personal use is permitted, but republication/redistribution requires IEEE permission.
- In particular, they have provided a security and trust guidance that is unique to NFV development, architecture and operation [30].
- It was noted that while solutions for these threats are available, there are currently no processes to take advantage of these solutions and, once in place, they will add procedural complexity [60], [184].
F. Modeling of Resources, Functions and Services
- NFV’s potential is based on its ability to deliver high levels of automation and flexibility.
- As part of the MANO specification [18], the ETSI provided a possible set of models that may be useful in NFV.
- TOSCA may be used for VNF definition, node monitoring and active policies like healing and scaling.
- Furthermore, YANG can be used to define the format of event notifications emitted by network elements and it allows data modelers to define the signature of remote procedure calls that can be invoked on network elements via the NETCONF protocol.
- To provide an integration with existing OSS/BSS systems, end-to-end network services that include VNFs or VNF Forwarding Graphs may be able to be mapped to the SID service model [18].
G. Research Directions in Selected NFV Use Cases
- 1) The Internet of Things: Like NFV, the Internet of Things (IoT) [194] paradigm has recently drawn a lot of industrial attention.
- The IoT is a network of physical objects or “things” into which sensors with unique identifiers are embedded.
- While the relationship between NFV, SDN and cloud computing has already received some attention, that between NFV and ICN has not.
- Personal use is permitted, but republication/redistribution requires IEEE permission.
- While the ETSI-defined reference architecture covers most of the aspects needed to operationalize NFV, current specifications are still too general to envelope all the essential pillars of required evolution such as inter-operability, legacy support, and management of both legacy and NFV-based systems.
VII. CONCLUSION
- Due to user demands for real-time, on-demand, online, inexpensive, short-lived services, TSPs have been forced to look for new ways of delivering these services in ways that are agile, and with OPEX and CAPEX savings.
- The authors then compared NFV with closely related fields, SDN and cloud computing, discussing current research for combining them.
- The authors believe that before these areas are explored, TSPs who deploy NFV may end up being reliant on vendor-proprietary solutions to solve these gaps, which would be against the original objective of NFV.
- As NFV moves from labs and PoCs to trials and commercial deployments, vendors are investing significant resources to develop these NFV solutions.
- It is therefore urgent for specification and standardization bodies to complete specifications before it becomes too late for the standards to change or influence what has already been deployed.
Did you find this useful? Give us your feedback
Citations
1,351 citations
766 citations
762 citations
661 citations
645 citations
References
15,145 citations
9,593 citations
9,138 citations
7,005 citations
[...]
6,373 citations
Related Papers (5)
Frequently Asked Questions (12)
Q2. What is the way to implement the forwarding plane?
depending on the performance and capacity needs of the SDN networking element, and depending on whether specialized hardware transport interfaces are required, the forwarding plane may also be implemented on commodity servers [55].
Q3. What is the role of the service provider in a cloud computing environment?
In a cloud computing environment, the traditional role of service provider is dividedinto two: the infrastructure providers who manage cloud platforms and lease resources according to a usage-based pricing model, and service providers, who rent resources from one or many infrastructure providers to serve the end users [14].
Q4. Why does the author want to provide elastic, automated provisioning for hardware acceleration to VNFs?
The author’s efforts are motivated by the observation that for some functions (e.g., DPI, network deduplication (Dedup) and NAT), industry standard servers may not achieve the required levels of performance.
Q5. What is the name of the chain of functions that make up a service?
2The chain of functions that make up a service for which the connectivity order is important is know as VNF Forwarding Graph (VNFFG) [9].
Q6. What is the main reason for the high reliability and availability needs of NFVs?
These high reliability and availability needs are not only a customer expectation, but often a regulatory requirement, as TSPs are considered to be part of critical national infrastructure, and respective legal obligations for service assurance/business continuity are in place.
Q7. What is the relationship between NFV and cloud computing?
In order for NFV to perform acceptably in cloud computing environments, the underlying infrastructure needs to provide a certain number of functionalities which range from scheduling to networking and from orchestration to monitoring capacities.
Q8. What is the role of the VNFs in the NFV ecosystem?
As an example, if VNFs belonging to the same service are placed in different VMs, then there must be a connection between these two VMs, and this connection must provide sustained, aggregated high bandwidth network traffic to the VNFs.
Q9. What are the two important security risks that should be considered in NFV designs?
In particular, there are two important security risks that should be consideredin NFVI designs: (1) functions or services from different subscribers should be protected/isolated from each other.
Q10. What are the main questions that are still open?
While both industry and academia embrace NFV at unprecedented speeds, the development is still at an early stage, with many open questions.
Q11. What is the main selling point of NFV?
any acceptable NFV platform must be an open, shared environment capable of running applications from different vendors.
Q12. What is the highest effort in promoting and standardizing SDN?
It can be observed that the highest efforts in promoting and standardizing SDN is in data center and cloud computing areas while telecom carriers are driving similar efforts for NFV.