Next Generation Nodes: Unterschied zwischen den Versionen

Version vom 8. November 2015, 12:39 Uhr

Vorwort

Der Artikel "Next Generation Nodes" erörtert Konzepte für die Funkfeuer-Mesh-Nodes von Morgen. Er dient zur Sammlung von Ideen, aus denen ein zukunftssicheres und performantes Netz hervorgehen soll.

Next Generation Nodes sind dadurch charakterisiert, dass sie:

• sparsam im Umgang mit IPv4-Adressen sind.
• als IPv4/IPv6 relay fungieren oder
• dual-stack unterstützen.
• OLSRv2 oder andere Routingprotokolle nützen.
• anstelle des Adhoc-Mode einen kombinierten AP/Station-Mode verwenden, wie er von Wirtz, Chants et al., "Establishing Mobile Ad-Hoc Networks in 802.11 Infrastructure Mode" beschrieben wird.
• optional als Hotspot funktionieren können.
• optional auto-provisioning beherrschen.
• optional auto-updating beherrschen, um Nodes immer im gewählten branch, z.B. "HEAD", "current", "bugfix only" zu betreiben.

Spezifikationen

Hardware

Jeder Router, der in der Lage ist, gleichzeitig an mehreren Netzen teilzunehmen, sei es durch

• Bereitstellung dedizierter Schnittstellen oder
• Unterstützung von virtuellen Drahtlosschnittstellen (VAP) in der Kombination: mindestens ein Access Point und mindestens eine Station.

Software

Als Betriebssystem kann -wie bisher- OpenWRT verwendet werden, aber theoretisch auch jede andere Distribution, die

• OLSRv2 zur Verfügung stellt.
• Routinen bereitstellt, um einerseits die Funktionalität
  • eines Access Points (AP), andererseits
  • einer Station (STA) bereitzustellen.

Eine beispielhafte Softwareausstattung umfasst:

1. OpenWRT
   1. Kernel: kmod-ipv6, kmod-ipip, kmod-gre; kmod-iptables etc.
2. OLSRv2 [1]
3. WLAN-bezogen:
   1. hostapd/wpad (nach Möglichkeit mit Unterstützung für WPA/WPA2)
   2. Unterstützung für Radius/WPA(2) Enterprise, 802.1X (im Falle des Aufbaus eines zentralen Hotspot-Portals)
4. Tayga [2], [3], [4]
5. DNS64 [5]

IPv6

Hard- und Software soll in der Lage sein, IPv6 sinnvoll einzusetzen. Durch Tayga [s.o.] können IPv4 fähige Knoten angebunden werden.

• Bitte ergänzen, wie konkret das aussehen kann
• Wie funktioniert das Zusammenspiel: OLSR,OLSR-NG in dieser Situation; HNA-Ankündigung? Tunnel? Separate OLSR-Inseln?

Für erste Testläufe genügen link-lokale IPv6 Subnetze. In weiterer Folge wird es erforderlich sein, für die Verwendung von NAT64 geeignete Mappings im vorläufigen IPv6-Vergabekonzept zu definieren und allenfalls ein Präfix (/96) hierfür entweder im 0xFF-Präfix 2a02:60:/29 zu definieren und die einzelnen 1:1 Mappings über HNA anzukündigen oder dies site-lokal innerhalb der zugewiesenen Adressblöcke vorzunehmen oder beides zusammen - je nach Funktionalitätserfordernissen.

OLSRv2

Bei OLSRv2 [6] handelt es sich um einen Entwurf (Draft/Proposed Standard) der The Internet Engineering Task Force (IETF) [7] und Weiterentwicklung von OLSR [8] bei folgende Eckpunkte verfolgt werden:

• Die Linkmetrik wird auch durch andere Faktoren als nur den Hopcount bestimmt.
• Wenn Informationen über den Linkstatus vorhanden sind, kann OLSRv2 diese mit einbeziehen.
• Topologiereduktion: Nur Knoten, die als Multipoint Relays (MPRs) fungieren müssen Information zum Linkstatus abgeben.
• Topologiereduktion und Reduktion des Floodings: MPRs führen zwei Typen von Nachbarn ein: Flooding MPRs und Routing MPRs.

...

OLSRv2 APIPA/Auto-IP Plugin

Henning Rogge (Institut für Kommunikation Informationsverarbeitung und Ergonomie/Fraunhofer) hat ein Plugin für die automatische Vergabe linklokaler Adressen via OLSRv2 geschrieben, dessen Funktiolität sich wie folgt darstellt:

• es vergibt IPv4-linklokale Adressen nur wenn das Interface noch keine IPv4 Adresse hat (und löscht sie wieder wenn der User eine zusätzliche

IPv4 vergibt).

• IPv4-linklokale Adressen werden zufällig gewählt, allerdings wird im ersten Versuch die IPv4 Adresse aus einem Hash der IPv6-linklokalen Adresse errechnet.
• Die Vergabe der IPv4-linklokalen Adressen wird um ein paar Sekunden(aktuell 10) verzögert, damit man Zeit hat die IPv6-linklokalen Adressen der Nachbarn zu lernen.
• Kollisionsdetektion sowohl mit den IPv4-Adressen der Nachbarn als auch mit deren Hash der IPv6-linklokalen Adressen (blockiere nicht die erste Wahl deines Nachbarn!)

Andere Quellen: Implementierung von olsr.org [9] OLSR-NG == OLSR 0.5.x+ [10]

