Hello Ali,
Thank you again and I'm sorry for bothering so much. After all this
time theres one thing that I couldn't really figure out:
Suppose I have only one FlowSpace rule giving WRITE permissions to
ALICE, and the match of this FlowSpace rule is dl_vlan=1. ALICE then
tries a FLOW_MOD (with an all-wildcarded match) with
Action:SetVlanID(22)
Given this piece of code from FVActionVirtualLanId and what I think it does:
1) FVMatch neoMatch = new FVMatch(match);
2) neoMatch.setDataLayerVirtualLan(this.virtualLanIdentifier);
3) List<FlowEntry> flowEntries =
fvClassifier.getSwitchFlowMap().matches(fvClassifier.getDPID(),
neoMatch);
1) Create a new match from the match of the FLOW_MOD (which was all
wildcarded). This means the 'neoMatch' will be exactly the same as
'match', right? (in this case, all wildcarded)
2) The 'neoMatch' created earlier will have its dl_vlan changed from
whatever it was (wildcard) to the dl_vlan specified by the Action of
the FlowMod (22), right?
3) The whole FlowSpace is compared to <dpid , neoMatch> and
overlapping entries are returned. My worst problem is here: if what I
said in 2) is correct, is it correct for it to say that neoMatch(with
dl_vlan=22) and the only FlowSpace rule (with dl_vlan=1) overlap? Can
it be a Subset or a Superset if the same field has different values in
them?
Thank you very very very much again!
Victor T.
On 11 September 2013 20:43, Ali Al-Shabibi <ali.al-shab...@stanford.edu> wrote:
>>
>> 1) When I send a FLOW_MOD with an Action to change de DL_VLAN, we talk
>> about SwitchFlowMap, which seems to come from the FlowSpaceUtil. Does
>> this mean that this SwitchFlowMap and the FlowEntries it talks about
>> are from the configured FlowSpace rules?
>>
>
> Yes those are the ones.
>
>> 2) If the above is correct, about the entity FlowEntry, what does it
>> mean by "ActionList"? I'm confused because we only provide permissions
>> in the FlowSpace, not actions? Would this be a "hook" for adding a
>> future feature?
>
> The action list in FlowEntry is a little confusing sorry. That action list is
> actually used to store the persmissions a slice has on this flowspace entry.
> So for example, alice has write permissions and bob only has read permissions.
>
> Cheers.
>
>>
>>
>> Thanks again, I think I'm really getting somewhere! =)
>>
>> Victor T.
>>
>> On 11 September 2013 00:31, Ali Al-Shabibi <ali.al-shab...@stanford.edu>
>> wrote:
>>> 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
