<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.27 (Ruby 3.1.4) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-tvr-use-cases-00" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.0 -->
  <front>
    <title abbrev="tvr-use-cases">TVR (Time-Variant Routing) Use Cases</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-tvr-use-cases-00"/>
    <author fullname="Ed Birrane">
      <organization>JHU/APL</organization>
      <address>
        <email>edward.birrane@jhuapl.edu</email>
      </address>
    </author>
    <author fullname="Nicolas Kuhn">
      <organization>Thales Alenia Space</organization>
      <address>
        <email>nicolas.kuhn.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Yingzhen Qu">
      <organization>Futurewei Technologies</organization>
      <address>
        <email>yingzhen.qu@futurewei.com</email>
      </address>
    </author>
    <date year="2023" month="April" day="15"/>
    <area>Routing</area>
    <keyword>Time-variant</keyword>
    <keyword>Routing</keyword>
    <keyword>Mobility</keyword>
    <keyword>Green computing</keyword>
    <keyword>Resource management</keyword>
    <abstract>
      <t>Time-Variant Routing (TVR) refers to the calculation of a path or subpath through a network where the time of message transmission (or receipt) is part of the overall route computation. This means that, all things being equal, a TVR computation might produce different results depending on the time that the computation is performed without other detectable changes to the network topology or other cost functions associated with the route.</t>
      <t>This document introduces use cases where TVR computations could improve message exchange in a network.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-tvr-use-cases/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Time Variant Routing Working Group mailing list (<eref target="mailto:tvr@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/tvr/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/tvr/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/NasaDtn/tvr-bof-use-cases"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>Existing Routing Protocols expect to maintain contemporaneous, end-to-end connected paths across a network. Changes to that connectivity, such as the loss of an adjacent peer, are considered to be exceptional circumstances that must be corrected prior to the resumption of data transmission. Corrections may include attempting to re-establish lost adjacencies and recalculating or rediscovering a functional topology.</t>
      <t>However, there are a growing number of use cases where changes to the routing topology are an expected part of network operations. In these cases the pre-planned loss and restoration of an adjacency, or formation of an alternate adjacency, should be seen as a non-disruptive event.</t>
      <t>The expected loss (and planned resumption) of links can occur for a variety of reasons. In networks with mobile nodes, such as unmanned aerial vehicles and some orbiting spacecraft constellations, links are lost and re-established as a function of the mobility of the platforms. In networks without reliable access to power, such as networks harvesting energy from wind and solar, link activity might be restricted to certain times of day. Similarly, in networks prioritizing green computing and energy efficiency over data rate, network traffic might be planned around energy costs or expected user data volumes.</t>
      <t>This document defines three use cases where a route computation might beneficially consider time information. Each of these use cases includes the following information.</t>
      <ol spacing="normal" type="1"><li>An overview of the use case describing how route computations might select different paths (or subpaths) as a function of time.</li>
        <li>A set of assumptions made by the use case as to the nature of the network and data exchange.</li>
        <li>Specific discussion on the routing impacts of the use case.</li>
        <li>An exemplar of a network conformant to the use case.</li>
      </ol>
      <t>The document may not represent the full set of cases where time-variant routes 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, not to present any exhaustive enumeration of potential examples. It is likely that there exist multiple example networks that could be claimed as instances of any given use case.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
    </section>
    <section anchor="Resource-Preservation">
      <name>Resource Preservation</name>
      <t>Some nodes in a network might operate in resource-constrained environments or otherwise with limited internal resources. Constraints such as available power, thermal ranges, and on-board storage can all impact the instantaneous functionality of a node. In particular, resource management on such a node can require that certain functionality be powered on (or off) to extend the ability of the node to participate in the network.</t>
      <t>When power on a node is running low, non-critical 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 fuse, delete, or transmit data off the node to free space for future data collection.</t>
      <t>In addition to power, thermal, and storage, other resource constraints may exist on a node such that the preservation of resources are necessary to preserve the existence (and proper function) of the node in the network. Nodes operating in these conditions might benefit from TVR computations as the connectivity of the node changes over time as part of node preservation.</t>
      <section anchor="assumptions">
        <name>Assumptions</name>
        <t>To manage on-board functionality as a function of available resources, a node must understand certain elements of how resources are used and replenished. It is assumed 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"><li>Known resource expenditures. It is assumed that there exists some determinable relationship between the resources available on a node and the resources needed to participate in a network. A node would need to understand when it has met some condition for participating in, or dropping out of, a network. This is somewhat similar to predicting the amount of battery life left on a laptop as a function of likely future usage.</li>
          <li>Predictable resource accumulation. It is assumed that the accumulation of resources on a node are predictable such that a node might expect (and be able to communicate) when it is likely to next rejoin a network.  This is similar to predicting the time at which a battery on a laptop will be fully charged.</li>
          <li>Consistent cost functions. It is assumed that resource management on a node is deterministic such that the management of a node as a function of resource expenditure and accumulation is consistent enough for link planning.</li>
        </ol>
      </section>
      <section anchor="routing-impacts">
        <name>Routing Impacts</name>
        <t>Resource management in these scenarios might involve turning off elements of the node as part of on-board resource management. These activities can affect data routing in a variety of ways.</t>
        <ol spacing="normal" type="1"><li>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>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>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>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="exemplar">
        <name>Exemplar</name>
        <t>One example of a network where nodes must perform resource preservation is an energy-harvesting, wireless sensor network. In such a network, nodes may be powered solely by the environment (such as through solar panels). On-board power may fluctuate as a function of the sensors on each node, the processing performed on each node, and position and orientation of the node relative to its energy source.</t>
        <t>Consider a contrived three node network where each node accumulates power through solar panels.  Power available for Radio Frequency (RF) transmission is shown below in <xref target="Resource-Example-Plots"/>. In this figure, each of the three nodes (Node 1, Node 2, and Node 3) have a different plot of available power over time.  This example assumes that a node will not power its radio until available power is over some threshold, which is shown by the horizontal line on each plot.</t>
        <figure anchor="Resource-Example-Plots">
          <name>Node Power Over Time</name>
          <artwork type="ascii" align="center"><![CDATA[
           Node 1                   Node 2                   Node 3
P |                      P |   -------            P |          --
o |  ----       --       o |  /       \           o |         /  \
w |~/~~~~\~~~~~/~~\~~    w |~/~~~~~~~~~\~~~~~~    w |~~~~~~~~/~~~~\~~~~
e |/      \   /    \     e |/           \         e |       /      \
r |        ---      -    r |             -----    r |-------        ---
  +---++----++----++-      +---++----++----++-      +---++----++----++-
      t1    t2    t3           t1    t2    t3           t1    t2    t3
           Time                     Time                     Time
]]></artwork>
        </figure>
        <t>The connectivity of 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"/>.  This figure shows a sample of network connectivity at three times: t1, t2, and t3.</t>
        <ul spacing="normal">
          <li>At time t1 Node 1 and Node 2 have their radios powered and are expected to communicate.</li>
          <li>At time t2 it is expected that Node 1  has its radio off, but that Node 2 and Node 3 can communicate.</li>
          <li>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 and there is no expectation of connectivity.</li>
        </ul>
        <figure anchor="Resource-Example-Schedule">
          <name>Topology over Time</name>
          <artwork type="ascii" align="center"><![CDATA[
     +----------+        +----------+        +----------+
t1   |  Node 1  |--------|  Node 2  |        |  Node 3  |
     +----------+        +----------+        +----------+

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

     +----------+        +----------+        +----------+
t3   |  Node 1  |        |  Node 2  |        |  Node 3  |
     +----------+        +----------+        +----------+
]]></artwork>
        </figure>
      </section>
    </section>
    <section anchor="Operating-Efficiency">
      <name>Operating Efficiency</name>
      <t>Some nodes in a network might alter their networking behavior to optimize metrics associated with the cost of a node's operation. While the resource preservation use case described in <xref target="Resource-Preservation"/> addresses node survival, this use case discusses non-survival efficiencies such as the financial cost to operate the node and the environmental impact (cost) of using that node.</t>
      <t>When a node operates using some pre-existing infrastructure there is (typically) some cost associated with the use of that infrastructure. Sample costs include items such as the following.</t>
      <ol spacing="normal" type="1"><li>Nodes that use existing wireless communications such as a cellular infrastructure must pay to communicate to and through that infrastructure.</li>
        <li>Nodes supplied with electricity from an energy provider pay for the power they use.</li>
        <li>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).</li>
        <li>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.</li>
      </ol>
      <t>When the cost of using a node's resources changes over time, a node can benefit from predicting when data transmissions might optimize costs, environmental impacts, or other metrics associated with operation.</t>
      <section anchor="assumptions-1">
        <name>Assumptions</name>
        <t>The ability to predict the impact of a node's resource utilization over time presumes that the node exists within a defined environment (or infrastructure). Some necessary characteristics of these environments are listed as follows.</t>
        <ol spacing="normal" type="1"><li>Cost Measureability. The impacts of operating a node within its environment can be measured in a deterministic way. For example, that the cost-per-bit of data over a cellular network or the cost-per-kilowatt of energy used are known.</li>
          <li>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.</li>
          <li>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 rapidly or near continuously it is likely not possible to meaningfully react to their change.</li>
          <li>Cost Magnitude. The magnitude of cost changes are such that a node sees a minimum threshold cost reduction as a result of optimization.</li>
        </ol>
      </section>
      <section anchor="routing-impacts-1">
        <name>Routing Impacts</name>
        <t>Optimizing resource utilization can affect route computation in ways similar to those experienced with resource preservation. The significant difference being that when optimizing costs the overall network topology is not changing. Even without a changing topology, cost optimization can impact route calculation in a variety of ways, some of which are described as follows.</t>
        <ol spacing="normal" type="1"><li>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).</li>
          <li>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.</li>
          <li>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 an 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.</li>
        </ol>
        <t>In each of these cases, some consideration of the efficiency of transmission is prioritized over achieving a particular data rate.  Waiting until data rate costs are lower takes advantage of platforms using time-of-use rate plans – both for pay-as-you-go data and associated energy costs. Accumulating data volumes and choosing more opportune times to transmit can also result in less energy consumption by radios and, thus, less operating cost for platforms.</t>
      </section>
      <section anchor="exemplar-1">
        <name>Exemplar</name>
        <t>One example of a network where nodes might seek to optimize operating cost is a set of nodes operating over cellular connections that charge both On-Peak and Off-Peak data rates. In this case, individual nodes may be allocated a fixed set of "On-Peak" minutes such that exceeding that amount of time results in expensive overage charges. Generally, the concept of On-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>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 non-critical 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>Consider a contrived three node network, similar to the one pictured in <xref target="Resource-Example-Plots"/>, except that in this case the resource that varies over time is the cost of the data exchange. This case is illustrated below in <xref target="Efficiency-Example-Plots"/>. In this figure, a series of three plots are given, one for each of nodes Node 1, Node 2, and Node 3.  Each of these nodes exists in a different cellular service area which has different On-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 (On-Peak).</t>
        <figure anchor="Efficiency-Example-Plots">
          <name>Data Cost Over Time</name>
          <artwork type="ascii" align="center"><![CDATA[
 Node 1                     Node 2                   Node 3

C |       +---------     C |--+                    C |-------------+
o |       |              o |  |                    o |             |
s |       |              s |  |                    s |             |
t |-------+              t |  +----------------    t |             +-------
  |                        |                         |
  +---++----++----++--     +----++----++----++--     +----++----++-----++--
      t1    t2    t3            t1    t2    t3            t1    t2     t3
           Time                      Time                      Time
]]></artwork>
        </figure>
        <t>Given the presumption that peak times are known in advance, the cost of data exchange from Node 1 through Node 2 to Node 3 can be calculated. Examples of these data exchanges are shown in <xref target="Efficiency-Example-Schedule"/>. From this figure, both times t1 and t3 result in a smaller cost of data exchange than choosing to communicate data at time t2.</t>
        <figure anchor="Efficiency-Example-Schedule">
          <name>Data Exchange Cost over Time</name>
          <artwork type="ascii" align="center"><![CDATA[
     +-----------+          +-----------+          +-----------+
t1   |  Node N1  |---LOW----|  Node N2  |---HIGH---|  Node N3  |
     +-----------+          +-----------+          +-----------+

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

     +-----------+          +-----------+          +-----------+
t3   |  Node N1  |---HIGH---|  Node N2  |----LOW---|  Node N3  |
     +-----------+          +-----------+          +-----------+
]]></artwork>
        </figure>
        <t>While not possible in every circumstance, a highly optimized plan could be to communicate from Node 1 to Node 2 at time t1 and then queue data at Node 2 until time t3 for delivery to Node 3. This case is shown in <xref target="Efficiency-Example-Store"/>.</t>
        <figure anchor="Efficiency-Example-Store">
          <name>Data Cost using Storage</name>
          <artwork type="ascii" align="center"><![CDATA[
     +-----------+          +-----------+
t1   |  Node N1  |---LOW----|  Node N2  |
     +-----------+          +-----------+
                            +-----------+          +-----------+
t3                          |  Node N2  |----LOW---|  Node N3  |
                            +-----------+          +-----------+
]]></artwork>
        </figure>
      </section>
    </section>
    <section anchor="mobile-devices">
      <name>Mobile Devices</name>
      <t>When a node is placed on a mobile platform, the mobility of the platform (and thus the mobility of the node) may cause changes to the topology of the network over time. To the extent that the relative mobility between and amongst nodes in the network can be understood in advance, the associated loss and establishment of adjacencies can also be planned for.</t>
      <t>Mobility can cause the loss of an adjacent link in several ways, such as the following.</t>
      <ol spacing="normal" type="1"><li>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.</li>
        <li>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.</li>
        <li>Nodes that can change the orientation of their communication terminals will also establish and lose connectivity with other nodes as a function of that motion.</li>
      </ol>
      <t>The impacts of node mobility are separate concerns from either resource preservation or cost efficiency.  Unlike with resource preservation, there is no expectation that mobile nodes are resource constrained. Unlike cost efficiency, there is no expectation that concepts such as peak-hours or other computation-based metrics need to be optimized. This use case is solely concerned with understanding the routing implications of motion-related changes to a network topology.</t>
      <section anchor="assumptions-2">
        <name>Assumptions</name>
        <t>Predicting the impact of node mobility on route computation requires some information relating to the nature of the mobility and the nature of the environment being moved through. Some information presumed to exist for planning is listed as follows.</t>
        <ol spacing="normal" type="1"><li>Path Predictability. The path of a mobile node through its environment is known (or can be predicted) as a function of (at least) time. it is presumed that mobile nodes using time-variant algorithms would not exhibit purely random motion.</li>
          <li>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.</li>
        </ol>
      </section>
      <section anchor="routing-impacts-2">
        <name>Routing Impacts</name>
        <t>Changing a network topology has a straightforward impact on 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"><li>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.</li>
          <li>Adjacent Link Resumption. Just as the loss of an adjacency can be predicted, it may be possible to predict when an adjacency will resume.</li>
          <li>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.</li>
          <li>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.</li>
        </ol>
      </section>
      <section anchor="exemplar-2">
        <name>Exemplar</name>
        <t>There are a significant number of mobile node use cases, to include vehicle-to-vehicle communications, swarms of unmanned aerial and underwater vehicles, ships in shipping lanes, airplanes following flight plans, and trains and subways. A (relatively) new type of mobile network that has emerged over the past several years is the Low Earth Orbit (LEO) networked constellation (LEO-NC). There are a number of such constellations being built by both private industry and governments.</t>
        <t>Many LEO-NCs 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. 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.</t>
        <t>A LEO-NC represents a good example of planned mobility based on the predictability of spacecraft in orbit. Unlike other mobile vehicles that might experience traffic congestion or significant changes to speed, spacecraft operate in a less impactful environment. This determinism makes them an excellent candidate for time-variant route computations.</t>
        <t>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"/>. While these spacecraft are all mobile, their relative mobility ensures that they are always in contact with each other (absent any true error condition).</t>
        <figure anchor="Mobility-SOP">
          <name>Three Sequential Spacecraft</name>
          <artwork type="ascii" align="center"><![CDATA[
      .--.                     .--.                     .--.
####-| N1 |-####  <--->  ####-| N2 |-####  <--->  ####-| N3 |-####
      \__/                     \__/                     \__/
]]></artwork>
        </figure>
        <t>Flying over a ground station imposes a non-relative motion between the ground and the spacecraft - namely that any given ground station will only be in view of the spacecraft for a short period of time. The times at which each spacecraft can see the ground station is shown in the plots in <xref target="Mobility-Example"/>. In this figure, ground contact is shown when the plot is high, and a lack of ground contact is shown when the graph is low. From this, we see that spacecraft N3 can see ground at time t1, N2 sees ground at time t2, and spacecraft N1 sees ground at time t3.</t>
        <figure anchor="Mobility-Example">
          <name>Spacecraft Ground Contacts Over Time</name>
          <artwork type="ascii" align="center"><![CDATA[
       Spacecraft N1            Spacecraft N2             Spacecraft N3
G |                      G |                       G |
r |              +--+    r |         +--+          r |   +--+
o |              |  |    o |         |  |          o |   |  |
u |              |  |    u |         |  |          u |   |  |
n |--------------+  +-   n |---------+  +-------   n |---+  +-------------
d |                      d |                       d |
  +---++----++----++--     +----++----++----++--     +----++----++----++--
      t1    t2    t3            t1    t2    t3            t1    t2    t3
           Time                      Time                      Time
]]></artwork>
        </figure>
        <t>Since the ground station in this example is stationary, each spacecraft will pass over it, resulting in a change to the network topology. This topology change is shown in <xref target="Mobility-Example-Topology"/>. At time t1, any message residing on N3 and destined for the ground could be forwarded directly to the ground station. At time t2, that same message would need to, instead, be forwarded to N2 and then forwarded to ground. By time t3, the same message would need to be forwarded from N2 to N1 and then down to ground.</t>
        <figure anchor="Mobility-Example-Topology">
          <name>Constellation Topology Over Time</name>
          <artwork type="ascii" align="center"><![CDATA[
    +------+          +------+
t1  |  N2  |----------|  N3  |
    +------+          +---+--+
                          |
                         /|\
                        \___/
                         / \
                       Ground
                       Station
------------------------------------------------------------------
    +------+          +------+          +------+
t2  |  N1  |----------|  N2  |----------|  N3  |
    +------+          +---+--+          +------+
                          |
                         /|\
                        \___/
                         / \
                       Ground
                       Station
------------------------------------------------------------------
                      +------+          +------+          +------+
t3                    |  N1  |----------|  N2  |----------|  N3  |
                      +---+--+          +------+          +------+
                          |
                         /|\
                        \___/
                         / \
                       Ground
                       Station
------------------------------------------------------------------
]]></artwork>
        </figure>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TBD</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner">
            <organization/>
          </author>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba">
            <organization/>
          </author>
          <date month="May" year="2017"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
    </references>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TBD</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA91d3Y4bx5W+51P0ji4ysyJHKynA7gpx4LE0spXIGkWSYwTr
