Zusammenfassung

  • Ein neues MPLS-Arbeitsgruppendokument erlaubt dem Ingress eines RSVP-TE-LSP, Optimierungsziele und harte Metrikgrenzen für die an Points of Local Repair berechneten Backup-LSP vorzugeben. Erfüllt ein PLR die Anforderung, setzt er FRR_EXT protection; kann er sie nicht erfüllen, darf er ohne dieses Flag auf lokale Regeln zurückfallen.
  • Das Flag ist ein knappes gemeinsames Ergebnis, kein Entscheidungsprotokoll. Für jeden PLR sollte ein Herkunftsnachweis Anfrage, Funktionsstand, Rückfallgrund, Richtlinienversion, Metrikquellen, Berechnungszeitpunkt, resultierenden Schutzpfad und spätere Gültigkeitsprüfungen verbinden.

Das fehlende Zeichen ist keine Fehlerursache

Eine geschützte LSP durchläuft vier Stellen, an denen Verkehr lokal umgeleitet werden könnte. Ihr Ingress verlangt, dass der jeweilige Backup-Pfad die mittlere Verzögerung minimiert, eine Obergrenze für die gesamte Verzögerung einhält und keinen Link mit zu hoher Verzögerungsschwankung nutzt. Drei PLR bestätigen die Vorgabe mit dem neuen Flag. Einer tut es nicht.

Aus dieser Lücke lässt sich kein vollständiger Betriebszustand ablesen. Der vierte Knoten könnte die Erweiterung nicht verstehen und das Objekt gemäß der Kompatibilitätsregel ignoriert haben. Er könnte sie verstehen, aber keinen Pfad finden, der alle Schranken erfüllt, und deshalb seine lokale Richtlinie anwenden. Oder der Ingress hatte gar keine expliziten erweiterten Vorgaben gesendet und die Wahl von Anfang an dem PLR überlassen.

In allen drei Fällen kann ein Backup vorhanden sein. Verantwortlichkeit und Begründung unterscheiden sich dennoch. Bei bewusster Delegation ist die lokale Regel die vorgesehene Autorität. Bei fehlender Unterstützung geht es um den Funktionsbestand. Bei unerfüllbaren Schranken müssen Anforderung, Messwerte und Topologie geprüft werden.

Ein Dashboard, das alle Fälle als „nicht geschützt“ darstellt, vernichtet diese Unterscheidung. Eines, das jeden vorhandenen Umweg als „Vorgabe erfüllt“ meldet, vernichtet die Bedeutung der zentralen Anforderung. Die Lösung liegt nicht in einem größeren Flag, sondern in einem passenden lokalen Nachweis.

Vom Individualentwurf zum MPLS-Arbeitsdokument

draft-ietf-mpls-frr-ext-00 trägt das Datum 23. August 2026. Der Datatracker führt Signaling Optimization Objective and Bounded Metrics for MPLS Fast Reroute Backup LSP Tunnels als aktives MPLS-WG-Dokument mit IESG-Status I-D Exists. Im Kopf steht Standards Track; der Entwurf läuft am 24. Februar 2027 aus. Er ist weder RFC noch IESG-Beschluss und belegt keine Implementierung.

Vorgänger war draft-deshmukh-mpls-frr-ext-02. Nach dem Aufruf zur Annahme vermerkte der Arbeitsgruppenvorsitz am 18. August die WG-Adoption und bat um Neuveröffentlichung unter einem draft-ietf-Namen. Die I-D-Mitteilung vom 23. August bestätigt Revision 00 als Arbeitsgegenstand der MPLS-Gruppe. Damit ist die institutionelle Zuständigkeit geklärt, nicht der endgültige Standard.

Technische Grundlage ist RFC 4090. Er beschreibt lokale Reparatur für RSVP-TE-LSP und das Objekt FAST_REROUTE, das unter anderem Prioritäten, Affinitäten, Hop-Grenze und Bandbreite überträgt. Der neue Entwurf fügt das TLV-basierte Begleitobjekt FAST_REROUTE_EXT für Optimierungsziele und begrenzte Metriken hinzu.

Der Ingress kann verlangen, dass der Backup-LSP die Ziele und Grenzen der geschützten LSP übernimmt, oder andere Werte setzen. Fehlt eine ausdrückliche Konfiguration, bestimmt die lokale PLR-Richtlinie. Der zentrale Knoten formuliert also eine Absicht; die Berechnung bleibt über mehrere Reparaturpunkte verteilt.

