[OLSR-users] data & routing

[lolo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Luke

(spam-protected) wrote:
> I have an important question: does data traffic and routing traffic
> have always the same next hop destination? I.e. MPR node is the
> next hope node for routing traffic, but it's the same for data
> traffic? It's possible that data traffic is sent to another
> neighborn than the MPR?

I will let Andreas and Thomas answer that particular interressant
question. but hey... here what *I* understand from the section 10
of RFC 3626

When a node have to recalculate it's routing table (for whatever reason)
it *can* do the following :

1 - Erase all the entries of the routing table

2 - Every symetric neighbor from the neighbor set is added to the routing
table with hop count h=1 (next hop @ is the node itself or 0.0.0.0)

- -> 3 - Every strict 2-hops neighbor from the 2-hops neighbor set is added
once to the routing table. The next hop that will let join it, is *a*
neighbor already present in the routing table  (That neighbor @ is picked
from the N_neighbor_main_addr field of the current 2-hop-neighbor tupple
being processed). Hop count is set to h wich is set to 2.

4 - For every tupple (T_dest_@, T_last_@) of the node's topology table,
if T_dest_@ is not present in the routing table AND T_last_@ is present
in the routing table *with* a hop count equal to the current value of h,
then add T_dest_@ in the routing table, and choose as next hop @ the
neighbor already present that let join (spam-protected) hop count is h+1.
h is not modified.

5 - Let h=h+1. Repeat step 4 until there is no addition in the routing
table in step 4.

The point is that even if T_last_@ is the address of an MPR joining
T_dest_@ (it's the MPR-MPR Selector relationship), the next hop to
join any of those final MPR can be any of the neighbor elected at stage 3.
And they are not necessary MPR. As each node on the road to the
destination can do the same thing, a whole route can be formed
of nodes that have not been elected as MPR (even for the last hop).

If a node ever wants to use it's MPR set as the only data relayers, at
stage 3, it has to chose while parsing it's 2 hop neighbor set, to discard
the tupple if the next hop is not an MPR, and wait to cycle to the tupple
whose N_neighbor_@ field match one of the node already chosen MPR.

If every node in the network choose to act this way, every data relayer
in the network will have to be an MPR (even the last hop)

That final point may have huge implications...or may not.

How olsrd deals with that issue ?  I don"t know. Andreas, Thomas
and others knows.

The RFC let the implementors choose. But should the implementors
be the "choosers"  ? ;-)

Maybe that could be set has an option if the two behaviour views are
easily "implementable" in future release of olsrd ?

Anyway, HTH ;-)

Laurent

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDE7pxfan7C/p60TARAi91AKCtQJSwqncAGGM1YG03kEvprWpWyQCg0xXB
oqR4t2koWDH+75XU/pfnbX8=
=QRxB
-----END PGP SIGNATURE-----