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

Timestamp:

Nov 21, 2012, 4:41:19 AM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/MultiCtl

@@ -345 +345 @@
 Future works: It is good to speculate on what can be made of this platform, given that it is a feasible one; One improvement to consider would be discovery-based startups, where the controllers do not need to be instructed who their neighbors are. This implies that advertisements are used to announce capabilities, and clients decide which services they require and choose based on the advertisements they hear on the wire. Connections can switch to dedicated stream once controllers choose their services.      
 
+==== (11/20) ====
+XID translation, comparison to !FlowVisor, and why it has a "better design", in terms of traditional distributed control planes. 
+
+XID translation is used as a way to map the incoming message's XID to a source and destination. This allows a message that has departed from one controller, and a response message, to retain the same XID to make it easy to track the origin of the original message. !FlowVisor uses this technique to track the origin slice of messages. Our case is a bit convoluted for the following reasons:
+ * The origin switch/client of a message is only known to the dispatch module, which receives all messages and routes them to the appropriate destination server. This means that we are not able to keep track of the switch/client generating the event. 
+ * XIDs are modified by the controller. Therefore, tracking sessions by the XID of the switch/client is impossible, unless we change the controller's behavior, possibly breaking protocol. 
+
+!FlowVisor takes this into account through its architecture; The Classifiers, representing each switch, are coupled to each slice that the respective switches are part of. This allows all return path packets to pass through the classifier from which it originated, allowing the determination of the source "for free". This only leaves determination of the correct destination (e.g. slice) up in the air, and this is solved by the use of XID translation based on the messages originating from the slices. 
+
+Adopting this architecture may make things "easier", if possible. This requires several changes:
+ * A DStreamImpl that tracks all upstream destinations (UStreamImpl instances)
+ * A UStreamImple instance per DStreamImpl
+ * separate channel per instance of USTreamImpl - making for DStreamImpl-number of connections seen by the remote server.  
+
+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".
+
 ----
 [#home Home.]