B.A.T.M.A.N. V outlook
Hey,
I wrote a summary regarding the current ideas how B.A.T.M.A.N. V could look
like: http://www.open-mesh.net/wiki/2009-12-18-batman-v-outlook
Feedback welcome!
Cheers,
Marek
Quoted 7 lines · Marek Lindner
Hey,
I wrote a summary regarding the current ideas how B.A.T.M.A.N. V could look
like: http://www.open-mesh.net/wiki/2009-12-18-batman-v-outlookFeedback welcome!
In the section "overhead Reduction" you say:
"The new message type (a name needs to be found) will contain the link qualities of the single hop neighbors only."
I propose the name "SHLIQ", pronounced sh-lik, kind of like slick, for "Single Hop LInk Quality".
Gus
Hey,
Quoted 2 lines
I propose the name "SHLIQ", pronounced sh-lik, kind of like slick, for "Single Hop LInk Quality".
ok, is noted. :)
Thanks,
Marek
Am 18.12.2009 um 10:14 schrieb Marek Lindner:
Quoted 8 lines
Hey,
I wrote a summary regarding the current ideas how B.A.T.M.A.N. V could look
like: http://www.open-mesh.net/wiki/2009-12-18-batman-v-outlookFeedback welcome!
are you considering attaching metrics to HNA?
How about ipv6?
Quoted 2 lines
Cheers,
Marek
Gruss, Alex
Quoted 1 line · On Thursday 07 January 2010 15:44:36 Alex Morlang wrote:
are you considering attaching metrics to HNA?
That is not necessary as each non-batman host is connected to a batman host which has a metric. Therefore the implementation just needs to support the HNA metric. The batman daemon does so since quite a long time. It is on the feature list for batman-adv 0.3 but does not require any protocol changes unless I miss your point.
Quoted 1 line
How about ipv6?
I can't follow you here. The length of the protocol identifier (IPv4 address/IPv6 address/mac address/random number) is not relevant for the routing protocol.
Regards,
Marek
Am 07.01.2010 um 14:23 schrieb Marek Lindner:
Quoted 8 lines · On Thursday 07 January 2010 15:44:36 Alex Morlang wrote:
Quoted 1 line
are you considering attaching metrics to HNA?
That is not necessary as each non-batman host is connected to a batman host which has a metric. Therefore the implementation just needs to support the HNA metric. The batman daemon does so since quite a long time. It is on the feature list for batman-adv 0.3 but does not require any protocol changes unless I miss your point.
maybe you do, as you might have costs between the connected network and the connecting batman node.
when you have more then one batman node connecting a network to the mesh, this costs should be relevant.
Quoted 8 lines
Quoted 3 lines
How about ipv6?
I can't follow you here. The length of the protocol identifier (IPv4 address/IPv6 address/mac address/random number) is not relevant for the routing protocol.
ok, i thought you were talking about an implementation, so i asked about support for this addresstype.
so am i right in thinking the next batman will be protocol independent?
Quoted 2 lines
Regards,
Marek
Gruss, Alex
Hello,
we probably did not make this very clear in the document, but we will focus our work on batman-adv (layer 2) and will keep the batmand (layer 3) as it is for now. As a consequence, some ideas for BATMAN V are layer 2 exclusive (mesh bonding, incoming interface based routing).
Quoted 16 lines · Alex Morlang
Am 07.01.2010 um 14:23 schrieb Marek Lindner:
Quoted 12 lines · On Thursday 07 January 2010 15:44:36 Alex Morlang wrote:
Quoted 1 line
are you considering attaching metrics to HNA?
That is not necessary as each non-batman host is connected to a batman host
which has a metric. Therefore the implementation just needs to support the HNA
metric. The batman daemon does so since quite a long time. It is on the
feature list for batman-adv 0.3 but does not require any protocol changes
unless I miss your point.
Quoted 6 lines
maybe you do, as you might have costs between the connected network and the connecting batman node.
when you have more then one batman node connecting a network to the mesh, this costs should be relevant.
That might be true, however in batman-adv we are dynamically adding and removing MAC addresses. IMHO, it would not make so much sense to add custom metrics to each mac address. If you need to connect subnets, it might be feasible to use something like BGP and extract batman metrics out of the module.
Quoted 10 lines
Quoted 9 lines
Quoted 3 lines
How about ipv6?
I can't follow you here. The length of the protocol identifier (IPv4 address/IPv6 address/mac address/random number) is not relevant for the
routing protocol.
Quoted 5 lines
ok, i thought you were talking about an implementation, so i asked about support for this addresstype.
so am i right in thinking the next batman will be protocol independent?
Even now, batman-adv is independent. We don't have an IPv6 verson of BATMAN layer 3 however.
best regards,
Simon
Am 07.01.2010 um 22:14 schrieb Simon Wunderlich:
Quoted 6 lines
Hello,
we probably did not make this very clear in the document, but we will focus our work on batman-adv (layer 2) and will keep the batmand (layer 3) as it is for now. As a consequence, some ideas for BATMAN V are layer 2 exclusive (mesh bonding, incoming interface based routing).
thanks for that clarification.
Quoted 21 lines · Alex Morlang
Quoted 19 lines
Am 07.01.2010 um 14:23 schrieb Marek Lindner:
Quoted 12 lines · On Thursday 07 January 2010 15:44:36 Alex Morlang wrote:
Quoted 1 line
are you considering attaching metrics to HNA?
That is not necessary as each non-batman host is connected to a batman host
which has a metric. Therefore the implementation just needs to support the HNA
metric. The batman daemon does so since quite a long time. It is on the
feature list for batman-adv 0.3 but does not require any protocol changes
unless I miss your point.maybe you do, as you might have costs between the connected network and the connecting batman node.
Quoted 8 lines
Quoted 3 lines
when you have more then one batman node connecting a network to the mesh, this costs should be relevant.
That might be true, however in batman-adv we are dynamically adding and removing MAC addresses. IMHO, it would not make so much sense to add custom metrics to each mac address. If you need to connect subnets, it might be feasible to use something like BGP and extract batman metrics out of the module.
sure, but as i understand, you have no way of exporting STP and RSTP path costs into batman, which could make sense in a mixed wired/wireless enviroment.
...
Quoted 2 lines
best regards,
Simon
Gruss, Alex
Moin Alex,
Quoted 15 lines · Alex Morlang
Am 07.01.2010 um 14:23 schrieb Marek Lindner:
Quoted 12 lines · On Thursday 07 January 2010 15:44:36 Alex Morlang wrote:
Quoted 1 line
are you considering attaching metrics to HNA?
That is not necessary as each non-batman host is connected to a batman host
which has a metric. Therefore the implementation just needs to support the HNA
metric. The batman daemon does so since quite a long time. It is on the
feature list for batman-adv 0.3 but does not require any protocol changes
unless I miss your point.
At the moment, every mac address announced by a batman-adv node in the mesh network has the same value. In an open mesh network an evil batman-adv node could do some serious DoS attacks. Therefore it is planned to prefer HNAs from the closest batman-adv node in batman-adv 0.3 instead so that such an attack would be limited to the local area only. As Marek already pointed out, this behavior had already been implemented in batman-daemon (the old layer 3 version) and would probably just need to be ported without any internal batman-adv protocol changes.
Quoted 3 lines
maybe you do, as you might have costs between the connected network and the connecting batman node.
In general, batman-adv adds a little header of 24 Bytes. But this kind of extra cost also applies to packets between batman nodes, not only when a packet comes from the connected network. So if you are bridging any other networks/hosts into the mesh network (i.e. bridging eth0 + bat0) does not matter, you should just a) increase the MTU of the mesh-interfaces to 1524 which is usually not a problem for wifi interfaces or b) decrease the MTU on all hosts to 1476 (usually not so do-able).
Quoted 2 lines
when you have more then one batman node connecting a network to the mesh, this costs should be relevant.
Hmm, well, batman-adv is adding the HNAs stating the hosts' mac addresses behind a certain batman-node (the bat0 interfaces directly or nodes being bridged into this one) to its originator messages, which get flooded one in a second by default so far. Do the maths how bad that might be for larger mesh networks (keeping the intended packet loss of wifi in mind).
Quoted 11 lines
Quoted 10 lines
Quoted 4 lines
How about ipv6?
I can't follow you here. The length of the protocol identifier (IPv4 address/IPv6 address/mac address/random number) is not relevant for the
routing protocol.
Quoted 4 lines
ok, i thought you were talking about an implementation, so i asked about support for this addresstype.
so am i right in thinking the next batman will be protocol independent?
batman-adv is operating between layer 2 and 3, you can use ipv6, ipv4, ..., any layer 3 internet protocol you like. And this has already been supperted in previous versions, this won't be a new feature of a batman-adv 0.3 version :).
Quoted 5 lines
Quoted 2 lines
Regards,
MarekGruss, Alex
Cheers, Linus
[B.A.T.M.A.N.] Maximum MTU (was Re: B.A.T.M.A.N. V outlook)
On 01/07/2010 01:43 PM, Linus Lüssing wrote:
[snip]
Quoted 8 lines
In general, batman-adv adds a little header of 24 Bytes. But this kind of extra cost also applies to packets between batman nodes, not only when a packet comes from the connected network. So if you are bridging any other networks/hosts into the mesh network (i.e. bridging eth0 + bat0) does not matter, you should just a) increase the MTU of the mesh-interfaces to 1524 which is usually not a problem for wifi interfaces or b) decrease the MTU on all hosts to 1476 (usually not so do-able).
Would you happen to know what the maximum MTU you could use on the wireless interface?
For example, if I have an ethernet network that can support jumbo frames like on a gigabit interface, how large of an MTU could I use on the wireless interface. In my case I'm using Atheros wireless devices, so I don't know if that matters.
Gus
Re: [B.A.T.M.A.N.] Maximum MTU (was Re: B.A.T.M.A.N. V outlook)
Quoted 2 lines
Would you happen to know what the maximum MTU you could use on the wireless interface?
The 802.11 standard says the MSDU size is 2304 octets. How many IP bytes you can fit into this depends on what encryption scheme you are using, which adds different size headers.
However your hardware may not support this, since typically 1500 bytes for Ethernet is what you need to work with. Also, as the packet gets bigger, the more likely it is to get corrupted, and more likely that the retry will also get corrupted etc... If you do increase the frame size to its max, i would suggest enabling RTC/CTS, use 5GHz, and in a mesh network of 2 nodes....
Andrew