Skip to content

Roadmap Multicast (batman‐adv)

Jump to bottom Edit New page
T-X edited this page Feb 21, 2024 · 11 revisions

Roadmap Multicast (batman-adv)

batman-adv multicast packet type DONE

The current listener limit in Gluon with batman-adv is 16 (with a few exceptions that are currently unlimited: https://github.com/freifunk-gluon/gluon/tree/master/package/gluon-ebtables-filter-multicast/luasrc/lib/gluon/ebtables).

To increase this limit and for more efficient multicast forwarding, the following patchset to batman-adv was submitted and is currently waiting to be merged:

https://patchwork.open-mesh.org/project/b.a.t.m.a.n./cover/20230907010910.22427-1-linus.luessing@c0d3.blue/

After it was merged and Gluon's batman-adv version updated accordingly then the new limits should apply automatically, with no changes needed to Gluon.

MLD proxy for routable multicast (WIP)

Status:

Currently MLD is filtered to and from the mesh. And batman-adv's translation table acts as a (hopefully) more efficient "one-way" proxy for it already.

Unfortunately, because it is one-way, any layer 3 multicast router will not be able to obtain the multicast IP address listeners via MLD. The proposed solution (for now, where routable multicast listeners are expected to be very sparse) is an MLD proxy which only forwards MLD information for routable multicast address listeners. A work-in-progress implementation (which needs more testing):

https://github.com/T-X/brmldproxy

And should be started like:

$ brmldproxy -6 -b br-client -p bat0 -e local-port -E ff05::2:1001 -E ff02::/ff0f:: -E ff00::/ff0e::

Then only if a node has client with a multicast listener for a routable multicast address group then should this generate MLD traffic into the mesh. And it should be able to use MLDv2 over the mesh to a layer 3 multicast router, so with one compact MLDv2 report in a single packet which (in contrast to MLDv1 which uses one packet per group) contains all routable multicast groups from all clients on this node. No redundant report packets. (MLDv2 should also work even if br-client is still set to use MLDv1 for now.)

MLD to Multicast Routers Only option for batman-adv (WIP)

Status:

tl;dr: Reduce MLD (proxy) overhead by adding an option to batman-adv to forward MLD to multicast routers only, instead of flooding MLD.

Currently, batman-adv always floods MLD messages to all nodes. And it is Gluon which prevents this via ebtables. With the addition of the MLD proxy described above, it would be great if batman-adv could send the proxied MLD reports to multicast routers only. Likely a tristate option "MLD handling" with values of "Hub" (current behaviour, default), "RFC4541" (tree like behaviour) and "Multicast Routers only".

The "Multicast Router only" option would only be safe in the Gluon context (unless batman-adv would then also automatically generate and transmit MRD Advertisements).

Background to RFC4541's recommended behaviour:

RFC4541 ("Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches") mandates an alternative approach for snooping switches to work around potential packetloss due to MLD(v1) report suppression: Send MLD reports to ports with multicast routers (detected via IGMP/MLD queries or MRD) only. And forward multicast packets to ports with multicast listeners or with multicast routers. Pros: Works around the report suppression issue, likely less MLD overhead in a "classic" network as only send routers instead of flooding. Cons: Multicast routers receive all multicast traffic, even link-local multicast which they wouldn't need otherwise, central approach with bottleneck potential, if there is no multicast router which poor node should take the MLD querier role and receive all this multicast traffic? -> Not ideal for a decentral mesh network.

Note that batman-adv does not need to (and currently does not) adhere to this rule from RFC4541 and instead floods MLD. This works fine because inside the batman-adv mesh routing layer there are no multicast listeners. Instead they are on bat0 or behind a bridge over bat0. In the latter case the bridge will take care of adhering to RFC4541 for us.

IPv6 multicast routers between communities, via ICVPN + DN42 (ToDo)

To make multicast more useful, it would be great to increase the chance to get a critical mass for it. The more hosts collaborate, the more likely and greater the benefits of multicasting will be.

Once the MLD proxying described above is implemented, IPv6 multicast routers could greatly increase the range for multicast. With >40k Gluon nodes and >80k client devices - or even more if including hackerspaces via DN42 - it is more likely to accumulate a significant amount of multicast senders that provide interesting content and multicast listeners that are interested. Compared to being confined to a <500 nodes / 1k clients domain.

There currently exist two implementations for IPv6 multicast routers:

Multicast Application Enhancements

Basically the following with gstreamer works great!

Transmitter:

$ while true; do gst-launch-1.0 -v rtpbin name=rtp fec-encoders='fec,0="raptorqenc\ mtu=400\ repair-packets=15\ repair-window=500\ symbol-size=192";' pulsesrc ! audio/x-raw,channels=2 ! audioconvert ! audioresample ! opusenc ! queue ! rtpopuspay ! rtp.send_rtp_sink_0 rtp.send_rtp_src_0 ! udpsink host=ff15::2342:1337 port=5000 rtp.send_fec_src_0_0 ! udpsink host=ff15::2342:1337 port=5002 async=false; sleep 1; done

Receiver:

while true; do gst-launch-1.0 rtpbin latency=3000 fec-decoders='fec,0="raptorqdec";' name=rtp udpsrc address=ff15::2342:1337 port=5002 caps="application/x-rtp, payload=96, raptor-scheme-id=(string)6, repair-window=(string)500, t=(string)192" ! rtp.recv_fec_sink_0_0 udpsrc address=ff15::2342:1337 port=5000 caps="application/x-rtp, media=audio, clock-rate=48000, encoding-name=OPUS, payload=96" ! queue ! rtp.recv_rtp_sink_0 rtp. ! decodebin ! audioconvert ! queue ! autoaudiosink; sleep 1; done

Also VLC (Git master, not 3.0.x...) can receive the gstreamer stream fine like this:

$ cat /tmp/description.sdp
v=0
o=jdoe 2890844526 2890842807 IN IP6 2001:67c:2d50:0:be24:11ff:fe5e:d24f
s=FREIRAUMDISKO
i=A community managed Radio stream (via MPD), tracks from Jamendo.com
e=tux@c0d3.blue (T_X)
c=IN IP6 ff7e:240:2001:67c:2d50:0:545f:5800
t=0 0
a=recvonly
m=audio 5000 RTP/AVP 96
a=rtpmap:96 opus/48000/2
a=fmtp:96 stereo=1; sprop-stereo=1
$ ./vlc --version
...
VLC version 4.0.0-dev Otto Chriek (4.0.0-dev-27807-g678d0466d0d6)
...
$ ./vlc /tmp/description.sdp

TODOs:

  • add SAP (RFC2974) support to gstreamer
  • add RaptorQ support to VLC
  • document freifraumdisko and other streams/radio setups

Install Multicast Applications

Tools that work well with IPv6 multicast:

Videostreaming via:

(gstreamer with a custom pipeline that has more redundancy and uses the raptor code plugin might work better on potentially lossy WiFi)

Implement New Multicast Applications and Libraries (ToDo)

  • A smartphone radio app? Where anyone can with ease start their own radio channel?

    • Studio side:
      • Features a configurable playlist + volume setting, like any media player, maybe with extra fading options
      • Allows mic input
      • publish somehow/somewhere (moderated?)
    • Listener side:
      • has a browsable list of channels to tune into
      • or a private way to tune into, token via QR-code?
      • receives audio via multicast, in a robust way

  • Meshenger enhancements:

  • St~Dream Pi:

    • A Raspberry Pi distro configured to easily become either a radio and/or TV receiver or sender
    • similar to the "radio app" idea above, but more like a plug&play TV solution, decentral, based on multicast
    • A UI that is similar to / compatible to Kodi for the receiver side?

  • flow3r bed:

    • the flow3r badge with its ESP32 supports IPv6, including multicast and WiFi
    • stream inputs from one badge (or a desktop app) to multiple others
    • multiplayer apps without needing servers
    • allow a decentral, interactive, collaborative light and audio installation (or other apps or games; also some inspiration from: https://fabianschwarze.de/strombluete/)

  • Multiplayer RTS over Multicast:

    • add a serverless mode to 0 A.D., Warzone2100 or OpenRA
    • game state (changes) will be exchanged via multicast, with no central game host
    • if game state changes are invalid, all participants could vote on which participant was wrong and is going to be kicked
    • advantage: more robust, than with current approaches with one game host/server -> if the game host disconnects then all participants would need to restart
    • Warzone2100 might be a good candidate as it has a deterministic and quantified (100ms?) game state engine (all randomness comes from an initial seed)
  • Add your ideas above ^

Proxy Meshtastic/TTN(LoRa) and Bluetooth Mesh into batman-adv mesh

To be able to receive any text messages or sensor data from LoRaWAN or a Bluetooth Mesh as an IPv6 client on the Gluon mesh.

A Bluetooth mesh for instance has the concept of groups, which are text strings. Which could be mapped to individual IPv6 multicast addresses. And messages in a Bluetooth mesh are flooded to all nodes anyway, so a proxying Bluetooth->WiFi mesh node would not create more overhead for the Bluetooth side.

(Also the other way, from Gluon -> LoRaWAN/Bluetooth Mesh? More tricky: How to avoid loops or to find best medium/path? Potential bandwidth issues for that direction? At least Bluetooth Mesh always floods any message, no path discovery to interested receivers. And Meshtastic, which meshes over LoRa, also floods.)

Improve ARP handling

There are still quite some broadcasted ARP Requests, especially from the gateways. Verify that the following patchset for the batman-adv Distributed ARP Table helps: https://patchwork.open-mesh.org/project/b.a.t.m.a.n./cover/20190407112320.32021-1-linus.luessing@c0d3.blue/

Disclaimer: Please note that this wiki can be edited by anyone. Please be careful when using it.

Clone this wiki locally