Next Generation Nodes

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.

Konfigurationsvorschlag: Pseudo-Adhoc OLSRd Combined Routing Node

• Ein OpenWRT-kompatibler Router mit mindestens 8 MB Flash und 32 MB Ram wird vorbereitet.
• Die Paketliste für ein Image umfasst zumindest die folgenden Installationspakete:

collectd-mod-cpu collectd-mod-conntrack collectd-mod-iptables collectd-mod-memory collectd-mod-network collectd-mod-olsrd collectd-mod-cpu collectd-mod-conntrack collectd-mod-iptables collectd-mod-memory collectd-mod-network collectd-mod-olsrd curl kmod-gre kmod-sit ip iperf iputils-tracepath iputils-tracepath6 iw iwinfo luci luci-app-commands luci-app-ddns luci-app-diag-core luci-app-firewall luci-app-olsr luci-app-qos luci-app-statistics luci-base luci-i18n-base-de luci-i18n-commands-de luci-i18n-ddns-de luci-i18n-diag-core-de luci-i18n-firewall-de luci-i18n-freifunk-de luci-mod-admin-full luci-mod-freifunk luci-proto-ipv6 luci-ssl luci-theme-bootstrap snmpd olsrd olsrd-mod-arprefresh olsrd-mod-jsoninfo olsrd-mod-nameservice olsrd-mod-txtinfo olsrd-mod-watchdog opkg qos-scripts socat swconfig tayga tc tcpdump wireless-tools -wpad-mini wpad wpa-supplicant zlib

• Es wird ein AP-Client(Station) eingerichtet: ESSID: [(linkpartner)|wien].funkfeuer.at eingerichtet. Für das daraus entstandene Interface wird eine OLSR-Schnittstelle mit der zugewiesenen öffentlichen IPv4-Adresse angelegt. Optional wird die dem Knoten gemäß IPv6-Konzept eine Adresse aus einem dem Knoten inhärenten IPv6-Hostnet (/64) vorzugsweise eingetragen. Vorzugsweise das zweite verfügbare /64, sodass im Bereich des ersten verfügbaren /64 NAT64 oder ähnliches passieren kann. Dieses Konzept betrachtet abweichend vom damaligen Konzept das Hostnet 20a2:60:100[xx]:[yy]00::/64 als für solche Zwecke reserviert.
• Es wird ein AP (Master) eingerichtet: ESSID [(eigenerknotenname]|wien)].funkfeuer.at. Bridging wird deaktiviert. Bei jedem derartigen Master kommt eine idente MAC-Adresse (BSSID) zum Einsatz (z.B. locally administered: 0A:00:00:FF:00:FF). Damit sollen das Roaming verbessert werden, indem Fluktuationen in der ARP-Tabelle vermieden werden, wenn ein Knoten den AP wechselt. Als IPv6-Adresse kann eine offizielle IP oder eine noch zu definierende öffentliche IP aus dem 0xFF-Subnetz gewählt werden. Alternativ kommt eine Link-lokale Adresse zum Einsatz. In diesem Punkt sind noch Forschungen erforderlich. In OLSR wird auch hierfür je ein eigenes Interface angelegt. Aus der Wahl einer einheitlichen MAC-Adresse ergibt sich allerdings das Problem, dass AP-Pinning also das festlegen auf einen bestimmten AP aufgrund seiner BSSID nicht mehr möglich ist.
• OLSR erhält die Originator-IPv4, die dem IPv4-Client-Interface (0xFF-Jargon "Device-IP") zugewiesen wurde. Damit ist gewährleistet, dass der Knoten nach Außen nur unter dieser Adresse angekündigt wird und die private Adresse nicht ebenso angekündigt wird.

Vorteile des Konzepts:

• Die Routen im Uplink bleiben aus Sicht des Clients stets unverändert, lediglich das Routing in die andere Richtung muss angepasst werden.
• Es wird der Adhoc-Mode bestmöglich nachgebaut.
• Es kann eine Wien-weite ESSID eingeführt werden. (siehe auch Nachteile)
• Über eine ESSID können sowohl Routing als auch die Versorgung von Hotspot-Clients erfolgen.

Nachteile des Konzepts:

• Mögliche PMTU-Probleme, noch zu erforschen.
• Master und Client sind stets auf demselben Kanal. Ändert der primäre Master in einer Kette den Kanal, so wechseln auch die anderen den Kanal.
• Bei einer Wien-weiten ESSID würde der Client meist den Master mit dem höchsten empfangbaren Signalpegel wählen. Es entstünden durch die Wahl unterschiedlicher Kanäle Netzwerk-Fragmente, was bei Flächendeckung kein großes Problem darstellt. Als Workaround kann ein Client an die BSSID (MAC-Adresse) eines spezifischen Linkpartners gebunden werden. Kanalwechsel sind so immer noch möglich. Eventuell bringt die automatische Kanalwahl am Kopf einer Kette Vorteile.
• Abweichende RTS-Thresholds, die bei Clients exponierter Hosts geringer sein sollten als am Master, sind so nur bedingt möglich, RTS-Thresholds (in OpenWRT) stets für das phy gelten, nicht für das jeweilige if.
• Bei Versorgung von Hotspot-Clients neben dem Routing ist MAC-basiertes Traffic-Shaping einzurichten, um das Routing für andere Knoten nicht zu beeinträchtigen. Vorzugsweise sollte ein Hotspot auf einem anderen Gerät laufen.
• Derzeit ist all dies nicht mit AirOS machbar, da nur jeweils ein Modus dort funktioniert.