commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multi-link-optimize-old (e86699e6)
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 e86699e6f9d95d780c046bcab3b0ca277f4c368d Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Wed Mar 7 08:26:01 2012 +0000 doc: batman-adv/Multi-link-optimize-old >--------------------------------------------------------------- e86699e6f9d95d780c046bcab3b0ca277f4c368d batman-adv/Multi-link-optimize-old.textile | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/batman-adv/Multi-link-optimize-old.textile b/batman-adv/Multi-link-optimize-old.textile index 2a06a3f7..72e66c25 100644 --- a/batman-adv/Multi-link-optimize-old.textile +++ b/batman-adv/Multi-link-optimize-old.textile @@ -1,6 +1,6 @@ h1. Multi-link Optimization -batman-adv is able to work on different interfaces - multiple WiFi interfaces, but also Ethernet interfaces. If two nodes are interconnected through batman-adv on multiple interfaces, they may leverage some features to increase throughput, which are explained here. +batman-adv is able to work on different interfaces - multiple WiFi interfaces, but also Ethernet interfaces. If two or more nodes are interconnected through batman-adv on multiple interfaces, they may leverage some features to increase throughput, which are explained here. For more technical information, please see [[Bonding-alternating]] @@ -25,3 +25,11 @@ To enable bonding, use batctl: <pre> batctl bonding enable </pre> + +h2. Throughput gains + +At the [[open-mesh:2010-06-13-wbm2010-bracciano|WirelessBattleMesh v3]] we performed throughput tests to measure the gain of the various modes: + +!bonding_2hops.png! + +This graph shows a 3 node setup each with 2 802.11abg wifi interfaces connected to the mesh network (1x 2.4GHz and 1x 5.8GHz). As you can see the alternating mode is able to maintain the performance. The old default behavior sometimes manages to maintain a similar level of performance but is rather unstable.

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Ap-isolation (98a518fe)
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 98a518fe6ca3aac8dae05f9bc689e99466aae12b Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Wed Mar 7 08:41:57 2012 +0000 doc: batman-adv/Ap-isolation >--------------------------------------------------------------- 98a518fe6ca3aac8dae05f9bc689e99466aae12b batman-adv/Ap-isolation.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/batman-adv/Ap-isolation.textile b/batman-adv/Ap-isolation.textile index 95759ea7..e47ee9ba 100644 --- a/batman-adv/Ap-isolation.textile +++ b/batman-adv/Ap-isolation.textile @@ -23,6 +23,6 @@ Note that packets are checked either at the sender or the receiver node, therefo Remember that B.A.T.M.A.N.-Advanced AP-Isolation will provide "inter-meshnode communications" prevention only. Therefore if you want to block communications between clients connected to the same access point (actually mesh node) you may want to enable the "class AP-Isolation" function provided by the access point itself. -h3. Technical details +h3. Caveats -to be added \ No newline at end of file +To isolate wireless clients from each other B.A.T.M.A.N.-Advanced checks the source and destination address of a packet traveling through the mesh. If sender and receiver are wireless clients the packet is discarded. It is in the very nature of broadcast and multicast packets to not have a single destination, therefore the packet could be destined for wireless clients as well as wired clients. B.A.T.M.A.N.-Advanced has no way to distinguish these cases. To not completely block needed broadcast traffic (ARP for instance) broadcast and multicast traffic is forwarded through the mesh even between wireless clients.

1 0

