QoS-orientierte Kommunikation über Ethernet für verteilte, Linux-basierte Automatisierungsanwendungen

Transkript

1 Fachhochschule Wiesbaden Fachbereich Informatik Diplomarbeit zur Erlangung des akademischen Grades Diplom-Informatiker (FH) QoS-orientierte Kommunikation über Ethernet für verteilte, Linux-basierte Automatisierungsanwendungen vorgelegt von: Marco Kosinski am: Referent: Korreferent: Prof. Dr. Reinhold Kröger Prof. Dr. Martin Gergeleit

2 II

3 Erklärung Hiermit erkläre ich an Eides statt, daß ich die vorliegende Diplomarbeit selbständig und nur unter Verwendung der angegebenen Hilfsmittel und Literaturquellen verfaßt habe. Wiesbaden, Marco Kosinski Hiermit erkläre ich mein Einverständnis mit den im Folgenden aufgeführten Verarbeitungsformen dieser Diplomarbeit: Verarbeitungsform ja nein Einstellung der Arbeit in die Bibliothek der FHW Veröffentlichung des Titels der Arbeit im Internet Veröffentlichung der Arbeit im Internet Wiesbaden, Marco Kosinski i

4 ii

5 Inhaltsverzeichnis 1 Einführung 1 2 Grundlagen Quality of Service Klassifizierung Paket Scheduling, Traffic Shaping und Policing Strict Priority Queueing Weighted Round Robin Queueing Token Bucket Algorithmus Ethernet im Echtzeitbetrieb Lastreduzierung Time Devision Multiple Access Einsatz von Switches Fazit Linux Packet-Sockets Q VLAN Modul Aufbau und Funktionsweise Konfiguration Queueing Disziplinen Funktionsweise Aufbau iii

6 3 Analyse Anforderungen Anfordern von QoS Steuern und Regeln Alarm-Signalisierung Datei-Download / Upload Human-Machine-Interface Sonstige Anforderungen Entwicklung unter Linux Portierbarkeit Modularität Performanz-Optimierung auf Senden und Empfangen Kommunikationsformen und ihre QoS-Anforderungen Steuern und Regeln Alarm-Signalisierung Datei-Download / Upload Human-Machine-Interface Einflussnahme auf die QoS-Parameter Service Availability Packet Loss Rate Delay Delay im Sendeknoten Delay auf dem Medium Delay im Empfangsknoten Jitter Throughput API der Linux-Queueing-Disziplinen Kommunikation über Netlink-Sockets Addressierung der Netlink-Messages Aufbau der Netlink-Messages Traffic-Control-Messages Verfügbare Queueing Disziplinen iv

7 First-In-First-Out (bfifo, pfifo, pfifo fast) Stochastical Fair Queueing (sfq) Prio (prio) Hierarchical Token Bucket (htb) Filter Der U32-Filter Designentscheidungen Statische Verkehrscharakteristik Linux ohne Echtzeiterweiterung Einsatz von Switches Konzept Grobentwurf Die Konfiguration (chconfread) Die Bibliotheksschnittstelle (chcontr) Der Kanalendpunkt (chdescr) Prozesszugriffsverwaltung (chavailcontr/ chavail) Netzwerk-Device (chdev) QoS-Controller (chqoscontr) Implementierung Implementierungsumgebung chconfread chcontr chdescr chavailcontr chdev chqoscontr Testapplikation Gesamtaufwand Kompilierung und Installation Aufgetretene Probleme v

8 6 Bewertung Messumgebung Messgrößen Instrumentierung Ende-zu-Ende Propagation Delay durch sendto-systemcall und QDisc Lastmodell Lastquelle Messergebnisse Fazit Zusammenfassung und Ausblick Literaturverzeichnis 119 A Prioritätentabelle 123 B Diagramme 125 B.1 HTB/Prio QDisc B.2 HTB/Prio End-to-End B.3 Prio QDisc B.4 Prio End-to-End B.5 FIFO QDisc B.6 FIFO End-to-End B.7 HTB/Prio QDisc variierender Burst-Parameter B.8 Ein Prio 1 Kanal ohne Störlast B.9 Ein Prio 1 Kanal mit Störlast B.10 Ein Prio 7 Kanal ohne Störlast B.11 Ein Prio 7 Kanal mit Störlast C Inhalt der CD 141 vi

9 Abbildungsverzeichnis 2.1 IEEE 802.1Q VLAN Tag Beispiel: Strict Priority Queueing Beispiel: Weighted Round Robin Queueing Beispiel: Token Bucket Algorithmus Aufbau eines Switch Aufbau der VLAN-Devices Funktionsweise von Queueing Disziplinen Aufbau von Queueing Disziplinen Use-Case Diagramm Service- und Ankunftskurve Netlink-Message Traffic-Control-Message Attribute einer Traffic-Control-Message Konzeptionelles Klassenmodell Übersicht Klassendiagramm Übersicht Klassendiagramm Kollaborationsdiagramm zu initchannels() Kollaborationsdiagramm zu closechannels() Kollaborationsdiagramm zu chopen() Kollaborationsdiagramm zu chclose() Kollaborationsdiagramm zu chopen() Kollaborationsdiagramm zu chrecv() chdesrc-klasse Konzept für den gepufferten Empfang vii

10 4.12 chavailcontr- und chavail-klasse registerchannel-methode Die chdev-klasse Die chqoscontr-klasse Basis-QDisc-Konfiguration Best-Effort-QDisc-Konfiguration QDisc-Konfiguration für Kanäle Semaphore für Prozess- und Threadsynchronisation Speichermodell für chdescr-objekte B.1 QDisc 200Byte HTB/Prio B.2 QDisc 500Byte HTB/Prio B.3 QDisc 1496Byte HTB/Prio B.4 End-to-End 200Byte HTB/Prio B.5 End-to-End 500Byte HTB/Prio B.6 End-to-End 1496Byte HTB/Prio B.7 QDisc 200Byte Prio B.8 QDisc 500Byte Prio B.9 QDisc 1496Byte Prio B.10 End-to-End 200Byte Prio B.11 End-to-End 500Byte Prio B.12 End-to-End 1496Byte Prio B.13 QDisc 200Byte FIFO B.14 QDisc 500Byte FIFO B.15 QDisc 1496Byte FIFO B.16 End-to-End 200Byte FIFO B.17 End-to-End 500Byte FIFO B.18 End-to-End 1496Byte FIFO B.19 QDisc 500Byte HTB/Prio cburst B.20 QDisc 500Byte HTB/Prio Minburst B.21 QDisc 500Byte HTB/Prio Minburst B.22 QDisc Kanal Prio 1 ohne Störlast viii

11 B.23 End-to-End Kanal Prio 1 ohne Störlast B.24 QDisc Kanal Prio 1 mit Störlast B.25 End-to-End Kanal Prio 1 mit Störlast B.26 QDisc Kanal Prio 7 ohne Störlast B.27 End-to-End Kanal Prio 7 ohne Störlast B.28 QDisc Kanal Prio 7 mit Störlast B.29 End-to-End Kanal Prio 7 ohne Störlast ix

12 x

13 Tabellenverzeichnis 2.1 Integrated Services Klassen Service Klassen im Automatisierungskontext Abbildung der User-Priority-Werte auf Traffic-Klassen Zuteilung der Traffic Klassen pro Anzahl der Ausgangsqueues VLAN ioctl Kommandos Namensgebung des VLAN Device RTNetlink-Kommandos Flags für Netlink-Messages Flags für Netlink-Messages (forts.) Implementierungsaufwand chconfread Implementierungsaufwand chcontr Implementierungsaufwand chdescr Implementierungsaufwand chavailcontr Implementierungsaufwand chdev Implementierungsaufwand chqoscontr Implementierungsaufwand Testapplikation Implementierungsaufwand chqoscontr Implementierungsaufwand Instrumentierung Lastkonfigurationen Genutzte Bandbreite der Lastkonfigurationen Maximaler Delay der Kanäle in der Queueing Disziplin Mittlerer Delay für Prio/HTB-Konfiguration Maximaler Delay für Prio/HTB-Konfiguration Mittlerer Delay für Prio-Konfiguration xi

14 6.8 Maximaler Delay für Prio-Konfiguration Mittlerer Delay für FIFO-Konfiguration Maximaler Delay für FIFO-Konfiguration A.1 Übersicht über alle prioritätsbezogenen Werte xii

15 Verzeichnis der Quelltexte 2.1 Der socket()-systemcall für Packet-Sockets Der ioctl()-systemcall Die vlan_ioctl_args Struktur Erforderliche Header Dateien für Netlink-Kommunikation Die msghdr Struktur Die iovec Struktur Die sockaddr_nl Struktur Die nlmsghdr Struktur Die tcmsg Struktur Die tc_sfq_qopt Struktur Die tc_prio_qopt Struktur Die tc_htb_glob Struktur Die tc_ratespec Struktur Die tc_htb_opt Struktur Die tc_u32_sel Struktur Die tc_u32_key Struktur Document Type Definition der Konfigurationsdatei Fehlerrückgabewerte Zuweisung der Kommunikationmethoden Setzen der Socket-Priotität Makros zur Umrechnung der Indizes in chcontain Stufenweises Allokieren in chcontain Die chdescr-struktur Suchschleife in chavailcontr Abruf der Shm-Statistiken xiii

16 5.9 Filter-Selector für Prio-QDisc Hinzufügen der Prio-QDisc User-Priority auf Prio-QDisc Mapping Basis-QDiscs und Filter Hinzufügen der Best-Effort-Klasse Setzen der QDisc-Basis-Parameter Generieren der Netlink-Message Versenden der Netlink-Message Hinzufügen von Attributen Generieren einer Netlink-Message für eine HTB-Klasse Die msrfrm-struktur testmodesend()-funktion Instrumentierung an der enqueue()-funktion xiv

17 Kapitel 1 Einführung Mit Beginn der Industrialisierung versuchte der Mensch immer mehr Arbeitsabläufe (Prozesse) zu automatisieren. Dies geschah zunächst nur durch Einsatz rein mechanischer Mittel. Mit der Entwicklung der Transistortechnik hielten Computer Einzug in die Industrie. Mit den Rechnern war es möglich an industriellen Fertigungsanlagen sowohl Zustände zu erfassen, als auch deren Verhalten zu steuern und zu regeln. Prozessund Steuerwerte wurden mittels analoger Spannungs- oder Stromwerte übertragen. Der baldige Anstieg in der Komplexität der Anlagen forderte die Entwicklung von dezentraler Peripherie, die über eine gewisse Eigenintelligenz verfügte. Über eine Anlage verteilte Sensoren und Aktoren gaben Prozesswerte nicht mehr nur als analoge Signale weiter, sondern übermittelten diese digitalisiert. Dies ebnete den Weg zum Austausch von Sensor- und Steuerdaten, sowie Statusmeldungen und Diagnoseinformationen. Um diese Art der Kommunikation zu ermöglichen, wurden Bussysteme entwickelt. Sie waren echtzeitfähig, was heißt, dass für alle Daten, die über den Bus gesendet wurden, garantiert wurde, dass sie nach einer maximalen Verzögerungszeit an ihrem Ziel eintreffen [Kop97]. Über die typischen Zweidrahtleitungen der Feldbusse findet immer eine Master-Slave-Kommunikation statt, bei der das Automationssystem zyklisch alle Slave-Komponenten (Peripherie) nach Daten abfragt (Polling) und an sie gerichtete Daten sendet. Heute existieren über 50 verschiedene Feldbusssysteme. Durch den weiter stetigen Komplexitätsanstieg der Industrianlagen, genügte bald ein zentraler Rechner zu deren Steuerung nicht mehr. Die Verteilung der Steuerungs- 1

18 Kapitel 1. Einführung aufgaben auf mehrere Rechner war eine eindeutige Konsequenz. Dadurch konnten wiederum kleinere, kostengünstigere, spezialisierte Microcontroller eingesetzt werden, was die Wartung der Anlagen günstiger machte, da einzelne Komponenten ausgetauscht werden konnten. Dadurch erhöhte sich weiterhin die Komplexität in der Kommunikation, da gleichberechtigte Steuereinheiten Daten miteinander austauschen mussten. Eine reine Master-Slave-Architektur war nun nicht mehr anwendbar; es musste eine Master-zu-Master-Kommunikation ermöglicht werden. Die vertikale Integration macht Mechanismen erforderlich, die sicher stellen, dass echtzeitkritischer Datenverkehr mit Protokollen wie FTP oder HTTP störungsfrei koexistieren. Weiterhin hat dies höhere Anforderungen an die zur Verfügung stehende Bandbreite zur Folge, denen die auf kleine Datenmengen optimierten Feldbusse nicht gewachsen sind [Jas02]. Als eine Alternative zu Feldbussen dafür hat sich Ethernet herauskristallisiert. Es bietet günstige, standardisierte Hardware mit hoher Geschwindigkeit, einfache Verkabelung und die Nutzung standardisierter Protokolle zur vertikalen Integration. Doch da Ethernet nicht für die Automatisierungsumgebung entwickelt wurde, lässt es sich dort nicht ohne Anpassungen integrieren. Es sind einige, zum Teil sehr erfolgreiche, proprietäre Lösungen entwickelt worden, die die Integration von Ethernet ermöglichen, wie z.b. PROFINET [eh]. Jedoch sind offene Lösungen, welche heute auch immer mehr im Office und Home-Computing Bereich Einzug halten, bisher die Ausnahme. Als ein offenes Betriebssystem bietet Linux die Möglichkeit, mit ihm eine offene Lösung für die Problematik, die Ethernet im Automatisierungskontext stellt, zu entwickeln. Linux ist kostengünstig und bietet große Flexibilität, da es durch Modularität den jeweiligen Anforderungen einer Automationsanlage angepasst werden kann. Diese Arbeit ist eingebettet in das Forschungsprojekt Real-Time Data Propagation in Distributed Environments, des Labors für verteilte System der FH Wiesbaden. Dieses sieht eine mehrschichtige Architektur vor, deren unterste Schicht eine Quality-of-Service-orientierte Kommunikation über Ethernet herstellen soll, basierend auf den von Linux gebotenen Möglichkeiten. Ziel dieser Arbeit ist es diese Kommunikationsschicht zu entwickeln, unter Berücksichtigung der Anforderungen, die eine Automatisierungsumgebung an diese stellt. In Kapitel 2 werden die Grundlagen erläutert, die zum Verständnis des Themas notwendig sind. Abschnitt 2.1 beschreibt was unter Quality of Service zu verstehen ist 2

19 Kapitel 1. Einführung und gibt einen Überblick über die in diesem Kontext eingesetzten Mechanismen. In Abschnitt 2.2 werden Aspekte von Ethernet betrachtet, die der Erlangung von Echtzeitfähigkeit im Wege stehen. Dabei wird ein Überblick über die bisher eingesetzten Lösungen zur Beseitigung dieser Aspekte gegeben. Abschnitt 2.3 erklärt die Implementierung der in Abschnitt2.1 erläuterten Mechanismen im Linux Kernel. Hierbei werden die Funktionsweise und Programmierschnittstelle zu den jeweiligen Modulen aufgezeigt. In Kapitel 3 werden die Anforderungen und Randbedingungen analysiert, die sich aus der Automationsumgebung ergeben. Abschnitt 3.1 geht auf die Anforderungen verschiedener Anwendugsfälle ein, die in der verteilten Automation auftreten. In Abschnitt 3.2 werden die einzelnen Kommunikationsformen in Bezug zu deren Anforderungen an QoS-Parameter beleuchtet. Wie diese Parameter beeinflusst werden können wird in Abschnitt 3.3 analysiert. Die Analyse der in der Arbeit zu verwendenden Queueing-Disziplinen wird in 3.4 vorgenommen. Zuletzt werden einige Designentscheidungen getroffen, die in Abschnitt 3.5 beschrieben werden. In Kapitel 4 wird ein Software-Design zur Lösung der Problemstellung konzipiert. In Abschnitt 4.1 wird zunächst ein Grobkonzept vorgestellt, das in den Abschnitten 4.2 bis 4.7 für jedes Subsystem verfeinert wird. Kapitel 5 zeigt, wie das in Kapitel 4 erstellte Konzept in die Implementierung umgesetzt wurde. Abschnitt 5.1 beschreibt kurz die Entwicklungsumgebung und die Hilfsmittel, die zur Erstellung der Software genutzt wurde. Die Abschnitte 5.2 bis 5.7 gehen näher auf die Implementierungsaspekte der einzelnen Module ein. In Abschnitt 5.8 wird eine Applikation beschrieben, die zum Testen der Grundfunktionen der Implementierung genutzt werden kann. Der Abschnitt 5.10 erklärt die Kompilierung und Installation der implementierten Software. In Abschnitt 5.11 werden Probleme behandelt, die im Laufe der Implementierung aufgetreten sind. In Kapitel 6 wird eine Bewertung der Implementierung anhand von Messungen durchgeführt. Abschnitt 6.1 beschreibt die Rechner- und Switchkonfiguration in der gemessen wurde. Abschnitt 6.2 geht auf die einzelnen Messgrößen ein. Die vorgenommene Instrumentierung wird in Abschnitt 6.3 beschrieben. Abschnitt 6.4 stellt das Lastmodell vor, dessen Implementierung in Abschnitt 6.5 beschrieben wird. In Abschnitt 6.6 werden die besprochen und dazu in 6.7 ein Fazit dazu gegeben. Die Arbeit wird Kapitel 7 zusammengefasst und es wird ein Ausblick mögliche Weiterentwicklungen gegeben. 3

20 4 Kapitel 1. Einführung

21 Kapitel 2 Grundlagen 2.1 Quality of Service Der Begriff Quality of Service, oder Dienstqualität [Tan02] ist in der Fachwelt nicht klar definiert [Jas02]. Ursprünglich stammt er aus der Multimediakommunikation. Bei der Übertragung von Video- oder Audiosignalen über ein Datennetzwerk treten gewöhnlich Verzögerungen auf. Überschreiten diese Verzögerungen einen bestimmten Grenzwert, so sind Verluste in der Qualität des Signals deutlich erkennbar. Um dies zu vermeiden und damit die Qualität des Services zu gewährleisten, wurden diverse Mechanismen entworfen, die unter dem Begriff Quality of Service (QoS) zusammengefasst wurden. Heute weitet sich deren Anwendung auf verschiedene andere Gebiete aus, unter anderem auf die Industrieautomation, wo sie eingesetzt werden, um harte Echtzeitanforderungen durchzusetzen. Der QoS-Begriff wird durch eine Reihe von Parametern bestimmt, die Einfluss auf die Qualität eines Dienstes haben. Mit ihnen können Anforderungen beschrieben werden, die ein Dienst stellt, um die benötigte Qualität aufrecht zu erhalten. Die Parameter sind nach [Fur03]: Service Availability (Dienstverfügbarkeit) Service Availability beschreibt die Zeit, die ein Service in einem Netzwerk zur Verfügung steht. Diese wird als Prozentsatz der Zeit angegeben, die ein Service innerhalb der Gesamtzeit verfügbar ist. Paket Loss Rate (Paketverlustrate) Fällt an einem Netzwerkknoten mehr Datenverkehr an als verarbeitet werden kann, so müssen unter Umständen Pakete 5

22 2.1. Quality of Service Kapitel 2. Grundlagen verworfen werden. Die Paketverlustrate gibt den prozentualen Anteil der Pakete an, die auf dem Weg durch das Netzwerk verloren gehen. Delay, Latency (Latenz) Der Delay ist die Propagationszeit zwischen dem Senden und Empfangen eines Pakets. Der Delay eines Pakets bewegt sich immer zwischen einem Worst-Case-Delay und einem Best-Case-Delay. Er besteht aus einem konstanten und einem variablen Teil. Der konstante Teil setzt sich aus der Verarbeitung der Daten durch die Hardware und der Signallaufzeiten in den Kabeln zusammen. Der variable Teil entsteht durch die Verzögerungen und Wartezeiten in den Betriebssystemen, Treibern und Firmware jedes passierten Netzwerkknotens. Jitter Werden Pakete in festen Zeitintervallen (isochron) gesendet, so kommt es beim Empfänger durch Unregelmäßigkeiten in der Latenz zu einer Varianz in den Intervallen. Der Jitter beschreibt diese Varianz im Delay in Form einer vorzeichenbehafteten Variablen, deren Wert negativ ist, wenn ein Paket früher als erwartet eintrifft und positiv, wenn es später eintrifft. Troughput(Durchsatz) Throughput beschreibt den Datendurchsatz im Netz, gemessen in Bytes oder Paketen pro Sekunde. Um QoS in einem Netzwerk durchsetzen zu können, müssen zwei Anforderungen erfüllt sein: Die Pakete, die ein QoS-orientiertes Netzwerk passieren, müssen klassifizierbar sein. Jeder Netzwerkknoten, den ein klassifiziertes Paket passiert, muss in der Lage sein, das Paket entsprechend seiner Klassifizierung zu verarbeiten Klassifizierung Um Pakete klassifizieren zu können, müssen zunächst verschiedene Klassen definiert werden. In RFC 1633 werden drei Dienstklassen vorgeschlagen, die in Tabelle 2.1 erläutert werden: Guaranteed Service, Predictive Service und Best-Effort-Service. 6

23 Kapitel 2. Grundlagen 2.1. Quality of Service Dienstklasse Guaranteed Predictive Best-Effort Eigenschaften Pakete werden innerhalb einer festgelegten Verzögerungszeit ausgeliefert. Um den Jitter zu minimieren können Pakete, die zu früh eintreffen, beim Empfänger gepuffert werden. Pakete dieser Klasse haben keine festgelegten maximalen Verzögerungszeiten, dennoch werden sie bevorzugt behandelt um ihre Ankunftszeit grob vorhersagbar zu halten. Ihr Verhalten sollte Best-Effort-Verkehr widerspiegeln, der auf einem unbelasteten Netz stattfindet. Normaler, unprivilegierter Netzwerkverkehr Tabelle 2.1: Integrated Services Klassen Die Eigenschaften dieser Klassen sind ursprünglich für die Multimediakommunikation konzipiert und nur grob umrissen. In [Fur03] werden diese Klassen in den Automatisierungskontext gebracht und um angemessene Werte in Bezug auf die restlichen QoS-Parameter erweitert (Tabelle 2.2). Dienstklasse Anw. i.d. Automation QoS-Parameter Guaranteed Echtzeitanwendung Verfügbarkeit: sehr hoch Synchronisation Verlustrate: sehr tief Fehlerbehandlung Verzögerung: niedrig+konstant Jitter: sehr klein Durchsatz: konstant Predictive Download Verfügbarkeit: sehr hoch Produktionsdaten Verlustrate: sehr tief Programmierung Verzögerung: kontrolliert Debugging Jitter: kontrolliert Monitoring Durchsatz: kontrolliert Best-Effort Bedienen & Beobachten Verfügbarkeit: hoch Internet-Zugriff Verlustrate: tief Extranet-Anbindung Verzögerung: unspezifiziert Jitter: unspezifiziert Durchsatz: unspezifiziert Tabelle 2.2: Service Klassen im Automatisierungskontext [Fur03] 7

24 2.1. Quality of Service Kapitel 2. Grundlagen Der Guaranteed Service soll für echtzeitkritische Anwendungen, wie Synchronisation und Fehlerbehandlung, eingesetzt werden. Der Predictive Service übernimmt Aufgaben wie Download, Programmierung der Peripherie, sowie Debugging und Monitoring. Der restliche Verkehr wird vom Best-Effort-Service bedient. Dies trifft auf Anwendungen wie Internet-Zugriff und Extranet-Anbindung zu. Auf IP-Ebene existieren zwei Ansätze zur Klassifizierung von Paketen : Integrated Services und Differentiated Services. Das in RFC 1633 beschriebene Integrated Services (IntServ) teilt den Netzwerkverkehr in einzelne Paketströme, sogenannte Flows, ein. Diesen Flows wird jeweils eine Serviceklasse zugeordnet. Damit jedes Netzwerkelement auf dem Pfad das Paket erkennen und ihm Resourcen zuteilen kann, wird das Resource Reservation Protokoll (RSVP) eingesetzt, das in RFC 2205 beschrieben ist. Jedes Netzwerkelement muss sich eine Tabelle halten, die die Flows und ihre zugehörige Klasse verwaltet. Das in RFC 2475 beschriebene Differentiated Services (DiffServ) verfolgt einen anderen Ansatz. Jedes Paket erhält entsprechend seiner Klasse eine Markierung. Dies geschieht durch die Zuweisung eines Wertes (DS-Wert), der seine Klasse identifiziert. Dieser Wert wird vom Paket mitgeführt und von den Netzwerkknoten innerhalb einer DS-Domäne zwecks Klassifizierung ausgelesen. Das schont die Resourcen der Netzwerkknoten, da keine Tabelle mehr im Speicher gehalten werden muss, und macht somit den Einsatz von RSVP unnötig. Allerdings müssen alle Netzwerkknoten innerhalb der DS-Domäne die Resourcen schon statisch für jede Klasse vorkonfiguriert haben. Für den DS-Wert muss ein Feld im Protokoll-Header existieren, das zu diesem Zweck verwendet werden kann. Da das Type-of-Service-Feld im IP-Header nur selten Verwendung fand, wird es mit Einführung von DiffServ als DS-Feld genutzt. Für Ethernet existiert ein ähnlicher Ansatz, bei dem wie bei DiffServ das Paket selbst markiert wird. Der Standard IEEE 802.1p (seit 2004 integriert in IEEE 802.1D [IEE04]) beschreibt die Möglichkeit einem Ethernet Frame eine Priorität zuzuweisen. Dies geschieht durch den sogenannten User Priority Wert, für den jedoch im klassischen Ethernet-Header kein Feld vorgesehen ist. Daher wird von IEEE 802.1p vorgeschlagen diesen Wert aus einem Feld in einer höheren Protokollschicht, wie dem DS-Feld im IP-Header, zu berechnen oder das im 802.1Q-Standard beschriebene User-Priority-Feld im VLAN-Tag zu verwenden. Der Standard IEEE 802.1Q [IEE03] beschreibt die Aufteilung eines physischen, von einem Switch vermittelten Local Area Network, in mehrere virtuelle LANs. Um das zu erreichen, wird zwischen der Zieladresse und dem Type-Feld ein 4 Byte langes 8

25 Kapitel 2. Grundlagen 2.1. Quality of Service VLAN-Tag eingefügt (Abbildung 2.1). Abbildung 2.1: IEEE 802.1Q VLAN Tag Eingeleitet wird das Tag durch den Tag Protocol Identifier (TPID), der immer den Wert 0x8100 hat. Darauf folgt die Tag Control Information (TCI), die aus dem 3- Bit User Priority Feld, dem 1-Bit Canonical Format Indicator (CFI) und der 12-Bit VLAN-ID (VID) besteht. Frames mit unterschiedlicher VID werden vom Switch wie Frames in physikalisch voneinander getrennten LANs behandelt. Drei der VIDs sind reserviert. VID 0 VID 0 bezeichnet einen Priority Tagged Frame. Ein solcher Frame besitzt keine VLAN-Zugehörigkeit; das Tag wird nur genutzt, um den Frame über das User-Priority-Feld klassifizieren zu können. VID 1 Jeder Switch muss über die Funktion verfügen, einem Frame ein Tag hinzuzufügen, sofern er noch keins besitzt. Die VID, die dem Frame zugewiesen wird, wird Port-VID (PVID) genannt. Als Default PVID legt 802.1Q die VID 1 fest. VID 0xFFF Diese VID ist für Implementationszwecke reserviert und sollte niemals verwendet werden. Mit dem User-Priority-Feld kann die Priorität eines Frames angegeben werden, wodurch der Frame für alle Netzwerkknoten auf seinem Pfad klassifizierbar ist. Zu diesem Zweck definiert IEEE 802.1D [IEE04] acht Verkehrsklassen, auf die der Wert des User-Priority-Feldes abgebildet wird. Tabelle 2.3 zeigt diese Klassen. 9

26 2.1. Quality of Service Kapitel 2. Grundlagen Priorität User-Priority Akronym Verkehrsklasse hoch 7 NC Network Control 6 VO Voice 5 VI Video 4 CL Controlled Load 3 EE Excellent Effort 0 BE Best Effort 2 - Nicht belegt niedrig 1 BK Background Tabelle 2.3: Abbildung der User-Priority-Werte auf Traffic-Klassen Die Priorität der einzelnen Verkehrsklassen entspricht ihrem Wert im User-Priority- Feld, d.h. 7 entspricht der höchsten Priorität, 6 der nächst niedrigeren, usw. Grundsätzlich wird davon ausgegangen, dass ein Frame ohne Tag der Best-Effort-Klasse angehört. Wird einem Frame ein Tag hinzugefügt, und seine Klasse ist nicht ersichtlich, wird ihm eine User-Priority von 0 zugewiesen. Der Standard IEEE 802.1p definiert jedoch zwei Klassen, die eine niedrigere Priorität aufweisen als Best-Effort- Verkehr. Aus diesem Grund wurde dem User-Priority-Wert 0 eine höhere Priorität zugewiesen, als den User-Priority-Werten 1 und 2. Dies geschah laut [Jas02] aus Kompatibilitätsgründen Paket Scheduling, Traffic Shaping und Policing Kann ein Paket klassifiziert werden, muss gewährleistet sein, dass jeder Netzwerkknoten auf dem Pfad in der Lage ist, es entsprechend seiner Klasse zu verarbeiten. Paket Scheduling Algorithmen legen die Art und Weise fest, wie ein Knoten ein Paket verarbeitet. Sie haben die Aufgabe die Ausgangsqueue eines Netzwerkknotens neu zu ordnen und somit bestimmten Paketen den Vorrang vor anderen Paketen zu geben. Eine andere Maßnahme, wie man den Verkehr in einem Netzwerk beeinflussen kann, stellt dass Traffic Shaping dar. Hier wird der Durchsatz eines Datenstroms begrenzt, um die Bandbreite für andere Datenströme freizuhalten. Pakete, die die Bandbreitenbegrenzung überschreiten würden, werden in einer Queue gehalten, bis wieder genügend Bandbreite zu Verfügung steht. Eine Umordnung der Pakete wird grund- 10

27 Kapitel 2. Grundlagen 2.1. Quality of Service sätzlich nicht berücksichtigt, ist jedoch nicht ausgeschlossen. Werden Pakete verworfen, anstatt sie in einer Queue zwischen zu lagern, so spricht man von Traffic Policing. Alle diese Algorithmen stellen nicht-preemptive Scheduling-Algorithmen dar, da die Übertragung eines Paketes nicht abgebrochen werden kann, selbst wenn ein Paket höherer Priorität zum Senden eintrifft. Es existieren unzählige Algorithmen, die auf verschiedene Arten und mit teils unterschiedlichen Zielen diese Aufgaben erledigen. Hier sollen nur die besprochen werden, die für diese Arbeit Relevanz haben. Als relevant werden die Algorithmen eingestuft, die unter Linux oder in Switches implementiert sind und auch mit reinem Ethernet einwandfrei genutzt werden können Strict Priority Queueing Unter Strict Priority Queueing versteht man die Umsortierung streng nach Priorität. Zu versendende Pakete werden bei diesem Algorithmus entsprechend ihrer Priorität in verschiedene Ausgangsqueues sortiert. Zuerst werden die Pakete aus der Queue mit der höchsten Priorität verschickt. Ist diese Queue leer, werden die Pakete aus der Queue mit der nächst niedrigeren Priorität versendet usw. Die Pakete in einer Queue müssen immer so lange warten, bis die Queues mit höherer Priorität keine Pakete mehr enthalten. Innerhalb einer Queue werden die Pakete nach FIFO abgearbeitet. Abbildung 2.2: Beispiel: Strict Priority Queueing 11

28 2.1. Quality of Service Kapitel 2. Grundlagen Abbildung 2.2 zeigt ein Beispiel für Strict Priority Queueing, in dem drei Queues mit den Prioritäten 1 bis 3 verwendet werden, wobei Priorität 1 die höchste darstellt. Das Paket aus der Prio 1 Queue wird bedient (1). Da die Prio 1 Queue leer ist, wird das erste Paket aus der Prio 2 Queue verschickt. Während dessen trifft ein weiteres Paket in der Prio 1 Queue ein, das Versenden des Pakets in der Prio 2 Queue kann jedoch nicht unterbrochen werden(2). Die verbleibenden Pakete werden in Reihenfolge ihrer Priorität verschickt (3)-(6) Weighted Round Robin Queueing Dieser Scheduling Algorithmus baut auf dem Round Robin Algorithmus auf, bei dem eine bestimmte Menge von Queues existiert. Unter diesen wird die gesamte Bandbreite aufgeteilt, womit jede Queue ein sogenanntes Quantum an Bandbreite erhält. Beim Weighted Round Robin lässt sich das Quantum gewichten. So ist es möglich, einer Queue mit hoher Priorität ein größeres Quantum an Bandbreite zukommen zu lassen, als einer mit niedriger Priorität. Jede Queue nimmt die Bandbreite seines Quantums in Anspruch, unabhängig davon, ob sie genutzt werden kann. Abbildung 2.3: Beispiel: Weighted Round Robin Queueing Das in Abbildung 2.3 gezeigte Beispiel für den Weighted Round Robin Algorithmus zeigt drei Queues, mit den Quanten 1, 2 und 3. Die Queue mit Quantum 3 kann alle enthaltenen Pakete versenden (1). In der Queue mit Quantum 2 werden nur zwei der drei Pakete verschickt(2) und die Queue mit Quantum 1 bedient ihr einziges 12

29 Kapitel 2. Grundlagen 2.2. Ethernet im Echtzeitbetrieb Paket (3). Die Queue mit Quantum 3 hat keine Pakete mehr zu versenden, nimmt aber trotzdem ihre Zeiteinheiten in Anspruch (4). Die Queue mit Quantum 2 hat zwar nur ein Paket zu versenden, nimmt aber auch ihre die Zeit von zwei Quanten in Anspruch Token Bucket Algorithmus Der Token Bucket Algorithmus stellt eine Traffic Shaping Methode dar. Der Algorithmus sieht einen Container (Bucket) vor, in dem mit einer festgelegten Rate Token generiert werden. Jedes Token entspricht dabei einer festgelegten Anzahl Bytes. Soll ein Paket verschickt werden, muss eine Anzahl Token, entsprechend der Größe des Pakets, aus dem Container entfernt werden. Sind nicht genug Token im Container, muss das Paket warten, bis genügend Token generiert wurden. Die Rate, in der die Token generiert werden, entspricht somit der Bandbreite, die einem Datenstrom zur Verfügung steht. Die Kapazität des Containers gibt die Anzahl Bytes an, die in einem Burst verschickt werden können, soweit entsprechend viele Token generiert werden konnten. Die Kapazität muss mindestens so groß gewählt werden, wie ein maximal großes Paket, da sonst nie ausreichend Token im Container vorhanden wären, um ein solches Paket zu verschicken, und es die Queue blockieren würde. Das in Abbildung 2.4 gezeigte Beispiel zeigt einen Bucket mit einer Kapazität von acht Token. Es wird in dem Beispiel davon ausgegangen, dass ein Paket beim Senden drei Token verbraucht. In (1) ist der Bucket komplett gefüllt. Vier Pakete treffen ein, von denen zwei sofort als Burst versandt werden können. Die zwei übrig gebliebenen Token, reichen zum Versenden eines weiteren Pakets nicht aus (2). Abhängig von der eingestellten Rate wird ein weiteres Token generiert, womit das dritte Paket bedient werden kann(3). Das letzte Paket wartet auf weitere drei Token (4)+(5), bis es an der Reihe ist. Solange keine weiteren Pakete in der Queue eintreffen, wird der Bucket in der eingestellten Rate wieder bis zu seiner Kapazität gefüllt(6). 2.2 Ethernet im Echtzeitbetrieb IEEE Ethernet ist grundsätzlich nicht echtzeitfähig konzipiert worden und kann in seiner ursprünglichen Form nicht als Feldbusersatz eingesetzt werden [Fel00]. Das größte Problem dabei ist das nicht-deterministische Medienzugriffsverfahren 13

30 2.2. Ethernet im Echtzeitbetrieb Kapitel 2. Grundlagen Abbildung 2.4: Beispiel: Token Bucket Algorithmus CSMA/CD [Tan02, Hal96]. Da Kollisionen von CSMA/CD nur erkannt und nicht verhindert werden, müssen Übertragungen abgebrochen und deren Neusendung initiiert werden. Diese kann bei hoher Last wiederum zu weitern Kollisionen führen, die somit zu unbestimmbaren Verzögerungen führen. Im wesentlichen existieren drei Ansätze, wie Kollisionen im Ethernet verhindert werden können: Lastreduzierung, TDMA und der Einsatz von Switches Lastreduzierung Der erste Ansatz Lastreduzierung ist von rein probabilistischer Natur und zielt darauf ab, die genutzte Bandbreite weit unter der verfügbaren zu halten [JL04]. Damit wäre eine statistische Garantie für die Einhaltung von Delay-Grenzen gegeben. Da es sich aber nur um eine statistische Garantie handelt, kann dieser Ansatz harten Echtzeitanforderungen nicht gerecht werden. Zugleich würde diese Lösung einer Konfiguration mit hoher Anzahl an Knoten nicht mehr standhalten, da die zur Verfügung stehende Bandbreite dafür kaum ausreichen würde. Somit würde dabei die Wahrscheinlichkeit des Auftretens von Kollisionen wieder ansteigen. 14

31 Kapitel 2. Grundlagen 2.2. Ethernet im Echtzeitbetrieb Time Devision Multiple Access Der zweite Ansatz sieht ein TDMA-Verfahren vor, bei dem jedem Knoten auf dem Medium ein Zeitschlitz zugewiesen ist, während dessen er senden darf. Die Zuteilung der Zeitschlitze wird statisch oder durch einen Master-Knoten bestimmt. Die Synchronisation wird durch den Einsatz einer fein granularen Uhr und eines Zeitprotokolls wie PTP [IEE] durchgesetzt. Die festen Delay-Grenzen werden von der gewählten Zykluszeit bestimmt. Durch die Wahl einer geringen Zykluszeit entsteht ein geringer Delay, jedoch wird auch die zur Verfügung stehende Bandbreite verringert. Durch die festen Zeitabstände entsteht ein geringer Jitter. Da nicht jeder Knoten in seinem Zeitschlitz sendebereit ist, bleibt Bandbreite teilweise ungenutzt, die für Best-Effort-Verkehr hätte genutzt werden können. Dieses Verfahren wird in Zusammenhang mit Ethernet unter anderem von RTnet [KS04] eingesetzt, welches die Nutzung der Echtzeiterweiterung RTAI unter Linux vorsieht. RTNet implementiert einen kompletten, echtzeitfähigen UDP/IP-Stack, der durch ein BSD-Socket-Interface erschlossen wird. Es setzt ein geschlossenes und durch einen Hub verschaltetes Netz voraus, in dem sich alle Teilnehmer an das TDMA-Protokoll halten und ein Masterknoten für die Synchronisierung der Stationen sorgt. Der Stack der beteiligten Rechner wird durch einen modifizierten Linux- Treiber an Ethernet angebunden. Eine Fernkonfiguration dieser Rechner ist durch ein eigenes, vom RTNet-Protokoll unabhängiges Protokoll namens RTcfg möglich. Die vertikale Integration erfolgt durch Tunnelung der betroffenen Protokolle über einen Gatewayknoten. Ein weiteres Beispiel für TDMA ist Profinet IRT (Isochronous Real Time) [eh]. Dieses teilt das Medium zunächst in einen deterministischen und einen offenen Zeitschlitz auf. Im offenen Zeitschlitz wird der gesamte Best-Effort-Verkehr, sowie der Verkehr mit weichen Echtzeitanforderungen abgewickelt. Die weiche Echtzeit wird durch Priorisierung nach IEEE 802.1p durchgesetzt. Der deterministische Zeitschlitz ist in weitere Zeitschlitze unterteilt, in denen Kommunikation nach harten Echtzeitanforderungen abläuft. Die Reservierung der Zeitschlitze erfolgt über einen speziell für diesen Zweck entwickelten Chip, der in die verwendeten Switches integriert ist. Im Zusammenhang mit TDMA soll noch das Token-Passing-Verfahren genannt werden. Auch hier wird das Medium in Zeitschlitze aufgeteilt, jedoch ist das Synchronisieren der Uhren in den Knoten nicht notwendig. Die Sendeberechtigung wird durch ein Token zugeteilt, das in Form eines Pakets zyklisch unter den Stationen ausge- 15

32 2.2. Ethernet im Echtzeitbetrieb Kapitel 2. Grundlagen tauscht wird. Der Besitzer des Tokens sendet seine Daten und reicht dann das Token an den nächsten weiter Einsatz von Switches Ein Switch ist ein Vermittlungselement zwischen Netzen, welches auf der MAC- Teilschicht der in IEEE 802 Standard [IEE01] beschriebenen Architektur arbeitet. Die Funktionsweise wird im Standard IEEE 802.1D [IEE04] festgelegt. Durch den Einsatz eines in Voll-Duplex-Modus arbeitenden Switches ist es möglich, Kollisionsdomänen zu segmentieren. Durch Microsegmentierung, d.h Zuweisung eines Ports für jeden Rechner, sind Kollisionen ausgeschlossen, was ein vollkommen deterministisches Verhalten von Ethernet zur Folge hat [Jas02]. Im Folgenden sollen die Funktionsweise und der Aufbau anhand der Abbildung 2.5 erläutert werden. Abbildung 2.5: Aufbau eines Switch Ein Switch besitzt mindestens zwei Ports, die sowohl unterschiedliche Datenraten, 16

33 Kapitel 2. Grundlagen 2.2. Ethernet im Echtzeitbetrieb als auch Duplex-Modi aufweisen können. Die Vermittlung zwischen den einzelnen Ports wird durch eine Vermittlungseinheit vorgenommen. Diese verwaltet eine Tabelle mit MAC-Adressen, die jeweils einem Port zugeordnet sind. Trifft ein Frame an einem Port ein, so wird er im Shared Memory des Switches abgelegt. Dort wird die Zieladresse des Frames ausgelesen und durch die Vermittlungseinheit mit den Adressen in der MAC-Tabelle verglichen. Gehört diese Adresse zu dem Port, auf dem der Frame empfangen wurde, wird der Frame verworfen. Ansonsten wird ein Zeiger auf die Speicheradresse des Frames in die Ausgangsqueue des entsprechenden Ports zwecks Weiterleitung eingereiht. Für den Fall, dass die Adresse nicht in der Tabelle enthalten ist, leitet er den Frame an alle Ports weiter (Flooding). Sobald der adressierte Rechner antwortet, kann die Vermittlungseinheit die MAC-Adresse dem Port zuordnen, auf dem er empfangen wurde, und sie in die Tabelle eintragen. Der Frame verweilt so lange im Shared Memory des Switches, bis die Ausgangsqueue auf die Position des zugehörigen Zeigers abgearbeitet ist und der Frame verschickt werden kann. Die Ausgangsqueues der Ports weisen in der Regel FIFO- Charakteristik auf; um jedoch User-Prioritäten nach 802.1p berücksichtigen zu können, sieht der Standard 802.1D [IEE04] auch die Ausstattung der Ports mit mehr als einer Queue vor. Da dort nicht zwingend acht Queues vorgesehen,sind erfolgt eine Zuteilung der Verkehrsklassen aus Tabelle 2.3 aufgrund von Tabelle 2.4. Diese Queues werden in der Regel dann nach dem Strict Priority Algorithmus abgearbeitet, können auf den einzelnen Switches aber auch per Weighted Round Robin bedient werden. Anzahl Queues Traffic Klasse 1 BE 2 BE VO 3 BE CL VO 4 BK BE CL VO 5 BK BE CL VI VO 6 BK BE EE CL VI VO 7 BK BE EE CL VI VO NC 8 BK BE EE CL VI VO NC Tabelle 2.4: Zuteilung der Traffic Klassen pro Anzahl der Ausgangsqueues [IEE04] 17

34 2.2. Ethernet im Echtzeitbetrieb Kapitel 2. Grundlagen Durch die gezielte Verteilung der Frames an ihre Zielnetze, werden die Netzwerke bzw. die zugehörigen Ports nicht belastet und es kommt nicht so schnell zu Überläufen und damit zu Paketverlust. Durch den Einsatz von Multicasts [IEE01] macht man diesen Vorteil zunichte, da diese, wie Broadcasts, über alle Ports gesendet werden. Um diesen Vorteil auch mit Multicasts nutzen zu können, wird in IEEE 802.1p [IEE04] das GARP Multicast Registration Protocol (GMRP) vorgestellt. Ein Switch der GMRP unterstützt leitet grundsätzlich erst einmal keine Multicast-Frames weiter. Empfängt er ein GMRP Paket mit der Information, dass eine Station Frames einer Multicast-Gruppe empfangen möchte, so wird diese in die MAC-Adresstabelle eingetragen. Das bewirkt, dass diese Frames über diesen Port weitergeleitet werden. Genauso ist es auch möglich, Multicast-Gruppen per GMRP zu deregistrieren. Managebare Switches, die kein GMRP unterstützen, lassen oft auch zu, die MAC- Adresstabelle für den Multicastbetrieb manuell zu konfigurieren. Switches, die über mehrere Ausgangsqueues pro Port verfügen und den IEEE 802.1p Standard unterstützen, werden unter anderem von Cisco (Catalyst 2950 mit 4 Queues) und Siemens (ELS TP40M mit 2 Queues) hergestellt Fazit Die vorgestellten Verfahren zur Erlangung von Determinismus unter Ethernet haben jeweils ihre Vorteile, jedoch auch ihre Einschränkungen. So ist Lastreduzierung zur Erlangung einer statistischen Kollisionsfreiheit in einem kleinen Netzwerk mit wenigen Teilnehmern eine günstige Lösung, jedoch skaliert diese nicht bei ansteigender Zahl der beteiligten Knoten. TDMA ist sehr aufwendig in der Umsetzung und setzt eine Anpassung des Protokoll- Stacks oder die Verwendung angepasster Hardware voraus. Dafür bietet es harte Echtzeitfähigkeit mit kontrolliertem Jitter. Der Einsatz von Switches bietet Determinismus durch Microsegmentierung des Netzwerks. Darüber hinaus kann QoS durch standardisierte Protokollerweiterungen durchgesetzt werden, wenn der Switch diese unterstützt und über geeignete Hardware verfügt. Ob sich dadurch harte Echtzeitanforderungen durchsetzen lassen, hängt von den Anforderungen des technischen Prozesses ab. Bei geeigneter Topologie und konfigurierter Last, können Transaktionszeiten im Millisekunden-Bereich garantiert werden [Jas02]. 18

35 Kapitel 2. Grundlagen 2.3. Linux 2.3 Linux Linux bietet als freies Betriebssystem diverse Einstellmöglichkeiten für Quality of Service, auf die im Folgenden eingegangen wird. In dieser Arbeit soll der Linux- Kernel ab Version 2.6 betrachtet werden, dessen System-Timer seit der Version 2.4 einen Granularitätsanstieg um den Faktor 10 auf 1000Hz erfahren hat Packet-Sockets Ein Packet-Socket ist eine direkte Schnittstelle zur Kommunikation über Ethernet. Bei den durch einen Packet-Socket versendeten Daten, wird nur der Ethernet-Header hinzugefügt, wodurch der TCP/UDP/IP-Stack umgangen wird. Der Packet-Socket ist zwar kein explizites QoS-Werkzeug, doch durch seinen Einsatz können Delay und Jitter implizit reduziert werden. Die Konfiguration erfolgt auf die gleiche Weise, wie die eines INET-Socket, durch den Aufruf des Systemcalls socket(). Quelltext 2.1: Der socket()-systemcall für Packet-Sockets packet_socket = socket ( PF_PACKET, int socket_type, int protocol ); Gibt man für den Parameter socket_type den Wert SOCK_DGRAM an, so wird der Header des Frames beim Versand durch das Betriebssystem generiert und beim Empfang automatisch wieder entfernt. Gibt man SOCK_RAW, an müssen diese von dem aufrufenden Prozess bereitgestellt bzw. entfernt werden. Der Parameter protocol nimmt den Protokolltyp auf, den der Socket empfangen soll. Der verwendete Wert wird in Network-Byte-Order übergeben und ist im Ethernet- Header im Type-Feld wiederzufinden. In der Header-Datei linux/if ether.h sind die allgemein bekannten Protokolle, wie ETH_P_IP (0x8000) oder auch ETH_P_8021Q (0x8200) definiert. Es ist jedoch auch möglich ein eigenes Protokoll zu definieren, wobei darauf geachtet werden sollte, dass es nicht mit den reservierten Protokollen kollidiert. Zur Adressierung wird die sockaddr_ll-struktur genutzt, die bei Aufrufen von sendto () übergeben wird. Die Struktur wird ausführlich auf der Manpage packet(7) besprochen. Dort wird auch erklärt, wie ein Paket-Socket für den Empfang von Ethernet- Multicast-Frames eingerichtet wird. 19

36 2.3. Linux Kapitel 2. Grundlagen Q VLAN Modul Die Virtual LAN Funktionalität wird unter Linux von dem Modul 8021q gewährleistet. Um das Modul nutzen zu können, muss es entweder dynamisch geladen oder fest in den Kernel kompiliert werden. Die dafür erforderliche Kernel-Option für Kernel 2.6 ist unter Device Drivers/Networking support/networking options/802.1q VLAN Support zu finden Aufbau und Funktionsweise Wird ein neues VLAN konfiguriert, so wird dafür ein neues logisches Netzwerk- Device erstellt. Normalerweise repräsentiert ein logisches Device unter Unix/Linux ein in Hardware vorhandenes Netzwerkinterface. Das für das VLAN erstellte Device repräsentiert keine Hardware. Vielmehr ist es einem realen, logischen Netzwerk- Device vorgeschaltet und wird als virtuelles Gerät bezeichnet(abbildung 2.6). Der Name des virtuellen Devices ist abhängig von der Konfiguration des Moduls. Tabelle 2.6 zeigt hierfür alle Möglichkeiten der Konfiguration auf, sowie deren Default- Einstellung. Normalerweise wird das Device, über das Pakete verschickt werden, durch den Routing-Prozess ermittelt. Daher ist es empfehlenswert, die Devices verschiedenen Subnetzen zuzuordnen oder die Sockets durch Socket-Optionen an das jeweilige Device zu binden. Ansonsten ist nicht eindeutig, auf welchem der Devices ein Paket gesendet werden soll. Jedem Device können bis zu 4093 VLANs (2 12 3) zugewiesen werden. Abbildung 2.6: Aufbau der VLAN-Devices 20

37 Kapitel 2. Grundlagen 2.3. Linux Wird ein Paket über ein VLAN verschickt, muss das über das dazugehörige virtuelle Device geschehen. Dort wird das VLAN-Tag mit der entsprechenden VID in das Paket eingefügt und an das reale Device weitergegeben. Umgekehrt werden am realen Device empfangene Pakete, die VLAN-gekennzeichnet sind, an das entsprechende virtuelle Device weitergereicht. Dort wird das Tag entfernt und über den Protokoll- Stack an den Empfängerprozess weitergegeben. Das Setzen des Wertes im User-Priority-Feld wird durch zwei Priority-Maps erreicht: der Egress-Priority-Map und der Ingress-Priority-Map. Die Egress-Priority-Map bildet beim Senden eines Pakets die Priorität dessen Socket-Buffers auf den Wert im User-Priority-Feld ab. Der Socket-Buffer ist eine Struktur im Linux Kernel, mit der die zu sendenden und empfangenen Pakete durch den Protokoll-Stack nach unten bzw. nach oben weitergereicht werden. Desweiteren enthält die Egress-Priority-Map weitere Flags und Werte, u.a. Socket-Priority, die mit dem zugehörigen Socket assoziiert werden. Für die Möglichkeit, die User-Priority auf die Socket-Priority zurück zu rechnen, ist die Ingress-Priority-Map zuständig. Diese wird aber nur für den Fall benötigt, dass Linux Bridging-Funktionen übernehmen soll. Die Priorität aller Socket-Buffer- Strukturen, die durch einen Socket gesendet werden, kann über eine Socket-Option gesetzt werden. Ansonsten wird der Wert des DS-Feldes im IP-Header auf die Priorität abgebildet. Die Prioritäten des User-Priority-Feld können mit dem 802.1Q Modul zwar gesetzt werden, jedoch wird die Einhaltung der Prioritäten nicht durchgesetzt. Dazu ist der Einsatz von Paket Scheduling Algorithmen nötig, die die Pakete nach dem User-Priority-Feld klassifizieren und entsprechend bedienen Konfiguration Die Konfiguration der VLANs und deren Parameter erfolgt durch das Open-Source Tool-vconfig, welches in jeder größeren Linux Distribution enthalten ist. Weitere Informationen sind der Manpage des Programms zu entnehmen. Möchte man die Konfiguration aus einem C-Programm vornehmen, so empfiehlt es sich, dass Application Programming Interface (API) zu nutzen, das auch von vconfig verwendet wird. Das Wissen über die Funktionalität des API wurde hauptsächlich aus dem Quellcode des vconfig-tools und dem 8021q Kernelmodul hergeleitet. Daher wird nicht der Anspruch auf Vollständigkeit erhoben. 21

38 2.3. Linux Kapitel 2. Grundlagen Die dafür erforderlichen Header-Dateien sind: # include <sys / ioctl.h> # include <linux / if_vlan.h> Der Systemcall ioctl() (Listing 2.2) dient als Schnittstelle zum 8021q Kernelmodul. Für die Handhabung der Funktion sei wiederum auf die entsprechende Manpage verwiesen. Quelltext 2.2: Der ioctl()-systemcall int ioctl ( int d, int request, void * argp ); Für den request -Parameter wird der definierte Wert SIOCSIFVLAN verwendet. Um die Anfrage näher zu spezifizieren, ist in if_vlan.h die Struktur struct vlan_ioctl_args definiert. Im Folgenden soll nun deren Aufbau und Funktion anhand des Quelltext- Listings 2.3 beschrieben werden. Quelltext 2.3: Die vlan_ioctl_args Struktur 1 struct vlan_ioctl_args { 2 int cmd ; 3 char device [24] 4 union { 5 char device2 [24]; 6 int VID ; 7 unsigned int skb_priority ; 8 unsigned int name_type ; 9 unsigned int bind_type ; 10 unsigned int flag ; 11 } u; 12 short vlan_qos ; 13 }; Das Datenmember cmd (Zeile 2) dient der Spezifizierung des Kommandos, das an das Kernel-Modul abgesetzt werden soll. Abhängig von den Kommandos (Tabelle 2.5) werden weitere Member-Argumente genutzt. Für jeden Befehl wird der den Namen des Devices, das konfiguriert werden soll in device (Zeile 3) gespeichert. Um ein virtuelles Device mit dem Kommando ADD_VLAN _CMD anzulegen, wird der Name des realen Device angegeben, an dem das virtuelle konfiguriert werden soll. Alle anderen Kommandos haben den Namen des zu konfigurierenden, virtuellen Devices als Argument. Das Member device2 (Zeile 5) der Union u dient der Übergabe eines zweiten Device- Namens. Bisher ist kein Kommando definiert, welches dies nutzt. VID (Zeile 6) wird beim Kommando ADD_VLAN_CMD genutzt, um die gewünschte VID an das Kernel-Modul zu übergeben. 22

39 Kapitel 2. Grundlagen 2.3. Linux Mit skb_priority (Zeile 7) wird die Priorität eines Socket-Buffers übergeben, die auf einen Wert im User-Priority-Feld eines Frames abgebildet werden soll. Dieses Member wird von den Kommandos SET_VLAN_INGRESS_PRIORITY_MAP_CMD und SET_VLAN_EGRESS_PRIORITY_MAP_CMD genutzt. name_type (Zeile 8) bestimmt die Art, wie die virtuellen Devices benannt werden. Tabelle 2.6 beschreibt die in if_vlan.h dafür definierten Werte und deren Auswirkung auf die Namensgebung der virtuellen Devices. In bind_type (Zeile 9) wird bestimmt, ob eine VID für den gesamten Kernel oder für jedes reale Device eindeutig ist. Zur Zeit der Erstellung dieser Arbeit existiert kein Kommando, das dieses Member nutzt. flag (Zeile 10) nimmt den Key für ein Flag auf, das gesetzt werden soll, wenn für cmd (Zeile 2) das Kommando SET_VLAN_FLAG_CMD gesetzt wurde. Zur Zeit dieser Arbeit existiert nur das REORDER_HDR Flag, das angibt, ob der Header neu geordnet werden soll. Dies soll die Kompatibilität zu diversen Programmen wahren, bedeutet aber auch Performance-Einbußen. Wenn die Option nicht unbedingt erforderlich ist, wird empfohlen, sie nicht zu nutzen. Das Datenmember vlan_qos (Zeile 12) hat zwei Funktionen: Hauptsächlich wird es genutzt, um bei den Kommandos SET_VLAN_INGRESS_PRIORITY_MAP_CMD und SET_VLAN _EGRESS_PRIORITY_MAP_CMD den User-Priority-Wert anzugeben, auf den ein Prioritätswert der Socket-Buffer abgebildet wird. Zusätzlich wird es beim Kommando SET_VLAN_FLAG_CMD genutzt, um einen optionalen Wert für das in flag angegebene Flag aufzunehmen. Kommando Bedeutung Argumente (Zeilennr.) ADD_VLAN_CMD Erstelle ein VLAN VID (3) DEL_VLAN_CMD Entferne ein VLAN SET_VLAN_INGRESS- Setze ein Socket-/User-Priority skb_priority (8) _PRIORITY_MAP_CMD Wertepaar für Ingress-Priority-Map vlan_qos (13) SET_VLAN_EGRESS- Setze ein Socket-/User-Priority skb_priority (8) _PRIORITY_MAP_CMD Wertepaar für Egress-Priority-Map vlan_qos (13) GET_VLAN_INGRESS- Wird zur Zeit der Arbeit nicht _PRIORITY_MAP_CMD unterstützt GET_VLAN_EGRESS- Wird zur Zeit der Arbeit nicht _PRIORITY_MAP_CMD unterstützt 23

40 2.3. Linux Kapitel 2. Grundlagen SET_VLAN_NAME- Setze die Namensgebung des name_type (9) _TYPE_CMD virtuellen Interfaces SET_VLAN_FLAG_CMD Setze ein Flag flag (11) vlan_qos (13) Tabelle 2.5: VLAN ioctl Kommandos Wert Namensbildung Beispiel VLAN_NAME_TYPE- vlan<4 Stellen VID> vlan0002 _PLUS_VID VLAN_NAME_TYPE- <Device Name>.<4 Stellen VID> eth _RAW_PLUS_VID VLAN_NAME_TYPE- vlan<vid> vlan2 _PLUS_VID_NO_PAD VLAN_NAME_TYPE- <Device Name>.<VID> eth0.2 _RAW_PLUS_VID_NO_PAD (default) Tabelle 2.6: Namensgebung des VLAN Device Queueing Disziplinen Queueing Disziplinen (QDiscs) sind die Implementierung von Paket Scheduling Algorithmen unter Linux. Jedem Netzwerk-Device ist eine QDisc zugeordnet Funktionsweise QDiscs sind zwischen dem jeweiligen Netzwerktreiber und den höheren Protokollschichten angeordnet (Abbildung 2.7). Ist vor dem realen Device ein virtuelles geschaltet, liegen zwischen dem Treiber und den höheren Protokollschichten zwei QDiscs. Die Funktionsweise einer QDisc ist aus der Sicht der angrenzenden Protokollschichten absolut transparent. Für sie existieren nur vordefinierte QDisc-Methoden. Die wichtigsten sind enqueue(), dequeue() und requeue(). Alle Informationen und die Funktionalitäten eines Netzwerk-Devices werden in der net_device-struktur gehalten, die in netdevice.h definiert ist. Hier wird auch ein 24

41 Kapitel 2. Grundlagen 2.3. Linux Abbildung 2.7: Funktionsweise von Queueing Disziplinen Zeiger auf die QDisc des Devices gehalten. Wird ein Paket über ein Netzwerk-Device verschickt, so ruft die höhere Protokollschicht die Funktion dev_queue_xmit() in der Struktur auf. Diese übergibt den Socket-Buffer des Pakets an die enqueue()-funktion der QDisc. Daraufhin startet dev_queue_xmit() die Funktion qdisc_run(), die dafür sorgt, dass die Funktion qdisc_restart() zyklisch ausgeführt wird. Bevor die beiden Abbruchbedingungen dieser Schleife erläutert werden, wird näher auf die Funktion qdisc_restart() eingegangen. qdisc_restart() ruft die dequeue()-funktion der QDisc auf. Wird ein Paket von der QDisc zurückgeliefert, so wird das Paket mit der Funktion hard_start_xmit() an den Treiber übergeben und über die Hardware versendet. Im Falle eines virtuellen Devices wird das Paket mit der Funktion dev_queue_xmit() an das reale Device übergeben. Ist das Netzwerk-Interface nicht bereit ein Paket entgegen zu nehmen, blockiert es. In diesem Fall wird das Paket mit der Funktion requeue() wieder in die QDisc an der ursprünglichen Position eingefügt. Das Blockieren des Netzwerk- Interfaces gilt als eine Abbruchbedingung für die Schleife in qdisc_run(). Die zweite Abbruchbedingung betrifft den Fall, dass die Queueing Disziplin kein Paket zurück liefert. Das heißt nicht, dass sich kein Paket in der Queue befindet. Je nach Bedingung des verwendeten Algorithmus könnte die QDisc enthaltene Pakete noch zurückhalten, um z.b. die Bandbreite zu begrenzen. Gibt die QDisc ein zurückgehaltenes Paket zum Senden frei oder kehrt das Device aus einem blockierten Zustand 25

