Zusammenfassung

  • RFC 5376 transportierte Anforderungen über AS-Grenzen, ließ aber dem empfangenden PCE die lokale Auslegung und das Recht, Priorität, Bandbreite, Schutz oder Klassen zu ändern beziehungsweise die Anfrage abzulehnen.
  • Ein Pfadsegment-Bezeichner durfte interne Hops verbergen; er war ein Verweis auf ein Berechnungsergebnis und kein Nachweis für Signalisierung, Reservierung, Betrieb oder Zustellung.
  • Weil der Quell-PCC nachgelagerte PCEs nicht kennen musste, reichte die Authentisierung des direkten Peers nicht aus: Das besitzende AS brauchte einen überprüfbaren Zusammenhang zwischen lokal berechnetem Segment und später signalisierter Expansion.

Syntax wanderte, Zuständigkeit blieb lokal

Inter-AS-Berechnung soll verschiedene Netze verbinden, ohne ihre Verwaltung zu vereinheitlichen. Ein PCC kann gewünschte oder auszuschließende ASes und ASBRs nennen, einen Hop als zwingend oder nur bevorzugt markieren und Bandbreite, Schutz, Disjunktheit oder Diversität verlangen. Der Requesting-AS wird mitgegeben, damit der empfangende PCE seine lokale Richtlinie anwenden kann.

Damit reist eine Anforderung, nicht das Eigentum an der fremden Ressource. Der empfangende Betreiber darf ablehnen. Er kann Prioritäten, Bandbreite, Fast-Reroute-Eigenschaften, DS-TE-Klassen und weitere Parameter verändern. Eine Vorgabe, die in MPLS eine bekannte Umsetzung hat, kann in einem GMPLS-Bereich anders abgebildet werden müssen.

Der entscheidende Auditpunkt ist die Transformation. Das System sollte den angeforderten Wert, die lokale Interpretation, die entscheidende Stelle, die verwendete Policy-Version und den akzeptierten oder abgelehnten Wert festhalten. Speichert es nur das Endergebnis, sieht eine Entscheidung des Zielbereichs später wie die ursprüngliche Absicht des Absenders aus.

Eine Policy-Ablehnung ist nicht automatisch ein Protokollfehler. Sie kann beweisen, dass die Ressourcenkontrolle beim Eigentümer geblieben ist. Ebenso beweist die Authentisierung eines PCE-Peers dessen Identität im direkten Verhältnis, nicht seine Berechtigung, jede ausdrückbare Ressource oder Priorität zu verlangen.

Provenienz musste die Übersetzung überleben

Bei einer technischen Übersetzung genügt es nicht, dass das Ergebnis ausführbar ist. Es muss erkennbar bleiben, welche ursprüngliche Bedingung abgebildet wurde und welche Semantik verloren ging oder ergänzt wurde. Sonst kann ein späterer Beobachter einen abweichenden Pfad als Implementierungsfehler bewerten, obwohl er eine dokumentierte lokale Anpassung war.

Diese Herkunft gehört in die Berechnungsakte: anforderndes AS, Eingangswert, Zieltechnologie, Transformationsregel, lokaler Entscheider, Ausgangswert und Restunsicherheit. Eine neue Policy-Version darf ältere Entscheidungen nicht stillschweigend umdeuten. Sie kann eine Neuberechnung auslösen, muss aber die frühere Aussage in ihrem damaligen Kontext stehen lassen.

Auch die Kostenmetrik benötigt Provenienz. RFC 5376 erlaubt eine kumulierte Inter-AS-Pfadkostenangabe, nimmt aber die Normalisierung zwischen ASes ausdrücklich aus dem Umfang. Zwei Domänen können gleich benannte Zahlen für unterschiedliche Ziele und Skalen verwenden. Eine korrekte Summe erzeugt keine gemeinsame Einheit.

