Opened 5 years ago

#56 new defect

Issue concerning RREQ redundancy check methodology and order

Reported by: lotte.steenbrink@… Owned by: draft-ietf-manet-aodvv2@…
Priority: minor Milestone:
Component: aodvv2 Version:
Severity: Active WG Document Keywords:
Cc:

Description

The check for redundancy of a RREQ is described in section 7.5.1, which is after section 7.5., which instructs the implementor to update the routing table with the info contained in a received RteMsg? (with reference to Section 6.1.). In consequence, if the implementor applied the checks in the order of the sections they're described in, the check for redundancy would take place after the routing table has been consulted.

I would like to address two issues concerning the updating process described above.

1) Following this scheme, a RREQ that is “redundant”, but with a better metric, would update the routing table, but *not* the RREQ table, since the RREQ Table only checks for metric Type, but not for metric value. In consequence, it would also not lead to a rebroadcasting of the new, better (in terms of metric) RREQ. This doesn't make sense to me, am I missing something here or is this in fact a defect?

2) Consider the following scenario:

Suppose a router A starts a route discovery. An intermediate router B receives two RREQs from two different neighbor routers (let's call them C and D). These RREQs both stem from the same route discovery initiated by A. Suppose the RREQ forwarded by C arrives first, leading to an update of the routing and RREQ table if B. Then, the RREQ forwarded by D arrives second at B. Because a redundant RREQ has the same SeqNum? as its predecessor(s), the check

  Stale::  RteMsg.SeqNum < Route.SeqNum

will fail, leading to an update of B's routing table with the information of the redundant RREQ-- if the metric info of the redundant RREQ was a) equal or b) better.

In case a), since the check for RREQ redundancy is performed after the routing table update, redundant RREQs may “update” the routing table with the exact same data it held before. This seems like computational overhead to me which could be solved by first checking the RREQ for redundancy and only updating the Routing table if this check turned out negative. However, this solution would only work if the RREQ table checked not only metric type, but metric value, as suggested in 1). Another solution would be to keep the order (routing table update, then RREQ table redundancy check) only update the routing table in case b). This would still involve an extra call to the routing table, but saves the effort of copying redundant data.

Change History (0)

Note: See TracTickets for help on using tickets.