use flow-tracking to infer dst for flow_removed message

[billsnow]

Status: Open Project: Flowvisor Component/s: Core Affects Version/s: 0.7.2 Fix Version/s: Long Term

Type: Improvement Priority: Major Reporter: Nick Bastin Assignee: Rob Sherwood Resolution: Unresolved Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified

Description
Right now, we send flow_removed messages to any controller who could have sent them. Instead, we should consult the flowDB to figure who did insert the flow, and send the remove msg back to them. Also, we should do better faking: i.e., if a flow was expanded three times, we should only send the flow_removed once all three inserted flows are removed.

Comments
Comment by Rob Sherwood [ 04/Jul/11 ] this feature depends on the flowDB feature, and is actually not mostly implemented. General issue: If a controller sends a flow_mod X and the FV rewrites it as X1, X2... Xn, then currently, when those flows expire, the flow_removed message, Xi get sent back to any controller that has flowspace for Xi rather than the controller that sent them. The flowDB feature ensure that only the sending controller gets the flow_removed message for Xi, but that's only most of the way there; the controller thinks it sent X, not Xi. So, what should be done is: the flowvisor surppresses and tracks the flow_remove for Xi for all X1.. Xn, and then, once they have all been removed, THEN send up a flow_removed for X, with the duration, byte, and packet counters updated to be the union of the Xi's. The trick is, in the mean time, if a packet_in comes up that matches any of X1...Xn that has expired, then we need to put it back in the flow table.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-19