In physics, superfluidity is a state in which matter behaves like a fluid with zero viscosity. The vision of superfluid networking corresponds to the ability to decompose services into network functions to be deployed on-the-fly, run them anywhere in the network (core, aggregation, edge) and shift them transparently to different locations and heterogeneous execution environments. Superfluid networking tackles crucial shortcomings in today’s networks like long provisioning times, with wasteful over-provisioning used to meet variable demand and reliance on rigid and cost-ineffective hardware devices. The 5G System architecture can be deployed using techniques like Network Function Virtualization (NFV) that potentially enable the realization of superfluid networking. In this talk, we discuss the state of the art of NFV models and infrastructures for 5G and illustrate the path toward superfluid networking, considering the results of the Superfluidity research project (funded by EU in the H2020 framework).

1. Superfluid networking for 5G: vision and state of the art
Stefano Salsano
CNIT / Univ. of Rome Tor Vergata, Italy
Project coordinator of EU H2020 Superfluidity project http://superfluidity.eu/
Invited talk – Session on Millimeter-wave and edge computing
SmartCom 2017 -The 4th International Workshop on Smart Wireless Communications
Rome, Italy - 24th October, 2017
A super-fluid, cloud-native, converged edge system

2. 5G Usage scenarios
2
ITU-R M.2083

3. Technical challenges / KPIs for 5G
3
10x User data rate
20x Peak data rate
100x Area traffic capacity
100x Network energy efficiency
10x Lower latency

4. Facing the 5G challenges
4
Radio Access Network 5G Core Network
Air interface
Networking: edge/aggregation/core
Internet /
Cloud Datacenters
Datacenter
BackhaulFronthaul

5. Facing the 5G challenges
5
Radio Access Network 5G Core Network
Air interface
Networking: edge/aggregation/core
Internet /
Cloud Datacenters
Datacenter
BackhaulFronthaul

6. 5G networks: the approach to face the challenges
6
• “The 5G System architecture is defined to support data connectivity and
services enabling deployments to use techniques such as e.g. Network
Function Virtualization (NFV) and Software Defined Networking (SDN).” (*)
NVF + SDN (+MEC) =
Network softwarization
(*) 3GPP TS 23.501 V1.4.0 (2017-09)

7. Network softwarization
7
Radio Access Network 5G Core Network
A large distributed Datacenter to support all networking/processing functions
Internet /
Cloud Datacenters
Datacenter
BackhaulFronthaul
Air interface
NFV – Network Function Virtualization / SDN – Software Defined Networking / MEC – Multi-access Edge Computing

8. Network softwarization
8
The Network Softwarization is the way to meet the target
KPIs and reduce costs, thanks to:
- efficient utilization of resources
- reuse of functions
- flexibility in the design of services
Edge / Cloud RAN 5G Core Network Cloud Datacenters

9. Network softwarization
9
The Network Softwarization is the way to meet the target
KPIs and reduce costs, thanks to:
- efficient utilization of resources
- reuse of functions
- flexibility in the design of services
Edge / Cloud RAN 5G Core Network Cloud Datacenters
We want to reduce “space” and “time” granularity in allocation of the resources

10. From Network Softwarization to
Superfluid networking
Goals
• Instantiate network functions and services on-the-fly
• Run them anywhere in the network (core, aggregation, edge), across
heterogeneous infrastructure environments (computing and networking), taking
advantage of specific hardware features, such as high performance accelerators,
when available
Approach
• Decomposition of network components and services into elementary and
reusable primitives (“Reusable Functional Blocks – RFBs”)
• Platform-independent abstractions, permitting reuse of network functions
across heterogeneous hardware platforms
10

11. The Superfluidity vision
11
Current NFV
technology
Granularity
Time scale
Superfluid
NFV
technology
Days, Hours Minutes Seconds Milliseconds
Big VMs
Small
components
Micro
operations • From VNFs
(Virtual Network Functions)
to RFBs
Reusable Functional Blocks

12. Heterogeneous composition/execution environments
12
• Classical NFV environments (i.e. by ETSI NFV standards)
– VNFs are composed/orchestrated to realize Network Services
– VNFs can be decomposed in VNFC (VNF Components)
«Big»
VNF
«Big»
VNF
«Big»
VNF
«Big»
VNF
VNFC
VNFC
VNFC
VM
VM

13. Heterogeneous composition/execution environments
13
• Classical NFV environments (i.e. by ETSI NFV standards)
– VNFs are composed/orchestrated to realize Network Services
– VNFs can be decomposed in VNFC (VNF Components)
«Big»
VNF
«Big»
VNF
«Big»
VNF
«Big»
VNF
VNFC
VNFC
VNFC
VM
VM
- VNFC -> Full VMs (initially)
- Containers are now being
considered in the models
- We further consider the
Unikernels technology

