Changes between Version 5 and Version 6 of Internal/OpenFlow/topoMapping

Timestamp:

Aug 13, 2012, 6:28:39 AM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/topoMapping

@@ -22 +22 @@
   * ''network'' : via !OpenFlow e.g. a Floodlight module that takes a topology description and pushes static flows, or even CLI.  
 
+The overall architecture will possibly work as follows:
+
+[[Image(topologizer.png)]]
+
 == Components Overviews ==
 This section contains some initial design considerations for the various components listed above. 
 ==== !OpenFlow topology setup ==== 
-It is assumed that [http://floodlight.openflowhub.org Floodlight] will be used for development. Several methods to enforce topology using SDN methods come to mind:
+It was assumed that [http://floodlight.openflowhub.org Floodlight] will be used for development. Several methods to enforce topology using SDN methods come to mind:
  1. '''''re-writing switch capabilities''''' : expose just the switch ports included in the desired topology to the modules involved in the experiment. This may be done by over-writing the FEATURE_REPLY messages that the controller receives from the switches during the initial handshake. Forging FEATURE_REPLY messages may be needed if topologies need to be dynamic. 
  
@@ -31 +35 @@
  
  3. '''''modified forwarding module''''' : A Floodlight module that behaves like the forwarding module, but alters its forwarding behavior based on the topology file. This module would replace any other routing/forwarding module.         
+
+ 4. '''''dpctl''''' : A controller/switch independent tool for pushing static flows. 
+
+In any case, high-priority static entries would work for the best. As `dpctl` is the most device/controller independent, it will be used for configuration. 
+
+