Software Dened Networking (OpenFlow) und seine Anwendbarkeit für die Steuerung von Videodaten im Internet

Transkript

1 ISE Seminar Software Dened Networking (OpenFlow) und seine Anwendbarkeit für die Steuerung von Videodaten im Internet 1. Oktober FH-Aachen - Stefan Königs (379575)

2 2 ISE-Seminar SS FH Aachen - Prof. Dr.-Ing. Frank Hartung 1 Einleitung Dieses Seminar verschat einen Überblick über das Thema Software Dened Networking, welches hier exemplarisch an dem OpenFlow-Protokoll erläutert wird. Neben genauer Betrachtung des grundsätzlichen Konzepts wird auch ein Vergleich mit anderen aktuell weit verbreiteten Verfahren gezogen. Software Dened Networking ist laut der Open Networking Foundation (ONF) ein Ansatz der über sechs Jahre hinweg gemeinsam mit den amerikanischen Universitäten Stanford und Berkeley entwickelt wurde. Die ONF ist ein Non- Prot-Konsortium, das im März 2011 gegründet worden ist. Die Gründerrmen sind: Deutsche Telekom Facebook Google Microsoft NTT Communication Verizon Yahoo Zwischenzeitlich sind einige weitere namenhafte Firmen diesem Konsortium beigetreten, wie z.b.: Alcatel-Lucent Cisco IBM Intel Huawei ORACLE Big Switch Networks Dell HP BroadCom NEC VMWare Die ONF möchte die Innovation der Netztechnik vorantreiben. Hierbei setzt sie auf den oben genannten SDN-Ansatz. Das Ziel des SDN-Ansatzes ist es, das Verhalten des Netzwerkes an die jeweilige Situation anzupassen und dies soll weitestgehend automatisiert geschehen. 2 Der SDN-Ansatz Software Dened Networking ist eine neue Netzwerk-Architektur, bei der die Netzwerk-Steuerung sowohl losgelöst vom forwarding als auch direkt programmierbar ist. Diese Migration der Netzwerk-Steuerung von den einzelnen Netzwerkgeräten in eine höhere Instanz bewirkt, dass die Infrastruktur für Anwendungen und Netzwerk-Dienste abstrakt wird. Die SDN Architektur besteht aus drei Layern. Der Anwendungs-Layer beinhaltet alle Anwendungen/Programme die Netzwerke benutzen und kommuniziert mit dem Kontroll-Layer. Dieser stellt

3 ISE-Seminar SS FH Aachen - Prof. Dr.-Ing. Frank Hartung 3 die Verbindung zum Infrastruktur-Layer (physischen Layer) her. Durch das hinzufügen des Kontroll-Layers ist es nun möglich, die physische Infrastruktur für den Anwendungs-Layer zu abstrahieren (siehe Abbildung 1; vgl. [ONF 2012]). Abbildung 1. SDN Architektur [ONF 2012] Um diesen Kontroll-Layer in eine Netzwerk-Infrastruktur zu integrieren, müssen die Hardware-Komponenten über ein entsprechendes Protokoll verfügen. Ein offenes Protokoll ist das OpenFlow Protokoll, welches von der ONF gemeinsam mit den Universitäten Berkeley und Stanford entwickelt wurde. 2.1 Motivation Die Notwendigkeit die bestehenden Netzwerk-Strukturen zu ändern entsteht nach [FKS 2012] aus der zunehmenden Virtualisierung von Servern und Workstation, den Cloud-Netzwerken und der höheren Belastung durch zunehmenden Datenverkehr (Trac). Ein Vorteil von SDN ist die zentral programmierbare Kontrolllogik. Durch die beschriebene Abstraktion in den Kontroll-Layer existiert eine globale Sicht der angeschlossenen Datenpfade neben der dazugehörigen Topologie. Somit wandelt sich die Netzwerkhardware im Wesentlichen zu einer Sammlung einfacher, generisch programmierbarer Forwarding-Elemente, die man nach Bedarf dem Netz hinzufügen oder sie daraus entfernen kann. Das vereinfacht die Entwicklung und Inbetriebnahme neuer Netzwerkanwendungen erheblich - vor allem im Vergleich zu den heute genutzten dezentralen Algorithmen und proprietären Hardwareschnittstellen. [ix 08/2012]

