Technische Universität Ilmenau Studienarbeit

Technische Universität Ilmenau
Fakultät für Elektrotechnik und Informationstechnik
Studienarbeit
Multicastrouting in Ad-hoc-Netzwerken
vorgelegt von:
eingereicht am:
Falk Ahlendorf
09. 12. 2008
geboren am:
Studiengang:
Studienrichtung:
Ingenieurinformatik
Informatikkomponenten für
Intelligente Systeme
Anfertigung im Fachgebiet:
Kommunikationsnetze
Fakultät für Elektrotechnik und Informationstechnik
Verantwortlicher Professor:
Wissenschaftlicher Betreuer:
Prof. Dr. rer. nat. habil. Jochen Seitz
Dipl.-Ing. Maik Debes
Kurzfassung
Immer mehr mobile Geräte mit Funknetzwerkfunktionen dominieren den Markt. Diese
Geräte arbeiten meist mit stromsparender Hardware und damit ist ihre Reichweite begrenzt. Auf Grund dessen steigt auch das Interesse Multihop-Kommunikation zwischen
diesen Geräten zu gewährleisten, um die Reichweite der Kommunikation zu vergrößern.
Das Ad hoc On-Demand Distance Vektor Routing (AODV) wurde extra entwickelt,
um in solchen mobilen Netzwerken Unicast- und Multicast-Kommunikation zu ermöglichen.
Diese Arbeit beschäftigt sich speziell mit der Multicasterweiterung des AODVProtokolls. Im Weiteren wird diese Erweiterung mit Hilfe des modularen Routingwerkzeuges Click“ implementiert. Anschließend werden die dabei entstandenen Soft”
waremodule in den Demonstartor für kontextsensitives Routing integriert und auf ihre
Funktionsfähigkeit hin untersucht. Damit schafft diese Arbeit die Grundlage für eine
Multicast-Kommunikation im Demonstartor.
Inhaltsverzeichnis
i
Inhaltsverzeichnis
1 Überblick
1.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen
2.1 Theoretische Grundbegriffe . . . . . . . . . . . . . . . . . . .
2.1.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Kommunikationsformen in einem Netzwerk . . . . . .
2.1.3 Ad-hoc-Netzwerke . . . . . . . . . . . . . . . . . . .
2.2 Die Netzwerkprotokolle . . . . . . . . . . . . . . . . . . . . .
2.2.1 AODV-Protokoll . . . . . . . . . . . . . . . . . . . .
2.2.2 Multicast AODV . . . . . . . . . . . . . . . . . . . .
2.2.2.1 Die Routingtabelle . . . . . . . . . . . . . .
2.2.2.2 RREQ-Nachrichtenformat . . . . . . . . . .
2.2.2.3 Das RREP-Nachrichtenformat . . . . . . . .
2.2.2.4 MACT-Nachricht . . . . . . . . . . . . . . .
2.2.2.5 GRPH-Nachricht . . . . . . . . . . . . . . .
2.2.2.6 Der Group Leader . . . . . . . . . . . . . .
2.2.2.7 Beitreten einer Multicastgruppe . . . . . . .
2.2.2.8 Verlassen einer Multicastgruppe . . . . . . .
2.2.2.9 Netzwerkpartitionierung . . . . . . . . . . .
2.2.2.10 Wiedervereinigung von Netzwerkpartitionen
2.2.2.11 Weiterleiten von Datenpaketen . . . . . . .
3 Implementierung
3.1 Schwachstellen des MAODV Protokoll
3.1.1 Verlorene MACT-Nachrichten .
3.1.2 Asymetrischer Linkausfall . . .
3.1.3
Tote Äste“ . . . . . . . . . . .
”
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
5
6
7
7
8
9
10
13
14
15
17
17
19
20
22
23
.
.
.
.
25
25
25
26
26
Studienarbeit Falk Ahlendorf
Inhaltsverzeichnis
3.2
3.3
3.4
3.5
ii
3.1.4 Lösungsansätze der Probleme . . . . . .
Die verwendete Software . . . . . . . . . . . . .
Die neuen Elemente . . . . . . . . . . . . . . . .
3.3.1 Das Element MulticastRoutingTabelle .
3.3.2 Das Element Multicastactivationmessage
3.3.3 Das Element GroupHello . . . . . . . . .
3.3.4 Das Element Controler . . . . . . . . . .
3.3.5 Das Element Forwarder . . . . . . . . .
Angepasste Elemente . . . . . . . . . . . . . . .
3.4.1 Das Element AODVDestinationClassifier
3.4.2 Das Element AODVKnownClassifier . .
3.4.3 Das Element AODVGenerateRREP . . .
3.4.4 Das Element AODVGenerateRREQ . . .
Anpassungen im Clickroutergraph . . . . . . . .
4 Tests
4.1 Einleitung . . . . . . . . . . . . . . . . . .
4.2 Test der Initialisierungsprozedur . . . . . .
4.3 Multicastbaum Aufbau- und Reperaturtest
4.4 Test des Kontextrouters . . . . . . . . . .
4.5 Nachweis der Multicastkommunikation . .
4.6 Kontextrouter Multicasttest . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
28
28
29
30
32
33
33
34
34
34
34
35
35
.
.
.
.
.
.
37
37
39
40
43
44
47
5 Zusammenfassung und Ausblick
50
A Software und Konfigurationsdateien
A.1 Clickscript des Kontextrouters . . . . . . . . . . . . . . . . . . . . . . .
A.2 Clickscript der Zwischenknoten . . . . . . . . . . . . . . . . . . . . . .
51
51
64
Literaturverzeichnis
70
Abbildungsverzeichnis
72
Tabellenverzeichnis
74
Abkürzungsverzeichnis und Formelzeichen
75
Erklärung
76
Studienarbeit Falk Ahlendorf
1 Überblick
1
1 Überblick
Dieses Kapitel soll dem Leser einen Überblick über das Thema der Arbeit geben. Im
Weiteren wird auf die detaillierte Aufgabenstellung der Studienjahresarbeit genannt.
1.1 Einführung
Die Entwicklung von mobilen Geräten schreitet stetig voran. Es werden immer noch
stromsparendere Komponenten entwickelt. Die Batterien machen den größten Teil des
Gewichtes eines solchen Gerätes aus. Durch die effizienteren Komponenten können auch
kleinere Baterien verwendet werden. Daraus resultiert, dass das Gewicht solcher Geräte
immer stärker abnimmt. Die Leistungsfähigkeit dieser Geräte nimmt hingegen immer
weiter zu. Deshalb werden die Geräte auch immer attraktiver für den Endverbraucher.
Eine Vielzahl dieser Geräte verfügt heutzutage standardmäßig über Bluetooth und
WLAN. Damit einhergehend steigt natürlich auch das Interesse, Kommunikation zwischen den Geräten zu betreiben. Aufgrund ihres mobilen Charakters, ist die Reichweite
der Geräte sehr eingeschränkt. Eine kostengünstig Variante die Reichweite zu erhöhen,
ist ein Ad-Hoc-Netzwerk mit Multihop-Kommunikation. Um für die Weiterleitung der
Datenpakete die richtigen Wege zu finden, benötigt man auch ein speziell angepasstes
Routingverfahren. Das Ad hoc On-Demand Distance Vektor (AODV) Routing (RFC
3561) ist eine mögliche Realisierung eines solchen Routingverfahrens. Es ermögliche
unicast und multicast Routing in einem Ad-hoc-Netzwerk.
Da jeder Knoten in dem Netzwerk die Nachrichten für andere Knoten weiterleiten muss, sollte darauf geachte werden, dass die Kommunikation möglichst effizient
gestaltet wird. Multicast ist eine solche effiziente Möglichkeit, um eine Nachricht an
mehrere Knoten zuzustellen. Deshalb beschäftigt sich diese Arbeit vor allem mit der
Multicasterweiterung des AODV-Protokolls, welche auch als MAODV bezeichnet wird.
Die Protokollerweiterung wird in dieser Arbeit ausführlich erläutert und anschließend
mit Hilfe des Click1 -Routers implementiert. Der letzte Teil der Arbeit beschäftigt sich
anschließend mit dem ausführlichen Test der Protokollerweiterung.
1
Click ist ein am MIT entwickeltes Softwarepaket, zur Programmierung von Netzwerkroutern.
Studienarbeit Falk Ahlendorf
1 Überblick
2
1.2 Aufgabenstellung
Ein Forschungsbereich des Fachgebietes Kommunikationsnetze beschäftigt sich mit der
Untersuchung vermittlungstechnischer Prozesse in Kommunikationsnetzen. Dabei stehen vor allem paketvermittelte Netze im Vordergrund. Es wird nach neuen Wegen
gesucht, die Wegewahl effzienter und an die Bedürfnisse des Nutzers angepasst zu gestalten. Damit dieses Ziel erreicht wird, soll beispielsweise auch der Kontext des Nutzers
in die Routingentscheidung einfließen. Ein Konzept sieht deshalb vor, dass sich innerhalb eines Kommunikationsnetzes spezielle Router - die so genannten Kontextrouter befinden, die Informationen über dort eingebundene kontextsensitive Server enthalten.
Mit diesem Wissen können die Router, dann Diensteanfragen, an den am besten für den
Nutzer geeigneten Server weiterleiten. Zur Untersuchung der Prozesse in einem solchen
Netzwerk wurde der DekoR (Demonstrator für kontextsensitives Routing) entwickelt.
Als Basis dient hier das Routingprotokoll AODV (Ad hoc On-Demand Distance Vector). Dieses Protokoll wurde zwar für das kontextsensitive Routing erweitert, ist aber
auch weiterhin kompatibel zur unmodifizierten Version. Aktuell werden die Kommunikationsprozesse im DekoR mit Hilfe von Uni- und Broadcasts realisiert. Zur Optimierung ist nun in einem nächsten Entwicklungsschritt vorgesehen, die Broadcast- durch
Multicast-Kommunikation zu ersetzen. Hierbei soll mit den Kontextroutern begonnen
werden. Als Arbeitspunkte sind daher anzugehen:
• Einarbeitung
Die komplexe Thematik erfordert eine Einarbeitung in das Konzept des kontextsensitiven Routings, in die DekoR-Umgebung sowie in das AODV (RFC 3561)
und die dazu gehörige Erweiterung zur Unterstützung von Multicasts.
• Konzept
Es ist ein Konzept zu erstellen, das die Funktionen einer Multicast-Umgebung
realisiert. Zu berücksichtigen ist, dass der DekoR sowohl Ad-hoc-Netze als auch
Insfrastrukturnetze unterstützt. Das Konzept muss den aktuellen Standards der
jeweiligen Netzwerke entsprechen.
• Realisierung
Das Konzept ist für den im DekoR eingebundenen Kontextrouter umzusetzen.
Dieser wurde bereits mit dem Softwarewerkzeug Click realisiert und ist entsprechend zu erweitern.
Studienarbeit Falk Ahlendorf
1 Überblick
3
• Verifizieren
Verschiedene Tests sollen die Erweiterungen verifizieren. Dazu sind aussagekräftige Szenarien zu entwickeln und durchzuführen.
Studienarbeit Falk Ahlendorf
2 Grundlagen
4
2 Grundlagen
Dieses Kapitel gibt einen Einblick in die theoretischen Grundlagen der Arbeit. Es
enthält eine Einführung in den Begriff des Multicast-Routings und seine Bedeutung
in Bezug auf Ad-hoc-Netzwerke. Im Weiteren folgt dann eine Erläuterung über die
Funktionsweise des MAODV Protokolls.
2.1 Theoretische Grundbegriffe
2.1.1 Routing
Wie in [Wiki08f] nachzulesen ist, kommt der Begriff des Routings aus dem Englischen und bedeutet Lotsen“, Wegewahl“ oder auch Verkehrslenkung“. Das Routing
”
”
”
in paketvermittelten Netzwerken ist dafür verantwortlich, dass die Pakete einen Weg
von Sender zum Empfänger finden. Dazu müssen sie meist von anderen Teilnehmern
des Netzes weitergeleitet werden. Damit die Datenpakete am Empfänger ankommen,
müssen die beteiligten Netzteilnehmern den Weg zum Ziel kennen. Die so genannten
Routen bezeichnen dabei die möglichen Wege, die ein Paket durch ein Netzwerk nehmen kann. Es ist möglich, diese Routen manuell festzulegen. Die so festgelegten Wege
werden als statisches Routen bezeichnet. In Netzwerken bei denen es schnell zu Änderungen kommen kann, ist dies allerdings mit einem hohen Aufwand verbunden. Für
solche Netzwerke gibt es Algorithmen, die die bestmögliche Route zu finden versuchen.
Die so festgelegten Routen werden als dynamische Routen bezeichnet.
Damit die Routen zwischen den Knoten1 nicht bei jedem eintreffenden Paket neu
ermittelt werden müssen, werden diese in einer Routingtabelle im Knoten abgelegt.
Der Knoten muss dann bei einem eintreffenden Paket nur noch in der entsprechenden
Tabelle nachschlagen, an welchen nächsten Knoten das Paket weitergeleitet werden
soll.
1
Ein Knoten ist ein Teilnehmer eines Netzwerkes.
Studienarbeit Falk Ahlendorf
2 Grundlagen
5
2.1.2 Kommunikationsformen in einem Netzwerk
In einem Netzwerk gibt es verschiedene Möglichkeiten Pakete auszuliefern und zu verteilen.
1. Unicast bezeichnet dabei das Zustellen der Nachricht an einen ausgewählten
Knoten im Netzwerk, wie in [Wiki08g] nachzulesen ist. Bei dieser Kommunikationsform komuniziert ein Sender mit genau einem Empfänger.
2. Broadcast beschreibt nach [Wiki08c] die Möglichkeit, an alle Knoten im Netzwerk
eine Nachricht zu schicken. Bei dieser Kommunikationsform stehen einem Sender
viele Empfänger gegenüber.
3. Multicast ist die Möglichkeit, eine Nachricht nur an eine ausgewählte Gruppe in
einem Netzwerk zuzustellen. Nachzulesen ist dies in [Wiki08e]. Es gibt bei dieser
Kommunikationsform wieder nur einen Sender aber eine Gruppe von Empfängern.
4. Anycast ist eine Auslieferungsmethode, bei der ein Paket an einen beliebigen
Knoten aus einer Gruppe von möglichen Knoten zugestellt wird. Typischerweise wird der dem Senderknoten am nächsten liegende Knoten gewählt. Wie in
[Wiki08b] dargelegt ist, gibt es wieder nur einen möglichen Sender aber eine
Gruppe von potentiellen Empfängern.
Bei Multicast werden Datenpakete nicht durch den Absender mehrfach verschickt,
sondern alle Empfänger werden mit einmal addressiert. Unterstützt das zugrundeliegende Netzwerk Multicast, wird die Vervielfachung der Datenpakete meist im Netzwerk
vorgenommen(siehe [Wiki08e]). Damit ist Multicast ein sehr effizienter Weg, um die
gleichen Datenpakete an verschiedene Empfänger zu senden. Vor allem bei Netzwerken,
bei denen auf Übertragungsbandbreite geachtet werden muss.
In Ad-Hoc-Netzwerken kommt dem Multicast außerdem noch eine besondere Bedeutung zu. Es wird dazu genutzt, um ein Netzwerk zu fluten. Das heißt, dass eine
Nachricht an alle Knoten in einem Netzwerk zugestellt werden soll. In einem normalen Netzwerk kann das mit Hilfe der limited broadcast“-Adresse passieren oder aber
”
mit der directed broadcast“-Adresse. In einem Ad-hoc-Netzwerk geht dies aber nicht.
”
Wie in [Bake95] erläutert ist, darf die limited broadcast“ Adresse nicht geroutet wer”
den. Daher erreicht man mit ihr lediglich seine Nachbarn. Für die directed broadcast“
”
Adresse wird einen Routingpräfix benötigen. Aus [PeBRD01] ist zu entnehmen, dass
dieser in einem Ad-Hoc-Netzwerk nicht ausgewählt werden kann.
Studienarbeit Falk Ahlendorf
2 Grundlagen
6
Der DekoR verwendet für das bekanntmachen und auffinden von Kontextroutern
ICMP-Advertisements und ICMP-Solicitation Nachrichten, nachzulesen in [Debe07].
Diese Nachrichten werden per Broadcast versendet und unterliegen deshalb den oben
bereits genannten Restriktionen. Diese Einschränkungen könnten umgangen werden,
wenn die ICMP-Advertisements und die ICMP-Solicitations nicht mehr per Brodacst
sondern per Multicast versendet werden würden.
2.1.3 Ad-hoc-Netzwerke
Laut [Wiki08a] ist, dass Ad-hoc eine lateinische Bezeichnung ist und soviel bedeute wie für diesen Augenblick gemacht“. Bei Ad-hoc-Netzwerken handelt es sich um
”
Funknetze, die aus mindestens zwei Endgeräten (auch als Netzwerkknoten bezeichnet)
bestehen. Verwendung findet diese Art von Netzwerken immer dann, wenn man mobile Geräte wie Mobieltelefone, PDA’s oder aber auch Notebooks ohne einen zentralen
Zugangspunkt miteinander verbinden will. Dabei gewinnt vor allem die Klasse der
mobilen Ad-hoc-Netze immer mehr an Einfluss. Als mobile Ad-hoc-Netzwerke werden
nach [Wiki08d] Ad-hoc-Netzwerke bezeichnet, welche aus mobilen Knoten bestehen,
die in der Lage sind sich selbstständig zu konfigurieren und ein Ad-hoc-Netzwerke
aufzubauen.
In einem Ad-hoc-Netzwerk wird zwischen zwei Verbindungsmöglichkeiten der Knoten unterschieden. Dies ist zum einen die direkte Verbindung, bei der sich der Start und
Ziel Knoten einer Kommunikation direkt erreichen können. Zum anderen gibt es noch
die indirekte Verbindung. Dabei können zwei Knoten nur Nachrichten austauschen,
wenn diese über Zwischenknoten weitergeleitet werden. Damit dies funktioniert, muss
jeder Knoten in einem Ad-hoc-Netzwerk neben seiner Funktion als Endgerät auch immer die Funktion eines Routers übernehmen.
Hinzu kommt noch, dass sich die Knoten in einem solchen Netzwerk bewegen können. Das führt dazu, dass auch die Wege, welche Datenpakete durch ein solches Netzwerk nehmen, ständigen Änderungen unterworfen sind. Um in einem solchen Netzwerk
Nachrichten austauschen zu können, benötigt man ein speziell angepasstes Routingverfahren. Diese müssen möglichst schnell auf Änderungen reagieren und die Netzwerkknoten dabei aber nicht übermäßig stark belasten. Das AODV-Protokoll ist eine
mögliche Realisierung eines solchen Routingprotokolls.
Studienarbeit Falk Ahlendorf
2 Grundlagen
7
2.2 Die Netzwerkprotokolle
2.2.1 AODV-Protokoll
Das AODV-Protokoll ist ein Verfahren, welches die Kommunikation von mobilen Knoten in einem Ad-hoc-Netzwerk ermöglicht. AODV übernimmt dabei in einem Netzwerk
das Finden und Erhalten von Routen. Ist erst einmal ein Weg durch ein Netzwerk gefunden, so spielt AODV bei der Übertragung der Datenpakete keine Rolle mehr. Die
Wege durch ein Netzwerk werden dann ermittelt, wenn sie benötigt werden. Dabei wird
mit Hilfe von Sequenznummern sichergestellt, dass die gefundenen Wege schleifenfrei
sind.
Das Protokoll wurde bereits 1997 von Charles Perkins, Elizabeth M Royer und Samir Ranjan Das entwickelt und im Juli 2003 als RFC 3561 [PeBRD03] verabschiedet.
Bei der Entwicklung dieses Protokolls wurde von vornherein darauf geachtet, dass es
sich durch geringe Netzwerkbelastung und niedrigen Speicherverbrauch in den Netzwerkknoten auszeichnet. Damit eignet sich dieses Routingprotokoll hervorragend für
kleine mobile Geräte, die meist keine große Leistungsfähigkeit besitzen.
Die Kontrollinformationen werden zwischen den Knoten mit Hilfe des User Data”
gram Protocol“ (UDP) und dem Internet Protokoll“ (IP) ausgetauscht. Das AODV”
Protokoll definiert dafür vier verschiedene, Nachrichtentypen die die Knoten untereinander austauschen können:
• Route Request (RREQ)
• Route Reply (RREP)
• Route Error (RERR)
• Reply Acknowledgement (RREP-ACK)
Sucht ein Knoten einen Weg durch das Netzwerk, schickt er ein RREQ mit seinem
gewünschten Ziel an seine Nachbarn. Können die Nachbarn diese Anfrage nicht beantworten, so leiten sie das RREQ wiederum an ihre Nachbarn weiter. Dies wird so lange
wiederholt, bis das RREQ einen oder mehre Knoten erreicht, die die Anfrage beantworten können. Diese beantworten die Anfrage mit einem RREP und schicken es auf
dem Weg des RREQ zurück. Beim Versenden und Empfangen der beiden Nachrichten,
aktualisieren die Knoten ihre Routingtabellen und erzeugen somit einen Weg durch
das Netzwerk.
Studienarbeit Falk Ahlendorf
2 Grundlagen
8
Fällt in dem Netzwerk eine Verbindung zwischen zwei Knoten aus, wird dies mit
Hilfe der RERR-Nachricht den Nachbarn mitgeteilt. Somit wissen diese Knoten, dass
sie einen neuen Weg suchen müssen, wenn sie Daten an einen Knoten hinter der Ausfallstelle senden wollen.
Ein Nachteil dieses Protokolls ist, dass es nicht in der Lage ist, fehlerhaft funktionierende Knoten zu erkennen. AODV geht davon aus, dass allen Knoten zu jedem Zeitpunkt vertraut werden kann. Wie in [NiSu05] gezeigt wird, ist es nicht sehr aufwendig
mit Hilfe eines manipulierten Knotens Verbindungen umzuleiten und abzuhören oder
die Kommunikation im Netz ganz und gar zu stören.
2.2.2 Multicast AODV
1999 stellten Elizabeth M. Royer und Charles E. Perkins in ihrem Paper Multicast
”
operation of the Ad-hoc On-Demand Distance Vektor Routing Protocol“ [RoPe99] die
Multicast-Funktionalität des AODV-Protokolls vor (auch Multicast AODV gennant
oder kurz MAODV). Dabei wurde die Multicast-Funktionalität nicht auf das Protokoll
aufgesetzt, sondern in dieses integriert. Damit kann ein Knoten, der auf der Suche
nach einer Multicastgruppe ist, nicht nur einen Weg zu dieser finden, sondern er kann
auch seine Unicast-Routingtabelle um zusätzliche Routen erweitern. Das Gleiche gilt
natürlich auch umgekehrt. Dadurch kann die zusätzliche Netzwerkbelastung gering
gehalten werden, was vor allem bei mobilen Geräten wichtig ist.
MAODV organisiert alle Knoten einer Multicastgruppe in einer Baumstruktur, allerdings besitzt kein Knoten aus dem Baum Wissen über alle Teilnehmer der Gruppe.
Die Wurzel dieses Baums bildet der so genannte Group Leader“. Dieser wird wie jeder
”
andere Knoten in dem Baum behandelt. Er hat lediglich ein paar Sonderrecht und
Pflichten (Siehe 2.2.2.6), kann aber jeder Zeit, durch einen anderen Knoten aus dem
Multicastbaum abgelöst werden. Damit gibt es bei diesem Protokoll keinen single
”
point of failure“.
Wie auch schon AODV ist MAODV ein reaktives Protokoll. Solange alle Mitglieder
einer Gruppe in dem Multicastbaum verbunden sind, spielt das Protokoll keine Rolle.
Es tritt nur zu Tage, wenn ein Knoten einer Gruppe beitreten will, sie verlassen möchte
oder es zu Störungen im Multicastbaum kommt.
Um Wege zu einem Multicastbaum zu finden oder zu reparieren nutzt MAODV die
bereits im AODV-Protokoll vorhandenen Nachrichtentypen RREQ und RREP. Diese
wurden um ein paar Flags erweitert. Außerdem definiert das Protokoll drei Erweiterungen für diese Nachrichten, um die nötigen Zusatzinformationen transportieren zu
Studienarbeit Falk Ahlendorf
2 Grundlagen
9
können.
Des Weiteren werden, neben den vier bereits im AODV Protokoll vorhandenen Nachrichtentypen, zwei neue Nachrichtenformate definiert. Das ist die Multicast Activation
”
Message“ (MACT)-Nachricht und die Group Hello“(GRPH)-Nachricht.
”
Die Nachteile des MAODV-Protokolls sind zum einen, dass jeder Knoten in dem Adhoc-Netzwerk das MAODV-Protokoll unterstützen muss, da es sonst zu Fehlfunktionen
kommen kann. Dies liegt daran, dass die nicht-MAODV-fähigen-Knoten die MACTund GRPH-Nachrichten nicht interpretieren können und sie deshalb verwerfen. Zum
anderen vertraut MAODV, wie auch schon AODV, jedem Knoten in dem Netzwerk.
Hinzu kommt noch, dass keine Zugangsbeschränkungen für Gruppen angelegt werden
können. So kann jeder Knoten, auch Knoten die nicht im Multicastbaum sind, jederzeit
Nachrichten an die Multicastgruppe versenden.
2.2.2.1 Die Routingtabelle
Neben der normalen AODV-Routingtabelle, wie sie in RFC 3561 [PeBRD03] spezifiziert ist, hat jeder MAODV-fähige-Knoten noch eine Multicastroutingtabelle. Für jede
Multicastgruppe, der ein Knoten angehöhrt, sollten die folgenden Informationen in der
Tabelle enthalten sein:
• Die IP-Adresse der Multicastgruppe
• Die IP-Adresse des Group Leader“
”
• Die Sequenznummer der Gruppe
• Eine Liste mit den nächsten Hops im Multicastbaum
• Anzahl der Hops zum nächsten Gruppenmitglied
• Anzahl der Hops zum Group Leader“
”
In der Liste der nächsten Hops müssen die folgenden Informationen für jeden Hop
gespeichert werden:
• IP-Adresse des nächsten Hops
• Zugehöriges Netzwerkinterface
• Richtung des Links
• Ob diese Route aktiv oder nicht aktiv ist
Studienarbeit Falk Ahlendorf
2 Grundlagen
10
Die Richtung des Links kann zwei Werte annehmen. UPSTREAM bedeutet dabei,
dass der Link in Richtung der Wurzel“ des Baumes geht. DOWNSTREAM hingegen
”
heißt, dass der Link in Richtung der Blätter“ zeigt. Es kann dabei in der Liste belie”
big viele Links mit der Richtung DOWNSTREAM geben. Die Richtung UPSTREAM
hingegen darf höchstens einmal vorkommen. Des Weiteren gilt, solange wie eine Route
nicht aktiviert wurde, dürfen keine Multicastpakete an den angegebenen Hop weitergeleitet werden.
Optional zur Multicastroutingtabelle kann ein Knoten eine Group Leader Tabelle“
”
mit führen. In dieser Tabelle speichert der Knoten die ihm bekannten Group Leader“
”
und Multicastgruppen. Dies ermöglicht dem Knoten später schneller einer Gruppe
beizutreten, in dem er sein RREQ direkt an den Group Leader“ richtet.
”
2.2.2.2 RREQ-Nachrichtenformat
Wie in Abbildung 2.1 zu sehen, wurde das Format der RREQ-Nachrichten, wie in
RFC 3561 [PeBRD03] angegeben, beinehalten. Lediglich zwei Flags sind bei MAODV
genauer spezifiziert worden.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|J|R|G|
Reserved
|
Hop Count
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Other fields as specified for AODV.......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
J Das Join-Flag wird dazu genutzt, um anzugeben, ob ein Knoten einer Multicastgruppe beitreten möchte. Ist das Flag nicht gesetzt, so sucht der Knoten lediglich
einen Weg zum Multicastbaum, möchte diesem aber nicht beitreten.
R Das Repair -Flag wird nur gesetzt, wenn durch das RREQ zwei separate Multicastbäume miteinander verbunden werden sollen.
Abbildung 2.1: RREQ-Nachricht [RoPe00]
Hinzu kommt beim RREQ noch, dass in MAODV zwei neue Erweiterungen für dieses
Nachrichtenformat definiert wurden. Zum einen ist das die Multicast Groub Rebuild“”
Erweiterung, welche genutzt wird, wenn ein Pfad im Multicastbaum repariert werden
soll. Mit ihr kann sichergestellt werden, dass nur Knoten auf die Anfrage antworten,
Studienarbeit Falk Ahlendorf
2 Grundlagen
11
welche näher am Group Leader“ sind, als der Knoten der versucht, den Multicastbaum
”
zu reparieren. Ihr Aufbau ist der Abbildung 2.2 zu entnehmen.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Length
|
Multicast Group Hop Count
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Der Typ der Extension ist 4
Length Die Länge ist 2
Multicast Group Hop Count Dieses Feld gibt an, wie weit entfernt der sendende
Knoten vom Group Leader der Multicastgruppe ist.
Abbildung 2.2: Rebuild-Erweiterung [RoPe00]
Die andere Erweiterung ist die Multicast Group Leader“-Erweiterung. Diese ermög”
licht es RREQ-Nachrichten speziell an den Group Leader“ zu senden. Das ist vor allem
”
beim Verbinden von zwei getrennten Multicastbäumen notwendig. Die Abbildung 2.3
zeigt den Aufbau der Erweiterung.
Studienarbeit Falk Ahlendorf
2 Grundlagen
12
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Length
| Multicast Group Leader IP ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
... Address (continued)
| Previous Hop IP Address ...
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
... (continued)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Diese Extension hat den Typ 3
Length Die Länge der Extension ist 8
Multicast Group Leader IP Address Dieses Feld gibt die IP-Adresse des Group
”
Leaders“ an, an den die Nachricht zugestellt werden soll.
Previous Hop IP Address Das Feld wird von jedem Knoten, der dieses RREQ weiterleitet aktualisiert. Damit enthält es immer die IP-Addresse des vorausgegangen
Knotens. Es hat allerdings nur Bedeutung, wenn der erste Knoten das RREQ
ausgesendet hat, um dem Multicastbaum beizutreten.
Abbildung 2.3: Group Leader“-Erweiterung [RoPe00]
”
Studienarbeit Falk Ahlendorf
2 Grundlagen
13
2.2.2.3 Das RREP-Nachrichtenformat
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|R|
Reserved
|Prefix Sz|
Hop Count
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Other fields as specified for AODV.......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R Das Repair-Flag wird nur gesetzt, wenn der Knoten auf ein RREQ Antwortet bei
dem auch das Flag gesetzt war.
Abbildung 2.4: RREP-Nachricht [RoPe00]
Bei der RREP-Nachricht, in Abbildung 2.4 zu sehen, wurde das Repair -Flag genauer
spezifiziert. Alle anderen Felder haben die gleiche Bedeutung, die man der RFC 3561
[PeBRD03] entnehmen kann. Wird das RREP an eine Multicastgruppe gerichtet, so
muss außerdem noch die Multicastgroup Information“-Erweiterung angehängt werden.
”
Wie die Erweiterung aufgebaut ist, kann der Abbildung 2.5 entnommen werden.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Length
|
Multicast Group Hop Count
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Multicast Group Leader IP Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Diese Extension hat den Typ 5
Length Die Länge der Extension ist 6
Multicast Group Hop Count In diesem Feld speichert der antwortende Knoten seine
Entfernung von Group Leader. Jeder Knoten der das RREP weiterleitet, erhöht
den Wert in diesem Feld um eins.
Multicast Group Leader IP Addresse Die IP Adresse das aktuellen Group Leaders
wird vom antwortenden Knoten in diesem Feld gespeichert.
Abbildung 2.5: Informations-Erweiterung [RoPe00]
Studienarbeit Falk Ahlendorf
2 Grundlagen
14
2.2.2.4 MACT-Nachricht
Die MACT-Nachricht ist eine der zwei neuen Nachrichten, die mit dem MAODV Protokoll eingeführt worden sind. Die Aufgabe der MACT-Nachricht ist es, Veränderungen
am Multicastbaum vorzunehmen. So ist es mit Hilfe dieser Nachricht zum Beispiel
möglich, Wege im Multicastbaum zu aktivieren oder zu deaktivieren. Aber auch das
Bestimmen eines neuen Group Leaders“ kann mit dieser Nachricht durchgeführt wer”
den. Ihren Aufbau ist in der Abbildung 2.6 zu sehen.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|J|P|G|U|R|
Reserved
|
Hop Count
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Multicast Group IP address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source IP address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Abbildung 2.6: MACT-Nachricht [RoPe00]
Type Das Type-Feld dieser Nachricht hat den Wert 5.
J Das Join-Flag wird gesetzt, wenn ein Knoten einem Baum beitreten und er einen
Link zum Baum aktivieren möchte.
P Das Prune-Flag bewirkt das Gegenteil zum Join Flag. Mit seiner Hilfe wird ein Link
zum Multicastbaum deaktiviert. Allerdings darf ein Knoten eine solche Nachricht
erst schicken, wenn er selber die Multicastnachrichten nicht mehr weiterleiten
muss.
G Das Group Leader -Flag zeigt an, dass der nächste Knoten im Multicastbaum, der
ein Gruppenmitglied ist, Group Leader werden soll.
U Mit Hilfe des Update-Flags wird angezeigt, dass sich die Entfernung zum Group
Leader geändert hat. Die neue Entfernung zum Group Leader wird dann aus
dem Hop Count Feld entnommen und in der Routingtabelle gespeichert.
Studienarbeit Falk Ahlendorf
2 Grundlagen
15
R Mit Hilfe des Reboot-Flags zeigt ein Knoten an, dass er gerade neu gestartet wurde.
Das bedeutet, dass dieser Knoten keinerlei Multicastroutinginformationen mehr
besitzt. Damit sind alle Multicastrouten, die möglicherweise über ihn gelaufen
sind, ungültig und müssen repariert werden.
Reserved Dieses Feld kann für spätere Erweiterungen genutzt werden. Es wird immer
als 0 gesendet und beim Empfang ignoriert.
Hop Count Ist das Update Flag gesetzt, so wird in diesem Feld die neue Entfernung
zum Group Leader gespeichert. Ansonsten wird dieses Feld immer mit dem Wert
0 gesendet.
Multicast Group IP Address Die IP-Adresse der Multicastgruppe wird hier abgelegt.
Mit dieser ist es möglich, die Nachricht einer bestimmten Multicastgruppe zuzuordnen.
Source IP Address Diese IP-Adresse identifiziert den Absender der MACT-Nachricht.
Source Sequenz Number Mit Hilfe der Sequenznummer des Absenders kann überprüft werden, ob die Nachricht aktuell ist oder nicht.
2.2.2.5 GRPH-Nachricht
Die GRPH-Nachricht, in Abbildung 2.7 zu sehen, ist der zweite neue Nachrichtentyp,
der mit dem MAODV-Protokoll eingeführt wurde. Seine Aufgabe besteht darin, die
Multicastgruppe im Netzwerk bekannt zu machen. Die Bedeutung der Felder in diesen
Nachrichtentyp kann der folgenden Auflistung entnommen werden.
Type Der Type der Nachricht ist 6
U Das Update-Flag gibt an, dass sich etwas an den Group Leader Informationen geändert hat. Ist dieses Flag gesetzt, aktualisieren alle Knoten des Multicastbaums
die dieses Nachricht empfangen, ihre entsprechenden Routingtabelleneinträge.
M Das Off Mtree-Flag gibt an, dass die GRPH-Nachricht den Multicastbaum verlassen hat. Das wiederum heißt, dass das Hop Count Feld nicht genutzt werden
kann, um die Entfernung zum Group Leader zu aktualisieren.
Studienarbeit Falk Ahlendorf
2 Grundlagen
16
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|U|M|
Reserved
|
Hop Count
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Group Leader IP address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Multicast Group IP address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Multicast Group Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Abbildung 2.7: GRPH-Nachricht [RoPe00]
Reserved Dieses Feld ist für spätere Erweiterungen reserviert. Es wird immer als 0
gesendet und beim Empfang ignoriert.
Hop Count Das Hop Count“-Feld gibt die Anzahl der Hops an, die eine Group
”
”
Hello“-Nachricht vom Group Leader“ bis zum empfangenden Knoten zurückge”
legt hat. Wenn das Off Mtree-Flag nicht gesetzt ist, kann der Knoten dieses Feld
nutzen, um seine Routingtabelle zu aktualisieren.
Group Leader IP Address Der Group Leader“ trägt seine IP-Addresse in dieses Feld
”
ein. Ist das Update-Flag gesetzt, wird der Inhalt dieses Feldes in die Routingtabelle des Knoten übernommen. Jeder Knoten überprüft beim Empfangen der
GRPH-Nachricht dieses Feld. Unterscheidet sich das Feld von seiner Aufzeichnung, ist das ein Hinweis dafür, dass sich zwei Group Leader für eine Multicastgruppe im Netzwerk befinden. Der Group Leader mit der kleineren IP-Addresse
ist in dem Fall für die Reparatur zuständig. Ist in der GRPH-Nachricht die
IP-Addresse des Group Leaders größer als die IP-Addresse, die der Knoten in
seiner Aufzeichnung hat, leitet er die Nachricht weiter. Ist die IP-Addresse in der
GRPH-Nachricht hingegen kleiner, kann er diese Nachricht verwerfen, da sein
Group Leader nicht für die Reparatur zuständig ist.
Multicast Group IP Address Die IP-Addresse der Multicastgruppe für die dieses
GRPH-Nachricht bestimmt ist, steht in diesem Feld.
Multicast Group Sequence Number Die aktuelle Sequenznummer der Gruppe steht
in diesem Feld.
Studienarbeit Falk Ahlendorf
2 Grundlagen
17
2.2.2.6 Der Group Leader
Der Group Leader“ ist die Wurzel eines Multicastbaums. Innerhalb eines verbundenen
”
Netzwerkes darf es für jede Multicastgruppe immer nur einen Group Leader“ geben.
”
Dies wird mit Hilfe von Mechanismen im MAODV-Protokoll sichergestellt.
Es gibt zwei Wege auf denen ein Knoten Group Leader“ werden kann. Zum einen
”
wird ein Knoten Group Leader“, wenn er als erster Knoten im Netzwerk versucht einer
”
Multicastgruppe beizutreten, die noch nicht existiert. Zum anderen kann ein Knoten
aber auch im Falle einer Netzwerkpartitionierung zum Group Leader“ werden (siehe
”
Kapitel 2.2.2.9).
Ist ein Knoten zum Group Leader“ ausgewählt worden, so hat dieser Knoten ein
”
paar Sonderrechte und Pflichten gegenüber einem normalen Knoten, die im Folgenden
kurz erläutert werden sollen:
• Der Group Leader“ darf immer auf RREQs, die an seine Gruppe gerichtet sind,
”
antworten.
• Der Group Leader“ darf als einziger Knoten das Verbinden eines partitionierten
”
Multicastbaumes einleiten.
• Der Group Leader“ darf als einziger Knoten auf Anfragen zur Wiedervereinigung
”
zweier Multicastbäume antworten.
• Der Group Leader“ hat die Pflicht, in regelmäßigen Abständen von
”
GROUP HELLO INTERVALL Millisekunden die Sequenznummer der Gruppe
zu erhöhen.
• Wenn der Group Leader“ die Sequenznummer erhöht hat, muss er das mit Hilfe
”
von GRPH-Nachrichten allen Knoten im Netzwerk mitteilen.
2.2.2.7 Beitreten einer Multicastgruppe
In Abbildung 2.8 sieht man das Aktivitätsdiagramm für einen Knoten, welcher einer Multicastgruppe beitreten möchte. Dazu sendet dieser Knoten ein RREQ mit
gesetztem ’J’-Flag aus. Möchte er nur Daten an eine Multicastgruppe senden, muss
er dieser nicht angehören und kann das RREQ ohne das ’J’- Flag senden. Als Ziel
des RREQ gibt der Knoten die IP-Adresse der Multicastgruppe an. In das Feld der
Ziel-Sequenznummer trägt er die ihm aktuell bekannte Squenznummer der Gruppe ein
oder 0 wenn er keine Aufzeichnungen besitzt. Als Nächstes schaut der Knoten in seiner Group Leader“-Tabelle nach, falls er eine besitzt. Findet er in dieser Tabelle einen
”
Studienarbeit Falk Ahlendorf
2 Grundlagen
18
Unicast RREQ
Broadcast RREQ
Group Leader bekannt
noch Wiederholungen erlaubt
Group Leader nicht bekannt
Broadcast RREQ
Warte auf weitere Antworten
Warten auf Antwort keine Antwort erhalten
Antwort erhalten
Suche beste Route aus wollte nur Daten senden
Sende MACT
Verwerf e Paket
keine Wiederholung mehr möglich
wollte Gruppe beitreten
Werde Groupleader
Abbildung 2.8: Aktivitätsdiagramm für das Beitreten zu einer Multicastgruppe
entsprechenden Eintrag, überprüft der Knoten, ob er eine aktuelle Route in Richtung
des dort aufgeführten Group Leaders“ besitzt. Ist das der Fall, so kann der Knoten
”
das Route Request direkt an den Group Leader“ richten. Dazu hängt er die Multicast
”
”
Group Leader“-Erweiterung an das RREQ an. Im Anschluss sendet der Knoten das
RREQ per Unicast an den in der Tabelle aufgeführten Group Leader“. Findet sich
”
in der Tabelle kein entsprechender Eintrag, lässt der Knoten die Erweiterung weg. In
dem Fall wird das RREQ dann per Broadcast an alle Nachbarn verteilt. Das TTL-Feld
des IP Headers wird in diesem Fall auf den Wert AODV TTL START gesetzt.
Hat der Knoten des RREQ versendet, wartet er, wie in Abblindung 2.8 zu sehen,
auf ein RREP. Erhält der Knoten innerhalb von RREP WAIT TIME keine Antwort,
wiederholt der Knoten das RREQ. Dies macht er so lange, wie in RREQ RETRIES
angegeben. Wenn der Knoten das RREQ wiederholen muss, so sendet er es mit einem
TTL-Feld aus, welches zum vorhergehenden RREQ um AODV TTL INCREMENT erhöht wurde. Das TTL-Feld darf dabei den Wert von AODV TTL TRESHOLD nicht
übersteigen, ansonsten wird es auf diesen Wert zurückgesetzt. Hatte der Knoten das
RREQ an den Group Leader“ gerichtet und keine Antwort erhalten, werden die nach”
folgenden RREQs per Broadcast an alle Nachbarn und ohne Erweiterungen verschickt.
Erhält der Knoten trotz mehrmaligen Wiederholen des RREQs keine Antwort, muss
er davon ausgehen, dass die Multicastgruppe, die er sucht, nicht existiert. Wollte der
Knoten nur ein Datenpaket an die Gruppe senden, so verwirft er es einfach. War es
Studienarbeit Falk Ahlendorf
2 Grundlagen
19
aber die Absicht des Knotes dieser Gruppe beizutreten, so wird er zum Group Leader“.
”
Dies teilt er dann auch gleich allen anderen Knoten im Netzwerk mit. Dazu verschickt
er eine GRPH-Nachricht, in der das ’U’-Flag gesetzt ist.
Erhält der Knoten eine Antwort auf seine Anfrage, dann wartet er noch
RREP WAIT TIME Millisekunden ob weitere Antworten eintreffen. Aus den eingetroffenen Antworten wählt er dann die jenige aus, welche die größte Sequenznummer
hat. Sollten das mehre Antworten sein, so wird diejenige genommen, welche den kürzesten Weg zum Multicastbaum verspricht. An den Absender dieser Antwort verschickt
der Knoten dann eine MACT-Nachricht mit gesetztem ’J’ -Flag. Auf diese Weise wird
die entsprechende Route ausgewählt und aktiviert. Damit ist der Knoten dann dem
Multicatbaum beigetreten.
2.2.2.8 Verlassen einer Multicastgruppe
Sich aus Next Hop Liste entfernen
Knoten ist kein Group Leader
Knoten ist Blatt
Sende Prune MACT
Knoten ist Group Leader
Knoten ist Blatt
Knoten ist kein Blatt
Sende Prune MACT
Knoten ist kein Blatt
Sende Group Leader MACT
Werde normaler Knoten
Abbildung 2.9: Aktivitätsdiagramm für das Verlassen einer Multicastgruppe
Einem Knoten steht es jeder Zeit frei, eine Multicastgruppe zu verlassen. Allerdings
darf der Knoten sich nur aus dem Multicastbaum entfernen, wenn er die Multicastnachrichten nicht an andere Knoten weiterleitet.
Studienarbeit Falk Ahlendorf
2 Grundlagen
20
Möchte ein Knoten eine Multicastgruppe verlassen, entfernt er sich selbst aus seiner
Next Hop“-Liste, wie in Abbildung 2.9 zu sehen ist. Somit werden alle eingehenden
”
Multicastpakete nur noch weitergeleitet aber nicht mehr lokal zugestellt. War der Knoten ein Group Leader“, muss er nun seinen Group Leader“-Status aufgeben. Dies kann
”
”
auf zwei verschiedene Weisen passieren, wie Abbildung 2.9 entnommen werden kann.
Hat der Group Leader“ nur noch einen Eintrag in seiner Next Hop Liste“, kann er
”
”
diesem Hop einfach eine MACT-Nachricht mit gesetztem ’P’-Flag schicken. Der Knoten welcher diese Nachricht empfängt, erkennt das sie vom Group Leader“ kam. Dieser
”
kann daraufhin zwischen drei Möglichkeiten entscheiden.
1. Er entfernt sich auch aus dem Multicastbaum. Für diese Variante entscheidet er
sich, wenn er selbst die Daten nur an einen Hop weitergeleitet hat.
2. Er bestimmt einen neuen Group Leader“. Diese Möglichkeit wählt er, wenn er
”
selbst die Daten nur weiterleitet aber mehr als einen Hop in der Next Hop“-Liste
”
stehen hat.
3. Er wird selber zum neuen Group Leader“. Dies passiert nur, wenn der Knoten
”
die Datenpakete der Mutlicastgruppe auch selber empfangen möchte.
Hat nun aber der alte Group Leader“ mehr als einen Hop in seiner Next Hop“”
”
Liste, so wählt er einen aus und bestimmt ihn zum neuen Group Leader“. Er selbst
”
gibt seinen Group Leader“-Status auf. Dies macht er, indem er dem entsprechenden
”
Knoten eine MACT-Nachricht mit gesetztem ’G’-Flag schickt.
Ist der Knoten, welcher die Multicastgruppe verlassen wollte, kein Group Leader“
”
gewesen, so kann er den Multicastbaum auch nicht einfach verlassen. Wenn er in seiner
Next Hop“-Liste noch mehr als einen Eintrag hat, dann muss er die eingehenden
”
Multicastdatenpakete noch weiterleiten. Hat er nur noch einen Eintrag, so kann er
diesen Knoten eine MACT-Nachricht mit gesetztem ’P’-Flag schicken. Daraufhin wird
der Knoten aus der Next Hop“-Liste des anderen Knotens entfernt. Wobei dieser
”
Knoten dann auch prüft, ob er sich selbst auch entfernen kann.
2.2.2.9 Netzwerkpartitionierung
Jeder Knoten ist in der Lage zu erkennen, wenn ein Link zwischen ihm und einem Nachbarknoten ausfällt. Der Ausfall des Links hat zur Folge, dass die AODV-Hello-Pakete
ausbleiben und der Knoten auch keinen Datentransfer von seinem Nachbarknoten mehr
empfängt. Stellt ein Knoten fest, das ein Link ausgefallen ist, muss er überprüfen, ob
Studienarbeit Falk Ahlendorf
2 Grundlagen
21
Deaktiviere Verbindung
DOWNSTREAM deaktiviert
UPSTREAM deaktiviert
Sende RREQ
noch Wiederholungen möglich
keine Antwort
keine Wiederholungen möglich
Antwort erhalten
Warte auf weitere Antworten benötigt Datenpakete
Wähle beste Antwort
Sende MACT
Werde Group Leader
leitet Daten nur weiter
nur ein nächster Hop
Sende Prune MACT
hat mehr als einen nächsten Hop
Sende Group Leader MACT
Abbildung 2.10: Aktivitätsdiagramm für das Reparieren eines Links
der Link relevant für einen Multicastbaum ist. Wird der Link in einem Multicastbaum verwendet, muss er in der Next Hop“-Liste als deaktiviert markiert werden.
”
Dies kann man auch der Abbildung 2.10 entnehmen. Ist der Knoten, der deaktiviert
werden muss, mit der Richtung DOWNSTREAM versehen, passiert nichts weiter. Hat
die Richtungsangabe allerdings den Wert UPSTREAM, so muss der Knoten unverzüglich die Reparatur des Baums einleiten. Dies geschieht, indem er einfach ein RREQ mit
gesetztem ’J’-Flag sendet. So als würde er versuchen der Multicastgruppe neu beizutreten. Um zu verhindern, dass Knoten antworten, die unter ihm im Baum hängen“,
”
fügt er allerdings an das RREQ noch die Multicast Group Rebuild“-Erweiterung an.
”
Aus Abbildung 2.10 geht hervor, dass der Knoten, wie auch schon beim Beitreten einer
Studienarbeit Falk Ahlendorf
2 Grundlagen
22
Multicastgruppe, auf eine Antwort wartet. Trifft eine Antwort ein, wird noch gewartet
ob weitere Antworten eintreffen. Von den eingetroffenen Antworten wird wieder diejenige mit der größten Sequenznummer und dem kürzesten Weg zum Baum und Group
”
Leader“ ausgewählt. Diese bestätigt der Knoten mit einer Join-MACT-Nachricht. Den
Knoten unterhalb von ihm teilt er dann mit einer Update-MACT-Nachricht den neuen
Hop Count“ zum Group Leader“ mit.
”
”
Sollte der Knoten nach RREQ RETRIES immer noch keine Antwort erhalten haben,
muss der Knoten davon ausgehen, dass es zu einer Netzwerkpartitionierung gekommen
ist. Da in jeder Netzwerkpartition ein Group Leader“ existieren muss, hat der Knoten
”
jetzt die Aufgabe einen neuen Group Leader“ zu bestimmen. Aus Abbildung 2.10 kann
”
man entnehmen, dass sich sein weiteres Vorgehen danach richtet, ob er die Multicastdatenpakete nur weitergeleitet hat oder ob er sie selber empfangen will. Empfängt er
sie selber, wird er einfach der neue Group Leader“. Leitet er sie allerdings nur wei”
ter, so richtet sich sein weiteres Vorgehen danach, an wie viele Knoten er die Daten
weiterleiten muss. Existiert nur ein Knoten, an den die Daten weitergeleitet werden,
so entfernt er sich selbst mit Hilfe einer Prune-MACT aus dem Baum. Der Knoten,
der diese Nachricht empfängt, erkennt das sein UPSTREAM ausgefallen ist und wird
dann selbst zum Group Leader“ oder bestimmt einen neuen nach dem gleichen Ver”
fahren. Hat der Knoten mehr als einen nächsten Hop, dann sendet er einem der Hops
eine Group Leader“-MACT und ändert die Richtung des Links auf UPSTREAM. Die
”
Group Leader MACT wird so lange von den Knoten weitergereicht, bis sie einen Knoten
erreicht, der die Multicastdatenpakete selber empfängt. In den Zwischenknoten wird
immer beim Weiterleiten die Richtung von dem Zielknoten auf UPSTREAM geändert.
2.2.2.10 Wiedervereinigung von Netzwerkpartitionen
Wenn zwei Netzwerkpartitionen mit zwei Group Leadern“ wieder zusammenfinden,
”
dann erkennen das die Group Leader“ in dem sie die GRPH-Pakete des anderen
”
Group Leaders“ empfangen. Der Group Leader“ mit der kleineren IP-Adresse muss
”
”
daraufhin die beiden Netzwerkpartitionen wieder vereinen. Dies macht er indem er ein
RREQ mit gesetztem ’J’- und ’R’-Flag an den Group Leader“ mit der größeren IP”
Adresse schickt. Dieser wählt die größere der beiden Sequenznummern, erhöht diese
und antwortet mit einem RREP mit gesetztem ’R’-Flag. Das RREP aktiviert auf
seinem Rückweg automatisch die Links. Somit brauchen keine MACT-Nachrichten zur
Aktivierung der Links verschickt werden. Der Group Leader“, welcher dann das RREP
”
empfängt, gibt nach dem Empfang sein Group Leader“-Status auf. Damit ist dann das
”
Verbinden der Netzwerkpartitionen abgeschlossen.
Studienarbeit Falk Ahlendorf
2 Grundlagen
23
Die Knoten, welche auf dem Weg zwischen den beiden Group Leadern“ liegen und
”
der einen oder anderen Multicastgruppe angehöhren, leiten die RREQ- und die RREPNachricht immer direkt an ihren UPSTREAM-Knoten weiter. Damit erreicht die Nachricht auf dem schnellstmöglichen Weg den entsprechenden Group Leader“ und es wer”
den nicht übermäßig viele Verzweigungen im Multicastbaum erzeugt.
Die hier beschriebene Vorgehensweise entspricht der, welche im IETF-Draft [RoPe00]
von MAODV beschrieben wird. In der originalen Veröffentlichung [RoPe99] ist das
Vorgehen noch etwas anders beschrieben.
Nach der originalen Veröffentlichung kann jeder Knoten aus dem Multicastbaum
des Group Leaders“ mit der niedrigeren IP-Adresse die beiden Multicastbäume zu”
sammenführen. Dazu sendet der Knoten, wenn er eine GRPH-Nachricht des anderen
Group Leader“ empfängt, ein RREQ mit gesetztem ’R’-Flag an seinen Group Lea”
”
der“. Der Group Leader“ antwortet daraufhin mit einem RREP, wenn nicht schon ein
”
anderer Knoten angefragt hat. Damit bekommt der anfragende Knoten die Berechtigung mit der Wiedervereinigung der beiden Multicastbäume zu beginnen. Der restliche
Ablauf ist dann so, wie oben bereits beschrieben.
2.2.2.11 Weiterleiten von Datenpaketen
Empfängt ein Knoten ein Multicastpaket, überprüft er ob das Datenpaket bereits empfangen wurde. Dazu notiert sich der Knoten für jedes Paket die Absender-IP-Adresse,
das IP-ID-Feld und das IP-Offset-Feld. Stimmen die Felder überein, wird das Datenpaket einfach verworfen. Im Anschluss muss der Knoten überprüfen, ob er das Datenpaket
lokal ausliefern muss. Ist das der Fall, liefert er eine Kopie des Datenpakets an das Betriebsystem aus. Wie in Abbildung 2.11 zu sehen muss der Knoten zum Schluss noch
überprüfen, ob er das Datenpaket auch an andere Knoten weiterleiten muss. Wenn das
zutrifft, dann sendet er das Datenpaket erneut per Brodcast aus, um sicherzustellen,
dass die anderen Knoten das Datenpaket auch empfangen haben. Wenn das unterliegende Netzwerk in der Lage ist Multicast zu unterstützen, muss das Datenpaket nicht
per Brodcast verteilt werden, sondern kann auch per Multicast weiter geleitet werden.
Studienarbeit Falk Ahlendorf
2 Grundlagen
24
Daten lokal benötigt
sonst
keine weiteren Hops
Paket Verwerf en
Lokal zustellen
Daten müssen weitergeleitet werden
Erneut Broadcasten
Abbildung 2.11: Aktivitätsdiagramm für das weiterleiten von Datenpaketen
Studienarbeit Falk Ahlendorf
3 Implementierung
25
3 Implementierung
Dieses Kapitel gibt einen Einblick in die Implementierung des MAODV-Protokolls. Der
erste Abschnitt beschreibt die Probleme, die bei der Implementierung auftraten und
zeigt Lösungansätze. Im zweiten Abschnitt werden die Elemente, welche zu dem bereits existierenden Click-Routergraphen hinzugefügt wurden, beschrieben. Der dritte
Abschnitt des Kapitels widmet sich dann den Anpassungen an den bereits vorhandenen
Elementen. Zum Abschluss wird dann die Integration der Elemente in den Routergraphen vorgestellt.
3.1 Schwachstellen des MAODV Protokoll
Während der Implementierung des MAODV-Protokolls sind einige Fehler in diesem zu
Tage getreten. Diese Probleme lassen sich auf drei Problemklassen zurückführen, die
in den nächsten Abschnitt näher erläutert werden sollen.
3.1.1 Verlorene MACT-Nachrichten
Die MACT-Nachrichten erfüllen entscheidende Aufgaben beim Aufbau und Instandhalten des Multicastbaums (siehe Kapitel 2.2.2.4). Trotz dieser wichtigen Aufgabe werden
die Nachrichten nicht gesichert übertragen. Damit kann ein Verlust dieser Nachrichten
dazu führen, dass die Knoten falsche Informationen über ihre Funktion im Multicastbaum haben.
Um einen Route in dem Multicastbaum zu aktivieren, muss ein Knoten eine JoinNachricht entlang dieser Route senden (siehe Kapitel 2.2.2.7). Geht diese Nachricht
verloren, wird die Route nie aktiviert. Damit werden auch keine Multicastdatenpakete
entlang dieser Route verschickt. Trotzdem merken das die Knoten nie. Deshalb werden
auch keine Reparaturversuche unternommen.
Ein ähnliches Problem gibt es mit der Leader-MACT. Geht diese verloren, wird
kein neuer Group Leader“ gewählt und es entsteht ein Teilbaum ohne Group Lea”
”
der“. Auch dieses Problem wird von den Knoten nicht erkannt und es werden keine
Studienarbeit Falk Ahlendorf
3 Implementierung
26
Gegenmaßnahmen unternommen.
Der Verlust einer Prune-MACT führt meist dazu, dass ein Ast in dem Multicastbaum
unötig Daten weiterleitet. Aber auch hier kann es unter Umständen dazu kommen, dass
ein Teilbaum ohne Group Leader“ entsteht.
”
3.1.2 Asymetrischer Linkausfall
Ein weiteres Problem des MAODV-Protokolls ergibt sich aus der Tatsache, dass in
einem Wireless Network die Links nicht immer symetrisch in beide Richtungen abbrechen. Meist fällt der Link asymetrisch aus. Dadurch können in die eine Richtung
zwar keine Daten mehr übertragen werden, in die Gegenrichtung hingegen kann das
aber durchaus noch möglich sein. Das führt dazu, dass ein Knoten einen Linkausfall
detektieren kann, während der Gegenknoten diesen nicht bemerkt. Erkennt der Knoten, der näher am Group Leader“ ist, einen Linkausfall, so entsteht eine Lücke im
”
Baum. Diese Lücke wird aber nicht geschlossen, weil das die Aufgabe des Knoten ist,
der weiter entfernt vom Group Leader“ ist. Dieser Knoten hat aber den Linkausfall
”
nicht detektiert und unternimmt somit nichts.
Ein weiterer Fall ist, dass der Knoten der weiter entfernt vom Group Leader“ ein
”
Linkausfall erkennt. Der Knoten, welcher näher am Group Leader“ ist, hingegen be”
kommt davon nichts mit. Wenn das auftritt, besteht die Möglichkeit, dass sich ein
Kreis im Multicastbaum ausbildet, wenn sich ein weiterer Knoten des Multicastbaums
in der Nähe befindet. Dies passiert dadurch, dass der Knoten auf sein RREQ- zwei
RREP-Nachrichten erhählt. Ist die Antwort des zweiten Knotens besser als die des ursprünglichen Knotens, bildet sich ein solcher Kreis. Der Knoten erhält nun die Multicastdatenpakete sowohl vom ursprünglichen Knoten als auch von dem zweiten Knoten.
3.1.3 Tote Äste“
”
Wenn zwei Teilbäume sich wieder verbinden, wird das über RREQ- und RREPNachrichten bewerkstelligt (Siehe Kapitel 2.2.2.10). Dabei ist keine zusätzliche Aktivierung der Routen notwendig, weil das RREP auf seinem Weg zurück die Route
auch gleich aktiviert. Dies führt dann zu Problemen, wenn das RREP auf seinem Weg
zurück verloren geht. Da der Group Leader“, welcher das RREQ ausgesendet hat,
”
keine Antwort bekommt, sendet er nochmals ein RREQ aus. Worauf er ein RREP erhält. Es besteht aber die Möglichkeit, dass die zweiten RREQ- und RREP-Nachrichten
einen anderen Weg wählen als die erste RREQ- und RREP-Nachrichten. Somit besteht
Studienarbeit Falk Ahlendorf
3 Implementierung
27
die Möglichkeit, dass in dem Multicastbaum nun ein Ast existiert, der die Daten weiterleitet aber in dem sie niemand empfangen möchte.
3.1.4 Lösungsansätze der Probleme
Das Problem der verlorenen MACTs lässt sich mit einfachen Acknowledgements beheben. In [DKBD+ 03] wird vorgeschlagen eine zusätzliche MACT-Nachricht einzuführen, die MACT ACK Nachricht. Sie wird vom Empfänger, der zu sichernden MACTNachrichten, an den Absender zurückgesendet. Somit kann dieser überprüfen, ob die
MACT-Nachricht angekommen ist. Erhält er nach MACT ACK TIMER keine Antwort, wiederholt er die MACT-Nachricht. Allerdings darf er die MACT-Nachricht
höchstens mit der Anzahl MACT RETRIES wiederholen.
Die Probleme der nicht selbst reparierenden Links der Teilbäume ohne Group Lea”
der“ oder die toten Äste können auf diese Weise nicht behoben werden. Ein möglicher
Lösungsansatz hierfür wird in [MoCP08] vorgestellt. Dort wird vorgeschlagen, eine
spezielle GRPH-Nachricht zu verwenden, welche sich nur entlang des Multicastbaums
ausbreitet. Empfängt ein Knoten keine solche Nachricht in einem bestimmten Intervall,
weiß er, dass er vom Group Leader“ getrennt wurde und kann mögliche Reperaturen
”
des Baums einleiten.
Das Problem dieses Lösungsansatzes ist, dass der Knoten nicht entscheiden kann wo
der Link abgerissen ist. Dafür benötigt dieser Lösungsansatz weitere Mechanismen.
In der Implementierung wird aufgrund dessen einen weiterentwickelten Ansatz verwendet. In diesem sendet jeder Knoten im MACT HELLO INTERVAL eine MACTNachricht ohne gesetzte Flags per Unicast an seine DOWNSTREAM-Knoten. Empfängt ein Knoten keine solche Nachricht von seinem UPSTREAM-Knoten, leitet er sofort eine Reparatur des Links ein. Empfängt ein Knoten eine solche MACT-Nachricht
von einem Knoten der nicht sein UPSTREAM-Knoten ist, kann er diesen mit einer
Prune-MACT auf seinen Fehler hinweisen.
Auf diese Weise können ausgefallene Links zuverlässig erkannt werden. Des Weiteren
ermöglicht dieser Ansatz das Überwachen der Multicastroutingtabelle durch die Nachbarknoten. Damit ist es möglich, tote Äste und Kreise zu erkennen und aufzulösen.
Durch seinen lokalen Ansatz werden auch keine zusätzlichen Mechanismen benötigt,
um zu erkennen, an welcher Stelle des Baums ein Fehler aufgetreten ist. Denn nur die
beteiligten Knoten bekommen diesen Fehler mit. Alle anderen Knoten werden dadurch
nicht beeinflusst.
Studienarbeit Falk Ahlendorf
3 Implementierung
28
3.2 Die verwendete Software
Um das MAODV-Routingprotokoll zu implementieren, wurde auf die Software Click
[MIT07] zurückgegriffen. Mit dieser Software ist man in der Lage, einen Router aus einzelnen Elementen zusammenzubauen. Jedes eingehende oder ausgehende Datenpakete
durchläuft bei dieser Software einen vordefinierten Graphen aus einzelnen Elementen.
Jedes dieser Elemente ist eine C++ Klasse, welche eine definierte Schnittstelle zur Entgegennahme und zur Weitergabe von Paketen besitzt. Des Weiteren darf jedes Element
Pakete erzeugen oder löschen.
In der Standardinstallation von Click ist bereits eine Vielzahl von Elementen vorhanden, die einen Großteil der herkömmlichen Routingaufgaben abdecken. Aber Click
bietet auch die Möglichkeit neue eigene Elemente hinzuzufügen.
Verbunden werden diese Elemente mit Hilfe einer Textdatei, die auch als Clickscript
bezeichnet wird. In ihr wird festgehalten, welche Elemente geladen werden sollen und
welche Parameter diesen übergeben wird. Außerdem wird, in dieser Datei notiert in
welcher Reihenfolge die Elemente von Paketen durchlaufen werden sollen. Dabei ist
es durchaus auch möglich, Verzweigungen zu realisieren oder Elemente parallel zu
durchlaufen.
Getestet wurde während der Implementierung mit Hilfe des Netzwerksimulators
NS2, welchen man unter [Info06] finden kann. Für diesen Netzwerksimulator gibt es
auf der Click-Webseite einen Patch. Dieser Patch sorgt dafür, dass das Routing in den
virtuellen Netzwerkknoten nicht mehr durch NS2, sondern durch Click durchgeführt
wird. Damit ist es möglich, Änderungen an einem Element sofort mit einer Vielzahl
von Netzwerkknoten zu testen, ohne das man mehrere Rechner dafür benötigt. Nach
dem die mit Hilfe von NS2 erstellen Elemente funktionsfähig waren, wurden sie auf
ihre Funktionsfähigkeit hin im DekoR untersucht. Die dafür notwendigen Tests und
ihre Auswertung ist im Kapitel 4 nachzulesen.
3.3 Die neuen Elemente
Um das MAODV-Protokoll zu realisieren, mussten dem Routergraphen sechs neue
Clickelemente hinzugefügt werden. Diese Elemente realisieren die einzelnen Funktionalitäten des Protokolls, wie sie im Abschnitt 2.2.2 beschrieben wurden.
Studienarbeit Falk Ahlendorf
3 Implementierung
29
MulticastRoutingTable
+ DIRECTION_LOCAL : cons t uns igned int
+ DIRECTION_UPSTREAM : cons t uns igned int
+ DIRECTION_DOWNSTREAM : cons t uns igned int
m cas tRoutingTable : tm cas tRoutingTable
m yTim eOutMap : tim eoutm ap
m cas tTable
0..1
mcast_Controler
m act : m cas t_Multicas tActivationMes s age*
control : m cas t_Controler*
m yip : IPAddres s
+ Multicas tRoutingTable()
+ ~ Multicas tRoutingTable()
control 0..1
+ clas s _nam e() : cons t char*
+ s etMulticas tGroupLeader(group : cons t IPAddres s &, leader : cons t IPAddres s &)
+ s etMulticas tGroupSequenznum ber(group : cons t IPAddres s &, newnum ber : cons t uns igned int)
+ s etMulticas tGroupHops ToLeader(group : cons t IPAddres s &, newnum ber : cons t uns igned int)
+ s etMulticas tGroupHops ToNextHop(group : cons t IPAddres s &, newnum ber : cons t uns igned int)
+ getMulticas tGroupLeader(group : cons t IPAddres s &) : IPAddres s
+ getNextHopToLeader(group : cons t IPAddres s &) : IPAddres s
+ getNextDownStream (group : cons t IPAddres s &) : IPAddres s
+ getMulticas tGroupSequenznum ber(group : cons t IPAddres s &) : uns igned int
Element
+ getMulticas tGroupHops ToLeader(group : cons t IPAddres s &) : uns igned int
+ getMulticas tGroupHops ToNextHop(group : cons t IPAddres s &) : uns igned int
+ s etGroupLeaderState(group : cons t IPAddres s &, s tate : bool)
+ getGroupLeaderState(group : cons t IPAddres s &) : bool
+ is KnownGroup(group : cons t IPAddres s &) : bool
+ is ActiveGroup(group : cons t IPAddres s &) : bool
+ is ActiveGroupRouter(group : cons t IPAddres s &) : bool
m act 0..1
+ addNewHop(group : cons t IPAddres s &, newhop : cons t IPAddres s &, interface : cons t uns igned int, direction : cons t uns igned)
m act 0..1
mcast_MulticastActivationMessage
+ rem oveHop(group : cons t IPAddres s &, hop : cons t IPAddres s &)
+ enableHop(group : cons t IPAddres s &, hop : cons t IPAddres s &)
+ dis ableHop(group : cons t IPAddres s &, hop : cons t IPAddres s &)
+ getDirection(group : cons t IPAddres s &, hop : cons t IPAddres s &) : uns igned int
+ num berNextHops (group : cons t IPAddres s &) : uns igned int
+ getNextHops (group : cons t IPAddres s &) : cons t tNextHopVector
+ routeTim out(ip : cons t IPAddres s &)
+ needRebroadcas t(group : cons t IPAddres s &, s ource : cons t IPAddres s &) : bool
+ needLocal(group : cons t IPAddres s &) : bool
+ is Touched(group : cons t IPAddres s &) : bool
+ is Repair(group : cons t IPAddres s &) : bool
m cas tTable0..1
+ s etRepair(group : cons t IPAddres s &, s tate : bool)
+ getLeaderGroups () : Vector< IPAddres s >
+ getExtens ion(type : uint8_t, p : Packet*, offs et : cons t int) : void*
+ run_tim er(tim er : Tim er*)
+ s etMact(m : m cas t_Multicas tActivationMes s age*)
+ s etControler(c : m cas t_Controler*)
+ s etMyIP(ip : cons t IPAddres s &)
+ is Known(group : cons t IPAddres s &, s ender : cons t IPAddres s &, id : uint32_t, offs et : uint32_t) : bool
+ s etKnown(group : cons t IPAddres s &, s ender : cons t IPAddres s &, id : uint32_t, offs et : uint32_t)
Abbildung 3.1: Klassendiagramm für die Multicastroutingtabelle
3.3.1 Das Element MulticastRoutingTabelle
Das MulticastRoutingTabellen Element realisiert die Multicast-Routingtabelle für das
MAODV-Protokoll. Dabei nimmt das Element nicht nur alle Informationen auf die im
MAODV-Draft spezifiziert wurden, sondern bietet auch zahlreiche zusätzliche Funktionen. Damit dient dieses Element den anderen Elementen vor allem auch als Kommunikationsschnittstelle.
So verfügt die hier implementierte Multicast-Routingtabelle zum Beispiel über Funktionen, die feststellen, ob ein Netzwerkknoten Mitglied in der Multicastgruppe ist oder
nicht. Da das Element die Möglichkeit bietet, auch unvollständige Einträge zu machen, wurde die im Draft angegebene Group Leader“-Tabelle gleich mit integriert.
”
Deaktivierte Hops werden außerdem nach Ablauf des im Draft angegebenen Timouts
automatisch entfernt. Für diese Funktionalität ist also auch kein weiteres Element
notwendig.
Der Zugriff auf die Routingtabelle wird über get“ und set“ Methoden realisiert,
”
”
welche als Parameter immer die IPAdresse der Multicastgruppe erwarten.
Aus Abbildung 3.1 kann man eine detallierte Übersicht über die Methoden des Ele-
Studienarbeit Falk Ahlendorf
3 Implementierung
30
ments entnehmen.
3.3.2 Das Element Multicastactivationmessage
Dieses Element verfügt über einen Eingangs- und einen Ausgangsport. Damit ist das
Element in der Lage, sowohl eingehende MACT-Nachrichten zu verarbeiten als auch
neue MACT-Nachrichten zu erzeugen.
Die Verarbeitung der MACT-Nachrichten beginnt damit, dass aus der Nachricht die
betreffende Multicastgruppe aus dem Multicast Group IP Address“-Feld extrahiert
”
wird. Im Anschluss daran wird die Absenderadresse der Nachricht aus dem Source IP
”
address“-Feld entnommen. Ist dies geschehen, kann die Nachricht anhand des Flag“”
Feldes eingestuft werden. Wie bereits an Abschnitt 2.2.2.4 beschrieben unterscheidet
man fünf verschiedene MACT-Nachrichten.
1. Die Join-Nachricht erkennt man an dem gesetzten Join-Flag. Sie signalisiert,
dass der sendende Knoten seinen Weg über den empfangenden Knoten gewählt
hat. Bei der Verarbeitung dieser Nachricht wird der Absender in der Multicasttabelle aktiviert. Anschließend wird überprüft, ob der Uplink zum Group Leader“
”
bereits aktiv ist. Ist er das nicht, so wird er mit Hilfe einer Join-MACT-Nachricht
aktiviert. Jede erfolgreich empfangene Join-Nachricht wird von dem Element mit
einer MACT-ACK-Nachricht bestätigt.
2. Ist das Prune-Flag gesetzt, wird die Nachricht als Prune-MACT verarbeitet. In
diesem Fall wird zuerst ermittelt, aus welcher Richtung die Nachricht gekommen ist. Danach wird der Knoten aus der Next Hop“-Liste der Gruppe entfernt.
”
Die bereits am Anfang ermittelte Empfangsrichtung der Nachricht bestimmt nun
über das weitere Vorgehen. War die Empfangsrichtung DOWNSTREAM, gibt es
keine Besonderheiten zu beachten. In diesem Fall geht der Knoten gleich dazu
über, zu überprüfen, ob er noch länger benötigt wird und entfernt sich gegebenenfalls selbst aus dem Multicastbaum. War die Empfangsrichtung allerdings UPSTREAM, wird, wie in Abschnitt 2.2.2.8 bereits beschrieben, ein neuer Group
”
Leader“ gewählt. Auch jede erfolgreich empfangene Prune-Nachricht wird mit
einer MACT-ACK-Nachricht bestätigt.
3. Bei gesetztem Leader -Flag wird die Nachricht als Leader-MACT erkannt. Empfängt ein Knoten eine solche Nachricht, überprüft er zuerst ob er selbst Group
”
Leader“ werden kann. Ist das nicht der Fall, so sendet er die Leader-MACT an
Studienarbeit Falk Ahlendorf
3 Implementierung
31
den ersten Hop aus der Next Hop“-Liste weiter und dreht dessen Linkrichtung
”
auf UPSTREAM um.
Zum Schluss der Verarbeitung wird dann auch noch die Richtung des Absenders
der Leader -MACT auf DOWNSTREAM geändert.
4. Empfängt der Knoten eine Update-MACT-Nachricht, überprüft er zuerst, ob
diese Nachricht aus Richtung des Group Leaders“ gekommen ist. Ansonsten
”
verwirft er sie. Kam die Nachricht aber aus Richtung des Group Leaders“, wird
”
der Hop Count“ zum Group Leader“ in der Multicastroutingtabelle aktualisiert.
”
”
Anschließend erhöht der Knoten das Hopcount Feld und verschickt die Nachricht
an seine Nachbarknoten.
Ob es sich bei einer Nachricht um eine Update-MACT-Nachricht handelt, wird
an Hand des Update-Flags festgestellt.
5. Der letzte im Draft spezifizierte MACT-Nachtichtentyp ist die Reboot-Nachricht.
Diese signalisiert, dass ein Knoten neugestartet wurde. Enthält eine MACTNachticht ein gesetztes Reboot-Flag, wird das der Multicastroutingtabelle mitgeteilt. Diese entscheidet dann über das weitere Vorgehen.
6. Aufgrund von Schwachstellen im MAODV-Protokoll, wurde im Kapitel 3.1.4 die
ACK -Nachricht als neuer Nachrichtentyp eingeführt. Wird die ACK -Nachricht
empfangen, wird der Timer gelöscht, welcher für das erneute senden von MACTNachrichten zuständig ist. Empfängt der Knoten auf eine der gesicherten MACTNachrichten keine ACK -Nachricht, wiederholt er sie automatisch.
In einer MACT-Nachricht darf immer nur eines der sechs möglichen Flags gesetzt werden. Sind mehrer Flags gesetzt, handelt es sich um eine ungültige Nachricht. In diesem
Fall verwirft das Element die Nachricht einfach. Ist in der Nachricht keines der Flags
gesetzt, wird sie als MACT-Hello-Nachricht interpretiert (siehe Kapitel 3.1.4). Mit Hilfe dieser Nachricht überprüft das Element, ob alle Nachbarn die gewünschten Routen
haben oder nicht. Ist das nicht der Fall, werden entsprechende Reperaturmaßnahmen
ergriffen.
Um MACT-Nachrichten zu verschicken, bietet das Element für jeden Nachrichtentyp eine eigene Funktion an. Diese Funktionen sind so implementiert, dass sie selbständig Nachrichten auf die richtige Weise verschicken. So werden die Join, Prune
und Leader -MACT-Nachrichten nur an das angegebene Ziel verschickt. Die UpdateMACT-Nachricht hingegen wird automatisch an alle DOWNSTREAM Hops verteilt.
Studienarbeit Falk Ahlendorf
3 Implementierung
32
Das Gleiche gilt auch für die Reboot-MACT-Nachricht, welche automatisch auf allen
Interfaces per Broadcast verteilt wird.
3.3.3 Das Element GroupHello
Das GroupHello Element verfügt wie auch schon das Multicastactivationmessage-Element über einen Eingangs- und einen Ausgangsport. Dieses Element übernimmt die
Generierung und Verarbeitung der GRPH-Nachrichten. Die Hauptaufgabe dieser Nachrichten ist es, wie in Abschnitt 2.2.2.5 beschrieben, Multicastgruppen in einem Netzwerk bekannt zu machen.
Wird eine GRPH-Nachricht empfangen, so extrahiert das Element zuerst die Gruppe
aus dem Multicast Group IP address“-Feld und den Group Leader“ aus dem Group
”
”
”
Leader IP address“-Feld (siehe Kapitel 2.2.2.5). Anhand dieser beiden Felder und unter
Berücksichtigung des Multicast Group Sequence Number“-Feldes wird anschließend
”
überprüft, ob diese GRPH-Nachricht innerhalb der letzten BCAST ID SAVE Millisekunden bereits verarbeitet wurde. Nachdem die GRPH-Nachricht diese Prüfungen
überstanden hat, werden die Felder in der Nachricht ausgewertet. Es wird überprüft,
ob sich die Informationen in diesen Feldern gegenüber den gespeicherten in der Multicastroutingtabelle geändert haben. Da dies, wie bereits in Kapitel 2.2.2.10 erwähnt,
ein Indiz dafür ist, dass möglicherweise zwei Group Leader“ in einer Multicastgruppe
”
existieren. Wird ein solcher Fall erkannt und ist der Knoten dann auch selber einer der
Group Leader“, wird das Wiederverbinden der Bäume eingeleitet.
”
Stellt der Knoten aber fest, dass die Informationenen absichtlich geändert wurden
(das Update-Flag ist gesetzt), übernimmt er die neuen Informationen in seine Routingtabelle.
Zum Abschluss der Verarbeitung wird die GRPH-Nachricht erneut per Broadcast
verschickt. Damit ist sichergestellt, dass auch alle Nachbarknoten sie empfangen.
Mit Hilfe einer Timerfunktion, welche im GROUP HELLO INTERVALL aufgerufen wird, realisiert das Element seine zweite Aufgabe. In dieser Timerfunktion wird
überprüft, für welche Gruppen der Knoten einen Group Leader“-Status hat. Für
”
diese Gruppen wird dann eine GRPH-Nachricht erzeugt und per Broadcast versand.
Somit stellt das Element auch sicher das im GROUP HELLO INTERVALL GRPHNachrichten vom Group Leader“ ausgesendet werden.
”
Studienarbeit Falk Ahlendorf
3 Implementierung
33
3.3.4 Das Element Controler
Das Controler-Element realisiert die Ablaufsteuerung innerhalb eines Knotens. Sein
Aufbau besteht aus drei Zustandsautomaten. Jeder dieser Zustandsautomaten regelt
einen bestimmten Ablauf. Es gibt jeweils einen Zustandsautomaten für das Beitreten,
Reparieren und Verbinden eines Multicastbaums. Alle drei Zustandsautomaten besitzen nur zwei Zustände. Im ersten Zustand wird immer eine entsprechende Anforderung
an die Nachbarknoten ausgesendet und möglicherweise wiederholt. Trifft eine Antwort
auf die Anforderung ein, dann gehen die Zustandsautomaten in ihren zweiten Zustand
über. In diesem Zustand erfolgt die Nachbereitung der Antworten. Allerdings erfolgt
die Ausführung des Zustands nicht sofort nachdem Zustandsübergang, sondern erst
nach dem eine gewisse Zeitspanne vergangen ist. Somit besteht noch die Möglichkeit,
das weitere Antworten auf die Anfrage eintreffen und die beste daraufhin ausgewählt
werden kann.
3.3.5 Das Element Forwarder
Das Forwarder-Element hat zwei Aufgaben im Clickroutergraphen. Für jede dieser
Aufgaben bietet das Forwarder-Element einen Eingangsport an. Die erste Aufgabe des
Elements ist es eingehende Multicast-Datenpakete entgegenzunhemen und gegebenenfalls weiterzuleiten. Dazu prüft das Element die am Port 0 eingehenden Datenpakete
darauf, ob sie bereits empfangen wurden. Dazu verwendet das Element die im Kapitel 2.2.2.11 beschriebene Methode. Hat das Element das Datenpaket bereits einmal
empfangen, wird es einfach verworfen. Stellt das Element fest, dass das Datenpaket
neu ist, wird als nächstes geprüft, ob das Datenpaket lokal zugestellt werden muss. Ist
das der Fall, wird es einmal auf dem Ausgangsport 0 als Kopie ausgegeben. Im Anschluss überprüft das Element nun auch noch, ob es das Datenpaket eventuell an andere
Knoten weiterleiten muss. Wird festgestellt, dass das Element die Daten nocheinmal
weiterleiten muss, wird es zusätzlich noch auf Port 1 ausgegeben.
Die zweite Aufgabe des Elements ist es, die selbst erstellten Multicast-Datenpakete so
zu modifizieren, dass sie bei anderen Knoten auch als neue Datenpakete erkannt werden
können. Dazu modifiziert das Element bei den auf Port 1 eingehenden Nachrichten das
IP-ID-Feld. Dieses Feld wird durch das Element für jedes Paket erhöht. Damit können
die anderen Knoten dieses Paket als ein neues Paket erkennen. Die so modifizierten
Pakete werden im Anschluss auf Port 1 ausgegeben.
Studienarbeit Falk Ahlendorf
3 Implementierung
34
3.4 Angepasste Elemente
In den nächsten Abschnitten wird erläutert welche Änderungen an den wichtigsten
Elementen durchgeführt wurden.
3.4.1 Das Element AODVDestinationClassifier
Die Aufgabe des AODVDestinationClassifier ist es, zu entscheiden, ob die eingehenden
RREP-Nachrichten weitergeleitet werden oder lokal benötigt werden.
Dieses Element wurde so erweitert, dass es in der Lage ist, mit Multicast-RREPNachrichten umzugehen. Dazu musste zuerst die Konfiguration des Elements um die
Multicastroutingtabelle erweitert werden. Mit Hilfe der Multicastroutingtabelle ist das
Element nun in der Lage zu entscheiden, ob es sich bei der RREP-Nachricht um eine
Multicast-RREP-Nachricht handelt oder nicht. Diese Information wird genutzt, um
beim Weiterleiten der Nachricht die entsprechenden Routen in die Multicastroutingtabelle einzutragen. Außerdem verwirft das Element alle Multicast-RREP-Nachrichten,
die einen schlechteren Weg zum Ziel, angeben als die beste bereits weitergeleitete
RREP-Nachricht.
Wird eine RREP-Nachricht so eingestuft, dass sie lokal zugestellt werden muss,
wird sie nicht an das RouteDiscovery Element ausgegeben, sondern an das ControlerElement, da dieses für die Verarbeitung der Multicastrouten zuständig ist.
3.4.2 Das Element AODVKnownClassifier
Das AODVKnownClassifier-Element ist dafür zuständig, zu entscheiden, ob ein Knoten
auf eine RREQ-Nachricht antworten kann oder ob diese RREQ-Nachricht weitergeleitet
werden muss. Auch diesem Element wurde in der Konfiguration die Multicastroutingtabelle hinzugefügt. Somit ist das Element nun auch in der Lage zu erkennen, ob es
sich um eine Multicast-RREQ-Nachricht handelt. Stellt das Element fest, dass es sich
um eine Multicast-RREQ-Nachricht handelt, so sieht es in der Multicastroutingtabelle
nach, ob es die Anfrage beantworten kann und darf. Wenn das der Fall ist, wird die
RREQ-Nachricht in Richtung des AODVGenerateRREP-Element weitergeleitet.
3.4.3 Das Element AODVGenerateRREP
Mit Hilfe des AODVGenerateRREP-Elements werden die RREP-Nachrichten erzeugt.
Damit dieses Element korrekte Multicast-RREP-Nachrichten erzeugen kann, musste
Studienarbeit Falk Ahlendorf
3 Implementierung
35
auch hier die Konfiguration um die Multicastroutingtabelle erweitert werden. Mit Hilfe der Multicastroutingtabelle kann nun dieses Element erkennen, ob es sich bei einer
eingehenden RREQ-Nachricht um eine multicast RREQ-Nachricht handelt oder nicht.
Handelt es sich um eine multicast RREQ-Nachricht, kann das Element die möglichen
Erweiterungen auswerten und ein entsprechende RREP-Nachricht generieren. Die Generierung der RREP-Nachricht ist fast komplett aus der Unicastversion übernommen
worden. Dieser Programmabschnitt wurde lediglich so verändert, dass er nun auch in
der Lage ist, die RREP-Erweiterungen, die durch MAODV eingeführt wurden, mit an
das Paket anzuhängen.
3.4.4 Das Element AODVGenerateRREQ
Dieses Element besitzt die Aufgabe RREQ-Nachrichten zu erzeugen. Wie auch schon
bei den anderen Elementen wurde bei diesem Element die Konfiguration um die Multicastroutingtabelle erweitert. Damit ist es nun diesem Element auch möglich, für
Multicastgruppen RREQ-Nachrichten zu erzeugen. Möglich ist das über zwei neue
Funktionen, die dem Element hinzugefügt wurden. Das ist zum einen die Funktion generateMcastRREQ. Diese ist dafür zuständig ist RREQ-Nachrichten zu erzeugen, wie
man sie für den Beitritt oder zur Linkreperatur benötigt. Zum anderen wurde auch die
Funktion generateUnicastMcastRREQ hinzugefügt. Ihre Aufgabe ist es den Knoten die
Möglichkeit zu gegeben, den Group Leader“ direkt anzusprechen. Unter anderem wird
”
diese Art der Kommunikation benötigt, wenn zwei Multicastbäume wieder miteinander
verbunden werden sollen.
3.5 Anpassungen im Clickroutergraph
Die Änderungen im Clickroutergraphen sind zahlreich. Ein vollständiges Clickscript
mit allen Änderungen ist im Anhang dargestellt. Eine der wichtigen Änderungen ist,
dass die Multicastroutingtabelle dem Graphen hinzugefügt wurde. Dies ist gleich in
den ersten Zeilen zu erkennen, die nun wie folgt lauten:
mcasttable :: MulticastRoutingTable();
neighbours :: AODVNeighbours(interfaces,mcasttable);
Des Weiteren musste der AODV Classifier so erweitert werden, dass er nun auch die
MACT- und GRPH-Nachrichten erkennt. Damit sieht die Konfiguration für den Classifier nun wie folgt aus:
Studienarbeit Falk Ahlendorf
3 Implementierung
36
//RREQ, RERR, HELLO, RREP, MACT, GRPH, other
classify_aodv :: Classifier(42/01, 42/03, 42/02 22/01,
42/02, 42/05, 42/06, - );
Wie bereits in den vorangegangen Kapitel erwähnt, wurden einige AODV Elemente
erweitert. Dabei wurden meist auch neue Konfigurationsparameter angehängt. Beispielhaft für alle geänderten Elemente sei hier die neue Konfiguration des AODVDestinationClassifiers genannt.
destinationclassifier :: AODVDestinationClassifier(neighbours,
mcasttable);
Des Weiteren mussten die neuen Elemente in den Routergraphen integriert werden.
Das MACT-Element und das GRPH-Element wurden dabei direkt hinter die Ausgabe
des AODVClassifiers gelegt. Die Ausgabeports der beiden Elemente werden dann auf
outputarpcl bzw. outputcl weitergeleitet. Das Forwarder-Element wurde in den Routergraphen vor den ipclassifier eingeschoben, sodass eingehende Multicastdatenpakete
rechtzeitig verworfen beziehungsweise weitergeleitet werden können.
Studienarbeit Falk Ahlendorf
4 Tests
37
4 Tests
In diesem Kapitel werden die Tests und Ergebnisse vorgestellt, die verwendet wurden,
um die Funktionsfähigkeit der Implementierung nachweisen zu können.
4.1 Einleitung
Abbildung 4.1: Aufbau des gesammten Demonstrators
Die Tests wurden im Demonstrator für kontextsensitives Routing durchgeführt, welcher auf der Dimplomarbeit [Wenz08] basiert, seitdem aber modifiziert und erweitert
Studienarbeit Falk Ahlendorf
4 Tests
38
wurde. Für die Tests wurde nicht der ganze Demonstrator benötigt, sondern lediglich
der WLAN-Teil. Um nachweisen zu können, dass das Protokoll auch über mehre Hops
funktioniert, wurden drei Rechner verwendet.
Abbildung 4.2: Empfangsbereiche der drei verwendeten Rechner
Wie aus der Abbildung 4.2 zu entnehmen ist, erreicht der Knoten 3 den Knoten 1
nur über den Knoten 2. Somit muss das Weiterleiten der Nachrichten funktionieren,
damit diese beiden Knoten miteinander kommunizieren können.
Jeder der Testrechner wurde mit der gleichen Clickversion ausgestattet und mit
einem individuell angepassten Konfigurationsscript versehen.
Das Mitschneiden der Kommunikation wurde mit Hilfe des Programms Wireshark
realisiert. Der eingestellte Filter !(aodv.type==2 and ip.ttl==1), im Wireshark ist
dafür zuständig die AODV-Hellopakete auszublenden. In einigen Fällen wurde dieser
Filter noch um !icmp && !arp erweitert. Dieser Filter blendet infolge dessen alle ICMPund ARP-Nachrichten zusätzlich noch aus. Dies ist nötig, damit man die gewünschten
Pakete besser sehen kann. Diese Filter haben aber keine weiteren Auswirkungen auf
die Ergebnisse der folgenden Tests.
Studienarbeit Falk Ahlendorf
4 Tests
39
4.2 Test der Initialisierungsprozedur
Dieser Test beschäftigt sich mit der Initialisierungsphase des MAODV Protokolls. Dafür soll nachgewiesen werden, dass ein Knoten, der gestartet wird, eine Reboot MACTNachricht aussendet (siehe Kapitel 2.2.2.4). Außerdem soll gezeigt werden, dass ein
Knoten, welcher einer nicht existierenden Multicastgruppe beitritt, automatisch zum
Group Leader“ dieser Gruppe wird.
”
Bei diesem Test ist Knoten 2 dem Netzwerk bereits einige Zeit beigetreten. Allerdings
hat Knoten 2 in dieser Zeit nicht versucht einer Multicastgruppe beizutreten. Knoten 1
tritt dem Netzwerk gerade bei und wird versuchen einer Multicastgruppe beizutreten.
Knoten 3 wurde bei dem Test zwischen Knoten 2 und Knoten 1 platziert. Allerdings
wurde in diesem Test auf Knoten 3 kein Click gestartet, sondern er wurde nur genutzt,
um die Kommunikation im Netzwerk aufzuzeichnen.
Abbildung 4.3: Knoten 1 sendet die gewünschte Reboot-MACT
In Abbildung 4.3 ist zu sehen, dass der Knoten 1 wie erwartet, nach dem Start eine Reboot-MACT-Nachricht aussendet. Dass es sich bei Paket 7 um die gewünschte
Nachricht handelt, ist an der Hexadezimalen Zahlenfolge 0x0508 erkennbar, wie sie
am Anfang des Datenblocks im Paket zu sehen ist (siehe auch Kapitel 2.2.2.4). Im
Anschluss sendet der Knoten eine RREQ-Nachricht aus, da er versucht der Multicastgruppe 224.0.62.1 beizutreten. Aus Abbildung 4.4 ist zu entnehmen, dass auch das entsprechende Flag gesetzt wurde, wie es in Kapitel 2.2.2.7 beschrieben ist. Des Weiteren
ist zu sehen, dass Knoten 2 die Pakete auch wie gewünscht wiederholt. Wie erwartet,
erhält der Knoten trotz dessen keine Antwort auf seine Anfrage. Damit wird er zum
Group Leader“, wie in Abbildung 4.5 zu sehen ist. Denn bei Paket 21 handelt es sich
”
um eine GRPH-Nachricht mit gesetztem Update-Flag. Dies is an der hexadezimalen
Studienarbeit Falk Ahlendorf
4 Tests
40
Abbildung 4.4: Knoten 1 sendet die RREQ-Nachrichten
Abbildung 4.5: Knoten 1 wird Group Leader“ und sendet die GRPH-Nachrichten
”
Zahlenkombination 0x0680 am Anfang des Datenblockes erkennenbar.
Abschließend lässt sich zu diesem Test sagen, dass sich Knoten 1 wie erwartet verhalten hat. Somit kann der Test als bestanden gewertet werden.
4.3 Multicastbaum Aufbau- und Reperaturtest
Dieser Test soll zeigen, dass der Multicastbaum wie in Kapitel 2.2.2.7 beschrieben
wurde, aufgebaut wird. Auch soll gezeigt werden, dass MADOV in der Lage ist, den
Multicastbaum aufrecht zu erhalten. Dazu wird untersucht, ob die im Kapitel 2.2.2.9
beschriebenen Reparaturmechanismen anlaufen .
Studienarbeit Falk Ahlendorf
4 Tests
41
Um nachzuweisen, dass der Multicastbaum intakt ist, sendet der Group Leader“
”
im 500ms Intervall Multicastdatenpakete aus. Ist die Verbindung eines Knoten zum
Group Leader“ intakt, so empfängt der Knoten diese Multicastdatenpakete.
”
Der Test macht an der Stelle weiter, an der der vorangegangene Test aufgehört hat.
Dazu wurde Knoten 3 nun außerhalb der Reichweite des Knotenes 1 platziert, wie in der
Einleitung bereits beschrieben wurde. Anschließend wurde das Clickscript gestartet,
woraufhin der Knoten 3 dem Multicastbaum beizutreten versucht. Da Knoten 1 Group
”
Leader“ der gesuchten Multicastgruppe ist, muss der Knoten 3 auf seine Anfrage auch
eine Antwort erhalten.
Abbildung 4.6: Knoten 3 sendet RREQ-Nachrichten
Sehen kann man diesen Beitrittsversuch in Abbildung 4.6. Der Knoten 3 sendet
entsprechende RREQ-Nachricht mit den Paketen 21 und 22 aus. In Paket 28 erhält er
anschließend die Antwort für die gewünschte Route. Nach kurzem Warten auf weitere
eintreffende Antworten sendet der Knoten 3, wie erwartet eine MACT-Join-Nachricht
aus, um die Multicastroute zu aktivieren. Zu sehen ist diese Nachricht als Paket 39 in
der Abbildung 4.7. Mit Paket 41 erfolgt anschließend die Bestätigung von Knoten 2,
dass dieser die Nachricht empfangen hat und sie verarbeitet. Diese Verarbeitung führt
seinerseits dazu, dass der Knoten 2 den Link zu Knoten 1 aktivieren muss. Dies erfolgt
mit Paket 43, welches man auch in der Abbildung 4.7 sehen kann.
Nach ungefähr 90s Betriebszeit ist aufgrund von Störungen die Verbindung zu Knoten 2 kurz abgerissen. Wie erwartet leitete Knoten 3 daraufhin die Reparatur des Links
ein. Zu sehen ist das in der Abbildung 4.8. Der in diesem Bildschirmausschnitt ausgewählten RREQ-Nachricht wurde wie erwartet die Erweiterung vom Typ 4 angehängt
(siehe Kapitel 2.2.2.2). Mit Paket 466 erhält der Knoten 3 eine Antwort auf seine
Studienarbeit Falk Ahlendorf
4 Tests
42
Abbildung 4.7: Knoten 3 aktiviert die Multicastroute
Abbildung 4.8: Knoten 3 repariert die Multicastroute
Reparaturanfrage und bestätigt den Link in den nachfolgenden Paketen.
Die Abbildung 4.9 zeigt die Anzahl der empfangenen Multicastpakete pro Sekunde.
Da der Knoten 1 als Group Leader“ zwei dieser Pakete pro Sekunde aussendet, sollte
”
sich im Idealfall eine Gerade bei zwei Paketen pro Sekunden ausbilden. Deutlich zu
sehen ist der gerade angesprochene Linkausfall bei etwa 90s. Einen ähnlichen Vorfall
kann man nochmals bei 145s beobachten.
Bei der Spitze, welche man bei etwa 195s sehen kann, handelt es sich um ein Kontextrouteradvertisement, welche in den für den Test verwendeten Scripten bereits per
Studienarbeit Falk Ahlendorf
4 Tests
43
Abbildung 4.9: IO Graph für die Multicastdatenpakete des Knoten 3
Multicast verschickt werden.
Damit läßt sich sagen das dieser Test von der Implementierung erfolgreich absolviert
worden ist.
4.4 Test des Kontextrouters
Der Kontextroutertest soll nachweisen, dass der Knotextrouter immer noch auf Kontextanfragen reagiert. Dazu wurde auf Knoten 1 und 2 Click mit einem entsprechenden Clickscript gestartet. Auf Knoten 3 hingegen wurde der in der Diplomartbeit
[Renh08] erweiterte aodv-uu client gestartet. Anschließend ist mit Hilfe des Programms
cont client, wie in [Renh08] beschrieben, eine Kontextanfrage durchgeführt worden.
Abbildung 4.10: CRREQ und CREEP am Knoten 3
Aus Abbildung 4.10 kann man entnehmen, dass der Knoten 3 die RREQ-Nachricht
mit der entsprechenden Erweiterung vom Typ 16 versendet hat. Dieses RREQ-Nachricht ist vom Knoten 2 weitergeleitet worden und wurde vom Kontextrouter beant-
Studienarbeit Falk Ahlendorf
4 Tests
44
wortet. Diese Antwort trifft dann mit Paket 185 beim Knoten 3 ein und trägt die
Erweiterung vom Typ 17.
Daraus lässt sich schlussfolgern, dass das Empfangen von CRREQ1 -Nachrichten und
das Versenden von CRREP2 -Nachrichten durch die Implementierung nicht beeinflusst
wurde.
4.5 Nachweis der Multicastkommunikation
Dieser Test beschäftigt sich mit dem Nachweis, dass die Kommunikation im MAODVProtokoll eine echte Multicastkommunikation ist.
Abbildung 4.11: Testaufbau für den Nachweis der Multicastkommunikation
Für diesen Test werden sechs Netzwerkknoten benötigt. Diese werden, wie in Grafik
4.11 zu sehen, angeordnet. Bei diesem Test sendet der Knoten 1 Datenpakete aus, die
der Knoten 3 weiterleiten muss, da Knoten 2 und 4 die Daten empfangen möchten.
1
CRREQ steht für Context Sensitives Route Request“ und ist ein erweitertes RREQ für Kontextan”
fragen an den Kontextrouter.
2
CRREP steht für Context Sensitives Route Reply“ und ist ein erweitertes RREP mit dem der
”
Kontextrouter auf CRREQ-Anfragen antworten kann.
Studienarbeit Falk Ahlendorf
4 Tests
45
Knoten 5 und 6 dürfen dabei am Anfang die Daten nicht weiterleiten. Somit darf Knoten 6 die Datenpakete nicht sehen. Zum Abschluss tritt Knoten 6 dem Multicastbaum
noch bei, um zu zeigen, dass er die Daten empfangen könnte, wenn er wollte.
Um festlegen zu können, welcher Knoten welchen anderen Knoten empfängt, wurde
dieser Test im Netzwerksimulator NS2 durchgeführt. Dabei wurde NS2 so konfiguriert,
dass der Simulator nur die physikalische Schicht und die MAC Schicht simuliert. Das
Routing der Datenpakete hingegen wird von den gleichen Clickscripten durchgeführt,
wie sie auch in den anderen Tests verwendet wurden.
Abbildung 4.12: IO-Graph für Datenpakete am Knoten 1
Abbildung 4.13: IO-Graph für Datenpakete am Knoten 2
Die Abbildung 4.12 zeigt die empfangenen und gesendeten Multicastpakete pro Sekunde des Knoten 1. Da der Knoten 1 zwei Pakete pro Sekunde aussendet und weil
er die weitergeleiteten Pakete von Knoten 3 nochmals empfängt weist, die Grafik vier
Pakete pro Sekunde aus. In den Abbildungen 4.13 und 4.15 sieht man das die Knoten
2 und 4 jeweils einen Datenstrom von zwei Paketen pro Sekunde über den ganzen Test
hinweg empfangen. Der IO-Graph für Knoten 3 (Abbildung 4.14) weist zu Beginn des
Tests wie bei Knoten 1 vier Pakete pro Sekunde aus. Es handelt sich hierbei um vier
Pakete pro Sekunde, weil die empfangenen Pakete von Knoten 1 und die weitergeleite-
Studienarbeit Falk Ahlendorf
4 Tests
46
Abbildung 4.14: IO-Graph für Datenpakete am Knoten 3
Abbildung 4.15: IO-Graph für Datenpakete am Knoten 4
Abbildung 4.16: IO-Graph für Datenpakete am Knoten 6
ten Pakete zusammengezählt werden. Bei 100s springt der Graph auf sechs Pakete pro
Sekunde. Dies liegt daran, da nun auch Knoten 6 dem Multicastbaum beigetreten ist.
Damit empfängt Knoten 3 nun zusätzlich noch die weitergeleiteten Pakete von Knoten
5. Wie auch schon Knoten 2 und Knoten 4 empfängt Knoten 6 zwei Pakete pro Sekunde, nachdem er dem Multicastbaum beigetreten ist. Zu sehen ist dies in Abbildungen
4.16.
Aus den IO-Graphen kann man nun einige Schlussfolgerungen ableiten.
Bei der Kommunikation, die durch die Implementierung realisiert wird, kann es sich
Studienarbeit Falk Ahlendorf
4 Tests
47
nicht um Unicasts handeln. Denn wäre dies der Fall, müsste der IO-Graph vom Knoten
1, zum einen acht Pakete pro Sekunde für die ersten hundert Sekunden ausweisen.
Jeweils zwei Pakete pro Sekunde für jeden Knoten und das noch mal zwei, weil die
Weiterleitungen von Knoten 3 auch mitgezählt werden müssen. Zum anderen müsste
ein Sprung im Graphen zu sehen sein, wenn Knoten 6 dem Multicastbaum beitritt.
Die Datenpakete werden auch nicht per Broadcast versendet, denn dann müsste
Knoten 6 die Datenpakete auch Empfangen, bevor er der Multicastgruppe beigetreten
ist. Des Weiteren kann es sich bei der Kommunikationsform auch nicht um Anycast
handeln. Denn Knoten 2, 4 und 6 empfangen einen kontinuierlichen Datenstrom, nachdem sie der Multicastgruppe beigetreten sind.
Somit kann geschlussfolgert werden, dass es sich bei der Kommunikationsform um
Multicast handelt. Da die Datenpakete an ausgewählte Knoten zugestellt werden können, ohne das sie mehrfach übertragen werden müssen.
Damit hat der Test gezeigt, dass es sich bei der Kommunikationsform, die durch das
MAODV Protokoll realisiert wird, um Multicast handelt.
4.6 Kontextrouter Multicasttest
Eine der Aufgaben dieser Arbeit war es, dass der Kontextrouter seine ICMP-Advertisements per Multicast versenden kann. Dies soll in diesem Test nachgewiesen werden.
Dazu gliedert sich der Test in zwei Teile. Im ersten Teil soll gezeigt werden, dass der
Kontextrouter seine ICMP-Advertisements per Multicast verschickt. Dafür wurde die
Konfiguration des Kontextrouters so verändert das er diese Nachrichten im Intervall
von 500ms aussendet. Dies verringert zum einen die Dauer des Tests erheblich. Zum
anderen wird die Wahrscheinlichkeit dafür, dass man keine solche Nachricht aufgrund
von Störungen im WLAN empfängt, deutlich vermindert. In diesem Test ist Knoten 1
der Group Leader“ und bereits einige Zeit der Multicastgruppe beigetreten. Knoten
”
3 wird außerhalb der Reichweite von Knoten 1 platziert und kann diesen nur über
Knoten 2 erreichen. Anschließend wird überprüft, ob die ICMP-Advertisements nur
dann weitergeleitet werden, wenn Knoten 3 auch dem Multicastbaum beigetreten ist.
Der zweite Teil zeigt das der Kontextrouter auch weiterhin auf ICMP-Solicitation
antwortet. Dazu wurde der Knoten 3 neben dem Kontextrouter platziert. Im Anschluss
wurden, mit Hilfe des aodv-uu-Clients, ICMP-Solicitation-Nachrichten ausgesendet.
Da der aodv-uu-Client nicht Multicastfähig ist, wurde außerdem die Konfiguration des
Knotens 2 so angepasst, dass er der Multicastgruppe beitritt. Dies ist erforderlich, weil
der Kontextrouter keine Antworten aussenden würde, wenn nicht mindestens 2 Knoten
Studienarbeit Falk Ahlendorf
4 Tests
48
Abbildung 4.17: IO-Graph für ICMP-Advertisements am Knoten 3
im Multicastbaum enthalten sind. Des Weiteren wurde für diesen Test die Konfiguration des Kontextrouters wieder auf seine Standardeinstellungen gestellt. Damit ist
wieder erkennbar, ob ein ICMP-Advertisement als Antwort auf eine ICMP-Solicitation
Nachricht gesendet wurde oder ob es nur zufällig gerade an der Stelle versandt worden
ist.
In Abbildung 4.17 ist der IO-Graphen des Knotens 3 für den ersten Test zu sehen.
Zur Erstellung des IO-Graphen wurde im Wireshark der Filter so eingestellt, dass nur
die eingehenden ICMP-Advertisements angezeigt werden. Der Knoten 3 ist in diesem
Test bei etwa 10s dem Multicastbaum beigetreten und hat ihn 35s nach Testbeginn
wieder verlassen. In der Abbildung 4.17 ist gut zu sehen, dass der Knoten 3 wie erwartet
ab 10s die ICMP-Nachrichten empfängt. Sobald aber Knoten 3 die Multicastgruppe
verlassen hat, werden die ICMP-Nachrichten auch nicht mehr weitergeleitet.
Abbildung 4.18: Kontextrouter antwortet auf ICMP-Solicitation-Nachrichten
Studienarbeit Falk Ahlendorf
4 Tests
49
Das Ergebnis des zweite Teils dieses Testes ist in Abblidung 4.18 zu sehen. Wie
Anfangs bereits beschrieben, hat Knoten 3 die ICMP-Solicitation-Nachrichten ausgesendet. Daraufhin hat der Kontextrouter mit ICMP-Advertisements geantwortet. Das
diese ICMP-Advertisments nicht zufällig an dieser Stelle ausgesendet wurden, ist daran
zu erkennen, dass es zwei Nachrichten mit einem Abstand von etwa 500ms sind. Das
Intervall in dem der Kontextrouter diese Nachrichten von sich aus aussendet, beträgt
aber 16s. Daraus lässt sich schlussfolgern, dass mindestens eine dieser Nachrichten
durch die ICMP-Solicitation-Nachrichten hervorgerufen worden ist.
Abschließend lässt sich zu diesem Test sagen, dass er zeigt, dass die ICMP-Advertisements erfolgreich per Multicast verschickt werden und das der Kontextrouter auch
auf ICMP-Solicitation-Nachrichten reagiert.
Studienarbeit Falk Ahlendorf
5 Zusammenfassung und Ausblick
50
5 Zusammenfassung und Ausblick
Die vorliegenden Arbeit stellt die Basis für Multicastrouting im DekoR dar. Dafür wurde das für diese Aufgabe verwendete MAODV-Protokoll ausführlich beschrieben. Im
weiteren ist auf die Schwachstellen des MAODV-Protokolls eingegangen worden und es
wurde eine mögliche Lösung beschrieben. Im Anschluss wurde eine Implementierung
des Protokolls vorgestellt. Diese Implementierung wurde auf ihre Funktionsfähigkeit
hin im DekoR und Netzwerksimulator NS2 untersucht. Die Ergebnisse dieser Untersuchung wurden dann im Rahmen dieser Arbeit vorgestellt. Damit ist es mit Hilfe dieser
Arbeit nun möglich, die ICMP-Advertisements und ICMP-Solicitation-Nachrichten im
DekoR mit Hilfe von Multicast zu verschicken. Somit werden die Einschränkungen, die
es für Broadcast-Nachrichten in einem Ad-Hoc-Netzwerk gibt, erfolgreich umgangen.
Die in dieser Arbeit vorgestellte Multicastimplementierung ist so allgemein gehalten, dass sie auch für andere Multicast-Nachrichten verwendet werden kann. So wäre
es zum Beispiel denkbar, dass man diese Funktionalität auch dem Client direkt zur
Verfügung stellt. Dafür müsste der Implementierung noch das Internet Group Mana”
gement Protocol“ hinzugefügt werden. Mit der Hilfe dieses Protokolls wäre ein Client
dann in der Lage der MAODV-Implementierung mitzuteilen, welche Multicastgruppe
er benötigt. Auf diese Weise könnten dann Radiosendungen per Multicast verbreitet
werden.
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
51
A Software und Konfigurationsdateien
A.1 Clickscript des Kontextrouters
// context-router script for 3 interfaces
// marco wenzel
// 2007-12
// modified by maik debes
// modified by karsten renhak
// modified by Falk Ahlendorf
//*************** configure interfaces
***************
AddressInfo(mydev0 192.168.1.10/24 00:50:04:EE:96:52); //fixed network
AddressInfo(mydev1 192.168.2.10/24 00:50:04:EE:95:A8); //wired aodv network
AddressInfo(mydev2 10.0.0.10/24 00:02:2D:49:8C:FF); //wireless aodv network
interfaces::AODVInterfaces(eth1 192.168.2.10/24 00:50:04:EE:95:A8,
eth3 10.0.0.10/24 00:02:2D:49:8C:FF);
//macfilter::Classifier(<OFFSET>/<MAC_ADRESSE>, -);
//macfilter::Classifier(6/001D7D38EC93, -);
//*************** configure routingtables ***************
mcasttable :: MulticastRoutingTable();
neighbours :: AODVNeighbours(interfaces,mcasttable);
cservers :: CServers;
clients :: CClients;
aconfig :: AdvertConfig;
//***************
element classes
***************
elementclass OutputClass{
input[0]
-> ipsrc :: IPClassifier(src mydev0, src mydev1, src mydev2, -);
ipsrc[0]
-> [0]output;
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
52
ipsrc[1]
-> [1]output;
ipsrc[2]
-> [2]output;
ipsrc[3]
-> ipdst :: IPClassifier(dst net mydev0,
dst net mydev1,
dst net mydev2, -);
ipdst[0]
-> [0]output;
ipdst[1]
-> [1]output;
ipdst[2]
-> [2]output;
ipdst[3]
-> tee::Tee(3);
tee[0]
-> [0]output;
tee[1]
-> [1]output;
tee[2]
-> [2]output;
}
elementclass OutputEth0{
input[0]
-> Queue(2000)
-> ToDevice(eth0);
}
elementclass OutputEth1{
input[0]
-> Queue(2000)
-> ToDevice(eth1);
}
elementclass OutputEth3{
input[0]
-> Queue(2000)
-> todev::ToDevice(eth3);
}
elementclass InputEth0{
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
53
$myaddr_ethernet |
FromDevice(eth0)
-> HostEtherFilter($myaddr_ethernet, DROP_OWN false, DROP_OTHER true)
-> output;
}
elementclass InputEth1{
$myaddr_ethernet |
FromDevice(eth1)
-> HostEtherFilter($myaddr_ethernet, DROP_OWN false, DROP_OTHER true)
-> Paint(0)
-> output;
}
//ohne macfilter
elementclass InputEth3{
$myaddr_ethernet |
FromDevice(eth3)
-> HostEtherFilter($myaddr_ethernet, DROP_OWN false, DROP_OTHER true)
-> Paint(1)
-> output;
}
//mit macfilter
/*
elementclass InputEth3{
$myaddr_ethernet |
FromDevice(eth3)
-> HostEtherFilter($myaddr_ethernet, DROP_OWN false, DROP_OTHER true)
-> macfilter::Classifier(6/00E000D1D034, -);
macfilter[0]
-> Discard;
macfilter[1]
-> Paint(1)
-> output;
}
*/
//macfilter ende
elementclass ClassifyARP{
$myaddr |
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
54
input[0]
//arp request, arp reply, other
-> arpclass :: Classifier(12/0806 20/0001, 12/0806 20/0002, -);
arpclass[0]
-> ARPResponder($myaddr, $myaddr)
-> [0]output;
arpclass[1]
-> [1]output
arpclass[2]
-> CheckIPHeader(OFFSET 14)
-> MarkIPHeader(14)
-> [2]output;
}
elementclass System{
FromHost(fake0, mydev0)
-> fromhost_cl :: Classifier(12/0806, -); //arp request, other
FromHost(fake1, mydev1)
-> fromhost_cl;
FromHost(fake2, mydev2)
-> fromhost_cl;
fromhost_cl[0]
-> ARPResponder(0.0.0.0/0 1:1:1:1:1:1)
-> ToHost(fake0);
fromhost_cl[1]
-> Strip(14)
-> CheckIPHeader
-> MarkIPHeader
-> output_cl :: IPClassifier(dst net mydev0, -);
output_cl[0]
-> [0]output;
output_cl[1]
-> [1]output;
input[0]
-> dstclass :: IPClassifier(dst net mydev0,
dst net mydev1,
dst net mydev2);
dstclass[0]
-> EtherEncap(0x0800, 1:1:1:1:1:1, mydev0)
-> CheckIPHeader(14)
-> MarkIPHeader(14)
-> ToHost(fake0);
dstclass[1]
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
55
-> EtherEncap(0x0800, 1:1:1:1:1:1, mydev1)
-> CheckIPHeader(14)
-> MarkIPHeader(14)
-> ToHost(fake1);
dstclass[2]
-> EtherEncap(0x0800, 1:1:1:1:1:1, mydev2)
-> CheckIPHeader(14)
-> MarkIPHeader(14)
-> ToHost(fake2);
}
elementclass FilterLocalhost{
input
//ping responder eingeschaltet:
-> localhost :: IPClassifier(dst host mydev0,
dst host mydev1,
dst host mydev2,
ip proto icmp && icmp type routersolicit,
- ); //cip0, cip1, cip2, solicit, other
localhost[0]
-> ping :: ICMPPingResponder;
localhost[1]
-> ping;
localhost[2]
-> ping;
localhost[3]
-> Strip(14)
-> classifyicmpcode :: Classifier(21/0a, -) //icmp-code = 10
//
-> classifyadvertdst :: IPClassifier(dst net mydev0,
//
dst net mydev1,
//
dst net mydev2);
-> classifyadvertdst :: Classifier(12/C0A801, 12/C0A802, 12/0A0000);
localhost[4]
-> classifyipdst :: IPClassifier(dst net mydev0, -);
ping[0]
-> Strip(14)
-> CheckICMPHeader
-> CheckIPHeader
-> MarkIPHeader
-> classifyipdst;
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
56
ping[1]
-> [0]output;
//ping responder ausgeschaltet:
/*
-> localhost :: IPClassifier(dst host mydev0,
dst host mydev1,
dst host mydev2,
ip proto icmp && icmp type routersolicit,
- ); //cip0, cip1, cip2, solicit, other
localhost[0]
-> [0]output;
localhost[1]
-> [0]output;
localhost[2]
-> [0]output;
localhost[3]
-> Strip(14)
-> classifyicmpcode :: Classifier(21/0a, -) //icmp-code = 10
-> classifyadvertdst :: IPClassifier(dst net mydev0,
dst net mydev1,
dst net mydev2);
localhost[4]
-> classifyipdst :: IPClassifier(dst net mydev0, -);
*/
//ping ende
classifyicmpcode[1]
-> Discard;
classifyadvertdst[2]
-> ICMPRouterAdvert(mydev2, 0, aconfig)
-> IPEncap(1, mydev2, 224.0.62.1, TTL 250)
-> EtherEncap(0x0800, mydev2, ff:ff:ff:ff:ff:ff)
-> [1]output;
classifyadvertdst[1]
-> ICMPRouterAdvert(mydev1, 0, aconfig)
-> IPEncap(1, mydev1, 255.255.255.255, TTL 2)
-> EtherEncap(0x0800, mydev1, ff:ff:ff:ff:ff:ff)
-> [1]output;
classifyadvertdst[0]
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
//
57
-> ICMPRouterAdvert(mydev0, 0, aconfig)
-> IPEncap(1, mydev0, 255.255.255.255, TTL 2)
-> IPEncap(1, mydev0, 255.255.255.255, TTL 2)
-> EtherEncap(0x0800, mydev0, ff:ff:ff:ff:ff:ff)
-> [1]output;
classifyipdst[0]
-> [2]output;
classifyipdst[1]
-> [3]output;
}
elementclass RouteDiscovery{
$genrreq |
input[0] //data
-> [0]discovery :: AODVWaitingForDiscovery($genrreq,neighbours);
input[1]
-> [1]discovery; //rrep
discovery[0]
-> [0]output; //found
discovery[1]
//not found
-> [1]output;
AODVLinkNeighboursDiscovery(neighbours,discovery);
}
elementclass ClassifyAODV {
input[0]
-> from_non_aodvsubnet :: IPClassifier(src net mydev0, - );
// handle CRREQ from mydev0 separately -// they aren’t from a AODV network
from_non_aodvsubnet[0]
-> aodv_crreq :: Classifier(42/01 66/10, - );
from_non_aodvsubnet[1] //RREQ, RERR, HELLO, RREP, MACT, GRPH, other
-> classify_aodv :: Classifier(42/01, 42/03,
42/02 22/01,
42/02, 42/05,
42/06, - );
aodv_crreq[0]
-> Paint(16)
//originator net mydev0 and CRREQ
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
58
// set IP address from incoming interface to destination annotation
-> SetIPAddress(mydev0)
-> [0]output; // CRREQ from mydev0
aodv_crreq[1]
//originator net = 192.168.1.x and no CRREQ!
-> [7]output; // other
classify_aodv[0]
-> [1]output;
classify_aodv[1]
-> [2]output;
classify_aodv[2]
-> [3]output;
classify_aodv[3]
-> [4]output;
classify_aodv[4]
-> [5]output;
classify_aodv[5]
-> [6]output;
classify_aodv[6]
-> [7]output;
// RREQ
// RERR
// HELLO
// RREP
// MACT
// GRPH
// other
}
//***************
element declarations
***************
outputcl :: OutputClass;
outputarpcl :: OutputClass;
outputeth0 :: OutputEth0;
outputeth1 :: OutputEth1;
outputeth3 :: OutputEth3;
classifyarpeth0 :: ClassifyARP(mydev0);
classifyarpeth1 :: ClassifyARP(mydev1);
classifyarpeth3 :: ClassifyARP(mydev2);
arpqueriereth0 :: ARPQuerier(mydev0);
arpqueriereth1 :: ARPQuerier(mydev1);
arpqueriereth3 :: ARPQuerier(mydev2);
classifyip :: IPClassifier(dst udp port 654, -);
//cip (on=30, cf=1; 34.Byte/Inhalt in Hex)
classifycip :: Classifier(34/9E, -);
cipforwarder :: ForwardCIP(cservers, clients);
system :: System;
classifycipout :: IPClassifier(dst net mydev0,
dst net mydev1,
dst net mydev2, -);
//AODV, other
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
59
filterlocalhost :: FilterLocalhost;
classifyaodv :: ClassifyAODV; // has to appear after "filterlocalhost"
lookup :: AODVLookUpRoute(neighbours);
//cip (on=16, cf=1), without ethernet-header
discoverycipclass :: Classifier(20/9E, -);
rreqclass :: Classifier(66/10, - ); //crreq (extension-type=16)
destinationclassifier :: AODVDestinationClassifier(neighbours,mcasttable);
setrrepheaders::AODVSetRREPHeaders()
routereply :: AODVGenerateRREP(neighbours,setrrepheaders,mcasttable);
rreqfwclass :: Classifier(50/C0A801, -); //destination net = 192.168.1.x
mcastforward :: mcast_forward(mcasttable,neighbours);
mtest :: mcast_datatest(mcasttable);
classifymcast :: IPClassifier(dst net 224.0.0.0/28,-);
mtest ->[1]mcastforward;
mcastforward[0]
-> classifyip;
mcastforward[1]
->SetIPChecksum
->outputcl;
classifymcast[0]
-> [1] mcastforward;
classifymcast[1]
-> outputcl;
rerr:: AODVGenerateRERR(neighbours,mcasttable)
-> outputcl;
knownclassifier :: AODVKnownClassifier(neighbours,mcasttable);
hello::AODVHelloGenerator(neighbours)
-> outputcl;
genrreq :: AODVGenerateRREQ(neighbours,knownclassifier,mcasttable)
-> hello;
routediscovery :: RouteDiscovery(genrreq);
mact :: mcast_MulticastActivationMessage(mcasttable,neighbours)
->StripToNetworkHeader
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
60
->outputarpcl;
mcastControler :: mcast_Controler(mcasttable,neighbours,genrreq,mact);
grouphello :: mcast_GroupHello(mcasttable,
neighbours,
mcastControler) -> outputcl;
//***************
element connections
***************
InputEth0(mydev0)
-> classifyarpeth0;
classifyarpeth0[0]
-> outputeth0; //arp request
classifyarpeth0[1]
-> [1]arpqueriereth0; //arp reply
classifyarpeth0[2]
-> [0]mcastforward; //other
InputEth1(mydev1)
-> classifyarpeth1;
classifyarpeth1[0]
-> outputeth1; //arp request
classifyarpeth1[1]
-> [1]arpqueriereth1; //arp reply
classifyarpeth1[2]
-> AODVTrackNeighbours(rerr, neighbours,mcasttable)
-> [0]mcastforward; //other
InputEth3(mydev2)
-> classifyarpeth3;
classifyarpeth3[0]
-> outputeth3; //arp request
classifyarpeth3[1]
-> [1]arpqueriereth3; //arp reply
classifyarpeth3[2]
-> AODVTrackNeighbours(rerr, neighbours,mcasttable)
-> [0]mcastforward; //other
classifyip[0]
-> classifyaodv;
classifyip[1]
-> classifycip;
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
61
classifycip[0] //cip
-> Strip(14)
-> CheckIPHeader
-> [0]cipforwarder
-> CheckIPHeader
-> MarkIPHeader
-> classifycipout;
classifycip[1] //ip
-> filterlocalhost;
icmperr::ICMPError(mydev1, 3, 1)
-> system;
cipforwarder[1]
-> icmperr;
classifycipout[0]
-> FixCIPSrc(mydev0)
-> outputarpcl;
classifycipout[1]
-> FixCIPSrc(mydev1)
-> Paint(3)
-> lookup;
classifycipout[2]
-> FixCIPSrc(mydev2)
-> Paint(3)
-> lookup;
classifycipout[3]
-> Paint(3)
-> lookup;
system[0]
-> outputarpcl
system[1]
-> Paint(3)
-> lookup;
filterlocalhost[0] //ip for system
-> Strip(14)
-> system;
filterlocalhost[1] //advert
-> classifymcast;
filterlocalhost[2] //ip for others
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
62
-> Strip(14)
-> outputarpcl;
filterlocalhost[3] //ip for others
-> Paint(3)
-> lookup;
lookup[0] //known
-> StripToNetworkHeader
-> outputarpcl;
lookup[1] //unknown
-> [0]routediscovery;
lookup[2] //rerr
-> rerr;
routediscovery[0] //found
-> SetIPChecksum
-> StripToNetworkHeader
-> outputarpcl;
routediscovery[1] //not found
-> discoverycipclass;
discoverycipclass[0] //cip
-> [1]cipforwarder
discoverycipclass[1] //ip
-> icmperr;
classifyaodv[0] //CRREQ from non-AODV network (mydev0)
-> GenerateCRREP(cservers,
clients,
neighbours,
setrrepheaders,
FCRREQPAINT 16)
-> setrrepheaders;
classifyaodv[1] //RREQ
-> AODVUpdateNeighbours(neighbours)
-> knownclassifier;
classifyaodv[2] //RERR
-> [1]rerr;
classifyaodv[3] //HELLO
-> AODVUpdateNeighbours(neighbours)
-> Discard;
classifyaodv[4] //RREP
-> AODVUpdateNeighbours(neighbours)
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
63
-> destinationclassifier;
classifyaodv[5] //MACT
-> mact;
classifyaodv[6] //GRPH
-> grouphello;
classifyaodv[7] //other
-> Discard;
knownclassifier[0] //reply
-> rreqclass;
knownclassifier[1] //forward
-> rreqfwclass;
rreqclass[0] //CRREQ
//-> Print(routrequest,PRINTANNO true)
-> GenerateCRREP(cservers,clients,neighbours,setrrepheaders)
-> setrrepheaders;
rreqclass[1] //CRREP
-> routereply;
destinationclassifier[0]
-> [1]routediscovery;
destinationclassifier[1]
-> SetIPChecksum
-> SetUDPChecksum
-> StripToNetworkHeader
-> outputarpcl;
destinationclassifier[2]
-> Paint(2)
-> [0]routediscovery;
destinationclassifier[3]
-> mcastControler;
rreqfwclass[0] //dst in net mydev0 -> reply
-> GenerateGWRREP(neighbours,setrrepheaders)
-> setrrepheaders;
rreqfwclass[1] //dst unknown -> forward
-> StripToNetworkHeader
-> outputarpcl;
routereply
-> setrrepheaders
-> SetUDPChecksum
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
64
-> SetIPChecksum
-> outputarpcl;
outputcl[0]
-> outputeth0;
outputcl[1]
-> outputeth1;
outputcl[2]
-> outputeth3;
outputarpcl[0]
-> arpqueriereth0
-> outputeth0;
outputarpcl[1]
-> arpqueriereth1
-> outputeth1;
outputarpcl[2]
-> arpqueriereth3
-> outputeth3;
//pings versenden
//ICMPPingSource(mydev2, 10.0.0.30)
// -> Paint(3)
// -> IPPrint(ping)
// -> lookup;
A.2 Clickscript der Zwischenknoten
AddressInfo(mydev0 10.0.0.20/24 00:09:5B:BB:36:08);
interfaces::AODVInterfaces(
eth0 10.0.0.20/24 00:09:5B:BB:36:08
);
// *** rotuingtables ***
mcasttable :: MulticastRoutingTable();
neighbours :: AODVNeighbours(interfaces,mcasttable);
// *** element classes ***
elementclass OutputClass{
input[0] -> ipsrc :: IPClassifier(src mydev0, -);
ipsrc[0] -> [0]output;
ipsrc[1] -> ipdst :: IPClassifier(dst net mydev0, -);
ipdst[0] -> [0]output;
ipdst[1] -> [0]output;
}
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
65
elementclass OutputEth0{
input[0]
->Queue(2000)
->ToDevice(wlan0);
}
elementclass InputEth0{
$myaddr_ethernet |
FromDevice(wlan0)
-> HostEtherFilter($myaddr_ethernet, DROP_OWN false, DROP_OTHER true)
-> Paint(0)
-> output;
}
elementclass ClassifyARP{
$myaddr |
input[0] -> arpclass :: Classifier(12/0806 20/0001, 12/0806 20/0002,-);
arpclass[0]
-> ARPResponder($myaddr, $myaddr)
-> [0]output;
arpclass[1] -> [1]output;
arpclass[2]
-> CheckIPHeader(OFFSET 14)
-> MarkIPHeader(14)
-> [2]output;
}
elementclass System{
FromHost(fake0, mydev0) -> fromhost_cl ::Classifier(12/0806,-);
fromhost_cl[0]
-> ARPResponder(0.0.0.0/0 1:1:1:1:1:1)
-> ToHost(fake0);
fromhost_cl[1]
-> Strip(14)
-> CheckIPHeader
-> MarkIPHeader
-> [0]output;
input[0]
-> EtherEncap(0x800, 1:1:1:1:1:1, mydev0)
-> CheckIPHeader(14)
-> MarkIPHeader(14)
-> ToHost(fake0);
}
elementclass FilterLocalhost{
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
66
input -> localhost::IPClassifier(dst host mydev0,
dest host 255.255.255.255,
-);
localhost[0] -> ping:: ICMPPingResponder;
localhost[1] -> [2]output;
localhost[2] -> [1]output;
ping[0]
-> Strip(14)
-> CheckICMPHeader
-> CheckIPHeader
-> MarkIPHeader
-> [1]output;
ping[1] -> [0]output;
}
elementclass RouteDiscovery{
$genrreq |
input[0] -> [0]discovery :: AODVWaitingForDiscovery($genrreq, neighbours);
input[1] -> [1]discovery; //RREP
discovery[0] -> [0]output;
discovery[1] -> [1]output;
AODVLinkNeighboursDiscovery(neighbours,discovery);
}
//*** element declarations ***
outputcl :: OutputClass;
outputarpcl :: OutputClass;
outputeth0 :: OutputEth0;
classifyarpeth0 :: ClassifyARP(mydev0);
arpqueriereth0 :: ARPQuerier(mydev0);
classifyip :: IPClassifier(dst udp port 654, -);
classifyaodv :: Classifier(42/01, 42/03,
42/02 22/01,
42/02, 42/05,
42/06, -);
system :: System;
filterlocalhost :: FilterLocalhost;
lookup :: AODVLookUpRoute(neighbours);
destinationclassifier :: AODVDestinationClassifier(neighbours,mcasttable);
setrrepheaders :: AODVSetRREPHeaders()
routereply :: AODVGenerateRREP(neighbours,setrrepheaders,mcasttable);
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
67
outputcl[0] -> outputeth0;
outputarpcl[0]
-> arpqueriereth0
-> outputeth0;
rerr ::AODVGenerateRERR(neighbours,mcasttable) -> outputcl;
knownclassifier :: AODVKnownClassifier(neighbours, mcasttable);
hello :: AODVHelloGenerator(neighbours) ->outputcl;
mact :: mcast_MulticastActivationMessage(mcasttable,neighbours)
->StripToNetworkHeader
->outputarpcl;
genrreq :: AODVGenerateRREQ(neighbours,
knownclassifier,
mcasttable) ->hello;
routediscovery :: RouteDiscovery(genrreq);
mcastControler :: mcast_Controler(mcasttable,neighbours,genrreq,mact);
grouphello :: mcast_GroupHello(mcasttable,
neighbours,
mcastControler) ->outputcl;
forward :: mcast_forward(mcasttable,neighbours);
mtest :: mcast_datatest(mcasttable);
//**** element connections ****
InputEth0(mydev0) ->classifyarpeth0;
classifyarpeth0[0] -> outputeth0;
classifyarpeth0[1] -> [1]arpqueriereth0;
classifyarpeth0[2]
-> AODVTrackNeighbours(rerr, neighbours,mcasttable)
-> [0]forward;
forward[0] -> classifyip;
forward[1] -> outputcl;
mtest -> [1]forward;
classifyip[0] -> classifyaodv;
classifyip[1] -> filterlocalhost;
icmperr:: ICMPError(mydev0,3,1) -> system;
system
-> Paint(3)
-> lookup;
filterlocalhost[0]
-> Strip(14)
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
68
-> system;
filterlocalhost[1]
->Paint(3)
->lookup;
filterlocalhost[2]
-> Strip(14)
-> CheckIPHeader
-> DecIPTTL
-> EtherEncap(0x800,mydev0, ff:ff:ff:ff:ff:ff)
-> outputcl;
lookup[0]
-> StripToNetworkHeader
-> outputarpcl;
lookup[1] -> [0]routediscovery;
lookup[2] -> rerr;
routediscovery[0]
->SetIPChecksum
->StripToNetworkHeader
->outputcl;
routediscovery[1]->icmperr;
classifyaodv[0]
->AODVUpdateNeighbours(neighbours)
->knownclassifier;
classifyaodv[1] -> [1]rerr;
classifyaodv[2]
->AODVUpdateNeighbours(neighbours)
->Discard;
classifyaodv[3]
->AODVUpdateNeighbours(neighbours)
->destinationclassifier;
classifyaodv[4] //MACT
// ->AODVUpdateNeighbours(neighbours)
// ->Print(mact,64)
->mact;
classifyaodv[5] //GRPH
// ->AODVUpdateNeighbours(neighbours)
// ->Print(grph,64)
->grouphello;
classifyaodv[6]
->Discard;
Studienarbeit Falk Ahlendorf
A Software und Konfigurationsdateien
69
destinationclassifier[0] ->[1]routediscovery;
destinationclassifier[1]
->SetIPChecksum
->SetUDPChecksum
->StripToNetworkHeader
->outputarpcl;
destinationclassifier[2]
->Paint(2)
->[0]routediscovery;
destinationclassifier[3] -> mcastControler;
knownclassifier[0] -> routereply;
knownclassifier[1]
-> StripToNetworkHeader
->outputarpcl;
routereply
->setrrepheaders
->SetUDPChecksum
->SetIPChecksum
->outputarpcl;
Studienarbeit Falk Ahlendorf
Literaturverzeichnis
70
Literaturverzeichnis
[Bake95]
F. Baker. RFC1812: Requirements for IP Version 4 Routers. Internet
RFCs, 1995.
[Debe07]
Maik Debes. Kontextsensitives Routing - Architekturkonzept -. Interner
Forschungsbericht, June 2007.
[DKBD+ 03] D. Dharmaraju, M. Karir, J.S. Baras, S. Das und T. Technologies. An
Implementation Study of Multicast Extensions of AODV. SIMULATION
SERIES 35(4), 2003, S. 122–130.
[Info06]
Information Sciences Institute of the University of Southern California,
http://www.isi.edu/nsnam/dist/. The Network Simulator - ns-2, September 2006. NS2 Hompage.
[MIT07]
MIT, http://read.cs.ucla.edu/click/. The Click Modular Router
Project, September 2007. Click Hompage.
[MoCP08]
L. Mottola, G. Cugola und G.P. Picco. A Self-Repairing Tree Topology
Enabling Content-Based Routing in Mobile Ad Hoc Networks. IEEE
Transactions on Mobile Computing 7(8), 2008, S. 946–960.
[NiSu05]
P. Ning und K. Sun. How to misuse AODV: A case study of insider
attacks against mobile ad-hoc routing protocols. Ad Hoc Networks 3(6),
2005, S. 795–819.
[PeBRD01] C.E. Perkins, EM Belding-Royer und SR Das. IP flooding in ad hoc
mobile networks. draft-ietf-manet-bcast-02. txt, November Band 14, 2001.
[PeBRD03] C. Perkins, E. Belding-Royer und S. Das. RFC3561: Ad hoc On-Demand
Distance Vector (AODV) Routing. Internet RFCs, 2003.
[Renh08]
Karsten Renhak. Entwicklung einer Clientsoftware zur Unterstützung des
kontextsensitiven Routings. Diplomarbeit, TU-Ilmenau, 2008.
Studienarbeit Falk Ahlendorf
Literaturverzeichnis
71
[RoPe99]
E.M. Royer und C.E. Perkins. Multicast operation of the ad-hoc ondemand distance vector routing protocol. In Proceedings of the 5th annual
ACM/IEEE international conference on Mobile computing and networking. ACM New York, NY, USA, 1999, S. 207–218.
[RoPe00]
E.M. Royer und C.E. Perkins. Multicast Ad hoc On-Demand Distance Vector (MAODV) Routing. IETF MANET Working Group Internet
Draft, 2000.
[Wenz08]
Marco Wenzel. Konzeption und Umsetzung eines Demonstrators zur Verifikation kontextsensitiver Routingprotokolle. Diplomarbeit, TU-Ilmenau,
2008.
[Wiki08a]
Wikipedia, http://de.wikipedia.org/wiki/Ad-hoc-Netz.
Netzwerke, November 2008.
[Wiki08b]
Wikipedia, http://en.wikipedia.org/wiki/Anycast. Anycast, November 2008.
[Wiki08c]
Wikipedia, http://de.wikipedia.org/wiki/Broadcast.
November 2008.
[Wiki08d]
Wikipedia, http://en.wikipedia.org/wiki/Mobile_ad-hoc_network.
Mobile Ad-hoc-Netzwerke, November 2008.
[Wiki08e]
Wikipedia, http://en.wikipedia.org/wiki/Multicast. Multicast, November 2008.
[Wiki08f]
Wikipedia, http://de.wikipedia.org/wiki/Routing. Routing, November 2008.
[Wiki08g]
Wikipedia, http://en.wikipedia.org/wiki/Unicast. Unicast, October
2008.
Ad-hoc-
Broadcast,
Studienarbeit Falk Ahlendorf
Abbildungsverzeichnis
72
Abbildungsverzeichnis
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
RREQ-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . .
Rebuild-Erweiterung . . . . . . . . . . . . . . . . . . . . . . . .
Group Leader“-Erweiterung . . . . . . . . . . . . . . . . . . . .
”
RREP-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . .
Informations-Erweiterung . . . . . . . . . . . . . . . . . . . . .
MACT-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . .
GRPH-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . .
Aktivitätsdiagramm für das Beitreten zu einer Multicastgruppe
Aktivitätsdiagramm für das Verlassen einer Multicastgruppe . .
Aktivitätsdiagramm für das Reparieren eines Links . . . . . . .
Aktivitätsdiagramm für das weiterleiten von Datenpaketen . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
11
12
13
13
14
16
18
19
21
24
3.1
Klassendiagramm für die Multicastroutingtabelle . . . . . . . . . . . .
29
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
Aufbau des gesammten Demonstrators . . . . . . . . . . . . . . .
Empfangsbereiche der drei verwendeten Rechner . . . . . . . . . .
Knoten 1 sendet die gewünschte Reboot-MACT . . . . . . . . . .
Knoten 1 sendet die RREQ-Nachrichten . . . . . . . . . . . . . .
Knoten 1 wird Group Leader“ und sendet die GRPH-Nachrichten
”
Knoten 3 sendet RREQ-Nachrichten . . . . . . . . . . . . . . . .
Knoten 3 aktiviert die Multicastroute . . . . . . . . . . . . . . . .
Knoten 3 repariert die Multicastroute . . . . . . . . . . . . . . . .
IO Graph für die Multicastdatenpakete des Knoten 3 . . . . . . .
CRREQ und CREEP am Knoten 3 . . . . . . . . . . . . . . . . .
Testaufbau für den Nachweis der Multicastkommunikation . . . .
IO-Graph für Datenpakete am Knoten 1 . . . . . . . . . . . . . .
IO-Graph für Datenpakete am Knoten 2 . . . . . . . . . . . . . .
IO-Graph für Datenpakete am Knoten 3 . . . . . . . . . . . . . .
IO-Graph für Datenpakete am Knoten 4 . . . . . . . . . . . . . .
37
38
39
40
40
41
42
42
43
43
44
45
45
46
46
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Studienarbeit Falk Ahlendorf
Abbildungsverzeichnis
73
4.16 IO-Graph für Datenpakete am Knoten 6 . . . . . . . . . . . . . . . . .
4.17 IO-Graph für ICMP-Advertisements am Knoten 3 . . . . . . . . . . . .
4.18 Kontextrouter antwortet auf ICMP-Solicitation-Nachrichten . . . . . .
46
48
48
Studienarbeit Falk Ahlendorf
Tabellenverzeichnis
74
Tabellenverzeichnis
Studienarbeit Falk Ahlendorf
Abkürzungsverzeichnis und Formelzeichen
75
Abkürzungsverzeichnis und
Formelzeichen
ACK . . . . . . . . . . . . . . .
AODV . . . . . . . . . . . . .
ARP . . . . . . . . . . . . . . .
CRREP . . . . . . . . . . . .
CRREQ . . . . . . . . . . . .
DekoR . . . . . . . . . . . . .
GRPH . . . . . . . . . . . . .
ICMP . . . . . . . . . . . . . .
ID . . . . . . . . . . . . . . . . .
IETF . . . . . . . . . . . . . . .
IO . . . . . . . . . . . . . . . . .
IP . . . . . . . . . . . . . . . . . .
MAC . . . . . . . . . . . . . . .
MACT . . . . . . . . . . . . .
MAODV . . . . . . . . . . .
MIT . . . . . . . . . . . . . . .
NS2 . . . . . . . . . . . . . . . .
PDA . . . . . . . . . . . . . . .
RFC . . . . . . . . . . . . . . .
RREP . . . . . . . . . . . . . .
RREP-ACK . . . . . . . .
RREQ . . . . . . . . . . . . .
RRER . . . . . . . . . . . . .
TTL . . . . . . . . . . . . . . .
UDP . . . . . . . . . . . . . . .
WLAN . . . . . . . . . . . . .
Acknowledgement
Adoc On-Demand Distance Vector
Adress Resolution Protocol
Context Sensitive Route Reply
Context Sensitive Route Reqest
Demonstrator für kontextsensitives Routing
Group Hello
Internet Control Message Protocol
Identification
Internet Engineering Task Force
Input Output
Internet Protocol
Media Access Control
Multicast Activation
Multicast Adoc On-Demand Distance Vector
Massachusetts Institute of Technology
The Network Simulator 2
Personal Digital Assistant
Request For Comments
Route Reply
Route Reply Acknowledgement
Route Reqest
Route Error
Time To Live
User Datagram Protocol
Wireless Local Area Network
Studienarbeit Falk Ahlendorf
Erklärung
76
Erklärung
Die vorliegende Arbeit habe ich selbstständig ohne Benutzung anderer als der angegebenen Quellen angefertigt. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten Quellen entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit ist
in gleicher oder ähnlicher Form oder auszugsweise im Rahmen einer oder anderer Prüfungen noch nicht vorgelegt worden.
Ilmenau, den 09. 12. 2008
Falk Ahlendorf
Studienarbeit Falk Ahlendorf