Summary

  • RFC 9933 macht SR-Algorithm in PCEP-Routen und Berechnungsanforderungen sichtbar. Für Werte von 128 bis 255 muss der PCE zusätzlich eine Flexible Algorithm Definition auswählen und deren Metrik, Constraints, teilnehmende Knoten sowie Topologiedaten anwenden. Dieselbe Nummer beweist deshalb keine unveränderte Policy.
  • Nachvollziehbarkeit braucht einen Policy-Auflösungsbeleg: Er bindet die Nummer an die damals gewinnende FAD, deren Urheber und Scope, das Metrikwörterbuch, die Objective Function, gelockerte Objekte, die geordnete Pruning-Regelversion und einen TED-Digest. Vertrauliche Netzdetails können geschützt bleiben.

In einem Störungsbericht steht vor und nach einer Umleitung derselbe Wert: SR-Algorithm 130. Die PCEP-Sitzung war authentisiert. Beide Peers hatten die Fähigkeit angekündigt. Die Segmentlisten waren syntaktisch korrekt. Für das Dashboard hat sich nichts an der Policy geändert, denn das sichtbare Etikett blieb gleich.

Tatsächlich kann zwischen beiden Zeitpunkten eine FAD mit höherer Priorität gewonnen haben. Sie kann eine lokale Kostenmetrik statt Verzögerung verwenden, eine neue Rückwärts-Affinität ausschließen oder einen Bandbreitenschwellwert ändern. Ein Router, der ein Element nicht unterstützt, kann daraufhin die Teilnahme beenden. All das ist möglich, ohne Algorithmus 130 umzubenennen.

Die Nummer lügt nicht. Sie sagt nur weniger aus, als ihr das Berichtswesen zuschreibt.

RFC 9933 standardisiert, wie PCEP den zu einem SID gehörenden SR-Algorithm übermittelt, eine SR-Algorithm-Bedingung anfordert und weitere Pfadmetriken ausdrückt. Das Protokoll beschreibt Aushandlung, Fehlerfälle und operative Sichtbarkeit genau. Bei Flexible Algorithms wird die vollständige Policy aber aus Zuständen ermittelt, die nicht in der einzelnen Anfrage stecken.

Diese Trennung ist technisch sinnvoll. Ein kurzer Schlüssel kann eine komplexe, verteilte Definition aufrufen. Institutionell wird daraus ein Problem, sobald der Schlüssel als dauerhafter Beweis für den Inhalt gilt.

Was RFC 9933 auf der Leitung festhält

RFC 9933 erschien im Juli 2026 als IETF Standards Track RFC und aktualisiert PCEP-Erweiterungen für Segment Routing mit MPLS und IPv6. Ein Algorithm-Feld kann in SR-ERO- und SR-RRO-Subobjekten sowie deren SRv6-Varianten vorkommen. Im LSPA-Objekt kann ein SR-Algorithm TLV die gewünschte Berechnung einschränken. Hinzu kommen PCEP-Metriktypen für minimale Verzögerung, Bandbreite und benutzerdefinierte Werte.

Die Nutzung ist abgesichert. Beide Sprecher müssen Unterstützung angekündigt haben. Ohne diese Aushandlung führt der Versuch zu einem Invalid-Operation-Fehler. Inkonsistente Längen machen ein Objekt ungültig. Ein unbekannter SID erzeugt einen festgelegten Fehler. Kann der PCE die Constraint-Kombination nicht erfüllen, muss er ein leeres ERO oder NO-PATH liefern, statt unbemerkt eine schwächere Berechnung auszuführen.

Damit lässt sich beweisen, dass die Peers die Erweiterung beherrschten, die Nachricht gültig war und Fehlschläge nicht als Erfolg ausgegeben wurden. Nicht bewiesen ist, welche Policy-Version die Nummer im fraglichen Moment bezeichnete.

Die Werte 0 und 1 sind als SPF und Strict-SPF registriert. 2 bis 127 bilden einen Standardisierungsbereich. 128 bis 255 stehen für Flexible Algorithms. In diesem Bereich stammt die Bedeutung aus einer Betreiberdefinition, nicht aus der Zahl selbst.

