Re: [B.A.T.M.A.N.] B.A.T.M.A.N.-Advanced Multicast Optimizations

Andrew Lunn
2010-12-08T07:29:15Z

On Tue, Dec 07, 2010 at 11:13:51PM +0100, Linus L??ssing wrote:
> Please see the attached document for details about the algorithm,
> the integration into the current B.A.T.M.A.N.-Advanced
> code and how to activate/use this mode.

Hi Linus, Simon

Nice document.

However one thing i don't like about it is the use of multicast
group. In the Terminology you define it as:

multicast group: B.A.T.M.A.N. advanced will not distinguish between
different multicast group IDs / IP protocols on layer 3. Instead, the
term multicast group will be used analogously for a multicast mac
address.

This is quite different to the normal usage of the term. In the RFC's
the multicast group is always an IP address in the range 224.0.0.0/4.

When looking at B.A.T.M.A.N. on its own, your definition is O.K, but
when you start to consider the whole protocol stack, it will lead to
confusion.

Do you think you could do a search/replace with "multicast MAC
address"?

Also, the meaning of symmetric multicast group membership takes a bit
of understanding. Once i read section 2.2.1 it became clear, but maybe
that section should be earlier in the document? Also, from experience
talking to people about IP multicast, i know people have trouble
getting the concept you can send a multicast packet without being a
member of the group. Maybe a short explanation of how IP multicast
works, or a link to a good tutorial would be good.

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.

Have you considered handing broadcast packets as multicast packets?
Broadcast is just a special case of multicast.

Andrew