Skalierbarkeit von Software Defined Networking mit Open Flow

INHALTSVERZEICHNIS

ABBILDUNGSVERZEICHNIS

TABELLENVERZEICHNIS

ABKÜRZUNGSVERZEICHNIS

1. EINLEITUNG
1.1 Einführung
1.2 Zielsetzung
1.3 Inhaltlicher und formaler Aufbau

2 STAND DER TECHNIK
2.1 Traditionelle Netzwerkarchitektur
2.2 Software-Defined Networking
2.2.1 VOM TRADITIONELLEN NETZWERK ZU SDN
2.3 SDN - Architektur
2.3.1 SOUTHBOUND INTERFACE PROTOKOLLE
2.3.2 NORTHBOUND APIS
2.4 OpenFlow Protokoll
2.4.1 OPENFLOW SPEZIFIZIERUNG
2.4.1.1 OpenFlow Version 1.0.0
2.4.1.2 OpenFlow Version 1.1.0
2.4.1.3 OpenFlow Version 1.2.0
2.4.1.4 OpenFlow Version 1.3.0
2.4.1.5 OpenFlow Version 1.4.0
2.4.2 VERGLEICH DER OPENFLOW VERSIONEN
2.5 Skalierbarkeit von SDN
2.5.1 SDN-CONTROLLER SKALIERBARKEIT
2.5.1.1 Beschreibung FlowVisor
2.5.2 SKALIERBARKEIT IN RECHENZENTREN
2.6 Zusammenfassung des aktuellen Standes von SDN mit OpenFlow

3 EXPERTENBEFRAGUNG
3.1 Experteninterviews
3.1.1 VORSTELLUNG DER EXPERTEN
3.1.2 AUFBAU DES INTERVIEWLEITFADENS
3.1.3 UMSETZUNG DER EXPERTENINTERVIEWS

4 AUSARBEITEN DER INTERVIEWS
4.1 Auswertung Software Defined Networking
4.1.1 EXPERTENDEFINITIONEN VON SOFTWARE DEFINED NETWORKING:
4.1.2 WELCHE VORTEILE SEHEN DIE EXPERTEN VON SDN GEGENÜBER TRADITIONELLER NETZWERKARCHITEKTUR:
4.1.3 WELCHE NACHTEILE SEHEN DIE EXPERTEN VON SDN GEGENÜBER TRADITIONELLER NETZWERKARCHITEKTUR:
4.1.4 WO SDN IMPLEMENTIERUNGEN NACH MEINUNGEN DER EXPERTEN SINN MACHEN:
4.1.5 WIE KANN EINE IMPLEMENTIERUNG VON SDN AUS SICHT DER EXPERTEN UMGESETZT WERDEN:
4.1.6 WELCHE PROBLEME KÖNNEN AUS SICHT DER EXPERTEN BEI SDN IMPLEMENTIERUNGEN AUFTRETEN:
4.1.7 WIE BEWERTEN EXPERTEN DIE ZUKUNFT VON SDN:
4.2 Auswertung OpenFlow
4.2.1 EXPERTENDEFINITIONEN VON OPENFLOW:
4.2.2 WELCHE VORTEILE SEHEN DIE EXPERTEN IN OPENFLOW:
4.2.3 WELCHE NACHTEILE SEHEN DIE EXPERTEN IN OPENFLOW:
4.2.4 VON EXPERTEN BEVORZUGTE OPENFLOW VERSION:
4.2.5 WIE BEWERTEN DIE EXPERTEN DIE ZUKUNFT VON OPENFLOW:
4.3 z, sowie Zielset- zung und
4.3.1 WAS DIE EXPERTEN UNTER SKALIERBARKEIT IN DER NETZWERKTECHNIK VERSTEHEN:
4.3.2 WIE BEWERTEN DIE EXPERTEN DEN STELLENWERT DER SKALIERBARKEIT IN DER NETZWERKTECHNOLOGIE:
4.3.3 WELCHE VORTEILE SEHEN DIE EXPERTEN VON SDN MIT OPENFLOW BEZOGEN AUF DIE SKALIERBARKEIT IM RECHENZENTRUM:
4.3.4 WELCHE NACHTEILE SEHEN DIE EXPERTEN VON SDN MIT OPENFLOW BEZOGEN AUF DIE SKALIERBARKEIT IM RECHENZENTRUM:
4.3.5 EINSCHÄTZUNGEN DER EXPERTEN, OB SDN MIT OPENFLOW IMSTANDE IST, DIE SKALIERUNGSANFORDERUNGEN AN DIE NETZWERKE IN DER ZUKUNFT ZU BEWÄLTIGEN:
4.4 Vorteile und Nachteile beim Einsatz von SDN mit OpenFlow
4.4.1 VORTEILE
4.4.2 NACHTEILE

5 ZUSAMMENFASSUNG UND BEANTWORTUNG DER FORSCHUNGSFRAGEN
5.1 Zusammenfassung des aktuellen Forschungsstands zu SDN mit OpenFlow
5.2 Beantwortung der Forschungsfragen:

6 AUSBLICK

7 LITERATURVERZEICHNIS

8 ANHANG
8.1 Interviewleitfaden Experteninterview Pfeiffenberger
8.2 Interviewleitfaden Experteninterview Koch
8.3 Interviewleitfaden Experteninterview Friedl
8.4 Interviewleitfaden Experteninterview Klinglhuber

DANKSAGUNG

An dieser Stelle möchte ich mich bei der OAFA Ärzteflugambulanz GmbH, insbesondere bei Herrn Dr. Helmut Zewedin, für die zeitliche und finanzielle Unterstützung bedanken. Ich weiß, dass solch eine Unterstützung in der heutigen Zeit keine Selbstverständlichkeit darstellt. Herzlichen Dank dafür.

Ein Dank geht auch an die Experten, die sich bereit erklärt haben, ihre knappe Zeit für den Erfolg dieser Arbeit zur Verfügung zu stellen. Ein Dank richtet sich ebenso an die Donau Universität Krems für zwei harte, aber sehr interessante und lehrreiche Jahre. Die Erfahrungen und die „Erweiterung des Horizontes“ sind schon heute ein deutlicher Mehrwert, der mir täglich zur Verfügung steht.

