Summary

  • RFC 9657 describes deterministic Time-Variant Routing use cases for resource preservation, operating efficiency and dynamic reachability; it defines no specific mechanism or solution.
  • A schedule can improve convergence or authorize waiting, filtering and planned topology change, but it cannot prove clock integrity, current contact, achieved data rate, queue release, forwarding or final delivery.
  • A defensible receipt binds forecast source and revision, time authority, distribution, local policy, computed action, observed adjacency, data-plane result and destination acknowledgement.

A future edge in the graph

Conventional routing reacts when a link appears or disappears. Time-Variant Routing asks whether a system should prepare for a change that is expected rather than surprising. If a moving platform will lose one adjacency and gain another, a route computation may avoid treating the transition as a failure. If power or price changes on a schedule, a node may wait for a better window.

RFC 9657 organizes these possibilities into three use-case families: resource preservation, operating efficiency and dynamic reachability. It is Informational. It defines neither a wire protocol nor a schedule format. Its examples are existence proofs, not an exhaustive catalogue.

That status matters. The RFC establishes that time can be a legitimate routing input. It does not say which forecast should win, how long it remains valid, whether a local node must obey it, or what evidence proves the predicted event happened.

Resource preservation makes absence intentional

A constrained node may turn a radio off to preserve power, remain inside a thermal limit or free storage at a more useful time. RFC 9657 assumes that expenditure, replenishment and the resource-management function are predictable enough for planning. In an energy-harvesting sensor network, three nodes can expose different connectivity at t1, t2 and t3 as their available power crosses a radio threshold.

Planned absence should not be mislabeled as failure. Yet planned return should not be mislabeled as reachability. The RFC notes that after a node rejoins, discovery and neighborhood synchronization may still delay forwarding. “Radio scheduled on” and “route ready” are different events.

The receipt therefore includes the resource model and its revision, the threshold policy, the intended power transition, the observed device state, neighbor discovery, route installation and a packet result. Without the latter half, the schedule only explains why the system expected the node.

Waiting can be a routing decision

Operating efficiency turns path cost into a function of time. The document assumes the cost can be measured, predicted, persists long enough to act upon and changes by enough to matter. A node may filter an expensive link, accumulate data for a longer burst or delay forwarding until a cheaper cellular or energy window.

The striking example is store-and-forward across time. Data may move from Node 1 to Node 2 at t1, wait, and move from Node 2 to Node 3 at t3. RFC 4838 and the Bundle Protocol in RFC 9171 provide broader delay-tolerant context for holding data until connectivity becomes useful.

But a lower modeled price at t3 does not prove that Node 2 still held the data, that the later link appeared, that the queue released, or that Node 3 received it. The optimization ledger must preserve custody, expiry, storage pressure, selected window, actual cost and delivery.

Motion makes adjacency expiration calculable, not certain

Dynamic reachability covers predictable motion and environmental effects. A route engine may anticipate adjacency expiration and resumption, changing data rate, or choose not to use a link that will soon disappear. Satellites, ferries and planes make the logic intuitive: their trajectories can often be forecast, and terminals may point in anticipation.

The RFC deliberately excludes non-deterministic vehicle-to-vehicle cases. Even inside scope, it preserves uncertainty. A LEO constellation can be regular while an inter-satellite link still fails unexpectedly. Weather, occultation, pointing and attenuation can change the useful rate. A predicted horizon crossing names a window, not the data plane.

The correct operational phrase is “contact expected under forecast revision X between T1 and T2.” “Contact occurred” needs terminal acquisition, neighbor state and link telemetry. “Data delivered” needs forwarding and destination evidence.

Time is both coordinate and control surface

Every TVR decision depends on what “now” means. RFC 3339 supplies a representation for Internet timestamps. RFC 5905 specifies NTPv4, while RFC 8633 gives current best practices for securing time. A well-formed timestamp, a synchronized clock and a trustworthy clock are three different claims.

RFC 9657 says time synchronization is critical and warns that unauthorized clock changes can disrupt functionality and potentially cause denial of service. A clock shift can make valid windows open early, close late or never align across peers. The schedule has not changed; its relation to reality has.

Store the time source, offset, uncertainty, leap handling, synchronization state and clock-change audit beside the schedule decision. Otherwise, the timestamp becomes an unexamined authority over topology.

Schedule syntax is not forecast truth

RFC 9922 later standardizes reusable YANG schedule groupings, validation and status. It expressly does not assume what action a schedule triggers and leaves conflict resolution outside scope. RFC 7758 likewise provides time capability for NETCONF management.

Those mechanisms answer how time intent can be expressed and managed. RFC 9657 asks why routing may use time. Neither proves the external assumptions behind a forecast. The source trajectory, energy estimate, price table or traffic pattern needs provenance and revision. A syntactically valid recurring window can be operationally obsolete.

This article therefore does not repeat the separate RFC 9922 boundary between schedule status and action execution. Its narrower claim is earlier and later at once: the network-state forecast feeding the schedule must remain distinguishable from the observed network state produced after it.

A receipt from forecast to delivery

Begin with the objective: preserve energy, reduce cost or exploit dynamic reachability. Record the forecast source, assumptions, model build and validity. Add the schedule representation, time zone or UTC basis, clock authority, distribution identity and receipt time. Record the local policy that accepted, rejected or modified the forecast and the route computation that followed.

At execution time, preserve radio or port state, neighbor discovery, adjacency identity, achieved rate and selected next hop. For delayed traffic, retain queue identity, custody, expiry and release. At the destination, keep a delivery acknowledgement or application observation. Failed predictions should update forecast error rather than disappear into a generic routing alarm.

Heng Lu's reality-layers discipline prevents forecast, schedule, decision and outcome from borrowing one another's authority. Minimum Initial Specification supports a shared minimum time vocabulary while leaving local adoption accountable. Running-code primacy insists that the observed transition and delivery close the story.

RFC 9845 extends the context to green-network management opportunities. A planned energy-saving topology can be worthwhile, but energy, utility and service effects still require measurement. Time makes a decision possible; evidence decides whether it worked.

Sources