Practical and Incremental Convergence between SDN and Middleboxes
•
1 like•405 views
This document discusses integrating software-defined networking (SDN) with middleboxes. It notes that middleboxes are critical for network functions like security and performance but are painful to manage. The SDN community should care about integration because standards bodies and surveys indicate it is important. However, integrating SDN and middleboxes poses challenges related to policy composition, traffic modifications, and resource constraints that simple flow rules may not address. The document proposes using state tags and joint optimization techniques to help overcome these challenges and achieve the goal of practical SDN and middlebox integration.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Practical and Incremental Convergence between SDN and Middleboxes
Similar to Practical and Incremental Convergence between SDN and Middleboxes (20)
More from Open Networking Summits
More from Open Networking Summits (20)
Recently uploaded
Recently uploaded (20)
Practical and Incremental Convergence between SDN and Middleboxes
- 3. Practical and Incremental Convergence between SDN and Middleboxes 1 Zafar Qazi Cheng-Chun Tu Luis Chiang Vyas Sekar Rui Miao Minlan Yu
- 4. Type of appliance Number Firewalls 166 Intrusion detection 127 Media gateways 110 Load balancers 67 Proxies 66 VPN gateways 45 WAN Optimizers 44 Voice gateways 11 Total Middleboxes 636 Total routers ~900 Why middleboxes? Data from a large enterprise Survey across 57 network operators Critical for security, performance, compliance But painful to manage 2
- 5. Why should SDN community care? 3 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
- 6. 4 Goal: SDN + Middlebox integration Centralized Controller “Flow” FwdAction … … “Flow” FwdAction … … Can we achieve SDN-Middlebox integration: with existing SDN APIs? with unmodified middleboxes? Open APIs
- 7. Challenges in SDN-MB integration 5 S1 S2 S4 S3 Proxy IDS Firewall Pkt, S2—S4: IDS or Dst ? Resource constraintsTraffic modificationsPolicy composition Firewall IDS Proxy IDS1 = 50% IDS2 = 50% Are forwarding rules correct? Proxy may modify traffic Space for traffic split? Simple flow rules may not suffice!
- 8. Recap: Three main challenges Policy composition 6 Is there enough rule space? Correctness? Flow rules may not suffice New dimensions beyond Layer 2-3 tasks Traffic modifications Resource constraints
- 9. 2= Post Firewall Composition Tag Processing State 7 Firewall Proxy IDS 1=None 3=Post IDS 4 = Post Proxy S2 S4 Use “state” tags in addition to header, interface info
- 10. Resource constraints Joint Optimization 8 Resource Manager Topology & Traffic Switch TCAM Middlebox Hardware Policy Spec Optimal & Feasible load balancing Theoretically hard, but have practical near-optimal heuristics
- 11. FW IDS ProxyWeb Rule Generator (Processing state tags, Switch tunnels) Resource Manager (Scalable joint optimization) Modifications Handler (Infer flow correlations) NIMBLE System Overview Legacy Middleboxes OpenFlow-capable OpenFlow 1.0 Flow Tag/Tunnel Action … … Flow Tag/Tunnel Action … … POX extensions OpenvSwitch 1.7.1 9
- 12. Benefits: Load balancing 10 Nimble Today 4-7X better load balancing without modifying middleboxes Low overhead: 0.1s to reconfigure after failure/overload
- 13. SDN + Middlebox Convergence 11 High OpEx Inflexible High CapEx COMB Consolidation [NSDI ‘12] ONS Poster APLOMB Cloud Outsourcing [SIGCOMM’12] NIMBLE Practical Integration [today’s talk] Middlebox pain points