Power point
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Power point

on

  • 321 views

 

Statistics

Views

Total Views
321
Views on SlideShare
321
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Let’s talk about facts FIRST FACT: OpenFlow is a hype and growing protocol with great potentials its powerful consists of the infinite possibilities that it gives, but this also makes it so complex for users, that have to mix competences of programming and network engineering The so called routing is one of the two basic modules that allow the forwarding of packets Powerful but tricky because it requires an in-depth knowledge of other modules (topology, devices, ....) Learning switch, the second module use to forward packet is easier than routing Beginners start from here experimenting the protocol (so rule, actions....) It is also useful to create and debug new modules without having a complex forwarding logic
  • Fact 2: Fail-over mechanisms require physical loops without the usage of loop-free-technologies -> broadcast storm (ARP, broadcast or multicast protocol....) Common switches use the spanning tree protocol to prevent these kind of situation OF specific says that OF switches show support STP and export the STP_bit to the controller, but most of the virtual switches don’t moreover ususaly controllers can’t intercept and manage these kind of messages coming from the switches PROBLEM: ...leggi slide
  • We neeed a Plug&Play solution, easy to integrate for beginners as well that makes possible the usage of learning switch with looped topologies, as well if the switches don’t support STP So WE thought to build the MST of the network then deactivating ports outside the minimum spanning tree just computed With these algorithm the goal would be preventing broadcast storm adopting lopped topologies, offering failover mechanisms and saving energy turning electrically off the ports of the switches
  • - Let’s see how the GreenMST works This is the flow diagram that represents the algorithm CLICK -> each time the controller listen for a new topology change between switches, it generates a linkUpdate event link update event messege contains informations reguarding the change (link added, link removed, .... Which link..) CLICK -> As soon as the linkupdate event arrives, the Minimum Spanning Tree of the updated topology is calculated using the Kruskal algorithm When the computation ends CLICK ports outside the calculated MST are turned off at the same time ports that before were closed, now useful for the new MST are re-opened Once acted on ports their current status (CLICK) is saved for optimization reasons and (CLICK) the system return to the initial state, listening for new linkupdate event
  • This is a modular view of the solution proposed CLICK -> The already existent topology module keeps the status of the topology updated receiving LLDP notifications Each time a change occurs a new LinkUpdate event is promulgated to the other modules listening for it CLICK -> The GreentMST module intercept the linkUpdate messeges Computes the MST on the new topology informations and turn off/on the ports using the modport command CLICK -> Upper, Learning switch continues to work normaly receiving the PacketIn events from the switches and sending out PacketOuts and flowMods
  • Spiega come funziona tutto As I was telling you before we build an additional structure has been added to save the last status of the port Port status is saved after each MST computation to do not send a message when it is unusefull

