Hi Derek, This question is better asked on openflow-spec or openflow-discuss. :)
Regards KK On 19 December 2010 22:11, Derek Cormier <derek.corm...@lab.ntt.co.jp> wrote: > Thanks KK, that clears everything up. May I ask, what is the main reason for > not including a flow mod reply in the OpenFlow protocol? Is it speed? Isn't > OpenFlow fast enough? > > -Derek > > On 12/20/2010 02:38 PM, kk yap wrote: >> >> Hi Derek, >> >> Some comments inline. Hope they help. >> >> Regards >> KK >> >> On 19 December 2010 21:10, Derek Cormier<derek.corm...@lab.ntt.co.jp> >> wrote: >>> >>> I noticed that the flow mod event fires in response to a successful NOX >>> API >>> call for adding a flow. It gives the impression that it was successfully >>> added to the switch, but, this is not always the case. For example, if I >>> send two identical ofp_flow_mod requests with the OFPFF_CHECK_OVERLAP >>> flag >>> set, then I will still get a flow mod, even though one triggers an error >>> and >>> is not added to the switch's table. >> >> A flow mod event is triggered whenever a flow_mod is sent by a >> component. As you have noticed, multiple comments can be sending flow >> mods and this is a way for a component to see all the flow mods sent. >> That's all. It does not imply NOX has sent the message, and even less >> if the switch has received it or processed it. >> >>> I'm guessing the reason for this is speed. Since OpenFlow switches do not >>> reply to flow mod requests, there are a couple ways I can think of to >>> confirm if a flow was added: >>> >>> 1. Send a barrier message after each add flow message. If a reply is >>> received and no error message was received, then it was added. >> >> Most of the time, you are right. While OpenFlow messages are carried >> over TCP and SSL connections, there is no guarantee that a switch will >> honor all the messages. Meaning, it is perfectly okay for a switch to >> send a reply to the barrier and ignore the flow mod before that. This >> is really because a switch can be overwhelmed by control messages and >> at some point it might discard messages. Your flow mod might just be >> the unlucky message dropped. >> >>> 2. Store an internal copy of the flow table in the NOX component and >>> check >>> for potential errors before adding. >> >> Yes. This is prudent but unfortunately tedious. This allows assume >> you emulate the entire switch functionality in the controller. By the >> way, you still will not have any guarantees about the switch inserting >> the flow mod, as I have explained above. >> >>> Both of these solutions have problems if other components are also adding >>> flows. Does anyone have any other ideas? >> >> In my mind, the obvious way to do this is hard and evil. You have to >> send the flow mods, cache it in the controller and periodically dump >> the flow table to check that it is there. This can be done in >> conjunction with other operations like stat gathering, but the >> operation can be very stressful to a switch. >> >>> It would be nice if the OpenFlow protocol had responses to flow mod >>> requests >>> that could be optionally turned on/off for speed. >> >> We have been through this discussion a few times in OpenFlow. And >> current result is that we still don't have it in the spec, even for >> the upcoming OpenFlow v1.1. >> >>> -Derek >>> >>> _______________________________________________ >>> nox-dev mailing list >>> nox-dev@noxrepo.org >>> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >>> >>> > > > _______________________________________________ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > _______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
