Changes between Version 26 and Version 27 of Internal/OpenFlow/Controllers/MultiCtl

Timestamp:

Oct 13, 2012, 2:28:21 AM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/MultiCtl

@@ -234 +234 @@
 Some time was spent getting a better sense of the software architecture. The most recent organization looks like below:
 [[Image(module_arch.png)]]
-This image attempts to summarize the required communication channels and message processing chain. 
+
+This image attempts to summarize the required communication channels and message processing chain:
+ * Channels - !OpenFlow (between switches and a controller), client/server connections between controllers on the control plane
+ * Message processing -  local data processing, escalation/forwarding, and return path
+
+In a sense, the main controller class is an implementation of a rudimentary kernel. 
 
  * Some more discussion on use case was had, in the context of different management domains with multiple controllers owned by separate groups, but on the same network. In the traditional network setup, each group would have to actively collaborate in order to prevent controllers from trampling each others' policies. For example, a central controller orchestrator, when allowing a user to administrate the network, would only permit the user to configure their own controller. The orchestrator would have to "know" which users can access which controller, and how that controller may influence the network.