Changes between Version 15 and Version 16 of Internal/OpenFlow/FloodlightFVModule

Timestamp:

Jun 25, 2012, 10:31:46 PM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/FloodlightFVModule

@@ -8 +8 @@
 [#s Setup] [[BR]]
 [#bg Background] [[BR]]
-[#a Approach] -  a diary-style log of the implementation. 
+[#a Approach] -  a diary-style log of the implementation. Following are some 'highlights' relevant to the software being ported in general:
  * [#fl-1 Floodlight Module System]
  * [#fv-1 Flowvisor FlowMap Overview]
- * [#fv-2 Flowvisor DB interface(?)]
+ * [#fv-2 Flowvisor Internals, Continued]
 [#end jump to bottom.] 
 == Overview. == #o
@@ -197 +197 @@
 The !Matchtype is used to describe ''Intersections'', descriptions of how two !FlowEntries relate. An intersection takes the form of a !FlowEntry built by choosing the more heavily constrained pattern for each header field and DPID(s). !FlowIntersect.java implements the representation of the intersection, and !FlowEntry defines matches(), which compares two !FlowEntries to produce the intersection. Comparisons are implemented in !FlowTestOp.java.  
 
-==== (6/22):[Flowvisor DB interface(?)] ==== #fv-2
+==== (6/22): ====
+Some thoughts from reading Flowvisor code.  
  * FVConfig interfaces database access operations pertaining to Flowspaces, slices, switches, and Flowvisor itself. The DB-related classes are all named *Impl. 
+ * The handling of messages received by Flowvisor are defined within the messages themselves, as part of the implementation of Classifiable and Sliceable interfaces.
  * The static flow pusher and related components may be eventually useful for these configuration aspects. 
 
+==== (6/25):[Flowvisor Internals, cont'd] ==== #fv-2
+Today's conference call elucidated quite a bit about the workings of the !FlowMap and how it fits in with the rest of the system.
+
+''Item 1: the usage of config databases.'' [[BR]]
+In Flowvisor, the !FlowMap is coupled to the database, but only loosely - the specific implementations are, indeed, hidden behind FVConfig. Furthermore, the database is only accessed when:
+
+ * an FVClassifier initializes connections to controllers (see FVClassifier.java:751)
+ * the flowspace changes.
+
+in short, the database is a convenience item for storing configurations, and for initial purposes of this project, something that can likely be dealt with later.     
+
+''Item 2: !FlowMap internals.'' [[BR]]
+The two implementations of interface !FlowMap process the flowspace very differently. 
+
+The Linear !FlowMap takes a literal copy of the flowspace; to save space, the flowspace is carted up by DPID, and the piece representing the 'correct' DPID e.g. matching that of the incoming message, is processed.  
+
+The Federated !FlowMap manipulates references. If multiple !FlowMaps existed, they would all point to the same flowspace. This !FlowMap relies on a global bitset, indexed by !FlowEntry ID, to keep track of entries that are part of a intersection (1=member, 0=otherwise). Starting with DPID, each field of a OFMatch is taken and compared to those of the flow entries. Each field is stored in its own hashmap, keyed by value. Each field comparison should narrow the number of 1's in the global bitset. At the end, the entry with the highest priority is chosen.    
+
+The goal of the Federated !FlowMap is speed - many of its operations are kept to bitwise ops, and storage, hashmaps. Slower operations that involve loops e.g. IP address matching, are kept until later when the set of entries to work with is smaller. 
+
 == . ==#end