RFC 9657

Time-Variant Routing (TVR) Use Cases

📅 published October 2024, from ietf

🦋 RFC 9657: Time-Variant Routing (TVR) Use Cases 🦋

okay bestie, so this is an Informational RFC (not a Standards Track spec, so it's a vibe-check doc, not a rulebook) 💅 It was published in October 2024 by the IETF, and it's not updating or obsoleting anything. 🎀

The authors are a whole squad 🫶 E. Birrane, III (JHU/APL), N. Kuhn (Thales Alenia Space), Y. Qu (Futurewei Technologies), R. Taylor (Aalyria Technologies), and L. Zhang (Huawei). The ISSN is 2070-1721 🌈

Okay, now the good stuff ✨

Abstract ✨

so the whole point of this doc is to show off use cases where Time-Variant Routing (TVR) computations could make routing protocol convergence and/or network performance way better. TVR basically means routing that actually plans around stuff that changes on a schedule (or is predictable) in the network 🧚

Status of This Memo 📜

ngl this part is kinda legal-coded, but here's the tea 🍓

This document is not an Internet Standards Track specification; it's published for informational purposes. It is still a product of the IETF, it represents the consensus of the IETF community, it got public review, and the IESG approved it for publication. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🙈

Info about the current status, errata, and how to leave feedback lives at https://www.rfc-editor.org/info/rfc9657 🔗

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) as of the publication date. Read those carefully, bestie, because they're your rights and restrictions. Any Code Components pulled out of this doc have to include Revised BSD License text (see Section 4.e of the Trust Legal Provisions), and they come with no warranty, per the Revised BSD License 🫶

Table of Contents 🌸

  • 1. Introduction
  • 2. Resource Preservation
    • 2.1. Assumptions
    • 2.2. Routing Impacts
    • 2.3. Example
  • 3. Operating Efficiency
    • 3.1. Assumptions
    • 3.2. Routing Impacts
    • 3.3. Example: Cellular Network
    • 3.4. Another Example: Tidal Network
  • 4. Dynamic Reachability
    • 4.1. Assumptions
    • 4.2. Routing Impacts
    • 4.3. Example: Mobile Satellites
    • 4.4. Another Example: Predictable Moving Vessels
  • 5. Security Considerations
  • 6. IANA Considerations
  • 7. Informative References
  • Acknowledgments
  • Authors' Addresses

1. Introduction 🦋

okay so the networks we're talking about are ones where topology changes are expected, not surprises 😭 Like, when a link goes down or a new one shows up on purpose, that should be seen as a nondisruptive event, not a crisis 💅

Why does this happen? Lots of reasons ✨ Mobile nodes like unmanned aerial vehicles and some orbiting spacecraft constellations lose and re-establish links as the platforms move 🛰️ Networks that don't have reliable power, like ones harvesting wind and solar, might only have link activity at certain times of day ☀️ And networks that prioritize green computing and energy efficiency over raw data rate might plan their traffic around energy costs or expected user data volumes 🌈

This document covers three categories of use cases where a route computation might benefit from knowing about time. Each one is laid out the same way:

  1. An overview of how route computations might pick different paths (or subpaths) depending on time 🧚
  2. The assumptions the use case makes about the network and data exchange 📋
  3. The specific routing impacts 💥
  4. Example networks that fit the use case 🌸

The three use cases are:

  1. Resource Preservation (Section 2): there's info about link availability over time at the client level. TVR can use that predictability to optimize connectivity by taking endpoint resource preservation into account 🔋
  2. Operating Efficiency (Section 3): server cost or path cost varies over time. TVR can exploit that predictable path cost to optimize what it costs to run the system. The notion of path cost gets extended to be a time-dependent function instead of a constant 💰
  3. Dynamic Reachability (Section 4): there's info about how link availability varies between nodes along the end-to-end path. TVR can use that predictability to optimize in-network routing 🦋

Heads up: this doc isn't claiming to cover every case where TVR could help network performance. New use cases will keep showing up 🌈 And the concrete examples inside each use case are just there to prove the use case exists. They aren't meant to be a complete list, and it's likely that several example networks could count as instances of any given use case 🙈

The doc also focuses on deterministic scenarios. Non-deterministic stuff, like vehicle-to-vehicle communication, is out of scope 🚗