4 4 ISE-Seminar SS FH Aachen - Prof. Dr.-Ing. Frank Hartung 2.2 Zurzeit weit verbreitete Technik Heutzutage werden Netzwerke häug mit Layer2- bzw. Layer3-Switches aufgebaut. Switches sind aktive Netzwerkgeräte die Netzwerksegmente miteinander verbinden. Switches die auf dem Data Link Layer (Layer2) des OSI-Modells weiterleiten, werden Layer2-Switchs genannt. Falls zusätzlich Daten auf der Netzwerkschicht (Layer3) verarbeitet werden, werden sie Layer3 bzw. Multilayer- Switches genannt. 2.3 Allgemeine Arbeitsweise von Layer2-Switches Ein Switch besteht aus Netzwerkanschlüssen (Ports) und einem Source-Adress- Table (SAT). In der SAT speichert der Layer2-Switch die von den ankommenden Ethernet-Pakete Quell-MAC-Adresse und den dazugehörigen Port. Somit werden zukünftig Pakete nur noch an den Port weitergeleitet, an dem auch die korrekte MAC-Adresse gespeichert ist. Falls in der SAT kein Eintrag für die Ziel-MAC-Adresse enthalten ist, wird an alle Ports weitergeleitet (broadcast). Nicht genutzte Tabellen-Einträge werden nach einer vordenierten Zeit aus der SAT gelöscht. Die SAT wird auch Forwarding-Tabelle genannt. 2.4 Arbeitsweise des OpenFlow-Protokolls Die Arbeitsweise von OpenFlow ähnelt der, der Layer2-Switches. Sie erweitert die Forwarding-Tabelle um weitere Header-Felder und stellt eine Schnittstelle bereit, über die die Einträge der Forwarding-Tabelle verändert werden können. Der OpenFlow-Switch ist über eine SSL Verbindung mit einem Controller verbunden. Der Controller kann über diese Verbindung Einträge in den angeschlossenen OpenFlow-Switchen verändern. Somit ist es möglich, statt des Standard Lernalgorithmus der Layer2-Switches andere Regeln zu denieren. Dadurch entkoppelt OpenFlow den für die Forwarding-Logik zuständigen Kontrollpfad vom Datenpfad und schat die Voraussetzung für das Integrieren von Anwendungsfunktionen direkt, ins Netzwerk (vgl. [ix 08/2012]). Die Datenpfade werden bei OpenFlow als Flow bezeichnet. Abbildung 2. OpenFlow Architektur [OF Spec] Durch die Trennung des Kontrollpfads vom Datenpfad ist es möglich den Internetverkehr in Bezug auf den Inhalt auf unterschiedlichen Flows durch die Netzwerkinfrastruktur zu routen. Dies ist auch ohne SDN möglich. Der Vorteil bei SDN ist jedoch, dass das Routing dynamisch geändert werden kann.

5 ISE-Seminar SS FH Aachen - Prof. Dr.-Ing. Frank Hartung 5 Eine Änderung ohne SDN hat zu Folge, dass ein Techniker das Netzwerk für die jeweilige Situation anpassen muss. Durch SDN ist es möglich, dass das Netz nach Vorgaben selbst die Konguration ändert. Beispielsweise kann bei einer Live-Übertragung eines WM-Fussballspiels, der komplette Video-Datenverkehr über die schnellste Verbindung zwischen den benötigten Routern geleitet werden und jeder andere Datenverkehr wird währenddessen über andere Verbindungen geroutet. Nach der Live-Übertragung wird die spezische Verbindung wieder für den gesamten Datenverkehr freigegeben. Dies ist möglich, da der OpenFlow-Controller eine globale Sicht auf den Netzwerkverkehr hat und dazu die Netzwerk-Topologie kennt. Abbildung 3. verschiedene Flows durch ein Netzwerk Abbildung 3 zeigt ein Netzwerk, in dem verschieden lange Flows eingezeichnet sind. Die Anzahl der Hops steht für die Geschwindigkeit der Flows, je höher, desto langsamer. Die einzelnen Flows können entweder nach dem Inhalt des Datenverkehrs unterschieden werden, durch die Quell-MAC-Adressen oder durch die Ziel-MAC-Adressen wie beim klassischen Layer2-Switch. Durch dieses kleine Beispiel wird die Idee von SDN einfach verdeutlicht.

