Die Wechselbeziehung zwischen SDN und NFV verstehen

SDN (Software-defined Networking) und NFV (Network Functions Virtualization) überschneiden sich teilweise. Davon könnten die Technologien profitieren.

Eine Branche mit einem langen Lebenszyklus bei Investitionsgütern für die Unterstützung einer Revolution zu gewinnen, ist schwierig. Beim Thema Netzwerk gibt es derzeit sogar gleich zwei große Veränderungen. Sowohl SDN (Software-Defined Networking) als auch NFV (Network Functions Virtualization) versprechen revolutionäre Entwicklungen. 

Damit beide das Netzwerk verändern können, müssen die Technologien wahrscheinlich miteinander harmonieren oder sich sogar gegenseitig unterstützen. Wo sich diese Harmonien befinden, erklärt möglicherweise der Fahrplan für das Netzwerk der Zukunft.

SND und NFV sind kein wesentlicher Bestandteil

SDN hat sich wegen zwei verschiedener Branchenprobleme entwickelt. Das Kreieren und Managen von großen IP- oder Ethernet-Netzwerken wurde immer komplexer. Der Grund ist die anpassbare Natur der Paketweiterleitung (Forwarding) für beide Protokolle

Traffic-Management und die Effizienz des Betriebs ließe sich nach Meinung vieler verbessern, wenn man die zentrale Kontrolle über das Forwarding hätte. Frühe SDN-Beispiele von Unternehmen wie Google scheinen diese Behauptungen zu unterstützen.

Weiterhin schafft Cloud Computing einige neue Modelle für die Bereitstellung von Applikationen. Kunden müssen sich Data Center in einer Public Cloud teilen und dürfen sich dabei nicht gegenseitig im Weg stehen. Applikationen mit vielen Komponenten muss man mit flexiblen Ressourcen-Pools einsetzen, ohne die Kontrolle über Performance und Security zu verlieren. 

Aufgrund der zwei verschiedenen Ziele überrascht es nicht, dass mindestens drei Modelle von SDN hofiert werden. Eines dreht sich um zentralisierte Kontrolle via OpenFlow-Controllern. Ein weiteres Modell will mittels SDN das Provisioning und Management von Netzwerk-Virtualisierung über Netzwerk-Overlays realisieren. Die dritte Option ist ein verteiltes Modell, bei dem eine höhere Software-Schicht mit dem Netzwerk und seinen existierenden Protokollen kommuniziert.

Virtualisierung von Netzwerk-Funktionen ist eine Initiative der Telekommunikations-Anbieter. Man möchte diese von speziell entwickelten Geräten auf herkömmliche Server transportieren. Die Ziele von NFV sind, die Einsatzkosten für Services zu reduzieren, indem man weniger proprietäre Geräte benötigt und die Flexibilität von Services zu erhöhen, indem man auf ein agileres Software-basiertes Framework setzt, um die Service-Funktionen zu erstellen. 

Wie man dem ersten Whitepaper entnehmen kann, haben Innovatoren einen Pool an virtuellen Funktionen, einen Pool an Ressourcen und einen Orchestrierungs-Prozess visualisiert, der ersteres mit letzterem verknüpft. Aus diesem Papier lässt sich ableiten, dass sich NFV und SDN etwas überschneiden. Dabei ist SDN aber keine Teilmenge von NFV oder andersherum. Wo überschneiden sich SDN und NFV nun? Wie wird die Interaktion zwischen SDN und NFV auf die Evolution beider Ansätze Einfluss haben?

SDN und NFV werden sich irgendwann treffen, um zentralisierte Kontrolle voranzubringen

Es scheint klar zu sein, dass NFV die zentrale Kontrollfunktion von SDN als virtuelle Funktionen definieren kann. Zum Beispiel könnten OpenFlow-Switches von NFV-Software gelenkt werden. Theoretisch könnte der SDN-Controller als virtuelle Funktion implementiert werden. Somit wäre das konform mit SDN und NFV.

Firewall- und Load-Balancing-Applikationen sind ebenfalls Ziele von NFV, weil sie eine SDN-ähnliche Trennung für Forwarding und Kontrollverhalten aufweisen. Sollte NFV das allgemeine Policy-verwaltete Forwarding adressieren, könnte das eine Übermenge von SDN definieren.

NFV könnte auch zentrale Kontrolle und Administration von Netzwerken umreißen, die mit anderen Protokollen wie BGP und MPLS (Multiprotocol Label Switching) laufen. Das gilt auch für Konfiguration und Management von Optical-Layer Transport. Allerdings scheinen das keine Prioritäten für die nahe Zukunft zu sein. Somit ist diese direkte Überlappung von SDN und NFV in den nächsten paar Jahren eher unwahrscheinlich.

NFV setzt virtuelle Netzwerk-Overlays voraus und damit SDN

