Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik. Medienprojekt. Ad-hoc-Netze / heterogene Netze

Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik Medienprojekt Ad-hoc-Netze / heterogene Netze vorgelegt von: Alexander Marr eingereicht am: 13. 04. 2006 geboren am: Studiengang: Studienrichtung: Medientechnik AVT 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... Mobilkommunikation ermöglicht den Zugang zu Informationen und Diensten. Viele Bereiche sind durch verschiedene drahtlose Netzinfrastrukturen abgedeckt. Um den Randbereich der Infrastrukturnetze zu erweitern, den Zugang zu Festnetzen zu ermöglichen oder eine eigene Kommunikation in nicht abgedeckten Bereichen einzurichten, stellen mobile Ad-hoc-Netze eine gute Möglichkeit dar. Ziel dieses Medienprojektes ist, die Zusammenarbeit von Ad-hoc-Netzen mit herkömmlichen Fest- und Mobilfunknetzen zu untersuchen. Es werden verschiedene Arten von Netzübergängen dargestellt und verglichen. Die in der vorliegenden Arbeit aufgeführten Messungen wurden an einem realen Netz durchgeführt....

Abstract... Mobil communication enables the access to informations and services. A lot of locations are equipped with different wireless networks. An alternative is a mobile ad-hocnetwork to expand the infrastructure network, to allow the access to fixed line network or to make an autonomous communication. The intention of this media project is to explore the interaction between ad-hoc-networks and ordinary wire and wireless networks. Important is the character of the net crossing, the additional arrangements and the possibilities. The measurements in this thesis were made with real networks....

Inhaltsverzeichnis i Inhaltsverzeichnis 1 Einleitung 1 2 Grundlagen 3 2.1 MANET................................... 3 2.2 OLSR.................................... 5 2.3 Gateway................................... 6 2.4 Netzwerkbrücke............................... 7 2.5 Dynamic DNS................................ 9 2.6 VPN..................................... 9 2.7 Voice over IP................................ 11 2.8 Mobile IP.................................. 12 3 Testaufbau 14 3.1 Testabsichten................................ 14 3.2 Testumgebung................................ 14 3.2.1 Hardware.............................. 14 3.2.2 Routing............................... 15 3.2.3 Software............................... 16 3.3 Ad-hoc-Netze mit Internet Connection Sharing.............. 17 3.4 Ad-hoc-Netze und Voice over IP...................... 21 3.5 Virtual Private Network über Ad-hoc-Netze............... 23 3.6 Netzübergreifendes Ad-hoc-Routing.................... 24 4 Messungen und Auswertung 26 4.1 Messungen zum Internet Connection Sharing............... 27 4.2 Messungen zu Voice over IP........................ 31 4.3 Messungen zu VPN............................. 32 4.4 Messungen zum netzübergreifenden Ad-hoc-Routing........... 33 5 Ausblick 36 Medienprojekt Alexander Marr

Inhaltsverzeichnis ii 6 Zusammenfassung 37 A Messungen 40 B Konfiguration 45 Literaturverzeichnis 49 Abbildungsverzeichnis 51 Tabellenverzeichnis 52 Abkürzungsverzeichnis 53 Erklärung 55 Medienprojekt Alexander Marr

1 Einleitung 1 1 Einleitung Die Bedeutung der Vernetzung von Systemen und Menschen steigt ständig. Zahlreiche Dienste bauen auf verschiedene Netze auf und werden ständig genutzt. Nicht nur im Büro und Business sondern auch im privaten mobilen Bereich steigt das Maß der Vernetzung weiter. Dennoch wird von den Netzbetreibern auf betriebswirtschaftliche Faktoren sehr großer Wert gelegt. Deshalb werden neue Netze zuerst in Ballungszentren errichtet und langsam über weitere stark frequentierte Regionen ausgebaut. In dünn besiedelten, ländlichen Gegenden erfolgt aus Kostengründen oft kein oder nur lückenhafter Netzausbau. In vielen Wald- und Naturgebieten ist oft keinerlei Netz nutzbar, da keine Netzinfrastruktur vorhanden ist. Die meisten drahtlosen Netze benötigen eine Infrastruktur. Dadurch werden der Medienzugriff, die Datenweiterleitung und der Zugang zu anderen Netzen geregelt. Die Kommunikation zwischen den Endgeräten kann meist nur über einen Zugangspunkt erfolgen. Außerhalb des Empfangsbereichs der Zugangspunkte kann das Netz und deren Dienste nicht genutzt werden. Ad-hoc-Netze stellen eine Möglichkeit dar, über die Netzgrenzen hinaus das Netz nutzen zu können. Sie benötigen keine Infrastruktur wie beispielsweise Zugangspunkte. Jedes Endgerät kommuniziert direkt (Peer-to-Peer) oder indirekt (Multihop) mit anderen Endgeräten. Die Mobile-Nodes vereinen Endgerät und Router in einem. Durch diese Selbstorganisation existiert keine zentrale Instanz für das Management. Auf diese Art können sich spontan Netze bilden. Somit wird höchste Flexibilität erreicht. Diese Netze können dazu genutzt werden, in Gebieten ohne Infrastruktur untereinander zu kommunizieren oder den Randbereich von vorhandenen Netzen kostengünstig und ohne weiteren Netzausbau zu erweitern. Medienprojekt Alexander Marr

