Changes between Version 54 and Version 55 of Internal/OpenFlow/Controllers/MultiCtl

Timestamp:

Mar 4, 2013, 4:51:45 PM (13 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] || [#w7 week7]   || [#w13 week13]  || ||
- || [#w2 week2] || [#w8 week8]   || [#w15 week 15] || ||
- || [#w3 week3] || [#w9 week9]   || [#w17 week 17] || ||
- || [#w4 week4] || [#w10 week10] || [#w19 week 19] || ||
- || [#w5 week5] || [#w11 week11] || [#w20 week 20] || ||
- || [#w6 week6] || [#w12 week12] || [#w23 week 23] || ||
+ || [#w1 week1] || [#w7 week7]   || [#w13 week13] || [#w24 week24] ||
+ || [#w2 week2] || [#w8 week8]   || [#w15 week15] || ||
+ || [#w3 week3] || [#w9 week9]   || [#w17 week17] || ||
+ || [#w4 week4] || [#w10 week10] || [#w19 week19] || ||
+ || [#w5 week5] || [#w11 week11] || [#w20 week20] || ||
+ || [#w6 week6] || [#w12 week12] || [#w23 week23] || ||
 [[BR]]
  
@@ -532 +532 @@
 Dispatcher behavior algorithm.  
 [[Image(dispatch-algo.png)]]
+
+==== w/o 3/4-3/9 ==== #w24
+'''3/4''' [[BR]]
+Filter subsystem. 
+
+The syntax - This is heavily based on [http://biot.com/capstats/bpf.html BPF], as in there are a handful of base elements - packet fields, and operations ''and'' and ''or''. In terms of operation, it is something else. The properties are:
+
+ * Each component is a 4-tuple: event type, directionality, attribute, and value. We can AND or OR these together to form the rules. 
+
+   || Event Types || Network events that can be detected via the control channel, ANY ||
+   || Directionality || SRC, DST, or ANY ||
+   || Attribute || DPID, VLAN, IP, MAC, ANY ||
+   || Value || for Attributes, in order - long, short, int, long, none ||
+   
+   ANY is a wildcard, with the most lenient rule being "ANY event, ANY attribute, ANY value"
+
+ * Some components can be condensed into one (a rule) - these are usually multiple rules ANDed together, e.g. "src IP A AND dst IP B". 
+ * "rules" are a condensation of one or more components. 
+ * Each rule is tied to a service ID, and as a result, a next-hop UID.   
+
+The matching occurs in the dispatcher, and returns a set of service IDs and next-hop UIDs. 
+
 ----
 [#home Home.]