2. Resource Preservation 🔋

Some nodes live in resource-constrained environments, or just have limited internal resources. Things like available power, thermal ranges, and on-board storage can all change what a node can do at any given moment ⚡ Resource management on such a node may need certain functionality to be powered on (or off) so the node can keep participating in the network 💖

When power is running low, noncritical functions might get switched off to extend the node's life 🪫 Or the opposite: certain functions might get turned off so the node has enough power to respond to an event, like collecting data 📡 If a node is in danger of breaking a thermal constraint, normal processing might pause and it moves into a thermal safe mode until things are back to normal 🌡️ When local storage runs low, a node might spend power to compress, delete, or transmit data off the node so it has room for future data collection 💾 Sometimes a node also just goes offline on purpose to save and accumulate power 😴

Beyond power, thermal, and storage, there may be other resource constraints too. Preserving those resources can be necessary to keep the node (and its proper function) alive in the network 🫶 Nodes in these conditions might benefit from TVR computations, since their connectivity changes over time as part of preserving the node 🦋

2.1. Assumptions 📋

To manage on-board functionality based on available resources, a node has to understand specific things about how resources get used up and how they get replenished 🧠 It's expected that patterns in the environment, device construction, and operational configuration are regular and stable enough to allow meaningful planning. This use case makes the following assumptions:

  1. Known resource expenditures. It's assumed there's some determinable relationship between the resources a node has and the resources it needs to participate in a network. A node needs to know when it has met some condition for joining or dropping out of a network. Kinda like predicting how much battery a laptop has left based on how you're likely to use it 💻
  2. Predictable resource accumulation. It's assumed that resources accumulate on a node predictably, so the node can expect (and communicate) when it's likely to rejoin a network. Like predicting when a laptop battery will be fully charged 🔌
  3. Consistent cost functions. It's assumed that resource management on a node is deterministic, so managing the node as resources get spent and gained is consistent enough for link planning 📅

2.2. Routing Impacts 💥

Resource management in these scenarios might mean turning off parts of the node as part of on-board resource management, and that can change how data gets routed in a few ways 🌸

  1. Power Savings. On-board radios may be turned off to free up processing for other stuff. This may happen on power-constrained devices to extend the node's battery life, or to let the node do some other power-hungry task 🔋
  2. Thermal Savings. On-board radios may be turned off if there are thermal considerations, like the node's operating temperature going up 🌡️
  3. Storage Savings. On-board radios may be turned on so they can transmit data off the node, freeing up local storage for new data 📦

Here's the catch 🙈 Whenever a communications device on a node changes its powered state, the network topology could change (if the node is within range of other nodes), and that affects route calculations through the network. Also, when a node joins a network there may be a delay between the node joining and any discovery about the status of its functional neighborhood. During that window, forwarding to and from the node might be held up while things get synchronized ⏳

That's the end of part 1, bestie! 🌈 Send me part 2 and we keep the slay going 💅✨

2.3. Example 🔋

okay so a super clear example of a network that needs resource preservation is an energy-harvesting wireless sensor network 🌞. These nodes have zero plug-in power. They live off environmental stuff like solar panels, so it's literally survival mode all the time 😭. How much juice a node has can swing around based on sensor activity, processing demands, and where the node is sitting or pointing relative to its energy source 🧚.

Let's imagine a simple three-node network where every node is charging up through solar panels ☀️. The power each node has left over for radio frequency (RF) transmission is shown in Figure 1 💜. Each of the three nodes (Node 1, Node 2, and Node 3) has its own plot of available power over time, so they're all having different power moods 💅. This example assumes that a node won't power up its radio until its available power gets over some threshold. You can spot that threshold as the horizontal line on each plot 🎀.

            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

                     Figure 1: Node Power over Time

