Zusammenfassung

  • RFC 9633 definiert das NMDA-konforme Modul ietf-detnet für App-Flows, Verkehrsprofile, Service- und Forwarding-Sub-Layer sowie bestimmte Betriebszustände.
  • Eine konfigurierte Maximallatenz ist ein Sollwert; app-flow-status=ready ist eine begrenzte Geräteaussage. Beides enthält weder Paketpopulation noch Messpunkte oder Uhren für einen Leistungsnachweis.
  • Ein belastbarer Beleg verbindet Soll- und Ist-Konfiguration, Knotenstatus, Generation, Zählerepoche, exakten Flow-Selektor, unabhängige Messung und Annahme durch die Anwendung.

Der relevante Unterschied in RFC 9633 steht in zwei Wörtern: config false. Ein Gerät meldet einen Zustand, statt dass der Operator ihn hineinschreibt. Das ist wertvoll. Es ist aber noch keine unabhängige Aussage darüber, ob ein Paket seine Frist eingehalten hat.

Ein YANG-Baum kann vollständig sein, alle Referenzen können aufgelöst werden, und ein App-Flow kann ready melden. Gleichzeitig kann die Anwendung einen Timeout verzeichnen. Beide Aufzeichnungen besitzen einen engeren Gegenstand als der Gesamtservice.

RFC 9633 liefert die gemeinsame Struktur, um diesen Gegenstand präzise zu benennen. Sie ordnet Applikations-, Service- und Weiterleitungselemente und folgt NMDA. Gerade deshalb muss ihre Beweiskraft ebenso präzise begrenzt werden.

Messbare Einheiten machen aus Anforderungen keine Messwerte

Ein traffic-profile enthält Mindestbandbreite und Obergrenzen für Latenz, Schwankung, Verlust, aufeinanderfolgende Verluste und Fehlreihenfolge. Nanosekunden, Prozent und Pakete wirken empirisch. Im Baum sind es Anforderungen.

Die traffic-spec beschreibt das Sendeversprechen oder die Anforderung der Quelle: Intervall, Paketanzahl und Nutzlastgrößen. Das Netz nutzt sie für Ressourcenzuteilung und Warteschlangen. Der konfigurierte Wert beweist weder den tatsächlich angebotenen Verkehr noch die tatsächlich erbrachte Behandlung.

max-latency setzt die Prüfgrenze, liefert aber keine Zeitstempel. max-loss enthält keine gemeinsame Sende-/Empfangsmenge. Aufeinanderfolgender Verlust und Fehlreihenfolge verlangen Sequenzinformation. Ein Sollwert kann nie durch bloße Existenz sein eigener Istwert werden.

Betriebszustand ist nicht Geschäftsabschluss

Die Statusidentitäten none, ready, failed, out-of-service und partial-failed schaffen differenzierte Aussagen. Unvollständige Konfiguration führt zu none; partial-failed kann bereite und ausgefallene Egress-Instanzen gleichzeitig abbilden.

Wer daraus ein einziges grünes Feld bildet, vernichtet Information. ready hat keinen Messzeitraum, keine Paketliste, keine Uhrbeziehung und keine Anwendungsquittung. Es muss an Gerät, Flow, Richtung, Sub-Layer, Datastore, Lesezeit und Konfigurationsgeneration gebunden bleiben.

Der Status darf eine nächste Prüfstufe auslösen. Er darf nicht eigenmächtig den Gegenstand wechseln und zum SLA-Urteil werden.

Verteilte Konfiguration braucht eine gemeinsame Epoche

Die RFC ermöglicht Provisionierung entlang des Pfads ohne Signalisierungsprotokoll. Damit ist kein atomarer Commit über sämtliche Geräte gemeint. Ein Knoten kann das neue Profil besitzen, ein anderer eine alte Forwarding-Referenz, ein dritter einen Fehler.

Wer Geräte nacheinander liest, kann während eines Rollouts einen synthetischen Gesamtzustand erzeugen: Jede Einzelangabe stimmt, doch ihre Kombination bestand nie gleichzeitig.

Die Sicherheitsbetrachtung warnt ausdrücklich, dass unkoordinierte Änderungen entlang eines konfigurierten DetNet-Pfads einen Denial of Service bewirken können. Daraus folgt die Nachweispflicht: erwartete Knotenmenge, Modulrevision, Transaktion, Antwort, Wirksamkeitszeit und Regel für die gemeinsame Generation.

NMDA strukturiert intended und operational state. Es bewahrt nicht automatisch die historische Gleichzeitigkeit einer verteilten Änderung.

Authentisierte Verwaltung ist keine unabhängige Beobachtung

NETCONF über SSH, RESTCONF über HTTPS und NACM schützen Zugriff und Operationen. Ohne diese Kontrolle könnten Angreifer Flows falsch verbinden, Inspektion umgehen oder Verkehr an unerwünschte Knoten lenken.

Ein authentisierter Server kann dennoch veraltete oder fehlerhaft implementierte Werte liefern. Ein berechtigter Benutzer kann eine falsche Anforderung korrekt schreiben. Das betreffende Gerät kann außerhalb des tatsächlich genommenen Pfads liegen.

Sichere Herkunft beantwortet, wer den Zustand erklärt hat. Paketmessung beantwortet, was innerhalb eines Zeitraums geschah. Die erste Frage autorisiert nicht die Antwort auf die zweite.

Kein Zähler ohne Discontinuity, keine Latenz ohne Uhren

Die Beispiele der RFC führen bei Interface-Statistiken eine discontinuity-time. Nach Reset oder Neustart gehört der Zähler zu einer neuen Epoche. Differenzen über ungleiche Epochen können Verlust erfinden oder verdecken.

Einweglatenz braucht gekoppelte Uhren und Beobachtungspunkte an den vereinbarten Grenzen. Verlust braucht dieselbe Paketpopulation. Reihenfolge braucht Identitäten. Replikation braucht Regeln für Kopien, Eliminierung und verspätete Ankunft.

Aktive, passive oder hybride Messung ist eine eigene OAM-Entscheidung. Ihr Selektor muss mit App-Flow, Richtung, Interfaces, Präfixen, Ports, DSCP, Labels und Member-Pfaden übereinstimmen. Sonst wird präzise das falsche Objekt gemessen.

Die fünfteilige Beweiskette

Erstens wird die Servicedefinition archiviert: Selektor, Profil, Anforderungen, Sub-Layer und Version. Zweitens folgt der Verwaltungsakt mit Autorität, Zielknoten, Antworten und Zeiten.

Drittens bleibt der Betriebszustand jedes Knotens einschließlich Teilfehler erhalten. Viertens dokumentiert die Messung Punkte, Uhren, Fenster, Population, Stichprobe und Unterbrechungen. Fünftens entscheidet die Anwendung oder Serviceautorität über Annahme, Ausnahme oder Rollback.

Heng Lus Trennung der Realitätsschichten ist hier ein Prüfprinzip. Ein Koordinationsmodell ist notwendig, aber es wird nicht zur physischen Wahrheit, nur weil es konsistent ist. Running Code und beobachtete Wirkung behalten ihre eigene Beweiskraft.

Quellen