This paper has been accepted in IEEE Journal on Selected Areas in Communications,

vol. 35, no. 11, pp. 2468-2478, Nov. 2017. (doi: 10.1109/JSAC.2017.2760418)

NFV and SDN - Key Technology

Enablers for 5G Networks
Faqir Zarrar Yousaf, Michael Bredel, Sibylle Schaller, and Fabian Schneider
arXiv:1806.07316v1 [cs.NI] 19 Jun 2018

NEC Laboratories Europe

69115 Heidelberg, Germany
Email: {zarrar.yousaf, michael.bredel, sibylle.schaller, fabian.schneider}@neclab.eu

Abstract—Communication networks are undergoing their next of a customer has changed from human customers only to now
evolutionary step towards 5G. The 5G networks are envisioned also include cars, sensors, consumer electronic items, energy
to provide a flexible, scalable, agile and programmable network meters etc. With such a diverse customer base, the mobile
platform over which different services with varying requirements
can be deployed and managed within strict performance bounds. network not only has to manage the burgeoning data volume,
In order to address these challenges a paradigm shift is taking but at the same time ensure that customer service requests
place in the technologies that drive the networks, and thus are being adequately fulfilled by the network, meeting the
their architecture. Innovative concepts and techniques are being respective quality-of-service or quality-of-experience require-
developed to power the next generation mobile networks. At the ments. In order to meet the data and service requirements,
heart of this development lie Network Function Virtualization
and Software Defined Networking technologies, which are now the network operators are constantly expanding and upgrading
recognized as being two of the key technology enablers for their network infrastructure, resulting in increased capital and
realizing 5G networks, and which have introduced a major operational expenditures (capex and opex). However, in view
change in the way network services are deployed and operated. of the intense competition and falling prices, the average
For interested readers that are new to the field of SDN and NFV revenue per user is not increasing proportionately resulting
this paper provides an overview of both these technologies with
reference to the 5G networks. Most importantly it describes how in lower return on investment. Thus, in order to reduce costs
the two technologies complement each other and how they are and increase revenue mobile networks need to take their next
expected to drive the networks of near future. evolutionary leap towards 5G, which now not only addresses
the mobile edge, but also the core network.
Index Terms—5G Networks, NFV, SDN.

I. I NTRODUCTION
Communication networks have evolved through three major
generational leaps following the technology trends and con-
stantly evolving user demands. The first evolutionary jump
was from the first generation, known as 1G, to the second
generation, i.e. 2G, when the mobile voice network was
digitized. The next evolutionary jump from 2G to 3G was
made in order to fulfill the users’ ever increasing demand for
data and service quality. The proliferation of sophisticated user
platforms, such as smart phones and tablets, and mushrooming
new bandwidth intensive mobile applications further fueled
user appetite for bandwidth and quality. This has led to the
next evolutionary leap towards 4G, which has made mobile
networks provide a true wireless broadband service to its
customers. With the enhanced options offered by 4G, new use Fig. 1: A 5G System Vision [1].
cases, such as in health, automotive, entertainment, industrial,
social, environmental etc. sectors, with diverse service require-
ments have been introduced. Services are innovating rapidly A. 5th Generation Networks - Vision
with exceeding reliance on the mobile network infrastructure 5G networks, also referred to as beyond 2020 communica-
for their connectivity needs. With such evolution and the tions systems, represent the next major phase of the telecom
Internet transforming towards an Internet-of-Things, the notion industry. The three main features that shall characterize a
5G network will be its ability to support Enhanced Mobile
Broadband, Massive Machine Type Communication and the
provisioning of Ultra-reliable Low Latency Communication
services. This entails 5G networks to provide increased peak
bit rates at Gbps per user, have higher spectrum efficiency,
better coverage, and support for a massively increased number
of diverse connectable devices. In addition, 5G systems are
required to be cost efficient, reliable, flexibly deployable, elas-
tic, agile, and above all programmable. These are ambitious
and highly challenging requirements that have implications on
both the mobile radio access network as well as the mobile
core network, and thus require a major re-design and re-
engineering of both the architecture and the technologies. In
view of these ambitious requirements, new innovative methods
and systems are being explored and evaluated in order to meet
the challenging performance goals of 5G networks.
First commercial deployments of 5G networks are expected
in 2020. Different stake-holders have expressed their respec-
tive vision of a 5G network, and Fig. 1 illustrates one such
Fig. 2: Network Slicing in 5G as envisioned by the NGMN project.
high-level vision [1] where the 5G network eco-system is
depicted as a three-tier model. Shown at the lowest level
are physical resources and assets such as compute, network,
storage, which are distributed and available in the back-end slice instances can be orchestrated and configured separately
data centers, core network infrastructures, and radio access according to their specific requirements, e.g. in terms of
networks. These physical resources are abstracted to create a network quality-of-service. Additionally, this is performed in
virtualized second level where network functions and other a cost efficient manner as the different network slice tenants
value-added application functions are enabled as virtualized share the same physical infrastructure.
instances or entities. The top-level consists of heterogeneous While the network slicing concept has been proposed re-
services that shall consume the APIs exposed by the virtual- cently [2], it has already attracted substantial attention and
ized entities below in order for them to provide their respective several standardization bodies started working on it. 3GPP
services transparently and in isolation to each other over has is working on the definition of requirements for network
a common network platform while meeting their respective slicing [3], whereas NGMN identified network sharing among
operational and functional service requirements. slices as one of the key 5G issues [4]. A Network Slice is
defined by NGMN as a set of network functions, and resources
B. 5G Slicing Concept & Challenges to run these network functions, forming a complete instanti-
ated logical network to meet certain network characteristics
The vision of 5G networks discussed above leads to a very
required by the service instance(s). According to NGMN, the
important concept of slicing that has become a central theme
concept of network slicing involves three layers namely (i)
in 5G networks. Network slicing allows network operators
service instance layer, (ii) network slice instance layer, and
to open their physical network infrastructure platform to
(iii) resource layer. The service instance layer represents the
the concurrent deployment of multiple logical self-contained
end-user and/or business services, provided by the operator or
networks, orchestrated in different ways according to their
the 3rd party service providers, which are supported by the
specific service requirements; such network slices are then
network slice instance layer. The network slice instance layer
(temporarily) owned by tenants. As these tenants have control
is in turn supported by the resource layer, which may consist
over multiple layers, i.e. the physical layer, the virtualization
of physical resources such as compute, network, memory,
layer, and the service layer, of a 5G infrastructure, they are also
storage etc, or it may be more comprehensive as being a
called verticals: That is, they integrate the 5G infrastructure
network infrastructure, or it may be more complex as network
vertically. The availability of this vertical market multiplies the
functions. Fig. 2 depicts this concept where the resources at the
monetization opportunities of the network infrastructure as (i)
resource layers are dimensioned to create several subnetwork
new players, such as automotive industry and e-health, may
instances, and network slice instances are formed that may use
come into play, and (ii) a higher infrastructure capacity utiliza-
none, one or multiple sub-network instances.
tion can be achieved by admitting network slice requests and
exploiting multiplexing gains. With network slicing, different The 5G mobile network system is thus going to be multi-
services, such as, automotive, mobile broadband or haptic tiered and slices need to be deployed and managed at each
Internet, can be provided by different network slice instances. level resulting in not only a complex architecture, but posing
Each of these instances consists of a set of virtual network enormous challenges in terms of 5G network sliced infras-
functions that run on the same infrastructure with a tailored or- tructure and traffic management. In this regard some of the
chestration. In this way, very heterogeneous requirements can principal key are:
be provided on the same infrastructure, as different network 1) Seamless and flexible management of physical and vir-
 tualized resources across the three tiers. way to reduce capital expenditures by using common-of-the-
