Benchmarking von OpenFlow im Vergleich zu traditionellen Netzwerken

Bachelor Thesis , 2013 , 79 Pages , Grade: 1.0

Computer Science - Commercial Information Technology

Das Internet, wie wir es heute kennen, ist ein entscheidender Wirtschaftsfaktor und ein Motor für Entwicklungen sogar außerhalb der IT geworden. Das Geschäftsmodell vieler Firmen ist direkt von der Verfügbarkeit und Verbindungsqualität zum Internet hin abhängig. Eine von den Pionieren dieser Technologie nicht absehbare Entwicklung ist der aktuelle Trend zur Virtualisierung, welcher Einzug in fast allen Bereichen der IT gehalten hat und immer noch hält. Die Netzwerktechnologie, welcher in bisheriger, am Markt verfügbarer Virtualisierungssoftware meist nur eine Nebenrolle zukommt - zur Anbindung der VM - konnte diese Entwicklungen aufgrund ihrer dezentral gewachsenen Architektur bisher nur in sehr begrenztem Maße unterstützen. Als evolutionären Ansatz hat sich seit einiger Zeit OpenFlow etabliert, welcher neue Managementkonzepte in die existierenden Infrastrukturen integriert, ohne dabei radikale Änderungen an Hard- oder Software zu erfordern, was die Barriere der Einführung massiv verringert. Kunden bekommen die Unterstützung für den neuen Standard quasi als Nebenprodukt beim Kauf ihrer Standardhardware.
Ziel der Arbeit soll es sein, für ein Fachpublikum das von OpenFlow vorgestellte Konzept und dessen Umsetzung zu analysieren, es auf die heutzutage in der Netzwerkumgebung auftretenden Probleme zu projezieren und aus dem theoretischen Konzept hinter OpenFlow die zu erwartenden Abweichungen zu einem klassischen Netzwerkbenchmark abzuleiten. Anschließend soll ein Modell entwickelt werden, anhand dessen neu aufgebaute Infrastrukturen bewertet werden können. Ein konsolidierter Katalog zu den Bewertungskriterien soll einen Anhaltspunkt zur Netzwerkbewertung für implementierende Fachkräfte geben. Zudem soll anhand einer exemplarischen Implementierung die Wirksamkeit der Konzepte überprüft werden. Hierzu wird eine Testumgebung aufgebaut anhand derer zu definierende Tests durchgeführt werden. Aus denen in der Testumgebung gewonnenen Erkenntnissen sollen Schlüsse gezogen werden, die Aussichten und Einschränkungen von OpenFlow in der aktuellen Form bewerten. Limitierungen der Technologie werden zudem gesondert betrachtet und Einsatzbereiche daraus abgeleitet werden.
Die zentrale Fragestellung der Arbeit ist: "In wieweit unterscheidet sich das Benchmarking eines OpenFlow-Netzwerks von dem einer klassischen Netzwerkinfrastruktur?". Der Anhang liefert zudem einen detaillierten Testaufbau, um eigene mit denen in der Arbeit gewonnenen vergleichen zu können.

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung

2 Grundlagen
2.1 Benchmarking
2.2 Prototyping
2.3 Netzwerk
2.4 Klassische Netzinfrastruktur
2.5 Switching
2.6 Routing
2.7 Netzwerkvirtualisierung . .
2.7.1 VPN
2.7.2 VLAN
2.8 Software defined Networking
2.9 Softwarequalität
2.10 Relevante Software
2.10.1 dpctl
2.10.2 taskset
2.10.3 mininet

3 Analyse
3.1 OpenFlow
3.1.1 OpenFlow Konzept
3.1.2 Funktionsweise
3.1.3 Relevanz für die Industrie
3.1.4 Relevanz für die Forschung
3.1.5 Einschränkungen von OpenFlow . .
3.2 Vorüberlegungen zum Netzwerkaufbau . .
3.2.1 Einflussfaktoren
3.2.2 Netzwerkaufbau der Testumgebung
3.3 Benchmarking
3.3.1 Klassisches Netzwerk
3.3.2 OpenFlow Netzwerk
3.3.3 Konfiguration der Testumgebung .
3.3.4 Konfiguration der Controller
3.3.5 Limitation des Benchmarkings
3.3.6 Ergebnisse
3.4 Wirtschaftliche Faktoren

4 Fazit

Literatur

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

2.1 Aufbau eines klassischen Netzwerks

2.2 Aufbau von virtuellen Netzwerken

2.3 Grundkonzept von SDN und Einordnung von OpenFlow

3.1 Trennung der Planes

3.2 Aufbau und Positionierung von OpenFlow

3.3 Header Informationen zur Steuerung von OpenFlow

3.4 Schematischer Aufbau der Testumgebung

3.5 Zusammenspiel der Software für OpenFlow

3.6 Aufbau der physikalischen Netzwerkumgebung

3.7 POXdesk Netzdarstellung