1 Einleitung 2 Diese Arbeit beschäftigt sich mit Möglichkeiten, Ad-hoc-Netze mit anderen Netzen zu verbinden. Mit Hilfe einer Testumgebung werden diese Möglichkeiten umgesetzt und Messungen durchgeführt. Im Rahmen des Medienprojektes reiht sich diese Arbeit Adhoc-Netze / heterogene Netze zwischen die Arbeit von Sabine Nowak: Ad-hoc-Netze / multimediale Anwendungen und die Arbeit von Alexander Pschichholz: Ad-hoc- Netze / kontextsensitive Anwendungen ein. Hierbei zeigt der Teil multimediale Anwendungen, wie die Echtzeitfähigkeit verschiedener Netzkonfigurationen zu bewerten ist. Der Abschnitt heterogene Netze be- schäftigt sich mit der Verbindung zu anderen Fest- und Mobilfunknetzen und greift bei der Bewertung auf die Echtzeitfähigkeit zurück. Die Arbeit kontextsensitive Anwendungen zeigt beispielhaft die Möglichkeit, einen kontextsensitiven Dienst im Ad- hoc-netz nutzbar zu machen. Voraussetzung ist das Bestehen von Verbindungen zu anderen Netzen. Medienprojekt Alexander Marr

2 Grundlagen 3 2 Grundlagen 2.1 MANET Ein mobiles Ad-hoc-Netz ist ein selbst konfigurierendes Netz, meist im Funkbetrieb, welches im Peer-to-Peer Modus Multihop-Routing unterstützt. Das Fehlen einer übergeordneten Infrastruktur bringt ein Höchstmaß an Freiheit aber auch die Notwendigkeit, Routingintelligenz in die Endgeräte zu bringen. Auch im Internet kommen verteilte adaptive Routingverfahren zum Einsatz aber die Wegewahlentscheidungen werden in Routern getroffen. Beim Distance Vector Routing speichert jeder Router eine Tabelle mit jedem Ziel und den besten Entfernungen. Der periodische Tabellenaustausch mit allen Nachbarn vervollständigt das Bild des Netzes. Die Count-to-infinity-Problematik ist sehr kritisch bei einem sich schnell ändernden Netz. Eine Optimierung für Ad-hoc- Netze ist, die Routinganforderung reaktiv zu behandeln. Hierbei wird die Routingtabelle nur für den Zeitraum einer Übertragung aktuell gehalten. Dies minimiert die Count-to-infinity-Problematik. Bei Link State Routing erfolgt eine Nachbarerkennung mit periodisch versendeten HELLO-Paketen. Die empfangenen ECHO-Pakete werden ausgewertet. Das erstellte Link-State-Paket wird an alle Nachbarn gesendet. Da Funknetze nur über sehr begrenzte Bandbreiten verfügen und das Ad-hoc-Netz sich ständig ändern kann, ist ein Optimum zwischen schneller Reaktion auf Topologieänderung und geringer Netzlast zu finden. Beide Anforderungen konkurrieren miteinander. Es gibt zahlreiche Ansätze von Routingverfahren und -protokollen sowie bereits einige lauffähige Implementationen. Prinzipiell kann man die Ad-hoc-Routingverfahren wie folgt klassifizieren: Positionsbasierte Routingverfahren Bei diesem Ansatz werden Positionsdaten, wie beispielsweise GPS, zur Ermittlung des besten Pfades zwischen Quell- und Zielknoten genutzt. Bei der Routingentscheidung zwischen mehreren möglichen Wegen wird die geringste Distanz zum Zielknoten gewählt. Allerdings werden die sehr unterschiedlichen Qualitäten der Funkstrecken nicht Medienprojekt Alexander Marr

