commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Release-todo (8966a5d4)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 8966a5d42a6100d708f5bb8df3d34db51ec8b02f Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Fri Jun 18 23:29:48 2010 +0000 doc: batman-adv/Release-todo >--------------------------------------------------------------- 8966a5d42a6100d708f5bb8df3d34db51ec8b02f batman-adv/Release-todo.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Release-todo.textile b/batman-adv/Release-todo.textile index 56ceab38..3611a077 100644 --- a/batman-adv/Release-todo.textile +++ b/batman-adv/Release-todo.textile @@ -23,7 +23,7 @@ This page contains a checklist of things that need to be done for a release. '''Release''' - * [ ] build package tar.gz (replace symlinks with real files) and generate checksums + * [x] build package tar.gz (replace symlinks with real files) and generate checksums * [ ] ~~build stable binary packages~~ * [ ] move packages/checksums to stable/sources / create symlinks from releases * [ ] update download links in the trac downloads page

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multicast-ideas: very drafty, scrawly initial multicast design page (7d46956d)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 7d46956d50d463384d5ca1a12dcce9cf499132c7 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Sat Jun 19 04:27:02 2010 +0000 doc: batman-adv/Multicast-ideas: very drafty, scrawly initial multicast design page >--------------------------------------------------------------- 7d46956d50d463384d5ca1a12dcce9cf499132c7 batman-adv/Multicast-ideas.textile | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/batman-adv/Multicast-ideas.textile b/batman-adv/Multicast-ideas.textile new file mode 100644 index 00000000..e2e439ca --- /dev/null +++ b/batman-adv/Multicast-ideas.textile @@ -0,0 +1,37 @@ += BATMAN-Adv Multicast Awareness = + +== Idea == +The intention is to decrease the broadcast domain for multicast packets, especially large multicast data packets should not be broadcasted through the whole mesh. + +== Concepts and classifications == +=== Reactive, multicast group specific, sender-based distribution infrastructure initiation === +Similar to batman-adv's current HNA sensing mechanisms, batman-adv would look for multicast packets going into its bat0 interface and memorize the according multicast MAC addresses which represent one multicast group id each in IPv6 or a small set of multicast group ids in IPv4. On sensing, the according batman-adv node will add MCA (= multicast sender announcements) entries to each OGM. + +=== Proactive, periodic distribution infrastructure maintenance === +A batman-adv node receiving an OGM with MCA entries will check its local multicast group table. If it is a member of the same multicast group fetched from the received OGM's MCAs, it will start a periodic unicast stream to the other member(s) of the same multicast group (packet type description, see mcast_pathsel_packet). This technique for maintenance is similar to the one used in ODMRP. The default interval would/should be 500ms for them, the purge timeout about 3 to 5 times higher - the higher the purge timeout, the more robust the infrastrucutre in a very mobile environment would be, but the larger the distribution infrastructure / broadcast domain would become. + +=== multicast data packet delivery === +In the beginning when an optimised distribution infrastructure has just started to build up, multicast data packets should still be broadcasted. The advantage of this would be, that no buffering or packet dropping would have to be done. After for about 5 seconds (then all nodes with a reasonable ogm receiving quality should have gotten the MCA), multicast data packets would still be encapsulated in a batman bcast_packet, but with the packet type set to BAT_MCAST. Another node will receiving this on-link broadcasted packet, will check if it got a mcast_pathsel_packet before which did not time out yet. The receiver will have to compare the mcast destination mac address and the ethernet frame source mac of the encapsulated multicast data packet with the mcast_pathsel src field and its ethernet frame source field. The latter is important to make the marked path unidirectional and the whole algorithm aware of asymmetric links. + +== New batman-adv packet types == +=== BAT_MCAST === +A multicast data packet that shall use an optimized path will still use a batman bcast_packet header, but set packet_type to BAT_MCAST. + +=== mcast_pathsel_packet === + +== Pros/Cons == + + +== Smaller/Easier optimizations == +=== Distribution infrastructure initiation - bursting === +=== still broadcast smaller, but important multicast packets === +=== broadcasting in dense multicast networks === +=== multicast sender announcement threshold === +=== multicast group id differentiation for IPv4 === +=== converting BAT_MCAST to unicast if just one member on path left === + +Resources: +* ADAMA +* ODMRP +* SMA +* ... \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multicast-ideas (e40d615f)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit e40d615f3a9edf4879e3b32b3a1d28cebc905a4b Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Sat Jun 19 04:29:53 2010 +0000 doc: batman-adv/Multicast-ideas >--------------------------------------------------------------- e40d615f3a9edf4879e3b32b3a1d28cebc905a4b batman-adv/Multicast-ideas.textile | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/batman-adv/Multicast-ideas.textile b/batman-adv/Multicast-ideas.textile index e2e439ca..e8da207a 100644 --- a/batman-adv/Multicast-ideas.textile +++ b/batman-adv/Multicast-ideas.textile @@ -18,7 +18,17 @@ In the beginning when an optimised distribution infrastructure has just started A multicast data packet that shall use an optimized path will still use a batman bcast_packet header, but set packet_type to BAT_MCAST. === mcast_pathsel_packet === - +{{{ +/* marks the path for multicast streams */ +struct mcast_pathsel_packet { + uint8_t packet_type; /* BAT_MCAST_PSEL */ + uint8_t version; /* batman version field */ + uint8_t src[6]; /* multicast mac address */ + uint8_t dest[6]; + uint8_t ttl; + uint8_t align; +} __attribute__((packed)); +}}} == Pros/Cons == @@ -31,7 +41,7 @@ A multicast data packet that shall use an optimized path will still use a batman === converting BAT_MCAST to unicast if just one member on path left === Resources: -* ADAMA -* ODMRP -* SMA -* ... \ No newline at end of file + * ADAMA + * ODMRP + * SMA + * ... \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: attachments/bonding_roundrobin.dia.jpg (64175050)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 64175050d35599bed491b146f344d73ad289d9d5 Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Fri Jun 4 17:04:03 2010 +0000 doc: attachments/bonding_roundrobin.dia.jpg >--------------------------------------------------------------- 64175050d35599bed491b146f344d73ad289d9d5 attachments/bonding_roundrobin.dia.jpg | Bin 0 -> 16058 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/attachments/bonding_roundrobin.dia.jpg b/attachments/bonding_roundrobin.dia.jpg new file mode 100644 index 00000000..d58aa4e1 Binary files /dev/null and b/attachments/bonding_roundrobin.dia.jpg differ

