RFC 8568
Network Virtualization Research Challenges
Pages: 42
Informational
Informational
Part 1 of 3 – Pages 1 to 17
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 ChallengesAbstract
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).
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.
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
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.
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.
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.
+-------------------------------------------+ +---------------+ | 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
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
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.
+----------+ | ------- | | |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
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).
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].
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.
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
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.
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
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 page on part 2)