[aodvv2-discuss] Re: Issues 36, 37, 38, 40, 42, 43, 44, 45, 47, 49, 50, 56, 57, 61

  • From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Thu, 29 Jan 2015 15:35:37 +0100

Hi everyone,
(comments inline too)

Am 29.01.2015 um 10:42 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:

> Hi all,
> 
> Comments on issue 56 and 57 in line...
> 
> 
> On Tue, Jan 27, 2015 at 9:10 PM, Charlie Perkins 
> <charles.perkins@xxxxxxxxxxxxx> wrote:
> Hello folks,
> 
> I have gone through the above remaining issues.  We need to discuss
> issue #56.  Stan was going to wordsmith something about how RFC 5444
> was in charge of security.  We were all going to read RFC 7182.  I did
> start to read it.  I need to provide text for issue #36, but I'd like to first
> see what Stan's wordsmithing would look like.
> 
> Most of the other remaining issues not mentioned below already have
> some proposal for resolution.
> 
> Can we have another conference call this Friday?
> 
> Regards,
> Charlie P.
> 
> 
> ===========================================================
> 
> === 36    Security Considerations: Reactive protocol concept  ===
> 
> Need to update Applicability statement to explain when reactive
> protocols are applicable even in the face of the threat as described.
> 
> === 37    Security Considerations: what needs to be implemented? ===
> 
> Stan's solution, wordsmithed for this.
> RFC 5444 problem.
> 
> === 38    difficulty to do security, in case messages are mutable ===
> 
> Stan's solution, wordsmithed for this.
> RFC 5444 problem.
> 
> === 40    AckReq vs RREP_ACK  ===
> 
> Reject with explanation that AckReq triggers RREP_ACK, so that
> they serve different purposes.
> 
> === 42    What happens if Active routes exceed RERR packet size? ===
> 
> Send multiple RERR packets in this case.  Add sentence to draft.
> Suggest closing issue.
> 
> === 43    Reliance on bidirectional paths (submitted for Chris Dearlove)  ===
> 
> We are now making RREP_ACK mandatory to implement.
> Suggest closing issue.
> 
> === 44    Hop count (submitted for Chris Dearlove)  ===
> 
> Metric in AODVv2 is implementable by pure fact of being
> required to be monotonically increasing.
> Suggest closing issue.
> 
> === 45    RFC 5498 non-compliance (submitted for Chris Dearlove) ===
> 
> Areas of noncompliance have been revised.
> Suggest closing issue.
> 
> === 47    Security approach unacceptable (submitted for Chris Dearlove)  ===
> 
> Stan's solution, wordsmithed for this.
> RFC 5444 problem.
> 
> === 49    Locating pseudocode in appendix (submitted for Chris Dearlove)  ===
> 
> Non-normative example text for specific cases provided as
> a hint for implementers.
> Suggest closing issue.
> 
> === 50    Weak gateway support (submitted for Chris Dearlove)  ===
> 
> Full gateway support is out of scope for the document.
> Refer to previous discussion on mailing list.
> Suggest closing issue, or else chartering a gateway draft.
> Note: We had a gateway draft already that was implemented
> and known working.
> 
> === 56    Issue concerning RREQ redundancy check methodology and order  ===
> 
> Look at moving section 7.5.1 so that RREQ redundancy precedes route table 
> check
> 
> Check RREQ redundancy (using RREQ table):
> - same metric type
> - same OrigAddr and TargAddr
> 
> Check route table (using route table):
> - same metric type
> - same TargAddr
> - not stale SeqNum
> - if SeqNum ==, then look at metric value, etc.
> 
> 
> > 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?
> 
> 
> The redundant RREQ typically does not have to be rebroadcast, since
> any RREP will take the improved route back to OrigAddr.  However,
> RREP might not reach the intermediate node at all if some other route
> looked better because of the nonoptimal metric back to OrigAddr.  We
> *could* specify that RREQs may be re-broadcast and add Metric to the
> RREQ redundancy table.
> 
> TO DISCUSS.
>  
> I like this idea. The way I read the current draft, it already does check 
> metric to determine if the incoming RREQ should replace the one in the table. 
> I thought this would result in the RREQ being regenerated, but you are right, 
> if we are concerned about the metric being correct then it will need to be 
> re-broadcast, but the route should already exist because of the previous RREQ 
> so we could make it optional to re-send the second RREQ. 

...But the already existing route could be a possibly worse one over an 
entirely different route, right?
In any case, I like your suggestion.

> 
> 
> > 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.
> 
> Let's consider specifying that the RREQ redundancy check happens before
> the route table check.
> 
> TO DISCUSS.
> 
> I think this should happen - with the check on metric in the RREQ. If the 
> incoming RREQ updates the RREQ table, it should then get processed as normal 
> (but maybe with the option to restrict re-broadcast).
> 

+1

> === 57    Need to further restrict "LoopFree" condition  ===
> 
> Fixed.
> Suggest closing issue.
> Or, wait for further analysis from Vicki.
> 
> 
> I would like to analyse this a bit further. I have one example of where 
> removing the +1 that was previously part of the LoopFree condition results in 
> a route being ignored when it does not form a loop, and I have an idea for 
> the LoopFree calculation (which I've mentioned in my "Notes on AODVv2 Draft" 
> document under 6.5.2) but I'd like to test it in a few example scenarios and 
> maybe add an explanation before we close this issue. Would you be able to 
> send me the proof that Kedar Namjoshi and Richard Trefler provided for their 
> work on the LoopFree condition?
> 

Will you be attending the call on friday too? If so, we could discuss this in 
depth...

Cheers,
Lotte

> Regards,
> Vicky.
> 
> 61    Difference between "broken" and "expired" (Submitted for Justin Dean)
> 
> Propose to coalesce the two states.  My analysis shows
> no harm, resulting improvement from simplification.
> Suggest to list and closing the issue.

Other related posts:

  1. Home
  2. aodvv2-discuss
  3. Archive
  4. 01-2015