FSM-Dynamisches-Bridging: Unterschied zwischen den Versionen

Aus Freifunk Köln, Bonn und Umgebung
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „Die FSM bildet modelliert das Verhalten eines Nodes bei der Verwendung der dynamisches Briding-Strategie. Sie ist ein Gegenentwurf zu - Unterschied hierbei: *Das…“)
 
Keine Bearbeitungszusammenfassung
 
(6 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
[[Kategorie:Netz-und-Technik]]
Die FSM bildet modelliert das Verhalten eines Nodes bei der Verwendung der dynamisches Briding-Strategie.
Die FSM bildet modelliert das Verhalten eines Nodes bei der Verwendung der dynamisches Briding-Strategie.
Sie ist ein Gegenentwurf zu - Unterschied hierbei:  
Sie ist ein Gegenentwurf zu https://wiki.metameute.de/Freifunk/Netzwerk/DynamischesBridging - Unterschied hierbei:  
*Das Batman-ADV GW Feature wird nicht benutzt
*Das Batman-ADV GW Feature wird nicht benutzt
*In einem Mesh-Verbund existieren mehrere DHCP-Server mit verschiedenen Subnets. Somit: In einer OSI-2 Broadcast-Domaine existieren verschiedene OSI-3 Broadcast / Anycast Domänen.
*In einem Mesh-Verbund existieren mehrere DHCP-Server mit verschiedenen Subnets. Somit: In einer OSI-2 Broadcast-Domaine existieren verschiedene OSI-3 Broadcast / Anycast Domänen.
[[Datei:Fsm-dyn-br-entwurf.png]]
== Zustände ==
*Idle - Node ist eingeschaltet, macht nichts
*Init - Node initialisiert Dyn-Briding routinen
*Up - Node nimmt am Dyn-Briding-Teil
=== Zustände in Teilautomaten ===
*downloadNetConfig - Falls nicht vorhanden fordert der Node Netz-Konfiugrationsdaten (insb. Subnet, Range für dhcp) per http an.
*establishVPN - Der Node baut eine Verbindung zum Intracity-VPN auf. Dies beinhaltet den Upload seines Tinc-Keys per http
== Ereignisse ==
*nodeStart - Router wird hochgefahren.
*wanUP - Wan-Interface verbunden
*wanDown - Wan-Interface ist getrennt
*downloaded - Config-Daten wurden herunter geladen
*established - VPN-Verbindung wurde eingerichtet
*initSucess - Node hat Initialisierungs-Phase erfolgreich abgeschlossen
*nodeDiscoverd - Beacon-Frame eines anderen Nodes wurde empfangen
*nodeTimedOut(t min/sec/h) - Kein Beacon-Frame wurden in den letzten t min/sec/h empfangen.
== TBD ==
#Macht ein Timeout von 3min Sinn? Andere Idee: 24h - TBD: Pros, Cons? Realisitisch: Wohl irgendwo dazwischen.
#Ggf. Aufräumen kaputter l2tp-Links zur Freigabe nutzbarer IDs

Aktuelle Version vom 5. Februar 2012, 20:54 Uhr

Die FSM bildet modelliert das Verhalten eines Nodes bei der Verwendung der dynamisches Briding-Strategie. Sie ist ein Gegenentwurf zu https://wiki.metameute.de/Freifunk/Netzwerk/DynamischesBridging - Unterschied hierbei:

  • Das Batman-ADV GW Feature wird nicht benutzt
  • In einem Mesh-Verbund existieren mehrere DHCP-Server mit verschiedenen Subnets. Somit: In einer OSI-2 Broadcast-Domaine existieren verschiedene OSI-3 Broadcast / Anycast Domänen.

Fsm-dyn-br-entwurf.png

Zustände

  • Idle - Node ist eingeschaltet, macht nichts
  • Init - Node initialisiert Dyn-Briding routinen
  • Up - Node nimmt am Dyn-Briding-Teil

Zustände in Teilautomaten

  • downloadNetConfig - Falls nicht vorhanden fordert der Node Netz-Konfiugrationsdaten (insb. Subnet, Range für dhcp) per http an.
  • establishVPN - Der Node baut eine Verbindung zum Intracity-VPN auf. Dies beinhaltet den Upload seines Tinc-Keys per http

Ereignisse

  • nodeStart - Router wird hochgefahren.
  • wanUP - Wan-Interface verbunden
  • wanDown - Wan-Interface ist getrennt
  • downloaded - Config-Daten wurden herunter geladen
  • established - VPN-Verbindung wurde eingerichtet
  • initSucess - Node hat Initialisierungs-Phase erfolgreich abgeschlossen
  • nodeDiscoverd - Beacon-Frame eines anderen Nodes wurde empfangen
  • nodeTimedOut(t min/sec/h) - Kein Beacon-Frame wurden in den letzten t min/sec/h empfangen.

TBD

  1. Macht ein Timeout von 3min Sinn? Andere Idee: 24h - TBD: Pros, Cons? Realisitisch: Wohl irgendwo dazwischen.
  2. Ggf. Aufräumen kaputter l2tp-Links zur Freigabe nutzbarer IDs