[Ns-bugs] [Bug 415] OLSR's broken dynamic behaviour?

code@nsnam.ece.gatech.edu code at nsnam.ece.gatech.edu
Wed Dec 3 09:32:33 PST 2008


http://www.nsnam.org/bugzilla/show_bug.cgi?id=415





--- Comment #5 from Gustavo J. A. M. Carneiro <gjcarneiro at gmail.com>  2008-12-03 12:32:33 EDT ---
(In reply to comment #4)
> http://code.nsnam.org/ns-3-dev/rev/8658841e4782
> 
> Details of changes are in the log message.  It should be easy to backport the
> patch to ns-3.2.
> 
> I should warn, though, that it takes a very long time for OLSR to redirect the
> flow through the new path.  This is kind of a pathological case, I guess.  In
> this network, normally none of the nodes are MPRs and so they do not ever emit
> TC messages.  At second 15 a link comes down, and the following has to take
> place before the new route is acquired:
> 
>   1- OLSR only notices the link is down after 3 lost HELLOs, i.e. 6 seconds;
> 
>   2- Only in next HELLO that node 2 sends (up to 2 seconds wait) will node 2
> inform node 1 that it (node 1) has been selected as MPR of node 2;
> 
>   3- In the next TC emission time (wait of up to 5 seconds) node 1 will finally
> send its first TC;
> 
>   4- Node 2 finally receives a TC and now has the topology information needed
> to compute a route to node 0.

Well, actually I just realized that OLSR supposedly computes routing table also
from two hop neighbors, so in theory the time without correct route should be
only 6 seconds (3 HELLO intervals), not 11 seconds.  I must be missing
something, but unfortunately have no time right now to look in more detail.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the Ns-bugs mailing list