Time-Variant Routing L. Zhang
Internet-Draft J. Dong
Intended status: Informational Huawei
Expires: 1 September 2025 M. Boucadair
Orange
28 February 2025
Applicability of TVR YANG Data Models
draft-zdm-tvr-applicability-02
Abstract
Time-Variant Routing (TVR) is a routing system that can support the
predicted topology changes caused by internal or external reasons.
Typical use cases include resource preservation networks, operating
efficiency networks and dynamic reachability networks. This document
provides examples of how to implement the TVR scheduling capabilities
for key use cases. It describes which part of the TVR data model is
used and why, and it outlines operational and security considerations
when deploying TVR-based technologies.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 1 September 2025.
Copyright Notice
Copyright (c) 2025 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
Zhang, et al. Expires 1 September 2025 [Page 1]
Internet-Draft Applicability Statement February 2025
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Use Case Examples . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Tidal Network Use Case . . . . . . . . . . . . . . . . . 3
3.2. Dynamic Reachability Use Case . . . . . . . . . . . . . . 4
4. Applicability of TVR Yang Model . . . . . . . . . . . . . . . 4
4.1. Network Model . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. Centralized Model . . . . . . . . . . . . . . . . . . 4
4.1.2. Distributed Model . . . . . . . . . . . . . . . . . . 5
4.2. Interaction Between Devices . . . . . . . . . . . . . . . 5
4.2.1. Interactions in Centralized Model . . . . . . . . . . 5
4.2.2. Interactions in Distributed Model . . . . . . . . . . 6
4.3. Encoding of the YANG Model . . . . . . . . . . . . . . . 6
4.4. Management Protocols for TVR . . . . . . . . . . . . . . 7
5. Time Synchronization . . . . . . . . . . . . . . . . . . . . 8
5.1. Hardware-based Time Synchronization Mechanisms . . . . . 9
5.2. Software-based Time Synchronization Protocols . . . . . . 10
5.2.1. NTP . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.2. SNTP . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Schedule Database . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Data Structure . . . . . . . . . . . . . . . . . . . . . 12
6.2. Schedule Operations . . . . . . . . . . . . . . . . . . . 12
7. Operational Considerations . . . . . . . . . . . . . . . . . 13
7.1. Schedule Execution Consideration . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8.1. Denial-of-Service (DoS) Attack . . . . . . . . . . . . . 15
8.2. Traffic Analysis and Path Prediction . . . . . . . . . . 15
8.3. Activity Identification and Privacy . . . . . . . . . . . 16
8.4. Spoofing and Manipulation of Time Information . . . . . . 16
8.5. Replay Attacks on Time-Sensitive Data . . . . . . . . . . 16
8.6. Compromised Time Sources . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A: Code Examples . . . . . . . . . . . . . . . . . . . . 18
Code Examples for Tidal Network . . . . . . . . . . . . . . . . 18
Code Examples for Dynamic Reachability Network . . . . . . . . 20
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Zhang, et al. Expires 1 September 2025 [Page 2]
Internet-Draft Applicability Statement February 2025
1. Introduction
The Time-Variant Routing (TVR) Working Group addresses a growing need
in modern network environments where predictable variations in
topology - such as the restoration, activation, or loss of network
elements, are part of normal operations. This approach is essential
in dynamic networks with mobile nodes, where links may be frequently
disrupted and re-established due to mobility or in networks with
highly predictable traffic patterns, where links may be powered down
to conserve or reduce energy.
This document provides examples of implementing TVR scheduling
capabilities in identified use cases. It demonstrates the
applicability of the TVR data model, methods for disseminating the
TVR schedule, and the necessary IETF ancillary technologies for
network environments, such as time synchronization and policy, that
support TVR capabilities.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Use Case Examples
3.1. Tidal Network Use Case
A tidal network is a typical scenario of an Energy Efficient case
(Section 3 of [I-D.ietf-tvr-use-cases]). The tidal network means
that the volume of traffic in the network changes periodically, like
the ocean tide. These changes are mainly affected by human
activities. Therefore, this tidal effect is obvious in human-
populated areas, such as campuses and airports.
In the context of a tidal network, if the network maintains all the
devices up to guarantee a maximum throughput all the time, often,
power will be wasted on network resources that are not being used.
Energy-saving methods may include the deactivation of some or all
components of network nodes. These activities have the potential to
alter network topology and impact data routing/forwarding in a
variety of ways. Interfaces on network nodes can be selectively
disabled or enabled based on traffic patterns, thereby reducing the
energy consumption of nodes during periods of low network traffic.
Zhang, et al. Expires 1 September 2025 [Page 3]
Internet-Draft Applicability Statement February 2025
3.2. Dynamic Reachability Use Case
Dynamic Reachability referred to the scenarios where a node is placed
on a mobile platform, the mobility of the platform may cause changes
to the topology of the network over timeSection 4 of
[I-D.ietf-tvr-use-cases]. As the relative mobility between and among
nodes in the network and the impacts of the environment on the signal
propagation can be predicted, the associated loss and establishment
of adjacencies can also be planned for.
The typical detailed use cases of Dynamic Reachability include but
not limited to satellite network, predictable moving vessels and
vehicles.
4. Applicability of TVR Yang Model
4.1. Network Model
According to the description of Section 3.1 of
[I-D.ietf-tvr-requirements], the scheduling generation locality and
execution locality may be centralized or distributed.
When the schedule is generated and executed in a centralized manner
and within the same device, the changes are sent to routing
applications in wall-clock time via a management interface, which
does not need to be delivered by the YANG model. This can be
implemented using the existing management plane technology.
Therefore, this scenario is outside of the scope of this document.
When the schedule is generated and executed in a distributed manner,
which means that each node generates its specific schedules. In this
scenario, there is also no need for delivering the schedule by the
YANG model. Therefore, this scenario is also outside of the scope of
this document.
When a schedule is generated in a centralized manner and executed in
a distributed manner, the YANG module needs to be used to deliver the
schedule to the managed device. Depending on the location of the
routing application, the network model can be divided into two types:
distributed and centralized.
4.1.1. Centralized Model
In the centralized model, the network managing device generates and
maintains schedules, the routing application is deployed in the
network controller, and the network devices execute the schedules and
routing results. The following figure shows the components of the
centralized model.
Zhang, et al. Expires 1 September 2025 [Page 4]
Internet-Draft Applicability Statement February 2025
+-----------------------------------------------------------------+
| Managing Device |
+-----------------------------------------------------------------+
| |
Data Model Data Model
| |
+---------\|/----------+ +--------\|/--------+
| Network Controller |---Routing Results-->| Network Devices |
+----------------------+ +-------------------+
Figure 1: Components of Centralized Model
4.1.2. Distributed Model
In the distributed model, the managing device generates and maintains
schedules, the routing application is deployed in the network devices
which also executes schedules and route calculation.
+-------------------------------------------------+
| Managing Device |
+-------------------------------------------------+
|
Data Model
|
+-----------------------\|/-----------------------+
| Managed Device (Network Devices) |
+-------------------------------------------------+
Figure 2: Components of Distributed Model
4.2. Interaction Between Devices
4.2.1. Interactions in Centralized Model
A centralized model involves the interaction between the managing
device and network controller, the managing device and network
devices, and the controller and network devices.
The managing device needs to deliver node-specific schedules to
network devices by TVR Schedule Node YANG module Section 5.2 of
[I-D.ietf-tvr-schedule-yang], and the network devices need to report
their own status data to the management device.
The managing device needs to deliver schedules of the network
topology to the network controller by the TVR Network Topology YANG
moduleSection 5.3 of [I-D.ietf-tvr-schedule-yang], so that the
routing application in the controller can consider the impact of
topology changes on routes when calculating routes.
Zhang, et al. Expires 1 September 2025 [Page 5]
Internet-Draft Applicability Statement February 2025
The network controller should deliver the route calculation result to
the network devices. The format of the routing results depend on the
protocols deployed (The typical protocols include BGP, PCEP, etc.).
The routing result for a period in the future could be sent to the
network devices in wall-clock time or be packed and sent at some
special points.
4.2.2. Interactions in Distributed Model
The distributed model only involves the interaction between managing
devices and network devices.
The managing device must deliver node-specific schedules to network
devices by TVR Schedule Node YANG Module and deliver network topology
schedules to all the network devices by TVR Network Topology Yang
module for route calculation. The network devices must report their
status data to the managing device. Editor’s note: In future
versions of this document, we will provide a more detailed procedure
for both the distributed and centralized approach.
4.3. Encoding of the YANG Model
The TVR data model [I-D.ietf-tvr-schedule-yang] can manage network
resources and topologies with scheduled attributes. There are
modules defined in the TVR data model, these are:
* The “ietf-tvr-schedule” module contains the schedule YANG
definitions. This module uses groupings from
[I-D.ietf-netmod-schedule-yang] data model;
* The “ietf-tvr-topology” module defines a network topology with a
time-variant availability schedule;
* The “ietf-tvr-node” module is to be used to manage the scheduled
attributes of a single node.
To create a schedule, the following TVR data model objects and
subsequent branches are used:
* ‘node-schedule’
* ‘interface-schedule’
* ‘attribute-schedule’
A TVR scenario example is provided below, where a wireless link is
shut down for 12 hours, from 19:00 to 7am the next day. The schedule
is identified using a unique identifier that is conveyed in
Zhang, et al. Expires 1 September 2025 [Page 6]
Internet-Draft Applicability Statement February 2025
‘schedule-id’, and the recurring schedule can be applied for multiple
days using Coordinated Universal Time (UTC). A more detailed example
of the json code is provided in this documents Appendix.
{
"ietf-tvr-node:node-schedule":[
{
"node-id":1234567890,
"node-power-schedule":{
"power-default":true,
},
"interface-schedule":[
{
"name":"Wlan0",
"default-available":false,
"attribute-schedule":{
"schedules":[
{
"schedule-id":111111,
"recurrence-first":{
"utc-start-time":"2025-12-01T19:00:00Z",
"duration":43200
},
"utc-until":"2026-12-01T00:00:00Z",
"frequency":"ietf-schedule:daily",
"interval":1,
"attr-value":{
"available":true
}
}
]
}
}
]
}
]
}
The methods for disseminating and propagating the generated schedule
are discussed in the following subsections.
4.4. Management Protocols for TVR
The TVR data model is designed to be accessed via YANG-based
management protocols such as NETCONF [RFC6241] and RESTCONF
[RFC8040]. This section discusses the applicability of these
protocols for configuring time-variant network resources using the
TVR YANG data models.
Zhang, et al. Expires 1 September 2025 [Page 7]
Internet-Draft Applicability Statement February 2025
NETCONF provides a robust mechanism for managing complex network
configurations, particularly when transactional integrity and
operational consistency are required. Its ability to execute atomic
transactions ensures that schedules involving multiple resources are
applied fully, preventing partial updates that could lead to
configuration inconsistencies. This feature is important for time-
sensitive scheduling in TVR environments. Additionally, NETCONF
supports the validation of configurations prior to commitment,
allowing operators to verify the correctness of schedules before they
are applied. It also includes rollback capabilities, such as
restoring a previous configuration during scheduling errors.
In contrast, RESTCONF offers a simpler, stateless method for
interacting with network devices, making it suitable for use cases
requiring lightweight, rapid configuration. RESTCONF utilizes a
RESTful interface over HTTP, providing a streamlined approach to
network configuration and management. Therefore, RESTCONF may be
advantageous in scenarios where quick adjustments to schedules are
needed or where integration with web-based or cloud-native systems is
a priority.
Depending on the type of node in the TVR network, NETCONF would be
the preferred protocol for large-scale, critical scheduling
operations requiring validation and rollback mechanisms. For
smaller-scale or isolated scheduling tasks, RESTCONF provides an
efficient and straightforward option without the need for the
transactional features offered by NETCONF. The choice of protocol to
use with the TVR YANG model should be driven by the specific
requirements of the network environment and the complexity of the
scheduling tasks involved.
The security aspects of both NETCONF and RESTCONF, including their
strengths and weaknesses, are discussed further in Section 8 of this
document.
5. Time Synchronization
According to Section 3.1.3 of [I-D.ietf-tvr-requirements], no matter
whether the schedules are executed in a centralized or distributed
mode, a mechanism is required to keep the time synchronization
between different devices.
Zhang, et al. Expires 1 September 2025 [Page 8]
Internet-Draft Applicability Statement February 2025
Different time-variant scenarios may require different granularities
of time synchronization. For example, the period of traffic and
topology changes in tidal networks is usually a day or week.
Therefore, a second-level time synchronization is enough. However,
for the dynamic reachability scenarios, a fine-granularity time
synchronization may be necessary, as the nodes may moving very fast
in some cases(the moving speed of a low earth orbit satellite is more
than 7900 m/s)
Existing clock synchronization protocols can be classified into
hardware-based protocols and software-based protocols. Hardware-
based protocols often rely on dedicated hardware to ensure clock
synchronization, such as Global Positioning System (GPS) and
Precision Time Protocol (PTP). Software-based protocols, on the
other hand, synchronize clocks through software packages running on
systems, such as Network Time Protocol (NTP) [RFC5905] and Simple
Network Time Protocol (SNTP) [RFC4330].
The security aspects of time synchronization mechanisms are discussed
further in Section 8 of this document.
5.1. Hardware-based Time Synchronization Mechanisms
Hardware-based protocols typically have higher precision and
stability, but also have higher cost due to the dedicated hardware.
GPS and PTP are the typical hardware-based time synchronization
mechanisms.
GPS provides a precise time synchronization service based on the
signals transmitted by the GPS satellites. GPS can realize the
micro-second level time synchronization among the devices installed
with GPS reviver hardware.
PTP is a network protocol that complies with the IEEE 1588 standard
and is used to implement high-precision time synchronization between
network nodes. PTP implements time synchronization by transmitting
synchronization messages between master and slave devices. Based on
the hardware timestamp, the precision of time synchronization is much
higher than that of NTP, and can reach the sub-microsecond level or
even tens of nanoseconds. When deploying PTP in TVR networks, the
managing devices should be the master and the network devices and
controller should be the slaves which get time from the master.
Zhang, et al. Expires 1 September 2025 [Page 9]
Internet-Draft Applicability Statement February 2025
Both GPS and PTP can realize micro-second level time synchronization.
Depending on the features of TVR network, the GPS would be the
preferred mechanisms for large-scale, high dynamic and open-air
networks, especially networks with unreliable links as it does not
require network links to exchange time information. For the small-
scale networks with stable links but have high-precision time
synchronization requirements, the PTP is much preferred.
5.2. Software-based Time Synchronization Protocols
Software-based protocols are simple and applicable to common hardware
devices, but have lower precision (For example, the NTP can realize
the synchronization at tens of milliseconds level).
5.2.1. NTP
NTP is fundamental for ensuring that TVR mechanisms, which depend on
highly accurate timing, function as intended across an entire
network. Misalignment in time could lead to serious routing issues,
including inefficiency in path forwarding, instability in routing
tables, and traffic outages.
NTP will be used to ensure:
* Coordination of Planned Network Events;
* Verification of TVR Data Model Time Stamps
* Accurate Scheduling of Paths;
* Fault Tolerance.
NTP uses a hierarchical structure of time sources. Each level of
this hierarchy is termed a stratum. Generally, an NTP server
synchronized to an authoritative clock runs at stratum 1. Such NTP
server functions as the primary time server to provide clock
synchronization for other devices on the network. Stratum 2 servers
obtain time from stratum 1 servers, stratum 3 servers obtain time
from stratum 2 servers, and so on.
In TVR use cases, the managing device functions as a level-1 NTP
server and synchronized to an authoritative clock source. The
network controller and network devices behave as clients to obtain
accurate time from the managing device. Figure 3 shows an NTP
deployment scenario for obtaining clock from a GPS clock source.
Zhang, et al. Expires 1 September 2025 [Page 10]
Internet-Draft Applicability Statement February 2025
+--------------------+
| GPS Clock Source |
+--------------------+
|
+--------------------\|/------------------+
Stratum 1 | Managing Device |
+-----------------------------------------+
| |
| |
| |
+---------\|/----------+ +--------\|/--------+
Stratum 2 | Network Controller | | Network Devices |
+----------------------+ +-------------------+
Figure 3: Deployment Case of NTP in Tidal Networks
NTP is preferred in large-scale networks with reliable links and
long-term changes, which dose not require a high-precision time
synchronization.
5.2.2. SNTP
SNTP is a subset of the NTP used to synchronize computer clocks in
the Internet. It simplifies the complex NTP synchronization function
and has lower clock precision, but the synchronization precision
still can be guarded under seconds. SNTP is also preferred in large-
scale networks with reliable links, long-term changes, and loose
synchronization precision. In addition, it is more suitable for
networks with limited resources than NTP.
6. Schedule Database
The schedule database is used to store and maintain schedules, the
database may be deployed on a managing device and managed devices
based on requirements.
The schedule source of the schedule database may be diversified, for
example, configuration from an administrator or YANG model from the
management interface. The schedule entries of different databases
may be different, but the content of the same schedule entry in the
schedule databases of different devices in the same domain must be
consistent. There are at least two ways to make the content of the
same schedule entry in different schedule databases consistent:
* All the schedule entries are generated at a specific device;
Zhang, et al. Expires 1 September 2025 [Page 11]
Internet-Draft Applicability Statement February 2025
* Schedule entries are generated at different devices, but there is
a synchronization mechanism to synchronize the schedule databases
among devices.
Option 1 is simplest and easy to implement. In a time-variant
domain, the managing device may receive scheduling requests and
generate all schedule entries. Then the schedule entries are
delivered to the necessary network devices in the domain through the
TVR YANG model.
Option 2 relies on advertisement mechanisms (such as routing
techniques) to advertise the scheduling data generated by itself to
other devices. This could be achieved using extensions to existing
routing schemes and techniques.
These options will be discussed with the TVR Working Group, and
agreed approaches will be documented in future versions of this
Internet Draft.
6.1. Data Structure
[I-D.ietf-tvr-schedule-yang] defines a TVR Node and TVR Topology YANG
modules. The Node YANG module includes node power schedule and
interface schedule. The Topology YANG module includes nodes schedule
and links schedule.
Based on the preceding four schedule types, the schedule database
should contain four types of schedule entries in different formats:
* Node power schedule entry;
* Interface schedule entry;
* Node schedule entry;
* Links schedule entry;
The detailed format and fields of different types of schedule entries
could reference to the definitions of the corresponding YANG modules.
Editor’s note: Code examples will be provided here in future versions
of this document.
6.2. Schedule Operations
This section provides general requirements for using the TVR
schedule.
Zhang, et al. Expires 1 September 2025 [Page 12]
Internet-Draft Applicability Statement February 2025
The schedule database should support the add, update, and delete
operations.
When adding or updating a schedule entry, the execution node needs to
check whether resource conflicts exist between the current schedule
and existing schedules. If a conflict exists, the operation should
be failed.
Schedules are updated and deleted based on schedule IDs. Therefore,
schedule IDs must be unique in a time-variant domain. This can be
handled, e.g., by a dedicated allocation agent within the time-
variant domain.
Editor’s note: Future versions of this document will expand on the
schedule operations requirements and best practices.
7. Operational Considerations
Several operational considerations exist when using TVR techniques
and data models in a network. This section provides some high-level
observations and more detailed sub-sections for specific
consideration related to schedule dissemination, execution, and
recovery in case of failure to apply a schedule or partial change.
* Coordinated Network Events: TVR often coordinates routing changes
anticipating events like predictable low-traffic periods or link
downtimes (e.g., scheduled maintenance or traffic demand).
* Accurate Scheduling of Paths: TVR schedule capable routers and
network nodes will dynamically adjust forwarding paths based on
planned changes in link availability or network conditions.
* Time-Stamped Data Models: TVR will require the use time-stamped
data models (e.g., schedules for link changes or availability
windows) to make interface management decisions. This ensures
that all TVR nodes interpret the timing of events consistently and
implement time-based policies correctly.
Therefore, network time accuracy and time-stamped data models are
critical to ensure that coordinated network events and scheduled path
decisions across the network are based on a consistent time
reference. Without accurate time sync, nodes could apply different
schedules, causing routing inconsistencies, path flapping, or packet
loss.
Zhang, et al. Expires 1 September 2025 [Page 13]
Internet-Draft Applicability Statement February 2025
7.1. Schedule Execution Consideration
Schedules execution means that a component (e.g., device) undertakes
an action (e.g., allocates and deallocates resources) at specified
time points. In a tidal network, the schedule execution indicates
powering on/off specific network components (such as interfaces or
entire network devices) directly or by commands.
The schedule executor should understand the consequences of the
schedule execution. The power on/off network components usually
affects the network topology, the addition and deletion of the
topology need to be considered separately.
A link coming up or a node joining a topology should not have any
functional change until the change is proven to be fully operational.
The routing paths may be pre-computed but should not be installed
before all the topology changes are confirmed to be operational. The
benefits of this pre-computation appear to be very small. The
network may choose to not do any pre-installation or pre-computation
in reaction to topological additions at a small cost of some
operational efficiency.
Topological deletions are an entirely different matter. If a link or
node is to be removed from the topology, then the network should act
before the anticipated change to route traffic around the expected
topological change. Specifically, at some point before the planned
topology change, the routing paths should be pre-computed and
installed before the topology change takes place. The required time
to perform such planned action will vary depending on the exact
network and configuration. When using an IGP or other distributed
routing protocols, the affected links may be set to a high metric to
direct traffic to alternate paths. This type of change does require
some time to propagate through the network, so the metric change
should be initiated far enough in advance that the network converges
before the actual topological change.
Editor's Note: multi-manager scenarios need to be considered.
8. Security Considerations
The integration of time-variant mechanisms in network operations
presents distinct security challenges that require thorough analysis
to safeguard the network’s integrity, availability, and
confidentiality. Networks that rely on time-sensitive data for
routing and forwarding decisions are particularly susceptible to
attacks that exploit timing dependencies.
Zhang, et al. Expires 1 September 2025 [Page 14]
Internet-Draft Applicability Statement February 2025
The "Security Considerations" section of [I-D.ietf-tvr-requirements]
outlines various threat vectors and categories specific to time-
variant environments.
8.1. Denial-of-Service (DoS) Attack
In a time variant network, malicious actors could attack the network
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.
This kind of attack could be mitigated by the redundancy time
synchronization mechanisms, for example, multiple NTP sources or
multiple time synchronization protocols could be deployed in a TVR
network. The network devices could guarantee the correctness of the
time by checking whether the time signals from different sources or
protocols.
In addition, the identification authentication is also an important
way to protect the time signals being tampered by attackers. Some
security extensions for time synchronization protocols (such as NTS
(Network Time Security)) are recommended to be applied.
8.2. Traffic Analysis and Path Prediction
In a time variant network, if time information is not adequately
protected, attackers could conduct traffic analysis to infer routing
decisions, network load, or usage patterns. The schedule ability
could enable attackers to launch highly targeted attacks, such as
selectively overloading certain links or intercepting sensitive
communications.
This kind of attack could be mitigated by the encryption of schedules
and the authentication of managing devices. For the networks using
NETCONF to deliver schedules, NETCONF over TLS[RFC7589] is
recommended to achieve the bidirectional authentication and
encryption of YANG model data. RESTCONF supports TLS originally, so
it can be deployed without additional configurations or
modifications.
In addition, in time variant networks with centralized
modelSection 4.1.1, the encryption of routing path information is
also necessary to avoid the fake routing information. Considering
the most typical protocols used to deliver the routing path
information between controller and network devices are BGP and PCEP,
and both are based on TCP. Therefore, the TLS is recommended to be
applied for the conservation.
Zhang, et al. Expires 1 September 2025 [Page 15]
Internet-Draft Applicability Statement February 2025
8.3. 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.
This risk could also be mitigated by the solutions mentioned in
Section 8.3.
8.4. Spoofing and Manipulation of Time Information
In a time variant network, 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.
This risk could also be mitigated by the solutions mentioned in
Section 8.1.
8.5. Replay Attacks on Time-Sensitive Data
Time variant network data and schedule updates may be susceptible to
replay attacks, which 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.
This kind of attack could be mitigated by encrypting time signals,
schedules and routing path data, and adding a unique number to the
encrypted section of a packet. This has been implemented in existing
protocols, for example, the NTS supports unique identifier extension
field (EF) containing a random number, the TLS supports Message
Authentication Code generated from sequence number.
8.6. 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 GPS signal or an NTP server, is
compromised, the attacker could feed erroneous time information to
the entire network, disrupting its operation.
This kind of attack could be mitigated by implement multiple,
redundant time sources or time synchronization protocols and
regularly verify the integrity of these sources. In addition,
alerting mechanisms should be in place to detect significant
deviations in time data that could indicate an attack.
Zhang, et al. Expires 1 September 2025 [Page 16]
Internet-Draft Applicability Statement February 2025
9. IANA Considerations
This document has no IANA actions.
10. References
10.1. Normative References
[I-D.ietf-tvr-schedule-yang]
Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M.
Blanchet, "YANG Data Model for Scheduled Attributes", Work
in Progress, Internet-Draft, draft-ietf-tvr-schedule-yang-
03, 20 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-tvr-
schedule-yang-03>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
10.2. Informative References
[I-D.ietf-netmod-schedule-yang]
Ma, Q., Wu, Q., Boucadair, M., and D. King, "A Common YANG
Data Model for Scheduling", Work in Progress, Internet-
Draft, draft-ietf-netmod-schedule-yang-04, 7 February
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
netmod-schedule-yang-04>.
[I-D.ietf-tvr-requirements]
King, D., Contreras, L. M., Sipos, B., and L. Zhang, "TVR
(Time-Variant Routing) Requirements", Work in Progress,
Internet-Draft, draft-ietf-tvr-requirements-04, 13
September 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-tvr-requirements-04>.
[I-D.ietf-tvr-use-cases]
Birrane, E. J., Kuhn, N., Qu, Y., Taylor, R., and L.
Zhang, "TVR (Time-Variant Routing) Use Cases", Work in
Progress, Internet-Draft, draft-ietf-tvr-use-cases-09, 29
February 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-tvr-use-cases-09>.
Zhang, et al. Expires 1 September 2025 [Page 17]
Internet-Draft Applicability Statement February 2025
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 4330, DOI 10.17487/RFC4330,
January 2006, <https://www.rfc-editor.org/rfc/rfc4330>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/rfc/rfc5905>.
[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/rfc/rfc6241>.
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication", RFC 7589,
DOI 10.17487/RFC7589, June 2015,
<https://www.rfc-editor.org/rfc/rfc7589>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/rfc/rfc8040>.
Acknowledgments
TODO acknowledge.
Appendix A: Code Examples
Code Examples for Tidal Network
Tidal networks usually need to manage the availability of some node
or interfaces. Figure 4 shows the example of a scheduling node that
is powered on from 12 AM, December 1, 2025 to 12 AM, December 1, 2026
in UTC and its interface named "interface1" is scheduled to be
enabled at 7:00 AM and disabled at 1:00 AM, every day, from December
1, 2025 to December 1, 2026 in UTC.
The JSON encoding is used only for illustration purposes.
Zhang, et al. Expires 1 September 2025 [Page 18]
Internet-Draft Applicability Statement February 2025
{
"ietf-tvr-node:node-schedule":[
{
"node-id":12345678,
"node-power-schedule":{
"power-default":false,
"schedules":[
{
"schedule-id":111111,
"period-start":"2025-12-01T00:00:00Z",
"period-end":"2026-12-01T00:00:00Z",
"attr-value":{
"power-state":true
}
}
]
},
"interface-schedule":[
{
"name":"interace1",
"default-available":false,
"default-bandwidth":1000000000,
"attribute-schedule":{
"schedules":[
{
"schedule-id":222222,
"recurrence-first":{
"utc-start-time":"2025-12-01T07:00:00Z",
"duration":64800
},
"utc-until":"2026-12-01T00:00:00Z",
"frequency":"ietf-schedule:daily",
"interval":1,
"attr-value":{
"available":true
}
}
]
}
}
]
}
]
}
Figure 4: An Example of Interface Activation Scheduling
Zhang, et al. Expires 1 September 2025 [Page 19]
Internet-Draft Applicability Statement February 2025
Code Examples for Dynamic Reachability Network
In a dynamic reachability network, the managing device usually needs
to deliver the time-variant network topology to the network devices
for them could react to the predictable topology changes in time.
Figure 5 shows the example of a topology with two nodes and one link.
Due to the moving of these two nodes, the link between these two
nodes will be interrupted from 10:00 AM to 10:05 and 10:10 AM to
10:20 AM, April 1, 2025 in UTC.
The JSON encoding is used only for illustration purposes.
{
"ietf-tvr-topology:topology-schedule": {
"nodes": [
{
"node-id": 10000000,
"available": {
"default-node-available": true,
"schedules": []
}
},
{
"node-id": 10000001,
"available": {
"default-node-available": true,
"schedules": []
}
}
],
"links": [
{
"source-node": 10000000,
"source-link-id": 32,
"available": {
"schedules": [
{
"schedule-id": 111111,
"period-description": "schedule down1",
"period-start": "2025-4-01T10:00:00Z",
"period-end": "2025-4-01T10:05:00Z",
"attr-vaule": {
"link-available": false
}
},
{
"schedule-id": 222222,
"period-description": "schedule down2",
Zhang, et al. Expires 1 September 2025 [Page 20]
Internet-Draft Applicability Statement February 2025
"period-start": "2025-4-01T10:10:00Z",
"period-end": "2025-4-01T10:20:00Z",
"attr-vaule": {
"link-available": false
}
}
]
}
}
]
}
}
Figure 5: An Example of Topology with Link Scheduling
Contributors
Daniel King
Lancaster University
United Kingdom
Email: d.king@lancaster.ac.uk
Charalampos (Haris) Rotsos
Lancaster University
Email: c.rotsos@lancaster.ac.uk
Peng Liu
China Mobile
Email: liupengyjy@chinamobile.com
Tony Li
Juniper Networks
Email: tony.li@tony.li
Authors' Addresses
Li Zhang
Huawei
Email: zhangli344@huawei.com
Jie Dong
Huawei
Email: jie.dong@huawei.com
Zhang, et al. Expires 1 September 2025 [Page 21]
Internet-Draft Applicability Statement February 2025
Mohamed Boucadair
Orange
Email: mohamed.boucadair@orange.com
Zhang, et al. Expires 1 September 2025 [Page 22]