[Berlin-wireless] Roaming mit OLSR??

[Bastian]

Hallo,

mal doch mal eine Topology auf, zeichne die diversen Komponenten und
Usecases ein. Achte auf so Sachen wie, Layer2/Layer3, NAT, IPv6...
Auf Hin- und Rückrouten bist du ja selbst schon gekommen.


Wenn ein Client von einem AP zum nächsten wandert, dann muss "alter
traffic", also Packets die noch an den alten AP gehen, an den aktuellen
AP weitergeleitet werden. Das wird solange noetig sein, bis das ganze
Mesh den Topology-Change registriert hat. Ansonsten gibt es Packet-Loss.

Damit Roaming Stadt-weit sauber funktioniert, braucht es eine ziemlich
zentralistische Architektur (zentrale Gateways) inkl. Full-Mesh (via
VPN).

Es darf keine fremden Gateways geben, weil diese ggf. nicht den vollen
Blick aufs ganze Mesh haben.

Es muss innerhalb des Netzes immer echte end-to-end Connectivity gegeben
sein. Also kein NAT durch Plastik-Router.


On 07/10/2016 10:54 AM, smilebef at gmail.com wrote:
> Ich denke trotzdem, dass wir um Roaming nicht herum kommen. 
> * S/U-Bahn
> * wir entwickeln uns weiter, wer weiß was noch kommt

Ach du willst WLAN in der U-Bahn? So richtig mit Internet und Telefonie
im fahrenden Zug, so wie es die Mobilfunk-Provider gerade vor machen?
Und wenn jemand aus der Bahn steigt und vor nem Kichturm steht, dann
soll es ein seamless handover zum Kirchturm geben?


> Ich verstehe noch nicht, wie du die Fälle auf 2 eindampfen kannst.
> Ich fände es besser, wenn wir mit Hin/Rück-Routen argumentieren.
> @Basti Vielleicht könntest du meine Fälle mal kommentieren?
> 
> 
> Fall 1
> Bis jetzt publiziert OLSR den gesamten DHCP-Bereich über HNA.
> Bei einem AP-Wechsel ändert sich die Rückroute.
> -> DHCP-HNA muss sich also individuell und schnell anpassen.

Definiere schnell. Implizit geht es hier nämlich um zwei
OLSR-Topology-Changes. Das HNA vom ersten OLSR-Speaker (aka alter AP)
verringert sich um ein /32 und der neue AP erweitert sein HNA-Set. Das
sind zwei OLSR Updates, die sich im gesamten Mesh verbreiten müssen.
Wieviel Zeit soll vergehen, bis in Spandau die Information über das
Roaming eines Clients in Adlershof angekommen ist? Während dieser Zeit
gibt es Packet-Loss/Routing-Loops...


> Fall 2
> Bei einem AP-Wechsel ändert sich die Hin-Route und damit der GW.
> -> Anycast aller GWs - also alle GWs haben die gleiche IP.

First of all: Anycast ist ein Konzept in gerouteten Netzen. Die 8.8.8.8
ist z.B. eine Anycast IP, die mehrfach im Internet an verschiedene
Maschinen vergeben ist. Das funktioniert fuer stateless protocols ganz gut.
Das default-gateway für Clients kann ruhig immer die gleiche IP haben,
muss dann aber zwangsläufig auch immer die selbe MAC-Adresse haben, weil
sich dein Client und der Gateway ja direkt via Layer-2 unterhalten.

> Bis hier wäre meiner Meinung nach Roaming ohne Streaming erfüllt.

Streaming??

> Fall 3
> Was passiert bei Pfad-Wechsels mit VOIP?
> GW/Port ändert sich aus Sicht des Servers.

Funktioniert nur wenn alle ueber zentrale VPNs online gehen und die
VPN/NAT-Gateways die Topology vom Mesh kennen.
Internet ohne VPN geht dann nicht mehr...

> Fall 3.1
> Wenn alle GWs eines Roaming-Raums über einen zentralen VPN gehen?
> -> Port ändert sich trotzdem
> Denn nur ein Client eines GWs wechselt den GWs
> -> man kann den Port also nicht manipulieren

Was ist ein Roaming-Raum? Wie ist dieser definiert? Nur Router an einem
Standort, die eh mit Kabel verbunden sind? Was ist mit dir und deinem
Nachbarn, wo zwar ein Smartphone beide APs sieht, aber die APs nicht
untereinander Meshen? -> Full-Mesh via VPN...

> Fall 3.2
> Man stellt sicher, dass sich der GW nicht ändert.
> -> Dann müssten alle GWs bei den keine direkte Route möglich
> ist, über VPN verbunden werden und den Trafik regeln.
> Fall 2 würde hinfällig.

Und schon hast du ein total zentrales Diktator-Mesh gebaut. Alle Router
müssen wegen den Roaming-Regeln mitspielen, keine "fremden" Gateways,
kein Traffic ohne VPN. Siehe typische batadv/gluon/supernode
Architektur... :/

> Fall 4
> Hybrid-Netz mit batman oder auch Mesh-Netz.
> -> hier wird es kompliziert
Es ist jetzt schon kompliziert....

IMHO liegt die Zukunft in OLSRv2 mit source-specific Routing. Damit
erhalten wir zumindest eine dezentrale Architektur und erlauben Traffic
ohne VPN...

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160710/fe06ff0e/attachment.sig>