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