Ein besonderer Dank geht an meinen Betreuer Dr. Philipp Liegl für die Unterstützung in der Erstellung dieser Arbeit.

KURZBESCHREIBUNG

Software Defined Networking ist ein neuer Architekturansatz in der Netzwerk- kommunikation. Bei dieser Architektur wird die Steuerungslogik aus den Netz- werkkomponenten extrahiert und zu einem externen Controller ausgelagert. An den Schnittstellen der Netzwerkkomponenten und den Controllern, dem soge- nannten Southbound Interface, hat sich das Protokoll OpenFlow zur Kommunika- tion als Standard durchgesetzt. OpenFlow wird von der Open Network Foundati- on unterstützt und weiterentwickelt. OpenFlow verspricht anhand dieser Architek- tur eine hohe Skalierbarkeit, Herstellerunabhängigkeit und die Möglichkeit einer zentralen Sicht auf das Netzwerk an den Tag zu legen. Trotz dieser Versprechen gibt es aber Bedenken, bezogen auf die Skalierbarkeit und Ausfallssicherheit des Controllers. Anhand durchgeführter Experteninterviews gibt es im österreichi- schen IT-Umfeld bis dato keine einzige Implementierung, die produktiv in einem Rechenzentrum im Einsatz ist. Gründe mögen in der jungen Technologie, den hohen Kosten und im fehlenden Know-how liegen. Hersteller forcieren den Ein- satz dieser Technologie. Experten sehen auch keine Alternativen am Markt dazu. Trotz all dieser Vor- und Nachteile sagen vier österreichische Netzwerkexperten Software Defined Networking mit OpenFlow, bezogen auf die Skalierbarkeit, eine große Zukunft voraus.

ABSTRACT

Software Defined Networking is a new approach for network communication. In this architecture the control logic is extracted from the networking components and transferred to an external controller. The interface between controller and networking component is called southbound interface. OpenFlow is the estab- lished protocol that communicates with the southbound interface. The Open Net- work Foundation is supporting a wider adoption of this protocol. OpenFlow prom- ises big advantages in scalability, multivendor-capability and a central view of the whole network based on this architecture. Nevertheless, there are still concerns about scalability and reliability of the controller. Therefore, I conducted expert interviews to analyze the current situation of Software Defined Networking with OpenFlow in the Austrian IT landscape. Currently, there is no live implementation in an Austria data center that makes use of these technologies. The reasons may be due to the young technology, the high costs or in the missing know-how. Manufacturers are pushing the adoption of Software Defined Networking as there are currently no alternatives available on the market. Despite all these advan- tages and disadvantages, four Austrian networking experts predict a bright future for Software Defined networking with OpenFlow because of the easy scalability.

Abbildungsverzeichnis

ABBILDUNG 1: SCHICHTENSICHT IM NETZWERK

ABBILDUNG 2: TRADITIONELLE NETZWERKARCHITEKTUR ZU SDN

ABBILDUNG 3: SDN-ARCHITEKTUR

ABBILDUNG 4: FLOW TABLE

ABBILDUNG 5: OPENFLOW KOMPONENTEN

ABBILDUNG 6: OPENFLOW FÄHIGES NETZWERKGERÄT

ABBILDUNG 7: OPENFLOW 1.1.0 PIPELINE PROCESSING

ABBILDUNG 8: ARCHITEKTUR OPENFLOW MIT FLOWVISOR

Tabellenverzeichnis

TABELLE 1: OPENFLOW VERSION 1.0.0 HEADER FIELDS

TABELLE 2: COUNTERS IN OPENFLOW 1.0.0

TABELLE 3: MODIFY-FIELDS IN OPENFLOW 1.0.0

TABELLE 4: OPENFLOW VERSION 1.1.0 MATCH FIELDS

TABELLE 5: COUNTERS IN OPENFLOW 1.1.0

TABELLE 6: SET-FIELDS IN OPENFLOW VERSION 1.1.0

TABELLE 7: METER TABLE EINTRÄGE

TABELLE 8: OPENFLOW MATCH FIELD UND PROTOKOLLE

TABELLE 9: ARTEN VON STATISTIKEN BEI OPENFLOW SWITCHES

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

1.1 Einführung

Das Rechenzentrum zu virtualisieren und der Einsatz von Cloud-Computing hatten in der letzten Dekade einen enormen Einfluss auf die Informationstechnologie. Diese beiden Techniken haben Anwendungsentwickler und ITAdministratoren bzw. Netzwerkverantwortliche mit der notwendigen Flexibilität ausgestattet, jeden Quadratmeter im Rechenzentrum auszunutzen und die verfügbare Hardware bestmöglich auszulasten. Das darunterliegende Netzwerk hat sich im Vergleich dazu nicht wesentlich weiterentwickelt.¹

In der heutigen Zeit ist fast alles mit allem vernetzt. Es ist möglich von überall, ob mit PC, Handy oder Tablets, auf Daten zuzugreifen. Traditionelle IP Netzwerke sind komplex und schwer zu managen. In diesen Netzen ist es ein großer Auf- wand Netzwerkrichtlinien in Abhängigkeit von Verfügbarkeit, Bandbreite und Aus- lastung zu ändern, beziehungsweise zu steuern. Erschwerend kommt hinzu, dass heutige Netzwerke eine vertikale Architektur besitzen. Dies bedeutet, dass Kontrollschicht (die entscheidet, wie eine Komponente im Netzwerk den Daten- verkehr weiterleitet) und Datenschicht (die aufgrund von Entscheidungen der Kontrollschicht den Datenverkehr weiterleitet) in einer Einheit zusammengefasst werden. Software-Defined Networking (SDN) verspricht durch das Auftrennen der vertikalen Architektur (Separierung von Daten und Kontrollschicht), diese Prob- leme zu lösen. Durch das Auftrennen dieser Schichten soll ermöglicht werden, Netzwerke zu programmieren und zentral zu steuern.²

