Diff: rfc9817xml2.original.xml

	rfc9817xml2.original.xml	rfc9817.xml

	<?xml version="1.0" encoding="UTF-8"?>	<?xml version='1.0' encoding='UTF-8'?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.26 (Ruby 2.
	6.10) -->


	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">


	]>	]>


	<?rfc docmapping="yes"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -irtf-coinrg-use-cases-07" number="9817" category="info" consensus="true" update s="" obsoletes="" submissionType="IRTF" tocInclude="true" sortRefs="true" symRef s="true" tocDepth="2" version="3" xml:lang="en">


	<rfc ipr="trust200902" docName="draft-irtf-coinrg-use-cases-07" category="info" submissionType="IRTF" tocInclude="true" sortRefs="true" symRefs="true" tocDepth= "2">
	<front>	<front>
	<title abbrev="COIN Use Cases">Use Cases for In-Network Computing</title>	<title abbrev="COIN Use Cases">Use Cases for In-Network Computing</title>

		<seriesInfo name="RFC" value="9817"/>
	<author initials="I." surname="Kunze" fullname="Ike Kunze">	<author initials="I." surname="Kunze" fullname="Ike Kunze">
	<organization abbrev="RWTH Aachen">RWTH Aachen University</organization>	<organization abbrev="RWTH Aachen">RWTH Aachen University</organization>
	<address>	<address>
	<postal>	<postal>
	<street>Ahornstr. 55</street>	<street>Ahornstr. 55</street>
	<city>Aachen</city>	<city>Aachen</city>
	<code>D-52074</code>	<code>D-52074</code>
	<country>Germany</country>	<country>Germany</country>
	</postal>	</postal>
	<email>kunze@comsys.rwth-aachen.de</email>	<email>kunze@comsys.rwth-aachen.de</email>

	skipping to change at line 55 ¶	skipping to change at line 51 ¶
	<address>	<address>
	<postal>	<postal>
	<street>Riesstr. 25C</street>	<street>Riesstr. 25C</street>
	<city>Munich</city>	<city>Munich</city>
	<code>D-80992</code>	<code>D-80992</code>
	<country>Germany</country>	<country>Germany</country>
	</postal>	</postal>
	<email>Dirk.Trossen@Huawei.com</email>	<email>Dirk.Trossen@Huawei.com</email>
	</address>	</address>
	</author>	</author>

	<author initials="M. J." surname="Montpetit" fullname="Marie-Jose Montpetit" >	<author initials="M-J." surname="Montpetit" fullname="Marie-Jose Montpetit">
	<organization abbrev="McGill">McGill University</organization>	<organization abbrev="McGill">McGill University</organization>
	<address>	<address>
	<postal>	<postal>
	<street>680 Sherbrooke Street W.</street>	<street>680 Sherbrooke Street W.</street>
	<city>Montreal</city>	<city>Montreal</city>
	<code>H3A 3R1</code>	<code>H3A 3R1</code>
	<country>Canada</country>	<country>Canada</country>
	</postal>	</postal>
	<email>marie-jose.montpetit@mcgill.ca</email>	<email>marie-jose.montpetit@mcgill.ca</email>
	</address>	</address>

	skipping to change at line 86 ¶	skipping to change at line 82 ¶
	<email>xavier.defoy@interdigital.com</email>	<email>xavier.defoy@interdigital.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="D." surname="Griffin" fullname="David Griffin">	<author initials="D." surname="Griffin" fullname="David Griffin">
	<organization abbrev="UCL">University College London</organization>	<organization abbrev="UCL">University College London</organization>
	<address>	<address>
	<postal>	<postal>
	<street>Gower St</street>	<street>Gower St</street>
	<city>London</city>	<city>London</city>
	<code>WC1E 6BT</code>	<code>WC1E 6BT</code>

	<country>UK</country>	<country>United Kingdom</country>
	</postal>	</postal>
	<email>d.griffin@ucl.ac.uk</email>	<email>d.griffin@ucl.ac.uk</email>
	</address>	</address>
	</author>	</author>
	<author initials="M." surname="Rio" fullname="Miguel Rio">	<author initials="M." surname="Rio" fullname="Miguel Rio">
	<organization abbrev="UCL">University College London</organization>	<organization abbrev="UCL">University College London</organization>
	<address>	<address>
	<postal>	<postal>
	<street>Gower St</street>	<street>Gower St</street>
	<city>London</city>	<city>London</city>
	<code>WC1E 6BT</code>	<code>WC1E 6BT</code>

	<country>UK</country>	<country>United Kingdom</country>
	</postal>	</postal>
	<email>miguel.rio@ucl.ac.uk</email>	<email>miguel.rio@ucl.ac.uk</email>
	</address>	</address>
	</author>	</author>

		<date year="2025" month="July"/>


	<date />	<workgroup>Computing in the Network (COIN)</workgroup>

	<area>General</area>
	<workgroup>COINRG</workgroup>


	<abstract>	<!-- [rfced] Please insert any keywords (beyond those that appear in
		the title) for use on https://www.rfc-editor.org/search. -->


	<t>Computing in the Network (COIN) comes with the prospect of deploying processi	<keyword>example</keyword>
	ng functionality on networking devices, such as switches and network interface c
	ards.
	While such functionality can be beneficial, it has to be carefully placed into t
	he context of the general Internet communication and it needs to be clearly iden
	tified where and how those benefits apply.</t>


	<t>This document presents some use cases to demonstrate how a number of salient	<!-- [rfced] Please ensure that the guidelines listed in Section 2.1 of
	COIN-related applications can benefit from COIN.	RFC 5743 have been adhered to in this document. See
	Furthermore, to guide research on COIN, it identifies essential research questio	https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1.
	ns and outlines desirable capabilities that COIN systems addressing the use case	-->
	s may need to support.
	Finally, the document provides a preliminary categorization of the described res
	earch questions to source future work in this domain.
	It is a product of the Computing in the Network Research Group (COINRG).
	It is not an IETF product and it is not a standard.</t>


		<abstract>
		<t>Computing in the Network (COIN) comes with the prospect of deploying
		processing functionality on networking devices such as switches and
		network interface cards. While such functionality can be beneficial, it
		has to be carefully placed into the context of the general Internet
		communication, and it needs to be clearly identified where and how those
		benefits apply.</t>
		<t>This document presents some use cases to demonstrate how a number of
		salient COIN-related applications can benefit from COIN. Furthermore,
		to guide research on COIN, it identifies essential research questions
		and outlines desirable capabilities that COIN systems addressing these use
		cases may need to support. Finally, the document provides a preliminary
		categorization of the described research questions to source future work
		in this domain. This document is a product of the Computing in the Networ
		k
		Research Group (COINRG). It is not an IETF product and it is not a
		standard.</t>
	</abstract>	</abstract>


	</front>	</front>


	<middle>	<middle>

		<section anchor="intro">
		<name>Introduction</name>
		<t>The Internet was designed as a best-effort packet network, forwarding
		packets from source to destination with limited guarantees regarding
		their timely and successful reception. Data manipulation, computation,
		and more complex protocol functionalities are generally provided by the
		end hosts, while network nodes are traditionally kept simple and only
		offer a "store and forward" packet facility. This simplicity of purpose
		of the network has shown to be suitable for a wide variety of
		applications and has facilitated the rapid growth of the Internet. Howeve
		r,
		introducing middleboxes with specialized functionality for enhancing
		performance has often led to problems due to their inflexibility.</t>
		<t>However, with the rise of new services, some of which are described
		in this document, there is a growing number of application domains that
		require more than best-effort forwarding, including strict performance
		guarantees or closed-loop integration to manage data flows. In this
		context, allowing for a tighter integration of computing and networking
		resources for enabling a more flexible distribution of computation tasks
		across the network (e.g., beyond "just" endpoints and without requiring
		specialized middleboxes) may help to achieve the desired guarantees and
		behaviors, increase overall performance, and improve resilience to
		failures.</t>
		<t>The vision of "in-network computing" and the provisioning of such
		capabilities that capitalize on joint computation and communication
		resource usage throughout the network is part of the move from a
		telephone network analogy of the Internet into a more distributed
		computer board architecture. We refer to those capabilities as "COIN
		capabilities" in the remainder of the document.</t>
		<t>We believe that this vision of in-network computing can be best
		outlined along four dimensions of use cases, namely those that:</t>
		<ol type="i">
		<li>provide new user experiences through the utilization of COIN
		capabilities (referred to as "COIN experiences"),</li>
		<li>enable new COIN systems (e.g., through new interactions
		between communication and compute providers),</li>
		<li>improve on already existing COIN capabilities, and</li>
		<li>enable new COIN capabilities.</li>
		</ol>
		<t>Sections <xref target="newExperiences" format="counter"/> through <xref
		target="newCapabilities" format="counter"/> capture those categories of
		use cases and provide the main structure of this document. The goal is
		to present how computing resources inside the network impact existing
		services and applications or allow for innovation in emerging
		application domains.</t>
		<t>By delving into some individual examples within each of the above
		categories, we outline opportunities and propose possible research
		questions for consideration by the wider community when pushing forward
		in-network computing architectures. Furthermore, identifying
		desirable capabilities for an evolving solution space of COIN systems is
		another objective of the use case descriptions. To achieve this, the
		following taxonomy is proposed to describe each of the use cases:</t>


	<section anchor="intro"><name>Introduction</name>	<dl spacing="normal" newline="false">
	<t>The Internet was designed as a best-effort packet network, forwarding packets	<dt>Description:</dt><dd>A high-level presentation of the purpose of the
	from source to destination with limited guarantees regarding their timely and s	use case and a short explanation of the use case behavior.</dd>
	uccessful reception.	<dt>Characterization:</dt><dd>An explanation of the services that are
	Data manipulation, computation, and more complex protocol functionality is gener	being utilized and realized as well as the semantics of interactions in
	ally provided by the end-hosts while network nodes are traditionally kept simple	the use case.</dd>
	and only offer a "store and forward" packet facility.	<dt>Existing Solutions:</dt><dd>A description of current methods that may
	This simplicity of purpose of the network has shown to be suitable for a wide va	realize the use case (if they exist), though not claiming to exhaustively
	riety of applications and has facilitated the rapid growth of the Internet while	review the landscape of solutions.</dd>
	introducing middleboxes with specialized functionality for enhancing performanc	<dt>Opportunities:</dt><dd>An outline of how COIN capabilities may
	e has often led to problems due to their inflexibility.</t>	support or improve on the use case in terms of performance and other
		metrics.</dd>
	<t>However, with the rise of new services, some of which are described in this d	<dt>Research questions:</dt><dd>Essential questions that are suitable
	ocument, there is a growing number of application domains that require more than	for guiding research to achieve the identified opportunities. The
	best-effort forwarding including strict performance guarantees or closed-loop i	research questions also capture immediate capabilities for any COIN
	ntegration to manage data flows.	solution addressing the particular use case whose development may
	In this context, allowing for a tighter integration of computing and networking	immediately follow when working toward answers to the research
	resources for enabling a more flexible distribution of computation tasks across	questions.</dd>
	the network, e.g., beyond 'just' endpoints and without requiring specialized mid	<dt>Additional desirable capabilities:</dt><dd>A description of
	dleboxes, may help to achieve the desired guarantees and behaviors, increase ove	additional capabilities that might not require research but may be
	rall performance, and improve resilience to failures.</t>	desirable for any COIN solution addressing the particular use case; we
		limit these capabilities to those directly affecting COIN, recognizing
	<t>The vision of 'in-network computing' and the provisioning of such capabilitie	that any use case will realistically require many additional
	s that capitalize on joint computation and communication resource usage througho	capabilities for its realization. We omit this dedicated section if
	ut the network is part of the move from a telephone network analogy of the Inter	relevant capabilities are already sufficiently covered by the
	net into a more distributed computer board architecture.	corresponding research questions.</dd>
	We refer to those capabilities as 'COIN capabilities' in the remainder of the do	</dl>
	cument.</t>

	<t>We believe that this vision of 'in-network computing' can be best outlined al
	ong four dimensions of use cases, namely those that (i) provide new user experie
	nces through the utilization of COIN capabilities (referred to as 'COIN experien
	ces'), (ii) enable new COIN systems, e.g., through new interactions between comm
	unication and compute providers, (iii) improve on already existing COIN capabili
	ties, and (iv) enable new COIN capabilities.
	Sections 3 through 6 capture those categories of use cases and provide the main
	structure of this document.
	The goal is to present how computing resources inside the network impact existin
	g services and applications or allow for innovation in emerging application doma
	ins.</t>

	<t>By delving into some individual examples within each of the above categories,
	we outline opportunities and propose possible research questions for considerat
	ion by the wider community when pushing forward 'in-network computing' architect
	ures.
	Furthermore, identifying desirable capabilities for an evolving solution space o
	f COIN systems is another objective of the use case descriptions.
	To achieve this, the following taxonomy is proposed to describe each of the use
	cases:</t>

	<t><list style="numbers">
	<t>Description: High-level presentation of the purpose of the use case and a s
	hort explanation of the use case behavior.</t>
	<t>Characterization: Explanation of the services that are being utilized and r
	ealized as well as the semantics of interactions in the use case.</t>
	<t>Existing solutions: Description of current methods that may realize the use
	case (if they exist), not claiming to exhaustively review the landscape of solu
	tions.</t>
	<t>Opportunities: An outline of how COIN capabilities may support or improve o
	n the use case in terms of performance and other metrics.</t>
	<t>Research questions: Essential questions that are suitable for guiding resea
	rch to achieve the identified opportunities. The research questions also capture
	immediate capabilities for any COIN solution addressing the particular use case
	whose development may immediately follow when working toward answers to the res
	earch questions.</t>
	<t>Additional desirable capabilities: Description of additional capabilities t
	hat might not require research but may be desirable for any COIN solution addres
	sing the particular use case; we limit these capabilities to those directly affe
	cting COIN, recognizing that any use case will realistically require many additi
	onal capabilities for its realization. We omit this dedicated section if relevan
	t capabilities are already sufficiently covered by the corresponding research qu
	estions.</t>
	</list></t>


	<t>This document discusses these six aspects along a number of individual use ca	<t>This document discusses these six aspects along a number of
	ses to demonstrate the diversity of COIN applications.	individual use cases to demonstrate the diversity of COIN applications.
	It is intended as a basis for further analyses and discussions within the wider	It is intended as a basis for further analyses and discussions within
	research community.	the wider research community. This document represents the consensus of
	This document represents the consensus of COINRG.</t>	COINRG.</t>
		</section>


	</section>	<section anchor="terms">
	<section anchor="terms"><name>Terminology</name>	<name>Terminology</name>
		<t>This document uses the terminology defined below.</t>


	<t>This document uses the terminology defined below.</t>	<dl spacing="normal" newline="false">


	<t>Programmable Network Devices (PNDs): network devices, such as network interfa	<dt>Programmable Network Devices (PNDs):</dt><dd>network devices, such
	ce cards and switches, which are programmable, e.g., using P4 <xref target="P4"/	as network interface cards and switches, which are programmable (e.g.,
	> or other languages.</t>	using P4 <xref target="P4"/> or other languages).</dd>


	<t>(COIN) Execution Environment: a class of target environments for function exe	<dt>(COIN) execution environment:</dt><dd>a class of target
	cution, for example, a JVM-based execution environment that can run functions re	environments for function execution, for example, an
	presented in JVM byte code</t>	execution environment based on the Java Virtual Machine (JVM) that can ru
		n functions represented in JVM byte
		code.</dd>


	<t>COIN System: the PNDs (and end systems) and their execution environments, tog	<dt>COIN system:</dt><dd>the PNDs (and end systems) and their
	ether with the communication resources interconnecting them, operated by a singl	execution environments, together with the communication resources
	e provider or through interactions between multiple providers that jointly offer	interconnecting them, operated by a single provider or through
	COIN capabilities</t>	interactions between multiple providers that jointly offer COIN
		capabilities.</dd>


	<t>COIN Capability: a feature enabled through the joint processing of computatio	<dt>COIN capability:</dt><dd>a feature enabled through the joint
	n and communication resources in the network</t>	processing of computation and communication resources in the
		network.</dd>


	<t>(COIN) Program: a monolithic functionality that is provided according to the	<dt>(COIN) program:</dt><dd>a monolithic functionality that is
	specification for said program and which may be requested by a user. A composit	provided according to the specification for said program and which may
	e service can be built by orchestrating a combination of monolithic COIN program	be requested by a user. A composite service can be built by
	s.</t>	orchestrating a combination of monolithic COIN programs.</dd>


	<t>(COIN) Program Instance: one running instance of a program</t>	<dt>(COIN) program instance:</dt><dd>one running instance of a program.</ dd>


	<t>COIN Experience: a new user experience brought about through the utilization	<dt>COIN experience:</dt><dd>a new user experience brought about
	of COIN capabilities</t>	through the utilization of COIN capabilities.</dd>


	</section>	</dl>
	<section anchor="newExperiences"><name>Providing New COIN Experiences</name>	</section>
		<section anchor="newExperiences">
		<name>Providing New COIN Experiences</name>
		<section anchor="mobileAppOffload">
		<name>Mobile Application Offloading</name>
		<section anchor="description">
		<name>Description</name>
		<t>This scenario can be exemplified in an immersive gaming
		application, where a single user plays a game using a Virtual
		Reality (VR) headset. The headset hosts several (COIN) programs.
		For instance, the display (COIN) program renders frames to the
		user, while other programs are realized for VR content processing
		and to incorporate input data received from sensors (e.g., in bodily
		worn devices including the VR headset).</t>


	<section anchor="mobileAppOffload"><name>Mobile Application Offloading</name>	<!-- [rfced] May we make this into two sentences as follows for ease of
		the reader? Also, would you like to change the adjective "compute intensive"
		to "CPU-intensive", which is used later in this document?


	<section anchor="description"><name>Description</name>	Original:
		Once this application is partitioned into its constituent (COIN)
		programs and deployed throughout a COIN system, utilizing a COIN
		execution environment, only the "display" (COIN) program may be left
		in the headset, while the compute intensive real-time VR content
		processing (COIN) program can be offloaded to a nearby resource rich
		home PC or a programmable network device (PND) in the operator's
		access network, for a better execution (faster and possibly higher
		resolution generation).


	<t>This scenario can be exemplified in an immersive gaming application, where a	Perhaps:
	single user plays a game using a Virtual Reality (VR) headset. <br />	Once this application is partitioned into its constituent (COIN)
	The headset hosts several (COIN) programs.	programs and deployed throughout a COIN system utilizing a COIN
	For instance, the "display" (COIN) program renders frames to the user, while oth	execution environment, only the display (COIN) program may be left in
	er programs are realized for VR content processing and to incorporate input data	the headset. Meanwhile, the CPU-intensive real-time VR content
	received from sensors, e.g., in bodily worn devices including the VR headset.</	processing (COIN) program can be offloaded to a nearby resource rich
	t>	home PC or a Programmable Network Device (PND) in the operator's
		access network for a better execution (i.e., faster and possibly higher
		resolution generation).
		-->


	<t>Once this application is partitioned into its constituent (COIN) programs and	<t>Once this application is partitioned into its constituent (COIN)
	deployed throughout a COIN system, utilizing a COIN execution environment, only	programs and deployed throughout a COIN system, utilizing a COIN
	the "display" (COIN) program may be left in the headset, while the compute inte	execution environment, only the display (COIN) program may be left
	nsive real-time VR content processing (COIN) program can be offloaded to a nearb	in the headset, while the compute intensive real-time VR content
	y resource rich home PC or a programmable network device (PND) in the operator's	processing (COIN) program can be offloaded to a nearby resource rich
	access network, for a better execution (faster and possibly higher resolution g	home PC or a Programmable Network Device (PND) in the operator's
	eneration).</t>	access network, for a better execution (faster and possibly higher
		resolution generation).</t>
		</section>
		<section anchor="characterization">
		<name>Characterization</name>
		<t>Partitioning a mobile application into several constituent (COIN)
		programs allows for denoting the application as a collection of
		(COIN) programs for a flexible composition and a distributed
		execution. In our example above, most capabilities of a mobile
		application can be categorized into any of three groups: receiving,
		processing, and displaying.</t>
		<t>Any device may realize one or more of the (COIN) programs of a
		mobile application and expose them to the (COIN) system and its
		constituent (COIN) execution environments. When the (COIN) program
		sequence is executed on a single device, the outcome is what you
		traditionally see with applications running on mobile devices.</t>


	</section>	<!-- [rfced] How may we update the following text to clarify the
	<section anchor="characterization"><name>Characterization</name>	relationship between the "result" and the phrases that follow?


	<t>Partitioning a mobile application into several constituent (COIN) programs al	Original:
	lows for denoting the application as a collection of (COIN) programs for a flexi	The result is the equivalent to 'mobile function offloading', for possible
	ble composition and a distributed execution.	reduction of power consumption (e.g., offloading CPU intensive process
	In our example above, most capabilities of a mobile application can be categoriz	functions to a remote server) or for improved end user experience (e.g.,
	ed into any of three, "receiving", "processing", and "displaying" groups.</t>	moving display functions to a nearby smart TV) by selecting more suitably
		placed (COIN) program instances in the overall (COIN) system.


	<t>Any device may realize one or more of the (COIN) programs of a mobile applica	Option A:
	tion and expose them to the (COIN) system and its constituent (COIN) execution e	The result is the equivalent to mobile function offloading, in that it
	nvironments.	offers the possible reduction of power consumption (e.g., offloading CPU-
	When the (COIN) program sequence is executed on a single device, the outcome is	intensive process functions to a remote server) or offers an improved
	what you traditionally see with applications running on mobile devices.</t>	end-user experience (e.g., moving display functions to a nearby smart TV)
		by selecting more suitably placed (COIN) program instances in the overall
		(COIN) system.


	<t>However, the execution of a (COIN) program may be moved to other (e.g., more	Option B (if both reducing power consumption and improving the end-user
	suitable) devices, including PNDs, which have exposed the corresponding (COIN) p	experience are due to selecting more suitably placed program instances):
	rogram as individual (COIN) program instances to the (COIN) system by means of a
	'service identifier'.
	The result is the equivalent to 'mobile function offloading', for possible reduc
	tion of power consumption (e.g., offloading CPU intensive process functions to a
	remote server) or for improved end user experience (e.g., moving display functi
	ons to a nearby smart TV) by selecting more suitably placed (COIN) program insta
	nces in the overall (COIN) system.</t>


	<t>We can already see a trend toward supporting such functionality with, e.g., g	The result is the equivalent to mobile function offloading because, by
	aming platforms rendering content externally, relying on dedicated cloud hardwar	selecting more suitably placed (COIN) program instances in the overall
	e. We envision, however, that such functionality is becoming more pervasive thro	(COIN) system, it offers a potential reduction of power consumption (e.g.,
	ugh specific facilities, such as entertainment parks or even hotels, to deploy n	offloading CPU-intensive process functions to a remote server) or an
	eeded edge computing capability to enable localized gaming as well as non-gaming	improved end-user experience (e.g., moving display functions to a nearby
	scenarios.</t>	smart TV).
		-->
		<t>However, the execution of a (COIN) program may be moved to other
		(e.g., more suitable) devices, including PNDs, which have exposed
		the corresponding (COIN) program as individual (COIN) program
		instances to the (COIN) system by means of a service identifier.
		The result is the equivalent to mobile function offloading, for
		possible reduction of power consumption (e.g., offloading CPU-intensiv
		e process functions to a remote server) or for improved
		end-user experience (e.g., moving display functions to a nearby
		smart TV) by selecting more suitably placed (COIN) program instances
		in the overall (COIN) system.</t>
		<t>We can already see a trend toward supporting such functionality
		with relyiccng on dedicated cloud hardware (e.g., gaming platforms
		rendering content externally). We envision, however, that such
		functionality is becoming more pervasive through specific
		facilities, such as entertainment parks or even hotels, in order to
		deploy needed edge computing capabilities to enable localized gaming
		as well as non-gaming scenarios.</t>


	<t><xref target="figureAppOffload"/> shows one realization of the above scenario	<t><xref target="figureAppOffload"/> shows one realization
	, where a 'DPR app' is running on a mobile device (containing the partitioned Di	of the above scenario, where a "DPR app" is running on a mobile
	splay(D), Process(P) and Receive(R) COIN programs) over a programmable switching	device (containing the partitioned COIN programs Display (D), Process
	, e.g., here an SDN, network.	(P) and
	The packaged applications are made available through a localized 'playstore serv	Receive (R)) over a programmable switching network, e.g., a Software-D
	er'.	efined Network (SDN) here. The packaged applications are made available
	The mobile application installation is realized as a 'service deployment' proces	through a localized "playstore server". The mobile application
	s, combining the local app installation with a distributed deployment (and orche	installation is realized as a service deployment process, combining
	stration) of one or more (COIN) programs on most suitable end systems or PNDs ('	the local app installation with a distributed deployment (and
	processing server').</t>	orchestration) of one or more (COIN) programs on most suitable end
		systems or PNDs (here, a "processing server").</t>


	<figure title="Application Function Offloading Example." anchor="figureAppOffloa	<figure anchor="figureAppOffload">
	d"><artwork><![CDATA[	<name>Application Function Offloading Example</name>
		<artwork><![CDATA[
	+----------+ Processing Server	+----------+ Processing Server
	Mobile \| +------+ \|	Mobile \| +------+ \|
	+---------+ \| \| P \| \|	+---------+ \| \| P \| \|
	\| App \| \| +------+ \|	\| App \| \| +------+ \|
	\| +-----+ \| \| +------+ \|	\| +-----+ \| \| +------+ \|
	\| \|D\|P\|R\| \| \| \| SR \| \|	\| \|D\|P\|R\| \| \| \| SR \| \|
	\| +-----+ \| \| +------+ \| Internet	\| +-----+ \| \| +------+ \| Internet
	\| +-----+ \| +----------+ /	\| +-----+ \| +----------+ /
	\| \| SR \| \| \| /	\| \| SR \| \| \| /
	\| +-----+ \| +----------+ +------+	\| +-----+ \| +----------+ +------+

	skipping to change at line 235 ¶	skipping to change at line 402 ¶
	\|\|Display\|\| /\|SDN Switch\|	\|\|Display\|\| /\|SDN Switch\|
	\|+-------+\| +-------+ / +----------+	\|+-------+\| +-------+ / +----------+
	\|+-------+\| /\|WIFI AP\|/	\|+-------+\| /\|WIFI AP\|/
	\|\| D \|\| / +-------+ +--+	\|\| D \|\| / +-------+ +--+
	\|+-------+\|/ \|SR\|	\|+-------+\|/ \|SR\|
	\|+-------+\| /+--+	\|+-------+\| /+--+
	\|\| SR \|\| +---------+	\|\| SR \|\| +---------+
	\|+-------+\| \|Playstore\|	\|+-------+\| \|Playstore\|
	+---------+ \| Server \|	+---------+ \| Server \|
	TV +---------+	TV +---------+

		]]></artwork>
		</figure>


	]]></artwork></figure>	<t>Such localized deployment could, for instance, be provided by a
		visiting site, such as a hotel or a theme park. Once the
		processing (COIN) program is terminated on the mobile device, the
		"service routing (SR)" elements in the network route (service)
		requests instead to the (previously deployed) processing (COIN)
		program running on the processing server over an existing SDN
		network. Here, capabilities and other constraints for selecting the
		appropriate (COIN) program, in case of having deployed more than
		one, may be provided both in the advertisement of the (COIN) program
		and the service request itself.</t>
		<t>As an extension to the above scenarios, we can also envision that
		content from one processing (COIN) program may be distributed to
		more than one display (COIN) program (e.g., for multi- and many-viewin
		g
		scenarios). Here, an offloaded processing program may collate
		input from several users in the (virtual) environment to generate a
		possibly three-dimensional render that is then distributed via a
		service-level multicast capability towards more than one display
		(COIN) program.</t>
		</section>


	<t>Such localized deployment could, for instance, be provided by a visiting site	<section anchor="existing-solutions">
	, such as a hotel or a theme park.	<name>Existing Solutions</name>
	Once the 'processing' (COIN) program is terminated on the mobile device, the 'se
	rvice routing' (SR) elements in the network route (service) requests instead to
	the (previously deployed) 'processing' (COIN) program running on the processing
	server over an existing SDN network.
	Here, capabilities and other constraints for selecting the appropriate (COIN) pr
	ogram, in case of having deployed more than one, may be provided both in the adv
	ertisement of the (COIN) program and the service request itself.</t>


	<t>As an extension to the above scenarios, we can also envision that content fro	<!-- [rfced] We note that the reference [ETSI] uses "Multi-access Edge
	m one processing (COIN) program may be distributed to more than one display (COI	Computing (MEC)" rather than "Mobile Edge Computing (MEC)" as seen in the
	N) program, e.g., for multi/many-viewing scenarios.	text below. May we update this sentence accordingly?
	Here, an offloaded "processing" program may collate input from several users in
	the (virtual) environment to generate a possibly three-dimensional render that i
	s then distributed via a service-level multicast capability towards more than on
	e "display" (COIN) program.</t>


	</section>	Original:
	<section anchor="existing-solutions"><name>Existing Solutions</name>	The ETSI Mobile Edge Computing (MEC) [ETSI] suite of technologies
		provides solutions...


	<t>The ETSI Mobile Edge Computing (MEC) <xref target="ETSI"/> suite of technolog	Perhaps:
	ies provides solutions for mobile function offloading by allowing mobile applica	The ETSI Multi-access Edge Computing (MEC) [ETSI] suite of technologies
	tions to select resources in edge devices to execute functions instead of the mo	provides solutions...
	bile device directly.	-->
	For this, ETSI MEC utilizes a set of interfaces for the selection of suitable ed	<t>The ETSI Mobile Edge Computing (MEC) <xref target="ETSI"/> suite
	ge resources, connecting to so-called MEC application servers, while also allowi	of technologies provides solutions for mobile function offloading by
	ng for sending data for function execution to the application server.</t>	allowing mobile applications to select resources in edge devices to
		execute functions instead of the mobile device directly. For this,
		ETSI MEC utilizes a set of interfaces for the selection of suitable
		edge resources, connecting to so-called MEC application servers,
		while also allowing for sending data for function execution to the
		application server.</t>


	<t>However, the technologies do not utilize micro-services <xref target="Microse	<!-- [rfced] Please clarify this sentence, especially "rather than".
	rvices"/> but mainly rely on virtualization approaches such as containers or vir
	tual machines, thus requiring a heavier processing and memory footprint in a COI
	N execution environment and the executing intermediaries.
	Also, the ETSI work does not allow for the dynamic selection and redirection of
	(COIN) program calls to varying edge resources rather than a single MEC applicat
	ion server.</t>


	<t>Also, the selection of the edge resource (the app server) is relatively stati	Original:
	c, relying on DNS-based endpoint selection, which does not cater to the requirem	Also, the ETSI work does not allow for the
	ents of the example provided above, where the latency for redirecting to another	dynamic selection and redirection of (COIN) program calls to varying
	device lies within few milliseconds for aligning with the framerate of the disp	edge resources rather than a single MEC application server.
	lay micro-service.</t>


	<t>Lastly, MEC application servers are usually considered resources provided by	Option A:
	the network operator through its MEC infrastructure, while our use case here als	Also, the ETSI work does not allow for the
	o foresees the placement and execution of micro-services in end user devices.</t	dynamic selection and redirection of (COIN) program calls to varying
	>	edge resources; it does allow for them to a single MEC application server.


	<t>There also exists a plethora of mobile offloading platforms provided through	Option B (stating the reverse):
	proprietary platforms, all of which follow a similar approach as ETSI MEC in tha	Also, the ETSI work allows for the dynamic selection and
	t a selected edge application server is being utilized to send functional descri	redirection of (COIN) program calls to only a single MEC application
	ptions and data for execution.</t>	server, not to varying edge resources.
		-->


	<t>The draft at <xref target="APPCENTRES"/> outlines a number of enabling techno	<t>However, the technologies do not utilize microservices <xref
	logies for the use case, some of which have been realized in an Android-based re	target="Microservices"/>; they mainly rely on virtualization
	alization of the micro-services as a single application, which is capable to dyn	approaches such as containers or virtual machines, thus requiring a
	amically redirect traffic to other micro-service instances in the network.	heavier processing and memory footprint in a COIN execution
	This capability, together with the underlying path-based forwarding capability (	environment and the executing intermediaries. Also, the ETSI work
	using SDN) was demonstrated publicly, e.g., at the Mobile World Congress 2018 an	does not allow for the dynamic selection and redirection of (COIN)
	d 2019.</t>	program calls to varying edge resources rather than a single MEC
		application server.</t>
		<t>Also, the selection of the edge resource (the app server) is
		relatively static, relying on DNS-based endpoint selection, which
		does not cater to the requirements of the example provided above,
		where the latency for redirecting to another device lies within a few
		milliseconds for aligning with the frame rate of the display
		microservice.</t>
		<t>Lastly, MEC application servers are usually considered resources
		provided by the network operator through its MEC infrastructure,
		while our use case here also foresees the placement and execution of
		microservices in end-user devices.</t>
		<t>There also exists a plethora of mobile offloading platforms
		provided through proprietary platforms, all of which follow a
		similar approach as ETSI MEC in that a selected edge application
		server is being utilized to send functional descriptions and data
		for execution.</t>
		<t><xref target="I-D.sarathchandra-coin-appcentres"/> outlines a
		number of enabling technologies for the use case, some of which have
		been realized in an Android-based realization of the microservices
		as a single application, which is capable of dynamically redirecting
		traffic to other microservice instances in the network. This
		capability, together with the underlying path-based forwarding
		capability (using SDN), was demonstrated publicly (e.g., at the
		Mobile World Congress 2018 and 2019).</t>
		</section>


	</section>	<section anchor="opportunities">
	<section anchor="opportunities"><name>Opportunities</name>	<name>Opportunities</name>
		<ul spacing="normal">
		<li>
		<t>The packaging of (COIN) programs into existing mobile
		application packaging may enable the migration from current
		(mobile) device-centric execution of those mobile applications
		toward a possible distributed execution of the constituent
		(COIN) programs that are part of the overall mobile
		application.</t>
		</li>
		<li>
		<t>The orchestration for deploying (COIN) program instances in
		specific end systems and PNDs alike may open up the possibility
		for localized infrastructure owners, such as hotels or venue
		owners, to offer their compute capabilities to their visitors
		for improved or even site-specific experiences.</t>
		</li>
		<li>
		<t>The execution of (current mobile) app-level (COIN) programs
		may speed up the execution of said (COIN) program by relocating
		the execution to more suitable devices, including PNDs that may
		reside better located in relation to other (COIN) programs and
		thus improve performance, such as latency.</t>
		</li>


	<t><list style="symbols">	<!-- [rfced] Seems a closing parenthesis was missing on "(service routing
	<t>The packaging of (COIN) programs into existing mobile application packaging	in [APPCENTRES]...". We added it; please review.
	may enable the migration from current (mobile) device-centric execution of thos
	e mobile applications toward a possible distributed execution of the constituent
	(COIN) programs that are part of the overall mobile application.</t>
	<t>The orchestration for deploying (COIN) program instances in specific end sy
	stems and PNDs alike may open up the possibility for localized infrastructure ow
	ners, such as hotels or venue owners, to offer their compute capabilities to the
	ir visitors for improved or even site-specific experiences.</t>
	<t>The execution of (current mobile) app-level (COIN) programs may speed up th
	e execution of said (COIN) program by relocating the execution to more suitable
	devices, including PNDs that may reside better located in relation to other (COI
	N) programs and thus improve performance, such as latency.</t>
	<t>The support for service-level routing of requests (service routing in <xref
	target="APPCENTRES"/> may support higher flexibility when switching from one (C
	OIN) program instance to another, e.g., due to changing constraints for selectin
	g the new (COIN) program instance.
	Here, PNDs may support service routing solutions by acting as routing overlay
	nodes to implement the necessary additional lookup functionality and also possi
	bly support the handling of affinity relations, i.e., the forwarding of one pack
	et to the destination of a previous one due to a higher level service relation,
	as discussed and described in <xref target="SarNet2021"/>.</t>
	<t>The ability to identify service-level COIN elements will allow for routing
	service requests to those COIN elements, including PNDs, therefore possibly allo
	wing for new COIN functionality to be included in the mobile application.</t>
	<t>The support for constraint-based selection of a specific (COIN) program ins
	tance over others (constraint-based routing in <xref target="APPCENTRES"/>, show
	cased for PNDs in <xref target="SarNet2021"/>) may allow for a more flexible and
	app-specific selection of (COIN) program instances, thereby allowing for better
	meeting the app-specific and end user requirements.</t>
	</list></t>


	</section>	Original:
	<section anchor="mobileOffloadRQ"><name>Research Questions</name>	* The support for service-level routing of requests (service routing
		in [APPCENTRES] may support higher flexibility when switching from
		one (COIN) program instance to another, e.g., due to changing
		constraints for selecting the new (COIN) program instance. Here,
		PNDs may support service routing solutions by acting as routing
		overlay nodes to implement the necessary additional lookup
		functionality and also possibly support the handling of affinity
		relations, i.e., the forwarding of one packet to the destination
		of a previous one due to a higher level service relation, as
		discussed and described in [SarNet2021].


	<t><list style="symbols">	Current:
	<t>RQ 3.1.1: How to combine service-level orchestration frameworks, such as TO	* The support for service-level routing of requests (such as service
	SCA orchestration templates<xref target="TOSCA"/>, with app-level, e.g., mobile	routing in [APPCENTRES]) may support higher flexibility when switching
	application, packaging methods, ultimately providing means for packaging micro-s	from one (COIN) program instance to another (e.g., due to changing
	ervices for deployments in distributed networked computing environments?</t>	constraints for selecting the new (COIN) program instance). Here, PNDs
	<t>RQ 3.1.2: How to reduce latencies involved in (COIN) program interactions w	may support service routing solutions by acting as routing overlay nodes
	here (COIN) program instance locations may change quickly? Can service-level req	to implement the necessary additional lookup functionality and also
	uests be routed directly through in-band signalling methods instead of relying o	possibly support the handling of affinity relations (i.e., the
	n out-of-band discovery, such as through the DNS?</t>	forwarding of one packet to the destination of a previous one due to a
	<t>RQ 3.1.3: How to signal constraints used for routing requests towards (COIN	higher level service relation as discussed and described in
	) program instances in a scalable manner, i.e., for dynamically choosing the bes	[SarNet2021]).
	t possible service sequence of one or more (COIN) programs for a given applicati	-->
	on experience through chaining (COIN) program executions?</t>
	<t>RQ 3.1.4: How to identify (COIN) programs and program instances so as to al
	low routing (service) requests to specific instances of a given service?</t>
	<t>RQ 3.1.5: How to identify a specific choice of (COIN) program instances ove
	r others, thus allowing to pin the execution of a service of a specific (COIN) p
	rogram to a specific resource, i.e., (COIN) program instance in the distributed
	environment?</t>
	<t>RQ 3.1.6: How to provide affinity of service requests towards (COIN) progra
	m instances, i.e., longer-term transactions with ephemeral state established at
	a specific (COIN) program instance?</t>
	<t>RQ 3.1.7: How to provide constraint-based routing decisions that can be rea
	lized at packet forwarding speed, e.g., using techniques explored in <xref targe
	t="SarNet2021"/> at the forwarding plane or using approaches like <xref target="
	Multi2020"/> for extended routing protocols?</t>
	<t>RQ 3.1.8: What COIN capabilities may support the execution of (COIN) progra
	ms and their instances?</t>
	<t>RQ 3.1.9: How to ensure real-time synchronization and consistency of distri
	buted application states among (COIN) program instances, in particular when freq
	uently changing the choice for a particular (COIN) program in terms of executing
	service instance?</t>
	</list></t>


	</section>	<li>
	</section>	<t>The support for service-level routing of requests (such as serv
	<section anchor="XR"><name>Extended Reality and Immersive Media</name>	ice
		routing in <xref target="I-D.sarathchandra-coin-appcentres"/>)
		may support higher flexibility when switching from one (COIN)
		program instance to another (e.g., due to changing constraints
		for selecting the new (COIN) program instance). Here, PNDs may
		support service routing solutions by acting as routing overlay
		nodes to implement the necessary additional lookup functionality
		and also possibly support the handling of affinity relations
		(i.e., the forwarding of one packet to the destination of a
		previous one due to a higher level service relation as
		discussed and described in <xref target="SarNet2021"/>).</t>
		</li>
		<li>
		<t>The ability to identify service-level COIN elements will
		allow for routing service requests to those COIN elements,
		including PNDs, therefore possibly allowing for a new COIN
		functionality to be included in the mobile application.</t>
		</li>
		<li>
		<t>The support for constraint-based selection of a specific
		(COIN) program instance over others (e.g., constraint-based routin
		g in
		<xref target="I-D.sarathchandra-coin-appcentres"/>, showcased
		for PNDs in <xref target="SarNet2021"/>) may allow for a more
		flexible and app-specific selection of (COIN) program instances,
		thereby allowing for better meeting the app-specific and end-user
		requirements.</t>
		</li>
		</ul>
		</section>
		<section anchor="mobileOffloadRQ">
		<name>Research Questions</name>


	<section anchor="description-1"><name>Description</name>	<ul spacing="normal">
		<li>RQ 3.1.1: How to combine service-level orchestration
		frameworks, such as TOSCA orchestration templates <xref
		target="TOSCA"/>, with app-level (e.g., mobile application)
		packaging methods, ultimately providing the means for packaging
		microservices for deployments in distributed networked computing
		environments?</li>
		<li>RQ 3.1.2: How to reduce latencies involved in (COIN) program
		interactions where (COIN) program instance locations may change
		quickly? Can service-level requests be routed directly through
		in-band signaling methods instead of relying on out-of-band
		discovery, such as through the DNS?</li>
		<li>RQ 3.1.3: How to signal constraints used for routing requests
		towards (COIN) program instances in a scalable manner (i.e., for
		dynamically choosing the best possible service sequence of one or
		more (COIN) programs for a given application experience through
		chaining (COIN) program executions)?</li>
		<li>RQ 3.1.4: How to identify (COIN) programs and program
		instances so as to allow routing (service) requests to specific
		instances of a given service?</li>
		<li>RQ 3.1.5: How to identify a specific choice of a (COIN) program
		instance over others, thus allowing pinning the execution of a
		service of a specific (COIN) program to a specific resource (i.e., a
		(COIN) program instance in the distributed environment)?</li>
		<li>RQ 3.1.6: How to provide affinity of service requests towards
		(COIN) program instances (i.e., longer-term transactions with
		ephemeral state established at a specific (COIN) program
		instance)?</li>
		<li>RQ 3.1.7: How to provide constraint-based routing decisions
		that can be realized at packet forwarding speed (e.g., using
		techniques explored in <xref target="SarNet2021"/> at the
		forwarding plane or using approaches like <xref
		target="Multi2020"/> for extended routing protocols)?</li>
		<li>RQ 3.1.8: What COIN capabilities may support the execution of
		(COIN) programs and their instances?</li>
		<li>RQ 3.1.9: How to ensure real-time synchronization and
		consistency of distributed application states among (COIN) program
		instances, in particular, when frequently changing the choice for a
		particular (COIN) program in terms of executing a service
		instance?</li>
		</ul>


	<t>Extended reality (XR) encompasses VR, Augmented Reality (AR) and Mixed Realit	</section>
	y (MR).	</section>
	It provides the basis for the metaverse and is the driver of a number of advance	<section anchor="XR">
	s in interactive technologies.	<name>Extended Reality and Immersive Media</name>
	While initially associated with gaming and immersive entertainment, applications	<section anchor="description-1">
	now include remote diagnosis, maintenance, telemedicine, manufacturing and asse
	mbly, intelligent agriculture, smart cities, and immersive classrooms.
	XR is one example of the multisource-multidestination problem that combines vide
	o and haptics in interactive multi-party interactions under strict delay require
	ments that can benefit from a functional distribution that includes fog computin
	g for local information processing, the edge for aggregation, and the cloud for
	image processing.</t>


	<t>XR stands to benefit significantly from computing capabilities in the network	<!-- [rfced] FYI, for readability, we made this into two sentences at
	.	"that can benefit". Please review.
	For example, XR applications can offload intensive processing tasks to edge serv
	ers, considerably reducing latency when compared to cloud-based applications and
	enhancing the overall user experience.
	More importantly, COIN can enable collaborative XR experiences, where multiple u
	sers interact in the same virtual space in real-time, regardless of their physic
	al locations, by allowing resource discovery and re-rerouting of XR streams.
	While not a feature of most XR implementations, this capability opens up new pos
	sibilities for remote collaboration, training, and entertainment.
	Furthermore, COIN can support dynamic content delivery, allowing XR applications
	to seamlessly adapt to changing environments and user interactions.
	Hence, the integration of computing capabilities into the network architecture e
	nhances the scalability, flexibility, and performance of XR applications by supp
	lying telemetry and advanced stream management, paving the way for more immersiv
	e and interactive experiences.</t>


	<t>Indeed, XR applications require real-time interactivity for immersive and inc	Original:
	reasingly mobile applications with tactile and time-sensitive data.	XR is one example of the multisource-
	Because high bandwidth is needed for high resolution images and local rendering	multidestination problem that combines video and haptics in
	for 3D images and holograms, strictly relying on cloud-based architectures, even	interactive multi-party interactions under strict delay requirements
	with headset processing, limits some of its potential benefits in the collabora	that can benefit from a functional distribution that includes fog
	tive space.	computing for local information processing, the edge for aggregation,
	As a consequence, innovation is needed to unlock the full potential of XR.</t>	and the cloud for image processing.


	</section>	Current:
	<section anchor="characterization-1"><name>Characterization</name>	XR is one example of the multisource-
		multidestination problem that combines video and haptics in
		interactive multiparty interactions under strict delay requirements.
		As such, XR can benefit from a functional distribution that includes
		fog computing for local information processing, the edge for
		aggregation, and the cloud for image processing.
		-->


	<t>As mentioned above, XR experiences, especially those involving collaboration,	<name>Description</name>
	are difficult to deliver with a client-server cloud-based solution as they requ	<t>Extended Reality (XR) encompasses VR, Augmented Reality (AR) and
	ire a combination of multi-stream aggregation, low delays and delay variations,	Mixed Reality (MR). It provides the basis for the metaverse and is
	means to recover from losses, and optimized caching and rendering as close as po	the driver of a number of advances in interactive technologies.
	ssible to the user at the network edge.	While initially associated with gaming and immersive entertainment,
	Hence, implementing such XR solutions necessitates substantial computational pow	applications now include remote diagnosis, maintenance,
	er and minimal latency, which, for now, has spurred the development of better he	telemedicine, manufacturing and assembly, intelligent agriculture,
	adsets not networked or distributed solutions as factors like distance from clou	smart cities, and immersive classrooms. XR is one example of the
	d servers and limited bandwidth can still significantly lower application respon	multisource-multidestination problem that combines video and haptics
	siveness.	in interactive multiparty interactions under strict delay
	Furthermore, when XR deals with sensitive information, XR applications must also	requirements. As such, XR can benefit from a functional distribution t
	provide a secure environment and ensure user privacy, which represent additiona	hat
	l burdens for delay sensitive applications.	includes fog computing for local information processing, the edge
	Additionally, the sheer amount of data needed for and generated by the XR applic	for aggregation, and the cloud for image processing.</t>
	ations, such as video holography, put them squarely in the realm of data-driven
	applications that can use recent trend analysis and mechanisms, as well as machi
	ne learning to find the optimal caching and processing solution and, ideally, re
	duce the size of the data that needs transiting through the network.
	Other mechanisms, such as data filtering and reduction, and functional distribut
	ion and partitioning are also needed to accommodate the low delay needs for the
	same applications.</t>


	<t>With functional decomposition the goal of a better XR experience, the element s involved in a COIN XR implementation include:</t>	<!-- [rfced] Should "re-rerouting" be updated to "re-routing" here?


	<t><list style="symbols">	Original:
	<t>the XR application residing in the headset,</t>	More importantly, COIN can enable collaborative XR experiences, where
	<t>edge federation services that allow local devices to communicate with one a	multiple users interact in the same virtual space in real-time, regardless
	nother directly,</t>	of their physical locations, by allowing resource discovery and
	<t>egde application servers that enable local processing but also intelligent	re-rerouting of XR streams.
	stream aggregation to reduce bandwidth requirements,</t>
	<t>edge data networks to allow precaching of information based on locality and
	usage,</t>
	<t>cloud-based services for image processing and application training, and</t>
	<t>intelligent 5G/6G core networks for managing advanced access services and p
	roviding performance data for XR stream management.</t>
	</list></t>


	<t>These characteristics of XR paired with the capabilities of COIN make it like	Perhaps:
	ly that COIN can help to realize XR over networks for collaborative applications	More importantly, COIN can enable collaborative XR experiences, where
	.	multiple users interact in the same virtual space in real time, regardless
	In particular, COIN functions can enable the distribution of the service compone	of their physical locations, by allowing resource discovery and
	nts across different nodes in the network.	re-routing of XR streams.
	For example, data filtering, image rendering, and video processing leveraging di	-->
	fferent hardware capabilities with combinations of CPU and GPU at the network ed
	ge and in the fog, where the content is consumed, represent possible remedies fo
	r the high bandwidth demands of XR.
	Machine learning across the network nodes can better manage the data flows by di
	stributing them over more adequate paths.
	In order to provide adequate quality of experience, multi-variate and heterogene
	ous resource allocation and goal optimization problems need to be solved, likely
	requiring advanced analysis and articificial intelligence.
	For the purpose of this document, it is important to note that the use of COIN f
	or XR does not imply a specific protocol but targets an architecture enabling th
	e deployment of the services.
	In this context, similar considerations as for <xref target="mobileAppOffload"/>
	apply.</t>


	</section>	<t>XR stands to benefit significantly from computing capabilities in
	<section anchor="existing-solutions-1"><name>Existing Solutions</name>	the network. For example, XR applications can offload intensive
		processing tasks to edge servers, considerably reducing latency when
		compared to cloud-based applications and enhancing the overall user
		experience. More importantly, COIN can enable collaborative XR
		experiences, where multiple users interact in the same virtual space
		in real time, regardless of their physical locations, by allowing
		resource discovery and re-rerouting of XR streams. While not a
		feature of most XR implementations, this capability opens up new
		possibilities for remote collaboration, training, and entertainment.
		Furthermore, COIN can support dynamic content delivery, allowing XR
		applications to seamlessly adapt to changing environments and user
		interactions. Hence, the integration of computing capabilities into
		the network architecture enhances the scalability, flexibility, and
		performance of XR applications by supplying telemetry and advanced
		stream management, paving the way for more immersive and interactive
		experiences.</t>
		<t>Indeed, XR applications require real-time interactivity for
		immersive and increasingly mobile applications with tactile and
		time-sensitive data. Because high bandwidth is needed for high
		resolution images and local rendering for 3D images and holograms,
		strictly relying on cloud-based architectures, even with headset
		processing, limits some of its potential benefits in the
		collaborative space. As a consequence, innovation is needed to
		unlock the full potential of XR.</t>
		</section>
		<section anchor="characterization-1">
		<name>Characterization</name>


	<t>The XR field has profited from extensive research in the past years in gaming	<!-- [rfced] For clarity, may we update "not networked or distributed"
	, machine learning, network telemetry, high resolution imaging, smart cities, an	in the text below to be more descriptive?
	d IoT.
	Information Centric Networking (and related) approaches that combine publish sub
	scribe and distributed storage are also very suited for the multisource-multides
	tination applications of XR.
	New AR/VR headsets and glasses have continued to evolve towards autonomy with lo
	cal computation capabilities, increasingly performing many of the processing tha
	t is needed to render and augment the local images.
	Mechanisms aimed at enhancing the computational and storage capacities of mobile
	devices could also improve XR capabilities as they include the discovery of ava
	ilable servers within the environment and using them opportunistically to enhanc
	e the performance of interactive applications and distributed file systems.</t>


	<t>While there is still no specific COIN research in AR and VR, the need for net	Original:
	work-support is important to offload some of the computations related to movemen	Hence, implementing such XR solutions necessitates substantial
	t, multi-user interactions, and networked applications notably in gaming but als	computational power and minimal latency, which, for now, has spurred the
	o in health <xref target="NetworkedVR"/>.<br />	development of better headsets not networked or distributed solutions as
	This new approach to networked AR/VR is exemplified in <xref target="eCAR"/> by	factors like distance from cloud servers and limited bandwidth can still
	using synchronized messaging at the edge to share the information that all users	significantly lower application responsiveness.
	need to interact.
	In <xref target="CompNet2021"/> and <xref target="WirelessNet2024"/>, the offloa
	ding uses artificial intelligence to assign the 5G resources necessary for the r
	eal time interactions and one could think that implementing this scheme on a PND
	is essentially a natural next step.
	Hence, as AR/VR/XR is increasingly becoming interactive, the efficiency needed t
	o implement novel applications will require some form or another of edge-core im
	plementation and COIN support.</t>


	<t>Summarizing, some XR solutions exist and headsets continue to evolve to what	Perhaps:
	is now claimed to be spatial computing.	Hence, implementing such XR solutions necessitates substantial
	Additionally, with recent work on the Metaverse, the number of publications rela	computational power and minimal latency, which, for now, has spurred the
	ted to XR has skyrocketed.	development of better headsets, rather than spurring networked or
	However, in terms of networking, which is the focus of this document, current de	distributed solutions, as factors like distance from cloud servers and
	ployments do not take advantage of network capabilities.	limited bandwidth can still significantly lower application responsiveness.
	The information is rendered and displayed based on the local processing but does	-->
	not readily discover the other elements in the vicinity or in the network that
	could improve its performance either locally, at the edge, or in the cloud.
	Yet, there are still very few interactive immersive media applications over netw
	orks that allow for federating systems capabilities.</t>


	</section>	<t>As mentioned above, XR experiences, especially those
	<section anchor="opportunities-1"><name>Opportunities</name>	involving collaboration, are difficult to deliver with a
		client-server cloud-based solution. This is because they require a
		combination of multistream aggregation, low delays and delay
		variations, means to recover from losses, and optimized caching and
		rendering as close as possible to the user at the network edge.
		Hence, implementing such XR solutions necessitates substantial
		computational power and minimal latency, which, for now, has spurred
		the development of better headsets not networked or distributed
		solutions as factors like distance from cloud servers and limited
		bandwidth can still significantly lower application responsiveness.
		Furthermore, when XR deals with sensitive information, XR
		applications must also provide a secure environment and ensure user
		privacy, which represent additional burdens for delay-sensitive
		applications. Additionally, the sheer amount of data needed for and
		generated by XR applications, such as video holography, put them
		squarely in the realm of data-driven applications that can use
		recent trend analysis and mechanisms, as well as machine learning,
		in order to find the optimal caching and processing solution and
		ideally reduce the size of the data that needs transiting through
		the network. Other mechanisms, such as data filtering and
		reduction, and functional distribution and partitioning, are also
		needed to accommodate the low delay needs for the same
		applications.</t>


	<t>While delay is inherently related to information transmission and if we conti	<t>With functional decomposition as the goal of a better XR experience
	nue the analogy of the computer board to highlight some of the COIN capabilities	,
	in terms of computation and storage but also allocation of resources, there are	the elements involved in a COIN XR implementation include:</t>
	some opportunities that XR could take advantage of:</t>	<ul spacing="normal">
		<li>
		<t>the XR application residing in the headset,</t>
		</li>
		<li>
		<t>edge federation services that allow local devices to
		communicate with one another directly,</t>
		</li>
		<li>
		<t>edge application servers that enable local processing but
		also intelligent stream aggregation to reduce bandwidth
		requirements,</t>
		</li>
		<li>
		<t>edge data networks that allow precaching of information based
		on locality and usage,</t>
		</li>
		<li>
		<t>cloud-based services for image processing and application
		training, and</t>
		</li>
		<li>
		<t>intelligent 5G/6G core networks for managing advanced access
		services and providing performance data for XR stream
		management.</t>
		</li>
		</ul>
		<t>These characteristics of XR paired with the capabilities of COIN
		make it likely that COIN can help to realize XR over networks for
		collaborative applications. In particular, COIN functions can
		enable the distribution of the service components across different
		nodes in the network. For example, data filtering, image rendering,
		and video processing leverage different hardware capabilities with
		combinations of CPUs and Graphics Processing Units (GPUs) at the
		network edge and in the fog, where the content is consumed. These
		represent possible remedies for the high bandwidth demands of XR.
		Machine learning across the network nodes can better manage the data
		flows by distributing them over more adequate paths. In order to
		provide adequate quality of experience, multivariate and
		heterogeneous resource allocation and goal optimization problems
		need to be solved, likely requiring advanced analysis and
		artificial intelligence. For the purpose of this document, it is
		important to note that the use of COIN for XR does not imply a
		specific protocol but targets an architecture enabling the
		deployment of the services. In this context, similar considerations
		as for <xref target="mobileAppOffload"/> apply.</t>
		</section>
		<section anchor="existing-solutions-1">
		<name>Existing Solutions</name>


	<t><list style="symbols">	<!-- [rfced] We have added additional punctuation to the text below. Please
	<t>Round trip time: 20 ms is usually cited as an upper limit for XR applicatio	review these updates and confirm that they do not change your intended
	ns. Storage and preprocessing of scenes in local elements (including in the mobi	meaning.
	le network) could extend the reach of XR applications at least over the extended
	edge.</t>
	<t>Video transmission: The use of better transcoding, advanced context-based c
	ompression algorithms, prefetching and precaching, as well as movement predictio
	n all help to reduce bandwidth consumption. While this is now limited to local p
	rocessing it is not outside the realm of COIN to push some of these functionalit
	ies to the network especially as realted to caching/fetching but also context ba
	sed flow direction and aggregation.</t>
	<t>Monitoring: Since bandwidth and data are fundamental for XR deployment, COI
	N functionality could help to better monitor and distribute the XR services over
	collaborating network elements to optimize end-to-end performance.</t>
	<t>Functional decomposition: Advanced functional decomposition, localization,
	and discovery of computing and storage resources in the network can help to opti
	mize user experience in general.</t>
	<t>Intelligent network management and configuration: The move to artificial in
	telligence in network management to learn about flows and adapt resources based
	on both data plane and control plane programmability can help the overall deploy
	ment of XR services.</t>
	</list></t>


	</section>	Original:
	<section anchor="research-questions"><name>Research Questions</name>	Information Centric Networking (and related) approaches that combine
		publish subscribe and distributed storage are also very suited for the
		multisource-multidestination applications of XR.


	<t><list style="symbols">	Current:
	<t>RQ 3.2.1: Can current PNDs provide the speed required for executing complex	Information-centric networking (and related) approaches that combine,
	filtering operations, including metadata analysis for complex and dynamic scene	publish, subscribe, and distribute storage are also very suited for
	rendering?</t>	the multisource-multidestination applications of XR.
	<t>RQ 3.2.2: Where should PNDs equipped with these operations be located for o	-->
	ptimal performance gains?</t>
	<t>RQ 3.2.3: Can the use of distributed AI algorithms across both data center
	and edge computers be leveraged for creating optimal function allocation and the
	creation of semi-permanent datasets and analytics for usage trending and flow m
	anagement resulting in better localization of XR functions?</t>
	<t>RQ 3.2.4: Can COIN improve the dynamic distribution of control, forwarding,
	and storage resources and related usage models in XR, such as to integrate loca
	l and fog caching with cloud-based pre-rendering, thus jointly optimizing COIN a
	nd higher layer protocols to reduce latency and, more generally, manage the qual
	ity of XR sessions, e.g., through reduced in-network congestion and improved flo
	w delivery by determining how to prioritize XR data?</t>
	<t>RQ 3.2.5: Can COIN provide the necessary infrastructure for the use of inte
	ractive XR everywhere? Particularly, how can a COIN system enable the joint coll
	aboration across all segments of the network (fog, edge, core, and cloud) to sup
	port functional decompositions, including using edge resources without the need
	for a (remote) cloud connection?</t>
	<t>RQ 3.2.6: How can COIN systems provide multi-stream efficient transmission
	and stream combining at the edge, including the ability to dynamically include e
	xtra streams, such as audio and extra video tracks?</t>
	</list></t>


	</section>	<!-- [rfced] For clarity, may we change 'the discovery of' to 'discovering'?
	<section anchor="additional-desirable-capabilities"><name>Additional Desirable C	This makes the action parallel with 'using' (in other words,
	apabilities</name>	'they include discovering X and using them to do Y').


	<t>In addition to the capabilities driven by the research questions above, there	Original:
	are a number of other features that solutions in this space might benefit from.	Mechanisms aimed at enhancing the computational and storage capacities of
	In particular, the provided XR experience should be optimized both in amount of	mobile devices could also improve XR capabilities as they include the
	transmitted data, while equally optimizing loss protection.	discovery of available servers within the environment and using them
	Furthermore, means for trend analysis and telemetry to measure performance may f	opportunistically to enhance the performance of interactive applications
	oster uptake of the XR services, while the interaction of the XR system with ind	and distributed file systems.
	oor and outdoor positioning systems may improve on service experience and user p
	erception.</t>


	</section>	Perhaps:
	</section>	Mechanisms aimed at enhancing the computational and storage capacities of
	<section anchor="PerformingArts"><name>Personalized and interactive performing a	mobile devices could also improve XR capabilities, as they include
	rts</name>	discovering available servers within the environment and using them
		opportunistically to enhance the performance of interactive applications
		and distributed file systems.
		-->


	<section anchor="description-2"><name>Description</name>	<t>The XR field has profited from extensive research in the past
	<t>This use case is a deeper dive into a specific scenario of the immersive and	years in gaming, machine learning, network telemetry, high
	extended reality class of use cases discussed in <xref target="XR"/>.	resolution imaging, smart cities, and the Internet of Things (IoT).
	It focuses on live productions of the performing arts where the performers and a	Information-centric networking (and related) approaches that combine,
	udience members are geographically distributed.	publish, subscribe, and distribute storage are also very suited for
	The performance is conveyed through multiple networked streams which are tailore	the multisource-multidestination applications of XR. New AR and VR
	d to the requirements of the remote performers, the director, sound and lighting	headsets and glasses have continued to evolve towards autonomy with
	technicians, and individual audience members; performers need to observe, inter	local computation capabilities, increasingly performing much of the
	act and synchronize with other performers in remote locations; and the performer	processing that is needed to render and augment the local images.
	s receive live feedback from the audience, which may also be conveyed to other a	Mechanisms aimed at enhancing the computational and storage
	udience members.</t>	capacities of mobile devices could also improve XR capabilities as
		they include the discovery of available servers within the
		environment and using them opportunistically to enhance the
		performance of interactive applications and distributed file
		systems.</t>
		<t>While there is still no specific COIN research in AR and VR, the
		need for network support is important to offload some of the
		computations related to movement, multiuser interactions, and
		networked applications, notably in gaming but also in health <xref
		target="NetworkedVR"/>. This new approach to networked AR and VR is
		exemplified in <xref target="eCAR"/> by using synchronized messaging
		at the edge to share the information that all users need to
		interact. In <xref target="CompNet2021"/> and <xref
		target="WirelessNet2024"/>, the offloading uses Artificial
		Intelligence (AI) to assign the 5G resources necessary for the
		real-time interactions, and one could think that implementing this
		scheme on a PND is essentially a natural next step. Hence, as AR,
		VR, and XR are increasingly becoming more interactive, the
		efficiency needed to implement novel applications will require some
		form or another of edge-core implementation and COIN support.</t>


	<t>There are two main aspects: i) to emulate as closely as possible the experien	<!-- [rfced] Would "federating systems capabilities" be more clear as
	ce of live performances where the performers, audience, director, and technician	"the federation of systems capabilities" here?
	s are co-located in the same physical space, such as a theater; and ii) to enhan
	ce traditional physical performances with features such as personalization of th
	e experience according to the preferences or needs of the performers, directors,
	and audience members.</t>


	<t>Examples of personalization include:</t>	Original:
		Yet, there are still very few interactive immersive media applications
		over networks that allow for federating systems capabilities.


	<t><list style="symbols">	Perhaps:
	<t>Viewpoint selection such as choosing a specific seat in the theater or for	Yet, there are still very few interactive immersive media applications
	more advanced positioning of the audience member's viewpoint outside of the trad	over networks that allow for the federation of systems capabilities.
	itional seating - amongst, above, or behind the performers (but within some limi	-->
	ts which may be imposed by the performers or the director, for artistic reasons)
	;</t>
	<t>Augmentation of the performance with subtitles, audio-description, actor-ta
	gging, language translation, advertisements/product-placement, other enhancement
	s/filters to make the performance accessible to disabled audience members (remov
	al of flashing images for epileptics, alternative color schemes for color-blind
	audience members, etc.).</t>
	</list></t>


	</section>	<t>In summary, some XR solutions exist, and headsets continue to
	<section anchor="characterization-2"><name>Characterization</name>	evolve to what is now claimed to be spatial computing.
	<t>There are several chained functional entities which are candidates for being	Additionally, with recent work on the metaverse, the number of
	deployed as (COIN) programs:</t>	publications related to XR has skyrocketed. However, in terms of
		networking, which is the focus of this document, current deployments
		do not take advantage of network capabilities. The information is
		rendered and displayed based on the local processing but does not
		readily discover the other elements in the vicinity or in the
		network that could improve its performance either locally, at the
		edge, or in the cloud. Yet, there are still very few interactive and
		immersive media applications over networks that allow for federating
		systems capabilities.</t>
		</section>


	<t><list style="symbols">	<section anchor="opportunities-1">
	<t>Performer aggregation and editing functions</t>	<name>Opportunities</name>
	<t>Distribution and encoding functions</t>	<t>While delay is inherently related to information transmission, if
	<t>Personalization functions	we continue the analogy of the computer board to highlight some of
	<list style="symbols">	the COIN capabilities in terms of computation and storage but also
	<t>to select which of the existing streams should be forwarded to the audi	allocation of resources, there are some opportunities that XR could
	ence member, remote performer, or member of the production team</t>	take advantage of:</t>
	<t>to augment streams with additional metadata such as subtitles</t>	<ul spacing="normal">
	<t>to create new streams after processing existing ones, e.g., to interpol	<li>
	ate between camera angles to create a new viewpoint or to render point clouds fr	<t>Round trip time: 20 ms is usually cited as an upper limit for
	om an audience member's chosen perspective</t>	XR applications. Storage and preprocessing of scenes in local
	<t>to undertake remote rendering according to viewer position, e.g., creat	elements (including in the mobile network) could extend the
	ion of VR headset display streams according to audience head position - when thi	reach of XR applications at least over the extended edge.</t>
	s processing has been offloaded from the viewer's end-system to the COIN functio	</li>
	n due to limited processing power in the end-system, or to limited network bandw	<li>
	idth to receive all of the individual streams to be processed.</t>	<t>Video transmission: The use of better transcoding, advanced
	</list></t>	context-based compression algorithms, prefetching and
	<t>Audience feedback sensor processing functions</t>	precaching, as well as movement prediction all help to reduce
	<t>Audience feedback aggregation functions</t>	bandwidth consumption. While this is now limited to local
	</list></t>	processing, it is not outside the realm of COIN to push some of
		these functionalities to the network, especially as related to
		caching and fetching but also context-based flow direction and
		aggregation.</t>
		</li>
		<li>
		<t>Monitoring: Since bandwidth and data are fundamental to XR
		deployment, COIN functionality could help to better monitor and
		distribute the XR services over collaborating network elements
		to optimize end-to-end performance.</t>
		</li>
		<li>
		<t>Functional decomposition: Advanced functional decomposition,
		localization, and discovery of computing and storage resources
		in the network can help to optimize user experience in
		general.</t>
		</li>
		<li>
		<t>Intelligent network management and configuration: The move to
		AI in network management to learn about
		flows and adapt resources based on both data plane and control
		plane programmability can help the overall deployment of XR
		services.</t>
		</li>
		</ul>
		</section>
		<!-- [rfced] For readability and clarity of RQ 3.2.3


	<t>These are candidates for deployment as (COIN) Programs in PNDs rather than be	a) Is this about two separate research questions ("the use of distributed AI"
	ing located in end-systems (at the performers' site, the audience members' premi	and "the creation of semi-permanent datasets")? May they be two separate
	ses or in a central cloud location) for several reasons:</t>	sentences?


	<t><list style="symbols">	b) May we adjust "resulting in" to "result in" to add a clear verb to the
	<t>Personalization of the performance according to viewer preferences and requ	second half of this text?
	irements makes it infeasible to be done in a centralized manner at the performer
	premises: the computational resources and network bandwidth would need to scale
	with the number of personalized streams.</t>
	<t>Rendering of VR headset content to follow viewer head movements has an uppe
	r bound on lag to maintain viewer QoE, which requires the processing to be under
	taken sufficiently close to the viewer to avoid large network latencies.</t>
	<t>Viewer devices may not have the processing-power to perform the personaliza
	tion tasks, or the viewers' network may not have the capacity to receive all of
	the constituent streams to undertake the personalization functions.</t>
	<t>There are strict latency requirements for live and interactive aspects that
	require the deviation from the direct network path between performers and audie
	nce members to be minimized, which reduces the opportunity to route streams via
	large-scale processing capabilities at centralized data-centers.</t>
	</list></t>


	</section>	Original:
	<section anchor="existing-solutions-2"><name>Existing solutions</name>	* RQ 3.2.3: Can the use of distributed AI algorithms across both
	<t>Note: Existing solutions for some aspects of this use case are covered in <xr	data center and edge computers be leveraged for creating optimal
	ef target="mobileAppOffload"/>, <xref target="XR"/>, and <xref target="CDNs"/>.<	function allocation and the creation of semi-permanent datasets
	/t>	and analytics for usage trending and flow management resulting in
		better localization of XR functions?


	</section>	Perhaps:
	<section anchor="opportunities-2"><name>Opportunities</name>	* RQ 3.2.3: Can the use of distributed AI algorithms across both
		data center and edge computers be leveraged for creating optimal
		function allocation? Can the creation of semi-permanent datasets
		and analytics for usage trending and flow management result in
		better localization of XR functions?
		-->


	<t><list style="symbols">	<!-- [rfced] For ease of the reader, may we break this one sentence into two?
	<t>Executing media processing and personalization functions on-path as (COIN)	In addition, may we update the verb "optimize" to "optimizing" as follows?
	Programs in PNDs can avoid detour/stretch to central servers, thus reducing late
	ncy and bandwidth consumption.
	For example, the overall delay for performance capture, aggregation, distributio
	n, personalization, consumption, capture of audience response, feedback processi
	ng, aggregation, and rendering should be achieved within an upper bound of laten
	cy (the tolerable amount is to be defined, but in the order of 100s of ms to mim
	ic performers perceiving audience feedback, such as laughter or other emotional
	responses in a theater setting).</t>
	<t>Processing of media streams allows (COIN) Programs, PNDs and the wider (COI
	N) System/Environment to be contextually aware of flows and their requirements w
	hich can be used for determining network treatment of the flows, e.g., path sele
	ction, prioritization, multi-flow coordination, synchronization and resilience.<
	/t>
	</list></t>


	</section>	Original:
	<section anchor="research-questions-1"><name>Research Questions:</name>	* RQ 3.2.4: Can COIN improve the dynamic distribution of control,
		forwarding, and storage resources and related usage models in XR,
		such as to integrate local and fog caching with cloud-based pre-
		rendering, thus jointly optimizing COIN and higher layer protocols
		to reduce latency and, more generally, manage the quality of XR
		sessions, e.g., through reduced in-network congestion and improved
		flow delivery by determining how to prioritize XR data?


	<t><list style="symbols">	Perhaps:
	<t>RQ 3.3.1: In which PNDs should (COIN) Programs for aggregation, encoding, a	* RQ 3.2.4: Can COIN improve the dynamic distribution of control,
	nd personalization functions be located? Close to the performers or close to the	forwarding, and storage resources and related usage models in XR,
	viewers?</t>	such as to integrate local and fog caching with cloud-based pre-
	<t>RQ 3.3.2: How far from the direct network path from performer to viewer sho	rendering? Could this jointly optimize COIN and higher layer protocols to
	uld (COIN) programs be located, considering the latency implications of path-str	reduce latency and, more generally, manage the quality of XR sessions
	etch and the availability of processing capacity at PNDs? How should tolerances	(e.g., through reduced in-network congestion and improved flow delivery
	be defined by users?</t>	by determining how to prioritize XR data)?
	<t>RQ 3.3.3: Should users decide which PNDs should be used for executing (COIN	-->
	) Programs for their flows or should they express requirements and constraints t	<section anchor="research-questions">
	hat will direct decisions by the orchestrator/manager of a COIN System? In case	<name>Research Questions</name>
	of the latter, how can users specify requirements on network and processing metr	<ul spacing="normal">
	ics (such as latency and throughput bounds)?</t>	<li>RQ 3.2.1: Can current PNDs provide the speed required for
	<t>RQ 3.3.4: How to achieve synchronization across multiple streams to allow f	executing complex filtering operations, including metadata
	or merging, audio-video interpolation, and other cross-stream processing functio	analysis for complex and dynamic scene rendering?</li>
	ns that require time synchronization for the integrity of the output?	<li>RQ 3.2.2: Where should PNDs equipped with these operations be
	How can this be achieved considering that synchronization may be required betwee	located for optimal performance gains?</li>
	n flows that are: i) on the same data pathway through a PND/router, ii) arriving	<li>RQ 3.2.3: Can the use of distributed AI algorithms across both
	/leaving through different ingress/egress interfaces of the same PND/router, iii	data center and edge computers be leveraged for creating optimal
	) routed through disjoint paths through different PNDs/routers?	function allocation and the creation of semi-permanent datasets
	This RQ raises issues associated with synchronisation across multiple media stre	and analytics for usage trending and flow management resulting in
	ams and sub-streams <xref target="RFC7272"/> as well as time synchronisation bet	better localization of XR functions?</li>
	ween PNDs/routers on multiple paths <xref target="RFC8039"/>.</t>	<li>RQ 3.2.4: Can COIN improve the dynamic distribution of
	<t>RQ 3.3.5: Where will COIN Programs be executed? In the data-plane of PNDs,	control, forwarding, and storage resources and related usage
	in other on-router computational capabilities within PNDs, or in adjacent comput	models in XR, such as to integrate local and fog caching with
	ational nodes?</t>	cloud-based pre-rendering, thus jointly optimizing COIN and higher
	<t>RQ 3.3.6: Are computationally-intensive tasks - such as video stitching or	layer protocols to reduce latency and, more generally, manage the
	media recognition and annotation (cf. <xref target="XR"/>) - considered as suita	quality of XR sessions (e.g., through reduced in-network
	ble candidate (COIN) Programs or should they be implemented in end-systems?</t>	congestion and improved flow delivery by determining how to
	<t>RQ 3.3.7: If the execution of COIN Programs is offloaded to computational n	prioritize XR data)?</li>
	odes outside of PNDs, e.g., for processing by GPUs, should this still be conside	<li>RQ 3.2.5: Can COIN provide the necessary infrastructure for
	red as COIN? Where is the boundary between COIN capabilities and explicit routin	the use of interactive XR everywhere? Particularly, how can a COIN
	g of flows to endsystems?</t>	system enable the joint collaboration across all segments of the
	</list></t>	network (fog, edge, core, and cloud) to support functional
		decompositions, including using edge resources without the need
		for a (remote) cloud connection?</li>
		<li>RQ 3.2.6: How can COIN systems provide multistream efficient
		transmission and stream combining at the edge, including the
		ability to dynamically include extra streams, such as audio and
		extra video tracks?</li>
		</ul>
		</section>


	</section>	<section anchor="additional-desirable-capabilities">
	<section anchor="additional-desirable-capabilities-1"><name>Additional Desirable	<name>Additional Desirable Capabilities</name>
	Capabilities</name>	<t>In addition to the capabilities driven by the research questions
	<t>In addition to the capabilities driven by the research questions above, there	above, there are a number of other features that solutions in this
	are a number of other features that solutions in this space might benefit from.	space might benefit from. In particular, the provided XR experience
	In particular, if users are indeed empowered to specify requirements on network	should be optimized both in the amount of transmitted data, while
	and processing metrics, one important capability of COIN systems will be to resp	equally optimizing loss protection. Furthermore, the means for trend
	ect these user-specified requirements and constraints when routing flows and sel	analysis and telemetry to measure performance may foster uptake of
	ecting PNDs for executing (COIN) Programs.	the XR services, while the interaction of the XR system with indoor
	Similarly, solutions should be able to synchronize flow treatment and processing	and outdoor positioning systems may improve on service experience
	across multiple related flows which may be on disjoint paths to provide similar	and user perception.</t>
	performance to different entities.</t>	</section>
		</section>
		<section anchor="PerformingArts">
		<name>Personalized and Interactive Performing Arts</name>
		<section anchor="description-2">
		<name>Description</name>
		<t>This use case is a deeper dive into a specific scenario of the
		immersive and extended reality class of use cases discussed in
		<xref target="XR"/>. It focuses on live productions of the
		performing arts where the performers and audience members are
		geographically distributed. The performance is conveyed through
		multiple networked streams, which are tailored to the requirements
		of the remote performers, the director, the sound and lighting
		technicians, and the individual audience members. Performers need to
		observe, interact, and synchronize with other performers in remote
		locations, and the performers receive live feedback from the
		audience, which may also be conveyed to other audience members.</t>


	</section>	<t>There are two main aspects:</t>
	</section>	<ol type="i">
	</section>	<li>to emulate as closely as possible the experience of live
	<section anchor="newEnvironments"><name>Supporting new COIN Systems</name>	performances where the performers, audience, director, and
		technicians are co-located in the same physical space, such as a
		theater; and</li>
		<li>to enhance traditional physical performances with features
		such as personalization of the experience according to the
		preferences or needs of the performers, directors, and audience
		members.</li>
		</ol>


	<section anchor="control"><name>In-Network Control / Time-sensitive applications	<t>Examples of personalization include:</t>
	</name>	<ul spacing="normal">
		<li>
		<t>Viewpoint selection, such as choosing a specific seat in the
		theater or for more advanced positioning of the audience
		member's viewpoint outside of the traditional seating (i.e.,
		amongst, above, or behind the performers, but within some limits
		that may be imposed by the performers or the director for
		artistic reasons);</t>
		</li>
		<!--[rfced] FYI, this text has been updated to use person-first language.
		Please let us know if you prefer otherwise.


	<section anchor="description-3"><name>Description</name>	Original:
	<t>The control of physical processes and components of industrial production lin	* Augmentation of the performance with subtitles, audio-description,
	es is essential for the growing automation of production and ideally allows for	actor-tagging, language translation, advertisements/product-
	a consistent quality level.	placement, other enhancements/filters to make the performance
	Traditionally, the control has been exercised by control software running on pro	accessible to disabled audience members (removal of flashing
	grammable logic controllers (PLCs) located directly next to the controlled proce	images for epileptics, alternative color schemes for color-blind
	ss or component.	audience members, etc.).
	This approach is best-suited for settings with a simple model that is focused on
	a single or few controlled components.</t>


	<t>Modern production lines and shop floors are characterized by an increasing nu	Current:
	mber of involved devices and sensors, a growing level of dependency between the	* Augmentation of the performance with subtitles, audio description,
	different components, and more complex control models.	actor tagging, language translation, advertisements and product
	A centralized control is desirable to manage the large amount of available infor	placement, and other enhancements and filters to make the
	mation which often has to be preprocessed or aggregated with other information b	performance accessible to audience members who are disabled (e.g.,
	efore it can be used.	the removal of flashing images for audience members who have
	As a result, computations are increasingly spatially decoupled and moved away fr	epilepsy or alternative color schemes for those who have color
	om the controlled objects, thus inducing additional latency.	blindness).
	Instead moving compute functionality onto COIN execution environments inside the	-->
	network offers a new solution space to these challenges, providing new compute	<li>
	locations with much smaller latencies.</t>	<t>Augmentation of the performance with subtitles, audio
		description, actor tagging, language translation, advertisements
		and product placement, and other enhancements and filters to
		make the performance accessible to audience members who are disabl
		ed
		(e.g., the removal of flashing images for audience members who hav
		e epilepsy or alternative color
		schemes for those who have color blindness).</t>
		</li>
		</ul>
		</section>


	</section>	<section anchor="characterization-2">
	<section anchor="characterization-3"><name>Characterization</name>	<name>Characterization</name>
		<t>There are several chained functional entities that are
		candidates for being deployed as (COIN) programs:</t>
		<ul spacing="normal">
		<li>
		<t>Performer aggregation and editing functions</t>
		</li>
		<li>
		<t>Distribution and encoding functions</t>
		</li>
		<li>
		<t>Personalization functions
		</t>
		<ul spacing="normal">
		<li>
		<t>to select which of the existing streams should be
		forwarded to the audience member, remote performer, or
		member of the production team</t>
		</li>
		<li>
		<t>to augment streams with additional metadata such as subtitl
		es</t>
		</li>
		<li>
		<t>to create new streams after processing existing ones
		(e.g., to interpolate between camera angles to create a new
		viewpoint or to render point clouds from an audience
		member's chosen perspective)</t>
		</li>
		<li>
		<t>to undertake remote rendering according to viewer
		position (e.g., the creation of VR headset display streams
		according to audience head position) when this processing
		has been offloaded from the viewer's end system to the COIN
		function due to limited processing power in the end system
		or due to limited network bandwidth to receive all of the
		individual streams to be processed.</t>
		</li>
		</ul>
		</li>
		<li>
		<t>Audience feedback sensor processing functions</t>
		</li>
		<li>
		<t>Audience feedback aggregation functions</t>
		</li>
		</ul>
		<t>These are candidates for deployment as (COIN) programs in PNDs
		rather than being located in end systems (at the performers' site,
		the audience members' premises, or in a central cloud location) for
		several reasons:</t>
		<ul spacing="normal">
		<li>
		<t>Personalization of the performance according to viewer
		preferences and requirements makes it infeasible to be done in a
		centralized manner at the performer premises: the computational
		resources and network bandwidth would need to scale with the
		number of personalized streams.</t>
		</li>
		<li>
		<t>Rendering of VR headset content to follow viewer head
		movements has an upper bound on lag to maintain viewer Quality of
		Experience (QoE),
		which requires the processing to be undertaken sufficiently
		close to the viewer to avoid large network latencies.</t>
		</li>
		<li>
		<t>Viewer devices may not have the processing power to perform
		the personalization tasks, or the viewers' network may not have
		the capacity to receive all of the constituent streams to
		undertake the personalization functions.</t>
		</li>
		<li>
		<t>There are strict latency requirements for live and
		interactive aspects that require the deviation from the direct
		network path between performers and audience members to be
		minimized, which reduces the opportunity to route streams via
		large-scale processing capabilities at centralized
		data centers.</t>
		</li>
		</ul>
		</section>
		<section anchor="existing-solutions-2">
		<name>Existing Solutions</name>
		<t>Note: Existing solutions for some aspects of this use case are
		covered in <xref target="mobileAppOffload"/>, <xref target="XR"/>,
		and <xref target="CDNs"/>.</t>
		</section>
		<section anchor="opportunities-2">
		<name>Opportunities</name>


	<t>A control process consists of two main components as illustrated in <xref tar	<ul spacing="normal">
	get="processControl"/>: a system under control and a controller.	<li>
	In feedback control, the current state of the system is monitored, e.g., using s	<t>Executing media processing and personalization functions
	ensors, and the controller influences the system based on the difference between	on-path as (COIN) programs in PNDs can avoid detour/stretch to
	the current and the reference state to keep it close to this reference state.</	central servers, thus reducing latency and bandwidth
	t>	consumption. For example, the overall delay for performance
		capture, aggregation, distribution, personalization,
		consumption, capture of audience response, feedback processing,
		aggregation, and rendering should be achieved within an upper
		bound of latency (the tolerable amount is to be defined, but in
		the order of 100s of ms to mimic performers perceiving audience
		feedback, such as laughter or other emotional responses in a
		theater setting).</t>
		</li>
		<li>
		<t>Processing of media streams allows (COIN) programs, PNDs, and
		the wider (COIN) system/environment to be contextually aware of
		flows and their requirements, which can be used for determining
		network treatment of the flows (e.g., path selection,
		prioritization, multiflow coordination, synchronization, and
		resilience).</t>
		</li>
		</ul>
		</section>
		<section anchor="research-questions-1">
		<name>Research Questions</name>
		<ul spacing="normal">
		<li>
		<t>RQ 3.3.1: In which PNDs should (COIN) programs for
		aggregation, encoding, and personalization functions be located?
		Close to the performers or close to the viewers?</t>
		</li>
		<li>
		<t>RQ 3.3.2: How far from the direct network path from performer
		to viewer should (COIN) programs be located, considering the
		latency implications of path-stretch and the availability of
		processing capacity at PNDs? How should tolerances be defined by
		users?</t>
		</li>
		<li>
		<t>RQ 3.3.3: Should users decide which PNDs should be used for
		executing (COIN) programs for their flows, or should they express
		requirements and constraints that will direct decisions by the
		orchestrator/manager of a COIN system? In case of the latter,
		how can users specify requirements on network and processing
		metrics (such as latency and throughput bounds)?</t>
		</li>
		<li>
		<t>RQ 3.3.4: How to achieve synchronization across multiple
		streams to allow for merging, audio-video interpolation, and
		other cross-stream processing functions that require time
		synchronization for the integrity of the output? How can this
		be achieved considering that synchronization may be required
		between flows that are:</t>
		<ol type="i">
		<li>
		<t>on the same data pathway through a PND/router,</t>
		</li>
		<li>
		<t>arriving/leaving through different ingress/egress
		interfaces of the same PND/router, or</t>
		</li>
		<li>
		<t>routed through disjoint paths through different PNDs/routers
		?</t>
		</li>
		</ol>
		<t>This RQ raises issues associated with synchronization
		across multiple media streams and substreams <xref
		target="RFC7272"/> as well as time synchronization between
		PNDs/routers on multiple paths <xref
		target="RFC8039"/>.</t>
		</li>
		<li>
		<t>RQ 3.3.5: Where will COIN programs be executed? In the
		data plane of PNDs, in other on-router computational
		capabilities within PNDs, or in adjacent computational
		nodes?</t>
		</li>
		<li>
		<t>RQ 3.3.6: Are computationally intensive tasks, such as video
		stitching or media recognition and annotation (cf. <xref
		target="XR"/>), considered as suitable candidate (COIN)
		programs or should they be implemented in end systems?</t>
		</li>
		<li>
		<t>RQ 3.3.7: If the execution of COIN programs is offloaded to
		computational nodes outside of PNDs (e.g., for processing by
		GPUs), should this still be considered as COIN? Where is the
		boundary between COIN capabilities and explicit routing of flows
		to end systems?</t>
		</li>
		</ul>
		</section>


	<figure title="Simple feedback control model." anchor="processControl"><artwork>	<section anchor="additional-desirable-capabilities-1">
	<![CDATA[	<name>Additional Desirable Capabilities</name>
		<t>In addition to the capabilities driven by the research questions
		above, there are a number of other features that solutions in this
		space might benefit from. In particular, if users are indeed
		empowered to specify requirements on network and processing metrics,
		one important capability of COIN systems will be to respect these
		user-specified requirements and constraints when routing flows and
		selecting PNDs for executing (COIN) programs. Similarly, solutions
		should be able to synchronize flow treatment and processing across
		multiple related flows, which may be on disjoint paths, to provide
		similar performance to different entities.</t>
		</section>
		</section>
		</section>

		<section anchor="newEnvironments">
		<name>Supporting New COIN Systems</name>

		<section anchor="control">
		<name>In-Network Control / Time-Sensitive Applications</name>

		<section anchor="description-3">
		<name>Description</name>
		<t>The control of physical processes and components of industrial
		production lines is essential for the growing automation of
		production and ideally allows for a consistent quality level.
		Traditionally, the control has been exercised by control software
		running on Programmable Logic Controllers (PLCs) located directly
		next to the controlled process or component. This approach is
		best suited for settings with a simple model that is focused on a
		single or a few controlled components.</t>
		<t>Modern production lines and shop floors are characterized by an
		increasing number of involved devices and sensors, a growing level
		of dependency between the different components, and more complex
		control models. A centralized control is desirable to manage the
		large amount of available information, which often has to be
		preprocessed or aggregated with other information before it can be
		used. As a result, computations are increasingly spatially
		decoupled and moved away from the controlled objects, thus inducing
		additional latency. Instead, moving compute functionality onto COIN
		execution environments inside the network offers a new solution
		space to these challenges, providing new compute locations with much
		smaller latencies.</t>
		</section>

		<section anchor="characterization-3">
		<name>Characterization</name>
		<t>A control process consists of two main components as illustrated
		in <xref target="processControl"/>: a system under control and a
		controller. In feedback control, the current state of the system is
		monitored (e.g., using sensors), and the controller influences the
		system based on the difference between the current and the reference
		state to keep it close to this reference state.</t>

		<figure anchor="processControl">
		<name>Simple Feedback Control Model</name>
		<artwork><![CDATA[
	reference	reference
	state ------------ -------- Output	state ------------ -------- Output
	----------> \| Controller \| ---> \| System \| ---------->	----------> \| Controller \| ---> \| System \| ---------->
	^ ------------ -------- \|	^ ------------ -------- \|
	\| \|	\| \|
	\| observed state \|	\| observed state \|
	\| --------- \|	\| --------- \|
	-------------------\| Sensors \| <-----	-------------------\| Sensors \| <-----
	---------	---------

	]]></artwork></figure>	]]></artwork>
		</figure>
	<t>Apart from the control model, the quality of the control primarily depends on	<t>Apart from the control model, the quality of the control
	the timely reception of the sensor feedback which can be subject to tight laten	primarily depends on the timely reception of the sensor feedback,
	cy constraints, often in the single-digit millisecond range.	which can be subject to tight latency constraints, often in the
	Even shorter feedback requirements may exist in other use cases, such as interfe	single-digit millisecond range. Even shorter feedback requirements
	rometry or high-energy physics, but these use cases are out of scope for this do	may exist in other use cases, such as interferometry or high-energy
	cument.	physics, but these use cases are out of scope for this document.
	While low latencies are essential, there is an even greater need for stable and	While low latencies are essential, there is an even greater need for
	deterministic levels of latency, because controllers can generally cope with dif	stable and deterministic levels of latency, because controllers can
	ferent levels of latency, if they are designed for them, but they are significan	generally cope with different levels of latency if they are
	tly challenged by dynamically changing or unstable latencies.	designed for them, but they are significantly challenged by
	The unpredictable latency of the Internet exemplifies this problem if, e.g., off	dynamically changing or unstable latencies. The unpredictable
	-premise cloud platforms are included.</t>	latency of the Internet exemplifies this problem if, for example,
		off-premise cloud platforms are included.</t>
	</section>	</section>
	<section anchor="existing-solutions-3"><name>Existing Solutions</name>	<section anchor="existing-solutions-3">
		<name>Existing Solutions</name>
	<t>Control functionality is traditionally executed on PLCs close to the machiner	<t>Control functionality is traditionally executed on PLCs close to
	y.	the machinery. These PLCs typically require vendor-specific
	These PLCs typically require vendor-specific implementations and are often hard	implementations and are often hard to upgrade and update, which makes
	to upgrade and update which makes such control processes inflexible and difficul	such control processes inflexible and difficult to manage. Moving
	t to manage.	computations to more freely programmable devices thus has the
	Moving computations to more freely programmable devices thus has the potential o	potential of significantly improving the flexibility. In this
	f significantly improving the flexibility.	context, directly moving control functionality to (central) cloud
	In this context, directly moving control functionality to (central) cloud enviro	environments is generally possible, yet only feasible if latency
	nments is generally possible, yet only feasible if latency constraints are lenie	constraints are lenient.</t>
	nt.</t>	<t>Early approaches such as <xref target="RÜTH"/> and <xref
		target="VESTIN"/> have already shown the general applicability of
	<t>Early approaches such as <xref target="RUETH"/> and <xref target="VESTIN"/> h	leveraging COIN for in-network control.</t>
	ave already shown the general applicability of leveraging COIN for in-network co	</section>
	ntrol.</t>	<section anchor="opportunities-3">
		<name>Opportunities</name>
	</section>	<ul spacing="normal">
	<section anchor="opportunities-3"><name>Opportunities</name>	<li>
		<t>Performing simple control logic on PNDs and/or in COIN
	<t><list style="symbols">	execution environments can bring the controlled system and the
	<t>Performing simple control logic on PNDs and/or in COIN execution environmen	controller closer together, possibly satisfying the tight
	ts can bring the controlled system and the controller closer together, possibly	latency requirements.</t>
	satisfying the tight latency requirements.</t>	</li>
	<t>Creating a coupled control that is exercised via (i) simplified approximati	<li>
	ons of more complex control algorithms deployed in COIN execution environments,	<t>Creating a coupled control that is exercised via</t>
	and (ii) more complex overall control schemes deployed in the cloud can allow fo	<ol type="i">
	r quicker, yet more inaccurate responses from within the network while still pro	<li>
	viding for sufficient control accuracy at higher latencies from afar.</t>	<t>simplified approximations of more complex control
	</list></t>	algorithms deployed in COIN execution environments, and</t>
		</li>
	</section>	<li>
	<section anchor="research-questions-2"><name>Research Questions</name>	<t>more complex overall control schemes deployed in the cloud</
		t>
	<t><list style="symbols">	</li>
	<t>RQ 4.1.1: How to derive simplified versions of the global (control) functio	</ol>
	n?</t>	<t>can allow for quicker, yet more inaccurate responses from
	<t>RQ 4.1.2: How to account for the limited computational precision of PNDs th	within the network while still providing for sufficient control
	at typically only allow for integer precision computation for enabling high proc	accuracy at higher latencies from afar.</t>
	essing rates while floating-point precision is needed by most control algorithms	</li>
	(cf. <xref target="KUNZE-APPLICABILITY"/>)?</t>	</ul>
	<t>RQ 4.1.3: How to find suitable tradeoffs regarding simplicity of the contro	</section>
	l function ("accuracy of the control") and implementation complexity ("implement	<section anchor="research-questions-2">
	ability")?</t>	<name>Research Questions</name>
	<t>RQ 4.1.4: How to (dynamically) distribute simplified versions of the global	<ul spacing="normal">
	(control) function among COIN execution environments?</t>	<li>
	<t>RQ 4.1.5: How to (dynamically) (re-)compose the distributed control functio	<t>RQ 4.1.1: How to derive simplified versions of the global
	ns?</t>	(control) function?</t>
	<t>RQ 4.1.6: Can there be different control levels, e.g., "quite inaccurate &a	</li>
	mp; very low latency" (PNDs, deep in the network), "more accurate & higher l	<li>
	atency" (more powerful COIN execution environments, farer away), "very accurate	<t>RQ 4.1.2: How to account for the limited computational
	& very high latency" (cloud environments, far away)?</t>	precision of PNDs that typically only allow for integer
	<t>RQ 4.1.7: Who decides which control instance is executed and which informat	precision computation for enabling high processing rates, while
	ion can be used for this decision?</t>	floating-point precision is needed by most control algorithms
	<t>RQ 4.1.8: How do the different control instances interact and how can we de	(cf. <xref target="KUNZE-APPLICABILITY"/>)?</t>
	fine their hierarchy?</t>	</li>
	</list></t>	<li>
		<t>RQ 4.1.3: How to find suitable tradeoffs regarding simplicity
	</section>	of the control function ("accuracy of the control") and
	<section anchor="additional-desirable-capabilities-2"><name>Additional Desirable	implementation complexity ("implementability")?</t>
	Capabilities</name>	</li>
		<li>
	<t>In addition to the capabilities driven by the research questions above, there	<t>RQ 4.1.4: How to (dynamically) distribute simplified versions
	are a number of other features that approaches deploying control functionality	of the global (control) function among COIN execution
	in COIN execution environments could benefit from.	environments?</t>
	For example, having an explicit interaction between the COIN execution environme	</li>
	nts and the global controller would ensure that it is always clear which entity	<li>
	is emitting which signals.	<t>RQ 4.1.5: How to (dynamically) compose or recompose the distrib
	In this context, it is also important that actions of COIN execution environment	uted
	s are overridable by the global controller such that the global controller has t	control functions?</t>
	he final say in the process behavior.	</li>
	Finally, accommodating the general characteristics of control approaches, functi
	ons in COIN execution environments should ideally expose reliable information on
	the predicted delay and must expose reliable information on the predicted accur
	acy to the global control such that these aspects can be accommodated in the ove
	rall control.</t>

	</section>
	</section>
	<section anchor="filtering"><name>Large Volume Applications</name>

	<section anchor="FilteringDesc"><name>Description</name>

	<t>In modern industrial networks, processes and machines are extensively monitor
	ed by distributed sensors with a large spectrum of capabilities, ranging from si
	mple binary (e.g., light barriers) to sophisticated sensors with varying degrees
	of resolution.
	Sensors further serve different purposes, as some are used for time-critical pro
	cess control while others represent redundant fallback platforms.
	Overall, there is a high level of heterogeneity which makes managing the sensor
	output a challenging task.</t>

	<t>Depending on the deployed sensors and the complexity of the observed system,
	the resulting overall data volume can easily be in the range of several Gbit/s <
	xref target="GLEBKE"/>.
	These volumes are often already difficult to handle in local environments and it
	becomes even more challenging when off-premise clouds are used for managing the
	data.
	While large networking companies can simply upgrade their infrastructure to acco
	mmodate the accruing data volumes, most industrial companies operate on tight in
	frastructure budgets such that frequently upgrading is not always feasible or po
	ssible.
	Hence, a major challenge is to devise a methodology that is able to handle such
	amounts of data efficiently and flexibily without relying on recurring infrastru
	cture upgrades.</t>

	<t>Data filtering and preprocessing, similar to the considerations in <xref targ
	et="XR"/>, can be building blocks for new solutions in this space.
	Such solutions, however, might also have to address the added challenge of busin
	ess data leaving the premises and control of the company.
	As this data could include sensitive information or valuable business secrets, a
	dditional security measures have to be taken.
	Yet, typical security measures such as encrypting the data make filtering or pre
	processing approaches hardly applicable as they typically work on unencrypted da
	ta.
	Consequently, incorporating security into these approaches, either by adding fun
	ctionality for handling encrypted data or devising general security measures, is
	an additional auspicious field for research.</t>

	</section>
	<section anchor="FilteringChar"><name>Characterization</name>

	<t>In essence, the described monitoring systems consist of sensors that produce
	large volumes of monitoring data.
	This data is then transmitted to additional components that provide data process
	ing and analysis capabilities or simply store the data in large data silos.</t>

	<t>As sensors are often set up redundantly, parts of the collected data might al
	so be redundant.
	Moreover, sensors are often hard to configure or not configurable at all which i
	s why their resolution or sampling frequency is often larger than required.
	Consequently, it is likely that more data is transmitted than is needed or desir
	ed, prompting the deployment of filtering techniques.
	For example, COIN programs deployed in the on-premise network could filter out r
	edundant or undesired data before it leaves the premise using simple traffic fil
	ters, thus reducing the required (upload) bandwidths.
	The available sensor data could be scaled down using standard statistical sampli
	ng, packet-based sub-sampling, i.e., only forwarding every n-th packet, or using
	filtering as long as the sensor value is in an uninteresting range while forwar
	ding with a higher resolution once the sensor value range becomes interesting (c
	f. <xref target="KUNZE-SIGNAL"/>).
	While the former variants are oblivious to the semantics of the sensor data, the
	latter variant requires an understanding of the current sensor levels.
	In any case, it is important that end-hosts are informed about the filtering so
	that they can distinguish between data loss and data filtered out on purpose.</t
	>

	<t>In practice, the collected data is further processed using various forms of c
	omputation.
	Some of them are very complex or need the complete sensor data during the comput
	ation, but there are also simpler operations which can already be done on subset
	s of the overall dataset or earlier on the communication path as soon as all dat
	a is available.
	One example is finding the maximum of all sensor values which can either be done
	iteratively at each intermediate hop or at the first hop, where all data is ava
	ilable.
	Using expert knowledge about the exact computation steps and the concrete transm
	ission path of the sensor data, simple computation steps can thus be deployed in
	the on-premise network, again reducing the overall data volume.</t>

	</section>
	<section anchor="FilteringSol"><name>Existing Solutions</name>

	<t>Current approaches for handling such large amounts of information typically b
	uild upon stream processing frameworks such as Apache Flink.
	These solutions allow for handling large volume applications and map the compute
	functionality to performant server machines or distributed compute platforms.
	Augmenting the existing capabilities, COIN offers a new dimension of platforms f
	or such processing frameworks.</t>

	</section>
	<section anchor="FilteringOppo"><name>Opportunities</name>

	<t><list style="symbols">
	<t>(Stream) processing frameworks can become more flexible by introducing COIN
	execution environments as additional deployment targets.</t>
	<t>(Semantic) packet filtering based on packet header and payload, as well as
	multi-packet information can (drastically) reduce the data volume, possibly even
	without losing any important information.</t>
	<t>(Semantic) data (pre-)processing, e.g., in the form of computations across
	multiple packets and potentially leveraging packet payload, can also reduce the
	data volume without losing any important information.</t>
	</list></t>

	</section>
	<section anchor="FilteringRQ"><name>Research Questions</name>

	<t>Some of the following research questions are also relevant in the context of
	general stream processing systems.</t>

	<t><list style="symbols">
	<t>RQ 4.2.1: How can the overall data processing pipeline be divided into indi
	vidual processing steps that could then be deployed as COIN functionality?</t>
	<t>RQ 4.2.2: How to design COIN programs for (semantic) packet filtering and w
	hich filtering criteria make sense?</t>
	<t>RQ 4.2.3: Which kinds of COIN programs can be leveraged for (pre-)processin
	g steps and what complexity can they have?</t>
	<t>RQ 4.2.4: How to distribute and coordinate COIN programs?</t>
	<t>RQ 4.2.5: How to dynamically reconfigure and recompose COIN programs?</t>
	<t>RQ 4.2.6: How to incorporate the (pre-)processing and filtering steps into
	the overall system?</t>
	<t>RQ 4.2.7: How can changes to the data by COIN programs be signaled to the e
	nd-hosts?</t>
	</list></t>

	</section>
	<section anchor="FilteringReq"><name>Additional Desirable Capabilities</name>

	<t>In addition to the capabilities driven by the research questions above, there
	are a number of other features that such large volume applications could benefi
	t from.
	In particular, conforming to standard application-level syntax and semantics lik
	ely simplifies embedding filters and preprocessors into the overall system.
	If these filters and preprocessors also leverage packet header and payload infor
	mation for their operation, this could further improve the performance of any ap
	proach developed based on the above research questions.</t>

	</section>
	</section>
	<section anchor="safety"><name>Industrial Safety</name>

	<section anchor="description-4"><name>Description</name>

	<t>Despite an increasing automation in production processes, human workers are s
	till often necessary.
	Consequently, safety measures have a high priority to ensure that no human life
	is endangered.
	In traditional factories, the regions of contact between humans and machines are
	well-defined and interactions are simple.
	Simple safety measures like emergency switches at the working positions are enou
	gh to provide a good level of safety.</t>

	<t>Modern factories are characterized by increasingly dynamic and complex enviro
	nments with new interaction scenarios between humans and robots.
	Robots can directly assist humans, perform tasks autonomously, or even freely mo
	ve around on the shopfloor.
	Hence, the intersect between the human working area and the robots grows and it
	is harder for human workers to fully observe the complete environment.
	Additional safety measures are essential to prevent accidents and support humans
	in observing the environment.</t>

	</section>
	<section anchor="characterization-4"><name>Characterization</name>

	<t>Industrial safety measures are typically hardware solutions because they have
	to pass rigorous testing before they are certified and deployment-ready.
	Standard measures include safety switches and light barriers.
	Additionally, the working area can be explicitly divided into 'contact' and 'saf
	e' areas, indicating when workers have to watch out for interactions with machin
	ery.
	For example, markings on the factory floor can show the areas where robots move
	or indicate their maximum physical reach.</t>

	<t>These measures are static solutions, potentially relying on specialized hardw
	are, and are challenged by the increased dynamics of modern factories where the
	factory configuration can be changed on demand or where all entities are freely
	moving around.
	Software solutions offer higher flexibility as they can dynamically respect new
	information gathered by the sensor systems, but in most cases they cannot give g
	uaranteed safety.
	COIN systems could leverage the increased availability of sensor data and the de
	tailed monitoring of the factories to enable additional safety measures with sho
	rter response times and higher guarantees.
	Different safety indicators within the production hall could be combined within
	the network so that PNDs can give early responses if a potential safety breach i
	s detected.
	For example, the positions of human workers and robots could be tracked and robo
	ts could be stopped when they get too close to a human in a non-working area or
	if a human enters a defined safety zone.
	More advanced concepts could also include image data or combine arbitrary sensor
	data.
	Finally, the increasing softwarization of industrial processes can also lead to
	new problems, e.g., if software bugs cause unintended movements of robots.
	Here, COIN systems could independently double check issued commands to void unsa
	fe commands.</t>

	</section>
	<section anchor="existing-solutions-4"><name>Existing Solutions</name>

	<t>Due to the importance of safety, there is a wide range of software-based appr
	oaches aiming at enhancing security.
	One example are tag-based systems, e.g., using RFID, where drivers of forklifts
	can be warned if pedestrian workers carrying tags are nearby.
	Such solutions, however, require setting up an additional system and do not leve
	rage existing sensor data.</t>

	</section>
	<section anchor="opportunities-4"><name>Opportunities</name>

	<t><list style="symbols">
	<t>Executing safety-critical COIN functions on PNDs could allow for early emer
	gency reactions based on diverse sensor feedback with low latencies.</t>
	<t>COIN software could provide independent on-path surveillance of control sof
	tware-initiated actions to block unsafe commands.</t>
	</list></t>

	</section>
	<section anchor="research-questions-3"><name>Research Questions</name>

	<t><list style="symbols">
	<t>RQ 4.3.1: Which additional safety measures can be provided and do they actu
	ally improve safety?</t>
	<t>RQ 4.3.2: Which sensor information can be combined and how?</t>
	<t>RQ 4.3.3: How can COIN-based safety measures be integrated with existing sa
	fety measures without degrading safety?</t>
	<t>RQ 4.3.4: How can COIN software validate control software-initated commands
	to prevent unsafe operations?</t>
	</list></t>

	</section>
	</section>
	</section>
	<section anchor="existingCapabilities"><name>Improving existing COIN capabilitie
	s</name>

	<section anchor="CDNs"><name>Content Delivery Networks</name>

	<section anchor="description-5"><name>Description</name>

	<t>Delivery of content to end users often relies on Content Delivery Networks (C
	DNs).
	CDNs store said content closer to end users for latency-reduced delivery as well
	as to reduce load on origin servers.
	For this, they often utilize DNS-based indirection to serve the request on behal
	f of the origin server.
	Both of these objectives are within scope to be addressed by COIN methods and so
	lutions.</t>

	</section>
	<section anchor="characterization-5"><name>Characterization</name>

	<t>From the perspective of this draft, a CDN can be interpreted as a (network se
	rvice level) set of (COIN) programs.
	These programs implement a distributed logic for first distributing content from
	the origin server to the CDN ingress and then further to the CDN replication po
	ints which ultimately serve the user-facing content requests.</t>

	</section>
	<section anchor="existing-solutions-5"><name>Existing Solutions</name>

	<t>CDN technologies have been well described and deployed in the existing Intern
	et.
	Core technologies like Global Server Load Balancing (GSLB) <xref target="GSLB"/>
	and Anycast server solutions are used to deal with the required indirection of
	a content request (usually in the form of an HTTP request) to the most suitable
	local CDN server.
	Content is replicated from seeding servers, which serve as injection points for
	content from content owners/producers, to the actual CDN servers, who will event
	ually serve the user's request.
	The replication architecture and mechanisms itself differs from one (CDN) provid
	er to another, and often utilizes private peering or network arrangements in ord
	er to distribute the content internationally and regionally.</t>

	<t>Studies such as those in <xref target="FCDN"/> have shown that content distri
	bution at the level of named content, utilizing efficient (e.g., Layer 2) multic
	ast for replication towards edge CDN nodes, can significantly increase the overa
	ll network and server efficiency.
	It also reduces indirection latency for content retrieval as well as required ed
	ge storage capacity by benefiting from the increased network efficiency to renew
	edge content more quickly against changing demand.
	Works such as those in <xref target="SILKROAD"/> utilize ASICs to replace server
	-based load balancing with significant cost reductions, thus showcasing the pote
	ntial for in-network CN operations.</t>

	</section>
	<section anchor="opportunities-5"><name>Opportunities</name>

	<t><list style="symbols">
	<t>Supporting service-level routing of requests (service routing in <xref targ
	et="APPCENTRES"/>) to specific (COIN) program instances may improve on end user
	experience in faster retrieving (possibly also more, e.g., better quality) conte
	nt.</t>
	<t>COIN instances may also be utilized to integrate service-related telemetry
	information to support the selection of the final service instance destination f
	rom a pool of possible choices</t>
	<t>Supporting the selection of a service destination from a set of possible (e
	.g., virtualized, distributed) choices, e.g., through constraint-based routing d
	ecisions (see <xref target="APPCENTRES"/>) in (COIN) program instances to improv
	e the overall end user experience by selecting a 'more suitable' service destina
	tion over another, e.g., avoiding/reducing overload situations in specific servi
	ce destinations.</t>
	<t>Supporting Layer 2 capabilities for multicast (compute interconnection and
	collective communication in <xref target="APPCENTRES"/>), e.g., through in-netwo
	rk/switch-based replication decisions (and their optimizations) based on dynamic
	group membership information, may reduce the network utilization and therefore
	increase the overall system efficiency.</t>
	</list></t>


	</section>	<!-- [rfced] For clarity, may we adjust this list as follows?
	<section anchor="research-questions-4"><name>Research Questions</name>
	<t>In addition to the research questions in <xref target="mobileOffloadRQ"/>:</t
	>


	<t><list style="symbols">	Original:
	<t>RQ 5.1.1: How to utilize L2 multicast to improve on CDN designs? How to uti	* RQ 4.1.6: Can there be different control levels, e.g., "quite
	lize COIN capabilities in those designs, such as through on-path optimizations f	inaccurate & very low latency" (PNDs, deep in the network), "more
	or fanouts?</t>	accurate & higher latency" (more powerful COIN execution
	<t>RQ 5.1.2: What forwarding methods may support the required multicast capabi	environments, farer away), "very accurate & very high latency"
	lities (see <xref target="FCDN"/>) and how could programmable COIN forwarding el	(cloud environments, far away)?
	ements support those methods (e.g., extending current SDN capabilities)?</t>
	<t>RQ 5.1.3: What are the constraints, reflecting both compute and network cap
	abilities, that may support joint optimization of routing and computing? How cou
	ld intermediary (COIN) program instances support, e.g., the aggregation of those
	constraints to reduce overall telemetry network traffic?</t>
	<t>RQ 5.1.4: Could traffic steering be performed on the data path and per serv
	ice request, e.g., through (COIN) program instances that perform novel routing r
	equest lookup methods? If so, what would be performance improvements?</t>
	<t>RQ 5.1.5: How could storage be traded off against frequent, multicast-based
	replication (see <xref target="FCDN"/>)? Could intermediary/in-network (COIN) e
	lements support the storage beyond current endpoint-based methods?</t>
	<t>RQ 5.1.6: What scalability limits exist for L2 multicast capabilities? How
	to overcome them, e.g., through (COIN) program instances serving as stateful sub
	tree aggregators to reduce the needed identifier space for, e.g., bit-based forw
	arding?</t>
	</list></t>


	</section>	Option A (without parentheses):
	</section>	* RQ 4.1.6: Can there be different control levels? For example,
	<section anchor="CFaaS"><name>Compute-Fabric-as-a-Service (CFaaS)</name>	"quite inaccurate & very low latency" for PNDs deep in the network;
		"more accurate & higher latency" for more powerful COIN execution
		environments that are farther away; and "very accurate & very high
		latency" for cloud environments that are far away.


	<section anchor="description-6"><name>Description</name>	Option B (using a sublist):
		* RQ 4.1.6: Can there be different control levels? For example:


	<t>We interpret connected compute resources as operating at a suitable layer, su	- "quite inaccurate & very low latency" for PNDs deep in the
	ch as Ethernet, InfiBand but also at Layer 3, to allow for the exchange of suita	network;
	ble invocation methods, such as exposed through verb-based or socket-based APIs.	- "more accurate & higher latency" for more powerful COIN execution
	The specific invocations here are subject to the applications running over a sel	environments that are farther away; and
	ected pool of such connected compute resources.</t>	- "very accurate & very high latency" for cloud environments that
		are far away.
		-->


	<t>Providing such pool of connected compute resources, e.g., in regional or edge	<li>
	data centers, base stations, and even end user devices, opens up the opportunit	<t>RQ 4.1.6: Can there be different control levels, e.g., "quite
	y for infrastructure providers to offer CFaaS-like offerings to application prov	inaccurate & very low latency" (PNDs, deep in the network),
	iders, leaving the choice of the appropriate invocation method to the app and se	"more accurate & higher latency" (more powerful COIN
	rvice provider.	execution environments, farther away), "very accurate & very
	Through this, the compute resources can be utilized to execute the desired (COIN	high latency" (cloud environments, far away)?</t> </li> <li>
	) programs of which the application is composed, while utilizing the interconnec	<t>RQ 4.1.7: Who decides which control instance is executed and
	tion between those compute resources to do so in a distributed manner.</t>	which information can be used for this decision?</t>
		</li>
		<li>
		<t>RQ 4.1.8: How do the different control instances interact and
		how can we define their hierarchy?</t>
		</li>
		</ul>
		</section>
		<section anchor="additional-desirable-capabilities-2">
		<name>Additional Desirable Capabilities</name>
		<t>In addition to the capabilities driven by the research questions
		above, there are a number of other features that approaches
		deploying control functionality in COIN execution environments could
		benefit from. For example, having an explicit interaction between
		the COIN execution environments and the global controller would
		ensure that it is always clear which entity is emitting which
		signals. In this context, it is also important that actions of COIN
		execution environments are overridable by the global controller such
		that the global controller has the final say in the process
		behavior. Finally, by accommodating the general characteristics of
		control approaches, functions in COIN execution environments should
		ideally expose reliable information on the predicted delay and must
		expose reliable information on the predicted accuracy to the global
		control such that these aspects can be accommodated in the overall
		control.</t>
		</section>
		</section>
		<section anchor="filtering">
		<name>Large-Volume Applications</name>
		<section anchor="FilteringDesc">
		<name>Description</name>
		<t>In modern industrial networks, processes and machines are
		extensively monitored by distributed sensors with a large spectrum
		of capabilities, ranging from simple binary (e.g., light barriers)
		to sophisticated sensors with varying degrees of resolution.
		Sensors further serve different purposes, as some are used for
		time-critical process control, while others represent redundant
		fallback platforms. Overall, there is a high level of heterogeneity,
		which makes managing the sensor output a challenging task.</t>
		<t>Depending on the deployed sensors and the complexity of the
		observed system, the resulting overall data volume can easily be in
		the range of several Gbit/s <xref target="GLEBKE"/>. These volumes
		are often already difficult to handle in local environments, and it
		becomes even more challenging when off-premise clouds are used for
		managing the data. While large networking companies can simply
		upgrade their infrastructure to accommodate the accruing data
		volumes, most industrial companies operate on tight infrastructure
		budgets such that frequently upgrading is not always feasible or
		possible. Hence, a major challenge is to devise a methodology that
		is able to handle such amounts of data efficiently and flexibly
		without relying on recurring infrastructure upgrades.</t>
		<t>Data filtering and preprocessing, similar to the considerations
		in <xref target="XR"/>, can be building blocks for new solutions in
		this space. Such solutions, however, might also have to address the
		added challenge of business data leaving the premises and control of
		the company. As this data could include sensitive information or
		valuable business secrets, additional security measures have to be
		taken. Yet, typical security measures such as encrypting the data
		make filtering or preprocessing approaches hardly applicable as they
		typically work on unencrypted data. Consequently, incorporating
		security into these approaches, either by adding functionality for
		handling encrypted data or devising general security measures, is an
		additional auspicious field for research.</t>
		</section>
		<section anchor="FilteringChar">
		<name>Characterization</name>
		<t>In essence, the described monitoring systems consist of sensors
		that produce large volumes of monitoring data. This data is then
		transmitted to additional components that provide data processing
		and analysis capabilities or simply store the data in large data
		silos.</t>
		<t>As sensors are often set up redundantly, parts of the collected
		data might also be redundant. Moreover, sensors are often hard to
		configure or not configurable at all, which is why their resolution
		or sampling frequency is often larger than required. Consequently,
		it is likely that more data is transmitted than is needed or
		desired, prompting the deployment of filtering techniques. For
		example, COIN programs deployed in the on-premise network could
		filter out redundant or undesired data before it leaves the premise
		using simple traffic filters, thus reducing the required (upload)
		bandwidths. The available sensor data could be scaled down using
		standard statistical sampling, packet-based sub-sampling (i.e., only
		forwarding every n-th packet), or using filtering as long as the
		sensor value is in an uninteresting range while forwarding with a
		higher resolution once the sensor value range becomes interesting
		(cf. <xref target="KUNZE-SIGNAL"/>). While the former variants are
		oblivious to the semantics of the sensor data, the latter variant
		requires an understanding of the current sensor levels. In any
		case, it is important that end hosts are informed about the
		filtering so that they can distinguish between data loss and data
		filtered out on purpose.</t>
		<t>In practice, the collected data is further processed using
		various forms of computation. Some of them are very complex or need
		the complete sensor data during the computation, but there are also
		simpler operations that can already be done on subsets of the
		overall dataset or earlier on the communication path as soon as all
		data is available. One example is finding the maximum of all sensor
		values, which can either be done iteratively at each intermediate hop
		or at the first hop where all data is available. Using expert
		knowledge about the exact computation steps and the concrete
		transmission path of the sensor data, simple computation steps can
		thus be deployed in the on-premise network, again reducing the
		overall data volume.</t>
		</section>
		<section anchor="FilteringSol">
		<name>Existing Solutions</name>
		<t>Current approaches for handling such large amounts of information
		typically build upon stream processing frameworks such as Apache
		Flink. These solutions allow for handling large-volume applications
		and map the compute functionality to performant server machines or
		distributed compute platforms. Augmenting the existing
		capabilities, COIN offers a new dimension of platforms for such
		processing frameworks.</t>
		</section>
		<section anchor="FilteringOppo">
		<name>Opportunities</name>
		<ul spacing="normal">
		<li>
		<t>(Stream) processing frameworks can become more flexible by
		introducing COIN execution environments as additional deployment
		targets.</t>
		</li>
		<li>
		<t>(Semantic) packet filtering based on packet header and
		payload, as well as multipacket information can (drastically)
		reduce the data volume, possibly even without losing any
		important information.</t>
		</li>
		<li>
		<t>(Semantic) data preprocessing and processing (e.g., in the form
		of
		computations across multiple packets and potentially leveraging
		packet payload) can also reduce the data volume without losing
		any important information.</t>
		</li>
		</ul>
		</section>
		<section anchor="FilteringRQ">
		<name>Research Questions</name>
		<t>Some of the following research questions are also relevant in the
		context of general stream processing systems.</t>
		<ul spacing="normal">
		<li>
		<t>RQ 4.2.1: How can the overall data processing pipeline be
		divided into individual processing steps that could then be
		deployed as COIN functionality?</t>
		</li>
		<li>
		<t>RQ 4.2.2: How to design COIN programs for (semantic) packet
		filtering and which filtering criteria make sense?</t>
		</li>
		<li>
		<t>RQ 4.2.3: Which kinds of COIN programs can be leveraged for
		(pre)processing steps and what complexity can they have?</t>
		</li>
		<li>
		<t>RQ 4.2.4: How to distribute and coordinate COIN programs?</t>
		</li>
		<li>
		<t>RQ 4.2.5: How to dynamically reconfigure and recompose COIN pro
		grams?</t>
		</li>
		<li>
		<t>RQ 4.2.6: How to incorporate the (pre)processing and
		filtering steps into the overall system?</t>
		</li>
		<li>
		<t>RQ 4.2.7: How can changes to the data by COIN programs be
		signaled to the end hosts?</t>
		</li>
		</ul>
		</section>
		<section anchor="FilteringReq">
		<name>Additional Desirable Capabilities</name>
		<t>In addition to the capabilities driven by the research questions
		above, there are a number of other features that such large-volume
		applications could benefit from. In particular, conforming to
		standard application-level syntax and semantics likely simplifies
		embedding filters and preprocessors into the overall system. If
		these filters and preprocessors also leverage packet header and
		payload information for their operation, this could further improve
		the performance of any approach developed based on the above
		research questions.</t>
		</section>
		</section>
		<section anchor="safety">
		<name>Industrial Safety</name>
		<section anchor="description-4">
		<name>Description</name>
		<t>Despite an increasing automation in production processes, human
		workers are still often necessary. Consequently, safety measures
		have a high priority to ensure that no human life is endangered. In
		traditional factories, the regions of contact between humans and
		machines are well defined and interactions are simple. Simple
		safety measures like emergency switches at the working positions are
		enough to provide a good level of safety.</t>
		<t>Modern factories are characterized by increasingly dynamic and
		complex environments with new interaction scenarios between humans
		and robots. Robots can directly assist humans, perform tasks
		autonomously, or even freely move around on the shop floor. Hence,
		the intersect between the human working area and the robots grows,
		and it is harder for human workers to fully observe the complete
		environment. Additional safety measures are essential to prevent
		accidents and support humans in observing the environment.</t>
		</section>
		<section anchor="characterization-4">
		<name>Characterization</name>
		<t>Industrial safety measures are typically hardware solutions
		because they have to pass rigorous testing before they are certified
		and deployment ready. Standard measures include safety switches and
		light barriers. Additionally, the working area can be explicitly
		divided into "contact" and "safe" areas, indicating when workers
		have to watch out for interactions with machinery. For example,
		markings on the factory floor can show the areas where robots move
		or indicate their maximum physical reach.</t>
		<t>These measures are static solutions, potentially relying on
		specialized hardware, and are challenged by the increased dynamics
		of modern factories where the factory configuration can be changed
		on demand or where all entities are freely moving around. Software
		solutions offer higher flexibility as they can dynamically respect
		new information gathered by the sensor systems, but in most cases
		they cannot give guaranteed safety. COIN systems could leverage the
		increased availability of sensor data and the detailed monitoring of
		the factories to enable additional safety measures with shorter
		response times and higher guarantees. Different safety indicators
		within the production hall could be combined within the network so
		that PNDs can give early responses if a potential safety breach is
		detected. For example, the positions of human workers and robots
		could be tracked, and robots could be stopped when they get too close
		to a human in a non-working area or if a human enters a defined
		safety zone. More advanced concepts could also include image data
		or combine arbitrary sensor data. Finally, the increasing
		softwarization of industrial processes can also lead to new
		problems, e.g., if software bugs cause unintended movements of
		robots. Here, COIN systems could independently double check issued
		commands to void unsafe commands.</t>
		</section>
		<section anchor="existing-solutions-4">
		<name>Existing Solutions</name>
		<t>Due to the importance of safety, there is a wide range of
		software-based approaches aiming at enhancing security. One example
		are tag-based systems (e.g., using RFID), where drivers of forklifts
		can be warned if pedestrian workers carrying tags are nearby. Such
		solutions, however, require setting up an additional system and do
		not leverage existing sensor data.</t>
		</section>
		<section anchor="opportunities-4">
		<name>Opportunities</name>
		<ul spacing="normal">
		<li>
		<t>Executing safety-critical COIN functions on PNDs could allow
		for early emergency reactions based on diverse sensor feedback
		with low latencies.</t>
		</li>
		<li>
		<t>COIN software could provide independent on-path surveillance
		of control software-initiated actions to block unsafe
		commands.</t>
		</li>
		</ul>
		</section>
		<section anchor="research-questions-3">
		<name>Research Questions</name>
		<ul spacing="normal">
		<li>
		<t>RQ 4.3.1: Which additional safety measures can be provided
		and do they actually improve safety?</t>
		</li>
		<li>
		<t>RQ 4.3.2: Which sensor information can be combined and
		how?</t>
		</li>
		<li>
		<t>RQ 4.3.3: How can COIN-based safety measures be integrated
		with existing safety measures without degrading safety?</t>
		</li>
		<li>
		<t>RQ 4.3.4: How can COIN software validate control
		software-initiated commands to prevent unsafe operations?</t>
		</li>
		</ul>
		</section>
		</section>
		</section>
		<section anchor="existingCapabilities">
		<name>Improving Existing COIN Capabilities</name>
		<section anchor="CDNs">
		<name>Content Delivery Networks</name>
		<section anchor="description-5">
		<name>Description</name>
		<t>Delivery of content to end users often relies on Content Delivery
		Networks (CDNs). CDNs store said content closer to end users for
		latency-reduced delivery as well as to reduce load on origin
		servers. For this, they often utilize DNS-based indirection to
		serve the request on behalf of the origin server. Both of these
		objectives are within scope to be addressed by COIN methods and
		solutions.</t>
		</section>
		<section anchor="characterization-5">
		<name>Characterization</name>
		<t>From the perspective of this draft, a CDN can be interpreted as a
		(network service level) set of (COIN) programs. These programs
		implement a distributed logic for first distributing content from
		the origin server to the CDN ingress and then further to the CDN
		replication points, which ultimately serve the user-facing content
		requests.</t>
		</section>
		<section anchor="existing-solutions-5">
		<name>Existing Solutions</name>
		<t>CDN technologies have been well described and deployed in the
		existing Internet. Core technologies like Global Server Load
		Balancing (GSLB) <xref target="GSLB"/> and Anycast server solutions
		are used to deal with the required indirection of a content request
		(usually in the form of an HTTP request) to the most suitable local
		CDN server. Content is replicated from seeding servers, which serve
		as injection points for content from content owners/producers, to
		the actual CDN servers, which will eventually serve the user's
		request. The replication architecture and mechanisms themselves diffe
		r
		from one (CDN) provider to another, and often utilize private
		peering or network arrangements in order to distribute the content
		internationally and regionally.</t>


	</section>	<t>Studies such as those in <xref target="FCDN"/> have shown that
	<section anchor="characterization-6"><name>Characterization</name>	content distribution at the level of named content, utilizing
		efficient (e.g., Layer 2 (L2)) multicast for replication towards edge
		CDN
		nodes, can significantly increase the overall network and server
		efficiency. It also reduces indirection latency for content
		retrieval as well as required edge storage capacity by benefiting
		from the increased network efficiency to renew edge content more
		quickly against changing demand. Works such as those in <xref
		target="SILKROAD"/> utilize Application-Specific Integrated Circuits (
		ASICs) to replace server-based load
		balancing with significant cost reductions, thus showcasing the
		potential for in-network CN operations.</t>
		</section>
		<section anchor="opportunities-5">
		<name>Opportunities</name>
		<ul spacing="normal">
		<li>
		<t>Supporting service-level routing of requests (such as service
		routing in <xref target="I-D.sarathchandra-coin-appcentres"/>)
		to specific (COIN) program instances may improve on end-user
		experience in retrieving faster (and possibly better
		quality) content.</t>
		</li>
		<li>
		<t>COIN instances may also be utilized to integrate
		service-related telemetry information to support the selection
		of the final service instance destination from a pool of
		possible choices.</t>
		</li>


	<t>We foresee those CFaaS offerings to be tenant-specific, a tenant here defined	<!-- [rfced] Section 5.1.4: To improve readability and avoid overuse
	as the provider of at least one application.	of "e.g.," and parentheses, how may these items be updated?
	For this, we foresee an interaction between CFaaS provider and tenant to dynamic
	ally select the appropriate resources to define the demand side of the fabric.
	Conversely, we also foresee the supply side of the fabric to be highly dynamic w
	ith resources being offered to the fabric through, e.g., user-provided resources
	(whose supply might depend on highly context-specific supply policies) or infra
	structure resources of intermittent availability such as those provided through
	road-side infrastructure in vehicular scenarios.</t>


	<t>The resulting dynamic demand-supply matching establishes a dynamic nature of	i) Does "(e.g., virtualized, distributed)" mean the set of choices
	the compute fabric that in turn requires trust relationships to be built dynamic	are virtualized and/or distributed?
	ally between the resource provider(s) and the CFaaS provider.
	This also requires the communication resources to be dynamically adjusted to sui
	tably interconnect all resources into the (tenant-specific) fabric exposed as CF
	aaS.</t>


	</section>	Original:
	<section anchor="existing-solutions-6"><name>Existing Solutions</name>	* Supporting the selection of a service destination from a set of
		possible (e.g., virtualized, distributed) choices, e.g., through
		constraint-based routing decisions (see [APPCENTRES]) in (COIN)
		program instances to improve the overall end user experience by
		selecting a 'more suitable' service destination over another,
		e.g., avoiding/reducing overload situations in specific service
		destinations.


	<t>There exist a number of technologies to build non-local (wide area) Layer 2 a	Option A:
	s well as Layer 3 networks, which in turn allows for connecting compute resource	* Supporting the selection of a service destination from a set of
	s for a distributed computational task.	possible choices (virtualized and distributed) in (COIN) program
	For instance, 5G-LAN <xref target="SA2-5GLAN"/> specifies a cellular L2 bearer f	instances (e.g., through constraint-based routing decisions as seen in
	or interconnecting L2 resources within a single cellular operator.	[APPCENTRES]) to improve the overall end-user experience by selecting a
	The work in <xref target="ICN5GLAN"/> outlines using a path-based forwarding sol	"more suitable" service destination over another (e.g.,
	ution over 5G-LAN as well as SDN-based LAN connectivity together with an ICN-bas	avoiding/reducing overload situations in specific service destinations).
	ed naming of IP and HTTP-level resources to achieve computational interconnectio
	ns, including scenarios such as those outlined in <xref target="mobileAppOffload
	"/>.
	L2 network virtualization (see, e.g., <xref target="L2Virt"/>) is one of the met
	hods used for realizing so-called 'cloud-native' applications for applications d
	eveloped with 'physical' networks in mind, thus forming an interconnected comput
	e and storage fabric.</t>


	</section>	Option B (moving the last two examples to one final sentence):
	<section anchor="opportunities-6"><name>Opportunities</name>	* Supporting the selection of a service destination from a set of
		possible choices (virtualized and distributed) in (COIN) program
		instances to improve the overall end-user experience by selecting a
		"more suitable" service destination over another. (For example,
		selecting through constraint-based routing decisions as seen in
		[APPCENTRES] may allow avoiding/reducing overload situations in
		specific service destinations.)


	<t><list style="symbols">	ii) Does "in-network/switch-based" mean "in-network and switch-based"?
	<t>Supporting service-level routing of compute resource requests (service rout
	ing in <xref target="APPCENTRES"/>) may allow for utilizing the wealth of comput
	e resources in the overall CFaaS fabric for execution of distributed application
	s, where the distributed constituents of those applications are realized as (COI
	N) programs and executed within a COIN system as (COIN) program instances.</t>
	<t>Supporting the constraint-based selection of a specific (COIN) program inst
	ance over others (constraint-based routing in <xref target="APPCENTRES"/>) will
	allow for optimizing both the CFaaS provider constraints as well as tenant-speci
	fic constraints.</t>
	<t>Supporting Layer 2 and 3 capabilities for multicast (compute interconnectio
	n and collective communication in <xref target="APPCENTRES"/>) will allow for de
	creasing both network utilization but also possible compute utilization (due to
	avoiding unicast replication at those compute endpoints), thereby decreasing tot
	al cost of ownership for the CFaaS offering.</t>
	<t>Supporting the enforcement of trust relationships and isolation policies th
	rough intermediary (COIN) program instances, e.g., enforcing specific traffic sh
	ares or strict isolation of traffic through differentiated queueing.</t>
	</list></t>


	</section>	Original:
	<section anchor="research-questions-5"><name>Research Questions</name>	* Supporting Layer 2 capabilities for multicast (compute
	<t>In addition to the research questions in <xref target="mobileOffloadRQ"/>:</t	interconnection and collective communication in [APPCENTRES]),
	>	e.g., through in-network/switch-based replication decisions (and
		their optimizations) based on dynamic group membership
		information, may reduce the network utilization and therefore
		increase the overall system efficiency.


	<t><list style="symbols">	Perhaps (moving the example to the end):
	<t>RQ 5.2.1: How to convey tenant-specific requirements for the creation of th	* Supporting L2 capabilities for multicast (compute interconnection
	e CFaaS fabric?</t>	and collective communication as seen in [APPCENTRES]) may
	<t>RQ 5.2.2: How to dynamically integrate resources into the compute fabric be	reduce the network utilization and therefore increase the overall
	ing utilized for the app execution (those resources include, but are not limited	system efficiency. For example, this support may be
	to, end user provided resources), particularly when driven by tenant-level requ	through in-network, switch-based replication decisions (and their
	irements and changing service-specific constraints? How can those resources be e	optimizations) based on dynamic group membership information.
	xposed through possible (COIN) execution environments?</t>	-->
	<t>RQ 5.2.3: How to utilize COIN capabilities to aid the availability and acco
	untability of resources, i.e., what may be (COIN) programs for a CFaaS environme
	nt that in turn would utilize the distributed execution capability of a COIN sys
	tem?</t>
	<t>RQ 5.2.4: How to utilize COIN capabilities to enforce traffic and isolation
	policies for establishing trust between tenant and CFaaS provider in an assured
	operation?</t>
	<t>RQ 5.2.5: How to optimize the interconnection of compute resources, includi
	ng those dynamically added and removed during the provisioning of the tenant-spe
	cific compute fabric?</t>
	</list></t>


	</section>	<li>
	</section>	<t>Supporting the selection of a service destination from a set
	<section anchor="virtNetProg"><name>Virtual Networks Programming</name>	of possible (e.g., virtualized, distributed) choices, e.g.,
		through constraint-based routing decisions (see <xref
		target="I-D.sarathchandra-coin-appcentres"/>) in (COIN) program
		instances to improve the overall end-user experience by
		selecting a "more suitable" service destination over another,
		e.g., avoiding/reducing overload situations in specific service
		destinations.</t>
		</li>
		<li>
		<t>Supporting L2 capabilities for multicast (compute
		interconnection and collective communication in <xref
		target="I-D.sarathchandra-coin-appcentres"/>), e.g., through
		in-network/switch-based replication decisions (and their
		optimizations) based on dynamic group membership information,
		may reduce the network utilization and therefore increase the
		overall system efficiency.</t>
		</li>
		</ul>
		</section>
		<section anchor="research-questions-4">
		<name>Research Questions</name>
		<t>In addition to the research questions in <xref target="mobileOffloa
		dRQ"/>:</t>
		<ul spacing="normal">
		<li>
		<t>RQ 5.1.1: How to utilize L2 multicast to improve on CDN
		designs? How to utilize COIN capabilities in those designs, such
		as through on-path optimizations for fanouts?</t>
		</li>
		<li>
		<t>RQ 5.1.2: What forwarding methods may support the required
		multicast capabilities (see <xref target="FCDN"/>) and how could
		programmable COIN forwarding elements support those methods
		(e.g., extending current SDN capabilities)?</t>
		</li>
		<li>
		<t>RQ 5.1.3: What are the constraints, reflecting both compute
		and network capabilities, that may support joint optimization of
		routing and computing? How could intermediary (COIN) program
		instances support, for example, the aggregation of those constrain
		ts to
		reduce overall telemetry network traffic?</t>
		</li>
		<li>
		<t>RQ 5.1.4: Could traffic steering be performed on the data
		path and per service request (e.g., through (COIN) program
		instances that perform novel routing request lookup methods)? If
		so, what would be performance improvements?</t>
		</li>
		<li>
		<t>RQ 5.1.5: How could storage be traded off against frequent,
		multicast-based replication (see <xref target="FCDN"/>)? Could
		intermediary/in-network (COIN) elements support the storage
		beyond current endpoint-based methods?</t>
		</li>
		<li>
		<t>RQ 5.1.6: What scalability limits exist for L2 multicast
		capabilities? How to overcome them, e.g., through (COIN) program
		instances serving as stateful subtree aggregators to reduce the
		needed identifier space (e.g., for bit-based forwarding)?</t>
		</li>
		</ul>
		</section>
		</section>
		<section anchor="CFaaS">
		<name>Compute-Fabric-as-a-Service (CFaaS)</name>
		<section anchor="description-6">
		<name>Description</name>


	<section anchor="description-7"><name>Description</name>	<!-- [rfced] FYI - We have added a subject for "such as exposed through" in
		the text below. Also, we assumed "InfiBand" was intended as "InfiniBand".
		Please review.


	<t>The term "virtual network programming" is proposed to describe mechanisms by	Original:
	which tenants deploy and operate COIN programs in their virtual network.	We interpret connected compute resources as operating at a suitable
	Such COIN programs can, e.g., be P4 programs, OpenFlow rules, or higher layer pr	layer, such as Ethernet, InfiBand but also at Layer 3, to allow for
	ograms.	the exchange of suitable invocation methods, such as exposed through
	This feature can enable other use cases described in this draft to be deployed u	verb-based or socket-based APIs.
	sing virtual networks services, over underlying networks such as datacenters, mo
	bile networks, or other fixed or wireless networks.</t>


	<t>For example, COIN programs could perform the following on a tenant's virtual	Current:
	network:</t>	We interpret connected compute resources as operating at a suitable
		layer, such as Ethernet, InfiniBand, but also at Layer 3 (L3), to allow
		for the exchange of suitable invocation methods, such as those
		exposed through verb-based or socket-based APIs.
		-->


	<t><list style="symbols">	<t>We interpret connected compute resources as operating at a
	<t>Allow or block flows, and request rules from an SDN controller for each new	suitable layer, such as Ethernet, InfiniBand, but also at Layer 3 (L3)
	flow, or for flows to or from specific hosts that need enhanced security</t>	, to
	<t>Forward a copy of some flows towards a node for storage and analysis</t>	allow for the exchange of suitable invocation methods, such as those
	<t>Update metrics based on specific sources/destinations or protocols, for det	exposed through verb-based or socket-based APIs. The specific
	ailed analytics</t>	invocations here are subject to the applications running over a
	<t>Associate traffic between specific endpoints, using specific protocols, or	selected pool of such connected compute resources.</t>
	originated from a given application, to a given slice, while other traffic uses	<t>Providing such a pool of connected compute resources (e.g., in
	a default slice</t>	regional or edge data centers, base stations, and even end-user
	<t>Experiment with a new routing protocol (e.g., ICN), using a P4 implementati	devices) opens up the opportunity for infrastructure providers to
	on of a router for this protocol</t>	offer CFaaS-like offerings to application providers, leaving the
	</list></t>	choice of the appropriate invocation method to the app and service
		provider. Through this, the compute resources can be utilized to
		execute the desired (COIN) programs of which the application is
		composed, while utilizing the interconnection between those compute
		resources to do so in a distributed manner.</t>
		</section>


	</section>	<section anchor="characterization-6">
	<section anchor="characterization-7"><name>Characterization</name>	<name>Characterization</name>
		<t>We foresee those CFaaS offerings to be tenant-specific, with a tena
		nt
		here defined as the provider of at least one application. For this,
		we foresee an interaction between the CFaaS provider and tenant to
		dynamically select the appropriate resources to define the demand
		side of the fabric. Conversely, we also foresee the supply side of
		the fabric to be highly dynamic, with resources being offered to the
		fabric through, for example, user-provided resources (whose supply mig
		ht
		depend on highly context-specific supply policies) or infrastructure
		resources of intermittent availability such as those provided
		through road-side infrastructure in vehicular scenarios.</t>
		<t>The resulting dynamic demand-supply matching establishes a
		dynamic nature of the compute fabric that in turn requires trust
		relationships to be built dynamically between the resource
		provider(s) and the CFaaS provider. This also requires the
		communication resources to be dynamically adjusted to suitably
		interconnect all resources into the (tenant-specific) fabric exposed
		as CFaaS.</t>
		</section>
		<section anchor="existing-solutions-6">
		<name>Existing Solutions</name>
		<t>There exist a number of technologies to build non-local (wide
		area) L2 as well as L3 networks, which in turn allows for connecting
		compute resources for a distributed computational task. For
		instance, 5G-LAN <xref target="SA2-5GLAN"/> specifies a cellular L2
		bearer for interconnecting L2 resources within a single cellular
		operator. The work in <xref
		target="I-D.trossen-icnrg-ip-icn-5glan"/> outlines using a
		path-based forwarding solution over 5G-LAN as well as SDN-based LAN
		connectivity together with an Information-Centric Network (ICN)
		based naming of IP and HTTP-level resources. This is done in order
		to achieve computational interconnections, including scenarios such
		as those outlined in <xref target="mobileAppOffload"/>. L2 network
		virtualization (see <xref target="L2Virt"/>) is one of the methods
		used for realizing so-called "cloud-native" applications for
		applications developed with "physical" networks in mind, thus
		forming an interconnected compute and storage fabric.</t>
		</section>
		<section anchor="opportunities-6">
		<name>Opportunities</name>
		<ul spacing="normal">
		<li>
		<t>Supporting service-level routing of compute resource requests
		(such as service routing in <xref
		target="I-D.sarathchandra-coin-appcentres"/>) may allow for
		utilizing the wealth of compute resources in the overall CFaaS
		fabric for execution of distributed applications, where the
		distributed constituents of those applications are realized as
		(COIN) programs and executed within a COIN system as (COIN)
		program instances.</t>
		</li>
		<li>
		<t>Supporting the constraint-based selection of a specific
		(COIN) program instance over others (such as constraint-based rout
		ing in
		<xref target="I-D.sarathchandra-coin-appcentres"/>) will allow
		for optimizing both the CFaaS provider constraints as well as
		tenant-specific constraints.</t>
		</li>
		<li>
		<t>Supporting L2 and L3 capabilities for multicast (such as comput
		e
		interconnection and collective communication in <xref
		target="I-D.sarathchandra-coin-appcentres"/>) will allow for
		decreasing both network utilization but also possible compute
		utilization (due to avoiding unicast replication at those
		compute endpoints), thereby decreasing total cost of ownership
		for the CFaaS offering.</t>
		</li>


	<t>To provide a concrete example of virtual COIN programming, we consider a use	<!-- [rfced] Section 5.2.4. Opportunities: How may we add a verb/outcome
	case using a 5G underlying network, the 5GLAN virtualization technology, and the	to the second part of this list item, in order to be consistent with the
	P4 programming language and environment.	rest of the items in this section?
	As an assumption in this use case, some mobile network equipment (e.g., UPF) and
	devices (e.g., mobile phones or residential gateways) include a network switch
	functionality that is used as a PND.</t>


	<t>Section 5.1 of <xref target="I-D.ravi-icnrg-5gc-icn"/> provides a description	Original:
	of the 5G network functions and interfaces relevant to 5GLAN, which are otherwi	* Supporting the enforcement of trust relationships and isolation
	se specified in <xref target="TS23.501"/> and <xref target="TS23.502"/>.	policies through intermediary (COIN) program instances, e.g.,
	From the 5GLAN service customer/tenant standpoint, the 5G network operates as a	enforcing specific traffic shares or strict isolation of traffic
	switch.</t>	through differentiated queueing.


	<t>In the use case depicted in <xref target="figureVN1"/>, the tenant operates a	Perhaps:
	network including a 5GLAN network segment (seen as a single logical switch), as	* Supporting the enforcement of trust relationships and isolation
	well as fixed segments.	policies through intermediary (COIN) program instances (e.g.,
	The mobile devices (or User Equipment nodes) UE1, UE2, UE3 and UE4 are in the sa	enforcing specific traffic shares or strict isolation of traffic
	me 5GLAN, as well as Device1 and Device2 (through UE4).	through differentiated queueing) will allow for [what?].
	This scenario can take place in a plant or enterprise network, using, e.g., a 5G	-->
	Non-Public Network.
	The tenant uses P4 programs to determine the operation of both the fixed and 5GL
	AN switches.
	The tenant provisions a 5GLAN P4 program into the mobile network, and can also o
	perate a controller.</t>


	<figure title="5G Virtual Network Programming Overview" anchor="figureVN1"><artw	<li>
	ork><![CDATA[	<t>Supporting the enforcement of trust relationships and
		isolation policies through intermediary (COIN) program
		instances, e.g., enforcing specific traffic shares or strict
		isolation of traffic through differentiated queueing.</t>
		</li>
		</ul>
		</section>
		<section anchor="research-questions-5">
		<name>Research Questions</name>
		<t>In addition to the research questions in <xref
		target="mobileOffloadRQ"/>:</t>
		<ul spacing="normal">
		<li>
		<t>RQ 5.2.1: How to convey tenant-specific requirements for the
		creation of the CFaaS fabric?</t>
		</li>
		<li>
		<t>RQ 5.2.2: How to dynamically integrate resources into the
		compute fabric being utilized for the app execution (those
		resources include, but are not limited to, end-user provided
		resources), particularly when driven by tenant-level
		requirements and changing service-specific constraints? How can
		those resources be exposed through possible (COIN) execution
		environments?</t>
		</li>
		<li>
		<t>RQ 5.2.3: How to utilize COIN capabilities to aid the
		availability and accountability of resources, i.e., what may be
		(COIN) programs for a CFaaS environment that in turn would
		utilize the distributed execution capability of a COIN
		system?</t>
		</li>
		<li>
		<t>RQ 5.2.4: How to utilize COIN capabilities to enforce traffic
		and isolation policies for establishing trust between tenant and
		CFaaS provider in an assured operation?</t>
		</li>
		<li>
		<t>RQ 5.2.5: How to optimize the interconnection of compute
		resources, including those dynamically added and removed during
		the provisioning of the tenant-specific compute fabric?</t>
		</li>
		</ul>
		</section>
		</section>
		<section anchor="virtNetProg">
		<name>Virtual Networks Programming</name>
		<section anchor="description-7">
		<name>Description</name>
		<t>The term "virtual network programming" is proposed to describe
		mechanisms by which tenants deploy and operate COIN programs in
		their virtual network. Such COIN programs can be, for example, P4
		programs, OpenFlow rules, or higher layer programs. This feature
		can enable other use cases described in this draft to be deployed
		using virtual network services, over underlying networks such as
		data centers, mobile networks, or other fixed or wireless
		networks.</t>
		<t>For example, COIN programs could perform the following on a
		tenant's virtual network:</t>
		<ul spacing="normal">
		<li>
		<t>Allow or block flows, and request rules from an SDN
		controller for each new flow, or for flows to or from specific
		hosts that need enhanced security.</t>
		</li>
		<li>
		<t>Forward a copy of some flows towards a node for storage and
		analysis.</t>
		</li>
		<li>
		<t>Update metrics based on specific sources/destinations or
		protocols, for detailed analytics.</t>
		</li>
		<li>
		<t>Associate traffic between specific endpoints, using specific
		protocols, or originated from a given application, to a given
		slice, while other traffic uses a default slice.</t>
		</li>
		<li>
		<t>Experiment with a new routing protocol (e.g., ICN), using a
		P4 implementation of a router for this protocol.</t>
		</li>
		</ul>
		</section>
		<section anchor="characterization-7">
		<name>Characterization</name>
		<t>To provide a concrete example of virtual COIN programming, we
		consider a use case using a 5G underlying network, the 5GLAN
		virtualization technology, and the P4 programming language and
		environment. As an assumption in this use case, some mobile network
		equipment (e.g., User Plane Functions (UPFs)) and devices (e.g.,
		mobile phones or residential gateways) include a network switch
		functionality that is used as a PND.</t>
		<t><xref target="I-D.ravi-icnrg-5gc-icn" sectionFormat="of"
		section="5.1"/> provides a description of the 5G network functions
		and interfaces relevant to 5GLAN, which are otherwise specified in
		<xref target="TS23.501"/> and <xref target="TS23.502"/>. From the
		5GLAN service customer/tenant standpoint, the 5G network operates as
		a switch.</t>
		<t>In the use case depicted in <xref target="figureVN1"/>, the
		tenant operates a network including a 5GLAN network segment (seen as
		a single logical switch), as well as fixed segments. The mobile
		devices (or User Equipment nodes) UE1, UE2, UE3, and UE4 are in
		the same 5GLAN, as well as Device1 and Device2 (through UE4). This
		scenario can take place in a plant or enterprise network, using a 5G
		non-public network, for example. The tenant uses P4 programs to
		determine the operation of both the fixed and 5GLAN switches. The
		tenant provisions a 5GLAN P4 program into the mobile network and
		can also operate a controller.</t>
		<figure anchor="figureVN1">
		<name>5G Virtual Network Programming Overview</name>
		<artwork><![CDATA[
	..... Tenant ........	..... Tenant ........
	P4 program : :	P4 program : :
	deployment : Operation :	deployment : Operation :
	V :	V :
	+-----+ air interface +----------------+ :	+-----+ air interface +----------------+ :
	\| UE1 +----------------+ \| :	\| UE1 +----------------+ \| :
	+-----+ \| \| :	+-----+ \| \| :
	\| \| :	\| \| :
	+-----+ \| \| V	+-----+ \| \| V
	\| UE2 +----------------+ 5GLAN \| +------------+	\| UE2 +----------------+ 5GLAN \| +------------+

	skipping to change at line 859 ¶	skipping to change at line 2206 ¶
	\| \|	\| \|
	\| Fixed or wireless connection \|	\| Fixed or wireless connection \|
	\| P4 runtime API \|	\| P4 runtime API \|
	\| +---------+ +-------------------------------+	\| +---------+ +-------------------------------+
	+--+ Device1 \| \|	+--+ Device1 \| \|
	\| +---------+ \|	\| +---------+ \|
	\| \|	\| \|
	\| +---------+ +------+-----+	\| +---------+ +------+-----+
	`--+ Device2 +----+ P4 Switch +--->(fixed network)	`--+ Device2 +----+ P4 Switch +--->(fixed network)
	+---------+ +------------+	+---------+ +------------+

	]]></artwork></figure>	]]></artwork>
		</figure>
	</section>	</section>
	<section anchor="existing-solutions-7"><name>Existing Solutions</name>	<section anchor="existing-solutions-7">
		<name>Existing Solutions</name>
	<t>Research has been conducted, for example by <xref target="Stoyanov"/>, to ena	<t>Research has been conducted, for example by <xref
	ble P4 network programming of individual virtual switches.	target="Stoyanov"/>, to enable P4 network programming of individual
	To our knowledge, no complete solution has been developed for deploying virtual	virtual switches. To our knowledge, no complete solution has been
	COIN programs over mobile or datacenter networks.</t>	developed for deploying virtual COIN programs over mobile or
		data center networks.</t>
	</section>	</section>
	<section anchor="opportunities-7"><name>Opportunities</name>	<section anchor="opportunities-7">
		<name>Opportunities</name>
	<t>Virtual network programming by tenants could bring benefits such as:</t>	<t>Virtual network programming by tenants could bring benefits such as
		:</t>
	<t><list style="symbols">	<ul spacing="normal">
	<t>A unified programming model, which can facilitate porting COIN programs bet
	ween data centers, 5G networks, and other fixed and wireless networks, as well a
	s sharing controller, code and expertise.</t>
	<t>Increasing the level of customization available to customers/tenants of mob
	ile networks or datacenters compared to typical configuration capabilities.
	For example, 5G network evolution points to an ever increasing specialization an
	d customization of private mobile networks, which could be handled by tenants us
	ing a programming model similar to P4.</t>
	<t>Using network programs to influence underlying network services, e.g., requ
	est specific QoS for some flows in 5G or datacenters, to increase the level of i
	n-depth customization available to tenants.</t>
	</list></t>

	</section>
	<section anchor="research-questions-6"><name>Research Questions</name>


	<t><list style="symbols">	<!-- [rfced] May "controller" be plural here in order to be parallel
	<t>RQ 5.3.1: Underlying Network Awareness: a virtual COIN program can be able	with the other plural list items?
	to influence, and be influenced by, the underling network. Research challenges i
	nclude defining methods to distribute COIN programs, including in a mobile netwo
	rk context, based on network awareness, since some information and actions may b
	e available on some nodes but not on others.</t>
	<t>RQ 5.3.2: Splitting/Distribution: a virtual COIN program may need to be dep
	loyed across multiple computing nodes, leading to research questions around inst
	ance placement and distribution. For example, program logic should be applied ex
	actly once or at least once per packet (or at least once for idempotent operatio
	ns), while allowing optimal forwarding path by the underlying network. Research
	challenges include defining manual (by the programmer) or automatic methods to d
	istribute COIN programs that use a low or minimal amount of resources. Distribut
	ed P4 programs are studied in <xref target="I-D.hsingh-coinrg-reqs-p4comp"/> and
	<xref target="Sultana"/> (based on capability 5.3.2).</t>
	<t>RQ 5.3.3: Multi-Tenancy Support: A COIN system supporting virtualization sh
	ould enable tenants to deploy COIN programs onto their virtual networks, in such
	a way that multiple virtual COIN program instances can run on the same compute
	node. While mechanisms were proposed for P4 multi-tenancy in a switch <xref targ
	et="Stoyanov"/>, research questions remain about isolation between tenants and f
	air repartition of resources (based on capability 5.3.3).</t>
	<t>RQ 5.3.4: Security: how can tenants and underlying networks be protected ag
	ainst security risks, including overuse or misuse of network resources, injectio
	n of traffic, or access to unauthorized traffic?</t>
	<t>RQ 5.3.5: Higher layer processing: can a virtual network model facilitate t
	he deployment of COIN programs acting on application layer data? This is an open
	question since the present section focused on packet/flow processing.</t>
	</list></t>


	</section>	Original:
	</section>	Virtual network programming by tenants could bring benefits such as:
	</section>
	<section anchor="newCapabilities"><name>Enabling new COIN capabilities</name>


	<section anchor="distributedAI"><name>Distributed AI Training</name>	* A unified programming model, which can facilitate porting COIN
		programs between data centers, 5G networks, and other fixed and
		wireless networks, as well as sharing controller, code and
		expertise.


	<section anchor="description-8"><name>Description</name>	Perhaps:
		Virtual network programming by tenants could bring benefits such as:


	<t>There is a growing range of use cases demanding the realization of AI trainin	* A unified programming model, which can facilitate porting COIN
	g capabilities among distributed endpoints.	programs between data centers, 5G networks, and other fixed and
	One such use case is to distribute large-scale model training across more than o	wireless networks, as well as sharing controllers, code, and
	ne data center, e.g., when facing energy issues at a single site or when simply	expertise.
	reaching the scale of training capabilities at one site, thus wanting to complem	-->
	ent training with capabilities of another, possibly many sites.
	From a COIN perspective, those capabilities may be realized as (COIN) programs a
	nd executed throughout a COIN system, including in PNDs.</t>


	</section>	<li>
	<section anchor="characterization-8"><name>Characterization</name>	<t>A unified programming model, which can facilitate porting
		COIN programs between data centers, 5G networks, and other fixed
		and wireless networks, as well as sharing controller, code and
		expertise.</t>
		</li>
		<li>
		<t>Increasing the level of customization available to
		customers/tenants of mobile networks or data centers compared to
		typical configuration capabilities. For example, 5G network
		evolution points to an ever-increasing specialization and
		customization of private mobile networks, which could be handled
		by tenants using a programming model similar to P4.</t>
		</li>
		<li>
		<t>Using network programs to influence underlying network
		services (e.g., requesting specific QoS for some flows in 5G or
		data centers) to increase the level of in-depth customization
		available to tenants.</t>
		</li>
		</ul>
		</section>
		<section anchor="research-questions-6">
		<name>Research Questions</name>
		<ul spacing="normal">
		<li>
		<t>RQ 5.3.1: Underlying network awareness</t>
		<t>A virtual COIN program can both influence, and be
		influenced by, the underling network. Research challenges
		include defining methods to distribute COIN programs, including
		in a mobile network context, based on network awareness, since
		some information and actions may be available on some nodes but
		not on others.</t>
		</li>
		<li>
		<t>RQ 5.3.2: Splitting/distribution</t>
		<t>A virtual COIN program may need to be deployed across
		multiple computing nodes, leading to research questions around
		instance placement and distribution. For example, program logic
		should be applied exactly once or at least once per packet (or
		at least once for idempotent operations), while allowing an optimal
		forwarding path by the underlying network. Research challenges
		include defining manual (by the programmer) or automatic methods
		to distribute COIN programs that use a low or minimal amount of
		resources. Distributed P4 programs are studied in <xref
		target="I-D.hsingh-coinrg-reqs-p4comp"/> and <xref
		target="Sultana"/> (based on capability 5.3.2).</t>
		</li>
		<li>
		<t>RQ 5.3.3: Multi-tenancy support</t>
		<t>A COIN system supporting virtualization should enable tenants
		to deploy COIN programs onto their virtual networks, in such a
		way that multiple virtual COIN program instances can run on the
		same compute node. While mechanisms were proposed for P4
		multi-tenancy in a switch <xref target="Stoyanov"/>, research
		questions remain about isolation between tenants and fair
		repartition of resources (based on capability 5.3.3).</t>
		</li>
		<li>
		<t>RQ 5.3.4: Security</t>
		<t>How can tenants and underlying networks
		be protected against security risks, including overuse or misuse
		of network resources, injection of traffic, or access to
		unauthorized traffic?</t>
		</li>
		<li>
		<t>RQ 5.3.5: Higher layer processing</t>
		<t>Can a virtual network model facilitate the deployment of COIN
		programs acting on application-layer data? This is an open
		question, since this section focuses on packet/flow
		processing.</t>
		</li>
		</ul>
		</section>
		</section>
		</section>


	<t>Some solutions may desire the localization of reasoning logic, e.g., for deri	<section anchor="newCapabilities">
	ving attributes that better preserve privacy of the utilized raw input data.	<name>Enabling New COIN Capabilities</name>
	Quickly establishing (COIN) program instances in nearby compute resources, inclu
	ding PNDs, may even satisfy such localization demands on-the-fly (e.g., when a p
	articular use is being realized, then terminated after a given time).</t>


	<t>Individual training 'sites' may not be a data center, but instead consist of	<section anchor="distributedAI">
	powerful, yet stand-along devices, that federate computing power towards trainin	<name>Distributed AI Training</name>
	g a model, captured as 'federated training' and provided through platforms such	<section anchor="description-8">
	as <xref target="FLOWER"/>.	<name>Description</name>
	Use cases here may be that of distributed training on (user) image data, the tra	<t>There is a growing range of use cases demanding the realization
	ining over federated social media sites <xref target="MASTODON"/>, or others.</t	of AI training capabilities among distributed endpoints. One such
	>	use case is to distribute large-scale model training across more
		than one data center (e.g., when facing energy issues at a single
		site or when simply reaching the scale of training capabilities at
		one site, thus wanting to complement training with the capabilities of
		another or possibly many sites). From a COIN perspective, those
		capabilities may be realized as (COIN) programs and executed
		throughout a COIN system, including in PNDs.</t>
		</section>


	<t>Apart from the distribution of compute power, the distribution of data may be	<section anchor="characterization-8">
	a driver for distributed AI training use cases, such as in the Mastodon federat	<name>Characterization</name>
	ed social media sits <xref target="MASTODON"/> or training over locally governed	<t>Some solutions may desire the localization of reasoning logic
	patient data or others.</t>	(e.g., for deriving attributes that better preserve privacy of the
		utilized raw input data). Quickly establishing (COIN) program
		instances in nearby compute resources, including PNDs, may even
		satisfy such localization demands on the fly (e.g., when a
		particular use is being realized, then terminated after a given
		time).</t>


	</section>	<t>Individual training "sites" may not be a data center, but may inste
	<section anchor="existing-solutions-8"><name>Existing Solutions</name>	ad
		consist of powerful, yet stand-along devices that federate
		computing power towards training a model, captured as "federated
		training" and provided through platforms such as <xref
		target="FLOWER"/>. Use cases here may be that of distributed
		training on (user) image data, the training over federated social
		media sites <xref target="MASTODON"/>, or others.</t>
		<t>Apart from the distribution of compute power, the distribution of
		data may be a driver for distributed AI training use cases, such as
		in the Mastodon federated social media sites <xref
		target="MASTODON"/> or training over locally governed patient data
		or others.</t>
		</section>


	<t>Reasoning frameworks, such as TensorFlow, may be utilized for the realization	<section anchor="existing-solutions-8">
	of the (distributed) AI training logic, building on remote service invocation t	<name>Existing Solutions</name>
	hrough protocols such as gRPC <xref target="GRPC"/> or MPI <xref target="MPI"/>	<t>Reasoning frameworks, such as TensorFlow, may be utilized for the
	with the intention of providing an on-chip NPU (neural processor unit) like abst	realization of the (distributed) AI training logic, building on
	raction to the AI framework.</t>	remote service invocation through protocols such as gRPC <xref
		target="GRPC"/> or the Message Passing Interface (MPI) <xref
		target="MPI"/> with the intention of providing an on-chip Neural
		Processor Unit (NPU) like abstraction to the AI framework.</t>
		<t>A number of activities on distributed AI training exist in the
		area of developing the 5th and 6th generation mobile network, with
		various activities in the 3GPP Standards Development Organization
		(SDO) as well as use cases developed for the ETSI MEC initiative
		mentioned in previous use cases.</t>
		</section>
		<section anchor="opportunities-8">


	<t>A number of activities on distributed AI training exist in the area of develo	<!-- [rfced] Section 6.1.4. Opportunities: We are having a difficult time
	ping the 5th and 6th generation mobile network with various activities in the 3G	parsing the two items below. How may we revise for clarity?
	PP SDO as well as use cases developed for the ETSI MEC initiative mentioned in p	(For example, in the second item, please consider where the first "e.g."
	revious use cases.</t>	phrase end, and how the second "e.g." connects to the preceding text.)


	</section>	Original:
	<section anchor="opportunities-8"><name>Opportunities</name>	* Supporting service-level routing of training requests (service
		routing in [APPCENTRES]), with AI services being exposed to the
		network, where (COIN) program instances may support the selection
		of the most suitable service instance based on control plane
		information, e.g., on AI worker compute capabilities, being
		distributed across (COIN) program instances.


	<t><list style="symbols">	* Supporting the collective communication primitives, such as all-
	<t>Supporting service-level routing of training requests (service routing in <	to-all, scatter-gather, utilized by the (distributed) AI workers
	xref target="APPCENTRES"/>), with AI services being exposed to the network, wher	to increase the overall network efficiency, e.g., through avoiding
	e (COIN) program instances may support the selection of the most suitable servic	endpoint-based replication or even directly performing, e.g.,
	e instance based on control plane information, e.g., on AI worker compute capabi	reduce, collective primitive operations in (COIN) program
	lities, being distributed across (COIN) program instances.</t>	instances placed in topologically advantageous places.
	<t>Supporting the collective communication primitives, such as all-to-all, sca
	tter-gather, utilized by the (distributed) AI workers to increase the overall ne
	twork efficiency, e.g., through avoiding endpoint-based replication or even dire
	ctly performing, e.g., reduce,
	collective primitive operations in (COIN) program instances placed in topolo
	gically advantageous places.</t>
	<t>Supporting collective communication between multiple instances of AI servic
	es, i.e., (COIN) program instances, may positively impact network but also comp
	ute utilization by moving from unicast replication to network-assisted multicast
	operation.</t>
	</list></t>


	</section>	Perhaps:
	<section anchor="research-questions-7"><name>Research Questions</name>	* Supporting service-level routing of training requests (such as service
	<t>In addition to the research questions in <xref target="mobileOffloadRQ"/>:</t	routing in [APPCENTRES]) with AI services being exposed to the
	>	network, and where (COIN) program instances may support the selection
		of the most suitable service instance based on control plane
		information (e.g., on AI worker compute capabilities being
		distributed across (COIN) program instances).


	<t><list style="symbols">	* Supporting the collective communication primitives, such as all-
	<t>RQ 6.1.1: What are the communication patterns that may be supported by coll	to-all and scatter-gather, utilized by the (distributed) AI
	ective communication solutions, where those solutions directly utilize (COIN) pr	workers may increase the overall network efficiency (e.g.,
	ogram instance capabilities within the network (e.g., reduce in a central (COIN)	through avoiding endpoint-based replication or even directly
	program instance)?</t>	performing (or reducing) collective primitive operations) in (COIN)
	<t>RQ 6.1.2: How to achieve scalable collective communication primitives with	program instances placed in topologically advantageous places.
	rapidly changing receiver sets, e.g., where training workers may be dynamically	-->
	selected based on energy efficiency constraints <xref target="GREENAI"/>?</t>
	<t>RQ 6.1.3: What COIN capabilities may support the collective communication p
	atterns found in distributed AI problems?</t>
	<t>RQ 6.1.4: How to support AI-specific invocation protocols, such as MPI or R
	DMA?</t>
	<t>RQ 6.1.5: What are the constraints for placing (AI) execution logic in the
	form of (COIN) programs in certain logical execution points (and their associate
	d physical locations), including PNDs, and how to signal and act upon them?</t>
	</list></t>


	</section>	<name>Opportunities</name>
	</section>	<ul spacing="normal">
	</section>	<li>
	<section anchor="preliminary-categorization-of-the-research-questions"><name>Pre	<t>Supporting service-level routing of training requests (such
	liminary Categorization of the Research Questions</name>	as service routing in <xref target="I-D.sarathchandra-coin-appcent
		res"/>), with AI services
		being exposed to the network, where (COIN) program instances may
		support the selection of the most suitable service instance
		based on control plane information, e.g., on AI worker compute
		capabilities, being distributed across (COIN) program
		instances.</t>
		</li>
		<li>
		<t>Supporting the collective communication primitives, such as
		all-to-all, scatter-gather, utilized by the (distributed) AI
		workers to increase the overall network efficiency, e.g.,
		through avoiding endpoint-based replication or even directly
		performing, e.g., reduce, collective primitive operations in
		(COIN) program instances placed in topologically advantageous
		places.</t>
		</li>
		<li>
		<t>Supporting collective communication between multiple
		instances of AI services (i.e., (COIN) program instances) may
		positively impact network but also compute utilization by moving
		from unicast replication to network-assisted multicast
		operation.</t>
		</li>
		</ul>
		</section>
		<section anchor="research-questions-7">
		<name>Research Questions</name>
		<t>In addition to the research questions in <xref
		target="mobileOffloadRQ"/>:</t>
		<ul spacing="normal">


	<t>This section describes a preliminary categorization of the reseach questions,	<!-- [rfced] Please clarify the final phrase; what is the subject of
	illustrated in <xref target="figureRQCategories"/>.	"reduce"? In other words, what educe in a central (COIN) program
	A more comprehensive analysis has been initiated by members of the COINRG commun
	ity in <xref target="USECASEANALYSIS"/> but has not been completed at the time o
	f writing this memo.</t>


	<figure title="Research Questions Categories" anchor="figureRQCategories"><artwo	Original:
	rk><![CDATA[	* RQ 6.1.1: What are the communication patterns that may be
		supported by collective communication solutions, where those
		solutions directly utilize (COIN) program instance capabilities
		within the network (e.g., reduce in a central (COIN) program
		instance)?
		-->
		<li>
		<t>RQ 6.1.1: What are the communication patterns that may be
		supported by collective communication solutions, where those
		solutions directly utilize (COIN) program instance capabilities
		within the network (e.g., reduce in a central (COIN) program
		instance)?</t>
		</li>
		<li>
		<t>RQ 6.1.2: How to achieve scalable collective communication
		primitives with rapidly changing receiver sets (e.g., where
		training workers may be dynamically selected based on energy
		efficiency constraints <xref target="GREENAI"/>)?</t>
		</li>
		<li>
		<t>RQ 6.1.3: What COIN capabilities may support the collective
		communication patterns found in distributed AI problems?</t>
		</li>
		<li>
		<t>RQ 6.1.4: How to support AI-specific invocation protocols,
		such as MPI or Remote Direct Memory Access (RDMA)?</t>
		</li>
		<li>
		<t>RQ 6.1.5: What are the constraints for placing (AI) execution
		logic in the form of (COIN) programs in certain logical
		execution points (and their associated physical locations),
		including PNDs, and how to signal and act upon them?</t>
		</li>
		</ul>
		</section>
		</section>
		</section>
		<section anchor="preliminary-categorization-of-the-research-questions">
		<name>Preliminary Categorization of the Research Questions</name>
		<t>This section describes a preliminary categorization of the research
		questions illustrated in <xref target="figureRQCategories"/>. A more
		comprehensive analysis has been initiated by members of the COINRG
		community in <xref target="I-D.irtf-coinrg-use-case-analysis"/> but has
		not been completed at the time of writing this memo.</t>
		<figure anchor="figureRQCategories">
		<name>Research Questions Categories</name>
		<artwork><![CDATA[
	+--------------------------------------------------------------+	+--------------------------------------------------------------+
	+ Applicability Areas +	+ Applicability Areas +
	+ .............................................................+	+ .............................................................+
	+ Transport \| App \| Data \| Routing & \| (Industrial) +	+ Transport \| App \| Data \| Routing & \| (Industrial) +
	+ \| Design \| Processing \| Forwarding \| Control +	+ \| Design \| Processing \| Forwarding \| Control +
	+--------------------------------------------------------------+	+--------------------------------------------------------------+

	+--------------------------------------------------------------+	+--------------------------------------------------------------+
	+ Distributed Computing FRAMEWORKS and LANGUAGES to COIN +	+ Distributed Computing FRAMEWORKS and LANGUAGES to COIN +
	+--------------------------------------------------------------+	+--------------------------------------------------------------+

	+--------------------------------------------------------------+	+--------------------------------------------------------------+
	+ ENABLING TECHNOLOGIES for COIN +	+ ENABLING TECHNOLOGIES for COIN +
	+--------------------------------------------------------------+	+--------------------------------------------------------------+

	+--------------------------------------------------------------+	+--------------------------------------------------------------+
	+ VISION(S) for COIN +	+ VISION(S) for COIN +
	+--------------------------------------------------------------+	+--------------------------------------------------------------+

	]]></artwork></figure>	]]></artwork>
		</figure>


	<t>The VISION(S) for COIN category is about defining and shaping the exact sco	<!-- [rfced] Section 7:
	pe of COIN.
	In contrast to the ENABLING TECHNOLOGIES category, these research questions look
	at the problem from a more philosophical perspective.
	In particular, the questions center around where to perform computations, which
	tasks are suitable for COIN, for which tasks COIN is suitable, and which forms o
	f deploying COIN might be desirable.
	This category includes the research questions 3.1.8, 3.2.1, 3.3.5, 3.3.6, 3.3.7,
	5.3.3, 6.1.1, and 6.1.3.</t>


	<t>The ENABLING TECHNOLOGIES for COIN category digs into what technologies are	a) In Figure 4 (and throughout Section 7) some words are in all caps, while
	needed to enable COIN, which of the existing technologies can be reused for COI	others are not. Should these partially capitalized phrases be updated to match
	N, and what might be needed to make the VISION(S) for COIN a reality.	the other categories that appear in title case?
	In contrast to the VISION(S), these research questions look at the problem from
	a practical perspective, e.g., by considering how COIN can be incorporated in ex
	isting systems or how the interoperability of COIN execution environments can be
	enhanced.
	This category includes the research questions 3.1.7, 3.1.8, 3.2.3, 4.2.7, 5.1.1,
	5.1.2, 5.1.6, 5.3.1, 6.1.2, and 6.1.3.</t>


	<t>The Distributed Computing FRAMEWORKS and LANGUAGES to COIN category focuses	Partially capitalized:
	on how COIN programs can be deployed and orchestrated.	VISION(S) for COIN
	Central questions arise regarding the composition of COIN programs, the placemen	ENABLING TECHNOLOGIES for COIN
	t of COIN functions, the (dynamic) operation and integration of COIN systems as	Distributed Computing FRAMEWORKS and LANGUAGES to COIN
	well as additional COIN system properties.
	Notably, COIN diversifies general distributed computing platforms such that many
	COIN-related research questions could also apply to general distributed computi
	ng frameworks.
	This category includes the research questions 3.1.1, 3.2.4, 3.3.1, 3.3.2, 3.3.3,
	3.3.5, 4.1.1, 4.1.4, 4.1.5, 4.1.8, 4.2.1, 4.2.4, 4.2.5, 4.2.6, 4.3.3, 5.2.1, 5.
	2.2, 5.2.3, 5.2.5, 5.3.1, 5.3.2, 5.3.3, 5.3.4, 5.3.5, and 6.1.5.</t>


	<t>In addition to these core categories, there are use-case-specific research qu	Title case:
	estions that are heavily influenced by the specific constraints and objectives o	Applicability Areas
	f the respective use cases.	Transport
	This Applicability Areas category can be further refined into the following su	App Design
	bgroups:</t>	Data Processing
		Routing & Forwarding
		(Industrial) Control


	<t><list style="symbols">	b) FYI - We have replaced the asterisks in this section with quotation marks
	<t>The Transport subgroup addresses the need to adapt transport protocols to	to indicate that these terms refer to items in Figure 4.
	handle dynamic deployment locations effectively.	-->
	This subgroup includes the research question 3.1.2.</t>
	<t>The App Design subgroup relates to the design principles and consideratio
	ns when developing COIN applications.
	This subgroup includes the research questions 4.1.2, 4.1.3, 4.1.7, 4.2.6, 5.1.1,
	5.1.3, and 5.1.5.</t>
	<t>The Data Processing subgroup relates to the handling, storage, analysis,
	and processing of data in COIN environments.
	This subgroup includes the research questions 3.2.4, 3.2.6, 4.2.2, 4.2.3, and 4.
	3.2.</t>
	<t>The Routing & Forwarding subgroup explores efficient routing and forw
	arding mechanisms in COIN, considering factors such as network topology, congest
	ion control, and quality of service.
	This subgroup includes the research questions 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.1.6,
	3.2.6, 5.1.2, 5.1.3, 5.1.4, and 6.1.4.</t>
	<t>The (Industrial) Control subgroup relates to industrial control systems,
	addressing issues like real-time control, automation, and fault tolerance.
	This subgroup includes the research questions 3.1.9, 3.2.5, 3.3.1, 3.3.4, 4.1.1,
	4.1.6, 4.1.8, 4.2.3, 4.3.1, and 4.3.4.</t>
	</list></t>


	</section>	<t>The "VISION(S) for COIN" category is about defining and shaping the
	<section anchor="sec_considerations"><name>Security Considerations</name>	exact scope of COIN. In contrast to the "ENABLING TECHNOLOGIES" category,
		these research questions look at the problem from a more philosophical
		perspective. In particular, the questions center around where to
		perform computations, which tasks are suitable for COIN, for which tasks
		COIN is suitable, and which forms of deploying COIN might be desirable.
		This category includes the research questions 3.1.8, 3.2.1, 3.3.5,
		3.3.6, 3.3.7, 5.3.3, 6.1.1, and 6.1.3.</t>
		<t>The "ENABLING TECHNOLOGIES for COIN" category digs into what
		technologies are needed to enable COIN, which of the existing
		technologies can be reused for COIN, and what might be needed to make
		the "VISION(S) for COIN" a reality. In contrast to the "VISION(S) for COI
		N", these
		research questions look at the problem from a practical perspective
		(e.g., by considering how COIN can be incorporated in existing systems or
		how the interoperability of COIN execution environments can be enhanced).
		This category includes the research questions 3.1.7, 3.1.8, 3.2.3,
		4.2.7, 5.1.1, 5.1.2, 5.1.6, 5.3.1, 6.1.2, and 6.1.3.</t>
		<t>The "Distributed Computing FRAMEWORKS and LANGUAGES to COIN" category
		focuses on how COIN programs can be deployed and orchestrated. Central
		questions arise regarding the composition of COIN programs, the
		placement of COIN functions, the (dynamic) operation and integration of
		COIN systems as well as additional COIN system properties. Notably,
		COIN diversifies general distributed computing platforms such that many
		COIN-related research questions could also apply to general distributed
		computing frameworks. This category includes the research questions
		3.1.1, 3.2.4, 3.3.1, 3.3.2, 3.3.3, 3.3.5, 4.1.1, 4.1.4, 4.1.5, 4.1.8,
		4.2.1, 4.2.4, 4.2.5, 4.2.6, 4.3.3, 5.2.1, 5.2.2, 5.2.3, 5.2.5, 5.3.1,
		5.3.2, 5.3.3, 5.3.4, 5.3.5, and 6.1.5.</t>
		<t>In addition to these core categories, there are use case specific
		research questions that are heavily influenced by the specific
		constraints and objectives of the respective use cases. This
		"Applicability Areas" category can be further refined into the following
		subgroups:</t>
		<ul spacing="normal">
		<li>
		<t>The "Transport" subgroup addresses the need to adapt transport
		protocols to handle dynamic deployment locations effectively. This
		subgroup includes the research question 3.1.2.</t>
		</li>
		<li>
		<t>The "App Design" subgroup relates to the design principles and
		considerations when developing COIN applications. This subgroup
		includes the research questions 4.1.2, 4.1.3, 4.1.7, 4.2.6, 5.1.1,
		5.1.3, and 5.1.5.</t>
		</li>
		<li>
		<t>The "Data Processing" subgroup relates to the handling, storage,
		analysis, and processing of data in COIN environments. This
		subgroup includes the research questions 3.2.4, 3.2.6, 4.2.2, 4.2.3,
		and 4.3.2.</t>
		</li>
		<li>
		<t>The "Routing & Forwarding" subgroup explores efficient
		routing and forwarding mechanisms in COIN, considering factors such
		as network topology, congestion control, and quality of service.
		This subgroup includes the research questions 3.1.2, 3.1.3, 3.1.4,
		3.1.5, 3.1.6, 3.2.6, 5.1.2, 5.1.3, 5.1.4, and 6.1.4.</t>
		</li>
		<li>
		<t>The "(Industrial) Control" subgroup relates to industrial control
		systems, addressing issues like real-time control, automation, and
		fault tolerance. This subgroup includes the research questions
		3.1.9, 3.2.5, 3.3.1, 3.3.4, 4.1.1, 4.1.6, 4.1.8, 4.2.3, 4.3.1, and
		4.3.4.</t>
		</li>
		</ul>
		</section>
		<section anchor="sec_considerations">
		<name>Security Considerations</name>
		<t>COIN systems, like any other system using "middleboxes", can have
		different security and privacy implications that strongly depend on the
		used platforms, the provided functionality, and the deployment domain,
		with most if not all considerations for general middleboxes also
		applying to COIN systems.</t>
		<t>One critical aspect for early COIN systems is the use of early
		generation PNDs, many of which do not have cryptography support and only
		have limited computational capabilities. Hence, PND-based COIN systems
		typically work on unencrypted data and often customize packet payload,
		while concepts such as homomorphic encryption could serve as
		workarounds, allowing PNDs to perform simple operations on the encrypted
		data without having access to it. All these approaches introduce the
		same or very similar security implications as any middlebox operating on
		unencrypted traffic or having access to encryption: a middlebox can
		itself have malicious intentions (e.g., because it got compromised or
		the deployment of functionality offers new attack vectors to
		outsiders).</t>
		<t>However, similar to middlebox deployments, risks for privacy and data
		exposure have to be carefully considered in the context of the concrete
		deployment. For example, exposing data to an external operator for
		mobile application offloading leads to a significant privacy loss of the
		user in any case. In contrast, such privacy considerations are not as
		relevant for COIN systems where all involved entities are under the same
		control, such as in an industrial context. Here, exposed data and
		functionality can instead lead to stolen business secrets or the
		enabling of DoS attacks, for example. Hence, even in fully controlled
		scenarios, COIN intermediaries, and middleboxes in general, are ideally
		operated in a least-privilege mode, where they have exactly those
		permissions to read and alter payload that are necessary to fulfill their
		purpose.</t>
		<t>Research on granting middleboxes access to secured traffic is only in
		its infancy, and a variety of different approaches are proposed and
		analyzed <xref target="TLSSURVEY"/>. In a SplitTLS <xref
		target="SPLITTLS"/> deployment, for example, middleboxes have different
		incoming and outgoing TLS channels, such that they have full read and
		write access to all intercepted traffic. More restrictive approaches
		for deploying middleboxes rely on searchable encryption or
		zero-knowledge proofs to expose less data to intermediaries, but those
		only offer limited functionality. MADTLS <xref target="MADTLS"/> is
		tailored to the industrial domain and offers bit-level read and write
		access to intermediaries with low latency and bandwidth overhead, at the
		cost of more complex key management. Overall, different proposals offer
		different advantages and disadvantages that must be carefully considered
		in the context of concrete deployments. Further research could pave the
		way for a more unified and configurable solution that is easier to
		maintain and deploy.</t>
		<t>Finally, COIN systems and other middlebox deployments can also lead
		to security risks even if the attack stems from an outsider without
		direct access to any devices. As such, metadata about the entailed
		processing (processing times or changes in incoming and outgoing data) can
		allow an attacker to extract valuable information about the process.
		Moreover, such deployments can become central entities that, if
		paralyzed (e.g., through extensive requests), can be responsible for
		large-scale outages. In particular, some deployments could be used to
		amplify DoS attacks. Similar to other middlebox deployments, these
		potential risks must be considered when deploying COIN functionality and
		may influence the selection of suitable security protocols.</t>
		<t>Additional system-level security considerations may arise from
		regulatory requirements imposed on COIN systems overall, stemming from
		regulation regarding, lawful interception, data localization, or
		AI use, for example. These requirements may impact, for example, the mann
		er in which (COIN)
		programs may be placed or executed in the overall system, who can invoke
		certain (COIN) programs in what PND or COIN device, and what type of
		(COIN) program can be run. These considerations will impact the design
		of the possible implementing protocols but also the policies that govern
		the execution of (COIN) programs.</t>
		</section>


	<t>COIN systems, like any other system using ``middleboxes'', can have different	<section anchor="iana-considerations">
	security and privacy implications that strongly depend on the used platforms, t	<name>IANA Considerations</name>
	he provided functionality, and the deployment domain, with most if not all consi	<t>This document has no IANA actions.</t>
	derations for general middleboxes also applying for COIN systems.</t>	</section>


	<t>One critical aspect for early COIN systems is the use of early-generation PND	<section anchor="conclusion">
	s, many of which do not have cryptography support and only have limited computat	<name>Conclusion</name>
	ional capabilities.	<t>This document presents use cases gathered from several application
	Hence, PND-based COIN systems typically work on unencrypted data and often custo	domains that can and could profit from capabilities that are provided by
	mize packet payload while concepts, such as homomorphic encryption, could serve	in-network and, more generally, distributed compute platforms. We
	as workarounds, allowing PNDs to perform simple operations on the encrypted data	distinguish between use cases in which COIN may enable new experiences
	without having access to it.	(<xref target="newExperiences"/>), expose new features (<xref
	All these approaches introduce the same or very similar security implications as	target="newCapabilities"/>), or improve on existing system capabilities
	any middlebox operating on unencrypted traffic or having access to encryption:	(<xref target="existingCapabilities"/>), and other use cases where COIN
	a middlebox can itself have malicious intentions, e.g., because it got compromis	capabilities enable totally new applications, for example, in industrial
	ed, or the deployment of functionality offers new attack vectors to outsiders.</	networking (<xref target="newEnvironments"/>).</t>
	t>	<t>Beyond the mere description and characterization of those use cases,
		we identify opportunities arising from utilizing COIN capabilities and
		formulate corresponding research questions that may need to be
		addressed before being able to reap those opportunities.</t>
		<t>We acknowledge that this work offers no comprehensive overview of
		possible use cases and is thus only a snapshot of what may be possible
		if COIN capabilities existed. In fact, the decomposition of many
		current client-server applications into node-by-node transit could
		identify other opportunities for adding computing to forwarding, notably
		in the supply chain, health care, intelligent cities and transportation,
		and even financial services (among others). The presented use cases
		are selected based on the expertise of the contributing community
		members at the time of writing and are intended to cover a diverse range,
		from immersive and interactive media, industrial networks, to AI with
		varying characteristics, thus, providing the basis for a thorough
		subsequent analysis.</t>
		</section>


	<t>However, similar to middlebox deployments, risks for privacy and of data expo	</middle>
	sure have to be carefully considered in the context of the concrete deployment.
	For example, exposing data to an external operator for mobile application offloa
	ding leads to a significant privacy loss of the user in any case.
	In contrast, such privacy considerations are not as relevant for COIN systems wh
	ere all involved entities are under the same control, such as in an industrial c
	ontext.
	Here, exposed data and functionality can instead lead to stolen business secrets
	or the enabling of, e.g., DoS attacks.
	Hence, even in fully controlled scenarios, COIN intermediaries, and middleboxes
	in general, are ideally operated in a least-privilege mode, where they have exac
	tly those permissions to read and alter payload that are necessary to fulfil the
	ir purpose.</t>


	<t>Research on granting middleboxes access to secured traffic is only in its inf	<back>
	ancy and a variety of different approaches are proposed and analyzed <xref targe	<displayreference target="I-D.trossen-icnrg-ip-icn-5glan" to="ICN-5GLAN"/>
	t="TLSSURVEY"/>.	<displayreference target="I-D.sarathchandra-coin-appcentres" to="APPCENTRES"
	In a SplitTLS <xref target="SPLITTLS"/> deployment, e.g., middleboxes have diffe	/>
	rent incoming and outgoing TLS channels, such that they have full read and write	<displayreference target="I-D.irtf-coinrg-use-case-analysis" to="USE-CASE-AN
	access to all intercepted traffic.	"/>
	More restrictive approaches for deploying middleboxes rely on searchable encrypt	<displayreference target="I-D.hsingh-coinrg-reqs-p4comp" to="P4-SPLIT"/>
	ion or zero-knowledge proofs to expose less data to intermediaries, but those on	<displayreference target="I-D.ravi-icnrg-5gc-icn" to="ICN-5GC"/>
	ly offer limited functionality.	<references>
	MADTLS<xref target="MADTLS"/> is tailored to the industrial domain and offers bi	<name>Informative References</name>
	t-level read and write access to intermediaries with low latency and bandwidth o
	verhead, at the cost of more complex key management.
	Overall, different proposals offer different advantages and disadvantages that m
	ust be carefully considered in the context of concrete deployments.
	Further research could pave the way for a more unified and configurable solution
	that is easier to maintain and deploy.</t>


	<t>Finally, COIN systems and other middlebox deployments can also lead to securi	<!-- [APPCENTRES]
	ty risks even if the attack stems from an outsider without direct access to any	draft-sarathchandra-coin-appcentres-04
	devices.	IESG State: Expired as of 03/21/25.
	As such, metadata about the entailed processing (processing times, changes in in	-->
	coming and outgoing data) can allow an attacker to extract valuable information	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.sa
	about the process.	rathchandra-coin-appcentres.xml"/>
	Moreover, such deployments can become central entities that, if paralyzed (e.g.,
	through extensive requests), can be responsible for large-scale outages.
	In particular, some deployments could be used to amplify DoS attacks.
	Similar to other middlebox deployments, these potential risks must be considered
	when deploying COIN functionality and may influence the selection of suitable s
	ecurity protocols.</t>


	<t>Additional system-level security considerations may arise from regulatory req	<!-- [RUETH] anchor changed to match surname Rüth.
	uirements imposed on COIN systems overall, stemming from regulation regarding, e	-->
	.g., lawful interception, data localization, or AI use.	<reference anchor="RÜTH">
	These requirements may impact, e.g., the manner in which (COIN) programs may be	<front>
	placed or executed in the overall system, who can invoke certain (COIN) programs	<title>Towards In-Network Industrial Feedback Control</title>
	in what PND or COIN device, and what type of (COIN) program can be run.	<author fullname="Jan Rüth" initials="J." surname="Rüth">
	These considerations will impact the design of the possible implementing protoco	<organization>RWTH Aachen University</organization>
	ls but also the policies that govern the execution of (COIN) programs.</t>	</author>
		<author fullname="René Glebke" initials="R." surname="Glebke">
		<organization>RWTH Aachen University</organization>
		</author>
		<author fullname="Klaus Wehrle" initials="K." surname="Wehrle">
		<organization>RWTH Aachen University</organization>
		</author>
		<author fullname="Vedad Causevic" initials="V." surname="Causevic">
		<organization>Technical University of Munich</organization>
		</author>
		<author fullname="Sandra Hirche" initials="S." surname="Hirche">
		<organization>Technical University of Munich</organization>
		</author>
		<date month="August" year="2018"/>
		</front>
		<refcontent>Proceedings of the 2018 Morning Workshop on In-Network Compu
		ting, pp. 14-19</refcontent>
		<seriesInfo name="DOI" value="10.1145/3229591.3229592"/>
		</reference>


	</section>	<!-- [VESTIN] -->
	<section anchor="iana-considerations"><name>IANA Considerations</name>	<reference anchor="VESTIN">
	<t>N/A</t>	<front>
		<title>FastReact: In-Network Control and Caching for Industrial Contro
		l Networks using Programmable Data Planes</title>
		<author fullname="Jonathan Vestin" initials="J." surname="Vestin">
		<organization/>
		</author>
		<author fullname="Andreas Kassler" initials="A." surname="Kassler">
		<organization/>
		</author>
		<author fullname="Johan Akerberg" initials="J." surname="Akerberg">
		<organization/>
		</author>
		<date month="September" year="2018"/>
		</front>
		<refcontent>2018 IEEE 23rd International Conference on Emerging Technolo
		gies and Factory Automation (ETFA), pp. 219-226</refcontent>
		<seriesInfo name="DOI" value="10.1109/etfa.2018.8502456"/>
		</reference>


	</section>	<!-- [GLEBKE] -->
	<section anchor="conclusion"><name>Conclusion</name>	<reference anchor="GLEBKE">
	<t>This document presented use cases gathered from several application domains t	<front>
	hat can and could profit from capabilities that are provided by in-network and,	<title>A Case for Integrated Data Processing in Large-Scale Cyber-Phys
	more generally, distributed compute platforms.	ical Systems</title>
	We distinguished between use cases in which COIN may enable new experiences (<xr	<author fullname="Rene Glebke" initials="R." surname="Glebke">
	ef target="newExperiences"/>), expose new features (<xref target="newCapabilitie	<organization/>
	s"/>), or improve on existing system capabilities (<xref target="existingCapabil	</author>
	ities"/>), and other use cases where COIN capabilities enable totally new applic	<author fullname="Martin Henze" initials="M." surname="Henze">
	ations, for example, in industrial networking (<xref target="newEnvironments"/>)	<organization/>
	.</t>	</author>
		<author fullname="Klaus Wehrle" initials="K." surname="Wehrle">
		<organization/>
		</author>
		<author fullname="Philipp Niemietz" initials="P." surname="Niemietz">
		<organization/>
		</author>
		<author fullname="Daniel Trauth" initials="D." surname="Trauth">
		<organization/>
		</author>
		<author fullname="Patrick Mattfeld" initials="P." surname="Mattfeld">
		<organization/>
		</author>
		<author fullname="Thomas Bergs" initials="T." surname="Bergs">
		<organization/>
		</author>
		<date year="2019"/>
		</front>
		<refcontent>Proceedings of the Annual Hawaii International Conference on
		System Sciences</refcontent>
		<seriesInfo name="DOI" value="10.24251/hicss.2019.871"/>
		</reference>


	<t>Beyond the mere description and characterization of those use cases, we ident	<!-- draft-irtf-coinrg-use-case-analysis-02
	ified opportunities arising from utilizing COIN capabilities and formulated corr	IESG State: I-D Exists as of 03/21/25.
	esponding research questions that may need to be addressed before being able to	-->
	reap those opportunities.</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ir
		tf-coinrg-use-case-analysis.xml"/>


	<t>We acknowledge that this work offers no comprehensive overview of possible us	<!-- [P4] -->
	e cases and is thus only a snapshot of what may be possible if COIN capabilities	<reference anchor="P4">
	existed.<br />	<front>
	In fact, the decomposition of many current client-server applications into node	<title>P4: programming protocol-independent packet processors</title>
	by node transit could identify other opportunities for adding computing to forwa	<author fullname="Pat Bosshart" initials="P." surname="Bosshart">
	rding notably in supply-chain, health care, intelligent cities and transportatio	<organization>Barefoot Networks, Palo Alto, CA, USA</organization>
	n and even financial services (among others).	</author>
	The presented use cases were selected based on the expertise of the contributing	<author fullname="Dan Daly" initials="D." surname="Daly">
	community members at the time of writing and are intended to cover a diverse ra	<organization>Intel, Ann Arbor, MI, USA</organization>
	nge from immersive and interactive media, industrial networks, to AI with varyin	</author>
	g characteristics, thus, providing the basis for a thorough subsequent analysis.	<author fullname="Glen Gibb" initials="G." surname="Gibb">
	</t>	<organization>Barefoot Networks, Palo Alto, CA, USA</organization>
		</author>
		<author fullname="Martin Izzard" initials="M." surname="Izzard">
		<organization>Barefoot Networks, Palo Alto, CA, USA</organization>
		</author>
		<author fullname="Nick McKeown" initials="N." surname="McKeown">
		<organization>Stanford University, Stanford, CA, USA</organization>
		</author>
		<author fullname="Jennifer Rexford" initials="J." surname="Rexford">
		<organization>Princeton University, Princeton, NJ, USA</organization
		>
		</author>
		<author fullname="Cole Schlesinger" initials="C." surname="Schlesinger
		">
		<organization>Princeton University, Princeton, NJ, USA</organization
		>
		</author>
		<author fullname="Dan Talayco" initials="D." surname="Talayco">
		<organization>Barefoot Networks, Palo Alto, CA, USA</organization>
		</author>
		<author fullname="Amin Vahdat" initials="A." surname="Vahdat">
		<organization>Google, Mountain View, CA, USA</organization>
		</author>
		<author fullname="George Varghese" initials="G." surname="Varghese">
		<organization>Microsoft Research, Mountain View, CA, USA</organizati
		on>
		</author>
		<author fullname="David Walker" initials="D." surname="Walker">
		<organization>Princeton University, Princeton, NJ, USA</organization
		>
		</author>
		<date month="July" year="2014"/>
		</front>
		<refcontent>ACM SIGCOMM Computer Communication Review, vol. 44, no. 3, p
		p. 87-95</refcontent>
		<seriesInfo name="DOI" value="10.1145/2656877.2656890"/>
		</reference>


	</section>	<!-- [GRPC] -->
	<section anchor="acknowledgements"><name>Acknowledgements</name>	<reference anchor="GRPC" target="https://grpc.io/">
		<front>
		<title>High performance, open source universal RPC framework</title>
		<author>
		<organization/>
		</author>
		<date/>
		</front>
		</reference>


	<t>The authors would like to thank Eric Wagner for providing text on the securit	<!-- [MPI] -->
	y considerations and Jungha Hong for her efforts in continuing the work on the u	<reference anchor="MPI" target="https://arxiv.org/pdf/1603.02339.pdf">
	se case analysis document that has largely sourced the preliminary categorizatio	<front>
	n section of this document.	<title>Scaling Distributed Machine Learning with In-Network Aggregatio
	The authors would further like to thank Chathura Sarathchandra, David Oran, Phil	n</title>
	Eardley, Stuart Card, Jeffrey He, Toerless Eckert, and Jon Crowcroft for review	<author initials="A." surname="Vishnu">
	ing earlier versions of the document, Colin Perkins for his IRTF chair review, a	<organization/>
	nd Jerome Francois for his thorough IRSG review.</t>	</author>
		<author initials="C." surname="Siegel">
		<organization/>
		</author>
		<author initials="J." surname="Daily">
		<organization/>
		</author>
		<date month="August" year="2017"/>
		</front>
		<refcontent>arXiv:1603.02339v2</refcontent>
		</reference>


	</section>	<!-- [FCDN] -->
		<reference anchor="FCDN" target="https://arxiv.org/pdf/1803.00876.pdf">
		<front>
		<title>fCDN: A Flexible and Efficient CDN Infrastructure without DNS R
		edirection of Content Reflection</title>
		<author initials="M." surname="Al-Naday">
		<organization/>
		</author>
		<author initials="M. J." surname="Reed">
		<organization/>
		</author>
		<author initials="J." surname="Riihijarvi">
		<organization/>
		</author>
		<author initials="D." surname="Trossen">
		<organization/>
		</author>
		<author initials="N." surname="Thomos">
		<organization/>
		</author>
		<author initials="M." surname="Al-Khalidi">
		<organization/>
		</author>
		<date/>
		</front>
		<refcontent>arXiv:1803.00876v2</refcontent>
		</reference>


	</middle>	<!-- [I-D.ravi-icnrg-5gc-icn]
		draft-ravi-icnrg-5gc-icn-04
		IESG State: Replaced by draft-irtf-icnrg-5gc-icn
		-->
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ra
		vi-icnrg-5gc-icn.xml"/>


	<back>	<!-- [I-D.hsingh-coinrg-reqs-p4comp]
		draft-hsingh-coinrg-reqs-p4comp-03
		IESG State: Expired as of 03/21/25.
		-->
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.hs
		ingh-coinrg-reqs-p4comp.xml"/>


	<references title='Informative References'>	<!--[rfced] References:


	<reference anchor='APPCENTRES'>	a) For [Stoyanov], would you like to change the URL for this
	<front>	reference or leave it as is?
	<title>In-Network Computing for App-Centric Micro-Services</title>
	<author fullname='Dirk Trossen' initials='D.' surname='Trossen'>
	<organization>Huawei</organization>
	</author>
	<author fullname='Chathura Sarathchandra' initials='C.' surname='Sarathcha
	ndra'>
	<organization>InterDigital Inc.</organization>
	</author>
	<author fullname='Michael Boniface' initials='M.' surname='Boniface'>
	<organization>University of Southampton</organization>
	</author>
	<date day='26' month='January' year='2021'/>
	<abstract>
	<t> The application-centric deployment of 'Internet' service
	s has
	increased over the past ten years with many millions of applications
	providing user-centric services, executed on increasingly more
	powerful smartphones that are supported by Internet-based cloud
	services in distributed data centres, the latter mainly provided by
	large scale players such as Google, Amazon and alike. This draft
	outlines a vision for evolving those data centres towards executing
	app-centric micro-services; we dub this evolved data centre as an
	AppCentre. Complemented with the proliferation of such AppCentres at
	the edge of the network, they will allow for such micro-services to
	be distributed across many places of execution, including mobile
	terminals themselves, while specific micro-service chains equal
	today's applications in existing smartphones.


	We outline the key enabling technologies that needs to be provided	Current: https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf
	for such evolution to be realized, including references to ongoing	Perhaps: https://dl.acm.org/doi/10.1145/3426744.3431329
	standardization efforts in key areas.


	</t>	b) For [SA2-5GLAN], the URL provided returns a "403 - Forbidden"
	</abstract>	error. We were unable to find an alternative source for this
	</front>	reference. Please review and let us know how to update.
	<seriesInfo name='Internet-Draft' value='draft-sarathchandra-coin-appcentres-
	04'/>


	</reference>	Current:
		[SA2-5GLAN]
		3GPP-5glan, "SP-181129, Work Item Description,
		Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and
		LAN Services", 3GPP , 2021,
		<http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-
		181120.zip>.
		-->


	<reference anchor='RUETH'>	<reference anchor="Stoyanov" target="https://eng.ox.ac.uk/media/6354/stoya
	<front>	nov2020mtpsa.pdf">
	<title>Towards In-Network Industrial Feedback Control</title>	<front>
	<author fullname='Jan Rueth' initials='J.' surname='Rueth'>	<title>MTPSA: Multi-Tenant Programmable Switches</title>
	<organization>RWTH Aachen University</organization>	<author initials="R." surname="Stoyanov">
	</author>	<organization/>
	<author fullname='Rene Glebke' initials='R.' surname='Glebke'>	</author>
	<organization>RWTH Aachen University</organization>	<author initials="N." surname="Zilberman">
	</author>	<organization/>
	<author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'>	</author>
	<organization>RWTH Aachen University</organization>	<date month="December" year="2020"/>
	</author>	</front>
	<author fullname='Vedad Causevic' initials='V.' surname='Causevic'>	<seriesInfo name="DOI" value="10.1145/3426744.3431329"/>
	<organization>Technical University of Munich</organization>	<refcontent>Proceedings of the 3rd P4 Workshop in Europe, pp. 43-48</ref
	</author>	content>
	<author fullname='Sandra Hirche' initials='S.' surname='Hirche'>	</reference>
	<organization>Technical University of Munich</organization>
	</author>
	<date month='August' year='2018'/>
	</front>
	<seriesInfo name='Proceedings of the 2018 Morning Workshop on In-Network' valu
	e='Computing'/>
	<seriesInfo name='DOI' value='10.1145/3229591.3229592'/>
	</reference>


	<reference anchor='VESTIN'>	<reference anchor="TS23.501" target="https://www.3gpp.org/DynaReport/23501
	<front>	.htm">
	<title>FastReact: In-Network Control and Caching for Industrial Control Netw	<front>
	orks using Programmable Data Planes</title>	<title>System Architecture for the 5G System; Stage 2 (Rel.17)</title>
	<author fullname='Jonathan Vestin' initials='J.' surname='Vestin'>	<author>
	<organization/>	<organization>3GPP</organization>
	</author>	</author>
	<author fullname='Andreas Kassler' initials='A.' surname='Kassler'>	<date year="2021"/>
	<organization/>	</front>
	</author>	<seriesInfo name="3GPP" value="TS 23.501"/>
	<author fullname='Johan Akerberg' initials='J.' surname='Akerberg'>	</reference>
	<organization/>
	</author>
	<date month='September' year='2018'/>
	</front>
	<seriesInfo name='2018 IEEE 23rd International Conference on Emerging Technolo
	gies and Factory Automation (ETFA)' value='pp. 219-226'/>
	<seriesInfo name='DOI' value='10.1109/etfa.2018.8502456'/>
	</reference>


	<reference anchor='GLEBKE'>	<reference anchor="TS23.502" target="https://www.3gpp.org/DynaReport/23502
	<front>	.htm">
	<title>A Case for Integrated Data Processing in Large-Scale Cyber-Physical S	<front>
	ystems</title>	<title>Procedures for the 5G System; Stage 2 (Rel.17)</title>
	<author fullname='Rene Glebke' initials='R.' surname='Glebke'>	<author>
	<organization/>	<organization>3GPP</organization>
	</author>	</author>
	<author fullname='Martin Henze' initials='M.' surname='Henze'>	<date year="2021"/>
	<organization/>	</front>
	</author>	<seriesInfo name="3GPP" value="TS 23.502"/>
	<author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'>	</reference>
	<organization/>
	</author>
	<author fullname='Philipp Niemietz' initials='P.' surname='Niemietz'>
	<organization/>
	</author>
	<author fullname='Daniel Trauth' initials='D.' surname='Trauth'>
	<organization/>
	</author>
	<author fullname='Patrick Mattfeld MBA' initials='P.' surname='Mattfeld MBA'
	>
	<organization/>
	</author>
	<author fullname='Thomas Bergs' initials='T.' surname='Bergs'>
	<organization/>
	</author>
	<date year='2019'/>
	</front>
	<seriesInfo name='Proceedings of the Annual Hawaii International Conference on
	System' value='Sciences'/>
	<seriesInfo name='DOI' value='10.24251/hicss.2019.871'/>
	</reference>


	<reference anchor='USECASEANALYSIS'>	<reference anchor="SA2-5GLAN" target="http://www.3gpp.org/ftp/tsg_sa/TSG_S
	<front>	A/Docs/SP-181120.zip">
	<title>Use Case Analysis for Computing in the Network</title>	<front>
	<author fullname='Ike Kunze' initials='I.' surname='Kunze'>	<title>SP-181129, Work Item Description, Vertical_LAN(SA2), 5GS Enhanc
	<organization>RWTH Aachen University</organization>	ed Support of Vertical and LAN Services</title>
	</author>	<author initials="" surname="3GPP-5glan" fullname="3GPP-5glan">
	<author fullname='Jungha Hong' initials='J.' surname='Hong'>	<organization/>
	<organization>ETRI</organization>	</author>
	</author>	<date year="2021"/>
	<author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'>	</front>
	<organization>RWTH Aachen University</organization>	<seriesInfo name="3GPP" value=""/>
	</author>	</reference>
	<author fullname='Dirk Trossen' initials='D.' surname='Trossen'>
	<organization>Huawei Technologies Duesseldorf GmbH</organization>
	</author>
	<author fullname='Marie-Jose Montpetit' initials='M.' surname='Montpetit'>
	<organization>Concordia University</organization>
	</author>
	<author fullname='Xavier de Foy' initials='X.' surname='de Foy'>
	<organization>InterDigital Communications, LLC</organization>
	</author>
	<author fullname='David Griffin' initials='D.' surname='Griffin'>
	<organization>University College London</organization>
	</author>
	<author fullname='Miguel Rio' initials='M.' surname='Rio'>
	<organization>University College London</organization>
	</author>
	<date day='4' month='December' year='2024'/>
	<abstract>
	<t> Computing in the Network (COIN) has the potential to enable a wide
	variety of use cases. The diversity in use cases makes challenges in
	defining general considerations. This document analyzes the use
	cases described in a COINRG companion document and potentially
	explores additional settings, to identify general aspects of interest
	across all use cases. The insights gained from this analysis will
	guide future COIN discussions.


	</t>	<!--[rfced] We see that draft-trossen-icnrg-ip-icn-5glan
	</abstract>	was replaced by draft-trossen-icnrg-internet-icn-5glan. Would you
	</front>	like this reference to be updated to the latter?
	<seriesInfo name='Internet-Draft' value='draft-irtf-coinrg-use-case-analysis-
	02'/>


	</reference>	Current:
		[ICN-5GLAN]
		Trossen, D., Wang, C., Robitzsch, S., Reed, M., AL-Naday,
		M., and J. Riihijarvi, "IP-based Services over ICN in 5G
		LAN Environments", Work in Progress, Internet-Draft,
		draft-trossen-icnrg-ip-icn-5glan-00, 6 June 2019,
		<https://datatracker.ietf.org/doc/html/draft-trossen-
		icnrg-ip-icn-5glan-00>.
		-->
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.tr
		ossen-icnrg-ip-icn-5glan.xml"/>


	<reference anchor='P4'>	<reference anchor="Sultana" target="https://flightplan.cis.upenn.edu/fligh
	<front>	tplan.pdf">
	<title>P4: programming protocol-independent packet processors</title>	<front>
	<author fullname='Pat Bosshart' initials='P.' surname='Bosshart'>	<title>Flightplan: Dataplane Disaggregation and Placement for P4 Progr
	<organization>Barefoot Networks, Palo Alto, CA, USA</organization>	ams</title>
	</author>	<author initials="N." surname="Sultana">
	<author fullname='Dan Daly' initials='D.' surname='Daly'>	<organization/>
	<organization>Intel, Ann Arbor, MI, USA</organization>	</author>
	</author>	<author initials="J." surname="Sonchack">
	<author fullname='Glen Gibb' initials='G.' surname='Gibb'>	<organization/>
	<organization>Barefoot Networks, Palo Alto, CA, USA</organization>	</author>
	</author>	<author initials="H." surname="Giesen">
	<author fullname='Martin Izzard' initials='M.' surname='Izzard'>	<organization/>
	<organization>Barefoot Networks, Palo Alto, CA, USA</organization>	</author>
	</author>	<author initials="I." surname="Pedisich">
	<author fullname='Nick McKeown' initials='N.' surname='McKeown'>	<organization/>
	<organization>Stanford University, Stanford, CA, USA</organization>	</author>
	</author>	<author initials="Z." surname="Han">
	<author fullname='Jennifer Rexford' initials='J.' surname='Rexford'>	<organization/>
	<organization>Princeton University, Princeton, NJ, USA</organization>	</author>
	</author>	<author initials="N." surname="Shyamkumar">
	<author fullname='Cole Schlesinger' initials='C.' surname='Schlesinger'>	<organization/>
	<organization>Princeton University, Princeton, NJ, USA</organization>	</author>
	</author>	<author initials="S." surname="Burad">
	<author fullname='Dan Talayco' initials='D.' surname='Talayco'>	<organization/>
	<organization>Barefoot Networks, Palo Alto, CA, USA</organization>	</author>
	</author>	<author initials="A." surname="DeHon">
	<author fullname='Amin Vahdat' initials='A.' surname='Vahdat'>	<organization/>
	<organization>Google, Mountain View, CA, USA</organization>	</author>
	</author>	<author initials="B. T." surname="Loo">
	<author fullname='George Varghese' initials='G.' surname='Varghese'>	<organization/>
	<organization>Microsoft Research, Mountain View, CA, USA</organization>	</author>
	</author>	</front>
	<author fullname='David Walker' initials='D.' surname='Walker'>	</reference>
	<organization>Princeton University, Princeton, NJ, USA</organization>
	</author>
	<date month='July' year='2014'/>
	</front>
	<seriesInfo name='ACM SIGCOMM Computer Communication Review' value='vol. 44, n
	o. 3, pp. 87-95'/>
	<seriesInfo name='DOI' value='10.1145/2656877.2656890'/>
	</reference>


	<reference anchor="GRPC" target="https://grpc.io/">	<!-- [ETSI] -->
	<front>	<reference anchor="ETSI" target="https://www.etsi.org/technologies/multi-a
	<title>High performance open source universal RPC framework</title>	ccess-edge-computing">
	<author >	<front>
	<organization></organization>	<title>Multi-access Edge Computing (MEC)</title>
	</author>	<author initials="" surname="ETSI" fullname="ETSI">
	<date />	<organization/>
	</front>	</author>
	</reference>	</front>
	<reference anchor="MPI" target="https://arxiv.org/pdf/1603.02339.pdf">	</reference>
	<front>
	<title>Scaling Distributed Machine Learning with In-Network Aggregation</tit
	le>
	<author initials="A." surname="Vishnu">
	<organization></organization>
	</author>
	<author initials="C." surname="Siegel">
	<organization></organization>
	</author>
	<author initials="J." surname="Daily">
	<organization></organization>
	</author>
	<date />
	</front>
	</reference>
	<reference anchor="FCDN" target="https://arxiv.org/pdf/1803.00876.pdf">
	<front>
	<title>A Flexible and Efficient CDN Infrastructure without DNS Redirection o
	f Content Reflection</title>
	<author initials="M." surname="Al-Naday">
	<organization></organization>
	</author>
	<author initials="M. J." surname="Reed">
	<organization></organization>
	</author>
	<author initials="J." surname="Riihijarvi">
	<organization></organization>
	</author>
	<author initials="D." surname="Trossen">
	<organization></organization>
	</author>
	<author initials="N." surname="Thomos">
	<organization></organization>
	</author>
	<author initials="M." surname="Al-Khalidi">
	<organization></organization>
	</author>
	<date />
	</front>
	</reference>


	<reference anchor='I-D.ravi-icnrg-5gc-icn'>	<!-- [Microservices] -->
	<front>	<reference anchor="Microservices" target="https://microservices.io/">
	<title>Enabling ICN in 3GPP's 5G NextGen Core Architecture</title>	<front>
	<author fullname='Ravi Ravindran' initials='R.' surname='Ravindran'>	<title>What are microservices?</title>
	<organization>Futurewei Technologies</organization>	<author initials="C." surname="Richardson">
	</author>	<organization/>
	<author fullname='Prakash Suthar' initials='P.' surname='Suthar'>	</author>
	<organization>Cisco Systems</organization>	</front>
	</author>	</reference>
	<author fullname='Dirk Trossen' initials='D.' surname='Trossen'>
	<organization>InterDigital Inc.</organization>
	</author>
	<author fullname='Chonggang Wang' initials='C.' surname='Wang'>
	<organization>InterDigital Inc.</organization>
	</author>
	<author fullname='Greg White' initials='G.' surname='White'>
	<organization>CableLabs</organization>
	</author>
	<date day='31' month='May' year='2019'/>
	<abstract>
	<t> The proposed 3GPP's 5G core nextgen architecture (5GC) offers
	flexibility to introduce new user and control plane function,
	considering the support for network slicing functions, that allows
	greater flexibility to handle heterogeneous devices and applications.
	In this draft, we provide a short description of the proposed 5GC
	architecture, including recent efforts to provide cellular Local Area
	Network (LAN) connectivity, followed by extensions to 5GC's control
	and user plane to support Packet Data Unit (PDU) sessions from
	Information-Centric Networks (ICN). In addition, ICN over 5GLAN is
	also described.


	</t>	<!-- [GSLB] -->
	</abstract>	<reference anchor="GSLB" target="https://www.cloudflare.com/learning/cdn/g
	</front>	lossary/global-server-load-balancing-gslb/">
	<seriesInfo name='Internet-Draft' value='draft-ravi-icnrg-5gc-icn-04'/>	<front>
		<title>What is global server load balancing (GSLB)?</title>
		<author>
		<organization>Cloudflare</organization>
		</author>
		</front>
		</reference>


	</reference>	<!-- [L2Virt] -->
		<reference anchor="L2Virt" target="https://blogs.oracle.com/cloud-infrastr
		ucture/post/first-principles-l2-network-virtualization-for-lift-and-shift">
		<front>
		<title>First principles: L2 network virtualization for lift and shift<
		/title>
		<author initials="L." surname="Kreger-Stickles">
		<organization/>
		</author>
		<date day="9" month="February" year="2021"/>
		</front>
		<refcontent>Oracle Cloud Infrastructure Blog</refcontent>
		</reference>


	<reference anchor='I-D.hsingh-coinrg-reqs-p4comp'>	<!-- [TOSCA] -->
	<front>	<reference anchor="TOSCA" target="https://docs.oasis-open.org/tosca/TOSCA-
	<title>Requirements for P4 Program Splitting for Heterogeneous Network Nod	Simple-Profile-YAML/v1.3/os/TOSCA-Simple-Profile-YAML-v1.3-os.pdf">
	es</title>	<front>
	<author fullname='Hemant Singh' initials='H.' surname='Singh'>	<title>TOSCA Simple Profile in YAML Version 1.3</title>
	<organization>MNK Labs and Consulting</organization>	<author fullname="Matt Rutkowski" role="editor"/>
	</author>	<author fullname="Chris Lauwers" role="editor"/>
	<author fullname='Marie-Jose Montpetit' initials='M.' surname='Montpetit'>	<author fullname="Claude Noshpitz" role="editor"/>
	<organization>Concordia Univeristy</organization>	<author fullname="Calin Curescu" role="editor"/>
	</author>	<date month="February" year="2020"/>
	<date day='18' month='February' year='2021'/>	</front>
	<abstract>	<refcontent>OASIS Standard</refcontent>
	<t> For distributed computing, the P4 research community has published	</reference>
	a
	paper to show how to split a P4 program into sub-programs which run
	on heterogeneous network nodes in a network. Examples of nodes are a
	network switch, a smartNIC, or a host machine. The paper has
	developed artifacts to split program based on latency, data rate,
	cost, etc. However, the paper does not mention any requirements. To
	provide guidance, this document covers requirements for splitting P4
	programs for heterogeneous network nodes.


	</t>	<!-- [FLOWER] -->
	</abstract>	<reference anchor="FLOWER" target="https://flower.ai/">
	</front>	<front>
	<seriesInfo name='Internet-Draft' value='draft-hsingh-coinrg-reqs-p4comp-03'/	<title>A Friendly Federated AI Framework</title>
	>	<author initials="" surname="Flower Labs GmbH">
		<organization/>
		</author>
		</front>
		</reference>


	</reference>	<!-- [KUNZE-APPLICABILITY] -->
		<reference anchor="KUNZE-APPLICABILITY">
		<front>
		<title>Investigating the Applicability of In-Network Computing to Indu
		strial Scenarios</title>
		<author fullname="Ike Kunze" initials="I." surname="Kunze">
		<organization/>
		</author>
		<author fullname="Rene Glebke" initials="R." surname="Glebke">
		<organization/>
		</author>
		<author fullname="Jan Scheiper" initials="J." surname="Scheiper">
		<organization/>
		</author>
		<author fullname="Matthias Bodenbenner" initials="M." surname="Bodenbe
		nner">
		<organization/>
		</author>
		<author fullname="Robert H. Schmitt" initials="R." surname="Schmitt">
		<organization/>
		</author>
		<author fullname="Klaus Wehrle" initials="K." surname="Wehrle">
		<organization/>
		</author>
		<date month="May" year="2021"/>
		</front>
		<refcontent>2021 4th IEEE International Conference on Industrial Cyber-P
		hysical Systems (ICPS), pp. 334-340</refcontent>
		<seriesInfo name="DOI" value="10.1109/icps49255.2021.9468247"/>
		</reference>


	<reference anchor="Stoyanov" target="https://eng.ox.ac.uk/media/6354/stoyanov202	<!-- [KUNZE-SIGNAL] -->
	0mtpsa.pdf">	<reference anchor="KUNZE-SIGNAL">
	<front>	<front>
	<title>MTPSA: Multi-Tenant Programmable Switches</title>	<title>Detecting Out-Of-Control Sensor Signals in Sheet Metal Forming
	<author initials="R." surname="Stoyanov">	using In-Network Computing</title>
	<organization></organization>	<author fullname="Ike Kunze" initials="I." surname="Kunze">
	</author>	<organization>Communication and Distributed Systems</organization>
	<author initials="N." surname="Zilberman">	</author>
	<organization></organization>	<author fullname="Philipp Niemietz" initials="P." surname="Niemietz">
	</author>	<organization>Laboratory for Machine Tools and Production Engineerin
	<date year="2020"/>	g (WZL)</organization>
	</front>	</author>
	<seriesInfo name="ACM P4 Workshop in Europe (EuroP4'20)" value=""/>	<author fullname="Liam Tirpitz" initials="L." surname="Tirpitz">
	</reference>	<organization>Communication and Distributed Systems</organization>
	<reference anchor="TS23.501" target="https://www.3gpp.org/DynaReport/23501.htm">	</author>
	<front>	<author fullname="Rene Glebke" initials="R." surname="Glebke">
	<title>Technical Specification Group Services and System Aspects; System Arc	<organization>Communication and Distributed Systems</organization>
	hitecture for the 5G System; Stage 2 (Rel.17)</title>	</author>
	<author initials="" surname="3gpp-23.501" fullname="3gpp-23.501">	<author fullname="Daniel Trauth" initials="D." surname="Trauth">
	<organization></organization>	<organization>Laboratory for Machine Tools and Production Engineerin
	</author>	g (WZL)</organization>
	<date year="2021"/>	</author>
	</front>	<author fullname="Thomas Bergs" initials="T." surname="Bergs">
	<seriesInfo name="3GPP" value=""/>	<organization>Laboratory for Machine Tools and Production Engineerin
	</reference>	g (WZL)</organization>
	<reference anchor="TS23.502" target="https://www.3gpp.org/DynaReport/23502.htm">	</author>
	<front>	<author fullname="Klaus Wehrle" initials="K." surname="Wehrle">
	<title>Technical Specification Group Services and System Aspects; Procedures	<organization>Communication and Distributed Systems</organization>
	for the 5G System; Stage 2 (Rel.17)</title>	</author>
	<author initials="" surname="3gpp-23.502" fullname="3gpp-23.502">	<date month="June" year="2021"/>
	<organization></organization>	</front>
	</author>	<refcontent>2021 IEEE 30th International Symposium on Industrial Electro
	<date year="2021"/>	nics (ISIE), pp. 1-6</refcontent>
	</front>	<seriesInfo name="DOI" value="10.1109/isie45552.2021.9576221"/>
	<seriesInfo name="3GPP" value=""/>	</reference>
	</reference>
	<reference anchor="SA2-5GLAN" target="http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs
	/SP-181120.zip">
	<front>
	<title>SP-181129, Work Item Description, Vertical_LAN(SA2), 5GS Enhanced Sup
	port of Vertical and LAN Services</title>
	<author initials="" surname="3GPP-5glan" fullname="3GPP-5glan">
	<organization></organization>
	</author>
	<date year="2021"/>
	</front>
	<seriesInfo name="3GPP" value=""/>
	</reference>


	<reference anchor='ICN5GLAN'>	<!-- [SarNet2021] -->
	<front>	<reference anchor="SarNet2021">
	<title>IP-based Services over ICN in 5G LAN Environments</title>	<front>
	<author fullname='Dirk Trossen' initials='D.' surname='Trossen'>	<title>Service-based Forwarding via Programmable Dataplanes</title>
	<organization>InterDigital Inc.</organization>	<author fullname="Rene Glebke" initials="R." surname="Glebke">
	</author>	<organization/>
	<author fullname='Chonggang Wang' initials='C.' surname='Wang'>	</author>
	<organization>InterDigital Inc.</organization>	<author fullname="Dirk Trossen" initials="D." surname="Trossen">
	</author>	<organization/>
	<author fullname='Sebastian Robitzsch' initials='S.' surname='Robitzsch'>	</author>
	<organization>InterDigital Inc.</organization>	<author fullname="Ike Kunze" initials="I." surname="Kunze">
	</author>	<organization/>
	<author fullname='Martin Reed' initials='M.' surname='Reed'>	</author>
	<organization>Essex University</organization>	<author fullname="David Lou" initials="D." surname="Lou">
	</author>	<organization/>
	<author fullname='Mays AL-Naday' initials='M.' surname='AL-Naday'>	</author>
	<organization>Essex University</organization>	<author fullname="Jan Ruth" initials="J." surname="Ruth">
	</author>	<organization/>
	<author fullname='Janne Riihijarvi' initials='J.' surname='Riihijarvi'>	</author>
	<organization>RWTH Aachen</organization>	<author fullname="Mirko Stoffers" initials="M." surname="Stoffers">
	</author>	<organization/>
	<date day='6' month='June' year='2019'/>	</author>
	<abstract>	<author fullname="Klaus Wehrle" initials="K." surname="Wehrle">
	<t> In this draft, we provide architecture and operations for enabling	<organization/>
	IP	</author>
	services over ICN over (5G-enabled) LAN environments. Operations	<date month="June" year="2021"/>
	include ICN API to upper layers, HTTP over ICN, Service Proxy	</front>
	Operations, ICN Flow Management, Name Resolution, Mobility Handling,	<refcontent>2021 IEEE 22nd International Conference on High Performance
	and Dual Stack Device Support.	Switching and Routing (HPSR), pp. 1-8</refcontent>
		<seriesInfo name="DOI" value="10.1109/hpsr52026.2021.9481814"/>
		</reference>


	</t>	<!-- [Multi2020] -->
	</abstract>	<reference anchor="Multi2020">
	</front>	<front>
	<seriesInfo name='Internet-Draft' value='draft-trossen-icnrg-ip-icn-5glan-00'	<title>Routing on Multiple Optimality Criteria</title>
	/>	<author fullname="João Luís Sobrinho" initials="J." surname="Sobrinho"
		>
		<organization>Instituto de Telecomunicações, Instituto Superior Tecn
		ico, Universidade de Lisboa</organization>
		</author>
		<author fullname="Miguel Alves Ferreira" initials="M." surname="Ferrei
		ra">
		<organization>Instituto de Telecomunicações, Instituto Superior Tecn
		ico, Universidade de Lisboa</organization>
		</author>
		<date month="July" year="2020"/>
		</front>
		<refcontent>Proceedings of the Annual conference of the ACM Special Inte
		rest Group on Data Communication on the applications, technologies, architecture
		s, and protocols for computer communication, pp. 211-225</refcontent>
		<seriesInfo name="DOI" value="10.1145/3387514.3405864"/>
		</reference>


	</reference>	<!-- [SILKROAD] -->
		<reference anchor="SILKROAD">
		<front>
		<title>SilkRoad: Making Stateful Layer-4 Load Balancing Fast and Cheap
		Using Switching ASICs</title>
		<author fullname="Rui Miao" initials="R." surname="Miao">
		<organization>University of Southern California</organization>
		</author>
		<author fullname="Hongyi Zeng" initials="H." surname="Zeng">
		<organization>Facebook</organization>
		</author>
		<author fullname="Changhoon Kim" initials="C." surname="Kim">
		<organization>Barefoot Networks</organization>
		</author>
		<author fullname="Jeongkeun Lee" initials="J." surname="Lee">
		<organization>Barefoot Networks</organization>
		</author>
		<author fullname="Minlan Yu" initials="M." surname="Yu">
		<organization>Yale University</organization>
		</author>
		<date month="August" year="2017"/>
		</front>
		<refcontent>Proceedings of the Conference of the ACM Special Interest Gr
		oup on Data Communication, pp. 15-28</refcontent>
		<seriesInfo name="DOI" value="10.1145/3098822.3098824"/>
		</reference>


	<reference anchor="Sultana" target="https://flightplan.cis.upenn.edu/flightplan.	<!-- [GREENAI] -->
	pdf">	<reference anchor="GREENAI">
	<front>	<front>
	<title>Flightplan: Dataplane Disaggregation and Placement for P4 Programs</t	<title>A Safe Genetic Algorithm Approach for Energy Efficient Federate
	itle>	d Learning in Wireless Communication Networks</title>
	<author initials="N." surname="Sultana">	<author fullname="Lina Magoula" initials="L." surname="Magoula">
	<organization></organization>	<organization>National and Kapodistrian University of Athens,Dept. o
	</author>	f Informatics and Telecommunications,Greece</organization>
	<author initials="J." surname="Sonchack">	</author>
	<organization></organization>	<author fullname="Nikolaos Koursioumpas" initials="N." surname="Koursi
	</author>	oumpas">
	<author initials="H." surname="Giesen">	<organization>National and Kapodistrian University of Athens,Dept. o
	<organization></organization>	f Informatics and Telecommunications,Greece</organization>
	</author>	</author>
	<author initials="I." surname="Pedisich">	<author fullname="Alexandros-Ioannis Thanopoulos" initials="A." surnam
	<organization></organization>	e="Thanopoulos">
	</author>	<organization>National and Kapodistrian University of Athens,Dept. o
	<author initials="Z." surname="Han">	f Informatics and Telecommunications,Greece</organization>
	<organization></organization>	</author>
	</author>	<author fullname="Theodora Panagea" initials="T." surname="Panagea">
	<author initials="N." surname="Shyamkumar">	<organization>National and Kapodistrian University of Athens,Dept. o
	<organization></organization>	f Informatics and Telecommunications,Greece</organization>
	</author>	</author>
	<author initials="S." surname="Burad">	<author fullname="Nikolaos Petropouleas" initials="N." surname="Petrop
	<organization></organization>	ouleas">
	</author>	<organization>National and Kapodistrian University of Athens,Dept. o
	<author initials="A." surname="DeHon">	f Informatics and Telecommunications,Greece</organization>
	<organization></organization>	</author>
	</author>	<author fullname="M. A. Gutierrez-Estevez" initials="M." surname="Guti
	<author initials="B. T." surname="Loo">	errez-Estevez">
	<organization></organization>	<organization>Huawei Technologies Duesseldorf GmbH,Munich Research C
	</author>	enter,Munich,Germany</organization>
	<date year="2020"/>	</author>
	</front>	<author fullname="Ramin Khalili" initials="R." surname="Khalili">
	</reference>	<organization>Huawei Technologies Duesseldorf GmbH,Munich Research C
	<reference anchor="ETSI" target="https://www.etsi.org/technologies/multi-access-	enter,Munich,Germany</organization>
	edge-computing">	</author>
	<front>	<date month="September" year="2023"/>
	<title>Multi-access Edge Computing (MEC)</title>	</front>
	<author initials="" surname="ETSI" fullname="ETSI">	<refcontent>2023 IEEE 34th Annual International Symposium on Personal, I
	<organization></organization>	ndoor and Mobile Radio Communications (PIMRC), pp. 1-6</refcontent>
	</author>	<seriesInfo name="DOI" value="10.1109/pimrc56721.2023.10293863"/>
	<date year="2022"/>	</reference>
	</front>
	</reference>
	<reference anchor="Microservices" target="https://microservices.io/">
	<front>
	<title>What are microservices?</title>
	<author initials="C." surname="Richardson">
	<organization></organization>
	</author>
	<date year="2024"/>
	</front>
	</reference>
	<reference anchor="GSLB" target="https://www.cloudflare.com/learning/cdn/glossar
	y/global-server-load-balancing-gslb/">
	<front>
	<title>What is global server load balancing (GSLB)?</title>
	<author initials="" surname="Cloudflare" fullname="Cloudflare">
	<organization></organization>
	</author>
	<date year="2022"/>
	</front>
	</reference>
	<reference anchor="L2Virt" target="https://blogs.oracle.com/cloud-infrastructure
	/post/first-principles-l2-network-virtualization-for-lift-and-shift">
	<front>
	<title>First principles: L2 network virtualization for lift and shift</title
	>
	<author initials="L." surname="Kreger-Stickles">
	<organization></organization>
	</author>
	<date year="2022"/>
	</front>
	</reference>
	<reference anchor="TOSCA" target="https://docs.oasis-open.org/tosca/TOSCA-Simple
	-Profile-YAML/v1.3/os/TOSCA-Simple-Profile-YAML-v1.3-os.pdf">
	<front>
	<title>TOSCA Simple Profile in YAML Version 1.3</title>
	<author initials="" surname="OASIS TOSCA">
	<organization></organization>
	</author>
	<date year="2020"/>
	</front>
	</reference>
	<reference anchor="FLOWER" target="https://flower.ai/">
	<front>
	<title>A Friendly Federated AI Framework</title>
	<author initials="" surname="Flower Labs GmbH">
	<organization></organization>
	</author>
	<date year="2024"/>
	</front>
	</reference>


	<reference anchor='KUNZE-APPLICABILITY'>	<!-- [TLSSURVEY] -->
	<front>	<reference anchor="TLSSURVEY">
	<title>Investigating the Applicability of In-Network Computing to Industrial	<front>
	Scenarios</title>	<title>A Survey and Analysis of TLS Interception Mechanisms and Motiva
	<author fullname='Ike Kunze' initials='I.' surname='Kunze'>	tions: Exploring how end-to-end TLS is made 'end-to-me' for web traffic</title>
	<organization/>	<author fullname="Xavier de Carné de Carnavalet" initials="X." surname
	</author>	="de Carné de Carnavalet">
	<author fullname='Rene Glebke' initials='R.' surname='Glebke'>	<organization>The Hong Kong Polytechnic University, Hong Kong SAR</o
	<organization/>	rganization>
	</author>	</author>
	<author fullname='Jan Scheiper' initials='J.' surname='Scheiper'>	<author fullname="Paul C. van Oorschot" initials="P." surname="van Oor
	<organization/>	schot">
	</author>	<organization>Carleton University, Ontario, Canada</organization>
	<author fullname='Matthias Bodenbenner' initials='M.' surname='Bodenbenner'>	</author>
	<organization/>	<date month="July" year="2023"/>
	</author>	</front>
	<author fullname='Robert H. Schmitt' initials='R.' surname='Schmitt'>	<refcontent>ACM Computing Surveys, vol. 55, no. 13s, pp. 1-40</refconten
	<organization/>	t>
	</author>	<seriesInfo name="DOI" value="10.1145/3580522"/>
	<author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'>	</reference>
	<organization/>
	</author>
	<date month='May' year='2021'/>
	</front>
	<seriesInfo name='2021 4th IEEE International Conference on Industrial Cyber-P
	hysical Systems (ICPS)' value='pp. 334-340'/>
	<seriesInfo name='DOI' value='10.1109/icps49255.2021.9468247'/>
	</reference>


	<reference anchor='KUNZE-SIGNAL'>	<!-- [MADTLS] -->
	<front>	<reference anchor="MADTLS">
	<title>Detecting Out-Of-Control Sensor Signals in Sheet Metal Forming using	<front>
	In-Network Computing</title>	<title>Madtls: Fine-grained Middlebox-aware End-to-end Security for In
	<author fullname='Ike Kunze' initials='I.' surname='Kunze'>	dustrial Communication</title>
	<organization>Communication and Distributed Systems</organization>	<author fullname="Eric Wagner" initials="E." surname="Wagner">
	</author>	<organization/>
	<author fullname='Philipp Niemietz' initials='P.' surname='Niemietz'>	</author>
	<organization>Laboratory for Machine Tools and Production Engineering (WZL	<author fullname="David Heye" initials="D." surname="Heye">
	)</organization>	<organization/>
	</author>	</author>
	<author fullname='Liam Tirpitz' initials='L.' surname='Tirpitz'>	<author fullname="Martin Serror" initials="M." surname="Serror">
	<organization>Communication and Distributed Systems</organization>	<organization/>
	</author>	</author>
	<author fullname='Rene Glebke' initials='R.' surname='Glebke'>	<author fullname="Ike Kunze" initials="I." surname="Kunze">
	<organization>Communication and Distributed Systems</organization>	<organization/>
	</author>	</author>
	<author fullname='Daniel Trauth' initials='D.' surname='Trauth'>	<author fullname="Klaus Wehrle" initials="K." surname="Wehrle">
	<organization>Laboratory for Machine Tools and Production Engineering (WZL	<organization/>
	)</organization>	</author>
	</author>	<author fullname="Martin Henze" initials="M." surname="Henze">
	<author fullname='Thomas Bergs' initials='T.' surname='Bergs'>	<organization/>
	<organization>Laboratory for Machine Tools and Production Engineering (WZL	</author>
	)</organization>	<date year="2023"/>
	</author>	</front>
	<author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'>	<seriesInfo name="DOI" value="10.48550/ARXIV.2312.09650"/>
	<organization>Communication and Distributed Systems</organization>	<refcontent>arXiv:2312.09650</refcontent>
	</author>	</reference>
	<date month='June' year='2021'/>
	</front>
	<seriesInfo name='2021 IEEE 30th International Symposium on Industrial Electro
	nics (ISIE)' value='pp. 1-6'/>
	<seriesInfo name='DOI' value='10.1109/isie45552.2021.9576221'/>
	</reference>


	<reference anchor='SarNet2021'>	<!-- [SPLITTLS] -->
	<front>	<reference anchor="SPLITTLS">
	<title>Service-based Forwarding via Programmable Dataplanes</title>	<front>
	<author fullname='Rene Glebke' initials='R.' surname='Glebke'>	<title>Multi-Context TLS (mcTLS): Enabling Secure In-Network Functiona
	<organization/>	lity in TLS</title>
	</author>	<author fullname="David Naylor" initials="D." surname="Naylor">
	<author fullname='Dirk Trossen' initials='D.' surname='Trossen'>	<organization>Carnegie Mellon University, Pittsburgh, PA, USA</organ
	<organization/>	ization>
	</author>	</author>
	<author fullname='Ike Kunze' initials='I.' surname='Kunze'>	<author fullname="Kyle Schomp" initials="K." surname="Schomp">
	<organization/>	<organization>Case Western Reserve University, Cleveland, OH, USA</o
	</author>	rganization>
	<author fullname='David Lou' initials='D.' surname='Lou'>	</author>
	<organization/>	<author fullname="Matteo Varvello" initials="M." surname="Varvello">
	</author>	<organization>Telefonica Research, Barcelona, Spain</organization>
	<author fullname='Jan Rueth' initials='J.' surname='Rueth'>	</author>
	<organization/>	<author fullname="Ilias Leontiadis" initials="I." surname="Leontiadis"
	</author>	>
	<author fullname='Mirko Stoffers' initials='M.' surname='Stoffers'>	<organization>Telefonica Research, Barcelona, Spain</organization>
	<organization/>	</author>
	</author>	<author fullname="Jeremy Blackburn" initials="J." surname="Blackburn">
	<author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'>	<organization>Telefonica Research, Barcelona, USA</organization>
	<organization/>	</author>
	</author>	<author fullname="Diego R. Lopez" initials="D." surname="Lopez">
	<date month='June' year='2021'/>	<organization>Telefonica, Barcelona, Spain</organization>
	</front>	</author>
	<seriesInfo name='2021 IEEE 22nd International Conference on High Performance	<author fullname="Konstantina Papagiannaki" initials="K." surname="Pap
	Switching and Routing (HPSR)' value='pp. 1-8'/>	agiannaki">
	<seriesInfo name='DOI' value='10.1109/hpsr52026.2021.9481814'/>	<organization>Telefonica Research, Barcelona, Spain</organization>
	</reference>	</author>
		<author fullname="Pablo Rodriguez Rodriguez" initials="P." surname="Ro
		driguez Rodriguez">
		<organization>Telefonica Research, Barcelona, Spain</organization>
		</author>
		<author fullname="Peter Steenkiste" initials="P." surname="Steenkiste"
		>
		<organization>Carnegie Mellon University, Pittsburgh, PA, USA</organ
		ization>
		</author>
		<date month="August" year="2015"/>
		</front>
		<refcontent>ACM SIGCOMM Computer Communication Review, vol. 45, no. 4, p
		p. 199-212</refcontent>
		<seriesInfo name="DOI" value="10.1145/2829988.2787482"/>
		</reference>


	<reference anchor='Multi2020'>	<!-- [MASTODON] -->
	<front>	<reference anchor="MASTODON">
	<title>Routing on Multiple Optimality Criteria</title>	<front>
	<author fullname='João Luís Sobrinho' initials='J.' surname='Sobrinho'>	<title>Challenges in the Decentralised Web: The Mastodon Case</title>
	<organization>Instituto de Telecomunicações, Instituto Superior Tecnico, U	<author fullname="Aravindh Raman" initials="A." surname="Raman">
	niversidade de Lisboa</organization>	<organization>King's College London</organization>
	</author>	</author>
	<author fullname='Miguel Alves Ferreira' initials='M.' surname='Ferreira'>	<author fullname="Sagar Joglekar" initials="S." surname="Joglekar">
	<organization>Instituto de Telecomunicações, Instituto Superior Tecnico, U	<organization>King's College London</organization>
	niversidade de Lisboa</organization>	</author>
	</author>	<author fullname="Emiliano De Cristofaro" initials="E." surname="Crist
	<date month='July' year='2020'/>	ofaro">
	</front>	<organization>University College London</organization>
	<seriesInfo name='Proceedings of the Annual conference of the ACM Special Inte	</author>
	rest Group on Data Communication on the applications, technologies, architecture	<author fullname="Nishanth Sastry" initials="N." surname="Sastry">
	s, and protocols for computer communication' value='pp. 211-225'/>	<organization>King's College London</organization>
	<seriesInfo name='DOI' value='10.1145/3387514.3405864'/>	</author>
	</reference>	<author fullname="Gareth Tyson" initials="G." surname="Tyson">
		<organization>Queen Mary University of London</organization>
		</author>
		<date month="October" year="2019"/>
		</front>
		<refcontent>Proceedings of the Internet Measurement Conference, pp. 217-
		229</refcontent>
		<seriesInfo name="DOI" value="10.1145/3355369.3355572"/>
		</reference>


	<reference anchor='SILKROAD'>	<!-- [eCAR] -->
	<front>	<reference anchor="eCAR">
	<title>SilkRoad: Making Stateful Layer-4 Load Balancing Fast and Cheap Using	<front>
	Switching ASICs</title>	<title>eCAR: edge-assisted Collaborative Augmented Reality Framework</
	<author fullname='Rui Miao' initials='R.' surname='Miao'>	title>
	<organization>University of Southern California</organization>	<author fullname="Jinwoo Jeon" initials="J." surname="Jeon">
	</author>	<organization/>
	<author fullname='Hongyi Zeng' initials='H.' surname='Zeng'>	</author>
	<organization>Facebook</organization>	<author fullname="Woontack Woo" initials="W." surname="Woo">
	</author>	<organization/>
	<author fullname='Changhoon Kim' initials='C.' surname='Kim'>	</author>
	<organization>Barefoot Networks</organization>	<date year="2024"/>
	</author>	</front>
	<author fullname='Jeongkeun Lee' initials='J.' surname='Lee'>	<refcontent>arXiv:2405.06872</refcontent>
	<organization>Barefoot Networks</organization>	<seriesInfo name="DOI" value="10.48550/ARXIV.2405.06872"/>
	</author>	</reference>
	<author fullname='Minlan Yu' initials='M.' surname='Yu'>
	<organization>Yale University</organization>
	</author>
	<date month='August' year='2017'/>
	</front>
	<seriesInfo name='Proceedings of the Conference of the ACM Special Interest Gr
	oup on Data Communication' value='pp. 15-28'/>
	<seriesInfo name='DOI' value='10.1145/3098822.3098824'/>
	</reference>


	<reference anchor='GREENAI'>	<!-- [NetworkedVR] -->
	<front>	<reference anchor="NetworkedVR">
	<title>A Safe Genetic Algorithm Approach for Energy Efficient Federated Lear	<front>
	ning in Wireless Communication Networks</title>	<title>Networked VR: State of the Art, Solutions, and Challenges</titl
	<author fullname='Lina Magoula' initials='L.' surname='Magoula'>	e>
	<organization>National and Kapodistrian University of Athens,Dept. of Info	<author fullname="Jinjia Ruan" initials="J." surname="Ruan">
	rmatics and Telecommunications,Greece</organization>	<organization>State Key Laboratory of Networking and Switching Techn
	</author>	ology, Beijing University of Posts and Telecommunications, Beijing 100876, China
	<author fullname='Nikolaos Koursioumpas' initials='N.' surname='Koursioumpas	</organization>
	'>	</author>
	<organization>National and Kapodistrian University of Athens,Dept. of Info	<author fullname="Dongliang Xie" initials="D." surname="Xie">
	rmatics and Telecommunications,Greece</organization>	<organization>State Key Laboratory of Networking and Switching Techn
	</author>	ology, Beijing University of Posts and Telecommunications, Beijing 100876, China
	<author fullname='Alexandros-Ioannis Thanopoulos' initials='A.' surname='Tha	</organization>
	nopoulos'>	</author>
	<organization>National and Kapodistrian University of Athens,Dept. of Info	<date month="January" year="2021"/>
	rmatics and Telecommunications,Greece</organization>	</front>
	</author>	<refcontent>Electronics, vol. 10, no. 2, p. 166</refcontent>
	<author fullname='Theodora Panagea' initials='T.' surname='Panagea'>	<seriesInfo name="DOI" value="10.3390/electronics10020166"/>
	<organization>National and Kapodistrian University of Athens,Dept. of Info	</reference>
	rmatics and Telecommunications,Greece</organization>
	</author>
	<author fullname='Nikolaos Petropouleas' initials='N.' surname='Petropouleas
	'>
	<organization>National and Kapodistrian University of Athens,Dept. of Info
	rmatics and Telecommunications,Greece</organization>
	</author>
	<author fullname='M. A. Gutierrez-Estevez' initials='M.' surname='Gutierrez-
	Estevez'>
	<organization>Huawei Technologies Duesseldorf GmbH,Munich Research Center,
	Munich,Germany</organization>
	</author>
	<author fullname='Ramin Khalili' initials='R.' surname='Khalili'>
	<organization>Huawei Technologies Duesseldorf GmbH,Munich Research Center,
	Munich,Germany</organization>
	</author>
	<date month='September' year='2023'/>
	</front>
	<seriesInfo name='2023 IEEE 34th Annual International Symposium on Personal, I
	ndoor and Mobile Radio Communications (PIMRC)' value='pp. 1-6'/>
	<seriesInfo name='DOI' value='10.1109/pimrc56721.2023.10293863'/>
	</reference>


	<reference anchor='TLSSURVEY'>	<!-- [CompNet2021] -->
	<front>	<reference anchor="CompNet2021">
	<title>A Survey and Analysis of TLS Interception Mechanisms and Motivations:	<front>
	Exploring how end-to-end TLS is made "end-to-me" for web traffic</title>	<title>Edge intelligence computing for mobile augmented reality with d
	<author fullname='Xavier de Carne de Carnavalet' initials='X.' surname='de C	eep reinforcement learning approach</title>
	arne de Carnavalet'>	<author fullname="Miaojiang Chen" initials="M." surname="Chen">
	<organization>The Hong Kong Polytechnic University, Hong Kong SAR</organiz	<organization/>
	ation>	</author>
	</author>	<author fullname="Wei Liu" initials="W." surname="Liu">
	<author fullname='Paul C. van Oorschot' initials='P.' surname='van Oorschot'	<organization/>
	>	</author>
	<organization>Carleton University, Ontario, Canada</organization>	<author fullname="Tian Wang" initials="T." surname="Wang">
	</author>	<organization/>
	<date month='July' year='2023'/>	</author>
	</front>	<author fullname="Anfeng Liu" initials="A." surname="Liu">
	<seriesInfo name='ACM Computing Surveys' value='vol. 55, no. 13s, pp. 1-40'/>	<organization/>
	<seriesInfo name='DOI' value='10.1145/3580522'/>	</author>
	</reference>	<author fullname="Zhiwen Zeng" initials="Z." surname="Zeng">
		<organization/>
		</author>
		<date month="August" year="2021"/>
		</front>
		<seriesInfo name="DOI" value="10.1016/j.comnet.2021.108186"/>
		<refcontent>Computer Networks, vol. 195, p. 108186</refcontent>
		</reference>


	<reference anchor='MADTLS'>	<!-- [WirelessNet2024] -->
	<front>	<reference anchor="WirelessNet2024">
	<title>Madtls: Fine-grained Middlebox-aware End-to-end Security for Industri	<front>
	al Communication</title>	<title>Online delay optimization for MEC and RIS-assisted wireless VR
	<author fullname='Eric Wagner' initials='E.' surname='Wagner'>	networks</title>
	<organization/>	<author fullname="Jie Jia" initials="J." surname="Jia">
	</author>	<organization/>
	<author fullname='David Heye' initials='D.' surname='Heye'>	</author>
	<organization/>	<author fullname="Leyou Yang" initials="L." surname="Yang">
	</author>	<organization/>
	<author fullname='Martin Serror' initials='M.' surname='Serror'>	</author>
	<organization/>	<author fullname="Jian Chen" initials="J." surname="Chen">
	</author>	<organization/>
	<author fullname='Ike Kunze' initials='I.' surname='Kunze'>	</author>
	<organization/>	<author fullname="Lidao Ma" initials="L." surname="Ma">
	</author>	<organization/>
	<author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'>	</author>
	<organization/>	<author fullname="Xingwei Wang" initials="X." surname="Wang">
	</author>	<organization/>
	<author fullname='Martin Henze' initials='M.' surname='Henze'>	</author>
	<organization/>	<date month="March" year="2024"/>
	</author>	</front>
	<date year='2023'/>	<refcontent>Wireless Networks, vol. 30, no. 4, pp. 2939-2959</refcontent
	</front>	>
	<seriesInfo name='' value='arXiv'/>	<seriesInfo name="DOI" value="10.1007/s11276-024-03706-4"/>
	<seriesInfo name='DOI' value='10.48550/ARXIV.2312.09650'/>	</reference>
	</reference>


	<reference anchor='SPLITTLS'>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.727
	<front>	2.xml"/>
	<title>Multi-Context TLS (mcTLS): Enabling Secure In-Network Functionality i	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.803
	n TLS</title>	9.xml"/>
	<author fullname='David Naylor' initials='D.' surname='Naylor'>	</references>
	<organization>Carnegie Mellon University, Pittsburgh, PA, USA</organizatio
	n>
	</author>
	<author fullname='Kyle Schomp' initials='K.' surname='Schomp'>
	<organization>Case Western Reserve University, Cleveland, OH, USA</organiz
	ation>
	</author>
	<author fullname='Matteo Varvello' initials='M.' surname='Varvello'>
	<organization>Telefonica Research, Barcelona, Spain</organization>
	</author>
	<author fullname='Ilias Leontiadis' initials='I.' surname='Leontiadis'>
	<organization>Telefonica Research, Barcelona, Spain</organization>
	</author>
	<author fullname='Jeremy Blackburn' initials='J.' surname='Blackburn'>
	<organization>Telefonica Research, Barcelona, USA</organization>
	</author>
	<author fullname='Diego R. Lopez' initials='D.' surname='Lopez'>
	<organization>Telefonica, Barcelona, Spain</organization>
	</author>
	<author fullname='Konstantina Papagiannaki' initials='K.' surname='Papagiann
	aki'>
	<organization>Telefonica Research, Barcelona, Spain</organization>
	</author>
	<author fullname='Pablo Rodriguez Rodriguez' initials='P.' surname='Rodrigue
	z Rodriguez'>
	<organization>Telefonica Research, Barcelona, Spain</organization>
	</author>
	<author fullname='Peter Steenkiste' initials='P.' surname='Steenkiste'>
	<organization>Carnegie Mellon University, Pittsburgh, PA, USA</organizatio
	n>
	</author>
	<date month='August' year='2015'/>
	</front>
	<seriesInfo name='ACM SIGCOMM Computer Communication Review' value='vol. 45, n
	o. 4, pp. 199-212'/>
	<seriesInfo name='DOI' value='10.1145/2829988.2787482'/>
	</reference>


	<reference anchor='MASTODON'>	<section anchor="acknowledgements" numbered="false">
	<front>	<name>Acknowledgements</name>
	<title>Challenges in the Decentralised Web: The Mastodon Case</title>	<t>The authors would like to thank <contact fullname="Eric Wagner"/> for
	<author fullname='Aravindh Raman' initials='A.' surname='Raman'>	providing text on the security considerations and <contact
	<organization>King's College London</organization>	fullname="Jungha Hong"/> for her efforts in continuing the work on the
	</author>	use case analysis document that has largely sourced the preliminary
	<author fullname='Sagar Joglekar' initials='S.' surname='Joglekar'>	categorization section of this document.</t>
	<organization>King's College London</organization>	<t>The authors would further like to thank <contact fullname="Chathura
	</author>	Sarathchandra"/>, <contact fullname="David Oran"/>, <contact
	<author fullname='Emiliano De Cristofaro' initials='E.' surname='Cristofaro'	fullname="Phil Eardley"/>, <contact fullname="Stuart Card"/>, <contact
	>	fullname="Jeffrey He"/>, <contact fullname="Toerless Eckert"/>, and
	<organization>University College London</organization>	<contact fullname="Jon Crowcroft"/> for reviewing earlier versions of
	</author>	the document, <contact fullname="Colin Perkins"/> for his IRTF chair
	<author fullname='Nishanth Sastry' initials='N.' surname='Sastry'>	review, and <contact fullname="Jerome Francois"/> for his thorough IRSG
	<organization>King's College London</organization>	review.</t>
	</author>	</section>
	<author fullname='Gareth Tyson' initials='G.' surname='Tyson'>	</back>
	<organization>Queen Mary University of London</organization>
	</author>
	<date month='October' year='2019'/>
	</front>
	<seriesInfo name='Proceedings of the Internet Measurement Conference' value='p
	p. 217-229'/>
	<seriesInfo name='DOI' value='10.1145/3355369.3355572'/>
	</reference>


	<reference anchor='eCAR'>	<!-- [rfced] Terminology and Abbreviations:
	<front>
	<title>eCAR: edge-assisted Collaborative Augmented Reality Framework</title>
	<author fullname='Jinwoo Jeon' initials='J.' surname='Jeon'>
	<organization/>
	</author>
	<author fullname='Woontack Woo' initials='W.' surname='Woo'>
	<organization/>
	</author>
	<date year='2024'/>
	</front>
	<seriesInfo name='arXiv' value='article'/>
	<seriesInfo name='DOI' value='10.48550/ARXIV.2405.06872'/>
	</reference>


	<reference anchor='NetworkedVR'>	a) We note different uses of (COIN) and COIN in the terms below.
	<front>	For consistency and ease of the reader, we suggest removing the
	<title>Networked VR: State of the Art, Solutions, and Challenges</title>	parentheses in "(COIN)" when it appears in these instances. Please review
	<author fullname='Jinjia Ruan' initials='J.' surname='Ruan'>	and let us know any objections.
	<organization>State Key Laboratory of Networking and Switching Technology,
	Beijing University of Posts and Telecommunications, Beijing 100876, China</orga
	nization>
	</author>
	<author fullname='Dongliang Xie' initials='D.' surname='Xie'>
	<organization>State Key Laboratory of Networking and Switching Technology,
	Beijing University of Posts and Telecommunications, Beijing 100876, China</orga
	nization>
	</author>
	<date month='January' year='2021'/>
	</front>
	<seriesInfo name='Electronics' value='vol. 10, no. 2, pp. 166'/>
	<seriesInfo name='DOI' value='10.3390/electronics10020166'/>
	</reference>


	<reference anchor='CompNet2021'>	(COIN) execution environment
	<front>	(COIN) system
	<title>Edge intelligence computing for mobile augmented reality with deep re	(COIN) programs
	inforcement learning approach</title>	(COIN) program instances
	<author fullname='Miaojiang Chen' initials='M.' surname='Chen'>
	<organization/>
	</author>
	<author fullname='Wei Liu' initials='W.' surname='Liu'>
	<organization/>
	</author>
	<author fullname='Tian Wang' initials='T.' surname='Wang'>
	<organization/>
	</author>
	<author fullname='Anfeng Liu' initials='A.' surname='Liu'>
	<organization/>
	</author>
	<author fullname='Zhiwen Zeng' initials='Z.' surname='Zeng'>
	<organization/>
	</author>
	<date month='August' year='2021'/>
	</front>
	<seriesInfo name='Computer Networks' value='vol. 195, pp. 108186'/>
	<seriesInfo name='DOI' value='10.1016/j.comnet.2021.108186'/>
	</reference>


	<reference anchor='WirelessNet2024'>	COIN execution environment
	<front>	COIN system
	<title>Online delay optimization for MEC and RIS-assisted wireless VR networ	COIN programs
	ks</title>	COIN program instances
	<author fullname='Jie Jia' initials='J.' surname='Jia'>
	<organization/>
	</author>
	<author fullname='Leyou Yang' initials='L.' surname='Yang'>
	<organization/>
	</author>
	<author fullname='Jian Chen' initials='J.' surname='Chen'>
	<organization/>
	</author>
	<author fullname='Lidao Ma' initials='L.' surname='Ma'>
	<organization/>
	</author>
	<author fullname='Xingwei Wang' initials='X.' surname='Wang'>
	<organization/>
	</author>
	<date month='March' year='2024'/>
	</front>
	<seriesInfo name='Wireless Networks' value='vol. 30, no. 4, pp. 2939-2959'/>
	<seriesInfo name='DOI' value='10.1007/s11276-024-03706-4'/>
	</reference>


	<reference anchor='RFC7272'>	b) In general, is there is a specific meaning that is intended when "COIN"
	<front>	is in parentheses? If so, could you add a sentence to define that
	<title>Inter-Destination Media Synchronization (IDMS) Using the RTP Control	meaning? For example, why is COIN in parentheses in this text?
	Protocol (RTCP)</title>
	<author fullname='R. van Brandenburg' initials='R.' surname='van Brandenburg
	'/>
	<author fullname='H. Stokking' initials='H.' surname='Stokking'/>
	<author fullname='O. van Deventer' initials='O.' surname='van Deventer'/>
	<author fullname='F. Boronat' initials='F.' surname='Boronat'/>
	<author fullname='M. Montagud' initials='M.' surname='Montagud'/>
	<author fullname='K. Gross' initials='K.' surname='Gross'/>
	<date month='June' year='2014'/>
	<abstract>
	<t>This document defines a new RTP Control Protocol (RTCP) Packet Type and
	an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destinat
	ion Media Synchronization (IDMS). IDMS is the process of synchronizing playout a
	cross multiple media receivers. Using the RTCP XR IDMS Report Block defined in t
	his document, media playout information from participants in a synchronization g
	roup can be collected. Based on the collected information, an RTCP IDMS Settings
	Packet can then be sent to distribute a common target playout point to which al
	l the distributed receivers, sharing a media experience, can synchronize.</t>
	<t>Typical use cases in which IDMS is useful are social TV, shared service
	control (i.e., applications where two or more geographically separated users ar
	e watching a media stream together), distance learning, networked video walls, n
	etworked loudspeakers, etc.</t>
	</abstract>
	</front>
	<seriesInfo name='RFC' value='7272'/>
	<seriesInfo name='DOI' value='10.17487/RFC7272'/>
	</reference>


	<reference anchor='RFC8039'>	Section 3.1.2:
	<front>	However, the execution of a (COIN) program may be moved to other
	<title>Multipath Time Synchronization</title>	(e.g., more suitable) devices, including PNDs, which have exposed the
	<author fullname='A. Shpiner' initials='A.' surname='Shpiner'/>	corresponding (COIN) program as individual (COIN) program instances
	<author fullname='R. Tse' initials='R.' surname='Tse'/>	to the (COIN) system by means of a 'service identifier'.
	<author fullname='C. Schelp' initials='C.' surname='Schelp'/>
	<author fullname='T. Mizrahi' initials='T.' surname='Mizrahi'/>
	<date month='December' year='2016'/>
	<abstract>
	<t>Clock synchronization protocols are very widely used in IP-based networ
	ks. The Network Time Protocol (NTP) has been commonly deployed for many years, a
	nd the last few years have seen an increasingly rapid deployment of the Precisio
	n Time Protocol (PTP). As time-sensitive applications evolve, clock accuracy req
	uirements are becoming increasingly stringent, requiring the time synchronizatio
	n protocols to provide high accuracy. This memo describes a multipath approach t
	o PTP and NTP over IP networks, allowing the protocols to run concurrently over
	multiple communication paths between the master and slave clocks, without modify
	ing these protocols. The multipath approach can significantly contribute to cloc
	k accuracy, security, and fault tolerance. The multipath approach that is presen
	ted in this document enables backward compatibility with nodes that do not suppo
	rt the multipath functionality.</t>
	</abstract>
	</front>
	<seriesInfo name='RFC' value='8039'/>
	<seriesInfo name='DOI' value='10.17487/RFC8039'/>
	</reference>


	</references>	We note this convention was also used in draft-irtf-coinrg-coin-terminology
		(now expired), but it does not seem to be explained.


	</back>	c) How should 'CN' be expanded here?


	<!-- ##markdown-source:	Works such as those in [SILKROAD] utilize ASICs to replace server-based
	H4sIAPYgUGcAA8y9e1cbWZYv+D+fIlbmWheolIQNxnZS9143CdhJp40pwM6q	load balancing with significant cost reductions, thus showcasing the
	np6pDqSQFGkpQhURAquw57PPfp99QiEyK6t7brtqJSDF4zz22e/92/1+f6vJ	potential for in-network CN operations.
	m1l2lHyos+QkrbM6GZdVcl70L7Lmvqw+JSflfLFs8mKyld7eVtndUXLy/vwi
	XL81KodFOodHjKp03PTzqhn3h2VeVJP+ss76Q7yo/+TF1iht4KKH0+Obs69b	d) FYI, we added expansions for the following abbreviations upon first use.
	Q/hjUlaroyQvxuVWvqiOkqZa1s3+kyffP9nfSqssPUreZEVWpbMtHMikKpcL	Please review each expansion in the document carefully to ensure correctness.
	fvnVm626gQvmR8n51c3rLfgrLUZ/TWdlAW9YwZgW+VHyfzXlsJfUZQWXjmv4
	bTXnX2DA83SxgCn931ufqnQ+Ku+Lv5aLJi+L+mgrSeC+v86yu2xWHyVPB4P9
	ra102UzL6mirD98mMGL44nyQ/LQs/p7RJzz/80+Z+6ysJkfJ1c83PybH6XCa
	FcmHIr/LqjpvVvS9rqa7hD7P5mk+O0o+4YP+ZVjO61U9qO6baT+lawYjfjwu
	QNYcJccwsAL+GCSHh/TFEF5w5B84LEcwuNP+4f6TF8/kk2XR4Nq/yap5Wqz8
	vH4aJD9n02rmJ/bTLF3W/uN/cm739KT/A5M7HSQ3VVnXcjPP7jQHKvcf0+x+
	XKb3WZ7cZMNpUc7KSQ4n43SZwUWzUVmNkzfz2x+jufINfpr44IE8+F/46wHM
	OZrhFTyXJrh/eOJm+G5Z5MNpNMOXT77/fr97hn6K7wb/OkjelUWzyOBku2m+
	S6s86/9rCec2/pqm+274Jp/NNu0jf+vnNqen/QJPG8z1af8yH07gssEw9TOB
	b+GozqJZP3/5JLmeZtVtVZZwaK7p4+TngZvwjwfHycHV03jCJ2mRjtJovn8e
	JKMseV2u3FT/nN7lWeU/pzmeF01WneaTvElnyNbmuMgpHfte8vbtSTTE7adP
	nkSD/Dmrm+1NE3NjfvOsc8xu7T7T8IDWx+XqX3Ic1IgHRdTRotc3VT4e5xG9
	wu2j6HOaXdg6mNtslk2y5G1ZjMoi2skPJ2+jab4p72Glrhs3MXcXT+vnk6dn
	yfMfbuJ5ffjJz2k0mPCA/mU5nA3S4WD5qUWWQOqlJ8d8ssxm9uF/gynMaUSD
	Ki/9HLZQPsExa2BoKByOLy9Pzi5urs6ugaD6pwMWenVapc10OAUxVKUk/fog
	YYYZkggIPySJqw9nNz/C7r0/Hzx9Mnj69Nnh3sH+/veH3z8d8E883B/Prm/O
	L9xVT77fO7t5fTzYf/L05eDl4ZP9Z4fP4bo3b89++OnMrtt/tn/4dO/H85Pr
	a7zy+8HLF3hyPlyfnRxfnx1fHL/9y/V5NOAuKd0HSp2t6hwGjGO5fBaPdv/5
	4fOXL14M6Of3T3AUV5cnR7SEokT8mE+mySKraMWKYZaUCxAOdbms4Pcl7y6c
	PbgtGYPgzVCu896KgMXf+0QM9CurDON0VrNcaNJqgls+bZpFfbS3N6kWw0Fe
	7sGX7y7Po6FcD9MZSHhgwkAn+e2yyUbAAofTvACiytKqwC/v82bqdZ3jyaTK
	JsQS1oYFA5OfQtLHg+RjXk+LZffXJ4PkOgcSnnV/DVz6FMhu1Z4n/tk517T6
	nN8NYGn2FqPx3tPnTw4GT/YPDr4fwJ90y+uT04toCY6T17Psc347yxKgy+QM
	jucwB5JM4EKYNewALM1y2CyrjFaiXDbJ6cV1cpWN8iob4iok5RiOIrAouOsq
	G8/4019fGzjux7P+BTC+1cYLYAWusmy0cXmu8nya/5JWd3n3JS1hvvb9BXw/
	Ledl/dgQf5oCmYzy37sLL3EXnrx88Rx3AW7AA1YBf+7nQzxZh5Mh/nYk30xr
	ILqpHrsq+1vdXzwDnr/AC66bcpUW5V20hdvvbi6vj1EfmDV5/yYrUtiIy6qc
	wOmZp7iz17BzoA3V2x3niOZ5NbBH+49hdf4tn92SBuFmv73/ZP8JP6vOQMTX
	yP6AlE7eAT9IfoZDUk/LBTwiOVtWcLqTHfx5+Qzu240WbFtXLCsmg/Izs9O9
	OZBWuvf84PDZXi2DwhfO4dIUlxDffHO9fzA4fPI0XghSxEBcz5LrRTbMxyK5
	QQ6CWZBcZ0AmQ1DRkNCvV3WTzZPjGi5s6j/a3xWc/iZjekcjp5lmyeEb+Rou
	a1IQOPvJzhVIgacvdrtWlGXXwWSx6PMgW0v3dH3pDt5cXnavzP39/QAfReR0
	uirSq2wB1sre/gE8eDBt5m419v/TVgOoZ5iNYA3q/6xF2P+vWoR9XYTr4/3+
	4Zu3xzF/276+7D99+fTp/vc9oszkHCd6mtXDKidrrpd8zKoGl+mvcO8OPGW3
	B5O9Ts6KKYonWJzlAt+GbE4vpUWDy20VH1kCmBWc8dnaCfrNK9BegHGz2Gvq
	yV/rdO/m+s1fr4/3TsthvacTfTL4e77AZ5+fXPB6OJHeMDMU1pMv8BceXf8J
	Sutr4CEg4eMlfD0Dkd0s4CJULJsUf8tQaKZBFNKKXM7SYTZHOYBUA7xAuNBm
	xgMcRl7pPwXGfl0WoCkNP/mPfwRNF9ZKeHnfbOxLYBi1mkLy8b8Nkh/Tov2q
	6Sqdf1qCXeK/uB4kPyyrdOQ/A7l9mv1YRg/4AWTFANTGspsVrlHt2JZtMMzr
	wRLUnGIAp8p/Iezs7Ob6vMXTiZmnQ6CtOjkbwXkzH0uy8+7s5JFDhw9rDXF/
	wxCRrrKmzomuGmfG7s3d+/sZvL8/1Pfjs97lQ6AkIf5o5D9P0yZJgXvO/SWv
	NhHACcpw2OlqVJftE/Jsw6ijJ6Nqh9e9uX77Q7yENJK8Tiaz8haOLN4ANsCs
	TEcJ/A1nm9YS79t9tXk1T2blcjSewYz+gTUd2k1oru3NRJfcG46KPRhODabA
	ao/H1edx9XFcfRtXf1LPbmleb/c/gh7eOpB5VTfJosrh2sUMNgCuSgrRT+/g
	8iUoLH/nc4kncZaPGzqg9RR+23gY3w6Sn+A8w2Cugct9ggf/xinfAtHUQEPp
	cMYTpvn380h93FuUdbM3xqH3w9D7s/2+jLwfj7wPI+/jyMHkGPVt5Dfvr0+O
	W4IOPwJFeg4PRJYzzuEnaB9/OX73Fll2jesAFtTGib8/BsuHn/wbz/YIOO6g
	TNEOQvOFz09ZD4El41P6PJi+DKaPI9m7gyHslfXmK/p4Rb+slSu8fvv+57Or
	eK6gr4O8KEazVfI6G2VgUYKEOj6HT8VU2jjJ1zOygd+mt3VwTP36YRvTbYM0
	J2r86cPFv531wb59e35y/MP52/Obv8SG6PnJ5fWz7/cPDwco4gbfP3v+cv/Z
	C7vz+vwNGJqtW67Pz54dHh7uyy2HL57v76PSdJ1WYHThh/ENP15eXx3Cx8/1
	HS9B8KH5TEwTd61lQh+8fHH49Nng4NmTw5fP8cLr87c/Xb0/Pm1d9+T7ly/3
	9wf88xkZr2dnF8fn8esvz99dnRw+fwGvhncdwOf73x+8fH6AxPn2+vrD1cez
	v7QefPjyyeE+qkDvjk/hGvv22cvDwydgL/wZ7IX9g6f7gyffPz8kOQwLfOOv
	ZOv65f73MLTB/ouXL5695Odd37w/fX/RnvDh4cHz7wf48/AFXpedHF91vxXW
	ZPAEbHa8SkzcbPQxXAzW45O9DI26qgRtsn76BNb36XN0MKBEWtsg+G7vF2QC
	cKp5f54+gf3B638GixGOfM33OM/Bkycv9mpQXV4878Pn/ScHL5487z/b2ur3
	+wmQawOMpdnaCgIQzjaqpGqR76C/fzeBd4K+SuY6frsAGYHqLOpto2wxK1d4
	6wI12xptrGS8LMhSBY7TrBJgEcKH8LtRRsKll9TL4TRJ66QWE4rYqLJa8suN
	QedJhijABls/T5H10D3x04dpkdxm8P8iQwM7nfWSvEmm8OCmxC/g/my8nMGp
	XqAONcJHlzSNIVrWn2kW+OeEox3sp4Rx4KyDj5JGBw8uwGa2R6P0gQfnI1DM
	wAqAh99Ps4rt/Wl5D49Ffy8PrYEJLhaz1WBr62YKshP43JIUukWFihd8XcMq
	J8sah4yBIHjHKJuX6IAHVkLPS5NiOQejEYdcw/TJmwA7BMbsjNgVvkGdqrIy
	9O5kXJVzunSw9XpZwXSreVllPXzJZAnjT3AQKZhouFt4Ha2iTaxO0PUOv8P6
	2JV/W2Y1vwnnWy6bWV7AlSPQuSsyjofpIr3NYZfwAQ3qDBS7qsnYgbtGo0oI
	Btc/zHyermidcXQ1mwgw7Bw2fLbq0bVu8co7GCU8DNdxls/hqgqJguJbKqll
	h0dkm9zCgzvmgO9iT9l4yT4ZpkO4k3ZrnubFYOuc9B58WTlaDo12Nh6gK30R
	m4Y7HD/b1QcVJWoPyfnZzWt7pBCafptQdA0OwYBP7TwfjWbZ1tbWt0ipfA/O
	8eHbHP/8CtSVBRq+T3lDJgVSB478Fibcz8ZjtLsWYAZkjR66Hmo09/AmOs30
	Vc2EIwtDFAnLVfCqEj/AJUfKmyzTKoW3wlag4cIPgZXIwcbN5xmcEtKSlqT2
	wnmEq4YZmYmDLbR8YNOLfLGcpWw5skosf+CdSK706Sz7jEvVlMNy1mIFqJHy
	IcbTzpQBGumKdgQkex+OI0zpnliJcpqiJPKBp8M5G+X8NLj/E4wuqVnzIfou
	4MNyPIbTlybf1E0p51zW7BtdTGBaSPJwzumY0xPyIfHBcbJYVgtkCUI2Ogbk
	VjUc8EIYS73MGzpBqGKmsNBwQO8w5MNPiU458Rq4X95LbACfXaWLHLalKu9h
	l+R9gSymrMgx/eBWMVndlp+V0SOHz1FlhOfFy4yDysiEJ0Jx/mYcRzlusiKZ
	8emFTYBpwFkfLYl8mCBAeyXPKK9TsrX1IyhCoKn3goipcl6lIrtP1B7pMYeE
	T2H4KDsqf6TDSWXWQIwCrqDjisuAgw3s062hHG5hUVX2t2WORhZuMHxSRCfG
	nRDQs2dL+g1d3HBw/Uq44wCrBUp7nY3AECHfHbCmil8MKwKXo8tnhEcAFUIQ
	decyE5FPQP+zGQ+fyaFBGzeroifBjMyK9IIU/wRmR+e3lp0DyqKreIpjdVKP
	1FUfPU8GmtafYB3ROKw95faSbDAZ9GCJViW8dPuXZd1s41FblDmKNByJ+rZ5
	YWm9HGk5uusR459mswUuDAYLgCiUccOWREwGn3ybTdO7vKzgTtiMKkuRZu7o
	/PvNYAYC5xA4Agm6HCUn87Nxms/QGUdSGQ5ZXsvst/NCraewstv0JFGB+Fqc
	D0pjVEzW5R18gpFFmCnK1V9wUaJ1xcfFaoZuFohDpItmCnJjQuvnGQZQxyKt
	TPzMcWLEqYE6QBFcTMsiXIxxpXKyWmMCpAgJFYxcnIYHCAR2WwKpJ6lz3IIe
	hiuITJBOc1m3pDwwgG0S8v7TbZWKFcb6ihGfQC/HYfl/RkVpJlueNnwEfnU/
	TPsDq100EBjxrKTDsqxgXvD4mhglPMRUjB65IGYrmQK9cCffVaFBbAcuhtPy
	eYFexGJIO0p7wcpKk8+cdrE25WSHVqliNmir4h63vduDV8I76UDyK716pEdL
	34rfk1acDpnx38JqZMBq19VU2UCdDZ4PeBO8Ss8AXjeD8zJawYjympjG2hT4
	2Ozkd+tD9JcNtq4zGdGBDfY5XkJalNII62NZvA30Bl1zImQgjySExYhKHE8f
	0CGdlKCF5jXLF9KdSTkO/C8wPODq+mg7OnMQ1E2Yd+299ZFkRWaLnJfYZl4U
	5R0vMQwxm2fVhJjouhgBWv5hBSxrdsdSghTLOUrbUQ4TXcLgs88p6hUsafFx
	6dBkdHqLOxQWDIRipqSdlKQMw27zYePVI40C/lMTG+9QbXH8IExwKURciE6E
	ikWlBASS/R6TiRbLeirCBkXdRk7o2ELdsirEblixvddpDpAog5nflbxOdTlj
	yVMv0OrTM6W2AkpxUIenyDpuf0GCuzMtSslJlAHOJANS8TIkr9lwGJcqS5v0
	c1mUc9IaZRFHouGSRhFtilHs0dbW04EPcnDUvU8Ja0qOkdHRUvlssERuqPVV
	SIzoso5us+tUyAFZ7Q+Sk2mKDCBT0+YoOVu/10i6UY/xbYZTZqaFDLJAE0gk
	MDCn+wwkZlrLzSA0m3xIJzViOMLEdWQwoIMBvF7PkWwghobD8pAisQQ+CId0
	ngEzGMmoUNTLEOL57uQ0CeFMwCTRChrOUjTtJrhB2edpCmoGEMAMH3GXZ/f0
	BFiFUQ00Rktto4FRPhsk7/25OUqOi3CixsQ81hk4DrDW+FTlWWc0XFwUIHta
	La8AkslA9ArTBvUQB3I4CPagnU7YQTOtnTWqOxeZAmiqC4Pjp7T0JOeIiDgF
	huI7OUM6q0tj1fmc4sNN50ldyXnUY9oy3lEbyYdgvlVhae6J9Y/wZJQLstZx
	Te0ts5WcRmY7qq02JXGdtKjvQXKJ0dAxdljP54PkeKQm2wZGs0aNabhjXV+b
	o2pNFKdmgL0YdCMa/23m3vR71+aPyNTJdMYr2kqUqVacCIK2M9idQxPTPTSe
	y0mR/51fgaQCgwgLj7mEdLhqiqnSORGrBi/ctAQk55paziWxFExHTUoeJwpi
	2LohmZi1ZKjAaUXX4x1mRsSaINrHomTUS01+gaEMUUUPdvmwBO5QL8B8iCjb
	73PsLwNVdbisyUNGS1fnn4F3UXhdND/vJnNSd6NrjTRRy31T0eN1AfXXID8s
	RuZKwSgFrdqYpV/CKVwimmWgdNBE0AehaxM16TtozbPKzDMo3kr4o17WOsCr
	NwN0At0A98kpuLhKHr4lXvS1vWRLWS1iVXrxKBuTtgxad3kPj4ryWtR/dcre
	2mTn8uK03j0yLWrNi7vBccteH/Hw9pzhvnBvU1V3SUfm8lny8HD57OtXZLvM
	QoG1g+k3ITNNXNJnn7Mhn7az4i6vygInegSbAqKipjXieAvorva17hU7M0CQ
	yCN6bBizUgZqb/KvH9/1YXNhcewa/xy17cBaWxb2vDrsGLsj4ClA5MhOy1G2
	tUVExYkeR7QZuKTJDi5QhovEms6umph51f1yVGRKmBiui7lLum1IptcKKKcQ
	7gHXznuYFsjRLTiCoILAF7NgLCSUlcJqfKe9QfHrhbtDeCdZt+YjWxOosgAn
	+tEKN2ucpSR62MAYRSYWW8suqtDySWy2nU1VEaI0ohESPyKrF44BHsphy7vV
	SGzb/IfpEFjUSJQP0pCinB8knTrNR0rR7PMgOhdxgbwXmJmuN9qVgyQ5psmU
	wHJMYTNrdpnPGry4rPDYIJNihw3ccZsHXc/NgdZWRuBOiUwYbH70Ig+zowQd
	A0C1Bdsm/CmJRb1b9unMLFVcrQ57OLmlrWrQYCHvxG83jpFtXdLy4igu1Ko8
	c7b2w7fwSvcBsLRvv03elbfotzx2Rtf78Rjj+/igh2/n9D18LZ/SXd96DUA4
	Yz0EiqvyUlccThq6aUlzypG0SE0BeQCK1SSdtyy9noZ59OzQ0oAaviJfY0ph
	HN6xjxx4B72PqWvn49VuMgWhWGcNEEFCBq38nbB7us7IhaWxt7Cpr8kM5S1j
	a+YbEDH42m9aFwPJFXQwKc3XlCgcZk98v8xY9eHEks0iQJL+eMX+x/gIEm8q
	0dtWglVDwjMv4ESy/xJd+rBiIwkagLQi3xwzd1jW23KUA4OAI1moAHFeVBwh
	vFUXZ2vrPfnocLu8lS2uL1JgNJqHSgvKR/h0iSNuLR1LYwpUBh6DRJt6I7Mn
	dMsbJ+6aDgbc41DAo+svJ3+WjRvlRTIvXX/h2uSnIa2CaA23oI/xkg3r33qN
	UG/J1C6+JjisaXW7Cp7ECnnRFF0Qlyfk1IiEb0ukk6Tf1UGzpCirbXT+UsKU
	jxVRNKlpMi+pdsZp3ZAmNFKfxCqZglrNOo+qyBynwV93B3xI25YtKCS6zeqt
	psMf0QI5V+S8PEoAaGew+AcTqVRZGD2MVLohFj5Y7nX7MTxn85grA1dplEZu
	VFsT8uijM1I0DHbx9GBCdUtnJj7cMU/ZZ4tqKt2jMk82f5XB877h8wdz+wb+
	CFTzDXvylFjxk4TK+VBQHBcr3XlvkqOYgMmSb1i8Cu3F2DRYUmg+L9ivms2V
	+cjtfNYkyNl5aru1HswAyIqOgcD+g3hFVgGcge9F87cI3JmnxxwTTv2QnHEY
	BgRBvyqXrbhfnXE6fuwLVJEJz5UpCwMbuOgVhRlt9LQ+3XwB/fV0WJkL7zCH
	pMVWe383qNiBRaLGqEr0NL3LZJ1HHYZU68Vp7S2h1pcqVOruvQJeMs/SQnZ8
	W5UVczZU2+yXhbeDakieWVwIMDjv0hmpy2WyLatmyndpcnubeYlzYGpIG10q
	lFmFVLKcswkvixXuT04uPzgWKnTv1HJiihXYe6JpZdUu0vY4eHVYA28rOLYt
	5KCU09N+rjDbeo7hmJuPu7haNSX1UFTVbakloGxcfWW6EsKKdoEjJMgIzKjO
	UANpUNSr00T8VeSOW8+UQapWaSxKDYyoQZdVLRoDfqZiJ/uMcSLOuQATfyXk
	H1wAlIqYYILpPaZjoqcAT2xNGtI0HAo4Zh2jydGigLNoywTrfpfSFqouqYq2
	xrZzb3CimVU1ac4WGagEn8hjDy8t4OVNNiNDScQ+pZPgNmO6bwgUGPNdkWOR
	oxyzcih6kGp+wUFalEVfPlUVEjnAw8M4n4Ad4zTPrxTQr1nfDv6U2MuvzwgK
	5fbp5RVynm1cH8d00pjtJDu4SzD5yMckKtEpU+rO6W6Pyw3qeueS7cor1tB2
	QAmNLIZdIrq2ZsB2O7xCqUaSm5Lr04ueagJ89jH5AQz0VgSFkpVBMUnSuzSf
	0TN1b1O3ztukOlNGBZ9PYSidEh8Oy2xmqqD3YjvexLuOlLGtDKEn1pOuGL0e
	nx0/k1l/JMjDw9had1YZqC+4o15aronJggW9OXKdsY83sRdg2yl5sgaoGG39
	v/Zvy+qnOv9917d/3+mu48Ou6WH+XjGi3L8vevd38Guytf7I7/y1cMkl/7IV
	PkzQKJPfOp+abLU//27Txe7KL6dfLr9cfYmvhD+ur9oD+JVn2oca/X781mg1
	3b89PzYaRjQ2XYvWv73HX9bxOh3443uR7H2Bkyg1aF/+iv++/FBWwMe/dBDL
	d/aAvY436qJ23PglOXxzfAE/97rmuDbUrjfajVuPTSd6vFz5xR7SXlg/Bb34
	i/C+L62Lo4XqfLJfna4n+4v3vvx8/vo8Ob4MK8L/bBjwn1P+Za+1Ct/pL+sP
	bj0Mvru+6h5sPLfv/ALwNiZfNtBX53zcGy+VE//KTn0RxhJTzM3H9uCiV3tu
	9nCUfNsWmpyK/7++8f6d16owOkfPGdtRg2++Aoe8Rn0gyBLHrIflcjbqSfRe
	3Sa3WfDskTsOFRbWmPImC+pFykoE28tox5CMBWknXokscSx7e02nq8XVnoox
	0gRx5s0RE1ggFDmsvnMNshn0R/ZXx35MugokjNy0q55FynNosnRk+vsC46Ll
	sp6tzO+x++iAnaoh6U2xNBL9oAh5E3igTAX4McOwfxz/sQDokAMtuTrgg3os
	JnhVLiqKO8aDIp8RBbQwSJuyFq5enJCeB8K3p4ZV2Fp4ta5eOrrD4sKa6+c6
	rVnL67L94JVFGzWbjdFOrnn2DacT6UrHehwna7CSXpemDUu8QPRqco6hxrDZ
	r6NxRqeEYKqgn7LZI+01Y00N15kc9XsY8etjkLyltPKWpYXzHnmfQTQW9IoE
	X59499jrgkaT0emO1BntxtGSUt09qOGaU4i8Fn1L0KLMcsoNUw98gwa/X4O7
	PEWrnrdIUi5okkAkTazM31PwKV6xTd46cUBZJsO15g5wTiAW/anS1FUumDw8
	4CWo8S/RmY8E5mFrLEXdchJ4dzYaxMSXNE1lXQfmVHU6Q3HEg4wb9atSogQ5
	Q5zFqmzC0ga9SaHBZnY0c8oMz/3sRFNHalr/xlJDMNAXCpnlYLOVE/RdHJYN
	FNXwEI7C1Kg+RqgRHgJe41V9Zjy1OkzpREWZsHXGrg7One2M7NkxXXtu228T
	bdmopBwAmTTXW/Ytq+bhIarRhI3n3IC8oED7jCpeWrWCxOVSKnNRCSMWHB4f
	GLtcD48hkAxKV1rWLmk2RQ8yAeu0/PHzDMgccynKBov/yOH8mP/aeJ18y0lq
	IK0wLaOijL5jWGteFiIAdg+XmVQkWE4cxc1XBdjDQ7f3nFwUYVisua1nM6LQ
	u7Qit0JMIgmCuTAfcF68bvJAzmyDjeiPZuifm+wIJZgTiOzHWSqpRDXGFYeR
	r+P04lrjwJLSHN6hfjhbF3SKVCFfhfItWIrraMT9GyKL7Adm259TmEBCDDnD
	3paQz4lmv8lhneUhe3Cc3QOJzmYg4YCmRuKmnuWTALJCqW8YCyImrMm3IkEi
	8oYFfQvcFJ0+Gw4kWfXLekneUk0r5Joa2b926YWqLxpNCPFlWBx8S1zOaiGq
	pUsmYtcD8gCYXVZnktCwsLp4djs752vr1CKDVCdf8N3ehOeSZkO1PTNMVKtS
	DrESi3TMObjMbJo6HVZksgYrkOwySt8PRQuS8oRkDXuWVsYZkCUYu81FZ0iF
	3tR1tb4d7EeLsvtIPBS+aiPKjORomPJMF6UgaUdgBgm8+uEhYC1hLoaWd/nk
	GqsliLinsgbdu3bdBnmubzGVwLw3HHM9LkZVmY/kyHV4zVpbSmq6sIdWeBbf
	gyUUqBPMuHKJGZVkQ/HZQtc/ZiYFV3z0hnXXrPN56dNJ4+jKyViiMsOsZAEM
	TWblCkicwrLD8WLQqXelZMuyk0bJYgmLPMQTybpdyrUAopL8XFazEaIETTDn
	LEGkKtphAqLaYtUmzn8kT9IfkuC2k+SKtueKQkym73c448LdqCSK+5T3SetS
	SFfUBNAdfoaGNvoE0AWrHx1bznzrVns4MzCECjrDbUosj8UDLb3SV1Go3339
	3QO3ZJH3TyKKWgL7mGffnNne/0fQHugABFL/xBE4wuxaLpi70URzq7oKZm7M
	MZPyviBVSXULdoCTXpEVy/A90jml53CCkQag17MP8VuyjMuqjiMl6mNHc7kf
	JhVSNfxiRZuyY4nAQgawwqLFt/eHkm8XWAIqKxE9iNJtWmtNAW9cHzMsIyUw
	iq1tCq35zGSqG5DoNj2WuRTrC/xMCd515BqQ6qYZw1Elkm6QSHq/VppszKqt
	t3HEOYBTN4t/p+U5wMG1WLbPYJYIvKu746xbc/EHs3QDETslRBmRFPUh7t5E
	IkePGPqYQ7Th2YQ8yQYp7YMfeXuewYpCM4kfDwtqawSHGJUaLuvE3BDUuSRr
	DweBqjMKaJcEOyvLT0BncXyKAvqoF5jBqiOibA74eiZ7giKEyieUOJCwBtlA
	Kw6M4UukQApFRVP0FbWSh8W+G7byeYlT3UAmiOCl0HpZlBmSFzuSdBdXGPnw
	EAAfvn71ROfCX1q00SI+NiTUIUWpxcECsE2J3SYuhTm6fT2WjeSUjSn8p8sc
	2XhWctRK0qMyWX6Y1n52CY1N5ytQqojlyHRIA7PedBjIHUaHoaZYXPy0jWey
	R1HBoWoCTO1rG7RLByCscrtSUyqVAveNRr9JCMli37ZWWHjcPMu8Sy48W/NT
	SXH2Zo24Tayi4U9WVaCJeOKyvfrTV9mGqz8lB4Ong6dHyY+IjlBKSC5rkVxL
	xCr+ipNvjEsTX9dgCh+w1frhgb7G1dZEDn6w8q11Oul5XYbLVHoJepbmXKiw
	sGxFzoSghIVwR6yWBp3AnLheUSkUCsQFon2my6torfZtrSgvQm3EnJQKLJ5i
	8l/bdJe4y/blJkpmmYnXkacPeXmWwC4PP81WrxA+ty2M9IjfMk9Gn7uWKYS8
	YTgIqOaADQrE5lbVu6CcoQ3P6Zdjvgn5GB6vVdhun1wKNnm8Qge2Qvy6SAwt
	9aTpkXQcin2Ej+lswAhA4SKVAeR3gZKPGTttsTMohtOytHoPKkY1HVVZo6Up
	/Uq8mA/8JEcdyyvbLjFFlwM2i+PZrTmY5tOipWe2Usbru7SX9aWoqYS1Ef+b
	rWVHIAJ3QTlHuJ94Kk9JbokHdrg+MMeDYXFzXreNe+XYsTjOjMdhlajIh1Zu
	lu7MoxyfhK99qT4OpYNNh0peGNkn4YjHk39uk9dKWFMoUNddl6yP060ODSth
	sqqPjj00c4va2AHyxGyBIS104KPbC5amRs04r6eoPjS/QQLGc3ixNoeNMnEE
	z61DjZukNoY8DkMlcYoTmQJxlQh5HHJcE6qeLKsuTUdNZY9rQgiLZaUZ2sEv
	SxbYw4MhXcHt7CCRkh+dgIKPtA7XSwHoe7yScI0Mu80HRsmQHY3f870tNVYD
	VT5nuF4VwyliSanTmSokihqokNyKCNfkKDJyJiEVwNvn5SNmLAXkXDUbWRBj
	okyu7FJDgMxvPrXMztxNaw8P9ZPBId12wLyi9P8z3QrNpscJnlui/jt0YIPy
	8eerrrx/u7nSVPw/Y6S1QCGcUjnZx6tecryczLmAxzL2j684d+pd/tl//O6K
	UXwsvEOs3yrCSB/NmhQ9pqyxSV7kqMrvBILEw5GM7kzqmPC+i8MSCoKFvCEn
	sQPjLoc52aZ0qjVhjeAudFmiRLle7FIpynvVojVDEtZwUoAwIzgOSquUegNS
	4kf5MOd4a7Ecp+h80BfiGs5v0UuFN4HQn5BXdlLhvrNbl5Mkhw5dIIySyraq
	ssRChz9f4WKhkFSXufr/8GwyB+7T7954EqwZDbaSYokIEqOsFJCcBZU1t1aY
	4TiRQFex2kT+O8V2GWWzdBV79R37chhbaeR29ZAqHNbkxUYamTj9z5w7ieHd
	84wk0NML4Qw6UAEdtmfhHE7HZF8NQoeEu0FThyUlHCmBLuMBo75EhUx0etlV
	t54bmXe4P1/7erk/X63jjonDfD0vl9gDockgB8MJWZzPIApu2UXLwEQaEyFm
	Q4dVQDUYCZOFyxoiUsAn8p69VobvYOtdSXXPyJppEXrKvgt1Z1Lo+xZLXXAS
	MFXn6dLQjVXEaTCcqUhXrcaCII3vMbxBXgS23RPALMTvE0IH7r+YrmrCQzb9
	vBfFhS2qZeqyBN76Veb8RbTv2KvHuAeDimnhHYU4QF3FI6eOEn1dE/u4yTNZ
	o0MOjfLgmlSXv/APt2BInaQDEAXztjhe1AKNsJVXWamhRU2cgDOYs11gq9Am
	PQp9pHNcSmSPIzjykYcqKgZN1ar1xx4TI6y+aiPCUutwiCvHAHc81DlTosgH
	NickZOCccbw6UeuG8drkblmNYKOJ2XEj2y7iYySbLahSzPAXnDmDr79PV5J7
	IOX+zHuJEzuWGDtzz4EPovbVHk6okFf9IzxDHdbtdxBIEwZsVp0efo6d4BPE
	y4GP7WMhWU4Dw6jVYOuHbJhibAldYgmajPf5qKFwj2R545vpS1dwRDyR95wZ
	bUh4x8sPTv0VU5S4qI71hP9LYF+s1YjzeBiUHrvGaRpa1OeZOFX81xYOw98X
	ZSPgDwYTKWwj5jzENwaUhsSl4GxN9iJgGlsBIMhlAfP8xOrvEgGx7EVEWhur
	ruANSDecSi4R6jbbywTBywCU2BXBPuDo+BNGG3amQSWA8/HpEGue9ZBALAWp
	OVrYgKZARydAGKyXwZIEF8qPRCMaqyS5tQQQhTgC6SmLY28OOVeIibIQRBhp
	1VCwMdmcLJNhyo5yZrNKPJjIgehu+IvZ/K7eUk0Q5Q0o8ozHGMu1ig3k1+bg
	Zmd1zqp5vbxFCU476Mqg05nUyFAqCLDaOcoMlpkSCGV3Bah6PQYaXCwZl2oa
	g3PASoovUEiX0xqCuwp9Hs58CONk9EEKFZERhVcRE2OVgvQSSx7AAyiYkeHs
	Ettv0Lcc6yQMrOwNFS5xQpYC2l0bd4h0BFjCEbAkhTE05uE0q3VmNl/Wjbj7
	1QhHiAtm4HHqjJhdXPMLynxqCx0AAHx04XZZjbJC3YJIgWFMMcZEADNRnFOw
	x3H+c2yZROYbhu0dl8PxaG6dpVu05hbcaKwLC3MDBQNkA+PKzZP6b8uUUpcM
	qS2dzfWNfbJZipaoVfUXWTFWHmKEhYqRtI+RZCeh8M1rSoQIhTSS5pQofjth
	8eWiydKZI3CScOJ8RqpxhmJEWFNao0T+UVo2KmGULBdcMhqsQPeiLyQXX3dw
	K5pq+57zANywdfk4ZyKfNVkV+IDUqjGz2KT60wSialZNOgn8GmEG5vNypIAk
	xrtk3JZkh9pkTDdbPyOlR+kevjQV7yLMNLI55YxHLF3Mi5B1HBzLkkm2ph+q
	JXO0tfWHDqrjCKrEQBpX/gxXsxmTGRhZC66KXIwso10yY0B6kPJMNA8tKUoc
	0PT0yagrT0ae7mu8PE1hBh9tiDde10WK88MH5uWtQpufnFQiKuc6Bf6gVE05
	lMHYY6kHv3CQX7wbhAKJD41Eo480tI29No5drIHDk/wMD9/sPX+DlaNZGCsp
	iKg/0sNUsZTy7wgtL0RFvOZqqUVmezh1lLOMMDHIFI9awcbg+kVKOJ8B16RV
	HU20OE9BxoD5irJmJoAdZjwofKgWMsNDSbBH04tVqxbQj3dx9eLgY+0tw8jB
	6/JODMwDj2DBlgYDp6IilFEGBEenH7WqY27Tk302xYMZDnN0t/kzSsumrQtv
	0xLNeDlpkZ0qxQt8+YEe/AZ/rmsuosaLU3XicxfVSmPg2no5R5shCERX3ote
	JJcm1lLjR4g/N6pVS33XFhTrILSymuyK4WAmg+oa+ydgXRSPYb/YIpozcZA9
	lI7gHCN7wWwtJgSqpYo883rN35aCbT+O2CiroqxhCgx8BgMqUUaXlM4rVjty
	A1cvz+yZVc3Im1UbEDrCQhNX7inhu9xgO6Ve9BIV5wyK7049mhGvZe0jcMII
	PJkRyM01giMoysawWTm7T0+knHZLhUVREYVwDLAb+SwDM1E9RctS1mzCqa/g
	bKMadgAkay5lBHLJeimM7OFhDRfmq2HxP5r6D3Ma59mMAbYX2E+kUXQTqQS5
	cwhxci4WWIywgo/ogLNLtrem8Fj9bLDke51GK1277jk9L29wIYL8OJFkuosA
	/LzDKgq1Btj1oQ7vIuX0wnpKBgYjX0oUNmj6oNrjeTKthdxNVO0wCs7ux3yz
	Ma4qn2zE/Tm+2guQL0y1kxl74ylLFHc4L5Z8AggrNLMAWLpsGMCTcehJont8
	qBjLNvI9iLjizMXCkJG9i1JqUIJ+JsUpdLA4SCBqGnlt54xO9s7UxiTN5xzO
	il2RselGQXJZXRzv0CRdjDLBtWyioUheGRBnG3qZ7GT154t8Eucg6n5WhK0q
	kUOla1s5yzqwSE0eNTRBCj5NU62Ea/mtvCtpzTHr6Yq6CUkqJGqxCozDqO1s
	DxYuoEy8xh+34yt6JgZuWB4IPWrbI/UktjmZeqfVEdPamFoPDWcO3okjjZn7
	msew5/HW275o4IbkzjZO4DVNJPwZ0O7Dg2sP8/XrgGChiPjuQ3o4MmB7B58b
	BjzxwFUPD9iOBitSVrKDISaIRXOY+8Z6XRMiCug0naYixr1Kqvq4+LVVEunk
	iRE/PLheNchXYS0eHlr9aDAVhwy7kEZPkIQooTrkE0NmoyeA7jp842oLQgKf
	Mh7U9JLY/2g9SYpMTg7S+Sc51d7p0jAaGNV3EszC5cUpratispIcK9BZDm8p
	sF0MkOtikKgLB04dbcYeB60iNmP4Fu5EiKkleJjDleMwIVOxKDHTpuUanc3M
	BUZ0i/tE5amKizxOpJscxzS8sYaLwVBX2k5l63o5xy7if2f5gg+MfE+U9y0a
	jHBnZcYRL2YYnZxDiQTTG9QVUKSCt4riULGHgxi3uA64QIQ3/J3GTeVYW5SU
	M+HXzyiMnDxbn1bAwT+BxjUahOouH2EOXRFckQArs8Nl3aEGacqyz+eS6rAG
	zRDSvKhpZ3h6Cx79pnWqcgVb0UxNLsMhf1gdqoU7TVTTsBACBrHUlMHz8SI6
	aBcP32HIlnTVql1PLHoAHhCVKuSTdvw8y+mhNBrcM8c4eu6JZJ4Otv6SWd8N
	Ai8mFk7yZ+zh6+989IHqzloaQmSxObcAVfmJ54CYG6fRxwveXfPA0oU9KnRQ
	p2QczVaekCLuh46ieU4Armz3jKm6104BZkrGrRVanRPggajRUU/KSNas54h4
	Im2DXKqCYJLDGQ+URmellW7l6W0RWjwtIyoNzBDb1EuOnKtyiT64Kl8QRz1K
	9p8kjL5uBV+k9KWkvQMvQdIgGGMxASJbGjsfs+JIzoIsxvLEWmSeOZO60e1O
	SBKOE3uFInZlCpyZozKAwdrbfl2YMmjc2BxCD4nl87An/g/JR7Kh/W4fUb6w
	GDhiUtL3w3LEprfaW2KBiF8GN46An3HjZojU1kzRgbjAXhCN92WqEyj2iYqm
	gd+PcimmhK+CS6PleHKwWINEtae8Vm6sbna4dY2ZhAZT5bKxHgnm9SUCRbt3
	iYZBoNw6ixKxQ7lI8BKE0FDK8DwyBJnxnq2EkbP2YZMCKXJ8WvUo6dvBAYcb
	9g60GSAseMZRcp0X0ZJYbRseAhjqKCUhODMT1fh4ryuvnAlLF1y9Cfy+lvqq
	Tk/ziBGFOc8STNEWRUkbdU8JKFFDqqbsZ3HgFyf4eoMn9yg5VsLb5OztaY2Q
	Sw6JjIC4S5Cylk3IuZFLzUbeBkrLFc9xhqM/d/5FfUxwAGpSGmF/SAuDm6m0
	sEG9b4NKmBddD0PSRoNaQGjZz8MBcQz9h2mZaCVgCKIQzgSU4TRVOZNPAgRW
	bg0GeQlcJknsnnBksDErntgrpvDtY/475lWrbkFFAL4LClc+ibI38mWaxcR6
	oIVABJfVSt2JsU5MPuOToD4h9nzy3UQXWrqNjDh4Fl+5ke5jUiPKlHpKJ4OG
	iuMCzh/ctHXmxkC4p1IwhW/UYE7UHQv7pPj3HPCKOL+StxOPzx07VQdg2Mgh
	ZZVwbC7gu6HFQhCs5BCVwaByzqkxMiqDDGg55Eia08VScpbN8z5MAcZP6iC8
	1zwWtMDkxB5TXim5HisBJ6CwELI0R7UMlCjyzdWY+XJXdD2p19mv1DNeKeJd
	qrORpS+bud7Fi2jb9/brbTj6zlsks5iXIywjzDGo6rLxS0uMMRg1nCVmtEls
	g33LLmSxoMQk811TirYBhjNfwfsYeB+NDil3Ar24Chm3a2UQK44Bkv/WWv/1
	vP/XOWrplDIef7u5Ej8UTWjX6qaY8NGVTEWpfxxLYI5SkcinnDHUD45/qknQ
	OVKrxB+QWPwWHrot9Mc+mLat6k5fUN3yr2AYDwdCfvhXyaVFLnAZqCtSajE8
	gfN04QttSOZSNvR4IZOrs0kEYKBLs0OufzYBhmUlDdZou3ddz86NQiriU+ym
	aCFAaM+4yKuTYlMtzDHblZwCRRIpC7+8kk8/1CVWI0GXOkoXUUO8WVf35YqA
	GhiZPjFutSuj82Uh6ooD7aZKNRHPYUzBA0oBLsAL7lQTHX6qX7Eccf1NTq3r
	yEmEpX5eWLaBKmORaSHBe0kO6GoCw0k+wXjwiclsU0q6oBgRwUugTRc5q5G7
	p/h02EHSjqeJn5WBE6IgtMqY28wl3SiOU0iBkH1qqPAITpaiRWBgZhZzE8zj
	IebBRAKDibJFQilXR95CyK9DHyCYEMsqdnTOKZeOsK6XC7Km5JQ4ZcCDfTvn
	lL+SzyTxy7wYlaJmAu3T73pivLHLTXQW2o1Iw41uIS2xET6xJquYQH8JQpFU
	XW0C5VmJc4rDfmEV36V9cgwfdCTVk5cytELC3LRRli0oIk8ZN3H1jKHuy/zj
	7MCsnaBvnTxC45ZQ40rOzj+jtxST8Ml9kxHY5kySjSUxw5hXe3ohcinfaHYS
	nkpaxnmGh4DxTiYZ58zIwXbaieCfOsrgyNRd5sDmQ4pw8OEKO3A9UZo050KW
	R0BkJMs2jFkaIpPBVFboylsWI0mzguMYamVAp1ZntYOCbs/2j3451ONb3lLE
	oBdSm4lBBteypGQQr3D3U5ozjdeymP9o6pW7ThoH8N6N4aW3wAI5zkbcVcbY
	c301yHK8zdxKa0F+e0YB5QWX+L7kJoPSMegoyUlkZfMlIZxpOh+bryGhbxod
	MNiLmTsynN/bRVA9N/awRcxfbE9oYMOy72AGLNHH0sCJw3p4QrgEAYd4PXOZ
	hQZlAqJ5eEI8WMoYUq6uT10Yf4hgVzxraTdDId9GxU07KPKSjdpHjtZBZy8U
	2LFJZ9oUkTupRQPxyUYf8+y+hcUUMLW0DtNznSy1VHxZNIX/lri/2NSe2SpM
	czzMbcyh07er40Qu9Wtei5XR54KqGstuWMhSwfU0Xz8CO+gOkXgcOVwkVzjq
	JINBrDok+rnbFY3LaIwUJkQ9bKhsMYXlrHf/CMsnFU7RBnvuxVmTy1vC4hQC
	LvsOQKiXUK5nv0knHJzW7kwsmg2RwKMu1nvCkfsG2NRTdzXTLF/FRm3NjZE/
	rUcXOQtJc2yBC3PboDWWTYriHae8jUGMkFEiCd5kTi9ALFM5EBYTEM45yUBQ
	hRG3guJBlioEc8W8hPXXgA7cDAe76nFey6UObMd6VGDFbuy+wTAT5+OYHADV
	dZSPKOuXK/S5blKQL9N27WdNx+JSiSHKV2OjmNMdzZ6Eq0/b6YlYCDdqX3XZ
	Oobhu4RKEgMQIQ/e+IX2hBQRFzQ7sUKDjGutaW9NwNGZ4S9dnF5bBDTw/DAY
	DcybaKUk86BCm09E+YXReXgGWf2MVqKPScdNDLtnEywJqU9sSYmMLkqSJNae
	l1DXYI0nM8lk5BdwUyXHTiqXZcAfkZVTS11Z0cGMhph8XxC3XHBP1DAPKl8j
	vVRW1OWseyaOI8iCpqmz8c6PkKJhmHG2NP5RNkC82p4IXPCeW3dwVy1dRIzY
	EQpYACA1ic+D2q7JSSo6shBM5LVVfBR1dbvHc1a8ZTfoY3qy0HqH2rTBhczV
	AKSPCHIbq++mMuncOcopr0RFEJmrrIApMdwFyQ/MH7D16/3hDVdK0mQHc3CO
	yMAYLgOEF7vsPKIisxOnbITFwXZ0TUu0bAswcsdhrRFcPwObmWU/ZQsTphdy
	OrLQVe3bFTwg5oIijpRtdakcLaa/Tq5O7WC/lVOVUXTUFOIoxhiMF3GBiLqY
	EeDHyWkRhO2QtKdukzvqyNyJ3WbrVHRPHE8VaKz7ykJaq4toe4vMKvX+kFzZ
	YY3Pn2ZZYro8IwnKgtCR0whSTYfLInS3ZBKgbZROWLTmBD2q9/6pPAsVDLSO
	9Vo+FC2f8ZSi1dKTKmDkgMpDkR/clTnQAKb72QoZfMlAVLkAx0haDoakKPUr
	HkCfjzP61nh7dKsi4qHC0p4qQzwQINIQOGg9X1KuVhvOvEeQc4c+cNauMdih
	xQk6DYDriNVtGdErVf92FeJpW1PyumjyB2dH3uUOYC+ofjZXTGI1GfRrFi7v
	LlUPISEGYkCvKNNCiCXzahESuS4KAjPTNveZ0B3hxClqTXTuqLaEvfd1G4TZ
	fExbFyC8jjq+YJaCqrIuk6ZvhB7bZFhxu1lyGKwngvbEjdCTzKWT04uaILJo
	OK0cgj9o21GKr2DaQivvfiMxwOnr05Y8wqTJVUtHZpQ1wFz2cHkbTv1StmrF
	0oIO3CqSxjF0x4fj5PI4lDWTslDPdKUpdC8uqPPRhV57tj3/wp61lcbMQyU4
	qd6Cx5rA8/WRa3XtQWcJKqQ0vB6ptdRmc2NbDQL8bcpZxm5T8SHmSu/SALdH
	kWjtvUQZ3/CMp0+ecB4mGyM5xlbcMSLPGvVaC5PTKXmUP+yQyfamWDugipkA
	oaUQoCG1TIHJI3ntIve4jPIlmOBM8eKOdi1aEvw8dbFwq2G5hlvP7p3FyOy3
	mcbf2X2aUqEAmU0aS22oID3iWMwfBLvFMJZ8JMRSjFCP9Gnc9FzVMulIOEhl
	C5wIDbCvnkIuw5KUAPmiC+oES45mUti/KQp7ZIGCAwzDnhcyFVo2obH2+VxD
	XFBbqfcrZz5EQl8lJ15ExoZ7h/R0Ib8DhQAbp9Xj3J6+DNpLUJbieRnUTBhe
	wF7QgIYeIcwj9InbhGSrfEnJTBKLcw20tdg/SdiU49yvaCoyID6apMOF48ip
	q60lODhKrvkeTkVFEKFR1rF3nhxDzLxrR5mqmcpLW6MGM6izz5TGE5O8guko
	shjJZMrKlL0IwEbingnwdGW1xyFJwX1xraBfIQ1qkwtZ+QatXg3e8YTZm9XS
	G8qQE9EqkcTIBQakd1p4o7Jl5JPG2k9imfWuX+oAEiaMdv2scYTQXNpONQpZ
	ekCB7B1i/xGHtoJ9bBxeWoTgEzUm12UrtVSgLrQjjZJybFpIkfZh2cBcX21p
	VJB0BC9IYuLHAFfr0a6RM2VkqF7F1KNgwuRLLp3zltNM4MQg7kJofAb0ukf6
	Eyanwi1pVZEk2ZtlCtXAl4YKrpzRnfcyBnl2vRe0OAbfFz8Yniz4fOF5tTTV
	xgqnjtfgSZInwPGj6A5QBRA8iam6XlKZQYw5ZGtVd1NHS2xh3GB529e/Hx5e
	Xb0+ebH/Yh9zx0MuXLzD8mhddj9M6q9mHclpXvzMl08OvidFzij7UJNZ6NTS
	Gbx0vFB7h9KJbKR0rC94YWPBKwVZLdnWRZ9H0LIL10rsRLvTZNl09Es65O5E
	/jYqYfPH8PlRcly1jM7Zqh/wdBhEp98q7kZ7RcpLK1l6hDaYFK5LbYFFCfTn
	znA8EP13Fx7lwPzJNyZoyeZxWOOjLb556/LO11wLfnIvQPKqq9BhocVbghBQ
	vrFxx4J5Hzwvcuh+4zOnV1jPWPfCYK28hNUfN2scwyuhE8kNJyaJaRlKf+vp
	uxy/RFGZNx6uWRgERmZGYR1+W2D/v3Vcvx3Wz8ciqPA9OSHGgK5LRrt4QH6X
	AOtRCUeo3fFoROM4veNetpNMeTIIJTUNx6VwttnocaFOjkrdv6ABByBr0jUe
	VS4GW9dcjYgZOGFFnf0i7igfPiUNN6jKrcVos1RN0uIBRhGisljj8qF6Vcsk
	vZ1HYRTl/xqLQGM8uQ7NZA2F+VoW++Fb+MhZEpwcAIyzL5VM2JCAcir3kpsY
	wydKz374VvLTOpMLMsvMRKXS4pjicNXdsyprSo0aLdFC5cs0SMCNK3xVjykL
	k4qBpLCYcG4eSHcvuWQYYsJ3EU8DsGJjOWYEkDvYuvH9pHvqSaJ5mM8byKcC
	dZHVXf22LscNmV+uG1vIRiXYgongYVXYpxwDXZdvT+pd8+YaEi9VKinX0OuN
	qBLJBKWFk2YWVmhGylHd9F19pxilGlBBQiLRjumBiZZKcg5G3HqbyjXu/QjC
	fgGRvYMHVMX6VtGZm5YLpPBSmEoADPg7r1pauGorx9kMvULdinyC0Q2P0T7b
	csGaHqMLHd0MqB4rh2cTS49FGDPrrBQ21kxa3TzOlRxsHUcuLv0Wi4qMzZML
	1jIU2T8aEpxCmaavRtEAW4PtjdMQfMgs/pA4M1WVM+byEcwEo63njbfeBVeK
	81J7cSkkM3RX1SZlXdRacFguFzPJJeKm5ilhjKmZ6ja+vP0FnXTiucKDOuTS
	9QDDrz0RzgUjWjpva5eKOFW/xOSizV2uCGk6ZFZKAyLc0VpCb1ZlzUKODwsj
	U8CAMfmz5xAuCiJjHkiAzKZFnqMGVs/xrsr7tzcibIWEczmOwktYm9cMFY8f
	AbOZzZbaEIZcmXKv8NmvX4/w1HGkjJEr9SWk8zmmQbLb3G+WH0zbJRnpjAms
	pgU/NK+1EKINxRvOliZO27uQ9GbLLODfSUd5X+im52yYRcdPx6IPtYCPjA72
	61OWLYiSgwOFiuuiCwdR29HwLUZK+Un0r+/+ae9S//d7MiK3wkX/G5ugnoSZ
	fknowy8iI/lvvdY3x/1/fv1lSasRb0dP4Y5/a7dI2tbIz/NXbln7tzbOuENw
	f/0ftoYlgoAH/k/65PHO1V0v4X/tfrExyWu32GsWRm2KZoZMPWKPqctPmynx
	BUz4LkvcX7GocqyR5S6qGaGSSB4R6DRUOSjplQGjgqK9NpbITwp27y+klgKh
	kkatThmngfaExWsOGInR/iifAJm7Hm9gkxdYvXZGkOpTUNMy99ZWMHQlxbxm
	u1o+ZfBUs0chgyWinFcBUOxjSv1kJbpXzZ5y06olJ5P8xcuGS/rKhaaruzJa
	hR4lYCdrX4D3mUKmZkrObVZxWpOKPeKW/12zOcpIfuJppvQmkuS18/xjm1/G
	iPS6Em6DFQkkNFTi30HQdzwoH7NtS0CGGdakB8yLuS0Ifx9j15kcIW0l7hYg
	cKRYLlLItJzgQM13WUgVoPvS6FObmLvy/9ryKwgEOR8rjwaZ15dAtgTlQwc7
	ke3UROWRLqh64GIBnNc+5222MgcKHhJUS2PHtgCgVKuBJDPQJc1qYT3Z2LcH
	Wz8qq9B/pAVLK8g2malCXGe7XICWPJLU5wU5K9Qu+qQJji2pS5GXqKdKBFTJ
	GhpCBDslJMDMckeWKpPuIEFHN8wyVHOmqUTSPfhmTCacyq1+d4cJ24FzY+q9
	aUZdGwOj2xEdVCslYsWodsdAU1x7yQr7umILU8uZyMddLIpWHwg7ZzivM7R0
	u/qbPjxcfTi7+dEwIT6eXd+cX8CfFH5PZ1jCvqJ+OAJRx2NSAzGY+Q7TytCG
	4kIdXIRBd9m3JcaRpsKiQpeNzamysKDZHvvoHtMqiZdbmMTpt6LadOhAdAww
	HsMdAnuuoxTQUz1e6dNiqdDqtfOH5ESL11CbY71bZ6I2WDArMSS/k+/ylNnz
	QXv0OZ+HaE6nIeNK7Szn8PFFYc1vBz3O0RM1wmz2reRV+sfSWnE1T1q4+AF1
	oMHFQrJkvOIiHQ6XVHQWYqck1B2MjRIF112wjy8o8SRFLHElzJieO6QglRWe
	qZji7LtxWm0OKopn81nU2gjjCXeZX38M3PuKhMmsvAV635Fh7NoxfuUeuO/C
	MUMyEdV1oRlsLTDYSsJQ6hNl2gh8lo54WGeKlnCuk9zn4QfI06WwXIRO5dxS
	FSWh8Uqjn7bhPJ2cK9jlaQFD6XbFUOMddCZ+6J8+XPzbWf/48vLt+cnxD+dv
	z2/+8vXrrl+N0OuHwELNRY2CKANJVwuWuh32fNih1ln24M43tvXxJd/satGf
	R1ERuqb2D9+E75hTfRMNNETRdpzk3/X147+HMqRBxyNn0Q/icMMgdqqsv8v1
	eC0YQ8dS1qpPn3GvGqnTrTLuUB98JMJTSYVS5eObv1FLdHd0/wfDgQRVENux
	s+9+ROZcdI534RGcpB/uj04o3j3n9nH3wOeXs8f5FBxjTPS7T1f4ZEbNb42M
	qDw8fF1+0lP4GX5pXmB0qZTItGVIqPvHGgPVQU1CChMQGuegaSdVsCYtx8m/
	8CXv7qhc81bF73QNCaiyVqKg9xpxl0j4NIdrgK2tXm39Ny49dHpGaLvarQb9
	miAXf7wPakQ5UlMOxqZFiOz4Gj7vq3jsPaoQyJl2egGniAqcNEtwEuLp7B4R
	y4eIbCAEQo55UrkzLH2kEmv6gluedWEi6rMYMU6xz2gNQ2HcowOvOEesyke0
	9bKL6/Mghc9wIde/VyUYiA0z2FIDmVb3122Ga12ChH2di9M8oCGrcqTqYQdw
	rEkUI46eyxz4FTqQwIz6+GGvSwK0nuVrPthSh02GWaaA8uT8RPzwf+hekzxy
	cOJ1ixe1DjmOwh4cWrSpUS11i0s+35J3+SMYc/MsOY5jLwYhsR59gW9f67f4
	8Vc67HP217soi4I09VphGbH2xMpXrEyyXMSHGMGxZuah1xADe8Vp0tWSMGli
	PMdKTGhSz0SvRyRb4OA7LHsYdukWsytAvHJhermYMorh2hvv4E4us5lUGedV
	BCDOwZa6tMZcQMx5mI7pCpAqg5xzUmrlmTjGwIaY2eYiWLbX0u6+mXItpELm
	YnZnMcJjO4Zt5WRJNd0HW+95t73jRGSXxjUC9Cy3+w3msME7O58VZ8mgbSF+
	C/o+rT8BHZ2S90siUpx/LBq8rmEwe0xF0uwbc0JK/YWIAkHAsCxUzJW5YzIl
	kGWwQWecUiCI9NSYkqA4uIrgzW3e7KGZ+ebt2Q8/nWGuBzsW+Cm18xKosRkZ
	+NTCN3P4U22unTeM4Ict5lCMsW3jVoeixWv+lTre+mituYGJeMN8Xry6GNIi
	FyjjmkF01bHRSE+4CBiiAzYe/q6WRMhhQbHRRUkOQDu34V2M3EKRY7Y/W++4
	XY4IrTcwJNfxjUdHxXWMJiWyy1wIXMNOv1vXixTW5BeMQKqDTFJy0XOCnE56
	hZaErKaWrQbOZNfYyUAxs1rbFAQwh9lKcFfYmbIyPAnXxKXC7g4Vg7BEE5YV
	R5v7dB3xP4IxC8jDIdTqAYitSL2nfPt2mc9ovW6xO0ttPY43pF4A46Hgkn5L
	aYEMa8hJGSTfuZ6hRF2M0sOIDkZoc4UlRiQzDNfg97RYIdksC1U8Hg3JYdql
	xYpChKyLEuYOC03Bt+hsskHd59PZkpUHfXedDauMXAYjVy4LW4EsQ3AWapsR
	5nNguYkiC7IV23GDOp2AwqrVovHnjStJHVxS1cKiczoluhPZm0UuqFlmqLrB
	gFakymUhL5NKhgH6SWs9GoQQUoJQUKhCHbJ2i6qzSF8RnMVbbkzuUh9ZmaWW
	Rqn0HI/fS31Z8OjgV6olra1QT1zrbtnTZQ1zolbjjHLNXbxYSd8UvvSKAX7H
	igH58bWPRGg9PjektgDVyKFOZuQsO+iIcw6AckVl4eSjsmfwKt8YEXJ+VhFB
	gvAx0Cm6GKq+hTJhODOz1TNB4T/ipgOVcmIETHKY8ig3aKxcUJrPSuQYx3UQ
	iSZ+sHBruQjyHKljQSAUdsZmmGCkG+qONmWdym3crq6k07/+EvWEK7Ya8V5k
	yQa2RuTMgL6GfXo/XSWa328BcZwzGkGsX3GnqRXn4+GbaNpSTKgpsWvET0zb
	d2gg6Wnb5ncMnxPcRETNdU5RZtihuTvMEeZaONChFWzLglOEJc4nbHsdsSJH
	5HZwJSNX4ycnLC9UBaNQjQyMpxEyKZCVWskcP1Ei46yXwmxRMsmD14p3WCGS
	1OKd5QJTHndDGY8EhDx6Nylsjg/fcmc5HBl60+Xl2O8RiQKjv4Ldbfvaky67
	2lEEU3LtK24gzLGA0DmXcKaSog/KMt/bC210nYysqfOw8E0dK8qBjGFXqV6n
	IEs640gTa3biRwzvE0NA3D2ePBV3PHo4P0UVNv/8yLt4ff7m4vjt16+7g4A3
	nkjFBPVtMNP3dpbfEXMU2V5jYwo1Od3rGYQopO7rY0ItJc0YtALaEYcuYekW
	/CB2nZEpj6D0GF3t6MPAXWxG/WlZNxrBo/GPBASRTW3dj7o0K5KhDEcc31si
	5L/6MFghINgvxc/kJ2QjDu0WauBQP0CgcvQhKL9vca88WEkhN4nJBFeGxE25
	DnULqk7AGZ3TxIjgLJggkeBgZTTxURgtXVjGHmshWnUwIVflc1l51MIQqVdj
	QcuFCV7kltD+1KRxNgvyduQ5aTXLKS1cByDdipBgtfCvLktqZ2f2DopkPdZg
	0bmGt7iIeWH4YvP0cz5nM5iB2QLh+6GrEqGFzk3GLW5mFNogjFw6GJQYDsuH
	KXalFT6Pc6BQ/EzbumwY5wfBQIDFa5JPRXk/49YwRn0wiWGU4E6Y6d5IxHyy
	Josx12iVuo6WRe3az+NijqVUD/0ad8fywpQQiRzf7TA/NzcF8brPNeWsnmiS
	UlAhI02N1FKf4CdZqg5l2vRKMg1AT6DprRXCgAjLGA5bVd3jBb4weQ0v+qSm
	r+vJZxEeG4xXrdYbM8zThTs77Wy7UHidEsOido3m5Gl1BtRHOG+FoM7oshuA
	RuzUIYEdJemN8jnaFpKWa4kLHMgbTruXaNBRvOv3Dr/4ip70nWta6N0NK802
	GwoUCfdrssAtqfGksVpUepMXtfb6qFNhpAvOgMchsmVXRKtj4JYrJ99gob+g
	nS7SFeoKMYi0tLOma9txhZ0RGroaBnIN8xz5u/C0NTPFgz0TYKVi5aSRe0F7
	IvTIHcT93PUGM/vmrIVUNW+JgXot253nIh3HNI9itvJpATJdWw9m43W5YYr/
	yJy6I76emq7+BLTkZJcAM5Bm0xHxUBmEDTLu+H0WecSkbXiIGXFrbCA0S5Ew
	0L5GnIdpsc7QPBxKvsgwuZqjdgy/SKaoAzbxLyIG6/oDkKHl+azUysR84lUY
	176LhFMrj1gbxxO8U28m+xAcC5+hAxV+E4seZUTmXniAATi84VMu/cPiN4oH
	JgYEbhOok1T30iRJ/ZmywityTrj3hlCvC+6yI0UqlrN4JO7eEKH1+WFYsaVG
	HBc2a7B203Oe23OC14HJfm2C5BgL6iFN1zpYK/UwnbkXvAhURtlrAfidbaFV
	a7FvMwlNBaQnU1o1wPjrEcbomGV/+/p/BOw0iPAu0dkVRmzVRuFmSgISxiDU
	LHOP6bPPvl4VTfpZ6hXU2BAb2rIFMAR4m4mPSODSYsdkWW3cURib4fhvvJfY
	kx6TzWInki6hotp0am0gzza1WAQesrrVNgq5sBWhSGPirNUUhXavY1sHUn5k
	/u3rdJzBmX34tqZfOsqLtuCPRU5H1deRuEKgPKpMsfhWL5ku5xhARxhPccFw
	ohG7RwzGue0T4aG0nJypptUQ8IG01goR4aKUt8Hec/YAuiMmGblczosIdZB7
	MOfSCAQzYTTMi7IFVXK19+iRHYE6VCL6WocfgdGo6GJdnGrcqPS7NSVq/5xh
	7Te5jOp7rEZl4BcckkY6DAiaw4MFd+H1vZcnZTkKkSx+TSgYspl2VwZF5SoK
	jK7FYmhLRhoa+RkK354GNXCBqq271qwqb0vU3K7op1jVkpmJfavQiqKrewGt
	iKp1pWUdmMBID2g2IrOSLFLqgJBWitVEZhAYY1QCZbGTRgrcqzpz+4mfBqIk
	MoYFCKUTPE4sfLLIVs7O7oyBMGOKxvSqJeWKcewutrnd4vmGTmu0EOV38+7i
	dDH/AFNkNMqmYOGyvpikTm81U8G/bkNFjTv4XaMINpZ1Qg2GkmaKm2inoSLy
	cJVPyoocQOJIEo9fo/new4yaVchZCbp9nxwIcEiU1dtoLGDCowznQ+F6LV7d
	1Q082lxRZzQ3hUCJnVq3LWd+m569jS/cphupiH1EgkdDmLrvOvv7FNE9qKFG
	Gfe6k4KnkMod+VvnKY3PqiT4mK64io+DmgSQP814JOJmEPIk+qf3jbjNM8sT
	dX1Y/Sf1+rE+wtFGk6dz6MNl3mBwwT9pUkMMQ2miZ6nlceY+HzniKJk1zZDQ
	RIsbBQhgnXrU6UT3jDUoOuXc7RanHVwuhgiahhRzSfhm9oCuMqkUDXRMZrN6
	S10auUWwiE1FWiZXSTPrC6J8QliBYe7iixHTw9CSOJeTKkD08RhtmGAUcLKE
	Ewpkg55lYd1RrTbrBKZixCvcRpPxPj7laKMMsbLjCJNaX7YbJEo56rGZSzGG
	hVTQaF4x5WvUvhGFzQgO5qllfcjDhGI1lyRkN6nuMOW0HHHVS+PVUVfesrpr
	DRCM1jOjHHuHGIUgMqGmQIZxy12wKF2wIYdsB+pXEL2YIRIrMibawlipGYEw
	uPZ3dVNyGxhG9wQamGSYWVGGwo9UXkEQVwUouhELw8M+tmsYB44g5FkBkWn9
	vSwyDn1Ffbew8iruiyq8lRtla2RUu9ym1W0Ok8G+tYGeXMKZo0F2m9MBc6iU
	cWm5pDqZo2GG9apNSYdJWzebs2McKrtvlxO8CwUOB0EI8T7gNmLakWgXP2aV
	xrDic4PwClyxTFy/XBJIxzQbfmKMFtJzuIk2YkAhoNyywMW0zx+p9TldWsWO
	ukRYPefdiNKNEF7M5eXIHCWk5Fyiac6w+74XrgaoY7c3o+BPNCqlLMdXm169
	Pj9VBzVZexWtGvCvT6Ajhww5GAoSUY4Ym9iKGGMyRupDkLJcdpFOmM8WcMZu
	V4/kW1jvTa6Fx4BuHE53BSDSIdIYXABE9rS3oV4lQAzykoe8sVYvei1c0TOg
	Dl/mFkELR7Yguo7aUiNat456RW6lfJ9EMJ1Mg0rC/DpV1R0xGsYhcNa7DAwi
	JZ02vkEf+1EyhJCODHM9MCOmg1J/reiCgNzY8/MInxeqsNYjsk2syw0F/E6t
	U775VXjDvr5BFqwjYdu4uiRZu7sP4o40St2tEd4qdFUo3w900yG1UD/DbEXO
	v1ob8rN2GxzdvzvQeyhdrHNb0qbFP1Rrl40JITMEsknOrXrNxrqOjvPwrX7p
	nTsMGXIigLan2lHpQtt+PnxLWJydlrtcK7QlUIZZofBwbIhjHi73BNn8kh18
	xy6oJ/BDMjzqNB/ZY612yz2d4Fq5QKCvjaOsIZTHsArNqtBdQokV+SQvFMST
	pTM6SXpMhzxsOPuomCanF9dCKahfaD9EglxXm4xyM2qKz2IO9WxsEUr/osHW
	D6WF1hBojsqQ8zs1+qXpABXEcs6VJJKxDkj7ySl5YrEpd1QWtm6QvdZaawdN
	bvCsoyodY0eEBBZdTw8jw2FQkJuLJjumEUl/G3IG7FIuDTyohWWo8S/zP4Ze
	ymkUmuKSP9xBjnYGQFOpI8BbrFI8WkYDIIdR54zHpvpoYf4td02VmX+P8dw1
	UouBDeAd5NWzrSSUItBd/Thke22dO2tz4U2UAIPpkrl6lQhjhugwJGMFGzVE
	Se3QakUx+qxQBvsnklPnDaenX/NSvEWC/iGdiTDfeXP99oddTMWFn1LweVys
	hth4VRbPRSY1O5ZCA/BMg8W2JBhP8ASY2FqRZEfb0bYCSUBMP97cXOp1u1Z8
	jMaKVYtxvi+unB4QZRAEH8HblgkcfQ2ykUW3IO9K4QXtHFXO/yIjlU3mrhGO
	kvSP8h5sZu2EwXlA0gOB5I8bEL2lZEgr4r482ZhatmudJicIeXpDUZmjDaAh
	hHmGRmde49Fo6mw2ltx1qW/EbAFkhbsqIBm/mzuLC1CjZ05YaJ7fpdSnwbIq
	DcqrIp3QmlAzpm4cH7GIVyFVNYVh3EnIYyJ/YqvyBiF2Q+S7wbYHnFz7Ggat
	JcVaSpwGmPSoG6I4Ic2rCKZwZpy+J1MjUWYVolJK8JbaEO7vclCSyJpzJcOK
	NyXmLdXcyA53kgDqepLKHRV8i6Ubuec9DJqcmNAjnlpcuXhmHR0QrRf2dFch
	fFqGDVCcPLLjRWPU/o+G0Hq70jCG1VXEhrl1sw3N67ljBdg80niT307Bcirg
	xd2kZp9NAD1gl8dg6+com8Ht6fX525+u3h+fwr6qLDy+Pj8RgUoNZGSNRD6S
	eL01bsQmfVhzGFfNqXxDUeopaQTJZcjWXhOV6Lfqy08unNKzQWtPsOmGA0wT
	oSVxHQcIqCwdY58s1/RLmvrx5eXJ2cXN1dk1IjIabB6IrFjgueK+Vjs4VVNa
	/XnHac0ODqIL4tkW5ifK4pZ4TO7SklRAUXZ1XwcyT+49Gg1Ac1Vlv0baDIV7
	hOpqWKN1660XZcKExpHsdpoFCdCE8jFZNquoHJFz1oHho2dEIOO0fddwWiIm
	w/o+rb0otRd0PFd0D3uscIe7vEIGzcj5TtnY1fe2u40GMAUhYKWBACEM5JGt
	0QPs40YyaMootqZ8pYscblcO0DBNtum4qnDc7lwA6m1t4oBnQ1D18Ig9S6jC
	q+gs1jksiJUzuE5ca0+uB+ubItw2tiGolMa4746mGJHsCH1AJcpD+Yjcz8nn
	4a0fsfbOhGO/x7553SDH6d0mBXR06TrJc9p1hrZEnybw/IX2W5jmC0/5PTpC
	LlVFOQ+fpqgpcSVJx10yRPu7OrmxyXbuCKN3xMpdywTpl3D1p69fj2THwM48
	jBAPlFm/3Xc75egSDTEQjJwOIkjg7rZ1u5GUOxQLcotrQSz7pR6HaPlZvQdq
	XVKugR8s2fFp49OM1bLBPfD8x6RlmEs0ODmhrIDshtJq9Y4ERBgFLbFEau0G
	H15XUiSDByJchdthkjkgSYbXp/H67LYmdyCTSyvTrwKsFBCOHnnqqaoHyHev
	iZPxOGvfrQqjivqlZndlaCdvzeV5c9VdqRmnWJu5iX/JS8KBzKJWSCQDyjqa
	lDOw9QgEyRL6D1DufWupsIs2pzVJaj6cHEm3C+j8AaFOcbwV7984mYjzNhvZ
	zKWpCEViwkXplQM1bWZl+YlYBVHDKwRKrsseZyPdq+s9ajfKx0vRH/w0Jb2I
	90EVvluBy0CVfmzqmRb19QK9d/C+mOhfySL6Hd5zmpMsQwe9Z240K8QzUxoH
	kiczSt6tqxBP67kQOtY8aKBI2iUy0hkygIgLeco2xoNEQ8mdDUF5/cYt1Ng0
	5nOjtwwxJ7CNXJUFii0rT5zM0qm4heLeGDKuBHVyXJo8vc111oFXcKoULDMd
	1v7r9LbKh/207qf9ayHBnZPXaXq9i+4y/KXLX/az868kIixdmq5rZaXloOKu
	T53NjEI5MOAzlEUF1oCcF+P8B+o7sxQjBW5kEX7Qi3sCsMeBo58UMdCHI2Sr
	UJjseHgTF9UHEHvYtFtZJ+r/46pYji/PpVgmoIfZk+sk9GJyQHzTVj6XQe+S
	xiOKEiLnik6pSGKb1hBk7qXhDXGKstz5yE0uLVYNX8oOGWkgS5ok9Uix4DB3
	qc18KYfE9DyBH+vhRsJ0lpzU7bs3sXkTlbyq0U9Uy4FkIqY+uX7oA4rr424u
	nFdLb+tF1aSs9araTnGgRUX1Bmv77LbATF+8V5+Mu8nbbm7SDrJVyBRnfAjI
	igSLuWqr3f8EBsi+nBYRcANnbrWqHbyDc8AycJzWGfJwWES1B4i+D0Qf4Dio
	90dy67nNjtSfiUVkyHb54bQv8ZYgQ88KMHQNNA+dq/wRE72ldFlfN/bxoMFD
	5WvkQ44WwTun78MgKJa7DoLCo7LnkrLK72+ltkq70DZhxEtlsDSaHuH77I6J
	B5LLjmJYGLy9l5zqsFQZCRvKm2zfKkuGgX2XHkZOgzAMbpJIyxwyWPV+JskQ
	lsyqvsWVwiN27mnDZBxc08mxMtQr5PWS9R3gDuXyRYlZPaDjJeunNbyCwtKE
	hNmQ4yVKnYg9KzZA5aMVqPP9mkN40eOxL2A25eTVkAfHCTcOuEEXjreor9NM
	pf1ERrCWeU3xX7u4SLUlWFRqousqjZqXlRWWYqnokrw33DQGbScleiyYaSLq
	8vlwukpGlTv1ruWPxPSqCOjsYXMNEGPzMSJSTIV3b05Hv8AwmVRErK0iNkGZ
	PeEJlp+70zq6u7oaKvcwzx5Hq5HQzijADR1zVn58QnPkx8dRU40RJmKwD3yH
	QviYjLFrZrfzGIoYdygvilfFm+QA8ZUbFpMO/seI+eslQgpaxzAjr4nUWc/q
	JYdv+m+PL9AdeLzfP3wDv3/9qnKdaGoIgyQaBU3vNiNgL0tXc6OBb8NAtGWc
	4tPbM1jtKStWH0h7Jev3/ORC3w16OqPTL6XDOPXCamtsAVacNAiZhVtTsOLk
	JvxCB3rHub+MECmlr0UCb5drkdLYg3h+SVSMYQ51L3q61KZN8QK3BBblAGK2
	DA3YUl1jjiHz3dg5cbAFS6uqvvnAgp2g/PHh4e3+R/iaPFg1yRk5/2rxGlYK
	0KFI2brs48GCz7cJVKXPDbq3Y2WN6Mp/ENLGaQm3NWnQeoCSUwGWciROYE3M
	V7m2rqSR/BFjRWRPkmz9k27g9hH5x/zC7HFVrTpWTe5hCTnYu34MWzhRzASF
	3bieJmxu+9Pq17jnshxbuIHaLLUO5npcZkjCS9Iu19uYSxcdQcezo+oyoNZv
	CoZZhyMxdoJo2kXL3fsrDnY+xoLNtLPRc9uxSxS9C9skfhNzwKyLoci34fMI
	YgnhL3vEe4qLefD/hw+1PdFRZll0NNEub6bZisFFL4PxV+1Id2/1NCc0DNIG
	XKizaand6kKodyVZ7Xblx9SUDQGDMAYJx2TRIasGaqxgb6CqDL23w8z6Wnbo
	KJRnX0uvO9PnnKf5N3jFlIXy64ijKBGY4wpMBoEp4Q7D4Z00ML5qrdUbZ18B
	z1lmPMv/akfxvnMUD1F1X63R9VpPZDq/rg992B5mWq+i5+931tKFKFSH8tVS
	QFnpNzNSh4DGaWCNO0xt/mmUd8qJ0ZRKiKl/As7blL1gm68bCbs9VymG2EKY
	S+Jq2HiFVMy3G1dpRFXFTBeHeOWqQ+Nxc/FA5FsJkS3x3G2AmPXLfrDm/193
	5OMZzjt6hVLCPcMau4Rv5xZhJJJ79UTfZmsyg1VLporMt7b1xgT7TXV8bckV
	Zhm3F4tETzzpZ79t0sIm7Bhu4Akke9VeIhZD/MSsGbak8eaWwGA0lbTGpMBR
	iFLHYw01piKCNOE+5vpdGoNXEyUSE9k8mkgJVEnNfxwEB40Rw2QuNX9dkPnj
	R43xkuQja5IhRU8aq5Ga9vAtKprwFX4ors7Y13lD76nmyTeikoYeueE53yTc
	KkGov7QsKZ8nc6uYiTxsBRDiZBgBzYuLXlm/yquk9WrJKl4rRw7x9uTymX3T
	A60yK16jOK2Ws4w7Rxro8Yr5iGW95bXWqzICCBc8tPp8uCwwhZejJDxrhC1Z
	YYLSEo++Vv6CI0FliLBsuJQmXCKmA3orzVnJEsFZj9YGe5x/Zv/tfY518HVt
	F4EoegTDSaJrWlQXFdtT3zHeq+26PQnq+3xMOgo8nVONpRM1EzAHX2jBJdxf
	cMAt4NhybvWQiwXxZpoQBRu1zWMpLZqNxBmlh0s5qSciJcCTGsr57zCs12w8
	UprbgkteMCqhD+W8opQSiqQPClsjHrQMHvOB215o618LQQfXEh/qPR9+ZzS8
	silB4at72sWba2vo2ViDjEunXV+Nlyl3sseb3mV9ofQb9wKkAEqqDAl2KdW4
	FN5U4LiBfF7PCGnIgaTaGJZ1JgUjKYJ60pWUQY+5DiQGBEQKd0xVdR2NBlrB
	yN7tmVEPB7GF+k6SQHq9GiC3PmRro+f2xpezGuKNFjrAQ5VCPYXPCSPjPgBJ
	wr16im2Ih286jiD7xslX0TbGzQm0Ci26Ar8hvjoDTWKpNBUXeNYqYuYLNQBo
	BXRYPabW+KwnqKss5i6F7sPl611JQeX+KPK53LeYlgIkg13cR5KJhZ3sEE90
	14p70lApRfkZbZgaQQtd1ppHfHlxihmEIuQOB09x6R8ezvungyq9y/v5sKgm
	/cPJEH/7+lX3jMkqwCGLBIOl1/eHOgwrlOaOzAbsATRM+6FeM0IVQ/q9R1Si
	0JGUtOeb6/2DweGTp9YuRT7YR0eLpVPz/qqLYAhaAqx9tScaAkEL0BnstUcr
	AovxaGTtGMtL0kmZxEASMDo1jYkhKD5ePEUA0yDA3cPs+UFPSGWQIX97wnRQ
	I7fg17PzjXKxMaWLRrMbwdiwgJB7JagnpGIEBMTyAdXqM6M1yrncTT6cPQWC
	O9vH/xzQcn44eyZQaRwbwG7Zsjfupaf05Kd0B/++j+o+68bwiF0RuOoxY7Ua
	sUg4KZHcFdgwmiHBOOQaIVAtPQgOneSLsuhfLkHzG6rGMxAdhpaaOJxTDlhZ
	4eZXkv2jWh9BvKpngdcPJyIkI5XG0cNNR6tt18KrgpUUH23mIVb4pppQ3GEw
	arn3W/4N8F9yw+MayL9HbnXjPOr4+uiRWx0GU7j1va3iY7e6fx83vPU76mP3
	XQIGTxW4gnzs/n23fusXJNxfvXKtT1/01kev7Lx1w7/fcuvvfOtHmev+prky
	Kfpbowu/+5VXvxW+4m78LurU+GuzvmbRIh8Aqdn7v/st7299UIF1i93s6U+Z
	+sFv2+bjy/Pw5+9f8F+d8OO3/u63fgc3Ief9h0n6y9aXTW/9tWfhrb/zH976
	es0wcSby47f+hn9ASkoNtrV063ed01mba3vqsMJwg4otP4RHnvrIWLvu0hMk
	b/yP8EY5v9/htPTI4Cf/e4elj/bw2Uo2PVSn0erzaXqHtvgEOdlyC0ReAWyF
	cJdn99jrc3OM1Lyb1oQbO2kuUd3pSfiDdXMw/B8erptylRblHak+BiQAM+1w
	J0h5uMKoqWJvMjdBYwCMrwCW2UNgn4BiqiFDG1mIY7FFpp1uumyGmq1ykdJS
	Xcw2uLequ+JVHze7SIL70Sr+JT+SSkTM4mfDGj3zpMv6J0h/1QBPiuVtMyox
	TdSZ3kYNc3i05kYIaqxY696HQEhtbSdCpNWhh1yr6lgCICSX9IpkFNMcgW3/
	kJyH+v+oUIj1bMvENiBmdGWLCl7v6WIRLkjk94j3hHOLUk0rEUT7Nk5I8CO2
	MBycTp/dKd1I5RmVbBFOcwRloFgnIZE8nhA1vOdqrjWPjbaxkrxT7r4w8sRh
	0fD2zvveCJfPcH0ZOLZFbFy6oG2iOyxb535ivVmdNeZf+FN5zY6R4DYBVRxW
	Kl74nuDjhcx52+G86MMhw7TozVstE9ajtLEi/ZAr0j+EiSjPOsYqa+yCgL26
	u46ydfeRV9qyMN1Tnax8gnvARhmvmFuwQRhb6GVuFjRlV/nE97gwLzqQ3v9L
	xk3LyrdmU+Zssjo2nSrC91IvbtwbX+7Dvn+2oMW3H5Yb3VZ4Axl0FFjBoEop
	DYwN//KQS/OvFzNuirV36ur9Ni4yvo2hpGPvZxt41LLZtZYPQT44hNiN7EnQ
	XRY4Jptwri3MfSXiIImOtI6La5OlH9WtxM4pPpEStBjhnjNcs6bsDSkVXDH6
	dta+pISYUTbn4jZXx7arDrXU3KcYHODqN01loZR3QQFaP5e/lczSAndgR56j
	bCKrKLVN4faGv4Uc2b2zpB4x4snFHtA4akZXjqJHg+TUBXm8Dc1QUVhTKo4O
	9AZNkTlN+0NgpdWkDzym7i+eIQmYR+YaCCMtUvh7x+jdRYyIGHc9aR4cJe8I
	jpfs2uFKo8hHIDB9VkMdgsst150Qg2gfynLJB0CxiJYeIBb7egSCTrKI7OQ+
	1ZYMSumdxySkvCNXAr3VUOnQe6KxGzwag4Sh9F3w5D7jtGKOsCAZwgYwNnEj
	i8F5WKw3xvpWx+GqsjlidzPGeAihxSEydsWNU+pmQXFVK1IJWZmbtu4g2rpn
	wFXEQ39kLRP9W7qCIIwvwtBLVlhhnViqvP4UcVRU25CYiYxr+m1sDDSKwf3i
	KiHZ9U2e9HRIbcQwClnAQZqWjIAYSl5sOhgDbEWQBA/2iF05bYIREe40Nk7H
	9R04YuJLOd2ujBz58joUwq8S8p1xFxpMTrfdFQnB3IFbn9Uy4XE5XEbw13so
	3t3wKSsyOdMWtejn78Ifgc/XoUc8ezg+T24wYM5BRhcdPj7vqqi4CSBIiKpI
	9Tta1eCjbvM0YPhz5pOpXPDGRt8YjZZbvEYBao2sgCWBaEl0js1nm7d5JoHV
	9qkhiGyjvUhFHMMY4kYUUYWBqliUhyBoFAhGPVkxtFQtVSHswK0RPpWh66xf
	GWGQWWktjYGptmumnHWOj5F0vPtUMOLVOuJYvt5N0Zy4Pc84lKVaQfMcoWTx
	qbW4ziWS78BIepo05B8mashvTlET13BJbfMcQ2+pTQjStDHDP2Ho8ACPgYPg
	igVWUTFP15fbgXDnoDqpC7phbCaCFs+VO0IKIjGlnpsOFyJIkLYfeh5bwkuV
	IhIgdgFkgKo/SQl/lJuwsTAqLwRE6/E8Au71i7OkwhVpgS4wy36yfHpQqvVh
	lP3xzDo7Er2lLnOGDkOuWfu6f6QeFwk7yxltatxQSI0Di+iH2aUgiJnuRmnb
	RD7brCuWDalj8UFhGETY7nTkm1ppH2JuXE4RmX5KHXGsMoeb6GUjdpwHLZNu
	tYBvOLNqSAOtNpToAXS5rfeP7MJtgXJu5fmHpgkao394eP32/c9nV1+/Aj/5
	YNyKWJocARpiKwnUBoRJUJjPtOug9iQ+ZJfcEY62DpFix7OE0t34YMIg3h1f
	37w/fX+BEl8TA+CcJFvHuLEBgCLC8HBZKrRcvc5LpO3bSraNUOL4iMQs38Zr
	PDvUnUmo6B3o0uUIRdHG2cSTwbnE60BUDdQ7wb8woRr0akIXUYxCM2oec17p
	sQ/9KcJYbwiV7DWlJMi017LYWuKHag8isAK/HsJbrFshVT/My4Dl4Eu5jNI0
	zG/jmlxdniAqEPzghXl3eY6LdXkOfxrsD8EgBk+EFs+RdOoPMTfz4vIDAkIt
	qwC+SP248maX0YnSW8x3M4QsfCpMx5YKG7O5qoiUE+4FHGwTTXA1hZAB41WO
	1TGnAu5QaoKfw0/u2sDFbbGZrA1mqfeRe7k8++DN5WVyffreO628EuFdgXj9
	2c31efLu7CQRGD1M0p3zCrJBg5Bt9C57yj8LW2KL8o/kqfd44rCm6sERBm1p
	h2Xi4A40sfxRpJNHEUJilKc1pJCg+QvwHYZqI6eESlO4BkbNYJHGb+LqeJ5J
	lCTPutXm/PT2anMG6oY8a5DRc2qp6Y45cJF+U/ap6y+oVijU+4zW2wvnXezs
	tbPtwL0fRSAK8BHtkmhLw24VaftsbMU0Nzx0ydVyYW+uiu5RTMpN3ybsu3I9
	hnhC/hVOaAMzU5IJKC0Rsy9AMOEJoIs61n7juqtFabZxeCEr7cEbycmpm3O3
	kV4Fb5dacIGCnBLeMi+05cB3pb7fGuQzycGuxHdCm6VH9Rl0PsKqsEX8L8/t
	fs4gIC3oiVb/M0T4Em1UBJScZKbYjdvhkFi17KSM+lwZoWki7qY6jkjT70Be
	3vHUyc4JVPVQ5Gx45O6raA1C/rnWYDE+wew3nXIpQE0XOTagtdRumFxG2ktN
	TXNN/62csqUnWxZ2vdw2c100xJpzGF6+6gRl9dnZBRi9X+PJKbbIunHd5sqb
	56pUMBY/aVvyKm5y/OaQaq1vOT7vd9T3+yxDZZiobgBHujp9dxw/9HAzVAqJ
	WWQbZOwcn/ssePbQtjAH2yYifI2NAdK8sAyn8ASJ1DjkoFQzK0cB4n6mmAW7
	65aTAs3gglCHHfWkc+s4xLIgZNZLhD9Fw6daJSfw+ElZtdS/rggG5zeJWNWs
	4ZrCO+Fxw87HEe/wrAPGPpshZnbayii7+pMOKKvJCDmW3urACKtsig3fEFtR
	+/FaVDTABiN7ZCwlqwuBTbh6oyRHoOzwvg/XZyfH12fHF8dv/3J9DkoJcV18
	IBt1FATmKOxI8QEpPI/YAFUuYhrGAG8ro7QmlF5b7Uj2P/7vO3rGhnD8sbSh
	ZiflMbVM6Pgnzxj8M//kGTfYkJEO2Rd+v6RmUCP0hP64En3vf+BfO6Hzxm6y
	Npcv1NZpUsAvl6EB1RdNeMY/+PGSnGNz+WfX9D91Y7yb8MSM9ddXx+/Ofn5/
	9dM1nb+3xxdvPhy/ObvGc0lM8r/nZPw/4PM/vD2/eJPcnJ38ePH+7fs352cc
	SNUJrFPZf9vJ8L+P59fn7y92rnc3TuM/czKdaSueuWn+SkcDwXARZa1gVua/
	/2F9+P/+B+W21ICb4x8WW6Pa5Glq5ig3XmUkZ3HQU5coMngEjY0syM6d1xeR
	T6XuVAYRnEr5pIhrTeInDr6YYh/0En6gGHP+1rWmaPiE8FxJV5EQqug31nLU
	F7NbToJ0VHLQhbZo7A71lzFkZW2X9nx/QW1GHNJsGPKa+/EIfgy3viXxGDaE
	Y531JtX5ADSNlz34sT94ij8OBof84zn/eNHjyFOPdWgeFGlbA6WIx8+op45R
	PpHKRiqXi5AfuMEBIVCFXCZeKV4DEaIGBx3dLUkJVWZ1+nyrNUm0lQrvoA6N
	+MiOE5myLwp7P3TQpt3w+8hQWlPH1GeFVisrrMBZoholCq2AkFvvRNJXAvy+
	9N/AQixpYESpvWRkhYLBx/rAarsmqf/5PaT0oucpCqiGGjP2GIWRf+zzj+dM
	WE+ZsPa7COv3STVPcBybIxeaLWS72WbIraAmR5gNx+rgYOtEjCufQJHTdk9E
	N9AKXelYsxZylIY2lmah31tlRk88IWwQ7bpUeS3ZmITU+ajRivPEuZ4SPma/
	oM3nBK2LkvBepFiNe2swSol2cl2HPiGHf+yaF+u44LC+oeV2UIPrepMS7A5s
	z+Ov8s2R/3HKe8ok94zZlvCyff5xYJztGV+JP57xD/nwJZPqU/7xjH8c8o/n
	PW6R0eMacf6xzz/kw0Oj5kN+7aHecIAPO+S3K4kfDrq6hBI+ANVIqtj1PUCB
	jvvoJ/W16GsL0ajBOEWsMyotd7lY7JHsKMBm0g8tF4K1pH0Rgpc24b359z90
	aP7+6Mnp0qYDlcB7WcVGKIqsl7cEPVurwybh42+KPjxWr7G2D7U4RpiVp6N0
	0XCrdrIMgpsfvuSEQAcGZQkCZsOir4FnimDurH+xmanvfZwEiQL3B/H40TRh
	48JPgI9MaE3L1scCmP0QfXlSNi8SQEbHJffBrc8iysGW/J4x10T3+0z+B/zj
	hRG8Y9gHTLiHQrh+imRzBbvpkXlqh/eelob2zHjuaVBQrS+NjuXSFsYLqd83
	U+MMcpj3ed77Ojfqn9OaWzAigy3oJ4hdDRHLzUHxe5zZCL43NDYoRDHxMp7b
	wYWQlOHCss94RVdPhNIkMMDjFvhzbkFHPt/fuz5PmVc+ZV75lFfrKSuDT1kZ
	NLrYN7o45CuVrz1rLWFkeosBvYFGXOsy6/mjrbXkzFMEhzM8KKCGGlqfPCFh
	Tawzbk/yrLDmtilncJSKf2ZxvucFOIyky7NInjyPBMkBy4yngb6ecR6Qpmzh
	evgz/vBtnQ3/Gh98sLq8yO9JIBGkL6eXi5zn9Ob/+I95PgJGd1t+zurtbW7r
	QE0nRqEZoL6cTxynWFDXZmWE3E8aVpMb0xoWoJRgjoJC0AsYCqhQR0WuoYjX
	cdtRiflxEnGjOFg+Jh8Xdx6MVgMVcdUW3LScPkEHR9X10HMec4+sGVnK3SND
	w7FIgcprKyyF80MX9F2AVJNAilVA4ZSmabSqw2q1aFDLW0yDd5kEaTGTLq2K
	sBIDncWZ89I0F94moapojKEtLJfIFsmygBvw1Yhlof0mufGJJoZbQ2ztgs1p
	tNqQMPiep+Uc/lehKZzIU+noCBizto/BV7PZi4dRxTb1dXMGMLdd9pExIZvW
	eLUv2JTRWEOCYI6l3AiQTaqQ682X4+k2mGJK7YQdpVZWmr9vhB0RM6rGxSoQ
	kEMObq2kVuuj9dQeV1gZTNcOD8PzJY1qaLfnKWKlYETPsgXqAJ/BDRXzJpmU
	DXuRYasIvVVC5nHiYlwzXnIfHEwdTJsGu+DdZUOFcEYMeYK4BfL/UVsBusKG
	MOLwCkRbx1xPjiQII2BK4l2i+DcidmjDXWwfB5olN13W05pZlyZJsw+wmQIm
	EF7ZKhKhF1B8Gl8nZSGfqcvOzKAOGQ6MMxV8ymbJUT5KA8lSzshOo34qOqcZ
	xrs1iaxWPJoVKbORbS+nQu9r8SPFTEpd7Xyb+7j2uBjymd1RWqTrk0v5uD49
	WaSWS+f5/xq7uqa2kSD4zq/QI1QZ32/wBXKBSiUU5u7qHoUl2yqERUlWgHPl
	v990z8x+yCZ1Lwk4jr3and2ZnenpJsdf5gllTlxn0zEJYdvnRkJ7NLSXa30O
	8H3gMhtAC8myiSzL4DZXOyi1W7ulXnVLs7F4OLFcDoUWX3xtUqoiL+PMFVcC
	YxivL5R1So5v+Qw71Wfa6w5xLbQNvNQho1Fqc8AlVkLWfaMA0YTSzw5Xbzkw
	7lgg6AZtFGfvQ6kX+rIlrNAOwnA/2tXY3SgUqZD4ummt1vUy9pjledKMJwa3
	6Q31mTmjcETw+EmOEXJIqvRXQ4GpNeHkHBBRNrUGbdEzp1KkKSw9EKgAN3E4
	PHxdLv+8/+v6H1Au4AqpjSXyMvDpd19vHuTHnz+Tbefrmg58EhUgp/Tscauc
	JpsOv+AzEbfu6lCu5PTFFYA5xJlGLapO5kT3AQic6vSINZncvlYuOFbR4rPn
	rYTpmKGMzZ4brgmzg/Fghj3/W/fdZehexAx2az2/uW0Kdt/5YTM1VJTcjFIU
	66b84u6+s20m419cydwAT3elk41AomxwGQh4oWQTa9hjhyuPcbDoO1/aB5OX
	j2+qeaqW9Ch/vDYVmDTlyJcbv/iS0gvcivQMJcu2fiueasKOS5U9m599V1TN
	LLEENTsJsmwGEvt0xMrgrULJK9apQT6w/+slTngIQKFDusDbdpRNqTTNIPSF
	KJ0aH81bOu3OrO2JBFZ526GzraDRUBXesBp7XxH9chA6uchynmMLnZwnneix
	tnLeSWEHp5HMq+PWD3b6JvfdUS2VWJF0G+3eHZZLphtsxBk6kUp1A6y26Flu
	nEjJTfo8+Zl64TMTdudRfHrf42Mv7MlgcviBQzeN0TeiGCHROpowQtIwF0Zj
	X6y7vfsRdBmmsyeBEbDlDmMJ/hLrRlnql7K30+88h3pRfIZVeAf8XcxiHYAy
	5I1XXNJ2AxkhjPao2sNmvmx43uTmSpCIXJr1e+4ilzHQ+oWleKEgKripgYRN
	E7eKJXuyOk/u6OlVyyS5dww1TBCGZpAhJQag6VQR2o6j8OZJ9EMyX2a+abd9
	vZEp2yPLlxE+NqpHQBGldBd1ftDg1+cAGLOPaQjctYS6e6u2fIVoSfAfvJbQ
	4FP8PWPnxQ0WyNVVswGZ7pyYa6rZo3oG2AB6qZuCYwyjZNi9wDkcT7FczEp1
	MDX4+tE91QFZcwJ0w1KUXJwKDx11Zyd1Krnw1ceInWDX484fdJoiBMGtofeS
	vKJFvoE0M/CGNQnL2BBxfvrmwANb7g0RbqW3hHv5SN2WUsuLb4tJYuPs228L
	/pu8vGpHRGiaQa661fisTocNVeT2c0SxQkbroG/KGc+uAOpWbZA8regDTNlq
	3biwaUZ36eFfyFo8YhcFMaASnNt0LBalwiEcFyvqmASZQ/2i0hLcCCWBKqAz
	48MES9OaLdpKtLxJVcogejcU54eDvHQdX1H5N41fyOinNIr+zqxfDG9FK22i
	s5jXBifaYIfDScVrfEx0e/EhNPw+xtZ53ycoi9t3vaJmVNzr9NbXZPcbm3d6
	Kn30JNMrIxGj+l21l7hvVSYkEp4ZwWzWrBRpvZN+idc6qhpVidCMXsyaIWJY
	A0/58YNaUvd5bE1/vFcvUykG8nQtZtLHnYhWq0ieQrS9l17CwRcPQ9NBzimy
	Iv4mRLcWiTeD5YUsP9BN8GmdsY5kkpBxTZXrVdvaGPfKHXpXvgzbbq85rwiF
	jSfI+pQRvBHbC9b5GzblGbtbVU+Ko0ynuZDWqkXW/NK0ZDMadpaJyCb5+K5/
	s7jT7F2wTZfTE6H5kjJArFSXLlQX912akt91Ln9haiaXYkhITm6Vmx5B7Izu
	p22bDQcbrSDUmWKhloEe1D937LsJzQTn2imp3TMXymx26rxjL/IxElZPXaP/
	SHIrqR64gwkdbPgBRJAXyd46WQwBsTIFKS0H19Yfyp3QoP3dMI5GHViurI1D
	biWzE9tYySsA47deEsYvcYMO4OnUJspZ0kODwcoDN86TjB5hBnjD+Dio4Fso
	FQEoXiziPuBBoXABbS4ejEeZiXLexcrdU3EN5uy/y83OWqySL+dtxHrGP4h+
	MAG3426zLYsvnWWdtyp+LDagYNoOHnX0x/FcraeX2QMbsKLB8XETA+jJ8BRQ
	aLYiVhZAfwhmHdKWkuQD5ycmwuuv+YR8km/eylWpWMri7Le4E1S9LOpVKfNS
	fO/B+3u3bdriWvZLW4sXXO5HdLx9kt9nxa08ei+3yS+yRx66uufV+ho3hL06
	j1uEgH33uhJP7DrUOIfYmVH2La5iRCAwTaxm7U8hVzAJQHbFXQ3PoFaBp7y5
	f/gMa2r8w+yr5Novlv4ZBZ6uiW8PZnRzv/zD/sf87D/enaJ6z3gBAA==


		Application-Specific Integrated Circuit (ASIC)
		Graphics Processing Units (GPUs)
		Information-Centric Network (ICN)
		Internet of Things (IoT)
		Java Virtual Machine (JVM)
		Message Passing Interface (MPI)
		Quality of Experience (QoE)
		Remote Direct Memory Access (RDMA)
		Software-Defined Network (SDN)
		Standards Development Organization (SDO)
		User Plane Function (UPF)
	-->	-->


		<!-- [rfced] Please review the "Inclusive Language" portion of the online
		Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
		and let us know if any changes are needed. Updates of this nature typically
		result in more precise language, which is helpful for readers.

		a) For example, please consider whether "native" should be updated here:

		so-called 'cloud-native' applications for applications developed

		b) In addition, please consider whether instances of "traditional"
		and "traditionally" should be updated for clarity. While the NIST website
		<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-l
		ibrary/nist-technical-series-publications-author-instructions#table1>
		indicates that this term is potentially biased, it is also ambiguous.
		"Tradition" is a subjective term, as it is not the same for everyone.
		-->
	</rfc>	</rfc>

End of changes. 212 change blocks.
	3196 lines changed or deleted	3299 lines changed or added
This html diff was produced by rfcdiff 1.48.