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 netplugd (difficult to port); Used ifplugd instead.
• 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).
• 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.
• 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 Google Schoolar, ACM Portal, 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" [1]

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

See Also

For a list of currently available thesis topics see [2]