Dieser Artikel ist Teil unseres Guides: Einführung in Software-defined Networking (SDN)

Das NETCONF-Protokoll als Alternative zu OpenFlow

Lange Zeit ging bei SDN nichts an OpenFlow vorbei. Langsam gibt es Alternativen wie zum Beispiel NETCONF.

OpenFlow war lange Zeit unbestritten das Nonplusultra für das Management und die Kontrolle für Software-defined Networks (SDN). Durch andere Protokolle gibt es aber plötzlich Konkurrenz. Wir sprechen hier von Alternativen zu OpenFlow, wie zum Beispiel NETCONF, BGP, OVSDB, XMPP und MPLS-TP. All diese Protokolle lassen sich nutzen, um bestimmte Aspekte in Sachen Netzwerkbetrieb zu managen. Allerdings bietet verglichen mit OpenFlow keines identische Funktionen und Leistungsmerkmale.

Das NETCONF-Protokoll ist in RFC 6241 definiert. Es handelt sich dabei um ein Protokoll für die Konfiguration von Geräten, um damit die Kommandozeile (CLI, Command Line Interface), SNMP (Simple Network Management Protocol) und andere proprietäre Mechanismen zur Konfiguration zu ersetzen. Verwendet eine Software das NETCONF- Protokoll, kann sie damit Konfigurationsdaten auf ein Gerät schreiben und natürlich auch Informationen von einem Gerät abrufen. Sämtliche Daten sind im XML-Format (Extensible Markup Language) gehalten und werden über sichere Remote Procedure Calls (RPCs) übertragen. Dafür setzen die Entwickler auf verbindungsorientierte Protokolle wie zum Beispiel Secure Socket Shell (SSH) oder Transport Layer Security (TLS).

Das NETCONF-Protokoll definiert mehrere Datenspeicher (Data Stores) oder Konfigurationssätze an Daten. Im laufenden Datenspeicher (Running Data Store) befinden sich die Daten oder die Konfiguration, die das Gerät momentan benutzt. Einige Geräte haben außerdem einen anfänglichen Configuration Data Store, der getrennt vom laufenden Konfigurationsspeicher ist. Diese Daten werden beim Start eines Geräts zurate gezogen.

Zusätzlich zu den Configuration Data Stores verwenden Geräte statische Daten (State Data). Das sind Informationen wie zum Beispiel Paketzähler und andere Daten, die das Gerät während des Betriebs sammelt. Die Controller-Software kann diese Daten lesen, aber nicht schreiben.

Der Candidate Configuration Data Store ist eine optionale Funktion des Geräts. Ist sie verfügbar, befindet sich darin ein Satz an Konfigurationsdaten, die der Controller für ein Update des laufenden Configuration Stores nutzen darf. So lässt sich der Betrieb des Geräts modifizieren. Durch die Trennung des laufenden Konfigurationsspeichers und eines möglichen Kandidaten lässt sich das Problem inkonsistenter Konfiguration vermeiden. Ein Beispiel wäre, dass eine Reihe an CLI-Befehlen die Konfiguration aktualisieren und sie so in einen inkonsistenten Status versetzen, weil einfach ein Befehl nach dem anderen ausgeführt wird.

Controller und Geräte tauschen einen Satz an Leistungsmerkmalen aus, sobald eine NETCONF-Sitzung beginnt. Zu den Merkmalen gehören Informationen wie die unterstützten Versionen des NETCONF-Protokolls. Weiterhin wird kommuniziert, ob ein Candidate Data Store vorhanden ist und auf welche Weise sich der Running Data Store modifizieren lässt. Zu den in den NETCONF RFC definierten Fähigkeiten können Entwickler zusätzliche hinzufügen. Sie müssen dafür einfach dem spezifizierten Format folgen, der in den RFC hinterlegt ist.

Der Befehlssatz des NETCONF-Protokolls besteht aus Kommandos, mit denen sich die Konfigurationsdaten des Geräts auslesen und modifizieren lassen. Außerdem gibt es einen Befehl, der die statischen Daten ausliest. Die Befehle werden via RPCs kommuniziert und die Antworten erfolgen ebenfalls via RPC. Für jede Anfrage, die über RPC gestellt wird, muss es auch eine Antwort via RPC geben. Ein Konfigurationsablauf besteht möglicherweise aus einer Reihe an RPCs und jeder davon erhält eine entsprechende Antwort.

Das gewählte Transportprotokoll muss sicherstellen, dass die zum Gerät gesendeten RPCs in der richtigen Reihenfolge geschickt werden. Das gilt auch für die entsprechenden Antworten. Es ist aber nicht nur möglich, Befehle vom Controller zum Gerät zu schicken. Ein Gerät kann auch Daten senden, um den Controller über Ereignisse auf dem Gerät zu informieren.

