SDN: Technik und Praxisrelevanz

Kampf um die Kontrolle

Bernd Reder ist freier Journalist mit den Schwerpunkten Netzwerke, IT und Telekommunikation in München.
Software Defined Networking (SDN) gilt als revolutionäre Technik, die das Bereitstellen von IT-Services über Netzwerke erheblich vereinfachen soll. Doch SDN ist nicht die einzige Technik, mit der Netzwerke "programmierbar" gemacht werden können. Als Alternative kristallisieren sich Overlay-Netzwerkinfrastrukturen heraus.

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.

Mit Software-defined Networking lassen sich sowohl physische als auch virtualisierte Netzwerksysteme steuern.
Mit Software-defined Networking lassen sich sowohl physische als auch virtualisierte Netzwerksysteme steuern.
Foto: ESG

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.

Stu Bailey, Chief Technology Officer von Infoblox: "White-Box-SDN-Systeme auf Basis von Standard-Hardware könnten an die Stelle von traditionellen Switches und Routern treten."
Stu Bailey, Chief Technology Officer von Infoblox: "White-Box-SDN-Systeme auf Basis von Standard-Hardware könnten an die Stelle von traditionellen Switches und Routern treten."
Foto: Infoblox

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.

Nach Auffassung von IBM lassen sich virtualisierte Overlay-Netze und Software-defined Networking auf Basis von OpenFlow durchaus parallel in einem Unternehmensnetz einsetzen – zum Vorteil beider Technologien.
Nach Auffassung von IBM lassen sich virtualisierte Overlay-Netze und Software-defined Networking auf Basis von OpenFlow durchaus parallel in einem Unternehmensnetz einsetzen – zum Vorteil beider Technologien.
Foto: IBM

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.

Perry Eekhout, Emulex: "Unternehmen müssen sich Gedanken darüber machen, wie sie I/O-Systeme und -Architekturen in SDN-Umgebungen zur Bereitstellung von Services und zur Verbesserung der End-to-End-Performance nutzen können."
Perry Eekhout, Emulex: "Unternehmen müssen sich Gedanken darüber machen, wie sie I/O-Systeme und -Architekturen in SDN-Umgebungen zur Bereitstellung von Services und zur Verbesserung der End-to-End-Performance nutzen können."
Foto: Emulex

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.

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.

Struktur einer SDN-Infrastruktur: Ein Vorteil ist, dass sich über SDN unterschiedliche Netzwerksysteme ansprechen lassen, von Servern und Switches bis hin zu Media-Gateways. Für einzelne Gerätekategorien können IT-Services mit speziellen Quality-of-Service-Merkmalen definiert und aufgesetzt werden.
Struktur einer SDN-Infrastruktur: Ein Vorteil ist, dass sich über SDN unterschiedliche Netzwerksysteme ansprechen lassen, von Servern und Switches bis hin zu Media-Gateways. Für einzelne Gerätekategorien können IT-Services mit speziellen Quality-of-Service-Merkmalen definiert und aufgesetzt werden.
Foto: Intel

"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.

Inhalt dieses Artikels