Changes between Version 51 and Version 52 of Internal/OpenFlow/Controllers/MultiCtl

Timestamp:

Feb 10, 2013, 8:18:33 AM (11 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/MultiCtl

@@ -25 +25 @@
  [#w17 week 17][[BR]]
  [#w19 week 19][[BR]]
+ [#w20 week 20][[BR]]
 == Overview. == #i
 The basic architecture for an !OpenFlow network is a client - server (switch - controller) model involving a single controller and one or more switches. Networks can host multiple controllers. !FlowVisor virtualizes a single network into slices so that it can be shared amongst various controllers, and the newest !OpenFlow standard (v1.3.0) defines ''equal'', ''master'' and ''slave'' controllers to coexist as part of a redundancy scheme in what would be a single slice. A multi-controller scheme that isn't really explored yet is one where each controller has a different function, and cooperate. 
@@ -477 +478 @@
     * transmission of all collected feature replies from the lower tiers (no two low-tier controllers connect to the same switch)
     * escalation of topology data (!PacketIn and !PortStats, required by topology and link discovery modules)
- 1. Need to work out the details of what is needed/not needed for a control plane to be deemed functional. Do we need all of the controllers properly running? Currently this is the case. However, if each controller is a separate functional component, technically not all components are equally critical to the core functions of a NOS.  
+ 1. Need to work out the details of what is needed/not needed for a control plane to be deemed functional. Do we need all of the controllers properly running? Currently this is the case. However, if each controller is a separate functional component, technically not all components are equally critical to the core functions of a NOS. 
+
+==== w/o 2/3-2/9 ==== #w20
+It is not week 21 until I go to sleep and wake up the same day (2/10). 
+
+Not much change in architecture, but refactoring nevertheless. The system can be split into a few, relatively disjoint components:
+ 1. Logical connectivity: The channels and control plane topology abstraction. This includes loop prevention in the control plane, context maintenance, and general in-controller representation of its adjacencies and the control plane topology. 
+ 2. Packet process chain: How packets a controller receives is handled and tracked across processing, escalation, and return. This involves using info generated and tracked by 1. in order to encapsulate/decapsulate control plane messages.  
+ 3. Filters and actions: How the controller responds to control messages, and decides where packets it received goes. This is part of the dispatcher, which I kind of see as a event-driven scheduler. 
+ 4. Application modules: The applications that leverage the first three to function. They live in the local process chain of 2.  
 ----
 [#home Home.]