Repository : ssh://git@diktynna/doc
On branches: backup-redmine/2023-01-14,main
commit 536eaa0c5147e3a4ed7bfac5cf6deb6b6d4bb7cf Author: Linus L��ssing linus.luessing@c0d3.blue Date: Mon Dec 26 15:06:13 2022 +0000
doc: batman-adv/Multicast-Packet-Type
536eaa0c5147e3a4ed7bfac5cf6deb6b6d4bb7cf batman-adv/Multicast-Packet-Type.textile | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/batman-adv/Multicast-Packet-Type.textile b/batman-adv/Multicast-Packet-Type.textile index d48136c7..10dbd5f5 100644 --- a/batman-adv/Multicast-Packet-Type.textile +++ b/batman-adv/Multicast-Packet-Type.textile @@ -138,12 +138,16 @@ h3. -Fragmentation / MTUs:-
-> Workaround C): We require a 1280 bytes MTU on all hard interfaces and only then set the multicast packet type capability flag.
-h3. Adding a sequence number? / How to avoid loops with tracker marking later? +h3. -Adding a sequence number? / How to avoid loops with tracker marking later?-
-When later implementing a split control <-> data plane as originally envisioned, by allowing to send a multicast packet with only the tracker TVLV, without data. And caching this information to fill a multicast routing table. And then allowing to send a multicast packet without the tracker TVLV afterwards, there is the following issue: +-When later implementing a split control <-> data plane as originally envisioned, by allowing to send a multicast packet with only the tracker TVLV, without data. And caching this information to fill a multicast routing table. And then allowing to send a multicast packet without the tracker TVLV afterwards, there is the following issue:-
-When first a path is marked through the tracker TVLV, then paths change due to OGM updates. And then a tracker packet marks such new paths then the merger of both the old and newly tracker marked paths could create routing loops, as the old path is not automatically invalidated. +-When first a path is marked through the tracker TVLV, then paths change due to OGM updates. And then a tracker packet marks such new paths then the merger of both the old and newly tracker marked paths could create routing loops, as the old path is not automatically invalidated.-
-Solution: +-Solution:-
-Don't mark paths. Instead use the tracker TVLV to fill a cache with the mcast/dests lists and assign a hash to this information. Then later send the multicast data with a TVLV containing only this hash instead of the full mcast/dests list. Therefore a specific list of destinations is still maintained and routing decisions still happen on the go, loopfree, instead of trying to a maintain a loopfree, adjacent multicast routing table. \ No newline at end of file +-Don't mark paths. Instead use the tracker TVLV to fill a cache with the mcast/dests lists and assign a hash to this information. Then later send the multicast data with a TVLV containing only this hash instead of the full mcast/dests list. Therefore a specific list of destinations is still maintained and routing decisions still happen on the go, loopfree, instead of trying to a maintain a loopfree, adjacent multicast routing table.- + +--- + +-> Don't add a sequence number, we don't need it now. And a new hashing/caching TVLV described above should work fine later. \ No newline at end of file