Zusammenfassung

  • RFC 9938 beschreibt eine DetNet-Controller-Ebene, die Flow-Anforderungen empfangen, Flows anlegen, ändern und löschen, mögliche Pfade berechnen, einen optimalen Pfad auswählen, Ressourcen reservieren und Verhalten pro Hop installieren kann. „Optimal“ bedeutet jedoch nur etwas relativ zu einer autorisierten Ordnung von Latenz, Verlust, Jitter, Bandbreite, Schutz, gemeinsamen Risiken, Domänenzusagen und Koexistenz.
  • Ergänzend braucht es einen Nachweis der Constraint-Verantwortung: Request und Zielversion, befugte Abwägungsinstanz, Ressourcengrenze jeder Domäne, Zustandsgrundlage der Berechnung, Auslöser einer Neubewertung, Ausnahmefrist und Freigabeverantwortung. Hashes und grobe Ressourcenklassen genügen oft; sensible Topologie, Zeitpläne und Flow-Zwecke gehören nicht in ein allgemein lesbares Audit.

Ein richtiges Ergebnis kann auf einer ungeklärten Entscheidung beruhen

Der Controller findet zwei zulässige Pfade. Der erste ist kürzer und beansprucht weniger Puffer, teilt aber eine Risikogruppe mit einem bereits geschützten Dienst. Der zweite nutzt getrennte Strecken und Paketduplikation. Er ist widerstandsfähiger, bindet dafür Kapazität auf mehreren Wegen. Beide lassen sich technisch begründen.

Welche Variante richtig ist, entscheidet keine Kante in der Topologie. Wenn Ausfallschutz eine harte Verpflichtung darstellt, hat die zweite Variante Vorrang. Wenn er nur Wunsch ist und die zusätzliche Kapazität für einen höherrangigen Dienst vorgesehen wurde, kann die erste richtig sein. Ein Mindestniveau für gewöhnlichen Nicht-DetNet-Verkehr kann wiederum beide Vorschläge verändern.

Der Algorithmus benötigt eine Zielfunktion. Sie legt fest, was unnachgiebig ist, was gewichtet werden darf und wessen Ressourcen eingesetzt werden. Diese Festlegung ist bereits eine institutionelle Entscheidung. Präzise Rechnung erzeugt keine Legitimität für ihre Eingaben.

RFC 9938 macht die Trennung sichtbar. Das Dokument wurde im März 2026 als Informational RFC der IETF veröffentlicht. Es bündelt Begriffe und Anforderungen für die Controller Plane des Deterministic Networking und diskutiert Architekturen, auf denen spätere Lösungsspezifikationen aufbauen könnten. Protokolldetails einer solchen Lösung liefert es ausdrücklich nicht.

Diese Grenze ist kein Defizit, das der Artikel dem RFC vorwerfen müsste. Eine IETF-Architektur kann nicht die Mandatsordnung jeder späteren Betreiberorganisation bestimmen. Problematisch würde es erst, wenn eine Implementierung den technisch gültigen Eingang eines Requests als Beweis dafür behandelt, dass seine Verteilungsentscheidung genehmigt ist.

Funktionsaggregation ist keine automatische Verantwortungsaggregation

DetNet fasst unter Controller Plane Funktionen zusammen, die sonst häufig Kontroll- und Managementebene heißen. Der Kontrollteil instanziiert und pflegt Flows, verteilt Informationen, signalisiert und konfiguriert. Der Managementteil beobachtet Performance und Konnektivität, verwaltet Fehler und unterstützt Konfiguration und OAM.

Die in RFC 9938 beschriebene Fläche ist weit: dynamisches Anlegen, Ändern und Löschen von Flows, explizite Pfade, Linkbandbreite, Verarbeitung und Puffer, Queue-Disziplinen, bidirektionale Flows, Aggregation, Labels, Replication/Elimination/Ordering, Topologie- und Capability-Erfassung sowie Anpassung und Überwachung.

