<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-tvr-use-cases-09" number="9657" updates="" obsoletes="" consensus="true" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" prepTime="2024-10-08T14:50:30" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-tvr-use-cases-09" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9657" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="TVR Use Cases">Time-Variant Routing (TVR) Use Cases</title>
    <seriesInfo name="RFC" value="9657" stream="IETF"/>
    <author fullname="Edward J. Birrane, III" surname="Birrane, III" initials="E.">
      <organization showOnFrontPage="true">JHU/APL</organization>
      <address>
        <email>edward.birrane@jhuapl.edu</email>
      </address>
    </author>
    <author fullname="Nicolas Kuhn" surname="Kuhn" initials="N.">
      <organization showOnFrontPage="true">Thales Alenia Space</organization>
      <address>
        <email>nicolas.kuhn.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Yingzhen Qu" surname="Qu" initials="Y.">
      <organization showOnFrontPage="true">Futurewei Technologies</organization>
      <address>
        <email>yingzhen.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Rick Taylor" surname="Taylor" initials="R.">
      <organization showOnFrontPage="true">Aalyria Technologies</organization>
      <address>
        <email>rtaylor@aalyria.com</email>
      </address>
    </author>
    <author fullname="Li Zhang" surname="Zhang" initials="L.">
      <organization showOnFrontPage="true">Huawei</organization>
      <address>
        <email>zhangli344@huawei.com</email>
      </address>
    </author>
    <date month="10" year="2024"/>
    <area>RTG</area>
    <workgroup>tvr</workgroup>
    <keyword>Time-variant</keyword>
    <keyword>Routing</keyword>
    <keyword>Mobility</keyword>
    <keyword>Green computing</keyword>
    <keyword>Resource management</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            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. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9657" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2024 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-resource-preservation">Resource Preservation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-assumptions">Assumptions</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-routing-impacts">Routing Impacts</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example">Example</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operating-efficiency">Operating Efficiency</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-assumptions-2">Assumptions</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-routing-impacts-2">Routing Impacts</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-cellular-network">Example: Cellular Network</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-another-example-tidal-netwo">Another Example: Tidal Network</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dynamic-reachability">Dynamic Reachability</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-assumptions-3">Assumptions</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-routing-impacts-3">Routing Impacts</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-mobile-satellites">Example: Mobile Satellites</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-another-example-predictable">Another Example: Predictable Moving Vessels</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">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.</t>
      <t indent="0" pn="section-1-2">Expected changes to topologies can occur for a variety of reasons. In
      networks with mobile nodes, such as unmanned aerial vehicles and some
      orbiting spacecraft constellations, links are lost and re-established as
      a function of the mobility of the platforms. In networks without
      reliable access to power, such as networks harvesting energy from wind
      and solar, link activity might be restricted to certain times of
      day. Similarly, in networks prioritizing green computing and energy
      efficiency over data rate, network traffic might be planned around
      energy costs or expected user data volumes.</t>
      <t indent="0" pn="section-1-3">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:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-1-4">
        <li pn="section-1-4.1" derivedCounter="1.">An overview of the use case describing how route computations
        might select different paths (or subpaths) as a function of time.</li>
        <li pn="section-1-4.2" derivedCounter="2.">A set of assumptions made by the use case as to the nature of
        the network and data exchange.</li>
        <li pn="section-1-4.3" derivedCounter="3.">Specific discussion on the routing impacts of the use case.</li>
        <li pn="section-1-4.4" derivedCounter="4.">Example networks conformant to the use case.</li>
      </ol>
      <t indent="0" pn="section-1-5">The use cases that are considered in this document are as follows:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-1-6">
        <li pn="section-1-6.1" derivedCounter="1.">Resource Preservation (described in <xref target="Resource-Preservation" format="default" sectionFormat="of" derivedContent="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.</li>
        <li pn="section-1-6.2" derivedCounter="2.">Operating Efficiency (described in <xref target="Operating-Efficiency" format="default" sectionFormat="of" derivedContent="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.</li>
        <li pn="section-1-6.3" derivedCounter="3.">Dynamic Reachability (described in <xref target="Dynamic-Reachability" format="default" sectionFormat="of" derivedContent="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.</li>
      </ol>
      <t indent="0" pn="section-1-7">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.</t>
      <t indent="0" pn="section-1-8">The document focuses on deterministic scenarios. Non-deterministic
      scenarios, such as vehicle-to-vehicle communication, are out of the
      scope of the document.</t>
    </section>
    <section anchor="Resource-Preservation" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-resource-preservation">Resource Preservation</name>
      <t indent="0" pn="section-2-1">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.</t>
      <t indent="0" pn="section-2-2">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.</t>
      <t indent="0" pn="section-2-3">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.</t>
      <section anchor="assumptions" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-assumptions">Assumptions</name>
        <t indent="0" pn="section-2.1-1">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:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2.1-2">
          <li pn="section-2.1-2.1" derivedCounter="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.</li>
          <li pn="section-2.1-2.2" derivedCounter="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.</li>
          <li pn="section-2.1-2.3" derivedCounter="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.</li>
        </ol>
      </section>
      <section anchor="routing-impacts" numbered="true" removeInRFC="false" toc="include" pn="section-2.2">
        <name slugifiedName="name-routing-impacts">Routing Impacts</name>
        <t indent="0" pn="section-2.2-1">Resource management in these scenarios might involve turning off elements of the node as part of on-board resource management. These activities can affect data routing in a variety of ways.</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2.2-2">
          <li pn="section-2.2-2.1" derivedCounter="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.</li>
          <li pn="section-2.2-2.2" derivedCounter="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.</li>
          <li pn="section-2.2-2.3" derivedCounter="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.</li>
        </ol>
        <t indent="0" pn="section-2.2-3">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.</t>
      </section>
      <section anchor="example" numbered="true" removeInRFC="false" toc="include" pn="section-2.3">
        <name slugifiedName="name-example">Example</name>
        <t indent="0" pn="section-2.3-1">An illustrative example of a network necessitating resource preservation is an energy-harvesting wireless sensor network. In such a network, nodes rely exclusively on environmental sources for power, such as solar panels. On-board power levels may fluctuate based on various factors including sensor activity, processing demands, and the node's position and orientation relative to its energy source.</t>
        <t indent="0" pn="section-2.3-2">Consider a simple three-node network where each node accumulates power through solar panels.  Power available for radio frequency (RF) transmission is shown in <xref target="Resource-Example-Plots" format="default" sectionFormat="of" derivedContent="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.</t>
        <figure anchor="Resource-Example-Plots" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-node-power-over-time">Node Power over Time</name>
          <artwork type="ascii-art" align="center" pn="section-2.3-3.1">
           Node 1                   Node 2                   Node 3
P |                      P |   -------            P |          --
o |  ----       --       o |  /       \           o |         /  \
w |~/~~~~\~~~~~/~~\~~    w |~/~~~~~~~~~\~~~~~~    w |~~~~~~~~/~~~~\~~~~
e |/      \   /    \     e |/           \         e |       /      \
r |        ---      -    r |             -----    r |-------        ---
  +---++----++----++-      +---++----++----++-      +---++----++----++-
      t1    t2    t3           t1    t2    t3           t1    t2    t3
           Time                     Time                     Time
</artwork>
        </figure>
        <t indent="0" pn="section-2.3-4">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 <xref target="Resource-Example-Schedule" format="default" sectionFormat="of" derivedContent="Figure 2"/>.  This figure
        shows a sample of network connectivity at three times: t1, t2, and
        t3.</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.3-5">
          <li pn="section-2.3-5.1">
            <t indent="0" pn="section-2.3-5.1.1">At time t1, Node 1 and Node 2 have their radios powered on and
            are expected to communicate.</t>
          </li>
          <li pn="section-2.3-5.2">
            <t indent="0" pn="section-2.3-5.2.1">At time t2, it is expected that Node 1 has its radio off but
            that Node 2 and Node 3 can communicate.</t>
          </li>
          <li pn="section-2.3-5.3">
            <t indent="0" pn="section-2.3-5.3.1">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.</t>
          </li>
        </ul>
        <figure anchor="Resource-Example-Schedule" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-topology-over-time">Topology over Time</name>
          <artwork type="ascii-art" align="center" pn="section-2.3-6.1">
     +----------+        +----------+        +----------+
t1   |  Node 1  |--------|  Node 2  |        |  Node 3  |
     +----------+        +----------+        +----------+

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

     +----------+        +----------+        +----------+
t3   |  Node 1  |        |  Node 2  |        |  Node 3  |
     +----------+        +----------+        +----------+
</artwork>
        </figure>
      </section>
    </section>
    <section anchor="Operating-Efficiency" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-operating-efficiency">Operating Efficiency</name>
      <t indent="0" pn="section-3-1">Some nodes in a network might alter their networking behavior to optimize metrics associated with the cost of a node's operation. While the resource preservation use case described in <xref target="Resource-Preservation" format="default" sectionFormat="of" derivedContent="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.</t>
      <t indent="0" pn="section-3-2">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:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3-3"><li pn="section-3-3.1" derivedCounter="1.">
          <t indent="0" pn="section-3-3.1.1">Nodes that use existing wireless communications, such as a
          cellular infrastructure, must pay to communicate to and through that
          infrastructure.</t>
        </li>
        <li pn="section-3-3.2" derivedCounter="2.">
          <t indent="0" pn="section-3-3.2.1">Nodes supplied with electricity from an energy provider pay for
          the power they use.</t>
        </li>
        <li pn="section-3-3.3" derivedCounter="3.">
          <t indent="0" pn="section-3-3.3.1">Nodes that cluster computation and activities might increase the
          temperature of the node and incur additional costs associated with
          cooling the node (or collection of nodes).</t>
        </li>
        <li pn="section-3-3.4" derivedCounter="4.">
          <t indent="0" pn="section-3-3.4.1">Beyond financial costs, assessing the environmental impact of
          operating a node may also be modeled as a cost associated with node
          operation, to include achieving carbon credits or other incentives
          for green computing.</t>
        </li>
      </ol>
      <t indent="0" pn="section-3-4">When the cost of using a node's resources changes over time, a node
      can benefit from predicting when data transmissions might optimize
      costs, environmental impacts, or other metrics associated with
      operation.</t>
      <section anchor="assumptions-1" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-assumptions-2">Assumptions</name>
        <t indent="0" pn="section-3.1-1">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:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3.1-2"><li pn="section-3.1-2.1" derivedCounter="1.">
            <t indent="0" pn="section-3.1-2.1.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.</t>
          </li>
          <li pn="section-3.1-2.2" derivedCounter="2.">
            <t indent="0" pn="section-3.1-2.2.1">Cost Predictability. Changes to the impacts of resource
            utilization are known in advance. For example, if the cost of
            energy is less expensive in the evening than during the day, there
            exists some way of communicating this change to a node.</t>
          </li>
          <li pn="section-3.1-2.3" derivedCounter="3.">
            <t indent="0" pn="section-3.1-2.3.1">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.</t>
          </li>
          <li pn="section-3.1-2.4" derivedCounter="4.">
            <t indent="0" pn="section-3.1-2.4.1">Cost Magnitude. The magnitude of cost changes is such that a
            node experiences a minimum threshold cost reduction through
            optimization. A specified time period is designated for measuring
            the cost reduction.</t>
          </li>
        </ol>
      </section>
      <section anchor="routing-impacts-1" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-routing-impacts-2">Routing Impacts</name>
        <t indent="0" pn="section-3.2-1">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:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3.2-2"><li pn="section-3.2-2.1" derivedCounter="1.">
            <t indent="0" pn="section-3.2-2.1.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).</t>
          </li>
          <li pn="section-3.2-2.2" derivedCounter="2.">
            <t indent="0" pn="section-3.2-2.2.1">Burst Planning. In cases where there is a cost savings
            associated with fewer longer transmissions (versus many smaller
            transmissions), nodes might refuse to forward data until a
            sufficient data volume exists to justify a transmission.</t>
          </li>
          <li pn="section-3.2-2.3" derivedCounter="3.">
            <t indent="0" pn="section-3.2-2.3.1">Environmental Measurement. Nodes that measure the quality of
            individual links can compute the overall cost of using a link as a
            function of the signal strength of the link. If link quality is
            insufficient due to environmental conditions (such as clouds on a
            free-space optical link or long distance RF transmission in a
            storm) the cost required to communicate over the link may be too
            much, even if access to infrastructure is otherwise in a less
            expensive time of day.</t>
          </li>
        </ol>
        <t indent="0" pn="section-3.2-3">In each of these cases, some consideration of the efficiency of
        transmission is prioritized over achieving a particular data rate.
        Waiting until data rate costs are lower takes advantage of platforms
        using time-of-use rate plans -- both for pay-as-you-go data and
        associated energy costs. Accumulating data volumes and choosing more
        opportune times to transmit can also result in less energy consumption
        by radios and, thus, less operating cost for platforms.</t>
      </section>
      <section anchor="example-cellular-network" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-example-cellular-network">Example: Cellular Network</name>
        <t indent="0" pn="section-3.3-1">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).</t>
        <t indent="0" pn="section-3.3-2">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.</t>
        <t indent="0" pn="section-3.3-3">Consider a simple three-node network, similar to the one pictured
        in <xref target="Resource-Example-Plots" format="default" sectionFormat="of" derivedContent="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 <xref target="Efficiency-Example-Plots" format="default" sectionFormat="of" derivedContent="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).</t>
        <figure anchor="Efficiency-Example-Plots" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-data-cost-over-time">Data Cost over Time</name>
          <artwork type="ascii-art" align="center" pn="section-3.3-4.1">
  Node 1                 Node 2                  Node 3

C |       +---------   C |--+                  C |-------------+
o |       |            o |  |                  o |             |
s |       |            s |  |                  s |             |
t |-------+            t |  +----------------  t |             +-------
  |                      |                       |
  +---++----++----++--   +----++----++----++--   +----++----++-----++--
      t1    t2    t3          t1    t2    t3          t1    t2     t3
           Time                    Time                    Time
</artwork>
        </figure>
        <t indent="0" pn="section-3.3-5">Given the presumption that peak times are known in advance, the
        cost of data exchange from Node 1 through Node 2 to Node 3 can be
        calculated. Examples of these data exchanges are shown in <xref target="Efficiency-Example-Schedule" format="default" sectionFormat="of" derivedContent="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.</t>
        <figure anchor="Efficiency-Example-Schedule" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-data-exchange-cost-over-tim">Data Exchange Cost over Time</name>
          <artwork type="ascii-art" align="center" pn="section-3.3-6.1">
     +-----------+          +-----------+          +-----------+
t1   |  Node N1  |---LOW----|  Node N2  |---HIGH---|  Node N3  |
     +-----------+          +-----------+          +-----------+

     +-----------+          +-----------+          +-----------+
t2   |  Node N1  |---HIGH---|  Node N2  |---HIGH---|  Node N3  |
     +-----------+          +-----------+          +-----------+

     +-----------+          +-----------+          +-----------+
t3   |  Node N1  |---HIGH---|  Node N2  |----LOW---|  Node N3  |
     +-----------+          +-----------+          +-----------+
</artwork>
        </figure>
        <t indent="0" pn="section-3.3-7">While not possible in every circumstance, a highly optimized plan
        could be to communicate from Node 1 to Node 2 at time t1 and then
        queue data at Node 2 until time t3 for delivery to Node 3. This case
        is shown in <xref target="Efficiency-Example-Store" format="default" sectionFormat="of" derivedContent="Figure 5"/>.</t>
        <figure anchor="Efficiency-Example-Store" align="left" suppress-title="false" pn="figure-5">
          <name slugifiedName="name-data-cost-using-storage">Data Cost Using Storage</name>
          <artwork type="ascii-art" align="center" pn="section-3.3-8.1">
     +-----------+          +-----------+
t1   |  Node N1  |---LOW----|  Node N2  |
     +-----------+          +-----------+
                            +-----------+          +-----------+
t3                          |  Node N2  |----LOW---|  Node N3  |
                            +-----------+          +-----------+
</artwork>
        </figure>
      </section>
      <section anchor="another-example-tidal-network" numbered="true" removeInRFC="false" toc="include" pn="section-3.4">
        <name slugifiedName="name-another-example-tidal-netwo">Another Example: Tidal Network</name>
        <t indent="0" pn="section-3.4-1">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.</t>
        <t indent="0" pn="section-3.4-2">In the context of a tidal network scenario, energy-saving methods may include the deactivation of some or all components of network nodes. These activities have the potential to alter network topology and impact data routing in a variety of ways. Ports on network nodes can be selectively disabled or enabled based on traffic patterns, thereby reducing the energy consumption of nodes during periods of low network traffic.</t>
        <t indent="0" pn="section-3.4-3">More information on tidal networks can be found in <xref target="I-D.zzd-tvr-use-case-tidal-network" format="default" sectionFormat="of" derivedContent="TIDAL"/>.</t>
      </section>
    </section>
    <section anchor="Dynamic-Reachability" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-dynamic-reachability">Dynamic Reachability</name>
      <t indent="0" pn="section-4-1">When a node is placed on a mobile platform, the mobility of the
      platform (and thus the mobility of the node) may cause changes to the
      topology of the network over time. The impacts on the dynamics of the
      topology can be very important. To the extent that the relative mobility
      between and among nodes in the network and the impacts of the
      environment on the signal propagation can be predicted, the associated
      loss and establishment of adjacencies can also be planned for.</t>
      <t indent="0" pn="section-4-2">Mobility can cause the loss of an adjacent link in several ways, such as that which follows:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4-3"><li pn="section-4-3.1" derivedCounter="1.">
          <t indent="0" pn="section-4-3.1.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.</t>
        </li>
        <li pn="section-4-3.2" derivedCounter="2.">
          <t indent="0" pn="section-4-3.2.1">Node mobility can also be used to maintain a required distance from other mobile nodes in the network. While moving, external characteristics may cause the loss of links through occultation or other hazards of traversing a shared environment.</t>
        </li>
        <li pn="section-4-3.3" derivedCounter="3.">
          <t indent="0" pn="section-4-3.3.1">Node mobility can cause the distance between two nodes to vary quickly over time, making it complicated to establish and maintain connectivity.</t>
        </li>
        <li pn="section-4-3.4" derivedCounter="4.">
          <t indent="0" pn="section-4-3.4.1">Nodes equipped with communication terminals capable of adjusting their orientation or moving behind and emerging from barriers will also establish and lose connectivity with other nodes as a function of that motion.</t>
        </li>
      </ol>
      <t indent="0" pn="section-4-4">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.</t>
      <section anchor="assumptions-2" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-assumptions-3">Assumptions</name>
        <t indent="0" pn="section-4.1-1">Predicting the impact of node mobility on route computation requires some information relating to the nature of the mobility and the nature of the environment being moved through. Some information presumed to exist for planning is listed as follows:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.1-2"><li pn="section-4.1-2.1" derivedCounter="1.">
            <t indent="0" pn="section-4.1-2.1.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.</t>
          </li>
          <li pn="section-4.1-2.2" derivedCounter="2.">
            <t indent="0" pn="section-4.1-2.2.1">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.</t>
          </li>
        </ol>
      </section>
      <section anchor="routing-impacts-2" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-routing-impacts-3">Routing Impacts</name>
        <t indent="0" pn="section-4.2-1">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:</t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.2-2"><li pn="section-4.2-2.1" derivedCounter="1.">
            <t indent="0" pn="section-4.2-2.1.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.</t>
          </li>
          <li pn="section-4.2-2.2" derivedCounter="2.">
            <t indent="0" pn="section-4.2-2.2.1">Adjacent Link Resumption. Just as the loss of an adjacency can
            be predicted, it may be possible to predict when an adjacency will
            resume.</t>
          </li>
          <li pn="section-4.2-2.3" derivedCounter="3.">
            <t indent="0" pn="section-4.2-2.3.1">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.</t>
          </li>
          <li pn="section-4.2-2.4" derivedCounter="4.">
            <t indent="0" pn="section-4.2-2.4.1">Adjacent Link Filtering. Separate from the instantaneous
            presence or absence of an adjacency, a route computation might
            choose to not use an adjacency if that adjacency is likely to
            expire in the near future or if it is likely to experience a
            significant drop in predicted data rate.</t>
          </li>
        </ol>
      </section>
      <section anchor="example-mobile-satellites" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-example-mobile-satellites">Example: Mobile Satellites</name>
        <t indent="0" pn="section-4.3-1">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)).</t>
        <t indent="0" pn="section-4.3-2">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.</t>
        <t indent="0" pn="section-4.3-3">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.</t>
        <t indent="0" pn="section-4.3-4">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 <xref target="Mobility-SOP" format="default" sectionFormat="of" derivedContent="Figure 6"/>. While these spacecraft are all mobile, their relative mobility ensures continuous contact with each other under normal conditions.</t>
        <figure anchor="Mobility-SOP" align="left" suppress-title="false" pn="figure-6">
          <name slugifiedName="name-three-sequential-spacecraft">Three Sequential Spacecraft</name>
          <artwork type="ascii-art" align="center" pn="section-4.3-5.1">
      .--.                     .--.                     .--.