Power point Presentation Transcript

  • 1. Energy efficent MST inOpenFlow networksEuropean Workshop on Software Defined NetworkL. Prete, F. Farina, M. Campanella, A. BianciniDarmstadt, 26th Oct 2012
  • 2. OUTLINE Motivation: OF, LearningSwitch module and loops The proposed solution Implementation and the virtual test-bed Measurements and validation Future works and conclusions 2 L. Prete, F. Farina, M. Campanella, A. Biancini Darmstadt, 26th Oct 2012
  • 3. Fact 1: OpenFlow and modules OpenFlow is growing protocol with great potentials  Powerful but still too complex  Users experience difficulties in the use of modules The routing module is difficult and tricky  Powerful...  ...but it requires in-depth knowledge of topology, devices, cluster, ... The learning Switch is easier than Routing module. Useful to:  Experiment the power of the protocol (rules, actions, ...)  Build and integrate new modules 3 L. Prete, F. Farina, M. Campanella, A. Biancini Darmstadt, 26th Oct 2012
  • 4. Fact 2: OpenFlow and loop free technologies Fail-over mechanisms require topologies with physical loops Without loop-free technologies broadcast storms  ARP requests, any broadcast or multicast based protocol, ... “Common” L2 switches use the Spanning Tree Protocol  Software OF switches should export the STP_bit, but most of them DON’T! Problem:  Lack of a loop free technology using OF learning switch module 4 L. Prete, F. Farina, M. Campanella, A. Biancini Darmstadt, 26th Oct 2012
  • 5. From a need to the idea Need  LearningSwitch + looped topologies + non-STP switches  Simple Plug&Play solution for beginners Idea  Build the Minimum Spanning Tree of the network  Turn off ports outside MST Goal  Prevent broadcast storm  Offer failover mechanisms  Save energy 5 L. Prete, F . Farina, M. Campanella, A. Biancini Darmstadt, 26th Oct 2012
  • 6. GreenMST: how it works Link between switches changes: linkUpdate event After each topology change recalculate Minimum Spanning Tree  MST is computed using the Kruskal algorithm Ports status is modified  Open ports not included in the MST are closed  Closed ports included in the MST are opened 6 L. Prete, F. Farina, M. Campanella, A. Biancini Darmstadt, 26th Oct 2012
  • 7. GreenMST: the proposed solutionModular approachTopology keeps the switch map updated and it sends updates to the GreenMST module when a link changesGreen MST computes the new MST using current topology information and itsends ModPort actions to the switchesLearningSwitch module continues to work normally, sending packets onlythrough the opened ports 7 L. Prete, F. Farina, M. Campanella, A. Biancini Darmstadt, 26th Oct 2012
  • 8. MST computation and Change Set Saved 3-2 closed Ports status saved in a data structure  Minimization of ModPort commands to the switches 8 L. Prete, F. Farina, M. Campanella, A. Biancini Darmstadt, 26th Oct 2012
  • 9. Implementation: the virtual testbed OF out-of-band network Users’ network Goal: experiment OpenFlow features and potentialities 9 L. Prete, F. Farina, M. Campanella, A. Biancini Darmstadt, 26th Oct 2012
  • 10. Implementation: Software used OpenvSwitch Beacon controller Enterprise  Java functionalities  Multi-platform Used by different Thread-oriented +  hypervisors, es. Xen  Used in large testbed (>150 switch)  Modular 10 L. Prete, F. Farina, M. Campanella, A. Biancini Darmstadt, 26th Oct 2012
  • 11. Experiment 1 – ARP request MST module is loaded (t = 37,4s) Redundant ARP requests disappear (t = 37,76s) From the point of view of OVS01 (one of the switches) after a PING  [t0 - t(37,3)] => observation window without MST module  t(37,4) => MST module is loaded  t(37,76) => redundant ARP requests disappear Final MST + ModPort actions end after 0,36 sec 11 L. Prete, F. Farina, M. Campanella, A. Biancini Darmstadt, 26th Oct 2012
  • 12. Experiment 2 – switch activation A B C D From the point of view of the controller  t0 => GreenMST module is loaded and MST is calculated => No switches are active  tA,B,C,D => Switches are activated => MST is re-calculated and ports status is modified (except for OVS01) 12 L. Prete, F. Farina, M. Campanella, A. Biancini Darmstadt, 26th Oct 2012
  • 13. Experiment 3 – Link status change A B From the point of view of the controller  t0 => Network is stable and MST is already calculated  tA => Link between OVS03 and OVS04 is deactivated  New MST calculated in 7 ms  tB => Link between OVS03 and OVS04 is re-activated  New MST calculated in 9 ms 13 L. Prete, F. Farina, M. Campanella, A. Biancini Darmstadt, 26th Oct 2012
  • 14. Conclusions and future works Now  Enable loop free technologies and failover mechanisms for Learning Switch OF modules  As well if the devices do not support the STP technology!  Save energy turning dynamically off the unused ports of the switches In the future  Assign dynamically a cost to the links between the switches using link parameters (bandwidth, delay, jitter)  ...but also SNMP or passive flow monitoring protocols (Netflow, sFlow, ...)  Memorize the alternative paths between two nodes before a fail  After a fail the alternative path is chosen  Integration with the Routing module 14 L. Prete, F. Farina, M. Campanella, A. Biancini Darmstadt, 26th Oct 2012
  • 15. THANK YOU QuestionGet the codehttps://github.com/LucaPrete/GreenMST 15 L. Prete, F. Farina, M. Campanella, A. Biancini Darmstadt, 26th Oct 2012
  • 16. Reference Project page: https://github.com/LucaPrete/GreenMST OpenFlow official site: http://www.openflow.org Open vSwitch: http://www.openvswitch.org Controller  Beacon: https://openflow.stanford.edu/display/Beacon/Home 16 L. Prete, F. Farina, M. Campanella, A. Biancini Darmstadt, 26th Oct 2012