Software-defined Networking

Architektur-Übersicht

SDN ermöglicht Netzadministratoren, das Netz einfacher zu verwalten, indem die unteren Funktionsebenen in virtuelle Services abstrahiert werden. Die Hardware muss also nicht mehr manuell konfiguriert werden.[3] Das wurde immer wichtiger mit dem Aufkommen von Virtualisierung, bei der ein größeres Rechenzentrum in zunehmender Anzahl über das Netz virtuelle Systeme erstellen und konfigurieren muss, und zugehörige Firewall-Regeln und Netzadressen generiert werden müssen. Es gibt etliche Ansätze, analog auch virtuelle Netze (VLANs) zu generieren, aber das führt zu einer hohen Komplexität.[3] SDN gibt den Netzadministratoren eine programmierbare, zentrale Steuerung des Netzverkehrs, ohne manuell Zugriff auf die einzelnen physischen Netzkomponenten nehmen zu müssen.[4][5]

SDN entkoppelt das System, das entscheidet, wohin die Daten geschickt werden (die Control-Plane), vom darunterliegenden System, das die Daten zum ausgewählten Bestimmungsort weiterleitet (die Data-Plane).[6] Die Entwickler und Anbieter dieser Systeme geben an, dass diese Technik die Netzadministration vereinfacht[7] und neue Anwendungen ermöglicht, wie die Netz-Virtualisierung, bei der die Control-Plane von der Data-Plane getrennt und als reine Anwendung implementiert wird.[8]

Die Open Networking Foundation wurde gegründet, um SDN-Standards zu fördern. Trends wie Cloud Computing verwischen die Grenzen zwischen Netz und Computer in einem technischen Umfeld, wo SDN-Standards nützlich erscheinen.[3]

Internet Protocol (IP)-basierende Netze basieren auf dem Konzept Autonomer Systeme (AS). Dieser Ansatz erlaubt es, Netze zu erweitern, indem immer weitere Knoten angeschlossen werden, die eintreffende Pakete zu einem sinnvollen nächsten Knoten weiterleiten und dabei keinen detaillierten Blick auf die gesamte Netzstruktur benötigen. Dieses Konzept ist einfach und hat sich als stabil und erweiterbar erwiesen. Im einfachsten Fall erlaubt es dieses Konzept einer Komponente nicht, sich an einer anderen Stelle im Netz anzuschließen, denn sie würde ihre Pakete nicht mehr erhalten. Die Identität einer Netzkomponente ergibt sich aus ihrer Stelle im Netz. Außerdem ist es mit einfachen AS-Strukturen kaum möglich, der Komponente bestimmte Eigenschaften zuzuordnen, wie logische Gruppierung, Zugriffskontrolle, Quality of Service, eine spezifische Verarbeitung von Daten vor der Zustellung oder auch Kontextinformationen zu Datenströmen, die über den Inhalt des einzelnen Pakets hinausgehen.

Ergänzende Standards wurden von der Internet Engineering Task Force (IETF) verabschiedet, um diesen Bedürfnissen Rechnung zu tragen, wie DHCP, Routing, virtuelle LANs oder virtuelle private Netze (VPNs). Nach und nach wuchs hierdurch die Komplexität bei der Spezifikation und Konfiguration des Netzes durch die Administratoren.

Die verstärkte Internet-Nutzung, inzwischen auch über mobile Endgeräte, war einer der Treiber, die den Bedarf an hoch standardisierten Betriebssysteminstanzen forcierte. Cloud-Architekturen mit dynamischer Ressourcen-Zuordnung tragen dem Rechnung, und SDN strebt an, die erforderlichen Netzkonfigurationen vergleichbar automatisiert auszurollen wie virtuelle Systeme. Die hohe Dynamik bei der Verlagerung mehr oder weniger stark genutzter Systeme auf jeweils passende Hardware-Ressourcen wird dabei unterstützt. Es muss nicht jedes Mal manuell an Switches konfiguriert werden, um die vereinbarten Policys einzuhalten. Vielmehr erfolgen die Anpassungen von Routing- und Firewall-Regeln, Bandbreitenzuteilungen usw. automatisiert und zentralisiert, während die dezentralen Hardware-Komponenten nur noch einfache Aufgaben wie die Weiterleitung eines Pakets zum richtigen Port übernehmen.

