1 / 25

Scalability of Software De fi ned Network

Scalability of Software De fi ned Network. Presented by Lin Zhou&Lei Zhang. Agenda. Background of our project The Design of our project. Brief Introduction to SDN. Distributed Data plane and Control plane Data plane:enquiring,forwarding Control plane:management,route Networklization

rwalden
Download Presentation

Scalability of Software De fi ned Network

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. Scalability of Software Defined Network Presented by Lin Zhou&Lei Zhang

  2. Agenda • Background of our project • The Design of our project

  3. Brief Introduction to SDN • Distributed Data plane and Control plane • Data plane:enquiring,forwarding • Control plane:management,route • Networklization • Intellectualization • Virtualization • Computationlization

  4. The Origin of the Scalability Problems inSDN • Early benchmarks on NOX, which showed it could only handle 30,000 flow initiations per second while maintaining a sub-10 ms flow install time.

  5. Current Solutions to the Probelm • DIFANE • DevoFlow • HyperFlow • Kandoo

  6. DIFANE Model

  7. DIFANE • Advantages: (i) DIFANE achieves small delay for the firstpacket of a flow by always keeping packets in thefast path. (ii)DIFANE achieves significantly higher throughput than NOX. • Disadvantages: (i)A number of authority switches are needed forthe large networks we evaluated. (ii)DIFANE does not address the issue of globalvisibility of flow states and statistics.

  8. DevoFlow Reducing the number of flows that interact with the control-plane. • By pushing responsibility over most flows to switches and adding efficientstatistics collection mechanisms to identify significant flows, which are the only flows managed by thecentral controller

  9. DevoFlow • Advantage: It can reduce the load of the controller so that it will enlarge the scalability of the controller. • Disadvantages: (i)How many flowswould be sufficient to achieve the desiredresults indifferent environments still is aquestion. (ii)It is hard to build a efficient statistics collectionmechanisms.

  10. HyperFlow • Logically centralized • Physically distributed • Does not require any changes to theOpenFlow standard

  11. HyperFlow Model

  12. HyperFlow • Advantages: (i)Enables network operators deployany number of controllers to tune the performanceof the control plane based on their needs. (ii)Keeps the network control logic centralized and localizes all decisions to each controllerto minimize control plane response time. • Disadvantage: HyperFlow doesn't influence the number of the switches of one controller.

  13. Kandoo • Kandoo creates a two-level structure for controllers: (i) Local controllers execute local applications asclose as possible to switches (ii) A logically centralized root controller runs non-local control applications.

  14. Kandoo Model

  15. Kandoo • Advantages: Preserving scalabilitywithout changing switches. Good at dealing with local flows. • Disadvantages: Cannothelp any control applications that require networkwide state

  16. The Design of our project • Goals • a controller system can serve as many switches as possible like Hyperflow • a root controller with network-view state can serve as many switches as possible like Kandoo

  17. The Design of our project • Model Design--HMKH

  18. Details of the HMKH • Assumptions 1. The communications are all wireless and wire- less communication detail is not the coverage of this report. 2. Any switches controlled by a root controller in a site is in the control range of that root con- troller. 3. The direct neighbours of any root controller are within the communication range of the root controller.

  19. The Design of our project • Implementations of HMKH • Initiation • Periodic Communications and Failure-free Mechanism • Network Change Information

  20. Implementations of HMKH • Initiation • root controller broadcast to get its local controllers • local controllers broadcast to get its switches

  21. Implementations of HMKH • Periodic Communications and Failure-free Mechanism • root controllers periodically broadcast • local controller once getting this will respond • local controller failure • root controller failure

  22. Implementations of HMKH • Network-view State Synchronization -switches failure -split a network -interconnect networks

  23. The Design of our project • Evaluations of HMKH • the process ability for controller is k msgs/sec • n switches,each sends m msgs/sec and p percent of them need network-view state

  24. Conclusions • The scalability lies not only in how many switches a controller system can serve,but also how many switches a controller with network-view state can serve(overhead) • The number of root controllers and local controllers should be estimated or calculated given the requests from switches to minimize the overhead while satisfy the requirements

  25. Thanks and QA!

More Related