[Olsr-dev] Client Roaming Plugin

[Markus Kittenberger]

i discussed this stuff today with henning,..

after discussing about various options that are quite complex #2, henning
found a very simple one, which will work nearly as well,..

just send one (or maybe 2-3) hnas #1 with the minimal valid validity time (~
1/16 second) at the old master (as soon as he knows he is the old master
(probably because he received a hna-message from the new master))

this will update (the validity time) and in fact delete the old hna entry
quite fast in the whole mesh

in some cases there might be loops, but in most cases everything works fine
(and fast)

On Wed, Jan 20, 2010 at 10:49 PM, Raphael <(spam-protected)> wrote:

> Hi everybody


>
> I still have some issues with the update on routes because the nodes
> do not communicate directly.
>
> I need help with adding new olsrd messages so that changing routes is
> fast enough to maintain voip-connections.
>

beside the hnas to announce(and "delete") the client

i think you need an additional message type, to announce the mac of the
client, so that new new master will (be able to identify) and use the same
ip for its hna as the old one,
(or you calculate the ip from the mac-address)

Markus

#1 the normal hnas could even run at normal (or better quite normal) hna
interval (and contain the maybe existing static hnas this node has aswell)
(it still would be better to seperate the static hnas from the dynamic
"client" ones, as different vtimes still make sense,..)

BUT the "deletion" hnas should clearly only contain the the hna for this
single client.

#2 the complex solutions with tcs of virtual nodes, slowly changing link
costs and a tunnel between old and new master try to
A work aorund intermittent loops
-> but it might be better to start with a simple approach to find out how
many loops will actually happen *G
B the fact that an hna can`t be deleted
-> and sending hna messages to reduce the actual validity time of this hna
to 1/16 second, is extremely close to being able to delete it directly
---> it makes no sense to complicate things to gain 1/16 second
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100122/dde098d1/attachment.html>