Next Generation Nodes: Unterschied zwischen den Versionen

Version vom 26. November 2013, 19:53 Uhr

Vorwort

Auf dieser Seite wird versucht, ein Konzept für "Next Generation Nodes" zu erstellen. Dieser Text stellt keine Empfehlung dar, sondern soll Überlegungen zur künftigen Entwicklung bündeln, mit deren Hilfe ein performantes Netz der nächsten Generation gestaltet werden könnte.

Next Generation Nodes sind dadurch charakterisiert, dass sie:

• Routing nur mit IPv6 betreiben.
• 6to4 NAT/4to6 NAT aus Kompatibilitätsgründen bereitstellen und mit nur einer individuellen IPv4-Adresse das Auslangen finden.
• OLSR-NG anstelle von OLSR verwenden.
• anstelle des Adhoc-Mode einen kombinierten AP/Station-Mode verwenden, wie er von Wirtz und anderen [1], "Establishing Mobile Ad-Hoc Networks in 802.11 Infrastructure Mode" beschrieben wird.

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

• OLSR-NG/v2 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. OLSR-NG [2], [3]
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 [4], [5], [6]
5. DNS64 [7]

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.

OLSR-NG

Beschreibung bitte hier einfügen: Quellen: [8] [9]

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 [10] 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.