14. Heterogeneous composition/execution environments
14
• Towards more «fine-grained» decomposition…
• Modular software routers (e.g. Click)
– Click elements are combined in configurations (Direct Acyclic Graphs)

15. Heterogeneous composition/execution environments
15
• Towards more «fine-grained» decomposition…
• XSFM-based (eXtended Finite State Machine) decomposition of
traffic forwarding / flow processing tasks, and HW support for
wire speed execution

16. The Superfluidity Architecture
16
RFB
#a
RFB
#b
RFB
#c
RFB
#n
(node-level) RDCL script
REE
RFB#2
(network-level) RDCL script
(network-wide) REE
RFB Execution Environment
RFB#1
(node-level) REE
RFB Execution Environment
RFB : Reusable Functional Blocks
RDCLs : RFB Description and Composition Languages
REE : RFB Execution Environments
REEs are heterogeneous and can be nested

17. The Superfluidity Architecture (APIs)
17
RFB
#a
RFB
#b
RFB
#c
RFB
#n
(node-level) RDCL script
REE
RFB#2
(network-level) RDCL script
REE
Manager
REE User
REE
Resource
Entity
UM API
MR API
REE
User
UM API
REE
Resource
Entity
REE
Manager
(network-wide) REE
RFB Execution Environment
RFB#1
MR API(node-level) REE
RFB Execution Environment

18. (Towards) Common Abstractions
for Heterogeneous Environments
18
REE - RFB Execution
Environment(s)
RFBs Description & Composition
Languages (RDCLs) and tools
• “Traditional” NFVI infrastructure
hypervisors with Full VMs
• NFVI with containers
• Unikernel based virtualization
• Software modular routers
environments (e.g. Click)
• Radio processing SW modules
• Hardware packet processors
• ETSI VNF descriptors / NEMO
• MISTRAL – HEAT
• Docker Compose …
• Click configurations / SEFL /
Symnet
• PN (Process Networks), SDF
(Synchronous Data Flow)…
• XFSMs (eXtended Finite State
Machines)

19. The Superfluidity vision
19
Current
NFV/SDN
technology
Virtualization technologies heterogeneity
Superfluid
NFV/SDN
technology
VMs VMs &
Containers
VM, Containers,
Unikernels
• From VNF
Virtual Network Functions
to RFB
Reusable Functional Blocks
• Improving Virtual Infrastructure
Managers (VIMs)
• Heterogeneous RFB execution
environments
- Hypervisors
- Modular routers
- Packet processors
…
Single-level
orchestration
Nested
decomposition
& orchestration

20. Unikernels: a tool for superfluid virtualization
Containers
e.g. Docker
• Lightweight (not enough?)
• Poor isolation
20
Hypervisors (traditional VMs)
e.g. XEN, KVM, wmware…
• Strong isolation
• Heavyweight
Unikernels
Specialized VMs (e.g. MiniOS, ClickOS…)
• Strong isolation
• Very Lightweight
• Very good security properties
They break the “myth” of VMs being heavy weight…

21. What is a Unikernel?
• Specialized VM: single application +
minimalistic OS
• Single address space,
co-operative scheduler so low
overheads
• Unikernel virtualization platforms
extend existing hypervisors (e.g. XEN)
driver1
driver2
app1
(e.g., Linux, FreeBSD)
KERNELSPACEUSERSPACE
app2
appNdriverN
Vdriver1
vdriver2
app
SINGLEADDRESS
SPACE
21
General purpose OS Unikernel
a minimalistic OS
(e.g., MiniOS, Osv)

22. Unikernels (ClickOS) memory footprint and boot time
VM configuration: MiniOS, 1 VCPU, 8MB RAM, 1 VIF
• ~ 2 ms
• 87.77 ms
22
Boot time, state of the art results
Recent results from Superfluidity,
by redesigning the XEN toolstack
Memory footprint
• Hello world guest VM : 296 KB
• Ponger (ping responder) guest VM : ~700KB

23. Unikernels (ClickOS) memory footprint and boot time
VM configuration: MiniOS, 1 VCPU, 8MB RAM, 1 VIF
23
Boot time, state of the art results
Memory footprint
• Hello world guest VM : 296 KB
• Ponger (ping responder) guest VM : ~700KB
Recent results from Superfluidity,
by redesigning the XEN toolstack
• ~ 2 ms
• 87.77 ms

24. ETSI NFV Orchestration architecture
24

25. VM instantiation and boot time
typical performance (no Unikernels)
25
Orchestrator
request
VIM
operations
Virtualization
Platform
Guest OS (VM)
Boot time
1-2 s
5-10 s
~1 s

26. VM instantiation and boot time
typical performance (no Unikernels)
26
Orchestrator
request
VIM
operations
Virtualization
Platform
Guest OS (VM)
Boot time
1-2 s
~1 ms
~1 ms
XEN Hypervisor
Enhancements
Unikernels
Unikernels and Hypervisor can provide
low instantiation times for “Micro-VNF”

