Next Generation Nodes - Versionsgeschichte

Erichn: /* Konfigurationsvorschlag: Pseudo-Adhoc OLSRd Combined Routing Node */

2015-11-22T12:54:45Z

‎Konfigurationsvorschlag: Pseudo-Adhoc OLSRd Combined Routing Node

Erichn: /* Konfigurationsvorschlag: Pseudo-Adhoc OLSRd Combined Routing Node */

2015-11-22T12:50:49Z

‎Konfigurationsvorschlag: Pseudo-Adhoc OLSRd Combined Routing Node

Erichn: /* Konfigurationsvorschlag: Pseudo-Adhoc OLSRd Combined Routing Node */

2015-11-08T12:46:25Z

‎Konfigurationsvorschlag: Pseudo-Adhoc OLSRd Combined Routing Node

Erichn: /* Konfigurationsvorschlag: Pseudo-Adhoc OLSRd Combined Routing Node */

2015-11-08T12:45:18Z

‎Konfigurationsvorschlag: Pseudo-Adhoc OLSRd Combined Routing Node

Erichn: /* AP/Sta statt Adhoc */

2015-11-08T12:16:15Z

‎AP/Sta statt Adhoc

Erichn: /* Vorwort */

2015-11-08T11:39:07Z

‎Vorwort

Erichn: /* Vorwort */

2015-11-08T11:35:46Z

‎Vorwort

Matthias: Vorschlag auto-x …

2014-04-14T09:17:04Z

Vorschlag auto-x …

Erichn: /* OLSRv2 */

2013-11-28T12:01:08Z

‎OLSRv2

Erichn: /* Software */

2013-11-28T10:53:31Z

‎Software

