Hello Vicky,
Follow-up below:
On 10/6/2015 11:20 AM, Victoria Mercieca wrote:
So 6621 gets involved when we send a multicast packet...not when we receive one that might want resending to ensure the whole network receives it?
How will it know if it can suppress the message? Does it mean that only certain routers (determined to be in some particular set by 6621) will ever participate in message regeneration
Vicky
On 6 Oct 2015 5:22 pm, "Charlie Perkins" <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello Vicky,
On 10/6/2015 5:26 AM, Victoria Mercieca wrote:
Hi...
I think the last call we had, we stated that 6621 would run
alongside AODVv2... As far as I understand it (and I dont profess
to understand much about 6621) 6621 determines whether a node
needs to re-send a multicast message. i.e. if it doesnt re-send
it, will everyone still hear it?
Yes, that is right.
Also, the message itself would be sent unchanged, but this is not
what we want in AODVv2 is it? We want AODVv2 to get the message
and decide whether to regenerate it.
We want AODVv2 to use RFC 6621 to decide whether or not to
transmit messages to the multicast group. It does not matter what
the message is.
So would 6621 give AODVv2 an indication of whether it thought it
would re-send a received message, then let AODVv2 update and send
the regenerated version? I dont understand how the two would work
together.
RFC 6621 would determine whether a node sends *any* message to the
multicast group.
Regards,
Charlie P.
Regards,
Vicky.
On Wed, Sep 30, 2015 at 1:45 AM, Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx
<mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello folks,
We had a discussion thread about the use of techniques in RFC
6621. I mentioned at the time that I was not aware of any
downside in the circumstance that some AODVv2 routers would
implement RFC 6621 and others would not.
That isn't a very precise statement because there is more
than one algorithm discussed in RFC 6621; moreover, there is
more than one kind of "downside". Nevertheless, to the best
of my knowledge my claim remains true "in spirit". Here is
some example text taken from Appendix A of RFC 6621, which is
naturally much more precise than my earlier claim.
The "Essential Connected Dominating Set" (E-CDS)
algorithm [RFC5614]
forms a single CDS mesh for the SMF operating
region. It allows
routers to use 2-hop neighborhood topology
information to dynamically
perform relay self-election to form a CDS. Its
packet-forwarding
rules are not dependent upon previous hop knowledge. Additionally,
E-CDS SMF forwarders can be easily mixed without
problems with CF SMF
forwarders, even those not participating in NHDP. Another benefit is
that packets opportunistically received from
non-symmetric neighbors
may be forwarded without compromising flooding
efficiency or
correctness. Furthermore, multicast sources not
participating in
NHDP may freely inject their traffic, and any
neighboring E-CDS
relays will properly forward the traffic.
If we specialize our suggestion to say E-CDS instead of RFC
6621, it might curtail some uncertainty. And I like E-CDS
the best. Nevertheless, I believe the same considerations
hold for MPR selection algorithms.
Regards,
Charlie P.
