Changes between Version 10 and Version 11 of Internal/OpenFlow/Controllers/MultiCtl

Timestamp:

Sep 12, 2012, 7:37:24 PM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/MultiCtl

@@ -9 +9 @@
 [#iii Subpages] - extra notes related to this page [[BR]]
 [#iv Logs] - records of work 
+ [#w1 week1][[BR]]
+ [#w2 week2][[BR]]
+ [#w3 week3][[BR]]
+ [#w4 week4][[BR]]
+ [#w5 week5][[BR]]
 
 == Overview. == #i
@@ -40 +45 @@
  * [wiki:Internal/OpenFlow/Controllers/MultiCtl/FLInternals Floodlight Internals]: A summary of Floodlight internals. 
 == Logging. == #iv
-==== (9/5): ====
+==== (9/5): ==== #w1
 keywords: hierarchy, collaboration.
 
@@ -85 +90 @@
 The service reply will probably communicate a service type (topology, network storage, etc.) and a location to find it, such as port on a datapath where a NAS is located (if network storage). This is basically a way for the network to advertise location of services to topology-aware elements, as opposed to a server attached to a network doing the adverts for hosts. 
 
-==== (9/11) ====
+==== (9/11) ==== #w2
 Some work was done to develop a general architecture of a single controller, tentatively named a "Unit".
 
 [[BR]] 
 [#iv Back to Logs.]
-==== (9/12) ====
+==== (9/12) ==== 
 Several points were discussed.
 
@@ -102 +107 @@
 
  5. '''''Use case.''''' A small setup of three switches, two hosts (one moving), and two tiers of controllers. The first tier may be a simple forwarding unit, and the second dictates a higher (protocol) layer logic - to keep it simple, authentication. The logical layout between the two tiers changes behaviors of the tiers:
-
   1. Tier two connects to just one tier one controller: the connection point must communicate the higher-tier's commands to others in its tier. 
   2. Tier two connects to all tier one controllers: tier two in this case is a global 'overseer' that can actively coordinate, in this case, a handoff where permitted.