2) Agile end-to-end service orchestration for each respec- shelf hardware and to apply existing management practices
tive service vertical, where each vertical may have and tools from the cloud computing space in order to automate
multiple service instances. network operation tasks and reduce operational expenditures.
3) Enabling end-to-end connectivity services to each ser- Hope is that NFV and networked systems benefit from automa-
vice instance, which is also programmable. tion and unified ecosystems the same way cloud environments
In consideration of the above challenges, two key technolo- did already. Moreover, NFV systems could embrace the high-
gies are being developed in order to cater scalability, flexibility, availability model of cloud systems. Rather than trying to build
agility, and programming requirements of 5G mobile net- an architecture that can’t fail, which is the dominant approach
works: Network Function Virtualization (NFV) and Software in today’s telco world, NVF aims at creating an architecture
Defined Networking (SDN). The inherent potential and recent that builds failure management into every part of the system
advances in the area of NFV and SDN have made them being and horizontally partitions it to limit single points of failure.
recognized as key technological enablers for the realization of The first generation of NFV system implementations trans-
a carrier cloud, which is a key component of the 5G system. ferred existing monolithic applications to big virtual machine
NFV is being designed and developed specifically in terms appliances, each representing a single Virtual Network Func-
of addressing flexibility, agility and scalability requirements, tion (VNF). Multiple VNFs are then chained together using
and it leverages on the recent advances in cloud computing a Service Function Chain, which determines how packets
and their support for virtualized services. On the other hand, are forwarded from one VNF to another, to constitute a
SDN is being developed in order to make the connectivity Network Service. This already improved flexibility as well as
services provided by 5G networks programmable, where traffic manageability of networks, as operators can use existing cloud
flows can be dynamically steered and managed in order to gain management tools, such as Puppet, Chef, and JuJu. But at the
maximum performance benefits. However, there are numerous same time, it also allowed operators to use existing and well-
challenges for making SDN and NFV deployable and carrier- known paradigms of traditional networks, like high-availability
grade [5]. Consequently, the Open Networking Foundation concepts using redundant systems and hot-standbys.
(ONF) and the ETSI NFV Industry Special Group have been However, it has been reported, e.g. in [6], that the model of
formed to standardize various aspects of SDN and NFV- using fat virtual machines and traditional high-availability and
enabled networks respectively. performance concepts does not translate well to the cloud.
The subsequent sections provide an overview of the main Simple ports of software, which was originally designed to
technological and architectural features of NFV and SDN, run on specialized hardware appliances, are often not able to
and describe how these two technologies can realize a 5G deliver performance and high-availability on standard cloud
core network. A detailed discussion on how NFV and SDN environments. For instance, cloud systems, hypervisors, and
complement each other towards realizing a functional 5G core virtual machines introduce an overhead in input/output op-
network is also provided. erations, which limits the performance of packet processing
significantly. In addition, these legacy solutions often lack
II. NFV AND MANO S YSTEMS mechanisms to scale horizontally, i.e. to add more nodes to (or
Obviously, the complex architecture of upcoming 5G net- remove nodes from) a system in order to meet performance
works calls for an efficient management framework that requirements. Moreover, solutions that strive to avoid failure
provides a uniform and coherent orchestration of various by vertical integration of failure management to an underlying
resources across the multiple layers of the 5G ecosystems. high availability platform, often fail to adapt to the cloud-
Network Function Virtualization and their Management and native high-availability paradigm, where service instances can
Orchestration (MANO) systems offer themselves as elegant be killed and restarted any time. This is because underlying
solutions, aiming at decreasing cost and complexity of im- assumptions and mechanisms are very different [7].
plementing new services, maintaining running services, and Today’s approaches, therefore, move even further and aim
managing available resources in existing infrastructure. Thus, at a more cloud-native software design for network appli-
in the following we provide a detailed introduction to NFV and cations with a much smaller footprint; not running in fat
MANO systems and give an overview of various open-source virtual machines but in slim container solutions. This however,
projects and solutions available today. imposes even more challenges on the NFV management as
the number of NFV entities, which need to be orchestrated,
A. Network Function Virtualization increases significantly. Thus, we elaborate on management and
The rise of powerful general-purpose hardware, cloud com- orchestration systems in the following.
puting technology, and flexible software defined networks, led
to the first idea of virtualizing classical network functions, such B. Management and Orchestration
as routers, firewalls, and evolved packet cores. These network In general, NVF Management and Orchestration systems
functions, which have been executed on dedicated and often aim at a simplified handling of complex network services
specialized hardware before, now run as software applications using NFV technology. To this end, MANO systems have to
in virtual machines on top of cloud infrastructure. Thus, the manage virtualized infrastructure, such as cloud systems, com-
operation of dedicated network middle-boxes transfers into the munication and network infrastructure, like Software Defined
operation of virtual machines and software, which paves the Networks, NFV entities, like Virtualized Network Functions,
 this end, the VNF Manager might be connected to Element
