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.

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.