Hi Victor, So what you are saying is correct. When a FlowMod arrives from a controller we know which slice/controller it's from. Therefore, the flowmod's match struct is matched against the flowspace of that slice. Then, for every flowspace rules matching the flowmod's match the original flowmod is expanded; ie. a new flowmod, which is the a composition of the original flowmod and the flowspace rule, is pushed to the switch.
I don't if you found this page but it could help you understand how flowmods are handled -> https://github.com/OPENNETWORKINGLAB/flowvisor/wiki/FlowMod-Message Cheers. -- Ali On Sep 10, 2013, at 7:46 PM, Victor Torres <vit...@poli.ufrj.br> wrote: > Hello again Ali, > > Thank you for all you support so far. I think theres no way for me but > to go into FlowVisor's code. So, at first, I have a question and > appreciate any direction on how to go on with this: > > At first, I'm really interested in how FLOW_MOD messages are handled. > According to the FV Wiki > (https://github.com/OPENNETWORKINGLAB/flowvisor/wiki/IO-Overview), is > it correct to say that a FLOW_MOD message from a controller/slice will > pass through a SLICER that will match it against the flowspace, > rewrite it and push it to the switch? > > > Thanks again, > > Victor T. > > On 3 September 2013 13:45, Ali Al-Shabibi <ali.al-shab...@stanford.edu> wrote: >>> 1) So FV does update its FlowTable Cache from OF Messages going Switch <-> >>> Controller. But when you say "at most every 30s, means that if it doesn't >>> get any update it asks the switch for its FlowTable? The FlowMod thing >>> means that the FlowVisor asks periodically for the switch for modified >>> flows? >>> >> >> So if no controller or user requests flowtable stats, FV does not store >> anything in its cache nor does it make any periodic requests. But if your >> controller asks for the flowtable then if it does not have a copy of the >> flowtable or if the cache is old, it will fetch the flowtable from the >> switch. Otherwise it will return the cached values. The reasoning behind >> this is: >> >> 1. There may be many controllers sitting on top of FV, therefore there may >> be many more flow table requests. >> 2. On some switch implementations, asking for the flowtable is an expensive >> operation (ie. forwarding may be delayed) >> >> For those two reasons, flowvisor caches the flowtable. Of course, you can >> change the refresh rate if you know your switches do not suffer from those >> issues. >> >> >>> 2) If a slice controller wants to install a flow that changes the VLAN tag >>> from A to B for a given flow, FV only approves it if the slice has >>> Read/Write permissions on flowspace with dl_vlan=A and dl_vlan=B? >> >> That's is correct. >> >>> If dl_vlan is wildcarded then everything is allowed, right? >> >> Yup that's right as well. >> >>> Finally, if its set to NONE it cannot install or mod flows that have (to >>> have) actions that change Vlan Tags? >>> >> >> And correct again ;) >> >> >>> >>> Sorry for asking so much but since these particular questions are very >>> important for our research I would lilke to understand it as accurately as >>> possible. >>> >> >> No worries, ask as many question as you can. >> >> >>> Thank you very much! >>> >>> Victor T. >>> >>> >>> >>> On 3 September 2013 13:04, Ali Al-Shabibi <ali.al-shab...@stanford.edu> >>> wrote: >>> Hi Victor, >>> >>>> 1) Does FlowVisor updates its FlowDB as OF Messages pass through it? Or >>>> does it asks directly the switches for their Flow Tables? Reading the >>>> source code I'm inclined to think of the first option. >>> >>> You are mostly right. Flowvisor stores a cache of the flowtable which it >>> refreshes at most every 30s (this is configurable in versions 1+ of FV). >>> One important note is that flowmods are not stored when they are pushed >>> down by a controller, but rather they are periodically read from the >>> datapath. >>> >>>> >>>> 2) I would like to be able to keep a certain controller from installing or >>>> modding Flows that change the VLAN Tag of a packet, for instance. Can you >>>> point out a direction to do this? I was investigating the source code, >>>> but I'm not sure if I should try to implement a new Callback type or >>>> something like that. >>> >>> FV will disallow a controller from pushing or modding a vlan tag if either >>> that vlan tag is not in the flowspace associated to that controller or if >>> dl_vlan is set to none. >>> >>>> >>>> If I get to any results I would gladly pull it in the future. >>>> >>> >>> That would be fantastic. Let me know if you need more help. >>> >>>> >>>> Big thanks! >>>> >>>> Victor T. >>>> >>>> >>>> On 30 August 2013 18:46, Ali Al-Shabibi <ali.al-shab...@stanford.edu> >>>> wrote: >>>> Hi Victor, >>>> >>>> Currently, you cannot specify which openflow actions are allowed on a per >>>> flowspace basis. This is clearly a desirable feature but unfortunately we >>>> have not addressed it yet. We would welcome any pull >>>> requests/contributions in this direction. >>>> >>>> Cheers. >>>> >>>> -- >>>> Ali >>>> >>>> On Aug 30, 2013, at 11:58 AM, Victor Torres <vit...@poli.ufrj.br> wrote: >>>> >>>>> Hello, >>>>> >>>>> Does anybody know if it is possible to define allowed/denied actions for >>>>> slices in FlowVisor? >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Victor T. >>>>> _______________________________________________ >>>>> openflow-discuss mailing list >>>>> openflow-discuss@lists.stanford.edu >>>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>> >>>> >>> >> _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
