rfc9657.original.xml		rfc9657.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.8 (Ruby 3.0.2		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	) -->		-ietf-tvr-use-cases-09" number="9657" updates="" obsoletes="" consensus="true" c
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft		ategory="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="
	-ietf-tvr-use-cases-09" category="info" submissionType="IETF" tocInclude="true"		true" version="3" xml:lang="en">
	sortRefs="true" symRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.20.1 -->
	<front>		<front>
	<title abbrev="tvr-use-cases">TVR (Time-Variant Routing) Use Cases</title>		<title abbrev="TVR Use Cases">Time-Variant Routing (TVR) Use Cases</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-tvr-use-cases-09"/>		<seriesInfo name="RFC" value="9657"/>
	<author fullname="Ed Birrane">		<author fullname="Edward J. Birrane, III" surname="Birrane, III" initials="E
			.">
	<organization>JHU/APL</organization>		<organization>JHU/APL</organization>
	<address>		<address>
	<email>edward.birrane@jhuapl.edu</email>		<email>edward.birrane@jhuapl.edu</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Nicolas Kuhn">		<author fullname="Nicolas Kuhn" surname="Kuhn" initials="N.">
	<organization>Thales Alenia Space</organization>		<organization>Thales Alenia Space</organization>
	<address>		<address>
	<email>nicolas.kuhn.ietf@gmail.com</email>		<email>nicolas.kuhn.ietf@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Yingzhen Qu">		<author fullname="Yingzhen Qu" surname="Qu" initials="Y.">
	<organization>Futurewei Technologies</organization>		<organization>Futurewei Technologies</organization>
	<address>		<address>
	<email>yingzhen.ietf@gmail.com</email>		<email>yingzhen.ietf@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Rick Taylor">		<author fullname="Rick Taylor" surname="Taylor" initials="R.">
	<organization>Ori Industries</organization>		<organization>Ori Industries</organization>
	<address>		<address>
	<email>rick.taylor@ori.co</email>		<email>rick.taylor@ori.co</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Li zhang">		<author fullname="Li Zhang" surname="Zhang" initials="L.">
	<organization>Huawei</organization>		<organization>Huawei</organization>
	<address>		<address>
	<email>zhangli344@huawei.com</email>		<email>zhangli344@huawei.com</email>
	</address>		</address>
	</author>		</author>
	<date year="2024" month="March" day="25"/>		<date year="2024" month="September"/>
	<area>Routing</area>
			<area>RTG</area>
			<workgroup>tvr</workgroup>
	<keyword>Time-variant</keyword>		<keyword>Time-variant</keyword>
	<keyword>Routing</keyword>		<keyword>Routing</keyword>
	<keyword>Mobility</keyword>		<keyword>Mobility</keyword>
	<keyword>Green computing</keyword>		<keyword>Green computing</keyword>
	<keyword>Resource management</keyword>		<keyword>Resource management</keyword>
	<abstract>		<abstract>
	<?line 101?>		<t>This document introduces use cases where Time-Variant Routing (TVR)
			computations (i.e., routing computations that take into consideration
	<t>This document introduces use cases where Time-Variant Routing (TVR) computati		time-based or scheduled changes to a network) could improve routing
	ons (i.e. routing computations taking into considerations time-based or schedule		protocol convergence and/or network performance.</t>
	d changes to a network) could improve routing protocol convergence and/or networ
	k performance.</t>
	</abstract>		</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:tv
	r@ietf.org"/>),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
	wse/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>		</front>
	<middle>		<middle>
	<?line 105?>
	<section anchor="introduction">		<section anchor="introduction">
	<name>Introduction</name>		<name>Introduction</name>
	<t>There is a growing number of use cases where changes to the routing top		<t>There is a growing number of use cases where changes to the routing
	ology are an expected part of network operations. In these use cases the pre-pla		topology are an expected part of network operations. In these use cases,
	nned loss and restoration of an adjacency, or formation of an alternate adjacenc		the pre-planned loss and restoration of an adjacency, or formation of an
	y, should be seen as a non-disruptive event.</t>		alternate adjacency, should be seen as a nondisruptive event.</t>
	<t>Expected changes to topologies can occur for a variety of reasons. In n		<t>Expected changes to topologies can occur for a variety of reasons. In
	etworks with mobile nodes, such as unmanned aerial vehicles and some orbiting sp		networks with mobile nodes, such as unmanned aerial vehicles and some
	acecraft constellations, links are lost and re-established as a function of the		orbiting spacecraft constellations, links are lost and re-established as
	mobility of the platforms. In networks without reliable access to power, such as		a function of the mobility of the platforms. In networks without
	networks harvesting energy from wind and solar, link activity might be restrict		reliable access to power, such as networks harvesting energy from wind
	ed to certain times of day. Similarly, in networks prioritizing green computing		and solar, link activity might be restricted to certain times of
	and energy efficiency over data rate, network traffic might be planned around en		day. Similarly, in networks prioritizing green computing and energy
	ergy costs or expected user data volumes.</t>		efficiency over data rate, network traffic might be planned around
	<t>This document defines three categories of use cases where a route compu		energy costs or expected user data volumes.</t>
	tation might beneficially consider time information. Each of these use cases inc		<t>This document defines three categories of use cases where a route
	ludes the following information.</t>		computation might beneficially consider time information. Each of these
	<ol spacing="normal" type="1"><li>		use cases includes the following information:</t>
	<t>An overview of the use case describing how route computations might		<ol spacing="normal" type="1">
	select different paths (or subpaths) as a function of time.</t>		<li>An overview of the use case describing how route computations
	</li>		might select different paths (or subpaths) as a function of time.</li>
	<li>		<li>A set of assumptions made by the use case as to the nature of
	<t>A set of assumptions made by the use case as to the nature of the n		the network and data exchange.</li>
	etwork and data exchange.</t>		<li>Specific discussion on the routing impacts of the use case.</li>
	</li>		<li>Example networks conformant to the use case.</li>
	<li>
	<t>Specific discussion on the routing impacts of the use case.</t>
	</li>
	<li>
	<t>Example networks conformant to the use case.</t>
	</li>
	</ol>		</ol>
	<t>The use cases that are considered in this document are the following.</ t>		<t>The use cases that are considered in this document are the following.</ t>
	<ol spacing="normal" type="1"><li>
	<t>Resource Preservation (described in <xref target="Resource-Preserva		<ol spacing="normal" type="1">
	tion"/>), where there is information about link availability over time at the cl		<li>Resource Preservation (described in <xref
	ient level. Time Variant Routing can utilize the predictability of the link avai		target="Resource-Preservation"/>), where there is information about
	lability to optimize network connectivity by taking into account end point resou		link availability over time at the client level. Time-Variant Routing (T
	rce preservation.</t>		VR)
	</li>		can utilize the predictability of the link availability to optimize
	<li>		network connectivity by taking into account endpoint resource
	<t>Operating Efficiency (described in <xref target="Operating-Efficien		preservation.</li>
	cy"/>), where there is a server cost or a path cost usage varying over time. Tim		<li>Operating Efficiency (described in <xref
	e Variant Routing can exploit the predictability of the path cost to optimize th		target="Operating-Efficiency"/>), where there is a server cost or a
	e cost of the system exploitation. The notion of a path cost is extended to be a		path cost usage varying over time. TVR can exploit
	time-dependent function instead of a constant.</t>		the predictability of the path cost to optimize the cost of the system
	</li>		exploitation. The notion of a path cost is extended to be a
	<li>		time-dependent function instead of a constant.</li>
	<t>Dynamic Reachability (described in <xref target="Dynamic-Reachabili		<li>Dynamic Reachability (described in <xref
	ty"/>), where there is information about link availability variation between nod		target="Dynamic-Reachability"/>), where there is information about
	es taking part of the end-to-end path. Time Variant Routing can exploit the pred		link availability variation between nodes in the
	ictability of the link availability to optimize in-network routing.</t>		end-to-end path. TVR can exploit the predictability
	</li>		of the link availability to optimize in-network routing.</li>
	</ol>		</ol>
	<t>The document does not intend to represent the full set of cases where t		<t>The document does not intend to represent the full set of cases where
	ime-variant routing computations could beneficially impact network performance -		TVR computations could beneficially impact network
	new use cases are expected to be generated over time. Similarly, the concrete		performance -- new use cases are expected to be generated over time.
	examples within each use case are meant to provide an existence proof of the use		Similarly, the concrete examples within each use case are meant to
	case, not to present any exhaustive enumeration of potential examples. It is li		provide an existence proof of the use case and not to present any
	kely that there exist multiple example networks that could be claimed as instanc		exhaustive enumeration of potential examples. It is likely that multiple
	es of any given use case.</t>		example networks exist that could be claimed as instances of any given
	<t>The document focuses on deterministic scenarios. Non-deterministic scen		use case.</t>
	arios such as vehicle-to-vehicle communication is out of the scope of the docume		<t>The document focuses on deterministic scenarios. Non-deterministic
	nt.</t>		scenarios, such as vehicle-to-vehicle communication, are out of the
			scope of the document.</t>
	</section>		</section>
	<section anchor="Resource-Preservation">		<section anchor="Resource-Preservation">
	<name>Resource Preservation</name>		<name>Resource Preservation</name>
	<t>Some nodes in a network might operate in resource-constrained environme		<t>Some nodes in a network might operate in resource-constrained
	nts or otherwise with limited internal resources. Constraints such as available		environments or otherwise with limited internal resources. Constraints,
	power, thermal ranges, and on-board storage can all impact the instantaneous ope		such as available power, thermal ranges, and on-board storage, can all
	ration of a node. In particular, resource management on such a node can require		impact the instantaneous operation of a node. In particular, resource
	that certain functionality be powered on (or off) to extend the ability of the n		management on such a node can require that certain functionality be
	ode to participate in the network.</t>		powered on (or off) to extend the ability of the node to participate in
	<t>When power on a node is running low, non-critical functions on the node		the network.</t>
	might be turned off in favor of extending node life. Alternatively, certain fun		<t>When power on a node is running low, noncritical functions on the
	ctions on a node may be turned off to allow the node to use available power to r		node might be turned off in favor of extending node life. Alternatively,
	espond to an event, such as data collection. When a node is in danger of violati		certain functions on a node may be turned off to allow the node to use
	ng a thermal constraint, normal processing might be paused in favor of a transit		available power to respond to an event, such as data collection. When a
	ion to a thermal safe mode until a regular operating condition is reestablished.		node is in danger of violating a thermal constraint, normal processing
	When local storage resources run low, a node might choose to expend power resou		might be paused in favor of a transition to a thermal safe mode until a
	rces to fuse, delete, or transmit data off the node to free space for future dat		regular operating condition is reestablished. When local storage
	a collection. There might also be cases where a node experiences a planned offli		resources run low, a node might choose to expend power resources to
	ne state to save and accumulate power.</t>		compress, delete, or transmit data off the node to free up space for futur
	<t>In addition to power, thermal, and storage, other resource constraints		e
	may exist on a node such that the preservation of resources are necessary to pre		data collection. There might also be cases where a node experiences a
	serve the existence (and proper function) of the node in the network. Nodes oper		planned offline state to save and accumulate power.</t>
	ating in these conditions might benefit from TVR computations as the connectivit		<t>In addition to power, thermal, and storage, other resource
	y of the node changes over time as part of node preservation.</t>		constraints may exist on a node such that the preservation of resources
			is necessary to preserve the existence (and proper function) of the
			node in the network. Nodes operating in these conditions might benefit
			from TVR computations as the connectivity of the node changes over time
			as part of node preservation.</t>
	<section anchor="assumptions">		<section anchor="assumptions">
	<name>Assumptions</name>		<name>Assumptions</name>
	<t>To effectively manage on-board functionality based on available resou		<t>To effectively manage on-board functionality based on available
	rces, a node must comprehend specific aspects concerning the utilization and rep		resources, a node must comprehend specific aspects concerning the
	lenishment of resources. It is expected that patterns of the environment, device		utilization and replenishment of resources. It is expected that
	construction, and operational configuration exist with enough regularity and st		patterns of the environment, device construction, and operational
	ability to allow meaningful planning. The following assumptions are made with th		configuration exist with enough regularity and stability to allow
	is use case.</t>		meaningful planning. The following assumptions are made with this use
	<ol spacing="normal" type="1"><li>		case:</t>
	<t>Known resource expenditures. It is assumed that there exists some		<ol spacing="normal" type="1">
	determinable relationship between the resources available on a node and the res		<li>Known resource expenditures.
	ources needed to participate in a network. A node would need to understand when		It is assumed that there exists
	it has met some condition for participating in, or dropping out of, a network. T		some determinable relationship between the resources available on a
	his is somewhat similar to predicting the amount of battery life left on a lapto		node and the resources needed to participate in a network. A node
	p as a function of likely future usage.</t>		would need to understand when it has met some condition for
	</li>		participating in, or dropping out of, a network. This is somewhat
	<li>		similar to predicting the amount of battery life left on a laptop as
	<t>Predictable resource accumulation. It is assumed that the accumul		a function of likely future usage.</li>
	ation of resources on a node are predictable such that a node might expect (and		<li>Predictable resource accumulation.
	be able to communicate) when it is likely to next rejoin a network. This is sim		It is assumed that the
	ilar to predicting the time at which a battery on a laptop will be fully charged		accumulation of resources on a node are predictable such that a node
	.</t>		might expect (and be able to communicate) when it is likely to next
	</li>		rejoin a network. This is similar to predicting the time at which a
	<li>		battery on a laptop will be fully charged.</li>
	<t>Consistent cost functions. It is assumed that resource management		<li>Consistent cost functions.
	on a node is deterministic such that the management of a node as a function of		It is assumed that resource
	resource expenditure and accumulation is consistent enough for link planning.</t		management on a node is deterministic such that the management of a
	>		node as a function of resource expenditure and accumulation is
	</li>		consistent enough for link planning.</li>
	</ol>		</ol>
	</section>		</section>
	<section anchor="routing-impacts">		<section anchor="routing-impacts">
	<name>Routing Impacts</name>		<name>Routing Impacts</name>
	<t>Resource management in these scenarios might involve turning off elem ents of the node as part of on-board resource management. These activities can a ffect data routing in a variety of ways.</t>		<t>Resource management in these scenarios might involve turning off elem ents of the node as part of on-board resource management. These activities can a ffect data routing in a variety of ways.</t>
	<ol spacing="normal" type="1"><li>		<ol spacing="normal" type="1">
	<t>Power Savings. On-board radios may be turned off to allow other n		<li>Power Savings. On-board radios may be turned off to allow other
	ode processing. This may happen on power-constrained devices to extend the batte		node processing. This may happen on power-constrained devices to
	ry life of the node or to allow a node to perform some other power-intensive tas		extend the battery life of the node or to allow a node to perform
	k.</t>		some other power-intensive task.</li>
	</li>		<li>Thermal Savings. On-board radios may be turned off if there are
	<li>		thermal considerations on the node, such as an increase in a node's
	<t>Thermal Savings. On-board radios may be turned off if there are t		operating temperature.</li>
	hermal considerations on the node, such as an increase in a node’s operating tem		<li>Storage Savings. On-board radios may be turned on with the
	perature.</t>		purpose of transmitting data off the node to free local storage
	</li>		space to collect new data.</li>
	<li>
	<t>Storage Savings. On-board radios may be turned on with the purpos
	e of transmitting data off the node to free local storage space to collect new d
	ata.</t>
	</li>
	</ol>		</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 networ k) 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 m ay take place relating to the status of the node’s functional neighborhood. Duri ng these times, forwarding to and from the node might be delayed pending some sy nchronization.</t>		<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 networ k) 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 m ay take place relating to the status of the node's functional neighborhood. Duri ng these times, forwarding to and from the node might be delayed pending some sy nchronization.</t>
	</section>		</section>
	<section anchor="example">		<section anchor="example">
	<name>Example</name>		<name>Example</name>
	<t>An illustrative example of a network necessitating resource preservat ion is an energy-harvesting wireless sensor network. In such a network, nodes re ly exclusively on environmental sources for power, such as solar panels. On-boar d power levels may fluctuate based on various factors including sensor activity, processing demands, and the node's position and orientation relative to its ene rgy source.</t>		<t>An illustrative example of a network necessitating resource preservat ion is an energy-harvesting wireless sensor network. In such a network, nodes re ly exclusively on environmental sources for power, such as solar panels. On-boar d power levels may fluctuate based on various factors including sensor activity, processing demands, and the node's position and orientation relative to its ene rgy source.</t>
	<t>Consider a simple three node network where each node accumulates powe		<t>Consider a simple three-node network where each node accumulates powe
	r through solar panels. Power available for Radio Frequency (RF) transmission i		r through solar panels. Power available for radio frequency (RF) transmission i
	s shown below in <xref target="Resource-Example-Plots"/>. In this figure, each o		s shown in <xref target="Resource-Example-Plots"/>. In this figure, each of the
	f the three nodes (Node 1, Node 2, and Node 3) have a different plot of availabl		three nodes (Node 1, Node 2, and Node 3) has a different plot of available power
	e power over time. This example assumes that a node will not power its radio un		over time. This example assumes that a node will not power its radio until ava
	til available power is over some threshold, which is shown by the horizontal lin		ilable power is over some threshold, which is shown by the horizontal line on ea
	e on each plot.</t>		ch plot.</t>
	<figure anchor="Resource-Example-Plots">		<figure anchor="Resource-Example-Plots">
	<name>Node Power Over Time</name>		<name>Node Power over Time</name>
	<artwork type="ascii" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	Node 1 Node 2 Node 3		Node 1 Node 2 Node 3
	P | P | ------- P | --		P | P | ------- P | --
	o | ---- -- o | / \ o | / \		o | ---- -- o | / \ o | / \
	w |~/~~~~\~~~~~/~~\~~ w |~/~~~~~~~~~\~~~~~~ w |~~~~~~~~/~~~~\~~~~		w |~/~~~~\~~~~~/~~\~~ w |~/~~~~~~~~~\~~~~~~ w |~~~~~~~~/~~~~\~~~~
	e |/ \ / \ e |/ \ e | / \		e |/ \ / \ e |/ \ e | / \
	r | --- - r | ----- r |------- ---		r | --- - r | ----- r |------- ---
	+---++----++----++- +---++----++----++- +---++----++----++-		+---++----++----++- +---++----++----++- +---++----++----++-
	t1 t2 t3 t1 t2 t3 t1 t2 t3		t1 t2 t3 t1 t2 t3 t1 t2 t3
	Time Time Time		Time Time Time
	]]></artwork>		]]></artwork>
	</figure>		</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 i		<t>The connectivity of this three-node network changes over time in
	n this small sensor network. Examples of connectivity are shown in <xref target=		ways that may be predictable and are likely able to be communicated to
	"Resource-Example-Schedule"/>. This figure shows a sample of network connectivi		other nodes in this small sensor network. Examples of connectivity are
	ty at three times: t1, t2, and t3.</t>		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">		<ul spacing="normal">
	<li>		<li>
	<t>At time t1 Node 1 and Node 2 have their radios powered on and are		<t>At time t1, Node 1 and Node 2 have their radios powered on and
	expected to communicate.</t>		are expected to communicate.</t>
	</li>		</li>
	<li>		<li>
	<t>At time t2 it is expected that Node 1 has its radio off, but tha		<t>At time t2, it is expected that Node 1 has its radio off but
	t Node 2 and Node 3 can communicate.</t>		that Node 2 and Node 3 can communicate.</t>
	</li>		</li>
	<li>		<li>
	<t>Finally, at time t3 it is expected that Node 1 may be turning its		<t>Finally, at time t3, it is expected that Node 1 may be turning
	radio off and that Node 2 and Node 3 are not powering their radios and there is		its radio off, that Node 2 and Node 3 are not powering their
	no expectation of connectivity.</t>		radios, and there is no expectation of connectivity.</t>
	</li>		</li>
	</ul>		</ul>
	<figure anchor="Resource-Example-Schedule">		<figure anchor="Resource-Example-Schedule">
	<name>Topology over Time</name>		<name>Topology over Time</name>
	<artwork type="ascii" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	t1 | Node 1 |--------| Node 2 | | Node 3 |		t1 | Node 1 |--------| Node 2 | | Node 3 |
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	t2 | Node 1 | | Node 2 |--------| Node 3 |		t2 | Node 1 | | Node 2 |--------| Node 3 |
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	t3 | Node 1 | | Node 2 | | Node 3 |		t3 | Node 1 | | Node 2 | | Node 3 |
	skipping to change at line 187 ¶		skipping to change at line 256 ¶
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	t2 | Node 1 | | Node 2 |--------| Node 3 |		t2 | Node 1 | | Node 2 |--------| Node 3 |
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	t3 | Node 1 | | Node 2 | | Node 3 |		t3 | Node 1 | | Node 2 | | Node 3 |
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	</section>		</section>
	</section>		</section>
	<section anchor="Operating-Efficiency">		<section anchor="Operating-Efficiency">
	<name>Operating Efficiency</name>		<name>Operating Efficiency</name>
	<t>Some nodes in a network might alter their networking behavior to optimi ze metrics associated with the cost of a node's operation. While the resource pr eservation use case described in <xref target="Resource-Preservation"/> addresse s node survival, this use case discusses non-survival efficiencies such as the f inancial cost to operate the node and the environmental impact (cost) of using t hat node.</t>		<t>Some nodes in a network might alter their networking behavior to optimi ze metrics associated with the cost of a node's operation. While the resource pr eservation use case described in <xref target="Resource-Preservation"/> addresse s node survival, this use case discusses non-survival efficiencies such as the f inancial cost to operate the node and the environmental impact (cost) of using t hat node.</t>
	<t>When a node operates using some pre-existing infrastructure there is ty pically some cost associated with the use of that infrastructure. Sample costs i nclude the following.</t>		<t>When a node operates using some preexisting infrastructure, there is ty pically some cost associated with the use of that infrastructure. Sample costs i nclude the following.</t>
	<ol spacing="normal" type="1"><li>		<ol spacing="normal" type="1"><li>
	<t>Nodes that use existing wireless communications such as a cellular		<t>Nodes that use existing wireless communications, such as a
	infrastructure must pay to communicate to and through that infrastructure.</t>		cellular infrastructure, must pay to communicate to and through that
			infrastructure.</t>
	</li>		</li>
	<li>		<li>
	<t>Nodes supplied with electricity from an energy provider pay for the		<t>Nodes supplied with electricity from an energy provider pay for
	power they use.</t>		the power they use.</t>
	</li>		</li>
	<li>		<li>
	<t>Nodes that cluster computation and activities might increase the te		<t>Nodes that cluster computation and activities might increase the
	mperature of the node and incur additional costs associated with cooling the nod		temperature of the node and incur additional costs associated with
	e (or collection of nodes).</t>		cooling the node (or collection of nodes).</t>
	</li>		</li>
	<li>		<li>
	<t>Beyond financial costs, assessing the environmental impact of opera		<t>Beyond financial costs, assessing the environmental impact of
	ting a node may also be modeled as a cost associated with node operation, to inc		operating a node may also be modeled as a cost associated with node
	lude achieving carbon credits or other incentives for green computing.</t>		operation, to include achieving carbon credits or other incentives
			for green computing.</t>
	</li>		</li>
	</ol>		</ol>
	<t>When the cost of using a node's resources changes over time, a node can		<t>When the cost of using a node's resources changes over time, a node
	benefit from predicting when data transmissions might optimize costs, environme		can benefit from predicting when data transmissions might optimize
	ntal impacts, or other metrics associated with operation.</t>		costs, environmental impacts, or other metrics associated with
			operation.</t>
	<section anchor="assumptions-1">		<section anchor="assumptions-1">
	<name>Assumptions</name>		<name>Assumptions</name>
	<t>The ability to predict the impact of a node's resource utilization ov		<t>The ability to predict the impact of a node's resource utilization
	er time presumes that the node exists within a defined environment (or infrastru		over time presumes that the node exists within a defined environment
	cture). Some characteristics of these environments are listed as follows.</t>		(or infrastructure). Some characteristics of these environments are
			listed as follows:</t>
	<ol spacing="normal" type="1"><li>		<ol spacing="normal" type="1"><li>
	<t>Cost Measureability. The impacts of operating a node within its e		<t>Cost Measurability. The impacts of operating a node within its
	nvironment can be measured in a deterministic way. For example, that the cost-pe		environment can be measured in a deterministic way. For example,
	r-bit of data over a cellular network or the cost-per-kilowatt of energy used ar		the cost-per-bit of data over a cellular network or the
	e known.</t>		cost-per-kilowatt of energy used are known.</t>
	</li>		</li>
	<li>		<li>
	<t>Cost Predictability. Changes to the impacts of resource utilizati		<t>Cost Predictability. Changes to the impacts of resource
	on are known in advance. For example, if the cost of energy is less expensive in		utilization are known in advance. For example, if the cost of
	the evening than during the day, there exists some way of communicating this ch		energy is less expensive in the evening than during the day, there
	ange to a node.</t>		exists some way of communicating this change to a node.</t>
	</li>		</li>
	<li>		<li>
	<t>Cost Persistent. Changes to the cost of operating in the environm		<t>Cost Persistent. Changes to the cost of operating in the
	ent persist for a sufficient amount of time such that behavior can be adjusted i		environment persist for a sufficient amount of time such that
	n response to changing costs. If costs change too rapidly it is likely not possi		behavior can be adjusted in response to changing costs. If costs
	ble to meaningfully react to their change.</t>		change too rapidly, it is likely not possible to meaningfully react
			to their change.</t>
	</li>		</li>
	<li>		<li>
	<t>Cost Magnitude. The magnitude of cost changes is such that a node		<t>Cost Magnitude. The magnitude of cost changes is such that a
	experiences a minimum threshold cost reduction through optimization. A specifie		node experiences a minimum threshold cost reduction through
	d time period is designated for measuring the cost reduction.</t>		optimization. A specified time period is designated for measuring
			the cost reduction.</t>
	</li>		</li>
	</ol>		</ol>
	</section>		</section>
	<section anchor="routing-impacts-1">		<section anchor="routing-impacts-1">
	<name>Routing Impacts</name>		<name>Routing Impacts</name>
	<t>Optimizing resource utilization can affect route computation in ways		<t>Optimizing resource utilization can affect route computation in
	similar to those experienced with resource preservation. The route computation m		ways similar to those experienced with resource preservation. The
	ay not change the available path but the topology as seen by an end point would		route computation may not change the available path, but the topology
	be different. Cost optimization can impact route calculation in a variety of way		as seen by an endpoint would be different. Cost optimization can
	s, some of which are described as follows.</t>		impact route calculation in a variety of ways, some of which are
			described as follows:</t>
	<ol spacing="normal" type="1"><li>		<ol spacing="normal" type="1"><li>
	<t>Link Filtering. Data might be accumulated on a node waiting for a		<t>Link Filtering. Data might be accumulated on a node waiting for
	cost-effective time for data transmission. Individual link costs might be annot		a cost-effective time for data transmission. Individual link costs
	ated with cost information such that adjacencies with a too-high cost might not		might be annotated with cost information such that adjacencies
	be used for forwarding. This effectively filters which adjacencies are used (pos		with a too high cost might not be used for forwarding. This
	sibly as a function of the type of data being routed).</t>		effectively filters which adjacencies are used (possibly as a
			function of the type of data being routed).</t>
	</li>		</li>
	<li>		<li>
	<t>Burst Planning. In cases where there is a cost savings associated		<t>Burst Planning. In cases where there is a cost savings
	with fewer longer transmissions (versus many smaller transmissions), nodes migh		associated with fewer longer transmissions (versus many smaller
	t refuse to forward data until a sufficient data volume exists to justify a tran		transmissions), nodes might refuse to forward data until a
	smission.</t>		sufficient data volume exists to justify a transmission.</t>
	</li>		</li>
	<li>		<li>
	<t>Environmental Measurement. Nodes that measure the quality of indi		<t>Environmental Measurement. Nodes that measure the quality of
	vidual links can compute the overall cost of using a link as a function of the s		individual links can compute the overall cost of using a link as a
	ignal strength of the link. If link quality is insufficient due to environmental		function of the signal strength of the link. If link quality is
	conditions (such as clouds on a free-space optical link or long distance RF tra		insufficient due to environmental conditions (such as clouds on a
	nsmission in a storm) the cost required to communicate over the link may be too		free-space optical link or long distance RF transmission in a
	much, even if access to infrastructure is otherwise in a less expensive time of		storm) the cost required to communicate over the link may be too
	day.</t>		much, even if access to infrastructure is otherwise in a less
			expensive time of day.</t>
	</li>		</li>
	</ol>		</ol>
	<t>In each of these cases, some consideration of the efficiency of trans		<t>In each of these cases, some consideration of the efficiency of
	mission is prioritized over achieving a particular data rate. Waiting until dat		transmission is prioritized over achieving a particular data rate.
	a rate costs are lower takes advantage of platforms using time-of-use rate plans		Waiting until data rate costs are lower takes advantage of platforms
	– both for pay-as-you-go data and associated energy costs. Accumulating data vo		using time-of-use rate plans -- both for pay-as-you-go data and
	lumes and choosing more opportune times to transmit can also result in less ener		associated energy costs. Accumulating data volumes and choosing more
	gy consumption by radios and, thus, less operating cost for platforms.</t>		opportune times to transmit can also result in less energy consumption
			by radios and, thus, less operating cost for platforms.</t>
	</section>		</section>
	<section anchor="example-cellular-network">		<section anchor="example-cellular-network">
	<name>Example : Cellular Network</name>		<name>Example: Cellular Network</name>
	<t>One example of a network where nodes might seek to optimize operating		<t>One example of a network where nodes might seek to optimize
	cost is a set of nodes operating over cellular connections that charge both On-		operating cost is a set of nodes operating over cellular connections
	Peak and Off-Peak data rates. In this case, individual nodes may be allocated a		that charge both peak and off-peak data rates. In this case,
	fixed set of "On-Peak" minutes such that exceeding that amount of time results i		individual nodes may be allocated a fixed set of "peak" minutes
	n expensive overage charges. Generally, the concept of On-Peak and Off-Peak minu		such that exceeding that amount of time results in expensive overage
	tes exists to deter the use of a given network at times when the cellular networ		charges. Generally, the concept of peak and off-peak minutes exists
	k is likely to encounter heavy call volumes (such as during the workday).</t>		to deter the use of a given network at times when the cellular network
	<t>Just as pricing information can act as a deterrent (or incentive) for		is likely to encounter heavy call volumes (such as during the
	a human cellular user, this pricing information can be codified in ways that al		workday).</t>
	so allow machine-to-machine (M2M) connections to prioritize Off-Peak communicati		<t>Just as pricing information can act as a deterrent (or incentive)
	ons for certain types of data exchange. Many M2M traffic exchanges involve sched		for a human cellular user, this pricing information can be codified in
	ulable activities, such as nightly bulk file transfers, pushing software updates		ways that also allow machine-to-machine (M2M) connections to
	, synchronizing datastores, and sending non-critical events and logs. These acti		prioritize off-peak communications for certain types of data
	vities are usually already scheduled to minimize impact on businesses and custom		exchange. Many M2M traffic exchanges involve schedulable activities,
	ers, but can also be scheduled to minimize overall cost.</t>		such as nightly bulk file transfers, pushing software updates,
	<t>Consider a simple three node network, similar to the one pictured in		synchronizing datastores, and sending noncritical events and
	<xref target="Resource-Example-Plots"/>, except that in this case the resource t		logs. These activities are usually already scheduled to minimize
	hat varies over time is the cost of the data exchange. This case is illustrated		impact on businesses and customers but can also be scheduled to
	below in <xref target="Efficiency-Example-Plots"/>. In this figure, a series of		minimize overall cost.</t>
	three plots are given, one for each of nodes Node 1, Node 2, and Node 3. Each o		<t>Consider a simple three-node network, similar to the one pictured
	f these nodes exists in a different cellular service area which has different On		in <xref target="Resource-Example-Plots"/>, except that in this case
	-Peak and Off-Peak data rate times. This is shown in each figure by times when t		the resource that varies over time is the cost of the data
	he cost is low (Off-Peak) and when the cost is high (On-Peak).</t>		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 the three nodes (Node 1, Node 2, and
			Node 3). Each of these nodes exists in a different cellular service
			area that has different peak and off-peak data rate times. This is
			shown in each figure by times when the cost is low (off-peak) and when
			the cost is high (peak).</t>
	<figure anchor="Efficiency-Example-Plots">		<figure anchor="Efficiency-Example-Plots">
	<name>Data Cost Over Time</name>		<name>Data Cost over Time</name>
	<artwork type="ascii" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	Node 1 Node 2 Node 3		Node 1 Node 2 Node 3
	C | +--------- C |--+ C |-------------+		C | +--------- C |--+ C |-------------+
	o | | o | | o | |		o | | o | | o | |
	s | | s | | s | |		s | | s | | s | |
	t |-------+ t | +---------------- t | +-------		t |-------+ t | +---------------- t | +-------
	| | |		| | |
	+---++----++----++-- +----++----++----++-- +----++----++-----++--		+---++----++----++-- +----++----++----++-- +----++----++-----++--
	t1 t2 t3 t1 t2 t3 t1 t2 t3		t1 t2 t3 t1 t2 t3 t1 t2 t3
	Time Time Time		Time Time Time
	]]></artwork>		]]></artwork>
	</figure>		</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. Example		<t>Given the presumption that peak times are known in advance, the
	s of these data exchanges are shown in <xref target="Efficiency-Example-Schedule		cost of data exchange from Node 1 through Node 2 to Node 3 can be
	"/>. From this figure, both times t1 and t3 result in a smaller cost of data exc		calculated. Examples of these data exchanges are shown in <xref
	hange than choosing to communicate data at time t2.</t>		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">		<figure anchor="Efficiency-Example-Schedule">
	<name>Data Exchange Cost over Time</name>		<name>Data Exchange Cost over Time</name>
	<artwork type="ascii" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	t1 | Node N1 |---LOW----| Node N2 |---HIGH---| Node N3 |		t1 | Node N1 |---LOW----| Node N2 |---HIGH---| Node N3 |
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	t2 | Node N1 |---HIGH---| Node N2 |---HIGH---| Node N3 |		t2 | Node N1 |---HIGH---| Node N2 |---HIGH---| Node N3 |
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	t3 | Node N1 |---HIGH---| Node N2 |----LOW---| Node N3 |		t3 | Node N1 |---HIGH---| Node N2 |----LOW---| Node N3 |
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>While not possible in every circumstance, a highly optimized plan cou
	ld be to communicate from Node 1 to Node 2 at time t1 and then queue data at Nod		<t>While not possible in every circumstance, a highly optimized plan
	e 2 until time t3 for delivery to Node 3. This case is shown in <xref target="Ef		could be to communicate from Node 1 to Node 2 at time t1 and then
	ficiency-Example-Store"/>.</t>		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">		<figure anchor="Efficiency-Example-Store">
	<name>Data Cost using Storage</name>		<name>Data Cost Using Storage</name>
	<artwork type="ascii" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	+-----------+ +-----------+		+-----------+ +-----------+
	t1 | Node N1 |---LOW----| Node N2 |		t1 | Node N1 |---LOW----| Node N2 |
	+-----------+ +-----------+		+-----------+ +-----------+
	+-----------+ +-----------+		+-----------+ +-----------+
	t3 | Node N2 |----LOW---| Node N3 |		t3 | Node N2 |----LOW---| Node N3 |
	+-----------+ +-----------+		+-----------+ +-----------+
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	</section>		</section>
	<section anchor="another-example-tidal-network">		<section anchor="another-example-tidal-network">
	<name>Another Example : Tidal Network</name>		<name>Another Example: Tidal Network</name>
	<t>Another example related to operating efficiency is what is often refe		<t>Another example related to operating efficiency is often referred to
	rred to as a 'tidal network,' in which traffic volume undergoes significant fluc		as a "tidal network," in which traffic volume undergoes significant fluctuations
	tuations at different times. Take, for instance, a campus network, where thousan		at different times. Take, for instance, a campus network, where thousands of in
	ds of individuals go to classrooms and libraries during the daytime and retire t		dividuals go to classrooms and libraries during the daytime and retire to the do
	o the dormitories at night. This results in a regular oscillation of network tra		rmitories at night. This results in a regular oscillation of network traffic acr
	ffic across various locations within the campus.</t>		oss various locations within the campus.</t>
	<t>In the context of a tidal network scenario, energy-saving methods may include the deactivation of some or all components of network nodes. These acti vities have the potential to alter network topology and impact data routing in a variety of ways. Ports on network nodes can be selectively disabled or enabled based on traffic patterns, thereby reducing the energy consumption of nodes duri ng periods of low network traffic.</t>		<t>In the context of a tidal network scenario, energy-saving methods may include the deactivation of some or all components of network nodes. These acti vities have the potential to alter network topology and impact data routing in a variety of ways. Ports on network nodes can be selectively disabled or enabled based on traffic patterns, thereby reducing the energy consumption of nodes duri ng periods of low network traffic.</t>
	<t>More information on Tidal Network can be found in <xref target="TIDAL "/>.</t>		<t>More information on tidal networks can be found in <xref target="I-D. zzd-tvr-use-case-tidal-network"/>.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="Dynamic-Reachability">		<section anchor="Dynamic-Reachability">
	<name>Dynamic Reachability</name>		<name>Dynamic Reachability</name>
	<t>When a node is placed on a mobile platform, the mobility of the platfor		<t>When a node is placed on a mobile platform, the mobility of the
	m (and thus the mobility of the node) may cause changes to the topology of the n		platform (and thus the mobility of the node) may cause changes to the
	etwork over time. The impacts on the dynamics of the topology can be very import		topology of the network over time. The impacts on the dynamics of the
	ant. To the extent that the relative mobility between and among nodes in the net		topology can be very important. To the extent that the relative mobility
	work and the impacts of the environment on the signal propagation can be predict		between and among nodes in the network and the impacts of the
	ed, the associated loss and establishment of adjacencies can also be planned for		environment on the signal propagation can be predicted, the associated
	.</t>		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 a s the following.</t>		<t>Mobility can cause the loss of an adjacent link in several ways, such a s the following.</t>
	<ol spacing="normal" type="1"><li>		<ol spacing="normal" type="1"><li>
	<t>Node mobility can cause the distance between two nodes to become la rge enough that distance-related attenuation causes the mobile node to lose conn ectivity with one or more other nodes in the network.</t>		<t>Node mobility can cause the distance between two nodes to become la rge enough that distance-related attenuation causes the mobile node to lose conn ectivity with one or more other nodes in the network.</t>
	</li>		</li>
	<li>		<li>
	<t>Node mobility can also be used to maintain a required distance from other mobile nodes in the network. While moving, external characteristics may c ause the loss of links through occultation or other hazards of traversing a shar ed environment.</t>		<t>Node mobility can also be used to maintain a required distance from other mobile nodes in the network. While moving, external characteristics may c ause the loss of links through occultation or other hazards of traversing a shar ed environment.</t>
	</li>		</li>
	<li>		<li>
	<t>Node mobility can cause the distance between two nodes to vary quic kly over the time making it complicated to establish and maintain connectivity.< /t>		<t>Node mobility can cause the distance between two nodes to vary quic kly over time, making it complicated to establish and maintain connectivity.</t>
	</li>		</li>
	<li>		<li>
	<t>Nodes equipped with communication terminals capable of adjusting th eir orientation or moving behind and emerging from barriers will also establish and lose connectivity with other nodes as a function of that motion.</t>		<t>Nodes equipped with communication terminals capable of adjusting th eir orientation or moving behind and emerging from barriers will also establish and lose connectivity with other nodes as a function of that motion.</t>
	</li>		</li>
	</ol>		</ol>
	<t>Mobile nodes, like any node, may have concerns regarding resource prese
	rvation and cost efficiency. However, they also face unique challenges associate		<t>Mobile nodes, like any node, may encounter issues regarding resource
	d with their mobility. The intermittent availability of links can lead to dynami		preservation and cost efficiency. In addition, they may face unique
	c neighbor relationships at the node level. This use case aims to examine the ro		challenges associated with their mobility. The intermittent availability of
	uting implications of motion-induced changes to network topology.</t>		links can lead to dynamic neighbor relationships at the node level. This use
			case aims to examine the routing implications of motion-induced changes to
			network topology.</t>
	<section anchor="assumptions-2">		<section anchor="assumptions-2">
	<name>Assumptions</name>		<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 en vironment being moved through. Some information presumed to exist for planning i s listed as follows.</t>		<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 en vironment being moved through. Some information presumed to exist for planning i s listed as follows.</t>
	<ol spacing="normal" type="1"><li>		<ol spacing="normal" type="1"><li>
	<t>Path Predictability. The path of a mobile node through its enviro		<t>Path Predictability. The path of a mobile node through its
	nment is known (or can be predicted) as a function of (at least) time. It is pre		environment is known (or can be predicted) as a function of (at
	sumed that mobile nodes using time-variant algorithms would not exhibit purely r		least) time. It is presumed that mobile nodes using TVR
	andom motion.</t>		algorithms would not exhibit purely random motion.</t>
	</li>		</li>
	<li>		<li>
	<t>Environmental Knowledge. When otherwise well-connected mobile nod		<t>Environmental Knowledge. When otherwise well-connected mobile
	es pass through certain elements of their environment (such as a storm, a tunnel		nodes pass through certain elements of their environment (such as
	, or the horizon) they may lose connectivity. The duration of this connectivity		a storm, a tunnel, or the horizon), they may lose connectivity. The
	loss is assumed to be calculable as a function of node mobility and the environm		duration of this connectivity loss is assumed to be calculable as
	ent itself.</t>		a function of node mobility and the environment itself.</t>
	</li>		</li>
	</ol>		</ol>
	</section>		</section>
	<section anchor="routing-impacts-2">		<section anchor="routing-impacts-2">
	<name>Routing Impacts</name>		<name>Routing Impacts</name>
	<t>Changing a network topology affects the computation of paths (or subp aths) through that topology. In particular, the following features can be implem ented in a network with mobile nodes such that different paths might be computed over time.</t>		<t>Changing a network topology affects the computation of paths (or subp aths) through that topology. In particular, the following features can be implem ented in a network with mobile nodes such that different paths might be computed over time:</t>
	<ol spacing="normal" type="1"><li>		<ol spacing="normal" type="1"><li>
	<t>Adjacent Link Expiration. A node might be able to predict that an		<t>Adjacent Link Expiration. A node might be able to predict that
	adjacency will expire as a function of that node's mobility, the other node's m		an adjacency will expire as a function of that node's mobility,
	obility, or some characteristic of the environment. Determining that an adjacenc		the other node's mobility, or some characteristic of the
	y has expired allows a route computation to plan for that loss, rather than defa		environment. Determining that an adjacency has expired allows a
	ult to an error recovery mechanism.</t>		route computation to plan for that loss rather than default to an
			error recovery mechanism.</t>
	</li>		</li>
	<li>		<li>
	<t>Adjacent Link Resumption. Just as the loss of an adjacency can be		<t>Adjacent Link Resumption. Just as the loss of an adjacency can
	predicted, it may be possible to predict when an adjacency will resume.</t>		be predicted, it may be possible to predict when an adjacency will
			resume.</t>
	</li>		</li>
	<li>		<li>
	<t>Data Rate Adjustments. The achievable data rate over a given link		<t>Data Rate Adjustments. The achievable data rate over a given
	is not constant over time, and may vary significantly as a function of both rel		link is not constant over time and may vary significantly as a
	ative mobility between a transmitter and receiver as well as the environment bei		function of both relative mobility between a transmitter and
	ng transmitted through. Knowledge of both mobility and environmental state may a		receiver as well as the environment being transmitted
	llow for prediction of data rates which may impact path computation.</t>		through. Knowledge of both mobility and environmental state may
			allow for prediction of data rates, which may impact path
			computation.</t>
	</li>		</li>
	<li>		<li>
	<t>Adjacent Link Filtering. Separate from the instantaneous presence		<t>Adjacent Link Filtering. Separate from the instantaneous
	or absence of an adjacency, a route computation might choose to not use an adja		presence or absence of an adjacency, a route computation might
	cency if that adjacency is likely to expire in the near future or if it is likel		choose to not use an adjacency if that adjacency is likely to
	y to experience a significant drop in predicted data rate.</t>		expire in the near future or if it is likely to experience a
			significant drop in predicted data rate.</t>
	</li>		</li>
	</ol>		</ol>
	</section>		</section>
	<section anchor="example-mobile-satellites">		<section anchor="example-mobile-satellites">
	<name>Example : Mobile Satellites</name>		<name>Example: Mobile Satellites</name>
	<t>A relatively new type of mobile network that has emerged over the pas		<t>A relatively new type of mobile network that has emerged over the pas
	t several years is the Low Earth Orbit (LEO) networked constellation (LEO-NC). T		t several years is the Low Earth Orbit (LEO) networked constellation. There are
	here are a number of such constellations being built by both private industry an		a number of such constellations being built by both private industry and governm
	d governments. While this example describes LEO satellites systems, the mobility		ents. While this example describes LEO satellite systems, the mobility events ca
	events can be applied to satellite systems orbiting at different altitude (incl		n be applied to satellite systems orbiting at different altitudes (including Ver
	uding Very LEO (V-LEO) or Medium Earth Orbit (MEO)).</t>		y LEO (V-LEO) or Medium Earth Orbit (MEO)).</t>
	<t>Many LEO-NCs have a similar operational concept of hundreds-to-thousa		<t>Many LEO networked constellations have a similar operational concept
	nds of inexpensive spacecraft that can communicate both with their orbital neigh		of hundreds to thousands of inexpensive spacecraft that can communicate both wit
	bors as well as down to any ground station that they happen to be passing over.		h their orbital neighbors as well as down to any ground station that they happen
	A ground station is a facility used to communicate with satellites in low Earth		to be passing over. A ground station is a facility used to communicate with sat
	orbit. The relationship between an individual spacecraft and an individual groun		ellites in LEO. The relationship between an individual spacecraft and an individ
	d station becomes somewhat complex as each spacecraft may only be over a single		ual ground station becomes somewhat complex as each spacecraft may only be over
	ground station for a few minutes at a time. Moreover, as a function of the const		a single ground station for a few minutes at a time. Moreover, as a function of
	ellation topology, there are scenarios where (1) the inter-satellite links need		the constellation topology, there are scenarios where (1) the inter-satellite li
	to be shut down for interference avoidance purposes or (2) the network topology		nks need to be shut down for interference avoidance purposes or (2) the network
	changes, which modifies the neighbors of a given spacecraft.</t>		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 p		<t>A LEO networked constellation represents a good example of planned mo
	redictability of spacecraft in orbit. While other mobile vehicles may encounter		bility based on the predictability of spacecraft in orbit. While other mobile ve
	unpredictable fluctuations in velocity, spacecraft operate in an environment wit		hicles may encounter unpredictable fluctuations in velocity, spacecraft operate
	h relatively stable velocity conditions. This determinism makes them an excellen		in an environment with relatively stable velocity conditions. This determinism m
	t candidate for time-variant route computations. However, inter-satellite link f		akes them an excellent candidate for TVR computations. However, inter-satellite
	ailures could still introduce unpredictability in the network topology.</t>		link failures could still introduce unpredictability in the network topology.</t
	<t>Consider three spacecraft (N1, N2, and N3) following each other seque		>
	ntially in the same orbit. This is sometimes called a string of pearls configura		<t>Consider three spacecraft (N1, N2, and N3) following each other seque
	tion. Spacecraft N2 always maintains connectivity to its two neighbor spacecraft		ntially in the same orbit. This is sometimes called a "string of pearls" configu
	, N1 which is behind in the orbit and N3 which is ahead in the orbit. This confi		ration. Spacecraft N2 always maintains connectivity to its two neighbor spacecra
	guration is illustrated in <xref target="Mobility-SOP"/>. While these spacecraft		ft: N1, which is behind in the orbit, and N3, which is ahead in the orbit. This
	are all mobile, their relative mobility ensures continuous contact with each ot		configuration is illustrated in <xref target="Mobility-SOP"/>. While these space
	her under normal conditions.</t>		craft are all mobile, their relative mobility ensures continuous contact with ea
			ch other under normal conditions.</t>
	<figure anchor="Mobility-SOP">		<figure anchor="Mobility-SOP">
	<name>Three Sequential Spacecraft</name>		<name>Three Sequential Spacecraft</name>
	<artwork type="ascii" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	.--. .--. .--.		.--. .--. .--.
	####-| N1 |-#### <---> ####-| N2 |-#### <---> ####-| N3 |-####		####-| N1 |-#### <---> ####-| N2 |-#### <---> ####-| N3 |-####
	\__/ \__/ \__/		\__/ \__/ \__/
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>Flying over a ground station imposes a non-relative motion between th
	e ground and the spacecraft - namely that any given ground station will only be		<t>Flying over a ground station imposes a non-relative motion between th
	in view of the spacecraft for a short period of time. The times at which each sp		e ground and the spacecraft -- namely that any given ground station will only be
	acecraft can see the ground station is shown in the plots in <xref target="Mobil		in view of the spacecraft for a short period of time. The times at which each s
	ity-Example"/>. In this figure, ground contact is shown when the plot is high, a		pacecraft can see the ground station is shown in the plots in <xref target="Mobi
	nd a lack of ground contact is shown when the graph is low. From this, we see th		lity-Example"/>. In this figure, ground contact is shown when the plot is high,
	at spacecraft N3 can see ground at time t1, N2 sees ground at time t2, and space		and a lack of ground contact is shown when the graph is low. From this, we see t
	craft N1 sees ground at time t3.</t>		hat spacecraft N3 can see ground at time t1, N2 sees ground at time t2, and spac
			ecraft N1 sees ground at time t3.</t>
	<figure anchor="Mobility-Example">		<figure anchor="Mobility-Example">
	<name>Spacecraft Ground Contacts Over Time</name>		<name>Spacecraft Ground Contacts over Time</name>
	<artwork type="ascii" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	Spacecraft N1 Spacecraft N2 Spacecraft N3		Spacecraft N1 Spacecraft N2 Spacecraft N3
	G | G | G |		G | G | G |
	r | +--+ r | +--+ r | +--+		r | +--+ r | +--+ r | +--+
	o | | | o | | | o | | |		o | | | o | | | o | | |
	u | | | u | | | u | | |		u | | | u | | | u | | |
	n |--------------+ +- n |---------+ +------- n |---+ +-------------		n |--------------+ +- n |---------+ +------- n |---+ +-------------
	d | d | d |		d | d | d |
	+---++----++----++-- +----++----++----++-- +----++----++----++--		+---++----++----++-- +----++----++----++-- +----++----++----++--
	t1 t2 t3 t1 t2 t3 t1 t2 t3		t1 t2 t3 t1 t2 t3 t1 t2 t3
	Time Time Time		Time Time Time
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>Since the ground station in this example is stationary, each spacecra ft will pass over it, resulting in a change to the network topology. This topolo gy change is shown in <xref target="Mobility-Example-Topology"/>. At time t1, an y 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 woul d need to be forwarded from N2 to N1 and then down to ground.</t>		<t>Since the ground station in this example is stationary, each spacecra ft will pass over it, resulting in a change to the network topology. This topolo gy change is shown in <xref target="Mobility-Example-Topology"/>. At time t1, an y 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 woul d need to be forwarded from N2 to N1 and then down to ground.</t>
	<figure anchor="Mobility-Example-Topology">		<figure anchor="Mobility-Example-Topology">
	<name>Constellation Topology Over Time</name>		<name>Constellation Topology over Time</name>
	<artwork type="ascii" align="center"><![CDATA[		<artwork type="ascii-art" align="center"><![CDATA[
	+------+ +------+		+------+ +------+
	t1 | N2 |----------| N3 |		t1 | N2 |----------| N3 |
	+------+ +---+--+		+------+ +---+--+
	|		|
	/|\		/|\
	\___/		\___/
	/ \		/ \
	Ground		Ground
	Station		Station
	------------------------------------------------------------------		------------------------------------------------------------------
	skipping to change at line 408 ¶		skipping to change at line 613 ¶
	+---+--+ +------+ +------+		+---+--+ +------+ +------+
	|		|
	/|\		/|\
	\___/		\___/
	/ \		/ \
	Ground		Ground
	Station		Station
	------------------------------------------------------------------		------------------------------------------------------------------
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>This example focuses on the case where the spacecrafts fly over a gro
	und station and introduce changes in the network topology. There are also scenar		<t>This example focuses on the case where the spacecrafts fly over a gro
	ios where the in-constellation network topology varies over time following a det		und station and introduce changes in the network topology. There are also scenar
	erministic time-driven operation from the ground system. More information on in-		ios where the in-constellation network topology varies over time following a det
	constellation network topology can be found in <xref target="LHAN-PROB"/> and <x		erministic time-driven operation from the ground system. More information on in-
	ref target="LWOOD-SCN"/>. For this example, and in particular for within constel		constellation network topology can be found in <xref target="I-D.lhan-problems-r
	lation network topology changes, TVR approach is important to avoid the Interior		equirements-satellite-net"/> and <xref target="SCN"/>. For this example, and in
	Gateway Protocol (IGP) issues mentioned in <xref target="LHAN-PROB"/>.</t>		particular for within constellation network topology changes, the TVR approach i
			s important to avoid the Interior Gateway Protocol (IGP) issues mentioned in <xr
			ef target="I-D.lhan-problems-requirements-satellite-net"/>.</t>
	</section>		</section>
	<section anchor="another-example-predictable-moving-vessels">		<section anchor="another-example-predictable-moving-vessels">
	<name>Another Example : Predictable Moving Vessels</name>		<name>Another Example: Predictable Moving Vessels</name>
	<t>Another relevant example for this use case involves the movement of v		<t>Another relevant example for this use case involves the movement of v
	essels with predictable trajectories, such as ferries or planes. These end point		essels with predictable trajectories, such as ferries or planes. These endpoints
	s often rely on a combination of satellite and terrestrial systems for Internet		often rely on a combination of satellite and terrestrial systems for Internet c
	connectivity, capitalizing on their predictable journeys.</t>		onnectivity, capitalizing on their predictable journeys.</t>
	<t>This scenario also covers situations where nodes employ dynamic point ing solutions to track the mobility of other nodes. In such cases, nodes dynamic ally adjust their antennas and application settings to determine the optimal tim ing for data transmission along the path.</t>		<t>This scenario also covers situations where nodes employ dynamic point ing solutions to track the mobility of other nodes. In such cases, nodes dynamic ally adjust their antennas and application settings to determine the optimal tim ing for data transmission along the path.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="acknowledgments">
	<name>Acknowledgments</name>
	<t>Many thanks to Tony Li, Peter Ashwood-Smith, Abdussalam Baryun, Arashmi
	d Akhavain, Dirk Trossen, Brian Sipos, Alexandre Petrescu, Haoyu Song, Hou Dongx
	u, Tianran Zhou, Jie Dong, Nkosinathi Nzima and Vinton Cerf for their useful com
	ments that helped improve the document.</t>
	</section>
	<section anchor="security-considerations">		<section anchor="security-considerations">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>While this document does not define a specific mechanism or solution, i t serves to motivate the use of Time-Based Validation and Revocation (TVR). Ther efore, security considerations are anticipated to be addressed elsewhere, such a s within a TVR schedule definition or through a protocol extension utilizing a T VR schedule. However it's important to note that time synchronization is critica l within a network employing a TVR schedule. Any unauthorized changes to network clocks can disrupt network functionality, potentially leading to a Denial of Se rvice (DoS) attack.</t>		<t>While this document does not define a specific mechanism or solution, i t serves to motivate the use of time-based validation and revocation strategies. Therefore, security considerations are anticipated to be addressed elsewhere, s uch as within a TVR schedule definition or through a protocol extension utilizin g a TVR schedule. However, it's important to note that time synchronization is c ritical within a network employing a TVR schedule. Any unauthorized changes to n etwork clocks can disrupt network functionality, potentially leading to a Denial of Service (DoS) attack.</t>
	</section>		</section>
	<section anchor="iana-considerations">		<section anchor="iana-considerations">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>This document has no IANA actions.</t>		<t>This document has no IANA actions.</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="I-D.zzd-tvr-use-case-tidal-network" to="TIDAL"/>
			<displayreference target="I-D.lhan-problems-requirements-satellite-net" to="
			SAT-CONSTELLATION"/>
	<references anchor="sec-informative-references">		<references anchor="sec-informative-references">
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="LWOOD-SCN" target="http://personal.ee.surrey.ac.uk/Pers onal/L.Wood/publications/zhang-book/zhang-book-wood-chapter-2.pdf">		<reference anchor="SCN" target="https://link.springer.com/chapter/10.1007/ 978-1-4615-0431-3_2">
	<front>		<front>
	<title>SATELLITE CONSTELLATION NETWORKS</title>		<title>Satellite Constellation Networks</title>
	<author initials="L." surname="Wood" fullname="Lloyd Wood">		<author initials="L." surname="Wood" fullname="Lloyd Wood">
	<organization/>		<organization/>
	</author>		</author>
	<date year="2003"/>		<date month="April" year="2003"/>
	</front>
	<seriesInfo name="Internetworking and Computing over Satellite Networks"
	value=""/>
	</reference>
	<reference anchor="TIDAL" target="https://datatracker.ietf.org/doc/draft-z
	zd-tvr-use-case-tidal-network/">
	<front>
	<title>Use Case of Tidal Network</title>
	<author initials="L." surname="Zang" fullname="Li Zang">
	<organization/>
	</author>
	<author initials="T." surname="Zhou" fullname="Tianran Zhou">
	<organization/>
	</author>
	<author initials="J." surname="Dong" fullname="Ji Dong">
	<organization/>
	</author>
	<author initials="N." surname="Nzima" fullname="Nkosinathi Nzima">
	<organization/>
	</author>
	<date>n.d.</date>
	</front>
	</reference>
	<reference anchor="LHAN-PROB" target="https://datatracker.ietf.org/doc/dra
	ft-lhan-problems-requirements-satellite-net/">
	<front>
	<title>Problems and Requirements of Satellite Constellation for Intern
	et</title>
	<author initials="L." surname="Han" fullname="Li Han">
	<organization/>
	</author>
	<author initials="R." surname="Li" fullname="Richard Li">
	<organization/>
	</author>
	<author initials="A." surname="Retana" fullname="Alvaro Retana">
	<organization/>
	</author>
	<author initials="M." surname="Chen" fullname="Meiling Chen">
	<organization/>
	</author>
	<author initials="L." surname="Su" fullname="Li Su">
	<organization/>
	</author>
	<author initials="T." surname="Jiang" fullname="Tianji Jiang">
	<organization/>
	</author>
	<author initials="N." surname="Wang" fullname="Ning Wang">
	<organization/>
	</author>
	<date>n.d.</date>
	</front>		</front>
			<seriesInfo name="DOI" value="10.1007/978-1-4615-0431-3_2"/>
			<refcontent>Internetworking and Computing over Satellite Networks, pp. 1
			3-34</refcontent>
	</reference>		</reference>
			<!-- [I-D.zzd-tvr-use-case-tidal-network] IESG state: Expired as of 05/20/24 -->
			<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-zzd-tvr-u
			se-case-tidal-network.xml"/>
			<!-- [I-D.lhan-problems-requirements-satellite-net] IESG state: I-D Exists as of
			05/20/24 -->
			<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-lhan-prob
			lems-requirements-satellite-net.xml"/>
	</references>		</references>
	<?line 410?>
	</back>		<section anchor="acknowledgments" numbered="false" toc="default">
	<!-- ##markdown-source:		<name>Acknowledgments</name>
	H4sIAAAAAAAAA919W48bx5LmO39FQXpw94hkH0vnZYU9C7d1seSj26h7bOzC		<t>Many thanks to <contact fullname="Tony Li"/>, <contact
	wEGyKtksd7GKpy7doiwb8x/2af7e/JKNLyLyVixKsi1gFkMYFptVlZfIyLh+		fullname="Peter Ashwood-Smith"/>, <contact fullname="Abdussalam
	GbVYLGZ92Vf2YXbn8oe32cllubWLH0xbmrrP3jZDX9ZXp9m/dTZ7ZDrb3ZmZ		Baryun"/>, <contact fullname="Arashmid Akhavain"/>, <contact
	1aq1N3R7f9Muhs4ucvk9N729atr9w6ys181sVjR5bbbUbtGadb8obb9eJI8s		fullname="Dirk Trossen"/>, <contact fullname="Brian Sipos"/>, <contact
	/vI/Zt2w2pZdVzZ1v9/Rvc+fXD6d1cN2ZduHs7sFNUn/5E3d2bobuodZ3w52		fullname="Alexandre Petrescu"/>, <contact fullname="Haoyu Song"/>,
	Rp3/dWZaa2gQOsI7s9umvb5qm2H3cHZt9/RX8XCWLTKezo1MB3/r/fj6slmV		<contact fullname="Hou Dongxu"/>, <contact fullname="Tianran Zhou"/>,
	Vdnv8f271to6y5vtzl9+a7tmaHObbU1truzWUgM3th5oRFkmPRHJqPlsRK07		<contact fullname="Jie Dong"/>, <contact fullname="Nkosinathi Nzima"/>,
	dF1mc+dHGhT9Qs3T7fh9a8pKSPcNCLJsWr7dtPmGft70/a57eHaGu/BTeWOX		and <contact fullname="Vinton Cerf"/> for their useful comments that
	7rYz/HC2apvbzp7R82d47qrsN8OKnnxlOvO4r3FhsWrW8bqYod80LYhBD2TZ		helped improve the document.</t>
	eqgqWZcnRfZt2bamtnyB+jB1+d70tBgPs++f/dvZ+ZsXfMXKqG1xa9piuZJn		</section>
	vvl5M5hdtbTFcNj0qzJvKtNlfx829UTjlxtT2S47r2xdmuxiZ3Ibd1TL08tr
	eprn/80VLixpeQ67+t9E3/cbWrx/HSZ6ejr0Q2tvbZld2nxTN1VzVdou7myv
	z3+yo7dlfp1dmn3VtBMdvW7L7HldDF3fjjpo6bllz89907QlNX7Y9osye78x
	4LuDhp8NhoYfN8h3VuWDv/71mw1f5PHO6qbd0jM3xJ8z7ED/V5a9+PH168eL
	i0evHnI7vWmvbP8wA7sRt+1s2zW1oaW0y25oW7tfmnw5XJ+90QtnL5Y/Nk1x
	thtWVZnzuLozHgXxWnMdfV3c0n2LfGN2vW0X95e7Yi09QsJkxKcX55dPXrx4
	fvkke/T61QW+n18+f/0qe/Xk8sfXb/9+cYdv532f3f/LXx7wn50FTTEnGT8+
	z2vqobb9re4wUxfZI7d9s+bGttkFtVLRBrfZK7lPlsXvB/2UNcmVF8sMU/Q/
	6rJUzb5wFy6fPz5/cUhA7Fcar+lbk1/bNuxXkn9nIvrevy8Sybfoy8JUCx39
	WaAQEcgJ2qxZk+yi29zg70wMfnEwif/jmCiaRBn/Onrkkh7ZNMPokUsSZ7TH
	40uj575fZo+bg66+L+NfR4+8Wmav3pdbM3rm1XVDS2v6Tekvv3h2/mrx5u3r
	b/8QtSvixsWubVaV3XaL1v5zKFuW3t2icxwB2qd0f6MPMCO9jR7CQgROekSs
	j++8CTLaZJ4RP299npn6cHnCj6MH3i7p8uh+EkMbEsPhwuiZ8yUNvyeVNXru
	vCIt2KTXRo++XGaPSBKOHnxpSUvSnoouHc7rYsxCNK2LI7xDPPd9ecinYLqf
	y+TSIQf9ePjcKwyOf18sFplZdeCNfja73JRdRmwxYBmpgb5tiiEntUPbMGPd
	mN1ubGuzKYuH7KAf3p6qQSASLzspl3aZtXpDcqk3LISokyaDtVIWtnWX0PqK
	uitIsGddviGFWdEfOYQmjYGeMJmKAnQ4VEVWbol/b6zvi/7qG9KJaJsk25Wt
	ySwhRj2jFvXRjKQ4y3y6tJwxKbZlUVR2NrsLHuXJY0QgDGZNxDEwY27RgVhc
	YPUxcaJh9pswor7ZQZfuyXLBSDL7bmfznqa1M22Pdtywmp2jxJKGgTaog9AJ
	2ty1drGrTF3T41XTyRZsbdc38iSaoy5M8TPZCXW+n4OQqt/C1QrbkPZpfF+3
	YXKuLKkQshAMplw39aIou3bYQTtmlky6ngj2xE0gnrBMknQPjZY6yvOBO6ZW
	YFHafo/OyQ7t3PR01kQ8MsyyLQxMSz0WtqPBDPkGQxjqrczVkFoj+X5jN2UO
	cwjT7hqyJ5t2VTKVO1hGOaQac5UXPNQabUnqBtQnkvVKsgURzZCO7jZoHrNd
	D3XuqARab9XmdX8T3XuQcmL4tNLUZFVSg0TUnHYOE2XX3No2zMY/QkLphrrH
	sG1NPLrP1m2zpZZoZDIzMmll3NQa0R6j2JZXmx7rg+UmQwkLgC1k296UNe8d
	FsCF2ZOMKbcwiyta2DIa664tyazqy/fo+iq147lnHY5dr8u8BGOIeQA1khGH
	2blnVpIcuCkMy7ElSc4htJQTxTswoed6Ymht8KapSOB0y7H8Key6rJnhaYSZ
	+kqlzG685wxvMxuLGD+k2mIWpqr2XtAwmTJv8jX1MntiaHVkiZPtVtZ5NRS6
	79ZNVcn2j5+dzb5eZuc10+imtLeOU1wjNJMub8sVnts0t4dD7XSsna2IOFlR
	rtc0KSLBjpQ8SVFIwWHFf5xOMCnNZclDoAZYkpiuG7Y7bdkUNlvt0wEZL51o
	/5O170bsVhU8wGtj38nm5vYvaOlKLDYJg3xgFzRr6kTIkRgmTu3GFODHn7wz
	211lAxvSaoj87d1owv0QuYnQMz1vXbeCxEHg9oRhcD1ZJVkZ75W+oS1DKyTc
	caKLIg398ou7axHf9euvp3PlsN6pgGjlSXViy8sGvYEH6kTFjeMxGjaGlFcl
	RliR7KyW2ZQLzPKSvlXle+tkfEHb26TS57AvIl1Da73Fc279iEq1dRIDix8p
	W5JLtDN72pmkehr6CZJECLSLps5L9lpUET36JIiCMeX8TYtw0xThDLwSEAbC
	IGOdAJaWP4fOXFnoiL13Rpivj9OKJEnVlP1HaBVaj2nEy8EjkLu6PWmJrWtO
	pQG4r268soyaoonYdz0RT+TuCrKHDZbC7vArjdJvzhIKyBTSBKsjA81JhH28
	J0uMdtJbS2LHDXtMWL1pEd/0RzmS4zl8x4p4BBKfdazjDGeDgCA0i0XfLJg/
	aNp/agk+zq5l7Tw6J0B04wcd0NAYaSHAuhgQPd1aZtNaukVAwIm9WCH0URBr
	2gDN1dCJ1INIryn7MFvQr7eRQIKs8bpM+OAKus7g74h9YxUsnFfnre3xMEtD
	MRxoubHGkYCm5rdWJSMsW5J5YjSWxFI179WGpjySs3OmFT8iJDI1afF3GzN0
	YrqR1WqDibhrqK0eFpUbDdk0zOJVeW2rvYhd4TPuOdsOVV9CiNuxMOdbHU1J
	3hmaPltUJbN9Lnob47mikdRjUe9XfE1fQGAaYUF0ardlTR3TVunIQqX1bGiM
	r2CQTl/0VpbaiOBk/Yrl3w61hmMwS2wVJwVyMrvdH24wNDZyBab1xy93pzXG
	bHYBg1R2F62r91RUx4t1D973cnfBoqEl883CYLop26ZWR5ocDJD/tiRqsYFc
	ETv1LCDYeK98I0SWR66ZPpBB9x7NXq1QNLfFc2yzz1nVEzlXDTxkdiCuLG9u
	2hFuQ4Amsoz0n22GLvgoItswWzaHIUfKfGC7tT2MBmNVZWT8CPej4QZlIDVj
	nQg1LDNWOnpsrZrNoWa9PgWfiyjmAY4kD7ePncAjKndK88jKodX9EVFQbhoN
	66CIMdqhriEwyIyYs/uTw1zOiWxuYJ2zfPgRb/2SMYVFpOGhs7W54bHqMNlt
	xO1VuSZynav/RdsB0mE89S4a0tbsR61DkcPKSeaKPTVacJGY3a4R4QkRAvct
	eCNs5pGjDMuTVR/TJJCCRlSAVXgeN2VTiT1gPCN55u1BKv6JZBN8H9wX/AKS
	QaLYPFUMvAcy55iP2Kl3bXZmDceLRkCWSlnBvLdX4CrHeCzMiaJuJ5OHEPw4
	nUPVYMEcS/t9gsWVhTXx4uWbpums8NRObCOQLzxGV9YDRGxBVjpcIJoEj582
	pFCR1yVajjX8FnZI2QVec2D9kOASXJBRmKpjXZL6NtwghtXCuIL28W4W9Uk6
	lrrpweDUaWduONABO28gcY2feSrE7s8REig8vVOJIKJAyTUXuRP2cB7JFnCj
	qIPAocxOTl0khqQ4/I6KUGxkmhJ3kKnnNRWZhWJ6ePV2gsEQH9Gc/Y44Tfb2
	aDOTUoDEDfxRutCJZ5QucQl78baRwUvsAtM5RR1M6LhfF+2IbPwuxHBwR2pG
	kwq5m50Hj4z0XQPPmhuHkhXxGITwSPZJHKyONranZmBh0u88i9ZuwLud89QM
	vvXsapF8YZnG9gL7GWoxchxkh8RStxEhvY61ynO1eZ2tgzUmaQrZ1QWT0Sst
	7I+b0nOMRNBUzTilIVJjXV4NqkSEm1jB2boZrjZuv4MCwpaR/SiCD+YRzYcM
	QNkMsB7Zbg9OeuwHs0UFX5h7YccxMkHIJP973dwGnaxSoMSW9UTg9hwNIrOo
	kyCUM0l0kTTwtCl33uZmVznsBb+iYR8Z1Wbhrtpa9TVGqswE3j+Xh2/Z/MID
	rA3IG2mhtAsIEhKTfbYhVt2SsczDDQIU0ik0LpuH5VtBG3DHDhlbSvO4Tw7W
	lDL1WxCkE0tXNzWcAcduZsseJzHLihlnzxqQvOG1ipDK7PpmdxjaUDNUJSf7
	iOw+vXHORrQbgsBjqTq9YslNqWSK1qCN3Jkqlm2JxpAtIZIKbiBu5WC2szLt
	qSd8ZFI3RMJ3cLp/btJFDBQ9SkgXUrglgxZGlCNnTMTbkgy3lXhGe0ir9opU
	IqgG+5Dlay+urLc0Jql1xHwLlsHIAk8UQPzM2tN1vLxTmy3VXare8zBylQ9g
	WXYu/d5nOeu80+cSh5rNJiAJQTMEr0FWtKxvmupG7CzmelLopOx9UsvrgEji
	e7E9QS+WR7DJRI+4qLhh4a/RVBc4q9MQ+a3ZdyKX3rAdcmFu6DZaqde+P1Pw
	yI+bhqLCVSU5i0w3Lh7bmB2RHYvKlkDihogQ70Y2drJ9Y4I0bejWBNtbHGgN
	0fNopCf25jt4pL3prpk5L9X0+x0TLdcqhDXw583RKJcUWenB5jUIzeTIQjhB
	Spf/89//IzYfervl78SSEvxUO/Jzx1c7RUPEH9pdI/lpZzByF8eNxtR0FROS
	RQtbjRyKwMPqwVhYIiZ1bzunhsOWdYZLSczs3Ck1G10kiUfbEJ+4iFQZG1w+
	VsG+IzO/57DU1z0NksCnvUYhZuxqHlAxV3HmYscaHjdVrhKAUwC86xOD71xN
	WYRuOCbmCMGjhXTtIu9b5qiLZGDE89egl/GAbPpkPcZhcUQwEP+G+acBEjTa
	m2vOfeRO83PGT0ILROMhkR/MasHMo/ZJ/KyallwQcl4eD63K+04kPtl5tI2A
	JNJWMQ42Xg8dUJ4Xkorqb/LW6/Z1ThR0CBkRlRqOn83OaTdUFWA4RoJEGtoR
	wa1TF5ud46PU6mTEmDVIrRmfRZTcuiX3vkIuDJC0kH/lgIGLBshPc+WlFprS
	vstpVGIjw0YMNib2hmptNl3S/BqnzUg+17aKt6n4cxyBl826rsg4HcD/3saG
	AEZ4Y02M2LQu+cN0lKG7NNw89nELSyK/0FiKW5KvsMnUt2XjF76bZqaEQ26Y
	v7AbNUkmc6LVeeTSVAa2ANZCcmC81G5FxDnksKHoJO/vdc71112TEkQVSjA+
	QcK3kGHZU8RiJMb/9umpE1aS6IFdsoGFvLIQ8mnORHlp8aZq+u7XXzVvTY+w
	jU+S14bsWjSXLjuB15Z9PWfvLbsvJOTvD05JP93wVg3pMGqe2XIU44jjrazd
	HAuLQePSR2okwz5CmFSeBf1ZgrtQw6jtUj093kgYOlGhCjLLU0UybBta5vcN
	cyi75Y0GdjFyWtjffvuNxpSXAaFCHyFBdvgRmhy78GD2JvswcZE+cmEhn8ML
	+lksZg3+jm7yX/jCmf7xU9RCE7VA13+a3WYffjujef32E/6Hr/QFV/2F38JV
	f0E/4cGZzT6che7OQr/hwmgw1g/FPThrw+j8pPifdkQqTxm6MKITfaXVuUf/
	3MP/wv/l8u+5oKvc8+L2vJL9g2gUn3khZhbOxUx9PnoBjDf75SEZSiw7FqYq
	r+q/3SHzl8y5O/5nQHD/docZ9E52d3p3C/zrb3eYB0WUvMb+QDd3fpVg/mHs
	pOymRNhhKIXECizfoFdXqSvGGhgIDnGmnM+1ioP74v2OTBMeQrc1nC1KtdAT
	l4lBCikeOTqS3T0t7S4UmQSBJ3JHxB0/xPlOr0gnE7NsIYEorOQf0qrPac1V
	jTwgcfEv2XkvdCGGUDHhBeR9kY80zbJ1NmgUJXeUipNUEY2WceP31UVNgzxO
	LiFoEKQk2avzbDX00T33I6nNDs6on6el2mjGdfjgYx1GhjR7RnHXqmIne+bQ
	opPrakEF0qhuFju3brRrHweIFyYR1DO/ufVzz22sT/024138IQh4J2kWH4Js
	92LJ/UZi4MOf6PPPDPf+aLjjod2fmMJ/4XAffMZwvzB1v4gYdWLDSdJL7yHF
	cvTuNPjil7uTcItPZR0Z66cbIoKAryzJkFKcd5+V31rgyjga1OQly1Pvyjrg
	hHE2ro/pIulSVjYJXqbuwRgO9QnkDVIV9EPHAADOMLQ35Q3yFEnw1oGR+LZ6
	4e4K2DVEXZxrwIgBkkY1Ev4RNERSsiG8o3Z86nJoMvQEj50KCE2kDEkjToBq
	PlHtTG2109vYfgRukyPGCiFrjYTIhxjOQeyDVGO1d2FagBUn1mLQkAL6T9ta
	ZheieQR2pxC2KWyUJE24CTTnx+ZdtlFQwUdQstySzwi/YjQNTkXszH6kb5zb
	Gjz5w1GHAXXDbleVbrKMiiOWhM5kt9d7mQ4a0XKPcGQkgiHej91jUsvRPOFU
	9oxCClBBiTn6IJ2LBmqIiJ2WEA5KI4E1uBgoV+PDEUr28ZrlTVO5QC4/i0R2
	SAS69FF3yiP+1u6Rs025FT4mWL1z7UxyKAIzXnZEGWSXXERitXJw10n2ihiY
	szfwU5WJyJsp7Y0ggNoVDTuHeRZhFXAnUCU36p2P8KVul8TSRHaIlykhJn9g
	IPqMF8yMJI8XRco56M7BtdiD7TwAQ+WcEnSKhN08TOeYOAySbyLDF+ERQhRf
	cBR+jQ7mm6Tlgk0MIRq8WM89mnnSkJxRuGwCIGEOSzfZKckGliobA8w/GUqI
	3rvoVGdT/ImY2l0vzCKyQ8PSj7B2L2l/UKM6VUm/RRDQAy7UwUrMIwxTFhMZ
	PbRWZDqfOL1wCzjzUwYQs2ibB2pgHRfU02JV9oJ8RlhVY6JOSnlwfZs+c13S
	lEzPD6pMYZwCZn6NjODST/ZNgnDDwY8E5x/Ne3JBfYs8veKGjx2kU9Joq9sW
	Oh7kjiCKOUnCQXNNfQPJoRqI+N1HDQH9nk+kJ4mEYul6ic73+0CsnqtgTebn
	bFtNvBzM141ynHFPVnYnz+sRgG5QpdxHKUHm8ZA98iaJMoUpfh46QTwpkEVQ
	GjxmwYHQDJfZ87WKXT+Zhkz/XVkA1xcn4MRFQIxbfMeQR6aLxMu5QyOTqRSB
	n4XfzVVd9gPATpec5dI/ha7IwbsYe3eYNUwBHODs7bANISVpgHhMUuZeU6q8
	UiPr3OX24TSxdKA2m0LycR2ZoyygQG7ZTY4n0saPJMteS1dJhDdm4Sh5dQi3
	d657lL3sN00Xz1sl5zTemCk6geI3smRuWTcJxAmwXHFGo0wDYsDQOau9WAoO
	53zr0Ik+oqjLGpOYJ6lC+iATMZmmm2t+a+3Ssm1s4o7l5gskLZ+WsMc5G/cY
	0sqH70MQt4gyN7dGDrfILmLZ5QEkwgW4cqDxEIYtyKYpBglHXusOCb3VRNnY
	QOn6BEwcsbCeECoVsAqsVtMsNtSSPCZtYqFWViToWo4cadpC044x7mXNROgc
	1aIeTKttnOhG3U8fzYGj5SX+yjLfYskKNaGGFiLMg0Oe1ylEOADTeQqdZPYO
	FP3acuKgYRBcalGckJbpBqQT6r1El8a3nLqUhhCotcCQcZ5PSCNjdyi3SEBG
	R2OcFKenIAvL9T4bLTQfr0jsGNXMkoWOrF/VsUy+fw7GISbLlFE6F8bZDeoX
	QZ8ieDY22QTgPbU4LIyQxKSNdtX76D8eYGnNT7ohMNAwnv0gULxkThGQ68Q5
	InnVDIWCN5A6XUiyFDs6d1zfyOrBU2Qkcvb26Si3gaeRbd2exsKScanjwJka
	Zg7b7oJVpG22NKQ5K2Uo8nD8a+QgIaHgMb3c80i784bWE1yM2bPJ0SRm4bmH
	8IRktwdjRae21gdJHH/2y+HUg0FvIvhuOOu1zLIfVf4Im/orzs/hE3Xscplr
	7F7YNr2RDLE/Lee8ZeDypdqCtAH8Rpf957//32zV9BuFIu0Xplvsm2Fx1Uh3
	7KCFfRmfKiOd6NEiLqmuR8r4MQZ2MhS1ge+22zVtP9QadGUt5UCcgnruGDA7
	VIwTkaVxvdXOxIdqCXFFGFsDDhji5higqoZPODEYJ16zh9kjZ53qgXXSwPWR
	/KuIrFiUkIq7TuI2o571xI2HJcZD44X3trGLfUqm3fQKGpIFeV0v3lgjue/X
	67X84VmgC6k+OX8QCRIdrGbcK2Aa2JEgwf8O0AMZ2h3t4A4soqG3seFk3+XW
	Fj7IMrIZZZU43BU2D8upK6tToOF9x6cyqvj8hd1xI5Mzc4MIIpf9kDjgYvQE
	g0cF9MpLt96vHXsdCfyLdibmQY1urLnZw76oPMd6wRbZ82iChAEptdn3A3vr
	2MX56BiisG/eizTmUbfBB1SX/FRtiM2whYB348RhTI2rHWuZUyyFGJ5JloZ3
	jEIyIUtqPnOhX7OTl/dfnqYc1kQyKBB+FGjCMP2ZVlLzndfz/kgiWeOkdal9
	fwjVXeo8kksPj+uBXBfgic7iYivRsqyG6hoGiRVpQNYh3bQbuo2E7tb9Ldsk
	O5TZwOMeUOFEDrSHO07Reax/dHCAYfcikchI7SagYWL1DBz5MxV5IsU+OvwO
	TwUuA5+b0hgCrQqkqgRJWdYRe5BewOBhFXuBtrJHWorV+mcCD+aphY8cN0nx
	kpXbOKI7wgXMeUfvehf9C4IjDRvzZbayk9xgl8V+p3i6CUNc+uZgTzhMiy1i
	zEIImn8atWC0jop0B0LsOAWKlWIZMOfJg1edjhahdxzVQNo0PWksD6i4kcCH
	xzv4/QkvCWAuVHBSexlZuXDnx6W0yKcIsuuSmjxqTVoCwTASY6pGQLsT1+pp
	5gHF8T3sCZzoME5TqMNRgMOnIQ6zRz6HExIx/Ocj5KLuTTwpVxZx2iaAFkaA
	Cb4wCaJoRj9/mHXHGumONtIdNNL7sY2G3uPWe4vRx1+JPu6m2ZFOJ0aYDGES
	qbAITX/eFf7nU/iGz7zyuRCHT1z5Q9m5Y+LAJefYPecgQYJy+I4tAHfUxVmF
	cjYCW0920lTIb54IsUSASSBbd4sL/+gOIVkbJdhXISqB404xgkGkStJuN0Yy
	TEw6xjI8FWhhJAjZElSD+WvFJ0RWsvG+7/S8OEDp7fCRPyX2vYcifDz5Hm+b
	z/k5zcG/0iT8i9c/4qr/WRPbz55/9yz+eTJZ/LtH8AXmECfm3RzGg/3/fQ5x
	tv4Tc9D1+cJz+ELSYZy9ZwHxxHG6hBNjSSFZ8SToXPIhzJYs/7Ilz1WCErA2
	oEQBdlWPrmDnOByqHm2cRFo0HhATEEOaxq6zfw52CBtNbxRn3uFxOIBoq1JQ
	zY23VhKT6hMiBCYwyY8DmOOX3ai/o83sI5/P59ojn8/n2j8zgi/FtVibQ50m
	MRk92sCok7vZeS15zxCmSIrqAS8uN7g4BaOZFXTnIwxREArnBtjeh37qLdI4
	a/imciAZzupXXN3POxhfsYPJVq7z7DQQykfarlATAtFFnHBEiQQH5JZzfnH9
	HGf3mmvLGHpfjAC7LafhD11wa1xUuBk6wLnTsGiXXTW8ASvTdW3TaNm7qly1
	4qek+Tc5qMUnK3s+3C6uUkEuddlLFSOgRuB96h6LohnRaWda0SocVhsXXTJ5
	i+JfDrXOERYmguZZ2dLgWUogUQMgPc6fyfnrmO7+ONTcYfglIo4M+KYpJJQT
	Y0kKy96rH55W4srEodzuyDfSg1P+FAGcnQnX1yEZo4oUfJwIQRI/aZ/eqQvn
	AX/6CFX2pml7jg8nY3BWlFRcknxEUXaIE3DROVvLV38ywJHcnXzVBCvigEiq
	BTzGQajQO4XKIZKwY7LAsRqtKS3US2zVOPxC/yVb0A1+zRW2WBxzpU2WvXen
	a8v8cneymkwKWUL4B0dYNPekxdhc+FIs12Pl0OQcJAKhk7eh/VPmoNwwdCtN
	Jh87JRQXAopz7MLLhUzJn63xrSiBWJnRM8QChk/jSWd8oK0PAAJ/HMMP2p0L
	4rDzttG6Dd3ozLnHiY2qXsUJcB2pJkNwoN1cJUE1xYbYQsgbBbl9YT9f2sCf
	p4xyZXGMxxUFoPVgPtLZcC6Hqc5pCzSb1AfUekE0uc5yPMilNWPU3CFuLJAr
	7cCnWfzpqtvGVRvCMHOIiYojzHqYk1fCPbZw+gQ7rR4csQZX+zAqEYj2qqYb
	Ac4FnVOzKJKY/xgKHpUAmZyLoyfnIBEuQ90Do5JZs0J+lmyGKVQoql54UJ9A
	DMFtA5E6Zx7k+i1jIE7YIvFiSVLOQwJycv0cdtnhlDbmvWlFrpAsQWJScjod
	dZDCgo7M+nNXEEW6yKQs8+tqH7JhrPG2WmdMihFUAY3vWZgZ2tMzRV17nB5o
	vNuFtHRctkeP2Ffg/J0cnl8rSCRgvuPDVswFN4p2daUV7ZbkNKfUsXor09ID
	SEXjbBCvfjrgY0wWMdZEDhTp1kbhFi+TwpZIBvBJQjmXKodxb6wr0wBr4EqP
	+01jaTnYCwsu2FnL7Flzi/07F+gjT2ONZCgRjzwAcBr56BIPOISTlq3nBpW1
	NZO6Z1mZVrdbR0niCgXOkCZRrePOMiYFELosRq65KngJjNeUWz1tTM3UGhAO
	VQV9FW30LlRd0GIOeVp/dGwsTGDz3qRH6gMer052BI7pHYBRdPcroCrW0eND
	n2ldRd+qPyGYXI4VhsAYiGOtB8sqZC/uTjGBsrfelSHRKHWLON80Cdt7A8TM
	GMmG5WYoDRuFiYBViTNG7FEHEtg6CUgtr8kmalSeGBQ/NABOizaXggNhGrJZ
	IvEZpYtdGTdToQBovyFG0UoXDXKEmxLAv93Ah0ZbojDtaLfvDnARqPJBhh2y
	BWz5ROW1bFUtdI/TiJLB7EwXpK9LS40qA5RtCr0MUGlGFsDj6AdqvZo7EKIe
	FjyV/QohcCBnZG2KIc7wSz2EIIpYR8TVG5ooPsiJr/FqpJw+gXbHettqfQQm
	9shB78yEcc4AH5epCTsHUICJYqYJHNxv2nElscQAydaWN4+34TlRhVE75KjP
	mY8rCkep5XGNVY+JUtBLXMRP6rs6W4kBXE/e7Up37uF8dATbHUoLqF9kSaNq
	zKJmLJqYWBx/nuCrzq+RkCCom+RSo4dTU0tiQrYss8cOU+tT6vGwkFKSURWS
	0O0m6+piaohLCdweG5sYcI5E04ZtAYBR7dogNqwVx9qW9YGemd9aCOyy2y4P
	6frWB9OXmct1Txut+X7Cgi7DocEI4ekWgpNWhwshMkjKcsKffIvg2jlbFLy/
	ZQ8KTIbXNuTVFGUseAAxoqVcpSv2mSDX2fLZi/0UxS+m0G0ccP+IXxIKSWAA
	HGfIbcmj6ViSOcIdqpbwZKRgvFj0nSfiYXT2notGyIkCuLCselSryvADPkTj
	OBw6EE2rpVQ9P01wQQSPvLAkCHy0kxV2UohQCl3mEndY6ddx8fPj1aFD1Tes
	GtfPi/mjXKfwx/0IySFb2Fv6xhd5Q6hpfVD4JyBhOcEeIlios4RmPCtH8KsR
	ZkgNSf9+BZLH555TAG+2tx4X6WSfL4FhpAQUW79exLHyB/5Rnb89zaNz2fYX
	tL5PSBRvstcosZ6dvHjy+tS1CNsrebsDri5ePTp1Re2MlK/zpfJZ/qZ12ZUr
	VwOtOXLQzHy7FmElUJZfDyNMeIXh1rol3WGz6LC/w9x2GY0i8y+u6LTCbzeK
	Xyggw8HM9cARV9Bzr67QB0N1+URxmKoX8PdJKBPxAwQcuj/5YcGUIkZ4SWs6
	bFMqvqRryJIzhEWI1rl6Bw5eMSqX5mBLm6EuiE06oGxGwcoAg4rK4AuiKz2V
	K1SOTH+eYVSJpIvlSAFDj0X5nt/iJPXYQsaTzRctJiTGB+wlhzODghw9xdA0
	ck1kIZyXHY+PhxYtYcklG5WGPFjFi09VWePyPh6GFpFC6rfEF0cDk+BEVNOM
	3Vj7DlRgrETUGERaU1esbVQPYM7EiKNGBXG1pn3pwGV8JkDsYAT7GnbaJkG0
	6fZyBpI73cFpXV/DSuLXJ1+fqpjE+4QCL4vH5mrDIfS5GXpZWgmM0+3M2BBO
	N01ZcABASxfx6a6T+6dJ9CtE2zZaS1ZlvcDEOr3ZMVSEnAtUXEJ6Cf+Hws78
	mo2mKWIkpAttBVXoI7ObqeLT0UKVteMYERpJrMa/SoKLWnpk3lDHVQeSBAM1
	R4K2ydn2irqJCvuapFqNO/TgRXQnrbpWIlyzOsXh6NMWIRUhpRx7fAdMkJ6Z
	KsqCNWPTHpa7Tt8vEMUGpviC9mJZiUnNfhXZjyj+697/ElNDCDyKg0betkeQ
	CV4qos/JKwCiHBjqwWlk0Qt4ipel4wo0vdbj1uCpcW/4SKsOCiAB8EmGleJ1
	GFK/aUcarOrSGpNLeWmajOXVfZLeDGF0oaiRT6WFeTju5QIaYS5zJCh9ARgN
	K+lgeZw6x3CP2SBMEt/iUqtJHcwRbI1D+y6Mu7h4/QboDH/MukvIy6qWVk34
	eq5y/dCExFsBZaWJyvUAGwpfYZnJYduwFpxtczV9IyY9rGOzXCyWkznOj14g
	w+bu3cUHEPPDAt+z7H8uFov/lWXuwv1jFx7oBe3/p3/842yym49e+EPJ1Xg5
	/Al+5vULz7oRqyGp+rQKLzUwB7pwKwJWXrMTrZcqpFCgTB907nq09gt+r5Or
	1x5qrI+6Ym/HqSyIsehdJVFrelZv07S9O12mkGvRuYptclUox3oRpkZnbTzk
	SO97CIHkjhrJeEZcrpbuFBxTW3Ps6lvzYESuD6VgRJEzqIqZX2P8n3z4qjW7
	jcIdIwwUaTWr80GN00iGPPBTdSvjoRcQdLjSHVxS+Re38/X0nQ+m6kVdJM9F
	n1S4HbvyYPbdMWzg0Qu4MhvXTwJKgTEL8YV7CY5BrtxL8Zf6cYDJ+EIKopQr
	+G02HHt6OPr0EJ6uR2hQDJFLNsUX7gXYhb9yL4ViLBaz4hiJjl7AlS8EuPyC
	eMv/QrjleJs7CRox6XeyDx7JRu1S3OUFTjJMipY6dQaxv+WSaffzAyHFopCj
	uiyVy36uAAwPJAhnoictHdHeIxN4hJEaT3bhKr1AuJ1HwgISe4uS6FKnvmRX
	kiZFIobfxMR1FPVIZTR3DwzTs4SclWzJhpFowyGVol7v6wF6tq1c30n96Ll7
	fc087QLgsPsBW5ZckO6W2bd7J8TmwYKb7CVtWyBtgnaN8GvOAdXmx3Lx3jEM
	laDKgMiKSxcJRsvDs6afvvdx/NhHkF1nH346epGsjn+cfeTR7OijsiuOXb2Q
	9Z0t/vTnEwQ9/IXRqSDo1wck/kNEn+jhKL3+my/D4ef3LcwkePF3L9X0KKaX
	amIUR0iV/XdevC+hGb2ycCoyfY+uvzoqvhipwOhNSgIERJLTnXyPlCEZ2A7I
	ceCdSHkjFwcIp+uOKkUf9QX6YBybkrjUIg1qHYSTDg5+RS90GFWFkRevtezs
	hFcS+VSBmwyHcSXWNgbWfXo4h2A7/7JlFCmjH+kX97ZwPj7BWjosxFypGJ+u
	hiZXkOanunfBNbyoxOx2bWMkpOBxbRyaRcSO58wvV0b9lO9Mb1Hy5Y17E+7J
	8+/enNKT3YBwFzzVpraHU1oeQQHH71x4KYCaH3DysOoCJBhFw3D4O+JBpYXH
	eejJTIfluvEvCbiRxiQKEUff+tb8bHNBzQZQGiDEpQQmERsMsFJf7yPAjSt9
	Q0LebFd4cbbDq/ogGFsawCQjhoSYsQb+47dVJwGiOdBHiJjLCVDZYmWbjPvn
	BqXg9/7Fpm43yN7gZChwzD6wGB/xtkS9Zu9BNTwfOYpaDf4YLb/R+wBtGYGS
	QoVtLRqgQFRpVQ6acp5TR29Qlr82gjrkjIiCrjrLFevDeWgP0eGzCobPEbgK
	JQd1SGjCjaJt+IWCAKme59eacuSEjmZCkDy+5l4uGyRGynn2ho9fn3eb26Yp
	Fhdb4o55dr4qBjImK7PNviX7fqjpp9Z0my1tgvPrDdBK9NPjkjbSJSDSOKn5
	LYKj2UW5a4gQ5xVxKPIoaJ+WPR/m2TPT7IfsogE871kz8HvZ39Hv8avd59n3
	peUr84PXsDPVfsA7NuvskW3Xzlwv+Xw13lODDAfHtyUTZytg3NybqwUf7l88
	dze7sPnAL8B5FFd56NyRkvTdp/5FiVIGDAEc9w4gn28XpIAwEOfK+cVLTG6E
	m25cDUQ9584v+f6Ww+w/EKMXQSO8tTcKNZeXfqvgp/niJQtu2KM3Mchrr90L
	bPzLM7XIY5HR3re8BcIe97XNIPvcAWaZYemwfQ5BYsIrvxnfy4wnxYtEc8Rt
	+Hg4UeGrkSglImqwRypTpbXz+b0F7ky3H5+T2rJtp/o7J3YeannXPR/tmQCt
	5VWTK6pOX7ftLyXvhJoHmDztYADw3HsBsse2hvyi1bvQI8Mnj5uLU2BpSVYw
	Wz0/f3V+wFLpm5eRI64budPkLujLb0hfUTP0dfb/ANTS2EkFhwAA
			</back>
	</rfc>		</rfc>
End of changes. 85 change blocks.
	715 lines changed or deleted		464 lines changed or added
This html diff was produced by rfcdiff 1.48.