From patchwork Mon Dec 26 20:42:32 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Linus_L=C3=BCssing?= X-Patchwork-Id: 18534 Return-Path: X-Original-To: patchwork@open-mesh.org Delivered-To: patchwork@open-mesh.org Received: from diktynna.open-mesh.org (localhost [IPv6:::1]) by diktynna.open-mesh.org (Postfix) with ESMTP id F036D846E7; Mon, 26 Dec 2022 21:42:46 +0100 (CET) Received: from mail.aperture-lab.de (mail.aperture-lab.de [116.203.183.178]) by diktynna.open-mesh.org (Postfix) with ESMTPS id BB09080704 for ; Mon, 26 Dec 2022 21:42:44 +0100 (CET) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=open-mesh.org; s=20121; t=1672087365; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=7Z8ew6514MvxIXkJ16N5UEke5aoHL0bl952HIEf5jXU=; b=mQ0kkOjE7pbVtuJiph2jI6qjI4r0lKbCLYpCpvArxGJmtC/VbVCHE3sd5myhJdFu2dt0uw YStYTR2WTfE1kcjPwRBiEPb1qJBS9QLkNkyLDXpgT12+25FldLXzn+q2IOVO1aICox+whi wayZOYKbcIiKvPP8GB5n+I7fmw3NoA4= ARC-Authentication-Results: i=1; diktynna.open-mesh.org; dkim=none; dmarc=none; spf=none (diktynna.open-mesh.org: domain of linus.luessing@c0d3.blue has no SPF policy when checking 116.203.183.178) smtp.mailfrom=linus.luessing@c0d3.blue ARC-Seal: i=1; s=20121; d=open-mesh.org; t=1672087365; a=rsa-sha256; cv=none; b=AovAOpJEtkSBRtbpR1u52beg2R5vMeN3oCBQ8vVDk63fOLyXp6GAzaUL8FzzjPra6ehN4w xlS9mLAx2CrC3k43DYsFnky2eDv1pDKDXjDlLGBNaHWhWuqQesfMfEG66RLR3+TgHgyuw9 pmn7tlmxfRMBe+6tzc2ky1GvyeFFKfQ= Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id A052841C91 for ; Mon, 26 Dec 2022 21:42:43 +0100 (CET) From: =?utf-8?q?Linus_L=C3=BCssing?= To: b.a.t.m.a.n@lists.open-mesh.org Subject: [PATCH v3 0/5] Implementation of a Stateless Multicast Packet Type Date: Mon, 26 Dec 2022 21:42:32 +0100 Message-Id: <20221226204237.10403-1-linus.luessing@c0d3.blue> MIME-Version: 1.0 X-Last-TLS-Session-Version: TLSv1.3 Message-ID-Hash: OW5T6RBGEW6X6W3TLVV7JWSTYUPJ5KJA X-Message-ID-Hash: OW5T6RBGEW6X6W3TLVV7JWSTYUPJ5KJA X-MailFrom: linus.luessing@c0d3.blue X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-b.a.t.m.a.n.lists.open-mesh.org-0; header-match-b.a.t.m.a.n.lists.open-mesh.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.1 Precedence: list Reply-To: The list for a Better Approach To Mobile Ad-hoc Networking List-Id: The list for a Better Approach To Mobile Ad-hoc Networking Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Hi, The following patchset implements a stateless, TVLV capable batman-adv multicast packet type. The new batman-adv multicast packet type allows to contain several originator destination MAC addresses within a TVLV. Routers on the way will potentially split the batman-adv multicast packet and adjust its tracker TVLV contents. Routing decisions are still based on the selected BATMAN IV or BATMAN V routing algorithm. So this new batman-adv multicast packet type retains the same loop-free properties. The purpose of this new packet type is to allow to forward an IP multicast packet with less transmissions / overhead than the multicast-via-multiple-unicasts approach. Or to reach a lot more destinations (currently up to 196, depending on the payload size, see Wiki documentation for details) than with the default multicast fanout for the via-unicasts approach. This will allow using applications like mDNS again in several Freifunk communities. And with less transmissions will also make more bulky multicast applications, like media streaming (to an assessable amount of receivers) a lot more feasible. This approach is way simpler than the original multicast (tracker) packet approach we envisioned years ago. As it involves no maintenance of an extra, state based multicast routing table. However the TVLV capability should allow to extend things later, to split control and data plane a bit more for instance, to further increase the number of destinations, to further reduce overhead. A compact overview can be found in the Wiki here, including limitations: https://www.open-mesh.org/projects/batman-adv/wiki/Multicast-Packet-Type Regards, Linus