[Olsr-dev] OLSR autoconf plugin
Wed Mar 18 04:29:43 CET 2009
Henning Rogge ha scritto:
>> The basic idea is that each node must flood the network with the list
>> of IP and netmask of all the HNA / OLSR interfaces it has.
> Hello/TC/MID and HNA together should give you a complete view of the network.
> Even if you are only listening.
Basically we should introduce another packet for two main reason:
1) the emission interval: Topology change times have different times
compared to Duplicate Address Detection times. If we use TC, each node
should parse all the tuple in each TC and this can results in an heavy
computation load on nodes. Instead we can send just few "DaD message"
(MAD Message) every minute.
2) When a node receive a TC message it should understand if it is
originated by itself or came from another node with its same IP address.
How can it do?
In this case the only choice is to rely upon sequence number and can be
Moreover, the problem is addressed more specifically (and maybe
theorically) in  .
In particular in  they say:
" However the duplicate address detection is
complicated by the optimizations of the OLSR routing protocol: first,
not all nodes originate TC messages ; second, TC messages might
include only a subset of neighbors ; third, OLSR messages may be
split and as a consequence, an individual TC message from one node
might not include all the topology information that the node should
periodically refresh. Finally, the MPR selection algorithm can be
affected by duplicate addresses, and prevent proper operation of the
MPR flooding mechanism, hence prevent proper propagation of the TCs
used by DAD.
(I don't understand the "finally" issue about MPR flooding, any
clarification? Is it a real issue? does it involve all the message
flooded with OLSR?)
At the end, passive duplicate DaD can be done, but it is more
complicated and inefficient in terms of CPU performance.
>> In the same
>> packet there is an unique id of the node (e.g. IPv6 address, random
>> 128bit string).
> Could be done based on MAC-addresses, a time value and some other stuff
> But if you have a unique id for a node, why not use it as a part of the
> Originator-IP/Router-ID ?
MAC addresses are guaranteed to be unique (in theory). So IPv6 address
that contains the MAC address should be unique too.
If a node extract a random 128 bit string, the probability that two
nodes has the same string is neglectible.
But both of these strings (MAC address or 128 bit string) can not be
used as originator IP address because the host part of an IPv4 address
is long 3 bytes (in a class A subnet).
>> If a node receives an OLSR message with an unique id MINOR than its own
>> one, but that contains some IP address that collide with one of its OLSR
>> interfaces / announced HNA, it must change its OLSR interface /
>> announced HNA.
> Most times your CAN NOT change the HNA because it's an external network. If
> the user has connected his private "192.168.0.1" Network to his mesh could
> OLSR cannot change this address.
We can use DHCP with leasing time of ...30 seconds. In this way, we can
change the HNA every 30 seconds.
We should handle the possibility of put some manually configured HNA.
>> which is the better way to change an HNA or and olsr interface "run-time"?
> You can change the interface addresses (it will become even easier in the
> future because we plan to get rid of these IPs in Hellos/TCs) and you can
> change the Originator-IP/Router-ID of an OLSR node (a little bit more
> difficult without a restart).
In the future Router-ID is guaranteed unique for all the nodes?
More information about the Olsr-dev