[aodvv2-discuss] Re: Fwd: loop scenario

From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
Date: Wed, 9 Mar 2016 08:47:59 +0000

Hi all...

Interesting...I think this one is fixed by only storing one unconfirmed
route. The seqno in steps 7 and 8 is higher, so this should replace any
existing unconfirmed entry. So n1 and n2 will have route to n0 learned from
the second RREP, with seqno 3. Version 14 includes this in 6.7.2....

2.  If two matching LocalRoutes exist in the Local Route Set, one is
       a valid route, and one is an Unconfirmed route.  AdvRte may offer
       further improvement to the Unconfirmed route, or may offer an
       update to the valid route.

       *  If AdvRte.NextHop's Neighbor.State is Unknown, the advertised
          route may offer improvement to the existing valid route, if
          the link to the next hop can be confirmed as bidirectional.
          Continue processing from Step 5 to update the existing
          Unconfirmed LocalRoute.

<snipped the 2nd bullet point which addresses the case when AdvRte's next
hop is already confirmed as bidirectional>

Did we respond to say we were changing to store only one unconfirmed route?

In regards to their previous question:

We are wondering if this scenario is feasible in the real world. As you
see, the scenario is sound based on the following assumptions:

·n0 attempts to resend the “rreq” message when it doesn’t receive an “ack”
from n1
·The resending procedure of the “rreq” message by n0 takes long enough that
the “rreq” message passes through two nodes and be processed by them.

We would really like to get a feedback on the mentioned scenario and
whether it conforms to the reality. Your feedback will affect on our base
theory on verifying protocols.

I guess it is feasible....but we've fixed the problem it caused.

Regards,
Vicky.

On Tue, Mar 8, 2016 at 8:18 PM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:

FYI

Anfang der weitergeleiteten Nachricht:

*Von: *Behnaz yousefi <behyousefi@xxxxxxxxx>
*Betreff: **Aw: loop scenario*
*Datum: *8. März 2016 21:03:09 MEZ
*An: *Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
*Antwort an: *Behnaz yousefi <behyousefi@xxxxxxxxx>

Dear Mr. Lotte Steenbrink
Again sorry for the delay, we were busy revising our paper. You can
publish our finding in the MANET group since our paper is under revision we
will upload its revised version near a week on the arXiv.
We really appreciate it if you answer our previous question that whether
the scenario we have found can happen in reality.  As we mentioned before,
your answer will effect on our theorem since as we explained before we
found that scenario based on some assumptions. If our assumptions don’t
hold we need to change our paper and that’s why we would really like to get
a feedback from you.
In addition, we found another loop scenario which involves resending the
“rreq” messages and is given for a network of four nodes with the network
topologies shown in Fig.1.

[image: Inline image]

   1. At first nodes are connected to each other as shown in Fig1.a.
   2. n0 initiates a route discovery procedure for destination n3 by
   multicasting a “rreq” message to n2 with sq=2.
   3. n2 after updating its routing table, multicast the “rreq” to its
   neighbors, n1 and n3.
   4. n1 upon receiving the “rreq” message sent by n2 updates its routing
   table and adds a route with hop-count=2, sq=2 and next-hope=2
   5. Consider that topology changes at this point and n1 moves into
   communication range of n0, gets connected to n0, and n2 leaves n0
   communication range, gets disconnected from n0, which leads to network
   topology shown in Fig1.b.
   6. n0, which hasn’t received an “rrep” yet, resend the “rreq” message
   after increasing its sequence number to 3.
   7. n1 receives the new “rreq” message, with sq=3, next-hop=0 and
   hop-count=1, since it’s a better route it would be added to the routing
   table. Then n1 multicast the “rreq” message to its neighbors, n2 and n3.
   8. n2 evaluate the received message sent by n1 and adds a new route to
   its routing table with sq=3, next-hop=1 and hop-count=2 since the sequence
   number of the received message is greater than the stored one.

At this point a loop has been formed between nodes n1 and n2. This loop
scenario and the one we mentioned before occur because the existing route
has not been replaced by the better route, the received one. Instead the
new route is added to the table. The new route replaces the existing one
only when the route state of the existing route is “invalid” or the route
state of the new route is “confirmed”.   It is been said in the protocol
that when the route state of the existing route is “unconfirmed” and the
neighbor state of the next-hop of the new route is “unknown”, the new route
should be added to the table, if it’s a better route and loop free, not
replace the existing one.
We believe, these loop scenarios won’t happen if the routing table only
keeps the best and freshest routes. In other words, whenever a better route
is discovered the existing routes which are worse than the new route are
expunged from the routing table.

We hope are findings would be helpful. We are looking forward to receive
your feedback especially about our question as I explained earlier it means
a lot to us.

Best regards
Behnaz Yousefi

References:
- [aodvv2-discuss] Fwd: loop scenario
  - From: Lotte Steenbrink

[aodvv2-discuss] Re: Fwd: loop scenario

Other related posts: