Die Etablierung von OpenFlow als zentrales Netzwerk-Kontroll-Protokoll

OpenFlow könnte sich zur zentralen Kontrollinstanz für alle Netzwerk-Protokolle entwickeln. Bis dahin ist aber noch einige Entwicklungsarbeit nötig.

Die Suche nach einem Mechanismus, um ein Netzwerk komplett managen zu können, ist eine Lebensaufgabe für jeden Netzwerk-Architekten. Eigentlich ist dieses Ziel nicht erreichbar, doch es gibt mittlerweile etwas Hoffnung. Die Lösung könnte OpenFlow sein, das sich in ein Protokoll verwandelt, welches über Layer 2 und Data Center hinaus geht.

In den letzten Jahren haben Netzwerkanbieter viel Wirbel um SDN und OpenFlow gemacht. Beide kommen zwar oft im Verbund vor, doch dieser Umstand verschleiert zum Teil ihren wahren Nutzen - unter anderem, da sich der SDN-Diskurs vor allem um Data Center und in Universitäten abspielt. OpenFlow ist aber nur ein Element im Gesamtbild. Das Erschaffen von weiterleitenden Netzen innerhalb einer Layer-2-Domäne ist zwar wichtig, aber nur ein kleines Puzzlestück. Wie wertvoll ist Data-Center-Networking und -Provisioning, ohne die Verbindung zu anderen Ressourcen und Konsumenten dieser Services?

Wir übersehen viel zu häufig, wie OpenFlow möglicherweise das zentrale Management und die Kontrolle aller Netzwerkschichten beeinflusst. WAN und die existierenden Provider-Netzwerke inklusive deren Forwarding-Mechanismen, wie zum Beispiel MPLS, VPLS und Layer-3-Routing-Mechanismen, sind ein wichtiger Teil, um die Services auf Anwendungsebene und die Verbindung auf den letzten Metern bereitzustellen.

Lassen Sie diese Teile bei der Planung einer OpenFlow-Strategie außen vor, ist das kurzsichtig. Sie müssen OpenFlow zu einem Plattform-übergreifenden, vielschichtigen Netzwerk-Kontroll-Protokoll entwickeln.

Ein Kontroll-Protokoll für jede Netzwerk-Schicht?

OpenFlow hat das Potential, das zentrale Netzwerk-Protokoll zu werden. Eventuell kann es Teil einer einzigen Strategie sein, um DWDM Waves, MPLS LSPs, VPLS-Kreisläufe, Layer-3-Routing und Layer-2-Tagging zu managen und manipulieren sowie Zugriff auf Ebenen-Ports und sogar „Layer 8“ - oder die administrative Schicht zu haben.

OpenFlow hat alle Eigenschaften einer vereinigenden Komponente in einer Branche, die YANG, NETCONF, SSH, Telnet und eine ganze Reihe anderer Management-Mechanismen verwendet. Möglicherweise ist es ein idealistisches Ziel. Es ist aber machbar und der Grundstein dafür ist bereits gelegt.

In OpenFlow 1.4 sind die Spezifikationen für die Unterstützung optischer Schnittstellen bereits integriert. Die optische Kontrolle ist einer der schwierigsten Aspekte der zentralen Kontrolle. Es ist ein Indikator, dass OpenFlow 1.3 und 1.4 gut positioniert sind, um die Kriterien der optischen Schicht zu erfüllen. Das beinhaltet die Unterstützung für MPLS und Protokolle, wie zum Beispiel IPv6.

Einige Hürden stehen OpenFlow noch im Weg

OpenFlow hat noch einen langen Weg vor sich. Dabei muss man bedenken, dass die Spezifikationen von 1.4 nur eine einfache optische Kontrolle beinhalten. Auch wenn OpenFlow 1.4 bereits die Basis für optische Kontrolle beinhalten, sind Layer 3 und WAN noch eine andere Ebene. Um das zu realisieren, muss man eine Lösung finden, um große Datensätze verarbeiten  zu können. Das umfasst zum Beispiel rund 400.000 IPv4- und 13.000 IPv6-Routen. Das ist zwar machbar, doch sie stabil, redundant und skalierbar zu gestalten, ist nicht einfach.

Realistisch betrachtet, kann OpenFlow kurzfristig L2/L2.5/MPLS-Kreisläufe sowie L3-Next-Hops und einige andere Aufgaben wie TTL (Time-to-Live) kontrollieren. Derzeit bleibt die Arbeit allerdings noch an konventionellen Routern hängen, die möglicherweise für einen oder zwei Lebenszyklen in einem hybriden Modus operieren werden.

Um zu einem einzigartigen Netzwerk-Kontroll-Protokoll aufzusteigen, muss OpenFlow viele Anbieter unterstützen. Darüber hinaus muss der Controller-Markt reifen. OpenDaylight ist derzeit führend in diesem Bereich. Doch für eine flächendeckende Annahme benötigt der Markt noch einige konkurrenzfähige Optionen, um Innovation voranzutreiben. Um sich in der Netzwerk-Branche durchzusetzen, muss OpenFlow genauso wichtig wie jedes andere Standard-Protokoll sowie universell einsetzbar sein und wie SSH und SNMP unterstützt werden.

Artikel wurde zuletzt im April 2014 aktualisiert

Erfahren Sie mehr über Software, Tools und Utilities für das Netzwerk-Management

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchDataCenter.de

SearchEnterpriseSoftware.de

Close