Grundidee von tata/Tarek

Als Grund-Kommunikationsmedium kommt hauptsächlich WLAN 2,4 und/oder 5GHz zum Einsatz, daher gehe ich hier von den genannten Medien hauptsächlich aus.

Layer 2 Organisation

Das Layer 2 ist in 2 Teilschichten zu unterscheiden. Das Layer 2.1 als Basis zum Verbindungsaufbau zwischen Nodes auf physikalischer Ebene und das Layer 2.2 Mesh Protokoll.

Layer 2.1

Als Standard kommt IEEE802.11s zu Einsatz. Der Vorteil gegenüber AD-Hoc(IBSS) Netzen ist die einfachere Implementierung von IEEE802.11s, was folglich dazu führt, dass wir zukünftig einen höheren Hardware Support daraus gewinnen können. Weitere Verbesserungen wird das IEEE802.11s nicht bringen, evtl. noch minimale Latenzverbesserungen durch die einfachere Implementierung im Treiber. Zudem könnte bereits in der nächsten Gluon Version das IBSS raus fliegen. Daher brauchen wir über eine Basis mit IBSS nicht wirklich reden, wenn wir bei Gluon bleiben wollen.

Layer 2.2

Als mesh Protokoll kommt BATMAN-adv zu Einsatz, dies ist ein Layer 2 mesh Protokoll welches uns hohe Flexibilität bietet. Aufgrund unserer WLAN Infrastruktur ändern sich die Qualitäten der Routen nahe zu ständig. BATMAN-adv nimmt uns eine Menge Arbeit bei der Routenorganisation im Layer 2 ab. In Kombination mit unserem hood-Konzept haben wir somit eine Art Interface geschaffen, mit dem wir dynamisch nahezu beliebig viele für sich operierende Layer 2 mesh Netze erzeugen können welches uns eine hohe Skalierung im Layer 2 ermöglicht.

Abschließend zum Layer 2 kann man sagen, haben wir somit eine flexible und dynamische Möglichkeit entwickelt, mesh Wolken zu erzeugen. diese werden aktuell über unterschiedliche Mesh-IDs/BSSIDs getrennt gehalten und räumlich über Geokoordinaten definiert. diese Informationen befinden sich im sogenannten hoodfile. Das zugehörige IPv4 Subnetz ist in die BSSID einkodiert. Dieses ist für das Layer 2 erstmal uninteressant. Eine andere Möglichkeit ist den Trennung anhand von verschiedenen VXLANs zu erzwingen. Somit ist die Änderung der mesh-ID/BSSID theoretisch nicht mehr nötig. Von der Betrachtung her finde ich die Trennung über das physische IEEE802.11s sauberer und übersichtlicher, als über logische virtuelle Layer 2 Räume wie VXLAN. Das sind aber mögliche Detailfragen die am eigentlichen Konzept nichts ändern.

Optionale Erweiterung für die Layer 2 Organisation

Das jetzige hood Konzept ist ein halb-automatisiertes Konzept welches das manuelle definieren eines hoodfiles erfordert. Eine Möglichkeit der vollen Automatisierung wäre z.b. möglich indem man Voronoi Algorithmen zur automatisierten räumlichen Trennung nutzt. Diese müssten mit einigen Kriterien belegt werden, wie z.b. das mindesten 2 BATMAN-adv Gateways existieren müssen bevor ein Splitt einer hood entstehen kann.

Übergang von Layer 2 zu Layer 3

Im neuen Layer 3 Konzept sollen Richtfunkverbindungen und lokale Exitgateways berücksichtigt werden. Dazu kommen wir nun zum Übergang aus dem Layer 2 ins Layer 3. Dies geschieht über sogenannte BATMAN-adv Gateways. Die Gatewayselektierung im Layer 2 erfolgt u.a. aus der zur Verfügung gestellten Bandbreite (Class 1). Aktuell haben wir in allen hoods nur ein BATMAN-adv Gateway welcher einfach die mögliche Bandbreite seines ETH Ports zur Verfügung stellt. Als Beispiel 1000/1000 MBit für einen Gigabit-Ethernet-Port oder 100/100 Mbit für einen Fast-Ethernet-Port. Das ist nicht ganz so hilfreich, weil es nur eine partielle Bandbreite auf den Weg in das Internet ist. Mit dieser Angabe wird im Grunde nur angegeben, wie gut die Verbindung vom BATMAN-adv Gateway internen Switch des jeweiligen Rechenzentrums ist. Interessanter wäre ein gemessener und evtl. gemittelter Wert, wie hoch der Durchsatz ins Internet ist. Diesen Wert kann man dann statisch fest setzen.

