[Discuss] Hotspot und Mesh am selben Interface

[David Hopfmueller]

On 04/23/2016 08:49 PM, Erich N. Pekarek wrote:
> Am 2016-04-23 um 16:37 schrieb David Hopfmueller:
>> On 04/23/2016 01:52 AM, Erich N. Pekarek wrote:

Hi,

>>> <https://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf>
>> Die Anforderungen von Nachbar-Knoten und Clients in diesem Konzept
>> stehen einander diametral gegenüber:
> Natürlich tun sie das: das Konzept ist ein Adhoc-Netzwerk Ersatz ohne
> zusätzliches Routingprotokoll mit allen sich daraus ergebenden Konsequenzen.

Doch, ein Routing-Protokoll braucht's schon, das wird nur nicht näher 
spezifiziert: "Hence, the selection of a suited MANET routing protocol 
is out of scope and presents future work."

Auch eine Lösung für das Tracking der roamenden Clients für braucht es: 
"Candidate solutions are proxy-based mobile IP variants or end-to-end 
mobility signaling as employed in HIP".

Zu Deinen nächsten zwei Kilometern ;-) :

Was die Autoren nicht klar spezifizieren, ich aber vermute, ist, dass 
sie mehrere (virtuelle) APs pro RON verwenden: einen für das RON-Mesh 
und einen für die STAs. Darauf deutet hin, dass sie einmal schreiben, 
dass die ESSID immer gleich sein soll (Kapitel 3.3), weiter hinten in 
Kapitel 3.4 heißt es hingegen, dass die ESSIDs der RONs unique sein 
sollen, damit die RONs untereinander nicht automatisch roamen.

Sollte das zutreffen, wäre die IP-Config wieder einfach und Nachteil in 
der zusätzlichen SSID sehe ich eigentlich auch keinen.

>> 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:

Die meisten Routing-Protokolle verwenden eine Router-ID, die zwar wie 
eine IPv4 aussieht, aber keine sein muss, die dem Router zugeordnet ist. 
Bei OLSR muss sie das offenbar sein, könnte aber auch die IP eines 
Loopback-Interfaces sein. Damit wäre man dann unabhängig von 
Interface-IP-Configs.

> Annahme:
> 1. Jede Station mit nur einem Multi-SSID-WLAN-Interface kann immer nur
> mit einem einzigen AP gleichzeitig verbunden sein.

Auch das stellen sich die Autoren anders vor, siehe Kapitel 2: "To form 
the ad-hoc Wi-Fi backbone, each RON associates to APs of multiple other 
RONs."

> 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.

Unter IPv6 wird das bei Link-local-Adressen ja durch Hinzuziehen des 
Interface-Identifiers gelöst. Link-local-Adressen gibt's ja 
grundsätzlich auch unter IPv4 und damit sollten mehrere Interfaces 
denselben Range verwenden können. Ich habe aber meine Bedenken, dass das 
zuverlässig funktioniert, insbesondere OS-übergreifend.

> Wenn Du das sauber auseinander halten willst, dann ist MultiSSID in
> jedem Fall der falsche Ansatz

Einspruch: Wenn die Vorgabe (wie in dem Artikel) ein einzelnes Radio 
ist, ist es IMHO die nächstbeste Lösung. Ansonsten bin ich natürlich bei 
Dir, dass eine Trennung auf Layer 1 vorzuziehen ist.

>> Ü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?

Von "beschleunigend" hab ich nichts geschrieben, das Gegenteil ist der 
Fall. "Wichtige Rolle" war vielleicht ungeschickt ausgedrückt, 
"negativer Faktor" trifft's besser. Dieser Aspekt wird aber eben im 
Artikel gar nicht beleuchtet. Das Optimierungspotential eines 
WLAN-Controllers unter diesem Aspekt ist unter [1] ganz gut zusammen 
gefasst.

> way. ... Access points do not have protocol operations that can
> influence where clients attach to, and whether they will move or not./"

Das ist richtig, allerdings steht einem AP frei, die Station 
rauszukicken und einen Re-Join abzulehnen – was auch (wenn konfiguriert) 
von aktuellen Lösungen so umgesetzt wird, um Sticky-Clients zum 
Übersiedeln zu bewegen, wenn der AP/Controller der Meinung ist, dass das 
von Vorteil ist.

>> Beide Punkte (Overlay und Authentifizierung) lassen sich durch
>> WLAN-Controller lösen.
> 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.

Ich bin ja auch nicht der Meinung, dass es die in MANETs braucht. Ich 
sehe andererseits aber auch keine Notwendigkeit für 
"unterbrechungsfreies" Client-Roaming.

Und von "Poor-man" schreiben sie selber eigentlich nicht. Ich hab das 
Gefühl, dass sie ihre Idee, sämtliche Mesh-Links plus Clients eines RONs 
mit einem einzelnen Radio abzufackeln, für durchaus chic halten, "weil's 
halt geht".

CU,
David

[1] 802.11 WLAN Roaming and Fast-Secure Roaming on CUWN: 
<http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/116493-technote-technology-00.html>