Oops.. typos. > One can interpret "finish processing" as having dropped. I am *not* > suggesting we do, but this is apparently not an impossibility. It is a > rare event nonetheless.
On 19 December 2010 23:41, kk yap <yap...@stanford.edu> wrote: > Hi Syed, > > One can interpret "finish processing" as having dropped. I am > suggesting we do, but this is apparently not a impossibility. It is a > rare event nonetheless. > > Regards > KK > > On 19 December 2010 23:37, Syed Akbar Mehdi > <akbar.me...@seecs.nust.edu.pk> wrote: >> Hi KK, >> >> Thanks for detailed explanation. However this conflicts somewhat with the >> OpenFlow Spec v1.0. In section 5.3.7 (page 36) of the OpenFlow1.0 spec it is >> written that: >> >> "Upon receipt, the switch must finish processing all previously received >> messages before executing any messages beyond the Barrier Request". >> >> -- >> Regards, >> Syed Akbar Mehdi, >> School of EECS (SEECS), >> National University of Sciences and Technology (NUST), >> Pakistan. >> >> On Mon, Dec 20, 2010 at 12:18 PM, kk yap <yap...@stanford.edu> wrote: >>> >>> Hi Syed, >>> >>> The barrier function is only there to tell you that a preceding >>> message is processed (i.e., the command is carried out, dropped or >>> error code is returned). So, you can imagine if you want to check the >>> flow mod is inserted or not, you can do the following: >>> 1) send flow mod >>> 2) send barrier request >>> 3) send flow stat after receiving barrier reply >>> This ensures that the flow mod is processed by the switch already. >>> Switch can choose to process messages out of order of what is >>> received, except for the barrier message. >>> >>> Hope this is clearer. >>> >>> Regards >>> KK >>> >>> On 19 December 2010 22:53, Syed Akbar Mehdi >>> <akbar.me...@seecs.nust.edu.pk> wrote: >>> > Hi KK, >>> > >>> > You say that: >>> > >>> > "Meaning, it is perfectly okay for a switch to >>> > send a reply to the barrier and ignore the flow mod before that." >>> > >>> > How is the barrier reply useful then, if it does not guarantee this? >>> > >>> > -- >>> > Regards, >>> > Syed Akbar Mehdi, >>> > School of EECS (SEECS), >>> > National University of Sciences and Technology (NUST), >>> > Pakistan. >>> > >>> > On Mon, Dec 20, 2010 at 10:38 AM, kk yap <yap...@stanford.edu> 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