3.8 Durchsatz von Beacon in Abhängigkeit der verfügbaren Threads im

Vergleich bei AWS

3.9 Durchsatz von Beacon in Abhängigkeit der verfügbaren Threads (phy-

sikalischer Server)

3.10 Durchsatz von Software-Flows gegenüber Hardware-Flows

3.11 Einfluss der Java VM auf den Durchsatz

3.12 Latenz der Controller bei der Übertragung des ersten Pakets nach x Sekunden bei reaktiven Flows

3.13 Latenz der Controller bei der Übertragung mittels praktiven Flows

3.1 Hardware der virtuellen Testumgebung

3.2 Genutzte AWS Instanzen

3.3 Kommandofolge zur Konfiguration eines Switches in der Testumgebung

3.4 OpenFlow Debugging Kommandos auf HP-Hardware

1 Einleitung

Das Internet, wie wir es heute kennen, ist ein entscheidender Wirtschaftsfaktor und ein Motor für Entwicklungen sogar außerhalb der Informationstechnologie (IT) geworden. Das Geschäftsmodell vieler Firmen ist direkt von der Verfügbarkeit und

Verbindungsqualität zum Internet hin abhängig. Diese Ausbaustufe und daraus hervorgehende Implikationen konnte von den Entwicklern und Pionieren, die die initialen Grundlagen dieses Netzwerkes entwickelt haben, nicht im Entferntesten vorausgesehen werden. So wurden Designentscheidungen, die in dieser Entwicklungs- phase vor 30 oder mehr Jahren unter Annahme völlig anderer Rahmenkriterien getroffen wurden, heutzutage in wachsendem Umfang zum Problem in Skalierung und Flexibilität¹. Internet Protocol (IP)-Adressierung etwa war initial nur für das Verbinden von 10-100 Hosts ausgelegt und entsprechend dimensioniert.² Eine dieser unvorhersehbaren Entwicklungen, welche in der urspünglichen Konzeption schon aufgrund des damaligen Stands der Technik keine Berücksichtigung finden konnte, ist der aktuelle Trend zur Virtualisierung, welcher Einzug in fast allen Be- reichen der IT gehalten hat und immer noch hält. So ist virtuelle Infrastruktur oder Infrastructure as a Service (IaaS) heutzutage schon fast eher die Regel als die Ausnahme im Firmennetzwerk. Die Zusammenlegung von Servern auf virtuelle Infrastruktur ist unabhängig von der darunterliegenden Hardware, es ist deutlich einfacher möglich, unterliegende Technologien anzupassen sowie Failover oder auch Load Balancing zu realisieren. Zusätzlich hat Virtualisierung diverse Kostenvorteile für niedrig ausgelastete Hardware, was speziell im Bereich IaaS viel Einsparpotential bietet. Die Netzwerktechnologie, welcher in bisheriger, am Markt verfügbarer Virtua- lisierungssoftware meist nur eine Nebenrolle zukommt - zur Anbindung der Virtual Machines (VMs) - konnte diese Entwicklungen aufgrund ihrer dezentral gewachsenen Architektur bisher nur in sehr begrenztem Maße unterstützen.

Auch sind neue Technologien im Maßstab des Internets für Entwickler im akade- mischen Umfeld sehr schwer zu realisieren, zu testen und zu verbreiten, da eine kritische Masse von Unterstützern erreicht werden muss, die einen neuen Standard unterstützen, umsetzen und gegebenenfalls Produkte am Markt platzieren. Ein wei- terer Faktor ist es dann, dem Kunden den Mehrwert exakt dieses neuen Standards als Kaufargument zu vermitteln.

Die Einschränkungen des Internets lassen sich jedoch in der aktuellen Situation ohne die Unterstützung der verwendenden und implementierenden Unternehmen nicht lösen, denn sie sind begründet in den bereits angesprochenen Grundproblemen, die nicht ohne Anpassungen größeren Umfangs an der Internet-Architektur gelöst werden können.

Zeitgleich werden IP-basierte Netzwerke in der Realität immer größer, verteilter, komplexer und diversifizierter und stellen dabei im selben Maß verteilte und kom- plexe Services und Anwendungen zur Verfügung. Daraus resultiert eine höhere Fehleranfälligkeit und eine größere Anzahl von Fehlerquellen. Auch kommen laufend neue Bedrohungen für die Infrastruktur aufgrund ihrer Komplexität hinzu, die abgedeckt werden müssen.³

Zur Lösung der Limitierungen gibt es konkurrierende Herangehensweisen: den Clean-Slate“- und den evolutionären Ansatz. Während der Clean-Slate-Ansatz das ” Ziel hat, die Limitierungen der Architektur des Internets durch einen radikalen Neuanfang und damit einhergehend durch eine komplette Neustrukturierung zu lösen, verfolgt das evolutionäre Modell das Ziel, bestehende Infrastrukturen so zu erweitern, dass sie die zukünftigen Anforderungen besser abdecken können. Clean-Slate Ansätze haben zudem sehr große Probleme, die kritische Masse der Unterstützer zu erreichen.