2 Grundlagen 4 berücksichtigt. Derzeit existiert keine lauffähige Implementierung für positionsbasierte Routingverfahren. Topologiebasierte Routingverfahren Bei diesem Verfahren werden die Informationen über die Nachbarschaftsbeziehungen der Knoten genutzt, um miteinander zu kommunizieren. Die Nachbarschaftserkennung wird meist mit HELLO-Paketen gewonnen und kann untereinander ausgetauscht werden. Sowohl topologiebasierte Verfahren als auch positionsbasierte Verfahren unterteilen sich weiter in proaktive, reaktive und hybride Verfahren. Proaktive Routingverfahren (Table-driven) Die Routen zwischen den Knoten werden sofort bestimmt und durch Kontrollpakete ständig überwacht. Der Vorteil besteht darin, dass die Pakete sofort versendet werden können, da die Routingtabellen aktuell sind. Somit hat der Nutzer immer eine aktuelle Sicht des Netzes. Nachteilig ist die höhere Netzlast durch zyklisch versendete Kontrollpakete. Dies macht sich besonders bei größeren Netzen mit vielen Nodes bemerkbar. Um nicht das gesamte Netz mit HELLO-Paketen zu fluten werden verschiedene Optimierungsansätze verwendet. Reaktive Routingverfahren (On demand) Die Routen zwischen den Knoten werden erst ermittelt, wenn sie benötigt werden. Das Versenden von Kontrollpaketen erfolgt erst, wenn eine Sendeanforderung für Datenpakete vorliegt. Das Verfahren erzeugt keine Netzlast im Ruhezustand. Nachteilig ist die Verzögerung beim Paketversand, die durch den Aufbau der Routingtabelle entsteht. Außerdem bekommt der Nutzer keine Sicht des aktuellen Netzes, ohne selbst Daten zu versenden. Hybride Routingverfahren Diese stellen eine Kombination aus reaktiven und proaktiven Routingverfahren dar. So kann der Aufbau der Routingtabelle im Nahbereich proaktiv und im Fernbereich reaktiv erfolgen. Dies kombiniert ein schnelles Paketversenden mit einer geringen Netzlast, besonders bei größeren Netzen. (Quellen: [Wiki06a], [M.05]) Medienprojekt Alexander Marr

2 Grundlagen 5 2.2 OLSR Optimized-Link-State-Routing ist ein proaktives, schleifenfreies und flaches Routingprotokoll für Ad-hoc-Netze nach RFC3626 (IETF, 2003e). Damit in großen Netzen die CPU zur Ermittlung der Routen nicht vollständig ausgelastet wird, verwendet OLSR einen Hysterese-Algorithmus und Multipoint-Relays. Der Hysterese-Algorithmus verhindert, dass in größeren Netzen kurzfristig sichtbare Nodes in das Routing mit einbezogen werden. Somit werden unsichere Routingwege minimiert. Mit den Multipoint-Relays werden die protokollbedingten Netzlasten (TC Messages) herabgesetzt. Somit wird die Übertragung der Routing-Informationen auf die nächstgelegenen Knoten beschränkt. OLSR ist wahlweise mit IPv4 und IPv6 funktionstüchtig. Ab der Version 0.4.8 enthält das Protokoll die Linkgüte-Messung Expected Transmission Count, um einen Kompromiss aus kürzester Route und größtem Datendurchsatz zu finden. Somit kann die Link-Qualität bewertet werden. Vor ETX gab es keine Möglichkeit, zwischen zwei Links den Besseren auszuwählen. Dafür werden die HELLO-Rundsendungen miteinander verglichen. Jeder Knoten sendet periodisch HELLO-Pakete als UDP-Broadcast ohne Empfangsbestätigung und ohne Neuaussendung. Die Anzahl der selbst ausgesendeten und die Anzahl der empfangenen Pakete der einzelnen Knoten werden gegenüber gestellt. Ist die Anzahl der Pakete eines Knotens geringer als die selbst ausgesendeten Pakete, ist von diesem Link ein Paketverlust aufgetreten, woraus sich ein schlechter Übertragungsweg schlussfolgern lässt. Schlechten Links wird bei Routingentscheidungen eine geringere Priorität zugewiesen. ETX arbeitet auf Layer3. ETX ist nicht konform mit der RFC3626-Spezifikation was dazu führt, das OLSR-Knoten ohne ETX von den OLSR-Knoten mit ETX in der Routingentscheidung nicht berücksichtigt. Um die Echtzeitanwendungen zu optimieren, beschäftigt sich derzeit ein Team am französischen Laboratoire de Recherche en Informatique mit einer QoS-Erweiterung für OLSR. Dabei sollen Parameter wie Bandbreite, Verzögerung, Laufzeitschwankungen, Ausfallwahrscheinlichkeit, Energieverbrauch usw. in die Berechnung der Routingtabelle mit einbezogen werden. Hierzu liegt derzeit ein IETF-DRAFT vor. [Labo06], [Inte06b] Implementierungen existieren noch nicht. Medienprojekt Alexander Marr