The connectivity of this three-node network changes over time, and the changes can be predictable 🔮. They're also likely able to be communicated to the other nodes in this small sensor network, which is so smart 🧠✨. Examples of connectivity are shown in Figure 2 🦋. This figure shows a sample of network connectivity at three different times: t1, t2, and t3 ⏰.

  • At time t1, Node 1 and Node 2 have their radios powered on and are expected to communicate 📡.
  • At time t2, it's expected that Node 1 has its radio off, but Node 2 and Node 3 can communicate 🫶.
  • Finally, at time t3, Node 1 may be turning its radio off, Node 2 and Node 3 aren't powering their radios, and there's no expectation of connectivity 💀.
          +----------+        +----------+        +----------+
     t1   |  Node 1  |--------|  Node 2  |        |  Node 3  |
          +----------+        +----------+        +----------+

          +----------+        +----------+        +----------+
     t2   |  Node 1  |        |  Node 2  |--------|  Node 3  |
          +----------+        +----------+        +----------+

          +----------+        +----------+        +----------+
     t3   |  Node 1  |        |  Node 2  |        |  Node 3  |
          +----------+        +----------+        +----------+

                    Figure 2: Topology over Time

3. Operating Efficiency 💸

Some nodes in a network might change how they network so they can optimize metrics tied to what it costs to run the node 🤑. Section 2 is all about resource preservation, which is about node survival 🥹. This use case is different because it's about non-survival efficiencies, like the financial cost of running the node and the environmental impact (cost) of using that node 🌍💚. Very main character energy for the planet 🌈.

When a node runs on some preexisting infrastructure, there is typically some cost that comes with using that infrastructure 🏗️. Here are some sample costs, bestie:

  1. Nodes that use existing wireless communications, like a cellular infrastructure, have to pay to communicate to and through that infrastructure 📶💸.
  2. Nodes supplied with electricity from an energy provider pay for the power they use ⚡.
  3. Nodes that cluster computation and activities might heat up and rack up extra costs for cooling the node (or the whole collection of nodes) 🥵🧊.
  4. Beyond financial costs, assessing the environmental impact of running a node can also be modeled as a cost tied to node operation. That includes things like earning carbon credits or other incentives for green computing 🌱🫶.

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 tied to operation 🔥. Predicting the timing is the whole move 💅.

3.1. Assumptions 🧐

Being able to predict how a node's resource use affects things over time assumes the node exists within a defined environment (or infrastructure) 🏘️. Some characteristics of these environments are listed below, and honestly they're kind of the rules of the game 🎮:

  1. Cost Measurability. The impacts of operating a node within its environment can be measured in a deterministic way. For example, the cost-per-bit of data over a cellular network or the cost-per-kilowatt of energy used is known 📏.
  2. Cost Predictability. Changes to the impacts of resource utilization are known in advance. For example, if energy is cheaper in the evening than during the day, there's some way of communicating that change to a node 🌙☀️.
  3. Cost Persistent. Changes to the cost of operating in the environment last long enough that behavior can be adjusted in response to them. If costs change too rapidly, it's likely not possible to meaningfully react to the change 🏃‍♀️💨.
  4. Cost Magnitude. The size of the cost changes is such that a node sees a minimum threshold cost reduction through optimization. A specific time period is designated for measuring that cost reduction ⏳.

3.2. Routing Impacts 🗺️

Optimizing resource utilization can affect route computation in ways that are similar to what happens with resource preservation 👯. The route computation might not change the available path, but the topology as seen by an endpoint would look different 👀. Cost optimization can impact route calculation in a bunch of different ways, and some of them are described below 💅:

  1. Link Filtering. Data might pile up on a node while it waits for a cost-effective time to transmit 📦. Individual link costs might be annotated with cost information, so adjacencies with a too high cost might not be used for forwarding. This basically filters which adjacencies get used (possibly depending on the type of data being routed) 🚫.
  2. Burst Planning. When there's a cost savings from fewer, longer transmissions (versus lots of smaller transmissions), nodes might refuse to forward data until there's enough data volume to justify a transmission 🧃📈.
  3. Environmental Measurement. Nodes that measure the quality of individual links can compute the overall cost of using a link as a function of the link's signal strength 📶🌩️. If link quality is insufficient because of environmental conditions (like clouds on a free-space optical link, or long distance RF transmission in a storm), the cost to communicate over the link may be too much, even if access to infrastructure is otherwise cheaper at that time of day ⛈️☁️.

In each of these cases, the efficiency of transmission gets 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 the energy costs that come with it 🕰️💜. Accumulating data volumes and picking more opportune times to transmit can also mean less energy used by radios and, thus, lower operating cost for platforms 🔋✨. Smart and sustainable, periodt 🌸.