Als einer der erwähnten evolutionären Ansätze hat sich seit einiger Zeit OpenFlow etabliert, welcher neue Managementkonzepte in die existierenden Infrastrukturen integriert, ohne dabei radikale Änderungen an Hard- oder Software zu erfordern, was die Barriere der Einführung massiv verringert. Kunden bekommen die Unterstützung für den neuen Standard quasi als Nebenprodukt beim Kauf ihrer Standardhardware. Ziel der Arbeit soll es sein, für ein Fachpublikum das von OpenFlow vorgestellte Kon- zept und dessen Umsetzung zu analysieren, es auf die heutzutage in der Netzwerkum- gebung auftretenden Probleme zu projezieren und aus dem theoretischen Konzept hinter OpenFlow die zu erwartenden Abweichungen zu einem klassischen Netzwerk- benchmark abzuleiten. Anschließend soll ein Modell entwickelt werden, anhand dessen neu aufgebaute Infrastrukturen bewertet werden können. Ein konsolidierter Katalog zu den Bewertungskriterien soll einen Anhaltspunkt zur Netzwerkbewertung für implementierende Fachkräfte geben. Zudem soll anhand einer exemplarischen Implementierung die Wirksamkeit der Konzepte überprüft werden. Hierzu wird eine Testumgebung aufgebaut anhand derer zu definierende Tests durchgeführt werden.

Aus denen in der Testumgebung gewonnenen Erkenntnissen sollen Schlüsse gezogen werden, die Aussichten und Einschränkungen von OpenFlow in der aktuellen Form bewerten. Limitierungen der Technologie werden zudem gesondert betrachtet und Einsatzbereiche daraus abgeleitet werden. Dem Leser soll anhand eines detailliert dokumentierten Testaufbaus ermöglicht werden, eigene Tests mit veränderten Kom- ponenten durchzuführen und diese mit den im Rahmen dieser Arbeit gewonnenen Erkenntnisse zu vergleichen. Zielgruppe der Arbeit sind folglich implementierende Fachkräfte und fachkundige Entscheidungsträger des unteren Managements, die Implementierungsdetails erfahren und eigene Tests durchführen lassen möchten sowie Personen, die ihre Software defined Networking (SDN)-Kenntnisse auf OpenFlow erweitern möchten. Daraus ergibt sich die zentrale Fragestellung der Arbeit: In wieweit unterscheidet sich das Benchmarking eines OpenFlow-Netzwerks von dem einer klassischen Netz- werkinfrastruktur? Abschließend wird ein Fazit zu den gewonnenen Erkenntnissen sowie eventuell exis- tierenden Einschränkungen des Einsatzes und der Weiterentwcklung von OpenFlow gezogen. Ein Ausblick auf die mögliche zukünftige Entwicklung der Technologie soll abschließend eine Einschätzung des Potentials von OpenFlow ermöglichen und die Unterschiede beim Benchmarking einer OpenFlow-basierenden Infrastruktur im Vergleich zu einer klassischen Netzwerkinfrastruktur hervorheben.

2 Grundlagen

Für die Bewertung der Netzwerktechnologie muss zunächst definiert werden, was unter einer solchen verstanden wird, welche Technologien aktuell eingesetzt werden und welche Einschränkungen diese mitbringen. So soll geklärt werden, was die Grundlage für die Gegenüberstellung der Arbeit ist - sprich - was ist ein klassisches Netzwerk und wie wird ein solches heutzutage bewertet.

2.1 Benchmarking

Als Benchmarking wird im Netzwerkbereich die Performancebewertung einer Netz- werkinfrastruktur definiert. Hierbei werden verschiedenste Messgrößen eingesetzt und bewertet. Im Folgenden eine Analyse klassischer Einflussfaktoren:

- Datendurchsatz - Die Menge der Daten, die über das Netzwerk übertragen werden können, innerhalb eines definierten Zeitraums. Der Datendurchsatz kann auf verschiedenen Wegen gesehen werden:

- End-to-End Capacity - Bewertung der Kapazität der Leitung anhand der Differenz der Roundtrip Time (RTT) zu zwei benachbarten Routern.
- Available Bandwidth - Bewertung der Kapazität anhand eines Daten- streams mit ansteigender Kapazität - sobald Daten verzögert oder verloren werden, ist die Kapazität gefunden

- Transmission Control Protocol (TCP) Throughput - Bewertung der Kapazität der Leitung anhand von gesendeten Bytes und der Zeit, die für die Übertragung vergangen ist.⁴

- Latenz - Die messbare Zeit, die vom Versenden einer Nachricht bis zu Empfang und Verarbeitung vergeht.
- Mean RTT - Das durchschnittliche Interval, das zwischen dem Versenden eines Paketes und dem Erhalt einer Rückantwort vergeht.⁵

