Zusammenfassung

  • Ein individueller Internet-Draft vom 28. Oktober 2026 schlägt vor, Pfadmetriken zu Qualitätswerten je Segmentliste zu verdichten und innerhalb des aktiven Candidate Path daraus dynamische Gewichte zu berechnen. Welche Metriken wie zusammengefasst werden, bleibt konfigurierbar.
  • RFC 9256 macht aus dem relativen Gewicht den vorgesehenen Anteil von Flows; die Genauigkeit hängt von der Plattform ab. Ein geändertes Gewicht ist ein Eingriff in die Verteilung, kein Messwert für Bytes, Kapazität oder Anwendungsleistung.

Eine kranke Strecke und ein überaus gesunder Zahlenwert

Im Beispiel des Entwurfs tragen drei Segmentlisten im aktiven Candidate Path zunächst dasselbe Gewicht. Ein Pfad verschlechtert sich, doch die statische Einstellung schickt ihm im Modell weiter ein Drittel des Verkehrs. Die Autoren wollen Verluste, Verzögerung und Auslastung messen, daraus die Listen bewerten und das Gewicht des schlechteren Wegs senken. Ein Router, der auf eine Störung reagiert, ist eine reizvolle Vorstellung. Vor der Reaktion liegt allerdings die Entscheidung, was in diesem Netz überhaupt als Störung und was als besserer Pfad zählt.

Der Entwurf benennt die Beteiligten. Messpunkte auf Zwischen- oder Endknoten beobachten Metriken. Ein logischer Candidate Path Quality Agent, kurz CPQA, sammelt Berichte, verdichtet sie zu einem Wert pro Segmentliste und berechnet mit einer Funktion F neue Gewichte. Das Head-end installiert die Gewichte in der Weiterleitung. Messen, berichten, zusammenfassen, berechnen, anwenden: In jedem Verb kann die Aussage über den Zustand des Netzes wechseln. Der Text verlangt, dass die Gewichte direkt proportional zum Qualitätswert sind. Er liefert keine allgemeingültige Formel, mit der Verzögerung, Verlust und Auslastung zu genau diesem Wert werden. „Qualität“ ist eine betreiberspezifische Einstellung.

Das wird schon beim Verkehrsmix relevant. Ein Weg kann eine niedrige Latenz, aber wenig freie Kapazität haben. Ein anderer trägt große Datenströme gut und bedient kurze Anfragen schlechter. Revision 01 ergänzt ein Motiv aus KI-Rechenlasten: Lange Kollektivkommunikation des Trainings braucht anhaltenden Durchsatz; kurze Inferenz- und Steuernachrichten reagieren auf Anfangs- und Randlatenz. Die Beispiele sind eine Begründung der Autoren, kein protokolliertes Ergebnis eines benannten Netzes. Sie zeigen den Konflikt, den ein einzelner Qualitätswert verdecken kann.

Die Formel bevorzugt bestimmte Anwendungen, selbst wenn das Dashboard nur eine neutrale Zahl anzeigt.

Der Bruch aus RFC 9256 zählt Flows

RFC 9256 beschreibt die vorhandene SR-Policy-Architektur. Eine Policy kann mehrere Candidate Paths besitzen; grundsätzlich dient der aktive Pfad der Weiterleitung, abgesehen von beschriebenen Schutzfällen. Liegen darin mehrere Segmentlisten, verwendet das Head-end gewichtetes ECMP pro Flow. Für eine Liste mit Gewicht w ist der vorgesehene Anteil w / Summe aller Gewichte. Der RFC weist ausdrücklich auf die plattformabhängige Genauigkeit hin. Der Nenner zählt Gewichte; das Ergebnis bezieht sich auf Flows, nicht auf gleich große Datenmengen.

Ein großer Flow kann weit mehr Bytes tragen als viele kleine. Erhöht der CPQA das Gewicht einer vermeintlich guten Liste, kann diese mehr kleine Flows erhalten, ohne wesentlich mehr Volumen zu transportieren. Eine herabgestufte Liste kann weiterhin einen massiven Flow führen. Auch Hash-Verfahren und Verkehrsstruktur der konkreten Plattform wirken mit. Das Drittel im Entwurfsbeispiel ist eine anschauliche Modellannahme. Ob das neue Gewicht eine Anwendung schneller macht, lässt sich erst nach der Installation und anhand tatsächlicher Weiterleitung beurteilen. Ein Rechenergebnis im Controller ist der Anfang dieser Prüfung, nicht ihr Abschluss.

