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 == |
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 == |
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 | {{{ |
| 146 | FlowStatsReply.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] == |
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 == |