On Tue, May 3, 2011 at 1:27 PM, Fabrice Deyber <fabricedey...@agilemesh.com> wrote: > Hi Javier, > thanks for your response. > > Concerning my routing question, I just changed the behavior when we get a > PREP not a PREQ.
Yes, I saw that, and that would be ok if the only path that was being established was from origin (and intermediate nodes) to destination. But IIRC PREPs are also used to establish reverse paths, and that's where the multiple PREPs *might* play a role. (In my previous message I mistakenly said PREQs instead of PREPs) That said, your observations suggest there are routing loops in the propagation of PREPs and that is bad. Hopefully some 11s routing experts can chime in and see if there is a better fix for the observed behavior that does not conflict with the current 11s draft specification. Who knows, maybe the spec is wrong given that it is based on AODV and both clearly differ on that point. Thanks for reporting this! Javier > I understand that we can get multiple PREQ and we should process them even > with the same sequence number. But for PREP I was getting multiple PREP with > the same sequence number. They were just stuck between two nodes until the > TTL expired...(TTL=31) and the metric and hops kept increasing. (loop route) > So if action is MPATH_PREP and the sequence number is the same it means that > we already forwarded the PREP. (this only happens when a node get a PREP not > a PREQ) > > In section 6.7 of the AODV spec (http://www.ietf.org/rfc/rfc3561.txt) > " > > When a node receives a RREP message, it searches (using longest- > prefix matching) for a route to the previous hop. If needed, a route > is created for the previous hop, but without a valid sequence number > (see section 6.2). Next, the node then increments the hop count > value in the RREP by one, to account for the new hop through the > intermediate node. Call this incremented value the "New Hop Count". > Then the forward route for this destination is created if it does not > already exist. Otherwise, the node compares the Destination Sequence > Number in the message with its own stored destination sequence number > for the Destination IP Address in the RREP message. Upon comparison, > the existing entry is updated only in the following circumstances: > > (i) the sequence number in the routing table is marked as > invalid in route table entry. > > (ii) the Destination Sequence Number in the RREP is greater than > the node's copy of the destination sequence number and the > known value is valid, or > > (iii) the sequence numbers are the same, but the route is is > marked as inactive, or > > (iv) the sequence numbers are the same, and the New Hop Count is > smaller than the hop count in route table entry. > > " > As you can see the RREP is not blindly forwarded if the sequence number are > the same. They are forwared only under certain conditions. > Shouldn't be the same in HWMP? > > Fabrice Deyber > > AgileMesh, Inc > 1761 International Parkway > Suite 113 > Richardson, TX, 75081 > Phone: 214-843-0036 > Fax: 972-231-2406 > www.agilemesh.com > On 5/3/2011 2:35 PM, Javier Cardona wrote: > > Hi Fabrice, > > On Tue, May 3, 2011 at 11:40 AM, Fabrice Deyber > <fabricedey...@agilemesh.com> wrote: > > Hi Javier, > do you know why I can't post on: gmane.linux.drivers.mesh.open80211s? > I keep getting that the list is unidirectionnal. > > gmane just archives this list. To post just e-mail to > devel@lists.open80211s.org > > Anyways maybe I can ask you a question directly. I'm working on multiple > mesh nodes and > I noticed some route loops when all the nodes are transmitting. > HWMP is based on AODV and AODV prevent forwarding multiple RREP by using > the sequence number. > I think we should do the same thing in HWMP, the current implementation will > forward any PREP as long as the sequence number is greater or equal. I > propose to forward PREP only if the sequence number is greater. > > (mpath->flags & MESH_PATH_SN_VALID)) { > if (SN_GT(mpath->sn, orig_sn) || > (mpath->sn == orig_sn && > - action == MPATH_PREQ && > - new_metric >= mpath->metric)) { > + action == MPATH_PREQ && > + new_metric >= mpath->metric) || > + (action == MPATH_PREP && mpath->sn == orig_sn)) { > process = false; > fresh_info = false; > } > > Let me know what do you think, I just started to look in AODV and HWMP and I > may be missing something. > > Section 11c.9.10.3 of the 11s draft (v10.1) is clear about this: > > A PREP is transmitted if the mesh STA has received a PREQ fulfilling > all of the following conditions: > (...) > b) An HWMP sequence number that is greater than or equal to > the Target HWMP sequence > number of the PREQ > > I would say that with your change you would disable the ability of the > mesh to find the best metric route. Keep in mind that it is acceptable > that the originator receives the same PREQs via different paths: the > path with the best metric will be selected. Did your change resolve > the routing loops you observed? > > Thanks! > > Javier > > > _______________________________________________ > Devel mailing list > Devel@lists.open80211s.org > http://open80211s.com/mailman/listinfo/devel > > -- Javier Cardona cozybit Inc. http://www.cozybit.com _______________________________________________ Devel mailing list Devel@lists.open80211s.org http://open80211s.com/mailman/listinfo/devel
