tunnel

Multicast for OLSR mesh networks: Obamp release by Saverio Proto

Saverio Proto (ZioPRoTo) has the released the olsr OBAMP plugin, that was a freifunk project for the Google Summer Of Code. The OBAMP plugin allows multicast traffic to be forwarded in a OLSR mesh network. OBAMP is an overlay protocol. It first makes a mesh network with overlay links (udp tunnels) between the OBAMP nodes, and then it creates a distribution spanning tree over these mesh links.

This version of the OBAMP protocol, implemented as an OLSR plugin, is a simplified one for Wireless Community Networks, where we assume the nodes to be in fixed positions on the roof of the houses. Protocol features regarding mobility have not been implemented (yet).

To explain how the plugin works consider the scenario in the following figure:

There are 7 routers, where only 5 have the OBAMP plugin working. Router 1 2 and 6 also have an attached HNA network with some hosts.

OBAMP nodes generate OLSR OBAMP_ALIVE messages, these OLSR messages are forwarded in the whole network (also by the nodes that do not understand OBAMP thanks to the OLSR design). Because of the flooding mechanism every OBAMP node has a complete list of all the other OBAMP nodes in the mesh network. Every OBAMP node listens on the UDP port 6226 for OBAMP signalling.

When a OBAMP nodes starts it has 5 timers to periodically start operations:

OBAMP_alive_timer: every obamp node sends alive messages to advertise its presence to the other obamp nodes in the network. In the alive message every nodes states its IP address, and if it has already a tree link or not (we will see later this information is important for the outer tree create procedure).
The OBAMP network must have a member called “Core”, that starts the TREE_CREATE procedure. The core is the node with the smallest IP address. When the list of known OBAMP nodes changes, the Core Election procedure is eventually called.

mesh_create_timer: every obamp node every OBAMP_MESH_CREATE_IVAL evaluates how far the other obamp nodes are and selects a subset of nodes to keep mesh links with. Note that to reduce signalling and to increase scalability, the overylay mesh links are setup only with a subset of the nearest OBAMP nodes. To select the overlay neighbor the OBAMP nodes first calculates the ETX distance of the nearest OBAMP nodes, and the creates overlay mesh links to every node that are far in the range (minETX,minETX+1)

tree_create_timer: the core of the network every OBAMP_TREE_CREATE_IVAL sends a message called TREE_CREATE on its mesh links. The creation of the spanning tree is very similar to the spanning tree protocol. When a TREE_CREATE message is received a OBAMP node enables a tree link with its parent and forwards the TREE_CREATE on the other mesh links. TREE_CREATE messages are generated only by the core and are numbered, so TREE_CREATE received over loops can be discarded.

outer_tree_create_timer: The mesh_create algorithm may create cluster of OBAMP nodes within the network that are disconnected between each other. This happens if there are groups OBAMP nodes that are far from each other. If this happens only the cluster where the Core is present will receive the TREE_CREATE and will receive traffic from the distribution tree. To overcome this problem if in a cluster there are not TREE_CREATE every OBAMP_TREE_CREATE_IVAL the node with the smallest IP in the cluster will make a long mesh link with the nearest node that has at least a tree link. All the necessary information to perform this procedure is diffused in the OBAMP_ALIVE messages.

purge_nodes_timer: checks expire time of various variables, and deletes nodes or tree links in a soft state fashion

The OBAMP nodes will capture the multicast udp traffic from the non-OLSR interfaces, and will forward this traffic encapsulated in the UDP tunnels of the distribution tree. The other OBAMP nodes will forward the traffic in the tree and will decapsulate it on their non-OLSR interfaces. To avoid duplicated packets the data is carried into OBAMP_DATA messages, that are identified by a sequence number, and the OBAMP source node where the traffic has been encapsulated.

In the figure black links represent real radio links, and red links represent overlay mesh links (udp tunnels). Router 1 2 3 and will create a OBAMP cluster, with two mesh links. Router 6 and 7 will create a mesh link between them. Because the mesh_create algorithm does not create a mesh link between the two clusters, the router 6 (supposing it has the smallest IP address in the mesh) will create an outer tree link with Router 3.

So please download the code and use it . If you find bugs please report them to Saverio and in the Sourceforge tracker here: 

http://sourceforge.net/tracker/?atid=681702&group_id=117612&func=browse

Thanks for this great result of the summer. Special thanks also to Nino from ninux.org who was the mentor for this projet.

Links

* http://zioproto.ninux.org/wordpress/2009/08/31/olsrd-obamp-plugin/
* http://gredler.at/hg/olsrd/rev/8e7887c1247f
* http://olsr.org
* http://blog.freifunk.net
* http://ninux.org

The Fonera Pack Story

This blog entry is mainly in english. Sorry for that, but the original recipient (a belgian guy) is very much better in english. Since beginning of 2007, a startup company called "FON" is distributing very cheap (subventioned) WLAN devices: the la-Fonera wireless LAN router. For these, I've created and published an additional software, called the Freifunk-Fonera-Pack available here: http://download.olsrexperiment.de/fonera/ . The Pack offers Freifunk meshing in parallel to the FON function. Obviously, I've missed to explain the different networking modes and hance a posting on our internal berlin mailing list reaches me with a lot of questions. Mario asked me to publish the anwers here.
Hi Steven,
yes I know. There's not enough info about the networking / mode stuff in the ff-fonera-pack readme. OK - I'll try.
Networking Model

Auf dem Weg zum überregionalen Freifunk-Netz

Viele Freifunker kennen das: Man ist der erste und hat keinen Kontakt zur „großen Wolke“. Auch wenn sich einige Freunde in der Umgebung mit anschließen, solange kein Kontakt zur großen Wolke besteht, bleibt das Freifunk-Erlebnis doch ziemlich unspektakulär. Warum also den ganzen Aufwand betreiben und mitmachen? Warum nicht warten, bis sich die Lücke zu zum lokalen Netz schließt?

Um verstreute Netze – kleine und große miteinander zu verbinden, gibt es nun das FreifunkVPN-Projekt. Denn, mittels VPN-Technik ergibt sich die Möglichkeit einzelne Wolken über das Internet mit einem Tunnel zu verbinden und so die Freifunkwolken in einer Stadt und sogar die Netze verschiedener Städte in einem gemeinsamen überregionalen Freifunk-Netz zu vereinen. Dies ermöglicht nun auch den Freifunkern in kleinen Netzen mit größeren Freifunk-Wolken in Kontakt zu treten und so direkt mit entfernten Teilnehmern zu kommunizieren -  ein starker Motivationsschub. Die Frage des Mitmachens wird klar mit „Ja, so schnell wie möglich“ beantwortet.

Auf der WE.FUNK06 ist die Idee nun konkret vorangetrieben worden. Weimar, Leipzig und Berlin setzten sich zusammen und überlegten erste Schritte. Ein Jahr zuvor hatte man an gleicher Stelle erste Überlegungen getroffen, nun konnte die zwischenzeitliche, sehr instabile Kopplung (mit viel NAT gewürzt) deaktiviert werden, mit einer skalierbaren Lösung in Griffweite. Die prototypische Einrichtung der neuen Verbindung folgte noch am selben Wochenende.

Möglich soll die dauerhafte Kopplung der Netze durch die Installation von so genannten VPN’s – Virtuellen Privaten Netzwerken werden. Ein Virtual Private Network ist ein Computernetz, das zum Transport privater Daten ein öffentliches Netz (zum Beispiel das Internet) nutzt. Teilnehmer eines VPN können Daten wie in einem internen LAN austauschen. Die einzelnen Teilnehmer selbst müssen hierzu nicht direkt verbunden sein. Genauso wie einzelne Freifunk-Router in einem lokalen Netz können die „Freifunk-Wolken“ der verschiedenen Städte verstanden werden. Diese können dann durch Links miteinander vernetzt werden. Nicht nur ein stadtweites Netz, sondern ein großes Freifunknetz ist das Ergebnis. Die freien Netze von Weimar und Leipzig konnten bereits experimentell über eine Kabelverbindung per DSL miteinander verbunden werden. Nun soll das Verbund-Experiment dauerhaft weitergeführt werden.

Auch bisher konnte sich theoretisch jeder mit entfernten Netzen über Tunnel und VPN verbinden. Dies verlangte jedoch spezifische Kenntnisse und einen nicht unbeträchtlichen Konfigurationsaufwand. Indem wir einige Server der verschiedenen Freifunk-Netze dauerhaft miteinander koppeln, bestehen die Verbindungen zwischen den Netzen ohne dass Teilnehmer eines Netzes ihren Computer konfigurieren müssen, um gleichzeitig in verschiedenen Netzen präsent zu sein. Die Konfiguration von VPN-Verbindungen auf einzelnen Rechnern zum Beispiel für Audiostreaming entfällt hierdurch. Die Freifunker hoffen nun, dass sie bald in der Lage sein werden die notwendigen Rechnerkapazitäten und DSL-Verbindungen zur Verfügung zu haben, um das Experiment dauerhaft fortzuführen.

Ein detailliertes Bild der Netze und des Verkoppelungsexperiments Weimar-Leipzig gibt es auf http://wiki.freifunk-leipzig.public-ip.org/index.php/NetzkopplungWeimarLeipzig.

(Artikeltext u.a. auf Basis von Egmont)

Syndicate content