„SR-Algorithm 130“ ist daher eine korrekte Adresse. Ohne Zeit, Scope und Zielversion ist es noch kein vollständiger Quellenverweis.

Die Wahl der gewinnenden FAD ist Teil der Entscheidung

RFC 9350 definiert eine Flexible Algorithm Definition, FAD, als Kombination aus Calculation Type, Metric Type und Constraints. Eine Zahl zwischen 128 und 255 wird per Konfiguration mit dieser Kombination verbunden.

Mehrere Router können für dieselbe Zahl unterschiedliche Definitionen ankündigen. Die Teilnehmer wählen deterministisch: Zuerst zählt die numerisch höchste Priorität. Bei Gleichstand gewinnt die Ankündigung des numerisch größten IS-IS System-ID beziehungsweise OSPF Router ID. RFC 9350 nennt das Ergebnis „winning FAD“.

Das Verfahren schafft Konsistenz im verteilten System. Zugleich macht es sichtbar, dass die Policy-Auflösung von der Menge der Ankündigungen, ihren Prioritäten, Urhebern und Tie-Break-Daten abhängt. Eine neue, höher priorisierte Ankündigung kann den Inhalt hinter 130 vollständig austauschen.

Bemerkenswert ist auch, dass ein Router eine FAD ankündigen darf, ohne selbst an diesem Flexible Algorithm teilzunehmen. Policy-Definition und Ausführung lassen sich organisatorisch trennen. Wer Ankündigungen erzeugen und Prioritäten setzen darf, verfügt deshalb über eine Steuerungsmacht, die in der Algorithmusnummer nicht erkennbar ist.

Unterstützt ein Knoten ein Element der gewinnenden FAD nicht, muss er die Teilnahme einstellen und den zugehörigen Forwarding State entfernen. Eine Definitionsänderung kann netzweite Neuberechnung und Konvergenz auslösen. Die Norm sorgt für kohärentes Verhalten nach der Änderung; sie dokumentiert nicht automatisch die Freigabe, die Absicht oder die Befristung der Änderung.

Wer einen früheren Pfad prüft, braucht die damaligen Kandidaten, die Wahlbeweise und den Gültigkeitszeitraum. Die heute sichtbare FAD ist dafür kein Ersatz.

Die Zahl besitzt keinen globalen Sinn

Der FAD-Scope ist ein Gebiet. RFC 9350 verlangt ausdrücklich nicht, dass dieselbe Flexible-Algorithm-Nummer in allen Gebieten gleich definiert ist. Ein Gebiet kann auf Verzögerung optimieren, ein anderes auf verfügbare Bandbreite.

Diese Lokalität erlaubt passende Betriebsentscheidungen. Sie macht aber zentrale Übersichten problematisch, die jede 130 gleich einfärben. Der minimale Name lautet nicht „130“, sondern „130 in Gebiet X, während Policy-Epoche Y“.

Eine Zahl ohne Scope ähnelt einem Paragraphen ohne Rechtsordnung. Der Verweis kann formal richtig und inhaltlich unbrauchbar sein. IS-IS-Level, OSPF-Area und Reichweite der Ankündigung gehören zur Semantik.

RFC 9933 erklärt die Verwendung unterschiedlicher SR-Algorithm-Constraints oder unterschiedlicher gewinnender FAD-Metriken in Teilen einer einzigen Ende-zu-Ende-Berechnung für außerhalb seines Umfangs. Ein organisationsweites Audit sollte diese Grenze nicht durch Aggregation verwischen. Es muss jede Domänenauflösung gesondert erfassen.

Governance muss lokale Unterschiede nicht beseitigen. Sie muss verhindern, dass lokale Gültigkeit als globale Gleichheit ausgegeben wird.

Eine gespeicherte Anfrage ist noch keine reproduzierbare Entscheidung

Für Flexible-Algorithm-Werte verlangt RFC 9933, dass der PCE seine Traffic Engineering Database verwendet. Darin sollen FADs, Knotenteilnahme und anwendungsspezifische Linkattribute enthalten sein. Sie können über IGP-Erweiterungen oder Verfahren wie BGP-LS aus RFC 9552 einfließen.