Wer Kandidaten nach dem Endwert sortiert, muss Zielgröße, Normalisierung, beteiligte Domänen und ausgelassene Beschränkungen belegen. Per-Domain-Verfahren können einen zulässigen Pfad liefern, ohne ein globales Optimum zu garantieren. „Optimal“ ist deshalb eine zusätzliche Behauptung, keine automatische Eigenschaft des PCE-Ergebnisses.

Der verborgene Abschnitt bekam einen Namen

Ein Betreiber muss interne Links, Kapazitäten, Schwachstellen und kommerzielle Entscheidungen nicht offenlegen, um an einer Ende-zu-Ende-Berechnung teilzunehmen. RFC 5376 erlaubte, ASes und ASBRs sichtbar zu machen, während interne Hops durch einen Pfadsegment-Bezeichner ersetzt werden.

Dieser Bezeichner schafft eine minimale gemeinsame Oberfläche. Der übergeordnete Rechner kann den Abschnitt in eine Komposition einsetzen, ohne seine innere Topologie zu kennen. Ein PCE kann wiederum andere Inter-AS- oder Intra-AS-PCEs um Beiträge bitten. Der Quell-PCC muss diese nachgelagerten Akteure nicht einmal sehen.

Was der Bezeichner beweist, bleibt eng. Ein PCE hat unter bestimmten Eingaben, Zustand und Richtlinie ein Segment berechnet und eine Referenz ausgegeben. Die Referenz belegt nicht, dass ein Signalisierungsprozess sie später benutzt hat, dass die Expansion unverändert blieb, dass Ressourcen reserviert wurden oder dass Datenverkehr floss.

RFC 5376 ist ein im November 2008 veröffentlichtes Informational-Anforderungsdokument für PCECP bei Inter-AS-MPLS/GMPLS. Die Expansion während der LSP-Signalisierung lag außerhalb seines Umfangs. RFC 5440 spezifizierte später PCEP, RFC 5520 Path Keys. Hierarchische und stateful PCEs sowie TLS erweiterten die Architektur, ohne Berechnung und Ergebnis zu verschmelzen.

Vertraulichkeit verlangte eine lokale Gegenprobe

Wenn der Quell-PCC die internen Hops nicht kennt, kann er nicht prüfen, ob eine spätere Expansion dem ursprünglichen Abschnitt entspricht. RFC 5376 fordert deshalb einen Mechanismus, der sich in der zugehörigen Signalisierung widerspiegelt und dem AS die Prüfung ermöglicht, ob der signalisierte Pfad zum Segment seines lokalen PCE passt.

Angenommen, Domäne B vergibt K für einen Abschnitt mit einem zwingenden Ausgang, definierter Bandbreite und Schutz. Zwischen Berechnung und Aufbau ändert sich eine Richtlinie oder ein altes Cache-Ergebnis wird verwendet. K kann nun in andere Hops aufgelöst werden, während der externe Beobachter weiterhin nur K sieht. Ohne Prüfung könnte eine unbemerkte Substitution als erfolgreicher Aufbau erscheinen.

Die zuständige Prüfstelle liegt in B. Dort sind sowohl die verborgene Berechnung als auch die Expansion bekannt. Sie kann K, Berechnungskontext, Topologie- und Policy-Version, Zeitpunkt und Ergebnis der Gegenprobe binden. Nach außen muss sie nicht den Pfad verraten; ein begrenztes Konformitätsurteil genügt.

Damit wird Geheimhaltung nicht zur Ausrede für fehlende Rechenschaft. Je weniger ein externer Akteur sehen darf, desto präziser muss der interne Eigentümer den Übergang bestätigen. Der Bezeichner sollte außerdem widerrufbar und zeitlich begrenzt sein, weil ein alter Netzstand kein ewiges Versprechen ist.

Eine kooperative Kette war keine automatische Vertrauenskette

