15-744: Computer Networking. Middleboxes and NFV

Transcription

1 15-744: Computer Networking Middleboxes and NFV

2 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

3 Outline NFV Motivation NFV challenges 3

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

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

6 Middleboxes Galore! Data from a large enterprise 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 Number of devices Survey across 57 network operators >100k hosts 10k-100k hosts 1k-10k hosts <1k hosts All Middleboxes L3 Routers L2 Switches APLOMB (SIGCOMM 13) 6

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

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

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

10 Network Functions Virtualisation 10

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

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

13 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

14 Consolidation at Platform-Level Today: Independent, specialized boxes Proxy Firewall IDS/IPS AppFilter Decouple Hardware and Software Commodity hardware: e.g., PacketShader, RouteBricks, ServerSwitch, SwitchBlade Consolidation reduces capital expenses and sprawl 14

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

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

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

18 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 18

19 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

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

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

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

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

24 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 24

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

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

27 Parallelizing Application Instances M1 App-per-core M2 M3 HyperApp-per-core M1 M2 M2 M3 Core1 Core2 Core3 Core1 Core2 PShim PShim - Inter-core communication - More work for PShim + No in-core context switch PShim PShim + Keeps structures core-local + Better for reuse - But incurs context-switch HyperApp-per-core is better or comparable Contention does not seem to matter! 27

28 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

29 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) 29

30 Next Lecture 2/14 Transport review 2/21 Readings: VJ congestion control TFRC Optional Many. 31

31 32