Das Chaosradio Express lebt wieder auf und Tim Pritlove hatte Elektra Wagenrad als Interviewpartnerin zum Thema „Mesh Networking Update“:
B.A.T.M.A.N. läutet die nächste Generation im Mesh Networking ein
Schon in Chaosradio Express 016 hat Elektra einen tiefen Einblick in Wesen und Form des Mesh Networking geboten. Im Gespräch mit Tim Pritlove werden nun die neuesten Erkenntnisse der Entwicklung berichtet.
Kern der Neuigkeiten ist der Nachfolger des OLSR-Protokolls namens B.A.T.M.A.N. Elektra erläutert, wie B.A.T.M.A.N. im Deatil funktioniert, welche Erfahrungen und Erkenntnisse seinem Design zu Grunde liegen und wie man sich das alles vorstellen muss. Ein Teil der Diskussion betrifft auch die geplante Mesh Networking Technologie im OLPC (XO) Laptop.
schön wäre übrigens, wenn B.A.T.M.A.N. in openmoko [1] integriert werden würde. man stelle sich das mal vor: wireless phone mesh networking ! freifunk fürs handy !
[1] http://openmoko.com/
@erlehmann:
Wenn das funktionieren würde, wäre das natürlich super. Ich sehe leider ein kleines Problem mit dem Stromverbrauch. Im Gegensatz zum „Client“ Modus gibt es beim Ad-Hoc Modus keinen Stromsparmodus. Der WLAN Chip ist *immer* an und die CPU wacht ständig auf. Dazu kommt noch die Frage der Skalierbarkeit. Ob batman so gut funktioniert, dass man damit Millionen von „Router“ zu einem Netz verbinden kann? Vor allem vor dem Hintergrund, wie hoch CPU Last is (=nocheinmal Strom). Und wenn das Netz nicht dicht genug ist, gibt es keinen Empfang… Ich bin gespannt, wie es in ein paar Jahren ausschaut.
@Michi: millionen … du bist ja optimistisch. was skalierbarkeit angeht – ist B.A.T.M.A.N. nicht dazu designt, gerade diese schwäche von OLSR auszugleichen ? als mir das mal jemand erklärt hat, hieß es, OLSR muss immer die genaue route zum ziel kennen, während B.A.T.M.A.N. nur die „richtung“ braucht; genau das löse das skalierungsproblem.
@erlehmann
Ganz so einfach ist es (lieder) nicht…
Eine Route in IP ist nichts anderes als die Zieladdresse + der nächste Router. Im Prinzip geht das „nur die Richtung kennen“ recht einfach. Für jeden Knoten speichert man die Distanz. Wenn man ein Ziel sieht, ist die Distanz 1. Für alle Knoten die man nicht sieht, ist die Distanz die kleinste Distanz, die ein Nachbarknoten hat +1. Die gesammte Liste aller Routen wird an alle Nachbarknoten gesendet.
Die ersten Routing Protokolle funktionierten so. Es funktioniert aber nicht so gut. (1) Durch eine Verbindung, die sich ändert können sich eine ganze Reihe von Routen ändern. Das erzeugt zum einen etwas Traffik, zum zweiten kann es etwas deuern, bis alle Router wieder synchron sind. In der Zwischenzeit laufen die Packete im Kreis. Nach diesem Prinzip funktioniert z.B. RIP
Aus diesem Grund gibt es „Link State“ Routing Protokolle. Jeder Router speichert jede Verbindung im ganzen Netzwerk. Wenn sich etwas ändert, muss man nur noch die Information „diese eine Verbindung ist nicht mehr verfügbar“ weitersenden. Nach diesem Prinzip funktioniert OSPF, OLSR und einige andere.
Es gibt aber noch einen Trick. Man muss nicht umbedingt eine Sicht auf das gesammte Netzwerk haben, wenn es nur ein paar Knoten im Netz gibt. Und man muss auch nicht umbedingt die 100% beste Route zu jedem Ziel haben, wenn der Aufwand die Route zu finden sehr groß ist und nur wenige Daten übertragen werden. Das Problem wird dadurch aber nicht gelöst, sondern nur gelindert. Und *dieses* Konzept auf IP aufzubauen, ist ein Krampf.
Damit das Netz skaliert, gibt es aber auch nicht ein paar andere Anforderungen. Die Zahl der Router, durch die Datenpackete geschickt werden, muss gering bleiben. Wenn die Daten durch 50 Router gesendet werden, bevor sie ankommen, verringert sich die verfügbare Bandbreite, weil das Verhältniss Router/Teilnehmer deutlich niedriger ist. Bei Netze mit einem zentralen Internetzugang schaut es nicht so toll aus.
Es gibt aber auch ein anderes Konzept, dass unter anderem das Bandbreitenproblem mit Multicasting + QoS/Credits und die Routing CPU Last auf eine sehr interessante Art lösen will.