View source for BRN-051030-5

=Internet Gateway for BRN=
* Assigned to: Jens Müller

=Abstract=
* BRN networks are usually isolated community networks without connectivity to the outside world. But they may be connected to the public Internet through one or multiple Internet Gateways, which should preferably be entirely self-configuring.
* I want a mesh node to
** determine, if it has a (local) internet connection
** and distribute it (tell other nodes about the connection)
** route packets to available mesh gateways, if necessary
** (hand over connection, if client moves)
* The contribution is to be seen technical.
* Not in my scope???
** Routing via Internet links (but maybe related)
** NAT traversal / Possible problems with NAT

=Personal Knowledge Base=
I'm going to divide my approach into several smaller pieces (keep it modular)
* Discover, if an connection is available (seen from Linux only)
** If an cable is plugged in (what about other foreign wireless nodes; maybe not here, since this can be done in click), I use a notification mechanism (something like hotplug; I think this is already existing), to run a pppoe configuration (if DSL modem was attached) or dhcp client (if ...). Afer this step the mesh node will have set up proper routes. See [http://people.debian.org/~enrico/netplugd.html netplugd] (difficult to port); Used [http://www.stud.uni-hamburg.de/users/lennart/projects/ifplugd/ ifplugd] instead. If a mesh node goes down and comes up again, ifplugd may not run the script. Therefore I need to adjust a startup script. (Use a LED to show, what state the node is in)
* Heuristic to test if the connection is working (with the help of click)
** Sending packets to the Linux Kernel and evaluating the responses is the general procedure. First this will be a ping to google.com or something similar. Later I plan to use the other gateways as destination instead of google.com. But therefore I need to distinguish between NATed mesh nodes and "fullly" connected nodes. And there must be at least one mesh gateway available, if I can't fall bask to google.com. In my first version I use Click's ICMPPingSource to send icmp-echo-requests and receive -replies. It will be easy to write a customized element, which might do a cryptographic challenge response to ensure the connectivity between mesh nodes via foreign networks. Later a metric (decribing the mesh gateway's connectivity) might be useful. For simplicity, I assume a metric with two distinct values (0 means no connection, infinity means connected).
** People suggested a DNS query to a DNS root server may be better suited. This way we will only have an Internet connection, if we reach a root server. It suggests that Internet connection without a root dns service is no "real" connection. A attacker may still simulate the existing of the root servers. But the motivation is fairly limited. In general, why should an attacker fake a mesh node to believe it has internet connection (maybe sniffing?). A cryptographic methods as suggested above would solve this. The most favored solution would be DNS root servers with cryptographic identities.
** I need to write some compound elements as a generic interface to use one of the methods above. They all share some kind of request and response method.
* Kinds of information (needs to be distributed)
** Ad-based version
*** The "Gateway" element (uses ICMPPinsSource) floods advertisements. An ad contains all known gateways. Other mesh nodes consume those ads and learn in way about mesh gateways.
** DHT-based version
*** We store the information about mesh gateways in a DHT under a key e.g. "gateway". All mesh nodes can modifify the value (a list of mac addresses) of the key "gateway". Therefore we need to be able to lock the key (synchronisation) to avoid information loss.
* GatewaySelector
** The element "GatewaySelector" (uses the element "Gateway") chooses a gateway and adjustes the destination mac address. It needs to care about TCP connections. Thus it should memorize the gateway it used for any connection-oriented protocols. If a client moves (changes the access point) we would lose this information. I propose to store the clients gateway (the gateway it is using at the moment) in the DHT. The "GatewaySelector" just reads the set gateway or examines one, if not set. Another solution might use a Inter Access Point Protocol instead of DHT to examine, what gateway the client is using. But to overcome the whole trouble, we might use a well-known internet service and all gateways connect to this "super" gateway (via tunnels) and the "super" gateway will be the one and only real gateway. Therefore we will have no problems with connections and other things may be handy.
* Further issues
** When to switch the mesh gateway: When do we decide to change the gateway. A change causes open TCP connection to break, which is extremely undesirable.
** Instead of holding the TCP connection, we might handover them to the new mesh gateway. 
** Click's ToHost elements are a bit tricky. See internal wiki [http:// link needs to be added].

* Results so far (reports, experiments downloadable software, ...)
**

=Project Plan: Working Packages=
*  List of tasks, milestones with deadlines, and deliverables


=Literature=
Interesting publications found with [http://scholar.google.com/ Google Schoolar], [http://portal.acm.org ACM Portal], [http://citeseer.ist.psu.edu CiteSeer]
* List of standard/basic papers a ''person skilled in the art'' should have read.
* List of relevant conferences, standards organizations to follow up with.
* "Architecture and Evaluation of an Unplanned 802.11b Mesh Network" [http://www.pdos.lcs.mit.edu/papers/roofnet:mobicom05/roofnet-mobicom05.pdf]
This paper is quite interesting in general. It a case study of the MIT Roofnet. It can be seen as a motivation, since "An evaluation of network performance shows that the unplanned mesh arcihtecture of Roffnet works well: [..] the entire network is well served by just a few Internet gateways whose position is determined by convenience. Compared to a hypothetical single-hop network, Roofnet's multi-hop mesh increases both connectivity and throughput."

=Competition=
* competing technologies, companies/research teams

=Nomenclature=

* A '''station''' is a client associated with the mesh network.
* A '''mesh node''' is a node used to forward frames.
* A '''mesh gateway''' is a mesh node with internet connectivity.

=See Also=
For a list of currently available thesis topics see [http://sar.informatik.hu-berlin.de/research/thesis_proposals.htm]