Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2017-07-13,master
commit 0f0ddd843ab07123991ba782dd5bc2845b070e54 Author: Sven Eckelmann sven@narfation.org Date: Sat Mar 26 20:13:55 2011 +0000
doc: batman-adv/Multicast-ideas
0f0ddd843ab07123991ba782dd5bc2845b070e54 batman-adv/Multicast-ideas.textile | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/batman-adv/Multicast-ideas.textile b/batman-adv/Multicast-ideas.textile index b6e02247..65d4520a 100644 --- a/batman-adv/Multicast-ideas.textile +++ b/batman-adv/Multicast-ideas.textile @@ -1,11 +1,6 @@ - - h1. B.A.T.M.A.N.-Adv Multicast Awareness
-<pre> -<code class="div"> - As batman-adv has full control over all data traffic flowing through the mesh network multicast traffic also falls under its jurisdiction. At the time of writing this document batman-adv handles the multicast traffic by flooding the whole network with it. Although this approach is suitable for common multicast groups sending a small number of packets (e.g. IPv6 neighbor announcements) it fails its purpose when it comes to large multicast data packets (e.g. multimedia streaming). This document aims to provide a concept for multicast optimizations, especially when it comes to these large data packets.
@@ -35,14 +30,16 @@ Multicast data packets would still be treated as standard batman-adv data broadc This mechanism requires the multicast group infrastructure to be known. Shortly after creating/joining a new group this won't be the case. During the build up phase multicast data packets should still be broadcasted to ensure fast delivery.
-h2. New batman-adv packet types == - BAT_MCAST === +h2. New batman-adv packet types + +h3. BAT_MCAST + A multicast data packet that shall use an optimized path will still use a batman bcast_packet header, but set packet_type to BAT_MCAST.
h3. mcast_pathsel_packet
-<pre> +<pre></code> /* marks the path for multicast streams */ struct mcast_pathsel_packet { uint8_t packet_type; /* BAT_MCAST_PSEL */ @@ -51,16 +48,17 @@ struct mcast_pathsel_packet { uint8_t destr6; uint8_t ttl; uint8_t align; -} +attribute+((packed)); +} __attribute__((packed)); </code></pre>
h2. Pros/Cons
* As the mcast_path_sel packets are being forwarded via unicast, they'd create a multicast topology with determining shortest, direct paths according to BATMAN's unicast metric. ADAMA-SM for instance is not optimising in this way, instead it tries to reduce the number of forwarding nodes in general (which is nice for the mesh burdon itself, but might create unusable / too long paths for certain multicast receivers in real wireless networks). -----
-h2. Further Extensions == - Distribution infrastructure initiation - bursting === +h2. Further Extensions + +h3. Distribution infrastructure initiation - bursting + To decrease the time needed for the initial infrastructure creation, the multicast announcements could be send with their own packet type instead of being attached to OGMs. They could then be send in a burst of for instance 5 identical packets. Furthermore, these packets could have a rebroadcast-count which means, that also every intermediate node would rebreadcast for instance 5 identical packets again. The wait-time to switch from pure flooding of the multicast packets to the optimised path selection could then for instance be set to 1 instead of the 5 seconds. After that, such designated multicast annuncement packets could be send at a much slower interval as the OGM packets (something like 5-10 seconds for instance).
(Or if there'd be the planned NDP(neighbor discovery protocol) - HELLOs - as well as optional HNA entries (so a missing HNA in an OGM not causing it to be purged on other nodes in the mesh, a designated multicast announcement packet type would not be needed for this. We could just use a small OGM with less information, but still the TQ-value and sequence numbers, too, then as otherwise the ethernet frames' payload would be zero-padded to 46 Bytes anyway which would be a waste.)