[B.A.T.M.A.N.] B.A.T.M.A.N.-Advanced Multicast Optimizations
simon.wunderlich at s2003.tu-chemnitz.de
Thu Dec 9 22:02:52 CET 2010
thank you for your comments and the review!
On Wed, Dec 08, 2010 at 08:29:15AM +0100, Andrew Lunn wrote:
> Do you think you could do a search/replace with "multicast MAC
You've got a point, we can change that.
> Is this symmetric assumption a problem? Depends one the use case. Your
> PIM gateway into the multicast cloud should be a member of the
> group. It has to receive the packets from the local hosts, so it can
> forward them upstream to the RP, the root of the distribution tree. So
> your traffic coming from upstream should be O.K. However if you have a
> webcam which is multicasting a video stream, it might not be a member
> of the group, since it is not interesting in receiving video streams,
> just sending them. So in this use case you won't have any benefit from
> your scheme.
> The symmetric assumption is a nice simplification to get started, but
> i think you need to have a good plan for allowing none members to send
> multicast traffic.
Yup, we had a "symmetric" application in mind when designing
this algorithm, but we have discussed ideas to improve the algorithm to
a more general scheme. For example we could detect if a multicast MAC
address is sent to through the soft interface, and then start
sending tracker packets accordingly - this method might need some tuning
however, the build up might take some time, and maybe we should avoid
building it up for single packets.
Detecting non-local receivers (like SNMP snooping) appears to be the
harder task IMHO to become more general - you will most likely not receive
your webcam stream with your WiFi AP. :)
> Have you considered handing broadcast packets as multicast packets?
> Broadcast is just a special case of multicast.
That is right, but I don't think this is a good idea to use this multicast
approach for broadcast in this case. From a theoretical point of view,
this algorithm is a group aware one for "sparse" mesh networks, where the number of
group members is quite small (< 50% of all mesh nodes). If all nodes were
in a group (as it would be the case for broadcast), the overhead of the
tracker packets would most likely nullify any gain. Non-group-aware algorithm
like MPR and its variations  are probably more suited for this case. But
maybe someone will find a clever workaround. ;)
 http://tools.ietf.org/html/draft-ietf-manet-smf-10 Appendices A to C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
More information about the B.A.T.M.A.N