Hi Javier,
thanks for your response.

Concerning my routing question, I just changed the behavior when we get a PREP not a PREQ. 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 <http://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

Reply via email to