[ArborMesh] Batman vs OLSR

[Ryan Hughes]

So I was just having some thoughts about Batman vs OLSR.

Batman is a layer 2 protocol - it operates below IP (layer 3), and routes 
based on MAC addresses.

As a result, you can, if you want, end up with a routed network where all 
the nodes seem local.

There are three exciting applications of this:
* DHCP
* mDNS
* Zeroconf Service Discovery

I'm especially excited about DHCP.

Did you know that DHCP was created in such a way that multiple DHCP 
servers can serve on the same network, even if they're serving overlapping 
IP ranges?  It's true!

That means that we could set it up so that routers could discover their 
own IP addresses, and we wouldn't necessarily have to manage them 
centrally.

The thing is that right now, I'm kind of frustrated with nodewatcher. 
There are two reasons for us to use nodewatcher:

1. We need to centrally manage IP address allocations.  Nodewatcher
    provides an interface for this, and gives you a preconfigured router
    firmware.

2. Nodewatcher shows a cool map that gets you excited about your network
    community.  It does this by reading data from OLSR.


But if we were using Batman and DHCP, we wouldn't need to centrally manage 
IP address allocations - we could ship stock firmwares out to routers. 
Some or all of them could have a DHCP server that could allocate addresses 
to new routers as they pop up.

One problem with this scheme is that most wireless networks have 
fragmented, disconnected areas.  If DHCP servers can't hear each other, 
they might end up assigning the same IP address to two different routers.

We could go with a different scheme:  Some number of privileged 
hand-configured DHCP servers, and the DHCP server on each router delegates 
to those servers over unicast IP.  DHCP can do this.

That means that we'd just have to throw up one DHCP server and let it 
allocate addresses for us.


The problem with this scheme is that, if DHCP is delegated to some 
disconnected zone of our network, then a new router can't get an IP 
address if it can't find an internet gateway, because it won't be able to 
talk to the central DHCP server.


So there's tradeoffs.
One thing we could do is do the decentralized DHCP method, but with short 
lease times - like 5 minutes - so that if there's an IP address conflict, 
it won't persist for more than 5 minutes.

Remember, this conflict would only occur if two disconnected regions of 
the network assign the same IP address to two different routers, and then 
later those regions become connected.


So DHCP could manage our IP address allocations.  But it doesn't provide a 
cool map.  People were talking about adding to nodewatcher a feature to 
draw a cool map from BATMAN data, but nodewatcher development is slooow.


But if we do decide to go with DHCP and Batman, then we could can the cool 
map feature for now, stop blocking on getting nodewatcher to work, and 
start setting up radios right quick.



There are other benefits of using Batman: mDNS and Zeroconf service 
discovery.

So, when I set up my laptop, I gave it a hostname:  "drawesome".  From 
any other computer in my home network, I can reach my computer with the 
name drawesome.local.  This is because my laptop runs avahi.  Apples run 
bonjour, and Windows can be made to run Apple's Bonjour.  We are using 
multicast-DNS.

If we were running BATMAN, then we could use this multicast-dns system 
inside our network.  Therefore, if our entire network were cut off from 
internet access, we'd still have some domain names -- we wouldn't have to 
go out to the DNS servers on the internet.


Zeroconf/bonjour/rendezvous also has a notion of "Service discovery".

For example, in my house network, the printer broadcasts its service.  My 
"Empathy" chat program broadcasts my availability to chat.  That sort of 
thing.  Service discovery would be useful on our network as well.

Now, I'm not proposing that we set up mDNS or service discovery to work 
for every client inside the network -- I don't want to hear (or even be 
able to hear!) about your inkjet printer.

I'm talking about servers.  Routers could advertise their services, if 
we're running services on the routers.  But if a person wanted to run a 
webserver on the inside of the network, they could broadcast the website's 
availability using avahi.

If there was a webserver inside the network that didn't broadcast its 
availability, oh well.  People can still access the server, it just 
wouldn't show up in a cool "Services inside the network" splash page that 
I'm imagining we'd run on a webserver in each router, which would read 
avahi for these services.

I'm not sure how a webserver could choose to broadcast its presence, 
though, because I'm only proposing that the avahi run on the layer of the 
routers, and that clients attached to different routers not be able to 
avahi to each other.  I'm not sure how to let webservers advertise but not 
inkjet printers.  I'm sure there's some way, though -- an avahi proxy 
running on the router that the webserver is attached to?


Anyway, this is what I'm thinking about today.  I'm sick of having a 
django application block deployment of this network, and I think this is a 
good way around that.  We could set it up with DHCP, and then later, at 
our leisure, write a cool nodewatcher extension that draws a map using 
batman data.


On Friday, at the hackathon, let's talk about this.

I intend to be at the hackerspace tonight, experimenting with DHCP and 
Batman.

--Ryan