Zusammenfassung

  • Ein positiver PCRep belegt eine erfolgreiche Berechnung anhand einer bestimmten TED, bestimmter Constraints, einer Zielfunktion und einer Policy-Sicht. Er belegt keine Annahme oder Installation durch den PCC.
  • Für Signalisierung beziehungsweise Programmierung, Reservierung, RIB/FIB, LSP-Zustand, Paketfluss und SLA sind jeweils spätere, eigenständige Belege nötig.

Eine Route kann auf dem Bildschirm vollständig sein und im Netz trotzdem noch nicht existieren. Der Unterschied wirkt klein, solange alles funktioniert. Im Störungsfall entscheidet er darüber, ob ein Betreiber am Algorithmus, an der Policy, an der Signalisierung, am Gerät oder am Datenpfad sucht.

Genau diese Trennung steckt bereits in RFC 4655. Adrian Farrel verfasste das Dokument gemeinsam mit Jean-Philippe Vasseur und Jerry Ash für die IETF-PCE-Arbeitsgruppe. Ein Path Computation Element berechnet auf Basis eines Netzwerkgraphen und unter Constraints einen Pfad. In der externen PCE-Variante fragt der Headend-Knoten zunächst nach einer Berechnung und startet danach die Signalisierung. Der PCE nutzt die TED unter lokaler Policy und sendet eine Antwort zurück.

Berechnung und Ausführung sind architektonisch benachbart, aber nicht identisch.

Die TED ist ein Wissensstand

Die Traffic Engineering Database enthält Topologie- und Ressourceninformationen einer Domäne. Sie kann aus IGP-Erweiterungen, aus Out-of-Band-Synchronisation oder aus mehreren Quellen entstehen. Was sie enthält, ist das verfügbare Modell des Netzes.

RFC 4655 weist darauf hin, dass schwächere Synchronisation zu mehr fehlgeschlagenen oder suboptimalen berechneten Pfaden führen kann. Zwischen Berechnung und Einrichtung kann außerdem ein Link ausfallen oder Bandbreite anderweitig gebunden werden. Deshalb gilt eine Lösung immer relativ zu ihrem Informationszeitpunkt.

RFC 5440 von Vasseur und Jean-Louis Le Roux definiert die PCEP-Nachrichten. Ein PCReq beschreibt unter anderem Endpunkte, Bandbreite und Prioritäten. Constraints begrenzen die zulässigen Kandidaten. Eine Zielfunktion nach RFC 5541 legt fest, welcher Kandidat bevorzugt wird. Lokale Policy kann Anfrage, Auswahl und Antwort weiter beeinflussen.

Wer nur die ERO archiviert, verliert daher den Begründungszusammenhang. Für eine reproduzierbare Entscheidung gehören TED-Version, Constraints, Zielfunktion und Policy in denselben Nachweis.

Was „erfolgreich“ im PCRep bedeutet

Der positive Ablauf in RFC 5440 endet damit, dass der PCE die Pfadberechnung erfolgreich abgeschlossen und die berechneten Pfade an den PCC gesendet hat. Das Explicit Route Object codiert den berechneten TE-LSP-Pfad. Es steht anschließend für unmittelbare Signalisierung zur Verfügung.

Zur Verfügung stehen heißt nicht eingerichtet sein.

Bei RSVP-TE beginnt nun der in RFC 3209 beschriebene Signalisierungs- und Reservierungsvorgang. Knoten entlang des Pfades können die Einrichtung ablehnen. Bei Segment Routing trennt RFC 9256 Candidate Path und Segmentliste von der am Headend instanziierten SR Policy sowie vom hineingelenkten Verkehr. RFC 8664 überträgt SR-Pfadinformationen per PCEP, bestätigt aber keine FIB-Programmierung.

RSVP-TE und Segment Routing haben unterschiedliche Ausführungsmodelle. Gemeinsam ist ihnen, dass eine Pfadbeschreibung noch keine Beobachtung der Weiterleitung darstellt.

Stateful PCE verschiebt die Grenze nicht weg

Stateful-Erweiterungen bringen Zustandsabgleich, Updates und Delegation. RFC 8231 belässt die Eigentümerschaft am LSP-Zustand beim PCC. Attribute vom PCE unterliegen weiterhin der lokalen Policy des PCC. Eine Delegation erlaubt einem aktiven PCE, definierte LSP-Attribute zu ändern; der PCC kann sie pro LSP widerrufen.

Die spätere Statusquittung ist der PCRpt. Wird ein LSP Up oder Active, meldet der PCC dies. Scheitert die Einrichtung, meldet er Down und die Ursache. Der RFC betont, dass PCRep und PCRpt nicht direkt miteinander korrelieren und auf einen PCRep mehrere Zustandsmeldungen folgen können.

Ein Stateful PCE schafft also mehr Sichtbarkeit, nicht automatische Gewissheit. Auch ein nach RFC 8281 vom PCE initiierter LSP bleibt eine Aktion, deren Ergebnis der PCC und das Gerät bestätigen müssen.

Die Belegkette bis zum Dienst

Nach der Berechnung folgt die Annahme durch den PCC. Danach kommt der konkrete Signalisierungs- oder Programmiermechanismus. Nötige Ressourcenreservierungen und Einträge in RIB und FIB sind separat zu prüfen. Erst Zähler, Probes, Pfadverfolgung und Flow-Telemetrie zeigen, ob Pakete den erwarteten Weg verwenden. Latenz, Verlust, Jitter und Verfügbarkeit über ein definiertes Zeitfenster tragen schließlich eine SLA-Aussage.

Eine RIB ist keine FIB. Eine FIB ist kein Paketbeobachtungsnachweis. Ein Up-Status ist kein vollständiger Dienstnachweis. Diese Sätze beschreiben keine theoretischen Spitzfindigkeiten, sondern unterschiedliche Fehlerflächen.

In der Junos-PCEP-Dokumentation wird beispielsweise erklärt, dass der PCC nach empfangenen PCE-Attributen einen LSP neu signalisiert. Session, LSP-Zustand, SPRING-TE-Details und Routen werden mit verschiedenen Befehlen geprüft. Eine Paragon-Fehlerbeschreibung kennt den Fall, dass ein Auftrag bestätigt ist, der LSP aber Down bleibt, weil der PCC ihn nicht signalisieren kann. Das ist ein herstellerspezifisches Beispiel, kein universelles Protokollverhalten; die Trennlinie ist dennoch deutlich.

Farrels Anteil ohne Alleinzuschreibung

Farrels öffentliches IETF-Profil zeigt eine breite Standardisierungsarbeit. Für diese Analyse ist der gemeinsam mit Vasseur und Ash formulierte Architekturbeitrag entscheidend. Der PCEP-Basisstandard stammt von Vasseur und Le Roux. Stateful-Verfahren, Initiierung und SR-Erweiterungen wurden von weiteren Autoren und der Arbeitsgruppe entwickelt. Implementierer und Betreiber führen sie aus.

Die geteilte Zuschreibung folgt derselben Logik wie die Belegkette: Ein wichtiges Dokument ist nicht das gesamte Kontrollsystem, so wie eine berechnete ERO nicht der gesamte Dienst ist.

Quellenregister