Kampf um die Kontrolle

Im Gegensatz zu bislang genutzten Netzwerk- und Switching-Architekturen weist Software Defined Networking (SDN) einige Besonderheiten auf. Ein Kernelement ist die Trennung der Control Plane von der Data Plane beziehungsweise (Forwarding Plane) auf Layer 2 und 3 von Switches und Routern. Das heißt: Kontroll- und Datenpfad werden separiert. Die Control Plane ist für die Konfiguration eines Switches beziehungsweise Routers zuständig, außerdem für das Programmieren der Pfade, die für den Transport der Daten genutzt werden. Das heißt: Die Control Plane wird bei SDN aus den Switches heraus genommen und in ein separates System ausgelagert, den SDN-Controller.

Ein Vorteil des Konzeptes besteht darin, das der SDN-Controller nicht an eine bestimmte Form gebunden ist. Es kann sich um einen physischen Server handeln, aber auch um eine Virtual Machine oder eine Hardware-Appliance. Etliche Hersteller von SDN-Controllern setzen auf solche Appliances, die mit Standard-Sever-Prozessoren bestückt sind.

Der Controller gibt der Forwarding Plane vor, wie diese mit Datenpaketen umgehen soll, also wohin, sprich an welchen Netzwerk-Port, die Pakete übermittelt werden sollen und mit welcher Priorität das erfolgen muss. Auf diese Weise kann der IT-Administrator beispielsweise festlegen, dass Daten mit hoher Priorität, wie zeitsensitive Video- oder Voice-over-IP-Informationen oder OLTP-Daten (Online Transaction Processing), Vorrang vor E-Mails erhalten.

OpenFlow derzeit noch De-facto-Standard

Die Forwarding Plane übermittelt diese Regeln wiederum an die applikationsspezifischen ICs (ASICs) im Router oder Switch. Vereinfacht gesagt: SDN separiert Entscheidungen, welche den Weitertransport von Paketen und Regeln (Policies) betreffen, von der Netzwerktopologie und der Transportebene. Die Kommunikation zwischen Controller und Infrastrukturebene (Data / Forwarding Plane) erfolgt über ein spezielles Protokoll. Hier kommt derzeit vor allem OpenFlow zum Einsatz, das an der Stanford University in Kalifornien entwickelt wurde.

Für die Anbindung der Anwendungen sind standardisierte Application Programming Interfaces (APIs) zuständig. Derzeit favorisieren etliche Netzwerkhersteller OpenFlow, darunter HP, NEC und IBM. Allerdings gibt es auch andere Ansätze, beispielsweise PCE (Path Computation Elements), das speziell für SDN in Weitverkehrsnetzen entwickelt wurde.

Die Switches und Router in einer SDN-Infrastruktur müssen das Protokoll "verstehen", das der SDN-Controller verwendet, also beispielsweise OpenFlow. Das bedeutet im Extremfall den Austausch von älteren Systemen gegen neue Komponenten, die über entsprechende Schnittstellen verfügen. Die meisten Anbieter von Netzwerkausrüstung für Enterprise Networks und Telekommunikationsnetzen rüsten derzeit ihre Systeme mit entsprechenden Interfaces aus.

Software Defined Networks
Die Flow-Tabelle steuert den Datenflusses. Verwaltet wird sie durch einen eigenständigen Controller.

Software Defined Networks
So sieht der Header eines OpenFlow-Datenpaktes aus.

Software Defined Networks
Das Programm WhatsUpGold liefert zahlreiche Informationen zum Netzwerk: So lassen sich zum Beispeil die Verursacher von Bandbreitenengpässen sehr leicht ermitteln.

Software Defined Networks
Auch Cisco unterstützt die OpenFlow Initiative.

Software Defined Networks
Ipswitch hat WhatUp bereits an die Überwachung von OpenFlow-Netzwerke angepasst.

Software Defined Networks
Die strukturierten Netzwerke werden abgeflacht. Jeder Knoten ist dabei über einen HOP zu erreichen.

Software Defined Networks
HP will mit FlexFabric die Netzwerke der Rechenzentren für die Cloud fit machen.

Software Defined Networks
Riverbeds virtuelle Appliance unterstützt Managed Service Provider beim Aufbau von SaaS-Diensten.

IETF mit eigenen Entwicklungen

Allerdings sind neben OpenFlow auch andere Ansätze im Gespräch. So versucht die Internet Engineering Task Force (IETF), die viele Netzwerk- und Internet-Standards entwickelt hat, auch bei SDN das Heft in die Hand zu nehmen. Die IETF forciert die Entwicklung von Forwarding and Control Element Separation (ForCES). Dieses Protokoll weist ähnliche Funktionen wie OpenFlow auf. Ein Kritikpunkt der IETF ist, dass es bislang keine Standardschnittstellen zwischen SDN-Controllern und IP-Routern gibt. Diesen Missstand soll die IETF-Arbeitsgruppe "The Interface to Routing System" (I2RS) beheben, die sich 2013 formiert hat.

