[Olsr-dev] Comments regarding the talk of Thomas Clausen at metalab

[Henning Rogge]

Am Dienstag 19 August 2008 15:21:33 schrieb Harald Geyer:
> > The problem is that it's impossible to know at this point of the
> > protocoll if we can reach the "weak neighbor" with another link.
>
> I know. So you would need to use information from the full routing
> table, to drop some nodes from the MPR set only if the information is
> available. Do you see there anything fundamentally wrong with such an
> aproach?
The decission what we should put into the MPR is done during Hello processing. 
Later the Hello-Information is used to generate TCs. If we use information 
from TCs to drop stuff from the hellos, this might lead to routing 
fluctuations.

> I'm not sure if/where we disagree: My point was: If you want to drop
> neighbors on long links from the MPR set (i.e. because there is a
> better multi hop route to them) then you (in a typical situation) need
> to drop them from the neighbor set as well.
>
> Do you see anything wrong with this statement?
>
> Did I miss your point?
You don't need to drop them, because the weak MPRs will only be used flooding 
olsr packets. If the weak link loose the flooded package it's okay, it will 
reach the node by retransmission. Because ALL olsr packets are broadcasts we 
don't even loose airtime, just a little bit space to store the additional 
neighbor in hellos/tcs.

> > The easiest way would be to do the routing completely on one
> > device and use dump "tunnels" to connect the WLAN interfaces
> > of the "secondary" routers to the "main router". But this would
> > require routing the traffic through userspace, which is very bad
> > for performance.
>
> That's what Markus Kittenberger and me are working on right now.
> Actually we don't use tunnels but link layer bridging, which
> seems to be sufficiently performant.
>
> There are at least three devices in the funkfeuer net testing our
> setup since about 4 weeks, but there are still some issues (unrelated
> to olsr) which prevent us from suggesting wider deployment. See the
> (german) wiki page for more info if you are interested:
> http://wiki.funkfeuer.at/index.php/Arbeitsgruppe_Software_AdhocBridge
I think this setup will be difficult for 3-channel devices (3 routers 
connected by switches), because we will not know which channel/router 
received the package. This is not important now, but it will become important 
for MIC metric (channel/collision aware routing).

> > The second way would be to keep "consistent" routing tables on all
> > devices, this would require some thoughts about synchronization,
> > but I think this is the better option.
>
> Yes, in the long term I'd prefer to have such a feature in the olsrd
> too. The above bridge setup was meant as a proof of concept to
> convince other people that we need this in olsrd ...
I think it's a really good way to reduce the complexity of our networks. We 
will only have one node for each geographical position, not one for each 
antenna. That will reduce the work for the dijkstra by a huge amount !

Henning

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: (spam-protected)
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender 
(Stellv.)