3.3. Example: Cellular Network ✨

okay so picture a bunch of nodes running over cellular connections 📱, where the plan charges different rates for peak and off-peak data 💸. Each node might get a fixed set of "peak" minutes, and if it goes over, bestie gets hit with expensive overage charges 💀. The whole point of peak and off-peak pricing is to discourage using the network when the cellular network is likely to be slammed with calls, like during the workday 🙄.

Just like pricing can nudge a human cellular user, the same pricing info can be coded up so that machine-to-machine (M2M) connections prioritize off-peak communications for certain kinds of data exchange 🤖💖. A lot of M2M traffic is schedulable, like nightly bulk file transfers, pushing software updates, synchronizing datastores, and sending noncritical events and logs 🗂️. These activities are usually already timed so they don't disrupt businesses and customers, but they can also be timed to keep overall cost down 💅.

Consider a simple three-node network, similar to the one pictured in Figure 1, except that here the resource that changes over time is the cost of the data exchange 🎀. This case is illustrated below in Figure 3. The figure has three plots, one for each of the three nodes (Node 1, Node 2, and Node 3). Each node lives in a different cellular service area with its own peak and off-peak data rate times. You can see it in each plot: low cost means off-peak, high cost means peak 🌸.

   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

Figure 3: Data Cost over Time

Assuming we already know when the peak times are, we can work out the cost of exchanging data from Node 1 through Node 2 to Node 3 🧮. Examples of these exchanges are in Figure 4. Looking at that figure, both t1 and t3 cost less than communicating at time t2 🫶.

      +-----------+          +-----------+          +-----------+
 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  |
      +-----------+          +-----------+          +-----------+

Figure 4: Data Exchange Cost over Time

It's not always possible, but a super optimized plan would be to send from Node 1 to Node 2 at time t1, then hold the data at Node 2 until time t3 and deliver it to Node 3 🧠✨. This case is shown in Figure 5.

      +-----------+          +-----------+
 t1   |  Node N1  |---LOW----|  Node N2  |
      +-----------+          +-----------+
                             +-----------+          +-----------+
 t3                          |  Node N2  |----LOW---|  Node N3  |
                             +-----------+          +-----------+

Figure 5: Data Cost Using Storage

3.4. Another Example: Tidal Network 🌊

Another operating efficiency example is the so-called "tidal network," where traffic volume swings a lot depending on the time of day 🌀. Think of a campus network: thousands of people head to classrooms and libraries during the day, then go back to the dorms at night. That creates a regular back-and-forth in network traffic across different spots on campus 🏫🌙.

In a tidal network, energy-saving tactics may include turning off some or all of the components of network nodes ⚡. These moves can change the network topology and affect data routing in all sorts of ways 🙃. Ports on network nodes can be selectively disabled or enabled based on traffic patterns, which cuts the energy use of nodes when traffic is low 🔋.

More info on tidal networks can be found in [TIDAL] 📚.

4. Dynamic Reachability 🌍

When a node sits on a mobile platform, the platform's movement (and so the node's movement) may change the network's topology over time 🚀. Those topology dynamics can be a really big deal 😭. The more predictable the relative mobility between nodes is, and the more predictable the environment's effect on signal propagation is, the easier it is to plan for losing and gaining adjacencies too 🗓️✨.

Mobility can cause an adjacent link to drop in a few ways, like these:

  1. Node mobility can make the distance between two nodes large enough that distance-related attenuation knocks the mobile node out of connection with one or more other nodes in the network 📉.
  2. Node mobility can also be used to keep a required distance from other mobile nodes in the network. While moving, outside factors may cause links to drop through occultation or other hazards of moving through a shared environment 🌫️.
  3. Node mobility can make the distance between two nodes change quickly over time, which makes it tricky to set up and keep connectivity 🎢.
  4. Nodes with communication terminals that can adjust their orientation, or that move behind and out from barriers, will also set up and lose connections with other nodes depending on that motion 🔄.