Der Mittelpunkt in einem mit SDN realisierten Netzwerk ist der Controller. Er be- findet sich an einem Ende bei den Netzwerk-Geräten und am anderen Ende an den Applikationen. Jede Kommunikation, zwischen Anwendungen und Netzwerk- Geräten, wird durch den Controller beinflusst. Dieser Controller benutzt Protokol- le wie OpenFlow, um die Netzwerk-Geräte zu steuern, damit diese den besten Weg für den Anwendungs-Traffic im Netzwerk zur Verfügung stellen. Der SDN- Controller ist somit eine Art Betriebssystem des Netzwerkes. Er entzieht der Netzwerk-Hardware die Kontrolle und verwirklicht diese Steuerung mit Software. Dadurch erleichtert der SDN-Controller das automatische Netzwerk- Management.³

In den Artikeln zu dieser Technologie kommen immer wieder zwei Begriffe vor: Northbound und Southbound. In der Northbound-Kommunikation oder Northbound-Bridge teilen die Applikationen dem Controller mit, wie er das Netz- werk programmieren soll. In der Southbound-Kommunikation oder Southbound- Bridge werden die einzelnen Netzwerk-Geräte durch den Controller program- miert.⁴

1.2 Zielsetzung

Das Ziel dieser Master Thesis ist es, den aktuellen Stand von SDN und OpenFlow, bezogen auf die Skalierbarkeit zu untersuchen. Der aktuelle Stand der zu untersuchenden Technologien wird durch Inhaltsanalyse zeitgemäßer Dokumentationen und Papers sichergestellt.

Zusätzlich zu der theoretischen Inhaltsanalyse werden Experten befragt. Diese Interviews werden durchgeführt, um die Expertenmeinungen von SDN bezogen auf die Skalierbarkeit zu untersuchen.

Mit dieser Arbeit soll es Netzwerkspezialisten ermöglicht werden, einen Überblick über die Vor- und Nachteile von SDN mit OpenFlow, bezogen auf die Skalierbar- keit zu erhalten. Des Weiteren soll ein Überblick geschaffen werden, welche Aspekte bei einer Implementation, bezogen auf die Skalierbarkeit, zu berücksich- tigen sind.

Folgende Forschungsfragen sollen in dieser Master Thesis beantwortet werden:

„Wie bewerten österreichische Netzwerkexperten SDN mit OpenFlow zur Abdeckung der Anforderungen an die Skalierbarkeit im Rechenzentrum? Welche Möglichkeiten gibt es und welche Probleme können dabei auftre- ten?“

1.3 Inhaltlicher und formaler Aufbau

Die Arbeit wird in 8 Kapitel unterteilt, welche in Folge kurz beschrieben werden.

Kapitel 1 beschreibt das Forschungsproblem und die Relevanz, sowie Zielset- zung und Aufbau dieser Arbeit. In Kapitel 2 werden die Technologien und Spezi- fizierungen von SDN, OpenFlow und Skalierbarkeit erläutert. Zu Anfang des 2. Kapitels wird auch kurz die traditionelle Netzwerkarchitektur umrissen, um den Unterschied zu SDN besser darzustellen.

Kapitel 3 widmet sich der Expertenbefragung zum Thema SDN. Kapitel 4 setzt den Fokus auf die Ausarbeitung der Experteninterviews, die Vor- und Nachteile von SDN aufzuzeigen und die Aussagen der Experten in Bezug auf die Skalierbarkeit von SDN zu analysieren.

Kapitel 5 bietet eine Zusammenfassung und es wird versucht, die Forschungsfragen zu beantworten. Kapitel 6 widmet sich dem Ausblick auf zukünftige Forschungsthematiken. Kapitel 7 beinhaltet das Literaturverzeichnis und in Kapitel 8 findet man den Anhang.

Um den formalen Anforderungen für wissenschaftliches Arbeiten gerecht zu wer- den, werden alle Zitate im Originalwortlaut angeführt. Technische Begriffe, wel- che auch im täglichen Sprachgebrauch in der englischen Sprache genutzt wer- den, werden daher in dieser Arbeit nicht auf deutsch übersetzt, sondern im Origi- nalwortlaut angewandt.

2 Stand der Technik

Im folgenden Kapitel wird auf den jetzigen Stand der Technik eingegangen. Die- ser umfasst eine kurze Beschreibung der traditionellen Netzwerkarchitektur. Da- nach wird die Architektur von Software Defined Networking beschrieben. Im An- schluss an SDN wird das Protokoll OpenFlow mit den unterschiedlichen Versio- nen dargestellt und zum Abschluß wird die Skalierbarkeit von SDN thematisiert.

2.1 Traditionelle Netzwerkarchitektur

Computernetzwerke können in 3 Schichten (engl. Planes) unterteilt werden. Die Data, Control und Management Plane (siehe Abbildung 1).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Schichtensicht im Netzwerk⁵

Die unterste Schicht - Data Plane, auch als Datenebene, Forwardingebene, Da- tenschicht oder Trägerschicht bezeichnet - hat zur Aufgabe, den Netzwerk-Traffic bzw. den Datenverkehr zu transportieren. Die Data Plane erlaubt die Datenüber- tragung von und zu Netzwerkclients, indem sie die Kommunikation mithilfe mul- tipler Protokolle verarbeitet. Zudem wird die Kommunikation mit außenstehenden Netzwerkgeräten arrangiert.⁶

Die mittlere Schicht - Control Plane - ist jener Teil des Netzwerkes, der für das Routing verantwortlich ist und den Signalverkehr trägt.⁷ Weiters füttert die Control Plane die Data Plane mit Informationen, wie diese ihren Netzwerk-Traffic zu steuern hat und versorgt diese auch mit Updates mithilfe von Routinginformationen über Veränderungen der Topologie im Netzwerk.⁸

Die oberste Schicht - Management Plane - beinhaltet die Software-Services wie zum Beispiel SNMP-basierte Werkzeuge, welche dazu gebraucht werden, die Control Plane zu konfigurieren und zu überwachen. Netzwerkrichtlinien sind in der Managementschicht definiert, die Kontrollschicht zwingt die Datenschicht, die Richtlinien auszuführen und die Daten entsprechend weiterzuleiten.⁹

