Changes between Version 48 and Version 49 of GENIEducation/SampleAssignments/OpenFlowLoadBalancerTutorial/ExerciseLayout/Execute


Ignore:
Timestamp:
07/15/13 14:58:51 (11 years ago)
Author:
shuang@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GENIEducation/SampleAssignments/OpenFlowLoadBalancerTutorial/ExerciseLayout/Execute

    v48 v49  
    5555}}}
    5656   - Change eth1 and eth3 to the corresponding two interfaces you found with IP address 192.168.2.1 (the interface that connects to the left path) and 192.168.3.1 (the interface that connects to the right path) and press the "save" icon on your !LabWiki page.
    57    - Drag the `file Icon` at the left-top corner on your !LabWiki page from `Prepare` column and drop it to `Execute` column. Fill in the name of your !LabWiki experiment (this can be anything), the name of your slice (this has to be your slice name), and type "true" in the graph box to enable graph. And then press "Start Experiment" button.
     57   - Drag the `file Icon` at the left-top corner on your !LabWiki page from `Prepare` column and drop it to `Execute` column. Fill in the name of your !LabWiki experiment (this can be anything), the name of your slice (this has to be your slice name), and type "true" in the graph box to enable graphs. And then press "Start Experiment" button.
    5858   - '''Note''': Do not start another experiment (i.e., drag and drop the file icon in !LabWiki and press "Start Experiment") before your current experiment is finished.
    5959   
     
    8787 Questions:
    8888 - Did you see any difference from the graphs plotted on !LabWiki, compared with the graphs plotted in the first experiment? why?
    89  - Check out the OpenFlow Load Balancing Controller's Log on node "Switch" at "/tmp/lb.tmp" and tell how many flows are directed to the left path and how many are on the right path, why?
    90  - To answer the above question, you need to understand the Load Balancing controller. Check out the "load-balancer.rb" file in your home directory on node "Switch". Check Section 3 for hints/explanations about this OpenFlow Controller.
    91 
    92 ==  2.6 Modify the OpenFlow Controller to balance throughput among all the TCP flows ==
     89 - Check out the output of the Load Balancer on node "Switch" and tell how many flows are directed to the left path and how many are on the right path, why?
     90 - To answer the above question, you need to understand the Load Balancing controller. Check out the "load-balancer.rb" file in your home directory on node "Switch". Check Section 2 for hints/explanations about this OpenFlow Controller.
     91
     92== 1.7 Automate your experiment using !LabWiki ==
     93 - Stop the Load Balancer:
     94  - On node "Switch", use the following command to disconnect the OpenFlow Switch from the controller:
     95  {{{
     96  ovs-vsctl del-controller br0
     97  }}}
     98  - On node "Switch", press "Ctrl" and "c" key to kill your Load Balancer process on node "Switch"
     99 - Add code in your !LabWiki script to automate starting and stoping your OpenFlow Controller:
     100  - Go back to your !LabWiki page, un-comment the script from line 184 to line 189 to start your OpenFlow Controller automatically on !LabWiki
     101  - Uncomment the script from line 209 to line 213 to stop your OpenFlow Controller automatically on !LabWiki
     102 - On your !LabWiki web page, drag and drop the `file icon` and repeat the experiment, as described in section 2.3, using a different experiment name (the slice name should stay the same).
     103
     104==  1.8 Modify the OpenFlow Controller to balance throughput among all the TCP flows ==
    93105 - You need to calculate the average per-flow throughput observed from both left and right path in function "stats_reply" in your load-balancer.rb
    94106 - In function "packet_in", change the path decision based on the calculated average per-flow throughput: forward the flow onto the path with more average per-flow throughput. (Why? TCP tries its best to consume the whole bandwidth so more throughput means network is not congested)
    95  - If you do not know where to start, check the hints in Section 3.
    96   - If you really do not know where to start after reading the hints, download the answer directly from [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/ExoGENI/load-balancer-solution.rb Here].
    97   - Save the above solution as "load-balancer.rb" in your home directory then re-do the experiment on !LabWiki.
    98  - Redo the above experiment (the one with some lossrate on the left path), check the graphs plotted on !LabWiki as well as the controller's log on node "Switch" at /tmp/lb.tmp and see the difference.
    99  - If you have more time or are interested in trying out things, go ahead and try section 2.7. The tutorial is over now and feel free to ask questions :-)
    100 
    101 == 2.7 Try more experiments using different kinds of OpenFlow Load Balancers ==
     107 - If you do not know where to start, check the hints in Section 2.
     108  - If you really do not know where to start after reading the hints, download the answer directly from [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/ExoGENI/load-balancer-solution.rb load-balancer-solution.rb].
     109  - Save the above solution in your home directory then re-do the experiment on !LabWiki. '''Note:''' you need to change your !LabWiki script at line 185 to use the correct Load Balancing controller (e.g., if your controller is "load-balancer-solution.rb", you should run "/opt/trema-trema-f995284/trema run /root/load-balancer-solution.rb > /tmp/lb.tmp")
     110 - Redo the above experiment, check the graphs plotted on !LabWiki as well as the controller's log on node "Switch" at /tmp/lb.tmp and see the difference.
     111 - If you have more time or are interested in trying out things, go ahead and try section 1.9. The tutorial is over now and feel free to ask questions :-)
     112
     113== 1.9 Try more experiments using different kinds of OpenFlow Load Balancers ==
    102114 - You can find more load balancers from http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/ExoGENI/load-balancer/
    103115 - To try out any one of them, follow the steps:
     
    106118  wget http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/ExoGENI/load-balancer/load-balancer-random.rb /root/
    107119  }}}
    108   - rename this load balancer to "load-balancer.rb" by:
    109   {{{
    110   cp load-balancer-random.rb load-balancer.rb
    111   }}}
     120  - Change your !LabWiki code at line 185 to use the correct OpenFlow controller.
    112121  - On !LabWiki, drag and drop the "File" icon and re-do the experiment as described in section 2.3
    113122 - Some explanations about the different load balancers:
     
    120129  - Load balancers that begin with "load-balancer-throughput" picks path based on the total throughput sent out to each path: the one with '''more throughput''' is picked
    121130
    122 = 3. Hints / Explanation =
    123 == 3.1 About The Rspec file [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/openflow-loadbalancer-kvm.rspec OpenFlowLBExo.rspec] ==
     131= 2. Hints / Explanation =
     132== 3.2 About the OpenFlow controller [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/ExoGENI/load-balancer.rb load-balancer.rb] ==
     133  - Trema web site: http://trema.github.io/trema/
     134  - Treme ruby API document: http://rubydoc.info/github/trema/trema/master/frames
     135  - '''Functions used in our tutorial:'''
     136    - '''start''': is the function that will be called when the OpenFlow Controller is started. Here in our case, we read the file /tmp/portmap and figures out which OpenFlow port points to which path
     137    - '''switch_ready''': is the function that will be called each time a switch connects to the OpenFlow Controller. Here in our case, we allow all non-TCP flows to pass (including ARP and ICMP packets) and ask new inbound TCP flow to go to the controller.
     138    - '''packet_in''': is the function that will be called each time a packet arrives at the controller. Here in our case, we send out a flow_stats_request to get the current statistics about each flow. Then waits for the latest TCP flow stats. Here we create another thread to wait for the stats reply so that the controller is not blocked. It calls "decide_path()" to get path decisions.
     139    - '''stats_reply''': is the function that will be called when the OpenFlow Controller receives a flow_stats_reply message from the OpenFlow Switch. Here in our case, we update the flow statistics then signal the thread created in "packet_in" to continue.
     140    - '''send_flow_mod_add()''': is the function that you should use to add a flow entry into an OpenFlow Switch.
     141    - '''decide_path()''': is the function that makes path decisions. It returns the path choices based on flow statistics.
     142  - '''The Whole Process: ''' Upon the arrival of a new TCP flow, the OpenFlow controller sends out a "FlowStatsRequest" message to the OpenFlow switch. The OpenFlow switch will reply with statistics information about all flows in its flow table.
     143  This flow statistics message will be fetched by the "stats_reply" function in the OpenFlow controller implemented by the user on node "Switch". Based on the statistics, experimenters can apply their own policy on which path to choose in different situations.
     144  The !FlowStatsReply message is in the following format:
     145{{{
     146FlowStatsReply.new(
     147  :length => 96,
     148  :table_id => 0,
     149  :match => Match.new
     150  :duration_sec => 10,
     151  :duration_nsec => 106000000,
     152  :priority => 0,
     153  :idle_timeout => 0,
     154  :hard_timeout => 0,
     155  :cookie => 0xabcd,
     156  :packet_count => 1,
     157  :byte_count => 1,
     158  :actions => [ ActionOutput.new ]
     159)
     160}}}
     161
     162== 2.2 About The Rspec file [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/openflow-loadbalancer-kvm.rspec OpenFlowLBExo.rspec] ==
    124163  - The Rspec file describes a topology we showed earlier--each node is assigned with certain number of interfaces with pre-defined IP addresses
    125164  - Some of the nodes are loaded with softwares and post-scripts. We will take node "Switch" as an example since it is the most complicated one.
     
    165204   }}}
    166205
    167 == 3.2 About the OpenFlow controller [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/ExoGENI/load-balancer.rb load-balancer.rb] ==
    168   - Trema web site: http://trema.github.io/trema/
    169   - Treme ruby API document: http://rubydoc.info/github/trema/trema/master/frames
    170   - '''Functions used in our tutorial:'''
    171     - '''start''': is the function that will be called when the OpenFlow Controller is started. Here in our case, we read the file /tmp/portmap and figures out which OpenFlow port points to which path
    172     - '''switch_ready''': is the function that will be called each time a switch connects to the OpenFlow Controller. Here in our case, we allow all non-TCP flows to pass (including ARP and ICMP packets) and ask new inbound TCP flow to go to the controller.
    173     - '''packet_in''': is the function that will be called each time a packet arrives at the controller. Here in our case, we send out a flow_stats_request to get the current statistics about each flow. Then waits for the latest TCP flow stats. Here we create another thread to wait for the stats reply so that the controller is not blocked. It calls "decide_path()" to get path decisions.
    174     - '''stats_reply''': is the function that will be called when the OpenFlow Controller receives a flow_stats_reply message from the OpenFlow Switch. Here in our case, we update the flow statistics then signal the thread created in "packet_in" to continue.
    175     - '''send_flow_mod_add()''': is the function that you should use to add a flow entry into an OpenFlow Switch.
    176     - '''decide_path()''': is the function that makes path decisions. It returns the path choices based on flow statistics.
    177   - '''The Whole Process: ''' Upon the arrival of a new TCP flow, the OpenFlow controller sends out a "FlowStatsRequest" message to the OpenFlow switch. The OpenFlow switch will reply with statistics information about all flows in its flow table.
    178   This flow statistics message will be fetched by the "stats_reply" function in the OpenFlow controller implemented by the user on node "Switch". Based on the statistics, experimenters can apply their own policy on which path to choose in different situations.
    179   The !FlowStatsReply message is in the following format:
    180 {{{
    181 FlowStatsReply.new(
    182   :length => 96,
    183   :table_id => 0,
    184   :match => Match.new
    185   :duration_sec => 10,
    186   :duration_nsec => 106000000,
    187   :priority => 0,
    188   :idle_timeout => 0,
    189   :hard_timeout => 0,
    190   :cookie => 0xabcd,
    191   :packet_count => 1,
    192   :byte_count => 1,
    193   :actions => [ ActionOutput.new ]
    194 )
    195 }}}
    196 
    197 == 3.3 About the GIMI script you run on !LabWiki ==
     206== 2.3 About the GIMI script you run on !LabWiki ==
    198207 - Line 1 to Line 140: the definition of oml trace and oml nmetrics library. It basically defines the command line options for oml2-trace and oml2-nmetrics, as well as the output (the monitoring data that is going to be stored into the oml server)
    199208  - users are not supposed to modify them
     
    229238  - The second graph uses the monitoring results from oml2-trace to display the throughput observed from each of the interfaces.
    230239
    231 = Tips: Debugging an OpenFlow Controller =
     240= 3. Tips: Debugging an OpenFlow Controller =
    232241You will find it helpful to know what is going on inside your OpenFlow controller and its associated switch when implementing these exercises. [[BR]]
    233242This section contains a few tips that may help you out if you are using the Open vSwitch implementation provided with this tutorial.