Zusammenfassung

  • RFC 9863 standardisiert die Ankündigung einer Farb-Fähigkeit und einen einzelnen 32-Bit-COLOR-TLV in einem PCEP-LSP-Objekt.
  • Dieser Wert kann einen Pfad kennzeichnen; er bescheinigt weder die gewählte Semantik noch Dienstlenkung, Qualität, Identität oder Wirkung.

Eine Farbe wirkt wie eine knappe Betriebszusage. Die RFC nennt als Beispiel einen für geringe Verzögerung optimierten TE-Tunnel. Standardisiert ist jedoch kein Verzögerungswert und kein Dienstversprechen, sondern ein vorzeichenloser Zahlenwert. Zwischen einer numerischen Kennzeichnung und einer Aussage über einen Dienst liegen mehrere getrennte Entscheidungen: Wer definiert die Bedeutung? Welche lokale Richtlinie verwendet sie? Welcher Dienst wird auf welchen Pfad abgebildet? Was geschieht in der Datenebene? Und welche Messung zeigt einen Effekt? RFC 9863 beantwortet diese Fragen nicht mit einem TLV.

Der gemeinsame und überprüfbare Teil beginnt bei der Fähigkeitenanzeige. Bit 20 im STATEFUL-PCE-CAPABILITY-TLV signalisiert COLOR-CAPABILITY. Danach kann der COLOR TLV vom Typ 67 und Länge 4 im LSP-Objekt erscheinen. An einen Peer ohne angekündigte Fähigkeit darf er nicht gesendet werden. Bei mehreren solchen TLVs wird nur der erste verarbeitet. Das macht Aussagen über Aushandlung und Syntax möglich. Es macht keinen lokal vergebenen Farbnamen zur universellen Dienstklasse.

Die Behandlung von SR Policy Associations hält dieselbe Grenze ein. Für SR-Pfade, die nach RFC 9862 mit einer SR Policy Association geführt werden, steht die Farbe bereits in der Association; dort hat sie Vorrang, und ein COLOR TLV im LSP-Objekt wird ignoriert. Diese Vorschrift löst einen Konflikt zwischen Kodierungen. Sie bestimmt weder einen Verkehrsstrom noch eine Kundenklasse und sie beweist nicht, dass die Richtlinie wirksam installiert wurde.

Auch PCErr-Antworten sind präzise, aber begrenzt. Kann ein PCC einen übergebenen Farbwert nicht einhalten, muss er Invalid Color melden. Ermittelt er widersprüchliche Farben für LSPs derselben Path Protection Association Group, muss er Inconsistent Color melden. Das sind belegbare Entscheidungen an einer Eingangsgrenze des Kontrollprotokolls. Eine erfolgreiche Nachricht belegt umgekehrt nur, dass diese Eingangsgrenze passiert wurde. Sie ersetzt keine Aufzeichnung über lokale Konfiguration, Dienstabbildung, Weiterleitung oder tatsächliche Leistung.

Die RFC lässt diese späteren Fragen ausdrücklich beim Betreiber. Der Mechanismus, mit dem Dienste auf farbige TE-Pfade abgebildet werden, liegt außerhalb ihres Geltungsbereichs. Ein PCC darf eine lokale Richtlinie für die Nutzung der Farbe haben. Implementierungen sollen die Konfiguration der Fähigkeit und der Farbzuordnung erlauben; ein Betreiber darf den operativen Zustand lesen, um die beabsichtigte Farbe zu prüfen. Neue Liveness-Überwachung schreibt die RFC nicht vor, und ihre Netzwerkwirkung hängt von der Bereitstellung ab. Ein ausgelesenes Attribut bleibt ein ausgelesenes Attribut.

Die Sicherheitsbetrachtung schließt eine weitere unzulässige Gleichsetzung aus. Ein unbefugter PCE kann einem LSP eine falsche Farbe zuordnen; die RFC verweist deshalb auf geschützten PCEP-Transport. Farbe ist weder Identitätsnachweis noch Autorisierung für einen Controller. Eine Führungsaussage über eine „gesicherte“ Dienstklasse braucht somit auch die Provenienz des PCE und die kontrollierende Richtlinie.

Heng Lus Unterscheidung zwischen gemeinsamer Spezifikation und freiwillig angenommener Betriebswirklichkeit verhindert die letzte Überdehnung. RFC 9863 stellt eine minimale, technisch prüfbare Koordinationsmöglichkeit bereit. Die spätere Bedeutung entsteht erst durch Implementierung, lokale Wahl, Gegenparteienakzeptanz und Beobachtung. Wer aus dem Feld einen Dienstschluss zieht, muss die fehlenden Glieder nachweisen statt sie mit Farbe zu übermalen.

Quellen