1 0

[doc] backup-redmine/2017-07-13, master: doc: attachments/alternation_chain.dia.jpg (e2a1665a)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit e2a1665af76e4f82d66ce10d4aa4d8051dd424dc Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Fri Jun 4 17:03:51 2010 +0000 doc: attachments/alternation_chain.dia.jpg >--------------------------------------------------------------- e2a1665af76e4f82d66ce10d4aa4d8051dd424dc attachments/alternation_chain.dia.jpg | Bin 0 -> 20069 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/attachments/alternation_chain.dia.jpg b/attachments/alternation_chain.dia.jpg new file mode 100644 index 00000000..64d12896 Binary files /dev/null and b/attachments/alternation_chain.dia.jpg differ

1 0

[doc] backup-redmine/2017-07-13, master: doc: attachments/interface_detection.dia.jpg (1ff5efc1)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 1ff5efc1d3477711d430796a566d86d074cbc0bd Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Fri Jun 4 17:04:17 2010 +0000 doc: attachments/interface_detection.dia.jpg >--------------------------------------------------------------- 1ff5efc1d3477711d430796a566d86d074cbc0bd attachments/interface_detection.dia.jpg | Bin 0 -> 22506 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/attachments/interface_detection.dia.jpg b/attachments/interface_detection.dia.jpg new file mode 100644 index 00000000..015df6e1 Binary files /dev/null and b/attachments/interface_detection.dia.jpg differ

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multi-link-optimizations-technical (344a3ade)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multi-link-optimizations-technical (3f43a28a)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/News-archive (794e1a17)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multi-link-optimizations-technical (4a0a8ad7)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 4a0a8ad7c958749f17aaca02d18141dd8354be15 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Fri Jun 4 21:49:31 2010 +0000 doc: batman-adv/Multi-link-optimizations-technical >--------------------------------------------------------------- 4a0a8ad7c958749f17aaca02d18141dd8354be15 .../Multi-link-optimizations-technical.textile | 23 +++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/batman-adv/Multi-link-optimizations-technical.textile b/batman-adv/Multi-link-optimizations-technical.textile index 0913cb75..953a4fb4 100644 --- a/batman-adv/Multi-link-optimizations-technical.textile +++ b/batman-adv/Multi-link-optimizations-technical.textile @@ -1,8 +1,11 @@ = Bonding and interface alternating = +{{{ +#!div style="width: 46em; text-align: justify" + On mesh nodes with multiple wifi radios (or even other interfaces) participating in the mesh network, we can use these multiple interfaces to gain more bandwidth or more stability in the links. The standard BATMAN algorithm considers all neighbors equally, and does not distinguish whether neighbors belong to the same physical nodes or not. The bonding and interface alternating mechanisms detect that some neighbors belong to the same physical node and use this information. -== multiple interface detection == +== Multiple interface detection == The first step is to detect that a peer has multiple interfaces, and we have multiple connections to it. @@ -10,26 +13,28 @@ The first step is to detect that a peer has multiple interfaces, and we have mul As seen in the illustration, we have a node A with 2 interfaces A1,A2. Both of its interfaces can reach different neighbors. By evaluating OGM packets from B with a new "PRIMARIES FIRST HOP" flag (which is only set in the first hop, obviously), we recognize that B2 is belonging to the same node B1. OGMs from the primary interface (B1) are sent on all available interfaces (B1 and B2), and we can therefore detect that the B2 is a secondary interface and B1 is the primary interface of the node it belongs to. -With this information, we know that we can send packets via each links (A1->B1 or A2->B2) without disturbing or changing the routing algorithm - we send from and to the same nodes after all. We call these possible links "candidates" internally. Links are only considered as candidates if the TQ (transmit quality) are nearly equally good as the best link. +With this information, we know that we can send packets via each links (A1->B1 or A2->B2) without disturbing or changing the routing algorithm - we send from and to the same nodes after all. Since we are going to use both links at the same time and not only the best, we need to make sure that both have a similar quality. Otherwise the performance might be worse instead of improving the situation. -== interface alternating == +== Interface alternating == -One application for our multiple detection is interface alternating. The idea is to avoid forwarding packets on the same interface as they were received. +One application for our multiple detection is "interface alternating": The algorithm tries to avoid forwarding packets on the interface which just received the packet. That way the typical store & forward mechanism of wifi which halfs the bandwidth with each hop can be worked around. [[Image(wiki:bonding-alternating:alternation_chain.dia.jpg)]] -In the illustration, we can see 4 nodes with 2 interfaces each. A stream is sent from node A to node D. There are 2 candidates for each node to reach the next hop, but only one is used - if possible, not the one where we received the packets. +In the illustration, we can see 4 nodes with 2 interfaces each. A stream is sent from node A to node D. There are 2 candidates for each node to reach the next hop, but only one is used - if possible, not the one which received the packets in the first place. -If one packet comes in, we have two links available for the next hop. We can now search through the list of candidates and can choose a candidate which is not using the receiving interface. +If a packet comes in, we have two links available for the next hop. We can now search through the list of candidates and can choose a candidate which is not going over the receiving interface. -This mechanism should avoid interferences and too much packet in one wifi channel, and thus should avoid problems with the half-duplex nature of WiFi hardware. As we currently don't see any scenarios where the interface alternating could cause disadvantages, we set it to default in the upcoming batman-adv 0.3.0 release. +This mechanism should avoid interferences and congestion of a wifi channel, and thus should avoid problems with the half-duplex nature of WiFi hardware. As we currently don't see any scenarios where the interface alternating could cause disadvantages, we set it to default in the upcoming batman-adv 0.3.0 release. -== bonding == +== Bonding == -In bonding, we split a single stream and distribute the packets over multiple links. Packets are sent in a round-robin fashion over the available candidates. This can be used to increase the throughput for data streams from node A to node B. In best case the throughput is n times higher, where n is the number of candidates. +In bonding, we split a single stream and distribute the packets over multiple links. Packets are sent in a round-robin fashion over the available candidates. This can be used to increase the throughput for data streams from node A to node B. In a perfect environemt the throughput is n times higher, where n is the number of candidates. [[Image(wiki:bonding-alternating:bonding_roundrobin.dia.jpg)]] However, with the round-robin way of sending packets, the actual throughput is limited by the link with the worst bandwidth. Also the errors and instabilities of all links are aggregated, which makes the link more fragile. For this reason, the bonding feature can be enabled optionally, and should be enabled in setups with high quality links. There are already ideas how to improve the situation with links of differend bandwidth, e.g. sending packets packets on interfaces where the queue has the least packets. Comments and patches [MailingList are appreciated]. + +}}} \ No newline at end of file

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017