Hello Vicky,
On 11/18/2015 1:35 AM, Victoria Mercieca wrote:
Hi all,
I'm reviving this thread in light of the comments overnight from Thomas Clausen and Christopher Dearlove.
Aside from Thomas' comments about interoperability:
/"
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./
"
I still didnt understand how this would actually work. From the previous conversation:
On Sun, Oct 11, 2015 at 12:44 AM, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello Vicky,
Follow-up below.
On 10/10/2015 9:45 AM, Victoria Mercieca wrote:
Hi Charlie,
Still trying to understand how it works, so I cant say whether
the statement you mentioned we could make, or the extra draft,
will be helpful.
So... is this how it works?
When originating an RREQ, a router sends it without involving a
6621 implementation.
Check.
A router receives a multicast RREQ message. A 6621 implementation
makes a note of whether it should be re-sent.
It should never be re-sent at this point because TTL=1.
So if TTL is 1, would the RFC6621 implementation note that the message shouldnt be resent, and would AODVv2 be told the message wouldnt be resent? In which case, AODVv2 wouldnt send a regenerated version either.
Also, what if the packet contains multiple MANET messages? And how can we be sure TTL is 1 and RFC6621 wouldnt resend? In this case, surely we need to get the 6621 implementation to find out if there's an AODVv2 message included, and not forward the packet? Or strip the AODVv2 part out and maybe forward the non-AODVv2 parts? How would this even work?
AODVv2 processes the message.
There are then two options:
Router prepares a regenerated version of the RREQ, and checks
with the 6621 implementation if it should send it, then sends it.
The 6621 implementation doesn't resend any version of it.
Any version of it will already be unsendable because TTL=1.
As above, if the RFC6621 implementation would have not resent the message anyway due to TTL being 1, then AODVv2 will check with the 6621 implementation and see that it shouldnt be resent, and AODVv2 would not send a regenerated version either?
Or
Router creates RREP, and sends it without checking anything with
6621. Again the 6621 implementation doesn't resend anything.
Check.
Wouldnt this require changes to 6621 implementations, so that
they can find out if they received a multicast packet containing
an AODVv2 message and decide not to resend it and signal to
AODVv2 to handle it? How does it handle the fact that the
multicast packet can contain multiple messages from different
protocols all using 5444? Does the 6621 implementation need to
parse 5444 formatting and separate out the AODVv2 bit
What needs to happen is that AODVv2 does not multicast regenerated
RteMsgs if multicast retransmission is inhibited by RFC 6621.
How does it get notified that multicast retransmission would be inhibited by 6621? Does this require changes to 6621 implementations?
Alternatively, we could add a step in the regeneration algorithm
that says "Do not regenerate if RFC 6621 is inhibiting
retransmission". That would be the content of the Internet Draft
I would write, and probably will.
