Hallo! Am 2016-04-23 um 16:37 schrieb David Hopfmueller:
On 04/23/2016 01:52 AM, Erich N. Pekarek wrote:Hi Erich,Man müsste folgende Konzept einmal im Detail nachbauen:<https://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf>Ein guter Denkanstoß, aber nachbauen würd ich das nicht wollen.
:) Vielleicht /noch/ nicht. Aber leider werden auch die Antwort-Mails nicht kürzer ;-)
Natürlich tun sie das: das Konzept ist ein Adhoc-Netzwerk Ersatz ohne zusätzliches Routingprotokoll mit allen sich daraus ergebenden Konsequenzen. Ich sehe darin eine Art Poor-Man's-Mesh, denn sauberer und zuverlässiger ist immer noch die Lösung mit mehreren Devices.Die Anforderungen von Nachbar-Knoten und Clients in diesem Konzept stehen einander diametral gegenüber:
Allerdings halte ich die Widersprüche für auflösbar. Die Frage ist nur - mit welchen Mitteln?
Auf Interfaces zu anderen Knoten will OLSR eindeutige IPs, die Clients sollen aber aber immer dieselbe verwenden können.RFC 3626, definiert dafür die "main address" - aka Orginator IP - hilf mir also bitte, das einmal durchzudenken:
main address
The main address of a node, which will be used in OLSR control
traffic as the "originator address" of all messages emitted by
this node. It is the address of one of the OLSR interfaces of
the node.
A single OLSR interface node MUST use the address of its only
OLSR interface as the main address.
*A multiple OLSR interface node MUST choose one of its OLSR interface
addresses as its "main address" (equivalent of "router ID" or "node
identifier"). It is of no importance which address is chosen, however a
node SHOULD always use the same address as its main address.*
Annahme:1. Jede Station mit nur einem Multi-SSID-WLAN-Interface kann immer nur mit einem einzigen AP gleichzeitig verbunden sein. 2. Diese APs werden so gestaltet, dass der Client stets dieselbe Routinginformation (unveränderte ARP-Tabelle hinsichtlich MAC und IP der potentiellen Partner) für Outbound-Traffic/Uplink hat.
Nebeneffekt von 2.:Auf den RONs würde sich ohne zusätzliches Routing-Protokoll das Problem ergeben, dass die stets idente IP einerseits lokal vorhanden ist, andererseits bei einem einen HOP entfernten Nachbarn - der Traffic würde den Router gar nie verlassen.
Hinzutreten von OLSR mit eindeutiger, sich nicht ändernder main ip:Jeder dieser Knoten mit multiplen OLSR-Schnittstellen, hat ja zumindest eine eindeutige IP, die als Originator verwendet wird. Trägt bei Inbound-Traffic aber die Routinginformation als Absender des Linkpartners die Originator-IP, müsste sohin die Anforderung an die Eindeutigkeit erfüllt sein. Die Routing-Tabelle wird wegen der von der Schnittstelleninformation abweichenden, umfassenderen Broadcastadresse mit den externen IPs der Nachbarn bestückt. Die uneindeutige Adresse des AP tritt in den Hintergrund, da der Traffic an die eindeutige IP des Nachbarn laut dessen Main IP adressiert wird. Die auf mehreren Routern quasiidente Schnittstellenadresse wird somit von OLSR-Traffic gar nicht effektiv verwendet. (Bei Stations, die mittels NAT bedient werden, ist es nicht weiter relevant, weil der Traffic ebenfalls über das eindeutig adressierte Interface den Router verlässt.)
Ob das mit dem Orginator-IP wie projektiert funktioniert, das muss erst noch überprüft und getestet werden.
Ich teile Deine Einschätzung, Erich, dass der skizzierte Ansatz zumindest in Verbindung mit OLSR mehr Probleme kreiert denn löst.Das ist eine momentane Einschätzung aufgrund der obigen und vorherigen Überlegungen, auch, da ich mir das mit OLSRv2 noch nicht überlegt habe.
Multi-SSID + ein Overlay-Netz wären IMHO der richtige Ansatz, um diese Anforderungen sauber in den Griff zu bekommen bzw. auseinander zu halten.Wenn Du das sauber auseinander halten willst, dann ist MultiSSID in jedem Fall der falsche Ansatz - schon wegen der Kanalidentität und der Funktionsweise von RTS/CTS und CTS-to-self (Die ESSID spielt nämlich dabei gerade keine Rolle, sondern nur die CTS-Aktivität auf dem Kanal von beliebigen Wifi-Geräten in Reichweite). Mit MultiSSID auf derselben Antenne bei derselben Ausrichtung vernichtest Du mit RTS/CTS entweder jede Menge Airtime, die aufgrund von MultiSSID schon auf dem Gerät selbst rationiert ist oder, Du nimmst Übersprechen in Kauf, womit es zu häufigeren Resends und sinkenden Datenraten kommt.
Wirklich "sauber" können nur pro Link dedizierte Geräte oder Schnittstellen mit möglichst fokussiertem Beam auf überlappungsfreien Kanälen je sein.
Alles andere ist ein Kompromiss zwischen Kosten und Performance.
Übrigens nicht einmal erwähnt wird die Authentifizierung, die beim (schnellen) Roaming eine wichtige Rolle spielt – Verschlüsselung kann man ja auch bei einem MANET-Hotspot wollen.Erläutere das bitte: Wieso soll Authentifizierung beim Roaming eine beschleunigende eine Rolle spielen?
Ich blättere gerade in Matthew S. Gast, "802.11 Wireless Networks - The Definitive Guide²", um für diese Behauptung eine Grundlage zu finden:
S 10 gibt einen Überblick über Arbeitgruppen wie 802.11F, 802.11r. S 182 widmet sich u.a. 802.11i und Key Caching:"/Preauthentication makes roaming a smoother operation because authentication can take place before it is needed to support an association./"
S 183:"/Station software is in control of roaming behavior, and can use that to its advantage. As the station moves in such a way that AP2 appears to be a better choice, it can perform preauthentication to speed up the process of moving over to AP2. Rather than move everything all at once, though, it performs preauthentication to cut down on the interruption between sending network packets./"
Auf Seite 349 und 350 finde ich:"/802.11 places no constraints on how a client device makes its decision on how to move between APs, and does not allow for any straightforward way for the AP to influence the decision. ... [350:] Roaming in 802.11 is entirely driven by client decisions. Where to send the Association Request frames is entirely in the hands of the client system’s driver and firmware, and is not constrained by the 802.11 specification in any way. ... Access points do not have protocol operations that can influence where clients attach to, and whether they will move or not./"
In "802.11n - A survival Guide" finde ich auf Anhieb nichts, was dem widerspricht. Fazit: Roamingentscheidungen treffen Stations autonom, meist aufgrund der SNR, wobei das "big light syndrom" auftreten kann - Stations "kleben" an einem AP, bis fast gar kein Signal mehr über dem Rauschen liegt. Der Schlüsseltausch kann durch Roamingeffekte forciert werden - absichtlich oder als Nebeneffekt. Authentifzierung ist langsam, OPC Key Caching und 802.11i Preauthentication können dies jedoch beschleunigen. Zum Stand der Entwicklung hinsichtlich 802.11r bin ich nicht auf dem Laufenden.
Auf den Seiten 426 und 427 finde ich hingegen eine Bestätigung für die Beschleunigung des Roamings im Ansatz von Wirtz: "/The best way to ensure interoperability between vendors is to select a system that bases roaming and handoff on dynamic VLAN assignment. As stations authenticate, they will retain the same logical point of attachment to the network./" "/Effective roaming requires transparent bridged access, not////routed access, to the link layer at different physical locations. However, roaming////with 802.11 is possible only when access points can communicate with each other to////track the movement of a wireless station./"
Deren Trick umschifft ja Notwenigkeit genau dafür.Wie Du vielleicht weißt, bin ich selbst Kritiker des unverschlüsselten WLANs, verzeih also bitte, wenn ich nun mit Gegenargumenten komme. Die Auswirkungen für Hotspots wären, sofern nicht getunnelt oder Ende-zu-Ende-verschlüsselt wird, dass man insgesamt drei SSIDs benötigte: Station (WPA2-PSK)*, AP(WPA2-PSK)*, Hotspot-AP (eventuell nach IEEE 802.1X), was wieder auf die Performance schlägt und die geforderte Einfachheit unterwanderte. *: Weil Radius ja zuvor die Verbindung zum Radius-Server erfordern würde, aber das vom selben Linknet abhängt...
Die Zeit für Association und Deassociation im unverschlüsselten Netz muss jedenfalls geringer sein, da weniger Routinen durchlaufen werden.
Ich wäre dankbar, wenn Du mir die Hintergründe erklären könntest oder mir Literatur nennen würdest, die dies kann.
Die es im Netz nur punktuell gibt (z.T. noch eine Kostenfrage). Der gegenständliche Artikel soll ja Vor- und Nachteile des Poor-Man's-Mesh thematisieren, nicht zum Kauf von Enterprise grade Hardware motivieren.Beide Punkte (Overlay und Authentifizierung) lassen sich durch WLAN-Controller lösen.
Das geht auf Kosten der Dezentralität – man muss sich halt entscheiden, was einem wichtiger ist. Allerdings ist die Fragestellung in Bezug auf 0xFF ohnehin rein akademisch, da Client-Roaming bei der derzeitigen Knoten-Dichte kein Thema ist.Dezentralität im 0xFF-Netz? - der war gut :-) - unter technischen wie sozialen Aspekten.
Auch die geht freilich auf die Performance. Die einfachste und sauberste Lösung sind multiple Geräte, nicht bloß multiple SSIDs. Als Interimslösung sind sie zulässig und notwendig. Die diskutierten Ansätze sind nicht grundverschieden - nur dass der eine Ansatz sparsam mit IPs umgeht und der andere eventuell nicht den umfassenden Anforderungen an die Netzneutralität hinsichtlich IPv4 entspricht.Insofern ist eine separate SSID mit eigener IPv4 + NAT bzw. einem zusätzlichen IPv6-Prefix auf absehbare Zeit IMHO die einfachste und sauberste Lösung, um Clients anzubinden.
Ich bin sicher, dass jeder der Ansätze Teile zur besten Lösung in sich trägt. Das Thema Hotspot sollte man jedoch mit Skepsis betrachten, aber auch als Chance sehen. Funknetze, wie wir sie bisher kennen, sind ja EOL ;-)Danke jedenfalls für den Input! Das Thema Hotspot soll auch im Rahmen des v642-Projekts wiederbelebt werden, da werden sich diese Fragen sicher stellen.
CU, David
LG Erich
<<attachment: erich.vcf>>
-- Discuss mailing list [email protected] https://lists.funkfeuer.at/mailman/listinfo/discuss