42 2.3. Linux Kapitel 2. Grundlagen zurück, kann nicht auf das Anstoßen von qdisc_run() durch das Eintreffen eines weiteren Pakets in der QDisc gewartet werden. Hierzu existiert der Software-Interrupt NET_TX_SOFTIRQ, der die Funktion aufruft. Ausgelöst wird der Interrupt zum einen durch den Jiffies-Timer, der den Kernel-Takt von 1ms erzeugt, und zum anderen durch den Übergang des Hardware-Devices vom blockierten in den unblockierten Zustand. Die Granularität des Jiffies-Timers beträgt im Linux-Kernel 2.6 1ms, der auf 1µs heruntergerechnet wird. Bei der Kernel-Konfiguration stehen Alternativen zum Jiffies- Timer zur Verfügung, die im Folgenden genannt werden. Auf Architekturen, die über ein CPU-Cycle-Counter verfügen, kann dieser als Timer für das QoS-Modul konfiguriert werden. Er weist eine weit höhere Granularität als 1µs auf, die dann auf 1µs hochgerechnet wird. Es wird empfohlen diesen zu nutzen falls er zur Verfügung steht, allerdings kann es zu Problemen auf Mehrprozessorsystemen kommen oder bei Prozessoren, die Frequenzwechsel unterstützen. Die zweite Alternative ist die Funktion gettimeofday(), die eine Granularität von genau 1µs aufweist. Es wird jedoch von dieser Möglichkeit abgeraten, da sie zu viel CPU-Zeit verbraucht Aufbau Queueing-Disziplinen unterscheiden sich untereinander in ihrem internen Aufbau (Abbildung 2.8). Grundsätzlich lassen sie sich in zwei Kategorien einordnen: die klassenlosen und die klassenbehafteten Queueing Disziplinen. Die klassenlosen QDiscs sind Implementierungen von Paket-Scheduling-Algorithmen, deren interner Aufbau nicht weiter konfigurierbar ist. Sie besitzen eine in Grenzen konfigurierbare Funktionalität und sind nicht erweiterbar. Die Art, wie Daten klassifiziert werden, ist fest vorgegeben und lässt sich nicht verändern. Klassenbehaftete Queueing Disziplinen sind modular aufgebaut [WPR + 02]. Intern lassen sich Klassen konfigurieren, die jeweils verschiedene Eigenschaften, wie z.b. Prioritäten, besitzen. Mit diesen Klassen lassen sich Baumstrukturen herstellen, deren Aufbau jedoch von der jeweiligen Queueing Disziplin abhängt. So kann die Klassenhierarchie bei bestimmten QDiscs nicht in die Tiefe wachsen. Klassen halten selbst keine Daten, ihnen muss eine QDisc zugeordnet werden, die die Daten auffängt. Dies kann sowohl eine klassenlose als auch eine klassenbehaftete QDisc sein, was wiederum eine weitere Verästelung der Baumstruktur zur Folge hat. 26

43 Kapitel 2. Grundlagen 2.3. Linux Abbildung 2.8: Aufbau von Queueing Disziplinen Das Verhalten der Blatt-QDiscs nimmt durch ihr eigenes Verhalten Einfluss auf das Verhalten ihrer Eltern-QDisc. Um Pakete den Klassen zuzuordnen, bringen viele QDiscs ihren eigenen Klassifizierer mit, die auf ihr Verhalten zugeschnitten sind. Um höhere Flexibilität beim Klassifizieren der Pakete zu erreichen, stehen eine Reihe von individuellen Filtern zur Verfügung, deren Funktionalität vom einfachen Erkennen eines Feldes im IP- Header (dsmark), über die Auswertung von Routinginformationen (route, fw), bis hin zur kompletten Mustererkennung im gesamten Paket (u32) reicht. Wird ein Filter an einer QDisc oder Klasse angebracht, überschreibt er deren eigenen Klassifizierer. Existieren mehrere Filterregeln nebeneinander, kann die Reihenfolge, in der sie abgefragt werden, durch einen Prioritätswert bestimmt werden. Wird ein Klasse oder QDisc gelöscht, so werden automatisch alle ihre Kindklassen und deren QDiscs mitgelöscht. Jedoch kann eine Klasse nur gelöscht werden, wenn kein Filter mehr auf diese Klasse verweist. Vom Linux-Kernel werden alle Elemente des Baums über 32-Bit Handles verwaltet. Diese sind zu jeweils 16-Bit in eine Major- und eine Minor-Nummmer aufgeteilt, welche nichts mit den Major- und Minor-Nummern der Linux-Gerätedateien zu tun haben. Die Handles sind für jedes Device eindeutig, können sich somit über alle Devices wiederholen. Die Minor-Nummer von Queueing Disziplinen ist stets null. Ausnahme davon sind die Root Queueing Disziplin und die Ingress Queueing Disziplin. Das Handle der 27

44 2.3. Linux Kapitel 2. Grundlagen Root QDisc ist FFFF:FFFF und als TC_H_ROOT definiert. Für die Ingress QDisc ist das Handle FFFF:FFF1 reserviert, welches als TC_H_INGRESS definiert ist. Beide beschreiben keine Queueing Disziplin im eigentlichen Sinne, sondern sind vielmehr Andockpunkte für die Wurzel-QDisc. Queueing Disziplinen, die an der Ingress QDisc angebracht werden, können nur für Traffic Policing genutzt werden. Nicht alle Queueing Disziplinen sind dazu geeignet. Beim Hinzufügen einer QDisc kann der Benutzer die Major-Nummer aus einem Intervall von 0x0001 bis 0x7FFF selbst wählen. Wird kein Handle vom Benutzer übergeben, weist der Kernel der QDisc eine Major-Nummer zwischen 0x8000 und 0xFFFF zu. Die Major-Nummer einer Klasse entspricht immer der Major-Nummer der QDisc, der sie angehört. Die Minor-Nummer hat einen zur Major-Nummer eindeutigen Wert im Intervall von 0x0001 bis 0xFFFF. Zur Konfiguration der Queueing Disziplinen steht das Programm tc zur Verfügung, dass im Paket iproute2 enthalten ist. Möchte man jedoch die QDiscs von einem Programm heraus konfigurieren, so existiert hierfür die Netlink-Socket-Schnittstelle. Deren Dokumentation ist jedoch sehr spärlich bis gar nicht vorhanden, so dass sie im Rahmen dieser Arbeit analysiert werden musste. Aus diesem Grund wird sie im Kapitel 3.4 beschrieben. Zu näheren Information über die Konfiguration der Queueing Disziplinen mit tc, sei [Hub03] empfohlen. 28

45 Kapitel 3 Analyse 3.1 Anforderungen Abbildung 3.1: Use-Case Diagramm 29

46 3.1. Anforderungen Kapitel 3. Analyse Anfordern von QoS Es gibt zwei Möglichkeiten, wie QoS-Eigenschaften für einen Kommunikationspfad angefordert werden können. Zunächst kann ein Prozess versuchen, die QoS-Eigenschaften zur Laufzeit zu reservieren. Ein Modul, dass die Resourcen verwaltet, entscheidet dann, ob sie diese für den Prozess reservieren kann. Voraussetzung dafür ist, dass das Modul die Topologie des Netzes kennt, da sonst QoS-Parameter, wie Ende-zu-Ende-Verzögerung, nicht ermittelbar sind. Die zweite Möglichkeit ist, mit einer Scheduability-Analyse zu bestimmen, ob die benötigten QoS-Parameter für die Kommunikationspfade bereitgestellt werden können. Dies findet meistens in der Industrieautomation Anwendung, denn dort findet man gewöhnlich statische Konfigurationen vor. Die Konfiguration der QoS-Parameter lässt sich dadurch schon vor der Inbetriebnahme der Anlage vornehmen und muss nicht erst von den einzelnen Knoten beantragt werden Steuern und Regeln In einer automatisierten Anlage treten sich zyklisch wiederholende Prozesse auf. Zur Steuerung einer solchen Anlage müssen Stellgrößen jeweils einmal pro Zyklus an die entsprechenden Aktoren übertragen werden. Desweiteren werden auch die Prozesszustände von den Sensoren für jeden Zyklus erfasst. Dies resultiert in isochron propagierten Datagrammen, die an jeden Knoten gerichtet sind, der sie benötigt. Damit der sendende Knoten nicht die Adressen aller Knoten halten muss, die seine Informationen benötigen, und kein Overhead durch mehrfach gesendete Daten an verschiedene Knoten entsteht, wird für jede Nachrichtenklasse eine Multicast- Gruppe eingerichtet. Somit können die Knoten, die bestimmte Daten benötigen, sich diese aus dem Verkehr herausgreifen. Diese Form der Kommunikation tritt meistens im hohen bis mittleren Prioritätsspektrum auf. So werden für die Prozesssteuerung kritischen Mess- und Steuerdaten mit hoher Priorität verteilt, während Messdaten, die einer statistischen Erfassung dienen, eine mittlere Priorität aufweisen. Die Stationen, die eine Anlage steuern, befinden sich in der Regel in einem Netzwerksegment, dessen Topologie statisch ist. Da alle Adressen bekannt sind, wird die 30

47 Kapitel 3. Analyse 3.1. Anforderungen Nutzung der höheren Protokollschichten unnötig. Daher besteht der Protokoll-Stack in der Automation meist nur aus Layer 1, 2 und 7 [Fur03]. Dies hat mehrere Vorteile: Zum einen verringern sich der Delay und der Jitter im Stack, da weniger Code ausgeführt werden muss und zeitaufwendige Protokolle wie ARP nicht mehr zur Anwendung kommen. Zum anderen haben Mess- und Steuerdaten in der Regel nur eine geringe Größe. Durch Aussparen der höheren Protokolle wird ein massiver Overhead durch die Protokoll-Header verhindert Alarm-Signalisierung Kommt es in einer automatisierten Anlage zu Fehlerzuständen, Unfällen oder anderen unvorhersehbaren Ereignissen, muss die Anlage sofort gestoppt werden können, um schwere Verletzungen oder eine Beschädigung der Anlage zu verhindern. Um das zu erreichen, muss eine Nachricht höchster Priorität an alle Knoten der Anlage gesandt werden, um sie von dem Fehlerzustand unterrichten. Diese stellen den Betrieb ein und lassen die Anlage in einen sicheren Zustand zurückkehren Datei-Download / Upload Durch vertikale Integration ist es möglich, von einem dedizierten Rechner Dateien von bzw. auf einen Automationsrechner zu laden. Dies wird genutzt, um z.b Firmware-Updates auf eine Steuerungseinheit zu laden oder eine lokal gespeicherte Log-Datei bzw. Messdaten von einem Automationsrechner herunterzuladen. Um große Datenmengen zu transferieren, ist die Nutzung klassischer Netzwerkprotokolle, wie FTP oder HTTP in Verbindung mit TCP/IP empfehlenswert. TCP/IP spaltet selbstständig große Dateien auf und stzt sie nach Ankunft am Empfänger wieder aus den einzelnen Paketen zusammen. Das Bestreben ist es, möglichst große Pakete zu bilden, um einem zu großen Overhead durch die Protokoll-Header entgegenzuwirken. Datenverkehr dieser Art hat meist eine niedrige Priorität Human-Machine-Interface Die Überwachung einer Anlage geschieht meist von einem Rechner durch ein Human- Machine-Interface (HMI), welches den laufenden Prozess visualisiert und die Abfragemöglichkeiten von Mess- und Statusinformationen bietet. Weiterhin kann mit dem 31

48 3.1. Anforderungen Kapitel 3. Analyse HMI in einen Automatisierungsprozess eingegriffen werden, um z.b. Regelgrößen zu justieren oder einen Nothalt auszulösen. Auch der Datei-Download bzw. -Upload kann darüber angestoßen werden. Die Informationen, die für die Überwachung eines Prozesses gebraucht werden, können sowohl nach dem Push, als auch nach dem Pull-Modell erfolgen. Ersteres kommt hauptsächlich bei der Visualisierung zum Einsatz, wo zyklische Updates von Daten nötig sind. Teilweise werden die Steuer- und Messdaten genutzt, die im Netz schon für die Steuerung und Regelung des Systems propagiert werden. Rein für die Visualisierung benötigte Daten, werden in der Regel in größeren Intervallen mit niedrigerer Priorität verteilt. Einzelne Statusabfragen erfolgen in der Regel nach dem Pull-Modell, da diese nur sporadisch benötigt werden. Als Reaktion auf eine Statusabfrage wird eine einzelne Aktualisierung der letzten Statusinformationen erwartet. Wird eine Visualisierung nicht durchgängig benötigt, so kann die Verteilung der rein für diesen Zweck benötigten Daten nach dem Publish-Subscriber-Modell angestoßen bzw. abgemeldet werden um Netzressourcen zu schonen. Eingriffe in den Ablauf des Automationsprozesses erfolgt wiederum durch einzelne Nachrichten, die an einzelne Rechner oder Rechnergruppen im Netz gerichtet sind Sonstige Anforderungen Aufgrund des Automatisierungskontextes in dem diese Arbeit steht, ergeben sich weitere Anforderungen an die Entwicklung der Kommunikationsschicht, die im Folgenden erläutert werden Entwicklung unter Linux Die Entwicklung unter dem offenen Betriebssystem Linux wird aufgrund der Einbettung der Arbeit in ein Forschungs- und Entwicklungs-Thema des Labors für Verteilte Systeme der FH Wiesbaden vorausgesetzt. Das Thema Real-Time Data Propagation in Distributed Environments sieht eine Netzwerk-Kommunikationsschicht mit QoS-Fähigkeit auf Basis des Linux-QoS-Frameworks vor. 32

49 Kapitel 3. Analyse 3.2. Kommunikationsformen und ihre QoS-Anforderungen Portierbarkeit In der Automation kommt eine Vielzahl von Embedded-PC-Architekturen zum Einsatz. Die Kommunikationsschicht sollte auf den meisten dieser Architekturen lauffähig sein. Dies kann gewährleistet werden, indem die von Linux gebotenen, Hardwareunabhängigen Schnittstellen genutzt werden. Damit würden alle Architekturen, die Linux unterstützt, von der Kommunikationsschicht mit unterstützt werden. Obwohl das Ziel der Arbeit eindeutig auf Ethernet ausgerichtet ist, soll auch eine Portierung der Kommunikationsschicht auf andere Layer-2-Protokolle, wie Firewire oder PPP, so einfach wie möglich sein Modularität Die zu entwickelnde Software soll modular aufgebaut sein. Damit soll eine einfache Portierung und Weiterentwicklung gewährleistet werden Performanz-Optimierung auf Senden und Empfangen Für die Einhaltung von QoS ist ein reibungsloses und schnelles Senden bzw. Empfangen nötig. Daher muss bei der Entwicklung der Software eine Optimierung der Performanz in Bezug auf den Sende- und Empfangsbetrieb vorgenommen werden. 3.2 Kommunikationsformen und ihre QoS-Anforderungen Die in Abschnitt 3.1 vorgestellten Kommunikationsmuster stellen unterschiedliche Anforderungen an die in Kapitel 2.1 definierten QoS-Parameter. In diesem Abschnitt werden diese Anforderungen für die betreffenden Use-Cases erkläutert Steuern und Regeln Mess- und Steuerwerte sind meist kritische Daten, bei deren Verlust der Zustand einer Anlage nicht definierbar ist. Daher stellt die Form der Kommunikation höchste 33

50 3.2. Kommunikationsformen und ihre QoS-Anforderungen Kapitel 3. Analyse Anforderungen an Dienstverfügbarkeit und Paketverlustrate. Die Dienstverfügbarkeit sollte so hoch wie möglich sein, wohingegen die Paketverlustrate bei Null liegen sollte. Um die Aktualität der Daten zu wahren, ist ein sehr geringer Delay notwendig, der in vielen Fällen harten Echtzeitanforderungen standhalten muss. Handelt es sich dabei um Daten mittlerer Priorität, ist auch ein höherer Delay tolerierbar. Da es sich um isochron propagierte Daten handelt, wird ein geringer Jitter angestrebt, damit die Synchronität von Abläufen gewährleistet werden kann. Die Anforderung an den Durchsatz eines isochron propagierten Datenstroms hängt von der Paketgröße und dem Sende-Intervall ab. Jedoch sind diese Anforderungen eindeutig bestimmbar, da die Paketgröße und das Sendeintervall in der Regel bekannt sind Alarm-Signalisierung Für die Alarm-Signalisierung sind die Anforderungen an die Verfügbarkeit höher, als die für Steuern und Regeln. Denn, fällt die Propagation von Mess- und Steuerdaten aus, kann der Schaden durch schnelles Signalisieren eines Alarms noch begrenzt werden, nicht jedoch, wenn gleichzeitig auch der Service für die Alarmsignalisierung ausfällt. Genauso verhält es sich für die Paketverlustrate. Um einen schnellstmöglichen Stop aller Vorgänge zu gewährleisten, muss die geringstmögliche Verzögerung erzielt werden, daher sind die Anforderungen an den Delay sehr hoch. Da es sich bei der Alarm-Signalisierung nur um die Propagation einzelner Pakete handelt, bestehen praktisch keine Anforderungen an Jitter oder Durchsatz Datei-Download / Upload Ein Datei-Download bzw. Upload hat recht geringe Anforderungen an Service-Availability und Paket-Verlust-Rate. Es ist zwar eine hohe Dienstverfügbarkeit erwünscht, jedoch ist diese nicht kritisch für die Stabilität einer Anlage. Noch unkritischer ist die Paket-Verlust-Rate, da verloren gegangene Pakete durch TCP erneut gesendet werden. 34

51 Kapitel 3. Analyse 3.3. Einflussnahme auf die QoS-Parameter Delay und Jitter sind ebenfalls nicht von kritischer Bedeutung für die Übertragung von Dateien. Allein der Durchsatz der Pakete ist von größerer Bedeutung, um Dateien so schnell wie möglich zu übertragen. Dies gilt aber nur in dem Rahmen, in dem die Anforderungen der Kommunikationsmuster höherer Priorität nur geringfügig oder gar nicht beeinflusst werden. Wobei auch hier ein hoher Durchsatz wünschenswert ist, um die Belastung des Netzwerks zeitlich so kurz wie möglich zu halten Human-Machine-Interface Die Überwachung und der Eingriff in den Automationsprozess erfolgen nach allen bisher genannten Kommunikationsformen, jedoch teilweise nach eigenen Prioritäten. Die ausschließlich zur Visualisierung benötigten Messdaten werden, wie Daten zum Steuern und Regeln, isochron propagiert, jedoch in größeren Intervallen und mit geringerer Priorität. Desweiteren ist deren Toleranz gegenüber Delay, Jitter und Paket-Verlust weitaus größer. Eingriffe in den Prozessablauf und Statusabfragen gleichen im Ablauf der Kommunikationsform der Alarmsignalisierung. Die Anforderungen an Delay und Paket-Verlust hängen stark von der Art der Nachrichten und deren Priorität ab. Eine einfache Abfrage von Messdaten ist von weit geringerer Priorität, als ein vom HMI ausgelöstes Alarmsignal. Die Änderung einer Stellgröße liegt in einem Bereich dazwischen. Vom HMI ausgelöste Datei-Up- und Downloads haben genau die Anforderungen, die für diesen Anwendungsfall definiert wurden. 3.3 Einflussnahme auf die QoS-Parameter Um die einzelnen QoS-Parameter zu beeinflussen, und damit geforderte Grenzen einhalten zu können, müssen zunächst deren Abhängigkeiten analysiert werden. Für die Betrachtungen einzelner Parameter wird auf die, in [Jas02] verwandten, analytischen Methoden zurückgegriffen, die aud [BT04] basieren. Diese beschreiben das Worst-Case-Verhalten eines Netzwerkelements anhand einer Ankunftskurve und einer Servicekurve. Alle hier verwendeten Betrachtungen gehen von einer konstanten Paketgröße aus. 35