AP/Sta statt Adhoc

Im oben zitierten Aufsatz von Wirtz et. al. wird empfohlen, eine gemischte Umgebung aufzusetzen, die mehr den Fähigkeiten, der auf dem Markt erhältlichen Geräten entspricht. Der Adhoc-Mode wird bei diesen oft nicht oder nur rudimentär unterstützt, und Kompatibilitätsprobleme zwischen verschiedenen Chipsätzen stehen dabei immer noch an der Tagesordnung [Anm: Beobachtungen in der 0xFF-Community beim Mischbetrieb von Broadcomm und Atheros]. Details über den Adhoc-Mode, seine Synchroniserungsmechanismen und Probleme können in Matthew S. Gast, "802.11 Wireless Networks - The Definitive Guide²" nachgelesen werden. Messungen von Wirtz haben ergeben, dass der kombinierte AP/Sta-Modus durchwegs performanter sein kann als Adhoc-Netzwerke und zudem wurde festgestellt, dass diese Modi für mehr Endgeräte zur Verfügung stehen, während der Adhoc-Mode eher vernachlässigt wird. Wirtz unterscheidet zwischen RONs (ROuting Nodes), die beides Modi betreiben, und STANs (Station Nodes), die nur als Client fungieren. In unserem Fall sind vermutlich IRONs [Anm: eigene Wortschöpfung] (Intermediate ROuting Ndes) erforderlich, die mit dedizierter Hardware zusätzlich ein Adhoc-Mode-Interface zur Verfügung stellen. Dedizierte Hardware wird deshalb erforderlich sein, das der gleichzeitige Betrieb von Adhoc-Netzen mit einem der anderen Modi erfahrungsgemäß [Anm: in der 0xFF-Community] Performanceeinbussen [Erg: mutmaßlich] jenseits der 20%, die Wirtz beschreibt, mit sich bringt, dies allerdings abhängig von der Umgebung. Wirtz problematisiert bei seinem Konzept das Thema Handover. Damit Stations von einer Übergabe an einen anderen RON auf Layer 2 möglichst wenig mitbekommen, wird auf allen RONs eine einheitliche ESSID, MAC [Anm: laut Originaltext, richtiger wäre hier "BSSID" oder "MAC-Adresse und BSSID"] und IP-Adresse (wegen Layer 3) benutzt, während auf den STANs keine derartigen Änderungen vorgesehen sind. Als Problem wird das Routing zwischen den RONs in Bezug auf die STANs im Falle eines Handovers gesehen, wobei ein dynamisches Layer2- oder Layer3- Routing-Protokoll - wie auch bisher - dieses Problem wohl recht rasch korrigiert. STANs entsprechen der mobilen Infrastruktur, während RONs eher als statische Punkte gesehen werden. Ein weiteres Problem stellt nach Wirtz unter Umständen die Skalierbarkeit der RON/STAN-Kombination dar. Dieses Problem stellt sich de facto wohl auch bei Adhoc-Netzen, ist aber durch Beschränkungen im AP-Mode wohl besser beherrschbar - ein Ansatz wäre die Fähigkeit RSSI-Thresholds oder die Anzahl der verbundenen Stationen zu limitieren, was im Adhoc-Mode so nicht funktioniert; bei gegenwärtigen Ath9k-Treibern führen derartige Limits, die über "iw" gesetzt werden, allerdings zu Fehlermeldungen - hier wird noch weiter nachzuforschen sein.

Abgebildet auf unser bestehendes Netz: RONs sind Backbone/Freebone-Nodes und ein Teil der etablierten restlichen Nodes, während STANs in der Regel Mobilgeräte (Handies, Laptops, etc) sind. Im Zusammenspiel mit IPv6 ist davon auszugehen, dass die größeren Datenmengen (alleine die Header sind länger) über den AP-Mode effizientier übertragen werden können. Unter anderem könnte sogar Frame Aggregation [11] benutzt werden, um die Performance zu steigern, was im Adhoc-Mode keinesfalls empfehlenswert erscheint. Die Richtigkeit dieser Vermutung ist allerdings noch zu belegen.

Zusammenfassung: Bei richtiger Planung könnten die Vorteile von Access Points und Adhoc-Netzwerken zusammengefasst werden, ohne eine unüberschaubare Zahl neuer Probleme zu schaffen. Erhöhte Performanz und Verfügbarkeit stehen im Vordergrund und werden beim Umstieg auf IPv6 unumgänglich sein. Durch die Umstellung würde die Zahl der für solch ein Netz geeigneter Geräte zunehmen und auch ältere Hardware, hier jedoch mit Einschränkungen wiederverwendbar sein, wobei typische Probleme (z.B. mit Ratenkontrollalgorithmen im Adhoc-Mode und bei starkem Noise) umgangen würden. Das Netz wäre wie beim Adhoc-Mode unproblematisch erweiterbar, jedoch kann ein Nodebetreiber im Gegensatz zum Adhoc-Mode wesentlich besser auf Störungen einer Station (Hidden Node Problem) reagieren (z.B. durch Verweigerung der Assoziierung auf MAC-Ebene). Es ist zu erwarten, dass mit einer einzigen Referenz-Konfiguration ein breites Spektrum an Einsatzszenarien abgedeckt werden kann, ohne wie in der Vergangenheit Unterscheidungen hinsichtlich des Betriebsmodus zu treffen.