Realisierung einer Testumgebung für Ad-hoc-Netze

Technische Universität Ilmenau
Institut für Informationstechnik
Fachgebiet Kommmunikationsnetze
Realisierung einer Testumgebung für Ad-hoc-Netze
Studienjahresarbeit
Marco Kramer
Betreuer:
Dipl.-Ing. Maik Debes, FG Kommunikationsnetze
Verantwortlicher Hochschullehrer:
Prof. Dr. Jochen Seitz, FG Kommunikationsnetze
INHALTSVERZEICHNIS
I
Inhaltsverzeichnis
1 Einleitung
1
2 Routing in Ad-hoc-Netzen
3
2.1
2.2
2.3
.
5
.
7
.
15
.
24
Weitere Routingalgorithmen . . . . . . . . . . . . . . . . . . . . . . . .
28
2.2.1
28
Unicast“ Routingalgorithmen (topologiebasiert) . . . . . . . . . . . .
”
2.1.1 Reaktive Routingalgorithmen ( Source-Initiated On-Demand“)
”
2.1.2 Proaktive Routingalgorithmen ( Table-Driven“) . . . . . . . .
”
2.1.3 Hybride Routingalgorithmen . . . . . . . . . . . . . . . . . . .
Unicast“ Routingalgorithmen (geographiebasiert) . . . . . . . .
”
2.2.2
Security“ Routingalgorithmen . . . . . . . . . . . . . . . . . .
”
Vergleich einiger Routingverfahren . . . . . . . . . . . . . . . . . . . .
3 Softwarekomponenten für Ad-hoc-Netze
3.1
Implementierungen der Routingprotokolle
30
32
. . . . . . . . . . . . . . . .
32
3.1.1
AODV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.1.2
ARAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.1.3
DSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.1.4
FSR-ATR“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
”
OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
Tools für Ad-hoc-Netze . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.2.1
51
3.1.5
3.2
30
3.2.2
3.2.3
APE ( Ad hoc Protocol Evaluation“) testbed“ . . . . . . . . .
”
”
Click! Modular Router“ . . . . . . . . . . . . . . . . . . . . . .
”
LUNAR“ ( Lightweight Underlay Network Ad hoc Routing“) .
”
”
45
52
54
INHALTSVERZEICHNIS
3.2.4
3.2.5
3.2.6
PACMAN“ ( Passive Autoconfiguration for Mobile Ad hoc
”
”
Networks“) und WNTE“ ( Wireless Network Topology Emu”
”
lator“) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ViTAN“ ( Visualization Tool for Ad Hoc Networks“) . . . . .
”
”
Zusammenfassung und Gegenüberstellung der Tools . . . . . . .
4 Konzeption der Testumgebung
II
55
55
57
60
4.1
Testabsichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.2
Verwendete Hardware- und Softwarekomponenten . . . . . . . . . . . .
61
4.3
Testaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.4
Festlegen der Testpunkte und Definition der Ziele . . . . . . . . . . . .
66
4.4.1
Messungen zur erzeugten Netzlast . . . . . . . . . . . . . . . . .
66
4.4.2
Messungen bei Veränderung der Topologie . . . . . . . . . . . .
66
4.4.3
Messungen zur mittleren Übertragungsrate . . . . . . . . . . . .
66
4.4.4
Messungen mit unterschiedlichen Betriebssystemen . . . . . . .
66
4.4.5
Messungen mit unterschiedlichen Routingparametern . . . . . .
67
5 Realisierung einer Testumgebung
5.1
68
Verwendete Hardware- und Softwarekomponenten . . . . . . . . . . . .
68
5.1.1
Konfiguration der WLAN-Karte . . . . . . . . . . . . . . . . . .
68
5.1.2
Verwendete Implementierungen . . . . . . . . . . . . . . . . . .
69
5.1.3
Verwendete Tools für
5.1.4
Monitoring“ und zur Erfassung des
”
Network-Traffic“ . . . . . . . . . . . . . . . . . . . . . . . . . .
”
Verwendete Tools und Software zur Erzeugung von Netzwerk-
75
80
5.2
verkehr ( Network Traffic“) . . . . . . . . . . . . . . . . . . . .
”
Testaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3
Testdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.3.1
5.3.2
81
Verwendete Hardware- und Softwarekomponenten für die Messungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
Beschreibung der Messungen . . . . . . . . . . . . . . . . . . . .
88
INHALTSVERZEICHNIS
III
6 Messungen und Ergebnisse
93
6.1
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
6.2
Messungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
6.2.1
Messungen zur erzeugten Netzlast . . . . . . . . . . . . . . . . .
94
6.2.2
Messungen bei Veränderung der Topologie . . . . . . . . . . . .
99
6.2.3
Bewertung der mittleren Übertragungsrate . . . . . . . . . . . . 105
6.2.4
Messungen mit unterschiedlichen Betriebssystemen . . . . . . . 107
6.2.5
Messungen mit unterschiedlichen Routingparametern . . . . . . 110
7 Ausblick
114
8 Zusammenfassung
116
A Informationen zu den Softwarekomponenten
118
A.1 Implementierungen der Routingprotokolle
. . . . . . . . . . . . . . . . 118
A.1.1 AODV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
A.1.2 ARAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
A.1.3 DSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
A.1.4
FSR-ATR“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
”
A.1.5 OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
A.2 Tools für Ad-hoc-Netze . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
B Hinweise zur realisierten Testumgebung
134
B.1 Verwendete Hardwarekomponenten . . . . . . . . . . . . . . . . . . . . 134
B.1.1 Überblick zu den Hardwarekomponenten . . . . . . . . . . . . . 134
B.1.2 Konfiguration der WLAN-Karte . . . . . . . . . . . . . . . . . . 138
B.2 Verwendete Softwarekomponenten . . . . . . . . . . . . . . . . . . . . . 144
B.2.1
B.2.2
B.2.3
B.2.4
B.2.5
AODV-UU“ (v0.9) . . . . .
”
Windows AODV“ (v0.1.14)
”
OLSRD“ (v0.48) . . . . . .
”
iPerf“ . . . . . . . . . . . .
”
FTP . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 144
. . . . . . . . . . . . . . . . . . . . 144
. . . . . . . . . . . . . . . . . . . . 146
. . . . . . . . . . . . . . . . . . . . 147
. . . . . . . . . . . . . . . . . . . . 149
INHALTSVERZEICHNIS
C Veränderungen an den Softwaretools
IV
151
C.1 Modifikation von IPTraf“ . . . . . . . . . . . . . . . . . . . . . . . . . 151
”
C.2 Modifikation vom Network Traffic Monitor“ . . . . . . . . . . . . . . . 153
”
D Installationshinweise zu Click!“ und PACMAN“
157
”
”
D.1 Installationshinweise zu Click! Modular Router“ . . . . . . . . . . . . 157
”
D.2 Installationshinweise zu PACMAN“ . . . . . . . . . . . . . . . . . . . 159
”
E Inhalt des Datenträgers
160
Abbildungsverzeichnis
164
Tabellenverzeichnis
166
Abkürzungsverzeichnis
170
Literaturverzeichnis
174
Softwareverzeichnis
177
KAPITEL 1. EINLEITUNG
1
Kapitel 1
Einleitung
Drahtlose Mobile Ad-hoc-Netze, Mobile Ad-hoc Networks“ (MANETs), setzen sich
”
aus Knoten zusammen, die über Funk miteinander kommunizieren. Diese Netze
gewinnen durch die steigende Verbreitung von WLAN immer mehr an Bedeutung.
Die Kennzeichen der herkömmlichen Funknetze sind eine feste Infrastruktur und
zentrale Verwaltung. Die Knoten können nur mit Hilfe eines Zugangspunktes die
bestehende, feste Infrastruktur erreichen. Zum Aufbau einer Verbindung muss sich
der Knoten in der Funkreichweite des Zugangspunktes befinden.
Im Gegensatz zu den herkömmlichen Funknetzen sind Ad-hoc-Netz Multi-Hop“”
Netze, das bedeutet, dass die Kommunikation über die Reichweite einer Quelle hinaus
von anderen Knoten weitergeleitet wird. Die Verbindungen zwischen den Knoten
erfolgt Peer-to-Peer“ (PTP) und alle Knoten fungieren sowohl als Endsystem als
”
auch als Router. Die Netzstruktur von Ad-hoc-Netzen entsteht dynamisch durch
Selbstorganisation und Selbstverwaltung. Es existiert keine zentrale Instanz, durch
die das Routing oder die Netzstruktur festgelegt wird. Somit ist das Management in
Ad-hoc-Netzen verteilt. Bedingt durch die Mobilität der Knoten ist die Netzstruktur
zeitinvariant und die Topologie kann sich kontinuierlich verändern, was gegebenenfalls
neue Routen erfordert. Die meisten Routingverfahren verwenden zur Signalisierung
den
Beacon“-Mechanismus. Dieses Signal wird in regelmäßigen Abständen von
”
jedem Knoten versendet und somit kennt jeder Knoten seine direkten Nachbarn.
Alle Knoten im Netz verwenden dieselbe Frequenz, was natürlich zur Begrenzung
KAPITEL 1. EINLEITUNG
2
der Netzkapazität führt. Der Zugang zum Ad-hoc-Netz erfolgt durch Interaktion mit
anderen Knoten. In einem Ad-hoc-Netz können auch feste Knoten vorhanden sein,
die beispielsweise einen Zugang zu einem Festnetz besitzen.
Mögliche Beispielszenarien sind Konferenzen, Einsätze kleiner militärischer oder
ziviler Teams, Sensornetzwerke oder einfach frei bewegliche, unabhängige Knoten.
Diese Arbeit beschäftigt sich mit den momentan frei verfügbaren Softwarekomponenten und der Realisierung einer Testumgebung für Ad-hoc-Netze. Mit Hilfe der Testumgebung wird eine erste Bewertung der Implementierungen und dem Routing in diesen
Netzen vorgenommen. Da das Routing in Ad-hoc-Netzen problematisch ist, werden zu
Beginn die vorhandenen Routingprotokolle aufgezeigt und die Funktionsweise diskutiert.
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
3
Kapitel 2
Routing in Ad-hoc-Netzen
In dem folgenden Kapitel werden Aussagen zum Routing in Ad-hoc-Netzen und zu
vorhandenen Routingprotokollen getroffen. Diese gewonnenen Informationen dienen
dem Verständnis und bilden die Grundlage für weitere Betrachtungen zum Routingverhalten.
Ad-hoc-Netze bestehen aus mobilen Geräten, die über Funk miteinander kommunizieren. Bedingt durch die Positionsveränderungen der mobilen Geräte kommt es zu
ständigen Rekonfigurationen der Netztopologie. Diese Netzdynamik stellt neue Herausforderungen an die Rountingverfahren. Im Internet werden die beiden Verfahren
Distance Vector Routing“ und Link State Routing“ verwendet. Für Ad-hoc-Netze
”
”
müssen diese beiden Verfahren entsprechend verändert und angepasst werden. In den
Ad-hoc-Netzen sind keine Router vorhanden, deshalb sollte jeder Knoten weiterleiten
können und mit mindestens einem Knoten in Verbindung stehen, der weiterleiten kann.
Dies wird aber durch die Netzdynamik und den damit verbundenen Veränderungen
erschwert.
Somit unterliegen die Routingprotokolle in Ad-hoc-Netzen wesentlich größeren Anforderungen als wie im Internet:
• Bandbreite:
Die Routingprotokolle in Ad-hoc-Netzen sollten schonend mit der Bandbreite
umgehen, denn diese ist wesentlich kleiner als die von Kabelnetzen.
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
4
• Konvergenz:
Die Konvergenz ist die Fähigkeit, nach Veränderung der Topologie möglichst
schnell mit stabilen Routing fortzufahren. Dabei hängt das Konvergenzkriterium
in der Regel von denen im Netz vorhandenen Routern ab, d.h. je mehr Router
im Netz vorhanden sind, desto geringer ist die Konvergenz.
Neben den bereits genannten Anforderungen existieren verschiedene wünschenswerte
Eigenschaften der Routingprotokolle:
• Anpassen an den Bedarf für nicht gleich verteilte Netzlast:
Die Netzstruktur sollte nicht starr anhand von Verbindungen aufgebaut werden,
sondern auch an den entsprechenden Bandbreitenbedarf der einzelnen Verbindungen angepasst werden. Somit könnten stark frequentierte Netzbereiche entlastet werden, indem ein Datenpaket einen größeren Umweg bzw. eine andere
Route benutzt. Dies könnte wiederum zur Erhöhung der Geschwindigkeit beitragen. Aber diese Forderung ist an die QoS-Fähigkeit des Netzes gebunden.
• Energieeffizienz und Reichweite:
Mobile Geräte werden mit Hilfe von Batterien betrieben, die nur eine begrenzte
Lebensdauer besitzen. Deshalb sollte in einem Ad-hoc-Netz möglichst Energieeffizient gearbeitet werden, d.h. die Routingprotokolle sollten den Energieverbrauch und die Reichweite berücksichtigen. Sowohl die Datenmenge als auch die
Sendehäufigkeit sollten so gering wie möglich sein und für die Berechnung der
Routen sollten effiziente Algorithmen benutzt werden.
• Geringere Netzlast:
Diese Forderung ergibt sich auch aus der Anforderung in Hinblick auf Energieeffizienz und Reichweite. Außerdem ist die Bandbreite von mobilen Funkstrecken
wesentlich kleiner als die von Kabelnetzen und deshalb sollten die Routingprotokolle bandbreiteschonend sein.
• Quality of Service“ (QoS):
”
QoS ist die Gesamtheit von Merkmalen und Merkmalswerten, welche die Qua”
lität der Diensterbringer charakterisieren“ [Schneider and Werner, 2002]. QoS
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
5
gewinnt im Bereich der Netzwerke immer mehr an Bedeutung. Die Gewährleistung von QoS ist bei mobilen Netzen sehr schwierig, denn diese Netze besitzen Einschränkungen, wie beispielsweise bei Energie und Reichweite. Außerdem
besitzen Funknetze oft Störungen, die unberechenbar sind. In Ad-hoc-Netzen
gestaltet sich das Management recht schwierig, denn es existiert keine zentrale
Managementstation. Deshalb müssen die Zugriffs- und Routingtechniken für die
Einhaltung des QoS sorgen. Dies geschieht, indem die Routen so gewählt werden,
dass diese die Anforderungen erfüllen.
• Sicherheit:
Die Knoten eines Ad-Hoc-Netzes kommunizieren über Funk miteinander und die
Funkwellen bilden ein wesentliches Sicherheitsrisiko, denn diese sind sehr einfach
abzuhören und zu stören. Entsprechende Maßnahmen sind erforderlich, um den
Angriff von außen zu verhindern. Eine mögliche Lösung bietet die Verschlüsselung.
• Schleifenfreiheit:
Die Routingprotokolle sollten frei von Schleifen sein, dafür sind entsprechende
Mechanismen erforderlich. Die meisten Routingprotokolle erfüllen diese Anforderung.
2.1
Unicast“
”
basiert)
Routingalgorithmen
(topologie-
Diese Routingalgorithmen lassen sich in drei Gruppen unterteilen:
1. Reaktive Routingalgorithmen ( Source-Initiated On-Demand“),
”
2. Proaktive Routingalgorithmen ( Table-Driven“) und
”
3. Hybride Routingalgorithmen.
Die Abbildung 2.1 liefert einen Überblick zu den unterschiedlichen Algorithmen und
den dazugehörigen Routingverfahren.
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
6
„Unicast“-Routingalgorithmen
„Unicast“-Routingalgorithmen
(topologiebasiert)
(topologiebasiert)
Proaktiv
ProaktivRoutingalgorithmen
Routingalgorithmen
(„Table-Driven“)
(„Table-Driven“)
Reaktiv
ReaktivRoutingalgorithmen
Routingalgorithmen
(„Source-Initiated
(„Source-InitiatedOn-Demand“)
On-Demand“)
DSDV à CGSR
WRP
FSR
OLSR
STAR
TBRPF
ABR à SSR
AODV
DSR
LMR à TORA
PAR
RDMAR
Abbildung 2.1: Unicast“ Routingalgorithmen
”
2002] & [Engel and Roth, 2005]
Hybrid
HybridRoutingalgorithmen
Routingalgorithmen
CBRP
CEDAR
FSR
ZRP
(topologiebasiert)
[Kasel,
Die Routingalgorithmen können auch in flache und hierarchische Protokolle unterteilt
werden. In kleineren Netzen werden die flachen Protokolle und in größeren Netzen die
hierarchischen Protokolle verwendet. Die hierarchischen Protokolle teilen das Netz in
so genannte Cluster“ ein und die Route wird nur entlang der Cluster“ bestimmt.
”
”
Die Routingalgorithmen in Ad-hoc-Netzen basieren auf zwei Verfahren:
1. Distance Vector Routing“
”
Bei den Routingverfahren, die auf dem Distance Vector Routing“ basieren,
”
speichert jeder Knoten eine Tabelle mit den besten Entfernungen (z.B. Anzahl
der Hops“) zu jedem Ziel und dem dazugehörigen Ausgang. Um die erforder”
lichen Informationen stets aktuell zu halten, versenden die einzelnen Knoten
regelmäßig die ihnen zur Verfügung stehenden Informationen zu der kürzesten
Route. Müssen Daten weitergeleitet werden, entscheidet sich der Knoten anhand
der ihm zur Verfügung stehenden Informationen für die beste Route.
2. Link State Routing“
”
Jeder Knoten versendet periodisch den Status seiner Links“ zusammen mit
”
dem vom Nachbarn empfangenen Link Status“. Dadurch kennt jeder Knoten
”
die gesamte Netztopologie. Die kürzeste Route zu jedem Knoten kann mit dem
Dijkstra´s Shortest Path First Algorithm“ ermittelt werden.
”
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
2.1.1
7
Reaktive Routingalgorithmen ( Source-Initiated On”
Demand“)
Reaktive Routingalgorithmen versuchen, sobald ein Knoten Daten zu einem anderen
Knoten senden möchte, eine passende Route zu finden. Diese Route bleibt so lange
bestehen, bis die Datenübertragung beendet oder der Empfänger im Netz nicht mehr
erreichbar ist. Es werden nur Informationen über die lokalen Nachbarn gespeichert, die
so genannten Local State Informations“.
”
Bei den reaktiven Verfahren werden drei wesentliche Basisfunktionen ausgeführt:
1. Routenerstellung ( Route Discovery“)
”
Innerhalb dieser Phase wird versucht, eine passende Route zum Ziel zu finden.
2. Routenwartung ( Route Maintenance“)
”
In dieser Phase wird versucht, diese gefundene Route während des Gebrauchs
aufrecht zu halten und zu pflegen.
3. Löschen alter Routen.
Der Vorteil dieser Protokolle ist eine vergleichbar geringe Netzlast, denn nur für
benötigte Routen müssen Daten ausgetauscht werden. Nachteil ist die Zeitdauer beim
Verbindungsaufbau, denn eine passende Route muss erst gefunden werden.
Associativity-Based Routing“ (ABR)
”
ABR definiert eine neue Metrik für das Routing, die als Degree of Association Sta”
bility“ bekannt ist. Dieses Routingverfahren ist frei von Schleifen, Deadlocks“ und
”
Paketduplikaten. Die Routen werden anhand der assoziativen Knotenzustände so ausgewählt, dass diese langlebig sind. Zur Signalisierung, dass ein Knoten noch existiert,
sendet jeder Knoten ein periodisches Leuchtfeuer ( Beacon“). Empfängt der Nachbar”
knoten ein Beacon“, führt dieser ein Update“ seiner assoziativen Tabelle ( Assozia”
”
”
tivity Table“) durch. Für jeden empfangenen Beacon“ inkrementiert der Knoten den
”
Assoziativitätszähler ( Associativity Tick“) des Knotens, von dem er den Beacon“
”
”
empfangen hat. Assoziative Stabilität bedeutet Verbindungsstabilität eines Knotens
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
8
in Bezug zu anderen Knoten über Zeit und Raum. Ein hoher Wert des Assoziativitätszählers in Bezug auf einen Knoten zeigt einen niedrigen Zustand von Knotenmobilität an, während ein niedriger Wert einen hohen Zustand von Knotenmobilität
anzeigt. Der Assoziativitätszähler wird zurückgesetzt, wenn der Nachbarknoten oder
der Knoten selber die Nachbarschaft verlässt, d.h. sich aus der Reichweite bewegt. Die
grundlegende Zielsetzung von ABR ist das Finden von langlebigen Routen für Ad-hocNetze.
ABR ist ein Kompromiss zwischen Broadcast“ und Point-to-Point“ (PTP)-Routing,
”
”
und benutzt die verbindungsorientierte Paketweiterleitung. Die Auswahl der Route
basiert hauptsächlich auf den gesamten Assoziativitätszählern der Knoten entlang der
Route. Obwohl möglicherweise nicht die kürzeste Route erstellt wird, neigt diese zu
Langlebigkeit. Langlebige Routen ergeben weniger Routenrekonstruktionen und erbringen folglich höheren Durchsatz. Jedoch um die Assoziativität einer Route beizubehalten, beruht ABR auf der Tatsache, dass jeder Knoten regelmäßig Beacons“
”
versendet. Das Erzeugen dieser Beacons“ verursacht eine zusätzliche Netzlast.
”
Signal Stability Routing“ (SSR)
”
Dieses Routingprotokoll ist eine Weiterentwicklung von ABR. SSR verwendet als Routingmetriken die Signalstärke und die Mobilität der Teilnehmer. Ziel ist die Nutzung
von Routen mit großen Signalstärken. Da die Routenauswahl mit Hilfe des Algorithmus nicht unbedingt die kürzesten Routen, d.h. mit den wenigsten Hops“, wählt,
”
neigen diese zu mehr Beständigkeit und zu einer längeren Lebenszeit. SSR setzt sich
aus zwei Teilprotokollen zusammen:
• Dynamic Routing Protocol“ (DRP)
”
DRP wird zur Verwaltung der Signal Stability Table“ (SST) und Routing
”
”
Table“ (RT) verwendet. Die SST erfasst dabei die Signalstärken der Nachbarknoten. DRP nimmt alle empfangenen Pakete entgegen und passt die Tabellen
entsprechend an. Die Pakete werden danach an das Static Routing Protocol“
”
(SRP) weitergeleitet.
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
9
• Static Routing Protocol“ (SRP)
”
Mit Hilfe von SRP werden die Pakete weitergeleitet und in den Stack abgelegt. Existiert keine Route zum Weiterleiten, wird ein Route Request“ (RREQ)
”
versendet. Dieser wird aber nur weitergeleitet, wenn er über ein starkes Signal
empfangen wird. Die Antwort wird vom Zielknoten auf demselben Weg zurückgesendet. Erhält die Quelle keine Antwort, so wird nach einem Timeout“ ein neuer
”
RREQ versendet. Beim Auftreten eines Fehlers wird die Quelle benachrichtigt
und mit Hilfe einer Erase Message“ werden alle Netzknoten informiert.
”
Ad-hoc On-Demand Distance Vector“ (AODV)
”
AODV minimiert die Anzahl der benötigten Broadcasts“, denn die Routen werden
”
nur bei Bedarf bestimmt. Die Routingtabellen werden nicht ständig aktualisiert und
komplett erstellt. Die Knoten, die nicht am Routing teilnehmen, führen kein Update“
”
ihrer Routinginformationen durch und tauschen auch keine Routinginformationen
aus. Beim Wegfall einer Route werden die Informationen nur an die Knoten gesendet,
welche diese benutzen. Dies ist vorteilhaft, denn häufig werden Routen nicht verwendet.
RREQ
B
E
RREQ
RREQ
RREQ
RREQ
RREQ
RREP
H
G
D
A
RREQ
RREP
RREP
RREP
RREQ
J
RREQ
I
F
C
RREQ
RREQ
RREQ
Abbildung 2.2: AODV-Beispiel: Route zwischen Knoten A und J [Tonnesen, 2004]
Die Abbildung 2.2 verdeutlicht den Routenaufbau bei AODV. Der Quellknoten A will
Daten zum Zielknoten J senden, kennt aber nicht die erforderliche Route und star-
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
10
tet deshalb den Route Discovery“-Prozess. Daraufhin wird per Broadcast“ das Netz
”
”
mit RREQ Messages“ geflutet. Über den Knoten H empfängt der Zielknoten J das
”
Paket und erzeugt ein Route Reply“ (RREP). Der RREP wird per Unicast“ an den
”
”
Quellknoten A über die ermittelte Route zurückgeschickt.
AODV verwendet Sequenznummern. Mit dem gesendeten RREQ erhöht jeder Knoten
seine Sequenznummer, somit sind zusammen mit der Knotenadresse die RREQs einzigartig. Wird ein RREQ doppelt empfangen, so wird dieser verworfen.
Die Routingtabelle wird also nur bei einer Anforderung einer Route gefüllt. Bewegt
sich ein Knoten oder kommt es zu einem Übertragungsfehler, wird eine Link Failure
”
Message“ versendet und der Mechanismus zur Ermittlung einer Route neu gestartet.
Kommt es zur Bewegung der Quelle, kann diese ebenfalls die Berechnung neu anstoßen.
Die Vorteile von AODV sind geringere Latenz und weniger Netzwerkverkehr.
Dynamic Source Routing“ (DSR)
”
Wenn die Quelle Daten senden will, aber die Route zum Ziel nicht kennt, wird der
Route Discovery“-Prozess gestartet. Die Quelle flutet per Broadcast“ das Netz
”
”
mit einer RREQ Message“, diese besitzt eine eindeutige ID ( Identifier“), Ziel”
”
und Quelladresse. Der RREQ-Prozess ist in der Abbildung 2.3 dargestellt. Mit Hilfe
„Route Request“ („Source“, „Destination“, „Hops“)
Route Cache
...
RREQ(1,5,{1,2,4})
Route Cache
...
Ziel
5
4
6
RREQ(1,5,{1,2})
RREQ(1,5,{1})
Quelle
1
Route Cache
...
2
Route Cache
...
RREQ(1,5,{1,2})
3
Route Cache
(3,5)>[3,6,5]
...
Abbildung 2.3: DSR - Route Request“ [Bahr, 2002]
”
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
11
der ID werden Paketduplikate erkannt und verworfen. Beim Erhalten eines RREQs
vergleicht der entsprechende Knoten als erstes die Zieladresse mit seiner eigenen. Ist
es dieselbe, sendet der Knoten die Route mittels eines RREPs an die Quelle zurück.
Ist dieses Paket nicht für den Knoten bestimmt, existieren zwei Möglichkeiten, um
fortzufahren. Im ersten Fall hat der Knoten den Request“ mit dieser ID erst kürzlich
”
empfangen und verwirft das Paket. Im zweiten Fall ist es ein neuer Request“, der
”
Knoten fügt seine Adresse an die Route im RREQ und schickt diesen an alle seine
Nachbarn. Dies führt allerdings dazu, dass bei jeder Suche einer Route der RREQ im
ganzen Netzwerk verteilt wird ( Flooting“). Kennt ein Empfänger eine Route zum
”
Ziel oder erreicht die Message“ den Empfänger, wird die Route vervollständigt und
”
zurückgeschickt.
In der Abbildung 2.4 ist die Route Reply“-Phase dargestellt. Die Antwort des Ziel”
„Route Reply“ („Source“, „Destination“, „Sourceroute“)
Route Cache
(5,1) > {5,4,2,1}
(5,2) > {5,4,2}
(5,4) > {5,4}
...
Ziel
5
RREQ(5,1,{1,2,4,5})
Route Cache
...
4
6
RREQ(5,1,{1,2,4,5})
RREQ(5,1,{1,2,4,5})
2
RREQ(5,1,{1,2,3,6,5})
Quelle
1
Route Cache
(1,5) > {1,2,4,5},
{1,2,3,6,5}
...
Route Cache
(2,1) > {2,1}
(2,4) > {2,4}
...
3
Route Cache
(3,1) > {3,2,1}
(3,2) > {3,2}
(3,5) > {3,6,5}
...
Abbildung 2.4: DSR - Route Reply“ [Bahr, 2002]
”
knotens wird mit einer RREQ Message“ versendet. Dabei wird der RREP mit einem
”
neuen RREQ zur Quelle zurückgeschickt. Somit können sich Hin- und Rückweg unterscheiden, was eine Benutzung von unidirektionalen Verbindungen erlaubt.
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
12
Lightweight Mobile Routing“ (LMR)
”
LMR gehört zur Klasse der Link Reversal Algorithmen“. Link Reversal Routing“
”
”
(LRR)-Verfahren verwenden die Graphentheorie, um eine Route zum Ziel zu ermitteln. Dabei wird von jedem Knoten je ein Graph für jeden möglichen Zielknoten erzeugt. Die Idee ist dabei, die Routingentscheidung mit Hilfe des Zielknotengraphen zu
treffen. Dazu werden so genannte Directed Acyclic Graphs“(DAGs) angewendet. Zur
”
Erstellung eines DAGs werden alle Netzknoten in den Graphen übertragen und die
Knoten, welche sich in Kommunikationsreichweite befinden, durch gerichtete Kanten
verbunden. Um eine Route zum Zielknoten zu finden, flutet die Quelle das Netz mit einem RREQ. Dieses Paket besitzt eine eindeutige ID und somit werden Paketduplikate
erkannt. Die Knoten, welche eine Route zum Zielknoten kennen, antworten mit einem
RREP. Der Link“, den die Knoten zum Zielknoten besitzen, wird als Downstream
”
”
Link“ bezeichnet. Ein großer Vorteil von LMR ist, dass keine globalen Verbindungsinformationen erforderlich sind. Jeder Knoten muss nur die Verbindungen zu seinen
Nachbarn kennen. Ein Nachteil ist, dass keine gemeinsame Zeitbasis vorausgesetzt
wird, was bei Link“-Fehlern zur Bildung falscher Routen führt und dann das Netz in
”
zwei Teile spaltet. Die Komplexität sowie die zusätzliche Netzlast führen zu längeren
Routen.
Temporally-Ordered Routing Algorithm“ (TORA)
”
TORA ist ein anpassungsfähiger, leistungsfähiger und skalierbarer Routingalgorithmus, der ebenfalls zur Klasse der LRR-Protokolle gehört.
TORA wurde für den Einsatz in hochdynamischen Netzen entwickelt und versucht, die
Anzahl der Control Messages“ zu minimieren, indem diese nur bei der Veränderung
”
der Netztopologie verwendet werden. Dazu müssen die Knoten Routinginformationen
zu ihren direkten Nachbarn speichern und verwalten. Der Quellknoten initialisiert die
Routenberechnung und für jedes realisierbare Quell- und Zielknotenpaar werden mehrere mögliche Routen bereitgestellt. Das Problem bei TORA ist, dass für das Protokoll
vorausgesetzt wird, dass alle Knoten über synchrone Uhren verfügen. Dies lässt sich
zum Beispiel über das Global Positioning System“ (GPS) verwirklichen.
”
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
13
Die Vorteile von TORA sind die Erzeugung mehrerer Routen zum Ziel und die lokale
Behandlung von Störungen.
Power-Aware Routing“ (PAR)
”
Als Routingmetrik wird die Lebensdauer der Batterie verwendet. Von PAR wird angestrebt:
• den Energieverbrauch pro Paket herabzusetzen,
• die Zeit zu maximieren, bevor sich das Netz aufteilt,
• die Abweichungen in den Leistungspegeln (Knoten) zu minimieren und
• die Kosten pro Paket und die maximalen Kosten pro Knoten so gering wie
möglich zu halten.
Somit wählt PAR Routen aus, bei denen die Batterien der mobilen Geräte eine längere
Lebensdauer aufweisen.
Die Abbildung 2.5 verdeutlicht ein entsprechendes Beispiel. Die Quelle möchte Daten
zum Ziel senden, wofür zwei Routen zur Verfügung stehen. Der Knoten R2 der Route
A hat einen schnelleren Leistungsabfall als die Knoten der Route B. Somit währe es
sinnvoll, die Route B zu verwenden.
Route A
R1
„Source“
+
R2
-
+
Route B
+
„Destination“
-
+
-
-
R3
+
-
R4
+
-
Abbildung 2.5: PAR - Beispiel [Kasel, 2002]
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
14
Relative Distance Micro-discovery Ad Hoc Routing“ (RDMAR)
”
RDMAR wurde für die Einsparung von Bandbreite entwickelt. Die Relative Distance“
”
(RD) ist die voraussichtliche Anzahl von Hops“, welche benötigt werden, um ein Ziel
”
zu erreichen. Implementiert ist diese im TTL ( Time To Life“)-Feld eines IP-Headers.
”
RDMAR verwendet zur schnelleren Reparatur einen Relative Distance Estimation“
”
(RDE)-Algorithmus, der folgende Aufgaben besitzt:
• Schätzen der RD zwischen Quelle (SRC) und Ziel (DST).
• Schnelle Reparatur der lokalen Routen.
In der Abbildung 2.6 ist die Route Discovery“-Phase dargestellt. Die Quelle (MH4)
”
versendet einen limitierten Broadcast RREQ“ (RD=2). Das Ziel (MH8) bestätigt
”
den RREQ mit einem Unicast RREP“. Die Route Maintenance“-Phase ist in der
”
”
„Source“
MH 3
MH 6
MH 4
RREQ
RREQ
RREQ
RREQ
MH 9
MH 2
RREQ
RREP
MH 7
MH 5
RREQ
MH 1
RREP
MH 8
„Destination"
Abbildung 2.6: RDMAR - Route Discovery“ [Kasel, 2002]
”
Abbildung 2.7 dargestellt. Es kommt zur Veränderung der Netztopologie, der Knoten
MH5 erkennt die fehlerhafte Verbindung zum Knoten MH8 und löst einen Emergency
”
RDM“ ( Relative Distance Micro-discovery“) (RD=3) aus. Der Knoten MH8 teilt
”
dem Knoten MH5 seine neue Position mit und MH5 setzt die Datenübertragung zum
Knoten MH8 fort. Dabei wird der Knoten MH4 nicht über die Reparatur informiert.
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
15
„Source“
MH 3
MH 6
DATA
DATA
MH 4
MH 9
MH 2
RREQ
RREP
RREP
DATA
RREQ
RREQ
RREQ
RREQ
RREQ
MH 5
DATA
MH 1
MH 7
RREQ
RREP
X
MH 8
MH 8
„Destination“
Abbildung 2.7: RDMAR - Route Maintenance“ [Kasel, 2002]
”
2.1.2
Proaktive Routingalgorithmen ( Table-Driven“)
”
Proaktive Routingalgorithmen erstellen eine Karte“ der Netztopologie ( Link State
”
”
Routing“) oder eine Liste der Entfernungen zu allen anderen Knoten ( Distance Vec”
tor Routing“). Diese werden immer aktuell gehalten, indem jeder Router alle Änderungen an alle seine Nachbarn weiterleitet. Dadurch ist gewährleistet, dass bereits
beim Verbindungsaufbau eine aktuelle Route in jedem Router vorhanden ist. Jeder
Knoten speichert für das gesamte Netz die Global State Informations“. Die für die
”
Aktualisierung notwendige Kommunikation erzeugt aber bereits eine hohe Netzlast.
Die einzelnen Routingprotokolle unterscheiden sich durch die Anzahl der verwendeten
Routingtabellen und den Methoden, Updates“ weiterzuleiten.
”
Destination-Sequenced Distance-Vector“ (DSDV)
”
DSDV basiert auf dem
Distance Vector“-Algorithmus bzw. dem Bellman-Ford”
”
Algorithmus“, der die kürzeste Route berechnet. Die kürzeste Route wird ermittelt,
indem jeder Knoten in einer Tabelle die Distanzen (Anzahl der Hops“) zu allen Nach”
barn abspeichert. Dabei sind aber Schleifen möglich, denn die Knoten können nicht
zwischen alten und neuen Routen unterscheiden. DSDV verwendet Sequenznummern
mit denen man zwischen unterbrochenen und neuen Routen unterscheiden kann. Ist die
Sequenznummer gerade, so handelt es sich um ein normales Update“, eine ungerade
”
Sequenznummer zeigt dagegen eine unterbrochene Route an. Regelmäßige Updates“
”
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
16
sind erforderlich, um aktuelle Informationen zum Netz zu erhalten. Die Updates“
”
benötigen aber wiederum zusätzliche Bandbreite.
In der Abbildung 2.8 sind ein Beispielnetz und die entsprechende Routingtabelle des
Knotens 4 dargestellt. In der Routingtabelle sind alle vorhandenen Routen mit den
wichtigsten Informationen eingetragen, beispielsweise führt eine Route zum Knoten 3
über den Knoten 2 und die Entfernung beträgt 2 Hops“.
”
3
4
5
2
1
6
„Node 4 RT Structure”
8
7
„Destination“
„Next Hop“
„Metric“
(„Next Hop“)
„Sequence
Number“
1
2
2
S406_1
2
2
1
S128_2
3
2
2
S564_3
4
4
0
S710_4
5
6
2
S392_5
6
6
1
S076_6
7
6
2
S128_7
8
6
3
S050_8
„Flag“
Abbildung 2.8: DSDV - Routingtable“ [Ampadu and Perkins, 2003]
”
Die Tabellen werden auf zwei Arten aktualisiert:
1. Full Dump“
”
Die gesamte Tabelle des Knoten wird versendet. Alle Informationen sind enthalten und eventuell sind mehrere Datenpakete erforderlich.
2. Inkrementelles Update“
”
Die Inkrementellen Updates“, welche periodisch versendet werden, enthalten
”
nur die Änderungen seit dem letzten Full Dump“.
”
Die Route mit der aktuellen Sequenznummer wird immer zum Routing verwendet.
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
17
Erhält ein Knoten zwei Updates“ mit der gleichen Sequenznummer, wird die Route
”
mit der kleinsten Metrik (Anzahl der Hops“) verwendet.
”
3
4
5
2
1
6
8
„Update Node 4 RT Structure”
7
1
„Destination“
„Next Hop“
„Metric“
(„Next Hop“)
„Sequence
Number“
„Flag“
1
6
3
S516_1
M
2
2
1
S238_2
3
2
2
S674_3
4
4
0
S820_4
5
6
2
S502_5
6
6
1
S186_6
7
6
2
S238_7
8
6
3
S160_8
Abbildung 2.9: DSDV - Update Routingtable“ [Ampadu and Perkins, 2003]
”
In der Abbildung 2.9 ist das Update“ einer Routingtabelle dargestellt. Der Knoten 4
”
führt ein Update“ seiner Routingtabelle durch, denn der Knoten 1 hat seine Position
”
verändert. Eine neue Route zum Knoten 1 wird in die Tabelle eingetragen. Die neuen
Sequenznummern sind gerade, denn es handelt sich um ein normales Update“.
”
Cluster-Head Gateway Switch Routing“ (CGSR)
”
Eine Weiterentwicklung von DSDV ist das Cluster-Head Gateway Switch Routing“
”
(CGSR). CGSR basiert auf DSDV und ist ein hierarchisches Routingprotokoll, welches das gesamte Netz in kleinere Cluster“ unterteilt. Diese Unterteilung führt zur
”
Vereinfachung des Routings, denn nur die so genannten Cluster Heads“ (CHs) besit”
zen die kompletten Routingtabellen. Der Cluster Head“ wird mit Hilfe des Cluster
”
”
Head Selection“-Algorithmus ermittelt. In Netzen mit sehr mobilen Knoten kommt es
oft zu einem aufwändigen Wechsel der Cluster Heads“. Aus diesem Grund verwen”
det CGSR den Least Cluster Change“ (LCC)-Algorithmus. LCC verändert nur dann
”
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
18
den Cluster Head“, wenn zwei Cluster Heads“ in direkten Kontakt geraten oder
”
”
ein Knoten keinen Kontakt mehr zu irgendeinem Cluster Head“ erhält. Als Gate”
”
way Nodes“ werden die Knoten bezeichnet, die Verbindungen zu zwei oder mehreren
Cluster Heads“ besitzen. Für dieses Protokoll sind je Knoten zwei Tabellen erforder”
lich, die Cluster Member Table“ und die Routing Table“. In der Abbildung 2.10
”
”
5
4
1
3
6
8
2
7
Knoten
„Gateway“
„Cluster Head“
Abbildung 2.10: CGSR - Beispiel [Royer and Toh, 1999]
ist ein Beispiel dazu dargestellt. Die Quelle (Knoten 1) will an den Knoten 8 Daten
senden. Dazu sendet die Quelle ein RREQ an den Cluster Head“, Knoten 2. Dieser
”
sendet das Paket an den Gateway Node“, Knoten 3 und von dort aus wird das Paket
”
an den nächsten Cluster Head“, Knoten 4 gesendet. Der gesuchte Knoten befindet
”
sich nicht in diesem Cluster“ und das Datenpaket wird weitergeleitet, bis es den Des”
”
tination Cluster Head“, Knoten 7 erreicht. Dieser leitet dann das Datenpaket an den
Zielknoten, Knoten 9 weiter.
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
19
Wireless Routing Protocol“ (WRP)
”
Jeder Knoten im Ad-hoc-Netz muss vier Tabellen speichern und verwalten:
• Distanztabelle
Diese beinhaltet für jeden Ziel- und Nachbarknoten die entsprechenden Distanzen. Die Daten werden in einer Matrix abgespeichert und dargestellt.
• Routingtabelle
In der Routingtabelle sind alle Informationen zu den Zielknoten enthalten.
• Link Cost“ Tabelle
”
Diese Tabelle beinhaltet die Transportkosten der Daten über jeden Nachbarknoten.
• Message Retransmission List“ (MRL)
”
Die MRL verwaltet die benötigten Daten für die Updates“, mit deren Hilfe die
”
Topologieveränderungen verbreitet werden. Dabei geben die Sequenznummern
das Alter der Daten an.
Mit Hilfe der Update Messages“ werden neue Knoten über ihre Nachbarn informiert.
”
Die Updates“ werden versendet, wenn der Knoten ein Update“ verarbeitet hat oder
”
”
wenn ein Knoten eine Veränderung seinen Nachbarknoten erkennt. Kommt es zum
Wegfall einer Verbindung, wird beim Update“ eine neue Route berechnet. Falls ein
”
Knoten keine Messages“ zu senden hat, muss dieser eine Hello Message“ verschi”
”
cken, um den anderen Knoten zu signalisieren, dass er das Netz noch nicht verlassen
hat. Wird innerhalb eines Timeouts“ keine Message“ empfangen, dann gilt diese
”
”
Verbindung als gestört.
Fisheye State Routing“ (FSR)
”
FSR beruht auf dem Link State Routing“ und es kann sofort Routinginformatio”
nen zur Verfügung stellen, wenn sie benötigt werden. In den Update Messages“ sind
”
nicht zu allen Knoten Informationen enthalten. Stattdessen werden Informationen über
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
20
Knoten, die sich in der näheren Umgebung befinden, häufiger ausgetauscht, als Informationen zu den Knoten, die weiter entfernt sind. Somit erhält jeder Knoten genaue
Informationen über seine Nachbarn und die Größe der Update Messages“ wird ver”
kleinert. Mit zunehmendem Knotenabstand nehmen die Genauigkeit und die Details
der Knoteninformationen ab. Selbst wenn ein Knoten keine genaue Information über
weit entfernte Knoten besitzt, werden die Pakete richtig weitergeleitet, denn die Routeninformationen werden immer genauer, je näher das Paket dem Bestimmungsort
kommt. Die Topologietabellen werden nur an die lokalen Nachbarn gesendet, anstatt
das komplette Netz zu fluten. Mit Hilfe von Sequenznummern wird ein schleifenfreies
Routing gewährleistet. Jeder Knoten besitzt eine Topology Table“, Neighbor Link
”
”
State List“ und Routing Table“.
”
„Hop“ = 1
„Hop“ = 2
3. Bereich
2. Bereich
1. Bereich
„Hop“ > 2
Abbildung 2.11: FSR - Beispiel [Thill, 2004]
In der Abbildung 2.11 sind die Bereiche innerhalb des Fischauges“ mit dem roten
”
Knoten im Zentrum dargestellt. Die Bereiche werden so definiert, dass sie über eine
bestimmte Anzahl von Hops“ erreichbar sind. Der Knoten im Zentrum besitzt alle
”
Informationen zu den Knoten im grauen Bereich (1. Bereich), dabei ist die Distanz
1 Hop“. Mit zunehmender Entfernung vom zentralen Knoten nimmt die Distanz zu
”
und die Knoten werden in die entsprechenden Bereiche eingeordnet.
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
21
Optimized Link State Routing (OLSR)“
”
OLSR ist ein Link State“-Verfahren und die Distanzdaten werden direkt an alle Kno”
ten im Netz gesendet. Folgende 5 Schritte verdeutlichen den Ablauf:
1. Suchen der Nachbarknoten
Jeder Knoten versendet periodisch Hello Messages“.
”
2. Messung der Distanzen zu den Nachbarn
Der Knoten versendet Echo-Pakete an alle Nachbarknoten, die diese sofort beantworten müssen. Das Zeitintervall zwischen Echo-Paket und Antwort kann als
Distanz verwendet werden.
3. Erzeugen eines Kontrollpakets ( Topology Control (TC) Message“ )
”
Enthält die Knotenadresse, eine eindeutige Sequenznummer und eine Liste der
Nachbarn mit den entsprechenden Distanzen.
4. Senden des Kontrollpakets an alle Netzknoten (Fluten)
5. Erstellen eines Abbildes der Netzwerktopologie
Wenn ein Knoten das Kontrollpaket erhält, erstellt er eine eigene Routingtabelle.
Mit Hilfe des Shortest Path Algorithm“ kann der Knoten die Routen zu jedem
”
Knoten, mit dem er kommunizieren möchte, erstellen. Wenn ein Knoten das Kontrollpaket mit der Sequenznummer schon einmal erhalten hat, wird es verworfen.
In der Routingtabelle werden alle Routen zu den Nachbarknoten gespeichert. Ein
Update“ der Informationen findet nur statt, wenn:
”
• eine Veränderung in der Nachbarschaft erkannt wurde,
• die Route zu einem Ziel beendet wurde,
• eine bessere (kürzere) Route, zu einem Ziel, gefunden wurde.
OLSR basiert auf den so genannten Multipoint Relays“ (MPRs). Die MPRs sind
”
ausgewählte Nachbarknoten (1 Hop“), die besondere Aufgaben bei der Weiterleitung
”
von Kontrollpaketen übernehmen. Die MPRs sollten so ausgewählt werden, dass jeder
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
22
Nachbarknoten im Umkreis von 2 Hops“ von mindestens einem MPR abgedeckt wird.
”
Dabei sollte aber die Anzahl der MPRs minimal sein.
N2
N1
MPR(N2) N6
MPR(N2)
N3
N(N2)
N7
N8
N9
N4
N2(N2)
N10
•
•
•
•
•
•
•
•
N5
N(Ni) - die Menge der Nachbarn von Ni
N(N ) - die Menge der Nachbarn von Ni
N2(Nii) - die Menge der Knoten, die von N
N2(N ) - die Menge der Knoten, die von Ni i
exakt i2 Schritte entfernt sind
exakt 2 Schritte entfernt sind
MPR(Ni) - die Menge der Nachbarknoten von Ni,
MPR(N ) - die Menge der Nachbarknoten von Ni,
die von Ni i als „Multipoint Relays“ ausgewählt wurden
die von N als „Multipoint Relays“ ausgewählt wurden
MPRsel(Ni)i - die Menge der Nachbarknoten von Ni,
MPRsel(Ni) - die Menge der Nachbarknoten von Ni,
die Ni als „Multipoint Relays“ ausgewählt haben
die Ni als „Multipoint Relays“ ausgewählt haben
Abbildung 2.12: OLSR - Beispiel [Schlesser, 2004]
In der Abbildung 2.12 ist das Routing mit OLSR dargestellt. Jeder Knoten im Netz,
in diesem Beispiel Knoten N2, wählt einige Nachbarknoten aus. Diese Knoten werden
Knoten N2’-Pakete versenden. Die Knoten N1 und N6 sind die MPRs vom Knoten
N2. Ein Knoten, der kein MPR ist, kann das gesendete Paket von N2 zwar lesen, kann
aber nichts an N2 senden.
MPRs minimieren das Fluten des Netzwerkes mit Broadcast Messages“. Ein Kon”
trollpaket sollte nicht zweimal in dieselbe Netzwerkregion versendet werden. MPRs
helfen, dieses Problem zu optimieren und zu reduzieren.
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
23
Source Tree Adaptive Routing (STAR)“
”
STAR war das erste proaktive Routingprotokoll, welches mit Link State Routing“
”
gearbeitet hat und schneller als die On-Demand“ Protokolle war. Es werden aber
”
nicht die kürzesten Routen verwendet, um die Control Messages“ niedrig zu halten.
”
Zur Identifikation eines Knotens wird eine feste Adresse verwendet. Ein großer Vorteil
besteht aber darin, dass keine regelmäßigen Updates“ nötig sind. Zu Beginn liegt
”
ein Source-Tree“ vor, der alle Links“ zu jedem Nachbarknoten beinhaltet. Im ers”
”
ten Aktualisierungsschritt wird der eigene Source-Tree“ sofort als Aktualisierung an
”
allen anderen Nachbarn gesendet. So kann jeder Router mit seinem eigenen Source”
Tree“ gebildet werden und man erhält einen Topologiegraphen, der das gesamte Netz
beschreibt. Diese Aktualisierungen bestehen aus einem oder mehreren Link State Up”
date Units“ (LSUs).
Alle
Update“-Informationen sind Broadcast“-Informationen. Muss eine Aktua”
”
lisierung gesendet werden, wird zwischen Optimum Routing Approach“ (ORA)
”
und Least Overhead Routing Approach“ (LORA) unterschieden. Eine ORA”
Aktualisierung ist nur erforderlich, wenn die Router ihre eigenen Source-Trees“
”
verändern. LORA wird ausgeführt und eine Aktualisierung wird gesendet, wenn:
• der Empfänger unerreichbar ist,
• ein neuer Empfänger entdeckt wird,
• wenn Schleifen entstehen,
• die Metrik der Links“ das Limit überschreiten.
”
Zur Prüfung gültiger Updates“ werden Sequenznummern verwendet. Ein Router sen”
det ein Update“, wenn:
”
• eine Route erkannt wird, die in einer Schleife endet,
• ein neuer Nachfolger für einen Router gewählt wird,
• die Entfernung zum Empfänger über den gewählten Nachfolger wesentlich größer
ist als die alte.
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
24
Topology Dissemination Based On Reverse-Path Forwarding“ (TBRPF)
”
TBRPF ist vorteilhaft, wenn eine große Anzahl von Routen benötigt wird und für
Anwendungen, die keine Verzögerung der Route Discovery“ tolerieren.
”
TBRPF ist ein Full Topology Link State Protocol“, d.h. jeder Knoten erhält
”
Informationen zum Zustand jeder Verbindung.
TBRPF setzt sich aus zwei Modulen zusammen:
1. Routing (inklusive Topology Discovery“):
”
Jeder Knoten berichtet allen Nachbarn nur über einen Teil seines Quellbaums,
der als Reportable Subtree“ (RT) bezeichnet wird.
”
2. Neighbor Discovery“:
”
Unterschiedliche HELLOs“ werden verwendet, die nur die ID von neuen und
”
kürzlich verlorenen Nachbarn beinhalten. Die Neighbor Discovery“-Phase ist
”
völlig modular. Diese dient lediglich der Erkennung von neuen Nachbarn und
dem Verlust alter Nachbarn.
2.1.3
Hybride Routingalgorithmen
Hybride Routingalgorithmen versuchen das Beste von reaktiven und proaktiven Verfahren zu verbinden. Deshalb verhalten sich die Router in einer beschränkten Umgebung wie bei einem proaktiven Protokoll, um kurze Antwortzeiten bei der Kommunikation mit nahe gelegenen Knoten zu garantieren. Bei Anfragen zu weit entfernten
Knoten wird reaktiv eine Route durch mehrere Zonen bestimmt. Im Vergleich zu reaktiven Routingalgorithmen ist die Netzlast nur geringfügig höher. Die Dauer eines
Verbindungsaufbaus ist unwesentlich länger als bei proaktiven Verfahren.
Cluster Based Routing Protocol“ (CBRP)
”
CBRP ist ein Routingverfahren, welches mit Hilfe des Algorithmus die Knoten in
Cluster“ einteilt. Kommt ein neuer Knoten, dessen Zustand Undecided“ ist, hin”
”
zu, ist dessen erste Handlung das Starten eines Timers“ und des Versenden einer
”
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
25
Hello Message“. Wird diese Hello Message“ von einem Cluster Head“ (CH) emp”
”
”
fangen, antwortet dieser mit einer ausgelösten Hello Message“. Erhält der Knoten
”
diese Antwort, wird sein Zustand in Member“ geändert. Erhält der Knoten aber kei”
ne Nachricht von den Cluster Heads“, wird er selber ein Cluster Head“, aber nur
”
”
dann, wenn bidirektionale Verbindungen zu einem oder mehr Nachbarn existieren. Besitzt der Knoten keine Verbindung zu anderen Knoten, so verbleibt er im Zustand
Undecided“ und wiederholt die gesamte Prozedur. Dabei sollten die Cluster Heads“
”
”
so wenig wie möglich verändert werden.
Jeder Knoten besitzt eine Tabelle mit den entsprechenden Nachbarn. In der Tabelle 2.1
ist ein Beispiel einer Nachbartabelle dargestellt. In der ersten Spalte befindet sich die
ID, in der zweiten der Neighbor Status“ und in der dritten Spalte der Link Status“.
”
”
Neighbor ID“
”
1
3
5
9
Neighbor Status“
”
Member“
”
Member“
”
Cluster Head“
”
Member“
”
Link Status“
”
Bi-Directional“
”
Uni-Directional“
”
Bi-Directional“
”
Bi-Directional“
”
Tabelle 2.1: CBRP - Nachbartabelle [Foetz, 2004]
Ein Cluster Head“ besitzt folgende Tabelleneinträge:
”
• Die Informationen zu den im Cluster“ vorhanden Members“.
”
”
• Eine Cluster“-Nachbarschaftstabelle mit Informationen zu den benachbarten
”
Clustern“, d.h. das Gateway“ zum Cluster“ und die ID des Cluster Heads“.
”
”
”
”
In der Abbildung 2.13 ist ein Beispielszenario dargestellt. Der Quellknoten (SRC) will
ein Datenpaket an den Zielknoten (DST) senden. Dazu versendet die Quelle ein RREQ
an den benachbarten Cluster Head“ CH0. Dieser überprüft, ob sich der Zielknoten in
”
diesem Cluster“ befindet. Da der gesuchte Knoten nicht in diesem Cluster vorhanden
”
ist, speichert der Cluster Head“ seine Adresse im Paket und leitet es an alle Cluster
”
”
Heads“ weiter. Erhält ein Cluster Head“ ein Paket, in dem seine Adresse gespeichert
”
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
26
N7
N4
CH2
N1
G0
CH3
G3
DST
N3
N6
G2
CH0
SRC
G1
N0
SRC „Source“
CH1
DST „Destination“
N2
CH
„Cluster Head“
G
„Gateway“
N
„Node“
Abbildung 2.13: CBRP - Beispiel [Foetz, 2004]
ist, wird es verworfen. Der Cluster Head“ CH3 erkennt, dass sich der gesuchte Ziel”
knoten (DST) in seinem Cluster“ befindet. Daraufhin leitet er den RREQ an den
”
Zielknoten weiter. Hat das Ziel das Paket erhalten, antwortet es über die Route, die
im RREQ gespeichert ist. Wenn die Quelle nach einer bestimmten Zeit keine Antwort
vom Ziel erhält, versucht sie erneut, ein RREQ zu senden.
Core Extraction Distributed Ad hoc Routing“ (CEDAR)
”
Es wird eine Gruppe ( Set“) von Knoten erstellt, die als Core“ bezeichnet werden.
”
”
Jeder Knoten wählt einen Core“-Knoten als Dominator“. Die Auswahl des Domina”
”
”
tor“-Knotens erfolgt nach dem Grad der wegführenden Verbindung. Die Verbindungszustände werden weiter verbreitet ( Link State Propagation“). Die stabilen und band”
breitestarken Verbindungen sollen auch weit entfernten Knoten bekannt sein. Dagegen
sollten die schwachen und dynamischen Verbindungen nur lokal gespeichert werden.
Die Auswahl der Routen erfolgt unter Berücksichtigung von QoS, den ein Link“ zur
”
Verfügung stellen kann.
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
Quelle
27
Ziel
1
2
„Core Node“
„Bi-directional Link“
„Node“
„Virtual Link“
Abbildung 2.14: CEDAR - Route Computation“ [Gao, 2003]
”
In der Abbildung 2.14 ist die Route Discovery“-Phase dargestellt. Die Quelle leitet
”
die Anforderung an seinen Dominator“ (Knoten 1) weiter. Der Knoten 1 findet im
”
Core“-Netz eine Route zum Knoten 2, welcher der Dominator“ vom Ziel ist. Die
”
”
Core“-Knoten erstellen mit Hilfe der lokalen Informationen eine Route zwischen der
”
Quelle und dem Ziel.
Zone Routing Protocol (ZRP)“
”
ZRP besteht im Wesentlichen aus drei Teilprotokollen (s. Abbildung 2.15):
IARP
IARP
IERP
IERP
BRP
BRP
„Zone
„ZoneRouting
RoutingProtocol“
Protocol“
„Inter-Process
Communication“
„Packet Flow“
„Network
„NetworkLayer“
Layer“
„MAC
„MACLayer“
Layer“(„includes
(„includesNDP“)
NDP“)
Abbildung 2.15: ZRP - Aufbau [Kasel, 2002]
1. Intrazone Routing Protocol“ (IARP):
”
IARP verwendet Link State“-Verfahren und übernimmt die Nachrichtenüber”
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
28
mittlung innerhalb der Zone. Nur Routen für einen begrenzten Bereich um die
Station werden aktuell und im Voraus präsent gehalten.
2. Interzone Routing Protocol“ (IERP):
”
IERP verwendet Distance Vector“-Verfahren und übernimmt die Nachrich”
tenübermittlung zwischen zwei unterschiedlichen Zonen.
3. Bordercast Resolution Protocol“ (BRP):
”
Die Distance Vector“-Verfahren werden verwendet. BRP arbeitet im Gegensatz
”
zu Broadcast“ viel effizienter. Jeder Station ist bekannt, ob sich der gesuchte
”
Knoten in der Routingzone befindet. Wenn nicht, reicht es aus, die Anfrage
an die Border“-Knoten weiterzuleiten. BRP legt fest, wie die Border“-Knoten
”
”
ermittelt werden. Die Border“-Knoten werden während der Aktivität des IARPs
”
gefunden.
Zur Ermittlung einer Route überprüft die Quelle zunächst, ob sich das Ziel in der
gleichen Zone befindet. Ist dies der Fall, so ist die Route bereits bekannt und die
Daten können sofort gesendet werden. Befindet sich aber das Ziel außerhalb der Zone,
wird eine Suchanfrage an alle Border“-Knoten der Quelle verschickt. Mit Hilfe der
”
Border“-Knoten wird die Zone ermittelt, in der sich das Ziel befindet. Wird das Ziel
”
gefunden, sendet dieses eine Antwort mit der Route an die Quelle.
2.2
2.2.1
Weitere Routingalgorithmen
Unicast“ Routingalgorithmen (geographiebasiert)
”
Geographisches Routing stellt einen alternativen Ansatz des Routings in MANETs
unter Einbezug von Informationen über die geographische Position von Netzknoten
dar. Dabei basiert das Routing auf modifizierten Routingtabellen, die den Netzknoten
approximativ eine geographische Position zuweisen. Die Routingtabelle ist somit eine
Liste von Tupeln der Form N,posn“ für Netzknoten N“ und ihre Position posn“.
”
”
”
Das Routing im Netz orientiert sich dabei an minimalen Distanzvektoren bzgl. der
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
29
erreichbaren Nachbarknoten und dem Zielknoten. In der Abbildung 2.16 ist ein Routingprozess auf Grundlage graphischer Informationen dargestellt. Die Quelle (Knoten
1) will ein Datenpaket an den Zielknoten (Knoten 3) schicken. In der Routingtabelle
vom Knoten 1 sind alle vorhanden Routen enthalten. Der Zielknoten kann über zwei
Routen erreicht werden. Zum Routing verwendet dieser Algorithmus Routen, welche
die kürzeste Distanz zum Nachbarknoten aufweisen. Nach der Berechnung wird deutlich, dass das Routing über den Knoten 2 erfolgt, denn dieser weist die geringste
Distanz zum Zielknoten auf.
dist(4,3) = 2,8284..
4
„Destination“
3
„Source“
1
„Routing Table“
(2,<2,1>)
(4,<1,4>)
(3,<3,2>)
2
dist(2,3) = 1,4142..
Abbildung 2.16: Routing auf Grundlage geographischer Informationen [Bahr,
2002]
Location-Aided Routing“ (LAR)
”
LAR ist ein On-Demand“-Protokoll und basiert auf DSR. Es werden Positionsin”
formationen benutzt, um den Netzwerkverkehr in Ad-hoc-Netzen zu reduzieren. Normalerweise wird GPS benutzt, um diese Positionsinformationen zu erhalten. Mit der
Verfügbarkeit von GPS kennen die mobilen Knoten ihre physischen Positionen. LAR
zählt zu den auf Fluten basierenden Verfahren, d.h. die Route Discovery“ erfolgt
”
durch Fluten des Netzwerkes.
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
2.2.2
30
Security“ Routingalgorithmen
”
Authenticated Routing for Ad hoc Networks“ (ARAN)
”
ARAN ist ein On-Demand“ Routingprotokoll, welches Zertifikate für garantierte Au”
thentifikation, Nachrichtenintegrität und Unleugbarkeit von Routingprotokollen verwendet. Basierend auf Logical Link Metric“ und den Zertifikaten, ist es gegen eine
”
Modifikation, Nachahmung und Erstellung von Routingnachrichten geschützt. Jeder
Knoten, der ein RREQ oder ein RREP weiterleitet, muss dieses signieren. Die verwendete asymmetrische Kryptographie führt zu einer größeren CPU ( Central Processing
”
Unit“)-Auslastung und zu einem höheren Energieverbrauch. ARAN ist aber nicht immun gegen Wurmattacken“.
”
2.3
Vergleich einiger Routingverfahren
In der Tabelle 2.2 sind einige Routingprotokolle mit ausgewählten Eigenschaften dargestellt. Der Vergleich einiger Routingverfahren soll dazu dienen, die Gemeinsamkeiten
und die Unterschiede der Protokolle darzustellen. Weiterhin können Aussagen über die
Einhaltung von Anforderungen und wünschenswerten Eigenschaften getroffen werden.
Um einen Vergleich vorzunehmen, werden neben grundsätzlichen Eigenschaften, wie
Aussagen zur Routenbestimmung und Einteilung in flache/hierarchische Protokolle,
auch Aussagen zu den Anforderungen und wünschenswerten Eigenschaften, in diesem
Fall QoS, Schleifenfreiheit und Multicast“, verwendet. Die Tabelle macht deutlich,
”
dass die Schleifenfreiheit von den meisten Protokollen gewährleistet ist. Die Schleifenfreiheit ist eine wesentliche Anforderung an die Routingprotokolle in Ad-hoc-Netzen.
Hingegen werden QoS und Multicast“ nur von sehr wenigen Routingprotokollen
”
unterstützt. AODV bietet Multicast“ und mit Aussatz QoS. Neben AODV bietet
”
RDMAR ebenfalls Multicast“ und mit einem Aufsatz bieten die beiden Verfahren,
”
CGSR und TORA ebenfalls eine Multicast“-Unterstützung an. QoS wird momentan
”
nur von ABR und ZRP unterstützt.
KAPITEL 2. ROUTING IN AD-HOC-NETZEN
Verfahren
Routen-
Schleifen-
QoS
31
Flach/
bestimmung freiheit
Hierarchisch
DSDV
Proaktiv
Ja
Flach
CGSR
Proaktiv
Ja
Hierarchisch
WRP
Proaktiv
Ja
( Cluster“)
”
Flach
FSR
Proaktiv
Ja
Hierarchisch
OLSR
Proaktiv
Ja
Flach
STAR
Proaktiv
Ja
Flach
TBRPF
Proaktiv
Nein
Flach
ABR
Reaktiv
Ja
SSR
Reaktiv
Ja
Flach
AODV
Reaktiv
Ja
Mit Auf- Flach
Ja
Multicast“”
Unterstützung
Mit Aufsatz
Flach
Ja
satz
DSR
Reaktiv
LMR
Reaktiv
TORA
Reaktiv
PAR
Reaktiv
RDMAR
Reaktiv
CBRP
Hybrid
CEDAR
Hybrid
ZRP
Hybrid
Ja
Flach
Flach
Ja
Ja
Flach
Mit Aufsatz
Flach
Ja
Flach
Hierarchisch
Ja
Ja
Hierarchisch
Tabelle 2.2: Vergleich einzelner Routingverfahren [Kasel, 2002], [Bornträger,
2002] & [Engel and Roth, 2005]
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
32
Kapitel 3
Softwarekomponenten für
Ad-hoc-Netze
Dieses Kapitel gibt eine grobe Übersicht über freie Softwarekomponenten für Ad-hocNetze im Internet. Es enthält einige Quellen zu diesem Thema, die auch Software für
die unterschiedlichsten Betriebssysteme, größtenteils Linux OS, anbieten. Leider sind
diese Quellen schlecht dokumentiert und aufgrund deren Aktualisierungsdatums hat
es den Anschein, dass die Entwicklung bei den meisten Implementierungen nicht mehr
fortgesetzt wird.
3.1
3.1.1
Implementierungen der Routingprotokolle
AODV
In den nachfolgenden Tabellen sind die vorhandenen AODV-Implementierungen mit
ausgewählten Eigenschaften dargestellt. Die detaillierten Angaben zu jeder einzelnen
Implementierung sind im Anhang A.1.1 zu finden. Anhand der ausgewählten Eigenschaften, wie beispielsweise Anforderungen an das System und die Software, können
die verschiedenen Implementierungen miteinander verglichen werden. Auffällig ist,
dass einige Implementierungen keine fortschreitende Weiterentwicklung erfahren, was
zu Problemen auf neueren Systemen führen kann.
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
33
In der Tabelle 3.1 sind die Linux-OS-Implementierungen dargestellt, die kein IPv6 und
Multicast“ unterstützen. Die Systemanforderungen sind im Wesentlichen identisch,
”
d.h. eine WLAN-Karte und das entsprechende Betriebssystem sind bei allen Implementierungen erforderlich. Die Implementierungen AODV Kernel“ [4], AODV-UCSB“
”
”
( University of California, Santa Barbara“) [5] und AODV-UICU“ ( University
”
”
”
of Illinois at Urban-Champaign“) [6] basieren nur auf Linux 2.4.x, hingegen kann
AODV-UU“ ( Uppsala University“) [7] bereits für Linux 2.6.x verwendet werden. Eine
”
”
wichtige Systemanforderung bei allen Implementierungen ist der Netfilter-Support“,
”
der im Kernel vorhanden sein muss. Die beiden Implementierungen AODV Kernel“
”
und AODV-UIUC“ besitzen weitere Anforderungen. Für AODV Kernel“ ist zusätz”
”
lich Packet Forwarding“ erforderlich und AODV-UIUC“ benötigt, neben Loadable
”
”
”
Module Support“ und TUN/TAP-Support“, als Softwarekomponente die Ad-hoc
”
”
Support Library“ (ASL) [1].
AODV-UIUC“ unterstützt ein einfaches Application Programming Interface“ (API)
”
”
und diese Implementierung arbeitet als User-Space-Daemon“. Anhand der Angaben
”
wird deutlich, dass AODV-UU“ wesentliche Vorteile gegenüber den anderen Imple”
mentierungen besitzt und diese wird auch ständig weiterentwickelt. AODV-UU“ kann
”
auch im Network Simulator 2“ (ns2) [29] verwendet werden. Von den in der Tabel”
le 3.1 dargestellten Implementierungen sind AODV Kernel“ und AODV-UU“ funk”
”
tionsfähig. Dagegen ist AODV-UIUC“ nicht funktionsfähig und die Verwendung von
”
AODV UCSB“ wird, laut Angaben der Internetquelle, nicht mehr empfohlen.
”
RFCs und Drafts:
AODV Kernel“ [4]
”
draft-ietf-manet-aodv-10 [IETF,
AODV-UCSB“ [5]
”
AODV-UIUC“ [6]
”
2002b];
AODV-UU“ [7]
”
draft-ietf-manet-aodv-13 [IETF,
2003b];
draft-perkins-aodv6-01
[IETF,
RFC 3561 [IETF, 2003d]
2000a]
Betriebssystem:
Linux OS
Linux OS
Linux OS
Linus OS
Systemanforderungen:
Linux 2.4.1;
Linux 2.4.1;
Linux 2.4.3;
Linux 2.4.x/2.6.x;
WLAN-Karte;
WLAN-Karte;
WLAN-Karte;
WLAN-Karte;
Netfilter“;
”
Packet Forwarding“
”
Netfilter“
”
Netfilter“, Loadable Module
”
”
Support“ und TUN/TAP Sup”
port“’
Netfilter“
”
Softwareanforderungen:
Sonstige Eigenschaften:
ASL [1]
von den Entwicklern mit 3 Kno-
einfaches API;
Internet Gateway Support“;
”
User-Space-Daemon“
”
User-Space-Daemon“;
”
für Einsatz in der Ad hoc Pro”
tocol Evaluation (APE) test-
ten (2 Hops“) getestet
”
bed“ [9] entwickelt;
sowohl für WLAN-“Interface“
als auch für übliche Netzwerk“Interface“ einsetzbar;
Verwendung im ns2 [29];
von den Entwicklern mit 5 KnoFunktionsfähig:
Ja
Keine Aussage
Nein
ten (4 Hops“) getestet
”
Ja
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
Implementierung:
Tabelle 3.1: Übersicht zu den AODV-Implementierungen (1)
34
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
35
In der Tabelle 3.2 sind die vorhandenen Implementierungen dargestellt, die IPv6 bzw.
Multicast“ unterstützen. Dabei ist auffällig, dass einige dieser Implementierungen
”
auf AODV-UU“ aufbauen und diese entsprechend mit IPv6 bzw. Multicast“ er”
”
weitern. Lediglich HUT AODV for IPv6“ [18] entwickelt an der Helsinki Univer”
”
sity of Technology“ (HUT) ist eine eigenständig Implementierung und benötigt kein
AODV-UU“. Die Systemanforderungen von AODV IPv6“ [3] und AODV-UU for
”
”
”
IPv6“ [8] sind fast identisch, lediglich Packet Forwarding“ ist noch für AODV-UU for
”
”
IPv6“ erforderlich. Diese Implementierung bietet außerdem einen zusätzlichen Layer“
”
für IP-Version-Abstraktion“. Multicast“ wird lediglich von MAODV“ ( Multicast
”
”
”
”
Extensions of AODV“) [28] zur Verfügung gestellt. Diese Implementierung basiert wiederum auf AODV-UU“. Die Multicast“-Unterstützung kann mit Hilfe eines Flags“
”
”
”
im Makefile“ aktiviert bzw. deaktiviert werden. Im aktuellen Draft [IETF, 2003b] sind
”
entsprechende Flags“ für Multicast“ reserviert. MAODV“ stellt keine besonderen
”
”
”
Anforderungen an das System, lediglich AODV-UU“ muss vorhanden sein. Von den in
”
der Tabelle 3.2 dargestellten Implementierungen sind AODV IPv6“ und MAODV“
”
”
funktionsfähig. Die Funktionsfähigkeit von AODV-UU IPv6“ und HUT AODV for
”
”
IPv6“ konnte in den ersten Tests nicht nachgewiesen werden. Bei beiden Implementierungen treten Probleme mit dem Kernel auf.
RFCs und Drafts:
AODV IPv6“ [3]
”
draft-ietf-manet-aodv-10 [IETF,
AODV-UU for IPv6“ [8]
”
RFC 3561 [IETF, 2003d]
HUT AODV for IPv6“ [18]
”
RFC 3561 [IETF, 2003d];
MAODV“ [28]
”
draft-ietf-manet-maodv-
2002b];
00 [IETF, 2000b]
draft-perkins-aodv6-01
[IETF,
draft-perkins-manet-aodv6-
2000a];
01 [IETF, 2000a];
draft-wakikawa-manet-globalv6-
draft-wakikawa-manet-globalv6-
02 [IETF, 2002c]
02 [IETF, 2002c]
Betriebssystem:
Linux OS
Linux OS
Linux OS
Linux OS
Systemanforderungen:
Linux OS;
Linux 2.4.x/2.6.x;
Linux 2.4.3;
Linux OS;
WLAN-Karte;
WLAN-Karte;
WLAN-Karte
WLAN-Karte
Netfilter“
”
Netfilter“;
”
Packet Forwarding“
”
AODV-UU“v0.9 [7]
”
IPv6-Unterstützung;
IPv6-Unterstützung;
zusätzlicher
unterstützt Eigenschaften der
Softwareanforderungen:
Sonstige Eigenschaften:
AODV-UU“ v0.5 [7]
”
IPv6-Unterstützung;
User-Space-Daemon“;
”
Layer“ für IP”
”
Version-Abstraktion“, iplib“
”
Spezifikation,
abgesehen
Hop-to-Hop“;
”
unterhält
Kernel-Routing”
von
AODV-UU“ v0.6/v0.72 [7]
”
Multicast“-Unterstützung;
”
-DMAODV
Flags“
im
”
Makefile“
zur
Aktivie”
rung/Deaktivierung von Multi”
cast“;
kein Multicast“ und QoS
”
noch nicht im ns2 [29] integriert
Nein
Ja
Table“
Funktionsfähig:
Ja
Nein
Tabelle 3.2: Übersicht zu den AODV-Implementierungen (2)
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
Implementierung:
36
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
37
In dieser Tabelle 3.3 sind die Implementierungen dargestellt, die auf Tiny OS oder MS
Windows aufbauen. Zu TinyAODV“ existieren kaum Aussagen und somit ist ein Ver”
gleich mit den beiden anderen Implementierungen nicht möglich. Lediglich Aussagen
zur Vereinfachung der AODV-Implementierung sind vorhanden, wie beispielsweise:
• RREP Message“ wird nur durch Destination“ erstellt,
”
”
• Routen sterben nicht bzw. laufen nicht ab,
• nur Hop Count Metric“ und
”
• Route Error“, wenn Data Message“ nichtzustellbar.
”
”
UoB JAdhoc“( Java Ad-hoc“), entwickelt an der University of Bremen“ (UoB) und
”
”
”
Windows AODV“ sind die beiden einzigen AODV-Implementierungen, die für MS
”
Windows verfügbar sind. Zusätzlich kann UoB JAdhoc“ auch unter Linux OS einge”
setzt werden. Beim Vergleich dieser beiden Implementierungen wird deutlich, dass für
UoB JAdhoc“ weitere Softwarekomponenten erforderlich sind:
”
• Linux OS:
Java Runtime Enviroment“ (JRE) [23] oder Java 2 Software Development
”
”
Kit“ (SDK) [22], Libpcap“ [26] und Jpcap“ ( Java Package for Packet Cap”
”
”
ture“) [24] .
• MS Windows:
JRE [23] oder SDK [22], WinPcap“ ( Windows Packet Capture“) [47] und
”
”
Jpcap“ [24].
”
• Zaurus Linux:
Cross-Compiler“ ( gcc“) für ARM Prozessor.
”
”
Hingegen sind die Anforderungen von Windows AODV“ relativ gering, aber diese
”
Implementierung kann nur unter MS Windows XP verwendet werden. Aussagen zur
Funktionsfähigkeit von TinyAODV“ sind nicht möglich, denn Tiny OS stand nicht zur
”
Verfügung. Die Funktionsfähigkeit von UoB JAdhoc“ und Windows AODV“ konnte
”
”
nachgewiesen werden.
TinyAODV“ [43]
UoB JAdhoc“ [44]
”
RFC 3561 [IETF, 2003d]
Windows AODV“ [46]
”
RFC 3561 [IETF, 2003d]
Betriebssystem:
Tiny OS
MS Windows;
MS Windows
Systemanforderungen:
WLAN-Karte
Linux OS:
RFCs und Drafts:
Linux OS
Linux Kernel mit “IP:advanced router“
MS Windows XP;
WLAN-Karte
MS Windows 2000/XP;
WLAN-Karte
Softwareanforderungen:
Linux OS:
JRE [23] oder SDK [22], Libpcap“ [26]
”
und Jpcap“ [24]
”
MS Windows:
JRE [23] oder SDK [22], WinPcap“ [47]
”
und Jpcap“ [24]
”
Zaurus Linux:
Cross-Compiler“ ( gcc“) für
”
”
ARM Prozessor
Sonstige Eigenschaften:
verschiedene Vereinfachungen der AODV-
IPv4-Unterstützung
verwendet UDP/IP-Port 654
Ja
Ja
Implementierung
Funktionsfähig:
Keine Aussage
Tabelle 3.3: Übersicht zu den AODV-Implementierungen (3)
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
Implementierung:
38
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
39
In der Tabelle 3.4 sind alle AODV-Implementierungen dargestellt und es werden entsprechende Aussagen zur Funktionsfähigkeit getroffen.
Implementierung
Funktionsfähig
AODV IPv6“
”
AODV Kernel“
”
Ja
Nein
Begründung
Die aktuelle Version ist nicht funktionsfähig,
denn es existieren Probleme mit dem Inter”
face“. Aber v2.1.0 [4] ist funktionsfähig.
AODV-UCSB“
”
Nein
Keine Aussage, denn die Verwendung wird
nicht mehr empfohlen!!
AODV-UIUC“
”
Nein
Trotz ASL [1] nicht funktionsfähig. Beim Erstellen der Software treten Probleme auf.
AODV-UU“
”
AODV-UU for IPv6“
”
Ja
Nein
Diese
Implementierung
ist
nicht
funkti-
onsfähig, denn es existieren Probleme mit dem
Kernel.
Hut AODV for IPv6“
”
Nein
Die Funktionsfähigkeit konnten nicht nachgewiesen werden, denn es kommt zu Problemen
mit dem Kernelmodul.
MAODV“
”
TinyAODV“
”
Ja
Keine Aussage
Eine Aussage zur Funktionsfähigkeit ist nicht
möglich, denn zum Zeitpunkt der Test lag kein
Tiny OS vor.
UoB JAdhoc“
”
Ja
Diese Implementierung ist funktionsfähig, aber
nach den ersten Tests wird die Verwendung
nicht mehr empfohlen!!
Windows AODV“
”
Ja
Tabelle 3.4: AODV-Implementierungen - Aussagen zur Funktionsfähigkeit
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
3.1.2
40
ARAN
Für die Verwendung von ARAN muss
arand“ [10] und ein X.509-Zertifikat auf
”
jedem Knoten des Ad-hoc-Netzes installiert werden. X.509 [IETF, 2002d] ist ein
ITU-T ( International Telecommunication Union-Telecommunication Standardizati”
on“)-Standard für eine Public Key Structure“ und stellt derzeit den wichtigsten Stan”
dard für die digitalen Zertifikate dar. Zusätzlich werden dem Anwender zwei weitere
Tools bereitgestellt:
• arandview“:
”
arandview“ [10] ist ein Graphical User Interface“ (GUI), welches die Überwa”
”
chung von arand“ ermöglicht.
”
• aranca“:
”
arance“ [10] stellt eine Einhüllung“ um die OpenSSL“ ( Secure Socket Layer“)
”
”
”
”
Kommandozeilenprogramme zur Verfügung. Dies dient der Entwicklung von
Certifcate Authorities“ (CA).
”
Implementierung:
ARAN [10]
Betriebssystem:
Linux OS
Drafts und RFCs:
Systemanforderungen:
x86 PC/Laptop;
Linux 2.4.x;
WLAN-Karte;
X.509-Zertifikat auf jedem Knoten
Softwareanforderungen:
OpenSSL Library“;
”
ASL [1]
Sonstige Eigenschaften:
Funktionsfähig:
Nein
Tabelle 3.5: Übersicht zu ARAN
ARAN (s. Tabelle 3.5) wurde für Linux OS entwickelt und benötigt als zusätzliche
Softwarekomponenten die OpenSSL Library“ und ASL [1]. Die Funktionsfähigkeit
”
von ARAN kann nicht nachgewiesen werden. Genaue Angaben und die Spezifikation
zu ARAN sind im Anhang A.1.2 zu finden.
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
3.1.3
41
DSR
Für DSR existiert nur eine kleine Anzahl von Implementierungen, die in der Tabelle 3.6
dargestellt sind. In der Tabelle sind neben den Anforderungen und den allgemeinen
Eigenschaften auch Aussagen zur Funktionsfähigkeit enthalten. Spezifische und
detaillierte Angaben zu den einzelnen Implementierungen sind im Anhang A.1.3 zu
finden.
Die
dargestellten
DSR-Implementierungen
den
unterstützten
Betriebssystemen.
unterscheiden
sich
bereits
bei
Während
DSR (Insignia)“ [13] und
”
DSR (Monarch)“ [14] nur für FreeBSD ( Berkeley Software Distribution“) konzipiert
”
”
sind, kann DSR (UC-Boulder-Click!)“ [16] nur für Linux OS verwendet werden.
”
Die Implementierung DSR (Piconet)“ [15] ist sowohl für Linux OS als auch für
”
BSD OS konzipiert. Für DSR (Insignia)“ und DSR (Monarch)“ wird FreeBSD
”
”
2.2.7/3.3 benötigt. Für DSR (Insignia)“ sind zusätzliche MAC-Filter und einige
”
Softwarekomponenten erforderlich. Diese beiden Implementierungen besitzen eine
Vielzahl von Eigenschaften, die in der Tabelle A.8 dargestellt sind. DSR (Piconet)“
”
bietet als einzige DSR-Implementierung die Handheld“-Unterstützung, dafür sind
”
aber entsprechende Softwarekomponenten erforderlich. Ein wesentlicher Unterschied
zwischen
DSR (UC-Boulder-Click!)“ und den anderen DSR-Implementierungen
”
besteht darin, dass DSR (UC-Boulder-Click!)“ [16] nur in Verbindung mit der
”
Click! Modular Router“-Software [11] funktionsfähig ist. Zusätzlich zu der Click!
”
”
Modular Router“-Software werden die Wireless Tools“ [48] benötigt. Zu den beiden
”
auf FreeBSD basierenden Implementierungen sind keine Aussagen möglich, denn zum
Zeitpunkt der Tests stand FreeBSD nicht zur Verfügung. Die ersten Tests mit DSR
”
(Piconet)“ konnten die Funktionsfähigkeit nicht bestätigen, denn beim Erstellen der
Software treten Probleme auf. DSR (UC-Boulder-Click!)“ ist von den vorgestellten
”
Implementierungen die einzige, die funktionsfähig ist. Es sind aber umfangreiche
Veränderungen am Kernel erforderlich.
DSR (Insignia)“ [13]
”
draft-ietf-manet-insignia-
DRS (Monarch)“ [14]
”
draft-ietf-manet-dsr-01
01 [IETF, 1999]
1998]
Betriebssystem:
FreeBSD
FreeBSD
Linux OS/BSD OS;
Systemanforderungen:
FreeBSD 2.2.7;
FreeBSD 2.2.7/3.3;
Linux 2.4.3;
Linux 2.4.2;
x86 Laptop;
x86 Laptop;
x86 PC;
x86 PC/Laptop;
WLAN-Karte (Lucent);
WLAN-Karte
RFCs und Drafts:
DSR (Piconet)“ [15]
”
[IETF,
DSR (UC Boulder-Click!)“ [16]
”
draft-ietf-manet-dsr-08 [IETF,
2003a]
Linux OS
UNIX-like OS
Softwareanforderungen:
WLAN-Karte (Lucent Orinoco);
WLAN-Karte;
MAC-Filter
H3600 Series Compaq iPAQ;
DSR Kernel Source Code“ [13];
”
Netfilter“
”
Cross Compiler“ und Varios
”
”
Tools“ für iPAQ;
Wireless Tools“ [48];
”
Kernel Tap“-Option
”
Click!
Modular
”
v1.2.4 [11];
INSIGNIA Kernel Source Co”
de“ [13];
INSIGNIA
”
de“ [13];
Sonstige Eigenschaften:
GUI-API
0.20 iPAQ/Linux Distribution“
”
oder Familiar Linux Distributi”
on“ 0.4
Co-
Tcl/Tk“ 8.0
”
basiert auf der CMU Implemen-
zwei Phasen Route Discovery“;
”
IPv4-Unterstützung;
GUI mit Kontrolle von API;
Handheld“-Unterstützung
”
tierung von DSR;
nur in Verbindung mit
Click!
”
Modular Router“ [11] funktionsfähig
einfacher
QoS-Benachrichti-
gungsmechanismus;
Funktionsfähig:
Router“
MPEG I Video Header Parser
”
Tool“ ;
Route-Cache“;
”
GUI mit Kontrolle von API;
Multi-Level Priority Interface
”
Queues“;
MPEG TV“
”
Keine Aussage
Paket rettent
Keine Aussage
Nein
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
Implementierung:
Ja
Tabelle 3.6: Übersicht zu den DSR-Implementierungen
42
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
43
In der Tabelle 3.7 sind alle DSR-Implementierungen dargestellt und es werden entsprechende Aussagen zur Funktionsfähigkeit getroffen.
Implementierung
Funktionsfähig
Begründung
DSR (Insignia)“
”
Keine Aussage
Eine Aussage zur Funktionsfähigkeit ist nicht
möglich, denn zum Zeitpunkt der Tests war
kein FreeBSD verfügbar.
DSR (Monarch)“
”
Keine Aussage
Ebenfalls keine Aussage, denn zum Zeitpunkt
DSR (Piconet)“
”
Nein
Die Funktionsfähigkeit konnte nicht nachge-
der Tests war kein FreeBSD verfügbar.
wiesen werden, denn beim Kompilieren treten
Fehler auf.
DSR (UC Boulder-Click!)“
”
Ja
Diese Implementierung ist funktionsfähig, aber
nur in Verbindung mit Click! Modular Rou”
ter“ [11]!!
Tabelle 3.7: DSR-Implementierungen - Aussagen zur Funktionsfähigkeit
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
3.1.4
44
FSR-ATR“
”
Zum Zeitpunkt der Recherchen existierte nur diese eine Implementierung von FSR.
FSR-ATR“ ( Advanced Telecommunications Researche“) [17] (s. Tabelle 3.8) basiert
”
”
mit den folgenden Veränderungen auf draft-ietf-manet-fsr-03 [IETF, 2002a]:
• Länge des Feldes Destination Sequence Number“ (Draft: 24 bits, Implementie”
rung: 16 bits),
• Länge des Feldes N neighbors“ (Draft: 8 bits, Implementierung: 16 bits) und
”
normal Dijkstra“ statt modifiziert-“Dijkstra“ zur Berechnung der Routen
”
Die Gründe für diese Veränderungen werden aber nicht aufgezeigt.
Implementierung:
Betriebssystem:
FSR-ATR“ [17]
”
Linux OS
RFCs und Drafts:
draft-ietf-manet-fsr-03 [IETF, 2002a]
Systemanforderungen:
x86 PC/Laptop;
Linux 2.2.x/2.4.x/2.6.x;
WLAN-Karte (Lucent Orinoco);
H3600 series Compaq iPAQ;
Softwareanforderungen:
Netfilter“
”
Linux Cross Compiler“ und Various Tools“
”
”
0.20 iPAQ/Linux für iPAQ;
0.20 iPAQ/Linux Distribution“ oder Famili”
”
ar Linux Distribution“ 0.40
Sonstige Eigenschaften:
IPv4-Unterstützung;
Unterschiede zu draft-ietf-manet-fsr-03 [IETF,
2002a]
Funktionsfähig:
Ja
Tabelle 3.8: Übersicht zu FSR-ATR“
”
Diese Implementierung ist für Linux OS konzipiert und erfordert zusätzlich den
Netfilter-Support“. FSR-ATR“ kann auch für Handhelds“ verwendet werden, da”
”
”
zu sind aber zusätzliche Softwarekomponenten erforderlich. Diese Implementierung
wird weiterentwickelt und somit ist die Funktionsfähigkeit unter neueren Linux OSVersionen gewährleistet. Erste Tests mit FSR-ATR“ konnten die Funktionsfähigkeit
”
nachweisen. Detaillierte Angaben zu dieser Software sind im Anhang A.1.4 zu finden.
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
3.1.5
45
OLSR
Die in den Tabellen 3.9 und 3.10 dargestellten OLSR-Implementierung sind nur für
Linux OS konzipiert. Beim Vergleich der Systemanforderungen wird deutlich, dass
bei allen Implementierungen nur geringe Anforderungen existieren. Für alle sind eine
WLAN-Karte und das entsprechende Linux OS erforderlich. Für crc-nolsrdv6“ [12],
”
inria-nolsrd“ [19] und OLSRv3 (Inria)“ ( Institut National De Recherche En Infor”
”
”
matique Et En Automatique“) [37] wird zusätzlich IP-Forward“ benötigt. Weiter”
hin benötigt PyOLSR“ ( Python OLSR“) [41] XFree86“. Fast alle Implementierun”
”
”
gen verwendet den UDP-Port 698. QOLSR“ ( QoS for OLSR“) [42] ist die einzige
”
”
Implementierung, die IPv6 und QoS bietet. crc-nolsrdv6“, inria-nolsrd“, OLSRv3
”
”
”
(Inria)“, OLSR EXTRA“ [36] und PyOLSR“ sind nach den ersten Tests nicht funk”
”
tionsfähig. Speziell bei OLSRv3 (Inria)“ treten Fehler beim Kompilieren auf, diese
”
weisen auf Probleme mit dem gcc“ hin. Die Funktionsfähigkeit von QOLSR“ konnte
”
”
nur mit IPv4 nachgewiesen werden.
Implementierung:
crc-nolsrdv6“ [12]
”
inria-nolsrd“ [19]
”
draft-ietf-manet-olsr-03 [IETF, 2000c]
Betriebssystem:
Linux OS
Linux OS
Systemanforderungen:
Linux 2.x.x;
Linux 2.x.x;
WLAN-Karte;
WLAN-Karte;
IP-Forward“
”
IP-Forward“
”
Sonstige Eigenschaften:
Modifikation des Inria OLSR Source”
Codes“
IPv4-Unterstützung;
Funktionsfähig:
Nein
Nein
RFCs und Drafts:
Softwareanforderungen:
verwendet UDP-Port 698
Tabelle 3.9: Übersicht zu den OLSR-Implementierungen (1)
RFCs und Drafts:
OLSRv3 (Inria)“ [37]
”
draft-ietf-manet-olsr-03 [IETF,
OLSR EXTRA“ [36]
”
PyOLSR“ [41]
”
RFC 3626 [IETF, 2003e]
QOLSR“ [42]
”
RFC 3626 [IETF, 2003e]
Betriebssystem:
Linux OS
Linux OS
Linux OS
Linux OS
Systemanforderungen:
Linux 2.x.x;
Linux OS;
Linux OS;
Linux 2.4;
WLAN-Karte;
WLAN-Karte
WLAN-Karte;
WLAN-Karte
2000c]
IP-Forward“
”
XFree86“
”
IPv4-Unterstützung;
verwendet UDP-Port 698
Softwareanforderungen:
Sonstige Eigenschaften:
gcc“ v3.0
”
IPv4- und IPv6-Unterstützung;
verwendet UDP-Port 698;
verwendet UDP-Port 698;
User-Space-Daemon“;
”
keine Modifikation des Kernels
bietet QoS;
erforderlich
Notification“
kein Support für
Considerations“
Funktionsfähig:
Nein
Nein
Keine Aussage
Tabelle 3.10: Übersicht zu den OLSR-Implementierungen (2)
Ja
Link Layer
”
und
Security
”
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
Implementierung:
46
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
47
Die OLSR-Implementierungen, die sowohl unter MS Windows als auch Linux OS
verwendet werden können, sind in der Tabelle 3.11 dargestellt. Wiederum sind die
Anforderungen an das System sehr gering, lediglich das entsprechende Betriebssystem
und eine WLAN-Karte werden benötigt. Für
OLSR (GRC, UPV)“ ( OLSR ”
”
Grupo de Investigaciòn de Redes de Computadores, Universidad Politèchnica de
Valencia“) [33] ist unter Linux OS zusätzlich IP-Forward“ und die PICA ( Pro”
”
”
tocol Implementation Specific API“)-Library“ [40] erforderlich. Von OOLSR“ [38]
”
werden für Linux OS die beiden Softwarekomponenten g++“ v2.95/3.3 und glibc“
”
”
v2.3.2. benötigt. OLSR (GRC, UPV)“ bietet Pocket-PC“-Unterstützung. Von den
”
”
vorgestellten Implementierungen bietet OOLSR“ IPv4-Unterstützung unter MS
”
Windows, IPv4- und IPv6-Unterstützung unter Linux OS, Cygwin-Support“ und
”
kann im ns2 [29] eingesetzt werden. OOLSR“ ist aber unter Linux OS nur mit
”
IPv4 funktionsfähig. Da für die Tests kein Cygwin“ zur Verfügung stand, können
”
keine Aussagen zur Funktionsfähigkeit unter MS Windows getroffen werden. Die
Implementierungen nrlolsrd“ [32], OLSR (GRC, UPV)“ und OLSRD“ ( OLSR
”
”
”
”
Daemon“) [35] sind unter beiden Betriebssystem, d.h. Linux OS und MS Windows,
funktionsfähig.
OLSR (GRC, UPV)“ [33]
”
RFCs und Drafts:
nrlolsrd“ [32]
”
RFC 3626 [IETF, 2003e]
OLSRD“
”
RFC 3626 [IETF, 2003e]
OOLSR“ [38]
”
RFC 3626 [IETF, 2003e]
Betriebssystem:
Linux OS;
Linux OS;
Linux OS;
Linus OS;
MS Windows
MS Windows
MS Windows
MS Windows
Linux OS;
Linux 2.x.x;
Linux OS;
Linux OS:
MS Windows;
MS Windows;
MS Windows;
WLAN-Karte
WLAN-Karte;
WLAN-Karte
g++“ v2.95/3.3,
”
glib“ v2.3.2
”
MS Windows 2000/XP und CE
Systemanforderungen:
IP-Forward“
”
ARM;
WLAN-Karte
Softwareanforderungen:
PICA Library“ [40]
”
IPv4-Unterstützung;
Sonstige Eigenschaften:
IPv4- und IPv6-Unterstützung
für Linux OS;
Pocket-PC“-Unterstützung;
”
IPv4-Unterstützung
Windows;
verwendet UDP-Port 698
Funktionsfähig:
Ja
Ja
Cygwin Support“;
”
ns2-Unterstützung
Ja
Tabelle 3.11: Übersicht zu den OLSR-Implementierungen (3)
Ja (teilweise)
für
MS
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
Implementierung:
48
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
49
OLSR11win (GRC)“ [34] und nOLSR“ [31] sind nur unter MS Windows anwendbar.
”
”
Diese beiden Implementierungen mit den entsprechenden Eigenschaften sind in der
Tabelle 3.12 aufgeführt. Beide Implementierungen haben lediglich als Systemanforderungen das Betriebssystem und eine WLAN-Karte. Für OLSR11win (GRC)“ ist
”
zusätzlich die Software WinPcap“ [47] erforderlich. Beide Implementierungen sind
”
funktionsfähig und auffällig ist die Ähnlichkeit.
Implementierung:
RFCs und Drafts:
nOLSR“ [31]
”
RFC 3626 [IETF, 2003e]
OLSR11win (GRC)“ [34]
”
draft-ietf-manet-olsr-11 [IETF, 2003c]
Betriebssystem:
MS Windows
MS Windows
Systemanforderungen:
MS Windows;
MS Windows;
WLAN-Karte
WLAN-Karte
Softwareanforderungen:
WinPcap“ [47]
”
Sonstige Eigenschaften:
Funktionsfähig:
Ja
Ja
Tabelle 3.12: Übersicht zu den OLSR-Implementierungen (4)
Von allen dargestellten Implementierungen fällt ein besonderes Augenmerk auf
OLSRD“ (s. Tabelle 3.11). Diese Implementierung ist sowohl in Linux OS als auch
”
MS Windows anwendbar. Die Entwickler stellen entsprechend neuere und verbesserte
Versionen zur Verfügung. Die OLSR-Community“ biete hilfreiche Unterstützung, bei
”
Fragen und Problemen zu OLSRD“. Eine praktische Anwendung erfolgt beim Frei”
funkt.Net [fre, ].
Detaillierte und spezifische Angaben zu jeder vorgestellten Implementierung sind im
Anhang A.1.5 zu finden. In der Tabelle 3.13 sind alle OLSR-Implementierungen dargestellt und es werden entsprechende Aussagen zur Funktionsfähigkeit getroffen.
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
Implementierung
Funktionsfähig
crc-nolsrdv6“
”
inria-nolsrd“
”
Ja
Nein
50
Begründung
Diese Implementierung ist unter Linux OS
nicht funktionsfähig. Es treten Probleme beim
Kompilieren und Erstellen der Software auf.
nOLSR“
”
nrlolsrd“
”
OLSR (GRC, UPV)“
”
OLSRD“
”
OLSRv3 (Inria)“
”
Ja
Ja
Ja
Ja
Nein
Diese
Implementierung
ist
nicht
funkti-
onsfähig, denn es treten Probleme beim Kompilieren und Erstellen der Software auf.
OLSR11win (GRC)“
”
OSRD EXTRA“
”
Ja
Nein
Diese
Implementierung
ist
nicht
funkti-
onsfähig, denn beim Erstellen der Software treten Probleme auf.
OOLSR“
”
Ja
Diese Implementierung ist unter Linux OS nur
mit IPv4 funktionsfähig. Zum Zeitpunkt der
Tests ist keine Aussage zur Funktionsfähigkeit
unter MS Windows möglich, denn Cygwin“
”
stand nicht zur Verfügung.
PyOLSR“
”
Keine Aussage
Keine Aussagen zur Funktionsfähigkeit, denn
zum Zeitpunkt der Tests stand Python“ nicht
”
zur Verfügung.
QOLSR“
”
Ja
Diese Implementierung ist unter Linux OS nur
mit IPv4 funktionsfähig.
Tabelle 3.13: OLSR-Implementierungen - Aussagen zur Funktionsfähigkeit
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
3.2
3.2.1
51
Tools für Ad-hoc-Netze
APE ( Ad hoc Protocol Evaluation“) testbed“
”
”
Innerhalb der APE Linux Distribution“ [9] können Tests durchgeführt und Daten
”
gesammelt werden. APE“ ist ein Softwarepaket und kann ohne Neupartitionierung
”
oder komplizierte Installationsverfahren in einem vorhandenen Linux OS oder MS
Windows mit der DOS-Unterstützung installiert werden. Die APE Distribution“ ist
”
bereits vorkonfiguriert und enthält Werkzeuge für die Datenerfassung, sowohl auf der
IP als auch auf der Ethernetschicht. Mit Hilfe des APE Source-Codes“ können ei”
gene APE Distributionen“ erstellt werden. Im Source-Code“ sind Analysewerkzeuge
”
”
für die Auswertung der ermittelten Daten enthalten. In APE“ sind momentan die
”
folgenden Routingprotokolle implementiert:
• AODV-UU“,
”
• Mad-hoc AODV“,
”
• OLSR (INRIA)“,
”
• LUNAR“ ( Lightweight Underlay Network Ad-hoc Routing“),
”
”
• TORA (University of Maryland, College Park)“ und
”
• DSR (Universität von Queensland)“.
”
Neben den bereits implementierten Protokollen können weitere Routingprotokolle integriert werden. Es existieren folgende APE-Tools“:
”
1. Mackill“
”
Mackill“ ist ein MAC-Filter, mit dem verschiedene Verbindungskonfigurationen
”
in Ad-hoc-Netzen durchgeführt werden.
2. Analysis“
”
Die Analyse-Tools dienen der einfachen Analyse von:
• Virtueller Beweglichkeit,
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
52
• Konnektivität,
• Verbindungsänderung,
• Hop“-Zählung,
”
• Routenoptimierung und
• Ping“-Erfolgsverhältnis.
”
3. APE-View:“
”
APE-View“ ist ein protokollgesteuertes Animationstool.
”
3.2.2
Click! Modular Router“
”
Mit Hilfe von Click!“ [11] können flexible und konfigurierbare Router erstellen wer”
den. Die Click! Router“ besitzt einen modularen Aufbau und die gesamte Konfigura”
tion wird durch einen gerichteten Graphen dargestellt. Jeder Knoten dieses Graphen
ist ein Element, welches einfache Routingfunktionalitäten wie Packet Classification“,
”
Queueing“, Scheduling“ und das Verbinden von Netzwerkgeräten realisiert (s. Ab”
”
bildung 3.1). Die Elemente sind durch die gerichteten Kanten der Graphen verbun-
Abbildung 3.1: Click!“ - Beispiel für ein einfaches Element
”
den. Der Graph veranschaulicht den Datenfluss im Router (s. Abbildung 3.2). Jeder
Click! Router“ unterstützt Push“- und Pull“-Operationen. Mit Hilfe der Push“”
”
”
”
Operation können Daten zum nächsten Element weitergeleitet werden. Bei der Pull“”
Operation signalisiert ein Element seine Empfangsbereitschaft (z.B. ToDevice“) und
”
sucht rückwärts im Graphen nach sendebereiten Daten. Von Click!“ werden auch
”
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
53
Abbildung 3.2: Click!“ - Einfaches Beispiel eines Click!“ Routers
”
”
Elemente bereit gestellt, die beide Operationen anbieten und sich je nach Konfiguration wie ein Push“- oder Pull“-Objekt verhalten. Diese Elemente werden Agnostic“
”
”
”
genannt. Für die Kopplung von Elementen ( Push“, Pull“ oder Agnostic“) müssen
”
”
”
deshalb bestimmte Vorgaben beachtet werden. Aus diesem Grund existieren für das
Erstellen einer Click!“-Konfiguration strenge syntaktische Regeln.
”
Jedes Element besitzt folgende Eigenschaften:
• Klasse des Elements:
Jedes Click!“ Element ist ein C++-Objekt und wie bei jeder objektorientierten
”
Programmiersprache bestimmt auch hier die Klasse das Objektverhalten.
• Ein- und Ausgänge:
Zur Kommunikation mit den verbundenen Elementen besitzt jedes Element eine unterschiedliche Anzahl von Ein- und Ausgängen. Je nach Klasse besitzen
die Ein- bzw. Ausgänge eine unterschiedliche Semantik, z.B. Fehlerausgabe oder
Ergebnisse einer Case“-Verzweigung bei Classifier-Objekten“.
”
”
• Konfigurationsangaben:
Bei der Initialisierung einer Objektinstanz kann ein String“ übergeben werden,
”
der zur Konfiguration des Objektes genutzt wird. Bei Tee“-Objekten wird z.B.
”
die Anzahl der gewünschten Ausgänge mit übergeben.
In der Abbildung 3.3 ist ein Beispiel dargestellt. Jedes Element wird durch ein Rechteck
dargestellt. Die Ausgänge sind rechteckig und die Eingänge werden als Dreiecke gekennzeichnet. Ports, die nach dem Push“-Verfahren arbeiten, sind schwarz ausgefüllt,
”
Pull“ dagegen verwendet zur Darstellung unausgefüllte Symbole.
”
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
54
Abbildung 3.3: Click!“ - Beispiel eines konfigurierten Click! Routers“
”
”
Ein Ein- bzw. Ausgang, der Agnostic“, wird durch eine zusätzliche Umrandung ge”
kennzeichnet. Die Füllung des eigentlichen Symbols erklärt die momentane Verwendung im Router, in diesem Fall wird das Counter“-Objekt als Push“-Objekt verwen”
”
det.
Über das Netzwerkinterface eth0“ werden Pakete an das Tee“-Objekt weitergege”
”
ben, das eine Duplizierung der Pakete vornimmt. Ein Exemplar jedes Paketes wird
gezählt und anschließend an einen Analysator weitergereicht. Das Duplikat der Pakete
wird in eine Queue“ geschrieben, aus der sich die Device“ eth1, mittels Pull“, bei
”
”
”
Sendebereitschaft Pakete holt und nach Draußen überträgt.
3.2.3
LUNAR“ ( Lightweight Underlay Network Ad hoc
”
”
Routing“)
LUNAR“ [27] ist ein einfaches, robustes und selbstkonfigurierendes Ad-hoc”
Routingsystem, welches eine IP-Subnet Illusion“ schafft. LUNAR“ wurde als ein
”
”
Kernelmodul entwickelt, das in ein laufendes System dynamisch geladen werden kann.
Der Anwender kann sich an ein Ad-hoc-Netz anzuschließen und alle zur Verfügung
gestellten Internetanwendungen benutzen. LUNAR“ realisiert ein On-Demand Rou”
”
te Discovery Protocol“ und arbeitet gut in Ad-hoc-Netz mit weniger als 10 Teilnehmern. Die IP-Adressen werden selbst konfiguriert und automatisches IP-Gatewaying“
”
ist enthalten. Weiterhin werden IP-Unicast“ und Broadcast“ unterstützt. Somit ist
”
”
LUNAR“ die ideale Lösung für spontane Ad-hoc-Netze und Wireless-Ad-hoc Inter”
”
net“.
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
3.2.4
55
PACMAN“ ( Passive Autoconfiguration for Mobile
”
”
Ad hoc Networks“) und WNTE“ ( Wireless Network
”
”
Topology Emulator“)
PACMAN“ [39] wurde am Institut für Telematik an der Universität Karlsruhe
”
entwickelt und stellt eine effiziente und robuste Lösung für die Adressautokonfiguration in Ad-hoc-Netzen dar.
PACMAN“ erzeugt kaum Netzlast, da es die
”
Information aus dem fortlaufenden Routingprotokollverkehr entnimmt. Dieses
Cross-Layer“/“Cross-Protocol-Design“ ist viel effektiver in bezug auf Netzlast als
”
ein Design mit unabhängigen Routingprotokollen. Z.B. wird das Passiv Duplicate
”
Address Detection“ (PDAD)-Konzept zur Erkennung von Adresskonflikten, basierend auf Anomalien im Routingprotokolverkehr, verwendet. Die Modularchitektur
erleichtert die Integration neuer Routingprotokolle. Eine signifikante Herausforderung
von Autokonfigurationsprotokollen besteht häufig in der potenziellen Vermischung
unabhängiger Netze. Demzufolge können Adresskonflikte auftreten und das Routing
von Paketen wird beeinflusst.
WNTE“ [49] ist ein Linux-Tool, welches zum Test oder zur Demonstration von Ad”
Hoc-Netzen verwendet werden kann. WNTE“ emuliert eine Multi-Hop“-Topologie,
”
”
indem die Knoten, die sich tatsächlich im Sendebereich eines anderen befinden,
mit IP-Table MAC-Filter-Rules“ konfiguriert werden. Die Konfiguration der MAC”
”
Filter-Rules“ erfolgt über einen Secure Shell Login“. Somit werden Pakete von einem
”
bestimmten Nachbarn sofort verworfen. Die zu emulierende Topologie kann mit einem
Qt-based GUI“ gesetzt und visualisiert werden (s. Abbildung 3.4).
”
3.2.5
ViTAN“ ( Visualization Tool for Ad Hoc Networks“)
”
”
Das ViTAN“-Projekt [45] entstand in Kooperation mit der Arizona State University“
”
”
(ASU) und der Universität von Ferrara“. ViTAN“ ist ein frei verfügbares Tool zur
”
”
Darstellung der Verbindungen und der Verbindungsqualität der Knoten in einem Adhoc-Netz. Als Input verwendet das Tool die Position der Knoten, angegeben durch X-
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
56
Abbildung 3.4: WNTE - Beispiel
und Y-Koordinaten und die Verbindungsqualitäten zwischen den Knoten, angegeben
durch Integer“-Werte. Das Tool erstellt die Visualisierung des Netzwerkes im fig“”
”
Format, das zu jedem allgemeinen graphischen Format umgewandelt werden kann.
ViTAN“ bewertet aber nicht die Verbindungen und Verbindungsqualitäten in einem
”
Ad-hoc-Netz. Stattdessen benutzt ViTAN“ zur Bestimmung der Verbindungsqua”
litäten andere Tools, Simulationen oder analytischen Einschätzungen als Input und
stellt dann graphisch diese Verbindungsqualitäten und die resultierenden Verbindungen im Netz dar. ViTAN“ erleichtert die graphische Analyse komplexer Ad-hoc-Netze,
”
dabei werden höhere Verbindungsqualitäten mit dickeren Rändern und in dunkleren
grauen Schatten dargestellt. Außerdem zieht ViTAN“ die Ränder in Abhängigkeit
”
von der entsprechenden Verbindungsqualität an verschiedenen Tiefenebenen des fig“”
Formats. Diese Eigenschaft ermöglicht die selektive Darstellung und graphische Analyse der Verbindungen anhand der Links“ mit einem spezifischen Qualitätsbereich.
”
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
3.2.6
57
Zusammenfassung und Gegenüberstellung der Tools
In den nachfolgenden Tabellen 3.14 und 3.15 sind die momentan vorhandenen Softwaretools dargestellt und anhand ausgewählter Eigenschaften, wie beispielsweise Anforderungen an das System und die Software, kann eine Unterscheidung vorgenommen
werden. Die Softwaretools Click! Modular Router“, LUNAR“ und PACMAN“ sind
”
”
”
für Linux OS konzipiert. APE“ kann sowohl unter MS Windows als auch Linux OS
”
verwendet werden. Die Softwaretools, die in den Tabellen gegenübergestellt werden,
unterscheiden sich in der Anwendung und Funktionsweise. Die beiden Softwarepakete APE“ und LUNAR“ können neben dem bereits vorhandenem Betriebssystem
”
”
installiert und betrieben werden. In APE“ sind eine Vielzahl von Routingprotokol”
len implementiert. LUNAR“ bietet ebenfalls die Möglichkeit einer Installations-CD.
”
Click! Modular Router“ stellt ein umfangreiches Softwarepaket dar, welches zur Kon”
figuration von Routern benutzt wird. Die Anwendung ist nicht nur auf Ad-hoc-Netze
beschränkt, sondern alle möglichen Netztypen können realisiert und die entsprechenden Router konfiguriert werden. Von den in diesem Abschnitt vorgestellten Tools und
Programmen erfordert Click!“, den höchsten Installationsaufwand (s. Anhang D.1).
”
Umfassende Veränderungen am Kernel sind vorzunehmen, um die Funktionsfähigkeit
zu gewährleisten. Der große Vorteil besteht aber in der Breite der Anwendungsmöglichkeiten. Die Entwicklung erfolgt fortschreitend und die Implementierungen zu einigen
Routingverfahren, sind frei verfügbar. PACMAN“ zeichnet sich dadurch aus, dass die
”
Entwicklung fortschreitend ist. Entsprechende Modifikationen am Kernel müssen vorgenommen werden, um eine Funktionsfähigkeit zu gewährleisten. In der momentanen
Version sind die beiden Implementierungen, FSR-ATR“ [17] und OLSRD“ [35], in”
”
tegriert. Die Entwickler schließen aber nicht aus, dass weitere Routingprotokolle, wie
beispielsweise AODV, integriert werden. PACMAN“ bietet auf einfache Art und Weise
”
das Betreiben eines Ad-hoc-Netzes an, indem die IP-Adressen selbständig konfiguriert
werden und auf die entsprechenden Konfigurationen von OLSRD“ und FSR-ATR“
”
”
zugegriffen wird. Hinweise zur Installation sind im Anhang D.2 zu finden. Zur Visualisierung des Netzes wird das Tool WNTE“ verwendet. Mit Hilfe von ViTAN“ können
”
”
die Knotenposition zur Visualisierung des Ad-hoc-Netzes verwendet werden.
APE“ [9]
”
Click! Modular Router“ [11]
”
LUNAR“ [27]
”
RFCs und Drafts:
PACMAN“ [39]
”
draft-ietf-manet-fsr-03 [IETF,
2002a];
draft-ietf-manet-olsr-03 [IETF,
2000c];
RFC 3626 [IETF, 2003e]
Betriebssystem:
Linux OS;
Linux OS
Linux OS
Linux OS
Linux 2.2/2.4;
Linux 2.4/2.6;
Linux 2.4.19/2.6.x;
Vanilla Linux Kernel“,
”
WLAN-Karte;
WLAN-Karte;
min. 700 MHz Pentium III;
TUN/TAP Device“, ARPD“
”
”
und Netfilter“
”
CONFIG IP NF QUEUE“
”
MS Windows
Systemanforderungen:
Linux OS:
Lilo“ oder Grub boot”
”
loader“,
Ext2“, Ext3“ oder
”
”
ReiserFS“ (Filesystem)
”
MS Windows mit DOS;
WLAN-Karte
WLAN-Karte
Softwareanforderungen:
Sonstige Eigenschaften:
Pcap Liprary“
”
Wireless Tools“ [48];
”
LUNAR Kernel Module“
”
integrierte in APE“ [9]
”
Ja
Keine Aussage
momentan sind folgenden Routingprotokolle implementiert:
Funktionsfähig:
AODV-UU“;
”
Mad-hoc AODV“;
”
OLSR (Inria)“;
”
LUNAR“;
”
TORA“;
”
DSR“
”
Nein
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
Implementierung:
Ja
Tabelle 3.14: Übersicht zu den Tools für Ad-hoc-Netze (1)
58
KAPITEL 3. SOFTWAREKOMPONENTEN FÜR AD-HOC-NETZE
Implementierung:
WNTE“ [49]
”
59
ViTAN“ [45]
”
RFCs und Drafts:
Betriebssystem:
Linux OS
Linux OS;
MS Windows
Systemanforderungen:
Linux OS;
Linux OS;
WLAN-Karte;
MS Windows XP;
iptable“, ipmac“ und
”
”
ssh public key“ auf jedem Knoten
”
WLAN-Karte
Softwareanforderungen:
Sonstige Eigenschaften:
Verwendung
Funktionsfähig:
PACMAN“ [39]
”
Ja
in
Verbindung
mit
Pcap Library“
”
mit Hilfe der Knotenkoordinaten wird das
Netz dargestellt
Ja
Tabelle 3.15: Übersicht zu den Tools für Ad-hoc-Netze (2)
Detaillierte und spezifische Angaben zu jedem vorgestellten Tool sind im Anhang A.2
zu finden. In der Tabelle 3.16 sind alle Tools dargestellt und es werden entsprechende
Aussagen zur Funktionsfähigkeit getroffen.
Implementierung
Funktionsfähig
Begründung
APE“
”
Nein
Probleme bei der Installation treten auf. Das
Click! Modular Router“
”
LUNAR“
”
Ja
WLAN-“Interface“ wird nicht erkannt.
Keine Aussage
Zusätzliche Veränderungen an der Festplattenpartitionierung bzw. eine weiter Festplattenpartition sind erforderlich.
PACMAN“
”
ViTAN“
”
WNTE“
”
Ja
Ja
Ja
Tabelle 3.16: Tools für Ad-hoc-Netze - Aussagen zur Funktionsfähigkeit
KAPITEL 4. KONZEPTION DER TESTUMGEBUNG
60
Kapitel 4
Konzeption der Testumgebung
Innerhalb dieses Kapitels wird ein Konzept für die Testumgebung erstellt. Die Konzipierung basiert auf den gewonnen Erkenntnissen zu den Routingprotokollen aus Kapitel 2 und den vorhanden Implementierungen aus Kapitel 3.
4.1
Testabsichten
Das erstellte Konzept bildet die Grundlage zum Testen von Ad-hoc-Netzen und den
entsprechenden Implementierungen. In das Konzept der Testumgebung fließen neben
der allgemeinen Spezifikation und dem Aufbau von Ad-hoc-Netzen, den bereits gewonnenen Erkenntnissen zu den Routingverfahren (s. Kapitel 2) und vorhandenen
Implementierungen (s. Kapitel 3) auch die momentan verfügbaren Hardwarekomponenten mit ein. Die Testumgebung ist nicht speziell für ein Routingverfahren bzw. Implementierung konzipiert, sondern ist allgemeingültig und bildet somit die Grundlage
für Betrachtungen und Tests zu Ad-hoc-Netzen. Somit können verschiedene Szenarien
und Verfahren innerhalb dieser Testumgebung realisiert und die Funktionalität dieser Verfahren nachgewiesen werden. Ebenso ist die Testumgebung nicht speziell für
eine Plattform oder ein Endsystem konzipiert, sondern verschiedene Betriebssysteme
und Endgeräte können verwendet werden. Im Vordergrund der ersten Tests stehen
Aussagen zu den einzelnen Implementierungen in Hinblick auf:
• Funktionalität und Funktionsweise, d.h. z.B. Aussagen zur Routenbestimmung
KAPITEL 4. KONZEPTION DER TESTUMGEBUNG
61
und Robustheit des Netzes,
• Netzlast, die vom Routingprotokoll erzeugt wird,
• mittlere Übertragungsrate und
• Interoperabilität zwischen verschiedenen Betriebssystemen.
Die Funktionalität und Funktionsweise von Ad-hoc-Netzen kann am besten mit Hilfe
einer Testumgebung dargestellt werden, in der eine Mobilität der Knoten gewährleistet ist und somit das Netz von Veränderungen geprägt ist. Diese Aussage schränkt
aber nicht ein, dass verschiedene bzw. einzelne Knoten einen Anschluss in ein Festnetz
besitzen bzw. nicht mobil sind. Mit Hilfe der Dynamik kann die entsprechende Entstehung von Routen bzw. des Ad-hoc-Netzes sehr gut dargestellt werden. Neben der
Dynamik des Netzes sollten auch Aussagen zur mittleren Übertragungsrate und zur
erzeugten Netzlast, die allein durch das Routingverfahren entsteht, getroffen werden.
4.2
Verwendete Hardware- und Softwarekomponenten
In der Testumgebung ist die Integration von verschiedenen Hardware- und Softwarekomponenten möglich. Somit können die Netze entsprechend den Anforderungen gestaltet und erweitert werden. Die zu verwendende Hardware ist abhängig vom Testszenario und den System- bzw. Hardwareanforderungen, die durch die verwendeten Softwarekomponenten definiert sind. Die Vorraussetzung zur Teilnahme an einem Funknetzwerk ist eine WLAN-Karte. Diese kann sowohl extern als auch intern sein. Dabei ist
zu beachten, dass in Linux-Systemen verschiedene WLAN-Karten bzw. die Chipsätze
nicht unterstützt werden. Zur Konfiguration der WLAN-Karte sind die entsprechenden
Treiber und die Firmenware erforderlich. Neben Arbeitsplatz-PCs, die z.B. eine Verbindung zu einem Festnetz realisieren können, werden die mobilen Teilnehmer mit Hilfe
von Laptops und PDAs ( Personal Digital Assistants“) realisiert. Durch die Mobilität
”
dieser Geräte ist ein besonderes Augenmerk auf die entsprechende Energieversorgung
KAPITEL 4. KONZEPTION DER TESTUMGEBUNG
62
und die damit verbundenen Einschränkungen in Hinblick auf Lebensdauer zu richten,
denn verschiedene Routingverfahren überprüfen den Status der Energieversorgung und
erstellen dann ihre Routen entsprechend dieser Statusinformation.
Die Testumgebung ist für verschiedene Betriebssysteme und Routingsoftware konzipiert. Somit können verschiedene Testszenarien mit unterschiedlichen Betriebssystemen und die Interoperabilität zwischen den verschiedenen Betriebssystemen getestet werden. Die speziellen Anforderungen an die Betriebssysteme und die Software
sind in den System- und Softwareanforderungen der verwendeten Implementierungen
definiert. Entsprechende Modifikationen an den einzelnen Betriebssystemen könnten
erforderlich sein, d.h. beim MS Windows das Anpassen der Registry“ und beim Li”
nux OS das Anpassen des Kernels. Mit Hilfe von firmenspezifischer Software werden
die Konfigurationen der WLAN-Karten durchgeführt. Um Aussagen zum Netzwerkverkehr und dem Verkehr zu ermöglichen, sind Komponenten erforderlich, mit denen
die benötigten Verkehrswerte, wie beispielsweise ankommender und abgehender Verkehr, ermittelt werden können. Zur Erfassung der relevanten Verkehrswerte kommt
das Prinzip des Monitoring“ zum Einsatz. Die Monitoring-Tool“ werden in interne
”
”
(Softwaremonitore) und externe (Hardwaremonitore) Monitore unterteilt. Die internen Monitore können beliebige Informationen erfassen und es ist keine zusätzliche
Hardware erforderlich. Ein Nachteil dieser Monitore ist die zusätzliche Belastung des
Systems. Hingegen ermöglichen die externen Monitore die Überwachung selbst beim
Zusammenbruch des Systems und das System wird nicht zusätzlich belastet. Die Nachteile bestehen darin, dass nur Aussagen anhand von Beobachtungen möglich sind, es
besteht keine Möglichkeit der Überwachung innerer Zustände und auch zusätzliche
Hardware ist erforderlich. In dieser Testumgebung bietet sich die Verwendung interner Monitor (Softwaremonitore) an, denn diese erfordern keine zusätzliche Hardware,
können schnell in das vorhandene System integriert werden und ermöglichen einfache
Aussagen zu den Verkehrswerten. Dabei ist aber zu beachten, dass die internen Monitore das System zusätzlich belasten. Die Softwaremonitore müssen auf jedem Endgerät
installiert werden. Mit Hilfe des Monitors werden das entsprechende Interface“ und
”
die Übertragung überwacht, die aktuelle Datenübertragungsrate wird dargestellt und
die übertragene Datenmenge ( Traffic“) wird gespeichert. Neben den Softwarekom”
KAPITEL 4. KONZEPTION DER TESTUMGEBUNG
63
ponenten zur Datenerfassung wird Software eingesetzt, mit der einfacher IP-Verkehr
erzeugt werden kann. Um einen einfachen Datenverkehr zu ermöglichen sollten Secure
”
Shell“ (SSH) oder File Transfer Protocol“ (FTP) auf den entsprechenden Endgeräten
”
installiert werden.
4.3
Testaufbau
Der Testaufbau bzw. die Testumgebung sollte der Spezifikation von Ad-hoc-Netzen
gerecht werden, d.h. es existiert keine feste Basisstation und Infrastruktur. Alle Teilnehmer sind mobil und fungieren sowohl als Endstation als auch als Router. Dabei wird
aber nicht ausgeschlossen, dass verschiedene Teilnehmer nicht mobil sondern fest sind.
Die gesamte dynamische Netzstruktur entsteht durch Selbstorganisation und Selbstverwaltung der Knoten bzw. der Teilnehmer. Wesentliche Bestandteile der Testumgebung sind sowohl mobile als auch feste Endgeräte mit unterschiedlichen Betriebssystemen und einer entsprechenden WLAN-Karte. Dabei werden Arbeitsplatz-PCs
als feste Endgeräte genutzt und mit Hilfe von Laptops bzw. PDAs werden die mobilen Endgeräte realisiert. Der Testaufbau wird wesentlich durch den Testfall bzw. das
Testszenario bestimmt. Zur Bestimmung der maximalen Übertragungsrate müssen die
Teilnehmer nicht mobil sein, dagegen sollte bei Messungen zum Routingverfahren und
zu Veränderungen der Topologie eine Veränderung des Testnetzes, d.h. der Position
der mobilen Teilnehmer, erfolgen. Bei Messungen zur mittleren Übertragungsrate sind
die erreichbaren Werte an einer entsprechenden Position von Interesse und somit ist
die Dynamik des Netzes nicht unbedingt erforderlich. Dagegen sollte ein Testnetz, mit
dem das Verhalten eines Routingalgorithmus gezeigt und bewiesen werden soll, von
einer Dynamik geprägt sein, d.h. entsprechende Veränderungen der mobilen Knoten
müssen gewährleistet sein und zwar so, dass neue Routen entstehen und somit der
IP-Verkehr neu geroutet werden muss. Der Testaufbau sollte wesentliche Phasen beinhalten, mit denen die Funktionsweise der Routingprotokolle getestet werden kann. In
den Abbildungen 4.1, 4.2 und 4.3 sind drei Phasen dargestellt.
In der Abbildung 4.1 ist die 1. Phase dargestellt. Diese ist dadurch beschrieben, dass
sich jeder Knoten in der Funkreichweite der beiden anderen Knoten befindet und somit
KAPITEL 4. KONZEPTION DER TESTUMGEBUNG
64
Knoten 1
Knoten 2
Knoten 3
Funkbereich Knoten 1
Funkbereich Knoten 2
Funkbereich Knoten 3
Abbildung 4.1: Allgemeiner Testaufbau - 1. Phase
sind diese seine direkten Nachbarn.
Funkbereich Knoten 1
Funkbereich Knoten 2
Funkbereich Knoten 3
Knoten 1
Knoten 3
Knoten 2
Abbildung 4.2: Allgemeiner Testaufbau - 2. Phase
In der 2. Phase (s. Abbildung 4.2) kommt es zur Veränderung der Topologie. Ein
Knoten, in diesem Fall Knoten 2, verlässt die Funkreichweite vom Knoten 1 bzw. wird
KAPITEL 4. KONZEPTION DER TESTUMGEBUNG
65
die Link“-Qualität so schlecht, sodass er als direkten Nachbarn nur noch den Knoten 3
”
besitzt. Dieser befindet sich aber noch in Funkreichweite vom Knoten 1. Somit können
Daten vom Knoten 1 zum Knoten 2 über den Knoten 3 weitergeleitet werden.
Knoten 2
Knoten 1
Position zum Zeitpunkt t = 0
Knoten 3
Knoten 2
Position zum Zeitpunkt t = 1
Knoten 2
gu
we
e
B
n
om
gv
Kn
n
ote
2
Funkbereich Knoten 1
Position zum Zeitpunkt t = 2
Funkbereich Knoten 2
Funkbereich Knoten 3
Abbildung 4.3: Allgemeiner Testaufbau - 3. Phase
Die Abbildung 4.3 verdeutlicht die 3. Phase. Diese beschreibt die Bewegung eines
Knotens und das Hinzukommen zum Ad-hoc-Netz. Zum Zeitpunkt t = 0 befindet sich
der Knoten 2 noch außerhalb der Funkreichweite eines Knotens, der am Ad-hoc-Netz
teilnimmt. Der Knoten 2 bewegt sich und zum Zeitpunkt t = 1 befindet sich der Knoten
in der Funkreichweite vom Knoten 3. Somit ist der Knoten 2 ein neuer Teilnehmer im
Ad-hoc-Netz. Zum Zeitpunkt t = 2 hat sich der Knoten wieder aus der Funkreichweite
vom Knoten 3 entfernt und somit das Ad-hoc-Netz verlassen.
Diese drei Phasen können in beliebiger Form in die Testumgebung eingebracht und
entsprechend erweitert werden.
KAPITEL 4. KONZEPTION DER TESTUMGEBUNG
4.4
66
Festlegen der Testpunkte und Definition der
Ziele
4.4.1
Messungen zur erzeugten Netzlast
Ziel dieses Tests ist die Ermittlung der erzeugten Netzlast, die durch das Routing
entsteht. Somit können Aussagen über die Belastung des Netzes getroffen werden, die
ausschließlich vom Routing stammen.
4.4.2
Messungen bei Veränderung der Topologie
Die Ermittlung der Übertragungsrate und Aussagen zum Netzverhalten bei Veränderung der Netztopologie sind die Ziele dieser Messungen. Somit können Aussagen über
das Verhalten der Übertragungsrate und dem Ad-hoc-Netz getroffen werden, wenn sich
die Knoten innerhalb des Netzes bewegen bzw. wenn sich die Topologie verändert.
4.4.3
Messungen zur mittleren Übertragungsrate
Ziel dieses Tests ist die Ermittlung der mittleren Übertragungsrate, welche mit dem
Routingverfahren bzw. der Routingsoftware möglich ist. Dieses Testszenario ermöglicht
Aussagen über die Datenmenge, die übertragbar ist in Hinblick auf Abstand der Knoten und der Netztopologie.
4.4.4
Messungen mit unterschiedlichen Betriebssystemen
Diese Messsung liefert Aussagen zur Interoperabilität der Routingverfahren bzw. Routingsoftware bei Verwendung unterschiedlicher Betriebssysteme. Somit sind Aussagen
zum Verhalten des Ad-hoc-Netzes möglich, wenn die Knoten unterschiedliche Betriebssysteme verwenden. Ebenso können Aussagen zum Verhalten der Betriebssysteme in
Hinblick auf Prozessorlast und Ressourcenverbrauch getroffen werden.
KAPITEL 4. KONZEPTION DER TESTUMGEBUNG
4.4.5
67
Messungen mit unterschiedlichen Routingparametern
Bei dieser Messung werden die Routingparamter verändert und das Ziel sind Aussagen zum Verhalten der Routingverfahren bzw. Routingsoftware bei Veränderung der
Parameter. Somit können Aussagen über das Verhalten des Ad-hoc-Netzes getroffen
werden, wenn die definierten Routingparameter bzw. die von der IETF ( Internet En”
gineering Task Force“) empfohlenen Routingparameter verändert werden.
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
68
Kapitel 5
Realisierung einer Testumgebung
In diesem Kapitel wird mit Hilfe der ausgewählten Implementierungen aus Kapitel 3
und dem Konzept aus Kapitel 4 eine entsprechende Testumgebung realisiert.
5.1
Verwendete Hardware- und Softwarekomponenten
Die momentane Testumgebung wird wesentlich durch die verfügbaren Hardwarekomponenten und die vorhandenen Implementierungen bestimmt.
Wesentliche Bestandteile der Testumgebung sind sowohl mobile als auch feste Endgeräte mit unterschiedlichen Betriebssystemen, d.h. Linux OS und MS Windows, und
einer entsprechenden WLAN-Karte, RoamAbout 802.11 DS (Cabletron)“. In der rea”
lisierten Testumgebung dient der Arbeitsplatz-PC-1 als festes Endgerät und mit Hilfe
von Laptops, d.h. Laptop-1, Laptop-2 und Laptop-3, werden die mobilen Endgeräte
realisiert. Die Spezifikation der verwendeten Geräte und der Hardwarekomponenten
sind im Anhang B.1 zu finden.
5.1.1
Konfiguration der WLAN-Karte
Wie bereits erläutert, wird bei allen Geräten als WLAN-Karte die RoamAbout 802.11
”
DS (Cabletron)“, ohne Verschlüsselung, verwendet.
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
69
Unter Linux OS muss kein spezieller Treiber installiert werden. Die Karte wird ohne
Probleme erkannt und kann entsprechend konfiguriert werden. Unter MS Windows
werden die entsprechenden Treiber und der Client-Manager“ installiert. Mit Hilfe des
”
Client-Managers“ kann das entsprechende Interface“ einfach konfiguriert und ein
”
”
Profil“ angelegt werden. Im Anhang B.1.2 sind nähere Angaben zur Installation und
”
Konfiguration der WLAN-Karte zu finden.
5.1.2
Verwendete Implementierungen
Anhand der Angaben aus Kapitel 3 werden entsprechende Implementierungen der Routingprotokolle ausgewählt und in die momentane Testumgebung eingebunden. Neben
der Funktionsfähigkeit der Implementierungen wird die Auswahl auch von den verwendeten Hardwarekomponenten und den Betriebssystemen beeinflusst. Da die momentane Testumgebung nur aus zwei Linux-Systemen besteht, werden vorrangig Implementierungen für MS Windows verwendet. Die Linux-Systeme werden aber für die
Tests mit unterschiedlichen Betriebssystemen benötigt.
Verwendete AODV-Implementierungen
Für MS Windows existieren momentan nur zwei funktionsfähige Implementierungen
von AODV, UoB JAdhoc“ [44] und Windows AODV“ [46]. Dagegen ist die Anzahl
”
”
der funktionsfähigen Implementierungen für Linux OS größer. Unter Linux OS bietet
sich die Verwendung von AODV-UU“ [7] an. Diese Implementierung zeichnet sich
”
durch eine ständige Weiterentwicklung aus und bildet die Grundlage für einige weiter
Implementierungen.
Die University of Bremen“ (UoB) entwickelte das auf Java basierende UoB JAdhoc“.
”
”
Laut Aussagen der Entwickler muss auf jedem Knoten, der sich am Ad-hoc-Netz
beteiligt, ein eigenes Subnetz“ definiert werden. Dies ist aber nicht im Sinne von
”
Ad-hoc-Netzen, denn die Konfiguration dieser erfordert zusätzliche Berechnungen
von IPv4-Adressen für jedes Gerät. Diese Art der IP-Adressen-Konfiguration ist im
Vergleich zu den anderen Implementierungen einzigartig. Normalerweise befinden sich
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
70
alle Knoten innerhalb eines Netzes, d.h. sie besitzen die gleiche Netzwerk-Adresse, die
gleiche Subnetzmaske“ und den gleichen Broadcast“. Die Host“-Adressen liegen
”
”
”
innerhalb eines entsprechenden Adressenbereiches. Ebenfalls führt diese Software zu
Problemen, besonders der Passthru Driver“, der als Service für das entsprechende
”
WLAN-“Interface“ zusätzlich installiert wird. Es kommt zu totalen Systemausfällen
und bei den Tests fällt auf, dass die Datenübertragungsrate der WLAN-Karten
verändert wird und somit weniger Übertragungsrate zur Verfügung steht.
UoB
”
JAdhoc“ ist zwar funktionsfähig, aber nach den ersten Tests wird deutlich, dass
verschiedene Probleme auftreten und die Verwendung daher nicht empfohlen wird.
Dagegen zeichnet sich Windows AODV“ durch einfache Benutzung und gute Darstel”
lung des verwendeten Ad-hoc-Netzes aus. In der Abbildung 5.1 wird die graphische
Oberfläche veranschaulicht.
Abbildung 5.1: Windows AODV“ - Oberfläche
”
Innerhalb dieser Oberfläche werden die benötigten und vorhandenen Parameter angezeigt. Einen Überblick, über die momentanen Routen und die Routenparameter liefert
die AODV Route Table“ (s. Abbildung 5.2).
”
In der Implementierung sind zwei Komponenten enthalten, die zur Gewährleistung der
Funktionsfähigkeit erforderlich sind:
• User-Space-Application“ (winaodv.exe) und
”
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
71
Abbildung 5.2: Windows AODV“ - AODV Route Table“
”
”
• NDIS Intermediate Driver“ (AODV Routing).
”
Zusätzlich besteht die Möglichkeit, Windows AODV“ in Verbindung mit pudl“ zu
”
”
verwenden. pudl“ ist eine Hilfsanwendung, die zur Filterung von Wireless-Links“
”
”
benutzt werden kann, so dass nur Links“ mit hoher Qualität für die Routen verwen”
det werden. Die Benutzung von pudl“ ist für die AODV-Operation nicht erforderlich.
”
Wichtig ist, dass bei der Verwendung von pudl“ alle anderen Knoten ebenfalls Win”
”
dows AODV“ und pudl“ benutzen. Die Parameter von AODV können nicht verändert
”
werden und somit können auch diesbezüglich keine Aussagen zum Verhalten getroffen
werden. Laut Angaben der Entwickler ist diese Implementierung nach einer Anpassung
interoperabel mit anderen AODV-Implementierungen. Leider kann diese Aussage momentan nicht bestätigt werden, denn nach Tests mit Linux-OS-Implementierungen,
wie beispielsweise AODV-UU“, ist eine Interoperabilität nicht gewährleistet. Somit
”
beschränken sich die momentanen Tests nur auf MS Windows. Näher Hinweise zur
Installation von Windows AODV“ sind im Anhang B.2.2 zu finden. Zum Testen der
”
Interoperabilität wird auf den Linux-Systemen AODV-UU“ verwendet. Diese Imple”
mentierung basiert auf IPv4 und arbeitet als User-Space-Daemon“. Zur Erfassung
”
der erforderlichen Daten werden Netfilter“ verwendet. Diese Implementierung kann
”
im ns2 [29] zur Simulation von Ad-hoc-Netzen verwendet werden. Näher Hinweise zur
Installation von AODV-UU“ sind im Anhang B.2.1 zu finden.
”
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
72
Verwendeten OLSR-Implementierungen
Als OLSR-Implementierung wird OLSRD“ verwendet. Der große Vorteil dieser Im”
plementierung besteht darin, dass diese sowohl für MS Windows als auch für Linux
OS existiert. OLSRD“ ist dadurch gekennzeichnet, dass eine fortschreitende Entwick”
lung erfolgt und dem Anwender neue Versionen zur Verfügung gestellt werden. Die
graphische Oberfläche teilt sich in vier Bereiche ein:
1. Settings“ (s. Abbildung 5.3):
”
Abbildung 5.3: OLSRD“ - Settings“
”
”
Es können die entsprechenden Einstellungen vorgenommen werden oder eine
Konfigurationsdatei kann geladen bzw. auch erstellt werden. Die Option Offen
”
Internet Connection“ kann aktiviert werden, wenn der entsprechende Knoten
einen Zugang zum Internet besitzt. Bei der Aktivierung wird ein Host and Net”
work Association“ (HNA)-Zugang für die Defaultroute“ zur Konfigurationsdatei
”
hinzugefügt und andere Knoten im OLSR-Netzwerk können diesen Internetzugang benutzen. IPv6 ist vorgesehen, kann aber momentan unter MS Windows
nicht verwendet werden. Enable ETX link quality“ ermöglicht die Ermittlung
”
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
73
der Link-Quality“ der Nachbarn unter Verwendung der Expected Transmis”
”
sion Count“ (ETX)-Metrik. Die Windows Size“ gibt die Anzahl, der kürzlich
”
erhaltenen Pakete an, die zur Berechnung des Paketverlustes verwendet werden.
Wenn z.B. dieser Parameter zu 10 gewählt wird, wird OLSR den Paketverlust
unter den letzten 10 von jedem Nachbarn erhaltenen Paketen berechnen. Ist For
”
MPR selection only“ aktiviert, wird die Link Quality“ nur verwendet, um den
”
MPR auszuwählen, der die beste Route zu dem Two-Hop“-Nachbarn anbietet.
”
Ist dagegen For MPR selection and routing“ aktiviert, wird die Link Quality“
”
”
zusätzlich benutzt, um die Routingtabelle zu erstellen. Die Aktivierung von ETX
entspricht nicht dem OLSR Standard.
2. Output“:
”
Unter Output“ werden der laufende Prozess und das Routing dargestellt. Die
”
erzeugte Ausgabe ist aber auf 1000 Zeilen begrenzt und kann in einer entsprechenden Datei abgespeichert werden.
3. Nodes“ (s. Abbildung 5.4):
”
Abbildung 5.4: OLSRD“ - Nodes“
”
”
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
74
Dargestellt werden die Informationen zu den Knoten, die sich momentan im Adhoc-Netz befinden. Zusätzlich werden zu jedem Knoten die Informationen zu
MPR, Multiple Interface Declaration“ (MID) und HNA bereitgestellt.
”
4. Routes“ (s. Abbildung 5.5):
”
Abbildung 5.5: OLSRD“ - Routes“
”
”
Die momentan verfügbaren Routen, mit den wichtigsten Parametern, wie beispielsweise das Gateway“ und die Routingmetrik, werden dargestellt. Diese Pa”
rameter werden bei Veränderung der Route angepasst.
Es muss keine zusätzliche Software installiert werden. Lediglich die Konfiguration des
Interfaces“ ist erforderlich. Tests zur Interoperabilität sind möglich, denn sowohl un”
ter Linux OS als auch unter MS Windows kann diese Implementierung angewendet
werden. Um ein korrektes Routing zu gewährleisten, sollte auf allen Geräten die gleiche Konfiguration der Routingparameter verwendet werden. Das Config-File“ kann
”
mit den entsprechenden Einstellungen erstellt und verwendet werden. Näher Hinweise
zur Installation und Konfiguration sind im Anhang B.2.3 zu finden.
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
5.1.3
75
Verwendete Tools für Monitoring“ und zur Erfassung
”
des Network-Traffic“
”
Zur Erfassung des Network-Traffic“ werden für die verschiedenen Betriebssysteme,
”
d.h. Linux OS und MS Windows, drei verschiedene Tools verwendet:
• Linux OS:
– IPTraf“
”
• MS Windows:
– Analyzer“
”
– Network Traffic Monitor“
”
Analyzer“
”
Der Analyzer“ [2] ist ein Netzwerkanalysetool für MS Windows und basiert auf
”
WinPcap“ [47]. Die Spezifikation und die Daten des Tools sind in der Tabelle 5.1
”
abgebildet. Dieses Tool bietet zahlreiche Funktionen für das Management von NetzEntwickler:
Quelle:
Politecnico di Torino“
”
http://analyzer.polito.it/
Betriebssystem:
MS Windows
Aktuelle Version:
Programmiersprache:
Analyzer 3.0 (alpha)“
”
Delphi
Systemanforderungen:
MS Windows
Softwareanforderungen:
WinPcap“ [47]
”
Tabelle 5.1: Analyzer“ - Spezifikation
”
werken. Die erhalten Daten und Werte können zur weiteren Bearbeitung abgespeichert
werden.
In der Abbildung 5.6 ist das Hauptmenü abgebildet. In der Testumgebung wird der
Analyzer“ zur Untersuchung der empfangenen Datenpakete verwendet. Dazu wird die
”
Option Capture“ benutzt.
”
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
76
Abbildung 5.6: Analyzer“ - Hauptmenü
”
Abbildung 5.7: Analyzer“ - Capture“
”
”
In der Abbildung 5.7 ist der Empfang eines NetBIOS“ ( Network Basic Input Output
”
”
System“)-Paketes dargestellt. Zu jedem empfangen Paket werden detaillierte Informationen, wie beispielsweise der Link“, das Netzwerk und das Transportprotokoll, bereit
”
gestellt.
Network Traffic Monitor“
”
Der Network Traffic Monitor“ [30] ist ein frei verfügbares Tool zur Netzwerkanalyse.
”
Die Spezifikation dieses Tools ist in der Tabelle 5.2 abgebildet und in der Abbildung 5.8
ist die graphische Oberfläche dargestellt.
Das Hauptziel dieser Anwendung ist die Kontrolle und das Erfassen des IP-Verkehrs.
Dieser Netzwerkmonitor stellt Real-Time-Traffic-Accounting“ und Monitoring“ zur
”
”
Verfügung. Er ist sehr dynamisch, d.h. jede neue Verbindung wird registriert und kontrolliert.
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
Entwickler:
Dirk Claessens; Zarko Gajic
Quelle:
http://delphi.about.com/od/
77
fullcodeprojects/l/aa112903a.htm
Betriebssystem:
MS Windows
Aktuelle Version:
Programmiersprache:
Delphi
Systemanforderungen:
MS Windows
Softwareanforderungen:
Tabelle 5.2: Network Traffic Monitor“ - Spezifikation
”
Abbildung 5.8: Network Traffic Monitor“ - Oberfläche
”
Die Implementierung sieht aber kein Log-File“ vor, in das die gemessenen Werte ab”
gespeichert werden.
Im Rahmen dieser Arbeit wurden entsprechende Anpassungen am Source-Code“ vor”
genommen. Nach den Anpassungen ist es nun möglich, jede Sekunde die Daten zum
ankommenden und abgehenden Verkehr des ausgewählten Interfaces“ in eine entspre”
chende Datei abzuspeichern. Die Datei und die Start- bzw. Stoppzeit dieses Logging“”
Vorganges sind vom Anwender frei wählbar. In der Abbildung 5.9 ist die angepasst
und ergänzte Bedienungsoberfläche dargestellt. Die vorgenommenen Veränderungen
am Source-Code“ sind im Anhang C.2 dargestellt.
”
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
78
Abbildung 5.9: Veränderter Network Traffic Monitor“ - Angepasste Oberfläche
”
IPTraf“
”
Zum Erfassen des Netzwerkverkehrs unter Linux OS wird das Tool IPTraf“ [21] ver”
wendet. Die Angaben zur Software sind in der Tabelle 5.3 dargestellt.
Entwickler:
Gerard Paul Java
Quelle:
http://iptraf.seul.org/
Betriebssystem:
Linux OS
Aktuelle Version:
IPTraf 2.7.0“ (2002-05-19)
”
C/C++
Programmiersprache:
Systemanforderungen:
Linux Kernel 2.2.x;
8 MB Physical-RAM“;
”
min. 16 MB Virtual-RAM“
”
Softwareanforderungen:
Tabelle 5.3: IPTraf“ - Spezifikation
”
IPTraf“ ist ein konsolenbasiertes Netzwerkstatistiktool. Es können eine Vielzahl von
”
Daten und Werten gesammelt werden, wie beispielsweise TCP-Verbindungspakete und
Byte-Zähler sowie Interface“-Statistik und Aktivitätsanzeige (s. Abbildung 5.10).
”
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
79
Abbildung 5.10: IPTraf“ - Menü
”
Ein wesentlicher Bestandteil, der auch bei den hier durchgeführten Messungen Anwendung findet, ist der TCP und UDP Service Monitor“, der vom entsprechenden
”
Interface“ den ankommenden und abgehenden Verkehr anzeigt (s. Abbildung 5.11).
”
Abbildung 5.11: IPTraf“ - TCP und UDP Service Monitor“
”
”
In IPTraf“ ist die Option eines Log-Files“ vorhanden, wo aber die entsprechenden
”
”
Daten nur in einem Zeitintervall von minimal einer Minute aufgezeichnet werden.
Aus der Tatsache heraus, dass sich das Ad-hoc-Netz, bedingt durch die Bewegungen
und Mobilität, innerhalb von Sekunden verändert, ist dieses Log-File“ für die Ermitt”
lung dieser Art von Daten nicht geeignet.
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
80
Deshalb wurden im Rahmen dieser Arbeit Veränderungen am Source-Code“ vorge”
nommen. Die Veränderungen beziehen sich aber nur auf den TCP und UDP Service
”
Monitor“. Dieser wurde erweitert und die Daten zum ankommenden und abgehenden Verkehr des Interfaces“ werden nun jede Sekunde in eine entsprechende Datei
”
abgespeichert. Im Anhang C.1 sind die vorgenommenen Veränderungen dargestellt.
5.1.4
Verwendete Tools und Software zur Erzeugung von
Netzwerkverkehr ( Network Traffic“)
”
iperf“
”
iPerf“ [20] ist ein Softwaretool zur Analyse der Netzwerk-“Performance“. iPerf“ wur”
”
de als eine moderne Alternative entwickelt, um die Bitrate bei Verwendung von TCP
und UDP zu messen. Die Spezifikation und Angaben zur Software sind in der Tabelle 5.4 zu finden.
Entwickler:
The Board of Trustees of the University of
”
Illinois“
Quelle:
http://dast.nlanr.net/Projects/Iperf/
Betriebssystem:
Linux OS;
MS Windows
Aktuelle Version:
iPerf-1.7.0“ (2003-03)
”
Programmiersprache:
Systemanforderungen:
Softwareanforderungen:
Tabelle 5.4: iPerf“ - Spezifikation
”
Die Entscheidung für iPerf“ fiel aufgrund der Eigenschaften und der Einsatzmöglich”
keiten. Sowohl MS Windows als auch Linux OS werden unterstützt. Die Funktionsweise
von iPerf“ ist sehr einfach. iPerf“ arbeitet nach dem bekannten Client-Server-Modell.
”
”
Der Client erzeugt Netzwerkverkehr in Richtung des Servers, welcher lediglich Empfangsinformationen zurücksendet. Zuvor muss iPerf“ auf dem empfangenden Rechner
”
als Serverdienst gestartet werden. Die angebotenen Funktionen werden über Kommandozeile aufgerufen. Nähere Angaben zum Aufruf und den Parametern sind im
Anhang B.2.4 zu finden.
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
81
Die in den Messungen verwendeten Parameter sind:
• TCP Transportprotokoll,
• Zuweisung der Server-/Client-Rolle,
• Überwachungsintervall im Log“ (Bildschirm/Datei),
”
• Ziel-IP und
• Dauer des erzeugten Traffics“.
”
File Transfer Protocol“
”
Das File Transfer Protocol“ (FTP) ist in der RFC 959 [IETF, 1985] spezifiziert und
”
wird zur Dateiübertragung über TCP/IP-Netzwerke verwendet. Es wird benutzt, um
Dateien vom Server zum Client ( Download“), vom Client zum Server ( Upload“) oder
”
”
clientgesteuert zwischen zwei Servern zu übertragen. Auf dem Rechner, der als Server agieren soll, muss entsprechend ein FTP-Server installiert und konfiguriert werden.
Über die Kommandozeile kann der Client auf den Server zugreifen und ein entsprechender Datentransfer kann stattfinden. Eine Zusammenstellung, der wichtigsten Befehle
ist im Anhang B.2.5 zu finden.
5.2
Testaufbau
Der Testaufbau bzw. die Testumgebung wird der Spezifikation von Ad-hoc-Netzen gerecht, d.h. es existiert keine feste Basisstation und Infrastruktur. Die gesamte dynamische Netzstruktur entsteht durch Selbstorganisation und Selbstverwaltung der Knoten
bzw. der Teilnehmer. Die Testumgebung und der Testaufbau werden neben dem Testfall bzw. Testszenario wesentlich durch den Arbeitsplatz-PC-1 bestimmt, denn dieser
kann seine Position nicht verändern und somit ist die Reichweite dieses Knotens räumlich begrenzt. Der Arbeitsplatz-PC-1 befindet sich im 1. Obergeschoss des Helmholtzbaus der TU-Ilmenau, genauer im Raum 2519. Somit beschränkt sich die momentane
Testumgebung auf den Helmholtzbau und die nähere Umgebung dieses Gebäudes. Der
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
82
verwendete Laptop-2 besitzt ebenfalls eine feste Position, denn die Laufzeit des Akkus ist zu gering, um eine Mobilität des Knotens zu gewährleisten. Somit wird dieser
Knoten innerhalb des Helmholzbaus so platziert, dass sich dieser in der Funkreichweite
vom Arbeitsplatz-PC-1 befindet. Der Laptop-1 wird als mobiles Gerät und somit als
mobiler Knoten verwendet, was bei einer Veränderung seiner Position zur Veränderung
des Netzes führen kann. Um eine später Auswertung der durchgeführten Messungen
zu ermöglichen und die verschiedenen Implementierungen vergleichen zu können, werden bestimmte Messpunkte (MPs) definiert, die sich an entsprechenden Positionen im
Helmholzbau befinden (s. Abbildungen 5.12 und 5.13).
MP 4
Helmholtzbau
1.Obergeschoss
MP 1
MP 3
Laptop-2
(10.0.0.2)
bzw.
Laptop-3
(10.0.0.4)
MP 6
Arbeitsplatz-PC-1
(10.0.0.3)
MP 2
MP 5
MP 7
Abbildung 5.12: 1.OG Helmholzbau mit Messpunkten
Die in der Abbildung 5.12 farblich hervorgehobenen Messpunkte werden zur Erfassung
der erzeugten Netzlast verwendet.
Die entsprechenden IP-Adressen der Teilnehmer werden in dieser momentanen Testumgebung vom Anwender konfiguriert. Das hier verwendete Netz ist ein /24“ (ent”
spricht Klasse C Netz), d.h. 28 − 2 = 254 Host“-Adressen können verwaltet werden.
”
Das verwendete Netzwerk hat die Netzwerk-Adresse 10.0.0.0/24, die Subnetzmaske“
”
255.255.255.0/24 und den Broadcast“ 10.0.0.255. Die entsprechenden IPv4-Adressen
”
der verwendeten Geräte sind in der Tabelle 5.5 dargestellt.
Die Implementierungen unterstützen den Zugang zu einem Festnetz, wie beispielsweise
dem Internet. Zusätzlich müssen entsprechende Einstellungen vorgenommen werden,
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
83
Helmholtzbau
2.Obergeschoss
MP 8
MP 9
MP 7
Abbildung 5.13: 2.OG Helmholzbau mit Messpunkten
Gerät
Host“”
Adresse
Subnetz”
maske“
Broadcast“
”
Adresse
Netzwerk-
Laptop-1
10.0.0.0/24
10.0.0.1/24
255.255.255.255.0/24
10.0.0.255/24
Laptop-2
10.0.0.0/24
10.0.0.2/24
255.255.255.255.0/24
10.0.0.255/24
Laptop-3
10.0.0.0/24
10.0.0.4/24
255.255.255.255.0/24
10.0.0.255/24
Arbeitsplatz-PC-1
10.0.0.0/24
10.0.0.3/24
255.255.255.255.0/24
10.0.0.255/24
Tabelle 5.5: IPv4-Adressen der verwendeten Geräte
die im Anhang B.1.2 beschrieben sind. Dabei müssen aber alle Sicherheitseinstellungen, wie beispielsweise die Firewall“, deaktiviert werden, was ein relativ hohes Sicher”
heitsrisiko darstellt. Zusätzlich wird ein DNS ( Domain Name System“)-Server für die
”
IP-Konfiguration der WLAN-Karte benötigt. Dazu kann beispielsweise der DNS-Server
der TU-Ilmenau, mit den IP-Adressen 142.24.12.2 und 142.24.4.1, verwendet werden.In
der momentanen Testumgebung wird ausschließlich IPv4 verwendet. Für das Testnetz
wird das in der Tabelle 5.6 dargestellte Profil“ für die WLAN-Karte verwendet.
”
5.3
Testdurchführung
Die Messungen erfolgen nach einem entsprechenden Zeitplan und zwei unterschiedlichen Testplänen, die von dem jeweiligen Testszenario abhängig sind.
Der in der Abbildung 5.14 dargestellte Testplan dient zur Erfassung des Netzver-
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
ESSID:
test-net
Mode:
ad-hoc/peer-to-peer
Kanal:
2
Netzwerk-Adresse:
10.0.0.0/24
Host“-Adressen:
”
Subnetzmaske“:
”
Broadcast“:
”
10.0.0.1-10.0.0.254/24
84
255.255.255.255.0/24
10.0.0.255/24
Tabelle 5.6: WLAN-Einstellungen des Testnetzes
haltens bei Veränderung der Netztopologie und der Parameter. Dieser Testplan
beinhaltet die wesentlichen Schritte zur Erfassung der benötigten Daten bei der
Bewegung des mobilen Knotens und Veränderung der Parameter.
MP5
4
MP1
1
MP2
2
MP6
7
3
5
MP3
6
MP5
8
MP7
13
14
9
12
MP8
10
MP9
11
Messpunkt
Bewegung
Kantennummer
für Bewegung
Messzeit
am MP
Zeitintervall für die
Bewegung zwischen MPs
MP1
MP1 à MP2
1
60 s
1..7 s
MP2
MP2 à MP3
2
60 s
1..7 s
MP3
MP3 à MP4
3
60 s
1..16 s
MP4
MP4 à MP1
4
60 s
1..18 s
MP3
MP3 à MP5
5
60 s
1..12 s
MP5
MP5 à MP6
6
60 s
1..15 s
MP6
MP6 à MP5
7
60 s
1..11 s
MP5
MP5 à MP7
8
60 s
1..9 s
MP7
MP7 à MP8
9
60 s
1..5 s
MP8
MP8 à MP9
10
60 s
1..10 s
MP9
MP9 à MP8
11
60 s
1..10 s
MP8
MP8 à MP7
12
60 s
1..10 s
MP7
MP7 à MP5
13
60 s
1..10 s
MP5
MP5 à MP1
14
60 s
1..15 s
MP1
60 s
Abbildung 5.14: Testaufbau - Allgemeiner Testplan
Wie bereits erläutert, werden zur Erfassung der erzeugten Netzlast, die vom eigentlichen Routingprotokoll stammt, wesentlich weniger Messpunkte verwendet, die aber
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
85
trotzdem Aussagen ermöglichen. Deshalb existiert speziell für diese Untersuchungen
der zweite Testplan, der in der Abbildung 5.15 dargestellt ist.
MP1
1
MP2
2
MP5
5
3
MP6
4
Messpunkt
Bewegung
Kantennummer
für Bewegung
Messzeit
am MP
Zeitintervall für die
Bewegung zwischen MPs
MP1
MP1 à MP2
1
60 s
1..7 s
MP2
MP2 à MP5
2
60 s
1..7 s
MP5
MP5 à MP6
3
60 s
1..15 s
MP6
MP6 à MP5
4
60 s
1..11 s
MP5
MP5 à MP1
5
60 s
1..15 s
6
60 s
MP1
Abbildung 5.15: Testaufbau - Testplan zur Erfassung der Netzlast
In den beiden Abbildungen 5.14 und 5.15 sind die verwendeten Messpunkte und die
Bewegungen, die mit Hilfe der Kanten verdeutlicht werden, abgebildet. Die Reihenfolge der Bewegungen wird mit Hilfe der Nummerierung deutlich. In den Tabellen sind
die Zeitintervalle für Messung und Bewegung definiert. Das Zeitintervall an dem Messpunkt ermöglicht die Ermittlung der Messdaten über einen relativ großen Zeitraum.
Bedingt durch die Mobilität kommt es zum kurzzeitigen Abbruch der Verbindungen
und eine gewisse Zeit wird benötigt, bis diese wieder stabil sind. Die Veränderungen
der Topologie und das Erstellen neuer Routen können innerhalb dieser Messzeit sehr
gut dargestellt werden.
Die Bewegungsintervalle definieren die Zeitdauer für die Bewegung zwischen den Messpunkten. Dabei wird versucht, mit gleich bleibender Geschwindigkeit die Messpunkte
zu erreichen. Beim Einhalten der oberen Grenze bewegt sich der Knoten mit einer
Geschwindigkeit von ca. 3 km/h. Die geringe Geschwindigkeit ist dadurch begründet,
dass die Laptops relativ groß bzw. unhandlich sind und bei höheren Geschwindigkeiten
Beschädigungen auftreten könnten, so z.B. am Display. An dieser Stelle würden sich
PDAs anbieten, die im Vergleich zu Laptops kleiner und handlicher sind, doch leider
konnten zum Zeitpunkt der ersten Tests keine PDAs in die Testumgebung eingebracht
und somit getestet werden. Durch die Festlegungen der entsprechenden Zeitintervalle
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
86
werden weiterführende Betrachtungen vereinfacht und einfache Vergleiche der unterschiedlichen Messungen werden ermöglicht.
Die Monitoring-Tools“ und die Routingsoftware werden auf den Geräten nacheinan”
der gestartet. Das Starten der Routingsoftware auf den Geräten in einem zeitlichen
Abstand ermöglicht Aussagen zum Verhalten des Netzes, wenn neue Knoten hinzukommen und sich somit die Anzahl der Teilnehmer erhöht.
5.3.1
Verwendete Hardware- und Softwarekomponenten für
die Messungen
Die verwendeten Hardware- und Softwarekomponenten für die Messungen zu AODV
und OLSR unterscheiden sich nur geringfügig.
ArbeitsplatzPC-1
Laptop-1
Laptop-3
IP-Verkehr
IP-Adresse: 10.0.0.1/24
Netzwerk-Adresse: 10.0.0.0/24
„Broadcast“: 10.0.0.255/24
„Subnetzmaske“: 255.255.255.0/24
IP-Adresse: 10.0.0.3/24
Netzwerk-Adresse: 10.0.0.0/24
„Broadcast“: 10.0.0.255/24
„Subnetzmaske“: 255.255.255.0/24
IP-Adresse: 10.0.0.4/24
Netzwerk-Adresse: 10.0.0.0/24
„Broadcast“: 10.0.0.255/24
„Subnetzmaske“: 255.255.255.0/24
Betriebssystem: MS Windows XP
„iPerf“: Client
Betriebssystem: MS Windows XP
„iPerf“: Server
Betriebssystem: MS Windows XP
Abbildung 5.16: Testdurchführung mit AODV
In der Abbildung 5.16 sind die verwendeten Geräte und die durchgeführten Konfigurationen für die AODV-Messungen dargestellt. Somit werden für die AODV-Messungen
folgende Hardwarekomponenten verwendet:
• Laptop-1 (MS Windows XP),
• Laptop-3 (MS Windows XP),
• Arbeitsplatz-PC-1 (MS Windows XP) und
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
87
• WLAN-Karte RoamAbout 802.11 DS (Cabletron)“.
”
ArbeitsplatzPC-1
Laptop-1
Laptop-2
IP-Verkehr
IP-Adresse: 10.0.0.1/24
Netzwerk-Adresse: 10.0.0.0/24
„Broadcast“: 10.0.0.255/24
„Subnetzmaske“: 255.255.255.0/24
IP-Adresse: 10.0.0.3/24
Netzwerk-Adresse: 10.0.0.0/24
„Broadcast“: 10.0.0.255/24
„Subnetzmaske“: 255.255.255.0/24
IP-Adresse: 10.0.0.2/24
Netzwerk-Adresse: 10.0.0.0/24
„Broadcast“: 10.0.0.255/24
„Subnetzmaske“: 255.255.255.0/24
Betriebssystem: MS Windows XP
Betriebssystem: MS Windows XP
Betriebssystem: MS Windows 2000/
Linux OS
„iPerf“: Client
„iPerf“: Server
Abbildung 5.17: Testdurchführung mit OLSR
Für die Messungen mit OLSR wird ein Linux OS benötigt und deshalb wird der
Laptop-3 durch den Laptop-2 ausgetauscht. In der Abbildung 5.17 werden die Konfigurationen und die verwendeten Hardwarekomponenten deutlich:
• Laptop-1 (MS Windows XP),
• Laptop-2 (Linux 2.4.26 und MS Windows 2000),
• Arbeitsplatz-PC-1 (MS Windows XP) und
• WLAN-Karte RoamAbout 802.11 DS (Cabletron)“.
”
Einige Tests erfordern IP-Verkehr, der mit Hilfe von iPerf“ zwischen Laptop-1, der als
”
Client fungiert und dem Arbeitsplatz-PC-1, der den Server darstellt, erzeugt wird. Der
Arbeitsplatz-PC-1 sendet dabei lediglich Empfangsinformationen zurück. Zur Erfassung des Netzwerkverkehrs wird unter MS Windows der Analyzer“ bzw. der Network
”
”
Traffic Monitor“ und unter Linux OS IPTraf“ verwendet. Das entsprechende WLAN”
“Interface“ wird überwacht und die erhaltenen Werte in das Log-File“ abgespeichert.
”
Anhand der gesammelten Messwerte wird eine abschließende Bewertung vorgenommen.
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
5.3.2
88
Beschreibung der Messungen
Messungen zur erzeugten Netzlast
Die Messungen werden in einem dynamischen Netz vorgenommen, d.h. der mobile
Knoten, realisiert durch Laptop-1, ändert seine Position zu bestimmten Zeitpunkten.
Dagegen besitzen Laptop-2/3 und Arbeitsplatz-PC-1 ihre feste Position.
Laptop-1
ArbeitsplatzPC-1
Laptop-2/3
Abbildung 5.18: Ermittlung der erzeugten Netzlast (1)
In der Abbildung 5.18 ist das Netz zu Beginn der Messungen dargestellt. Durch die
Bewegung des mobilen Knotens (Laptop-1) kommt es zur Veränderung der Netztopologie und neue Routen entstehen. Die Veränderung des Netzes verdeutlicht die Abbildung 5.19.
ArbeitsplatzPC-1
Laptop-2/3
Laptop-1
Abbildung 5.19: Ermittlung der erzeugten Netzlast (2)
Für diese Messung werden die in Abbildung 5.12 farblich gekennzeichneten Messpunkte
(MP1, MP2, MP 5 und MP 6) verwendet Die Reihenfolge der Messung ist in Abbildung 5.15 aufgezeigt.
Diese geringe Anzahl von Messpunkten reicht aus, um Aussagen zur erzeugten Netzlast, die vom Routing stammt, zu treffen.
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
89
Messungen bei Veränderung der Topologie
Mit Hilfe von iPerf“ wird zwischen Laptop-1 und dem Arbeitsplatz-PC-1 der IP”
Verkehr erzeugt.
ArbeitsplatzPC-1
Laptop-1
Laptop-2/3
IP-Verkehr
Abbildung 5.20: Messung bei Veränderung der Topologie (1)
In der Abbildung 5.20 sind der Verkehrsfluss und das verwendete Netz dargestellt.
Der Laptop-2/3 und der Arbeitsplatz-PC-1 besitzen innerhalb dieses Netzes feste Positionen, lediglich der Laptop-1 verändert seine Position. Aufgrund der Bewegung des
mobilen Knotens kommt es zur Veränderung der Netztopologie und der Netzwerkverkehr muss über neue Routen weitergeleitet werden.
ArbeitsplatzPC-1
Laptop-2/3
IP-Verkehr
Laptop-1
IP-Verkehr
X
IP-Verkehr
Abbildung 5.21: Messung bei Veränderung der Topologie (2)
In der Abbildung 5.21 ist der Verlust der Route zwischen Laptop-1 und ArbeitsplatzPC-1 dargestellt. Der Verkehr wird daraufhin über den Laptop-2/3 weitergeleitet.
Für diese Messung werden die in den Abbildungen 5.12 und 5.13 definierten Messpunkte (MP1 - MP 9) verwendet. Die Reihenfolge der Messung ist in Abbildung 5.14
aufgezeigt.
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
90
Ermitteln der mittleren Übertragungsrate
Die Messungen zur Veränderung der Topologie (s. Abschnitt 5.3.2) bilden die Grundlage für die Ermittlung der mittleren Übertragungsrate. Dabei werden aber lediglich
die Werte an den Messpunkten (MP1 - MP 9) berücksichtigt. Für jeden Messpunkt
wird die mittlere Übertragungsrate bestimmt, indem eine Mittelung über alle Werte
dieses Messpunktes erfolgt.
Messungen mit unterschiedlichen Betriebssystemen
Die Messung kann momentan nur mit OLSR erfolgen, denn die verwendeten AODVImplementierungen sind nicht interoperabel.
Der Laptop-2 verwendet in diesem Testfall Linux OS als Betriebssystem (s. Abbildung 5.22).
Laptop-1
(MS Windows XP)
ArbeitsplatzPC-1
(MS Windows XP)
Laptop-2
(Linux 2.4.26)
IP-Verkehr
Abbildung 5.22: Messungen mit unterschiedlichen Betriebssystemen (1)
Als feste Knoten werden der Laptop-2 und der Arbeitsplatz-PC-1 definiert. Der mobile
Knoten, realisiert durch Laptop-1, bewegt sich innerhalb des Netzes und es kommt zur
Veränderung der Topologie (s. Abbildung 5.23).
Für die Position des mobilen Knotens werden die in der Abbildung 5.12 definierten
Messpunkte (MP1 - MP9) verwendet und die Reihenfolge der Bewegung ist in der
Abbildung 5.14 dargestellt. Mit Hilfe von iPerf“ wird der erforderliche IP-Verkehr
”
erzeugt.
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
ArbeitsplatzPC-1
(MS Windows XP)
Laptop-2
(Linux 2.4.26)
IP-Verkehr
91
Laptop-1
(MS Windows XP)
IP-Verkehr
X
IP-Verkehr
Abbildung 5.23: Messungen mit unterschiedlichen Betriebssystemen (2)
Messungen mit unterschiedlichen Routingparametern
Bei der verwendeten AODV-Implementierung für MS Windows können keine Parameter verändert werden und somit ist diese Messung auf OLSR beschränkt.
Bei dieser Messung werden die Routingparameter verändert. Die Parameter von OLSR
sind in der RFC 2636 [IETF, 2003e] definiert. Dabei ist aber zu beachten, dass einige
Parameter voneinander abhängig sind und nicht unabhängig voneinander zu betrachten sind. Es werden Veränderungen am Zeitintervall der Hello Message“ und entspre”
chend an der Hello Validity Time“ vorgenommen. Als mobiler Knoten wird in dieser
”
Messung der Laptop-1 verwendet. Die festen Knoten werden mit Hilfe vom Laptop-2
und dem Arbeitsplatz-PC-1 gebildet. Der Netzaufbau ist in der Abbildung 5.24 dargestellt.
ArbeitsplatzPC-1
Laptop-1
Laptop-2/3
IP-Verkehr
Veränderte Routingparameter:
- „Hello Interval“
= 4 sec
- „Hello Validity Time“ = 12 sec
Abbildung 5.24: Messungen mit unterschiedlichen Parameter (1)
Durch die Bewegung des mobilen Knotens kommt es zur Veränderung der Netztopo-
KAPITEL 5. REALISIERUNG EINER TESTUMGEBUNG
92
logie. Der IP-Verkehr wird zwischen Laptop-1 und dem Arbeitsplatz-PC-1 erzeugt.
Dazu wird das Tool iPerf“ verwendet. Bei Veränderung der Topologie entstehen neue
”
Routen (s. Abbildung 5.25). Die verwendeten Messpunkte (MP1 - MP9) sind in den
Abbildungen 5.12 und 5.13 dargestellt. Die Bewegung zwischen den Knoten wird mit
Hilfe der Abbildung 5.14 verdeutlicht.
ArbeitsplatzPC-1
Laptop-2/3
IP-Verkehr
Laptop-1
IP-Verkehr
X
IP-Verkehr
Veränderte Routingparameter:
- „Hello Interval“
= 4 sec
- „Hello Validity Time“ = 12 sec
Abbildung 5.25: Messungen mit unterschiedlichen Parameter (2)
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
93
Kapitel 6
Messungen und Ergebnisse
In diesem Kapitel wird die Funktionsfähigkeit der im Kapitel 5 realisierten Testumgebung überprüft. In den ersten Messungen wird die konzipierte Testumgebung überprüft
und die angestrebten Tests sollen zeigen, dass die Überlegungen zur Realisierung, die
Funktion der Ad-hoc Verfahren nachweist.
6.1
Einleitung
Die Messungen erfolgen nach dem im Kapitel 4 spezifiziertem Testkonzept und die
entsprechenden Angaben zur momentanen Testumgebung sind im Kapitel 5 zu finden.
Zur Glättung der Messwerte wird eine Mittelung über fünf Werte vorgenommen. Es ist
aber zu beachten, dass sich die momentane Testumgebung innerhalb eines Gebäudes
befindet. Dieses Gebäude ist mit weiteren Funknetzen, wie beispielsweise WLAN und
Bluethooth“, ausgestattet, die Einfluss auf das Ad-hoc-Netz haben könnten. Deshalb
”
sind diese Störungen bei den Betrachtungen zu berücksichtigen.
Die mit den verschiedenen Testszenarien realisierte Testumgebung für AODV und
OLSR sind im Abschnitt 5.3.1 beschrieben. Laut Angaben der Entwickler von
Windows AODV“, basiert diese Implementierung auf der RFC 3561 [IETF, 2003d].
”
Die Implementierung OLSRD“ hält sich an die RFC 3626 [IETF, 2003e] und ent”
sprechend sind die Routingparameter implementiert. Dabei ist aber zu beachten, dass
verschiedene Parameter voneinander abhängig sind bzw. sich mit Hilfe anderer Para-
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
94
meter berechnen lassen. Somit können sie nicht willkürlich geändert werden.
Zur besseren Veranschaulichung der erhaltenen Messwerte werden zwei unterschiedliche Diagrammtypen verwendet. Für die Darstellung der Messungen zur Netzlast,
der Übertragungsrate und dem Topologieverhalten werden Messwertkurven verwendet. In diesen Diagrammen wird die resultierende Datenrate bzw. Übertragungsrate
aller verwendeten Geräten in Abhängigkeit von der Zeit und der Bewegung bzw. Position des mobilen Knotens (Laptop-1) dargestellt. Von besonderem Interesse sind dabei
die Übertragungsraten der beiden anderen Geräte, wenn sich der Laptop-1 im Netz
bewegt bzw. sich an einem bestimmten Messpunkt befindet. Um eine bessere Auswertung dieser Messungen zu ermöglichen, werden die entsprechenden Werte für den
ankommenden Verkehr, den abgehenden Verkehr und schließlich den resultierenden
Gesamtverkehr in getrennten Abbildungen dargestellt. Dabei berechnet sich der resultierende Gesamtverkehr aus dem ankommenden und abgehenden Verkehr.
Hingegen bieten sich für die Betrachtungen zur mittleren Übertragungsrate Säulendiagramme an. Mit Hilfe dieser Diagramme wird die mittlere Übertragungsrate der
einzelnen Geräte für jeden Messpunkt dargestellt, wenn sich der Laptop-1 an dem entsprechenden Messpunkt befindet. Zur Berechnung der mittleren Übertragungsrate an
einem Messpunkt wird eine Mittelung über alle erhalten Wert, d.h. die resultierenden
Übertragungsraten des entsprechenden Gerätes, des Messpunktes durchgeführt.
6.2
6.2.1
Messungen
Messungen zur erzeugten Netzlast
Messung mit AODV
In der Abbildung 6.1 ist der abgehende Verkehr der verwendeten Geräte dargestellt.
Aus der Abbildung geht hervor, dass zu verschiedenen Zeitpunkten einzelne Peaks“
”
erscheinen. Bei weiterführenden Betrachtung und Messungen wurde deutlich, dass diese nur in Verbindung mit MS Windows auftreten. MS Windows versucht, sobald eine
Netzwerkumgebung vorhanden ist, Nachrichten über das NetBIOS“-Protokoll zu ver”
senden. Mit Hilfe des Tools Analyzer“ konnten diese Pakte ermittelt werden. NetBI”
”
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
95
Messung mit AODV
- Erzeugte Netzlast ("Outgoing Traffic")
4,000
MP
1
"Outgoing Traffic" [kbit/s]
3,500
MP
2
MP
5
MP
6
MP
5
MP
1
3,000
2,500
2,000
1,500
1,000
0,500
Start AODV 0,000
Arbeitsplatz-0,500
PC-1
Start AODV
Laptop-1
Start AODV
Laptop-3
0
100
200
300
400
500
600
700
800
900
t [s]
Laptop-1 (10.0.0.1)
Arbeitspaltz-PC-1 (10.0.0.3)
Laptop-3 (10.0.0.4)
Zeigt die Aktivität von OLSR an
Verdeutlicht den Messpunkt
Abbildung 6.1: Messung mit AODV - Erzeugte Netzlast (Abgehender Verkehr)
OS“ ist eine API für Netzwerkanwendungen und wird von den meisten Diensten und
Anwendungen, die innerhalb von MS Windows arbeiten, verwendet. NetBIOS“ ver”
wendet den UDP-Port 137 und durch das Versenden eines solchen Paketes erhöht sich
die Netzlast um ca. 400 bit/s. Z.B. versendet der Laptop-3 (10.0.0.4) zum Zeitpunkt
t = 315 s ein NetBIOS“-Paket, was wiederum bei den beiden anderen Geräten einen
”
erhöhten ankommenden Verkehr verursacht. Diese Pakte werden von allen verwendeten Geräten versendet und führen zu einer zusätzlichen Belastung des Netzes.
An den Messpunkten MP5 und MP6 kommt es zur Veränderung der Netzlast, was
auf die Veränderung des Netzes zurückzuführen ist. Der Laptop-1 bewegt sich aus der
Funkreichweite vom Arbeitsplatz-PC-1 und der Laptop-2 befindet sich sowohl im Sendebereich vom Laptop-1 als auch vom Arbeitsplatz-PC-1.
Weiterhin wird deutlich, dass AODV eine relativ geringe Netzlast erzeugt. Dies ist
bedingt durch die Funktionsweise von reaktiven Protokollen, zu denen AODV zählt.
In der Abbildung 6.2 ist der ankommende Verkehr dargestellt. Dabei wird deutlich,
dass sobald ein Knoten mit dem Senden beginnt, alle anderen Knoten des Ad-hocNetzes diese Daten empfangen und somit ankommenden Verkehr besitzen. Mit steigender Anzahl der Teilnehmer wird dieser größer. An den Messpunkten MP5 und
MP6 kommt es zur Veränderung der erzeugten Netzlast, die durch die Veränderung
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
96
Messung mit AODV
- Erzeugte Netzlast ("Incoming Traffic")
4,000
MP
1
3,500
MP
2
MP
5
MP
6
MP
5
MP
1
"Incoming Traffic" [kbit/s]
3,000
2,500
2,000
1,500
1,000
0,500
Start AODV
ArbeitsplatzPC-1
0,000
0
100
200
300
400
500
600
700
800
900
-0,500
t [s]
Start AODV
Laptop-1
Laptop-1 (10.0.0.1)
Start AODV
Laptop-3
Arbeitsplatz-PC-1 (10.0.0.3)
Laptop-3 (10.0.0.4)
Zeigt die Aktivität von OLSR an
Verdeutlicht den Messpunkt
Abbildung 6.2: Messung mit AODV - Erzeugte Netzlast (Ankommender Verkehr)
des Netzes und der Distanz zwischen den Knoten entsteht.
Messung mit AODV
- Erzeugte Netzlast ("Total Traffic")
4,000
3,500
MP
1
MP
2
400
500
MP
5
MP
6
MP
5
MP
1
"Total Traffic" [Mbit/s]
3,000
2,500
2,000
1,500
1,000
0,500
Start AODV
ArbeitsplatzPC-1
Start AODV
Laptop-1
Start AODV
Laptop-3
0,000
0
100
200
300
600
700
800
900
-0,500
t [s]
Laptop-1 (10.0.0.1)
Arbeitsplatz-PC-1 (10.0.0.3)
Laptop-3 (10.0.0.4)
Zeigt die Aktivität von OLSR an
Verdeutlicht den Messpunkt
Abbildung 6.3: Messung mit AODV - Erzeugte Netzlast (Gesamtverkehr)
Die Abbildung 6.3 verdeutlicht den resultierenden Gesamtverkehr, der sich aus dem
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
97
abgehenden und ankommenden Verkehr berechnet.
Bei der Analyse des abgehenden Verkehrs wird deutlich, das AODV nur eine sehr
geringe Netzlast erzeugt. Dies ist bedingt durch die Funktionsweise von reaktiven Protokollen, zu denen AODV zählt.
Messung mit OLSR
Messung mit OLSR
- "Erzeugte Netzlast" ("Outgoing Traffic")
3,500
MP
1
"Outgoing Traffic" [kbit/s]
3,000
Start OLSR
ArbeitsplatzPC-1
Start OLSR
Laptop-1
Start OLSR
Laptop-2
MP
2
MP
5
MP
6
MP
5
MP
1
2,500
2,000
1,500
1,000
0,500
0,000
0
100
200
300
400
500
600
700
800
900
-0,500
t [s]
Laptop-1 (10.0.0.1)
Laptop-2 (10.0.0.2)
Arbeitsplatz-PC-1 (10.0.0.3)
Zeigt die Aktivität von OLSR an
Verdeutlicht den Messpunkt
Abbildung 6.4: Messung mit OLSR - Erzeugte Netzlast (Ankommender Verkehr)
Die Abbildung 6.4 zeigt den abgehenden Verkehr der verwendeten Geräte. Auf den
verwendeten Geräten wird nacheinander OLSR gestartet und es wird sofort Netzlast
erzeugt. Wie bereits bei den Messungen zu AODV treten auch hier wieder die einzelnen Peaks“ auf, die durch das NetBIOS“ verursacht werden. Bei der Analyse des
”
”
abgehenden Verkehrs wird deutlich, das OLSR eine relativ große Netzlast erzeugt, die
Einfluss auf das komplette Ad-hoc-Netz hat. Bereits beim Starten von OLSR wird
eine Karte des Netzes erstellt. Eine periodische Aktualisierung der Routen ist erforderlich, was zur Erhöhung der Netzlast führt. Diese wird mit zunehmender Knotenund Routenanzahl größer. Ebenfalls kommt es an den Messpunkten MP5 und MP6 zur
Veränderung der Netzlast, was auf die Veränderung des Netzes zurückzuführen ist. Der
Laptop-1 bewegt sich aus der Funkreichweite vom Arbeitsplatz-PC-1 und der Laptop-2
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
98
befindet sich sowohl im Sendebereich vom Laptop-1 als auch vom Arbeitsplatz-PC-1.
Messung mit OLSR
- "Erzeugte Netzlast" ("Incoming Traffic")
3,500
MP
1
"Incoming Traffic" [kbit/s]
3,000
MP
2
MP
5
MP
6
MP
5
MP
1
2,500
2,000
1,500
1,000
0,500
Start OLSR 0,000
ArbeitsplatzPC-1
-0,500
0
100
200
300
400
500
600
700
800
900
t [s]
Start OLSR
Laptop-1
Laptop-1 (10.0.0.1)
Start OLSR
Laptop-2
Laptop-2 (10.0.0.2)
Arbeitsplatz-PC-1 (10.0.0.3)
Zeigt die Aktivität von OLSR an
Verdeutlicht den Messpunkt
Abbildung 6.5: Messung mit OLSR - Erzeugte Netzlast (Ankommender Verkehr)
In der Abbildung 6.5 ist der ankommende Verkehr dargestellt. Der resultierende Gesamtverkehr, der sich aus dem abgehenden und ankommenden Verkehr berechnet, ist
in der Abbildung 6.6 dargestellt.
Messung mit OLSR
- "Erzeugte Netzlast" ("Total Traffic")
3,500
MP
1
"Total Traffic" [kbit/s]
3,000
MP
2
MP
5
MP
6
MP
5
MP
1
2,500
2,000
1,500
1,000
0,500
Start OLSR 0,000
ArbeitsplatzPC-1
-0,500
Start OLSR
Laptop-1
Start OLSR
Laptop-2
0
100
200
300
400
500
600
700
800
900
t [s]
Laptop-1 (10.0.0.1)
Laptop-2 (10.0.0.2)
Arbietsplatz-PC-1 (10.0.0.3)
Zeigt die Aktivität von OLSR an
Verdeutlicht den Messpunkt
Abbildung 6.6: Messung mit OLSR - Erzeugte Netzlast (Gesamtverkehr)
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
99
Abschließender Vergleich von AODV und OLSR
Aus den Messungen zu beiden Routingverfahren wird deutlich, dass OLSR eine wesentlich höhere Netzlast erzeugt als AODV. Dies ist dadurch begründet, dass OLSR zu den
proaktiven Verfahren zählt und AODV hingegen zur Gruppe der reaktiven Verfahren
gehört. Aber mit zunehmender Mobilität der aktiven Knoten wird auch die Netzlast
von AODV größer. Diese wird aber trotzdem geringer sein, als dies im Vergleich bei
einem gleichen Netz, das OLSR unterstützt, der Fall wäre.
6.2.2
Messungen bei Veränderung der Topologie
Messungen mit AODV
In der Abbildung 6.7 ist der resultierende Gesamtverkehr aller verwendeten Geräte in
Abhängigkeit von der Position und Bewegung des mobilen Knotens dargestellt.
Messung mit AODV
- Veränderung der Topologie ("Total Traffic")
7,000
MP MP MP MP MP MP MP MP MP MP MP MP MP MP MP
1 2 3
4
3
5
6 5
7 8
9
8
7 5 1
6,000
"Total Traffic" [Mbit/s]
5,000
4,000
3,000
2,000
1,000
Start
AODV
Start
„Traffic“
0,000
0
200
400
600
800
1000
1200
1400
-1,000
t [s]
Laptop-1 (10.0.0.1)
Arbeitsplatz-PC-1 (10.0.0.3)
Laptop-3 (10.0.0.4)
Zeigt die Aktivität von AODV an
Verdeutlicht den Messpunkt
Abbildung 6.7: Messung mit AODV - Veränderung der Topologie (Gesamtverkehr)
Dieser berechnet sich aus dem abgehenden Verkehr (s. Abbildung 6.8) und ankommenden Verkehr (s. Abbildung 6.9).
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
100
Messung mit AODV
- Veränderung der Topologie ("Outgoing Traffic")
7,000
MP MP MP MP MP MP MP MP MP MP MP MP MP MP MP
1 2 3
4
3
5
6 5
7 8
9
8
7 5
1
6,000
"Outgoing Traffic" [kbit/s]
5,000
4,000
3,000
2,000
1,000
0,000
Start
AODV
0
200
400
600
-1,000
800
1000
1200
1400
t [s]
Start
„Traffic“
Laptop-1 (10.0.0.1)
Arbeitsplatz-PC-1 (10.0.0.3)
Laptop-3 (10.0.0.4)
Zeigt die Aktivität von AODV an
Verdeutlicht den Messpunkt
Abbildung 6.8: Messung mit AODV - Veränderung der Topologie (Abgehender
Verkehr)
Messung mit AODV
- Veränderung der Topologie ("Incoming Traffic")
7,000
MP MP MP MP MP MP MP MP MP MP MP MP MP MP MP
1 2 3
4
3
5
6 5
7 8
9
8
7 5
1
"Incoming Traffic" [kbit/s]
6,000
5,000
4,000
3,000
2,000
1,000
Start
AODV
0,000
0
200
400
600
800
1000
1200
1400
-1,000
Start
„Traffic“
t [s]
Laptop-1 (10.0.0.1)
Arbeitsplatz-PC-1 (10.0.0.3)
Laptop-3 (10.0.0.4)
Zeigt die Aktivität von AODV an
Verdeutlicht den Messpunkt
Abbildung 6.9: Messung mit AODV - Veränderung der Topologie (Ankommender
Verkehr)
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
101
In der Abbildung 6.7 sind die Phasen, in denen neue Routen gefunden und aufgebaut werden, nur schlecht erkennbar. Mit Hilfe des Log-Files“, das von Win”
”
dows AODV“ erstellt wird, können die Betrachtungen aber vorgenommen werden.
Innerhalb dieses Log-Files“, werden alle Informationen des Ad-hoc-Netzes aufgezeigt.
”
Windows AODV“ benötigt von der Initialisierung des Interfaces“ bis zum Versenden
”
”
der ersten Hello Message“ ca. 15 Sekunden.
”
Initialisierung der
Netzwerkkarten
Fri Apr 15 15:28:14 2005
:
:
Fri Apr 15 15:28:14 2005
BindingIndex: 5
Device Name :\Device\{A214E2BF-B02F-4136-B4F0
-75224B1CE1E6}
Device desc :RoamAbout 802.11 DS
:
:
Fri Apr 15 15:28:14 2005
5. \Device\{A214E2BF-B02F-4136-B4F0-75224B1CE1E6}
- RoamAbout 802.11 DS
Fri Apr 15 15:28:14 2005
Matched binding index:5
IPv4-Adressen der
WLAN-Karte
Aufbau der
Routingtabelle
Fri Apr 15 15:28:14 2005
IfIndex:2 IP:10.0.0.1 Mask:255.255.255.0
Fri Apr 15 15:28:14 2005
Set special gw ip=10.0.0.254
Fri Apr 15 15:28:15 2005
Adding Destination:10.0.0.1 Nexthop:10.0.0.1 DSN:1
Hops:0
Lifetime:4294967295.0 to Route Table
Fri Apr 15 15:28:15 2005
Adding 10.0.0.3 to LF All-neighbors Table
Abbildung 6.10: Windows AODV-Log-File“ - Starten von Windows AODV
”
In der Abbildung 6.10 ist das Log-File“ mit der Initialisierung des Interfaces“ und
”
”
dem Versenden der ersten Hello Message“ für den Laptop-1 (10.0.0.1) dargestellt.
”
Anhand der Abbildung 6.7 wird deutlich, dass mit zunehmender Distanz zwischen
der Quelle (Laptop-1) und dem Ziel (Arbeitsplatz-PC-1) die Übertragungsrate entsprechend kleiner wird, beispielsweise bei der Bewegung vom MP3 zum MP4 und
der resultierenden Übertragungsrate am MP4. Am Messpunkt MP9 kommt es sogar
zum Totalausfall und der Datentransfer ist nicht mehr möglich. Die Bewegungen vom
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
102
Laptop-1 innerhalb des Netzes führen zur Veränderung der Netztopologie. Deutlich
wird es bei der Bewegung vom MP5 zum MP6, denn die Quelle verliert hier die Route
zum Ziel, so dass eine neue Route erst gefunden bzw. aufgebaut werden muss. Aber
auch bei den Messpunkten MP7, MP8 und MP9 erfolgt die Weiterleitung der Daten über den Laptop-3. In diesem Fall vergehen ca. 6 Sekunden, bis eine neue Route
gefunden und in die Routingtabelle eingetragen wird.
Fri Apr 15 15:37:24 2005
Checking for expired routes
Fri Apr 15 15:37:25 2005
Neighbor link break!:NBR:10.0.0.3 CurrTime:1113572245.41
LastHelloTime:1113572240.755 LastKeepAliveTime:1113572240.755
Wegfall einer
Route und
entfernen dieser
Route aus der
Routingtabelle
Fri Apr 15 15:37:25 2005
Deleting Kernel Route Dest:10.0.0.3 Nexthop:10.0.0.3 If:2
Fri Apr 15 15:37:25 2005
Deleting route from driver
Fri Apr 15 15:37:25 2005
RERR case1:
Fri Apr 15 15:37:25 2005
Received Route Trigger; src:10.0.0.1 dst:10.0.0.3
Fri Apr 15 15:37:25 2005
Creating RREQ callback after 800 msecs
„Route
Discovery“-Phase
Neue Route zum
Ziel ermittelt und
eintragen in die
Routingtabelle
Fri Apr 15 15:37:25 2005
Send RREQ:
Flags: G HCNT:0 RREQID:18 D:10.0.0.3 DSN:39 O:10.0.0.1 OSN:38
:
Fri Apr 15 15:37:27 2005
Rcvd RREP Dest:10.0.0.3/0 Hops:1 Dest_seq:39 Orig:10.0.0.1
Lifetime:6860 Flags:0 PrevHop:10.0.0.4
Fri Apr 15 15:37:27 2005
Adding kernel route Dst:10.0.0.3Mask:0xffffffff Nexthop:10.0.0.4 Metric:2
Fri Apr 15 15:37:27 2005
Adding route in driver
:
Abbildung 6.11: Windows AODV-Log-File“ - Aufbau einer neuen Route
”
In der Abbildung 6.11 ist das Log-File“ mit dem Verbindungsabbruch und der Initia”
lisierung einer neuen Route dargestellt. Die neue Route führt dann über den Laptop-3,
denn dieser hat sowohl den Laptop-1 als auch den Arbeitsplatz-PC-1 als Eintrag in
seiner Routingtabelle. Besonders deutlich wird das Routingverhalten vom Laptop-2
anhand der beiden Abbildungen 6.8 und 6.9. An den Messpunkten MP6, MP7, MP8
und MP9 wird deutlich, dass der Laptop-3 die Daten vom Laptop-1 empfängt und dann
an den Arbeitsplatz-PC-1 weiterleitet. Somit hat der Laptop-3 an diesen Messpunkten
sowohl abgehenden als auch ankommenden Verkehr.
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
103
Messungen mit OLSR
Der resultierende Gesamtverkehr aller verwendeten Geräte in Abhängigkeit von der
Position und Bewegung des mobilen Knotens ist in der Abbildung 6.12 dargestellt.
Messung mit OLSR
- Veränderung der Topologie ("Total Traffic")
7,000
MP MP MP MP MP MP MP MP MP MP MP MP MP MP MP
1 2 3
4
3
5
6
5
7 8
9
8
7
5
1
6,000
"Total Traffic" [Mbit/s]
5,000
4,000
3,000
2,000
1,000
Start
OLSR
0,000
0
200
400
600
800
1000
1200
1400
-1,000
Start
„Traffic“
t [s]
Laptop-1 (10.0.0.1)
Laptop-2 (10.0.0.2)
Arbeitsplatz-PC-1 (10.0.0.3)
Zeigt die Aktivität von OLSR an
Verdeutlicht den Messpunkt
Abbildung 6.12: Messung mit OLSR - Veränderung der Topologie (Gesamtverkehr)
Der resultierende Gesamtverkehr berechnet sich aus dem abgehenden Verkehr (s. Abbildung 6.13) und ankommenden Verkehr (s. Abbildung 6.14).
Aus der Abbildung 6.12 geht hervor, dass OLSR bei Veränderung der Netztopologie sofort reagiert und der IP-Verkehr ohne wesentliche Zeitverzögerung über neue
Routen weitergeleitet wird. Dies ist dadurch begründet, dass bei proaktiven Routingalgorithmen die Knoten bereits beim Verbindungsaufbau Informationen zu allen
Nachbarn besitzen. Anhand der Messung wird deutlich, dass sofort beim Start des
IP-Traffics“ zwischen Quelle und Ziel eine entsprechende Route vorhanden ist und
”
die Daten können ohne Verzögerung übertragen werden. Wie bei den Messungen zu
AODV, führt die Vergrößerung der Distanz zwischen Quelle und Ziel zur Verkleinerung
der Übertragungsrate. Dies wird z.B. bei der Bewegung vom MP3 zum MP4 und der
resultierenden Übertragungsrate am MP4 deutlich. Ebenfalls führt die Bewegung des
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
104
Messung mit OLSR
- Veränderung der Topologie ("Outgoing Traffic")
7,000
MP MP MP MP MP MP MP MP MP MP MP MP MP MP MP
1 2 3
4
3
5
6
5
7 8
9
8
7
5
1
"Outgoing Traffic" [Mbit/s]
6,000
5,000
4,000
3,000
2,000
1,000
Start
OLSR
0,000
0
200
400
600
800
1000
1200
1400
-1,000
Start
„Traffic“
t [s]
Laptop-1 (10.0.0.1)
Laptop-2 (10.0.0.2)
Arbeitsplatz-PC-1 (10.0.0.3)
Zeigt die Aktivität von OLSR an
Verdeutlicht den Messpunkt
Abbildung 6.13: Messung mit OLSR - Veränderung der Topologie (Abgehender
Verkehr)
Messungen mit OLSR
- Veränderung der Topologie ("Incoming Traffic")
7,000
MP MP MP MP MP MP MP MP MP MP MP MP MP MP MP
1
2 3
4
3
5
6
5
7 8
9
8
7
5
1
"Incoming Traffic" [Mbit/s]
6,000
5,000
4,000
3,000
2,000
1,000
0,000
Start
OLSR
0
200
400
600
800
1000
1200
1400
-1,000
Start
„Traffic“
t [s]
Laptop-1 (10.0.0.1)
Laptop-2 (10.0.0.2)
Laptop-3 (10.0.0.3)
Zeigt die Aktivität von OLSR an
Verdeutlicht den Messpunkt
Abbildung 6.14: Messung mit OLSR - Veränderung der Topologie (Ankommender
Verkehr)
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
105
mobilen Knotens (Laptop-1) innerhalb des Netzes zur Veränderung der Netztopologie.
Deutlich wird es bei der Bewegung vom MP5 zum MP6. Bei dieser Bewegung verliert
die Quelle die Route zum Ziel und sofort wird mit Hilfe der Routingtabellen eine neue
Route gefunden bzw. aufgebaut. Die neue Route führt dann über den Laptop-2, denn
dieser hat sowohl den Laptop-1 als auch den Arbeitsplatz-PC-1 als Eintrag in seiner
Routingtabelle.
Abschließender Vergleich von AODV und OLSR
Beide Routingverfahren reagieren auf die Veränderung der Netztopologie. Wesentliche Unterschiede existieren beim Management der Routen. Die proaktiven Verfahren
stellen bereits zu Beginn die Route zur Verfügung. Hingegen stellen die reaktiven Verfahren erst eine Route zur Verfügung, wenn sie benötigt wird.
6.2.3
Bewertung der mittleren Übertragungsrate
Diese Bewertung beruht auf den im Abschnitt 6.2.2 ermittelten Übertragungsraten.
Wie bereits erläutert, wird mit Hilfe von Säulendiagrammen die mittlere Übertragungsrate der einzelnen Geräte für jeden Messpunkt dargestellt, wenn sich der Laptop-1
an dem entsprechenden Messpunkt befindet. Zur Berechnung der mittleren Übertragungsrate an einem Messpunkt wird eine Mittelung über alle erhaltenen Werte, d.h.
die resultierenden Übertragungsraten des entsprechenden Gerätes, des Messpunktes
durchgeführt.
Beim Vergleich der mittleren Übertragungsrate von AODV (s. Abbildung 6.15) und
OLSR (s. Abbildung 6.16) wird deutlich, dass bei AODV die mittlere Übertragungsrate an verschiedenen Messpunkten etwas größer ist als bei OLSR, beispielsweise an den
Messpunkten MP4 und MP5. Dies ist dadurch begründet, dass AODV erst bei Bedarf
eine Route aufbaut, was eine höhere Bandbreite ermöglicht. Die höhere Bandbreite
geht aber auf Kosten der Zeit, die sich durch den Aufbau von Routingtabellen ergibt.
Aber die Zeit, die AODV für den Aufbau einer Route benötigt, hat natürlich auch Einfluss auf die mittlere Übertragungsrate der Messpunkte, an denen eine Veränderung
der Netztopologie erfolgt. An diesen Messpunkten, d.h. MP6, MP7, MP8 und MP9,
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
106
Messung mit AODV
- mittlere Übertragungsrate ("Total Traffic")
mittlere Übertragungsrate [Mbits/s]
6,000
5,000
4,000
3,000
2,000
1,000
0,000
MP1
MP2
MP3
MP4
MP3
MP5
MP6
MP5
MP7
MP8
MP9
MP8
MP7
MP5
MP1
Messpunkte
Laptop-1 (10.0.0.1)
Laptop-2 (10.0.0.4)
Arbeitsplatz-PC-1 (10.0.0.3)
Abbildung 6.15: Messung mit AODV - Mittlere Übertragungsrate (Gesamtverkehr)
Messung mit OLSR
- mittlere Übertragungsrate ("Total Traffic") 6,000
mittlere Übertragungsrate [Mbit/s]
5,000
4,000
3,000
2,000
1,000
0,000
MP1
MP2
MP3
MP4
MP3
MP5
MP6
MP5
MP7
MP8
MP9
MP8
MP7
MP5
MP1
Messpunkt
"Laptop-1 (10.0.0.1)"
"Laptop-2 (10.0.0.2)"
"Arbeitsplatz-PC-1 (10.0.0.3)"
Abbildung 6.16: Messung mit OLSR- Mittlere Übertragungsrate (Gesamtverkehr)
wird deutlich, dass die mittlere Übertragungsrate von OLSR größer ist als bei AODV.
Bei beiden Verfahren ist offensichtlich, dass mit zunehmender Distanz zwischen Quelle
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
107
und Ziel und dem Routing des Verkehrs über weitere Knoten, die mittlere Übertragungsrate abnimmt. Am Messpunkt MP4 hat sich die Distanz zwischen der Quelle
und dem Ziel vergrößert und somit nimmt die mittlere Übertragungsrate ab. Das Routing über einen weiteren Knoten wird an den Messpunkten MP6, MP7, MP8 und
MP9 deutlich. Diese Messpunkte befinden sich nicht mehr in der Funkreichweite vom
Arbeitsplatz-PC-1. Eine neue Route zwischen dem Arbeitsplatz-PC-1 und dem mobilen Knotens (Laptop-1) wird ermittelt, die dann über den Laptop-2 führt. Der Laptop2 besitzt nur ein Interface“ und die Bandbreite ist begrenzt auf ca. 5,5 Mbits. Der
”
Knoten hat sowohl ankommenden als auch abgehenden Verkehr, der auf die verfügbare
Bandbreite aufgeteilt werden muss.
6.2.4
Messungen mit unterschiedlichen Betriebssystemen
Messungen mit AODV
Laut Angaben der Entwickler ist eine Interoperabilität, mit anderen AODVImplementierungen möglich. Leider kann in den momentanen Tests diese Aussage nicht
bestätigt werden. Somit sind keine Aussagen zur Interoperabilität und dem damit verbundenem Verhalten des Ad-hoc-Netzes möglich.
Messungen mit OLSR
Diese Messung unterscheidet sich von den bisherigen Messungen dadurch, dass als
Betriebssystem auf dem Laptop-2, Linux OS verwendet wird.
In der Abbildung 6.17 ist der resultierende Gesamtverkehr dargestellt, der sich aus
dem ankommenden Verkehr (s. Abbildung 6.18) und abgehenden Verkehr (s. Abbildung 6.19) zusammensetzt.
Außerdem sind in der Abbildung 6.20 die mittleren Übertragungsraten der einzelnen
Geräte in Abhängigkeit von der Position des mobilen Knotens (Laptop-1) dargestellt.
Es wird deutlich, dass unterschiedliche Betriebssysteme die Funktionsfähigkeit des Adhoc-Netzes nicht beeinflussen. Als Vergleich zu dieser Messung werden die bereits in
Abschnitt 6.2.2 vorgestellten Ergebnisse verwendet.
Bei der Gegenüberstellung der beiden Messungen fällt auf, dass bei der Verwendung
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
108
Messung mit OLSR
- Unterschiedliche Betriebssysteme ("Total Traffic")
7,000
MP MP MP MP MP MP MP MP MP MP MP MP MP MP MP
1 2 3
4
3
5
6
5
7
8
9
8 7
5
1
6,000
"Total Traffic" [Mbit/s]
5,000
4,000
3,000
2,000
1,000
0,000
Start
OLSR
0
200
400
600
800
1000
1200
1400
-1,000
Start
„Traffic“
t [s]
Laptop-1 (10.0.0.1)
Laptop-2 (10.0.0.2)
Arbeitsplatz-PC-1 (10.0.0.3)
Zeigt die Aktivität von OLSR an
Verdeutlicht den Messpunkt
Abbildung 6.17: Messung mit OLSR - Unterschiedliche Betriebssysteme (Gesamtverkehr)
Messung mit OLSR
- Unterschiedliche Betriebssysteme ("Incoming Traffic")
7,000
MP MP MP MP MP MP MP MP MP MP MP MP MP MP MP
1 2 3
4
3
5
6
5
7
8
9
8 7
5
1
"Incoming Traffic" [Mbit/s]
6,000
5,000
4,000
3,000
2,000
1,000
Start
OLSR
0,000
0
200
400
600
800
1000
1200
1400
-1,000
Start
„Traffic“
t [s]
Laptop-1 (10.0.0.1)
Laptop-2 (10.0.0.2)
Arbeitsplatz-PC-1 (10.0.0.3)
Zeigt die Aktivität von OLSR an
Verdeutlicht den Messpunkt
Abbildung 6.18: Messung mit OLSR - Unterschiedliche Betriebssysteme (Ankommender Verkehr)
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
109
Messung mit OLSR
- Unterschiedliche Betriebssysteme ("Outgoing Traffic")
7,000
MP MP MP MP MP MP MP MP MP MP MP MP MP MP MP
1 2 3
4
5
6
5
7
8
9
8 7
5
1
3
"Outgoing Traffic" [Mbit/s]
6,000
5,000
4,000
3,000
2,000
1,000
0,000
Start
OLSR
0
200
400
600
800
1000
1200
1400
-1,000
Start
„Traffic“
t [s]
Laptop-1 (10.0.0.1)
Laptop-2 (10.0.0.2)
Arbeitsplatz-PC-1 (10.0.0.3)
Zeigt die Aktivität von OLSR an
Verdeutlicht den Messpunkt
Abbildung 6.19: Messung mit OLSR - Unterschiedliche Betriebssysteme (Abgehender Verkehr)
Messung mit OLSR
- Unterschiedliche Betriebssysteme, die mittlere Übertragungsrate ("Total Traffic")
6,000
mittlere Übertragungsrate [Mbit/s]
5,000
4,000
3,000
2,000
1,000
0,000
MP1
MP2
MP3
MP4
MP3
"Laptop-1 (10.0.0.1)"
MP5
MP6 MP5 MP7
Messpunkte
"Laptop-2 (10.0.0.2)"
MP8
MP9
MP8
MP7
MP5
MP1
"Arbeitsplatz-PC-1 (10.0.0.3)"
Abbildung 6.20: Messung mit OLSR - Unterschiedliche Betriebssysteme, die mittlere Übertragungsrate (Gesamtverkehr)
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
110
vom Laptop-2 als Router wesentlich höhere Übertragungsraten möglich sind. Die höhere Übertragungsraten werden besonders an den Messpunkten MP6, MP7, MP8 und
MP9 deutlich.
Ein Grund für dieses Verhalten und das Ergebnis könnten die Konfigurationsmöglichkeiten der WLAN-Karte unter Linux OS sein. Unter Linux OS können gegenüber MS
Windows weitere Parameter der WLAN-Karte konfiguriert werden, wie beispielsweise
die Sendeleistung. Diese Parameter könnten Einfluss auf das Netz und auf die vorhandene Übertragungsrate haben.
6.2.5
Messungen mit unterschiedlichen Routingparametern
Messungen mit AODV
Bei Windows AODV“ können die Routingparameter nicht verändert werden.
”
Messungen mit OLSR
Bei dieser Messung werden folgende Routingparameter verändert:
• Hello Interval“ = 4 sec und
”
• Hello Validity Time“ = 12 sec.
”
Diese Veränderungen haben natürlich Einfluss auf das Ad-hoc-Netz und das Routing
innerhalb des Netzes.
In der Abbildung 6.21 ist der resultierende Gesamtverkehr dargestellt, dieser berechnet
sich aus dem ankommenden (s. Abbildung 6.22) und abgehenden Verkehr (s. Abbildung 6.23).
In den Abbildungen sind für jedes Gerät die einzelnen Messwertkurven dargestellt.
Zusätzlich sind in der Abbildung 6.24 die mittleren Übertragungsraten der einzelnen
Geräte in Abhängigkeit von der Position des mobilen Knotens (Laptop-1) dargestellt.
Als Vergleich zu dieser Messung werden die bereits in Abschnitt 6.2.2 vorgestellten
Ergebnisse verwendet.
Bei der Gegenüberstellung dieser Messung werden wesentliche Unterschiede deutlich.
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
111
Messung mit OLSR
- Veränderung der Routingparameter ("Total Traffic")
7,000
MP MP MP MP MP MP MP MP MP MP MP MP MP MP MP
1
2 3
4
5
6
5
7
8
9
8
7
5
1
3
6,000
"Total Traffic" [Mbit/s]
5,000
4,000
3,000
2,000
1,000
0,000
Start
OLSR
0
200
400
600
800
1000
1200
1400
-1,000
Start
„Traffic“
t [s]
Laptop-1 (10.0.0.1)
Laptop-2 (10.0.0.2)
Arbeitsplatz-PC-1 (10.0.0.3)
Zeigt die Aktivität von OLSR an
Verdeutlicht den Messpunkt
Abbildung 6.21: Messung mit OLSR - Veränderung der Parameter (Gesamtverkehr)
Messung mit OLSR
- Veränderung der Routingparameter ("Incoming Traffic")
7,000
MP MP MP MP MP MP MP MP MP MP MP MP MP MP MP
3
5
6
5
7
8
9
8
7
5
1 2 3
4
1
"Incoming Traffic" [Mbit/s]
6,000
5,000
4,000
3,000
2,000
1,000
Start
OLSR
0,000
0
200
400
600
800
1000
1200
1400
-1,000
Start
„Traffic“
t [s]
Laptop-1 (10.0.0.1)
Laptop-2 (10.0.0.2)
Arbeitsplatz-PC-1 (10.0.0.3)
Zeigt die Aktivität von OLSR an
Verdeutlicht den Messpunkt
Abbildung 6.22: Messung mit OLSR - Veränderung der Parameter (Ankommender Verkehr)
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
112
Messung mit OLSR
- Veränderung der Routingparameter ("Outgoing Traffic")
7,000
MP MP MP MP MP MP MP MP MP MP MP MP MP MP MP
3
5
6
5
7
8
9
8
7
5
1 2 3
4
1
"Outgoing Traffic" [Mbit/s]
6,000
5,000
4,000
3,000
2,000
1,000
0,000
Start
OLSR
0
200
400
600
800
1000
1200
1400
-1,000
Start
„Traffic“
t [s]
Laptop-1 (10.0.0.1)
Laptop-2 (10.0.0.2)
Arbeitsplatz-PC-1 (10.0.0.3)
Zeigt die Aktivität von OLSR an
Verdeutlicht den Messpunkt
Abbildung 6.23: Messung mit OLSR - Veränderung der Parameter (Abgehender
Verkehr)
Messung mit OLSR
- Veränderung der Routingparameter, die mittlere Übertragungsrate ("Total Traffic")
6,000
mittlere Übertragungsrate [Mbit/s]
5,000
4,000
3,000
2,000
1,000
0,000
MP1
MP2
MP3
MP4
MP3
MP5
MP6
MP5
MP7
MP8
MP9
MP8
MP7
MP5
MP1
Messpunkt
Laptop-1 (10.0.01)
Laptop-2 (10.0.0.2)
Arbeitsplatz-PC-1 (10.0.0.3)
Abbildung 6.24: Messung mit OLSR - Veränderung der Parameter, die mittlere
Übertragungsrate (Gesamtverkehr)
KAPITEL 6. MESSUNGEN UND ERGEBNISSE
113
Die Übertragungsraten dieser Messung sind etwas größer als bei der in Abschnitt 6.2.2
diskutierten Messung, bei der keine Veränderungen an den Routingparametern vorgenommen wurden. Besonders deutlich wird es an den Messpunkten MP4 und MP8.
Bedingt durch die Modifikation der Routingparameter verändert sich auch die Aktualisierung der Routen und somit verringert sich die erzeugte Netzlast, was zur Vergrößerung der Bandbreite führt. Kommt es zum Verlust einer Route, dauert es etwas
länger, bis eine neue Route gefunden und aufgebaut wird. Dies wird deutlich bei der
Bewegung vom MP5 zum MP6 und vom MP5 zum MP7.
KAPITEL 7. AUSBLICK
114
Kapitel 7
Ausblick
Ad-hoc-Netze erfahren eine ständige Weiterentwicklung und entsprechende Implementierungen kommen hinzu. Momentan existieren Implementierungen zu AODV, ARAN,
DSR, FSR und OLSR, aber nur ein geringer Anteil wird weiterentwickelt. Dabei finden
Multicast“, IPv6 und QoS nur wenig Aufmerksamkeit. Für Ad-hoc-Netze existieren
”
weitere Routingverfahren, die aber momentan nicht implementiert sind.
Mit der Weiterentwicklung ist denkbar, dass die Lücken geschlossen werden, d.h. neue
Protokolle implementiert und die fehlenden Features, wie beispielsweise Multicast“,
”
IPv6 und QoS, integriert werden.
Die Testumgebung ist nicht speziell für eine Implementierung oder ein Routingverfahren konzipiert, sondern kann individuell eingesetzt werden und bildet die Grundlage
für entsprechende Tests zu Ad-hoc-Netzen. Entsprechende Veränderungen der Testumgebung sollten erfolgen, wenn neue Implementierungen mit zusätzlichen Features
entstehen bzw. ältere Implementierungen zusätzliche Erweiterungen erfahren.
Denkbar sind auch Untersuchungen zum Verhalten des Netzes, wenn unterschiedliche
mobile Geräte, beispielsweise Laptops und PDAs, verwendet werden, denn verschiedene Routingalgorithmen benutzen als Metrik die Stromversorgung, die bei PDAs
etwas kritischer zu betrachten ist. Leider konnten in die momentane Testumgebung
keine PDAs integriert werden und somit sind keine Aussagen zu diesen Testszenarien
möglich. Die PDAs ermöglichen eine bessere Mobilität der Knoten und somit können
auch Aussagen zum Verhalten des Netzes getroffen werden, wenn sich die Knoten mit
KAPITEL 7. AUSBLICK
115
höherer Geschwindigkeit bewegen. In den absolvierten Tests wurden Laptops verwendet und die maximal mögliche Geschwindigkeit beträgt ca. 3 km/h. In weiterführenden
Tests sollten entsprechende Aussagen verifiziert werden, wenn PDAs verwendet werden.
Ebenfalls ist in der momentanen Testumgebung die Mobilität der Knoten nur auf ein
mobiles Gerät, bedingt durch die Stromversorgung und Akkulaufzeit, beschränkt. Weiterführende Untersuchungen zu mehreren mobilen Teilnehmern sind denkbar.
Somit sollten sich weitere Untersuchungen mit der Integration verschiedener mobiler
Geräte und neuer Implementierungen beschäftigen. Zusätzliche Testszenarien sollten
dazu erstellt werden und entsprechende Messungen sollten erste Aussagen zur Leistungsfähigkeit der Umgebung liefern.
Weiter Betrachtungen könnten Multicast“, IPv6 und QoS sein.
”
KAPITEL 8. ZUSAMMENFASSUNG
116
Kapitel 8
Zusammenfassung
Im Vordergrund dieser Arbeit standen Aussagen zu vorhandenen Implementierungen,
die für Ad-hoc-Netze momentan verfügbar sind und die Realisierung einer Testumgebung. Mit dieser sollten Aussagen zu den Ad-hoc-Netzen und den Implementierungen
getroffen werden.
Da Ad-hoc-Netze keine Infrastruktur besitzen, können sie einfach und schnell aufgebaut werden. Deshalb stellen sie eine wesentliche Alternative zu den Infrastrukturnetzen dar. Die Problematik der Ad-hoc-Netze ist, dass sie geeignete Routingprotokolle aufweisen müssen, um die Netzdynamik zu unterstützen. Die Topologie eines
Ad-hoc-Netzes verändert sich dynamisch, denn alle Knoten sind mobil, aber es wird
nicht ausgeschlossen, dass auch feste Knoten vorhanden sind. Dabei können die festen Knoten einen Zugang zu Infrastrukturnetzen gewährleisten bzw. anbieten. Die
Routingprotokolle müssen mit der Mobilität der Teilnehmer sowie deren begrenzter
Energieversorgung und Bandbreite umgehen können.
Für die Routingprotokolle der Ad-hoc-Netze existieren bereits verschiedene Implementierung, die sich anhand der Anforderung, die an das System gestellt werden,
dem Verhalten und der notwendigen Konfiguration unterscheiden. Einige Implementierungen sind aber nicht mehr auf dem neuesten Stand und erfahren keine Weiterentwicklung. Eine Verwendung dieser Implementierungen wird nicht empfohlen, denn
es kann zu Problemen mit der Software und neueren Betriebssystemen führen. Eine
geringe Anzahl von Implementierungen zeichnet sich durch eine fortschreitende Wei-
KAPITEL 8. ZUSAMMENFASSUNG
117
terentwicklung aus. Dies hat den Vorteil, dass neue Features“ vorhanden sind und
”
entsprechende Veränderungen an RFC bzw. Draft berücksichtigt werden. Insbesondere für Multicast“, IPv6 und QoS sind weitere Veränderungen erforderlich. Die Anzahl
”
der Implementierungen, die diese Anforderungen bereits unterstützen, ist sehr gering.
Zur Realisierung der Testumgebung für Ad-hoc-Netze werden die wesentlichen Eigenschaften der Ad-hoc-Netze und verwendeten Implementierungen berücksichtigt. Dabei
bestehen die Netze sowohl aus mobilen als auch festen Knoten. Der Testaufbau und
Testablauf ist dabei abhängig vom Testszenario und der Konfiguration der Knoten.
Die Erfassung von Messdaten eines Ad-hoc-Netzes erwies sich im ersten Moment als
schwierig. Die verfügbaren Softwarekomponenten, die zum Monitoring“ verwendet
”
werden, orientieren sich an Infrastrukturnetzen und bieten nur eingeschränkte bzw.
keine Möglichkeit zur genauen Erfassung und abschließender Archivierung der Daten. Deshalb wurden an den frei verfügbaren Softwarekomponenten Veränderungen
vorgenommen, die eine Archivierung der Daten, welche innerhalb von Ad-hoc-Netzen
ermittelt werden, ermöglichen.
Von den vorhandenen Implementierungen wurden AODV und OLSR ausgewählt. Mit
Hilfe der Testumgebung konnten erste Aussagen zu dem entsprechenden Routingprotokoll getroffen werden. Die Unterschiede zwischen den reaktiven und proaktiven Verfahren wurden deutlich und anhand weiterführender Untersuchungen konnten auch
Aussagen zur Interoperabilität getroffen werden. Es wird ersichtlich, dass die einzelnen
Routingalgorithmen unterschiedliche Metriken zum Management der Routen verwendet. Eine Veränderung am Routingprotokoll sollte dabei auf Grundlage der Anwendung
geschehen, d.h. entsprechend der Verwendung sind die Routingparameter zu wählen
und anzupassen. Die ersten Ergebnisse machen deutlich, dass die Überlegungen zur
Testumgebung und den Testszenarien gute Aussagen liefern.
Es wurde gezeigt, dass MANETs mit den heute zur Verfügung stehenden Technologien
bereits realisierbar sind, wenn auch durch veraltete oder unvollständige Implementierungen Einschränkungen zu berücksichtigen sind. Für spezielle Anwendungen, wie beispielsweise die spontane Vernetzung von Konferenzteilnehmern oder Arbeitsgruppen
sind MANETs schon heute gut realisierbar und sinnvoll anwendbar. Für den breiten
Einsatz von Ad-hoc-Netzen ist jedoch noch einige Entwicklungsarbeit notwendig.
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
Anhang A
Informationen zu den
Softwarekomponenten
A.1
A.1.1
Implementierungen der Routingprotokolle
AODV
118
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
Implementierung:
Entwickler:
AODV IPv6“ [3]
”
Peter Lee
Quelle:
http://members.shaw.ca/aodv6-sfu/
119
AODV Kernel“ [4]
”
NIST - National Institute of Standards
”
and Technology“; Technology Adminis”
tration, U.S. Department of Commerce“
http://w3.antd.nist.gov/wctg/
aodv kernel/index.html
Betriebssystem
Linux OS
Linux OS
Aktuelle Version:
AODV6-R0.2“
”
2.2.2
draft-ietf-manet-aodv-10 [IETF, 2002b];
draft-ietf-manet-aodv-10 [IETF, 2002b];
draft-perkins-aodv6-01 [IETF, 2000a];
draft-perkins-aodv6-01 [IETF, 2000a]
Programmiersprache:
RFCs und Drafts:
draft-wakikawa-manet-globalv602 [IETF, 2002c]
Systemanforderungen:
Softwareanforderungen:
Sonstige Eigenschaften:
Linux OS;
Linux 2.4.1;
WLAN-Karte;
WLAN-Karte;
Netfilter“
”
Netfilter“;
”
Packet Forwarding“
”
AODV-UU“ v0.5 [7]
”
IPv6-Unterstützung;
von den Entwicklern mit 3 Knoten (2
Hops“) getestet
”
Funktionsfähig:
User-Space-Daemon“;
”
unterhält Kernel-Routing-Table“
”
Ja
Ja, aber nur die Version 2.1.0!!
Tabelle A.1: Übersicht zu den AODV-Implementierungen (1)
Implementierung:
AODV-UCSB“ [5]
”
Entwickler:
Quelle:
http://moment.cs.ucsb.edu/AODV/aodv.
AODV-UIUC“ [6]
”
University of Illinois
”
Champaign“
at
Urbana-
http://aslib.sourceforge.net/
html
Betriebssystem:
Linux OS
Linux OS
Aktuelle Version:
aodv-ucsb-0.1b“
”
AODV-UIUC-0.5“ (2002-08-12)
”
Linux 2.4.1;
Linux 2.4.3;
WLAN-Karte;
WLAN-Karte;
Netfilter“
”
Netfilter“, Loadable Module Support“
”
”
und TUN/TAP Support“
”
ASL [1]
Verwendung wird nicht mehr empfohlen!!
einfaches API;
Keine Aussage, denn die Verwendung
User-Space-Daemon“
”
Nein
Programmiersprache:
RFCs und Drafts:
Systemanforderungen:
Softwareanforderungen:
Sonstige Eigenschaften:
Funktionsfähig:
wird nicht mehr empfohlen!!
Tabelle A.2: Übersicht zu den AODV-Implementierungen (2)
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
Implementierung:
AODV UU“ [7]
”
Uppsala University“
”
http://core.it.uu.se/AdHoc/
AODV-UU for IPv6“ [8]
”
University of Buckingham“
”
http://webspace.buckingham.ac.uk/
ImplementationPortal
cadams/bnrg/aodv6/index.html
Betriebssystem:
Linux OS
Linux OS
Aktuelle Version:
aodv-uu-0.9“
”
aodv-uu-ipv6-0.9 4“
”
draft-ietf-manet-aodv-13 [IETF, 2003b];
RFC 3561 [IETF, 2003d]
Entwickler:
Quelle:
120
Programmiersprache:
RFCs und Drafts:
RFC 3561 [IETF, 2003d]
Systemanforderungen:
Linux 2.4.x/2.6.x;
Linux 2.4.x/2.6.x;
WLAN-Karte;
WLAN-Karte;
Netfilter“
”
Netfilter“;
”
Packet Forwarding“
”
AODV-UU“ v0.9 [7]
”
IPv6-Unterstützung;
Softwareanforderungen:
Sonstige Eigenschaften:
Internet Gateway Support“;
”
User-Space-Daemon“;
”
zusätzlicher
Layer“
”
Abstraktion“, iplib“
”
für
für Einsatz in APE“ [9] entwickelt;
”
sowohl für WLAN-“Interface“ als auch für
übliche Netzwerk-“Interface“ einsetzbar;
Verwendung im ns2 [29];
von den Entwicklern getestet mit 5 KnoFunktionsfähig:
ten (4 Hops“);
”
Ja
Nein
Tabelle A.3: Übersicht zu den AODV-Implementierungen (3)
IP-Version”
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
Implementierung:
Entwickler:
Hut AODV for IPv6“ [18]
”
Antti J. Tuominen, Helsinki University
”
of Technology, Telecommunications Soft-
121
MAODV“ [28]
”
University of Maryland“
”
ware und Multimedia Lab“
http://www.tcs.hut.fi/∼anttit/
Quelle:
http://www.isr.umd.edu/CSHCN/
manet/aodv/
research/maodv/MAODV-UMD.html
Betriebssystem:
Linux OS
Linux OS
Aktuelle Version:
hut-aodv6-0.20“
”
patch-maodv-umd-0.6“;
”
maodv-umd-0.7.2-rel-1.2.patch“
”
Programmiersprache:
RFCs und Drafts:
RFC 3561 [IETF, 2003d];
draft-perkins-manet-aodv6-01
draft-ietf-manet-maodv-00 [IETF, 2000b]
[IETF,
2000a];
draft-wakikawa-manet-globalv602 [IETF, 2002c]
Systemanforderungen:
Linux 2.4.3;
Linux OS;
WLAN-Karte
WLAN-Karte
Softwareanforderungen:
Sonstige Eigenschaften:
IPv6-Unterstützung;
unterstützt Eigenschaften der Spezifikation, abgesehen von Hop-to-Hop“;
”
Funktionsfähig:
kein Multicast“ und QoS
”
Nein
AODV-UU“ v0.6/v0.72 [7]
”
Multicast“-Unterstützung;
”
-DMAODV Flags“ im Makefile“ zur
”
”
Aktivierung/Deaktivierung von Multi”
cast“;
noch nicht im ns2 [29] integriert
Ja
Tabelle A.4: Übersicht zu den AODV-Implementierungen (4)
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
Implementierung:
TinyAODV“ [43]
”
http://cvs.sourceforge.net/viewcvs.
UoB JAdHoc“ [44]
”
ComNet, Universität Bremen“
”
http://www.aodv.org/modules.php?
py/tinyos/tinyos-1.x/contrib/hsn/
op=modload&name=UpDownload&file=
Entwickler:
Quelle:
122
index&req=viewdownload&cid=2
Betriebssystem:
Tiny OS
MS Windows;
Linux OS
Aktuelle Version:
UoB Jadhoc v0.2“ (MS Windows/Linux
”
OS); (2004-03)
UoB JAdhoc v0.2“ (Sharp Zaurus Linux
”
(PDA)) (2004-03);
UoBWinAODV v0.15“ (MS Windows
”
XP) (2005-03
Programmiersprache:
Java
RFCs und Drafts:
Systemanforderungen:
RFC 3561 [IETF, 2003d]
WLAN-Karte
Linux OS:
Linux Kernel mit IP: advanced router“
”
MS Windows 2000/XP;
WLAN-Karte
Softwareanforderungen:
Linux OS:
JRE [23] oder SDK [22], Libpcap“ [26]
”
und Jpcap“ [24]
”
MS Windows:
JRE [23] oder SDK [22],
WinPcap“ [47] und Jpcap“ [24]
”
”
Zaurus Linux:
Cross-Compiler“ ( gcc“) für
”
”
ARM Prozessor
Sonstige Eigenschaften:
verschiedene Vereinfachungen der AODV-
IPv4-Unterstützung
Implementierung:
RREP-“Messages“ nur durch Destina”
tion“ erstellt,
Routen sterben nicht bzw. laufen nicht
ab,
nur Hop Count Metric“ wird benutzt,
”
keine Messages“, um Routen aktiv zu
”
halten,
Route Error“, wenn Data Message“
”
”
nichtzustellbar
Funktionsfähig:
Keine Aussage
Ja, aber nach den ersten Tests, wird die
Verwendung nicht empfohlen!!
Tabelle A.5: Übersicht zu den AODV-Implementierungen (5)
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
Implementierung:
Windows AODV [46]
Entwickler:
Intel Corporation“
”
http://moment.cs.ucsb.edu/AODV/
Quelle:
aodv-windows.html
Betriebssystem:
MS Windows
Aktuelle Version:
windows aodv 0.1.14“
”
Programmiersprache:
RFCs und Drafts:
RFC 3561 [IETF, 2003d]
Systemanforderungen:
MS Windows XP;
WLAN-Karte
Softwareanforderungen:
Sonstige Eigenschaften:
verwendet UDP/IP-Port 654
Funktionsfähig:
Ja
Tabelle A.6: Übersicht zu den AODV-Implementierungen (6)
123
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
A.1.2
124
ARAN
Entwickler:
Daniel LaFlamme, Secure Internet and Group-Networking Lab, Computer
”
Science at the Depertment, University of Massachusetts, Arnherst“
Quelle:
http://signl.cs.umass.edu/arand/index.php
Betriebssystem:
Linux OS
Aktuelle Version:
arand-0.3.2“ (2003-01-31)
”
C
Programmiersprache:
RFCs und Drafts:
Systemanforderungen:
x86 PC/Laptop;
Linux 2.4.x;
WLAN-Karte;
X509-Zertifikat auf jedem Knoten
Softwareanforderungen:
OpenSSL Library“;
”
ASL [1]
Sonstige Eigenschaften:
Funktionsfähig:
Nein
Tabelle A.7: Übersicht zu ARAN
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
A.1.3
125
DSR
Implementierung:
Entwickler:
Quelle:
DSR (Insignia)“ [13]
”
INSIGNIA Project Team“
”
http://comet.columbia.edu/
DSR (Monarch) [14]
Rice Monarch Project“
”
http://www.monarch.cs.rice.edu/
insignia/testbed.html
dsr-impl.html
Betriebssystem:
FreeBSD
FreeBSD
Aktuelle Version:
INSIGNIA-0.01“
”
DSR-0.02“
”
Programmiersprache:
RFCs und Drafts:
draft-ietf-manet-insignia-01
[IETF,
draft-ietf-manet-dsr-01 [IETF, 1998]
1999]
Systemanforderungen:
x86 Compatible Notebook;
x86 Compatible Notebook;
FreeBSD 2.2.7;
FreeBSD 2.2.7/3.3;
WLAN-Karte (Lucent);
WLAN-Karte
MAC-Filter
Softwareanforderungen:
Sonstige Eigenschaften:
DSR Kernel Source Code“ [13];
”
INSIGNIA Kernel Source Code“ [13];
”
INSIGNIA GUI-API Code“ [13];
”
Tcl/Tk“ 8.0
”
basiert auf der CMU Implementation
zwei Phasen Route Discovery“
”
von DSR;
einfache
QoS-Benachrichtigungs-
GUI mit Kontrolle von API;
mechanismus;
MPEG I Video Header Parser Tool“;
”
GUI mit Kontrolle von API;
Route-Cache“;
”
Multi-Level Priority Interface Queu”
es“;
MPEG TV“ wird als Streaming Vi”
”
deo“
Paket rettend;
Anpassungsfähige
Link Layer Re”
transmission“ und Missing Neighbor
”
Detection“;
Gateway“ Funktionalität für die Inte”
gration von IP-Netzwerken;
MAC-Filter
für
Ad-hoc-Netzwerk
”
Emulation“ und Testen der Protokolle;
Unterstützung für mehrere Schnittstellen;
zahlreiche Support-Tools;
benutzt IPv6-artige
Headers“, um
”
Routinginformationen zu übertragen
Funktionsfähig:
Keine Aussage, da FreeBSD benötigt
Keine Aussage, da FreeBSD benötigt
wird!!
wird!!
Tabelle A.8: Übersicht zu den DSR-Implementierungen (1)
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
Implementierung:
126
DSR (Piconet)“ [15]
”
DSR (UC Boulder-Click!)“ [16]
”
http://piconet.sourceforge.net/
http://pecolab.colorado.edu/DSR.
thesis/main.html
html
Linux/BSD OS;
Linux OS
Entwickler:
Quelle:
Betriebssystem:
UNIX-like OS
Aktuelle Version:
Programmiersprache:
initial release“ (2002-11-11)
”
C
RFCs und Drafts:
Systemanforderungen:
Softwareanforderungen:
Sonstige Eigenschaften:
C++
draft-ietf-manet-dsr-08 [IETF, 2003a]
x86 PC;
x86 PC/Laptop;
Linux 2.4.3;
Linux 2.4.2;
H3600 series Compaq iPAQ;
WLAN-Karte;
WLAN-Karte (Lucent Orinoco);
Wireless Tools“ [48]
”
Netfilter“
”
Cross Compiler“ und Varios Tools“
”
”
für iPAQ;
Click! Modular Router“ v1.2.4 [11];
”
0.20 iPAQ/Linux Distribution“ oder
”
Familiar Linux Distribution“ 0.4
”
IPv4-Unterstützung;
Kernel Tap Option“
”
Nur in Verbindung mit Click! Modular
Router“ [11] funktionsfähig!!
Funktionsfähig:
Handheld“-Unterstützung
”
Nein
Ja
Tabelle A.9: Übersicht zu den DSR-Implementierungen (2)
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
A.1.4
FSR-ATR“
”
Entwickler:
Quelle:
Adaptive Communications Research Laboratories“ (ACR)
”
http://www.acr.atr.jp/acr/general/product/GSRFSR/
Betriebssystem:
Linux OS
Aktuelle Version:
Programmiersprache:
FSR-ATR v1.2“ (2005-01-19)
”
C
RFCs und Drafts
draft-ietf-manet-fsr-03 [IETF, 2002a]
Systemanforderungen:
x86 PC/Laptop;
Linux 2.2.x/2.4.x/2.6.x;
H3600 series Compaq iPAQ;
WLAN-Karte (Lucent Orinoco);
Sonstige Eigenschaften:
Netfilter“
”
Linux Cross Compiler“ und Various Tools“ 0.20 iPAQ/Linux für iPAQ;
”
”
0.20 iPAQ/Linux Distribution“oder Familiar Linux Distribution“ 0.40
”
”
IPv4-Unterstützung;
Funktionsfähig:
Ja
Softwareanforderungen:
Unterschiede zu draft-ietf-manet-fsr-03 [IETF, 2002a]
Tabelle A.10: Übersicht zu FSR-ATR“
”
127
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
A.1.5
128
OLSR
Implementierung:
Entwickler:
crc-nolsrdv6“ [12]
”
Project Hipercom, Inria Rocquen”
court, NRL“
inria-nolsrd“ [19]
”
Project Hipercom, Inria Rocquen”
court“
Quelle:
http://pf.itd.nrl.navy.mil/
http://pf.itd.nrl.navy.mil/
project/showfiles.php?group id=
project/showfiles.php?group id=
16414&release id=18181
16414&release id=18181
Betriebssystem:
Linux OS
Linux OS
Aktuelle Version:
nolsrdv6“ (2003-04-03)
”
C++
nolsrd 1.0a9“ (2003-04-04)
”
Programmiersprache:
RFCs und Drafts:
Systemanforderungen:
draft-ietf-manet-olsr-03 [IETF, 2000c]
Linux Kernel 2.x.x;
Linux Kernel 2.x.x;
WLAN-Karte;
WLAN-Karte;
IP-Forward“
”
IP-Forward“
”
Softwareanforderungen:
Sonstige Eigenschaften:
Modifizierung
des
Inria
”
OLSR
IPv4-Unterstützung;
Source-Codes“
verwendet UDP-Port 698
Funktionsfähig:
Nein
Nein
Tabelle A.11: Übersicht zu den OLSR-Implementierungen (1)
Implementierung:
nolsrd“ [31]
”
nrlolsrd“ [32]
”
http://sourceforge.net/projects/
http://pf.itd.nrl.navy.mil/
Entwickler:
Quelle:
nolsr/
project/showfiles.php?group id=
16414&release id=18367
Betriebssystem:
MS Windows
MS Windows;
Linux OS
Aktuelle Version:
nrlolsrdv7.5“ (2004-11-17)
”
Programmiersprache:
nOLSR-old“ (2003-11-02)
”
C
RFCs und Drafts:
RFC 3626 [IETF, 2003e]
RFC 3626 [IETF, 2003e]
Systemanforderungen:
MS Windows;
Linux OS;
WLAN-Karte
MS Windows;
WLAN-Karte
Softwareanforderungen:
Sonstige Eigenschaften:
Funktionsfähig:
Ja
Ja
Tabelle A.12: Übersicht zu den OLSR-Implementierungen (2)
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
Implementierung:
OLSR (GRC, UPV)“ [33]
”
Entwickler:
129
OLSRD“ [35]
”
U.S. Naval Research Laboratory“
”
http://www.olsr.org/index.cgi?
Quelle:
http://www.grc.upv.es/software/
Betriebssystem:
Linux OS;
Linux OS;
MS Windows
MS Windows
action=main
Aktuelle Version:
Olsrd-0.4.8“
”
C++
Programmiersprache:
RFCs und Drafts:
Systemanforderungen:
Softwareanforderungen:
Sonstige Eigenschaften:
RFC 3626 [IETF, 2003e]
Linux 2.x.x;
Linux OS;
MS Windows;
MS Windows;
WLAN-Karte;
WLAN-Karte
IP-Forward“
”
PICA Library“ [40]
”
IPv4-Unterstützung;
Pocket-PC“-Unterstützung;
”
verwendet UDP-Port 698
Funktionsfähig:
Ja
Ja
Tabelle A.13: Übersicht zu den OLSR-Implementierungen (3)
Implementierung:
OLSR11win (GRC)“ [34]
”
Entwickler:
OLSRv3 (Inria)“ [37]
”
Projet Hipercom, INRIA Rocquen”
court“
Quelle:
http://hipercom.inria.fr/olsr/
http://www.grc.upv.es/software/
intro OLSR11win.html
Betriebssystem:
Linux OS
MS Windows
RFCs und Drafts:
draft-ietf-manet-olsr-03 [IETF, 2000c]
draft-ietf-manet-olsr-11 [IETF, 2003c]
Systemanforderungen:
Linux 2.x.x;
MS Windows;
WLAN-Karte;
WLAN-Karte
Aktuelle Version:
Programmiersprache:
IP-Forward“
”
Softwareanforderungen:
Sonstige Eigenschaften:
WinPcap“ [47]
”
IPv4-Unterstützung;
verwendet UDP-Port 698;
User-Space-Daemon“;
”
keine Modifikation des Kernels erforderlich
Funktionsfähig:
Nein
Ja
Tabelle A.14: Übersicht zu den OLSR-Implementierungen (4)
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
Implementierung:
130
OOLSR“ [38]
”
Entwickler:
OLSR EXTRA“ [36]
”
Projet Hipercom, INRIA Rocquen”
court“
Quelle:
http://pf.itd.nrl.navy.mil/
http://hipercom.inria.fr/OOLSR/
project/showfiles.php?group id=
16414&release id=18181
Betriebssystem:
Linux OS
Linux OS;
MS Windows
Aktuelle Version:
ethereal-parser-RFC-1.0“;
”
ethereal-parser-spec3-1.0“;
”
manetconf-1.1a9-4“
”
Programmiersprache:
C++
RFCs und Drafts:
Systemanforderungen:
oolr-0.99.15“
”
RFC 3626 [IETF, 2003e]
Linux OS;
Linux OS:
WLAN-Karte
g++“ v2.95/3.3,
”
glibc“ v2.3.2
”
MS Windows 2000/XP und CE ARM;
WLAN-Karte
Softwareanforderungen:
Sonstige Eigenschaften:
IPv4-Unterstützung für MS Windows;
IPv4- und IPv6-Unterstützung für Linux OS;
Cygwin Support“;
”
ns2-Unterstützung
Funktionsfähig:
Nein
Ja, aber unter Linux OS nur mit
IPv4. Unter MS Windows keine Aussage, denn Cygwin“ stand nicht zur
”
Verfügung.
Tabelle A.15: Übersicht zu den OLSR-Implementierungen (5)
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
Implementierung:
Entwickler:
PyOLSR“ [41]
”
Cedric Adjih, Projet
”
INRIA Rocquencourt“
Quelle:
http://hipercom.inria.fr/pyOLSR/
http://qolsr.lri.fr/
Betriebssystem:
Linux OS
Linux OS
Aktuelle Version:
Programmiersprache:
PyOLSR-0.0.2“
”
Python
Qolyester-2004-1023“
”
C++
RFCs und Drafts:
RFC 3626 [IETF, 2003e]
RFC 3626 [IETF, 2003e]
Systemanforderungen:
Linux OS;
Linux 2.4;
WLAN-Karte;
WLAN-Karte
Hipercom,
131
QOLSR“ [42]
”
Laboratoire De Recherche En Infor”
matique“
XFree86
Softwareanforderungen:
Sonstige Eigenschaften:
verwendete UDP-Port 698
gcc“ v3.0
”
IPv4 und IPv6-Unterstützung;
verwendet UDP-Port 698;
bietet QoS;
Funktionsfähig:
Keine Aussage
kein Support für Link Layer Notifica”
tion“ und Security Considerations“
”
Ja, aber nur mit IPv4!!
Tabelle A.16: Übersicht zu den OLSR-Implementierungen (6)
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
A.2
132
Tools für Ad-hoc-Netze
Implementierung:
Entwickler:
APE“ [9]
”
Department of Computer System,
”
Uppsala University“; Ericsson“
”
Click! Modular Router“ [11]
”
MIT LCS’s Parallel and Distributed
”
Operating Systems group, Mazu Networks, the ICSI Center for Internet Research and UCLA“
Quelle:
http://www.pdos.lcs.mit.edu/
http://pdos.csail.mit.edu/click/
click/-downloads
Betriebssystem:
Linux OS;
Linux OS
MS Windows
Aktuelle Version:
Programmiersprache:
ape-0.4“ (2002-11-07)
”
Perl
click-1.4.3“
”
Linux OS:
Linux Kernel 2.2/ 2.4;
RFCs und Drafts:
Systemanforderungen:
“Lilo“ oder Grub boot-loader“,
”
Ext2, Ext3 oder ReiserFS (Filesys-
Vanilla Linux Kernel“;
”
700 MHz Pentium III;
tem)
MS Windows mit Dos;
WLAN-Karte
WLAN-Karte
Softwareanforderungen:
Sonstige Eigenschaften:
Pcap Library“
”
momentan sind folgende Routingprotokolle implementiert:
Funktionsfähig:
AODV-UU“,
”
Mad-hoc AODV“,
”
OLSR (Inria)“,
”
LUNAR“,
”
TORA“,
”
DSR“,
”
Nein
Ja
Tabelle A.17: Übersicht zu den Tools für Ad-hoc-Netze (1)
ANHANG A. INFORMATIONEN ZU DEN SOFTWAREKOMPONENTEN
Implementierung:
Entwickler:
LUNAR“ [27]
”
Uppsala University“
”
133
PACMAN“ [39]
”
Dr. Kilian Weniger, Ingmar Baumgart und Prof. M. Zitterbart;
Insti”
tut für Telematik, Universität Karlsruhe (TH)“
Quelle:
http://core.it.uu.se/AdHoc/
http://pacman-autoconf.
LunarImpl
sourceforge.net/
Betriebssystem:
Linux OS
Linux OS
Aktuelle Version:
Lunar-0.4.0“
”
Perl
Pacman-1.32“
”
C
Programmiersprache:
RFCs und Drafts:
draft-ietf-manet-fsr-03 [IETF, 2002a];
draft-ietf-manet-olsr-03 [IETF, 2000c];
RFC 3626
Systemanforderungen:
Softwareanforderungen:
Sonstige Eigenschaften:
Funktionsfähig:
Linux Kernel 2.4/2.6;
Linux 2.4.19, 2.6.x;
WLAN-Karte;
WLAN-Karte;
TUN/TAP Device“, ARPD“ und
”
”
Netfilter“
”
Wireless Tools“ [48];
”
LUNAR Kernel Module“
”
integriert in APE“
”
Keine Aussagen
CONFIG IP NF QUEUE“
”
Ja
Tabelle A.18: Übersicht zu den Tools für Ad-hoc-Netze (2)
Implementierung:
WNTE“ [49]
”
Institut für Telematik, Universität
”
Karlsruhe (TH)“
ViTAN“ [45]
”
F. Fitzek, acticom GmbH - mobile
”
”
networks“; P. Seeling und M. Reisslein,
Quelle:
http://wnte.sourceforge.net/
Arizone State University“; M. Zorzi,
”
”
Univerità di Ferrara“
”
http://www.acticom.de/vitan.html
Betriebssystem:
Linux OS
Entwickler:
Linux OS;
MS Windows
Aktuelle Version:
v1.1
Programmiersprache:
Perl
RFCs und Drafts:
Systemanforderungen:
Linux OS;
Linux OS;
WLAN-Karte;
Windows XP
iptable“, iptmac“ und
”
”
ssh public key“ auf jedem Knoten
”
Softwareanforderungen:
Sonstige Eigenschaften:
Verwendung
in
Funktionsfähig:
PACMAN“ [39]
”
Ja
Verbindung
mit
Pcap Library“
”
mit Hilfe der Knotenkoordinaten Darstellung des Netzes
Ja
Tabelle A.19: Übersicht zu den Tools für Ad-hoc-Netze (3)
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
134
Anhang B
Hinweise zur realisierten
Testumgebung
B.1
Verwendete Hardwarekomponenten
B.1.1
Überblick zu den Hardwarekomponenten
Wesentliche Bestandteile der Testumgebung sind sowohl mobile als auch feste Endgeräte mit unterschiedlichen Betriebssystemen, d.h. Linux OS und MS Windows, und
einer entsprechenden WLAN-Karte, RoamAbout 802.11 DS (Cabletron)“ (s. Tabel”
le B.5).
In der realisierten Testumgebung dient der Arbeitsplatz-PC-1 (s. Tabelle B.4) als festes
Endgerät und mit Hilfe von Laptops, d.h. Laptop-1 (s. Tabelle B.1), Laptop-2 (s. Tabelle B.2) und Laptop-3 (s. Tabelle B.3), werden die mobilen Endgeräte realisiert. Die
Spezifikationen der verwendeten Geräte sind in den folgenden Tabellen dargestellt. Neben Aussagen zur Hard- und Software sind in diesen Tabellen auch die entsprechenden
IPv4-Adressen dargestellt.
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
Bezeichnung:
Laptop-1
Hersteller:
Fujitsu Siemens
Produkt:
AMILO Pro V2000
CPU:
Mobile Intel Celeron M, 1500 MHz
Arbeitsspeicher:
246 MB (PC2700 DDR SDRAM)
Netzwerkkarte-WLAN:
Intern:
Intel(R) PRO/Wireless 2200BG Network Connection;
54 Mbps
Extern (PCMCIA Karte): RoamAbout 802.11 DS (Cabletron);
11 Mbps
Betriebssystem:
Linux Kernel 2.4.26 und MS Windows XP Professional (SP1)
IPv4-Adresse:
Netzwerk-Adresse:
10.0.0.0/24
Host“-Adresse:
”
Subnetzmaske“:
”
Broadcast“:
”
10.0.0.1/24
255.255.255.0/24
10.0.0.255/24
Tabelle B.1: Laptop-1 - Spezifikation
Bezeichnung:
Laptop-2
Hersteller:
Dell
Produkt:
Latitude C800
135
CPU:
Mobile Intel Pentium IIIE, 700 MHz
Arbeitsspeicher:
512 MB (SDRAM)
Netzwerkkarte-WLAN:
Intern:
Extern (PCMCIA Karte): RoamAbout 802.11 DS (Cabletron);
11 Mbps
Betriebssystem:
Linux Kernel 2.4.26 und MS Windows 2000 Professional (SP4)
IPv4-Adresse:
Netzwerk-Adresse:
10.0.0.0/24
Host“-Adresse:
”
Subnetzmaske“:
”
Broadcast“:
”
10.0.0.2/24
255.255.255.0/24
10.0.0.255/24
Tabelle B.2: Laptop-2 - Spezifikation
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
Bezeichnung:
Laptop-3
Hersteller:
Toshiba
Produkt:
PORTEGE 3500
CPU:
Mobile Intel Pentium III-S, 600 MHz
Arbeitsspeicher:
240 MB (SDRAM)
Netzwerkkarte-WLAN:
Intern:
Intel(R) PRO/100 M Mobile Connection;
11 Mbps
Extern (PCMCIA Karte): RoamAbout 802.11 DS (Cabletron);
11 Mbps
Betriebssystem:
MS Windows XP Professional (SP2)
IPv4-Adresse:
Netzwerk-Adresse:
10.0.0.0/24
Host“-Adresse:
”
Subnetzmaske“:
”
Broadcast“:
”
10.0.0.4/24
255.255.255.0/24
10.0.0.255/24
Tabelle B.3: Laptop-3 - Spezifikation
Bezeichnung:
Arbeitsplatz-PC-1
Hersteller:
Produkt:
CPU:
Intel Pentium 4, 1513 MHz
Arbeitsspeicher:
512 MB (SDRAM)
Netzwerkkarte-WLAN:
Intern:
Extern (PCMCIA Karte): RoamAbout 802.11 DS (Cabletron);
11 Mbps
Betriebssystem:
MS Windows XP Professional (SP2)
IPv4-Adresse:
Netzwerk-Adresse:
10.0.0.0/24
Host“-Adresse:
”
Subnetzmaske“:
”
Broadcast“:
”
10.0.0.3/24
255.255.255.0/24
10.0.0.255/24
Tabelle B.4: Arbeitsplatz-PC-1 - Spezifikation
136
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
Hersteller:
Cabletron
Produkt:
RoamAbout 802.11 DS
P/N:
CSIBD-AB-128
Chipset“:
”
Interface Type“:
”
Data Transfer Rate“:
”
Data Link Protocol“:
”
Frequency Band“:
”
Port(s) Required“:
”
Features“:
”
Software:
BAKOM 99.0538.L.P
PC Card
11 Mbps
IEEE 802.11b
2.4 GHz
Slot(s) Required 1*PC Card-type II
128-bit Verschlüsselung
MS Windows:
Client Manager Utility“ v3.30;
”
NDIS 5 Miniport Driver“ v7.86
”
Linux OS:
Tabelle B.5: RoamAbout 802.11 DS (Cabletron)“ - Spezifikation
”
137
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
B.1.2
138
Konfiguration der WLAN-Karte
Konfiguration der WLAN-Karten unter Linux OS
Die verwendete WLAN-Karte wird vom Linux OS unterstützt. Eine WLAN-Karte ist
für den Linux Kernel das gleiche wie eine normale Netzwerkkarte und somit als Ether”
net Device“ (z.B. eth1“) im Kernel angemeldet. Es ist aber zu beachten, das SuSE
”
diese Device“ als WLan“ bzw. WLan-Pcmcia“ (z.B. wlan0“) bezeichnet. Mit Hilfe
”
”
”
”
der Programme ifconfig“ und route“ kann die WLAN-Karte genauso konfiguriert
”
”
werden wie jede andere Netzwerkkarte (s. Abbildung B.1).
linux:~ # ifconfig –a
eth1 Link encap:Ethernet HWaddr 00:E0:63:82:A1:86
inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::2e0:63ff:fe82:a186/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:648 (648.0 b)
Interrupt:3 Base address:0x100
Abbildung B.1: Beispielausgabe: ifconfig -a“
”
Zum Einstellen der Wireless Extensions“ wird das Programm iwconfig“ verwendet.
”
”
iwconfig“ funktioniert genauso wie ifconfig“ und zeigt beim Aufrufen ohne Parameter
”
”
die aktuellen Einstellungen der Wireless Extensions“ an (s. Abbildung B.2).
”
linux:~ # iwconfig
eth1 IEEE 802.11-DS ESSID:"test-net" Nickname:"fujitsu"
Mode:Ad-Hoc Frequency:2.417GHz Cell: 00:E0:63:82:A1:86
Bit Rate=11Mb/s Tx-Power=15 dBm Sensitivity:1/3
Retry limit:4 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Abbildung B.2: Beispielausgabe: iwconfig
Die Abbildung B.3 verdeutlicht die Konfiguration der
ESSID“ und dem Modus.
”
WLAN-Device“ mit der
”
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
139
linux:~ # iwconfig <De v ic e > essid test-net
linux:~ # iwconfig <De v ic e > mode ad-hoc
Abbildung B.3: Linux OS - Konfiguration der WLAN-Karte mit der ESSID“
”
und dem Modus
Unter SuSE ist die entsprechende Konfigurationsdatei der WLAN-Karte im Verzeichnis
/etc/sysconfig/network/“ zu finden. Innerhalb dieses Verzeichnisses sind alle konfigu”
rierten Netzwerkkarten ( Devices“) zu finden. Die entsprechende Konfigurationsdatei
”
einer Device“ ist ifcfg-< Device >“. In der Abbildung B.4 ist ein Beispiel einer Kon”
”
figurationsdatei dargestellt. Enthalten sind sowohl allgemeine Einstellungen als auch
Wireless Extensions“ und die entsprechenden IPv4-Adressen.
”
BOOTPROTO='static'
DHCLIENT_SET_DOWN_LINK='yes'
MTU=''
REMOTE_IPADDR=''
STARTMODE='hotplug'
UNIQUE='K1pk.jrBDbmL7DWA'
WIRELESS_ESSID="test-net"
WIRELESS_KEY=''
WIRELESS_MODE='Ad-hoc'
WIRELESS_NICK='fujitsu'
WIRELESS_CHANNEL="2"
WIRELESS_NWID=''
WIRELESS_RATE='11M'
BROADCAST="134.102.158.255"
IPADDR='134.102.158.235'
NETMASK='255.255.255.248'
NETWORK='134.102.158.232'
Abbildung B.4: Linux OS - Konfigurationsdatei ifcfg-eth1“
”
Zusätzlich müssen per Kommandozeile weitere Parameter (s. Abbildung B.5) vor dem
Starten des eigentlichen Routingprotokolls eingegeben werden.
linux:~ # echo 1 >/proc/sys/net/ipv4/ip_forward
linux:~ # echo 1 >/proc/sys/net/ipv4/conf/all/accept_source_route
linux:~ # route add 255.255.255.255 <De v ic e >
Abbildung B.5: Linux OS - Zusätzliche Kommandozeilenparameter
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
140
Konfiguration der WLAN-Karte, unter MS Windows
Für die WLAN-Karte wird der entsprechende Treiber installiert und die IPv4-Adressen
werden konfiguriert (s. Abbildung B.6).
Abbildung B.6: MS Windows - Konfiguration der IPv4-Adressen
Nach der Konfiguration der IP-Adressen müssen die drahtlosen Netzeigenschaften konfiguriert werden (s. Abbildung B.7). Zusätzlich wird zur Konfiguration der WLANKarte ein Client Manager“ verwendet (s. Abbildung B.8). Mit Hilfe dieses können
”
verschiedene Einstellungen vorgenommen werden und die entsprechenden Informationen zur verwendeten WLAN-Karte werden dargestellt.
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
Abbildung B.7: MS Windows - Konfiguration der drahtlosen Netzeigenschaften
Abbildung B.8: MS Windows - Client Manager“ der WLAN-Karte
”
141
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
142
Für die WLAN-Karte und das verwendete Netzwerk können Profile angelegt werden,
in denen die wichtigen Einstellungen definiert werden. Die Profile können individuell
erstellt und verwendet werden. Für die verwendeten Geräte werden folgende Parameter
verwendet (s. Abbildung B.9):
• Netzwerkname: test-net“,
”
• Netzwerktype: Peer-to-Peer“-Gruppe,
”
• Kanalnummer: Channel 2“ und
”
• Datensicherheit: deaktiviert.
Abbildung B.9: MS-Windows - Konfigurationsprofil der WLAN-Karte
Um IP-Forwarding“ in MS Windows zu aktivieren, muss der entsprechende Regis”
trierungseintag verändert werden. Folgen Schritte sind erforderlich, um die TCP/IPWeiterleitung zu aktivieren:
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
143
1. Starten des Registrierungseditors ( Regedit.exe“).
”
2. Suchen des folgenden Schlüssels:
HKEY LOCAL M ACHIN E\SY ST EM \CurrentControlSet
”
\Services\T cpip\P arameters“
3. Setzen des Registrierungswertes:
Wertname: IPEnableRouter“
”
Werttyp: REG DWORD“
”
Wert: 1
Der Wert 1 aktiviert die TCP/IP-Weiterleitung für alle Netzwerkverbindungen,
die auf dem jeweiligen Computer installiert sind und verwendet werden.
4. Beenden des Registrierungseditors.
Abbildung B.10: Aktivierung von IP-Forward“ in der Registrierung
”
Um zu gewährleisten, dass andere Teilnehmer des Ad-hoc-Netzes auf die Dienste eines
Rechners zugreifen können, muss die Internetverbindungsfirewall“ deaktiviert werden
”
(s. Abbildung B.11).
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
144
Abbildung B.11: MS Windows - Deaktivierung der Internetverbindungsfirewall“
”
B.2
B.2.1
Verwendete Softwarekomponenten
AODV-UU“ (v0.9)
”
Zur Erstellung und Installation von AODV-UU“ muss der Netfilter Support“ im
”
”
Kernel vorhanden sein. Die folgenden Schritte sind für die erfolgreiche Installation
erforderlich:
1. Das Erstellen: make“.
”
2. Die Installation: make install“.
”
Zur Ausführung von AODV-UU“ muss das Modul kaodv.o“ bzw. kaodv.ko“ geladen
”
”
”
sein.
B.2.2
Windows AODV“ (v0.1.14)
”
Die Installation von Windows AODV“ gestaltet sich sehr einfach und erfolgt in den
”
folgenden Schritten:
1. Ausführen von setup.exe“.
”
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
145
2. Konfiguration der WLAN-Karte.
3. Konfiguration der IP-Adressen.
Für das WLAN-“Interface“ wird ein zusätzlicher Treiber, der AODV Routing Driver“,
”
installiert (s. Abbildung B.12).
Abbildung B.12: Windows AODV“ - AODV Routing Driver“
”
”
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
146
Zur Interoperabilität mit weiteren AODV-Implementierungen muss das Text-File“
”
aodv sign cfg.txt“ mit dem Wert 0“ angelegt werden. Dieses File“ wird dann in
”
”
”
das Installationsverzeichnis von Windows ADOV“ abgespeichert.
”
B.2.3
OLSRD“ (v0.48)
”
Installation unter Linux OS
Zur Erstellung und Installation von OLSRD“ müssen die Development Tools“ in”
”
stalliert sein. Die folgenden Schritte sind erforderlich:
1. Das Erstellen: make OS=linux“.
”
2. Die Installation: make install“.
”
3. Das Löschen der Objekt-Files: make clean“.
”
Vor dem Start von OLSRD“ muss das Config-File“, /etc/olsrd.conf“, bearbeitet und
”
”
”
angepasst werden. In der Abbildung B.13 ist das verwendete Config-File“ olsrd.conf“
”
”
dargestellt. Entsprechende Konfigurationen können innerhalb dieses Files“ vorgenom”
men werden. Die einzelnen Einstellungen sind von den Entwicklern gut erläutert, wurden aber in dieser Darstellung entfernt. Zum Ausführen von OLSRD“ sind Root“”
”
Rechte erforderlich.
Installation unter MS Windows
Die Installation unter MS Windows erfolgt mit Hilfe der ausführbaren Datei,
olsrd.exe“. Vor dem Start muss OLSRD“ konfiguriert werden. Ein entsprechen”
”
des Config-File“ kann angelegt werden (s. Abbildung B.13) oder innerhalb der GUI
”
können die Einstellungen vorgenommen werden.
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
147
DebugLevel 9
IpVersion
4
Hna4
{
# 0.0.0.0 0.0.0.0
}
Hna6
{
# ::
0
}
AllowNoInt yes
#TosValue
16
#Willingness 4
IpcConnect
{
MaxConnections 0
Host
127.0.0.1
#Host
10.0.0.5
#Net
192.168.1.0 255.255.255.0
#Net
10.0.0.0 255.255.255.0
}
UseHysteresis no
HystScaling
0.50
HystThrHigh
0.80
HystThrLow
0.30
#LinkQualityLevel 0
#LinkQualityWinSize 10
Pollrate
0.05
#TcRedundancy
0
#MprCoverage
1
#LoadPlugin "olsrd_dyn_gw.so.0.3"
#{
# Example: dyn_gw params
# PlParam "Interval" "40"
# PlParam "Ping"
"141.1.1.1"
# PlParam "Ping"
"194.25.2.129"
#}
Interface "eth1"
{
# Ip4Broadcast
255.255.255.255
# Ip4Broadcast
10.0.0.255
# Ip6AddrType
site-local
# Ip6MulticastSite
ff05::11
# Ip6MulticastGlobal
ff0e::1
HelloInterval
2.0
HelloValidityTime
6.0
TcInterval
5.0
TcV alidityTime
15.0
MidInterval
5.0
MidValidityTime
15.0
HnaInterval
5.0
HnaValidityTime
15.0
}
Abbildung B.13: OLSRD“ - Config-File“ olsrd.conf“
”
”
”
B.2.4
iPerf“
”
iPerf“ stellt eine Vielzahl von Parametern zur Verfügung, welche per Kommandozeile
”
aufgerufen werden können (s. Abbildung B.14).
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
148
Usage: iperf [-s|-c host] [options]
iperf [-h|--help] [-v|--version]
Client/Server:
-f, --format
-i, --interval
-l, --len
-m, --print_mss
[kmKM] format to report: Kbits, Mbits, KBytes, MBytes
#
seconds between peri odic bandwidt h reports
#[KM] length of bu ffer to rea d or write (default 8 KB)
print TCP maximum segment size (MTU - TCP/IP
header)
-o, --output
<filenam e>output the repor t or error message to this specified fil e
-p, --port
#
server port to listen on/connect to
-u, --udp
use UDP rather than TCP
-w, --window
#[KM] TCP window size (so cket buffer s ize)
-B, --bind
<host> bind to <hos t>, an int erface or m ulticast address
-C, --compatib ility
for use with ol der versions d oes not sent ex tra msgs
-M, --mss
#
set TCP maximum segm ent size (MT U - 40 bytes)
-N, --nodelay
set TCP no delay, disabling Nagle's Algorithm
-V, --IPv6V ersion
Set the domain to IPv6
Server s pecifi c:
-s, --server
-D, --daemon
-R, --remove
Client spe cific:
-b, --bandwidth
-c, --client
-d, --dualtest
-n, --num
-r, --tradeoff
-t, --time
-F, --fileinput
-I, --stdin
-L, --listenpo rt
-P, --parallel
-T, --ttl
Miscellane ous:
-h, --help
-v, --version
run in se rver mod e
run the server as a daemon
remove service in win32
#[KM]
for UDP, band width to se nd at in bi ts/sec
(default 1 Mbit/s ec, implies -u)
<host> run in client mode, connecting to <host>
Do a bidir ectional t est simulta neously
#[KM] number of b ytes to transmit (inst ead of -t)
Do a bidir ectional t est individually
#
time in seconds to transmi t for (d efault 10 secs )
<name> input the data to b e transmitted from a file
input the data to be transmitted from stdin
#
port to recieve bidir ectional tests back on
#
number of pa rallel cli ent threads to run
#
time-to-live, for multicast (default 1)
print this m essage and quit
print versio n informat ion and quit
[KM] Indicates options that supp ort a K or M suffix fo r kilo- or megaThe TCP window size op tion can be se t by th e envir onment variable
TCP_WINDOW_SIZE. M ost other o ptions can be set by an environm ent variable
IPERF_<long option nam e>, such as IPERF_BANDWIDTH.
Report bugs to <[email protected]>
Abbildung B.14: iPerf“ - Parameter
”
In der Abbildung B.15 sind die Kommandozeilenaufrufe vom Client dargestellt. Dieser
beinhaltet:
• die Client-Option und die dazugehörige Adresse des Servers (-c 10.0.0.3),
• die Bindung auf einen Ausgangsnetzadapter (-B 10.0.0.1),
• das Darstellungsintervall der Messwerte (-i 0.5 [sec]),
• die Zeitdauer der Verkehrserzeugung und -messung (-t 3600 [sec]) und
• den Export in eine entsprechende Datei (> test-routing.txt).
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
149
iperf –c 10.0.0.3 –B 10.0.0.1 –i 0.5 –t 3600 > test-routing.txt
Abbildung B.15: iPerf“ - Kommandozeilenaufruf des Clients
”
Die Kommandozeilenaufrufe vom Server, mit der Server-Option (-s) und der Bindung an den überwachten Ausgangsnetzwerkadapter (-B 10.0.0.3) sind in der Abbildung B.16 dargestellt.
iperf –s –B 10.0.0.3
Abbildung B.16: iPerf“ - Kommandozeilenaufruf vom Server
”
B.2.5
FTP
Auf dem Rechner, der als Server agieren soll, muss entsprechend ein FTP-Server installiert und konfiguriert werden. Über die Kommandozeile kann der Client auf den
Server zugreifen und ein entsprechender Datentransfer kann stattfinden. Eine Zusammenstellung der wichtigsten Befehle ist in der Abbildung B.17 zu finden.
ANHANG B. HINWEISE ZUR REALISIERTEN TESTUMGEBUNG
open
user
close
cd
get
put
mkdir
delete
mdelete
rename
Öffnet eine Verbindung zum Server
Definiert den User, der sich einloggen will. Fast
immer kann hier anonymous angegeben werden,
um eine anonyme Verbindung herzustellen. Da
der User in diesem Fall dem Server nicht bekannt
ist, hat er normaleweise auch nicht all Rechte und
kann zum Beispiel nur auf bestimmte
Verzeichnisse zugreifen.
Diese Art der Verbindung wird als Anonymous-ftp
bezeichnet.
Beendet eine Verbindung zum Server.
Wechselt in ein anderes Verzeichnis auf dem ftpServer. Statt "\" wie unter DOS und Windows
wird als Trennzeichen der normale Schrägstrich
"/" (Unix-Konvention) verwendet.
Kopiert eine Datei vom Server auf den lokalen
Rechner.
Kopiert eine Datei vom lokalen Rechner auf den
Server. Funktioniert aber nur, wenn man
Schreibrechte auf dem Server hat. Viele Server
stellen für diese Zweck ein incoming-Verzeichnis
zur Verfügung, in das Dateien abgelegt werden
dürfen.
Erzeugt ein neues Verzeichnis auf dem Server,
analog MkDir unter DOS
Löscht eine Datei auf dem Server.
Löscht mehrere Dateien über eine Maske
Mit dieser Funktion können Sie Dateien und
Verzeichnisse auf dem Server umbenennen.
Abbildung B.17: Wichtige FTP-Befehle
150
ANHANG C. VERÄNDERUNGEN AN DEN SOFTWARETOOLS
151
Anhang C
Veränderungen an den
Softwaretools
C.1
Modifikation von IPTraf“
”
Im Rahmen dieser Arbeit wurden Veränderungen am Source-Code“ vorgenommen,
”
die sich aber nur auf den TCP und UDP Service Monitor“ beschränken. Im Ver”
zeichnis iptraf-2.70/src/“ wurde die Datei ifstafs.c“ angepasst. Neben verschiedenen
”
”
Veränderungen wurde eine Funktion zur Erstellung des Log-Files“ hinzugefügt (s.
”
Abbildung C.1).
Die Funktion write proto“ überprüft im ersten Schritt, ob bereits ein entsprechendes
”
File“ existiert, wenn dies aber nicht der Fall ist, wird das Log-File“ neu erstellt.
”
”
Ist das File“ bereits vorhanden, werden die ermittelten Messwerte an die bereits
”
gespeicherten Daten angehangen. Der Name des Files“ setzt sich aus der Bezeichnung
”
Protocol“ und dem aktuellen Datum zusammen, beispielsweise Protocol20050510“.
”
”
Die Idee ist dabei, dass das File“ bei der Veränderung des Datums neu erstellt wird
”
und somit für jeden Tag ein entsprechendes File“ erstellt wird. In das Log-File“
”
”
werden neben der Startzeit jede Sekunde der abgehende und ankommende Verkehr,
in kbits/s, abgespeichert.
Zur besseren Darstellung der Werte wurden in der Funktion void detstats“ Veränder”
ANHANG C. VERÄNDERUNGEN AN DEN SOFTWARETOOLS
152
void write_proto(float activity_in, float activity_out)
{
FILE *stream_err;
struct tm* tim;
time_t t;
char* f_proto = "Protocol";
char timeIndex[15];
time(&t);
tim = gmtime(&t);
char filename[200];
sprintf(timeIndex,"%i%.2i%.2i%.2i%.2i%.2i",((tim-tm_year)+1900),
((tim->tm_mon)+1),tim->tm_mday,((tim->tm_hour)),
tim-tm_min,tim->tm_sec);
sprintf(filename,"%s%i%.2i%.2i","Protocol",((tim-tm_year)+1900),
((tim->tm_mon)+1),tim->tm_mday);
f_proto = strdup(filename);
if(stream_err = fopen(f_proto,"r"))
{
stream_err = fopen(f_proto,"a+");
fprintf(stream_err,"%s \t%8.3f\t%8.3f\n",timeIndex,activity_in,
activity_out);
fclose(stream_err);
}
else
{
stream_err = fopen(f_proto,"a+");
fprintf(stream_err,"%s \t%8.3f\t%8.3f\n",timeIndex,activity_in,
activity_out);
fclose(stream_err);
}
}
Abbildung C.1: IPTraf“ - Modifikation (1)
”
ungen am Float“-Datentyp vorgenommen. In der Originalimplementierung ist die
”
Anzahl der Nachkommastellen auf eine Stelle beschränkt. Nach den Veränderungen
werden drei Nachkommastellen berücksichtigt. Ebenfalls wird das Intervall für die
Anzeige der Messwerte von 5 s auf 1 s verändert. Innerhalb dieser Funktion wird die
Funktion write proto“ zur Erstellung des Log-Files“ aufgerufen (s. Abbildung C.2).
”
”
Mit Hilfe des Log-Files“ ist eine einfache Auswertung der Messungen möglich.
”
ANHANG C. VERÄNDERUNGEN AN DEN SOFTWARETOOLS
153
void detstats(char *iface, const struct OPTIONS *options, int facilitytime,
struct filterstate *ofilter)
{
int logging = options->logging;
:
:
gettimeofday(&tv, NULL);
now = tv.tv_sec;
unow = tv.tv_sec * 1e+6 + t v.tv_usec;
if (now - starttime >= 1) {
wattrset(statwin, BOXATTR);
:
}
:
spanbr = spanbr_in = spanbr_out = 0;
spanpkt = spanpkt_in = spanpkt_out = 0;
starttime = now;
wattrset(statwin, HIGHATTR);
mvwprintw(statwin, 13, 19, "%8.3f %s/sec", activity,
unitstring);
mvwprintw(statwin, 14, 19, "%8.3f packets/sec", pps);
mvwprintw(statwin, 16, 19, "%8.3f %s/sec", activity_in,
unitstring);
mvwprintw(statwin, 17, 19, "%8.3f packets/sec", pps_in);
mvwprintw(statwin, 19, 19, "%8.3f %s/sec", activity_out,
unitstring);
mvwprintw(statwin, 20, 19, "%8.3f packets/sec", pps_out);
write_proto(activity_in,activity_out);
if (activity > peakactivity)
peakactivity = activity;
:
}
Abbildung C.2: IPTraf“ - Modifikation (2)
”
C.2
Modifikation vom Network Traffic Monitor“
”
Diese Implementierung wurde laute Angaben der Entwickler mit Delphi 4.03“, Del”
”
phi 6.0 Enterprise“ und Delphi 7.0“ erfolgreich getestet. Für die Modifikation stand
”
leider nur Delphi 5.0“ zur Verfügung. Dies führte zu einigen Problemen mit bestimm”
ten Befehlen bzw. Paketen:
• Panel3.Color“,
”
• Panel3.DesignSize“,
”
ANHANG C. VERÄNDERUNGEN AN DEN SOFTWARETOOLS
154
• StaticText1.BevelInner“,
”
• StaticText1.BevelKind“ und
”
• StaticText1.BevelOuter“.
”
Diese werden für die graphische Oberfläche verwendet und deshalb sind entsprechende
Veränderungen erforderlich. Der Menüpunkt About...“ wurde entfernt und die we”
sentlichen Daten, wie Angaben zum Entwickler und der Quelle, sind nun direkt in der
Traffic Monitor“-Oberfläche integriert. Die Orginalimplementierung wurde mit ein
”
Log-File“ ergänzt, was auch eine Anpassung der graphischen Oberfläche erforderte.
”
:
object cbOnTop: TCheckBox
Left = 179
Top = 4
Width = 86
Height = 37
Caption = 'Stay On Top'
TabOrder = 4
OnClick = cbOnTopClick
end
object LogButton: TButton
Left = 304
Top = 8
Width = 105
Height = 25
Caption = 'Start Logging'
TabOrder = 5
OnClick = LogButtonClick
end
object fNameEdit: TEdit
Left = 424
Top = 10
Width = 153
Height = 21
TabOrder = 6
Text = 'test.txt'
End
:
Abbildung C.3: Network Traffic Monitor“ - Modifikation (1)
”
In der Abbildung C.3 sind die zusätzliche Objekt, d.h. der
Logging Button“
”
und das Textfeld, definiert. Diese werden in der Datei NetworkTrafficMoni”
tor/MainFormUnit.dfm“ vereinbart.
Die grundlegenden Funktionen vom Network Traffic Monitor“ sind in der Datei Net”
”
workTrafficMonitor/MainFormUnit.pas“ definiert. Innerhalb dieser Datei werden die
ANHANG C. VERÄNDERUNGEN AN DEN SOFTWARETOOLS
155
erforderlichen Veränderungen zur Erstellung des Log-Files“ vorgenommen. Diese Da”
tei wird mit der Prozedur TMain.LogButtonClick“ ergänzt. In der Abbildung C.4 sind
”
die zusätzliche bzw. veränderte Typen- und Variablendefinitionen dargestellt. Innerhalb der Prozedur TMainForm.LogButtonClick“ ist der gesamte Logging“-Vorgang
”
”
definiert (s. Abbildung C.4) und anhand des Status, den der Logging-Button“ auf”
weist, werden die entsprechenden Optionen ausgeführt.
Nach der Aktivierung des Logging Buttons“ wird das entsprechende Log-File“ er”
”
stellt. In das Log-File“ werden zu Beginn das aktuelle Datum und die Startzeit
”
eingetragen. Danach werden jede Sekunde der abgehende und ankommende Verkehr
in Byte/s abgespeichert. Nach der Deaktivierung des Logging-Buttons“ wird noch
”
einmal der Name des erzeugten Log-Files“ in einem separaten Fenster dargestellt.
”
Der Name des Log-Files“ ist vom Anwender frei wählbar, als Standardname wird
”
test.txt“ verwendet, wenn keine Eingabe bzw. Veränderung erfolgt.
”
Das erzeugte Log-File“ ermöglicht eine einfach Auswertung der Messungen.
”
ANHANG C. VERÄNDERUNGEN AN DEN SOFTWARETOOLS
Type
:
ledStartedAt: TEdit;
ledActiveFor: TEdit;
ledOctInSec: TEdit;
ledPeakINSec: TEdit;
ledAvgINSec: TEdit;
ledTotalIN: TEdit;
ledOctOUTSec: TEdit;
ledPeakOUTSec: TEdit;
ledAvgOUTSec: TEdit;
ledTotalOUT: TEdit;
ledAdapterDescription: TEdit;
ledMACAddress: TEdit;
ledSpeed: TEdit;
LogButton: TButton;
fNameEdit: TEdit;
:
var
MainForm: TMainForm;
ActiveTraffic : TTraffic;
f
: text;
LogFlag
: boolean;
fName
: string = 'test.txt';
count
: integer = 0;
end; (*ClearDisplay*)
:
:
procedure TMainForm.RefreshDisplay;
:
self.ledActiveFor.Text := FriendlyRunningTime;
if LogFlag then
begin
count:=count+1;
writeln(f,IntToStr(count)+#9+IntToStr(InPerSec)+#9+IntToStr(OutPerSec));
end;
StatusText.Caption := GetStatus;
end;//with
end; (*RefreshDisplay*)
:
procedure TMainForm.LogButtonClick(Sender: TObject);
begin
if LogButton.Caption='Start Logging' then
begin
LogButton.Caption:='Stop Logging';
count:=0;
fname:=fNameEdit.text;
AssignFile(f,fName);
rewrite(f);
writeln(f,DateTimeToStr(Time));
writeln(f);
LogFlag:=true;
fNameEdit.Enabled:=false;
end else
begin
LogButton.Caption:='Start Logging';
LogFlag:=false;
CloseFile(f);
fNameEdit.Enabled:=true;
ShowMessage('Data were logged into the file "'+ fname+ '" !');
end
end;
end.
Abbildung C.4: Network Traffic Monitor“ - Modifikation (2)
”
156
ANHANG D. INSTALLATIONSHINWEISE ZU CLICK!“ UND PACMAN“ 157
”
”
Anhang D
Installationshinweise zu Click!“
”
und PACMAN“
”
D.1
Installationshinweise zu Click! Modular Rou”
ter“
Bevor
Click! Modular Router“ verwendet werden kann, müssen entsprechende
”
Veränderungen am Kernel vorgenommen werden. Folgende Schritte sind für die In-
stallation erforderlich:
1. Verwenden eines Vanilla-Kernels“ [25].
”
2. Click Kernel Patch“ installieren:
”
cd /usr/src/linux
patch -p0 -b < CLICKDIR/etc/linux-VERSION-patch
(Dabei ist die Patch-Version abhängig vom verwendeten Kernel.)
3. Konfiguration des neuen Kernels.
Für Click! Modular Router“ sind folgende zusätzliche Kernel-Optionen erfor”
derlich:
• Code maturity level option: Yes
• Processor type and features
ANHANG D. INSTALLATIONSHINWEISE ZU CLICK!“ UND PACMAN“ 158
”
”
– Symmetric multi-processor support: No
• General setup
– Networking support : Yes
– PCI support : Yes
• Networking options
– Netlink device emulation: Yes
• Network device support
– Universal TUN/TAP device driver: Yes
– Ethertap network tap : Yes
– Ethernet (10 or 100 Mbit)
∗ 3COM cards: Yes
∗ Other ISA cards: Yes
– PCMCIA network device support
∗ NE2000 compatible PCMCIA support: No
∗ Aviator/Raytheon 2.4GHz wireless support:No
4. Kompilieren und installieren des neuen Kernels:
make dep
make bzImage (oder make zImage)
make install
make modules
make modules install
5. Anpassen des Bootloaders.
6. Neustart das Systems mit dem neuen Kernel.
7. Kompilieren und installieren von Click!“:
”
rm -f config.cach; ./configure [OPTIONS]
ANHANG D. INSTALLATIONSHINWEISE ZU CLICK!“ UND PACMAN“ 159
”
”
8. Erstellen und installieren der Click!“-Module:
”
qmake install
Die beiden Module linuxmodule/click.o“ und linuxmodule/poclikefs.o“ werden
”
”
erstellt. Diese beiden Module werden in das Verzeichnis CLICKPREFIX/lib“
”
installiert.
9. Installation der beiden Module:
CLICKPREFIX/sbin/click-install ROUTERCONFIGFILE
D.2
Installationshinweise zu PACMAN“
”
Zur Erstellung von PACMAN“ wird make“ verwendet. Es sind die folgenden Kernel”
”
Module, die durch make“ erstellt werden, erforderlich:
”
• kpacman.o“ für Linux 2.4.x bzw.
”
• kpacman.ko“ für Linux 2.6.x.
”
Zusätzlich wird die Kernel-Option Config IP NF QUEUE“ benötigt.
”
Weiterhin sind die entsprechenden Implementierungen von FSR bzw. OLSR erforderlich. In den ersten Test wurden FSR-ATR“ [17] und OLSRD“ [35] verwendet. Es
”
”
ist zu beachten, dass PACMAN“ im Non-Daemon Mode“, d.h. im Vordergrund,
”
”
arbeitet.
ANHANG E. INHALT DES DATENTRÄGERS
160
Anhang E
Inhalt des Datenträgers
Auf dem beigefügten Datenträger befinden sich folgende Dateien und Verzeichnisse:
/Ad-hoc-Netze/
Verzeichnis mit den Softwarekomponenten
für die Ad-hoc-Netze.
/Ad-hoc-Netze/Routingprotokolle/
Verzeichnis mit den Implementierungen
der Routingprotokolle.
/Ad-hoc-Netze/Routingprotokolle(Sim)/
Verzeichnis mit den Implementierungen
der Routingprotokolle, die in den
Simulatoren verwendet werden können.
/Ad-hoc-Netze/Tools/
Verzeichnis mit den Tools für
Ad-hoc-Netze.
/Doc/Studienjahresarbeit.pdf
Diese Arbeit als PDF-File.
/Modifikationen/
Verzeichnis mit den modifizierten
Software-Tools.
/Software-Tools/
Verzeichnis mit allgemeinen
Software-Tools.
ABBILDUNGSVERZEICHNIS
161
Abbildungsverzeichnis
Unicast“ Routingalgoritmen (topologiebasiert) . . . . . . . . . . . . .
”
AODV-Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
10
2.5
DSR - Route Request“ . . . . . . . . . . . . . . . . . . . . . . . . . .
”
DSR - Route Reply“ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
”
PAR - Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6
. . . . . . . . . . . . . . . . . . . . .
14
. . . . . . . . . . . . . . . . . . . . .
15
. . . . . . . . . . . . . . . . . . . . .
16
. . . . . . . . . . . . . . . . . . . . .
17
. . . . . . . . . . . . . . . . . . . . .
18
2.11 FSR - Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.12 OLSR - Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.13 CBRP - Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.14 CEDAR - Route Computation“ . . . . . . . . . . . . . . . . . . . . . .
”
2.15 ZRP - Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.16 Routing auf Grundlage geographischer Informationen . . . . . . . . . .
29
3.1
. . . . . . . . .
52
. . . . . . . . .
53
. . . . . . . . .
54
2.1
2.2
2.3
2.4
RDMAR - Route Discovery“ . .
”
2.7 RDMAR - Route Maintenance“
”
2.8 DSDV - Routingtable“ . . . . .
”
2.9 DSDV - Update Routingtable“ .
”
2.10 CGSR - Beispiel . . . . . . . . . .
9
11
13
27
3.4
Click!“ - Beispiel für ein einfaches Element . . . . . .
”
Click!“ - Einfaches Beispiel eines Click!“ Routers . .
”
”
Click!“ - Beispiel eines konfigurierten Click! Routers“
”
”
WNTE - Beispiel . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . .
56
4.1
Allgemeiner Testaufbau - 1. Phase . . . . . . . . . . . . . . . . . . . . .
64
4.2
Allgemeiner Testaufbau - 2. Phase . . . . . . . . . . . . . . . . . . . . .
64
3.2
3.3
ABBILDUNGSVERZEICHNIS
162
4.3
Allgemeiner Testaufbau - 3. Phase . . . . . . . . . . . . . . . . . . . . .
5.1
. . . .
70
. . . .
71
. . . .
72
. . . .
73
. . . .
74
. . . .
76
. . . .
76
. . . .
77
. . . .
78
. . . .
79
. . . .
79
. . . .
82
5.13 Testaufbau - 2.OG Helmholzbau mit Messpunkten . . . . . . . . . . . .
83
5.14 Testaufbau - Allgemeiner Testplan . . . . . . . . . . . . . . . . . . . . .
84
5.15 Testaufbau - Testplan zur Erfassung der Netzlast . . . . . . . . . . . .
85
5.16 Testdurchführung mit AODV . . . . . . . . . . . . . . . . . . . . . . .
86
5.17 Testdurchführung mit OLSR . . . . . . . . . . . . . . . . . . . . . . . .
87
5.18 Ermittlung der erzeugten Netzlast (1) . . . . . . . . . . . . . . . . . . .
88
5.19 Ermittlung der erzeugten Netzlast (2) . . . . . . . . . . . . . . . . . . .
88
5.20 Messung bei Veränderung der Topologie (1) . . . . . . . . . . . . . . .
89
5.21 Messung bei Veränderung der Topologie (2) . . . . . . . . . . . . . . .
89
5.22 Messungen mit unterschiedlichen Betriebssystemen (1) . . . . . . . . .
90
5.23 Messungen mit unterschiedlichen Betriebssystemen (2) . . . . . . . . .
91
5.24 Messungen mit unterschiedlichen Parameter (1) . . . . . . . . . . . . .
91
5.25 Messungen mit unterschiedlichen Parameter (2) . . . . . . . . . . . . .
92
6.1
Messung mit AODV - Erzeugte Netzlast (Abgehender Verkehr) . . . . .
95
6.2
Messung mit AODV - Erzeugte Netzlast (Ankommender Verkehr) . . .
96
6.3
Messung mit AODV - Erzeugte Netzlast (Gesamtverkehr) . . . . . . . .
96
6.4
Messung mit OLSR - Erzeugte Netzlast (Ankommender Verkehr) . . .
97
Windows AODV“ - Oberfläche . . . . . . . . . . . . . . . . . .
”
5.2 Windows AODV“ - AODV Route Table“ . . . . . . . . . . . .
”
”
5.3 OLSRD“ - Settings“ . . . . . . . . . . . . . . . . . . . . . . .
”
”
5.4 OLSRD“ - Nodes“ . . . . . . . . . . . . . . . . . . . . . . . .
”
”
5.5 OLSRD“ - Routes“ . . . . . . . . . . . . . . . . . . . . . . . .
”
”
5.6 Analyzer“ - Hauptmenü . . . . . . . . . . . . . . . . . . . . .
”
5.7 Analyzer“ - Capture“ . . . . . . . . . . . . . . . . . . . . . . .
”
”
5.8 Network Traffic Monitor“ - Oberfläche . . . . . . . . . . . . . .
”
5.9 Veränderter Network Traffic Monitor“ - Angepasste Oberfläche
”
5.10 IPTraf“ - Menü . . . . . . . . . . . . . . . . . . . . . . . . . .
”
5.11 IPTraf“ - TCP und UDP Service Monitor“ . . . . . . . . . . .
”
”
5.12 Testaufbau - 1.OG Helmholzbau mit Messpunkten . . . . . . . .
65
ABBILDUNGSVERZEICHNIS
163
6.5
Messung mit OLSR - Erzeugte Netzlast (Ankommender Verkehr) . . .
98
6.6
Messung mit OLSR - Erzeugte Netzlast (Gesamtverkehr) . . . . . . . .
98
6.7
Messung mit AODV - Veränderung der Topologie (Gesamtverkehr) . .
99
6.8
Messung mit AODV - Veränderung der Topologie (Abgehender Verkehr) 100
6.9
Messung mit AODV - Veränderung der Topologie (Ankommender Verkehr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.10 Windows AODV-Log-File“ - Starten von Windwos AODV . . . . . . . 101
”
6.11 ‘Windows AODV-Log-File“ - Aufbau einer neuen Route . . . . . . . . 102
6.12 Messung mit OLSR - Veränderung der Topologie (Gesamtverkehr) . . . 103
6.13 Messung mit OLSR - Veränderung der Topologie (Abgehender Verkehr) 104
6.14 Messung mit OLSR - Veränderung der Topologie (Ankommender Verkehr)104
6.15 Messung mit AODV - Mittlere Übertragungsrate (Gesamtverkehr) . . . 106
6.16 Messung mit OLSR - Mittlere Übertragungsrate (Gesamtverkehr) . . . 106
6.17 Messung mit OLSR - Unterschiedliche Betriebssysteme (Gesamtverkehr) 108
6.18 Messung mit OLSR - Unterschiedliche Betriebssysteme (Ankommender
Verkehr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.19 Messung mit OLSR - Unterschiedliche Betriebssysteme (Abgehender
Verkehr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.20 Messung mit OLSR - Unterschiedliche Betriebssysteme, die mittlere
Übertragungsrate (Gesamtverkehr) . . . . . . . . . . . . . . . . . . . . 109
6.21 Messung mit OLSR - Veränderung der Parameter (Gesamtverkehr) . . 111
6.22 Messung mit OLSR - Veränderung der Parameter (Ankommender Verkehr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.23 Messung mit OLSR - Veränderung der Parameter (Abgehender Verkehr) 112
6.24 Messung mit OLSR - Veränderung der Parameter, die mittlere Übertragungsrate (Gesamtverkehr) . . . . . . . . . . . . . . . . . . . . . . . 112
B.1 Linux OS - ifconfig -a“ . . . . . . . . . . . . . . . . . . . . . . . . . . 138
”
B.2 Linux OS - iwconfig“ . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
”
B.3 Linux OS - Konfiguration der ESSID und dem Modus . . . . . . . . . . 139
B.4 Linux OS - Konfigurationsdatei ifcfg-eth1“
”
. . . . . . . . . . . . . . . 139
ABBILDUNGSVERZEICHNIS
164
B.5 Linux OS - Zusätzliche Kommandozeilenparameter . . . . . . . . . . . 139
B.6 MS Windows - Konfiguration der IPv4-Adressen . . . . . . . . . . . . . 140
B.7 MS Windows - Konfiguration der drahtlosen Netzeigenschaften . . . . . 141
B.8 MS Windows - Client Manager“ der WLAN-Karte . . . . . . . . . . . 141
”
B.9 MS Windows - Konfigurationsprofil der WLAN-Karte . . . . . . . . . . 142
B.10 MS Windows - IPEnableRouter“ . . . . . . . . . . . . . . . . .
”
B.11 MS Windows - Deaktivierung der Internetverbindungsfirewall“
”
B.12 Windows AODV“ - AODV Routing Driver“ . . . . . . . . . .
”
”
B.13 OLSRD“ - Config-File“ olsrd.conf“ . . . . . . . . . . . . . . .
”
”
”
B.14 iPerf“ - Parameter . . . . . . . . . . . . . . . . . . . . . . . . .
”
B.15 iPerf“ - Kommandozeilenaufruf vom Client . . . . . . . . . . .
”
B.16 iPerf“ - Kommandozeilenaufruf vom Server . . . . . . . . . . .
”
B.17 Wichtige FTP-Befehle . . . . . . . . . . . . . . . . . . . . . . .
C.1
IPTraf“ - Modifikation (1)
”
C.2 IPTraf“ - Modifikation (2)
”
C.3 Network Traffic Monitor“ ”
C.4 Network Traffic Monitor“ ”
. . . . 143
. . . . 144
. . . . 145
. . . . 147
. . . . 148
. . . . 149
. . . . 149
. . . . 150
. . . . . . . . . . . . . . . . . . . . . . . . 152
. . . . . . . . . . . . . . . . . . . . . . . . 153
Modifikation (1) . . . . . . . . . . . . . . . 154
Modifikation (2) . . . . . . . . . . . . . . . 156
TABELLENVERZEICHNIS
165
Tabellenverzeichnis
2.1
CBRP - Nachbartabelle
. . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.2
Vergleich einzelner Routingverfahren . . . . . . . . . . . . . . . . . . .
31
3.1
Übersicht zu den AODV-Implementierungen (1) . . . . . . . . . . . . .
34
3.2
Übersicht zu den AODV-Implementierungen (2) . . . . . . . . . . . . .
36
3.3
Übersicht zu den AODV-Implementierungen (3) . . . . . . . . . . . . .
38
3.4
AODV-Implementierungen - Aussagen zur Funktionsfähigkeit . . . . . .
39
3.5
Übersicht zu ARAN
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.6
Übersicht zu den DSR-Implementierungen . . . . . . . . . . . . . . . .
42
3.7
DSR-Implementierungen - Aussagen zur Funktionsfähigkeit . . . . . . .
43
3.8
Übersicht zu FSR-ATR“ . . . . . . . . . . . . . . . . . . . . . . . . .
”
Übersicht zu den OLSR-Implementierungen (1) . . . . . . . . . . . . .
44
3.10 Übersicht zu den OLSR-Implementierungen (2) . . . . . . . . . . . . .
46
3.11 Übersicht zu den OLSR-Implementierungen (3) . . . . . . . . . . . . .
48
3.12 Übersicht zu den OLSR-Implementierungen (4) . . . . . . . . . . . . .
49
3.13 OLSR-Implementierungen - Aussagen zur Funktionsfähigkeit . . . . . .
50
3.14 Übersicht zu den Tools für Ad-hoc-Netze (1) . . . . . . . . . . . . . . .
58
3.15 Übersicht zu den Tools für Ad-hoc-Netze (2) . . . . . . . . . . . . . . .
59
3.16 Tools für Ad-hoc-Netze - Aussagen zur Funktionsfähigkeit . . . . . . .
59
5.1
. . . . . . . . . . . . . . . . .
75
. . . . . . . . . . . . . . . . .
77
. . . . . . . . . . . . . . . . .
78
. . . . . . . . . . . . . . . . .
80
3.9
5.2
5.3
5.4
Analyzer“ - Spezifikation . . . . . . . .
”
Network Traffic Monitor“ - Spezifikation
”
IPTraf“ - Spezifikation . . . . . . . . . .
”
iPerf“ - Spezifikation . . . . . . . . . . .
”
45
TABELLENVERZEICHNIS
166
5.5
Testaufbau - IPv4-Adressen der verwendeten Geräte . . . . . . . . . . .
83
5.6
Testaufbau - WLAN-Einstellungen des Testnetzes . . . . . . . . . . . .
84
A.1 Übersicht zu den AODV-Implementierungen (1) . . . . . . . . . . . . . 119
A.2 Übersicht zu den AODV-Implementierungen (2) . . . . . . . . . . . . . 119
A.3 Übersicht zu den AODV-Implementierungen (3) . . . . . . . . . . . . . 120
A.4 Übersicht zu den AODV-Implementierungen (4) . . . . . . . . . . . . . 121
A.5 Übersicht zu den AODV-Implementierungen (5) . . . . . . . . . . . . . 122
A.6 Übersicht zu den AODV-Implementierungen (6) . . . . . . . . . . . . . 123
A.7 Übersicht zu ARAN
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
A.8 Übersicht zu den DSR-Implementierungen (1) . . . . . . . . . . . . . . 125
A.9 Übersicht zu den DSR-Implementierungen (2) . . . . . . . . . . . . . . 126
A.10 Übersicht zu FSR-ATR“ . . . . . . . . . . . . . . . . . . . . . . . . . 127
”
A.11 Übersicht zu den OLSR-Implementierungen (1) . . . . . . . . . . . . . 128
A.12 Übersicht zu den OLSR-Implementierungen (2) . . . . . . . . . . . . . 128
A.13 Übersicht zu den OLSR-Implementierungen (3) . . . . . . . . . . . . . 129
A.14 Übersicht zu den OLSR-Implementierungen (4) . . . . . . . . . . . . . 129
A.15 Übersicht zu den OLSR-Implementierungen (5) . . . . . . . . . . . . . 130
A.16 Übersicht zu den OLSR-Implementierungen (6) . . . . . . . . . . . . . 131
A.17 Übersicht zu den Tools für Ad-hoc-Netze (1) . . . . . . . . . . . . . . . 132
A.18 Übersicht zu den Tools für Ad-hoc-Netze (2) . . . . . . . . . . . . . . . 133
A.19 Übersicht zu den Tools für Ad-hoc-Netze (3) . . . . . . . . . . . . . . . 133
B.1 Laptop-1 - Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . 135
B.2 Laptop-2 - Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . 135
B.3 Laptop-3 - Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . 136
B.4 Arbeitsplatz-PC-1 - Spezifikation . . . . . . . . . . . . . . . . . . . . . 136
B.5
RoamAbout 802.11 DS (Cabletron)“ - Spezifikation . . . . . . . . . . 137
”
ABKÜRZUNGSVERZEICHNIS
Abkürzungsverzeichnis
ABR . . . . . . . . . . . . . Associativity-Based Routing
ACR . . . . . . . . . . . . . Adaptive Communications Researche Laboratories
AODV . . . . . . . . . . . Ad-hoc On-Demand Distance Vector
APE . . . . . . . . . . . . . Ad hoc Protocol Evaluation
API . . . . . . . . . . . . . . Application Programming Interface
ARAN . . . . . . . . . . . Authenticated Routing for Ad hoc Networks
ASL . . . . . . . . . . . . . Ad-hoc Support Library
ASU . . . . . . . . . . . . . Arizona State University
ATR . . . . . . . . . . . . . Advanced Telecommunications Researche
BRP . . . . . . . . . . . . . Bordercast Resolution Protocol
BSD . . . . . . . . . . . . . Berkeley Software Distribution
CA . . . . . . . . . . . . . . Certifcate Authorities
CBRP . . . . . . . . . . . Cluster Based Routing Protocol
CEDAR . . . . . . . . . Core Extraction Distributed Ad hoc Routing
CGSR . . . . . . . . . . . Cluster-Head Gateway Switch Routing
CH . . . . . . . . . . . . . . Cluster Head
CPU . . . . . . . . . . . . . Central Processing Unit
DAG . . . . . . . . . . . . . Directed Acyclic Graph
DNS . . . . . . . . . . . . . Domain Name System
DRP . . . . . . . . . . . . . Dynamic Routing Protocol
DSDV . . . . . . . . . . . Destination-Sequenced Distance-Vector
DSR . . . . . . . . . . . . . Dynamic Source Routing
DST . . . . . . . . . . . . . Destination
167
ABKÜRZUNGSVERZEICHNIS
168
ESSID . . . . . . . . . . . Extended Service Set Identifier
ETX . . . . . . . . . . . . . Expexted Transmission Count
FSR . . . . . . . . . . . . . Fisheye State Routing
FTP . . . . . . . . . . . . . File Transfer Protocol
GPS . . . . . . . . . . . . . Global Positioning System
GRC . . . . . . . . . . . . . Grupo de Investigaciòn de Redes de Computadores
GUI . . . . . . . . . . . . . Graphical User Interface
HNA . . . . . . . . . . . . Host and Network Association
HUT . . . . . . . . . . . . . Helsinki University of Technology
IARP . . . . . . . . . . . . Intrazone Routing Protocol
ID . . . . . . . . . . . . . . . Identifier
IERP . . . . . . . . . . . . Interzone Routing Protocol
IETF . . . . . . . . . . . . Internet Engineering Task Force
Inria . . . . . . . . . . . . . Institut National De Recherche En Informatique Et En
Automatique
IP . . . . . . . . . . . . . . . Internet Protocol
ITU-T . . . . . . . . . . . International
Telecommunication
Union-Telecommunication
Standardization
JAdhoc . . . . . . . . . . Java Ad-hoc
Jpcap . . . . . . . . . . . . Java Package for Packet Capture
JRE . . . . . . . . . . . . . Jave Runtime Enviroment
LAN . . . . . . . . . . . . . Local Area Network
LAR . . . . . . . . . . . . . Location-Aided Routing
LCC . . . . . . . . . . . . . Least Cluster Change
LMR . . . . . . . . . . . . Lightweight Mobile Routing
LORA . . . . . . . . . . . Least Overhead Routing Approach
LRR . . . . . . . . . . . . . Link Reversal Routing
LSU . . . . . . . . . . . . . Link State Update Unit
LUNAR . . . . . . . . . Lightweight Underlay Network Ad-hoc Routing
MAC . . . . . . . . . . . . Media Access Control
MANET . . . . . . . . . Mobile Ad-hoc Network
ABKÜRZUNGSVERZEICHNIS
MAODV . . . . . . . . . Multicast Extensions of AODV
MID . . . . . . . . . . . . . Multiple Interface Declaration
MP . . . . . . . . . . . . . . Messpunkt
MPEG . . . . . . . . . . . Motion Pictures Experts Group
MPR . . . . . . . . . . . . Multipoint Relay
MRL . . . . . . . . . . . . Message Retransmission List
MS . . . . . . . . . . . . . . Microsoft
NetBIOS . . . . . . . . . Network Basic Input Output System
NIST . . . . . . . . . . . . National Institute of Standards and Technology
ns2 . . . . . . . . . . . . . . Network Simulator 2
OLSR . . . . . . . . . . . Optimzed Link State Routing
OLSRD . . . . . . . . . . OLSR Daemon
ORA . . . . . . . . . . . . Optimum Routing Approach
OS . . . . . . . . . . . . . . . Operation System
PACMAN . . . . . . . Passive Autoconfiguration for Mobile Ad hoc Network
PAR . . . . . . . . . . . . . Power-Aware Routing
PC . . . . . . . . . . . . . . Personal Computer
PDA . . . . . . . . . . . . . Personal Digital Assistant
PDAD . . . . . . . . . . . Passive Duplicate Address Detection
PICA . . . . . . . . . . . . Protocol Implementation Specific API
PTP . . . . . . . . . . . . . Peer-to-Peer
PTP . . . . . . . . . . . . . Point-to-Point
pyOLSR . . . . . . . . . Python OLSR
QOLSR . . . . . . . . . . QoS for OLSR
QoS . . . . . . . . . . . . . Quality of Service
RD . . . . . . . . . . . . . . Relative Distance
RDE . . . . . . . . . . . . . Relative Distance Estimation
RDM . . . . . . . . . . . . Relative Distance Micro-discovery
RDMAR . . . . . . . . . Relative Distance Micro-discovery Ad Hoc Routing
RFC . . . . . . . . . . . . . Request for Comments
RREP . . . . . . . . . . . Route Reply
169
ABKÜRZUNGSVERZEICHNIS
RREQ . . . . . . . . . . . Route Request
RT . . . . . . . . . . . . . . Reportable Subtree
RT . . . . . . . . . . . . . . Routing Table
SDK . . . . . . . . . . . . . Software Development Kit
SRC . . . . . . . . . . . . . Source
SRP . . . . . . . . . . . . . Static Routing Protocol
SSH . . . . . . . . . . . . . Secure Shell
SSL . . . . . . . . . . . . . . Secure Socket Layer
SSR . . . . . . . . . . . . . Signal Stability Routing
SST . . . . . . . . . . . . . Signal Stability Table
STAR . . . . . . . . . . . . Source Tree Adaptive Routing
TBRPF . . . . . . . . . . Topology Dissemination Based On Reverse-Path Forwarding
TC . . . . . . . . . . . . . . Topology Control
TCP . . . . . . . . . . . . . Transmission Control Protocol
TORA . . . . . . . . . . . Temporally-Ordered Routing Algorithm
TTL . . . . . . . . . . . . . Time To Life
UCSB . . . . . . . . . . . University of California, Santa Barbara
UDP . . . . . . . . . . . . . User Datagram Protocol
UICU . . . . . . . . . . . . University of Illinois at Urban-Champaign
UoB . . . . . . . . . . . . . University of Bremen
UPV . . . . . . . . . . . . . Universidad Politèchnica de Valencia
UU . . . . . . . . . . . . . . Uppsala University
ViTAN . . . . . . . . . . Visualization Tool for Ad Hoc Networks
WinPcap . . . . . . . . Windows Packet Capture
WLAN . . . . . . . . . . Wireless LAN
WNTE . . . . . . . . . . Wireless Network Topology Emulator
WRP . . . . . . . . . . . . Wireless Routing Protocol
ZRP . . . . . . . . . . . . . Zone Routing Protocol
170
LITERATURVERZEICHNIS
171
Literaturverzeichnis
[fre, ] Freifunk.Net. http://www.freifunk.net/.
[Ampadu and Perkins, 2003] Ampadu, P. and Perkins, C. E. (2003). Highly Dynamic
Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers. ,
http://wisl.ece.cornell.edu/ECE794/Mar5/DSDV.ppt.
[Bahr, 2002] Bahr, F. (2002). Mobile Ad hoc Networking. Technische Universität
Carolo-Wilhelmina Braunschweig, Institut für Betriebssysteme und Rechnerverbund, http://www.ibr.cs.tu-bs.de/lehre/ws0102/svs/bahr-folien.pdf.
[Bornträger, 2002] Bornträger,
C.
(2002).
Ad-hoc-Netzwerke.
Techni-
sche Universität Ilmenau, Fakultät für Elektrotechnik und Informationstechnik,
netze,
Institut
für
Informationstechnik,
Fachgebiet
Kommunikations-
http://zack1.e-technik.tu-ilmenau.de/∼webkn/STUD-DIPLOM/
Hauptseminarreferat/ad-hoc-netze/HS-SS01-AdHocNetze.html.
[Engel and Roth, 2005] Engel, T. and Roth, U. (2005). Ad-Hoc Protocols. Université
du Luxembourg, The SECAN-LAB, http://wiki.uni.lu/secan-lab/Ad-Hoc+
Protocols.html.
[Foetz, 2004] Foetz, L. (2004). Ad-Hoc Workshop 2004 - Lecture 3-Link State Routing,
Distance Vector Routing. University of Luxembourg, The SECAN-LAB, http://
wiki.uni.lu/secan-lab/Ad-Hoc-Workshop2004-L3.pdf.
[Gao, 2003] Gao (2003).
Wireless Routing Protocol — Mobile Ad hoc NETwork
(MANET). Advanced Computer Networks.
LITERATURVERZEICHNIS
172
[IETF, 1985] IETF (1985). RFC959: File Transfer Protocol (FTP). Network Working
Group, http://www.ietf.org/rfc/rfc959.txt.
[IETF, 1998] IETF (1998). The Dynamic Source Routing Protocol for Mobile Ad Hoc
Networks (DSR). IETF MANET Working Group, http://www.monarch.cs.rice.
edu/internet-drafts/draft-ietf-manet-dsr-01.txt.
[IETF, 1999] IETF (1999). The Dynamic Source Routing Protocol for Mobile Ad
Hoc Networks. IETF MANET Working Group, http://monarch.cs.rice.edu/
internet-drafts/draft-ietf-manet-dsr-01.txt.
[IETF, 2000a] IETF (2000a). Internet Draft: Ad hoc On-Demand Distance Vector
(AODV) Routing for IP version6. Mobile Ad Hoc Networking Group, http://www.
tcs.hut.fi/∼anttit/manet/drafts/draft-perkins-aodv6-01.txt.
[IETF, 2000b] IETF (2000b). Internet Draft: Multicast Ad hoc On-Demand Distance
Vector (MAODV) Routing. Mobile Ad Hoc Networking Group, http://www.ietf.
org/proceedings/00jul/I-D/manet-maodv-00.txt.
[IETF, 2000c] IETF (2000c).
tocol.
Internet Draft: Optimized Link State Routing Pro-
Mobile Ad Hoc Networking Group, http://hipercom.inria.fr/olsr/
draft-ietf-manet-olsr-03.txt.
[IETF, 2002a] IETF (2002a).
Fisheye State Routing Protocol (FSR) for Ad Hoc
Networks. IETF MANET Working Group, http://www.ietf.org/proceedings/
02jul/I-D/draft-ietf-manet-fsr-03.txt.
[IETF, 2002b] IETF (2002b). Internet Draft: Ad hoc On-Demand Distance Vector
(AODV) Routing.
Mobile Ad Hoc Networking Group, http://www.ietf.org/
proceedings/02mar/I-D/draft-ietf-manet-aodv-10.txt.
[IETF, 2002c] IETF (2002c). Internet Draft: Ad hoc On-Demand Distance Vector
(AODV) Routing for IP version6. Mobile Ad Hoc Networking Group, http://www.
tcs.hut.fi/∼anttit/manet/drafts/draft-wakikawa-manet-globalv6-02.txt.
LITERATURVERZEICHNIS
173
[IETF, 2002d] IETF (2002d). RFC3280: Internet X.509 Public Key Infrastructure.
Network Working Group, http://www.ietf.org/rfc/rfc3280.txt.
[IETF, 2003a] IETF (2003a). The Dynamic Source Routing Protocol for Mobile Ad
Hoc Networks (DSR). IETF MANET Working Group, http://www.ietf.org/
proceedings/03mar/I-D/draft-ietf-manet-dsr-08.txt.
[IETF, 2003b] IETF (2003b). Internet Draft: Ad hoc On-Demand Distance Vector
(AODV) Routing.
Mobile Ad Hoc Networking Group, http://www.ietf.org/
internet-drafts/draft-ietf-manet-aodv-13.txt.
[IETF, 2003c] IETF (2003c).
tocol.
Internet Draft: Optimized Link State Routing Pro-
Mobile Ad Hoc Networking Group, http://hipercom.inria.fr/olsr/
draft-ietf-manet-olsr-11.txt.
[IETF, 2003d] IETF (2003d).
RFC3561: Ad hoc On-Demand Distance Vector
(AODV) Routing. Network Working Group, http://www.ietf.org/rfc/rfc3561.
txt.
[IETF, 2003e] IETF (2003e).
RFC3626: Optimized Link State Routing Protocol
(OLSR). Network Working Group, http://www.ietf.org/rfc/rfc3626.txt.
[Kasel, 2002] Kasel, M. (2002). Ad ho Netzwerke - Routing Protokolle 2. Institut
Superieur de Technologie, .
[Royer and Toh, 1999] Royer, E. and Toh, C.-K. (1999). A Review of Current Routing
Protocols for Ad Hoc Mobile Wireless Networks. IEEE Personal Communications,
http://www.csie.nctu.edu.tw/∼yctseng/WirelessNet05-02/toh-IEEE-PC.
ppt.
[Schlesser, 2004] Schlesser, A. (2004). Ad-Hoc Workshop 2004 - Lecture 3-Link State
Routing, Distance Vector Routing. University of Luxembourg, The SECAN-LAB,
http://wiki.uni.lu/secan-lab/Ad-Hoc-Workshop2004-L7.pdf.
[Schneider and Werner, 2002] Schneider, U. and Werner, D. (2002). Taschenbuch der
Informatik. Fachbuchverlag Leipzig, 3 edition.
LITERATURVERZEICHNIS
[Thill, 2004] Thill, M. (2004).
Routing.
174
Ad-Hoc Workshop 2004 - Lecture 6-Hierarchical
University of Luxembourg, The SECAN-LAB, http://wiki.uni.lu/
secan-lab/Ad-Hoc-Workshop2004-L6.pdf.
[Tonnesen, 2004] Tonnesen, A. (2004). Impementing and extending the Optimized Link
State Routing Protocol. http://www.olsr.org/docs/report html/.
SOFTWAREVERZEICHNIS
175
Softwareverzeichnis
[1] Ad-hoc Support Library (ASL). http://aslib.sourceforge.net.
[2] Analyzer. http://analyzer.polito.it/.
[3] AODV IPv6. http://members.shaw.ca/aodv6-sfu/.
[4] AODV Kernel. http://w3.antd.nist.gov/wctg/aodv kernel/index.html.
[5] AODV-UCSB. http://moment.cs.ucsb.edu/AODV/aodv.html.
[6] AODV-UIUC. http://aslib.sourceforge.net/.
[7] AODV-UU. http://core.it.uu.se/AdHoc/AodvUUImp.
[8] AODV-UU IPv6. http://webspace.buckingham.ac.uk/cadams/bnrg/aodv6/
index.html.
[9] APE. apetestbed.sourceforge.net/.
[10] ARAN. http://signl.cs.umass.edu/arand/index.php.
[11] Click! Modular Router. http://pdos.csail.mit.edu/click/.
[12] crc-nolsrdv6). http://pf.itd.nrl.navy.mil/project/showfiles.php?group
id=16414&release id=18181.
[13] DSR (Insignia). http://comet.columbia.edu/insignia/testbed.html.
[14] DSR (Monarch). http://www.monarch.cs.rice.edu/dsr-impl.html.
[15] DSR (Piconet). http://piconet.sourceforge.net/thesis/main.html.
SOFTWAREVERZEICHNIS
176
[16] DSR (UC-Boulder-Click!). http://pecolab.colorado.edu/DSR.html.
[17] FSR-ATR. http://www.acr.atr.jp/acr/general/product/GSRFSR/.
[18] Hut AODV for IPv6. http://www.tcs.hut.fi/∼anttit/manet/aodv/.
[19] inria-nolsrd.
http://pf.itd.nrl.navy.mil/project/showfiles.php?group
id=16414&release id=18181.
[20] iperf. http://dast.nlanr.net/Projects/Iperf/.
[21] IPTraf. http://iptraf.seul.org/.
[22] Java 2 SDK. http://java.sun.com/j2se/.
[23] Java Runtime Enviroment. http://java.sun.com/j2se/.
[24] Jpcap. http://jpcap.sourceforge.net/.
[25] Kernel.org. http://www.kernel.org/.
[26] libpcap. http://www.tcpdump.org/.
[27] LUNAR. http://core.it.uu.se/AdHoc/LunarImpl.
[28] MAODV. http://www.isr.umd.edu/CSHCN/research/maodv/MAODV-UMD.html.
[29] Network Simulator - (ns2). http://www.isi.edu/nsnam/ns/.
[30] Network Traffic Monitor. http://delphi.about.com/od/fullcodeprojects/l/
aa112903a.htm.
[31] nOLSR. http://sourceforge.net/projects/nolsr/.
[32] nrlolsrd.
http://pf.itd.nrl.navy.mil/project/showfiles.php?group id=
16414&release id=18367.
[33] OLSR (GRC, UPV). http://www.grc.upv.es/software.
SOFTWAREVERZEICHNIS
[34] OLSR11win (GRC).
177
http://www.grc.upv.es/software/intro OLSR11win.
html.
[35] OLSRD. http://www.olsr.org/index.cgi?action=main.
[36] OLSR EXTRA.
http://pf.itd.nrl.navy.mil/project/showfiles.php?
group id=16414&release id=18367.
[37] OLSRv3 (Inria). http://hipercom.inria.fr/olsr/.
[38] oolsr. http://hipercom.inria.fr/OOLSR/.
[39] PACMAN. http://pacman-autoconf.sourceforge.net/.
[40] PICA. http://pica-api.sourceforge.net/.
[41] PyOLSR. http://hipercom.inria.fr/pyOLSR/.
[42] QOLSR. http://qolsr.lri.fr/.
[43] TinyAODV. http://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-1.x/
contrib/hsn/.
[44] UoB
JAdhoc.
http://www.aodv.org/modules.php?op=modload&name=
UpDownload&file=index&req=viewdownload&cid=2.
[45] ViTAN. http://www.acticom.de/vitan.html.
[46] Windows AODV. http://moment.cs.ucsb.edu/AODV/aodv-windows.html.
[47] WinPcap. http://winpcap.polito.it/.
[48] Wireless Tools. http://www.hpl.hp.com/personal/Jean Tourrilhes/Linux/
Tools.html.
[49] WNTE. http://wnte.sourceforge.net/.