From: Andrew Lunn <andrew@lunn.ch>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] B.A.T.M.A.N.-Advanced Multicast Optimizations
Date: Wed, 8 Dec 2010 08:29:15 +0100 [thread overview]
Message-ID: <20101208072915.GA8875@lunn.ch> (raw)
In-Reply-To: <20101207221351.GA19474@Sellars>
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
next prev parent reply other threads:[~2010-12-08 7:29 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-07 22:13 [B.A.T.M.A.N.] B.A.T.M.A.N.-Advanced Multicast Optimizations Linus Lüssing
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 01/20] batman-adv: Add packet structures for multicast optimizations Linus Lüssing
2010-12-08 8:18 ` Andrew Lunn
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 02/20] batman-adv: Adding configurable variables " Linus Lüssing
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 03/20] batman-adv: compat macros/defines for local multicast group fetching Linus Lüssing
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 04/20] batman-adv: Attach local MCAs to OGMs Linus Lüssing
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 05/20] batman-adv: Add periodic multicast tracker timer Linus Lüssing
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 06/20] batman-adv: Buffer other originator's received MCA entries Linus Lüssing
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 07/20] batman-adv: Prepare and send own multicast tracker packets Linus Lüssing
2010-12-08 9:06 ` Andrew Lunn
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 08/20] batman-adv: Add length check for (received) " Linus Lüssing
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 09/20] batman-adv: Route multicast " Linus Lüssing
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 10/20] batman-adv: Add/refresh entries to/in mcast forwarding table Linus Lüssing
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 11/20] batman-adv: Output mcast forw table in debugfs Linus Lüssing
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 12/20] batman-adv: Purge timeouted entries in mcast forw table Linus Lüssing
2010-12-08 18:08 ` Andrew Lunn
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 13/20] batman-adv: Send own BAT_MCAST packets in proact_tracking multicast mode Linus Lüssing
2010-12-08 18:12 ` Andrew Lunn
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 14/20] batman-adv: Export broadcast packet ethernet header checks Linus Lüssing
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 15/20] batman-adv: Receive multicast data packets BAT_MCAST Linus Lüssing
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 16/20] batman-adv: Forward multicast data in proact_tracking mode Linus Lüssing
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 17/20] batman-adv: Add duplicate checks for multicast data Linus Lüssing
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 18/20] batman-adv: Still flood multicast packets we are not a receiver of Linus Lüssing
2010-12-10 13:07 ` Andrew Lunn
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 19/20] batman-adv: Make number of (re)broadcasts configurable via sysfs Linus Lüssing
2010-12-07 22:32 ` [B.A.T.M.A.N.] [PATCH 20/20] batman-adv: Do not disable irqs for spinlocks in multicast specific code Linus Lüssing
2010-12-08 7:29 ` Andrew Lunn [this message]
2010-12-09 21:02 ` [B.A.T.M.A.N.] B.A.T.M.A.N.-Advanced Multicast Optimizations Simon Wunderlich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101208072915.GA8875@lunn.ch \
--to=andrew@lunn.ch \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).