rfc9657.original | rfc9657.txt | |||
---|---|---|---|---|
Network Working Group E. Birrane | Internet Engineering Task Force (IETF) E. Birrane, III | |||
Internet-Draft JHU/APL | Request for Comments: 9657 JHU/APL | |||
Intended status: Informational N. Kuhn | Category: Informational N. Kuhn | |||
Expires: 2 September 2024 Thales Alenia Space | ISSN: 2070-1721 Thales Alenia Space | |||
Y. Qu | Y. Qu | |||
Futurewei Technologies | Futurewei Technologies | |||
R. Taylor | R. Taylor | |||
Ori Industries | Aalyria Technologies | |||
L. zhang | L. Zhang | |||
Huawei | Huawei | |||
1 March 2024 | October 2024 | |||
TVR (Time-Variant Routing) Use Cases | Time-Variant Routing (TVR) Use Cases | |||
draft-ietf-tvr-use-cases-09 | ||||
Abstract | Abstract | |||
This document introduces use cases where Time-Variant Routing (TVR) | This document introduces use cases where Time-Variant Routing (TVR) | |||
computations (i.e. routing computations taking into considerations | computations (i.e., routing computations that take into consideration | |||
time-based or scheduled changes to a network) could improve routing | time-based or scheduled changes to a network) could improve routing | |||
protocol convergence and/or network performance. | protocol convergence and/or network performance. | |||
About This Document | ||||
This note is to be removed before publishing as an RFC. | ||||
Status information for this document may be found at | ||||
https://datatracker.ietf.org/doc/draft-ietf-tvr-use-cases/. | ||||
Discussion of this document takes place on the Time Variant Routing | ||||
Working Group mailing list (mailto:tvr@ietf.org), which is archived | ||||
at https://mailarchive.ietf.org/arch/browse/tvr/. Subscribe at | ||||
https://www.ietf.org/mailman/listinfo/tvr/. | ||||
Source for this draft and an issue tracker can be found at | ||||
https://github.com/NasaDtn/tvr-bof-use-cases. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This document is not an Internet Standards Track specification; it is | |||
provisions of BCP 78 and BCP 79. | published for informational purposes. | |||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | 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. | ||||
This Internet-Draft will expire on 2 September 2024. | 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 Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
extracted from this document must include Revised BSD License text as | to this document. Code Components extracted from this document must | |||
described in Section 4.e of the Trust Legal Provisions and are | include Revised BSD License text as described in Section 4.e of the | |||
provided without warranty as described in the Revised BSD License. | Trust Legal Provisions and are provided without warranty as described | |||
in the Revised BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction | |||
2. Resource Preservation . . . . . . . . . . . . . . . . . . . . 4 | 2. Resource Preservation | |||
2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.1. Assumptions | |||
2.2. Routing Impacts . . . . . . . . . . . . . . . . . . . . . 5 | 2.2. Routing Impacts | |||
2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.3. Example | |||
3. Operating Efficiency . . . . . . . . . . . . . . . . . . . . 7 | 3. Operating Efficiency | |||
3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.1. Assumptions | |||
3.2. Routing Impacts . . . . . . . . . . . . . . . . . . . . . 8 | 3.2. Routing Impacts | |||
3.3. Example : Cellular Network . . . . . . . . . . . . . . . 9 | 3.3. Example: Cellular Network | |||
3.4. Another Example : Tidal Network . . . . . . . . . . . . . 11 | 3.4. Another Example: Tidal Network | |||
4. Dynamic Reachability . . . . . . . . . . . . . . . . . . . . 11 | 4. Dynamic Reachability | |||
4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 12 | 4.1. Assumptions | |||
4.2. Routing Impacts . . . . . . . . . . . . . . . . . . . . . 13 | 4.2. Routing Impacts | |||
4.3. Example : Mobile Satellites . . . . . . . . . . . . . . . 13 | 4.3. Example: Mobile Satellites | |||
4.4. Another Example : Predictable Moving Vessels . . . . . . 17 | 4.4. Another Example: Predictable Moving Vessels | |||
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 | 5. Security Considerations | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 6. IANA Considerations | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | 7. Informative References | |||
8. Informative References . . . . . . . . . . . . . . . . . . . 17 | Acknowledgments | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
There is a growing number of use cases where changes to the routing | There is a growing number of use cases where changes to the routing | |||
topology are an expected part of network operations. In these use | topology are an expected part of network operations. In these use | |||
cases the pre-planned loss and restoration of an adjacency, or | cases, the pre-planned loss and restoration of an adjacency, or | |||
formation of an alternate adjacency, should be seen as a non- | formation of an alternate adjacency, should be seen as a | |||
disruptive event. | nondisruptive event. | |||
Expected changes to topologies can occur for a variety of reasons. | Expected changes to topologies can occur for a variety of reasons. | |||
In networks with mobile nodes, such as unmanned aerial vehicles and | In networks with mobile nodes, such as unmanned aerial vehicles and | |||
some orbiting spacecraft constellations, links are lost and re- | some orbiting spacecraft constellations, links are lost and re- | |||
established as a function of the mobility of the platforms. In | established as a function of the mobility of the platforms. In | |||
networks without reliable access to power, such as networks | networks without reliable access to power, such as networks | |||
harvesting energy from wind and solar, link activity might be | harvesting energy from wind and solar, link activity might be | |||
restricted to certain times of day. Similarly, in networks | restricted to certain times of day. Similarly, in networks | |||
prioritizing green computing and energy efficiency over data rate, | prioritizing green computing and energy efficiency over data rate, | |||
network traffic might be planned around energy costs or expected user | network traffic might be planned around energy costs or expected user | |||
data volumes. | data volumes. | |||
This document defines three categories of use cases where a route | This document defines three categories of use cases where a route | |||
computation might beneficially consider time information. Each of | computation might beneficially consider time information. Each of | |||
these use cases includes the following information. | these use cases are included as follows: | |||
1. An overview of the use case describing how route computations | 1. An overview of the use case describing how route computations | |||
might select different paths (or subpaths) as a function of time. | 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 | 2. A set of assumptions made by the use case as to the nature of the | |||
network and data exchange. | network and data exchange. | |||
3. Specific discussion on the routing impacts of the use case. | 3. Specific discussion on the routing impacts of the use case. | |||
4. Example networks conformant to the use case. | 4. Example networks conformant to the use case. | |||
The use cases that are considered in this document are the following. | The use cases that are considered in this document are as follows: | |||
1. Resource Preservation (described in Section 2), where there is | 1. Resource Preservation (described in Section 2), where there is | |||
information about link availability over time at the client | information about link availability over time at the client | |||
level. Time Variant Routing can utilize the predictability of | level. Time-Variant Routing (TVR) can utilize the predictability | |||
the link availability to optimize network connectivity by taking | of the link availability to optimize network connectivity by | |||
into account end point resource preservation. | taking into account endpoint resource preservation. | |||
2. Operating Efficiency (described in Section 3), where there is a | 2. Operating Efficiency (described in Section 3), where there is a | |||
server cost or a path cost usage varying over time. Time Variant | server cost or a path cost usage varying over time. TVR can | |||
Routing can exploit the predictability of the path cost to | exploit the predictability of the path cost to optimize the cost | |||
optimize the cost of the system exploitation. The notion of a | of the system exploitation. The notion of a path cost is | |||
path cost is extended to be a time-dependent function instead of | extended to be a time-dependent function instead of a constant. | |||
a constant. | ||||
3. Dynamic Reachability (described in Section 4), where there is | 3. Dynamic Reachability (described in Section 4), where there is | |||
information about link availability variation between nodes | information about link availability variation between nodes in | |||
taking part of the end-to-end path. Time Variant Routing can | the end-to-end path. TVR can exploit the predictability of the | |||
exploit the predictability of the link availability to optimize | link availability to optimize in-network routing. | |||
in-network routing. | ||||
The document does not intend to represent the full set of cases where | The document does not intend to represent the full set of cases where | |||
time-variant routing computations could beneficially impact network | TVR computations could beneficially impact network performance -- new | |||
performance - new use cases are expected to be generated over time. | use cases are expected to be generated over time. Similarly, the | |||
Similarly, the concrete examples within each use case are meant to | concrete examples within each use case are meant to provide an | |||
provide an existence proof of the use case, not to present any | existence proof of the use case and not to present any exhaustive | |||
exhaustive enumeration of potential examples. It is likely that | enumeration of potential examples. It is likely that multiple | |||
there exist multiple example networks that could be claimed as | example networks exist that could be claimed as instances of any | |||
instances of any given use case. | given use case. | |||
The document focuses on deterministic scenarios. Non-deterministic | The document focuses on deterministic scenarios. Non-deterministic | |||
scenarios such as vehicle-to-vehicle communication is out of the | scenarios, such as vehicle-to-vehicle communication, are out of the | |||
scope of the document. | scope of the document. | |||
2. Resource Preservation | 2. Resource Preservation | |||
Some nodes in a network might operate in resource-constrained | Some nodes in a network might operate in resource-constrained | |||
environments or otherwise with limited internal resources. | environments or otherwise with limited internal resources. | |||
Constraints such as available power, thermal ranges, and on-board | Constraints, such as available power, thermal ranges, and on-board | |||
storage can all impact the instantaneous operation of a node. In | storage, can all impact the instantaneous operation of a node. In | |||
particular, resource management on such a node can require that | particular, resource management on such a node can require that | |||
certain functionality be powered on (or off) to extend the ability of | certain functionality be powered on (or off) to extend the ability of | |||
the node to participate in the network. | the node to participate in the network. | |||
When power on a node is running low, non-critical functions on the | When power on a node is running low, noncritical functions on the | |||
node might be turned off in favor of extending node life. | node might be turned off in favor of extending node life. | |||
Alternatively, certain functions on a node may be turned off to allow | 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 | 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 | collection. When a node is in danger of violating a thermal | |||
constraint, normal processing might be paused in favor of a | constraint, normal processing might be paused in favor of a | |||
transition to a thermal safe mode until a regular operating condition | transition to a thermal safe mode until a regular operating condition | |||
is reestablished. When local storage resources run low, a node might | is reestablished. When local storage resources run low, a node might | |||
choose to expend power resources to fuse, delete, or transmit data | choose to expend power resources to compress, delete, or transmit | |||
off the node to free space for future data collection. There might | data off the node to free up space for future data collection. There | |||
also be cases where a node experiences a planned offline state to | might also be cases where a node experiences a planned offline state | |||
save and accumulate power. | to save and accumulate power. | |||
In addition to power, thermal, and storage, other resource | In addition to power, thermal, and storage, other resource | |||
constraints may exist on a node such that the preservation of | constraints may exist on a node such that the preservation of | |||
resources are necessary to preserve the existence (and proper | resources is necessary to preserve the existence (and proper | |||
function) of the node in the network. Nodes operating in these | function) of the node in the network. Nodes operating in these | |||
conditions might benefit from TVR computations as the connectivity of | conditions might benefit from TVR computations as the connectivity of | |||
the node changes over time as part of node preservation. | the node changes over time as part of node preservation. | |||
2.1. Assumptions | 2.1. Assumptions | |||
To effectively manage on-board functionality based on available | To effectively manage on-board functionality based on available | |||
resources, a node must comprehend specific aspects concerning the | resources, a node must comprehend specific aspects concerning the | |||
utilization and replenishment of resources. It is expected that | utilization and replenishment of resources. It is expected that | |||
patterns of the environment, device construction, and operational | patterns of the environment, device construction, and operational | |||
configuration exist with enough regularity and stability to allow | configuration exist with enough regularity and stability to allow | |||
meaningful planning. The following assumptions are made with this | meaningful planning. The following assumptions are made with this | |||
use case. | use case: | |||
1. Known resource expenditures. It is assumed that there exists | 1. Known resource expenditures. It is assumed that there exists | |||
some determinable relationship between the resources available on | some determinable relationship between the resources available on | |||
a node and the resources needed to participate in a network. A | a node and the resources needed to participate in a network. A | |||
node would need to understand when it has met some condition for | node would need to understand when it has met some condition for | |||
participating in, or dropping out of, a network. This is | participating in, or dropping out of, a network. This is | |||
somewhat similar to predicting the amount of battery life left on | somewhat similar to predicting the amount of battery life left on | |||
a laptop as a function of likely future usage. | a laptop as a function of likely future usage. | |||
2. Predictable resource accumulation. It is assumed that the | 2. Predictable resource accumulation. It is assumed that the | |||
skipping to change at page 5, line 47 ¶ | skipping to change at line 214 ¶ | |||
elements of the node as part of on-board resource management. These | elements of the node as part of on-board resource management. These | |||
activities can affect data routing in a variety of ways. | activities can affect data routing in a variety of ways. | |||
1. Power Savings. On-board radios may be turned off to allow other | 1. Power Savings. On-board radios may be turned off to allow other | |||
node processing. This may happen on power-constrained devices to | node processing. This may happen on power-constrained devices to | |||
extend the battery life of the node or to allow a node to perform | extend the battery life of the node or to allow a node to perform | |||
some other power-intensive task. | some other power-intensive task. | |||
2. Thermal Savings. On-board radios may be turned off if there are | 2. Thermal Savings. On-board radios may be turned off if there are | |||
thermal considerations on the node, such as an increase in a | thermal considerations on the node, such as an increase in a | |||
node’s operating temperature. | node's operating temperature. | |||
3. Storage Savings. On-board radios may be turned on with the | 3. Storage Savings. On-board radios may be turned on with the | |||
purpose of transmitting data off the node to free local storage | purpose of transmitting data off the node to free local storage | |||
space to collect new data. | space to collect new data. | |||
Whenever a communications device on a node changes its powered state | Whenever a communications device on a node changes its powered state | |||
there is the possibility (if the node is within range of other nodes | 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 | in a network) that the topology of the network is changed, which | |||
impacts route calculations through the network. Additionally, | impacts route calculations through the network. Additionally, | |||
whenever a node joins a network there may be a delay between the | 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 | joining of the node to the network and any discovery that may take | |||
place relating to the status of the node’s functional neighborhood. | place relating to the status of the node's functional neighborhood. | |||
During these times, forwarding to and from the node might be delayed | During these times, forwarding to and from the node might be delayed | |||
pending some synchronization. | pending some synchronization. | |||
2.3. Example | 2.3. Example | |||
An illustrative example of a network necessitating resource | An illustrative example of a network necessitating resource | |||
preservation is an energy-harvesting wireless sensor network. In | preservation is an energy-harvesting wireless sensor network. In | |||
such a network, nodes rely exclusively on environmental sources for | such a network, nodes rely exclusively on environmental sources for | |||
power, such as solar panels. On-board power levels may fluctuate | power, such as solar panels. On-board power levels may fluctuate | |||
based on various factors including sensor activity, processing | based on various factors including sensor activity, processing | |||
demands, and the node's position and orientation relative to its | demands, and the node's position and orientation relative to its | |||
energy source. | energy source. | |||
Consider a simple three node network where each node accumulates | Consider a simple three-node network where each node accumulates | |||
power through solar panels. Power available for Radio Frequency (RF) | power through solar panels. Power available for radio frequency (RF) | |||
transmission is shown below in Figure 1. In this figure, each of the | transmission is shown in Figure 1. In this figure, each of the three | |||
three nodes (Node 1, Node 2, and Node 3) have a different plot of | nodes (Node 1, Node 2, and Node 3) has a different plot of available | |||
available power over time. This example assumes that a node will not | power over time. This example assumes that a node will not power its | |||
power its radio until available power is over some threshold, which | radio until available power is over some threshold, which is shown by | |||
is shown by the horizontal line on each plot. | the horizontal line on each plot. | |||
Node 1 Node 2 Node 3 | Node 1 Node 2 Node 3 | |||
P | P | ------- P | -- | P | P | ------- P | -- | |||
o | ---- -- o | / \ o | / \ | o | ---- -- o | / \ o | / \ | |||
w |~/~~~~\~~~~~/~~\~~ w |~/~~~~~~~~~\~~~~~~ w |~~~~~~~~/~~~~\~~~~ | w |~/~~~~\~~~~~/~~\~~ w |~/~~~~~~~~~\~~~~~~ w |~~~~~~~~/~~~~\~~~~ | |||
e |/ \ / \ e |/ \ e | / \ | e |/ \ / \ e |/ \ e | / \ | |||
r | --- - r | ----- r |------- --- | r | --- - r | ----- r |------- --- | |||
+---++----++----++- +---++----++----++- +---++----++----++- | +---++----++----++- +---++----++----++- +---++----++----++- | |||
t1 t2 t3 t1 t2 t3 t1 t2 t3 | t1 t2 t3 t1 t2 t3 t1 t2 t3 | |||
Time Time Time | Time Time Time | |||
Figure 1: Node Power Over Time | Figure 1: Node Power over Time | |||
The connectivity of this three node network changes over time in ways | The connectivity of this three-node network changes over time in ways | |||
that may be predictable and are likely able to be communicated to | that may be predictable and are likely able to be communicated to | |||
other nodes in this small sensor network. Examples of connectivity | other nodes in this small sensor network. Examples of connectivity | |||
are shown in Figure 2. This figure shows a sample of network | are shown in Figure 2. This figure shows a sample of network | |||
connectivity at three times: t1, t2, and t3. | connectivity at three times: t1, t2, and t3. | |||
* At time t1 Node 1 and Node 2 have their radios powered on and are | * At time t1, Node 1 and Node 2 have their radios powered on and are | |||
expected to communicate. | expected to communicate. | |||
* At time t2 it is expected that Node 1 has its radio off, but that | * At time t2, it is expected that Node 1 has its radio off but that | |||
Node 2 and Node 3 can communicate. | Node 2 and Node 3 can communicate. | |||
* Finally, at time t3 it is expected that Node 1 may be turning its | * Finally, at time t3, it is expected that Node 1 may be turning its | |||
radio off and that Node 2 and Node 3 are not powering their radios | radio off, that Node 2 and Node 3 are not powering their radios, | |||
and there is no expectation of connectivity. | and there is no expectation of connectivity. | |||
+----------+ +----------+ +----------+ | +----------+ +----------+ +----------+ | |||
t1 | Node 1 |--------| Node 2 | | Node 3 | | t1 | Node 1 |--------| Node 2 | | Node 3 | | |||
+----------+ +----------+ +----------+ | +----------+ +----------+ +----------+ | |||
+----------+ +----------+ +----------+ | +----------+ +----------+ +----------+ | |||
t2 | Node 1 | | Node 2 |--------| Node 3 | | t2 | Node 1 | | Node 2 |--------| Node 3 | | |||
+----------+ +----------+ +----------+ | +----------+ +----------+ +----------+ | |||
skipping to change at page 7, line 35 ¶ | skipping to change at line 299 ¶ | |||
3. Operating Efficiency | 3. Operating Efficiency | |||
Some nodes in a network might alter their networking behavior to | Some nodes in a network might alter their networking behavior to | |||
optimize metrics associated with the cost of a node's operation. | optimize metrics associated with the cost of a node's operation. | |||
While the resource preservation use case described in Section 2 | While the resource preservation use case described in Section 2 | |||
addresses node survival, this use case discusses non-survival | addresses node survival, this use case discusses non-survival | |||
efficiencies such as the financial cost to operate the node and the | efficiencies such as the financial cost to operate the node and the | |||
environmental impact (cost) of using that node. | environmental impact (cost) of using that node. | |||
When a node operates using some pre-existing infrastructure there is | When a node operates using some preexisting infrastructure, there is | |||
typically some cost associated with the use of that infrastructure. | typically some cost associated with the use of that infrastructure. | |||
Sample costs include the following. | Sample costs are included as follows: | |||
1. Nodes that use existing wireless communications such as a | 1. Nodes that use existing wireless communications, such as a | |||
cellular infrastructure must pay to communicate to and through | cellular infrastructure, must pay to communicate to and through | |||
that infrastructure. | that infrastructure. | |||
2. Nodes supplied with electricity from an energy provider pay for | 2. Nodes supplied with electricity from an energy provider pay for | |||
the power they use. | the power they use. | |||
3. Nodes that cluster computation and activities might increase the | 3. Nodes that cluster computation and activities might increase the | |||
temperature of the node and incur additional costs associated | temperature of the node and incur additional costs associated | |||
with cooling the node (or collection of nodes). | with cooling the node (or collection of nodes). | |||
4. Beyond financial costs, assessing the environmental impact of | 4. Beyond financial costs, assessing the environmental impact of | |||
skipping to change at page 8, line 20 ¶ | skipping to change at line 329 ¶ | |||
When the cost of using a node's resources changes over time, a node | When the cost of using a node's resources changes over time, a node | |||
can benefit from predicting when data transmissions might optimize | can benefit from predicting when data transmissions might optimize | |||
costs, environmental impacts, or other metrics associated with | costs, environmental impacts, or other metrics associated with | |||
operation. | operation. | |||
3.1. Assumptions | 3.1. Assumptions | |||
The ability to predict the impact of a node's resource utilization | The ability to predict the impact of a node's resource utilization | |||
over time presumes that the node exists within a defined environment | over time presumes that the node exists within a defined environment | |||
(or infrastructure). Some characteristics of these environments are | (or infrastructure). Some characteristics of these environments are | |||
listed as follows. | listed as follows: | |||
1. Cost Measureability. The impacts of operating a node within its | 1. Cost Measurability. The impacts of operating a node within its | |||
environment can be measured in a deterministic way. For example, | environment can be measured in a deterministic way. For example, | |||
that the cost-per-bit of data over a cellular network or the | the cost-per-bit of data over a cellular network or the cost-per- | |||
cost-per-kilowatt of energy used are known. | kilowatt of energy used are known. | |||
2. Cost Predictability. Changes to the impacts of resource | 2. Cost Predictability. Changes to the impacts of resource | |||
utilization are known in advance. For example, if the cost of | utilization are known in advance. For example, if the cost of | |||
energy is less expensive in the evening than during the day, | energy is less expensive in the evening than during the day, | |||
there exists some way of communicating this change to a node. | there exists some way of communicating this change to a node. | |||
3. Cost Persistent. Changes to the cost of operating in the | 3. Cost Persistent. Changes to the cost of operating in the | |||
environment persist for a sufficient amount of time such that | environment persist for a sufficient amount of time such that | |||
behavior can be adjusted in response to changing costs. If costs | behavior can be adjusted in response to changing costs. If costs | |||
change too rapidly it is likely not possible to meaningfully | change too rapidly, it is likely not possible to meaningfully | |||
react to their change. | react to their change. | |||
4. Cost Magnitude. The magnitude of cost changes is such that a | 4. Cost Magnitude. The magnitude of cost changes is such that a | |||
node experiences a minimum threshold cost reduction through | node experiences a minimum threshold cost reduction through | |||
optimization. A specified time period is designated for | optimization. A specified time period is designated for | |||
measuring the cost reduction. | measuring the cost reduction. | |||
3.2. Routing Impacts | 3.2. Routing Impacts | |||
Optimizing resource utilization can affect route computation in ways | Optimizing resource utilization can affect route computation in ways | |||
similar to those experienced with resource preservation. The route | similar to those experienced with resource preservation. The route | |||
computation may not change the available path but the topology as | computation may not change the available path, but the topology as | |||
seen by an end point would be different. Cost optimization can | seen by an endpoint would be different. Cost optimization can impact | |||
impact route calculation in a variety of ways, some of which are | route calculation in a variety of ways, some of which are described | |||
described as follows. | as follows: | |||
1. Link Filtering. Data might be accumulated on a node waiting for | 1. Link Filtering. Data might be accumulated on a node waiting for | |||
a cost-effective time for data transmission. Individual link | a cost-effective time for data transmission. Individual link | |||
costs might be annotated with cost information such that | costs might be annotated with cost information such that | |||
adjacencies with a too-high cost might not be used for | adjacencies with a too high cost might not be used for | |||
forwarding. This effectively filters which adjacencies are used | forwarding. This effectively filters which adjacencies are used | |||
(possibly as a function of the type of data being routed). | (possibly as a function of the type of data being routed). | |||
2. Burst Planning. In cases where there is a cost savings | 2. Burst Planning. In cases where there is a cost savings | |||
associated with fewer longer transmissions (versus many smaller | associated with fewer longer transmissions (versus many smaller | |||
transmissions), nodes might refuse to forward data until a | transmissions), nodes might refuse to forward data until a | |||
sufficient data volume exists to justify a transmission. | sufficient data volume exists to justify a transmission. | |||
3. Environmental Measurement. Nodes that measure the quality of | 3. Environmental Measurement. Nodes that measure the quality of | |||
individual links can compute the overall cost of using a link as | individual links can compute the overall cost of using a link as | |||
a function of the signal strength of the link. If link quality | a function of the signal strength of the link. If link quality | |||
is insufficient due to environmental conditions (such as clouds | is insufficient due to environmental conditions (such as clouds | |||
on a free-space optical link or long distance RF transmission in | on a free-space optical link or long distance RF transmission in | |||
a storm) the cost required to communicate over the link may be | a storm) the cost required to communicate over the link may be | |||
too much, even if access to infrastructure is otherwise in a less | too much, even if access to infrastructure is otherwise in a less | |||
expensive time of day. | expensive time of day. | |||
In each of these cases, some consideration of the efficiency of | In each of these cases, some consideration of the efficiency of | |||
transmission is prioritized over achieving a particular data rate. | transmission is prioritized over achieving a particular data rate. | |||
Waiting until data rate costs are lower takes advantage of platforms | 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 | using time-of-use rate plans -- both for pay-as-you-go data and | |||
associated energy costs. Accumulating data volumes and choosing more | associated energy costs. Accumulating data volumes and choosing more | |||
opportune times to transmit can also result in less energy | opportune times to transmit can also result in less energy | |||
consumption by radios and, thus, less operating cost for platforms. | consumption by radios and, thus, less operating cost for platforms. | |||
3.3. Example : Cellular Network | 3.3. Example: Cellular Network | |||
One example of a network where nodes might seek to optimize operating | One example of a network where nodes might seek to optimize operating | |||
cost is a set of nodes operating over cellular connections that | cost is a set of nodes operating over cellular connections that | |||
charge both On-Peak and Off-Peak data rates. In this case, | charge both peak and off-peak data rates. In this case, individual | |||
individual nodes may be allocated a fixed set of "On-Peak" minutes | nodes may be allocated a fixed set of "peak" minutes such that | |||
such that exceeding that amount of time results in expensive overage | exceeding that amount of time results in expensive overage charges. | |||
charges. Generally, the concept of On-Peak and Off-Peak minutes | Generally, the concept of peak and off-peak minutes exists to deter | |||
exists to deter the use of a given network at times when the cellular | the use of a given network at times when the cellular network is | |||
network is likely to encounter heavy call volumes (such as during the | likely to encounter heavy call volumes (such as during the workday). | |||
workday). | ||||
Just as pricing information can act as a deterrent (or incentive) for | Just as pricing information can act as a deterrent (or incentive) for | |||
a human cellular user, this pricing information can be codified in | a human cellular user, this pricing information can be codified in | |||
ways that also allow machine-to-machine (M2M) connections to | ways that also allow machine-to-machine (M2M) connections to | |||
prioritize Off-Peak communications for certain types of data | prioritize off-peak communications for certain types of data | |||
exchange. Many M2M traffic exchanges involve schedulable activities, | exchange. Many M2M traffic exchanges involve schedulable activities, | |||
such as nightly bulk file transfers, pushing software updates, | such as nightly bulk file transfers, pushing software updates, | |||
synchronizing datastores, and sending non-critical events and logs. | synchronizing datastores, and sending noncritical events and logs. | |||
These activities are usually already scheduled to minimize impact on | These activities are usually already scheduled to minimize impact on | |||
businesses and customers, but can also be scheduled to minimize | businesses and customers but can also be scheduled to minimize | |||
overall cost. | overall cost. | |||
Consider a simple three node network, similar to the one pictured in | 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 | 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 | 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 | Figure 3. In this figure, a series of three plots are given, one for | |||
each of nodes Node 1, Node 2, and Node 3. Each of these nodes exists | each of the three nodes (Node 1, Node 2, and Node 3). Each of these | |||
in a different cellular service area which has different On-Peak and | nodes exists in a different cellular service area that has different | |||
Off-Peak data rate times. This is shown in each figure by times when | peak and off-peak data rate times. This is shown in each figure by | |||
the cost is low (Off-Peak) and when the cost is high (On-Peak). | times when the cost is low (off-peak) and when the cost is high | |||
(peak). | ||||
Node 1 Node 2 Node 3 | Node 1 Node 2 Node 3 | |||
C | +--------- C |--+ C |-------------+ | C | +--------- C |--+ C |-------------+ | |||
o | | o | | o | | | o | | o | | o | | | |||
s | | s | | s | | | s | | s | | s | | | |||
t |-------+ t | +---------------- t | +------- | t |-------+ t | +---------------- t | +------- | |||
| | | | | | | | |||
+---++----++----++-- +----++----++----++-- +----++----++-----++-- | +---++----++----++-- +----++----++----++-- +----++----++-----++-- | |||
t1 t2 t3 t1 t2 t3 t1 t2 t3 | t1 t2 t3 t1 t2 t3 t1 t2 t3 | |||
Time Time Time | Time Time Time | |||
Figure 3: Data Cost Over Time | Figure 3: Data Cost over Time | |||
Given the presumption that peak times are known in advance, the cost | 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 | 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. | 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 | From this figure, both times t1 and t3 result in a smaller cost of | |||
data exchange than choosing to communicate data at time t2. | data exchange than choosing to communicate data at time t2. | |||
+-----------+ +-----------+ +-----------+ | +-----------+ +-----------+ +-----------+ | |||
t1 | Node N1 |---LOW----| Node N2 |---HIGH---| Node N3 | | t1 | Node N1 |---LOW----| Node N2 |---HIGH---| Node N3 | | |||
+-----------+ +-----------+ +-----------+ | +-----------+ +-----------+ +-----------+ | |||
skipping to change at page 11, line 17 ¶ | skipping to change at line 467 ¶ | |||
queue data at Node 2 until time t3 for delivery to Node 3. This case | queue data at Node 2 until time t3 for delivery to Node 3. This case | |||
is shown in Figure 5. | is shown in Figure 5. | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
t1 | Node N1 |---LOW----| Node N2 | | t1 | Node N1 |---LOW----| Node N2 | | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
t3 | Node N2 |----LOW---| Node N3 | | t3 | Node N2 |----LOW---| Node N3 | | |||
+-----------+ +-----------+ | +-----------+ +-----------+ | |||
Figure 5: Data Cost using Storage | Figure 5: Data Cost Using Storage | |||
3.4. Another Example : Tidal Network | 3.4. Another Example: Tidal Network | |||
Another example related to operating efficiency is what is often | Another example related to operating efficiency is often referred to | |||
referred to as a 'tidal network,' in which traffic volume undergoes | as a "tidal network," in which traffic volume undergoes significant | |||
significant fluctuations at different times. Take, for instance, a | fluctuations at different times. Take, for instance, a campus | |||
campus network, where thousands of individuals go to classrooms and | network, where thousands of individuals go to classrooms and | |||
libraries during the daytime and retire to the dormitories at night. | libraries during the daytime and retire to the dormitories at night. | |||
This results in a regular oscillation of network traffic across | This results in a regular oscillation of network traffic across | |||
various locations within the campus. | various locations within the campus. | |||
In the context of a tidal network scenario, energy-saving methods may | In the context of a tidal network scenario, energy-saving methods may | |||
include the deactivation of some or all components of network nodes. | include the deactivation of some or all components of network nodes. | |||
These activities have the potential to alter network topology and | These activities have the potential to alter network topology and | |||
impact data routing in a variety of ways. Ports on network nodes can | impact data routing in a variety of ways. Ports on network nodes can | |||
be selectively disabled or enabled based on traffic patterns, thereby | be selectively disabled or enabled based on traffic patterns, thereby | |||
reducing the energy consumption of nodes during periods of low | reducing the energy consumption of nodes during periods of low | |||
network traffic. | network traffic. | |||
More information on Tidal Network can be found in [TIDAL]. | More information on tidal networks can be found in [TIDAL]. | |||
4. Dynamic Reachability | 4. Dynamic Reachability | |||
When a node is placed on a mobile platform, the mobility of the | 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 | 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 | topology of the network over time. The impacts on the dynamics of | |||
the topology can be very important. To the extent that the relative | the topology can be very important. To the extent that the relative | |||
mobility between and among nodes in the network and the impacts of | mobility between and among nodes in the network and the impacts of | |||
the environment on the signal propagation can be predicted, the | the environment on the signal propagation can be predicted, the | |||
associated loss and establishment of adjacencies can also be planned | associated loss and establishment of adjacencies can also be planned | |||
for. | for. | |||
Mobility can cause the loss of an adjacent link in several ways, such | Mobility can cause the loss of an adjacent link in several ways, such | |||
as the following. | as that which follows: | |||
1. Node mobility can cause the distance between two nodes to become | 1. Node mobility can cause the distance between two nodes to become | |||
large enough that distance-related attenuation causes the mobile | large enough that distance-related attenuation causes the mobile | |||
node to lose connectivity with one or more other nodes in the | node to lose connectivity with one or more other nodes in the | |||
network. | network. | |||
2. Node mobility can also be used to maintain a required distance | 2. Node mobility can also be used to maintain a required distance | |||
from other mobile nodes in the network. While moving, external | from other mobile nodes in the network. While moving, external | |||
characteristics may cause the loss of links through occultation | characteristics may cause the loss of links through occultation | |||
or other hazards of traversing a shared environment. | or other hazards of traversing a shared environment. | |||
3. Node mobility can cause the distance between two nodes to vary | 3. Node mobility can cause the distance between two nodes to vary | |||
quickly over the time making it complicated to establish and | quickly over time, making it complicated to establish and | |||
maintain connectivity. | maintain connectivity. | |||
4. Nodes equipped with communication terminals capable of adjusting | 4. Nodes equipped with communication terminals capable of adjusting | |||
their orientation or moving behind and emerging from barriers | their orientation or moving behind and emerging from barriers | |||
will also establish and lose connectivity with other nodes as a | will also establish and lose connectivity with other nodes as a | |||
function of that motion. | function of that motion. | |||
Mobile nodes, like any node, may have concerns regarding resource | Mobile nodes, like any node, may encounter issues regarding resource | |||
preservation and cost efficiency. However, they also face unique | preservation and cost efficiency. In addition, they may face unique | |||
challenges associated with their mobility. The intermittent | challenges associated with their mobility. The intermittent | |||
availability of links can lead to dynamic neighbor relationships at | availability of links can lead to dynamic neighbor relationships at | |||
the node level. This use case aims to examine the routing | the node level. This use case aims to examine the routing | |||
implications of motion-induced changes to network topology. | implications of motion-induced changes to network topology. | |||
4.1. Assumptions | 4.1. Assumptions | |||
Predicting the impact of node mobility on route computation requires | Predicting the impact of node mobility on route computation requires | |||
some information relating to the nature of the mobility and the | some information relating to the nature of the mobility and the | |||
nature of the environment being moved through. Some information | nature of the environment being moved through. Some information | |||
presumed to exist for planning is listed as follows. | presumed to exist for planning is listed as follows: | |||
1. Path Predictability. The path of a mobile node through its | 1. Path Predictability. The path of a mobile node through its | |||
environment is known (or can be predicted) as a function of (at | environment is known (or can be predicted) as a function of (at | |||
least) time. It is presumed that mobile nodes using time-variant | least) time. It is presumed that mobile nodes using TVR | |||
algorithms would not exhibit purely random motion. | algorithms would not exhibit purely random motion. | |||
2. Environmental Knowledge. When otherwise well-connected mobile | 2. Environmental Knowledge. When otherwise well-connected mobile | |||
nodes pass through certain elements of their environment (such as | nodes pass through certain elements of their environment (such as | |||
a storm, a tunnel, or the horizon) they may lose connectivity. | a storm, a tunnel, or the horizon), they may lose connectivity. | |||
The duration of this connectivity loss is assumed to be | The duration of this connectivity loss is assumed to be | |||
calculable as a function of node mobility and the environment | calculable as a function of node mobility and the environment | |||
itself. | itself. | |||
4.2. Routing Impacts | 4.2. Routing Impacts | |||
Changing a network topology affects the computation of paths (or | Changing a network topology affects the computation of paths (or | |||
subpaths) through that topology. In particular, the following | subpaths) through that topology. In particular, the following | |||
features can be implemented in a network with mobile nodes such that | features can be implemented in a network with mobile nodes such that | |||
different paths might be computed over time. | different paths might be computed over time: | |||
1. Adjacent Link Expiration. A node might be able to predict that | 1. Adjacent Link Expiration. A node might be able to predict that | |||
an adjacency will expire as a function of that node's mobility, | an adjacency will expire as a function of that node's mobility, | |||
the other node's mobility, or some characteristic of the | the other node's mobility, or some characteristic of the | |||
environment. Determining that an adjacency has expired allows a | environment. Determining that an adjacency has expired allows a | |||
route computation to plan for that loss, rather than default to | route computation to plan for that loss rather than default to an | |||
an error recovery mechanism. | error recovery mechanism. | |||
2. Adjacent Link Resumption. Just as the loss of an adjacency can | 2. Adjacent Link Resumption. Just as the loss of an adjacency can | |||
be predicted, it may be possible to predict when an adjacency | be predicted, it may be possible to predict when an adjacency | |||
will resume. | will resume. | |||
3. Data Rate Adjustments. The achievable data rate over a given | 3. Data Rate Adjustments. The achievable data rate over a given | |||
link is not constant over time, and may vary significantly as a | link is not constant over time and may vary significantly as a | |||
function of both relative mobility between a transmitter and | function of both relative mobility between a transmitter and | |||
receiver as well as the environment being transmitted through. | receiver as well as the environment being transmitted through. | |||
Knowledge of both mobility and environmental state may allow for | Knowledge of both mobility and environmental state may allow for | |||
prediction of data rates which may impact path computation. | prediction of data rates, which may impact path computation. | |||
4. Adjacent Link Filtering. Separate from the instantaneous | 4. Adjacent Link Filtering. Separate from the instantaneous | |||
presence or absence of an adjacency, a route computation might | presence or absence of an adjacency, a route computation might | |||
choose to not use an adjacency if that adjacency is likely to | 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 | expire in the near future or if it is likely to experience a | |||
significant drop in predicted data rate. | significant drop in predicted data rate. | |||
4.3. Example : Mobile Satellites | 4.3. Example: Mobile Satellites | |||
A relatively new type of mobile network that has emerged over the | A relatively new type of mobile network that has emerged over the | |||
past several years is the Low Earth Orbit (LEO) networked | past several years is the Low Earth Orbit (LEO) networked | |||
constellation (LEO-NC). There are a number of such constellations | constellation. There are a number of such constellations being built | |||
being built by both private industry and governments. While this | by both private industry and governments. While this example | |||
example describes LEO satellites systems, the mobility events can be | describes LEO satellite systems, the mobility events can be applied | |||
applied to satellite systems orbiting at different altitude | to satellite systems orbiting at different altitudes (including Very | |||
(including Very LEO (V-LEO) or Medium Earth Orbit (MEO)). | LEO (V-LEO) or Medium Earth Orbit (MEO)). | |||
Many LEO-NCs have a similar operational concept of hundreds-to- | Many LEO networked constellations have a similar operational concept | |||
thousands of inexpensive spacecraft that can communicate both with | of hundreds to thousands of inexpensive spacecraft that can | |||
their orbital neighbors as well as down to any ground station that | communicate both with their orbital neighbors as well as down to any | |||
they happen to be passing over. A ground station is a facility used | ground station that they happen to be passing over. A ground station | |||
to communicate with satellites in low Earth orbit. The relationship | is a facility used to communicate with satellites in LEO. The | |||
between an individual spacecraft and an individual ground station | relationship between an individual spacecraft and an individual | |||
becomes somewhat complex as each spacecraft may only be over a single | ground station becomes somewhat complex as each spacecraft may only | |||
ground station for a few minutes at a time. Moreover, as a function | be over a single ground station for a few minutes at a time. | |||
of the constellation topology, there are scenarios where (1) the | Moreover, as a function of the constellation topology, there are | |||
inter-satellite links need to be shut down for interference avoidance | scenarios where (1) the inter-satellite links need to be shut down | |||
purposes or (2) the network topology changes, which modifies the | for interference avoidance purposes or (2) the network topology | |||
neighbors of a given spacecraft. | changes, which modifies the neighbors of a given spacecraft. | |||
A LEO-NC represents a good example of planned mobility based on the | A LEO networked constellation represents a good example of planned | |||
predictability of spacecraft in orbit. While other mobile vehicles | mobility based on the predictability of spacecraft in orbit. While | |||
may encounter unpredictable fluctuations in velocity, spacecraft | other mobile vehicles may encounter unpredictable fluctuations in | |||
operate in an environment with relatively stable velocity conditions. | velocity, spacecraft operate in an environment with relatively stable | |||
This determinism makes them an excellent candidate for time-variant | velocity conditions. This determinism makes them an excellent | |||
route computations. However, inter-satellite link failures could | candidate for TVR computations. However, inter-satellite link | |||
still introduce unpredictability in the network topology. | failures could still introduce unpredictability in the network | |||
topology. | ||||
Consider three spacecraft (N1, N2, and N3) following each other | Consider three spacecraft (N1, N2, and N3) following each other | |||
sequentially in the same orbit. This is sometimes called a string of | sequentially in the same orbit. This is sometimes called a "string | |||
pearls configuration. Spacecraft N2 always maintains connectivity to | of pearls" configuration. Spacecraft N2 always maintains | |||
its two neighbor spacecraft, N1 which is behind in the orbit and N3 | connectivity to its two neighbor spacecraft: N1, which is behind in | |||
which is ahead in the orbit. This configuration is illustrated in | the orbit, and N3, which is ahead in the orbit. This configuration | |||
Figure 6. While these spacecraft are all mobile, their relative | is illustrated in Figure 6. While these spacecraft are all mobile, | |||
mobility ensures continuous contact with each other under normal | their relative mobility ensures continuous contact with each other | |||
conditions. | under normal conditions. | |||
.--. .--. .--. | .--. .--. .--. | |||
####-| N1 |-#### <---> ####-| N2 |-#### <---> ####-| N3 |-#### | ####-| N1 |-#### <---> ####-| N2 |-#### <---> ####-| N3 |-#### | |||
\__/ \__/ \__/ | \__/ \__/ \__/ | |||
Figure 6: Three Sequential Spacecraft | Figure 6: Three Sequential Spacecraft | |||
Flying over a ground station imposes a non-relative motion between | Flying over a ground station imposes a non-relative motion between | |||
the ground and the spacecraft - namely that any given ground station | 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. | 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 | 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 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 | 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 | 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 t1, N2 sees ground at time t2, and spacecraft N1 sees | |||
ground at time t3. | ground at time t3. | |||
Spacecraft N1 Spacecraft N2 Spacecraft N3 | Spacecraft N1 Spacecraft N2 Spacecraft N3 | |||
G | G | G | | G | G | G | | |||
r | +--+ r | +--+ r | +--+ | r | +--+ r | +--+ r | +--+ | |||
o | | | o | | | o | | | | o | | | o | | | o | | | | |||
u | | | u | | | u | | | | u | | | u | | | u | | | | |||
n |--------------+ +- n |---------+ +------- n |---+ +------------- | n |--------------+ +- n |---------+ +------- n |---+ +------------- | |||
d | d | d | | d | d | d | | |||
+---++----++----++-- +----++----++----++-- +----++----++----++-- | +---++----++----++-- +----++----++----++-- +----++----++----++-- | |||
t1 t2 t3 t1 t2 t3 t1 t2 t3 | t1 t2 t3 t1 t2 t3 t1 t2 t3 | |||
Time Time Time | Time Time Time | |||
Figure 7: Spacecraft Ground Contacts Over Time | Figure 7: Spacecraft Ground Contacts over Time | |||
Since the ground station in this example is stationary, each | Since the ground station in this example is stationary, each | |||
spacecraft will pass over it, resulting in a change to the network | spacecraft will pass over it, resulting in a change to the network | |||
topology. This topology change is shown in Figure 8. At time t1, | topology. This topology change is shown in Figure 8. At time t1, | |||
any message residing on N3 and destined for the ground could be | any message residing on N3 and destined for the ground could be | |||
forwarded directly to the ground station. At time t2, that same | forwarded directly to the ground station. At time t2, that same | |||
message would need to, instead, be forwarded to N2 and then forwarded | 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 | to ground. By time t3, the same message would need to be forwarded | |||
from N2 to N1 and then down to ground. | from N2 to N1 and then down to ground. | |||
skipping to change at page 16, line 36 ¶ | skipping to change at line 689 ¶ | |||
t3 | N1 |----------| N2 |----------| N3 | | t3 | N1 |----------| N2 |----------| N3 | | |||
+---+--+ +------+ +------+ | +---+--+ +------+ +------+ | |||
| | | | |||
/|\ | /|\ | |||
\___/ | \___/ | |||
/ \ | / \ | |||
Ground | Ground | |||
Station | Station | |||
------------------------------------------------------------------ | ------------------------------------------------------------------ | |||
Figure 8: Constellation Topology Over Time | Figure 8: Constellation Topology over Time | |||
This example focuses on the case where the spacecrafts fly over a | This example focuses on the case where the spacecrafts fly over a | |||
ground station and introduce changes in the network topology. There | ground station and introduce changes in the network topology. There | |||
are also scenarios where the in-constellation network topology varies | are also scenarios where the in-constellation network topology varies | |||
over time following a deterministic time-driven operation from the | over time following a deterministic time-driven operation from the | |||
ground system. More information on in-constellation network topology | ground system. More information on in-constellation network topology | |||
can be found in [LHAN-PROB] and [LWOOD-SCN]. For this example, and | can be found in [SAT-CONSTELLATION] and [SCN]. For this example, and | |||
in particular for within constellation network topology changes, TVR | in particular for within constellation network topology changes, the | |||
approach is important to avoid the Interior Gateway Protocol (IGP) | TVR approach is important to avoid the Interior Gateway Protocol | |||
issues mentioned in [LHAN-PROB]. | (IGP) issues mentioned in [SAT-CONSTELLATION]. | |||
4.4. Another Example : Predictable Moving Vessels | 4.4. Another Example: Predictable Moving Vessels | |||
Another relevant example for this use case involves the movement of | Another relevant example for this use case involves the movement of | |||
vessels with predictable trajectories, such as ferries or planes. | vessels with predictable trajectories, such as ferries or planes. | |||
These end points often rely on a combination of satellite and | These endpoints often rely on a combination of satellite and | |||
terrestrial systems for Internet connectivity, capitalizing on their | terrestrial systems for Internet connectivity, capitalizing on their | |||
predictable journeys. | predictable journeys. | |||
This scenario also covers situations where nodes employ dynamic | This scenario also covers situations where nodes employ dynamic | |||
pointing solutions to track the mobility of other nodes. In such | pointing solutions to track the mobility of other nodes. In such | |||
cases, nodes dynamically adjust their antennas and application | cases, nodes dynamically adjust their antennas and application | |||
settings to determine the optimal timing for data transmission along | settings to determine the optimal timing for data transmission along | |||
the path. | the path. | |||
5. Acknowledgments | 5. Security Considerations | |||
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. | ||||
6. Security Considerations | ||||
While this document does not define a specific mechanism or solution, | While this document does not define a specific mechanism or solution, | |||
it serves to motivate the use of Time-Based Validation and Revocation | it serves to motivate the use of time-based validation and revocation | |||
(TVR). Therefore, security considerations are anticipated to be | strategies. Therefore, security considerations are anticipated to be | |||
addressed elsewhere, such as within a TVR schedule definition or | addressed elsewhere, such as within a TVR schedule definition or | |||
through a protocol extension utilizing a TVR schedule. However it's | through a protocol extension utilizing a TVR schedule. However, it's | |||
important to note that time synchronization is critical within a | important to note that time synchronization is critical within a | |||
network employing a TVR schedule. Any unauthorized changes to | network employing a TVR schedule. Any unauthorized changes to | |||
network clocks can disrupt network functionality, potentially leading | network clocks can disrupt network functionality, potentially leading | |||
to a Denial of Service (DoS) attack. | to a Denial of Service (DoS) attack. | |||
7. IANA Considerations | 6. IANA Considerations | |||
This document has no IANA actions. | This document has no IANA actions. | |||
8. Informative References | 7. Informative References | |||
[LHAN-PROB] | [SAT-CONSTELLATION] | |||
Han, L., Li, R., Retana, A., Chen, M., Su, L., Jiang, T., | Han, L., Li, R., Retana, A., Chen, M., Su, L., and T. | |||
and N. Wang, "Problems and Requirements of Satellite | Jiang, "Problems and Requirements of Satellite | |||
Constellation for Internet", n.d., | Constellation for Internet", Work in Progress, Internet- | |||
<https://datatracker.ietf.org/doc/draft-lhan-problems- | Draft, draft-lhan-problems-requirements-satellite-net-06, | |||
requirements-satellite-net/>. | 4 January 2024, <https://datatracker.ietf.org/doc/html/ | |||
draft-lhan-problems-requirements-satellite-net-06>. | ||||
[LWOOD-SCN] | [SCN] Wood, L., "Satellite Constellation Networks", | |||
Wood, L., "SATELLITE CONSTELLATION NETWORKS", | Internetworking and Computing over Satellite Networks, pp. | |||
Internetworking and Computing over Satellite Networks , | 13-34, DOI 10.1007/978-1-4615-0431-3_2, April 2003, | |||
2003, <http://personal.ee.surrey.ac.uk/Personal/L.Wood/ | <https://link.springer.com/ | |||
publications/zhang-book/zhang-book-wood-chapter-2.pdf>. | chapter/10.1007/978-1-4615-0431-3_2>. | |||
[TIDAL] Zang, L., Zhou, T., Dong, J., and N. Nzima, "Use Case of | [TIDAL] Zhang, L., Zhou, T., Dong, J., and N. Nzima, "Use Case of | |||
Tidal Network", n.d., <https://datatracker.ietf.org/doc/ | Tidal Network", Work in Progress, Internet-Draft, draft- | |||
draft-zzd-tvr-use-case-tidal-network/>. | 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 | Authors' Addresses | |||
Ed Birrane | Edward J. Birrane, III | |||
JHU/APL | JHU/APL | |||
Email: edward.birrane@jhuapl.edu | Email: edward.birrane@jhuapl.edu | |||
Nicolas Kuhn | Nicolas Kuhn | |||
Thales Alenia Space | Thales Alenia Space | |||
Email: nicolas.kuhn.ietf@gmail.com | Email: nicolas.kuhn.ietf@gmail.com | |||
Yingzhen Qu | Yingzhen Qu | |||
Futurewei Technologies | Futurewei Technologies | |||
Email: yingzhen.ietf@gmail.com | Email: yingzhen.ietf@gmail.com | |||
Rick Taylor | Rick Taylor | |||
Ori Industries | Aalyria Technologies | |||
Email: rick.taylor@ori.co | Email: rtaylor@aalyria.com | |||
Li zhang | Li Zhang | |||
Huawei | Huawei | |||
Email: zhangli344@huawei.com | Email: zhangli344@huawei.com | |||
End of changes. 89 change blocks. | ||||
257 lines changed or deleted | 242 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |