NFVRG CJ. Bernardos
Internet-Draft UC3M
Intended status: Informational A. Rahman
Expires: May 4, 2017 InterDigital
JC. Zuniga
SIGFOX
LM. Contreras
P. Aranda
TID
October 31, 2016
Network Virtualization Research Challenges
draft-irtf-nfvrg-gaps-network-virtualization-03
Abstract
This document describes open research challenges for network
virtualization. Network virtualization is following a similar path
as previously taken by cloud computing. Specifically, Cloud
computing popularized migration of computing functions (e.g.,
applications) and storage from local, dedicated, physical resources
to remote virtual functions accessible through the Internet. In a
similar manner, network virtualization is encouraging migration of
networking functions from dedicated physical hardware nodes to a
virtualized pool of resources. However, network virtualization can
be considered to be a more complex problem than cloud computing as it
not only involves virtualization of computing and storage functions
but also involves abstraction of the network itself. This document
describes current research challenges in network virtualization
including guaranteeing quality-of-service, performance improvement,
supporting multiple domains, network slicing, service composition,
device virtualization, privacy and security. In addition, some
proposals are made for new activities in IETF/IRTF that could address
some of these challenges.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
Bernardos, et al. Expires May 4, 2017 [Page 1]
Internet-Draft Network Virtualization Research Challenges October 2016
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Network Function Virtualization . . . . . . . . . . . . . 5
3.2. Software Defined Networking . . . . . . . . . . . . . . . 8
3.3. Mobile Edge Computing . . . . . . . . . . . . . . . . . . 11
3.4. IEEE 802.1CF (OmniRAN) . . . . . . . . . . . . . . . . . 12
3.5. Distributed Management Task Force . . . . . . . . . . . . 12
3.6. Open Source initiatives . . . . . . . . . . . . . . . . . 12
3.7. Internet of Things (IoT) . . . . . . . . . . . . . . . . 14
4. Network Virtualization Challenges . . . . . . . . . . . . . . 14
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Guaranteeing quality-of-service . . . . . . . . . . . . . 15
4.2.1. Virtualization Technologies . . . . . . . . . . . . . 15
4.2.2. Metrics for NFV characterization . . . . . . . . . . 15
4.2.3. Predictive analysis . . . . . . . . . . . . . . . . . 16
4.2.4. Portability . . . . . . . . . . . . . . . . . . . . . 16
4.3. Performance improvement . . . . . . . . . . . . . . . . . 16
4.3.1. Energy Efficiency . . . . . . . . . . . . . . . . . . 16
4.3.2. Improved link usage . . . . . . . . . . . . . . . . . 16
4.4. Multiple Domains . . . . . . . . . . . . . . . . . . . . 17
4.5. Network Slicing . . . . . . . . . . . . . . . . . . . . . 17
4.6. Service Composition . . . . . . . . . . . . . . . . . . . 18
4.7. End-user device virtualization . . . . . . . . . . . . . 19
4.8. Security and Privacy . . . . . . . . . . . . . . . . . . 19
4.9. Separation of control concerns . . . . . . . . . . . . . 21
Bernardos, et al. Expires May 4, 2017 [Page 2]
Internet-Draft Network Virtualization Research Challenges October 2016
5. Technology Gaps and Potential IETF Efforts . . . . . . . . . 21
6. Mapping to NFVRG Near-Term work items . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
10. Informative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
The telecommunications sector is experiencing a major revolution that
will shape the way networks and services are designed and deployed
for the next decade. We are witnessing an explosion in the number of
applications and services demanded by users, which are now really
capable of accessing them on the move. In order to cope with such a
demand, some network operators are looking at the cloud computing
paradigm, which enables a potential reduction of the overall costs by
outsourcing communication services from specific hardware in the
operator's core to server farms scattered in datacenters. These
services have different characteristics if compared with conventional
IT services that have to be taken into account in this cloudification
process. Also the transport network is affected in that it is
evolving to a more sophisticated form of IP architecture with trends
like separation of control and data plane traffic, and more fine-
grained forwarding of packets (beyond looking at the destination IP
address) in the network to fulfill new business and service goals.
Virtualization of functions also provides operators with tools to
deploy new services much faster, as compared to the traditional use
of monolithic and tightly integrated dedicated machinery. As a
natural next step, mobile network operators need to re-think how to
evolve their existing network infrastructures and how to deploy new
ones to address the challenges posed by the increasing customers'
demands, as well as by the huge competition among operators. All
these changes are triggering the need for a modification in the way
operators and infrastructure providers operate their networks, as
they need to significantly reduce the costs incurred in deploying a
new service and operating it. Some of the mechanisms that are being
considered and already adopted by operators include: sharing of
network infrastructure to reduce costs, virtualization of core
servers running in data centers as a way of supporting their load-
aware elastic dimensioning, and dynamic energy policies to reduce the
monthly electricity bill. However, this has proved to be tough to
put in practice, and not enough. Indeed, it is not easy to deploy
new mechanisms in a running operational network due to the high
dependency on proprietary (and sometime obscure) protocols and
interfaces, which are complex to manage and often require configuring
multiple devices in a decentralized way.
Bernardos, et al. Expires May 4, 2017 [Page 3]
Internet-Draft Network Virtualization Research Challenges October 2016
Network Function Virtualization (NFV) and Software Defined Networking
(SDN) are changing the way the telecommunications sector will deploy,
extend and operate their networks. This document describes current
research challenges in network virtualization and correlates them to
activities currently occurring in the key standards forums and open
source efforts. Based on this analysis, we also go a step farther,
identifying which are the potential work areas where IETF/IRTF can
work on to complement the complex network virtualization map of
technologies being standardized today.
2. Terminology
The following terms used in this document are defined by the ETSI NVF
ISG, the ONF and the IETF:
Application Plane - The collection of applications and services
that program network behavior.
Control Plane (CP) - The collection of functions responsible for
controlling one or more network devices. CP instructs network
devices with respect to how to process and forward packets. The
control plane interacts primarily with the forwarding plane and,
to a lesser extent, with the operational plane.
Forwarding Plane (FP) - The collection of resources across all
network devices responsible for forwarding traffic.
Management Plane (MP) - The collection of functions responsible
for monitoring, configuring, and maintaining one or more network
devices or parts of network devices. The management plane is
mostly related to the operational plane (it is related less to the
forwarding plane).
NFV Infrastructure (NFVI): totality of all hardware and software
components which build up the environment in which VNFs are
deployed
NFV Management and Orchestration (NFV-MANO): functions
collectively provided by NFVO, VNFM, and VIM.
NFV Orchestrator (NFVO): functional block that manages the Network
Service (NS) lifecycle and coordinates the management of NS
lifecycle, VNF lifecycle (supported by the VNFM) and NFVI
resources (supported by the VIM) to ensure an optimized allocation
of the necessary resources and connectivity.
OpenFlow protocol (OFP): allowing vendor independent programming
of control functions in network nodes.
Bernardos, et al. Expires May 4, 2017 [Page 4]
Internet-Draft Network Virtualization Research Challenges October 2016
Operational Plane (OP) - The collection of resources responsible
for managing the overall operation of individual network devices.
Physical Network Function (PNF): Physical implementation of a
Network Function in a monolithic realization.
Service Function Chain (SFC): for a given service, the abstracted
view of the required service functions and the order in which they
are to be applied. This is somehow equivalent to the Network
Function Forwarding Graph (NF-FG) at ETSI.
Service Function Path (SFP): the selection of specific service
function instances on specific network nodes to form a service
graph through which an SFC is instantiated.
virtual EPC (vEPC): control plane of 3GPPs EPC operated on NFV
framework (as defined by [I-D.matsushima-stateless-uplane-vepc]).
Virtualized Infrastructure Manager (VIM): functional block that is
responsible for controlling and managing the NFVI compute, storage
and network resources, usually within one operator's
Infrastructure Domain.
Virtualized Network Function (VNF): implementation of a Network
Function that can be deployed on a Network Function Virtualization
Infrastructure (NFVI).
Virtualized Network Function Manager (VNFM): functional block that
is responsible for the lifecycle management of VNF.
3. Background
3.1. Network Function Virtualization
The ETSI ISG NFV is a working group which, since 2012, aims to evolve
quasi-standard IT virtualization technology to consolidate many
network equipment types into industry standard high volume servers,
switches, and storage. It enables implementing network functions in
software that can run on a range of industry standard server hardware
and can be moved to, or loaded in, various locations in the network
as required, without the need to install new equipment. To date,
ETSI NFV is by far the most accepted NFV reference framework and
architectural footprint [etsi_nvf_whitepaper]. The ETSI NFV
framework architecture framework is composed of three domains
(Figure 1):
o Virtualized Network Function, running over the NFVI.
Bernardos, et al. Expires May 4, 2017 [Page 5]
Internet-Draft Network Virtualization Research Challenges October 2016
o NFV Infrastructure (NFVI), including the diversity of physical
resources and how these can be virtualized. NFVI supports the
execution of the VNFs.
o NFV Management and Orchestration, which covers the orchestration
and life-cycle management of physical and/or software resources
that support the infrastructure virtualization, and the life-cycle
management of VNFs. NFV Management and Orchestration focuses on
all virtualization specific management tasks necessary in the NFV
framework.
+-------------------------------------------+ +---------------+
| Virtualized Network Functions (VNFs) | | |
| ------- ------- ------- ------- | | |
| | | | | | | | | | | |
| | VNF | | VNF | | VNF | | VNF | | | |
| | | | | | | | | | | |
| ------- ------- ------- ------- | | |
+-------------------------------------------+ | |
| |
+-------------------------------------------+ | |
| NFV Infrastructure (NFVI) | | NFV |
| ----------- ----------- ----------- | | Management |
| | Virtual | | Virtual | | Virtual | | | and |
| | Compute | | Storage | | Network | | | Orchestration |
| ----------- ----------- ----------- | | |
| +---------------------------------------+ | | |
| | Virtualization Layer | | | |
| +---------------------------------------+ | | |
| +---------------------------------------+ | | |
| | ----------- ----------- ----------- | | | |
| | | Compute | | Storage | | Network | | | | |
| | ----------- ----------- ----------- | | | |
| | Hardware resources | | | |
| +---------------------------------------+ | | |
+-------------------------------------------+ +---------------+
Figure 1: ETSI NFV framework
The NFV architectural framework identifies functional blocks and the
main reference points between such blocks. Some of these are already
present in current deployments, whilst others might be necessary
additions in order to support the virtualization process and
consequent operation. The functional blocks are (Figure 2):
o Virtualized Network Function (VNF).
o Element Management (EM).
Bernardos, et al. Expires May 4, 2017 [Page 6]
Internet-Draft Network Virtualization Research Challenges October 2016
o NFV Infrastructure, including: Hardware and virtualized resources,
and Virtualization Layer.
o Virtualized Infrastructure Manager(s) (VIM).
o NFV Orchestrator.
o VNF Manager(s).
o Service, VNF and Infrastructure Description.
o Operations and Business Support Systems (OSS/BSS).
+--------------------+
+-------------------------------------------+ | ---------------- |
| OSS/BSS | | | NFV | |
+-------------------------------------------+ | | Orchestrator +-- |
| ---+------------ | |
+-------------------------------------------+ | | | |
| --------- --------- --------- | | | | |
| | EM 1 | | EM 2 | | EM 3 | | | | | |
| ----+---- ----+---- ----+---- | | ---+---------- | |
| | | | |--|-| VNF | | |
| ----+---- ----+---- ----+---- | | | manager(s) | | |
| | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | |
| ----+---- ----+---- ----+---- | | | | |
+------|-------------|-------------|--------+ | | | |
| | | | | | |
+------+-------------+-------------+--------+ | | | |
| NFV Infrastructure (NFVI) | | | | |
| ----------- ----------- ----------- | | | | |
| | Virtual | | Virtual | | Virtual | | | | | |
| | Compute | | Storage | | Network | | | | | |
| ----------- ----------- ----------- | | ---+------ | |
| +---------------------------------------+ | | | | | |
| | Virtualization Layer | |--|-| VIM(s) +-------- |
| +---------------------------------------+ | | | | |
| +---------------------------------------+ | | ---------- |
| | ----------- ----------- ----------- | | | |
| | | Compute | | Storage | | Network | | | | |
| | | hardware| | hardware| | hardware| | | | |
| | ----------- ----------- ----------- | | | |
| | Hardware resources | | | NFV Management |
| +---------------------------------------+ | | and Orchestration |
+-------------------------------------------+ +--------------------+
Figure 2: ETSI NFV reference architecture
Bernardos, et al. Expires May 4, 2017 [Page 7]
Internet-Draft Network Virtualization Research Challenges October 2016
3.2. Software Defined Networking
The Software Defined Networking (SDN) paradigm pushes the
intelligence currently residing in the network elements to a central
controller implementing the network functionality through software.
In contrast to traditional approaches, in which the network's control
plane is distributed throughout all network devices, with SDN the
control plane is logically centralized. In this way, the deployment
of new characteristics in the network no longer requires of complex
and costly changes in equipment or firmware updates, but only a
change in the software running in the controller. The main advantage
of this approach is the flexibility it provides operators with to
manage their network, i.e., an operator can easily change its
policies on how traffic is distributed throughout the network.
The most visible of the SDN protocol stacks is the OpenFlow protocol
(OFP), which is maintained and extended by the Open Network
Foundation (ONF: https://www.opennetworking.org/). Originally this
protocol was developed specifically for IEEE 802.1 switches
conforming to the ONF OpenFlow Switch specification. As the benefits
of the SDN paradigm have reached a wider audience, its application
has been extended to more complex scenarios such as Wireless and
Mobile networks. Within this area of work, the ONF is actively
developing new OFP extensions addressing three key scenarios: (i)
Wireless backhaul, (ii) Cellular Evolved Packet Core (EPC), and (iii)
Unified access and management across enterprise wireless and fixed
networks.
Bernardos, et al. Expires May 4, 2017 [Page 8]
Internet-Draft Network Virtualization Research Challenges October 2016
+----------+
| ------- |
| |Oper.| | O
| |Mgmt.| |<........> -+- Network Operator
| |Iface| | ^
| ------- | +----------------------------------------+
| | | +------------------------------------+ |
| | | | --------- --------- --------- | |
|--------- | | | | App 1 | | App 2 | ... | App n | | |
||Plugins| |<....>| | --------- --------- --------- | |
|--------- | | | Plugins | |
| | | +------------------------------------+ |
| | | Application Plane |
| | +----------------------------------------+
| | A
| | |
| | V
| | +----------------------------------------+
| | | +------------------------------------+ |
|--------- | | | ------------ ------------ | |
|| Netw. | | | | | Module 1 | | Module 2 | | |
||Engine | |<....>| | ------------ ------------ | |
|--------- | | | Network Engine | |
| | | +------------------------------------+ |
| | | Controller Plane |
| | +----------------------------------------+
| | A
| | |
| | V
| | +----------------------------------------+
| | | +--------------+ +--------------+ |
| | | | ------------ | | ------------ | |
|----------| | | | OpenFlow | | | | OpenFlow | | |
||OpenFlow||<....>| | ------------ | | ------------ | |
|----------| | | NE | | NE | |
| | | +--------------+ +--------------+ |
| | | Data Plane |
|Management| +----------------------------------------+
+----------+
Figure 3: High level SDN ONF architecture
Figure 3 shows the blocks and the functional interfaces of the ONF
architecture, which comprises three planes: Data, Controller, and
Application. The Data plane comprehends several Network Entities
(NE), which expose their capabilities toward the Controller plane via
a Southbound API. The Controller plane includes several cooperating
modules devoted to the creation and maintenance of an abstracted
Bernardos, et al. Expires May 4, 2017 [Page 9]
Internet-Draft Network Virtualization Research Challenges October 2016
resource model of the underneath network. Such model is exposed to
the applications via a Northbound API where the Application plane
comprises several applications/services, each of which has exclusive
control of a set of exposed resources.
The Management plane spans its functionality across all planes
performing the initial configuration of the network elements in the
Data plane, the assignment of the SDN controller and the resources
under its responsibility. In the Controller plane, the Management
needs to configure the policies defining the scope of the control
given to the SDN applications, to monitor the performance of the
system, and to configure the parameters required by the SDN
controller modules. In the Application plane, Management configures
the parameters of the applications and the service level agreements.
In addition to the these interactions, the Management plane exposes
several functions to network operators which can easily and quickly
configure and tune the network at each layer.
The SDNRG has documented a reference layer model in RFC7426
[RFC7426], which is reproduced in Figure 4. This model structures
SDN in planes and layers which are glued together by different
abstraction layers. This architecture differentiates between the
control and the management planes and provides for differentiated
southbound interfaces (SBIs).
Bernardos, et al. Expires May 4, 2017 [Page 10]
Internet-Draft Network Virtualization Research Challenges October 2016
o--------------------------------o
| |
| +-------------+ +----------+ |
| | Application | | Service | |
| +-------------+ +----------+ |
| Application Plane |
o---------------Y----------------o
|
*-----------------------------Y---------------------------------*
| Network Services Abstraction Layer (NSAL) |
*------Y------------------------------------------------Y-------*
| |
| Service Interface |
| |
o------Y------------------o o---------------------Y------o
| | Control Plane | | Management Plane | |
| +----Y----+ +-----+ | | +-----+ +----Y----+ |
| | Service | | App | | | | App | | Service | |
| +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ |
| | | | | | | |
| *----Y-----------Y----* | | *---Y---------------Y----* |
| | Control Abstraction | | | | Management Abstraction | |
| | Layer (CAL) | | | | Layer (MAL) | |
| *----------Y----------* | | *----------Y-------------* |
| | | | | |
o------------|------------o o------------|---------------o
| |
| CP | MP
| Southbound | Southbound
| Interface | Interface
| |
*------------Y---------------------------------Y----------------*
| Device and resource Abstraction Layer (DAL) |
*------------Y---------------------------------Y----------------*
| | | |
| o-------Y----------o +-----+ o--------Y----------o |
| | Forwarding Plane | | App | | Operational Plane | |
| o------------------o +-----+ o-------------------o |
| Network Device |
+---------------------------------------------------------------+
Figure 4: SDN Layer Architecture
3.3. Mobile Edge Computing
Mobile Edge Computing capabilities deployed in the edge of the mobile
network can facilitate the efficient and dynamic provision of
services to mobile users. The ETSI ISG MEC working group, operative
Bernardos, et al. Expires May 4, 2017 [Page 11]
Internet-Draft Network Virtualization Research Challenges October 2016
from end of 2014, intends to specify an open environment for
integrating MEC capabilities with service providers networks,
including also applications from 3rd parties. These distributed
computing capabilities will make available IT infrastructure as in a
cloud environment for the deployment of functions in mobile access
networks. It can be seen then as a complement to both NFV and SDN.
3.4. IEEE 802.1CF (OmniRAN)
The IEEE 802.1CF Recommended Practice specifies an access network,
which connects terminals to their access routers, utilizing
technologies based on the family of IEEE 802 Standards (e.g., 802.3
Ethernet, 802.11 Wi-Fi, etc.). The specification defines an access
network reference model, including entities and reference points
along with behavioral and functional descriptions of communications
among those entities.
The goal of this project is to help unifying the support of different
interfaces, enabling shared network control and use of software
defined network (SDN) principles, thereby lowering the barriers to
new network technologies, to new network operators, and to new
service providers.
3.5. Distributed Management Task Force
The DMTF is an industry standards organization working to simplify
the manageability of network-accessible technologies through open and
collaborative efforts by some technology companies. The DMTF is
involved in the creation and adoption of interoperable management
standards, supporting implementations that enable the management of
diverse traditional and emerging technologies including cloud,
virtualization, network and infrastructure.
There are several DMTF initiatives that are relevant to the network
virtualization area, such as the Open Virtualization Format (OVF),
for VNF packaging; the Cloud Infrastructure Management Interface
(CIM), for cloud infrastructure management; the Network Management
(NETMAN), for VNF management; and, the Virtualization Management
(VMAN), for virtualization infrastructure management.
3.6. Open Source initiatives
The Open Source community is especially active in the area of network
virtualization. We next summarize some of the active efforts:
o OpenStack. OpenStack is a free and open-source cloud-computing
software platform. OpenStack software controls large pools of
Bernardos, et al. Expires May 4, 2017 [Page 12]
Internet-Draft Network Virtualization Research Challenges October 2016
compute, storage, and networking resources throughout a
datacenter, managed through a dashboard or via the OpenStack API.
o OpenDayLight. OpenDaylight (ODL) is a highly available, modular,
extensible, scalable and multi-protocol controller infrastructure
built for SDN deployments on modern heterogeneous multi-vendor
networks. It provides a model-driven service abstraction platform
that allows users to write apps that easily work across a wide
variety of hardware and southbound protocols.
o ONOS. The ONOS (Open Network Operating System) project is an open
source community hosted by The Linux Foundation. The goal of the
project is to create a software-defined networking (SDN) operating
system for communications service providers that is designed for
scalability, high performance and high availability.
o OpenContrail. OpenContrail is an Apache 2.0-licensed project that
is built using standards-based protocols and provides all the
necessary components for network virtualization-SDN controller,
virtual router, analytics engine, and published northbound APIs.
It has an extensive REST API to configure and gather operational
and analytics data from the system.
o OPNFV. OPNFV is a carrier-grade, integrated, open source platform
to accelerate the introduction of new NFV products and services.
By integrating components from upstream projects, the OPNFV
community aims at conducting performance and use case-based
testing to ensure the platform's suitability for NFV use cases.
The scope of OPNFV's initial release is focused on building NFV
Infrastructure (NFVI) and Virtualized Infrastructure Management
(VIM) by integrating components from upstream projects such as
OpenDaylight, OpenStack, Ceph Storage, KVM, Open vSwitch, and
Linux. These components, along with application programmable
interfaces (APIs) to other NFV elements form the basic
infrastructure required for Virtualized Network Functions (VNF)
and Management and Network Orchestration (MANO) components.
OPNFV's goal is to increase performance and power efficiency;
improve reliability, availability, and serviceability; and deliver
comprehensive platform instrumentation.
o OSM. Open Source Mano (OSM) is an ETSI-hosted project to develop
an Open Source NFV Management and Orchestration (MANO) software
stack aligned with ETSI NFV. OSM is based on components from
previous projects, such Telefonica's OpenMANO or Canonical's Juju,
among others.
o OpenBaton. OpenBaton is a ETSI NFV compliant Network Function
Virtualization Orchestrator (NFVO). OpenBaton was part of the
Bernardos, et al. Expires May 4, 2017 [Page 13]
Internet-Draft Network Virtualization Research Challenges October 2016
OpenSDNCore project started with the objective of providing a
compliant implementation of the ETSI NFV specification.
Among the main areas that are being developed by the former open
source activities that related to network virtualization research, we
can highlight: policy-based resource management, analytics for
visibility and orchestration, service verification with regards to
security and resiliency.
3.7. Internet of Things (IoT)
The Internet of Things (IoT) refers to the vision of connecting a
multitude of automated devices (e.g. lights, environmental sensors,
traffic lights, parking meters, health and security systems, etc.) to
the Internet for purposes of reporting, and remote command and
control of the device. This vision is being realized by a multi-
pronged approach of standardization in various forums and
complementary open source activities. For example, in IETF, support
of IoT web services has been defined by an HTTP-like protocol adapted
for IoT called CoAP [RFC7252], and lately a group has been studying
the need to develop a new network layer to support IP applications
over Low Power Wide Area Networks (LPWAN).
Elsewhere, for 5G cellular evolution there is much discussion on the
need for supporting virtual "network slices" for the expected massive
numbers of IoT devices. A separate virtual network slice is
considered necessary for different 5G IoT use cases because devices
will have very different characteristics than typical cellular
devices like smart phones [ngmn_5G_whitepaper], and the number of IoT
devices is expected to be at least one or two orders of magnitude
higher than other 5G devices.
4. Network Virtualization Challenges
4.1. Introduction
Network Virtualization is changing the way the telecommunications
sector will deploy, extend and operate their networks. These new
technologies aim at reducing the overall costs by outsourcing
communication services from specific hardware in the operators' core
to server farms scattered in datacenters (i.e. compute and storage
virtualization). In addition, the connecting networks are
fundamentally affected in the way they route, process and control
traffic (i.e. network virtualization).
Bernardos, et al. Expires May 4, 2017 [Page 14]
Internet-Draft Network Virtualization Research Challenges October 2016
4.2. Guaranteeing quality-of-service
Guaranteeing a given quality-of-service in an NFV environment is not
an easy task. For example, ensuring a guaranteed and stable
forwarding data rate has proven not to be straightforward when the
forwarding function is virtualized and runs on top of COTS server
hardware. We next identify some of the challenges that this poses.
4.2.1. Virtualization Technologies
The issue of guaranteeing a network quality-of-service is less of an
issue for "traditional cloud computing". NFV poses very strict
requirements posed in terms of performance, stability and
consistency. Although there are some tools and mechanisms to improve
this, such as Enhanced Performance Awareness (EPA), SR-IOV, NUMA,
DPDK, etc, these are still unsolved challenges. One open research
issue is finding out technologies that are different from VM and more
suitable for dealing with network functionalities.
Lately, a number of light-weight virtualization technologies
including containers, unikernels (specialized VMs) and minimalistic
distributions of general-purpose OSes have appeared as virtualization
approaches that can be used when constructing an NFV platform.
[I-D.natarajan-nfvrg-containers-for-nfv] describes the challenges in
building such a platform and discusses to what extent these
technologies, as well as traditional VMs, are able to address them.
4.2.2. Metrics for NFV characterization
Another relevant aspect is the need for tools for diagnostics and
measurement suited for NFV. There is a pressing need to define
metrics and associated protocols to measure the performance of NFV.
Specifically, since NFV is based on the concept of taking centralized
functions and evolving it to highly distributed SW functions, there
is a commensurate need to fully understand and measure the baseline
performance of such systems.
The IP Performance Metrics (IPPM) WG defines metrics that can be used
to measure the quality and performance of Internet services and
applications running over transport layer protocols (e.g., TCP, UPD)
over IP. It also develops and maintains protocols for the
measurement of these metrics. While the IPPM WG is a long running WG
that started in 1997 it does not have a charter item or active drafts
related to the topic of network virtualization. In addition to using
IPPM metrics to evaluate the QoS, there is a need for specific
metrics for assessing the performance of network virtualization
techniques.
Bernardos, et al. Expires May 4, 2017 [Page 15]
Internet-Draft Network Virtualization Research Challenges October 2016
4.2.3. Predictive analysis
On top of diagnostic tools that enable an assessment of the QoS,
predictive analyses are required to react before anomalies occur.
Due to the SW characteristics of VNFs, a reliable diagnosis framework
could potentially enable the prevention of issues by a proper
diagnosis and then a reaction in terms of acting on the potentially
impacted service (e.g., migration to a different compute node,
scaling in/out, up/down, etc).
4.2.4. Portability
Portability is also a key feature that, if fully enabled, would
contribute to making the NFV environment achieve a better reliability
than a traditional system. The fact of running functionality in SW
over "commodity" infrastructure should make much easier to port/move
functions from one place to another. However this is not yet as
ideal as it sounds and there are aspects not fully tackled. The
existence of different hypervisors, specific hardware dependencies
(e.g., EPA related) or state synchronization aspects are just some
examples of trouble-makers for portability purposes.
4.3. Performance improvement
4.3.1. Energy Efficiency
Virtualization is typically seen as a direct enabler of energy
savings. Some of the enablers for this that are often mentioned are:
(i) the multiplexing gains achieved by centralizing functions in data
centers reduce overall the energy consumed, (ii) the flexibility
brought by network programmability enables to switch off
infrastructure as needed in a much easier way. However there is
still a lot of room for improvement in terms of virtualization
techniques to reduce the power consumption, such as enhanced
hypervisor technologies.
4.3.2. Improved link usage
The use of NFV and SDN technologies can help improving link usage.
SDN has shown already that it can greatly increase average link usage
(e.g., Google example). NFV adds more complexity (e.g., due to
service function chaining / VNF forwarding drafts) which need to be
considered. Aspects like the ones described in
[I-D.bagnulo-nfvrg-topology] on NFV data center topology design have
to be carefully looked as well.
Bernardos, et al. Expires May 4, 2017 [Page 16]
Internet-Draft Network Virtualization Research Challenges October 2016
4.4. Multiple Domains
Market fragmentation has resulted in a multitude of network operators
each focused on different countries and regions. This makes it
difficult to create infrastructure services spanning multiple
countries, such as virtual connectivity or compute resources, as no
single operator has a footprint everywhere. Cross-domain
orchestration of services over multiple administrations or over
multi-domain single administrations will allow end-to-end network and
service elements to mix in multi-vendor, heterogeneous technology and
resource environments.
For the specific use case of 'Network as a Service', it becomes even
more important to ensure, that Cross Domain Orchestration also takes
care of hierarchy of networks and their association, with respect to
provisioning tunnels and overlays.
Multi-domain orchestration is currently an active research topic,
which is being tackled, among others, by ETSI NFV ISG and the 5GEx
project (https://www.5gex.eu/) [I-D.bernardos-nfvrg-multidomain].
4.5. Network Slicing
From the beginning of all 5G discussions in the research and industry
fora, it has been agreed that 5G will have to address much more use
cases than the preceding wireless generations, which first focused on
voice services, and then on voice and high speed packet data
services. In this case, 5G should be able to handle not only the
same (or enhanced) voice and packet data services, but also new
emerging services like tactile Internet and IoT. These use cases
take the requirements to opposite extremes, as some of them require
ultra-low latency and higher-speed, whereas some others require
ultra-low power consumption and high delay tolerance.
Because of these very extreme 5G use cases, it is envisioned that
different radio access networks are needed to better address the
specific requirements of each one of the use cases. However, on the
core network side, virtualization techniques can allow tailoring the
network resources on separate slices, specifically for each radio
access network and use case, in an efficient manner.
Network slicing techniques can also allow dedicating resources for
even more specific use cases within the major 5G categories. For
example, within the major IoT category, which is perhaps the most
disrupting one, some autonomous IoT devices will have very low
throughput, will have much longer sleep cycles (and therefore high
latency), and a battery life thousands of times longer compared to
smart phones or some other connected IoT devices that will have
Bernardos, et al. Expires May 4, 2017 [Page 17]
Internet-Draft Network Virtualization Research Challenges October 2016
almost continuous control and data communications. Hence, it is
envisioned that a single virtual core network could be used by
slicing separate resources to dedicated radio access networks (RANs)
that are better suited for specific use cases.
Network slicing is also a key for introducing new actors in existing
market at low cost -- by letting new players rent "blocks" of
capacity, if this new market provides performance that are adequate
with the application needs (e.g., broadcasting updates to many
sensors with satellite broadcasting capabilities). However, more
work needs to be done to define how network slicing will impact
existing architectures like ETSI NFV, and to define the impacts of
network slicing to guaranteeing quality-of-service as described in
Section 4.2.
4.6. Service Composition
Current network services deployed by operators often involve the
composition of several individual functions (such as packet
filtering, deep packet inspection, load balancing). These services
are typically implemented by the ordered combination of a number of
service functions that are deployed at different points within a
network, not necessary on the direct data path. This requires
traffic to be steered through the required service functions,
wherever they are deployed.
For a given service, the abstracted view of the required service
functions and the order in which they are to be applied is called a
Service Function Chain (SFC), which is called Network Function
Forwarding Graph (NF-FG) in ETSI. An SFC is instantiated through
selection of specific service function instances on specific network
nodes to form a service graph: this is called a Service Function Path
(SFP). The service functions may be applied at any layer within the
network protocol stack (network layer, transport layer, application
layer, etc.).
Service composition is a powerful tool which can provide significant
benefits when applied in a softwarized network environment. There
are however many research challenges in this area, as for example the
ones related to composition mechanisms and algorithms to enable load
balancing and improve reliability. The service composition should
also act as an enabler to gather information across all hierarchies
(underlays and overlays) of network deployments which may span across
multiple operators, for faster serviceability thus facilitating in
accomplishing aforementioned goals of "load balancing and improve
reliability".
Bernardos, et al. Expires May 4, 2017 [Page 18]
Internet-Draft Network Virtualization Research Challenges October 2016
The SFC working group is working on an architecture for service
function chaining that includes the necessary protocols or protocol
extensions to convey the Service Function Chain and Service Function
Path information to nodes that are involved in the implementation of
service functions and Service Function Chains, as well as mechanisms
for steering traffic through service functions.
In terms of actual work items, the SFC WG is has not yet considered
working on the management and configuration of SFC components related
to the support of Service Function Chaining. This part is of special
interest for operators and would be required in order to actually put
SFC mechanisms into operation. Similarly, redundancy and reliability
mechanisms are currently not dealt with by any WG in the IETF. While
this was the main goal of the VNFpool BoF efforts, it still remains
unaddressed.
4.7. End-user device virtualization
So far, most of the network softwarization efforts have focused on
virtualizing functions of network elements. While virtualization of
network elements started with the core, mobile networks architectures
are now heavily switching to also virtualize radio access network
(RAN) functions. The next natural step is to get virtualization down
at the level of the end-user device (i.e., virtualizing a
smartphone). The cloning of a device in the cloud (central or local)
bears attractive benefits to both the device and network operations
alike (e.g., power saving at the device by offloading computational-
heaving functions to the cloud, optimized networking -- both device-
to-device and device-to-infrastructure) for service delivery through
tighter integration of the device (via its clone in the networking
infrastructure). This is being explored for example by the European
H2020 ICIRRUS project (www.icirrus-5gnet.eu).
4.8. Security and Privacy
Similar to any other situation where resources are shared, security
and privacy are two important aspects that need to be taken into
account.
In the case of security, there are situations where multiple vendors
will need to coexist in a virtual or hybrid physical/virtual
environment. This requires attestation procedures amongst different
virtual/physical functions and resources, as well as ongoing external
monitoring. Similarly, different network slices operating on the
same infrastructure can present security problems, for instance if
one slice running critical applications (e.g. support for a safety
system) is affected by another slice running a less critical
application. In general, the minimum common denominator for security
Bernardos, et al. Expires May 4, 2017 [Page 19]
Internet-Draft Network Virtualization Research Challenges October 2016
measures on a shared system should be equal or higher than the one
required by the most critical application. Multiple and continuous
threat model analysis, as well as DevOps model are required to
maintain certain level of security in an NFV system.
On the other hand, privacy in its strictest interpretation, refers to
concerns about exposing users of the system to individual threats
such as surveillance, identification, stored data compromise,
secondary use, intrusion, etc. In this case, the storage,
transmission, collection, and potential correlation of information in
the NFV system, for purposes not originally intended or not known by
the user, should be avoided. This is particularly challenging, as
future intentions and threats cannot be easily predicted, and still
can be applied for instance on data collected in the past.
Therefore, well-known techniques such as data minimization, using
privacy features as default, and allowing users to opt in/out should
be used to prevent potential privacy issues.
Compared to traditional networks, NFV will result in networks that
are much more dynamic (in function distribution and topology) and
elastic (in size and boundaries). NFV will thus require network
operators to evolve their operational and administrative security
solutions to work in this new environment. For example, in NFV the
network orchestrator will become a key node to provide security
policy orchestration across the different physical and virtual
components of the virtualized network. For highly confidential data,
for example, the network orchestrator should take into account if
certain physical HW of the network is considered more secure (e.g.,
because it is located in secure premises) than other HW.
Traditional telecom networks typically run under a single
administrative domain controlled by an operator. With NFV, it is
expected that in many cases, the telecom operator will now become a
tenant (running the VNFs), and the infrastructure (NFVI) may be run
by a different operator and/or cloud service provider (see also
Section 4.4). Thus, there will be multiple administrative domains
which will make coordination of security policy more complex. For
example, who will be in charge of provisioning and maintaining
security credentials such as public and private keys? Also, should
private keys be allowed to be replicated across the NFV for
redundancy reasons?
On a positive note, NFV will allow better defense against Denial of
Service (DoS) attacks because of the distributed nature of the
network (i.e. no single point of failure) and the ability to steer
(undesirable) traffic quickly. Also, NFVs which have physical HW
which is distributed across multiple data centers will also provide
better fault isolation environments. Especially, if each data center
Bernardos, et al. Expires May 4, 2017 [Page 20]
Internet-Draft Network Virtualization Research Challenges October 2016
is protected separately via fire walls, DMZs and other network
protection techniques.
4.9. Separation of control concerns
NFV environments offer two possible levels of SDN control. One level
is the need for controlling the NFVI to provide connectivity end-to-
end among VNFs or among VNFs and PNFs (Physical Network Functions).
A second level is the control and configuration of the VNFs
themselves (in other words, the configuration of the network service
implemented by those VNFs), taking profit of the programmability
brought by SDN. Both control concerns are separated in nature.
However, interaction between both could be expected in order to
optimize, scale or influence each other.
Clear mechanisms for such interaction are needed in order to avoid
mal-functioning or interference among concerns. These ideas are
considered in [etsi_sdn_in_nvf_eve005] and
[I-D.irtf-sdnrg-layered-sdn]
5. Technology Gaps and Potential IETF Efforts
Table 1 correlates the open network virtualization research areas
identified in this document to potential IETF groups that could
address some aspects of them. An example of a specific gap that the
group could potentially address is identified in parenthetical beside
the group name.
+----------------------------------+--------------------------------+
| Open Research Area | Potential IETF/IRTF Group |
+----------------------------------+--------------------------------+
| 1-Guaranteeing QoS | IPPM WG (Measurements of NFVI) |
| 2-Performance improvement | VNFPOOL BoF (NFV resilience) |
| 3-Multiple Domains | NFVRG |
| 4-Network Slicing | NVO3 WG (5G Traffic isolation) |
| 5-Service Composition | SFC WG (SFC Mgmt and Config) |
| 6-End-user device virtualization | N/A |
| 7-Security | N/A |
| 8-Separation of control concerns | SDNRG |
+----------------------------------+--------------------------------+
Table 1: Mapping of Open Research Areas to Potential IETF Groups
6. Mapping to NFVRG Near-Term work items
Table 2 correlates the currently identified NFVRG near-work items to
the open network virtualization research areas enumerated in this
Bernardos, et al. Expires May 4, 2017 [Page 21]
Internet-Draft Network Virtualization Research Challenges October 2016
document. This can help the NFVRG in identifying and prioritizing
research topics.
+--------------------------------------+-------------------------+
| NFVRG Near-Term work item | Open Research Area |
+--------------------------------------+-------------------------+
| 1-Policy-based resource management | - Performance improvem. |
| | - Network Slicing |
| 2-Analytics for visibility & orches. | - Guaranteeing QoS |
| 3-Security and service verification | - Security |
| 4-Reliability and fault detection | - Guaranteeing QoS |
| 5-Service orchestration & lifecycle | - Multiple Domains |
| | - Network Slicing |
| | - Service Composition |
| 6-Real-time properties | - Guaranteeing QoS |
| | |
| (other) | - End-user device virt. |
| | - Separation of control |
+--------------------------------------+-------------------------+
Table 2: Mapping of NFVRG Near-Term work items to Open Research Areas
7. IANA Considerations
N/A.
8. Security Considerations
This is an informational document, which therefore does not introduce
any security threat. Research challenges and gaps related to
security and privacy have been included in Section 4.8.
9. Acknowledgments
The authors want to thank Dirk von Hugo, Rafa Marin, Diego Lopez,
Ramki Krishnan, Kostas Pentikousis, Rana Pratap Sircar, Alfred
Morton, Nicolas Kuhn and Saumya Dikshit for their very useful reviews
and comments to the document.
The work of Carlos J. Bernardos and Luis M. Contreras is partially
supported by the H2020-ICT-2014 project 5GEx (Grant Agreement no.
671636).
The work of Pedro Aranda is supported by the European FP7 Project
Trilogy2 under grant agreement 317756.
Bernardos, et al. Expires May 4, 2017 [Page 22]
Internet-Draft Network Virtualization Research Challenges October 2016
10. Informative References
[etsi_nvf_whitepaper]
"Network Functions Virtualisation (NFV). White Paper 2",
October 2014.
[etsi_sdn_in_nvf_eve005]
"Report on SDN Usage in NFV Architectural Framework",
Dicember 2015.
[I-D.bagnulo-nfvrg-topology]
Bagnulo, M. and D. Dolson, "NFVI PoP Network Topology:
Problem Statement", draft-bagnulo-nfvrg-topology-01 (work
in progress), March 2016.
[I-D.bernardos-nfvrg-multidomain]
Bernardos, C. and L. Contreras, "Multi-domain Network
Virtualization", draft-bernardos-nfvrg-multidomain-00
(work in progress), March 2016.
[I-D.irtf-sdnrg-layered-sdn]
Contreras, L., Bernardos, C., Lopez, D., Boucadair, M.,
and P. Iovanna, "Cooperating Layered Architecture for
SDN", draft-irtf-sdnrg-layered-sdn-01 (work in progress),
October 2016.
[I-D.matsushima-stateless-uplane-vepc]
Matsushima, S. and R. Wakikawa, "Stateless user-plane
architecture for virtualized EPC (vEPC)", draft-
matsushima-stateless-uplane-vepc-06 (work in progress),
March 2016.
[I-D.natarajan-nfvrg-containers-for-nfv]
natarajan.sriram@gmail.com, n., Krishnan, R., Ghanwani,
A., Krishnaswamy, D., Willis, P., Chaudhary, A., and F.
Huici, "An Analysis of Lightweight Virtualization
Technologies for NFV", draft-natarajan-nfvrg-containers-
for-nfv-03 (work in progress), July 2016.
[ngmn_5G_whitepaper]
"NGMN 5G. White Paper", February 2015.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
Bernardos, et al. Expires May 4, 2017 [Page 23]
Internet-Draft Network Virtualization Research Challenges October 2016
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <http://www.rfc-editor.org/info/rfc7426>.
Authors' Addresses
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Akbar Rahman
InterDigital Communications, LLC
1000 Sherbrooke Street West, 10th floor
Montreal, Quebec H3A 3G4
Canada
Email: Akbar.Rahman@InterDigital.com
URI: http://www.InterDigital.com/
Juan Carlos Zuniga
SIGFOX
425 rue Jean Rostand
Labege 31670
France
Email: j.c.zuniga@ieee.org
URI: http://www.sigfox.com/
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, S/N
Madrid 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
Bernardos, et al. Expires May 4, 2017 [Page 24]
Internet-Draft Network Virtualization Research Challenges October 2016
Pedro Aranda
Telefonica I+D
Ronda de la Comunicacion, S/N
Madrid 28050
Spain
Email: pedroa.aranda@telefonica.com
Bernardos, et al. Expires May 4, 2017 [Page 25]