Wie das Netz funktioniert
Geschrieben von Administrator   
Freitag, 15. September 2006
Wie ein Wlannetzwerk theoretisch funktioniert..

Wie das Netz funktioniert

1 Das Problem
2 Die Loesung: Routingprotokolle
3 Was OLSR besonders macht ?
4 Wie es praktisch funktioniert

Das Problem

Der IEEE (ein US-amerikanisches Standardisierungsgremium) 802.11 WLAN-Standard ist vorrangig fuer SOHO (small office / home office) und Heimnetzwerke entwickelt worden. Die typische Anwendung ist die Sterntopologie, bei der sich mehrere Clients mit einem Access-Point (AP) verbinden um miteinander und mit dem kabelgebundenen Netzwerk kommunizieren zu koennen. Die einzige Moeglichkeit den Empfangsbereich zu vergroessern, ist der Einsatz einer besseren Antenne, die Erhoehung der elektrischen Sendeleistung an den APs hat zur Folge, das bei groesserer Entfernung der Client den AP empfangen kann, aber nicht genuegend Sendeleistung zum Antworten hat (eine technische Begrenzung aufgrund von gesetzlichen Grenzwerten). Das vollstaendige Ausleuchten ganzer Stadtteile gelingt ausserdem nichteinmal mit sehr grossen Antennen. Um trotzdem eine flaechendeckende WLan-Struktur umsetzen zu koennen, wurde in den 802.11-Standard das Wireless Distribution System (WDS) integriert. Dieses ermoeglicht es, mehrere APs miteinander zu verbinden, um die Reichweite des Netzes zu erhoehen. Dazu muss jedoch jeder AP-Betreiber die MAC-Adressen (Hardware-Adressen) seiner Nachbarn manuell in seinen AP eintragen, was reichlich unpraktisch und wenig nutzerfreundlich ist. Ausserdem ist die Implementation von WDS bei verschiedenen Herstellern unterschiedlich miserabel umgesetzt worden, so dass der scheinbare Vorteil der freien Geraetewahl, trotz der Standardisierung des WDS-Modus, durch Inkompatibilitaeten wieder verpufft. Es ist auch nicht im Standard festgehalten, ob ein AP im WDS-Modus normalen Clienten (wie zB Notebooks) die Verbindung ermoeglichen soll oder nicht. Das alles klingt also nach einer mehr als halbherzigen und umstaendlichen Loesung.

Die Loesung: Routingprotokolle

Damit sich zwei Client-Geraete (zB Notebooks) auch mal spontan ohne AP verbinden koennen, wurde ausserdem der Ad-Hoc-Modus im 802.11-Standard beschrieben. Damit ist es allen Clienten, die auf dem selben Kanal funken und die Selbe BSSID haben, moeglich, direkt miteinander zu kommunizieren, was eine total dezentrale Vernetzung moeglich macht. Der Datenaustausch funktioniert aber nur auf der ersten Ebene, dh., dass nur Geraete, die sich direkt empfangen miteinander kommunizieren koennen.

AP A sieht AP B aber nicht AP C

Als Modell haben wir hier mal unsere APs A, B und C. A und B sowie B und C koennen sich empfangen aber A und C koennen sich nicht direkt empfangen. Die APs A und C wissen nichts voneinander, aber die Menschen hinter diesen APs moechten sich gerne Daten austauschen. Bereits hier setzt das Routing-Protokoll an. Es sorgt dafuer, dass B von der Existenz von C erfaehrt und den Auftrag bekommt, es allen seinen Nachbarn weiterzuerzaehlen. A weiss nun also bescheid, dass C existiert und ein Nachbar von B ist. Ausserdem werden nun alle Daten, welche von A nach C sollen, an B gesendet.

Image

Kommen mehr APs hinzu, wird jeder AP mit mindestens zwei direkten Nachbarn selbst zum Weiterleiter (Router). Somit kann Jeder Daten zu Jedem senden.

Was OLSR besonders macht ?

Die herkoemmlichen Routingprotokolle sind fuer schnelle und zuverlaessige Kabelverbindungen entwickelt worden, die sich selten aendern, also fuer wenig dynamische Netze. Sie arbeiten unter der Annahme, dass eine Leitung endweder existiert oder nicht existiert. In einem Funknetz kommt es aber haeufig vor, dass eine Route kurzzeitig gestoert wird und dass sich einzelne Clients durch das Netz bewegen (Roaming), was das Protokoll mit moeglichst wenig Overhead (Verwaltungsaufwand), guter Geschwindigkeit und hoher Robustheit erledigen sollte. Ein guter Ansatz dazu wurde in olsr.org (Optimized Link-State Routing) gefunden, welches ausserdem noch aktiv entwickelt wurde und noch wird, es ist also eine der wenigen praxistauglichen Open-Source-Implementationen, die es aus der grauen Universitaetstheorie heraus geschafft haben.

In der Praxis angelangt hat man schnell festgestellt, das Informationen ueber die Link-Qualitaet fuer die Routenberechnung in einem WLAN ungemein wichtig sind, da bereits Verbindungen mittlerer Qualitaet Pakete "verlieren". Die Problemloesung wurde mit Hilfe der Berliner Freifunk-Community in Form von ETX (Expected Transmission Count) Ende 2004 nachgereicht. Auch ein Fairness-Algorithmus ist implementiert, der verhindert, dass einzelne APs zu viel Traffic uebergeholfen kriegen, waehrend Andere auf der selben Strecke nicht annaehernd ausgelastet sind, so kann im Bild oben zB der Datenverkehr von C nach F mal ueber D und mal ueber E geleitet werden.

Es existiert nun ein Routing-Protokoll, das selbstorganisierend (die APs finden sich selbst, ohne zutun vom AP-Betreiber) ist, relativ wenig Overhead verursacht, die Eigenheiten von WLAN beruecksichtigt und ganz nebenbei von einer WLAN-Community nach ihren Beduerfnissen entwickelt wird und durch den Open-Source-Charakter bereits auf vielen Plattformen lauffaehig ist, sowohl, was Betriebssysteme, als auch was Prozessorarchitekturen angeht.

Wie es praktisch funktioniert

Wird der AP A also eingeschaltet, broadcastet er an alle in seiner Empfangsreichweite, dass er existiert. Empfaengt AP B ihn, dann wird durch den Austausch von HELLO-Messages vergewissert, dass es sich um einen funktionierenden Link handelt. Damit ist A in der Routing-Tabelle von B eingetragen und hoert damit die Statusnachrichten aller APs mit und verschickt selbst welche. Da diese Statusmeldungen in regelmaessigen Abstaenden von einigen Sekunden verschickt werden, kennt A das gesamte Netz innerhalb weniger Sekunden. Da jede dieser Statusmeldungen die Liste der Nachbarn samt der Verbindungqualitaet zu ihnen enthaelt, ist jedem AP das komplette Netzwerk bekannt, wodurch die Routenberechnung schnell und effizient erfolgt und ueber die Strecke mit der niedrigsten Wahrscheinlichkeit fuer den Verlust des Paketes.

Letzte Aktualisierung ( Montag, 8. September 2008 )