[aodvv2-discuss] Re: Hangout in progress?
- From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
- To: aodvv2-discuss@xxxxxxxxxxxxx
- Date: Sat, 19 Mar 2016 11:06:42 +0100
Hi all,
Am 04.03.2016 um 19:21 schrieb Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx>:
<snip>
(What are we checking! What table or timer is there to check? JWD!)
Fix: add reference to multicast route message table: if no RREP matching our
RREP_Ack is found there, no actions are required (as the RREQ was unsolicited
and should thus be ignored).
Buuut, as I'm typing this, I'm wondering– some RREPs are unicast and would
thus not be in the Multicast table– is this a problem? I'm thinking it
wouldn't because neighbors whose bidirectionality is unconfirmed get their
RREPs via multicast, but then the document shouldn't say:
"and RREP messages may be multicast when the link to
the next router is not known to be bidirectional.
"
in section 4.6, should it? I think we should change the "may" to "will".
Quick follow-ups to that one:
1) finding the RREP matching our RREP_Ack in the Multicast Route Message Table
is a bit more complicated than I’d anticipated: since the RREP is multicast
when no bidirectionality is determined yet, the MRMT doesn’t contain any info
regarding the IP Address who we’re expecting the RREP_Ack from. Consequently, a
RREP_Ack would be considered expected if it matched *any* RREP in the MRMT
(i.e. if the MRMT contains a RREP with RteMsg.Timestamp > CurrentTime -
RREP_Ack_SENT_TIMEOUT).
At the very least, this should be mentioned in the Security Considerations, but
I’m wondering if there’s anyting we can do to improve this situation?
2) since I didn’t see anyone protesting, I’ve changed „may“ to „will“ as
suggested above :D
Other related posts:
