[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-bernardos-nfvrg-gaps-network-virtualization) 00 01 02 03 04 05 06 07 08 09 10 RFC 8568

NFVRG                                                      CJ. Bernardos
Internet-Draft                                                      UC3M
Intended status: Informational                                 A. Rahman
Expires: January 9, 2017                                    InterDigital
                                                              JC. Zuniga
                                                                  SIGFOX
                                                           LM. Contreras
                                                               P. Aranda
                                                                     TID
                                                            July 8, 2016


           Gap Analysis on Network Virtualization Activities
            draft-irtf-nfvrg-gaps-network-virtualization-01

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 service guarantees, energy efficiency, supporting multiple
   domains, network slicing, self-management, 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 January 9, 2017                [Page 1]


Internet-Draft     Gap Analysis Network Virtualization         July 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 January 9, 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 . . . . . . . . . . . . . . .   7
     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.  Service Guarantees  . . . . . . . . . . . . . . . . . . .  15
     4.3.  Energy Efficiency . . . . . . . . . . . . . . . . . . . .  16
     4.4.  Multiple Domains  . . . . . . . . . . . . . . . . . . . .  16
     4.5.  Network Slicing . . . . . . . . . . . . . . . . . . . . .  16
     4.6.  Service Composition . . . . . . . . . . . . . . . . . . .  17
     4.7.  Orchestration . . . . . . . . . . . . . . . . . . . . . .  18
     4.8.  Self Management . . . . . . . . . . . . . . . . . . . . .  18
     4.9.  Robustness  . . . . . . . . . . . . . . . . . . . . . . .  18
     4.10. Security and Privacy  . . . . . . . . . . . . . . . . . .  18
   5.  Summary of Gaps . . . . . . . . . . . . . . . . . . . . . . .  19
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  19
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  20



Bernardos, et al.        Expires January 9, 2017                [Page 2]


Internet-Draft     Gap Analysis Network Virtualization         July 2016


   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

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.

   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



Bernardos, et al.        Expires January 9, 2017                [Page 3]


Internet-Draft     Gap Analysis Network Virtualization         July 2016


   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.

      Operational Plane (OP) - The collection of resources responsible
      for managing the overall operation of individual network devices.





Bernardos, et al.        Expires January 9, 2017                [Page 4]


Internet-Draft     Gap Analysis Network Virtualization         July 2016


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

   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



Bernardos, et al.        Expires January 9, 2017                [Page 5]


Internet-Draft     Gap Analysis Network Virtualization         July 2016


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

   o  NFV Infrastructure, including: Hardware and virtualized resources,
      and Virtualization Layer.

   o  Virtualized Infrastructure Manager(s) (VIM).




Bernardos, et al.        Expires January 9, 2017                [Page 6]


Internet-Draft     Gap Analysis Network Virtualization         July 2016


   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

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.



Bernardos, et al.        Expires January 9, 2017                [Page 7]


Internet-Draft     Gap Analysis Network Virtualization         July 2016


   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 January 9, 2017                [Page 8]


Internet-Draft     Gap Analysis Network Virtualization         July 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 January 9, 2017                [Page 9]


Internet-Draft     Gap Analysis Network Virtualization         July 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 January 9, 2017               [Page 10]


Internet-Draft     Gap Analysis Network Virtualization         July 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 January 9, 2017               [Page 11]


Internet-Draft     Gap Analysis Network Virtualization         July 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 January 9, 2017               [Page 12]


Internet-Draft     Gap Analysis Network Virtualization         July 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 January 9, 2017               [Page 13]


Internet-Draft     Gap Analysis Network Virtualization         July 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 January 9, 2017               [Page 14]


Internet-Draft     Gap Analysis Network Virtualization         July 2016


4.2.  Service Guarantees

   Providing service guarantees in an NFV environment is not an easy
   task.  We next identify some of the challenges that this poses.

   An important difference between NFV and traditional Cloud computing
   comes from the very strict requirements posed by NFV 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.  [I-D.natarajan-nfvrg-containers-for-nfv] analyzes
   different virtualization technologies that could be used, instead of
   just using VMs.

   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.

   Related to the need of diagnostics tools, there is also a need in
   terms of predictive analysis allowing for reaction before an
   operation anomaly takes place.  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).

   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.




Bernardos, et al.        Expires January 9, 2017               [Page 15]


Internet-Draft     Gap Analysis Network Virtualization         July 2016


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

   Multi-domain orchestration is currently an active research topic,
   which is being tackled, among others, by ETSI NFV ISG and the 5GEx
   project.

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.




Bernardos, et al.        Expires January 9, 2017               [Page 16]


Internet-Draft     Gap Analysis Network Virtualization         July 2016


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

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



Bernardos, et al.        Expires January 9, 2017               [Page 17]


Internet-Draft     Gap Analysis Network Virtualization         July 2016


   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
   un-addressed.

4.7.  Orchestration

   TBD.

4.8.  Self Management

   TBD.  Include aspects such as: Planning, optimization, diagnostics,
   recovery, validation.

4.9.  Robustness

   TBD.

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



Bernardos, et al.        Expires January 9, 2017               [Page 18]


Internet-Draft     Gap Analysis Network Virtualization         July 2016


   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.

5.  Summary of Gaps

   Table 1 correlates the open network virtualization research areas to
   potential IETF/IRTF WGs and new activities that could address these
   gaps.

   +----------------------------+--------------------------------------+
   | Open Research Area         | Potential IETF/IRTF Gap              |
   +----------------------------+--------------------------------------+
   | 1-Service Guarantee        | IPPM WG (Measurements for NFV)       |
   | 2-Energy Efficiency        | WG-x                                 |
   | 3-Multiple Domains         | WG-x                                 |
   | 4-Network Slicing          | NVO3 (Traffic isolation)             |
   | 5-Service Composition      | SFC WG (Mgmt and configuration)      |
   | 6-Orchestration            | WG-x                                 |
   | 7-Self Management          | WG-x                                 |
   | 8-Robustness and           | VNFPool BoF (Redundancy and          |
   | Reliability                | reliability)                         |
   | 9-Security                 | WG-x                                 |
   +----------------------------+--------------------------------------+

    Table 1: Mapping of Open Research Areas to Potential IETF/IRTF Gaps

6.  IANA Considerations

   N/A.

7.  Security Considerations

   TBD.

8.  Acknowledgments

   The authors want to thank Dirk von Hugo, Rafa Marin, Diego Lopez,
   Ramki Krishnan, Kostas Pentikousis, Rana Pratap Sircar and Alfred
   Morton 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 January 9, 2017               [Page 19]


Internet-Draft     Gap Analysis Network Virtualization         July 2016


9.  Informative References

   [etsi_nvf_whitepaper]
              "Network Functions Virtualisation (NFV). White Paper 2",
              October 2014.

   [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-02 (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>.

   [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/







Bernardos, et al.        Expires January 9, 2017               [Page 20]


Internet-Draft     Gap Analysis Network Virtualization         July 2016


   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: JuanCarlos.Zuniga@sigfox.com
   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


   Pedro Aranda
   Telefonica I+D
   Ronda de la Comunicacion, S/N
   Madrid  28050
   Spain

   Email: pedroa.aranda@telefonica.com















Bernardos, et al.        Expires January 9, 2017               [Page 21]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/