27. VM instantiation and boot time
typical performance (no Unikernels)
27
Orchestrator
request
VIM
operations
Virtualization
Platform
Guest OS (VM)
Boot time
1-2 s
~1 ms
~1 ms
XEN Hypervisor
Enhancements
Unikernels
Can we improve VIM
performances?
Unikernels and Hypervisor can provide
low instantiation times for “Micro-VNF”

28. Results – Unikernels (ClickOS) instantiation times
in VIMs (OpenStack, Nomad, OpenVIM)
28
OpenStack Nova
Nomad
seconds
seconds
OpenVIM
seconds

29. There is no comparison implied…
• NB: the purpose of the work was NOT to compare OpenStack vs.
Nomad vs. OpenVIM. The goal was to understand how the different
VIMs behave and find ways to reduce instantiation times.
• A direct comparison makes few sense. OpenStack is a much more
complete framework in terms of offered functionality and different
types of supported hypervisors. Note also that we have put most of our
efforts into the optimization of OpenVIM because it was simpler to
modify for our purposes.
29

30. The Superfluidity vision
30
Current
NFV/SDN
technology
Virtualization technologies heterogeneity
Superfluid
NFV/SDN
technology
VMs VMs &
Containers
VM, Containers,
Unikernels
• From VNF
Virtual Network Functions
to RFB
Reusable Functional Blocks
• Improving Virtual Infrastructure
Managers (VIMs)
• Heterogeneous RFB execution
environments
- Hypervisors
- Modular routers
- Packet processors
…
Single-level
orchestration
Nested
decomposition
& orchestration

31. Orchestration of heterogeneous and nested RFBs
• Extended the ETSI NFV models to support:
– coexistence of VMs, containers, unikernels
– nested decomposition of one “VDU” into a modular software router platform
(click router)
• Developed the RDCL 3D tool to demonstrate the extended models
• Extended the OpenStack networking with “kuryr” project to support
the networking of VMs and containers
31

32. Working prototype
RDCL 3D: RFB Description and Composition Language Design Deploy and Direct
32
This is a regular
VM (XEN HVM)
These are 3 Unikernel
VMs
(ClickOS)

33. Working prototype
RDCL 3D: RFB Description and Composition Language Design Deploy and Direct
33
This is a regular
VM (XEN HVM)
These are 3
Unikernel VMs
(ClickOS)

34. Working prototype
RDCL 3D: RFB Description and Composition Language Design Deploy and Direct
34
This is a regular
VM (XEN HVM)
These are 3
Unikernel VMs
(ClickOS)

35. Working prototype
RDCL 3D: RFB Description and Composition Language Design Deploy and Direct
35
This is a regular
VM (XEN HVM)
These are 3
Unikernel VMs
(ClickOS)
Live demo of RDCL 3D prototype:
http://rdcl-demo.netgroup.uniroma2.it/

36. The Superfluidity vision
36
Hardware platforms heterogeneity
Homogeneous HW
(COTS Servers)
HW
acceleration
• Heterogeneous RFB execution
environments
- Hypervisors
- Modular routers
- Packet processors
…
Programmable
Data Plane Chips
OpenFlow
Switches
XFSM
eXtended Finite
State Machine
abstractions
Current
NFV/SDN
technology
Superfluid
NFV/SDN
technology

37. Network Functions reuse/migration
37
NFV-like VNF
management
General purpose
Computing
Platform (CPUs)
specific
VNF
VM
General purpose
Computing
Platform (CPUs)
specific
VNF
VM
SDN-like
Configuration
deployment
The ‘traditional’ VNF’s view
General purpose computing platform
Deploy VNFs over the VMs
Full flexibility (VNF = ‘anything’ coded in ‘any’ language)
Performance limitations (slow path execution)
Pre-implemented
match/action table
OpenFlow
(HW) switch
Flow table Entry
Flow table Entry
Flow table Entry
flow-mod
Flow table Entry
Flow table Entry
Flow table Entry
flow-mod
Pre-implemented
match/action table
OpenFlow
(HW) switch
Traditional SDN southbound (OpenFlow)
Domain-specific platform (OpenFlow router)
move ‘config’ of a (pre-implemented!) flow-table
Extremely limited flexibility (hardly an NF)
Line-rate performance (TCAM/HW)

