[Berlin-wireless] Roaming mit OLSR

[Smilie]

Meine Mühle arbeitet langsam die Beiträge auf.
Ich fasse zusammen:



Der Anspruch VOIP im Freifunk Mobilfunk-like umzusetzen ist
unrealistisch. Selbst in zusammenhängenden Räumen, wie dem RAW macht es
im Grunde keinen Sinn über Roaming nachzudenken.
Trotz besseren Wissens hat Basti im RAW versucht zwischen Badehaus und
Gerätelager ein Roaming zu realisieren.
Auch Perry hat eines umgesetzt. Also irgendwas spannenden ist scheinbar 
dran.
Was isses nur?
Wenn Roaming in kleinen abgeschlossenen Roaming-Räumen einfach zu
realisieren ist, warum nicht einfach installieren.

1.
Roaming macht also nur dann Sinn, wenn Installation und
Funktion einen geringen Aufwand bedeuten.

2.
Sinn macht es also nur dann, wenn die Roaming-Räume sowieso schon über
einen GW gehen und wenn kein größeres Funkloch in der Coverage liegt.

3.
Es muss nicht unbedingt eine Kabelverbindung über die Router bestehen.

4.
Es können dabei mehrere Konfigurationen verwendet werden.
Perry-style,
batman-style,
kalua-style,
basti-style?



Ich wollte nur noch mal anmerken, dass ich in meiner
Vorstellung Roaming-Räume definiert habe. Ein Roaming-Raum soll ein
Raum sein, in dem ein zusammenhängender Bereich einer Coverage
existiert. Wenn ein Client von einem Roaming-Raum in den nächsten
wechselt, muss er per Definition zwangsläufig durch ein Funkloch.
Bei dieser Gelegenheit wird also die Verbindung unterbrochen. Bei
größeren Lücken muss man auch kein Roaming mehr umsetzen. 
Aber bei näher zusammen liegenden Bereichen, könnte man durchaus über
ein Roaming nachdenken.


Zu deinem Beispiel mit Adlershof und Spandau.
Wie wichtig ist die Information für Adlershof, wenn eine
Strukturänderung in Spandau stattfindet?
Ich könnte mir vorstellen, das dies lokal keinen Einfluss hat.


Eine wichtige Information fehlte mir noch zum Verständnis beim Routing.
Ein Packet wird bei Vorhandensein von mehreren Route-Einträgen immer
zum näher spezifizierten Netz geroutet. Höchste Priorität hat dabei
zwangsläufig das /32er Netz. Was beim Routen geschickt ausgenutzt
werden kann.



Am Sun, 10 Jul 2016 13:31:46 +0200
schrieb Bastian <fly at d00m.org>:

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