Mobile nodes, like any other node, can run into issues with resource preservation and cost efficiency 💸. On top of that, they can have their own challenges because they move 🏃‍♀️. Links that come and go can lead to neighbor relationships that change at the node level 💫. This use case is all about looking at how motion-driven changes to network topology affect routing 🧭💜.

4.1. Assumptions

Predicting how node mobility affects route computation takes some info about how the nodes move and what kind of environment they move through 🗺️. Here's some of the info that's presumed to be available for planning:

  1. 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 TVR algorithms would not exhibit purely random motion 🎯.
  2. Environmental Knowledge. When otherwise well-connected mobile nodes pass through certain parts of their environment (like a storm, a tunnel, or the horizon), they may lose connectivity 🌩️🚇. The length of that connectivity loss is assumed to be calculable as a function of node mobility and the environment itself 🧮.

4.2. Routing Impacts

Changing a network's topology affects how paths (or subpaths) through it get computed 🛤️. In particular, the following features can be implemented in a network with mobile nodes, so that different paths might be computed over time:

  1. 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 ⏳. If a route computation knows an adjacency has expired, it can plan for that loss instead of falling back on an error recovery mechanism 🙌.
  2. Adjacent Link Resumption. Just as the loss of an adjacency can be predicted, it may be possible to predict when an adjacency will come back 🔁.
  3. Data Rate Adjustments. The achievable data rate over a given link isn't constant over time and can change a lot depending on the relative mobility between a transmitter and receiver, as well as the environment being transmitted through 📶. Knowing both the mobility and the environmental state may let you predict data rates, which can affect path computation 📈.
  4. Adjacent Link Filtering. Separate from whether an adjacency is currently present or absent, a route computation might choose not to use an adjacency if it's likely to expire soon, or if it's likely to see a significant drop in predicted data rate 🙅‍♀️💅.

4.3. Example: Mobile Satellites ✨

Okay so this one is literally my favourite 🛰️🌈 A relatively new kind of mobile network that has popped up over the past several years is the Low Earth Orbit (LEO) networked constellation. Lots of companies and governments are building these right now, and honestly, the vibes are immaculate. This example is about LEO satellite systems, but the mobility events can also be applied to satellite systems orbiting at different altitudes (including Very LEO (V-LEO) or Medium Earth Orbit (MEO)) 💫

Most LEO networked constellations work on a similar idea: hundreds to thousands of inexpensive spacecraft that can talk to their orbital neighbours, and also talk down to any ground station they happen to be passing over 🧚 A ground station is a facility used to communicate with satellites in LEO. The relationship between one spacecraft and one ground station gets kind of complicated, because each spacecraft may only be over a single ground station for a few minutes at a time ⏱️ Plus, depending on how the constellation is shaped, there are scenarios where (1) the inter-satellite links need to be shut down to avoid interference, or (2) the network topology changes, which swaps out the neighbours of a given spacecraft. Chaotic, but make it make sense 💅

A LEO networked constellation is a great example of planned mobility, because spacecraft in orbit are super predictable 🌸 Other mobile vehicles can run into unpredictable changes in velocity, but spacecraft operate in an environment with relatively stable velocity conditions. That determinism makes them an excellent candidate for TVR computations 👑 Still, inter-satellite link failures could introduce some unpredictability into the network topology, so it's not all perfectly smooth sailing 😭

Let's picture three spacecraft (N1, N2, and N3) following each other one after another in the same orbit. This is sometimes called a "string of pearls" configuration 🫧 Spacecraft N2 always stays connected to its two neighbours: N1, which is behind it in the orbit, and N3, which is ahead of it in the orbit. This setup is shown in Figure 6. Even though all of these spacecraft are mobile, their relative motion keeps them in continuous contact with each other under normal conditions 🎀

      .--.                     .--.                     .--.
####-| N1 |-####  <--->  ####-| N2 |-####  <--->  ####-| N3 |-####
      \__/                     \__/                     \__/

               Figure 6: Three Sequential Spacecraft

Flying over a ground station creates a non-relative motion between the ground and the spacecraft. In other words, any given ground station is only in view of the spacecraft for a short window 🙈 The times when each spacecraft can see the ground station are shown in the plots in Figure 7. In that figure, ground contact is shown when the plot is high, and no ground contact is shown when the graph is low. So spacecraft N3 can see ground at time t1, N2 sees ground at time t2, and spacecraft N1 sees ground at time t3 🌈

   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

        Figure 7: Spacecraft Ground Contacts over Time