@@ Zeile 92: / Zeile 92: @@
 ''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äß [http://www.ipv6.wien.funkfeuer.at/ 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.
+* 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.

@@ Zeile 92: / Zeile 92: @@
 ''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äß [http://www.ipv6.wien.funkfeuer.at/ 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. Als IP-Adresse kommt bei jedem (sic!) derartigen Master die private IPv4-Adresse 172.16.16.16/32 zum Einsatz. Als IPv6-Adresse kann eine offizielle IP oder eine noch zu definierende öffentliche IP aus dem 0xFF-Subnetz gewählt werden, mit der eine Anycast-ähnliche Funktion nachgebildet wird. 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.
+* 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.

@@ Zeile 93: / Zeile 93: @@
 * 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äß [http://www.ipv6.wien.funkfeuer.at/ 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. Als IP-Adresse kommt bei jedem (sic!) derartigen Master die private IPv4-Adresse 172.16.16.16/32 zum Einsatz. Als IPv6-Adresse kann eine offizielle IP oder eine noch zu definierende öffentliche IP aus dem 0xFF-Subnetz gewählt werden, mit der eine Anycast-ähnliche Funktion nachgebildet wird. 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.
-* 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.
+* 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:

@@ Zeile 99: / Zeile 99: @@
 * Es wird der Adhoc-Mode bestmöglich nachgebaut.
 * Es kann eine Wien-weite ESSID eingeführt werden. (siehe auch Nachteile)
 Nachteile des Konzepts:
@@ Zeile 105: / Zeile 106: @@
 * 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.

← Nächstältere Version		Version vom 8. November 2015, 12:16 Uhr
Zeile 86:		Zeile 86:
	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).		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.		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äß [http://www.ipv6.wien.funkfeuer.at/ 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. Als IP-Adresse kommt bei jedem (sic!) derartigen Master die private IPv4-Adresse 172.16.16.16/32 zum Einsatz. Als IPv6-Adresse kann eine offizielle IP oder eine noch zu definierende öffentliche IP aus dem 0xFF-Subnetz gewählt werden, mit der eine Anycast-ähnliche Funktion nachgebildet wird. 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.
		+	* 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.
		+
		+	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)
		+
		+	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.

@@ Zeile 10: / Zeile 10: @@
 * 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.|http://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf]'', "Establishing Mobile Ad-Hoc Networks in 802.11 Infrastructure Mode" beschrieben wird.
+* anstelle des Adhoc-Mode einen kombinierten AP/Station-Mode verwenden, wie er von [http://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf 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.

@@ Zeile 2: / Zeile 2: @@
 == Vorwort ==
-Auf dieser Seite wird versucht, ein Konzept für "Next Generation Nodes" zu erstellen.
+Der Artikel "Next Generation Nodes" erörtert Konzepte für die Funkfeuer-Mesh-Nodes von Morgen.
-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.
+Er dient zur Sammlung von Ideen, aus denen ein zukunftssicheres und performantes Netz hervorgehen soll.
-Next Generation Nodes sind dadurch charakterisiert, dass sie:
+''Next Generation Nodes'' sind dadurch charakterisiert, dass sie:
-* Routing nur mit IPv6 betreiben.
+* sparsam im Umgang mit IPv4-Adressen sind.
-* 6to4 NAT/4to6 NAT aus Kompatibilitätsgründen bereitstellen und mit nur einer individuellen IPv4-Adresse das Auslangen finden.
+* als IPv4/IPv6 relay fungieren oder
-* [[OLSRv2]] anstelle von OLSR verwenden.
+* dual-stack unterstützen.
-* anstelle des Adhoc-Mode einen kombinierten AP/Station-Mode verwenden, wie er von Wirtz und anderen ''[http://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf]'', "Establishing Mobile Ad-Hoc Networks in 802.11 Infrastructure Mode" beschrieben wird.
+* OLSRv2 oder andere Routingprotokolle nützen.
-* optional auto-provisioning beherrschen, um Node "Hands-off-Software" installieren zu können.
+* anstelle des Adhoc-Mode einen kombinierten AP/Station-Mode verwenden, wie er von ''[Wirtz, Chants et al.|http://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf]'', "Establishing Mobile Ad-Hoc Networks in 802.11 Infrastructure Mode" beschrieben wird.
 * optional auto-updating beherrschen, um Nodes immer im gewählten branch, z.B. "HEAD", "current", "bugfix only" zu betreiben.

@@ Zeile 44: / Zeile 44: @@
 === OLSRv2 ===
-Beschreibung bitte hier einfügen:
+Bei OLSRv2 ''[https://ietf.org/doc/draft-ietf-manet-olsrv2/?include_text=1]'' handelt es sich um einen Entwurf (Draft/Proposed Standard) der The Internet Engineering Task Force (IETF) ''[http://www.ietf.org/]'' und Weiterentwicklung von OLSR ''[http://en.wikipedia.org/wiki/Optimized_Link_State_Routing_Protocol]'' bei folgende Eckpunkte verfolgt werden:
-Quellen:
+* Die Linkmetrik wird auch durch andere Faktoren als nur den Hopcount bestimmt.
-[http://wiki.funkfeuer.at/index.php/OLSR-NG]
+* Wenn Informationen über den Linkstatus vorhanden sind, kann OLSRv2 diese mit einbeziehen.
-[http://www.olsr.org/?q=taxonomy/term/10]
+* Topologiereduktion: Nur Knoten, die als Multipoint Relays (MPRs) fungieren müssen Information zum Linkstatus abgeben.
-[http://olsr.org/?q=node/63]
+* Topologiereduktion und Reduktion des Floodings: MPRs führen zwei Typen von Nachbarn ein: Flooding MPRs und Routing MPRs.
 === AP/Sta statt Adhoc ===

@@ Zeile 19: / Zeile 19: @@
 === Software ===
 Als Betriebssystem kann -wie bisher- OpenWRT verwendet werden, aber theoretisch auch jede andere Distribution, die
-* OLSR-NG/v2 zur Verfügung stellt.
+* OLSRv2 zur Verfügung stellt.
 * Routinen bereitstellt, um einerseits die Funktionalität
 ** eines Access Points (AP), andererseits