Anpassung eines Netzwerkprozessor-Referenzsystems im Rahmen des MAMS-Forschungsprojektes
Diplomarbeit
an der Fachhochschule Hof Fachbereich Informatik / Technik Studiengang: Angewandte Informatik
Vorgelegt bei von Prof. Dr. Dieter Bauer Stefan Weber Fachhochschule Hof Pacellistr. 23 Alfons-Goppel-Platz 1 95119 Naila 95028 Hof Matrikelnr. 00041503
Abgabgetermin: Freitag, den 28. September 2007
Hof, den 27. September 2007 Diplomarbeit - ii -
Inhaltsverzeichnis
Titelseite i
Inhaltsverzeichnis ii
Abbildungsverzeichnis v
Tabellenverzeichnis vii
Quellcodeverzeichnis viii
Funktionsverzeichnis x
Abkurzungen¨ xi
Definitionen / Worterkl¨arungen xiii
1 Vorwort 1
2 Einleitung 3 2.1 Abstract ...... 3 2.2 Zielsetzung der Arbeit ...... 3 2.3 Aufbau der Arbeit ...... 4 2.4 MAMS ...... 4 2.4.1 Anwendungsszenario ...... 4 2.4.2 Einführung ...... 5 2.4.3 NGN - Next Generation Networks ...... 5 2.4.4 Abstrakte Darstellung und Begriffe ...... 7
3 Hauptteil 8 3.1 BorderGateway Hardware ...... 8 3.1.1 Control-Blade - Control-PC ...... 9 3.1.2 ConverGate-D Evaluation Board: Modell easy4271 ...... 10 3.1.3 ConverGate-D Netzwerkprozessor ...... 12 3.1.4 Motorola POWER Chip (MPC) Modul ...... 12 3.1.5 Test- und Arbeitsumgebung ...... 13 3.2 Vorhandene Software / Werkzeuge ...... 15 3.2.1 ConverGate-D Konfiguration ...... 15 3.2.2 Das U-Boot (Universal Boot) ...... 22 3.2.3 Buildroot: Cross-Compile-Umgebung ...... 24 3.2.4 Embedded Linux ...... 27 3.3 BorderGateway Software: Struktur ...... 32
Inhaltsverzeichnis - iii - Fachhochschule Hof
3.4 BorderGateway Software: Spezifikation ...... 34 3.4.1 Allgemeines ...... 34 3.4.2 Fehlerbehandlung ...... 35 3.4.3 Control-PC Schnittstelle ...... 36 3.4.4 ConverGate-D Schnittstelle ...... 54 3.4.5 Binärer Dateizugriff (BCFA) ...... 62 3.4.6 Netzwerkpakete ...... 65 3.5 BorderGateway Software: Implementierung ...... 80 3.5.1 Allgemeines ...... 80 3.5.2 Fehlerbehandlung ...... 81 3.5.3 Control-PC Schnittstelle ...... 82 3.5.4 ConverGate-D Schnittstelle ...... 91 3.5.5 Binärer Dateizugriff (BCFA) ...... 99 3.5.6 Netzwerkpakete ...... 100 3.6 Modul- / System- / Integrationstests ...... 108 3.6.1 Modul- und Funktionstests ...... 108 3.6.2 Systemtests ...... 109 3.6.3 Integrationstests ...... 123
4 Schlussbetrachtung 125 4.1 Zusammenfassung ...... 125 4.2 Ausblick ...... 126
A Pr¨aambel: Anh¨ange 128
B Meilensteine / Zeitplan 129
C Errata 131 C.1 Sourceball buildroot_easy4271.sh ...... 131 C.2 ConverGate-D Linux Kernel Treiber: drv_cg, v3.2.5 ...... 132 C.3 ConverGate-D Linux Kernel Treiber Erweiterungen ...... 133 C.4 ConverGate-D Treiber: cg_connectix ...... 133
D Offene Themen 134
E Benutzte Software 136 E.1 Betriebssysteme ...... 136 E.2 ARP / ICMP Generierung ...... 136 E.2.1 Linux: arping, ping ...... 136 E.2.2 Windows: arp.exe, ping.exe ...... 137 E.3 Serielle Verbindungen ...... 137 E.4 Ethernet Paketüberwachung ...... 138 E.5 Testpaketgenerierung ...... 138 E.6 TFTP ...... 138 E.7 NFS ...... 139 E.8 Erstellung der Diplomarbeit ...... 139 E.9 Bilder, Diagramme ...... 139 E.10 Quellcodedokumentation ...... 140
Inhaltsverzeichnis Diplomarbeit - iv -
E.10.1 Doxygen ...... 140 E.10.2 Quellcodestatistik: cncc ...... 140 E.11 Dateimanager / Editor ...... 140
F Technische Informationen 141 F.1 Quellcode ...... 141 F.2 Bytereihenfolge (byte order) ...... 141 F.3 ConverGate-D Daten ...... 142 F.4 MPC-Modul Daten ...... 142 F.5 Buildroot Daten ...... 143 F.6 uClibc: semtimedop Patch ...... 143 F.7 Installation des gesamten Quellcode ...... 143 F.8 Erstellen eines Sourceballs ...... 143 F.9 BorderGateway Software: Kommandozeilenparameter ...... 144 F.10 BorderGateway: Makefile.am ...... 145
Literaturverzeichnis 146
Internetverzeichnis 147
Index 158
Eidesstattliche Erkl¨arung 161
Inhaltsverzeichnis - v - Fachhochschule Hof
Abbildungsverzeichnis
Mit Ausnahme der Bilder 1.1 bis 2.2, 3.3 bis 3.5 und F.2 bis F.4, wurden alle Bilder in diesem Dokument vom Autor erstellt. Die Beschriftung in Bildern und Diagrammen ist durchweg in Englisch, da dieses Dokument und Bilder daraus in firmeninternen Projekten verwendet werden werden, bei denen die Sprache für technische Dokumente immer Englisch ist. Zudem ist Englisch die Sprache der IT-Industrie und lässt sich meistens nicht verständlich und knapp übersetzen. Ausgenommen hiervon sind z.B. die Internetseiten im Anhang. 1.1 Fachhochschule Hof (Logo) ...... 1 1.2 Infineon Technologies AG (Logo) ...... 1 1.3 Alcatel-Lucent (Logo) ...... 2
2.1 Multi Access, Modular Services (Logo) ...... 4 2.2 Bundesministerium für Bildung und Forschung (Logo) ...... 5 2.3 Next Generation Network (abstrakt) ...... 6 2.4 Multi Access, Modular Services (abstrakt) ...... 7
3.1 BorderGateway Hardware - prototypische Darstellung ...... 8 3.2 BorderGateway Hardware - Control-Blade (rechts) ...... 9 3.3 ConverGate-D Evaluation Board ...... 11 3.4 ConverGate-D Netzwerkprozessor ...... 12 3.5 MPC-Modul ...... 12 3.6 Testumgebung ...... 13
3.7 WinEASY - Programmfenster ...... 17 3.8 WinEASY - Neue Nachrichten ...... 18 3.9 WinEASY - LIB_WE_CGD_OpenFile ...... 19 3.10 WinEASY - LIB_WE_CGD_CloseFile ...... 19 3.11 WinEASY - CG_UC_FWD_FIB_VALUE_Assign ...... 20 3.12 WinEASY - CG_UC_FWD_FIB_VALUE_Query ...... 20 3.13 WinEASY - Nachrichtenübertragung ...... 21
3.14 BorderGateway Software - Struktur ...... 33
3.15 Befehl an MPC-Modul ...... 41 3.16 Befehl - ADD_REQ ...... 42 3.17 Befehl - SUBTRACT_REQ ...... 44 3.18 Befehl - MODIFY_REQ ...... 46 3.19 Befehl - READ_STATUS_REQ ...... 48 3.20 Befehl - CONFIG_REQ ...... 49 3.21 Befehl - WAKE_UP ...... 50 3.22 Befehl - FAULT ...... 51
Abbildungsverzeichnis Diplomarbeit - vi -
3.23 BorderGateway - Media Stream Switching (downstream) ...... 60 3.24 ARP-Request Prozess ...... 69 3.25 SIP Paketbehandlung ...... 76
3.26 Debug-Thread - Hilfe [hH?] ...... 110 3.27 Control-PC - CONFIG_REQ senden [ENTER] ...... 111 3.28 MPC-Modul - CONFIG_REQ empfangen ...... 112 3.29 MPC-Modul - FAULT senden [f] & [F] ...... 112 3.30 Control-PC - FAULT empfangen ...... 113 3.31 MPC-Modul - BorderGateway Information [1] ...... 114 3.32 MPC-Modul - BCAM und FIB Lese-/Schreibzugriffe [vV] ...... 115 3.33 Linux - ARP-Anfragen senden (arping) ...... 116 3.34 MPC-Modul - ARP-Anfragen beantworten ...... 116 3.35 Control-PC - IP- und MAC-Adresse ...... 116 3.36 MPC-Modul - ARP-Anfrage an Control-PC (Test #1) ...... 116 3.37 MPC-Modul - ARP-Anfrage an Control-PC (Test #2) ...... 117 3.38 Linux - ICMP-Anfragen senden (ping) ...... 117 3.39 MPC-Modul - ICMP-Anfragen beantworten ...... 117 3.40 MPC-Modul - SIP-Pakete senden [s] & [S] ...... 118 3.41 PC #1 - SIP-Pakete empfangen ...... 119 3.42 MPC-Modul - BorderGateway Information nach SIP-Test [1] ...... 119 3.43 PC #1 - Paket an BorderGateway senden ...... 122 3.44 PC #1 - Pakete an den BorderGateway ...... 122 3.45 PC #2 - Pakete vom BorderGateway ...... 123 3.46 T-Systems Berlin - Testaufbau ...... 124 3.47 T-Systems Berlin - Bildtelefonie ...... 124
B.1 Zeitplan ...... 130
F.1 BorderGateway Software - Kommandozeilenparameter ...... 144 F.2 MAMS Homepage ...... 148 F.3 Wikipedia: NGN ...... 149 F.4 Internet: Additive Checksums ...... 151
Abbildungsverzeichnis - vii - Fachhochschule Hof
Tabellenverzeichnis
3.1 IP-Adressen der Testumgebung ...... 14
3.2 Linux Verzeichnisbaumvergleich ...... 28
3.3 TLV Beispiel ...... 37 3.4 Control-PC ⇔ MPC-Modul TLV-Daten ...... 39 3.5 Control-PC ⇔ MPC-Modul Befehle ...... 40 3.6 BorderGateway Port Übersicht ...... 56 3.7 ConverGate-D Egress Header ...... 56 3.8 TCP/IP-Protokollstapel ...... 65 3.9 Ethernet II Header ...... 65 3.10 Ethernet Protokoll Typen ...... 65 3.11 ARP-Paket ...... 66 3.12 ARP-Paket Befehlscodes (op) ...... 66 3.13 IP-Header ...... 71 3.14 IP-Protokoll-Typen ...... 71 3.15 ICMP-Echo-Reply-Header ...... 74 3.16 ICMP Echo Typen ...... 74 3.17 UDP-Header ...... 75 3.18 UDP-Checksum-Header ...... 75
3.19 IP/UDP Eintrag im Vergleichsspeicher ...... 97 3.20 UDP/MAC Eintrag im Vergleichsspeicher ...... 97 3.21 Einträge in Weiterleitungstabelle ...... 99
F.1 Quellcodestatistik ...... 141 F.2 Big endian Beispiel ...... 142 F.3 Little endian Beispiel ...... 142 F.4 ConverGate-D - Technische Daten ...... 142 F.5 MPC-Modul - Technische Daten ...... 142
Tabellenverzeichnis Diplomarbeit - viii -
Quellcodeverzeichnis
Die Kommentare im Quellcode sind durchweg in Englisch gehalten.
3.1 IBE Makefile ...... 26 3.2 IBE easy427.target ...... 26 3.3 BorderGateway Startskript ...... 27 3.4 lib_we_cgd Makefile.am: INCLUDE ...... 29 3.5 lib_we_cgd Makefile.am: SOURCES ...... 29 3.6 lib_we_cgd.h ...... 29 3.7 lib_we_cgd.c: Includes ...... 29 3.8 lib_we_cgd.c: tCg_Ctrl() #1 ...... 29 3.9 lib_we_cgd.c: tCg_Ctrl() #2 ...... 29 3.10 lib_we_cgd.c: OnCgApi() ...... 29 3.11 drv_cg_api.h ...... 30 3.12 ioctl_api_processing_msg.h ...... 30 3.13 ioctl_api_processing_msg.c: CG_IOCTL_API_Processing_Entry() ...... 30 3.14 api_processing.h ...... 30 3.15 api_packet_handler.c: CG_PH_IRQ_Service() ...... 31 3.16 cg_swaplib.c: CG_SwapIn() ...... 31
3.17 bordergateway.c: Hauptschleife ...... 81 3.18 ifx_types.h: Rückgabewerte ...... 81 3.19 commands_result_strings.c: Rückgabestringliste ...... 81 3.20 commands.h: Rückgabestrings ...... 82 3.21 tlv.h: TLV-Block - Definition ...... 82 3.22 tlv.h: TLV-Block - action-Feld ...... 82 3.23 tlv.h: TLV-Block - TLV-C-Funktion ...... 82 3.24 tlv.h: TLV-Block schreiben ...... 83 3.25 tlv.h: TLV-Block lesen ...... 83 3.26 commands.h: Nachrichtenstruktur ...... 84 3.27 context.h: Halfcall - Struktur ...... 85 3.28 context.h: Kontext - Struktur ...... 85 3.29 commands_message_table.c: Nachrichtentabelle - Struktur ...... 85 3.30 commands.h: In Fehlerwarteschlange schreiben ...... 88 3.31 commands.h: Aus Fehlerwarteschlange lesen ...... 89 3.32 udp_sockets.h: UDP-Paket versenden ...... 90 3.33 udp_sockets.h: UDP-Paket empfangen ...... 91 3.34 Linux: ioctl() ...... 91 3.35 evalboard.h: DIP-Switches lesen ...... 92 3.36 evalboard.h: User-LEDs schreiben ...... 92 3.37 packet.h: ConverGate-D-Paket ...... 93 3.38 packet.h: Payloaddatentyp ...... 93
Quellcodeverzeichnis - ix - Fachhochschule Hof
3.39 packet.h: Beispielzugriff auf Ethernet-Header ...... 93 3.40 convergate.c: Egress-Port lesen ...... 94 3.41 convergate.c: Egress-Port schreiben ...... 94 3.42 convergate.h: WinEASY-Konfiguration schreiben ...... 95 3.43 convergate.c: MAC-Adresse setzen ...... 96 3.44 convergate.c: MAC-Adresse lesen ...... 96 3.45 convergate.c: Vergleichsspeicher (BCAM) schreiben ...... 97 3.46 convergate.c: Vergleichsspeicher (BCAM) lesen ...... 98 3.47 convergate.c: Vergleichsspeicher (BCAM) löschen ...... 98 3.48 convergate.c: Weiterleitungstabelle schreiben ...... 98 3.49 bcfa.h: BCFA - Header ...... 99 3.50 bcfa.h: BCFA - Dateizugriff ...... 100 3.51 bcfa.h: BCFA - Operationskonstanten ...... 100 3.52 eth.h: Ethernet-Header schreiben ...... 101 3.53 arp.h: ARP-Request-Header schreiben ...... 101 3.54 arp.h: ARP-Reply-Header schreiben ...... 102 3.55 convergate.h: ARP-Request beantworten ...... 102 3.56 convergate.h: ARP-Request senden ...... 102 3.57 arp.h: ARP-Reply verarbeiten ...... 103 3.58 ip.h: IP-Header schreiben ...... 103 3.59 sip.h: SIP-Paket einpacken ...... 104 3.60 sip.h: SIP-Paket auspacken ...... 104 3.61 icmp.h: Aufbau eines ICMP-Paketes ...... 105 3.62 udp.h: Aufbau eines UDP-Paketes ...... 105 3.63 packet.h: UDP-Prüfsummenstruktur ...... 106 3.64 sip.h: SIP-Paket überprüfen ...... 106 3.65 packet.h: IP-Prüfsummen ...... 107 3.66 packet.c: IP-Prüfsummencode ...... 107
4.1 fault_pipe.h: FAULT_PIPE_WAIT_TIMEOUT_READ ...... 127
C.1 IBE Installationsskript ...... 131 C.2 IBE Sourceball ...... 132
F.1 BorderGateway Makefile.am ...... 145
Quellcodeverzeichnis Diplomarbeit - x -
Funktionsverzeichnis
Dieses Verzeichnis scheint auf den ersten Blick wenig hilfreich. Dies ändert sich allerdings wenn konkret nach einer Funktionsbeschreibung sowie den korrespondierenden Funktionsprototyp gesucht wird. Beschreibung 1 ...... 36 Prototyp 1 ...... 81 Beschreibung 2 ...... 37 Prototyp 2 ...... 83 Beschreibung 3 ...... 38 Prototyp 3 ...... 83 Beschreibung 4 ...... 52 Prototyp 4 ...... 88 Beschreibung 5 ...... 53 Prototyp 5 ...... 89 Beschreibung 6 ...... 53 Prototyp 6 ...... 90 Beschreibung 7 ...... 53 Prototyp 7 ...... 90 Beschreibung 8 ...... 54 Prototyp 8 ...... 92 Beschreibung 9 ...... 55 Prototyp 9 ...... 92 Beschreibung 10 ...... 57 Prototyp 10 ...... 94 Beschreibung 11 ...... 57 Prototyp 11 ...... 94 Beschreibung 12 ...... 57 Prototyp 12 ...... 95 Beschreibung 13 ...... 58 Prototyp 13 ...... 95 Beschreibung 14 ...... 58 Prototyp 14 ...... 96 Beschreibung 15 ...... 58 Prototyp 15 ...... 96 Beschreibung 16 ...... 60 Prototyp 16 ...... 97 Beschreibung 17 ...... 61 Prototyp 17 ...... 98 Beschreibung 18 ...... 61 Prototyp 18 ...... 98 Beschreibung 19 ...... 61 Prototyp 19 ...... 98 Beschreibung 20 ...... 62 Prototyp 20 ...... 98 Beschreibung 21 ...... 63 Prototyp 21 ...... 100 Beschreibung 22 ...... 63 Prototyp 22 ...... 100 Beschreibung 23 ...... 64 Prototyp 23 ...... 100 Beschreibung 24 ...... 64 Prototyp 24 ...... 100 Beschreibung 25 ...... 65 Prototyp 25 ...... 101 Beschreibung 26 ...... 66 Prototyp 26 ...... 101 Beschreibung 27 ...... 68 Prototyp 27 ...... 102 Beschreibung 28 ...... 70 Prototyp 28 ...... 102 Beschreibung 29 ...... 71 Prototyp 29 ...... 103 Beschreibung 30 ...... 72 Prototyp 30 ...... 103 Beschreibung 31 ...... 73 Prototyp 31 ...... 104 Beschreibung 32 ...... 73 Prototyp 32 ...... 104 Beschreibung 33 ...... 74 Prototyp 33 ...... 105 Beschreibung 34 ...... 75 Prototyp 34 ...... 105 Beschreibung 35 ...... 77 Prototyp 35 ...... 106 Beschreibung 36 ...... 78 Prototyp 36 ...... 106 Beschreibung 37 ...... 78 Prototyp 37 ...... 106 Beschreibung 38 ...... 78 Prototyp 38 ...... 107
Funktionsverzeichnis - xi - Fachhochschule Hof
Abkurzungen¨
Einige der hier aufgelisteten Abkürzungen werden nicht in dieser Arbeit verwendet. Da aber häufig in weiterführenden bzw. verwiesenen Dokumenten eine Vielzahl von Abkürzun- gen ohne Erklärung vorkommen, hat sich der Autor entschieden, zusätzliche, themenbezogene Abkürzungen mit in diese Liste aufzunehmen.
API Application Programming Interface ARP Address Resolution Protocol ATCA Advanced Telecommunications Computing Architecture B2BUA Back-to-back User Agent BCAM Binary Content Addressable Memory BCFA Binary Configuration File Access BG BorderGateway BMBF Bundesministerium für Bildung und Forschung BRAS Broadband Remote Access Server CB Control-Blade (Control-PC) CG ConverGate-D CRLT Classification Result Location Table DIP Dual In-line Package DSCP DiffServ Code Point DSLAM Digital Subscriber Line Access Multiplexer FCS Frame Check Sequence FIB Forwarding Information Base FIFO First In First Out GbE Gigabit Ethernet IBE Infineon Buildroot Extension ICMP Internet Control Message Protocol IMS IP Multimedia Subsystem IOCTL Input/Output Control IP Internet Protocol IP-DSLAM for IP based Digital Subscriber Line Access Multiplexer IPNI Ingress Port Number Information
Abkürzungen Diplomarbeit - xii -
ISONI Intelligent Service Oriented Network Infrastructure IT Informations Technologie JFFS2 Journalling Flash File System 2 KMU kleine und mittlere Unternehmen LAN Local Area Network LED Light-Emitting Diode MAC Media Access Control MAMS Multi Access, Modular Services MG Media Gateway MIB Management Information Base MMS Multimedia Messaging Service MPC Motorola POWER Chip MSS Media Stream Switching MSS+ Enhanced Media Stream Switching NFS Network File System NGN Next Generation Network ODSDP Open Distributed Service Delivery Platform PDU Protocol/Payload Data Unit PosPHY POS-PHY Level 3 saturn-compatible Packet Over Sonet interface specification for PHYsical and link layer devices QoS Quality of Service RFC Request for Comments RTCP Real Time Control Protocol RTP Real Time Protocol SDP Service Delivery Platform SIP Session Initiation Protocol SMS Short Message Service TFTP Trivial File Transfer Protocol TK Telekommunikation TLV Type Length Value UA User Agent UDP User Datagram Protocol UMPR User’s Manual, Programmer’s Reference VoIP Voice over IP XML Extensible Markup Language
Abkürzungen - xiii - Fachhochschule Hof
Definitionen / Worterkl¨arungen
Dieses Kapitel erklärt wichtige Wörter und legt z.B. Einheiten fest.
• Bit: Kleinste Speichereinheit. • Byte, Octet: Entspricht 8-Bit. • Word, Wort: Entspricht 16-Bit. • DWord (Doubleword, Doppelwort): Entspricht 32-Bit. • 1 Kilo: In Verbindung mit den vorherigen Speichereinheiten entspricht dies nicht dem physikalischen Wert 1000, sondern 1024 = 210. • k = Kilo, M = Mega, G = Giga, ... : Es gilt die physikalische Standardschreibweise für Größeneinheiten. • Byte = B, Bit = b: Es werden z.B. Kilobyte in kB und Megabit in Mb angegeben. • 0x00, 0x0a, ... : Hexadezimale Schreibweise eines Wertes in C/C++. • Embedded System / eingebettetes System: Direkt in Hardware eingebettetes Computer- system ohne Zugriff auf externe Quellen. • easy4271: Modellbezeichnung des ConverGate-D Evaluation Board. • make und makefile: Programm und Ausführungsvorschrift um Prozesse, z.B. Übersetzen von Quellcode, automatisiert auszuführen. • Image: Abbild bzw. Datei, z.B. JFFS21-Image. • Header: Eine am Beginn eines Datenblockes stehende Datenstruktur mit Informationen über die folgenden Daten. • String: Zeichenkette. • Stack: Ein Stack (Stapel) ist eine Datenstruktur, welche aus Elementen und einem Zeiger auf diese Elemente (Elementzeiger) besteht. Schreiben: Ein Wert wird in ein Element des Stack geschrieben, dann wird der Element- zeiger auf das nächste Element gesetzt. Lesen: Der Elementzeiger wird auf das vorhergehende Element gesetzt, dann wird der Wert gelesen. • Thread: Ein Thread ist ein zum Hauptprogramm parallel laufendes Programm, das einen eigenen Stack besitzt aber auf die gleichen Ressourcen (Variablen, Funktionen) zugreift. Es können beliebig viele Threads gleichzeitig laufen (abhängig von Betriebssystem, Speicher und Prozessorleistung). • Zeiger, Pointer: Wert der auf einen Datentyp oder eine Struktur zeigt.
1Journalling Flash File System 2
Definitionen / Worterklärungen Diplomarbeit - xiv -
• NULL: Bezeichnet einen Zeiger der den Wert 0 hat. • Port: Physikalische oder logische Schnittstelle zwischen zwei Geräten. • MAC2-Adresse / Hardware Adresse: 6 Byte lange Nummer über die jede Hardware in einem Netzwerk eindeutig identifiziert werden kann.
2Media Access Control
Definitionen / Worterklärungen - 1 - Fachhochschule Hof
Kapitel 1
Vorwort
Diese Diplomarbeit dokumentiert meine Arbeit an einem Forschungsprojekt seit dem 1.3.2007. Da mit der Abgabe dieser Arbeit ein wichtiger Lebensabschnitt endet und ein neuer beginnt, möchte ich an dieser Stelle die Gelegenheit nutzen mich bei einigen Personen zu bedanken. Allen voran möchte ich meiner Familie für die Unterstützung in den vier Jahren meines Studiums danken. Besonders meinem Bruder Martin, der mir immer Vorbild und wichtiger Ansprechpart- ner war. Abb. 1.1: Fachhochschule Hof (Logo)
Dank gilt der Fachhochschule Hof, die immer für eine komfortable und funktionierende Hard- und Software gesorgt hat, sowie den Professoren und Dozenten, die stets um eine kollegiale, teils freundschaftliche Atmosphäre bemüht waren. Als Prüfer dieser Arbeit und meinen ersten Ansprechpartner in organisatorischen Themen rund um die Diplomarbeit, möchte ich besonderen Dank an Prof. Dr. Dieter Bauer richten. Abb. 1.2: Infineon Technologies AG (Logo)
Ich bedanke mich bei den Mitarbeitern und Kollegen der Infineon Technologies AG, die mir das Praktikum und damit auch die Diplomarbeit ermöglicht haben: Thomas Drews, Henrik Höfner und Andreas Foglar. Besonderer Dank gilt meinem chinesischen Projektkollegen Beier Li, der an entscheidenden Teilen dieses Projektes beteiligt war.
Kapitel 1 Vorwort Diplomarbeit - 2 -
Abb. 1.3: Alcatel-Lucent (Logo)
Abschließend danke ich dem auftraggebenden und federführenden Projektpartner Alcatel- Lucent für die gute Zusammenarbeit und die Einladungen nach Stuttgart. Insbesondere meinem direkten Ansprechpartner, Herrn Joachim „Jean“ Riemer, für den unkomplizierten, prompten und freundlichen Kontakt, sowie Herrn Thomas-Rolf Banniza, der mir zum Abschluss meiner Diplomarbeit die Veröffentlichung dieses Dokumentes ermöglicht hat.
Kapitel 1 Vorwort - 3 - Fachhochschule Hof
Kapitel 2
Einleitung
2.1 Abstract
Seit einigen Jahren wird daran gearbeitet, die verschiedenen Multimediadienste (z.B. SMS (Short Message Service) oder MMS (Multimedia Messaging Service) für Handys, ...) mitein- ander zu vernetzen. Diese neuen Netze werden Next Generation Networks (NGN) genannt. Das „Multi Access, Modular Services“-Forschungsprojekt (MAMS) will ein solches Netz prototypisch entwerfen, implementieren und erproben.
Der Übergang zwischen verschiedenen Netzen wird durch sog. BorderGateways ermöglicht, wel- che Verbindungen zwischen Benutzern bzw. Anwendungen verwalten und Datenströme weiter- leiten. Der Kern eines BorderGateway ist in der Regel ein Netzwerkprozessor. In MAMS wird ein Netzwerkprozessor von Infineon eingesetzt werden.
Diese Diplomarbeit wird die Konfiguration der Hardware und Anpassung der Software des Netz- werkprozessors ConverGate-D von Infineon für den Einsatz im BorderGateway beschreiben, spe- zifizieren und implementieren.
2.2 Zielsetzung der Arbeit
Ziel dieser Arbeit ist die Spezifikation und Implementierung einer prototypischen Software auf einem Netzwerkreferenzsystem für die Anwendung im MAMS1-Forschungsprojekt.
Die Spezifikation der Grundfunktionalität der Software wird in Zusammenarbeit mit Alcatel- Lucent, die Konfiguration der Hardware mit dem Diplomanden Beier Li [9] erarbeitet. Die Spe- zifikation der Software und die Umsetzung bzw. Implementierung geschieht durch den Autor dieses Dokumentes.
Am Ende der Arbeit soll eine funktionsfähige Umsetzung der Spezifikation an Alcatel-Lucent ge- liefert werden können.
1Multi Access, Modular Services
2.3 Aufbau der Arbeit Kapitel 2 Einleitung Diplomarbeit - 4 -
2.3 Aufbau der Arbeit
Dieses Kapitel soll einleitend über die Diplomarbeit und das MAMS-Forschungsprojekt berich- ten. Im Hauptteil wird die Hardware-Plattform sowie bereits existierende Software mitsamt nötigen Änderungen erläutert. Gefolgt werden diese beiden Kapitel von der BorderGateway Softwa- re Spezifikation, der Implementierungsbeschreibung sowie den Software-Tests. Abschließend wird in der Zusammenfassung ein Resümee über die gesamte Diplomarbeit gezo- gen und in dem darauf folgenden Ausblick weiterführende Ansätze und Ideen betrachtet.
2.4 MAMS - Multi Access, Modular Services
Abb. 2.1: Multi Access, Modular Services (Logo)
MAMS soll die Entwicklung und Bereitstellung von Telekommunikations- und Multimediadiens- ten für Anwender ohne spezielle Programmierkenntnisse ermöglichen. Hauptzielgruppe sind kleine und mittlere Unternehmen (KMU). Prinzipiell handelt es sich bei der Funktionalität von MAMS um eine Verbindung zwischen zwei Teilnehmern, einem Anrufer und einem Angerufe- nen2. Dieses Forschungsprojekt ist in zwei Phasen unterteilt, wobei für jede Phase 18 Monate geplant sind. Im Moment befindet sich das Projekt in Phase 1, welche im September 2007 endet. Diese Arbeit konzentriert sich ausschließlich auf MAMS Phase 1. Zuerst soll an einem einfachen Beispiel die Grundidee von MAMS verdeutlicht werden.
2.4.1 Anwendungsszenario: Ortsabh¨angige Werbeinformation uber¨ Handy
Ein Geschäft bietet seinen Kunden an, Werbeinformationen via SMS3 automatisch an deren Handy zu schicken, wenn diese sich in einem bestimmten Umkreis um das Geschäft aufhalten. Hierzu legt der Geschäftsinhaber über das Internet, z.B. http://mams.münchen.de, via simpler Onlinemasken eine neue Benutzergruppe sowie einen neuen Multimedia-Dienst an. In die Benutzergruppe trägt er die Namen sowie die Handynummern der Kunden ein, die diese Dienstleistung in Anspruch nehmen möchten.
2Caller und Callee 3Short Message Service
Kapitel 2 Einleitung 2.4 MAMS - 5 - Fachhochschule Hof
Den Onlinedienst nennt der Geschäftsführer ’Lokale Werbeinformation via SMS’. Hierzu konfi- guriert er die Positionsparameter mit der Adresse seines Geschäftes und den Einzugsbereich für die Dienstleistung (z.B. 5km). Als nächstes legt er den Inhalt seiner Nachricht fest, z.B. durch das Hochladen einer Datei mit dem vorbereiteten Inhalt. Zu guter Letzt spezifiziert er die Art der Datenübertragung, in diesem Fall Handy und SMS. Nach erfolgreicher, vom Online-System unterstützter und überwachter Konfiguration installiert (aktiviert!) der Geschäftsinhaber den Dienst.
2.4.2 Einfuhrung¨
Da MAMS ein äußerst umfangreiches Projekt mit unzähligen Abkürzungen, neuen Wortschöp- fungen und Querverweisen ist, wird in diesem Dokument nur der Teil von MAMS so knapp wie möglich erläutert und zitiert, der auf den eigentlichen Kern dieser Arbeit hinführt. Abb. 2.2: Bundesministerium für Bildung und Forschung (Logo)
Hierzu ein Auszug der Startseite der offiziellen Homepage: MAMS ist ein vom BMBF (Bundesministerium für Bildung und Forschung)4 gefördertes Verbundvorha- ben, welches im März 2006 gestartet wurde. Das Vorhaben wird getragen durch Partner aus Forschung und Industrie unter der Konsortialführung der Deutschen Telekom AG, Laboratories. ... Die Vision von MAMS ist der prototypische Entwurf sowie die exemplarische Umsetzung und Erprobung einer neuartigen, einheitlichen und offenen Service Delivery Platform (SDP) basierend auf Next Generation Networks (NGN5) und einer zugehörigen durchgängigen Werkzeugkette zur vereinfachten Entwicklung, Verteilung, Simulation und Ausführung von Diensten für unterschiedlichste IT6/TK7-Anwendungen. [16] Die genaue Bezeichnung der Service Delivery Platform in MAMS ist Open Distributed Service Delivery Platform (ODSDP). Auf eine detailliertere Erklärung wird hier verzichtet, da dies kein Bestandteil dieser Arbeit ist. 8
2.4.3 NGN - Next Generation Networks
Next Generation Network (NGN) ist ein Begriff aus der Telekommunikation, mit dem ein Kommunika- tionsnetz bezeichnet wird, das sich durch die Konvergenz9 herkömmlicher Netze (Telefonnetze, Mobilfun- knetze etc.) mit IP-basierten Netzen ergibt. Dabei zeichnet sich ein NGN durch eine Systemarchitektur aus, die im Wesentlichen aus folgenden Kom- ponenten besteht:
4http://www.bmbf.de 5Next Generation Network 6Informations Technologie 7Telekommunikation 8http://de.wikipedia.org/wiki/Service_Delivery_Platform 9Verschmelzung, Vereinigung
2.4 MAMS Kapitel 2 Einleitung Diplomarbeit - 6 -
Media Gateways, welche die einzelnen Netze physikalisch verbinden und für die Übertragung von Informationen sorgen - einschließlich dabei notwendiger Format- und Datenkonvertierung, und Softswitches, welche die Media Gateways steuern, und zum Beispiel Verbindungen über alle Netzgren- zen hinweg auf- und abbauen. [17] Abb. 2.3: Next Generation Network (abstrakt)
Next Generation Networks bauen also u.a. auf Media Gateways auf. In MAMS entspricht dem Media Gateway der BorderGateway. Das Ziel dieser Diplomarbeit wird ein Teil des BorderGate- way sein, und zwar das sog. Media Stream Switching10. Der BorderGateway besteht aus Hard- und Software, welche in 3.1 BorderGateway Hardware und 3.2 Vorhandene Software / Werkzeuge näher erläutert werden.
Ein bekanntes Beispiel für ein Next Generation Network ist z.B. Voice over IP12.
Die in dem Zitat erwähnten Softswitches sind in MAMS sog. Back-to-back User Agents (auch SIP13-Proxies). Diese Instanzen erhalten und senden über die BorderGateways SIP-Pakete, wel- che zum Auf- und Abbau von Verbindungen über den BorderGateway dienen. In dieser Arbeit spielt der Back-to-back User Agent nur eine virtuelle Rolle für die Behandlung von SIP-Paketen. Siehe 3.4.6.7 SIP - Session Initiation Protocol.
10MSS: Umschalten bzw. verbinden und optionales Umwandeln von medialen, IP11-basierten Datenströmen. 12http://de.wikipedia.org/wiki/VoIP 13Session Initiation Protocol
Kapitel 2 Einleitung 2.4 MAMS - 7 - Fachhochschule Hof
2.4.4 Abstrakte Darstellung und Begriffe
Der BorderGateway ist das Bindeglied zwischen zwei voneinander unabhängigen Netzen. Abb. 2.4: Multi Access, Modular Services (abstrakt)
Auf der A-Seite befindet sich das Zugangs- bzw. Benutzernetzwerk. Dieses Netz (z.B. das Inter- net) ist frei für jederman zugänglich und wird daher als unsicher bezeichnet (insecure). Die B-Seite ist das sog. Overlay-Network (übergelagertes Netzwerk). Dieses Seite ist ein abge- schlossenes System eines Anbieters bzw. Providers und gilt daher als sicher (secure). Eine Verbindung in Richtung A nach B in das Overlay-Network wird upstream genannt (Da- tenstrom nach oben). Eine Verbindung von B nach A gilt als downstream (Datenstrom nach unten). Eine Verbindung in eine Richtung wird auch Halfcall14 oder Terminierung15 genannt. Zwei (oder mehr) Verbindungen bzw. Halfcalls und deren gemeinsame Daten bilden den sog. Kontext. Die erwähnten Datenströme zwischen den Teilnehmern bestehen aus UDP16-Paketen, genauge- nommen RTP17 und RTCP18. Diese beiden Protokolle dienen der Übetragung von Audio- und Videodaten über IP-basierte Netzwerke, z.B. dem Internet.
14Hälfte eines Anrufs bzw. einer Verbindung 15Netzabschluss 16User Datagram Protocol 17Real Time Protocol 18Real Time Control Protocol
2.4 MAMS Kapitel 2 Einleitung Diplomarbeit - 8 -
Kapitel 3
Hauptteil
Dieses Kapitel beschreibt die Hardware und Software rund um den BorderGateway. Außerdem wird hier die Spezifikation und die Implementierung der BorderGateway Software auf dem ConverGate-D Evaluation Board dokumentiert.
3.1 BorderGateway Hardware
Dieser Abschnitt beschäftigt sich mit der Hardware des BorderGateways. Hier werden die einzel- nen Hardware-Elemente beschrieben und in Verbindung gebracht. Das folgende Bild zeigt eine prototypische Darstellung der BorderGateway Hardware, welche im Folgenden dann einzeln erklärt wird. Abb. 3.1: BorderGateway Hardware - prototypische Darstellung
Kapitel 3 Hauptteil 3.1 BorderGateway Hardware - 9 - Fachhochschule Hof
3.1.1 Control-Blade - Control-PC
Die von Alcatel-Lucent bereitgestellten Steuereinheiten für den BorderGateway sind sog. Control-Blades (ATCA1-Blades). Diese Hardware enthält auf möglichst kleinem Raum einen kompletten Rechner mit hoher Leistung für die Anwendung als Host bzw. Server. Aufgrund des platzsparenden Designs können mehrere Blades in „Schränken“ nebeneinander installiert und betrieben werden. Abb. 3.2: BorderGateway Hardware - Control-Blade (rechts)
Control-Blades steuern nicht nur den BorderGateway, sondern realisieren auch die in 2.4.3 NGN - Next Generation Networks erwähnten Back-to-back User Agents. Über eine 10 Mbit-Ethernet- Schnittstelle 2 (siehe 3.1.2 ConverGate-D Evaluation Board: Modell easy4271) des ConverGate-D Eva- luation Board kommunizieren Control-Blade und MPC-Modul miteinander, wobei das Modul eher den passiven Teil der beiden Einheiten darstellt, siehe 3.1.4 Motorola POWER Chip (MPC) Modul. Die Einheiten im BorderGateway arbeiten in little endian byte order, siehe F.2 Bytereihenfolge (byte order). In dieser Arbeit ersetzt ein Control-PC die Control-Blade-Einheit. Von hier an werden Control- Blade und Control-PC als Synonyme betrachtet. Die Control-PC-Software für die Steuerung des BorderGateway ist nicht Teil dieser Arbeit und wird ausgeblendet. Ab hier wird der Begriff BorderGateway Software rein für die in dieser Diplomarbeit entwickelte Software (den BorderGateway-Teilbereich Media Stream Switching) verwendet, um eine eindeutige Terminologie einzuführen.
1Advanced Telecommunications Computing Architecture 2Schnittstelle: Interface
3.1 BorderGateway Hardware Kapitel 3 Hauptteil Diplomarbeit - 10 -
3.1.2 ConverGate-D Evaluation Board: Modell easy4271
Das Infineon ConverGate-D Evaluation Board enthält Hardwarebausteine für alle modernen Netzwerkanwendungen. Entscheidend für den BorderGateway in MAMS sind folgende Elemen- te (von links nach rechts und oben nach unten, siehe Abbildung 3.3 ConverGate-D Evaluation Board): • RS232 : Serielle Schnittstelle zum netzwerkunabhängigen Zugriff auf das MPC-Modul. Über diese Schnittstelle kann mit einem Terminalprogramm das Board jederzeit via Tasta- tur gesteuert werden, siehe E.3 Serielle Verbindungen. • MBC2 / MBC1 : Die Schnittstellen (PosPHY3) dienen zum Anschluss eines zusätzlichen Motherboards (Sub-Board), z.B. der Media Conversion Hardware aus MAMS Phase 2. Sie spielen aber für diese Arbeit keine Rolle. • User LEDs 4: Die 8 Leuchtdioden stehen der Software auf dem MPC-Modul zur freien Verfügung. Die LED Nummerierung von links nach rechts ist 7 bis 0. • User DIPs 5: Über diese 8 Schalter kann Software auf dem MPC-Modul konfiguriert wer- den. • MPC-Module : Zentrale Steuereinheit für das Board, siehe 3.1.4 Motorola POWER Chip (MPC) Modul. Das Modul selbst fehlt in der Darstellung. • ETH : Die 10 Mbit Ethernet Schnittstelle für das MPC-Modul, zur Kommunikation mit dem Control-PC. • ConverGate-D : Der Netzwerkprozessor, siehe 3.1.3 ConverGate-D Netzwerkprozessor. • MII / GMII / TBI : Die Ethernet Schnittstelle für den Netzwerkprozessor. Diese wird im Gigabit Modus betrieben, kann aber z.B. auch Fast Ethernet (10/100 Mbit). Im GbE6 Mo- dus werden Port 0 und Port 1 verwendet.
3POS-PHY Level 3 saturn-compatible Packet Over Sonet interface specification for PHYsical and link layer devices 4Light-Emitting Diode, Leuchtdioden 5Dual In-line Package, Miniaturschalter 6Gigabit Ethernet
Kapitel 3 Hauptteil 3.1 BorderGateway Hardware - 11 - Fachhochschule Hof
Abb. 3.3: ConverGate-D Evaluation Board
3.1 BorderGateway Hardware Kapitel 3 Hauptteil Diplomarbeit - 12 -
3.1.3 ConverGate-D Netzwerkprozessor
Der ConverGate-D ist ein Netzwerkprozessor, der dazu dient, Datenpakete so effizient wie mög- lich von Teilnehmer 1 zu Teilnehmer 2 weiterzuleiten7. Die Zuordnung zwischen eingehenden Paketen und Zieladresse im hier angewendeten Szenario geschieht über einen Vergleichsspei- cher (BCAM8) und eine Weiterleitungstabelle (FIB9). Abb. 3.4: ConverGate-D Netzwerkprozessor
Der ConverGate-D wird vom MPC-Modul aus konfiguriert, siehe 3.1.4 Motorola POWER Chip (MPC) Modul, zudem wird unterschieden zwischen statischer und dynamischer Konfiguration, siehe 3.2.1 ConverGate-D Konfiguration. Zur statischen Konfiguration gehört auch die MAC-Adresse des ConverGate-D. A und B-Seite haben somit die gleiche Hardwareadresse.
Für technische Details siehe F.3 ConverGate-D Daten.
3.1.4 Motorola POWER Chip (MPC) Modul
Das MPC-Modul ist das Herz des BorderGateway, denn von ihm aus wird das gesamte Media Stream Switching gesteuert und initialisiert. Das MPC-Modul bekommt lediglich Daten vom Control-PC um Verbindungen zu überwachen, auf- oder abzubauen. Abb. 3.5: MPC-Modul
7Forwarding 8Binary Content Addressable Memory 9Forwarding Information Base
Kapitel 3 Hauptteil 3.1 BorderGateway Hardware - 13 - Fachhochschule Hof
Das MPC-Modul besitzt u.a. einen 8 MB Flash-Speicher, in dem ein Bootprogramm und ein Betriebssystem Platz finden. Damit ist das ConverGate-D Evaluation Board völlig unabhängig von externen Quellen und kann somit als Referenzsystem für eine spätere Massenprodukti- on benutzt werden. Zu dem MPC-Modul gehört auch eine Ethernet-Schnittstelle, siehe ETH in 3.1.2 ConverGate-D Evaluation Board: Modell easy4271.
Für die Beschreibung der installierten Software siehe 3.2.4 Embedded Linux. Für technische Details siehe F.4 MPC-Modul Daten.
3.1.4.1 Flash-Speicher
Flash-Speicher ist ein häufig wiederbeschreibbarer Speicher, der die geschriebenen Daten ohne zusätzliche Spannungsquelle permanent halten kann. Er wird z.B. in USB-Sticks verwendet.
3.1.5 Test- und Arbeitsumgebung
Für den Betrieb des BorderGateways und den Test der BorderGateway-Funktionen musste eine einfache, möglichst wirklichkeitsnahe Arbeitsumgebung eingerichtet werden. Diese wird sche- matisch im nächsten Bild dargestellt. Abb. 3.6: Testumgebung
3.1 BorderGateway Hardware Kapitel 3 Hauptteil Diplomarbeit - 14 -
Entscheidend hierbei ist, dass sich tatsächlich beide Gigabit Ethernet-Schnittstellen in unter- schiedlichen Netzwerken befinden, da sonst Systemtests die Funktion des BorderGateway nicht eindeutig nachweisen können. Für die Software-Tests ist die gestrichelt dargestellte Verbindung von Control-PC und MPC- Modul zu der A-Seite interessant, siehe 3.6 Modul- / System- / Integrationstests. Somit befinden sich Control-PC , MPC-Modul und eine GbE-Schnittstelle im selben Netzwerk und können sich gegenseitig Pakete schicken. Die einzelnen Netzwerkelemente haben folgende IP-Adressen:
Tab. 3.1: IP-Adressen der Testumgebung Netzwerkelement IP-Adresse Control-PC 192.168.152.14 MPC-Modul 192.168.152.18 ConverGate-D A-Seite 192.168.152.50 ConverGate-D B-Seite 192.168.152.51 PC #1 192.168.152.10 PC #2 192.168.152.99
Siehe 2.4.4 Abstrakte Darstellung und Begriffe.
Kapitel 3 Hauptteil 3.1 BorderGateway Hardware - 15 - Fachhochschule Hof
3.2 Vorhandene Software / Werkzeuge
Dieser Abschnitt behandelt Software und Werkzeuge rund um die BorderGateway-Hardware, die bereits vor diesem Projekt vorhanden waren und unbedingt erforderlich für die Durchführung dieses Projektes sind. Zudem sind hier notwendige Änderungen und Erweiterungen dokumentiert. Es werden Proto- typen, Strukturen und Konstanten aus dem Code zum besseren Verständnis gezeigt, Quellcode dagegen wird nur zeilenweise zur Orientierung verwendet. Grundsätzlich ist die Entwicklungsumgebung Linux. Zur Erstellung und Übertragung der Konfi- guration des ConverGate-D wird außerdem Microsoft Windows benötigt.
3.2.1 ConverGate-D Konfiguration
Die Konfiguration des ConverGate-D besteht aus mehreren Teilen. Interessant hierbei ist, dass dieses Projekt eine völlig neue Anwendung des ConverGate-D darstellt, welche eine von Grund auf neue Konfiguration sowie Firmwareänderungen beinhaltet. Hauptänderung besteht in der Zuordnung von Paketen zwischen zwei Teilnehmern, nicht wie ursprünglich über den Vergleich von MAC-Hardwareadressen sondern jetzt aufgrund von IP- und UDP-Paketinformationen.
3.2.1.1 Firmware
Die Firmware des ConverGate-D ist verantwortlich für die Verarbeitung und Weiterleitung von Netzwerkpaketen über die verschiedenen Kommunikationsschnittstellen des ConverGate-D Eva- luation Board. Sie ist modular aufgebaut (unterteilt in diverse Untermodule) und bekommt die Pakete aus einer Eingangswarteschlange (Ingress-Queue). Nach Verarbeitung der Pakete wer- den diese in eine Ausgangswarteschlange (Egress-Queue) gestellt. Die Warteschlangen werden durch die ConverGate-D-Hardware verwaltet. [7] Die bisherige Firmware war nicht fähig, die für das MAMS-Forschungsprojekt benötigten Funk- tionen bereitzustellen. Die daraufhin angepasste Firmware basiert auf der ursprünglichen Versi- on 3.2.3 und wurde von Beier Li [9] spezifiziert und umgesetzt. Es mussten folgende Änderungen vorgenommen werden: 1. IP-UDP-Behandlung Bisher hat die Firmware nur MAC-Adressen (Ethernet Information) verglichen und aus- getauscht. Da jetzt aber IP-Adresse und UDP-Port verglichen werden, müssen zusätzlich zur MAC-Adresse auch IP-Adresse und UDP-Port ausgetauscht werden. Siehe 3.4.6.3 IP - Internet Protocol (v4) und 3.4.6.6 UDP - User Datagram Protocol. 2. IP-UDP-Header-Checksum Da Zugriff auf und Änderung von Informationen in den IP-Paketen stattfindet, muss ei- ne Neuberechnung der IP- und UDP-Prüfsumme vorgenommen werden. Die UDP-Summe wird hierbei auf 0 gesetzt (die Prüfsumme wird ignoriert). Siehe 3.4.6.8 IP-Prüfsummen, 3.5.6.8 IP-Prüfsummen und Seite 151.
3.2 Vorhandene Software / Werkzeuge Kapitel 3 Hauptteil Diplomarbeit - 16 -
3.2.1.2 Statische Konfiguration
Mit statischer Konfiguration ist der Teil der Einstellungen gemeint, der nur einmal (sinnvol- ler Weise beim Start der BorderGateway Software) ausgeführt werden muss. Sie kann in drei Bestandteile geordnet werden und besteht aus: 1. Der Grundkonfiguration des ConverGate-D für die Anwendung in MAMS, die mit WinEA- SY von Beier Li [9] umgesetzt wurde. Siehe 3.2.1.4 WinEASY Erweiterungen. 2. Der Übermittlung einer Firmware an den ConverGate-D, siehe 3.2.1.1 Firmware. 3. Einer eindeutigen MAC-Adresse für den ConverGate-D. Siehe 3.2.1.3 WinEASY, 3.4.4.2 ConverGate-D - Paketbehandlung und 3.4.4.3 ConverGate-D - Statische Konfiguration.
3.2.1.3 WinEASY
Infineon stellt eine Software zur Verfügung, welche es ermöglicht, von einem Microsoft Windows PC Nachrichten an das ConverGate-D Evaluation Board zu schicken, Antworten zu erhalten und somit die Hardware komplett zu konfigurieren. Diese Software heißt WinEASY. WinEASY stellt hierzu eine einfache Skriptsprache bereit, mit der man sog. Trackfiles erzeugen kann. Diese Trackfiles bestehen aus einfachen Anweisungen (z.B. if-then-else-Abfragen) und vordefinierten Nachrichten. Die Nachrichten sind in sog. Messagefiles definiert und können in das Trackfile kopiert werden. Ein Messagefile ist ein einfacher Katalog aller vom Treiber unter- stützten Nachrichten. Trackfile wie auch Messagefiles sind Dateien im XML10-Format und sind daher für eine Darstel- lung in diesem Dokument ungeeignet. Außerdem sollten diese Dateien immer in WinEASY be- arbeitet werden. Die vordefinierten Nachrichten lassen sich in drei Kategorien einteilen: Befehle (Commands), Antworten (Indications) und Anfragen (Requests = Commands + Indications). Jede Nachricht hat eine eindeutige 16-Bit ID11 und besteht aus vordefinierten Feldern, welche später mit an- wendungsspezifischen Werten im Trackfile gefüllt werden können. In einem Arbeitsfenster (Edit Window) werden Nachrichten und Trackfiles bearbeitet. Ein Datei- fenster (File / Message Window) erlaubt Zugriff auf Trackfiles und Messagefiles. Zudem existiert ein Logfenster (Log Window), in dem gesendete Befehle und Antworten des ConverGate-D an- gezeigt werden. Siehe Abbildung 3.7 WinEASY - Programmfenster. Man kann einzelne Nachrichten senden oder auch komplette Trackfiles ausführen bzw. abar- beiten lassen. WinEASY basiert auf dem Client-Server-Prinzip, siehe Abbildung 3.13 WinEASY - Nachrichtenübertragung.
10Extensible Markup Language 11Identification Number, Identifikationsnummer
Kapitel 3 Hauptteil 3.2 Vorhandene Software / Werkzeuge - 17 - Fachhochschule Hof
Abb. 3.7: WinEASY - Programmfenster
3.2 Vorhandene Software / Werkzeuge Kapitel 3 Hauptteil Diplomarbeit - 18 -
3.2.1.4 WinEASY Erweiterungen
Um die komplette Konfiguration des ConverGate-D für die MAMS-Anwendung erstellen zu kön- nen, war es nötig, zusätzliche Nachrichten zu definieren. Es wurden insgesamt vier neue Nach- richten zu dem bestehenden Nachrichtenkatalog hinzugefügt, welche in zwei Kategorien einge- teilt werden können: Abb. 3.8: WinEASY - Neue Nachrichten
Kapitel 3 Hauptteil 3.2 Vorhandene Software / Werkzeuge - 19 - Fachhochschule Hof
1. Speichern der gesendeten Nachrichten Um die Konfiguration permanent speichern und beliebig oft laden zu können, wurden Anfragen (Requests) definiert, welche den Start und das Ende von zu schreibenden Daten signalisieren: a) LIB_WE_CGD_OpenFile Diese Nachricht hat die ID 0xe000 (57344) und signalisiert den Start der Daten, welche mitgeschrieben werden sollen.
Abb. 3.9: WinEASY - LIB_WE_CGD_OpenFile
b) LIB_WE_CGD_CloseFile Diese Nachricht hat die ID 0xe001 (57345) und signalisiert das Ende der Daten, die geschrieben werden sollen.
Abb. 3.10: WinEASY - LIB_WE_CGD_CloseFile
Diese beiden Nachrichten selbst werden nicht mitgeschrieben und wurden in der Datei lib_we_cgd.wms definiert. Für die Erweiterung auf dem MPC-Modul siehe 3.2.4.4 ConverGate-D Treiber: lib_we_cgd v0.0.2 und den binären Dateizugriff 3.4.5 Binärer Dateizugriff (BCFA). 2. Schreiben von Werten beliebiger Größe Entscheidend für die Konfiguration des ConverGate-D ist die Möglichkeit Daten mit den Größen 16-Bit (UDP-Portnummer) und 32-Bit (IP-Adresse) in den Vergleichsspeicher des ConverGate-D schreiben zu können. Hierzu wurden folgende Befehle definiert: a) CG_UC_FWD_FIB_VALUE_Assign Diese Nachricht hat die ID 0x1072 (4210) und schreibt einen Wert an gegebene Po-
3.2 Vorhandene Software / Werkzeuge Kapitel 3 Hauptteil Diplomarbeit - 20 -
sition. Über einen 8-Bit-Parameter kann man die Größe der zu schreibenden Wertes angeben.
Abb. 3.11: WinEASY - CG_UC_FWD_FIB_VALUE_Assign
b) CG_UC_FWD_FIB_VALUE_Query Diese Nachricht hat die ID 0x1073 (4211). Mit Ihr kann man Werte beliebiger Größe auslesen.
Abb. 3.12: WinEASY - CG_UC_FWD_FIB_VALUE_Query
Die Bezeichnung folgt der offiziellen Dokumentation [8], wobei die einzelnen Kürzel fol- gendes Aussagen: ConverGate-D Unicast „Forwarding Module“ „Forwarding Informa- tion Base“ Assignment. Diese Nachrichten wurden nur zu Testzwecken in dem WinEASY Messagefile ConverGate- D_BG_addon.wms definiert, denn diese Befehle werden für den dynamischen Aufbau von Verbindungen benötigt und nicht in der statischen Konfiguration, könnten aber für zukünftige Verwendung interessant sein. Siehe 3.2.4.5 ConverGate-D Treiber: drv_cg v3.2.5 für die Implementierung auf dem MPC- Modul und die zugehörigen Parameter.
Der Zusammenhang der einzelnen Komponenten wird in der nächsten Abbildung dargestellt.
Kapitel 3 Hauptteil 3.2 Vorhandene Software / Werkzeuge - 21 - Fachhochschule Hof
Abb. 3.13: WinEASY - Nachrichtenübertragung
3.2 Vorhandene Software / Werkzeuge Kapitel 3 Hauptteil Diplomarbeit - 22 -
3.2.1.5 Dynamische Konfiguration
Die dynamische Konfiguration wird von der BorderGateway Software vorgenommen. Prinzipiell wird in zwei Schritten jeweils eine Seite einer Verbindung zwischen zwei Teilnehmern aufge- baut. Die Befehle um diese Verbindung zu Verwalten bekommt die BorderGateway Software vom Control-PC, siehe 3.1.1 Control-Blade - Control-PC.
Siehe auch 2.4.4 Abstrakte Darstellung und Begriffe, 3.1.3 ConverGate-D Netzwerkprozessor und 3.4.4.4 ConverGate-D - Dynamische Konfiguration.
3.2.2 Das U-Boot (Universal Boot)
„Das U-Boot“12 ist ein universeller Bootloader13 und dient dazu das System hochzufahren bzw. zu starten. Dieses Programm ist also verantwortlich für den Start des MPC-Moduls und damit des gesamten ConverGate-D Evaluation Board. Daher soll es grundlegend erklärt werden.
Nach dem Start des ConverGate-D Evaluation Board wird Das U-Boot geladen, welches eini- ge Sekunden wartet (siehe Unterunterabschnitt 3.2.2.1) bevor es automatisch ein Betriebssystem startet, welches dann wiederum Treiber, Dateisystem usw. auf dem MPC-Modul bereitstellt. Das U-Boot kann nur über die serielle Schnittstelle via Kommandozeile konfiguriert werden, siehe 3.1.2 ConverGate-D Evaluation Board: Modell easy4271 für Informationen über die Hardware und E.3 Serielle Verbindungen für die eingesetzte Software.
3.2.2.1 Konfiguration
Hier sollen kurz die wichtigsten Einstellungen bzw. Das U-Boot-Befehle zur Konfiguration des Bootloaders erläutert werden.
Hier beispielhaft die wichtigsten Befehle:
1. printenv Dieser Befehl füllt den Bildschirm mit den Umgebungsvariablen und deren Werten. 2. setenv
12Das U-Boot: Der Name der Software besteht tatsächlich aus „Das“ und „U-Boot“. Siehe http://www.denx.de/ wiki/UBoot. 13Programm um Computerhardware zu booten bzw. einzurichten
Kapitel 3 Hauptteil 3.2 Vorhandene Software / Werkzeuge - 23 - Fachhochschule Hof
Die Befehle können auch in beliebig kürzeren Versionen geschrieben werden, z.B. hat pri den selben Effekt wie printenv. Die Einstellungen werden in Umgebungsvariablen gespeichert die alle dieses Layout haben:
3.2.2.2 Flash Bootvorgang
Um ein das ConverGate-D Evaluation Board komplett vom MPC-Modul zu starten, muss sich ein JFFS2-Image in dem Flash-Speicher befinden und der Befehl run flash_self ausgeführt wer- den. Dies wird automatisiert, indem man die Variable bootcmd füllt: setenv bootcmd ‘run flash_self’.
14Substitution, Ersetzung 15Trivial File Transfer Protocol 16Network File System 17Intranet: http://trinity.muc.infineon.com/cgi-bin/moin.cgi
3.2 Vorhandene Software / Werkzeuge Kapitel 3 Hauptteil Diplomarbeit - 24 -
Alternativ könnte man auch bei jedem Bootvorgang ein neues Dateisystem übertragen. Der Be- fehl würde dann wie folgt aussehen: ‘run load_jf flash_self’.
3.2.2.3 NFS Bootvorgang
Um ein NFS zu nutzen, kann via run flash_nfs gestartet werden. Der Unterschied zu dem Boot- vorgang via flash_self liegt im Zugriff auf das Dateisystem, welches bei flash_self aus dem Flash- Speicher geladen (JFFS2) und bei NFS über das Netzwerk eingebunden wird.
Siehe E.7 NFS für die Einrichtung eines NFS-Servers und 3.2.3 Buildroot: Cross-Compile-Umgebung für eine nähere Erläuterung des NFS.
3.2.3 Buildroot: Cross-Compile-Umgebung
Die Buildroot ist eine Open-Source18 Cross-Compile-Umgebung19 für Linux und wurde speziell für die Entwicklung von Software für Embedded Systems entwickelt. Ein solches Embedded System ist z.B. auch das ConverGate-D Evaluation Board mit MPC-Modul.
Resultat eines Übersetzungsvorgangs (via make) ist ein Dateisystem in einem Zielverzeichnis, welches sich dann in eine JFFS2-Datei umwandeln lässt und in einen Flash-Speicher geladen werden kann. Diese Umwandlung geschieht automatisch beim Übersetzungsvorgang. Für einen schnelleren Entwicklungsprozess kann auch via NFS direkt auf das Zielverzeichnis zugegrif- fen werden. Man hat dadurch nicht nur einen großen Geschwindigkeitsvorteil sondern schont zusätzlich noch den Flash-Speicher, der bekanntlich nicht unendlich oft beschrieben werden kann.
Für weitere Informationen siehe auch F.5 Buildroot Daten und 3.2.2.3 NFS Bootvorgang.
3.2.3.1 Infineon Buildroot Extension (IBE)
Bei der IBE20 handelt es sich um eine Erweiterung der Buildroot für Infineon-Hardware, wie z.B. das ConverGate-D Evaluation Board easy4271. Hierzu wurden eine Vielzahl von neuen Übersetzungszielen (Targets) definiert und mit in die Umgebung integriert.
Ab hier wird nun als Wurzelverzeichnis (root) für alle relativen Verzeichnisangaben (Verzeich- nisnamen, die nicht mit / beginnen) das Verzeichnis ˜/projects/buildroot/ angenommen. ˜ steht hierbei für das Home-Verzeichnis des momentanen Benutzers. Sofern also ein Verzeichnis nicht mit / beginnt, befinden wir uns im Verzeichnis ˜/projects/buildroot/.
Außerdem wird ab jetzt anstatt Übersetzungsvorschrift der Begriff Makefile verwendet sowie das Linux-Programm make, welches das Makefile verarbeitet, als gegeben vorausgesetzt.
18Kostenlose Software mit Quellcode unter einer bestimmten Lizenz 19Umgebung zur Übersetzung von Software auf einem Rechner für einen anderen Rechner auch mit unterschiedlicher Hardware-Architektur 20Infineon Buildroot Extension
Kapitel 3 Hauptteil 3.2 Vorhandene Software / Werkzeuge - 25 - Fachhochschule Hof
3.2.3.2 Rational ClearCase
Voraussetzung für den Zugriff auf Software bei Infineon ist das Versionsverwaltungswerkzeug Rational ClearCase. Der Autor setzt für Abschnitte, welche sich auf ClearCase beziehen, Grund- wissen über dieses Tool voraus, denn eine Einführung oder verständliche Erklärung dieses Werk- zeugs mitsamt Framework ist äußerst aufwendig und würde den Gesamtfluss dieser Arbeit stö- ren.
In den Abschnitten 3.2.3.3 und 3.2.3.4 wird daher vom Autor eine alternative Vorgehensweise für die Leser gegeben, die sich nicht mit ClearCase beschäftigen können oder wollen. Die folgen- den Schritte sind auch in Windows mit Anwendungen von Rational mit grafischer Oberfläche möglich.
Um diese Abschnitte komplett zu überspringen bitte hier weiterlesen 3.2.3.5 Übersetzen des ConverGate-D-Quellcode.
3.2.3.3 Installation der IBE
Alternativ kann dieser Schritt vollkommen übersprungen werden, siehe 3.2.3.4 Installation des ConverGate-D-Quellcode. Zu Beginn der Softwareinstallation muss die IBE installiert werden. Hierzu wird über die Linux- Kommandozeile via ClearCase der Zugriff auf den sog. IBE-Integrations-Datenstrom (Stream) mit folgendem Befehl hergestellt: ccJoinSubProject buildroot_int Als Nächstes muss man die momentane Kommandozeilenumgebung durch folgenden Befehl erweitern (anstatt ’ct setview’ kann das alias ’ctsv’ verwendet werden): ct setview
3.2.3.4 Installation des ConverGate-D-Quellcode
Nun muss der Quellcode für die ConverGate-D Evaluation Board-Hardware installiert werden. Wie im vorherigen Abschnitt wird auch hier über ClearCase der ConverGate-D-Quellcode hinzu- gefügt. Für den BorderGateway wurde ein aktueller, stabiler Stream gewählt: ccRecreateStre- amView
3.2 Vorhandene Software / Werkzeuge Kapitel 3 Hauptteil Diplomarbeit - 26 -
3.2.3.5 Ubersetzen¨ des ConverGate-D-Quellcode
Zum Übersetzen des Quellcodes und Erstellen des JFFS2-Images muss in das Verzeichnis ˜/pro- jects/buildroot/ gewechselt werden. Dort konfiguriert man das IBE-Ziel config.24/easy4271, indem man change_configuration.sh ausführt (dies ist nur einmal nötig, nicht vor jedem Über- setzungsvorgang). Zu guter Letzt führt man make aus.
In dem Verzeichnis ˜/projects/buildroot/ befinden sich jetzt zwei Dateien mit dem Na- men easy4271.jffs2 und vmlinux.pkg. Diese Dateien können nun in den Flash-Speicher des ConverGate-D übertragen werden. Das Linux Kernel vmlinux.pkg muss prinzipiell nur für Upda- tes oder auf neuen MPC-Modulen installiert werden.
Komfortabler ist es ein NFS einzurichten, siehe 3.2.2.3 NFS Bootvorgang und E.7 NFS.
3.2.3.6 IBE Erweiterungen fur¨ die BorderGateway Software
Nachdem der erste Übersetzungsvorgang erfolgreich beendet wurde, kann begonnen werden, das BorderGateway Target zur IBE hinzuzufügen. Das aktuelle Verzeichnis ist ˜/projects/- buildroot/. Hier die einzelnen Erweiterungen:
1. Makefile
Listing 3.1: IBE Makefile
1 TFTP_DIR=~/projects/tftp
3 a l l : world 4 @echo " ∗ Copying f i l e s to t f t p dir : $(TFTP_DIR) "
Diese Erweiterung kopiert die automatisch generierten Image-Dateien in das TFTP-Server- Verzeichnis. 2. Infineon/package/easy4271.target Um die BorderGateway Software zu übersetzen, muss folgende Zeile hinzugefügt werden:
Listing 3.2: IBE easy427.target
1 TARGETS+=bordergateway
3. Infineon/package/bordergateway.mk Diese Datei muss zuerst neu erstellt werden. Hierzu wurde die Datei buildroot/Infi- neon/package/drv_cg_eb.mk in bordergateway.mk kopiert. Anschließend wurden folgende Änderungen vorgenommen 21: - Ändern aller Einträge mit DRV_CGC_EB* nach BORDERGATEWAY* und drv_cg_eb* nach bordergateway* (auf Groß-/Kleinschreibung achten!) - Einstellen der Versionsnummer BORDERGATEWAY_VERSION - Kommentieren der Zeilen BORDERGATEWAY_APPL sowie BORDERGATEWAY_TARGET_APPL mit #
21* steht für beliebig folgende Zeichen
Kapitel 3 Hauptteil 3.2 Vorhandene Software / Werkzeuge - 27 - Fachhochschule Hof
4. Der BorderGateway-Verzeichnisbaum muss erstellt werden. Wichtig hierbei sind das Ver- zeichnis mit der Versionsnummer von Punkt 3 dieser Liste, z.B. build_powerpc/bordergateway-0.0, und ein Softlink auf dieses Verzeichnis mit dem Namen build_powerpc/bordergateway. Der Autor hat danach das Verzeichnis build_powerpc/drv_cg_eb nach build_powerpc/bordergateway/ kopiert, um alle Konfigu- rationsdateien zu übernehmen. 5. Der Inhalt des Verzeichnisses build_powerpc/bordergateway/src kann komplett gelöscht werden. Allerdings benötigt IBE die Datei build_powerpc/bordergateway/src/Makefile.am, siehe F.10 BorderGateway: Makefile.am. Bevor nun endlich mit der Arbeit an dem BorderGateway Quellcode begonnen werden kann, sollte noch ein kurzer Blick auf die Bootskripts geworfen werden. Diese befinden sich in dem Ver- zeichnis Infineon/package/project_skeleton/easy4271/opt/ifx/scripts/. Der Autor hat dort eine Skriptdatei unter dem Namen S20_start_bordergateway.sh hinzugefügt, mit folgendem Inhalt:
Listing 3.3: BorderGateway Startskript
1 echo " −− deleting WinEASY startup s c r i p t to prevent WinEASY support −−" 2 rm −f /opt/ifx/scripts/S20_start_we_app.sh 3 echo " −− executing bordergateway app −−" 4 /opt/ifx/bordergateway −d −t −q
Alle Dateien aus dem Skriptverzeichnis werden bei jedem Übersetzungsvorgang erneut in das Zielverzeichnis für das Dateisystem kopiert, nach ˜/projects/buildroot/build_powerpc/fs.24/easy4271/. Zum Übersetzen der BorderGateway Software siehe 3.2.3.5 Übersetzen des ConverGate-D- Quellcode.
3.2.4 Embedded Linux
Dieser Abschnitt beschreibt kurz das Embedded Linux und Quellcodeänderungen an Teilen des Betriebssystems und ConverGate-D Treibern22.
3.2.4.1 Embedded Linux: Verzeichnisbaum
Der Verzeichnisbaum des Embedded Linux entspricht jedem anderen Linux Betriebssystem. Die zusätzliche Infineon spezifische Software befindet sich in dem Verzeichnis /opt/ifx/. An dieser Stelle sei noch einmal auf den Unterschied zwischen dem Linux-Entwicklungs- Betriebssystem, dem generierten Embedded-Linux-Betriebssystem und deren Verzeichnisbäu- me hingewiesen. Siehe Tabelle 3.2 Linux Verzeichnisbaumvergleich. Der Verzeichnisbaum für das Embedded Linux wird in ˜/projects/buildroot/build_powerpc/fs.24/easy4271/ generiert.
22Änderungen im Quellcode wurden immer mit den Initialen des Autors SW gekennzeichnet.
3.2 Vorhandene Software / Werkzeuge Kapitel 3 Hauptteil Diplomarbeit - 28 -
Tab. 3.2: Linux Verzeichnisbaumvergleich Entwicklungs Linux Embedded Linux build_powerpc/fs.24/easy4271/ / build_powerpc/fs.24/easy4271/opt/ifx/ /opt/ifx/
3.2.4.2 Embedded Linux: if arp.h
Um einen kompletten ARP23-Header zu erhalten, wurde in der Datei build_powerpc/linux/include/linux/if_arp.h in der Struktur arphdr das #if 0 ... #endif Kon- strukt kommentiert. Die gleiche Änderung wurde auch auf dem Linux-Entwicklungs-Betriebssystem vorgenommen, in der Datei /usr/include/linux/if_arp.h.
3.2.4.3 uClibc
Diese Bibliothek ist ein für Embedded-Linux-Systeme entwickelter Ersatz zur Standard-Linux-C- Bibliothek glibc. uClibc steht hierbei für Mikrocontroller-C-Bibliothek. Vorteile im Gegensatz zu glibc sind die viel geringere Größe der Bibliothek und ein modularer Aufbau, der es sehr einfach macht Funktionen je nach vorhandenem Speicherplatz einzubinden oder wegzulassen. Da die BorderGateway Software Aufgaben parallel verarbeiten wird, müssen sog. Semaphoren zum Schutz vor gleichzeitigem oder ungeordnetem Zugriff auf Ressourcen eingesetzt werden. Semaphoren können gesperrt und wieder geöffnet werden. Nur ein Thread kann jeweils eine Semaphore sperren, alle anderen müssen warten bis dieser Thread die Semaphore wieder frei gibt. [3] Ab Linux Kernel v2.4.22 gibt es Operationen mit Semaphoren, die zeitlich begrenzt werden können. So kann z.B. die Wartezeit auf die Freigabe einer Semaphore nach 1s abgebro- chen werden. [3] In der vorhandenen Version aus der IBE war diese Funktion leider nicht eingebaut (C- Funktion semtimedop()). Daher wurde die uClibc Bibliothek mit einem Patch24 um diese Funk- tion erweitert. Siehe F.6 uClibc: semtimedop Patch.
3.2.4.4 ConverGate-D Treiber: lib we cgd v0.0.2
Um den ConverGate-D via WinEASY (siehe 3.2.1.3 WinEASY) konfigurieren zu können, muss auf dem MPC-Modul eine Client/Server Anwendung laufen, welche Nachrichten empfängt und auch beantworten kann. Die Anwendung heißt /opt/ifx/cg_connectix und nutzt die Bibliothek lib_we_cgd. Diese Bi- bliothek wurde geändert, um eingehende Nachrichten in einer binären Datei speichern zu kön- nen. 23Address Resolution Protocol 24Datei, die Informationen zum automatisierten Verändern von Zieldateien enthält
Kapitel 3 Hauptteil 3.2 Vorhandene Software / Werkzeuge - 29 - Fachhochschule Hof
1. buildroot/build_powerpc/lib_we_cgd/src/Makefile.am Der INCLUDES= Anweisung wurde an erster Stelle das Include-Verzeichnis der BorderGa- teway Software hinzugefügt: Listing 3.4: lib_we_cgd Makefile.am: INCLUDE
1 INCLUDES=\ 2 −I@srcdir@/../../bordergateway/src/include \ 3 −I@DRIVER_CG_PATH@/ src \ 4 −I@DRIVER_CG_PATH@/ src / api \
Als zweite Änderung wurde die Variable nodist_lib_we_cgd_a_SOURCES um zwei Quell- dateien der BorderGateway Software erweitert: Listing 3.5: lib_we_cgd Makefile.am: SOURCES
1 nodist_lib_we_cgd_a_SOURCES = \ 2 @DRIVER_CG_PATH@/ src / api / cg_swaplib . c \ 3 @DRIVER_CG_PATH@/ src / api /cg_addon_swaplib . c \ 4 @srcdir@/../../bordergateway/src/bordergateway_linux.c \ 5 @srcdir@/../../bordergateway/src/bcfa.c
2. buildroot/build_powerpc/lib_we_cgd/src/lib_we_cgd.h In der Header-Datei wurden nur die beiden zusätzlichen WinEASY Nachrichten definiert: Listing 3.6: lib_we_cgd.h
1 #define LIB_WE_CGD_CFG_OPENFILE 0xe000 /∗ 57344 ∗/ 2 #define LIB_WE_CGD_CFG_CLOSEFILE 0xe001 /∗ 57345 ∗/
3. buildroot/build_powerpc/lib_we_cgd/src/lib_we_cgd.c Zu guter Letzt wurde die Quelldatei um Code ergänzt, der die eingehenden Nachrichten in eine binäre Datei schreibt. Zuerst die zwei zusätzlichen Include-Dateien: Listing 3.7: lib_we_cgd.c: Includes
1 /∗ ======∗/ 2 /∗ I n c l u d e s ∗/ 3 /∗ ======∗/ 4 #include " bordergateway_os . h " 5 #include " bcfa . h "
In die Funktion tCg_Ctrl() wurden die Abfragen für die zwei neuen WinEASY-Nachrichten eingebaut, und zwar zwischen diesen beiden Codezeilen: Listing 3.8: lib_we_cgd.c: tCg_Ctrl() #1
1 switch(pMsg−>Header . MessageType) 2 {
Listing 3.9: lib_we_cgd.c: tCg_Ctrl() #2
1 case CG_REGISTERWRITE:
In die Funktion OnCgApi() wurde schließlich der eigentliche Zugriff auf die binäre Konfi- gurationsdatei eingebracht, bei dem jede Nachricht von WinEASY an den ConverGate-D- Treiber mitgeschrieben wird: Listing 3.10: lib_we_cgd.c: OnCgApi()
1 CG_SwapIn ( transfer.header.ioctlId , 2 transfer.buf,pMsg−>pData , pMsg−>Header.Size ); 3 i f ( BCFA_FileAccess (BCFA_GET_STATE , NULL, 0) == IFX_SUCCESS) 4 BCFA_FileAccess(BCFA_WRITE, &transfer, sizeof(transfer));
Siehe auch 3.2.1.4 WinEASY Erweiterungen, bzw. 3.4.5 Binärer Dateizugriff (BCFA), sowie Problembe- schreibung in C.4 ConverGate-D Treiber: cg_connectix.
3.2 Vorhandene Software / Werkzeuge Kapitel 3 Hauptteil Diplomarbeit - 30 -
3.2.4.5 ConverGate-D Treiber: drv cg v3.2.5
Die meisten Änderungen wurden am ConverGate-D-Treiber vorgenommen, im Verzeich- nis ˜/projects/buildroot/build_powerpc/drv_cg/src/. Die Änderung hier ist die Erwei- terung der ConverGate-D-API um die Befehle CG_UC_FWD_FIB_VALUE_Assign() und CG_UC_FWD_FIB_VALUE_Query(). Siehe 3.2.1.4 WinEASY Erweiterungen und C.3 ConverGate-D Li- nux Kernel Treiber Erweiterungen.
1. drv_cg_api.h Der Versions-String DRV_CG_VER_STR war von vorneherein kryptisch und aussagelos. Als die ersten Änderungen in den Treiber eingeflossen sind, hat der Autor entschieden, diesen String zu ändern:
Listing 3.11: drv_cg_api.h
1 #define DRV_CG_VER_STR " BorderGateway " __DATE__ " " __TIME__
2. ioctl/ioctl_api_processing_msg.h Die nächste Änderung definiert zwei neue Nachrichtennummern (IOCTL25-Nummer) für die Kommunikation zw. Treiber und BorderGateway Software sowie die zugehörigen Kommando- bzw. Antwort-Datenstrukturen:
Listing 3.12: ioctl_api_processing_msg.h
1 #define CG_UC_FWD_FIB_VALUE_ASSIGN 0x1072 2 typedef struct 3 { 4 CG_uint8_t CRLT_index; 5 CG_uint16_t index; 6 CG_uint8_t value_size; 7 CG_uint32_t value; 8 } __PACKED__ CMD_CG_UC_FWD_FIB_VALUE_Assign_t; 9 #define CG_UC_FWD_FIB_VALUE_QUERY 0x1073 10 typedef s t r u c t 11 { 12 CG_uint8_t CRLT_index; 13 CG_uint16_t index ; 14 CG_uint8_t value_size; 15 } __PACKED__ CMD_CG_UC_FWD_FIB_VALUE_Query_t; 16 typedef s t r u c t 17 { 18 CG_uint32_t value ; 19 } __PACKED__ IND_CG_UC_FWD_FIB_VALUE_Query_t;
3. ioctl/ioctl_api_processing_msg.c Nun muss in CG_IOCTL_API_Processing_Entry() die IOCTL-Nummer der neuen Nach- richten abgefragt und an den Treiber weitergeleitet werden. Dies geschieht über zwei case-Abfragen vor folgendem Code:
Listing 3.13: ioctl_api_processing_msg.c: CG_IOCTL_API_Processing_Entry()
1 default : 2 returnCode = CG_ERROR_FUNCTION_NOT_IMPL; 3 break ;
4. api/api_processing.h Hier werden die beiden neuen Treiberfunktionen deklariert:
Listing 3.14: api_processing.h
1 extern CG_error_t CG_UC_FWD_FIB_VALUE_Assign ( CG_IN CG_devCtx_t ∗ devCtx , 2 CG_INCG_uint8_tCRLT_index, 3 CG_INCG_uint16_tindex,
25Input/Output Control
Kapitel 3 Hauptteil 3.2 Vorhandene Software / Werkzeuge - 31 - Fachhochschule Hof
4 CG_INCG_uint8_tvalue_size, 5 constCG_INIFX_void_t ∗ value ) ; 6 extern CG_error_t CG_UC_FWD_FIB_VALUE_Query ( CG_IN CG_devCtx_t ∗ devCtx , 7 CG_INCG_uint8_tCRLT_index, 8 CG_INCG_uint16_tindex, 9 CG_INCG_uint8_tvalue_size, 10 CG_OUT IFX_void_t ∗ value ) ;
5. api/api_processing.c Hier werden die beiden Treiberfunktionen implementiert. Die Implementierung ist der der anderen C-Funktion in dieser Datei sehr ähnlich und unterscheidet sich nur durch die Behandlung der Variablen value und value_size. 6. api/api_packet_handler.c In der Funktion CG_PH_IRQ_Service() wurde ein Kommentar aufgehoben, um Informa- tionen über den LAN26-Port (IPNI27) von eingehenden Paketen zu erhalten:
Listing 3.15: api_packet_handler.c: CG_PH_IRQ_Service()
1 /∗ PN o f DES header ∗/ 2 recvPkt.IPNI = segData[CG_DES_IPNI_OFFSET];
7. api/cg_swaplib.c Um eingehende Nachrichten auf das Endian-Format (siehe F.2 Bytereihenfolge (byte order)) des MPC-Prozessors umzuwandeln, wurde die Routine CG_SwapIn() um die neuen Nach- richten erweitert, und zwar nach folgender Zeile:
Listing 3.16: cg_swaplib.c: CG_SwapIn()
1 return sizeof(CMD_CG_IP_HitBitDownRead_t);
26Local Area Network 27Ingress Port Number Information
3.2 Vorhandene Software / Werkzeuge Kapitel 3 Hauptteil Diplomarbeit - 32 -
3.3 BorderGateway Software: Struktur
Zunächst sollen einige allgemeine Festlegungen über Struktur und Eigenschaften der Softwa- re getroffen werden: 1. Die Software wird auf der Kommandozeile ausgeführt und via einzelnen Tastatureingaben zu Debugzwecken bedient werden, siehe 3.6.2 Systemtests. 2. Die Programmiersprache wird ANSI C sein . Diese Einschränkung soll generell dafür sor- gen, dass die Software oder Teile der Software problemlos auf jeder Plattform zu überset- zen sind. Gegen C++ sprachen der höhere Speicherverbrauch, schlechtere Performance und auch mehr Programmcode im Vergleich zu C. 3. Es sollen nicht die Standarddatentypen verwendet werden, sondern in einer zentralen Header-Datei neue Typen definiert werden, um schnelles Ändern der Datentypen über den gesamten Quellcode hinweg zu ermöglichen. Außerdem können eigene Datentypen eine einheitlichere und eindeutigere Bezeichnung erhalten, z.B. uint16_t anstatt unsigned short. 4. Die Software sollte in der offiziellen IBE entwickelt werden. Siehe 3.2.3.6 BorderGateway Er- weiterungen. 5. Funktionen müssen generell thread safe (reentrant) 28 sein, um fehlerfrei beliebig viele Threads starten zu können. Funktionalität und Eigenschaften der BorderGateway Software können grob in wenige Teilbe- reiche aufgegliedert werden: 1. Allgemeine Themen. 2. Fehlerbehandlung. 3. Schnittstelle zwischen Control-PC und MPC-Modul. 4. Schnittstelle zwischen MPC-Modul und ConverGate-D Evaluation Board bzw. ConverGate- D. 5. Binärer Dateizugriff. 6. Behandlung von Netzwerk Protokollen wie z.B. ARP. Die Spezifikation sowie die Implementierung wird in die o.g. Bereiche gegliedert. Um einen Überblick über die wichtigsten Funktionselemente zu geben, soll die folgende Abbildung dienen:
28fehlerfreie, mehrfache, parallele Ausführung eines Programmteiles
Kapitel 3 Hauptteil 3.3 BorderGateway Software: Struktur - 33 - Fachhochschule Hof
Abb. 3.14: BorderGateway Software - Struktur
3.3 BorderGateway Software: Struktur Kapitel 3 Hauptteil Diplomarbeit - 34 -
3.4 BorderGateway Software: Spezifikation
Dieser Abschnitt wird den eigentlichen Kern der Arbeit einleiten, nämlich die Spezifikation 29 der BorderGateway Software und ihrer Funktionalität.
Hier werden keine konkreten Funktionsprototypen30 spezifiziert, sondern die einzelnen, von Alcatel-Lucent verlangten Eigenschaften der BorderGateway Software sowie dafür benötigte Funktionen, Voraussetzungen und Bedingungen beschrieben. Zudem werden dazu (wo mög- lich) Eingabedaten bzw. -werte sowie ein erwartetes Ergebnis angegeben, um Funktionstests für jede Funktionalität durchführen zu können und die Grundfunktionalität genau festzulegen.
Für die Implementierung siehe 3.5 BorderGateway Software: Implementierung.
3.4.1 Allgemeines
3.4.1.1 Rahmenbedingungen (Alcatel-Lucent)
Für die BorderGateway Software wurden einige Rahmenbedingungen bzw. Anforderungen von Alcatel-Lucent vorgegeben [1], die an dieser Stelle aufgeführt werden:
1. Es wird für das ganze System eine maximale Anzahl von zwei Teilnehmern pro Verbindung und Kontext festgelegt (bidirektional, keine Konferenzschaltungen). 2. Die BorderGateway Software verwaltet die Kontext-, UDP- sowie Terminierungsdaten der Verbindungen in Listen. 3. Für jeden Kontext wird vom MPC-Modul eine eindeutige ID vergeben (x > 1): Context ID. 4. Für jede Terminierung wird vom MPC-Modul eine eindeutige ID vergeben (x > 1) : Ter- mination ID. 5. Die Steuerung erfolgt über eine Schnittstelle zwischen Control-PC und BorderGate- way Software, siehe 3.4.3 Control-PC Schnittstelle. 6. Es wird IP v4 verwendet (z.B. 192.168.152.18). 7. SIP-Nachrichten werden verpackt (encapsulated) und entpackt (decapsulated), siehe 3.4.6.7 SIP - Session Initiation Protocol. 8. Lokale UDP-Portnummer für RTP ist gerade, für RTCP ungerade.
9. Unterstützte Netzwerkprotokolle: ARP, UDP, IP, ICMP31, SIP, siehe 3.4.6 Netzwerkpakete.
29Beschreibung, Planung, Festlegung 30Prototyp: float sin(float x); 31Internet Control Message Protocol
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 35 - Fachhochschule Hof
3.4.1.2 Rahmenbedingungen (ConverGate-D)
Abgesehen von den Rahmenbedingungen von Alcatel-Lucent, muss sich die Software auch den Gegebenheiten der umgebenden Hardware und Software unterordnen. Aufgrund der maximal 2048 Einträge im Vergleichsspeicher des ConverGate-D ergeben sich folgende Einschränkun- gen:
1. Maximal 512 Teilnehmer (Termination IDs) auf jeder Seite des BorderGateway, insgesamt also 1024, denn pro Teilnehmer wird jeweils eine RTP-ID und eine implizite RTCP-ID zugeteilt. Dies ergibt insgesamt 2048 Einträge:
Siehe auch F.3 ConverGate-D Daten.
3.4.2 Fehlerbehandlung
Ein wichtiger Teil der Software ist die Fehlerbehandlung. Daher wird ihr ein Teil in der Spezifi- kation zugeteilt.
3.4.2.1 Ruckgabewerte,¨ Fehlercodes (Fehlernummern)
Ein Großteil der C-Funktionen wird einen Wert zurückgeben, der Auskunft über den Erfolg bzw. das Ergebnis geben soll. Demnach werden sehr viele verschiedene Rückgabewerte definiert werden. Diese Werte werden als ganze Zahlen 32 definiert. Deswegen werden die Rückgabewerte für eine leichtere Zuordnung in 3 Kategorien unterteilt:
• Fehler Werte < 0 signalisieren einen Fehler. • Erfolg Die Funktion wurde erfolgreich ausgeführt wenn der Wert = 0 ist. • Warnung Werte > 0 signalisieren eine Warnung. Es muss kein Programm- oder Operationsabbruch vorgenommen werden.
32Integer
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 36 -
Alle Rückgabewerte werden als Aufzählungstyp33 definiert. Generell mögliche Rückgabewerte werden während der Spezifikation der einzelnen Module bzw. Funktionen angegeben. Auf An- gabe genauer Fehlerwerte wird in dieser Arbeit verzichtet.
3.4.2.2 Ruckgabestrings¨
Um die Rückgabewerte für den Benutzer verständlich darstellen zu können, soll jedem Rück- gabewert ein Rückgabestring zugeordnet werden, welcher den Wert erklärt. Wichtig hierbei ist eine detaillierte und aussagekräftige Beschreibung der Fehler. Diese Strings sollen in einer Liste gespeichert werden, die es erlaubt, jedem Rückgabewert den richtigen String zuzuordnen.
Funktionsbeschreibung 1 Zuordnen eines Rückgabewertes zu einem beschreibenden String, z.B. zur Ausgabe auf dem Bildschirm oder Weiterleitung an den Control-PC. Eingabe • Ein ganzzahliger Rückgabewert.
Ausgabe • Ein beschreibender String, falls der Rückgabewert zugeordnet werden konnte. • Ein leerer String oder NULL, falls ein unbekannter Wert übergeben wurde.
3.4.3 Control-PC Schnittstelle
Die Schnittstelle zwischen Control-PC und MPC-Modul wurde vom Autor in Zusammenarbeit mit Alcatel-Lucent [1] und Beier Li [9] festgelegt. Genaugenommen handelt es sich bei dieser Schnittstelle um ein Kommunikationsprotokoll.
3.4.3.1 Grundlegende Eigenschaften
Das Protokoll soll folgende Bedingungen erfüllen: • Es handelt sich um ein binäres Protokoll. • Das Protokoll besteht aus vielen einzelnen TLV34-Blöcken, siehe 3.4.3.2 TLV - Type Length Value. • Asynchroner Nachrichtenaustausch: Eine Nachricht B kann eintreffen, auch wenn Nach- richt A noch nicht beantwortet wurde (Threads). • Nachrichten werden über UDP-Pakete verschickt und empfangen. • Das Format für Werte in Nachrichten ist Little Endian, siehe F.2 Bytereihenfolge (byte order). • Nachrichten vom Control-PC werden immer beantwortet. • Das MPC-Modul schickt Nachrichten, auf die keine Antwort gesendet wird.
33Enumerated type: typedef enum {...}
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 37 - Fachhochschule Hof
3.4.3.2 TLV - Type Length Value
Das Protokoll wird sich an dem TLV-Format orientieren. Dieses binäre Format ist leicht zu lesen und zu schreiben, zudem ist es effizient aufgrund seines kompakten, flexiblen Aufbaues. Damit sorgt es für wenig Netzwerkverkehr, da die zu versendenden UDP-Daten (Payload35) relativ klein sind.
Die drei Felder eines TLV-Blocks werden so definiert:
Tab. 3.3: TLV Beispiel Feldname Beschreibung Maximaler Wert Länge in Byte Beispiel Type Bestimmt den Typ von Value 0xff 1 0x04 Length Bestimmt die Länge von Value 0xff 1 0x08 Value Der eigentliche Wert mit Länge 255 Bytes
Der Beispielblock würde so im Speicher stehen : In Hexadezimal: 04 08 54 65 73 74 77 65 72 73. Als String: ..Testwert
Die Bytelänge der Type und Length Felder kann theoretisch auch 2 oder 4 betragen. Dies wurde in der Protokollspezifikation beachtet und beinhaltet die Möglichkeit, andere Längen als 1 für die Felder Type und Length zu benutzen, was zukünftige Protokollerweiterungen ermöglicht, ohne den TLV-Code zu ändern.
Siehe auch z.B. http://en.wikipedia.org/wiki/Type-length-value.
3.4.3.3 TLV-Block schreiben (Kodieren)
Um also eigene Nachrichten generieren zu können, wird eine Funktion benötigt, die einen TLV- Block schreiben kann.
Funktionsbeschreibung 2 Schreiben eines TLV-Blocks. Eingabe • Das Feld Type von Value. • Das Feld Length von Value. • Das Feld Value.
Ausgabe • Erfolg, falls der TLV-Block erfolgreich geschrieben wurde. – Den geschriebenen TLV-Block. • Fehler, falls der Block nicht geschrieben werden konnte.
Hinweis(e) • Value kann größer als der größte Standarddatentyp sein: >4 Bytes.
35Payload: Anhang von Daten an einem Protokoll oder Netzwerkpaket, der in dem jeweiligen Objekt gekapselt ist.
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 38 -
3.4.3.4 TLV-Block lesen (Dekodieren)
Um eingehende Nachrichten zu dekodieren, muss eine Funktion TLV-Blöcke lesen bzw. interpre- tieren können.
Funktionsbeschreibung 3 Lesen eines TLV-Blocks. Eingabe • -
Ausgabe • Erfolg, falls die TLV-Variablen erfolgreich gelesen wurden. – Den Type-Wert. – Den Length-Wert. – Den Value-Wert. • Fehler, falls die Variablen nicht gelesen werden konnten.
Hinweis(e) • Die Maximalgröße für Value muss beachtet werden.
3.4.3.5 TLV-Daten fur¨ die Control-PC Schnittstelle
In Tabelle 3.4 Control-PC ⇔ MPC-Modul TLV-Daten werden die TLV-Daten der Control-PC-MPC- Modul-Schnittstelle definiert. Die einzelnen Type-Werte sind noch einmal logisch in Kategorien unterteilt, z.B. 0x80-0xff für statistische Typen.
Einige dieser Werte werden in der aktuellen BorderGateway Software nicht verwendet und igno- riert. Diese Werte sind für die Anfangs- und Testphasen unnötig und mit * gekennzeichnet. Die Verwendung der einzelnen Werte wird in den Beispielen deutlich, die zu jedem Befehl angege- ben sind, siehe 3.4.3.7.1 ADD_REQ (0x00): Verbindung einrichten.
Typen werden in Hexadezimal angegeben, ohne 0x.
3.4.3.6 Befehle fur¨ die Control-PC Schnittstelle
Der Type „Befehl“ (ID 03, Bytegröße 1) ist der wichtigste Teil jeder Nachricht, denn dessen Value bestimmt, welcher Inhalt in der Nachricht erwartet wird und welche Aktionen ausgeführt werden müssen.
Interessant an den Befehlen ist, dass anhand von Bit 7 (0x80) die Richtung der Nachricht ausge- lesen werden kann. So haben alle Nachrichten vom Control-PC an das MPC-Modul einen Wert >= 0, alle Nachrichten vom MPC-Modul an den Control-PC einen Wert < 0. Dies lässt für jede Richtung 128 Befehle zu.
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 39 - Fachhochschule Hof
Tab. 3.4: Control-PC ⇔ MPC-Modul TLV-Daten Type Beschreibung Länge in Byte Werte Nachrichtenspezifisch, 00-1f, 32 Werte maximal 00 Type-Länge 1 1, 2, 4 01 Length-Länge 1 1, 2, 4 02 Zeitstempel, identifiziert jede Nachricht, wird in Antworten einfach zurück- 4 Tageszeit in ms geschickt 03 Befehl, siehe 3.4.3.6 Befehle für die Control-PC Schnittstelle 1 0-255 04 Rückgabewert, siehe 3.4.2.1 Rückgabewerte, Fehlercodes (Fehlernummern) 2 32767 bis -32767 05 Rückgabestring, siehe 3.4.2.2 Rückgabestrings 0-255 String Halfcallspezifisch, 20-4f, 48 Werte maximal 20 Lokale (local) IP-Adresse, siehe Type 50 und 51 4 IPA 21 Lokaler (local) UDP-Port 2 0-65535 22 Fremde (remote) IP-Adresse 4 IPA 23 Fremder (remote) UDP-Port 2 0-65535 24 Halfcall ID (Termination ID) 2 1-1024 25 Kontext ID (Context ID) 2 1-1024 26* Quality of Service (QoS, DSCP) 1 0-3 27* Bandbreite in 100 kbit/s 2 0-65535 Konfiguration, 50-7f, 48 Werte maximal 50 BorderGateway unsichere (A) Seite 4 IPA 51 BorderGateway sichere (B) Seite 4 IPA 52 B2BUA-IP-Adresse 4 IPA 53 MPC-IP-Adresse 4 IPA 54 MPC-ID (= Type 53) 4 IPA 55 Control-PC IP-Adresse 4 IPA 56 SIP-Tunnel-Adresse 4 IPA Statistiken, 80-ff, 128 Werte maximal 80 RTP: Gesendete Pakete 4 0-232 − 1 81 RTP: Erhaltene Pakete 4 0-232 − 1 82* RTP: Verlorene Pakete 2 (1-10000) * 0.01 in % 83* RTP: Jitter 4 in ms 84* RTP: Verzögerung 4 in ms 85 Verbindungsdauer 4 in s 86 Versendete Bytes 4 0-232 − 1 87 Erhaltene Bytes 4 0-232 − 1
In der folgenden Tabelle werden die spezifizierten Befehlsnummern mit ihren Namen aufgeführt und kurz beschrieben. Zudem enthält die Tabelle die Senderichtung und eine Liste von TLV- Typen, die in der Nachricht vorkommen können oder müssen. Eine detaillierte Beschreibung der Befehle folgt in den kommenden Abschnitten.
Es werden folgende Kürzel und Bezeichnungen verwendet:
+ 1 oder mehr Wiederholungen.
* 0 oder mehr Wiederholungen.
- von-bis.
? Platzhalter: 8? heißt alle Typen von 80-8f.
CB Control-PC.
REQ Request (Anfrage).
REP Reply (Antwort).
(...) ein Block von Typen, die zusammengehören.
[...] ein optionaler Block von Typen, d.h. diese müssen nicht zwingend enthalten sein.
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 40 -
Tab. 3.5: Control-PC ⇔ MPC-Modul Befehle ID Name Beschreibung Absender Parameter 00 ADD_REQ 2 Verbindungen einrichten CB 26 27 (20 22 23)+ 80 ADD_REP Antwort MPC 25 (21 24)+ 04 05 01 SUBTRACT_REQ Verbindungen abbrechen CB 25 [24]* 81 SUBTRACT_REP Antwort MPC 25 (24 8?)* 04 05 02 MODIFY_REQ Verbindungen komplettieren CB 25 24*27 20-23 82 MODIFY_REP Antwort MPC 25 24* 04 05 03 READ_STATUS_REQ Statistiken abrufen CB 25 24 83 READ_STATUS_REP Antwort MPC 25 24 8? 04 05 04 CONFIG_REQ MPC-Modul konfigurieren CB 50-53 55 84 CONFIG_REP Antwort MPC 04 05 85 WAKE_UP Bereitschaft signalisieren MPC 54 86 FAULT Fehler signalisieren MPC 54 04 05
3.4.3.7 Behandlung von Nachrichten
Die Behandlung von eingehenden Nachrichten ist prinzipiell für alle Befehle gleich, nur wird je nach Befehl eine andere Operation eingeleitet. Dies wird in Abbildung 3.15 Befehl an MPC-Modul veranschaulicht. Aufgrund der TLV-Struktur der Nachricht lassen sich alle TLV-Blöcke nacheinander lesen und die Daten in (temporäre) Variablen speichern. Nachdem die Nachricht vollständig und fehlerfrei gelesen worden ist, kann die eigentliche Operation der Nachricht, der Befehl, ausgeführt werden (grünes Feld). Am Ende des Befehlsoperation steht die Generierung einer Antwort. Wenn ein Fehler während des Lesens der Nachricht aufgetreten ist, wird noch auf das Gewicht des Fehlers hin überprüft. Bei „kleineren’"Fehlern, wie z.B. einer ungültigen Kontext-ID, wird der Fehler via einer Standardantwort gemeldet (z.B. MODIFY_REP). Ist beispielsweise ein un- bekannter Befehl aufgetaucht, kann nicht mit einer normalen Antwort (z.B. ADD_REP) reagiert werden, denn der Befehl ist ja unbekannt. In diesem Fall wird eine FAULT-Nachricht generiert. Am Ende folgt immer das Versenden einer Antwort an den Control-PC. Die folgenden Absätze erläutern für jede einzelne Nachricht nur die Befehlsoperation (grünes Feld) und stellen jeweils den Ideal-Ablauf dar. Antworten besitzen kein Aktivitätsdiagramm, denn dort werden keine Aktionen außer das Schreiben der TLV-Blöcke durchgeführt. Ausnah- men bilden dabei FAULT (rotes Feld, 3.4.3.7.12 FAULT (0x86): Fehler signalisieren) und WAKE_UP (komplett unabhängig von eingehenden Nachrichten, 3.4.3.7.11 WAKE_UP (0x85): Bereitschaft si- gnalisieren).
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 41 - Fachhochschule Hof
Abb. 3.15: Befehl an MPC-Modul
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 42 -
3.4.3.7.1 ADD REQ (0x00): Verbindung einrichten Dieser Befehl veranlasst die BorderGateway Software eine Verbindung zwischen zwei Halfcalls so weit wie möglich aufzubauen. Dies beinhaltet das Erstellen des Kontextes und der beiden Terminierungen sowie die Feststellung der Netzwerkdaten für den Teilnehmer A. Abb. 3.16: Befehl - ADD_REQ
ADD_REQ stellt immer nur Informationen für einen Teilnehmer bereit. Die Daten für den zwei- ten Teilnehmer werden mit MODIFY_REQ übermittelt (3.4.3.7.5 MODIFY_REQ (0x02): Einzelne Ver- bindung einrichten). Theoretisch könnten aber auch beide Halfcalls in einer ADD_REQ Nachricht übermittelt und eingerichtet werden. Siehe Hinweise bei Halfcall B im Beispiel. Ob A oder B- Seite des BorderGateway zu dem Halfcall gehören, wird über die lokale IP-Adresse ermittelt.
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 43 - Fachhochschule Hof
Beispiel: TLV-Daten einer ADD REQ-Nachricht HEX PAYLOAD DESCRIPTION ------02 04 0a 00 00 00 Timestamp: 00,010s (0000000Ah) 03 01 00 Command: ADD_REQ
Halfcall A 20 04 32 98 a8 c0 local IP-Addr: 192.168.152.50 22 04 0a 98 a8 c0 remote IP-Addr: 192.168.152.10 23 02 3e 22 remote UDP (RTP) Port: 8766
Halfcall B 20 04 97 04 a8 c0 local IP-Addr: 192.168.152.51 (optionally remote information)
27 02 40 00 Bandwidth: 6400 kbps (64*100 kbps) 26 01 02 QoS: Realtime ’RT’
Siehe Befehlsübersicht Tabelle 3.5 Control-PC ⇔ MPC-Modul Befehle.
3.4.3.7.2 ADD REP (0x80): Antwort auf ADD REQ Als Antwort auf ADD_REQ sendet das MPC-Modul eine ADD_REQ-Nachricht an den Control-PC. Die Nachricht beinhaltet vor allem die neu generierte Context ID, die beiden Termination IDs und die lokalen UDP-Ports. Die UDP-Ports sind die jeweiligen RTP-Ports. Der korrespondierende RTCP-Port ist
Beispiel: TLV-Daten einer ADD REP-Nachricht HEX PAYLOAD DESCRIPTION ------02 04 0a 00 00 00 Timestamp: 00,010s (0000000Ah) 03 01 80 Command: ADD_REP
25 02 c4 00 Context ID: 196
Halfcall A 24 02 4d 01 Termination Id: 333 for RTP (334 RTCP implicit) 21 02 6e 9c local UDP (RTP) Port: 40046
Halfcall B 24 02 4f 01 Termination Id: 335 for RTP (336 RTCP implicit) 21 02 b8 9c local UDP (RTP) Port: 40120
04 02 00 00 Result: Success 05 00 Result string: ""
Siehe Befehlsübersicht Tabelle 3.5 Control-PC ⇔ MPC-Modul Befehle.
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 44 -
3.4.3.7.3 SUBTRACT REQ (0x01): Verbindungen beenden Dieser Befehl beendet Verbindungen und kann in zwei Formen auftreten: 1. Als Parameter wird nur die Context ID übertragen. Dies führt zum Abbau aller Verbindun- gen in diesem Kontext und zur Freigabe des Kontextes selbst. 2. Außer der Context ID werden explizit die Termination IDs angegeben, welche zum Kontext gehören und beendet werden sollen. Bei Beendigung des letzten Halfcall in einem Kontext wird auch der Kontext freigegeben. Abb. 3.17: Befehl - SUBTRACT_REQ
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 45 - Fachhochschule Hof
Beispiel: TLV-Daten einer SUBTRACT REQ-Nachricht HEX PAYLOAD DESCRIPTION (complete context) ------02 04 b4 c3 00 00 Timestamp: 50,100s (0000C3B4h) 03 01 01 Command: SUBTRACT_REQ
25 02 c4 00 Context ID: 196
HEX PAYLOAD DESCRIPTION (single halfcall) ------02 04 b4 c3 00 00 Timestamp: 50,100s (0000C3B4h) 03 01 01 Command: SUBTRACT_REQ
25 02 c4 00 Context ID: 196
24 02 4d 01 Termination Id: 333 for RTP (334 RTCP implicit)
Siehe Befehlsübersicht Tabelle 3.5 Control-PC ⇔ MPC-Modul Befehle.
3.4.3.7.4 SUBTRACT REP (0x81): Antwort auf SUBTRACT REQ Mit diesem Befehl wird ein SUBTRACT_REQ beantwortet. Als Parameter in der Nachricht wird der Kontext sowie die gelöschten Halfcalls mitsamt Statistiken (siehe 3.4.3.7.8 READ_STATUS_REP (0x83): Antwort auf READ_STATUS_REQ) zurückgegeben.
Beispiel: TLV-Daten einer SUBTRACT REP-Nachricht HEX PAYLOAD DESCRIPTION ------02 04 b4 c3 00 00 Timestamp: 50,100s (0000C3B4h) 03 01 81 Command: SUBTRACT_REP
25 02 c4 00 Context ID: 196
Halfcall A 24 02 4d 01 Termination Id: 333 for RTP (334 RTCP implicit) 80 ?? .. Statistics : ...
Halfcall B 24 02 4f 01 Termination Id: 335 for RTP (336 RTCP implicit) 80 ?? .. Statistics: ...
04 02 00 00 Result: Success 05 00 Result string: ""
Siehe Befehlsübersicht Tabelle 3.5 Control-PC ⇔ MPC-Modul Befehle.
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 46 -
3.4.3.7.5 MODIFY REQ (0x02): Einzelne Verbindung einrichten Wenn mit ADD_REQ nur ein Halfcall aufgebaut wird, muss ein zweiter Teilnehmer separat zu dem jeweiligen Kontext hinzugefügt werden. Dies geschieht mit MODIFY_REQ. Hierzu wird die Context ID sowie eine oder mehrere Termination IDs übergeben. Wenn Termination IDs übergeben werden, die bereits verbunden sind und/oder keine Verbindungsdaten enthalten, werden diese ignoriert. Abb. 3.18: Befehl - MODIFY_REQ
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 47 - Fachhochschule Hof
Beispiel: TLV-Daten einer MODIFY REQ-Nachricht HEX PAYLOAD DESCRIPTION ------02 04 78 00 00 00 Timestamp: 00,120s (00000078h) 03 01 02 Command: MODIFY_REQ
25 02 c4 00 Context ID: 196
Halfcall A 24 02 4d 01 Termination Id: 333 for RTP (334 RTCP implicit)
Halfcall B 24 02 4f 01 Termination Id: 335 for RTP (336 RTCP implicit) 22 04 d5 04 a8 c0 remote IP-Addr: 192.168.4.213 23 02 3e 22 remote UDP (RTP) Port: 8766
Siehe Befehlsübersicht Tabelle 3.5 Control-PC ⇔ MPC-Modul Befehle.
3.4.3.7.6 MODIFY REP (0x82): Antwort auf MODIFY REQ Dies ist die Antwort auf ein MODIFY_REQ. Hier wird die Context ID sowie alle in MODIFY_REQ übertragenen Termination IDs zurückgegeben.
Beispiel: TLV-Daten einer MODIFY REP-Nachricht HEX PAYLOAD DESCRIPTION ------02 04 78 00 00 00 Timestamp: 00,120s (00000078h) 03 01 82 Command: MODIFY_REP
25 02 c4 00 Context ID: 196
Halfcall A 24 02 4d 01 Termination Id: 333 for RTP (334 RTCP implicit)
Halfcall B 24 02 4f 01 Termination Id: 335 for RTP (336 RTCP implicit)
04 02 00 00 Result: Success 05 00 Result string: ""
Siehe Befehlsübersicht Tabelle 3.5 Control-PC ⇔ MPC-Modul Befehle.
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 48 -
3.4.3.7.7 READ STATUS REQ (0x03): Statistiken abrufen Dieser Befehl fordert Statistikdaten eines Halfcalls (Terminierung) an. Übergeben wird nur die Context ID sowie die Termination ID. Abb. 3.19: Befehl - READ_STATUS_REQ
Beispiel: TLV-Daten einer READ STATUS REQ-Nachricht HEX PAYLOAD DESCRIPTION ------02 04 D8 28 00 00 Timestamp: 10,456s (000028D8h) 03 01 03 Command: READ_STATUS_REQ
25 02 c4 00 Context ID: 196
Halfcall A 24 02 4d 01 Termination Id: 333 for RTP (334 RTCP implicit)
Siehe Befehlsübersicht Tabelle 3.5 Control-PC ⇔ MPC-Modul Befehle.
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 49 - Fachhochschule Hof
3.4.3.7.8 READ STATUS REP (0x83): Antwort auf READ STATUS REQ READ_STATUS_REP liefert die angeforderten Statistiken zurück (siehe Tabelle 3.4 Control- PC ⇔ MPC-Modul TLV-Daten).
Beispiel: TLV-Daten einer READ STATUS REP-Nachricht
HEX PAYLOAD DESCRIPTION ------02 04 D8 28 00 00 Timestamp: 10,456s (000028D8h) 03 01 83 Command: READ_STATUS_REP
25 02 c4 00 Context ID: 196
Halfcall A 24 02 4d 01 Termination Id: 333 for RTP (334 RTCP implicit)
Statistics 80 04 10 00 00 00 16 RTP packets sent 81 04 15 00 00 00 21 RTP packets received 82 02 00 00 0 % RTP packet loss 83 04 00 00 00 00 0 ms RTP packet jitter 84 04 00 00 00 00 0 ms RTP packet delay 85 04 00 00 00 00 5 s halfcall activity duration 86 04 23 11 00 00 4404 Bytes sent 87 04 09 32 00 00 12809 Bytes received
04 02 00 00 Result: Success 05 00 Result string: ""
Siehe Befehlsübersicht Tabelle 3.5 Control-PC ⇔ MPC-Modul Befehle.
3.4.3.7.9 CONFIG REQ (0x04): MPC-Modul konfigurieren Dieser Befehl wird prinzipiell nur nach einem Neustart des Systems oder des ConverGate-D Eva- luation Board versandt, um die Basisdaten der BorderGateway Software festzulegen. Es werden die IP-Adressen der beiden GbE-Ports, des B2BUA, des SIP-Tunnel, des MPC-Modul sowie des Control-PC mitgeteilt. Abb. 3.20: Befehl - CONFIG_REQ
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 50 -
Beispiel: TLV-Daten einer CONFIG REQ-Nachricht HEX PAYLOAD DESCRIPTION ------02 04 D8 28 00 00 Timestamp: 10,456s (000028D8h) 03 01 04 Command: CONFIG_REQ
50 04 32 98 a8 c0 A IP: 192.168.152.50 51 04 33 98 a8 c0 B IP: 192.168.152.51 52 04 0a 98 a8 c0 SIP Proxy/B2BUA IP: 192.168.152.10 53 04 12 98 a8 c0 MPC IP: 192.168.152.18 55 04 0e 98 a8 c0 CB IP: 192.168.152.14 56 04 0a 98 a8 c0 SIP Tunnel IP: 192.168.152.10
Siehe Befehlsübersicht Tabelle 3.5 Control-PC ⇔ MPC-Modul Befehle.
3.4.3.7.10 CONFIG REP (0x84): Antwort auf CONFIG REP Die Antwort auf CONFIG_REQ bestätigt lediglich die Übernahme der gelieferten Parameter.
Beispiel: TLV-Daten einer CONFIG REP-Nachricht HEX PAYLOAD DESCRIPTION ------02 04 D8 28 00 00 Timestamp: 10,456s (000028D8h) 03 01 84 Command: CONFIG_REP
04 02 00 00 Result: Success 05 00 Result string: ""
Siehe Befehlsübersicht Tabelle 3.5 Control-PC ⇔ MPC-Modul Befehle.
3.4.3.7.11 WAKE UP (0x85): Bereitschaft signalisieren WAKE_UP wird vom MPC-Modul als Bestätigung der Funktionsbereitschaft nach einem Neu- start, Reset o.Ä. an den Control-PC geschickt. Als Parameter wird eine BorderGateway ID über- tragen. Es wurde festgelegt, als ID die MPC-Modul-IP-Adresse zu nutzen, da diese im Kontroll- netzwerk ohnehin einzigartig sein muss. Dieser Befehl erwartet keine Antwort. Abb. 3.21: Befehl - WAKE_UP
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 51 - Fachhochschule Hof
Beispiel: TLV-Daten einer WAKE UP-Nachricht HEX PAYLOAD DESCRIPTION ------02 04 10 00 00 00 Timestamp: 0,016s (00000010h) 03 01 85 Command: WAKE_UP
54 04 12 98 a8 c0 Border Gateway ID: MPC IP address (192.168.152.18)
Siehe Befehlsübersicht Tabelle 3.5 Control-PC ⇔ MPC-Modul Befehle.
3.4.3.7.12 FAULT (0x86): Fehler signalisieren FAULT signalisiert Fehler an den Control-PC, die außerhalb eines Befehl-Antwort-Kontextes auf- tauchen, z.B. wenn eingehende SIP-Nachrichten nicht weitergeleitet werden konnten. Abb. 3.22: Befehl - FAULT
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 52 -
Beispiel: TLV-Daten einer FAULT-Nachricht
HEX PAYLOAD DESCRIPTION ------02 04 D8 28 00 00 Timestamp: 10,456s (000028D8h) 03 01 86 Command: FAULT
54 04 12 98 a8 c0 Border Gateway ID: MPC IP address (192.168.152.18)
04 02 ff ff Fault reason: -1 05 0d ... Result string: "general error"
Siehe Befehlsübersicht Tabelle 3.5 Control-PC ⇔ MPC-Modul Befehle und 3.4.3.8 Fehlerwarteschlange (Fault pipe).
3.4.3.8 Fehlerwarteschlange (Fault pipe)
Für die in 3.4.3.7.12 FAULT (0x86): Fehler signalisieren beschriebene Funktionalität benötigt die BorderGateway Software eine Art Warteschlange, in der Rückgabewerte bis zu ihrer Abarbei- tung stehen. Wie in 3.4.6.2.3 Versenden vieler/paralleler ARP-Requests muss der Zugriff auf diese Warteschlange über Semaphoren geschützt werden. Nur ein Programmteil darf Zugriff auf die Fehlerwarteschlange zur Zeit haben, siehe Semaphoren in 3.2.4.3 uClibc.
Diese Warteschlange wird über zwei Funktionen realisiert, die folgende Typen von Einträgen verarbeiten können müssen:
1. Einen Standardrückgabewert, siehe 3.4.2.1 Rückgabewerte, Fehlercodes (Fehlernummern): Die- ser Wert kann jederzeit in der Liste der Rückgabestrings gefunden werden. 2. Besondere Rückgabewerte, die nicht in der Liste mit Rückgabestrings stehen: Dies sind Fehler, die nur an einer Stelle in der Software auftauchen und daher immer genau zu- zuordnen sind. Zudem können diese Werte nicht über die normalen Control-PC ⇔ MPC- Modul Nachrichten mitgeteilt werden.
Ein Eintrag von Typ 1 benötigt demnach keine weiteren Daten zur Interpretation. Einträge von Typ 2 müssen genau identifizierbar sein und werden gefolgt von dem speziellen Rückgabestring. Prinzipiell genügt hier ein einziger besonderer Rückgabewert.
3.4.3.8.1 In Fehlerwarteschlange (Fault pipe) schreiben
Funktionsbeschreibung 4 Schreiben in die Fehlerwarteschlange. Eingabe • Einen Rückgabewert. • Einen Rückgabestring (optional).
Ausgabe • Erfolg, wenn in die Fehlerwarteschlange geschrieben werden konnte. • Fehler, wenn nicht in die Fehlerwarteschlange geschrieben werden konnte.
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 53 - Fachhochschule Hof
3.4.3.8.2 Aus Fehlerwarteschlange (Fault pipe) lesen
Funktionsbeschreibung 5 Lesen aus der Fehlerwarteschlange. Eingabe • -
Ausgabe • Erfolg, wenn in die Fehlerwarteschlange gelesen werden konnte. – Den Rückgabestring. • Fehler, wenn die Fehlerwarteschlange nicht gelesen werden konnte.
3.4.3.9 Nachrichten via UDP
Die Nachrichten der Control-PC-Schnittstelle werden via UDP versendet. Hierfür wird aller- dings keinerlei Information aus 3.4.6 Netzwerkpakete benötigt, denn diese Nachrichten werden durch das Betriebssystem verarbeitet. Der für die Nachrichten der Testanwendung gewählte UDP-Zielport ist 4369 (0x1111).
3.4.3.9.1 Versenden von Nachrichten via UDP Zunächst die Beschreibung der Funktion zum Versenden einer UDP-Nachricht an den Control- PC. Es wird eine Nachricht an nur einen UDP-Port geschickt. Hierbei agiert die BorderGate- way Software als Client.
Funktionsbeschreibung 6 Versenden eines UDP-Paketes via Betriebssystem. Eingabe • Die IP-Zieladresse. • Den UDP-Zielport. • Die zu versendenden Daten. • Die Größe der zu versendenden Daten.
Ausgabe • Erfolg, wenn das Paket gesendet werden konnte. • Fehler, wenn das Paket nicht gesendet werden konnte.
3.4.3.9.2 Erhalten von Nachrichten via UDP Für den Empfang von UDP-Nachrichten vom Control-PC wird folgende Funktion benötigt. Dabei wird auf einem UDP-Port auf eingehende Daten gewartet. Dies entspricht einem Serververhal- ten.
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 54 -
Funktionsbeschreibung 7 Empfangen eines UDP-Paketes via Betriebssystem. Eingabe • Den UDP-Port auf dem auf eingehende Daten gewartet werden sollen. • Die Wartezeit die auf eingehende Daten gewartet werden soll.
Ausgabe • Erfolg, wenn das Paket gesendet werden konnte. – Die empfangenen Daten. – Die Größe der empfangenen Daten. • Fehler, wenn aufgrund eines Fehlers keine Daten empfangen werden konnten. • Warnung, wenn aufgrund abgelaufener Wartezeit keine Daten empfangen wurden.
3.4.4 ConverGate-D Schnittstelle
Die Spezifikation der Schnittstelle zwischen ConverGate-D Hardware und MPC-Modul wurde vom Autor entwickelt. Sie umfasst die statische und dynamische Konfiguration des ConverGate- D, Entnahme und Einsetzen von Netzwerkpaketen sowie Zugriff auf das ConverGate-D Evalua- tion Board. Zugriff auf die Hardware wird über Linux-Kernel-Treiber ermöglicht, welche die übertragenen Daten auf die jeweiligen Komponenten anwenden.
3.4.4.1 ConverGate-D Evaluation Board
Prinzipiell ist für die BorderGateway-Anwendung kein Zugriff auf das ConverGate-D Evaluation Board nötig. Allerdings bietet das Board zwei Merkmale, die für die Konfiguration bzw. Entwick- lung der BorderGateway Software sehr hilfreich sein können.
Siehe 3.1.2 ConverGate-D Evaluation Board: Modell easy4271.
3.4.4.1.1 User DIP Switches lesen Diese Miniaturschalter können von MPC-Modul-Softwareabgefragt werden und dienen somit als externe Konfigurationsmodifikatoren. Die Nutzung der Schalter ist allerdings nicht spezifiziert worden.
Funktionsbeschreibung 8 Abrufen der DIP36-Schalter des ConverGate-D Evaluation Board. Eingabe • -
Ausgabe • Erfolg, falls der Status abgefragt und an den Aufrufer zurückgeliefert werden konnte.
36Dual In-line Package
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 55 - Fachhochschule Hof
– Den Status der Schalter. • Fehler, falls der Status nicht abgefragt oder die Zielvariable nicht geschrieben werden konnte.
3.4.4.1.2 User LEDs schreiben Die Leuchtdioden können von MPC-Modul-Software an und ausgeschalten werden. Damit eig- nen sie sich für die Signalisierung von Zuständen und Aktivitäten der BorderGateway Softwa- re. Die Belegung der LED37s lautet wie folgt (von links nach rechts): 7 Leuchtet, wenn eine Nachricht an den Control-PC gesendet wird. 6 Leuchtet, wenn eine Nachricht vom Control-PC empfangen wird. 5 Leuchtet, wenn ein SIP-Paket erkannt und verarbeitet wird. 4 Leuchtet, wenn ein ARP-Paket erkannt und verarbeitet wird. 3 Leuchtet, wenn ein ICMP-Paket erkannt und verarbeitet wird. Die Dioden werden wieder ausgeschalten, wenn die Aktion beendet wurde.
Funktionsbeschreibung 9 Ändern des Zustands einer User LEDs des ConverGate-D Evaluation Board (An oder Aus). Eingabe • Die Position der LED (0-7). • Den neuen Zustand der LED (An / Aus).
Ausgabe • Erfolg, falls die Operation durchgeführt werden konnte. • Fehler, falls die Operation fehlgeschlagen ist.
3.4.4.2 ConverGate-D - Paketbehandlung
Eine Kernfunktion der BorderGateway Software ist die Antwort auf, die Weiterleitung und der Versand von Netzwerkpaketen auf der A bzw. B-Seite des BorderGateway (siehe 2.4.4 Abstrakte Darstellung und Begriffe). Dazu müssen dem Datenstrom über die beiden GbE-Ports Pakete ent- nommen und auch wieder eingesetzt werden können. Hierfür besitzt der ConverGate-D Voraussetzungen, die nachfolgend erläutert werden [7]: • Exceptions (Ausnahmen) ... ermöglichen es, Netzwerkpakete anhand ihres Inhalts auszufiltern und an eine Softwa- re auf dem MPC-Modul zu übergeben. Über diese Ausnahmen werden ARP, ICMP und SIP Pakete an die BorderGateway Software weitergeleitet. Diese Funktion wird statisch konfiguriert (3.2.1.2 Statische Konfiguration).
37Light-Emitting Diode
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 56 -
• Ingress-Port (Eingang) Über den Ingress-Port können Pakete in die Eingangswarteschlange gestellt werden, um sie erneut von der Firmware verarbeiten zu lassen. Dieser Port ist nur schreibbar und wird in der BorderGateway Software nicht benötigt. • Egress-Port (Ausgang) Über den Egress-Port können Pakete in die Ausgangswarteschlange gestellt werden, oh- ne sie nochmals durch die Firmware verarbeiten zu lassen und werden somit direkt über einen GbE-Port versandt. Dieser Port les- und schreibbar und wird gelesen, um o.g. Netz- werkpakete an die BorderGateway Software weiterzugeben. • PPorts (Physical Ports) Der ConverGate-D besitzt eine Vielzahl von Ports über die einzelne Hardwarebausteine physikalisch identifiziert werden. Diese Ports nennt man daher PPorts. Für die Paketbe- handlung benötigt die BorderGateway Software die Portnummer für GbE-Port 0 (A-Seite, Nummer 128) und GbE-Port 1 (B-Seite, Nummer 130). • LPorts (Logical Ports) Ein PPort kann mehrere virtuelle Ports besitzen. Um einen einheitlichen Zugriff auf PPorts und virtuelle Ports zu ermöglichen, werden beide Typen logischen Portnummern zugeord- net (LPorts). So wird z.B. der LPort anstatt dem PPort für die Weiterleitung (Switching) der Pakete verwendet. Dem GbE-Port 0 wurde LPort 0 zugewiesen, dem GbE-Port 1 LPort 1. Hier eine Übersicht zu den Portnummern:
Tab. 3.6: BorderGateway Port Übersicht GbE-Port PPort LPort 0 (A-Seite) 128 0 1 (B-Seite) 130 1
Der ConverGate-D-Treiber benutzt unterschiedliche Paket-Header für Pakete, die an den Treiber übergeben und die vom Treiber an die BorderGateway Software geliefert werden. In der folgen- den Tabelle werden die Header entnommener und zu versendender Pakete erläutert: [8][5]
Tab. 3.7: ConverGate-D Egress Header Bits 0 - 7 8 - 15 16 - 23 24 - 31 Egress-Receive-Header (CG_Packet_t) 0 payloadLen: Gesamtlänge pduType exceptionPacketI 32 UUI exRxId ingressLport 64 IPNI: Ingress PPort EPNI VC_ID 96 VLAN_tagging Egress-Send-Header (CMD_CG_PH_PacketEgressSend_t) 0 PDU_Type: destinationPort: Egress priority: 0x00 VC_id (0 - 7): 0x00 CG_PH_ETHERNET PPort 32 VC_id (8 - 15): 0x00 UUI: 0x00 payloadLen: Gesamtlänge
Die wichtigen Felder der beiden Header sind mit grün gekennzeichnet. Siehe IPNI-Änderung in 3.2.4.5 ConverGate-D Treiber: drv_cg v3.2.5 und die Firmware-Beschreibung in 3.2.1.1 Firmware. Im Grunde wird je eine Funktion zum Lesen und eine Funktion zum Schreiben von Paketen benötigt.
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 57 - Fachhochschule Hof
3.4.4.2.1 Egress-Port lesen Pakete, die über Exceptions ausgefiltert worden sind, müssen via Egress-Port entnommen wer- den, da der Ingress-Port nur zum Einfügen dient. Zugriff auf den Egress-Port kann nur an einer Stelle bzw. einem Thread im Betriebssystem erfolgen. Wer zuerst liest, bekommt auch die Daten zuerst.38
Funktionsbeschreibung 10 Entnahme von ausgefilterten Paketen via Egress-Port. Eingabe • -
Ausgabe • Erfolg, wenn das Paket gelesen werden konnte. – Das ausgefilterte Paket. • Fehler, wenn das Paket nicht gelesen werden konnte.
3.4.4.2.2 Egress-Port schreiben Zum Einfügen von Paketen wird ebenfalls der Egress-Port genutzt, denn die Firmware muss die Pakete nicht verarbeiten und somit können die Pakete direkt verschickt werden.
Funktionsbeschreibung 11 Einfügen von Paketen via Egress-Port. Eingabe • Das zu versendende Paket.
Ausgabe • Erfolg, wenn das Paket eingefügt werden konnte. • Fehler, wenn das Paket nicht eingefügt werden konnte.
3.4.4.3 ConverGate-D - Statische Konfiguration
Wie in 3.2.1.2 Statische Konfiguration beschrieben, wird die statische Konfiguration beim Start der BorderGateway Software auf den ConverGate-D übertragen bzw. angewendet. Ein Fehler wäh- rend der statischen Konfiguration muss zum Abbruch der BorderGateway Software führen.
3.4.4.3.1 WinEASY-Konfiguration schreiben Die binäre Konfigurationsdatei muss geöffnet und API39-Befehl für API-Befehl gelesen und an den ConverGate-D-Treiber übertragen werden. Siehe 3.4.5 Binärer Dateizugriff (BCFA)).
38Die WinEASY-Applikation cg_connectix auf dem MPC-Modulmuss beendet werden, um Pakete lesen zu können. 39Application Programming Interface
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 58 -
Funktionsbeschreibung 12 Lesen und übertragen der WinEASY-Konfiguration an den ConverGate-D. Eingabe • Den Namen einer binären Konfigurationsdatei.
Ausgabe • Erfolg, wenn die Daten übertragen wurden. • Fehler, wenn die Daten nicht übertragen wurden.
3.4.4.3.2 Firmware ubertragen¨ Eine Firmware wird mit dem „Basic Device Init“-Befehl an den ConverGate-D-Treiber wei- tergegeben. Da dieser Befehl in der binären Konfigurationsdatei vorkommen muss, kann die Firmware direkt beim Übertragen der binären Daten eingespielt werden.
Funktionsbeschreibung 13 Abfangen des Befehls „Basic Device Init“ und Anhängen der Firmware. Eingabe • Den Namen der Firmware-Datei. • Den Kontext des „Basic Device Init“-Befehls.
Ausgabe • Erfolg, wenn die Firmwareübertragen wurde. • Fehler, wenn die Firmwarenicht übertragen wurde.
3.4.4.3.3 MAC-Adresse setzen Die MAC-Adresse kann auch in der binären Konfigurationsdatei vorkommen. In diesem Fall wird die MAC-Adresse nicht durch die BorderGateway Software gesetzt. Wenn allerdings nach dem Laden der binären Konfiguration keine MAC-Adresse konfiguriert ist, muss dies nachträglich geschehen.
Funktionsbeschreibung 14 Setzen der MAC-Adresse. Eingabe • Die MAC-Adresse.
Ausgabe • Erfolg, wenn die Hardwareadresse gesetzt wurde. • Fehler, wenn die Hardwareadresse nicht gesetzt wurde.
3.4.4.3.4 MAC-Adresse lesen Um die MAC-Adresse anzeigen zu können und zu überprüfen, ob überhaupt eine Adresse einge- stellt wurde, muss die MAC-Adresse auch gelesen werden.
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 59 - Fachhochschule Hof
Funktionsbeschreibung 15 Lesen der MAC-Adresse. Eingabe • -
Ausgabe • Erfolg, wenn die Hardwareadresse gelesen wurde. – Die MAC-Adresse. • Fehler, wenn die Hardwareadresse nicht gelesen wurde.
3.4.4.4 ConverGate-D - Dynamische Konfiguration
Um einen Halfcall zu verwalten, muss dem ConverGate-D eine Reihe von Daten übergeben werden, z.B. IP- und MAC-Adressen. Die Termination IDs sind gleichzeitig Index in die Weiter- leitungstabelle bzw. den Vergleichsspeicher. An dieser Stelle muss man darauf achten, dass für jeden Halfcall zwei Einträge in den Speicher bzw. die Tabelle geschrieben werden. Jeder Eintrag wird über einen Index spezifiziert. Der Index entspricht der Termination ID für eben jenen Halfcall: Index für RTP = Termination ID, Index für RTCP = Termination ID+1. Siehe auch 3.4.1.2 Rahmenbedingungen (ConverGate-D). Für die komplette dynamische Konfiguration werden fünf Operationen benötigt: 1. Füllen des Vergleichsspeichers (BCAM). 2. Lesen des Vergleichsspeichers. 3. Löschen des Vergleichsspeichers. 4. Füllen der Weiterleitungstabelle (FIB). 5. Löschen der Weiterleitungstabelle. Der Vergleichsspeicher dient dem ConverGate-D zum Vergleich der IP-Adresse und des UDP- Ports eines eingegangen Paketes mit bestehenden Halfcalls. Ein Eintrag im Vergleichsspeicher ist 64-Bit groß. Aus der Weiterleitungstabelle holt sich der ConverGate-D die Daten, um das Paket weiterzu- leiten, falls die Suche im Vergleichsspeicher erfolgreich war. Für den BorderGateway werden 7 Einträge benötigt (siehe „CRLT40 index“-Wertetabelle rechts unten):
40Classification Result Location Table
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 60 -
Abb. 3.23: BorderGateway - Media Stream Switching (downstream)
Wie auf der Abbildung zu sehen ist, befinden sich an Index 13 im Vergleichsspeicher (BCAM) die Adressdaten des eingehenden Paketes. Unter Index 13 in der Weiterleitungstabelle (FIB) findet man die Adressdaten des augehenden Paketes. Bei einer erfolgreichen Suche im Vergleichsspei- cher ist der Index des gefundenen Eintrages der Index in die Weiterleitungstabelle.
Siehe auch 2.4.4 Abstrakte Darstellung und Begriffe, 3.1.3 ConverGate-D Netzwerkprozessor und 3.2.1.5 Dynamische Konfiguration.
3.4.4.4.1 Vergleichsspeicher (BCAM) fullen¨ Als Parameter werden, abgesehen von einigen festen Werten, die Remote-IP-Adresse und der lokale UDP-Port des Halfcalls verwendet.
Funktionsbeschreibung 16 Schreiben eines BCAM Eintrages. Eingabe • Den Index in den Vergleichsspeicher. • Die Remote-IP-Adresse des Halfcalls. • Den lokalen UDP-Port des Halfcalls.
Ausgabe • Erfolg, wenn der Eintrag geschrieben wurde. • Fehler, wenn der Eintrag nicht geschrieben wurde.
3.4.4.4.2 Vergleichsspeicher (BCAM) lesen Prinzipiell benötigt die BorderGateway Software keine Funktion zum Auslesen eines BCAM-
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 61 - Fachhochschule Hof
Eintrages. Es gibt dennoch zwei hilfreiche Anwendungen, und zwar als Test, ob ... 1. ... die Werte auch korrekt geschrieben worden sind. 2. ... der Eintrag bei Index X frei ist. Wenn über den Index kein Eintrag im Vergleichsspeicher gefunden wird und der Index innerhalb 1-2048 liegt, kann davon ausgegangen werden, dass dieser Eintrag noch nicht belegt ist. Ein Fehler als Ergebnis ist also je nach Anwendung als Erfolg zu werten.
Funktionsbeschreibung 17 Lesen eines BCAM Eintrages. Eingabe • Den Index in den Vergleichsspeicher.
Ausgabe • Erfolg, wenn der Eintrag gelesen wurde. – Remote-IP-Adresse des Halfcalls. – Lokaler UDP-Port des Halfcalls. • Fehler, wenn der Eintrag nicht gelesen wurde.
3.4.4.4.3 Vergleichsspeicher (BCAM) l¨oschen Diese Funktion wird zum Beenden von Verbindungen benötigt. Der ConverGate-D-Treiber löscht den Speichereintrag.
Funktionsbeschreibung 18 Löschen eines BCAM Eintrages. Eingabe • Den Index in den Vergleichsspeicher.
Ausgabe • Erfolg, wenn der Eintrag gelöscht wurde. • Fehler, wenn der Eintrag nicht gelöscht werden konnte.
3.4.4.4.4 Weiterleitungstabelle (FIB) fullen¨ Das Schreiben der Daten in die Weiterleitungstabelle erfolgt anhand der Termination ID des Halfcalls und der Art der zu schreibenden Werte.
Funktionsbeschreibung 19 Schreiben eines Eintrages in die Weiterleitungstabelle. Eingabe • Den Index in die Weiterleitungstabelle (Termination ID). • Den Index des Wertes (CRLT-Index). Siehe Tabelle 3.21 Einträge in Weiterleitungstabelle. • Den zu schreibenden Wert. Siehe Tabelle 3.21 Einträge in Weiterleitungstabelle.
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 62 -
Ausgabe • Erfolg, wenn der Eintrag geschrieben wurde. • Fehler, wenn der Eintrag nicht geschrieben werden konnte.
Siehe 3.2.1.4 WinEASY Erweiterungen.
3.4.4.4.5 Weiterleitungstabelle (FIB) l¨oschen Das Löschen eines Eintrags in der Tabelle wird vorgenommen, indem anstatt den Werten aus Tabelle 3.21 Einträge in Weiterleitungstabelle der Wert 0 geschrieben wird.
Funktionsbeschreibung 20 Löschen eines Eintrages in der Weiterleitungstabelle. Eingabe • Den Index in die Weiterleitungstabelle. • Den Index des Wertes. Siehe Tabelle 3.21 Einträge in Weiterleitungstabelle. • Den zu schreibenden Wert 0. Siehe Tabelle 3.21 Einträge in Weiterleitungstabelle.
Ausgabe • Erfolg, wenn der Eintrag geschrieben wurde. • Fehler, wenn der Eintrag nicht geschrieben werden konnte.
Siehe 3.2.1.4 WinEASY Erweiterungen.
3.4.5 Bin¨arer Dateizugriff (BCFA)
Binärer Dateizugriff wird benötigt, um die mit WinEASY übertragenen Konfigurationsdaten spei- chern und wieder laden zu können (BCFA41).
Es soll ein Header und jede WinEASY-Nachricht vollständig in eine binäre Datei geschrieben werden. Dies verbraucht zwar mehr Speicherplatz, vereinfacht aber den Speicher- und Lade- vorgang sowie das Layout der Datei sehr. Das ist allerdings nur möglich, da alle WinEASY- Nachrichten an den ConverGate-D-Treiber in der gleichen Datenstruktur übertragen werden. Zwar unterscheidet sich der Inhalt bzw. Layout der Struktur von API-Befehl zu API-Befehl, die Größe ist jedoch immer gleich. Das Ergebnis ist eine binäre Konfigurationsdatei, mit der die ConverGate-D Hardware konfiguriert werden kann, ohne die einzelnen API-Nachrichten ken- nen zu müssen.
Siehe 3.2.1.4 WinEASY Erweiterungen, bzw. 3.4.4.3.1 WinEASY-Konfiguration schreiben.
41Binary Configuration File Access
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 63 - Fachhochschule Hof
3.4.5.1 Header / Dateivorspann
Der Header der Konfigurationsdatei soll sicherstellen, dass eine zuvor gespeicherte Konfigurati- on fehlerfrei geladen und übertragen werden kann. Der Autor hat sich für folgendes Design entschieden: • Ein Identifikationskennzeichen, das die Datei eindeutig identifiziert (’IFX’ und den Byte- wert 0). • Die Größe eines API-Datensatzes bzw. Datenblockes. Dieser Wert dient zwei Aufgaben: – Durch den Vergleich dieses Wertes mit der Größe eines Datensatzes der ladenden An- wendung, kann die grundlegende Kompatibilität zwischen Konfigurationsdatei und aktuellem ConverGate-D-Treiber überprüft werden. – Die Datei kann über folgende Rechnung auf Fehlerfreiheit überprüft werden: (
3.4.5.2 BCFA - Datei ¨offnen
Die Konfigurationsdatei muss geöffnet werden, bevor sie gelesen bzw. geschrieben werden kann. Man muss ebenfalls beachten, ob die Datei zum Lesen oder zum Schreiben geöffnet wird. • Lesen: Die Datei wird nur zum Lesen geöffnet und nicht geändert. • Schreiben: Die Datei wird zum Schreiben geöffnet. Falls die Datei bereits existiert, wird sie auf die Größe 0 gekürzt, ansonsten wird die Datei neu erstellt. In beiden Fällen beginnt der Schreib- bzw. Lesevorgang bei Position 0 in der Datei.
Funktionsbeschreibung 21 Öffnen / erstellen der binären Datei. Eingabe • Die Information ob die Datei zum Lesen oder Schreiben geöffnet wird.
Ausgabe • Erfolg, wenn die Datei geöffnet wurde. • Fehler, wenn die Datei nicht geöffnet wurde.
3.4.5.3 BCFA - Datei schließen
Funktionsbeschreibung 22 Schließen der binären Datei. Eingabe • -
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 64 -
Ausgabe • Erfolg, wenn die Datei geschlossen wurde. • Fehler, wenn die Datei nicht geschlossen wurde.
3.4.5.4 BCFA - Datei schreiben
Der erste Schreibvorgang bestimmt die Datensatzgröße, die in den Dateiheader geschrieben wird. Beim ersten Dateizugriff wird zuerst der Header geschrieben. Alle Datensätze müssen die gleiche Größe haben.
Funktionsbeschreibung 23 Schreiben eines Datensatzes (WinEASY-Nachricht) in die Konfigurationsdatei. Eingabe • Den Datensatz. • Die Größe des Datensatzes.
Ausgabe • Erfolg, wenn der Datensatz geschrieben wurde. • Fehler, wenn der Datensatz nicht geschrieben wurde.
3.4.5.5 BCFA - Datei lesen
Wie beim schreibenden Zugriff auf die Konfigurationsdatei, wird beim Lesen immer die gleiche Größe des Datensatzes erwartet. Bei den Rückgabewerten muss ein spezieller Wert signalisie- ren, wenn keine Daten mehr gelesen werden konnten, was das Dateiende und damit keinen Fehler darstellt. Der Dateiheader wird beim ersten Lesezugriff implizit gelesen und die Datei auf Konsistenz überprüft.
Funktionsbeschreibung 24 Lesen eines Datensatzes (WinEASY-Nachricht) aus der Konfigurationsdatei. Eingabe • Die Größe des Datensatzes.
Ausgabe • Erfolg, wenn der Datensatz geschrieben wurde. – Den Datensatz. • Fehler, wenn der Datensatz nicht geschrieben wurde. • Warnung, wenn das Dateiende erreicht wurde und somit keine Daten gelesen werden konnten.
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 65 - Fachhochschule Hof
3.4.6 Netzwerkpakete
Eine der Hauptaufgaben der BorderGateway Software ist die Unterstützung und Behandlung von Netzwerkpaketen, die über das ConverGate-D-Interface entnommen bzw. eingefügt wer- den (siehe 3.4.4.2 ConverGate-D - Paketbehandlung). Netzwerkpakete bestehen aus verschiedenen Schichten. Jede Schicht enthält einen Header und, je nach Pakettyp, darauf folgende Nutzdaten (Payload): [14]
Tab. 3.8: TCP/IP-Protokollstapel Schicht (Layer) Name Protokoll(e) 5. Anwendung (Application) SIP, RTP, RTCP 4. Transport UDP 3. Vermittlung (Network/Internet) IP, ARP, ICMP 1 + 2. Netzzugang (Physical & Data Link) Ethernet
Im Folgenden wird für jedes Protokoll die einzelnen Paketbestandteile und benötigte Operatio- nen erläutert.
3.4.6.1 Ethernet
Die unterste Schicht der verwendeten Netzwerkprotokolle ist die sog. Ethernet-Schicht42. Diese Schicht verbindet die in einem Netzwerk vorhandene Hardware via MAC-Adressen und ist die Basis für alle folgenden Netzwerkprotokolle. MAC-Adressen müssen in einem Netzwerk immer eindeutig sein: [10]
Tab. 3.9: Ethernet II Header Bits 0 - 7 8 - 15 16 - 23 24 - 31 0 MAC-Zieladresse (0 - 31) 32 MAC-Zieladresse (32 - 47) MAC-Quelladresse (0 - 15) 64 MAC-Quelladresse (16 - 47) 96 Ethernet Protokoll Typ
Die MAC-Quelladresse spezifiziert die Quell-Hardware, von der das Netzwerkpaket versendet wird. Die MAC-Zieladresse spezifiziert die Ziel-Hardware, die durch das Netzwerkpaket ange- sprochen werden soll. Ein Netzwerkpaket auch kann an alle Teilnehmer im Netz versendet wer- den, wenn die Zieladresse die sog. Broadcast-MAC-Adresse FF:FF:FF:FF:FF:FF ist.
Der Ethernet Protokoll Typ identifiziert die Payload-Daten des Netzwerkpaketes: [2]
Tab. 3.10: Ethernet Protokoll Typen Protokoll Wert Konstante ARP 0x0806 ETH_P_ARP IP 0x0800 ETH_P_IP
Für die BorderGateway Software genügen o.g. Protokolle. Diesem Vorspann folgen protokolls- pezifische Daten (Payload).
42Ethernet physical layer
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 66 -
Funktionsbeschreibung 25 Aufbau eines Ethernet Header. Eingabe • Die MAC-Quelladresse. • Die MAC-Zieladresse. • Den Ethernet Protokoll Typ.
Ausgabe • Erfolg, wenn der Ethernet Header erstellt werden konnte. – Den Ethernet Header. • Fehler, wenn der Ethernet Header nicht erstellt werden konnte.
3.4.6.2 ARP - Address Resolution Protocol
Um als vollwertige Hardware in einem Netzwerk Pakete verschicken zu können, muss man die MAC-Adressen der eigenen (Quell-) sowie der Ziel-Hardware kennen. Dazu ist es erforderlich in einem Netzwerk auf Anfragen über die eigene Hardware-Adresse zu antworten und selbst Anfragen über Ziel-Hardware an das Netzwerk zu stellen. Dies ermöglicht die Zuordnung von IP-Adresse zu MAC-Adresse. Aus diesem Grund werden ARP-Pakete im Netzwerk verschickt.
ARP-Anfragen werden generell an alle Teilnehmer in einem Netzwerk verschickt, indem die Broadcast-MAC-Adresseals MAC-Zieladresse benutzt wird. ARP-Antworten sind immer an einen Teilnehmer zurückzuschicken.
Die folgende Tabelle zeigt speziell die Anwendung in MAMS in einem Ethernet-Netzwerk mit IPv4: [10][2] Tab. 3.11: ARP-Paket Bits 0 - 7 8 - 15 16 - 23 24 - 31 0 hrd: 0x0001 / ARPHRD_ETHER pro: 0x0800 / ETH_P_IP 32 hln: 0x06 / ETH_ALEN pln: 0x04 op: Request, Reply 64 sha (0 - 31): MAC-Quelladresse 96 sha (32 - 47): MAC-Quelladresse spa (0 - 15): IP-Quelladresse 128 spa (16 - 31): IP-Quelladresse tha (0 - 15): MAC-Zieladresse 160 tha (16 - 47): MAC-Zieladresse 192 tpa (0 - 31): IP-Zieladresse
Die folgende Tabelle zeigt die verwendeten Operationscodes: [2]
Tab. 3.12: ARP-Paket Befehlscodes (op) Operation Wert Konstante Request 0x0001 ARPOP_REQUEST Reply 0x0002 ARPOP_REPLY
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 67 - Fachhochschule Hof
Funktionsbeschreibung 26 Aufbau eines ARP-Pakets. Eingabe • Den ARP-Befehlscode (Request, Reply). • Die MAC-Quelladresse. • Die MAC-Zieladresse. • Die IP-Quelladresse. • Die IP-Zieladresse.
Ausgabe • Erfolg, wenn das ARP-Paket erstellt werden konnte. – Das gefüllte ARP-Paket . • Fehler, wenn das ARP-Paket nicht erstellt werden konnte.
Hinweis(e) • Die angegebenen Einträge aus Tabelle 3.11 ARP-Paket sind für alle Pakete gleich.
Siehe 3.4.6.1 Ethernet.
3.4.6.2.1 Antwort auf einen ARP-Request Um die eigene IP-Adresse in einem Netzwerk bekannt zu machen, muss die BorderGateway Soft- ware auf eingehende ARP-Requests mit einem ARP-Reply antworten, wenn folgende Bedingun- gen zutreffen: • Ethernet Header: – Die MAC-Zieladresse ist ein Broadcast. – Der Protokoll Typ ist ETH_P_ARP. • ARP-Request-Paket: – Der Befehlscode ist ARPOP_REQUEST. – Die IP-Zieladresse ist eine der beiden BorderGateway IP-Adressen. Das eingehende Paket muss verworfen bzw. ignoriert werden, wenn eine der genannten Bedin- gungen nicht zutrifft. Ansonsten wird ein ARP-Reply-Paket mit folgenden Eigenschaften gene- riert und verschickt: • Ethernet Header: – Die MAC-Quelladresse ist die BorderGateway bzw. ConverGate-D MAC-Adresse. – Die MAC-Zieladresse ist die MAC-Quelladresse des ARP-Requests. • ARP-Reply-Paket: – Die MAC-Quelladresse ist die BorderGateway bzw. ConverGate-D MAC-Adresse. – Die IP-Quelladresse ist die BorderGateway IP-Adresse, auf der der Request eingegan- gen ist. – Die MAC-Zieladresse ist die MAC-Quelladresse des ARP-Requests.
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 68 -
– Die IP-Zieladresse ist die IP-Quelladresse des ARP-Requests. Auf jeden eingehenden Request muss auch ein Reply gesendet werden.
Funktionsbeschreibung 27 Antwort auf einen ARP-Request. Eingabe • Das empfangene ARP-Request-Paket.
Ausgabe • Erfolg, wenn das ARP-Reply-Paket versendet werden konnte. • Fehler, wenn das ARP-Reply-Paket nicht versendet werden konnte.
Siehe Tabelle 3.9 Ethernet II Header und Tabelle 3.11 ARP-Paket.
3.4.6.2.2 Versenden eines ARP-Request Um fremde IP-Adressen MAC-Adressen zuordnen zu können, muss der BorderGateway auch ARP-Anfragen in das Netzwerk schicken. Dies ist notwendig, da für die Verwaltung von Verbin- dungen dem BorderGateway nur IP-Adressen vorliegen, MAC-Adressen aber ebenfalls für den Verbindungsaufbau benötigt werden. Siehe Abbildung 3.16 Befehl - ADD_REQ, Abbildung 3.18 Be- fehl - MODIFY_REQ und 3.4.4.4 ConverGate-D - Dynamische Konfiguration. Hierzu wird ein ARP-Request-Paket mit folgenden Eigenschaften generiert: • Ethernet Header: – Die MAC-Quelladresse ist die BorderGateway bzw. ConverGate-D MAC-Adresse. – Die MAC-Zieladresse ist die Broadcast Adresse. • ARP-Request-Paket: – Die MAC-Quelladresse ist die BorderGateway bzw. ConverGate-D MAC-Adresse. – Die IP-Quelladresse ist die BorderGateway IP-Adresse auf der der Request verschickt wird. – Die IP-Zieladresse ist die Remote-IP-Adresse des Teilnehmers, für die die MAC- Adresse gesucht wird. Nach Versenden dieses Paketes wird eine gewisse Zeit lang auf einen ARP-Reply gewartet. Wenn innerhalb dieser Wartezeit keine Antwort eintrifft, muss der BorderGateway davon ausgehen, dass die IP-Adresse des Teilnehmers nicht existiert. Ansonsten wird ein ARP-Reply-Paket mit folgenden Bedingungen erwartet: • Ethernet Header: – Die MAC-Quelladresse ist die MAC-Adresse des gesuchten Teilnehmers. – Die MAC-Zieladresse ist die BorderGateway bzw. ConverGate-D MAC-Adresse. • ARP-Reply-Paket: – Die MAC-Quelladresse ist die MAC-Adresse des gesuchten Teilnehmers. – Die IP-Quelladresse ist die IP-Adresse des gesuchten Teilnehmers. – Die MAC-Zieladresse ist die BorderGateway bzw. ConverGate-D MAC-Adresse.
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 69 - Fachhochschule Hof
– Die IP-Zieladresse ist die BorderGateway IP-Adresse auf der der Request verschickt wurde. Mit dem Eintreffen des ARP-Replies erhält man also die MAC-Adresse des gesuchten Teilnehmers und hat somit alle Daten um Pakete an diesen zu senden.
3.4.6.2.3 Versenden vieler/paralleler ARP-Requests Aufgrund der parallelen Abarbeitung von ADD_REQ und MODIFY_REQ Nachrichten vom Control-PC an das MPC-Modul, müssen mehrere ARP-Requests parallel versendet und mehrere eingehende ARP-Replies parallel bearbeitet werden. Dies ist nicht mehr so trivial wie die 1:1 Beziehung von eingehenden ARP-Requests zu den zu versendenden ARP-Replies. Die Schwie- rigkeit hierbei besteht in der Tatsache, dass ein Thread eingehende Pakete empfängt, aber viele Threads auf eingehende ARP-Replies warten können. Die BorderGateway Software muss also eine Zuordnung zwischen den eingehenden ARP-Replies und den wartenden Threads treffen. Dies wird so gelöst: Abb. 3.24: ARP-Request Prozess
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 70 -
• Die auf Antwort wartenden Threads schreiben in eine sog. ARP-Reply-Warteliste, bevor sie den ARP-Request abschicken. • Ein Eintrag in der Liste besteht aus folgenden Einträgen: – Die Semaphore, die den Erfolg oder Timeout der Operation signalisiert. – Die IP-Adresse des gesuchten Teilnehmers. – Der MAC-Adresse des gesuchten Teilnehmers. • Für den wartenden Thread (links) ist entscheidend, dass die Warteliste erst dann wieder freigegeben wird, wenn das Paket versandt wurde. Die Antwort auf einen ARP-Request kann äußerst schnell erfolgen, so dass sichergestellt werden muss, dass zwischen der Frei- gabe der Warteliste und dem Warten auf Timeout bzw. Erhalt der MAC-Adresse möglichst wenig Zeit vergeht. • Der empfangende Thread (rechts) durchsucht die Warteliste mit der IP-Quelladresse von eingehenden ARP-Reply-Paketen: – Das Paket wird verworfen, wenn kein wartender Thread in der Warteliste gefunden wird. – Die MAC-Adresse des gesuchten Teilnehmers wird übergeben, die Semaphore des wartenden Threads wird geöffnet und damit der Erfolg der Operation signalisiert. • Der Zugriff auf die Warteliste darf immer nur durch einen einzigen Thread zur Zeit ge- schehen (siehe Semaphoren in 3.2.4.3 uClibc).
Somit sind zwei Funktionen nötig.
ARP-Request senden Wie in 3.4.6.2.3 Versenden vieler/paralleler ARP-Requests beschrieben, müssen viele ARP-Requests parallel verschickt werden.
Funktionsbeschreibung 28 Versenden eines ARP-Request. Eingabe • Die IP-Quelladresse. • Die IP-Zieladresse.
Ausgabe • Erfolg, wenn die MAC-Adresse ermittelt werden konnte. – Die MAC-Adresse der IP-Zieladresse. • Fehler, wenn die MAC-Adresse nicht ermittelt werden konnte.
Siehe 3.4.6.2.3 Versenden vieler/paralleler ARP-Requests.
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 71 - Fachhochschule Hof
ARP-Replies verarbeiten Nachdem ein ARP-Reply empfangen wurde, muss eine Liste nach wartenden Threads durchsucht werden.
Funktionsbeschreibung 29 Verarbeiten eines ARP-Replies. Eingabe • Das empfangene ARP-Paket.
Ausgabe • Erfolg, wenn der ARP-Reply zugeordnet werden konnte. – MAC-Adresse und Signal an den wartenden Thread. • Fehler, wenn der ARP-Reply nicht zugeordnet werden konnte.
Siehe 3.4.6.2.3 Versenden vieler/paralleler ARP-Requests.
3.4.6.3 IP - Internet Protocol (v4)
IP ist das wichtigste Protokoll in der BorderGateway Software, denn auf IP basieren alle fol- genden Protokolle. Es dient dem Transport von Daten in paketbasierten Netzwerken mit festen, eindeutigen Quell- und Zieladressen, den IP-Adresse. Für das Versenden von IP-Paketen benötigt man die IP-Quell- und Zieladresse sowie die jeweils korrespondierende MAC-Adresse, siehe 3.4.6.2 ARP - Address Resolution Protocol. Alle von der BorderGateway Software generierten IP-Header haben folgendes Layout: [14]
Tab. 3.13: IP-Header Bits 0 - 7 8 - 15 16 - 23 24 - 31 0 version (7 - 4): 4 / IP- tos: 0 tot_len: Gesamtlänge IP+Daten VERSION, ihl (3 - 0): 5 / IP_P_MIN_HEAD- ER_LENGTH 32 id: 0x0000 flags/frag_off: 0x0000 64 ttl: 64/IPDEFTTL protocol: ICMP, UDP check: Siehe 3.4.6.8 IP-Prüfsummen 96 saddr: IP-Quelladresse 128 daddr: IP-Zieladresse
Der Wert im Feld ttl (time to live) wird von jedem Teilnehmer, der das Paket erhält und wei- terleitet, um 1 verringert. Wenn dieser Wert 0 erreicht, muss das Paket verworfen werden. Mit diesem Feld lässt sich also die maximale Zahl der Weiterleitungspunkte auf dem Weg zur Ziel- adresse begrenzen. [14] Für die Anwendung in MAMS werden folgende IP-Protokolle verwendet: [2]
Tab. 3.14: IP-Protokoll-Typen Protokoll Wert Konstante ICMP 0x01 IPPROTO_ICMP IP in IP 0x04 IPPROTO_IPIP UDP 0x11 IPPROTO_UDP
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 72 -
Funktionsbeschreibung 30 Aufbau eines IP-Header. Eingabe • Die Gesamtlänge (IP-Header + Daten). • Das Protokoll. • Die Quelladresse. • Die Zieladresse.
Ausgabe • Erfolg, wenn der IP-Header erstellt werden konnte. – Den gefüllten IP-Header. • Fehler, wenn der IP-Header nicht erstellt werden konnte.
Hinweis(e) • Die angegebenen Einträge aus Tabelle 3.13 IP-Header sind für alle Pakete gleich. • Die Prüfsumme wird implizit von dieser Funktion berechnet.
Siehe 3.4.6.1 Ethernet.
3.4.6.4 IP in IP
Bei IP in IP handelt es sich um ein IP-Paket, das in ein neues IP-Paket verpackt wurde. Das ursprüngliche, eingepackte IP-Paket nennt man inneres (inner) und das neue, umgebende IP- Paket äußeres (outer) Paket. IP in IP wird genutzt, um IP-Pakete an einen Empfänger umzuleiten43, der normalerweise das eingepackte Paket nicht erhalten hätte. Ein IP-Paket wird also in ein weiteres IP-Paket eingepackt und an einen neuen Empfänger gesendet, welcher das Paket wieder entpackt und es an den ursprünglichen Empfänger weiterleitet. Dieses Verfahren nennt man tunneln44.[4] Für die BorderGateway Software wird je eine Funktion zum Einpacken und Auspacken benötigt, welche beide [4] entsprechen müssen.
3.4.6.4.1 IP in IP einpacken (encapsulation) Hier der Ablauf für das Einpacken nach [4] mit abweichenden bzw. neuen Werten für den Hea- der in Tabelle 3.13 IP-Header: • IP Header (outer): – Das Feld tos (type of service) ist das des inneren IP-Pakets. – Die Gesamtlänge ist die Länge des äußeren Headers (20 Bytes) plus Gesamtlänge des inneren IP-Pakets. – Das Feld Flags muss Bit 1 „Don’t Fragment“ gesetzt haben, wenn dies auch im inneren IP-Paket gesetzt ist.
43Routing 44tunneling
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 73 - Fachhochschule Hof
– Das Protokoll ist IP in IP. – Die IP-Quelladresse ist die der BorderGateway B-Seite (Tunnelanfang). – Die IP-Zieladresse ist die des B2BUA (Tunnelende). • IP in IP Header (inner): – Das Feld ttl (time to live) wird um 1 verringert. – Die Prüfsumme wird neu berechnet.
Funktionsbeschreibung 31 Einpacken eines IP-Paketes. Eingabe • Das empfangene IP-Paket.
Ausgabe • Erfolg, wenn das IP-Paket eingepackt werden konnte. – Das fertige IP in IP-Paket. • Fehler, wenn das IP-Paket nicht eingepackt werden konnte.
Hinweis(e) • Die Prüfsumme wird implizit von dieser Funktion berechnet.
Siehe 3.4.6.3 IP - Internet Protocol (v4).
3.4.6.4.2 IP in IP auspacken (decapsulation) Das Auspacken erfordert keine Veränderung am inneren IP-Paket. Es wird einfach das innere Paket ausgepackt und über die A-Seite weitergeleitet.
Funktionsbeschreibung 32 Auspacken eines IP-Paketes. Eingabe • Das empfangene IP in IP-Paket.
Ausgabe • Erfolg, wenn das IP-Paket ausgepackt werden konnte. – Das ausgepackte IP-Paket. • Fehler, wenn das IP-Paket nicht ausgepackt werden konnte.
Siehe 3.4.6.3 IP - Internet Protocol (v4).
3.4.6.5 ICMP - Internet Control Message Protocol
Um die Bereitschaft des BorderGateway und den Zugriff auf dessen Ethernet-Schnittstellen (ge- rade in den Test- und Aufbauphasen) prüfen zu können, sollen ICMP-Echo-Pakete unterstützt werden. Damit ist es möglich, die IP-Adressen der beiden BorderGateway-Netzwerkseiten (A/B)
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 74 - zu pingen45. Dies war nicht in der Spezifikation von Alcatel-Lucent [1] gefordert, hat sich aber als lohnenswerte Ergänzung herausgestellt.
Alle aktuellen Betriebssysteme haben eine Anwendung, um diesen Vorgang durchzuführen (sie- he E.2 ARP / ICMP Generierung) und deswegen erweist sich diese Funktion als äußerst nützlich. Be- sagte Programme senden eine ICMP-Echo-Request-Nachricht an die Zielhardware, welche dann (falls möglich) mit einem Echo-Reply antwortet.
Der ICMP-Echo-Request-Header hat die gleichen Felder wie der Echo-Reply-Header: [12] Tab. 3.15: ICMP-Echo-Reply-Header Bits 0 - 7 8 - 15 16 - 23 24 - 31 0 Type: 0x00 / Code: Aus Echo-Anfrage Checksum: Siehe 3.4.6.8 IP-Prüfsummen ICMP_ECHOREPLY 32 Identifier: Aus Echo-Anfrage Sequence Number: Aus Echo-Anfrage
Nach dem ICMP-Echo-Request-Header folgen noch Daten die 1:1 wieder zurückgeschickt wer- den. Normal ist eine gesamte ICMP-Paketgröße von 64 Byte. In der BorderGateway Softwa- re wird nur auf Echo-Anfragen reagiert, Echo-Anfragen werden nicht versendet: [2] Tab. 3.16: ICMP Echo Typen ICMP Typ Wert Konstante Echo-Anfrage 0x08 ICMP_ECHO Echo-Antwort 0x00 ICMP_ECHOREPLY
Funktionsbeschreibung 33 Aufbau eines ICMP-Pakets. Eingabe • Das eingegangene ICMP-Echo-Request-Paket.
Ausgabe • Erfolg, wenn das ICMP-Echo-Reply-Paket erstellt werden konnte. – Das gefüllte ICMP-Echo-Reply-Paket. • Fehler, wenn das ICMP-Echo-Reply-Paket nicht erstellt werden konnte.
Hinweis(e) • Die angegebenen Einträge aus Tabelle 3.15 ICMP-Echo-Reply-Header sind für alle Pakete gleich. • Die Prüfsumme wird implizit von dieser Funktion berechnet und besteht aus dem gesam- ten ICMP-Paket: ICMP-Header + Daten
Siehe 3.4.6.3 IP - Internet Protocol (v4).
45Auf Vorhandensein im Netzwerk zu überprüfen.
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 75 - Fachhochschule Hof
3.4.6.6 UDP - User Datagram Protocol
UDP ist ein unsicheres, paketbasiertes Protokoll, mit dem relativ einfach kleinere Datenpakete (bis 64 kB) an einen bestimmten Port der Ziel-Hardware geschickt werden können. Unsicher ist es, weil keine Eingangsbestätigung der Ziel-Hardware übermittelt wird und Pakete somit verloren gehen können. [11]
Hier die Felder des UDP-Headers: [11] Tab. 3.17: UDP-Header Bits 0 - 7 8 - 15 16 - 23 24 - 31 0 Source Port: Quellport des Pakets Destination Port: Zielport des Pakets 32 Length: Gesamtlänge = Header+Daten Checksum: Siehe 3.4.6.8 IP-Prüfsummen
Diesem Header folgen Daten mit einer maximalen Länge in Bytes von 0xffe3 (65507):
Funktionsbeschreibung 34 Aufbau eines UDP-Header. Eingabe • Den zugehörigen IP-Header. • Den Quellport. • Den Zielport. • Die Gesamtlänge des Paketes.
Ausgabe • Erfolg, wenn der UDP-Header erstellt werden konnte. – Den gefüllten UDP-Header. • Fehler, wenn der UDP-Header nicht erstellt werden konnte.
Hinweis(e) • Die UDP-Prüfsumme wird implizit von dieser Funktion berechnet. Sie besteht aus folgen- den Feldern, gefolgt von dem gesamten UDP-Paket: [11]
Tab. 3.18: UDP-Checksum-Header Bits 0 - 7 8 - 15 16 - 23 24 - 31 0 IP-Quelladresse 32 IP-Zieladresse 64 0x00 IP-Protokoll UDP-Gesamtlänge
Siehe 3.4.6.3 IP - Internet Protocol (v4).
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 76 -
3.4.6.7 SIP - Session Initiation Protocol
SIP ist ein Signalisierungsprotokoll, mit dem Sessions46 zwischen zwei oder mehreren Teilneh- mern aufgebaut, geändert und beendet werden können. Es wird z.B. auch in Voice over IP verwendet. [13] Der eigentliche Grund für die Unterstützung von IP und UDP ist SIP. SIP-Pakete werden über die Netzwerke hinweg verschickt, um die Verbindungen des BorderGa- teway zu steuern. Absender dieser Pakete ist ein Benutzer (z.B. ein IP-Telefon) und Empfänger ist der Back-to-back User Agent (UDP-Port 5060). Wie in 2.4.3 NGN - Next Generation Networks be- schrieben, erhält und sendet der B2BUA über den BorderGateway SIP-Pakete. Je nachdem von welcher Seite der BorderGateway SIP-Pakete erhält, wird das Paket weiterverarbeitet: Abb. 3.25: SIP Paketbehandlung
46Sitzungen
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 77 - Fachhochschule Hof
Am Anfang der SIP-Paketbehandlung muss erst einmal festgestellt werden, ob es sich bei dem empfangenen Paket um ein SIP-Paket handelt. Hierzu müssen folgende Bedingungen eingehal- ten werden: [1]
• Ethernet Header (siehe 3.4.6.1 Ethernet): – Die MAC-Zieladresse ist die des ConverGate-D. – Das Protokoll ist IP. • Überprüfung auf A-Seite: – IP Header (siehe 3.4.6.3 IP - Internet Protocol (v4)): ∗ Das Protokoll ist UDP. ∗ Die IP-Zieladresse ist die des B2BUA. – UDP Header (siehe 3.4.6.6 UDP - User Datagram Protocol): ∗ Der UDP-Zielport ist der des B2BUA (5060). • Überprüfung auf B-Seite: – IP Header (siehe 3.4.6.3 IP - Internet Protocol (v4)): ∗ Das Protokoll ist IP in IP. ∗ Die IP-Quelladresse ist die des B2BUA. ∗ Die IP-Zieladresse ist die der BorderGateway B-Seite. – IP in IP Header (siehe 3.4.6.4 IP in IP): ∗ Das Protokoll ist UDP. ∗ Die IP-Quelladresse ist die des B2BUA. – UDP Header (siehe 3.4.6.6 UDP - User Datagram Protocol): ∗ Der UDP-Quellport ist der des B2BUA (5060).
Das Paket wird verworfen, wenn eine der Bedingungen nicht eingehalten wird. Zudem werden alle eingehenden SIP-Pakete gezählt.
Funktionsbeschreibung 35 Überprüfen auf SIP-Paket von A oder B-Seite. Eingabe • Das eingegangene Netzwerkpaket.
Ausgabe • Erfolg, wenn das Paket den SIP-Bedingungen entspricht. – Die IP-Adresse der A oder B-Seite. • Fehler, wenn das Paket den SIP-Bedingungen nicht entspricht.
Hinweis(e) • Nachdem das Paket erfolgreich als SIP-Paket überprüft wurde, muss auch sichergestellt werden, dass das Paket auch tatsächlich über den der IP-Adresse entsprechenden A oder B-Port eingegangen ist. Siehe Feld IPNI in Tabelle 3.7 ConverGate-D Egress Header.
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 78 -
3.4.6.7.1 SIP-Pakete an der A-Seite SIP-Nachrichten von der unsicheren A-Seite werden verpackt (encapsulated) und an den B2BUA im sicheren Netzwerk weitergeleitet. [1]
Funktionsbeschreibung 36 Für den SIP-Einpackvorgang siehe 3.4.6.4.1 IP in IP einpacken (encapsulation). Für den Versand siehe 3.4.4.2.2 Egress-Port schreiben. Hinweis(e) • Die MAC-Adresse des B2BUA muss via ARP ermittelt werden. Die Adresse soll gespeichert werden, damit für neue SIP-Nachrichten nicht nocheinmal ARP-Pakete verschickt werden müssen.
3.4.6.7.2 SIP-Pakete an der B-Seite SIP-Nachrichten von der sicheren B-Seite werden entpackt (decapsulated) und ohne weitere Änderungen in das unsichere Netzwerk versendet. [1]
Funktionsbeschreibung 37 Für den SIP-Auspackvorgang siehe 3.4.6.4.2 IP in IP auspacken (decapsulation). Für den Versand siehe 3.4.4.2.2 Egress-Port schreiben. Hinweis(e) • Die MAC-Adresse der IP-Zieladresse des inneren IP-Paketes muss über ARP ermittelt wer- den.
3.4.6.8 IP-Prufsummen¨
IP-, ICMP- und UDP-Pakete besitzen eine Prüfsumme, mit der die Integrität der Pakete überprüft werden kann. Der Algorithmus ist relativ einfach und wird für IPwie folgt definiert:
The checksum field is the 16-Bit one’s complement of the one’s complement sum of all 16-Bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero. [14]
Mit anderen Worten: Jedes Wort eines IP-Header wird zusammengezählt (Achtung: zu einer 16-Bit-Summe mit Über- läufen!). Am Ende der Berechnung wird die Summe mit einem binären NICHT (NOT = ˜) invertiert (aus jeder 0 wird 1 und aus jeder 1 wird 0).
Die Prüfsumme für UDP und ICMP unterscheidet sich lediglich in den Daten, die in den Berech- nungsprozess mit einbezogen werden. Der Algorithmus ist identisch.
Funktionsbeschreibung 38 Berechnen einer IP/UDP/ICMP kompatiblen 16-Bit Prüfsumme. Eingabe • Die zu berechnenden Daten. • Die Größe der Daten in Byte.
Kapitel 3 Hauptteil 3.4 BorderGateway Software: Spezifikation - 79 - Fachhochschule Hof
Ausgabe • Die Prüfsumme, wenn die Prüfsumme berechnet wurde. • 0, wenn die Prüfsumme nicht berechnet werden konnte.
Siehe 3.4.6.3 IP - Internet Protocol (v4), 3.4.6.6 UDP - User Datagram Protocol, 3.4.6.5 ICMP - Internet Control Message Protocol und Implementierung in 3.5.6.8 IP-Prüfsummen.
3.4 BorderGateway Software: Spezifikation Kapitel 3 Hauptteil Diplomarbeit - 80 -
3.5 BorderGateway Software: Implementierung
Die Implementierung beschäftigt sich mit der Umsetzung der in 3.3 BorderGateway Software: Struk- tur und 3.4 BorderGateway Software: Spezifikation festgelegten Eigenschaften und Funktionalität der BorderGateway Software. Sie wurde vollständig und alleine vom Autor dieser Arbeit umge- setzt. Um die Funktionalität eines Funktionsprototypen bzw. eines Programmablaufes zu verstehen, muss sowohl die Spezifikation als auch die Implementierung betrachtet werden. Da die Funk- tionsbeschreibungen in der Spezifikation äußerst genau sind, fallen die Beschreibungen zu den Funktionsprototypen oft sehr kurz aus. Nur von den Beschreibungen abweichende Details oder zusätzliche Informationen werden in der Implementierung vermerkt. Ab hier werden Grundkenntnisse in C vorausgesetzt, denn wichtige Datenstrukturen sowie Funktionsprototypen werden als Referenz und Beschreibung aus dem Quellcode übernommen. Wenn in Prototypbeschreibungen Bezeichner in eckigen Klammern auftauchen, handelt es sich dabei um Felder von Strukturen in API-Aufrufen oder Datenpaketen. Bei Eingabeparametern wird dieses Feld gefüllt, bei Ausgabeparametern wird aus diesem Feld gelesen. Verweise in Klammern hinter dem Funktionsprototypen zeigen auf den Teil dieses Dokumentes, in dem die zugehörige Funktionsbeschreibung zu finden ist.
3.5.1 Allgemeines
Wie schon in der Spezifikation sollen hier zuerst einige allgemeine Themen erläutert werden. Es werden folgende firmeninterne Notationen verwendet bzw. übernommen: • Globale Konstanten und Definitionen werden in der Datei ifx_types.h gespeichert. • Datentypen beginnen mit IFX_, z.B. IFX_uint16_t. • Konstanten und Macros werden immer großgeschrieben.
3.5.1.1 Listen
Wie in 3.4.1.1 Rahmenbedingungen (Alcatel-Lucent) spezifiziert ist, verwaltet die BorderGate- way Software die Listen für Kontext, Termination-IDs sowie UDP-Ports. Zusammen mit 3.4.1.2 Rahmenbedingungen (ConverGate-D) werden also folgende Listen benötigt und mit den Wer- ten in () initialisiert: 1. Liste mit freien Kontexten (512 Einträge, Kontexte mit Context IDs von 1-512). 2. Liste mit benutzten Kontexten (0 Einträge). 3. Liste mit freien Termination IDs, upstream (512 Einträge, 1025-2048 in Zweier-Schritten). 4. Liste mit freien Termination IDs, downstream (512 Einträge, 1-1024 in Zweier-Schritten). 5. Liste mit benutzten Termination IDs (0 Einträge). 6. Liste mit freien UDP-Ports (1024 Einträge, 20000-22047 in Zweier-Schritten). 7. Liste mit benutzten UDP-Ports (0 Einträge).
Kapitel 3 Hauptteil 3.5 BorderGateway Software: Implementierung - 81 - Fachhochschule Hof
Die verschiedenen Listen werden über externen Quellcode realisiert. Es wird die C-Bibliothek SimCList v1.1 47 verwendet, welche verkettete Listen bereitstellt.
3.5.1.2 Hauptschleife (Main loop)
Die wichtigsten Programmteile der BorderGateway Software sind die Hauptschleife und der paketempfangende Thread. Letzterer wird in 3.5.4.2.1 ConverGate-D Receive-Thread erläutert.
Die Hauptschleife (siehe Abbildung 3.14 BorderGateway Software - Struktur) wartet auf eingehende Nachrichten des Control-PC und versendet Fehlermeldungen:
Listing 3.17: bordergateway.c: Hauptschleife
1 IFX_error_t Bordergateway_Start(IFX_void_t) {
Funktionsweise: 1. Senden der WAKE_UP-Nachricht an den Control-PC, siehe 3.4.3.7.11 WAKE_UP (0x85): Be- reitschaft signalisieren. 2. Solange das Programm nicht abgebrochen wird: a) Warten auf und Behandlung von eingehenden Nachrichten vom Control-PC. b) Überprüfung auf Fehler und senden von Fehlermeldungen an den Control-PC.
3.5.2 Fehlerbehandlung
Wie in 3.4.2.1 Rückgabewerte, Fehlercodes (Fehlernummern) beschrieben werden Rückgabewerte als Aufzählungstyp definiert. Hier ein beispielhafter Auszug:
Listing 3.18: ifx_types.h: Rückgabewerte
1 typedef enum { 2 IFX_ERROR_BG_CMD_CUSTOM_ERROR_STRING = −500, 3 IFX_ERROR = −1, 4 IFX_SUCCESS = 0, 5 IFX_NO_DATA = 1 , 6 } IFX_error_t, IFX_return_t;
Die Rückgabestrings werden in einer Liste wie folgt gespeichert:
Listing 3.19: commands_result_strings.c: Rückgabestringliste
1 static const BG_error_info_t bg_errors[] = 2 {IFX_ERROR , " general error " }, 3 {IFX_NO_DATA , " no data : non−blocking sockets , TLV buffer parsing " }, 4 {0 , " \0 " } /∗ end o f t a b l e ∗/ 5 };
Für jeden Eintrag wird der Rückgabewert angegeben, gefolgt von dem erklärenden Rückgabe- string. Die Liste wird mit leeren Einträgen beendet.
Funktionsprototyp 1 (3.4.2.2 Rückgabestrings) Die C-Funktion durchsucht die Liste mit den Rückgabestrings anhand der Fehlernummer und liefert entweder NULL oder einen String zurück.
47http://mij.oltrelinux.com/devel/simclist/
3.5 BorderGateway Software: Implementierung Kapitel 3 Hauptteil Diplomarbeit - 82 -
Listing 3.20: commands.h: Rückgabestrings
1 IFX_char_t ∗Commands_GetErrorString(IFX_error_t e);
Eingabe • e ist der Rückgabewert.
Ausgabe • Rückgabestring oder NULL.
3.5.3 Control-PC Schnittstelle
3.5.3.1 TLV - Type Length Value
Die gesamte TLV-Funktionalität wurde modular und unabhängig von der Anwendung imple- mentiert. Sie kann also ohne Änderungen in anderer Software genutzt werden. Hierzu wird dem TLV-Code eine TLV-Tabelle übergeben, in der die einzelnen TLV-Blöcke be- schrieben sind. Aus dieser Tabelle liest der Code alle nötigen Daten um eine TLV-Nachricht zu lesen oder zu schreiben. Ein TLV-Block besteht aus folgender Struktur:
Listing 3.21: tlv.h: TLV-Block - Definition
1 typedef struct { 2 IFX_int_t type; 3 IFX_int_t length; 4 TLV_type_action_t action; 5 IFX_void_t ∗actionptr ; 6 IFX_char_t desc [TLV_TABLE_DESCRIPTION_LENGTH ] ; 7 } TLV_type_table_entry_t;
Die Type und Length Felder entsprechen den Feldern in 3.4.3.2 TLV - Type Length Value. Die restli- chen Felder werden nachfolgend erläutert: • action: Mit diesem Feld wird die Operation spezifiziert, die ausgeführt wird, wenn der korrespondierende Typ erkannt wurde:
Listing 3.22: tlv.h: TLV-Block - action-Feld
1 typedef enum { 2 TLV_NO_ACTION = 0 , /∗∗< encode : use p r o v i d e d value 3 decode : i g n o r e t h i s value ∗/ 4 TLV_READ_WRITE = 1 , /∗∗< allow read and w r i t e o p e r a t i o n s on the value ∗/ 5 TLV_READ = 2 , /∗∗< allow only read o p e r a t i o n s ∗/ 6 TLV_WRITE = 3 , /∗∗< allow only w r i t e o p e r a t i o n s ∗/ 7 TLV_CALL_FUNCTION = 4 /∗∗< c a l l a f u n c t i o n to en / decode the value ∗/ 8 } TLV_type_action_t;
• actionptr: Je nach Operation wird hiermit entweder ein Zeiger auf eine Variable oder eine TLV-C-Funktion angegeben. Eine Variable wird einfach gelesen oder geschrieben, während TLV-C-Funktionn aufgerufen werden. Eine TLV-C-Funktion ist folgendermaßen deklariert:
Listing 3.23: tlv.h: TLV-Block - TLV-C-Funktion
1 typedef IFX_error_t (∗IFX_TLV_function_t)(TLV_decode_encode_t mode, /∗∗< encode or decode the value ∗/ 2 TLV_type_table_entry_t ∗entry , /∗∗< t y p e e n t r y in decode t a b l e ∗/ 3 IFX_int_t ∗length , /∗∗< LENGTH o f the value ∗/ 4 IFX_void_t ∗value , /∗∗< VALUE ∗/ 5 IFX_void_t ∗arg /∗∗< u s e r argument ∗/ 6 ) ;
Die Parameter geben der TLV-C-Funktion jede Möglichkeit mit den TLV-Daten zu arbeiten:
Kapitel 3 Hauptteil 3.5 BorderGateway Software: Implementierung - 83 - Fachhochschule Hof
– mode signalisiert, ob der Code sich im Dekodier- oder Kodiermodus befindet. Je nachdem, in welchem Modus man sich befindet, müssen die Parameter length und value entweder gelesen (Dekodiermodus) oder geschrieben (Kodiermodus) werden. – entry ist der zu dem Typ korrespondierende Inhalt aus der TLV-Tabelle. – arg ist ein benutzerdefinierter Parameter, welcher von den folgenden beiden Funk- tionen übergeben wird. • desc: Dieses Feld dient der Identifikation des Blockes.
Die Grundfunktionalität ist durch folgende C-Funktionen gegeben. Beide besitzen den benut- zerdefinierten Parameter arg, welcher an aufgerufene TLV-C-Funktionen übergeben wird, und beide wandeln selbstständig zwischen Little und Big Endian um, siehe F.2 Bytereihenfolge (byte order).
Funktionsprototyp 2 (3.4.3.3 TLV-Block schreiben (Kodieren)) Diese Kodierfunktion schreibt genau einen TLV-Block in den vorgegebenen Puffer.
Listing 3.24: tlv.h: TLV-Block schreiben
1 IFX_error_t TLV_Encode_Block(IFX_int_t type, /∗ TYPE ∗/ 2 IFX_int_t length, /∗ LENGTH ∗/ 3 IFX_void_t ∗value , /∗ VALUE ∗/ 4 IFX_void_t ∗∗buffer , 5 IFX_int_t ∗buffersize , 6 IFX_void_t ∗arg /∗ u s e r argument ∗/ 7 ) ;
Eingabe • type, length und value entsprechen den TLV-Feldern. • buffer und buffersize beschreiben den Zielpuffer. • arg ist ein benutzerdefinierter Parameter, welcher an die aufgerufene TLV-C- Funktion übergeben wird.
Ausgabe • Einen Rückgabewert. • Die Parameter buffer und buffersize werden automatisch um die Größe des geschriebenen Blockes erweitert, falls kein Fehler aufgetreten ist.
Funktionsprototyp 3 (3.4.3.4 TLV-Block lesen (Dekodieren)) Diese Dekodierfunktion liest rekursiv alle TLV-Blöcke aus dem übergeben Puffer.
Listing 3.25: tlv.h: TLV-Block lesen
1 IFX_error_t TLV_Decode_Block(IFX_void_t ∗∗buffer , 2 IFX_int_t ∗buffersize , 3 IFX_void_t ∗arg /∗ u s e r argument ∗/ 4 ) ;
Eingabe • buffer und buffersize beschreiben den Quellpuffer. • arg ist ein benutzerdefinierter Parameter, welcher an die aufgerufene TLV-C- Funktion übergeben wird.
3.5 BorderGateway Software: Implementierung Kapitel 3 Hauptteil Diplomarbeit - 84 -
Ausgabe • Einen Rückgabewert. • Die Parameter buffer und buffersize werden automatisch um die Größe des gelesenen Blockes erweitert.
Hinweis(e) • Bei dem ersten Fehler wird die Operation abgebrochen.
3.5.3.2 TLV-Daten fur¨ die Control-PC Schnittstelle
Alle Werte in Tabelle 3.4 Control-PC ⇔ MPC-Modul TLV-Daten werden über TLV-C-Funktion deko- diert und interpretiert. Dies erlaubt u.a. die Überprüfung der übergebenen Werte, bevor weiter- gehende Operationen ausgeführt werden.
Ausnahme bilden hier die Werte 0x50-0x56. Sie werden direkt in globale Variablen gelesen und geschrieben.
Als benutzerdefinierten Parameter arg erhalten die C-Funktion folgende Struktur:
Listing 3.26: commands.h: Nachrichtenstruktur
1 typedef struct { 2 IFX_void_t ∗buf ; 3 IFX_void_t ∗buf_current; 4 IFX_int_t bufsize; 5 IFX_int_t bufsize_rest; 6 IFX_int_t timestamp; 7 IFX_int_t message; 8 IFX_error_t result; 9 IFX_char_t ∗custom_result_string; 10 BG_CTX_info_t ∗context ; 11 BG_CTX_TID_info_t ∗termination; 12 IFX_boolean_t termination_id_encode [CTX_MAX_TERMINATION_IDS] ; 13 IFX_boolean_t termination_id_decode [CTX_MAX_TERMINATION_IDS] ; 14 } BG_CMD_info_t ;
Diese Struktur speichert alle Daten, die spezifisch für eine Nachricht sind. Sie werden nur für einen De- und Kodiervorgang verwendet.
Es wird der eingehende Nachrichtenpuffer buf mit der Nachricht und dessen Größe bufsize ge- speichert. Da die (De)Kodierfunktionen automatisch übergebene Puffer- und Größenvariablen ändern, sind zwei temporäre Variablen mit in der Struktur enthalten (buf_current und bufsi- ze_rest).
Die folgenden Variablen speichern die Daten eines (De)Kodiervorgangs:
• timestamp enthält den Zeitstempel der Nachricht. • message speichert den Befehl der Nachricht, siehe Tabelle 3.5 Control-PC ⇔ MPC-Modul Be- fehle. • result speichert das Ergebnis mit dem dem Control-PC geantwortet wird. • custom_result_string erlaubt es der Software auch Ergebnisse zu schicken, die nicht in Listing 3.19 gespeichert sind, siehe Listing 3.18.
Kapitel 3 Hauptteil 3.5 BorderGateway Software: Implementierung - 85 - Fachhochschule Hof
• Die Zeiger context und termination zeigen entweder auf den aktuellen Kontext bzw. Half- call oder (im Fehlerfall) auf NULL. Dies ermöglicht den schnellen Zugriff in den TLV-C- Funktion ohne Überprüfung der Context ID bzw. Termination ID. • termination_id_encode bzw. termination_id_decode signalisieren dem Nachrichtencode welcher Halfcall bzw. welche Termination ID schon bearbeitet wurde. Die Daten, die sich auf den Halfcall bzw. den Kontext beziehen, müssen ebenfalls permanent ge- speichert werden. Hierzu wurden zwei weitere Strukturen definiert. Die erste Struktur speichert die Daten für einen Halfcall (Statistikfelder werden nicht aufgeführt):
Listing 3.27: context.h: Halfcall - Struktur
1 typedef struct { 2 IFX_int_t id; 3 IFX_ip_port_t local; 4 IFX_ip_port_t remote; 5 } BG_CTX_TID_info_t;
• id enthält die Termination ID des Halfcalls. • local/remote enthalten die lokale/remote IP-Adresse und den lokalen/remote UDP-Port.
Die zweite Struktur speichert die Daten für den gesamten Kontext:
Listing 3.28: context.h: Kontext - Struktur
1 typedef struct { 2 IFX_int_t id; 3 BG_CTX_TID_info_t termination_id [CTX_MAX_TERMINATION_IDS] ; 4 IFX_int_t qos_class; 5 IFX_int_t bandwidth; 6 } BG_CTX_info_t;
• id enthält die Context ID des gesamten Kontext. • termination_id enthält die beiden Halfcallstrukturen, siehe Listing 3.27. • qos_class/bandwidth speichern die Verbindungsqualität bzw. Bandbreite.
Siehe 3.4.3.5 TLV-Daten für die Control-PC Schnittstelle.
3.5.3.3 Behandlung von Nachrichten
Das Lesen von eingehenden Nachrichten ist mit der rekursiven TLV-Dekodierfunktion sehr ein- fach. Das Erstellen von Nachrichten an den Control-PC ist etwas aufwendiger. Um Nachrichten an den Control-PC zusammenzustellen, wurde eine Tabelle erstellt, welche jedem Befehl die nötigen Einträge zuordnet. Ein Eintrag in dieser Tabelle besteht aus folgenden Feldern:
Listing 3.29: commands_message_table.c: Nachrichtentabelle - Struktur
1 typedef struct { 2 IFX_int_t id; 3 IFX_char_t desc[32]; 4 IFX_char_t data[32]; 5 } BG_MSG_info_t;
• id enthält den Befehl der zu erstellenden Nachricht, siehe siehe Tabelle 3.5 Control- PC ⇔ MPC-Modul Befehle.
3.5 BorderGateway Software: Implementierung Kapitel 3 Hauptteil Diplomarbeit - 86 -
• desc dient zur Identifikation des Eintrages. • data speichert bis zu 32 TLV-Typen, die an die Nachricht angehängt werden, siehe Tabelle 3.4 Control-PC ⇔ MPC-Modul TLV-Daten.
Die Nachricht kann erstellt werden, indem der TLV-Kodierfunktion jeweils ein TLV-Typ aus data übergeben wird, bis data abgearbeitet wurde. Entscheidend hierbei ist das wirklich alle Typen bearbeitet werden, denn die letzten Parameter schreiben das Ergebnis (Rückgabewert und Rück- gabestring). Würde beim ersten Fehler abgebrochen, erhielte der Control-PC kein Resultat in der Antwort. Die jeweiligen Befehlsoperationen werden nach dem Dekodieren der eingehenden Nachricht und vor dem Kodieren der Antwort ausgeführt. Siehe 3.5.3.3.1 ADD_REQ, ADD_REP: Verbindung einrichten ff. Nachdem der Puffer geschrieben wurde, wird dieser via UDP-Paket an den Control- PC geschickt. Siehe 3.5.3.5 Nachrichten via UDP. In den nächsten Paragraphen werden die einzelnen Befehlsoperationen, die an sich schon sehr genau in der Spezifikation beschrieben sind, noch mit Details zur Implementierung ergänzt.
3.5.3.3.1 ADD REQ, ADD REP: Verbindung einrichten
Funktionsweise: 1. Die Liste der freien Kontexte wird auf Einträge überprüft, siehe 3.5.1.1 Listen. 2. Wenn noch freie Einträge vorhanden sind: a) Wenn die vorhandenen Halfcall Daten in Ordnung sind: i. Einen ARP-Request für den Teilnehmer A ausführen, siehe 3.5.6.2.2 Versenden eines ARP-Request. ii. Wenn die MAC-Adresse ermittelt werden konnte: A. Bereitstellen des Kontext, zweier Termination IDs und zweier UDP-Ports, sie- he 3.5.1.1 Listen. B. Schreiben des Vergleichsspeichers und der Weiterleitungstabelle, siehe 3.5.4.4 ConverGate-D - Dynamische Konfiguration. C. Speichern der Startzeit für diesen Halfcall, siehe 3.5.3.3.4 READ_STATUS_REQ, READ_STATUS_REP: Statistiken abrufen. 3. Operation beendet.
Siehe Abbildung 3.16 Befehl - ADD_REQ, 3.4.3.7.1 ADD_REQ (0x00): Verbindung einrichten und 3.4.3.7.2 ADD_REP (0x80): Antwort auf ADD_REQ.
3.5.3.3.2 SUBTRACT REQ, SUBTRACT REP: Verbindungen beenden
Funktionsweise: 1. Die Liste der benutzten Kontexte wird auf den spezifizierten Kontext hin überprüft, siehe 3.5.1.1 Listen. 2. Wenn der Kontext in der benutzten Liste steht:
Kapitel 3 Hauptteil 3.5 BorderGateway Software: Implementierung - 87 - Fachhochschule Hof
a) Löschen aller Halfcalls, die beim Lesen der Nachricht spezifiziert wurden. Wenn keine Halfcalls gelesen wurden, werden alle Halfcalls aus dem Kontext beendet. 3. Operation beendet.
Siehe Abbildung 3.17 Befehl - SUBTRACT_REQ, 3.4.3.7.3 SUBTRACT_REQ (0x01): Verbindungen beenden und 3.4.3.7.4 SUBTRACT_REP (0x81): Antwort auf SUBTRACT_REQ.
3.5.3.3.3 MODIFY REQ, MODIFY REP: Einzelne Verbindung einrichten
Funktionsweise: 1. Die Liste der benutzten Kontexte wird auf den spezifizierten Kontext hin überprüft, siehe 3.5.1.1 Listen. 2. Wenn der Kontext in der benutzten Liste steht: a) Wenn die vorhandenen Halfcall Daten in Ordnung sind: i. Einen ARP-Request für den Teilnehmer B ausführen, siehe 3.5.6.2.2 Versenden eines ARP-Request. ii. Wenn die MAC-Adresse ermittelt werden konnte: A. Schreiben des Vergleichsspeichers und der Weiterleitungstabelle, siehe 3.5.4.4 ConverGate-D - Dynamische Konfiguration. B. Speichern der Startzeit für diesen Halfcall, siehe 3.5.3.3.4 READ_STATUS_REQ, READ_STATUS_REP: Statistiken abrufen. 3. Operation beendet.
Siehe Abbildung 3.18 Befehl - MODIFY_REQ, 3.4.3.7.5 MODIFY_REQ (0x02): Einzelne Verbindung ein- richten und 3.4.3.7.6 MODIFY_REP (0x82): Antwort auf MODIFY_REQ.
3.5.3.3.4 READ STATUS REQ, READ STATUS REP: Statistiken abrufen
Funktionsweise: 1. Die Liste der benutzten Kontexte wird auf den spezifizierten Kontext hin überprüft, siehe 3.5.1.1 Listen. 2. Wenn der Kontext in der benutzten Liste steht: a) Wenn die vorhandenen Halfcall Daten in Ordnung sind: i. Rückgabe der Statistiken über eingehende und ausgehende Pakete für diesen Halfcall: die Statistiken sind in dieser prototypischen Version der BorderGate- way Software nicht korrekt implementiert und werden an dieser Stelle daher nicht weiter behandelt. ii. Rückgabe der Dauer des Halfcalls:
Siehe Abbildung 3.19 Befehl - READ_STATUS_REQ, 3.4.3.7.7 READ_STATUS_REQ (0x03): Statistiken abrufen und 3.4.3.7.8 READ_STATUS_REP (0x83): Antwort auf READ_STATUS_REQ.
3.5 BorderGateway Software: Implementierung Kapitel 3 Hauptteil Diplomarbeit - 88 -
3.5.3.3.5 CONFIG REQ, CONFIG REP: MPC-Modul konfigurieren Aufgrund der Funktionalität in 3.5.3.1 TLV - Type Length Value werden die übergebenen Daten direkt in die globalen Variablen der korrespondierenden Parameter beim Dekodieren der Nach- richt übertragen. Es benötigt also keiner besonderen Operation.
Siehe Abbildung 3.20 Befehl - CONFIG_REQ, 3.4.3.7.9 CONFIG_REQ (0x04): MPC-Modul konfigurieren und 3.4.3.7.10 CONFIG_REP (0x84): Antwort auf CONFIG_REP.
3.5.3.3.6 WAKE UP: Bereitschaft signalisieren Für diese Operation wird lediglich die IP-Adresse des MPC-Modul benötigt. Generell ist es sinn- voller, diese Adresse bereits beim Start der Software festzustellen. Weil zusätzlich beim Kodieren der Nachricht der Wert automatisch aus der korrespondierenden Variable gelesen wird, ist auch hier keine weitere Operation nötig.
Siehe Abbildung 3.21 Befehl - WAKE_UP und 3.4.3.7.11 WAKE_UP (0x85): Bereitschaft signalisieren.
3.5.3.3.7 FAULT: Fehler signalisieren Diese Funktion wurde in 3.5.3.4.2 Aus der Fehlerwarteschlange lesen integriert.
Siehe Abbildung 3.22 Befehl - FAULT und 3.4.3.7.12 FAULT (0x86): Fehler signalisieren.
3.5.3.4 Fehlerwarteschlange (Fault pipe)
Für die Implementierung der Fehlerwarteschlange wurde der sog. Pipe-Mechanismus48 verwen- det. Dieser Mechanismus erlaubt das Schreiben und Lesen in eine Datenstruktur innerhalb eines Pro- zesses nach dem FIFO49 -Prinzip. Genau genommen werden hier unbenannte Pipes 50 benutzt. Zugriff auf die Warteschlange ist über die C-Funktion write() und read() möglich. [3] Ein Eintrag in die Fehlerwarteschlange ist immer 32-Bit groß.
3.5.3.4.1 In die Fehlerwarteschlange schreiben
Funktionsprototyp 4 (3.4.3.8.1 In Fehlerwarteschlange (Fault pipe) schreiben) Schreiben in die Fehlerwarteschlange.
Listing 3.30: commands.h: In Fehlerwarteschlange schreiben
1 IFX_error_t Commands_Add_Fault(IFX_char_t ∗string , IFX_error_t error);
Eingabe • string ist der Rückgabestring oder NULL. • error ist der Rückgabewert.
48Pipe = Rohr 49First In First Out: Das Element, welches als erstes geschrieben wurde, wird auch wieder als erstes gelesen. 50unnamed pipes
Kapitel 3 Hauptteil 3.5 BorderGateway Software: Implementierung - 89 - Fachhochschule Hof
Ausgabe • Einen Rückgabewert.
Hinweis(e) • Wenn string NULL ist, wird error in die Fehlerwarteschlange geschrieben. • Wenn string nicht NULL ist, wird ein besonderer Rückgabewert in die Fehlerwarteschlange geschrieben, der einen nachfolgenden Rückgabestring signalisiert. Da alle Threads Zugriff auf die gleichen Systemresourcen haben, genügt es den Zeiger auf den String zu überge- ben. error wird dann ignoriert. • Übergebene Rückgabestrings müssen mit malloc() erstellt worden sein.
Funktionsweise: 1. Schreiben des Rückgabewertes. 2. Wenn es sich um einen besonderen Rückgabewert handelt: • Schreiben des Zeigers auf den Rückgabestring.
3.5.3.4.2 Aus der Fehlerwarteschlange lesen
Funktionsprototyp 5 (3.4.3.8.2 Aus Fehlerwarteschlange (Fault pipe) lesen) Lesen aus der Fehlerwarteschlange. Da nur an einer Stelle in der BorderGateway Software aus der Fehlerwarteschlange gelesen wird, wurde das Lesen der Warteschlange mit dem automati- schen Versenden der FAULT-Nachricht in eine C-Funktion gekapselt.
Listing 3.31: commands.h: Aus Fehlerwarteschlange lesen
1 IFX_int_t Commands_Handle_Errors(IFX_void_t);
Eingabe • -
Ausgabe • Einen Rückgabewert.
Hinweis(e) • Nachdem ein Eintrag komplett gelesen wurde, wird die FAULT-Nachricht generiert und via UDP versendet. • Nach dem Versand wird der Speicher gelesener Rückgabestrings freigegeben.
Funktionsweise: 1. Wenn Daten in der Fehlerwarteschlange stehen: a) Lesen des Rückgabewertes. b) Wenn es sich nicht um einen besonderen Rückgabewert handelt: i. Lesen des Strings aus der Liste der Rückgabestrings, siehe 3.5.2 Fehlerbehandlung. c) Wenn es sich um einen besonderen Rückgabewert handelt: i. Lesen des Zeigers auf den Rückgabestring.
3.5 BorderGateway Software: Implementierung Kapitel 3 Hauptteil Diplomarbeit - 90 -
d) Generieren und Versand der FAULT-Nachricht.
Siehe 3.4.3.7.12 FAULT (0x86): Fehler signalisieren.
3.5.3.5 Nachrichten via UDP
Die nächsten beiden Funktionen werden vom Betriebssystem auf einer höheren Stufe bereitge- stellt, so dass man sich hier nicht um den Aufbau des Paketes an sich kümmern muss. Über- geben bzw. empfangen wird hier nur der Payload eines UDP-Paketes (kein UDP-Header), siehe 3.4.6.6 UDP - User Datagram Protocol.
Funktionsprototyp 6 (3.4.3.9.1 Versenden von Nachrichten via UDP) Versenden eines UDP-Paketes via Betriebssystem.
Listing 3.32: udp_sockets.h: UDP-Paket versenden
1 IFX_error_t UDP_Send( IFX_IP_addr_t ip , 2 IFX_int16_t port, 3 IFX_int16_t portfrom, 4 IFX_void_t∗ buffer , 5 IFX_int_t bufsize);
Eingabe • ip ist die Ziel-IP-Adresse. • port ist der Ziel-UDP-Port. • portfrom ist der Quell-UDP-Port, von dem aus ein Paket verschickt werden soll. • buffer und bufsize beschreiben den Quellpuffer.
Ausgabe • Einen Rückgabewert.
Hinweis(e) • portfrom ist ein optionaler Parameter (Defaultwert = 0x1111).
Funktionsweise: [3] 1. Ein UDP-Socket öffnen. 2. Falls portfrom benutzt wird: a) Den UDP-Port in portfrom in lokale Socket-Adress-Struktur schreiben. b) Die lokale Socket-Adress-Struktur an geöffneten Socket binden. 3. Den UDP-Port in port und IP-Adresse in ip in remote Socket-Adress-Struktur schreiben. 4. Das UDP-Paket versenden. 5. Das UDP-Socket schließen.
Funktionsprototyp 7 (3.4.3.9.2 Erhalten von Nachrichten via UDP) Empfangen eines UDP-Paketes via Betriebssystem.
Kapitel 3 Hauptteil 3.5 BorderGateway Software: Implementierung - 91 - Fachhochschule Hof
Listing 3.33: udp_sockets.h: UDP-Paket empfangen
1 IFX_error_t UDP_Receive(IFX_IP_addr_t ip , 2 IFX_int16_t port, 3 IFX_void_t ∗buffer , 4 IFX_int_t bufsize, 5 IFX_int_t ∗recvsize , 6 IFX_boolean_tnonblocking);
Eingabe • ip ist die Quell-IP-Adresse. • port ist der Quell-UDP-Port, auf dem auf Daten gewartet wird. • buffer und bufsize beschreiben den Zielpuffer. • recvsize ist die Zielvariable für die Größe der empfangenen Daten. • nonblocking spezifiziert ob auf Daten gewartet werden soll.
Ausgabe • Einen Rückgabewert. • Den mit Daten gefüllten Zielpuffer. • Die Größe der empfangenen Daten.
Hinweis(e) • ip ist in der momentanen Implementierung unbenutzt.
Funktionsweise: [3] 1. Ein UDP-Socket öffnen. 2. Den UDP-Port in portfrom in lokale Socket-Adress-Struktur schreiben. 3. Die lokale Socket-Adress-Struktur an geöffneten Socket binden. 4. Auf ein remote UDP-Paket warten (unendlich oder zeitlich begrenzt). 5. Das UDP-Socket schließen.
3.5.4 ConverGate-D Schnittstelle
Zugriff auf die ConverGate-D-Hardware wird über den Linux Befehl ioctl() erlangt. Über diesen Befehl steht man in direktem Kontakt mit den Kernel-Treibern. [3]
Listing 3.34: Linux: ioctl()
1 #include
3 int ioctl(int d, int request, char ∗argp ) ;
• d ist ein offenes Gerät (Device). • request ist ein IOCTL-Code, der die Anfrage an den Treiber identifiziert. • argp übergibt einen Zeiger auf eine Variable, die je nach IOCTL-Code gelesen oder ge- schrieben wird.
3.5 BorderGateway Software: Implementierung Kapitel 3 Hauptteil Diplomarbeit - 92 -
In den nächsten Abschnitten wird zu den Funktionsprototypen jeweils das anzusprechende Gerät und die benötigten IOCTL-Codes aufgelistet. Die ConverGate-D-API (IOCTL-Code: FIO_CG_API) erwartet Ein- und Ausgabeparameter in Strukturen. Diese Strukturen sowie ConverGate-D-Konstanten und Definitionen sind in der Hea- derdatei drv_cg/src/drv_cg_interface.h definiert. [5]
3.5.4.1 ConverGate-D Evaluation Board
Die nächsten beiden C-Funktion sind äußerst einfach und werden daher nicht näher erklärt. Zugriff auf die ConverGate-D Evaluation Board Hardware erlangt man über das Gerät /de- v/cg_eb/0 auf dem MPC-Modul.
Funktionsprototyp 8 (3.4.4.1.1 User DIP Switches lesen) Listing 3.35: evalboard.h: DIP-Switches lesen
1 IFX_error_t EB_Get_DIP(IFX_uint32_t ∗dip ) ;
Eingabe • dip ist ein Zeiger auf den Zielpuffer.
Ausgabe • Einen Rückgabewert. • Status der DIP-Schalter in den Bits 0-7.
Hinweis(e) • IOCTL-Code: FIO_CG_EB_GET_DIP [5].
Funktionsprototyp 9 (3.4.4.1.2 User LEDs schreiben) Listing 3.36: evalboard.h: User-LEDs schreiben
1 IFX_error_t EB_Set_LED(IFX_int_t led, IFX_onoff_t onoff);
Eingabe • led enthält die LED-Position (0-7). • onoff signalisiert den neuen Zustand der LED: 0 = Aus, 1 = An.
Ausgabe • Einen Rückgabewert.
Hinweis(e) • IOCTL-Code: FIO_CG_EB_SET_LED [5].
3.5.4.2 ConverGate-D - Paketbehandlung
Dieser Abschnitt erläutert die Implementierung des Zugriffs auf die ConverGate-D-Ports. Den Zugriff auf die ConverGate-D Ports erlangt man über die Geräte /dev/cg/0/pegress und /de- v/cg/0/pingress auf dem MPC-Modul. Die Pakete kann man mit den C-Befehlen write() und read() über o.g. Geräte entnehmen bzw. einfügen.
Kapitel 3 Hauptteil 3.5 BorderGateway Software: Implementierung - 93 - Fachhochschule Hof
Wie in Tabelle 3.7 ConverGate-D Egress Header spezifiziert, werden verschiedene Header benötigt, um Pakete an den ConverGate-D-Treiber zu übergeben bzw. vom Treiber entnommene Pakete zu interpretieren. Der Autor hat zur Vereinfachung und Kapselung einen einzigen Datentyp erstellt, der nicht nur die ConverGate-D-spezifischen Header, sondern auch die verschiedenen Netzwerk- protokolle in sich vereint. Dieser Datentyp wird von hier an ConverGate-D-Paket genannt:
Listing 3.37: packet.h: ConverGate-D-Paket
1 typedef union 2 { 3 CG_Packet_t erecvpkt; 4 CMD_CG_PH_PacketEgressSend_t esendpkt; 5 s t r u c t 6 { 7 CG_PacketDescr_t hdr; 8 IFX_payload_t payload; 9 } PACKED erecv ; 10 s t r u c t 11 { 12 IFX_uint8_t hdr[sizeof(CMD_CG_PH_PacketEgressSend_t) − MAX_PAYLOAD_SIZE] ; 13 IFX_payload_t payload; 14 } PACKED esend ; 15 } PACKED IFX_packet_t;
• erecvpkt und esendpkt sind jeweils das komplette Paket für Sende- und Empfangsrich- tung für den ConverGate-D-Treiber: ConverGate-D-Header + Payload. Payload ist in die- sem Fall das Netzwerkpaket, beginnend mit Ethernet. • Die Strukturen erecv und esend sind die wichtigen Bestandteile dieses Datentyps, denn diese ermöglichen den getrennten Zugriff auf die verschiedenen ConverGate-D- Paketheader und die Daten der Netzwerkpakete über hdr bzw. payload.
Die Typdefinition als union stellt sicher, dass das ConverGate-D-Paket die Größe des größten gekapselten Datentyps hat. Alle vier gekapselten Datentypen beginnen jeweils an Position 0 im Speicher. In dem Payloaddatentyp stecken, ebenfalls wieder ineinander gekapselt, die einzel- nen Netzwerkdatentypen. Prinzipiell könnte dieser Datentyp auch als Ethernetpaket bezeichnet werden:
Listing 3.38: packet.h: Payloaddatentyp
1 typedef struct 2 { 3 IFX_eth_protocol_t eth; 4 union 5 { 6 IFX_uint8_t minsize[ETH_ZLEN−sizeof(struct ethhdr)]; 7 IFX_arp_protocol_t arp; 8 IFX_ip_protocol_t ip; 9 } PACKED ethprot ; 10 } PACKED IFX_payload_t;
• eth beinhaltet die Ethernet-spezifischen Paketdaten. • arp und ip hängen an das Ethernetpaket ihre protokollspezifischen Daten an.
In dieser Struktur wurden die auf Ethernet basierenden Protokolle wieder als union definiert. Somit beginnen alle Datentypen in ethprot am Ende des Ethernetpaketes. Hier ein beispielhafter Zugriff auf das Ethernetprotokoll, welches für das Versenden vorbereitet wird:
Listing 3.39: packet.h: Beispielzugriff auf Ethernet-Header
1 IFX_packet_t packet; 2 packet.esend.payload.eth.hdr.ar_op = ARPOP_REQUEST;
3.5 BorderGateway Software: Implementierung Kapitel 3 Hauptteil Diplomarbeit - 94 -
Analog zu diesem Datentyp wurden die Datentypen für ARP, IP, ICMP und UDP-Pakete defi- niert.
3.5.4.2.1 ConverGate-D Receive-Thread Da nur an einer Stelle im System Pakete vom ConverGate-D-Treiber gelesen werden können, wurde ein Thread implementiert, der ConverGate-D-Paket liest und die eingegangenen Pakete weiterverarbeitet. Der Ablauf dieses Threads lässt sich so darstellen: 1. Warten auf eingehende Daten über den Egress-Port mit poll(). Siehe Fehlerbeschreibung 2 ConverGate-D Linux Kernel Treiber: drv_cg, v3.2.5. 2. Lesen der Daten in ein ConverGate-D-Paket mit read(). 3. Falls es sich um ein ARP, ICMP oder SIP-Paket handelt: • ARP: Siehe Spezifikation 3.4.6.2.1 Antwort auf einen ARP-Request und 3.4.6.2.2 Versenden eines ARP-Request sowie Implementierung 3.5.6.2 ARP - Address Resolution Protocol. • ICMP: Siehe Spezifikation 3.4.6.5 ICMP - Internet Control Message Protocol und Imple- mentierung 3.5.6.5 ICMP - Internet Control Message Protocol. • SIP: Siehe Spezifikation 3.4.6.7 SIP - Session Initiation Protocol und Implementierung 3.5.6.7 SIP - Session Initiation Protocol. 4. Zurück zu 1.
Funktionsprototyp 10 (3.4.4.2.1 Egress-Port lesen) Listing 3.40: convergate.c: Egress-Port lesen
1 static IFX_int_t CG_Receive_Thread(IFX_void_t ∗arg )
Eingabe • -
Ausgabe • Einen Rückgabewert.
Hinweis(e) • Für die Felder des Egress-Receive-Headers siehe Tabelle 3.7 ConverGate-D Egress Header. • arg wird an jeden Thread übergeben, wird aber in diesem Thread nicht benötigt und daher ignoriert.
3.5.4.2.2 ConverGate-D-Paket versenden
Funktionsprototyp 11 (3.4.4.2.2 Egress-Port schreiben) Diese C-Funktion schreibt ein ConverGate-D-Paket an den Egress-Port.
Listing 3.41: convergate.c: Egress-Port schreiben
1 static IFX_error_t CG_Send_Packet(const IFX_char_t ∗name, const IFX_packet_t ∗pkt )
Eingabe • name sollte die aufrufende C-Funktion identifizieren, um Fehler besser zuordnen zu kön- nen.
Kapitel 3 Hauptteil 3.5 BorderGateway Software: Implementierung - 95 - Fachhochschule Hof
• pkt ist das zu versendende ConverGate-D-Paket.
Ausgabe • Einen Rückgabewert.
Hinweis(e) • Für die Felder des Egress-Send-Headers siehe Tabelle 3.7 ConverGate-D Egress Header. • Siehe Fehlerbeschreibung 3 ConverGate-D Linux Kernel Treiber: drv_cg, v3.2.5.
3.5.4.3 ConverGate-D - Statische Konfiguration
Zugriff auf die ConverGate-D-Kontrollschnittstelle erlangt man über das Gerät /de- v/cg/0/ctrl.
Wie in 3.4.4.3.2 Firmware übertragen beschrieben wurde, kann die Firmware während der Konfi- guration mit übertragen werden. Daher sind beide Funktionen in einer C-Funktionenthalten.
Funktionsprototyp 12 (3.4.4.3.1 WinEASY-Konfiguration schreiben) Funktionsprototyp 13 (3.4.4.3.2 Firmware übertragen) Diese C-Funktion liest die binäre Konfigurationsdatei und schickt die Konfigurationsdaten an den Linux-Kernel-Treiber.
Listing 3.42: convergate.h: WinEASY-Konfiguration schreiben
1 IFX_error_t CG_Set_Configuration(IFX_void_t);
Eingabe • -
Ausgabe • Einen Rückgabewert.
Hinweis(e) • IOCTL-Code: FIO_CG_API [5]. Der Wert ist gleich für alle Nachrichten an den Kernel- Treiber. • Sub-IOCTL-Code: Je nach gelesenem Konfigurationspaket. • Im Fehlerfall muss das Programm beendet werden.
Funktionsweise: 1. Öffnen der Konfigurationsdatei. 2. Solange Daten aus der Datei gelesen werden können: a) Lesen einer Nachricht. b) Wenn es sich bei der Nachricht um den Basic Device Init-Befehl handelt (Sub-IOCTL- Code: CG_BASIC_DEVICEINIT [5]): i. Öffnen und laden der Firmware. ii. Abändern von Übergabeparametern damit die neue Firmware vom Treiber gela- den wird.
3.5 BorderGateway Software: Implementierung Kapitel 3 Hauptteil Diplomarbeit - 96 -
c) Übertragen der Nachricht an den Treiber. 3. Schließen der Konfigurationsdatei.
Siehe 3.5.5 Binärer Dateizugriff (BCFA).
Funktionsprototyp 14 (3.4.4.3.3 MAC-Adresse setzen) Diese C-Funktion muss nur aufgerufen werden, wenn noch keine MAC-Adresse in der WinEASY- Konfiguration gesetzt wurde, siehe nächsten Funktionsprototyp.
Listing 3.43: convergate.c: MAC-Adresse setzen
1 static IFX_error_t CG_Set_MAC_Address(const IFX_char_t ∗buf, IFX_int_t bufsize)
Eingabe • buf und bufsize beschreiben den Quellpuffer.
Ausgabe • Einen Rückgabewert.
Hinweis(e) • IOCTL-Code: FIO_CG_API [5]. • Sub-IOCTL-Code: CG_GLOBAL_DEVICEMAC_SET [5]. • Der Parameter bufsize muss mindestens 6 Byte groß sein.
Funktionsprototyp 15 (3.4.4.3.4 MAC-Adresse lesen) Mit dieser C-Funktion kann die ConverGate-D-MAC-Adresse ausgelesen werden.
Listing 3.44: convergate.c: MAC-Adresse lesen
1 static IFX_error_t CG_Get_MAC_Address(IFX_char_t ∗buf, IFX_int_t bufsize)
Eingabe • buf und bufsize beschreiben den Zielpuffer.
Ausgabe • Einen Rückgabewert. • Den gefüllten Zielpuffer.
Hinweis(e) • IOCTL-Code: FIO_CG_API [5]. • Sub-IOCTL-Code: CG_GLOBAL_DEVICEMAC_GET [5]. • Der Parameter bufsize muss mindestens 6 Byte groß sein. • Die Werte FF:FF:FF:FF:FF:FF bzw. 00:00:00:00:00:00 signalisieren eine ungültige oder noch nicht konfigurierte MAC-Adresse.
Kapitel 3 Hauptteil 3.5 BorderGateway Software: Implementierung - 97 - Fachhochschule Hof
3.5.4.4 ConverGate-D - Dynamische Konfiguration
3.5.4.4.1 Vergleichsspeicher (BCAM) Die nächsten Prototypen behandeln den Vergleichsspeicher (BCAM).
Funktionsprototyp 16 (3.4.4.4.1 Vergleichsspeicher (BCAM) füllen) Diese C-Funktion schreibt einen Eintrag in den Vergleichsspeicher.
Listing 3.45: convergate.c: Vergleichsspeicher (BCAM) schreiben
1 static IFX_error_t CG_BCAM_Write(IFX_uint16_t tableidx , 2 IFX_IP_addr_tip, 3 IFX_uint16_tudp, 4 IFX_MAC_addr_t ∗mac 5 )
Eingabe • tableidx ist der Index in den Vergleichsspeicher [tableEntryId, index]. • ip und udp sind die Werte, die in den Vergleichsspeicher geschrieben werden [BCAM_entry]. • Der Parameter mac dient dazu auch die alte Firmware mit MAC und UDP-Zuordnung zu unterstützen. Dies war äußerst hilfreich in den Anfangs- und Testphasen, als die neue Firmware noch nicht getestet war. Siehe auch 3.2.1.1 Firmware.
Ausgabe • Einen Rückgabewert. • Den gefüllten Zielpuffer.
Hinweis(e) • IOCTL-Code: FIO_CG_API [5]. • Sub-IOCTL-Code: CG_CE_BCAM_ENTRYDIRECTADD [5]. • Folgende Strukturfelder des API-Befehls sind für alle Einträge gleich: – [explicitEnable] = True – [limitEnable] = False – [staticFlag] = True – [agingTimerId] = 0 • Layout eines Eintrags im Vergleichsspeicher [BCAM_entry]:
Tab. 3.19: IP/UDP Eintrag im Vergleichsspeicher Bits 63-48 47-16 15-0 Wert 0
Tab. 3.20: UDP/MAC Eintrag im Vergleichsspeicher Bits 63-48 47-0 Wert
3.5 BorderGateway Software: Implementierung Kapitel 3 Hauptteil Diplomarbeit - 98 -
Funktionsprototyp 17 (3.4.4.4.2 Vergleichsspeicher (BCAM) lesen) Diese C-Funktion liest einen Eintrag aus dem Vergleichsspeicher.
Listing 3.46: convergate.c: Vergleichsspeicher (BCAM) lesen
1 static IFX_error_t CG_BCAM_Read(IFX_uint16_t tableidx , 2 IFX_IP_addr_t ∗ip , 3 IFX_uint16_t ∗udp 4 )
Eingabe • tableidx ist der Index in den Vergleichsspeicher [tableEntryId]. • ip und udp sind Zielpuffer [BCAM_entry].
Ausgabe • Einen Rückgabewert. • Die gefüllten Zielpuffer [BCAM_entry].
Hinweis(e) • IOCTL-Code: FIO_CG_API [5]. • Sub-IOCTL-Code: CG_CE_BCAM_ENTRYDIRECTQUERY [5].
Funktionsprototyp 18 (3.4.4.4.3 Vergleichsspeicher (BCAM) löschen) Diese C-Funktion löscht einen Eintrag aus dem Vergleichsspeicher.
Listing 3.47: convergate.c: Vergleichsspeicher (BCAM) löschen
1 static IFX_error_t CG_BCAM_Delete(IFX_uint16_t tableidx)
Eingabe • tableidx ist der Index in den Vergleichsspeicher [tableEntryId].
Ausgabe • Einen Rückgabewert.
Hinweis(e) • IOCTL-Code: FIO_CG_API [5]. • Sub-IOCTL-Code: CG_CE_BCAM_ENTRYDIRECTDELETE [5].
3.5.4.4.2 Weiterleitungstabelle (FIB) Mit den folgenden Prototypen wird die Weiterleitungstabelle (FIB) konfiguriert.
Funktionsprototyp 19 (3.4.4.4.4 Weiterleitungstabelle (FIB) füllen) Funktionsprototyp 20 (3.4.4.4.5 Weiterleitungstabelle (FIB) löschen) Diese C-Funktion schreibt einen Eintrag in die Weiterleitungstabelle.
Listing 3.48: convergate.c: Weiterleitungstabelle schreiben
1 static IFX_error_t CG_CRLT_Write(IFX_uint16_t tableidx , 2 IFX_uint8_t CRLT_index, 3 IFX_void_t ∗value 4 )
Kapitel 3 Hauptteil 3.5 BorderGateway Software: Implementierung - 99 - Fachhochschule Hof
Eingabe • tableidx ist der Index in die Weiterleitungstabelle [index]. • CRLT_index ist der Index des Wertes [CRLT_index]. Siehe Tabelle 3.21 Einträge in Weiterlei- tungstabelle). • value ist der zu schreibende Wert [Siehe Variable in Tabelle 3.21 Einträge in Weiterleitungs- tabelle].
Ausgabe • Einen Rückgabewert.
Hinweis(e) • IOCTL-Code: FIO_CG_API [5]. • Sub-IOCTL-Code: Siehe Tabelle 3.21 Einträge in Weiterleitungstabelle. • Anhand des übergebenen CRLT_index werden die passenden Strukturen gewählt und ge- füllt. Der Benutzer muss nur den richtigen Wert zu dem CRLT_index übergeben. • Um Einträge zu löschen wird in value 0 übergeben. • Übersicht der Einträge in die Weiterleitungstabelle: Siehe Abbildung 3.23 BorderGateway -
Tab. 3.21: Einträge in Weiterleitungstabelle Wert Bit Sub-IOCTL: CG_UC_FWD_FIB_ ... CRLT Index Variable LPort 16 ... LPORTQUERY 11 lport Remote MAC 48 ... MACDA_QUERY 12 MACDA ConverGate-D MAC 48 ... MACSA_QUERY 14 MACSA ConverGate-D IP 32 ... VALUE_QUERY 16 value Remote IP 32 ... VALUE_QUERY 17 value ConverGate-D UDP 16 ... VALUE_QUERY 18 value Remote UDP 16 ... VALUE_QUERY 19 value
Media Stream Switching (downstream). • Im Fall von CG_UC_FWD_FIB_VALUE_QUERY muss zusätzlich die Größe des Wertes in Bit in der Struktur gefüllt werden [value_size].
3.5.5 Bin¨arer Dateizugriff (BCFA)
3.5.5.1 Header / Dateivorspann
Der Header für die binäre Konfigurationsdatei wurde so definiert:
Listing 3.49: bcfa.h: BCFA - Header
1 typedef struct 2 { 3 IFX_char_t id [ s i z e o f (BCFA_HEADER_ID) ] ; 4 IFX_uint32_t blocksize; 5 } BCFA_header_t;
• id dient der Identifikation der Datei. • blocksize dient der Überprüfung der Datei.
3.5 BorderGateway Software: Implementierung Kapitel 3 Hauptteil Diplomarbeit - 100 -
Für Einzelheiten siehe 3.4.5.1 Header / Dateivorspann.
3.5.5.2 Dateizugriff
Funktionsprototyp 21 (3.4.5.2 BCFA - Datei öffnen) Funktionsprototyp 22 (3.4.5.3 BCFA - Datei schließen) Funktionsprototyp 23 (3.4.5.4 BCFA - Datei schreiben) Funktionsprototyp 24 (3.4.5.5 BCFA - Datei lesen) Für die Implementierung dieser Funktionen hat sich der Autor entschieden, eine einzige C- Funktion zu entwickeln, die möglichst einfachen Zugriff auf binäre Dateien ermöglicht.
Listing 3.50: bcfa.h: BCFA - Dateizugriff
1 IFX_error_t BCFA_FileAccess( 2 BCFA_binary_config_file_access_tbcfat, 3 IFX_void_t ∗data , 4 IFX_int32_tdatasize 5 ) ;
Eingabe • bcfat definiert die Operation, siehe Listing 3.51. • data ist der Quell- bzw. Zielpuffer, je nach Operation. • datasize ist die Größe von data.
Ausgabe • Einen Rückgabewert. • Einen gefüllten Zielpuffer bei Lesezugriff.
Hinweis(e) • Übersicht über die BCFA-Operationen:
Listing 3.51: bcfa.h: BCFA - Operationskonstanten
1 typedef enum 2 { 3 BCFA_OPEN = 1 , /∗∗< can be combined with READ or WRITE ∗/ 4 BCFA_CLOSE = 2 , /∗∗< s i g n a l c l o s i n g o f f i l e ∗/ 5 BCFA_WRITE = 4 , /∗∗< s i g n a l w r i t e a c c e s s ∗/ 6 BCFA_READ = 8 , /∗∗< s i g n a l read a c c e s s ∗/ 7 BCFA_SHOW_PROGRESS = 16 , /∗∗< show p r o g r e s s , can be combined with READ or WRITE ∗/ 8 BCFA_GET_STATE = 32 /∗∗< r e t u r n s IFX_SUCCESS i f ready to read / w r i t e ∗/ 9 } BCFA_binary_config_file_access_t;
Die Felder BCFA_OPEN, BCFA_CLOSE, BCFA_WRITE und BCFA_READ entsprechen den spezifizierten Funktionsbeschreibungen. BCFA_PROGRESS kann mit BCFA_WRITE und BCFA_READ (durch eine Oder-Verknüpfung) kombiniert werden, um einen Vorgangsfort- schritt auszugeben. BCFA_GET_STATE liefert Information darüber, ob die Datei geöffnet und damit les- oder schreibbar ist.
3.5.6 Netzwerkpakete
Die Implementierung der Netzwerkfunktionen war nicht so aufwendig wie erwartet, denn der Linux Quellcode beinhaltet bereits für alle üblichen und in der Diplomarbeit benötigten Proto- kolle Headerdateien mit Definitionen und Konstanten.
Kapitel 3 Hauptteil 3.5 BorderGateway Software: Implementierung - 101 - Fachhochschule Hof
Da das MPC-Modul bereits im Big-Endian-Format arbeitet, muss die BorderGateway Softwa- re keine Umwandlung von IP-Adresse und UDP-Ports vornehmen. Siehe F.2 Bytereihenfolge (byte order).
3.5.6.1 Ethernet
Der Ethernet-Header ist implizit für jedes Netzwerkpaket zu erstellen. Darauf wird im Folgenden nicht mehr hingewiesen.
Konstanten und Definitionen für dieses Protokoll können über #include
Funktionsprototyp 25 (3.4.6.1 Ethernet) Schreiben eines Ethernet Headers.
Listing 3.52: eth.h: Ethernet-Header schreiben
1 IFX_error_t ETH_Header_Create(struct ethhdr ∗eth , 2 IFX_uint16_tprotocol, 3 constIFX_MAC_addr_t ∗smac , 4 constIFX_MAC_addr_t ∗tmac 5 ) ;
Eingabe • eth ist der zu füllende Ethernet-Header, siehe Tabelle 3.9 Ethernet II Header. • protocol beschreibt die Daten nach dem Header, siehe Tabelle 3.10 Ethernet Protokoll Typen. • smac und tmac zeigen auf die Quell- und Ziel-MAC-Adresse.
Ausgabe • Einen Rückgabewert. • Den gefüllten Header.
3.5.6.2 ARP - Address Resolution Protocol
Konstanten und Definitionen für dieses Protokoll können über #include
Funktionsprototyp 26 (3.4.6.2 ARP - Address Resolution Protocol) Schreiben eines ARP-Headers. Hier wurden für die Replies und Requests einzelne C- Funktionen implementiert. Implizit wird der nötige ARP-Befehlscode geschrieben.
Listing 3.53: arp.h: ARP-Request-Header schreiben
1 IFX_error_t ARP_Request_Create(struct arphdr ∗arp , 2 IFX_MAC_addr_t ∗smac , 3 IFX_IP_addr_tsip, 4 IFX_MAC_addr_t ∗tmac , 5 IFX_IP_addr_ttip 6 ) ;
3.5 BorderGateway Software: Implementierung Kapitel 3 Hauptteil Diplomarbeit - 102 -
Listing 3.54: arp.h: ARP-Reply-Header schreiben
1 IFX_error_t ARP_Reply_Create(struct arphdr ∗arp , 2 IFX_MAC_addr_t ∗smac , 3 IFX_IP_addr_tsip, 4 IFX_MAC_addr_t ∗tmac , 5 IFX_IP_addr_ttip 6 ) ;
Eingabe • arp ist der zu füllende ARP-Header, siehe Tabelle 3.11 ARP-Paket. • smac und tmac zeigen auf die Quell- und Ziel-MAC-Adresse [sha, tha]. • sip und tip enthalten die Quell- und Ziel-IP-Adresse [spa, tpa].
Ausgabe • Einen Rückgabewert. • Das gefüllte Paket in arp.
Hinweis(e) • Die ARP-Reply-Funktion ruft intern die ARP-Request-Funktion auf und ändert danach nur den ARP-Befehlscode.
3.5.6.2.1 Antwort auf einen ARP-Request Die Antwort auf einen ARP-Request ist sehr einfach und ist genau in 3.4.6.2.1 Antwort auf einen ARP-Request beschrieben.
Funktionsprototyp 27 (3.4.6.2.1 Antwort auf einen ARP-Request) Antwort auf einen ARP-Request.
Listing 3.55: convergate.h: ARP-Request beantworten
1 IFX_error_t CG_Send_ARP_Reply(const struct arphdr ∗arp ) ;
Eingabe • arp ist der eingegangene ARP-Request, siehe Tabelle 3.11 ARP-Paket.
Ausgabe • Einen Rückgabewert.
3.5.6.2.2 Versenden eines ARP-Request Die Funktionsweise der nächsten beiden C-Funktion ist ebenfalls genau in 3.4.6.2.3 Versenden vieler/paralleler ARP-Requests beschrieben.
Funktionsprototyp 28 (3.4.6.2.3 ARP-Request senden) Senden eines ARP-Requests.
Listing 3.56: convergate.h: ARP-Request senden
1 IFX_error_t CG_Send_ARP_Request(IFX_IP_addr_t sip , IFX_IP_addr_t tip , IFX_MAC_addr_t ∗tmac) ;
Eingabe • sip und tip enthalten die Quell- und Ziel-IP-Adresse.
Kapitel 3 Hauptteil 3.5 BorderGateway Software: Implementierung - 103 - Fachhochschule Hof
• tmac zeigt auf die Ziel-MAC-Adresse.
Ausgabe • Einen Rückgabewert. • Die ermittelte MAC-Adresse.
Hinweis(e) • Der Aufruf geschieht durch den Thread, der eine MAC-Adresse benötigt. • Der komplette Aufbau und Versand des ARP-Paketes wird implizit in dieser C- Funktion durchgeführt.
Funktionsprototyp 29 (3.4.6.2.3 ARP-Replies verarbeiten) Verarbeiten eines ARP-Replies.
Listing 3.57: arp.h: ARP-Reply verarbeiten
1 IFX_error_t ARP_Reply_Check(const struct arphdr ∗arp ) ;
Eingabe • arp ist der eingegangene ARP-Reply, siehe Tabelle 3.11 ARP-Paket.
Ausgabe • Einen Rückgabewert. • MAC-Adresse und Signal an den wartenden Thread bei Erfolg.
Hinweis(e) • Der Aufruf geschieht durch den Thread der die ConverGate-D-Pakete empfängt.
3.5.6.3 IP - Internet Protocol (v4)
Konstanten und Definitionen können über #include
Funktionsprototyp 30 (3.4.6.3 IP - Internet Protocol (v4)) Aufbau eines IP-Header.
Listing 3.58: ip.h: IP-Header schreiben
1 IFX_error_t IP_Header_Create(struct iphdr ∗hdr , 2 IFX_uint8_tprotocol, 3 IFX_IP_addr_tsip, 4 IFX_IP_addr_ttip, 5 IFX_uint16_tdatasize 6 ) ;
Eingabe • hdr ist der IP-Header, der beschrieben werden soll, siehe Tabelle 3.13 IP-Header. • protocol ist der IP-Protokoll-Typ [protocol], siehe Tabelle 3.14 IP-Protokoll-Typen. • sip und tip enthalten die Quell- und Ziel-IP-Adresse[saddr, daddr]. • datasize spezifiziert die Größe des IP-Payload.
3.5 BorderGateway Software: Implementierung Kapitel 3 Hauptteil Diplomarbeit - 104 -
Ausgabe • Einen Rückgabewert. • Den gefüllten IP-Header.
3.5.6.4 IP in IP
Für dieses Protokoll gibt es keine Linux-Include-Datei.
Da das Ein- und Auspacken von IP-Paketen nur für SIP-Pakete nötig ist, wurde diese Funktiona- lität in den SIP-Code gepackt. Beide C-Funktion arbeiten nach [4] und [1].
Siehe 3.4.6.4 IP in IP, 3.4.6.7 SIP - Session Initiation Protocol und 3.5.6.7 SIP - Session Initiation Protocol.
Funktionsprototyp 31 (3.4.6.4.1 IP in IP einpacken (encapsulation)) Einpacken eines IP-Paketes (SIP).
Listing 3.59: sip.h: SIP-Paket einpacken
1 IFX_error_t SIP_Encapsulate(const IFX_payload_t ∗spkt , IFX_payload_t ∗tpkt ) ;
Eingabe • spkt und tpkt sind das Quell- und das Ziel-Netzwerkpaket, siehe 3.5.4.2 ConverGate-D - Paketbehandlung.
Ausgabe • Einen Rückgabewert. • Das gefüllte Netzwerkpaket in tpkt.
Siehe 3.4.6.7.1 SIP-Pakete an der A-Seite.
Funktionsprototyp 32 (3.4.6.4.2 IP in IP auspacken (decapsulation)) Auspacken eines IP-Paketes (SIP).
Listing 3.60: sip.h: SIP-Paket auspacken
1 IFX_error_t SIP_Decapsulate(const IFX_payload_t ∗spkt , IFX_payload_t ∗tpkt ) ;
Eingabe • spkt und tpkt sind das Quell- und das Ziel-Netzwerkpaket.
Ausgabe • Einen Rückgabewert. • Das gefüllte Netzwerkpaket in tpkt.
Siehe 3.4.6.7.2 SIP-Pakete an der B-Seite.
Kapitel 3 Hauptteil 3.5 BorderGateway Software: Implementierung - 105 - Fachhochschule Hof
3.5.6.5 ICMP - Internet Control Message Protocol
Konstanten und Definitionen für dieses Protokoll können über #include
Funktionsprototyp 33 (3.4.6.5 ICMP - Internet Control Message Protocol) Aufbau eines ICMP-Paketes.
Listing 3.61: icmp.h: Aufbau eines ICMP-Paketes
1 IFX_error_t ICMP_Echo_Reply_Create(IFX_icmp_protocol_t ∗ticmp , 2 constIFX_icmp_protocol_t ∗sicmp 3 ) ;
Eingabe • sicmp und ticmp sind der Quell- und Ziel-ICMP-Header, siehe Tabelle 3.15 ICMP-Echo-Reply- Header.
Ausgabe • Einen Rückgabewert. • Das gefüllte Netzwerkpaket in tpkt.
3.5.6.6 UDP - User Datagram Protocol
Konstanten und Definitionen für dieses Protokoll können über #include
Funktionsprototyp 34 (3.4.6.6 UDP - User Datagram Protocol) Aufbau eines UDP-Paketes.
Listing 3.62: udp.h: Aufbau eines UDP-Paketes
1 IFX_error_t UDP_Header_Create(IFX_udp_protocol_t ∗udp , 2 conststructiphdr ∗iphdr , 3 IFX_uint16_t source, 4 IFX_uint16_t destination, 5 IFX_uint16_t length 6 ) ;
Eingabe • udp zeigt auf das UDP-Paket, das geschrieben werden soll, siehe Tabelle 3.17 UDP-Header. • iphdr zeigt auf den IP-Header, der dem UDP-Paket voransteht, siehe Tabelle 3.13 IP-Header. • source und destination sind der Quell- und Ziel-UDP-Port [Source Port, Destination Port]. • length ist die Gesamtlänge des UDP-Paketes [Length].
Ausgabe • Einen Rückgabewert. • Das gefüllte UDP-Netzwerkpaket in udp.
Hinweis(e) • Die benötigte Struktur zur Berechnung der UDP-Prüfsumme wurde folgendermaßen defi- niert:
3.5 BorderGateway Software: Implementierung Kapitel 3 Hauptteil Diplomarbeit - 106 -
Listing 3.63: packet.h: UDP-Prüfsummenstruktur
1 typedef struct 2 { 3 s t r u c t 4 { 5 IFX_IP_addr_t saddr, 6 daddr ; 7 IFX_uint8_t dummy, 8 protocol ; 9 IFX_uint16_t length; 10 } PACKED ip ; 11 IFX_udp_protocol_t udp; 12 } PACKED IFX_udp_checksum_protocol_t;
Siehe Tabelle 3.18 UDP-Checksum-Header.
3.5.6.7 SIP - Session Initiation Protocol
Auch für dieses Protokoll gibt es keine Linux-Include-Datei.
Funktionsprototyp 35 (3.4.6.7 SIP - Session Initiation Protocol) Überprüfen auf SIP-Paket von A oder B-Seite.
Listing 3.64: sip.h: SIP-Paket überprüfen
1 IFX_error_t SIP_Check_Pkt(const IFX_payload_t ∗pkt, IFX_IP_addr_t ∗t i p ) ;
Eingabe • pkt ist das Netzwerkpaket, das auf SIP überprüft werden soll, siehe 3.5.4.2 ConverGate-D - Paketbehandlung. • tip zeigt auf den Zielpuffer, in dem die IP-Adresse der BorderGateway A- oder B-Seite gespeichert wird.
Ausgabe • Einen Rückgabewert. • Die IP-Adresse des eingehenden Paketes in tip.
Funktionsprototyp 36 (3.4.6.7.1 SIP-Pakete an der A-Seite) Funktionsprototyp 37 (3.4.6.7.2 SIP-Pakete an der B-Seite) Ein- und Auspacken der SIP-Pakete wurde bereits in 3.5.6.4 IP in IP beschrieben. Für den Versand eines SIP-Paketes siehe 3.5.4.2.2 ConverGate-D-Paket versenden.
3.5.6.8 IP-Prufsummen¨
Der Prüfsummencode wurde im Internet gefunden, siehe [15]. Allerdings beinhaltet die Doku- mentation zu diesem Code einen Fehler:
If the packet has just been received, the checksum routine is expected to return a value of 0xFFFF to indicate that the IP header was received correctly. [15]
Kapitel 3 Hauptteil 3.5 BorderGateway Software: Implementierung - 107 - Fachhochschule Hof
Dies hat sich als falsch herausgestellt: ein fehlerfreies Paket gibt den Wert 0 zurück, nicht 0xffff. Zudem wurde der Code etwas geändert: anstatt der Größe des Paketes in Wörtern wird die Größe in Bytes übergeben. Dies ist transparenter und logischer für den Aufrufer. Die Datengröße wird implizit durch 2 geteilt.
Funktionsprototyp 38 (3.4.6.8 IP-Prüfsummen) Berechnung von IP-kompatiblen Prüfsummen.
Listing 3.65: packet.h: IP-Prüfsummen
1 IFX_uint16_t PKT_Compute_Checksum(const IFX_uint16_t ∗data, IFX_int_t size);
Eingabe • data ist ein Zeiger auf den Quellpuffer, der die zu berechnenden Daten beinhaltet. • size ist die Größe des Quellpuffers in Byte.
Ausgabe • Die Prüfsumme.
Hinweis(e) • size sollte ein Vielfaches von 2 sein, ansonsten liegt vermutlich ein Fehler vor. • Zur Neuberechnung der Prüfsumme für ein Paket muss das Prüfsummenfeld in dem Paket auf 0 gesetzt werden. • Zur Überprüfung eines eingegangenen Paketes muss das Paket nicht geändert werden. Das Resultat der Berechnung sollte bei Fehlerfreiheit 0 sein. • Da die Suche nach einem Beispielcode recht langwierig war, soll hier die Implementierung gezeigt werden:
Listing 3.66: packet.c: IP-Prüfsummencode
1 IFX_uint16_t PKT_Compute_Checksum(const IFX_uint16_t ∗data, IFX_int_t size) 2 { 3 IFX_uint32_t sum= 0; 4 size >>= 1; 5 while (size−− > 0) 6 { 7 sum += ∗(data++); 8 } 9 sum= (sum>> 16) + (sum & 0xFFFF); 10 sum += sum >> 16; 11 return ((IFX_uint16_t) ~sum); 12 }
3.5 BorderGateway Software: Implementierung Kapitel 3 Hauptteil Diplomarbeit - 108 -
3.6 Modul- / System- / Integrationstests
Dieser Abschnitt wird die in 3.3 BorderGateway Software: Struktur sowie 3.4 BorderGateway Software: Spezifikation spezifizierte und in 3.5 BorderGateway Software: Implementierung umgesetzte Funktio- nalität der Software prüfen und die Ergebnisse aufführen. Am Beginn dieses Abschnitts soll gleich vorweggenommen werden, dass die Software fehlerfrei die Spezifikation umsetzt und bereits von Alcatel-Lucent getestet und abgesegnet wurde.
3.6.1 Modul- und Funktionstests
Alle in dieser Software enthaltenen C-Funktion und Module wurden stets gleich nach deren Implementierung auf Funktion getestet.
Es wurden Black-Box-Tests durchgeführt: Die Tests bezogen sich auf die Überprüfung von bestimmten Eingabeparametern und korrekter Ausgabewerte im Rahmen der Spezifikation (3.4 BorderGateway Software: Spezifikation). Diese Tests wurden aus Zeitgründen nicht dokumen- tiert und würden auch den Rahmen dieser Arbeit sprengen.
Außerdem wurden die entscheidenden Komponenten vor Einbau in die BorderGateway Softwa- re auf die gewünschte Funktionalität durch das sog. Proof-of-Concept51 geprüft. Dabei wurde in kleinen und einfachen, separaten Programmen die Funktion der BorderGateway Software bzgl. der jeweiligen Komponente prototypisch umgesetzt:
• TLV: Lesen bzw. Schreiben der Werte in 3.4.3.5 TLV-Daten für die Control-PC Schnittstelle via 3.4.3.3 TLV-Block schreiben (Kodieren) und 3.4.3.4 TLV-Block lesen (Dekodieren) sowie Test der Funktionalität von 3.5.3.1 TLV - Type Length Value. • Kontextlisten: Initialisieren, Schreiben, Lesen und Löschen der Listen in 3.5.1.1 Listen. Dies war gleichzeitig der Testcode für die SimCList-Bibliothek. • ConverGate-D Evaluation Board: Testen der DIP-Switch-Abfrage und User-LED- Ansteuerung, siehe 3.4.4.1 ConverGate-D Evaluation Board. • Pipe: Testen der Pipe- bzw. Warteschlangenfunktionalität, siehe 3.4.3.8 Fehlerwarteschlange (Fault pipe). • Semaphoren: Testen der Semaphoren, siehe 3.2.4.3 uClibc. • UDP: Senden und Empfangen von UDP-Paketen via Betriebssystem, siehe 3.5.3.5 Nachrich- ten via UDP.
White-Box-Tests, wie z.B. statische Code-Analyse durch externe Programme, wurden nicht durchgeführt. Allerdings war der C-Compiler äußerst genau konfiguriert, so dass z.B. auch War- nungen bereits zum Abbruch des Übersetzungsprozesses führten. Dies hat von Anfang an die Zahl der möglichen Programmierfehler minimiert.
51Machbarkeitsbeweis, Machbarkeitsstudie
Kapitel 3 Hauptteil 3.6 Modul- / System- / Integrationstests - 109 - Fachhochschule Hof
3.6.2 Systemtests
Die entscheidenden Tests in diesem Projekt waren die, die das gesamte System, also MPC- Modul & ConverGate-D & Control-PC & Netzwerk, abgedeckt haben. Dabei wurde sich Schritt für Schritt von der kleinsten Einheit bis zum Gesamtsystem hochgearbeitet, und zwar durch Test der Funktionalität zwischen...: 1. BorderGateway Software ⇔ MPC-Modul. 2. BorderGateway Software ⇔ Control-PC. 3. BorderGateway Software ⇔ ConverGate-D. 4. BorderGateway Software ⇔ ConverGate-D ⇔ Netzwerk. 5. BorderGateway Software ⇔ Control-PC ⇔ ConverGate-D ⇔ Netzwerk. Für die Durchführung dieser Tests wurden zwei Maßnahmen getroffen: 1. Es wurde ein sog. Debug-Thread eingebaut, der es erlaubt, mit einfachen Tastatureinga- ben die BorderGateway Software abzufragen oder anzusteuern. 2. Die BorderGateway Software wurde auch auf dem Linux-Entwicklungs-Betriebssystem 52 übersetzt, um verwandte Codeelemente nicht noch einmal implementieren oder kopieren zu müssen. Diese Übersetzung wird von hier an Control-PC Software genannt. Da das MPC-Modul sowie der Control-PC auf Linux basieren, war diese Erweiterung einfach zu realisieren. Hieraus ergeben sich verschiedene Anwendungsmöglichkeiten, je nachdem auf welcher Hardware-Plattform man sich befindet: • MPC-Modul: Von hier aus lassen sich Zustände der BorderGateway Software abfragen oder Operationen aus der BorderGateway Software heraus ausführen. • Control-PC: Die Control-PC Software ermöglicht den Test von externen Einflüssen auf die BorderGateway Software. Für Details zu den einzelnen Hardware-Elementen und der Netzwerkkonfiguration siehe 3.1.5 Test- und Arbeitsumgebung.
3.6.2.1 Debug-Thread
Der Debug-Thread kann je nach Hardware-Plattform verschiedene Operationen ausführen oder starten. Innerhalb der laufenden BorderGateway Software kann mit den Tasten [h], [H] oder [?] ein Überblick über die implementierten Debug-Funktionen aufgerufen werden:
52PC mit Intel-kompatiblen Prozessor ⇒ x86
3.6 Modul- / System- / Integrationstests Kapitel 3 Hauptteil Diplomarbeit - 110 -
Abb. 3.26: Debug-Thread - Hilfe [hH?]
Die einzelnen Operationen werden in den folgenden Abschnitten erklärt.
3.6.2.2 Control-PC Software
Um die BorderGateway Software auch auf dem Linux-Entwicklungs-Betriebssystem nutzen zu können, wurde das BorderGateway Makefile erweitert, siehe Listing F.1 Zeilen 6-21. In der Bor- derGateway Software wurde mit dem Makro X86 ConverGate-D-spezifischer bzw. Control-PC- spezifischer Code weggelassen oder hinzugefügt. Wie bereits erwähnt, mussten nur wenig Än- derungen vorgenommen werden um eine lauffähige Control-PC Software zu erhalten. Meistens reichte es aus, Teile des Quellcodes wegzulassen.
Siehe F.10 BorderGateway: Makefile.am.
3.6.2.3 BorderGateway Software ⇔ MPC-Modul
Das Zusammenspiel zwischen BorderGateway Software und MPC-Modul war selbstverständ- lich grundlegend für die Funktionalität des gesamten Projektes. Hierbei wurde Folgendes über- prüft:
• Startet die BorderGateway Software ohne Fehlermeldungen? • Funktioniert die Konfiguration über die Kommandozeile? • Funktioniert der Debug-Thread und kann dieser einzelne Tastatureingaben korrekt lesen bzw. interpretieren?
Da jede Operation über Fehlerausgaben quittiert wird, konnte die o.g. Funktionalität durch einfache Ein- und Ausgabetests bestätigt werden. Nach jeder neu hinzugefügten Funktion aus der 3.4 BorderGateway Software: Spezifikation begann der Testlauf wieder mit den hier genannten Tests.
Kapitel 3 Hauptteil 3.6 Modul- / System- / Integrationstests - 111 - Fachhochschule Hof
3.6.2.4 BorderGateway Software ⇔ Control-PC
Ein großer Teil der Arbeit floss in die Kommunikationsschnittstelle zwischen MPC- Modul und Control-PC, siehe 3.4.3 Control-PC Schnittstelle. Getestet wurden also folgende Be- reiche: 1. UDP: Werden eingehende UDP-Pakete empfangen? Werden UDP-Pakete korrekt versandt? 2. TLV: Wird das empfangene Paket korrekt gelesen? Wird eine Antwort korrekt zusammen- gestellt? Werden die Listen korrekt verwaltet? 3. Fehlerfälle: Was passiert bei fehlerhaften, eingehenden Paketen? Wird die richtige Fehler- nachricht generiert? In welchem Zustand ist die BorderGateway Software anschließend? An dieser Stelle wurde zum ersten Mal die Control-PC Software verwendet. Für diese Tests muss auf dem Control-PC die Control-PC Software und auf dem MPC-Modul die BorderGateway Soft- ware laufen, und zwar mit folgenden Kommandozeilenaufrufen:
• Control-PC: x86test –dbg-thread –byte-order –showbuffer –dbg-eth-if eth1 • MPC-Modul: bordergateway –dbg-thread -sendbind -cg-rcv-quiet
Siehe F.9 BorderGateway Software: Kommandozeilenparameter.
3.6.2.4.1 Vordefinierte Nachrichten Via [ENTER] kann eine vordefinierte Nachricht von der Control-PC Software an die BorderGa- teway Software geschickt werden. Die Antwort der BorderGateway Software wird in hexade- zimaler Darstellung auf dem Bildschirm ausgegeben. Die Control-PC Software interpretiert die erhaltene Antwort nicht, sondern zeigt lediglich den Inhalt an. Hier soll als Beispiel für alle möglichen Befehle aus Sicht des Control-PC das Senden von CON- FIG_REQ und Empfangen von CONFIG_REP dienen, siehe 3.4.3.7.9 CONFIG_REQ (0x04): MPC- Modul konfigurieren: Abb. 3.27: Control-PC - CONFIG_REQ senden [ENTER]
Abbildung 3.27 Control-PC - CONFIG_REQ senden [ENTER] zeigt den gesendeten Befehl CON- FIG_REQ und die daraufhin empfangene Antwort CONFIG_REP. In Abbildung 3.28 MPC-Modul - CONFIG_REQ empfangen der gleiche Vorgang aus Sicht der BorderGateway Software. Es werden auch folgende fehlerhaften Nachrichten auf erwartete Reaktion ( ⇒ ) getestet:
• Unbekannter TLV-Typ ⇒ FAULT-Nachricht, siehe Tabelle 3.4 Control-PC ⇔ MPC-Modul TLV- Daten. • Unbekannter Befehlscode ⇒ FAULT-Nachricht, siehe Tabelle 3.5 Control-PC ⇔ MPC-Modul Be- fehle. • Falsche Context-ID in SUBTRACT_REQ-Nachricht ⇒ fehlgeschlagene SUBTRACT_REP- Nachricht.
3.6 Modul- / System- / Integrationstests Kapitel 3 Hauptteil Diplomarbeit - 112 -
Abb. 3.28: MPC-Modul - CONFIG_REQ empfangen
3.6.2.4.2 FAULT Generierung Die schon in der Spezifikation als Spezialfall erwähnte FAULT-Nachricht erhält auch in den Tests eine Spezialbehandlung. So können zwei vordefinierte Werte mit [f] und [F] auf dem MPC-Modul in die Fehlerwarteschlange geschrieben und damit die Generierung von FAULT- Nachrichten an den Control-PC getestet werden: 1. [f]: Schreibt den Wert -1 (0xffff) in die Fehlerwarteschlange. Dies entspricht einem allge- meinen Fehler (general error). 2. [F]: Schreibt den Wert -500 (0xfe0c) in die Fehlerwarteschlange plus einen Zeiger auf einen frei gewählten Rückgabestring. Dies entspricht einem besonderen Fehler, der nicht in der Liste der Rückgabestrings zu finden ist (custom error message). Abb. 3.29: MPC-Modul - FAULT senden [f] & [F]
Kapitel 3 Hauptteil 3.6 Modul- / System- / Integrationstests - 113 - Fachhochschule Hof
Abb. 3.30: Control-PC - FAULT empfangen
Siehe 3.4.3.7.12 FAULT (0x86): Fehler signalisieren und 3.5.3.3.7 FAULT: Fehler signalisieren.
3.6.2.5 BorderGateway Software ⇔ ConverGate-D
Die Tests der ConverGate-D Schnittstelle können in drei unterschiedliche Kategorien eingeteilt werden: 1. 3.6.2.5.1 Statische Konfiguration. 2. 3.6.2.5.2 Dynamische Konfiguration. 3. 3.6.2.5.3 Paketbehandlung.
3.6.2.5.1 Statische Konfiguration Die statische Konfiguration wurde anhand zweier Punkte überprüft: 1. Wurde die binäre Konfigurationsdatei sowie die Firmware fehlerfrei geladen? Da die Bor- derGateway Software bei einem Fehler während der statischen Konfiguration abbrechen muss, ist dieser Beweis durch das Starten der Software bereits erbracht. 2. War die vorgegebene MAC-Adresse eingerichtet? Siehe festgelegte MAC-Adresse in F.3 ConverGate-D Daten und das Ergebnis in Abbildung 3.31 MPC-Modul - BorderGateway In- formation [1]. Im folgenden Bild werden u.a. auch die gespeicherten IP-Adresse der verschiedenen Elemente des MAMS-Netzwerkes angezeigt:
3.6 Modul- / System- / Integrationstests Kapitel 3 Hauptteil Diplomarbeit - 114 -
Abb. 3.31: MPC-Modul - BorderGateway Information [1]
Siehe 3.4.4.3 ConverGate-D - Statische Konfiguration.
3.6.2.5.2 Dynamische Konfiguration Bei der dynamischen Konfiguration handelt es sich um das Schreiben der Halfcall bzw. Verbin- dungsdaten in den Speicher des ConverGate-D. Hierfür wurde eine weitere Funktion in den Debug-Thread eingebaut, die via [v] oder [V] aufgerufen werden kann. Insgesamt werden in vier Blöcken jeweils folgende Tests durchgeführt (siehe Abbildung 3.32 MPC-Modul - BCAM und FIB Lese-/Schreibzugriffe [vV]): 1. Weiterleitungstabelle FIB: In den ersten 6 Zeilen jedes Blocks wird der Zugriff auf die Weiterleitungstabelle getestet. Die jeweils erste Zeile eines FIB-Tests beschreibt den Wert der geschrieben wird (value=0x...), die zweite Zeile das gelesene Ergebnis in „Soll == Ist“-Darstellung. a) Schreiben und Lesen eines 16-Bit Wertes. b) Schreiben und Lesen eines 32-Bit Wertes. c) Schreiben und Lesen einer MAC-Adresse. 2. Vergleichsspeicher BCAM: Die letzten 3 Zeilen jedes Blocks beschreiben die durchgeführte Aktion mit dem jeweiligen Ergebnis für IP und UDP, wieder in „Soll == Ist“-Darstellung. Der Indexwert für das BCAM entspricht dem Index der vorher ausgeführten FIB-Tests. a) Lesen der IP-Adresse und des UDP-Port, ohne vorher etwas dorthin geschrieben zu haben. Obwohl hier Soll und Ist nicht übereinstimmen, ist der Test erfolgreich: Wenn ein leerer Eintrag aus dem BCAM gelesen wird, muss Ist gleich 0 sein. Der Autor hat an dieser Stelle die Sollwertanzeige nicht explizit für die Leseoperation angepasst. b) Schreiben und Lesen der IP-Adresse und des UDP-Port. Hier müssen Soll und Ist übereinstimmen. c) Löschen und Lesen der IP-Adresse und des UDP-Port. Wie in a) stimmen hier Soll und Ist nicht überein. Soll zeigt hier die Werte die in b) geschrieben wurden. Ist muss aber nach dem löschen 0 sein. Dieser Test ist somit ebenfalls erfolgreich abgeschlossen.
Kapitel 3 Hauptteil 3.6 Modul- / System- / Integrationstests - 115 - Fachhochschule Hof
Abb. 3.32: MPC-Modul - BCAM und FIB Lese-/Schreibzugriffe [vV]
Diese Funktion muss auf dem MPC-Modul ausgeführt werden. Siehe 3.4.4.4 ConverGate-D - Dyna- mische Konfiguration.
3.6.2.5.3 Paketbehandlung Insgesamt muss die BorderGateway Software auf ARP-, ICMP- und SIP-Pakete reagieren. Ob die 3 Pakettypen auch tatsächlich erkannt und korrekt verarbeitet werden, wird in den folgenden Paragraphen erläutert. Siehe 3.4.4.2 ConverGate-D - Paketbehandlung.
ARP Die ARP Funktionalität besteht aus der Antwort auf eingehende ARP-Anfragen und dem Senden eigener ARP-Anfragen. Siehe 3.4.6.2.1 Antwort auf einen ARP-Request und 3.4.6.2.2 Versenden eines ARP-Request.
3.6 Modul- / System- / Integrationstests Kapitel 3 Hauptteil Diplomarbeit - 116 -
Der einfachere Test besteht in der Überprüfung von Antworten auf ARP-Anfragen. Hierfür werden unter Linux explizite ARP-Anfragen an die ConverGate-D-IP-Adresse gesendet (siehe E.2.1 Linux: arping, ping). Korrespondierende Bereiche sind mit rot bzw. grün gekennzeichnet: Abb. 3.33: Linux - ARP-Anfragen senden (arping)
Abb. 3.34: MPC-Modul - ARP-Anfragen beantworten
Für das Senden eigener ARP-Anfragen wird wieder auf den Debug-Thread zurückgegriffen. In diesem Test sendet die BorderGateway Software über die beiden GbE-Schnittstellen eine ARP- Anfrage an den Control-PC und erwartet eine Antwort: Abb. 3.35: Control-PC - IP- und MAC-Adresse
Abb. 3.36: MPC-Modul - ARP-Anfrage an Control-PC (Test #1)
Kapitel 3 Hauptteil 3.6 Modul- / System- / Integrationstests - 117 - Fachhochschule Hof
Wie man sieht war die ARP-Anfrage auf der A-Seite erfolgreich, auf der B-Seite allerdings nicht. Dies ist korrekt, da nach Abbildung 3.6 Testumgebung der Control-PC nur an der A-Seite des Test- Aufbaus angeschlossen ist. Im folgenden Beispiel wurde die B-Seite mit dem Switch der A-Seite verbunden, womit nun beide GbE-Ports den Control-PC erreichen: Abb. 3.37: MPC-Modul - ARP-Anfrage an Control-PC (Test #2)
ICMP Die ICMP-Funktionalität lässt sich sehr leicht testen, siehe E.2 ARP / ICMP Generierung. Hierzu wird der Befehl ping benutzt: Abb. 3.38: Linux - ICMP-Anfragen senden (ping)
Auf dem MPC-Modul erfolgt folgende Ausgabe (man achte auf die einleitende ARP-Anfrage des ping Befehls): Abb. 3.39: MPC-Modul - ICMP-Anfragen beantworten
Siehe 3.4.6.5 ICMP - Internet Control Message Protocol.
SIP Die SIP-Funktionalität wurde ebenfalls aus dem Debug-Thread heraus über das MPC-Modul ge- testet. Um ein eingehendes SIP-Paket an der A-Seite zu testen, wird [s] gedrückt, für ein SIP- Paket an der B-Seite [S].
Die folgenden zwei Tests (Abbildung 3.40 MPC-Modul - SIP-Pakete senden [s] & [S]) lassen sich übrigens auch von der Control-PC Software ausführen, denn hierbei werden Pakete nicht über die ConverGate-D GbE-Schnittstellen, sondern über eine Linux-Ethernet-Schnittstelle verschickt (siehe ETH in 3.1.2 ConverGate-D Evaluation Board: Modell easy4271). Der Code ist auf beiden Platt- formen gleich und unterscheidet sich nur durch unterschiedliche Schnittstellenbezeichnungen, z.B. eth0 oder eth1 (siehe –dbg-eth-if in F.9 BorderGateway Software: Kommandozeilenparameter).
Die Konfiguration der BorderGateway Software entspricht hier wieder Abbildung 3.31 MPC- Modul - BorderGateway Information [1]. Für diesen Test wird die B-Seite wieder mit dem Switch der A-Seite verbunden. Dies verbindet nicht nur den Control-PC, sondern auch das MPC-Modul mit den beiden GbE-Schnittstellen des ConverGate-D Evaluation Board.
3.6 Modul- / System- / Integrationstests Kapitel 3 Hauptteil Diplomarbeit - 118 -
Die folgende Abbildung zeigt wie jeweils ein SIP-Paket erhalten (erst an A, dann B) und dann erfolgreich weitergeleitet wird. Auf eine detailliertere Darstellung wurde hier verzichtet, da in Abbildung 3.41 PC #1 - SIP-Pakete empfangen die Pakete genau zu sehen sind. Abb. 3.40: MPC-Modul - SIP-Pakete senden [s] & [S]
In Abbildung 3.41 PC #1 - SIP-Pakete empfangen werden die von der BorderGateway Software an den Control-PC gesendeten Pakete in Wireshark (E.4 Ethernet Paketüberwachung) dargestellt. Ganz oben in der Abbildung sieht man die Liste der eingegangenen Pakete, gefiltert nach UDP und ARP. Insgesamt werden sechs Pakete angezeigt. Drei Pakete beschreiben jeweils die Vorgänge für die Weiterleitung eines SIP-Paketes. Vor jedem SIP-Paket (angezeigt als UDPENC) muss die BorderGateway Software via ARP die MAC-Adresse der jeweiligen Ziel-IP-Adresse abfragen. Dies kann man sehr schön an den Paketen 1+2 bzw. 4+5 sehen. Als Ziel der Pakete wurde PC #1 mit der IP-Adresse 192.168.152.10 gewählt. Als Quell-IP- Adresse für innere bzw. ausgepackte IP-Pakete wurde die gleiche Adresse verwendet, so dass, egal nach welcher Operation, das Ziel immer PC #1 ist. Das Fenster mit der Markierung SIP to A side zeigt das Paket, welches an der A-Seite einge- troffen ist, eingepackt und über B weitergeleitet wurde. Dort kann man auch den Aufbau des Paketes erkennen: 1. Ethernet II. 2. Internet Protocol. 3. Internet Protocol. 4. User Datagram Protocol. Das Fenster mit der Markierung SIP to B side zeigt das Paket, welches an der B-Seite eingetrof- fen ist, ausgepackt und über A weitergeleitet wurde. Sein Aufbau: 1. Ethernet II. 2. Internet Protocol. 3. User Datagram Protocol. Zum besseren Verständnis sollte noch einmal daran erinnert werden, dass SIP-Pakete, je nach- dem ob sie auf der A oder B-Seite eintreffen, eingepackt oder ausgepackt werden. Siehe 3.4.6.7.1 SIP-Pakete an der A-Seite und 3.4.6.7.1 SIP-Pakete an der A-Seite. Die Information [Malformed Packet]53 bezieht sich darauf, dass keine UDP-Daten versendet wurden. Die via [s] und [S] generierten UDP-Pakete haben eine Datenlänge von 0.
53Missgestaltetes/-gebildetes Paket
Kapitel 3 Hauptteil 3.6 Modul- / System- / Integrationstests - 119 - Fachhochschule Hof
Abb. 3.41: PC #1 - SIP-Pakete empfangen
Abschließend werden noch einmal mit [1] die Informationen bzw. der momentane Status der BorderGateway Software abgefragt. Markiert sind in diesem Bild die B2BUA-IP-Adresse (PC #1!) sowie dessen MAC-Adresse. Außerdem zeigt diese Abbildung auch den SIP-Nachrichtenzähler.
Abb. 3.42: MPC-Modul - BorderGateway Information nach SIP-Test [1]
Siehe 3.4.6.7 SIP - Session Initiation Protocol.
3.6 Modul- / System- / Integrationstests Kapitel 3 Hauptteil Diplomarbeit - 120 -
3.6.2.6 BorderGateway Software ⇔ ConverGate-D ⇔ Netzwerk
Die Systemtests, die zum ersten mal die Grundfunktionalität des BorderGateway testen soll- ten, wurden mit fest konfigurierten IP-Adressen, MAC-Adressen und UDP-Ports durchgeführt, ohne eine externe Konfiguration durch den Control-PC bzw. der BorderGateway Software. Da- durch sollte die BorderGateway Software als potentielle Fehlerquelle ausgeschlossen werden. Die Einstellungen wurden in der statischen WinEASY-Konfiguration (3.4.4.3 ConverGate-D - Stati- sche Konfiguration) an den ConverGate-D übergeben. Bei den Tests wurde ein Datenstrom (ein MPEG-Streaming) von PC #1, über den ConverGate- D, an PC #2 gesendet. Diese Tests können leider schlecht durch Bilder belegt werden, daher soll eine kurze, abstrakte Beschreibung die Vorgänge verdeutlichen. Alle UDP-Ports in dieser Konfiguration wurden auf 1234 gesetzt, um die Tests einfacher zu gestalten. Daher werden die UDP-Ports in der folgenden Beschreibung nicht mit aufgeführt. 1. PC #1 (192.168.152.10): Mit einem MPEG-Abspielprogramm 54 wird ein Film an die Bor- derGateway A-Seite gesendet (UDP-Pakete: RTP und RTCP). 2. BorderGateway A-Seite (192.168.152.50): Empfängt die Pakete von PC #1. 3. ConverGate-D: Umschalten der eingehenden Pakete von PC #1 ⇒ A-Seite auf B- Seite ⇒ PC #2. 4. BorderGateway B-Seite (192.168.152.51): Versendet die Pakete an PC #2. 5. PC #2 (192.168.152.99): Empfängt den MPEG-Datenstrom auf UDP-Port 1234 und spielt die Daten als Film ab. Im nächsten Abschnitt wird die Funktionalität des BorderGateway deutlicher wiedergegeben.
3.6.2.7 BorderGateway Software ⇔ Control-PC ⇔ ConverGate-D ⇔ Netzwerk
Der Unterschied dieses Tests zu dem im letzten Abschnitt, besteht in der dynamischen Konfi- guration des ConverGate-D. Hier werden keine festen Konfigurationen mehr übertragen. Der ConverGate-D ist somit nach dem Start der BorderGateway Software leer und wird keine Datenströme durchlassen. Über die Control-PC Software werden nun vordefinierte Nachrich- ten an die BorderGateway Software geschickt, welche eine komplette Verbindung aufbauen. Die Nachricht ADD_REQ dient zur Übermittlung der Halfcall-Daten für PC #1 ⇒ A-Seite (192.168.152.10 ⇒ 192.168.152.50).
HEX PAYLOAD DESCRIPTION ------02 04 01 00 00 00 Timestamp: 00,001s (00000001h) 03 01 00 Command: ADD_REQ
Halfcall A 20 04 32 98 a8 c0 local IP-Addr: 192.168.152.50 22 04 0a 98 a8 c0 remote IP-Addr: 192.168.152.10 23 02 d2 04 remote UDP (RTP) Port: 1234
Halfcall B 20 04 97 04 a8 c0 local IP-Addr: 192.168.152.51
54VLC media player 0.8.6c
Kapitel 3 Hauptteil 3.6 Modul- / System- / Integrationstests - 121 - Fachhochschule Hof
27 02 40 00 Bandwidth: 6400 kbps (64*100 kbps) 26 01 02 QoS: Realtime ’RT’
Die BorderGateway Software antwortet mit einem ADD_REP. Für den Test sind die zurückgege- benen lokalen UDP-Ports von Interesse:
HEX PAYLOAD DESCRIPTION ------02 04 01 00 00 00 Timestamp: 00,001s (00000001h) 03 01 80 Command: ADD_REP
25 02 01 00 Context ID: 1
Halfcall A 24 02 01 00 Termination Id: 1 for RTP (2 RTCP implicit) 21 02 24 4e local UDP (RTP) Port: 20004 (RTCP 20005 implicit)
Halfcall B 24 02 03 00 Termination Id: 3 for RTP (4 RTCP implicit) 21 02 25 4e local UDP (RTP) Port: 20006 (RTCP 20007 implicit)
04 02 00 00 Result: Success 05 00 Result string: ""
MODIFY_REQ übermittelt letztendlich die Halfcall-Daten für PC #2 ⇒ B-Seite (192.168.152.99 ⇒ 192.168.152.51).
HEX PAYLOAD DESCRIPTION ------02 04 02 00 00 00 Timestamp: 00,002s (00000002h) 03 01 02 Command: MODIFY_REQ
25 02 01 00 Context ID: 1
Halfcall A 24 02 01 00 Termination Id: 1 for RTP (2 RTCP implicit)
Halfcall B 24 02 03 00 Termination Id: 3 for RTP (4 RTCP implicit) 22 04 63 98 a8 c0 remote IP-Addr: 192.168.152.99 23 02 d2 04 remote UDP (RTP) Port: 1234
Nun ist eine Verbindung eingerichtet und alle benötigten Informationen sind vorhanden, um den Paketverlauf zu verfolgen. Hierzu werden auf PC #1 die Programme Wireshark und PacketCrafter gestartet, siehe E.4 Ether- net Paketüberwachung und E.5 Testpaketgenerierung. Auf PC #2 wird ebenfalls Wireshark geladen.
3.6 Modul- / System- / Integrationstests Kapitel 3 Hauptteil Diplomarbeit - 122 -
Das Programm PacketCrafter wird benutzt, um leere UDP-Pakete an den BorderGateway zu senden. Die folgende Abbildung zeigt das Programmfenster. Es wird ein UDP-Paket von PC #1 (192.168.152.10) an den BorderGateway (192.168.152.50) geschickt. Die Quell- und Zieladres- sen sind mit rot bzw. grün gekennzeichnet: Abb. 3.43: PC #1 - Paket an BorderGateway senden
Es werden zwei Pakete versandt. Ein Paket, wie im Bild zu sehen, an UDP-Port 20004. Das zweite Paket wird an UDP-Port 20005 gesendet (ohne Abbildung). Das Programm Wireshark auf PC #1 zeigt die ausgehenden Pakete an den BorderGateway an: Abb. 3.44: PC #1 - Pakete an den BorderGateway
Kapitel 3 Hauptteil 3.6 Modul- / System- / Integrationstests - 123 - Fachhochschule Hof
Auf PC #2 (192.168.152.99) werden die eingehenden Pakete von dem BorderGate- way (192.168.152.51) in Wireshark angezeigt: Abb. 3.45: PC #2 - Pakete vom BorderGateway
In diesem Bild sieht man den Paketübergang besonders gut an den UDP-Ports:
• Der RTP-Port 20004 auf der A-Seite wird umgesetzt auf den Port 20006 auf der B-Seite. • Der RTCP-Port 20005 auf der A-Seite wird umgesetzt auf den Port 20005 auf der B-Seite.
Damit wurde auf recht unspektakuläre Weise die Umsetzung von IP-Adressen und UDP-Ports ge- testet und bewiesen. Die entgegengesetzte Richtung wurde durch den gleichen Test überprüft.
3.6.3 Integrationstests
Mit Integrationstests sind die Tests gemeint, welche die Funktionalität des ConverGate-D Evalua- tion Board mit Software außerhalb der Test- bzw. Arbeitsumgebung unter realen Bedingungen prüfen.
Der erste Integrationstest wurde vor Ort bei Alcatel-Lucent in Stuttgart am 3.5.2007 durchge- führt. Hierbei wurde die Kontrollschnittstelle getestet, siehe 3.4.3 Control-PC Schnittstelle. Es ging um die korrekte Umsetzung der Schnittstellenspezifikation auf der Seite von Alcatel-Lucent und der Seite des Autors. Dabei wurde der Control-PC der Testumgebung durch einen Control-PC von Alcatel-Lucent ersetzt. Dieser Test verlief für beide Seiten zufriedenstellend. Kleinere Unstim- migkeiten und Verbesserungsvorschläge wurden vor Ort besprochen und umgesetzt. Bei diesem Besuch wurde auch ein funktionsfähiges ConverGate-D Evaluation Board bei Alcatel-Lucent hin- terlassen, so dass in Zukunft nur noch Software-Pakete übermittelt werden mussten.
Der zweite Integrationstest zog sich über eine Woche hin und wurde alleine durch Alcatel- Lucent vorgenommen. Nachdem mehrere kleine Probleme in direkter Zusammenarbeit mit Alcatel-Lucent analysiert und behoben waren, wurde am 17.8.2007 die finale Version der Bor- derGateway Software geliefert. Bei diesen Tests ging es um die Prüfung der kompletten Funk- tionalität des BorderGatewayunter realen Bedingungen. So wurde z.B. bereits mit IP-Telefonen über den BorderGateway telefoniert.
Ein dritter, großer Integrationstest fand am 21.9.2007 in Berlin in den T-Labs der Deutschen Telekom AG statt, in denen eine Vielzahl von Projekten in großen Testumgebungen erprobt und getestet werden. In einer dieser Testumgebungen wurde unter wirklichkeitsgetreuen Bedin- gungen der BorderGateway auf Funktion unter Aufsicht der Telekom erfolgreich geprüft. Jean
3.6 Modul- / System- / Integrationstests Kapitel 3 Hauptteil Diplomarbeit - 124 -
Riemer von Alcatel-Lucent, sowie der Betreuer der Diplomarbeit Andreas Foglar und der Autor dieser Arbeit haben vor Ort dem Test beigewohnt. Abbildung 3.46 zeigt den Testaufbau. In der Mitte des Aufbaus ist das ConverGate-D Evaluation Board zu sehen, welches auf den Control-Blade von Alcatel-Lucent steht. Abb. 3.46: T-Systems Berlin - Testaufbau
In Abbildung 3.47 sind zwei IP-Bildtelefone zu sehen, die über den BorderGateway miteinander kommunizieren. Der Monitor in der Mitte des Bildes zeigt die Ausgaben der einzelnen Elemente des gesamten Netzwerkes. Abb. 3.47: T-Systems Berlin - Bildtelefonie
Kapitel 3 Hauptteil 3.6 Modul- / System- / Integrationstests - 125 - Fachhochschule Hof
Kapitel 4
Schlussbetrachtung
4.1 Zusammenfassung
Das Ziel dieser Diplomarbeit war die prototypische Entwicklung eines BorderGateway für die Verwendung im „Multi Access, Modular Services“-Forschungsprojekt (MAMS), basierend auf der Infineon ConverGate-D-Hardware. MAMS in seiner Gesamtheit zu erfassen, ist für den Leser dieser Arbeit sicherlich unmöglich. Zudem sagt ja schon das Wort Forschungsprojekt, dass sich Planung, Entwurf und Spezifikation oft in der Umsetzung entweder bewahrheitet oder auch als falsch oder unbrauchbar herausstellt. Dies hat sich auch in dieser Arbeit an einigen Stellen gezeigt. Glücklicherweise war in dieser Diplomarbeit Wissen über das gesamte MAMS-Projekt für die Bearbeitung der konkreten Aufgabenstellung nicht nötig. Vielmehr musste relativ zügig von der abstrakten MAMS-Gesamtübersicht hin zu der Kernaufgabe der Diplomarbeit übergegangen werden. Bei der Eingrenzung und Festlegung sowie der Spezifikation und Umsetzung der zu erledigenden Arbeiten, war enge Zusammenarbeit mit dem Betreuer, den Arbeitskollegen und v.a. mit Alcatel- Lucent notwendig. Das Ergebnis dessen ist der Kern dieser Diplomarbeit. Die Hauptarbeiten bestanden in der Definition und Umsetzung der Kontrollschnittstelle zwi- schen MPC-Modul und Control-PC, der Konfiguration des ConverGate-D und der Kommunikati- on mit den verbundenen Netzwerken. Es gelang durch Änderungen an vorhandener Software, diverse neue Ideen einzubringen, welche bereits jetzt in einem anderen Projekt1 Verwendung finden. Hier sei beispielhaft das Konzept der binären Konfigurationsdatei sowie die Vereinheitlichung der drei ConverGate-D-Header und Netzwerkprotokolle in eine Datenstruktur genannt. Die Anwendung des ConverGate-D Evaluation Boards im MAMS-Projekt war in mehrfacher Hin- sicht eine Herausforderung: 1. Das Weiterleiten von Paketen anhand von IP-Adresse und UDP-Port war bisher nicht er- probt und implementiert. Hierfür waren Änderungen in der ConverGate-D-Firmware und in den Linux-Kernel-Treibern notwendig. 2. Die zu erstellende Software musste in die bestehende Infineon-Linux-Entwicklungsumgebung integriert werden und sich an firmeninternen Gegebenheiten orientieren.
1http://medea-planets.eu/
4.1 Zusammenfassung Kapitel 4 Schlussbetrachtung Diplomarbeit - 126 -
3. Das Projekt auf Seite von Infineon wurde ausschließlich von Studenten umgesetzt. Es war also nicht sicher, ob am Ende des Projektes und damit dieser Diplomarbeit auch ein funktionsfähiges System stehen würde. Abschließend konnten aber alle geplanten Systemteile erfolgreich implementiert, getestet und an Alcatel-Lucent geliefert werden. Die Zielsetzung dieser Arbeit wurde somit vollständig erreicht.
4.2 Ausblick
Ein Ausblick auf das gesamte MAMS-Projekt fällt an dieser Stelle schwer, denn Spekulation über ob, wie und wann ein marktreifes Produkt verfügbar wäre soll nicht Teil dieses Abschnittes sein. Vielmehr soll an dieser Stelle ein Ausblick auf mögliche Änderungen, Verbesserungen und Erwei- terungen der in diesem Dokument gezeigten Arbeiten erörtert werden. Die BorderGateway Soft- ware ist eine prototypische Umsetzung der Spezifikation, zwar fehlerfrei, aber trotzdem nicht geeignet für den Einsatz in einem kommerziellen Rahmen. Die folgenden Punkte würden der Software eine professionelle Anwendung ermöglichen.
Visualisierung Die BorderGateway Software sollte eine übersichtlichere Bildschirmausgabe bieten. Damit ist keine grafische Oberfläche gemeint, denn die ist in einem Terminal, das nur über die Tastatur gesteuert werden kann, überflüssig. Jedoch könnte der Bildschirm in feste Bereiche eingeteilt werden, was dem Betrachter eine bessere Übersicht über den momentanen Zustand der Softwa- re bieten würde. Momentan werden Informationen einfach durch zeilenweise Ausgabe auf dem Bildschirm angezeigt. Des Weiteren wäre eine Zustandssignalisierung der laufenden BorderGateway Software über die User LEDs sinnvoll. So könnte man nur durch den Blick auf das ConverGate-D Evaluation Board feststellen, ob die Software fehlerfrei geladen wurde und betriebsbereit ist. Diese Anzeige würde den Herzschlag der Software durch einen sog. Heartbeat-Thread darstellen. Dafür wäre User LED 0 ideal.
Programmsteuerung Zur momentanen Programmsteuerung über einzelne Tasteneingaben gibt es nicht viele Alterna- tiven. Eine sinnvoll erscheinende Möglichkeit wäre die Steuerung der Software über Befehle auf der Kommandozeile. Hierfür müsste die BorderGateway Software im Hintergrund gestartet wer- den, so dass im Vordergrund der Linux-Befehlsinterpreter aktiv bleibt. Die BorderGateway Soft- ware würde eine benannte Pipe (Warteschlange) bereitstellen, in die über den Befehlsinterpreter Befehle geschrieben werden können: echo quit > /
Kapitel 4 Schlussbetrachtung 4.2 Ausblick - 127 - Fachhochschule Hof
Konfiguration In zukünftigen Anwendungen könnte es hilfreich sein, die aktuelle Systemzeit der BorderGa- teway Software von dem Control-PC zu erhalten, und somit beide System zu synchronisieren. Hierfür würde es sich anbieten mit dem CONFIG_REQ Befehl einen zusätzlichen Parameter für die Systemzeit zu übermitteln.
Zeitverhalten Für die prototypische Anwendung ist das momentane Zeitverhalten der BorderGateway Soft- ware absolut ausreichend und wurde in internen Tests nicht überprüft. Allerdings hat Alcatel- Lucent in dem zweiten Integrationsdienst festgestellt, dass zwischen zwei an die BorderGate- way Software versendeten Nachrichten und entsprechenden Antworten eine relativ lange War- tepause besteht. Tatsächlich liegt das u.a. daran, dass nach jeder eingehenden Nachricht die Fehlerwarteschlange überprüft wird. Bei dieser Überprüfung wird eine halbe Sekunde auf Daten in der Fehlerwar- teschlange gewartet. Diese Wartezeit ist überflüssig und sollte auf ein Minimum oder sogar 0 reduziert werden:
Listing 4.1: fault_pipe.h: FAULT_PIPE_WAIT_TIMEOUT_READ
1 /∗∗ F a u l t p i p e read wait timeout in ms ∗/ 2 #define FAULT_PIPE_WAIT_TIMEOUT_READ 500
Um mehr potentielle Flaschenhälse (Bottlenecks) zu entdecken, sollte die Software einem Performance-Test (Performance-Profiling) unterzogen werden2.
2Weiterführende Informationen hierzu über die Stichwörter gcc und gprof.
4.2 Ausblick Kapitel 4 Schlussbetrachtung Diplomarbeit - 128 -
Anhang A
Pr¨aambel: Anh¨ange
Die folgenden Anhänge dienen als erweiternde und/oder notwendige Information zu den vom Autor ausgeführten Tätigkeiten. Die Ausarbeitung der folgenden Seiten ist allerdings nicht so detailliert wie bisher, da der Autor nun einerseits Grundwissen voraussetzt und andererseits der Umfang der Anhänge und die Arbeit an den Anhängen nicht überhand nehmen soll.
Anhang A Präambel: Anhänge - 129 - Fachhochschule Hof
Anhang B
Meilensteine / Zeitplan
Für diese Arbeit wurden folgende Meilensteine definiert: • Einarbeitung in Thema, Hardware, Software • Spezifikation und Implementierung der Kontrollschnittstelle • Integrationstest der Kontrollschnittstelle im Mai • Spezifikation und Implementierung der ConverGate-D-Schnittstelle • Modultests (durchgehend) • System- / Integrationstests • Lieferung der Software im Juni oder Juli • Dokumentation der Arbeit ab Juli Der tatsächliche Ablauf der Arbeiten ist auf der nächsten Seite in einem Balkendiagramm darge- stellt. Für die Abgabe dieser Diplomarbeit war der 31. August 2007 geplant, letztendlich wurde aber bis zum 28. September 2007 daran gearbeitet.
Anhang B Meilensteine / Zeitplan Diplomarbeit - 130 -
Abb. B.1: Zeitplan
Anhang B Meilensteine / Zeitplan - 131 - Fachhochschule Hof
Anhang C
Errata: Fehler/Probleme & L¨osungen
C.1 Sourceball buildroot easy4271.sh
Bei der Erstellung des Basissourceballs für die Arbeit an dem BorderGateway ist anscheinend eine Unregelmäßigkeit aufgetreten. Wenn man den o.g. Sourceball unter Linux ausführt, bricht der Installationsprozess ab, weil die Datei buildroot/LICENSE nicht gefunden werden kann. Offensichtlich war diese Datei nicht in der Basisinstallation des Autors vorhanden. Als Lösung hat der Autor ein Installationsskript install.h geschrieben, welches u.a. das LICENSE Problem behebt, auszuführen in ˜/projects/:
Listing C.1: IBE Installationsskript
1 #!/ bin / bash 2 # 3 # bash because o f pushd /popd 4 # 5 # c r e a t e mis sing b u i l d r o o t /LICENSE f i l e b e f o r e c o n t i n u i n g 6 # 7 # todo : s e t c o r r e c t a c c e s s modes to new f i l e s (WIN <−> LINUX f i l e s y s t e m s !) 8 # 9 function install_bg_src() { 10 mkdir −p ~/projects/tftp/
12 echo " ∗∗∗ uncompressing BorderGateway source " 13 tar −xzf bg_src.tgz
15 echo " ∗∗∗ copying f i l e s " 16 # save the o r i g i n a l arp . h f i l e i f ∗. bak doesn ’ t e x i s t y e t 17 i f [ ! −f /usr/include/linux/if_arp.h.bak ]; then 18 cp /usr/include/linux/if_arp.h /usr/include/linux/if_arp.h.bak 19 f i 20 # copy the l o c a l usr /... to / 21 cp usr/include/linux/if_arp.h /usr/include/linux/if_arp.h
23 return 0 24 }
26 FILES_TO_COPY=" " 27 UCLIBC_DIR=" buildroot / toolchain_build_powerpc / uClibc −0.9.28/ " 28 CWD=‘pwd‘
30 i f [ ! −f ~/projects/buildroot/.unpacked ]; then 31 echo " ∗∗∗ unpacking buildroot " 32 mkdir buildroot 33 touch buildroot/LICENSE 34 ./buildroot_easy4271.sh 35 f i
37 i f [ ! −f ~/projects/buildroot/.configured ]; then 38 echo " ∗∗∗ configuring buildroot " 39 pushd buildroot 40 ./change_configuration.sh && touch .configured 41 popd 42 f i
44 i f [ ! −f ~/projects/buildroot/.builtonce ]; then 45 echo " ∗∗∗ making buildroot " 46 pushd buildroot
C.1 Sourceball buildroot_easy4271.sh Anhang C Errata Diplomarbeit - 132 -
47 make && install_bg_src && touch .builtonce 48 popd 49 f i
51 i f [ −f ~/projects/buildroot/.builtonce ]; then 52 i n s t a l l _ b g _ s r c 53 f i
55 #semtimedop () patch from 56 #h t t p :// bugs . busybox . net / print_bug_page . php? bug_id=927 57 # 58 #to be e x e c u t e d in 59 #~/ p r o j e c t s / b u i l d r o o t / toolchain_build_powerpc / uClibc −0.9.28/ 60 #with 61 #" patch −p0 −b < semtimedop_df " 62 pushd $UCLIBC_DIR 63 i f [ ! −f .patched ]; then 64 echo " ∗∗∗ applying patch ( es ) " 65 patch −p0 −b −N −s < $CWD/semtimedop_df && touch .patched .configured 66 f i 67 popd
69 i f [ −f $UCLIBC_DIR/.patched ]; then 70 echo " ∗∗∗ recompiling buildroot " 71 pushd buildroot 72 make 73 popd 74 f i
Zusätzlich musste der Sourceball selbst verändert werden, denn das fehlgeschlagene Entpacken der Lizenzdatei führt ebenfalls zum Abbruch der Installation:
Listing C.2: IBE Sourceball
1 UnTARlic() 2 { 3 # t a r $1vf − ./ LICENSE > / dev / n u l l 2>&1 || { echo E x t r a c t i o n o f LICENSE f a i l e d . > / dev / t t y ; k i l l −15 $$ ; } 4 tar $1vf − ./LICENSE > /dev/null 2>&1 || { echo Extraction of LICENSE failed. > /dev/tty; } 5 }
C.2 ConverGate-D Linux Kernel Treiber: drv cg, v3.2.5
Die folgenden Probleme beziehen sich auf die Datei drv_cg_linux.c in dem Verzeichnis ~/projects/buildroot/build_powerpc/drv_cg/src.
Genannt wird jeweils die Funktion und die Problembeschreibung, welche mögliche Lösungen bereits impliziert.
1. cg_open(): Das Gerät /dev/cg/
1>= 1 wenn das Gerät Daten zum Lesen bereit hat
Anhang C Errata C.2 ConverGate-D Linux Kernel Treiber: drv_cg, v3.2.5 - 133 - Fachhochschule Hof
3. cg_write(): Standardmäßig bekommt man von write() den Wert des übergebenen Wertes count zu- rück. cg_write() allerdings gibt nur die Größe des tatsächlich versendeten Netzwerkpake- tes zurück 2, was nicht konform zu der Standardanwendung des write() Befehls ist.
C.3 ConverGate-D Linux Kernel Treiber Erweiterungen
Die Befehle CG_UC_FWD_FIB_VALUE_Assign() und CG_UC_FWD_FIB_VALUE_Query() (sie- he 3.2.4.5 ConverGate-D Treiber: drv_cg v3.2.5) sind nur mit 16 bzw. 32-Bit Werten getestet wor- den.
C.4 ConverGate-D Treiber: cg connectix
Wenn Änderungen an lib_we_cgd durchgeführt werden, wird nicht automatisch auch cg_connectix neu übersetzt bzw. gelinkt. Dann muss die Datei per Hand gelöscht und make erneut ausgeführt werden: ˜/projects/buildroot/build_powerpc/build.24/easy4271/cg_connectix/cgd-easy4271/cg_connectix. Siehe 3.2.4.4 ConverGate-D Treiber: lib_we_cgd v0.0.2.
2sizeof(ConverGate-D Paket) - sizeof(ConverGate-D Paketinformationen) = sizeof(Netzwerkpaket)
C.4 ConverGate-D Treiber: cg_connectix Anhang C Errata Diplomarbeit - 134 -
Anhang D
Offene Themen bzgl. der BorderGateway Software
Hier soll stichpunktartig auf diverse Probleme und offene Thematiken der BorderGateway Soft- ware aufgelistet werden: 1. LAN-Ports 0 und 1 arbeiten im Gigabit-Modus. Wenn Fast-Ethernet-Hardware angeschlos- sen wird, zeigt das ConverGate-D Evaluation Board zwar die korrekte Geschwindigkeit an, aber es können keine Pakete über diesen Port empfangen oder geschickt werden. 2. Die automatische Ermittlung der eigenen IP-Adresse auf dem MPC-Modul funktioniert nicht mehr, seitdem die ConverGate-D Evaluation Boards bei Alcatel-Lucent ausgetauscht wurden. Obwohl kein Fehler vom Betriebssystems gemeldet wird, beträgt die lokale IP- Adresse immer 0.0.0.0. Siehe Configuration_Init() in commands.c. 3. Alle Quellcode-Header-Dateien sollten C++ kompatibel sein: #ifdef __cplusplus extern "C"{ #endif . . . #ifdef __cplusplus } #endif
4. Beim Einpacken von SIP-Paketen wird der „Time to Live“-Wert nicht auf 0 überprüft. Laut [4] dürfen Pakete mit ttl==0 nicht weitergeleitet werden. Zudem muss der Type of Service des äußeren Headers dem des Inneren entsprechen und, wenn das „Don’t Fragment“-Bit des inneren Headers gesetzt ist, muss dies auch im äußeren Header gesetzt sein. 5. Laut [12] muss die Echo-Request-Nachricht 1:1 zurückgegeben werden. Im Moment wird allerdings Code auf 0 gesetzt. 6. Globale Variablen im TLV-Code sind nicht vor parallelen Zugriffen geschützt. 7. Folgende Themen sind in [1] vorhanden oder im Laufe des Projektes aufgetaucht, aber aufgeschoben oder nicht besprochen worden: a) Protokollparameter für das „Firewall/NAT!1 Learningïst offen: State of Termination, Learning style.
1NAT!
Anhang D Offene Themen - 135 - Fachhochschule Hof
b) DiffServ Code Point oder Quality of Service? c) Bandbreite und QoS für jeden Halfcall? d) Kann die IP-Adresse des MPC-Modul zur Laufzeit geändert werden? Wenn nicht, kann TLV-Parameter 0x53 entfallen. 8. MPC-Modul ⇔ Media-Translation (PosPHY-Schnittstelle) ist nicht definiert. 9. QoS sowie Bandbreitenbegrenzung wurde nicht implementiert. 10. Statistiken über ein- und ausgehende Pakete sind global auf die beiden GbE-Schnittstellen bezogen. Allerdings sollten diese auf Halfcall-Basis geführt werden. Dafür ist die momen- tane Konfiguration nicht entworfen worden. Diese Funktion könnte über Sub-Ports unter- stützt werden2, was aber erst bewiesen werden muss.
2UMPR: Statistics API - CG_STATISTICS_SportStatsGet()
Anhang D Offene Themen Diplomarbeit - 136 -
Anhang E
Benutzte Software
In diesem Kapitel werden die wichtigsten Programme im Zusammenhang mit der Erstellung der BorderGateway Software kurz vorgestellt.
E.1 Betriebssysteme
Folgende Betriebssysteme wurden in der Entwicklung der BorderGateway Software einge- setzt. • Microsoft Windows 2000: 5.00.2195, Service Pack 4, Deutsche Standardinstallation • Ubuntu Linux v6.06 (Dapper Drake): Linux Kernel 2.6.26 (x86) Um Pakete zu installieren, kann über die Kommandozeile Folgendes eingegeben werden: apt-get install
E.2 ARP / ICMP Generierung
E.2.1 Linux: arping, ping
Für die ARP bzw. ICMP Generierung hält Linux standardmäßig die Programme arping bzw. ping bereit. Für die ARP Generierung wurde arping verwendet, da ping nach dem ersten erfolgreichen ARP- Paket keine weiteren ARP-Pakete mehr aussendet. Arping muss normalerweise mit root- oder Superuser-Rechten ausgeführt werden, da direkter Zugriff auf Ethernet-Schnittstellen stattfin- det. Um ICMP-Pakete zu generieren, wurde ping verwendet.
Nachfolgend die verwendeten Kommandozeilenaufrufe für die einzelnen Programme. • arping, mit einem ARP-Paket: arping -c 1 -I
1Ethernet Interface: eth0, eth1, ...
Anhang E Benutzte Software E.2 ARP / ICMP Generierung - 137 - Fachhochschule Hof
• arping, um doppelte IP Adressen im Netzwerk zu finden: arping -c 1 -D -I
E.2.2 Windows: arp.exe, ping.exe
In Windows gibt es standardmäßig leider kein equivalentes Programm zu Linux’ arping. Es exis- tiert lediglich arp.exe, welches zum Manipulieren der MAC Adressen dient. Dafür gibt es ein ping eqivalent, ping.exe.
Hier der Kommandozeilenauf für ping.exe
• ping.exe, mit einem ICMP Paket: ping -n 1
Hinweis: ping.exe sucht sich selbstständig das lokale Netzwerkinterface 2 aus, über welches es die ICMP-Pakete verschickt. Daher ist es notwendig, dem lokalen Netzwerkinterface den glei- chen Adressraum zu geben, z.B.: Es soll über ein eingebautes Netzwerkinterface mit der IP-Adresse 192.168.152.10 ein ICMP- Paket an 192.168.4.10 geschickt werden. Hierzu muss über Systemsteuerung->Netzwerk- und DFÜ-Verbindungen die Eigenschaften des entsprechenden Interfaces geöffnet und eine zusätzli- che, im Netzwerk freie IP-Adresse, angegeben werden, in unserem Fall z.B. 192.168.4.11.
E.3 Serielle Verbindung zu dem ConverGate-D Evaluation Board
Für die netzwerkunabhängige Kommunikation über die serielle Schnittstelle mit dem ConverGate-D Evaluation Board wurden folgende Programme verwendet:
• Linux: cu (Taylor UUCP package) 1.07 mit der folgenden Kommandozeile: cu -l /dev/ttyS0 -s 115200 -e -o • Windows: ZOC/Pro 4.14 (http://www.emtec.com)
Standardeinstellungen: 115200 Baud, 8 Datenbits, keine Parität, 1 Prüfbit (8N1)
Siehe 3.1.2 ConverGate-D Evaluation Board: Modell easy4271.
2Interface, welches in dem PC vorhanden ist, von dem ein Paket verschickt werden soll
E.4 Ethernet Paketüberwachung Anhang E Benutzte Software Diplomarbeit - 138 -
E.4 Ethernet Paketuberwachung¨
Zum Überprüfen von verschickten Paketen wurden sog. LAN-Analysierprogramme verwendet. Mit diesen Programmen können der Netzwerkverkehr überwacht und einzelne Pakete analysiert werden. Folgend die Details: • Linux: tcpdump v3.9.4 (libpcap v0.9.4) mit der folgenden Kommandozeile: tcpdump -enqti
E.5 Testpaketgenerierung
Für die automatische Generierung von einfachen Testpaketen wurde das Windows Programm Komodia PacketCrafter 1.4 (http://www.komodia.com/) verwendet.
E.6 TFTP - Trivial File Transfer Protocol
Windows und Linux bieten jeweils ein Client-Programm names tftp[.exe] zum einfachen 3 Über- tragen von Dateien auf den lokalen Rechner von einem fremden Rechner oder umgekehrt. Hierfür muss allerdings auf dem Fremdrechner ein TFTP-Server laufen. Die nötigen Programme in der folgenden Liste: • Linux Client: tftp (tftp-hpa package: apt-get install tftp-hpa) Kommandozeile: tftp -m binary
3trivial 4Daemon
Anhang E Benutzte Software E.7 NFS - 139 - Fachhochschule Hof
E.7 NFS - Network File System
Hier folgt nun eine kurze Anleitung, um NFS in Ubuntu Linux zu installieren. Das embedded Linux Kernel des MPC-Modul hat bereits einen NFS Client eingebaut, siehe 3.2.2.3 NFS Bootvor- gang.
1. Es sollten folgende Pakete installiert sein: nfs-common, nfs-kernel-server, portmap. Kommandozeile: apt-get install nfs-common nfs-kernel-server portmap 2. Einen Softlink anlegen: Linkname: /exports/easy4271 Linkziel: ˜/projects/buildroot/build_powerpc/fs.24/easy4271/ 3. In Datei /etc/exports Zeile hinzufügen (Hilfe siehe ’man exports’): /exports/easy4271 192.168.152.18/255.255.255.0(rw,async,no_root_squash) 4. In Datei /etc/hosts.allow Zeile hinzufügen (Hilfe siehe ’man hosts’): portmap: 192.168.152.0/255.255.255.0 nfsd: 192.168.152.18 5. Neustart des NFS-Server: /etc/init.d/nfs-kernel-server restart
E.8 Erstellung der Diplomarbeit
Dieses Dokument wurde in LATEX geschrieben und mit dem Windows Programm MiKTeX 2.5 nach PDF übersetzt. (http://www.miktex.org/)
E.9 Bilder, Diagramme
Bilder und Diagramme wurden in Windows mit folgenden Programmen erstellt:
• UML Pad v2.1: Open-Source-Werkzeug für Windows von Luigi Bignami http://web.tiscali.it/ggbhome • Microsoft PowerPoint 2002 (10.2623.2625)
• Gimp v2.2.11 Open-Source-Bildbearbeitung in Linux.
E.10 Quellcodedokumentation Anhang E Benutzte Software Diplomarbeit - 140 -
E.10 Quellcodedokumentation
E.10.1 Doxygen
Die HTML-Quellcodedokumentation wurde mit der Linux Version von Doxygen v1.4.6 (http: //www.stack.nl/~dimitri/doxygen/index.html) erstellt und danach mit dem Windows Mi- crosoft HTML Help Workshop (http://de.wikipedia.org/wiki/Microsoft_Help) in *.chm5 übersetzt.
Um Beziehungsgraphen in der Quellcodedokumentation zu erstellen, wurde zusätzlich das Linux Programm dot v2.2.1 (graphviz package) installiert, welches von Doxygen automatisch benutzt wird (falls gewünscht).
E.10.2 Quellcodestatistik: cncc
Die Quellcodestatstik (F.1 Quellcode) wurde mit cncc erstellt. Programm: cncc v1.3 (2003-2004) Autor: Alex Vinokur ([email protected]), http://up.to/alexv Kommandozeile: cncc ./src/include/*.h ./src/*.c
E.11 Dateimanager / Editor
Als Dateimanager sowie Editor wurde das Windows/Linux Programm NDN6 (http://ndn. muxe.com/) verwendet, welches vom Autor dieser Diplomarbeit selbst entwickelt wird.
5Compressed HTML Help File 6Necromancer’s Dos Navigator
Anhang E Benutzte Software E.11 Dateimanager / Editor - 141 - Fachhochschule Hof
Anhang F
Technische Informationen
Dieser Anhang beschreibt verschiedene technische Informationen, denen der Autor kein eigenes Kapitel zuordnen wollte.
F.1 Quellcode
Der Quellcode zu der BorderGateway Software befindet sich auf der beiliegenden CD im Wur- zelverzeichnis unter src.
Hier einige statistische Angaben über den Quellcode im Verzeichnis build_powerpc/bordergateway/src/ (*.c) und build_powerpc/bordergateway/src/include (*.h) (siehe E.10.2 Quellcodestatistik: cncc). Diese Statistik beinhaltet nicht die Änderungen an Quellcode bzw. Programmen aus 3.2 Vorhandene Software / Werkzeuge.
Tab. F.1: Quellcodestatistik Beschreibung Zeilen Zeichen Code 7568 (50.4 %) 186673 (48.3 %) Code + Kommentare 321 (2.1 %) - (- %) Kommentare 4845 (32.3 %) 165175 (42.7 %) Leer 2272 (15.1 %) 34819 (9.0 %) Gesamt 15006 (100 %) 386667 (100 %)
F.2 Bytereihenfolge (byte order)
Es gibt zwei grundlegende Arten, wie Rechner Dateneinheiten > 1 Byte speichern1. Die Unter- scheidung wird Anhand des Bytes getroffen, mit dem der Datensatz im Speicher beginnt. Diese sollen hier kurz erläutert werden.
• Big endian: Dies ist die Bytereihenfolge, die im Internet und Netzwerken gebräuchlich ist. Daher nennt man sie network byte order. Hierbei wird das „most significant byte“ als Erstes gespei- chert. Das MPC-Modul sowie der ConverGate-D arbeiten mit diesem Speicherlayout, wobei das MPC-Modul allerdings auch in Little Endian betrieben werden kann. Beispiel: 1Es gibt noch weitere, welche aber eher selten und nach Ansicht des Autors unpraktikabel sind
F.2 Bytereihenfolge (byte order) Anhang F Technische Informationen Diplomarbeit - 142 -
Tab. F.2: Big endian Beispiel Größe Wert in C Wert im Speicher 16-Bit 0xaabb aa bb 32-Bit 0xaabbccdd aa bb cc dd
• Little endian: Dieses Speicherlayout wird vor allem in Intel kompatiblen Rechnern verwendet. Dieses Layout heißt host byte order. Hier wird das „least significant byte“ als Erstes gespeichert. Der Control-PC arbeitet in diesem Format. Beispiel:
Tab. F.3: Little endian Beispiel Größe Wert in C Wert im Speicher 16-Bit 0xaabb bb aa 32-Bit 0xaabbccdd dd cc bb aa
Diese Unterscheidung ist entscheidend im Umgang mit IP-Adressen und UDP-Port-Numern.
F.3 ConverGate-D Daten
Einige Informationen zum ConverGate-D: 2 [6]
Tab. F.4: ConverGate-D - Technische Daten Hersteller Infineon Technologies AG Modell Bezeichnung Access Network Processor, PXF 4271E Stromverbrauch 2,8 W (max.) Firmware Code Speicher 64 kB Vergleichsspeicher (BCAM) 2 kB x 64-Bit = 16 kB Segment Speicher (SSB) 3 Mbit = 128 kB*3 = 384 kB (Paketspeicher, PDUs) MAC-Adresse 00:03:19:5f:42:47 (00 03 19 = Infineon, 5f 42 47 = ’_BG’)
F.4 MPC-Modul Daten
Wissenswerte Daten zum MPC-Modul: 3
Tab. F.5: MPC-Modul - Technische Daten Hersteller Freescale (www.freescale.com) CPU Modell Bezeichnung XPC862PZPnnB (MPC862, Motorola POWER Chip) Frequenz 80 MHz Board Modell TQM862LDB0A03 DRAM 16 MB Flash-Speicher 8 MB
2MAC Information: http://standards.ieee.org/regauth/oui/oui.txt 3PowerPC Architektur, PowerQUICC: MPC 860 Quad Integrated Communications Controller
Anhang F Technische Informationen F.5 Buildroot Daten - 143 - Fachhochschule Hof
F.5 Buildroot Daten
Die Buildroot ist eine sog. Chroot4, da ihre Funktion auf dem Linux Befehl chroot basiert. Wei- terführende Links: Buildroot: http://buildroot.busybox.net/ BusyBox: http://busybox.net/ Embedded System: http://de.wikipedia.org/wiki/Eingebettetes_System Projektseite: http://developer.berlios.de/projects/buildroot Chroot Informationen: http://de.wikipedia.org/wiki/Chroot
F.6 uClibc: semtimedop Patch
Die Patch-Datei befindet sich im Quellcodeverzeichnis src/ und heißt semtimedop_df. Der Patch wurde hier gefunden http://bugs.busybox.net/print_bug_page.php?bug_id=927. Als Bei- spiel für das Hinzufügen der Erweiterungen siehe Listing C.1, Zeile 14-25. Siehe http://buildroot.uclibc.org/.
F.7 Installation des gesamten Quellcode
Für eine einfache und schnelle Installation des benutzten Quellcodes, hat der Autor ein Instal- lationsskript geschrieben, welches alle nötigen Installationsoperationen automatisiert ausführt. Hierzu werden folgende Dateien in ˜/projects/ kopiert: bg_src.tgz, buildroot_easy4271.sh, in- stall.sh, readme.txt und semtimedop_df. install.sh ist das Installationsskript, welches ausgeführt werden muss, siehe Listing C.1. Bei Ers- tinstallationen kann dieser Vorgang einige Zeit dauern kann und evtl. mehrere Neustarts erfor- den, falls Pakete nachinstalliert werden mussten. Erfolgreich abgeschlossene Installationsschrit- te müssen nicht wiederholt werden. Auch die Konfiguration der IBE wird ausgeführt. Nach er- folgreichem make-Prozess ist der Quellcode installiert, von dem aus die letzte Software-Version für Alcatel-Lucent entwickelt und geliefert wurde.
Für eine Fehlerbeschreibung über den Sourceball siehe C.1 Sourceball buildroot_easy4271.sh.
F.8 Erstellen eines Sourceballs
Um einen Sourceball5 zu erstellen, kann im ˜/projects/buildroot/ Verzeichnis folgender Befehl ausgeführt werden: make ifx_sourceball. Das Ergebnis dieses Befehls ist eine *.sh und eine *.tar.gz Datei, wobei nur die *.sh Datei behalten werden muss, denn diese beinhaltet bereits die *.tar.gz Datei. Die Dateien werden im nächsthöheren Verzeichnis ˜/projects/buildroot/.. erstellt.
4change root: Verändern, umlenken des Wurzelverzeichnis 5Selbstinstallierendes Archiv
F.9 BorderGateway Software: KommandozeilenparameterAnhang F Technische Informationen Diplomarbeit - 144 -
F.9 BorderGateway Software: Kommandozeilenparameter
Abb. F.1: BorderGateway Software - Kommandozeilenparameter
Anhang F Technische InformationenF.9 BorderGateway Software: Kommandozeilenparameter - 145 - Fachhochschule Hof
F.10 BorderGateway: Makefile.am
Diese Datei befindet sich in ˜/projects/buildroot/build_powerpc/bordergateway/src/. Die Control-PC Software wird in diesem Verzeichnis mit make -f Makefile.am x86test übersetzt.
Listing F.1: BorderGateway Makefile.am
1 a l l : 2 @echo "−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−" 3 @echo "−−− creating BORDERGATEWAY application −−−" 4 @echo "−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−"
6 x86test: bordergateway.c $(common_sources) 7 @echo "−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−" 8 @echo "−−−−− creating X86 t e s t application −−−−−−" 9 @echo "−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−" 10 @gcc $(AM_CFLAGS) −D__BYTE_ORDER=__LITTLE_ENDIAN \ 11 −DX86 \ 12 −DBORDERGATEWAY \ 13 −Iinclude \ 14 −I t e s t \ 15 −I../../drv_cg_eb/src \ 16 −I../../drv_cg/src \ 17 −I../../drv_cg/src/ioctl \ 18 −lpthread −lm \ 19 −o x86test \ 20 bordergateway . c \ 21 $(common_sources)
23 bin_PROGRAMS = bordergateway
25 # t h e s e s o u r c e s are n e c e s s a r y f o r the X86 t e s t program as w e l l 26 common_sources = \ 27 bordergateway_linux.c\ 28 commandline . c \ 29 configuration . c \ 30 udp_sockets . c \ 31 t l v . c \ 32 commands . c \ 33 context . c \ 34 s i m c l i s t . c \ 35 sip . c \ 36 eth . c \ 37 ip . c \ 38 arp . c \ 39 packet . c \ 40 icmp . c \ 41 raw_sockets . c \ 42 udp . c \ 43 fault_pipe . c
45 # t h e s e modules u s a b l e f o r the s o f t w a r e on the MPC module only 46 bg_sources = $(common_sources) \ 47 evalboard . c \ 48 convergate . c \ 49 bcfa . c
51 ## main program 52 bordergateway_SOURCES = \ 53 bordergateway.c $(bg_sources)
55 AM_CPPFLAGS = \ 56 −I@srcdir@ \ 57 −I@top_srcdir@/.. \ 58 −I@KERNEL_BUILD_PATH@/ include \ 59 −I@KERNEL_BUILD_PATH@/ include2 \ 60 −I@KERNEL_INCL_PATH@ \ 61 −I@srcdir@/test \ 62 −I@srcdir@/../../drv_cg_eb/src \ 63 −I@srcdir@/../../drv_cg/src \ 64 −I@srcdir@/../../drv_cg/src/ioctl
66 INCLUDES = −I@builddir@/include \ 67 −I@srcdir@/include
69 AM_CFLAGS= −DLINUX −D__LINUX__\ 70 −O2 −ansi −fPIC \ 71 −Wall −Werror −Wimplicit −Wswitch \ 72 −Wcomment −Wuninitialized −Wparentheses −Wpointer−arith −Wsign−compare \ 73 −Wmissing−braces −Wreturn−type −Wformat−security \ 74 −Winline −Wformat −Wformat−extra−args −Wunused
76 # c f l a g s f o r BG application 77 bordergateway_CFLAGS = $(AM_CFLAGS) −DBORDERGATEWAY
79 bordergateway_LDADD = −lpthread −lm
F.10 BorderGateway: Makefile.am Anhang F Technische Informationen Diplomarbeit - 146 -
Literaturverzeichnis
[1] Banniza, Thomas R.: Functional MSS+6 Specification (M4.9: Specification of BorderGate- way Functions for Implementation on Infineon Chip Platform) , Alcatel-Lucent Stuttgart, 1. Februar 2007, Unpublished/Confidential. [2] GNU/Linux: Linux Quellcode v2.4.31. [3] GNU/Linux: The Linux Manpages. [4] IBM: RFC 2003: IP Encapsulation within IP, Oktober 1996, http://www.rfc-editor.org/, http://www.ibm.com/. [5] Infineon Technologies AG München: Convergate-D Linux-Kernel-Treiber Quellcode v3.2.5, 2006, Unpublished/Confidential. [6] Infineon Technologies AG München: Convergate-D (PXF 4271 E), Version 1.2, User’s Ma- nual, Functional Description, Rev. 3.0 , 15. Mai 2006, Unpublished/Confidential. [7] Infineon Technologies AG München: Convergate-D (PXF 4271 E), Version 1.2, User’s Ma- nual, Functional Firmware Description, Rev. 3.0 , 22. Mai 2006, Unpublished/Confiden- tial. [8] Infineon Technologies AG München: Convergate-D (PXF 4271 E), Version 1.2, User’s Ma- nual, Programmer’s Reference, Rev. 4 , 5. Mai 2006, Unpublished/Confidential. [9] Li, Beier: Bordergatewayimplementation on a network processor, Masterarbeit, TU Mün- chen, August 2007. [10] Plummer, David C.: RFC 826: An Ethernet Address Resolution Protocol, DCP@MIT-MC, November 1982, http://www.rfc-editor.org/. [11] Postel, J.: RFC 768: User Datagram Protocol, USC/ISI, 28 August 1980, http://www. rfc-editor.org/, http://www.isi.edu/. [12] Postel, J.: RFC 792: Internet Control Message Protocol, USC/ISI, September 1981, http: //www.rfc-editor.org/, http://www.isi.edu/. [13] Rosenberg, J., Schulzrinne, H., Camarillo, G., et al.: RFC 3261: Session Initiation Pro- tocol, The Internet Society, June 2002, http://www.rfc-editor.org/, http://www. isoc.org/. [14] USC/ISI: RFC 791: Internet Protocol (v4), September 1981, http://www.rfc-editor. org/, http://www.isi.edu/.
6Enhanced Media Stream Switching
Literaturverzeichnis - 147 - Fachhochschule Hof
Internetverzeichnis
[15] Barr, Michael: Additive Checksums, http://www.netrino.com/Connecting/1999-11/ index.php, siehe Seite 151. [16] MAMS: Multi Access, Modular Services Framework, http://www.mams-platform.de/, siehe Seite 148. [17] NGN, Wikipedia: Next Generation Network, http://de.wikipedia.org/wiki/Next_ Generation_Network, siehe Seite 149.
Internetverzeichnis Diplomarbeit - 148 -
Abb. F.2: MAMS Homepage
Internetverzeichnis - 149 - Fachhochschule Hof
Next Generation Network - Wikipedia Seite 1
Next Generation Network
aus Wikipedia, der freien Enzyklopädie
Next Generation Network (NGN ) ist ein Begriff aus der Telekommunikation, mit dem ein Kommunikationsnetz bezeichnet wird, das sich durch die Konvergenz herkömmlicher Netze (Telefonnetze, Mobilfunknetze etc.) mit IP-basierten Netzen ergibt.
Dabei zeichnet sich ein NGN durch eine Systemarchitektur aus, die im Wesentlichen aus folgenden Komponenten besteht:
Media Gateways welche die einzelnen Netze physikalisch verbinden und für die Übertragung von Informationen sorgen – einschließlich dabei notwendiger Format- und Datenkonvertierung, und Softswitches welche die Media Gateways steuern, und zum Beispiel Verbindungen über alle Netzgrenzen hinweg auf- und abbauen.
Im Gegensatz zu einem herkömmlichen Vermittlungssystem, das vergleichbare Funktionskomponenten in sich vereinigt (wenn auch nur für einen Netztyp), geht man davon aus, dass Media Gateways und Softswitches getrennte Systeme sind, die auch an unterschiedlichen Orten aufgestellt sind. Stark vereinfacht dargestellt wird ein herkömmliches Vermittlungssystem physikalisch in zwei Teile geteilt, wobei entsprechende Gatewayfunktionen hinzugefügt werden. Hinzu kommt, dass der Softswitch selber wiederum als verteiltes System realisiert werden kann.
Durch die Trennung in Media Gateways und Softswitches wird erreicht, dass beide Teile unabhängig voneinander weiterentwickelt werden können. So erhofft man sich zum Beispiel, dass die Einführung eines neuen Dienstes nur Änderungen an den Softswitches erfordert. Andererseits benötigt man zur Einbindung einer neuen Netzwerktechnologie nur entsprechende neue Media Gateways an den Netzschnittstellen.
Neue Dienste in einem NGN werden auch als NGS (Next Generation Services ) bezeichnet. Erbracht werden diese Services von der sogenannten Service Delivery Platform (SDP).
Die langsam voranschreitende Verbreitung von Voice-over-IP-Telefonie (Stand 2004/2005) ist eine der treibenden Kräfte hinter der Entstehung von NGNs. Hier steht man in Zukunft in der Telekommunikation vor der Aufgabe, einen Massendienst (Telefonie) über eine völlig andere Netztechnologie als bisher üblich abwickeln zu müssen. Die spezifische NGN-Systemarchitektur ist die Antwort der Telekommunikation auf diese Herausforderung. Eine andere treibende Kraft sind die Kosten. Man erhofft sich, bei NGNs insgesamt sehr stark auf bereits installierte IP-Technologie zurückgreifen zu können und dass dies kostengünstiger ist als die Modernisierung und Weiterentwicklung der klassischen Vermittlungssysteme.
Einschränkungen
Viele Telekommunikationsanbieter gehen inzwischen dazu über, Festnetzanschlüsse nicht mehr unter Verwendung leitungsvermittelter Technik anzubieten, bei der die Stromversorgung des Anschlusses über die Vermittlungsstelle (VSt) erfolgt, sondern mittels NGN-Technologie.
An NGN-Anschlüssen kann es daher zu Verfügbarkeitseinschränkungen kommen, wenn im Falle eines Stromausfalls oder bei Problemen mit dem DSL-Anschluss (z. B. Anmelde- oder Synchronisationsprobleme)
http://de.wikipedia.org/wiki/Next_Generation_Network 28.07.2007 11:52:17
Internetverzeichnis Diplomarbeit - 150 -
Next Generation Network - Wikipedia Seite 2
ein Betrieb von Endgeräten nicht mehr möglich ist. Die Verwendung von Notrufeinrichtungen oder das direkte Absetzen von Notrufen kann somit nicht sichergestellt werden.
Ein anderes Problem ist die Verwendung geografischer Einwahlnummern. Da die Zugangs- und Standortinformationen oft im Integrated Access Device (Media Gateway) hinterlegt sind, ist es möglich, dieses an einem beliebigen Anschluss eines Anbieters zu benutzen. Die Lokalisierung eines Anrufers wird hierdurch erschwert oder sogar unmöglich. Betroffen sind hiervon standortnahe Leitzentralen von Rettungsdiensten, aber auch Angebote, die geografische Einwahlnummern besitzen um regionsspezifische Informationen bereitzustellen (Auskunfsdienste, Service- oder Callcenter, Sonderrufnummern).
Technisch kann es zu Einschränkungen beim Betrieb herkömmlicher Endgeräte (Faxgeräte, Modem, ISDN- Karte) kommen. So werden beispielsweise Schmalband-Datendienste nicht oder nur eingeschränkt unterstützt, da das Media Gateway oft nur Sprachdienste unterstützt und der Analog- bzw. ISDN-Anschluss über das Gerät nur nachgebildet bzw. emuliert wird. Auch spezifische Dienstmerkmale leitungsvermittelter Technik stehen nur selektiv zur Verfügung. Weblinks
ETSI TISPAN website (http://www.tispan.org) ECMA TR/91 "Enterprise Communication in Next Generation Corporate Networks (NGCN) involving Public Next Generation Networks (NGN) (Ecma-International, December 2005)" (also ISO/IEC DTR 26905 and ETSI TR 102 478) (http://www.ecma-international.org/publications/techreports/E-TR-091.htm) ITU-T Focus Group on Next Generation Networks (FGNGN) (http://www.itu.int/ITU-T/ngn/fgngn/ index.html) ITU-T NGN Management Focus Group (http://www.itu.int/ITU-T/studygroups/com04/ngn-mfg/ index.html)
Von „http://de.wikipedia.org/wiki/Next_Generation_Network“
Kategorien: VoIP | Telekommunikation | Kommunikationstechnik
Diese Seite wurde zuletzt am 21. Juli 2007 um 15:35 Uhr geändert. Ihr Inhalt steht unter der GNU-Lizenz für freie Dokumentation. Wikipedia® ist eine eingetragene Marke der Wikimedia Foundation Inc.
http://de.wikipedia.org/wiki/Next_Generation_Network 28.07.2007 11:52:17
Internetverzeichnis - 151 - Fachhochschule Hof
Additive Checksum Algorithms as Error Detection Codes Seite 1
Home About Us Design Training Technical Library Contact Us Glossary
Articles #error Directive Add-on Software Assembly vs. C ATVEF Protocol BDM Tools Bluetooth vs. IrDA Calibrating Hardware Checksums Compiled Java Configurable Computing Counter Hardware CRC Theory CRC Calculations Cross Compilers Digital Filters Efficient 8-bit C Embedded ARP Embedded IP Embedded Java Embedded TCP Endianness Fixed-Width Integers Function Pointers Internationalization ISR Minimization Java 2 Micro Edition Kaffe Java VM Lint Introduction Linux and the Law Memory Testing MAC Addresses Memory Types MISRA C Network Processors offsetof() Macro Open Source Terms Optimal C for 8051 PID Control Preemption Perils of Preemption Priority Inversion Programmable Logic PWM Signals RMA Scheduling RS-485 Enable RTOS Selection volatile Keyword Watchdog Timers
http://www.netrino.com/Connecting/1999-11/index.php 25.07.2007 23:20:53
Internetverzeichnis Diplomarbeit - 152 -
Additive Checksum Algorithms as Error Detection Codes Seite 2
Books
Article Additive Checksums
by Michael Barr
Whenever you connect two or more computers together with the intent of exchanging information, you assume that the exchange will take place without errors. But what if some of the data is lost or corrupted in transit? Communication protocols usually attempt to detect such errors automatically. To do that they use checksums.
The most important part of listening to someone speak is ensuring that you've heard them correctly. Your brain performs the tasks of error detection and correction for you, automatically. It does this by examining extra bits of information from the speaker and the speech; if a phrase or sentence makes sense as a whole and it makes sense coming from the mouth of the particular speaker, then the individual words were probably heard correctly. The same principle applies when you are reading. But what happens when computers are communicating with one another? How does the receiving computer know if an error has occurred in transmission?
Establishing correctness is more difficult for computers than humans. At the lowest level, communication between computers consists of nothing but a stream of binary digits. Meaning is only assigned to that particular sequence of bits at higher levels. We call that meaningful sequence of bits the message; it is analogous to a spoken or written phrase. If one or more bits within the message are inverted (a logic one becomes a logic zero, or vice versa) as it travels between computers, the receiver has no way to detect the error. No environmental or syntactical context is available to the receiver, since it cannot understand the message in its transmitted form.
Achieving parity
If we want communicating computers to detect and correct transmission errors automatically, we must provide a replacement for context. This usually takes the form of an error correction code or error detection code. A simple type of error detection code that you are probably already familiar with is called a parity bit. A parity bit is a single, extra binary digit that is appended to the message by the sender and transmitted along with it. Depending on the type of parity used, the parity bit ensures that the total number of logic ones sent is even (even parity) or odd (odd parity). For an example of even parity, consider the sequence:
10101110 1
in which the eight-bit message contains five ones and three zeros. The parity bit is one in this case to force the total number of ones in the transmitted data stream to be even.
When a parity bit is appended to a message, one additional bit of data must be sent between the computers. So there must be some benefit associated with the lost bandwidth. The most obvious benefit is that if any single bit in the message is inverted during transmission, the number of ones will either increase or decrease by one, thus making the received number of ones odd and the parity incorrect. The receiver can now detect such an error automatically and request a retransmission of the entire stream of bits. Interestingly, the receiver can also now detect any odd number of bit inversions. (Note that all of this still applies even when the parity bit is one of the inverted bits.)
However, as you may have already noticed, if two bits are inverted (two ones become zeros, for example), the parityof the stream of bits will not change; a receiver will not be able to detect such errors. In fact, the same is
http://www.netrino.com/Connecting/1999-11/index.php 25.07.2007 23:20:53
Internetverzeichnis - 153 - Fachhochschule Hof
Additive Checksum Algorithms as Error Detection Codes Seite 3
true for any even number of bit inversions.A parity bit is a weak form of error detection code. It has a small cost (one bit per message), but it is unable to detect manytypes of possible errors. (By the way, odd parity has the same costs, benefits, and weaknesses as even parity.)
Perhaps this is not acceptable for your application. An alternative that might occur to you is to send the entire message twice. If you're already spending bandwidth sending an error detection code, why not spend half of the bandwidth? The problem is that you could actually be spending much more than half of the available bandwidth. If a computer receives two copies of a message and the bits that comprise them aren't exactly the same, it cannot tell which one of the two is correct.In fact, it may be that both copies contain errors. So the receiver must request a retransmission whenever there is a discrepancy between the message and the copy sent as an error detection code.
With that in mind, let's compare the bandwidth costs of using a parity bit vs. resending the entire message. We'll assume that all messages are 1,000-bits long and that the communications channel has a bit error rate (average number of inverted bits) of one per 10,000 bits sent. Using a parity bit, we'd spend 0.1% of our bandwidth sending the error detection code (one bit of error protection for 1,000 bits of message) and have to retransmit one out of every 10 messages due to errors. If we send two complete copies of each message instead, the smallest unit of transmission is 2,000 bits (50% of our bandwidth is now spent sending the error detection code). In addition, we'll have to retransmit one out of every five messages. Therefore, the achievable bandwidths are approximately 90% and 40%, respectively. As the width of the code increases, the message plus code lengthens and becomes more vulnerable to bit errors and, as a result, expensive retransmissions.
From this type of analysis it should be clear that keeping the size of an error detection code as small as possible is a good thing,even if it does mean that some types of errors will be undetectable. (Note that even sending two copies of the message is not a perfect solution. If the same bit errors should happen to occur in both copies, the errors will not be detected by the receiver.) In addition to reducing the bandwidth cost of transmitting the error detection code itself, this also increases the message throughput. But we still don'twant to goso far as using a one-bit error detection scheme like parity. That would let too many possible errors escape detection.
In practice, of course, we can achieve far better error detection capabilities than just odd numbers of inverted bits. But in order to do so we have to use error detection codes that are more complex than simple parity, and also contain more bits. I'll spend the remainder of this column and most of the next two discussing the strengths and weaknesses of various types of checksums, showing you how to compute them, and explaining how each can be best employed for purposes of error detection.
Checksums
As the name implies, a checksum usually involves a summation of one sort or another. For example, one of the most common checksum algorithms involves treating the message like a sequence of bytes and summing them. Listing 1 shows how this simple algorithm might be implemented in C.
unsigned char Sum(unsigned char const message[], int nBytes) { unsigned char sum = 0;
while (nBytes-- > 0) { sum += *(message++); }
return (sum);
} /* Sum() */
Listing 1. A Sum-of-Bytes Checksum
The sum-of-bytes algorithm is straightforward to compute. However, understanding its strengths and weaknesses as a checksum is more difficult. What types of errors does it detect? What errors is it unable to detect? These are important factors to consider whenever you are selecting a checksum algorithm for a particular application. You want the algorithm you choose to be well matched to the types of errors you expect to http://www.netrino.com/Connecting/1999-11/index.php 25.07.2007 23:20:53
Internetverzeichnis Diplomarbeit - 154 -
Additive Checksum Algorithms as Error Detection Codes Seite 4
occur in your transmission environment. For example, a parity bit would be a poor choice for a checksum if bit errors will frequently occur in pairs.
A noteworthy weakness of the sum-of-bytes algorithm is that no error will be detected if the entire message and data are somehow received as a string of all zeros. (A message of all zeros is a possibility, and the sum of a large block of zeros is still zero.) The simplest way to overcome this weakness is to add a final step to the checksum algorithm: invert the bits of the final sum. The new proper checksum for a message of all zeros would be FFh. That way, if the message and checksum are both all zeros, the receiver will know that something's gone terribly wrong. A modified version of the checksum implementation is shown in Listing 2.
unsigned char SumAndInvert(unsigned char const message[], int nBytes) { unsigned char sum = 0;
while (nBytes-- > 0) { sum += *(message++); }
return (~sum);
} /* SumAndInvert() */
Listing 2. A Slightly More Robust Version of the Sum-of-Bytes Algorithm
This final inversion does not affect any of the other error detection capabilities of this checksum, so let's go back to discussing the basic sum-of-bytes algorithm in Listing 1. First, it should be obvious that any single bit inversion in the message or checksum will be detectable. Such an error will always affect at least one bit within the checksum. (It could affect more, of course, but not less.) Observe that the sum-of-bytes is performed by essentially lining up all of the bytes that comprise the message and performing addition on them, like this:
10110101 11000000 00001101 + 11100011 ------01100101
Because of this mathematical arrangement, simultaneous single-bit inversions could occur in each of any number of the "columns." At least one bit of the checksum will always be affected. No matter how the inversions occur, at least the lowest-order column with an error will alter the checksum. This is an important point, because it helps us to understand the broader class of errors that can be detected by this type of checksum. I'll say it again: no matter how the inversions occur, at least the lowest order column with an error will alter the checksum, which means that two or more bit inversions in higher-order columns may cancel each other out. As long as the lowest-order column with an error has only one, it doesn't matter what other errors may be hidden within the message.
Now let's step back for a minute and talk about errors more formally. What exactly does a transmission error look like? Well,the first and most obvious type of error is a single bit that is inverted. That happens sometimes and is easy to detect (even a parity bit will do the job). Other times, bit inversions are part of an error burst. Not all of the bits within an error burst must be inverted. The defining characteristic is simply an inverted bit on each end. So an error burst may be 200 bits long, but contain just two inverted bitsÑone at each end.
A sum-of-bytes checksum will detect the vast majority of error bursts, no matter what their length. However, describing exactly which ones is generally difficult. Only one class of error bursts is always detectable: those of length eight bits or less. As long as the two inverted bits that bound the error burst have no more than six bits between them, the error will always be detected by this algorithm. That's because our previous requirement for error detectionÑthat the lowest-order column with an error have only one errorÑis always met when the length of the error burst is no longer than the width of the checksum. We can know with certainty that such errors will always be detected.
http://www.netrino.com/Connecting/1999-11/index.php 25.07.2007 23:20:53
Internetverzeichnis - 155 - Fachhochschule Hof
Additive Checksum Algorithms as Error Detection Codes Seite 5
Of course, many longer error bursts will also be detected. The probability of detecting a random error burst longer than eight bits is 99.6%. Errors will only be overlooked if the modified message has exactly the same sum as the original one, for which there is a 2-8 chance. That's much better error detection than a simple parity bit, and for not too much more cost.
The sum-of-bytes algorithm becomes even more powerful when the width of the checksum is increased. In other words, increasing the number of bits in the checksum causes it to detect even more types of errors. A 16-bit sum-of-words checksum will detect all single bit errors and all error bursts of length 16 bits or fewer. It will also detect 99.998% of longer error bursts. A 32-bit sum will detect even more errors. In practice, this increase in performance must be weighed against the increased cost of sending the extra checksum bits as part of every exchange of data.
Internet checksum
Many protocol stacks include some sort of a checksum within each protocol layer. The TCP/IP suite of protocols is no exception in this regard. In addition to a checksum at the lowest layer (within Ethernet packets, for example), checksums also exist within each IP, UDP, and TCP header. Figure 1 shows what some of these headers look like in the case of some data sent via UDP/IP. Here the fields of the IP header are summed to generate the 16-bit IP checksum and the data, fields of the UDP header, and certain fields of the IP header are summed to generate the 16-bit UDP checksum.
Figure 1. UDP and IP Headers with Checksum Fields Highlighted
A function that calculates the IP header checksum is shown in Listing 3. This function can be used before sending an IP packet or immediately after receiving one. If the packet is about to be sent, the checksum field should be set to zero before calculating the checksum and filled with the returned value afterward. If the packet has just been received, the checksum routine is expected to return a value of 0xFFFF to indicate that the IP header was received correctly. This result is a property of the type of addition used to compute the IP checksum.
unsigned short NetIpChecksum(unsigned short const ipHeader[], int nWords) { unsigned long sum = 0;
/* * IP headers always contain an even number of bytes. */ while (nWords-- > 0) { sum += *(ipHeader++); }
/* * Use carries to compute 1's complement sum. */
http://www.netrino.com/Connecting/1999-11/index.php 25.07.2007 23:20:53
Internetverzeichnis Diplomarbeit - 156 -
Additive Checksum Algorithms as Error Detection Codes Seite 6
sum = (sum >> 16) + (sum & 0xFFFF); sum += sum >> 16;
/* * Return the inverted 16-bit result. */ return ((unsigned short) ~sum);
} /* NetIpChecksum() */
Listing 3. IP Header Checksum Calculation
The IP header to be checksummed should be passed to NetIpChecksum() as an array of 16-bit words. Since the length of an IP header is always a multiple of four bytes, it is sufficient to provide the header length as a number of 16-bit words. The checksum is then computed by the function and returned to the caller for insertion into the header for validation of the header contents.
When you first look at this function, you may be overcome with a feeling of deja vu . The IP checksum algorithm begins in much the same way as the sum-of-bytes algorithm I discussed earlier. However, this algorithm is actually different. First, of course, we're computing a 16-bit checksum instead of an eight-bit one, so we're summing words rather than bytes. That difference is obvious. Less obvious is that we're actually computing a ones complement sum.
Recall that most computers store integers in a twos complement representation. Simply adding two integers, as we did in the previous algorithm, will therefore result in a twos complement sum. In order to compute the ones complement sum, we need to perform our addition with "end around carry." This means that carries out of the most significant bit (MSB) are not discarded, as they were previously. Instead, carries are added back into the checksum at the least significant bit (LSB). This could be done after each addition, but testing for a carry after each addition is expensive in C. A faster way is to let the carries accumulate in the upper half of a 32-bit accumulator. Once the sum-of-words is complete, the upper half of the 32-bit accumulator is turned into a 16-bit value and added to the 16-bit twos complement sum (the lower half). One final carry is possible at that point, and must be included in the final sum. The IP checksum is the inverted ones complement sum of all of the words in the IP header.
For checksum purposes, ones complement arithmetic has an important advantage over twos complement arithmetic. Recall that the biggest weakness of a parity bit is that it can't detect a pair of bit errors or any even number of errors, for that matter. A twos complement sum suffers from a similar weakness. Only one of the bits inthe sum (the MSB) is affected by changes in the most significant of the 16 columns. If an even number of bit errors occurs within that column, the checksum will appear to be correct and the error will not be detected. A ones complement sum does not suffer this weakness.
Because carries out of the MSB are added back into the LSB during a ones complement sum, errors in any one column of the data will be reflected in more than one bit of the checksum. So a ones complement sum is a stronger checksum (for example, will detect more errors) than a twos complement sum, and only slightly more expensive. Hence, it is chosen for use in a lot of different situations.
The checksums within the UDP and TCP headers are computed in exactly the same way as the IP checksum. In fact, the only major difference is the set of words over which the sum is calculated. (A minor difference is that UDP checksums are optional.) In both cases, these layer 4 protocols include the message, their own header fields, and a few important fields of the IP header in the checksum calculation. The inclusion of some IP header fields in the UDP and TCP checksums is one of the biggest reasons that these layers of the protocol stack cannot be completely separated from the IP layer in a software implementation. The reason that IP checksums include only the IP header is that many intermediate computers must validate, read, and modify the contents of the IP header as a packet travels from its source to the destination. By reducing the number of words involved in the calculation, the speed with which all IP packets move across the Internet is improved. Including a larger set of words in the UDP and TCP checksums does not slow down communications; rather, it increases the likelihood that the message received is the same as the message sent.
Further reading
The checksum algorithms considered here are based on simple binary addition. That makes them relatively inexpensive to compute. However, these are weak checksum algorithms that will allow common types of hardware errors to escape detection.
http://www.netrino.com/Connecting/1999-11/index.php 25.07.2007 23:20:53
Internetverzeichnis - 157 - Fachhochschule Hof
Additive Checksum Algorithms as Error Detection Codes Seite 7
A more sophisticated type of checksum is called a cyclic redundancy code (CRC). Related pages cover CRC theory and CRC implementation .
This content began life as a column in the November 1999 issue of Embedded Systems Programming , which is available here .
Copyright © 1996-2007 Netrino, LLC. All rights reserved.
http://www.netrino.com/Connecting/1999-11/index.php 25.07.2007 23:20:53
Internetverzeichnis Diplomarbeit - 158 -
Index
Dieser Stichwortindex soll eine möglichst komplette Übersicht über die wichtigen, in diesem Dokument verwendeten Stichwörter liefern.
- 0-9 - CG 10baseT ConverGate-D ...... xi 10 MBit cncc ...... 140 ETH ...... 10 CONFIG_REP Spezifikation ...... 50 -A- CONFIG_REQ A-Seite ...... 7 Implementierung ...... 88 ADD_REP Spezifikation ...... 49 Spezifikation ...... 43 Context ADD_REQ TLV ...... 39 Implementierung ...... 86 Control-PC Spezifikation ...... 42 Control-Blade ...... 9 API ConverGate-D Evaluation Board Application Programming Interface ...... xi Spezifikation ...... 54 ARP CRLT Address Resolution Protocol ...... xi Classification Result Location Table ...... xi Implementierung ...... 101 Spezifikation ...... 66 -D- Windows/Linux ...... 136 DIP ATCA Dual In-line Package ...... xi Advanced Telecommunications Computing Architec- downstream ...... 7 ture ...... Doxygen ...... 140 xi DSCP DiffServ Code Point ...... xi -B- DSLAM B-Seite ...... 7 Digital Subscriber Line Access Multiplexer ...... xi B2BUA DWord ...... xiii Control-Blade (Control-PC) ...... 9 Dynamische Konfiguration NGN ...... 6 Software ...... 22 Back-to-back User Agent ...... xi Implementierung ...... 97 BCAM Spezifikation ...... 59 Binary Content Addressable Memory ...... xi BCFA -E- Binary Configuration File Access ...... xi Ethernet Implementierung ...... 99 Firmware ...... 15 Spezifikation ...... 62 Implementierung ...... 101 BG Spezifikation ...... 65 BorderGateway ...... xi tcpdump ...... 138 Bit ...... xiii Wireshark ...... 138 BMBF Bundesministerium für Bildung und Forschung . . . . xi -F- BorderGateway FAULT Media Gateway ...... 6 Implementierung ...... 88 BRAS Spezifikation ...... 51 Broadband Remote Access Server ...... xi FCS Broadcast Frame Check Sequence ...... xi ARP ...... 66 Fehlerbehandlung Ethernet ...... 65 Implementierung ...... 81 Byte ...... xiii Spezifikation ...... 35 Fehlerwarteschlange -C- Implementierung ...... 88 CB Spezifikation ...... 52 Control-Blade (Control-PC) ...... xi FIB
Index - 159 - Fachhochschule Hof
Forwarding Information Base ...... xi -K- FIFO KMU Fehlerwarteschlange ...... 88 kleine und mittlere Unternehmen ...... xii First In First Out ...... xi Kontext ...... 7 Firmware ...... 15 Internet Protocol ...... 15 -L- User Datagram Protocol ...... 15 LAN Ethernet ...... 15 Local Area Network ...... xii Prüfsumme ...... 15 Latex ...... 139 Flash LED Das U-Boot Light-Emitting Diode ...... xii MPC-Modul ...... 23 Listen ...... 80 Hardware ...... 13 -M- -G- MAC GbE Media Access Control ...... xii Gigabit Ethernet ...... xi MAC-Adresse ...... xiv GMII ...... 10 Main loop ...... 81 Gimp ...... 139 MAMS ...... 4 Multi Access, Modular Services ...... xii -H- Media Conversion Halfcall ...... 7 MBC1 / MBC2 ...... 10 TLV ...... 39 Media Gateway Hauptschleife ...... 81 BorderGateway ...... 6 Header ...... xiii MG BCFA ...... 63 Media Gateway ...... xii MIB -I- Management Information Base ...... xii IBE Microsoft PowerPoint ...... 139 Infineon Buildroot Extension ...... xi MMS ICMP Multimedia Messaging Service ...... xii Implementierung ...... 105 MODIFY_REP Internet Control Message Protocol ...... xi Spezifikation ...... 47 Spezifikation ...... 73 MODIFY_REQ Windows/Linux ...... 136 Implementierung ...... 87 Image ...... xiii Spezifikation ...... 46 Implementierung ...... 80 MPC Control-PC ⇔ MPC-Modul ...... 82 Motorola POWER Chip ...... xii ConverGate-D ⇔ MPC-Modul ...... 91 MSS Netzwerkpakete ...... 100 BorderGateway ...... 6 IMS Control-PC ...... 9 IP Multimedia Subsystem ...... xi MPC-Modul ...... 12 IOCTL Media Stream Switching ...... xii Input/Output Control ...... xi MSS!Enhanced Media Stream Switching ...... xii IP Implementierung ...... 103 -N- Internet Protocol ...... xi NDN ...... 140 Spezifikation ...... 71 NFS IP in IP Client Implementierung ...... 104 MPC-Modul ...... 24 Spezifikation ...... 72 Network File System ...... xii IP-DSLAM Server ...... 139 for IP based Digital Subscriber Line Access Multiplexer NGN ...... 5 xi Voice over IP ...... 6 IPNI Next Generation Network ...... xii ConverGate-D Treiber ...... 31 Ingress Port Number Information ...... xi -O- Spezifikation ...... 56 Octet ...... xiii ISONI ODSDP Intelligent Service Oriented Network Infrastructure . . Open Distributed Service Delivery Platform ...... xii xii SDP ...... 5 IT Informations Technologie ...... xii -P- PDU -J- Protocol/Payload Data Unit ...... xii JFFS2 Pointer Journalling Flash File System 2 ...... xii Zeiger ...... xiii
Index Diplomarbeit - 160 -
PosPHY TK MBC1 / MBC2 ...... 10 Telekommunikation ...... xii POS-PHY Level 3 saturn-compatible Packet Over Sonet TLV interface specification for PHYsical and link layer Implementierung ...... 82 devices ...... xii Spezifikation ...... 37 Prüfsumme Type Length Value ...... xii Firmware ...... 15 -U- -Q- UA QoS User Agent ...... xii Quality of Service ...... xii UDP Control-PC ...... 53, 90 -R- Implementierung ...... 105 READ_STATUS_REP Spezifikation ...... 75 Spezifikation ...... 49 User Datagram Protocol ...... xii READ_STATUS_REQ UMLPad ...... 139 Implementierung ...... 87 UMPR Spezifikation ...... 48 User’s Manual, Programmer’s Reference ...... xii RFC upstream ...... 7 Request for Comments ...... xii User DIPs RTCP Hardware ...... 10 Real Time Control Protocol ...... xii Spezifikation ...... 54 RTP User LEDs Real Time Protocol ...... xii Hardware ...... 10 Spezifikation ...... 55 -S- SDP -V- Verbindung ...... 7 Service Delivery Platform ...... xii VoIP seriell Voice over IP ...... xii Schnittstelle ...... 137 SimCList Implementierung ...... 81 -W- Modultests ...... 108 WAKE_UP SIP Implementierung ...... 88 B2BUA ...... 6 Spezifikation ...... 50 Implementierung ...... 106 WinEasy ...... 16 Session Initiation Protocol ...... xii Wireshark ...... 138 Word ...... xiii Spezifikation ...... 76 SMS Short Message Service ...... xii -X- Spezifikation ...... 34 XML Control-PC ⇔ MPC-Modul ...... 36 Extensible Markup Language ...... xii ConverGate-D ⇔ MPC-Modul ...... 54 Netzwerkpakete ...... 65 -Z- Rahmenbedingungen Zeiger Alcatel-Lucent ...... 34 Pointer ...... xiii ConverGate-D ...... 35 Stack ...... xiii Statische Konfiguration Implementierung ...... 95 Spezifikation ...... 57 SUBTRACT_REP Spezifikation ...... 45 SUBTRACT_REQ Implementierung ...... 86 Spezifikation ...... 44
-T- tcpdump ...... 138 Terminierung ...... 7 Tests ...... 108 Integration ...... 123 Module, Funktionen ...... 108 System ...... 109 TFTP ...... 138 Trivial File Transfer Protocol ...... xii Thread ...... xiii
Index - 161 - Fachhochschule Hof
Eidesstattliche Erkl¨arung
Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe; die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Die Arbeit wurde nach meiner besten Kenntnis bisher in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht.
Hof, den 27. September 2007 Stefan Weber
Eidesstattliche Erklärung