CompSci 514: Computer Networks Lecture 16: Network Function - - PowerPoint PPT Presentation

CompSci 514: Computer Networks Lecture 16: Network Function Virtualization

Xiaowei Yang Adapted from Prof. Srinivasa Seshan’s lecture slides

Overview

• NFV Motivation
• NFV case study
• More NFV challenges and solutions
• Optional homework

2

Network as we knew it vs. Reality

Traditional view: “Dumb” network

Reality: Lots of in-network processing Appliances or Middleboxes: IDS, Firewall, Proxies, Load balancers….

3

Need for Network Evolution

New devices New applications Evolving threats Policy constraints

Performance, Security, Compliance

4

Type of appliance Number Firewalls 166 NIDS 127 Media gateways 110 Load balancers 67 Proxies 66 VPN gateways 45 WAN Optimizers 44 Voice gateways 11 Total Middleboxes 636 Total routers ~900

Middleboxes Galore!

Data from a large enterprise

1 10 100 1000 10000 All Middleboxes L3 Routers L2 Switches Number of devices >100k hosts 10k-100k hosts 1k-10k hosts <1k hosts

Survey across 57 network operators

APLOMB (SIGCOMM’13)

5

Specialized boxes Narrow interfaces “Point” solutions! Increases capital expenses & sprawl Increases operating expenses Limits extensibility and flexibility

Management Management Management

è

Key “pain points”

6

Middlebox management is hard!

Critical for security, performance, compliance But expensive, complex and difficult to manage

7

Vision

• Why cant networking get same benefits as IT

and cloud world?

• Commodity hardware?
• Virtualization?
• Consolidation

8

Network Functions Virtualisation

9

Network-wide Controller

Key idea: Consolidation

• 2. Consolidate

Management

• 1. Consolidate

Platform Two levels corresponding to two sources of inefficiency

10

What are the grand challenges?

• High performance virtual appliances?
• Isolation/coexistence
• Management solutions
• Fault tolerance
• Vendor independence/multi-vendor

11

What’s missing?

• What functions yield most benefits?
• Can it really replace hardware acceleration?
• Is virtualization necessary?
• What novel services can be developed?
• How much benefit is “enough” to motivate

adoption?

12

Consolidation at Platform-Level

Proxy Firewall IDS/IPS AppFilter

Today: Independent, specialized boxes

Decouple Hardware and Software

Commodity hardware: e.g., PacketShader, RouteBricks, ServerSwitch, SwitchBlade

Consolidation reduces capital expenses and sprawl

13

Consolidation reduces CapEx

0.2 0.4 0.6 0.8 1 07-09,06:00 07-09,17:00 07-10,04:00 07-10,15:00 07-11,02:00 Normalized utilization (%) Time (mm-dd,hr) WAN optimizer Proxy Load Balancer Firewall

Multiplexing benefit = Max_of_TotalUtilization / Sum_of_MaxUtilizations

14

Consolidation Enables Extensibility

Session Management Protocol Parsers

VPN Web Mail IDS Proxy Firewall

Contribution of reusable modules: 30 – 80 %

15

Management consolidation enables flexible resource allocation

N1 N3 N2

P: N1à N3 Process (0.4 P)

Today: All processing at logical “ingress” Overload! Network-wide distribution reduces load imbalance

Process (0.3 P) Process (0.3 P) Process (P)

16

Centralized Controller

“Flow”

FwdAction

“Flow”

FwdAction

OpenFlow

Proxy IDS

Necessity and an Opportunity: Incorporate functions markets views as important

Firewall IDS Proxy

Web

…

Can NFV/SDN help middlebox management?

17

SDN vs NFV

• Complementary
• SDN is all about “control” plane
• NFV can happen w/o SDN
• Natural allies

– SDN enables orchestration, routing – NFV can be the “substrate” over which SDN runs

18

Network-wide Controller

CoMb System Overview

19

General-purpose hardware: e.g., PacketShader, RouteBricks, ServerSwitch, Logically centralized e.g., NOX, 4D

Middleboxes: complex, heterogeneous, new opportunities

Network-wide Controller Processing responsibilities

CoMb Management Layer

Policy Constraints Resource Requirements Routing, Traffic

Goal: Balance load across network. Leverage multiplexing, reuse, distribution

20

Capturing Reuse with HyperApps

IDS Proxy common

Footprint on resource

HTTP UDP HTTP NFS 2 3 1 1

Memory CPU

HTTP: IDS & Proxy 4 3

Memory

UDP: IDS NFS: Proxy 1 3 4 1

CPU CPU Memory Memory CPU

HyperApp: find the union of apps to run Policy dependency are implicit Need per-packet policy dependencies!

HTTP: 1+2 unit of CPU 1+3 units of mem

21

Modeling Processing Coverage

HTTP N1 à N3 N1 N2 N3 What fraction of traffic of class HTTP from N1 to N3 should each node process? IDS à Proxy 0.4 HTTP: Run IDS à Proxy IDS à Proxy 0.3 IDS à Proxy 0.3

22

Network-wide Optimization

Minimize Maximum Load, Subject to Processing coverage for each class of traffic à Fraction of processed traffic adds up to 1 Load on each node à sum over HyperApp responsibilities per-path

No explicit Dependency Policy

23

Network-wide Optimization

A simple, tractable linear program Very close (< 0.1%) to theoretical optimal

24

CoMb Platform

NIC

Policy Shim (Pshim)

Core1 Core4 IDS

… …

Proxy Traffic

Applications Policy Enforcer Classification: HTTP IDSà Proxy

Challenges: Performance Parallelize Isolation Challenges: Lightweight Parallelize Challenges: No contention Fast classification

25

Parallelizing Application Instances

M1 M2

PShim

App-per-core

Core3 M3

PShim

Core1 Core2

HyperApp-per-core

M2 M3

PShim

M1 M2

PShim

Core1 Core2

• Inter-core communication
• More work for PShim

+ No in-core context switch + Keeps structures core-local + Better for reuse

• But incurs context-switch
• HyperApp-per-core is better or comparable

Contention does not seem to matter!

26

Discussion

• Changes traditional vendor business

– Already happening (e.g., “virtual appliances”) – Benefits imply someone will do it! – May already have extensible stacks internally!

• Isolation

– Current: rely on process-level isolation – Get reuse-despite-isolation?

27

Conclusions

• Network evolution occurs via middleboxes
• Today: Narrow “point” solutions

– High CapEx, OpEx, and device sprawl – Inflexible, difficult to extend

• Our proposal: Consolidated architecture

– Reduces CapEx, OpEx, and device sprawl – Extensible, general-purpose

• More opportunities

– Isolation – APIs (H/W—Apps, Management—Apps, App Stack)

28

More NFV challenges & solutions

• Performance
• Session management

– How to chain the NFV together?

• More applications

29

• Use parallel

processing to shorten NFV latency

• Use a session

protocol to set up NFV chain and dynamically manage the chaining

• A user space NF

scheduler that uses backpressure to shed load early in service chain.

• Change from

packet-layer to transport-layer processing for performance improvement

Summary

• Network Function Virtualization
• A case study

– CoMb

• More challenges and solutions