Changes between Version 2 and Version 3 of Internal/OpenFlow/FloodlightFVPort/Overview

Timestamp:

Aug 20, 2012, 6:50:23 AM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/FloodlightFVPort/Overview

@@ -8 +8 @@
 Currently, 2) is only true for modules that depend on one another. Modules that have conflicting functions cannot be loaded together on one running Floodlight instance. For example, the learning switch and forwarding modules will conflict, as they both send a PACKET_OUT to a switch - The switch will respond with a buffer error when it receives the second PACKET_OUT, since it had already sent the packet out.
 
-Without some form of management over control traffic, the same problem will still occur if two (or more) controllers on the same network are running conflicting modules. An entity such as !FlowVisor can resolve this situation by intercepting control traffic and ensuring that each controller's messages do not interfere with the others.   
+Without some form of management over control traffic, the same problem will still occur if two (or more) controllers on the same network are running conflicting modules. An entity such as !FlowVisor can resolve this situation by intercepting control traffic and ensuring that each controller's messages do not interfere with the others. The re-writing of messages has the effect of controlled network resource allocation that enables multiple controllers to share a single physical network.     
 
-This project draws an analog between the individual modules and controllers, and attempts to implement an isolation scheme within Floodlight to isolate conflicting modules, allowing them to run properly on the same controller. 
+This project draws an analog between the individual modules and controllers, and attempts to implement a version of Floodlight applies !FlowVisor's resource allocation to its modules.  
 
 == Goals ==