Changes between Version 5 and Version 6 of GENIEducation/SampleAssignments/OpenFlowLoadBalancerTutorial/ExerciseLayout/Execute


Ignore:
Timestamp:
06/25/13 12:23:01 (6 years ago)
Author:
shuang@bbn.com
Comment:

--

Legend:

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

    v5 v6  
    6464
    6565  '''Balancing the Load''' [[BR]]
    66   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] (If you have already downloaded it, ignore this). [[BR]]
    67   The goal of your OpenFlow controller will be to achieve full bandwidth utilization of the two links between the OpenFlow switch and the Aggregator host. In order to accomplish this, your OpenFlow switch will intelligently divide TCP flows between the two paths. The intelligence for this decision will come from the flow statistics reports from the open vswitch on node `Switch`. [[BR]]
    68   The binding of OpenFlow port numbers to logical topology links can be found in the file /tmp/portmap on the switch node when the provided RSpec boots. It consists of three lines, each containing one logical link name (left, right, and outside) and an integer indicating the port on which the corresponding link is connected. You may use this information in your controller configuration if it is helpful. [[BR]]
    69   You will find an example OpenFlow controller that arbitrarily assigns incoming TCP connections to alternating paths in the file [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/load-balancer.rb load-balancer.rb]. This simple controller can be used as a starting point for your controller if you desire. Examining its behavior may also prove instructive; you should see that its effectiveness at achieving the assignment goals falls off as the imbalance between balanced link capacities or delays grows.
     66  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]]
     67   Log on to node `switch`, download the load balancing controller by running:
     68{{{
     69wget http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/ExoGENI/load-balancer.rb /root/
     70}}}
     71   (If you have already downloaded it, ignore this)
     72 
     73   '''Run the experiment and monitor the load balancer''' [[BR]]
     74   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]. [[BR]]
     75   
     76   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.
     77   
    7078
    71   '''Gathering Information''' [[BR]]
    72   The information you will use to inform your OpenFlow controller about the state of the two load-balanced paths will be gathered via sending OpenFlow `FlowStatsRequest` from the OpenFlow controller to the OpenFlow switch and then collecting OpenFlow `FlowStatsReply` message from the OpenFlow switch to the OpenFlow controller. For more information about !FlowStatsRequest and !FlowStatsReply, please refer to http://rubydoc.info/github/trema/trema/master/Trema/FlowStatsRequest and http://rubydoc.info/github/trema/trema/master/Trema/FlowStatsReply. [[BR]]
    73 
    74   '''Question 1: Implement your load-balancer.rb, run it on ''switch'' using the following command: '''
    75 {{{
    76 /opt/trema-trema-f995284/trema run load-balancer.rb
    77 }}} 
    78   Your load balancer should display the total number of bytes sent to the left and right paths when a new TCP flow comes and forward the new TCP flow to the path with less number of bytes transferred. [[BR]]
    79   A sample output is as follows: [[BR]]
    80 {{{
    81 [stats_reply]-------------------------------------------
    82 left path: packets 3890, bytes 5879268
    83 right path: packets 7831, bytes 11852922
    84 since there are more bytes going to the right path, let's go *LEFT* for this flow
    85 }}}
    86   You can use iperf to generate TCP flows from ''outside'' node to ''inside'' node:
    87  -
    88   - On ''inside'', run:
    89 {{{
    90 iperf -s
    91 }}}
    92   - On ''outside'' run the following command multiple times, with several seconds interval between each run:
    93 {{{
    94 iperf -c 10.10.10.2 -t 600 &
    95 }}}
    96   The above command starts a new TCP flow from outside to inside, that runs for 600 seconds.
    97 
    98   '''Hints:'''
     79  '''Hints on the OpenFlow controller Script load-balancer.rb:'''
    9980  -
    10081    - Remember that the default OpenFlow policy for your switch or Open vSwitch instance will likely be to send any packets that do not match a flow spec to the controller, so you will have to handle or discard these packets.
     
    120101}}}
    121102 
    122  Note: there is some delay in fetching the flow statistics. The OpenFlow controller may not be able to receive any !FlowStatsReply message before two flows are established.
    123  
    124  '''If you really do not know where to start, you can find the answer for Question 1 [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/ExoGENI/load-balancer.rb HERE]''' [[BR]]
    125  
    126  '''Question 2: Modify your load balancer so that it decides path based on the average per-flow throughput observed on each path. ''' [[BR]]
    127  '''Question 3: Which path should the controller send the new TCP flow to? The one with less average per-flow throughput or the other? Why? '''
    128  
    129103 '''Note: ''' since Trema does not yet support multi-thread mode, this simple implementation runs in one thread. As a result, users will experience some delay in fetching the flow statistics (i.e., `stats_reply` will not be called right after a !FlowStatsRequest message has been sent in `packet_in` handler).
    130104