2.2 Prototyping

Prototyping bezeichnet ein Vorgehensmodell bei der Erstellung einer Leistung. In der Softwareentwicklung werden Prototyping-orientierte Prozessmodelle dazu verwendet, die Anforderungen von Kunden schrittweise in Zusammenarbeit zu erarbeiten. Die jeweils realisierte Prototypen müssen dabei lauffähig sein.⁶ Für die Umsetzbarkeit von Prototyping werden verschiedene Faktoren definiert:

- Flexibilität - Neue Topologien und Funktionalitäten sollen sich in der Software definieren lassen.
- Implementierbarkeit Das Ausrollen der simulierten Lösung soll sich ohne Codeänderungen auf reele Hardware portieren lassen.
- Interaktivität - Der Test soll in Echtzeit geschehen, als wenn mit einem realen Netzwerk interagiert wird.
- Skalierbarkeit - Die Skalierbarkeit der Lösung soll von einem einzigen Gerät bis zu hunderten oder tausenden von Geräten gewährleistet sein.
- Realitätsbezug - Die Testumgebung soll mit einer hohen Wahrscheinlichkeit ein realisitisches Bild des Verhaltens der schlussendlichen Anwendung liefern.
- Verteilbarkeit - Die Testumgebung soll so konstruiert sein, dass sie Anderen einfach zur Verfügung gestellt werden kann, so dass diese ihre eigenen Tests in der Umgebung laufen lassen können.⁷

2.3 Netzwerk

Der Begriff des Netzwerkes, kann in der Fachliteratur wissenschaftlich nicht eindeutig und allumfassend beschrieben werden, Liotta und Exarchakos wagen mit ”Netzwerke

[..] sind komplexe Systeme, in denen eine Vielzahl von Aktionen und Antworten stattfinden”⁸ den Versuch einer generellen Beschreibung.

In der IT wird eine Struktur aus Hosts oder Endgeräten, die durch Kommunikations- schnittstellen und Packet Switches miteinander verbunden ist⁹, als Computernetzwerk bezeichnet. Das Internet ist ein Computernetzwerk, welches eine immer weiter stei- gende Zahl von Hosts oder Endgeräten verbindet. Computernetzwerke, wie wir sie heute kennen, sind in dieser Form schon sehr lange im Einsatz - sie basieren auf Entscheidungen, die vor bis zu 30 Jahren getroffen wurden und haben entsprechende Schwächen und Einschränkungen¹⁰. Eine dieser Einschänkungen ist die Schwierigkeit von Änderungen an der Kernarchitektur - die letzte tiefgreifende Änderung an der

Architektur des Internets was die Abschaltung des National Science Foundation Network (NSFNET) im Jahre 1995¹¹. Zusätzlich diktieren Hersteller aktuell mit ihren Geräten und proprietären Protokollen bereits die Infrastruktur, die Sicherheit, das Routing sowie die Energieverwaltung gesamter Netzwerke und kreieren so eine künstliche Bindung an die Geräte eines einzelnen Herstellers.¹².

2.4 Klassische Netzinfrastruktur

Klassische Netzwerkgeräte basieren auf den Netzwerkstrukturen, wie sie bereits seit Jahren weitgehend im Gebrauch sind. Zu nennen sind hierbei Hubs, Switches und Router, die jeweils spezifische Aufgaben erfüllen. Diese Geräte sind hauptsächlich basierend auf application-specific integrated circuits (ASICs) implementiert, damit sie große Bandbreiten im Bereich bis 600Gigabit/second (Gb/s)¹³ (aktueller Stand) verarbeiten können.

Klassische Netzwerke setzen, wie in Abbildung 2.1 gezeigt, häufig auf baumähnliche Strukturen, bei denen es üblicherweise drei grobe Ebenen gibt - das Core-Network, das Aggregation-Network und das Access-Network. Hierbei bildet sich eine pyra- midenartige Struktur - im Core und Aggregation Netzwerk werden in größeren Netzwerken üblicherweise leistungsfähigere Geräte eingesetzt als im Access Network. Diese Geräte bieten zusätzlich zu ihren Open Systems Interconnect (OSI)-Layer zwei Funktionen Funktionalitäten der OSI-Layer drei und vier.¹⁴

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Aufbau eines klassischen Netzwerks¹⁵

2.5 Switching