[doc] backup-redmine/2017-07-13, master: doc: attachments/bonding_2hops.png (b91b86f9)
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 b91b86f9b11c1e7abac6b8f9ac8d99a57f9f8854 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Wed Mar 7 08:27:16 2012 +0000 doc: attachments/bonding_2hops.png >--------------------------------------------------------------- b91b86f9b11c1e7abac6b8f9ac8d99a57f9f8854 attachments/bonding_2hops.png | Bin 0 -> 10462 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/attachments/bonding_2hops.png b/attachments/bonding_2hops.png new file mode 100644 index 00000000..6002d5f3 Binary files /dev/null and b/attachments/bonding_2hops.png differ

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/SubmittingLinux (827fd6f2)
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 827fd6f28cd1111e46565105b2cd386fbb51d73a Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Sat Mar 10 23:40:49 2012 +0000 doc: batman-adv/SubmittingLinux >--------------------------------------------------------------- 827fd6f28cd1111e46565105b2cd386fbb51d73a batman-adv/SubmittingLinux.textile | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/batman-adv/SubmittingLinux.textile b/batman-adv/SubmittingLinux.textile index b1104b30..ab235bfd 100644 --- a/batman-adv/SubmittingLinux.textile +++ b/batman-adv/SubmittingLinux.textile @@ -328,6 +328,10 @@ Applying: batman-adv: adapting source version to revised versioning scheme Applying: batman-adv: Add include guards to all header files '-(%25)-(batman-adv/next)> git diff merge/master -- net/batman-adv/ '-(%25)-(batman-adv/next)> git push +'-(%25)-(batman-adv/next)> git tag -d batman-adv-for-davem +'-(%25)-(batman-adv/next)> git push origin :batman-adv-for-davem +'-(%25)-(batman-adv/next)> git tag -s batman-adv-for-davem +'-(%25)-(batman-adv/next)> git push origin batman-adv-for-davem '-(%25)-(batman-adv/next)> git request-pull 12513b76a021e5b41a9d5d5981da75dfd6480890 git://git.open-mesh.org/linux-merge.git batman-adv-for-davem > shortlog '-(%25)-(batman-adv/next)> git send-email --compose --to=davem(a)davemloft.net --cc=netdev(a)vger.kernel.org --cc=b.a.t.m.a.n(a)lists.open-mesh.org 00*.patch </pre>