38. Network Functions reuse/migration
38
NFV-like VNF
management
General purpose
Computing
Platform (CPUs)
specific
VNF
VM
General purpose
Computing
Platform (CPUs)
specific
VNF
VM
SDN-like
Configuration
deployment
The ‘traditional’ VNF’s view
General purpose computing platform
Deploy VNFs over the VMs
Full flexibility (VNF = ‘anything’ coded in ‘any’ language)
Performance limitations (slow path execution)
Pre-implemented
match/action table
OpenFlow
(HW) switch
Flow table Entry
Flow table Entry
Flow table Entry
flow-mod
Flow table Entry
Flow table Entry
Flow table Entry
flow-mod
Pre-implemented
match/action table
OpenFlow
(HW) switch
Traditional SDN southbound (OpenFlow)
Domain-specific platform (OpenFlow router)
move ‘config’ of a (pre-implemented!) flow-table
Extremely limited flexibility (hardly an NF)
Line-rate performance (TCAM/HW)
Lean towards ‘more
domain specific’
network computing HW
Lean towards ‘more
expressive’ programming
constructs / APIs

39. References
• SUPERFLUIDITY project Home Page http://superfluidity.eu/
• G. Bianchi, et al. “Superfluidity: a flexible functional architecture for 5G networks”, Transactions on
Emerging Telecommunications Technologies 27, no. 9, Sep 2016
• F. Manco, C. Lupu, F. Schmidt, J. Mendes, S. Kuenzer, S. Sati, K. Yasukata, C. Raiciu, F. Huici,
“My VM is Lighter (and Safer) than your Container”, 26th ACM Symposium on Operating Systems
Principles, SOSP 2017, October 28-31, 2017, Shanghai, China
• P. L. Ventre, C. Pisa, S. Salsano, G. Siracusano, F. Schmidt, P. Lungaroni,
N. Blefari-Melazzi, “Performance Evaluation and Tuning of Virtual Infrastructure Managers for
(Micro) Virtual Network Functions”,
IEEE NFV-SDN Conference, Palo Alto, USA, 7-9 November 2016
http://netgroup.uniroma2.it/Stefano_Salsano/papers/salsano-ieee-nfv-sdn-2016-vim-performance-for-unikernels.pdf
39
Architecture
Unikernels

40. References
• S. Salsano, F. Lombardo, C. Pisa, P. Greto, N. Blefari-Melazzi,
“RDCL 3D, a Model Agnostic Web Framework for the Design and Composition of NFV Services”,
3rd IEEE International Workshop on Orchestration for Software Defined Infrastructures, O4SDI at
IEEE NFV-SDN conference, Berlin, 6-8 November 2017
• S. Salsano, L. Chiaraviglio, N. Blefari-Melazzi, C. Parada, F. Fontes, R. Mekuria, D. Griffioen,
“Toward Superfluid Deployment of Virtual Functions: Exploiting Mobile Edge Computing for Video
Streaming”, Soft5 Workshop, 1st International Workshop on Softwarized Infrastructures for 5G and
Fog Computing, in conjunction with 29th ITC conference, Genoa, Italy, 8th September 2017
40
NFV models and tools
MEC Multi-access Edge Computing

41. References
• L. Chiaraviglio, L. Amorosi, S. Cartolano, N. Blefari-Melazzi, P. Dell’Olmo, M. Shojafar, S. Salsano,
“Optimal Superfluid Management of 5G Networks”,
3rd IEEE Conference on Network Softwarization, NetSoft 2017, 3-7 July 2017, Bologna, Italy.
• L. Chiaraviglio, N. Blefari-Melazzi, C.F. Chiasserini, B. Iatco, F. Malandrino, S. Salsano,
“An Economic Analysis of 5G Superfluid Networks”,
18th IEEE International Conference on High Performance Switching and Routing (IEEE HPSR), 18-21
June 2017, Campinas, Brazil.
• M. Shojafar, L. Chiaraviglio, N. Blefari-Melazzi, S. Salsano,
“P5G: A bio-inspired algorithm for the superfluid management of 5G Networks”,
IEEE GLOBECOM 2017, 4-8 December, 2017, Singapore.
41
NFV Infrastructures optimal design, planning, management

42. Take home messages
• Superfluid networking: a vision to fully exploit the network
softwarization approach
• Decomposition in “small” Reusable Functional Blocks to reduce the
space granularity in the allocation of resources
• Redesign of the orchestration models and tools for dynamic
deployment of services to reduce the time granularity in the
allocation of resources
• Orchestration models and tools need to take into account
heterogeneity of Execution Environment and support “nested”
decomposition across multiple Execution Environments
42

43. Thank you. Questions?
Contacts
Stefano Salsano
University of Rome Tor Vergata / CNIT
stefano.salsano@uniroma2.it
http://superfluidity.eu/
The work presented here only covers a subset of the work performed in the project
43

44. The SUPERFLUIDITY project has received funding from the European Union’s Horizon
2020 research and innovation programme under grant agreement No.671566
(Research and Innovation Action).
The information given is the author’s view and does not necessarily represent the view
of the European Commission (EC). No liability is accepted for any use that may be
made of the information contained.
44