Bei konventionellen Netzwerken sind alle drei Schichten in der Firmware eines Switches oder Routers eingebettet.¹⁰

2.2 Software-Defined Networking

Um zu verstehen, was die Software in SDN bedeutet, hilft es einen Schritt zurück zu machen. Im durchschnittlichen Switch oder Router findet man zwischen 2 und 10 Millionen Zeilen von Software-Code, abhängig von den Funktionen, welche bereitgestellt werden. Wir haben also bereits eine Menge an Software im heutigen Netzwerkequipment. Der Schlüssel ist, dass diese Software nicht wirklich das Netzwerk „definiert“. Die zwei Hauptanforderungen, welche Netzwerkoperatoren an die Netzwerktechnologie haben, sind folgende:

(a) Die Möglichkeit einer schnellen Umstrukturierung wie auch Anpassung des Netzwerkes in Abhängigkeit der Anforderungen (höhere Geschwin- digkeiten, verschiedene Arten der Wegeberechnung eines Netzwerk Pa- Datenschicht. ckets, verschiedene Möglichkeiten um die Anforderungen der End-User zu behandeln).

(b) Optimale Kosten (bester verfügbarer Weg durch das Netzwerk).

Es ist daher nicht möglich, in den Geräten einen neuen Code zu schreiben und daraus ein völlig anderes Netzwerk zu erhalten. Der Grund liegt darin, wie ein Netzwerk aufgebaut ist.

Ein Netzwerk besteht im Allgemeinen aus 3 Komponenten.

(a) Endverbraucher: Webserver, Cloudspeicher, Mobiltelefone, uvm.
(b) Netzwerkgeräte: Basisstationen für den Mobilfunk, Routern, Switches, uvm.
(c) Zugriffspunkte (wired oder wireless): verbinden die Endverbraucher mit den Netzwerkgeräten beziehungsweise mit der Netzwerkinfrastruk- tur.¹¹

2.2.1 Vom traditionellen Netzwerk zu SDN

In der letzten Dekade hat sich eine Revolution bei den Endverbrauchern ereignet. Unsere Handys und Server erlebten einen Anstieg ihrer Intelligenz und Rechenleistung um mehr als das Tausendfache. Drahtlose Netzwerke im Gigabit Bereich und Drahtgebundene Netzwerke jenseits der 100 Gigabits sind möglich. Die Netzwerkgeräte wurden jedoch nur stufenweise an diese Veränderungen angepasst. Dafür gibt es verschieden Gründe.

Netzwerkkomponenten wie Switches oder Router beinhalten je nach Anforderung eigens entwickelte Prozessoren (embedded processors). Diese eigens entwickel- ten Prozessoren sind nicht zwingend die schnellsten am Markt üblichen. Es ist keine Seltenheit, dass diese Prozessoren langsamer sind als jene in Smartpho- nes. Heutige Netzwerke transportieren sehr viele Daten über sehr große Netz- werktopologien mit komplexen Algorithmen, welche wesentlich mehr Prozessor- leistung benötigen. Die Prozessoren in den Netzwerkkomponenten können je- doch nicht einfach ausgetauscht werden, da die darauf programmierte Software nicht mit neueren Prozessoren kompatibel ist. Daher ist das einfache Austauschen der Prozessoren keine gültige Option, um den gestiegenen Anforderungen gerecht zu werden.

Führende Entwickler und Firmen haben sich daher folgende Fragen gestellt:

- Wie ist es möglich, bestehende Algorithmen und Berechnungen aus den Netzwerkkomponenten zu extrahieren bzw. zu exportieren?
- Ist es möglich, Geräte zu verwenden, welche eine höhere Leistungsfähig- keit aufweisen?
- Wenn das möglich ist, müsste es doch auch möglich sein, flexiblere und intelligentere Netzwerke zu schaffen?

Wenn man das erreicht hat, dann transformiert man traditionelle Netzwerke in „software-defined“ Netzwerke. Die „Intelligenz“ der Netzwerkkomponenten wird ausgelagert in einen eigenen Server, den sogenannten SDN-Controller.¹² Der Controller ist der Drehpunkt in einem mit SDN realisierten Netzwerk. Dieser be- findet sich zwischen den Netzwerkgeräten und den Applikationen. Es muss also jede Kommunikation zwischen den Applikationen und den Geräten durch den Controller. SDN-Controller nutzen Protokolle wie OpenFlow, um Netzwerkgeräte zu konfigurieren, um den optimalen Weg durch das Netzwerk aufgrund des An- wendungs-Traffic zu wählen. Man kann den SDN-Controller auch als eine Art Betriebssystem für das Netzwerk bezeichnen.¹³

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Traditionelle Netzwerkarchitektur zu SDN¹⁴

SDN unterscheidet sich durch drei Gesetzmäßigkeiten von einer traditionellen Netzwerkarchitektur:

1. Control Plane und Data Plane Traditionell: Control und Data Plane befinden sich gemeinsam in einem Netzwerkelement. SDN: Control Plane ist separiert von der Data Plane und befindet sich im SDN-Controller.
2. Kontrollintelligenz Traditionell: Die Kontrollintelligenz ist verteilt in jedem einzelnen Netzwerkelement. SDN: Die Kontrollintelligenz befindet sich zentral im SDN-Controller.
3. Programmierfähigkeit des Netzwerkes durch Applikationen Traditionell: Das Netzwerk kann nicht programmiert werden durch Appli- kationen. Jedes Netzwerkelement muss einzeln programmiert werden. SDN: Das Netzwerk kann durch Applikationen programmiert werden.¹⁵

2.3 SDN - Architektur

Der Autor beschreibt SDN anhand der Definition der ONF (Open Network Foundation), da diese Definition die weltweit verbreiterste und von den führenden Technologiekonzernen anerkannt wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: SDN-Architektur¹⁶

