Subject: [manet] #56 (aodvv2): Issue concerning RREQ redundancy check methodology and order

From: "manet issue tracker" <[email-masked]>
Date: Wed, 08 Oct 2014 16:18:37 -0000

#56: Issue concerning RREQ redundancy check methodology and order

 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.

-- 
-------------------------------------+-------------------------------------
 Reporter:  lotte.steenbrink@fu-     |      Owner:  draft-ietf-manet-
  berlin.de                          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  minor                    |  Milestone:
Component:  aodvv2                   |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/56>
manet <http://tools.ietf.org/manet/>