6 6 ISE-Seminar SS FH Aachen - Prof. Dr.-Ing. Frank Hartung 2.5 OpenFlow-Switch Wie schon im vorherigen Abschnitt beschrieben, erweitert OpenFlow die Forwarding- Tabelle um weitere Felder. Diese erweiterte Forwarding-Tabelle wird in der Literatur auch als Flow-Tabelle (OpenFlow-Table) bezeichnet. In dieser wird für jeden Flow ein Eintrag mit entsprechend gesetzten Header-Bits gespeichert. 2.6 OpenFlow-Table Jeder Eintrag in einer Flow-Tabelle besteht aus einem Match-Field, einem Zähler und einer Instruktionssammlung die ausgeführt wird, wenn das Paket mit den im Match-Field angegebenen Parametern übereinstimmt. Das Matching startet immer auf der ersten Flow-Tabelle. Das Matching arbeitet auf Basis einer Prioritätenreihenfolge. Der erste zutreende Eintrag wird genutzt um jeweiligen Instruktionen zu ermitteln. Abbildung 4. Hauptkomponenten eines Eintrag in einer Flow-Tabelle [OF Spec] Match Fields: Diese Spalte enthält die Bedingungen, die ein empfangenes Paket erfüllen muss um dann die entsprechenden Instruktionen aus der Instruktionsspalte zu erhalten. Die Bedingungen bestehen aus dem Empfangsport und den gesetzten Paket-Headern und können optional mit weiteren Metadaten erweitert werden. Counter (Zähler): Zähler für die empfangenen Pakete die die jeweilige Bedingung erfüllen. Instruction (Instruktion): Die auszuführenden Instruktionen für den Fall, dass das Paket die Parameter im Match Field erfüllt. Falls kein Eintrag in der ersten Flow-Tabelle gefunden wird, hängt das weitere Verhalten des Routers von dessen Konguration ab. Die Spezikation lässt folgendes Verhalten zu: das Paket wird zum OpenFlow-Controller weitergeleitet das Paket wird verworfen das Paket wird zur nächsten Flow-Tabelle im OpenFlow-Switch weitergeleitet

7 ISE-Seminar SS FH Aachen - Prof. Dr.-Ing. Frank Hartung 7 Die jeweiligen Instruktionen beschreiben Paket-Weiterleitungen, Paket-Modikation, Group-Table Verarbeitung oder Pipeline Verarbeitung (vgl. [OF Spec] S.3). OpenFlow-only Diese Switches unterstützen nur eine Verarbeitung durch die OpenFlow Operationen OpenFlow-hybrid Diese Switches unterstützen sowohl die Verarbeitung durch OpenFlow Operationen als auch durch normale Ethernet Switching Operationen 2.7 OpenFlow Channel Wie zu am Anfang bereits beschrieben haben OpenFlow-Switches eine Schnittstelle zu einem OpenFlow-Controller. Über diese Schnittstelle werden die OpenFlow- Switches konguriert und verwaltet. Die Schnittstelle ist implementierungs-spezisch. Sie muss allerdings alle OpenFlow Message entsprechend dem OpenFlow-Protokoll verarbeiten und formatieren. Dieser OpenFlow Channel ist in der Regel mit TLS verschlüsselt, arbeitet dennoch direkt auf TCP. Eine Unterstützung für eine gleichzeitige Anbindung an mehrere OpenFlow- Controller ist zurzeit nicht in der Spezikation enthalten (vgl. [OF Spec] S.16) Für detailliertere Angaben möchte ich auf die OpenFlow Switch Specication verweisen. 2.8 Netzwerkvirtualisierung (Slicing) In der Praxis möchte man häug die Steuerungslogik auf mehrere Controller verteilen. Falls nur ein Controller genutzt wird, kann dieser zu einem Bottleneck oder zu einem Single Point of Failure werden. Durch den Einsatz mehrere Controller besteht die Möglichkeit mehrere Netzanwendungen unabhängig voneinander und parallel auf der gleichen physischen Netzinfrastruktur auszuführen (vgl. [ix 08/2012]) Die Benutzung mehrerer Controller auf einer gemeinsamen Netzinfrastruktur kann als eine Art Netzwerkvirtualisierung bezeichnet werden. Durch die Trennung des Kontroll-Layers vom Datenpfad (Flow) ist die Virtualisierung trivial. Dabei ist es allerdings erforderlich, dass nicht mehrere Controller die Forwarding-Tabellen der Switches überschreiben können. Die Entwickler von OpenFlow sprechen bei dieser Art von Virtualisierung von Slicing, da jeder Controller eine Scheibe der Switch-Ressource zugewiesen bekommt. Das Slicing kann entweder als Feature direkt vom Hersteller im Switch integriert sein oder als externe Komponente hinzugefügt werden. Als externe Komponente kann z.b. das OpenSource Projekt FlowVisor genutzt werden.

