Changes between Version 60 and Version 61 of Internal/OpenFlow/Controllers/MultiCtl

Timestamp:

May 1, 2013, 8:26:39 PM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/MultiCtl

@@ -11 +11 @@
 [#iii Subpages] - extra notes related to this page [[BR]]
 [#iv Logs] - records of work 
- || [#w1 week1] || [#w7 week7]   || [#w13 week13] || [#w24 week24] ||
- || [#w2 week2] || [#w8 week8]   || [#w15 week15] || [#w25 week25] ||
- || [#w3 week3] || [#w9 week9]   || [#w17 week17] || [#w28 week28] ||
- || [#w4 week4] || [#w10 week10] || [#w19 week19] || [#w29 week29] ||
- || [#w5 week5] || [#w11 week11] || [#w20 week20] || [#w30 week30] ||
- || [#w6 week6] || [#w12 week12] || [#w23 week23] || [#w31 week31] ||
+ || [#w1 week1] || [#w7 week7]   || [#w13 week13] || [#w24 week24] || [#w32 week32] ||
+ || [#w2 week2] || [#w8 week8]   || [#w15 week15] || [#w25 week25] || [#w33 week33] ||
+ || [#w3 week3] || [#w9 week9]   || [#w17 week17] || [#w28 week28] ||||
+ || [#w4 week4] || [#w10 week10] || [#w19 week19] || [#w29 week29] ||||
+ || [#w5 week5] || [#w11 week11] || [#w20 week20] || [#w30 week30] ||||
+ || [#w6 week6] || [#w12 week12] || [#w23 week23] || [#w31 week31] ||||
 [[BR]]
  
@@ -655 +655 @@
 Switch performance testing is difficult. There is OVS, which may be possible to hack up a bit so we can pull times from it, but for anything else, this is not really feasible. 
 
+==== w/o 4/28-5/4 ==== #w32
+Tiered routing/resolution.
+
+We can take advantage of the tiered structure of the control plane to tweak how a given controller "sees" the network. The view of higher tier nodes may be simplified into domains, or clusters of switches connected to an adjacent client node. Resolution based on this mapping can rely on higher tiers to give a general location of a host, then rely on lower tiers to pinpoint exact attachment points. 
+
+This implies client-server coordination specifically tuned to this service, and not just the generic schedule/dispatch mechanism. A
+list of first-guess functions needed are:
+
+Client node (modified !ForwardingBase)
+ 1. mapping of hosts and domains to attachment point - former is external ports, latter, internal
+ 1. ability to pull routes using both results of queries to server tier and regular attachment points
+ 1. flow installation along switches.
+
+Server node
+ 1. maintain domain-host mappings
+ 1. return attachment point map of destination nodes.
+
+A client may have the following flow of operation:
+{{{
+if packetIn from a new host
+  escalate
+
+processResponse:
+  if dest local
+    find route to attachment point
+  if dest remote
+    find attachment of domain
+    find route to domain atachment point
+  else
+    bcast
+}}}
+
+The server just derives the destination's attachment point in terms of domain, and replies with a !PacketOut. Domains, to keep it simple, will have an identifier that can be aliased to an attachment point as describable in a !PacketOut.
+
+
 ----
 [#home Home.]