Zusammenfassung

  • RFC 9730 beschreibt kein Ablösungsmodell, sondern eine Arbeitsteilung: Netzwerkgeräte können weiterhin Topologie ermitteln, lokal Richtlinien anwenden, RSVP-TE-Signalisierung durchführen und Schutz- oder Wiederherstellungsaktionen auslösen, während zentrale Controller Dienste übersetzen, domänenübergreifend koordinieren und Pfade aus rohen, reduzierten oder abstrahierten Ressourcensichten berechnen.
  • Ein „erfolgreicher“ Wiederherstellungsvorgang besteht aus mehreren getrennten Behauptungen: Ein Controller kann eine Alternative akzeptiert oder berechnet haben, eine Domäne kann sie signalisiert haben, lokale Hardware kann umgeschaltet haben und der End-to-End-Dienst kann trotzdem noch nicht den erwarteten SLO erfüllen. Jede dieser Aussagen braucht eigene Evidenz.

RFC 9730, veröffentlicht im März 2025 als IETF Informational RFC unter dem Titel „Interworking of GMPLS Control and Centralized Controller Systems“, setzt an einem Problem an, das in Transportnetzen oft falsch vereinfacht wird. Zentralisierte Steuerung wird gern als Gegenmodell zu einem verteilten Control Plane verstanden. Der RFC beschreibt das Gegenteil: GMPLS und Controller-Hierarchien können gleichzeitig aktiv sein, mit unterschiedlichen Verantwortlichkeiten und unterschiedlichen Zeitachsen. Daraus entsteht keine rein technische Stilfrage, sondern eine Frage der Nachweisbarkeit betrieblicher Zustände.

Verteilte Kontrolle bleibt eine aktive Entscheidungsinstanz

Ein GMPLS-Netzelement ist im beschriebenen Modell kein passiver Ausführungsendpunkt. Es kann Knoten- und Linkzustände sammeln, daraus eine Topologie beziehungsweise Traffic Engineering Database ableiten, Routen unter lokalen Richtlinien berechnen und Labels über RSVP-TE Hop für Hop aushandeln. Diese verteilten Funktionen bleiben relevant, selbst wenn ein Controller einen Pfad auswählt oder vorrechnet.

Das ist wichtig, weil ein zentral berechneter Pfad nicht zwangsläufig bedeutet, dass jede einzelne Cross-Connect-Konfiguration von einem Controller geschrieben wird. RFC 9730 erlaubt, dass ein Controller einen Ingress-Knoten etwa über PCInitiate oder NETCONF anweist, einen bestimmten Pfad zu provisionieren. Danach kann die eigentliche Signalisierung innerhalb der GMPLS-Domäne zwischen den Netzelementen per RSVP-TE erfolgen. Der Controller hat in diesem Fall den Pfad angestoßen; das verteilte Control Plane realisiert ihn.

Damit zerfällt eine scheinbar einfache Handlung – „der Controller hat den LSP eingerichtet“ – in mehrere technische Schritte. Zuerst steht die Anfrage mit Bandbreite, Constraints und Policy. Dann folgt die Pfadauswahl. Danach muss der Ingress die Anweisung annehmen. Erst dann beginnen Path- und Resv-Nachrichten, Label-Zuweisungen und Cross-Connect-Programmierung. Ein Fehler kann an jedem dieser Punkte auftreten, ohne dass die anderen Stufen notwendig fehlerhaft sind.

ACTN vergrößert Reichweite, aber nicht automatisch Detailtiefe

RFC 8453 ordnet in einer ACTN-Architektur den Multi-Domain Service Coordinator (MDSC) zwischen Kunden- oder Serviceanforderungen und den Provisioning Network Controllern (PNCs) ein. Der MDSC übersetzt Servicewünsche, koordiniert mehrere Domänen und arbeitet mit abstrahierten Ressourcensichten. Ein PNC wiederum konfiguriert und überwacht Netzelemente und stellt dem MDSC rohe oder abstrahierte Topologieinformationen bereit.

