[Olsr-dev] Freifunk Testing
Sun Jun 15 13:07:08 CEST 2008
On Sun, 2008-06-15 at 09:48 +0200, Sven-Ola Tücke wrote:
> no paper on this AFAIK. This is the result of practial implementation, testing
> and observing.
Nevertheless a IMHO nice writeup.
> While I'm not a routing expert (you may note that I've missed to learn the
> specific vocabulary) this is my personal opinion on different mesh routing
> protocols doing loops and such:
> * Loops occur, because a couple of nodes do not agree on their routing
> decisions. Two reasons: different (topo) input or different algo (also known
> as bugs).
> * While algo/bugs can be solved by deploying software, different input is
> fundamental. Transferring state info over lossy links automatically leads to
> different input. At least on the time axis (e.g. if you make a snapshot of a
> typical mesh, you'll find that nodes have a different notion on the networks
> * The original RFC-OLSR also includes an optimization to limit the amount of
> traffic necessary to spread info by use of MPRs (some "overlay network" of
> nodes involved in info transmission).
> * Current OLSRd approach to overcome this is "brute force". Simply send out
> info more than once. And disable the MPR optimization so every possible link
> spreads info. This is a "bandwith wasting does not care" approach. To limit
> ridiculous high bandwith wasting, we use higher spread rates in near
> neighborhood (in hops) which is called fisheye (or HSLS? didn't read the
> paper - really the same)?
In theory this should fix routing loops as it is quite important for the
local neighborhood to know the exact data and pretty much irrelevant for
9 hop nodes.
But I fear it needs more analysis and simulation to get more thorough
wisdom about this.
> * The other approach is to throw away "calculation based on input". And use
> measurement instead. This is realized with B.A.T.M.A.N. Constantly flood the
> network with a lot of packets and do the routing based on "where does most
> packets come through". Has some aspects of ant-routing. Works, because Radio
> links always loose packets. Currently - as elektra pointed out - BATMAN is
> superior to OLSR because it does reasonable routing decisions and does not
I'm not following B.A.T.M.A.N. in detail but how much traffic overhead
does this generate?
> * With OLSR every node is aware of the complete network. Which can be used
> e.g. to draw nifty pictures without additional softs installed on every node.
Never underestimate the power of nifty pictures in presentations for the
uninformed and/or clueless. SCNR ....
> This is an advantage: you only need the routing daemon to have the complete
> picture) and nobody can disable this "side effect" without loosing the
... as seen by this one node ....
> function. Or a disadvantage: if network/info grows too large e.g. to a size
> an embedded device cannot handle.
For the last point: Personally I don't think that that will be a real
issue as the size of "embedded devices" are also growing.
And if a mesh net really is too large (how many nodes is that - without
or without other space/CPU savings) for a LinkSys: Is that mesh net
actually usable (or does it break because of too much OLSRD traffic)?
OK, I don't expect an answer to it.
> To come to a end: spreading topo info is the critical thing. The recent OLSR
> implementation changes are done to make is possible to change the info spread
> algo in the near future. As far as I understand it: will be something based
> on a more active role of each node - query for topo / sync answer with
> diffs. But that has to be elaborated by the original coders...
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
More information about the Olsr-dev