Abbildung 3 zeigt die Architektur von SDN, welche aus drei Schichten (Layers) besteht. Die unterste Schicht ist der Infrastructure Layer oder auch Data Plane genannt. Er ist verantwortlich für die Weiterleitung und Überwachung des Netz- werkverkehrs.

Die mittlere Schicht ist der Control Layer oder auch Control Plane genannt. Diese Schicht ist verantwortlich für die Programmierung und das Management der Data Plane. Die Control Plane verarbeitet aber auch Informationen der Data Plane und definiert so den Netzwerkbetrieb und das Routing. Sie enthält einen oder mehrere SDN-Controller, welche über ein Standardinterface mit der Data Plane kommunizieren.

Dieses Standardinterface wird auch als Southbound Interface bezeichnet. OpenFlow ist das am meisten verwendete Protokoll für die Kommunikation im Southbound Interface.

Der Application Layer beinhaltet die Netzwerkapplikationen. Er erhält eine abstrahierte und globale Sicht des Netzwerkes vom SDN-Controller und nutzt diese Informationen, um den Controller zu steuern beziehungsweise zu lenken. Das Interface zwischen Control Layer und Application Layer wird als Northbound Interface bezeichnet. Zur Zeit gibt es keine standardisierte API (Application Programming Interface) für das Northbound Interface. In der Praxis stellt der SDNController seine eigene API für Anwendungen bereit.¹⁷

2.3.1 Southbound Interface Protokolle

Das am weitesten verbreitete Protokoll am Southbound Interface ist OpenFlow, welches durch die Open Network Foundation standardisiert wurde. OpenFlow als Protokoll beschreibt die Interaktion von einem oder mehreren SDN-Controllern mit OpenFlow fähigen Switches beziehungsweise Routern. Ein OpenFlow Cont- roller installiert im Switch einen sogenannten Flow Table. Anhand dieser Flow Tables wird der Netzwerkverkehr weitergeleitet.¹⁸ Siehe Abbildung 4.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Flow Table¹⁹

Ein weiteres Protokoll, welches das Southbound Interface nutzt, ist das ForCES (Forwarding and Control Element Separation). Diese Technolgie ist nicht nur ein Protokoll, es ist auch ein Framework, welches seit 2003 standardisiert und entwi- ckelt wird durch eine Arbeitsgruppe bei der IETF (Internet Engineering Task Force).²⁰

In der „The SoftRouter architecture“ kommt es ebenso zur Trennung von Data Plane und Control Plane Funktionalitäten. Bei dieser Architektur werden alle Control Plane Funktionalitäten in einen so genannten „General Purpose Server“, welcher als „Control Elements“ (CEs) bezeichnet wird, implementiert. Dieser kann mehrere Hops von den Forwarding Elements (FEs) entfernt sein.²¹

In dieser Master Thesis wird nur das OpenFlow Protokoll näher betrachtet.

2.3.2 Northbound APIs

Wie schon erwähnt, stellt das OpenFlow Protokoll ein Interface (Southbound In- terface) zur Verfügung, welches das Steuern und Kontrollieren der Netzwerkge- räte übernimmt. Grundsätzlich ändert und kontrolliert der SDN-Controller die Wei- terleitungstabelle in den Netzwerkelementen. SDN-Controller stellen den Applika- tionen ähnliche Schnittstellen bereit. Diese Schnittstellen werden als Northbound APIs bezeichnet, welche die Aufgabe haben die Programmierfähigkeit des Netz- werkes hervorzuheben. Das Northbound Interface ist nicht standardisiert, aber erlaubt eine sehr feine Kontrolle der Netzwerkelemente. Applikationen soll- ten sich nicht mit den Details des Southbound Interfaces beziehungsweise mit der Netzwerktopologie auseinandersetzen. Zum Beispiel: Eine Netzwerkapplika- tion in einem Verkehrsleitsystem soll dem SDN-Controller den besten Weg mittei- len, wobei der SDN-Controller dann die Steuerung und Programmierung der Netzwerkelemente übernimmt. Dies bedeutet, dass Programmiersprachen zum Vereinfachen und Automatisieren der Konfiguration und des Netzwerkmanage- ments benötigt werden.²²

Die Anforderungen an eine Programmiersprache für SDN werden in drei wichtige Aspekte eingeteilt.

1. Die Programmiersprache muss den Status des Netzwerkes abfragen können. Diese Daten beziehungsweise Statistiken sollen der Applikation zur Verfügung gestellt werden.
2. Die Sprache muss verschiedene Netzwerkrichtlinien von verschiedenen Netzwerkapplikationen kombinieren und Konflikte erkennen können. An- hand dieser Informationen ist es möglich, die Weiterleitung des Netzwerk- verkehrs zu steuern und zusätzlich muss die Sprache schnell genug sein, um Kontroversen zu lösen.
3. Das Verändern eines Netzwerkes ist eine schwierige Aufgabe, speziell mit verschiedenen Netzwerkrichtlinien. Für die Laufzeitumgebung der Programmiersprache muss ein reservierter Zugriff für den Update Pro- zess ermöglicht werden, um Routingschleifen oder andere unerwünschte Effekte zu unterbinden.²³

Bekannte SDN Programmiersprachen, welche diese Anforderungen erfüllen, sind Frenetic, Pyretic und Procera. Diese Sprachen bieten einen deklarativen Syntax und beruhen auf FRP (functional reactive programming). Aufgrund dieser FRP Eigenschaft versprechen diese Sprachen die Möglichkeit, ein Interface für das Programmieren von Netzwerkrichtlinien zu erzeugen.²⁴

2.4 OpenFlow Protokoll

OpenFlow ist ein standardisiertes Kommunikationsprotokoll zwischen der Control und der Data Plane in einer SDN Architektur. OpenFlow ermöglicht den direkten Zugriff und die Bearbeitung der Data Plane beziehungsweise des Flow Tables, egal ob in einer physischen oder in einer virtuellen (hypervisor) Umgebung. OpenFlow wurde an der Stanford University entwickelt und wird nun durch die Open Network Foundation (ONF) standardisiert und weiterentwickelt. Die ONF ist ein non-profit Konsortium, welches von verschiedenen Unternehmen gegründet wurde.²⁵

