Zusammenfassung

  • RFC 5330 überträgt die Zahl der mit Bandbreite null signalisierten TE-LSPs. Die Spezifikation legt nicht fest, welcher einzelne Populationswechsel eine neue LSA oder ein neues IS-IS-LSP auslöst, und warnt vor systematisch zu hoher Flooding-Granularität.
  • Ein aktuelles Protokollobjekt kann daher eine geschwellte oder gebündelte Sicht enthalten. Vergleichbar wird der Wert erst mit Triggerpolitik, Berechnungszeit, Populationseinschluss und zulässigem Staleness-Budget.

Zwei Uhren wurden zu einer Ampel

Stellen wir uns vor, zehn LSPs werden innerhalb einer Minute aufgebaut und wieder verlegt. Der Originator veröffentlicht den RFC-5330-Wert erst, wenn eine Schwelle überschritten wird oder ein Timer abläuft. Kurz danach trifft eine neue LSA ein. Das Dashboard markiert den Wert als „live“, weil Age und Sequenz aktuell sind.

Die Anzeige verwechselt zwei Uhren. Die erste gehört zum Protokollobjekt: Wann wurde diese LSA oder dieses LSP erzeugt und beobachtet? Die zweite gehört zur Population: Bis zu welchem Ereignis wurde der Zähler neu berechnet, welche Änderungen wurden gebündelt und welche warten noch?

RFC 5330 definiert den Zähler, lässt aber die Originationstrigger außerhalb seines Umfangs. Zugleich mahnt es, bei Änderungen der LSP-Zahl nicht systematisch mit zu hoher Granularität neue IS-IS-LSPs oder OSPF-LSAs zu fluten.

Eine frische Hülle kann also eine bewusst gröbere Sicht tragen. Das ist nicht automatisch ein Fehler. Es ist eine Eigenschaft, die der Verbraucher kennen muss.

Der Zähler misst eine Signalpopulation

Als Unconstrained TE LSP bezeichnet das RFC einen TE-LSP, der mit einer Bandbreite von null signalisiert wurde. Null ist der Wert der Signalisierungsanforderung, nicht das gemessene Verkehrsvolumen.

Der motivierende Einsatz kombiniert solche LSPs mit MPLS TE Fast Reroute. Verkehr kann dem kürzesten IGP-Pfad folgen und bei einem lokalen Ausfall umgeleitet werden. Ein LSP ohne Bandbreitenreservierung kann daher Bytes transportieren, physische Kapazität beanspruchen und geschäftskritische Dienste tragen.

Auch ein perfekt zeitnaher Zähler bleibt eine Anzahl von Pfaden, keine Rate. Zwei Intervalle mit demselben Wert können völlig unterschiedliche Last haben. Ein einzelner LSP kann mehr Verkehr tragen als viele andere zusammen.

Für Last braucht man Paket- und Bytezähler, Messfenster und Zuordnung. Für Schutz braucht man Haupt-/Backup-Beziehungen und Tests. Die Zeitnähe des RFC-5330-Felds verleiht ihm keine dieser Bedeutungen.

Die Population kann sich ohne LSP-Ereignis ändern

RFC 5330 erlaubt, über ein Managementsystem konfigurierte und provisionierte Unconstrained TE LSPs aus dem gemeldeten Wert auszuschließen.

Wechselt eine Softwareversion diese Einschlusspolitik, kann der Zähler springen, obwohl kein LSP aufgebaut oder entfernt wurde. Die Protokollfrische ist dann ausgezeichnet: Das neue Objekt meldet sofort die neue Politik. Als Netztrend wäre die Differenz dennoch falsch interpretiert.

Jede Beobachtung braucht deshalb einen Populationsvertrag. Er beschreibt einbezogene Provisionierungsquellen, qualifizierende Signalisierungszustände, Make-before-break-Überlappung, Eintritt und Austritt, Behandlung verwalteter LSPs, Software- und Konfigurationsversion sowie Aktivierungszeit.

Ein Politikwechsel erzeugt eine semantische Epochengrenze. Vorher und nachher können beide Werte korrekt sein, ohne direkt vergleichbar zu sein.

Triggerpolitik ist Teil der Herkunft

Ein belastbarer Count Receipt enthält mehr als Wert und Timestamp. Er nennt die Triggerart: pro Ereignis, nach Schwelle, per Timer, bei Refresh oder als Kombination. Er enthält das letzte Populations-Recompute, das Aggregationsfenster und den maximal tolerierten Rückstand.

Diese Metadaten müssen nicht im RFC-5330-sub-TLV stehen. Sie gehören zur lokalen Betriebsprovenienz. Genau weil das gemeinsame Protokoll sie nicht erzwingt, muss die Plattform sie neben dem Wert verwalten.

Ein Consumer kann dann entscheiden, ob eine Sicht für seinen Zweck aktuell genug ist. Eine Kapazitätsanalyse kann Minuten tolerieren; eine automatische Reoptimierung vielleicht nicht. Das gleiche Feld erhält keine universelle Frische allein durch sein Age.

Fehlt die Triggerpolitik, ist fresh=true lediglich eine Aussage über den Container.

Ein fehlendes Feld ist keine schnelle Null

Das sub-TLV ist optional. Seine Abwesenheit soll laut RFC 5330 als fehlende Information über den Link verstanden werden.

