[aodvv2-discuss] Fwd: Re: [manet] draft-ietf-manet-aodvv2-11 review

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
  • Date: Mon, 3 Aug 2015 11:28:50 -0700


Hello folks,

If no objection, I could forward this email to the [manet] mailing list as well.

Regards,
Charlie P.


-------- Forwarded Message --------
Subject: Re: [manet] draft-ietf-manet-aodvv2-11 review
Date: Mon, 3 Aug 2015 11:27:46 -0700
From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
To: Marc.Mosko@xxxxxxxx



Hello Mark,

Here are some follow-up comments to your observations.

On 7/24/2015 12:57 PM, Marc.Mosko@xxxxxxxx wrote:


- multi-homing: Is this implying that a Router Client can only have 1 network interface and only 1 IP address? What happens if it has, say 2 radios, but is not willing to forward packets for another node? It would help to have a strong definition of what “multi-homing” means or maybe say a bit more in the definition of a Router Client.

It means that a Router Client can only be a client of one AODVv2 router. That restriction could be lifted, but it would take additional specification. There should be no restriction on a Router Client having other interfaces as long as the same IP address is not served as the client of multiple AODVv2 routers.

We could sharpen this up a bit without too much damage to the current specification. But I would like to avoid if possible the requirement to specify how an AODVv2 router might "partition" its AODVv2_INTERFACES into separate "lists" of AODVv2_INTERFACES that have separate SEQ_NUMs. At least, not have to do it this week!



- Comparing sequence numbers. Section 4.4 says you wrap from 65535 to 1, but all the sections that I saw comparing sequence numbers just use “>” or “<“ or “=“. For example, Sec 6.5.1 bullet #2 “Compare sequence numbers” does not address wrap-around. How do you handle comparing wrap-around? The old aodv spec had a section on that. Is it RFC 1982? If it’s defined somewhere and I missed it? I think sec 4.4 should define this.

Yes, I agree that the specification of this comparison needs to be in the current document. This was apparently just noticed recently, or anyway nobody complained until recently and I somehow mistakenly assumed that the comparison was specified since it had been in previous versions.


- Section 6.3 says “In its default mode of operation…” what’s the other mode besides RFC5444?

That remains to be specified. Probably we don't need to say that here; the language has been in there since Ian made the first attempts to conform to RFC 5444.


- Section 6.3 says “When multiple interfaces are available, a node…” This should be clarified if it means both a router and client or just router (see comments on clarifying multi-homing).

It just means the router; the word "node" could be replaced by "AODVv2 router" for more clarity, although the rest of the paragraph really only applies to routers.



- Section 7.1.2 bullet #2 says “Verify the message hop count, if included, hasn’t exceeded MAX_HOPCOUNT.” However, D.2.2 does not include that check. It’s done in D.2.3 Regenerate_RREQ (which is described in 7.1.3).

- Section 7.2.2 bullet #2 on MAX_HOPCOUNT for RREP has parallel inconsistency with D.3.2 and D.3.3.

Good Catch!


- D.2.3 Regenerate_RREQ decrements the inRREQ.HopLimit, but I did not see in Receive_RREQ that is assures the inRREQ.HopLimit is positive. Well-behaving nodes should never send a RREQ with a 0 hop limit due to rules in Regenerate_RREQ, but if a misbehaving node does it will cause a math issue possibly wrapping around to some large positive number.

- D.3.3 Regenerate_RREP probably has the same issue.

Thanks much for these comments.

Regards,
Charlie P.



Other related posts:

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