Jeder dieser Vorgänge kann knappe gemeinsame Mittel verschieben. Daraus folgt aber nicht, dass eine einzige abstrakte Controller-Rolle alle Zwecke besitzt. Application Owner, Service Owner, Flow Management Entity, Controller Plane Function, lokale Domänenbetreiber, Sicherheit und Betrieb halten unterschiedliche Teile der Wahrheit.

Eine Anwendung kennt den sachlichen Bedarf. Der Service Owner verantwortet das Leistungsversprechen. Die FME formuliert den Request. Die CPF rechnet und installiert. Eine Domäne entscheidet, ob sie den lokalen Anteil trägt. Sicherheit schützt Identität und Nachrichten. Betrieb bewertet OAM.

Auch wenn dieselbe Software mehrere Rollen erfüllt, müssen ihre Befugnisse unterscheidbar bleiben. „Der Controller hat entschieden“ darf nicht verbergen, welcher Principal das Ziel definiert hat.

Requests können über eine Anwendungs-API, statische Provisionierung, einen SDN-Controller oder verteilte Signalisierung eintreffen. Das sind Übertragungswege für Absicht, keine Rangordnung konkurrierender Absichten.

Ein Datenmodell transportiert Werte, nicht deren Mandat

RFC 9016 stellt ein Informationsmodell für DetNet-Flows und -Dienste bereit. Bandbreite, maximale Ende-zu-Ende-Latenz, Verlust, Verzögerungsschwankung und weitere Anforderungen können formuliert werden. RFC 9938 weist darauf hin, dass die Traffic Specification den ungünstigsten Fall statt eines Durchschnitts beschreibt.

Für eine ausreichende Reservierung ist das sinnvoll. Trotzdem sagt der Wert nicht, woher er kommt. Eine Latenzgrenze kann physikalisch, vertraglich oder nur vorsorglich sein. Zwei disjunkte Wege können zwingend oder bloß bevorzugt sein. Ein Spitzenwert kann gemessen, modelliert oder aus einer alten Vorlage übernommen sein.

Hard Constraint, Soft Preference und Monitoring Trigger lösen verschiedene Handlungen aus. Wird jede Zahl hart, bleiben brauchbare Pfade unnötig ungenutzt. Wird jede Zahl verhandelbar, verliert das Serviceversprechen seinen Inhalt. Wird eine alte Messung als gegenwärtig behandelt, kann eine perfekt reproduzierbare Rechnung die falsche Gegenwart optimieren.

YANG kann gewünschten Zustand ausdrücken. NETCONF kann ihn übertragen. PCE kann zentral rechnen und steuern. BGP-LS kann Topologie- und Capability-Daten liefern. Keiner dieser Mechanismen leitet aus korrekter Syntax ab, wer einen Wert setzen durfte.

Auch Authentisierung reicht nicht bis zur konkreten Entscheidung. Sie weist eine technische Identität nach. Eine Autorisierungsregel kann eine Operationsklasse erlauben. Ob dieser Befehl innerhalb des Mandats liegt, hängt zusätzlich von Dienst, Ressourcenobergrenze, beteiligten Domänen, Zeitfenster, Degradationsregel und Ausnahme ab.

Breite Konfigurationsrechte dürfen deshalb nicht als unbegrenztes Recht zur Allokation gelesen werden.

Reservierung verteilt Knappheit

RFC 8938 ordnet Ressourcenallokation und explizite Pfade der DetNet-Weiterleitung zu. Reservierte Bandbreite, Puffer und Queue-Möglichkeiten können Konkurrenz, Verlust und Jitter reduzieren. Das Dokument erklärt zugleich, dass der „beste“ Pfad von der gewählten Eigenschaft abhängt—höchste Bandbreite, niedrigster Jitter oder mehrere Metriken—und nicht der kürzeste sein muss.

Es gibt also keinen absoluten optimalen Pfad. Es gibt einen nach genehmigten Kriterien höchstplatzierten Pfad.

