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
