Zusammenfassung

  • RFC 9657 beschreibt deterministische TVR-Fälle für Resource Preservation, Operating Efficiency und Dynamic Reachability, ohne Mechanismus oder Lösung zu spezifizieren.
  • Zeitabhängiger Cost kann Filtering, Burst Planning oder Warten autorisieren; er beweist weder Forecast-Aktualität noch tatsächlichen Preis, Kontakt, Queue Release, Forwarding oder Delivery.
  • Der belastbare Receipt bindet Forecast-Quelle und Revision, Zeitautorität, Schedule, lokale Policy, Berechnung, beobachtete Adjazenz, Queue und Zielergebnis.

Aus einer Zahl wird eine Kurve

Klassisches Routing behandelt Metriken oft als aktuellen Wert. Time-Variant Routing fragt, welchen Wert ein Link zu einem späteren Zeitpunkt haben wird. Ein Mobilfunktarif kann zwischen Peak und Off-Peak wechseln, Energie kann nachts billiger sein, eine Umweltbedingung kann die Übertragung verteuern.

RFC 9657 ordnet solche Fälle. Es ist Informational, definiert kein Wire Protocol und kein Schedule Format. Die drei Gruppen sind Resource Preservation, Operating Efficiency und Dynamic Reachability.

Der Standard legitimiert Zeit als Recheninput. Jede Zeitfunktion bleibt jedoch ein Modellprodukt. Ohne Herkunft und Revision wird aus einer nützlichen Kurve eine unbegrenzte Behauptung.

Cost braucht Messbarkeit und Haltbarkeit

Operating Efficiency setzt voraus, dass Cost messbar, vorhersagbar, ausreichend persistent und in relevanter Größenordnung veränderlich ist. Nur dann lohnt es sich, einen teuren Link zu filtern, Daten für einen Burst zu sammeln oder eine günstigere Periode abzuwarten.

Diese vier Annahmen sind Teile des Beweises. Wenn eine Tarifquelle geändert, ein Energiepreis kurzfristig schwankt oder Umweltqualität die Rate senkt, kann eine alte Funktion syntaktisch gültig und operativ falsch sein.

Speichern Sie Producer, Modell, Input-Version, Ausgaberevision, Gültigkeitsintervall und lokale Schwelle. Ein Pfadentscheid sollte rekonstruierbar machen, welche Kurve warum gewann.

Warten erweitert den Pfad

RFC 9657 beschreibt Daten, die bei N1 beginnen, N2 zu t1 erreichen, dort warten und N3 zu t3 erreichen sollen. Damit gehören Storage und Zeit zur Route. RFC 4838 und RFC 9171 geben Delay-Tolerant-Networking- und Bundle-Protocol-Kontext.

Der billigere zweite Hop beweist nicht, dass N2 die Daten bewahrte. Ein Receipt benötigt Queue ID, Custody, Integrity, Expiry, verfügbaren Speicher, Window Revision, Release und Destination Acknowledgement. Der Forecast darf Warten begründen; er darf dessen Erfolg nicht vorwegnehmen.

Geplante Abwesenheit ist nicht automatisch Fehler

Resource Preservation umfasst Knoten, die Radios wegen Power, Thermal oder Storage ausschalten. Bekannter Verbrauch, vorhersagbare Akkumulation und konsistente Managementfunktionen erlauben eine geplante Aus- und Rückkehr.

Im Solar-Sensor-Beispiel entstehen zu t1, t2 und t3 verschiedene Topologien. Das hilft, geplante Abwesenheit nicht als Incident zu behandeln. Aber RFC 9657 weist darauf hin, dass nach dem Join Discovery und Neighborhood Synchronization Forwarding verzögern können.

Power-on, Neighbor-up, Route-installed und Packet-delivered sind getrennte Zeitpunkte. Der Schedule besitzt nur den ersten erwarteten Übergang.

Bewegliche Links besitzen ein Ablaufdatum

Dynamic Reachability verwendet vorhersagbare Bewegung und Umweltwissen, um Adjacency Expiration/Resumption, Data Rate oder Link Filtering zu planen. Satelliten, Fähren und Flugzeuge können bekannte Trajektorien haben.

Eine LEO-Konstellation bleibt trotz deterministischer Bahn für unerwartete Inter-Satellite-Link-Fehler anfällig. Wetter, Abschattung und Pointing verändern Kontakte. Nichtdeterministische Vehicle-to-Vehicle-Szenarien sind außerhalb des Dokuments; die eingeschlossenen Fälle sind trotzdem nur begrenzt sicher.

„Wird zu T2 enden“ ist Forecast. „Endete zu T2“ ist Observation. „Traffic wechselte“ ist Forwarding State. „Service kam an“ ist Destination Evidence.

Clock Authority steckt in jeder Kostenfunktion

RFC 3339 standardisiert Date-Time-Darstellung. RFC 5905 spezifiziert NTPv4; RFC 8633 beschreibt Time-Security-Praktiken. Format, Synchronisation und vertrauenswürdige Quelle sind verschiedene Claims.

RFC 9657 erklärt Time Synchronization für kritisch und warnt, dass unautorisierte Clock-Änderungen Funktion stören und DoS auslösen können. Bei unterschiedlichen Offsets werten zwei Peers dieselbe Cost-Funktion an verschiedenen Punkten aus.

Zeitquelle, Offset, Uncertainty, Sync State und Clock Steps gehören deshalb zum Decision Record.

Schedule-Syntax ist keine Input-Garantie

RFC 9922 definiert gemeinsame YANG-Gruppen für Schedule, Validation und Status, nimmt aber keine Trigger Action an und löst keine Konflikte. RFC 7758 bietet Time Capability in NETCONF.

Diese Standards drücken „wann“ aus. Sie validieren nicht Preis, Trajektorie, Energie oder Demand Forecast. Der bestehende RFC-9922-Artikel besitzt die Schedule-Status/Action-Grenze. Dieser Artikel besitzt die Forecasted-Network-State/Observed-Network-State-Grenze.

Von der Funktion zum Ergebnis

Der Ledger beginnt mit Objective, Forecast Producer, Assumptions, Build, Issued Time und Validity. Dann folgen Time Authority, Distribution, Local Policy, Route Calculation und verworfene Alternativen. Zur Ausführung kommen Port/Radio State, Neighbor, Adjacency, Rate und Next Hop.

Für verzögerte Daten werden Queue, Custody, Expiry und Release verfolgt. Destination Receipt schließt die Kette. Forecast Errors bleiben erhalten und aktualisieren Qualitätsmetriken.

Heng Lus Reality-Layers-Disziplin trennt Forecast, Schedule, Decision und Outcome. Die Minimum Initial Specification ermöglicht gemeinsames Zeitvokabular ohne Verlust lokaler Autorität. Running-Code Primacy fordert die tatsächliche Transition.

RFC 9845 setzt zeitabhängige Planung in Green-Networking-Kontext. Energie- und Utility-Ergebnis bleiben Messwerte.

Quellen