[WLANware] DHCP servers and Subnets in Wireless Mesh Networks [Mesh Architecture]

[Naman Muley]

Hi All, Antonio!

First of all, it's an honour to talk to you! :D


On Tue, Nov 6, 2012 at 10:49 AM, Antonio Quartulli <ordex at autistici.org>wrote:

> Hello list, Naman,
>
> On Tue, Nov 06, 2012 at 10:32:34AM -0500, Naman Muley wrote:
> >    Me and a group of undergrads are working on establishing it for
> >    the campus students for now. It will also act as a good research test
> bed
> >    for wireless research. But my major aim is to provide seamless
> networking
> >    inside the campus.
>
> [....]
>
> >      I your end-users are able to run the mesh-software (OLSR or batman)
> on
> >      their devices, then this is no problem, because they can choose a
> fixed
> >      gateway with both applications. If they are just "stupid" dhcp
> clients,
> >      then once again batman-adavanced as a layer 2 protocol would be the
> >      reasonable choice.
> >
> >    So we don't deal with IP handovers at all? Also, here's a major doubt
> that
> >    i had. For technically a mesh network to exist, do all the client
> nodes
> >    have to be mesh nodes / nodes-with-OLSRd ? But I guess, mesh networks
> can
> >    also be used by ISPs to run a network of routers giving services to
> >    clients right?
> >
>
> I was reading on with the BATMAN-adv wikis. I understand the functionality
to an extent. Here's my question with respect to the translation table:
I guess the translation table keeps record of the clients connected to a
particular node. Now, my question is, doesn't this get exhaustive?
Typically looking at my deployment scenario, say a library, or a lecture
theater, will have atleast 400 people at a place. (Not going into load
balancing on one node! ) will the size of the table not become large? I
mean then performing a search operation every time a packet addressing the
client comes and sending it, will that not become time consuming? As I
understand, in the wired counterpart, switches are supported by CAMs which
are fast at search operations but a normal router working on it, won't the
load become overwhelming very quickly?



I think that for the two aforementioned points (seamless roaming and node
> vs.
> client installation) batman-adv can be of help.
> By being a layer 2 mesh networking protocol it handles roaming
> "automatically"
> and in the last versions it also has support for seamless roaming (well, I
> think
> it still has room for improvement). This will leave IP handoff/mobile IP
> out of
> the game: the IP is kept regardless of the node you are attached to, the
> protocol
> will do the rest while the client is simply moving around.
>
>
> For what concerns the node vs. client issue, what you usually want is to
> install the
> routing protocol on nodes only and let the clients be totally un-aware of
> the
> mesh logics. Then you can have handhelds, cellphones or whatever connected
> to the
> mesh.
>
> Ahh yes. thanks.


> This is possible with batman-adv, but also with layer3
> protocols (like OLSRd or Babel): simply because the clients will become
> part
> of the node network segment. However, as already mentioned before my
> reply, with
> batman-adv the (mesh-un-aware) clients will have their DHCP packets
> re-routed in
> a smart way so to choose the best (from the batman-adv metric point of
> view)
> DHCP server. In case of a layer 3 protocol, each node should also run the
> DHCP
> server, unless you think to some a bit more complex solutions.
>
>
> Coming back to say an OLSR implementation, I don't really understand well
enough how will clients move freely if there are multiple subnets. Moving
from one MR supporting one sub-net to another will require an IP handover.
How does this happen in a typical OLSR deployment? Do we have to add some
software to the MRs to support IP handover or OLSR has some mechanism for
that?

Apologies for such conceptual doubts. I have been trying to google this for
a long time.

Naman

> Cheers,
>
> --
> Antonio Quartulli
>
> ..each of us alone is worth nothing..
> Ernesto "Che" Guevara
>
> _______________________________________________
> WLANware mailing list
> WLANware at freifunk.net
> Abonnement abbestellen? -> https://freifunk.net/mailman/listinfo/wlanware
>
> Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung
> unter http://freifunk.net/mailinglisten
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.freifunk.net/pipermail/wlanware-freifunk.net/attachments/20121108/5fd74c92/attachment.html>