Das MPI zwischen MDSC und PNC transportiert deshalb nicht nur Konnektivitäts- und Bandbreitenanforderungen. Es trägt auch jene Topologieabstraktion, die eine Domäne nach ihren Richtlinien offenlegen will. Ein globaler domänenübergreifender Graph kann damit gleichzeitig nützlich und absichtlich unvollständig sein. Er kann zeigen, welche Grenzpunkte miteinander verbunden werden können, ohne interne Knoten, konkrete Wellenlängen, Schutzgruppen oder alle lokalen Restriktionen offenzulegen.

Diese Abstraktion ist weder ein Fehler noch automatisch ein Risiko. Sie ist eine Governance- und Skalierungsfunktion. Operativ entsteht jedoch eine wichtige Konsequenz: Eine zentrale Pfadentscheidung ist nur so konkret wie die Sicht, auf der sie beruht. Ein MDSC kann einen domänenübergreifenden Pfad als gültig betrachten, während eine beteiligte Domäne intern noch prüfen muss, ob die konkrete Ressourcenkombination unter ihrer lokalen Policy tatsächlich verfügbar ist.

Drei Orte für Berechnung, mehrere Orte für Entscheidung

Pfadberechnung kann in dieser Architektur an unterschiedlichen Stellen stattfinden: im Controller, im Ingress auf Basis seiner TED oder in einem Path Computation Element. Auch hier ist die Unterscheidung zwischen Berechnen und Ausführen zentral. Beim klassischen PCE-Modell liefert der PCE einem PCC einen Pfad; der PCC entscheidet, ob und wann dieser Pfad eingesetzt wird. PCE-initiierte Verfahren können dagegen Aufbau, Pflege oder Abbau eines LSP selbst anstoßen.

Wer einen Audit-Trail für einen Dienst aufbauen will, muss deshalb erfassen, welche Instanz den Pfad berechnet hat, welche Instanz ihn freigegeben hat und welche Instanz die Signalisierung ausgelöst hat. Die Aussage „PCE-Berechnung erfolgreich“ beweist noch nicht, dass der Ingress den Pfad eingerichtet hat. Umgekehrt kann ein Ingress eine alternative Route aus eigener Sicht wählen, wenn die Architektur dies vorsieht.

Multi-Domain bedeutet nicht nur einen Signalisierungsweg

Domänenübergreifender Aufbau kann auf unterschiedliche Weise erfolgen. Ein End-to-End-RSVP-TE-LSP kann mehrere Domänen überspannen. Alternativ können domänenspezifische LSPs gestitcht werden, oder einzelne Segmente bleiben als getrennte Verbindungen organisiert. Inter-Domain-Labels können je nach Modell an Border Nodes oder durch Controller zugewiesen werden.

Aus Sicht des Betriebs ist daher die Frage „Ist der LSP oben?“ zu grob. Man muss wissen, welches Konstrukt gemeint ist: ein durchgehender signalisierter LSP, mehrere verbundene Segmente oder ein Dienst, dessen End-to-End-Konnektivität aus mehreren kontrollierten Teilstrecken entsteht. Die Evidenzkette unterscheidet sich entsprechend.

Zustände laufen auf verschiedenen Uhren

RFC 9730 behandelt rohe, reduzierte und abstrahierte Zustände, legt aber keine universelle Frischegrenze fest. Ein Netzelement kann einen Link bereits als ausgefallen sehen, während ein PNC die Änderung noch verarbeitet. Der PNC kann den Zustand bereits aktualisiert haben, während der MDSC noch mit einer älteren Abstraktionsversion arbeitet. Gleichzeitig kann ein Ingress eine eigene TED besitzen, deren Aktualisierung wiederum über einen anderen Mechanismus erfolgt.