Since the ground station in this example is stationary, each spacecraft will pass over it, and that changes the network topology 🔄 This topology change is shown in Figure 8. At time t1, any message sitting on N3 and destined for the ground could be forwarded directly to the ground station. At time t2, that same message would instead need to be forwarded to N2 and then forwarded to ground. By time t3, the same message would need to go from N2 to N1 and then down to ground. Main character topology shift 💖

    +------+          +------+
t1  |  N2  |----------|  N3  |
    +------+          +---+--+
                          |
                         /|\
                        \___/
                         / \
                       Ground
                       Station
------------------------------------------------------------------
    +------+          +------+          +------+
t2  |  N1  |----------|  N2  |----------|  N3  |
    +------+          +---+--+          +------+
                          |
                         /|\
                        \___/
                         / \
                       Ground
                       Station
------------------------------------------------------------------
                      +------+          +------+          +------+
t3                    |  N1  |----------|  N2  |----------|  N3  |
                      +---+--+          +------+          +------+
                          |
                         /|\
                        \___/
                         / \
                       Ground
                       Station
------------------------------------------------------------------

             Figure 8: Constellation Topology over Time

This example focuses on the case where the spacecraft fly over a ground station and introduce changes to 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 info on in-constellation network topology can be found in [SAT-CONSTELLATION] and [SCN]. For this example, and especially for within-constellation topology changes, the TVR approach is important to avoid the Interior Gateway Protocol (IGP) issues mentioned in [SAT-CONSTELLATION] 🦋

4.4. Another Example: Predictable Moving Vessels 🚢✈️

Another relevant example for this use case is the movement of vessels with predictable trajectories, such as ferries or planes. These endpoints often rely on a combination of satellite and terrestrial systems for Internet connectivity, and they capitalise on their predictable journeys 🧡

This scenario also covers situations where nodes use dynamic pointing solutions to track the mobility of other nodes. In those cases, nodes dynamically adjust their antennas and application settings to work out the best timing for data transmission along the path 🎯

5. Security Considerations 🔐

While this document does not define a specific mechanism or solution, it serves to motivate the use of time-based validation and revocation strategies. Therefore, security considerations are expected to be addressed elsewhere, such as within a TVR schedule definition or through a protocol extension that uses a TVR schedule. However, it's really important to note that time synchronization is critical within a network employing a TVR schedule. Any unauthorised changes to network clocks can disrupt network functionality and potentially lead to a Denial of Service (DoS) attack. Please protect those clocks like they're your best friend's phone passcode 😭🚨

6. IANA Considerations 📋

This document has no IANA actions. Nothing to register, nothing to update, we are clear ✨

7. Informative References 📚

[SAT-CONSTELLATION]
           Han, L., Li, R., Retana, A., Chen, M., Su, L., and T.
           Jiang, "Problems and Requirements of Satellite
           Constellation for Internet", Work in Progress, Internet-
           Draft, draft-lhan-problems-requirements-satellite-net-06,
           4 January 2024, <https://datatracker.ietf.org/doc/html/
           draft-lhan-problems-requirements-satellite-net-06>.

[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>.

[TIDAL]    Zhang, L., Zhou, T., Dong, J., and N. Nzima, "Use Case of
           Tidal Network", Work in Progress, Internet-Draft, draft-
           zzd-tvr-use-case-tidal-network-02, 28 July 2023,
           <https://datatracker.ietf.org/doc/html/draft-zzd-tvr-use-
           case-tidal-network-02>.

Acknowledgments 🫶

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. The people who made this possible are absolutely iconic 👑

Authors' Addresses 💌

Edward J. Birrane, III
JHU/APL
Email: edward.birrane@jhuapl.edu


Nicolas Kuhn
Thales Alenia Space
Email: nicolas.kuhn.ietf@gmail.com


Yingzhen Qu
Futurewei Technologies
Email: yingzhen.ietf@gmail.com


Rick Taylor
Aalyria Technologies
Email: rtaylor@aalyria.com


Li Zhang
Huawei
Email: zhangli344@huawei.com
📦 where this page comes from