Es wird wahrscheinlich noch eine Weile dauern, bis NFV bei der SDN-Architektur eine entscheidende Rolle spielt und umgekehrt. Die Verwendung von Netzwerk-Overlays bei NFV wird kurzfristig treibender Faktor für einen Schnittpunkt der Technologien.

NFV wird ein Modell an Cloud-basierten virtuellen Funktionen akzeptieren müssen, wenn nicht sogar voraussetzen. Jede Ansammlung virtueller Funktionen, die einen Anwender-Service definieren, könnten als Mandant der NFV-Infrastruktur gesehen werden. Das bedeutet, dass die Cloud-Probleme bei der Mandantenfähigkeit NFV möglicherweise dahingehend beeinflussen, ein Software-Overlay-Netzwerk-Protokoll anzunehmen. An dieser Stelle kommt SDN ins Spiel.

Dieses aus Tunneln und vSwitches bestehende Modell würde die virtuellen Funktionen trennen, um versehentliche oder böswillige Interaktion zu verhindern. Weiterhin würde es sich einfach zu derzeitigen virtuellen Cloud-Computing-Netzwerk-Schnittstellen verbinden lassen. Wir sprechen hier zum Beispiel von OpenStacks Quantum. Diese virtuellen Netzwerke würden mithilfe von SDN vorgehalten und gemanagt.

Die Adoption von Netzwerk-Overlays für die Trennung virtueller Funktionen könnte NFV zum größten Verbraucher von Cloud-Networking und SDN-Services machen. Das bedeutet auch, dass NFV Produkt-Funktionen beeinflussen und den Einsatz von SDN-Produkten beschleunigen würde. Dieser Umstand könnte einen Einfluss auf jedes Data Center und jede Applikation hinsichtlich Cloud Computing haben, inklusive privater und hybrider Clouds.

Wie NFV über das Data Center hinaus SDN voranbringt

Die Verwendung von virtuellen Netzwerk-Overlays durch NFV könnte auch die Erweiterung dieses SDN-Modells über das Data Center hinaus antreiben, wo es heutzutage am meisten eingesetzt wird. Wenn es NFV gestattet, dass Services aus virtuelle Funktionen zusammengestellt werden, die sich in verschiedenen Data Centern befinden, würde das voraussetzen, dass sich virtuelle Netzwerke über Data Center erstrecken und somit „Endpunkt-zu-Endpunkt (End-to-End)“ werden. 

Ein virtuelles End-to-End-Netzwerk wäre für Unternehmen wesentlich interessanter sein als ein begrenztes Data Center. Legt man Applikations-spezifische Netzwerke an, die sich bis zu den Außenstellen erstrecken, ist das Resultat möglicherweise ein neues Modell hinsichtlich Applikation-Zugriffs-Kontrolle, Applikations-Performance-Management und sogar Applikations-Security.

Wird NFV die verschiedenen SDN-Modelle vereinen?

Mit der Benutzung von Netzerk-Overlays, könnte NFV also die beiden Modelle hinsichtlich SDN-Infrastruktur, zentralisiert und verteilt, vereinen. Wenn Verbindungs-Kontrolle und Isolation von Applikations-Komponenten oder Anwendern von einem Netzwerk-Overlay verwaltet werden, könnte das Ziel von SDN für das physischen Netzwerk mehr auf das Traffic-Management beschränkt sein. Sollte SDN aggregierte Routen mehr als individuelle Applikations-Flüsse verwalten, könnte es skalierbarer sein.

Schenken Sie den SDN-Applikationen Beachtung, auf die heutzutage am meisten referenziert wird. Das sind LANs im Data Center und Googles SDN-IP-Kern-Netzwerk. Diese sind mehr routen- als flussbasiert. Die Vereinigung des SDN-Modells könnte es also einfacher machen, SDN-Implementierungen zu realisieren. 

Das tiefer liegende physische SDN-Netzwerk in diesem Zwei-Schichten-Modell ließe sich einfach mit Revisionen existierender Protokolle realisieren. Das wurde auch schon so vorgeschlagen. Es bietet nicht die Art an Applikations-Verbindungs-Kontrolle an, die sich einige gerne wünschen. Diese Anforderung würde von einer höher angesiedelten Software-Schicht für virtuelle Netzwerke oder einem Overlay erfüllt.

Trotz aller Diskussionen befinden sich SDN und NFV immer noch aktiv in der Entwicklung und beide könnten das geplante Ziel nicht erreichen. Sollte NFV allerdings sein Ziel erfüllen, wird das auch SDN vorwärts bringen und zumindest für eine gemeinsame Netzwerk-Revolution sorgen.

Über den Autor:
Tom Nolle ist Präsident von CIMI, einem strategischen Beratungsunternehmen im Bereich Tele- und Datenkommunikation.

Folgen Sie SearchNetworking.de auch auf Facebook, Twitter und Google+!

Erfahren Sie mehr über Software-defined Networking

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close