RFC 8568
Network Virtualization Research Challenges
RFC 8568: Network Virtualization Research Challenges 🦋
okay bestie, let's get the vibe check done first 💅 this is a super nerdy IRTF doc, so here's the who-dunnit:
- RFC number: 8568
- Title: Network Virtualization Research Challenges
- Stream: Internet Research Task Force (IRTF) 🌈
- Category: Informational (so not a Standards Track spec, just vibes and research 🧠)
- ISSN: 2070-1721
- Date: April 2019
- Authors: CJ. Bernardos (UC3M), A. Rahman (InterDigital), JC. Zuniga (SIGFOX), LM. Contreras (TID), P. Aranda (UC3M), P. Lynch (Keysight Technologies) 👩💻
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🙌
Abstract 💖
okay so this doc is all about open research challenges in network virtualization 🔥 and honestly it's giving cloud computing glow-up. Cloud computing made it iconic to move apps and storage off local, dedicated hardware and onto remote virtual stuff you reach over the Internet ☁️. Network virtualization is doing the same thing for networking functions, moving them off dedicated physical boxes and into a virtualized pool of resources 🦋.
Here's the plot twist though: network virtualization is lowkey harder than cloud computing, because it's not just virtualizing compute and storage, it's also abstracting the network itself 🙈.
The doc covers the current research and engineering challenges, like guaranteeing 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. It also suggests some new activities the IETF and IRTF could take on to tackle 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's published for informational purposes 🎀.
It's a product of the Internet Research Task Force (IRTF), which publishes results of Internet-related research and development work 🔬. Those results might not be suitable for deployment, so be careful 👀. This RFC represents the consensus of the Network Function Virtualization Research Group of the IRTF. Documents approved for publication by the IRSG are not candidates for any level of Internet Standard, see Section 2 of RFC 7841 💅.
Info about the current status of this doc, any errata, and how to send feedback can be found 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) as they stand on the date of publication. Read those carefully, bestie, because they spell out your rights and restrictions for 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 . . . . . . . . . . . . . . . . . . . . . . . 411. Introduction and Scope 🌟
The telecom sector is in the middle of a MAJOR revolution 💅 and it's going to shape how networks and services get designed and deployed for the next few decades. To keep up with demand and cost that keep climbing, network operators are copying the cloud computing playbook from IT 📈. This virtualize-your-network-functions move is going to unlock multi-fold advantages by shifting services from bespoke hardware in the operator's core network onto Commercial Off-The-Shelf (COTS) equipment spread across data centers 🏢.
Some of the network virtualization ideas being considered are: sharing network infrastructure to cut costs 💸, virtualizing core and edge servers and services running in data centers so they can scale elastically based on load 📊, and dynamic energy policies to bring down electricity consumption ⚡.
This document lays out the research and engineering challenges that need to be tackled to actually hit these goals 🎯. It spans everything from pure research all the way to the engineering and standards side. The main objective is to document the technical challenges, the current approaches to them, and the requirements that future research and standards work should address 🫶.
This document represents the consensus of the Network Function Virtualization Research Group (NFVRG) ✨. It has also been reviewed by the RG members who are active in the specific areas the document covers 👀.
2. Terminology 📖
okay so these terms 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], and we're gonna use them the same way here 🧠:
- Application Plane: the squad of applications and services that program how the network behaves 🎀.
- Control Plane (CP): the group of functions in charge of controlling one or more network devices 🎮. The CP tells network devices how to process and forward packets. It mostly talks to the forwarding plane and, to a lesser extent, to the operational plane 💬.
- Forwarding Plane (FP): all the resources across every network device that are responsible for forwarding traffic 🚚.
- Management Plane (MP): the functions that monitor, configure, and maintain one or more network devices, or parts of them 🛠️. The management plane is mostly tied to the operational plane, and much less to the forwarding plane 🙃.
- NFV Infrastructure (NFVI): the whole pile of hardware and software components that make up the environment where VNFs get deployed 🏗️.
- NFV Management and Orchestration (NFV-MANO): functions that are collectively provided by NFVO, VNFM, and VIM 🎶.
- NFV Orchestrator (NFVO): the functional block that manages the Network Service (NS) life cycle. It coordinates the NS life cycle, the VNF life cycle (supported by the VNFM), and NFVI resources (supported by the VIM), so that the necessary resources and connectivity get allocated in an optimized way 🧩.
- Operational Plane (OP): the resources responsible for managing the overall operation of individual network devices 🔧.
- Physical Network Function (PNF): a physical implementation of a network function in a monolithic realization 🧱.
- Service Function Chain (SFC): for a given service, the abstract view of the service functions it needs and the order they should be applied in 🔗. This is somehow equivalent to the Network Function Forwarding Graph (NF-FG) at ETSI 🤝.
- Service Function Path (SFP): picking specific service function instances on specific network nodes to build the service graph that an SFC gets instantiated through 🗺️.
- Virtualized Infrastructure Manager (VIM): the functional block responsible for controlling and managing the NFVI compute, storage, and network resources, usually inside one infrastructure operator's domain 👑.
- Virtualized Network Function (VNF): an implementation of a Network Function that can be deployed on a Network Function Virtualization Infrastructure (NFVI) 💜.
- Virtualized Network Function Manager (VNFM): the functional block responsible for the life-cycle management of VNF 🌸.
3. Background 🌈
This section gives a quick rundown of some basic background technologies, plus other Standards Developing Organizations (SDOs) and open-source initiatives that are working on network virtualization or related topics 🧚♀️.
3.1. Network Function Virtualization
okay so bestie, this section is about NFV, which is basically the big idea of ditching a pile of specialised network boxes and just running the network functions as software on normal industry-standard high-volume servers, switches, and storage 🖥️✨ since 2012, the ETSI ISG Network Function Virtualization (NFV) working group has been making this a real thing, and honestly it's giving "consolidate everything, no new hardware needed" 💅 the software can run on a range of industry-standard server hardware and can be moved to, or loaded in, different spots in the network whenever it's needed 🦋 no cap, that's the whole glow-up. The ETSI NFV is one of the predominant NFV reference frameworks and architectural footprints [nfv_sota_research_challenges] 👑 and its architecture is made of three domains (Figure 1):
- Virtualized Network Function, running over the NFVI. 🌸
- NFVI, which covers the diversity of physical resources and how they can be virtualised. NFVI supports the execution of the VNFs. 🫶
- NFV Management and Orchestration, which handles the orchestration and life-cycle management of the physical and/or software resources that support the infrastructure virtualisation, plus the life-cycle management of VNFs. It focuses on all the virtualisation-specific management tasks needed 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 FrameworkThe NFV architectural framework identifies functional blocks and the main reference points between those blocks 🧚 some of these already show up in current deployments, whilst others might be necessary additions to support the virtualisation process and the operation that comes with it ✨ The functional blocks are (Figure 2):
- Virtualized Network Function (VNF) 🎀
- Element Management (EM) 🌈
- NFV Infrastructure, including: Hardware and virtualized resources as well as the Virtualization Layer.
- Virtualized Infrastructure Manager(s) (VIM) 💖
- NFV Orchestrator ⭐
- VNF Manager(s) 🍓
- Service, VNF and Infrastructure Description
- 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 🦋✨
okay so bestie, SDN is literally the vibe of the networking world rn 💅 The whole idea is that the smart stuff that usually lives inside every single network box gets pulled out and moved into one central controller that runs the network through software 🧠✨ Like, in the old school way, the control plane is spread across every device, but with SDN it's logically centralized 🎀 So when you want a new feature on the network, you don't have to do the messy, expensive hardware swaps or firmware updates. You just change the software on the controller 💖 The biggest slay here is flexibility for operators, because they can easily change their policies on how traffic gets spread around the network 🌈🔥
One of the most famous protocols for talking between the central controller and the networking elements is the OpenFlow Protocol (OFP) 👑 It's maintained and extended by the Open Network Foundation (ONF) <https://www.opennetworking.org/> 🫶 Originally, OFP was built specifically for IEEE 802.1 switches that follow the ONF OpenFlow Switch specification [OpenFlow] 🍓 But the SDN paradigm got so popular that people wanted it for more complicated stuff too, like wireless and mobile networks 📱💜 Right now the ONF is actively developing new OFP extensions for three key scenarios: (i) wireless backhaul, (ii) cellular Evolved Packet Core (EPC), and (iii) unified access and management across enterprise wireless and fixed networks ⭐
Here's the picture of the ONF architecture, Figure 3 🧚
+----------+
| ------- |
| |Oper.| | O
| |Mgmt.| |<........> -+- Network Operator
| |Iface| | ^
| ------- | +----------------------------------------+
| | | +------------------------------------+ |
| | | | --------- --------- --------- | |
| | | | | App 1 | | App 2 | ... | App n | | |
| | | | --------- --------- --------- | |
| | | | 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 functional interfaces of the ONF architecture, and it has three planes: data, controller, and application 🎀 The data plane has several Network Entities (NEs) that expose their capabilities up to the control plane through a Southbound API 💅 The control plane has a bunch of cooperating modules whose whole job is creating and maintaining an abstracted resource model of the underlying network ✨ That model gets exposed to the applications through a Northbound API, and the application plane holds several applications/services, each with exclusive control over a set of exposed resources 👑
The management plane is the main character across all the planes 🦋 It handles the initial configuration of the network elements in the data plane, plus assigning the SDN controller and the resources it's responsible for 🫶 In the control plane, management has to configure the policies that define how much control the SDN applications get, monitor how the system is performing, and configure the parameters the SDN controller modules need 🌸 In the application plane, management configures the parameters of the applications and the service-level agreements 💜 On top of all that, management exposes a bunch of functions that let network operators configure and tune the network at each layer, easily and quickly ⭐
So RFC 7426 [RFC7426] is where the IRTF Software-Defined Networking Research Group (SDNRG) wrote down a layer model of an SDN architecture 📚 Honestly it was needed because there was a lot of controversial discussion going on, like: What exactly is SDN? What is the layer structure of the SDN architecture? How do the layers interface with each other? 😭
Figure 4 is a copy of the figure from RFC 7426 [RFC7426], and it sums up the SDN architecture abstractions in a detailed, high-level schematic 🧚 In a real implementation, planes can be collocated with other planes or physically separated, totally up to whoever is building it 🌈
In SDN, a controller manipulates controlled entities through an interface 🎀 When the interface is local, it's mostly API invocations through some library or system call 💖 But those interfaces can also be extended with some protocol definition, which may use local interprocess communication (IPC) or a protocol that can also act remotely 🔥 That protocol can be an open standard or proprietary, either way 💅
SDN spans multiple planes: forwarding, operational, control, management, and application 🦋 All the planes mentioned above are connected through interfaces ✨ RFC 7426 [RFC7426] also 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
Now, while SDN is often directly associated with OpenFlow, that's just one (relevant!) example of a southbound protocol between the central controller and the network entities 🫶 Other relevant examples in the SDN family are NETCONF [RFC6241], RESTCONF [RFC8040], and ForCES [RFC5810] 🌈✨
3.3. ITU-T Functional Architecture of SDN 🌸
okay so the ITU-T (the Telecommunication standardization sector of the International Telecommunication Union 💅) went its own way with SDN architectures. It's a slightly modified version compared to what other SDOs have done 👀. In ITU-T recommendation Y.3302 [itu-t-y.3302], they give us a functional architecture of SDN, with descriptions of functional components and reference points 🧩. It's meant as an enabler for further studies on other stuff like protocols and security, and also for customizing SDN for use cases like cloud computing and mobile networks ☁️📱. This recommendation is based on ITU-T Y.3300 [itu-t-y.3300] and ITU-T Y.3301 [itu-t-y.3301]. The first one covers the framework of SDN (definitions, objectives, high-level capabilities, requirements, and the high-level architecture), and the second one gets into more-detailed requirements 📝.
Figure 5 shows the SDN functional architecture defined by the ITU-T 🖼️. It's a layered architecture made of the SDN application layer (SDN-AL), the SDN control layer (SDN-CL), and the SDN resource layer (SDN-RL). There are also multi-layer management functions (MMF) that let you manage the functionalities of those layers, aka SDN-AL, SDN-CL, and SDN-RL. MMF talks to these layers through the Multi-layer Management Functions Application (MMFA), Multi-layer Management Functions Control (MMFC), and Multi-layer Management Functions Resource (MMFR) reference points 🧚.
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 LayerFigure 5: ITU-T SDN Functional Architecture ✨
The SDN-AL makes the underlying network service-aware in a programmatic way 💜. The SDN-CL gives you programmable means to control SDN-RL resources (like data transport and processing), following the requests it gets from the SDN-AL and the MMF policies 🎀. The SDN-RL is the place where the physical or virtual network elements actually transport and/or process data packets, following the SDN-CL's decisions 🫶.
3.4. Multi-Access Edge Computing 🌈
Multi-access Edge Computing (MEC), formerly known as Mobile Edge Computing, is about capabilities deployed at the edge of the mobile network so services can be provided to mobile users efficiently and dynamically 📱✨. The ETSI ISG MEC working group, operative from the end of 2014, intends to specify an open environment for integrating MEC capabilities with service providers' networks, including applications from third parties 🦋. These distributed computing capabilities give you IT infrastructure like a cloud environment, for deploying functions in mobile access networks ☁️. So honestly, it can be seen 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, using technologies based on the family of IEEE 802 Standards (like 802.3 Ethernet, 802.11 Wi-Fi, etc.) 🌐. The spec defines an access network reference model, including entities and reference points, plus behavioral and functional descriptions of communications among those entities 📋.
The goal of this project is to help unify support for different interfaces, enabling shared-network control and use of SDN principles 🔥. That means lower barriers for new network technologies, new network operators, and 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 🤝. It's involved in creating and adopting interoperable management standards, supporting implementations that manage diverse traditional and emerging technologies, including cloud, virtualization, network, and infrastructure ☁️.
There are several DMTF initiatives relevant to the network virtualization area 🌸. There's 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 🖥️. Main character energy, honestly 👑.
3.7. Open-Source Initiatives ✨
okay so the open-source crowd is ABSOLUTELY obsessed with network virtualization and orchestration 🫶 here's the lineup of the projects that are giving main character energy right now:
- OpenStack 🏠 is a free and open-source cloud-computing software platform. It controls huge pools of compute, storage, and networking resources across a whole data center, and you manage it through a dashboard or the OpenStack API.
- Kubernetes 🚢 is an open-source system for automating the deployment, scaling and management of containerized applications. It 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. iconic, honestly 💅
- OpenDayLight 🌈 (ODL) is a highly available, modular, extensible and scalable multiprotocol controller infrastructure built for SDN deployments on modern heterogeneous multi-vendor networks. It gives you a model-driven service abstraction platform, so users can write apps that easily work across a wide variety of hardware and southbound protocols. 🦋
- ONOS 👑 (The Open Network Operating System) is an open-source community hosted by The Linux Foundation. Its goal is to create an SDN operating system for communications service providers that is designed for scalability, high performance, and high availability.
- OpenContrail 🌸 is a licensed Apache 2.0 project built using standards-based protocols. It provides all the necessary components for network virtualization: an SDN controller, a virtual router, an analytics engine, and published northbound APIs. It also has an extensive Representational State Transfer (REST) API to configure and gather operational and analytics data from the system. the way that's so complete 😭
- OPNFV 🧚 (The Open Platform for NFV) is a carrier-grade, integrated, open-source platform that accelerates 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 make sure the platform is suitable for NFV use cases. Its 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. 💜
- OSM 🍓 (Open Source Mano) is an ETSI-hosted project to develop an Open Source NFV Management and Orchestration (MANO) software stack aligned with ETSI NFV. It's built on components from previous projects, such Telefonica's OpenMANO or Canonical's Juju, among others.
- OpenBaton 🎀 is a Network Function Virtualization Orchestrator (NFVO) that is ETSI NFV compliant. It was part of the OpenSDNCore project, which started with the objective of providing a compliant implementation of the ETSI NFV specification.
- ONAP 💀 (Open Network Automation Platform) 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. ate.
- SONA 🦋 (The Simplified Overlay Network Architecture) is an extension to ONOS that gives 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 being developed by these 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. 🔥
4. Network Virtualization Challenges 💅
4.1. Overview
Okay bestie, network virtualization is changing the way the telecommunications sector will deploy, extend, and operate their networks 🌸 The goal is to reduce overall costs by moving communication services from specific hardware in the operators' cores to server farms scattered in data centers (i.e., compute and storage virtualization). On top of that, the networks interconnecting the functions that make up a network service are fundamentally affected in the way they route, process, and control traffic (i.e., network virtualization). it's a whole glow-up 🦋
4.2. Guaranteeing Quality of Service
Getting a given QoS in an NFV environment with virtualized and distributed computing, storage, and networking functions is way more challenging than doing the same with discrete non-virtualized components 😭 For example, guaranteeing a stable forwarding data rate has proven not to be straightforward when the forwarding function is virtualized and runs on top of COTS server hardware [openmano_dataplane] [NFV-COTS] [etsi_nfv_whitepaper_3]. Again, the comparison point is against a router or forwarder built on optimized hardware. Here are some of the challenges that this poses 🙈
4.2.1. Virtualization Technologies
The issue of guaranteeing network QoS is less of an issue for "traditional" cloud computing, because the workloads there are servers or clients in the networking sense and hardly ever process packets. Cloud computing hosts applications on shared servers in a highly separated way. Its main advantage is that infrastructure costs are shared among tenants, and the cloud infrastructure provides levels of reliability that can not be achieved on individual premises in a cost-efficient way [intel_10_differences_nfv_cloud]. NFV, though, has very strict requirements in terms of performance, stability, and consistency. There are some tools and mechanisms to improve this, such as Enhanced Performance Awareness (EPA), Single Root I/O Virtualization (SR-IOV), Non-Uniform Memory Access (NUMA), Data Plane Development Kit (DPDK), etc., but these are still unsolved challenges. One open research issue is finding technologies that are different from Virtual Machines (VMs) and more suitable for dealing with network functionalities. 🧚
Lately, a number of lightweight virtualization technologies have appeared as options for constructing an NFV platform, including containers, unikernels (specialized VMs) and minimalistic distributions of general-purpose OSes. [LIGHT-NFV] describes the challenges in building such a platform and discusses to what extent these technologies, as well as traditional VMs, are able to address them. ✨
4.2.2. Metrics for NFV Characterization
Another relevant aspect is the need for diagnostic and measurement tools suited for NFV. There is a pressing need to define metrics and associated protocols to measure the performance of NFV. Since NFV is based on taking centralized functions and evolving them into highly distributed software (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 and UDP) over IP. It also develops and maintains protocols for measuring these metrics. The IPPM WG is a long-running WG that started in 1997, but at the time of writing, it does not have a charter item or active Internet-Drafts related to network virtualization. In addition to using IPPM to evaluate QoS, there is a need for specific metrics for assessing the performance of network-virtualization techniques. 🌈
The Benchmarking Methodology Working Group (BMWG) is also doing work related to NFV metrics. For example, [RFC8172] investigates additional methodological considerations needed when benchmarking VNFs that are instantiated and hosted in general-purpose hardware, using bare-metal hypervisors or other isolation environments (such as Linux containers). An essential consideration is benchmarking physical and VNFs in the same way when possible, so you can compare them directly. 🎀
There is a clear motivation for the work on performance metrics for NFV [etsi_gs_nfv_per_001], as stated in [RFC8172] (and replicated here):
I'm designing and building my NFV Infrastructure platform. The first steps were easy because I had a small number of categories of VNFs to support and the VNF vendor gave HW recommendations that I followed. Now I need to deploy more VNFs from new vendors, and there are different hardware recommendations. How well will the new VNFs perform on my existing hardware? Which among several new VNFs in a given category are most efficient in terms of capacity they deliver? And, when I operate multiple categories of VNFs (and PNFs) concurrently on a hardware platform such that they share resources, what are the new performance limits, and what are the software design choices I can make to optimize my chosen hardware platform? Conversely, what hardware platform upgrades should I pursue to increase the capacity of these concurrently operating VNFs? 🙋
Lately, there are also some efforts looking into VNF benchmarking. Selecting an NFV Infrastructure Point of Presence to host a VNF, or allocating resources (e.g., virtual CPUs, memory), needs to be done over virtualized (abstracted and simplified) resource views [vnf_benchmarking] [VNF-VBAAS]. 💜
4.2.3. Predictive Analysis
On top of diagnostic tools that enable an assessment of QoS, predictive analyses are required to react before anomalies occur. Because VNFs are software, a reliable diagnosis framework could potentially prevent issues through proper diagnosis, followed by a reaction that acts on the potentially impacted service (e.g., migration to a different compute node, scaling in/out, up/down, etc.). 🔮
4.2.4. Portability 🎀
okay so portability in NFV basically means running a given VNF on multiple NFVIs and making sure it can still do its job with high and predictable performance 💖, as long as a set of requirements on the NFVI resources is met ✨. That's why it's a key feature: if it's fully enabled, the NFV environment could reach a better reliability than a traditional system 🔥. Building functions in software over "commodity" infrastructure should make it way easier to port or move them from one place to another 🧚. BUT ngl, it's not as ideal as it sounds yet, and some aspects aren't fully tackled 💀. Different hypervisors, specific hardware dependencies (e.g., EPA related), and state-synchronization aspects are just some of the troublemakers for portability 🙈.
The ETSI NFV ISG is doing work on portability too 🫶. [etsi_gs_nfv_per_001] gives a list of minimal features that the VM Descriptor and Compute Host Descriptor should contain, so VM images can be deployed properly over an NFVI (a "telco data center") 🌸. The goal is high, predictable performance for data-plane workloads while still keeping things portable 💅. It also offers recommendations on the minimum requirements that hardware (HW) and hypervisor should have for a "telco data center" suited to different workloads (data plane, control plane, etc.) found in VNFs 🖥️. In short, the purpose is to list the VM requirements that belong in the VM Descriptor template, plus the HW capabilities that belong in the Compute Host Descriptor (CHD), so predictable high performance is assured 🔥. ETSI NFV assumes the MANO functions will do the mix & match 👑. So yeah, there are still several research challenges to tackle here 😭.
4.3. Performance Improvement 🚀
4.3.1. Energy Efficiency 🔋
Virtualization is typically seen as a direct enabler of energy savings 💚. Some enablers that get mentioned a lot [nfv_sota_research_challenges] are (i) the multiplexing gains from centralizing functions in data centers, which reduce the overall energy consumed, and (ii) the flexibility of network programmability, which makes it much easier to switch off infrastructure as needed 🌈. Still, there's a lot of room to improve virtualization techniques for cutting power consumption, such as enhanced-hypervisor technologies 💜.
Some additional research topics that could enable energy savings are [nfv_sota_research_challenges]:
- Energy-aware scaling (e.g., reductions in CPU speeds and partially turning off some hardware components to meet a given energy consumption target.
- Energy-aware function placement.
- Scheduling and chaining algorithms, for example, adapting the network topology and operating parameters to minimize the operation cost (e.g., tracking energy costs to identify the cheapest prices).
Note that it's also important to analyze the trade-off between energy efficiency and network performance ⚖️.
4.3.2. Improved Link Usage 🛣️
NFV and SDN technologies can help improve link usage 💫. SDN has already shown it can greatly increase average link utilization (e.g., Google example [google_sdn_wan]) 🌟. NFV adds more complexity (e.g., due to service-function chaining / VNF forwarding graphs), and that needs to be considered 🧩. Aspects like the ones described in [NFVRG-TOPO] (on NFV data center topology design) also have to be looked at carefully 👀.
4.4. Multiple Domains 🌍
Market fragmentation has resulted in a whole bunch of network operators, each focused on different countries and regions 🗺️. That makes it hard to create infrastructure services spanning multiple countries, like virtual connectivity or compute resources, since no single operator has a footprint everywhere 😩. Cross-domain orchestration of services over multiple administrations, or over multi-domain single administrations, will let end-to-end network and service elements mix across multi-vendor, heterogeneous technology and resource environments [multi-domain_5GEx] 🤝.
For the specific use case of 'Network as a Service', it becomes even more important to make sure Cross Domain Orchestration also takes care of the hierarchy of networks and their association, with respect to provisioning tunnels and overlays 🎯.
Multi-domain orchestration is currently an active research topic, being tackled by the ETSI NFV ISG and the 5GEx project <https://www.5gex.eu/>, among others [MULTI-NMRG] [multi-domain_5GEx] 🔬.
Another side of the multi-domain problem is the integration/harmonization of different management domains 🧩. A key example comes from Multi-access Edge Computing, which, according to ETSI, comes with its own MANO system and would need integration if interconnected to a generic NFV system 🌐.
4.5. 5G and Network Slicing 📡
From the very beginning of all the 5G discussions in research and industry fora, it was agreed that 5G would have to handle way more use cases than the earlier wireless generations, which first focused on voice and then on voice plus high-speed packet data 📱. 5G should handle not only the same (or enhanced) voice and packet data services, but also emerging stuff like the tactile Internet and the Internet of Things (IoT) 🤖. These use cases pull the requirements to opposite extremes: some need ultra-low latency and higher speed, while others need ultra-low power and high delay tolerance 😵.
Because of these super extreme 5G use cases, it's envisioned that selective combinations of radio access networks and core network components will have to be combined into a given network slice to address the specific requirements of each use case 🍰.
For example, within the major IoT category (perhaps the most disrupting one), some autonomous IoT devices will have very low throughput, much longer sleep cycles (and therefore high latency), and a battery life exceeding by a factor of thousands that of smartphones or other devices with almost continuous control and data communications 🔋. So a customized network slice will have to be stitched together from virtual resources or sub-slices to meet these requirements 🧵.
The actual definition of a "network slice" from an IP infrastructure viewpoint is currently undergoing intense debate; see [COMS-PS], [NETSLICES], [SLICE-3GPP], and [ngmn_5G_whitepaper] 🥊. Network slicing is a key for introducing new actors into existing markets at a low cost -- by letting new players rent "blocks" of capacity, if the new business model enables performance that meets the application needs (e.g., broadcasting updates to many sensors with satellite broadcasting capabilities) 🛰️. However, more work is needed to define the basic architectural approach of how network slices will be defined and formed 🏗️. For example, is it mostly a matter of defining the appropriate network models (e.g., YANG) to stitch the network slice from existing components? Or do end-to-end timing, synchronization, and other low-level requirements mean more fundamental research has to be done? 🤔
4.5.1. Virtual Network Operators 🏢
The widespread use, discussion, and practice of system and network virtualization technologies has led to new business opportunities, enlarging the offer of IT resources with virtual network and computing resources, among others 💼. As a result, the network ecosystem now differentiates between the owner of physical resources, the Infrastructure Provider (InP), and the intermediary that conforms and delivers network services to final customers, the Virtual Network Operator (VNO) 🧾.
VNOs aim to exploit virtualized infrastructures to deliver new-and-improved services 🚀. But current network virtualization techniques offer poor support for VNOs to control their resources 😤. It's been considered that the InP is responsible for the reliability of virtual resources, but there are several situations where a VNO needs finer control over its resources 🎛️. Dynamic events, like the identification of new requirements or the detection of incidents within the virtual system, might urge a VNO to quickly reform its virtual infrastructure and resource allocation 🌪️. However, the interfaces offered by current virtualization platforms don't provide the functions VNOs need to make the elastic adaptations they require in dynamic environments 🙅♀️.
Beyond their heterogeneity (which software adapters can resolve), current virtualization platforms don't have common methods and functions, so it's difficult for the virtual network controllers used by VNOs to manage and control virtual resources instantiated on different platforms, not even considering different InPs 🥴. So it's necessary to agree on a common definition of the functions that underlying platforms should offer, so overlay controllers can allocate and deallocate resources dynamically and get monitoring data about them 📊.
Such common methods should be offered by all underlying controllers, whether network-oriented (e.g., ODL, ONOS, and Ryu) or computing-oriented (e.g., OpenStack, OpenNebula, and Eucalyptus) 🖥️. It's also important for those platforms to offer a "PUSH" function to report resource state, so the VNO's controller doesn't have to "POLL" for that data 🔔. A starting point for proper notifications within current REST APIs could be the protocol proposed by the WEBPUSH WG [RFC8030] 💌.
Finally, to establish a proper order and allow different systems to coexist and collaborate, a common ontology regarding network and system virtualization should be defined and agreed upon 📚. That way, heterogeneous systems can understand each other without relying on specific adaptation mechanisms that might break with any update on either side of the relation 💖.
4.5.2. Extending Virtual Networks and Systems to the Internet of Things 🦋
okay so the Internet of Things (IoT) 🌸 is basically the vision of hooking a whole crowd of automated devices (think lights, environmental sensors, traffic lights, parking meters, health and security systems, etc.) up to the Internet so they can report stuff and get remote command and control. ✨ this vision is coming together through a multi-pronged approach: standardization across different forums, plus complementary open-source activities. for example, in the IETF, IoT web services got 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, everyone is talking about the need for 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 these devices will have very different characteristics than typical cellular devices like smartphones [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 (see Section 4.5). that's a LOT of things, bestie 😭.
the specific nature of the IoT ecosystem, especially in Machine-to-Machine (M2M) communications, leads to the creation of new and highly distributed systems that demand location-based network and computing services. 🌍 a super specific example is a set of "things" that suddenly need a firewall set up so external entities can access their data, while outsourcing some computation to more powerful systems running cloud-based services ☁️. this representative use case exposes important requirements for both NFV and the underlying cloud infrastructures. not me noticing how much this touches everything 💀.
to provide those location-based functions integrated with highly distributed systems, the so-called fog infrastructures should be able to instantiate VNFs and place them where they're needed, e.g., close to their consumers 🌫️. this means the interfaces offered by virtualization platforms must support the specification of location-based resources, which is a key function in these scenarios. 📍 those platforms must also be able to interpret and understand the references IoT systems use for their location (e.g., My-AP or 5BLDG+2F), plus the specification of identifiers linked to other resources. like, the infrastructure may need to establish a link between a specific Access Point (AP) and a specific virtual computing node 🔗. in summary, the research gap is exact localization of VNFs at far network edge infrastructure, which is highly distributed and dynamic. the edge is giving chaotic and I'm here for it 🙈✨.
4.6. Service Composition 🧩
current network services deployed by operators often involve composing several individual functions (such as packet filtering, deep-packet inspection, load-balancing) 🔥. these services are typically built by ordering a bunch of service functions that are deployed at different points in a network, not necessarily on the direct data path. so traffic has to be steered through the required service functions, wherever they happen to be deployed [RFC7498] 🚦.
for a given service, the abstracted view of the required service functions and the order they're applied in is called "Service Function Chaining" (SFC) [sfc_challenges]. ETSI calls the same idea "Network Function Forwarding Graph" (NF-FG) 💅. SFC gets instantiated by selecting specific service function instances on specific network nodes to form a service graph, and 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 seriously powerful tool that can provide big benefits when applied in a softwarized network environment ⭐. but there are a lot of research challenges here. for example, the ones related to composition mechanisms and algorithms that enable load-balancing and improve reliability 🌈. service composition should also act as an enabler that gathers information across all hierarchies (underlays and overlays) of network deployments, which may span multiple operators, for faster serviceability. that helps with accomplishing the aforementioned goals of "load-balancing and improving reliability" 🫶.
as described in [dynamic_chaining], different algorithms can be used for dynamic service composition that optimizes a QoS-based utility function (e.g., minimizing the latency per-application traffic flows) for a given composition plan 📊. these algorithms can consider the computation capabilities and load status of the resources running the VNF instances. that info is either deduced through estimations from historical usage data or collected through real-time monitoring (i.e., context-aware selection) 👀. for this reason, selections should include references to dynamic information on the status of the service instance and its constituent elements. that means monitoring information related to individual VNF instances and the links connecting them, plus derived monitoring information at the chain level (e.g., end-to-end delay) ⏱️. at runtime, if one or more VNF instances are no longer available, or QoS degrades below a given threshold, the service selection task can be rerun to perform service substitution. swap it out, no drama 🔄💖.
there are different research directions related to the previous point. for example, Integer Linear Programming (ILP) techniques can be explored to optimize the management of diverse traffic flows 🧮. deep-machine learning can also be applied to optimize service chains using information parameters, such as some of the ones mentioned above 🤖. newer scheduling paradigms, like co-flows, can also be used 🗓️.
the SFC working group is working on an architecture for SFC [RFC7665]. it includes the necessary protocols or protocol extensions to convey the SFC and SFP information to the nodes involved in implementing service functions and SFCs, plus mechanisms for steering traffic through service functions 🏗️.
in terms of actual work items, the SFC WG has not yet considered working on the management and configuration of SFC components related to supporting SFC. this part is of special interest for operators, and it would be required to actually put SFC mechanisms into operation. it's giving unfinished business 😤. similarly, redundancy and reliability mechanisms for SFC are currently not dealt with by any WG in the IETF. the VNFpool BoF efforts were supposed to handle this, and it still remains unaddressed 🥺💔.
4.7. Device Virtualization for End Users 📱💜
so far, most network softwarization efforts have focused on virtualizing functions of network elements 💻. virtualization of network elements started with the core, and mobile-network architectures are now heavily switching to virtualize Radio Access Network (RAN) functions too 📡. the next natural step is to get virtualization down to the level of the end-user device (e.g., virtualizing a smartphone) [virtualization_mobile_device] 🪞. cloning a device in the cloud (central or local) has attractive benefits for both the device and network operations. for example, the device can save power by offloading computation-heavy functions to the cloud, and networking can be optimized, both device-to-device and device-to-infrastructure. that makes service delivery tighter through integration of the device with its clone in the networking infrastructure 🫧. this is, for example, being explored by the European H2020 ICIRRUS project <https://www.icirrus-5gnet.eu> 🌟. the future is literally a clone of you in the cloud and I am not okay about it 😭✨.
4.8. Security and Privacy 🔒✨
okay so security and privacy are literally the two big things to think about whenever resources get shared, bestie 🫶 same story as always, just with more main character energy 💅
security first 🛡️. there are situations where multiple service providers have to coexist in a virtual or hybrid physical/virtual environment, and that needs attestation procedures between the different virtual/physical functions and resources, plus ongoing external monitoring 👀. and get this, different network slices running on the same infrastructure can cause security problems too 😭. imagine one slice running something critical (say, support for a safety system) getting messed with by another slice running something less critical. yikes 💀. in general, the minimum common denominator for security on a shared system should be equal to or higher than what the most-critical application needs 🔐. and to keep a certain level of security in an NFV system, you need multiple and continuous threat model analysis plus a DevOps model, no cap 🔥.
quick DevOps tea 🍵 (simplistically): it's a process that squishes multiple functions into single cohesive teams so you can quickly produce quality software. it usually also leans on Agile, which is all about (among many things) chopping big features into multiple, smaller deliveries 🍰. part of that is testing the new smaller features right away so you get immediate feedback on errors, and if there are any, they can be fixed and redeployed super fast 🏃♀️💨
now privacy 🙈. this is about controlling personal data and deciding what you reveal to whom 🫣. in an NFV system, storing, transmitting, collecting, and potentially correlating info for purposes that weren't originally intended or known to the user should be avoided 🚫. this is honestly so hard bc nobody can predict future intentions and threats super well, and they can still get applied to data that was collected in the past 😩. so well-known techniques should be used to prevent privacy issues, like data minimization, privacy features as the default, and letting users opt in/out 🌸💜.
NFV is way more dynamic (in function distribution and topology) and elastic (in size and boundaries) than traditional networks 🌈. so network operators will need to evolve their operational and administrative security solutions to work in this new world 🧚. for example, the network orchestrator becomes a key node for security policy orchestration across the different physical and virtual components of the virtualized network 👑. and for highly confidential data, the orchestrator should take into account whether certain physical HW is considered more secure (e.g., because it's located in secure premises) than other HW 🗝️.
admin domains time 🏰. traditional telecom networks usually run under a single administrative domain controlled by (exactly) one operator. with NFV, the telecom operator will often become a tenant running the VNFs, while the infrastructure (NFVI) may be run by a different operator and/or cloud service provider (see also Section 4.4) ☁️. so there are multiple administrative domains involved, and security policy coordination gets more complex 😵💫. who's in charge of provisioning and maintaining security credentials like public and private keys? 🔑 and should private keys be allowed to be replicated across the NFV for redundancy reasons? 🤔 alternatively, it can be investigated how to develop a mechanism that avoids that security policy coordination, which would make the system more robust 💪.
positive note 🌟: NFV may better defend against denial-of-service (DoS) attacks because the network is distributed (no single point of failure) and it can steer (undesirable) traffic quickly [etsi_gs_nfv_sec_001] 🛡️. also, NFVs with physical HW distributed across multiple data centers provide better fault isolation environments 🧩. this especially holds true if each data center is protected separately via firewalls, Demilitarized Zones (DMZs), and other network-protection techniques 🔥.
SDN can help security too 🦋 by facilitating the operation of existing protocols, like Authentication, Authorization and Accounting (AAA). managing AAA infrastructures (AAA routing and establishing security associations between AAA entities) can be performed using SDN, as analyzed in [SDN-AAA] ✨.
4.9. Separation of Control Concerns 🎀
NFV environments offer two possible levels of SDN control 🎛️. level one is controlling the NFVI to provide connectivity end-to-end among VNFs or among VNFs and Physical Network Functions (PNFs) 🛣️. level two is controlling and configuring the VNFs themselves (aka configuring the network service those VNFs implement), taking advantage of the programmability SDN brings 🧠. both control concerns are separated in nature, but interaction between them could be expected in order to optimize, scale, or influence each other 🤝.
clear mechanisms for those interactions are needed to avoid malfunctioning or interference concerns 🚧. these ideas are considered in [etsi_gs_nfv_eve005] and [LAYERED-SDN] 📚.
4.10. Network Function Placement 📍
network function placement is a problem in any telecom infrastructure 🗺️. and the extra freedom network virtualization adds makes it even more important and even harder to tackle 😤. deciding where VNFs go is a resource-allocation problem that needs to (or may) consider quite a few aspects: resiliency, (anti-)affinity, security, privacy, energy efficiency, etc 🌿.
when several functions are chained (the typical scenario), placement algorithms get more complex and more important (as described in Section 4.6) 🔗. there's been research on the topic ([nfv_piecing], [dynamic_placement], and [vnf-p]), but this is still an open challenge that needs more attention 🙏. and the use of multi-domains adds another component of complexity that has to be considered 🌍.
4.11. Testing 🧪
the impacts of network virtualization on testing can be split into three groups 🪄:
- Changes in methodology
- New functionality
- Opportunities
4.11.1. Changes in Methodology 💅
the biggest impact of NFV is the ability to isolate the System Under Test (SUT) 🔍. when testing PNFs, isolating the SUT means all the other devices it talks to get replaced with simulations (or controlled executions) so the SUT is tested all by itself 🧼. the SUT may be one or more devices, and the simulations use the appropriate traffic type and protocols to run test cases 🎯.
as shown in Figure 2, NFV gives all functions a common architecture to use ✨. a VNF runs on resources offered by the NFVI, which have been allocated using the MANO function 🧩. you literally can't test a VNF by itself without the entire supporting environment present, and that totally changes how we think about the SUT 😳. for a VNF (or multiple VNFs), the SUT is part of a larger architecture that's necessary in order to run the SUTs at all 🏗️.
so isolation of the SUT becomes controlling the environment in a disciplined manner 🧘♀️. the components of the environment needed to run the SUTs that aren't part of the SUT itself become the test environment 🌱. when VNFs are part of the SUT, the NFVI and MANO become the test environment 🪴. the configurations and policies guiding the test environment should remain constant during the execution of the tests, and also from test to test 📌. configurations like CPU pinning, NUMA configuration, and the SW versions and configurations of the hypervisor, vSwitch and NICs should remain constant too 💾. the only variables in the testing should be the ones controlling the SUT itself 🎚️. if any test environment configuration changes from test to test, the results become very difficult, if not impossible, to compare, since the test environment behavior may change the results as a consequence of that change 🙃.
testing the NFVI itself also brings new considerations 🗺️. with a PNF, the dedicated hardware is optimized for the particular workload of that function. routing hardware is specially built to support packet forwarding, while hardware supporting a purely control-plane application (say, a DNS server, or a Diameter function) won't have that specialized capability 🛠️. in NFV, the NFVI is required to support all types of potentially different workload types 🧺.
so testing the NFVI requires careful consideration about which metrics you're after 🔬. that in turn depends on the workload type the expected VNF will be. examples of different workload types are data forwarding, control plane, encryption, and authentication, and all of these expected workloads determine the metrics that should be sought 📏. for example, if the workload is control plane, then a metric like jitter isn't useful, but dropped packets are critical 🚨. in a multi-tenant environment, the NFVI could support various types of workloads, so testing with a variety of traffic types while measuring the corresponding metrics simultaneously becomes necessary 🧑🤝🧑.
test beds for any type of NFV-based testing will be largely similar to previously used test architectures ✌️. the methods are impacted by virtualization as described above, but the design of test beds is similar to how it's always been. there are two main new considerations 👇:
- since networking is based on software, which has led to greater automation in deployment, the test system should also be deployable with the rest of the system so you can fully automate everything 🤖. this is especially relevant in a DevOps environment supported by a Continuous Integration and Continuous Deployment (CI/CD) tool chain (see Section 4.11.3 below) 🔁.
- in any performance test bed, the test system should not share the same resources as the SUT 🚫. multi-tenancy is a reality in virtualization, but having the test system share resources with the SUT will impact the measured results in a performance test bed 📉. the test system should be deployed on a separate platform so it doesn't impact the resources available to the SUT 🧱.
4.11.2. New Functionality ✨
Okay so NFV comes with a whole bag of brand new functionality to support the goal of software networking 💻. Every component in the architecture in Figure 2 has its own set of functionality, so VNFs can run things like onboarding, life-cycle management for VNFs and Network Services (NS), resource allocation, hypervisor functions, etc. It's giving full toolkit 🧰.
One of the new capabilities NFV enables is VNF Forwarding Graphs (VNFFG) 🦋. This is the graph that represents a network service by chaining VNFs together into a forwarding path. The forwarding path can be built a bunch of different ways using different networking tools: vSwitch, SDN, and SDN with a northbound application 🔥. The VNFFG might also use tunneling protocols like Virtual eXtensible Local Area Network (VXLAN) 🌈. The dynamic allocation and implementation of these paths have different performance characteristics depending on the method, so the path implementation mechanism becomes a variable in testing the NSs 👀. The methodology used to test the different mechanisms basically stays the same. As usual, the test environment has to stay constant for each test, and you only vary the path establishment method 💅.
"Scaling" is the change in resource allocation to a VNF or NS 📈. It happens dynamically at run-time, based on defined policies and triggers, and those triggers can be network, compute, or storage based. Scaling can allocate more resources when things get busy, or reduce the amount allocated when demand drops 📉. The SUT here becomes way bigger than the VNF itself. MANO controls how scaling is done based on policies, then allocates the resources accordingly in the NFVI. So testing scaling basically pulls the entire NFV architecture components into the SUT 🤯.
4.11.3. Opportunities 🌟
Softwarization of networking functionality leads to softwarization of testing too 💾. As PNFs get transformed into VNFs, so are the test tools. That means the test tools are controlled and executed in the same environment as the VNFs 🧚. This is an opportunity to include VNF-based test tools alongside the VNFs that support the service provider's services, deployed into host data centers 🏢. Tests can then run automatically upon deployment in the target environment, for each deployment and each service ✅. With PNFs, this was super hard to do 😭.
This new concept helps enable modern stuff like DevOps and Continuous Integration and Continuous Deployment in the NFV environment 🚀. The CI/CD pipeline supports this. It's a series of tools, and immediate testing is an integral part of delivering software from source to deployment 🔄. Deploying the test tools themselves into the production environment stretches the CI/CD pipeline all the way to production deployment, so a range of tests can run there 🎀. The tests can be simple, with the goal of verifying correct deployment and networking establishment, or they can be more complex, like testing VNF functionality 💖.
5. Technology Gaps and Potential IETF Efforts 🗺️
Table 1 correlates the open network virtualization research areas identified in this document with potential IETF and IRTF groups that could address some aspects of them 💜. A specific gap the group could potentially address is shown in a parenthetical beside the group name 🦋.
+-------------------------+-----------------------------------------+
| Open Research Area | Potential IETF/IRTF Group |
+-------------------------+-----------------------------------------+
| 1) Guaranteeing QoS | IPPM WG (Measurements of NFVI) |
| | |
| 2) Performance | SFC WG, NFVRG (energy-driven |
| improvement | orchestration) |
| | |
| 3) Multiple Domains | NFVRG (multi-domain orchestration) |
| | |
| 4) Network Slicing | NVO3 WG, NETSLICES bar BoF (multi- |
| | tenancy support) |
| | |
| 5) Service Composition | SFC WG (SFC Mgmt and Config) |
| | |
| 6) End-user device | N/A |
| virtualization | |
| | |
| 7) Security | N/A |
| | |
| 8) Separation of | NFVRG (separation between transport |
| control concerns | control and services) |
| | |
| 9) Testing | NFVRG (testing of scaling) |
| | |
| 10) Function placement | NFVRG, SFC WG (VNF placement algorithms |
| | and protocols) |
+-------------------------+-----------------------------------------+
Table 1: Mapping of Open Research Areas to Potential IETF Groups6. NFVRG Focus Areas 🎯
Table 2 correlates the currently identified NFVRG topics of interest and focus areas with the open network virtualization research areas enumerated in this document. This helps the NFVRG spot and prioritize research topics 📋. The current NFVRG focus points are:
- Re-architecting functions, including new architectural and design patterns (e.g., containerization, statelessness, serverless, control/data plane separation), SDN integration, and proposals on programmability 🏗️.
- New management frameworks, looking at new OAM mechanisms (e.g., configuration control, hybrid descriptors) and lightweight MANO proposals 🧩.
- Techniques to guarantee low latency, resource isolation, and other data-plane features, including hardware acceleration, functional offloading to data-plane elements (including NICs), and related approaches ⚡.
- Measurement and benchmarking, addressing both internal measurements and external applications 📊.
+-------------------------------------+-------------------------+
| NFVRG Focus Point | Open Research Area |
+-------------------------------------+-------------------------+
| 1) Re-architecting functions | - Performance improvem. |
| | - Network Slicing |
| | - Guaranteeing QoS |
| | - Security |
| | - End-user device virt. |
| | - Separation of control |
| | |
| 2) New management frameworks | - Multiple Domains |
| | - Service Composition |
| | - End-user device virt. |
| | |
| 3) Low latency, resource isolation, | - Performance improvem. |
| etc. | - Separation of control |
| | |
| 4) Measurement and benchmarking | - Guaranteeing QoS |
| | - Testing |
+-------------------------------------+-------------------------+
Table 2: Mapping of NFVRG Focus Points to Open Research Areas7. IANA Considerations 🌸
This document has no IANA actions. Nothing to register here, bestie 💅.
8. Security Considerations 🔐
This is an Informational RFC that details research challenges. It does not introduce any security threat.
Research challenges and gaps related to security and privacy are covered in Section 4.8. Go read that section, because it is where the real security drama lives 🚨.
9. Informative References 📚
[COMS-PS] Geng, L., Slawomir, S., Qiang, L., Matsushima, S., Galis,
A., and L. Contreras, "Problem Statement of Common
Operation and Management of Network Slicing", Work in
Progress, draft-geng-coms-problem-statement-04, March
2018.
[dynamic_chaining]
Martini, B. and F. Paganelli, "A Service-Oriented Approach
for Dynamic Chaining of Virtual Network Functions over
Multi-Provider Software-Defined Networks", Future
Internet Vol. 8, No. 2, DOI 10.3390/fi8020024, June 2016.
[dynamic_placement]
Clayman, S., Maini, E., Galis, A., Manzalini, A., and
N. Mazzocca, "The dynamic placement of virtual network
functions", 2014 IEEE Network Operations and Management
Symposium (NOMS) pp. 1-9, DOI 10.1109/NOMS.2014.6838412,
May 2014.
[etsi_gs_nfv_003]
ETSI NFV ISG, "Network Functions Virtualisation (NFV);
Terminology for Main Concepts in NFV", ETSI GS NFV 003
V1.2.1 NFV 003, December 2014,
<http://www.etsi.org/deliver/etsi_gs/
NFV/001_099/003/01.02.01_60/gs_NFV003v010201p.pdf>.
[etsi_gs_nfv_eve005]
ETSI NFV ISG, "Network Functions Virtualisation (NFV);
Ecosystem; Report on SDN Usage in NFV Architectural
Framework", ETSI GS NFV-EVE 005 V1.1.1 NFV-EVE 005,
December 2015,
<http://www.etsi.org/deliver/etsi_gs/NFV-EVE/001_099/
005/01.01.01_60/gs_NFV-EVE005v010101p.pdf>.
[etsi_gs_nfv_per_001]
ETSI NFV ISG, "Network Functions Virtualisation (NFV); NFV
Performance & Portability Best Practises", ETSI GS NFV-PER
001 V1.1.2 NFV-PER 001, December 2014,
<https://www.etsi.org/deliver/etsi_gs/nfv-per/
001_099/001/01.01.02_60/gs_nfv-per001v010102p.pdf>.
[etsi_gs_nfv_sec_001]
ETSI NFV ISG, "Network Functions Virtualisation (NFV); NFV
Security; Problem Statement", ETSI GS NFV-SEC 001 V1.1.1
NFV-SEC 001, October 2014, <http://www.etsi.org/deliver/
etsi_gs/NFV-SEC/001_099/001/01.01.01_60/
gs_NFV-SEC001v010101p.pdf>.
[etsi_nfv_whitepaper_3]
ETSI, "Network Functions Virtualisation (NFV) - White
Paper #3: Network Operator Perspectives on Industry
Progress", Issue 1, SDN & OpenFlow World
Congress Dusseldorf, Germany, October 2014,
<http://portal.etsi.org/NFV/NFV_White_Paper3.pdf>.
[google_sdn_wan]
Jain, S., et al., "B4: experience with a globally-deployed
Software Defined WAN", SIGCOMM '13: Proceedings of the ACM
SIGCOMM 2013 conference on SIGCOMM, pp. 3-14, Hong
Kong China, DOI 10.1145/2486001.2486019, August 2013.Okay bestie, here are the references! 📚✨ Each one is listed with every detail intact, URLs included 🔗
[intel_10_differences_nfv_cloud] Torre, P., "Discover the Top 10 Differences Between NFV and Cloud Environments", November 2015, <https://software.intel.com/en-us/videos/discover-the-top-10-differences-between-nfv-and-cloud-environments>.
[itu-t-y.3300] ITU-T, "Y.3300: Framework of software-defined networking", ITU-T Recommendation Y.3300, June 2014, <http://www.itu.int/rec/T-REC-Y.3300-201406-I/en>.
[itu-t-y.3301] ITU-T, "Y.3301: Functional requirements of software-defined networking", ITU-T Recommendation Y.3301, September 2016, <http://www.itu.int/rec/T-REC-Y.3301-201609-I/en>.
[itu-t-y.3302] ITU-T, "Y.3302: Functional architecture of software-defined networking", ITU-T Recommendation Y.3302, January 2017, <http://www.itu.int/rec/T-REC-Y.3302-201701-I/en>.
[LAYERED-SDN] Contreras, L., Bernardos, C., Lopez, D., Boucadair, M., and P. Iovanna, "Cooperating Layered Architecture for Software Defined Networking (CLAS)", Work in Progress, draft-contreras-layered-sdn-03, November 2018.
[LIGHT-NFV] Sriram, N., Krishnan, R., Ghanwani, A., Krishnaswamy, D., Willis, P., Chaudhary, A., and F. Huici, "An Analysis of Lightweight Virtualization Technologies for NFV", Work in Progress, draft-natarajan-nfvrg-containers-for-nfv-03, July 2016.
[multi-domain_5GEx] Bernardos, C., Gero, B., Di Girolamo, M., Kern, A., Martini, B., and I. Vaishnavi, "5GEx: Realizing a Europe-wide Multi-domain framework for software-defined infrastructures", Transactions on Emerging Telecommunications Technologies Vol. 27, No. 9, pp. 1271-1280, DOI 10.1002/ett.3085, July 2016.
[MULTI-NMRG] Bernardos, C., Contreras, L., Vaishnavi, I., Szabo, R., Li, X., Paolucci, F., Sgambelluri, A., Martini, B., Valcarenghi, L., Landi, G., Andrushko, D., and A. Mourad, "Multi-domain Network Virtualization", Work in Progress, draft-bernardos-nmrg-multidomain-00, March 2019.
[NETSLICES] Galis, A., Dong, J., Makhijani, K., Bryant, S., Boucadair, M., and P. Martinez-Julia, "Network Slicing - Introductory Document and Revised Problem Statement", Work in Progress, draft-gdmb-netslices-intro-and-ps-02, February 2017.
[NFV-COTS] Mo, L. and B. Khasnabish, "NFV Reliability using COTS Hardware", Work in Progress, draft-mlk-nfvrg-nfv-reliability-using-cots-01, October 2015.
[nfv_piecing] Luizelli, M., Bays, L., Buriol, L., Barcellos, M., and L. Gaspary, "Piecing together the NFV provisioning puzzle: Efficient placement and chaining of virtual network functions", 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM) pp. 98-106, DOI 10.1109/INM.2015.7140281, May 2015.
[nfv_sota_research_challenges] Mijumbi, R., Serrat, J., Gorricho, J-L., Bouten, N., De Turck, F., and R. Boutaba, "Network Function Virtualization: State-of-the-art and Research Challenges", IEEE Communications Surveys & Tutorials Volume: 18, Issue: 1, pp. 236-262, DOI 10.1109/COMST.2015.2477041, September 2015.
[NFVRG-TOPO] Bagnulo, M. and D. Dolson, "NFVI PoP Network Topology: Problem Statement", Work in Progress, draft-bagnulo-nfvrg-topology-01, March 2016.
[ngmn_5G_whitepaper] NGMN Alliance, "NGMN 5G White Paper", Version 1.0, February 2015, <https://www.ngmn.org/fileadmin/ngmn/content/images/news/ngmn_news/NGMN_5G_White_Paper_V1_0.pdf>.
[omniran] IEEE, "Recommended Practice for Network Reference Model and Functional Description of IEEE 802 Access Network", P802.1CF IEEE Draft, December 2017.
[onf_tr_521] Open Networking Foundation, "SDN Architecture", ONF TR-521 TR-521, Issue 1.1, February 2016, <https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR-521_SDN_Architecture_issue_1.1.pdf>.
[OpenFlow] Open Networking Foundation, "OpenFlow Switch Specification", ONF TS-025, Version 1.5.1 (Protocol version 0x06), March 2015.
[openmano_dataplane] Lopez, D., "OpenMANO: The Dataplane Ready Open Source NFV MANO Stack", March 2015, <https://www.ietf.org/proceedings/92/slides/slides-92-nfvrg-7.pdf>.
[RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, DOI 10.17487/RFC5810, March 2010, <https://www.rfc-editor.org/info/rfc5810>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://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, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, <https://www.rfc-editor.org/info/rfc7498>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic Event Delivery Using HTTP Push", RFC 8030, DOI 10.17487/RFC8030, December 2016, <https://www.rfc-editor.org/info/rfc8030>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8172] Morton, A., "Considerations for Benchmarking Virtual Network Functions and Their Infrastructure", RFC 8172, DOI 10.17487/RFC8172, July 2017, <https://www.rfc-editor.org/info/rfc8172>.
[SDN-AAA] Lopez, R. and G. Lopez-Millan, "Software-Defined Networking (SDN)-based AAA Infrastructures Management", Work in Progress, draft-marin-sdnrg-sdn-aaa-mng-00, November 2015.
[sfc_challenges] Medhat, A., Taleb, T., Elmangoush, A., Carella, G., Covaci, S., and T. Magedanz, "Service Function Chaining in Next Generation Networks: State of the Art and Research Challenges", IEEE Communications Magazine vol. 55, no. 2, pp. 216-223, DOI 10.1109/MCOM.2016.1600219RP, February 2017.
[SLICE-3GPP] Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case", Work in Prgoress, draft-defoy-netslices-3gpp-network-slicing-02, October 2017.
[virtualization_mobile_device] Sproule, W. and A. Fernando, "Virtualization of Mobile Device User Experience", US Patent 9.542.062 B2, filed October 2013 and issued December 2014, Current Assignee: Microsoft Technology Licensing LLC.
[vnf-p] Moens, H. and , "VNF-P: A model for efficient placement of virtualized network functions", 10th International Conference on Network and Service Management (CNSM) and Workshop pp. 418-423, DOI 10.1109/CNSM.2014.7014205, November 2014.
[VNF-VBAAS] Rosa, R., Rothenberg, C., and R. Szabo, "VNF Benchmark-as-a-Service", Work in Progress, draft-rorosz-nfvrg-vbaas-00, October 2015.
[vnf_benchmarking] Rosa, R., Rothenberg, C., and R. Szabo, "A VNF Testing Framework Design, Implementation and Partial Results", NFVRG IETF 97, November 2016, <https://www.ietf.org/proceedings/97/slides/slides-97-nfvrg-06-vnf-benchmarking-00.pdf>.
Acknowledgments 🫶
The authors want to thank Dirk von Hugo, Rafa Marin, Diego Lopez, Ramki Krishnan, Kostas Pentikousis, Rana Pratap Sircar, Alfred Morton, Nicolas Kuhn, Saumya Dikshit, Fabio Giust, Evangelos Haleplidis, Angeles Vazquez-Castro, Barbara Martini, Jose Saldana, and Gino Carrozzo for their very useful reviews and comments to the document. Special thanks to Pedro Martinez-Julia, who provided text for the network slicing section. 💜
The authors want to also thank Dave Oran and Michael Welzl for their very detailed IRSG reviews. 🙌
The work of Carlos J. Bernardos and Luis M. Contreras is partially supported by the H2020 5GEx (Grant Agreement no. 671636) and 5G-TRANSFORMER (Grant Agreement no. 761536) projects. 🌈
Authors' Addresses 🎀
Carlos J. Bernardos
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/Akbar Rahman
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
Juan Carlos Zuniga
SIGFOX
425 rue Jean Rostand
Labege 31670
France
Email: j.c.zuniga@ieee.org
URI: http://www.sigfox.com/Luis M. Contreras
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, S/N
Madrid 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.comPedro Aranda
Pedro Aranda
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Email: pedroandres.aranda@uc3m.esPierre Lynch
Pierre Lynch
Keysight Technologies
800 Perimeter Park Dr, Suite A
Morrisville, NC 27560
United States of America
Email: pierre.lynch@keysight.com
URI: http://www.keysight.comAnd that's a wrap on RFC 8568! 🦋✨💖
📦 where this page comes from
- ietf: rfc8568 2019-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms