Eine der anspruchvollsten Aufgaben in einem Netzwerk ist die Verwaltung der Teilnehmer und das Routing von Informationen zwischen diesen. Ist diese Aufgabe in klassischen verdrahteten Netzwerken noch vergleichsweise einfach zu bewerkstelligen, da sich die Netztopologie nur selten ändert und daher in den meisten Fällen statisch behandelt werden kann, herrschen in WLANs sehr dynamische Bedingungen vor. Zu jedem Zeitpunkt kann ein Client dem Netzwerk beitreten, zu einem anderen Zeitpunkt wieder verlassen, oder bei größeren Netzwerken, wie sie z.B. in Firmen und Universitäten vorkommen sogar von einem Zugangspunkt zu einem anderen umziehen.
Bei diesen vergleichsweise komplexen Netzwerken, handelt es sich immer in der Regel um Infrastruktur-Netzwerke, also solche, bei denen ein zentraler Zugangspunkt den Zugriff der Teilnehmer verwaltet, Zeitscheiben für die Datenübertragung zuteilt oder andere Management-Aufgaben, wie die Sitzungsverwaltung übernimmt. Aber nicht in jedem drahtlosen Netzwerk gibt es diese zentrale Instanz. Ein sehr gutes Beispiel hierfür sind sogenannte Ad-hoc-Netzwerke, die wie ihr Name bereits vermuten lässt ad-hoc aus dem Nichts aus aufgebaut werden können. Nehmen an solch einem Netzwerk wenige Clients teil, sehen sich diese in den meisten Fällen und abgesehen von der Vergabe der passenden Netzwerk-Parameter (BSSID, ESSID, IP der Clients, Netmask und Gateway) ist nicht sonderlich viel zu beachten.
Spannender wird es jedoch, wenn nicht mehr alle Teilnehmer jeden anderen sehen und das Ad-hoc-Netzwerk als ein Mesh-Netzwerk zu betrachten ist. Ein Projekt, was sich mit dem Betrieb solcher Mesh-Netzwerke beschäftigt, ist Freifunk, dass in einer ganzen Reihe von Städten bereits meist kleinere, teils aber auch größere Ad-hoc-Netzwerke aufzuweisen hat. In diesen Netzen muss typischerweise jeder am Routing teilnehmen, um ein Datenpaket vom Absender zum Empfänger zu befördern, da es im Gegensatz zu Infrastruktur-Netzwerken kein zentrales Routing gibt und daher sich die Clients untereinander kooperativ um alle Verwaltungsaufgaben kümmern müssen. Die Aufgabe des Routings ist dabei relativ unproblematisch über eine Reihe von Protokollen geregelt, von denen OSPF, OLSR und BATMAN die am Häufigsten eingesetzten sind. Diese funktionieren aber allesamt nur, wenn alle zu routenden Clients sich auch am Protokoll beteiligen und regelmäßig ihre Informationen dem Netz mitteilen.
Ein relativ neuer Weg, der derzeit vom Freifunk Chemnitz beschritten wird, ist es nun, auch Clients ohne Routing-Software den Zugang zum Netz zu ermöglichen. Die hierfür eingesetzte Technik des ARP-Roaming ähnelt ein wenig dem Vorgehen in Infrastruktur-Netzwerken, denn der Client wird von den Routern „verwaltet“ und wenn nötig zwischen diesen umgezogen, wenn sich seine Position im Netzwerk ändert. Damit dies auch ohne Infrastruktur-Modus in einem Ad-hoc-Netzwerk funktioniert, müssen jedoch eine Reihe von Bedingungen erfüllt sein.
Eine der wichtigsten Bedingungen, damit man einen Client ohne Probleme von einem zum anderen Router umziehen kann, ist, dass der Client möglichst wenig davon mitbekommt. Insbesondere der Standard-Gateway sollte aus Sicht des Clients an jeder Stelle des Netzes identisch sein. Zu diesem Zweck wird beim Freifunk Chemnitz im Ad-hoc-WLAN-Teil des Netzes mit einer Anycast-IP für den Standard-Gateway gearbeitet, die unabhängig vom Router, der die Anfrage des Clients empfängt immer identisch ist. Somit entfällt bei einem Handover eines Clients die Umkonfiguration von Netzwerk-Parametern.
Ein weiteres Problem, was sowohl mit dem Routing zusammenhängt, aber auch die Verwaltung der Clients betrifft ist zudem die IP-Adress-Vergabe. Man könnte theoretisch zwar einen zentralen DHCP-Server nehmen und auf Layer 2 (Ethernet-Ebene) routen, hätte dann aber sofort einen Netzausfall, wenn der Client sich in einem Teil des Netzwerkes anmeldet, der gerade keine Verbindung zum DHCP-Server besitzt. Der gegenteilige Weg, also dass jeder Router auch gleichzeitig DHCP-Server spielt, scheint zwar übertrieben, birgt aber andererseits einen Reihe essentieller Vorteile, die man für die Netzwerk-Verwaltung benutzen kann. Damit nun auch ein einzelner, nicht gerade mit dem Rest des Netzwerkes verbundener Knoten noch operativ bleibt, muss jeder der DHCP-Server autark und autoritiv entscheiden können. Da er dies für den gesamten im Netzwerk verwendeten Adressbereich nicht autark tun kann, muss jedem DHCP-Server ein eigener Adressbereich zugeteilt werden, den dieser autonom verwalten darf. Zu diesem Zweck wird der gesamte für das WLAN vorgesehene Adressbereich noch einmal in Subnetze unterteilt. Im Fall von Freifunk Chemnitz handelt es sich hierbei um ein /17-Netz für WLAN, welches in /28-Netze für jeden Router aufgeteilt wird. Da sich einige Clients etwas zickig haben, wenn der DHCP-Server aus einem anderen Subnetz kommt, ist eine der IPs dieses /28-Netzes für den DHCP-Server des Routers zugewiesen.
Wäre noch ein letzter Aspekt kurz zu erwähnen: Nämlich das Backbone-Netzwerk, welches von den Nodes untereinander verwendet wird, um das Netz auch beim Zusammenbruch direkter Funkstrecken (z.B. Sichverbindungen, Richtfunk) über alternative Wege, wie eine VPN-Verbindung über UMTS) am Leben zu halten. Da auch diese Struktur sehr dynamisch sich ändert, wird dieser gesamte Netzbereich (beim Freifunk Chemnitz ein /21) mit OLSR verwaltet.
Somit besitzt jeder Node, der am Routing teilnimmt folgende 4 Angaben:
- Seine Node-IP: z.B. 10.8.40.42
- DHCP-Range: z.B. 10.8.130.144/28
- DHCP-Server-IP: z.B. 10.8.130.145
- Gateway-Anycast: z.B. 10.8.255.254
Diese gehören zu den folgenden 2 Netzwerken:
- Backbone/Routing: 10.8.40.0/21
- WLAN/Roaming: 10.8.128.0/17
Betrachtet man sich das Netzwerk bisher, so ist dieses noch sehr unflexibel: Möchte ein Client umziehen, muss er, trotz dem er an jedem Router Pakete in das Netzwerk senden kann, zum Empfang der Antwort immer in Reichweite des Knotens bleiben, der ihm seine IP zugeteilt hat, da bedingt durch die im Routing bekanntgegebenen Subnetze alle Pakete des WLAN immer wieder zu dem Knoten, der die IP vergeben hat, zurück geroutet werden.
Soviel zum Vorgeplänkel; tut mir echt leid, dass ich etwas ausholen musste, aber der spannende Teil kommt nun!
OLSR bietet nun die Möglichkeit, die an jedem Knoten angeschlossenen „Netzwerke“ – sogenannte Host-Network Associations – bekanntzugeben. Neben ganzen Subnetzen funktioniert dieser Mechanismus nun auch für einzelne IPs, womit es möglich wird, einen Client, der von seinem Heimat-Knoten entfernt im Netzwerk lebt – ähnlich dem Roaming im Telefonnetzen – an seiner fremden Basisstation zu erreichen. Dies funktioniert, weil Hostrouten immer Vorrang vor Netzwerk-Routen haben und diese somit überschreiben.
Wenn man nun einen Client von einem zum anderen Knoten im Netzwerk umziehen kann, ist als letzter Schritt für eine Automatisierung dieses Vorgangs zu sorgen, da der Client möglichst nichts davon mitbekommen soll. Damit man aber von Seite der WLAN-Knoten weiß, dass nun plötzlich ein Knoten in Reichweite ist, muss eine Möglichkeit gefunden werden, die Clients der Umgebung zu beobachten und die Verbindungsqualität zu bewerten. Ein einfacher Ansatz ist derzeit bereits im Netz von Freifunk Chemnitz umgesetzt und betrachtet den Inhalt der ARP-Tabelle der Router als Quelle für neue Clients. Wird dort ein neuer Client entdeckt, wird durch einen ARP-Ping geprüft, ob dieser wirklich in der Nähe ist und im Erfolgsfall als Client im OLSR registriert, um dem Netzwerk Bescheid zu geben, dass dieser Knoten den neu gesichteten Client empfangen kann. Schlegt ein ARP-Ping fehl, so wird nach einem Timeout erneut versucht diesen Client zu erreichen bzw. nach einer einstellbaren Anzahl Fehlversuche der Client als unerreichbar wieder entfernt.
Auch wenn dieser bisher noch recht passive Versuch der Client-Erkennung beim Umzug von Clients eine Reihe kleinerer Nebenwirkungen besitzt, was sich i.d.R. durch Nicht-Erreichbarkeit des Clients äußert, funktioniert dieser Ansatz in der Praxis bereits vergleichsweise gut für das noch sehr frühe Entwicklungsstadium: Immerhin wird hier auf Software-Ebene nachgebildet, was typischerweise die Netzwerk-Hardware erledigt. Weitere Ausbaustufen umfassen daher auch Dinge wie eine verbesserte Erkennung neuer Clients bereits anhand ihres Traffics, bzw. ein dem ARP-Spoofing entlehntes zwangsweises Umziehen des Standard-Gateway für einzelne Clients. Auch eine proaktive Erkennung der Bewegung eines Clients zwischen den Routern und eine dieser Bewegung angepasste vorausschauendes Handover des Clients sind Dinge, die auf der Wunschliste bereits heiß diskutiert werden und in spätere Versionen durchaus einfließen werden. Mehr dazu aber in einem gesonderten Beitrag, da jedes dieser Themen eine ganze Menge Aspekte berührt, die weit über den Umfang dieses Eintrags hinausgehen würden.
