Dynamic routing in OLSR

[Eugeniu Vasilyev]

I've found in docs a next quote:

Presently, OLSR is limited to use with an Ipv4ListRouting object, and does not respond to dynamic changes to a device’s IP address or link up/down notifications; i.e. the topology changes are due to loss/gain of connectivity over a wireless channel

And I supposed that a using OLSR in a wireless mobility network is impossible, because dynamic recomputed routes doesn't work in principle. Is this true? Because a simple test with 2 hops route appearing failed - link down and the second route is not used.
When this feature will repair? How can I work with OLSR in mobility wireless network now? Maybe somehow to use Ipv4GlobalRoutingHelper::RecomputeRoutingTables ()?

[Tommaso Pecorella]

Hi,

perhaps the documentation is a bit cryptic.

The point is: the tuples are removed when their timeout happens. Shutting down a link has no direct effect on the tuples associated with the link itself.

This could seems a big problem, but it isn't for real. If you think about it, when a wireless node goes out of range from one of its neighbors, there's no change in the interface status. It's the routing protocol (through a timeout) that must find out that the neighbor isn't anymore a neighbor.

Reacting to the link up/down status is extremely important for wired links, but it's not that dramatic for wireless. Also because usually a node does have just one wireless link and it's always up.

Hope this makes sense.

T.

[Eugeniu Vasilyev]

Thank you for reply.
But I don't understand fully. For a example, why in wireless network usually have just one up link? I develop application for Airborne Network and link up/down important for me, because network is small.
I was expect heard on my post yes or no. Yes, OLSR dynamically to switch route if I generate traffic with OnOffApplication and PacketSink. Or No, that I wrong to use OLSR and the dynamic routing in wireless network perfect to work and I silly.
Now I understand that all should work and OLSR must switch route if node range out from neighbour, because it's routing protocol. Than I don't understand why doesn't work my test.

P.S. sorry if the attached file has errors. I write post from work and don't have building version. Look at principe. And sorry for my bad english.

Thanks!

[Tommaso Pecorella]

Hi,

maybe I was too simplistic. In "normal" wireless systems you have links always up. An also this needs an explanation.

Link up / down: we're talking about physical net devices. Like when you do a "ifup eth0". It's the ethernet deice to be up or down.

The routing protocol could react to this by purging the routing tables, propagating reachability and so on. RipNg does this, and you can see if a protocol react to ifup / ifdown by checking the implementation of RoutingProtocol's subclass NotifyInterfaceUp and NotifyInterfaceDown. In OLSR these functions are empty.

Note that there are similar functions for address add/removal (e.g., NotifyAddAdress)

It's not that OLSR shouldn't react to these events, it's just that it hasn't been developed to do so. Any addition is welcome.

However, OLSR is an ad-hoc protocol. As a consequence it keeps a L3 "link" state concept (the neighbor tuples). These links are somewhat independent from the status of the physical interface. Of course the phi interface must be up. If it's down, there's no reason to think that the L3 link is up. Still, even if the phi interface is up, the L3 link could be down, e.g., because the neighbor is too far away. As a consequence, all the wireless routing protocols keeps a L3 reachability state (with timers and probes).

Since the tuples are removed after a timeout, even if the protocol doesn't react to the NotifyInterfaceDown, the neighbor reachable thanks to that link will be removed in due time. The protocol is just slower t react to a physical link failure.

Said so, mind that the implementation could have been made thinking to just one wireless link. This is the common scenario for terrestrial ad-hoc systems. Thus, the implementation could reflect that. I'm not the author, so I can't say.

Still, it's not correct to think that the protocol is not "dynamic". It is dynamic with respect to the node's movement and the L3 links changes. The dynamically with respect to PHY links up / down and address changes is not guaranteed.

As an example:

void RoutingProtocol::DoInitialize ()
{
  if (m_mainAddress == Ipv4Address ())
    {
      Ipv4Address loopback ("127.0.0.1");
      for (uint32_t i = 0; i < m_ipv4->GetNInterfaces (); i++)
        {
          // Use primary address, if multiple
          Ipv4Address addr = m_ipv4->GetAddress (i, 0).GetLocal ();
          if (addr != loopback)
            {
              m_mainAddress = addr;
              break;
            }
        }
      NS_ASSERT (m_mainAddress != Ipv4Address ());
    }
  NS_LOG_DEBUG ("Starting OLSR on node " << m_mainAddress);

The node's "main" address is just one and it's initialized at the simulation start. If the node has more than one interface it will have more than one address. Is this a problem ? I don't know.

What happens if the interface with the "main" address goes down ? No idea.

This is why I say that the protocol implementation was made thinking to primarily one always-up interface.

Of course this could be improved. 

Hope this helps,

T.

[Eugeniu Vasilyev]

Thank you very much for depth explanation.
I think that is enough for me.

[Vijay Vasanth]

Hi 

Can You please verify me that ," can I call OLSR has a dynamic Routing protocol"?