On Mon, 2008-09-01 at 18:37 +0900, Nguyen Lan wrote:
> Henning Rogge wrote:
> > On Mon, Sep 1, 2008 at 08:00, Nguyen Lan <nguyentienlan@gmail.com> wrote:
[...]
> >> How OLSR prevents Topology Control messages from packet loss ? Since

It doesn't.

> >> loss of TC message could lead to inconsistent problems in routing table.
> >>     
> > Retransmissions and redundant paths. TCs are flooded through the
> > network, so if you have multiple connections to the net you have more
> > than one chance to hear a TC.
> But TCs are only forwarded by MPR nodes, so I guess it's not always true.

The redundant network paths step in on the next transmission (try).
There is always a compromise between reliability and used bandwidth.

> >  In addition to this TCs are
> > restransmitted periodicly.
> >   
> Yes, I mean routing table is inconsistent at some moments

Routing tables of two hosts may be inconsistent at any time. But that is
not a unique "feature" of OLSR but IMHO of (almost?) all IP-routing
protocols (including the "old ones"  from the cable world like RIP and
OSPF).
In the wireless world, it is just more visible because the latency and
packet loss are (much) larger than on Gbit cables.

The basic problem is that you have rather large networks. As soon as you
implement absolutely synchronous routing tables between an|y 2 hosts,
you have one through the whole network.
I have no idea how slow and sluggish any route change will be.
IMHO you need *at least* some kind of "two-phase commit" (similar to
databases) with all it's drawbacks. And you have to live the "two-phase
commit" over slow and lossy links (and not only - like DBs - on locally
0% loss and quite fast disks).
Actually I don't know if there are any papers on that subject ("reliable
two-phase commit over slow, high-latency, lossy networks" or so) ....

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




