Änderungen

= Grundidee von tata/Tarek =

= Grundidee von tata/Tarek =

Als Grund-Kommunikationsmedium kommt hauptsächlich WLAN 2,4 und/oder 5GHz zum Einsatz.

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

 

=== Layer 2 Organisation ===

=== Layer 2 Organisation ===

Hier ist in 2 schichten zu unterscheiden. Das Layer 2 als Basis zum Verbindungsaufbau zwischen Nodes auf physikalischer ebene und das Layer 2 Mesh Protokoll.

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 ====

==== Layer 2.1 ====

Als Standard kommt IEEE802.11s zu Einsatz. Der verteil gegenüber AD-Hoc(IBSS) Netzen ist die einfachere Implementierung von IEEE802.11s was folglich dazu führt das 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 AD-hoc gar nicht erst reden wenn wir bei bei gluon bleiben wollen.

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 das 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 bei Gluon bleiben wollen.

==== Layer 2.2 ====

==== 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 Routen Qualitäten nahe zu ständig BATMAN-adv nimmt uns eine menge Arbeit bei der Routen Organisation im Layer 2 ab, wenn wir mehrere Batman-adv Gateways haben. In Kombination mit unseren hood-Konzept haben wir somit eine Art Interface geschaffen mit der wir dynamisch nahezu beliebig viele für sich operierende Layer 2 mesh Netze erzeugen können welches und eine hohe Skalierung im Layer 2 ermöglicht.

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 Routen Qualitäten nahe zu ständig BATMAN-adv nimmt uns eine menge Arbeit bei der Routen Organisation im Layer 2 ab. In Kombination mit unseren 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 ein kodiert. 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 Detail fragen die am eigentlichen Konzept nix ändern.

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 ein kodiert. 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 Detail fragen die am eigentlichen Konzept nix ändern.

'''Optionale Erweiterung für die Layer 2 Organisation'''

'''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üsste mit einigen Kriterien belegt werden, wie z.b. das mindesten 2 BATMAN-adv Gateways existieren müssen bevor ein Splitt einer hood entstehen kann.

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 ===

=== Übergang von Layer 2 zu Layer 3 ===

Im neuen Layer 3 Konzept sollen Richtfunkverbindungen und lokale exits Gateways berücksichtigt werden. Dazu kommen wir nun zum Übergang aus dem Layer 2 ins Layer 3. Dies geschieht über sogenannte BATMAN-adv Gateways. Die Gateway Selectirung im Layer 2 erfolgt u.a. aus der announcten Bandbreite (Class 1). Aktuell haben wir in allen hoods nur ein BATMAN-adv Gateway welcher einfach die mögliche Bandbreite seines ETH Ports announced. 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 zum Rechenzentrum internen Switch ist. Interessanter wäre ein gemessener und evtl. gemittelter Wert wie hoch der Durchsatz in Internet ist. Diesen wert kann man dann Statisch fest setzen.

Im neuen Layer 3 Konzept sollen Richtfunkverbindungen und lokale exits Gateways berücksichtigt werden. Dazu kommen wir nun zum Übergang aus dem Layer 2 ins Layer 3. Dies geschieht über sogenannte BATMAN-adv Gateways. Die Gateway selektierung 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 zum Rechenzentrum internen Switch ist. Interessanter wäre ein gemessener und evtl. gemittelter Wert wie hoch der Durchsatz in Internet ist. Diesen Wert kann man dann Statisch fest setzen.

  root@default02:~# speedtest-cli --simple

  root@default02:~# speedtest-cli --simple

  Upload: 144.71 Mbits/s

  Upload: 144.71 Mbits/s

Die announcte Bandbreite ist bei einem einzigen Gateway pro hood natürlich so ziemlich egal, da sowieso immer nur dieses eine Gateway gewählt werden kann.

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.

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.

# Ein direkten exit über eine DSL Leitung.

Zu 1.:

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 announced werden. Als Beispiel bei einem VDSL50 Anschluss dann entweder stumpf 50/10 Mbit oder eben auch hier einen gemessenden Wert Statisch setzen.

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

  tata@codestulle ~ % speedtest-cli --simple

Zu 2.:

Zu 2.:

Bei Richtfunk Verbindungen wird das ganze ein bisschen komplizierter da wir uns hier fragen müssen was genau soll hier announced werden.

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 von 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.

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 auch hier die Gemessene Bandbreite ins Internet announced wird.

Wir gehen Erstmal davon aus, das auch hier die Gemessene Bandbreite ins Internet zur Verfügung gestellt wird.

[[Datei:L2_zu_L3_uebergang.jpeg]]

[[Datei:L2_zu_L3_uebergang.jpeg]]

Um eine Überlastung einzelner annoncierter Batman-adv Gateways zu vermeiden, könnte man in einen Intervall die zur Verfügung gestellte Bandbreite - der aktuell genutzten Bandbreite announcend, also die noch zur Verfügung stehende Rest-Bandbreite. Die [https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen#B.A.T.M.A.N_Gateway_Selection Freifunk franken community hat zufälligerweise schon genau so ein Script gebaut].

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 [https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen#B.A.T.M.A.N_Gateway_Selection Freifunk Franken Community hat zufälligerweise schon genau so ein Script gebaut].

  done

  done

Es würde dazu frühen das, wenn ein Batman-adv Gateway voll ausgelastet ist die annoncierte Bandbreite stark sinken würde und somit andere Gateways mit höher annoncierter Bandbreite bevorzugt werden.

 

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'''

'''Optionale Erweiterung für das Bandbreiten anouncemend'''

Das statische setzen der Bandbreite könnte durch eine dynamische Lösung ersetze werden. Indem der 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. Das würde die Menschliche Komponente an der stelle ausmerzten. Andererseits 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.

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. Das würde die Menschliche Komponente an der stelle ausmerzten. Andererseits 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.

=== Layer 3 Organisation ===

=== Layer 3 Organisation ===