1 / 14

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 piece of network infrastructure

sherri
Télécharger la présentation

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 piece of network infrastructure But painful to manage, hard to add new functions

  3. Why should SDN community care? Aug. 2012 ONF report • Integrate SDN into production networks • APIs for functions the 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

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

  5. Challenge: Policy Composition Proxy1 Firewall1 Pkt, S2—S4: IDS1 vsDst?? Firewall IDS Proxy S2 S4 S1 Dst Src S3 IDS1 Policy routing Need more expressive data plane?

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

  7. Challenge: Resource Management Proxy1 Firewall1 Rules to “split” traffic S2 S4 Dst Src S3 S1 IDS1 = 50% IDS2 = 50% How much TCAM does this load balancing need?

  8. Solution: Joint Optimization Topology Traffic Middlebox Hardware Policy Spec Switch TCAM Resource Manager Forwarding Rules Processing Distribution Theoretically hard, but we have practical decomposition

  9. Challenge: Traffic Modifications Proxy may modify sessions Proxy1 Firewall1 S2 S4 Dst Src S3 S1 IDS1 = 50% IDS2 = 50% How can we set up the correct forwarding rules?

  10. Solution: Infer flow correlations Payload similarity algorithms Install rules Collect first 2-3 packets Correlate flows P1* P2* p1 p2 q2 q1 User 1 Proxy f1: p2 p1 User 2 p3 p4 p2* p1* p3 p4* f1’: f2’: q3 q2 q1 Time window T

  11. Challenges in SDN-Middlebox integration “Tag” processing state Policy composition Resource management Traffic modification Scalable joint optimization Tunnels for compact routing Infer flow correlations

  12. NIMBLE System Overview Web FW IDS Proxy Admin Resource Manager Dynamics Handler Forward first k pkts Rule Generator Using OpenFlow 1.0! OpenFlow-enabled Switches Legacy Middleboxes

  13. Evaluation TBD Say something about prototype Show one/two results

  14. Broader MiddleboxResearch Agenda Inflexible, not extensible SDN integration [ongoing] Consolidated Architecture [NSDI ‘12] ONS Poster Management complexity Cloud Outsourcing [SIGCOMM’12] High capital costs

More Related