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

[Harald Geyer]

>> Ok. For this to work you will most likely need to drop nodes which
>> shouldn't be MPR from the neighbor set if you want to be RFC
>> compliant. That shouldn't cause any problems, but it would be nice
>> if the information about the full neighbor set was kept around
>> somehow - we use this a lot for link planning (As we use the
>> information from topology flooding for our map.)
> Of course the MPR selection must still be "large enough" to be RFC
> sufficient. I discussed the idea with Thomas Clausen in Vienna and
> he said he doesn't see a reason why it should not be RFC compatible.

That's part of what I wanted to point out in my initial mail, when
I was talking about channel diversity and especially when I was talking
about (weak) long range links:

Direkt neighbors on long range links tend to introduce new 2-hop 
neighbors that can't be reached by any other MPR (in two hops).

Now the whole point of the link quality system is IMO to use several
short links instead of a long one in cases where this will improve
performance. So if you want to use link quality for MPR selection you
will want to drop the neighbor on the long range link from the MPR set.
But if you do this the RFC requires you to drop this neighbor from the
neighbor set as well to get rid of the now "unreachable" 2-hop
neighbors.

>> > Second we are thinking about writing some kind of "remote repeater"
>> > version of the olsrd for connecting multiple routers (connected
>> > with ethernet) into a virtual "one node, multiple radio" router.
>> > This way olsr would not need MPRs to connect over ethernet because
>> > the switched connections would be "invisible".
>>
>> Yes, that would be extremely useful. Depending on how far you want
>> to go it might be difficult to implement for a link state protocol
>> though ...
> My idea was just to have to "dump" nodes that give the "master" olsr to
> communicate over interfaces not connected to his own machine. Maybe just a
> tunnel protocoll or something like this.

Yes, having a dedicated master that calculates the routing tables for
all devices (or calculates some general routing table that is refined
by the slave olsrd) will make things a lot easier, but one
issue remains: You need some very robust mechanism to keep the 
kernel routing tables on all devices synchronized. If for some reason
the routing tables get out of syncronization for more then a few
miliseconds then a node internal routing loop might happen - easily 
producing that much traffic that further routing table update messages
might get delayed or lost - thus adding to the synchronization
problem.

Anyway I think it would be very interesting to try this in practice.

Harald