Changes between Version 57 and Version 58 of Internal/OpenFlow/Controllers/MultiCtl

Timestamp:

Apr 1, 2013, 5:55:02 AM (11 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/MultiCtl

@@ -11 +11 @@
  || [#w1 week1] || [#w7 week7]   || [#w13 week13] || [#w24 week24] ||
  || [#w2 week2] || [#w8 week8]   || [#w15 week15] || [#w25 week25] ||
- || [#w3 week3] || [#w9 week9]   || [#w17 week17] || [#w25 week26] ||
+ || [#w3 week3] || [#w9 week9]   || [#w17 week17] || [#w28 week28] ||
  || [#w4 week4] || [#w10 week10] || [#w19 week19] || ||
  || [#w5 week5] || [#w11 week11] || [#w20 week20] || ||
@@ -612 +612 @@
 with deny and split being combined into a divert action. This choice for precedence and priority handling is acceptable as long as we stand by the assumption that no two servers provide overlapping rules. For example, no service will absolutely rely upon a event being ALLOWed when another service relies on DIVERTing it, in which case, conflicts in handling will result in control plane malfunction. 
 
-==== w/o 3/16-3/22 ==== #w26
-
-
+==== w/o 3/31-4/1 ==== #w28
+Topic: Some thoughts about the role of core controller components, versus modules. 
+
+A controller in context of the current states of things, divides the control plane (or what was considered the control plane early on) into an application layer, and the system underlying it. The latter has become what is referred to as the control plane in the recent models of network operating systems. From a functional perspective, it appears as if the applications preform the computations specific to the behaviors imposed on the data plane, leaving the control plane to provide underlying functions such as network view abstraction and event scheduling and dispatch. (TODO: to look up the formal delegations for these layers)   
+
+Using this idea as a basis, we can roughly guess at what functions belong where, and importantly, the breadth of functions to provide certain controller sub-components. What this leads to is that the core of a controller - the implementation of the control plane - probably does not generate control messages intended to modify the flow tables of the datapaths. This is a role left to the application layer, which among other things implements the network algorithms that manipulate the handling of traffic. 
+
+The exercise here ties back into implementation. The current controller core does not respond to !PacketIns directly, but merely dispatches them to available modules (applications). The added message diversion function may be implemented in two ways, at first glance:
+
+ 1. By halting the processing of the message by further modules 
+ 1. Writing a drop message back (buffer set to -1)to the switch prompting instruction, then halting the processing
+
+The former does not prevent a datapath from sending further !PacketIns to the same event, while the latter does. While the latter is cleaner in handling, and prevents unnecessary handling of multiple copies of !PacketIns, it blurs the boundaries between application and control. A similar story holds for the return handling of a message processed by a remote server. Further processing of a response can be done at the client, but the extent of actions that the control plane can take are limited by the logical separation into two layers. 
+
+Maybe keeping this in mind will make fleshing out and tuning the implementation into less of a pain...    
 ----
 [#home Home.]