2 Grundlagen 6 2.3 Gateway Sowohl auf der Transportschicht als auch auf der Anwendungsschicht können Gateways verschiedene Netze verbinden. Hierbei können Daten gewandelt, Inhalte extrahiert und umgesetzt werden. Bei einem VoIP-Gateway erfolgt beispielsweise die Umsetzung von IP-Telefonie auf ISDN, also eine Datenwandlung der Sprachdaten von G.729A auf G.711 und umgekehrt. Ebenso werden die Steuerdaten an den D-Kanal angepasst. Für Internetverbindungsfreigabe und für den Übergang von Ad-hoc-Netzen in öffentliche Netze wird oft ein Network Address Translation Gateway verwendet. Bei Full Cone NAT werden alle Anfragen einer bestimmten internen IP an eine externe IP-Adresse im Gateway fest an eine definierte öffentliche IP-Adresse und einen festen Port gebunden. Somit werden alle Pakete einer definierten internen IP an eine definierte öffentliche IP gesendet. Da diese Bindung fest ist, kann auch die interne IP durch die feste öffentliche IP erreicht werden. Bei Restricted Cone NAT wird eine Bindung interner IP-Adressen zu definierten öffentlichen IP-Adressen gehalten, ähnlich wie Full Cone NAT. Allerdings kann hier die interne IP nur erreicht werden, wenn der interne PC Pakete an den externen Computer gesendet hat. Port Restricted Cone NAT funktioniert wie Restricted Cone NAT mit der zusätzlichen Einschränkung der Port Nummer. Dabei erfolgt eine Adressumsetzung. Im Gateway wird die IP-Adresse des anfragenden PCs zusammen mit dem Port in einer Liste gehalten, durch eine öffentliche IP-Adresse ersetzt und weiter gereicht. Wird aus dem Netz die Antwort übermittelt, so wird wieder die öffentliche Zieladresse durch die in der Liste gehaltene IP-Adresse ersetzt und weitergeleitet. Symmetric NAT übersetzt alle Requests von einer privaten, internen IP-Adresse mit Port zu einer öffentlichen IP-Adresse mit Port. Wenn derselbe interne PC mit der gleichen Quelladresse ein Paket zu einem anderen Ziel sendet, wird ein anderer Eintrag in der Übersetzungstabelle gesetzt. Der Rechner kann von extern nur erreicht werden, wenn er ein Paket an die externe IP gesendet hat. Die Bindungszuordnung in der Liste ist zeitlich oft auf ca. 30 Sekunden begrenzt. Um die Erreichbarkeit nach einer Authentifizierung von außen zu gewährleisten, müssen-keep-alive-pakete die Bindungszuordnung im NAT-Gateway beibehalten. Diese Bindungszuordnung benötigt Rechenzeit im Gateway. Dabei kann zusätzlich eine Datenfragmentierung erfolgen. Medienprojekt Alexander Marr

2 Grundlagen 7 NAT arbeitet auf der TCP/IP-Internetschicht (entspricht ISO/OSI Schicht 3) beziehungsweise unter Einbeziehung der Portnummer auf TCP/IP-Transportschicht (entspricht ISO/OSI Schicht 4). Dies geschieht völlig transparent aus Sicht der Anwendungen. Es sind verschiedene Maßnahmen erforderlich, damit Anwendungen die Konfiguration des NAT-Gateways herausfinden können. (Quelle: [link06b]) Universal Plug and Play basiert auf vorhandenen und standardisierten Netzwerkprotokollen. Es dient zur Steuerung von IP-basierten Geräten. Mit UPnP kann auch das NAT-Gerät konfiguriert werden. Dabei wird direkt im Gateway oder Router abgefragt, welche IP-Adresse und Ports benutzt werden dürfen. Die Pakete können nach der Konfiguration ins Netz weitergereicht werden. (Quelle: [Wiki06b]) Simple Traversal of UDP through NAT (RFC3489) ist eine weitere Möglichkeit, die Netzkonfiguration herauszufinden. Das lokale STUN-Programm verbindet sich mit einem öffentlichen STUN- Server. Der STUN-Server schickt daraufhin eine Statusmeldung mit der ermittelten Netzkonfiguration zurück. Somit erhält die Anwendung Sicht auf die Netzeinstellungen. (Quelle: [Inte03]) 2.4 Netzwerkbrücke Mit Netzwerkbrücken können Teile eines Subnetzes auf Schicht 2 miteinander verbunden werden. Sowohl die Kopplung homogener als auch heterogener Netze ist möglich. Es gibt Hardware- und Softwarebrücken. Bei Softwarebrücken müssen mehrere LAN- Adapter in einem System eingebaut sein. (Quelle: [Krüg04], S. 148-152) Source-Route-Brücken (IEEE 802.5) Die Weginformation wird im Kopf eines Datenpaketes eingetragen. Der Kopf beinhaltet die Empfängeradresse und alle Adressen der Brücken, die zwischen Sender und Empfänger liegen. Die Brücke leitet die Pakete an die jeweilige nächste Position weiter. Obwohl die Pflege einer Weiterleitungstabelle in Zwischensystemen entfällt, kommen Source-Route-Brücken selten zum Einsatz. Es ist problematisch jede Route zu bestimmen, besonders bei wechselnden Netzen. Außerdem steigt der Overhead jedes Paketes bei langen Routen stark an. Medienprojekt Alexander Marr

