Zusammenfassung

  • RFC 7149 macht aus Sicht eines Netzbetreibers Controller-Erreichbarkeit, Inbetriebnahme und Kontinuität zu Betriebsaufgaben – nicht zu automatischen Vorteilen der Trennung von Steuerung und Weiterleitung.
  • In einem Netz ohne IGP/BGP kann ein eigenes Bootstrap-Protokoll oder -Netz nötig sein. Das Memo verlangt, dessen Kosten mit einer Einbindung in das vorhandene Routing zu vergleichen. Bei Verlust der Verbindung zum Policy Decision Point (PDP) soll das darunterliegende Netz weiterarbeiten.
  • RFC 7149 hat den Status Informational: Es beschreibt eine Architekturperspektive und bedingte Anforderungen, aber weder einen Internet-Standard noch eine Bestandsaufnahme von Installationen oder einen tatsächlich eingetretenen Ausfall.

Die Trennung war nicht die ganze Geschichte

SDN wurde oft als klare Arbeitsteilung dargestellt: Die Steuerung entscheidet, die Weiterleitung setzt um. RFC 7149 warnte bei seiner Veröffentlichung im März 2014 davor, diese Darstellung für neu zu halten. Router kombinierten schon lange softwaregestützte Routingentscheidungen mit Hardware-Weiterleitung. Bedeutender war, Entscheidungslogik in eine logisch zentrale Instanz zu verlagern, die Netzkomponenten programmieren kann.

Dadurch entsteht eine praktische Abhängigkeit. Der Controller muss Geräte und Fähigkeiten entdecken, Richtlinien- und Dienstinformationen austauschen, Ressourcen zuteilen, Entscheidungen durchsetzen und Rückmeldungen über die erbrachte Leistung erhalten. RFC 7149 ordnet diese Arbeit vier Bereichen zu: Topologie- und Fähigkeitserkennung; Bereitstellung von Diensten und Aushandlung ihrer Parameter; dynamische Ressourcenzuteilung und Richtliniendurchsetzung; sowie Rückmeldung für Erfüllung und Qualitätssicherung.

So verbindet das Memo Netzwerkarchitektur mit dem Versprechen gegenüber Kunden. In seiner vorläufigen Definition ist ein Dienst nicht bloß ein vom Programm gewählter Pfad, sondern ein deterministisches Ergebnis, dessen Parameter mit dem Kunden verhandelbar sind. Das ist eine analytische Perspektive, keine allgemein übernommene SDN-Definition. Die Frage lautet damit nicht nur „Gibt es einen Controller?“, sondern „Kann der Betreiber den vereinbarten Dienst anbieten, liefern und nachweisen?“

Auch der Controller braucht einen Weg ins eigene Netz

Das Bootstrap-Problem macht die Abhängigkeit greifbar. In einem Netz ohne IGP oder BGP kann der Controller ein eigenes Protokoll oder Netz benötigen, um Geräte zu entdecken und zu konfigurieren. Dieser Kanal muss aufgebaut, geschützt, betrieben und erreichbar gehalten werden. Eine Integration der Entscheidungsinstanz in das bestehende Routing kann ein paralleles Bootstrap-Netz vermeiden, bindet das Design aber stärker an dessen Verhalten und Grenzen. RFC 7149 verlangt einen Kostenvergleich, statt eine Steuerungsanwendung über einem noch unkonfigurierten Netz vorauszusetzen.

Auch der Fehlerfall legt die Abhängigkeit offen. Für die betrachtete IGP/BGP-freie Umgebung fordert das Memo, dass das darunterliegende Netz beim Verlust der PDP-Verbindung weiterarbeitet. Es behauptet weder, jeder Controller-Ausfall stoppe den Verkehr, noch berichtet es von einem beobachteten Ausfall. Es formuliert eine bedingte Kontinuitätsanforderung: Wird die Entscheidungsinstanz getrennt, muss feststehen, was bei unterbrochener Kommunikation autonom weiterläuft.

Abgeschlossene Erkennung heißt noch nicht, dass ein Dienst bereitsteht. Der Controller kann Geräte inventarisiert haben, ohne Kundenparameter auszuhandeln, Richtlinien zu installieren, Ressourcen zu bestätigen oder Rückmeldungen zur Leistung zu erhalten. Wer diese Schritte trennt, verwechselt den Status „verbunden“ im Dashboard weniger leicht mit einem tatsächlich gelieferten Dienst.

Vom Architekturversprechen zum Betriebsnachweis

RFC 7149 setzt weder ein einziges Pflichtprotokoll noch einen einmaligen Umstellungstermin voraus. OpenFlow ist ein Werkzeug, nicht gleichbedeutend mit SDN; das Memo rechnet mit schrittweiser Einbindung in bestehende Netze und herstellerspezifische Systeme. Eine zentrale Entscheidungsinstanz sollte kein einzelner Ausfallpunkt werden und die Weiterleitung nicht beeinträchtigen. Das sind Architekturhinweise, kein Nachweis für ein konkretes System.

Für die historische Einordnung ist diese Grenze wichtig. Ein Informational-RFC kann eine Debatte ordnen und Fragen benennen, die Betreiber beantworten sollten. Er belegt nicht, wie viele Betreiber die Architektur einsetzten, welche Dienstqualität sie erreichten oder ob ein bestimmter Ausfall geschah. Dafür braucht es Installationsnachweise, Messungen, Betriebsberichte und Kundenergebnisse – nicht allein die Veröffentlichung des Memos.

Der bleibende Beitrag ist weniger ein neues Weiterleitungsverfahren als eine Verschiebung der Beweislast. Programmierbarkeit beseitigt weder Erreichbarkeit noch Beobachtbarkeit oder Rückfallverhalten; sie macht den Steuerungskanal selbst zum Teil des Dienstentwurfs. Bevor ein Betreiber fragt, was ein Controller befehlen kann, muss er zeigen, wie er ihn erreicht, was er prüfen kann und wie das Netz arbeitet, wenn der Rückweg zur Entscheidungsinstanz ausfällt.

Quellen