Wenn eine neue LSA ohne type 23 eintrifft, darf das Dashboard nicht folgern, der Zähler sei aktuell auf null gefallen. Die Nachricht ist frisch; die Information ist nicht vorhanden. Gerade die hohe Frische macht eine erfundene Null nicht richtiger.

Das Datenmodell muss präsent-null, präsent-positiv, abwesend, fehlerhaft, nicht unterstützt und nicht beobachtet unterscheiden. Bei Abwesenheit kann ein letzter Wert mit klarer Beobachtungszeit und Ablaufgrenze angezeigt werden, aber nicht als aktuelle Messung.

Eine Lücke ist ein gültiger Befund. Sie mit null zu schließen, verwandelt Sichtverlust in scheinbare Entlastung.

Bei Duplikaten entscheidet die Reihenfolge

RFC 5330 verwendet type 23 sowohl für IS-IS als auch für OSPF. Der IS-IS-Wert umfasst zwei Oktette; der OSPF-Wert vier. In beiden Fällen darf das sub-TLV im betreffenden Container nicht mehrfach vorkommen. Erscheint eine zweite Instanz, verarbeitet der Empfänger nur die erste.

Ein generischer Decoder mit Last-write-wins kann aus 31 gefolgt von 36 den Wert 36 speichern, während der Router 31 verwendet. Der später wirkende Wert ist nicht der gültigere Wert.

Der Parse Receipt muss Protokoll, Container, Offsets, Längen, geordnete Instanzen, ausgewählte erste Instanz und Ignoriergrund bewahren. Sonst kann eine moderne, zeitnahe Telemetrie einen anderen Zustand anzeigen als der Empfänger.

IANA koordiniert die Bedeutung des Codepoints. Das Register beweist weder die empfangene Reihenfolge noch die Entscheidung einer konkreten Implementierung.

Statistische Eingabe ist kein Ergebnis

In symmetrischen Topologien mit Equal-Cost-Pfaden ist reservierbare Bandbreite kein hilfreicher Tie-Breaker für LSPs, deren Bandbreitenanforderung null ist. Das RFC erläutert, dass Algorithmen unter statistischen Annahmen über aggregierten Verkehr die LSP-Zahl nutzen können.

Die Algorithmen selbst liegen ausdrücklich außerhalb des RFC. Es legt weder Gewichtung noch Reoptimierungszeitpunkt noch zulässige Staleness fest.

Ein Decision Receipt muss deshalb Datenbankversion, Populationsvertrag, Werte und Alter, andere Metriken, Kandidaten, Algorithmus, Auswahl und beobachtetes Resultat enthalten. Ein Zähler kann eine Entscheidung informieren, aber nicht nachträglich als Beweis für deren Erfolg dienen.

Wenn eine Automation Pfade verschiebt, verändert sie außerdem die künftige Population. Ohne Kausalitätsgrenze zitiert sie ihren eigenen Eingriff als scheinbar unabhängige Netzbeobachtung.

Fehlerauswirkung braucht zeitlich passende Joins

RFC 5330 nennt die Abschätzung der bei einem Linkausfall betroffenen Unconstrained TE LSPs als möglichen Nutzen. Auch hier ist die zeitliche Ausrichtung entscheidend.

Der Count Snapshot, der tatsächliche LSP-Pfad, der Verkehr, die Schutzbeziehung und die Servicezuordnung müssen zum relevanten Zeitpunkt passen. Ein frischer Zähler zusammen mit einem alten Serviceinventar bildet keinen realen gemeinsamen Zustand.

One-to-one detours und Facility-Backup-Bypasses erzeugen unterschiedliche Schutzbeziehungen. Ein gemeinsamer Bypass kann mehrere Haupt-LSPs schützen. Seine Existenz beweist weder aktuelle Bereitschaft noch ausreichende Kapazität bei korrelierten Fehlern.

Vom Link zur Wirkung braucht es Belege für tatsächliche LSPs, Verkehr, Dienste, Schutz, Fehlererkennung, Umschaltung, Weiterleitung und Anwendungsergebnis. Der Zähler setzt eine Untersuchungspriorität; er schließt die Wirkung nicht ab.

Frische muss mehrdimensional bleiben

Eine brauchbare Plattform zeigt getrennt: Protokollfrische, Populations-Berechnungszeit, Triggergranularität, Policy-Epoche, Collector-Beobachtungszeit und Consumer-Staleness. Keine einzelne Ampel ersetzt diese Dimensionen.

Der Wire Receipt hält Ursprung, Scope, Linkidentität, LSA-/LSP-Schlüssel, Sequenz, Checksum, Capture Point und Zeit fest. Der Parse Receipt bewahrt Reihenfolge und Entscheidung. Count Receipt und Populationsvertrag erklären Wert und Umfang. LSP-, Traffic-, Protection-, Decision- und Impact-Receipts folgen getrennt.

Diese Trennung entspricht einer einfachen Realitätsschichtung. Das registrierte Symbol koordiniert Bedeutung. Das Protokoll transportiert eine Behauptung. Lokale Politik bestimmt die Population. Laufender Code erzeugt und verbraucht sie. Das Ergebnis wird erst danach beobachtet.

Eine aktuelle LSA ist wertvoll. Sie sollte nur nicht als Echtzeitzertifikat für alles erscheinen, was ihr Zähler nicht misst.

Quellen