Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2019-09-17,master
commit 4453063bce6ee2019e8a1a9604c7b3600eacd707 Author: Sven Eckelmann sven@narfation.org Date: Tue Sep 17 10:26:50 2019 +0000
doc: batman-adv/Multicast-optimizations-report-suppresion
4453063bce6ee2019e8a1a9604c7b3600eacd707 ...lticast-optimizations-report-suppresion.textile | 48 +++++++++++----------- 1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/batman-adv/Multicast-optimizations-report-suppresion.textile b/batman-adv/Multicast-optimizations-report-suppresion.textile index 1779fab..45a70f0 100644 --- a/batman-adv/Multicast-optimizations-report-suppresion.textile +++ b/batman-adv/Multicast-optimizations-report-suppresion.textile @@ -2,13 +2,13 @@ h1. Multicast Optimizations – IGMP/MLD Report Suppresion
Prior Readings:
- * [[multicast-optimizations|Multicast Optimizations]] - * [[multicast-optimizations-tech|Multicast Optimizations – Technical Description]] - * [[multicast-optimizations-flags|Multicast Optimizations – Flags Explained]] +* [[multicast-optimizations|Multicast Optimizations]] +* [[multicast-optimizations-tech|Multicast Optimizations – Technical Description]] +* [[multicast-optimizations-flags|Multicast Optimizations – Flags Explained]]
h2. Scenario
-!{width: 90%25;}basic-multicast-snoopables-shadowing-querier.png! +!{width: 90%;}basic-multicast-snoopables-shadowing-querier.png!
_A Querier behind a bridge potentially shadowing a multicast listener_
@@ -18,13 +18,13 @@ h2. Cause: Report Suppression
The reason for this is a mechanism called "Report Suppression", defined by standards of MLD and IGMP in their old version (MLDv1, IGMPv1, IGMPv2):
-!{width: 80%25;}basic-multicast-switch.png! +!{width: 80%;}basic-multicast-switch.png!
- * IGMPv2: "RFC2236":https://tools.ietf.org/html/rfc2236, section 3: +* IGMPv2: "RFC2236":https://tools.ietf.org/html/rfc2236, section 3:
[...] If the host receives another host's Report (version 1 or 2) while it has a timer running, it stops its timer for the specified group and does not send a Report, in order to suppress duplicate Reports. [...]
- * MLDv1: "RFC2710":https://tools.ietf.org/html/rfc2710, section 4: +* MLDv1: "RFC2710":https://tools.ietf.org/html/rfc2710, section 4:
If a node receives another node's Report from an interface for a multicast address while it has a timer running for that same address on that interface, it stops its timer and does not send a Report for that address, thus suppressing duplicate reports on the link.
@@ -32,13 +32,13 @@ This on its own, not getting to know all listeners behind a bridge port, is not
However, if snooping switches were simply flooding such listener reports, then they themselves would not be able to notice all listeners anymore:
-!{width: 80%25;}basic-multicast-switch-uncertain.png! +!{width: 80%;}basic-multicast-switch-uncertain.png!
Therefore another RFC mandates an additional report suppression for snooping switches:
-!{width: 80%25;}basic-multicast-snooping-switch.png! +!{width: 80%;}basic-multicast-snooping-switch.png!
- * "RFC4541":https://tools.ietf.org/html/rfc4541, section 2.1.1.1) +* "RFC4541":https://tools.ietf.org/html/rfc4541, section 2.1.1.1)
A snooping switch should forward IGMP Membership Reports only to those ports where multicast routers are attached. [...]
@@ -46,34 +46,34 @@ Which in turn can potentially lead to a batman-adv node not receiving any MLD/IG
h2. Report Suppression in a Mesh
-!{width: 60%25;}basic-multicast-querier-scenario.png! +!{width: 60%;}basic-multicast-querier-scenario.png!
- * _*Querier:*_ An IGMP or MLD querier (i.e. a multicast router requesting IGMP/MLD Reports) - * _*Snooping Switch:*_ A multicast aware layer 2 switch - * _*Listener:*_ An IPv4 or IPv6 multicast listener (using IGMPv1, IGMPv2 or MLDv1) - * _*Bridge:*_ A Linux kernel bridge on top of a bat0 device of a batman-adv node - * _*Mesh:*_ A mesh network consisting of batman-adv nodes - * _*Sender:*_ An IPv4 or IPv6 multicast sender +* _*Querier:*_ An IGMP or MLD querier (i.e. a multicast router requesting IGMP/MLD Reports) +* _*Snooping Switch:*_ A multicast aware layer 2 switch +* _*Listener:*_ An IPv4 or IPv6 multicast listener (using IGMPv1, IGMPv2 or MLDv1) +* _*Bridge:*_ A Linux kernel bridge on top of a bat0 device of a batman-adv node +* _*Mesh:*_ A mesh network consisting of batman-adv nodes +* _*Sender:*_ An IPv4 or IPv6 multicast sender
# In the beginning the selected querier sends its query message to all hosts and therefore through the whole mesh, asking any multicast listener to reval themselves: -!{width: 66%25;}basic-multicast-querier-scenario-query.png! +!{width: 66%;}basic-multicast-querier-scenario-query.png! # The listener behind the snooping switch will respond, but as previously described, the snooping switch will only forward this report to the querier: -!{width: 80%25;}basic-multicast-querier-scenario-report.png! +!{width: 80%;}basic-multicast-querier-scenario-report.png! # The batman-adv node will not receive the report on its according bridge and therefore is not able to detect the listener. Any other node in the mesh, including the multicast sender is not able to sense this listener either: -!{width: 60%25;}basic-multicast-querier-no-listener.png! +!{width: 60%;}basic-multicast-querier-no-listener.png!
h2. The Solution
Therefore batman-adv has to not only forward multicast packets to the according listeners, but also IGMP/MLD Queriers (regardless of their version) behind bridges – even if the multicast packets actually have a link-local scope and therefore will never be routed on layer 3.
# A batman-adv node noticing an IGMP/MLD Querier _behind_ its bridge (i.e. by snooping the query message shown above) signalizes this by setting the BATADV_MCAST_WANT_ALL_IPV4/BATADV_MCAST_WANT_ALL_IPV6 multicast TVLV flag accordingly: -!{width: 60%25;}basic-multicast-querier-want.png! +!{width: 60%;}basic-multicast-querier-want.png! # The multicast sender is now able to have its multicast packet forwarded to the batman-adv node with this flag set even though it did not notice any according multicast listener: -!{width: 60%25;}basic-multicast-querier-want-#1.png! +!{width: 60%;}basic-multicast-querier-want-#1.png! # The receiving batman-adv node will decapsulate and forward the multicast frame to its Linux bridge. The Linux bridge, which has snooping support too, will forward the frame even though it did not sense the listener either. Similar to batman-adv only having sensed the querier, the Linux bridge will forward towards the sensed, selected querier as well: -!{width: 75%25;}basic-multicast-querier-want-#2.png! +!{width: 75%;}basic-multicast-querier-want-#2.png! # The snooping switch on the other hand was able to detect the querier and the listener and will therefore forward the frame to both: -!{width: 80%25;}basic-multicast-querier-want-#3.png! +!{width: 80%;}basic-multicast-querier-want-#3.png!
Since the active, selected Querier is the root of a tree for all IGMPv1/IGMPv2/MLDv1 Listener Reports, the solution described above will ensure despite suppression mechanisms that all multicast listeners will receive the multicast packets they signed up for.