Die zentrale, software-definierte Steuerung erkennt auch spezifische Kontexte, die an Quelle-Ziel-Beziehungen festzumachen sind. So muss nicht jedes Paket der kompletten Firewall-Prüfung unterzogen werden, wenn frühere, vergleichbare Pakete aus derselben Verbindung die Prüfung bereits bestanden haben. Passende Mechanismen zur Einbindung herstellerspezifischer Funktionen und Implementierungen wurden gefunden. Einen Schritt weiter geht Openflow mit der Standardisierung von Befehlen zur Konfiguration der Data Plane. Das OpenFlow-Protokoll ermöglicht die Entwicklung von Software-Controllern, die das gesamte Netz steuern. Sie können zentralisiert oder verteilt implementiert werden, um über die traditionellen IP-Kernfunktionen eine Ebene zu legen, welche die komplexeren und teilnehmerspezifischen Netzfunktionen verwaltet.

Der Begriff "Software-Defined Networking" wurde 2009 von Kate Greene geprägt.[9]

Man kann ein SDN so konfigurieren, dass die Hardware mit der Control Plane eine andere ist als die mit der Data Plane, sodass ein Switch nur Pakete weiterleitet, während ein separater Server die Aufgaben der Control Plane übernimmt.

Es gibt zwei Gründe für diesen Ansatz. Zum einen können unterschiedliche Gerätezahlen, Austauschzyklen usw. zum Einsatz kommen. Zum anderen kann jeweils optimal geeignete Hardware eingesetzt werden, z. B. ein leistungsfähiger Server für die Control Plane und eine größere Anzahl energiesparender Switches für reines Forwarding.

Control Planes und Data Planes müssen hier selbst über das Netz miteinander kommunizieren. OpenFlow ist ein Standard für ein solches Protokoll, jedoch können auch andere Verfahren eingesetzt werden. OpenFlow wird von der Open Networking Foundation verwaltet.[10]

Symmetrisch vs. asymmetrisch

In einem asymmetrischen Modell wird die globale Information eines SDN so weit wie möglich zentralisiert, während der Betrieb der Switches so weit wie möglich verteilt wird. Die Erwartungen daran sind klar: Zentralisierung der Konfiguration vermeidet zu viele Redundanzen und mögliche Inkonsistenzen, während die Verteilung des Datenverkehrs Bandbreitenengpässe an zentralen Stellen vermeidet. Allerdings bleiben Aspekte zu bedenken, z. B. wie störunanfällig eine solche Konstruktion gerade bei mehreren Lokationen ist und ob solche zentralisierten Strukturen ausreichend wachsen können. Beim gegenteiligen Ansatz kennt jede Komponente auch alle für sie relevanten Control-Plane-Konfigurationen, sodass auch bei beliebigen Teilausfällen jede verbleibende Teilstruktur in ihren Grenzen normal weiter arbeiten kann. Praxistauglich sind vor allem solche Ansätze, bei denen zwar die Anzahl der Control Planes minimal ist, wobei aber jede Lokation zur Not autonom arbeiten kann und zwar ohne einen Single Point of Failure.

Floodless vs. flood-based

Im Flood-based-Modell wird ein erheblicher Anteil der globalen Informationsverteilung erreicht, indem jede Veränderung über normale Broadcast- und Multicast-Mechanismen kommuniziert wird. Dadurch können SDN-Modelle symmetrischer werden. Transparentes Bridging wird genutzt, um Informationen allgemein bekannt zu machen und die Identität der Netzteilnehmer zu verbreiten. Andererseits steigt die Netzlast pro Netzknoten an, je mehr Knoten hinzukommen, was die Skalierbarkeit begrenzt. Beim Floodless-Modell wird die korrekte Funktion aller Komponenten dagegen über lokale Caches von SDN-Lookup-Tables sichergestellt, welche von Zeit zu Zeit miteinander synchronisiert werden.

Host-based vs. netz-zentriert

Das host-based Modell nimmt an, dass es in Rechenzentren mit vielen virtuellen Maschinen günstig ist, die SDN-Verarbeitung auf dem Hypervisor-System zu erledigen, weil es hier immer freie Kapazitäten für die relativ geringe entstehende Last gibt. Der netz-zentrierte Ansatz dagegen bleibt bei dedizierten Routern wie traditionell üblich und überlässt die Routing-Funktionen nicht den Virtualisierungshosts.

Einige Grenzlinien sind nicht immer scharf zu ziehen. So können Virtualisierungshosts einige CPU-lastige SDN-Aufgaben wie die Verschlüsselung von VPN-Verkehr übernehmen, während andere Funktionen auf dedizierten SDN-Servern angesiedelt sind. Auch gibt es gewisse Abhängigkeiten; so implizieren Host-based Ansätze ein asymmetrisches Design.