root@default02:~# speedtest-cli --simple
Ping: 26.696 ms
Download: 220.28 Mbits/s
Upload: 144.71 Mbits/s

Die zur Verfügung gestellte Bandbreite ist bei einem einzigen Gateway pro hood natürlich so ziemlich egal, da sowieso immer nur dieses eine Gateway gewählt werden kann. Wenn wir aber jetzt mehrere Gateways Pro hood haben, wird das tatsächlich interessant. Hier gibt es jetzt mehrere Faktoren zu berücksichtigen:

Ein direkten exit über eine DSL Leitung.
Eine Richtfunk Verbindung in eine andere hood.

Zu 1.: Bei einem Node der ein direkten exit über die eigene DSL Leitung anbietet ist es relativ Klar. In diesem falle sollte auch die zur Verfügung stehende Bandbreite des Anschlusses zur Verfügung gestellt werden. Als Beispiel bei einem VDSL50 Anschluss dann entweder stumpf 50/10 Mbit oder eben auch hier einen gemessenen Wert Statisch setzen.

tata@codestulle ~ % speedtest-cli --simple
Ping: 32.393 ms
Download: 37.34 Mbit/s
Upload: 9.21 Mbit/s

Zu 2.: Bei Richtfunk Verbindungen wird das ganze ein bisschen komplizierter, da wir uns hier fragen müssen was genau wir hier zur Verfügung stellen wollen. Eine Internet Verbindung die über die Richtfunk Verbindung erreichbar ist? Oder doch der gemessene wert der rein über die Richtfunk Verbindung möglich ist? Streng genommen würden wir im zweiten falle wie oben schon beschrieben nur eine Partielle Bandbreite ermitteln allerdings geht es bei den Richfunk Verbindungen zwischen den hoods auch eher darum das Lokale Clients/Services erreichbar sind. An dieser stelle ist denke ich noch ein TBD nötig. Wir gehen Erstmal davon aus, das auch hier die Gemessene Bandbreite ins Internet zur Verfügung gestellt wird.

Um eine Überlastung einzelner BATMAN-adv Gateways zu vermeiden, könnte man in einen Intervall die zur Verfügung gestellte Bandbreite - der aktuell genutzten Bandbreite zur Verfügung stellen, also die noch zur Verfügung stehende Rest-Bandbreite. Die Freifunk Franken Community hat zufälligerweise schon genau so ein Script gebaut.

#!/bin/bash
gwsel_lockfile="/tmp/gwsel_lockfile"  # lockfile to allow for low bandwidth settings 

if [ -z "$1" ]; then
        echo
        echo "usage: $0 <network-interface> <update_interval [sec]> <total BW up [Mbit/sec]> <total BW down [Mbit/sec]>"
        echo
        echo "e.g. $0 eth0 60 10 10"
        echo
        exit
fi

while true
do
    if [ ! -e ${gwsel_lockfile} ]; then    # lockfile not present
        # Bandwidth currently used (time averaged)
        R1=$(cat "/sys/class/net/$1/statistics/rx_bytes")
        T1=$(cat "/sys/class/net/$1/statistics/tx_bytes")
        sleep "$2"
        R2=$(cat "/sys/class/net/$1/statistics/rx_bytes")
        T2=$(cat "/sys/class/net/$1/statistics/tx_bytes")
        TkbitPS=$(echo "scale=0; ($T2 - $T1) / 1024 * 8 / $2" | bc -l)
        RkbitPS=$(echo "scale=0; ($R2 - $R1) / 1024 * 8 / $2" | bc -l)
#        echo "BW used      -- up $1: $TkbitPS kBit/s; down $1: $RkbitPS kBit/s"

        # Remaining bandwidth available; cut-off negative values
        Tavail_kbitPS=$(echo "scale=0; if (($3 * 1024 - $TkbitPS) >0) ($3 * 1024 - $TkbitPS) else 0" | bc -l)
        Ravail_kbitPS=$(echo "scale=0; if (($4 * 1024 - $RkbitPS) >0) ($4 * 1024 - $RkbitPS) else 0" | bc -l)