Der Pfad hängt also von der Anfrage und von einem veränderlichen Evidenzbestand ab.

Bei der Optimierungsmetrik ist die Hierarchie eindeutig. Der PCE muss die Metrik aus der FAD verwenden. Eine Optimierungsmetrik in der PCEP-Nachricht des PCC wird bei Flexible Algorithms ignoriert. FAD-Constraints und direkt gesendete PCC-Constraints werden zusammen angewendet, wobei der PCC die FAD-eigenen Bedingungen nicht in die Anfrage kopieren soll.

Diese Aufteilung verhindert doppelte oder widersprüchliche Policy. Sie bedeutet zugleich, dass identische PCReq-Bytes zu einem späteren Zeitpunkt nicht dieselbe Entscheidung reproduzieren müssen. Gewinnende FAD, TED, Teilnehmer oder Regeln können sich geändert haben.

Anfrage und Antwort können als Kommunikationsprotokoll vollständig und als Entscheidungsakte unvollständig sein. Der fehlende Teil ist die damalige Auflösungsumgebung.

Lokale Metriken enthalten Wertentscheidungen

RFC 9843 erweitert FADs um Bandbreiten- und Verzögerungsbedingungen, automatische Bandbreitenmetrik und generische Metriken. Die Typen 128 bis 255 können Betreiber lokal definieren.

Damit lassen sich finanzielle Kosten, Jitter, Energiebelastung oder vertragliche Risiken ausdrücken, ohne für jede Bedeutung einen globalen Standard abzuwarten. Doch „Metric Type 130“ verrät weder Einheit noch Formel. RFC 9843 weist darauf hin, dass Gebiete oder Level demselben benutzerdefinierten Typ dieselbe Bedeutung geben sollten, wenn er ihre Grenzen überschreitet.

Auch die standardisierte Bandbreitenmetrik enthält Policy-Parameter. Ein explizit angekündigter Wert überschreibt die automatische Ableitung. Fehlt er, kann die gewinnende FAD Referenzbandbreite oder Schwellenwerte vorgeben. Ändert man diese zentralen Parameter, ändern sich Linkkosten und Pfade, obwohl SR-Algorithm 130 unverändert bleibt.

Eine Metrik ist deshalb keine neutrale Zahl. Die Entscheidung, Verzögerung, Kapazität, Geld oder Risiko zu gewichten, verteilt Infrastruktur und Ausfallreserven. Das Wörterbuch ist ein Governance-Artefakt.

Für lokale Typen müssen Eigentümer, Einheit, Normalisierung, Version und Scope erhalten bleiben. Für Ableitungen gehören Methode, Parameter, Eingabepriorität und Quelldaten dazu. Ohne Semantik reproduziert man bestenfalls die Rechnung, nicht die begründete Wahl.

Auch die Reihenfolge des Prüfers hat eine Version

Flexible Algorithms bewerten nicht nur Links; sie entfernen Links, die Constraints verletzen. RFC 9917 schuf dafür das IANA-Register „IGP Flex-Algorithm Path Computation Rules“ als geordnete Liste.

Das IANA-Register für IGP Parameters enthält derzeit zehn Prüfungen. Sie behandeln ausgeschlossene Administrative Groups, SRLGs, Include-any und Include-all, fehlende Metriken, Bandbreiten- und Verzögerungsgrenzen sowie Attribute der Rückrichtung. Neue Regeln können per Expert Review folgen; eine feste Obergrenze gibt es nicht.

Damit ist der Auswerter selbst zeitabhängig. Zwei Softwarestände können bei gleicher FAD und ähnlichem TED verschiedene Regelkontexte besitzen. RFC 9933 verlangt einen Fehlschlag, wenn eine Kombination nicht unterstützt wird. Ein NO-PATH ohne Regelversion und Eliminierungsgrund erklärt dennoch nicht, welche Bedingung den letzten Kandidaten entfernte.

Automatisierte Governance archiviert oft Eingang und Ausgang, aber nicht den Interpreter. Reproduzierbarkeit braucht Faktenstand, Policy-Version und Evaluator-Version. Die sichtbare Algorithmusnummer bezeichnet nur den Einstieg in dieses System.