2 Grundlagen 8 Transparente Brücken (IEEE 802.1D) Für die Endsysteme ist nicht ersichtlich, ob transparente Brücken vorhanden sind oder nicht. Die Entscheidung zur Weiterleitung von Datenpaketen wird von der Brücke getroffen. Dazu wird in der Brücke eine Filterbasis, eine Tabelle mit den Orten von Endsystemen, gepflegt. Die Adressen werden selbstständig gelernt. Ist die Zieladresse eines empfangenen Paketes unbekannt, erfolgt die Weiterleitung als Broadcast. Ist sie hingegen bekannt, kann das Paket über den jeweiligen Ausgang geschickt werden. Zur Aktualisierung der Filterbasis werden die Quelladressen der eingehenden Pakete überprüft. Bekannte Adressen werden aktualisiert, unbekannte neu erstellt. Die Einträge sind mit Zeitstempeln versehen und werden nach Ablauf einer definierten Zeit gelöscht. Dies ermöglicht das Reagieren auf einen Wechsel der Netztopologie. Spanning Tree Für die Broadcast-Weiterleitung, welche in der Lernphase eingesetzt wird, ist Zyklenfreiheit zwingend notwendig. Ohne weitere Maßnahmen könnten die Pakete endlos kreisen. Auch durch redundante Wege werden die Pakete dupliziert. Um das Problem zu lösen, wurde der Spanning-Tree-Algorithmus entwickelt. Dabei wird eine logische Baumstruktur auf alle Brücken abgebildet. Es muss eine Gruppenadresse zur Adressierung aller Brücken vorhanden sein. Jede Brücke und jeder Anschluss benötigen eine eindeutige Kennung. Zusätzlich kann jeder Anschluss mit einem Kostenfaktor belegt werden. Zunächst wird die Root-Brücke bestimmt. Dazu werden zyklisch Konfigurations-Brücken-PDUs verschickt. Die Brücke mit der kleinsten Kennung wird zur Root-Brücke. Im nächsten Schritt wird der kostengünstigste Pfad zur Root-Brücke ermittelt. Angefangen von der Root-Brücke verteilt jede Brücke die bekannten Kosten zur Root-Brücke. Darauf aufbauend wird für jedes einzelne LAN entschieden, welche Brücke den günstigsten Root-Anschluss darstellt. Dies ist die Designated-Brücke. Jedes LAN besitzt nun genau eine Designated-Brücke. Somit wird eine logische Struktur abgebildet. Mit einem ablaufenden Zeitstempel kann das Netz auf Strukturänderungen reagieren. Medienprojekt Alexander Marr

2 Grundlagen 9 2.5 Dynamic DNS Dynamic Domain-Name-System hat zum Ziel, dass bei wechselnder IP-Adresse des Gerätes, auf dem ein Service angeboten wird z.b. ein Webserver, die Erreichbarkeit unter einem festen Namen gegeben ist. Um den dynamischen IP-Eintrag zu einem statischen Namen in einem Namensserver zu aktualisieren, kann ein DDNS-Client benutzt werden. Die Aktualisierung kann manuell oder automatisch erfolgen. Da es verschiedene Wege gibt, aus einem Ad-hoc-Netz den Zugang zu einem anderen Netzwerk bereitzustellen, ist DDNS von Bedeutung. Bei der sehr verbreiteten Methode NAT kann sich die IP-Adresse des Gateways oft ändern. DDNS bietet somit eine Möglichkeit, die Erreichbarkeit sicher zu stellen. Mit Hilfe von STUN (2.3) können der Anwendung die Konfigurationsparameter des Gateways übermittelt werden. Eine Liste mit Dynamic DNS Anbieter ist hier hinterlegt. [netz06] 2.6 VPN Durch Virtual Private Networks kann eine logische Netzstruktur auf unterschiedliche Netze abgebildet werden. Es besteht die Möglichkeit der Ankopplung entfernter Clients an Netze. Weiterhin besteht die Möglichkeit der Kopplung gesamter Netze oder einzelner Endgeräte. Die Verbindung wird durch einen Tunnel realisiert. Befindet man sich in einem Ad-hoc-Netz, so kann man eine bereitgestellte Internetverbindung dazu nutzen um sich bei einem VPN-Server zu registrieren. Dadurch erhält der Mobile Node eine topologisch korrekte Adresse aus dem Adressraum des VPN-Servers und kann über den VPN-Tunnel von außen erreicht werden. PPTP Mit dem Point-to-Point-Tunneling-Protocol besteht die Möglichkeit, das Point-to- Point-Protocol über IP-Verbindungen zu tunneln. Dabei handelt es sich um eine Client- Server-Architektur. Der Tunnel besteht aus zwei logischen Leitungen, einer logischen Kontrollleitung und einem IP-Tunnel. Zuerst wird die logische Kontrollleitung TCP Port 1723 aufgebaut. Die erste Nachricht vom Client, der Start-Control-Connection- Request, wird vom Server mittels Start-Control-Connections-Reply beantwortet. Zyklisch wird ein Echo-Mechanismus ausgeführt, um die Verbindung zu halten. PPTP- Client/Server für Windows, Linux, MacOS und Free BSD sind lauffähig. Medienprojekt Alexander Marr

