[olsr-dev] MRP selection (all OLSRd versions)

[Andreas Tønnesen]

Hey Sven-Ola,

The only way MPR selection has any impact on regular data routing(remember
MPRs are only used to forward OLSR packets, and has no effect on regular
data forwarding) is by the effect of the TC redundancy set in nodes. This
value specifies if a node should announce all links or just MPRs(selected
or selectors). As I have understood it, most uses of OLSR LQ sets TC
redundancy to max(which will be the default value in 0.5) so that all
links in the network are known to all nodes, meaning that MPR selection
has no impact on route selection.
Now since MPRs are only used for forwarding OLSR control packets, not
regular data traffic and it has no effect on routes being chosen as long
as you use TC redundancy 2, I don't think changing the MPR selection would
yield the results you want unless I missunderstand something(which I very
well might do :-) ).

- Andreas


> Thomas, Andreas,
>
> while I do not want you guys to disturb while playing with new features, I
> have a moderate urgent bugfix request. Normally, I would do it for my own,
> but this one evt. needs some internal data changes and I am not too
> familiar
> with that.
>
> OK. I am not happy with the MPR selection done in LQ and in RFC mode.
> Investigated only the lq_mpr() so far, but the RFC mprselect() may do it
> the
> same way. With multihomed hosts (nodes with more than one radio or nodes
> bound to ether backbones and wifi) at least *one* MPR should be selected
> on
> each interface. Otherwise inter-suburb routing may be dead / unrealiable /
> really slow.
>
> Example: We connect 2 suburbs with a long distance managed link running on
> a
> double radio node. Other radio is Ad-Hoc. If all MPRs (due to LQ/ETX
> values)
> are selected on the Ad-Hoc radio, no routing info is tranmitted over the
> managed link. Same for RFC, if e.g. all AdHoc neighbours have high
> willingness values configured. Very slow routing happens, if a really
> unreliable ad-hoc parallel link exists between those suburbs.
>
> Investigated the code in lq_mpr(). There is a chance, that more than
> MPRCoverage MPRs are selected (due to hashing) but I would call that a
> feature not a bug. More neighbours, more MPRs. Thats OK :) But at least
> one
> MPR for every interface - that code does not guarantee this.
>
> Comments?
>
> LG
> Sven-Ola
>
>
>
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
>