Ziele ordnen, Schranken schließen aus

Als Optimierungsmetrik kommen IGP- und TE-Metrik, nicht reservierte Bandbreite sowie minimale, durchschnittliche oder maximale Verzögerung in Betracht. Kosten und Verzögerung werden minimiert, freie Bandbreite maximiert. Mehrere unterschiedliche Ziele können gemeinsam übertragen und mit Gewichten normalisiert werden.

Eine begrenzte Metrik ist dagegen eine harte Zulassungsbedingung. Der PLR darf nur unter den Pfaden optimieren, die alle Grenzen erfüllen. Die Schranke kann für den gesamten Pfad oder jeden Link gelten; die Verzögerungsschwankung ist nur linkbezogen vorgesehen. Für dieselbe Metrik dürfen eine Pfad- und eine Linkgrenze nebeneinander bestehen.

Kommen mehrere identische Grenztypen mit gleichem Geltungsbereich an, wird nur der erste verarbeitet. Nachfolgende Exemplare bleiben unbeachtet. Für einen späteren Nachweis reicht deshalb keine sortierte Liste. Er muss die tatsächlich empfangene Anforderung einschließlich Reihenfolge eindeutig abbilden.

Der Entwurf legt nicht fest, nach welchen Kriterien ein Betreiber Ziele und Grenzen auswählt. Auch ein Gewicht ist noch keine vollständige Beschreibung der Normalisierung verschiedener Einheiten. Diese Offenheit ist für unterschiedliche Netze sinnvoll, verlagert die Erklärungspflicht aber in die lokale Betriebsführung.

Vier Ergebnisse, vier verschiedene Zuständigkeiten

Ohne erweiterte Anforderung entscheidet lokale Politik planmäßig. Das ist Delegation, kein Scheitern.

Ein PLR, der FAST_REROUTE_EXT nicht versteht, muss das Objekt ignorieren und unverändert weitergeben. Seine lokale Richtlinie berechnet den Schutz. Gemischte Netze bleiben dadurch funktionsfähig; die Fähigkeit und Softwareversion des Knotens wird aber Teil der Beweiskette.

Ein fähiger PLR behandelt empfangene Grenzen als harte Bedingungen. Kann er sie nicht erfüllen, darf er auf seine lokale Optimierung und Grenzen zurückfallen. Dann darf er im zugehörigen RRO-Unterobjekt der Resv-Antwort FRR_EXT protection nicht setzen. Hier hat eine bekannte zentrale Forderung einer konkreten lokalen Alternative Platz gemacht.

Fehlt dagegen das grundlegende FAST_REROUTE-Objekt, obwohl FAST_REROUTE_EXT vorhanden ist, muss ein fähiger PLR die Path-Nachricht mit Policy Control Failure ablehnen. Dieser Formfehler gehört zum Absender und seiner Validierung, nicht in dieselbe Kategorie wie ein betrieblicher Rückfall.

Wer alle vier Ergebnisse in einen Alarmtext presst, lenkt Untersuchungen in die falsche Richtung. Delegation verlangt eine Richtlinienprüfung, Nichtunterstützung eine Migrationsentscheidung, Nichterfüllbarkeit eine Prüfung von Pfad und Daten, ein Formfehler eine Korrektur der Anfrage.

Auch das gesetzte Flag gilt nur innerhalb einer Grenze

Erfüllt der PLR Ziele und Schranken, muss er das neue Flag im RRO setzen. Der Ingress kann die Bestätigung damit pro Reparaturpunkt auswerten und muss nicht aus einer erfolgreichen Reservierung eine einheitliche Befolgung ableiten.

Der Nachweis bleibt punktuell. Das Flag nennt weder die Generation der TE-Datenbank noch das Alter der Messung, die Rechenversion, ausgeschlossene Kandidaten oder das Normalisierungsverfahren. Nach einer Änderung von Topologie, Auslastung oder Reservierungen ist es keine dauerhafte Leistungszusage.

Es ist auch kein Umschaltnachweis. RFC 4090 bereitet lokale Umwege vor, damit Verkehr nach einem Fehler schnell umgelenkt werden kann. Eine erfolgreiche Signalisierung beweist nicht, dass die Fehlererkennung korrekt auslöst, der Hardwarezustand erhalten bleibt, Haupt- und Ersatzpfad keine gemeinsame physische Ursache besitzen, zum Fehlerzeitpunkt Kapazität verfügbar ist oder ein Ende-zu-Ende-Dienstziel erfüllt wird.

