Key–based Overlay Routing in Mobilen Ad–Hoc Netzen

Key–based Overlay Routing in
Mobilen Ad–Hoc Netzen
Matthias Wählisch
[email protected]
8. Mai 2006
Zusammenfassung
Mobile Ad–Hoc Netze (MANETs) sind ein Feld aktueller Untersuchungen und Entwicklungen. Verteilte Hash–Tabellen (DHTs), schlüsselbasiertes Overlay Routing, gilt als
Durchbruch in der effizienten Lokalisierung von Ressourcen. Obwohl DHTs als auch MANETs frei von Infrastruktur sind, können DHTs nicht unmittelbar in MANETs angewendet werden. Probleme und Chancen des Zusammenspiels wollen wir nachfolgend betrachten.
1
Einleitung
Funkbasierte Netze stimulieren nicht mehr nur länger die Idee allgegenwärtiger Konnektivität, sondern sind im Alltag realisiert. Kabelfreie Campusnetze verbinden Studenten mit ihren
Hochschulen, Stadtnetze ihre Bewohner mühelos untereinander. Dennoch bedürfen diese einer
dedizierten Infrastruktur, damit die Endgeräte durch die Luft kommunizieren können. Mobile
Ad–Hoc Netze (MANETs) brechen hingegen mit den Konzepten der Infrastrukturnetzwerke.
Frei von zusätzlichen Komponenten auf der Verbindungsschicht gestatten sie die Bildung spontaner, funkbasierender Netze.
Die Infrastrukturlosigkeit auf der Schicht 2 findet ihr Pendant auf der Applikationsschicht
in Peer–to–Peer (P2P) Netzen. Stellten diese bisher eine Anwendung vor allem für Netze mit
zugehörigen Vermittlungskomponenten dar, erweitern sie nun, dem Paradigma fehlender Infrastruktur folgend, MANETs. Teilnehmer in MANET–Netzen sind sowohl veränderlich bezüglich
ihrer genauen Position in der Topologie als auch ihrer tatsächlichen Netzteilnahme. Der Aufbau von Client–Server–Strukturen ist für Anwendungen auf MANETs folglich ungünstig. In
ihrer Funktion ausgezeichnete Rechner müssen in MANETs stärker denn je als Single Point of
Failure betrachtet werden. Jedem Teilnehmer eines MANETs steht es per Definition frei, das
selbige zu verlassen, so daß eine Sicherstellung der angebotenen Dienste nur aus einer möglichst
vollständigen und effizient selbstheilenden Verteilung der Daten folgt. Der Ersatz serverbasierter Strukturen durch geeignete infrastrukturunabhängige Kommunikationsmodelle erweitert im
Umkehrschluss den Anwendungshorizont von mobilen Ad–Hoc Netzen.
Trotz ihrer konzeptuellen Ähnlichkeit müssen die technologieimmanenten Eigenschaften von
MANETs und P2P–Netzen aufeinander abgestimmt werden. Das prinzipielle Problem der effizienten Lokalisierung von Ressourcen in P2P–Netzen scheint zwar durch Distributed Hash Tables
(DHTs) gelöst, dennoch können eben jene nicht unmittelbar auf MANETs übertragen werden:
1
Geringe Bandbreiten, unzuverlässigere Verbindungen und die Forderung nach Energieeffizienz
stehen dem im Wege.
Verteilte Hash–Tabellen und MANETs verbindet aber nicht nur ein Kommunikationsparadigma. Beide treffen sich ebenfalls im Kontext der Mobilität. Es existieren zwei unterschiedliche Arten der ’Bewegung’, eine Veränderung der Anwendungsinformation zum einen, Mobilität
im realen Raum zum anderen. Muss bei dem Ein- oder Austritt eines Teilnehmers der DHT
das logische Netz (Overlay) neu strukturiert werden, bedingt die Bewegung eines Knotens im
MANET die Reorganisation des physikalischen Netzwerks. Hierbei ist es von praktischer wie
konzeptioneller Bedeutung, wie sichtbar Veränderungen auf der einen für die jeweils andere
Schicht werden. Zwar sind DHTs entworfen worden, um robust gegen Teilnehmerfluktuation
des Overlay–Netzes zu bleiben, doch ist keinesfalls evident, ob und wie gut sie Bewegungshäufigkeiten hervorgerufen durch Mobile Ad–Hoc Netze verkraften. Fragile und schwache Verbindungen zwischen MANET–Knoten sowie schnelle und grundlegende Wechsel der Topologie
lassen Ursachen für inkonsistente DHT–Strukturen leicht vorstellbar werden. Umgekehrt ist die
Frage zu beantworten, inwieweit MANETs eine zusätzlich durch DHTs erzeugte Verkehrslast
bewältigen. Die vorliegende Arbeit orientiert sich also an dem dualen Problem, inwieweit MANETs DHT–basierte P2P–Strukturen unterstützen bzw. schlüsselbasiertes Overlay Routing auf
MANETs sinnvoll zum Einsatz gelangen kann.
Nachfolgend werden hierzu in Abschnitt 2 zwei Ansätze der Verteilten Hash–Tabellen mit
ihren charakteristischen Eigenschaften erläutert. Abschnitt 3 verknüpft die gewonnen Erkenntnisse mit Untersuchungen aus dem Bereich der mobilen Ad–Hoc Netze und stellt aktuelle Ansätze, die auf bestehende DHTs rekurrieren und diese erweitern, vor. Schließlich wird in Abschnitt
4 eine Zusammenfassung und ein Ausblick gegeben.
2
Distributed Hash Tables in klassischen P2P–Netzen
Das Auffinden von Ressourcen stellt in Rechnernetzen einen üblichen Vorgang dar. Es können
dabei nicht nur die Ressourcen selbst, d.h. Dateien, Informationen u.ä. zentral oder dezentral abgelegt werden, sondern auch die Daten, um ihre Lokalisierung zu realisieren. Ziel ist es, zu einem
’Suchkriterium’, etwa dem Identifikationsschlüssel einer Ressource, den zugehörigen Speicherort, etwa einen Rechner zu finden. Hierzu muß die Zuordnung zwischen Rechner und Schlüssel
den anderen Knoten an geeigneter anderer Stelle bereitgestellt werden. Dies geschieht in seiner
einfachsten Form entweder durch Fluten der Informationen im gesamten Netz oder durch die
Hinterlegung des Tupels auf einem zentralen Server. Beide Ansätze skalieren aber nicht mit der
Anzahl der Teilnehmer, also etwa der Netzknoten. Das Fluten erlaubt zwar einen optimalen
Speicheraufwand, da Knoten selbst über ihre Ressourcen informieren und folglich keine weiteren
gespeichert werden müssen, steigt aber asymptotisch linear im Kommunikationsaufwand. Eine
serverbasierte Vorgehensweise verhält sich genau entgegengesetzt. Ein üblicher Lösungsansatz
in verteilten Informationssystemen liegt deshalb darin, die benötigten Informationen vorzustrukturieren und so zu verteilen, daß sie in logarithmischer Zeit aufgefunden werden können.
Der DNS ist wohl das bekannteste Beispiel hierfür.
Verteilte Hash Tabellen (Distributed Hash Tables, DHTs) erlauben ganz analog das effiziente
Auffinden einer Ressource bei gleichermaßen günstiger Datenverteilung über mehrere Knoten.
Der Aufwand beträgt bei n Knoten i. d. R. O(log n). Jeder Knoten innerhalb einer DHT verwaltet eine Menge an Zuordnungspaaren (Schlüssel, Rechner) und kann auf Anfrage effizient
herausfinden, welche Knoten die restlichen Schlüsseln besitzen. Dazu wird mittels einer Hash–
Funktion hash() sowohl der Ressourcenschlüssel (k ∈ K) als auch eine eindeutige Kennung,
z.B. die IP–Adresse, der DNS–Eintrag oder der öffentliche Schlüssel des Rechners (v ∈ V ) auf
2
eine geordnete Menge (M ) abgebildet. Der Bildraum ist dabei für beide Datenquellen derselbe:
hash : V, K → M . Knoten aus einem Rechnernetz sind demnach innerhalb der DHT mittels
hash(v), einer applikationsspezifischen Adresse, identifizierbar. Verteilte Hash Tabellen zeichnet
das effiziente Auffinden eines Schlüssels aus.
Da die Schlüssel verteilt abgelegt werden, erstellt eine DHT zur Wegewahl eine vom darunterliegenden Rechnernetz abstrakte und unabhängige Struktur. Die Basis für eine Verteilte
Hash–Tabelle entsteht, ähnlich zum physikalischen Verbinden von Rechnern, durch das Verknüpfen mindestens zweier Knoten anhand ihres DHT–Identifizierers. Die erzeugte Topologie
hängt von der konkreten DHT ab [1]. Ein Netz entsteht über den darunterliegenden Schichten,
ein Overlay–Netz.
Darauf aufsetzend werden Routing–Tabellen für das logische Netz berechnet. Knoten eines
DHT Overlay–Netzes besitzen somit entweder nur Informationen zur Weiterleitung eines Schlüssels an andere DHT–Knoten oder zusätzlich eine konkrete Zuordnung eines ihm übertragenen
Schlüssels zu einem Rechner.
Die Zuweisung eines Schlüssel zu einem Knoten des Overlay–Netzes nutzt die Ordnung
des Bildraumes aus und basiert auf folgender Idee: Ein Schlüssel k und die zugehörige Rechneradresse wird dem Knoten v zugeordnet, der bezüglich seiner Overlay-ID den numerisch kleinsten
Abstand zum Hash–Wert von k hat. Formal muß für v und k also gelten:
hash(k) ≤ hash(v) und hash(v) ≤ hash(v 0 ), ∀ v 0 ∈ {v 0 |v 0 ∈ V, hash(k) ≤ hash(v 0 )
und Mitglied der DHT}. (1)
Unter einer DHT wird also eine Datenstruktur verstanden, die einen Schlüssel verteilt speichert, einschließlich eines Algorithmus’, der das Routing zwischen den Knoten der DHT beschreibt, um die Auflösung zwischen Schlüssel und Referenz zu gewährleisten. Eine DHT wird
ergänzt von einem Kommunikationsprotokoll, welches die Datenstruktur unterhält und die notwendigen Routing–Informationen austauscht. Im Folgenden werden die Routing–Ideen von zwei
konkreten Implementierungen einer Verteilten Hash Tabelle, Chord [2] und Pastry [3], exemplarisch vorgestellt.
2.1
Chord
Chord [2] verknüpft die Knoten innerhalb der DHT zu einem Ring. Für drei unterschiedliche Knoten u, v, w, des Overlay–Netzes gilt somit u < v < w. Auf diese Weise besitzt jeder Overlay–Knoten einen Vorgänger und Nachfolger, zu welchen er sich die (Vermittlungs–)
Adressen der physikalischen Rechner merkt1 . Erhält nun ein Knoten eine Anfrage nach einem
Schlüssel, könnte er diese entsprechend der Größe des Hash–Wertes links oder rechts entlang
des Kreises schicken, falls er ihn nicht selbst auflöst.
Da ein solches Vorgehen aufgrund des linearen Suchaufwandes ineffizient ist, pflegt ein Knoten in Chord zusätzlich eine Routing–Tabelle fester Länge m bestehend aus zwei Spalten, die
so genannte Finger Table. Die erste Spalte enthält Werte, die folgender Vorschrift für die i−te
Zeile entsprechen: hash(v) + 2i−1 (1 ≤ i ≤ m). Sie repräsentieren das Ziel einer Anfrage. Die
zweite Spalte enthält folglich die Adresse des Knotens, der die Gleichung (1) für den jeweiligen
Wert der ersten Spalte erfüllt. In der ersten Zeile wäre das der unmittelbare Nachfolger des
Knotens im Ring. Bei einer Anfrage wird die Zeile ausgewählt, die analog zu (1) dem Wert der
ersten Spalte entspricht oder dem nächst größeren zugeordnet werden kann. Da die Abstände
der Hash–Schlüsselwerte in der Routing–Tabelle exponentiell größer werden, gelingt es einem
1
Im Internet also z.B. die IP–Adresse.
3
Chord–Knoten bei Anfragen zu besonders weit entfernten Schlüsseln im Ring besonders viele
Overlay–Zwischenknoten zu überspringen und nahe Anfragen möglichst direkt zuzustellen. Augenscheinlich nimmt das Overlay Routing aber keinen Bezug auf die darunterliegende Schicht
2 oder 3 Topologie2 .
2.2
Pastry
Im Gegensatz zu Chord wird in Pastry [3] beim Aufbau der Routing–Tabelle per se eine Metrik
berücksichtigt, die die Entfernung zweier Knoten u und v (distvu ) in der physikalischen Topologie
widerspiegelt, z.B. die RTT. Ein Knoten im aufgebauten Ring leitet eine Schlüsselanfrage also
nicht mehr nur an einen numerisch dichteren Knoten im logischen Netz weiter, sondern auch an
einen mit geringster Verzögerungszeit bezüglich des physikalischen Netzwerkes. Dazu besitzt ein
Pastry–Knoten eine auf Präfixen basierende Routing–Tabelle. Kann es bei Chord per Definition
pro Zieleintrag nur genau eine Möglichkeit zur Wegewahl geben, stehen in Pastry potentiell
mehrere zur Verfügung. Hierzu verdeutlichen wir uns als erstes den Aufbau der Routing–Tabelle:
Sei b die Basis des Zahlensystems, auf das die Hash–Funktion abbildet, und n die Anzahl an
Ziffern der größt möglichen Zahl aus dem Bildraum. Sei ferner pref ix(m, ∗) eine Funktion,
die auf die ersten m Zeichen eines Wertes abbildet mit pref ix(0, ∗) := kein Zeichen. Dann
besitzt eine Routing–Tabelle n Zeilen und b Spalten, wobei jede Zelle in der i-ten Zeile und
j-ten Spalte (1 ≤ i ≤ n, 1 ≤ j ≤ b) des Knoten v ∈ V und Mitglied der DHT folgende
Semantik hat: Der Index approximiert mittels einer Transformation T (i, j) den Pastry–Schlüssel
im Overlay, der Tabelleneintrag beinhaltet die korrespondierende Adresse im Rechnernetz. Die
Indextransformation bildet die möglichen Präfixlängen des lokalen Knotenschlüssels und ist
gegeben durch:
T (i, j) = pref ix(i − 1, (hash(v)) · jb , mit z · jb =: z konkateniert mit j zur Zahlenbasis b. (2)
Damit korrespondiert jede Spalte einer Zeile i mit den ersten i − 1 Zeichen des Hash–Wertes
des Knotens. Weiterhin gibt es für jede Zeile eine Spalte l, die dem Wert des Knotens unter
der Hash–Funktion in den ersten i Zeichen entspricht (T (i, l) = pref ix(i, hash(v))). Diese
kann ignoriert werden, da sie auf den Knoten selbst referenziert. Auch wenn die Definition der
Routing–Tabelle kompliziert erscheint, erlaubt sie durch die Rechenvorschrift den Zugriff auf
die Einträge in konstanter Zeit3 .
Die Einträge werden nun wie folgt erzeugt: Für ein Präfix P der Länge |P | stehen alle
Knoten w aus der Menge M der bekannten Overlay–Teilnehmer zur Verfügung, für die gilt:
pref ix(|P |, hash(w)) = P, mit w ∈ M.
Gewählt wird der Pastry–Knoten w, welcher die geringste Latenz zu v hat, d.h.
distvw < distvw0 , ∀ w0 .
Dieses Verfahren zur Berücksichtigung der unterliegenden Topologie wird auch Proximity Neighbor Selection (PNS) genannt.
Der eigentliche Routing–Algorithmus wählt nun auf Basis von (2) die Zelle aus der Tabelle,
deren Präfix eine um eine Ziffer größere Übereinstimmung mit dem angefragten Schlüssel besitzt
als der Hash–Wert des Knoten selbst. Einen solchen Eintrag muß es entsprechend der Definition
2
3
Eine direkte Erweiterung des Chord–Algorithmus’, der dies ermöglicht, wird am Rande in [1] vorgestellt.
Damit beträgt die Größe der Routing–Tabelle O(b · log n).
4
geben und die Anfrage kann weitergereicht werden4 . Der Schlüssel wird also mit jedem Schritt
um eine Präfixstelle näher an das tatsächliche Ziel geleitet.
Um die Effizienz des Routing–Verfahrens zu erhöhen, besitzt jeder Knoten in Pastry zusätzlich eine Blattmenge (Leaf Set). In dieser speichert er eine feste Anzahl unmittelbarer links
und rechts von ihm liegender Nachbarn im Ring. Tatsächlich konsultiert ein Knoten also seine
Routing–Tabelle erst dann, wenn kein Knoten aus der Blattmenge die analog zu sehende Bedingung (1) für den Hash–Wert des gesuchten Schlüssels erfüllt, da dieser sonst direkt erfragt
werden könnte. Typischerweise besteht die Blattmenge aus 16 oder 32 Knoten abhängig von der
Größe des Bildraumes der Hash–Funktion [3]. Es ist augenscheinlich, daß je größer das Verhältnis zwischen der Anzahl abgespeicherter Knoten in der Blattmenge und Größe des Bildraumes
der Hash–Funktion ist, desto mehr Anfragen können ihr Ziel unmittelbar erreichen.
Pastry nutzt für seine Routing–Entscheidungen Informationen der Vermittlungsschicht. Wichtig ist dabei, daß die Einbeziehung des unterliegenden Netzes ausschließlich bezüglich der Wegewahl geschieht, aber die Struktur des Overlay–Netzes oder die Position eines Knotens innerhalb
derselben unberührt bleibt. Abhängig von der benutzten Hash–Funktion und des Funktionswertes, also eines eindeutigen Identifizierers des Knotens im physikalischen Netz, können zwei
im Ring benachbarte Knoten im ’realen Netz’ weit voneinander entfernt sein. Wir wollen nachfolgend erst einmal einige Eigenschaften der vorgestellten DHTs mit Blick auf das Verhältnis
zwischen Overlay– und realer Pfadlänge betrachten.
2.3
Eigenschaften von Chord und Pastry
Die Routing–Effizienz einer Verteilten Hash Tabelle wird von der Anzahl an nötigen Zwischenknoten im Overlay–Netz bis zum Ziel bestimmt. Dennoch fließt zusätzlich in die Gesamtverzögerungszeit die Dauer der Paketzustellung zwischen zwei Geräten im physikalischen Netz ein.
Zählt man die zu traversierenden Knoten, ist deren Anzahl für das physikalische Netz immer
größer oder gleich der Anzahl im logischen Netz. Selbst wenn eine ’numerische’ Korrespondenz
zwischen der Vermittlungsadresse, bsp. der IP-Adresse und ihrer Abbildung über eine monotone
Hash–Funktion herstellbar wäre, würde dies im Allgemeinen losgelöst von der physikalischen
Geometrie sein. Zwei numerisch nahe IP–Adressen können in der Realität ’genauso weit’ auseinander liegen wie die Knoten eines Overlay–Netzes. Faktisch müßten z.B. topologische Metriken
bei der Abbildung der Hash–Werte einbezogen werden. Weder Pastry noch Chord berücksichtigen in ihrer ursprünglichen Gestaltung bei der Konstruktion des Overlay–Netzes die Topologie
der zugrundeliegenden IP–Infrastruktur.
Ein Knoten im Chord–Netzwerk mit insgesamt n Teilnehmern benötigt O(log2 n) Routing–
Informationen, um asymptotisch eine Anfrage in ebenso vielen Schritten aufzulösen [2]. Stoica
et al. zeigen weiterhin, daß die mittlere Pfadlänge sogar bei (1/2) log2 n liegt. In einem Netz
bestehend aus insgesamt 212 Overlay–Knoten müssen folglich im Durchschnitt 6 Chord–Knoten
passiert werden, um denjenigen Knoten zu finden, der Kenntnis über die Zuordnung einer Ressource zum tatsächlichen Rechner hat. Die Verteilung der Pfadlängen im Overlay approximiert
bei einer hinreichend großen Anzahl an Knoten eine Gaussfunktion. Gemäß [4] ist sie durch eine
Binomialverteilung gegeben mit der Varianz log2 (n)/4. Diese Verteilung hängt nur logarithmisch
von der Größe des P2P Netzes ab und ist scharf um den Mittelwert mit einer Streuung von
p
log2 (n)/4 konzentriert. Entsprechend bleibt das Routing–Verhalten weitgehend unbeeinflußt
von der Overlay–Netzgröße und dem individuellen Sender–Empfänger Paar.
Das Maß, welches die durch das Overlay–Routing hervorgerufene, zusätzliche Verzögerung
4
Es ist natürlich möglich, daß der mit dem Ziel verknüpfte Overlay–Knoten nicht erreichbar ist oder es aufgrund von Inkonsistenzen keine Verknüpfung gibt. Für die Behandlung solcher Sonderfälle sei auf [3] verwiesen.
5
beschreibt, wird als Delay Stretch bezeichnet [5, 6], [7]. Der Delay Stretch d ist das Verhältnis
zwischen der aus den Routing–Schritten im Overlay resultierenden (physikalischen) Pfadlänge zweier Knoten (u, v) und der Distanz zwischen ihnen bei ’direkter’ Kommunikation im
Rechnernetz:
P
distxy
d :=
, mit ∀ x, y : Zwischenknoten im Overlay auf dem Weg von u nach v.
distuv
Die Chord–Topologie und das Routing nach [2] werden vollständig unabhängig von dem
zugrunde liegenden Rechnernetz entwickelt. Aufgrund dieser Unabhängigkeit ergibt sich die
mittlere Pfadlänge im Overlay zu d. Setzen wir voraus, daß der Adressraum im Rechnernetz
gleichmäßig gefüllt wird, so erhält die in Chord benutzte Hash–Funktion diese Gleichverteilung.
Entsprechend werden auch zwei benachbarte Overlay–Knoten als zufällig gewählte Teilnehmer
im physikalischen Netz gefunden. Ihre mittlere Distanz entspricht der mittleren Distanz im
Rechnernetz. Für Ad–Hoc Netze mit N Knoten, deren Topologie einem Random Graph entspricht, beträgt die mittlere Pfadlänge nach [8] O(ln N/ ln deg), wo deg den durchschnittlichen
Grad der Knoten bezeichnet. Sind die √
Knoten des Ad–Hoc Netzes in einem rechteckigen Gitter angeordnet, erhöht sie sich auf O( N ) [8]. Diese beiden Geometrien stellen Extremfälle
bezüglich der Topologiewahl dar. Für eine Gitterstruktur ergibt
√ sich dadurch die mittlere Pfadlänge im Chord als Funktion der Ad–Hoc Netzknoten zu O( N (1/2) log2 n). Die logarithmisch
gedämpfte Abhängigkeit von der Netzgröße geht damit verloren.
Analog zu Chord ist in Pastry die erwartete Anzahl an Zwischenknoten im Overlay–Netz für
eine Suchanfrage O(log n) [3]. Gemäß den tabellarischen Werten aus [4] ähneln sich die geometrischen Eigenschaften des Chord– und des Pastry–Graphen. Im Gegensatz zu Chord bezieht
Pastry aber die physikalische Topologie beim Aufbau seiner Routing–Tabellen ein (vgl. Abschnitt 2.2). In [9] und [5] wird mittels Simulationen5 gezeigt, daß der Delay Stretch abhängig
von der gewählten Topologie im Mittel zwischen 1, 37 und 2, 2 liegt. Auf der Basis realer Internetdaten ist d = 2, 2 mit einem Maximalwert von 6, 5 [9]. Pastry gelingt es hierbei, unabhängig
von der Anzahl an Overlay–Knoten zu werden [5].
Die optimierenden Effekte der Proximity Neighbor Selection in Pastry wirken sich vorwiegend bei im Pastry Ring weit voneinander entfernten Knoten positiv aus (vgl. [9]). Nahe Knoten
teilen ein längeres Präfix. Je länger aber das Präfix wird, desto weniger Overlay–Teilnehmer
stehen prinzipiell für einen Routing–Eintrag zur Verfügung. Entsprechend sinkt die Wahrscheinlichkeit, einen physikalisch dichten Knoten auswählen zu können.
Es ergeben sich also zwei Situationen: In Pastry ist zwar der Delay Stretch konstant und
entkoppelt von der Größe des logischen Netzes, verändert sich aber mit der darunterliegenden
Topologie. In Chord hingegen wächst d logarithmisch mit der Anzahl an DHT–Teilnehmern,
bleibt aber unabhängig von der physikalischen Topologie.
Ein günstiges Verhältnis von logischer und realer Pfadlänge ist nicht nur bei konkreten
Suchanfragen relevant. Treten Teilnehmer einer DHT bei oder verlassen sie diese, müssen die
Informationen über sie auf den anderen Knoten des Overlays aktualisiert werden. Schlüsselzuordnungen und Routen invalidieren. Den kontinuierlichen Prozess des An- und Abmeldens
von Teilnehmern bezeichnet man als Churn [10], [11], [12]. Der Terminus bleibt aber ohne eine
konkrete Metrik vage. Die Sitzungszeit, d.h. die Zeit zwischen einem Bei- und Austritt, oder die
gesamte Lebenszeit, also die Zeit zwischen dem ersten An- und dem letzten Abmelden, stellen
dafür nur zwei Beispiele dar (vgl. [10]). Im Allgemeinen umfasst der Ausdruck weiterhin auch
solche Knoten, die gezwungen durch Abstürze, Überlast, u.ä. ausscheiden. Eine Unterscheidung
5
Die Autoren verwenden bis zu 60.000 Pastry–Knoten.
6
dazwischen ist wichtig, denn geschieht das Verlassen der DHT, wenn auch nur zeitweilig ungewollt, halten Nachbarn zumindest für diese Dauer falsche Informationen der verzeichneten
Wege.
Um Fehlerzustände zu korrigieren, teilen sich die Knoten einer DHT regelmäßig ihren Status
mit. Basierend auf Simulationen haben Li et al. einen Kompromiss zwischen den Kosten zur
Aufrechterhaltung einer adäquaten Suchantwort und dem dafür nötigen Kommunikationsaufwand sowie die dafür nötigen DHT–Einstellungen ermittelt [11]. Die gesamtheitlichen Faktoren,
also die das logische sowie das physikalische Netz betreffen und zum Einbruch der Effizienz führen, wurden in [10] untersucht. Die Autoren haben das Verhalten der DHT in einem Netzwerk
vollständig emuliert, so daß Auswirkungen von z.B. hoher Verkehrslast auf das Verhalten der
DHT und damit das Zusammenspiel beider Netze zu erkennen sind. Es wurden drei charakteristische Eigenschaften identifiziert: Timeouts, die Reaktion im Fehlerfall (reaktiv vs. periodisch)
und das Einbeziehen der physikalischen Topologie in das Overlay Routing Verhalten.
Hiervon wollen wir die ersten beiden genauer betrachten. Sind Zeitmesser (Timeouts) zu kurz
eingestellt, folgert ein Knoten fälschlich auf einen Fehlerfall und initiiert unnötig einen neuen
Weg. Dieser Weg ist vor allem bei der Verknüpfung des Overlay Routings mit Eigenschaften
der physikalischen Topologie mit hoher Wahrscheinlichkeit schlechter und damit die Pfadlänge
größer. Unabhängig davon führt es zu einem höheren Verkehrsaufkommen, welches insbesondere
dann zu vermeiden ist, wenn die Antwort aufgrund von Stauphänomenen nicht angekommen
ist. Der Knoten ist eigentlich noch Teilnehmer des Netzes, die Nachricht womöglich schon auf
dem Weg, wird aber nicht innerhalb der konfigurierten Zeit zugestellt. Sind diese aber zu lang,
wartet der Anfragende, obgleich das Ziel unfreiwillig nicht mehr im Overlay teilnimmt. Bei
Chord wächst die mittlere Verzögerungszeit deutlich superlinear als Funktion abnehmender
mittlerer Sitzungszeit [10].
Ein weiteres Charakteristikum ist das Vorgehen zur Aktualisierung der Knoteninformationen. Sendet ein Teilnehmer reaktiv seine Informationen, führt das gerade bei Staus zu ungewollten Zyklen: Ein Teilnehmer erfährt über seine Nachbarn nichts, führt eine Wiederherstellung
seiner Tabellen durch und löst somit einen Verkehrskollaps auf seiner Netzschnittstelle aus, wodurch er noch weniger Informationen erhält. Dies kann zu einem Einbruch der Erfolgsquote von
bis zu 80% beim Auflösen von Anfragen führen [10]. Im Gegensatz dazu verringert der reaktive
Mechanismus das Verkehrsaufkommen bei einem geringen Churn um die Hälfte (vgl. [10]) im
Vergleich zu einem periodischen Algorithmus, da Daten nur bei einer wirklichen Veränderung
ausgetauscht werden.
Die Untersuchungen [10] und [11] zeigen, daß verteilte Hash–Tabellen unter einem hohen
Teilnehmerwechsel prinzipiell benutzbar sind. Ihr Funktionieren bedingt jedoch eine geeignete
Einstellung der Funktionsparameter. Diese sind zum Teil deutlich von der zugrunde liegenden
Infrastruktur abhängig. Keineswegs zu vernachlässigen sind also die durch die unterliegenden
Schichten hervorgerufenen Effekte, genauso wie das Verhältnis von Kosten und Nutzen.
3
Mobilitätstaugliche Distributed Hash Tables
Die Sitzung eines Teilnehmer klassischer P2P–Netze dauert zwischen 20 Sekunden und einer
Stunde [10]. Knoten in DHT–Netzen sind gleichsam ähnlich flüchtig wie sich bewegende Geräte
eines MANETs. Wird dies auf der einen Seite durch die Applikation bedingt, ist es auf der anderen Seite physikalischer Natur und wirkt unmittelbar auf darüberliegende Schichten. Sowohl
DHTs als auch MANETs müssen robust gegen die (unvorhersagbare) Mobilität ihrer Anwender
sein. Berücksichtigt das eine Netz für seine Kommunikation, z.B. Interferenzen, versteckte oder
ausgelieferte Endgeräte, handelt es sich bei dem anderen um die ungewollte Terminierung der
7
Anwendung. Ferner repräsentieren sie eine ähnliche Kategorie an Ausstattung und Aufgaben:
Es handelt sich um Endgeräte, die in ihrer Leistung als nicht spezialisiert betrachtet werden
dürfen, aber zusätzlich ’gemeinnützige’ Aufgaben wahrnehmen, wie das Vermitteln von Anfragen. Hierzu benötigt ein Knoten des Overlay–Netzes ein gleichermaßen günstiges Verständnis
der Topologie wie sein Pendant im MANET.
3.1
Probleme
Funkbasierende Ad–Hoc Netzwerke (Multihop Networks) bringen eine Beschränkung des Ende
zu Ende Durchsatz abhängig von ihrer Knotenanzahl mit sich. Nach Gupta und Kumar läßt sich
der Durchsatz zwischen zwei Knoten, in dem jeder√auch die Funktion eines Router übernimmt,
für ein Netzwerk mit n Teilnehmer mittels O(1/ n) abschätzen [13]. Demnach approximiert
die Vermittlungskapazität langsam die Null in wachsenden MANETs. MANETs sind per se
also nicht beliebig skalierbar. Der Grund hierfür liegt darin, daß die Teilnehmer mehr mit dem
Weiterleiten der Pakete anderer Knoten beschäftigt sind, als daß sie eigene Daten auf den Weg
schicken können. Diese Analyse setzt voraus, daß die Kommunikation innerhalb des MANETs
in der Regel zwischen zwei entsprechend dem Durchmesser des Netzes entfernten Knoten stattfindet, so daß das Verkehrsaufkommen aus Sicht eines Knotens tatsächlich von seiner Umgebung
statt von ihm selbst stammt. Bleibt aber die zurückgelegte Kommunikationsdistanz klein, ’zerfällt’ das MANET also in Teile, in denen weitestgehend lokaler Datenaustausch stattfindet,
sinkt der administrative Verkehr für jeden einzelnen Knoten und die Annahme muß relativiert betrachtet werden [14], [15]. Gleichwohl muß bei der Betrachtung die zusätzliche, durch
Routing–Aufgaben hervorgerufene Last Berücksichtigung finden. Darüber hinaus ist die Frage
relevant, wie sich die DHT–Struktur in die MANET–Topologie einbettet.
Da nun MANETs und Overlay–Netze beide Mobilität und Instabilität von Knoten unabhängig voneinander hervorrufen, gilt es die Frage der Aufschaukelung bzw. des Ausgleichs
zueinander ebenfalls zu beantworten.
Sei etwa die Lebenszeit der MANET–Knoten Tα exponentialverteilt mit Mittelwert 1/α und
TDHT die Lebenszeit der DHT–Knoten. Dann ermittelt sich die Verteilung der Gesamtlebenszeit
zu
Pr(min(Tα , TDHT ) > t) = Pr(Tα > t) · Pr(TDHT > t) = e−α·t · Pr(TDHT > t),
(3)
d.h. die Überlebenswahrscheinlichkeit sinkt mit dem Exponentialfaktor e−α·t .
3.2
Lösungsansätze
3.2.1
Back–Up Chord
Backup–Up Chord [16] und das hybride Chord Protokoll [17] behandeln ihren Ideen nach von
MANETs losgelöste Probleme. Ziel von Back–Up Chord ist es, sowohl das ungewollte Austreten
eines Knotens aus dem Chord–Ring zu registrieren, als auch seine gespeicherte Schlüsselmenge
unmittelbar an den entsprechend Gleichung (1) existierenden neuen Knoten zu übermitteln.
Hierzu wird für jeden Knoten v genau ein Stützknoten w (Backup–Knoten) definiert, derart
daß hash(w) den numerisch kleinsten Abstand zu hash(hash(v)) besitzt. Der Knoten v teilt w
sowohl seine gesamte Schlüsselmenge, als auch seine Vorgänger und Nachfolger im Ring mit.
Folglich kennt w denjenigen Knoten, der nach dem Ausscheiden für die Schlüssel verantwortlich
ist, den Vorgänger von v. Durch ein regelmäßiges Funkfeuer (Beacon) wissen v und w um ihre
gegenseitige Existenz im Ring. Die auf einer wenig komplexen Simulation beruhende Evaluation
von maximal 16 bzw. 100 Knoten zeigt eine Verbesserung gegenüber dem in Abschnitt 2.1
8
behandelten Chord von maximal 38% bei einem mittleren Ausscheiden von 1000 Knoten pro
Sekunde [16]. Es ist also davon auszugehen, daß ein physikalischer Knoten mehreren logischen
entspricht6 . Generell schlagen die Autoren einen reaktiven Widerherstellungsmechanismus vor.
Aus [10] wissen wir aber, daß ein unmittelbares Reagieren auf einen Fehler in realen Netzen
zu nachteiligen Effekten führt. Für MANETs mit ihren schwankenden Netzparametern gilt
das im Besonderen. Ferner lassen die Autoren ungeklärt, wie die Chord–Konfigurationsgrößen
eingestellt wurden. Nach [11] läßt sich damit alleine schon eine Verbesserung des Suchverhaltens
um mehrere Größenordnungen erreichen. Schlussendlich stellt sich die Frage nach dem Chord
Back–Up spezifischen Beacon–Intervall. Offensichtlich entscheidet dieses maßgeblich über die
Güte des Algorithmus und ist nicht trivial zu beantworten mit Blick auf Verkehrslast und einem
in MANETs per se fluktuierenden Antwortverhalten. Der in [16] vorgeschlagene Ansatz mag
zwar die Trefferhäufigkeit bei volatilen Benutzern erhöhen, bleibt aber für MANETs ungeeignet.
3.2.2
Das Hybrid Chord Protocol
Das Hybride Chord Protokoll (HCP) verfolgt zwei andere Ansätze: die semantische Erweiterung der hinterlegten Schlüssel und damit eine kostengünstigere Suche sowie die Fixierung der
Objektreferenzen [17]. Dafür führen die Autoren Informationsprofile (Info Profiles) ein und kategorisieren die Knoten des Overlay–Netzes als statisch oder temporär. Ein Informationsprofil
entspricht einem klassischen (Schlüssel, Rechner) Tupel, erweitert um die Möglichkeit, mehrere Schlüsselwörter aufzunehmen, einen Objektnamen u.a. Attribute zu halten. Den bekannten
Prinzipien folgend (vgl. Abschnitt 2) verwaltet jeder Overlay–Knoten die Objekte, zu denen er
bezüglich des Schlüsselwortes unter der Hash–Funktion den numerisch kleinsten Abstand hat.
Da in HCP einem Objekt mehrere Schlüsselwörter zugeordnet sein können, existieren Knoten,
die das gleiche Informationsprofil besitzen. Zöls et al. gehen nun davon aus, daß eine Suche
nicht mehr nur der Lokalisierung einer einzelnen Entität dient, sondern sich die Anfrage auf
einen Kontext bezieht, hergestellt z.B. durch die Verbindung der Schlüsselwörter. Bei einer
herkömmlichen DHT müßten alle zu einem Desiderat gehörenden Knoten angefragt werden.
HCP minimiert hingegen (ausschließlich) für die boolesche AN D Verknüpfung die Anzahl der
zu kontaktierenden Overlay–Teilnehmer auf eins, da für sie per Definition gilt: Gibt es auf einen
Knoten Informationsprofile mit dem Schlüsselwort k, sind auch darunter diejenigen mit k ∧ k 07 .
Informationsprofile werden nicht auf alle Knoten des Overlays verteilt. Ausgehend von der
Überlegung, daß das Verschieben von Objektreferenzen Netzwerklast erzeugt und in MANETs
die Mobilität besonders häufig dazu führt, unterteilen Zöls et al. die Knoten in temporäre und
statische. Als statisch werden Knoten mit hoher Anwesenheit im HCP–Ring bezeichnet, als
temporär alle anderen [17]. Demnach müssen im besten Fall nach der Trennung eines (temporären) Teilnehmers vom Ring nur die Routing–Tabellen eine Aktualisierung erfahren. Allen
temporären Knoten ordnet der Algorithmus über die reguläre Nachfolgerbedingung jeweils eine feste Anzahl an statischen Knoten zu, so daß bei einer Anfrage lediglich auf die statischen
HCP–Knoten weiter verwiesen werden muß. Zöls et al. evaluieren ihr Protokoll analytisch, indem sie die durch Verschiebung der Informationsprofile erzeugte durchschnittliche Verkehrslast
(λ) für einen Knoten in Chord und HCP berechnen. Die Reduzierung ist für λHCP proportional
zu dem Verhältnis (β) zwischen mittlerer Sitzungslänge eines Knotens und der eines statischen
[17]. Anders ausgedrückt: Gibt es (statische) Knoten, die um einen Faktor β seltener wechseln und die Objektreferenzen halten, sinkt die betriebene Kommunikation um diesen Faktor.
Arithmetisch ist dies zwar richtig, bedarf aber dennoch eines Kommentars. Jeder Knoten in
6
7
Eine genauere Beschreibung der Simulation liegt nicht vor.
Es ist klar, daß bei der OR Verknüpfung wiederum alle Knoten befragt werden müssen.
9
Chord besitzt im Mittel O(m/n) Informationsprofile m und O(m/x · n) in HCP mit 0 < x < 1,
dem Anteil der statischen Knoten an der Gesamtknotenmenge n [17]. Generell hält damit ein
statischer Teilnehmer in HCP mehr Schlüssel. Wechselt dieser, sind die maximalen Kosten pro
Knoten natürlich höher als beim herkömmlichen Chord. Da temporäre Knoten als Vermittler
im MANET dienen, werden sie mit O(m/x · n) stärker belastet als gewöhnlich. Unklar bleibt,
wie genau und woran ein Overlay–Teilnehmer als statisch ausgezeichnet wird. In [18] ist dies
etwas präziser ausgeführt. Neben der Einbeziehung konkreter Hardware–Ressourcen ist es eine
auf realer P2P–Daten gründende Beobachtung in [19], die besagt: Je länger ein Knoten Mitglied des Overlay für x Minuten ist, desto wahrscheinlicher bleibt er das für x + 60 Minuten.
Das gilt zwar für kabelgebundene Netze, aber nicht für MANETs. Interferenzen u.ä. (vgl. auch
[20]) lassen diese Gewissheit nicht vermuten und führen in jedem Fall zu einem unfreiwilligen
Ausscheiden zusätzlich zum Churn (vgl. Gleichung (3)). Das Verschieben der Objektreferenzen
mag zwar für einen temporären Knoten entfallen, wird aber zugunsten einer größeren Fehlerwahrscheinlichkeit beim Suchen aufgegeben, da die Schlüssel nicht mehr homogen, sondern nur
noch auf die (potentiell ebenfalls ausfallenden) statischen Knoten verteilt. Insofern ist die von
Zöls et al. vorgenommene Analyse irreführend, da sie statisch argumentieren. Unberücksichtigt
bleiben insbesondere alle Aufwendungen, welche sich aus einer fehlerhaften Kategorisierung der
Knoten ergeben.
HCP muß, wie andere DHTs auch, unter zwei Perspektiven betrachtet werden: der Schicht 2
und 7 Mobilität. Die daraus resultierenden und jeweils überwiegenden Kosten sind ohne weitere
Annahmen nicht entscheidbar. Sie hängen von der Anwendung ab. So läßt sich als Applikation
für eine DHT ein Infrastrukturdienst überlegen, wie z.B. das DNS, der bezüglich des Churn
wenig volatil ist, aber in einem hoch mobilen MANET betrieben wird. Dem entgegengesetzt
wären z.B. Stadtnetze, bei denen die Zugehörigkeit zum Overlay durch die Benutzung von etwa
File Sharing Diensten bestimmt und die Teilnahme am MANET vom angeschalteten Rechner
festgelegt wird.
3.2.3
Ekta
In MANETs fungiert jeder Knoten als Router und besitzt somit umfangreichere Routing–
Einträge des Ad–Hoc Netzes. Diese sind mit zunehmender Bewegung der Endgeräte weniger
persistent: einzelne Einträge verändern ihre Güte oder verfallen ganz. Pakete der Applikationsschicht können dementsprechend entweder gar nicht oder nur verzögert zugestellt werden, da
erst eine neue Unicast Route ermittelt werden muß. Ekta [21], eine für MANETs konzipierte
Erweiterung von Pastry, steuert deshalb den Aufbau seiner Overlay Routing–Tabelle über die
Vermittlungsschicht unter der Voraussetzung, daß alle Knoten des Rechnernetzes auch Teil des
logischen Netzes sind und der Hash–Wert ihrer IP–Adressen8 als Identifizierer dient.
Jede Zelle der Overlay Routing Tabelle speichert nicht mehr nur einen Eintrag, sondern
alle für den Präfix bekannten. Die Ekta–Teilnehmer verwenden als Ad–Hoc Routing Protokoll
Dynamic Source Routing [22], demgemäß für eine (physikalische) Route alle Knoten zwischen
Sender und Ziel gespeichert werden. Gibt es eine Anfrage an die Ekta Routing Tabelle, werden
alle gefundenen Einträge an die Ad–Hoc Routing Tabelle weitergereicht. Diese wählt unter
den kürzesten Pfaden den aktuellsten Weg auf der Grundlage ihrer Daten aus. Neue Source
und damit Ekta Routen werden u.a. über das Mithören von Paketen gelernt. Das im Pastry
verwendete aktive Messen der RTT entfällt und vermindert die administrative Verkehrslast.
Der Vorteil von Ekta liegt in der späteren Ermittlung der zu verwendenden Unicast Route
8
Wir gehen hier von der IP–Adresse aus. Im Allgemeinen ist es die zur Vermittlung benutzte Adresse, also
z.B. auch die MAC–Adresse.
10
für einen Overlay–Schlüssel, auch als Late Binding bezeichnet. Der physikalische Knoten wird
genau dann bestimmt, wenn er benötigt wird. Das ist in Ekta möglich, weil eine stärkere Interaktion der Schichten untereinander stattfindet und Ekta als Knotenidentifizierer im Overlay
die IP–Adresse unter der Hash–Funktion benutzt. In einem klassischen schichtenbasierten Ansatz bezieht die DHT ihre Routing–Informationen durch das Overlay. Die Knoten des Overlays
tauschen Routen aus, d.h. Hash–Werte und dazugehörige IP–Adressen. Das Aufweichen der
Schichten hingegen bedeutet, daß ein logischer Knoten das ’reale’ Rechnernetz wahrnimmt.
Er verwertet Informationen darunterliegender Protokolle, in diesem Fall der Schicht 2 bzw. 3
unmittelbar. Ekta profitiert somit von Paketen, die nicht von der DHT erzeugt wurden. Das
wiederum ist nur dann möglich, wenn es ein Bindeglied zwischen den Schichten gibt, das Overlay
also anhand der IP–Adresse auf einen logischen Knoten folgern kann. Folglich müssen aber auch
alle Geräte des physikalischen Netzes Bestandteil des Overlays sein, da auf Basis der Pakete
und der damit erhaltenen Information keine Unterscheidung zwischen beiden Netzen gemacht
werden kann. Ekta gewinnt also Informationen von allen, eine Source Route beinhaltenden Paketen. Die Routing–Tabelle der Applikationsschicht ist dementsprechend genauso aktuell wie
die der Vermittlungsschicht.
Obgleich in Ekta die Schichten transparenter werden, bleiben sie sichtbar. Ekta verwaltet weiterhin die DHT–Logik und damit das Routing im Overlay. Abstrahiert erhält die DHT
mittels eines Push–Mechanismus’ alle eintreffenden Source Routen. Diese ordnet sie den jeweiligen Zellen zu, da sie und nicht die Vermittlungsschicht um die Abbildung zwischen Rechner–
und Overlay–Netz weiss. Um die Kosten, d.h. die Menge der auszutauschenden Daten zwischen den Schichten gering und aktuell zu halten, ist es erforderlich, daß sich Ekta mehr als
einen Eintrag pro Zelle vermerkt. Invalidiert eine Source Route nutzt Ekta einfach die verbleibenden Zelleinträge. Wäre die Anzahl an Einträgen wie im herkömmlichen Pastry auf eins
beschränkt, müßte Ekta mittels Pull im Fehlerfall die gesamte Ad–Hoc Routing Tabelle erfragen. Ein solches Verhalten würde mit der Menge an Abfragen und der Routing–Tabelle des
Ad–Hoc Netzes skalieren statt mit konstanter Zeit. Umgekehrt ist es möglich, die Logik der
DHT auch der Vermittlungsschicht bekannt zu machen. Damit entfallen aber modularisierte
Kombinationen zwischen Ad–Hoc Routing Protokollen und Verteilten Hash Tabellen. Das wäre insofern ungünstig, als daß gerade bei MANETs mit ihrer starken Anwendungsbezogenheit
situativ Vermittlungsprotokolle auszusuchen sind. Abhängig von der Aufgabe und der daraus
folgenden Mobilität, kann z.B. das Ad hoc On-Demand Distance Vector Routing oder Dynamic
Source Routing besser geeignet sein, wobei die DHT beiderseitig implementiert werden müßte,
statt nur Primitive zur Verfügung zu stellen.
Pucha et al. evaluieren Ekta im Vergleich zu einem modifizierten Pastry9 . Die initiale Phase
des Anschließens an den DHT–Ring wird angepaßt und die Proximity–Metrik wird durch die
Länge der Source Route Vektoren via DSR bereitgestellt [21], um grundlegende Eigenschaften von MANETs zu berücksichtigen. Das Dynamic Source Routing Protokoll wird unter der
Verwendung eines Path Caches 10 und eines Link Caches 11 betrieben. Welchen Modus Ekta
benutzt, beschreiben die Autoren nicht. Die Erfolgswahrscheinlichkeit einer Schlüsselanfrage
schwankt bei Ekta zwischen 98% und 100% und ist damit im Prinzip unabhängig von dem
Bewegungsverhalten der Geräte in einem von Yoon et al. erweiterten Random Waypoint Modell für MANETs. In dem von den Autoren verwendeten Pastry hingegen verringert sich die
Erfolgswahrscheinlichkeit bei sehr hoher Mobilität auf bis zu 35%, wobei dies unabhängig vom
9
Ferner untersuchen die Autoren das Verhalten für eine spezielle Anwendung der DHT, Resource Discovery.
Hierfür sei auf [21] verwiesen.
10
Die Wege werden sich pfadweise gemerkt.
11
Ein (Teil–)Graph des Ad Hoc Netzes wird gespeichert.
11
verwendeten DSR–Modus ist. Ekta profitiert demnach vom Erfolg des Routing–Protokolls, Pastry hingegen ist auf das Ausaltern vorhandener Overlay–Einträge angewiesen. Als weitere Größen betrachten Pucha et al. die durch das Overlay–Routing entstandenen Unkosten (Overhead )
und die mittlere Verzögerungszeit bei der Beantwortung einer Anfrage. Diese sind mit höherer
Mobilität für alle drei Ansätze steigend. Die Werte unterscheiden sich bei größter Mobilität
um ca. den Faktor fünf zwischen Ekta/DSR Link Cache und DSR Path Cache [21]. Mit Blick
auf [23] ist also davon auszugehen, daß ein Ekta–Knoten auf der Grundlage einer linkbasierten
Cache–Strategie für DSR operiert.
Die Ergebnisse bedürfen einer Erklärung. Tatsächlich läßt sich mit ihnen nicht nur die Frage
beantworten, ob ein schichtenorientierter Ansatz besser geeignet ist oder nicht, sondern auch,
wie stark das Ad–Hoc Routing–Protokoll Einfluß auf die Güte der DHT hat. Das Verhältnis von
erfolgreicher zu misserfolgter Schlüsselanfrage wird demnach maßgeblich von der eingesetzten
Architektur dominiert. Partizipiert Ekta an den per se vorhandenen Paketen im Netz, um sie
für den Aufbau seiner Routing–Tabelle zu verwenden, bleibt es robust gegenüber einer hohen
Bewegung. Passiert dies nicht, unterliegt es analog zu den in statischen Netzen auftretenden
Problemen bei hohem Churn im Internet. Das folgt unmittelbar aus [10] und [21]. Augenscheinlich verändern sich aber auch nicht die Kosten zur Aufrechterhaltung der DHT–Tabellen. Diese
bleiben, bei Akzeptierung entsprechender Qualität, gleich und werden vom Ad–Hoc Routing
Protokoll bestimmt (vgl. [21] mit [23]).
Ekta kann als einfachste Anpassung von Pastry an MANETs verstanden werden. Die DHT
nimmt Rücksicht auf eine angemessene Metrik zur PNS und nutzt die in MANETs verfügbaren
Daten, um Mobilität auf Schicht 2 und 7 gleichermaßen zu kompensieren, um den Preis, daß
alle Teilnehmer des MANETs auch Knoten des Overlay sein müssen.
3.3
Anmerkungen
Die vorgestellten Konzepte zur Verwendung von DHTs in MANETs nutzen verschiedene Ansätze aus, um Key–based Overlay Routing für MANETs zu optimieren. Back–Up Chord legt
die Schlüssel redundant ab, so daß trotz Ausfall eines Knotens die Objektreferenzen abrufbar
bleiben. Die Autoren wirken damit nur fehlender Verfügbarkeit entgegen, die DHTs selbst bei
stark volatilen Benutzern originär überwinden. Im Kontext von MANETs ist der von Jeong
et al. vorgeschlagene Ansatz damit sogar kontraproduktiv, da er eine doppelte Verkehrslast
erzeugt, die es in Ad–Hoc Netzen zu reduzieren gilt. Die Effizienz der verfolgten Lösung skaliert
bei fehlenden Voraussetzungen zudem nur mit der Anzahl an Back–Up Knoten.
HCP versucht hingegen, das Problem fluktuierender Benutzer zu reduzieren, indem es die
Schlüssel der Ressourcen nur auf Knoten mit einer hohen Lebenszeit verteilt. Dies setzt voraus,
daß Knoten mit höherer Lebenszeit mit einem geeignet Grad an Zuverlässigkeit identifizierbar
sind. Die Begründung der Autoren hierfür ist nicht korrekt. Die Voraussetzungen sind falsch. Die
Analyse läßt dynamische Prozesse und Fehlvorhersagen in der Zuverlässigkeit außer Acht. Sie
suggeriert, daß ein Ergebnis äquivalent zu einer generellen Verlangsamung aller Knoten erreicht
werden kann, was offensichtlich nicht stimmig ist. Insbesondere muß das Zusammenwirken von
Churn und MANET bedingtem Wechsel untersucht werden. Kann man aus der Lebenszeit im
Overlay auf die Lebenszeit im MANET schlußfolgern? Solche eine bedingte Persistenzwahrscheinlichkeit gilt es zu untersuchen. Eine ernsthafte Analyse des von Zöls et al. angebotenen
Algorithmus’ läßt sich aber erst nach einer Analyse der Voraussetzungen durchführen. Problematisch bleibt aber generell die Konzentrierung des Datenvolumens auf weniger Teilnehmer des
MANETs. Selbst wenn Knoten als statisch angenommen werden können, sind sie nicht als Infrastrukturkomponenten zu verstehen. Das (gewollte) Ausscheiden aus dem Overlay bleibt ihnen
12
freigestellt. Folglich müssen sie die verwalteten Objektreferenzen an einen Nachfolger übermitteln. Das kann, analog zu Back–Up Chord, zu einem ungewollt ’explosionsartigen’ Verkehrsaufkommen führen. Hiernach käme es unter Umständen zur Überlast im Netz, wodurch auch
die Robustheit der Ad–Hoc Routing–Protokolle gefordert wird. Eine sorgfältige dynamische
Analyse der gegenläufigen Prozesse mag ein Optimum zwischen Verteilung und Konzentration
auf statische Knoten als Funktion der Topologie und der Veränderungsparameter ergeben. Das
Konzept bleibt dann jedoch mit dem Problem behaftet, daß die Routing–Optimierung von den
(ebenfalls veränderlichen) Gegebenheiten der individuellen Overlay/MANET–Instanz abhängt.
Ekta durchbricht den klassischen, Schichten trennenden Ansatz und greift die vom MANET
gegebenen Chancen aktiv auf. Sämtliche Pakete im Netz, die Vermittlungsinformationen beinhalten, dienen auch der DHT. Somit können die bekannten Eigenschaften der Verteilten Hash
Tabellen erst einmal erhalten werden. Gleichzeitig wirft aber ein derartiger Ansatz architekturelle Fragen bezüglich der Entwicklung von Protokoll–Stacks sowie deren Flexibilität auf12 und
muß noch viel stärker für die Konzipierung des Netzes beantwortet werden. Tatsächlich setzt
solch ein Vorgehen voraus, daß als Identifizierer im Overlay der Hash–Wert der Vermittlungsadresse genommen wird. Zusätzlich müssen alle Teilnehmer des physikalischen Netzes auch Teil
des Overlays sein. Eine schwergewichtige Bedingung, die realistisch nur dann eingehalten werden kann, wenn entweder alle Knoten im MANET die gleiche Applikation benutzen oder die
DHT Bestandteil der Infrastruktur ist. Eine DHT kann nicht aus der Menge aller ’gewöhnlichen’
Pakete zwischen den für sie nützlichen und unnützlichen unterscheiden. Konsequenterweise darf
es auch nur eine DHT–Anwendung im MANET geben. Gibt es mindestens zwei Applikationen
mit disjunkten Teilnehmern, fällt es ebenso schwer, die unmarkierten Informationen an die
richtige Stelle weiterzuleiten.
Ein unmittelbares Verwerten simpel aufgefangener Pakete ließe sich für DHTs durch ihre
vollständige Einbeziehung in die unteren Schichten verwirklichen. Gewöhnliche Pakete müßten für jede Applikation einer DHT spezifisch gekennzeichnet werden. Letztlich bedeutet das,
daß sich die Subnetzwerkschicht verändert, sobald eine Overlay–Applikation gestartet wird.
Offensichtlich benötigt das einen weiten Konsens in der Verwendung von DHTs in MANETs.
Es gibt zwei weitere Gruppen von Lösungsansätzen, die aber nicht weiter ausgeführt wurden. Zum einen sind dies Geographic Based Hash Tables (GHTs) [24], [25], zum anderen clusterbildende DHTs [7], [26]. GHTs setzen voraus, daß der Knoten geographisch, z.B. mittels
GPS lokalisierbar ist. Die Struktur einer DHT wird bezüglich der Geographie optimiert und
ist damit nicht invariant zur räumlichen Bewegung. Demgegenüber versuchen clusterbasierte
Protokolle entsprechend eines günstigen Durchmessers, das MANET zu partitionieren, so daß
administrativer Verkehr weitestgehend lokal bezüglich eines Clusters bleibt.
Für GHTs ist zu beachten, daß das Ausmessen von räumlichen Distanzen rechenaufwändig
und damit nicht energieschonend ist [27], [20]. Dem gleichen Problem sehen sich aber auch
Ansätze ausgesetzt, die von ’zufällig’ im promiscuous Modus mitgehörten Paketen profitieren,
wie z.B. Ekta. Erschwerend kommt für GHTs hinzu, daß die kürzeste geographische Distanz
weiterhin nicht die kürzeste Routing–Distanz darstellen muß.
Sowohl GHTs als auch clusterbasierende Vorschläge koppeln die Effizienz der Hash Tabellen
an Ad–Hoc Routing Mechanismen. Sie umgehen damit die Frage nach Kosten und Nutzen für
zusätzlich aufgebrachte Rechenleistung oder Pakete ganz analog zu Ekta, sind aber gleichermaßen architekturellen Zwängen unterworfen – der stärkeren Vermischung von Schichten.
12
Dieses Problem könnte mit einer bidirektionalen Schnittstelle (Interface) zwischen den Schichten gelöst
werden.
13
4
Zusammenfassung und Ausblick
Mobile Ad–Hoc Netzwerke und Key–based Overlay Routing sind grundsätzlich zum Zusammenspiel geeignet. Ausgehend von der Überlegung, daß DHTs für mobiles Teilnehmerverhalten entworfen wurden, lassen sie sich mit einfachen Veränderungen auf MANETs übertragen.
Verteilte Hash Tabellen sehen sich seit ihrem initialen Einsatz im Internet mit volatilen Benutzern konfrontiert. Wegbrechende Verbindungen auf der Applikationsschicht verringern dabei die
Qualität beim Auffinden eines Schlüssels, können aber mit zusätzlichen Maßnahmen kompensiert werden. Dies ist zum einen mit einer höheren Austauschrate der Routing–Informationen
möglich, zum anderen aber auch mittels an typische Staueffekte angepasste Mechanismen. Ein
angemessenes Verhältnis zwischen der Overlay– und realen Netzwerkdistanz stellte ebenso den
Fokus frühzeitiger Untersuchungen dar.
MANETs werden als wenig beständig in ihrer Struktur angesehen. Aufgrund der physikalischen Beweglichkeit der Geräte oder Interferenzen zwischen ihnen wird jeder weitere Zwischenknoten in der Paketvermittlung als Gefahr für die Kommunikation wahrgenommen. DHTs sind
solche wegfallenden Verbindungen erst einmal bekannt. Sie können mit hohem Churn, speziell
dem unverhofften Bei– und Austritt der Overlay–Teilnehmer umgehen. Benutzermobilität ist
ihnen immanent. Die daraus resultierenden, traditionellen Wiederherstellungsprozeduren zur
Gewährleistung einer konsistenten DHT würden MANETs aber schaden, da ihre Kapazität im
Gegensatz zu festverdrahteten Netzen merklich beschränkt ist.
Der für DHTs nötige administrative Overlay–Verkehr kann aber, die Eigenschaften der
MANET–Teilnehmer nutzend, verringert werden. Ein Gerät im MANET ist ebenso Endgerät wie Router. Dadurch besitzt es deutlich mehr Informationen über die Netztopologie. Diese,
im Internet in der Regel nicht vorhandenen Daten können unter der Berücksichtigung einer
geeigneten Metrik für den Aufbau der Overlay Routing Tabelle benutzt werden. Die Effizienz
einer DHT wird dadurch auf das für die jeweilige Anwendung des MANETs auszuwählende
Ad–Hoc Routing Protokoll verlagert.
Insofern darf das Verhältnis von DHT und MANET als potentiell symbiotisch bezeichnet
werden. Eine (Churn gerüstete) DHT verhilft einem MANET zum effizienten schlüsselbasierten
Routing und Teilnehmer in MANETs befördern durch ihr zusätzliches Wissen um die Topologie
die Robustheit von Verteilten Hash Tabellen.
Untersuchungen von DHTs, die nicht mehr nur unmittelbar auf darunterliegende Schichten
aufsetzen und damit für MANETs tauglich werden, reduzieren sich somit auf die Güte der
Mobilen Ad–Hoc Routing Mechanismen sowie auf das Verhalten von Verteilten Hash Tabellen
bei stark fluktuierenden Benutzern im Allgemeinen.
Die vorliegende Arbeit hat Ansätze vorgestellt, die den Einsatz von DHTs in MANETs näher
bringen. Dennoch haben sie signifikante konzeptionelle Probleme. Benötigt wird ein Mechanimus, der leichtgewichtig bleibt und sich dennoch selbsttätig an die unterschiedlichen Eigenschaften von MANETs anpaßt, etwa wie der Nagle–Algorithmus von TCP an die Netzwerklast
und die Transportkosten gleichzeitig. Das ist derzeit nicht in Sicht.
Literatur
[1] K. Gummadi, R. Gummadi, S. Gribble, S. Ratnasamy, S. Shenker, and I. Stoica, “The
Impact of DHT Routing Geometry on Resilience and Proximity,” in SIGCOMM ’03: Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols
for computer communications. New York, NY, USA: ACM Press, 2003, pp. 381–394.
14
[2] I. Stoica, R. Morris, D. Liben-Nowell, D. R. Karger, M. F. Kaashoek, F. Dabek, and H. Balakrishnan, “Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications,”
IEEE/ACM Trans. Netw., vol. 11, no. 1, pp. 17–32, 2003.
[3] A. Rowstron and P. Druschel, “Pastry: Scalable, distributed object location and routing for
large-scale peer-to-peer systems,” in IFIP/ACM International Conference on Distributed
Systems Platforms (Middleware), Nov. 2001, pp. 329–350.
[4] D. Loguinov, J. Casas, and X. Wang, “Graph-Theoretic Analysis of Structured Peer-toPeer Systems: Routing Distances and Fault Resilience,” IEEE/ACM Trans. Netw., vol. 13,
no. 5, pp. 1107–1120, 2005.
[5] M. Castro, P. Druschel, Y. C. Hu, and A. Rowstron, “Proximity neighbor selection in tree–
based structured peer-to-peer overlays,” Microsoft Research, Tech. Rep. MSR-TR-2003-52,
2003.
[6] ——, “Topology-aware routing in structured peer-to-peer overlay networks,” in FuDiCo
2002: International Workshop on Future Directions in Distributed Computing, Bertinoro,
Italy, June 2002.
[7] T. Zahn and J. Schiller, “MADPastry: A DHT Substrate for Practicably Sized MANETs,”
in Proc. of 5th Workshop on Applications and Services in Wireless Networks (ASWN
2005), Paris, France, June 2005.
[8] R. Hekmat and P. V. Mieghem, “Degree distribution and Hopcount in Wireless Ad–hoc
Networks,” in ICON 2003 Eleventh IEEE international conference on networks. Piscataway: IEEE, 2003, pp. 603–609.
[9] M. Castro, P. Druschel, Y. C. Hu, and A. Rowstron, “Exploiting network proximity in
peer–to–peer overlay networks,” Microsoft Research, Tech. Rep. MSR-TR-2002-82, 2002.
[10] S. Rhea, D. Geels, T. Roscoe, and J. Kubiatowicz, “Handling Churn in a DHT,” in Proceedings of the 2004 USENIX Annual Technical Conference. Boston, MA, USA: USENIX
Association, June 2004, pp. 127–140.
[11] J. Li, J. Stribling, T. M. Gil, R. Morris, and M. F. Kaashoek, “Comparing the performance
of distributed hash tables under churn,” in Peer–to–Peer Systems III. Third International
Workshop, IPTPS 2004, Revised Selected Papers, ser. LNCS, G. M. Voelker and S. Shenker,
Eds., vol. 3279. Berlin Heidelberg: Springer-Verlag, 2005, pp. 87–99.
[12] H.-C. Hsiao and C.-T. King, “Mobility Churn in DHTs,” in Proceedings of the First International Workshop on Mobility in Peer-to-Peer Systems (MPPS) (ICDCSW’05), vol. 8.
Washington, DC, USA: IEEE Computer Society, June 2005, pp. 799–805.
[13] P. Gupta and P. R. Kumar, “The capacity of wireless networks,” IEEE Transactions on
Information Theory, vol. 46, no. 2, pp. 388–404, 2000.
[14] M. Grossglauer and D. N. C. Tse, “Mobility Increases the Capacity of Ad Hoc Wireless
Networks,” IEEE/ACM Trans. Netw., vol. 10, no. 4, pp. 477–486, 2002.
[15] J. Li, C. Blake, D. S. D. Couto, H. I. Lee, and R. Morris, “Capacity of Ad Hoc wireless
networks,” in MobiCom ’01: Proceedings of the 7th annual international conference on
Mobile computing and networking. New York, NY, USA: ACM Press, 2001, pp. 61–69.
15
[16] H.-J. Jeong, D. Kim, J. Song, B. Kim, and J.-S. Park, “Back-Up Chord: Chord Ring
Recovery Protocol for P2P File Sharing over MANETs,” in International Conference on
Computational Science (2), ser. LNCS, V. S. Sunderam, G. D. van Albada, P. M. A. Sloot,
and J. Dongarra, Eds., vol. 3515. Berlin Heidelberg: Springer-Verlag, 2005, pp. 477–484.
[17] S. Zöls, R. Schollmeier, W. Kellerer, and A. Tarlano, “The Hybrid Chord Protocol: A
Peer-to-Peer Lookup Service for Context-Aware Mobile Applications,” in Networking –
ICN 2005. 4th International Conference on Networking, Proceedings, Part II, ser. Lecture
Notes in Computer Science, P. Lorenz and P. Dini, Eds., vol. 3421. Berlin Heidelberg:
Springer-Verlag, April 2005, pp. 781–792.
[18] S. Zöls, R. Schollmeier, and W. Kellerer, “Making chord go mobile,” in Kommunikation
in Verteilten Systemen (KiVS), Kurzbeiträge und Workshop der 14. GI/ITG-Fachtagung
Kommunikation in Verteilten Systemen (KiVS 2005) Kaiserslautern, 28. Februar - 3. März
2005, ser. LNI, P. Müller, R. Gotzhein, and J. B. Schmitt, Eds., vol. 61. Bonn: GI, 2005,
pp. 215–218.
[19] P. Maymounkov and D. Maziéres, “Kademlia: A Peer-to-Peer Information System Based
on the XOR Metric,” in Peer-to-Peer Systems: First International Workshop, IPTPS 2002,
ser. LNCS, P. Druschel, F. Kaashoek, and A. Rowstron, Eds., vol. 2429. Berlin Heidelberg:
Springer-Verlag, 2002, pp. 53–65.
[20] C. S. R. Murthy and B. S. Manoj, Ad Hoc Wirless Networks. Architectures and Protocols, ser. Prentice Hall Communications Engineering and Emerging Technologies, T. S.
Rappaport, Ed. Upper Saddle River, NJ, USA: Prentice Hall PTR, 2004.
[21] H. Pucha, S. M. Das, and Y. C. Hu, “Ekta: An Efficient DHT Substrate for Distributed
Applications in Mobile Ad Hoc Networks,” in Proceedings of the 6th IEEE Workshop on
Mobile Computing Systems and Applications (WMCSA 2004). Washington, DC, USA:
IEEE Computer Society, December 2004, pp. 163–173.
[22] D. B. Johnson, D. A. Maltz, and Y.-C. Hu, “The Dynamic Source Routing Protocol for
Mobile Ad Hoc Networks (DSR),” IETF MANET Working Group, IETF Internet Draft –
work in progress 10, July 2004.
[23] Y.-C. Hu and D. B. Johnson, “Caching strategies in on-demand routing protocols for
wireless ad hoc networks,” in MobiCom ’00: Proceedings of the 6th annual international
conference on Mobile computing and networking. New York, NY, USA: ACM Press, 2000,
pp. 231–242.
[24] L. Fang and R. Ruonan, “Analysis of GHT in Mobile Ad Hoc Networks,” in Parallel and
Distributed Processing and Applications - ISPA 2005 Workshops: ISPA 2005 International
Workshops, AEPP, ASTD, BIOS, GCIC, IADS, MASN, SGCA, and WISA, Nanjing,
China, November 2-5, 2005. Proceedings, ser. LNCS, G. Chen, Y. Pan, M. Guo, and J. Lu,
Eds., vol. 3759. Berlin Heidelberg: Springer-Verlag, October 2005, pp. 35–44.
[25] J. B. Tchakarov and N. H. Vaidya, “Efficient Content Location in Wireless Ad Hoc Networks,” in Proc. of 5th IEEE International Conference on Mobile Data Management (MDM
2004). IEEE Computer Society, 2004, pp. 74–86.
16
[26] F. Araújo, L. Rodrigues, J. Kaiser, C. Liu, and C. Mitidieri, “CHR: A Distributed Hash
Table for Wireless Ad Hoc Networks,” in Proc. of 25th International Conference on Distributed Computing Systems Workshops (ICDCS 2005 Workshops). IEEE Computer Society,
2005, pp. 407–413.
[27] C.-K. Toh and V. Vassiliou, “The Effects of Beaconing on the Battery Life of Ad Hoc
Mobile Computers,” in Ad Hoc Networking, C. E. Perkins, Ed. Upper Saddle River, NJ,
USA: Addison Wesley, 2000, ch. 9, pp. 299–321.
17