Subject: [manet] Bug with DYMO not incrementing OwnSeqNum and nodes throwing packets away

From: Christoph Sommer <[email-masked]>
Date: Mon, 14 May 2007 13:24:26 +0200

Hello list,

We have built a model of DYMO for use in OMNeT++ and came across a weird 
issue:

Intermediate hops throw away RREP packets that were requested to refresh 
timed-out routes.

In the draft revision we used to build the model, nodes are not yet 
allowed to send RREPs on behalf of a sink, but it seems like the problem 
should also present with the current revision. This is what happens in 
our simulation:

1.) node sends RREQ, receives RREP and stores current OwnSeqNum of sink

2.) route to sink times out (invalid, but not yet deleted)

3.) node sends RREQ, includes current OwnSeqNum of sink

4.) sink recognizes that the included SeqNum in RREQ equals OwnSeqNum, 
sends back RREP without incrementing OwnSeqNum

5.) (intermediate) node judges usefulness of RREP packet, recognizes 
SeqNum stayed the same, hop count did not get better and throws RREP away.

6.) node retries RREQ and steps 3--5 repeat

Where did our implementation go wrong? Maybe a (destination or 
intermediate) node should not take expired-but-not-yet-deleted route 
entries into account when judging a RREP's usefulness? The current draft 
does not seem to require this.

Simulations with NIST-DYMO run fine, probably because a node increments 
its OwnSeqNum with every RREP it sends, regardless of the expected 
SeqNum included in a DYMO packet. It seems like DYMOUM, on the other 
hand, should run into the same problem, so I am bit confused.

Kind regards,

   Christoph Sommer

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Ian Chakeres" <[email-masked]>
Date: Mon, 14 May 2007 17:24:17 +0530

I think there might be a few issues here.

If the destination does not increment its OwnSeqNum, the RREP might be
discarded.  This fact is clearly called out in the draft in Section
5.3.2 in paragraph 3.

That said, I suspect one problem with the implementation is in the
route discovery proceedure. See Section 5.3.1 paragraph 3. After
failing to determine a route several times, the originator should not
include the SeqNum information for the target. In this case when the
RREQ reaches the target, the target will be required to increment its
sequence number and the RREP will then reach the originator.

Another issue in the implementation appears to be determining the
usefulness of routing information. In the above scenario, since the
new information has equal sequence number, equal hopcount, and is
being carried in a RREP - the information should be accepted as
superior. Please see Section 5.2.1.

Ian Chakeres