This is the author’s version of an article that has been published in IEEE Communications Surveys and Tutorials. Changes were made to this version by the publisher prior to publication. The final version of record is available at http://dx.doi.org/10.1109/COMST.2015.2477041 Network Function Virtualization: State-of-the-art and Research Challenges Rashid Mijumbi, Joan Serrat, Juan-Luis Gorricho, Niels Bouten, Filip De Turck, Raouf Boutaba Abstract—Network Function Virtualization (NFV) has drawn that due to the high competition, both among themselves significant attention from both industry and academia as an and from services being provided over-the-top on their data important shift in telecommunication service provisioning. By channels, increasing prices only leads to customer churn. decoupling Network Functions (NFs) from the physical devices on which they run, NFV has the potential to lead to significant Therefore, TSPs have been forced to find ways of building reductions in Operating Expenses (OPEX) and Capital Expenses more dynamic and service-aware networks with the objective (CAPEX) and facilitate the deployment of new services with of reducing product cycles, operating & capital expenses and increased agility and faster time-to-value. The NFV paradigm is improving service agility. still in its infancy and there is a large spectrum of opportunities NFV [3], [4] has been proposed as a way to address these for the research community to develop new architectures, systems and applications, and to evaluate alternatives and trade-offs in challenges by leveraging virtualization technology to offer a developing technologies for its successful deployment. In this new way to design, deploy and manage networking services. paper, after discussing NFV and its relationship with comple- The main idea of NFV is the decoupling of physical network mentary fields of Software Defined Networking (SDN) and cloud equipment from the functions that run on them. This means computing, we survey the state-of-the-art in NFV, and identify that a network function - such as a firewall - can be dispatched promising research directions in this area. We also overview key NFV projects, standardization efforts, early implementations, use to a TSP as an instance of plain software. This allows for cases and commercial products. the consolidation of many network equipment types onto high volume servers, switches and storage, which could be located Index Terms—Network function virtualization, virtual network functions, future Internet, software defined networking, cloud in data centers, distributed network nodes and at end user computing. premises. 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 I. INTRODUCTION industry standard physical servers. The VNFs may then be Service provision within the telecommunications industry relocated and instantiated at different network locations (e.g., has traditionally been based on network operators deploying aimed at introduction of a service targeting customers in a physical proprietary devices and equipment for each function given geographical location) without necessarily requiring the that is part of a given service. In addition, service components purchase and installation of new hardware. have strict chaining and/or ordering that must be reflected NFV promises TSPs with more flexibility to further open in the network topology and in the localization of service up their network capabilities and services to users and other elements. These, coupled with requirements for high quality, services, and the ability to deploy or support new network stability and stringent protocol adherence, have led to long services faster and cheaper so as to realize better service product cycles, very low service agility and heavy dependence agility. To achieve these benefits, NFV paves the way to a on specialized hardware. number of differences in the way network service provisioning However, the requirements by users for more diverse and is realized in comparison to current practice. In summary, these arXiv:1509.07675v1 [cs.NI] 25 Sep 2015 new (short-lived) services with high data rates continue to differences are as follows [5]: increase. Therefore, Telecommunication Service Providers Decoupling software from hardware. As the network ele- (TSPs) must correspondingly and continuously purchase, store ment is no longer a composition of integrated hardware and and operate new physical equipment. This does not only software entities, the evolution of both are independent of require high and rapidly changing skills for technicians op- each other. This allows separate development timelines and erating and managing this equipment, but also requires dense maintenance for software and hardware. deployments of network equipment such as base stations. All Flexible network function deployment. The detachment of these lead to high CAPEX and OPEX for TSPs [1], [2]. software from hardware helps reassign and share the in- Moreover, even with these high customer demands, the frastructure resources, thus together, hardware and software, resulting increase in capital and operational costs cannot be can perform different functions at various times. This helps translated in higher subscription fees, since TSPs have learned network operators deploy new network services faster over R. Mijumbi, J. Serrat and J.L. Gorricho are with the Network Engineering the same physical platform. Therefore, components can be Department, Universitat Politecnica` de Catalunya, 08034 Barcelona, Spain. instantiated at any NFV-enabled device in the network and N. Bouten and F. De Turck are with Department of Information Technology, their connections can be set up in a flexible way. Ghent University - iMinds, B-9050 Ghent, Belgium. R. Boutaba is with the D.R. Cheriton School of Computer Science, Dynamic scaling. The decoupling of the functionality of the University of Waterloo, Waterloo, Ontario, N2L 3G1, Canada. network function into instantiable software components pro- Copyright (c) 2015 IEEE. Personal use is permitted. For any other purposes, permission must be obtained from the IEEE by emailing [email protected]. IEEE COMMUNICATIONS SURVEYS & TUTORIALS 2 PublicPublic IP IP PrivatePrivate IP IP PublicPublic IP IP PrivatePrivate IP IP ServicesServices ServicesServices ServicesServices ServicesServices ServiceService Provider Provider ServiceService Provider Provider vCorevCoreRouterRouter VirtualVirtual Functions Functions CoreCore Router Router vRouting vRouting vUPnPvUPnP vFirewallvFirewal vNATvNAT l CustomerCustomer Sites Sites CustomerCustomer Sites Sites CPECPE 1 1 CPECPE 2 2 CPECPE 1 1 CPECPE 2 2 CPECPE 3 3 CPECPE N N RoutingRouting RoutingRouting RadioRadio RadioRadio RadioRadio RadioRadio RadioRadio RadioRadio UPnP UPnPUPnPUPnP UPnPUPnP FirewallFirewall FirewallFirewall . .. .. SwitchSwitch SwitchSwitch SwitchSwitch SwitchSwitch NATNAT NATNAT ModemModem ModemModem Modem Modem Modem Modem SwitchSwitch SwitchSwitch Modem Modem Modem Modem Fig. 1. Traditional CPE Implementations Fig. 2. Possible CPE Implementation with NFV vides greater flexibility to scale the actual VNF performance Now, more than two years later, a large community of experts in a more dynamic way and with finer granularity, for instance, are working intensely to develop the required standards for according to the actual traffic for which the network operator NFV as well as sharing their experiences of its development needs to provision capacity. and early implementation. The membership of ETSI has It is worth remarking that the general concept of decoupling grown to over 245 individual companies including 37 of the NFs from dedicated hardware does not necessarily require world’s major service providers as well as representatives virtualization of resources. This means that TSPs could still from both telecoms and IT vendors [6]. ETSI has successfully purchase or develop software (NFs) and run it on physical completed Phase 1 of its work with the publication of 11 machines. The difference is that these NFs would have to be ETSI Group Specifications [7]. These specifications build on able to run on commodity servers. However, the gains (such the first release of ETSI documents published in October as flexibility, dynamic resource scaling, energy efficiency) an- 2013 and include an infrastructure overview, updated architec- ticipated from running these functions on virtualized resources tural framework, and descriptions of the compute, hypervisor are very strong selling points of NFV. Needless to mention, and network domains of the infrastructure. They also cover it is also possible to have hybrid scenarios where functions Management and Orchestration (MANO), security and trust, running on virtualized resources co-exist with those running resilience and service quality metrics. on physical resources. Such hybrid scenarios may be important Since ETSI is not a standards body, its aim is to produce in the transition towards NFV. requirements and potential specifications that TSPs and equip- ment vendors can adapt for their individual environments, and which may be developed by an appropriate standards A. History of Network Function Virtualization development organization (SDO). However, since standards The concept and collaborative work on NFV was born in bodies such as the 3GPP [8] are in liaison with the ETSI, October 2012 when a number of the world’s leading TSPs we can expect these proposals will be generally