[aodvv2-discuss] Re: Hangout in progress?

  • From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Sat, 19 Mar 2016 16:57:46 +0100


Am 19.03.2016 um 16:51 schrieb Lotte Steenbrink 
<lotte.steenbrink@xxxxxxxxxxxx>:

Hi Vicky,

Am 19.03.2016 um 16:14 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx 
<mailto:vmercieca0@xxxxxxxxx>>:

Just thinking quickly (so I could have forgotten something)...would that 
RREP contain the AckReq element which contains the IP address of who the Ack 
is expected from…?

Oooh, good point! Yes it would! Sorry I didn’t think about that :) Problem 
solved, thanks.

Wait, nope…  The sent RREP would contain the AckReq, *but* we’re not storing 
that in the MRMT.. If nobody objects, I’d propose to add 

RteMsg.AckReqAddr 
        The address from which a RREP_Ack is expected, if RteMsg is a RREP that 
contains an AckReq.

to the table– since the MRMT is a conceptual table, nobody has to implement it 
as an actual table containing this extra column in every entry (which might be 
a problem for resource-constained devices) ?


Lotte

Vicky :-)

On 19 Mar 2016 10:06, "Lotte Steenbrink" <lotte.steenbrink@xxxxxxxxxxxx 
<mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
Hi all,

Am 04.03.2016 um 19:21 schrieb Lotte Steenbrink 
<lotte.steenbrink@xxxxxxxxxxxx <mailto: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:

  1. Home
  2. aodvv2-discuss
  3. Archive
  4. 03-2016