| Internet-Draft | tvr-requirements | September 2023 |
| King, et al. | Expires 9 March 2024 | [Page] |
Time-Variant Routing (TVR) involves calculating a path, or subpath within a network, taking into account the timing of message transmission or receipt as an integral part of the overall route computation. The results of a TVR computation are influenced by the specific time at which the path is needed, and the computation is performed without any discernible alterations to the network topology or other cost functions associated with the route.¶
This document introduces requirements for TVR computations to improve network communication and resource efficiency.¶
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 9 March 2024.¶
Copyright (c) 2023 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.¶
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.¶
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, optimisation 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 that the calculation is performed without other detectable changes to the network topology or other cost functions associated with the route.¶
TVR-based network topologies may be either a) systems with intrinsic topological changes; b) systems with occasional topological changes.¶
Planned resource scheduling will be required for various scenarios; these include networks with mobile nodes, 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.¶
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 an application 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 precison of wall-clocks which implement 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 accomodate 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 periodicy 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 RECOMMENDED 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 invaraint might not be enforcable 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 temporarilly (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 possibile 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" of a link at a node. Following the concepts described in Section 3.1 the nodes and links are the entities to which a schedule can be applied. Furthermore, topological changes could also be advertised as partial changes of a given topology.¶
Existing routing techniques are not typically designed to handle potential connectivity, i.e., nodes and links scheduled to appear in the future. Therefore, the TVR Scenarios and use cases referenced and discussed in this document will be compromised of scheduled resources that are expected to appear in the future.¶
However, even if some adjacency failures are predictable, others are not, including link failures and node outages. Therefore, any new technique or routing protocol extension for TVR enviroments must be capable of handling planned and unexpected resource losses.¶
TBD¶
Several TVR use cases have been identifed and discussed in [I-D.ietf-tvr-use-cases].¶
This document has no IANA actions.¶