commits

commits@lists.open-mesh.org

1 participants
12404 discussions

[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Multicast-optimizations-report-suppresion (4453063)
by postmaster＠open-mesh.org 17 Sep '19

17 Sep '19

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2019-09-17,master >--------------------------------------------------------------- commit 4453063bce6ee2019e8a1a9604c7b3600eacd707 Author: Sven Eckelmann <sven(a)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.

1 0

[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Multicast-optimizations-flags (d7d14d5)
by postmaster＠open-mesh.org 17 Sep '19

17 Sep '19

1 0

[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Multicast-optimizations-listener-reports (f2fdeb2)
by postmaster＠open-mesh.org 17 Sep '19

17 Sep '19

1 0

[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Multicast-ideas (5d689b8)
by postmaster＠open-mesh.org 17 Sep '19

17 Sep '19

1 0

[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Multicast-optimizations-bridges (8a693fb)
by postmaster＠open-mesh.org 17 Sep '19

17 Sep '19

1 0

[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Multicast-ideas-updated (c873f1b)
by postmaster＠open-mesh.org 17 Sep '19

17 Sep '19

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2019-09-17,master >--------------------------------------------------------------- commit c873f1b8046992f0ab500963247e26d1c223aabf Author: Sven Eckelmann <sven(a)narfation.org> Date: Tue Sep 17 10:24:48 2019 +0000 doc: batman-adv/Multicast-ideas-updated >--------------------------------------------------------------- c873f1b8046992f0ab500963247e26d1c223aabf batman-adv/Multicast-ideas-updated.textile | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/batman-adv/Multicast-ideas-updated.textile b/batman-adv/Multicast-ideas-updated.textile index ae536f1..26fad8e 100644 --- a/batman-adv/Multicast-ideas-updated.textile +++ b/batman-adv/Multicast-ideas-updated.textile @@ -463,12 +463,12 @@ Update (2012-12-xx): Current status / Todo: - * there is a working, "feature complete", but not much tested "patchset based on v2013.0.0":https://git.open-mesh.org/batman-adv.git/shortlog/refs/heads/linus/multicast-rebase which should work for any IP multicast data (no more code changes other than bug, comment or commit message fixes intended) - * More issues with the Linux bridge got fixed upstream (recent kernel recommended) - * Multicast video streaming still does not work reliably due to packet loss (anyone knowing a robust video codec? or the old FEC ideas could help) - * What about compatibility? Should we break it? Or should we wait for TLV support? How should multicast-optimizating nodes interact with others (should they drop it? should we monitor MLD/IGMP messages coming from the mesh to find multicast listeners behind non-multicast-optimizing batman nodes?) Or should it be part of BATMAN V instead of being a stand-alone (optional?) feature? UPDATE: There is a suggestion at the bottom now. - * Does the proactive, redundant attching of MLA information to an OGM hinder the development of BATMAN V (bc. the idea of BATMAN V was to allow drastically increasing the proactive, periodic OGM interval to increase scalability - what impact would a very high OGM interval have on the usability of this multicast optimization feature? - * What about the Bridge Loop Avoidance? If a batman-adv client sending multicast data is attached to two or more batman-adv nodes, will they all, redundantly send the multicast data to any multicast listener resulting in duplicate multicast data packets on the upper mesh layer? (though it at least shouldn't cause any loops, I think) +* there is a working, "feature complete", but not much tested "patchset based on v2013.0.0":https://git.open-mesh.org/batman-adv.git/shortlog/refs/heads/linus/multicast-rebase which should work for any IP multicast data (no more code changes other than bug, comment or commit message fixes intended) +** More issues with the Linux bridge got fixed upstream (recent kernel recommended) +** Multicast video streaming still does not work reliably due to packet loss (anyone knowing a robust video codec? or the old FEC ideas could help) +** What about compatibility? Should we break it? Or should we wait for TLV support? How should multicast-optimizating nodes interact with others (should they drop it? should we monitor MLD/IGMP messages coming from the mesh to find multicast listeners behind non-multicast-optimizing batman nodes?) Or should it be part of BATMAN V instead of being a stand-alone (optional?) feature? UPDATE: There is a suggestion at the bottom now. +** Does the proactive, redundant attching of MLA information to an OGM hinder the development of BATMAN V (bc. the idea of BATMAN V was to allow drastically increasing the proactive, periodic OGM interval to increase scalability - what impact would a very high OGM interval have on the usability of this multicast optimization feature? +** What about the Bridge Loop Avoidance? If a batman-adv client sending multicast data is attached to two or more batman-adv nodes, will they all, redundantly send the multicast data to any multicast listener resulting in duplicate multicast data packets on the upper mesh layer? (though it at least shouldn't cause any loops, I think) * Multicast Router Discovery (RFC4286): For multicast traffic with a link-local address scope MLD snooping should be sufficient. However, for potentially routed multicast traffic we need to send any multicast traffic to any multicast router, too. For that we need to snoop for multicast router announcements, too and should perform the multicast router solicitation part. The same needs to be implemented for the Linux bridge code * The Linux bridge lacks proper querier protocol support. Meaning if there is a multicast router with a proper querier protocol implementation on the linux, administrators would need to manually disable the rudimentary querier implemantion on all bridges. If there is no multicast router, then the querier should be enabled on at least one bridge. See: https://lkml.kernel.org/r/loom.20130403T154347-81@post.gmane.org * If the bridge snooping works reliably then, then the application of snooping for IPv6 transient addresses only should probably be removed. Instead only ff00::/15, ff01::/15 and ff02::1/128 should be excluded.

1 0

[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Multi-link-optimizations-technical (dff6d54)
by postmaster＠open-mesh.org 17 Sep '19

17 Sep '19

1 0

[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Kmalloc-kmem-cache-tests (b94bda9)
by postmaster＠open-mesh.org 17 Sep '19

17 Sep '19

1 0

[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Faq (1a53391)
by postmaster＠open-mesh.org 17 Sep '19

17 Sep '19

1 0

[doc] backup-redmine/2019-09-17, master: doc: batman-adv/Broadcast-Avoidances (ce3c07d)
by postmaster＠open-mesh.org 17 Sep '19

17 Sep '19

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits