| 72 | | - Log on to your !LabWiki Account on http://emmy9.casa.umass.edu:3005 , on the `Prepare` Column, type `OpenFlow`, it will pop up with a list of .rb choices. Choose any one, and replace the whole content with the ruby script [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/ExoGENI/loadbalancer_monitor.rb HERE]. |
| 73 | | - Log on to node `switch` and do `ifconfig` to see the IP addresses on each interfaces. Identify the two interfaces that you want to monitor: the interfaces with IP address 192.168.2.1 and 192.168.3.1 respectively. On the !LabWiki page, in your ruby script, find the following line: |
| | 72 | - Log on to your !LabWiki Account on http://emmy9.casa.umass.edu:3005 , on the `Prepare` Column, type "OpenFlow", it will pop up with a list of .rb choices. Choose any one, and replace the whole content with the ruby script [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/ExoGENI/loadbalancer_monitor.rb HERE]. |
| | 73 | - Log on to node "Switch" and do "ifconfig" to see the IP addresses on each interfaces. Identify the two interfaces that you want to monitor: the interfaces with IP address 192.168.2.1 and 192.168.3.1 respectively. On the !LabWiki page, in your ruby script, find the following line: |
| 80 | | - 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. |
| 81 | | - Drag the file Icon 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. |
| 82 | | - '''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. |
| | 80 | - 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. |
| | 81 | - Drag the file Icon 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. |
| | 82 | - '''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. |
| 154 | | - 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 |
| 155 | | - 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. |
| 156 | | - 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 based on the last received statistics (so we are not using the current statistics to make path decisions--there is a delay of two flows), we make our path choices. |
| 157 | | - 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 here in this function. |
| 158 | | - send_flow_mod_add(): is the function that you should use to add a flow entry into an OpenFlow Switch. |
| 159 | | - '''Process: ''' Upon the arrival of a new TCP flow, the OpenFlow controller should send out a `FlowStatsRequest` message to the OpenFlow switch. The OpenFlow switch will reply with statistics information about all flows in its flow table. |
| 160 | | 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. |
| | 154 | - '''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 |
| | 155 | - '''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. |
| | 156 | - '''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 based on the last received statistics (so we are not using the current statistics to make path decisions--there is a delay of two flows), we make our path choices. |
| | 157 | - '''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 here in this function. |
| | 158 | - '''send_flow_mod_add()''': is the function that you should use to add a flow entry into an OpenFlow Switch. |
| | 159 | - '''Process: ''' Upon the arrival of a new TCP flow, the OpenFlow controller should send out a "FlowStatsRequest" message to the OpenFlow switch. The OpenFlow switch will reply with statistics information about all flows in its flow table. |
| | 160 | 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. |
