<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.8 (Ruby 3.0.2) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-tvr-use-cases-09" number="9657" updates="" obsoletes="" consensus="true" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.20.1 -->version="3" xml:lang="en"> <front><title abbrev="tvr-use-cases">TVR<!-- [rfced] FYI, the title of the document has been updated as follows; please let us know if you prefer otherwise. Original: TVR (Time-Variant Routing) Use Cases Current: Time-Variant Routing (TVR) Use Cases --> <title abbrev="TVR Use Cases">Time-Variant Routing (TVR) Use Cases</title> <seriesInfoname="Internet-Draft" value="draft-ietf-tvr-use-cases-09"/>name="RFC" value="9657"/> <authorfullname="Ed Birrane">fullname="Edward J. Birrane, III" surname="Birrane, III" initials="E."> <organization>JHU/APL</organization> <address> <email>edward.birrane@jhuapl.edu</email> </address> </author> <author fullname="NicolasKuhn">Kuhn" surname="Kuhn" initials="N."> <organization>Thales Alenia Space</organization> <address> <email>nicolas.kuhn.ietf@gmail.com</email> </address> </author> <author fullname="YingzhenQu">Qu" surname="Qu" initials="Y."> <organization>Futurewei Technologies</organization> <address> <email>yingzhen.ietf@gmail.com</email> </address> </author> <author fullname="RickTaylor">Taylor" surname="Taylor" initials="R."> <organization>Ori Industries</organization> <address> <email>rick.taylor@ori.co</email> </address> </author> <author fullname="Lizhang">Zhang" surname="Zhang" initials="L."> <organization>Huawei</organization> <address> <email>zhangli344@huawei.com</email> </address> </author> <date year="2024"month="March" day="25"/> <area>Routing</area>month="September"/> <area>RTG</area> <workgroup>tvr</workgroup> <keyword>Time-variant</keyword> <keyword>Routing</keyword> <keyword>Mobility</keyword> <keyword>Green computing</keyword> <keyword>Resource management</keyword> <abstract><?line 101?><t>This document introduces use cases where Time-Variant Routing (TVR) computations(i.e.(i.e., routing computationstakingthat take intoconsiderationsconsideration time-based or scheduled changes to a network) could improve routing protocol convergence and/or network performance.</t> </abstract><note removeInRFC="true"> <name>About This Document</name> <t> Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-tvr-use-cases/"/>. </t> <t> Discussion of this document takes place on the Time Variant Routing Working Group mailing list (<eref target="mailto:tvr@ietf.org"/>), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/tvr/"/>. Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/tvr/"/>. </t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/NasaDtn/tvr-bof-use-cases"/>.</t> </note></front> <middle><?line 105?><section anchor="introduction"> <name>Introduction</name> <t>There is a growing number of use cases where changes to the routing topology are an expected part of network operations. In these usecasescases, the pre-planned loss and restoration of an adjacency, or formation of an alternate adjacency, should be seen as anon-disruptivenondisruptive event.</t> <t>Expected changes to topologies can occur for a variety of reasons. In networks with mobile nodes, such as unmanned aerial vehicles and some orbiting spacecraft constellations, links are lost and re-established as a function of the mobility of the platforms. In networks without reliable access to power, such as networks harvesting energy from wind and solar, link activity might be restricted to certain times of day. Similarly, in networks prioritizing green computing and energy efficiency over data rate, network traffic might be planned around energy costs or expected user data volumes.</t> <t>This document defines three categories of use cases where a route computation might beneficially consider time information. Each of these use cases includes the followinginformation.</t>information:</t> <ol spacing="normal"type="1"><li> <t>Antype="1"> <li>An overview of the use case describing how route computations might select different paths (or subpaths) as a function oftime.</t> </li> <li> <t>Atime.</li> <li>A set of assumptions made by the use case as to the nature of the network and dataexchange.</t> </li> <li> <t>Specificexchange.</li> <li>Specific discussion on the routing impacts of the usecase.</t> </li> <li> <t>Examplecase.</li> <li>Example networks conformant to the usecase.</t> </li>case.</li> </ol> <t>The use cases that are considered in this document are the following.</t> <ol spacing="normal"type="1"><li> <t>Resourcetype="1"> <li>Resource Preservation (described in <xref target="Resource-Preservation"/>), where there is information about link availability over time at the client level.Time VariantTime-Variant Routing can utilize the predictability of the link availability to optimize network connectivity by taking into accountend pointendpoint resourcepreservation.</t> </li> <li> <t>Operatingpreservation.</li> <li>Operating Efficiency (described in <xref target="Operating-Efficiency"/>), where there is a server cost or a path cost usage varying over time.Time VariantTime-Variant Routing can exploit the predictability of the path cost to optimize the cost of the system exploitation. The notion of a path cost is extended to be a time-dependent function instead of aconstant.</t> </li> <li> <t>Dynamicconstant.</li> <!--[rfced] Here, "taking part of" reads oddly; does it mean "in"? Original: 3. Dynamic Reachability (described in Section 4), where there is information about link availability variation between nodes taking part of the end-to-end path. Perhaps: 3. Dynamic Reachability (described in Section 4), where there is information about link availability variation between nodes in the end-to-end path. --> <li>Dynamic Reachability (described in <xref target="Dynamic-Reachability"/>), where there is information about link availability variation between nodes taking part of the end-to-end path.Time VariantTime-Variant Routing can exploit the predictability of the link availability to optimize in-networkrouting.</t> </li>routing.</li> </ol> <t>The document does not intend to represent the full set of cases where time-variant routing computations could beneficially impact network performance--- new use cases are expected to be generated over time. Similarly, the concrete examples within each use case are meant to provide an existence proof of the usecase,case and not to present any exhaustive enumeration of potential examples. It is likely thatthere existmultiple example networks exist that could be claimed as instances of any given use case.</t> <t>The document focuses on deterministic scenarios. Non-deterministicscenariosscenarios, such as vehicle-to-vehiclecommunication iscommunication, are out of the scope of the document.</t> </section> <section anchor="Resource-Preservation"> <name>Resource Preservation</name> <t>Some nodes in a network might operate in resource-constrained environments or otherwise with limited internal resources.ConstraintsConstraints, such as available power, thermal ranges, and on-boardstoragestorage, can all impact the instantaneous operation of a node. In particular, resource management on such a node can require that certain functionality be powered on (or off) to extend the ability of the node to participate in the network.</t> <t>When power on a node is running low,non-criticalnoncritical functions on the node might be turned off in favor of extending node life. Alternatively, certain functions on a node may be turned off to allow the node to use available power to respond to an event, such as data collection. When a node is in danger of violating a thermal constraint, normal processing might be paused in favor of a transition to a thermal safe mode until a regular operating condition is reestablished. <!--[rfced] Is "fuse" the correct word here? What does "fuse data" mean in this context? Was "merge" or "compress" intended? Original: When local storage resources run low, a node might choose to expend power resources to fuse, delete, or transmit data off the node to free space for future data collection. --> When local storage resources run low, a node might choose to expend power resources to fuse, delete, or transmit data off the node to free up space for future data collection. There might also be cases where a node experiences a planned offline state to save and accumulate power.</t> <t>In addition to power, thermal, and storage, other resource constraints may exist on a node such that the preservation of resourcesareis necessary to preserve the existence (and proper function) of the node in the network. Nodes operating in these conditions might benefit from TVR computations as the connectivity of the node changes over time as part of node preservation.</t> <section anchor="assumptions"> <name>Assumptions</name> <t>To effectively manage on-board functionality based on available resources, a node must comprehend specific aspects concerning the utilization and replenishment of resources. It is expected that patterns of the environment, device construction, and operational configuration exist with enough regularity and stability to allow meaningful planning. The following assumptions are made with this usecase.</t>case:</t> <ol spacing="normal"type="1"><li> <t>Knowntype="1"> <li>Known resource expenditures. It is assumed that there exists some determinable relationship between the resources available on a node and the resources needed to participate in a network. A node would need to understand when it has met some condition for participating in, or dropping out of, a network. This is somewhat similar to predicting the amount of battery life left on a laptop as a function of likely futureusage.</t> </li> <li> <t>Predictableusage.</li> <li>Predictable resource accumulation. It is assumed that the accumulation of resources on a node are predictable such that a node might expect (and be able to communicate) when it is likely to next rejoin a network. This is similar to predicting the time at which a battery on a laptop will be fullycharged.</t> </li> <li> <t>Consistentcharged.</li> <li>Consistent cost functions. It is assumed that resource management on a node is deterministic such that the management of a node as a function of resource expenditure and accumulation is consistent enough for linkplanning.</t> </li>planning.</li> </ol> </section> <section anchor="routing-impacts"> <name>Routing Impacts</name> <t>Resource management in these scenarios might involve turning off elements of the node as part of on-board resource management. These activities can affect data routing in a variety of ways.</t> <ol spacing="normal"type="1"><li> <t>Powertype="1"> <li>Power Savings. On-board radios may be turned off to allow other node processing. This may happen on power-constrained devices to extend the battery life of the node or to allow a node to perform some other power-intensivetask.</t> </li> <li> <t>Thermaltask.</li> <li>Thermal Savings. On-board radios may be turned off if there are thermal considerations on the node, such as an increase in anode’snode's operatingtemperature.</t> </li> <li> <t>Storagetemperature.</li> <li>Storage Savings. On-board radios may be turned on with the purpose of transmitting data off the node to free local storage space to collect newdata.</t> </li>data.</li> </ol> <t>Whenever a communications device on a node changes its powered state there is the possibility (if the node is within range of other nodes in a network) that the topology of the network is changed, which impacts route calculations through the network. Additionally, whenever a node joins a network there may be a delay between the joining of the node to the network and any discovery that may take place relating to the status of thenode’snode's functional neighborhood. During these times, forwarding to and from the node might be delayed pending some synchronization.</t> </section> <section anchor="example"> <name>Example</name> <t>An illustrative example of a network necessitating resource preservation is an energy-harvesting wireless sensor network. In such a network, nodes rely exclusively on environmental sources for power, such as solar panels. On-board power levels may fluctuate based on various factors including sensor activity, processing demands, and the node's position and orientation relative to its energy source.</t> <t>Consider a simplethree nodethree-node network where each node accumulates power through solar panels. Power available forRadio Frequencyradio frequency (RF) transmission is shownbelowin <xref target="Resource-Example-Plots"/>. In this figure, each of the three nodes (Node 1, Node 2, and Node 3)havehas a different plot of available power over time. This example assumes that a node will not power its radio until available power is over some threshold, which is shown by the horizontal line on each plot.</t> <figure anchor="Resource-Example-Plots"> <name>Node PowerOverover Time</name> <artworktype="ascii"type="ascii-art" align="center"><![CDATA[ Node 1 Node 2 Node 3 P | P | ------- P | -- o | ---- -- o | / \ o | / \ w |~/~~~~\~~~~~/~~\~~ w |~/~~~~~~~~~\~~~~~~ w |~~~~~~~~/~~~~\~~~~ e |/ \ / \ e |/ \ e | / \ r | --- - r | ----- r |------- --- +---++----++----++- +---++----++----++- +---++----++----++- t1 t2 t3 t1 t2 t3 t1 t2 t3 Time Time Time ]]></artwork> </figure> <t>The connectivity of thisthree nodethree-node network changes over time in ways that may be predictable and are likely able to be communicated to other nodes in this small sensor network. Examples of connectivity are shown in <xref target="Resource-Example-Schedule"/>. This figure shows a sample of network connectivity at three times: t1, t2, and t3.</t> <ul spacing="normal"> <li> <t>At timet1t1, Node 1 and Node 2 have their radios powered on and are expected to communicate.</t> </li> <li> <t>At timet2t2, it is expected that Node 1 has its radiooff,off but that Node 2 and Node 3 can communicate.</t> </li> <li> <t>Finally, at timet3t3, it is expected that Node 1 may be turning its radiooff andoff, that Node 2 and Node 3 are not powering theirradiosradios, and there is no expectation of connectivity.</t> </li> </ul> <figure anchor="Resource-Example-Schedule"> <name>Topology over Time</name> <artworktype="ascii"type="ascii-art" align="center"><![CDATA[ +----------+ +----------+ +----------+ t1 | Node 1 |--------| Node 2 | | Node 3 | +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ t2 | Node 1 | | Node 2 |--------| Node 3 | +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ t3 | Node 1 | | Node 2 | | Node 3 | +----------+ +----------+ +----------+ ]]></artwork> </figure> </section> </section> <section anchor="Operating-Efficiency"> <name>Operating Efficiency</name> <t>Some nodes in a network might alter their networking behavior to optimize metrics associated with the cost of a node's operation. While the resource preservation use case described in <xref target="Resource-Preservation"/> addresses node survival, this use case discusses non-survival efficiencies such as the financial cost to operate the node and the environmental impact (cost) of using that node.</t> <t>When a node operates using somepre-existing infrastructurepreexisting infrastructure, there is typically some cost associated with the use of that infrastructure. Sample costs include the following.</t> <ol spacing="normal" type="1"><li> <t>Nodes that use existing wirelesscommunicationscommunications, such as a cellularinfrastructureinfrastructure, must pay to communicate to and through that infrastructure.</t> </li> <li> <t>Nodes supplied with electricity from an energy provider pay for the power they use.</t> </li> <li> <t>Nodes that cluster computation and activities might increase the temperature of the node and incur additional costs associated with cooling the node (or collection of nodes).</t> </li> <li> <t>Beyond financial costs, assessing the environmental impact of operating a node may also be modeled as a cost associated with node operation, to include achieving carbon credits or other incentives for green computing.</t> </li> </ol> <t>When the cost of using a node's resources changes over time, a node can benefit from predicting when data transmissions might optimize costs, environmental impacts, or other metrics associated with operation.</t> <section anchor="assumptions-1"> <name>Assumptions</name> <t>The ability to predict the impact of a node's resource utilization over time presumes that the node exists within a defined environment (or infrastructure). Some characteristics of these environments are listed asfollows.</t>follows:</t> <ol spacing="normal" type="1"><li> <t>CostMeasureability.Measurability. The impacts of operating a node within its environment can be measured in a deterministic way. For example,thatthe cost-per-bit of data over a cellular network or the cost-per-kilowatt of energy used are known.</t> </li> <li> <t>Cost Predictability. Changes to the impacts of resource utilization are known in advance. For example, if the cost of energy is less expensive in the evening than during the day, there exists some way of communicating this change to a node.</t> </li> <li> <t>Cost Persistent. Changes to the cost of operating in the environment persist for a sufficient amount of time such that behavior can be adjusted in response to changing costs. If costs change toorapidlyrapidly, it is likely not possible to meaningfully react to their change.</t> </li> <li> <t>Cost Magnitude. The magnitude of cost changes is such that a node experiences a minimum threshold cost reduction through optimization. A specified time period is designated for measuring the cost reduction.</t> </li> </ol> </section> <section anchor="routing-impacts-1"> <name>Routing Impacts</name> <t>Optimizing resource utilization can affect route computation in ways similar to those experienced with resource preservation. The route computation may not change the availablepathpath, but the topology as seen by anend pointendpoint would be different. Cost optimization can impact route calculation in a variety of ways, some of which are described asfollows.</t>follows:</t> <ol spacing="normal" type="1"><li> <t>Link Filtering. Data might be accumulated on a node waiting for a cost-effective time for data transmission. Individual link costs might be annotated with cost information such that adjacencies with atoo-hightoo high cost might not be used for forwarding. This effectively filters which adjacencies are used (possibly as a function of the type of data being routed).</t> </li> <li> <t>Burst Planning. In cases where there is a cost savings associated with fewer longer transmissions (versus many smaller transmissions), nodes might refuse to forward data until a sufficient data volume exists to justify a transmission.</t> </li> <li> <t>Environmental Measurement. Nodes that measure the quality of individual links can compute the overall cost of using a link as a function of the signal strength of the link. If link quality is insufficient due to environmental conditions (such as clouds on a free-space optical link or long distance RF transmission in a storm) the cost required to communicate over the link may be too much, even if access to infrastructure is otherwise in a less expensive time of day.</t> </li> </ol> <t>In each of these cases, some consideration of the efficiency of transmission is prioritized over achieving a particular data rate. Waiting until data rate costs are lower takes advantage of platforms using time-of-use rate plans–-- both for pay-as-you-go data and associated energy costs. Accumulating data volumes and choosing more opportune times to transmit can also result in less energy consumption by radios and, thus, less operating cost for platforms.</t> </section> <section anchor="example-cellular-network"><name>Example :<name>Example: Cellular Network</name> <!--[rfced] Are the terms "on-peak" and "off-peak" correct, or should they be be simply "peak" and "off-peak"? We see "peak and off-peak" used in RFC 7536. (FYI, the terms have been lowercased.) Original: ... connections that charge both On-Peak and Off-Peak data rates. Perhaps: ... connections that charge both peak and off-peak data rates. Depending on your reply, other instances would be updated as well. --> <t>One example of a network where nodes might seek to optimize operating cost is a set of nodes operating over cellular connections that charge bothOn-Peakon-peak andOff-Peakoff-peak data rates. In this case, individual nodes may be allocated a fixed set of"On-Peak""on-peak" minutes such that exceeding that amount of time results in expensive overage charges. Generally, the concept ofOn-Peakon-peak andOff-Peakoff-peak minutes exists to deter the use of a given network at times when the cellular network is likely to encounter heavy call volumes (such as during the workday).</t> <t>Just as pricing information can act as a deterrent (or incentive) for a human cellular user, this pricing information can be codified in ways that also allow machine-to-machine (M2M) connections to prioritizeOff-Peakoff-peak communications for certain types of data exchange. Many M2M traffic exchanges involve schedulable activities, such as nightly bulk file transfers, pushing software updates, synchronizing datastores, and sendingnon-criticalnoncritical events and logs. These activities are usually already scheduled to minimize impact on businesses andcustomers,customers but can also be scheduled to minimize overall cost.</t> <t>Consider a simplethree nodethree-node network, similar to the one pictured in <xref target="Resource-Example-Plots"/>, except that in this case the resource that varies over time is the cost of the data exchange. This case is illustrated below in <xref target="Efficiency-Example-Plots"/>. In this figure, a series of three plots are given, one for each of the three nodesNode(Node 1, Node 2, and Node3.3). Each of these nodes exists in a different cellular service areawhichthat has differentOn-Peakon-peak andOff-Peakoff-peak data rate times. This is shown in each figure by times when the cost is low(Off-Peak)(off-peak) and when the cost is high(On-Peak).</t>(on-peak).</t> <figure anchor="Efficiency-Example-Plots"> <name>Data CostOverover Time</name> <artworktype="ascii"type="ascii-art" align="center"><![CDATA[ Node 1 Node 2 Node 3 C | +--------- C |--+ C |-------------+ o | | o | | o | | s | | s | | s | | t |-------+ t | +---------------- t | +------- | | | +---++----++----++-- +----++----++----++-- +----++----++-----++-- t1 t2 t3 t1 t2 t3 t1 t2 t3 Time Time Time ]]></artwork> </figure> <t>Given the presumption that peak times are known in advance, the cost of data exchange from Node 1 through Node 2 to Node 3 can be calculated. Examples of these data exchanges are shown in <xref target="Efficiency-Example-Schedule"/>. From this figure, both times t1 and t3 result in a smaller cost of data exchange than choosing to communicate data at time t2.</t> <figure anchor="Efficiency-Example-Schedule"> <name>Data Exchange Cost over Time</name> <artworktype="ascii"type="ascii-art" align="center"><![CDATA[ +-----------+ +-----------+ +-----------+ t1 | Node N1 |---LOW----| Node N2 |---HIGH---| Node N3 | +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ t2 | Node N1 |---HIGH---| Node N2 |---HIGH---| Node N3 | +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+ t3 | Node N1 |---HIGH---| Node N2 |----LOW---| Node N3 | +-----------+ +-----------+ +-----------+ ]]></artwork> </figure> <t>While not possible in every circumstance, a highly optimized plan could be to communicate from Node 1 to Node 2 at time t1 and then queue data at Node 2 until time t3 for delivery to Node 3. This case is shown in <xref target="Efficiency-Example-Store"/>.</t> <figure anchor="Efficiency-Example-Store"> <name>Data CostusingUsing Storage</name> <artworktype="ascii"type="ascii-art" align="center"><![CDATA[ +-----------+ +-----------+ t1 | Node N1 |---LOW----| Node N2 | +-----------+ +-----------+ +-----------+ +-----------+ t3 | Node N2 |----LOW---| Node N3 | +-----------+ +-----------+ ]]></artwork> </figure> </section> <section anchor="another-example-tidal-network"> <name>AnotherExample :Example: Tidal Network</name> <t>Another example related to operating efficiency iswhat isoften referred to as a'tidal network,'"tidal network," in which traffic volume undergoes significant fluctuations at different times. Take, for instance, a campus network, where thousands of individuals go to classrooms and libraries during the daytime and retire to the dormitories at night. This results in a regular oscillation of network traffic across various locations within the campus.</t> <t>In the context of a tidal network scenario, 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 in a variety of ways. Ports 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.</t> <t>More information onTidal Networktidal networks can be found in <xreftarget="TIDAL"/>.</t>target="I-D.zzd-tvr-use-case-tidal-network"/>.</t> </section> </section> <section anchor="Dynamic-Reachability"> <name>Dynamic Reachability</name> <t>When a node is placed on a mobile platform, the mobility of the platform (and thus the mobility of the node) may cause changes to the topology of the network over time. The impacts on the dynamics of the topology can be very important. To the extent that 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.</t> <t>Mobility can cause the loss of an adjacent link in several ways, such as the following.</t> <ol spacing="normal" type="1"><li> <t>Node mobility can cause the distance between two nodes to become large enough that distance-related attenuation causes the mobile node to lose connectivity with one or more other nodes in the network.</t> </li> <li> <t>Node mobility can also be used to maintain a required distance from other mobile nodes in the network. While moving, external characteristics may cause the loss of links through occultation or other hazards of traversing a shared environment.</t> </li> <li> <t>Node mobility can cause the distance between two nodes to vary quickly overthe timetime, making it complicated to establish and maintain connectivity.</t> </li> <li> <t>Nodes equipped with communication terminals capable of adjusting their orientation or moving behind and emerging from barriers will also establish and lose connectivity with other nodes as a function of that motion.</t> </li> </ol> <!--[rfced] Would it be more clear to say mobile nodes "encounter issues" (rather than "have concerns", which has a connotation that the nodes are worried) regarding resource preservation and cost efficiency? Also, may "However" be changed to "In addition"? It seems the mobility-related challenges are in addition (rather than in contrast) to the typical issues. Original: Mobile nodes, like any node, may have concerns regarding resource preservation and cost efficiency. However, they also face unique challenges associated with their mobility. Perhaps: Mobile nodes, like any node, may encounter issues regarding resource preservation and cost efficiency. In addition, they may face unique challenges associated with their mobility. --> <t>Mobile nodes, like any node, may have concerns regarding resource preservation and cost efficiency. However, they also face unique challenges associated with their mobility. The intermittent availability of links can lead to dynamic neighbor relationships at the node level. This use case aims to examine the routing implications of motion-induced changes to network topology.</t> <section anchor="assumptions-2"> <name>Assumptions</name> <t>Predicting the impact of node mobility on route computation requires some information relating to the nature of the mobility and the nature of the environment being moved through. Some information presumed to exist for planning is listed as follows.</t> <ol spacing="normal" type="1"><li> <t>Path Predictability. The path of a mobile node through its environment is known (or can be predicted) as a function of (at least) time. It is presumed that mobile nodes using time-variant algorithms would not exhibit purely random motion.</t> </li> <li> <t>Environmental Knowledge. When otherwise well-connected mobile nodes pass through certain elements of their environment (such as a storm, a tunnel, or thehorizon)horizon), they may lose connectivity. The duration of this connectivity loss is assumed to be calculable as a function of node mobility and the environment itself.</t> </li> </ol> </section> <section anchor="routing-impacts-2"> <name>Routing Impacts</name> <t>Changing a network topology affects the computation of paths (or subpaths) through that topology. In particular, the following features can be implemented in a network with mobile nodes such that different paths might be computed overtime.</t>time:</t> <ol spacing="normal" type="1"><li> <t>Adjacent Link Expiration. A node might be able to predict that an adjacency will expire as a function of that node's mobility, the other node's mobility, or some characteristic of the environment. Determining that an adjacency has expired allows a route computation to plan for thatloss,loss rather than default to an error recovery mechanism.</t> </li> <li> <t>Adjacent Link Resumption. Just as the loss of an adjacency can be predicted, it may be possible to predict when an adjacency will resume.</t> </li> <li> <t>Data Rate Adjustments. The achievable data rate over a given link is not constant overtime,time and may vary significantly as a function of both relative mobility between a transmitter and receiver as well as the environment being transmitted through. Knowledge of both mobility and environmental state may allow for prediction of dataratesrates, which may impact path computation.</t> </li> <li> <t>Adjacent Link Filtering. Separate from the instantaneous presence or absence of an adjacency, a route computation might choose to not use an adjacency if that adjacency is likely to expire in the near future or if it is likely to experience a significant drop in predicted data rate.</t> </li> </ol> </section> <section anchor="example-mobile-satellites"><name>Example :<name>Example: Mobile Satellites</name> <!--[rfced] Regarding "LEO-NC", please consider whether introducing this acronym is necessary. (Google does not show any usage outside of this document.) Would you like to use "LEO networked constellation" (as shown below) for the 2 instances in this document after the term is introduced? Or, perhaps use an existing term? Is this term distinct from "LEO constellation network", which appears to be more commonly used? One option if you decide not to introduce the acronym: Current: Low Earth Orbit networked constellation (LEO-NC) Perhaps: Low Earth Orbit (LEO) networked constellation Original: Many LEO-NCs have ... Perhaps: Many LEO networked constellations have ... Original: A LEO-NC represents ... Perhaps: A LEO networked constellation represents ... If it is kept, we suggest to update as follows to avoid the double expansion of "LEO". Original: Low Earth Orbit (LEO) networked constellation (LEO-NC) Perhaps: Low Earth Orbit networked constellation (LEO-NC) --> <t>A relatively new type of mobile network that has emerged over the past several years is the Low Earth Orbit (LEO) networked constellation (LEO-NC). There are a number of such constellations being built by both privateindustryindustries and governments. While this example describes LEOsatellitessatellite systems, the mobility events can be applied to satellite systems orbiting at differentaltitudealtitudes (including Very LEO (V-LEO) or Medium Earth Orbit (MEO)).</t> <t>Many LEO-NCs have a similar operational concept ofhundreds-to-thousandshundreds to thousands of inexpensive spacecraft that can communicate both with their orbital neighbors as well as down to any ground station that they happen to be passing over. A ground station is a facility used to communicate with satellites inlow Earth orbit.LEO. The relationship between an individual spacecraft and an individual ground station becomes somewhat complex as each spacecraft may only be over a single ground station for a few minutes at a time. Moreover, as a function of the constellation topology, there are scenarios where (1) the inter-satellite links need to be shut down for interference avoidance purposes or (2) the network topology changes, which modifies the neighbors of a given spacecraft.</t> <t>A LEO-NC represents a good example of planned mobility based on the predictability of spacecraft in orbit. While other mobile vehicles may encounter unpredictable fluctuations in velocity, spacecraft operate in an environment with relatively stable velocity conditions. This determinism makes them an excellent candidate for time-variant route computations. However, inter-satellite link failures could still introduce unpredictability in the network topology.</t> <t>Consider three spacecraft (N1, N2, and N3) following each other sequentially in the same orbit. This is sometimes called astring"string ofpearlspearls" configuration. Spacecraft N2 always maintains connectivity to its two neighborspacecraft, N1spacecraft: N1, which is behind in theorbitorbit, andN3N3, which is ahead in the orbit. This configuration is illustrated in <xref target="Mobility-SOP"/>. While these spacecraft are all mobile, their relative mobility ensures continuous contact with each other under normal conditions.</t> <figure anchor="Mobility-SOP"> <name>Three Sequential Spacecraft</name> <artworktype="ascii"type="ascii-art" align="center"><![CDATA[ .--. .--. .--. ####-| N1 |-#### <---> ####-| N2 |-#### <---> ####-| N3 |-#### \__/ \__/ \__/ ]]></artwork> </figure> <t>Flying over a ground station imposes a non-relative motion between the ground and the spacecraft--- namely that any given ground station will only be in view of the spacecraft for a short period of time. The times at which each spacecraft can see the ground station is shown in the plots in <xref target="Mobility-Example"/>. In this figure, ground contact is shown when the plot is high, and a lack of ground contact is shown when the graph is low. From this, we see that spacecraft N3 can see ground at time t1, N2 sees ground at time t2, and spacecraft N1 sees ground at time t3.</t> <figure anchor="Mobility-Example"> <name>Spacecraft Ground ContactsOverover Time</name> <artworktype="ascii"type="ascii-art" align="center"><![CDATA[ Spacecraft N1 Spacecraft N2 Spacecraft N3 G | G | G | r | +--+ r | +--+ r | +--+ o | | | o | | | o | | | u | | | u | | | u | | | n |--------------+ +- n |---------+ +------- n |---+ +------------- d | d | d | +---++----++----++-- +----++----++----++-- +----++----++----++-- t1 t2 t3 t1 t2 t3 t1 t2 t3 Time Time Time ]]></artwork> </figure> <t>Since the ground station in this example is stationary, each spacecraft will pass over it, resulting in a change to the network topology. This topology change is shown in <xref target="Mobility-Example-Topology"/>. At time t1, any message residing on N3 and destined for the ground could be forwarded directly to the ground station. At time t2, that same message would need to, instead, be forwarded to N2 and then forwarded to ground. By time t3, the same message would need to be forwarded from N2 to N1 and then down to ground.</t> <figure anchor="Mobility-Example-Topology"> <name>Constellation TopologyOverover Time</name> <artworktype="ascii"type="ascii-art" align="center"><![CDATA[ +------+ +------+ t1 | N2 |----------| N3 | +------+ +---+--+ | /|\ \___/ / \ Ground Station ------------------------------------------------------------------ +------+ +------+ +------+ t2 | N1 |----------| N2 |----------| N3 | +------+ +---+--+ +------+ | /|\ \___/ / \ Ground Station ------------------------------------------------------------------ +------+ +------+ +------+ t3 | N1 |----------| N2 |----------| N3 | +---+--+ +------+ +------+ | /|\ \___/ / \ Ground Station ------------------------------------------------------------------ ]]></artwork> </figure> <t>This example focuses on the case where the spacecrafts fly over a ground station and introduce changes in the network topology. There are also scenarios where the in-constellation network topology varies over time following a deterministic time-driven operation from the ground system. More information on in-constellation network topology can be found in <xreftarget="LHAN-PROB"/>target="I-D.lhan-problems-requirements-satellite-net"/> and <xreftarget="LWOOD-SCN"/>.target="SCN"/>. For this example, and in particular for within constellation network topology changes, the TVR approach is important to avoid the Interior Gateway Protocol (IGP) issues mentioned in <xreftarget="LHAN-PROB"/>.</t>target="I-D.lhan-problems-requirements-satellite-net"/>.</t> </section> <section anchor="another-example-predictable-moving-vessels"> <name>AnotherExample :Example: Predictable Moving Vessels</name> <t>Another relevant example for this use case involves the movement of vessels with predictable trajectories, such as ferries or planes. Theseend pointsendpoints often rely on a combination of satellite and terrestrial systems for Internet connectivity, capitalizing on their predictable journeys.</t> <t>This scenario also covers situations where nodes employ dynamic pointing solutions to track the mobility of other nodes. In such cases, nodes dynamically adjust their antennas and application settings to determine the optimal timing for data transmission along the path.</t> </section> </section> <sectionanchor="acknowledgments"> <name>Acknowledgments</name> <t>Many thanks to Tony Li, Peter Ashwood-Smith, Abdussalam Baryun, Arashmid Akhavain, Dirk Trossen, Brian Sipos, Alexandre Petrescu, Haoyu Song, Hou Dongxu, Tianran Zhou, Jie Dong, Nkosinathi Nzima and Vinton Cerf for their useful comments that helped improve the document.</t> </section> <sectionanchor="security-considerations"> <name>Security Considerations</name> <!--[rfced] How should this sentence be updated - perhaps you intended for the expansion to match the previous usage of TVR? Original: While this document does not define a specific mechanism or solution, it serves to motivate the use of Time-Based Validation and Revocation (TVR). Perhaps: While this document does not define a specific mechanism or solution, it serves to motivate the use of Time-Variant Routing (TVR). --> <t>While this document does not define a specific mechanism or solution, it serves to motivate the use of Time-Based Validation and Revocation (TVR). Therefore, security considerations are anticipated to be addressed elsewhere, such as within a TVR schedule definition or through a protocol extension utilizing a TVR schedule.HoweverHowever, it's important to note that time synchronization is critical within a network employing a TVR schedule. Any unauthorized changes to network clocks can disrupt network functionality, potentially leading to a Denial of Service (DoS) attack.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>This document has no IANA actions.</t> </section> </middle> <back> <displayreference target="I-D.zzd-tvr-use-case-tidal-network" to="TIDAL"/> <displayreference target="I-D.lhan-problems-requirements-satellite-net" to="SAT-CONSTELLATION"/> <references anchor="sec-informative-references"> <name>Informative References</name> <!-- [rfced] Since the provided URL for [LWOOD-SCN] returns a 403 Forbidden error, may it be updated to one of the following URLs? Original: [LWOOD-SCN] Wood, L., "SATELLITE CONSTELLATION NETWORKS", Internetworking and Computing over Satellite Networks , 2003, <http://personal.ee.surrey.ac.uk/Personal/L.Wood/ publications/zhang-book/zhang-book-wood-chapter-2.pdf>. Perhaps A: [SCN] Wood, L., "Satellite Constellation Networks", Internetworking and Computing over Satellite Networks, pp. 13-34, DOI 10.1007/978-1-4615-0431-3_2, April 2003, <https://www.researchgate.net/publication/2559727_ Satellite_Constellation_Networks> Perhaps B: [SCN] Wood, L., "Satellite Constellation Networks", Internetworking and Computing over Satellite Networks, pp. 13-34, DOI 10.1007/978-1-4615-0431-3_2, April 2003, <https://link.springer.com/chapter/10.1007/ 978-1-4615-0431-3_2> --> <referenceanchor="LWOOD-SCN"anchor="SCN" target="http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/zhang-book/zhang-book-wood-chapter-2.pdf"> <front><title>SATELLITE CONSTELLATION NETWORKS</title><title>Satellite Constellation Networks</title> <author initials="L." surname="Wood" fullname="Lloyd Wood"> <organization/> </author> <date month="April" year="2003"/> </front> <seriesInfoname="Internetworkingname="DOI" value="10.1007/978-1-4615-0431-3_2"/> <refcontent>Internetworking and Computing over SatelliteNetworks" value=""/>Networks, pp. 13-34</refcontent> </reference><reference anchor="TIDAL" target="https://datatracker.ietf.org/doc/draft-zzd-tvr-use-case-tidal-network/"> <front> <title>Use Case<!-- [I-D.zzd-tvr-use-case-tidal-network] IESG state: Expired as ofTidal Network</title> <author initials="L." surname="Zang" fullname="Li Zang"> <organization/> </author> <author initials="T." surname="Zhou"05/20/24 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-zzd-tvr-use-case-tidal-network.xml"/> <!-- [I-D.lhan-problems-requirements-satellite-net] IESG state: I-D Exists as of 05/20/24 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-lhan-problems-requirements-satellite-net.xml"/> </references> <!-- [rfced] FYI, we removed some extra space in Figures 3 and 7 to accommodate the 72-character line limit. Please let us know if further changes are needed. --> <section anchor="acknowledgments" numbered="false" toc="default"> <name>Acknowledgments</name> <t>Many thanks to <contact fullname="Tony Li"/>, <contact fullname="Peter Ashwood-Smith"/>, <contact fullname="Abdussalam Baryun"/>, <contact fullname="Arashmid Akhavain"/>, <contact fullname="Dirk Trossen"/>, <contact fullname="Brian Sipos"/>, <contact fullname="Alexandre Petrescu"/>, <contact fullname="Haoyu Song"/>, <contact fullname="Hou Dongxu"/>, <contact fullname="TianranZhou"> <organization/> </author> <author initials="J." surname="Dong" fullname="Ji Dong"> <organization/> </author> <author initials="N." surname="Nzima"Zhou"/>, <contact fullname="Jie Dong"/>, <contact fullname="NkosinathiNzima"> <organization/> </author> <date>n.d.</date> </front> </reference> <reference anchor="LHAN-PROB" target="https://datatracker.ietf.org/doc/draft-lhan-problems-requirements-satellite-net/"> <front> <title>ProblemsNzima"/>, andRequirements of Satellite Constellation<contact fullname="Vinton Cerf"/> forInternet</title> <author initials="L." surname="Han" fullname="Li Han"> <organization/> </author> <author initials="R." surname="Li" fullname="Richard Li"> <organization/> </author> <author initials="A." surname="Retana" fullname="Alvaro Retana"> <organization/> </author> <author initials="M." surname="Chen" fullname="Meiling Chen"> <organization/> </author> <author initials="L." surname="Su" fullname="Li Su"> <organization/> </author> <author initials="T." surname="Jiang" fullname="Tianji Jiang"> <organization/> </author> <author initials="N." surname="Wang" fullname="Ning Wang"> <organization/> </author> <date>n.d.</date> </front> </reference> </references> <?line 410?>their useful comments that helped improve the document.</t> </section> </back> <!--##markdown-source: H4sIAAAAAAAAA919W48bx5LmO39FQXpw94hkH0vnZYU9C7d1seSj26h7bOzC wEGyKtksd7GKpy7doiwb8x/2af7e/JKNLyLyVixKsi1gFkMYFptVlZfIyLh+ GbVYLGZ92Vf2YXbn8oe32cllubWLH0xbmrrP3jZDX9ZXp9m/dTZ7ZDrb3ZmZ 1aq1N3R7f9Muhs4ucvk9N729atr9w6ys181sVjR5bbbUbtGadb8obb9eJI8s /vI/Zt2w2pZdVzZ1v9/Rvc+fXD6d1cN2ZduHs7sFNUn/5E3d2bobuodZ3w52 Rp3/dWZaa2gQOsI7s9umvb5qm2H3cHZt9/RX8XCWLTKezo1MB3/r/fj6slmV Vdnv8f271to6y5vtzl9+a7tmaHObbU1truzWUgM3th5oRFkmPRHJqPlsRK07 dF1mc+dHGhT9Qs3T7fh9a8pKSPcNCLJsWr7dtPmGft70/a57eHaGu/BTeWOX 7rYz/HC2apvbzp7R82d47qrsN8OKnnxlOvO4r3FhsWrW8bqYod80LYhBD2TZ eqgqWZcnRfZt2bamtnyB+jB1+d70tBgPs++f/dvZ+ZsXfMXKqG1xa9piuZJn vvl5M5hdtbTFcNj0qzJvKtNlfx829UTjlxtT2S47r2xdmuxiZ3Ibd1TL08tr eprn/80VLixpeQ67+t9E3/cbWrx/HSZ6ejr0Q2tvbZld2nxTN1VzVdou7myv z3+yo7dlfp1dmn3VtBMdvW7L7HldDF3fjjpo6bllz89907QlNX7Y9osye78x 4LuDhp8NhoYfN8h3VuWDv/71mw1f5PHO6qbd0jM3xJ8z7ED/V5a9+PH168eL i0evHnI7vWmvbP8wA7sRt+1s2zW1oaW0y25oW7tfmnw5XJ+90QtnL5Y/Nk1x thtWVZnzuLozHgXxWnMdfV3c0n2LfGN2vW0X95e7Yi09QsJkxKcX55dPXrx4 fvkke/T61QW+n18+f/0qe/Xk8sfXb/9+cYdv532f3f/LXx7wn50FTTEnGT8+ z2vqobb9re4wUxfZI7d9s+bGttkFtVLRBrfZK7lPlsXvB/2UNcmVF8sMU/Q/ 6rJUzb5wFy6fPz5/cUhA7Fcar+lbk1/bNuxXkn9nIvrevy8Sybfoy8JUCx39 WaAQEcgJ2qxZk+yi29zg70wMfnEwif/jmCiaRBn/Onrkkh7ZNMPokUsSZ7TH 40uj575fZo+bg66+L+NfR4+8Wmav3pdbM3rm1XVDS2v6Tekvv3h2/mrx5u3r b/8QtSvixsWubVaV3XaL1v5zKFuW3t2icxwB2qd0f6MPMCO9jR7CQgROekSs j++8CTLaZJ4RP299npn6cHnCj6MH3i7p8uh+EkMbEsPhwuiZ8yUNvyeVNXru vCIt2KTXRo++XGaPSBKOHnxpSUvSnoouHc7rYsxCNK2LI7xDPPd9ecinYLqf y+TSIQf9ePjcKwyOf18sFplZdeCNfja73JRdRmwxYBmpgb5tiiEntUPbMGPd mN1ubGuzKYuH7KAf3p6qQSASLzspl3aZtXpDcqk3LISokyaDtVIWtnWX0PqK uitIsGddviGFWdEfOYQmjYGeMJmKAnQ4VEVWbol/b6zvi/7qG9KJaJsk25Wt ySwhRj2jFvXRjKQ4y3y6tJwxKbZlUVR2NrsLHuXJY0QgDGZNxDEwY27RgVhc YPUxcaJh9pswor7ZQZfuyXLBSDL7bmfznqa1M22Pdtywmp2jxJKGgTaog9AJ 2ty1drGrTF3T41XTyRZsbdc38iSaoy5M8TPZCXW+n4OQqt/C1QrbkPZpfF+3 YXKuLKkQshAMplw39aIou3bYQTtmlky6ngj2xE0gnrBMknQPjZY6yvOBO6ZW YFHafo/OyQ7t3PR01kQ8MsyyLQxMSz0WtqPBDPkGQxjqrczVkFoj+X5jN2UO cwjT7hqyJ5t2VTKVO1hGOaQac5UXPNQabUnqBtQnkvVKsgURzZCO7jZoHrNd D3XuqARab9XmdX8T3XuQcmL4tNLUZFVSg0TUnHYOE2XX3No2zMY/QkLphrrH sG1NPLrP1m2zpZZoZDIzMmll3NQa0R6j2JZXmx7rg+UmQwkLgC1k296UNe8d FsCF2ZOMKbcwiyta2DIa664tyazqy/fo+iq147lnHY5dr8u8BGOIeQA1khGH 2blnVpIcuCkMy7ElSc4htJQTxTswoed6Ymht8KapSOB0y7H8Key6rJnhaYSZ +kqlzG685wxvMxuLGD+k2mIWpqr2XtAwmTJv8jX1MntiaHVkiZPtVtZ5NRS6 79ZNVcn2j5+dzb5eZuc10+imtLeOU1wjNJMub8sVnts0t4dD7XSsna2IOFlR rtc0KSLBjpQ8SVFIwWHFf5xOMCnNZclDoAZYkpiuG7Y7bdkUNlvt0wEZL51o /5O170bsVhU8wGtj38nm5vYvaOlKLDYJg3xgFzRr6kTIkRgmTu3GFODHn7wz 211lAxvSaoj87d1owv0QuYnQMz1vXbeCxEHg9oRhcD1ZJVkZ75W+oS1DKyTc caKLIg398ou7axHf9euvp3PlsN6pgGjlSXViy8sGvYEH6kTFjeMxGjaGlFcl RliR7KyW2ZQLzPKSvlXle+tkfEHb26TS57AvIl1Da73Fc279iEq1dRIDix8p W5JLtDN72pmkehr6CZJECLSLps5L9lpUET36JIiCMeX8TYtw0xThDLwSEAbC IGOdAJaWP4fOXFnoiL13Rpivj9OKJEnVlP1HaBVaj2nEy8EjkLu6PWmJrWtO pQG4r268soyaoonYdz0RT+TuCrKHDZbC7vArjdJvzhIKyBTSBKsjA81JhH28 J0uMdtJbS2LHDXtMWL1pEd/0RzmS4zl8x4p4BBKfdazjDGeDgCA0i0XfLJg/ aNp/agk+zq5l7Tw6J0B04wcd0NAYaSHAuhgQPd1aZtNaukVAwIm9WCH0URBr 2gDN1dCJ1INIryn7MFvQr7eRQIKs8bpM+OAKus7g74h9YxUsnFfnre3xMEtD MRxoubHGkYCm5rdWJSMsW5J5YjSWxFI179WGpjySs3OmFT8iJDI1afF3GzN0 YrqR1WqDibhrqK0eFpUbDdk0zOJVeW2rvYhd4TPuOdsOVV9CiNuxMOdbHU1J 3hmaPltUJbN9Lnob47mikdRjUe9XfE1fQGAaYUF0ardlTR3TVunIQqX1bGiM r2CQTl/0VpbaiOBk/Yrl3w61hmMwS2wVJwVyMrvdH24wNDZyBab1xy93pzXG bHYBg1R2F62r91RUx4t1D973cnfBoqEl883CYLop26ZWR5ocDJD/tiRqsYFc ETv1LCDYeK98I0SWR66ZPpBB9x7NXq1QNLfFc2yzz1nVEzlXDTxkdiCuLG9u 2hFuQ4Amsoz0n22GLvgoItswWzaHIUfKfGC7tT2MBmNVZWT8CPej4QZlIDVj nQg1LDNWOnpsrZrNoWa9PgWfiyjmAY4kD7ePncAjKndK88jKodX9EVFQbhoN 66CIMdqhriEwyIyYs/uTw1zOiWxuYJ2zfPgRb/2SMYVFpOGhs7W54bHqMNlt xO1VuSZynav/RdsB0mE89S4a0tbsR61DkcPKSeaKPTVacJGY3a4R4QkRAvct eCNs5pGjDMuTVR/TJJCCRlSAVXgeN2VTiT1gPCN55u1BKv6JZBN8H9wX/AKS QaLYPFUMvAcy55iP2Kl3bXZmDceLRkCWSlnBvLdX4CrHeCzMiaJuJ5OHEPw4 nUPVYMEcS/t9gsWVhTXx4uWbpums8NRObCOQLzxGV9YDRGxBVjpcIJoEj582 pFCR1yVajjX8FnZI2QVec2D9kOASXJBRmKpjXZL6NtwghtXCuIL28W4W9Uk6 lrrpweDUaWduONABO28gcY2feSrE7s8REig8vVOJIKJAyTUXuRP2cB7JFnCj qIPAocxOTl0khqQ4/I6KUGxkmhJ3kKnnNRWZhWJ6ePV2gsEQH9Gc/Y44Tfb2 aDOTUoDEDfxRutCJZ5QucQl78baRwUvsAtM5RR1M6LhfF+2IbPwuxHBwR2pG kwq5m50Hj4z0XQPPmhuHkhXxGITwSPZJHKyONranZmBh0u88i9ZuwLud89QM vvXsapF8YZnG9gL7GWoxchxkh8RStxEhvY61ynO1eZ2tgzUmaQrZ1QWT0Sst 7I+b0nOMRNBUzTilIVJjXV4NqkSEm1jB2boZrjZuv4MCwpaR/SiCD+YRzYcM QNkMsB7Zbg9OeuwHs0UFX5h7YccxMkHIJP973dwGnaxSoMSW9UTg9hwNIrOo kyCUM0l0kTTwtCl33uZmVznsBb+iYR8Z1Wbhrtpa9TVGqswE3j+Xh2/Z/MID rA3IG2mhtAsIEhKTfbYhVt2SsczDDQIU0ik0LpuH5VtBG3DHDhlbSvO4Tw7W lDL1WxCkE0tXNzWcAcduZsseJzHLihlnzxqQvOG1ipDK7PpmdxjaUDNUJSf7 iOw+vXHORrQbgsBjqTq9YslNqWSK1qCN3Jkqlm2JxpAtIZIKbiBu5WC2szLt qSd8ZFI3RMJ3cLp/btJFDBQ9SkgXUrglgxZGlCNnTMTbkgy3lXhGe0ir9opU IqgG+5Dlay+urLc0Jql1xHwLlsHIAk8UQPzM2tN1vLxTmy3VXare8zBylQ9g WXYu/d5nOeu80+cSh5rNJiAJQTMEr0FWtKxvmupG7CzmelLopOx9UsvrgEji e7E9QS+WR7DJRI+4qLhh4a/RVBc4q9MQ+a3ZdyKX3rAdcmFu6DZaqde+P1Pw yI+bhqLCVSU5i0w3Lh7bmB2RHYvKlkDihogQ70Y2drJ9Y4I0bejWBNtbHGgN 0fNopCf25jt4pL3prpk5L9X0+x0TLdcqhDXw583RKJcUWenB5jUIzeTIQjhB Spf/89//IzYfervl78SSEvxUO/Jzx1c7RUPEH9pdI/lpZzByF8eNxtR0FROS RQtbjRyKwMPqwVhYIiZ1bzunhsOWdYZLSczs3Ck1G10kiUfbEJ+4iFQZG1w+ VsG+IzO/57DU1z0NksCnvUYhZuxqHlAxV3HmYscaHjdVrhKAUwC86xOD71xN WYRuOCbmCMGjhXTtIu9b5qiLZGDE89egl/GAbPpkPcZhcUQwEP+G+acBEjTa m2vOfeRO83PGT0ILROMhkR/MasHMo/ZJ/KyallwQcl4eD63K+04kPtl5tI2A JNJWMQ42Xg8dUJ4Xkorqb/LW6/Z1ThR0CBkRlRqOn83OaTdUFWA4RoJEGtoR wa1TF5ud46PU6mTEmDVIrRmfRZTcuiX3vkIuDJC0kH/lgIGLBshPc+WlFprS vstpVGIjw0YMNib2hmptNl3S/BqnzUg+17aKt6n4cxyBl826rsg4HcD/3saG AEZ4Y02M2LQu+cN0lKG7NNw89nELSyK/0FiKW5KvsMnUt2XjF76bZqaEQ26Y v7AbNUkmc6LVeeTSVAa2ANZCcmC81G5FxDnksKHoJO/vdc71112TEkQVSjA+ QcK3kGHZU8RiJMb/9umpE1aS6IFdsoGFvLIQ8mnORHlp8aZq+u7XXzVvTY+w jU+S14bsWjSXLjuB15Z9PWfvLbsvJOTvD05JP93wVg3pMGqe2XIU44jjrazd HAuLQePSR2okwz5CmFSeBf1ZgrtQw6jtUj093kgYOlGhCjLLU0UybBta5vcN cyi75Y0GdjFyWtjffvuNxpSXAaFCHyFBdvgRmhy78GD2JvswcZE+cmEhn8ML +lksZg3+jm7yX/jCmf7xU9RCE7VA13+a3WYffjujef32E/6Hr/QFV/2F38JV f0E/4cGZzT6che7OQr/hwmgw1g/FPThrw+j8pPifdkQqTxm6MKITfaXVuUf/ 3MP/wv/l8u+5oKvc8+L2vJL9g2gUn3khZhbOxUx9PnoBjDf75SEZSiw7FqYq r+q/3SHzl8y5O/5nQHD/docZ9E52d3p3C/zrb3eYB0WUvMb+QDd3fpVg/mHs pOymRNhhKIXECizfoFdXqSvGGhgIDnGmnM+1ioP74v2OTBMeQrc1nC1KtdAT l4lBCikeOTqS3T0t7S4UmQSBJ3JHxB0/xPlOr0gnE7NsIYEorOQf0qrPac1V jTwgcfEv2XkvdCGGUDHhBeR9kY80zbJ1NmgUJXeUipNUEY2WceP31UVNgzxO LiFoEKQk2avzbDX00T33I6nNDs6on6el2mjGdfjgYx1GhjR7RnHXqmIne+bQ opPrakEF0qhuFju3brRrHweIFyYR1DO/ufVzz22sT/024138IQh4J2kWH4Js 92LJ/UZi4MOf6PPPDPf+aLjjod2fmMJ/4XAffMZwvzB1v4gYdWLDSdJL7yHF cvTuNPjil7uTcItPZR0Z66cbIoKAryzJkFKcd5+V31rgyjga1OQly1Pvyjrg hHE2ro/pIulSVjYJXqbuwRgO9QnkDVIV9EPHAADOMLQ35Q3yFEnw1oGR+LZ6 4e4K2DVEXZxrwIgBkkY1Ev4RNERSsiG8o3Z86nJoMvQEj50KCE2kDEkjToBq PlHtTG2109vYfgRukyPGCiFrjYTIhxjOQeyDVGO1d2FagBUn1mLQkAL6T9ta ZheieQR2pxC2KWyUJE24CTTnx+ZdtlFQwUdQstySzwi/YjQNTkXszH6kb5zb Gjz5w1GHAXXDbleVbrKMiiOWhM5kt9d7mQ4a0XKPcGQkgiHej91jUsvRPOFU 9oxCClBBiTn6IJ2LBmqIiJ2WEA5KI4E1uBgoV+PDEUr28ZrlTVO5QC4/i0R2 SAS69FF3yiP+1u6Rs025FT4mWL1z7UxyKAIzXnZEGWSXXERitXJw10n2ihiY szfwU5WJyJsp7Y0ggNoVDTuHeRZhFXAnUCU36p2P8KVul8TSRHaIlykhJn9g IPqMF8yMJI8XRco56M7BtdiD7TwAQ+WcEnSKhN08TOeYOAySbyLDF+ERQhRf cBR+jQ7mm6Tlgk0MIRq8WM89mnnSkJxRuGwCIGEOSzfZKckGliobA8w/GUqI 3rvoVGdT/ImY2l0vzCKyQ8PSj7B2L2l/UKM6VUm/RRDQAy7UwUrMIwxTFhMZ PbRWZDqfOL1wCzjzUwYQs2ibB2pgHRfU02JV9oJ8RlhVY6JOSnlwfZs+c13S lEzPD6pMYZwCZn6NjODST/ZNgnDDwY8E5x/Ne3JBfYs8veKGjx2kU9Joq9sW Oh7kjiCKOUnCQXNNfQPJoRqI+N1HDQH9nk+kJ4mEYul6ic73+0CsnqtgTebn bFtNvBzM141ynHFPVnYnz+sRgG5QpdxHKUHm8ZA98iaJMoUpfh46QTwpkEVQ GjxmwYHQDJfZ87WKXT+Zhkz/XVkA1xcn4MRFQIxbfMeQR6aLxMu5QyOTqRSB n4XfzVVd9gPATpec5dI/ha7IwbsYe3eYNUwBHODs7bANISVpgHhMUuZeU6q8 UiPr3OX24TSxdKA2m0LycR2ZoyygQG7ZTY4n0saPJMteS1dJhDdm4Sh5dQi3 d657lL3sN00Xz1sl5zTemCk6geI3smRuWTcJxAmwXHFGo0wDYsDQOau9WAoO 53zr0Ik+oqjLGpOYJ6lC+iATMZmmm2t+a+3Ssm1s4o7l5gskLZ+WsMc5G/cY 0sqH70MQt4gyN7dGDrfILmLZ5QEkwgW4cqDxEIYtyKYpBglHXusOCb3VRNnY QOn6BEwcsbCeECoVsAqsVtMsNtSSPCZtYqFWViToWo4cadpC044x7mXNROgc 1aIeTKttnOhG3U8fzYGj5SX+yjLfYskKNaGGFiLMg0Oe1ylEOADTeQqdZPYO FP3acuKgYRBcalGckJbpBqQT6r1El8a3nLqUhhCotcCQcZ5PSCNjdyi3SEBG R2OcFKenIAvL9T4bLTQfr0jsGNXMkoWOrF/VsUy+fw7GISbLlFE6F8bZDeoX QZ8ieDY22QTgPbU4LIyQxKSNdtX76D8eYGnNT7ohMNAwnv0gULxkThGQ68Q5 InnVDIWCN5A6XUiyFDs6d1zfyOrBU2Qkcvb26Si3gaeRbd2exsKScanjwJka Zg7b7oJVpG22NKQ5K2Uo8nD8a+QgIaHgMb3c80i784bWE1yM2bPJ0SRm4bmH 8IRktwdjRae21gdJHH/2y+HUg0FvIvhuOOu1zLIfVf4Im/orzs/hE3Xscplr 7F7YNr2RDLE/Lee8ZeDypdqCtAH8Rpf957//32zV9BuFIu0Xplvsm2Fx1Uh3 7KCFfRmfKiOd6NEiLqmuR8r4MQZ2MhS1ge+22zVtP9QadGUt5UCcgnruGDA7 VIwTkaVxvdXOxIdqCXFFGFsDDhji5higqoZPODEYJ16zh9kjZ53qgXXSwPWR /KuIrFiUkIq7TuI2o571xI2HJcZD44X3trGLfUqm3fQKGpIFeV0v3lgjue/X 67X84VmgC6k+OX8QCRIdrGbcK2Aa2JEgwf8O0AMZ2h3t4A4soqG3seFk3+XW Fj7IMrIZZZU43BU2D8upK6tToOF9x6cyqvj8hd1xI5Mzc4MIIpf9kDjgYvQE g0cF9MpLt96vHXsdCfyLdibmQY1urLnZw76oPMd6wRbZ82iChAEptdn3A3vr 2MX56BiisG/eizTmUbfBB1SX/FRtiM2whYB348RhTI2rHWuZUyyFGJ5JloZ3 jEIyIUtqPnOhX7OTl/dfnqYc1kQyKBB+FGjCMP2ZVlLzndfz/kgiWeOkdal9 fwjVXeo8kksPj+uBXBfgic7iYivRsqyG6hoGiRVpQNYh3bQbuo2E7tb9Ldsk O5TZwOMeUOFEDrSHO07Reax/dHCAYfcikchI7SagYWL1DBz5MxV5IsU+OvwO TwUuA5+b0hgCrQqkqgRJWdYRe5BewOBhFXuBtrJHWorV+mcCD+aphY8cN0nx kpXbOKI7wgXMeUfvehf9C4IjDRvzZbayk9xgl8V+p3i6CUNc+uZgTzhMiy1i zEIImn8atWC0jop0B0LsOAWKlWIZMOfJg1edjhahdxzVQNo0PWksD6i4kcCH xzv4/QkvCWAuVHBSexlZuXDnx6W0yKcIsuuSmjxqTVoCwTASY6pGQLsT1+pp 5gHF8T3sCZzoME5TqMNRgMOnIQ6zRz6HExIx/Ocj5KLuTTwpVxZx2iaAFkaA Cb4wCaJoRj9/mHXHGumONtIdNNL7sY2G3uPWe4vRx1+JPu6m2ZFOJ0aYDGES qbAITX/eFf7nU/iGz7zyuRCHT1z5Q9m5Y+LAJefYPecgQYJy+I4tAHfUxVmF cjYCW0920lTIb54IsUSASSBbd4sL/+gOIVkbJdhXISqB404xgkGkStJuN0Yy TEw6xjI8FWhhJAjZElSD+WvFJ0RWsvG+7/S8OEDp7fCRPyX2vYcifDz5Hm+b z/k5zcG/0iT8i9c/4qr/WRPbz55/9yz+eTJZ/LtH8AXmECfm3RzGg/3/fQ5x tv4Tc9D1+cJz+ELSYZy9ZwHxxHG6hBNjSSFZ8SToXPIhzJYs/7Ilz1WCErA2 oEQBdlWPrmDnOByqHm2cRFo0HhATEEOaxq6zfw52CBtNbxRn3uFxOIBoq1JQ zY23VhKT6hMiBCYwyY8DmOOX3ai/o83sI5/P59ojn8/n2j8zgi/FtVibQ50m MRk92sCok7vZeS15zxCmSIrqAS8uN7g4BaOZFXTnIwxREArnBtjeh37qLdI4 a/imciAZzupXXN3POxhfsYPJVq7z7DQQykfarlATAtFFnHBEiQQH5JZzfnH9 HGf3mmvLGHpfjAC7LafhD11wa1xUuBk6wLnTsGiXXTW8ASvTdW3TaNm7qly1 4qek+Tc5qMUnK3s+3C6uUkEuddlLFSOgRuB96h6LohnRaWda0SocVhsXXTJ5 i+JfDrXOERYmguZZ2dLgWUogUQMgPc6fyfnrmO7+ONTcYfglIo4M+KYpJJQT Y0kKy96rH55W4srEodzuyDfSg1P+FAGcnQnX1yEZo4oUfJwIQRI/aZ/eqQvn AX/6CFX2pml7jg8nY3BWlFRcknxEUXaIE3DROVvLV38ywJHcnXzVBCvigEiq BTzGQajQO4XKIZKwY7LAsRqtKS3US2zVOPxC/yVb0A1+zRW2WBxzpU2WvXen a8v8cneymkwKWUL4B0dYNPekxdhc+FIs12Pl0OQcJAKhk7eh/VPmoNwwdCtN Jh87JRQXAopz7MLLhUzJn63xrSiBWJnRM8QChk/jSWd8oK0PAAJ/HMMP2p0L 4rDzttG6Dd3ozLnHiY2qXsUJcB2pJkNwoN1cJUE1xYbYQsgbBbl9YT9f2sCf p4xyZXGMxxUFoPVgPtLZcC6Hqc5pCzSb1AfUekE0uc5yPMilNWPU3CFuLJAr 7cCnWfzpqtvGVRvCMHOIiYojzHqYk1fCPbZw+gQ7rR4csQZX+zAqEYj2qqYb Ac4FnVOzKJKY/xgKHpUAmZyLoyfnIBEuQ90Do5JZs0J+lmyGKVQoql54UJ9A DMFtA5E6Zx7k+i1jIE7YIvFiSVLOQwJycv0cdtnhlDbmvWlFrpAsQWJScjod dZDCgo7M+nNXEEW6yKQs8+tqH7JhrPG2WmdMihFUAY3vWZgZ2tMzRV17nB5o vNuFtHRctkeP2Ffg/J0cnl8rSCRgvuPDVswFN4p2daUV7ZbkNKfUsXor09ID SEXjbBCvfjrgY0wWMdZEDhTp1kbhFi+TwpZIBvBJQjmXKodxb6wr0wBr4EqP +01jaTnYCwsu2FnL7Flzi/07F+gjT2ONZCgRjzwAcBr56BIPOISTlq3nBpW1 NZO6Z1mZVrdbR0niCgXOkCZRrePOMiYFELosRq65KngJjNeUWz1tTM3UGhAO VQV9FW30LlRd0GIOeVp/dGwsTGDz3qRH6gMer052BI7pHYBRdPcroCrW0eND n2ldRd+qPyGYXI4VhsAYiGOtB8sqZC/uTjGBsrfelSHRKHWLON80Cdt7A8TM GMmG5WYoDRuFiYBViTNG7FEHEtg6CUgtr8kmalSeGBQ/NABOizaXggNhGrJZ IvEZpYtdGTdToQBovyFG0UoXDXKEmxLAv93Ah0ZbojDtaLfvDnARqPJBhh2y BWz5ROW1bFUtdI/TiJLB7EwXpK9LS40qA5RtCr0MUGlGFsDj6AdqvZo7EKIe FjyV/QohcCBnZG2KIc7wSz2EIIpYR8TVG5ooPsiJr/FqpJw+gXbHettqfQQm 9shB78yEcc4AH5epCTsHUICJYqYJHNxv2nElscQAydaWN4+34TlRhVE75KjP mY8rCkep5XGNVY+JUtBLXMRP6rs6W4kBXE/e7Up37uF8dATbHUoLqF9kSaNq zKJmLJqYWBx/nuCrzq+RkCCom+RSo4dTU0tiQrYss8cOU+tT6vGwkFKSURWS 0O0m6+piaohLCdweG5sYcI5E04ZtAYBR7dogNqwVx9qW9YGemd9aCOyy2y4P 6frWB9OXmct1Txut+X7Cgi7DocEI4ekWgpNWhwshMkjKcsKffIvg2jlbFLy/ ZQ8KTIbXNuTVFGUseAAxoqVcpSv2mSDX2fLZi/0UxS+m0G0ccP+IXxIKSWAA HGfIbcmj6ViSOcIdqpbwZKRgvFj0nSfiYXT2notGyIkCuLCselSryvADPkTj OBw6EE2rpVQ9P01wQQSPvLAkCHy0kxV2UohQCl3mEndY6ddx8fPj1aFD1Tes GtfPi/mjXKfwx/0IySFb2Fv6xhd5Q6hpfVD4JyBhOcEeIlios4RmPCtH8KsR ZkgNSf9+BZLH555TAG+2tx4X6WSfL4FhpAQUW79exLHyB/5Rnb89zaNz2fYX tL5PSBRvstcosZ6dvHjy+tS1CNsrebsDri5ePTp1Re2MlK/zpfJZ/qZ12ZUr VwOtOXLQzHy7FmElUJZfDyNMeIXh1rol3WGz6LC/w9x2GY0i8y+u6LTCbzeK Xyggw8HM9cARV9Bzr67QB0N1+URxmKoX8PdJKBPxAwQcuj/5YcGUIkZ4SWs6 bFMqvqRryJIzhEWI1rl6Bw5eMSqX5mBLm6EuiE06oGxGwcoAg4rK4AuiKz2V K1SOTH+eYVSJpIvlSAFDj0X5nt/iJPXYQsaTzRctJiTGB+wlhzODghw9xdA0 ck1kIZyXHY+PhxYtYcklG5WGPFjFi09VWePyPh6GFpFC6rfEF0cDk+BEVNOM 3Vj7DlRgrETUGERaU1esbVQPYM7EiKNGBXG1pn3pwGV8JkDsYAT7GnbaJkG0 6fZyBpI73cFpXV/DSuLXJ1+fqpjE+4QCL4vH5mrDIfS5GXpZWgmM0+3M2BBO N01ZcABASxfx6a6T+6dJ9CtE2zZaS1ZlvcDEOr3ZMVSEnAtUXEJ6Cf+Hws78 mo2mKWIkpAttBVXoI7ObqeLT0UKVteMYERpJrMa/SoKLWnpk3lDHVQeSBAM1 R4K2ydn2irqJCvuapFqNO/TgRXQnrbpWIlyzOsXh6NMWIRUhpRx7fAdMkJ6Z KsqCNWPTHpa7Tt8vEMUGpviC9mJZiUnNfhXZjyj+697/ElNDCDyKg0betkeQ CV4qos/JKwCiHBjqwWlk0Qt4ipel4wo0vdbj1uCpcW/4SKsOCiAB8EmGleJ1 GFK/aUcarOrSGpNLeWmajOXVfZLeDGF0oaiRT6WFeTju5QIaYS5zJCh9ARgN K+lgeZw6x3CP2SBMEt/iUqtJHcwRbI1D+y6Mu7h4/QboDH/MukvIy6qWVk34 eq5y/dCExFsBZaWJyvUAGwpfYZnJYduwFpxtczV9IyY9rGOzXCyWkznOj14g w+bu3cUHEPPDAt+z7H8uFov/lWXuwv1jFx7oBe3/p3/842yym49e+EPJ1Xg5 /Al+5vULz7oRqyGp+rQKLzUwB7pwKwJWXrMTrZcqpFCgTB907nq09gt+r5Or 1x5qrI+6Ym/HqSyIsehdJVFrelZv07S9O12mkGvRuYptclUox3oRpkZnbTzk SO97CIHkjhrJeEZcrpbuFBxTW3Ps6lvzYESuD6VgRJEzqIqZX2P8n3z4qjW7 jcIdIwwUaTWr80GN00iGPPBTdSvjoRcQdLjSHVxS+Re38/X0nQ+m6kVdJM9F n1S4HbvyYPbdMWzg0Qu4MhvXTwJKgTEL8YV7CY5BrtxL8Zf6cYDJ+EIKopQr +G02HHt6OPr0EJ6uR2hQDJFLNsUX7gXYhb9yL4ViLBaz4hiJjl7AlS8EuPyC eMv/QrjleJs7CRox6XeyDx7JRu1S3OUFTjJMipY6dQaxv+WSaffzAyHFopCj uiyVy36uAAwPJAhnoictHdHeIxN4hJEaT3bhKr1AuJ1HwgISe4uS6FKnvmRX kiZFIobfxMR1FPVIZTR3DwzTs4SclWzJhpFowyGVol7v6wF6tq1c30n96Ll7 fc087QLgsPsBW5ZckO6W2bd7J8TmwYKb7CVtWyBtgnaN8GvOAdXmx3Lx3jEM laDKgMiKSxcJRsvDs6afvvdx/NhHkF1nH346epGsjn+cfeTR7OijsiuOXb2Q 9Z0t/vTnEwQ9/IXRqSDo1wck/kNEn+jhKL3+my/D4ef3LcwkePF3L9X0KKaX amIUR0iV/XdevC+hGb2ycCoyfY+uvzoqvhipwOhNSgIERJLTnXyPlCEZ2A7I ceCdSHkjFwcIp+uOKkUf9QX6YBybkrjUIg1qHYSTDg5+RS90GFWFkRevtezs hFcS+VSBmwyHcSXWNgbWfXo4h2A7/7JlFCmjH+kX97ZwPj7BWjosxFypGJ+u hiZXkOanunfBNbyoxOx2bWMkpOBxbRyaRcSO58wvV0b9lO9Mb1Hy5Y17E+7J 8+/enNKT3YBwFzzVpraHU1oeQQHH71x4KYCaH3DysOoCJBhFw3D4O+JBpYXH eejJTIfluvEvCbiRxiQKEUff+tb8bHNBzQZQGiDEpQQmERsMsFJf7yPAjSt9 Q0LebFd4cbbDq/ogGFsawCQjhoSYsQb+47dVJwGiOdBHiJjLCVDZYmWbjPvn BqXg9/7Fpm43yN7gZChwzD6wGB/xtkS9Zu9BNTwfOYpaDf4YLb/R+wBtGYGS QoVtLRqgQFRpVQ6acp5TR29Qlr82gjrkjIiCrjrLFevDeWgP0eGzCobPEbgK JQd1SGjCjaJt+IWCAKme59eacuSEjmZCkDy+5l4uGyRGynn2ho9fn3eb26Yp Fhdb4o55dr4qBjImK7PNviX7fqjpp9Z0my1tgvPrDdBK9NPjkjbSJSDSOKn5 LYKj2UW5a4gQ5xVxKPIoaJ+WPR/m2TPT7IfsogE871kz8HvZ39Hv8avd59n3 peUr84PXsDPVfsA7NuvskW3Xzlwv+Xw13lODDAfHtyUTZytg3NybqwUf7l88 dze7sPnAL8B5FFd56NyRkvTdp/5FiVIGDAEc9w4gn28XpIAwEOfK+cVLTG6E m25cDUQ9584v+f6Ww+w/EKMXQSO8tTcKNZeXfqvgp/niJQtu2KM3Mchrr90L bPzLM7XIY5HR3re8BcIe97XNIPvcAWaZYemwfQ5BYsIrvxnfy4wnxYtEc8Rt +Hg4UeGrkSglImqwRypTpbXz+b0F7ky3H5+T2rJtp/o7J3YeannXPR/tmQCt 5VWTK6pOX7ftLyXvhJoHmDztYADw3HsBsse2hvyi1bvQI8Mnj5uLU2BpSVYw Wz0/f3V+wFLpm5eRI64budPkLujLb0hfUTP0dfb/ANTS2EkFhwAA[rfced] Regarding terminology throughout the text, the expansion of TVR as well as its capitalization and hyphenation appear to be used inconsistently. For consistency, may we update to the term on the right? Expansions of TVR: Time-Variant Routing (TVR) vs. Time-Based Validation and Revocation (TVR) - 1 instance. see question above. This has been updated: Time Variant Routing -> Time-Variant Routing Capitalization/hyphenation variants: May these be updated? time-variant algorithms -> TVR algorithms time-variant route computations -> TVR computations time-variant routing computations -> TVR computations --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>