Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2017-07-13,master
commit 5e7a05da20a7204b678bc50260877a59a09746a8 Author: Linus Lüssing linus.luessing@c0d3.blue Date: Mon Jun 28 23:26:23 2010 +0000
doc: batman-adv/Multicast-ideas: wouldn't need a new packet type, just the unicast struct
5e7a05da20a7204b678bc50260877a59a09746a8 batman-adv/Multicast-ideas.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/batman-adv/Multicast-ideas.textile b/batman-adv/Multicast-ideas.textile index b83b5816..df9f1998 100644 --- a/batman-adv/Multicast-ideas.textile +++ b/batman-adv/Multicast-ideas.textile @@ -75,11 +75,11 @@ If so, the intermediate node should not rebroadcast this multicast data packet. A node knows, whether there might be a single multicast member of the same group on the forwarding path left (or better: whether all but one multicast members are behind the neighbor we just received the multicast-data packet from) because of the previously received, broadcasted OGMs (+ MCA entries). In this case, the forwarding node can unwrapp the multicast data packet and wrap it into a batman unicast-header to this single destination instead. This will greatly increase the reliability and throughput to such a remote multicast member because the rate selection algorithms being able to select an optimal value instead of just broadcasting it with the default value of 11MBit/s on the one hand and the now acknowledged transfer for the rest of the path on the other.
=== switching between multicast and unicast forwarding === -This is basically an extension of the optimization stated above. But instead of converting a BAT_MCAST to unicast only once at the end of a packets journey, this optimization here also suggests to convert the means of tranportation back and forth: If a multicast data packets journey would get to a crotch, so two different forwarding nodes as next hops for the data, then the packet should be broadcasted by the node on the crotch with the advantage of only blocking the wifi medium once (as the basic algorithm is doing it, too). However, if a node which is part of the distribution infrastructure and knows, that there's just one recipient, just one next hop being a forwarding node, then the multicast data packet should be send as a unicast packet (with a special packet structure *). +This is basically an extension of the optimization stated above. But instead of converting a BAT_MCAST to unicast only once at the end of a packets journey, this optimization here also suggests to convert the means of tranportation back and forth: If a multicast data packets journey would get to a crotch, so two different forwarding nodes as next hops for the data, then the packet should be broadcasted by the node on the crotch with the advantage of only blocking the wifi medium once (as the basic algorithm is doing it, too). However, if a node which is part of the distribution infrastructure and knows, that there's just one recipient, just one next hop being a forwarding node, then the multicast data packet should be send as a unicast packet. The packet-type would be a new one (i.e. BAT_MCAST_UNI) and the orig-field needs to be set to the multicast address.
A forwarding node of a certain multicast group distribution infrastructure can detect if it is on a crotch without any additional communication need, it just has to memorise the following more entry: Of one multicast-group's mcast_pathsel stream(s) (the unicast packets maintaining an efficient distribution infrastructure), not only memorize the group and the previous senders mac address, but also the next hop destination mac address(es). If this forwarding node has multiple of these matching next hop destination addresses then it knows it is on a crotch.
-So if a forwarding node sitting on a crotch receives a multicast data packet via unicast, then it has to reencapsulate it in a broadcast header with multicast flag. If a forwarding node ''not'' sitting on a crotch receives a multicast data packet via broadcast, then it has to reecapsulate it in a mcast header with unicast destination. Otherwise it can forward the packet according to its table without having to reencapsulate it. +So if a forwarding node sitting on a crotch receives a multicast data packet via unicast, then it has to reencapsulate it in a broadcast header with multicast flag. If a forwarding node ''not'' sitting on a crotch receives a multicast data packet via broadcast, then it has to reecapsulate it in a unicast header. Otherwise it can forward the packet according to its table without having to reencapsulate it.
=== NAKs between neighbors === In wireless networks all unicast traffic is being acknowledged and in case of a loss resend until a certain amount of times. We usually don't have this feature for broadcasted packets, especially because of the mobile characteristics of the mesh it can be quite tough to tell on link layer if there was no ACK because of interference or because the neighbor got out of range. It is therefore a lot easier to use NAKs in this case - if a neigbor who is part of the distribution infrastructure detects a missing sequence number, it could request it again and receive it via unicast from the according neighbor. PGM ([http://tools.ietf.org/html/rfc3208 RFC3208])is also using the NAK approach on the transport layer for multicast packets for instance.