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

[code@nsnam.ece.gatech.edu]

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


Gustavo J. A. M. Carneiro <gjcarneiro at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #4 from Gustavo J. A. M. Carneiro <gjcarneiro at gmail.com>  2008-12-02 14:01:07 EDT ---
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.

In my tests, only around simulation time 27s is the new route acquired.  I know
the performance isn't great, but as far as I know it's the way OLSR is.

Closing, please reopen if the fix doesn't work for you, or open a new bug
report if you find any other unrelated problem.


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