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
