Next Generation Nodes: Unterschied zwischen den Versionen

Version vom 17. November 2013, 13:36 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 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. 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 [3], [4], [5]
5. DNS64 [6]

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?

OLSR-NG

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. 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 für mehr Endgeräte zur Verfügung steht. Wirtz unterscheidet zwischen RONs (ROting Nodes), die beides Modi betreiben, und STANs (Station Nodes), die nur als Client fungieren. In unserem Fall sind vermutlich IRONs (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äß Performanceeinbussen 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, BSSID(der Originaltext spricht von "MAC") und IP-Adresse (wegen Layer 3) benutzt, während auf den STANs keine derartigen Änderungen vorgesehen sind. STANs entsprechen der mobilen Infrastruktur, während RONs eher als statische Punkte gesehen werden.

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 [7] benutzt werden, um die Performance zu steigern. Dies ist allerdings noch auszutesten.