scispace - formally typeset
Open AccessJournal ArticleDOI

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

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

read more

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
Proceedings ArticleDOI

Hash-based load balanced traffic steering on softswitches for chaining virtualized network functions

TL;DR: The design, implementation, and evaluation of Hash-based Traffic Steering on Softswitches (HATS) shows that HATS can reduce the number of flow entries and service chaining time up to 85% and 93%, respectively, when compared with Least Load First (LLF), a controller-based service chains algorithm.
Journal ArticleDOI

Design and implementation of an intrusion detection system by using Extended BPF in the Linux kernel

TL;DR: In this paper , an intrusion detection system (IDS) that checks the content of headers and payload of packets to detect intrusions from the network is presented, which is an essential function for network security.
Proceedings ArticleDOI

Towards Effective Virtualization of Intrusion Detection Systems

TL;DR: This paper proposes a novel approach to virtualize Intrusion Detection Systems as microservices where the virtualized IDSes can be customized on demand, and the underlying microservices could be shared and scaled independently.
Journal ArticleDOI

Internet of Intelligence: A Survey on the Enabling Technologies, Applications, and Challenges

TL;DR: In this article , the authors provide an overview of the Internet of intelligence, focusing on motivations, architecture, enabling technologies, applications, and existing challenges, which can provide a good foundation for those who are interested to gain insights into the concept of the internet of intelligence and the key enablers of this emerging networking paradigm.
References
More filters
ReportDOI

The NIST Definition of Cloud Computing

Peter Mell, +1 more
TL;DR: This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.
Journal ArticleDOI

Internet of Things (IoT): A vision, architectural elements, and future directions

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.
Journal ArticleDOI

OpenFlow: enabling innovation in campus networks

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

Theory of Linear and Integer Programming

TL;DR: Introduction and Preliminaries.
Book

Tabu Search

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.
Related Papers (5)
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.