Damit wird „Topologie aktuell“ zu einer relativen Aussage. Für belastbare Entscheidungen reicht es nicht, nur den Inhalt einer Topologiesicht zu kennen; man braucht ihre Version, ihren Zeitpunkt, die zugrunde liegende Policy und idealerweise die letzte bestätigte Änderungsfolge. Ein globaler Graph ohne Zeitbezug kann korrekt gewesen sein und inzwischen dennoch irreführend wirken.

Schutz und Wiederherstellung bilden einen Handoff

Bei Fehlern treffen lokale Reaktionsgeschwindigkeit und zentrale Reichweite besonders sichtbar aufeinander. RFC 9730 fügt für Span Protection keine neue universelle Anforderung hinzu. Eine zentrale Instanz kann disjunkte Schutzpfade berechnen oder vorbereiten, doch die schnelle Umschaltung kann weiterhin lokal durch Automatic Protection Switching oder GMPLS-Mechanismen wie Notify erfolgen.

Lokale Hardware oder ein benachbarter Knoten erkennt einen Fehler meist früher als eine hierarchische Controller-Kette. Ein Controller kann dagegen breitere Ressourceninformation einbeziehen und eine Alternative über mehrere Domänen oder sogar eine neue Domäne hinweg bestimmen.

Bei Fast Reroute sollte man daher drei Vorgänge trennen: berechnen, anlegen, umschalten. Ein Controller kann den Bypass oder eine Alternative berechnen. RSVP-TE kann den Schutzpfad aufbauen. Der Point of Local Repair (PLR) schaltet bei einem Ereignis den Verkehr um. Wer nur die Controller-Logs betrachtet, sieht möglicherweise eine korrekte Vorausberechnung, aber nicht den tatsächlichen lokalen Switch-Zeitpunkt.

RFC 4873 erweitert diese Perspektive auf Segment-Recovery: Ein Branch- oder PLR-Knoten kann einen unabhängigen Recovery-LSP bis zu einem Merge-Knoten aufbauen. Branch- und Merge-Punkte können dynamisch gewählt werden. Wenn eine solche Wiederherstellung nicht möglich ist, muss diese Unfähigkeit gemeldet werden. Damit wird lokale Autonomie explizit zu einem Bestandteil der Gesamtwiederherstellung, nicht zu einem Sonderfall außerhalb der zentralen Steuerung.

Wenn lokale Ressourcen nicht reichen

In einer Multi-Domain-Störung kann zunächst eine betroffene GMPLS-Domäne versuchen, lokal oder segmentweise umzuleiten. Reichen die Ressourcen nicht aus oder ist ein Inter-Domain-Link ausgefallen, kann das Ergebnis über den Controller der GMPLS-Domäne an den MDSC weitergegeben werden. Der MDSC kann dann eine domänenübergreifende Alternative berechnen und deren Einrichtung anstoßen, gegebenenfalls unter Einbeziehung einer anderen Domäne.

Das ist ein klassischer Handoff zwischen schnellen lokalen und weiter reichenden zentralen Mechanismen. Er ist aber kein einzelner atomarer Vorgang. Dazwischen liegen Fehlererkennung, lokale Entscheidung, Ressourcenprüfung, Meldung nach oben, Aktualisierung der abstrahierten Sicht, neue Pfadberechnung, Provisionierung und schließlich erneute End-to-End-Prüfung.

RFC 4426 hilft bei der Einordnung, weil es Wiederherstellungsebenen wie Span, Segment und End-to-End unterscheidet und gleichzeitige Mechanismen zulässt. Mehrere Schutzebenen können also parallel existieren. Das erhöht Robustheit, kann aber Folgeeffekte erzeugen: Preemption kann andere LSPs verdrängen, Reversion kann später erneut Verkehr verschieben, und eine zentrale Optimierung kann mit bereits lokal aktivierten Schutzpfaden interagieren.

Was als Beweis gelten sollte

