[B.A.T.M.A.N.] B.A.T.M.A.N. V outlook

[B.A.T.M.A.N.] B.A.T.M.A.N. V outlook

[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-outlook

Feedback welcome!

Cheers,
Marek

Re: [B.A.T.M.A.N.] B.A.T.M.A.N. V outlook

[Gus Wirth]

On 12/18/2009 01:14 AM, Marek Lindner wrote:
> 
> 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!

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

Re: [B.A.T.M.A.N.] B.A.T.M.A.N. V outlook

[Marek Lindner]

Hey,

> I propose the name "SHLIQ", pronounced sh-lik, kind of like slick, for
> "Single Hop LInk Quality".

ok, is noted.  :)

Thanks,
Marek

Re: [B.A.T.M.A.N.] B.A.T.M.A.N. V outlook

[Alex Morlang]

Am 18.12.2009 um 10:14 schrieb 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-outlook
>
> Feedback welcome!
>

are you considering attaching metrics to HNA?

How about ipv6?

> Cheers,
> Marek

Gruss, Alex

Re: [B.A.T.M.A.N.] B.A.T.M.A.N. V outlook

[Marek Lindner]

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.


> 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

Re: [B.A.T.M.A.N.] B.A.T.M.A.N. V outlook

[Alex Morlang]

Am 07.01.2010 um 14:23 schrieb Marek Lindner:

> 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.

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.

>
>
>> 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?

> Regards,
> Marek

Gruss, Alex

Re: [B.A.T.M.A.N.] B.A.T.M.A.N. V outlook

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]

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).

On Thu, Jan 07, 2010 at 05:10:39PM +0100, Alex Morlang wrote:
>
> Am 07.01.2010 um 14:23 schrieb Marek Lindner:
>
>> 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.
>
> 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.

>>
>>
>>> 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?
>

Even now, batman-adv is independent. We don't have an IPv6 verson of BATMAN
layer 3 however.

best regards,
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [B.A.T.M.A.N.] B.A.T.M.A.N. V outlook

[Linus Lüssing]

[-- Attachment #1: Type: text/plain, Size: 2982 bytes --]

Moin Alex,

On Thu, Jan 07, 2010 at 05:10:39PM +0100, Alex Morlang wrote:
> 
> Am 07.01.2010 um 14:23 schrieb Marek Lindner:
> 
> >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.
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.
> 
> 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).
> 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).
> 
> >
> >
> >>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?
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 :).

> >Regards,
> >Marek
> 
> Gruss, Alex
>
Cheers, Linus

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] B.A.T.M.A.N. V outlook

[Alex Morlang]

Am 07.01.2010 um 22:14 schrieb Simon Wunderlich:

> 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.

>
> On Thu, Jan 07, 2010 at 05:10:39PM +0100, Alex Morlang wrote:
>>
>> Am 07.01.2010 um 14:23 schrieb Marek Lindner:
>>
>>> 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.
>>
>> 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.

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.
...

> best regards,
> 	Simon

Gruss, Alex

[B.A.T.M.A.N.] Maximum MTU (was Re: B.A.T.M.A.N. V outlook)

[Gus Wirth]

On 01/07/2010 01:43 PM, Linus Lüssing wrote:
[snip]
> 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)

[Andrew Lunn]

> 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