Im Local Area Network (LAN) werden Netzwerk-Endgeräte heutzutage klassischerweise über Switche verbunden - ein Switch ist nichts anderes als eine Multiport-Bridge¹⁶, welche aufgrund einer Tabelle Entscheidungen darüber trifft, über welchen physikalischen Port eingehende Nachrichten weitergeleitet werden.¹⁷ Dabei wird das Netzwerk pro Port in Kollisionsdomänen, aufgeteilt.¹⁸ Hardwareseitig haben klassische Switche (wie auch die meisten anderen Netzwerkgeräte) eine Zweiteilung der Logik: ein Management-Central Processing Unit (CPU) ( ”schlauaberlangsam“) und ein Forwarding-ASIC ( ”dummaberschnell“).¹⁹ SwitchingbasiertaufderSi- cherungsschicht des OSI-Modells und adressiert dabei üblicherweise über Medium Access Control (MAC)-Adressen. Es existieren auch Geräte, die Funktionalitäten der Vermittlungs- oder Transportschicht bieten und dann als ”Layer-3-“bzw ”Layer-4 Switch“ bezeichnet werden - das klassische Switching beschränkt sich jedoch auf die Sicherungsschicht. Ein geswitchtes Netzwerk wird häufig auch mit Autonomous System (AS) bezeichnet.

2.6 Routing

Routing ist eine Funktion der Vermittlungsschicht im OSI-Modell - die Funktion reali- siert IP-netzübergreifende Kommunikation, indem sie Entscheidungen zur Verteilung von Paketen aufgrund von Routing-Logik trifft. Diese Logik - also die Verknüpfung von Zieladressen mit einem ”Next-Hop“-wirdalsForwardingInformationBase(FIB) bezeichnet²⁰. Routing wird häufig als der Beschleuniger der Netzwerkinnovation gesehen - denn im Gegensatz zur reinen LAN Kommunikation ist es durch Routing möglich, über ein einzelnes IP-Netzwerk hinaus zu kommunizieren. Routing verbindet dabei mehrere ASs miteinander.

Es ermöglicht also erst die Entwicklung des Internet, wie es heutzutage existiert, denn auch das Internet, wie wir es kennen und nutzen, ist nichts anderes als die Verbindung von vielen ASs zu einem Ganzen²¹. Intelligenz in Routing-Geräten wird häufig durch standardisierte Technologien und Protokolle, etwa Open Shortest Path First (OSPF) oder Interior Gateway Routing Protocol (IGRP) implementiert²², wobei sich hier oft Inkonsistenzen in der Kommunikation und den verwendeten Technologien über mehrere AS hinweg ergeben.²³

Wiederherstellung nach einem Fehler (beispielsweise Ausfall einer Route) wird im Routing über im OSI-Modell höherliegende Technologien wie etwa TCP realisiert - hierbei werden Timer genutzt, innerhalb deren der Sender eine Rückinformation des Empfängers erwartet.²⁴

2.7 Netzwerkvirtualisierung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Aufbau von virtuellen Netzwerken²⁵

Netzwerkvirtualisierung hat zum Ziel, sogenannte virtuelle Netzwerkinfrastruktu- ren als Abstraktion einer physikalischen Infrastruktur anzubieten. Netzwerkgeräte haben hierbei mindestens zwei virtualisierbare Ebenen: die Control plane, welche die Entscheidungen zum Paketfluss aufgrund der vorhandenen Informationen trifft, und die Forwarding Plane, die aufgrund der auf der Control Plane definierten Re- geln die Pakete tatsächlich weiterleitet.²⁶ Dabei können Erfordernisse verschiedener Benutzergruppen optimal berücksichtigt werden,²⁷ zudem können virtualisierte In- frastrukturen explizit einem Service, einer Aufgabe oder einer Gruppe zugeordnet werden²⁸.

OpenFlow stellt eine solche Abstraktion über die Implementierung von virtueller Infrastruktur über der physikalischen Infrastruktur zur Verfügung. Die Anzahl der unterschiedlichen virtuellen Infrastrukturen ist dabei nicht beschränkt. Wie in der Abbildung 2.2 ersichtlich, kann das virtuelle Netzwerk aus einer beliebigen Anzahl von abstrahierten virtuellen Knoten bestehen. Virtuelle Knoten haben dabei nicht zwingend einen direkten Bezug zu einem physikalischen Knoten, sondern können sich bereits aus anderen virtuellen Netzwerkstrukturen ableiten. Über diese Abstrak- tionsebene kann jedem der Serviceprovider ein auf seine Bedürfnisse zugeschnittenes Netzwerk geboten werden.²⁹ Zusätzlich kann so eine Isolierung der Paketflüsse von- einander garantiert werden, so dass in den Netzen konkurrierende Technologien zum Einsatz kommen können (etwa IP Alternativen) und diese sich unter norma- len Umständen nicht stören können.³⁰ Aus Sicht des Kunden wird ihm nur sein eigenes Netzwerk präsentiert - was eine Abstraktion des tatsächlich unterliegenden Netzwerks darstellt. Netzwerkvirtualisierung kann also zusätzlich zur Reduzierung der Komplexität der Infrastruktur aus Kundensicht beitragen. Im Rahmen von Cloud Computing wird Netzwerkvirtualisierung allgemein häufig mit dem Akronym Network as a Service (NaaS) belegt, was sich in die Dreiteilung IaaS, Platform as a Service (PaaS) und Software as a Service (SaaS) einfügt und als Grundlage dieser fungieren kann.³¹