RVAki8O2mt1MVzdHtGUj77BXe7fPso+SJ9nznXPqr9mUZFtAFhnAFofdVXXq
/P9VzWw2m3RlV9kHxcmrP74oTl+VGzv7o2lLU3fFi6bvyvr6rPjK2eKhcdad
TMx83todvd7t2lnv7Gwh3y9MZ6+bdv+gKOtVM5ksm0VtNjTvsjWrblbabjXL
hsz+5V8mrp9vSufKpu72W3r3yeWrx5O638xt+2Bya0lT0j+Lpna2dr17UHRt
bye0+P2Jaa0hIBTCk8lN076+bpt++2Dy2u7pt+WDSTEreDs72Q5+1/fx8ctm
XlZlt8fnz1tr62LRbLbh8Qvrmr5d2GJjanNtN5Ym2Nm6J4iKQlYilNH0xQBb
J/RcdnPyNQFF39D09Dq+35iyEtR9CoScNy2/btrFmr5ed93WPbhzB2/hq3Jn
z/1rd/DFnXnb3Dh7h8bfwbjrslv3cxr5zDjzqKvxYDZvVildTN+tmxbIoAFF
seqrSuhyuSw+K9vW1JYf0BqmLr8zHRHjQfG7L766c/H8KT+xArVd3ph2eT6X
MZ9+u+7Ntjq3y/5w6mfloqmMK37fr+uRyV+tTWVdcVHZujTFy61Z2HShWkaf
v6bRvP9Pr/HgnMhzuNSfCL/frYl4f+hHVnrcd31rb2xZvLKLdd1UzXVpXbrY
Xsef/6X/dOXf5qUmddNuaJ4dUXwCno6/TWazWWHmrmvNoptMxmSGJOmPL86K
1q5s64quKbq1LRamWvQVw1Y0q8IUW9OtCeSC5IA/dmvilOs1PaltB5Yubta2
tTy4A6/RqI11jhiSZMHUTqWnOKVJWruw5bY7K0pHE7cdXsbAZmdbU1UFTd1Z
ZXKG4ZwoQe9uLE1Eb5puWuC9bk3wu2JusQ37l95U9H0B7ZCMLTbl9bortm2z
7ElIluWKNkoyQlC4vupcsbRbWy8xBb0c4McqgopkKsBrWyDYLosb4mkCtGjo
rZZm6eyiM/OKRqxNfW0DLj2CumYLsu6BRhmzaFxHHFIvMLkrjHPNoiRVInPz
YEbFOVEO+ydN1UO8SXF1sh1XkAAVLEBKgMHuHf3SV8ui3BACdjbQxL4RKGmq
SMNz4ZdNuVxWdjK5VTzRdTDTZHL5pnTMMZ5znrdN15AIOJpuS7vHjolZ647+
o3Xrzm62DWSw6d20ICTPumZG/+BZTe/TRsFMtPNF2ziXAFI8THFIlNAR5Y70
4JS4cEGs5xhDFUaCR2kjy29JQgk/W2tbYoUW1KtduSTELDHVnDdut9iPqYpF
2RJCXWdqYJLX2fREkjnGta1C2JZEMKUleGaz9WJBat9k3E1wyzjG/MbsCb2L
ql/awnRABmONpmrtzDowS+nW2EDnQV+Q0NNOlhARL4JgTMjMsnQLSAi+MIFt
aBuesYh8XzQ3doe9d8wMwICBDbjBIDFXAHzINAOObZW+gWN5nlqpzFQTofWs
3ZBUCLudE89gjrAA5tvSfreVIQouhVyyQ9c1bVQxgXwLIjBtWNVYfFp1tq1J
OtL33Jq5mwjmYBcN81BTzwhXbb+FEiwIH3XHEmTjBhiKU4Dh4YqUPcOCVVm/
JtmhdZvFomdoaGrYZ9vt8QJZdef3q2hwIrYbmGsS+2ZpXWTVvt7IQoYoSETb
2XW5qJTaroHGbOclo93BzizgjDD7drYSTUyzCVggh3AN4zHyEqZ3CXN4xbpR
D8L/TpvugN8R8KHRWluVrMnMggSD2WJLjNXG3YQha9PurGgFW9uWeGXVNhua
iSCTnZGDIHDTbCK/qpHnLE5dWzJFaI2FbVlzQP86ka/9efGy3MDJqIjaZQIr
iyXh6zssfZ17RbyygmNXq5KkiriFzYvILLGdnUbFTKimlyJYnicMCUKcCdra
gTMDF5EY6YS7piLN7A4U9dKuypqlgCA8EDtzaOkCELUF3GTl9kGHiWEKBh7q
5tIQPYSoLp1f1Y6I36qpKtEA6djJ5O55cVEzVnalvfG84Sch2N2iLecYt25u
DkF1CquzFXR/NKyi00+jt+DORtiS9nLOINAErEzI/KkEQnWSzpzvc4BMNKkG
/o+H2NMRVGdqeOPG878kYpUgL/RnL06IGnqv58g4Em+6IQbOFUP2DaluYkHx
hPxqRBVGZt15qOI4VjaBCWAH6gZiRYrQ4RumCnmGfuspU3RJICBI9zY8YwqB
OUCjbgksGYUENZEzMgPUReBZsYLX4Gn2NFgomBhFKmri+dSLltwaGmwIAVYU
BAmhBddFsrSWPTPGA7yMcqnWgtwFC4DoS9rkALtTxgkPEaSYmqT1zdqQBWa9
TebKRvuwbWiuDprTQ0O6q4NHVpWvbbUPDhtvllYmU151Jb3oB0TdoR6FWo5F
ZcqNaM6y9s4A25w9xS1kPVLC3iILX8OiiMdGHPcIIl7y70J3iuoKhHWuOPny
q5evTqbyb/Hsij+/uPzDV09eXD7C55dfXDx9Gj5M9I2XX1x99fRR/BRHPrz6
8svLZ49kMH1bZF9NTr68+BM9AVQnV89fPbl6dvH0BFqzy5QSCCZsQK6abbeg
MbY/UYmnX2jMZw+f/+//3P118f33//Ti8cN7d+/++w8/6C//dvdff02/EL/W
slpTEwHkV6LAfmK2W0vyAt+SmHxhtmVnKjJfhGKy2Dd1ATIRNv/5P4CZ/3xQ
/Ga+2N799W/1C2w4+9LjLPuScXb4zcFgQeLIVyPLBGxm3w8wncN78afsd4/3
5EtwTQjSn4Pb253w9fe3/Pez9PsfJpOX8AjYhcg8dFW54m+x8976CdhVaMl+
WlisXdk2NajtQrhxUxIbs4dSkZx3TGV2qaowiYMDq9PQSG/tzQ5xPhwCdQMw
3Qbj2G30PEABPcXdBbt115adJ5BfNRVkX+Srk4ggcWHVNTG8Y/ZJ4GGW8H9p
tfYwwQENLtDxEF6rpQiwbDVy875EvsZcdwC9J6Fos1qdQRjsmw6BCYA0ua/E
80NNMUTlVvGeGB5i5K8R2PPUmFiBIplr+7qGhSH7O2XHdAGfhVz7JOxTY8RD
ggtC9g2EJPCw2MrsGFYFk515vF6VK0LXhXrGpKuguodbdwlIMEX57LQzA/cg
2ysU3oDoEra4bVOzDYF+hxqMLiFbXgoGKwl/zgvGSUQFQbQEu/A+dmWjoY0J
zBQYuAOq+CsyHHBA8V50zshAiIYKWNEgjJUwAxfmdGYF75cg6EllV/C47HXP
tlxCFpqZ1l2WPrwnNy0607qHqgHBPFsHWQFxhbAmJd5i3TTOCk8hsaDoi8Po
yaqH/VuS4wQ/FOGlBJGdYJHpkpBjBeeRowKOQyT7c4DwyeQJYqhlQEMurCKl
uoupZiCCaC0SsQeTiAmNjMNUDjmRbarEOBjym4NtoUAdWYZ2H6w7xQg8LroE
Enu1oEJg1LNM5AYyVjxjZRjJVoY409PPZc5zJ5HIQT5E0wZpQiFb18fCwTHC
iBDw4o109+fQ7reKi+i7khPQqKaKOjFXQwfOcJS1gMnIVchIUBhiW+jOZRBv
Yh7V7yvxzzMasIxIeLhF9lLYWRwmdrThCoKcW2Qm2jo4v4npAIfuysAckgZS
Ze8DfpHbVXndq6smjMNmxtacIlSJ440zB3oFG1QPvEciKXnEEnrRZ2T80sgl
DQ7Y4USAoFmy0qUeGvnsv6/hYwTeFjksITRuFAeJ1+gkFkc2r92UtdJE4+91
uSXm6m4QbGo2yKM8EDCKjFF7Et+qrV2KCz4wJkni60IG37B3igGsjyP54WUV
xNxrg3xoJ+BGFQb9ECcXOWENsyRZ23IuCSnL1TRdk2PWUrZ+A4Q4CQRUfpcU
oXM6CMZxQyExi8KcGWfPNqio7Eq1RWW2XbM9ZHH10lV39UhCcnz1XObPmB95
h36j+edjFMteypVQQoPW+h3wClGNZTpb05eslObwACrWu6Q3Nn1domB0FhCf
RBwNofAN4rpvm5yIEaNHESmahSRlXbIb49GZIvGmJPdpLqHiHoqpvSYpBtbg
pbEq7QZJ5FFsHXGgom327I787mKg69Mxq4DXIXnHhI0lIKNS6SSZIZCrfgDL
cn4oyD6rVJ9kfiLB+WQyUueKRsAtbE06pvE2oKx3TbUTT4e5nkxqqjGDuk+U
e9DWI/hifQSvSEwG0rTs365WnPvgpJLPJtR5pvDG7J3opefsCbw0O5Qtzour
sJ5ZMuTHnTOx1mp9vE/kqyI0bI2Ii/MabPSzYECUuBt4uZn4pgiRZLcsa6L3
K/kFzVQyNLISYgiiKFBt3GtmzlfqfP2EjZarJGOdOoTIe5kDPzl6nUSDElkK
JCJKz9J/++t/p54CMu/43LeaEVJP7kPhq2M5Ztu3W3h3QJi6bLzEcbctdx7F
iWPVwn4bZ2owWGMIJO8Lkyge3rma4Siy3kcpiZl9QEPmobOKxVLz7g3xiRrb
0zL1rUIqhyM4Zv7AYXnEeRY1QSxg5Xk3SDUDtJyqOvMJNc0ZxmKiC4XDzLe7
UK8Vma0pa1pFBEML7ZoUh3SPSiQDN5o/RruMASL0GT2GuUIkeHxRRfNHmLQz
rzkFvPCWX2o2GA0c95n+YFZLajG1JfUzb1oKAsjfetS3qu+daHxy60iMUJ7W
WQEH+6mHISDvC8UWjfhY9Ny+XhAGfeFYVOWlJignk6s6pruybKXkFoW87FF6
gQ66LvPpS5YsSXzPYo6faEMRdoWaABodSFUEEj6JAbl8NfWrmSzudk0F26m5
3cTbLE5jVU9YhGsHpJ1rW7mzREoloMK8q4qc0p5rQmNlD4GRNQenLEV1SAAT
AstY0M1f4wCl0aCSfV7S6HVn0gWYYMIkO2YxCKSWCwStRKCHPn1vuCba0qtL
LQjw+JxEAYJoOa3zIfgIYsjZELMSXVAY1BfQZMVj5ES49nH64vFZXogvfS5u
bqHqSea//z5koy6Fh2bPq6ZzP/ygVT0awp4+YcfGwkOyF1ecIkwr7k45XCvu
CRr58/0zslI7FthYKaDp8/hHcyhJUpptnOdpcWtc5sKxl4RcsowFCViP+5B/
MHepoR2LE0AnLFRRcwWsCIOuierfEdVItMlHsYFHADnR9scffySYFmXJnRr6
IygoDn8EJ8ce3J88L96OPKQfeTCTn8MH+jObTRr8nrwUPvCDO/rLN8kMTTID
Pf9mclO8/fEO7evHb/A/fKQPeBoe/Bifhgf6EwdObPH2TlzuTlw3PhgAYwMo
fuCkjdCFTfE/7QBVATP0YIAn+kjUuU3/3Mb/4v/l8U95oFTumLgdU7K7n0Dx
gQ9SZuHGrLGfdz4A402+f0DuEuuOmanK6/qTEzQ/2PYkfI3urk9OmEFPilvj
0l1wV90nJ8yDokquIB9Y5uQHKWkcJktKN6bCDnMnpFbg/0brOs8DMrbDKGdL
SOUjL+7ACMEXx8ADB4VBcBvDRbTcFF36chUqaynkWEike1zbvVys7bKvLBSe
6B1RdzwIBsYFy5pUAZP5O0UKm/oHRHWyNqoDu/uodxQXnbYX3fVqIijIe6If
aZtl6z1RbzU9mtIyXoKg83TmexqlxneBe6+UkDeIKpJc1mkx77vknXuJyuYY
Z7DO41LdNOMXvP+uBRNfmoOjdGlNkYyuzIlEr9TViYp40dyKuLp1o0sH25xS
JdPSkyDZ+nPbS9X7vpuwCL+N2t2rmdnbqNiDTvLfkQ54+wvW/CXg3huAOwTt
3sgW/o7g3v8AcD8ydj+KDvU6w6vRVyFISpXoreIqhKOXsSPl+1vh61n8+r3l
P26FUoHQJ5h4bkmBaLNasyXZLL9DZR4dNuPNhZw6CkmdX7mY1kXlA01Maf4y
jxCGbSJSkkmUalbQ/AGFCfoC7QhaT2h35Q5ViSx/65s0+LV65t+KXTxIvKTd
fyvSRjVaImQzvHOpjcYMj2Y8kljDhKrkKYadSU+caBnSRlyF1KKeOpk6q9PX
2HlEW5v1PZFlvWqNZMn7NonDT4l/UPCr9mc+V4vGrRFq9JpXAAT5bOfFSzE8
0oLkewrLzm4G2PD5csk3ScmEJ8TkAdYQxA3yDCGpUixsVXGZbLAtCR3NfmB/
fCQbg/vDPUSAXL/dVqXfOncPEYvCgHIkHAJP30zS8oqIaiSpIaGQ3WNT54N9
EmZcx621saVK0pAhb+cThJo14ggmZojy5GANrkb/nwkZCiXCkIKLpql8bpfH
orocq3O+eESBLCD+zO5RSM25lxsknIalRzkWuZqgS5Kyrqkc+02odla+EXCU
2RKG5oIO4lbfprpYl3bHVVHTzgnsBXy1pIkAb6L7ZUeIBEUGnXdealLtIhIT
dExM0x94i6HmBbcjq+IlyXPOwx903rrQGaF6TxE6hkI3jds5ph6jJhyp7yVN
AjGxLw0OgUYH+y0IQZWmbRIHecuNp559A/doMUqzdEYbCZd5wqQZyucZaQq2
HKECi6IBQUQuFFL7PnXlbN4iIh64kzYg1SKas34IKn5JkkLT66alNpc0zR3w
o4It2ZAIsJAV5T7Mtix0Z2nt4QYtn4+5yZJV3rRIGvFdN6OVZvOyC93XjSZM
vb4KHcltPuZ1SVsyHQ9U7SIlUtr5a5QLz8NmQ0VKN/swb45O9j1K2jAjb2+5
Qz/ZYEuaivUCovCgsASlzBUUzqhrCRyNFmqbiPNDShHtsb7RO61dEgrFBw66
nd8PWVrpkBAbF/ZsW63KHOzXQzmsvGeU3cp4bZN2vZrrLqkXMrfH0lJwVpQp
zPLb3klTkvaZSBMFwyxtGrTD8+LJShWwbqY123JZ8aGKGj1nSLGVdd/0Dk2S
ablOoglkxCXGjFVnekjMvfCNnORVJf2jIgDmui67Hs1Jr7gmpr8Kol0XdBmH
mMMio7N4UoDJN/0mJp1kKLGblNZFZcuxFME467JEDR3UxK7kFXw3yoxJjeqw
1djH5kmRsls3TqJMJDsXXhuOuoCCCkdOM9pr0f/pE3v0opzJYSSwwm4ioEK+
Ljnvc3BChoO6LtCeQnq0Yfr2dBOZwo+YKpsmGOO9qz4+qEOMFummWt1a+aJs
m3q3Q8X4FCXLxyVccQbxEdRRSN7H5O0yqdvcGOnwFzFh5WSZOpw+hoDgycix
kif1ktyXZS9pyNeKw7haTehKfRHXpb3eKUcm50z4XVqpaWZrmkmGyZzA/ly7
SFZyGEOLFlp0DGCjps9IcB5r6UkW34lyqoI30vvC/hfFWEGlC+swyZbqLfUt
dFRoDXlS5x3T3tdWf8dJXe/Apq8sPMeq4Sa03Hk4JU50PYoV9V6ySsNXzkI9
gxHUWvRwcZVPUCOw+y6zRAMm5wO8mqZRUHblal8MCI3dXmYui5peqUEnjq4a
UUYfTr5pZq7MGcX5DM6215DIy9zQO5MTGqNVFJJwLmGSZF93IeuPAayOeaQH
gRv90t330gqX7Snp2ApFn0XV9Etp3RBtsfC83gjNEBpyc3bx4vGgkgH5QoV1
cxYtlnaDDjNl6nkp/CE71ZA5IECmbGthn+PJl0EEhPJB6KbllQdG259+xOEV
bsmz2RkNZtxpaNuJBe7QgJUcWFkdlGzCsRffuh89dpM0zcZjLudF8bVqHWHO
8MQHMnyYiGMq8xoyC5elM1IVDgeFfHiMwwlybFfmQM+GK/721/8q5k231vaj
/cy42b7pZ9eNLMcRWJTG9EDNeXEROkR8IV1P0/AwbqfkBtAGwdl227RdX2uK
lU2Wb52UfmPXeAtKxBHS+NXqcHZvvk8SifChcD6RX07bQtWfiYelflaxVc/I
2NdZWmawDisvPQxSDxodmczBwfWpzab2ES+3BQn6r+rZc2ukun21WskvgeAu
lvHkAEaiLLJaLZo/JO9O2qB8g6qtgHaiC5zAl+GTKdGy4GClXQarP3D8/GHb
sk5EhXXRtdUtEHif87GUKj2AYrc8yejOPBBRrXIwkWZTjB7hCHX/TjnnJoSp
w9Aha/AiOcQ+aNK1Nbs9fIgq8GdQXolTjilI9MlwTX7Xc/ANmV0MTl8Jsy46
0bgMdRtDOo2wz9RPWPcbKHEPJ06dadrs2MxcPiFvrBR/OlZgWD606RKao7Y4
kqsfi9Mv7315lnNYk2iciPhB3ghghsN7ZMpdsOXhJBZ50GRZaf5w2s4/cqFX
y0kqVU8e+nxNcugQooTegb56DadDT5bj3Pq02PZuLZm5VXfDfscWtzJgeGiZ
8AoGtsIfW3Chnz5pzufWdtE/5F26keYv8Wx6PoplKooelnsPv9gcdvaBNJ8S
IKpAh0oOlDUbsQdZAQCPCkxQX3N7ZKbUdH94X8E09+9Rwia1XbI1G+ZsB2X/
qZ6W9vm8qDvyxDA/Zmc6K/25Io0fJWLNeOJVmA5uQ4XUnRxKS1oSYlr8/U0J
UKECxEoRseUKJ4jFamDKmwe7eqMseu940wKZz/yMpQxQjSMJjNDOEEQUMRI6
tnD3h7rFqLvFN9+tqEVFJX25vmbJUGtNEg0KA02mlgS4O/WznhWhazh9hx3+
UwXjLO9kONq/8P4OhsnDUKWJpRb+9SGqTbdHRsqTWVqYiT0Jg34IfjDaI9EM
vn47cccmcUcncQeTdAG2AegdXr09G/yEJ8mPf2lyZNERCDMQRhsRZnHqD3vC
/7yvfeEDn3xoB8N7nvys+tsxdeDLbxyFc8oma2L4nJ0Af3TFu4FyAAKiJ5I0
lrqbZkosU2CSmlZp8aUPlRDStUkJfR6TDziGkTYoiFbJ5nXDRoWRTaetCo+l
fzBRhOwMqod8V9sPErfYhBB3fF+caAyO9yCAEoc+NBu8u7yeis2HfJ1X2Z9p
mf3p1dd4Gr7W0vUXTz7/Iv16tBz8kyH4CHtIS+9+D0Ng/7/vIa3Hv2cPSp+P
vIePpB2G9XlWEJee01lTZJV6qXtnueKSzzqimJLcFwNvA0YUqWcN6uQykXiw
fCA4mbZoQstLbAjSQnVd/KW3fRQ0fVGid99xw3lCW5XSutwEbyVzqd6jQuAF
k/446GL8uIL6E+Ys3vHz4Vx75OfDufaXQPCxuBa0ObRpkoTR8wvg1sktuR3O
Fo/klEfetYAQEY3smoPWm2l8QkNM27G7YeQ0FFIjo69h/jNOGCwMd2/kVaNj
ZwWSzt5X8iafSelimS+0U4cVfWs/Z5E2TX3turQPMGk/FFOrp+WaZnlgx5Mk
VLiIKBz4DWeckgx2GpX5a2EIOyQ0/lY+ybAyDroj11FxqpFAcZYjOF9seHfj
Rtx/vkBIg4YTDzeNooMbJxfILFacE9IDVoxaP2zG+EVqpyO89z5n0Pu7mpLb
izBf1bhB+6eUx2s+KCQ5uWFjZnIwfnQvHp9cGUivDDMxaxt2yVpTa/XJxUoH
x4NFb2+aHR9TAFPxzQbD+ndk2JRYkir3LhxufKp8M6FvFFib7wzu9JCcLMoF
knN1tEBelz9oSWFnSh0rO3KMoGzzhEqhZ08rJ73tjK94X5hkJcbJkpBiJJeP
skGj1cRBCb/OqMT+p90aTRMTHXBCmElhyy47OJ4fBVePMuawKX7+qkY67R2F
RF/EPmzlVJATsgOyw0PrcKp1mcH675lbM4yx9QnRwGxN07v0mr5QM53NDZjW
d43487lzG50AtcGho43P1fKZF0WkL0fFQ70+d5jcR1SF5BouUmSiBclNVK05
qJ2O9Ks8z0+exh6VnOiEk8MasQqkthakecbh2aj8TqbIStp9lz9Oewek3keS
a0MDmbaxpMtpn8xSjjGWMTcvF2xw0na0geU5rqsc9nSA++VKy1W0i6LzVAkM
e1doAQkNT2PPgnb+2OXI/VanxF2VNWguFHMnvQhxGwesnVRY/PVPprpG7nW9
cf5AeINE+7pEC8yW8InOBcIwyaUX7IMCIg7DV3aJfBu7BsldMLaqZvEqxgyY
rXFRIY5dOSB6a/T8lhbj4CF3Pc1eTX07jp6mOZP2PejiA0UmtFn2aVFMjg1H
XcdqOz3k3CQRNmePh9QYqLfDjlDQ21arI20WD32/waG8cWIPOyY9dL3ufDU4
Zn0lfRAlClW1kQvSstbJIMzDq3AyX6FYWRYq5/kReoMp5HurQkFqeC9hUrcZ
3tsWmgq0apxeESZ3xnm3hjsgLt9sS98zfDE4wehPc8QOOZQgkosexb5ZTDF6
hE97cX/lAu0EBdHOZY8aPdWVG/0RnXNO7rJ2nYV6VQoWaCpQLaVa4kbv6sPW
EPFJayoEnhhzihTumqtQaNeyK4Osi16Z07Zy/a0cOd1YqPLSbc4P8foipKnO
C19IGvcvF/sDfTSFtgkHL2PLkycEp4MPCSG6iYHhmOMFzP8FN2ax3ItsSsWZ
aRsz1tqHJ8U28Xe1h6eRO5+yLk+SP0C3Q4di0kA01h7Cqax3xATxHDYAkJtT
bcnQONZwHnGHJieOTAxPUJdh8Uxt5I0McuZaum+RdWeTpNY2uSJWOselDsCX
wopyYAOU3nJ8yAVJf9FL74+F48L5bVpyjd6C/XIz14/De1WP3zgZry0C1fgC
qJQ/ylXeP7QflElFhINTbsItRShorg7uzYgdZtCdaQtZ22wxTWDlpJNhUH5/
lVxxm04Rr7lN7Xofey+Sfme9hRVFUP04qG1SmEb6fMMiN7zCFfzATtyNAfP5
G11xK2255QgFH/jSFdISXHAs2y1/TJV4JfdTo5FCj4rBpdWLYfs5Xx9BqvXU
CwFOEuDaAN805XcZTscbuR2GLAHuC4kdL2TTuxCD7olGztfonhLvXpKZWRdX
uIS2OH16eXXmZ7TL/Bpafjp79vBMbnrwJIhoZ9uS31yrEjfviZ9RuWLB2rbl
Ti7AWaLyJwJ2DXClLRlBNqrGspzzx4d9OXNwB5HvFFgTSYh5HGiKfkFHszpp
jYqdB8kVuzFGS3J1DJ8/mUF+Dt/Nmxzvd6l2WcItZAW/5/v25ZKjGGSws6M3
dIirAu/Kt3aIUh29Y4gvtwgtGgnMcntB+nCwrqQBkht9IPCVfQNwuYiYTAaN
xBc4zoMaB3DEUoNJpRthRaznGy+4xVU9gwulU7zmFKr8GlmYpEnG51CiIueA
qgnFmcRNZ16KcJa1kCGEellWINynLI51uNZHtYzvOlig+8/5YDVVG0lU5bYW
NjRZO7lwURu+RIfjyqrMr5Drf0NLO/nl3FRFkMrBljeoEWsv/LJcsj5v2pFL
X7NLy9JqvxS2E9hOn6Fy7avW988S3SJVbkaT45sAOr08VtDtjL92ujjtkjug
pHKEVhduAcIdzXKbBm71rFx+4xfOHERgnt0jU8j9Jj6rM/Dd9ZIETlqpMCWb
mSKVfBqO4s+JqHwERzMnBOmZbjN5y6ytGbzkE+HZ1WSDJgPOi/ss3uzl1XPU
0sKxN5fhmFUcSbsw21S1wqFbgr/+0SaHOfTqdMGIXooP0y8nnyJ1Ttliyx24
+NMh6imGRsmzkbsGzmez89FE9TsfkA29dWv2Fnh+O8PnovjNbDb7bVH4B/eO
PbivD3T9b/785zujy7zzwc/KkKdUCgctWQ5eBrZOuBCZ8cfVPjTPmaEmI+Ft
uA2H234SMqryjFfJ6EAfMSYsMSvwdz38xcPxsuDBUuxYe/VKHJBetZ3Mpgcn
KEDmwxRls/Stc2IftEDt7wsb6nDYL2dtCrKLf7Mi1IEkv99I50rC/Fp2GOup
0dk844bZQkcJ3+GhHSWig3B/2eI14H/v4OvWbNfas5IUsqdkW3U/uI0uUS/3
w1Y9ZUL9DEpQjloMH6luTOe5O/7m/bE7PV5m45KfXO8de3J/8vmxBo+jD/Bk
MrzjAqUmLjylD25nxSh5cjtvotEf3/WSPsg7YeQJvpv0x0b3R0f3cXQ9aOkB
iHytRvrgdqydhSe383rabDZZHkPR0Qd48pG6Zj5i08zfsWdmKOZegyZM+rnI
wUMRVJc3z7ws2YMaUS2qK7x/B/mWRxTYTw+UFKtCTiyyVi67qfakhFvz4gG1
tKwXs2Fs1EPmzf8Fm6zQPdzszB/Ih3K7SJQFNLb/azgERun/AhCpGP5DAnzj
lR5/SfYeqvua6eNaFf7kiwS2h1hKVr2npxnZ7/JrZzd9TjmoJ3dmmi+BCv+9
2CCQPZDlzovP9l6JTaN3N7pKPrf0JUjLUtKE4KManX6oF28fK4RLawDK6ukN
E1JoDzX28dG3390E8I7y/J233xx9SF4HuR3HhxZHh4pUHHv6Uug7mf3in/cg
9PAbbjECQu8eoPhnIX1khaP4+gcnw+HPTyPMaAfKTybVOBTjpBqB4giqin9k
4n0MyxiMhTeRD7PEV3iamcfJLYpCFj1fcP0wu7J0Mnn12SN+4cnFs4vDh9lf
5UDKrm7kTbPwYT//QbY5udOY5WLxWrPTnB+j7UrSzS4/OVmZysl9XbTk/wHu
gFRXLXMAAA==

-->

</rfc>
