Internet-Draft | tvr-requirements | September 2024 |
King, et al. | Expires 17 March 2025 | [Page] |
Time-Variant Routing (TVR) refers to calculating a path or subpath 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 where TVR computations could improve message exchange in a network.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may 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.¶
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 17 March 2025.¶
Copyright (c) 2024 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.¶
Specific terms used within this document are as follows:¶
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 may also be requested, especially post-topology changes due to disruptive events. However, there are a growing number of use cases where changes to the routing topology are an expected part of network operations. In these scenarios, the pre-planned loss and restoration of an adjacency, or formation of an alternate adjacency, should be seen as a non-disruptive event.¶
Time-Variant Routing (TVR) refers to calculating a path or subpath 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.¶
Planned resource scheduling will be required for various scenarios; these include networks with mobile entities, such as crewless aerial vehicles and orbiting satellite constellations [I-D.ietf-tvr-use-cases]. 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 green computing and energy efficiency over data rate.¶
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:¶
There is also the possibility of an intermediate situation 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 allows a more distributed use of scheduled data than centralizing its processing in an Orchestrator.¶
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:¶
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.¶
Depending on the visibility of schedules within a data model (see Section 3.1.1) there are different options for where the schedule may be executed, and ultimately influence a time-varying configuration on a managed device.¶
Two extremes for locality of schedule execution are:¶
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.¶
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 may be made to bring it back into alignment with the other devices or the other devices' configurations must be rolled-back into consistency which will then cause all the devices to be off-schedule.¶
When schedules are executed on each device, there is a risk that clocks on different devices become desynchronized 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., GPS time) 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.¶
This section covers different aspects of how temporality applies to any potential TVR information model. Each aspect is roughly independent and informs how a model can choose to include temporality in its parameter space.¶
One aspect of any time-varying model is the scope of what may be time-variable. Two extremes of this aspect are:¶
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-varying model is the granularity of state to which a schedule can be applied. Two extremes of this aspect are:¶
It is expected that the use of time-variability to data models will fit within these extremes, possibly applying a schedule to each entity indicating when that entity is valid or invalid, or applying a schedule to groups of properties within the entity (while leaving other properties time-invariant).¶
In an idealized model the schedules will apply indefinitely far in the past and the future, but in a realizable 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 model itself, with an explicit model parameter indicating the horizon. In other cases the model may allow indefinitely-large schedules but the processing of the planning timeline is bounded to limit resource needs.¶
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.¶
Within a single schedule over the planning 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.¶
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.¶
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 periodic change of state is to combine a set of absolute time intervals with a periodic parameterization (duration valid and duration invalid); this is the mdoel of [AIXM].¶
A model which does not include the notion of periodicity within a schedule could be used in situations where discrete intervals of validity are needed to handle periodic state changes which is neither storage nor processing efficient.¶
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.¶
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, it enables the concept of an "overlay" where a long-duration state can be temporarily (in schedule time) superseded by a short-duration state.¶
When a schedule is applied to an entity in a way which is more granular (Section 3.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:¶
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.¶
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:¶
The primary entities of a topological network model, as realized in [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 3.1 these are the entities to which an intrinsic schedule can be applied.¶
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 may define an interpolation method, either globally or per-property.¶
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, that validity could apply to all of its termination points and links as well. This logic allows a schedule to represent, for example, the expected power-on state of a node at a specific layer.¶
When a schedule is applied to a termination point the granularity should at least be at the individual entity. In cases where the properties of a termination point have time-variable values the model may define an interpolation method, either globally or per-property.¶
A termination point is associated with an IP address in Layer 3 [RFC8346] and a MAC address 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, that validity may apply to all of its links as well. 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.¶
When a schedule is applied to a link the granularity should at least be at the individual link. In cases where the properties of a link have time-variable values the model should 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 should 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 should not apply to its termination points and nodes. This logic allows a schedule to represent, for example, the expected connectivity state, data throughput/rate, and latency/delay of a link.¶
When a schedule indicates that an entity is not valid for a schedule time instant, that validity should not apply to 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.¶
Traditional network routing techniques typically use link bandwidth and delay for path calculation, and do not consider time-based factors. TVR should 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 must be capable of handling planned and unexpected resource losses.¶
Time-Variant Routing (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 in TVR networks.¶
Three scenarios are currently considered when computing TVR-enabled paths.¶
The network entities will receive the time variable information and traffic forwarding rules directly from a logically centralized source, an Orchestrator. The time-variable data may then be processed locally by the entity entered into the scheduled routing table and specific forwarding rules applied.¶
Network entities may 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 may be considered when making forwarding decisions for per-hop packets or calculating traffic engineered end-to-end paths. It should be noted that schedule distribution and entity computation latency may exist in some network environments.¶
In some environments, scheduling information may distributed through a management plane mechanism, such as NETCONF or gnmi, instead of the routing scheme.¶
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.¶
Time-variant network constraints may 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:¶
Several TVR use cases have been identified and discussed in [I-D.ietf-tvr-use-cases]. This section provides further detail on specific requirements to meet use case needs.¶
Several operational efficiency requirements exist; these include:¶
In Time-Variant Routing, scheduling of available entity resources is expected is expected. In practical situations, however, the properties of entities can be converted back and forth between Time-Variant and Non-Time-Variant nodes.¶
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.¶
A manager should provide an advertisement methodology for responding to abnormal changes in the system.¶
Proxies can help to improve the efficiency of the network. There are some entities in the network that do not have routing functions. When their properties change, they are unable to notify other entities in the network. Proxy nodes can help nodes without routing functions to advertise information, thus improving the efficiency of the network. Therefore,¶
o Must support proxy entities to help non-routing nodes implement information advertisement.¶
The entity properties of the network may change as described in 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,¶
o Must provide a discovery and resolving methodology for the identification and classification of entity schedule changes.¶
The system's schedule may change, requiring entity configuration updates instead it being set once and not being able to be modified. Additionally, time-variant intervals in the system may also vary. Therefore,¶
o Must support system schedule changes.¶
o Must support time interval changes.¶
The accuracy of the time cannot be too large or too small; otherwise, convergence may not be possible. Therefore,¶
o Must support appropriate time tolerance.¶
Using time-variant mechanisms introduces unique security vulnerabilities that must 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.¶
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 may 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.¶
Time variant networks may 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 ability 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 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.¶
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.¶
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.¶
Replay Attacks on Time-Sensitive Data: Time variant network data and schedule updates may 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, which negates these types of attacks and verify the validity and timeliness of received information.¶
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. 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 should implement multiple, redundant time sources 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.¶
This document has no IANA actions.¶
This work has benefited from the particpation of the TVR working group and the discussions on the mailing list.¶
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).¶
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¶