15 744 Computer Networking L11 Middleboxes and NFV

15 -744: Computer Networking L-11 Middleboxes and NFV

Middleboxes and NFV • • Overview of NFV Challenge of middleboxes Middlebox consolidation Outsourcing middlebox functionality • Readings: • Network Functions Virtualization White Paper • Design and Implementation of a Consolidated Middlebox Architecture • Optional reading • Making Middleboxes Someone Else’s Problem 2

Outline • NFV Motivation • NFV challenges 3

Network “ 101” vs. Reality Traditional view: “Dumb” network Reality: Lots of in-network processing Appliances or Middleboxes: IDS, Firewall, Proxies, Load balancers…. 4

Need for Network Evolution New applications Evolving threats Policy constraints Performance, Security, Compliance New devices 5

Middleboxes Galore! Data from a large enterprise Type of appliance Survey across 57 network operators 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 APLOMB (SIGCOMM’ 13) 6

Key “pain points” Management Narrow interfaces Specialized boxes “Point” solutions! Increases capital expenses & sprawl Increases operating expenses Limits extensibility and flexibility 7

Middlebox management is hard! Critical for security, performance, compliance But expensive, complex and difficult to manage 8

Vision • Why cant networking get same benefits as IT and cloud world? • Commodity hardware? • Virtualization? • Consolidation 9

Network Functions Virtualisation 10

Key idea: Consolidation Two levels corresponding to two sources of inefficiency Network-wide Controller 2. Consolidate Management 1. Consolidate Platform 11

What are the grand challenges? • High performance virtual appliances? • Isolation/coexistence • Management solutions • Fault tolerance • Vendor independence/multi-vendor 12

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? 13

Consolidation at Platform-Level Today: Independent, specialized boxes Proxy Decouple Hardware and Software Firewall IDS/IPS App. Filter Commodity hardware: e. g. , Packet. Shader, Route. Bricks, Server. Switch, Switch. Blade Consolidation reduces capital expenses and sprawl 14

Consolidation reduces Cap. Ex Multiplexing benefit = Max_of_Total. Utilization / Sum_of_Max. Utilizations 15

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

Management consolidation enables flexible resource allocation Today: All processing at logical “ingress” Process (P) Process (0. 4 P) N 1 Overload! Process (0. 3 P) N 2 N 3 P: N 1 N 3 Network-wide distribution reduces load imbalance 17

Can NFV/SDN help middlebox management? Centralized Controller Web Firewall IDS “Flow” … Proxy Open. Flow Fwd. Action … … “Flow” Fwd. Action … … IDS Necessity and an Opportunity: Incorporate functions markets views as important 18

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 19

Co. Mb System Overview Network-wide Controller Logically centralized e. g. , NOX, 4 D General-purpose hardware: e. g. , Packet. Shader, Route. Bricks, Server. Switch, Middleboxes: complex, heterogeneous, new opportunities 20

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

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

Modeling Processing Coverage HTTP: Run IDS Proxy 0. 4 IDS Proxy 0. 3 HTTP N 1 N 3 N 1 N 2 N 3 What fraction of traffic of class HTTP from N 1 to N 3 should each node process? 23

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 Hyper. App responsibilities per-path No explicit Dependency Policy 24

Network-wide Optimization A simple, tractable linear program Very close (< 0. 1%) to theoretical optimal 25

Co. Mb Platform Applications IDS … Proxy Core 1 … Core 4 Policy Enforcer IDS Proxy Policy Shim (Pshim) Classification: HTTP NIC Traffic Challenges: Performance Parallelize Isolation Challenges: Lightweight Parallelize Challenges: No contention Fast classification 26

Parallelizing Application Instances App-per-core M 2 M 1 Core 1 PShim Core 2 Hyper. App-per-core M 3 Core 3 PShim - Inter-core communication - More work for PShim + No in-core context switch M 1 M 2 Core 1 PShim M 2 M 3 ✔ Core 2 PShim + Keeps structures core-local + Better for reuse - But incurs context-switch Hyper. App-per-core is better or comparable Contention does not seem to matter! 27

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? 28

Conclusions • Network evolution occurs via middleboxes • Today: Narrow “point” solutions • High Cap. Ex, Op. Ex, and device sprawl • Inflexible, difficult to extend • Our proposal: Consolidated architecture • Reduces Cap. Ex, Op. Ex, and device sprawl • Extensible, general-purpose • More opportunities • Isolation • APIs (H/W—Apps, Management—Apps, App Stack) 29