Objective Function und SR-Algorithm bleiben getrennt

RFC 5541 definiert Objective Functions für PCEP. Ein PCC kann eine Funktion verbindlich fordern oder nur wünschen. Bei einem Wunsch darf der PCE nach lokalen Fähigkeiten und Regeln eine andere Funktion verwenden.

RFC 9933 stellt klar, dass SR-Algorithm die Objective Function nicht ersetzt. Auch Metric Type ist keine andere Bezeichnung für den Algorithmus. Die FAD begrenzt den gültigen Raum; die Metrik bewertet Links; die Objective Function wählt zwischen Kandidaten; das TED liefert die aktuellen Tatsachen.

RFC 9753 regelt zusätzlich die optionale Verarbeitung bestimmter PCEP-Objekte in Stateful-Sitzungen. Wenn beide Peers dies unterstützen, kann ein Objekt ignoriert und diese Tatsache zurückgemeldet werden. Ein Pfad, der alle Bedingungen erfüllt, hat einen anderen Entscheidungsstatus als einer, der erst nach Lockerung eines optionalen Objekts möglich wurde.

Das YANG-Modell aus RFC 9826 macht PCEP-Entitäten, Peers, Sitzungen, Benachrichtigungen und Statistiken verwaltbar. RFC 9933 empfiehlt außerdem Sichtbarkeit von Fähigkeit, FADs und teilnehmenden Knoten. Sichtbarkeit ermöglicht Beweiserzeugung, garantiert aber keine historische Aufbewahrung.

TLS schützt die Nachricht, nicht die Bedeutungsepoche

RFC 9933 empfiehlt TLS für PCEP; RFC 9916 aktualisiert das PCEPS-Profil für moderne TLS-Versionen. Ohne authentisierten Transport könnten Constraints manipuliert oder Controller imitiert werden.

Eine authentisierte Anfrage kann trotzdem gegen eine eben geänderte, ordnungsgemäß veröffentlichte FAD laufen. TLS belegt Absender und Transportintegrität. Es belegt nicht, wer Priorität 200 genehmigte, wann eine Notfalldefinition enden sollte oder welche Semantik die lokale Metrik trug.

Kryptografische Integrität und Policy-Provenienz sind komplementär. Der sichere Umschlag schützt die Nachricht; er erklärt nicht die Regel, die der Empfänger darauf anwendet.

Ein Beleg für die Policy-Auflösung

Die Antwort ist nicht, komplette Topologien und Change-Protokolle in PCEP einzubauen. Netzstruktur, Kosten und Risikogruppen sind sensibel; das Protokoll muss effizient bleiben. Eine begleitende Evidenzschicht kann öffentliche Digests mit geschützten Details verbinden.

Ein Auflösungsbeleg sollte Anforderungs-ID, PCE/PCC, Zeitpunkt und Scope enthalten; SR-Algorithm und Fundstelle; normalisierte gewinnende FAD samt Hash; Urheber, Priorität, Tie-Break und Gebiet; Metriksemantik oder Ableitungsparameter; Objective Function und Verbindlichkeit; direkte Constraints und ignorierte Objekte; geordnete Regel- und Implementierungsversion; TED-, Teilnehmer- und Fähigkeitsdigest; ERO, leeres ERO oder NO-PATH samt Grund; Change Ticket, genehmigende Rolle, Aktivierungsfenster, Rollback-Kriterium und Prüfdatum.

Eine organisationsweite Ansicht kann sich auf Hashes, Versionen, Grundklassen und Verwahrung beschränken. Autorisierte Prüfer lösen diese Verweise gegen geschützte Bestände auf. Auditierbarkeit verlangt kontrollierte Nachweisbarkeit, nicht grenzenlose Offenlegung.

Der Beleg trennt außerdem Faktenänderung und Policy-Änderung. Ein Linkausfall verändert einen Pfad bei gleicher Regel. Eine neue FAD verändert ihn bei ähnlicher Topologie. Ohne beide Versionen wird eine menschliche Steuerungsentscheidung leicht als spontane Netzreaktion erzählt.

Sources