"In der Diskussion um Software Defined Networking wird häufig vergessen, dass es sehr wohl Alternativen zu OpenFlow gibt. Der Eindruck, dass SDN mit OpenFlow gleichzusetzen sei, ist schlichtweg falsch", bestätigt auch Ulrich Hamm, EMEA Consulting System Engineer Datacenter, Cisco Deutschland.

Vorteile von SDN

Gleich, ob OpenFlow oder ein anderes SDN-Protokoll zum Zuge kommt, hat Software Defined Networking aus Sicht seiner Protagonisten etliche Vorteile:

• Der Controller ist kein geschlossenes System, sondern kann von Netzwerkfachleuten programmiert und somit an spezielle Anforderungen angepasst werden.

• Es lassen sich unterschiedliche Netzwerk-Systeme von einer zentralen Stelle aus steuern. Das gilt für physische Switches und Router bis hin zu virtualisierten Switches (vSwitches), WLAN-Access-Points und WAN-Optimierungssysteme.

• Anwendungen und neue Netzwerkdienste können innerhalb von Stunden bereitgestellt werden. Derzeit erfordert dies oft mehrere Tage oder gar Monate. Bei SDN wird die Implementierung neuer Services über die Einträge in den Flow Tables gesteuert. Auf diese Weise lassen sich auch Quality-of-Service-Merkmale und VLAN-Konfigurationen festlegen.

• Service-Definitionen müssen nicht mehr auf physikalische Netzwerk-Ports "gemappt" werden. Das verringert den Konfigurationsaufwand.

• Der Controller vermittelt dem Administrator eine "ganzheitliche" Sicht auf die Anwendungen, Netzwerkelemente und Datenströme (Flows). Dies ist ein Vorteil gegenüber anderen Konzepten wie etwa virtualisierten Overlay-Netzen.

• Die Komplexität einer Netzwerkinfrastruktur verringert sich, weil weniger Switch-Ports und Kabel erforderlich sind. Bei LANs und Storage Area Networks sind es nach Angaben von Oracle, das sich ebenfalls im Bereich SDN als Anbieter betätigt, etwa 50 Prozent.

• Mit einem SDN-Controller lassen sich sowohl physische als auch virtualisierte Data Planes steuern. Das erleichtert die Bereitstellung von IT-Services in IT-Umgebungen, in denen zumindest ein Teil der IT-Ressourcen virtualisiert wurde.

Skeptische Netzwerkhersteller

Nachvollziehbar ist, dass Software Defined Networking nicht nur auf Gegenliebe stößt. Vor allem etablierte Netzwerkausrüster wie Cisco Systems, Juniper, HP, Brocade oder Extreme Networks, das jüngst Enterasys Networks übernahm, müssen fürchten, dass SDN ihnen einen Teil des Geschäfts wegnimmt. Denn statt hoch spezialisierter Switches mit speziellen ASICS (Application-specific ICs) und Betriebssystemen wie IOS (Cisco) oder JUNOS (Juniper) können Anwender auf "White-Box"-Systeme mit konventionellen Hochleistungsprozessoren zurückgreifen.

Diesen Trend sieht beispielsweise Stu Bailey, Mitbegründer und Chief Technology Officer von Infoblox, einem Anbieter von Netzwerkmanagement-Lösungen: "Mit SDN ergibt sich eine Entwicklung in Richtung einer 'Consumerization' von Netzwerkausrüstung. Anbieter von SDN-Open-Switches wie Big Switch oder Pica8 setzen bei der Hardware auf Standarddesigns und Standardprozessoren. Eine vergleichbare Entwicklung haben wir im Server-Bereich erlebt - weg von Spezialprozessoren hin zur x86-Architektur."

Overlay-Netze als Alternative

Als Alternative zum des SDN-Konzept werden derzeit virtualisierte Netzwerk-Overlay-Infrastrukturen (Virtual Network Overlays) gehandelt. Unter anderem hat Cisco Systems mit Cisco One (Open Network Environment) ein solches Konzept entwickelt. Im Unterschied zu SDN beschränkt sich ein Overlay-Netz nicht auf Control und Data Plane, sondern bezieht über entsprechende Application Programming Interfaces auch höhere Ebenen mit ein, etwa das Management und die Orchestrierung. Zudem lassen sich, so Cisco, in einer Overlay-Struktur wie Cisco One im Vergleich zu SDN erweiterte Netzwerkanalyse-Funktionen verwenden. Auf Basis der Daten, die diese Applikationen liefern, kann ein Netzwerkverwalter detaillierte "Network Policies" definieren. Das wieder macht es einfacher, IT-Services bereitzustellen.

