Changes between Version 25 and Version 26 of GENIEducation/SampleAssignments/OpenFlowLoadBalancerTutorial/ExerciseLayout/Execute


Ignore:
Timestamp:
07/08/13 13:10:48 (6 years ago)
Author:
shuang@bbn.com
Comment:

--

Legend:

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

    v25 v26  
    4040= 2. Implement a Load Balancing OpenFlow Controller =
    4141  - Files to download: [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/load-balancer.rb load-balancer.rb] [[BR]]
    42   - We will implement a Load Balancer OpenFlow Controller on node `Switch` using Trema. [[BR]]
     42  - We will implement a Load Balancer OpenFlow Controller on node "Switch" using Trema. [[BR]]
    4343  - Load balancing in computer networking is the division of network traffic between two or more network devices or paths, typically for the purpose of achieving higher total throughput than either one path, ensuring a specific maximum latency or minimum bandwidth to some or all flows, or similar purposes. For this exercise, you will design a load-balancing OpenFlow controller capable of collecting flow status data from OpenFlow switches and using it to divide traffic between dissimilar network paths so as to achieve full bandwidth utilization. [[BR]]
    4444  - An interesting property of removing the controller from an OpenFlow device and placing it in an external system of arbitrary computing power and storage capability is that decision-making for network flows based on external state becomes reasonable. Traditional routing and switching devices make flow decisions based largely on local data (or perhaps data from adjacent network devices), but an OpenFlow controller can collect data from servers, network devices, or any other convenient source, and use this data to direct incoming flows. [[BR]]
     
    5151    - '''Switch:''' This node is a Linux host running Open vSwitch. Your Load Balancing OpenFlow Controller will be running on this node as well. This is the main node that you will be working on.
    5252    - '''Traffic Shaping Nodes (Left and Right)''': These are Linux hosts with two network interfaces. You can configure netem on the two traffic shaping nodes to have differing characteristics; the specific values don’t matter, as long as they are reasonable. Use several different delay/loss combinations as you test your load balancer.
    53     - '''Aggregator''': This node is a Linux host running Open vSwitch with a switch controller that will cause TCP connections to “follow” the decisions made by your OpenFlow controller on the Switch node. So leave this node alone, you only need to implement the OpenFlow controller on node `Switch`.
     53    - '''Aggregator''': This node is a Linux host running Open vSwitch with a switch controller that will cause TCP connections to “follow” the decisions made by your OpenFlow controller on the Switch node. So leave this node alone, you only need to implement the OpenFlow controller on node "Switch".
    5454
    5555== 2.2 Linux netem ==
     
    5959}}}
    6060  Use the ''tc qdisc change'' command to reconfigure existing links,instead of ''tc qdisc add''. [[BR]]
    61   The outgoing links on node `Switch` in the provided rspec are numbered 192.168.2.1 and 192.168.3.1 for left and right, respectively.
     61  The outgoing links on node "Switch" in the provided rspec are numbered 192.168.2.1 and 192.168.3.1 for left and right, respectively.
    6262
    6363== 2.3 Balancing the Load ==
    6464  An example openflow controller that arbitrarily assigns incoming TCP connections to alternating paths can be found at [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/load-balancer.rb load-balancer.rb]. [[BR]]
    65   Log on to node `switch`, download the load balancing controller by running:
     65  Log on to node "switch", download the load balancing controller by running:
    6666{{{
    6767wget http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/ExoGENI/load-balancer.rb /root/
     
    7070 
    7171== 2.4 Use GIMI Portal to run the experiment and monitor the load balancer ==
    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:
    7474{{{
    7575###### Change the following to the correct interfaces ######
     
    7878###### Change the above to the correct interfaces ######
    7979}}}
    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.
    8383   
    8484== 2.5 Fetch experimental results from your iRods account ==
     
    152152  - Treme ruby API document: http://rubydoc.info/github/trema/trema/master/frames
    153153  - '''Functions used in our tutorial:'''
    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.
    161161  The !FlowStatsReply message is in the following format:
    162162{{{