1 / 11

Practical and Incremental Convergence between SDN and Middleboxes

Practical and Incremental Convergence between SDN and Middleboxes. Zafar Qazi Cheng-Chun Tu Luis Chiang Vyas Sekar. Rui Miao Minlan Yu. Why middleboxes ?. Data from a large enterprise. Survey across 57 network operators. Critical for security, performance, compliance

shyla
Download Presentation

Practical and Incremental Convergence between SDN and Middleboxes

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. Practical and IncrementalConvergence betweenSDN and Middleboxes ZafarQazi Cheng-Chun Tu Luis Chiang Vyas Sekar Rui Miao Minlan Yu

  2. Why middleboxes? Data from a large enterprise Survey across 57 network operators Critical for security, performance, compliance But painful to manage

  3. Why should SDN community care? Aug. 2012 ONF report • “integrate into production networks” • “APIs for functions market views as important” Survey on SDN adoption [Metzler 2012] • “use cases that justify deployment” • “add a focus on Layer 4 through Layer 7 functionality … change in the perceived value of SDN.” Middleboxes: Necessity and Opportunity for SDN

  4. Goal: SDN + Middlebox integration Centralized Controller Open APIs Can we achieve SDN-Middlebox integration: with existing SDN APIs? with unmodified middleboxes?

  5. Challenges in SDN-MB integration Firewall Proxy Proxy may modify traffic Space for traffic split? Pkt, S2—S4: IDS or Dst? Firewall IDS Proxy S2 S4 S1 S3 IDS IDS1 = 50% IDS2 = 50% Policy composition Resource constraints Traffic modifications Simple flow rules may not suffice! Are forwarding rules correct?

  6. Recap: Three main challenges Flow rules may not suffice Policy composition Is there enough rule space? Resource constraints Correctness? Traffic modifications New dimensions beyond Layer 2-3 tasks

  7. Composition  Tag Processing State Firewall Proxy IDS S4 S2 Use “state” tags in addition to header, interface info 2= Post Firewall 1=None 3=Post IDS 4 = Post Proxy

  8. Resource constraints Joint Optimization Topology & Traffic Middlebox Hardware Policy Spec Switch TCAM Resource Manager Optimal & Feasible load balancing Theoretically hard, but have practical near-optimal heuristics

  9. NIMBLE System Overview Web FW IDS Proxy Modifications Handler (Infer flow correlations) Resource Manager (Scalable joint optimization) POX extensions Rule Generator (Processing state tags, Switch tunnels) OpenFlow 1.0 OpenvSwitch 1.7.1 OpenFlow-capable Legacy Middleboxes

  10. Benefits: Load balancing Nimble Today 4-7X better load balancing without modifying middleboxes Low overhead: 0.1s to reconfigure after failure/overload

  11. SDN + Middlebox Convergence Middlebox pain points NIMBLE Practical Integration [today’s talk] High OpEx COMB Consolidation [NSDI ‘12] ONS Poster Inflexible APLOMB Cloud Outsourcing [SIGCOMM’12] High CapEx

More Related