2.7.1 VPN

Auch Virtual Private Network (VPN) ist bereits eine Technologie, die Netzwerke virtualisiert - auf die Struktur der vorhandenen physikalischen Strukturen wird eine weitere, virtuelle Struktur aufgesetzt, welche die Strukturen netzübergreifend verbindet. Der Begriff ”Private“ bezieht sich dabei auf die Sicht barkeit des Netzwerks - ein VPN kann von anderen Teilnehmern desselben physikalischen Netzwerks nicht gesehen werden. VPNs nutzen üblicherweise verschlüsselte Verbindungen und Authen- tifizierungen über Zertifikate, etwa auf Basis von Internet Protocol Security (IPSec) oder Transport Layer Security (TLS)/Secure Sockets Layer (SSL). Das Netzwerk, durch welches hindurch verbunden wird, muss dabei nicht sicher sein (etwa das Internet) - auch über unsichere Wireless Local Area Network (WLAN) Verbindungen, die etwa über Wired Equivalent Privacy (WEP) gesichert sind, kann problemlos ein VPN aufgebaut werden, ohne dass die über das VPN übertragenen Daten gefährdet werden.³²

2.7.2 VLAN

Ein Virtual Local Area Network (VLAN) ist strukturell grundsätzlich nichts ande- res als ein klassiches LAN, es stellt weiterhin eine Broadcast-Domäne dar. VLANs ermöglichen es aber, im Gegenteil zu LANs, die Entscheidung der Zuordnung zu einem spezifischen VLAN portbasierend oder anhang von ”Tags“ im Paketheaderzu treffen und so ein VLAN aus mehreren LANs zu bilden. Die portbasierte Verbindung von Netzwerken wird auch über Tags wird als ”untagged“ VLAN genannt, die logische Verschaltung ”tagged“ VLAN bezeichnet.³³

Die zu verbindenden Netze müssen dabei über Routing-Technologien miteinander verbunden sein. Historisch haben sich VLANs aus dem Fakt entwickelt, dass Ent- scheidungen aufgrund des Ethernet Headers günstiger zu implementieren waren als Entscheidungen auf Basis des IP-Headers - dieses Manko ist heute so nicht mehr existent. VLANs decken im heutigen Einsatz Probleme des proportionalen Wachs- tums von Broadcasttraffic in großen Netzen ab.³⁴ So ist es möglich, Datenverkehr aufgrund von Anpassungen in der sendenden Applikation zu kategorisieren und so zu unterteilen - dies geschieht meist über die VLAN-Identifikationsnummer (ID). Die Hauptgrund für der Grenzen dieser Technologie ist die bereits erwähnte Abhängigkeit von der Endanwendung. Zusätzlich ist die Anzahl der VLANs aufgrund der Feldlänge auf 4096 Einträge (12 Bits) begrenzt. Lösungsansätze zu diesem spezifischen Pro- blem, etwa IEEE802.1ad (Stacked VLANs) oder IEEE802.1ah (Provider Backbone Bridges (PBB))³⁵ sollen im Rahmen dieser Arbeit keine weitere Rolle spielen, da sie für ein Benchmarking keine bekannten Auswirkungen haben. Zusätzlich können netzübergreifend VLAN-Tags mehrfach genutzt werden, was ein zentrales Mana- gement der verfügbaren VLAN-IDs schwierig macht. VLAN-Technologie lässt sich in den meisten Fällen problemlos in Kombination mit OpenFlow kombinieren - OpenFlow kann etwa Entscheidungen aufgrund der VLAN-ID treffen und Traffic entsprechend weiterleiten. VLANs basieren auf den Schichten zwei und drei des OSI-Modells mittels LAN-Switching und/oder virtuellen Routing.³⁶

2.8 Software defined Networking

Ziel von SDN ist es, Control- und Forwarding-Plane zu trennen und getrennt zu implementieren. Damit stellt es einen fundamental unterschiedlichen Ansatz zu der bisher stark an Anbieter und physikalisches Produkt gebundenen Implementierung der beiden Ebenen dar.³⁷. In der Grafik 2.3 sichtbar ist diese Trennung, wobei auf der Infrastruktur eine Kontrollschicht eingesetzt wird, welche die Vermittlung zwischen Anwendungen oberhalb dieser Kontrollschicht und der darunterliegenden Infrastrukturschicht vornimmt. OpenFlow ist dabei ein Kommunikationsprotokoll zwischen der Kontrollschicht und der Infrastrukturschicht - in der Literatur wird dies aufgrund der Anordnung in einer Struktur auch als Programming Interface (API)“ bezeichnet. Das Grundprinzip von SDN ist eine

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Grundkonzept von SDN und Einordnung von OpenFlow³⁸