1 0

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

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/DistributedArpTable (03b21c49)
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 03b21c498211633641b38643a499ade7cab3df71 Author: Antonio Quartulli <a(a)unstable.cc> Date: Sat Mar 3 02:10:31 2012 +0000 doc: batman-adv/DistributedArpTable >--------------------------------------------------------------- 03b21c498211633641b38643a499ade7cab3df71 batman-adv/DistributedArpTable.textile | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/batman-adv/DistributedArpTable.textile b/batman-adv/DistributedArpTable.textile index 688b3a44..fd545e54 100644 --- a/batman-adv/DistributedArpTable.textile +++ b/batman-adv/DistributedArpTable.textile @@ -1,6 +1,6 @@ h1. Distributed ARP Table -D.A.T. (Distributed ARP Table) is a feature aimed to solve the unreliability problem of the ARP:http://en.wikipedia.org/wiki/Address_Resolution_Protocol dialogue +D.A.T. (Distributed ARP Table) is a feature aimed to solve the unreliability problem of the "ARP":http://en.wikipedia.org/wiki/Address_Resolution_Protocol dialogue in sparse wireless networks, where the experienced packet loss is not negligible. h2. The Problem @@ -21,13 +21,35 @@ the correct destination, thus dramatically increasing the latency of establishin h2. A possible solution The idea behind D.A.T. is to reduce as much as possible the usage of broadcast packets by replacing them with unicasts. In order to accomplish this task D.A.T. dat uses -part of the theory behind the DHT(Distributed Hash Tables):http://en.wikipedia.org/wiki/Distributed_hash_table, in particular it uses the DHT to store the ARP entries +part of the theory behind the "DHT (Distributed Hash Tables)":http://en.wikipedia.org/wiki/Distributed_hash_table, in particular it uses the DHT to store the ARP entries so becoming able to later query a particular node in order to get the data which the requester is looking for. h2. DHT basics -The DHT which D.A.T. is based on +The DHT which D.A.T. is based on is actually inspired by "CHORD":http://en.wikipedia.org/wiki/Chord_(peer-to-peer), which is one of the earliest Peer-to-Peer algorithm based on a DHT. B.A.T.M.A.N.-Advanced inherits the shape of the key space and the rule used to allocate objects onto participant nodes. + +Going a bit deeper into the details, the key space is represented by a ring on which the 2^16 keys are equally distributed. Being a ring means that once the key with value 2^32 has been riched, the next one is 0 again. + +As in CHORD, either the objects to distribute into the DHT and the participant nodes are mapped (by means of an hash function) to keys in the same space. Therefore, while scrolling the ring it is possible to find either keys mapping to an object and keys mapping to a node. This mechanism is definitely useful in order to decide which key is allocated on which node. In particular whenever there is a new object that we want to store in the DHT, the steps to follow are: +# compute the key of the object by means of the hash function +# locate the key on the ring +# identify the 3 nodes with the closest (from the left) key on the ring +# distribute the object content on these 3 nodes + +In this way, as soon as all the nodes shares the same vision of the ring, given a generic object, whatever node can identify the 3 participants that are storing the object content and query them. !dat_dht-90.png! +In the figure above, it is possible to see a DHT ring populated with some participants. At some point a generic node in the network wants to retrieve the content for the red object. The node computes the key of the latter and then identifies the 3 nodes that store the content (the green ones in the figure). Now the node looking for the object content can directly query the selected participants and retrieve the data. + h2. How DAT merges ARP and the DHT + +Once the DHT concept has been introduced into B.A.T.M.A.N.-Advanced, the next step is to merge the ARP protocol and make D.A.T. born. + +D.A.T. actually exploits the DHT mechanism to store ARP entries of the form *[IP, MAC]*. The IP is used as input for the hash function as it is the always known part of the entry. In particular, whenever a node detect an ARP entries in the network (because of an ARP request/reply being sent/received by one of its clients) it simply activate the preiously explained mechanisn and stores the ARP data into the DHT. + +Upon retrieving data, a node (due to an ARP request being sent by a client) directly uses the DHT to retrieve the ARP tuple, and only if the DHT cannot provide the wanted data (e.g. the first time the data is requested) then the node fallbacks to the classic broadcast mechanism. As it is possible to understand, using the DHT will make the nodes avoid to use broadcast packets as much as possible and will make them instead rely on the unicast packets directly sent to the node storing the data in the DHT. + +h2. Technical details + +TBD \ No newline at end of file

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Experience (d19943ee)
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 d19943ee276f9e3cb31626398f5858f2c2fc0344 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Sat Mar 3 19:15:19 2012 +0000 doc: open-mesh/Experience >--------------------------------------------------------------- d19943ee276f9e3cb31626398f5858f2c2fc0344 open-mesh/Experience.textile | 1 + 1 file changed, 1 insertion(+) diff --git a/open-mesh/Experience.textile b/open-mesh/Experience.textile index 581a62c8..09f17e17 100644 --- a/open-mesh/Experience.textile +++ b/open-mesh/Experience.textile @@ -26,6 +26,7 @@ h2. Papers: * "Client announcement and Fast roaming in a Layer-2 mesh network":http://eprints.biblio.unitn.it/archive/00002269/ * "Network Coding for Wireless Mesh Networks":http://downloads.open-mesh.org/batman/papers/batman-adv_network_coding.pdf * "B.A.T.M.A.N. routing protocol overhead analysis":http://downloads.open-mesh.org/batman/papers/OGMoverhead.pdf +* "Improving B.A.T.M.A.N. Routing Stability and Performance":http://downloads.open-mesh.org/batman/papers/Improving%2520BATMAN%2520Routing%2520Stability%2520and%2520Performance.pdf * "Performance Analysis of the B.A.T.M.A.N. protocol":http://downloads.open-mesh.org/batman/papers/SANLAB%2520technical%2520report.Batrytis.pdf * "B.A.T.M.A.N. performance comparison paper":http://wirelessafrica.meraka.org.za/wiki/images/9/98/Batman_ifip.pdf * "B.A.T.M.A.N. / BABEL / OLSR performance comparison":http://ro.uow.edu.au/cgi/viewcontent.cgi?article=1747&context=infopapers

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/DistributedArpTable (6be05abf)
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 6be05abfe1fb60a561ac9a967eed6a6f4dbca352 Author: Antonio Quartulli <a(a)unstable.cc> Date: Wed Feb 29 21:25:51 2012 +0000 doc: batman-adv/DistributedArpTable >--------------------------------------------------------------- 6be05abfe1fb60a561ac9a967eed6a6f4dbca352 batman-adv/DistributedArpTable.textile | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/batman-adv/DistributedArpTable.textile b/batman-adv/DistributedArpTable.textile index 53dab872..9795033c 100644 --- a/batman-adv/DistributedArpTable.textile +++ b/batman-adv/DistributedArpTable.textile @@ -1,24 +1,33 @@ h1. Distributed ARP Table -D.A.T. (Distributed ARP Table) is a feature aimed to solve the unreliability problem of the ARP mechanism -which uses a simple broadcast flooding technique in order to retrieve the the data in the network. +D.A.T. (Distributed ARP Table) is a feature aimed to solve the unreliability problem of the [[http://en.wikipedia.org/wiki/Address_Resolution_Protocol|ARP]] dialogue +in sparse wireless networks, where the experienced packet loss is not negligible. h2. The Problem -In each and every subnet the ARP protocol is extremely important: it gives the hosts the possibility to send IP datagram to each other -by retrieving their MAC-layer address. The first step in an ARP dialogue is to issue a broadcast ARP request containing the IP address of the -desidered node which will flood the whole subnet. Once the node using such IP receives the packet, a unicast ARP Reply is sent back -in order to communicate its own MAC-layer address and so becoming reachable for the node that issued the request. +In each and every subnet the ARP protocol is extremely important: it gives any host the possibility to retrieve any other host MAC-layer address. As the reader may know, the latter is mandatory in order to establish any data flow on the IP layer. + +The first step in an ARP dialogue is to issue a broadcast ARP request containing the IP address of the +desidered node. In a mesh network relying on B.A.T.M.A.N.-Advanced, once a node receives a broadcast packet it get forwarded three times (if the packet is received again by the same node it is dropped). Once the node having the IP address contained in the request receives the packet, a *unicast* ARP Reply is sent back to the requester +in order to communicate its own MAC-layer address and making it able to initiate an IP data flow. The mechanism is pretty simple and works well until the probability of losing packets in the network is low enough. For this reason Ethernet or -wireless-infrastructured LANcan use such protocol as is without getting in troubles. Unluckily it is not possible to state the same for a wireless -mesh network, where the probability of losing a packet increase with the number of links the packet has to traverse. In particular, this probability +wireless-infrastructured LAN can use such protocol as-is without getting in troubles. Unluckily it is not possible to state the same for a wireless +mesh network, where the probability of losing a packet increase with the number of links that the packet has to traverse. In particular, this probability gets higher if the packet to send is of type broadcast (this is due to the MAC layer limitations which do not provide ARQ mechanism for this packet type) -like the ARP Request. Assuming to be in a fairly sparse wireless mesh network, an ARP Request could get lost several times before being able to find -its destination, thus dramatically increasing the latency of establishing an IP connection. +like the ARP Request. Assuming to be in a fairly sparse wireless mesh network, an ARP Request could get lost (and so retransmitted) several times before being able to find +the correct destination, thus dramatically increasing the latency of establishing an IP flow. + +h2. A possible solution + +The idea behind D.A.T. is to reduce as much as possible the usage of broadcast packets by replacing them with unicasts. In order to accomplish this task D.A.T. dat uses +part of the theory behind the [[http://en.wikipedia.org/wiki/Distributed_hash_table|DHT (Distributed Hash Tables)]], in particular it uses the DHT to store the ARP entries +so becoming able to later query a particular node in order to get the data which the requester is looking for. h2. DHT basics +The DHT which D.A.T. is based on + !dat_dht-90.png! h2. How DAT merges ARP and the DHT \ No newline at end of file

1 0

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

14 Jul '17

1 0

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

14 Jul '17

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017