Os-Ma-nfvo
Managers and Virtual Network Functions directly in order to
OSS/BSS NFV Orchestrator (NFVO perform actions, such as starting, scaling, and configuring the
related entities. Again, external reference points allow for con-
Or-Vnfm
nections to legacy systems and facilitate a unified management
NS
Catalogue
VNF
Catalogue
NFV
Instances
NFVI
Resources
and orchestration of NFV systems. Complex life-cycle events,
potentially spanning multiple virtual machines, are automated
and often described by Domain Specific Languages like JuJu,
Ve-Vnfm-em
EM VNF Manager
Puppet, and Ansible, which are executed, e.g., by process
(VNFM) management systems.
VNF
Ve-Vnfm-vnf The Virtualized Infrastructure Manager connects to NFV
Vi-Vnfm
Infrastructures, like OpenStack cloud systems, and manages
Vn-Nf
Virtualised Or-Vi virtual network functions at the level of virtual machines and
Nf-Vi
Infrastructure containers. Moreover, the VIM is responsible for providing
NFVI Manager (VIM)
NFV MANO connectivity between the various VNFs of a network service.
Thus, it sets up the virtual links within the cloud infrastruc-
Execution Reference Points Other Reference Points Main NFV Reference Points
tures, e.g., by using Software Defined Networks.
Fig. 3: The NFV Management and Orchestration (MANO) framework as In addition to the MANO framework as such, ETSI spec-
specified by ETSI [8]. The figure depicts the various components and
reference points. It clearly shows the three layers of NFV orchestration, VNF
ifies various descriptors to provide metadata, such as life-
management, and infrastructure management. cycle and monitoring information, needed to execute virtual
network services and functions. To this end, the Network
Service Descriptor (NSD) provides a high-level description
and the various life-cycles of all these components. Virtualized of a network service, including all the constituent VNFs
Network Functions are often implemented as virtual machine and the life-cycle events of a network service which can be
or container images. In view of the multi-tiered architecture interpreted and executed by the NFV Orchestrator. Likewise,
vision for 5G and the related slice concept discussed earlier, VNF Descriptor (VNFD) describes a virtual network function.
a 5G network is mainly composed of three layers, namely In addition to life-cycle events, the VNF Descriptor also
the resource layer, the network slice instance layer and the includes specific information of the Virtual Deployment Units,
service instance layer. Each of these respective layers needs i.e., virtual machine images or containers, and how they should
to be managed in coordination with other layers. How these be executed. For example, the VNF Descriptor describes
management plane entities manage and orchestrate between minimal CPU requirements that must be met in order to run a
physical or virtual resources at their respective planes, and certain VNF. Finally, the Network Service Descriptor, the VNF
more importantly, how they coordinate with each to deliver Descriptor, and other artifacts, like virtual machine images, can
an effective 5G mobile network service platform is indeed a be combined in a Service Package that acts as a vehicle to ship
challenging proposition and mandates the design and devel- and on-board network services at a MANO service platform.
opment of an effective NFV Management and Orchestration For more details on the ETSI NFV MANO framework we
system that is sensitive to the stringent carrier requirements. refer to its specification [8] and [9]. The related reference
ETSI MANO Framework: The most relevant NFV MANO points are undergoing specifications at the time of writing.
framework today is the reference model specified by ETSI and
depicted in Fig. 3. This framework has three main functional C. MANO Implementations
blocks namely the Virtualized Infrastructure Manager (VIM), Several open-source and commercial projects aim at imple-
the Virtual Network Function Manager (VNFM), and the menting a MANO framework, often based on ETSI specifica-
Network Function Virtualization Orchestrator (NFVO). tions as described above. Most of these projects, however, are
The NFVO manages network services. Thus, it is respon- still in an early stage but already demonstrate the abilities and
sible for the on-boarding process of network service descrip- advantages of a holistic service management and orchestration
tions, which specify network services, and the overall life- for network function virtualization. Below we provide a brief
cycle management of network services as such. It ensures overview of the most relevant projects in the field.
end-to-end service integrity that is formed by multiple VNFs OSM - Open-Source MANO: Open-Source MANO
interconnected by virtual links. Therefor, the NFV Orches- OSM [10] is an ETSI project aiming at a reference implemen-
trator offers reference points to external systems and might tation of the ETSI MANO specification. Thus, it is an operator-
be connected to legacy Operating Support Systems (OSS) driven initiative to meet the requirements for orchestration
and Business Support Systems (BSS). Moreover, the NFV of production NFV networks. OSM is based on three main
Orchestrator is connected to additional data repositories, such software components, namely a VIM connector, Canonical
as the network service catalog, the VNF catalog, the instance JuJu, and Rift.io’s Rift.ware, that reflect the three layers, i.e.,
catalog, and an NFV Infrastructure resource database, which Virtual Infrastructure Management, VNF Management, and
contain relevant information about the respective entities. NFV Orchestration layer, of the ETSI MANO framework. The
The VNF Manager is responsible for the life-cycle of single OSM Virtual Infrastructure Manager connector supports mul-
virtual network functions that constitute a network service. To tiple VIMs and natively uses OpenVIM and VMware Cloud
Directory as Virtual Infrastructure Manager. JuJu Charms are tionality the orchestrator provides a multi-tenant environment
used to incorporate domain knowledge on how to manage the distributed on top of multiple cloud instances.
life-cycle of virtual machines and services. Rift.io’s contribu- SONATA - Agile Service Development and Orchestration
tion to OSM includes the NFV Orchestrator, which performs in 5G Virtualized Networks: The SONATA open-source
end-to-end network service delivery and drives the coherent project [14] builds a service programming and orchestration
service delivery through the resource orchestrating VIM layer framework that provides a development toolchain and a ser-
and VNF configuration components in JuJu. OSM is under vice development kit for virtualized services which is fully
heavy development and Release 2 is expected to be published integrated with a service platform and orchestration system.
in early summer 2017. To this end, the SDK component supports service developers
ONAP - Open Network Automation Platform: The ONAP with both a programming model and a set of software tools.
project [11] evolved from the former Open-O and ECOMP It allows developers to define complex services consisting of
MANO projects that have originally initiated by industry. It multiple VNFs. Moreover, SONATA offers a MANO emulator
is governed by the Linux Foundation. It is the newest player such that a developer can test services in complex scenarios
on stage and aims at building a comprehensive framework on a single computer without the need of a full-fletched
for real-time, policy-driven software automation of virtual Virtual Infrastructure Manager installation, like OpenStack.
network functions. The code is still under heavy development Once tested, a service provider, which can also be the service
at the time of writing and only available to ONAP community developer, can then deploy and manage the created services on
members. one or more SONATA service platforms. Moreover, services
OpenStack Tacker: OpenStack Tacker [12] is under the and their components can be published in a way that they can
big tent of OpenStack projects and aims at building an open be re-used by other developers. Thus, SONATA paves the way
orchestrator with a general purpose VNF Manager to deploy towards an integrated DevOps approach for network services.
and operate virtual network functions on an NFV platform. The SONATA Service Platform, which, unlike many other
It is based on the ETSI MANO architectural framework and MANO systems, is implemented in a modular micro-service
provides a full functional stack to orchestrate VNFs end-to- oriented way, is also based on the ETSI MANO specification.
end. Today, Tacker offers features like a VNF catalog, a basic Due to the micro-service design, however, it is very flexible
VNF life-cycle management, VNF configuration management and a service platform operator can modify the platform, e.g.,
framework, and a VNF health monitoring framework. The to support a desired business model, by replacing components
VNF catalog makes use of the Topology and Orchestration of the loosely coupled MANO framework like plugins. Similar
Specification for Cloud Applications (TOSCA) language for to OSM, the service platform today supports multiple VIMs
VNF meta-data definition and OpenStack Glance to store using a Virtual Infrastructure Abstraction. Natively supported
and manage the VNF images. The Tacker VNF life-cycle is OpenStack. Docker support is currently under development.
management takes care of instantiation and termination of The VNF life-cycle management, i.e. the VNF Manager
virtual machines, self-healing and auto-scaling, and VNF im- in the ETSI MANO framework, is handled either by the
age updates. It also takes care of interfaces to vendor specific generic Life-Cycle Manager or by Function Specific Managers
element management systems. Like the VNF catalog, the basic that ship with any VNF. Likewise, the service life-cycle,
VNF life-cycle management relies on existing OpenStack i.e. NFV Orchestrator functionality, is managed by Service
services and uses OpenStack Heat to start and stop virtual Specific Managers that come with every service. This allows
machines that contain the VNF. Thus, the TOSCA templates to customize management and orchestration of each and every
are automatically translated to OpenStack Heat templates. network service in a very flexible way.
OpenStack Tacker is under heavy development. At the time
of writing, several crucial features, such as service function
D. Management and Orchestration of 5G Slices
chaining and VNF decomposition, are still under discussion.
OpenBaton: OpenBaton [13] is an open source project by When NFV MANO is compared to the idea of slicing in
Fraunhofer FOKUS that provides an implementation of the 5G networks as depicted in Fig. 4, the VIM corresponds to
ETSI Management and Orchestration specification. Its main the Infrastructure Manager, the VNFM corresponds to the
components are a Network Function Virtualization Orchestra- Network Slice Manager while the NFVO corresponds to the
tor, a generic Virtual Network Function Manager that manages Service Instance Layer. It can thus be inferred that the ETSI
VNF life-cycles based on he VNF description, and an SDK NFV MANO system has the required building blocks for
comprising a set of libraries that could be used for building a providing a MANO framework for the 5G network slices.
specific VNF Manager. Network Slice MANO: A MANO system is supposed
The NFV Orchestrator, which is the main component of to orchestrate multiple complex management tasks in order
OpenBaton, is written in Java using the spring.io framework. to ensure the provisioning of network slice service. Thus,
To interconnect the NFV Orchestrator to different VNF Man- a MANO framework for 5G virtualized networks infras-
agers, OpenBaton relies on the Java Messaging System. The tructure is designed to go beyond providing the traditional
NFV Orchestrator is currently using OpenStack as integrated Fault, Configuration, Accounting, Performance, and Security
Virtual Infrastructure Manager, supporting dynamic registra- (FCAPS) management into providing additional management
tion of NFV points of presence and deploys in parallel multiple tasks. Some of the additional management functions, besides
slices consisting of one or multiple VNFs. Through this func- FCAPS are listed below:
 Service Instance Layer decoupling the release cycles of agile software from the
Service
Service Service Service Service Manager comparatively slow release cycles of integrated software and
Instance 1 Instance 4
Instance 2 Instance 3
hardware. The radical change towards making networks pro-
Network Slice Instance Layer grammable and enabling applications and network services to
Network Slice-1 directly control the abstracted infrastructure, sparked a major
Network Slice-2
Network Slice
Network
Network
Slice
Manager
Slice
development direction in research and education networks and
Manager
Network Slice-3
Manager commercial networks, affecting especially established network
equipment vendors among the market players.
SDN has gained a lot of traction over the past years. The
ability to manage network services through abstractions of
Virtualization Layer
lower level functionalities opens up a wide range of new
Infrastructure
Manager
architecture, management and operation options, including
new forms of interaction between end-users applications and
NFV Infrastructure Network Slice networks. Deploying agile software on white-box switches
MANO
Network Function (e.g., VNF) Shared Network Function Compute/Storage
is expected to improve the cost-performance behavior of the
Virtual Links Physical Links Reference Point Infrastructure Network network. Another great value of SDN will be the ability for
Fig. 4: Network Slice Management and Orchestration (MANO) Overview.
rapid delivery of user services while using network resources
more efficiently.
A. OpenFlow and ONF
1) Software image management
An important protocol in the space of SDN is OpenFlow,
2) Service reliability management
which enables the communication between network infras-
3) Policy management
tructure elements and the network controlling, software-based
4) Bandwidth and Latency management
entities. OpenFlow is maintained by the Open Networking
5) QoS/QoE management
Foundation (ONF) and today supported by all major network
6) Mobility management
equipment vendors.
7) Energy management
From ONF’s point of view, SDN has started as a vehi-
8) Charging and billing management
cle to flexibly update packet forwarding algorithms. Since
9) Network slice update/upgrade
then, its applicability extended to the wider communications
10) VNF lifecycle management, including VNF scaling and
network domains covering all kinds of applications across
migration
the enterprise, carrier, data-center and campus network areas.
11) Virtualized infrastructure management i.e., management
Expanding from the initial three-layer architecture picture,
of resource capacity, performance, fault, isolation etc.
consisting of Infrastructure, Control and Application Layers,
As mentioned earlier, the basic building block of a network the ONF published a detailed SDN Architecture [16], [17] that
slice at the virtualization layer is the VNF. The MANO entity will very briefly be introduced in the following. It is based on
performs the lifecycle management of a network slice by the following three principles:
managing the individual VNFs that are part of the network
• Decoupling of control from traffic forwarding and pro-
slice.
cessing. This is to enable independent deployment, life
III. S OFTWARE D EFINED N ETWORKING cycles and evolution of control and traffic forwarding and
Evidently, introducing NFV and MANO systems into 5G processing entities.
networks also fosters very dynamic mechanisms of data traffic • Logically centralized control. Logically centralized
engineering and steering. For instance, new connections have means that control appears from the outside, application
to be set up fast and agile, e.g. to connect VNFs within and perspective as a single entity, but it is not implied to be
across data centers and establish end-to-end service. Likewise, deployed in a centralized monolithic implementation.
network equipment has to be updated and (re-) configured con- • Programmability of network services. Interfaces between
tinuously to support the NFV infrastructure and architecture. SDN components expose resource abstractions and state.
This, however, is very hard to do using traditional approaches Applications are enabled to act on these abstractions and
for network operations where changes are often done (semi) states programmatically using a well defined API.
manual at relatively long timescales, like minutes, hours, even We believe that open interfaces and related protocols, like
days. To this end, Software Defined Networking comes into OpenFlow, are key for these systems that are built of decou-
play to overcome the limitations of traditional networks and pled functional components to enable the system operators
traditional network operations. to deploy components from any combination of a multitude
Software Defined Networking is a network paradigm that of sources like commercial vendors and open-source groups.
evolved from work done at UC Berkeley and Stanford [15]. Open, well-defined interfaces may encourage competition be-
The motivation was to break up ossified networks by replacing tween providers of community-agreed (standardized) function-
rigid hardware-based proprietary equipment and services with ality. However, proprietary features and interfaces should be
deeply programmable common software-driven services and expected to persist, especially in non-mainstream areas or for
methods that span across multiple vendor-platforms; thereby specialized ad-hoc extensions.
 As shown in Fig. 5, SDN controllers are at the center of
