Changes between Version 28 and Version 29 of GENIEducation/SampleAssignments/OpenFlowLoadBalancerTutorial/ExerciseLayout/Execute

Timestamp:

07/10/13 10:57:10 (11 years ago)

Author:

shuang@bbn.com

Comment:

--

GENIEducation/SampleAssignments/OpenFlowLoadBalancerTutorial/ExerciseLayout/Execute

@@ -156 +156 @@
     - '''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
     - '''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. 
-    - '''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.
-    - '''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. 
+    - '''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. Based on the latest statistics, we make our path choices.
+    - '''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. 
     - '''send_flow_mod_add()''': is the function that you should use to add a flow entry into an OpenFlow Switch. 
-  - '''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. 
-  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. 
+  - '''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. 
+  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. 
   The !FlowStatsReply message is in the following format: 
 {{{
@@ -178 +178 @@
 )
 }}}
-  - '''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` function). Also, it seems that it will take some time for the Open vSwitch to be able to report some flow statistics to the controller. In our experience, Open vSwitch will start to report flow statistics after two flows have already been established. So do not be panic when flow_stats_reply says nothing when one or two flows are already running. 
 
 == 3.3 About the GIMI script you run on !LabWiki ==