8 8 ISE-Seminar SS FH Aachen - Prof. Dr.-Ing. Frank Hartung 2.9 FlowVisor Beim Slicing eines Netzwerks (Netzwerkvirtualisierung) werden fünf primäre Slicing Dimensionen deniert: Bandbreite Es sollte möglich sein, jedem einzelnen Slice eine eigene Bandbreite pro Link zuzuordnen. Topologie Jede Slice hat eine eigene Sicht auf alle beteiligten Netzwerk-Knoten und deren Verbindung untereinander (Switches / Router). Somit lassen sich Loops z.b. vorab vermeiden. Datenverkehr Es sollte möglich, sein Trac getrennt voneinander über virtuelle Netwerke zu übermitteln. Geräte CPU Jeder Netzwerk-Knoten hat eine bestimmte Kapazität und CPU Leistung, diese müssen ebenfalls teilbar sein. Forwarding Tables Netzwerk-Knoten können nur eine begrenzte Anzahl von Forwarding-Regeln fassen. Hierbei ist darauf zu achten, dass die einzelnen Slices nicht die Regeln anderer Slices überschreibt. FlowVisor arbeitet ähnlich wie ein Virtualisierungs-Layer bei einem Computer. FlowVisor ist eine Schicht zwischen der physischen Hardware und dem Kontroll-Layer. Abbildung 6 verdeutlicht die Anordnung des FlowVisors, physischer Hardware und der verschiedenen Controller. Der FlowVisor benutzt das OpenFlow Protokoll um das darunterliegende physische Netz zu kongurieren (vgl. [FlowVisor]). Er selber kommuniziert mit den einzelnen OpenFlow-Controllern (in der Abbildung 5(a) SAURAV's Controller, KK's Controller und Glen's Controller genannt). Hierbei hat jede Slice nur einen Controller. Der FlowVisor kontrolliert und verwaltet die einzelnen physischen Netzwerkkomponenten, sodass er z.b. das Problem des möglichen Überschreibens der Forwarding-Tabelle vorher erkennt. Der FlowVisor sorgt somit dafür, dass die einzelnen Slices immer in einem konsistenten Zustand bleiben. Der FlowVisor ist keine Erweiterung des OpenFlow-Protokolls, er ist als ein Proxy implementiert. Er fängt die Nachrichten der OpenFlow-Netzwerkkomponenten ab und leitet sie an den zuständigen Gast-Controller weiter. Somit ist auch wieder sichergestellt, dass die einzelnen Slices voneinander getrennt arbeiten. Abbildung 5(b) beschreibt den Ablauf der Arbeitsweise eines FlowVisors. (1) Der FlowVisor unterbricht die Nachrichten der Gast-Controller und prüft diese anhand der Controller Slice Policies (2) er überschreibt die Nachricht so, dass sie

9 ISE-Seminar SS FH Aachen - Prof. Dr.-Ing. Frank Hartung 9 nur die Steuerlogik von dem jeweiligen Netzwerk Slice (3) ändert. Die Nachrichten vom Switch (4) werden nur zu dem jeweiligen Gast-Controller weitergeleitet, bei dem die Slice-Policy zutrit. FlowVisor bietet auch die Möglichkeit mehrere FlowVisors zu kaskadieren. Somit ist es möglich im Netzwerk eine hierarchische Struktur über mehrere FlowVisor aufzubauen. (a) FlowVisor [FlowVisor] (b) Ablauf im FlowVisor [FlowVisor] Abbildung 5. 3 Anwendung und Nutzen Es ist ein Problem neu entwickelte Netzwerkalgorithmen zu testen, da die Integration der neuen Algorithmen in bestehende Netzwerkkomponenten sehr zeitaufwändig ist. Das problematische daran ist auÿerdem, dass die neu entwickelten Algorithmen nicht anhand von echten Trac-Daten getestet werden können. Denn über ein so groÿes Netz wie das Internet kann als Test-Umgebung nicht verfügt werden. Somit können die neuen Netzwerkalgorithmen zwar unter Laborbedingungen getestet werden und evtl. sogar Intranet weit, aber das Verhalten in gröÿeren Netzwerken kann nicht überprüft bzw. gemessen werden. Zudem müssen die Gerätehersteller diese Algorithmen in ihre Geräte integrieren. Man kann evtl. einen Vergleich zu der Einführung von IPv6 ziehen. Die Einführung dauert schon Jahrzehnte an (vgl. [ix 08/2012] S.112). Durch den Zusammenschluss zur ONF zeigt die Industrie den Willen an einer standardisierten Lösung, die herstellerunabhängig ist. Durch diese standardisierte Schnittstelle wird die Timeto-Product reduziert und die Hersteller können schneller neue Algorithmen in ihren Geräten zu Verfügung stellen. Auÿerdem bietet die oene Schnittstelle auch Drittanbietern die Möglichkeit, Produkte für OpenFlow-Komponenten zu entwickeln. Somit ist es z.b. denkbar, dass Firewalls/Intrusion Detection Systems nicht mehr nur in einem Gerät wären, sondern im ganzen Netz verteilt liegen könnten und von einem Controller

10 10 ISE-Seminar SS FH Aachen - Prof. Dr.-Ing. Frank Hartung aus verwaltet werden würden. Ein anderes Beispiel könnte ein Load-Balancer sein, der direkt im Netz abgelegt ist und die Netzwerkstruktur der jeweiligen Netzlast anpasst (vgl. [SNT]). Inzwischen haben einige Universitäten (University of Washigton, Stanford, Wisconsin, Indiana, Princeton, Rutgers, Clemson) in den USA ihre Netzwerke mit OpenFlow ausgestattet und sind untereinander vernetzt. Hier gibt es verschiedene Messungen die auf evtl. auftretende Probleme hinweisen. Das Setup des gröÿten von Stanford implementierten, produktiven OpenFlow-Netzwerks erreicht 500 Flows pro Sekunde. ([SNT]). Laut Doug Gourlay (Vice President of Marketing for Arista Networks) müssen Netzwerke mit Millionen Flows pro Sekunde erreicht werden. 3.1 Probleme Aus der Veröentlichung A First Look at OpenFlow Control Plane Behavior from a Test Deployment geht hervor, dass sich der OpenFlow-Control-Trac zwischen 3 und 4% des Datentracs liegt. Somit wird die Netzwerkinfrastruktur durch den Control-Trac etwas höher belastet. Auÿerdem hat die Auswertung, des in der Veröentlichung untersuchten Datenverkehrs ergeben, dass durch einen Firmware Bug der Daten-Trac komplett vom Control-Trac überschrieben werden kann und somit eine Datenweiterleitung nicht möglich ist. Dieser Bug verdeutlicht die Wichtigkeit einer sorgfältigen Programmierung des Kontroll- Layers und der Steuerlogik um die Robustheit eines Netzwerkes zu gewährleisten. Ebenso wurde herausgefunden, dass es sich für Basisdienste wie ARP, DNS und LLDP ggf. lohnt im OpenFlow-Switch ein vordeniertes Verhalten zu speichern und nicht den OpenFlow-Controller anzufragen. (vgl. [DTAG]) 3.2 Hardware und Software für OpenFlow Im Anhang C bendet sich eine List mit verschiedenen OpenFlow-Controllern, virtueller OpenFlow Hardware und Software sowie verschiedenen Testprogrammen. Eine Analyse der einzelnen Tools ist nicht Bestandteil dieser Arbeit. Im Anhang B bendet sich eine Liste mit verschiedenen OpenFlow-Hardware- Komponenten. Um mit OpenFlow zu experimentieren existiert ein Projekt innerhalb von Europa mit dem Namen OFELIA (OpenFlow in Europe: Linking Infrastructure and Applications). Das Projekt bietet Forschern eine einzigartige Test-Umgebung. Sie können in dieser Test-Umgebung nicht nur Experimente durchführen, sondern es auch selbst dynamisch erweitern. Das OFELIA Netzwerk ist auf Basis von OpenFlow aufgebaut. Das Projekt ist im September 2010 gestartet und endet im September Abbildung 6 zeigt die OFELIA Facilities and Islands (beteiligte Universitäten)

11 ISE-Seminar SS FH Aachen - Prof. Dr.-Ing. Frank Hartung 11 Abbildung 6. OFELIA Facility und Islands Berlin (TUB) - teilweise Ersetzung der am Campus existierenden Netzwerk durch OF-Switches Ghent (IBBT) - zentraler Hub, largescale Emulation Zürich (ETH) - Verbindung zu OneLab und GENI Barcelona (i2cat) - L2 (NEC) Switches und optisches Equipment (ROADM ring) Essex (UEssex) - nationaler Hub für England; L2 (extreme) Switches, FPGA Testbed Rom und Catania (CNIT) - two islands, basierend auf NetFPGA und OpenSwitch Technologie Trento (CREATE-NET) - Stadtweites Netzwerk basierend auf L2 (NEC) Swiches und NetFPGA Somit ist OFELIA eine Alternative für die Entwicklung und Forschung mit OpenFlow. Zumindest bis September Anwendung von OpenFlow für Medieninhalte Wie aus Kapitel 1 hervorgeht, wird das Netzwerk nicht anhand von Paketen de- niert, sondern anhand von Flows. Wie der Name schon sagt wird ein Fluss von der Quelle zu einem Ziel gesucht. Hierfür sind aus der Mathematik verschiedene Algorithmen bekannt um den optimalen Weg zu nden. Diese Algorithmen können in dem OpenFlow-Controllern integriert werden bzw. sind darin schon implementiert. Somit kann für jeden Flow der optimale Weg gefunden werden. Daraus kann man folgern, dass sich für groÿe Dateien der Aufwand den Controller anzufragen und alle auf dem Weg liegenden Switches zu kongurieren lohnt. Jedoch zeigen erste Messungen (vgl. [DTAG]), dass diese Netzwerkstruktur für Anfragen wie ARP und DNS einen groÿen Overhead erzeugt. Da es sich bei Medieninhalten in der Regel um groÿe Dateien handelt, wäre der SDN Ansatz in Ausprägung mit OpenFlow für Medieninhalte sehr gut geeignet. Wie im Anfangsbeispiel schon erwähnt, können so spezielle Inhalte über schnellere bzw. kürzere Strecken gesendet werden. Denn nachdem der Controller den Flow berechnet und an die jeweiligen OpenFlow-Switches verteilt hat, werden die Paket direkt entlang des Flows weitergeleitet. Somit wird nur einmalig für den gesamten Inhalt der Mediendatei der Controller nachgefragt.

12 12 ISE-Seminar SS FH Aachen - Prof. Dr.-Ing. Frank Hartung 3.4 Anwendbarkeit im Internet und in Intranets Die Frage bezüglich der Anwendbarkeit von SDN im Internet und in Intranets kann aus meiner Sicht noch nicht abschlieÿend beantwortet werden, da hierfür zu wenig Erfahrungs- bzw. Messwerte vorliegen. Da es jedoch OpenFlow-hybride Switches gibt, die sowohl die klassische Methode unterstützen als auch den SDN- Ansatz, spricht nichts gegen eine Anwendbarkeit im Internet und in Intranets. Denn falls die neue Methode im Einsatz schlechtere Ergebnisse liefert als die herkömmliche, kann dank der Hybridität der Switches auf die herkömmliche Methode zurückgegrien werden. Die Industrie zeigt allein schon durch die Bildung des Konsortiums ein groÿes Interesse an diesem Ansatz. Wie auch erste Messungen zeigen, gibt es in vielen Fällen einen Nutzen, wie z.b. durch die vereinfachte Konguration. Abschlieÿend kann man sagen, dass durch den Wandel der Computerlandschaft von einem Einzug des SDN-Ansatzes in die Netzinfrastrukturen auszugehen ist. Es werden vermutlich noch einige Anpassungen in der Spezikation erforderlich sein, aber der Ansatz ist vielversprechend.

13 ISE-Seminar SS FH Aachen - Prof. Dr.-Ing. Frank Hartung 13 A Firmen und Hochschulen A.1 Mitglieder der ONF Eine vollständige Liste alle Mitglieder der ONF sind unter A.2 Deutscher Universitäten/Laboratorien die sich mit OpenFlow und SDN beschäftigen: Institut für Kommunikationsnetze und Rechnersysteme (IKR) Universität Stuttgart Pfaenwaldring 47 D Stuttgart Prof. Dr.-Ing. Andreas Kirstädter Telefon: Telefax: andreas.kirstaedter@ikr.uni-stuttgart.de Leibniz Universität Hannover Institut für Kommunikationstechnik Appelstraÿe 9a Hannover Prof. Dr. Panagiotis Papadimitriou Telefon: panagiotis.papadimitriouikt.unihannover.de Technische Universität Berlin Institut Deutsche Telekom Laboratories Research Group Anja Feldmann Ernst-Reuter-Platz Berlin Phone: Fax: Otto-von-Guericke-Universität Fakultät für Informatik Institut für Verteilte Systeme Herrn Prof. Dr. rer. nat. Edgar Nett Postfach 4120 D Magdeburg Telefon: (+49) Fax: (+49) nett@ovgu.de B OpenFlow kompatible Hardware HP Procurve 5400zl: This switch typically features 48 x 1Gbps ports that are expandable to 576 ports. Support OpenFlow ver NEC PF5240: This switch typically features 48 x 1Gbps ports, along with 2 x 10Gbps ports. Supports OpenFlow ver up 1.0 NEC Univerge PF x 10GbE(SPF/SFP+) ports + 4 x 40GbE(QSFP+) ports in compact 1U form factor

14 14 ISE-Seminar SS FH Aachen - Prof. Dr.-Ing. Frank Hartung C Auistung einiger OpenFlow Projekte C.1 Switch Software and Stand-Alone OpenFlow Stacks Open vswitch: (C/Python) Open vswitch is a an OpenFlow stack that is used both as a vswitch in virtualized environments and has been ported to multiple hardware platforms. It is now part of the Linux kernel (as of 3.3). OpenFlow Reference: (C) The OpenFlow reference implementation is a minimal OpenFlow stack that tracks the spec. Pica8: (C) An open switch software platform for hardware switching chips that includes an L2/L3 stack and support for OpenFlow. Indigo: (C) Indigo is a for-hardware-switching OpenFlow implementation based on the Stanford reference implementation. Pantou: (C) Pontou is an OpenFlow port to the OpenWRT wireless environment. OpenFaucet: (Python) OpenFaucet is a pure Python implementation of the OpenFlow protocol, based on Twisted. OpenFaucet can be used to implement both switches and controllers in Python. OpenFlowJ: (Java) OpenFlow stack written in Java. Oib-node: (Javascript) Oib-node is an OpenFlow protocol library for Node. It converts between OpenFlow wire protocol messages and Javascript objects. Nettle: (Haskell) OpenFlow library written in Haskell. C.2 Controller Platforms POX: (Python) Pox as a general SDN controller that supports OpenFlow. It has a high-level SDN API including a queriable topology graph and support for virtualization. MUL: (C) MUL, is an openow (SDN) controller. It has a C based mulithreaded infrastructure at its core. It supports a multi-level north bound interface for hooking up applications. It is designed for performance and reliability which is the need of the hour for deployment in mission-critical networks. NOX: (C++/Python) NOX was the rst OpenFlow controller. Jaxon: (Java) Jaxon is a NOX-dependent Java-based OpenFlow Controller. Trema: (C/Ruby) Trema is a full-stack framework for developing OpenFlow controllers in Ruby and C. Beacon: (Java) Beacon is a Java-based controller that supports both eventbased and threaded operation. Floodlight: (Java) The Floodlight controller is Java-based OpenFlow Controller. It was forked from the Beacon controller, originally developed by David Erickson at Stanford. Maestro: (Java) Maestro is an OpenFlow öperating system"for orchestrating network control applications.

15 Literatur ISE-Seminar SS FH Aachen - Prof. Dr.-Ing. Frank Hartung 15 [ONF 2012] Software-Dened Networking: The New Norm for Networks [FKS 2012] Mathias Hein, Consultant; OpenFlow als Alternative zu Spanning-Tree, [ix 08/2012] Zdravko, Bozakov; OpenFlow - eine Softwareschnittstelle zur Netzprogrammierung - Alles ieÿt, S.112 [OF Spec] Open Network Foundation; OpenFlow Switch Specication, February 28, 2011 [FlowVisor] FlowVisor: A Network Virtualization Layer S. 2f [DTAG] Anja Feldmann, Dan Levin; A First Look at OpenFlow Control Plane Behavior from a Test Deployment [WikiEth] Wikipedia Artikel zu Ethernet [SNT] Shamus McGillicuddy; Ansätze und Potentiale von Software- Dened Networks, Was hinter dem OpenFlow-Hype steckt