Ein belastbares Betriebsmodell braucht deshalb eine Evidenzkette, die Entscheidungen und Wirkungen nicht vermischt. Auf Controller- und MDSC-Ebene gehören dazu die Serviceanforderung mit Constraints, die verwendete Version und Policy der abstrahierten Topologie, Antworten der PNCs, Annahmen zu Pfaden, Segmenten und Disjointness sowie die Bestätigung eines ausgelösten Reroute-Befehls.

Auf Domänenebene sind die rohe TED beziehungsweise die lokale Sicht, das Ergebnis lokaler Policy, der Eingang von PCInitiate- oder NETCONF-Anweisungen, RSVP Path/Resv- oder Fehlermeldungen, Label- und Cross-Connect-Programmierung sowie ein PCRpt-äquivalenter Zustand relevant. Für die lokale Wiederherstellung kommen Erkennungszeitpunkt, PLR beziehungsweise Branch und Merge, geschützter Bereich, Zustand eines Detours oder Bypasses, tatsächlicher Traffic Switch, Meldungen über Ressourcenmangel sowie Preemption und Reversion hinzu.

Erst danach folgt die entscheidende Kundenperspektive: Endpunkt-Erreichbarkeit, Performance und Nachweis am SLO-Rand. Ein erfolgreich quittierter Controller-Befehl belegt keine wiederhergestellte Kundensitzung. Ein erfolgreich signalisierter LSP beweist keine erwartete Latenz. Und eine lokale Umschaltung kann den Verkehr zwar retten, ohne dass die übergeordnete Abstraktion bereits den neuen Zustand kennt.

Verfügbarkeit der Steuerung ist selbst eine Entwurfsbedingung

RFC 9730 macht deutlich, dass bestehende Dienste und bereits eingerichtete Schutzmechanismen weiterarbeiten sollen, wenn ein zentraler Controller nicht verfügbar ist. Redundanz und Backup-Funktionen in Netzelementen sind deshalb wünschenswert. Das ist kein Argument gegen zentrale Steuerung, sondern eine Abgrenzung der Betriebsverantwortung: Ein temporärer Verlust der Orchestrierung darf nicht automatisch bereits etablierte Datenpfade oder lokale Schutzfunktionen außer Kraft setzen.

Gleichzeitig werden Controller zu hochwertigen Angriffszielen. Jede beteiligte Instanz braucht eigene Management-, Trust- und Security-Policies. Authentisierung, Autorisierung, Patch-Management, Monitoring und Schutz der Steuerungsinfrastruktur sind keine nachgelagerten Betriebsdetails. Je mehr ein Controller domänenübergreifend anstoßen kann, desto größer ist der mögliche Wirkungsradius falscher oder kompromittierter Anweisungen.

Grenzen des Dokuments

RFC 9730 definiert weder ein einzelnes Telemetrieprodukt noch ein universelles Konvergenzziel oder ein standardisiertes Beweisformat. Einige nicht-GMPLS-basierte Recovery-Verfahren liegen außerhalb seines Umfangs. Ebenso sollten benachbarte Standards nicht mit Recovery-Funktionen aus RFC 9730 gleichgesetzt werden: RFC 9731 behandelt ein YANG-Modell für virtuelle Netze, RFC 9732 die Ressourcenpartitionierung für Network Resource Partitions und RFC 9889 Aspekte der Realisierung von 5G Network Slices.

Sie können in angrenzenden Architekturen relevant sein, ersetzen aber keine Aussage darüber, wie ein konkreter GMPLS-/Controller-Handoff bei einer Störung tatsächlich ablief.

Der operative Kern lautet: In hybriden Steuerungsmodellen ist Zuständigkeit nicht identisch mit Sichtbarkeit, und Sichtbarkeit nicht identisch mit Wirkung. Wer nach einem Fehler nur fragt, ob „der Controller funktioniert hat“, stellt eine zu kleine Frage.

Quellen