[Olsr-dev] OLSR autoconf plugin

[OrazioPirataDelloSpazio (Lorenzo)]

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.
>   
Hello!
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 
complicated.

Moreover,  the problem is addressed more specifically (and maybe 
theorically) in [1] [2].
In particular in [2] 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? 

Lorenzo




[1]http://manetautoconf.online.fr/Blog/wp-content/draft-weniger-autoconf-pdad-olsr-01.txt
[2] 
http://hipercom.inria.fr/noa-olsr/draft-mase-manet-autoconf-noaolsr-00.txt