diff options
Diffstat (limited to 'doc/rfc/rfc9657.txt')
| -rw-r--r-- | doc/rfc/rfc9657.txt | 789 |
1 files changed, 789 insertions, 0 deletions
diff --git a/doc/rfc/rfc9657.txt b/doc/rfc/rfc9657.txt new file mode 100644 index 0000000..8ff2f16 --- /dev/null +++ b/doc/rfc/rfc9657.txt @@ -0,0 +1,789 @@ + + + + +Internet Engineering Task Force (IETF) E. Birrane, III +Request for Comments: 9657 JHU/APL +Category: Informational N. Kuhn +ISSN: 2070-1721 Thales Alenia Space + Y. Qu + Futurewei Technologies + R. Taylor + Aalyria Technologies + L. Zhang + Huawei + October 2024 + + + Time-Variant Routing (TVR) Use Cases + +Abstract + + This document introduces use cases where Time-Variant Routing (TVR) + computations (i.e., routing computations that take into consideration + time-based or scheduled changes to a network) could improve routing + protocol convergence and/or network performance. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9657. + +Copyright Notice + + Copyright (c) 2024 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +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 + + There is a growing number of use cases where changes to the routing + topology are an expected part of network operations. In these use + cases, the pre-planned loss and restoration of an adjacency, or + formation of an alternate adjacency, should be seen as a + nondisruptive event. + + 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. + + This document defines three categories of use cases where a route + computation might beneficially consider time information. Each of + these use cases are included as follows: + + 1. An overview of the use case describing how route computations + might select different paths (or subpaths) as a function of time. + + 2. A set of assumptions made by the use case as to the nature of the + network and data exchange. + + 3. Specific discussion on the routing impacts of the use case. + + 4. Example networks conformant to the use case. + + The use cases that are considered in this document are as follows: + + 1. Resource Preservation (described in Section 2), where there is + information about link availability over time at the client + level. Time-Variant Routing (TVR) can utilize the predictability + of the link availability to optimize network connectivity by + taking into account endpoint resource preservation. + + 2. Operating Efficiency (described in Section 3), where there is a + server cost or a path cost usage varying over time. TVR 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 a constant. + + 3. Dynamic Reachability (described in Section 4), where there is + information about link availability variation between nodes in + the end-to-end path. TVR can exploit the predictability of the + link availability to optimize in-network routing. + + The document does not intend to represent the full set of cases where + TVR 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 use case and not to present any exhaustive + enumeration of potential examples. It is likely that multiple + example networks exist that could be claimed as instances of any + given use case. + + The document focuses on deterministic scenarios. Non-deterministic + scenarios, such as vehicle-to-vehicle communication, are out of the + scope of the document. + +2. Resource Preservation + + Some nodes in a network might operate in resource-constrained + environments or otherwise with limited internal resources. + Constraints, such as available power, thermal ranges, and on-board + storage, 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. + + When power on a node is running low, noncritical 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. When local storage resources run low, a node might + choose to expend power resources to compress, 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. + + In addition to power, thermal, and storage, other resource + constraints may exist on a node such that the preservation of + resources is 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. + +2.1. Assumptions + + 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 + use case: + + 1. 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 future usage. + + 2. 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 fully charged. + + 3. 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 link planning. + +2.2. Routing Impacts + + 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. + + 1. 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-intensive task. + + 2. Thermal Savings. On-board radios may be turned off if there are + thermal considerations on the node, such as an increase in a + node's operating temperature. + + 3. 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 new data. + + 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 the node's functional neighborhood. + During these times, forwarding to and from the node might be delayed + pending some synchronization. + +2.3. Example + + 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. + + Consider a simple three-node network where each node accumulates + power through solar panels. Power available for radio frequency (RF) + transmission is shown in Figure 1. In this figure, each of the three + nodes (Node 1, Node 2, and Node 3) has 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. + + 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 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 Figure 2. This figure shows a sample of network + connectivity at three 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 is expected that Node 1 has its radio off but that + Node 2 and Node 3 can communicate. + + * Finally, at time t3, it is expected that Node 1 may be turning its + radio off, that Node 2 and Node 3 are not powering their radios, + and there is 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 alter their networking behavior to + optimize metrics associated with the cost of a node's operation. + While the resource preservation use case described in Section 2 + 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. + + When a node operates using some preexisting infrastructure, there is + typically some cost associated with the use of that infrastructure. + Sample costs are included as follows: + + 1. Nodes that use existing wireless communications, such as a + cellular infrastructure, must 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 increase the + temperature of the node and incur additional costs associated + with cooling the node (or collection of nodes). + + 4. 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. + + 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. + +3.1. Assumptions + + 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 as follows: + + 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 are known. + + 2. 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. + + 3. 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 too rapidly, it is likely not possible to meaningfully + react to their change. + + 4. 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. + +3.2. Routing Impacts + + Optimizing resource utilization can affect route computation in ways + similar to those experienced with resource preservation. The route + computation may not change the available path, but the topology as + seen by an endpoint would be different. Cost optimization can impact + route calculation in a variety of ways, some of which are described + as follows: + + 1. 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 a too 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). + + 2. 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. + + 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 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. + + 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. + +3.3. Example: Cellular Network + + One example of a network where nodes might seek to optimize operating + cost is a set of nodes operating over cellular connections that + charge both peak and off-peak data rates. In this case, individual + nodes may be allocated a fixed set of "peak" minutes such that + exceeding that amount of time results in expensive overage charges. + Generally, the concept of peak and off-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). + + 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 + prioritize off-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 sending noncritical events and logs. + These activities are usually already scheduled to minimize impact on + businesses and customers but can also be scheduled to minimize + overall cost. + + Consider a simple three-node network, similar to the one pictured in + Figure 1, except that in this case the resource that varies over time + is the cost of the data exchange. This case is illustrated below in + Figure 3. In this figure, a series of three plots are given, one for + each of the three nodes (Node 1, Node 2, and Node 3). Each of these + nodes exists in a different cellular service area that has different + peak and off-peak data rate times. This is shown in each figure by + times when the cost is low (off-peak) and when the cost is high + (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 + + 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 Figure 4. + From this figure, both times t1 and t3 result in a smaller cost of + data exchange than choosing to communicate data 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 + + 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 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 example related to operating efficiency is often referred to + as a "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. + + 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. + + More information on tidal networks can be found in [TIDAL]. + +4. Dynamic Reachability + + 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. + + Mobility can cause the loss of an adjacent link in several ways, such + as that which follows: + + 1. 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. + + 2. 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. + + 3. Node mobility can cause the distance between two nodes to vary + quickly over time, making it complicated to establish and + maintain connectivity. + + 4. 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. + + 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. 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. + +4.1. Assumptions + + 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: + + 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 elements of their environment (such as + a storm, a tunnel, or the 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. + +4.2. Routing Impacts + + 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 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. Determining that an adjacency has expired allows a + route computation to plan for that loss rather than default to 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 resume. + + 3. Data Rate Adjustments. The achievable data rate over a given + link is not constant over 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 data rates, which may impact path computation. + + 4. 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. + +4.3. Example: Mobile Satellites + + A relatively new type of mobile network that has emerged over the + past several years is the Low Earth Orbit (LEO) networked + constellation. There are a number of such constellations being built + by both private industry and governments. While this example + describes LEO satellite systems, the mobility events can be applied + to satellite systems orbiting at different altitudes (including Very + LEO (V-LEO) or Medium Earth Orbit (MEO)). + + Many LEO networked constellations have a similar operational concept + of hundreds 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 in 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. + + A LEO networked constellation 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 TVR computations. However, inter-satellite link + failures could still introduce unpredictability in the network + topology. + + Consider three spacecraft (N1, N2, and N3) following each other + sequentially in the same orbit. This is sometimes called a "string + of pearls" configuration. Spacecraft N2 always maintains + connectivity to its two neighbor spacecraft: N1, which is behind in + the orbit, and N3, which is ahead in the orbit. This configuration + is illustrated in Figure 6. While these spacecraft are all mobile, + their relative mobility ensures continuous contact with each other + under normal conditions. + + .--. .--. .--. + ####-| N1 |-#### <---> ####-| N2 |-#### <---> ####-| N3 |-#### + \__/ \__/ \__/ + + Figure 6: Three Sequential Spacecraft + + 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 Figure 7. 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. + + 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, resulting in a change to the network + topology. This topology change is shown in Figure 8. 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. + + +------+ +------+ + 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 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 [SAT-CONSTELLATION] and [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 [SAT-CONSTELLATION]. + +4.4. Another Example: Predictable Moving Vessels + + Another relevant example for this use case involves 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, capitalizing on their + predictable journeys. + + 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. + +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 anticipated to be + addressed elsewhere, such as within a TVR schedule definition or + through a protocol extension utilizing a TVR schedule. However, 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. + +6. IANA Considerations + + This document has no IANA actions. + +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. + +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 |