Sorry for the confusion, I meant the fields are part of the rfc5444 message
rather than the rfc5444 packet. So multiplexing is fine. But since the
message is from and to aodvv2, these fields are sort of "ours" to use.
Appendix B of RFC5444 says the MANET router should decrease the hop limit
and increase the hop count when forwarding a message. So AODVv2 (or
whatever other MANET routing protocol) would be responsible for that +/-1.
"Used to prevent messages from circulating endlessly in a MANET". So in
summary, I'm not sure we are currently doing it wrong...
Either way, unless there was something I missed, we can accomplish more or
less the same using max metric values.
Also, I found the text I was looking for earlier, in section 7.1 of RFC
5444, where it says about fields changing when forwarded. I think we use
"regeneration" to make it clear we are changing more than hop limit and hop
count and this is also why we would do hop by hop security rather than end
to end. Can we legitimately use the word "forwarding" if we are changing
the metric value, adding a validity time, or adding/removing AckReq?
Regards,
Vicky
On 18 Nov 2015 15:12, "Ratliff, Stanley" <sratliff@xxxxxxxxxxx> wrote:
Vicky,
That confuses me a bit. You said “…so we can use them for our own purposes
since they are part of the AODVv2 message…”. But Thomas says “…the RFC5444
hop-limit/hop-count fields…”.
Are we talking about AODVv2-specific fields, or something that RFC5444
“owns”, but allows applications to set? If it’s the latter, then I really
don’t understand how multiplexing works (this would seem to be a circular
argument much like the ‘TTL’ field everyone haggled about earlier).
I like the notion of using MAX_METRIC, and completely taking this issue
off the table.
Regards,
Stan
*From:* aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:
aodvv2-discuss-bounce@xxxxxxxxxxxxx] *On Behalf Of *Victoria Mercieca
*Sent:* Wednesday, November 18, 2015 10:03 AM
*To:* aodvv2-discuss@xxxxxxxxxxxxx
*Subject:* [aodvv2-discuss] Re: regeneration vs forwarding
Hi Stan, hope you're well!
Well... we are allowed to set these fields...so we can use them for our
own purposes since they are part of the AODVv2 message...at least we
thought we could set and use them as we like...but Thomas seems to think
this inappropriate.
If we dont use them, we dont have the concept of "network diameter", and a
maximum number of hops allowed in a route discovery. Unless we are using
the hopcount metric type, in which case the test for MAX_METRIC
accomplishes this anyway. In fact for any cost metric type, MAX_METRIC
accomplishes this type of limit...
...so maybe we can do away with the msg_hop_count and msg_hop_limit
fields, set them to 1 every time? Unless I'm forgetting something else.....
Regards,
Vicky
On Wed, Nov 18, 2015 at 2:36 PM, Ratliff, Stanley <sratliff@xxxxxxxxxxx>
wrote:
Vicky,
As I read the comment, RFC5444 hop-limit/hop-count just flat don’t work,
because the message is (effectively) “generated anew” at each hop. The
document may call it “regenerated”, but fact is it’s a “new packet” – not
something that we’ve just noticed as it flew by, but something that is
effectively consumed, then a fresh (and potentially modified) copy is
issued again.
That being the case, I don’t understand how the hop count is anything
other than ‘1’. Each and every time.
Regards,
Stan
*From:* aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:
aodvv2-discuss-bounce@xxxxxxxxxxxxx] *On Behalf Of *Victoria Mercieca
*Sent:* Wednesday, November 18, 2015 4:53 AM
*To:* aodvv2-discuss@xxxxxxxxxxxxx
*Subject:* [aodvv2-discuss] regeneration vs forwarding
Hi all,
Regarding Thomas comments on this subject in the email to MANET overnight
(below).
I thought we took this decision to "regenerate" since for RREQ and RREP,
we may add TLVs (AckReq, ValidityTime) or remove TLVs (AckReq), and because
we change the metric in the message. In RERR we remove addresses (and
associated TLVs) that there is no point re-reporting, i.e. Unreachable
Addresses that didnt affect any of our own routes.
Somewhere in the back of my mind there was some statement that when using
RFC5444 we shouldnt change anything other than header fields of a message
when forwarding it... but now I cant find where that was written. Since we
are changing the metric, and potentially adding or removing TLVs, was the
problem that it would affect the value in an ICV field?
The changes we make to the message content are:
- We change the metric so that each router along the path learns a
route from the message, with the metric associated with the path up to that
point
- AckReq only applies between hops, so needs to be removed or added
accordingly.
- ValidityTime could potentially be added at any intermediate router
that wishes to limit the time it will forward packets on the route.
- Stripping out Unreachable Addresses from RERR which did not affect
our route set.
Picking one particular comment from Thomas Clausen's email:
"Second, if a RREQ message is hop-by-hop only, then I do not think that
the use of the RFC5444 hop-limit/hop-count fields is appropriate."
I think we only really use these to test if the message has exceeded
MAX_HOPCOUNT, i.e. the diameter of the network?
Regards,
Vicky.
---------- Forwarded message ----------
From: *Thomas Clausen* <ietf@xxxxxxxxxxxxxxxxx>
Date: Wed, Nov 18, 2015 at 1:35 AM
Subject: Re: [manet] draft-ietf-manet-aodvv2-12 and
draft-ietf-manet-dlep-17
To: "Ratliff, Stanley" <sratliff@xxxxxxxxxxx>
Cc: "manet@xxxxxxxx" <manet@xxxxxxxx>
Dear all,
I have started looking through the recently
updated draft-ietf-manet-aodvv2-12. A lot has changed, and I regret not to
have had a blow-by-bow comeback to the previous review comments - would
have made it a somewhat easier task to check if all have been addressed or
not.
But, I will work through it and produce a detailed review - but from my
first quick read-through there're a couple of issue that jumped at me as
worth bringing forward on a more global level already.
The first relates to how RREQs are forwarded -- or, more generally, are
not.
The protocol currently talks about "message is regenerated" rather than
"forwarded". I have understood that this means that a RREQ is actually not
an "end to end" entity, but is a "hop by hop" entity.
First, that is a curious design choice, is there any reason why this is so
considered?
Second, if a RREQ message is hop-by-hop only, then I do not think that the
use of the RFC5444 hop-limit/hop-count fields is appropriate.
Third, the statement in section 6.5 on the use of RFC6621 is incorrect in
two ways: RFC6621 does specify how messages are *forwarded* (but, as
discussed above, you are not forwarding messages).
More seriously, this paragraph is incorrect:
"Implementations MAY choose to employ techniques to reduce the number of
multicast messages sent. Use of [RFC6621
<https://tools.ietf.org/html/rfc6621>] in deployments is recommended.
Employing [RFC6621 <https://tools.ietf.org/html/rfc6621>] in a subset of the
operational AODVv2 routers in a network, or configuring different algorithms
on different routers, will not cause interoperability issues, but will reduce
the effectiveness of the multicast reduction scheme."
Different routers using different relay selection algorithms in the same
network will not *just* cause loss of efficiency, but *will* cause
interoperability issues.
For example if "router A" decides to suppress its message relaying because
it estimates that "router B" provides sufficient coverage - and conversely
"router B" suppresses relaying for the same reason: neither A nor B would
relay, and so any routers reachable only via A and B would not be covered.
This is not a far-sought example: it can be as simple as A and B simply
using self-selecting relay algorithms with different tie-breakers.
In short: I think that the whole message flooding/regeneration part
requires serious work.
The second issue is that I also suspect that there is some issue with
buffering, or rather with how it is specified; starting in section 6.6, I
am not sure that leaving that as "a matter of policy at each router" is
entirely right.
Also on buffering, I am wondering if the "start delivering buffered
packets" conditions (penultimate paragraph in 6.6, and of course through
the processing sections) is sufficient; I suspect that the condition "When
a valid route is installed" is not sufficient - that there are situations
where a routing table entry is installed, but the complete route is not
available or is not bidirectional?This obviously is related to RREP_Ack
being hop-by-hop and not end-to-end....
Either way, the parts of the specification that relate to buffering
contain a mixture of normative and non-normative verbiage (a lot of "can"
but also a lot of MUST/SHOULD) which I think could do with a tightening up.
But....is buffering even something that should be specified by this
document? It does not impact interoperability and it interferes
substantially with transport and congestion control, and I am not sure that
we understand the consequences (I am not convinced that the claims in the
document on benefits to TCP are substantiated or even true).
As I indicated, a complete review will follow, but I thought that these
was a global enough topics to call out and get engineered right.
Thomas
PS: I remain convinced that the security considerations section is
insufficient ; I will try to articulate my thoughts on why that is, but for
starters looking at the recently raised (by somebody else, the Chris
replied) AODV security questions would probably be helpful
On 10 Nov 2015, at 02:10, Ratliff, Stanley <sratliff@xxxxxxxxxxx> wrote:
Hello WG participants –
The above referenced drafts were posted Oct. 13 (for AODVv2), and Oct. 16
(DLEP). The co-authors and the chairs ask that you please take some time to
review and comment on the new submissions.
Regards,
Stan
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________
_______________________________________________
manet mailing list
manet@xxxxxxxx
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@xxxxxxxx
https://www.ietf.org/mailman/listinfo/manet
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________