#        echo "BW available -- up $1: $Tavail_kbitPS kBit/s; down $1: $Ravail_kbitPS kBit/s"
    else                                     # lockfile present
        Tavail_kbitPS=0
        Ravail_kbitPS=0
        sleep "$2"
    fi

    for bat in /sys/class/net/bat*; do
              iface=${bat##*/}
              batctl -m $iface gw_mode server "${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit"
    done
done

Es würde dazu frühen das, wenn ein BATMAN-adv Gateway voll ausgelastet ist die zur Verfügung gestellte Bandbreite stark sinken würde und somit andere Gateways mit höher zur Verfügung gestellter Bandbreite bevorzugt werden.

Optionale Erweiterung für das Bandbreiten anouncemend

Das statische setzen der Bandbreite könnte durch eine dynamische Lösung ersetze werden. Indem das Gateway selber schaut wie gut seine Bandbreite ins Internet ist. Das könnte z.b. für Volumen begrenzte oder auch stark schwankende Anschlüsse interessant sein. Auf der anderen Seite kann man das statische setzen der Möglichen Bandbreite auch zur Begrenzung nehmen, falls man nicht den gesamten Anschluss zur Verfügung stellen möchte.

Optionale Erweiterung zur BATMAN-adv Gateway Filterung im RZ

Um zu verhindern das bsp. VPN Router 1 das Rifu 1 Gateway wählt welches nur über das RZ Gateway 1 erreichbar ist müssen die Gateway anouncemend Pakete anderer BATMAN-adv Gateways am RZ Server gefiltert werden. Ansonsten könnte über das RZ Gateway ein anderes Gateway welches eine höhere Bandbreite announce gewählt werden. Das würde zu eine suboptimalen Verbindung führen, da das RZ Gateway ja bereits eine geringere Bandbreite ermöglicht und der Traffic des anderen BATMAN Gateways zwangsweise über das RZ Gateway geroutet werden muss. (Dies beruht auf der Annahmen das die Gatewayselection von BATMAN-adv ein solchen Fall nicht berücksichtigt.)

Layer 3 Organisation

Nun kommen wir aber zum Layer 3. Ich unter teile dies der Übersichthalber in mehrere punkte. Das erste wird die Adressen-zuordnung und Mitname sein. Danach das Routing zwischen den Eizellen Gateways.

Layer 3 Adressenvergabe

Nun zur v4 und v6 Adressenvergabe. Es ist naheliegend das die BATMAN-adv Gateways auch Adressenverteilen dies geschieht aktuell via dhcpd und radvd. Die IP adressrange Vergabe erfolgt aktuell über unser wiki.

Wenn man mit den dhcp Leases am Limit ist, sollte das o.g. Script die Gatewayselection abschaltet wenn nur noch wenige Leases offen sind. Dazu muss die for schleife durch folgenden Teil Ersetzt werden. Dies ist zufälliger weise auch schon bei den Freifunk Frankenern so.:

   for bat in /sys/class/net/bat*; do
             iface=${bat##*/}
             if [ `pidof dhcpd` > "0" ]
             then
                  batctl -m $iface gw_mode server "${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit"
             else
                  batctl -m $iface gw_mode server off
                  /etc/init.d/isc-dhcp-server restart
             fi

   done

Optionale Erweiterung für die Adressvergabe

Die Adressvergabe kann dynamisch gestaltet werden mittels des Einsatzes von ddhcpd. Dies muss aber genauer evaluiert werden, da ich selber keine Erfahrungen mit ddhcpd habe.

Optionale Erweiterung für das hood übergreifende Roaming

Ein Problem wird sein die zugeordneten Adressen bei einem hood wechsel zu erhalten. Das Roaming geht hier kaputt und der Client muss bis zum timeout warten oder sich eine neue Adresse erfragen. Diese Problem können wir evtl. mittels l3roamd lösen, so das auch hood übergreifend das Roaming möglich ist. Auch hier fehlen die Erfahrungen.

Layer 3 Routing

Um Verbindungen zwischen den hoods und lokalen exit nodes zu ermöglichen müssen wir Routing Informationen zwischen den Teilnehmern austauschen. Als Protokoll eignet sich Babel. Babel ist ein loop-avoiding distance-vector routing Protokoll welches double-stack (v6 & v4) kann. Das Protokoll basiert auf den Ideen von DSDV, AODV und Cisco's EIGRP. Das Design von Babel ist allerdings so flexiebel das es sowohl mit Kabelverbindungen als auch mit Funkverbindungen umgehen kann, was ein großer Vorteil für unsere Szenarios ist. Zudem kann Bable auch als Overlay-Netz eingesetzt werden. Zu guter Letzt bietet Babel eine menge Optionen für verschiedene Metriken. Das RFC zur Protokoll Standardisierung findet ihr hier und über Metriken könnt ihr hier was finden.

Diese Grafik stellt eine Grobe Übersicht über ein Theoretisches Netzwerk da. Wir haben jeweils ein RZ Gateway (0 & 1) pro hood. Diese Stelle auch einen Exit ins Internet bereit und haben zudem ein Routing untereinander mittels Babel Protokoll. Die RZ Gateways stellen die Möglichkeit das Router sich via VPN zu den Servern verbinden können um darüber BATMAN-adv zu sprechen. VPN Router (0 & 1) sind einfache Gluon Router, die einen VPN zu den RZ Gateway ihrer hood aufbauen und dort drüber BATMAN-adv sprechen. An den VPN Router (0 & 1) können via mesh weitere Router hängen, diese sind in dem Bild aber nicht weiter dargestellt, da diese Grafik nur eine Grobe Übersicht stellen soll. DSL Exit (1 & 2) sind Lokale BATMAN-adv Gateways und funktionieren vom Prinzip her wie die RZ Gateways. Hier können ebenfalls z.B. via WLAN oder Kabel weitere mesh Router hängen. Zudem Haben die Router DSL Exit (1 & 2) auch noch einen VPN Tunnel zu den RZ Gateways worüber die Babel sprechen. In dem oben gezeigten Beispiel gibt es noch die Router Rifu (0 & 1). Die Rifu 1 hat über das batman-adv Netz eine Layer 3 Route mit Babel zu DSL Exit 1. Um Manipulationen des Layer 3 zu verhindern haben sich die Betreiber der Gateways DSL Exit 1 und Rifu 1 entschieden HMAC, was für Hashed Message Authentication Code steht, einzusetzen. Das ist ein Authentifizierungsverfahren welches dafür sorgt das die Router keine manipulierten Pakete erhalten. Das zugehörige RFC für Babel HMAC findet sich hier. Die Betreiber haben somit weiteren overhead einsparen können da, die Netzwerk Pakete nicht nochmal in eine Tunnel verpackt werden müssen. Über die Richtfunkverbindung können die Client nun auch andere Geräte und ein anderes Subnetz aus der Nachbar Hood erreichen. Wir schauen uns die Hood OL jetzt mal ein wenig genauer an und gucken was theoretisch mit den Clients passiert.

Routing und Adressvergabe Schwerpunkt

In dem Oberen Beispiel Bild sieht man einen genaueren theoretischen aufbaut der Hood OL. Für eine gewisse Übersichtlichkeit gehe ich hier auf v6 nicht ein. Der Hood OL ist das v4 Subnetz 10.18.152.0/21 zugewiesen. Dieses ist unterteilt in 24er Subnetze, wie man der Grafik auch entnehmen kann. Über das 10.18.154er Netz ist nun auch eine Nachbar Hood erreichbar, welche über Richtfunk angebunden ist. Behalten wir die Metrik im BATMAN-adv wie oben besprochen bei, würden alle Clients des Netzes einfach eine Adresse vom RZ Gateway 1 bekommen da dieser eine wesentlich höhere Bandbreite bereitstellt als andere Gateways. Das passiert solange bist alle 254 Adressen des RZ Gateway 1 Netzes aufgebraucht sind und die Gateway anouncmend abgeschaltet wird oder die Bandbreite unter andere BATMAN-adv Gateways singt. Die Bandbreite der RZ Gateway 1 ist nicht real da die Limitierung (Bottleneck) in der Regel am VPN Router und dessen DSL Anbindung liegt. Das heißt der Schwerpunkt der Adressenverteilung liegt somit allgemein bei den RZ Gateways.

Um den Schwerpunkt nun sinnvollerweise mehr in das Lokale Netz zu verlagern, könnte man das Script zum announcen der Bandbreite so anpassen das ein maximaler Schwellwert eingehalten wird. Als Beispiel announcen die RZ Gateways nur noch eine Bandbreite von 5Mbit synchron. Das würde bedeuten das lokale BATMAN-adv Gateways die eine höhere Bandbreite besitzen bevorzugt werden. Somit sind die RZ Gateways eine Art Fallback und dienen als vom Verein gestellte Basis stütze.

Jetzt schauen wir uns mal genauer an, was passiert wenn die RZ Gateways nur eine minimale Bandbreite annoucen. Fangen wir bei VPN Router 0, mesh Router 0 und Client 0 an. Wie man der Grafik entnehmen kann hat der VPN Router 0 eine VPN Verbindung zum RZ Gateway worüber der Router BATMAN-adv spricht. Der VPN Router 0 selber sieht nur das RZ Gateway 1 als BATMAN-adv Gateway. Das liegt daran das andere BATMAN-adv Gateways vom RZ Gateway 1 weg gefiltert werden, da die RZ Gateways eine Sonderrolle vertreten. Das Resultat ist also Das der VPN Router 0 immer das RZ Gateway nehmen wird egal was für eine Bandbreite dieses announce. Am VPN Router 0 hängt via Mesh über das 11s WLAN der mesh Router 0 und dieser Router hat den Client 0 welcher eine Adresse aus dem 10.18.152er Netz bekommt. Für die Gruppe 0 ist also alles super so wie es sein soll. Schauen wir uns nun mal VPN Router 1 an so können wir feststellen das dieser 3 BATMAN-adv Gateways sehen kann: RZ Gateway 1, Gateway Router und Rifu Gateway. Gateway Router anounced 16Mbit und Rifu Gateway eine minimal schlechtere Bandbreite von 10Mbit und RZ Gateway 1 announce wie oben gesagt eine künstlich geringe Bandbreite von 5Mbit. VPN Router 1 Wählt somit also Gateway Router mit einer Bandbreite von 13Mbit. Der Client 1 bekommt somit eine Adresse aus dem 10.18.153er Netz. Analog dazu die Betrachtung von mesh Router 1 und mesh Router 2.

Nun zu VPN Router 2. Dieser sieht ebenfalls die 3 BATMAN-adv Gateways, leider ist die Link Qualität zum Gateway Router semi gut. Da die BATMAN-adv Metrik aus Linksqualität und Bandbreite besteht Entscheidet sich der Router für das BATMAN-adv Gateway Rifu Gateway der Client 3 bekommt somit eine Adresse aus dem 10.18.154er Netz.

Allgemein merkt man nun das der Schwerpunkt nun mehr auf Lokaler ebene sitzt. Wir haben die Kommunikation also auf die Richtfunkstrecken und Lokalen Exit Gateways forcieren.

Die Dezentrale Hood

Das Ergebnis ist somit eine Dezentrale hood in der jeder der es möchte ein Netz anbieten und Routing bauen kann. Leute die einfach nur Router aufstellen und sich mit dem Routing nicht beschäftigen wollen können dies nach wie vor ungestört machen. Babel kann man natürlich ebenfalls ersetzen es können sogar mehere Protokolle eingesetzt werden.

Ein Fallbeispiel ist: Klaus und Peta betreiben jeweils ein Netz. Nun möchte Klaus eine Route zu Petas Netz bauen. Dazu Treffen sich beide auf einen Kaffee und besprechen die Sache, dabei tauschen sie die nötigen Informationen aus wie Klaus an Petas Netz ran kann, Sie gehen also ein peering ein. Es ist quasi der Bau vom Internet. Dadurch das ein Gateway Betreiber mit vielen ein peering eingehen kann ist es auch nicht so einfach möglich einzelne Teilnehmer von netz auszuschließen. Denkt sich Klaus jetzt "Also ne den Peta den mag ich nicht! Ich löse das peering mit ihm auf". So kann Peter immer noch teil des netzes sein da dieser ein peering mit 3 anderen Personen hat.

Technik/Netzkonzept

Inhaltsverzeichnis