Hi Charlie,
iirc, we’ve already determined that this loop is fixed by changes we’ve already
made….
Am 29.03.2016 um 01:34 schrieb Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx>:
Hello folks,
Here is some discussion about the second purported loop. It does not use
RREP, and so it is simpler to understand.
First, I reckon there is some confusion and the diagrams 1(a) and 1(b) are
switched. So reverse the labeling and follow the steps.
In step 7, node n1 should never use the previous unconfirmed route because
that previous route has an older sequence number. Moreover, the previous
route has a larger metric, which would make it ineligible for use compared to
the more recent route.
Finally, given all the serious recriminations against ever ever ever using
unconfirmed routes to do routing, I remain at a loss to understand why
unconfirmed routes could be considered part of a routing loop. It is an
immediate absurdity to claim that a route that cannot be used, would be a
route that has a routing loop. It would be like giving a speeding ticket to
something that can't move (e.g., a mountain). Or like assigning a routing
violation to something that can't route.
Note, however, that I continue to think that unconfirmed routes SHOULD be
allowed to carry control information that is aimed at CONFIRMING the
unconfirmed route.
Regards,
Charlie P.
On 3/16/2016 10:12 AM, Lotte Steenbrink wrote:
Following up, they’ve found another loop in -13:
<Mail-Anhang.jpeg>
At first nodes are connected to each other as shown in Fig1.a.
n0 initiates a route discovery procedure for destination n3 by multicasting
a “rreq” message to n2 with sq=2.
n2 after updating its routing table, multicast the “rreq” to its neighbors,
n1 and n3.
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
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.
n0, which hasn’t received an “rrep” yet, resend the “rreq” message after
increasing its sequence number to 3.
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.
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.
Since we’ve moved to disallowing multiple Unconfirmed routes (in -14, which
isn’t published yet), this one is resolved already as well.
The reason we didn’t discuss this earlier on [manet] was that the authors
hadn’t submitted their paper yet (and I didn’t want to leak their work).
They’ve done so now, and will send us a link to their paper once it’s
available. I’m guessing it’ll take a while to be published properly, but it
should be enough for for our purposes for the paper to appear on arxiv.org
<http://arxiv.org/> for now…
Best regards,
Lotte
