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

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Tue, 27 Jan 2015 13:10:51 -0800

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.


> 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.

=== 57    Need to further restrict "LoopFree" condition  ===

Fixed.
Suggest closing issue.
Or, wait for further analysis from Vicki.

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