Created an attachment (id=306) [details]
interface setdown patch

OLSR is based on timers.  After bringing down an interface, you have to wait
some time (6 seconds IIRC) until neighbor tuples on that interface expire and a
new routing table is calculated.

Although I would agree a possible optimization is to force the tuple expiration
as soon as the interface comes down.  But I am not sure NS-3 can give the OLSR
agent any kind of notification that an interface has gone down; not without new
core API anyway...

(In reply to comment #2)
> OLSR is based on timers.  After bringing down an interface, you have to wait
> some time (6 seconds IIRC) until neighbor tuples on that interface expire and a
> new routing table is calculated.
> 
> Although I would agree a possible optimization is to force the tuple expiration
> as soon as the interface comes down.  But I am not sure NS-3 can give the OLSR
> agent any kind of notification that an interface has gone down; not without new
> core API anyway...
> 

In the test file attached, the on/off application starts at 10, and stops at 30
sec. (both for the sink and the source). The interface is being setdown at 15
sec. and from 15 sec to 30 sec there is no traffic. According to your comment
there should be traffic from 21 sec to 30 sec., which is not the case.

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.

(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.

Gustavo,

I was/am/will be busy as well. Worst case, we will look to it after Dec. 17
release (either by opening a new bug report or continuing on this bug).

Regards,

Egemen