PREOF verdeutlicht den Preis. Pakete können über getrennte Pfade repliziert und später dedupliziert und geordnet werden. Der Dienst widersteht dadurch bestimmten Ausfällen. Gleichzeitig werden Bandbreite, Verarbeitung und Puffer auf mehreren Zweigen beansprucht. Mehr Schutz für einen Flow verringert die Optionen für andere.

RFC 8655 verlangt Koexistenz mit Nicht-DetNet-Verkehr. Selbst wenn ein hoher Anteil der Kapazität deterministischen Flows dient, darf gewöhnlicher Verkehr nicht ausgehungert werden. Schedules sollen ausreichende Übertragungsmöglichkeiten lassen. DetNet-Verkehr in eine nicht vorbereitete Downstream-Domäne zu senden, gilt als Fehler; die Vorbereitung kann eine administrative Entscheidung umfassen, dass dort Kapazität vorhanden ist.

„Administrativ“ markiert den Übergang. Für den Controller ist die Zusage eine Eingabe. Für Governance ist sie ein Akt mit Absender, Geltungsbereich, Frist und geschützter Gegenpopulation.

Ein Pfad kann die SLA des Antragstellers erfüllen und trotzdem institutionell falsch sein: Er belegt einen Korridor höherer Priorität, repliziert ohne genehmigten Bedarf oder unterschreitet den zugesagten Boden für normalen Verkehr.

Zentral, verteilt und hybrid erzeugen unterschiedliche Beweisketten

RFC 9938 skizziert drei Architekturfamilien.

Im verteilten Modell tauschen Knoten Informationen aus und bauen mittels Signalisierung Pfad und Reservierung auf. Das Ende-zu-Ende-Ergebnis kann aus lokalen Admission-Entscheidungen entstehen. Kein Element muss den ganzen sensiblen Zweck kennen. Später müssen Request, lokale Zusagen, Versionen und Ergebnis dennoch zusammengeführt werden, ohne einen zentralen Entscheider zu erfinden.

Im zentralen Modell sammelt ein Controller Topologie und Fähigkeiten, berechnet Kandidaten, wählt und konfiguriert. Der technische Ablauf ist leichter zu korrelieren. Gleichzeitig wirkt das breite Credential schnell wie eine universelle Ermächtigung. Derselbe Controller kann mehrere Organisationseinheiten, Prioritäten und Service Owner bedienen. Aus dem Zertifikat folgt nicht, welcher Request Vorrang hat.

Im hybriden Modell berechnet eine zentrale Instanz Pfadinformationen, während RSVP-TE oder andere Verfahren signalisieren und reservieren. Zwischen beiden Schritten kann sich der Zustand ändern. Berechnung und Signalisierung können jeweils erfolgreich sein und doch verschiedene Snapshots oder Constraint-Versionen verwenden. Zwei grüne Statuswerte beweisen nicht, dass der genehmigte Zustand installiert wurde.

Die Architektur verschiebt Orte und Formate des Beweises. Sie beseitigt nicht die Frage, wem die Vorgaben gehörten.

Domänenübergreifend zählt die begrenzte Zusage

Bei mehreren Domänen müssen laut RFC 9938 mehrere Controller Plane Functions zusammenarbeiten, um einen Request der Flow Management Entity in Verhalten pro Flow und Hop umzusetzen. CPFs können einander entdecken, authentisieren und über Verhalten verhandeln. Die Anwendungsebene kann Verantwortungen vorab aufteilen.

Authentisierung schützt davor, mit einem unbekannten oder gefälschten Controller zu sprechen. Sie sagt nicht, wie viel die erkannte Identität verlangen darf, welchen Dienst sie vertritt, wann ihre Zusage endet oder wer eine Verlängerung genehmigt. Erfolgreiche lokale Verhandlung garantiert ebenfalls nicht, dass alle Domänen Latenzfenster, Risikotrennung und Degradation gleich verstehen.

