<?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.36 (Ruby 3.2.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-tvr-use-cases-01" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.4 -->
  <front>
    <title abbrev="tvr-use-cases">TVR (Time-Variant Routing) Use Cases</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-tvr-use-cases-01"/>
    <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="July" day="03"/>
    <area>Routing</area>
    <keyword>Time-variant</keyword>
    <keyword>Routing</keyword>
    <keyword>Mobility</keyword>
    <keyword>Green computing</keyword>
    <keyword>Resource management</keyword>
    <abstract>
      <?line 45?>

<t>This document introduces use cases where Time-Variant Routing (TVR) computations (i.e. routing computations taking into considerations time-based or scheduled changes to a network) could improve routing protocol convergence and/or network performance.</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>
    <?line 49?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Existing routing protocols are expected to maintain end-to-end connected paths across a network. There are cases where the end-to-end path can not be maintained, such as the loss of an adjacent peer. In these cases, corrections could be applied 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 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 non-disruptive event.</t>
      <t>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>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 use-cases that are considered in this document are the following.</t>
      <ol spacing="normal" type="1"><li>Resource Preservation (described in <xref target="Resource-Preservation"/>), where there is on-off link availability over time at the client level. Time Varying Routing can exploit the predictibility of the link availability to optimize end point resource.</li>
        <li>Operating Efficiency (described in <xref target="Operating-Efficiency"/>), where there is a server cost usage varying over time. Time Varying Routing can exploit the predictibility of the link cost to optimize the cost of the system exploitation.</li>
        <li>Mobile Devices (described in <xref target="Mobile-Devices"/>), where there is on-off link availability along with path cost considerations between nodes taking part of the end-to-end path. Time Varying Routing can exploit the predictability of the link availability to optimize in-network routing.</li>
      </ol>
      <t>The document may not represent the full set of cases where time-variant routing 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, 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>
      <t>The document focuses on deterministic scenarios : non-determinisc scenarios such as vehicule-to-vehicule communication is out of the scope of the document.</t>
      <t>The document extends the notion of cost of a path by introducing the notion of its time-varying characteristic.</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>
      <?line -18?>

</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. There might also be cases where a node experiences a planned offline state to save and accumulate power.</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>Node mobility can cause the distance between two nodes to vary quickly over the time making it complicated to establish and maintain connectivity.</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>Mobile nodes (like any node) may have concerns related to resource preservation and cost efficiency, but they can also have concerns uniquely attributed to their mobility. This use case focuses on 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. 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>A LEO-NC represents a good example of planned mobility based on the predictability of spacecraft in orbit. While other mobile vehicles might experience unpredictable significant changes to speed, spacecraft operate in a less impactful environment. This determinism makes them an excellent candidate for time-variant route computations. It is worth pointing out that unplanned inter-satellite links failures could still introduce randomness in the network topology.</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>
        <t>This example focuses on the case where the spacecrafts fly over a 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.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document does not include any security considerations.</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"/>
          <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"/>
          <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>
    <?line 361?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TBD</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9196ZLb2JXmfz4FJvWjM1skNZIcMT0K2+0sLVXq1taSyg7H
1ETHJXiZhAUCNC6QKVapKvod5tf8m2eZR+knmfOdc+4GglpciuiJzrBLTAJ3
O/t2Ty4Wi1lf9bV9UJy9/ePr4vxttbOLP5quMk1fvG6HvmquLorvnS0eGmfd
2cysVp29ptf7624xOLso5fvS9Paq7Q4PiqrZtLPZui0bs6N5153Z9IvK9ptF
NmTxX+/O3LDaVc5VbdMf9vTu08dvn8yaYbey3YPZrTVNSf+UbeNs4wb3oOi7
wc5o8fsz01lDm9Adns1u2u7dVdcO+wezd/ZAv60fzIpFwce5luPgd30fH5+3
q6qu+gM+f9tZ2xRlu9uHx6+ta4eutMXONObK7ixNcG2bgXZUFLISgYymL0bQ
OqPncpqzP9Gm6Buanl7H9ztT1QK6PwAgy7bj101Xbunrbd/v3YM7d/AWvqqu
7dK/dgdf3Fl17Y2zd2j8HYy7qvrtsKKRL4wzj/oGDxardpPixQz9tu0ADBpQ
FJuhrgUvj9fFN1XXmcbyA1rDNNWPpidkPCj+6bvv71y+esZPrOzarm9Mt16u
ZMwf/rIdzL5e2vVwPPWLqmxr44p/HrbNxORvt6a2rrisbVOZ4s3elDZdqJHR
y3c0ms//hys8WBJ6jpf6M8H3xy0h71+GiZWeDP3Q2RtbFW9tuW3aur2qrEsX
O+j45V+HP2z827zUrGm7Hc1zTRifgabjb7PFYlGYles7U/az2dtt5Qqi9wFE
QuTfd+16KOmEhIaC0VDcbG1niynmIpb74+sLpT3etivOq6VdFp2+kD3qDVMU
LdIWYIxqbTv/CLOvaLk1QaFw5ZZwU9Mv5dY0V7QHGmGKxvZgFSw41Oui2u27
9tqGtei3viXwY+5r213ZhjjANOs7NKMOLfa2Y2DQo6WAYlet17WdzW4VT/Xw
2NFs9vh95Xja8fSOSN4W9v3elj3tkHZG2Gh6+n9hm/Wibxf0D/bQyAt7029p
TNm1zsVDLImSAFbMlYK539p0Ggym503RtH2xsmEpu54Xbii3BVEqhtSYvN3Q
cQuz/gsRJSFpb223pFPhBY/MOW2s62wpUBc40rRmv68r7LWrCFh0JMzZWTfs
9ngTM5NAMyTDTONU6i2Lh8lUO3MgxJb1sKbZ+t5iIAGNpurswrrerOrKbbHP
3u+wJHIGfuiN0tTlUBseQhvo7LpyJeG2wxeGWKbhZUxNE+7BCQfC3nftjaVX
5tgsQa4CdEm43WCMyGHse0zHCUXxIRW7fl5GCEEx4Hdvuh7zeApq955oE9jG
RTDnno68rw0RwFoQI4d0fSsjc0SVhznOrDwan9a97RrSIul7busx5iD0DRNU
2ywIXN2wB4cXBJKmX4J+9QDpgeWQgDtoqi3LgRemWaBnbH/A4qSdnD+enpqA
R+K62EHtWFpxDUry9Dc0OzmrIXwRiq7ttiprxa1rScu03apiKDvIyxJKlQVA
b+taYDkv6qp5J6wlNMIgi5SD6V1CCtgoYL1TTeh/J7j3AOXE9gnTNGVd0YQE
1JKEHANlT2TUxdOEIVvTXVsRAbYhcXIoNl27o5loZ3IyUnSyb5qNYI9d7Kqr
LTMq0N1VXkKUtmMBATHnhJsOy+JNtYOyrAmxVbJXZkKC149Y+irX7ryybsdu
NhXxEBFGAVYRDiUKs/NArMSveCluy5OlIbqPM5UEcQciDFRPBK0TXrc16Qa3
HKuKtd2QGALB0w6PuMwwY9lU/odNNBb7NnV9CFqAAVMERQXh8tgQPgSpGYOp
kBFO27R1LQyfjp3N7i6Ly4ahcl3ZG08bfhLauyu7aoVx2/bmeKtO9+psTeAo
1tVmQ4eCSGVZfg4VNaz4l4sJsqSzLHkLNAHLDuO8JIWgJAm5OuQbMkEeEceT
Hvc79ngE1hkb9r2wM8//hpBVAb2QlgML5aJtMrFGOpJo040hsFQI2fckqIkE
eZNhNcKKKMne7yqOIyrgXxde3JledJhikmgHdJ6RilG9FrAlGApW6itiFsKU
UMm5Ikcm+ukn/9Yifevnny/mUWGK8Ccx2G42yo/XMEO9ZLj2BEZ7xT5K0nW0
rZpEZb0svB0MayoYNqWogLqtei/S18TNVS5sjtcieLWE6F31I6txEi6kryEM
+AwM9peiQGiRx5GBx6cOLy3iS1OHNgVgQucDCxNeyNqHKOezhHP/+jPy7OnZ
GIz4Ut9yBxLmOz+dsiEd9rlojEf2uoJROT6mPF7o4y/CqqlbOgOrJTGSsJuR
Vbkigob4ZIXlzU+v0CcsrS8DlPkSYqiahWcv5U3lpcAlsKBg5XV2D0pvZC14
C16MZHZi4hxOW9veuEvErUiDKWOYnMaGBGUUs2Mbl3THFbSFwe8JZaVKTIii
KTvbY7Ah0WJF9cI2hjyPAo+m31mVMDDjq7WaXWR1s+FOX9KRR3JrzhDiIQIi
05AefL81gxPjh+w+G42sfUtz9bBJ/G7IKuhBVnX1ztYHEV9Ca7xysRvqvqIX
/YColfnVYDCXtaHjs01SkR0DEKr9fSDPlkywscgMaN7QBwCYdrgmOHW7qoGj
UZLTYxvCZ+uKB2LThafpM2+msJFFLhLI138G/ncDuaACAHDPEDm0JMvV/+J3
M96cfU8AW4tuJUgrGD2jG+G01SH4iWw5Z+9WvQu0yUxE+gqeJpmGOOUSjtZD
+GeNUCk02yOYEhX/Lvt5Zw8FwiCuOHv+/Zu3Z3P5t3jxkj+/fvwv3z99/fgR
Pr/57vLZs/Bhpm+8+e7l988exU9x5MOXz58/fvFIBtO3RfbV7Oz55Z/pCXZ1
9vLV26cvX1w+Ozuh0ZgpCBK224PiQQyzTL598/DV//0/d39Dcu6/vH7y8N7d
u//955/1l3+4+99+Q78QLzeyWtsQOcqvBNDDjDwyS3q5giNAHq3Zk1StyUwm
1JMTcNMUIFqC5t//D0Dmfz4ofrsq93d/83v9AgfOvvQwy75kmB1/czRYgDjx
1cQyAZrZ9yNI5/u9/HP2u4d78uVv/5GkKwmpu//wj7+fgYSmbYefbk1bC7PZ
G7ghogYA0iACxc4Tnw7IDKp6wf5Jx642iZXrqmsboJ7N5BYi46YiDmf9U5MI
7Bnl7LLVYRIHH1mn6SPvqpIghlXfA9PtMI49NU8Qi1VrOvIz4DZeWdZCoAUV
4mA7ET30P9sOLvGSVSsZPjE7QlB6kBHwWLrj6CCkkeyOh/Banf3rULEqhuBT
ByZfY6UngEpo2CwmXX0BzhBBwpscqUmeHxKcd1TtFe6JtUtU/SdExXhqTKyb
IgbshqaBUCEzcs5CsoSjVBLo/Mact4B5SPB7yKgGImFK4BTmmveq2+SAAV6v
qw2B61I9bxLj0Grjo7tkS9DZ+ewIVMHKzc4KXTBCukRG3L5tWL1C9UEmRj+U
zf2SLGaJsCwLhkkEBe1oDXLhc1xXrUZPTCCmQMA9QMVfkU6F14v3okdIulPE
VYCKxnlYIkvkzc/pzAYuN+1gIPldw82zVwM7EMGqpXXXlVdA5BtGD17PULdA
mCfrwCtAriDWpMgrt23rrNDUXkxqgC8OoyebAabBmrw1OL+IYEmcqhcoMl4S
dGzgsXIogoMfEjo9BrgE6GQXJHtZ3Oc+Lk+IbXUw0GE1BQeb1mSRRafveVFn
rjkaicjDsEOwSymByP0pgkHrAO9cKog4UHDNRfZEHi4T+QJqFDMmUiiTkzdz
xGzy0pJDPR6K0GiNBXWQ3g4WFrkWYicHs+wcmyE6ojMHjrjIeHvEzMULlrqR
PqoQkPSE4rLQQC9xFmR0MntWI50aWJVwS7quj3Ml7p6L0Tu8kZ5+CTVyq7iM
njmZHq2KxCh8c3l35OpHpg6QjOQ7wCNryBuBkF4HOUJUqopkI9GHDAfMjBL8
2iPHIHwjRiuHEWCOA517RFm7xkVXJugosAIcKiUOiWirVvHRSxEQm+pqUHNZ
CIf1mW3a4WrrWZsPzhSY+DUi42DBE0rJRxG6h1cDtkniMmnog41+hD94Fbao
EiuZvMV/bmDZBNoWhq/AnW4SBonl7iTS6I1mxYlGF7fVPviCGtn2IA8IjCxj
VHHFtxpr1+IGjbRWEs6/lME37CFgAAv+iH7YdmQdF1sioh35c7zdKCshiOLk
wicsytbEa3t259mWn+cpBCgCOfoNAOLEGVP+ZW9eLXSza4eGWWHFhHNgZVfU
dqPSojb7vt0fk7h6SiokOcLAnv0r7wQnxB9lGwvQaYxlL+VCKMFBl7jZdSrG
MuUgHqoIJaQx8Conl7wfZC8C4BOvryUQvoen/Zc2R2KE6ElA+kDSDflcsJc8
OFMg3lRkp63EeT+wB3RFXAyowRxkUdqLVxWMiklonbDUohEw8iAzWZ+O2QS4
jtE7xWy5mlJNXsadq3wAyXLQI/A+i1QfNXkqocfZbCIbHZVA9GwFo1Vz3dbX
YlIx1ZPuTiVmEPeJcA/SegJeLI9gfonK8KkPs9lwZJdD5j5W2uR5kBtzcCKX
XrHJ8cZc02uEqZdhPbPmnZ+2AkVbq/bxxpcyLoZt4edx1JaVfuZ1rDVolpvT
GfumAJHEnSxropktMR7Nw/BuZCU4K4RRgNq4d0ycb9XK+4KDVhsVwhrjDZZn
EoVLDPJo3hIOKkSKEAyqPEn/+7/979RSQBYRn4dO491qMn7u/hqvaAj4Q7eH
GQmAqW3IS5y2D3MrVaxFFi1sIHK0DIPVWUEisjB5AMZ5NRxZ1tsoiJJ4z0kt
RB/w5N22RCeqbM+r1LYK4TR2FZn4A4Xlru1FlAQhtznKKoCreUPruYozny7Q
jIjPynKGftsx12e23aVarYgucujWA4J3C+mapLz1jIokA3udP0a9jAHC9Bk+
xpkQBNl8glhjeJi0N+84wVV6zS/5Zw5+EYyHTH4wqSV55caS+Fm1HXkbZG89
GjqV904kPpl1xEYoItFZsQ+2U499TT4XMsfqWjLruUNTEgR9eYeIyseafpnN
XjYx5JjlYsTVEPSyRekZOsi6zKavmLMkrbeIGUzCDbnyNTKeKEeKBREcHPCe
v3w196uZzMF3bQ3dqZmrxNoszmMhgpAIZ0ZJOje2dhcJl4rnhnk3NRmlAye3
p5K6skeWHBw2FtEhDkzwYBUQwujJa+ygtOq9ss0L76w36QKMMCGSayYxMKQm
Q32qZvbQJyfB103f0atrTXfy+BxFYQeJg+e8rz8BGDI2RK1EExQK9TUkWfEE
wRdJDL1+cpGVXbB1whHAlYWoz5Nkj4WGFq/qtnc//6wlCjSELX2Cjo1p1eQs
rjiHm1bcnbO7VtwTMPLn+xekpa6ZYWMelKbP/R8N1iSJAdZxnqbFrPH5QjWV
YSUhni9jgQKW4z62MJq7UteO2QlbJyjUUXIFqAiBbgnrPxLWiLXZD/c0gp0T
bn/55RfaU1lVXE+lPwKC4vhHYHLqwf3Zq+LDxEP6kQcL+Tl+oD+LxazF78lL
4QM/uKO//JDM0CYz0PMfZjfFh1/u0Ll++QH/wUf6gKfhwS/xaXigP3HgzBYf
7sTl7sR144PRZmzYih846+LuwqH4n24EqgAZejCCE30k7Nymf27jP/G/8vhL
HiiWe0Zuz5js7ye7+MwHKbFwpnDq56MPQHiznx6QucSyY2Hq6qr53RnqtWx3
Fr5GDebvzphAz4pb09xdcO3r786YBkWUvAR/YJmznyWRchwsqdyUCDuOnZBY
gf0btesqd8hYD6NYR1wq73mt0iSU+MAjA4W34HaG05q5KnrsU4acc0p2joWE
u6el3RutF4TAE7kj4o4HcZI8aNakxiGZv1egsKp/QFgnbaMysL+PLEtx2Qtc
iCBUTAQBeU/kIx2z6rwl6rWmB1OaSk0AtExnvqdeanwXsPdCCXGDKCLJZJ0X
q6FP3rmXiGz2cUbrPKnUTDN+wfsfWzCxpdk5SpfWEMnkyhxI9EJdjagIF42t
iKnbtLp00M0pVjIpPQucrT+3PVd96rsZs/CHKN29mFl8iII9yCT/HcmAD79i
zV+z3Xuj7Y63dm/iCP+B273/Gdv9ytD9KjLUywwvRt8GJykVoremy3V+ujVZ
oPOpPCPXdCpD6BNMvLIkQLTwNhSM7CzqBzkg1JYVC9PgzcaEPJb6OxfDukix
oOAmjV/mHsK4CO4TdVZITNAXyHpoPqG7rq6Rlcjit74EjV9rFv6tWKOIwEta
sLwhadSgLCWpLZIkbIzwaMQj8TVMSH+eY9iFFPiKlCFpxOlOzR6qkamzOn2N
jUfU51pf3l01m85IlHxIC4/OiX6QWawPFz5Wi7LUCWwMGlfADvLZlsUbUTxS
YOnro6ve7kbQyCvjJGXCE2LysNfgxI3iDCGoUpS2rjkfNzqWuI7mMNI/3pON
zv3xGeKG3KBl4pIlQByESBQKlD3h4Hj6gp6OV4RXI0ENcYXsAYdajs5JkHE9
17HFglEJQ4a4nQ8QatSIPZgYIcqDgw2oGtXNJkQoFAljDJZtW8cyFhqLNHZM
A/rkETmy2PE39oCMbU69XJbh1C09SbGI1QRZkuSPfWoRadXalzlPEltC0JzQ
gd/qS+7LbWWvpVitW9G2S9hqSbUC3kTNzTUBEhgZ1RV7rkmli3BMkDExTH9k
LYacF8yOLIuXBM85Dn90i8CFEgyVewrQKRC6eTzOKfEYJeFEfi+pRoiBfamk
CDg6Om9BAKo1bJMYyHu+HuHJN1CPJqM0Sme0THqdB0zaMX9ekKRgzREysHnZ
lA9dOZvXoogF7qT4SKWIxqwfAovPiVNoej205OaSkuAjetRtSzQkbljQinQf
ZlsXerI093CDgvYnXELOIm8e4QKMLmilxarqw02SVgOmXl6F6xVdPuZdRUcy
PQ9U6SIpUjr5O6QLl+Gwr7KyTPoyv+mRnHsStWFGPt76mu8I5UfSUKxnEN0P
EksQypxB4Yi6psBR0aG6iSg/hBRR/O8vraS5SwKh2MBBtvP7IUqrl6BYx4Uz
206zMkfn9bscZ94zzO5lvF4CcYOq6z7JFzK1x9RSMFaUKMz6L4OT6ictaJFq
Dd6z1IPQCZfF040KYD1MZ/bVmjxHdgBNxyG2qhnawaFQNU3XiTeBiLj4mDHr
TA+JuEtfpk5WVVIdLwxgrpqqH1AF9ZZzYvprKGv0soxdzHGS0Vmu6QCR74Zd
DDrJUCI3Sa2LyIY8qBXiLMsSMXSUE3spr/D9siliTHJUxxcpvG+eJCn7bevS
UhSVhpMmoIDCkdGMywOowfWBPXpxZYM1xQK7jRsV9IGCwLxw4ENg39vO7NT1
Affk0qMU1l++MZEo/Ii5kmkCMT67yuOjPMRkkm6u2a2NT8p2qXU7FozPkLJ8
UsEU5y0+gjgKwfsYvF0neZsbI/eXhE1YOFnGDoePwSB4MnFF7mmzJvNlPUgY
8p3CMK7WELhSW8T16U2WlCKTO3P8Lq3UtostzSTDZE69JsgiciO3yjRpoUnH
sG3k9BkIzkMtvZXnK1HOlfEmal/Y/jpITTGfXEiHUbZWa2noIKNCacjTZnzX
0d9i4CM4yesd6fSNheWIen/bjYyHc6JENyBZ0RwkqjR+5SLkMxhAnUWxGGf5
BDSyd1/OlkjA5PaTF9M0CsKu2hyKEaJx2seZyaKqV3LQiaGrSpTB99ch1GpW
OaE4H8HZD+oSeZ4bW2dy7WAyi0IczilM4uyrPkT9MYDFMY/0W+CKwvT0g9Tc
ZWdKKrZC0qes22EtpRsiLUpP663gDK4hF8gXr5+MMhngL2RYdxdRY2nZ6ThS
ppaXv2fho1MtqQPayJx1LfRzvNc38oCQPghlu7zySGkzG+vVPC7Js9kNNL0+
68t2YoI7FGAl1/E2RymbcKnPX5+IFrtJqnPjJb5lUfxJpY4QZ3jiHRm+Ksk+
lXkHnoXJ0hvJCodrkN49Rkm+XK6XOVCz4Yp//7f/VazafqvlR4eFcYtDOyyu
WlmOPbDIjel1wWVxGSpEfCJd7wryMK7b5ErTFs7Zft92/dBoiJVVlq/RlMJm
13oNSsgR1PjVmnAPeXVIAomwoQbcHMXLaf2p2jPxKujflGzVG4D2XRaWGa2j
V7BCjWG6EUZzMHB9aFNy6abXsiAB/8tm8coayW6/3Gzkl4BwF9N4cgkmERZZ
rhbFHxJ3J2lQvUfWVrZ2pgucwZYZeh+L4X3Y96W166D1R4af4ISjWZFVWBZd
WT0Cbe9bvhpUp5eA7J4nmTyZ30QUq+xMpNEUo9doQt6/V8q5CW7q2HXICryI
D3EOmnRrzfUBNkQd6DMIr8QoxxTE+qS4Zv80sPMNni1Hd0uFWMteJC7vuosu
nXrYF2onbIcdhLjfJ+7Uatjs1MycPiFrrBJ7OmZgmD+06BKSo+GLP/qxOH9+
7/lFTmFtInEi4EdxI2wzXE0mVe6CLg/3TMmCJs1K84e7xP6RC7Va2q5B71X7
eE1ypRqshNqBoX4Ho8MK75PJSS/tB7eVyNymv2G7Y4/eKRgeSia8gIGu8Pcj
XCjcT24BcA29yB+yLt1E8ZdYNgNfhzM1eQ/rQ9JuAt4FjH2+sachAcIKZKjE
QFmyEXmQFsDmkYEJ4mtlT8yUqu7PryuY5/Y9UtgktivWZuOY7SjtP2em3vc+
nhdlRx4Y5sdsTGepP1ek/qN4rBlNvA3TwWyoEbqTi4FJSUIMi3+6KIFvsVZW
oxwAxJ4znEAWi4E5Hx7k6pWyyL3TRQukPvMb5DJAJY4EMEI5Q2BR+Eio2EKH
HjWLkXeLb35cUIuISupyfc6Sd605SRQojCSZahLA7tzPelGEquH0HTb4z3Ub
F3klw8n6hU9XMMwehixNTLXwrw+Rbbo9MVKeLNLETKxJGNVD8IPJGol29PWH
mTs1iTs5iTuapA97G229x6u3F6Of8CT58S/NTiw6scNsC5OFCIs49ec94X8+
Vb7wmU8+t4LhE0/+pvzbKXHg02/shXPIJiti+JaNAH91xZuBcgECrCecNBW6
m2dCLBNgEppWbvGpD+UQkrVJCn0Vgw+4hpEWKIhUyeZ140KFiUOnpQpPpH4w
EYRsDKqFfFfLDxKz2AQXd/pcHGgMhvfIgRKDPhQbfDy9nrLN53ydZ9lfaJr9
2cs/4Wn4WlPX3z399rv068l08Bfv4CucIU29+zOMN/v/+xnSfPwnzqD4+cpn
+ErSYZyfZwHx2FM6S4osUy957yxWXPGlSiRTqo5cVYlCwNqAEkXoWZ26NXvD
8XL/iHEyadGGkpdYEKSJ6qb462CHyGj6onjvvuKG44S2rqR0uQ3WSmZSfUKE
wAom+XFUxfh1GfUL5iw+8vP5VHvi5/Op9tfs4GtRLXBzrNMkCKP3F6SuZNQZ
5adbo14oeRkDfEZUtmtQWhtx+QiH6LpTrbDkehRiJZOvYf4LjiCUhss58jTS
qcsDaXcZeZMvqfQx7xfqq8OKvtafw0q7trlyfVoYmNQjiu7V63Ntuz5S7ElU
KrRYC1eNw6WnJKSdumn+ki5Bh7jIN9OUkCvDgOOMEy31OPZIW3GWXTqfffh4
JUc8f75AiIuGKxA3rW9Vg22WCDXWHCTSG1cMWj9swfBFrKcnuA8+iDD4LnRJ
szbMV7duVA8q+fKGbw5JkG5cqZlcyZ88i4cnpwrSRogmhnHDKVmMavI+6SN3
dF9YBPmuveZ7CyAq7qkwTohHgk2RJbFzb9OhwV3tqwt95cDW/GjQWkSCtMgf
SBDW0QJ5ov7EqT8Xg+iAQiqhKt/Vhxi+ZkWw006YPYf461gsGzslgqADPPO6
yFHlDNt8av/ZidsOVTdqDKNXZGsnJfiMxXzhU8SSEMhEygHZjVaTns9TFJ8j
LsfXdqKw4ZpZDhTiErOnZemKMFG2xoEXiNIYZvcFsDYhxnxWOjKpZER6+r6r
VoOuIDDxOFXdGyrZkgY98fqujxImfdXqEEajw8u5A0tOtS1NW1eOK1Ne5XdM
YzVKk1Efbek4G6ycpkUEaURxfAsq7y0XZvV1dvnjtEpAMnvEkjaUimnBSrqc
VsQIHb+vYhReenZweHayVOUVugqNqzeQo+Z2QxwMzoSZcve4SoUWECfwPFYn
aI2PXU/06Ts36AFnUEYoekyqDuIxhKATOk5yKb71lqmvEGXd7py/+t0ipL6t
UOyyJ3iiRoEgTLLP88ZRqhDX3mu7RmSNdX7SXsbW9SK2ks02szcuSrqp5gJC
5pM3tTTtBlu4H2j2eu4Lb/TezIXwFRj1SBYIbtZDmv6SC8JRXLA8Tq8zt4kv
zXHiMTZySp+o/QS+bb05UVDx0FcWHPMbh/Bw4s4gEO3zvjG+K4GCyFHIn000
esyKJAMzj7vrZEZAsbHMVM7TI+QGY8hXUYXU07i/apKhGfefDOUDmh9OG7JJ
70tvr3Ctw+P3+8pXB1+O7ir6exuxFg7JhqQ3ragIiykmL+tp1e3fuYA7AUFU
FdmjVu9v5dp8QuYsyTLW+rKQmUq3BZzKrtaSF3GTPUdxNPh2UoQKhifCnCNY
u2V9jMIsuzGIr2gXnq7jBsR6uXRnIcort1sew/V1CEgtC58ymjYcy8ORPJpD
2oQrlrG4ySOCA7/HiBDZxJth7+I1HNRLLsFivhfelNwy4zbGprXiTtJqYshq
tU4rbaSyek62Pg5iwySlQlOFIBy0+oixH29cYwPS79lWvBvHEs4D7ljlxJGJ
4gniMiyeiY28ZEFuV0udLeLrrJJU2yaNraVGXCL+3MpahIN2lgz0NEEFSSXR
G0uCIEQMWJFnDbqkaWHJBrdZ6cdxK+jTnXNjJyRgjXtKpfRRbfJKocMoISos
HKxtExofIXW5OeqQEWvJIDvTYrGu3WOaQMpJzcIo0f42tAbIp4jduVO9PsQq
i6SyWbtJhz6H4zaH8L9Inu+Y5catqEEPbMTdGBCf70yNRtrVnl0PfOD2KiQl
OLVYdXv+mArxmuHPJRN6KQwtGrTB9bDiRhEkWs89E+DOABoE+PIof8pwD95I
HxjSBOgMEp0D0ul9cC4PhCPns3HPiHYfk5rZFi/RTLs4f/b45YWf0a7zdtr8
dPHi4UXaZd4kYGfdknfgVo5bDUTPyFExY+276lpa3ayR4xMGu8J2pQAZhj7M
elnO+YvCPnE56jbkawK2hBIiHgecojLQmUb8saqJNQZJq/Do5iRROd6fv4NB
dg73GE8u8rtUuqxhFrKAP/Dfv5B2RjGXwMaO9uIQUwXWlS/iEKE62U2I21iE
Yoxkz9KnIH04Wlf8+6R3D3uC9j22y+nCZDJIJG4QuQpiHJsjkhpNKnUHGyI9
X2LBxaxi3j4nH7/lhvmT5WI5BcUCzT5QUOzVIoUy53cvVMoRcy2cweiqt+qE
+x5ISItvyVFjHGy4ToJe9/Wm5rqt1uxDa4sOvrJwfu8iiwcFU04dK3/reyfF
EtqwNGA+qR+JUCRavVRCjT12+W8GIL6U1AP56FDUZPJ3KUIeatT8N0FU1Qgd
+ihGFu4IffFj7yIVsEOT9TpKJGXiSLq95b/6EFdL2lZqNZuoLfTjykwp6dwe
6vV3iD8I0OTWznskwLXQf12tWYW13XGP4bxJum9ZRBiCqECna9+nSq4uNR6S
0wSyMVUttjE7TmQIorul/wsk6jU1fKxmkhrSWgopG0iAc/4CdQG+JuD+RSLP
pYaAUeO4z0Kv7ZFlGWf8nywozvukw5bk5VBIxAVW6O8vvUrQqbV2eT813OiI
m3lxj8wPrubxIZ2Rv6QtKDh+pGScHGaOQP15aHSwIkJq1n67vNMLPWbyltla
M3rJpxmyxm+jEo7Yl5v2tXjz8hUyleFSoctgzGqFkCYEPldJfGwK4i8gdclV
Gf0rGwIRCW/1MLfkXlnEzjlbSdLlGX8+Sa3zUIZ6MdHJYblYLCfTAB99QHbL
rVuLD4DzhwU+F8VvF4vF74vCP7h36sF9faDr//Cv/3pncpmPPvib8g8plsI1
VuaDN4GsEypE3uFJHVvDm7H2IOnBAlj+pkiCRlVYsVGPDvReekISiwJ/28i3
1o7tsEdLsTPjVRpRQPpnGpLZ9FrKliQMrqpU7doXJopO1vS/78Y21puwGZy1
6ZbDWZMsmyRLWqkLSohfkzpTFUs6myfcMFuo1+EOKVqvIzII3eHKd9j/Jwdf
dWa/1YqgpEyAtJ7V86DXXyJe7oejesyE7CSEoFxkGT9S2ZjOc3f6zftTHVPe
ZOOSn1zunXpyf/btqfKZkw/wZDbuIIJEHqf10ge3s1SfPLmdlyjpj68pSh/k
dUbyBN/NhlOjh5Ojhzi6GRVMYYvctCR9cDtmJsOT23m2crGYrU+B6OQDPPlK
NUlfsSTpP7AiaczmXoImRPqt8MFDYVSXlya9Qb3vpGhRWeFNSvC3PDLdYX4k
pFgUcjCXpXLVz7XiJ/QkjNf/Jq0gUeojE3lURjA+7MK3O4Bwu0yEBST2DndQ
pTVzxZkPOhSJGP4jNNxPTC8XJWcPtRMaXeXEH/44mAQTjqGUrHpP74qy3eXX
zvqozjmQQubMPF8C9RP3YvlF9kCWWxbfHLwQm0frbnKVfG6p+pCCsKTEw3uS
Ov1YLt4+VWYghRcoWkj7d0gZQ6hgmB59++MlFh8pfrjz4YeTD8nqILPj9NDi
5FDhilNP3wh+Z4tf/fMJgB5/wwVcAOjdIxD/TUCfWOEkvP6To+H458sQM1nf
88Womt7FNKomdnECVMV/ZuR9Dc0YlIVXkQ+zUFF4Omo/lqjAJKfOoSbk2ePf
u4zKkAxsXythjv0T6erh4wPxFspJtRhCnygNGEevJHK1yMNeRwGno9sRSWvz
UQsEDpesO3Z3QuQz5gL8YfgvZfHfwXljy4Hbqz/MGuYe/aW91kqiJjT7wF1X
PzZvtsvzPr18cfmJORF9blp505R+KP9B1BV5KZjlsnyniRYO9RIVSfzYrn93
tiGICpa/eTT7fxGjKyCIeQAA

-->

</rfc>
