Virtualization for NFV/Data Plane SDN Bob Lantz Open Networking - - PowerPoint PPT Presentation

virtualization for nfv data plane sdn
SMART_READER_LITE
LIVE PREVIEW

Virtualization for NFV/Data Plane SDN Bob Lantz Open Networking - - PowerPoint PPT Presentation

Virtualization for NFV/Data Plane SDN Bob Lantz Open Networking Laboratory ONS 2016 Talk Outline - What is NFV? - One Way to Do It - A Better Way - Control Plane NFV/SDN - Data Plane SDN - VM Configuration - Container Configuration -


slide-1
SLIDE 1

Virtualization for NFV/Data Plane SDN

Bob Lantz Open Networking Laboratory ONS 2016

slide-2
SLIDE 2

Talk Outline

  • What is NFV?
  • One Way to Do It
  • A Better Way
  • Control Plane NFV/SDN
  • Data Plane SDN
  • VM Configuration
  • Container Configuration
  • Evaluating Virtualization Options
  • Conclusions
slide-3
SLIDE 3

What is NFV?

For the purpose of this talk, Network Function Virtualization is replacing "middlebox" hardware functionality (beyond simple forwarding and routing) with software applications running on a network and/or server OS. Some example network/middle box functions include: Firewalls, Load Balancers, NATs, Access Control, Authentication, Intrusion Detection/Mitigation, Packet Inspection, Compression, Caching, VPN/Encryption, Transcoding, Monitoring/Measurement/Statistics, Metering/Billing, etc.

slide-4
SLIDE 4

server1

One Way to Do It: Middleboxes -> VMs

Client Firewall Load Balancer Server Client VM server2 server3 server1 Firewall VM Load Balancer VM Server VM Network Fabric

slide-5
SLIDE 5

server1

A Better Way: Push functionality to edge and use SDN

Client1 VM server4 Server VM Network Fabric LB FW

slide-6
SLIDE 6

Control Plane NFV/SDN

A network function that primarily deals in packet forwarding decisions and doesn't require extensive computation or data plane activity can be implemented on a Network OS using existing SDN/OpenFlow switches. Examples: Firewall, Load Balancer, NAT, Authentication, Simple Statistics/Monitoring/Metering, basic QoS/rate limiting Edge switch processing scales linearly with the number of edge ports. Centralized control can scale out across multiple nodes of a distributed Network OS. ...but what about packet processing in the data plane?

slide-7
SLIDE 7

Adding the Data Plane to SDN

Network OS Control Protocol (OpenFlow) SDN Switch (OpenFlow) Network OS Data Plane Program Packet Processing Engine Control Program Control Program Control Protocol(s) (OpenFlow?, config? RPC?)

slide-8
SLIDE 8

Data Plane SDN: Software + Platform for Network Functions

Data Plane Program (Network Function Application) P4, Click, OpenFlow Extensions, TPP, Active Networking, C... Hardware Packet Processor Programmable pipeline, OpenFlow switch + extensions, P4 parse/match/action hardware, Smart NIC, NPU, FPGA... Software Packet Processor OF soft switch + Extensions, P4 Software Switch, EBPF, Click, Software NIC/BESS, kernel, DPDK/netmap, raw sockets... Virtual or Physical Machine VM, Container, Process... ... but what about overhead and scalability?

slide-9
SLIDE 9

Server OS + VMM VM OS Kernel Network Function Application init, system processes, daemons, libraries...

VM Configuration for Scalability: "Just Enough OS"

Server Bare Metal VMM VM Minimal/Library "OS" Network Function Application

slide-10
SLIDE 10

Linux containers: a-la-carte OS-level virtualization/isolation

Resource Virtualization/Isolation Method Linux Command(s) CPU, I/O bandwidth, Memory processes + cgroups (process control groups) cgreate, cgset, cgclassify... Network Devices network namespaces ip netns Process IDs, user IDs, hostname... pid, user, uts namespaces unshare Disk/File System virtual disk, chroot, mount namespaces, overlayfs, union FS mount, chroot, unshare

slide-11
SLIDE 11

Container Configuration for Scalability:

"Just Enough OS + Just Enough Virtualization"

Virtual Disk Image cgroups CPU Memory I/O init Network Function App Read-only FS Image cgroups CPU Memory I/O init System processes Network Function App Private r/w FS (aufs,

  • verlayfs, mnt...)

File System System processes Network Function App namespaces User PID Network UTS Mount namespaces User PID Network UTS Mount cgroups CPU Memory I/O Private r/w

slide-12
SLIDE 12

Summary: Evaluating Virtualization Options for NFV

Method Software Support Scalability/ Overhead Complexity Performance Isolation Other: multi- kernel, live mi- gration... VMs virsh, Open- Stack... Possibly Poor High Good (PCI passthrough, ELI, DPDK / netmap...) Good Yes Containers lxc, docker, OpenVZ, Open- Stack... Probably Good Variable Good OK/ variable No. Processes bash? python? ??? Very Good Low Good poor? No.

slide-13
SLIDE 13

Conclusions

Control plane network functions (firewall, load balancer, NAT, simple stats etc.) can and should be "virtualized" by implementing them as SDN apps on a Network OS. Packet processing data plane network functions should use switch features or hardware where available, and will eventually (P4, future OpenFlow, Click, etc.) become data plane SDN apps on a Network OS! There is a large space of virtualization and container options - what is best will depend on each specific use case. Overhead and complexity are likely to be reduced by a "Just Enough OS + Just Enough virtualization" approach. The future of data plane SDN is exciting!

slide-14
SLIDE 14
slide-15
SLIDE 15

Backup slides

slide-16
SLIDE 16

Alternatives: VMs, Containers, and Processes

Server Server OS Container Network Function App Server Server OS Network Function App Server OS kernel + VMM OS Kernel Network Function App init, system processes, daemons, libraries... Container

slide-17
SLIDE 17

Evaluating Container Configurations for NFV

Container Features Resembles Advantages Disadvantages

OS Disk Image (COW?) + User/pid/UTS/Mount/ Network namespaces + cgroups + init lxc-ish can boot in VMM; full OS;

  • rchestration support

bulky OS image; extra processes, CPU and memory usage OS File System Image (overlayfs) + User/pid/UTS/Mount/ Network namespaces + cgroups + init Docker-ish full OS; orchestration support bulky OS image + libraries (might be required anyway?) extra processes, CPU and memory usage Underlying r/w file system + Network namespaces + cgroups (optional) bash Mininet-ish zero file overhead; no init/OS processes; minimal per- container admin and configuration minimal isolation/security; Mininet not really designed for NFV Underlying read-only File system + mount namespace + cgroups "Just Enough OS + Just Enough Virtualization for NFV?" zero file overhead; no init/OS processes; minimal per-container admin and configuration no good orchestration support (yet?); privilege isolation may require OS configuration (e.g. user IDs); perturbs server OS