1 / 70

15-744: Computer Networking

Learn about the challenges of middleboxes in computer networking and how NFV can help in consolidating and outsourcing their functionality. Explore the benefits, enablers, use cases, challenges, and real-world implementations of NFV.

jesusr
Download Presentation

15-744: Computer Networking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 15-744: Computer Networking L-12 Middleboxes and NFV

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

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

  4. ETSI NFV

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

  6. Network Functions Virtualisation

  7. Benefits • Reduced Capex • Reduced time to market • Elastic scaling • Targeted services • “Openness” (vendor neutrality..) • Streamlining operations

  8. Key Enablers • Cloud + Virtualization • Commodity/high volume servers

  9. Big Picture

  10. 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

  11. New use cases • Virtualized services for enterprises • Virtual CDNs • Virtualized mobile core networks • Cloud bursting • Integrate production/testing

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

  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?

  14. Some references on NFV/SDN in real world • AT&T Domain 2.0 Vision White Paper • ONS 2014 Keynote: John Donovan, Senior EVP, AT&T https://www.youtube.com/watch?v=tLshR-BkIas • Verizon-Carrier Adoption of Software-defined Networking, Stuart Elby, VP, Verizon https://www.youtube.com/watch?v=WVczl03edi4

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

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

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

  18. Middleboxes Galore! Data from a large enterprise Survey across 57 network operators APLOMB (SIGCOMM’13)

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

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

  21. Can NFV/SDN help middlebox management? Web Firewall IDS Proxy Centralized Controller OpenFlow Proxy IDS … Necessity and an Opportunity: Incorporate functions markets views as important

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

  23. Outline • Motivation • High-level idea: Consolidation • System design • Implementation and Evaluation

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

  25. 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

  26. Consolidation reduces CapEx Multiplexing benefit = Max_of_TotalUtilization / Sum_of_MaxUtilizations

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

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

  29. Outline • Motivation • High-level idea: Consolidation • CoMb: System design • Implementation and Evaluation

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

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

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

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

  34. 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 Policy Load on each node  sum over HyperApp responsibilities per-path

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

  36. CoMb System Overview Logically centralized e.g., NOX, 4D General-purpose hardware: e.g., PacketShader, RouteBricks, ServerSwitch, Network-wide Controller Existing work: simple, homogeneous routing-like workload Middleboxes: complex, heterogeneous, new opportunities

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

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

  39. CoMb Platform Design M1 M1 M2 M4 M4 M3 Core-local processing Workload balancing Core 1 Core 2 Core 3 M1 M5 Hyper App1 Hyper App2 Hyper App4 Hyper App3 Hyper App3 PShim PShim PShim PShim PShim Q1 Q2 Q4 Q5 Q3 NIC hardware Parallel, core-local Contention-free network I/O

  40. Outline • Motivation • High-level idea: Consolidation • System design: Making Consolidation Practical • Implementation and Evaluation

  41. Consolidation is Practical • Low overhead for existing applications • Controller takes < 1.6s for 52-node topology

  42. Benefits: Reduction in Maximum Load MaxLoadToday /MaxLoadConsolidated Consolidation reduces maximum load by 2.5-25X

  43. Benefits: Reduction in Provisioning Cost ProvisioningToday /ProvisioningConsolidated Consolidation reduces provisioning cost 1.8-2.5X

  44. 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?

  45. 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)

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

  47. Typical Enterprise Networks Internet

  48. Typical Enterprise Networks Internet

  49. Recap of middleboxes pain points • High Capital and Operating Expenses • Time Consuming and Error-Prone • Physical and Overload Failures

  50. How can we improve this?

More Related