Benutzer:Leo/Blog:2016 July 06 22:05:39 CEST

Opennet Techniktreffen (06.07.2016)

Durch den Wechsel von OLSRv1 nach OLSRv2 feht uns die Funktionalität des nameservice Plugins (http://www.olsr.org/mediawiki/index.php/Olsrd#Plugins). Bisher wurde von uns das Plugin genutzt, um die Liste der DNS Server und der UGW-Server im Netz zu verbreiten.

Derzeit wird nach einer Alternative gesucht. Im Folgenden werden mögliche Wege aufgezeigt.

Portieren des alten nameservice Plugins auf OLSRv2

Das Portieren des Plugins auf OLSRv2 wurde auf der olsrd Mailingliste diskutiert (https://lists.olsr.org/pipermail/olsr-users/2016-July/006922.html). Es stellt sich heraus, dass dies nicht der optimale Weg ist. Schon die Art und Weise, wie das nameservice-Plugin damals implementiert wurde, scheint von einigen Personen kritisch gesehen zu werden. Der Vorschlag auf der Mailingliste ist, einen Mechanismus ähnlich HNCP (https://tools.ietf.org/html/rfc7788) zu nutzen. Somit ist eine klare Trennung zwischen dem Routingprotokoll und anderen Diensten (hier das Verbreiten von anderweitigen Daten im Netz) gegeben.

Was spricht *für* eine enge Verknüpfnug von nameservice Plugin und OLSRv2 Daemon:

• bestehenden MPR Flooding nutzen
• Nutzung vieler Funktionen des OONF Frameworks (Config Parsing, ....)
• Kein zusätzliches Binary

Was spricht dagegen:

• Dokumentation von OONF ist minimal und dadurch der Weg zur Implementierung an vielen Stellen unklar
• Der Hauptentwickler rät davon ab, das nameservice Plugin an das OLSRv2 Plugin anzuknüpfen

Was wäre theoretisch zu tun, um dies umzusetzen:

• Zusätzlichen Nachrichtentyp definieren (nameservice-Nachricht)
• Eigenes Plugin erstellen mit Kommunikation zum OONF-OLSRv2-Plugin
  • Empfangen: wenn Nachricht vom Typ "nameservice-Nachricht" ankommt:
    • enthaltene Service-Definitionen zu lokaler Service-Datenbank hinzufügen (falls sie noch nicht bekannt war)
      • externes Programm der ONI-Firmware über Änderung der Service-Liste informierten
    • falls Service-Definition schon bekannt war, Aging-Timer zurücksetzen
  • Senden: regelmäßig Service-Definitionen des eigenen APs per MPR-Flooding verteilen
  • periodisch Aging-Zähler der "gelernten" Services dekrementieren, bei Ablauf eines Zähler entsprechenden Eintrag aus lokaler Datenbank löschen und ggf. externes Programm der ONI-Firmware über Änderung der Service-Liste informierten
• Eigene Services (des APs) werden in de OLSRd-Konfigurationsdatei spezifiziert

Home Networking Control Protocol (HNCP)

HNCP (RFC7788) ist ein Protokol/Mechanismus, welcher das automatische Konfigurieren von Geräten im Heimnetzwerk ermöglicht. Es basiert auf DNCP (RFC7787). DNCP ist ein Protokol zum Verteilen und Synchronisieren von Stati im Netz. Es nutzt TLV Strukturen für die Daten und den Trickle Algorithmus sowie Hash Bäume zum Verteilen der Daten im Netz.

Vorteile:

• Es gibt Implementationen dafür: shncp und hnetd

Nachteile:

• Wir benötigen nur einen sehr kleinen Teil von HNCP (Flooding von TLVs).
• HNCP/DNCP macht eigentlich zu viel, denn jeder Knoten merkt sich den Status jedes anderen Knotens im Netz. Das benötigen wir nicht.

Was wäre theoretisch zu tun, um dies umzusetzen:

• Ein Reduzieren und Anpassen von shncpd wäre möglich. Aufgrund seines minimalistischen Umfangs sollte der Zeitaufwand her geringer sein als bei hnetd.

Eigenen Daemon für's Verteilen der Service-Informationen schreiben

Vorteil:

• Wir sind unabhängig vom fremden Codebases, guter Dokumentation bzw. der Unterstützung durch die jeweiligen Entwickler
• Das Programm kann sehr schlank sein

Nachteil:

• Höherer Programmieraufwand
• "Insellösung" (das wäre allerdings ein OLSRv2-Plugin oder ein Hack von shncp/hnetd im Grunde auch)
• wenn wir effizientes Flooding a la MPR wollen, entsteht hoher Implementierungsaufwand, da quasi das halbe OLSR nachgebaut werden müsste