2.4.1 OpenFlow Spezifizierung

Eine OpenFlow Architektur besteht aus drei Hauptkomponenten:

1. einem OpenFlow fähigen Switch
2. einem Secure Channel und
3. einem Controller siehe Abbildung 5.²⁶

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: OpenFlow Komponenten²⁷

Switches nutzen diesen Flow Table um Packets weiterzuleiten. Ein Flow Table ist eine Liste von sogenannten Flow Entries. Jeder Flow Entry besitzt ein Überein- stimmungsfeld (Match Fields), einen Zähler (Counter) und Anweisungen (Instruc- tions). Eingehende Packets werden mit den Flow Entries beziehungsweise mit dem Flow Table verglichen. Bei einer Übereinstimmung (Match) wird das Packet anhand der Instruction im Flow Entry weitergeleitet. Die Counters werden ge- nutzt, um Statistiken über jedes Packet aufzuzeichnen. Das Packet kann aber auch genauso eingekapselt (encapsulated) und zum Controller gesendet wer- den.²⁸

Der Controller ist ein Softwareprogramm welches für die Steuerung und Manipulation der Flow Tables in einem OpenFlow fähigen Switch verantwortlich ist. Der Secure Channel verbindet den Controller mit allen Switches. Über diesen Channel verwaltet der Controller die Switches, empfängt Packets und sendet Packets zu den Switches. Abbildung 6 zeigt, wie ein OpenFlow fähiges Netzwerkgerät ein Packet verarbeitet. Vorausgesetzt, die Kommunikation zwischen Switch und Controller ist in den Flow Table Anweisungen definiert.²⁹

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: OpenFlow fähiges Netzwerkgerät³⁰

Ein Switch benutzt intern ein Ternary Content Adressable Memory (TCAM) und ein Random Access Memory (RAM), um Packets zu bearbeiten beziehungsweise weiterzuleiten.

Es liegen verschiedene Versionen des OpenFlow Protokolls vor. Die erste Version war die OpenFlow Version 0.2.0, welche im März 2008 veröffentlicht wurde. Version 0.8.2 wurde im Oktober 2008 veröffentlicht. Diese wurde um Echo Anforderung und Echo Antwort Mitteilungen erweitert. Im Dezember 2008 kam dann Version 0.8.9, die um IP Netzmasken und zusätzliche Statistikinformationen erweitert wurde. OpenFlow Version 0.9 wurde im Juli 2009 veröffentlicht. Im Dezember 2009 wurde die weitverbreitete Version 1.0 publiziert.³¹

Nachstehend wird ein Überblick über die OpenFlow Versionen 1.0 - 1.4 gege- ben.

2.4.1.1 OpenFlow Version 1.0.0

OpenFlow Version 1.0.0 unterstützt einen Flow Table, der aus den Header Fields, den Counters und den Instructions (Actions) besteht.³² Bei OpenFlow Version 1.0.0 werden die Übereinstimmungsfelder (Match Fields) als Header Fields bezeichnet. Version 1.0.0 besitzt 12 solche Header Fields.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: OpenFlow Version 1.0.0 Header Fields³³

Tabelle 1 zeigt die Header Fields, auf welche eingehende Packets verglichen werden. Jeder Eintrag beinhaltet einen speziellen Wert. Es ist auch möglich, ein ANY zu definieren, dies trifft dann auf alle Einträge im Packet zu. Falls der Switch Subnet Masks unterstützt, ist es möglich, diese Masks bei den Header Fields der IP Quelle und dem IP Ziel anzugeben.³⁴

Counters werden gewartet per-Table, per-Flow und per-Queue. Tabelle 2 zeigt, welche Counter definiert wurden und auf welche Bitlänge diese begrenzt sind.³⁵

Tabelle 2: Counters in OpenFlow 1.0.0³⁶

Abbildung in dieser Leseprobe nicht enthalten

Verschiedene Actions können per Flow gesetzt werden. Die wichtigste Action ist die forwarding Action. Diese Action kann ein Packet an ein bestimmtes oder an alle Ports weiterleiten. Zusätzlich kann der Controller dem Switch auch mitteilen, alle Packets einzukapseln und an den Controller zu senden. Eine Action, um die Packets zu verwerfen, ist ebenfalls möglich. Anhand dieser Actions ist es mög- lich, eine Netzwerkzugriffskontrolle mit OpenFlow zu etablieren beziehungsweise zu implementieren.³⁷

Es gibt zwei Arten von OpenFlow Switches. OpenFlow-only Switches und Open- Flow-enabled Switches. OpenFlow-only Switches unterstützen die REQUIRED Actions, wobei OpenFlow-enabled Switches, Routers und Access Points auch die NORMAL Actions unterstützen. Jede dieser beiden Arten kann auch die FLOOD Action unterstützen.³⁸

Required Action: Forward - Alle OpenFlow Switches müssen nachstehende Ac- tions unterstützen, um Packets an physikalische oder virtuelle Ports weiterzulei- ten.

- ALL: Sende das Packet an alle Ports, ausgenommen an das eingehende.
- CONTROLLER: Das Packet wird eingekapselt und an den Controller ge- sendet.
- LOCAL: Sende das Packet zum lokalen Netzwerkstack des Switches.
- TABLE: Führe die Action, welche im Flow Table hinterlegt ist, aus. Nur für ausgehende Packets.
- IN_PORT: Sende das Packet durch den EingangsPort hinaus. Optional Action: Forward
- NORMAL: Verarbeite das Packet anhand des traditionellen Weiterlei- tungspfades, der vom Switch unterstützt wird. Der Switch analysiert das Packet anhand der VLAN ID, ob er dieses Packet auf traditionellem Wege weiterleiten kann oder nicht. Falls es dem Switch nicht möglich ist, dieses Packet weiterzuleiten, muss er das Packet indizieren, dass die geforderte Action nicht unterstützt wird.

- FLOOD: Packet wird an alle Ports anhand des minimalen Spanning Trees weitergeleitet. Ausgenommen an den eingehenden Port.