the SDN architecture as envisioned by the ONF. They are
responsible for the provisioning, management and control of
services and related resources. To this end, the controller
offers so-called northbound interfaces to applications and
southbound interfaces to the resources. Using these interfaces,
users and applications have the ability to directly interact with
the network. Leveraging the SDN controllers northbound inter-
face, authorized applications establish so-called management-
control sessions in order to invoke services or to change the
state of a resources at the southbound interface. In addition,
the administrator role is responsible to create and maintain the
environment needed to provide services to clients. It has the
authority to configure the SDN controller, as well as to create
and manage client and server contexts. To this end, configuring
an SDN controller includes the creation of the controller itself,
the installation and modification controller-internal policies, Fig. 5: The ONF SDN architecture, adapted from [17]. It shows the SDN
and the installation and configuration of actual resources and controller in the center of the architecture. It mediates between control appli-
control applications. cations at northbound interfaces and resources connected to the southbound
interfaces.
Service consumption, i.e. data transfer and data processing,
takes place through the corresponding network resources.
Ultimately, user traffic is conveyed by physical resources,
which may be any number of levels of abstraction below of programmable hardware. Bare-metal or white-box switches
the resources visible to the client or to any particular SDN that do not ship with proprietary but allow various operating
controller. Thus, leveraging the SDN controller’s ability to systems have arrived in the mass market. The market for
abstract complex network resources and to mediate between operating systems to install on these switches is evolving
resources and control applications, also paves the way to rapidly and there is already a wide range of options available.
virtualized network resources. As the controller manages the SDN Software: Similar to SDN hardware, a diversity of
information flow from the resources to the applications, it can SDN controllers has been developed meanwhile, too, and are
restrict the view and only provides a subset of resources or available either on commercial basis or as open-source. Two
features to its upper layers. Thus, control applications can very prominent examples are the OpenDaylight controller and
access network functionality and for example steer network the ONOS controller, both governed by the Linux Foundation.
traffic easily by using a standardized interface which simplifies
dynamic network management a lot. C. Future directions in SDN research
For a more detailed view on SDN we refer to [18] and The initial ideas that lead to the inception of SDN and
references therein. Moreover, the authors in [19] provide a OpenFlow came from the researchers desire to be able to
detailed description of the ONF SDN architecture and its innovate more freely and to be able to experiment with new
relationships to other standardization efforts. A comprehensive Internet architectures. To some degree this goal is achieved
survey of SDN can be found in [20]. by today’s incarnations of SDN. We are now able to program
the forwarding of packets in the network. For example this
B. SDN implementation allows to explore and realize advanced and reactive traffic
SDN system developments are buzzing with new commer- engineering approaches, it provides deep visibility into the
cial and non-commercial network hardware, like switches and current utilization of the network, or enable creative re-use
routers, and software, like SDN controllers. In the following of header fields in well known data plane protocols.
we provide some examples out of the growing number of However contemporary implementations of SDN are fo-
available options. cused on providing support for existing data-plane protocols
SDN Hardware: At the advent of SDN dedicated silicon and legacy approaches of operating networks. In particular,
was not available. SDN switches were (and still are) imple- the match part of forwarding rules allows to specify subsets
mented using either firmware that was translating SDN control of network traffic based on well known header fields that are
protocol abstractions into the switching chips tables or by in use in today’s networks. Likewise the action part allows to
leveraging already programmable hardware such as Network prescribe typical actions, such as output on port X, or drop.
Processing Units and FPGAs. At the time of writing first Limitations still exist when users want to define their own,
chips that natively support a programmable forwarding plane new, data plane protocols, on which they want to match.
are available. Today, switches and other network equipment Thus, enabling flexible matching on arbitrary header fields has
often support forwarding plane programmability by protocols been a recent topic of SDN research and standardization. Key
like OpenFlow [21]. Moreover, Ternary Content Addressable works in this context are Protocol Independent Forwarding
Memory (TCAM) in switches, which was often a bottleneck, (PIF/P4) [22], Protocol Oblivious Forwarding (POF) [23] or
is growing as well. This improves the practical applicability Deeply Programmable Networks (DPN) [24].
 Cloud/DC/IT view Joint view Telco operator view are responsible for offering a unified central point for admins
