Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: IRTF

RFC 8568

Network Virtualization Research Challenges

Pages: 42
Informational
Part 1 of 3 – Pages 1 to 17
None   None   Next

Top   ToC   Page 1
Internet Research Task Force (IRTF)                        CJ. Bernardos
Request for Comments: 8568                                          UC3M
Category: Informational                                        A. Rahman
ISSN: 2070-1721                                             InterDigital
                                                              JC. Zuniga
                                                                  SIGFOX
                                                           LM. Contreras
                                                                     TID
                                                               P. Aranda
                                                                    UC3M
                                                                P. Lynch
                                                   Keysight Technologies
                                                              April 2019


               Network Virtualization Research Challenges

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 and engineering challenges in network
   virtualization including the guarantee of quality of service,
   performance improvement, support for multiple domains, network
   slicing, service composition, device virtualization, privacy and
   security, separation of control concerns, network function placement,
   and testing.  In addition, some proposals are made for new activities
   in the IETF and IRTF that could address some of these challenges.
   This document is a product of the Network Function Virtualization
   Research Group (NFVRG).
Top   ToC   Page 2
Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Research Task Force
   (IRTF).  The IRTF publishes the results of Internet-related research
   and development activities.  These results might not be suitable for
   deployment.  This RFC represents the consensus of the Network
   Function Virtualization Research Group of the Internet Research Task
   Force (IRTF).  Documents approved for publication by the IRSG are not
   candidates for any level of Internet Standard; see Section 2 of RFC
   7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8568.

Copyright Notice

   Copyright (c) 2019 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
   (https://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.
Top   ToC   Page 3
Table of Contents

   1.  Introduction and Scope  . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Network Function Virtualization . . . . . . . . . . . . .   6
     3.2.  Software-Defined Networking . . . . . . . . . . . . . . .   9
     3.3.  ITU-T Functional Architecture of SDN  . . . . . . . . . .  13
     3.4.  Multi-Access Edge Computing . . . . . . . . . . . . . . .  15
     3.5.  IEEE 802.1CF (OmniRAN)  . . . . . . . . . . . . . . . . .  15
     3.6.  Distributed Management Task Force (DMTF)  . . . . . . . .  15
     3.7.  Open-Source Initiatives . . . . . . . . . . . . . . . . .  16
   4.  Network Virtualization Challenges . . . . . . . . . . . . . .  18
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  18
     4.2.  Guaranteeing Quality of Service . . . . . . . . . . . . .  18
       4.2.1.  Virtualization Technologies . . . . . . . . . . . . .  18
       4.2.2.  Metrics for NFV Characterization  . . . . . . . . . .  19
       4.2.3.  Predictive Analysis . . . . . . . . . . . . . . . . .  20
       4.2.4.  Portability . . . . . . . . . . . . . . . . . . . . .  20
     4.3.  Performance Improvement . . . . . . . . . . . . . . . . .  21
       4.3.1.  Energy Efficiency . . . . . . . . . . . . . . . . . .  21
       4.3.2.  Improved Link Usage . . . . . . . . . . . . . . . . .  21
     4.4.  Multiple Domains  . . . . . . . . . . . . . . . . . . . .  22
     4.5.  5G and Network Slicing  . . . . . . . . . . . . . . . . .  22
       4.5.1.  Virtual Network Operators . . . . . . . . . . . . . .  23
       4.5.2.  Extending Virtual Networks and Systems to the
               Internet of Things  . . . . . . . . . . . . . . . . .  24
     4.6.  Service Composition . . . . . . . . . . . . . . . . . . .  25
     4.7.  Device Virtualization for End Users . . . . . . . . . . .  27
     4.8.  Security and Privacy  . . . . . . . . . . . . . . . . . .  27
     4.9.  Separation of Control Concerns  . . . . . . . . . . . . .  29
     4.10. Network Function Placement  . . . . . . . . . . . . . . .  29
     4.11. Testing . . . . . . . . . . . . . . . . . . . . . . . . .  30
       4.11.1.  Changes in Methodology . . . . . . . . . . . . . . .  30
       4.11.2.  New Functionality  . . . . . . . . . . . . . . . . .  31
       4.11.3.  Opportunities  . . . . . . . . . . . . . . . . . . .  32
   5.  Technology Gaps and Potential IETF Efforts  . . . . . . . . .  33
   6.  NFVRG Focus Areas . . . . . . . . . . . . . . . . . . . . . .  34
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  35
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  35
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  35
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  41
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  41
Top   ToC   Page 4
1.  Introduction and Scope

   The telecommunications sector is experiencing a major revolution that
   will shape the way networks and services are designed and deployed
   for the next few decades.  In order to cope with continuously
   increasing demand and cost, network operators are taking lessons from
   the IT paradigm of cloud computing.  This new approach of
   virtualizing network functions will enable multi-fold advantages by
   moving communication services from bespoke hardware in the operator's
   core network to Commercial Off-The-Shelf (COTS) equipment distributed
   across data centers.

   Some of the network virtualization mechanisms that are being
   considered include the following: sharing of network infrastructure
   to reduce costs, virtualization of core and edge servers/services
   running in data centers as a way of supporting their load-aware
   elastic dimensioning, and dynamic energy policies to reduce the
   electricity consumption.

   This document presents research and engineering challenges in network
   virtualization that need to be addressed in order to achieve these
   goals, spanning from pure research and engineering/standards space.
   The objective of this memo is to document the technical challenges
   and corresponding current approaches and to expose requirements that
   should be addressed by future research and standards work.

   This document represents the consensus of the Network Function
   Virtualization Research Group (NFVRG).  It has been reviewed by the
   RG members active in the specific areas of work covered by the
   document.

2.  Terminology

   The following terms used in this document are defined by the ETSI
   Network Function Virtualization (NFV) Industrial Study Group (ISG)
   [etsi_gs_nfv_003], the Open Networking Foundation (ONF) [onf_tr_521],
   and the IETF [RFC7426] [RFC7665]:

   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.  The 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.
Top   ToC   Page 5
   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 that 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) life cycle and coordinates the management of NS life
      cycle, VNF life cycle (supported by the VNFM) and NFVI resources
      (supported by the VIM) to ensure an optimized allocation of the
      necessary resources and connectivity.

   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.

   Virtualized Infrastructure Manager (VIM):  Functional block that is
      responsible for controlling and managing the NFVI compute,
      storage, and network resources, usually within one infrastructure
      operator's 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 life-cycle management of VNF.
