Flowvisor should ensure that flowmods have reasonable timeouts

[billsnow]

Status: Open Project: Flowvisor Component/s: None Affects Version/s: None Fix Version/s: None

Type: New Feature Priority: Major Reporter: Niky Riga Assignee: Ali Al-Shabibi Resolution: Unresolved Votes: 0 Labels: needsdesign, willfix Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified

Description
Many controllers might use timeout values that are not reasonable for some slices, i.e. infinite values causing flows to stay at the flow table even when a controller is not running or when a slice is removed. FV should probably check the values, and take reasonable actions.

Comments
Comment by Rob Sherwood [ 24/Oct/11 ] Hi Niki, I know I've taken a back seat to FV stuff, but I claim that you've found a valid problem but I would suggest a different solution. When a slice disconnects, the FV should implement the OpenFlow spec's behavior for a disconnected controller, e.g. fail closed or fail open. When a slice is removed, it should remove all of the flows then. Relying on timeouts is inefficient for both the flowvisor and for the switch: if a high bandwidth flow times out in the middle, it will cause havoc in the control channel and flowvisor. Fwiw. Rob . Comment by Nick Bastin [ 24/Oct/11 ] The slice deletion case is, in theory, uninteresting - I don't think we disagree on what the behaviour ought to be there. However, I do still think that we need to "virtualize" (or at least restrict) the timeout values of slices - admins should be able to control this part of the upstream flowmod (imo, anyhow). We probably ought to more explicitly specify the failure behaviour of your slice as well (not necessarily restricting ourselves to the openflow standard modes of "standalone" and "secure", but possibly also more useful things) so that we can do something reasonable when your controller is down (this is probably a separate issue). Comment by Nick Bastin [ 24/Oct/11 ] Also, I think this fits somewhere along the lines of the type of control we're looking for in FLOWVISOR-88. (A new class of per-slice restrictions that are more like existing hypervisors for compute resources - flowtable limits would be one, timeout restrictions another, etc.) Comment by Niky Riga [ 24/Oct/11 ] I see. I agree on the deleted slice case. What I had in mind were mostly cases where the controller was stopped in an effort to kill related traffic from flowing, and it took us a while to realize what was happening. I haven't thought about this hard, so it might be the case that killing your controller should not affect existing traffic, although if you kill your controller in theory you don't expect your traffic to flow. I understand of course that there are cases when the connection to the controller is temporarily lost and you don't want this to cause a whole churn of control messages, but if the disconnection is longer it seems reasonable that the traffic for the slice shouldn't flow either. There are also cases (thinking about broadcast storms here) that killing the actual traffic won't stop the storm and it would be nice if by killing the controller you could make this stop. Comment by Ali Al-Shabibi [ 06/Feb/12 ] There are some notes about resource limits at https://openflow.stanford.edu/display/DOCS/Resource+and+Slice+limits. Please feel free to comment.

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