Subject: [manet] AODV RFC - Interpretation of in which cases one may choose "local repair"

From: Andrew Hardy <[email-masked]>
Date: Wed, 31 Oct 2012 12:45:42 +0000

I am a student researcher and part of my work means I need to look at AODV.

I have been given an interpretation by an implementer of the
circumstance under which "local repair" may be appropriate and I am
having difficulty reconciling this with the RFC.
This interpretation says that, if chosen to be turned on, "local repair"
will be actioned if a line break occurs for ANY kind of packet,
including RREP, RERR and so on and NOT JUST for 'data' packets.

Therefore, for example, in the case of a line break for a RREP, if local
repair is configured, the RREP is buffered and a RREQ for the original
RREQ originator node is issued.  If this latest RREQ results in a RREP
arriving back at the node which encountered the line break then the
buffered RREP is unicast again, but if such a RREP does not arrive back
then the the node which encountered the line break for the RREP it was
trying to send, sends a RERR back on the precursors towards the
destination of the original RREQ, i.e. the originator of the RREP.

If find this difficult to reconcile with the RFC and I will do my best
to explain why

1)
Under local repair the text regarding buffering the text explicitly says
'data' packets are buffered.  Perhaps implying not other packets.

2)
RERRs are sent on the precursor.  I had thought that precursors by
definition were created from the next hop forwarding node of each RREP,
in which case there would be no precursors in the direction of the
destination of the original RREQ at the node with the line break on
sending the RREP.  The last sentence of 6.7 may have something to say
against this but I  am finding that piece hard to understand.

3)
Regarding 2) even if a RERR IS issued following failed forwarding of a
RREP, this RERR will arrive back at the destination of the original RREQ
and I can find no instructions that say a destination will reissue a
RREP on receipt of a RERR.

4)
6.12 'Local Repair' begins "when a line break ocurrs in an 'active'
route...", I am thinking that the the route the RREP is about to be
forwarded on is, though valid, not actually an 'active' route and so
"local Repair" does not apply.
When a RREP is processed the route to the destination (i.e. the
destination requested by the originating RREQ) is marked as 'active'.
However there seems to be nothing to say that the route to originator on
which the RREP is next forwarded is marked as active before forwarding
and nothing in the processing of RREQs to say that the route to the
originator is marked as active, so I am assuming that this reverse route
TO the originator is NOT an active route.

5)
6.7 describes forwarding of RREP and refers to 6.8 which describes
possible actions if a RREP fails.  If "local repair" were an option for
failed RREPs, one might expect some reference to it here, but there is not.

6)
Finally perhaps I am misreading the RFC, but informally it doesn't seem
obvious to me from the RFC that "local repair" may be chosen for failed
RREP, RERR, RREP_ACK and so on.  Anecdotally, using the implementation
in question, I have a network which has high density and high path loss
and some congestion from time to time.  With local repair turned off
occasionally a route requested is repeated, but with local repair turned
on, one failed RREP seems to snow ball into more and more congestion.

Perhaps part of the confusion arises out of the fact that in some
implementations the destination can use the reverse route (to the
originator of the original route requested) for the purpose of sending
data.  However I don't see where this route is 'marked as active',
unless active is not a mark/flag, but is simply a 'valid' route which
has an in time active_route_timeout.  If this is the case, then perhaps
the reverse route used by the RREP IS active and therefore "local
repair" does apply to RREPs, but some how, intuitively, it doesn't seem
right.

I hope this has made some sense.  Any guidance would be gratefully received.

Thank you

________________________________
Important Notice: the information in this email and any attachments is for the sole use of the intended recipient(s). If you are not an intended recipient, or a person responsible for delivering it to an intended recipient, you should delete it from your system immediately without disclosing its contents elsewhere and advise the sender by returning the email or by telephoning a number contained in the body of the email. No responsibility is accepted for loss or damage arising from viruses or changes made to this message after it was sent. The views contained in this email are those of the author and not necessarily those of Liverpool John Moores University.