Changes between Version 36 and Version 37 of Internal/OpenFlow/Controllers/MultiCtl

Timestamp:

Nov 30, 2012, 3:10:08 AM (11 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/MultiCtl

@@ -52 +52 @@
  * [http://winlab.rutgers.edu/~akoshibe/SDN-archs A Thought Exercise]: A "prologue" (ASCII text) page on thinking about multi-controller architecture design to get back up to speed after a hiatus.
  * [wiki:Internal/OpenFlow/Controllers/MultiCtl/FLInternals Floodlight Internals]: A summary of Floodlight internals. 
+ * [wiki:Internal/OpenFlow/Controllers/MultiCtl/VendorMsgHow OpenFlow Vendor message HOWTO]: A rundown on using and creating !OpenFlow Vendor messages in Floodlight. 
 == Logging. == #iv
 ==== (9/5): ==== #w1
@@ -361 +362 @@
 However, this makes the network transparently visible to the higher-tier controller, which, in our case, is not the virtualized controller as with !FlowVisor, but a higher-layer application. If virtualization /was/ the higher-layer application, it makes sense to make the network visible to the controller above, but for any plain application, hardware details (e.g. the network) should be something left to the low-lying logic (the lower-tier controllers). It would take some thinking before we modify this controller to make it more "!FlowVisor-like".
 
+[[BR]]      
+End of week10 :[#iv Back to Logs.]
+==== (11/27) ==== #w11
+IAB project report writeups. Implementation is on hold for now. 
+
+==== (11/29) ==== 
+Some concepts for message handling by the remote dispatcher. 
+ * SPLIT, DIVERT - the two types of operations that a new event can initially be handled with. Specified by the server side. 
+ * BYPASS - allow skip of further processing by the remote dispatcher. That is, pretend that it doesn't exist and let the process chain process it like usual. 
+ 
+Return types:
+ * OFMessage : to be sent immediately down return path. Incoming event that produces these are never BYPASSed so they always hit the dispatcher, or remote controller's process chain.
+ * !FloodlightContext : to be added to the context of the initial event, meaning the initial process chain must be preserved until the service returns. 
+ * BYPASS : add event associated with a device to the bypass list. Incoming event producing this is a device or switch. Packet_ins associated with a device being evaluated are sent up, and returned to be replayed through the process chain with its context, which must be preserved. 
+
+For bypass, device identity is specified by MAC for now, which we assume doesn't change. The important part is that there is some unique identifier that can be used to specify a device. 
+We also assume that each Packet_in is not sensitive to the handling of others, so they do not have to be processed in the order that they arrive. This is a simplifying assumption for the replay aspect of the bypass. Bypass is on a per-server basis, since some servers may still want the event even if another forgoes it.     
 ----
 [#home Home.]