Optional Action: Enqueue - Diese Action besagt, dass das Packet an einem be- stimmten Port in eine Warteschlange eingereiht werden soll. Die Weiterleitung ist abhängig von der Konfiguration der Warteschlange. Dies kann genutzt werden, um grundlegende QoS (Quality-of-Service) Funktionalitäten zu erhalten.

Required Action: Drop - Ein Flow Entry mit keiner spezifizierten Action gibt an, dass alle übereinstimmenden Packets verworfen werden sollen.

Optional Action: Modify-Field - Hier ist es möglich, Header Fields umzuschreiben. Tabelle 3 gibt einen Überblick über die Möglichkeiten.³⁹

Tabelle 3: Modify-Fields in OpenFlow 1.0.0⁴⁰

Abbildung in dieser Leseprobe nicht enthalten

Das OpenFlow Protokoll 1.0.0 unterstützt drei Arten von Nachrichten: Controller- to-Switch, Asynchron und Symmetrisch.⁴¹ Diese werden nachfolgend beschrie- ben.

Controller-to-Switch Nachrichten: Diese Nachrichten werden vom Controller initi- iert. Sie werden benutzt, um die Eigenschaften des Switches abzufragen, den Switch zu konfigurieren, Statistiken anzufordern und die Flow Table zu verwal- ten.⁴²

Asynchrone Nachrichten: Diese Nachrichten werden vom Switch initiiert. Sie die- nen dazu, den Controller über Fehlermeldungen, Netzwerkereignisse oder Sta- tusinformationen des Switches zu informieren. Weiters sendet der Switch Nach- richten an den Controller, welche ein Packet enthalten, für das kein Eintrag im Flow Table existiert. Solche Nachrichten werden als Packet-In bezeichnet. Der Controller muss jetzt entscheiden, wie das Packet verarbeitet wird, oder ob es verworfen wird.⁴³

Symmetrische Nachrichten: Diese Nachrichten, welche in drei Typen eingeteilt werden, können von beiden Seiten initiiert werden, welche.

- Hello: Hello-Nachrichten werden beim Aufbau einer Verbindung zwischen Controller und Switch ausgetauscht. Sie beinhalten die jeweils unterstütz- te Version des OpenFlow Protokolls.
- Echo: Echo-Nachrichten müssen mit einer Echo-Reply Nachricht beant- wortet werden. Diese Nachrichten können benutzt werden, um die Band- breite, Latenz oder Verfügbarkeit der Verbindungen abzurufen.
- Vendor: Vendor-Nachrichten werden für zukünftige OpenFlow Versionen bereit gestellt. Diese sollen den Zweck haben, zusätzliche OpenFlow Funktionalitäten innerhalb der Nachrichtentypen anzubieten.⁴⁴

2.4.1.2 OpenFlow Version 1.1.0

OpenFlow Version 1.1.0 (Februar 2011) unterstützt mehrere Flow Tables und einen Group Table, welche aus den Match Fields, den Counters und den Instructions bestehen. OpenFlow Version 1.1.0 besitzt 15 Match Fields.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: OpenFlow Version 1.1.0 Match Fields⁴⁵

Version 1.1.0 wird um 3 Match Fields erweitert. Das Feld Metadaten wird genutzt, um Informationen über den Matching Prozess von einem Flow Table zum anderen zu sammeln. Es ist also ein Feld, um Informationen von einem Table zum anderen zu transportieren. Die Multi Protokoll Label Switching (MPLS) Felder werden genutzt, um MPLS Erkennung zu etablieren.⁴⁶

Im Gegensatz zu Version 1.0.0 hat sich der Prozess des Vergleichens verändert, da in Version 1.1.0 mehrere Flow Tables im Einsatz sind. Die Flow Tables sind im Switch miteinander verbunden. Der Prozess, wenn ein Packet mehrere Flow Tables durchläuft, wird als pipeline processing bezeichnet (siehe Abbildung 7).⁴⁷

OpenFlow Version 1.1.0 Switches kommen in zwei Arten vor OpenFlow-only und OpenFlow-hybrid. OpenFlow-only Switches unterstützen ausschließlich OpenFlow Verarbeitung. Beide Switcharten verarbeiten die Packets anhand einer OpenFlow-pipeline.⁴⁸

OpenFlow-hybrid Switches unterstützen OpenFlow und normales EthernetSwit- ching, wie Layer 2 Switching, VLAN Isolation, Layer 3 routing oder Quality of Service. In einem OpenFlow-hybrid Switch besteht auch die Möglichkeit, Packets von einem OpenFlow Prozess zu einem normalen EthernetSwitching Prozess um- oder weiterzuleiten.⁴⁹

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: OpenFlow 1.1.0 pipeline processing⁵⁰

OpenFlow Version 1.1.0 besitzt auch einen Group Table. Ein Group Table be- steht aus Group Entries. Durch den Einsatz eines Group Table wird einem Flow ermöglicht, anhand seines Group Entries sich einer Group zuzuordnen, dies er- möglicht zusätzliche Weiterleitungsmethoden. Jeder Group Entry beinhaltet fol- gende Einträge:

- Group Identifier (32bit Zahl mit der die Group identifiziert wird)
- Group Type (Bestimmen der Semantik/Eigenschaften der Group)
- Counters (Zähler, wenn Packets durch eine Group verarbeitet werden)
- Action Buckets (Ein Set an Actions und zugehörigen ParaMetern in Groups)⁵¹

[...]

---

¹ Vgl. Ethan Banks, „SDN-Grundlagen: Zcntralc Kontrolle und Programmierbarkeit", 2014, 1, http://www.searchnetworking.de/ehandbook/eGuide-SDN-Grundlagen-Zentrale-Kontrolle-und-Programmierbarkeit.

² Vgl. Diego Kreutz u. a., „Software-Defined Networking: A Comprehensive Survey" (Cornell University Library, 2014), 1, http://arxiv.org/abs/1406.0440v3.

