[Olsr-dev] Freifunk Testing
Sun Jun 15 09:48:57 CEST 2008
no paper on this AFAIK. This is the result of practial implementation, testing
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
* 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)?
* 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
* 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.
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
function. Or a disadvantage: if network/info grows too large e.g. to a size
an embedded device cannot handle.
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...
Am Sonntag 15 Juni 2008 07:53:16 schrieb Jan Groenewald:
> On Sat, Jun 14, 2008 at 10:47:01PM +0200, elektra wrote:
> > Btw: There should be an option to disable the MPR algorithm completely.
> > It is superfluous anyway for Freifunk-like configurations since Wizard
> > of OS 2004. Setting MPR redundancy to 7 in the config is just a dirty
> > hack to get rid of the negative effects of MPR selection and the
> > problems that are growing out of it.
> Is there somewhere we can read why/how MPR is bad for freifunk-like
> /V\ Jan Groenewald
> /( )\ ICT Manager
> ^^-^^ www.aims.ac.za
More information about the Olsr-dev