[Berlin-wireless] Roaming mit OLSR??

[Smilie]

Vielen Dank,


da es sich hier um ein Gedanken-Experiment handelt, hilft eine zweite
Person super weiter.


lg


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