Ein globaler Topologiedump wäre die falsche Lösung. Jede Domäne kann eine begrenzte, zusammensetzbare Zusage abgeben: angenommene Constraint-Version, Ressourcenklasse, Geltungszeit, Aktivierungsergebnis, Neubewertungsbedingung und Freigabeereignis. Ein gemeinsamer Digest bindet diese Zusagen an denselben Request.

Interne Wege bleiben vertraulich. Ändert eine Domäne ihren Pfad innerhalb der zugesagten Bedingungen, muss sie nicht jedes Detail offenlegen. Zieht sie ihre Zusage zurück oder bricht eine Ende-zu-Ende-Eigenschaft, muss der Gesamtzustand neu entschieden werden. Stilles Umschalten kann Lieferung erhalten und dennoch das ursprüngliche Schutzversprechen verletzen.

Authentisierung beantwortet die Identität. Ein Commitment beantwortet Umfang, Zweck und Dauer des Versprechens.

Ein authentischer Befehl kann außerhalb der Delegation liegen

RFC 9055 untersucht manipulierte und injizierte Kontrollnachrichten, Pfadmanipulation, kompromittierte Controller und Ressourcenerschöpfung. Ein kompromittiertes Element kann gegenüber Knoten legitim erscheinen. Controller-Plane-Spoofing kann Bandbreite verändern, Endpunkte hinzufügen oder entfernen, Flows löschen oder falsche Flows erzeugen. Verzögertes Teardown lässt Ressourcen gebunden.

Authentisierung, Integritätsschutz und robuste Systemarchitektur sind folglich unverzichtbar. Dennoch kann auch ein authentischer Befehl unzulässig sein.

Der Controller ist gesund, das Credential gültig und die Nachricht unverändert. Der Befehl überschreitet aber das Servicebudget, nutzt eine abgelaufene Ausnahme, fügt eine nicht genehmigte Domäne hinzu oder macht einen temporären Schutzmodus dauerhaft. Credential-Rotation behebt keine falsche Zielversion. Ein anderer Algorithmus hilft nicht, wenn der bestehende seine Eingaben korrekt umgesetzt hat.

Geprüft werden muss die Übereinstimmung von Handlung und konkreter Delegation.

Dabei darf das Audit keine Aufklärungsdatenbank werden. RFC 9055 weist darauf hin, dass Anzahl, Bandbreite, Zeitplan und Eigenschaften von Flows betriebliche Absichten verraten können. Digests, Zeiträume, grobe Klassen und Prüfergebnisse reichen häufig aus. Raw Topology und genauer Zweck bleiben geschützt.

Messwerte brauchen Methode und Verfallsdatum

Die Managementseite überwacht Performance und Konnektivität. RFC 9938 unterscheidet aktive Messung, die Testverkehr einspeist und Latenz oder Durchsatz beeinflussen kann, von passiver Messung, die im Betrieb vorzuziehen ist. RFC 9551 führt den OAM-Rahmen aus.

Ein Messwert trägt daher Methode, Fenster, Aggregation und Alter. Ein aktiver Inbetriebnahmetest ist keine ewige Wahrheit. Ein passiver Durchschnitt kann seltene Verstöße gegen einen Maximalwert verdecken. Ein vollständiger Snapshot kann für eine dringende Reallokation bereits zu alt sein.

Constraints müssen auf ihre Evidenz verweisen. Hängt Schutz von Risikotrennung ab, ist deren Veränderung ein Trigger. Erlaubt eine Ausnahme vorübergehend geringeren Schutz, erzwingt ihr Ablauf eine neue Entscheidung. Scheitert die Löschung eines Flows, erhält die Restbelegung einen Owner und eine Korrekturfrist.

Monitoring bewertet nicht nur nachträglich die Leistung. Es bestimmt, wann der frühere Beschluss den heutigen Zustand nicht mehr trägt.

Was die Berechnung tatsächlich beweist

Mit definiertem Topologie-/Capability-Snapshot, Constraint-Version und Algorithmus lässt sich zeigen, welche Kandidaten geprüft, verworfen und geordnet wurden. Installationsnachweis zeigt empfangene Konfiguration. OAM beschreibt Verhalten in einem Zeitraum.