####-| N1 |-####  &lt;---&gt;  ####-| N2 |-####  &lt;---&gt;  ####-| N3 |-####
      \__/                     \__/                     \__/

</artwork>
        </figure>
        <t indent="0" pn="section-4.3-6">Flying over a ground station imposes a non-relative motion between the ground and the spacecraft -- namely that any given ground station will only be in view of the spacecraft for a short period of time. The times at which each spacecraft can see the ground station is shown in the plots in <xref target="Mobility-Example" format="default" sectionFormat="of" derivedContent="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.</t>
        <figure anchor="Mobility-Example" align="left" suppress-title="false" pn="figure-7">
          <name slugifiedName="name-spacecraft-ground-contacts-">Spacecraft Ground Contacts over Time</name>
          <artwork type="ascii-art" align="center" pn="section-4.3-7.1">
       Spacecraft N1           Spacecraft N2            Spacecraft N3
G |                     G |                      G |
r |              +--+   r |         +--+         r |   +--+
o |              |  |   o |         |  |         o |   |  |
u |              |  |   u |         |  |         u |   |  |
n |--------------+  +-  n |---------+  +-------  n |---+  +-------------
d |                     d |                      d |
  +---++----++----++--    +----++----++----++--    +----++----++----++--
      t1    t2    t3           t1    t2    t3           t1    t2    t3
           Time                     Time                     Time