RSVP-Authentisierung kann die Nachricht gegen Manipulation schützen. Sie macht alte Messwerte nicht frisch und eine undokumentierte lokale Regel nicht erklärbar. Nachrichtenechtheit, Datenqualität und Entscheidungsbefugnis sind getrennte Prüfgegenstände.

Eine Metrik hat Quelle und Alter

RFC 7471 und RFC 7810 strukturieren TE-Leistungsattribute für OSPF beziehungsweise IS-IS. Ein PLR kann daraus aufgebaute TE-Daten, konfigurierte Werte oder andere lokale Quellen verwenden. Der FRR-Entwurf bestimmt keine weltweit maßgebliche Quelle.

Ein kürzlich gemessener Mittelwert und ein alter Planungswert passen in dasselbe Zahlenfeld. Nicht reservierte Bandbreite hängt von Klasse, Reservierungsstand und Aktualisierung ab. Bei mehreren Zielen macht erst eine Normalisierung verschiedene Einheiten vergleichbar; das übertragene Gewicht verrät nicht Formel, Skalierung oder Implementierungsstand.

Darum beantwortet „Grenze 20, Flag null“ die spätere Frage nicht. Benötigt werden Quelle, Einheit, Beobachtungszeit, Topologie- oder TE-Epoche, Rechnerfassung und die Richtlinie, die das Resultat autorisierte.

Der Herkunftsnachweis für jeden PLR

Daniel Kade schlägt einen betriebsinternen, nach geschützter LSP und PLR gegliederten Nachweis vor. Er ist keine Forderung des Entwurfs und kein zusätzliches RSVP-Objekt.

Der erste Teil identifiziert Sitzung, Ingress, PLR, geschützte Ressource und Zusammenführungspunkt. Er speichert exakte Fingerabdrücke von FAST_REROUTE und FAST_REROUTE_EXT, alle Metriktypen, Gewichte, Werte, Grenzen und Geltungsbereiche. Fähigkeit, Parsergebnis, Begleitobjekt und zurückgelieferte Resv/RRO-Angaben werden festgehalten.

Fehlt das Flag, wird ein beobachteter Grund erfasst, nicht aus dem Bit erfunden: keine ausdrückliche Vorgabe, nicht unterstützte Erweiterung, unerfüllte harte Schranke oder ein anderer belegter Zustand. Dazu gehören lokale Richtlinie und Version, Ausnahmebefugnis, Ablaufzeit und Prüftermin.

Der Rechenkontext nennt Quelle, Einheit und Zeitpunkt jeder Metrik, die Topologie- oder TE-Datenbankepoche, die zulässige Alterung, Normalisierung und Berechnungsversion sowie den entstandenen Backup-Pfad. Wo Schicksalstrennung behauptet wird, gehört die tatsächlich geprüfte Shared-Risk-Evidenz dazu; ein logisch anderer Weg ist noch keine physische Unabhängigkeit.

Spätere Nachweise werden verbunden, aber nicht vermischt. Signalisierungsaktualisierungen erneuern eine Kontrollbehauptung. Übungen prüfen die Umschaltung. Ereignisse zeigen die Wirkung auf echten Verkehr. Keine spätere Beobachtung darf die ursprünglichen Eingaben überschreiben.

Der Nachweis kann vertraulich bleiben. Er soll keine Topologie veröffentlichen und keinen Einheitsalgorithmus erzwingen, sondern lokale Entscheidungsspielräume gegenüber den zuständigen Betreibern erklärbar machen.

Ein gemeinsames Minimum braucht lokale Erinnerung

Das neue Flag ist als gemeinsame Mindestsprache stark. Eine einheitliche Anfrage trifft auf eine pro PLR lesbare Antwort, ohne dass jede Implementierung identisch werden muss.

Schwach wird das Modell nur, wenn dieses Minimum zur Obergrenze des Wissens wird. Ein gesetztes Bit fasst eine zeitgebundene Einhaltung zusammen; ein nicht gesetztes mehrere Wege zur lokalen Richtlinie. Die Organisation muss ergänzen, welche Regel mit welchen Daten wie lange galt und wer sie zurücknehmen kann.

Die Wahl lautet nicht zentrale Kontrolle oder lokale Freiheit. Sie lautet undurchsichtige oder nachvollziehbare Freiheit. Ein dokumentierter Rückfall bewahrt Schutz in Übergängen und erhält zugleich die Bedeutung der zentralen Absicht.

Quellen