52 3.3. Einflussnahme auf die QoS-Parameter Kapitel 3. Analyse Die Ankunftskurve α(t) eines Elements, wie z.b. einer QDisc, ist eine stetig steigende Funktion, die die eintreffenden Daten über die Zeit charakterisiert. Sie begrenzt den Datenfluss R nach oben, wenn für alle Zeitpunkte u t gilt: R(t) R(u) α(t u) (3.1) Eine einfache Möglichkeit die Ankunftskurve zu beschreiben, ist der Token-Bucket, der durch die Parameter b für die Bucketgröße und r für die Abflussrate beschrieben werden kann. Es wird bei der Verwendung der Ankunftskurve davon ausgegangen, dass alle Daten eines Bursts gleichzeitig in der Queue eintreffen. α r,b (t) = r t + b (3.2) Der Parameter Bucketgröße gibt dabei die Größe von Bursts, bei angesammelten Token, in [Bytes] oder [Paketen], an. Die maximale Ankunftsrate entspricht der Abflussrate des Token-Buckets in [Bytes/s] oder [Pakete/s]. Die Servicekurve β(t) beschreibt, wann ein Paket in einem Element bedient wird. Sie wird in den meisten Fällen in Form der rate latency function dargestellt. β R,T (t) = R[t T ] + = { R(t T ) wenn t > T 0 wenn t T (3.3) R beschreibt die Rate in der Daten, die sich im System befinden abgearbeitet werden, in [Bytes/s] oder [Pakete/s]. Der Parameter T stellt die maximale Latenz [s] des Systems dar, bevor die ersten Daten abgearbeitet werden können. Ankunfts- und Servicekurve werden anhand eines Beispiels in Abbildung 3.2 erklärt. Das Beispielsystem stellt eine Queue mit FIFO-Charakteristik dar. Die Ankunftskurve wird durch einen Tokenbucket begrenzt, dessen Parameter b die maximale Paketgröße L max zugewiesen wird. Diese wird mit der Länge eines maximal großen Frames, inklusive Präambel, Header, Frame-Check-Sequence und Inter-Frame-Gap, angenommen und entspricht damit b = L max = 1538Byte. Präambel, Frame-Check-Sequence und Inter-Frame-Gap werden zwar erst in der Hardware hinzugefügt [WPR + 02], jedoch ist die Bedienungszeit der Pakete von deren Größe abhängig. Um den maximalen, belegten Speicher in der Queue zu berechnen, sind Präambel, Frame-Check-Sequence und Inter-Frame-Gap wieder abzuziehen. Die Ankunftsrate r wird mit 25M Bit/s angenommen. 36

53 Kapitel 3. Analyse 3.3. Einflussnahme auf die QoS-Parameter Abbildung 3.2: Service- und Ankunftskurve Der Parameter R der Servicekurve entspricht der Linkkapaziät des Netzwerk-Devices C = 100M Bit/s. Die Latenz T ist abhängig davon, wie schnell ein Paket über die Queue durchgereicht werden kann. Angenommen das Durchlaufen der Queue würde 1000 Instruktionen in Anspruch nehmen, dann würde die Queue auf einem Prozessor mit 1GHz Taktfrequenz und einer Instruktion pro Takt eine Latenz von 1µs aufweisen. Mit diesen Parametern lassen sich nun die folgenden Werte berechnen: die maximale Verweilzeit eines Pakets in der Queue. den maximal genutzten Speicher der in der Queue gehaltenen Pakete Die Formel für die maximale Verweilzeit d max in der Queue lautet: d max = T + b R (3.4) Der maximal belegte Speicher B max berechnet sich mit: 37

54 3.3. Einflussnahme auf die QoS-Parameter Kapitel 3. Analyse B max = α(t ) = r T + b 1 (3.5) Das Ergebnis muss auf das nächste n-fache der Paketgröße aufgerechnet werden. Durch Einsetzen ergeben sich folgende Werte: d max = 124, 04µs B max = 3028Byte Service Availability Die Dienstverfügbarkeit ist stark abhängig von der Stabilität aller beteiligten Elemente. Es darf zu keinen Hardwareausfällen kommen. Die Software muss sorgfältig programmiert sein, unter den Gesichtspunkten, dass Deadlock-Situationen um jeden Preis zu verhindern sind. Um die Dienstverfügbarkeit zu erhöhen, sind redundante Lösungen denkbar. Diese sind jedoch nicht Schwerpunkt dieser Arbeit und sollen daher nicht weiter betrachtet werden Packet Loss Rate Pakete können aus zwei Gründen verloren gehen. Zum einen kann es bei der Übertragung eines Pakets zu Fehlern durch Störeinflüsse von außen kommen, wodurch das Paket beim Empfang verworfen wird. Dem kann man durch Einsatz störungsarmer Hardware, wie z.b. Kategorie 5 Kabel, entgegenwirken. Die zweite Ursache ist das Überlaufen eines Puffers in einem Switch oder Host. In einem Host kommt das nicht vor, solange der empfangende Prozess die Pakete schnell genug abholt. In einem Switch werden Pakete mit einer höheren Wahrscheinlichkeit verworfen. Treffen an zwei Ports eine Serie von Pakete mit dem gleichen Zielport ein, und deren addierte Ankunftskurven liegen höher als die Servicekurve des Zielports, beginnt sich die Ausgangsqueue des Ports mit Verweisen auf die gespeicherten Pakete zu füllen. Geschieht das über einen längeren Zeitraum, so kann die Queue des Ports 1 b entspricht hier der maximalen Paketgröße inklusive Header, aber ohne Präambel, CRC und IFG: 1514Byte 38

55 Kapitel 3. Analyse 3.3. Einflussnahme auf die QoS-Parameter überlaufen. Daraufhin werden alle weiteren Pakete verworfen, bis wieder Platz zur Aufnahme eines Zeigers zur Verfügung steht. Um das zu verhindern, muss für die Menge aller Ports P gelten [Jas02]: r i < R j (3.6) i j P Bedingt durch die niedrige Ankunftsrate, können weiter auftretende Bursts abgebaut werden können Delay Die Garantie zur Einhaltung dieser Grenzen ist von verschiedenen Faktoren abhängig. Grob setzt sich der Delay aus drei Teilen zusammen: Delay im Sendeknoten, auf dem Medium und im Empfängerknoten. Im Folgenden sollen alle Teile genauer betrachtet werden Delay im Sendeknoten Hier sind wiederum einzelne Elemente für unterschiedliche, variable und konstante Anteile an der Gesamtlatenz beteiligt. Zum einen ist der Delay im Systemcall zu betrachten, mit dem die zu versendenden Daten an das Betriebssystem übergeben werden. Linux-Systemcalls der Socket-Schnittstelle haben grundsätzlich eine vorhersehbare Bearbeitungszeit, die von der Schnelligkeit der CPU abhängt. Da sie jedoch von einem Aktivitätsträger im Kern unterbrochen werden können, ist der dadurch verursachte Delay nicht deterministisch. Das ist im Falle von Soft- und Hardware- Interrupts recht unkritisch, da diese in der Regel nur aus ein paar Anweisungen bestehen, nach deren Abarbeitung der Systsemcall weiter ausgeführt werden kann. Problematisch kann es jedoch bei sogenannten Bottom-Halfs und Tasklets werden. Dabei handelt es sich um asynchron auftretende Aktivitätsträger im Kern, die dazu ausgelegt sind auch Tasks, die mehrere tausend Taktzyklen in Anspruch zu nehmen. Diese können nur von Interrupts unterbrochen werden, sind jedoch dazu in der Lage Systemcalls zu unterbrechen. Das Problem könnte durch die Verwendung einer Echtzeiterweiterung umgangen werden. Für weitere Informationen zu Tasklets und Bottom-Halfs sei [BC02] empfohlen. 39

56 3.3. Einflussnahme auf die QoS-Parameter Kapitel 3. Analyse Das nächste Element, das den Delay beeinflusst, ist der Protokoll-Stack. Um diesen Teil-Delay gering zu halten, besteht der Stack in der Automation nur aus Layer 1, 2 und 7. Daten, die nicht den Echtzeitanforderungen unterliegen und der vertikalen Integration dienen, sollten die restlichen Layer weiterhin nutzen können. Einen nicht unerheblichen Einfluss auf den Delay hat die verwendete Queueing Disziplin. Der Delay innerhalb der Queueing Disziplin sich lässt mit dem Ankunftsbzw. Servicekurven-Modell ermitteln, wenn folgende Rahmenbedingungen erfüllt sind [Jas02]: Der Ankunftsprozess muss für jede Verbindung, d.h. sendende Quelle auf einer Station, charakterisiert werden können. Dies kann, wie oben erläutert, durch den Einsatz eines Token Buckets erreicht werden. Dieser sollte nach erwarteter Senderate und Paketgröße der Quelle dimensioniert werden, um eine obere Grenze durchzusetzen. Überschreitet der Prozess diese Grenze, wird er mit einem erhöhten Delay durch den Token Bucket bestraft, nicht jedoch die restlichen Quellen. Die maximale Paketgröße muss bestimmbar sein. Dies ist wichtig, da der Worst-Case-Delay stark abhängig von der Paketgröße ist. Diese bestimmt in Abhängigkeit mit der Linkkapazität, die Zeit, die es braucht um ein Paket auf das Medium zu senden. Wird die Paketgröße klein gehalten, verkürzt sich der Delay. In der Automation werden in der Regel kleine Pakete verschickt, die Sensordaten enthalten. Durch die vertikale Integration von Netzwerkkommunikation aus dem Office-Bereich auf dem gleichen Netzwerksegment, besteht die Gefahr, dass diese Pakete den Worst-Case-Delay alleine durch ihre Größe drastisch anheben. Dem kann durch ein Verkleinern der Maximum Transmission Unit (MTU) am Netzwerktreiber entgegengewirkt werden. Die verwendeten Paket Scheduling Algorithmen müssen bekannt sein. Durch das Wissen über die Algorithmen kann deren Verhalten durch das Ankunfts-/Servicekurven-Modell berechnet werden. Dies ist durch die Queueing Disziplinen unter Linux gewährleistet. Verwendet man die Prio Queueing Disziplin, so lassen sich nach den oben genannten Bedingungen Aussagen über den Worst-Case-Delay innerhalb der QDisc treffen. Hierzu sind einige Definitionen nötig: 40

57 Kapitel 3. Analyse 3.3. Einflussnahme auf die QoS-Parameter Für L max wird ein Wert zwischen 84 und 1538Byte angenommen. In diesem Rahmen bewegt sich die Größe eines validen Ethernet-Frames, wie er auf dem physischen Medium gesendet wird. Die Prio QDisc besteht aus n Bändern, mit den aufsteigenden Prioritäten i [0; n 1], wobei 0 die niedrigste Priorität darstellt. Für jedes Band der Priorität i der Prio-QDisc existieren m i Quellen, für die gelten m i N. Jede Quelle j wird durch einen eigenen Token-Bucket begrenzt, dessen Burst- Parameter b j auf die maximale Paketgröße P max festgelegt wird. Der Parameter r j ist für jede Quelle unterschiedlich. Zum Ermitteln der Ankunftskurve α i des Bandes i werden die Token-Bucket-Parameter jeder Quelle addiert. b i = j m i b j = m i P max (3.7) r i = j m i r j (3.8) α i (t) = r i t + b i (3.9) Um Stausituationen zu vermeiden, dürfen die addierten Ankunftsraten der Bänder mit der Priorität i > 0 nicht die Linkkapazität C übersteigen. Daher gilt: n 1 i=1 j m i r j < C (3.10) Betrachtet man nun das Band mit der höchsten Priorität, so gelten die Bedingungen einer Queue mit FIFO-Charakteristik, wie sie oben schon betrachtet wurde. Da ein Paket der höchsten Priorität immer gegenüber den Paketen niedriger Priorität bevorzugt wird, kann es nur von einem gerade gesendeten Paket oder von Paketen gleicher Priorität, die vor ihm eingetroffen sind, verzögert werden. Daher gilt für das Band mit der höchsten Priorität die Formel 3.4. Für alle Bänder niedrigerer Priorität gilt, dass die Ankunftskurven der höherprioren Bänder zur eigenen hinzu addiert wird. Also gilt für alle Bänder: 41

58 3.3. Einflussnahme auf die QoS-Parameter Kapitel 3. Analyse d maxi = T + n 1 j=i b j R (3.11) Diese Formel lässt die konstanten Verzögerungen außer Acht, die durch die Ausführung des Codes im Betriebssystem verursacht werden. Diese muss durch Zeitmessungen im Kernel ermittelt werden. Der Delay durch den Treiber nimmt nur einen sehr geringen Teil ein, da Treiber dazu ausgelegt sind, die Daten schnellstmöglich an die Hardware zu übergeben. Daher ist die Wahrscheinlichkeit einer Unterbrechung sehr gering. Der Delay in der Hardware entsteht sowohl durch Hinzufügen von Präambel, SFD und Frame-Check-Sequence, als auch durch die Zeit, die benötigt wird ein Paket auf das Medium zu legen. Die Zeit um die Daten auf das Medium zu senden wird durch seine Linkkapazität gegeben. Ein Fast-Ethernet-Interface (100MBit) sendet 12,5Byte/µs, was heißt, dass ein 1538Byte großes Paket in µs versendet wird Delay auf dem Medium Der Delay auf dem Medium ist abhängig von sowohl der Signallaufzeit, und somit der Länge der verwendeten Kabel, als auch der Anzahl und Verzögerung in den Netzwerkvermittlungselementen. Die Signallaufzeit in einem UTP-Kabel der Kategorie 5 beträgt V = m/µs [Hal96]. Dadurch ergibt sich folgende Formel für die Verzögerung T p [µs]: T p = S[m] V [m/µs] (3.12) Zur Signallaufzeit addiert sich der Delay, der in den Netzwerkvermittlungselementen auftritt. Da sich der Umfang dieser Arbeit auf die Betrachtung von Ethernet beschränkt, kommen hier nur zwei Typen dieser Elemente in Frage: Hubs und Switches. Hubs sind keine Vermittlungselemente im eigentlichen Sinne, da sie das empfangene Signal nur verstärken und auf allen Ports weiterleiten. Sie werden jedoch erwähnt, da ihr Einsatz eine weitere Verzögerungszeit hinzu addiert. Der Standart IEEE [IEE02] definiert zwei Klassen von Repeatern mit einer 100MBit Rate, die sich durch unterschiedliche Verzögerungszeiten auszeichnen. Bei der Nutzung eines schnelleren Klasse II Hub gilt: Delay 3.68µs. 42

59 Kapitel 3. Analyse 3.3. Einflussnahme auf die QoS-Parameter Der Delay eines Switches setzt sich wiederum aus zwei Zeiten zusammen. Zum einen die Zeit, die ein Switch benötigt, um ein Paket zu vermitteln, ohne dass Queueing- Effekte eintreten. Diese Zeit ist vom jeweiligen Switch abhängig. Kommt es zum Queueing, kann je nach verwendeten Paket Scheduling Algorithmus entweder die Formel 3.4 oder 3.11 zur Anwendung kommen Delay im Empfangsknoten Im Empfangsknoten kommen wieder die Verzögerungen in Hardware, Treiber und Systemcall zum Tragen, mit den jeweiligen Abhängigkeiten. Paket Scheduling Algorithmen werden hier nicht verwendet Jitter Der Jitter wird durch die variablen Aspekte im Delay bestimmt. Er entsteht bereits durch den sendenden Prozess, der niemals hundertprozentig isochron senden kann. Dies kann durch den Einsatz eines entsprechenden Prozess-Schedulers und fein-granularer Timer im Betriebssystem minimiert werden. Einen großen Einfluss auf den Jitter hat der Protokoll-Stack. Daher wird er, wie schon erwähnt, auf Layer 1, 2 und 7 reduziert. Die in Linux implementierten Paket Scheduling Algorithmen können nur zum Eingrenzen von maximalem Delay eingesetzt werden. Pakete werden trotzdem weiterhin zu den frühest möglichen Zeitpunkt gesendet. Daher bewegt sich der Jitter zwischen dem Best- und dem Worst-Case-Delay. Wird dennoch ein geringer Jitter benötigt, um z.b. für die Visualisierung eine konstante Bildwiederholrate zu erzielen, können die Daten am Empfänger gepuffert werden, um dann mit geringem Jitter ausgelesen zu werden. Dies führt jedoch zu einem Anstieg im Delay, was in dem Fall der Visualisierung durchaus akzeptabel wäre Throughput Der Durchsatz eines Datenstroms ist abhängig davon, wieviel Bandbreite von anderen Datenströmen verbraucht wird, und ist nach oben begrenzt durch die Linkkapazität des Netzwerk-Device. Um den Durchsatz eines Datenstroms zu sicheren müssen die der restlichen Datenströme begrenzt werden. 43

60 3.4. API der Linux-Queueing-Disziplinen Kapitel 3. Analyse 3.4 Application Programming Interface der Linux- Queueing-Disziplinen In diesem Abschnitt soll beschrieben werden, wie aus Sicht einer Applikation, die unter Linux zur Verfügung stehenden Queueing Disziplinen konfiguriert werden können. Es werden die für diese Arbeit benötigten QDiscs vorgestellt und deren Parameter erläutert. Die Informationen über diese Schnittstellen sind zum größten Teil aus der Analyse der Linux-Kernel Quellen und der Quellen des Programms TC aus dem Paket iproute2 gewonnen worden Kommunikation über Netlink-Sockets Zur Konfiguration aus einer Applikation heraus stellt der Kernel Netlink-Sockets bereit [WPR + 02]. Diese sind das Kommunikationsmittel, mit dem man vom User- Space aus mit dem Kernel in einen Dialog treten kann. Die dafür erforderlichen Header-Dateien sind in Listing 3.1 dargestellt. Quelltext 3.1: Erforderliche Header Dateien für Netlink-Kommunikation # include <sys / types.h> # include <sys / socket.h> # include <asm / types > # include <linux / netlink.h> # include <linux / rtnetlink.h> Geöffnet werden Netlink-Sockets mit dem Systemcall socket(), dessen genaue Beschreibung der entsprechenden Manpage zu entnehmen ist. Als domain-parameter ist PF_NETLINK zu wählen, sowie für den type-parameter SOCK_DGRAM oder SOCK_RAW. In netlink.h sind verschiedene Protokolle definiert, die jeweils eine Schnittstelle zu einem anderen Subsystem im Kernel repräsentieren. So bildet NETLINK_ROUTE die Schnittstelle zu Routing und Netzwerk, NETLINK_FIREWALL zur Firewall und NETLINK_ARPD zur ARP-Tabelle. Zum Manipulieren der Queueing-Disziplinen muss als protocol-parameter NETLINK_ROUTE eingetragen werden, dessen Definition in rtnetlink.h enthalten ist. Um mit dem Kernel zu kommunizieren, werden über die Systemcalls sendmsg() und recvmsg() Netlink-Messages ausgetauscht. Zum Transport der Netlink-Messages werden diese in die Struktur struct msghdr eingebettet, die im Folgenden erklärt wird (Listing 3.2). 44

61 Kapitel 3. Analyse 3.4. API der Linux-Queueing-Disziplinen 1 struct msghdr { 2 void * msg_name ; 3 socklen_t msg_namelen ; 4 struct iovec * msg_iov ; 5 size_t msg_iovlen ; 6 void * msg_control ; 7 socklen_t msg_controllen ; 8 int msg_flags ; 9 }; Quelltext 3.2: Die msghdr Struktur Im Zeiger msg_name wird die Speicheradresse eines Adressierungsobjekts gespeichert, dessen Größe in msg_namelen übergeben wird. Auf den Aufbau dieses Adressierungsobjekts wird in Abschnitt eingegangen. Der Daten-Member msg_iov ist ein Zeiger auf einen Vektor von iovec-strukturen. Eine Struktur nimmt die Basisadresse und Größe des Adressbereichs auf, in dem sich die zu versendende Message befindet. In msg_iovlen wird die Anzahl der zu versendenden Messages angegeben und nicht die Bytes, die der Zeiger einnimmt. Listing 3.3 zeigt den Aufbau von struct iovec. Quelltext 3.3: Die iovec Struktur 1 struct iovec { 2 void * iov_base ; 3 size_t iov_len ; 4 }; msg_control, msg_controllen und msg_flags können genutzt werden, um optionale, Protokoll-spezifische Informationen zu übergeben. Für die Nutzung von Netlink- Messages werden sie nicht benötigt Addressierung der Netlink-Messages Da die Kommunikation über Netlink-Sockets zwischen User-Prozessen und dem Kernel erfolgt, werden zur Addressierung die Prozess IDs genutzt. Zu diesem Zweck ist in netlink.h die Struktur struct sockaddr_nl definiert, die in Listing 3.4 gezeigt wird. Quelltext 3.4: Die sockaddr_nl Struktur 1 struct sockaddr_nl { 2 sa_family_t nl_family ; 3 unsigned short nl_pad ; 4 u32 nl_pid ; 5 u32 nl_group ; 6 }; 45

62 3.4. API der Linux-Queueing-Disziplinen Kapitel 3. Analyse Als nl_family wird immer AF_NETLINK übergeben. nl_pad füllt die Lücke zwischen nl_family und nl_pid bis zur nächsten 4-Byte- Grenze auf. In nl_pid wird die Prozess ID des Empfängerprozesses übergeben. Da von User-Seite aus der Kernel der Empfänger ist, wird das Feld auf Null gesetzt 2. Es ist prinzipiell möglich in nl_group eine Multicast-Gruppenmaske zu übergeben und so mehrere Prozesse zu adressieren. Wie dies genau funktioniert, war im Laufe dieser Arbeit nicht in Erfahrung zu bringen Aufbau der Netlink-Messages Der grundsätzliche Aufbau einer Netlink-Message wird in Abbildung 3.3 gezeigt und anhand des Listings 3.5 erläutert. Abbildung 3.3: Netlink-Message In netlink.h ist die Struktur struct nlmsghdr (Listing 3.5) definiert, die die Daten des Headers aufnimmt. Quelltext 3.5: Die nlmsghdr Struktur 1 struct nlmsghdr { 2 u32 nlmsg_len ; 3 u16 nlmsg_type ; 4 u16 nlmsg_flags ; 5 u32 nlmsg_seq ; 6 u32 nlmsg_pid ; 7 }; Das nlmsg_len Feld hält die Länge der Message inklusive Header und Attribute in Bytes. In nlmsg_type (Zeile 2) wird das Kommando eingetragen, das von dem Kernelsubsystem ausgeführt werden soll. Die zur Verfügung stehenden Kommandos sind vom genutzten Netlink-Protokoll abhängig. Das NETLINK_ROUTE Protokoll enthält einen 2 Die PID des Kernel ist 0 46

63 Kapitel 3. Analyse 3.4. API der Linux-Queueing-Disziplinen Satz von 27 Befehlen, von denen jedoch nur neun für die Konfiguration von QDiscs relevant sind. Diese werden in Tabelle 3.1 zusammengefasst. RTNetlink-Messagetyp Bedeutung RTM_NEWQDISC Neue QDisc anlegen RTM_DELQDISC QDisc löschen RTM_GETQDISC QDisc-Parameter anfordern RTM_NEWTCLASS Neue Klasse anlegen RTM_DELTCLASS Klasse löschen RTM_GETTCLASS Klassenparameter anfordern RTM_NEWTFILTER Neuen Filter anlegen RTM_DELTFILTER Filter löschen RTM_GETTFILTER Filterparameter anfordern Tabelle 3.1: RTNetlink-Kommandos Die in nlmsg_flags (Zeile 3) einzutragenden Flags verfeinern die Kommandos in Tabelle 3.1. Die zur Verfügung stehenden Flags sind in netlink.h definiert und werden in Tabelle 3.3 zusammengefasst. Message-Typ Flag Bedeutung NEW-Messages NLM_F_CREATE Element wird erstellt, falls es noch nicht existiert NLM_F_EXCL Element wird nicht erstellt, wenn es schon existiert NLM_F_REPLACE Überschreibe existierendes Element NLM_F_APPEND Hänge Element an das Ende der Liste (Keine Angabe des Handles) DEL-Messages - - Tabelle 3.2: Flags für Netlink-Messages In nlmsg_seq wird die Sequenznummer der Message in der Kommunikation zwischen Kernel und User-Space-Applikation festgehalten. Im Feld nlmsg_pid wird die Prozess ID des sendenden Prozesses eingetragen. Diese 47

64 3.4. API der Linux-Queueing-Disziplinen Kapitel 3. Analyse dient als Quelladresse, da im Addressierungsobjekt selbst keine solche vorgesehen ist. Message-Typ Flag Bedeutung GET-Messages NLM_F_ROOT Spezifiziere die Wurzel des Elementbaums NLM_F_MATCH Liefere alle passenden Elemente zurück NLM_F_ATOMIC Befehl ist nicht unterbrechbar NLM_F_DUMP (NLM_F_ROOT NLM_F_MATCH) Alle Messages NLM_F_REQUEST Es handelt sich um eine Request-Message NLM_F_MULTI Multipart-Message Wird durch NLMSG_DONE terminiert NLM_F_ACK Message-Quittierung Kann Error-Codes enthalten NLM_F_ECHO Echo-Message zu Überprüfung der Kommunikation Tabelle 3.3: Flags für Netlink-Messages (forts.) Traffic-Control-Messages Eine Traffic-Control-Message (Abbildung 3.4) mit angehängten Attributen wird als Payload der Netlink-Message verschickt. Zur Bildung der Traffic-Control-Message ist in rtnetlink.h die Struktur struct tcmsg (Listing 3.6) definiert. Abbildung 3.4: Traffic-Control-Message 48

65 Kapitel 3. Analyse 3.4. API der Linux-Queueing-Disziplinen 1 struct tcmsg { 2 unsigned char tcm_family ; 3 unsigned char tcm_pad1 ; 4 unsigned short tcm_pad2 ; 5 int tcm_ifindex ; 6 u32 tcm_handle ; 7 u32 tcm_parent ; 8 u32 tcm_info ; 9 }; Quelltext 3.6: Die tcmsg Struktur Das Feld wird tcm_family (Zeile 2) laut der Definition in rtnetlink.h stets mit dem Wert AF_UNSPEC belegt. Die beiden Padding-Felder tcm_pad1 (Zeile 3) und tcm_pad2 (Zeile 4) werden auf den Wert Null gesetzt. Sie dienen dazu, das tcm_ifindex-feld auf die nächste 4-Byte- Grenze zu schieben. Im Feld tcm_ifindex (Zeile 4) wird der Index-Wert des betreffenden Netzwerk- Devices übergeben. Es handelt sich dabei nicht um den Namen des Devices, sondern dessen interne Identifizierungsnummer. Um den Index eines Netzwerk-Devices zu ermitteln, wird der Systemcall ioctl() mit SIOCGIFINDEX als request-parameter genutzt. Zu näheren Informationen sei auf die Manpage netdevice(7) verwiesen. Das Handle des jeweiligen Traffic-Control-Elements wird in tcm_handle (Zeile 5) gespeichert. Wird als Handle Null angegeben, so wird dem Element ein Handle vom Kernel zugewiesen. In tcm_parent wird das Handle des Elternelements angegeben. Handelt es sich bei dem zu konfigurierenden Element um die Root-QDisc, so ist als Elternelement entweder TC_H_ROOT oder TC_H_INGRESS anzugeben. Die Verwendung des tcm_info-feldes (Zeile 6) ist abhängig vom verwendeten Message- Typ, und ob es sich bei dem Ziel um eine QDisc, Klasse oder einen Filter handelt. Wird mit RTM_GETQDISC oder RTM_GETTCLASS der Status einer Queueing Disziplin oder Klasse abgefragt, nutzt der Kernel das Feld zur Übermittlung eines Teils der Statusinformationen. Welche das im einzelnen sind wurde in diese Arbeit nicht ermittelt. Bei der Konfiguration von Filtern wird in den oberen 16 Bit des tcm_info-feldes die Priorität des Filters und in den unteren 16-Bit das Protokoll, das gefiltert werden soll, an den Kernel übergeben. Darauf wird im Abschnitt eingegangen. Die Attribute die der jeweiligen Message angehängt werden, sind vom verwendeten Element abhängig. Grundsätzlich ist in einem TCA_KIND-Attribut die Bezeichnung des Elements als String zu übergeben. In linux/pkt_sched.h sind für alle QDiscs 49

66 3.4. API der Linux-Queueing-Disziplinen Kapitel 3. Analyse Strukturen definiert, die in den meisten Fällen im Attribut TCA_OPTIONS an den Kernel übergeben werden. Alle Attribute, die zur Konfiguration eines Elements notwendig sind, werden in Abschnitt bzw im Einzelnen erklärt. Der Aufbau eines Attributes ist in Abbildung 3.5 dargestellt. In rtnetlink.h sind Makros zur Erstellung und Bearbeitung von Attributen definiert. Abbildung 3.5: Attribute einer Traffic-Control-Message Verfügbare Queueing Disziplinen Unter Linux-Kernel 2.6 existieren 13 verschiedene Queueing Disziplinen, von denen acht klassenlos und fünf klassenbehaftet sind. Die meisten lassen sich für die Zwecke dieser Arbeit nicht verwenden, da sie entweder den Anforderungen von Automatisierungskommunikation zuwiderlaufen oder für die Arbeit auf höheren Protokollschichten ausgelegt sind. So verwirft Random Early Detection zufällig gewählte Pakete, um den Durchsatz fair über alle Verbindungen hinweg zu drosseln, und DSMark, der vollwertigen Implementierung von DiffServ, ist auf das DS-Feld im IP-Header angewiesen. Im Folgenden sollen die für diese Arbeit relevanten Queueing Disziplinen erläutert werden. Die in den Überschriften, in Klammern, angegebenen Namen entsprechen den Namen der jeweiligen QDisc, mit dem sie in dem TCA_KIND-Attribut an den Kernel übergeben werden müssen First-In-First-Out (bfifo, pfifo, pfifo fast) Bei diesen Queueing Disziplinen handelt es sich um verschiedene Implementierungen des FIFO-Algorithmus. Der einzige Unterschied zwischen bfifo und pfifo besteht darin, dass die Größe der Queue bei bfifo Byte und bei pfifo in Paketen berechnet wird. Die pfifo fast-qdisc stellt einen Spezialfall dar. Sie besteht eigentlich aus drei FIFO-Queues, die nach den Strict-Priority-Algorithmus abgearbeitet werden. Die Zuordnung der Pakete, zu den Queues richtet sich nach dem DS-Feld im IP-Header. 50

67 Kapitel 3. Analyse 3.4. API der Linux-Queueing-Disziplinen pfifo fast ist die Default-QDisc für alle Netzwerk-Devices und Blattklassen einer QDisc, wenn für diese keine QDisc explizit konfiguriert wurde. Der einzige Parameter dieser QDiscs ist die Größe der Queue in Byte für bfifo und in Paketen für pfifo und pfifo fast. Er kann nur indirekt mit dem Befehl ifconfig <device> txqueuelen <len> konfiguriert werden. Bei einem Überfüllen der Queue, werden alle nachkommenden Pakete verworfen, bis wieder ein Platz für ein weiteres Paket frei ist. Die anderen beiden Varianten lassen sich hingegen über die Netlink-Messages konfigurieren. Die Struktur struct tc_fifo_qopt enthält den Parameter limit mit dem die Größe der Queue, je nach Variante, in Bytes oder in Paketen übergeben wird. Die Struktur wird im Attribut TCA_OPTIONS an die Netlink-Message angefügt Stochastical Fair Queueing (sfq) Die Stochastical Fair Queue verhält sich wie ein Round Robin Algorithmus, indem sie die zur Verfügung stehende Bandbreite unter allen Verbindungen (Flows) aufteilt und sie auf mehrere interne Queues verteilt. Eine Verbindung wird durch eine TCP/UDP-Port Nummer klassifiziert, dies macht die QDisc zwar für die Automationsspeziefischen Zwecke ungeeignet, sie ist jedoch gut einsetzbar um den Best-Effort- Verkehr auf den höheren Protokoll-Ebenen fair zu halten. Die SFQ besitzt eine Reihe von Parametern, mit der sie beeinflusst werden kann. Diese sind in der Struktur tc_sfq_qopt (Listing 3.7) zusammengefasst. Quelltext 3.7: Die tc_sfq_qopt Struktur 1 struct tc_sfq_qopt { 2 unsigned quantum ; 3 int perturb_period ; 4 u32 limit ; 5 unsigned divisor ; 6 unsigned flows ; 7 }; Der Parameter quantum legt die Anzahl Bytes fest, die ein Flow senden darf, bevor der nächste an der Reihe ist. Da insgesamt verschiedene Port-Nummern existieren, ist es nicht optimal für jeden Flow eine eigene Queue zu verwalten. Deshalb wird nur eine begrenzte Anzahl Queues angelegt, auf die dann alle Flows verteilt werden. Treten mehr Flows auf, als Queues vorhanden sind, werden sie doppelt belegt. Um eine statistische Fairness zu ermöglichen, werden die Flows nach einer Zeit umsortiert. In welchen 51

68 3.4. API der Linux-Queueing-Disziplinen Kapitel 3. Analyse Sekundenintervallen das geschehen soll, wird im Paramter perturb_period festgelegt. Wird der Parameter nicht gesetzt, findet keine Umsortierung statt. Die letzten drei Parameter sind zur Zeit dieser Arbeit fest in den Code der QDisc einkompiliert und können nicht beeinflusst werden. limit legt die Queue-Größe und flows die Anzahl der Queues fest. Bei divisor handelt sich um einen Hash-Divisor Prio (prio) Die Prio-QDisc ist die Implementierung des Strict Priority Algorithmus. Sie besteht aus einer Reihe von Klassen, die je eine Prioritätsstufe darstellen. Dabei stellt, im Gegensatz zur Wertigkeit des User-Priority-Feldes im VLAN-Tag, der Wert 0 die höchste Priorität dar. Um eine Prio-QDisc zu konfigurieren, wird die tc_prio_qopt-struktur im TCA_OPTIONS -Attribut an die Netlink-Message angehängt. Quelltext 3.8: Die tc_prio_qopt Struktur 1 struct tc_prio_qopt { 2 int bands ; 3 u8 priomap [ TC_PRIO_MAX +1]; 4 }; Im Parameter bands wird die Anzahl der Klassen angegeben, die die QDisc enthalten soll. Diese werden beim Erzeugen der QDisc automatisch mit erschaffen, und erhalten ein Handle mit einer Minor-Nummer entsprechend der Priorität, inkrementiert um eins. Bis zu 16 Klassen können auf diese Weise erzeugt werden, jedoch können keine Klassen nachträglich erzeugt werden. Sind keine Filter für die QDisc konfiguriert, so werden Pakete über ein Prioritäts- Mapping klassifiziert, bei dem die Socket-Priorität auf die entsprechende Klasse abgebildet wird. Diese Map wird über den Parameter priomap übergeben. Dieser besteht aus einem Array von 16 Werten, bei der die Einzelnen Positionen der Socket- Prioritäten entspricht. Als Werte werden an den Positionen die Prioritäten der Klassen eingetragen Hierarchical Token Bucket (htb) Der Hierarchical Token Bucket(HTB) stellt eine klassenbehaftete Implementierung des Token Bucket Flow Algorithmus dar. Nicht der QDisc selbst, sondern ihren 52

69 Kapitel 3. Analyse 3.4. API der Linux-Queueing-Disziplinen Klassen werden Burst- und Rate-Parameter zugewiesen. Die Klassen können in beliebigen Baumstrukturen angeordnet werden, wobei die Parameter der Kindklassen nicht die der Elternklassen übersteigen dürfen. Hat eine Elternklasse mehr Bandbreite zur Verfügung, als die Kindklassen verbrauchen, so kann die Bandbreite auf die Kindklassen verteilt werden, solange diese unter einem maximalen Grenzwert bleiben. Die Verteilung der Bandbreite an die Kindklassen erfolgt als Sendezeit, gemessen in der internen Einheit Ticks. Die folgenden Informationen zur Umrechnung von Microsekunden nach Ticks und zurück, stammt aus einer -Korrespondenz mit Stephen Hemminger, einem Mit-Autor der iproute2-utilities. In der Datei /proc/- net/psched sind zwei Variablen eingetragen, t2us und us2t, die als hexadezimale Werte ausgelesen werden können. Der erste Wert in der Datei entspricht der Variablen t2us und der zweite der Variablen us2t. Welche Bedeutung die beiden anderen Werte haben, konnte nicht ermittelt werden. Möchte man die Ticks pro Microsekunde ausrechnen, dividiert man t2us durch us2t. Um die benötigten Ticks für eine bestimmte Paketgröße zu ermitteln, verwaltet jede Klasse intern zwei Rate-Tabellen mit je 256 Einträgen, die die Anzahl der von einem Paket verbrauchten Token auf die benötigten Ticks abbilden. Die Tabelle rtab gilt dabei für die konfigurierte Mindestrate und die Tabelle ctab für die Maximalrate, die nicht überschritten werden darf, unabhängig davon, wieviel Bandbreite der Elternklasse noch zur Verfügung steht. Da die Tabellen nur 256 Einträge enthalten, nimmt ein maximal großes Paket 256 Token ein. Um die Größe eines Tokens zu ermitteln teilt man die maximale Paketgröße [Byte] durch 256 und rundet zu nächsten 2er Potenz auf. Ein Eintrag E i in eine Rate-Tabelle mit der Tokengröße T und der Rate R wird wie folgt berechnet: E i = ( i T [Byte] ) T icks[ticks/µsec] (3.13) R[Byte/µs] Um die QDisc zu konfigurieren wird die nachstehend beschriebene Struktur tc_htb_glob genutzt. Jedoch wird sie nicht, wie bei anderen QDiscs im TCA_OPTIONS-Attribut versendet, sondern in einem eigenen TCA_HTB_INIT-Attribut. Das TCA_OPTIONS-Attribut wird jedoch als leeres Attribut davor eingefügt. 53

70 3.4. API der Linux-Queueing-Disziplinen Kapitel 3. Analyse Quelltext 3.9: Die tc_htb_glob Struktur 1 struct tc_htb_glob { 2 u32 version ; 3 u32 rate2quantum ; 4 u32 defcls ; 5 u32 debug ; 6 7 u32 direkt_pkts ; 8 }; Der Parameter version dient zum Versionsabgleich zwischen Software und verwendeter HTB-Version, da neue Versionen des TC-Programms nicht mit alten HTB- Versionen kompatibel sind. Für die im Rahmen dieser Arbeit genutzten QDisc muss Versionsnummer 3 angegeben werden. rate2quantum ist eine Berechnungsgröße für die Zuteilung von überschüssiger Bandbreite. Diese wird als Quantum nach einem Weighted Round Robin Algorithmus von Eltern an die Kindklassen weitergegeben. Wird beim Erzeugen einer Klasse ein Quantum nicht explizit angegeben, so wird es durch Division ihrer Rate durch den rate2quantum-wert ermittelt. Der Default-Wert für rate2quantum beträgt 10. In defcls wird die Minor-Nummer der Klasse angegeben, die Pakete aufnehmen soll, die nicht durch einen Filter klassifiziert werden konnten. Wird kein Wert angegeben, so entspricht er null, was bedeutet, dass unklassifizierte Pakete aus der QDisc herausfallen und mit der vollen Linkkapazität bedient werden. Der debug-parameter nimmt Debug-Level Informationen auf. Leider konnte im Rahmen dieser Arbeit nicht ermittelt werden, wie diese anzugeben sind. Der Parameter direkt_pkts gibt die Anzahl der Pakete an, die an der HTB-QDisc direkt bedient wurden, wenn bei der Konfiguration keine Default-Klasse angegeben wurde. Dieser Parameter wird bei Statusabfragen vom Kernel befüllt. Um eine Klasse eines HTB zu konfigurieren, wird eine die tc_htb_opt benutzt. Um einige der Parameter erklären zu können, muss jedoch zuerst näher auf eine andere Struktur eingegangen werden. Mit der tc_ratespec-struktur werden Datenraten spezifiziert, die zur Konfiguration der Klassen nötig sind. Es werden jedoch nicht alle Parameter der Struktur benötigt. 54

71 Kapitel 3. Analyse 3.4. API der Linux-Queueing-Disziplinen 1 struct tc_ratespec { 2 unsigned char cell_log ; 3 unsigned char reserved ; 4 unsigned short feature ; 5 short addend ; 6 unsigned short mpu ; 7 u32 rate ; 8 }; Quelltext 3.10: Die tc_ratespec Struktur Der Parameter cell_log ist der binäre Logarithmus der Tokengröße. Mit ihm kann man durch eine einfache Bitshift-Operation die Anzahl Token für ein Paket, und somit dessen Sendezeit in den rtab- und ctab-tabellen ermitteln. rtab [ pkt_size >> cell_log ] = pkt_xmit_time ; Die Paramter reserved, feature und addend werden zur Konfiguration der HTB- Klasse nicht genutzt. mpu ist die Minimum Packet Unit, also die Mindestgröße eines Pakets. Für alle Einträge in einer der Rate-Tabellen, deren Paketgröße kleiner wäre als mpu, wird zur Berechnung der Paketsendezeit der Wert von mpu verwendet. Der rate-parameter ist die Datentransferrate, angegeben in Bytes pro Sekunde. Die tc_htb_opt-struktur wird wie bei der QDisc nicht im TCA_OPTIONS-Attribut, sondern in dessen Anschluss in einem eigenen Attribut namens TCA_HTB_PARMS gesendet. Im Folgenden werden die einzelnen Parameter erklärt. Quelltext 3.11: Die tc_htb_opt Struktur 1 struct tc_htb_opt { 2 struct tc_ratespec rate ; 3 struct tc_ratespec ceil ; 4 u32 buffer ; 5 u32 cbuffer ; 6 u32 quantum ; 7 u32 level ; 8 u32 prio ; 9 }; Die Parameter rate und ceil geben die Mindest- bzw. Maximalrate an, die der Klasse zur Verfügung stehen sollen. Dabei ist zu beachten, dass die beiden Parameter für eine Klasse, deren Elternknoten die QDisc ist, gleich sind. Über die beiden Parameter buffer und cbuffer wird die Menge an Sendezeit eingestellt, die eine Klasse ansammeln und als Burst versenden kann. buffer ist also der 55

72 3.4. API der Linux-Queueing-Disziplinen Kapitel 3. Analyse Burst-Parameter für rate und cbuffer für ceil. Die Werte für die Parameter werden als benötigte Sendezeit für die Größe bei der entsprechenden Rate übergeben. Durch den Timer-Takt von 1ms ergibt sich Mindestwert für buffer. In Byte wird dieser wie folgt berechnet: b = rate/1000hz (3.14) Das würde für eine Klasse deren Rate Byte/s beträgt einen Burst-Wert von mindestens 1200Bytes haben muss um seine Rate erreichen zu können. Das ist jedoch bei kleinen Paketen nicht unbedingt erwünscht. Daher kann laut [Hub03] der Paramter cbuffer genutzt werden, um den Burst weiter nach unten zu beschränken. Der quantum-parameter bestimmt wie groß der Anteil an überschüssiger Bandbreite ist, den die Klasse im Verhältnis zu den Geschwisterklassen abbekommt. Wird der Parameter nicht angegeben, wird er durch den rate2quantum Divisor der QDisc bestimmt. Die Verwendung des Parameters level ist nirgendwo dokumentiert, und auch das Programm TC stellt diese Option nicht bereit. Die überschüssige Bandbreite der Elternklassen wird nach dem Weighted Round Robin Algorithmus auf die Kindklassen verteilt. Die Reihenfolge in der sie verteilt werden, wird durch den prio-parameter bestimmt. Der Wert liegt im Intervall [0; 7], wobei 0 die höchste Priorität darstellt. Nach dem TCA_HTB_PARMS-Attribut müssen noch die Attribute TCA_HTB_RTAB und TCA_HTB_CTAB angefügt werden. Diese enthalten die beiden Tabellen rtab und ctab, deren Inhalt mit der Formel 3.13 berechnet wird Filter Die Konfiguration von Filtern funktioniert genauso, wie die Konfiguration von Klassen und QDisc, jedoch mit ein paar Besonderheiten. Zunächst ist da der Aufbau der Handles zu erwähnen. Dieser ist nicht, wie bei Klassen und QDiscs, einheitlich, sondern von dem jeweils verwendeten Filtertyp abhängig. Daher soll weiter unten darauf eingegangen werden, wo der verwendete Filter näher erklärt wird. Elternknoten eines Filters kann jede klassenbehaftete Queueing Disziplin sein, oder eine ihrer Klassen. Passiert ein Paket diesen Knoten, wird eine Klassifizierung durchgeführt. 56

73 Kapitel 3. Analyse 3.4. API der Linux-Queueing-Disziplinen Eine weitere Besonderheit ist die Nutzung des tcm_info-feldes in der tcmsg-struktur (Listing 3.6). Ihm wird die Information über Priorität des Filters und des zu filternden Protokolls zugewiesen. Der Prioritätswert liegt im Intervall [0; 7], mit 0 als höchster Priorität, und bestimmt die Reihenfolge die Filter mit dem gleichen Elternknoten aufgerufen werden. Filter mit gleicher Priorität werden in der Reihenfolge aufgerufen, in der sie erzeugt wurden. Das zu filternde Protokoll entspricht einem gültigen Protokolltyp, wie er im Type- Feld des Ethernet-Headers vorkommt. Definierte Werte sind in der Header-Datei linux/if ether.h enthalten. Durch den Protokoll-Wert wird eine Art Vorfilterung vorgenommen. Sollen alle Protokolle berücksichtigen werden, muss der Wert ETH_P_ALL (0x0003) verwendet werden. Der Prioritätswert nimmt die oberen 16-Bit des tcm_info-feldes ein und das Protokoll die unteren Der U32-Filter Die meisten zur Verfügung stehenden Filter filtern nach speziellen Merkmalen, die entweder eine höhere Protokollschicht voraussetzen (DSMark) oder vom Routing- Modul am Socket-Buffer vorgenommene Markierungen (fw, route) benötigen. U32 filtert zwar prinzipiell nach Mustern in höheren Protokollschichten, ist jedoch so flexibel, dass er mit einem Trick 3 so konfiguriert werden kann, dass er nach Feldern im Ethernet-Header filtert. Grundsätzlich besteht der Filter aus einer Reihe von Schlüssel-, Maske-, Offset- Datensätzen, mit denen Muster in einem Paket erkannt werden können. Schlüssel und Maske decken je 32 Bit ab und können durch den Offset in 4Byte-Schritten jedes Muster an jeder Stelle, innerhalb der Payload des Ethernet-Headers, erkennen. Der Offset beginnt ab dem Ende des Ethernet-Headers. Handelt es sich dabei um einen VLAN-Tagged-Frame, beginnt der Offset zwischen dem Tag Protocol Identifier und der Tag Control Information. Soll jedoch ein Feld im Ethernet-Header selbst erkannt werden, so kann ein negativer Offset genutzt werden. Um zum Beispiel die Zieladresse eines Ethernet-Frames zu filtern, müssen zwei Datensätze angelegt werden, da die vollständige Adresse nicht von 32-Bit abgedeckt werden kann. Der erste Datensatz hätte als Schlüssel die obersten zwei Byte der Adresse, eine Maske mit dem Wert 0x00FF und ein Offset von -16. Der Schlüssel 3 Dieser Trick wurde von den Entwicklern vorgeschlagen 57

74 3.4. API der Linux-Queueing-Disziplinen Kapitel 3. Analyse des zweiten Datensatzes würde die restlichen vier Bytes der Adresse enthalten, die Maske hätte den Wert 0xFFFF und der Offset wäre -12. Das Handle des U32-Filters ist in drei Segmente unterteilt. Die oberen 12 Bit nimmt die ID einer Hash-Tabelle ein, die erzeugt wird, sobald an einem Elternknoten ein neuer Filter mit einer Priorität angelegt wird, die bisher kein Filter an diesem Knoten besitzt. Die Hash-Table-IDs werden nach diesem Prinzip automatisch vergeben, beginnend bei dem Wert 0x800. Diese ID ist eindeutig für den Elternknoten, an dem der Filter konfiguriert wurde. Die unteren 12 Bit nehmen das eigentliche Handle auf, das für die Hash-Tabelle eindeutig sein muss. Die mittleren acht Bit stehen einem Hash-Wert zur Verfügung. Zur Zeit dieser Arbeit ist jedoch kein Anwendungsfall aufgetreten, wo dieser benötigt wurde, weshalb dessen Bedeutung nicht weiter nachgegangen wurde. Um den U32-Filter anzulegen, müssen wie bei Klassen und QDiscs Attribute an die Netlink-Message angefügt werden. Das erste Attribut ist TCA_KIND mit der Filterkennung u32 als String, gefolgt von einem leeren TCA_OPTIONS-Attribut. Danach wird im Attribut TCA_U32_CLASSID das vollständige Handle der Zielklasse untergebracht, welche nicht zwingend zu der gleichen Elternklasse oder -qdisc angehören muss, wie der Elternknoten des Filters. Als letztes folgt das Attribut TCA_U32_SEL, in dem der Selektor des Filters untergebracht wird. Der Selektor wird aus zwei Strukturen gebildet: der tc_u32_sel- Struktur (Listing 3.12) und einem Array von tc_u32_key-struktur (Listing 3.13). Beide Strukturen sollen im Folgenden erläutert werden. Quelltext 3.12: Die tc_u32_sel Struktur 1 struct tc_u32_sel { 2 unsigned char flags ; 3 unsigned char offshift ; 4 unsigned char nkeys ; 5 6 u16 offmask ; 7 u16 off ; 8 short offoff ; 9 10 short hoff ; 11 u32 hmask ; struct tc_u32_key keys [0]; 14 }; Das einzige relevante Flag das in flags gespeichert wird, ist das TC_U32_TERMINAL, 58

75 Kapitel 3. Analyse 3.4. API der Linux-Queueing-Disziplinen das gesetzt werden muss, wenn das TCA_U32_CLASSID-Attribut in der Message enthalten ist. Den Verwendungszweck der Parameter offshift, offmask, off, offoff, hoff und hmask wurde im Laufe dieser Arbeit nicht ermittelt, da sie zum Einsatz in dessen Rahmen nicht benötigt werden. Der Parameter nkeys gibt die Anzahl der folgenden tc_u32_key-strukturen an. Der keys Parameter ist ein Zeiger auf den nachfolgenden Speicherbereich, in dem das Array der tc_u32_key-strukturen angelegt wird. Dieses Array bildet die Datensätze, die zum erkennen der Muster benötigt werden. 1 struct tc_u32_key { 2 u32 mask ; 3 u32 val ; 4 int off ; 5 int offmask ; 6 }; Quelltext 3.13: Die tc_u32_key Struktur Im mask-parameter wird die 32-Bit Maske gespeichert, mit der durch eine AND- Operation die nicht zu betrachtenden Bits ausgeblendet werden. Der Parameter val nimmt den Schlüssel auf. off stellt den Offset für den Schlüssel dar. Dieser kann nur in 4-Byte-Schritten angegeben werden. Mit dem Parameter offmask wird bestimmt, ab welcher Position der Offset des Musters gemessen wird. Ist der Parameter 0, wird der Offset ab dem Ende des Ethernet-Headers gemessen, ist er -1, so wird er ab dem Beginn des nächsthöheren Headers gemessen. Wird eine Queueing Disziplin oder Klasse gelöscht, so werden automatisch alle Filter, deren Elternknoten sie ist, ebenfalls gelöscht. Ist das so erwünscht müssen für die Erzeugung des Filter nicht notwendigerweise Priorität und Handle angegeben werden. Soll jedoch ein Filter gezielt gelöscht werden muss dieser eindeutig identifizierbar sein. Dazu ist die Angabe des Handles des Elternkotens, des Handles des Filters inklusive Hash-Table-ID, dessen Priorität und die Art des Filters in einem TCA_KIND-Attribut nötig. 59

76 3.5. Designentscheidungen Kapitel 3. Analyse 3.5 Designentscheidungen Statische Verkehrscharakteristik Es wird, aufgrund der heute in der Regel statischen Verkehrscharakteristik einer Automationsumgebung, auf eine dynamische Allokation der QoS-Parameter verzichtet. Jedoch soll die entwickelte Software in Hinblick auf eine Erweiterung auf dynamische Umgebungen offen sein Linux ohne Echtzeiterweiterung Echtzeiterweiterungen für das Linux-Betriebssystem nutzen die Kern-im-Kern-Architektur. Dabei setzt sich der Echtzeit-Kern der Erweiterung zwischen das Interrupt- System des Rechners und den Linux-Kern. Der Linux-Kern greift auf ein simuliertes Interrupt-System des Echtzeit-Kerns zurück, hat aber noch vollen Zugriff auf alle seine Treiber. Echtzeitanwendungen laufen als Module im Kern-Adressraum und haben dadurch keinen Zugriff auf die Systemcall-Schnittstellen des Betriebssystems. Zugriff auf die Hardware, muss durch eigene Treiber realisiert werden. Eine solche Echtzeitanwendung könnte das vom Linux-Kern bereitgestellte QoS- Framework nicht nutzen. Daher wird auf den Einsatz einer Echtzeiterweiterung verzichtet. Zur Zeit ist für die Echtzeiterweiterung RTAI eine experimentelle Entwicklung nahmens RTAI/fusion in Arbeit. Diese soll einen kurzzeitigen Wechsel von der RTAIin die Linux-Domäne ermöglichen, um deren Systemschnittstellen zu nutzen. Dies bringt aber auch einen Verlust des Determinismus für diesen Zeitraum mit sich Einsatz von Switches Um den Determinismus für Ethernet zu erreichen, soll eine Microsegmentierung des Netzwerks durch Switches durchgeführt werden. Die eingesetzten Switches sollen 802.1p-fähig sein und über Ports mit mindestens vier Ausgangsqueues verfügen, die nach dem Strict-Priority-Algorithmus bedient werden. 60

77 Kapitel 4 Konzept 4.1 Grobentwurf Um verschiedene Kommunikationsformen mit verschiedenen QoS-Eigenschaften, wie sie in Kapitel 3.2 besprochen wurden, unterscheiden zu können, bedarf es einer logischen Einteilung der Netzwerkressourcen. Der Kommunikationsschicht liegt ein Modell zugrunde, welches das Medium logisch in bidirektionale Kanäle mit eigenen QoS-Eigenschaften einteilt. Jeder Kanal entspricht einer Multicastgruppe mit zwei oder mehr Teilnehmern. Damit lässt sich jede Kommunikationsform aus Kapitel 3.2 unterstützen. Isochrone Propagation von Messdaten erfordert ohnehin Multicast- Betrieb. Gezielte Adressierung einer Station erfordert einen eigenen Kanal mit zwei Teilnehmern. Dies ist unproblematisch, da davon ausgegangen wird, dass alle Kommunikationspfade vor der Inbetriebnahme der Anlage bekannt sind. Auch die Anmeldung und Abmeldung von Publish-Subscriber-Listen, wie sie in Abschnitt erwähnt wurden, ist durch das Modell unterstützt, auch wenn deren Implementierung höheren Protokollschichten überlassen wird. Abbildung 4.1 zeigt ein konzeptionelles Klassenmodell, an dem das Grobkonzept weiter beschrieben wird. Um über einen Kanal kommunizieren zu können, muss von einem Prozess ein Kanalendpunkt (Channel) geöffnet werden. Dem Kanalendpunkt sind lokale QoS-Eigenschaften zugewiesen, die so gewählt sind, dass die QoS-Eigenschaften des Kanals gewahrt werden. Es wird angenommen, dass lokalen Parameter vor der Inbetriebnahme der Anlage durch eine Scheduability-Analyse ermittelt und über eine Konfigurationsdatei eingelesen werden. 61

78 4.1. Grobentwurf Kapitel 4. Konzept Abbildung 4.1: Konzeptionelles Klassenmodell Ein Kanal wird über eine ID eindeutig identifiziert; diese wird bei jeder Interaktion angegeben. Eine Kanal ID wird auf eine Layer-2-Multicast-Adresse abgebildet. Für bestimmte Kanäle, wie einen Alarm-Kanal, ist es notwendig, dass mehr als ein Prozess eines Rechners auf den Kanal zugreifen kann. Für diesen Fall wird mit einem Sychronisationsobjekt(Sync) der wechselseitige Ausschluss beim Senden durchgesetzt. Die Kommunikation erfolgt über Packet-Sockets (Kapitel 2.3.1), um den TCP/- UDP/IP-Stack zu umgehen. Die Adressierung ist vom verwendeten Device (Physical Device) und dessen Layer-2- Protokoll abhängig. Diese wird vorgenommen, während der Kanalendpunkt an das Device gebunden wird. Um die Klassifizierung von Paketen durchzuführen, werden bei Initialisierung des Devices zwei VLANs erzeugt: Eins für die Kanal-Konfigurationsschicht und ein anderes um die vertikale Integration durchzusetzen. In dem virtuellen Device der Kanäle werden die Socket-Prioritäten eins zu eins auf die User Priority des VLAN-Tags abgebildet. Verkehr, der über das virtuelle Device für den Best-Effort-Verkehr gesendet wird, bekommt eine Standard-Priorität von 1 zugewiesen, was wie in besprochen wurde, der niedrigsten Priorität entspricht. Die Konfiguration der Queueing-Disziplinen, entsprechend der Kanal-Parameter, wird durch einen QoS-Controller vorgenommen. Dieser nimmt die Parameter eines Kanalendpunktes auf und setzt sie in die entsprechenden Queueing-Disziplinen um. Als Schnittstelle zur Kommunikationsschicht dient eine Shared-Library, die zu der aufrufenden Applikation gebunden wird. 62

79 Kapitel 4. Konzept 4.1. Grobentwurf Die QoS-Parameter der Kanäle werden durch Linux-Queueing-Disziplinen durchgesetzt, die, wie in Kapitel besprochen, über Netlink-Sockets konfiguriert werden. Zum Einsatz kommt eine Prio-Qdisc mit acht Bändern, deren Bandbreite durch Hierarchical-Token-Buckets für jeden Kanal eingegrenzt wird. Der Best-Effort- Verkehr bekommt an dem Band mit der niedrigsten Priorität einen eigenen Bucket mit der verbleibenden Bandbreite zugewiesen. Die Parameter für die Kanalendpunkte auf einem Rechner, werden in Form einer Konfigurationsdatei bei der Initialisierung eingelesen. Auf Grundlage des konzeptionellen Klassenmodells wird ein detailiertes Klassenmodell erstellt, das in Abbildung 4.2 dargestellt ist. Die Klasse chcontr dient als Bibliotheksschnittstelle und verwaltet die Kanalendpunkte, die in der chdescr-klasse abgebildet sind. Die Klasse enthält das sync- Objekt und noch ein Kommunikationsobjekt (com), das als Kommunikationsschnittstelle zu den Packet-Sockets dient. Bei Initialisierung wird, wie in Kapitel besprochen, eine Konfigurationsdatei eingelesen, deren Inhalt durch die Klasse chconfread zugreifbar ist. Die Prozess-Klasse im konzeptionellen Klassendiagramm ist der chavailcontr-klasse gewichen, welche für jedes chdescr-objekt ein chavail-objekt hält, das die maximale und die aktuelle Anzahl der Prozesszugriffe auf den Kanal verwaltet. Diese chavail-objekte werden in einem Shared-Memory-Segment gehalten, um für alle Prozesse einsehbar zu sein. Die Klasse chdev entspricht der Klasse Physical Device aus dem konzeptionellen Klassendiagramm und wird zu Adressierung und Konfiguration der VLANs eingesetzt. Die drei Instanzen der devinfo-klasse halten nach der Initialisierung die Informationen über das physikalische und die beiden virtuellen Devices. Die Klasse chqoscontr setzt die QoS-Parameter der Kanalendpunkte in eine entsprechende Konfiguration der Queueing Disziplinen um. Da es sich bei dem Klassenmodell um eine Design-Methode aus der Objekt Orientierung handelt, jedoch bei der Implementierung eine prozedurale Programmiersprache zum Einsatz kommt, werden weitestgehend Utitlity-Klassen verwendet. Bei diesen handelt es sich nach [Oes01] um eine Sammlung globaler Variablen und Funktionen, die semantisch zu einer Klasse zusammengefasst werden. 63

80 4.2. Die Konfiguration (chconfread) Kapitel 4. Konzept Abbildung 4.2: Übersicht Klassendiagramm 4.2 Die Konfiguration (chconfread) Bei der Konfigurationsdatei handelt es sich um eine Datei im XML-Format, deren Aufbau im Folgenden anhand ihrer Document Type Definition erklärt werden soll. 64

81 Kapitel 4. Konzept 4.2. Die Konfiguration (chconfread) Abbildung 4.3: Übersicht Klassendiagramm Quelltext 4.1: Document Type Definition der Konfigurationsdatei 1 <? xml version =" 1.0 " encoding ="ISO "?> 2 < DOCTYPE channelconf [ 3 <! ELEMENT channelconf ( host +) > 4 <! ELEMENT host ( name, netdevice, channel +) > 5 <! ELEMENT name (# PCDATA ) > 6 <! ELEMENT netdevice ( devname, mtu ) > 7 <! ELEMENT devname (# PCDATA ) > 8 <! ELEMENT mtu (# PCDATA ) > 9 <! ELEMENT channel ( ID, processes, prio, delay, jitter, psize, bandwidth ) > 10 <! ELEMENT ID (# PCDATA ) > 11 <! ELEMENT processes (# PCDATA ) > 12 <! ELEMENT prio (# PCDATA ) > 13 <! ELEMENT delay (# PCDATA ) > 14 <! ELEMENT jitter (# PCDATA ) > 15 <! ELEMENT psize (# PCDATA ) > 16 <! ELEMENT bandwidth (# PCDATA ) > 17 ]> Die Datei kann die Parameter für mehrere Rechner übernehmen (Zeile 3), so dass für alle Rechner einer Automationsanlage die gleiche Konfigurationsdatei verwendet werden kann. Der Host (Zeile 4) wird durch den Rechnernamen identifiziert. Beim Einlesen der Datei wird der name-parameter mit dem Rechnernamen verglichen, um die passenden Konfigurationsparameter zu ermitteln. Die Daten für das Netzwerk-Device (Zeile 6) bestehen aus dem Namen des Devices und der zu konfigurierenden MTU für das Device des Best-Effort-Verkehrs. Danach folgt eine Liste mit den Kanalparametern (Zeile 9). Die Klasse chconfread dient als Interface zur Konfigurationsdatei. Mit deren Methode readconffile() wird die Datei eingelesen und im Speicher gehalten und kann mit den folgenden Methoden ausgelesen werden. Über die Methode getdevname() werden der Name und die MTU für das Netzwerk-Device abgefragt. Mit jedem Aufruf der Methode getchannelparame() werden die Parameter eines Kanals in die per Referenz übergebenen Variablen eingetragen, bis alle Kanal-Daten übergeben sind. Sind alle gewünschten Daten abgerufen, kann mit closeconffile() die Datei 65

82 4.3. Die Bibliotheksschnittstelle (chcontr) Kapitel 4. Konzept geschlossen und der belegte Speicher freigegeben werden. 4.3 Die Bibliotheksschnittstelle (chcontr) Die Klasse chcontr dient als Bibliotheksschnittstelle und als zentrale Controller- Klasse, mit deren Methoden alle Aktivitäten, der mit ihr assozierten Klassen, gesteuert werden. Zusätzlich enthält sie eine Liste mit den geöffneten Kanalendpunkten, sowie denen, die zum Öffnen bereitstehen. Um den wechselseitigen Ausschluss sowohl beim Initialisieren von globalen Betriebsmitteln, wie Queueing Disziplinen und virtuellen Devices, als auch beim Zugriff auf die chavailcontr-klasse zu gewährleisten, hält die Klasse chcontr ein Semaphor. Die Interaktionsmöglichkeiten mit der Bibliotheksschnittstelle werden im Folgenden mit Hilfe einiger Kollaborationsdiagramme gezeigt. Initialisierung der Bibliothek Vor der Nutzung der Bibliothek muss diese initialisiert werden, damit die Konfigurationsdatei ausgelesen wird und daraufhin alle benötigten Resourcen reserviert werden können. Bei Initialisierung wird das Semaphor erschaffen, das den Vorgang schützen soll. Wird durch die Existenz des Semaphors feststellt, dass ein anderer Prozess die globalen Betriebsmittel bereits initialisiert hat, werden nur noch für den Prozess globale Variablen initialisiert. Das Diagramm in Abbildung 4.4 geht von der Annhame aus, dass noch kein Prozess vorher auf die Bibliothek zugegriffen hat. 1 Die Initialisierung der Bibliothek wird durch die Funktion initchannels() angestoßen. 1.1 Über die Konfigurationsdatei werden alle verfügbaren Kanal-IDs, sowie deren Parameter und Prozesszugriffsdaten, eingelesen und in dem chconfread-objekt gehalten. 1.2 Der Name des Netzwerk-Devices wird durch die getdevname()-methode angefordert. 1.3 Der Name des Devices wird mit der Methode initdev() an das device-objekt übergeben. Diese initialisiert alle erforderlichen Daten und legt die VLANs an. 66

83 Kapitel 4. Konzept 4.3. Die Bibliotheksschnittstelle (chcontr) Abbildung 4.4: Kollaborationsdiagramm zu initchannels() 1.4 Das chavailcontr-objekt wird durch die Methode initchavail() angewiesen den Shared Memory anzulegen. 1.5 In initqos() werden die QDisc-Grundkonfigurationen angelegt. Die Kanalspezifischen QoS-Einstellungen werden hier noch nicht vorgenommen, sondern erst beim Öffnen des Kanals. Dies ist in einer statischen Umgebung zwar nicht nötig, erleichtert aber die Erweiterung des Designs für dynamische Umgebungen. 1.6.*.1 Am chconfread-objekt werden zyklisch alle Kanaldaten sowie deren Prozesszugriffsdaten mit der Methode fillnextchannel() abgefragt. 1.6.*.2 Mit den ausgelesenen Daten wird ein chdescr-objekt erstellt. 1.6.*.3 Die Prozesszugriffsdaten werden im chavailcontr-objekt mit der Methode addavailentry() eingetragen. 1.7 Die Konfigurationsdatei wird geschlossen. Schließen der Bibliothek Nach Benutzung der Bibliothek muss diese wieder geschlossen werden, um alle allokierten Resourcen wieder freizugeben. Der letzte zugreifende Prozess entfernt damit 67

84 4.3. Die Bibliotheksschnittstelle (chcontr) Kapitel 4. Konzept auch alle VLANs, QoS-Einstellungen und das Shared-Memory-Segment. Auch in dem Diagramm in Abbildung 4.5 wird davon ausgegangen, dass der ausführende Prozess, der letzte ist, der auf die Bibliothek zugreift. Abbildung 4.5: Kollaborationsdiagramm zu closechannels() 1 Die Schließung der Bibliothek wird über die Methode closechannels() durchgeführt. 1.1.* Bevor die Bibliothek geschlossen werden kann, muss geprüft werden, ob noch geöffnete Kanäle für den Prozess existieren. Ist dies der Fall, muss der Vorgang mit einer Fehlermeldung abgebrochen werden. 1.2.* Existieren keine geöffneten Kanäle mehr, werden alle chdescr-objekte zerstört. 1.3 Mit der Methode closeavailcontr wird der Prozess vom Shared-Memory-Segment getrennt. 1.4 Der letzte zugreifende Prozess entfernt mit der Methode closeqoscontr alle QoS-Einstellungen. 1.5 Desweiteren entfernt der letzte Prozess mit closedev am chdev-objekt alle vorgenommen Einstellungen am Netzwerk-Device, inklusive VLANs. 68

85 Kapitel 4. Konzept 4.3. Die Bibliotheksschnittstelle (chcontr) Öffnen eines Kanals Um Daten auf einem Kanal senden und empfangen zu können, muss ein Kanalendpunkt geöffnet werden. Ein geöffneter Kanal verfügt über ein Kommunikationsobjekt, das die nötigen send()- und recv()-methoden bereitstellt. Abbildung 4.6: Kollaborationsdiagramm zu chopen() 1 Die Bibliotheksschnittstelle zum Öffnen von Kanälen ist die Funktion chopen(), bei der die ID des gewünschten Kanals übergeben werden muss. 1.1 Mit der Methode registerchannel() wird ermittelt, ob der Prozess auf den Kanal zugreifen darf und ob er dabei der erste ist. Außerdem wird ein Schlüssel zu einem globalen Synchronisationsobjekt im per Referenz übergebenen Parameter key eingetragen, wenn mehr als ein Prozess auf den Kanal zugreifen darf. Die registerchannel()-methode ist durch das Semaphor geschützt, dass bei der Initialisierung erschaffen wird. 1.2 Wurde ein Wert größer Null zurückgeliefert, wird ein Kommunikationsobjekt für den Kanal erzeugt. 1.3 Weißt der Parameter key einen Wert ungleich Null auf, wird ein Sychronisationsobjekt mit dem enthaltenen Schlüssel generiert. 1.4 Sowohl Kommunikations- als auch Synchronisationsobjekt werden an das chdescr -Objekt übergeben. 1.5 Der Kanal wird mit der Methode bindchannel an das Netzwerk-Device gebunden. 69

86 4.3. Die Bibliotheksschnittstelle (chcontr) Kapitel 4. Konzept 1.6 War der von der registerchannel()-methode zurückgelieferte Wert gleich Eins, ist der Prozess der erste, der auf den Kanal zugreift. In diesem Fall werden die QoS-Eigenschaften des Kanals mit der Methode addchannel() an das chqoscontr-objekt übergeben. Schließen eines Kanals Das Schließen eines Kanalendpunktes ist notwendig, um die Resourcen, die reserviert wurden, wieder freizugeben. Abbildung 4.7: Kollaborationsdiagramm zu chclose() 1 Um einen Kanalendpunkt zu schließen, muss die Methode chclose aufgerufen werden. 1.1 Der Kanal wird am chavailcontr mit der Methode unregisterchannel() deregistriert. 1.2 Konnte der Kanalendpunkt deregistriert werden, wird er mit der Methode releasechannel () vom Netzwerk-Device entbunden. 1.3 Wurde von der Methode unregisterchannel() ein Wert gleich Eins zurückgeliefert, war der Prozess der letzte, der auf den Kanal zugegriffen hat. In diesem Fall werden die QoS-Eigenschaften des Kanal mit der Methode remchannel() 70

87 Kapitel 4. Konzept 4.3. Die Bibliotheksschnittstelle (chcontr) am chqoscontr-objekt wieder entfernt. Die registerchannel()-methode ist durch das Semaphor geschützt, dass bei der Initialisierung erschaffen wird. 1.4 Das Kommunikations- und das Synchronisationsobjekt des Kanalendpunktes werden vom chdescr angefordert. 1.5 Wenn ein Synchronisationsobjekt vorhanden ist, wird es zerstört. 1.6 Das Kommunikationsobjekt wird zerstört. Senden auf einem Kanal Ist die Bibliothek initialisiert und ein Kanalendpunkt geöffnet, kann auf diesem gesendet bzw. empfangen werden. Abbildung 4.8: Kollaborationsdiagramm zu chopen() 1 Zum Senden auf einem Kanal bietet die Biliotheksschnittstelle die Methode chsend (). 1.1 Vom chdescr-objekt werden Synchronisations- und Kommunikationsobjekt angefordert. 1.2 Existiert ein Synchronisationsobjekt, so wird an ihm der exklusive Zugriff auf den Kanal reserviert. 1.3 chcontr ruft die send-methode am Kommunikationsobjekt auf. 1.4 Der exklusive Zugriff wird wieder aufgehoben, sofern er zuvor reserviert wurde. 71

88 4.4. Der Kanalendpunkt (chdescr) Kapitel 4. Konzept Empfangen auf einem Kanal Für den Empfang von Daten über einen Kanal ist keine Synchronisation notwendig, da die Information alle Kanalendpunkte erreichen soll. Abbildung 4.9: Kollaborationsdiagramm zu chrecv() 1 Mit der Methode chrecv() können Daten über einen geöffneten Kanalendpunkt empfangen werden. 1.1 Das Kommunikationsobjekt wird von chdescr geholt. 1.3 Die recv()-methode wird aufgerufen. 4.4 Der Kanalendpunkt (chdescr) Die chdescr-klasse stellt den Kanalendpunkt dar, durch den die Kommunikation mit den restlichen Teilnehmern stattfindet. Jedes chdescr-objekt hat eine eindeutige ID, durch die es identifiziert wird und eine Reihe von QoS-Parametern, die es charakterisieren. Die ID ist eine netzwerkweite Identifikationsnummer, die für jeden Kanal eindeutig ist, und im Parameter id gespeichert wird. Kanalendpunkte, die auf einen Kanal zugreifen möchten, verwenden dessen ID. Durch die Art, wie die Kanal- ID auf QDisc und Filter-Handles abgebildet wird, ergibt sich für die Kanal-ID ein Wertebereich von 0x001 bis 0xFFF. Der Ursprung dieser Grenzen wird in Abschnitt 4.7 beschrieben. Der Parameter prio entspricht einem Prioritätswert gemäß IEEE 802.1p. Der delay-parameter ist die maximale Verweilzeit in der QDisc in µsec. Der Delay kann nicht direkt beeinflusst werden, sondern wird indirekt über die Priorität gesteuert. Der Parameter wird trotzdem in der Klasse gehalten, um zukünftigen Implementationen, die den Delay evtl. direkt beeinflussen können, zur Verfügung zu stehen. 72

89 Kapitel 4. Konzept 4.4. Der Kanalendpunkt (chdescr) Abbildung 4.10: chdesrc-klasse Mit jitter verhält es sich genauso wie mit dem delay-parameter. Der Jitter kann nicht direkt beeinflusst werden, sondern nur durch hohe Priorität oder durch Pufferung am Empfänger minimiert werden. psize ist die maximale Payload-Größe in Byte. Der konfigurierte Wert muss eingehalten werden, um die berechneten Parameter für den Delay einhalten zu können. Daher werden Daten, die größer sind als in psize spezifiziert, von der chsend()- Methode der Bibliothek zurückgewiesen. Im Parameter bandwidth wird die benötigte Bandbreite des Kanals gespeichert. Diese wird in Pakete/s angegeben, kann aber über die Paketgröße in Byte/s umgerechnet werden. Alle Kanalendpunkte, die während des Betriebs gebraucht werden, werden zur Zeit der Bibliotheksinitialisierung erzeugt. Diese sind zu diesem Zeitpunkt noch ungeöffnet, was daran erkennbar ist, dass sie noch kein Kommunikationsobjekt besitzen. Das Kommunikationobjekt(com) kapselt im wesentlichen einen Packet-Socket und dessen Adresse, die mit dem Systemcall sendto() genutzt wird. 73

90 4.4. Der Kanalendpunkt (chdescr) Kapitel 4. Konzept Zusätzlich besitzt es die zwei abstrakten Methoden send()- und recv(), die durch Ableitung der Klasse überschrieben werden können. Die Basis-Methoden sind wiederum einfache Kapselungen der sendto() und recv() Systemcalls. Es sind jedoch auch andere Kommunikationsmethoden möglich, die bestimmte Kommunikationsformen besser unterstützen. So wäre es möglich, den Jitter auf Kosten des Delays zu verringern, indem man die empfangenen Pakete puffert. In Abbildung 4.11 wird das Konzept zur Umsetzung dieser Kommunikationsform gezeigt. Abbildung 4.11: Konzept für den gepufferten Empfang Für das Konzept benötigt man zwei verschiedene Ableitungen der Klasse com, von der die Klasse bufrecvcom die Senderseite des Kanals darstellt. Die Klasse für den Empfang bufproccom wartet in einem eigenen Prozess auf die Ankunft von Paketen. Diese werden dann mit der send()-methode an eine Message-Queue weitergegeben, sobald sie eintreffen. Das bufrecvcom-objekt kann diese mit der eigenen recv()- Methode Jitter-frei auslesen. Wird der Kanal von mehreren Prozessen genutzt, so muss der wechselseitige Ausschluss beim Senden gewährleistet sein. Zu diesem Zweck hält ein Kanalendpunkt, auf dem mehr als ein Prozess zugreifen darf, ein Synchronisationsobjekt (sync) bereit, über das ein Kanal zum Senden reserviert werden kann (Abbildung 5.1). 74

91 Kapitel 4. Konzept 4.5. Prozesszugriffsverwaltung (chavailcontr/ chavail) Das in chdescr enthaltene Synchronisationsobjekt sync ist ein Prozess-übergreifendes, vom Betriebssystem verwaltetes Semaphor, das global über einen Schlüssel identifiziert wird. Das Semaphor wird beim Anlegen eines Eintrags im Shared-Memory- Segment von der Methode addchavailentry() erzeugt und dessen Schlüssel wird im synckey-attribut des chavail-objekts abgelegt. 4.5 Prozesszugriffsverwaltung (chavailcontr/ chavail) Abbildung 4.12: chavailcontr- und chavail-klasse Der Zugriff von mehr als einem Prozess auf einen Kanal ist nicht immer erwünscht. Zum einen hängen die QoS-Parameter stark von der genutzten Bandbreite ab, so dass nicht mehr Prozesse Daten senden dürfen, als vorher festgelegt wurden. Zum anderen ist auch die Anzahl der zur Verfügung stehenden Semaphoren begrenzt. Um zu verhindern, dass mehr Prozesse auf einen Kanal zugreifen, als vorgesehen sind, muss ein Prozess-übergreifender Mechanismus existieren, der den Zugriff auf die Kanäle einschränkt. Zu diesem Zweck existiert für jeden Kanal ein chavail- Objekt, das in einem Shared-Memory-Segment gehalten wird. Dies enthält sowohl die maximale Anzahl von Prozessen, die auf den Kanal zugreifen dürfen (max), als auch die aktuelle Anzahl von Prozessen, die schon auf den Kanal zugreifen (cur). Außerdem halten diese Objekte den Schlüssel zu dem Kanal-zugehörigen Semaphor, falls mehr als ein Prozess einen Endpunkt auf diesem Kanal öffnen darf. Ein neues Objekt wird mit der Methode addchavailentry() in das Shared-Memory-Segment eingetragen. Wurde der Eintrag schon von einem anderen Prozess vorgenommen, wird kein neuer Eintrag angelegt. Das Shared-Memory-Segment wird von dem ersten Prozess erzeugt, der die Methode initavailcontr aufruft, und vom letzten zugreifenden Prozess mit der Methode 75

92 4.6. Netzwerk-Device (chdev) Kapitel 4. Konzept closeavailcontr wieder zerstört. Alle anderen Prozesse verbinden bzw. lösen sich von dem bestehenden Segment. Die Methoden registerchannel() und unregisterchannel() dienen als Test-And- Set-Methoden zur Reservierung des Kanalzugriffs. Der Rückgabewert signalisiert den Zugriffsstatus des Kanals. Ein negativer Wert zeigt, dass der Kanalendpunkt nicht geöffnet bzw geschlossen werden kann. Ein Wert gleich Null gibt den Kanal zum Öffnen bzw. Schließen frei. Wird ein positiver Wert zurückgeliefert, heißt das, der Prozess ist der erste bzw. der letzte, der auf den Kanal zugreift. Damit wird signalisiert, dass die zum Kanal zugehörige QDisc angelegt bzw. gelöscht werden kann. Abbildung 4.13 zeigt den Vorgang exemplarisch für registerchannel als Aktivitätsdiagramm. Abbildung 4.13: registerchannel-methode 4.6 Netzwerk-Device (chdev) Das Adressierungsschema eines Packet-Sockets ist vom unterlagerten Netzwerk-Device abhängig. Wird ein Kanal geöffnet, muss dessen Socket an das entsprechende Device gebunden und die Kanal-ID auf eine Adresse abgebildet werden. Die chdev-klasse enthält für diesen Zweck zwei abstrakte Methoden, die durch Implementierung in abgeleiteten Klassen, für das jeweilige Adressierungsschema angepasst werden können. Für diese Arbeit ist lediglich eine abgeleitete Klasse für das Binden des Sockets an Ethernet-Devices vorgesehen. Eine Anpassung an andere Layer-2-Protokolle, soweit 76

93 Kapitel 4. Konzept 4.6. Netzwerk-Device (chdev) Abbildung 4.14: Die chdev-klasse sie durch die Packet-Socket-Schnittstelle nutzbar sind, sollte durch dieses Design leicht fallen. Informationen über das reale und die zwei virtuellen Netzwerk-Devices werden vom chdev-objekt in drei devinfo-objekten gehalten. Die Information besteht aus dem Namen, dem Index und dem ARP-Addresstyp des Device. Bei der Initialisierung des chdev-objekts mit der Methode initdev(), wird der Name des zu verwendenden realen Netzwerk-Devices übergeben, mit dem dann dessen Index und Adresstyp ermittelt werden. Je nach Adresstyp kann dann die Initialisierung fortgesetzt werden. Entspricht der Adresstyp Ethernet, werden als nächstes die beiden VLANs erzeugt, falls diese noch nicht existieren sollten. Das VLAN für die Kanäle bildet die Priorität der mit dem Kanal assoziierten Sockets auf die User- Priority eins zu eins ab. Das VLAN für den Best-Effort-Verkehr bildet alle Socket- Prioritäten auf den User-Priority-Wert Eins ab, welcher nach 802.1p dem Wert mit der niedrigsten Priorität entspricht. Das VLAN-Device bekommt die IP-Adresse des physikalischen Device zugewiesen, und die MTU wird auf den in der initdev() übergebenen Wert gesetzt. Danach werden die Informationen über die beiden virtuellen 77

94 4.7. QoS-Controller (chqoscontr) Kapitel 4. Konzept Devices ermittelt und in deren devinfo-objekten gespeichert. Die beiden abstrakten Methoden werden mit den Ethernet-spezifischen Methoden überschrieben. Die Konfiguration der virtuellen Devices wird über eine Konfigurationsbibliothek durchgeführt, die die nötigen ioctl()-zugriffr kapselt. Die für Ethernet konzipierte bindchannel()-methode öffnet einen Packet-Socket, bildet die Kanal-ID auf eine Ethernet-Multicast-Adresse ab und bindet den Packet- Socket des Kommunikationsobjekts an diese Adresse am virtuellen Device. Die ermittelte Adresse wird dem Kommunikationsobjekt zugewiesen. releasechannel() entfernt den Packet-Socket von dem Netzwerk-Device und schließt ihn. 4.7 QoS-Controller (chqoscontr) Abbildung 4.15: Die chqoscontr-klasse Der QoS-Controller ist die Schnittstelle zu den Queueing-Disziplinen unter Linux. Beim Hinzufügen oder Entfernen eines Kanals übernimmt der QoS-Controller die Parameter des Kanals und fügt entsprechende Queueing-Disziplinen hinzu oder entfernt sie wieder. Dazu nutzt er eine dafür implementierte QDisc-Konfigurations- Bibliothek, die den Zugriff auf die Netlink-Sockets kapselt. Die Filterregeln, die zum Klassifizieren der Pakete genutzt werden, sind vom verwendeten Layer-2-Protokoll abhängig. Unter Ethernet ist die ID eines Kanals Teil einer Filterregel. Diese ist ein Teil der Multicast-Adresse des Ethernet-Frames. Wird die Bibliothek für ein Device mit einem anderen Layer-2-Protokoll genutzt, kann diese 78

95 Kapitel 4. Konzept 4.7. QoS-Controller (chqoscontr) Regel nicht verwendet werden. Für diesen Fall wird in chqoscontr eine Tabelle mit Filterregeln für mögliche Adresstypen gehalten. Das chqoscontr-objekt wird mit dem Index des zu verwendenden Device und dessen Adresstyp über die Methode initqos() initialisiert. Wird für den boolschen Parameter initqdisc TRUE übergeben, so wird ein Grundgerüst an Queueing-Disziplinen erzeugt, an dem jeweils die benötigten Queueing-Disziplinen für die Kanäle angebracht werden. Die QDisc für den Best-Effort-Verkehr wird auch zur Zeit der Initialisierung erzeugt und bekommt zunächst die gesamte Bandbreite zugesprochen. Die Methode closeqos entfernt alle QoS-Einstellungen vom konfigurierten Netzwerk- Device. Mit den Methoden addchqos() und remchqos() werden die Queueing-Disziplinen, entsprechend der übergebenen QoS-Parameter, erzeugt bzw. gelöscht. Gleichzeitig werden die Filter, entsprechend der Regeln für den Adresstyp, gesetzt. Mit jedem Hinzufügen und Entfernen von Kanälen, wird die QDisc des Best-Effort-Verkehrs mit der verbleibenden Bandbreite rekonfiguriert. Die Vorgehensweise, QDiscs und Filter für die Kanäle erst bei deren Öffnung bzw. Schließung zu konfiguriert, unterstützt die Erweiterbarkeit der Bibliothek für dynamische Umgebungen. Wie der Aufbau der QDiscs bei der Initialisierung und für jeden Kanal im Detail aussieht, soll im Folgenden genauer betrachtet werden. Basis-QDisc-Konfiguration Für die Basiskonfiguration (Abbildung 4.16) wird bei der Initialisierung zunächst eine Prio-QDisc mit acht Bändern als Root-QDisc konfiguriert. Wie in erläutert, kann die Major-Nummer eines QDisc-Handles mit einem Wert zwischen 0x0001 und 0x7FFF erzeugt werden. Für die Prio-QDisc wird das Handle 0x7FFF:0 gewählt, damit die niedrigen Handles für die Blatt-QDiscs frei bleiben. In wurde besprochen, dass eine Prio-QDisc ihre Klassen selbst in der Anzahl der konfigurierten Bänder erzeugt. Diese Klassen erhalten Handles deren Minor Nummer von 0x0001 bis 0x0008 durch nummeriert. Die Priorität der Klassen ist umgekehrt proportional zu deren Minor-Nummer. Switches klassifizieren Pakete nach dem in IEEE 802.1p definierten Schema (vgl. Kapitel 2.1.1), daher müssen Pakete in der QDisc auf die gleich Weise klassifiziert werden. Um das zu gewährleisten wird für jede Klasse der Prio-QDisc ein u32-filter 79

96 4.7. QoS-Controller (chqoscontr) Kapitel 4. Konzept Abbildung 4.16: Basis-QDisc-Konfiguration erzeugt, der das User-Priority-Feld des VLAN-Tags ausliest und an die Zielklasse mit der entsprechenden Priorität sendet (vgl. Abbildung4.16 und Tabelle A.1). Um den Klassifizierungsaufwand für hochpriore Pakete zu minimieren, werden den Filtern Prioritäten entsprechend der Priorität ihrer jeweiligen Zielklasse zugewiesen. Grundsätzlich müsste man keinen eigenen Filter für Prio erzeugen, da dieser Pakete selbst aufgrund ihrer Socket-Priorität klassifizieren kann. Auf die Socket-Prioritäten der Pakete, die über das Best-Effort-Device versendet werden, kann jedoch kein Einfluss genommen werden. Daher wird die Socket-Prioritäten durch die Egress- Prio-Map des Best-Effort-Devices alle auf die Priorität 1 abgebildet und für die QDisc die Filter erzeugt. 80

97 Kapitel 4. Konzept 4.7. QoS-Controller (chqoscontr) Wie in in Kapitel besprochen, muss der Verkehr für eine nach dem Strict- Priority-Algorithmus arbeitende Queue charakterisierbar sein, um den maximalen Delay innerhalb der Queue garantieren zu können. Dort wurde der Verkehr durch den Token-Bucket-Algorithmus eingegrenzt. Dies soll in der Konfiguration durch eine HTB-QDisc geschehen, deren Kindklassen die Bandbreite für jeden Kanal eingrenzen sollen. Die QDisc wird als reiner Bandbreitenbegrenzer eingesetzt werden, ohne das Automatische Verteilen von überschüssiger Bandbreite. In der Basiskonfiguration werden die Klassen für die Kanäle noch nicht erzeugt, sondern nur deren Eltern-QDiscs an jeder Prio-Klasse. Die Handles der QDiscs werden so gewählt, dass deren Major-Nummer jeweils der um eins inkrementierten User- Priority der Pakete entspricht, die ihnen durch die Filter zugewiesen werden. Auch hier sei zum besseren Versändnis wieder auf Tabelle A.1 verwiesen. Abbildung 4.17: Best-Effort-QDisc-Konfiguration An der QDisc 2:0, deren Elternklasse die niedrigste Priorität hat, wird die Klasse für den Best-Effort Verkehr angefügt (Abbildung 4.17). Diese bekommt das Handle 2:FFFF zugewiesen, da 0xFFFF dieses außerhalb des Wertebereichs der Kanal-ID und es daher nicht zu Kollisionen der Klassen Handles kommen kann. Bevor die 81

98 4.7. QoS-Controller (chqoscontr) Kapitel 4. Konzept Kanäle geöffnet werden, bekommt die Klasse des Best-Effort-Device die gesamte Bandbreite als rate-parameter zugewiesen. Als Burst-Parameter wird die maximale Best-Effort-Paketgröße zugewiesen. Diese entspricht der für das Best-Effort-Device konfigurierten MTU plus Präambel, Header, CRC und IFG. Der Eltern-QDisc wird ein Filter angefügt, der die Pakete nach dem Wert im VID- Feld des VLAN-Tags klassifiziert. Entspricht die VID im Paket, der VID des Best- Effort-VLANs, so wird das Paket an die Klasse 2:FFFF übergeben. Der Klasse 2:FFFF wird eine SFQ-QDisc als Blatt-QDisc zugewiesen, der ein Handle automatisch vom Betriebssystem zugewiesen bekommt. Diese sorgt für Fairness zwischen den Datenströmen, die den Best-Effort-Verkehr ausmachen. QDisc-Konfiguration für Kanäle Abbildung 4.18: QDisc-Konfiguration für die Kanäle 2 (Prio 4), 3 (Prio 1), 4 (Prio7) und 5 (Prio4) 82

99 Kapitel 4. Konzept 4.7. QoS-Controller (chqoscontr) Jedes mal, wenn ein Kanal vom ersten Prozess geöffnet bzw. vom letzten Prozess geschlossen wird, muss eine Konfiguration der QDiscs vorgenommen werden. Wird ein Kanal das erste mal geöffnet, wird für ihn eine eigene Klasse an eine der HTB- QDiscs angefügt. Die Eltern-QDisc wird mit Hilfe des Prio-Parameters des Kanals gewählt. Die Major-Nummer des Handles entspricht des um eins inkrementierten Wert des Prio-Parameters. Um die Klasse zur späteren Löschung identifizieren zu können, erhält die Klasse ein Handle mit einer Minor-Nummer, die der Kanal-ID entspricht. In Abbildung 4.18 wird das Prinzip beispielhaft an vier Kanälen demonstriert. Die Kanäle mit den IDs 2 und 5 besitzen einen Priority-Wert von 4, während Kanal 4 einen Priority-Wert von 7 hat. Kanal 3 hat die niedrigste Priorität, was nach IEEE 801.1p die Priorität 1 ist. Die Eltern-QDisc der Klasse, die für den Kanal erzeugt wird, ist die gleiche wie die, der Klasse für den Best-Effort-Verkehr (blass eingezeichnet). Der Wert für den rate-parameter wird, wie in 4.4 angegeben, aus dem bandwidthund dem psize-parameter des Kanals berechnet. Jedoch muss dazu noch der Overhead durch Präambel, Start-of-Frame-Delimiter, Ethernet-Header inklusive VLAN- Tag, CRC und IFG auf die Paketgröße addiert werden. Als cburst-parameter dient der Parameter psize, der wiederum um den Overhead erhöht wird. Für jede der Klassen wird ein Filter an der Eltern-QDisc angelegt, der die Pakete anhand der letzten 12 Bit der Zieladresse im Ethernetheader klassifiziert. Entsprechen diese der ID des Kanals, für den die Klasse angelegt wurde, wird das Paket an die Klasse weitergegeben. Um die Filter zur späteren Löschung eindeutig identifizieren zu können, werden diese mit einem eindeutigen Handle angelegt und Priorität angelegt. Da die Kanäle, die diese Filter passieren, alle die gleiche Priorität haben, wird alle Filter die gleiche Priorität konfiguriert, wodurch, wie in Kapitel erläutert, nur eine Hash-Tabelle für die Filter angelegt wird. Als Handle für den Filter wird die Kanal-ID verwendet, die jedoch nur 12-Bit breit ist. Dadurch ergibt sich die obere Grenze für den Wertebereich der Kanal-IDs Es wäre zwar möglich eine Zuordnungstabelle von Kanal-IDs zu Filterhandles zu verwalten, jedoch müsste diese dann wieder Prozess-übergreifend zugreifbar sein. Um diesen Aufwand zu umgehen wurde ein verminderter Wertebereich für die Kanal-IDs in Kauf genommen. Als Blatt-QDisc kommt eine pfifo-qdisc zum Einsatz, deren Handle automatisch zugewiesen wird, da diese beim Löschen der Klasse automatisch mit entfernt wird. 83

100 4.7. QoS-Controller (chqoscontr) Kapitel 4. Konzept 84

101 Kapitel 5 Implementierung In diesem Kapitel wird die prototypische Implementierung des im Kapitel 4 besprochenen Designs behandelt. Da das objekt-orientierte Konzept in der prozeduralen Programmiersprache C umgesetzt wurde, sind ein paar Dinge anzumerken. Alle Utility-Klassen sind als globale, statische Variablen und Funktionen in einem jeweils getrennten Modul umgesetzt worden. Die aus der Objekt-Orientierten Softwareentwicklung bekannte Vererbung von Klassen, ist in der prozeduralen Programmiersprache C nicht im klassischen Sinne umsetzbar. Die im Klassendiagramm verwendeten, ableitbaren Klassen bieten im wesentlichen die Möglichkeit, abstrakte Methoden auf verschiedene Weise zu implementieren. Diese Methoden werden in C durch Zeiger auf Funktionen realisiert. Es werden verschiedene Implementierungen einer solchen Funktion mit gleichen Parametern und Rückgabetypen erstellt. Zur Laufzeit wird ermittelt, welche Implementierung der Funktionen genutzt werden soll und deren Adresse im Zeiger gespeichert. Im Folgenden wird kurz auf die Implementierungsumgebung eingegangen. Danach werden die einzelnen Module der Bibliothek in den entsprechenden Abschnitten genauer betrachtet. Module wie Konfigurationsbibliotheken, die semantisch einem anderen Modul untergeordnet sind, werden in den Unterabschnitten der jeweiligen Hauptmodule behandelt. Abschließend wird deren Implementierungsaufwand inklusive Kommentaren aufgezeigt. 85

102 5.1. Implementierungsumgebung Kapitel 5. Implementierung 5.1 Implementierungsumgebung Die Implementierung wird auf einem Rechner mit Intel Celeron 2,8GHz und 512 MB RAM durchgeführt, auf dem eine Debian Linux Distribution in der Version 3.1 installiert wurde. An der Standard Kernelkonfiguration werden folgende Optionen verändert: Die Option CONFIG_PREEMPT wird entfernt, da das Modul 8021q sonst bei atomaren Vorgängen unterbrochen wird, was zu Kernel Panics führt. Das Linux Advanced Router Modul wird, durch Entfernen der Option CONFIG_IP -_ADVANCED_ROUTER, aus dem Kernel herausgenommen. Um das Propagieren von IPv6-Routing-Informationen zu unterbinden, wird die CONFIG_IPV6-Option entfernt. Als Entwicklungsumgebung dient eine Kombination aus dem Editor vim und dem Compiler gcc Zum Auswerten der Konfigurationsdatei, werden das parser- und das tree-modul der Bibliothek libxml2 genutzt. Bei der Konfiguration der Queueing-Disziplinen werden, zum Aufbauen und Versenden der Netlink-Messages, Teile des Quellcodes des Programms TC verwendet. Dieses ist Teil der iproute2-utility-suite [ipr], welche unter der GNU-Public-License- 2 veröffentlicht ist. Für die Messung der Ende-zu-Ende Propagationszeit, hat Dipl. Inf. Bernhard Gelling eine Messbibliothek zur Verfügung gestellt. 5.2 chconfread Die Konfigurationsdatei wird mit Hilfe des XML-Parsers aus der Bibliothek libxml2 eingelesen und mit dem tree-modul der Bibliothek, in einer Baumstruktur abgebildet. Danach wird der Aufbau der Datei verifiziert 1 und die Position benötigter Knotenpunkte des Baums in Zeigern abgelegt. 1 Es wird darauf hingewiesen, dass der Aufbau nicht über eine DTD-Datei, sondern durch den Sourcecode selbst verifiziert wird 86

103 Kapitel 5. Implementierung 5.3. chcontr Implementierungsaufwand Datei Zeilen (ohne Kommentare) chconfread.h 10 chconfread.c 256 xmlnav.h 11 xmlnav.c 83 Gesamt 360 Tabelle 5.1: Implementierungsaufwand chconfread 5.3 chcontr In der Header-Datei der Bibliothek sind eine Reihe von Rückgabewerte definiert, um aufgetretene Fehler in den Funktionen näher zu spezifizieren (Listing 5.1). Bei einem Fehler in der Bibliothek werden diese als Negativwerte zurückgeliefert. Quelltext 5.1: Fehlerrückgabewerte 1 enum { 2 NO_ERR = 0, // Kein Fehler 3 ERR_NOT_SPEC, // Nicht näher spezifizierter Fehler 4 ERR_AVAIL_TABLE_FULL, // Shared - Memory ist voll 5 ERR_AVAIL_TABLE_EMPTY, // Es existiert kein Eintrag im Shared - Memory 6 ERR_INVAL_CH_ID, // Die Kanal - ID kann ( noch ) nicht eingesetzt werden 7 ERR_INVAL_MODE, // Kommunikationsmodus existiert nicht 8 ERR_INVAL_SIZE, // Übergebene Payload größer als zugelassen 9 ERR_CH_OPEN, // Der Kanal ist bereits geöffnet 10 ERR_CH_OCCUPIED, // Der Kanal ist bereit besetzt 11 ERR_CH_NOCCUPIED, // Der Kanal ist nicht besetzt 12 ERR_CH_NOT_EXIST, // Der Kanal ist nicht für den Einsatz vorgesehen 13 ERR_NO_QOS_INIT, // Bibliothek wurde noch nicht initialisiert 14 ERR_QOS_INIT_CALLED, // Bibliothek wurde bereits initialisiert 15 ERR_NO_XML_FILE, // Pfad zur Konfigurationsdatei ist falsch 16 ERR_INVAL_XML_FILE, // Aufbau Konfigurationsdatei ist falsch 17 ERR_INVAL_DEVICE, // Netzwerk - Device existiert nicht 18 ERR_INVAL_ADDRTYPE, // Adresstyp wird nicht unterstützt 19 ERR_NO_LOCAL_MEM, // malloc () ist fehlgeschlagen 20 ERR_SYSCALL, // Ein Systemcall ist fehlgeschlagen 21 ERR_AVAIL_ENTRY_OCC // Es existiert schon ein Eintrag für diesen Kanal im ShM 22 }; Alle Funktionen der Bibliothek werden entsprechend der Kollaborationsdiagramme aus Kapitel 4.3 umgesetzt. In der Initialisierungsfunktion initchannels() wird zunächst ermittelt, ob die Bi- 87

104 5.3. chcontr Kapitel 5. Implementierung bliothek, und damit alle globalen Betriebsmittel, schon von einem anderen Prozess initialisiert wurde. Dies geschieht indem das Semaphor, das das Shared-Memory- Segment schützen soll, mit einem festen Schlüssel und den Flags IPC_CREAT und IPC_EXCL aufgerufen wird. Kommt es dabei zum Fehler und der Inhalt der globalen Variablen errno entspricht EEXIST, wird davon ausgegangen, dass der Erstzugriff auf die Bibliothek schon durch einen anderen Prozess erfolgt ist. In diesem Fall bekommt die globale Variable first den Wert FALSE zugewiesen, die jeder init-funktion der anderen Contr-Klassen als Parameter übergeben werden. Für die Funktion chopen() wird ein mode-parameter deklariert, der in zwei 16-Bit Felder geteilt ist. Die oberen 16-Bit sind für Flags reserviert. Zur Zeit der Arbeit ist nur das USE_THREADS-Flag definiert, welches signalisiert, dass es sich, bei dem auf die Bibliothek zugreifenden Prozess, um eine multi-threaded Anwendung handelt und somit der Sendezugriff auf den Kanalendpunkt wechselseitig ausgeschlossen werden muss. Die unteren 16-Bit bestimmen den Kommunikationsmodus des Kanals. Bisher sind zwei Kommunikationsmodi definiert: CH_BASIC_MODE und CH_TEST_MODE. Die beiden Modi werden in Abschnitt 5.6 und Kapitel 6.3 näher erklärt. Aufgrund des Kommunikationsmodus bekommt das chdescr-objekt seine send()- und recv()-methoden zugewiesen (Listing 5.2). Quelltext 5.2: Zuweisung der Kommunikationmethoden 1 switch ( mode & 0 xffff ) { 2 case CH_BASIC_MODE : 3 channel - > send = basicmodesend ; 4 channel - > recv = basicmoderecv ; 5 break ; 6 # ifdef _CH_TEST_ 7 case CH_TEST_MODE : 8 channel - > send = testmodesend ; 9 channel - > recv = testmoderecv ; 10 break ; 11 # endif 12 default : 13 releasechannel ( channel ); 14 unregisterchannel ( id); 15 return - ERR_INVAL_MODE ; 16 } Bei der Registrierung des Kanalendpunkts wird der Methode registerchannel() ein synckey-parameter per Referenz mit übergeben. Existiert ein Schlüssel für den Kanal, wird er in den Parameter eingetragen. Mit dem Schlüssel wird eine Verbindung zum Semaphor geöffnet. Kann nur ein Prozess auf einen Kanal zugreifen, wird 0 88

105 Kapitel 5. Implementierung 5.3. chcontr in den synckey eingetragen, was signalisiert, dass kein Semaphor für diesen Kanal existiert. Nutzt der Prozess jedoch Threads, so muss auch hier der wechselseitige Ausschluss beim Senden gewährleistet sein. Dazu muss beim Öffnen des Kanalendpunktes das USE_THREADS-Flag gesetzt werden, welches die chopen-methode veranlasst, ein lokales Semaphor mit dem Schlüssel IPC_PRIVATE zu erzeugen. Ist das Flag gesetzt und ein Prozesszugriff von mehr als einem Prozess ist erlaubt, wird das Prozess-übergreifende Semaphor für den Kanalendpunkt genutzt. Der Vorgang ist in Abbildung 5.1 dargestellt. Abbildung 5.1: Semaphore für Prozess- und Threadsynchronisation Nachdem der Socket des chdescr-objekts an das Device gebunden ist, wird ihm die für den Kanal definierte Priorität zugewiesen (Listing 5.3). Quelltext 5.3: Setzen der Socket-Priotität 1 if( setsockopt ( channel - >sock, SOL_SOCKET, SO_PRIORITY, ( const void *)& prio, sizeof ( prio )) < 0) { 2 return -1; 3 } Die Liste der chdescr-objekte wird in dem dafür implementierten Modul chcontain eingefügt. Auf dieses Modul wird im Folgenden eingegangen. chcontain Das chcontain-modul implementiert einen Container für die chdescr-objekte. Da die Objekte für jeden Kommunikationsvorgang benötigt werden, ist ein schnellst- 89

106 5.3. chcontr Kapitel 5. Implementierung möglicher Zugriff auf die Objekte nötig. Eine einfache Liste, die sequenziell durchsucht werden müsste, kann daher nicht eingesetzt werden. Am besten wäre die direkte Abbildung der Kanal-ID auf eine Speicheradresse, jedoch würde ein Array aus Zeigern mit 2 12 Einträgen alleine 4kByte Speicher belegen, ohne auch nur ein Objekt zu referenzieren. Eine Hash-Tabelle würde einen kollisionsfreien Hash-Algorithmus voraussetzen und, je nach Dimensionierung der Tabelle, wiederum zu Suchoperationen führen. Abbildung 5.2: Speichermodell für chdescr-objekte Die implementierte Lösung sieht ein dynamisch angelegtes, zweidimensionales Array mit Zeigern auf chdescr-objekte vor (Abbildung 5.2). Die Indizierung erfolgt über die Kanal-ID, die über einen Offset in zwei Segmente geteilt wird. In der Implementierung wird ein Offset von 5 gewählt, was eine Verhältnis von 128 auf 32 Einträgen bedeutet. Um den Speicherbedarf gering zu halten, werden nur die Arrays der zweiten Dimension erzeugt, die benötigt werden. Desweiteren wird für das erste Array nur so viel Speicher allokiert, wie zur Haltung der benötigten Arrays der zweiten 90

107 Kapitel 5. Implementierung 5.3. chcontr Dimension erforderlich ist. So ist die optimale Speicherausnutzung abhängig von der Distanz zwischen den einzelnen Kanal-IDs. Für 32 chdescr-objekte die von 0 bis 31 sequenziell durchnummeriert sind, würde die Tabelle 132 Byte groß sein 2. Die Größe würde jedoch auf 4224 Byte ansteigen, wenn die IDs der 32 Objekte jeweils eine Distanz von 32 aufweisen würden 3. Das ist generell nicht problematisch, sollte jedoch berücksichtigt werden, wenn der Speicheroverhead gering gehalten werden soll. In Listing 5.6 werden die Makros zur Umrechnung der Kanal-ID auf die Indizes und zur Bestimmung der Größe des Arrays der zweiten Dimension gezeigt. Quelltext 5.4: Makros zur Umrechnung der Indizes in chcontain 1 # define ID_OFFSET (( unsigned short ) 5) 2 # define LDSEG ( x) (( x) >> ID_OFFSET ) // Leading Segment 3 # define TRSEG ( x) (( x) & ~(( unsigned short ) 0 xffff << ID_OFFSET )) // Trailing Segment 4 # define TRSEGSIZ (( unsigned short )(1 << ID_OFFSET )) Mit der Funktion insertchanneldescr()werden chdescr-objekte der Tabelle hinzugefügt. Zunächst wird geprüft, ob der errechnete, obere Index größer ist, als die Anzahl der allokierten Array-Elemente. Ist das der Fall, wird das Array mit realloc() mit der erforderlichen Größe neu allokiert und die neu hinzugewonnenen Zeiger im Array mit NULL initialisiert. Quelltext 5.5: Stufenweises Allokieren in chcontain 1 if( LDSEG ( channel - >id) >= tablesize ) { 2 if( chdescrtable!= NULL ) { 3 memoffset = tablesize ; 4 } 5 tablesize = LDSEG ( channel - >id) +1; 6 7 chdescrtable = realloc (( void *) chdescrtable, tablesize * sizeof ( struct chdescr **) ) ; 8 if( chdescrtable == NULL ) { 9 tablesize = memoffset ; 10 return - ERR_NO_LOCAL_MEM ; 11 } for (; memoffset < tablesize ; memoffset ++) { 14 chdescrtable [ memoffset ] = NULL ; 15 } 16 } Byte + 4Byte für das erste Array der Größe Byte Byte 91

108 5.3. chcontr Kapitel 5. Implementierung Danach wird geprüft, ob der Zeiger des oberen Index auf NULL zeigt. Ist dies der Fall, wird der Speicher für ein neues Array allokiert und dessen Felder mit NULL initialisiert. Ist die Position mit den für die ID ermittelten Indizes noch nicht belegt, wird der Speicher für ein neues chdescr-objekt allokiert und die Daten des übergebenen Objekts kopiert. Ist die Position schon belegt wird -ERR_CH_OCCUPIED zurückgeliefert, ansonsten 0. Mit der Funktion getchanneldescr() wird der Zeiger auf ein gespeichertes Objekt angefordert. Durch die Art der Speicherung kann die Position mit nur drei Instruktionen abgefragt werden. Existiert das Objekt nicht, wird der NULL-Zeiger zurückgeliefert. Die Funktion removechanneldescr()entfernt einen einzelnen Eintrag aus der Tabelle, wobei dessen Speicher freigegeben wird. Jedoch wird nicht geprüft, ob der Eintrag der letzte war, und somit eines der Arrays freigegeben werden könnte. Ist kein Eintrag an der Stelle vorhanden, wird -ERR_INVAL_CH_ID und ansonsten 0 zurückgeliefert. Die Funktion getnextchanneldescr()kann zum sequentiellen Abrufen der gespeicherten Elemente genutzt werden. Mit jedem Aufruf wird ein Iterator übergeben, der die Stelle markiert, ab der nach dem nachfolgenden Element gesucht werden soll. Wird ein Objekt gefunden, wird der Zeiger auf dessen Speicheradresse zurückgeliefert und der Parameter iterator auf die aktuelle Position gesetzt. Befindet sich kein Objekt mehr hinter der angegeben Position, wird NULL zurückgeliefert. Wird mit jedem neuen Aufruf der Iterator des letzten Aufrufs übergeben, wird die Liste sequenziell durchlaufen. Um die Suche am Anfang der Tabelle zu beginnen, muss dem Iterator ein Wert von -1 zugewiesen werden. Implementierungsaufwand Datei Zeilen (ohne Kommentare) channel.h 51 chcontr.c 402 chcontain.h 11 chcontain.c 184 Gesamt 648 Tabelle 5.2: Implementierungsaufwand chcontr 92

109 Kapitel 5. Implementierung 5.4. chdescr 5.4 chdescr Quelltext 5.6: Die chdescr-struktur 1 struct chdescr { 2 unsigned short id; 3 int prio ; // Usr Priority 4 unsigned long delay ; // usec 5 unsigned long jitter ; // usec 6 unsigned long bandwidth ; // Pakets /s 7 unsigned short psize ; // PayloadSize [ Byte ] 8 int mode ; // Kommunikationsmodus 9 int sem ; // Synchronisationsobjekt 10 int sock ; // Kommunikationsobjekt 11 unsigned int seq ; // Bisher gesendete Pakete 12 struct sockaddr * sendaddr ; // Mcast - Addr 13 socklen_t addrlen ; // Länge von sendaddr 14 int (* send )( struct chdescr * channel, void * buf, size_t size ); 15 int (* recv )( struct chdescr * channel, void * buf, size_t size ); 16 }; Die chdescr-struktur hält alle Informationen, die mit dem Kanalendpunkt assoziiert werden. mode wird von der Funktion chopen() des chcontr-moduls gesetzt und entspricht dem Parameter der gleichen Bezeichnung. Das Kommunikationsobjekt ist in Form des Socket-File-Deskriptors(sock), der sockaddr -Struktur und den Zeigern auf die Funktionen (*send)() und (*recv)() in die Struktur integriert. Die Einbindung des Members addrlen ist vorgesehen, da bei verschiedenen Layer-2-Protokollen unterschiedliche sockaddr-strukturen eingesetzt werden, deren Größe variiert. Aus diesem Grund kann keine statische sockaddr-struktur eingefügt werden, sondern ein Zeiger. Das Datenmember sem hält den Deskriptor des Semaphors, dass als Synchronisationsobjekt dient. Beim Anlegen der chdescr-objekte werden zunächst nur die ID und die QoS-Parameter initialisiert. Solange der Kanalendpunkt geschlossen ist, bleiben sock und sem auf 0 bzw. -1. Im chdescr-modul sind die Basis-Kommunikationsfunktionen basicmodesend() und basicmoderecv() implementiert, die den Methoden (*send)() und (*recv)() zugewiesen werden, wenn beim Öffnen des Kanals CH_BASIC_MODE übergeben wird (Listing 5.2). 93

110 5.5. chavailcontr Kapitel 5. Implementierung Implementierungsaufwand Datei Zeilen (ohne Kommentare) chdescr.h 36 chdescr.c 40 Gesamt 76 Tabelle 5.3: Implementierungsaufwand chdescr 5.5 chavailcontr Bei der Initialisierung des Moduls wird eine boolsche Variable im Parameter initshm übergeben. Ist diese auf TRUE gesetzt, wird das Shared-Memory-Segment erzeugt und mit 0 initialisiert. Ansonsten wird das existierende Shared-Memory-Segment in den lokalen Adressraum eingeblendet. Wird mittels der Funktion addchavailentry() ein neuer Eintrag dem Shared-Memory- Segment hinzugefügt, wird überprüft, ob mehr als ein Prozess auf den Kanal, für den dieser Eintrag gilt, zugreifen darf. Ist das der Fall, wird für den Kanal ein Semaphor erzeugt und dessen Erzeugungsschlüssel im Eintrag abgelegt. Beim Befüllen des Shared-Memory-Segments mit chavail-einträgen wird eine Fehlermeldung ausgegeben, falls das Ende des Segments erreicht wird. Um festzustellen wo sich der nächste freie Eintrag befindet, macht sich das Programm zunutze, dass kein Kanal mit der ID 0 existieren kann und das Shared-Memory-Segment mit Null initialisiert wird. Listing 5.7 zeigt die dafür verwendete Suchschleife. Quelltext 5.7: Suchschleife in chavailcontr 1 for ( i = 0; ( chavailtable [ i]. id!= 0) ( sizeof ( struct chavail ) > ( PAGE_SIZE - i* sizeof ( struct chavail )); i ++) { } Beim Schließen der Bibliothek wird am Shared-Memory-Segment überprüft, ob der aufrufende Prozess der letzte darauf zugreifende ist. Dies geschieht durch einen Aufruf des Systemcalls shmctl() wie in Lisiting 5.8 dargestellt. Quelltext 5.8: Abruf der Shm-Statistiken 1 shmctl ( shmid, IPC_STAT, & shmparam ); 94

111 Kapitel 5. Implementierung 5.6. chdev Im shmparam.shm_nattach ist daraufhin die Anzahl der auf das Shared-Memory- Segment zugreifenden Prozesse zu finden. Ist der Prozess der letzte zugreifende, so werden die Semaphoren aller Kanäle und das Shared-Memory-Segment zerstört. Implmentierungsaufwand Datei Zeilen (ohne Kommentare) chavailcontr.h 30 chavailcontr.c 245 Gesamt 275 Tabelle 5.4: Implementierungsaufwand chavailcontr 5.6 chdev Im Klassendiagramm wird gezeigt, dass die Utitltiy-Klasse chdev über zwei abstrakte Methoden verfügt, die durch Ableitung der Klasse überschrieben werden können. Im Modul chdev sind die zwei statischen, globalen Zeiger (*bindchannelp)() und (*releasechannelp)() deklariert, die diese abstrakten Methoden repräsentieren. Bei Initialisierung wird der Adresstyp des Devices ermittelt, dessen Namen als Parameter der Funktion initdev übergeben wird. Aufgrund des Adresstyps wird ermittelt welche Implementierungen der Funktionen bindchannel() und releasechannel() den Zeigern zugewiesen werden. vlan Handelt es sich bei dem Adresstyp um Ethernet, werden die virtuellen Devices erzeugt. Alle dafür nötigen ioctl()-zugriffe werden von der dafür implementierten Konfigurationsbibliothek vlan gekapselt. Nach oben bietet die Bibliothek sowohl Funktionen zum Anlegen und Löschen von virtuellen Devices, als auch zum Setzen der Ingress- und Egress-Priority-Maps. Eine Besonderheit stellt die Funktion addbe_vlan() dar, da sie ein virtuelles Device erzeugt, das die IP-Adresse des physikalischen Devices auf das virtuelle überträgt und dessen MTU setzt. Die Funktion rembe_vlan() macht diese Konfigurationen wieder rückgängig. 95

112 5.6. chdev Kapitel 5. Implementierung devinfo Das devinfo-modul definiert die Struktur devinfo, die Name, Index und Addresstyp eines Devices enthält. Zum Abrufen dieser Daten ist die Funktion initdevinfo() definiert, die diese über ioctl()-aufrufe bezieht. cheth Dieses Modul definiert die Funktionen chethbind()und chethrealease(), welche die Ethernet-spezifischen Implementationen bindchannel() und releasechannel() -Methoden sind. Man kann im objekt-orientierten Sinne davon sprechen, dass cheth eine abgeleitete Klasse von chdev ist. Die Funktion chethbind() öffnet einen Paket-Socket und weißt den zurückgegebenen Socket-Fileskriptor den sock-member derchdescr-struktur zu, die als Parameter übergeben wurde. Anschließend wird eine sockaddr_ll-struktur allokiert und dem addr-member zugewiesen. Diese Struktur ist speziell für Packet-Sockets spezifiziert und erhält als Adressinformationen die Multicast-Adresse des Kanals und den Index des virtuellen Devices. Mit diesen Daten wird der Socket an das Device gebunden und anschließend in eine Multicast-Gruppe im Treiber eingetragen. Die Funktion chethrelease() entfernt den Socket wieder aus der Multicast-Gruppe und schließt ihn. Anschließend gibt er den Speicher des addr-members frei. Datei Zeilen (ohne Kommentare) chdev.h 11 chdev.c 125 cheth.h 9 cheth.c 135 devinfo.h 11 devinfo.c 125 vlan.h 11 vlan.c 295 Gesamt 722 Tabelle 5.5: Implementierungsaufwand chdev 96

113 Kapitel 5. Implementierung 5.7. chqoscontr 5.7 chqoscontr Bei Initialisierung des chqoscontr-moduls wird zunächst die Kommunikationsverbindung zum Kern aufgebaut. Zu diesem Zweck wird die in der iproute2-utility-suite beiliegende libnetlink-bibliothek integriert. Mit der Funktionrtnl_open() wird eine globale rtnl_handle-struktur initialisiert, die für die gesamte Kommunikation genutzt wird. Eine andere Funktion, die von iproute2 übernommen wird, ist tc_core_init(), die die in Kapitel beschriebenen Timer-Werte initialisiert. Wie in Kapitel 4.7 erläutert wird, sind die Filtereinstellungen von dem verwendeten Layer-2-Protokoll abhängig. Daher werden in der initqos() die Filterregeln für die Filter der Prio-Klassen, der Best-Effort-Klasse und der einzelnen Kanal-Klassen abhängig vom Adresstyp des verendeten Devices initialisiert. Der Wert des Best- Effort-Filters ist fest (VID 3), die Werte der Prio- und Kanal-Filter jedoch sind Variabel (User Prio bzw. Kanal ID). Daher bekommen sie zu Anfang keinen Wert in für.val zugewiesen, sondern in einer eigenen Variablen einen Bit-Shift-Offset, der anzeigt wo in dem 32 Bit breiten Suchmuster, sich der zu suchende Wert befinden muss, um erkannt werden zu können. An der Funktion initqos() wird nun exemplarisch die Konfiguration von QDiscs, Klassen und Filtern gezeigt. Für die Funktionen addchqos() und remchqos() sei nur erwähnt, dass diese die Konfiguration wie in Kapitel 4.7 vorgesehen durchführen. In Listing 5.9 zeigt, wie das für den Filter der Prio-QDisc umgesetzt wurde. Quelltext 5.9: Filter-Selector für Prio-QDisc 1 prsel. sel. nkeys = 1; // Prio - Filter (User - Priority in VLAN - Tag ) 2 prsel. keys [0]. mask = htonl (0 xe ); 3 prsel. keys [0]. val = 0; 4 prseloff = 29; // Anzahl der Bit um die geshiftet werden muss Die Listings 5.10, 5.12 und 5.13 zeigen die QDisc-Basis-Konfiguration, wie sie in Kapitel 4.7 beschrieben ist. In Listing 5.10 wird die Prio-QDisc mit acht Bändern parametrisiert und dann konfiguriert. 97

114 5.7. chqoscontr Kapitel 5. Implementierung Quelltext 5.10: Hinzufügen der Prio-QDisc 1 prio_opt. bands = 8; 2 if( addqdisc (& rth, TC_H_ROOT, 0 x7fff0000, prio, ( void *) & prio_opt, devindex ) < 0 ) { 3 rtnl_close (& rth ); 4 return -1; 5 } Danach werden die HTB-QDiscs und der Filter für jede Klasse der Prio-QDisc hinzugefügt (Listing 5.12). Zeile 2 zeigt wie der User-Priority-Wert (userprio), mit Hilfe des Arrays aus Listing 5.11, auf die Minor-Nummern der Prio-Klassen abgebildet wird. In Zeile 9 wird das Suchmuster für jeden Filter berechnet, indem der User- Priority-Wert, um die in Listing 5.9 definierten Anzahl Bits, nach links verschoben wird. Quelltext 5.11: User-Priority auf Prio-QDisc Mapping 1 static unsigned char priomap [8] = { 2 // UP Handle 3 6, // , // , // , // , // , // , // // }; Quelltext 5.12: Basis-QDiscs und Filter 1 for ( userprio = 0; userprio < 8; userprio ++) { 2 parent = 0 x7fff priomap [ userprio ]; 3 handle = ( userprio +1) << 16; 4 5 if( addqdisc (& rth, parent, handle, htb, ( void *) & htb_opt, devindex ) < 0) { 6 rtnl_close (& rth ); 7 return -1; 8 } 9 prsel. keys [0]. val = htonl ( userprio << prseloff ); 10 flowid = parent ; 11 if( addfilter (& rth, 0 x7fff0000, 0, flowid, ETH_P_8021Q, priomap [ userprio ], u32, & prsel, devindex ) < 0) { 12 rtnl_close (& rth ); 13 return -1; 14 } 15 } Nachdem die Grundkonfiguration von QDiscs und Filtern erfolgt ist, wird noch die Klasse und der Filter für den Best-Effort-Verkehr hinzugefügt (Listing 5.13). In den 98

115 Kapitel 5. Implementierung 5.7. chqoscontr Zeilen 1 bis 4 wird gezeigt, wie die Parameter der HTB-Klasse nach den Vorgaben in Kapitel 4.7 zugewiesen werden. Die Parameter sind im Einzelnen in Kapitel beschrieben. Der Quelltext der Funktion get_cell_log() entstammt der Funktion tc_calc_rtable(). Diese ist in der Datei tc core.c implementiert und ist Teil der iproute2-utility-suite. Sie wird kopiert und in die zwei einzelnen Funktionen get_cell_log() und calc_rtable() unterteilt, damit deren Funktionalitäten separat verfügbar sind. get_cell_log() generiert den binären Logarithmus der maximalen Tokengröße, in Abhängigkeit von der maximalen Paketgröße, wie in Kapitel beschrieben. Die Funktion calc_rtable() errechnet die Rate-Table für eine HTB-Klasse. Sie wird bei der Generierung von Netlink-Messages für diese Klasse eingesetzt, was in Listing 5.18 gezeigt wird. Abschließend wird noch die SFQ-QDisc und der Filter für den Best-Effort-Verkehr hinzugefügt. Quelltext 5.13: Hinzufügen der Best-Effort-Klasse 1 htb_copt. rate. cell_log = get_cell_log ( mtu + FRM_OVRHD ); 2 htb_copt. rate. mpu = mpu ; 3 htb_copt. rate. rate = maxbw ; 4 htb_copt. cbuffer = mtu + FRM_OVRHD ; 5 6 if( addclass (& rth, 0 x , 0 x0002ffff, htb, ( void *) & htb_copt, devindex ) < 0) { 7 rtnl_close (& rth ); 8 return -1; 9 } sfq_opt. perturb_period = 10; if( addqdisc (& rth, 0 x0002ffff, 0 x , sfq, ( void *) & sfq_opt, devindex ) < 0) { 14 rtnl_close (& rth ); 15 return -1; 16 } if( addfilter (& rth, 0 x , 0 x , 0 x0002ffff, ETH_P_8021Q, 8, u32, ( void *) & besel, devindex ) < 0) { 19 rtnl_close (& rth ); 20 return -1; 21 } 99

116 5.7. chqoscontr Kapitel 5. Implementierung qdisc und filter Für die Konfiguration der Queueing Disziplinen, sowie deren Klassen und Filter, wird eine eigene Bibliothek implementiert, die Funktionen zum Hinzufügen und Löschen bietet. Diese Funktionen sind sich im Aufbau sehr ähnlich und werden im Folgenden an der Funktion addqdisc() erläutert (Listings 5.14 und 5.15). Zunächst wird eine Request-Struktur (req) deklariert, die ein Netlink-Message inklusive Netlink-Header, tc-message und Speicher für Attrtbute reserviert. Die Member der Struktur bekommen Werte, entsprechend der in Kapitel qdiscconf erläuterten Konfigurationsbeschreibung, zugewiesen. Quelltext 5.14: Setzen der QDisc-Basis-Parameter 1 memset (& req, 0, sizeof ( req )); 2 req. nlh. nlmsg_len = NLMSG_LENGTH ( sizeof ( struct tcmsg )); 3 req. nlh. nlmsg_type = RTM_NEWQDISC ; 4 req. nlh. nlmsg_flags = NLM_F_REQUEST NLM_F_EXCL NLM_F_CREATE ; 5 6 req. tcm. tcm_family = AF_UNSPEC ; 7 req. tcm. tcm_ifindex = devindex ; 8 req. tcm. tcm_handle = handle ; 9 req. tcm. tcm_parent = parent ; Welche QDisc erzeugt werden soll, wird mit dem Parameter qdisc bestimmt. Aufgrund dessen Wert wird eine QDisc spezifische Netlink-Message generiert. Quelltext 5.15: Generieren der Netlink-Message 1 switch ( qdisc ) { 2 case prio : 3 genprionlmsg (& req. nlh, ( struct tc_prio_qopt *) param ); 4 break ; 5 case htb : 6 genhtbnlmsg (& req. nlh, ( struct tc_htb_glob *) param ); 7 break ; case sfq : 12 gensfqnlmsg (& req. nlh, ( struct tc_sfq_qopt *) param ); 13 break ; 14 default : 15 return -1; 16 } 17 } Abschließend wird die Message über die Funktion rtnl_talk() aus der Bibliothek 100

117 Kapitel 5. Implementierung 5.7. chqoscontr libnetlink an den Kernel gesandt. Quelltext 5.16: Versenden der Netlink-Message 1 2 if( rtnl_talk (rth, & req.nlh, 0, 0, NULL, NULL, NULL ) < 0) { 3 return -1; 4 } 5 return 0; 6 } Die Funktionen zum Generieren von Netlink-Messages, übernehmen die für sie definierten Strukturen und fügen je nach verwendeter QDisc Attribute hinzu. Dazu wird die Funktion addattr_ll() genutzt, die ebenfalls Bestandteil der libnetlink- Bibliothek ist. In Listing 5.17 wird gezeigt, wie die Attribute für die SFQ-QDisc in der Funktion gensfqnlmsg() hinzugefügt werden. Quelltext 5.17: Hinzufügen von Attributen 1 int gensfqnlmsg ( struct nlmsghdr *n, struct tc_sfq_qopt * opt ) { 2 addattr_l (n, 1024, TCA_KIND, " sfq ", 4); 3 addattr_l (n, 1024, TCA_OPTIONS, opt, sizeof ( struct tc_sfq_qopt )); 4 return 0; 5 } Die Generierung von Attributen der HTB-Klasse gestaltet sich etwas komplizierter. Für sie müssen noch die beiden Rate-Tabellen erzeugt werden und die angegebenen burst und cburst-parameter in Sendezeiten umgewandelt werden, wie es im Kapitel beschrieben wurde. Dies geschieht mit der Funktion calc_rtable(), die, wie schon vorher im Abschnitt erwähnt, aus der Funktion tc_calc_rtable ausgeschnitten wurde. Ist der Parameter buffer kleiner als der berechnete Mindestwert, wird der Mindestwert zugewiesen. Die Byte-Werte für buffer und cbuffer werden mit der Funktion tc_calc_xmittime () aus der iproute2-utility-suite in die Sendezeit umgerechnet. Anschließend werden alle Attribute an die Netlink-Message angehängt. Quelltext 5.18: Generieren einer Netlink-Message für eine HTB-Klasse 1 int genhtbclassnlmsg ( struct nlmsghdr *n, struct tc_htb_opt * opt ) 2 { 3 u32 rtab [256], ctab [256]; 4 unsigned buffer =0, cbuffer =0; 5 struct rtattr * tail ; 6 7 if (! opt -> ceil. rate ) opt -> ceil = opt -> rate ; 8 9 buffer = opt -> rate. rate / get_hz (); // min ; 101

118 5.7. chqoscontr Kapitel 5. Implementierung 10 if (opt -> buffer > buffer ) 11 buffer = opt - > buffer ; cbuffer = opt - > cbuffer +50; calc_rtable (& opt ->rate, rtab ); 16 opt -> buffer = tc_calc_xmittime (opt -> rate.rate, buffer ); calc_rtable (& opt ->ceil, ctab ); 19 opt -> cbuffer = tc_calc_xmittime (opt -> ceil.rate, cbuffer ); addattr_l (n, 1024, TCA_KIND, " htb ", 3); 22 tail = ( struct rtattr *) ((( void *)n)+ NLMSG_ALIGN (n-> nlmsg_len )); 23 addattr_l (n, 1024, TCA_OPTIONS, NULL, 0); 24 addattr_l (n, 2024, TCA_HTB_PARMS, opt, sizeof ( struct tc_htb_opt )); 25 addattr_l (n, 3024, TCA_HTB_RTAB, rtab, 1024) ; 26 addattr_l (n, 4024, TCA_HTB_CTAB, ctab, 1024) ; 27 tail -> rta_len = ((( void *)n)+ NLMSG_ALIGN (n-> nlmsg_len )) - ( void *) tail ; 28 return 0; 29 } Datei Zeilen (ohne Kommentare) chqoscontr.h 10 chqoscontr.c 341 qdisc.h 21 qdisc.c 208 filter.h 13 filter.c 108 qfifo.h 7 qfifo.c 19 qsfq.h 6 qsfq.c 13 qprio.h 6 qprio.c 16 qhtb.h 7 qhtb.c 78 fu32.h 11 fu32.c 36 Gesamt 900 Tabelle 5.6: Implementierungsaufwand chqoscontr 102

119 Kapitel 5. Implementierung 5.8. Testapplikation 5.8 Testapplikation Zum Testen der Basisfunktionalität der Bibliothek steht die menügeführte Applikation channelapp zur Verfügung. Mit ihr lassen sich die Bibliothek und Kanäle öffnen und schließen, sowie einzelne Pakete versenden und empfangen. Durch mehrere Instanzen ist der wechselseitige Ausschluss für den Kanalzugriff validierbar. Um die Konfiguration der Queueing-Disziplinen zu prüfen, kann das Tool TC eingesetzt werden. Im Folgenden sollen die wichtigsten Befehle zur Überprüfung der Konfiguration genannt werden: 1 # tc [- s] qdisc sh [ dev <devname >] 2 # tc [- s] class sh dev <devname > 3 # tc filter sh dev <devname > [ parent <handle >] Der erste Befehl zeigt die Liste der angelegten QDiscs an. Mit der Option -s werden noch statistische Informationen, wie die Anzahl Pakete und Bytes, die die QDisc passiert haben, angezeigt. Der zweite Befehl zeigt die erzeugten Klassen an. Hier muss darauf geachtet werden, dass der Device-Name spezifiziert wird, da sonst keine Ausgabe erfolgt. Mit dem letzten Befehl werden die angelegten Filter angezeigt. Wie bei den Klassen, muss auch hier der Device-Name angegeben werden. Der Befehl zeigt immer nur die Filter an, die an einem Knoten sitzen. Wird der Elternknoten nicht explizit angegeben, so werden die Filter an TC_H_ROOT ausgegeben. Implementierungsaufwand Datei Zeilen (ohne Kommentare) channelapp.c 127 Tabelle 5.7: Implementierungsaufwand Testapplikation 103

120 5.10. Kompilierung und Installation Kapitel 5. Implementierung 5.9 Gesamtaufwand Modul Zeilen (ohne Kommentare) chconfread 360 chcontr 648 chdescr 76 chavailcontr 275 chdev 722 chqoscontr 900 chmsr channelapp 127 msrsend 5 87 msrrecv 6 75 Gesamt 3270 Tabelle 5.8: Implementierungsaufwand chqoscontr 5.10 Kompilierung und Installation Auf der CD ist ein tar-archiv der Bibliothek enthalten, dem ein Makefile beiliegt. Im Makefile sind unter der Option LIBCFLAGS drei #define-schalter, die den Umfang des zu kompilierenden Quellcodes steuern. _EMSG_ sorgt dafür, dass für jeden Fehler eine Ausgabe auf stderr erscheint, während _DEBUG_ eine Ausgabe von Debug- Informationen auslöst, die zum Testen der Bibliothek genutzt werden. Der Schalter _CH_TEST_ entscheidet, ob die Instrumentierung des Quellcodes für die Bewertung mit in die Bibliothek eingebunden wird. Durch Ausführung von make wird die Bibliothek kompiliert. make clean entfernt alle ausführbaren Dateien und den Objektcode. Um die Bibliothek in ein Programm einzubinden, wird die Headerdatei channel.h und der Pfad zu den Bibliotheksdateien libchannel.so, libchannel.so.0 und libchannel.so.0.0 benötigt. Dieser muss mit dem Befehl export LD LIBRARY PATH=<path> bekannt gemacht werden. Außerdem müssen bei der Kompilierung die Optionen -L <path> und -lchannel angehängt werden. 4 s. Kapitel s. Kapitel s. Kapitel

121 Kapitel 5. Implementierung Aufgetretene Probleme Bei der Verwendung der Bibliothek ist unbedingt darauf zu achten, dass vor dem Beenden der Applikation die Funktion closechannels() aufgerufen wird. Geschieht dies nicht, können Betriebsmittel, wie Semaphoren, nicht freigegeben und die Einstellungen an den Queueing-Disziplinen und dem Netzwerk-Device nicht rückgängig gemacht werden. Aus diesem Grund sollten entsprechende Signale abgefangen und die Bibliothek geschlossen werden Aufgetretene Probleme Während der Implementierung sind einen Reihe von Problemen aufgetreten, die auf Eigenheiten im Betriebssystem zurückzuführen sind. Diese sollen hier mit entsprechender Lösung, falls vorhanden, vorgestellt werden. Laut der manpage packet(7) kann ein Packet-Socket, mit der Hilfe der Optionen PACKET_ADD_MEMBERSHIP und PACKET_DROP_MEMBERSHIP, explizit an eine Multicast- Adresse gebunden bzw. von einer Multicast-Adresse entbunden werden. Beim Testen der Applikation werden jedoch an einem Kanalendpunkt Nachrichten eines anderen Kanals empfangen, obwohl dessen Multicast-Adresse von keinem Kanal auf der Empfängerseite konfiguriert wurde. Die Ursache liegt in der verwendeten Netzwerkkarte und deren Linux-Treiber. Die Unterstützung von Multicast-Filterung ist von Treiber zu Treiber unterschiedlich. Diesem Problem wird aus Zeitgründen und der Tatsache, dass dessen Lösung der zentralen Kernproblemstellung der Arbeit nicht zuträglich ist, nicht weiter nachgegangen. Ein weiteres Problem ist, dass bei Sendungen von Paketen in kurzen Intervallen Kernel-Panics ausgelöst werden können. Dies liegt daran, dass niederpriore Prozesse unterbrechbar sind, selbst wenn sie sich gerade, durch Ausführung eines Systemcalls, im Kernel-Adressraum aufhalten. Das 802.1Q-Modul unter Linux ist für die Unterbrechungen nicht ausgelegt. Eine Lösung wäre es, für Prozesse, die Kanäle nutzen, einen Real-Time Scheduler einzusetzen und dem Prozess eine höhere Priorität zu verleihen. Dadurch würde der Prozess im Kern-Modus nicht mehr unterbrochen werden. Da jedoch Best-Effort-Applikationen auch über VLANs versendet werden, kann diese Option nur eingesetzt werden, wenn alle Applikationen, die Netwerkressourcen benötigen, einen höhere Priorität zugeordnet bekommen. Eine andere Lösung ist die Kernel-Option CONFIG_PREEMPT, wie in Abschnitt 5.1 angegeben, auszuschalten. Somit können niederpriore Prozesse nicht mehr im Kernel- 105

122 5.11. Aufgetretene Probleme Kapitel 5. Implementierung Modus unterbrochen werden, was bedeutet, dass leicht erhöhte Latenzen für die Aktivierung von hochprioren Prozessen auftreten können. In [Hub03] ist angegeben, dass Filter Pakete an Klassen über mehrere Level hinweg weiterreichen können. Dies ist auch in den meisten Anleitungen im Internet angegeben. Auf den in Abschnitt 5.1 angegeben Rechnern läßt sich das nicht bestätigen. Werden Filter an einer QDisc angebracht, deren Flow-ID eine Major-Nummer aufwiest, die nicht der Major-Nummer der Eltern-QDisc des Filters entspricht, treten die Pakete, die auf die Filter-Regel zutreffen, nicht in den Statistiken der entsprechenden Blatt-QDisc auf. Erst wenn für jede klassenbehaftete QDisc eine eigene Filter-Instanz erzeugt wird, kommen die Pakete bei der Blatt-QDisc an. 106

123 Kapitel 6 Bewertung In diesem Abschnitt wird eine Bewertung der gewählten Konfiguration der Queueing Disziplinen anhand von Messungen vorgenommen. 6.1 Messumgebung Die Messungen werden mit den in 5.1 beschriebenen Rechnern, in einem von einem Cisco Catalyst 2950 Switch vermittelten Netz durchgeführt. Drei dieser Rechner sind in Sterntopologie um den Switch angeordnet, wobei einer davon den Datenverkehr auf dem Switch mit dem Programm Tethereal aufzeichnet. Der Switch verfügt über vier Ausgangsqueues pro Port, die über ein Strict-Priority- Queueing bedient werden. Die Konfiguration des Switches beinhaltet die Einrichtung der beteiligten Ports als Trunk-Ports für VLAN 1-3, wobei VLAN 1 alle Ethernet- Frames bediente, die kein VLAN-Tag enthalten. Weiterhin wurden für die Multicast- Adressen, der an der Messung beteiligten Kanäle, statische Einträge in der MAC- Adress-Tabelle des Switches vorgenommen. Dis Konfigurationsdatei des Switches liegt im Verzeichniss Messungen/Switchkonfiguration der CD. 6.2 Messgrößen Gemessen wurden sowohl die Ende-zu-Ende-Propagationszeit zwischen zwei Rechnern, als auch die Verweilzeit eines Pakets innerhalb der Queueing Disziplinen. Um 107

124 6.3. Instrumentierung Kapitel 6. Bewertung eine Korrelation der Daten zu ermöglichen wird auch die Zeit gemessen, die ein Paket benötigt, um vom Eintritt in den Systemcall zur enqueue()-funktion der QDisc zu gelangen. 6.3 Instrumentierung Die Messung wird durch eigens implementierte send()- und recv()-methode am chdescr-objekt des zu messenden Kanals angestoßen. Diese sind instrumentiert um zwei verschiedene Messungen vorzunehmen, die anschließend korreliert werden. Die Methoden testmodesend() und testmoderecv() sind im Modul chmsr definiert Ende-zu-Ende Propagation Um die Ende-zu-Ende Propagation und den Jitter bei Paketankunft zu messen, wurde eine Bibliothek von Dipl. Inf. Bernharg Gelling geschrieben, deren Funktion 8- Bit Information aufnimmt und diese am Parallel-Port des Testrechners ausgibt. Diese Informationen wurden von einem Logic-Analyzer aufgezeichnet und anschließend in Excel weiterverarbeitet. Von den acht zur Verfügung stehenden Bit, wurden drei genutzt um die Kanal-ID zu codieren und die restlichen fünf, für die Sequenznummer der Pakete verwendet. Die send()-methode wurde direkt vor dem Aufruf des sendto()-systemcalls mit der Funktion zum Setzen des Parallelports instrumentiert, während die recv()-methode direkt nach dem Aufruf des recv()-systemcalls instrumentiert wurde Delay durch sendto-systemcall und QDisc Für die interne Delay-Messung wurde das Time-Stamp-Register der CPU genutzt. Für diesen Zweck wird das Messmodul chmsr implementiert, mit dem verschiedene Punkte im Betriebssystem instrumentiert werden. Um den Delay innerhalb des Systemcalls und der QDisc zu messen, wird der Paket- Pfad an drei Punkten instrumentiert: In der send-methode, am QDisc-Eingang und am QDisc-Ausgang. An jedem dieser Punkte wird der Wert aus dem Time Stamp Register der CPU ausgelesen und im Paket eingefügt. Dazu wird in das Paket eine Struktur eingefügt, die aus einem Header und drei 64-Bit Zeitstempel besteht (Listing 6.1). 108

125 Kapitel 6. Bewertung 6.3. Instrumentierung 1 union msrpnt { 2 u32 part [2]; 3 u64 value ; 4 }; 5 struct msrhdr { 6 u16 mark ; 7 u16 chid ; 8 u32 seq ; 9 u32 cpu ; 10 u8 wpos ; 11 }; 12 struct msrfrm { 13 struct msrhdr hdr ; 14 union msrpnt tsc [ MAX_MSR_PNTS ]; 15 char buf [ MAX_MSR_PAYL ]; 16 }; Quelltext 6.1: Die msrfrm-struktur Der Header beginnt mit dem Erkennungsmuster 0x7FFE, über das festgestellt werden kann, ob es sich um ein Testpaket handelt. Danach folgen Informationen über die Kanal-ID, die Sequenznummer des Pakets und die Taktfrequenz der CPU. Letzteres ist nötig, da die Zeitinformationen auf einem anderen Rechner ausgewertet werden, der evtl. eine andere Taktfrequenz besitzt. Headerinformationen werden in der send()-methode gesetzt, wo auch der erste Zeitstempel, kurz vor dem Versenden des Pakets, gesetzt wird (Listing 6.2). Quelltext 6.2: testmodesend()-funktion 1 int testmodesend ( struct chdescr * channel, void * buf, size_t size ) { 2 struct msrfrm frame ; 3 int sentdata ; 4 5 memset (& frame, ( unsigned ) 0, sizeof ( frame )); 6 7 frame. hdr. mark = htons (0 x7ffe ); 8 frame. hdr. seq = htonl ( channel -> seq ); 9 frame. hdr. chid = htons ( channel ->id); 10 frame. hdr. cpu = htonl ( cpukhz ); memcpy (( void *)& frame. buf, buf, size < MAX_MSR_PAYL? size : MAX_MSR_PAYL ); 13 addmsrpoint (& frame ); 14 llaappch_write ( channel ->id, ( unsigned short ) channel -> seq ); sentdata = sendto ( channel ->sock, ( void *)&frame, size, 0, channel -> sendaddr, channel -> addrlen ); 17 channel -> seq ++; 18 return sentdata ; 19 } 109

126 6.3. Instrumentierung Kapitel 6. Bewertung Im Kern wird vor dem Aufruf der enqueue()-funktion der QDisc ermittlet, ob ein Frame mit einem VLAN-Tag das Muster für ein Testpaket enthält. Ist das der Fall, wird ein Zeitstempel genommen und an der nächsten freien Stelle im Paket eingefügt (Listing 6.3). Quelltext 6.3: Instrumentierung an der enqueue()-funktion 1 spin_lock_bh (& dev -> queue_lock ); 2 /* Instrumetation for ChannelDelay Measurement */ 3 if(skb -> protocol == htons (0 x8100 )) { 4 struct msrfrm * frm ; 5 u32 upper, lower ; 6 7 frm = ( struct msrfrm *)(skb -> data + ( sizeof ( struct ethhdr ) + 4)); 8 if(frm -> hdr. mark == htons (0 x7ffe ) && frm -> hdr. wpos < MAX_MSR_PNTS ) { 9 rdtsc ( lower, upper ); 10 frm -> tsc [frm -> hdr. wpos ]. part [ UPPER ] = htonl ( upper ); 11 frm -> tsc [frm -> hdr. wpos ]. part [ LOWER ] = htonl ( lower ); 12 frm -> hdr. wpos ++; 13 } 14 } 15 /* End of Instrumentation */ rc = q-> enqueue (skb, q); qdisc_run ( dev ); spin_unlock_bh (& dev -> queue_lock ); Der letzte Zeitstempel wird nach dem Aufruf der Funktion dequeue() an der QDisc genommen und in das zurückgelieferte Paket eingefügt, sofern es sich um ein Testpaket handelt. Die Pakete werden von dem Netzwerk-Analyzer tethereal aufgezeichnet und anschließend mit zwei Perl-Skripten in eine von Excel lesbare Form gebracht. Damit werden Diagramme zur Visualisierung des Delays erstellt. 110

127 Kapitel 6. Bewertung 6.4. Lastmodell Instrumentierungsaufwand Datei Zeilen (ohne Kommentare) chmsr.h 37 chmsr.c 148 dev.c 1 12 sch generic.c 2 12 Gesamt 209 Tabelle 6.1: Implementierungsaufwand Instrumentierung 6.4 Lastmodell Das Lastmodell ist dahingehend konzipiert, dass die Dauerlast unterhalb der Linkkapazität des Netzwerkinterface (R = 12, 5Bytes/µs) bleibt. Damit können Stausituationen, die durch Bursts entstehen, wieder abgebaut werden und es entsteht kein dauerhaftes Aufstauen von Paketen. Exemplarisch wird hierzu die isochrone Propagation von Steuerdaten aufgegriffen, wie sie im Use-Case Steuern und Regeln beschrieben wurde. Im Folgenden werden drei Lastkonfigurationen betrachtet (Tabelle 6.2), die sich in Paketgröße 3, und Propagationsintervall unterscheiden. Jede Konfiguration besteht aus drei Kanälen, wobei zwei Kanäle eine Priorität von vier und ein Kanal eine Priorität von sieben aufweist. Der Kanal mit der hohen Priorität besitzt außerdem ein größeres Propagationsintervall. Lastkonf. Paketgröße Intervall Prio 4 Intervall Prio Byte 50µs 100µs 2 500Byte 100µs 500µs Byte 300µs 900µs Tabelle 6.2: Lastkonfigurationen Zur Ermittlung der verbrauchten Bandbreite der einzelnen Kanäle, wurde die Frame- Größe der Lastkonfigurationen inklusive Präambel, Header, CRC und IFG zu Grun- 1 Kernel-Quelltext /usr/src/linux/net/core/dev.c 2 Kernel-Quelltext /usr/src/linux/net/sched/sch generic.c 3 Paketgröße bedeutet hier reine Payload 111

128 6.4. Lastmodell Kapitel 6. Bewertung de gelegt (Tabelle 6.3). Lastkonf. Framegröße Bandbreite Prio 4 Bandbreite Prio 7 Bandbreite gesamt 1 242Byte 4, 48Byte/µs 2, 24Byte/µs 12, 1Byte/µs 2 542Byte 5, 24Byte/µs 1, 084Byte/µs 11, 924Byte/µs Byte 5, 125Byte/µs 1, 71Byte/µs 11, 96Byte/µs Tabelle 6.3: Genutzte Bandbreite der Lastkonfigurationen Aufgrund der gewählten Lastkonfigurationen wurden die maximal auftretenden Delays mit der Formel 3.11 aus Kapitel voraus berechnet. Der konstante Delay- Parameter T der Servicekurve wurde durch eine Messung des Delays in der QDisc ermittelt. Dazu wurden Pakete in einem Intervall auf einem Kanal gesendet, der keinen Stau verursachen würde. Somit konnte der Durchschnitts-Delay in der QDisc ermittelt werden. Dieser Beträgt 0.855µs und wird als Grundlage für die Berechnung der Werte in Tabelle 6.4 verwendet. Lastkonf. Delay Prio 4 Delay Prio , 935µs 20, 215µs 2 130, 935µs 44, 215µs 3 369, , 895µs Tabelle 6.4: Maximaler Delay der Kanäle in der Queueing Disziplin Um Vergleichsmöglichkeiten zu haben wurde das Lastmodell außer mit der für die Implementierung vorgesehenen, noch mit zwei weiteren Queueing-Disziplin-Konfigurationen gemessen: eine Prio-QDisc ohne Bandbreitenbegrenzer und eine reine FIFO-QDisc. Ein weiteres Messzenario untersucht das Verhalten eines Kanals unter massiver Störlast durch Best-Effort-Verkehr. Hierzu wird je ein einzelner Kanal mit der Priorität 7 bzw. 1 und einem Sendeintervall von 1000µs gemessen. Jeder Kanal wird einmal mit einem je einmal mit einer Störlast und einmal ohne gemessen. Die Störlast wird durch das Kommando ping -f -s 500 ausgelöst. 112

129 Kapitel 6. Bewertung 6.5. Lastquelle 6.5 Lastquelle Bei der Implementierung der Lastquelle, ist absolute Gleichzeitigkeit beim Senden auf den einzelnen Kanäle nicht möglich. Um eine möglichst gute Annäherung zu erreichen, werden die Sendeoperationen auf den Kanälen direkt aufeinander folgend durchgeführt. Dabei wird auf dem Kanal mit der höchsten Priorität zuletzt gesendet, um ein Zurückhalten von Paketen niedriger Priorität in der Queueing Disziplin zu provozieren. Die Lastquellenapplikation msrsend und das instrumentierte Gegenstück msrrecv wird speziell für die Messungen des in Abschnitt 6.4 beschriebenen Lastmodells implementiert. Als Argumente nimmt msrsend die Payloadgröße, das Sendeintervall, die Anzahl der Iterationen und einen Divisor entgegen. Mit dem Divisor wird angegeben, nach wieviel Iterationsschritten jeweils ein hochpriores Paket versendet werden soll. Der Implementierungsaufwand wird in Kapitel 5.9 angegeben. 6.6 Messergebnisse Die einzelnen Diagramme zu den Messungen sind in Anhang B aufgeführt. Der Grund, dafür, dass einige Diagramme kürzer sind als andere, obwohl die gleich Anzahl Pakete versendet wurden, ist teilweise bei Tethereal zu suchen, dass zeitweise zu langsam ist um alle Pakete zu empfangen und zu verarbeiten. Ein anderer Grund wird im Folgenden besprochen. Es ist deutlich zu sehen, dass die Werte stark von den Erwartungen abweichen. Außerdem ist zu erkennen, dass die Ursache für die Abweichungen in den Queueing- Disziplinen zu suchen ist. Dort werden die Pakete aufgestaut, was wiederum zu Paketverlust durch Überlaufen der Blatt-QDisc, verursacht. Im Vergleich zu anderen QDisc-Konfigurationen fällt auf, dass die großen Delay-Werte ausschließlich in der Konfiguration, die HTB nutzt, auftreten. Die durchschnittlichen und maximalen Delay-Werte werden in den folgenden Tabellen zusammengefasst. Lastkonf. Delay Prio 4 Delay Prio , 12µs 1549, 43µs , 60µs 0, 098µs , 887µs 0, 218µs 113

130 6.6. Messergebnisse Kapitel 6. Bewertung Tabelle 6.5: Mittlerer Delay für Prio/HTB-Konfiguration Lastkonf. Delay Prio 4 Delay Prio , 54µs 30515, 08µs , 55µs 7, 67µs , 64µs 12, 15µs Tabelle 6.6: Maximaler Delay für Prio/HTB- Konfiguration Lastkonf. Delay Prio 4 Delay Prio 7 1 0, 105µs 0, 014µs 2 0, 097µs 0, 012µs 3 0, 094µs 0, 020µs Tabelle 6.7: Mittlerer Delay für Prio-Konfiguration Lastkonf. Delay Prio 4 Delay Prio 7 1 3, 43µs 0, 33µs 2 6, 917µs 0, 94µs 3 6, 79µs 1, 018µs Tabelle 6.8: Maximaler Delay für Prio-Konfiguration Lastkonf. Delay Prio 4 Delay Prio 7 1 0, 075µs 0, 076µs 2 0, 063µs 0, 065µs 3 0, 065µs 0, 065µs Tabelle 6.9: Mittlerer Delay für FIFO-Konfiguration Lastkonf. Delay Prio 4 Delay Prio 7 1 0, 36µs 6, 117µs 114

131 Kapitel 6. Bewertung 6.7. Fazit 2 0, 357µs 0, 0676µs 3 6, 793µs 1, 018µs Tabelle 6.10: Maximaler Delay für FIFO-Konfiguration Da die Ursache für den hohen Delay offensichtlich in der HTB-QDisc liegt, werden weitere Messungen mit veränderten Parametern durchgeführt. Der cbuffer- Parameter scheint zur Variation geeignet, da er genutzt wird, um den Burst auf eine Paketgröße zu beschränken, und damit den Mindestwert für den Parameter buffer unterschreitet. Die Diagramme B.19 bis B.21 zeigen das Ergebnis der Messungen in der QDisc für einen cbuffer-parameter, der um 1000 Byte erhöht ist oder 1000 bzw. 500 Byte unter dem Minimum liegt. Aus den Ergebnissen ist abzulesen, dass der cbuffer- Parameter durchaus unter dem Minimum liegen kann, ohne dass ein erhöhter Delay feststellbar wäre. Jedoch scheint es davon abhängig zu sein, wie weit sich der cbuffer vom Minimum entfernt. Da der Minimalwert für buffer von der Rate und dem Timer abhängig ist (s. Kapitel ), kann dem Problem nicht mit einem einfachen Modifikator abgeholfen werden. Dies wird in Diagramm B.20 gezeigt, wo ein Modifikator von keinen Einfluss auf die beiden Kanäle mit der höheren Bandbreite hat, aber auf den Kanal mit wenig Bandbreite, dessen cburst-parameter unter die Paketgröße fällt. Eine weitere Auffälligkeit bei den Messungen ist, dass die Delay-Werte für alle anderen QDisc-Konfigurationen unter einer Microsekunde liegen. Eigentlich sollte zumindest der dritte Kanal durch den Stau, den der Burst verursacht um ein paar Microsekunden verzögert werden. Erklärbar ist dies, wenn die Hardware ihrerseits eine Queue enthält, die größer ist, als ein Paket. In diesem Fall kann es bei so kurzen Bursts, wie die im Lastmodell nicht zu messbaren Stausituationen in der QDisc kommen. 6.7 Fazit Es wurden stark von der Erwartung abweichende Werte gemessen, die jedoch daraufhin deuten, dass der Einsatz der HTB-QDisc als präzisen Bandbreitenbegrenzer, in der jetzigen Implementation nicht für den Automatisierungskontext geeignet ist. 115

132 6.7. Fazit Kapitel 6. Bewertung Dies ist jedoch bisher nur eine Vermutung, die mit weiteren Messungen verifiziert werden muss. Aus Zeitgründen können diese Messungen nicht im Rahmen dieser Arbeit durchgeführt werden. 116

133 Kapitel 7 Zusammenfassung und Ausblick In dieser Arbeit wurde gezeigt, dass eine Integration von Ethernet in die Automatisierungsumgebung ohne proprietäre Hardware durchaus möglich ist. Switches machen das Medium deterministisch, so dass keine Kollisionen mehr auftreten können. Um einen priorisierten Datenverkehr zu realisieren ist ein Modell erstellt worden, das QoS-behaftete Kanäle vorsieht. Die QoS-Eigenschaften sollten durch die vom Linux-Kernel bereitgestellten Queueing-Disziplinen durchgesetzt werden. Die Beschreibung der Queueing-Disziplinen, als Implementierungen von Paket-Scheduling-Algorithmen, deutete darauf hin, dass diese für den Einsatz in der verteilten Automation geeignet sind. Die Queueing-Disziplinen wurden entsprechend dem, in der Analyse verwandten Ankunfts- und Servicekurvenmodell, konfiguriert. Durchgeführte Messungen wichen jedoch stark von den erwarteten Ergebnissen ab. Die Ergebnisse deuten daraufhin, dass die Queueing-Disziplinen, speziell gezeigt an der HTB, in ihrer Implementierungsform im Linux-Kernel noch nicht ausgereift sind, um in so präzisen Umgebungen eingesetzt zu werden, wie sie in der verteilten Automation vorkommen. Als eine Weiterentwicklung dieser Arbeit würde sich die Implementierung präziser Paket-Scheduling-Algorithmen anbieten. Diese Implementierung könnte dann in Zusammenhang mit einer Echtzeiterweiterung, wie RTAI, erfolgen, was eine Portierung des Kanalkonzepts in eine harte Echtzeitumgebung ermöglichen würde. Eine weitere Weiterentwicklung, könnte ein Programm sein, dass die lokalen QoS- Parameter eines Kanals aufgrund von Wissen über Topologie, Hardware und geplanten Netzwerkverkehr berechnet. Dies könnte so weit gehen, dass auf jedem Rechner 117

134 Kapitel 7. Zusammenfassung und Ausblick ein Deamon läuft, der die QoS-Kapazitäten der gesamten Topologie kennt und die lokalen QoS-Parameter dynamisch errechnet und mit anderen Deamons aushandelt. 118

135 Kapitel 8 Literaturverzeichnis [BC02] [BT04] [eh] [Fel00] [Fur03] [Hal96] [Hub03] [IEE] Daniel P. Bovet and Marco Cesati. Understanding the Linux Kernel. O Reilly, 2. edition, Dezember Jean-Yves Le Boudec and Patrick Thiran. Network Calculus, A Theory of Deterministic Queueing Systems for the Internet. Springer Verlag, 1. edition, PROFIBUS Nutzerorganisation e.v. (Hrsg.). Profinet systembeschreibung. Technical report. Max Felser. Ethernet als Feldbus?, Kommunikationsmodelle für Industrielle Netzwerke. Hochschule für Technik und Informatik, Bern, Mai Frank J. Furrer. Industrieautomation mit Ethernet-TCP/IP und Web- Technologie. Hüthig Verlag Heidelberg, 3. edition, Fred Halsall. Data Communications, Computer Networks and Open Systems. Addison-Wesley Publishing Company Inc., 4. edition, Bert Hubert. Linux Advanced Routing and Traffic Control, September Institute for Electrical and Electronics Engineers Inc. IEEE 1588, Standard for precision Clock Synchronization Protocol for Network Measurement and Control Systems

136 Kapitel 8. Literaturverzeichnis [IEE01] [IEE02] Institute for Electrical and Electronics Engineers Inc. 802, IEEE Standard for Local and Metropolitan Area Networks, Overview and Architecture, März Institute for Electrical and Electronics Engineers Inc , IEEE Standard for Information technology- Telecommunications and information exchange between systems- Local and metropolitan area networks-specific requirements, Carrier sense multiple access with collision detection (CS- MA/CD) access method and physical layer specifications, März [IEE03] Institute for Electrical and Electronics Engineers Inc Q, IEEE Standard for Local and Metropolitan Area Networks, Virtual Bridged Local Area Networks, Mai [IEE04] Institute for Electrical and Electronics Engineers Inc D, IEEE Standard for Local and Metropolitan Area Networks, Media Access Control(MAC) Bridges, Juni [ipr] [Jas02] [JL04] [Kop97] [KS04] [Oes01] [Tan02] iproute2 utitlity suite. Jürgen Jaspereite. Leistungsbewertung eines Netzwerkes mit Class-of- Service Unterstützung für Prozessnahe Echtzeitkommunikation. PhD thesis, Otto-von-Guericke Universität Magdeburg, Oktober Herrmann Haertig Jork Loeser. Low-Latency Hard Real-Time Communication over Switched Ethernet. Technische Universität, Dresden, Juni ps/loeser ecrts2004.pdf. Hermann Kopetz. Real-Time Systems, Design Principles for Distributed Embedded Applications Jan Kiszka and Robert Schwebel. Alternative: Rtnet. A&D Newsletter, publish-industry Verlag GmbH, Bernd Oestereich. Objektorientierte Softwareentwicklung: Analyse und Design mit der Unified Modeling Language Andrew S. Tanenbaum. Computernetzwerke. Pearson Studium, 3. edition,

137 Kapitel 8. Literaturverzeichnis [WPR + 02] Klaus Wehrle, Frank Pählke, Hartmut Ritter, Daniel Müller, and Marc Bechler. Linux-Netzwerkarchitektur, Design und Implementierung von Netzwerkprotokollen im Linux-Kern. Addison-Wesley Verlag, 1. edition,

138 122 Kapitel 8. Literaturverzeichnis

139 Anhang A Prioritätentabelle Priorität User Prio Prio Class ID Filter Prio HTB Handle hoch 7 x:1 0 8:0 6 x:2 1 7:0 5 x:3 2 6:0 4 x:4 3 5:0 3 x:5 4 4:0 0 x:6 5 1:0 2 x:7 6 3:0 niedrig 1 x:8 7 2:0 Tabelle A.1: Übersicht über alle prioritätsbezogenen Werte 123

140 124 Anhang A. Prioritätentabelle

141 Anhang B Diagramme B.1 HTB/Prio QDisc Abbildung B.1: Delay in QDisc für 200Byte, 2 Kanäle Prio 4 50µs und 1 Kanal Prio 7 100µs 125

142 B.1. HTB/Prio QDisc Anhang B. Diagramme Abbildung B.2: Delay in QDisc für 500Byte, 2 Kanäle Prio 4 100µs und 1 Kanal Prio 7 500µs Abbildung B.3: Delay in QDisc für 1496Byte, 2 Kanäle Prio 4 300µs und 1 Kanal Prio 7 900µs 126

143 Anhang B. Diagramme B.2. HTB/Prio End-to-End B.2 HTB/Prio End-to-End Abbildung B.4: End-to-End Propagation Time für 200Byte, 2 Kanäle Prio 4 50µs und 1 Kanal Prio 7 100µs 127

144 B.2. HTB/Prio End-to-End Anhang B. Diagramme Abbildung B.5: End-to-End Propagation Time für 500Byte, 2 Kanäle Prio 4 100µs und 1 Kanal Prio 7 500µs Abbildung B.6: End-to-End Propagation Time für 1496Byte, 2 Kanäle Prio 4 300µs und 1 Kanal Prio 7 900µs 128

145 Anhang B. Diagramme B.3. Prio QDisc B.3 Prio QDisc Abbildung B.7: Delay in QDisc für 200Byte, 2 Kanäle Prio 4 50µs und 1 Kanal Prio 7 100µs Abbildung B.8: Delay in QDisc für 500Byte, 2 Kanäle Prio 4 100µs und 1 Kanal Prio 7 500µs 129

146 B.4. Prio End-to-End Anhang B. Diagramme Abbildung B.9: Delay in QDisc für 1496Byte, 2 Kanäle Prio 4 300µs und 1 Kanal Prio 7 900µs B.4 Prio End-to-End Abbildung B.10: End-to-End Propagation Time für 200Byte, 2 Kanäle Prio 4 50µs und 1 Kanal Prio 7 100µs 130

147 Anhang B. Diagramme B.4. Prio End-to-End Abbildung B.11: End-to-End Propagation Time für 500Byte, 2 Kanäle Prio 4 100µs und 1 Kanal Prio 7 500µs Abbildung B.12: End-to-End Propagation Time für 1496Byte, 2 Kanäle Prio 4 300µs und 1 Kanal Prio 7 900µs 131

148 B.5. FIFO QDisc Anhang B. Diagramme B.5 FIFO QDisc Abbildung B.13: Delay in QDisc für 200Byte, 2 Kanäle Prio 4 50µs und 1 Kanal Prio 7 100µs Abbildung B.14: Delay in QDisc für 500Byte, 2 Kanäle Prio 4 100µs und 1 Kanal Prio 7 500µs 132

149 Anhang B. Diagramme B.6. FIFO End-to-End Abbildung B.15: Delay in QDisc für 1496Byte, 2 Kanäle Prio 4 300µs und 1 Kanal Prio 7 900µs B.6 FIFO End-to-End Abbildung B.16: End-to-End Propagation Time für 200Byte, 2 Kanäle Prio 4 50µs und 1 Kanal Prio 7 100µs 133

150 B.6. FIFO End-to-End Anhang B. Diagramme Abbildung B.17: End-to-End Propagation Time für 500Byte, 2 Kanäle Prio 4 100µs und 1 Kanal Prio 7 500µs Abbildung B.18: End-to-End Propagation Time für 1496Byte, 2 Kanäle Prio 4 300µs und 1 Kanal Prio 7 900µs 134

151 Anhang B. Diagramme B.7. HTB/Prio QDisc variierender Burst-Parameter B.7 HTB/Prio QDisc variierender Burst-Parameter Abbildung B.19: Delay in QDisc für 500Byte, 2 Kanäle Prio 4 100µs und 1 Kanal Prio 7 500µs mit cburst Abbildung B.20: Delay in QDisc für 500Byte, 2 Kanäle Prio 4 100µs und 1 Kanal Prio 7 500µs mit Minimum Burst

152 B.8. Ein Prio 1 Kanal ohne Störlast Anhang B. Diagramme Abbildung B.21: Delay in QDisc für 500Byte, 2 Kanäle Prio 4 100µs und 1 Kanal Prio 7 500µs mit Minimum Burst B.8 Ein Prio 1 Kanal ohne Störlast Abbildung B.22: Kanal Prio 1 500Byte ohne Störlast gemessen in QDisc 136

153 Anhang B. Diagramme B.9. Ein Prio 1 Kanal mit Störlast Abbildung B.23: Kanal Prio 1 500Byte ohne Störlast gemessen End-to-End B.9 Ein Prio 1 Kanal mit Störlast Abbildung B.24: Kanal Prio 1 500Byte mit Ping-Flood gemessen in QDisc 137

154 B.10. Ein Prio 7 Kanal ohne Störlast Anhang B. Diagramme Abbildung B.25: Kanal Prio 1 500Byte mit Ping-Flood gemessen End-to-End B.10 Ein Prio 7 Kanal ohne Störlast Abbildung B.26: Kanal Prio 7 500Byte ohne Störlast gemessen in QDisc 138

155 Anhang B. Diagramme B.11. Ein Prio 7 Kanal mit Störlast Abbildung B.27: Kanal Prio 7 500Byte ohne Störlast gemessen End-to-End B.11 Ein Prio 7 Kanal mit Störlast Abbildung B.28: Kanal Prio 7 500Byte mit Ping Flood gemessen in QDisc 139

156 B.11. Ein Prio 7 Kanal mit Störlast Anhang B. Diagramme Abbildung B.29: Kanal Prio 7 500Byte mit Ping Flood gemessen End-to-End 140