[Olsr-dev] Idea for small OLSR improvement

Henning Rogge (spam-protected)
Sat Apr 24 14:45:24 CEST 2010


Am Samstag 24 April 2010 12:53:42 schrieb Mitar:
> Hi!
> 
> I got an idea for small improvement in OLSR which I think could
> improve its behavior in practical scenarios. The idea is to leave last
> route node had to last peering node in place and do not remove it. So
> if the node has many peers then there is no difference - OLSR is
> choosing the best route. But once node has only one peering node and
> it decides to remove route to it then I would recommend that we leave
> it in place as it has the highest probability that this same route
> will be restored (especially when nodes have fixed locations). And
> maybe even some packets will get through (not so useful for TCP but
> for UDP this is quite useful, like for streaming or telephony). Of
> course whole mesh should also leave last known path in place so that
> traffic can be routed back. Maybe it will be routed in wain, but maybe
> something will come over.
> 
> If some other peering node gets route then at that time routes are
> rewritten for that peering node.
> 
> With this we do not lose anything in the sense of optimal routing but
> we get a little bit more of robustness.
> 
> (Of course this same laziness technique could be used also for other
> routing protocols.)
When an OLSR node loose it's last neighbor, it normally kills all routes 
(because it's not connected to the mesh anymore).

If you just want to keep the routes from the moment before the connection was 
lost active, we need some kind of memory what kind of routes we "maintained". 
Because if we don't do this, some routes might stay up forever if the target 
left the mesh before we got reconnected (and the route is never set again).

I'm not sure this is easy to do because our route creation/removal is directly 
hardcoded in the dijkstra algorithm.

Henning Rogge

-- 
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100424/c7e0d647/attachment.sig>


More information about the Olsr-dev mailing list