BrainStorming

Hallo Zusammen,

wie bereits mehrmals angekündigt, habe ich vor ein Dokument über die BRN-OLSR-Integration zu schreiben. Da die Realisierung nicht primär von mir erfolgte, bitte ich euch mir „interessante“ Informationen zukommen zu lassen. Unter „interessant“ meine ich hierbei auch Designentscheidungen: Warum habt Ihr euch für Lösung A entschieden, wo doch auch die Möglichkeit B bestand, usw. Einige Fragen von mir im Vorfeld:

• Wurden lediglich Anpassungen an den Click-Scripten vorgenommen, oder mussten auch neue Element geschrieben werden?
• Integration auf Ebene von 802.11: Was wurde hier gemacht?
• IP: Zuweisung von IPs für OLSR-Knoten: Wie erfolgte dies? Kann das OLSR von der Existenz des BRN in irgendeiner Art und Weise profitieren?
• Ist die Realisierung selbstorganisierend?
• Aussagen über Performance?

---

Anpassungen:

• Infrastructure-Element (von Robert) im Click um mit dem Adhoc-OLSR-Netz zu verbinden
• Eigenes Device "olsr" im click
• olsr device eine IP geben (kann im Click erfolgen) und olsr daemon starten

OLSR-Netz weiß nicht von dem BRN. Aus Sicht des OLSR-Netzes ist der hybride Knoten ein Adhoc-Client.

Was soll das heißen selbstorganisierend? Wenn ein hybrider Knoten startet, dann guckt er, ob er ein Freifunk-OLSR findet und bringt die SSID in Erfahrung. Frames vom olsr-Device (also Pakete vom olsrd) bekommen dann die ermittelte SSID gesetzt.

Aussagen über Performance haben wir nicht.

Ergänzung von Robert:

• Ein click-element wurde geschrieben (läßt sich vielleicht auch durch vorhandene Elemente und passende skripte realisieren, ist jedoch durch andere Funktion erweitern)

• Infrastructure-Element (hat den Namen nur, weil es am Anfang für die Verbindung zu anderen APs gedacht war):

 - Konfiguration: 1. WirelessInfo-Element: Name des Netzes (olsr.freipunkt.net),SSID
 - Funktionsweise: Beacons werden nach gesuchten Namen(Netz) durchsucht und WirelessInfo entsprechend konfiguriert (z.B. SSID setzten) 

• Integration auf Ebene von 802.11:

 - eingehende Pakete mussten nach SSIDs Klassifiziert werden (ACHTUNG: manche Pakete (z.B. Beacons) werden in beide Teile (BRN,OLSR)  geschickt , könnte man mit einer Art Netzbroadcast vergleichen (an alle Netze))
 - bei ausgehenden Paketen müssen die SSID etc. im WIFI-Header entsprechend gesetzt werden 
 

• IP für das OLSR-Netz:

 - hier liegt es in der Natur des OLSR-Netzes, dass man die IP manuell setzen muss (also eigentlich nicht selbstorganisierend)

• Performance

 - Performance des olsr-Algos wurde bestimmt schon untersucht (vielleicht darauf verweisen)
 - interessant: da es nun zu einer Doppelbelastung kommt (BRN-Routing,OLSR-Routing) kann es vorkommen, dass die CPU schneller ans Limit kommt -> Wie reagieren die Routing-Algos (hier eigentlich nur OLSR) darauf ( Hello-Pakete gehen verloren etc.) 

• Weiteres:

 - die Devices für das OLSR- und BRN-Netz haben unterschiedliche MAC-Adresse, was eigentlich nicht so schön ist, weil vorher nehmen (gibt es private MAC-Bereiche wie bei IPs ?)
 - Grund für verschiedene MAC-Adressen war meine , ich denke unberechtigte Befürchtung, dass andere Knoten durcheinanderkommen, wenn ein Knoten an verschiedene Netze etwas sendet bzw. Beacons für verschiedene Netze sendet. Es bietet ausserdem die Möglichkeit auch nach dem Entfernen des WIFI-Headers die Pakete den verschiedenen netzen zuzuordnen

Jens: Soweit ich weiß benutzt das OLSR-Device diesselbe MAC Adresse, wie die ath0 Karte.

• Für das Paper

- Related Work
  1. verweise auf Geräte, die mehrere APs ind einem vereinen (Virtuelle APs, mehrere Netze) wäre interessant

- Future Work
  1. mehrere Ad-Hoc- und Infrastruktur-Netze pro Knoten unterstützen (Arbeit, die Jens mit den VPNs vollendet)