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 applications Policy Evolving constraints threats Performance, Security, Compliance New devices 4

Middleboxes Galore! Data from a large enterprise Survey across 57 network operators Type of appliance Number >100k hosts 1k-10k hosts Firewalls 166 10k-100k hosts <1k hosts 10000 NIDS 127 Number of devices Media gateways 110 1000 Load balancers 67 100 Proxies 66 VPN gateways 45 10 WAN Optimizers 44 1 Voice gateways 11 All Middleboxes L3 Routers L2 Switches Total Middleboxes 636 Total routers ~900 APLOMB (SIGCOMM’13) 5

Key “pain points” Narrow Management Management Management interfaces Specialized boxes Increases capital expenses & sprawl “Point” è Increases operating expenses solutions! Limits extensibility and flexibility 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

Key idea: Consolidation Two levels corresponding to two sources of inefficiency 2. Consolidate Network-wide Management Controller 1. Consolidate Platform 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 Today: Independent, specialized boxes AppFilter Proxy Firewall IDS/IPS Decouple Hardware and Software Commodity hardware: e.g., PacketShader, RouteBricks, ServerSwitch, SwitchBlade Consolidation reduces capital expenses and sprawl 13

Consolidation reduces CapEx 1 Normalized utilization (%) 0.8 0.6 0.4 0.2 WAN optimizer Load Balancer Proxy Firewall 0 07-09,06:00 07-09,17:00 07-10,04:00 07-10,15:00 07-11,02:00 Time (mm-dd,hr) Multiplexing benefit = Max_of_TotalUtilization / Sum_of_MaxUtilizations 14

Consolidation Enables Extensibility VPN Web Mail IDS Proxy Firewall Protocol Parsers Session Management Contribution of reusable modules: 30 – 80 % 15

Management consolidation enables flexible resource allocation Today: All processing at logical “ingress” Process (P) Process (0.4 P) Process (0.3 P) Process (0.3 P) N3 N1 P: N1 à N3 Overload! N2 Network-wide distribution reduces load imbalance 16

Can NFV/SDN help middlebox management? Centralized Controller Web Firewall IDS Proxy OpenFlow “ Flow ” FwdAction “ Flow ” FwdAction … … … … Proxy IDS … Necessity and an Opportunity: Incorporate functions markets views as important 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

CoMb System Overview Network-wide Logically centralized Controller e.g., NOX, 4D General-purpose hardware: e.g., PacketShader, RouteBricks, ServerSwitch, Middleboxes: complex, heterogeneous, new opportunities 19

CoMb Management Layer Goal: Balance load across network. Leverage multiplexing, reuse, distribution Resource Policy Routing, Requirements Constraints Traffic Network-wide Controller Processing responsibilities 20

Capturing Reuse with HyperApps HTTP: HyperApp: find the union of apps to run 1+2 unit of CPU 1+3 units of mem HTTP: IDS & Proxy HTTP HTTP 3 4 UDP NFS Memory CPU IDS Proxy UDP: IDS 2 3 1 1 3 1 common Memory CPU Memory CPU NFS: Proxy Footprint on 4 1 Memory CPU resource Need per-packet Policy dependency are implicit policy dependencies! 21

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

Network-wide Optimization Minimize Maximum Load, Subject to Processing coverage for each class of traffic à Fraction of processed traffic adds up to 1 No explicit Dependency Load on each node Policy à sum over HyperApp responsibilities per-path 23

Network-wide Optimization A simple, tractable linear program Very close (< 0.1%) to theoretical optimal 24

CoMb Platform Applications Challenges: IDS Proxy … Performance Parallelize … Core1 Core4 Isolation Challenges: Policy Enforcer Policy Shim (Pshim) Lightweight IDS à Proxy Parallelize NIC Challenges: Classification: No contention Traffic HTTP Fast classification 25

Parallelizing Application Instances � App-per-core HyperApp-per-core M2 M3 M1 M2 M2 M3 M1 Core1 Core2 Core1 Core2 Core3 PShim PShim PShim PShim + Keeps structures core-local - Inter-core communication + Better for reuse - More work for PShim - But incurs context-switch + No in-core 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