2 Grundlagen 10 IPSec Das Protokoll ist modular aufgebaut. Algorithmen für Authentifizierung, Verschlüsselung und Schlüsselmanagement sind austauschbar. Damit die Kommunikationspartner die gleichen Algorithmen verwenden, werden diese am Anfang einer Kommunikationsbeziehung ausgehandelt. Bei IPSec kommen mehrere Protokolle wie beispielsweise: Authentification Header Protokoll (RFC-2402), Encapsulated Security Protokoll, Internet Key Exchange Protokoll und Internet Security Association and Key Management Protocol zum Einsatz. Der Umfang von IPSec ist sehr komplex. Der größte Wert wurde bei der Entwicklung auf Sicherheit gelegt. Es werden viele Hardware und Softwarelösungen am Markt angeboten. Weitere VPN Lösungen sind L2TP: Layer 2 Tunneling Protocol Tinc Open VPN SSL VPNs SSH Secure Shell GNU Virtual Private Ethernet Amrita Htun Nest SSL Explorer - SSL VPN SLAN Yavipin VTun Medienprojekt Alexander Marr

2 Grundlagen 11 2.7 Voice over IP Mit der VoIP-Technik können mehrere Clients in Ad-hoc-Netzen mit Sprachnetzen kombiniert werden. Hierbei wird eine bereitgestellte Internetverbindung genutzt, um sich an einem VoIP Server zu registrieren. Die Erreichbarkeit der Clients wird periodisch überprüft. Alternativ kann auch ein VoIP-Gateway im Ad-hoc-Netz selbst vorhanden sein. Ein VoIP-Server verfügt meist über eine Nutzerdatenbank und übernimmt alle Vermittlungsprozesse. Das Gateway verbindet herkömmliche Sprach-, Fest- und Mobilfunknetze mit der VoIP-Welt. Die VoIP Clients stellen die Softwarelösung für Endgeräte dar. Für die Signalisierung sind die Protokolle H.323 oder SIP verantwortlich. H.323 wurde als Videokonferenzprotokoll über TCP/IP entwickelt und durch die ITU-T genormt. Zu der H.323 Protokollfamile zählen die Protokolle H.225.0 für Setup, Q.931 für Signalisierung, H.245 für Telefonie und H.450 für weitere Leistungsmerkmale wie beispielsweise Verbinden, Rufweiterleitung, Halten und Parken. Ebenfalls sind Gateway-Funktionen für den Übergang zu anderen Sprachnetzen und Gatekeeper- Funktionen (Torwächter) für das Bandbreitenmanagement und Adressumsetzungen im Gateway enthalten. Mit aufgebauter Verbindung wird durch H.245 ein Handshaking- Verfahren für die Einigung auf einen Sprach-Codec genutzt. SIP wurde mittels der IETF genormt. Das Signalisierungsprotokoll überträgt Informationen im Klartext. SIP setzt eine kombinierte Client-/Server-Architektur voraus. Der Client initiiert Anrufe, der Server vermittelt die Anrufe. Die Dialoge beinhalten Request und Response. Request Anforderungen können Invite, Ack, Bye, Cancel, Options und Register sein. Aufgrund seiner Einfachheit wird derzeit fast ausschließlich das SIP-Protokoll eingesetzt. Die Codecs zur Sprachsignalisierung unterstützen mittels Forward Error Correction bis 5 % Paketverluste und Jitter Buffering zum Ausgleich von Laufzeitunterschieden. (Quelle: [Elek06]) Codec Name Rate Sample Block Coderdelay G.711 PCM 64 Kbps - 0,25ms G.726 ADPCM 32 Kbps 10ms 2,5-10ms G.729/A CS-ACELP 8 Kbps 10ms 2,5-10ms G.723.1 MP-MLQ 6,3 Kpbs 30ms 5-20ms G.723.1 MP-ACELP 5,3 Kbps 30ms 5-20ms Tabelle 2.1: Digitalisierung und Komprimierung von Sprachdaten, (Quelle: [cisc06a]) Medienprojekt Alexander Marr