Orchestration Service Controller Orchestration
and customers to provision and monitor their services which
OSS/BSS Orchestration OSS/BSS mainly consist of providing connectivity typically with service
OSS/BSS
level agreements. In these NFV times, several of the more
VMM NC complex network elements, which were previously managed
VMM NC
NC VMM by the network controller are now deployed as virtual ma-
chines. Thus the network controller will instruct the virtual
machine management to instantiate a VNF.
To summarize, in both cases the network controller or the
Fig. 6: Different views of chains of command in the Cloud/DC/IT world (left) virtual machine manager are just seen to provide a service
and the telecommunication world (right). A joint view is shown in the middle,
offering a way forward. (VMM: virtual machine management, NC: network
to the other. In order to bring these two worlds together
controller) we need to put them on the same level and integrate them
further. This is shown in the middle and already implemented
in SONATA. The virtual machine manager and the network
Extensions on the matching capabilities of SDN are espe- controller will become components of a single infrastructure
cially interesting for new network architectures such as In- resource controller. This is already supported by the ONF SDN
formation Centric Networking (ICN), Locator Identifier Split, architecture [28], when assuming that the infrastructure can
and other approaches that define their own stacks of network include compute and storage resources beyond the typically
protocols. Yet more recently, work on extending the action discussed network resources.
part of forwarding rules has caught the interest of the re- In order to fully utilize such a combined service controller,
search community. The EU funded BeBa research project [25] we need to start developing holistic service descriptions for In-
introduced two concepts that extend the programmability of ternet applications, that include all its components, supported
actions. In a first contribution stateful flow processing has been deployment topology, hints on how to scale, requirements on
added to SDN. Up to version 1.5, OpenFlow does not allow to network path properties, desired network functions, as well
store state from the processing of one packet of a flow (read as easy to program interfaces that abstract away unnecessary
match traffic identifier) to the next. OpenState [26] is adding complexity from the developer.
this possibility. In a second contribution, in-switch packet As described in the previous section, ONF takes a much
generation [27] adds the capability to programatically generate broader view of network systems, and thus the broad definition
packets inside the switch, reacting to triggering packets or of SDN that has developed over time within the ONF can be
other in-switch events. translated into many different ways in terms of specifications
These extension and future directions are particularly bene- and implementations. ETSI NFV, on the other hand, provides a
ficial in the light of increased deployment of NFV. They allow very precise architectural framework for a very clear purpose,
to partially implement VNF functionality directly within the and that is to manage and orchestrate NFV Infrastructure
network elements, thereby reducing the need for deploying resources, typically located in data centers, that are utilized
virtual machines. and consumed by telco related functions and services. In this
context ETSI NFV specifies features and functions it requires
IV. T HE MARRIAGE OF SDN AND NFV from SDN. They then look into various possibilities of posi-
Bringing together SDN and NFV also means to bring tioning SDN in the larger scope of NFV. From this perspective,
together the views of so far distinct communities. On the one the ETSI NFV system as per today’s requirements uses the
hand there is the cloud, data center and IT view that have services of SDN to provide a programmable platform for
long standing experience with deploying and managing virtual establishing links between VNFs and VNF components, and to
machines. And on the other hand there is telecom operator support enhanced functions such as policy based management
and vendor view, with a long lasting history of providing of traffic between VNFs, or dynamic bandwidth management.
communication services. The problem that arises from these Thus the NFV system realizes a fully programmable end-to-
different views is illustrated in Fig. 6. end network services within the NFV domain.
On the left side we show the typical chain of command in When integrating the SDN functional components within
a typical data center deployment. The users and admins of the the NFV infrastructure, it must take into consideration the
data center will use an orchestration interface to upload virtual SDN interfaces relevant for its requirements. Figure 7 gives
machine images and request the instantiation of their service. a high level overview depicting ETSI NFV perspective on
In a first step the virtual machine management system, which interfacing with the SDN domain [29]. As shown, ETSI NFV
is part of the Virtual Infrastructure Manager, will identify is in the process of specifying the orchestration interface(s) for
suitable servers and spin up the virtual machines according interfacing the SDN controller with the NFV MANO system.
to the request. Then it will instruct a network controller These specifications take the interfaces internal to the SDN
component to provide connectivity between the instantiated domain into account. That is, the Application Control Inter-
virtual machines. face that provides to the VNFs an application programmatic
Contrary on the right side we show the typical telco view. control of abstracted network resources [29], and the Resource
Telcos main piece of infrastructure is the network which is Control Interface for controlling the NFV Infrastructure net-
controlled by the NC. Operation and business support systems work resources (e.g, physical/virtual routers and switches, and
 reference platform for NFV. In other words, it is an ongoing
project attempting the marriage between NFV and SDN. There
are also some prominent research projects like 5G NORMA
SDN Application(s)
(e.g., PCRF, EM etc) [31] that leverages on the SDN and NFV concepts in order
to develop a novel mobile network architecture that shall
Application Control provide the necessary adaptability in a resource efficient way
Interface (ACI)
Orchestration able to handle fluctuations in traffic demand resulting from
Interface
NFV Orchestrator
heterogeneous and dynamically changing service portfolios
SDN Controller
(Management and to changing local context. From the NFV perspective
Functions) 5G NORMA extends the NFV MANO framework to support
Resource Control
Interface (RCI) multi-tenancy and manage service slices that may be extended
over multiple sites. From the SDN perspective, it defines two
SDN Resources SDN-based controllers, one for the management of network
(Nework Resources e.g.,
virtual/physical switch or router, e- functions local to a mobile network service slice, and the
switch, SDN switch ion NIC etc.) second for the management of network functions that are
NFV Domain SDN Domain common/shared between mobile network service slices [32].
These controllers leverages on the concept of SDN controller
and translate decisions of the control applications into com-
Fig. 7: ETSI NFV perspective of interacing with the SDN domain [29]
mands to VNFs. 5G NORMA recommends these special SDN
controllers to be deployed as VNFs.
Thus, Figure 8 gives different options of integrating the
networks connecting VNFs). SDN system (application, resources and controller) in the
context of NFV and [29] provides an overview of each option
NFV MANO
Os-Ma-nfvo and its combination. The key point is that NFV aims at
NFV Orchestrator
OSS/BSS
(NFVO)
leveraging the programability feature of SDN in order to
implement network services that may be designed according
Or-Vnfm to some pre-configured VNF Forwarding Graph, or implement
EM 1 EM 2 EM 3 Ve-Vnfm
NS that may require the chaining of VNFs based on some
VNF Manager
(VNFM)
policy/service or even based on VNF processing, for example,
VNF 1 VNF 2 VNF 3 a security related VNF may want to change the path of traffic
on the fly depending on its processing output.
Vn-Nf Vi-Vnfm