Abstraktion der physikalischen Hardware, um darauf aufsetzend beliebige Strukturen zu realisieren. Die genaue Trennung und Relation zwischen OpenFlow und SDN ist in der Literatur oft fließend - es lässt sich die Abgrenzung ”Open Flow is a technical- to-technical service [..] By contrast, SDN is a business-to-technology interface.“³⁹ finden, welche die jeweiligen Enden der Technologie in den Vordergrund stellt. Im Rahmen der Arbeit wird OpenFlow als eine Ausprägung von SDN gewertet. Als solche stellt OpenFlow in der Relation zu SDN eine Spezialisierung dar.

2.9 Softwarequalität

Da an SDN und OpenFlow in zentralen Punkten Software beteiligt ist, hat diese einen erheblichen Beitrag zum Gesamtsystem - als solche ist auch die Softwarequalität ent- scheidend. Diese beurteilt, inwieweit eine Software generelle Benutzeranforderungen erfüllen kann. Softwarequalität ist International Organization for Standardizati- on (ISO)/International Electrotechnical Commission (IEC) 25010 definiert⁴⁰, welche folgende Bestandteile besitzt:

- Effectiveness
- Efficiency
- Satisfaction
- Usefulness
- Trust oder Satisfaction with Security
- Pleasure (emotional Satisfaction)
- Comfort (physical Satisfaction)
- Freedom from Risk
- Economic risk mitigation
- Health and safety risk mitigation
- Environmental risk mitigation
- Context Coverage
- Context completeness
- Flexibility

Im Rahmen der Arbeit soll auch untersucht werden, welchen Einfluss Softwarequalität auf das Benchmarking eines OpenFlow-Systems haben kann und an welchen Punkten die Beachtung der genannten Kriterien von Belang ist.

2.10 Relevante Software

Außerhalb der direkt an OpenFlow beteiligten Software und der verwendeten Benchmarking-software gibt es noch einige weitere, die hauptsächlich für die Kontrolle und das Umsetzen des Benchmarks sowie der Kontrolle des OpenFlow-Controllers Werkzeuge zur Verfügung stellen - diese soll im folgenden Kapitel vorgestellt wer- den.

2.10.1 dpctl

Datapath Control (dpctl) gibt dem Benutzer die Kontrolle über OpenFlow Flowta- bles mittels einer Command Line Interface (CLI). dpctl kann Flows anlegen, diese modifizieren und löschen. Hierzu stehen Kommandos sowohl zur Verwaltung von Flows als auch für das Monitoring zur Verfügung. Die Syntax ist identisch mit dem Programm Open vSwitch Data Path Control (ovs-dpctl), welches speziell für Open vSwitch als Kontrollprogramm agiert.

2.10.2 taskset

Taskset ist ein weiteres Programm, welches im Rahmen eines Benchmarks die Umge- bung stabilisiert - über taskset können Prozesse auf bestimmte Prozessoren/Threads beschränkt werden. Taskset ist bei der im Rahmen der Arbeit hautpsächlich verwen- deten Distribution Ubuntu im vorinstallierten util-linux Paket.

2.10.3 mininet

Mininet ist ein Programm, das virtualisierte Netzwerke parametrisiert, von der Linux is not Unix (Linux)-Commandline aus erzeugen und aufrufen kann. Das Programm bietet ein CLI, von welchem aus die virtualisierten Geräte konfiguriert und geprüft werden können.⁴¹ Mininet bietet Möglichkeiten zur Virtualisierung von Hosts, Netzwerkgeräten und Controllern, soweit erforderlich.⁴² Zusätzlich zur reinen Virtualisierung bietet mininet bereits weitere Tools zum integrierten Testen der virtualisierten Infrastruktur mittels bekannter Netzwerkbenchmarkingwerkzeuge - etwa ping oder iperf.⁴³ Durch ein modulares Konzept kann mininet mit verschie- densten verfügbaren Controllern und virtualisierten Switchen kombiniert werden - es ist folglich problemlos möglich, OpenFlow Controller mit mininet zu kombinieren.

Die Benchmarkingergebnisse unterliegen den üblichen Beschränkungen virtualisierter Tests - etwa den Abweichungen der virtualisierten von realen Inhalten, die über die Leitungen transferiert werden. Zusätzlich wird die Skalierung durch die Performance des Guest-Systems limitiert.

Mininet wird für die weitere Entwicklung von SDN immer wieder als entscheidender Faktor genannt, denn es bietet die Möglichkeit, in sich abgeschlossene Netzwerke, die beispielsweise über OpenFlow implementiert sind, an andere weiterzugeben, testen zu lassen und diese weiter zu entwickeln.⁴⁴ Ebenso können neue Ideen sehr schnell in einer isolierten Umgebung getestet werden, im Extremfall direkt auf der Entwickler- workstation - so kann ein effektives Rapid Prototyping realisiert werden.⁴⁵

3 Analyse

