Subject: [manet] Distance vector routing and adhoc

From: "Christophe Jelger" <[email-masked]>
Date: Fri, 27 Jun 2003 09:29:31 +0200

Hi all,

I am relatively unfamiliar with some aspects of adhoc routing and was
wondering if people could point me to some key papers describing the
performance (and potential problems) of distance vector routing in adhoc
networks. I know it is probably not the best way for routing in such
networks but I'd like to know what optimizations have been proposed in order
to increase the efficiency of distance vector routing in adhoc networks. In
particular, I'd like to know if there are some relatively well admitted
methods for optimizations.

Thanks in advance and apologies for the (quite) silly question. ;-)

Regards,

Christophe

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Christophe Jelger" <[email-masked]>
Date: Wed, 2 Jul 2003 10:20:54 +0200

Hi Ryuji and thanks for your answer,

Just a quick remark about routing in BSD when you say :

> About the philosophy, you can configure two routes for a destination on
BSD.
> Check your routing table. sometime the default route is configured as
> follows on BSD.
>    default-route  -> gw global-addr
>    gw global-addr -> gw MAC-addr
>
> One of advantage of this configuration is that even if a neighbor
> node towards a gateway is changed due to movements, the default route
> is not expired. Only the host route is deleted from the routing table.
> Manet node just requests the host route towards the gateway by RREQ.
> The host route may be fixed by local-repair.

While this is correct, note that the gw is directly accessible at the MAC
layer, i.e. the gw is a directly connected neighbor because it is reachable
via its MAC address. This is indeed a "classical" and correct routing entry
with IPv6.

However, this is far too simple. The problem arises when you have :

    default-route -> gw global-addr
    gw global-addr -> next_hop_neighbor addr

This is not so trivial any more ... I did a few testing with BSD and this
kind of entry does not work (with current implementations). While I agree
that it is the best way to record the route to the gateway because only the
host route needs to be changed in case of movements, it requires
modifications in the OS code. This is why I rather advocate the use of a
default route to the next_hop_neighbor to the gateway. This, of course,
leads to a more complicated maintenance of this routing entry, but the good
point is that we can use this mechanism with any OS without having to modify
kernel code. It is the routing daemon job to maintain the default route.
Also note that I only consider this mechanism for proactive protocols. For
reactive protocols, I would rather prefer not to use a default route, and
the gateway should answer to RREQ for nodes outside the MANET.

 Regards,

Christophe

---------------------------------------------------------------
Christophe Jelger - LSIIT           [email-masked]
Université Louis Pasteur
Strasbourg - France                   Tel: +33 (0)3 90 24 45 90

http://www-r2.u-strasbg.fr/~jelger
---------------------------------------------------------------