NFVI
NFV MANO
Virtual Virtual Virtual
Computing Storage Network Nf-Vi Virtualised
PNF Infrastructure Or-Vnfm
Virtualization layer
Manager (VIM) Or-Vi VNF Manager NFV Orchestrator
(VNFM) (NFVO) Vi-Vnfm
Computing Storage Network
Hardware Hardware Hardware Or-Vi
Vi-Vnfm Or-Vi Or-Vi

SDN Resources SDN Applications SDN Controller Virtualised WAN Virtualised

Infrastructure Infrastructure Infrastructure
Manager (VIM) Manager (WIM) Manager (VIM)
Fig. 8: Possible options of positioning SDN Resources, SDN Controller and
SDN Applications in NFV Architectural Framework Nf-Vi Nf-Vi Nf-Vi

Network Network Network

In this context, ETSI NFV has published a detailed report Controller (NC) Controller (NC) Controller (NC)
[29] describing the various possible options of SDN feder-
NFVI PoP 1 NFVI PoP 2
ation in NFV. Figure 8 summarizes these possible options PNF
WAN
of integrating SDN application, SDN resources and SDN Endpoint
2
VNF1
controller with different entities within the NFV MANO and
PNF
NFV architecture. Each one has its own requirements on the Endpoint 1
VNF2