2 Grundlagen 12 In der Tabelle 2.1 sind Codecs zur Digitalisierung und Komprimierung von Sprache dargestellt. Je niedriger die Datenrate, desto höher ist die Verzögerungszeit. VoIP Anwendungen können mehrere Codecs nutzen. Diese werden im Handshake Verfahren ausgehandelt. Meist wird G.729A verwendet, was eine Datenrate von 8 bis 10 kbit/s fordert. Ad-hoc Netze sind, je nach Konfiguration, durchaus in der Lage, solche Datenraten auch über mehrere Hops zu transportieren. Das belegt das Medienprojekt multimediale Anwendungen ([S.06]). 2.8 Mobile IP Damit ein Computer im Internet neben www-seiten und Emails empfangen auch Dienste anbieten kann, benötigt er eine topologisch korrekte Adresse. Mit dem Wechsel der IP-Adresse kann der Computer nur als Client arbeiten und die angebotenen Dienste nutzen. Das Bereitstellen von Diensten ist problematisch. Besonders kritisch ist der Wechsel der IP-Adresse während einer TCP - Verbindung. Durch den Wechsel des Sockets wird die TCP - Verbindung abgebrochen. Eine Möglichkeit die Erreichbarkeit unter einer topologisch korrekten IP-Adresse auch in verschiedenen Ad-hoc-Netzen mit unterschiedlichen Adressbereichen zu gewährleisten, ist Mobile-IP. Sobald sich ein Mobile-Node im neuen Netz befindet, muss er sich bei einem Foreign Agent registrieren. Home Agent und FA senden regelmäßig Agend Advertisement Messages in Form von ICMP Paketen nach RFC1256 aus. Dabei wird das TTL Feld auf 1 gesetzt, da die Pakete nur in einem Subnetz gültig sind. Dies ist die einzige Möglichkeit für den MN festzustellen, ob er sich im Heimatnetz oder im Fremdnetz befindet. Empfängt der MN diese Pakete nicht, kann er auch aktiv nach Agenten suchen. Wurde ein FA gefunden, muss eine Care-Of-Adress vergeben werden und die Registrierung vom MN über den FA zum HA erfolgen. Somit wird beim HA die Adresse des FA bekannt gegeben. Befindet sich der MN im Heimnetz, kann er sich direkt am HA registrieren. Medienprojekt Alexander Marr

2 Grundlagen 13 Die Kapselung der Pakete zum Aufbau des Tunnels zwischen HA und MN kann auf unterschiedliche Weise erfolgen. Bei der IP-in-IP-Kapselung folgen die Felder der Paketköpfe der Standardspezifikation für IP. Lediglich die Kennzeichnung des Protokolltyps der Nutzlast muss auf IP-Version-4 gesetzt werden. Es wird bekannt gegeben, dass es sich um eine IP-in-IP-Kapselung handelt. Ein Tunneleingang ist die IP-Adresse des HA und Tunnelausgang die COA. Der innere Paketkopf ist fast identisch mit dem äußeren. Allerdings ist die Absenderadresse die des originalen Senders, die Empfängeradresse ist die MN-Adresse. Die Nutzlastmarkierung ist ein echtes Transportprotokoll wie TCP oder UDP und das TTL-Feld um eins verkleinert. Zur Veringerung der durch die Kapselung zusätzlichen Daten, wurde die Minimale Kapselung definiert. Auch hier handelt es sich um eine Art IP-in-IP-Kapselung, allerdings werden keine redundanten Felder der 2 IP-Paketköpfe übertragen. Eine weitere Möglichkeit ist die Generic-Routing-Encapsulation. Hierbei wird ein GRE-Kopf vor das Originalpaket gesetzt. An erster Stelle wird der Paketkopf des äußeren Protokolls gefasst. Der GRE-Kopf ist variabel in der Länge, minimal sind es 4 Bytes. Die Vorteile sind zusätzliche Felder wie Schlüssel für Authentifizierung, Sequenznummer für die Originalreihenfolge beim Entschlüsseln und Rekursionskontrolle, um unendlich tiefe Kapselungen zu unterbinden. (Quelle: [Schi00], S. 354-399) Medienprojekt Alexander Marr