Die Befehle des NETCONF-Protokolls:

  • get-config: Damit wird ein Teil oder der gesamte Data Configuration Store abgefragt. Die mit auf den Weg gegebenen Parameter spezifizieren den Configuration Data Store und geben an, ob der gesamte Inhalt zurückgegeben werden soll. Ist das nicht der Fall, werden die bestimmten Objekte angegeben. Das Gerät antwortet mit den angeforderten Daten oder einem RPC-Fehler, sollte die Anforderung nicht erfüllt werden können.
  • get: Fordert den Running Configuration Data Store und State Data an. Über den Befehl können Sie alle Daten oder nur spezielle Elemente abfragen.
  • edit-config: Modifiziert einen Configuration Data Store. Der Befehl enthält spezielle Betriebsanweisungen, die sich auf spezielle Konfigurationselemente im Zieldatenspeicher beziehen.
  • merge: Die Daten im Befehl edit werden mit existierenden Daten zusammengeführt.
  • replace: Die existierenden Daten werden durch die Daten ersetzt, die sich in diesem Befehl befinden.
  • create: Das spezielle Element im Data Store wird erzeugt und die Daten aus dem Befehl eingefügt. Existiert das Element bereits, dann antwortet das Gerät mit einem RPC-Fehler.
  • delete: Das angegebene Element aus dem Data Store wird gelöscht. Sollte es nicht existieren, dann antwortet das Gerät mit einem RPC-Fehler.
  • remove: Ist ähnlich zu delete. Existiert das Element allerdings nicht, dann wird die Handlung schlicht ignoriert und kein Fehler zurückgegeben.
  • copy-config: Kopiert den Inhalt von einem Data Store zu einem anderen. Sollte der Datenspeicher nicht existieren, wird er durch den Befehl erstellt.
  • commit: Kopiert den Inhalt des Candidate Data Stores in den Running Data Store. Der Befehl wird verwendet, wenn es keine Möglichkeit gibt, den Running Data Store mittels copy-config zu modifizieren.
  • delete-config: Löscht den entsprechenden Data Store.
  • lock und unlock: Ein Gerät unterstützt möglicherweise mehrere NETCONF Sessions, die von verschiedenen Controllern eingeleitet werden. Vielleicht unterstützt es auch andere Konfigurationsmechanismen wie zum Beispiel CLI oder SNMP. Der Befehl lock verhindert, dass andere Konfigurationsquellen derzeit laufenden NETCONF-Anweisungen stören. Der Befehl unlock hebt lock auf und ermöglicht es anderen Quellen, mit dem Gerät zu interagieren. Locks oder Sperren sollten nur eine kurze Zeit vorhanden sein und zwar dann, wenn tatsächlich eine Operation vor sich geht.
  • close-session: Controller-Software öffnet in der Regel eine NETCONF-Verbindung zu einem Gerät und hält diese solange aufrecht, wie der Controller das Gerät verwaltet. Close-session schließt die Verbindung sanft, wenn der Controller nicht mehr länger auf das Gerät zugreift.

NETCONF und OpenFlow

Sowohl NETCONF als auch OpenFlow können einen Pfad zur Kommunikation zwischen Controller-Software und Geräten bereitstellen. Die Protokolle unterscheiden sich allerdings auf mehrere Arten. NETCONF ist ein Protokoll für die Konfiguration, während OpenFlow nur mit Flow-Tabellen arbeitet, die bestimmen, wie eintreffende Pakete geroutet werden. OpenFlow-Switches werden mittels OF-Config konfiguriert, das wiederum NETCONF verwendet, um mit den Geräten zu kommunizieren.

Das NETCONF-Protokoll lässt sich auf jede Gerätearchitektur anpassen. Dazu dient ein Satz optionaler Fähigkeiten. Entwickler können außerdem zusätzliche Funktionen erstellen. Auf diese Weise lassen sich NETCONF-Geräten sogar proprietäre Funktionen spendieren. OpenFlow schreibt hingegen eine spezielle Gerätearchitektur vor. OpenFlow-Geräte müssen zu einer Standardarchitektur konform sein und dürfen keine proprietären Funktionen enthalten. Somit können die Anbieter von White-Box-Switches entwickeln, die den OpenFlow-Standard befolgen. Es wird erwartet, dass sich die Verfügbarkeit solcher Geräte von der Stange sehr positiv auf die Kosten für das Netzwerk auswirkt.

OpenFlow-Switches unterstützen die Routing-Protokolle nicht, die Switches und Router in der Regel für die Bestimmung des Pfades im Netzwerk verwendet haben. Sämtliche Informationen über die Pfade der Pakete kommen vom Controller. NETCONF-Geräte könne solche Routing-Protokolle unterstützen. Setzen Software-defined Networks diese Protokolle noch weiterhin ein, verwaltet die Controller-Software einige Aspekte des Netzwerkbetriebs, während die Pfade für die Pakete weiterhin auf Geräteebene bestimmt werden.

OpenFlow oder NETCONF?

Nun stellt sich die Frage, ob Sie auf OpenFlow oder NETCONF setzen sollten? Pauschalisieren lässt sich das leider nicht, da Netzwerke grundsätzlich unterschiedlich sind. Einige Netzwerk-Administratoren werden weiterhin existierende Geräte verwenden, die mit NETCONF-Schnittstellen nachgerüstet wurden. Andere priorisieren möglicherweise die Preisvorteile der White-Box-Switches. Die Administratoren müssen einfach die Entwicklung von SDN verfolgen, da die Technologie immer noch am Reifen ist. Im Endeffekt sollten Sie immer auf Designs setzen und Produkte wählen, die Ihre Anforderungen am besten erfüllen.

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

Nächste Schritte

Fünf SDN-Protokolle neben OpenFlow

OpenFlow: Konfigurations-Protokolle OF-Config und OVSDB verstehen

Wie viele SDN-Programmiersprachen sollte man beherrschen?

White Box Networking bietet mehr Auswahl, aber nicht nur Vorteile

 

Erfahren Sie mehr über Software-defined Networking

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close