Eine effiziente IPv6 Implementierung für Steuergeräte
- Art: MA-Thesis / Master
- Autor: Klaus Erlenbach
- Abgabedatum: November 2007
- Umfang: 128 Seiten
- Dateigröße: 2,3 MB
- Note: 1,3
- Institution / Hochschule: Georg-Simon-Ohm-Fachhochschule Nürnberg Deutschland
- Bibliografie: ca. 23
- ISBN (eBook): 978-3-8366-1462-7
- Sprache: Deutsch
- Prämierung:
- Arbeit zitieren: Erlenbach, Klaus November 2007: Eine effiziente IPv6 Implementierung für Steuergeräte, Hamburg: Diplomica Verlag
- Schlagworte: IPv6, Dual-Stack, Embedded System, AUTOSAR, Steuergerät
48,00 €
PDF-eBook Download: 48,00 €
MA-Thesis / Master von Klaus Erlenbach
Einleitung:
Die Firma Elektrobit Automotive GmbH bietet einen für das OSEK-Betriebssystem optimierten TCP/IP-Stack für den gängigen IPv4-Standard an. Diese ressourcenschonende und schlanke Implementierung zeichnet sich durch besonders hohe Performance auf kleinen Prozessoren gegenüber alternativen, freien und kommerziellen TCP/IP-Produkten ab. Insbesondere die Umsetzung eines dynamischen Protokolls wie TCP/IP in der sehr statischen Umgebung eines Automotive-Steuergerätes erfordert besondere Aufmerksamkeit, bietet damit aber auch ein interessantes und herausforderndes Thema für eine wissenschaftliche Arbeit.
IPv4 ist das gegenwärtig am meisten genutzte Internet-Protokoll. Problematisch ist allerdings der auf 32 Bit begrenzte Adressraum, welcher eine maximale Anzahl von 4,295 Milliarden Geräten adressieren kann. Mit dem Wirtschaftsboom in Asien und dem Bedarf an IP-Adressen für mobile Endgeräte, für Haushaltsgeräte (Kühlschrank), Sensor-Netzwerke für Brücken, Häuser usw. oder RFID-Chips und in Zukunft auch für Fernsehgeräte und Kfz-Fahrzeuge, steigt der Bedarf an IP-Adressen rapide an. Die Zahl der Internetnutzer weltweit hat im Jahr 2005 die Milliarden-Marke überschritten berichten die Marktforscher von [ETFO06]. Sie rechnen mit einem Anstieg der Nutzerzahlen auf zwei Milliarden für das Jahr 2011.
Bereits 1993 begann man daher mit der Entwicklung von TCP/IP-Version 6. IPv6 bietet einen Adressbereich von 128 Bit. Damit kann man wesentlich mehr Rechner im Internet mit IP-Adressen versehen: ca. 340 Sextillionen (2 hoch 128)! Es können also rein rechnerisch für jeden Quadratmillimeter Oberfläche der Erde ungefähr 667 Billiarden IPv6-Adressen zur Verfügung gestellt werden. In Asien werden die IPv4-Adressen schon knapp und auch allgemein wird der Adressraum des IPv4-Protokolls nicht ausreichen, denn neben einer exponentiell ansteigenden Zahl von neuen benötigten IP-Adressen ist ein großer Teil des IP-Adressraums nicht nutzbar, da er für Sonderaufgaben (Multicast) zugeteilt ist oder zu großen Subnetzen gehört. Die Normen werden von der IETF gesetzt.
Da die Umstellung von IPv4 auf IPv6 kontinuierlich verlaufen soll, sind bereits viele Geräte mit einer Dual-Stack-Implementierung ausgestattet, d.h. sie verfügen über beide Protokollvarianten. Das heißt zudem, dass im Kernbereich des Netzes beide Protokolle parallel gefahren werden können. Für jedes Teilnetz, zum Beispiel einzelne Unternehmen oder Abteilungen, kann nun separat entschieden werden, ob auf IPv6 umgestellt wird. Geräte, für die es keine Aktualisierung gibt, kommunizieren weiterhin über IPv4.
Aufbauend auf den IPv4-Protokoll-Stack soll eine ebenso performante und schlanke Implementierung für den kommenden IPv6-Standard entstehen. Dieser Protokoll-Stack soll als Dual-Stack beide IP-Versionen unterstützen können. Innerhalb dieser Arbeit werden die Neuheiten des IPv6-Standards analysiert. Aus den Ergebnissen werden Anforderungen an die Implementierung abgeleitet. Dabei soll auf den bereits gewonnenen Erkenntnissen aus der IPv4-Stack-Entwicklung aufgebaut werden. Anschließend wird ein Softwaredesign erstellt und dieses für einen Prototyp implementiert.
Gang der Untersuchung:
Die vorliegende Masterarbeit gliedert sich in acht Hauptkapitel.
In Kapitel 2 werden die Grundlagen zum Automotive-Markt untersucht, um für die geforderte Aufgabenstellung ein Verständnis für das Umfeld zu bekommen, in dem das zu entwickelnde System eingesetzt wird. Die derzeitige Situation auf dem Automotive-Markt in Bezug auf die Entwicklung neuer Technologien wird vorgestellt. Für die Softwareentwicklung haben die führenden Hersteller einen Standard für die Entwicklung von Steuer-Software entwickelt, der für alle Steuergeräte eine gemeinsame Plattform zur Verfügung stellt. Der Standard OSEK/VDX und dessen Nachfolger AUTOSAR werden beschrieben. Schließlich wird etwas näher auf den Begriff „Steuergerät“ eingegangen, welches die Hardwareplattform für das zu entwickelnde Produkt bildet.
Kapitel 3 beschreibt die Grundlagen zu den in der Automobil-Industrie eingesetzten Bussystemen. Die derzeit gängigen Bussysteme werden kurz beschrieben. Der im Rahmen dieses Projektes verwendete Ethernet-Bus wird vorgestellt.
In Kapitel 4 werden die Grundlagen zum TCP/IP-Protokoll beschrieben, soweit sie für das Verständnis der nachfolgenden Aufgabenstellungen relevant sind. Nach einer einführenden Betrachtung der OSI-Schichtenarchitektur werden die protokollspezifischen Details zu Ethernet, IPv4, ICMPv4, IPv6, ICMPv6 sowie UDP und TCP vorgestellt. Die Neuerungen des IPv6-Protokolls werden erarbeitet.
In Kapitel 5 wird die eigentliche Projektarbeit mit einer Anforderungs-Analyse gestartet. Die geplanten funktionalen und nichtfunktionalen Anforderungen werden spezifiziert. Außerdem wird die System- und Produktgrenze festgelegt und Projektrandbedingungen werden spezifiziert.
Kapitel 6 beschäftigt sich mit der Analyse des bestehenden IPv4-Protokoll-Stacks. Für eine Übersicht wird die Stack-Architektur beschrieben. Weiterhin wird die Speicherverwaltung untersucht, soweit diese für das Projekt relevant ist. Das Konzept der Einbindung von Netzwerktreibern in das Gesamtsystem wird vorgestellt. Schließlich wird der Hin- und Rückweg eines Nutzdatenpaketes auf dem Protokoll-Stack dargestellt. Außerdem werden die wichtigsten Schnittstellenfunktionen und deren Aufgaben beschrieben.
In Kapitel 7 erfolgt eine detaillierte Beschreibung der Implementierung. Zunächst wird die Reihenfolge der zu implementierenden Funktionen mit den für die Umsetzung notwendigen Aufgaben festgelegt. Anschließend wird die erweiterte Software-Architektur gezeigt. Es folgt eine detaillierte Beschreibung für die Realisierung eines PING-Befehls. Die dazu notwendigen Erweiterungen bestehender Funktionen und Schnittstellen, sowie die hierfür notwendige Implementierung neuer Funktionalitäten und Datenstrukturen werden vorgestellt. Anschließend werden die durchzuführenden Aufgaben zur Erweiterung der Protokollschichten UDP und TCP sowie die Erweiterung der SOCKET-Schnittstelle beschrieben. Schließlich wird beschrieben, wie die neue Funktionalität der automatischen Adresskonfiguration für IPv6 zu implementieren ist.
In Kapitel 8 wird ein Rückblick auf die durchgeführten Aufgaben gegeben und die dabei aufgetretenen Schwierigkeiten beschrieben. Nach Vorstellung der Ergebnisse dieser Masterarbeit wird ein Ausblick gegeben, wie es mit diesem Projekt sinnvollerweise weiter gehen kann.
Im Anhang werden alle relevanten RFC-Dokumente vorgestellt, welche die Grundlage für die Umsetzung der IPv6-spezifischen Details gebildet haben.
Inhaltsverzeichnis:
| Abkürzungen und Begriffe | 9 | |
| 1. | Einleitung | 15 |
| 1.1 | Motivation | 15 |
| 1.2 | Ziele dieser Masterarbeit | 15 |
| 1.3 | Kapitelübersicht | 15 |
| 2. | Grundlagen Automotive-Markt | 17 |
| 2.1 | Der Automotive-Markt | 17 |
| 2.2 | Echtzeitbetriebssysteme | 18 |
| 2.3 | OSEK | 18 |
| 2.4 | Implementierungssprache OIL | 19 |
| 2.4.1 | Task-Verwaltung | 19 |
| 2.4.2 | Kommerzielle OSEK-Distributionen | 20 |
| 2.4.3 | AUTOSAR | 20 |
| 2.5 | Architektur | 21 |
| 2.5.1 | AUTOSAR-Software | 21 |
| 2.5.2 | Runtime Environment | 22 |
| 2.5.3 | AUTOSAR-Basic-Software | 22 |
| 2.5.4 | ECU-Hardware | 22 |
| 2.6 | Vorgehensmodell | 23 |
| 2.7 | Steuergeräte in Fahrzeugen | 24 |
| 3. | Grundlagen Bussysteme | 25 |
| 3.1 | CAN | 25 |
| 3.2 | FlexRay | 25 |
| 3.3 | LIN | 26 |
| 3.4 | Most | 26 |
| 3.5 | Ethernet | 27 |
| 4. | Grundlagen TCP/IP-Protokolle | 29 |
| 4.1 | OSI-Referenzmodell | 29 |
| 4.2 | Das TCP/IP-Referenzmodell | 30 |
| 4.3 | Ethernet | 31 |
| 4.4 | IPv4 | 33 |
| 4.5 | ICMPv4 | 35 |
| 4.5.1 | ICMPv4-Anfragen | 36 |
| 4.6 | IPv6 | 37 |
| 4.6.1 | Warum IPv6? | 37 |
| 4.6.2 | Änderungen gegenüber IPv4 | 37 |
| 4.6.3 | Der IPv6-Header | 38 |
| 4.7 | ICMPv6 | 39 |
| 4.7.1 | ICMPv6-Anfragen | 40 |
| 4.7.2 | Neighbor Discovery (ND) | 41 |
| 4.8 | UDP | 43 |
| 4.9 | TCP | 44 |
| 4.10 | Das Netzwerk-API „Berkeley Sockets“ | 45 |
| 4.10.1 | Schnittstellen-Funktionen | 46 |
| 5. | Anforderungsanalyse | 49 |
| 5.1 | Randbedingungen | 49 |
| 5.1.1 | Zweck des Systems | 49 |
| 5.1.2 | Auftraggeber, Kunden und andere Beteiligte/Betroffene | 49 |
| 5.1.3 | Nutzer des Produkts | 49 |
| 5.1.4 | Randbedingungen für das Produkt | 50 |
| 5.1.5 | Annahmen | 50 |
| 5.2 | Funktionale Anforderungen | 50 |
| 5.2.1 | Die Abgrenzung des Systems | 50 |
| 5.2.2 | Anforderungen an Funktionen und Daten des Systems | 51 |
| 5.3 | Nichtfunktionale Anforderungen | 54 |
| 5.3.1 | Performance/Durchsatz/Sicherheit | 54 |
| 5.3.2 | Operationale Anforderungen | 54 |
| 5.3.3 | Wartungs- und Portierungsanforderungen | 55 |
| 5.3.4 | Zugriffsschutzanforderungen | 55 |
| 5.3.5 | Normen und Richtlinien | 55 |
| 5.4 | Projektrandbedingungen | 55 |
| 5.4.1 | Inbetriebnahme und Migration | 55 |
| 5.4.2 | Benutzerdokumentation | 55 |
| 5.4.3 | Warteraum | 55 |
| 6. | Analyse des bestehenden IPv4-Protokoll-Stacks | 56 |
| 6.1 | Stack-Architektur | 56 |
| 6.2 | Speicherverwaltung | 59 |
| 6.2.1 | Aufbau der PBUF-Speicherverwaltung | 59 |
| 6.2.2 | Schnittstellenfunktionen der Speicherverwaltung | 60 |
| 6.3 | Message-Verwaltung | 61 |
| 6.4 | Netzwerk-Schnittstelle | 61 |
| 6.5 | Protokoll-Stack-Übersicht | 62 |
| 6.5.1 | Empfangen eines Nutzdatenpaketes | 62 |
| 6.5.2 | Senden eines Nutzdatenpaketes | 65 |
| 6.6 | Das Ethernet-Protokoll | 67 |
| 6.6.1 | Empfang von Ethernet-Frames | 67 |
| 6.6.2 | Senden von Ethernet-Frames | 69 |
| 6.7 | Das IPv4-Protokoll | 71 |
| 6.7.1 | Empfang von IP-Frames | 71 |
| 6.7.2 | Senden von IP-Frames | 72 |
| 6.8 | Das UDP-Protokoll | 74 |
| 6.8.1 | Empfangen von UDP-Paketen | 74 |
| 6.8.2 | Senden von UDP-Paketen | 75 |
| 6.9 | Das TCP-Protokoll | 78 |
| 6.9.1 | Empfangen von TCP-Paketen | 78 |
| 6.9.2 | Senden von TCP-Paketen | 79 |
| 6.10 | Die Socket-Schnittstelle | 81 |
| 7. | Prototypische Implementierung | 84 |
| 7.1 | Festlegen der Implementierungsreihenfolge | 84 |
| 7.1.1 | Schritt 1: Zugriffe auf Protokoll-Header durch Makros ersetzen | 84 |
| 7.1.2 | Schritt 2: Auf IPv6-Echo-Requests antworten | 85 |
| 7.1.3 | Schritt 3: ICMP-Neighbor-Discovery-Address-Resolution | 85 |
| 7.1.4 | Schritt 4: UDP-Pakete senden und empfangen | 85 |
| 7.1.5 | Schritt 5: TCP-Pakete senden und empfangen | 86 |
| 7.1.6 | Schritt 6: „Stateless-Autoconfiguration“ ermöglichen | 86 |
| 7.2 | Stack-Architektur für Dual-Stack | 87 |
| 7.3 | Zugriffe auf Protokoll-Header durch Makros ersetzen | 88 |
| 7.4 | Auf ein IPv6-Echo-Request antworten | 90 |
| 7.4.1 | Arbeitsweise von Ping | 90 |
| 7.4.2 | Beobachtung eines Ping-Befehls in der Praxis | 91 |
| 7.4.3 | Anpassen der Ethernet-Empfangsfunktion | 94 |
| 7.4.4 | Anpassen der Ethernet-Sendefunktion | 95 |
| 7.4.5 | Anpassen der IP-Adressen-Struktur und Hilfsfunktionen | 97 |
| 7.4.6 | Anlegen der IPv6-Empfangsfunktion | 98 |
| 7.4.7 | Anlegen der IPv6-Sendefunktion | 100 |
| 7.4.8 | Die ICMPv6-Empfangsfunktion | 102 |
| 7.4.9 | Empfangen von Echo-Request-Nachrichten | 104 |
| 7.4.10 | Empfangen von Echo-Reply-Nachrichten | 105 |
| 7.4.11 | Empfangen von Neighbor-Solicitation-Nachrichten | 106 |
| 7.4.12 | Empfangen von Neighbor-Advertisement-Nachrichten | 107 |
| 7.4.13 | Der Neighbor Cache | 109 |
| 7.5 | ICMP-Neighbor-Discovery-Address-Resolution implementieren | 115 |
| 7.6 | UDP-Pakete senden und empfangen | 115 |
| 7.6.1 | Anpassung der UDP-Funktionen | 115 |
| 7.6.2 | Anpassung der Socket-Schnittstelle | 115 |
| 7.7 | TCP-Pakete senden und empfangen | 117 |
| 7.7.1 | Anpassung der TCP-Funktionen | 117 |
| 7.8 | „Stateless Autoconfiguration“ implementieren | 118 |
| 7.8.1 | Generieren einer Link-lokalen IP-Adresse | 120 |
| 7.8.2 | „Duplicate Address Detection“-Prozess | 121 |
| 8. | Resümee | 122 |
| 8.1 | Rückblick | 122 |
| 8.2 | Unerwartete Schwierigkeiten | 123 |
| 8.3 | Ergebnisse | 124 |
| 8.4 | Ausblicke | 125 |
| Anhang A: RFC-Referenz | 126 | |
| Anhang B: CD-ROM | 128 | |
| Abbildungsverzeichnis | 129 | |
| Tabellenverzeichnis | 131 | |
| Literaturverzeichnis | 132 |
Textprobe:
Kapitel 4.6, IPv6:
In diesem Kapitel werden die Neuerungen des zukünftigen Internet-Protokolls IPv6 vorgestellt.
Warum IPv6? Durch das Wachstum des Internets stößt der Adressraum von IPv4 mit nur 32 Bit-Adressbreite in wenigen Jahren an seine Grenzen. Darüber hinaus besteht zunehmend der Wunsch nach verbesserten Sicherheitsfunktionen sowie Multimedia- und Echtzeitanwendungen. Mit der Einführung von IP in der Version 6 (IPv6) sollen diese Schwächen abgeschafft werden. Zu erwähnen ist, dass die IP Version 5 für das Stream Protokoll (ST) reserviert wurde. IPv6 stellt somit die nächste Generation von IPv4 dar. Neben dem erweiterten Adressraum steht mit IPv6 ein Protokoll zur Verfügung, das die Konfiguration und Verwaltung von Local-Area-Networks (LAN) und Wide-Area-Networks (WAN) an aktuelle und absehbare zukünftige Gegebenheiten anpasst.
Da die Umstellung von IPv4 auf IPv6 kontinuierlich verlaufen soll, sind bereits viele Maschinen mit einer Dual-Stack-Implementierung ausgestattet, d.h. sie verfügen über beide Protokollvarianten.
Änderungen gegenüber IPv4:
Obwohl viele Grundfunktionen von IPv4 beibehalten wurden, sind zahlreiche zukunftssichere Neuerungen definiert worden. Die wesentlichen Änderungen betreffen:
1. Mehr Adressen: Der Adressraum wurde um den Faktor 296 vergrößert. Es stehen somit statt der bisher 32 Bit nun 128 Bit für die Adressen bereit.
2. Neues Header-Format: Das Format des IPv6-Headers wurde fast vollständig geändert. Statt der bisherigen 13 Felder enthält er nur noch 7. Durch diese Vereinfachung wird es Routern ermöglicht, Pakete schneller zu verarbeiten, da unter anderem die Berechnung der Prüfsumme in höhere Protokollschichten verlagert wird. Optionen, welche bei IPv4 noch alle im IP-Header integriert waren, werden nun als eigener Header realisiert. Ein Datagramm besteht somit aus einem Basis-Header und mehreren Zusatz-Headern gefolgt von den Nutzdaten. Durch die daraus resultierende feste Länge des IPv6-Headers können die Datagramme schneller von den Routern verarbeitet werden.
3. Mehr Sicherheit: IPv6 führt die Verschlüsselung der „Nutzlast“ und die Echtheitsprüfung von Adressat und Absender auf Netzwerkebene ein. Dies erlaubt eine manipulations- und abhörsichere Übertragung auf jeder Verbindung zwischen zwei IPv6-Maschinen.
4. Autokonfiguration: Bei IPv6 ist es nun möglich im laufenden Betrieb und ohne umfangreiche Eingriffe des Administrators den Adress-Präfix zu verändern. Sobald eine IPv6-Schnittstelle aktiviert wird, konfiguriert diese sich automatisch. Jede IPv6-Schnittstelle ist nicht nur auf eine IPv6-Adresse beschränkt, sondern besitzt IPv6-Adressen mit unterschiedlichen Reichweiten. Damit eine Schnittstelle den nächsten Router finden kann, sendet der Router periodisch sogenannte Router-Advertisement-Nachrichten.
5. Verbesserung der Routing-Eigenschaften: Ein Großteil der Last in Routern bei IPv4 entsteht durch fragmentierte Pakete und beim Neuberechnen von Prüfsummen auf Grund eines geänderten Time-To-Live-Wertes (TTL) im Header. Der Aufwand dafür erhöht sich mit zunehmender Zahl an Datagrammen, welche durch steigende Leitungskapazitäten von den Routern verarbeitet werden müssen. Durch den geänderten IPv6-Header werden Router größtenteils von diesen Aufgaben entlastet. So wird die Prüfung von Prüfsummen auf den Transport Layer (TCP/UDP) verlegt. Das Problem der Fragmentierung wird dadurch umgangen, dass nur noch der Sender selbst ein Paket in Fragmente unterteilen darf. Router fragmentieren somit ein zu großes Paket nicht mehr, sondern verwerfen das Paket und schicken eine Fehlermeldung zum Sender, welcher die maximale Paketgröße entsprechend anpasst.
6. Erweiterbarkeit: IPv6 wurde als ein erweiterbares Protokoll entwickelt. Es wurde nicht nur versucht, alle potenziell möglichen Einsatzfelder in die Spezifikation zu integrieren, sondern es bietet auch die Möglichkeit, über Extension-Header das Protokoll zu erweitern. Damit ist das Protokoll offen für zukünftige Entwicklungen.
7. Der IPv6-Header: Ein IPv6-Packet besteht aus einem IPv6-Header gefolgt von (bis zu 7) Extended-Headern und/oder den eigentlichen Protokoll-Nutzdaten (siehe Abbildung 13: Übersicht eines IPv6-Headers). Eine IPv6-Implementierung muss alle Header bis zu den Protokoll-Nutzdaten analysieren, um zu entscheiden, welche Informationen an die nächsthöhere Protokollschicht weiterzugeben sind.
8. IPv6-Header-Datenstruktur: Der neue IPv6-Header (RFC2461) ist wegen der enormen Vergrößerung der Adressen zwar doppelt so lang wie der IPv4-Header, aber wesentlich einfacher aufgebaut somit hat er weniger Felder und ist daher einfacher zu verarbeiten [HeWi02] (siehe Abbildung 14: Aufbau eines IPv6-Basis-Headers).
Die folgende Tabelle gibt eine Übersicht über die wichtigsten Protokollwerte (P) und die in der Basis-Spezifikation definierten Extension Header (E) für das Feld Next Header (siehe Tabelle 9: Tabelle der wichtigsten Werte im Feld Next Header).
48,00 €
PDF-eBook Download: 48,00 €
Link zur Arbeit:
http://www.diplom.de/ean/9783836614627
Arbeit zitieren:
Erlenbach, Klaus November 2007: Eine effiziente IPv6 Implementierung für Steuergeräte, Hamburg: Diplomica Verlag
Schlagworte:
IPv6, Dual-Stack, Embedded System, AUTOSAR, Steuergerät