3 Testaufbau 14 3 Testaufbau Innerhalb dieses Kapitels wird die Testumgebung definiert und die einzelnen Testszenarios vorgestellt. Außerdem wird eine erste Einschätzung der Messungen in Bezug auf die Zusammenarbeit von Ad-hoc-Netzen mit herkömmlichen Fest- und Mobilfunknetzen dargestellt. 3.1 Testabsichten Das Konzept aus dem Teilprojekt Ad-hoc-Netze / multimediale Anwendungen bildet die Grundlage zum Testen der einzelnen Szenarios und beschäftigt sich ausschließlich mit dem reinen Ad-hoc-Netz. Dieses Teilprojekt legt den Schwerpunkt auf den Netzübergang. Deshalb beschränken sich fast alle Szenarios auf einen Hop im Ad-hoc-Netz. Hierbei wird auf Funktionalität, Erreichbarkeit in beide Richtungen und die dafür zusätzlichen Maßnahmen Wert gelegt. Funktionsfähige Szenarios werden mit verschiedenen MPEG4-Video-Multimedia-Streams getestet, aufgezeichnet und ausgewertet. 3.2 Testumgebung Mit Hilfe der ausgewählten Implementierungen für Routingprotokolle aus einer Studienarbeit von Kramer M. (2005) Realisierung einer Testumgebung für Ad-hoc-Netze [M.05] und der Multimediadaten aus dem ersten Teilprojekt erfolgen die Messaufbauten. 3.2.1 Hardware Die Szenarios werden mit der verfügbaren Hardware umgesetzt. Diese besteht aus Laptop 1, Laptop 2, Arbeitsplatz-PC 1 und Arbeitsplatz-PC 2 mit den Betriebssystemen Windows 2000 SP4 und Windows XP SP2, wie in Tabelle 3.1 dargestellt. Medienprojekt Alexander Marr

3 Testaufbau 15 Name System CPU RAM PC 1 Windows XP 2002 SP2 Intel Pentium 4 1,5GHz 384MB PC 2 Windows XP 2002 SP2 Intel Pentium 4 1,5GHz 512MB Laptop 1 Windows 2000 5.00.2195 SP4 Intel Pentium 3E 1,0GHz 512MB Laptop 2 Windows 2000 5.00.2195 SP4 Intel Pentium 3E 1,0GHz 384MB Tabelle 3.1: Hardwareasustattung PCs und Laptops Als WLAN-Karten kommen RoamAbout 802.11 DS Cabletron und Dell TrueMobile im Peer-to-Peer Modus zum Einsatz. In Tabelle 3.2 ist die Ausstattung der Computer mit LAN- und WLAN-Adaptern und den Versionen der Treiber dargestellt. Name WLAN Adapter Treiber LAN Adapter Treiber PC 1 Roamabout 802.11DS 7.86 Intel(R)Pro/1000T 8.6.11.0 PC 2 Roamabout 802.11DS 7,86 SMC EZ-Card 10/100 5.396.530 Laptop 1 Dell True Mobile 1150 7,44 nicht verwendet - Laptop 2 Roamabout 802.11DS 7,86 nicht verwendet - Tabelle 3.2: Netzwerkadapter PCs und Laptops 3.2.2 Routing Zwei funktionsfähige Implementierungen von Routingprotokollen für Windows-Betriebssysteme stehen zur Verfügung. Ad-hoc On-demand Distance Vector ist ein reaktives, schleifenfreies und flaches Routingprotokoll für Ad-hoc-Netze nach RFC3561 (IETF, 2003d). Windows-AODV liegt derzeit als Version 0.1.14 vom 02.04.2004 vor. [Inte04] OLSR ist ein proaktives, schleifenfreies und flaches Routingprotokoll für Ad-hoc- Netze nach RFC3626 (IETF, 2003e). OLSR liegt zum Zeitpunkt der Messungen in der Version 0.4.9 vor. Derzeit ist die Version 0.4.10 vom 04.01.2006 aktuell. [olsr06], [Inte06a], [frei06], [R.05] Da Windows-AODV nur in Verbindung mit Windows XP und OLSR mit Windows 2000 und XP funktionsfähig ist, wird in den Szenarios OLSR eingesetzt. Bei der Installation von Windows-AODV unter Windows 2000 wird ein Fehler gemeldet. In Abbildung 3.1 ist die Fehlermeldung dargestellt. Im Gegensatz zu vielen anderen Ad-hoc Routingprotokollen ist OLSR für zahlreiche Betriebssysteme portiert und wird ständig weiterentwickelt. Derzeit existieren Implementierungen für NetBSD, FreeBSD, OS X, Linux und Windows 2000/XP/2003. Medienprojekt Alexander Marr