³ Vgl. Margarete Rouse, „SDN-Controller (Software-defined Networking Controller)" (www.searchnetworking.de, 2013), 1, http://www.searchnetworking.de/definition/SDN-Controller-Software-defined-Networking-Controller

⁴ Vgl. Banks, „SDN-Grundlagen: Zentrale Kontrolle und Programmierbarkeit", 3.

⁵ Vgl. Kreutz u. a., „Software-Defined Networking: A Comprehensive Survey“, 4.

⁶ Vgl. „Was ist Data Plane (DP, Datenebene, Datenschicht)? - Definition von WhatIs.com“, zugegrif- fen 16. Mai 2015, http://www.searchnetworking.de/definition/Data-Plane-DP-Datenebene-

⁷ Vgl. „Was ist Control Plane (CP, Kontrollebene, Kontrollschicht)? - Definition von WhatIs.com“, zugegriffen 16. Mai 2015, http://www.searchnetworking.de/definition/Control-Plane-CP- Kontrollebene-Kontrollschicht.

⁸ Vgl. „The Control Plane, Data Plane and Forwarding Plane in Networks“, zugegriffen 16. Mai 2015, http://networkstatic.net/the-control-Plane-Data-Plane-and-forwarding-Plane-in- networks/#!lightbox[2875] /2/.

⁹ Vgl. Kreutz u. a., „Software-Defined Networking: A Comprehensive Survey“, 3.

¹⁰ Vgl. „Was ist Data Plane (DP, Datenebene, Datenschicht)? - Definition von WhatIs.com“.

¹¹ Vgl. Rajesh Kumar Sundararajan, Software Defined Networking (SDN) - a Definitive Guide (English Edition), Kindle Edition (Amazon Media EU S.à r.l., o. J.), Kapitel 2.

¹² Vgl. Ebd.

¹³ Vgl. „Was ist SDN-Controller (Software-defined Networking Controller)? - Definition von Wha- tIs.com“, zugegriffen 16. Mai 2015, http://www.searchnetworking.de/definition/SDN-Controller- Software-defined-Networking-Controller.

¹⁴ „Traditional_to_SDN“, zugegriffen 17. Mai 2015, http://deliveryimages.acm.org/10.1145/2670000/2661063/figs/f1.jpg.

¹⁵ Vgl. Sundararajan, Software Defined Networking (SDN) - a Definitive Guide (English Edition), Kapitel 2.

¹⁶ Open Networking Foundation, „Software-Defined Networking: The New Norm for Networks“ (Open Networking Foundation, 13. April 2012), 7, https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn- newnorm.pdf.

¹⁷ Vgl. Wolfgang Braun und Michael Menth, „Software-Defined Networking Using OpenFlow: Protocols, Applications and Architectural Design Choices“, Future Internet 6, Nr. 2 (2014): 304, doi:10.3390/fi6020302.

¹⁸ Vgl. Open Networking Foundation, „Software-Defined Networking: The New Norm for Networks“, 8-11.

¹⁹ Ebd., 9.

²⁰ Vgl. Marc Mendonca u. a., „A Survey of software-defined networking: past, present, and future of programmable networks“, hal-00825087, 2013, 3, http://hal.inria.fr/hal-00825087/PDF/bare_jrnl.pdf.

²¹ Vgl. T.V. Lakshman u. a., „The SoftRouter Architecture“ (ACM Workshop on Hot Topics in Networks, San Diego, CA, 2004), 1.

²² Vgl. Braun und Menth, „Software-Defined Networking Using OpenFlow: Protocols, Applications and Architectural Design Choices“, 305.

²³ Vgl. N. Foster u. a., „Languages for software-defined networks“, Communications Magazine, IEEE 51, Nr. 2 (Februar 2013): 1-7.

²⁴ Vgl. Braun und Menth, „Software-Defined Networking Using OpenFlow: Protocols, Applications and Architectural Design Choices“, 305.

²⁵ Vgl. Open Networking Foundation, „Software-Defined Networking: The New Norm for Networks“, 1-10.

²⁶ Vgl. A. Lara, A. Kolasani, und B. Ramamurthy, „Network Innovation using OpenFlow: A Survey“, Communications Surveys & Tutorials, IEEE 16, Nr. 1 (First Quarter 2014): 495, doi:10.1109/SURV.2013.081313.00105.

²⁷ Vgl. Ebd.

²⁸ Vgl. Ebd.

²⁹ Vgl. Ebd.

³⁰ Vgl. Ebd., 496.

³¹ Vgl. Ebd.

³² Vgl. Open Networking Foundation, „OpenFlow Switch Specification Version 1.0.0“, 31. Dezem- ber 2009, 2, https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf- specifications/openFlow/openFlow-spec-v1.0.0.pdf.

³³ Vgl. Ebd., 3.

³⁴ Vgl. Ebd., 3-4.

³⁵ Vgl. Ebd., 3.

³⁶ Ebd., 5.

³⁷ Vgl. Braun und Menth, „Software-Defined Networking Using OpenFlow: Protocols, Applications and Architectural Design Choices“, 308.

³⁸ Vgl. Open Networking Foundation, „OpenFlow Switch Specification Version 1.0.0“, 6.

³⁹ Vgl. Ebd.

⁴⁰ Ebd., 5.

⁴¹ Vgl. Ebd., 10-11.

⁴² Vgl. Ebd., 10.

⁴³ Vgl. Ebd., 10-11.

⁴⁴ Vgl. Ebd., 11.

⁴⁵ Vgl. Open Networking Foundation, „OpenFlow Switch Specification Version 1.1.0“, 28. Novem- ber 2011, 8, https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf- specifications/openFlow/openFlow-spec-v1.1.0.pdf.

⁴⁶ Vgl. Lara, Kolasani, und Ramamurthy, „Network Innovation using OpenFlow: A Survey“, 496.

⁴⁷ Vgl. Ebd.

⁴⁸ Vgl. Open Networking Foundation, „OpenFlow Switch Specification Version 1.1.0“, 5.

⁴⁹ Vgl. Ebd.

⁵⁰ Vgl. Ebd., 6.

⁵¹ Vgl. Ebd., 7