commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multicast-ideas: fixing links (4aaa3ed6)
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 4aaa3ed6f98c9ee70232b0279d8a920990e67ca4 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Mon Jun 28 22:52:23 2010 +0000 doc: batman-adv/Multicast-ideas: fixing links >--------------------------------------------------------------- 4aaa3ed6f98c9ee70232b0279d8a920990e67ca4 batman-adv/Multicast-ideas.textile | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/batman-adv/Multicast-ideas.textile b/batman-adv/Multicast-ideas.textile index 75e9c085..d10c0d3a 100644 --- a/batman-adv/Multicast-ideas.textile +++ b/batman-adv/Multicast-ideas.textile @@ -58,11 +58,11 @@ To decrease the time needed for the initial infrastructure creation, the multica === still broadcast smaller/rare, but important multicast packets === The smaller the packets, the less harmful the broadcasting would be for the mesh itself. However, the broadcasting would make the transportation of these packtes more robust in most topologies. The critirea for a "small" multicast packet could be: - * An IPv4 multicast packet from the "Local Network and Internet Work Control Blocks" (224.0.0.0/24, 224.0.1.0/24 - [[http://tools.ietf.org/html/rfc3171|RFC3171]]). These are for instance IGMP- or mDNS-packets. + * An IPv4 multicast packet from the "Local Network and Internet Work Control Blocks" (224.0.0.0/24, 224.0.1.0/24 - [http://tools.ietf.org/html/rfc3171 RFC3171]). These are for instance IGMP- or mDNS-packets. * Well-known IPv6 multicast addresses, having the transient-flag unset. These are for instance the important IPv6 neighbor- and router-discovery packets or mDNS- or DHCPv6-packets. * Threshold-triggering: Only if there've been sent for instance 5KB/s during the last second to the same multicast group destination, start building the optimised multicast distribution infrastructure. -For a nice table of multicast IP- and MAC-address ranges, also see [[http://en.wikipedia.org/wiki/Multicast_address|this]] nice wikipedia-article +For a nice table of multicast IP- and MAC-address ranges, also see [http://en.wikipedia.org/wiki/Multicast_address this] nice wikipedia-article === broadcasting in dense multicast networks === If already about 50%25 of the nodes are part of the same multicast group, then such an optimised multicast distribution infrastructure's gain by minimising the number of forwarding nodes is not that much and because of the very high maintenance overhead the total-"gain" would even be negative. Therefore, if a multicast member notices that there are about 50%25 of the nodes in the originator table in the same multicast group, this node would not start sending mcast_pathsel packets and send the multicast data packets via BAT_BCAST instead. @@ -75,7 +75,7 @@ If so, the intermediate node should not rebroadcast this multicast data packet. A node knows, whether there might be a single multicast member of the same group on the forwarding path left (or better: whether all but one multicast members are behind the neighbor we just received the multicast-data packet from) because of the previously received, broadcasted OGMs (+ MCA entries). In this case, the forwarding node can unwrapp the multicast data packet and wrap it into a batman unicast-header to this single destination instead. This will greatly increase the reliability and throughput to such a remote multicast member because the rate selection algorithms being able to select an optimal value instead of just broadcasting it with the default value of 11MBit/s on the one hand and the now acknowledged transfer for the rest of the path on the other. === NAKs between neighbors === -In wireless networks all unicast traffic is being acknowledged and in case of a loss resend until a certain amount of times. We usually don't have this feature for broadcasted packets, especially because of the mobile characteristics of the mesh it can be quite tough to tell on link layer if there was no ACK because of interference or because the neighbor got out of range. It is therefore a lot easier to use NAKs in this case - if a neigbor who is part of the distribution infrastructure detects a missing sequence number, it could request it again and receive it via unicast from the according neighbor. PGM ([[http://tools.ietf.org/html/rfc3208|RFC3208]])is also using the NAK approach on the transport layer for multicast packets for instance. +In wireless networks all unicast traffic is being acknowledged and in case of a loss resend until a certain amount of times. We usually don't have this feature for broadcasted packets, especially because of the mobile characteristics of the mesh it can be quite tough to tell on link layer if there was no ACK because of interference or because the neighbor got out of range. It is therefore a lot easier to use NAKs in this case - if a neigbor who is part of the distribution infrastructure detects a missing sequence number, it could request it again and receive it via unicast from the according neighbor. PGM ([http://tools.ietf.org/html/rfc3208 RFC3208])is also using the NAK approach on the transport layer for multicast packets for instance. === Only send MCAs as a receiver(/sender), if there is a sender(/receiver) too === If there is no multicast sender available anyway, then a receiver does not have to announce its multicast member presence because there'd be no need for the distribution infrastructure with no sender anyway. Especially if the multicast sender might not be statically, permanently but adhoc, temporarily available instead, this can reduce the burdon on the mesh network quite a lot if there are also a lot of multicast receivers. @@ -88,8 +88,8 @@ A node can easily detect a receiver-host on its local network by listening to IG === Resources: === * ADAMA (-SM/DM - sparse and dense mode) - "Multicast-Routing in mobilen Ad-hoc-Netzen", Oliver Stanze, ISBN-13: 978-3832266141 - * ODMRP [[http://tools.ietf.org/html/draft-ietf-manet-odmrp-04|draft-ietf-manet-odmrp…, - * SMF [[http://tools.ietf.org/html/draft-ietf-manet-smf-10|draft-ietf-manet-smf-10]] - * PGM [[http://tools.ietf.org/html/rfc3208|rfc3208]] + * ODMRP [http://tools.ietf.org/html/draft-ietf-manet-odmrp-04 draft-ietf-manet-odmrp-04],[http://www.hpl.hp.com/personal/Sung-Ju_Lee/abst… wcnc99.pdf], + * SMF [http://tools.ietf.org/html/draft-ietf-manet-smf-10 draft-ietf-manet-smf-10] + * PGM [http://tools.ietf.org/html/rfc3208 rfc3208] }}}

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multicast-ideas: added another optimization idea (4af9cbb9)
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 4af9cbb991fcb4295b90985e26e7c5ffb7d82154 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Mon Jun 28 23:47:45 2010 +0000 doc: batman-adv/Multicast-ideas: added another optimization idea >--------------------------------------------------------------- 4af9cbb991fcb4295b90985e26e7c5ffb7d82154 batman-adv/Multicast-ideas.textile | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/batman-adv/Multicast-ideas.textile b/batman-adv/Multicast-ideas.textile index df9f1998..a93af4b4 100644 --- a/batman-adv/Multicast-ideas.textile +++ b/batman-adv/Multicast-ideas.textile @@ -93,6 +93,13 @@ This probably depends on the usage scenarion, but the first option should be the A node can easily detect a receiver-host on its local network by listening to IGMP- or ICMPv6-MDN packets. A sender could be detected by the multicast-destination mac of data packets - however this should not initiate the path maintenance for all kinds of multicast packets as stated above (also IGMP/ICMPv6 are being send via multicast for instance - effectively making any node receiver a sender as well otherwise). +=== Only build paths from senders to receivers === +In most cases, a multicast member won't be a sender and receiver at the same time. In such a case, a selected multicast path from the receiver to the sender is not necessary. Two additional flags MCAST_SENDER and MCAST_RECEIVER could be attached to an MCA. A node receiving an MCA, would then only start the unicasted mcast_pathsel stream if the following requirements are matched: + * I belong to the same multicast group stated in the received MCA. + * I am a sender of the MCA's multicast group. + * The received MCA has the MCAST_RECEIVER flag set. +Only then an optimised multicast path would be established to the MCA's originator. + === Resources: === * ADAMA (-SM/DM - sparse and dense mode) - "Multicast-Routing in mobilen Ad-hoc-Netzen", Oliver Stanze, ISBN-13: 978-3832266141 * ODMRP [http://tools.ietf.org/html/draft-ietf-manet-odmrp-04 draft-ietf-manet-odmrp-04],[http://www.hpl.hp.com/personal/Sung-Ju_Lee/abst… wcnc99.pdf],

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multicast-ideas: wouldn't need a new packet type, just the unicast struct (5e7a05da)
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 5e7a05da20a7204b678bc50260877a59a09746a8 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Mon Jun 28 23:26:23 2010 +0000 doc: batman-adv/Multicast-ideas: wouldn't need a new packet type, just the unicast struct >--------------------------------------------------------------- 5e7a05da20a7204b678bc50260877a59a09746a8 batman-adv/Multicast-ideas.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/batman-adv/Multicast-ideas.textile b/batman-adv/Multicast-ideas.textile index b83b5816..df9f1998 100644 --- a/batman-adv/Multicast-ideas.textile +++ b/batman-adv/Multicast-ideas.textile @@ -75,11 +75,11 @@ If so, the intermediate node should not rebroadcast this multicast data packet. A node knows, whether there might be a single multicast member of the same group on the forwarding path left (or better: whether all but one multicast members are behind the neighbor we just received the multicast-data packet from) because of the previously received, broadcasted OGMs (+ MCA entries). In this case, the forwarding node can unwrapp the multicast data packet and wrap it into a batman unicast-header to this single destination instead. This will greatly increase the reliability and throughput to such a remote multicast member because the rate selection algorithms being able to select an optimal value instead of just broadcasting it with the default value of 11MBit/s on the one hand and the now acknowledged transfer for the rest of the path on the other. === switching between multicast and unicast forwarding === -This is basically an extension of the optimization stated above. But instead of converting a BAT_MCAST to unicast only once at the end of a packets journey, this optimization here also suggests to convert the means of tranportation back and forth: If a multicast data packets journey would get to a crotch, so two different forwarding nodes as next hops for the data, then the packet should be broadcasted by the node on the crotch with the advantage of only blocking the wifi medium once (as the basic algorithm is doing it, too). However, if a node which is part of the distribution infrastructure and knows, that there's just one recipient, just one next hop being a forwarding node, then the multicast data packet should be send as a unicast packet (with a special packet structure *). +This is basically an extension of the optimization stated above. But instead of converting a BAT_MCAST to unicast only once at the end of a packets journey, this optimization here also suggests to convert the means of tranportation back and forth: If a multicast data packets journey would get to a crotch, so two different forwarding nodes as next hops for the data, then the packet should be broadcasted by the node on the crotch with the advantage of only blocking the wifi medium once (as the basic algorithm is doing it, too). However, if a node which is part of the distribution infrastructure and knows, that there's just one recipient, just one next hop being a forwarding node, then the multicast data packet should be send as a unicast packet. The packet-type would be a new one (i.e. BAT_MCAST_UNI) and the orig-field needs to be set to the multicast address. A forwarding node of a certain multicast group distribution infrastructure can detect if it is on a crotch without any additional communication need, it just has to memorise the following more entry: Of one multicast-group's mcast_pathsel stream(s) (the unicast packets maintaining an efficient distribution infrastructure), not only memorize the group and the previous senders mac address, but also the next hop destination mac address(es). If this forwarding node has multiple of these matching next hop destination addresses then it knows it is on a crotch. -So if a forwarding node sitting on a crotch receives a multicast data packet via unicast, then it has to reencapsulate it in a broadcast header with multicast flag. If a forwarding node ''not'' sitting on a crotch receives a multicast data packet via broadcast, then it has to reecapsulate it in a mcast header with unicast destination. Otherwise it can forward the packet according to its table without having to reencapsulate it. +So if a forwarding node sitting on a crotch receives a multicast data packet via unicast, then it has to reencapsulate it in a broadcast header with multicast flag. If a forwarding node ''not'' sitting on a crotch receives a multicast data packet via broadcast, then it has to reecapsulate it in a unicast header. Otherwise it can forward the packet according to its table without having to reencapsulate it. === NAKs between neighbors === In wireless networks all unicast traffic is being acknowledged and in case of a loss resend until a certain amount of times. We usually don't have this feature for broadcasted packets, especially because of the mobile characteristics of the mesh it can be quite tough to tell on link layer if there was no ACK because of interference or because the neighbor got out of range. It is therefore a lot easier to use NAKs in this case - if a neigbor who is part of the distribution infrastructure detects a missing sequence number, it could request it again and receive it via unicast from the according neighbor. PGM ([http://tools.ietf.org/html/rfc3208 RFC3208])is also using the NAK approach on the transport layer for multicast packets for instance.

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multicast-ideas (b7e008ff)
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 b7e008ff11f90332a4f2acbe5aff63c5bb105cc5 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Sun Jun 27 02:07:16 2010 +0000 doc: batman-adv/Multicast-ideas >--------------------------------------------------------------- b7e008ff11f90332a4f2acbe5aff63c5bb105cc5 batman-adv/Multicast-ideas.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Multicast-ideas.textile b/batman-adv/Multicast-ideas.textile index 1d714145..fa83482c 100644 --- a/batman-adv/Multicast-ideas.textile +++ b/batman-adv/Multicast-ideas.textile @@ -36,7 +36,7 @@ struct mcast_pathsel_packet { }}} == Pros/Cons == * As the mcast_path_sel packets are being forwarded via unicast, they'd create a multicast topology with determining shortest, direct paths according to BATMAN's unicast metric. ADAMA-SM for instance is not optimising in this way, instead it tries to reduce the number of forwarding nodes in general (which is nice for the mesh burdon itself, but might create unusable / too long paths for certain multicast receivers in real wireless networks). - +---- == Further Extensions == === Distribution infrastructure initiation - bursting === To decrease the time needed for the initial infrastructure creation, the multicast announcements could be send with their own packet type instead of being attached to OGMs. They could then be send in a burst of for instance 5 identical packets. Furthermore, these packets could have a rebroadcast-count which means, that also every intermediate node would rebreadcast for instance 5 identical packets again. The wait-time to switch from pure flooding of the multicast packets to the optimised path selection could then for instance be set to 1 instead of the 5 seconds. After that, such designated multicast annuncement packets could be send at a much slower interval as the OGM packets (something like 5-10 seconds for instance).

1 0

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

14 Jul '17

1 0

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

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Contribute (5c03d719)
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 5c03d71944a64342557e8205a5ce02cd871aec00 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Mon Jun 21 12:24:35 2010 +0000 doc: open-mesh/Contribute >--------------------------------------------------------------- 5c03d71944a64342557e8205a5ce02cd871aec00 open-mesh/Contribute.textile | 56 +++++++++++++++++--------------------------- 1 file changed, 21 insertions(+), 35 deletions(-) diff --git a/open-mesh/Contribute.textile b/open-mesh/Contribute.textile index 3dea4bd4..35e2f404 100644 --- a/open-mesh/Contribute.textile +++ b/open-mesh/Contribute.textile @@ -1,20 +1,23 @@ + = How to Contribute = -Thanks for using B.A.T.M.A.N.! If you have suggestions, comments, want to tell us [[BR]] -about your experiences or discuss problems the best thing is always to use the [[BR]] -[wiki:MailingList Mailing List]. You can always contact us via [wiki:IRC IRC]. -If you like this project and you want to take part and/or give something back, [[BR]] -here is a short list of starting points: +{{{ +#!div style="width: 46em; text-align: justify" + +Thanks for using B.A.T.M.A.N.! If you have suggestions, comments, want to tell us about your experiences or discuss problems the best thing is always to use the [wiki:MailingList Mailing List]. You can always contact us via [wiki:IRC IRC]. + +If you like this project and you want to take part and/or give something back, here is a short list of starting points: === Reporting Bugs === + If you find a bug, please see if the problem is already known in the by [https://dev.open-mesh.org/batman/report Reading the Tickets]. [[BR]] If not, please [https://dev.open-mesh.org/batman/newticket add a new Ticket]. Please add as much information as possible. In particular interesting are: * Which branch (batman, bmx, batman-advanced) - * Which version (0.X, SVN revision number) + * Which version (0.X, SVN/git revision number) * kernel version, distribution (and version) * machine type (PC, Linksys WRT, Fon, NS2, ...) * command line parameters used @@ -24,8 +27,7 @@ Please add as much information as possible. In particular interesting are: === Documentation / Feedback === -Write an article about your experience with B.A.T.M.A.N. and have it published here or ask [[BR]] -us to link to your site: +Write an article about your experience with B.A.T.M.A.N. and have it published here or ask us to link to your site: * How did you find us ? * How does you setup look like ? * Where are you building your mesh ? @@ -34,43 +36,27 @@ us to link to your site: * What did you like / not like ? * How can B.A.T.M.A.N. improve ? -There's lots of people that want to know about B.A.T.M.A.N. - help us to spread the word! [[BR]] -We also hand out direct wiki access to those that are interested. Please ask on our [[BR]] -[wiki:MailingList mailing list] for the accounts. +There's lots of people that want to know about B.A.T.M.A.N. - help us to spread the word! You also can create a wiki account and improve the documentation. === Research === -B.A.T.M.A.N. gives much room for research, especially the layer 2 implementation in the [[BR]] -kernel. Get in touch with us to share your ideas. If you write papers we are happy to [[BR]] -publish them here or link to your page. If you are looking for the right topic or [[BR]] -mentorship feel free to contact us. We have more ideas than time to implement them. +B.A.T.M.A.N. gives much room for research, especially the layer 2 implementation in the kernel. Get in touch with us to share your ideas. If you write papers we are happy to publish them here or link to your page. If you are looking for the right topic or mentorship feel free to contact us. We have more ideas than time to implement them. === Development === -You looked in the code ? Fixed bugs ? Added a cool new function ? Integrated B.A.T.M.A.N.[[BR]] -in a distribution ? Don't hesitate to let us and others know! We can avoid duplicated [[BR]] -work by publishing it here or linking to your page. Patches are always welcome and can [[BR]] -be posted on the [wiki:MailingList mailing list] to get integrated. We also hand out SVN [[BR]] -access to people that want to get involved. +You looked in the code ? Fixed bugs ? Added a cool new function ? Integrated B.A.T.M.A.N. in a distribution ? Don't hesitate to let us and others know! We can avoid duplicated work by publishing it here or linking to your page. Patches are always welcome and can be posted on the [wiki:MailingList mailing list] to get integrated. We also hand out SVN/git access to people that want to get involved. === Submitting patches === If you intend to send us patches, please consider the following guidelines: * Prefer small & digestible over long "all in one" patches. - * No MIME, no links, no compression, no attachments. Just plain text. - * Patches sent to the mailing list should include "PATCH" in the subject to make[[BR]] - it easier to distinguish between patches and discussions. - * The mail's subject will become the first line in the commit message. The body [[BR]] - contains the longer patch description and the patch (unified format) itself. [[BR]] - Please also specify the target branch (e.g. batctl, batman-adv, etc) at the [[BR]] - beginning of the subject line. See the [http://www.open-mesh.org/timeline timeline] for more examples. - * Add a "Signed-off-by: Your Name <!you(a)example.com>" line to the patch [[BR]] - message to make the ownership of the patch clear. - * Patches for B.A.T.M.A.N. Advanced need to follow the linux kernel coding style[[BR]] - closely (use checkpatch.pl to verify your patch) as well as the linux "how to [[BR]] - submit patches" guidelines (search for the term !SubmitPatches to find thorough[[BR]] - documentation). - * An exemplary good submission you may want to look at can be found here:[[BR]] - https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2009-December/002033.html + * No MIME, no links, no compression, no attachments. Just plain text (patches are to be sent inline). + * Patches sent to the mailing list should include "PATCH" in the subject to make it easier to distinguish between patches and discussions. + * The mail's subject will become the first line in the commit message. The body contains the longer patch description and the patch (unified format) itself. Please also specify the target branch (e.g. batctl, batman-adv, etc) at the beginning of the subject line. See the [http://www.open-mesh.org/timeline timeline] for more examples. + * Add a "Signed-off-by: Your Name <!you(a)example.com>" line to the patch message to make the ownership of the patch clear. + * Patches for B.A.T.M.A.N. Advanced need to follow the linux kernel coding style closely (use checkpatch.pl to verify your patch) as well as the linux "how to submit patches" guidelines (search for the term !SubmitPatches to find thorough documentation). + * An exemplary good submission you may want to look at can be found here: https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2009-December/002033.html + +}}}

1 0

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

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Multicast-ideas: adding two more extension ideas (5850e38f)
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 5850e38f04e45c624dcdc7f153da26dcdcd718ff Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Sun Jun 27 01:27:01 2010 +0000 doc: batman-adv/Multicast-ideas: adding two more extension ideas >--------------------------------------------------------------- 5850e38f04e45c624dcdc7f153da26dcdcd718ff batman-adv/Multicast-ideas.textile | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/batman-adv/Multicast-ideas.textile b/batman-adv/Multicast-ideas.textile index 7cf4483f..396f0535 100644 --- a/batman-adv/Multicast-ideas.textile +++ b/batman-adv/Multicast-ideas.textile @@ -39,7 +39,9 @@ struct mcast_pathsel_packet { == Further Extensions == === Distribution infrastructure initiation - bursting === -To decrease the time needed for the initial infrastructure creation, the multicast announcements could be send with their own packet type instead of being attached to OGMs. They could then be send in a burst of for instance 5 identical packets. Furthermore, these packets could have a rebroadcast-count which means, that also every intermediate node would rebreadcast for instance 5 identical packets again. The wait-time to switch from pure flooding of the multicast packets to the optimised path selection could then for instance be set to 1 instead of the 5 seconds. +To decrease the time needed for the initial infrastructure creation, the multicast announcements could be send with their own packet type instead of being attached to OGMs. They could then be send in a burst of for instance 5 identical packets. Furthermore, these packets could have a rebroadcast-count which means, that also every intermediate node would rebreadcast for instance 5 identical packets again. The wait-time to switch from pure flooding of the multicast packets to the optimised path selection could then for instance be set to 1 instead of the 5 seconds. After that, such designated multicast annuncement packets could be send at a much slower interval as the OGM packets (something like 5-10 seconds for instance). + +(Or if there'd be the planned NDP(neighbor discovery protocol) - HELLOs - as well as optional HNA entries (so a missing HNA in an OGM not causing it to be purged on other nodes in the mesh, a designated multicast announcement packet type would not be needed for this. We could just use a small OGM with less information, but still the TQ-value and sequence numbers, too, then as otherwise the ethernet frames' payload would be zero-padded to 46 Bytes anyway which would be a waste.) === still broadcast smaller/rare, but important multicast packets === The smaller the packets, the less harmful the broadcasting would be for the mesh itself. However, the broadcasting would make the transportation of these packtes more robust in most topologies. The critirea for a "small" multicast packet could be: @@ -62,6 +64,15 @@ A node knows, whether there might be a single multicast member of the same group === NAKs between neighbors === In wireless networks all unicast traffic is being acknowledged and in case of a loss resend until a certain amount of times. We usually don't have this feature for broadcasted packets, especially because of the mobile characteristics of the mesh it can be quite tough to tell on link layer if there was no ACK because of interference or because the neighbor got out of range. It is therefore a lot easier to use NAKs in this case - if a neigbor who is part of the distribution infrastructure detects a missing sequence number, it could request it again and receive it via unicast from the according neighbor. PGM ([[http://tools.ietf.org/html/rfc3208|RFC3208]])is also using the NAK approach on the transport layer for multicast packets for instance. +=== Only send MCAs as a receiver(/sender), if there is a sender(/receiver) too === +If there is no multicast sender available anyway, then a receiver does not have to announce its multicast member presence because there'd be no need for the distribution infrastructure with no sender anyway. Especially if the multicast sender might not be statically, permanently but adhoc, temporarily available instead, this can reduce the burdon on the mesh network quite a lot if there are also a lot of multicast receivers. + +Of course, the other way round, the benefits would be greater if doing it the other way round - receiver-based - if there'd be more multiple senders in the same multicast group and only one receiver there at a time with a very dynamic uptime. + +This probably depends on the usage scenarion, but the first option should be the default. + +A node can easily detect a receiver-host on its local network by listening to IGMP- or ICMPv6-MDN packets. A sender could be detected by the multicast-destination mac of data packets - however this should not initiate the path maintenance for all kinds of multicast packets as stated above (also IGMP/ICMPv6 are being send via multicast for instance - effectively making any node receiver a sender as well otherwise). + === Resources: === * ADAMA (-SM/DM - sparse and dense mode) - "Multicast-Routing in mobilen Ad-hoc-Netzen", Oliver Stanze, ISBN-13: 978-3832266141 * ODMRP [[http://tools.ietf.org/html/draft-ietf-manet-odmrp-04|draft-ietf-manet-odmrp…,

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/UsingBatmanGit (c1befc23)
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 c1befc23a5a8033436740419e7600d12dfc87785 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jun 26 10:08:39 2010 +0000 doc: open-mesh/UsingBatmanGit >--------------------------------------------------------------- c1befc23a5a8033436740419e7600d12dfc87785 open-mesh/UsingBatmanGit.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/open-mesh/UsingBatmanGit.textile b/open-mesh/UsingBatmanGit.textile index b5d27d13..bcfb48ae 100644 --- a/open-mesh/UsingBatmanGit.textile +++ b/open-mesh/UsingBatmanGit.textile @@ -110,7 +110,7 @@ If you need to see the difference between the maint branch and the batman-adv dr }}} {{{ -git diff maint: master:drivers/staging/batman-adv/ +git diff maint: linux:drivers/staging/batman-adv/ }}} {{{

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017