Changes between Version 53 and Version 54 of Internal/OpenFlow/Controllers/MultiCtl

Timestamp:

Mar 2, 2013, 12:35:31 AM (11 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/MultiCtl

@@ -481 +481 @@
 
 ==== w/o 2/24-3/2 ==== #w23
+'''2/28''' [[BR]]
+
 Many revisions to things:
  * update to Mininet 2.0.0 
@@ -502 +504 @@
     * invisibility of peers to one another, since we don't want peers to ask each other for services they don't host. Peers do not show up in each others' route tables.
     * service advertisement propagation, across to peers that don't see the service.    
+
+'''3/1''' [[BR]]
+We re-visit and revise the event filter/dispatch subsystem. This is layer 3 in our control node.
+
+ 1. Event Types - the types of events we can receive from Floodlight's core system.
+   * switch - new, port change, removed
+   * message - various !OpenFlow messages: we stick to Packet_In, Port_Stat, Vendor (custom messages), each a separate event 
+   * device - new, removed, changed ( IP, VLAN, MOVED )
+   * all - everything above  
+
+ 2. Filter Types - the fields of things to match an event on. Varies with the type of event. We want a stable basis, and let the remote services take care of the finer details. Off the top of the mind: 
+   * switch - DPID, current event trigger switch
+   * device - MAC, current event trigger device, DPID of attachment
+   * Packet_Ins - certain device (or event trigger device), certain switch (event trigger switch) - by MAC and DPID, respective (we're narrowing our choices for sanity)  
+   * Port_Status - ???
+   * Vendor - Vendor ID
+   * all - anything in that event
+
+ 3. Process chain operations, associated with each server (sID), after we send it off to our service provider:
+   * ALLOW - just a server telling us to carry on with local processing of the message. Don't write out, just return CONTINUE
+   * SPLIT - keep processing after sending up - write out and return CONTINUE
+   * DIVERT - stop processing the message, don't continue until the server answers - write out, save message context (indicate it had been DIVERTED so it can be resumed upon return), return STOP
+   * DENY - a server wanting us to just drop the message. Don't write out, return STOP. 
+
+ These return consensus-driven CONTINUE or STOP commands if multiple servers are interested in one event type. In general, we want to be conservative - STOP-related ops like DIVERT take precedence over Continue-related ops like SPLIT. Basically all of these are ANDed together. 
+
+Dispatcher behavior algorithm.  
+[[Image(dispatch-algo.png)]]
 ----
 [#home Home.]