</artwork>
        </figure>
        <t indent="0" pn="section-4.3-8">Since the ground station in this example is stationary, each spacecraft will pass over it, resulting in a change to the network topology. This topology change is shown in <xref target="Mobility-Example-Topology" format="default" sectionFormat="of" derivedContent="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.</t>
        <figure anchor="Mobility-Example-Topology" align="left" suppress-title="false" pn="figure-8">
          <name slugifiedName="name-constellation-topology-over">Constellation Topology over Time</name>
          <artwork type="ascii-art" align="center" pn="section-4.3-9.1">
    +------+          +------+
t1  |  N2  |----------|  N3  |
    +------+          +---+--+
                          |
                         /|\
                        \___/
                         / \
                       Ground
                       Station
------------------------------------------------------------------
    +------+          +------+          +------+
t2  |  N1  |----------|  N2  |----------|  N3  |
    +------+          +---+--+          +------+
                          |
                         /|\
                        \___/
                         / \
                       Ground
                       Station
------------------------------------------------------------------
                      +------+          +------+          +------+
t3                    |  N1  |----------|  N2  |----------|  N3  |
                      +---+--+          +------+          +------+
                          |
                         /|\
                        \___/
                         / \
                       Ground
                       Station
------------------------------------------------------------------
</artwork>
        </figure>
        <t indent="0" pn="section-4.3-10">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 <xref target="I-D.lhan-problems-requirements-satellite-net" format="default" sectionFormat="of" derivedContent="SAT-CONSTELLATION"/> and <xref target="SCN" format="default" sectionFormat="of" derivedContent="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 <xref target="I-D.lhan-problems-requirements-satellite-net" format="default" sectionFormat="of" derivedContent="SAT-CONSTELLATION"/>.</t>
      </section>
      <section anchor="another-example-predictable-moving-vessels" numbered="true" removeInRFC="false" toc="include" pn="section-4.4">
        <name slugifiedName="name-another-example-predictable">Another Example: Predictable Moving Vessels</name>
        <t indent="0" pn="section-4.4-1">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.</t>
        <t indent="0" pn="section-4.4-2">This scenario also covers situations where nodes employ dynamic pointing solutions to track the mobility of other nodes. In such cases, nodes dynamically adjust their antennas and application settings to determine the optimal timing for data transmission along the path.</t>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">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.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.zzd-tvr-use-case-tidal-network" to="TIDAL"/>
    <displayreference target="I-D.lhan-problems-requirements-satellite-net" to="SAT-CONSTELLATION"/>
    <references anchor="sec-informative-references" pn="section-7">
      <name slugifiedName="name-informative-references">Informative References</name>
      <reference anchor="I-D.lhan-problems-requirements-satellite-net" target="https://datatracker.ietf.org/doc/html/draft-lhan-problems-requirements-satellite-net-06" quoteTitle="true" derivedAnchor="SAT-CONSTELLATION">
        <front>
          <title>Problems and Requirements of Satellite Constellation for Internet</title>
          <author initials="L." surname="Han" fullname="Lin Han">
            <organization showOnFrontPage="true">Futurewei Technologies, Inc.</organization>
          </author>
          <author initials="R." surname="Li" fullname="Richard Li">
            <organization showOnFrontPage="true">Futurewei Technologies, Inc.</organization>
          </author>
          <author initials="A." surname="Retana" fullname="Alvaro Retana">
            <organization showOnFrontPage="true">Futurewei Technologies, Inc.</organization>
          </author>
          <author initials="M." surname="Chen" fullname="Meiling Chen">
            <organization showOnFrontPage="true">China Mobile</organization>
          </author>
          <author initials="L." surname="Su" fullname="Li Su">
            <organization showOnFrontPage="true">China Mobile</organization>
          </author>
          <author initials="T." surname="Jiang" fullname="Tianji Jiang">
            <organization showOnFrontPage="true">China Mobile</organization>
          </author>
          <date month="January" day="4" year="2024"/>
          <abstract>
            <t indent="0">   This document presents the detailed analysis about the problems and
   requirements of satellite constellation used for Internet.  It starts
   from the satellite orbit basics, coverage calculation, then it
   estimates the time constraints for the communications between
   satellite and ground-station, also between satellites.  How to use
   satellite constellation for Internet is discussed in detail including
   the satellite relay and satellite networking.  The problems and
   requirements of using traditional network technology for satellite
   network integrating with Internet are finally outlined.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-lhan-problems-requirements-satellite-net-06"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="SCN" target="https://link.springer.com/chapter/10.1007/978-1-4615-0431-3_2" quoteTitle="true" derivedAnchor="SCN">
        <front>
          <title>Satellite Constellation Networks</title>
          <author initials="L." surname="Wood" fullname="Lloyd Wood">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="April" year="2003"/>
        </front>
        <seriesInfo name="DOI" value="10.1007/978-1-4615-0431-3_2"/>
        <refcontent>Internetworking and Computing over Satellite Networks, pp. 13-34</refcontent>
      </reference>
      <reference anchor="I-D.zzd-tvr-use-case-tidal-network" target="https://datatracker.ietf.org/doc/html/draft-zzd-tvr-use-case-tidal-network-02" quoteTitle="true" derivedAnchor="TIDAL">
        <front>
          <title>Use Case of Tidal Network</title>
          <author initials="L." surname="Zhang" fullname="Li Zhang">
            <organization showOnFrontPage="true">Huawei</organization>
          </author>
          <author initials="T." surname="Zhou" fullname="Tianran Zhou">
            <organization showOnFrontPage="true">Huawei</organization>
          </author>
          <author initials="J." surname="Dong" fullname="Jie Dong">
            <organization showOnFrontPage="true">Huawei</organization>
          </author>
          <author initials="N." surname="Nzima" fullname="Nkosinathi Nzima">
            <organization showOnFrontPage="true">MTN</organization>
          </author>
          <date month="July" day="28" year="2023"/>
          <abstract>
            <t indent="0">   The tidal effect of traffic is very typical on our network, this
   document introduces the time variant routing scenario in the tidal
   network, and then describes the assumptions and routing impacts based
   on the use case.  Finally, an exempar of tidal network is provided.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-zzd-tvr-use-case-tidal-network-02"/>
        <refcontent>Work in Progress</refcontent>
      </reference>
    </references>
    <section anchor="acknowledgments" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">Many thanks to <contact fullname="Tony Li"/>, <contact fullname="Peter Ashwood-Smith"/>, <contact fullname="Abdussalam       Baryun"/>, <contact fullname="Arashmid Akhavain"/>, <contact fullname="Dirk Trossen"/>, <contact fullname="Brian Sipos"/>, <contact fullname="Alexandre Petrescu"/>, <contact fullname="Haoyu Song"/>,
      <contact fullname="Hou Dongxu"/>, <contact fullname="Tianran Zhou"/>,
      <contact fullname="Jie Dong"/>, <contact fullname="Nkosinathi Nzima"/>,
      and <contact fullname="Vinton Cerf"/> for their useful comments that
      helped improve the document.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Edward J. Birrane, III" surname="Birrane, III" initials="E.">
        <organization showOnFrontPage="true">JHU/APL</organization>
        <address>
          <email>edward.birrane@jhuapl.edu</email>
        </address>
      </author>
      <author fullname="Nicolas Kuhn" surname="Kuhn" initials="N.">
        <organization showOnFrontPage="true">Thales Alenia Space</organization>
        <address>
          <email>nicolas.kuhn.ietf@gmail.com</email>
        </address>
      </author>
      <author fullname="Yingzhen Qu" surname="Qu" initials="Y.">
        <organization showOnFrontPage="true">Futurewei Technologies</organization>
        <address>
          <email>yingzhen.ietf@gmail.com</email>
        </address>
      </author>
      <author fullname="Rick Taylor" surname="Taylor" initials="R.">
        <organization showOnFrontPage="true">Aalyria Technologies</organization>
        <address>
          <email>rtaylor@aalyria.com</email>
        </address>
      </author>
      <author fullname="Li Zhang" surname="Zhang" initials="L.">
        <organization showOnFrontPage="true">Huawei</organization>
        <address>
          <email>zhangli344@huawei.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