PCE-Peers sollen Identitäten authentisieren, Daten prüfen und sensible Kommunikation verschlüsseln. Schlüsselverteilung über AS-Grenzen muss die Grundsätze aus RFC 4107 berücksichtigen. Diese Sicherungen schützen die tatsächlich aufgebaute Peer-Beziehung, nicht unbekannte Teilnehmer kraft Vererbung.

Der Quell-PCC authentisiert vielleicht PCE A. A verwendet B, B einen lokalen Rechner C. Die sichere Sitzung mit A attestiert nicht automatisch die Entscheidungen von B und C. Eine Vertrauenskette ist wünschenswert, nach den Anforderungen aber nicht immer erreichbar.

Der Nachweis sollte daher Transportpeer und sachliche Entscheidungsinstanz trennen. Wo Namen nicht offenbart werden dürfen, kann zumindest die verantwortliche AS-Grenze und der Umfang der verborgenen Mitwirkung festgehalten werden. „Authentisierter PCE“ darf nicht zur Beschreibung der gesamten unsichtbaren Kette werden.

Policy-Objekte können für das Transportprotokoll undurchsichtig sein. Benötigt ihr Inhalt stärkere Herkunfts-, Integritäts- oder Berechtigungsprüfung, muss die verstehende Policy-Komponente sie durchführen. Ein geschützter Umschlag kann keine Semantik genehmigen, die er nicht interpretiert.

Sechs Nachweise statt eines Gesamtstatus

Eine belastbare Betriebsakte trennt mindestens:

  1. Request: Endpunkte, anforderndes AS, gewünschte oder ausgeschlossene AS/ASBR, Pflichtmerkmale, Bandbreite, Schutz und Diversität;
  2. Policy: lokale Autorität, angenommene Werte, Änderungen, Übersetzungen und Ablehnungsgrund;
  3. Berechnung: Zustandsversion, offenlegbare PCE-Beiträge, explizite Hops oder undurchsichtige Segmente;
  4. Konformität: Prüfung des besitzenden AS, dass die Signalisierung genau das berechnete Segment expandierte;
  5. Aufbau: Signalisierung, Reservierung, Labels und realer LSP-Zustand;
  6. Wirkung: Forwarding-Beobachtung, Qualität, Empfang und Anwendungsbestätigung.

Eine erfolgreiche PCE-Antwort deckt nicht automatisch die letzten Stufen ab. Ein korrekt berechneter Pfad kann beim Aufbau scheitern. Ein aufgebauter LSP kann später ausfallen. Ein technisch zugestelltes Paket kann von der Anwendung abgelehnt werden. Ein grüner Gesamtstatus löscht diese Kausalität.

Getrennte Nachweise machen Änderungen reversibel. Eine Domäne kann eine Referenz zurückziehen, nach einer Störung neu rechnen, einen geänderten Vorrang ablehnen oder einen Peer-Schlüssel drehen. Frühere Entscheidungen behalten ihren damaligen Wahrheitsbereich, statt nachträglich als umfassender Fehler umgeschrieben zu werden.

Der sichere Umfang der Aussage

Die Quellen belegen Anforderungen und Protokollentwicklung. Sie belegen keine heutige Implementierung eines konkreten Providers, keinen Vertrag, keinen Vorfall, keine gemessene Leistung und keine Zustellung. Aus einem Path Key darf auch nicht auf die verborgenen Hops geschlossen werden.

Die belastbare Schlussfolgerung ist institutionell: Inter-AS-Automatisierung bleibt eine Zusammenarbeit eigenständiger Autoritäten. Der Absender formuliert eine Absicht, jede Domäne interpretiert sie, ein PCE berechnet, die Signalisierung versucht den Aufbau, der Eigentümer prüft die verborgene Expansion und der Betrieb beobachtet die Wirkung.

Das ist weder vollständige Offenlegung noch eine unkontrollierte Blackbox. Es ist überprüfbare Abstraktion. Ein kleiner, zuordenbarer Verweis trägt nur so viel Bedeutung, wie die zuständige Instanz tatsächlich bestätigen kann.