scispace - formally typeset
Search or ask a question
Journal ArticleDOI

Network Function Virtualization: State-of-the-Art and Research Challenges

TL;DR: In this article, the authors survey the state-of-the-art in NFV and identify promising research directions in this area, and also overview key NFV projects, standardization efforts, early implementations, use cases, and commercial products.
Abstract: Network function virtualization (NFV) has drawn significant attention from both industry and academia as an important shift in telecommunication service provisioning. By decoupling network functions (NFs) from the physical devices on which they run, NFV has the potential to lead to significant reductions in operating expenses (OPEX) and capital expenses (CAPEX) and facilitate the deployment of new services with increased agility and faster time-to-value. The NFV paradigm is still in its infancy and there is a large spectrum of opportunities for the research community to develop new architectures, systems and applications, and to evaluate alternatives and trade-offs in developing technologies for its successful deployment. In this paper, after discussing NFV and its relationship with complementary fields of software defined networking (SDN) and cloud computing, we survey the state-of-the-art in NFV, and identify promising research directions in this area. We also overview key NFV projects, standardization efforts, early implementations, use cases, and commercial products.

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

Content maybe subject to copyright    Report

1553-877X (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2015.2477041, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS 1
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
significant attention from both industry and academia as an
important shift in telecommunication service provisioning. By
decoupling Network Functions (NFs) from the physical devices
on which they run, NFV has the potential to lead to significant
reductions in Operating Expenses (OPEX) and Capital Expenses
(CAPEX) and facilitate the deployment of new services with
increased agility and faster time-to-value. The NFV paradigm is
still in its infancy and there is a large spectrum of opportunities
for the research community to develop new architectures, systems
and applications, and to evaluate alternatives and trade-offs in
developing technologies for its successful deployment. In this
paper, after discussing NFV and its relationship with comple-
mentary fields of Software Defined Networking (SDN) and cloud
computing, we survey the state-of-the-art in NFV, and identify
promising research directions in this area. We also overview key
NFV projects, standardization efforts, early implementations, use
cases and commercial products.
Index Terms—Network function virtualization, virtual network
functions, future Internet, software defined networking, cloud
computing.
I. INTRODUCTION
Service provision within the telecommunications industry
has traditionally been based on network operators deploying
physical proprietary devices and equipment for each function
that is part of a given service. In addition, service components
have strict chaining and/or ordering that must be reflected
in the network topology and in the localization of service
elements. These, coupled with requirements for high quality,
stability and stringent protocol adherence, have led to long
product cycles, very low service agility and heavy dependence
on specialized hardware.
However, the requirements by users for more diverse and
new (short-lived) services with high data rates continue to
increase. Therefore, Telecommunication Service Providers
(TSPs) must correspondingly and continuously purchase, store
and operate new physical equipment. This does not only
require high and rapidly changing skills for technicians op-
erating and managing this equipment, but also requires dense
deployments of network equipment such as base stations. All
these lead to high CAPEX and OPEX for TSPs [1], [2].
Moreover, even with these high customer demands, the
resulting increase in capital and operational costs cannot be
translated in higher subscription fees, since TSPs have learned
R. Mijumbi, J. Serrat and J.L. Gorricho are with the Network Engineering
Department, Universitat Polit
`
ecnica de Catalunya, 08034 Barcelona, Spain.
N. Bouten and F. De Turck are with Department of Information Technology,
Ghent University - iMinds, B-9050 Ghent, Belgium.
R. Boutaba is with the D.R. Cheriton School of Computer Science,
University of Waterloo, Waterloo, Ontario, N2L 3G1, Canada.
that due to the high competition, both among themselves
and from services being provided over-the-top on their data
channels, increasing prices only leads to customer churn.
Therefore, TSPs have been forced to find ways of building
more dynamic and service-aware networks with the objective
of reducing product cycles, operating & capital expenses and
improving service agility.
NFV [3], [4] has been proposed as a way to address these
challenges by leveraging virtualization technology to offer a
new way to design, deploy and manage networking services.
The main idea of NFV is the decoupling of physical network
equipment from the functions that run on them. This means
that a network function - such as a firewall - can be dispatched
to a TSP as an instance of plain software. This allows for
the consolidation of many network equipment types onto high
volume servers, switches and storage, which could be located
in data centers, distributed network nodes and at end user
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
industry standard physical servers. The VNFs may then be
relocated and instantiated at different network locations (e.g.,
aimed at introduction of a service targeting customers in a
given geographical location) without necessarily requiring the
purchase and installation of new hardware.
NFV promises TSPs with more flexibility to further open
up their network capabilities and services to users and other
services, and the ability to deploy or support new network
services faster and cheaper so as to realize better service
agility. 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. In summary, these
differences are as follows [5]:
Decoupling software from hardware. As the network ele-
ment is no longer a composition of integrated hardware and
software entities, the evolution of both are independent of
each other. This allows separate development timelines and
maintenance for software and hardware.
Flexible network function deployment. The detachment of
software from hardware helps reassign and share the in-
frastructure resources, thus together, hardware and software,
can perform different functions at various times. This helps
network operators deploy new network services faster over
the same physical platform. Therefore, components can be
instantiated at any NFV-enabled device in the network and
their connections can be set up in a flexible way.
Dynamic scaling. The decoupling of the functionality of the
network function into instantiable software components pro-

1553-877X (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2015.2477041, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS 2
Customer Sites
CPE 1
UPnP
UPnP
Modem
Switch
Radio
Firewall
Routing
NAT
Service Provider
Public IP
Services
Private IP
Services
CPE 2
UPnP
UPnP
Modem
Switch
Radio
Firewall
Routing
NAT
Core Router
Customer Sites
CPE 1
UPnP
vUPnP
Modem
Switch
Radio
vFirewal
l
vRouting
vNAT
Service Provider
Public IP
Services
Private IP
Services
vCore Router
Modem
Switch
Radio
Modem
Switch
Radio
Modem
Switch
Radio
. . .
CPE 2
CPE 3
CPE N
Virtual Functions
Fig. 1. Traditional CPE Implementations
Customer Sites
CPE 1
UPnP
UPnP
Modem
Switch
Radio
Firewall
Routing
NAT
Service Provider
Public IP
Services
Private IP
Services
CPE 2
UPnP
UPnP
Modem
Switch
Radio
Firewall
Routing
NAT
Core Router
Customer Sites
CPE 1
UPnP
vUPnP
Modem
Switch
Radio
vFirewall
vRouting
vNAT
Service Provider
Public IP
Services
Private IP
Services
vCore Router
Modem
Switch
Radio
Modem
Switch
Radio
Modem
Switch
Radio
. . .
CPE 2
CPE 3
CPE N
Virtual Functions
Fig. 2. Possible CPE Implementation with NFV
vides greater flexibility to scale the actual VNF performance
in a more dynamic way and with finer granularity, for instance,
according to the actual traffic for which the network operator
needs to provision capacity.
It is worth remarking that the general concept of decoupling
NFs from dedicated hardware does not necessarily require
virtualization of resources. This means that TSPs could still
purchase or develop software (NFs) and run it on physical
machines. The difference is that these NFs would have to be
able to run on commodity servers. However, the gains (such
as flexibility, dynamic resource scaling, energy efficiency) an-
ticipated from running these functions on virtualized resources
are very strong selling points of NFV. Needless to mention,
it is also possible to have hybrid scenarios where functions
running on virtualized resources co-exist with those running
on physical resources. Such hybrid scenarios may be important
in the transition towards NFV.
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. In November 2012 seven of these operators
(AT&T, BT, Deutsche Telekom, Orange, Telecom Italia, Tele-
fonica and Verizon) selected the European Telecommunica-
tions Standards Institute (ETSI)[6] to be the home of the
Industry Specification Group for NFV (ETSI ISG NFV)
1
.
1
In the rest of this paper, the acronyms ETSI and ETSI ISG NFV are used
synonymously.
Now, more than two years later, a large community of experts
are working intensely to develop the required standards for
NFV as well as sharing their experiences of its development
and early implementation. 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]. ETSI has successfully
completed Phase 1 of its work with the publication of 11 ETSI
Group Specifications [7]. 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 equip-
ment vendors can adapt for their individual environments,
and which may be developed by an appropriate standards
development organization (SDO). However, since standards
bodies such as the 3GPP [8] are in liaison with the ETSI,
we can expect these proposals will be generally accepted and
enforced as standards. 3GPP’s Telecom Management working
group (SA5) is also studying the management of virtualized
3GPP network functions.
B. NFV Examples
The ETSI has proposed a number of use cases for NFV [9].
In this subsection, we will explain how NFV may be applied

1553-877X (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2015.2477041, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS 3
to Customer Premises Equipment (CPE), and to an Evolved
Packet Core (EPC) network.
1) Customer Premises Equipment (CPE): In Figures 1 and
2, we use an example of a CPE to illustrate the economies of
scale that may be achieved by NFV. Fig. 1 shows a typical
(current) implementation of a CPE which is made up of the
functions: Dynamic Host Configuration Protocol (DHCP),
Network Address Translation (NAT), routing, Universal Plug
and Play (UPnP), Firewall, Modem, radio and switching. In
this example, a single service (the CPE) is made up of eight
functions. These functions may have precedence requirements.
For example, if the functions are part of a service chain
2
, it
may be required to perform firewall functions before NAT.
Currently, it is necessary to have these functions in a physical
device located at the premises of each of the customers 1 and
2. With such an implementation, if there is a need to make
changes to the CPE, say, by adding, removing or updating a
function, it may be necessary for a technician from the ISP to
individually talk to or go to each of the customers. It may even
require a complete change of the device in case of additions.
This is not only expensive (operationally) for the ISPs, but
also for the customers.
In Figure 2, we show a possible implementation based on
NFV in which some of the functions of the CPE are transferred
to a shared infrastructure at the ISP, which could also be a data
center. This makes the changes described above easier since,
for example, updating the DHCP for all customers would
only involve changes at the ISP. In the same way, adding
another function such as parental controls for all or a subset
of customers can be done at once. In addition to saving on
operational costs for the ISP, this potentially leads to cheaper
CPEs if considered on a large scale.
2) Evolved Packet Core: Virtualizing the EPC is another
example of NFV that has attracted a lot of attention from
industry. The EPC is the core network for Long Term Evolu-
tion (LTE) as specified by 3GPP [8]. On the left side of Fig.
3, we show a basic architecture of LTE without NFV. The
User Equipment (UE) is connected to the EPC over the LTE
access network (E-UTRAN). The evolved NodeB (eNodeB)
is the base station for LTE radio. The EPC performs essential
functions including subscriber tracking, mobility management
and session management. It is made up of four NFs: Serving
Gateway (S-GW), Packet Data Network (PDN) Gateway (P-
GW), Mobility Management Entity (MME), and Policy and
Charging Rules Function (PCRF). It is also connected to
external networks, which may include the IP Multimedia
Core Network Subsystem (IMS). In the current EPC, all its
functions are based on proprietary equipment. Therefore, even
minor changes to a given function may require a replacement
of the equipment. The same applies to cases when the capacity
of the equipment has to be changed.
On the right side of Fig. 3, we show the same architecture in
which the EPC is virtualized. In this case, either all functions
2
The chain of functions that make up a service for which the connectivity
order is important is know as VNF Forwarding Graph (VNFFG) [9]. In
addition to sequencing requirements, the links in a VNFFG may split (i.e.
from one function, packets could take one of many paths which lead to similar
functionality), or may join.
Fig. 3. Virtualization of the EPC
in the EPC, or only a few of them are transferred to a shared
(cloud) infrastructure. Virtualizing the EPC could potentially
lead to better flexibility and dynamic scaling, and hence allow
TSPs to respond easily and cheaply to changes in market
conditions. For example, as represented by the number of
servers allocated to each function in Fig. 3, there might be
a need to increase user plane resources without affecting the
control plane. In this case, VNFs such as a virtual MME
may scale independently according to their specific resource
requirements. In the same way, VNFs dealing with the data
plane might require a different number of resources than those
dealing with signaling only. This flexibility would lead to more
efficient utilization of resources. Finally, it also allows for
easier software upgrades on the EPC network functions, which
would hence allow for faster launch of innovative services.
C. Related Work and Open Questions
While both industry and academia embrace NFV at unprece-
dented speeds, the development is still at an early stage, with
many open questions. As TSPs and vendors look at the details
of implementing NFV and accomplishing its foreseen goals,
there are concerns about the realization of some of these goals
and whether implementation translates to the benefits initially
expected. There are important unexplored research challenges
such as testing and validation [10], resource management,
inter-operability, instantiation, performance of VNFs, etc, that
should be addressed. Even areas being explored such as
MANO still have open questions especially with regard to
support for heterogeneity.
There have been recent efforts to introduce NFV, explain its
performance requirements, architecture, uses cases and poten-
tial approaches to challenges [3]. A discussion of challenges
to introducing NFV in mobile networks, with a focus on
virtualized evolved packet core is presented in [11], while

1553-877X (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2015.2477041, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS 4
the reliability challenges of NFV infrastructures are examined
in [12]. However, all efforts in current literature are narrow
in at least one of the following main ways: (1) with regard
to scope, they do not consider important aspects of NFV,
such as its relationship with SDN and cloud computing, (2)
limited review and analysis of standardization activities, and
(3) incomplete descriptions of ongoing research and state-of-
the-art efforts and research challenges.
This paper examines the state-of-the-art in NFV and iden-
tifies key research areas for future exploration. In addition,
we explore the relationship between NFV and two closely
related fields, SDN [13] and cloud computing [14]. We also
describe the different research and industrial initiatives and
projects on NFV, as well as early implementation, proof of
concepts and product cases. To the best of our knowledge, this
paper presents the most comprehensive state-of-the-art survey
on NFV to date.
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. We propose a reference business
model and identify important design considerations in section
III. In section IV, we 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, we 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.
II. NFV ARCHITECTURE
According to ETSI, the NFV Architecture is composed of
three key elements: Network Function Virtualization Infras-
tructure (NFVI), VNFs and NFV MANO [15]. We represent
them graphically in Fig. 4. In this section these elements are
defined [5], [15], [16].
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. The physical resources include commercial-off-
the-shelf (COTS) computing hardware, storage and network
(made up of nodes and links) that provide processing, storage
and connectivity to VNFs. Virtual resources are abstractions
of the computing, storage and network resources. The ab-
straction is achieved using a virtualization layer (based on a
hypervisor), which decouples the virtual resources from the
underlying physical resources. In a data center environment,
the computing and storage resources may be represented in
terms of one or more Virtual Machines (VMs), while virtual
networks are made up of virtual links and nodes. A virtual
node is a software component with either hosting or routing
functionality, for example an operating system encapsulated
in a VM. A virtual link is a logical interconnection of two
virtual nodes, appearing to them as a direct physical link with
dynamically changing properties [17].
Fig. 4. Network Function Virtualization Architecture
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]. Examples of NFs are elements
in a home network, e.g. Residential Gateway (RGW); and
conventional network functions, e.g. DHCP servers, firewalls,
etc. Therefore, a VNF is an implementation of an NF that is
deployed on virtual resources such as a VM. A single VNF
may be composed of multiple internal components, and hence
it could be deployed over multiple VMs, in which case each
VM hosts a single component of the VNF [5]. A service
is an offering provided by a TSP that is composed of one
or more NFs. In the case of NFV, the NFs that make up
the service are virtualized and deployed on virtual resources
such as a VM. However, in the perspective of the users,
the serviceswhether based on functions running dedicated
equipment or on VMsshould have the same performance.
The number, type and ordering of VNFs that make it up are
determined by the service’s functional and behavioral speci-
fication. Therefore, the behaviour of the service is dependent
on that of the constituent VNFs.
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. It also includes databases that
are used to store the information and data models which
define both deployment as well as lifecycle properties of
functions, services, and resources. NFV MANO focuses on
all virtualization-specific management tasks necessary in the
NFV framework. In addition the framework defines interfaces
that can be used for communications between the different
components of the NFV MANO, as well as coordination with
traditional network management systems such as Operations

1553-877X (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2015.2477041, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS 5
Support System (OSS) and Business Support Systems (BSS)
so as to allow for management of both VNFs as well as
functions running on legacy equipment.
Discussion: The ETSI-proposed NFV reference architecture
specifies initial functional requirements and outlines the re-
quired interfaces. However, the ETSI’s scope of work is rather
limited, excluding aspects such as control and management of
legacy equipment [5]. This could make it difficult to specify
the operation and MANO of an end-to-end service involving
both legacy functions and VNFs. In addition, standards and/or
de-facto best practices and reference implementations of the
VNFs, infrastructure, MANO and detailed definitions of re-
quired interfaces are not yet available.
In particular, it can be seen from current NFV solutions
that vendors have differing ideas on what constitutes an NFVI
and VNFs, and how both of them can be modeled. There
remains a number of open questions such as: (1) which NFs
should be deployed in data center nodes, and which ones
in operator nodes; (2) which functions should be deployed
on dedicated VMs and which ones in containers
3
; (3) what
quantity and types of NFVI resources will be required to
run specific functions; and (4) operational requirements of
environments that involve both VNFs and those running on
legacy equipment. While many of these questions such as
inter-operability and interface definition will be addressed in
the second Phase of ETSI’s work, time is of the essence. Since
both vendors and TSPs are already investing significantly in
NFV, we could reach a point where it is impossible to reverse
the vendor-specific solutions.
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], we 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. 5. We also discuss important NFV system
design considerations.
A. Business Model
1) Infrastructure Provider (InP): InPs deploy and manage
physical resources in form of data centers and physical net-
works. It is on top of these resources that virtual resources may
be provisioned and leased through programming interfaces to
one or more TSPs. The InPs may also determine how the pool
of the available resources are allocated to the TSPs. In NFV,
examples of InPs could be public data centers such as those
by Amazon, or private servers owned by TSPs. If a given InP
is not able to provide resources fully or in part to a given
TSPs, negotiations and hence coalitions can be formed with
other InPs so as to provision multi-domain VNFs [21].
3
In fact, even the fact whether containers may be used to host VNFs and
the corresponding ecosystem still needs research [19].
Brokers
Infrastructure Provider (InP)
Computing, Storage, Network Resources
User
Telecommunications Service
Provider (TSP)
2
3
4
VNF
Provider
(VNFP)
Server
Provider
(SP)
1
2
Fig. 5. Proposed NFV Business Model
2) Telecommunications Service Provider (TSP): TSPs
4
lease resources from one or more InPs, which they use for
running VNFs. They also determine the chaining of these
functions to create services for end users. In a more general
case, TSPs may sub-lease their virtual resources to other TSPs.
In such a case, the reselling TSP would take up the role of a
InP. In cases where the InP is private or in-house, e.g. provided
by TSP network nodes or servers, then the InP and TSP may
be one entity.
3) VNF Providers (VNFPs) and Server Providers (SPs):
NFV splits the role of traditional network equipment vendors
(such as Cisco, Huawei, HP and Alcatel-Lucent) into two:
VNFPs and SPs. VNFPs provide software implementations
for NFs. These functions may either be provided directly to
TSPs (via interface 1), or VNFPs could provide them to InPs
(via interface 2), who would then provide both infrastructure
as well as VNFs to TSPs. It is also possible that TSPs develop
(some of) their own NFs (software). In this case, VNFPs and
TSPs would be one entity.
In the same way, SPs provide industry standard servers on
which VNFs can be deployed. These servers may be provided
to InPs (in case the functions will be run in a cloud), or to
TSPs (in case the functions will be run in the network nodes of
TSPs). It is worth noting that these entities (VNFPs and SPs)
may in fact be one company. The main difference is that the
functions they provide are not tied to running on equipment
with specialized functionality or made by a specific vendor.
In other words, a TSP could purchase VNFs from one entity,
and servers from a different one.
4) Brokers: 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-to-
end services running on resources from multiple InPs. In this
case, it may be necessary to have a brokerage role. The brokers
would receive resource and/or functions requirements from
TSPs and then discover, negotiate and aggregate resources and
functions from multiple InPs, VNFPs and SPs to offer them as
4
In this paper, we use the term TSP to generally mean all service providers.
This includes service providers such as Netflix that deploy services with
caches in different locations, as well as the traditional TSPs such as Telefonica
and Deutsche Telecom.

Citations
More filters
Journal ArticleDOI
TL;DR: This paper analyzes the MEC reference architecture and main deployment scenarios, which offer multi-tenancy support for application developers, content providers, and third parties, and elaborates further on open research challenges.
Abstract: Multi-access edge computing (MEC) is an emerging ecosystem, which aims at converging telecommunication and IT services, providing a cloud computing platform at the edge of the radio access network MEC offers storage and computational resources at the edge, reducing latency for mobile end users and utilizing more efficiently the mobile backhaul and core networks This paper introduces a survey on MEC and focuses on the fundamental key enabling technologies It elaborates MEC orchestration considering both individual services and a network of MEC platforms supporting mobility, bringing light into the different orchestration deployment options In addition, this paper analyzes the MEC reference architecture and main deployment scenarios, which offer multi-tenancy support for application developers, content providers, and third parties Finally, this paper overviews the current standardization activities and elaborates further on open research challenges

1,351 citations

Journal ArticleDOI
TL;DR: The diverse use cases and network requirements of network slicing, the pre-slicing era, considering RAN sharing as well as the end-to-end orchestration and management, encompassing the radio access, transport network and the core network are outlined.
Abstract: Network slicing has been identified as the backbone of the rapidly evolving 5G technology. However, as its consolidation and standardization progress, there are no literatures that comprehensively discuss its key principles, enablers, and research challenges. This paper elaborates network slicing from an end-to-end perspective detailing its historical heritage, principal concepts, enabling technologies and solutions as well as the current standardization efforts. In particular, it overviews the diverse use cases and network requirements of network slicing, the pre-slicing era, considering RAN sharing as well as the end-to-end orchestration and management, encompassing the radio access, transport network and the core network. This paper also provides details of specific slicing solutions for each part of the 5G system. Finally, this paper identifies a number of open research challenges and provides recommendations toward potential solutions.

766 citations

Journal ArticleDOI
TL;DR: This paper presents a comprehensive state of the art of NFV-RA by introducing a novel classification of the main approaches that pose solutions to solve the NFV resource allocation problem.
Abstract: Network functions virtualization (NFV) is a new network architecture framework where network function that traditionally used dedicated hardware (middleboxes or network appliances) are now implemented in software that runs on top of general purpose hardware such as high volume server. NFV emerges as an initiative from the industry (network operators, carriers, and manufacturers) in order to increase the deployment flexibility and integration of new network services with increased agility within operator’s networks and to obtain significant reductions in operating expenditures and capital expenditures. NFV promotes virtualizing network functions such as transcoders, firewalls, and load balancers, among others, which were carried out by specialized hardware devices and migrating them to software-based appliances. One of the main challenges for the deployment of NFV is the resource allocation of demanded network services in NFV-based network infrastructures. This challenge has been called the NFV resource allocation (NFV-RA) problem. This paper presents a comprehensive state of the art of NFV-RA by introducing a novel classification of the main approaches that pose solutions to solve it. This paper also presents the research challenges that are still subject of future investigation in the NFV-RA realm.

762 citations

Journal ArticleDOI
TL;DR: This paper is the first to present the state-of-the-art of the SAGIN since existing survey papers focused on either only one single network segment in space or air, or the integration of space-ground, neglecting the Integration of all the three network segments.
Abstract: Space-air-ground integrated network (SAGIN), as an integration of satellite systems, aerial networks, and terrestrial communications, has been becoming an emerging architecture and attracted intensive research interest during the past years. Besides bringing significant benefits for various practical services and applications, SAGIN is also facing many unprecedented challenges due to its specific characteristics, such as heterogeneity, self-organization, and time-variability. Compared to traditional ground or satellite networks, SAGIN is affected by the limited and unbalanced network resources in all three network segments, so that it is difficult to obtain the best performances for traffic delivery. Therefore, the system integration, protocol optimization, resource management, and allocation in SAGIN is of great significance. To the best of our knowledge, we are the first to present the state-of-the-art of the SAGIN since existing survey papers focused on either only one single network segment in space or air, or the integration of space-ground, neglecting the integration of all the three network segments. In light of this, we present in this paper a comprehensive review of recent research works concerning SAGIN from network design and resource allocation to performance analysis and optimization. After discussing several existing network architectures, we also point out some technology challenges and future directions.

661 citations

Journal ArticleDOI
TL;DR: Fog computing extends the cloud services to the edge of network, and makes computation, communication and storage closer to edge devices and end-users, which aims to enhance low-latency, mobility, network bandwidth, security and privacy.

645 citations

References
More filters
ReportDOI
28 Sep 2011
TL;DR: This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.
Abstract: Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.

15,145 citations

Journal ArticleDOI
TL;DR: In this article, the authors present a cloud centric vision for worldwide implementation of Internet of Things (IoT) and present a Cloud implementation using Aneka, which is based on interaction of private and public Clouds, and conclude their IoT vision by expanding on the need for convergence of WSN, the Internet and distributed computing directed at technological research community.

9,593 citations

Journal ArticleDOI
31 Mar 2008
TL;DR: This whitepaper proposes OpenFlow: a way for researchers to run experimental protocols in the networks they use every day, based on an Ethernet switch, with an internal flow-table, and a standardized interface to add and remove flow entries.
Abstract: This whitepaper proposes OpenFlow: a way for researchers to run experimental protocols in the networks they use every day. OpenFlow is based on an Ethernet switch, with an internal flow-table, and a standardized interface to add and remove flow entries. Our goal is to encourage networking vendors to add OpenFlow to their switch products for deployment in college campus backbones and wiring closets. We believe that OpenFlow is a pragmatic compromise: on one hand, it allows researchers to run experiments on heterogeneous switches in a uniform way at line-rate and with high port-density; while on the other hand, vendors do not need to expose the internal workings of their switches. In addition to allowing researchers to evaluate their ideas in real-world traffic settings, OpenFlow could serve as a useful campus component in proposed large-scale testbeds like GENI. Two buildings at Stanford University will soon run OpenFlow networks, using commercial Ethernet switches and routers. We will work to encourage deployment at other schools; and We encourage you to consider deploying OpenFlow in your university network too

9,138 citations

Book
01 Dec 1986
TL;DR: Introduction and Preliminaries.
Abstract: Introduction and Preliminaries. Problems, Algorithms, and Complexity. LINEAR ALGEBRA. Linear Algebra and Complexity. LATTICES AND LINEAR DIOPHANTINE EQUATIONS. Theory of Lattices and Linear Diophantine Equations. Algorithms for Linear Diophantine Equations. Diophantine Approximation and Basis Reduction. POLYHEDRA, LINEAR INEQUALITIES, AND LINEAR PROGRAMMING. Fundamental Concepts and Results on Polyhedra, Linear Inequalities, and Linear Programming. The Structure of Polyhedra. Polarity, and Blocking and Anti--Blocking Polyhedra. Sizes and the Theoretical Complexity of Linear Inequalities and Linear Programming. The Simplex Method. Primal--Dual, Elimination, and Relaxation Methods. Khachiyana s Method for Linear Programming. The Ellipsoid Method for Polyhedra More Generally. Further Polynomiality Results in Linear Programming. INTEGER LINEAR PROGRAMMING. Introduction to Integer Linear Programming. Estimates in Integer Linear Programming. The Complexity of Integer Linear Programming. Totally Unimodular Matrices: Fundamental Properties and Examples. Recognizing Total Unimodularity. Further Theory Related to Total Unimodularity. Integral Polyhedra and Total Dual Integrality. Cutting Planes. Further Methods in Integer Linear Programming. References. Indexes.

7,005 citations

Book
31 Jul 1997
TL;DR: This book explores the meta-heuristics approach called tabu search, which is dramatically changing the authors' ability to solve a host of problems that stretch over the realms of resource planning, telecommunications, VLSI design, financial analysis, scheduling, spaceplanning, energy distribution, molecular engineering, logistics, pattern classification, flexible manufacturing, waste management,mineral exploration, biomedical analysis, environmental conservation and scores of other problems.
Abstract: From the Publisher: This book explores the meta-heuristics approach called tabu search, which is dramatically changing our ability to solve a hostof problems that stretch over the realms of resource planning,telecommunications, VLSI design, financial analysis, scheduling, spaceplanning, energy distribution, molecular engineering, logistics,pattern classification, flexible manufacturing, waste management,mineral exploration, biomedical analysis, environmental conservationand scores of other problems. The major ideas of tabu search arepresented with examples that show their relevance to multipleapplications. Numerous illustrations and diagrams are used to clarifyprinciples that deserve emphasis, and that have not always been wellunderstood or applied. The book's goal is to provide ''hands-on' knowledge and insight alike, rather than to focus exclusively eitheron computational recipes or on abstract themes. This book is designedto be useful and accessible to researchers and practitioners inmanagement science, industrial engineering, economics, and computerscience. It can appropriately be used as a textbook in a masterscourse or in a doctoral seminar. Because of its emphasis on presentingideas through illustrations and diagrams, and on identifyingassociated practical applications, it can also be used as asupplementary text in upper division undergraduate courses. Finally, there are many more applications of tabu search than canpossibly be covered in a single book, and new ones are emerging everyday. The book's goal is to provide a grounding in the essential ideasof tabu search that will allow readers to create successfulapplications of their own. Along with the essentialideas,understanding of advanced issues is provided, enabling researchers togo beyond today's developments and create the methods of tomorrow.

6,373 citations

Frequently Asked Questions (12)
Q1. What contributions have the authors mentioned in the paper "Network function virtualization: state-of-the-art and research challenges" ?

In this paper, after discussing NFV and its relationship with complementary fields of Software Defined Networking ( SDN ) and cloud computing, the authors survey the state-of-the-art in NFV, and identify promising research directions in this area. The authors also overview key NFV projects, standardization efforts, early implementations, use cases and commercial products. 

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

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

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. 

2The chain of functions that make up a service for which the connectivity order is important is know as VNF Forwarding Graph (VNFFG) [9]. 

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. 

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. 

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. 

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. 

While both industry and academia embrace NFV at unprecedented speeds, the development is still at an early stage, with many open questions. 

any acceptable NFV platform must be an open, shared environment capable of running applications from different vendors. 

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.