Allein beweist dies nicht:

  • dass der Requester Eigentümer des Serviceziels war;
  • dass die Constraint-Version aktuell war;
  • dass harte und weiche Bedingungen richtig klassifiziert wurden;
  • dass Ressourcen innerhalb der genehmigten Grenze blieben;
  • dass Replikation und zusätzlicher Puffer legitimiert waren;
  • dass der Boden für normalen Verkehr gewahrt wurde;
  • dass alle Domänen dieselbe Ende-zu-Ende-Bedeutung akzeptierten;
  • dass Degradation Owner und Ablauf hatte;
  • dass die Reservierung mit dem Mandat endete.

Diese Grenze schwächt den Algorithmus nicht. Sie verhindert, dass ein mathematisches Ergebnis institutionelle Tatsachen vorspiegelt, die nie Eingabe waren.

Nachweis der Constraint-Verantwortung

Der vorgeschlagene Nachweis beginnt mit einem stabilen Request-Digest, Requester-Rolle, Service Owner, FME-Grenze und Geltungsintervall. Sensibler Inhalt muss nicht kopiert werden.

Danach folgen versionierte Constraints mit Quelle und Status: hart, weich oder Monitoring. Reservierter Peak wird vom beobachteten Durchschnitt getrennt, Verpflichtung vom Ziel, notwendige Disjunktheit vom Wunsch. Der Koexistenzboden und das Ressourcenmaximum werden festgehalten.

Die Entscheidungsbefugnis wird benannt: Wer darf weiche Vorgaben sortieren, Degradation akzeptieren, das Budget erhöhen, eine weitere Domäne binden und Teardown anordnen? Ein allgemeiner Admin-Account ersetzt diese Reichweite nicht.

Berechnungsevidenz kann sparsam sein: Snapshot-Digest und Frische, Evaluator-Version, Kandidaten-Digest, gewählter Pfad-Digest, Ablehnungsgründe und Unsicherheit. Jede Domäne ergänzt ein lokales Commitment, ohne den internen Weg offenzulegen.

Zum Lebenszyklus gehören Aktivierung, OAM-Fenster, Trigger, Exception Expiry, Rollback, Release Owner und Korrekturstatus. Ändern sich Tatsachen, verweist ein neuer Nachweis auf den alten. Geschichte wird nicht überschrieben, als hätte sie spätere Informationen schon enthalten.

Beweisgrenzen

Die Quellen dokumentieren keinen Vorfall in einem benannten Netz, keine Fehlallokation eines Produkts, keine gemessene Verbreitung und keine allgemeine Kapazitätsknappheit. RFC 9938 ist ein Informational Framework, kein fertiges Controller-Protokoll.

Der Nachweis der Constraint-Verantwortung ist Daniel Kades redaktioneller Vorschlag, keine IETF-Pflicht. Die Aussage ist enger: Je genauer Automation Entscheidungen umsetzt, desto wichtiger ist die rekonstruierbare Befugnis, die ihre Ziele festgelegt hat.

Berechnen, authentisieren, installieren und messen bleibt notwendig. Vor dem Etikett „optimal“ steht aber die Antwort: nach wessen Vorgaben, mit wessen Ressourcen und bis wann?

Quellen

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://www.rfc-editor.org/info/rfc9938/
  5. https://www.rfc-editor.org/rfc/rfc9938.html
  6. https://www.rfc-editor.org/rfc/rfc8655.html
  7. https://www.rfc-editor.org/rfc/rfc8938.html
  8. https://www.rfc-editor.org/rfc/rfc9016.html
  9. https://www.rfc-editor.org/rfc/rfc9055.html
  10. https://www.rfc-editor.org/rfc/rfc9551.html
  11. https://www.rfc-editor.org/rfc/rfc9633.html
  12. https://www.rfc-editor.org/rfc/rfc7426.html
  13. https://www.rfc-editor.org/rfc/rfc8283.html
  14. https://www.rfc-editor.org/rfc/rfc9552.html