Nutzung von SDN in der Mininet-Umgebung zur Optimierung einer
Werbung
Projektarbeit Nutzung von SDN in der Mininet‐Umgebung zur Optimierung einer Beispielapplikation Bearbeiter: Eike Björn Schweißguth Matrikelnummer 209204206 Studiengang Elektrotechnik 11. Fachsemester Universität Rostock 1 Inhaltsverzeichnis 1 Einleitung ......................................................................................................................................... 4 2 Grundlagen ...................................................................................................................................... 4 2.1 Software Defined Networking (SDN) ....................................................................................... 4 2.2 OpenFlow ................................................................................................................................ 7 2.2.1 Switch .............................................................................................................................. 7 2.2.2 Controller ......................................................................................................................... 9 2.2.3 Protokoll .......................................................................................................................... 9 2.3 2.3.1 Aufbau und Funktionsweise .......................................................................................... 11 2.3.2 Grenzen und Einschränkungen ...................................................................................... 13 2.4 3 POX‐Controller ....................................................................................................................... 14 Implementierung ........................................................................................................................... 16 3.1 Testaufbau und Durchführung .............................................................................................. 16 3.1.1 Sterntopologie (Single Switch) ...................................................................................... 17 3.1.2 Binärbaumtopologie ...................................................................................................... 18 3.1.3 Mesh Grid‐Topologie ..................................................................................................... 19 3.1.4 FatTree‐Topologie ......................................................................................................... 21 3.2 Theoretischer Hintergrund .................................................................................................... 22 3.2.1 Realer Hardwareaufbau ................................................................................................ 22 3.2.2 Emulation mit Mininet .................................................................................................. 23 3.3 4 Mininet .................................................................................................................................. 11 Ergebnisanalyse ..................................................................................................................... 25 Optimierung einer Beispielapplikation .......................................................................................... 26 4.1 Anwendungsorientierte Controller ....................................................................................... 27 4.2 SDN und echtzeitfähige Datenübertragung .......................................................................... 27 5 Ausblick ......................................................................................................................................... 28 6 Verwandte Themen ....................................................................................................................... 29 6.1 Etablierte Netzwerktechnologien.......................................................................................... 29 6.1.1 Simple Network Management Protocol (SNMP) ........................................................... 29 6.1.2 Routing Information Protocol und Open Shortest Path First ........................................ 31 6.2 SDN‐bezogene Projekte ......................................................................................................... 32 6.2.1 Virtualisierung von Netzwerken .................................................................................... 32 6.2.2 EstiNet OpenFlow Network Simulator and Emulator .................................................... 33 6.2.3 KVM‐unterstützte Echtzeitdatenübertragung über OpenFlow‐Netzwerke .................. 33 7 Zusammenfassung ......................................................................................................................... 34 I. Abbildungsverzeichnis ................................................................................................................... 35 2 II. Tabellenverzeichnis ....................................................................................................................... 35 III. Literaturverzeichnis ................................................................................................................... 36 Anhang A: Testsystem und Softwareversionen .................................................................................... 38 Hardware ........................................................................................................................................... 38 Software ............................................................................................................................................ 38 3 1 Einleitung Das Software Defined Networking (SDN) ist ein Prinzip zum Betreiben von Netzwerken, das vor allem in den letzten Jahren ein gesteigertes Interesse von Forschern und Unternehmen hervorgerufen hat. Einer der Hauptgründe dafür ist die stark gestiegene Anzahl von netzwerkfähigen Geräten und der damit verbundene Anstieg des Datenverkehrs in Netzwerken. Netzwerke in Unternehmen und Rechenzentren wachsen daher ständig, um diesen Anforderungen gerecht zu werden. Dabei hat sich gezeigt, dass der Betrieb und die Konfiguration, ebenso wie die Anpassung an veränderte Bedürfnisse laufender Applikationen mit den bisher eingesetzten Technologien zum Betreiben von Netzwerken eine große Herausforderung darstellen. Diese Schwierigkeiten haben zu ineffizienten Netzwerken geführt und so den Weg für die Umsetzung neuer Konzepte wie SDN bereitet. Durch OpenFlow, ein Protokoll, dass viele Ideen des SDN implementiert, wurde der Übergang von der Forschung in praktische Anwendungen erleichtert, da es sich um einen offenen Standard handelt, der von der Netzwerkhardware vieler Hersteller unterstützt wird. Diese Arbeit verfolgt zwei Ziele. Der erste Teil soll eine Einleitung in SDN, OpenFlow und Mininet (ein Tool zum Betreiben virtueller OpenFlow‐ Netzwerke) geben, während der zweite Teil die Vor‐ und Nachteile eines praktischen Einsatzes von SDN in einem Netzwerk zur echtzeitfähigen Datenübertragung analysieren soll. Zu diesem Zweck konzentrieren sich die durchgeführten Experimente auf die Messung von Latenzen des Netzwerks, welche ein wichtiges Kriterium für Echtzeitkommunikation darstellen. Abschließend werden die Themengebiete vorgestellt, die für die weitere Optimierung von Netzwerken relevant sind und es werden einige verwandte Projekte kurz erläutert. Diese Arbeit ist als Einleitung in das große Themengebiet des SDN zu sehen und daher nicht auf ein spezifisches Problem von Netzwerken (Routing, Topologien, Robustheit, etc.) ausgerichtet. 2 Grundlagen In diesem Kapitel sollen einige wichtige Grundlagen des SDN erläutert werden. Da es sich dabei um ein sehr vielfältiges Themengebiet handelt, soll der Fokus hier auf den im praktischen Teil der Arbeit verwendeten sowie den für das prinzipielle Verständnis notwendigen Themen liegen. 2.1 Software Defined Networking (SDN) In heutigen Computernetzwerken gibt es eine Vielzahl von verschiedenen Komponenten mit speziell zugewiesenen Aufgaben, welche eine effiziente und möglichst transparente Kommunikation zwischen angeschlossenen Endgeräten gewährleisten sollen. Diese Komponenten sind beispielsweise Switches, Router, Firewalls und Load Balancer. Jedes dieser Netzwerkgeräte besitzt eine eigene Kontrolllogik, um Pakete zu analysieren und zu entscheiden, wie diese verändert und weitergeleitet werden sollen. Die Komplexität der Logik hängt dabei von der Aufgabe des Netzwerkgerätes ab. Außerdem besitzt es entsprechende Hardware zur Umsetzung der Entscheidungen und Weiterleitung der Pakete. Die Kontrolllogiken aller Netzwerkgeräte können zusammen als Kontrollschicht (Control Plane) aufgefasst werden, während die gesamte Hardware zur Paketweiterleitung und ‐modifikation als Datenschicht (Data Plane oder Forwarding Plane) bezeichnet wird. In den typischen, seit Jahrzehnten etablierten Netzwerken ist die Logik der Control Plane durch die Implementierung in den jeweiligen Netzwerkgeräten (Router, Switches, Firewalls, etc.) über das gesamte Netzwerk verteilt und direkt mit der ausführenden Hardware der Forwarding Plane verbunden. Daraus ergibt sich das Problem, dass Veränderungen an der Netzwerkkonfiguration oft nicht zentral vorgenommen werden können, sondern eine Vielzahl von Geräten einzeln neu konfiguriert werden müssen. Es existieren daher Management Tools, die diesen Konfigurationsprozess vereinfachen sollen. Auf Grund der unterschiedlichen Konfigurationsschnittstellen und Protokolle verschiedener Hersteller ist jedoch in der Regel keine umfassende Kompatibilität gegeben, sodass Änderungen an der Netzwerkkonfiguration und ‐hardware erschwert werden. Dies hemmt die Übernahme neuer 4 Netzwerktechnologien in den produktiven Einsatz und verlangsamt somit auch die Weiterentwicklung in diesem Bereich (vgl. zu diesem Abschnitt [1]). Die zwei grundlegenden Merkmale von SDN sind das Trennen von Control Plane und Data Plane sowie das Zusammenführen der Kontrolllogiken der Control Plane in einer Controller‐Software, die viele Geräte der Data Plane steuert [1] [2]. Application Application Application Application Northbound API Controller Network Service Network Service Network Service Southbound API Abbildung 1: Beziehung zwischen Control Plane, Data Plane und Anwendungen [2] Der Controller (auch als Netzwerk‐Betriebssystem bezeichnet) kommuniziert dabei über ein klar definiertes Application Programming Interface (API) mit den Geräten der Data Plane und kann darüber hinaus auch eine API zur Kommunikation mit der Anwendungssoftware, welche das Netzwerk nutzt, bieten [1] [2]. Dieses Konzept ist in Abbildung 1 zu sehen. Entsprechend dieser Darstellung werden die APIs auch als Southbound API (zur Data Plane) und Northbound API (zur Anwendung) bezeichnet [3]. Dabei ist anzumerken, dass eine Kommunikation mit der Anwendung bzw. eine Northbound API für ein funktionierendes Software Defined Network nicht zwingend notwendig ist. Je nach Anwendungsbereich kann eine Kommunikation mit den Anwendungen, die das Netzwerk nutzen, jedoch entscheidende Vorteile mit sich bringen und stellt daher aktuell ein wichtiges Forschungsthema dar [4]. 5 Eine der derzeit bekanntesten Southbound APIs ist das OpenFlow‐Protokoll, welches hier als Beispiel für die Funktionsweise von SDN dienen soll. Die Arbeitsweise der OpenFlow‐Switches basiert auf einem Regelsystem für eintreffende Pakete. In einem OpenFlow‐Switch existiert eine Liste von Regeln, die jeweils aus einem Paketheader und einer Reihe von auszuführenden Aktionen bestehen. Stimmt der Paketheader eines im Switch eingetroffenen Paketes mit dem einer Regel überein, so werden die der Regel zugehörigen Aktionen für das Paket angewendet. Typische Aktionen sind zum Beispiel das Austauschen der MAC‐Adressen, IP‐Adressen oder TCP/UDP‐Ports und das Weiterleiten eines Paketes über einen bestimmten Port des Switches. Existiert keine passende Regel, so wird die korrekte Verarbeitung beim Controller erfragt. Dieser analysiert das Paket, legt dessen Verarbeitung fest und sendet gegebenenfalls eine neue, passende Regel an den Switch. Weitere Details werden in Kapitel 2.2 erläutert. Durch dieses Konzept ergeben sich folgende Vorteile bei der Nutzung von SDN (vgl. dazu [1] [2]): Vereinfachte Hardwarekomponenten. Eine hardwareseitige Unterscheidung vieler Netzwerkgeräte wie Switches, Routern und Firewalls entfällt. Grund hierfür ist, dass sich diese Geräte nur darin unterscheiden, welche Protokolle bzw. Headerfelder analysiert und verändert werden. Die OpenFlow‐Switch‐Spezifikation sieht dagegen vor, dass Veränderungen an den Headerfeldern verschiedener Protokolle beliebig miteinander kombiniert und gleichzeitig von einem einzigen Netzwerkgerät ausgeführt werden können. Ob ein Gerät als Switch, Router, Firewall oder etwas anderes arbeitet, wird nicht mehr durch die Hardware vorgegeben, sondern durch den Controller. Zudem entfällt die komplexe Kontrolllogik innerhalb der einzelnen Netzwerkgeräte durch die Verlagerung in den Controller. Flexibilität. Die Netzwerkhardware kann ihre Funktion ändern, ohne ausgetauscht werden zu müssen. Zentrales Management. Änderungen der Netzwerkkonfiguration können zentral im Controller vorgenommen werden und werden auf einheitliche Weise an die Netzwerkgeräte weitergegeben. Das direkte Ansprechen einzelner Netzwerkgeräte über individuelle Konfigurationsschnittstellen entfällt. Konfiguration durch Programmierung. Da der Controller in Software implementiert werden kann, ist ein hohes Maß an Freiheit bei der Netzwerkkonfiguration gegeben. Updates können einfach ausgeführt werden und erlauben ein schnelles Testen neuer Methoden. Außerdem ermöglicht dieses Konzept ein einfacheres Debugging sowie eine einfachere Simulation neuer Konfigurationen. Dadurch soll die Übernahme neuer Netzwerktechnologien in den produktiven Einsatz unterstützt werden und die zukünftige Weiterentwicklung beschleunigt werden. Herstellerunabhängigkeit. Durch etablierte offene Standards wie OpenFlow kann auf proprietäre Lösungen zur Netzwerkkonfiguration verzichtet werden und Anwender sind nicht mehr auf spezifische, kompatible Hardware eines Herstellers beschränkt. Dabei handelt es sich allerdings nicht um einen direkten Vorteil des SDN, sondern um ein Resultat der breiten Akzeptanz von OpenFlow. Proprietäre Lösungen, die dem Konzept des SDN folgen, sind ebenfalls möglich. Für das Verständnis von SDN ist es außerdem wichtig zu erkennen, dass es sich dabei um ein übergeordnetes Konzept handelt, welches die Verwaltung von komplexen Netzwerken vereinfachen und gleichzeitig neue Möglichkeiten bieten soll. SDN löst keine konkreten Aufgaben (Routing, Load Balancing, Anpassung an Anwendungen, etc.) im Netzwerk. Die Effizienz eines mittels SDN betriebenen Netzwerkes kann somit nicht verallgemeinert werden, sondern hängt maßgeblich von den im Controller implementierten Diensten hab. 6 2.2 OpenFlow Bei OpenFlow handelt es sich um einen bedeutenden pragmatischen Ansatz, um programmierbare Netzwerke zu etablieren, indem er Wissenschaftler, Hardwarehersteller und Netzwerkadministratoren zugleich anspricht. Es ist ein wichtiges Ziel von OpenFlow, dass normale, produktiv eingesetzte Netzwerke (z.B. Universitätsnetz) mit OpenFlow‐Unterstützung aufgebaut werden sollen, um Forschern die Möglichkeit zu bieten, neue Protokolle auf einem Netzwerk mit realistischer Größe zu testen. Dabei soll das Netzwerk eine zuverlässige Unterscheidung zwischen „normalem“ Traffic und zu einem Experiment gehörendem Traffic beherrschen, um normale Nutzer nicht zu behindern und somit Netzwerkadministratoren vom Einsatz eines solchen Netzwerkes zu überzeugen [5]. Aber auch der Aufbau von kleinen Netzwerken im Labor oder das Testen durch Emulation/Simulation (siehe Kapitel 2.3) sind möglich. Außerdem sollen Unternehmen bzw. Netzwerkadministratoren durch eine einfachere Verwaltung und schnellere Weiterentwicklung ihrer Netzwerke profitieren, sobald OpenFlow (oder eine andere SDN‐Lösung) zur Kontrolle des „normalen“ Traffics eingesetzt wird. Hardwarehersteller können OpenFlow auf ihren Geräten ohne signifikante Änderungen an ihrer Hardware unterstützen, da die Implementierung von OpenFlow‐Switches Anforderungen stellt, die bereits durch herkömmliche Switches und Router erfüllt werden [1]. So konnte die Unterstützung für OpenFlow vielen Geräten mit geringen oder keinen Hardwareänderungen und einem einfachen Software/Firmware‐Update hinzugefügt werden [1]. Außerdem ist keine Offenlegung von der internen Funktionsweise der Hardware erforderlich [5]. Aus diesen Eigenschaften resultiert die weite Verbreitung von OpenFlow. OpenFlow wurde ursprünglich an der Universität von Stanford von Nick McKeown et al. entwickelt und 2008 in [5] vorgestellt. Die hier gegebenen Informationen basieren neben [5] außerdem auf der OpenFlow‐Switch‐Spezifikation der Version 1.0.0 [6]. Neuere Versionen der Spezifikation sind bereits verfügbar, allerdings unterstützt die im praktischen Teil der Arbeit verwendete Mininet‐Software (siehe Kapitel 2.3) offiziell derzeit nur OpenFlow 1.0.0, sodass diese Version auch als Referenz für dieses Kapitel verwendet wurde. OpenFlow hat außerdem bedeutend zum verstärkten Interesse am SDN in den vergangenen Jahren beigetragen. Mittlerweile wurde die Open Networking Foundation gegründet, welche die Weiterentwicklung und Verbreitung von OpenFlow sowie SDN mittels offener Standards unterstützt. Die beiden Kernkomponenten von OpenFlow sind die Spezifikation von Eigenschaften und Fähigkeiten eines OpenFlow‐fähigen Switches sowie die Definition der API zur Kommunikation zwischen OpenFlow‐Switches und Controller‐ Software. 2.2.1 Switch Die Klassifizierung und Verarbeitung von Paketen in OpenFlow‐fähigen Switches erfolgt an Hand von sogenannten Flows. Bei einem Flow handelt es sich um eine bestimmte Verbindung im Netzwerk, welche mit unterschiedlicher Granularität angegeben werden kann. Beispiele für Flows: Alle auf Port 1 des Switches ankommenden Pakete. Alle Pakete mit Absender‐MAC‐Adresse 00:70:32:ab:ac:7a. Alle Pakete mit Absender‐IP‐Adresse 10.0.0.1 und Ziel‐IP‐Adresse 10.0.0.2 Alle Pakete mit TCP‐Protokoll und Absender 10.0.1.1:7778 und Ziel 10.0.1.2:9000 Die gesamten Flow‐Definitionen werden in einer Flow‐Tabelle gespeichert. Ein Eintrag der Tabelle besteht aus einem Paketheader (definiert den Flow), keiner bis mehreren Aktionen (Verarbeitung von Paketen dieses Flows) und einer Statistik (bisherige Anzahl der Pakete dieses Flows, Zeit seit dem letzten Paket des Flows, etc.). Das Format für den Paketheader, welches von einem OpenFlow‐Switch mindestens unterstützt werden muss, ist in Abbildung 2 gezeigt. 7 In Port MAC SRC MAC DST Ether‐ VLAN VLAN ID type Priority IP SRC IP DST IP Protocol IP ToS/ TCP/ TCP/ DSCP UDP SRC UDP DST Bits Port Port Abbildung 2: Paketheader zur Definition von Flows [6] Um weniger spezifische Flows zu definieren, unterstützen die einzelnen Headerfelder Wildcards, die bei einem beliebigen Eintrag im Headerfeld ankommender Pakete eine Übereinstimmung erzeugen. Zusätzlich zu den Wildcards für komplette Headerfelder kann ein Switch Subnetzmasken für Quelle und Ziel des IP‐Protokolls unterstützen [6]. Für jedes im Switch ankommende Paket wird die Flow‐ Tabelle nach einem passenden Eintrag durchsucht. Diese Flow‐Tabellen können mit Hilfe von Ternary Content Addressable Memory (TCAM) implementiert werden. Dabei handelt es sich um einen Assoziativspeicher. Statt einer Speicheradresse können Daten (der Paketheader eines angekommenen Paketes) am Eingang angelegt werden. Der Speicher wird dann nach diesen Daten durchsucht. Bei einer gefundenen Übereinstimmung kann die zugehörige Speicheradresse oder zugehörige Daten (die auszuführenden Aktionen) zurückgeliefert werden [7] [8]. Auch Wildcards für nicht‐exakte Übereinstimmungen werden von TCAM unterstützt. Durch diese hardwarebasierte Suche ist die Paketverarbeitung anhand von Flows performant genug, um die Geschwindigkeit der Ethernetverbindungen nicht zu limitieren. Außerdem werden TCAMs bereits in herkömmlichen Switches und Routern verwendet und somit die schnelle Übernahme des Konzepts durch Hardwarehersteller ermöglicht (vgl. zu diesem Abschnitt [5]). Ein OpenFlow‐Switch muss mindestens drei Aktionen unterstützen (vgl. dazu [5]): 1. Das Weiterleiten von Paketen eines Flows an einen bestimmten Port bzw. an mehrere Ports. So kann eine typische Switch‐Funktionalität bereitgestellt werden und die Weiterleitung durch ein Subnetz erfolgen. 2. Das Senden einer Nachricht inklusive des eingegangenen Paketes an den Controller. Dabei soll eine sichere Verbindung verwendet werden (z.B. SSL). Diese Aktion wird auch für Pakete ohne passenden Flow‐Eintrag verwendet, um dem Controller die Entscheidung zu überlassen, was mit dem Paket passieren soll, und um gegebenenfalls passende Flow‐Einträge zu erstellen. 3. Das Verwerfen eines Paketes. Dies kann z.B. für Sicherheitsmechanismen verwendet werden. Das Verwerfen eines Paketes wird nicht explizit als Aktion auf einem Paket ausgeführt, sondern passiert, indem keine Weiterleitungsaktion für den entsprechenden Flow definiert wird. Es sind zwei Arten von OpenFlow‐Switches möglich. Reine OpenFlow‐Switches und herkömmliche Switches und Router, welche OpenFlow unterstützen, jedoch weiterhin eine eigene Kontrolllogik besitzen. Herkömmliche Switches und Router mit OpenFlow‐Unterstützung sollten daher eine zusätzliche Aktion beherrschen: Das Weiterleiten von Paketen an die eigene Kontrolllogik. Zur gleichzeitigen Nutzung für „normalen“ Traffic und für Experimente sind herkömmliche Geräte mit OpenFlow‐Unterstützung besonders interessant. Anhand von VLAN IDs oder auch anderen Flow‐ Merkmalen können die beiden Arten von Traffic unterschieden werden und „normaler“ Traffic durch die eigene Kontrolllogik der Geräte zuverlässig weitergeleitet werden, während experimenteller Traffic an die jeweilige Controller‐Software weitergeleitet wird (vgl. zu diesem Abschnitt [5]). OpenFlow‐Switches sind jedoch prinzipiell nicht auf die oben beschriebenen Flow Header oder Aktionen beschränkt. Weitere Aktionen, die von den meisten OpenFlow fähigen Geräten unterstützt werden und in Form von „optionalen Aktionen“ bereits Teil der OpenFlow‐Switch‐Spezifikation [6] sind, sind Modifikationen an verschiedenen Headerfeldern, so wie sie auch von herkömmlichen Routern durchgeführt werden (z.B. Austausch von MAC‐Adressen, Network Address Translation (NAT)). Der Flow Header kann theoretisch ein beliebiges Format annehmen. So sind auch andere 8 Protokolle als IP problemlos möglich (derzeit nicht Teil der Spezifikation). Die tatsächliche Unterstützung von verschiedenen Headerformaten und Aktionen hängt somit von der Implementierung bzw. einer effizienten technischen Realisierbarkeit ab (vgl. zu diesem Abschnitt [5]). 2.2.2 Controller Ist in einem OpenFlow‐Switch noch kein passender Flow‐Eintrag zu einem ankommenden Paket vorhanden, so wird es an einen OpenFlow‐Controller weitergeleitet. Der OpenFlow‐Controller entscheidet dann über die weitere Verarbeitung des Paketes. Er kann dem Switch entweder mitteilen, wie einmalig mit dem Paket umgegangen werden soll (ggf. Modifikationen durchführen, Weiterleitung an bestimmten Port, Verwerfen), oder er kann einen passenden Flow‐Eintrag für das Paket erstellen, welcher sowohl für das aktuelle als auch zukünftige Pakete des Flows die Verarbeitung festlegt. Das Stellen einer Anfrage beim Controller zur weiteren Verarbeitung eines Paketes bedeutet eine vergleichsweise hohe Verzögerung, da der Controller typischerweise in Software implementiert ist. Damit das Netzwerk eine hohe Performance bieten kann, ist es also in der Regel wünschenswert, Flow‐ Einträge zu erstellen. Außerdem hat der Controller die Möglichkeit Flow‐Einträge zu löschen (vgl. zu diesem Abschnitt [5]). Die verwendeten Routingverfahren des Controllers sowie die allgemeine Komplexität der Paketverarbeitung im Controller sind implementierungsabhängig. Die Performance des Controllers (z.B. in verarbeiteten Paketen pro Sekunde) hängt neben der verwendeten Hardware ebenfalls von der Komplexität des implementierten Controllers ab. Es soll auch ermöglicht werden, dass mehrere Experimente gleichzeitig auf einem einzigen OpenFlow‐fähigen Netzwerk stattfinden. Dabei unterscheidet ein relativ komplexer Controller den Traffic unterschiedlicher Experimente anhand von Flows und kann die Verarbeitung an das für das jeweilige Experiment zuständige Kontrollprogramm übergeben, um dieses über das Setzen von Flow‐Einträgen entscheiden zu lassen. Zur Gewährleistung von ausreichender Zuverlässigkeit und Skalierbarkeit eines durch OpenFlow gesteuerten Netzwerkes, ist es vorgesehen, dass sich auch mehrere Controller in einem Netzwerk befinden können (genaue Funktionsweise noch nicht spezifiziert). Damit mehrere Controller konsistente Entscheidungen treffen können, ist eine zustandslose Implementierung empfehlenswert (vgl. zu diesem Abschnitt [5]). 2.2.3 Protokoll Im Folgenden sollen einige wichtige Mechanismen des OpenFlow‐Protokolls vorgestellt werden, welche auch im praktischen Teil dieser Arbeit verwendet wurden. Die Kommunikation zwischen Controller und Switch wird durch das OpenFlow‐Protokoll in drei Nachrichtentypen unterteilt: 1. Controller‐to‐Switch‐Nachrichten werden vom Controller zur Konfiguration des Switches, zum Abfragen von Statistiken, sowie zum Installieren oder Löschen von Flows verwendet. Die Kommunikation wird vom Controller gestartet, wobei einigen Nachrichten eine Antwort durch den Switch folgen kann. 2. Asynchrone Nachrichten werden als Folge von bestimmten Ereignissen (z.B. angekommenes Paket ohne passenden Flow‐Eintrag) vom Switch an den Controller gesendet. 3. Symmetrische Nachrichten werden zwischen Controller und Switch ausgetauscht und können von beiden Seiten aus gestartet werden. Hierzu zählen die HELLO‐Nachricht, die beim Verbindungsaufbau ausgetauscht wird und die ECHO‐Request/Reply‐Nachrichten, mit denen z.B. überprüft werden kann, ob der Kommunikationspartner noch aktiv ist. Die Packet‐In (OFPT_PACKET_IN)‐Nachricht zählt zu den asynchronen Nachrichten. Sie wird von einem Switch an den Controller gesendet, wenn der Flow‐Eintrag zu einem am Switch angekommenen Paket eine Aktion zum Senden des Pakets an den Controller beinhaltet oder wenn kein passender Flow‐ 9 Eintrag existiert und der Switch die korrekte Verarbeitung beim Controller erfragen muss. Bemerkenswert ist in diesem Zusammenhang (kein passender Flow‐Eintrag) die Nutzung von Buffern im Switch. Besitzt die Switch‐Implementierung einen entsprechend nutzbaren Speicher, so kann das zu verarbeitende Paket in diesem bis zur Antwort des Controllers zwischengespeichert werden. Dem Controller wird in diesem Fall nur ein Teil des Paketes zugesendet (standardmäßig die ersten 128 Bytes), da dies in der Regel ausreichend zur Entscheidung über die korrekte Verarbeitung ist. Bei der Antwort kann das vollständige, zwischengespeicherte Paket über eine Buffer ID referenziert und zur weiteren Verarbeitung genutzt werden. Unterstützt ein Switch dieses Verfahren nicht oder ist nicht mehr ausreichend Speicher vorhanden, so muss in Anfrage und Antwort jeweils das vollständige Paket übertragen werden. In der Regel reagiert der Controller auf eine Packet‐In‐Nachricht als Folge von keinem passenden Flow‐Eintrag mit einer Flow‐Modification‐ oder Packet‐Out‐Nachricht. Bei Packet‐ In‐Nachrichten als Folge eines Flow‐Eintrages mit entsprechender Aktion kann in dieser angegeben werden, wie viele Bytes des Paketes an den Controller gesendet werden sollen. Eine Modify Flow Entry (OFPT_FLOW_MOD)‐Nachricht ist eine Controller‐to‐Switch Nachricht zum Hinzufügen, Ändern und Entfernen von Einträgen in der Flow‐Tabelle. Diese Nachricht wird häufig als Reaktion auf eine Packet‐In‐Nachricht versendet um die Verarbeitung des entsprechenden Paketes sowie folgender Pakete des Flows festzulegen. Dabei wird die Buffer ID genutzt, um anzugeben, auf welches zwischengespeicherte Paket im Switch die Aktionen des Flows sofort angewendet werden sollen. Sie kann aber auch als Reaktion auf andere Ereignisse im Netzwerk oder unabhängig von Ereignissen zur proaktiven Installation von Routen verwendet werden. Bei der Installation von Flow‐ Einträgen sind ein passender Flow Header sowie keine bis mehrere Aktionen anzugeben. Weiterhin ist die Konfiguration von Timeouts möglich, nach denen der Flow‐Eintrag automatisch entfernt wird. Es gibt sowohl ein Zeitlimit für Inaktivität als auch ein festes Zeitlimit, nach dem der Flow‐Eintrag auf jeden Fall gelöscht wird. Außerdem können Prioritäten für Flow‐Einträge mit Wildcards angegeben werden. Flow‐Einträge für exakte Übereinstimmung (ohne Wildcards) haben immer die maximale Priorität. Gibt es mehrere Flow‐Einträge mit Wildcards, die eine Übereinstimmung für das gleiche Paket erzeugen können, sind Prioritäten notwendig, um über die Verarbeitung zu entscheiden. Bei gleicher Priorität kann ein Switch einen beliebigen passenden Flow auswählen. Eine Send Packet (OFPT_PACKET_OUT)‐Nachricht ist eine Controller‐to‐Switch‐Nachricht, welche vom Controller benutzt werden kann, um ein Paket von einem bestimmten Switch aus zu senden. Sie kann u.a. als Reaktion auf Packet‐In‐Nachrichten verwendet werden, um am Switch angekommene Pakete zu bearbeiten und weiterzuleiten, ohne dabei einen Flow‐Eintrag zu installieren. Dabei können entweder zwischengespeicherte Pakete über eine Buffer ID referenziert und verarbeitet werden oder ein zu bearbeitendes Paket in der Send Packet‐Nachricht selbst enthalten sein. Read State (OFPT_STATS_REQUEST)‐Nachrichten sind Controller‐to‐Switch‐Nachrichten, welche zum Abfragen verschiedener Statistiken eines Switches nutzbar sind und daher eine Antwort vom Switch erfordern (OFPT_STATS_REPLY). Es können zum Beispiel Statistiken zur Nutzung von Ports oder Flows oder eine Beschreibung des Switches erfragt werden. Bei der Port Modification (OFPT_PORT_MOD)‐Nachricht handelt es sich um eine Controller‐to‐Switch Nachricht, welche dem Setzen von Konfigurationsparametern einzelner Ports dient. Interessant ist dabei die Flooding‐Konfiguration. Das Flooding kann auf einzelnen Ports deaktiviert werden, um im Falle von Schleifen im Netzwerk keine zirkulierenden Pakete zu erzeugen. Neben der Konfiguration des Floodings durch den Controller kann ein Switch zusätzlich das Spanning Tree Protocol (STP) nach IEEE 802.1D unterstützen. Ob das Flooding in diesem Fall durch den Controller oder die eigene STP‐ Implementierung gesteuert wird, ist ebenfalls durch die Portkonfiguration einstellbar. Empfang und Weiterleitung zielgerichteter Pakete kann auf dem Port bei deaktiviertem Flooding weiterhin erfolgen. 10 2.3 Mininet Mininet [9] wurde von Brandon Heller im Rahmen seiner Doktorarbeit [10] an der Universität von Stanford entwickelt. Dabei wurde das Ziel verfolgt, wissenschaftliche Arbeiten aus dem Bereich der Netzwerktechnologien einfach reproduzierbar zu machen. Das grundlegende Problem dabei ist, dass in einem Netzwerk viele Switches, Router und angeschlossene Hosts parallel arbeiten und Pakete parallel über verschiedene Netzwerkverbindungen übertragen werden. Der Nachbau des entsprechenden Hardwareaufbaus, um Ergebnisse aus wissenschaftlichen Arbeiten nachzuvollziehen, ist oft nicht realisierbar. Andere Möglichkeiten zur Reproduktion wie vorgefertigte Testumgebungen oder Simulatoren unterliegen dagegen anderen wesentlichen Einschränkungen. Vorgefertigten Testumgebungen fehlt es an der nötigen Flexibilität, Simulatoren vernachlässigen auf Grund ihrer Abstraktion den Einfluss von einzelnen Komponenten des realen Systems. Außerdem entspricht der im Simulator ausgeführte Code oft nicht vollständig dem realen Code. Der von Brandon Heller verfolgte Ansatz ist dagegen eine Emulation aller Netzwerkkomponenten in Software und das Betreiben virtueller Hosts mit dem realen Programmcode, was durch die heutigen fortschrittlichen Virtualisierungstechnologien ermöglicht wird. Die Flexibilität und der Realismus, die so von Mininet erreicht werden, sollen eine Vielzahl von Experimenten reproduzierbar machen und darüber hinaus die interaktive Weiterentwicklung von Netzwerktechnologien ermöglichen (vgl. zu diesem Absatz [10]). 2.3.1 Aufbau und Funktionsweise Eine detaillierte Beschreibung zu den Zielen, der Funktionsweise, sowie den Einschränkungen von Mininet ist in den Quellen [11], [10], [12] und [13] nachlesbar, auf welchen auch dieses Kapitel basiert. Mininet setzt auf eine Emulation des Netzwerkes, da hierbei viele Vorteile von Simulatoren und hardwarebasierten Testumgebungen vereint werden, ohne deren Schwächen zu übernehmen. Im Gegensatz zu Simulatoren wird keine umfassende Abstraktion von Systemkomponenten vorgenommen, was zu funktionalen Unterschieden im Vergleich zur realen Hardware führen könnte. Stattdessen werden bei der Emulation Softwarekomponenten verwendet, deren Verhalten aus funktionaler Sicht identisch mit der realen Hardware ist. Dies ermöglicht es, auf den mit dem Netzwerk verbundenen virtuellen Hosts realen Programmcode auszuführen, so wie man ihn auch bei einem hardwarebasierten Testaufbau verwenden würde. Dementsprechend stimmt auch das Trafficmuster in der Emulation mit dem eines realen Testaufbaus überein. Dennoch hat man im Gegensatz zu einem realen Testaufbau und ähnlich zu einem Simulator die Vorteile der hohen Flexibilität (z.B. hinsichtlich der Netzwerktopologie) und der geringen Kosten. Der einzige nennenswerte Schwachpunkt ist die zeitliche Genauigkeit und in diesem Zusammenhang die Abhängigkeit von der Leistung des Rechners, auf dem die Emulation durchgeführt wird. Dies wird in Kapitel 2.3.2 näher erläutert. Ermöglicht wird die Emulation durch viele standardmäßig in Linux vorhandene Möglichkeiten zur Virtualisierung von Switches, Ethernetadaptern und Hosts (zum besseren Verständnis ist ein einfaches Beispiel für das Konzept in Abbildung 3 dargestellt): Ethernetadapter und ‐verbindungen. Der ip link‐Befehl ermöglicht das Erzeugen von virtuellen Ethernetverbindungen mit einem virtuellen Ethernetadapter an jedem Ende. Switches. In Mininet wird das Linux Package des Open vSwitch zur Erzeugung virtueller Ethernet‐ Switches verwendet. Dabei handelt es sich um einen OpenFlow‐fähigen Software‐Switch, der mit dem ovs‐vsctl‐Befehl erzeugt werden kann. Jeweils ein Ethernetadapter der virtuellen Ethernetverbindungen wird dem Switch zugeordnet. Ohne zusätzliche Packages bietet Linux darüber hinaus eine Möglichkeit zur Erzeugung virtueller Ethernet‐Bridges/Switches mit Hilfe des ip link‐Befehls. Diese können jedoch mangels OpenFlow‐Unterstützung nicht genutzt werden. 11 Hosts. Eine ressourcenschonende Maßnahme zur Virtualisierung von Hosts sind network namespaces. Dies ist ein unter Linux verfügbares Konzept, um einzelnen Prozessen einen vom restlichen System unabhängigen Netzwerkstack zur Verfügung zu stellen. D.h. für die entsprechenden Prozesse sind unabhängige Routing‐ und Firewalleinstellungen möglich und es sind nur die Netzwerkadapter sichtbar, welche dem entsprechenden network namespace zugeordnet wurden [14]. Dieser kann mit dem ip netns‐Befehl erzeugt werden. Nach der Erstellung eines network namespaces wird ein Shell‐Prozess in diesem gestartet, der den Host darstellt. Alle von dort aufgerufenen Programme befinden sich dann im gleichen network namespace (in Abbildung 3 z.B. firefox und httpd). Außerdem wird jeweils der zweite Ethernetadapter einer virtuellen Ethernetverbindung dem network namespace zugeordnet, um die Verbindung zum Software‐Switch herzustellen. Trotz der eigenen Sicht auf die Netzwerkressourcen hat ein solcher Host den vollen Zugriff auf das Dateisystem des Linux‐Systems und kann normale Programme, welche in Experimenten zum Erzeugen der gewünschten Trafficmuster benötigt werden, innerhalb des network namespaces starten. Eine weitere, intuitive Möglichkeit zur Erzeugung virtueller Hosts wäre das Betreiben einer virtuellen Maschine (VM) für jeden Host, die jeweils über den zweiten Ethernetadapter einer virtuellen Ethernetverbindung am Software Switch angeschlossen ist. Auf Grund des größeren Overheads (vor allem hinsichtlich des Arbeitsspeichers) wird diese Methode jedoch nicht gewählt. shell shell firefox Network Namespace 1 httpd 10.0.0.1 10.0.0.2 h1‐eth0 h2‐eth0 Network Namespace 2 Virtual Ethernet Pairs veth1 veth2 Software Switch Abbildung 3: Netzwerkaufbau von Mininet [12] Der in Abbildung 4 gezeigte Code ist eine Möglichkeit zur Erzeugung entsprechender virtueller Netzwerke (mit anschließendem Start des ping‐Tools auf Host 1 statt einem Shell‐Prozess). Dabei ist anzumerken, dass nach der Erzeugung des virtuellen Netzwerkes jeder in einem der network namespaces gestartete Prozess als ein auf dem virtuellen Host laufender Prozess angesehen werden kann. 12 sudo bash # Create host namespaces ip netns add h1 ip netns add h2 # Create switch ovs-vsctl add-br s1 # Create links ip link add h1-eth0 type veth peer name s1-eth1 ip link add h2-eth0 type veth peer name s1-eth2 ip link show # Move host ports into namespaces ip link set h1-eth0 netns h1 ip link set h2-eth0 netns h2 ip netns exec h1 ip link show ip netns exec h2 ip link show # Connect switch ports to OVS ovs-vsctl add-port s1 s1-eth1 ovs-vsctl add-port s1 s1-eth2 ovs-vsctl show # Set up OpenFlow controller ovs-vsctl set-controller s1 tcp:127.0.0.1 ovs-controller ptcp: & ovs-vsctl show # Configure network ip netns exec h1 ifconfig ip netns exec h1 ifconfig ip netns exec h2 ifconfig ip netns exec h1 ifconfig ifconfig s1-eth1 up ifconfig s1-eth2 up # Test network ip netns exec h1 ping -c1 h1-eth0 10.1 lo up h2-eth0 10.2 lo up 10.2 Controller S1 H1 – 10.0.0.1 H2 – 10.0.0.2 Abbildung 4: Erstellen eines virtuellen Netzwerks unter Linux [12] Mininet bietet ein komfortables Framework, um das Arbeiten mit virtuellen Netzwerken dieser Art zu erleichtern. Es wird ein Kommandozeilenprogramm geboten, welches automatisch entsprechende Netzwerke generieren (und löschen) kann. Dabei sind Konfigurationsparameter vorhanden, die u.a. die Auswahl unterschiedlicher vorgefertigter Topologien, Switch‐Betriebsmodi und OpenFlow‐ Controller ermöglichen. Nach dem Erzeugen des Netzwerks wird ein Command Line Interface (CLI) gestartet, welches das interaktive Arbeiten mit dem Netzwerk ermöglicht. Dies beinhaltet z.B. das Starten von Prozessen auf den einzelnen Hosts oder das komfortable Abfragen der Flow‐Tabellen aller Switches. Ein weiteres Feature mit großer Bedeutung für die Durchführung umfangreicher Experimente ist Mininets Python API. Durch die Python API lassen sich eigene Topologien definieren und eine umfangreiche Konfiguration einzelner Hosts, Switches und Ethernetverbindung vornehmen. Darüber hinaus ist es möglich, Prozessaufrufe auf den Hosts und die Auswertung von Messergebnissen vollständig zu automatisieren. Ein Experiment kann also vollständig durch ein einziges Python‐Skript beschrieben werden. Mit Hilfe von Mininets Python API definiert dieses Topologie und Konfiguration des Netzwerks, startet das virtuelle Netzwerk, führt die gewünschten Messungen durch und entfernt das Netzwerk anschließend wieder. Neben den standardmäßig gebotenen OpenFlow‐Controllern (welche als normaler L2‐Switch arbeiten) ist auch ein eigener Controller zur Kontrolle über das virtuelle Netzwerk verwendbar. Auf Grund des Konzepts von Mininet gestaltet sich der Wechsel zwischen einem realen Testaufbau und Emulation sehr einfach: Topologie, OpenFlow‐Controller und auf den Hosts aktive Software können in der Regel ohne Veränderungen übernommen werden. 2.3.2 Grenzen und Einschränkungen Das grundlegende Problem von Mininet (und Emulatoren im Allgemeinen) ist der korrekte zeitliche Ablauf von Ereignissen und daher auch die korrekte Wiedergabe von Performanceeigenschaften eines Systems. Dieses Problem wird bereits in [13] als bedeutendste Einschränkung von Mininet genannt und in einem folgenden Paper [11] der gleichen Autoren näher analysiert. Ein weiteres eng verknüpftes Problem ist die Skalierbarkeit. Dieses Problem ist jedoch weniger relevant, da durch die Verwendung 13 von ressourcensparenden Virtualisierungstechniken auch auf durchschnittlichen PCs ausreichend große Netzwerke emuliert werden können. Ursache für die Probleme mit der zeitlichen Korrektheit ist das Betreiben des gesamten Netzwerkes auf nur einem realen PC. Im realen Netzwerk arbeiten viele Switches und Hosts parallel und unabhängig voneinander. In der Emulation müssen dagegen durch die begrenzte Anzahl von Kernen der CPU viele ursprünglich parallele Vorgänge sequentiell durchgeführt werden. Darüber hinaus können rechenintensive Prozesse auf einem Host die Performance des gesamten emulierten Netzwerkes beeinflussen, indem der Scheduler des Betriebssystems den Software‐Switches oder anderen Hosts nicht mehr ausreichend Rechenzeit zur Verfügung stellt, um die Verarbeitung und Weiterleitung von Paketen durchzuführen. Dementsprechend kann sich das Zeitverhalten des Systems signifikant ändern. Daher gibt es einige Kriterien, die eingehalten werden müssen, damit ein Experiment in der Emulation brauchbare Ergebnisse liefern kann. Das Hauptkriterium ist, dass das Experiment durch das Netzwerk limitiert sein muss. Durch die CPU oder Speicherbandbreite limitierte Experimente liefern Ergebnisse, welche vom verwendeten PC abhängen und nicht mit einem realen Testaufbau vergleichbar sind. In [11] werden daher zwei wichtige Mechanismen vorgestellt, um den gegenseitigen Einfluss der Hosts zu verringern und Experimente durch das Netzwerk zu limitieren: Eine Einschränkung der Rechenzeit pro Host (mit Hilfe von Prozessgruppen und dem Linux Scheduler) Eine Limitierung der Bandbreite von virtuellen Ethernetverbindungen (mit Hilfe der Linux Traffic Control) Zusätzlich wurden zwei weitere wichtige Kriterien genannt, mit deren Hilfe sich beurteilen lässt, ob ein mit dem Emulator durchgeführtes Experiment korrekte Ergebnisse produzieren kann: 1. Alle virtuellen Ethernetverbindungen müssen mit der eingestellten Übertragungsrate arbeiten. Das bedeutet, dass Pakete immer nach einem bestimmten Zeitintervall übertragen werden müssen, sofern die Queue bei der entsprechenden Verbindung nicht leer ist (z.B. ein 1514 Byte Paket alle 121.1 µs bei einer 100 Mbit/s Verbindung). 2. Alle Hosts müssen im Rahmen der ihnen zugewiesenen Rechenzeit stets ein geringes Maß an Idlezeit aufweisen, da dies darauf hinweist, dass das Experiment nicht CPU‐limitiert ist. Für die beiden Kriterien wurden Überwachungsfunktionen (nicht in der öffentlichen Version von Mininet enthalten) in Mininet implementiert und an einer Reihe von Experimenten überprüft, ob Mininet die Kriterien einhält und außerdem mit einem realen Testaufbau vergleichbare Ergebnisse liefert. Für eine Vielzahl von Experimenten konnten übereinstimmende Ergebnisse erzeugt werden. Dabei wurden einige sich aus den oben genannten Kriterien ergebende Erkenntnisse gewonnen. Viele Experimente mussten hinsichtlich der Bandbreiten im Netzwerk herunterskaliert werden, da der Hardwareaufbau des Experiments mit 1 Gbit/s oder mehr pro Verbindung betrieben wurde und der für die Emulation genutzte PC nicht die notwendige Rechenleistung für viele entsprechende Verbindung besaß (CPU‐Limitierung) und das erste der oben genannten Kriterien verletzt wurde (Pakete können nicht exakt im vorgesehenen Intervall übertragen werden, z.B. alle ~12 µs bei 1 Gbit/s). Ob das Herunterskalieren der Bandbreiten möglich ist, ohne die Resultate zu verfälschen, ist vom Experiment abhängig. Bei den in [11] untersuchten Experimenten lieferte Mininet jedoch nach evtl. nötiger Skalierung zur Einhaltung der beiden Kriterien überwiegend zuverlässige Ergebnisse. 2.4 POX‐Controller Da die in Mininet integrierten Controller nicht den nötigen Funktionsumfang boten, wurde in den Experimenten aus Kapitel 3 ein Controller auf Basis von POX verwendet. POX [15] [16] [17] ist ein Framework zur Entwicklung von OpenFlow‐Controllern in der Programmiersprache Python. Es ist 14 ursprünglich aus dem NOX‐Controller hervorgegangen, welcher von Nicira Networks parallel zu OpenFlow entwickelt wurde und daher der erste OpenFlow‐Controller war [18]. Nachdem Nicira Networks den Quellcode von NOX 2008 veröffentlicht hat, wurde die weitere Entwicklung von NOX und POX in den vergangenen Jahren vor allem durch James McCauley (International Computer Science Institute und University of California at Berkeley) unterstützt. Das Hauptziel von POX ist es, die Entwicklung von OpenFlow‐Controllern zu vereinfachen und somit neue Konzepte zur Steuerung von Netzwerken einfach testbar zu machen. Das Ziel ist also mit dem von Mininet vergleichbar. Während Mininet einen schnellen und unkomplizierten Zugriff auf ein virtuelles Netzwerk als Testumgebung bietet, erlaubt POX die schnelle Implementierung neuer Controller für dieses Netzwerk. Hierfür sind in POX grundlegende Funktionen, die jeder OpenFlow‐Controller benötigt, bereits fertig implementiert. Darüber hinaus kann POX mit selbstgeschriebenen Python‐Modulen um die gewünschten Funktionen (z.B. neue Routingalgorithmen) erweitert werden. Die wichtigsten von POX zur Verfügung gestellten Funktionen umfassen: Verbindungsmanagement. POX wartet automatisch auf Verbindungsanfragen von Switches und kann Verbindungen mit einer beliebigen Anzahl an Switches aufnehmen und aufrechterhalten. OpenFlow API. Die OpenFlow API übernimmt das Parsen von am Controller eingetroffenen OpenFlow‐Nachrichten und macht die einzelnen Felder der Nachrichten über entsprechende Datenstrukturen einfach zugreifbar. Umgekehrt können auch OpenFlow‐Nachrichten erzeugt werden, indem eine entsprechende Datenstruktur beschrieben wird. POX sorgt dann beim Senden für den Aufbau eines dem OpenFlow‐Protokoll entsprechenden Paketes. Event‐System. Das Event‐System von POX dient dazu, Module über aufgetretene Ereignisse zu informieren. Eine typische Nutzung ist z.B. die Signalisierung von eingetroffenen Packet‐In‐ Nachrichten gegenüber einem Routingmodul. Darüber hinaus kann es auch zur Kommunikation zwischen Modulen genutzt werden. Neben diesen Funktionen, die POX zu einem Framework zur Controllerentwicklung machen, beinhaltet POX bereits einige Module, welche häufig in einem Controller benötigte Funktionen realisieren. Einige dieser Module sind bereits ausreichend, um ein Netzwerk zu betreiben. Die folgenden Module wurden im praktischen Teil dieser Arbeit verwendet: openflow.discovery erkennt die Netzwerktopologie. Neue und entfernte Verbindungen zwischen Switches werden außerdem mittels Events an andere Module bekanntgegeben. Das zu Grunde liegende Prinzip des Moduls ist das Senden von speziell angepassten LLDP (Link Layer Discovery Protocol)‐Paketen von bestimmten Switches aus mit Hilfe von Send Packet‐Nachrichten. Wenn die Pakete beim nächsten OpenFlow‐Switch ankommen, sendet dieser wiederum eine Packet‐In‐ Nachricht an den Controller. Dadurch weiß der Controller sowohl den Startpunkt als auch den Endpunkt des LLDP‐Paketes und kann so die vorhandenen Verbindungen erkennen. Die verschiedenen OpenFlow‐Switches werden dabei anhand einer eindeutigen Switch‐ID identifiziert. openflow.spanning_tree muss zusammen mit dem openflow.discovery‐Modul verwendet werden. Es nutzt die erkannte Topologie, um darin einen Spannbaum zu bilden. Anschließend werden Konfigurationsnachrichten an die Switches gesendet, um das Flooding auf den Verbindungen zu deaktivieren, die nicht im Spannbaum enthalten sind. So kann verhindert werden, dass Broadcasts in Topologien mit redundanten Pfaden bzw. Schleifen das Netzwerk unbrauchbar machen. 15 forwarding.l2_pairs sorgt dafür, dass sich OpenFlow‐Switches wie normale Layer 2 Switches verhalten (Flooding für unbekannte Ziel‐MAC‐Adresse, gezielte Weiterleitung für bekannte Ziel‐ MAC‐Adresse). Sobald die benötigten MAC‐Adressen gelernt wurden, werden entsprechende Flow‐Einträge in den Switches installiert. Für Topologien mit Schleifen muss dieses Modul zusammen mit openflow.discovery und openflow.spanning_tree verwendet werden. Die von POX gebotenen Funktionen und Module sind ein guter Ausgangspunkt zur Entwicklung eigener Module, da man sich voll auf die Implementierung neuer Funktionen konzentrieren kann, ohne sich mit der Implementierung des OpenFlow‐Protokolls befassen zu müssen. Zusätzlich können einige bestehende Module weiterverwendet werden (z.B. Topologieerkennung) oder als Startpunkt für die eigenen Module verwendet werden. Die derzeit umfangreichste Dokumentation zu den Funktionen von POX ist [15]. 3 Implementierung Im Rahmen dieser Arbeit wurden Mininet und OpenFlow auch praktisch eingesetzt. Dabei wurde das Ziel verfolgt, die Einsetzbarkeit sowie mögliche Vorteile von SDN in einem System zur echtzeitfähigen Datenübertragung zu bewerten. Da bei einer echtzeitfähigen Datenübertragung die Einhaltung von maximalen Übertragungszeiten garantiert werden muss, ist vor allem die Messung der Round Trip Time (RTT) des Netzwerks interessant. Daher wurde in Mininet eine Vielzahl von Messungen mit Hilfe des ping‐Tools durchgeführt, um entsprechende Daten für mittels OpenFlow gesteuerte Netzwerke zu sammeln. Für ein Echtzeitsystem ist dabei vor allem die maximale RTT von Bedeutung, sowie die Schwankung der Messwerte, um die Zuverlässigkeit des Systems hinsichtlich der RTT zu beurteilen. Außerdem wurde der Einfluss der gleichzeitigen Kommunikation mehrerer Endgeräte (mehrere sendende Geräte innerhalb eines Netzwerkes) auf die RTT untersucht und Optimierungsmöglichkeiten durch verschiedene Topologien und Routingverfahren analysiert. 3.1 Testaufbau und Durchführung Alle Messungen wurden mit Hilfe eines Python‐Skriptes und unter der Verwendung der Python API von Mininet ausgeführt. Der Ablauf des Skriptes wird im Folgenden beschrieben. Zu Beginn werden Topologie und Controller ausgewählt und das Netzwerk gestartet. Dann wird das Address Resolution Protocol (ARP) auf allen Hosts deaktiviert. Dies ist notwendig, damit im Laufe der Messungen keine unerwünschten ARP‐Pakete auftreten, die zu Verzögerungen in den Switches führen können und die Ergebnisse somit negativ beeinflussen würden. Stattdessen werden auf allen Hosts permanente ARP‐Tabellen installiert, welche jeweils die IP‐MAC‐Adressenzuordnung aller anderen Hosts beinhalten. Die dafür benötigten Informationen (IP‐ und MAC‐Adressen aller Hosts) und Operationen sind durch Mininet verfügbar, da dieses globale Informationen besitzt und Befehle an alle Hosts senden kann. Anschließend wird das Trafficmuster festgelegt. In den hier durchgeführten Messungen besteht der Traffic aus einfachen ICMP Echo Request/Reply‐Paketen. Das Trafficmuster gibt an, welche Hosts gleichzeitig ein ICMP Echo Request senden und welche Zielhosts dabei verwendet werden. Unter Verwendung dieses Trafficmusters wird die Trainingsphase gestartet. In dieser werden die für die Messung vorgesehenen Pings bereits einmal ausgeführt, was zur Installation der passenden Einträge in den Flow‐Tabellen der OpenFlow‐Switches führt. Um sicher zu stellen, dass während der Messung keine (vergleichsweise langsame) Kommunikation zwischen Switches und Controller mehr nötig ist, werden für diese Einträge keine Timeouts eingestellt. Die durch den Controller installierten Routen werden durch eine Analyse der Flow‐Tabellen aller Switches ermittelt. Zuletzt wird die Messung durchgeführt. Dabei werden alle dem vorgesehenen Trafficmuster entsprechenden ICMP Echo Requests gleichzeitig (soweit dies in Software möglich ist) ausgelöst und die gemessene RTT protokolliert. Für eine Messreihe wird dieser Schritt 500‐mal wiederholt und aus den gesammelten 16 Daten die minimale, maximale und durchschnittliche RTT sowie die Standardabweichung berechnet. Darüber hinaus wird mit Wireshark überwacht, dass während der Messung keine unerwünschten Pakete (z.B. Flow Modification‐Nachrichten) versendet werden. Während des gesamten Ablaufs werden zusätzlich möglichst viele Daten protokolliert, um die Messungen auch im Nachhinein überprüfbar und nachvollziehbar zu machen. Zu diesen Daten zählen u.a. verwendeter Controller, verwendete Topologie, ARP‐Tabellen der Hosts, Flow‐Tabellen der Switches, ermittelte Routen, Flooding‐Konfiguration der Switches und die gemessenen Antwortzeiten der ICMP Echo Requests. Für die unterschiedlichen Teile des Experimentes wurden im Skript nur die verwendete Topologie, der Controller und das Trafficmuster ausgetauscht, während der weitere Ablauf identisch war. Alle virtuellen Ethernetverbindungen wurden auf eine Geschwindigkeit von 1 Mbit/s begrenzt und die Payload der ICMP Echo Requests auf 1472 Bytes eingestellt. Hierfür gibt es verschiedene Gründe. Durch diese Konfiguration sollen möglichst hohe Messwerte für die RTT erzeugt werden, damit Einflüsse durch den Scheduler und die Ungenauigkeit der Zeitmessungen um Größenordnungen unterhalb der RTT liegen. Auch eine CPU‐Limitierung der Emulation bei größeren Netzwerken ist durch die Konfiguration langsamer Ethernetverbindungen vermeidbar. Außerdem haben die gewählten Einstellungen bedeutende Auswirkungen bei der Messung des Einflusses von paralleler Kommunikation auf die Übertragungszeiten. Wenn zwei Hosts gleichzeitig Daten in einem Netzwerk übertragen kommt es nur zu einer gegenseitigen Beeinflussung, wenn zwei Pakete gleichzeitig in einem Switch verarbeitet werden müssen und daher die Verarbeitung von einem der Pakete möglicherweise (z.B. wenn beide den gleichen Ausgangsport benötigen) verzögert wird. In der Realität tritt diese Situation bei vielen gleichzeitig sendenden Endgeräten auch bei schnellen Ethernetverbindungen (z.B. 100 Mbit/s, 1 Gbit/s) zufällig auf. Auf Grund der sehr kurzen Sendedauer (ca. 12 µs für 1500 Bytes bei 1 Gbit/s) ist es jedoch bei schnellen Ethernetverbindungen problematisch, die gleichzeitige Verarbeitung von zwei Paketen in einem Switch gezielt herbeizuführen. Ein geringer Unterschied im Sendezeitpunkt (von den Hosts aus) führt dazu, dass das erste Paket den Switch beim Eintreffen des zweiten Paketes bereits wieder verlassen hat. Langsame Ethernetverbindungen und große Pakete erhöhen die Sendedauer und erleichtern so die gezielte Erzeugung von Verzögerungen durch parallele Kommunikation. Bevor in Kapitel 3.2 näher auf dieses Verhalten eingegangen wird, sollen zunächst die verwendeten Topologien, Trafficmuster und Messergebnisse gezeigt werden. 3.1.1 Sterntopologie (Single Switch) H16 H1 H2 H4 H5 S1 H15 H14 H3 H13 H12 H6 H7 H11 H10 H9 H8 Abbildung 5: Single Switch Topologie Für die ersten Messreihen wird eine einfache Sterntopologie verwendet, bei der 16 Hosts über einen einzigen Open vSwitch kommunizieren (Abbildung 5). Als Controller kommt das forwarding.l2_pairs‐ Modul des POX‐Frameworks (siehe Kapitel 2.4) zum Einsatz. Die Messungen werden mit zwei 17 verschiedenen Trafficmustern durchgeführt. Im ersten Fall sendet ein Host einen ICMP Echo Request an einen anderen Host, während alle weiteren Hosts inaktiv sind. Im zweiten Fall werden acht Paare gebildet und es senden acht Hosts gleichzeitig einen ICMP Echo Request an ihren Partner. Diese Topologie wurde verwendet, um das allgemeine Verhalten der Switches an einem einfachen Beispiel zu ermitteln. So sollte die RTT bei Übertragung über einen Switch bestimmt werden und verifiziert werden, dass parallele Kommunikation keine Auswirkungen hat, solange unterschiedliche Ethernetverbindungen genutzt werden. Quelle H1 Ziel H2 Maximale RTT [ms] Mittlere RTT [ms] 2.842 0.229 Standardabweichung [ms] 0.217 Tabelle 1: Single Switch‐Topologie mit einem sendenden Host Quelle H1 H3 H5 H7 H9 H11 H13 H15 Ziel H2 H4 H6 H8 H10 H12 H14 H16 Maximale RTT [ms] 0.508 4.186 16.12 8.698 14.012 6.7 0.995 3.257 Mittlere RTT [ms] 0.083 0.094 0.118 0.111 0.121 0.111 0.090 0.094 Standardabweichung [ms] 0.068 0.206 0.721 0.452 0.669 0.403 0.094 0.168 Tabelle 2: Single Switch‐Topologie mit acht sendenden Hosts 3.1.2 Binärbaumtopologie Die folgenden Messreihen wurden auf einer Binärbaumtopologie (Abbildung 6) mit insgesamt 15 Switches und 16 Hosts durchgeführt. Das forwarding.l2_pairs‐Modul des POX‐Frameworks wurde weiterhin zur reaktiven Installation von Flow‐Einträgen genutzt. S1 S2 S9 S6 S3 S4 H1 H2 S5 H3 S10 S7 H4 H5 S8 H6 H7 S11 H8 H9 S13 S12 H10 H11 S14 H12 H13 S15 H14 H15 H16 Abbildung 6: Binärbaumtopologie mit Routen zwei verschiedener Trafficmuster. Rote Pfeile zeigen die Routen des Trafficmusters der Tabelle 7 (keine überlappenden Pfade). Grüne Pfeile zeigen die Routen des Trafficmusters der Tabelle 8 (teilweise überlappende Pfade). Alle Pfeile zeigen in Richtung der ICMP Echo Requests (ICMP Echo Response nutzt jeweils die gleiche Route in Gegenrichtung). Überlappende Pfade eines Trafficmusters können anhand unterschiedlicher Linientypen unterschieden werden. 18 Die Trafficmuster umfassen das Senden von ICMP Echo Requests von nur einem Host an verschiedene Ziele (Tabelle 3 bis Tabelle 6), das gleichzeitige Senden von mehreren ICMP Echo Requests zwischen Hosts mit nicht überlappenden Pfaden (Tabelle 7), sowie das gleichzeitige Senden zwischen Hosts mit überlappenden Pfaden (Tabelle 8). Die Messreihen mit dieser Topologie sollten zeigen, dass die RTT proportional zur Anzahl der durchlaufenen Switches ist und dass die parallele Kommunikation über unterschiedliche Pfade keinerlei Verzögerung verursacht, während eine beliebige Überschneidung der Pfade Verzögerungen hervorruft. Außerdem wird deutlich, dass diese Topologie nur sehr wenige Kombinationen von paralleler Kommunikation ermöglicht, da keine unterschiedlich wählbaren Pfade zwischen Hosts existieren. Für eine umfangreiche parallele Kommunikation beliebiger Hosts wird also eine bessere Topologie benötigt. Quelle H1 Ziel H2 Maximale RTT [ms] Mittlere RTT [ms] 31.441 0.245 Standardabweichung [ms] 1.409 Tabelle 3: Binärbaumtopologie mit Sendevorgang über einen Hop Quelle H1 Ziel H4 Maximale RTT [ms] Mittlere RTT [ms] 7.949 0.271 Standardabweichung [ms] 0.412 Tabelle 4: Binärbaumtopologie mit Sendevorgang über drei Hops Quelle H1 Ziel H8 Maximale RTT [ms] Mittlere RTT [ms] 6.762 0.360 Standardabweichung [ms] 0.383 Tabelle 5: Binärbaumtopologie mit Sendevorgang über fünf Hops Quelle H1 Ziel H16 Maximale RTT [ms] Mittlere RTT [ms] 13.011 0.443 Standardabweichung [ms] 0.634 Tabelle 6: Binärbaumtopologie mit Sendevorgang über sieben Hops Quelle H1 H3 H5 H9 H13 Ziel H16 H4 H8 H12 H14 Maximale RTT [ms] 9.144 1.26 6.449 4.672 1.359 Mittlere RTT [ms] 0.270 0.090 0.156 0.146 0.095 Standardabweichung [ms] 0.556 0.094 0.307 0.228 0.107 Tabelle 7: Binärbaumtopologie mit fünf sendenden Hosts und nicht überlappenden Pfaden Quelle H1 H2 H5 H7 H15 Ziel H4 H3 H12 H10 H16 Maximale RTT [ms] 38.301 30.516 40.628 32.139 1.731 Mittlere RTT [ms] 3.430 3.500 3.768 3.045 0.094 Standardabweichung [ms] 5.418 5.435 5.563 4.959 0.106 Tabelle 8: Binärbaumtopologie mit fünf senden Hosts und teilweise überlappenden Pfaden 3.1.3 Mesh Grid‐Topologie Die Topologie für die folgenden Messreihen war eine quadratische Gitterstruktur mit 16 Switches und 16 Hosts (Abbildung 7). Der POX‐basierte Controller wurde in diesem Fall mit den Modulen forwarding.l2_pairs, openflow.spanning_tree und openflow.discovery betrieben. Es wurden zwei verschiedene Trafficmuster mit paralleler Kommunikation getestet, eins mit und eins ohne überlappende Pfade. Die am Binärbaum gewonnenen Erkenntnisse über den Einfluss paralleler Kommunikation sollten hierbei verifiziert werden. Darüber hinaus ist bei dieser Topologie auch die Betrachtung der Controller‐Logik interessant. Im Gegensatz zum Binärbaum bestehen in der Gitterstruktur verschiedene Pfade zwischen zwei Hosts, sodass mehr Kombinationen paralleler Kommunikation ohne Verzögerungen möglich sind, da überlappende Pfade durch die Wahl eines 19 alternativen Weges vermieden werden können. Das Problem ist dabei die Unterstützung dieser zusätzlichen Pfade durch den Controller. H1 H5 H9 S1 S5 H2 H6 H3 S2 H7 S6 H4 S3 H8 S7 S4 S8 S9 H10 S10 H11 S11 H12 S12 H13 S13 H14 S14 H15 S15 H16 S16 Abbildung 7: Mesh Grid‐Topologie mit Routen zwei verschiedener Trafficmuster. Rote Pfeile zeigen die Routen des Trafficmusters der Tabelle 7 (keine überlappenden Pfade). Grüne Pfeile zeigen die Routen des Trafficmusters der Tabelle 10 (überlappende Pfade). Alle Pfeile zeigen in Richtung der ICMP Echo Requests (ICMP Echo Response nutzt jeweils die gleiche Route in Gegenrichtung). Überlappende Pfade eines Trafficmusters können anhand unterschiedlicher Linientypen unterschieden werden. Das forwarding.l2_pairs‐Modul unterstützt redundante Pfade bzw. Schleifen im Netzwerk nicht, da es ein einfaches Layer 2 Switch Verhalten nachbildet. Ohne zusätzliche Maßnahmen würde das Fluten von Paketen mit bisher unbekannter Ziel‐MAC‐Adresse zu zirkulierenden Paketen führen und das Netzwerk funktionsuntüchtig machen. Daher werden zusätzlich openflow.discovery und openflow.spanning_tree aktiviert, welche eine Topologieerkennung durchführen, einen Spannbaum zu dieser Topologie ermitteln und das Flooding nur noch auf den im Spannbaum enthaltenen Verbindungen erlauben. Dadurch wird die Funktionalität des Netzwerkes bei Nutzung einer einfachen Layer 2 Switch‐Logik wiederhergestellt. Die nicht im Spannbaum enthaltenen Pfade können dadurch jedoch nicht mehr genutzt werden und der Vorteil der redundanten Pfade der ursprünglichen Topologie geht verloren. Der Bedarf nach einem besseren Routingverfahren wird anhand der in Abbildung 7 gezeigten Routen sofort deutlich. Im Falle des Trafficmusters der Tabelle 10 (grün markierte Routen) sind beispielsweise starke Verzögerungen durch überlappende Routen ersichtlich, obwohl die Topologie kürzere, exklusive Routen bieten würde. Quelle H13 H16 H14 Ziel H9 H5 H10 Maximale RTT [ms] 2.014 10.453 1.149 Mittlere RTT [ms] 0.140 0.314 0.137 Standardabweichung [ms] 0.168 0.546 0.114 Tabelle 9: Mesh Grid‐Topologie mit drei sendenden Hosts und nicht überlappenden Pfaden 20 Quelle H13 H9 H6 H11 H3 Ziel H1 H5 H4 H8 H12 Maximale RTT [ms] 101.356 68.293 66.044 54.371 75.167 Mittlere RTT [ms] 22.438 23.007 14.671 12.398 18.428 Standardabweichung [ms] 17.548 17.309 14.205 12.613 14.731 Tabelle 10: Mesh Grid‐Topologie mit fünf senden Hosts und überlappenden Pfaden 3.1.4 FatTree‐Topologie Die letzte Messreihe sollte zeigen, wie effizient parallele Kommunikation sein kann, wenn eine passende Topologie genutzt wird, sowie ein Controller, der das vorhandene Potential der Topologie nutzen kann. Bei der hier verwendeten FatTree‐Topologie [19] handelt es sich um eine hierarchische Topologie, welche für eine effiziente Vernetzung von Rechenzentren entworfen wurde und folgende Vorteile bieten soll [19]: 1. Das Netzwerk soll ausreichend Bandbreite bieten, um die Gesamtbandbreite der angeschlossenen Hosts vollständig nutzbar zu machen (realisiert durch redundante Pfade und gleiche Bisektionsbandbreite auf allen Ebenen des Baumes). 2. Es sollen gleichartige und kostengünstige Switches im gesamten Netzwerk eingesetzt werden. 3. Das Netzwerk soll problemlos skalierbar sein. Eine entsprechende Topologie für 16 Hosts ist in Abbildung 8 zu sehen. Die Bezeichnungen für Hosts und Switches sind an [19] angelehnt. 411 002 412 421 422 021 031 121 131 221 231 321 331 001 011 101 111 201 211 301 311 003 012 013 102 103 112 113 202 203 212 213 302 303 312 313 Abbildung 8: FatTree‐Topologie mit sechs sendenden Hosts und zufälligem Routing durch RipL‐POX (Tabelle 11). Rote Pfeile zeigen die Routen der ICMP Echo Requests. Grüne Pfeile zeigen die Routen der ICMP Echo Responses. Überlappende Routen können durch unterschiedliche Linientypen unterschieden werden. Für die Emulation einer FatTree‐Topologie in Mininet wurde die „Ripcord Lite“ (RipL) Python Bibliothek [20] verwendet. Wie bereits bei der Mesh Grid‐Topologie angemerkt deaktivieren einfache Controller bzw. Routingverfahren die redundanten Pfade und nutzen das Potential der Topologie nicht angemessen. Daher wurde für die FatTree‐Topologie das POX‐Modul „Ripcord Lite for POX“ (RipL‐POX) [21] verwendet. Dieses bietet verschiedene Routingverfahren, um die redundanten Pfade der Topologie nutzbar zu machen. Für den Test wurde RipL‐POX so konfiguriert, dass Flows reaktiv installiert werden und die verwendeten Pfade zufällig aus einer zuvor berechneten Menge gültiger Pfade ausgewählt werden. Es ist also damit zu rechnen, dass die redundanten Pfade genutzt werden, durch die zufällige Auswahl aber nicht das bestmögliche Routing erreicht wird. Mit dieser Topologie wurde nur ein Trafficmuster getestet (Tabelle 11). 21 Quelle 002 003 102 112 113 312 Ziel 013 012 213 203 303 313 Maximale RTT [ms] 2.43 8.21 30.249 37.513 3.852 3.619 Mittlere RTT [ms] 0.148 0.143 2.803 3.047 0.187 0.100 Standardabweichung [ms] 0.168 0.373 4.583 4.843 0.208 0.190 Tabelle 11: FatTree‐Topologie mit sechs sendenden Hosts und zufällig ausgewählten Pfaden 3.2 Theoretischer Hintergrund 3.2.1 Realer Hardwareaufbau Um die Ergebnisse verstehen zu können, muss man betrachten, wie sich ein realer Hardwareaufbau in Bezug auf die RTT bzw. Latenzen verhält und wie dieses Verhalten durch die Emulation nachgebildet wird. Ein ICMP Echo Request mit einer Nutzlast von 1472 Bytes ist einschließlich ICMP (8 Byte), IP (20 Bytes) und Ethernet (14 Bytes) Header 1514 Bytes groß. Mit Frame Check Sequence (FCS, 4 Bytes), Präambel (7 Bytes) und Start Frame Delimiter (SFD, 1 Byte) ergeben sich 1526 Bytes, die physikalisch übertragen werden müssen. Bei einer 1 Mbit/s Ethernetverbindung ergibt sich somit eine reine Sendedauer von 12,208 ms. Da das ICMP Echo Reply‐Paket die gleiche Größe und Sendedauer besitzt, ergibt sich bereits eine RTT von mindestens 24,416 ms. Hinzu kommen noch weitere Verzögerungen durch Switches sowie die Übertragungsdauer durch die Kabel. Die Übertragungsdauer ist von den Kabellängen abhängig (hier vernachlässigbar), die Verzögerung durch Switches ist implementierungsabhängig. Im Falle von Switches, welche die Auswertung des Headers bereits vor dem Erhalt des vollständigen Paketes durchführen und so früh wie möglich mit der Weiterleitung beginnen (Cut‐through‐Switching), kann eine sehr geringe zusätzliche Verzögerung pro Switch (< 1ms) erreicht werden. Bei Switches, die erst das vollständige Paket empfangen und dann mit der Auswertung des Header und der Weiterleitung beginnen (Store‐and‐Forward‐Switching), entspricht die Verzögerung pro Switch mindestens der Sendedauer. Zur Vereinfachung soll hier angenommen werden, dass ein realer Hardwareaufbau mit Cut‐through‐Switching realisierbar ist, sodass kaum Verzögerungen durch Switches entstehen. Bei Trafficmustern mit sich nicht überschneidenden Routen wäre also insgesamt eine mittlere RTT von ca. 25 ms zu erwarten. Abgesehen von der RTT selbst wurden im Experiment Standardabweichung und Maximalwert der RTT betrachtet. Hier kann man davon ausgehen, dass die Standardabweichung der RTT in einem realen Netzwerk sehr gering ausfällt und der Maximalwert nur geringfügig vom Mittelwert abweicht. Der Grund dafür ist, dass die Paketverarbeitung bekannter Flows in typischen Switch‐Implementierungen vollständig in Hardware ausgeführt wird und daher ein sehr gut vorhersagbares Verhalten besteht. Der Einfluss des Netzwerkes auf die RTT ist also nahezu konstant. Unterschiede entstehen hauptsächlich durch die in Software ausgeführte Verarbeitung in den Hosts. Im Falle von zwei sich überlappenden Routen wird das zuerst im Switch eintreffende Paket nicht zusätzlich verzögert, während das zweite eine Verzögerung von ca. 12 ms erfährt (Sendevorgang des ersten Paketes). Geht man davon aus, dass es vom Zufall abhängt, welches der Pakete der beiden sendenden Hosts zuerst ankommt, so ist bei beiden Hosts gegenüber der Situation mit nicht überlappenden Pfaden ein Anstieg der mittleren RTT um 6 ms und der maximalen RTT um 12 ms zu erwarten. Obwohl dieser Abschnitt noch keine detaillierte Analyse des Verhaltens realer Netzwerk darstellt, ist diese Sichtweise für einen Vergleich mit der Arbeitsweise von Mininet und eine Beurteilung der Messwerte ausreichend und das Thema soll in dieser Arbeit nicht weiter ausgeführt werden. 22 3.2.2 Emulation mit Mininet An den in Kapitel 3.1 gezeigten Ergebnissen ist leicht erkennbar, dass dieses Verhalten nur unzureichend in Mininet nachgebildet wird. Die grundlegenden Unterschiede zum zuvor beschriebenen theoretischen Verhalten eines realen Netzwerkes sind: Deutlich zu niedrige mittlere RTT (< 1 ms) bei nicht überlappenden Pfaden Anstieg der mittleren RTT im Falle von zwei überlappenden Pfaden (Tabelle 8, Tabelle 11) ist niedriger als die erwarteten 6 ms Sehr große Standardabweichung bei allen Messungen Maximalwerte sind deutlich vom Mittelwert abweichende, zufällige Ausreißer In der Emulation gibt es zwei wichtige Einflüsse, die für diese Abweichungen verantwortlich sind: Das Scheduling der Prozesse und die Funktionsweise der Bandbreitenkontrolle. Das Scheduling kann die Messung auf zwei Arten beeinflussen. Zum einen kann es vorkommen, dass Pakete verzögert werden, indem der gerade für die weitere Verarbeitung des Paketes zuständige Prozess nicht sofort bei der Ankunft des Paketes ausgeführt wird. Zum anderen ist es möglich, dass zwei Hosts, die gleichzeitig senden und durch überlappende Pfade eine Verzögerung von einem der Pakete erzeugen sollten, mit zu großem zeitlichen Abstand ausgeführt werden und der gegenseitige Einfluss der Pakete dadurch sinkt oder sogar verschwindet. Die Funktionsweise der Bandbreitenkontrolle hat einen Einfluss auf die Messungen, da sie dafür verantwortlich ist, neben der Bandbreite auch die Verzögerungseigenschaften von 1 Mbit/s Ethernetverbindungen nachzubilden. Der Einfluss von Bandbreitenkontrolle und Scheduling ist damit sehr unterschiedlich. Die Bandbreitenkontrolle bestimmt, ob die Emulation überhaupt ein realistisches Verhalten bezüglich der RTT besitzt, während das Scheduling nur zufällige Messfehler verursacht. Im Folgenden soll daher die Funktionsweise der Bandbreitenkontrolle näher erläutert werden. Die Bandbreite der virtuellen Ethernetverbindungen wird in Mininet mit Hilfe des Linux Traffic Control Tools konfiguriert. Dabei handelt es sich um ein komplexes Tool, welches nicht nur eine Bandbreitenbegrenzung für virtuelle Ethernetadapter bietet, sondern eine umfangreiche Konfiguration von Quality of Service (QoS)‐Mechanismen für alle im System vorhandenen realen und virtuellen Netzwerkadapter erlaubt. Über eine einfache Limitierung der Übertragungsrate hinaus ist es z.B. möglich, Pakete nach Flows zu klassifizieren und unterschiedlich zu behandeln. So können Pakete einzelner Programme bevorzugt behandelt werden, um geringe Latenzen sicherzustellen oder es können Teile der Bandbreite für bestimmte Programme reserviert werden. Hierarchische Strukturen zur Paketklassifizierung und verschiedene Scheduling‐Verfahren für Pakete (Entscheidung, in welcher Reihenfolge Pakete gesendet werden) ermöglichen eine Anpassung von Netzwerkadaptern auf viele verschiedene Anwendungsszenarien. Eine detaillierte Beschreibung der Funktionsweise und der Möglichkeiten der Linux Traffic Control kann in den Quellen [22] und [23] gefunden werden. Im folgenden Abschnitt werden nur einige wichtige Features vorgestellt, welche in Mininet Verwendung finden und somit für die Auswertung der Messergebnisse relevant sind. 3.2.2.1 Traffic Control Unter Linux ist jedem Netzwerkadapter eine eigene Queue zugeordnet. Daten, die über einen bestimmten Adapter gesendet werden sollen, werden der zugehörigen Queue übergeben. Die Verarbeitung durch die Queue befindet sich sehr weit unten im Netzwerkstack und ist nach dem OSI‐ Referenzmodell in die Schicht 2 einzuordnen. An die Queue werden demnach vollständige Ethernet Frames inklusive des Ethernet Headers zur weiteren Verarbeitung übergeben. Mit einer maximalen Nutzlast von 1500 Bytes und einem 14 Bytes großen Header ergibt sich eine maximale Framelänge von 1514 Bytes. Präambel, SFD und FCS werden nur von der Hardware verwendet und daher in der Verarbeitung durch die Queue nicht berücksichtigt. Die Verarbeitung von Frames durch die Queue 23 hängt von der verwendeten Implementierung ab. In Linux existieren verschiedene als Queuing Disciplines (qdisc) bezeichnete Queue‐Implementierungen, welche einem Netzwerkadapter mit Hilfe des Traffic Control Tools zugeordnet werden können. Standardmäßig ist jedem Netzwerkadapter die pfifo_fast qdisc zugeordnet. Diese qdisc analysiert die Type of Service (ToS)‐Bits des IP‐Headers der Pakete und ordnet sie an Hand dieser Bits in 3 Prioritäten ein. Für jede der drei Prioritäten existiert ein eigener First In First Out (FIFO)‐Speicher, in den die Pakete eingereiht werden. Pakete aus einem FIFO Speicher mit höherer Priorität werden immer vor den Paketen aus einem FIFO‐Speicher mit niedrigerer Priorität gesendet. Da diese qdisc keine weiteren Konfigurationsmöglichkeiten wie z.B. eine Bandbreitenbegrenzung erlaubt, ordnet Mininet den virtuellen Ethernetadaptern andere qdiscs zu, sobald eine Bandbreite vorgegeben wird. Für die im Rahmen dieser Arbeit durchgeführten Messungen wurde die Token Bucket Filter (TBF) qdisc verwendet. Die TBF qdisc ist eine einfache FIFO Queue mit einem Mechanismus zur Bandbreitenbegrenzung. Bei diesem Mechanismus werden Tokens in einem Behälter (Bucket) gesammelt, wobei ein Token einer Sendeerlaubnis für ein Byte entspricht. Der Behälter wird kontinuierlich mit einer konfigurierbaren Rate mit Tokens aufgefüllt. Soll ein Frame gesendet werden, so wird geprüft, ob ausreichend Tokens (entsprechend der Framelänge in Bytes) im Bucket vorhanden sind. Falls dies zutrifft, werden entsprechend viele Tokens aus dem Bucket entfernt und der Frame ohne jegliche Verzögerung zum Senden an den zugehörigen Ethernetadapter weitergereicht. Andernfalls wird das Paket verzögert, bis ausreichend Tokens im Bucket vorhanden sind. Durch dieses einfache Prinzip kann die Senderate des zugehörigen Ethernetadapters über einen längeren Zeitraum betrachtet die Füllrate des Buckets nicht übersteigen. Die Begrenzung arbeitet somit jedoch frameweise und nicht byteweise. Von der Queue an den Ethernetadapter übergebene Frames werden also weiterhin mit der normalen Geschwindigkeit des Ethernetadapters gesendet. Die Sendedauer von Frames und somit auch die RTT des Netzwerkes werden durch dieses Verfahren der Bandbreitenbegrenzung also nicht passend nachgebildet. Stattdessen hängt die Verzögerung eines Frames vom Füllstand des Buckets beim Eintreffen in der Queue sowie der Geschwindigkeit des darunterliegenden Ethernetadapters ab. Im Falle der virtuellen Ethernetadapter kann die Verzögerung durch den Adapter vollständig vernachlässigt werden, da dessen Geschwindigkeit nur durch die verwendete Hardware (CPU, RAM) begrenzt wird. Das Token Bucket‐Prinzip alleine reicht jedoch nicht aus, um das reale Zeitverhalten eines Ethernetadapters nachzubilden. Wenn keine Frames gesendet werden, füllt sich das Bucket immer weiter, bis die konfigurierbare maximale Anzahl an Tokens gesammelt wurde. Weitere eintreffende Tokens werden verworfen. Nach einer längeren Sendepause stehen also viele Tokens zur Verfügung und der erste zu sendende Frame wird daher nie durch die qdisc verzögert. In Abhängigkeit von der Bucketgröße werden noch weitere Frames ohne jegliche Verzögerung und mit einer höheren Datenrate als im TBF konfiguriert gesendet (Burst). Dieses Verhalten ist von großer Bedeutung für die durchgeführten Messungen. Auf Grund des zeitlichen Abstands zwischen den durchgeführten Pings kann davon ausgegangen werden, dass sämtliche Buckets zu Beginn eines Sendevorgangs vollständig gefüllt sind. Dies erklärt bereits, warum die mittlere RTT bei sämtlichen Trafficmustern ohne überlappende Routen bei unter einer Millisekunde liegt, obwohl man bei der Verwendung von 1 Mbit/s Verbindungen theoretisch wesentlich höhere Verzögerungen erwarten würde. Außerdem folgt aus dem beschriebenen Mechanismus, dass die Buckets so klein sein müssen, dass sie nach dem Senden eines Paketes leer sind und auf neue Tokens gewartet werden muss. Daher wurde eine Bucketgröße von 1514 konfiguriert. Wählt man wesentlich größere Buckets, so sind stets genügend Tokens vorhanden, um bei überlappenden Routen alle ICMP Pakete ohne Verzögerung zu übertragen. Der Einfluss paralleler Kommunikation wäre somit praktisch nicht messbar. Anmerkung: Ursprünglich hat die standardmäßige Konfiguration von Mininet genau dieses Problem verursacht. Bezüglich der RTT konnten keinerlei Eigenschaften eines realen Netzwerkes mit 1 Mbit/s 24 Ethernetverbindungen erfasst werden. Unabhängig vom Trafficmuster lag der Mittelwert der RTT bei unter einer Millisekunde und überlappende Routen zeigten keine messbare Auswirkung. Der Grund hierfür war die standardmäßige Verwendung einer qdisc mit einem 15000 Byte großen Bucket, sodass stets genügend Tokens für das sofortige Weiterleiten mehrerer ICMP Pakete hintereinander zur Verfügung standen. Die Analyse dieses Problems sowie das Auffinden der zuvor beschriebenen Konfiguration, mit der sinnvolle Ergebnisse erzeugt werden konnten, gestaltete sich zunächst als schwierig, da die Dokumentation von Mininet nur sehr wenige Information darüber bietet, wie die Bandbreitenlimitierung arbeitet und inwiefern die Eigenschaften realer Ethernetadapter nachgebildet werden. Darüber hinaus bietet die Python API von Mininet nur eingeschränkte Konfigurationsmöglichkeiten für die Traffic Control. Die Größe des Buckets lässt sich über die API beispielsweise nicht konfigurieren, sondern wird nach dem Erstellen des virtuellen Netzwerkes nachträglich mit Hilfe der Traffic Control angepasst. 3.3 Ergebnisanalyse Nachdem die der Emulation zu Grunde liegenden Funktionsweisen beschrieben wurden, können die Ergebnisse aus Kapitel 3.1 vollständig erklärt werden. Für alle Topologien und Trafficmuster ist die mittlere RTT von unter einer Millisekunde bei nicht überlappenden Routen dadurch erklärbar, dass zum Sendezeitpunkt sämtliche Buckets vollständig gefüllt sind und die Traffic Control daher keinerlei Verzögerungen verursacht. Das Bandbreite und Verzögerung von den darunter liegenden virtuellen Ethernetadaptern nur von der zur Verfügung stehenden Rechenleistung abhängig sind, bedeutet, dass die aufgenommenen Messwerte nur vom Scheduling der an der Paketweiterleitung beteiligten Prozesse abhängen. Da die Messungen in einer VM durchgeführt wurden, beeinflussen sowohl der Scheduler außerhalb der VM als auch der Scheduler innerhalb der VM die Messung. Da beide Scheduler nicht auf entsprechend latenzabhängige Prozesse optimiert sind und im Laufe einer Messreihe nicht bei jedem Ping exakt das gleiche Scheduling durchführen, schwanken die Messwerte stark. Daher ist die Standardabweichung der Messungen groß (größer als der Mittelwert) und bei den Maximalwerten handelt es sich um zufällige Ausreißer, die weit vom Mittelwert entfernt sind. Alle Messungen mit paralleler Kommunikation und nicht überlappenden Routen zeigen außerdem keine signifikanten Veränderungen der gemessenen Eigenschaften. Im Gegensatz zu den absoluten Messwerten der RTT und den großen Schwankungen entspricht dieses Verhalten dem, was man von einem realen Hardwareaufbau mit Switches erwarten würde: Pakete, die über unterschiedliche Ports weitergeleitet werden müssen, beeinflussen sich nicht. Des Weiteren kann man beobachten, dass Pakete über mehr Hops eine größere mittlere RTT sowie Standardabweichung besitzen (Tabelle 7 und Tabelle 9), da mehr Prozesse an der Weiterleitung der Pakete beteiligt sind. Dies entspricht ebenfalls dem Verhalten eines realen Hardwareaufbaus, in dem jeder durchlaufene Switch eine zusätzliche Verzögerung bedeutet (die genaue zeitliche Verzögerung ist implementierungsabhängig). Bei allen Messungen mit überlappenden Routen sind dagegen sowohl der Einfluss des Schedulings als auch der Bandbreitenbegrenzung durch die TBF qdisc relevant. Tabelle 8 zeigt eine entsprechende Messreihe mit überlappenden Pfaden in der Binärbaumtopologie. ICMP Echo Requests von H1 an H4 und von H2 an H3 treffen in S4 aufeinander und das etwas später im Switch angekommene Paket wird verzögert, weil es darauf warten muss, dass im Bucket (für die Verbindung zu S3) wieder ausreichend Tokens vorhanden sind. Da das Auffüllen des Buckets mit der konfigurierten Rate von 1 Mbit/s stattfindet, entspricht die dadurch hinzukommende Verzögerung des zweiten Paketes mit etwa 12 ms sehr gut der zu erwartenden Verzögerung eines entsprechenden Hardwareaufbaus. Obwohl auch nach der Übertragung von S4 zu S3 noch mehrfach die gleichen Verbindungen genutzt werden, kommt es zu keinen weiteren Verzögerungen, weil die Pakete durch die Verzögerung in S4 ausreichend zeitlichen Abstand besitzen um die Buckets zwischenzeitlich wieder zu füllen. Da es vom Zufall abhängt, welches der beiden ICMP Pakete zuerst in S4 eintrifft, kann davon ausgegangen werden, dass H1 und H2 jeweils 25 bei 50 % ihrer gesendeten Pakete eine um 12 ms erhöhte RTT messen. Daher sollte sich bei beiden eine mittlere RTT von 6 ms ergeben. Die Messwerte liegen leicht darunter, weil hier wieder der Einfluss des Schedulers deutlich wird. In vielen Fällen werden die ICMP Echo Requests von H1 und H2 zeitlich soweit versetzt gesendet, dass beim Eintreffen des zweiten Paketes in S4 bereits wieder einige Tokens im Bucket vorhanden sind und sich die Verzögerung entsprechend verkürzt. Auch die Maximalwerte unterliegen wieder dem zufälligen Einfluss des Schedulers. Allein durch die TBF qdisc wird nur eine maximale Verzögerung von etwa 12 ms verursacht. Die Standardabweichung ist bei den Messungen mit überlappenden Pfaden prinzipiell nicht aussagekräftig. Dieses Verhalten zeigt sich ebenfalls bei den Pings von H5 an H12 und H7 an H10 (Tabelle 8), wobei die Pakete hier in S6 verzögert werden. Die Pings von H15 an H16 nutzen exklusive Pfade und werden dementsprechend nicht verzögert. Die gleichen Prinzipien für überlappende Pfade gelten für die in Tabelle 10 ersichtlichen Messungen mit der Mesh Grid‐Topologie. Auf Grund der vielen überlappenden Pfade (siehe Abbildung 7) treten hier jedoch wesentlich mehr Verzögerungen durch die TBF qdisc auf und die mittlere RTT ist entsprechend höher. Insgesamt wird deutlich, dass Mininet das Zeitverhalten eines realen Netzwerkes zwar nicht detailliert nachbilden kann, aber der Einfluss von paralleler Kommunikation dennoch ersichtlich ist. Die bisher betrachteten Messungen von Binärbaumtopologie und Mesh Grid‐Topologie zeigen außerdem, dass neben der Topologie auch der Controller wichtig für eine effiziente parallele Kommunikation ist. Obwohl die Mesh Grid‐Topologie im Gegensatz zur Binärbaumtopologie viele alternative Routen bietet, können diese vom Controller nicht genutzt werden. Es entstehen große Verzögerungen, obwohl durch angepasstes Routing die gesamte Kommunikation des in Tabelle 10 gezeigten Trafficmusters auf exklusiven Pfaden ohne gegenseitige Beeinflussung stattfinden könnte. Aus diesem Grund wurde als letztes die FatTree‐Topologie zusammen mit dem RipL‐POX‐Controller betrieben. Das Konzept der FatTree‐Topologie, günstige, gleichartige Switches im gesamten Netzwerk zu nutzen, passt hervorragend zu den Zielen von SDN und OpenFlow. Darüber hinaus sind die zur Steigerung der Bandbreite vorgesehenen redundanten Pfade auch bestens geeignet, um parallele Kommunikation ohne gegenseitige Beeinflussung zu realisieren. Wie die in Abbildung 8 dargestellten Routen und die in Tabelle 11 aufgelisteten Messergebnisse zeigen, kann der RipL‐POX‐Controller die vorhandenen Pfade effektiv nutzen. Nur zwei der sechs durchgeführten Pings verzögern sich gegenseitig durch überlappende Pfade. Bei den ungestört gleichzeitig kommunizierenden Hosts sind Paare dabei, die in einer Binärbaumtopologie nicht ohne zusätzliche Verzögerungen miteinander kommunizieren können (002 und 013; 003 und 012; 113 und 303). Da RipL‐POX auf eine zufällige Routenauswahl konfiguriert war, können sich die Ergebnisse bei einer wiederholten Ausführung des Tests unterscheiden. Da RipL‐ POX kein Routingverfahren bietet, welches die gewählten Routen dynamisch an das Trafficmuster anpasst und überlappende Pfade effektiv vermeidet, ist dieser Controller noch nicht ausreichend für Anwendungen, welche eine Garantie für niedrige Verzögerungen erfordern (Echtzeitanwendungen). Dennoch konnte mit diesem Experiment das große Potential der Topologie demonstriert werden. 4 Optimierung einer Beispielapplikation Basierend auf der vorgestellten Funktionsweise von SDN mit OpenFlow und den durch das Experiment gewonnenen Erkenntnissen soll in diesem Kapitel beurteilt werden, inwiefern SDN und OpenFlow genutzt werden können, um Netzwerke für eine bestimmte Anwendung zu optimieren. Dabei soll zuerst auf die allgemeinen Möglichkeiten zur anwendungsorientierten Steuerung eines Netzwerkes eingegangen werden, bevor bewertet wird, welche Vor‐ und Nachteile der Einsatz von SDN in einem System zur echtzeitfähigen Datenübertragung mit sich bringt. 26 4.1 Anwendungsorientierte Controller Der OpenFlow‐Controller ist in einem Netzwerk dafür zuständig, korrekte Routen zwischen angeschlossenen Endgeräten zu finden und die verwendete Netzwerktopologie möglichst effizient zu nutzen. Gefundene Routen sollten idealerweise außerdem in den Flow‐Tabellen der Switches installiert werden, da das Netzwerk andernfalls durch die Weiterleitung aller Pakete an den Controller stark verlangsamt wird. Die Kommunikation mit den Switches erfolgt über das standardisierte OpenFlow‐Protokoll. Darüber hinaus gibt es jedoch keine Vorgaben für die Implementierung des Controllers. Die Komplexität des Controllers kann also von Layer 2 Switches über herkömmliche Layer 3 Router bis hin zu individuell angepassten Controllern reichen. Dadurch kann das Verhalten des Netzwerkes auf einfache und kostengünstige Weise vom Nutzer angepasst werden. Spezielle Hardware oder Unterstützung durch die Hersteller von Netzwerkhardware sind nicht erforderlich. Der Controller kann unter Berücksichtigung der vorhandenen Netzwerktopologie und der zu erwartenden Trafficmuster programmiert werden. Allgemein gibt es zwei mögliche Herangehensweisen bei der Optimierung eines Controllers für eine bestimmte Anwendung: 1. Statisches Szenario. Verwendete Netzwerktopologien und Trafficmuster der Anwendungen sind zum Zeitpunkt der Programmierung des Controllers bekannt. Im Controller können mit diesem Wissen effiziente Routingalgorithmen implementiert werden, ohne dass eine Kommunikation mit der Anwendung notwendig ist. 2. Dynamisches Szenario. Sowohl die Topologie als auch die Trafficmuster ändern sich im Laufe der Zeit. Um ein optimales Routing (z.B. hinsichtlich Bandbreite oder Latenzen) zu gewährleisten, muss der Controller die Topologie automatisch erkennen und darüber hinaus mit den Anwendungen kommunizieren, um Routing und Sendeverhalten aufeinander abzustimmen. Vor allem die Kommunikation zwischen Anwendung und Controller bietet ein großes Potential, allerdings sind derzeit noch keine hierfür vorgesehenen Northbound APIs standardisiert und weit verbreitet. Die Open Networking Foundation arbeitet an der Standardisierung einer oder mehrerer Northbound APIs [24], aber derzeit ist noch unklar, ob sich ein entsprechender Standard ähnlich zum OpenFlow‐Protokoll als Southbound API durchsetzen kann, da die zwischen Controller und Anwendung benötigte Kommunikation sehr spezifisch für die jeweilige Anwendung ist. Für experimentelle Zwecke ist das Fehlen einer standardisierten Northbound API jedoch kein Problem, da Code von Controller und Anwendung zur Verfügung stehen und entsprechend aufeinander angepasst werden können. 4.2 SDN und echtzeitfähige Datenübertragung Das am Institut angestrebte Einsatzgebiet für OpenFlow ist die Optimierung einer echtzeitfähigen Datenübertragung. Das derzeit vorhandene System verwendet Zeitschlitze, um einzelnen Netzwerkteilnehmern exklusiven Zugriff auf das gesamte Netzwerk zu ermöglichen. Dadurch soll vermieden werden, dass gleichzeitige Datenübertragungen zu unerwarteten und für ein Echtzeitsystem inakzeptablen Verzögerungen in Switches führen. Die Koordination des exklusiven Zugriffs erfolgt mittels einer Peer‐to‐Peer (P2P)‐Plattform und ohne eine zentrale Steuerung. Darüber hinaus sind bei diesem System kurzzeitige Unterbrechungen der Echtzeitkommunikation durch eine Wartungsphase vorgesehen, welche z.B. zur Synchronisation der Peers und der Aktualisierung spezieller Routingtabellen des P2P‐Systems benötigt wird. Zunächst soll betrachtet werden, inwiefern SDN in diesem System einsetzbar ist, ohne die Echtzeitfähigkeit zu beeinträchtigen. Das erste und wichtigste Kriterium ist die Realisierbarkeit echtzeitfähiger OpenFlow‐Switches. In Kapitel 2.2 wurde bereits erläutert, dass dies kein Problem ist. Typische Switch‐Implementierungen sehen vor, dass die Weiterleitung von Paketen bekannter Flows auch bei Nutzung von OpenFlow vollständig in Hardware ausgeführt wird. Das verwendete Prinzip zum Lookup der Flows (TCAMs) unterscheidet sich dabei nicht 27 von herkömmlichen Switches und Routern, sodass an dieser Stelle keine zusätzlichen Verzögerungen in das Netzwerk eingebracht werden. Dennoch werden auch neue Probleme eingeführt. Da nur für bekannte Flows das vorhersagbare, hardwarebasierte Switching genutzt werden kann, muss noch die Behandlung unbekannter Flows berücksichtigt werden. Diese werden vom Controller bearbeitet und gegebenenfalls passende Flow‐Einträge erstellt. Da es sich bei den bisher bekannten Controllern um normale Software ohne Anpassungen an die Echtzeitfähigkeit handelt, führt dies zu langen, unvorhersehbaren Verzögerungen der Pakete. Es gibt zwei mögliche Lösungen für dieses Problem. Die erste Möglichkeit ist die Implementierung eines echtzeitfähigen Controllers, welcher die reaktive Installation von Flow‐Einträgen beherrscht, ohne die für das Echtzeitsystem maximal zulässigen Übertragungszeiten zu verletzen. Dieser Lösungsansatz ist jedoch auf Grund der Implementierung des Controllers als relativ komplexe Software voraussichtlich nicht geeignet, wenn sehr kurze Übertragungszeiten gefordert sind. Die zweite Möglichkeit ist die proaktive Installation von Flow‐ Einträgen. Das bedeutet, dass der Controller alle benötigten Flow‐Einträge bereits vor dem Beginn der zeitkritischen Kommunikation installiert. Hierzu muss er neben der Topologie auch das kommende Trafficmuster kennen. Wie im vorigen Kapitel genannt, können Topologie und von der Anwendung benötigte Trafficmuster statisch festgelegt sein oder zur Laufzeit erkannt werden. Sowohl die proaktive Flow‐Installation als auch die Topologieerkennung und Aushandlung der Trafficmuster mit der Anwendung im Falle des dynamischen Szenarios sollten innerhalb der Wartungsphase des P2P‐ Systems erfolgen. Ein weiteres noch zu lösendes Problem ist die Einführung des Controllers als Single Point of Failure (SPoF) in das Netzwerk, welcher Robustheit und Skalierbarkeit stark verschlechtert. Dennoch kann das System zur echtzeitfähigen Datenübertragung auch stark vom Einsatz von SDN profitieren, da es parallele Kommunikation während der Zeitschlitze erlaubt, ohne dass es zu unerwarteten Verzögerungen kommt. In dem bisher verwendeten System war dies nicht möglich, da der Netzwerkzugriff alleine durch die P2P‐Plattform geregelt wurde, welche keine Kenntnis von Topologie und verwendeten Routen besitzt und somit keine konfliktfreie parallele Kommunikation garantieren konnte. Parallele Kommunikation innerhalb der Zeitschlitze kann sowohl zur Steigerung der Bandbreite als auch zur Verkürzung der Cycle Time (Zeit, bis alle Geräte einmal senden durften) genutzt werden. Alternativ können auch mehr Geräte in das Netzwerk aufgenommen werden, ohne die Eigenschaften hinsichtlich der Echtzeitfähigkeit zu verschlechtern. Wie Kapitel 3 zeigte, ist der mögliche Gewinn von Topologie und Controller abhängig. 5 Ausblick Die vorangegangen Kapitel haben gezeigt, dass im Bereich des SDN noch viele weitere Arbeiten zur Verbesserung von Netzwerktechnologien möglich und nötig sind, sowohl im Bereich der Echtzeitsysteme als auch unabhängig davon. Mögliche Themen für weitere Arbeiten in diesem Bereich sind: Robustheit und Skalierbarkeit von SDN: Die Analyse von verteilten Controllern. Es gibt bereits Projekte die sich mit diesem Thema befassen (z.B. [25], HyperFlow [26]). Auffinden optimaler Topologien. Die FatTree‐Topologie ist bereits ein guter Ausgangspunkt, aber es existieren noch andere Ansätze wie z.B. DCell [27] und Jellyfish [28]. Ein Vergleich möglicher Topologien auch unter Einbeziehung des gewünschten Anwendungsbereiches wäre sinnvoll. Entwicklung neuer Routingstrategien. Vor allem die Ausnutzung redundanter Pfade unter Einbeziehung des aktuellen Traffics (Load Balancing) ist kein vollständig gelöstes Problem, 28 obwohl es bekannte Entwicklungen wie Equal Cost Multipath Routing (ECMP) und MultiPath TCP gibt, die eine gleichmäßige Auslastung verschiedener Routen anstreben. Entwicklung von Northbound APIs für Controller. Die Kommunikation zwischen Anwendung und Controller ist ein wichtiger Aspekt von SDN, welcher bisher nur unzureichend bearbeitet wurde. Er ist eng mit dem Routing verknüpft, da eine Abstimmung von Routing und Anwendungsverhalten (Trafficmuster) aufeinander zu einem effektiveren Load Balancing führen kann. Dies ist auch der wichtigste Aspekt für den Einsatz von SDN in einem Echtzeitsystem. Die Herausforderung bei der Realisierung der parallelen Kommunikation in dem bestehenden System ist das Aushandeln der zulässigen Trafficmuster mit dem P2P‐ System (für ein dynamisches Szenario). Bisher wurde der Zugriff auf das Netzwerk während der Zeitslots nicht durch eine zentrale Instanz verwaltet. Daher hat der Controller keinen direkten Kommunikationspartner, mit dem die zulässigen Trafficmuster ausgehandelt werden. Es muss also ein neuer Mechanismus entworfen werden, wie der Zugriff auf das Netzwerk während der Zeitschlitze geregelt wird. Die Verwendung von Mininet ist eine Möglichkeit, um neue Entwicklungen in dem Bereich schnell und kostengünstig zu testen. Aus funktionaler Sicht unterscheiden sich die virtuellen Netzwerkkomponenten von Mininet nicht von realen Komponenten. Daher ist es empfehlenswert Mininet in Zukunft auch weiterhin zu nutzen, um zu überprüfen, ob z.B. neue Topologien oder Routingalgorithmen den Erwartungen entsprechen bzw. korrekt funktionieren. Darüber hinaus haben die Autoren des Emulators gezeigt, dass auch Performanceeigenschaften eines Netzwerkes in der Emulation zuverlässig bestimmt werden können, sofern die Messungen bandbreitenorientiert sind. Bezüglich des Zeitverhaltens ermöglicht Mininet jedoch nur eine grobe Einschätzung eines Systems, da die entsprechenden Eigenschaften eines realen Systems nicht passend abgebildet werden. Um bei der Optimierung eines Echtzeitsystems durch SDN auch eine zuverlässige Bewertung der zeitlichen Eigenschaften abgeben zu können, ist es empfehlenswert, ähnliche Tests wie in Kapitel 3 zukünftig auch in einem realen Testaufbau durchzuführen. Vor allem die Messung der maximalen RTT, welche für ein Echtzeitsystem von großer Bedeutung ist, war mit dem bisherigen Testaufbau nicht sinnvoll möglich. Neben einem realen Testaufbau kann auch versucht werden, die Messungen mit Mininet zu optimieren. Es ist z.B. vorstellbar, dass durch den Betrieb von Mininet in einer nativen Linux Installation statt einer VM bessere Ergebnisse erzielt werden können. Darüber hinaus könnten optimierte Scheduler Einstellungen oder andere qdiscs die Messung des Zeitverhaltens verbessern. Im Rahmen dieser Arbeit konnten entsprechende Versuche nicht durchgeführt werden, da vor allem das Auffinden optimaler Einstellungen für Scheduler und qdisc sehr zeitaufwändig ist. Außerdem ist noch unklar, ob mit diesen Veränderungen eine signifikante Verbesserung erzielt werden kann. 6 Verwandte Themen Im folgenden Kapitel sollen einige mit SDN und OpenFlow verbundene Themen vorgestellt werden. Die gezeigten Themen sind im Allgemeinen sehr umfangreich und sollen daher hier nicht im Detail erläutert werden, sondern dienen der Einordnung von SDN, OpenFlow und dem angestrebten Einsatz in einer Echtzeitumgebung in das gesamte Themengebiet. 6.1 Etablierte Netzwerktechnologien 6.1.1 Simple Network Management Protocol (SNMP) Wenn man SDN abstrakt betrachtet, kann man es als eine neue Form des Managements von Netzwerkgeräten ansehen, und OpenFlow als ein neues Protokoll, um die Kommunikation zwischen den verwalteten Geräten und einer zentralen Management Software durchzuführen. Mit dieser stark vereinfachten und etwas irreführenden Sichtweise scheint sich der Anwendungsbereich von SDN bzw. 29 OpenFlow stark mit dem seit Jahrzehnten etablierten SNMP zu überschneiden. Daher soll hier kurz erläutert werden, warum dies nur in sehr geringem Maße zutreffend ist und inwiefern SDN bzw. sich im Wesentlichen von SNMP unterscheidet. SNMP wurde entworfen, um die Überwachung und Konfiguration beliebiger mit dem Netzwerk verbundener Geräte zu ermöglichen. Bei SNMP wird zwischen folgenden Bestandteilen unterschieden: Das verwaltete Gerät kann ein beliebiges an das Netzwerk angeschlossenes Gerät sein (z.B. Router, Switch, Drucker, PC). Der SNMP Agent des verwalteten Gerätes kann in Software oder Hardware ausgeführt sein und kann Daten auf dem Gerät auslesen und optional auch schreiben. Er kommuniziert über das SNMP mit der zentralen Netzwerkmanagementstation. Die Netzwerkmanagementstation kann Daten von Agenten abfragen (Get) oder Kommandos zum Schreiben von Konfigurationsparametern (Set) senden und bietet somit zentrale Überwachungs‐ und Kontrollfunktionen. Die vom Protokoll definierten Nachrichtentypen umfassen neben den genannten Get‐ und Set‐ Anfragen einen Response‐Nachrichtentyp für die zugehörigen Antworten der Agenten und einen sogenannten Trap‐Nachrichtentyp zur Berichterstattung des Agenten an die Managementstation (meist im Fehlerfall). Da es sich bei SNMP um ein Protokoll zur Verwaltung verschiedenster Geräte handelt, ist nicht allgemein festgelegt, welche Variablen auf einem Gerät gelesen und geschrieben werden können. Die durch SNMP zugreifbaren Variablen eines Gerätes werden auch als „managed objects“ bezeichnet. In einer gerätespezifischen Management Information Base (MIB) wird definiert, welche „managed objects“ auf dem Gerät verwaltet werden können und welchen Datentyp das jeweilige Objekt besitzt. Zur Klassifizierung der möglichen Objekte und deren Bedeutung wurde der Object Identifier Tree (Abbildung 9) eingeführt. Um in dieser Baumstruktur ein bestimmtes Objekt auszuwählen können die Knoten in der Hierarchie durch Zahlen ausgewählt werden (Abbildung 9). Sendet eine Managementstation die gezeigte Object ID (OID) 1.3.6.1.2.1.7.1 beispielsweise in einer Get‐Anfrage an ein Gerät, so antwortet dieses Gerät mit der Anzahl der dort eingetroffenen UDP Pakete (udpInDatagrams Objekt). Damit eine Managementstation weiß, welche Objekte von einem Gerät unterstützt werden, muss sie die zugehörige MIB kennen. ITU‐T (0) ISO (1) Standard (0) US DoD (6) ISO member body (2) ... Open Software Foundation (22) Joint ISO/ITU‐T (2) ISO identified organization (3) ... NATO identified (57) 1.3.6.1.2.1.7.1 udpInDatagrams UDP MIB2 management ISO ISO‐ident. Org. US DoD Internet Internet (1) directory (1) experimental (3) management (2) security (5) private (4) mail (7) snmpv2 (6) MIB‐2 (1) ... system (1) address translation (3) icmp (5) udp (7) cmot (9) snmp (11) rmon (16) interface (2) Ip (4) tcp (6) egp (8) transmission (10) Abbildung 9: Der Object Identifier Tree von SNMP [29] 30 Bei einem Vergleich ist es angebracht, nicht SDN und SNMP zu vergleichen, sondern OpenFlow und SNMP, da es sich bei SDN um ein übergeordnetes Konzept handelt und bei OpenFlow und SNMP um festgelegte Protokolle. Beide Protokolle können dabei als Southbound API betrachtet werden. Es ist generell vorstellbar eine SDN‐Lösung mit Hilfe von SNMP umzusetzen. Hierzu müssten im OID‐Baum neue „managed objects“ definiert werden, welche die gleiche Funktionalität bieten wie die aus dem OpenFlow‐Protokoll bekannten Nachrichten. Anstelle der verschiedenen Nachrichtentypen aus OpenFlow könnte man zur Realisierung der verschiedenen Aufgaben wie z.B. Erstellung von Flow‐ Einträgen, Abfragen von Flow‐Statistiken, Setzen der Portkonfiguration, etc. also Set‐ und Get‐ Nachrichten, angewendet auf die entsprechenden neu definierten OIDs, verwenden. Obwohl eine entsprechende Implementierung vorstellbar ist, wäre die Benutzung zum Management von Netzwerken jedoch wesentlich weniger intuitiv als mit OpenFlow. Die datenorientierte Sicht und die sehr allgemein gehaltenen Nachrichtentypen von SNMP ermöglichen den Einsatz des Protokolls für ein allgemeines Gerätemanagement, das nicht auf eine bestimmte Hardware beschränkt ist und mit OpenFlow nicht durchgeführt werden kann. Gleichzeitig wird jedoch der Overhead für eine spezifische Aufgabe wie das Netzwerkmanagement erhöht, sodass die Verwendung eines auf netzwerkbezogene Aufgaben ausgelegten Protokolls wie OpenFlow Nutzung und Implementierung vereinfacht. 6.1.2 Routing Information Protocol und Open Shortest Path First Das Routing Information Protocol (RIP) ist ein seit Jahrzehnten existierendes Routingprotokoll das auf einem Distanzvektoralgorithmus basiert. Router dieser Art haben keine globale Sicht auf das Netzwerk, sondern kennen zu Beginn nur ihre direkten Nachbarn und die Kosten, um diese zu erreichen. Bei RIP wird die Anzahl der Hops als Kostenmetrik verwendet und die Kosten für direkte Nachbarn sind daher immer 1. Nach der Initialisierung der Routingtabelle mit den direkten Nachbarn schickt jeder Router diese Routingtabelle an jeden seiner Nachbarn. Durch den Erhalt dieser Nachrichten erfahren die Router, welche weiteren Router über den Absender der Nachricht erreichbar sind. Diese Informationen werden in die eigene Routingtabelle aufgenommen und die Kosten der Einträge um 1 erhöht. Anschließend wird diese aktualisierte Routingtabelle wieder an die eigenen Nachbarn weitergegeben. Dadurch wird die Information, wie ein bestimmter Router bzw. ein bestimmtes Netzwerk erreichbar ist, schrittweise im Netzwerk verteilt. Erhält ein Router mehrere Routinginformationen für das gleiche Ziel, so wird prinzipiell die Route mit den geringsten Kosten gespeichert. Um im Falle von Schleifen im Netzwerk zu vermeiden, dass eine Routinginformation zirkulierend weitergereicht wird, beträgt die maximal zulässige Anzahl an Hops 15. Der Vorteil von RIP ist, dass es praktisch ohne manuelle Konfiguration funktioniert und die optimalen Routen im Netzwerk nutzt. Die Nachteile sind jedoch eine hohe Konvergenzzeit (Zeit, bis neue Routinginformationen im ganzen Netz bekannt sind), die Begrenzung der Netzwerkgröße durch die maximale Hopanzahl und relativ viel Traffic durch Routinginformationen. Außerdem ist die Hopanzahl in vielen Fällen kein gutes Kriterium für die Kosten. Dadurch dass bei RIP nur die Routinginformationen durch das Netzwerk weitergeleitet werden, erfahren die einzelnen Router, wohin sie Daten senden müssen. Rückschlüsse auf die Topologie sind anhand dieser Daten möglich, die vollständige Topologie kann daraus jedoch in der Regel nicht abgeleitet werden. Anders ist es bei sogenannten Link State‐Routingprotokollen wie dem Open Shortest Path First (OSPF) Protokoll. Bei OSPF wird das Netzwerk zunächst in Areas eingeteilt. Innerhalb einer Area werden Link State Advertisements (LSA) zwischen den Routern ausgetauscht, um andere Router über die vorhandenen Verbindungen zu informieren. Diese LSAs werden von den Routern dazu verwendet, eine Topologiedatenbank aufzubauen. Alle Router innerhalb einer Area erhalten nach diesem Prinzip eine konsistente Sichtweise auf die Topologie der eigenen Area. Durch die Anwendung des Shortest Path First (SPF) Algorithmus kann jeder Router daraus seine Routingtabelle ableiten. Der SPF Algorithmus (nach Dijkstra) bestimmt den kürzesten Pfad zu jedem Zielknoten innerhalb der 31 Topologie. Die Metrik für die Pfadlänge ist nicht durch OSPF festgelegt. Da die Hopanzahl typischerweise nicht sehr aussagekräftig ist, werden in der Regel Bandbreite und RTT zur Bildung einer passenden Metrik verwendet. OSPF ist RIP in vielen Fällen vorzuziehen, da die Konvergenzzeiten und der verursachte Traffic in der Regel geringer sind, die verwendete Metrik sinnvoller ist und die Einteilung in Areas eine Unterstützung größerer Netzwerk ermöglicht. Bei beiden Routingprotokollen ist ein Equal Cost Multipath (ECMP) Load Balancing möglich. Dabei wird versucht, Verbindungen mit gleichen Kosten gleichmäßig zu belasten, indem unterschiedliche Flows über verschiedene Routen weitergeleitet werden. Die Zuordnung von Flows zu einer bestimmten Route kann dabei unterschiedlich erfolgen. Typische Verfahren sind Round Robin (die für den nächsten Flow zu verwendende Route wird der Reihe nach gewechselt) und hashbasierte Zuordnung. Bei den hashbasierten Verfahren wird eine Hashfunktion auf einen Teil des Paketheaders angewendet um einen Hashwert zu berechnen, während den unterschiedlichen Routen Zuständigkeitsbereiche im Rahmen aller möglichen Hashwerte zugeordnet sind. Im Bereich des Software Defined Networking stellt das Routing einen bedeutenden Bestandteil dar. Da es durch den zentralen Controller vergleichsweise einfach ist eine globale Sicht auf das Netzwerk zu erhalten und eine interne Repräsentation der Topologie zu erzeugen, sind vor allem Routingverfahren, die dies ausnutzen (z.B. SPF), interessant. Da bei SDN‐Lösungen nicht alle Knoten über Veränderungen der Topologie informiert werden müssen, ist der für die Topologieerkennung notwendige Traffic vergleichsweise gering. Außerdem ist man bei SDN‐Lösungen nicht an ein bestimmtes Routingverfahren gebunden, sondern es ist einfach austauschbar. Load Balancing kann unterschiedliche Flows durch die unterstützten Headerfelder sehr feingliedrig unterscheiden und durch die Implementierung einer Northbound API zusätzlich Anwendungsinformationen in die Entscheidung mit einbeziehen. Abschließend kann man sagen, dass SDN nicht per se ein effizienteres Routing zulässt als existierende Verfahren mit einer verteilten Kontrolllogik, aber es macht Verbesserungen einfacher zugänglich und erfordert in heterogenen Umgebungen keine Einigung der Hardwarehersteller auf ein bestimmtes Protokoll. 6.2 SDN‐bezogene Projekte 6.2.1 Virtualisierung von Netzwerken Eine der wichtigsten Anwendungsmöglichkeiten von SDN ist die Virtualisierung von Netzwerken. Diese Nutzung von SDN wurde bereits in der ursprünglichen Veröffentlichung von OpenFlow [5] vorgeschlagen. Damit ist nicht nur das Erstellen von vollständig virtuellen Netzwerken ohne eine echte Hardwarebasis (z.B. Mininet) gemeint, was in der Regel zu Test‐ und Entwicklungszwecken genutzt wird, sondern auch das Erstellen von virtuellen Netzwerken auf Basis eines realen Netzwerkes. Durch die Virtualisierung von Netzwerken ist es möglich, dass unterschiedliche Anwendungen, Benutzer oder Endgeräte unterschiedliche logische (virtuelle) Netzwerke anstelle des realen Netzwerkes sehen. Obwohl der gesamte Traffic physikalisch über das gleiche Netzwerk geleitet wird, ist für die Netzwerkteilnehmer nur der Traffic des eigenen logischen Netzwerkes sichtbar. Genutzt werden können logische Netzwerke u.a. zur Isolation von Traffic, um unterschiedliche QoS und Routing Einstellungen anzuwenden oder um entfernte reale Netzwerke miteinander zu verbinden (z.B. VPN), während alle diese Vorgänge für die Anwendungen transparent bleiben und diese stets den optimalen Zugriff auf benötigte Ressourcen erhalten. Obwohl diese Funktionen bereits ohne SDN realisiert werden konnten (z.B. VLAN Tags), bietet SDN in diesem Bereich erhebliche Vorteile. Die Konfiguration von virtuellen Netzwerken vereinfacht sich, da diese in einem zentralen Controller definiert werden können, an Stelle von vielen Routern und Switches die alle eine passende Konfiguration erhalten müssen. Die Einteilung von Traffic in bestimmte virtuelle Netzwerke kann durch die Nutzung von Flows feiner strukturiert werden. Netzwerkvirtualisierung ist ein wichtiger Anwendungsfall von SDN, da er 32 einer der ersten war, der das Interesse am praktischen Einsatz von SDN in Unternehmensnetzwerken und Datenzentren geweckt hat. Die Netzwerkvirtualisierung ist beispielsweise für Anbieter von Cloud Computing wichtig, welche den Traffic unterschiedlicher Kunden trennen müssen, die alle virtuelle Maschinen auf den gleichen realen Servern und dem gleichen realen Netzwerk betreiben (vgl. zu diesem Abschnitt [1], [30]). 6.2.2 EstiNet OpenFlow Network Simulator and Emulator Der EstiNet OpenFlow Network Simulator and Emulator [31] [32] ist ein weiteres Projekt, welches eine schnelle und einfache Testmöglichkeit für OpenFlow‐Netzwerke bieten soll und damit mit Mininet vergleichbar ist. Ähnlich zu Mininet ermöglicht EstiNet die Durchführung von Experimenten auf virtuellen Netzwerken unter Verwendung eines unmodifizierten OpenFlow‐Controllers und unmodifizierten Host‐Anwendungen. Es bietet einen Simulationsmodus für maximale Genauigkeit und einen Emulationsmodus, welcher einen schnelleren Ablauf der Experimente bei geringfügig schlechterer Genauigkeit erlaubt. Das zu Grunde liegende Prinzip unterscheidet sich dabei signifikant von Mininet und soll besser reproduzierbare und genauere Ergebnisse liefern. In [31] wurden RTTs für unterschiedlich große OpenFlow‐Netzwerke gemessen und die Ergebnisse der beiden EstiNet‐Modi mit Ergebnissen aus Mininet verglichen. Der Autor zeigt dabei, dass Mininet weniger zuverlässige Ergebnisse liefert und teilweise ein unerklärbares Verhalten zeigt. Die Aussage, in Bezug auf die RTT bessere Ergebnisse liefern zu können, macht den EstiNet Simulator/Emulator zu einem interessanten Tool für Messungen wie in Kapitel 3, allerdings handelt es sich um ein kommerzielles Produkt und das Tool ist weder frei verfügbar noch Open Source. Darüber hinaus scheint der Testaufbau in [31] ungünstig gewählt, da den virtuellen Ethernetverbindungen statische Verzögerungen hinzugefügt wurde, welche die Übertragungsdauer von Paketen simulieren sollen, während die Sendedauer von Paketen vernachlässigt wurde. Dies ist genau das gegenteilige Vorgehen zu Kapitel 3 und ist zumindest für die Betrachtung von Verzögerungen bei paralleler Kommunikation weniger relevant. Darüber hinaus zeigt der Autor Probleme bei der Verwendung von Mininet, welche in dieser Arbeit nicht vorgekommen sind. 6.2.3 KVM‐unterstützte Echtzeitdatenübertragung über OpenFlow‐Netzwerke Eine Arbeit der Universität von Tokyo [33], die sich bereits mit Echtzeitkommunikation über OpenFlow‐ Netzwerke befasst hat, schlägt eine Erweiterung des Linux KVM (Kernel‐based Virtual Machine) Moduls vor, welche den damit betriebenen Virtuellen Maschinen eine echtzeitfähige Kommunikation über ein OpenFlow‐Netzwerk erlaubt. Das Konzept sieht vor, neben dem normalen virtuellen Ethernetadapter (vNIC), der einer VM durch KVM zur Verfügung gestellt wird, einen weiteren, echtzeitfähigen virtuellen Ethernetadapter (RTvNIC) einzuführen. Dieser fügt dem Paket beim Sendevorgang den Sendezeitpunkt hinzu (zur späteren Überprüfung der Einhaltung von Deadlines) und setzt die DSCP (Differentiated Service Code Point) Bits des IP‐Headers, um sich gegenüber dem OpenFlow‐Controller als Echtzeit‐Flow zu identifizieren. Die Behandlung aller virtuellen Netzwerkadapter durch KVM wird um einen Earliest Deadline First (EDF) Paket‐Scheduler erweitert, welcher Pakete von RTvNICs stets den Paketen von normalen vNICs vorzieht. Abgesehen von diesem erweiterten System für virtuelle Ethernetadapter ist eine neue Komponente in KVM vorgesehen, welche mit dem OpenFlow‐Controller kommuniziert. Diese Komponente soll beim OpenFlow‐ Controller die Reservierung von Bandbreite für alle von RTvNICs benötigten Pfade erfragen. Außerdem überprüft sie im Empfänger die Einhaltung von Deadlines und sendet im Fehlerfall eine Anfrage auf Verbesserung des zugehörigen Pfades an den OpenFlow‐Controller. Die Autoren der Arbeit haben eine lauffähige Implementierung des Systems in einer virtuellen Umgebung mit einem System ohne RTvNICs verglichen und konnten eine signifikante Verbesserung hinsichtlich durchschnittlicher und maximaler RTT feststellen. Die Präsentation der Arbeit macht keine konkreten Angaben, welche Echtzeitkriterien eingehalten werden. Auf Grund der Implementierung ist jedoch davon auszugehen, 33 dass weiche Echtzeitbedingungen eingehalten werden, was eine verbesserte Nutzung von Kommunikationsanwendungen (VoIP, Videotelefonie) in stark ausgelasteten Netzwerken erlaubt. Garantien zur Einhaltung von Deadlines sind bei diesem System voraussichtlich nicht möglich, sodass das System harten Echtzeitanforderungen nicht gerecht wird und ein anderes Nutzungsgebiet angestrebt wird als bei dem am Institut untersuchten System zur echtzeitfähigen Datenübertragung. 7 Zusammenfassung Im Laufe dieser Arbeit hat sich gezeigt, dass die Vor‐ und Nachteile von SDN, ebenso wie dessen Nutzungsmöglichkeiten, sich nicht auf kurze, einfache und eindeutige Weise beschreiben lassen. Dies liegt vor allem daran, dass es sich bei SDN nur um ein abstraktes Konzept handelt, das selbst noch keine konkreten Probleme löst. Welche Charakteristiken ein Software Defined Network im Detail aufweist, ist somit stark von der Implementierung abhängig – vor allem von der Implementierung des Controllers. Beim Routing können Probleme wie hohe Konvergenzzeiten und fehlende Konsistenz innerhalb des Netzwerkes, die bei klassischen Routingprotokollen einer verteilten Control Plane auftreten können, durch SDN vermieden werden, da ein zentraler Controller solche Probleme Prinzip‐ bedingt nicht aufweisen kann. Teilt man den logisch zentralisierten Controller jedoch physikalisch auf, um Probleme mit der Skalierbarkeit und Robustheit zu lösen, kehren derartige Probleme auch bei SDN zurück. Was als Vorteil von SDN‐Lösungen in jedem Fall bestehen bleibt, ist die erhöhte Flexibilität des gesamten Netzwerkes durch die Programmierbarkeit und die feingliedrige Aufteilung von Flows. Darüber hinaus können neue Netzwerktechnologien in vielen Fällen hardwareunabhängig realisiert werden. OpenFlow ist ein wichtiger Bestandteil in der SDN‐Umgebung und bietet eine gut nutzbare Southbound API, da das Protokoll sowohl von Hardwareherstellern als auch vielen Controller‐ Frameworks unterstützt wird. Weitere wichtige Aspekte der Netzwerkforschung, wie das Auffinden optimaler Topologien, Routingverfahren und Traffic Engineering, sind beim SDN ebenso bedeutsam wie bei herkömmlichen Netzwerktechnologien. Ein Ziel von SDN ist jedoch die Verbesserung der Innovationsrate in diesem Bereich, da Neuerungen durch SDN schneller praktisch einsetzbar sind. Im Bereich der Echtzeitkommunikation spricht grundlegend nichts gegen einen Einsatz von SDN bzw. OpenFlow. Durch den Weg wie OpenFlow typischerweise in Switch Hardware implementiert wird, sind bei bekannten Flows die gleichen Verzögerungen durch das Netzwerk zu erwarten wie bei herkömmlichen Routern und Switches. Der kritische Aspekt ist die Installation von Flow‐Einträgen in den Switches, welche durch die notwendige Kommunikation mit dem Controller zusätzliche Verzögerungen verursacht. Für dieses Problem gibt es jedoch verschiedene Lösungsansätze. Darüber hinaus bietet SDN durch die Implementierung einer Northbound API eine weitere bedeutende Möglichkeit, Netzwerke effizienter zu nutzen. Im Falle eines Echtzeitsystems ist die Nutzung einer Northbound API ein vielversprechender Ansatz, um parallele Kommunikation zu erlauben, auch wenn die entsprechende API voraussichtlich größtenteils selbst implementiert werden muss, da sie sehr anwendungsabhängig ist. Zukünftige RTT‐Messungen eines OpenFlow‐basierten Systems zur Echtzeitkommunikation sollten in einem Hardwareaufbau verifiziert werden, da Mininet keine zeitlich präzisen Ergebnisse liefert. Sowohl seitens der Wissenschaft als auch der Wirtschaft besteht großes Interesse am SDN. Aktuelle Projekte reichen daher von allgemein anwendbaren Methoden wie z.B. verteilten Controllern bis hin zu praktischen Anwendungen wie einer umfangreichen Netzwerkvirtualisierung oder einem individuell optimierten Load Balancing mit Hilfe von Northbound APIs. 34 I. Abbildungsverzeichnis Abbildung 1: Beziehung zwischen Control Plane, Data Plane und Anwendungen [2] ............................ 5 Abbildung 2: Paketheader zur Definition von Flows [6] .......................................................................... 8 Abbildung 3: Netzwerkaufbau von Mininet [12] ................................................................................... 12 Abbildung 4: Erstellen eines virtuellen Netzwerks unter Linux [12] ..................................................... 13 Abbildung 5: Single Switch Topologie ................................................................................................... 17 Abbildung 6: Binärbaumtopologie mit Routen zwei verschiedener Trafficmuster. Rote Pfeile zeigen die Routen des Trafficmusters der Tabelle 7 (keine überlappenden Pfade). Grüne Pfeile zeigen die Routen des Trafficmusters der Tabelle 8 (teilweise überlappende Pfade). Alle Pfeile zeigen in Richtung der ICMP Echo Requests (ICMP Echo Response nutzt jeweils die gleiche Route in Gegenrichtung). Überlappende Pfade eines Trafficmusters können anhand unterschiedlicher Linientypen unterschieden werden. ..................................................................................................... 18 Abbildung 7: Mesh Grid‐Topologie mit Routen zwei verschiedener Trafficmuster. Rote Pfeile zeigen die Routen des Trafficmusters der Tabelle 9 (keine überlappenden Pfade). Grüne Pfeile zeigen die Routen des Trafficmusters der Tabelle 10 (überlappende Pfade). Alle Pfeile zeigen in Richtung der ICMP Echo Requests (ICMP Echo Response nutzt jeweils die gleiche Route in Gegenrichtung). Überlappende Pfade eines Trafficmusters können anhand unterschiedlicher Linientypen unterschieden werden. ......................................................................................................................... 20 Abbildung 8: FatTree‐Topologie mit sechs sendenden Hosts und zufälligem Routing durch RipL‐POX (Tabelle 11). Rote Pfeile zeigen die Routen der ICMP Echo Requests. Grüne Pfeile zeigen die Routen der ICMP Echo Responses. Überlappende Routen können durch unterschiedliche Linientypen unterschieden werden. ......................................................................................................................... 21 Abbildung 9: Der Object Identifier Tree von SNMP [29] ....................................................................... 30 II. Tabellenverzeichnis Tabelle 1: Single Switch‐Topologie mit einem sendenden Host ........................................................... 18 Tabelle 2: Single Switch‐Topologie mit acht sendenden Hosts ............................................................. 18 Tabelle 3: Binärbaumtopologie mit Sendevorgang über einen Hop ..................................................... 19 Tabelle 4: Binärbaumtopologie mit Sendevorgang über drei Hops ...................................................... 19 Tabelle 5: Binärbaumtopologie mit Sendevorgang über fünf Hops ...................................................... 19 Tabelle 6: Binärbaumtopologie mit Sendevorgang über sieben Hops .................................................. 19 Tabelle 7: Binärbaumtopologie mit fünf sendenden Hosts und nicht überlappenden Pfaden ............ 19 Tabelle 8: Binärbaumtopologie mit fünf senden Hosts und teilweise überlappenden Pfaden ............ 19 Tabelle 9: Mesh Grid‐Topologie mit drei sendenden Hosts und nicht überlappenden Pfaden ........... 20 Tabelle 10: Mesh Grid‐Topologie mit fünf senden Hosts und überlappenden Pfaden ........................ 21 Tabelle 11: FatTree‐Topologie mit sechs sendenden Hosts und zufällig ausgewählten Pfaden .......... 22 35 III. Literaturverzeichnis [1] N. Feamster, J. Rexford und E. Zegura, „The Road to SDN: An Intellectual History of Programmable Networks,“ [Online]. Available: https://www.cs.princeton.edu/courses/archive/fall13/cos597E/papers/sdnhistory.pdf. [Zugriff am 6 Januar 2015]. [2] O. N. Foundation, „Software‐Defined Networking (SDN) Definition,“ [Online]. Available: https://www.opennetworking.org/sdn‐resources/sdn‐definition. [Zugriff am 6 Januar 2015]. [3] SDxCentral, „What’s Software‐Defined Networking (SDN)?,“ [Online]. Available: https://www.sdxcentral.com/resources/sdn/what‐the‐definition‐of‐software‐defined‐ networking‐sdn/. [Zugriff am 6 Januar 2015]. [4] SDxCentral, „What are SDN Northbound APIs?,“ [Online]. Available: https://www.sdxcentral.com/resources/sdn/north‐bound‐interfaces‐api/. [Zugriff am 6 Januar 2015]. [5] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker und J. Turner, „OpenFlow: Enabling Innovation in Campus Networks,“ [Online]. Available: http://archive.openflow.org//documents/openflow‐wp‐latest.pdf. [Zugriff am 7 Januar 2015]. [6] B. Pfaff, B. Heller, D. Talayco, D. Erickson, G. Gibb, G. Appenzeller, J. Tourrilhes, J. Pettit, K. Yap, M. Casado, M. Kobayashi, N. McKeown, P. Balland, R. Price, R. Sherwood und Y. Yiakoumis, „OpenFlow Switch Specification,“ [Online]. Available: https://www.opennetworking.org/images/stories/downloads/sdn‐resources/onf‐ specifications/openflow/openflow‐spec‐v1.0.0.pdf. [Zugriff am 10 Janaur 2015]. [7] M. Rouse, „(TCAM) ternary content‐addressable memory,“ [Online]. Available: http://searchnetworking.techtarget.com/definition/TCAM‐ternary‐content‐addressable‐ memory. [Zugriff am 9 Januar 2015]. [8] Wikipedia, „Content‐addressable memory,“ [Online]. Available: http://en.wikipedia.org/wiki/Content‐addressable_memory. [Zugriff am 9 Januar 2015]. [9] B. Lantz, B. Heller, N. Handigol, V. Jeyakumar und B. O’Connor, „Mininet ‐ An Instant Virtual Network on your Laptop (or other PC),“ [Online]. Available: http://mininet.org/. [Zugriff am 28 Januar 2015]. [10] B. Heller, „Reproducible Network Research with High‐Fidelity Emulation,“ [Online]. Available: https://stacks.stanford.edu/file/druid:zk853sv3422/heller_thesis‐augmented.pdf. [Zugriff am 12 Januar 2015]. [11] N. Handigol, B. Heller, V. Jeyakumar, B. Lantz und N. McKeown, „Reproducible Network Experiments Using Container‐Based Emulation,“ [Online]. Available: http://conferences.sigcomm.org/co‐next/2012/eproceedings/conext/p253.pdf. [Zugriff am 12 Januar 2015]. [12] T.‐Y. Huang, V. Jeyakumar, B. Lantz, B. O'Connor, N. Feamster, K. Winstein und A. Sivaraman, „Teaching Computer Networking with Mininet,“ [Online]. Available: 36 http://conferences.sigcomm.org/sigcomm/2014/doc/slides/mininet‐intro.pdf. [Zugriff am 13 Januar 2015]. [13] B. Lantz, B. Heller und N. McKeown, „A Network in a Laptop: Rapid Prototyping for Software‐ Defined Networks,“ [Online]. Available: http://conferences.sigcomm.org/hotnets/2010/papers/a19‐lantz.pdf. [Zugriff am 13 Januar 2015]. [14] E. W. Biederman, „IP‐NETNS(8),“ [Online]. Available: http://man7.org/linux/man‐ pages/man8/ip‐netns.8.html. [Zugriff am 13 Januar 2015]. [15] „POX Wiki,“ [Online]. Available: https://openflow.stanford.edu/display/ONL/POX+Wiki. [Zugriff am 30 Januar 2015]. [16] „POX on GitHub,“ [Online]. Available: https://github.com/noxrepo/pox. [Zugriff am 31 Januar 2015]. [17] „NOXRepo.org,“ [Online]. Available: http://www.noxrepo.org/. [Zugriff am 31 Januar 2015]. [18] „About NOX,“ [Online]. Available: http://www.noxrepo.org/nox/about‐nox/. [Zugriff am 31 Januar 2015]. [19] M. Al‐Fares, A. Loukissas und A. Vahdat, „A Scalable, Commodity Data Center Network Architecture,“ [Online]. Available: http://ccr.sigcomm.org/online/files/p63‐alfares.pdf. [Zugriff am 26 Januar 2015]. [20] B. Heller, „Ripcord‐Lite on GitHub,“ [Online]. Available: https://github.com/brandonheller/ripl. [Zugriff am 26 Januar 2015]. [21] B. Heller, „Ripcord‐Lite for POX on GitHub,“ [Online]. Available: https://github.com/brandonheller/riplpox. [Zugriff am 26 Januar 2015]. [22] B. Hubert, „Linux Advanced Routing & Traffic Control HOWTO,“ [Online]. Available: http://www.lartc.org/howto/. [Zugriff am 25 Januar 2015]. [23] M. A. Brown, „Traffic Control HOWTO,“ [Online]. Available: http://www.tldp.org/HOWTO/html_single/Traffic‐Control‐HOWTO/. [Zugriff am 25 Januar 2015]. [24] Open Networking Foundation, „Open Networking Foundation Introduces Northbound Interface Working Group,“ [Online]. Available: https://www.opennetworking.org/news‐and‐ events/press‐releases/1182‐open‐networking‐foundation‐introduces‐northbound‐interface‐ working‐group. [Zugriff am 29 Januar 2015]. [25] B. Heller, R. Sherwood und N. McKeown, „The Controller Placement Problem,“ [Online]. Available: http://yuba.stanford.edu/~nickm/papers/hot21‐heller.pdf. [Zugriff am 2 Februar 2015]. [26] A. Tootoonchian und Y. Ganjali, „HyperFlow: A Distributed Control Plane for OpenFlow,“ [Online]. Available: http://www.cse.iitd.ac.in/~siy107537/csl374/a5/files/Tootoonchian.pdf. [Zugriff am 29 Januar 2015]. 37 [27] C. Guo, H. Wu, K. Tan, L. Shi, Y. Zhang und S. Lu, „DCell: A Scalable and Fault‐Tolerant Network Structure for Data Centers,“ [Online]. Available: http://www.sigcomm.org/sites/default/files/ccr/papers/2008/October/1402946‐1402968.pdf. [Zugriff am 5 Februar 2015]. [28] A. Singla, C.‐Y. Hong, L. Popa und P. B. Godfrey, „Jellyfish: Networking Data Centers Randomly,“ [Online]. Available: https://www.usenix.org/system/files/conference/nsdi12/nsdi12‐ final82.pdf. [Zugriff am 5 Februar 2015]. [29] C. Tschudin, „Network Management,“ [Online]. Available: http://informatik.unibas.ch/uploads/media/cs262‐20140423‐2up.pdf. [Zugriff am 31 Januar 2015]. [30] S. Katukam, „Using Network Virtualization in Campus Networks,“ [Online]. Available: https://www.sdxcentral.com/articles/contributed/network‐virtualization‐campus‐ sdn/2013/07/. [Zugriff am 2 Februar 2015]. [31] S.‐Y. Wang, „Comparison of SDN OpenFlow Network Simulator and Emulators: EstiNet vs. Mininet,“ [Online]. Available: http://www.estinet.com/fckimages/14117014621397232509.pdf. [Zugriff am 3 Februar 2015]. [32] S.‐Y. Wang, C.‐L. Chou und C.‐M. Yang, „EstiNet OpenFlow Network Simulator and Emulator,“ [Online]. Available: http://www.estinet.com/fckimages/1411701431891112745.pdf. [Zugriff am 3 Februar 2015]. [33] K. Suzuki, „Real‐time Virtual NIC on KVM for Real‐Time Network with OpenFlow,“ [Online]. Available: http://events.linuxfoundation.org/sites/events/files/lcjpcojp13_ksuzuki.pdf. [Zugriff am 2 Februar 2015]. [34] N. Handigol, B. Heller, V. Jeyakumar, B. Lantz und N. McKeown, „Mininet‐HiFi: Rapid, High Fidelity SDN Prototyping,“ [Online]. Available: https://github.com/mininet/mininet/wiki/pdf/mininet‐hifi‐bdh2.pdf. [Zugriff am 13 Januar 2015]. Anhang A: Testsystem und Softwareversionen Hardware Intel Core 2 Duo P9700 4 GB DDR3‐1066 RAM Software Windows 8.1 64 bit (Hostsystem) Virtual Box 4.3.18 Mininet VM 2.1.0p2: o Ubuntu 14.04 LTS (Gastsystem, 2 Cores, 1 GB RAM) o POX Controller 0.3.0/dart commit 3b3fb43 o Ripcord‐Lite (ripl) master commit 350ff5c 38 o Ripcord‐Lite for POX (riplpox) master commit 9e8eb84 39