NFV MANO interfaces. For example, there are five integration VNF Forwarding Graph

options for SDN controller to either (i) be part of OSS/BSS, Fig. 9: NFV SDN in a multi-site scenario
(ii) exist as an entity within the NFV Infrastructure, (iii) exist
as a Physical Network Function, (iv) be instantiated as a VNF, ETSI MANO in [8] provides clear insight as to how it can
or (v) be integrated within the Virtual Infrastructure Manager. utilize the features of SDN for its respective purposes. Figure 9
The latter approach is supported by the ONF SDN architecture gives a useful overview with reference to a multi-site scenario
[28] and is also adopted by open source OPNFV platform [30], where two network services involving two virtual (i.e., VNF1
where SDN controllers like ODL and ONOS are integrated and VNF2) and two physical network functions (i.e., PNF1
with OpenStack, the latter being widely accepted as a suitable and PNF2) are extended over two NFV Infrastructure Points-
virtual machine management platform. The goal of OPNFV of-Presence (PoP). Each NFVI-PoP has its own VIM while
project is to provide a carrier grade integrated open source a WAN Infrastructure Manager (WIM) is also required for
requesting connectivity services between the two NFVI-PoPs • How to manage/handle the agility of software, especially
over the WAN. Multiple connectivity services are requested in view of the trend/need of the decomposition of network
by the NFV Orchestrator over the Or-Vi interface from the function into micro-functions.
respective VIMs/WIMs for establishing connectivity within • How to distribute network functions onto different ex-
their respective domains. Each VIM/WIM can request for the ecution platforms, when highly programmable hardware
provisioning of virtual networks from the Network Controller (switches, smartNICs) becomes more ubiquitous.
(NC) over a fully open and programmable Nf-Vi interface. • How to ensure interoperability between different vendors,
The NC, which for all practical purposes can be an SDN especially in this cloud-native environment of massively
controller and will be referred to as such. This SDN controller decomposed network functions.
has visibility into the devices (i.e, SDN resources) that they • What is the best way of translating and mapping the
control directly and thus is able to provide an abstracted customers/clients/tenants business requirements over the
view of them to the VIM/WIM via the Nf-Vi northbound service providers’ infrastructure.
interface. It should be noted that the SDN applications can • How to ensure that the QoS and QoE requirements and
also reside inside VIM (see Figure 8). The SDN controller SLAs can be fulfilled in the cloud-native environment.
then establishes the connectivity services by configuring the • How to efficiently assign and manage resources for the
forwarding tables of the underlying VNFs/PNFs. Although multitude of slices that may exist within the same admin-
shown as a separate functional entity, the SDN controller can istrative domain, or traverse over different administrative
also be part of VIM/WIM as discussed above (see Figure domains.
8). At the time of writing this paper, the Infrastructure and • How, and to what extent can the network/system man-
Architecture (IFA) working group of the ETSI ISG for NFV agement be automated in order to reduce the need for
is specifying use cases for multi-site connectivity in order to manual tasks and intervention.
draw more concrete requirements for the Northbound interface
(i.e., Nf-Vi) of the SDN controller in order to achieve a happy ACKNOWLEDGMENT
successful marriage between NFV and SDN. This research work has been performed in the framework of H2020-
ICT-2014-2 project 5G NORMA and SONATA projects. The authors
V. C ONCLUSION would like to acknowledge the contributions of their colleagues of the
5G NORMA and SONATA partner consortium, although the views
expressed are those of the authors and do not necessarily represent
Communication networks are currently undergoing a major the project.
evolutionary change in order to be capable to flexibly serve
the needs and requirements of massive numbers of connected R EFERENCES
users and devices and to enable the functioning of the new
[1] “Network Evolution toward 2020 and Beyond,” http://www.nec.com
set of envisioned applications and services in an agile and /en/global/solutions/nsp/5g vision/doc/2020 network.pdf, 2015.
programmable way. Key terms in that context are Internet-of- [2] NGMN Alliance, Description of Network Slicing Concept, Public De-
things, virtualization, softwarization and cloud-native. liverable, 2016.
[3] 3GPP, Study on Architecture for Next Generation System, TR 23.799,
In order to be able to maintain and run these networks 2016.
over 5G slices, NFV and SDN technologies are widely con- [4] NGMN Alliance, 5G White Paper, Public Deliverable, 2015.
sidered as the key enablers in network architecture, design, [5] T. Taleb, “Toward Carrier Cloud: Potential, Challenges, & Solutions,”
Wireless Communications, IEEE, vol. 21, no. 3, pp. 90–91, 2014.
operation and management. Several organizations (ETSI NFV, [6] M. Taylor, “The Myth of the Carrier-Grade Cloud,”
ONF, ETSI MEC, NGMN, 3GPP, IEEE, BBF, MEF etc.) http://www.metaswitch.com/the-switch/the-myth-of-the-carrier-grade-
are working on standardizing the architecture frameworks and cloud, 2015.
interfaces required for combining the multitude of components [7] I. Nadareishvili, R. Mitra, M. McLarty, and M. Amundsen, Microservice
Architecture - Aligning Principles, Practices, and Culture, 1st ed.
into a functional system that can be implemented within Sebastopol, CA, USA: OReilly, 2016.
the provider/operator systems based on a variety of business [8] ETSI NFV ISG, “GS NFV-MAN 001 V1.1.1 Network Function Virtu-
models and use cases. alisation (NFV); Management and Orchestration,” Dec. 2014.
[9] ——, “GS NFV 002 V1.2.1 Network Function Virtualisation (NFV);
In parallel to standardization activities, several compo- Architectural Framework,” Dec. 2014.
nents are being developed under the umbrella of open-source [10] “OSM: Open-Source MANO,” https://osm.etsi.org/, 2016.
projects (OpenStack, OPNFV, OSM, ONAP, ODL, ONOS, [11] “ONAP: Open Network Automation Platform,” https://www.onap.org/,
2016.
etc.) that are expected to complement, if not replace, commer- [12] “OpenStack Tacker,” https://wiki.openstack.org/wiki/Tacker, 2015.
cial vendors’ products. Moreover, these open-source projects [13] “OpenBaton,” https://openbaton.github.io/, 2015.
and relevant standardization bodies are also mutually influ- [14] “SONATA,” http://sonata-nfv.eu, 2015.
[15] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,
encing each other towards the development of their respective J. Rexford, S. Shenker, and J. Turner, “Openflow: Enabling Innovation
goals, and validating and progressing their respective work. in Campus Networks,” in SIGCOMM Comput. Commun. Rev., 2008.
Although the community/industry is on its way and pro- [16] ONF, “SDN Architecture 1.0, howpublished =
https://www.opennetworking.org/ima\discretionary{-} {}{}ges/stories/downloads/sdn-r
gressing well to realize a large part of the 5G vision by 2020, 2014.
a number of research challenges and issues are still open that [17] ——, “SDN architecture, issue 1.1, ONF TR-521,”
needs to be addressed in order to ensure a healthy conception https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-repo
Feb. 2016.
of the envisaged 5G systems. Some of those questions/issues [18] “Software-Defined Networking: The New Norm for Networks,” Apr.
are: 2012, ONF White Paper.
[19] S. Schaller and D. Hood, “Software defined networking architecture
standardization,” Elsevier Journal on Computer Standards & Interfaces,
2017.
[20] D. Kreutz, F. M. V. Ramos, P. E. Verssimo, C. E. Rothenberg, S. Azodol-
molky, and S. Uhlig, “Software-defined networking: A comprehensive
survey,” Proceedings of the IEEE, vol. 103, no. 1, pp. 14–76, Jan 2015.
[21] ONF, “Openflow switch specification, version 1.5.1, ONF TS-025,”
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.5.1.pdf,
Apr. 2015.
[22] P. Bosshart, D. Daly, G. Gibb, M. Izzard, N. McKeown, J. Rexford,
C. Schlesinger, D. Talayco, A. Vahdat, G. Varghese, and D. Walker,
“P4: Programming protocol-independent packet processors,” SIGCOMM
Comput. Commun. Rev., vol. 44, no. 3, pp. 87–95, Jul. 2014. [Online].
Available: http://doi.acm.org/10.1145/2656877.2656890
[23] H. Song, “Protocol-oblivious forwarding: Unleash the power of
sdn through a future-proof forwarding plane,” in Proceedings
of the Second ACM SIGCOMM Workshop on Hot Topics in
Software Defined Networking, ser. HotSDN ’13. New York,
NY, USA: ACM, 2013, pp. 127–132. [Online]. Available:
http://doi.acm.org/10.1145/2491185.2491190
[24] S. Nirasawa, M. Hara, A. Nakao, M. Oguchi, S. Yamamoto,
and S. Yamaguchi, “Network application performance improvement
with deeply programmable switch,” in Adjunct Proceedings of the
13th International Conference on Mobile and Ubiquitous Systems:
Computing Networking and Services, ser. MOBIQUITOUS 2016.
New York, NY, USA: ACM, 2016, pp. 263–267. [Online]. Available:
http://doi.acm.org/10.1145/3004010.3004030
[25] “BeBa - Behavioral Based Forwarding,” http://www.beba-project.eu,
2015.
[26] G. Bianchi, M. Bonola, A. Capone, and C. Cascone,
“Openstate: Programming platform-independent stateful openflow
applications inside the switch,” SIGCOMM Comput. Commun.
Rev., vol. 44, no. 2, pp. 44–51, Apr. 2014. [Online]. Available:
http://doi.acm.org/10.1145/2602204.2602211
[27] R. Bifulco, J. Boite, M. Bouet, and F. Schneider, “Improving sdn with
inspired switches,” in Proceedings of the Symposium on SDN Research,
ser. SOSR ’16. New York, NY, USA: ACM, 2016, pp. 11:1–11:12.
[Online]. Available: http://doi.acm.org/10.1145/2890955.2890962
[28] ONF, “Relationship of SDN and NFV, issue 1, ONF TR-518,”
https://www.opennetworking.org/ima-ges/stories/downloads/sdn-
resources/technical-reports/onf2015.310 Architectural comparison.08-
2.pdf, Oct. 2015.
[29] ETSI NFV ISG, “GS NFV-EVE 005 V1.1.1 Network Function Virtual-
isation (NFV); Ecosystem; Report on SDN Usage in NFV Architectural
Framework,” Dec. 2015.
[30] “OPNFV,” https://www.opnfv.org, 2016.
[31] “5G NORMA,” https://5gnorma.5g-ppp.eu/, 2015.
[32] 5G NORMA Project, Deliverable D3.2: 5G NORMA network architec-
ture - Intermediate Report, Public Deliverable, 2017.