Top   ToC   Page 6
3.  Background

   This section briefly describes some basic background technologies as
   well as other Standards Developing Organizations (SDOs) and open-
   source initiatives working on network virtualization or related
   topics.

3.1.  Network Function Virtualization

   The ETSI ISG Network Function Virtualization (NFV) is a working group
   that, since 2012, has aimed 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.  The ETSI NFV is one of the
   predominant NFV reference framework and architectural footprints
   [nfv_sota_research_challenges].  The ETSI NFV framework architecture
   is composed of three domains (Figure 1):

   o  Virtualized Network Function, running over the NFVI.

   o  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.
Top   ToC   Page 7
   +-------------------------------------------+  +---------------+
   |   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
      as well as the Virtualization Layer.

   o  Virtualized Infrastructure Manager(s) (VIM)

   o  NFV Orchestrator

   o  VNF Manager(s)

   o  Service, VNF and Infrastructure Description
Top   ToC   Page 8
   o  Operational Support Systems and Business Support Systems (OSS and
      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
Top   ToC   Page 9
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 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 to manage their
   network, i.e., an operator can easily change its policies on how
   traffic is distributed throughout the network.

   One of the most well-known protocols for the SDN control plane
   between the central controller and the networking elements 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
   [OpenFlow].  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.
Top   ToC   Page 10
   +----------+
   | -------  |
   | |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                     | |
   |          |      | +------------------------------------+ |
   |          |      | Control 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
   (NEs), which expose their capabilities toward the control plane via a
   Southbound API.  The control plane includes several cooperating
   modules devoted to the creation and maintenance of an abstracted
Top   ToC   Page 11
   resource model of the underlying network.  Such a 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 control 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, the management plane configures the parameters
   of the applications and the service-level agreements.  In addition to
   these interactions, the management plane exposes several functions to
   network operators that can easily and quickly configure and tune the
   network at each layer.

   In RFC 7426 [RFC7426], the IRTF Software-Defined Networking Research
   Group (SDNRG) documented a layer model of an SDN architecture.  This
   was due to the following controversial discussion topics (among
   others).  What exactly is SDN?  What is the layer structure of the
   SDN architecture?  How do layers interface with each other?

   Figure 4 reproduces the figure included in RFC 7426 [RFC7426] to
   summarize the SDN architecture abstractions in the form of a
   detailed, high-level schematic.  In a particular implementation,
   planes can be collocated with other planes or can be physically
   separated.

   In SDN, a controller manipulates controlled entities via an
   interface.  Interfaces, when local, are mostly API invocations
   through some library or system call.  However, such interfaces may be
   extended via some protocol definition, which may use local
   interprocess communication (IPC) or a protocol that could also act
   remotely; the protocol may be defined as an open standard or in a
   proprietary manner.

   SDN expands multiple planes: forwarding, operational, control,
   management, and application.  All planes mentioned above are
   connected via interfaces.  Additionally, RFC 7426 [RFC7426] considers
   four abstraction layers: the Device and resource Abstraction Layer
   (DAL), the Control Abstraction Layer (CAL), the Management
   Abstraction Layer (MAL), and the Network Services Abstraction Layer
   (NSAL).
Top   ToC   Page 12
                  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

   While SDN is often directly associated to OpenFlow, this is just one
   (relevant) example of a southbound protocol between the central
   controller and the network entities.  Other relevant examples of
   protocols in the SDN family are NETCONF [RFC6241], RESTCONF
   [RFC8040], and ForCES [RFC5810].
Top   ToC   Page 13
3.3.  ITU-T Functional Architecture of SDN

   The ITU-T (the Telecommunication standardization sector of the
   International Telecommunication Union) has also looked into SDN
   architectures, defining a slightly modified one from what other SDOs
   have done.  In ITU-T recommendation Y.3302 [itu-t-y.3302], the ITU-T
   provides a functional architecture of SDN with descriptions of
   functional components and reference points.  The described functional
   architecture is intended to be used as an enabler for further studies
   on other aspects such as protocols and security as well as being used
   to customize SDN in support of appropriate use cases (e.g., cloud
   computing, mobile networks).  This recommendation is based on ITU-T
   Y.3300 [itu-t-y.3300] and ITU-T Y.3301 [itu-t-y.3301].  While the
   first describes the framework of SDN (including definitions,
   objectives, high-level capabilities, requirements, and the high-level
   architecture of SDN), the second describes more-detailed
   requirements.

   Figure 5 shows the SDN functional architecture defined by the ITU-T.
   It is a layered architecture composed of the SDN application layer
   (SDN-AL), the SDN control layer (SDN-CL), and the SDN resource layer
   (SDN-RL).  It also has multi-layer management functions (MMF), which
   provide the ability to manage the functionalities of SDN layers,
   i.e., SDN-AL, SDN-CL, and SDN-RL.  MMF interacts with these layers
   using Multi-layer Management Functions Application (MMFA), Multi-
   layer Management Functions Control (MMFC), and Multi-layer Management
   Functions Resource (MMFR) reference points.

   The SDN-AL enables a service-aware behavior of the underlying network
   in a programmatic manner.  The SDN-CL provides programmable means to
   control the behavior of SDN-RL resources (such as data transport and
   processing) following requests received from the SDN-AL according to
   MMF policies.  The SDN-RL is where the physical or virtual network
   elements perform transport and/or processing of data packets
   according to SDN-CL decisions.
Top   ToC   Page 14
          MMFO                      MMFA
   +-----+ . +---------------------+ . +--------------------+
   |     | . |+---+ +---+ +-------+| . |+---------+ +-----+ |
   |     | . ||   | |   | |       || . ||   AL.   | |     | |
   |     | . || E | |   | |  App. || . || Mngmt.  | | SDN | | SDN-AL
   |     | . || x | | M | | Layer || . || Support | | App | |
   |     | . || t.| | u | | Mngmt.|| . || & Orch. | |     | |
   |     | . ||   | | l | +-------+| . |+---------+ +-----+ |
   |     | . || R | | t |          | . +--------------------+
   |     | . || e | | i |          |MMFC ..................... ACI
   |     | . || l | | - |          | . +--------------------+
   |     | . || a | | l | +-------+| . |+------+ +---------+|
   | OSS/| . || t | | a | |       || . ||      | |   App.  ||
   | BSS | . || i | | y | |       || . ||      | | Support ||
   |     | . || o | | e | |       || . ||      | +---------+|
   |     | . || n | | r | |       || . ||  CL  | +---------+|
   |     | . || s | |   | |Control|| . ||Mngmt.| | Control ||
   |     | . || h | | M | | Layer || . || Supp.| |  Layer  || SDN-CL
   |     | . || i | | a | | Mngmt.|| . || and  | |  Serv.  ||
   |     | . || p | | n | |       || . || Orch.| +---------+|
   |     | . ||   | | a | |       || . ||      | +---------+|
   |     | . || M | | g | |       || . ||      | | Resource||
   |     | . || n | | e | |       || . ||      | | Abstrac.||
   |     | . || g | | m | +-------+| . |+------+ +---------+|
   |     | . || m | | e |          | . +--------------------+
   |     | . || t.| | n |          |MMFR ..................... RCI
   |     | . ||   | | t |          | . +--------------------+
   +-----+ . |+---+ |   | +-------+| . |+------++----------+|
             |      | O | |       || . ||      ||RL Control||
             |      | r | |Resour.|| . ||  RL  |+----------+|
        MMF  |      | c | | Layer || . ||Mngmt.|+----++----+| SDN-RL
             |      | h.| | Mngmt.|| . || Supp.||Data||Data||
             |      |   | |       || . ||      ||Tran||Proc||
             |      +---+ +-------+| . |+------++----++----+|
             +---------------------+ . +--------------------+

   Legend:
     ACI:  Application Control Interface
     MMFA: Multi-layer Management Functions Application
     MMFC: Multi-layer Management Functions Control
     MMFO: Multi-layer Management Functions OSS/BSS
     MMFR: Multi-layer Management Functions Resource
     RCI:  Resource Control Interfaces
     RL:   Resource Layer

                Figure 5: ITU-T SDN Functional Architecture
Top   ToC   Page 15
3.4.  Multi-Access Edge Computing

   Multi-access Edge Computing (MEC) -- formerly known as 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 from end of
   2014, intends to specify an open environment for integrating MEC
   capabilities with service providers' networks, also including
   applications from third parties.  These distributed computing
   capabilities provide 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.5.  IEEE 802.1CF (OmniRAN)

   The IEEE 802.1CF Recommended Practice [omniran] specifies an access
   network that 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 unify the support of different
   interfaces, enabling shared-network control and use of SDN
   principles, thereby lowering the barriers to new network
   technologies, to new network operators, and to new service providers.

3.6.  Distributed Management Task Force (DMTF)

   The DMTF <https://www.dmtf.org/> 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 (CIMI)
   for cloud infrastructure management; the Network Management (NETMAN),
   for VNF management; and the Virtualization Management (VMAN), for
   virtualization infrastructure management.
Top   ToC   Page 16
3.7.  Open-Source Initiatives

   The open-source community is especially active in the area of network
   virtualization and orchestration.  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
      compute, storage, and networking resources throughout a data
      center, managed through a dashboard or via the OpenStack API.

   o  Kubernetes.  Kubernetes is an open-source system for automating
      deployment, scaling and management of containerized applications.
      Kubernetes can schedule and run application containers on clusters
      of physical or virtual machines.  Kubernetes allows (i) Scale on
      the fly, (ii) Limit hardware usage to required resources only,
      (iii) Load-balancing Monitoring, and (iv) Efficient life-cycle
      management.

   o  OpenDayLight.  OpenDayLight (ODL) is a highly available, modular,
      extensible and scalable multiprotocol 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 Open Network Operating System (ONOS) project is an
      open-source community hosted by The Linux Foundation.  The goal of
      the project is to create an SDN operating system for
      communications service providers that is designed for scalability,
      high performance, and high availability.

   o  OpenContrail.  OpenContrail is a licensed Apache 2.0 project that
      is built using standards-based protocols and that provides all the
      necessary components for network virtualization: an SDN
      controller, a virtual router, an analytics engine, and published
      northbound APIs.  It has an extensive Representational State
      Transfer (REST) API to configure and gather operational and
      analytics data from the system.

   o  OPNFV.  The Open Platform for NFV (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 Manager (VIM) by integrating components
Top   ToC   Page 17
      from upstream projects such as OpenDayLight, OpenStack, Ceph
      Storage, Kernel-based Virtual Machine (KVM), Open vSwitch, and
      Linux.  These components, along with APIs to other NFV elements,
      form the basic infrastructure required for Virtualized Network
      Functions (VNFs) and Management and Orchestration (MANO)
      components.  OPNFV's goal is to (i) increase performance and power
      efficiency, (ii) improve reliability, availability, and
      serviceability, and (iii) 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 Network Function Virtualization
      Orchestrator (NFVO) that is ETSI NFV compliant.  OpenBaton was
      part of the OpenSDNCore project started with the objective of
      providing a compliant implementation of the ETSI NFV
      specification.

   o  ONAP.  Open Network Automation Platform (ONAP) is an open-source
      software platform that delivers capabilities for the design,
      creation, orchestration, monitoring, and life-cycle management of
      (i) Virtual Network Functions (VNFs), (ii) The carrier-scale
      Software-Defined Networks (SDNs) that contain them, and (iii)
      higher-level services that combine the above.  ONAP (derived from
      the AT&T's ECOMP) provides for automatic, policy-driven
      interaction of these functions and services in a dynamic, real-
      time cloud environment.

   o  SONA.  The Simplified Overlay Network Architecture (SONA) is an
      extension to ONOS to have an almost full SDN network control in
      OpenStack for virtual tenant network provisioning.  Basically,
      SONA is an SDN-based network virtualization solution for cloud DC.

   Among the main areas that are being developed by the aforementioned
   open-source activities that relate to network virtualization
   research, we can highlight policy-based resource management,
   analytics for visibility and orchestration, and service verification
   with regard to security and resiliency.


Next Section