Changes between Version 3 and Version 4 of GENIEducation/SampleAssignments/OpenFlowLoadBalancerTutorial/ExerciseLayout/Execute
- Timestamp:
- 06/20/13 14:22:47 (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GENIEducation/SampleAssignments/OpenFlowLoadBalancerTutorial/ExerciseLayout/Execute
v3 v4 21 21 22 22 = Debugging an OpenFlow Controller = 23 You will find it helpful to know what is going on inside your OpenFlow controller and its associated switch when implementing these exercises. 23 You will find it helpful to know what is going on inside your OpenFlow controller and its associated switch when implementing these exercises. [[BR]] 24 24 This section contains a few tips that may help you out if you are using the Open vSwitch implementation provided with this tutorial. 25 25 If you are using a hardware OpenFlow switch, your instructor can help you find equivalent commands. [[BR]] … … 41 41 = Exercises = 42 42 - '''Load Balancing''' -- Files to download: [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/load-balancer.rb load-balancer.rb] [[BR]] 43 We will implement a Load Balancer OpenFlow Controller on node `Switch` using Trema. 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]] 43 We will implement a Load Balancer OpenFlow Controller on node `Switch` using Trema. [[BR]] 44 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]] 44 45 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]] 45 46 For the purpose of this exercise, data collection will be limited to the flow statistics reported by open vswitches. … … 119 120 '''If you really do not know where to start, you can find the answer [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/ExoGENI/load-balancer.rb HERE]''' [[BR]] 120 121 121 '''Question 2: Modify your load balancer so that it decides path based on the average per-flow throughput observed on each path''' 122 '''Question 2: Modify your load balancer so that it decides path based on the average per-flow throughput observed on each path. ''' [[BR]] 123 '''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? ''' 122 124 123 125 '''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).