"Cisco One unterstützt OpenFlow, OpenStack und Network Functions Virtualization, arbeitet aber gleichzeitig mit der vorhandenen Infrastruktur zusammen, etwa auf Basis von Switches und Servern von Cisco", so Hamm. Ein Vorteil der Cisco-Lösung sei zudem die Unterstützung von mehreren Domänen. "Dies ist bei anderen SDN- Lösungen nicht der Fall", betont Hamm.

Während sich SDN auf die Trennung von Control und Data Plane beschränkt, wird bei Netzwerk-Virtualisierung der gesamte Management-Layer, inklusive SDN, von der zugrundeliegenden physischen Infrastruktur abstrahiert. Auch dieser Ansatz ermöglicht es, Netzwerke "zu programmieren".

Eine "Overlay Network Virtualization" hat den Vorteil, dass sich damit bestehende Netzwerke, in denen Standard-Switches eingesetzt werden, auf eine Weise erweitern lassen, dass sie auch mit Workloads in virtualisierten und Cloud-Computing-Umgebungen umgehen können, so Jason Metlof, Marketing-Chef von Big Switch Networks, einem Anbieter von SDN-Komponenten. Dazu nutzten Overlay-Netze Tunnel, über die der Datenverkehr zwischen Virtual Hosts läuft. Ein Schwachpunkt dieses Ansatzes ist laut Big Switch, dass die Steuerung der Virtual Switches über herstellerspezifische Protokolle erfolgt.

Dennoch räumt Thomas Schwaller, Linux and Network Architect bei IBM, Overlay-Netzen gute Chancen ein: "Sie ermöglichen es Netzwerkverwaltern, ohne größere Risiken Erfahrungen mit programmierbaren Netzen zu sammeln. Zudem lässt sich auf diese Weise eine Virtualisierungsebene über vorhandene Netzwerk-Hardware legen. Dies eröffnet Anwendern die Option, ihre vorhandene Infrastruktur weiterhin zu nutzen."

Laut Schwaller werden sich Overlay-Netze zunächst am Rand von Netzwerken etablieren. Allerdings räumt er ein, dass es speziell in mittelständischen Unternehmen neue Ansätze wie SDN, Overlay-Netze und Netzwerkvirtualisierung schwer haben: "OpenFlow und Overlay-Infrastrukturen sind noch nicht in den Köpfen drin. Wir werden aber spätestens 2014 erste Proof-of-Concept-Installationen sehen."

Rolle der I/O-Systeme nicht unterschätzen

Ein Punkt, der beim Umstieg auf eine SDN- oder Overlay-Infrastruktur nicht vergessen werden sollte, sind laut Perry Eekhout, Regional Manager Central Europe bei Emulex, die I/O-Systeme: "Unternehmen müssen sich Gedanken darüber machen, wie sie I/O-Systeme und -Architekturen zur Bereitstellung von Services und zur Verbesserung der End-to-End-Performance nutzen können. Durch den Einsatz eines intelligenten I/O-Systems am Netzwerkrand können Anwender mithilfe der verteilten Prozessbearbeitung sowohl I/O als auch Netzwerkvirtualisierung effektiver gestalten."

Die Möglichkeit, I/O- und Netzwerkverarbeitung unabhängig vom Host-CPU durchzuführen, bedeutet laut Eekhout, dass mehr Rechenleistung zur Unterstützung einer größeren Anzahl von Virtual Machines zur Verfügung steht. "Und höhere VM-Dichten führen dazu, dass CIOs ihre Betriebs- und Investitionskosten reduzieren können, da sie weniger physische Server benötigen."

Praxis: Miteinander von SDN und Virtual Overlay Networks

Ob nun virtualisierte Overlay-Netze oder Software Defined Networking - noch ist nicht absehbar, welche Technologie sich durchsetzen wird. Es ist zu vermuten, dass in der Praxis mehrere Ansätze gleichzeitig in einem Netzwerk zum Zuge kommen. IBM sieht in einem solchen Dualismus kein Problem. Im Gegenteil: Der Vorteil von virtualisierten Overlay-Netzen ist, dass sie Hardware-agnostisch sind und mit jeder IP-basierten Infrastruktur zurechtkommen.

SDN wiederum lässt sich dazu verwenden, um in einem OpenFlow-basierten Netzsegment neue Dienste und Anwendungen bereitzustellen. Als übergeordnetes Bindeglied dient eine SDN-Plattform, über deren Northbound-API Anwendungen und Netzwerkdienste angebunden werden. In der Praxis dürften solche Modelle allerdings zumindest derzeit nur für große Infrastrukturen mit Tausenden von Netzwerkkomponenten in Frage kommen. (hi)