Time-Variant Routing (TVR) Requirements
draft-ietf-tvr-requirements-11
| Document | Type | Active Internet-Draft (tvr WG) | |
|---|---|---|---|
| Authors | Daniel King , Luis M. Contreras , Brian Sipos , Li Zhang | ||
| Last updated | 2026-11-03 (Latest revision 2026-07-02) | ||
| Replaces | draft-kcs-tvr-requirements | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Reviews |
INTDIR Telechat review
(of
-08)
by Darren Dukes
Ready w/nits
OPSDIR IETF Last Call review
(of
-07)
by Bo Wu
Clarification Needed
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Associated WG milestone |
|
||
| Document shepherd | Edward J. Birrane | ||
| Shepherd write-up | Show Last changed 2025-11-30 | ||
| IESG | IESG state | RFC Ed Queue | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Gunter Van de Velde | ||
| Send notices to | edward.birrane@jhuapl.edu | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA action state | No IANA Actions | ||
| RFC Editor | RFC Editor status | Awaiting First editor | |
| Details |
draft-ietf-tvr-requirements-11
Network Working Group D. King
Internet-Draft Lancaster University
Intended status: Informational L. M. Contreras
Expires: 3 January 2027 Telefonica
B. Sipos
JHU/APL
L. Zhang
Huawei
2 July 2026
Time-Variant Routing (TVR) Requirements
draft-ietf-tvr-requirements-11
Abstract
Time-Variant Routing (TVR) refers to calculating a forwarding path
through a network where the time of message transmission (or receipt)
is part of the overall route computation. This means that, all
things being equal, a TVR computation might produce different results
depending on the time that the computation is performed without other
detectable changes to the network topology or other cost functions
associated with the route.
This document introduces requirements for the design and
implementation of systems which perform TVR computations. It also
explains different aspects of a TVR system which need to be
considered during its design.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document can be found at
https://datatracker.ietf.org/doc/draft-ietf-tvr-requirements/.
Discussion of this document takes place on the Time Variant Routing
Working Group mailing list (mailto:tvr@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/tvr/. Subscribe at
https://www.ietf.org/mailman/listinfo/tvr/.
Source for this draft and an issue tracker can be found at
https://github.com/danielkinguk/tvr-requirements.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
King, et al. Expires 3 January 2027 [Page 1]
Internet-Draft TVR Requirements July 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions and Definitions . . . . . . . . . . . . . . . 4
2. Overview of Time-Variant Networks . . . . . . . . . . . . . . 7
2.1. Resource Scheduling . . . . . . . . . . . . . . . . . . . 8
2.1.1. Schedule Domains . . . . . . . . . . . . . . . . . . 8
2.1.2. Schedule Visibility . . . . . . . . . . . . . . . . . 9
2.1.3. Generation Locality . . . . . . . . . . . . . . . . . 10
2.1.4. Execution Locality . . . . . . . . . . . . . . . . . 11
2.1.5. Configuration and Operational State . . . . . . . . . 13
2.2. General Temporality . . . . . . . . . . . . . . . . . . . 13
2.2.1. Scope of Time-Variability . . . . . . . . . . . . . . 14
2.2.2. Time Horizon . . . . . . . . . . . . . . . . . . . . 14
2.2.3. Time Precision and Accuracy . . . . . . . . . . . . . 15
2.2.4. Time Synchronization and Margin . . . . . . . . . . . 15
2.2.5. Validity in a Schedule . . . . . . . . . . . . . . . 15
2.2.6. Periodicity in a Schedule . . . . . . . . . . . . . . 16
2.2.7. Continuity in a Schedule . . . . . . . . . . . . . . 16
2.2.8. Time-Overlap and Priority . . . . . . . . . . . . . . 16
2.2.9. Property Value Interpolation . . . . . . . . . . . . 17
2.2.10. Changes to Model State . . . . . . . . . . . . . . . 18
King, et al. Expires 3 January 2027 [Page 2]
Internet-Draft TVR Requirements July 2026
2.3. Topologies . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1. Nodes . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2. Termination Points . . . . . . . . . . . . . . . . . 19
2.3.3. Links . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.4. Network Layering . . . . . . . . . . . . . . . . . . 20
2.4. Routing Strategies . . . . . . . . . . . . . . . . . . . 20
2.4.1. Centralized . . . . . . . . . . . . . . . . . . . . . 20
2.4.2. Distributed . . . . . . . . . . . . . . . . . . . . . 21
2.4.3. Hybrid . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.4. Constraints . . . . . . . . . . . . . . . . . . . . . 21
2.5. Integrity Considerations . . . . . . . . . . . . . . . . 22
3. TVR Use Case Needs . . . . . . . . . . . . . . . . . . . . . 23
3.1. Resource Preservation Use Case . . . . . . . . . . . . . 23
3.2. Operating Efficiency Use Case . . . . . . . . . . . . . . 24
3.3. Dynamic Reachability Use Case . . . . . . . . . . . . . . 24
4. TVR Requirements Summary . . . . . . . . . . . . . . . . . . 25
4.1. Support the Identification and Advertisement of Entity
Property Changes . . . . . . . . . . . . . . . . . . . . 25
4.2. Support Proxy Advertisement . . . . . . . . . . . . . . . 25
4.3. Support Identification and Classification of Node
Properties . . . . . . . . . . . . . . . . . . . . . . . 26
4.4. Support System Schedule and Time Interval Changes . . . . 26
4.5. Support Appropriate Time Accuracy . . . . . . . . . . . . 26
4.6. Support Robust Security for TVR Information . . . . . . . 27
5. Operational Considerations . . . . . . . . . . . . . . . . . 28
5.1. Schedule Domain Consistency . . . . . . . . . . . . . . . 28
5.2. Incremental Deployment . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
6.1. Denial-of-Service (DoS) Attack . . . . . . . . . . . . . 30
6.2. Traffic Analysis and Path Prediction . . . . . . . . . . 30
6.3. Schedule Disclosure . . . . . . . . . . . . . . . . . . . 31
6.4. Activity Identification and Privacy . . . . . . . . . . . 31
6.5. Spoofing and Manipulation of Time Information . . . . . . 31
6.6. Replay Attacks on Time-Sensitive Data . . . . . . . . . . 32
6.7. Compromised Time Sources . . . . . . . . . . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 33
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Normative References . . . . . . . . . . . . . . . . . . . . . 33
Informative References . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
King, et al. Expires 3 January 2027 [Page 3]
Internet-Draft TVR Requirements July 2026
1. Introduction
This document was written to inform the design and implementation of
systems that manage time-variant routing (TVR) information, and to
characterize those systems using design aspects understandable to
network operators. The terms discussed in this document are
intentionally general and are intended to be tailored for specifics
of those individual TVR systems.
The motivation for this work is explained in the TVR Use Cases
document [RFC9657], which justifies why there is value in having some
form of time-variance in a system. This document discusses technical
detail of aspects that designers and operators could adopt and
considerations for when (or when not) to need to incorporate each of
these aspects in a system design. This document builds on the use
cases described in [RFC9657] by deriving design requirements and
operational considerations for TVR systems, but it does not define a
protocol solution and is not limited to a single use case. These
requirements are intended to inform solution work, such as the YANG
data model for scheduled attributes in [I-D.ietf-tvr-schedule-yang],
by identifying the time-variant information and operational behavior
that such solutions need to represent.
This document starts with an overview of TVR networks and aspects of
their time variance in Section 2 and elaborates on TVR use cases in
Section 3. Requirements on the design of TVR systems are then
categorized and summarized in Section 4 with operational
considerations for those systems in Section 5, and security
considerations in Section 6.
1.1. Conventions and Definitions
Specific terms used within this document are as follows:
Model: The universe being modeled, which defines a parameter state
space.
Data Model: Describes how data is represented and accessed. When
defined by YANG, data models are structured into modules for ease
of use (see Section 2.5 of [RFC9907]).
Network Model: Describes a network-level abstraction (or a subset of
aspects of a network infrastructure), including devices and their
subsystems, and relevant protocols operating at the link and
network layers across multiple devices. This model corresponds to
the "network configuration model" discussed in Section 4 of
[RFC8309]. See also Section 3.5.1 of [RFC9907].
King, et al. Expires 3 January 2027 [Page 4]
Internet-Draft TVR Requirements July 2026
TVR System: A set of functions, protocols, data models, and
operational procedures that produce, distribute, execute, or use
scheduled time-variant routing information.
Route: The forwarding information used to direct traffic toward a
destination.
Path: The ordered sequence of nodes, links, and termination points
used by traffic crossing a network. Paths are unidirectional and
time dependent (_i.e._, there can be a variety of paths from one
node to another, and the path over which packets are transmitted
may change) but not necessarily scheduled (_e.g._, paths can
change as a reaction to locally sensed conditons, possibly through
routing control protocols). See also Section 2 of [RFC9473].
Termination Point: The topological attachment point on a node where
a link terminates, consistent with the terminology of [RFC8345].
Entity: A single separable item within the model. Each entity has a
stable identity which is time-invariant.
Property: A single attribute of an entity which is used to
parameterize that entity. The notion of a property is not time-
variant, the property always exists within an entity but its value
can be time-variant.
Property Value: The specific value of a property, both as a planned
state within the schedule timeline and as a realized state in
wall-clock time.
Schedule: The method of parameterizing time-variance intrinsic to a
time-variant model. The parameters of a schedule are within the
state space of the model.
Schedule Time: An idealized timeline within a time-variant model
over which entities and property values can change without a
difference of state in the model itself. The notion of schedule
time is intrinsic to the model.
Wall-Clock Time: The true timeline, measured in some time scale by
some local ticker. The notion of wall-clock time is extrinsic to
the model; even non-time-variant models allow for changes over
wall-clock time, just as different model states rather than a
change _within_ the model itself.
Time Instant: A single instant of time, consistent with the concepts
of date-time in [RFC3339].
King, et al. Expires 3 January 2027 [Page 5]
Internet-Draft TVR Requirements July 2026
Timeline: A discrete or continuous sequence of time defined over a
specific time datum.
Time Horizon: A bounded interval of time used to limit the
applicability of a schedule or timeline, consistent with the
concepts of period in [RFC3339].
Subsequent: A time instant which is later in a timeline than some
reference time instant.
Snapshot: A way to transform a model with scheduled time-variance
into one that is time-invariant and applies only to a single time
instant. That instant need not be the current wall-clock time.
The term snapshot can be used as a verb, to mean the
transformation itself, or as a noun, to mean the output of the
transformation.
Schedule Domain: A set of time-variant entities that are expected to
be configured and operated jointly on the same timeline with a
bounded synchronization of execution in wall-clock time.
Orchestrator: The managing entity subsystem or function which
centralizes control of a network and applies policy to manage a
network. A Path Computation Element (PCE) [RFC4655] is an example
of an Orchestrator.
Manager: The managing entity subsystem or function which operates a
management protocol to control an Agent.
Agent: The managed entity subsystem or function which operates a
management protocol to be controlled by a Manager.
Management Protocol: The mechanism used to exchange data between
managing and managed entities, governed by one or more data models
shared by those entities.
(Routing) Application: The managed entity subsystem or function
which performs the functions of a routing protocol and/or
algorithm.
King, et al. Expires 3 January 2027 [Page 6]
Internet-Draft TVR Requirements July 2026
+--------------------+ +-------------------+
| Managing Entity | | Managed Entity |
| | | |
| +--------------+ | | +-------------+ |
| | Orchestrator | | | | Application | |
| +--------------+ | | +-------------+ |
| | | Management | | |
| +--------------+ | Protocol | +-------------+ |
| | Manager | |------+------| | Agent | |
| +--------------+ | : | +-------------+ |
+--------------------+ : +-------------------+
:
+-------------+
| Data Model |
+-------------+
Figure 1: Management Entities
As a concrete example for the use of Figure 1 when applied to
existing IETF standards, the management protocol could be NETCONF
[RFC6241], RESTCONF [RFC8040], or gNMI (gRPC Network Management
Interface) [gNMI], which would be governed by a set of YANG data
models [RFC7950] known to the Manager and its Orchestrator and
implemented on the Agent and its Application. In this example, if
the system uses all _extrinsic schedules_ the data model does not
need to be time-variant and all schedule execution would occur within
the Orchestrator. If the system uses any _intrinsic schedules_ then
those need to be present within the data model, which would be
communicated to and executed within the Application.
The entities shown in Figure 1 are logical entities and need not
correspond one-to-one with physical devices. For example, the
Orchestrator and Manager functions can be separated, combined, or
instantiated as virtual functions, and a managed entity can contain
multiple Agents, Applications, and data models. The figure is
intended to show the functional relationships involved in TVR
management, not to constrain deployment topology or internal
implementation decomposition.
2. Overview of Time-Variant Networks
Existing Internet routing techniques maintain end-to-end connected
paths across a network. Routing mechanisms exist to recover
connectivity and resume normal traffic forwarding as the topology
changes. Occasionally, optimization of routes can also be requested,
especially post-topology changes due to disruptive events. However,
there are a number of use cases [RFC9657] where changes to the
routing topology are an expected part of network operations. In
King, et al. Expires 3 January 2027 [Page 7]
Internet-Draft TVR Requirements July 2026
these scenarios, the pre-planned loss and restoration of an
adjacency, or formation of an alternate adjacency, can be treated as
a non-disruptive event.
TVR refers to calculating a forwarding path through a network where
the time of message transmission (or receipt) is part of the overall
route computation. Therefore, a TVR computation might produce
different results depending on the time a calculation is performed
without other detectable changes to the network topology or other
cost functions associated with the route.
This section is organized into the following: Section 2.1 includes
some basic definitions for when and how schedules would relate to a
general data model, Section 2.2 discusses the temporal aspects within
a schedule itself, Section 2.3 explains the entities of an IETF
network model expected to benefit from a schedule, Section 2.4
discusses complex routing behaviors enabled by a network model with
intrinsic schedules, and Section 2.5 discusses considerations needed
when schedules are present in a data model. The discussion
progresses from where scheduled information can be generated,
distributed, and executed; to how schedule time is represented; and
finally to where scheduled properties apply in network topology and
routing systems.
2.1. Resource Scheduling
Planned resource scheduling is essential for various scenarios,
including networks with mobile entities such as uncrewed aerial
vehicles and orbiting satellite constellations [RFC9657]. In these
scenarios, links are lost and re-established as a function of the
mobility of the platforms. Furthermore, link activity might be
restricted to certain times of the day in networks without reliable
access to power, such as networks harvesting energy from tidal, wind,
and solar resources. Similarly, network traffic might be planned
around energy costs or expected user data volumes in networks
prioritising energy efficiency over data rate.
2.1.1. Schedule Domains
The concept of a schedule domain is to allow partitioning the
universe of managed entities into separate sets of entities, each
with independent timelines having independent schedule execution
(Section 2.1.4) and likely independent schedule generation
(Section 2.1.3). Within each domain, all schedules need to use the
same timeline, need synchronized execution, and joint schedule
generation.
Two extremes of how a system can organize schedule domains are:
King, et al. Expires 3 January 2027 [Page 8]
Internet-Draft TVR Requirements July 2026
Universal Domain: This extreme is to combine all scheduled state
together into a single domain and single timeline. For cases
where all nodes in a network have time-varying properties that
affect their topological neighbors, all of the nodes need to be
scheduled in the same domain to avoid misaligned configuration
between devices. The orchestration and management burden in this
case is the need to consider all schedules jointly and the
operational burden is the need for synchronization of schedule
execution across managed devices.
Per-Device Domains: This extreme is to consider each managed device
as a separate scheduled domain, where property changes between
devices need not be synchronized. This simplifies aspects of
schedule execution but would likely rely on control plane
communication between devices to avoid mismatch between the actual
configuration of any node and how it is assumed to be configured
by other nodes. The orchestration of schedules within a device in
this case would likely be based on device-local needs such as for
power control.
In cases where there does not need to be tight synchronization
between some schedules, they can be managed in separate domains and
effectively form separate timelines where the schedule time in one
domain has little to no relation with any other domain.
A system design can choose to make some "edge" nodes or some
properties of edge nodes intentionally time-invariant in order to
form a logical boundary around schedule domains or possibly aligning
schedule domains with routing domains so that schedule edge nodes
correspond with routing edge nodes. This would allow routing control
protocols to be used for online negotiation at domain boundaries.
2.1.2. Schedule Visibility
Because scheduled time-variance is not a part of existing routing
algorithms and managed data models, not all routing applications will
be made to handle schedules as part of the routing parameters
intrinsically.
Two extremes of schedules being associated with routing data are:
Intrinsic Schedule: In this situation, the schedule is an intrinsic
King, et al. Expires 3 January 2027 [Page 9]
Internet-Draft TVR Requirements July 2026
part of the managed data model which is visible to the routing
application and used as part of the routing algorithms. When the
schedule is intrinsic, there is not necessarily the notion of a
schedule being "executed" as a single activity in wall-clock time
because the time-varying parameters are ingested as part of the
routing algorithm functioning (see Section 2.4) when routing is
needed.
Extrinsic Schedule: In this situation, the schedule is not part of
the managed data model for the managed entity but maintained
within the Orchestrator; the routing application only sees the
effects of changes in routing parameters as the schedule is
executed (in wall-clock time) by the Orchestrator.
There is also the possibility of an intermediate schedule, where the
schedule is still part of the managed data model but is visible only
to, and executed in wall-clock time by, the management Agent. This
intermediate schedule allows a more distributed use of scheduled data
than centralizing its processing in an Orchestrator.
2.1.3. Generation Locality
The generation of a scheduled data model depends on collecting source
data (which likely has some temporal information in it to begin
with), choosing a time horizon to schedule within, and then
processing the source data into an overall schedule.
Two extremes for locality of schedule generation are:
Centralized Generation: In this situation, all schedule generation
is centralized within a network Orchestrator and changes are sent
to routing applications in wall-clock time via a management
interface. Even though the generation of the schedule is
centralized, both the schedule visibility (within the data model)
and the locality of how the schedule is executed are
unconstrained.
For example, a schedule could be generated in a central
Orchestrator synchronized to all managed devices which then
execute the schedule in a distributed manner.
Distributed Generation: This situation corresponds with the
intrinsic or intermediate schedule visibility. Where a schedule
(with a potentially limited time horizon from what is known at the
Orchestrator) is part of the managed data which is distributed to
managed devices to be handled either by the Agent or by the
routing Application itself.
King, et al. Expires 3 January 2027 [Page 10]
Internet-Draft TVR Requirements July 2026
2.1.4. Execution Locality
Depending on the visibility of schedules within a data model (see
Section 2.1.2) there are different options for where the schedule can
be executed, and ultimately influence a time-varying configuration on
a managed device.
Two extremes for locality of schedule execution are:
Centralized Execution: In this situation, all schedule execution is
centralized within a network Orchestrator and changes are sent to
routing applications in wall-clock time via a management
interface. This situation can apply to any type of schedule
visibility, but only to centralized generation because the full
scheduled data model needs to be available to the entity
performing the execution.
Distributed Execution: In this situation, schedules are executed on
each managed device independently but based on synchronized
clocks. This situation corresponds with the Intrinsic or
intermediate schedule visibility, where a schedule (with a
potentially limited time horizon from what is known at the
Orchestrator) is part of the managed data which is distributed to
managed devices to be handled either by the Agent or by the
routing Application itself.
When schedules are distributed to the managed devices, it
necessarily increases the amount of data that the managing device
needs to synchronize across the network. The ratio of increased
size can be mitigated by only distributing a limited time horizon
to each device within a sliding window that moves forward in non-
real-time.
When schedules are both generated and executed centrally, there is a
consistency risk between different managed devices because if one
device fails to be reconfigured in wall-clock time its configuration
will no longer align with the other devices which are supposed to all
operate on the same schedule. To recover from this kind of
situation, either reattempt to configure the misaligned device can be
made to bring it back into alignment with the other devices or the
other devices' configurations need to be rolled back into consistency
which will then cause all the devices to be off-schedule.
King, et al. Expires 3 January 2027 [Page 11]
Internet-Draft TVR Requirements July 2026
When schedules are executed on each device, there is a risk that
clocks on different devices become de-synchronized beyond the time
precision required of the schedule. Because real-time clocks are
necessary for more than just schedule execution, and because accurate
and precise time sources exist outside of network time (_e.g._, UTC-
traceable time sources) this risk can be made to have a low
probability.
With distributed execution there is also a risk that a Manager loses
connectivity with the managed device and the device eventually runs
out of time horizon in the schedule which is known to it. This risk
can be mitigated by trading between the size and the horizon end-time
of schedules distributed to managed devices. This trade can be
different for different devices, where some well-connected devices
operate closer to just-in-time with short horizons while other
devices can be given a longer horizon to allow it to execute in the
absence of near-continuous Manager connectivity.
One possible combination of these options is depicted in Figure 2,
where inputs are collected in a centralized schedule generator, the
schedule is executed on that centralized entity by taking a snapshot
(periodically or as-needed when model state changes over schedule
time) and distributing the time-invariant snapshot configuration.
The example assumes that no scheduling conflicts or execution errors
are encountered during generation, execution, or configuration
distribution.
Schedule Schedule Config
Generation Execution Distribution
| | |
--inputs-->| | |--config-->
--inputs-->|---schedule--->|---snapshot--->|--config-->
--inputs-->| | |--config-->
<----------------------------------------------------->
Information Configuration
Sources Consumers
Figure 2: Centralized Generation with Centralized Execution
An alternative combination is depicted in Figure 3, where inputs are
also collected in and a schedule generated by a centralized entity,
but in this alternative the scheduled data model (or some filtered
time horizon of it) is distributed to the managed devices to be
executed independently on each device. The example assumes that no
scheduling conflicts or execution errors are encountered during
generation, distribution, or execution.
King, et al. Expires 3 January 2027 [Page 12]
Internet-Draft TVR Requirements July 2026
Schedule Schedule Schedule
Generation Distribution Execution
| | |
--inputs-->| |---schedule--->|--config-->
--inputs-->|---schedule--->|---schedule--->|--config-->
--inputs-->| |---schedule--->|--config-->
<----------------------------------------------------->
Information Configuration
Sources Consumers
Figure 3: Centralized Generation with Distributed Execution
2.1.5. Configuration and Operational State
Most of the discussion in this document treats scheduling as the
means for influencing when configuration on some managed device is
planned to be updated. But as explained in [X.731] devices are
expected to have an operational state alongside many administrative
states being configured. For example, a known delay between enabling
the modem supporting a termination point or link and the modem
actually being usable for sending traffic.
Strategies for modeling time margins around changes of configuration
are discussed in Section 2.2.4. Even when time margins are taken
into account, the schedules are still being applied to cascading
subsequent changes of administrative state within configurations.
Those changes can motivate subsequent changes in operational states.
While the administrative changes follow the schedule times, the
operational states could be effective at different times across
devices (_e.g._, because of different implementations or other
device-specific reasons).
2.2. General Temporality
This section covers different aspects of how temporality applies to
any potential TVR data model or TVR augmentation of a time-invariant
data model. Each aspect is roughly independent and informs how a
model can choose to include temporality in its parameter state space.
Each of these aspects can be different across different schedule
domains (Section 2.1.1), but are expected to be consistent within a
single schedule domain. Also, just because an entire model or domain
allows high granularity (Section 2.2.1) or high precision
(Section 2.2.3) does not mean that every single entity needs to make
use of those aspects (or even that every entity needs to have time-
variance at all). It is perfectly valid for some entities to have
time-variance and others to have none.
King, et al. Expires 3 January 2027 [Page 13]
Internet-Draft TVR Requirements July 2026
2.2.1. Scope of Time-Variability
One aspect of any time-variant data model is the scope of what can be
time-variable. Two extremes of this aspect are:
* A model that is entirely time-invariant, where time exists
conceptually but has no impact on any of the model's entities.
* A model in which every entity has some kind of schedule applied.
It is expected that an application of time-variability to real world
data models will keep some entities within the model time-invariant
and allow scheduling of other, specific entities.
Another aspect of any time-variant data model is the granularity of
state to which a schedule can be applied. Two extremes of this
aspect are:
* A model where one single schedule applies to the entire universe
(_i.e._ indicating when the time-variant entities are valid or
invalid).
* A model where every property of every entity can be scheduled
independently. This is the temporality model of Aeronautical
Information Exchange Model [AIXM].
It is expected that the use of time-variability in data models will
fit within these extremes. One possibility is to apply a schedule to
each entity indicating when that entire entity is valid or invalid.
Another possibility is to apply a schedule to groups of properties
within an entity (while leaving other properties time-invariant).
2.2.2. Time Horizon
In an idealized model the schedules will apply indefinitely far in
the past and the future, but in a realizable data model with both
processing and storage limitations there will need to be a time
horizon within which the model applies and outside of which the model
has no meaning. In some cases this horizon will be intrinsic to the
data model itself, with an explicit model parameter indicating the
horizon. In other cases the data model can allow indefinitely-large
schedules but the processing of the schedule timeline is bounded to
limit resource needs.
One possible rationale for separating schedule domains
(Section 2.1.1) is the duration of the time horizon needed for
entities in each domain.
King, et al. Expires 3 January 2027 [Page 14]
Internet-Draft TVR Requirements July 2026
2.2.3. Time Precision and Accuracy
Different time-variant models will require different granularities of
planning time, either because of limitations or assumptions about
wall-clock time or because of requirements within the modeled domain.
It is up to specific models to define the precision of time values
and the required accuracy and precision of wall-clocks which execute
the schedules.
One possible rationale for separating schedule domains
(Section 2.1.1) is the level of time precision or accuracy of
execution time able to be upheld across entities in each domain.
2.2.4. Time Synchronization and Margin
Any schedule execution and device configuration (see locality options
in Section 2.1.4) will necessarily have some misalignment in the
synchronization of time across all devices operating in the same
timeline. This misalignment is hopefully bounded by design and able
to be characterized statistically.
It is important for the activity of schedule generation (see
Section 2.1.3) to take the misalignment into account as some form of
margin around the instants of scheduled change. The exact form that
this margin would take depends on the specific time-varying
properties.
Another source of time margin in a time-varying system can be due to
a desire to model the time delay between changing the administrative
state of some subsystem and a subsequent change to its operational
state as a consequence.
Regardless of the reason for a schedule margin being accounted for,
it is critical that the margin is not double-counted by different
activities in the schedule processing chain.
2.2.5. Validity in a Schedule
Within a single schedule over its timeline there will likely be a
need to have multiple discrete intervals of validity over absolute
schedule time. The time instants at which a schedule is invalid
indicate an undefined property value, so it is important for a model
to be able to accommodate multiple schedules as necessary to ensure
that some properties can have values at all times.
King, et al. Expires 3 January 2027 [Page 15]
Internet-Draft TVR Requirements July 2026
A model which restricts itself to a single interval of validity could
run into difficulties over a long enough time horizon and would need
to resort to having multiple model entities represent the same
modeled "thing" which can lead to confusion and inefficiency.
2.2.6. Periodicity in a Schedule
Separate from the concept of intervals of validity in absolute
schedule time, there can be a need to model repetitive states in a
concise way. One way to model a recurrent change of state is to
combine a set of absolute time intervals with a periodic
parameterization (duration valid and duration invalid); this is the
model of [AIXM]. Periodic behavior is one form of recurrence, but
TVR systems can also need to represent recurring changes that are not
strictly periodic.
A model which does not include the notion of recurrence within a
schedule could be used in situations where discrete intervals of
validity are needed to handle repeated state changes which are
neither storage nor processing efficient. Periodicity can also be
seen as unnecessary when the time horizon will always be small enough
compared to any schedule time period that only one repetition is ever
seen within the horizon in one state.
2.2.7. Continuity in a Schedule
A schedule which includes a sequence of time intervals needs to
ensure that the interpretation of those intervals in the schedule
timeline does not leave any "gaps" at the interval boundaries. For
that reason, it is important that the model uses half-open intervals
of time so that time-adjacent intervals leave no gap. In keeping
with the terminology of [RFC3339], intervals are bounded by their
"start" and "end" instants. It is suggested that any time-varying
model use schedules with intervals closed on their start time and
open on their end time. This behavior lends to the interpretation,
in the schedule timeline, that the scheduled state takes effect at an
interval's start and continues until the subsequent state.
2.2.8. Time-Overlap and Priority
In an ideal situation a model would be guaranteed by design to
contain only contiguous and non-overlapping schedules for each time-
variant scope. In a realized model this kind of invariant might not
be enforceable or might lead to overly complex schedule structures.
One way a model can handle this is to establish a concept of schedule
priority, where some intervals of the schedule timeline contain
overlapping schedules for the same properties and only the highest-
priority schedule applies. When priorities are allowed by a model,
King, et al. Expires 3 January 2027 [Page 16]
Internet-Draft TVR Requirements July 2026
it enables the concept of an "overlay" where a long-duration state
can be temporarily (in schedule time) superseded by a short-duration
state.
Schedule priority is a model-level mechanism for resolving
overlapping scheduled property values. It does not by itself define
how a system arbitrates physical resource contention, coordinates
independent transmitters, or manages store-and-forward queueing.
When overlapping schedules are used to influence such mechanisms, the
corresponding solution needs to account for technology-specific
constraints, including admission control, queue depth, sender pacing,
loss, and the feasibility of sharing or preempting the constrained
resource.
2.2.9. Property Value Interpolation
When a schedule is applied to an entity in a way which is more
granular (Section 2.2.1) than just indicating when that whole entity
is valid or invalid, the model needs to consider how individual
properties are to be treated between scheduled instants. Some of the
possible behaviors are:
Zero-order hold: From the instant a scheduled value applies to a
property until the subsequent-in-schedule-time value supersedes
it. This is simple from a logical standpoint, but discontinuities
in the value over schedule time could cause issues with the model
itself. For some models, though, the constant values between
change instants are actually beneficial by allowing the entire
timeline to be compressed into a sequence of discrete state-change
instants. This is the behavior implied in models such as [AIXM].
Linear interpolation: At the instants of time defined in the
schedule the property takes the exact values, but between those
instants the property is interpolated linearly over time. This
results in a state that is continuous over time, which is
beneficial for some kinds of model but also means that there is no
simple discrete sequence of states.
Higher-order or spline interpolation: Higher order interpolations
can result in properties that vary over schedule time in ways that
are more or less beneficial to different types of models.
Regardless of the types of interpolation used, a model can choose to
apply interpolation globally or per-property. Since different
properties represent different physical or logical metrics of a
network it is expected that different types of interpolation will be
needed for different represented quantities.
King, et al. Expires 3 January 2027 [Page 17]
Internet-Draft TVR Requirements July 2026
2.2.10. Changes to Model State
Separate from how a time-variant model can contain a schedule
timeline within the model state, a model design will need to consider
how changes to the model state itself (over wall-clock time) are
handled. This aspect is actually not specific to a time-variant
model but is important to consider in this context.
Two extremes of this aspect are:
* A model which can only be changed wholesale, superseded by an
entire new model state. This is easy to keep consistent but has
inefficiencies of storage and transport if the model state is to
be shared or exchanged between real entities.
* A model which has an intrinsic notion of fine-grained superseding
changes, possibly scoped to individual entities, individual
schedules, or more complex groupings.
2.3. Topologies
The primary entities of a topological network model, as realized in
the IETF [RFC8345] and similar predecessors, are _nodes_ and
unidirectional _links_, with a secondary entity representing the
_termination point_ for each side of a link at a node. Following the
concepts described in Section 2.1 these are the entities to which an
intrinsic schedule can be applied. Since TVR is focused on the
routing aspect of scheduled systems, relating schedules to entities
in a network model used for routing is meant to give concrete
guidance about where there is value to put a schedule in a TVR
system.
2.3.1. Nodes
When a schedule is applied to a node the granularity could at least
be at the individual node. In cases where the properties of a node
have time-variable values the model can define an interpolation
method, either globally or per-property.
King, et al. Expires 3 January 2027 [Page 18]
Internet-Draft TVR Requirements July 2026
A node is just a named entity in Layer 3 [RFC8346] and Layer 2
[RFC8944] topologies. Schedules on a node could be used to indicate
the validity of the entire node or changing properties of that
entity. When a schedule indicates that a node is not valid for a
schedule time instant, a model can define whether that condition also
affects the validity or usability of its termination points or links.
For example, the power state of a node can affect the operational
state of all of its interfaces, while other node properties can
remain independent of link state. This logic allows a schedule to
represent, for example, the expected power-on state of a node at a
specific layer.
2.3.2. Termination Points
When a schedule is applied to a termination point the granularity can
be at least the individual entity. In cases where the properties of
a termination point have time-variable values the model can define an
interpolation method, either globally or per-property.
A termination point is associated with an IP address in Layer 3
[RFC8346] and a link-layer identifier, such as an EUI-48 or EUI-64
identifier, in Layer 2 [RFC8944] topologies. Schedules on a
termination point could be used to indicate the validity of the
layer-2/3 interface represented by the entity or changing properties
of that entity. When a schedule indicates that a termination point
is not valid for a schedule time instant, a model can define whether
that condition affects links anchored at that termination point.
This logic allows a schedule to represent, for example, the expected
power-on or administrative-enabled state of an attached network
interface card (NIC) or virtual private network (VPN) endpoint.
2.3.3. Links
When a schedule is applied to a link the granularity can be at least
the individual link. In cases where the properties of a link have
time-variable values the model can define an interpolation method,
either globally or per-property.
A link is associated with link metric properties in Layer 3 [RFC8346]
and Layer 2 [RFC8944] topologies. Schedules on a link can be used to
indicate the validity of the entire link or changing properties of
that entity. When a schedule indicates that a link is not valid for
a schedule time instant, that validity does not imply invalidity of
its termination points or nodes. This logic allows a schedule to
represent, for example, the expected connectivity state, data
throughput/rate, and latency/delay of a link.
King, et al. Expires 3 January 2027 [Page 19]
Internet-Draft TVR Requirements July 2026
2.3.4. Network Layering
When a schedule indicates that an entity is not valid for a schedule
time instant, that validity does not imply invalidity of any of its
associated overlay or underlay network entities. The effects of
scheduled administrative disabling or enabling of an entity at one
layer do not imply a change in administrative enabled state at any
other layer. Likewise, the assigning of an address property at one
layer does not imply the presence or absence of an address assignment
at that same time instant for any other layer.
2.4. Routing Strategies
Traditional network routing techniques typically use link bandwidth
and delay for path calculation, and do not consider time-based
factors. TVR is intended to be capable of improving network
performance and reliability in environments where entities liveness
and link availability is a time-based consideration, with various
factors, including power availability, interface line of sight or
expected demand.
However, even if some adjacency failures are predictable, others are
not, including link failures and entity outages. Therefore, any new
technique or routing protocol extension for TVR environments needs to
be capable of handling planned and unexpected resource losses or
other changes.
TVR introduces a scenario of calculating a path, or sub-path within a
network, taking into account the timing of message transmission or
receipt as an integral part of the overall route computation.
Furthermore, synchronization of network time across TVR-capable
entities is critical.
Three scenarios are currently considered when computing TVR-enabled
paths and described in the following subsections.
2.4.1. Centralized
The network entities will receive the time variable information and
traffic forwarding rules directly from a logically centralized
source, an Orchestrator or network controller. The time-variable
data can then be processed locally by the entity entered into the
scheduled routing table and specific forwarding rules applied.
Furthermore, a centralized approach could also be used to extend
existing tunnel and path delivery mechanisms and protocols to
distribute traffic forwarding rules along with time-variable
King, et al. Expires 3 January 2027 [Page 20]
Internet-Draft TVR Requirements July 2026
information. However, in certain environments, a logically
centralized source can lose connectivity with network entities (as
described in Section 2.1.4), preventing timely delivery of traffic
forwarding rules. To mitigate this risk, the time horizon for time-
variable information can be extended accordingly.
2.4.2. Distributed
Network entities can participate in a routing scheme where time
variable information is propagated through the network via capability
and variability advertisements. This could be achieved using
extensions to existing routing schemes and techniques so that link,
adjacency, cost, and schedule can be considered when making
forwarding decisions for per-hop packets or calculating traffic
engineered end-to-end paths. Note that schedule distribution and
entity computation latency can exist in some network environments.
In some environments, scheduling information can be distributed
through a management plane mechanism, such as NETCONF [RFC6241] or
gNMI (gRPC Network Management Interface) [gNMI], instead of the
routing scheme.
2.4.3. Hybrid
In this scenario, mixed-entity TVR capability exists. Some entities
will require a schedule provided by a centralized source, and others
will be capable of advertising and learning scheduled information via
a distributed mechanism.
This scenario presents time and schedule synchronization and source
verification challenges and will require further study, but are out
of scope for this document.
2.4.4. Constraints
Time-variant network constraints can be based on dynamic factors that
will influence how the network is managed and how network resources
are scheduled. These constraints are influenced by real-time data
and can vary significantly depending on multiple factors. By
considering time-variant constraints, network operators can enhance
the efficiency, reliability, and performance of telecom networks.
The main factors influencing these constraints include:
King, et al. Expires 3 January 2027 [Page 21]
Internet-Draft TVR Requirements July 2026
1. Predicted Traffic Demand: Network usage patterns fluctuate
throughout the day, with peak times typically occurring during
business hours and in the evening. Predicting these patterns
accurately allows for proactive resource allocation, ensuring
that sufficient bandwidth is available during high-demand periods
without over-provisioning during low-demand times.
2. Energy Efficiency: The energy consumption of network equipment
can be optimized based on the current load. By scheduling
resources and adjusting power levels or shutting down
underutilized equipment, telecom networks can significantly
reduce energy costs and carbon footprints, contributing to
sustainability goals.
3. Weather Conditions: Weather can impact network performance,
especially for wireless and satellite communications. Adverse
weather conditions such as heavy rain, snow, or extreme
temperatures can degrade signal quality. Incorporating predicted
and real-time weather data into network management strategies can
help in adjusting transmission power, rerouting traffic, or
preemptively switching to more resilient pathways.
4. Network Maintenance and Upgrades: Scheduled maintenance or
unexpected faults can introduce temporary constraints. By
planning maintenance activities during off-peak hours and having
real-time monitoring systems to quickly detect and address
faults, network downtime can be minimized.
2.5. Integrity Considerations
Time-variant network relies on accurate and timely dissemination of
time-variant routing and forwarding information. However, the
presence of malicious or unintended divergent information introduces
risks that can impact network stability and operational correctness.
An adversary could manipulate scheduled routing updates to introduce
black holes, persistent loops, or denial-of-service conditions by
injecting false time-sensitive state changes. Even in non-malicious
scenarios, incorrect or misaligned scheduling or misconfiguration, or
time de-synchronization, can lead to unintended forwarding behavior,
potentially degrading performance or causing service disruptions.
King, et al. Expires 3 January 2027 [Page 22]
Internet-Draft TVR Requirements July 2026
To mitigate these risks, TVR solution mechanisms can incorporate
integrity validation and trust enforcement to ensure the correctness
and authenticity of time-sensitive routing updates. This can include
cryptographic techniques to verify the source and integrity of
schedule updates, consistency checks against expected network state,
and mechanisms to detect and reject anomalous scheduling data.
Additionally, fallback strategies can allow continued operation in
cases where unexpected or inconsistent information is detected.
Specific security considerations are discussed in Section 6 later in
this document.
3. TVR Use Case Needs
Several TVR use cases have been identified and discussed in an
earlier TVR document [RFC9657]. This section provides further detail
on specific needs from those use cases.
3.1. Resource Preservation Use Case
This use case is about managed devices being reactive to sensed
conditions, but also providing feedback to an Orchestrator to allow
coarse schedules of expected resource availability. Its needs
include:
Temporality tailored to system dynamics: Because managed devices are
either powered-off or severely degraded in performance when
preserving resources, the schedules governing expected topology
need to be of sufficient precision and synchronization to capture
the dynamics of the managed devices.
Parameterization of periodicity: Resource availability based on
diurnal activity on Earth fits well into a periodicity based
strictly on time-of-day. But when resources are available based
on other natural phenomena (_e.g._, orbital periods) the schedules
need to have a periodicity which is parameterized in such a way
that allows matching the resource dynamics (_e.g._, repeating
subsequent intervals of durations of seconds available and seconds
unavailable).
Time horizon tailored to uncertainty: Even when periodicity is well
understood, characterized, and parameterized in a data model,
there needs to be allowance for uncertainty of expected resource
availability. This operates both in the sense of having a large
enough time horizon to enable a device to "ride out" times of low
resources without needing schedule updates, as well as the horizon
being limited to avoid large schedules which far exceed the point
where actual system state will diverge from the model state.
King, et al. Expires 3 January 2027 [Page 23]
Internet-Draft TVR Requirements July 2026
3.2. Operating Efficiency Use Case
This use case is about scheduling resources proactively to improve
efficiencies. Its needs include:
Distribution of Predicted Topology-change: The predicted topology-
change information might include the valid time, invalid time,
link costs at different times, and change periods.
Topology Changes: Predicted topology-change information can need
revision as forecasts are refined or as unexpected events occur.
The managing entity needs to be capable of providing a partial or
full topology update as often as needed.
Minimum Route Recalculation Interval and Threshold: Although some
cases might assume that the cost persists for a sufficient amount
of time, considering that each route contains multiple links, the
frequency of changes to the path might be much higher than the
cost. In this case, the minimum recalculation interval or cost
change threshold is needed to determine when a route recalculation
is required. Of course, scheduled topology connection changes
need to be considered when path calculation is required.
3.3. Dynamic Reachability Use Case
This use case is about geometric and kinematic constraints of mobile
devices influencing their ability to establish or maintain links to
neighbors. Its needs include:
Pairwise consideration of synchronization and margins: When
scheduling links, the execution clock synchronization of its two
endpoints as well as any margin needed on each of those endpoints
need to be considered when generating schedules for those links.
Additionally, schedules on long-distance (_i.e._, interplanetary
scale) links need to be planned for the effects of light-speed
delays on distribution and execution.
Schedule independence from external conditions: An important concept
of distributed schedule execution in TVR is that a consistent
shared timeline and a wall-clock ticker across managed devices is
the unified mechanism to synchronize state across devices.
Schedule entries are not expected to depend on externally sensed
conditions such as location, orientation, or other geometric or
kinematic properties. Changes arising from such external
conditions that are not captured in the schedules are outside the
scope of TVR and are handled reactively by the network. Schedule-
based TVR and condition-based reactive mechanisms can coexist
within the same network and within its devices.
King, et al. Expires 3 January 2027 [Page 24]
Internet-Draft TVR Requirements July 2026
4. TVR Requirements Summary
The requirements in this section are derived from the use case needs
discussed in Section 3 and from the design aspects introduced in this
document.
Not every architectural option or property described in this document
results in a hard requirement; rather, those aspects inform the
requirements that TVR systems need to support when they are
applicable to a deployment or use case.
4.1. Support the Identification and Advertisement of Entity Property
Changes
In Time-Variant Routing, scheduling of available entity resources is
expected. In practical situations, however, the properties of
entities can be converted back and forth between Time-Variant and
Non-Time-Variant nodes.
REQ_NON_SCH_CHANGE_ENTITY: An entity must support the identification
and advertisement of non-scheduled property changes.
Besides, if there are abnormal changes in the system, it is necessary
to advertise them through the existing routing protocols in time to
achieve the stability of Time-Variant Routing and avoid redundant
advertisements. For example, an entity in the system is suddenly
damaged due to external factors. Changes in entity state outside of
a schedule are communicated to other entities in a network through
existing routing protocol mechanism, where they exist.
REQ_NON_SCH_CHANGE_MANAGER: A Manager should provide a mechanism to
advertise unscheduled changes that invalidate or supersede
previously distributed scheduled state, so that other entities can
react without waiting for the next scheduled update.
4.2. Support Proxy Advertisement
A proxy is an entity that advertises TVR-relevant property changes on
behalf of another entity that cannot originate such advertisements
itself. For example, a node with routing or management capabilities
can advertise scheduled or unscheduled property changes for an
attached non-routing node, interface, or other modeled entity. A
proxy advertisement needs to preserve the identity of the represented
entity and the properties being advertised, so receivers can
distinguish between the proxy itself and the entity on whose behalf
it is acting.
King, et al. Expires 3 January 2027 [Page 25]
Internet-Draft TVR Requirements July 2026
Supporting proxy entities means that a TVR system can designate,
authenticate, and authorize an entity to advertise information for
another entity, and can process those advertisements as applying to
the represented entity rather than to the proxy. Proxy nodes can
help nodes without routing functions to advertise information, thus
improving the efficiency of the network. Therefore,
REQ_PROXY_ADV: Systems should support proxy entities to help non-
routing nodes implement information advertisement.
4.3. Support Identification and Classification of Node Properties
The entity properties of the network might change as described in
Section 3.1. If the system cannot timely identify and classify in a
processing manner after the entity properties change, it will lead to
suboptimal routing decisions. Therefore,
REQ_IDENT_CLASS_NODE_PROP: Systems must provide a discovery and
resolving methodology for the identification and classification of
entity schedule changes.
4.4. Support System Schedule and Time Interval Changes
The system's schedule state can change, requiring entity
configuration updates rather than being fixed and unmodifiable.
Additionally, time-variant intervals in the system can also vary.
Therefore,
REQ_SCH_CHANGE: Systems must support system schedule changes and
time interval changes, the frequency of update depends on the
detailed scenarios. A rollback mechanism is necessary in case of
incorrect updates.
4.5. Support Appropriate Time Accuracy
TVR schedule execution depends on the relationship between time
accuracy, schedule precision, synchronization error, and network
convergence behavior. If the tolerated time error is too large for a
deployment, entities can apply scheduled state at different effective
times and produce inconsistent forwarding behavior. If the required
tolerance is unnecessarily small, the system can impose avoidable
implementation and operational cost. Therefore,
REQ_TIME_TOL: Systems must support configurable or otherwise
specified time tolerance appropriate to the schedule precision,
synchronization uncertainty, and convergence needs of the
deployment.
King, et al. Expires 3 January 2027 [Page 26]
Internet-Draft TVR Requirements July 2026
4.6. Support Robust Security for TVR Information
The security properties listed here are not unique to TVR and are
generally applicable to routing information systems. TVR adds
specific sensitivity to the correctness, authorization, timing, and
freshness of scheduled routing information, because an incorrect
schedule can affect future forwarding behavior even before the
affected time interval begins.
Implementations need to address security risks associated with time-
variant information to ensure the reliability and integrity of
scheduled network operations. The following security-related
requirements are to be considered:
REQ_INTEGRITY: Mechanisms must be in place to ensure that time-
sensitive routing updates are protected from unauthorized
modification.
REQ_PROMPT_DELIVER: Mechanisms must ensure that time-sensitive
routing updates are delivered within the time bounds needed for
the affected schedule horizon, or that late updates are detected
and handled safely.
REQ_AUTHN_AUTHZ: Entities generating or modifying TVR schedules must
be authenticated, and only authorized entities should be permitted
to inject, update, or override scheduled routing information.
REQ_CONFIDENTIALITY: TVR implementations must protect
confidentiality of schedule information when disclosure could
reveal sensitive operational plans, business relationships, or
other information about future network behavior.
REQ_RESILIENCE: A TVR network must be resilient against the
injection of incorrect or maliciously crafted scheduling
information.
REQ_ROBUSTNESS: Since TVR relies on time-sensitive operations, it
must ensure the trustworthiness of external time sources.
Protection against time-based attacks, such as replay attacks or
clock manipulation, is also considered.
REQ_STABILITY: In the event of conflicting, missing, or compromised
time-variant routing data, TVR implementations must include
mechanisms for fallback (to contingency configuration), rollback
(to previously working configuration), and/or recovery (by
adapting configuration to new sensed conditions) to maintain
network stability.
King, et al. Expires 3 January 2027 [Page 27]
Internet-Draft TVR Requirements July 2026
By integrating these security requirements into TVR implementations,
networks can mitigate risks associated with malicious actors,
misconfigurations, or unintended disruptions, ensuring the robustness
of time-sensitive routing decisions. Specific security scenarios and
negation and mitigation methods are discussed in Section 6.
5. Operational Considerations
Introducing time-variance to network operations and management in any
capacity adds complexity to those areas of system design and
implementations. This section discusses considerations for those
areas in the spirit of [I-D.ietf-opsawg-rfc5706bis] but without
concrete details of a specific TVR system design.
5.1. Schedule Domain Consistency
As explained in Section 2.1.1, the purpose of a schedule domain is to
organize managed devices based on their time-variant needs and
capabilities. The choice of which devices to include in a domain is
subjective, but can take into consideration the schedule-awareness
capabilities of the devices and temporal sensitivities of their
configurations.
For example, including in a single domain devices which can handle
data models with intrinsic schedules and devices which cannot will
increase the burden on the network Orchestrator to validate the joint
configurations of those devices. Segmenting into different schedule
domains would allow for a more simple validation of the time-
invariant device configurations and a more narrow but complex
validation of the time-variant device configurations.
Another important consideration for schedule domains is the required
wall-clock time precision and accuracy of devices in each domain, as
explained in Section 2.2.3. A single domain which includes devices
needing only coarse time precision as well as those needing tight
precision can add unnecessary burden to planning and validation of
schedules for the coarse-precision devices.
Similarly, the required time synchronization for devices in each
domain, as explained in Section 2.2.4, affects the amount of and
types of analysis that a network Orchestrator needs to validate
configurations of those devices. A single domain which includes some
devices needing only loose synchronization and some with very tight
requirements adds burden to planning and validation of schedules.
King, et al. Expires 3 January 2027 [Page 28]
Internet-Draft TVR Requirements July 2026
5.2. Incremental Deployment
There is an expectation that the intentionally simplified view of
Figure 1 would actually contain a large number of separate but
possibly inter-related data models being managed for even a modestly
complex managed device. And that figure shows only a single managed
device while a real network is expected to contain a large number of
managed devices, possibly with a diverse set of management protocols
serving different sets of devices, but under the control of a central
Orchestrator. Because of these expectations, the introduction of TVR
into an existing management ecosystem is meant to be able to be
deployed incrementally, possibly along different aspects in different
increments. This supports both greenfield deployments, where TVR can
be designed into the initial architecture, and brownfield
deployments, where TVR capabilities coexist with and gradually
augment non-TVR operation.
Within the aspect of schedule domains (Section 2.1.1) it is possible
to start with a single completely time-invariant domain, add TVR as a
single time-variant domain covering a portion of devices most in need
of scheduled behavior. From there the operator can either grow that
time-variant domain to cover more devices or add other time-variant
domains to suit the operator's needs over deployment increments.
Within the aspect of schedule visibility (Section 2.1.2) it is
possible to deploy TVR first as extrinsic schedules known only to the
network Orchestrator and executed centrally there. From there the
operator can transition a portion of those extrinsic schedules to
intrinsic schedules, which requires support for (some form of)
schedule execution on the managed devices. As needs change or device
support is updated, the scope of intrinsic schedules can be grown or
adjusted to suit over deployment increments.
Within the aspect of generation locality (Section 2.1.3) a time-
variant domain can start out as a fully externally-controlled device
and possibly expand to allow managed devices themselves to propose
schedules based on locally-sensed conditions such as traffic
periodicity or resource (_e.g._, power) availability. Managed
devices might propose schedules which can then be simulated and
verified by an Orchestrator and augmented as intrinsic schedules back
to those devices.
King, et al. Expires 3 January 2027 [Page 29]
Internet-Draft TVR Requirements July 2026
The complexity and scope of supported schedules can also be adjusted
incrementally, starting with a time-variant domain that operates on
very simple schedules with coarse-grained scope and short time
horizons. From there, an operator can incrementally increase
schedule complexity, make schedule scope more fine grained, or expand
time horizons as device support is updated. These changes can all be
mediated through schedule domains focused based on that device
support.
6. Security Considerations
Using time-variant mechanisms introduces unique security
vulnerabilities that need to be carefully considered to ensure the
integrity, availability, and confidentiality of the network.
Networks relying on time-sensitive data for forwarding decisions are
particularly susceptible to attacks that exploit temporal aspects and
timing dependencies.
The following potential security considerations warrant detailed
investigation as solutions are developed and deployed.
6.1. Denial-of-Service (DoS) Attack
Precisely coordinating time information across devices and routers is
critical to maintaining network stability. Malicious actors could
exploit this dependency by disrupting or manipulating the time
synchronization process. For example, an attacker could
intentionally delay or corrupt time signals exchanged within the
network, leading to routing errors and widespread denial-of-service
(DoS) attacks. In this scenario, routers and managed devices might
fail to correctly determine the optimal paths, resulting in dropped
packets, increased latency, or even complete service outages.
Additionally, these attacks could be scaled to affect multiple
devices simultaneously, further amplifying their impact. Given the
critical nature of time in such networks, securing time
synchronization mechanisms, such as Network Time Protocol (NTP) or
Precision Time Protocol (PTP), is essential to mitigate these risks.
6.2. Traffic Analysis and Path Prediction
Time-variant networks can involve frequent updates and adjustments to
routing tables based on current and forecasted network conditions.
If time information is not adequately protected, attackers could
conduct traffic analysis to infer routing decisions, network load, or
usage patterns. The schedule availability could enable attackers to
launch highly targeted attacks, such as selectively overloading
certain links or intercepting sensitive communications. Moreover,
long-term analysis of time-variant network data could provide
King, et al. Expires 3 January 2027 [Page 30]
Internet-Draft TVR Requirements July 2026
attackers with insights into the underlying structure of the network,
enabling them to plan more sophisticated attacks. To counter these
threats, it is vital to encrypt time-sensitive data and limit the
exposure of time-related metadata to unauthorized entities.
6.3. Schedule Disclosure
Schedule information can reveal future network behavior before it
occurs. In some deployments, disclosure of planned topology changes,
resource availability, or forwarding behavior could reveal sensitive
operational plans, business relationships, or other confidential
information. TVR solutions need to protect schedule information from
unauthorized disclosure when the schedule itself is sensitive.
6.4. Activity Identification and Privacy
In certain scenarios, precise time information exchanged within the
network could be correlated with specific user or device behavior,
inadvertently revealing private information. For instance, time
scheduling decisions could be analyzed to determine when and where
certain devices are active, allowing an attacker to infer user
habits, locations, or preferences. This could pose significant
privacy concerns, particularly in environments where sensitive
personal or organizational data is transmitted. Furthermore,
attackers could use this information to create detailed profiles of
network users, which could be exploited for social engineering
attacks, surveillance, or other malicious activities.
6.5. Spoofing and Manipulation of Time Information
The accuracy and integrity of time information are crucial for making
correct routing decisions. If an attacker were to inject false or
manipulated time data into the network, it could cause routers and
devices to make incorrect decisions, potentially leading to traffic
misrouting, network partitions, or inefficient use of resources.
Such spoofing attacks could divert traffic through malicious nodes,
enabling man-in-the-middle attacks, data interception, or
unauthorized access to network resources. Furthermore, time
manipulation could create persistent disruptions by continuously
altering the perceived time, thereby forcing the network into a
constant state of flux and instability. Robust authentication
mechanisms for time sources and integrity checks on time-related
messages are essential to defend against these types of attacks.
Moreover, implementing redundancy in time synchronization (e.g.,
multiple time sources) can provide resilience against single points
of failure.
King, et al. Expires 3 January 2027 [Page 31]
Internet-Draft TVR Requirements July 2026
6.6. Replay Attacks on Time-Sensitive Data
Time-variant network data and schedule updates can be susceptible to
replay attacks, where a malicious actor intercepts and retransmits
valid time-based data at a later time. This could cause network
devices to act on outdated information, leading to inconsistent
routing decisions, misaligned schedules, or security gaps. In
particular, attackers could exploit replay attacks to force devices
into outdated configurations or interfere with the synchronization of
schedules across the network. To prevent this type of attack, it is
important to use a messaging protocol for time-variant schedules that
mitigates such attacks while ensuring the validity and timeliness of
received information.
6.7. Compromised Time Sources
The reliance on external time sources for synchronization purposes
presents a potential attack surface for time-variant networks. If a
trusted time source, such as a GNSS (Global Navigation Satellite
System) signal, PTP or an NTP server, is compromised, the attacker
could feed erroneous time information to the entire network,
disrupting its operation. Such an attack could lead to cascading
failures as devices attempt to synchronize with the compromised
source, ultimately resulting in incorrect routing decisions or even
the collapse of the network. To address this, network operators can
implement multiple, redundant time sources and regularly verify the
integrity of these sources. In addition, alerting mechanisms can be
in place to detect significant deviations in time data that could
indicate an attack.
7. IANA Considerations
This document has no IANA actions.
Acknowledgments
The authors would like to specifically thank Tony Li, Mark Blanchet,
Alexander Petrescu, Ed Birrane, Jie Dong, Abdussalam Baryun and Joel
Halpern
This work is partly supported by the UK Department for Science,
Innovation and Technology under the Future Open Networks Research
Challenge project TUDOR (Towards Ubiquitous 3D Open Resilient
Network).
King, et al. Expires 3 January 2027 [Page 32]
Internet-Draft TVR Requirements July 2026
Contributors
The following authors contributed significantly to this document:
Jing Wang
China Mobile
China
Email: wangjingjc@chinamobile.com
Peng Liu
China Mobile
China
Email: liupengyjy@chinamobile.com
Zheng (Sandy) Zhang
ZTE Corporation
China
Email: zhang.zheng@zte.com.cn
Yuehua Wei
ZTE Corporation
China
Email: wei.yuehua@zte.com.cn
Charalampos (Haris) Rotsos
Lancaster University
United Kingdom
Email: c.rotsos@lancaster.ac.uk
References
Normative References
[RFC9657] Birrane, III, E., Kuhn, N., Qu, Y., Taylor, R., and L.
Zhang, "Time-Variant Routing (TVR) Use Cases", RFC 9657,
DOI 10.17487/RFC9657, October 2024,
<https://www.rfc-editor.org/info/rfc9657>.
Informative References
[AIXM] EUROCONTROL and Federal Aviation Administration, "AIXM 5
Temporality Model", 15 September 2010,
<https://aixm.aero/sites/default/files/imce/AIXM51/
aixm_temporality_1.0.pdf>.
King, et al. Expires 3 January 2027 [Page 33]
Internet-Draft TVR Requirements July 2026
[gNMI] Borman, P., Hines, M., Lebsack, C., Morrow, C., Shaikh,
A., Shakir, R., Li, W., and D. Loher, "gRPC Network
Management Interface (gNMI)", Version 10.0, May 2023,
<https://www.openconfig.net/docs/gnmi/gnmi-
specification/>.
[I-D.ietf-opsawg-rfc5706bis]
Claise, B., Clarke, J., Farrel, A., Barguil, S.,
Pignataro, C., and R. Chen, "Guidelines for Considering
Operations and Management in IETF Specifications", Work in
Progress, Internet-Draft, draft-ietf-opsawg-rfc5706bis-05,
26 June 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-opsawg-rfc5706bis-05>.
[I-D.ietf-tvr-schedule-yang]
Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M.
Blanchet, "A YANG Data Model for Scheduled Attributes",
Work in Progress, Internet-Draft, draft-ietf-tvr-schedule-
yang-12, 10 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-tvr-
schedule-yang-12>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
King, et al. Expires 3 January 2027 [Page 34]
Internet-Draft TVR Requirements July 2026
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X.,
Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model
for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346,
March 2018, <https://www.rfc-editor.org/info/rfc8346>.
[RFC8944] Dong, J., Wei, X., Wu, Q., Boucadair, M., and A. Liu, "A
YANG Data Model for Layer 2 Network Topologies", RFC 8944,
DOI 10.17487/RFC8944, November 2020,
<https://www.rfc-editor.org/info/rfc8944>.
[RFC9473] Enghardt, R. and C. Krähenbühl, "A Vocabulary of Path
Properties", RFC 9473, DOI 10.17487/RFC9473, September
2023, <https://www.rfc-editor.org/info/rfc9473>.
[RFC9907] Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines
for Authors and Reviewers of Documents Containing YANG
Data Models", BCP 216, RFC 9907, DOI 10.17487/RFC9907,
March 2026, <https://www.rfc-editor.org/info/rfc9907>.
[X.731] ITU, "Information Technology - Open Systems
Interconnection - System Management: State Management
Function", ITU-T X.731, 31 January 1993,
<https://www.itu.int/rec/T-REC-X.731>.
Authors' Addresses
D. King
Lancaster University
Email: d.king@lancaster.ac.uk
L. M. Contreras
Telefonica
Email: luismiguel.contrerasmurillo@telefonica.com
B. Sipos
JHU/APL
Email: brian.sipos+ietf@gmail.com
L. Zhang
Huawei
King, et al. Expires 3 January 2027 [Page 35]
Internet-Draft TVR Requirements July 2026
Email: zhangli344@huawei.com
King, et al. Expires 3 January 2027 [Page 36]