Der Vorschlag hält seinen Eingriff eng: Er ändert Gewichte von Segmentlisten innerhalb des aktiven Candidate Path. Priorität des Candidate Path und Zusammensetzung der Listen bleiben in diesem Modus gleich. Daneben beschreibt er eine zweite Betriebsart, die identifizierte überlastete Flows auf eine weniger belastete Segmentliste umleitet. Der erste Modus verändert eine Verteilungsregel, der zweite behandelt bestimmte Flows. Für die Umleitung muss jemand festlegen, welcher Flow betroffen ist und wann sie endet. Wer beide Handlungen als „automatische Routenoptimierung“ verkauft, verdeckt die unterschiedliche Entscheidung und ihre Folgen.

Der Qualitätsagent kann umziehen

Im zentralen Betrieb sitzt der CPQA beim Controller. Er erhält Qualitätsberichte, rechnet Gewichte aus und sendet das Tupel über eine südgerichtete Schnittstelle an das Head-end; PCEP wird als Beispiel genannt. Im verteilten Betrieb sitzt der CPQA am Head-end, bekommt die Berichte unmittelbar und installiert die neu berechneten Gewichte lokal. Der Rahmenentwurf definiert keine neue PCEP-Nachricht. Seine IANA-Sektion fordert gegenwärtig keine Zuteilung; erst künftige Protokollerweiterungen könnten Nummern brauchen.

Ein zentraler Controller kann eine gemeinsame Bewertungsregel über mehrere Pfade legen. Ein Fehler in dieser Regel erreicht entsprechend viele Head-ends. Lokal kann ein Head-end mit näheren Beobachtungen handeln; mehrere Head-ends können zugleich verschiedene Vorstellungen von „gut“ entwickeln. Der Entwurf erlaubt diese Wahl. Wer sie trifft, sollte auch die Spur der Entscheidung verwalten: Welche Messpunkte lieferten Daten? Welche Zeitfenster galten? Wie wurden fehlende oder verspätete Meldungen behandelt? Welche F-Version erzeugte welches Tupel, und welches Tupel wurde tatsächlich installiert? Ein unverändertes Topologiebild verrät nicht, dass sich die Verkehrsverteilung durch eine neue Bewertungsregel geändert hat.

Sicherheit des Meldungswegs beantwortet eine andere Frage. Der Entwurf verlangt Authentisierung für Nachrichten zwischen Monitoren, CPQA und ausführender Instanz; TLS oder TCP-AO werden empfohlen. Qualitätsberichte können interne Netzzustände offenlegen, weshalb Verschlüsselung bei relevantem Datenschutz erwogen werden soll. Gegen gefälschte Meldungsfluten empfiehlt der Text Ratenbegrenzung und Quellenprüfung. Eine authentisierte Nachricht hat eine nachvollziehbare Herkunft. Ob ihr Messpunkt den gesamten Weg repräsentiert und ob die Bewertungsfunktion dem richtigen Dienst nützt, muss anders geprüft werden.

Die Rückkopplung hat zudem ein Tempo. Dämpfung soll verhindern, dass ein kurzer Ausschlag die Gewichte ständig hin und her schiebt. Für diesen Rahmen legt der Entwurf keinen einheitlichen Schwellenwert und keinen konkreten Algorithmus fest. Eine zu schnelle Schleife verschiebt Flows, verändert dadurch die Auslastung und jagt anschließend die eigene Wirkung. Eine langsame Schleife belastet den kranken Weg weiter. Die Reaktionsgeschwindigkeit ist eine Betriebsentscheidung mit einer Version und einem Verantwortlichen.

Die Versionsgeschichte ist überschaubar. Schon Revision 00 vom Juli enthielt die Kette aus Messung, Bericht, Berechnung und Anwendung. Die Oktoberfassung ergänzt die KI-Last als Motivation und einen dritten Autor. Datatracker führt das Papier als individuellen Internet-Draft. Die geprüften Originale zeigen keine benannte Erprobung, die Messwerte, F-Konfiguration, installierte Gewichte und Anwendungsresultat gemeinsam protokolliert. Eine solche Spur würde die Bewertung einer konkreten Implementierung ändern.

Quellen