Eine Anwendung von SDN ist Infrastructure as a Service (IaaS). Hier wird SDN kombiniert mit virtuellen Systemen und virtuellem Storage, was eine "elastische", also bedarfsabhängige Ressourcenallokation erlaubt. Insbesondere Scale-Out-Szenarien, bei denen nach Bedarf weitere Systeme zugeschaltet werden, profitieren von der möglichen Automatisierung. Anbieter mit sehr großen Softwareinstallationen wie Google und Facebook zeigen, dass passende Software-Architekturen für solche verteilten Systeme gefunden werden können. Aber auch für kleine Anwendungen, die nur auf einer VM laufen, können dieselben Mechanismen helfen, vollständig von der (Netz-)Hardware zu abstrahieren.

Ein anderer Ansatz sorgt für eine dynamische Re-Allokation virtueller Systeme auf den Virtualisierungshosts. Ziel dabei ist es, möglichst wenige Hosts möglichst gut auszunutzen. Virtualisierungsumgebungen, bei denen Re-Allokationen (wenn überhaupt) nur manuell durchgeführt werden, berücksichtigen bestenfalls die überlasteten Hosts, während ungenutzte Kapazitäten meist keine Beachtung finden, was zu einer schleichenden Unterforderung der betreffenden Hosts und der Verschwendung von Ressourcen führt.

SDN erlaubt die Verteilung von Lasten auf viele Verbindungen, beispielsweise zwischen den Anwendungsservern und dem Netz-Backbone. Traditionell werden hier manuell VLANs definiert und Routen gesetzt oder mit Bondings gearbeitet, was aufwändig ist und keine dynamische Anpassung an wechselnde Lasten ermöglicht. Load-Balancing auf verschiedene Anwendungsserver, verteilte Firewalls und weitere Anwendungen kommen hinzu.

SDN kann in Unternehmen oder bei Carriern auch Managed Network Services (MNS) übernehmen. Hier geht es um Service Level Agreements, d. h. auch bei permanenten Veränderungen am Netz, wie es in solchen Umgebungen unausweichlich ist, soll der einzelne Teilnehmer seine garantierten Bandbreiten, Latenzzeiten, Verfügbarkeiten und Sicherheitsfeatures bekommen.

Wenn der SDN-"Overlay" nicht die Charakteristika der darunter liegenden Infrastruktur berücksichtigt, sind Ineffizienz und geringer Durchsatz die wahrscheinliche Folge.[11] Gerade Carrier sind daher interessiert an SDN-Lösungen, welche Datenmengen, Topologie und Hardware berücksichtigen und entsprechend reagieren.[12] Entsprechend gibt es einen Vorschlag für eine SDN-Lösung, die Netz-Ressourcen berücksichtigt, sodass der Datenstrom kontinuierlich optimiert werden kann, und die Anforderungen in besser vorhersehbarer Weise gehandhabt werden.[13]

Fernzugriff auf die Control Plane wird den Administratoren aus Sicherheitsgründen üblicherweise per RBAC ermöglicht.

1. William Stallings: Foundations of modern networking : SDN, NFV, QoE, IoT, and Cloud. Indianapolis, Indiana 2016, ISBN 978-0-13-417547-8.
2. Sean Michael Kerner: OpenFlow Inventor Martin Casado on SDN, VMware, and Software Defined Networking Hype. In: Enterprise Networking Planet. 29. April 2013, abgerufen am 21. Mai 2013.
3. http://arstechnica.com/information-technology/2013/02/100gbps-and-beyond-what-lies-ahead-in-the-world-of-networking/2/
4. Margaret Rouse: software-defined networking (SDN). TechTarget, Juni 2012, abgerufen am 21. Mai 2013.
5. Bort, Julie.The Three Letters That Are Setting The Enterprise Tech World On Fire, Business Insider, 5 October 2012
6. Software-Defined Networking: The New Norm for Networks. (PDF; 739 kB) Abgerufen am 16. Oktober 2023 (englisch).
7. Big Switch Networks Products. Abgerufen am 20. Oktober 2013.
8. David Strom: Software-defined networking could drastically change today’s network infrastructure. TechTarget, November 2012, abgerufen am 21. Mai 2013.
9. Kate Greene: TR10: Software-Defined Networking In: Technology Review, MIT, 2009. Abgerufen am 21. Mai 2013
10. Open Networking Foundation. Abgerufen am 20. Oktober 2013.
11. Still no VMware of Networking. Overlays change nothing beneath the surface. Abgerufen am 20. Oktober 2013.
12. Adoption of SDN: Progress Update. Archiviert vom Original am 21. Oktober 2012; abgerufen am 20. Oktober 2013.
13. Blueprint for Infrastructure SDN. (PDF; 719 kB) Abgerufen am 20. Oktober 2013.

• Software-Defined Networking: The New Norm for Networks (PDF; 739 kB)
• Floodlight, an open source Java based OpenFlow controller
• Network Function Virtualization (NFV)
• The difference between SDN and NFV - a simple guide by Codilime
• Decoding SDN
• Open Daylight Project