[B.A.T.M.A.N.] Improving the roaming procedure: multiple roaming within one orig interval
Hello people,
as some of you may know, batman-adv has client fast-roaming support since version 2011.3.0. This technique has been introduced together with the new client announcement mechanism and it is described on its wikipage[0].
At the bottom of the same it is also written that multiple roaming of the same client within one originator interval are not supported.
Right now I am working on a concept that would enable such possibility. I tried to summarise my ideas on the wiki as well[1] in order to share with you the solution I am thinking about.
The document is still a draft and may not be 100% understandable. If you have time and you are curious enough to read the wiki, please drop me your feedback, it would really be appreciated :-)
Thank you,
[0] http://www.open-mesh.org/wiki/batman-adv/Client-roaming [1] http://www.open-mesh.org/wiki/batman-adv/MultipleRoaming
Hi,
Right now I am working on a concept that would enable such possibility. I tried to summarise my ideas on the wiki as well[1] in order to share with you the solution I am thinking about.
The document is still a draft and may not be 100% understandable. If you have time and you are curious enough to read the wiki, please drop me your feedback, it would really be appreciated :-)
if I understand the document correctly each mesh node a client connects to will send a roaming advertisement back to the last known mesh node this client was connected to. A few questions come to my mind:
* Does this already work with the current code ? If not what happens now ? * How do all nodes get back in sync ? It sounds to me like for certain while a number of nodes claim the same client, right ? Nobody tells the intermediate mesh nodes that their client has moved. * What if receiving a roaming advertisement triggered an immediate (unscheduled) OGM broadcast ? That would potentially speed up the gap and also address the "longer path" problem you outlined in the wikipage.
Regards, Marek
On Thu, May 10, 2012 at 09:12:37 +0800, Marek Lindner wrote:
Hi,
Right now I am working on a concept that would enable such possibility. I tried to summarise my ideas on the wiki as well[1] in order to share with you the solution I am thinking about.
The document is still a draft and may not be 100% understandable. If you have time and you are curious enough to read the wiki, please drop me your feedback, it would really be appreciated :-)
if I understand the document correctly each mesh node a client connects to will send a roaming advertisement back to the last known mesh node this client was connected to.
Yes, this is the idea.
A few questions come to my mind:
- Does this already work with the current code ? If not what happens now ?
Now the ROAM_ADV is still sent to the last known mesh node the client was connected to, but the rerouting mechanism could be broken by other nodes that still think the client is connected to them. (if a client at A roams to B and then to C, B could break the rerouting).
- How do all nodes get back in sync ? It sounds to me like for certain while
a number of nodes claim the same client, right ? Nobody tells the intermediate mesh nodes that their client has moved.
all the nodes will advertise the entry and so all the nodes will delete it, but, eventually, the node that is really serving the client will re-add it and advertise it again. Yap, this must be improved. thank you for pointing it out.
- What if receiving a roaming advertisement triggered an immediate
(unscheduled) OGM broadcast ? That would potentially speed up the gap and also address the "longer path" problem you outlined in the wikipage.
I have to think about that... Imho the OGM should not be the solution, because an OGM have a not negligible prob to be lost. So we should not rely on it.
Thank you for your comments! I'll try to refine the concept a bit more to address the problem you pointed out and then I will post an update here :-)
Cheers,
b.a.t.m.a.n@lists.open-mesh.org
-
Antonio Quartulli -
Marek Lindner