Auf Basis der geschaffenen Grundlagen soll nun das im OpenFlow Standard verankerte Modell vorgestellt werden - zudem soll speziell darauf eingegangen werden, welche Punkte direkten Einfluss auf einen Benchmark haben und welche Besonderheiten sich ergeben. Anschließend soll das OpenFlow-Konzept anhand ausgewählter Software in einer Testumgebung implementiert werden und damit eine Umsetzbarkeit belegen.

3.1 OpenFlow

Die ursprüngliche Idee des Entwicklerteams um OpenFlow war die Möglichkeit der Schaffung einer Testplattform für Entwickler, um neue Konzepte und Ideen im Netzwerksektor in einer größeren Skalierung zu testen.⁴⁶ Dies war nach Ansicht des Entwicklerteams nötig geworden, nachdem die aktuellen Strukturen des Internets auf Designentscheidungen basieren, die vor 30 Jahren oder mehr getroffen wurden und als solche die aktuellen Entwicklungen nicht berücksichtigen konnten.⁴⁷ In den letzten Jahren allerdings hat OpenFlow sich dahingehend weiterentwickelt, dass auch Unternehmen immer mehr dazu übergehen, OpenFlow aufgrund der im Forschungseinsatz bewiesenen Vorteile in ihren Datacentern einzusetzen. Ein Beispiel hierzu ist Google, die als Pioniere ihren Datacenter-Backbone mit OpenFlow erweitert haben um eine bessere Flusskontrolle und Fehlerkorrektur realisieren zu können.⁴⁸

[...]

---

¹ Mähönen u. a. 2006, Vgl. S.1.

² Ebd., Vgl. S.4.

³ Shaikh und Greenberg 2005, Vgl. S.4ff.

⁴ Botta, Pescap und Ventre 2005, Vgl. S.1ff.

⁵ Jarschel u. a. 2012, Vgl. S.51.

⁶ Pree 2004, Vgl. S.26ff.

⁷ Lantz, Heller und McKeown 2010, Vgl. S.1.

⁸ Liotta und Exarchakos 2011, S.15.

⁹ Kurose und Ross 2007, Vgl. S.4.

¹⁰ Mähönen u. a. 2006, Vgl. S.1.

¹¹ ”NSFNET:APartnershipforHigh-SpeedNetworking-FinalReport“,Vgl.S.⁴¹.

¹² Green 2009, Vgl. S.54.

¹³ BCM88130 - High Performance Paket Switch Fabric, Vgl. S.1.

¹⁴ Moreno und Reddy 2006, Vgl. S.131.

¹⁵ Nach: Davy und Brar 2012

¹⁶ Seifert 2000, Vgl. S.149.

¹⁷ Ebd., Vgl. S.302.

¹⁸ Ebd., Vgl. S.151.

¹⁹ Shenker 2011, Vgl. S.26.

²⁰ Menth u. a. 2008, Vgl. S.359ff.

²¹ Menth u. a. 2008, Vgl. S.359ff.

²² Wood 2005, Vgl. Chapter 2.3.

²³ Menth u. a. 2008, Vgl. S.359ff.

²⁴ Wood 2005, Vgl. Chapter 2.4.

²⁵ Nach: (Chowdhury und Boutaba 2009)

²⁶ Moreno und Reddy 2006, Vgl. S.41.

²⁷ Ebd., Vgl. S.5.

²⁸ Ebd., Vgl. S.65.

²⁹ Chowdhury und Boutaba 2009, Vgl. S.2ff.

³⁰ Moreno und Reddy 2006, Vgl. S.55.

³¹ FG Cloud Computing 2012, Vgl. S.3.

³² Becker 2008, Vgl. S.18ff.

³³ Meinel und Sack 2011, Vgl. S.275f.

³⁴ Perlman 2000, Vgl. S. 171ff.

³⁵ Yamasaki u. a. 2011, Vgl. S.348.

³⁶ Borowka 1999, Vgl. S.501.

³⁷ Open Networking Foundation 2012, Vgl. S.7. ”Southbound-Application

³⁸ Nach: Open Networking Foundation 2012

³⁹ Greg Ferro 2012.

⁴⁰ ISO/IEC 2012, Vgl. S.8ff.

⁴¹ Lantz u. a. 2012b.

⁴² Lantz u. a. 2012a.

⁴³ Lantz u. a. 2012c.

⁴⁴ Lantz, Heller und McKeown 2010, Vgl. S.2f.

⁴⁵ Ebd., Vgl. S.1f.

⁴⁶ Vgl. McKeown u. a. 2008, S.1.

⁴⁷ Vgl. Green 2009, S.54.

⁴⁸ Vgl. Hoelzle 2012, S.7ff.

• College: University of applied sciences, Neuss
• Grade: 1.0
• Author: Ralf Leichter (Author)
• Publication Year: 2013
• Pages: 79
• Catalog Number: V231360
• ISBN (eBook): 9783656475118
• ISBN (Book): 9783656475187
• Language: German
• Tags: benchmarking, openflow, vergleich, netzwerken