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 "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?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 44 skipping to change at line 40
<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>wehrle@comsys.rwth-aachen.de</email> <email>wehrle@comsys.rwth-aachen.de</email>
</address> </address>
</author> </author>
<author initials="D." surname="Trossen" fullname="Dirk Trossen"> <author initials="D." surname="Trossen" fullname="Dirk Trossen">
<organization abbrev="Huawei">Huawei Technologies Duesseldorf GmbH</organi zation> <organization abbrev="DaPaDOT Tech">DaPaDOT Tech UG (haftungsbeschränkt)</ organization>
<address> <address>
<postal> <postal>
<street>Riesstr. 25C</street> <street>Palestrinastr. 7A</street>
<city>Munich</city> <city>Munich</city>
<code>D-80992</code> <code>D-80639</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>Dirk.Trossen@Huawei.com</email> <email>dirk@dapadot-tech.eu</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="SLICES-RI">SLICES-RI</organization>
<organization abbrev="McGill">McGill University</organization>
<address> <address>
<postal> <postal>
<street>680 Sherbrooke Street W.</street> <street>.</street>
<city>Montreal</city> <city>Paris</city>
<code>H3A 3R1</code> <code></code>
<country>Canada</country> <country>France</country>
</postal> </postal>
<email>marie-jose.montpetit@mcgill.ca</email> <email>marie-jose.montpetit@slices-ri.eu</email>
</address> </address>
</author> </author>
<author initials="X." surname="de Foy" fullname="Xavier de Foy"> <author initials="X." surname="de Foy" fullname="Xavier de Foy">
<organization>InterDigital Communications, LLC</organization> <organization>InterDigital Communications, LLC</organization>
<address> <address>
<postal> <postal>
<street>1000 Sherbrooke West</street> <street>1000 Sherbrooke West</street>
<city>Montreal</city> <city>Montreal</city>
<code>H3A 3G4</code> <code>H3A 3G4</code>
<country>Canada</country> <country>Canada</country>
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="August"/>
<date /> <workgroup>Computing in the Network (COIN)</workgroup>
<area>General</area> <keyword>COIN, in-network computing, VR, XR, Industry 4.0, Industrial IIoT, Perf
<workgroup>COINRG</workgroup> orming Arts, CDN, P4</keyword>
<abstract> <abstract>
<t>Computing in the Network (COIN) comes with the prospect of deploying
<t>Computing in the Network (COIN) comes with the prospect of deploying processi processing functionality on networking devices such as switches and
ng functionality on networking devices, such as switches and network interface c network interface cards. While such functionality can be beneficial, it
ards. has to be carefully placed into the context of the general Internet
While such functionality can be beneficial, it has to be carefully placed into t communication, and it needs to be clearly identified where and how those
he context of the general Internet communication and it needs to be clearly iden benefits apply.</t>
tified 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,
<t>This document presents some use cases to demonstrate how a number of salient to guide research on COIN, it identifies essential research questions
COIN-related applications can benefit from COIN. and outlines desirable capabilities that COIN systems addressing these use
Furthermore, to guide research on COIN, it identifies essential research questio cases may need to support. Finally, the document provides a preliminary
ns and outlines desirable capabilities that COIN systems addressing the use case categorization of the described research questions to source future work
s may need to support. in this domain. This document is a product of the Computing in the Networ
Finally, the document provides a preliminary categorization of the described res k
earch questions to source future work in this domain. Research Group (COINRG). It is not an IETF product and it is not a
It is a product of the Computing in the Network Research Group (COINRG). standard.</t>
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 commonly 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
ses to demonstrate the diversity of COIN applications.
It is intended as a basis for further analyses and discussions within the wider
research community.
This document represents the consensus of COINRG.</t>
</section>
<section anchor="terms"><name>Terminology</name>
<t>This document uses the terminology defined below.</t>
<t>Programmable Network Devices (PNDs): network devices, such as network interfa
ce cards and switches, which are programmable, e.g., using P4 <xref target="P4"/
> or other languages.</t>
<t>(COIN) Execution Environment: a class of target environments for function exe
cution, for example, a JVM-based execution environment that can run functions re
presented in JVM byte code</t>
<t>COIN System: the PNDs (and end systems) and their execution environments, tog
ether with the communication resources interconnecting them, operated by a singl
e provider or through interactions between multiple providers that jointly offer
COIN capabilities</t>
<t>COIN Capability: a feature enabled through the joint processing of computatio
n and communication resources in the network</t>
<t>(COIN) Program: a monolithic functionality that is provided according to the <t>This document discusses these six aspects along a number of
specification for said program and which may be requested by a user. A composit individual use cases to demonstrate the diversity of COIN applications.
e service can be built by orchestrating a combination of monolithic COIN program It is intended as a basis for further analyses and discussions within
s.</t> the wider research community. This document has received review comments
at different stages of its development, by experts within and out of COINR
G,
as detailed in the Acknowledgements section. This document represents the
consensus of COINRG.</t>
</section>
<t>(COIN) Program Instance: one running instance of a program</t> <section anchor="terms">
<name>Terminology</name>
<t>This document uses the terminology defined below.</t>
<t>COIN Experience: a new user experience brought about through the utilization of COIN capabilities</t> <dl spacing="normal" newline="false">
</section> <dt>Programmable Network Devices (PNDs):</dt><dd>network devices, such
<section anchor="newExperiences"><name>Providing New COIN Experiences</name> as network interface cards and switches, which are programmable (e.g.,
using P4 <xref target="P4"/> or other languages).</dd>
<section anchor="mobileAppOffload"><name>Mobile Application Offloading</name> <dt>COIN execution environment:</dt><dd>a class of target
environments for function execution, for example, an
execution environment based on the Java Virtual Machine (JVM) that can ru
n functions represented in JVM byte
code.</dd>
<section anchor="description"><name>Description</name> <dt>COIN system:</dt><dd>the PNDs (and end systems) and their
execution environments, together with the communication resources
interconnecting them, operated by a single provider or through
interactions between multiple providers that jointly offer COIN
capabilities.</dd>
<t>This scenario can be exemplified in an immersive gaming application, where a <dt>COIN capability:</dt><dd>a feature enabled through the joint
single user plays a game using a Virtual Reality (VR) headset. <br /> processing of computation and communication resources in the
The headset hosts several (COIN) programs. network.</dd>
For instance, the "display" (COIN) program renders frames to the user, while oth
er 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>
<t>Once this application is partitioned into its constituent (COIN) programs and <dt>COIN program:</dt><dd>a monolithic functionality that is
deployed throughout a COIN system, utilizing a COIN execution environment, only provided according to the specification for said program and which may
the "display" (COIN) program may be left in the headset, while the compute inte be requested by a user. A composite service can be built by
nsive real-time VR content processing (COIN) program can be offloaded to a nearb orchestrating a combination of monolithic COIN programs.</dd>
y 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 g
eneration).</t>
</section> <dt>COIN program instance:</dt><dd>one running instance of a program.</dd
<section anchor="characterization"><name>Characterization</name> >
<t>Partitioning a mobile application into several constituent (COIN) programs al <dt>COIN experience:</dt><dd>a new user experience brought about
lows for denoting the application as a collection of (COIN) programs for a flexi through the utilization of COIN capabilities.</dd>
ble composition and a distributed execution.
In our example above, most capabilities of a mobile application can be categoriz
ed into any of three, "receiving", "processing", and "displaying" groups.</t>
<t>Any device may realize one or more of the (COIN) programs of a mobile applica </dl>
tion and expose them to the (COIN) system and its constituent (COIN) execution e </section>
nvironments. <section anchor="newExperiences">
When the (COIN) program sequence is executed on a single device, the outcome is <name>Providing New COIN Experiences</name>
what you traditionally see with applications running on mobile devices.</t> <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>
<t>However, the execution of a (COIN) program may be moved to other (e.g., more <t>Once this application is partitioned into its constituent COIN
suitable) devices, including PNDs, which have exposed the corresponding (COIN) p programs and deployed throughout a COIN system utilizing a COIN
rogram as individual (COIN) program instances to the (COIN) system by means of a execution environment, only the display COIN program may be left in
'service identifier'. the headset. Meanwhile, the CPU-intensive real-time VR content
The result is the equivalent to 'mobile function offloading', for possible reduc processing COIN program can be offloaded to a nearby resource rich
tion of power consumption (e.g., offloading CPU intensive process functions to a home PC or a Programmable Network Device (PND) in the operator's
remote server) or for improved end user experience (e.g., moving display functi access network for a better execution (i.e., faster and possibly hi
ons to a nearby smart TV) by selecting more suitably placed (COIN) program insta gher
nces in the overall (COIN) system.</t> 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
commonly see with applications running on mobile devices.</t>
<t>We can already see a trend toward supporting such functionality with, e.g., g <t>However, the execution of a COIN program may be moved to other
aming platforms rendering content externally, relying on dedicated cloud hardwar (e.g., more suitable) devices, including PNDs, which have exposed
e. We envision, however, that such functionality is becoming more pervasive thro the corresponding COIN program as individual COIN program
ugh specific facilities, such as entertainment parks or even hotels, to deploy n instances to the COIN system by means of a service identifier.
eeded edge computing capability to enable localized gaming as well as non-gaming The result is the equivalent to mobile function offloading, in that it
scenarios.</t> offers the possible reduction of power consumption (e.g., offloading C
PU-
intensive process functions to a remote server) or an improved
end-user experience (e.g., moving display functions to a nearby smart
TV)
by selecting more suitably placed COIN program instances in the overal
l
COIN system.</t>
<t>We can already see a trend toward supporting such functionality
that relies 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 344
||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
<t>Such localized deployment could, for instance, be provided by a visiting site processing COIN program is terminated on the mobile device, the
, such as a hotel or a theme park. "service routing (SR)" elements in the network route (service)
Once the 'processing' (COIN) program is terminated on the mobile device, the 'se requests instead to the (previously deployed) processing COIN
rvice routing' (SR) elements in the network route (service) requests instead to program running on the processing server over an existing SDN
the (previously deployed) 'processing' (COIN) program running on the processing network. Here, capabilities and other constraints for selecting the
server over an existing SDN network. appropriate COIN program, in case of having deployed more than
Here, capabilities and other constraints for selecting the appropriate (COIN) pr one, may be provided both in the advertisement of the COIN program
ogram, in case of having deployed more than one, may be provided both in the adv and the service request itself.</t>
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 from one processing COIN program may be distributed to
<t>As an extension to the above scenarios, we can also envision that content fro more than one display COIN program (e.g., for multi- and many-viewing
m one processing (COIN) program may be distributed to more than one display (COI scenarios). Here, an offloaded processing program may collate
N) program, e.g., for multi/many-viewing scenarios. input from several users in the (virtual) environment to generate a
Here, an offloaded "processing" program may collate input from several users in possibly three-dimensional render that is then distributed via a
the (virtual) environment to generate a possibly three-dimensional render that i service-level multicast capability towards more than one display
s then distributed via a service-level multicast capability towards more than on COIN program.</t>
e "display" (COIN) program.</t> </section>
</section>
<section anchor="existing-solutions"><name>Existing Solutions</name>
<t>The ETSI Mobile Edge Computing (MEC) <xref target="ETSI"/> suite of technolog
ies provides solutions for mobile function offloading by allowing mobile applica
tions to select resources in edge devices to execute functions instead of the mo
bile device directly.
For this, ETSI MEC utilizes a set of interfaces for the selection of suitable ed
ge resources, connecting to so-called MEC application servers, while also allowi
ng for sending data for function execution to the application server.</t>
<t>However, the technologies do not utilize micro-services <xref target="Microse
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
c, relying on DNS-based endpoint selection, which does not cater to the requirem
ents of the example provided above, where the latency for redirecting to another
device lies within few milliseconds for aligning with the framerate of the disp
lay micro-service.</t>
<t>Lastly, MEC application servers are usually considered resources provided by
the network operator through its MEC infrastructure, while our use case here als
o foresees the placement and execution of micro-services 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 tha
t a selected edge application server is being utilized to send functional descri
ptions and data for execution.</t>
<t>The draft at <xref target="APPCENTRES"/> outlines a number of enabling techno
logies for the use case, some of which have been realized in an Android-based re
alization of the micro-services as a single application, which is capable to dyn
amically redirect traffic to other micro-service 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 an
d 2019.</t>
</section>
<section anchor="opportunities"><name>Opportunities</name>
<t><list style="symbols">
<t>The packaging of (COIN) programs into existing mobile application packaging
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>
<section anchor="mobileOffloadRQ"><name>Research Questions</name>
<t><list style="symbols">
<t>RQ 3.1.1: How to combine service-level orchestration frameworks, such as TO
SCA orchestration templates<xref target="TOSCA"/>, with app-level, e.g., mobile
application, packaging methods, ultimately providing means for packaging micro-s
ervices for deployments in distributed networked computing environments?</t>
<t>RQ 3.1.2: How to reduce latencies involved in (COIN) program interactions w
here (COIN) program instance locations may change quickly? Can service-level req
uests be routed directly through in-band signalling methods instead of relying o
n out-of-band discovery, such as through the DNS?</t>
<t>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 bes
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>
</section>
<section anchor="XR"><name>Extended Reality and Immersive Media</name>
<section anchor="description-1"><name>Description</name>
<t>Extended reality (XR) encompasses VR, Augmented Reality (AR) and Mixed Realit
y (MR).
It provides the basis for the metaverse and is the driver of a number of advance
s in interactive technologies.
While initially associated with gaming and immersive entertainment, applications
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
.
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
reasingly 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 collabora
tive space.
As a consequence, innovation is needed to unlock the full potential of XR.</t>
</section>
<section anchor="characterization-1"><name>Characterization</name>
<t>As mentioned above, XR experiences, especially those involving collaboration,
are difficult to deliver with a client-server cloud-based solution as they requ
ire a combination of multi-stream aggregation, low delays and delay variations,
means to recover from losses, and optimized caching and rendering as close as po
ssible to the user at the network edge.
Hence, implementing such XR solutions necessitates substantial computational pow
er and minimal latency, which, for now, has spurred the development of better he
adsets not networked or distributed solutions as factors like distance from clou
d servers and limited bandwidth can still significantly lower application respon
siveness.
Furthermore, when XR deals with sensitive information, XR applications must also
provide a secure environment and ensure user privacy, which represent additiona
l burdens for delay sensitive applications.
Additionally, the sheer amount of data needed for and generated by the XR applic
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>
<t><list style="symbols">
<t>the XR application residing in the headset,</t>
<t>edge federation services that allow local devices to communicate with one a
nother directly,</t>
<t>egde application servers that enable local processing but also intelligent
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
ly that COIN can help to realize XR over networks for collaborative applications
.
In particular, COIN functions can enable the distribution of the service compone
nts across different nodes in the network.
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>
<section anchor="existing-solutions-1"><name>Existing Solutions</name>
<t>The XR field has profited from extensive research in the past years in gaming
, machine learning, network telemetry, high resolution imaging, smart cities, an
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
work-support is important to offload some of the computations related to movemen
t, multi-user interactions, and networked applications notably in gaming but als
o in health <xref target="NetworkedVR"/>.<br />
This new approach to networked AR/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 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
is now claimed to be spatial computing.
Additionally, with recent work on the Metaverse, the number of publications rela
ted to XR has skyrocketed.
However, in terms of networking, which is the focus of this document, current de
ployments 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 immersive media applications over netw
orks that allow for federating systems capabilities.</t>
</section>
<section anchor="opportunities-1"><name>Opportunities</name>
<t>While delay is inherently related to information transmission and if we conti
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
some opportunities that XR could take advantage of:</t>
<t><list style="symbols">
<t>Round trip time: 20 ms is usually cited as an upper limit for XR applicatio
ns. Storage and preprocessing of scenes in local elements (including in the mobi
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>
<section anchor="research-questions"><name>Research Questions</name>
<t><list style="symbols">
<t>RQ 3.2.1: Can current PNDs provide the speed required for executing complex
filtering operations, including metadata analysis for complex and dynamic scene
rendering?</t>
<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>
<section anchor="additional-desirable-capabilities"><name>Additional Desirable C
apabilities</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, the provided XR experience should be optimized both in amount of
transmitted data, while equally optimizing loss protection.
Furthermore, means for trend analysis and telemetry to measure performance may f
oster uptake of the XR services, while the interaction of the XR system with ind
oor and outdoor positioning systems may improve on service experience and user p
erception.</t>
</section>
</section>
<section anchor="PerformingArts"><name>Personalized and interactive performing a
rts</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 a
udience members are geographically distributed.
The performance is conveyed through multiple networked streams which are tailore
d to the requirements of the remote performers, the director, sound and lighting
technicians, and individual audience members; performers need to observe, inter
act and synchronize with other performers in remote locations; and the performer
s receive live feedback from the audience, which may also be conveyed to other a
udience members.</t>
<t>There are two main aspects: i) to emulate as closely as possible the experien
ce of live performances where the performers, audience, director, and technician
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> <section anchor="existing-solutions">
<name>Existing Solutions</name>
<t><list style="symbols"> <t>The ETSI Multi-access Edge Computing (MEC) <xref target="ETSI"/> su
<t>Viewpoint selection such as choosing a specific seat in the theater or for ite
more advanced positioning of the audience member's viewpoint outside of the trad of technologies provides solutions for mobile function offloading by
itional seating - amongst, above, or behind the performers (but within some limi allowing mobile applications to select resources in edge devices to
ts which may be imposed by the performers or the director, for artistic reasons) execute functions instead of the mobile device directly. For this,
;</t> ETSI MEC utilizes a set of interfaces for the selection of suitable
<t>Augmentation of the performance with subtitles, audio-description, actor-ta edge resources, connecting to so-called MEC application servers,
gging, language translation, advertisements/product-placement, other enhancement while also allowing for sending data for function execution to the
s/filters to make the performance accessible to disabled audience members (remov application server.</t>
al of flashing images for epileptics, alternative color schemes for color-blind
audience members, etc.).</t>
</list></t>
</section> <t>However, the technologies do not utilize microservices <xref
<section anchor="characterization-2"><name>Characterization</name> target="Microservices"/>; they mainly rely on virtualization
<t>There are several chained functional entities which are candidates for being approaches such as containers or virtual machines, thus requiring a
deployed as (COIN) programs:</t> heavier processing and memory footprint in a COIN 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; it does allow for them to
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>
<t><list style="symbols"> <section anchor="opportunities">
<t>Performer aggregation and editing functions</t> <name>Opportunities</name>
<t>Distribution and encoding functions</t> <ul spacing="normal">
<t>Personalization functions <li>
<list style="symbols"> <t>The packaging of COIN programs into existing mobile
<t>to select which of the existing streams should be forwarded to the audi application packaging may enable the migration from current
ence member, remote performer, or member of the production team</t> (mobile) device-centric execution of those mobile applications
<t>to augment streams with additional metadata such as subtitles</t> toward a possible distributed execution of the constituent
<t>to create new streams after processing existing ones, e.g., to interpol COIN programs that are part of the overall mobile
ate between camera angles to create a new viewpoint or to render point clouds fr application.</t>
om an audience member's chosen perspective</t> </li>
<t>to undertake remote rendering according to viewer position, e.g., creat <li>
ion of VR headset display streams according to audience head position - when thi <t>The orchestration for deploying COIN program instances in
s processing has been offloaded from the viewer's end-system to the COIN functio specific end systems and PNDs alike may open up the possibility
n due to limited processing power in the end-system, or to limited network bandw for localized infrastructure owners, such as hotels or venue
idth to receive all of the individual streams to be processed.</t> owners, to offer their compute capabilities to their visitors
</list></t> for improved or even site-specific experiences.</t>
<t>Audience feedback sensor processing functions</t> </li>
<t>Audience feedback aggregation functions</t> <li>
</list></t> <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>
<li>
<t>The support for service-level routing of requests (such as serv
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 routing
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>
<t>These are candidates for deployment as (COIN) Programs in PNDs rather than be <ul spacing="normal">
ing located in end-systems (at the performers' site, the audience members' premi <li>RQ 3.1.1: How to combine service-level orchestration
ses or in a central cloud location) for several reasons:</t> 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><list style="symbols"> </section>
<t>Personalization of the performance according to viewer preferences and requ </section>
irements makes it infeasible to be done in a centralized manner at the performer <section anchor="XR">
premises: the computational resources and network bandwidth would need to scale <name>Extended Reality and Immersive Media</name>
with the number of personalized streams.</t> <section anchor="description-1">
<t>Rendering of VR headset content to follow viewer head movements has an uppe <name>Description</name>
r bound on lag to maintain viewer QoE, which requires the processing to be under <t>Extended Reality (XR) encompasses VR, Augmented Reality (AR) and
taken sufficiently close to the viewer to avoid large network latencies.</t> Mixed Reality (MR). It provides the basis for the metaverse and is
<t>Viewer devices may not have the processing-power to perform the personaliza the driver of a number of advances in interactive technologies.
tion tasks, or the viewers' network may not have the capacity to receive all of While initially associated with gaming and immersive entertainment,
the constituent streams to undertake the personalization functions.</t> applications now include remote diagnosis, maintenance,
<t>There are strict latency requirements for live and interactive aspects that telemedicine, manufacturing and assembly, intelligent agriculture,
require the deviation from the direct network path between performers and audie smart cities, and immersive classrooms. XR is one example of the
nce members to be minimized, which reduces the opportunity to route streams via multisource-multidestination problem that combines video and haptics
large-scale processing capabilities at centralized data-centers.</t> in interactive multiparty interactions under strict delay
</list></t> requirements. As such, XR can benefit from a functional distribution t
hat
includes fog computing 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. 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-routing 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>As mentioned above, XR experiences, especially those 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, rather than spurring 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>
</section> <t>With functional decomposition as the goal of a better XR experience
<section anchor="existing-solutions-2"><name>Existing solutions</name> ,
<t>Note: Existing solutions for some aspects of this use case are covered in <xr the elements involved in a COIN XR implementation include:</t>
ef target="mobileAppOffload"/>, <xref target="XR"/>, and <xref target="CDNs"/>.< <ul spacing="normal">
/t> <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>The XR field has profited from extensive research in the past
years in gaming, machine learning, network telemetry, high
resolution imaging, smart cities, and the Internet of Things (IoT).
Information-Centric Networking (ICN) (and related) approaches that
combine publish-subscribe and distributed storage are also very
suited for the multisource-multidestination applications of XR. New
AR and VR headsets and glasses have continued to evolve towards
autonomy with local computation capabilities, increasingly
performing much of the processing that 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 discovering 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>In summary, some XR solutions exist, and headsets continue to
evolve to what is now claimed to be spatial computing.
Additionally, with recent work on the metaverse, the number of
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 the
federation of systems capabilities.</t>
</section>
</section> <section anchor="opportunities-1">
<section anchor="opportunities-2"><name>Opportunities</name> <name>Opportunities</name>
<t>While delay is inherently related to information transmission, if
we continue 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 some opportunities that XR could
take advantage of:</t>
<ul spacing="normal">
<li>
<t>Round trip time: 20 ms is usually cited as an upper limit for
XR applications. Storage and preprocessing of scenes in local
elements (including in the mobile network) could extend the
reach of XR applications at least over the extended edge.</t>
</li>
<li>
<t>Video transmission: The use of better transcoding, advanced
context-based compression algorithms, prefetching and
precaching, as well as movement prediction all help to reduce
bandwidth consumption. While this is now limited to local
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>
<section anchor="research-questions">
<name>Research Questions</name>
<ul spacing="normal">
<li>RQ 3.2.1: Can current PNDs provide the speed required for
executing complex filtering operations, including metadata
analysis for complex and dynamic scene rendering?</li>
<li>RQ 3.2.2: Where should PNDs equipped with these operations be
located for optimal performance gains?</li>
<li>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?</li>
<li>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? Could this jointly optimize 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)?</li>
<li>RQ 3.2.5: Can COIN provide the necessary infrastructure for
the use of interactive XR everywhere? Particularly, how can a COIN
system enable the joint collaboration across all segments of the
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>
<t><list style="symbols"> <section anchor="additional-desirable-capabilities">
<t>Executing media processing and personalization functions on-path as (COIN) <name>Additional Desirable Capabilities</name>
Programs in PNDs can avoid detour/stretch to central servers, thus reducing late <t>In addition to the capabilities driven by the research questions
ncy and bandwidth consumption. above, there are a number of other features that solutions in this
For example, the overall delay for performance capture, aggregation, distributio space might benefit from. In particular, the provided XR experience
n, personalization, consumption, capture of audience response, feedback processi should be optimized both in the amount of transmitted data, while
ng, aggregation, and rendering should be achieved within an upper bound of laten equally optimizing loss protection. Furthermore, the means for trend
cy (the tolerable amount is to be defined, but in the order of 100s of ms to mim analysis and telemetry to measure performance may foster uptake of
ic performers perceiving audience feedback, such as laughter or other emotional the XR services, while the interaction of the XR system with indoor
responses in a theater setting).</t> and outdoor positioning systems may improve on service experience
<t>Processing of media streams allows (COIN) Programs, PNDs and the wider (COI and user perception.</t>
N) System/Environment to be contextually aware of flows and their requirements w </section>
hich can be used for determining network treatment of the flows, e.g., path sele </section>
ction, prioritization, multi-flow coordination, synchronization and resilience.< <section anchor="PerformingArts">
/t> <name>Personalized and Interactive Performing Arts</name>
</list></t> <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 anchor="research-questions-1"><name>Research Questions:</name> <ol type="i">
<li>to emulate as closely as possible the experience of live
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 conventional 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>
<t><list style="symbols"> <t>Examples of personalization include:</t>
<t>RQ 3.3.1: In which PNDs should (COIN) Programs for aggregation, encoding, a <ul spacing="normal">
nd personalization functions be located? Close to the performers or close to the <li>
viewers?</t> <t>Viewpoint selection, such as choosing a specific seat in the
<t>RQ 3.3.2: How far from the direct network path from performer to viewer sho theater or for more advanced positioning of the audience
uld (COIN) programs be located, considering the latency implications of path-str member's viewpoint outside of the conventional seating (i.e.,
etch and the availability of processing capacity at PNDs? How should tolerances amongst, above, or behind the performers, but within some limits
be defined by users?</t> that may be imposed by the performers or the director for
<t>RQ 3.3.3: Should users decide which PNDs should be used for executing (COIN artistic reasons);</t>
) Programs for their flows or should they express requirements and constraints t </li>
hat will direct decisions by the orchestrator/manager of a COIN System? In case <li>
of the latter, how can users specify requirements on network and processing metr <t>Augmentation of the performance with subtitles, audio
ics (such as latency and throughput bounds)?</t> description, actor tagging, language translation, advertisements
<t>RQ 3.3.4: How to achieve synchronization across multiple streams to allow f and product placement, and other enhancements and filters to
or merging, audio-video interpolation, and other cross-stream processing functio make the performance accessible to audience members who are disabl
ns that require time synchronization for the integrity of the output? ed
How can this be achieved considering that synchronization may be required betwee (e.g., the removal of flashing images for audience members who hav
n flows that are: i) on the same data pathway through a PND/router, ii) arriving e epilepsy or alternative color
/leaving through different ingress/egress interfaces of the same PND/router, iii schemes for those who have color blindness).</t>
) routed through disjoint paths through different PNDs/routers? </li>
This RQ raises issues associated with synchronisation across multiple media stre </ul>
ams and sub-streams <xref target="RFC7272"/> as well as time synchronisation bet </section>
ween PNDs/routers on multiple paths <xref target="RFC8039"/>.</t>
<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 comput
ational nodes?</t>
<t>RQ 3.3.6: Are computationally-intensive tasks - such as video stitching or
media recognition and annotation (cf. <xref target="XR"/>) - considered as suita
ble candidate (COIN) Programs or should they be implemented in end-systems?</t>
<t>RQ 3.3.7: If the execution of COIN Programs is offloaded to computational n
odes outside of PNDs, e.g., for processing by GPUs, should this still be conside
red as COIN? Where is the boundary between COIN capabilities and explicit routin
g of flows to endsystems?</t>
</list></t>
</section> <section anchor="characterization-2">
<section anchor="additional-desirable-capabilities-1"><name>Additional Desirable <name>Characterization</name>
Capabilities</name> <t>There are several chained functional entities that are
<t>In addition to the capabilities driven by the research questions above, there candidates for being deployed as COIN programs:</t>
are a number of other features that solutions in this space might benefit from. <ul spacing="normal">
In particular, if users are indeed empowered to specify requirements on network <li>
and processing metrics, one important capability of COIN systems will be to resp <t>Performer aggregation and editing functions</t>
ect these user-specified requirements and constraints when routing flows and sel </li>
ecting PNDs for executing (COIN) Programs. <li>
Similarly, solutions should be able to synchronize flow treatment and processing <t>Distribution and encoding functions</t>
across multiple related flows which may be on disjoint paths to provide similar </li>
performance to different entities.</t> <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>
</section> <ul spacing="normal">
</section> <li>
</section> <t>Executing media processing and personalization functions
<section anchor="newEnvironments"><name>Supporting new COIN Systems</name> on-path as COIN programs in PNDs can avoid detour/stretch to
central servers, thus reducing latency and bandwidth
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>
<section anchor="control"><name>In-Network Control / Time-sensitive applications <section anchor="additional-desirable-capabilities-1">
</name> <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="description-3"><name>Description</name> <section anchor="newEnvironments">
<t>The control of physical processes and components of industrial production lin <name>Supporting New COIN Systems</name>
es 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 pro
grammable logic controllers (PLCs) located directly next to the controlled proce
ss or component.
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 <section anchor="control">
mber of involved devices and sensors, a growing level of dependency between the <name>In-Network Control / Time-Sensitive Applications</name>
different components, and more complex control models.
A centralized control is desirable to manage the large amount of available infor
mation which often has to be preprocessed or aggregated with other information b
efore it can be used.
As a result, computations are increasingly spatially decoupled and moved away fr
om 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="description-3">
<section anchor="characterization-3"><name>Characterization</name> <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.
Commonly, 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>
<t>A control process consists of two main components as illustrated in <xref tar <section anchor="characterization-3">
get="processControl"/>: a system under control and a controller. <name>Characterization</name>
In feedback control, the current state of the system is monitored, e.g., using s <t>A control process consists of two main components as illustrated
ensors, and the controller influences the system based on the difference between in <xref target="processControl"/>: a system under control and a
the current and the reference state to keep it close to this reference state.</ controller. In feedback control, the current state of the system is
t> 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 title="Simple feedback control model." anchor="processControl"><artwork> <figure anchor="processControl">
<![CDATA[ <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 commonly 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 &amp; 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
&amp; 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 <li>
ons in COIN execution environments should ideally expose reliable information on <t>RQ 4.1.6: Can there be different control levels? For example,
the predicted delay and must expose reliable information on the predicted accur "quite inaccurate &amp; very low latency" for PNDs deep in the net
acy to the global control such that these aspects can be accommodated in the ove work;
rall control.</t> "more accurate &amp; higher latency" for more powerful COIN execut
ion
</section> environments that are farther away; and "very accurate &amp; very
</section> high
<section anchor="filtering"><name>Large Volume Applications</name> latency" for cloud environments that are far away.</t></li><li>
<t>RQ 4.1.7: Who decides which control instance is executed and
<section anchor="FilteringDesc"><name>Description</name> which information can be used for this decision?</t>
</li>
<t>In modern industrial networks, processes and machines are extensively monitor <li>
ed by distributed sensors with a large spectrum of capabilities, ranging from si <t>RQ 4.1.8: How do the different control instances interact and
mple binary (e.g., light barriers) to sophisticated sensors with varying degrees how can we define their hierarchy?</t>
of resolution. </li>
Sensors further serve different purposes, as some are used for time-critical pro </ul>
cess control while others represent redundant fallback platforms. </section>
Overall, there is a high level of heterogeneity which makes managing the sensor <section anchor="additional-desirable-capabilities-2">
output a challenging task.</t> <name>Additional Desirable Capabilities</name>
<t>In addition to the capabilities driven by the research questions
<t>Depending on the deployed sensors and the complexity of the observed system, above, there are a number of other features that approaches
the resulting overall data volume can easily be in the range of several Gbit/s < deploying control functionality in COIN execution environments could
xref target="GLEBKE"/>. benefit from. For example, having an explicit interaction between
These volumes are often already difficult to handle in local environments and it the COIN execution environments and the global controller would
becomes even more challenging when off-premise clouds are used for managing the ensure that it is always clear which entity is emitting which
data. signals. In this context, it is also important that actions of COIN
While large networking companies can simply upgrade their infrastructure to acco execution environments are overridable by the global controller such
mmodate the accruing data volumes, most industrial companies operate on tight in that the global controller has the final say in the process
frastructure budgets such that frequently upgrading is not always feasible or po behavior. Finally, by accommodating the general characteristics of
ssible. control approaches, functions in COIN execution environments should
Hence, a major challenge is to devise a methodology that is able to handle such ideally expose reliable information on the predicted delay and must
amounts of data efficiently and flexibily without relying on recurring infrastru expose reliable information on the predicted accuracy to the global
cture upgrades.</t> control such that these aspects can be accommodated in the overall
control.</t>
<t>Data filtering and preprocessing, similar to the considerations in <xref targ </section>
et="XR"/>, can be building blocks for new solutions in this space. </section>
Such solutions, however, might also have to address the added challenge of busin <section anchor="filtering">
ess data leaving the premises and control of the company. <name>Large-Volume Applications</name>
As this data could include sensitive information or valuable business secrets, a <section anchor="FilteringDesc">
dditional security measures have to be taken. <name>Description</name>
Yet, typical security measures such as encrypting the data make filtering or pre <t>In modern industrial networks, processes and machines are
processing approaches hardly applicable as they typically work on unencrypted da extensively monitored by distributed sensors with a large spectrum
ta. of capabilities, ranging from simple binary (e.g., light barriers)
Consequently, incorporating security into these approaches, either by adding fun to sophisticated sensors with varying degrees of resolution.
ctionality for handling encrypted data or devising general security measures, is Sensors further serve different purposes, as some are used for
an additional auspicious field for research.</t> time-critical process control, while others represent redundant
fallback platforms. Overall, there is a high level of heterogeneity,
</section> which makes managing the sensor output a challenging task.</t>
<section anchor="FilteringChar"><name>Characterization</name> <t>Depending on the deployed sensors and the complexity of the
observed system, the resulting overall data volume can easily be in
<t>In essence, the described monitoring systems consist of sensors that produce the range of several Gbit/s <xref target="GLEBKE"/>. These volumes
large volumes of monitoring data. are often already difficult to handle in local environments, and it
This data is then transmitted to additional components that provide data process becomes even more challenging when off-premise clouds are used for
ing and analysis capabilities or simply store the data in large data silos.</t> managing the data. While large networking companies can simply
upgrade their infrastructure to accommodate the accruing data
<t>As sensors are often set up redundantly, parts of the collected data might al volumes, most industrial companies operate on tight infrastructure
so be redundant. budgets such that frequently upgrading is not always feasible or
Moreover, sensors are often hard to configure or not configurable at all which i possible. Hence, a major challenge is to devise a methodology that
s why their resolution or sampling frequency is often larger than required. is able to handle such amounts of data efficiently and flexibly
Consequently, it is likely that more data is transmitted than is needed or desir without relying on recurring infrastructure upgrades.</t>
ed, prompting the deployment of filtering techniques. <t>Data filtering and preprocessing, similar to the considerations
For example, COIN programs deployed in the on-premise network could filter out r in <xref target="XR"/>, can be building blocks for new solutions in
edundant or undesired data before it leaves the premise using simple traffic fil this space. Such solutions, however, might also have to address the
ters, thus reducing the required (upload) bandwidths. added challenge of business data leaving the premises and control of
The available sensor data could be scaled down using standard statistical sampli the company. As this data could include sensitive information or
ng, packet-based sub-sampling, i.e., only forwarding every n-th packet, or using valuable business secrets, additional security measures have to be
filtering as long as the sensor value is in an uninteresting range while forwar taken. Yet, typical security measures such as encrypting the data
ding with a higher resolution once the sensor value range becomes interesting (c make filtering or preprocessing approaches hardly applicable as they
f. <xref target="KUNZE-SIGNAL"/>). typically work on unencrypted data. Consequently, incorporating
While the former variants are oblivious to the semantics of the sensor data, the security into these approaches, either by adding functionality for
latter variant requires an understanding of the current sensor levels. handling encrypted data or devising general security measures, is an
In any case, it is important that end-hosts are informed about the filtering so additional auspicious field for research.</t>
that they can distinguish between data loss and data filtered out on purpose.</t </section>
> <section anchor="FilteringChar">
<name>Characterization</name>
<t>In practice, the collected data is further processed using various forms of c <t>In essence, the described monitoring systems consist of sensors
omputation. that produce large volumes of monitoring data. This data is then
Some of them are very complex or need the complete sensor data during the comput transmitted to additional components that provide data processing
ation, but there are also simpler operations which can already be done on subset and analysis capabilities or simply store the data in large data
s of the overall dataset or earlier on the communication path as soon as all dat silos.</t>
a is available. <t>As sensors are often set up redundantly, parts of the collected
One example is finding the maximum of all sensor values which can either be done data might also be redundant. Moreover, sensors are often hard to
iteratively at each intermediate hop or at the first hop, where all data is ava configure or not configurable at all, which is why their resolution
ilable. or sampling frequency is often larger than required. Consequently,
Using expert knowledge about the exact computation steps and the concrete transm it is likely that more data is transmitted than is needed or
ission path of the sensor data, simple computation steps can thus be deployed in desired, prompting the deployment of filtering techniques. For
the on-premise network, again reducing the overall data volume.</t> example, COIN programs deployed in the on-premise network could
filter out redundant or undesired data before it leaves the premise
</section> using simple traffic filters, thus reducing the required (upload)
<section anchor="FilteringSol"><name>Existing Solutions</name> bandwidths. The available sensor data could be scaled down using
standard statistical sampling, packet-based sub-sampling (i.e., only
<t>Current approaches for handling such large amounts of information typically b forwarding every n-th packet), or using filtering as long as the
uild upon stream processing frameworks such as Apache Flink. sensor value is in an uninteresting range while forwarding with a
These solutions allow for handling large volume applications and map the compute higher resolution once the sensor value range becomes interesting
functionality to performant server machines or distributed compute platforms. (cf. <xref target="KUNZE-SIGNAL"/> and <xref target="TIRPITZ-REDUCIO"/
Augmenting the existing capabilities, COIN offers a new dimension of platforms f >). While the former variants are
or such processing frameworks.</t> oblivious to the semantics of the sensor data, the latter variant
requires an understanding of the current sensor levels. In any
</section> case, it is important that end hosts are informed about the
<section anchor="FilteringOppo"><name>Opportunities</name> filtering so that they can distinguish between data loss and data
filtered out on purpose.</t>
<t><list style="symbols"> <t>In practice, the collected data is further processed using
<t>(Stream) processing frameworks can become more flexible by introducing COIN various forms of computation. Some of them are very complex or need
execution environments as additional deployment targets.</t> the complete sensor data during the computation, but there are also
<t>(Semantic) packet filtering based on packet header and payload, as well as simpler operations that can already be done on subsets of the
multi-packet information can (drastically) reduce the data volume, possibly even overall dataset or earlier on the communication path as soon as all
without losing any important information.</t> data is available. One example is finding the maximum of all sensor
<t>(Semantic) data (pre-)processing, e.g., in the form of computations across values, which can either be done iteratively at each intermediate hop
multiple packets and potentially leveraging packet payload, can also reduce the or at the first hop where all data is available. Using expert
data volume without losing any important information.</t> knowledge about the exact computation steps and the concrete
</list></t> transmission path of the sensor data, simple computation steps can
thus be deployed in the on-premise network, again reducing the
</section> overall data volume.</t>
<section anchor="FilteringRQ"><name>Research Questions</name> </section>
<section anchor="FilteringSol">
<t>Some of the following research questions are also relevant in the context of <name>Existing Solutions</name>
general stream processing systems.</t> <t>Current approaches for handling such large amounts of information
typically build upon stream processing frameworks such as Apache
<t><list style="symbols"> Flink. These solutions allow for handling large-volume applications
<t>RQ 4.2.1: How can the overall data processing pipeline be divided into indi and map the compute functionality to performant server machines or
vidual processing steps that could then be deployed as COIN functionality?</t> distributed compute platforms. Augmenting the existing
<t>RQ 4.2.2: How to design COIN programs for (semantic) packet filtering and w capabilities, COIN offers a new dimension of platforms for such
hich filtering criteria make sense?</t> processing frameworks.</t>
<t>RQ 4.2.3: Which kinds of COIN programs can be leveraged for (pre-)processin </section>
g steps and what complexity can they have?</t> <section anchor="FilteringOppo">
<t>RQ 4.2.4: How to distribute and coordinate COIN programs?</t> <name>Opportunities</name>
<t>RQ 4.2.5: How to dynamically reconfigure and recompose COIN programs?</t> <ul spacing="normal">
<t>RQ 4.2.6: How to incorporate the (pre-)processing and filtering steps into <li>
the overall system?</t> <t>(Stream) processing frameworks can become more flexible by
<t>RQ 4.2.7: How can changes to the data by COIN programs be signaled to the e introducing COIN execution environments as additional deployment
nd-hosts?</t> targets.</t>
</list></t> </li>
<li>
</section> <t>(Semantic) packet filtering based on packet header and
<section anchor="FilteringReq"><name>Additional Desirable Capabilities</name> payload, as well as multipacket information can (drastically)
reduce the data volume, possibly even without losing any
<t>In addition to the capabilities driven by the research questions above, there important information.</t>
are a number of other features that such large volume applications could benefi </li>
t from. <li>
In particular, conforming to standard application-level syntax and semantics lik <t>(Semantic) data preprocessing and processing (e.g., in the form
ely simplifies embedding filters and preprocessors into the overall system. of
If these filters and preprocessors also leverage packet header and payload infor computations across multiple packets and potentially leveraging
mation for their operation, this could further improve the performance of any ap packet payload) can also reduce the data volume without losing
proach developed based on the above research questions.</t> any important information.</t>
</li>
</section> </ul>
</section> </section>
<section anchor="safety"><name>Industrial Safety</name> <section anchor="FilteringRQ">
<name>Research Questions</name>
<section anchor="description-4"><name>Description</name> <t>Some of the following research questions are also relevant in the
context of general stream processing systems.</t>
<t>Despite an increasing automation in production processes, human workers are s <ul spacing="normal">
till often necessary. <li>
Consequently, safety measures have a high priority to ensure that no human life <t>RQ 4.2.1: How can the overall data processing pipeline be
is endangered. divided into individual processing steps that could then be
In traditional factories, the regions of contact between humans and machines are deployed as COIN functionality?</t>
well-defined and interactions are simple. </li>
Simple safety measures like emergency switches at the working positions are enou <li>
gh to provide a good level of safety.</t> <t>RQ 4.2.2: How to design COIN programs for (semantic) packet
filtering and which filtering criteria make sense?</t>
<t>Modern factories are characterized by increasingly dynamic and complex enviro </li>
nments with new interaction scenarios between humans and robots. <li>
Robots can directly assist humans, perform tasks autonomously, or even freely mo <t>RQ 4.2.3: Which kinds of COIN programs can be leveraged for
ve around on the shopfloor. preprocessing and processing steps and what complexity can they ha
Hence, the intersect between the human working area and the robots grows and it ve?</t>
is harder for human workers to fully observe the complete environment. </li>
Additional safety measures are essential to prevent accidents and support humans <li>
in observing the environment.</t> <t>RQ 4.2.4: How to distribute and coordinate COIN programs?</t>
</li>
</section> <li>
<section anchor="characterization-4"><name>Characterization</name> <t>RQ 4.2.5: How to dynamically reconfigure and recompose COIN pro
grams?</t>
<t>Industrial safety measures are typically hardware solutions because they have </li>
to pass rigorous testing before they are certified and deployment-ready. <li>
Standard measures include safety switches and light barriers. <t>RQ 4.2.6: How to incorporate the preprocessing, processing, and
Additionally, the working area can be explicitly divided into 'contact' and 'saf filtering steps into the overall system?</t>
e' areas, indicating when workers have to watch out for interactions with machin </li>
ery. <li>
For example, markings on the factory floor can show the areas where robots move <t>RQ 4.2.7: How can changes to the data by COIN programs be
or indicate their maximum physical reach.</t> signaled to the end hosts?</t>
</li>
<t>These measures are static solutions, potentially relying on specialized hardw </ul>
are, and are challenged by the increased dynamics of modern factories where the </section>
factory configuration can be changed on demand or where all entities are freely <section anchor="FilteringReq">
moving around. <name>Additional Desirable Capabilities</name>
Software solutions offer higher flexibility as they can dynamically respect new <t>In addition to the capabilities driven by the research questions
information gathered by the sensor systems, but in most cases they cannot give g above, there are a number of other features that such large-volume
uaranteed safety. applications could benefit from. In particular, conforming to
COIN systems could leverage the increased availability of sensor data and the de standard application-level syntax and semantics likely simplifies
tailed monitoring of the factories to enable additional safety measures with sho embedding filters and preprocessors into the overall system. If
rter response times and higher guarantees. these filters and preprocessors also leverage packet header and
Different safety indicators within the production hall could be combined within payload information for their operation, this could further improve
the network so that PNDs can give early responses if a potential safety breach i the performance of any approach developed based on the above
s detected. research questions.</t>
For example, the positions of human workers and robots could be tracked and robo </section>
ts could be stopped when they get too close to a human in a non-working area or </section>
if a human enters a defined safety zone. <section anchor="safety">
More advanced concepts could also include image data or combine arbitrary sensor <name>Industrial Safety</name>
data. <section anchor="description-4">
Finally, the increasing softwarization of industrial processes can also lead to <name>Description</name>
new problems, e.g., if software bugs cause unintended movements of robots. <t>Despite an increasing automation in production processes, human
Here, COIN systems could independently double check issued commands to void unsa workers are still often necessary. Consequently, safety measures
fe commands.</t> have a high priority to ensure that no human life is endangered. In
conventional factories, the regions of contact between humans and
</section> machines are well defined and interactions are simple. Simple
<section anchor="existing-solutions-4"><name>Existing Solutions</name> safety measures like emergency switches at the working positions are
enough to provide a good level of safety.</t>
<t>Due to the importance of safety, there is a wide range of software-based appr <t>Modern factories are characterized by increasingly dynamic and
oaches aiming at enhancing security. complex environments with new interaction scenarios between humans
One example are tag-based systems, e.g., using RFID, where drivers of forklifts and robots. Robots can directly assist humans, perform tasks
can be warned if pedestrian workers carrying tags are nearby. autonomously, or even freely move around on the shop floor. Hence,
Such solutions, however, require setting up an additional system and do not leve the intersect between the human working area and the robots grows,
rage existing sensor data.</t> and it is harder for human workers to fully observe the complete
environment. Additional safety measures are essential to prevent
</section> accidents and support humans in observing the environment.</t>
<section anchor="opportunities-4"><name>Opportunities</name> </section>
<section anchor="characterization-4">
<t><list style="symbols"> <name>Characterization</name>
<t>Executing safety-critical COIN functions on PNDs could allow for early emer <t>Industrial safety measures are typically hardware solutions
gency reactions based on diverse sensor feedback with low latencies.</t> because they have to pass rigorous testing before they are certified
<t>COIN software could provide independent on-path surveillance of control sof and deployment ready. Standard measures include safety switches and
tware-initiated actions to block unsafe commands.</t> light barriers. Additionally, the working area can be explicitly
</list></t> divided into "contact" and "safe" areas, indicating when workers
have to watch out for interactions with machinery. For example,
</section> markings on the factory floor can show the areas where robots move
<section anchor="research-questions-3"><name>Research Questions</name> or indicate their maximum physical reach.</t>
<t>These measures are static solutions, potentially relying on
<t><list style="symbols"> specialized hardware, and are challenged by the increased dynamics
<t>RQ 4.3.1: Which additional safety measures can be provided and do they actu of modern factories where the factory configuration can be changed
ally improve safety?</t> on demand or where all entities are freely moving around. Software
<t>RQ 4.3.2: Which sensor information can be combined and how?</t> solutions offer higher flexibility as they can dynamically respect
<t>RQ 4.3.3: How can COIN-based safety measures be integrated with existing sa new information gathered by the sensor systems, but in most cases
fety measures without degrading safety?</t> they cannot give guaranteed safety. COIN systems could leverage the
<t>RQ 4.3.4: How can COIN software validate control software-initated commands increased availability of sensor data and the detailed monitoring of
to prevent unsafe operations?</t> the factories to enable additional safety measures with shorter
</list></t> response times and higher guarantees. Different safety indicators
within the production hall could be combined within the network so
</section> that PNDs can give early responses if a potential safety breach is
</section> detected. For example, the positions of human workers and robots
</section> could be tracked, and robots could be stopped when they get too close
<section anchor="existingCapabilities"><name>Improving existing COIN capabilitie to a human in a non-working area or if a human enters a defined
s</name> safety zone. More advanced concepts could also include image data
or combine arbitrary sensor data. Finally, the increasing
<section anchor="CDNs"><name>Content Delivery Networks</name> softwarization of industrial processes can also lead to new
problems, e.g., if software bugs cause unintended movements of
<section anchor="description-5"><name>Description</name> robots. Here, COIN systems could independently double check issued
commands to void unsafe commands.</t>
<t>Delivery of content to end users often relies on Content Delivery Networks (C </section>
DNs). <section anchor="existing-solutions-4">
CDNs store said content closer to end users for latency-reduced delivery as well <name>Existing Solutions</name>
as to reduce load on origin servers. <t>Due to the importance of safety, there is a wide range of
For this, they often utilize DNS-based indirection to serve the request on behal software-based approaches aiming at enhancing security. One example
f of the origin server. are tag-based systems (e.g., using RFID), where drivers of forklifts
Both of these objectives are within scope to be addressed by COIN methods and so can be warned if pedestrian workers carrying tags are nearby. Such
lutions.</t> solutions, however, require setting up an additional system and do
not leverage existing sensor data.</t>
</section> </section>
<section anchor="characterization-5"><name>Characterization</name> <section anchor="opportunities-4">
<name>Opportunities</name>
<t>From the perspective of this draft, a CDN can be interpreted as a (network se <ul spacing="normal">
rvice level) set of (COIN) programs. <li>
These programs implement a distributed logic for first distributing content from <t>Executing safety-critical COIN functions on PNDs could allow
the origin server to the CDN ingress and then further to the CDN replication po for early emergency reactions based on diverse sensor feedback
ints which ultimately serve the user-facing content requests.</t> with low latencies.</t>
</li>
</section> <li>
<section anchor="existing-solutions-5"><name>Existing Solutions</name> <t>COIN software could provide independent on-path surveillance
of control software-initiated actions to block unsafe
<t>CDN technologies have been well described and deployed in the existing Intern commands.</t>
et. </li>
Core technologies like Global Server Load Balancing (GSLB) <xref target="GSLB"/> </ul>
and Anycast server solutions are used to deal with the required indirection of </section>
a content request (usually in the form of an HTTP request) to the most suitable <section anchor="research-questions-3">
local CDN server. <name>Research Questions</name>
Content is replicated from seeding servers, which serve as injection points for <ul spacing="normal">
content from content owners/producers, to the actual CDN servers, who will event <li>
ually serve the user's request. <t>RQ 4.3.1: Which additional safety measures can be provided
The replication architecture and mechanisms itself differs from one (CDN) provid and do they actually improve safety?</t>
er to another, and often utilizes private peering or network arrangements in ord </li>
er to distribute the content internationally and regionally.</t> <li>
<t>RQ 4.3.2: Which sensor information can be combined and
<t>Studies such as those in <xref target="FCDN"/> have shown that content distri how?</t>
bution at the level of named content, utilizing efficient (e.g., Layer 2) multic </li>
ast for replication towards edge CDN nodes, can significantly increase the overa <li>
ll network and server efficiency. <t>RQ 4.3.3: How can COIN-based safety measures be integrated
It also reduces indirection latency for content retrieval as well as required ed with existing safety measures without degrading safety?</t>
ge storage capacity by benefiting from the increased network efficiency to renew </li>
edge content more quickly against changing demand. <li>
Works such as those in <xref target="SILKROAD"/> utilize ASICs to replace server <t>RQ 4.3.4: How can COIN software validate control
-based load balancing with significant cost reductions, thus showcasing the pote software-initiated commands to prevent unsafe operations?</t>
ntial for in-network CN operations.</t> </li>
</ul>
</section> </section>
<section anchor="opportunities-5"><name>Opportunities</name> </section>
</section>
<t><list style="symbols"> <section anchor="existingCapabilities">
<t>Supporting service-level routing of requests (service routing in <xref targ <name>Improving Existing COIN Capabilities</name>
et="APPCENTRES"/>) to specific (COIN) program instances may improve on end user <section anchor="CDNs">
experience in faster retrieving (possibly also more, e.g., better quality) conte <name>Content Delivery Networks</name>
nt.</t> <section anchor="description-5">
<t>COIN instances may also be utilized to integrate service-related telemetry <name>Description</name>
information to support the selection of the final service instance destination f <t>Delivery of content to end users often relies on Content Delivery
rom a pool of possible choices</t> Networks (CDNs). CDNs store said content closer to end users for
<t>Supporting the selection of a service destination from a set of possible (e latency-reduced delivery as well as to reduce load on origin
.g., virtualized, distributed) choices, e.g., through constraint-based routing d servers. For this, they often utilize DNS-based indirection to
ecisions (see <xref target="APPCENTRES"/>) in (COIN) program instances to improv serve the request on behalf of the origin server. Both of these
e the overall end user experience by selecting a 'more suitable' service destina objectives are within scope to be addressed by COIN methods and
tion over another, e.g., avoiding/reducing overload situations in specific servi solutions.</t>
ce destinations.</t> </section>
<t>Supporting Layer 2 capabilities for multicast (compute interconnection and <section anchor="characterization-5">
collective communication in <xref target="APPCENTRES"/>), e.g., through in-netwo <name>Characterization</name>
rk/switch-based replication decisions (and their optimizations) based on dynamic <t>From the perspective of this draft, a CDN can be interpreted as a
group membership information, may reduce the network utilization and therefore (network service level) set of COIN programs. These programs
increase the overall system efficiency.</t> implement a distributed logic for first distributing content from
</list></t> the origin server to the CDN ingress and then further to the CDN
replication points, which ultimately serve the user-facing content
</section> requests.</t>
<section anchor="research-questions-4"><name>Research Questions</name> </section>
<t>In addition to the research questions in <xref target="mobileOffloadRQ"/>:</t <section anchor="existing-solutions-5">
> <name>Existing Solutions</name>
<t>CDN technologies have been well described and deployed in the
<t><list style="symbols"> existing Internet. Core technologies like Global Server Load
<t>RQ 5.1.1: How to utilize L2 multicast to improve on CDN designs? How to uti Balancing (GSLB) <xref target="GSLB"/> and Anycast server solutions
lize COIN capabilities in those designs, such as through on-path optimizations f are used to deal with the required indirection of a content request
or fanouts?</t> (usually in the form of an HTTP request) to the most suitable local
<t>RQ 5.1.2: What forwarding methods may support the required multicast capabi CDN server. Content is replicated from seeding servers, which serve
lities (see <xref target="FCDN"/>) and how could programmable COIN forwarding el as injection points for content from content owners/producers, to
ements support those methods (e.g., extending current SDN capabilities)?</t> the actual CDN servers, which will eventually serve the user's
<t>RQ 5.1.3: What are the constraints, reflecting both compute and network cap request. The replication architecture and mechanisms themselves diffe
abilities, that may support joint optimization of routing and computing? How cou r
ld intermediary (COIN) program instances support, e.g., the aggregation of those from one (CDN) provider to another, and often utilize private
constraints to reduce overall telemetry network traffic?</t> peering or network arrangements in order to distribute the content
<t>RQ 5.1.4: Could traffic steering be performed on the data path and per serv internationally and regionally.</t>
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>
</section>
<section anchor="CFaaS"><name>Compute-Fabric-as-a-Service (CFaaS)</name>
<section anchor="description-6"><name>Description</name>
<t>We interpret connected compute resources as operating at a suitable layer, su
ch as Ethernet, InfiBand but also at Layer 3, to allow for the exchange of suita
ble invocation methods, such as exposed through verb-based or socket-based APIs.
The specific invocations here are subject to the applications running over a sel
ected pool of such connected compute resources.</t>
<t>Providing such pool of connected compute resources, e.g., in regional or edge
data centers, base stations, and even end user devices, opens up the opportunit
y for infrastructure providers to offer CFaaS-like offerings to application prov
iders, leaving the choice of the appropriate invocation method to the app and se
rvice provider.
Through this, the compute resources can be utilized to execute the desired (COIN
) programs of which the application is composed, while utilizing the interconnec
tion between those compute resources to do so in a distributed manner.</t>
</section>
<section anchor="characterization-6"><name>Characterization</name>
<t>We foresee those CFaaS offerings to be tenant-specific, a tenant here defined
as the provider of at least one application.
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
the compute fabric that in turn requires trust relationships to be built dynamic
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>
<section anchor="existing-solutions-6"><name>Existing Solutions</name>
<t>There exist a number of technologies to build non-local (wide area) Layer 2 a
s well as Layer 3 networks, which in turn allows for connecting compute resource
s for a distributed computational task.
For instance, 5G-LAN <xref target="SA2-5GLAN"/> specifies a cellular L2 bearer f
or interconnecting L2 resources within a single cellular operator.
The work in <xref target="ICN5GLAN"/> outlines using a path-based forwarding sol
ution over 5G-LAN as well as SDN-based LAN connectivity together with an ICN-bas
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>
<section anchor="opportunities-6"><name>Opportunities</name>
<t><list style="symbols">
<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>
<section anchor="research-questions-5"><name>Research Questions</name>
<t>In addition to the research questions in <xref target="mobileOffloadRQ"/>:</t
>
<t><list style="symbols">
<t>RQ 5.2.1: How to convey tenant-specific requirements for the creation of th
e CFaaS fabric?</t>
<t>RQ 5.2.2: How to dynamically integrate resources into the compute fabric be
ing utilized for the app execution (those resources include, but are not limited
to, end user provided resources), particularly when driven by tenant-level requ
irements and changing service-specific constraints? How can those resources be e
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>
</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, e.g., be P4 programs, OpenFlow rules, or higher layer pr
ograms.
This feature can enable other use cases described in this draft to be deployed u
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
network:</t>
<t><list style="symbols">
<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>
<t>Forward a copy of some flows towards a node for storage and analysis</t>
<t>Update metrics based on specific sources/destinations or protocols, for det
ailed analytics</t>
<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>
<t>Experiment with a new routing protocol (e.g., ICN), using a P4 implementati
on of a router for this protocol</t>
</list></t>
</section>
<section anchor="characterization-7"><name>Characterization</name>
<t>To provide a concrete example of virtual COIN programming, we consider a use <t>Studies such as those in <xref target="FCDN"/> have shown that
case using a 5G underlying network, the 5GLAN virtualization technology, and the content distribution at the level of named content, utilizing
P4 programming language and environment. efficient (e.g., Layer 2 (L2)) multicast for replication towards edge
As an assumption in this use case, some mobile network equipment (e.g., UPF) and CDN
devices (e.g., mobile phones or residential gateways) include a network switch nodes, can significantly increase the overall network and server
functionality that is used as a PND.</t> 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 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>
<li>
<t>Supporting the selection of a service destination from a set of
possible choices (virtualized and distributed) in COIN program
instances (e.g., through constraint-based routing decisions as
seen in
[APPCENTRES]) to improve the overall end-user experience by sel
ecting a
"more suitable" service destination over another (e.g.,
avoiding/reducing overload situations in specific service desti
nations).</t>
</li>
<li>
<t>Supporting L2 capabilities for multicast (compute interconnecti
on
and collective communication as seen in [APPCENTRES]) may
reduce the network utilization and therefore increase the overa
ll
system efficiency. For example, this support may be
through in-network, switch-based replication decisions (and the
ir
optimizations) based on dynamic group membership information.</
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>
<t>Section 5.1 of <xref target="I-D.ravi-icnrg-5gc-icn"/> provides a description <t>We interpret connected compute resources as operating at a
of the 5G network functions and interfaces relevant to 5GLAN, which are otherwi suitable layer, such as Ethernet, InfiniBand, but also at Layer 3 (L3)
se specified in <xref target="TS23.501"/> and <xref target="TS23.502"/>. , to
From the 5GLAN service customer/tenant standpoint, the 5G network operates as a allow for the exchange of suitable invocation methods, such as those
switch.</t> exposed through verb-based or socket-based APIs. The specific
invocations here are subject to the applications running over a
selected pool of such connected compute resources.</t>
<t>Providing such a pool of connected compute resources (e.g., in
regional or edge data centers, base stations, and even end-user
devices) opens up the opportunity for infrastructure providers to
offer CFaaS-like offerings to application providers, leaving the
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>
<t>In the use case depicted in <xref target="figureVN1"/>, the tenant operates a <section anchor="characterization-6">
network including a 5GLAN network segment (seen as a single logical switch), as <name>Characterization</name>
well as fixed segments. <t>We foresee those CFaaS offerings to be tenant-specific, with a tena
The mobile devices (or User Equipment nodes) UE1, UE2, UE3 and UE4 are in the sa nt
me 5GLAN, as well as Device1 and Device2 (through UE4). here defined as the provider of at least one application. For this,
This scenario can take place in a plant or enterprise network, using, e.g., a 5G we foresee an interaction between the CFaaS provider and tenant to
Non-Public Network. dynamically select the appropriate resources to define the demand
The tenant uses P4 programs to determine the operation of both the fixed and 5GL side of the fabric. Conversely, we also foresee the supply side of
AN switches. the fabric to be highly dynamic, with resources being offered to the
The tenant provisions a 5GLAN P4 program into the mobile network, and can also o fabric through, for example, user-provided resources (whose supply mig
perate a controller.</t> 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-internet-icn-5glan"/> outlines using a
path-based forwarding solution over 5G-LAN as well as SDN-based LAN
connectivity together with an ICN-based naming of IP and HTTP-level re
sources. 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-based" 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 routin
g 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>
<figure title="5G Virtual Network Programming Overview" anchor="figureVN1"><artw <li>
ork><![CDATA[ <t>Supporting intermediary COIN program
instances to allow for the enforcement of trust relationships and
isolation policies (e.g., enforcing specific traffic shares or str
ict
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 1802
| | | |
| 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 <li>
ween data centers, 5G networks, and other fixed and wireless networks, as well a <t>A unified programming model, which can facilitate porting
s sharing controller, code and expertise.</t> COIN programs between data centers, 5G networks, and other fixed
<t>Increasing the level of customization available to customers/tenants of mob and wireless networks, as well as sharing controllers, code, and
ile networks or datacenters compared to typical configuration capabilities. expertise.</t>
For example, 5G network evolution points to an ever increasing specialization an </li>
d customization of private mobile networks, which could be handled by tenants us <li>
ing a programming model similar to P4.</t> <t>Increasing the level of customization available to
<t>Using network programs to influence underlying network services, e.g., requ customers/tenants of mobile networks or data centers compared to
est specific QoS for some flows in 5G or datacenters, to increase the level of i typical configuration capabilities. For example, 5G network
n-depth customization available to tenants.</t> evolution points to an ever-increasing specialization and
</list></t> customization of private mobile networks, which could be handled
by tenants using a programming model similar to P4.</t>
</section> </li>
<section anchor="research-questions-6"><name>Research Questions</name> <li>
<t>Using network programs to influence underlying network
<t><list style="symbols"> services (e.g., requesting specific QoS for some flows in 5G or
<t>RQ 5.3.1: Underlying Network Awareness: a virtual COIN program can be able data centers) to increase the level of in-depth customization
to influence, and be influenced by, the underling network. Research challenges i available to tenants.</t>
nclude defining methods to distribute COIN programs, including in a mobile netwo </li>
rk context, based on network awareness, since some information and actions may b </ul>
e available on some nodes but not on others.</t> </section>
<t>RQ 5.3.2: Splitting/Distribution: a virtual COIN program may need to be dep <section anchor="research-questions-6">
loyed across multiple computing nodes, leading to research questions around inst <name>Research Questions</name>
ance placement and distribution. For example, program logic should be applied ex <ul spacing="normal">
actly once or at least once per packet (or at least once for idempotent operatio <li>
ns), while allowing optimal forwarding path by the underlying network. Research <t>RQ 5.3.1: Underlying network awareness</t>
challenges include defining manual (by the programmer) or automatic methods to d <t>A virtual COIN program can both influence, and be
istribute COIN programs that use a low or minimal amount of resources. Distribut influenced by, the underling network. Research challenges
ed P4 programs are studied in <xref target="I-D.hsingh-coinrg-reqs-p4comp"/> and include defining methods to distribute COIN programs, including
<xref target="Sultana"/> (based on capability 5.3.2).</t> in a mobile network context, based on network awareness, since
<t>RQ 5.3.3: Multi-Tenancy Support: A COIN system supporting virtualization sh some information and actions may be available on some nodes but
ould enable tenants to deploy COIN programs onto their virtual networks, in such not on others.</t>
a way that multiple virtual COIN program instances can run on the same compute </li>
node. While mechanisms were proposed for P4 multi-tenancy in a switch <xref targ <li>
et="Stoyanov"/>, research questions remain about isolation between tenants and f <t>RQ 5.3.2: Splitting/distribution</t>
air repartition of resources (based on capability 5.3.3).</t> <t>A virtual COIN program may need to be deployed across
<t>RQ 5.3.4: Security: how can tenants and underlying networks be protected ag multiple computing nodes, leading to research questions around
ainst security risks, including overuse or misuse of network resources, injectio instance placement and distribution. For example, program logic
n of traffic, or access to unauthorized traffic?</t> should be applied exactly once or at least once per packet (or
<t>RQ 5.3.5: Higher layer processing: can a virtual network model facilitate t at least once for idempotent operations), while allowing an optimal
he deployment of COIN programs acting on application layer data? This is an open forwarding path by the underlying network. Research challenges
question since the present section focused on packet/flow processing.</t> include defining manual (by the programmer) or automatic methods
</list></t> to distribute COIN programs that use a low or minimal amount of
resources. Distributed P4 programs are studied in <xref
</section> target="I-D.hsingh-coinrg-reqs-p4comp"/> and <xref
</section> target="Sultana"/> (based on capability 5.3.2).</t>
</section> </li>
<section anchor="newCapabilities"><name>Enabling new COIN capabilities</name> <li>
<t>RQ 5.3.3: Multi-tenancy support</t>
<section anchor="distributedAI"><name>Distributed AI Training</name> <t>A COIN system supporting virtualization should enable tenants
to deploy COIN programs onto their virtual networks, in such a
<section anchor="description-8"><name>Description</name> way that multiple virtual COIN program instances can run on the
same compute node. While mechanisms were proposed for P4
<t>There is a growing range of use cases demanding the realization of AI trainin multi-tenancy in a switch <xref target="Stoyanov"/>, research
g capabilities among distributed endpoints. questions remain about isolation between tenants and fair
One such use case is to distribute large-scale model training across more than o repartition of resources (based on capability 5.3.3).</t>
ne data center, e.g., when facing energy issues at a single site or when simply </li>
reaching the scale of training capabilities at one site, thus wanting to complem <li>
ent training with capabilities of another, possibly many sites. <t>RQ 5.3.4: Security</t>
From a COIN perspective, those capabilities may be realized as (COIN) programs a <t>How can tenants and underlying networks
nd executed throughout a COIN system, including in PNDs.</t> be protected against security risks, including overuse or misuse
of network resources, injection of traffic, or access to
</section> unauthorized traffic?</t>
<section anchor="characterization-8"><name>Characterization</name> </li>
<li>
<t>Some solutions may desire the localization of reasoning logic, e.g., for deri <t>RQ 5.3.5: Higher layer processing</t>
ving attributes that better preserve privacy of the utilized raw input data. <t>Can a virtual network model facilitate the deployment of COIN
Quickly establishing (COIN) program instances in nearby compute resources, inclu programs acting on application-layer data? This is an open
ding PNDs, may even satisfy such localization demands on-the-fly (e.g., when a p question, since this section focuses on packet/flow
articular use is being realized, then terminated after a given time).</t> processing.</t>
</li>
<t>Individual training 'sites' may not be a data center, but instead consist of </ul>
powerful, yet stand-along devices, that federate computing power towards trainin </section>
g a model, captured as 'federated training' and provided through platforms such </section>
as <xref target="FLOWER"/>. </section>
Use cases here may be that of distributed training on (user) image data, the tra
ining 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 federat
ed social media sits <xref target="MASTODON"/> or training over locally governed
patient data or others.</t>
</section>
<section anchor="existing-solutions-8"><name>Existing Solutions</name>
<t>Reasoning frameworks, such as TensorFlow, may be utilized for the realization
of the (distributed) AI training logic, building on remote service invocation t
hrough protocols such as gRPC <xref target="GRPC"/> or MPI <xref target="MPI"/>
with the intention of providing an on-chip NPU (neural processor unit) like abst
raction to the AI framework.</t>
<t>A number of activities on distributed AI training exist in the area of develo
ping the 5th and 6th generation mobile network with various activities in the 3G
PP SDO as well as use cases developed for the ETSI MEC initiative mentioned in p
revious use cases.</t>
</section>
<section anchor="opportunities-8"><name>Opportunities</name>
<t><list style="symbols"> <section anchor="newCapabilities">
<t>Supporting service-level routing of training requests (service routing in < <name>Enabling New COIN Capabilities</name>
xref target="APPCENTRES"/>), with AI services being exposed to the network, wher
e (COIN) program instances may support the selection of the most suitable servic
e instance based on control plane information, e.g., on AI worker compute capabi
lities, being distributed across (COIN) program instances.</t>
<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> <section anchor="distributedAI">
<section anchor="research-questions-7"><name>Research Questions</name> <name>Distributed AI Training</name>
<t>In addition to the research questions in <xref target="mobileOffloadRQ"/>:</t <section anchor="description-8">
> <name>Description</name>
<t>There is a growing range of use cases demanding the realization
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><list style="symbols"> <section anchor="characterization-8">
<t>RQ 6.1.1: What are the communication patterns that may be supported by coll <name>Characterization</name>
ective communication solutions, where those solutions directly utilize (COIN) pr <t>Some solutions may desire the localization of reasoning logic
ogram instance capabilities within the network (e.g., reduce in a central (COIN) (e.g., for deriving attributes that better preserve privacy of the
program instance)?</t> utilized raw input data). Quickly establishing COIN program
<t>RQ 6.1.2: How to achieve scalable collective communication primitives with instances in nearby compute resources, including PNDs, may even
rapidly changing receiver sets, e.g., where training workers may be dynamically satisfy such localization demands on the fly (e.g., when a
selected based on energy efficiency constraints <xref target="GREENAI"/>?</t> particular use is being realized, then terminated after a given
<t>RQ 6.1.3: What COIN capabilities may support the collective communication p time).</t>
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> <t>Individual training "sites" may not be a data center, but may inste
</section> ad
</section> consist of powerful, yet stand-along devices that federate
<section anchor="preliminary-categorization-of-the-research-questions"><name>Pre computing power towards training a model, captured as "federated
liminary Categorization of the Research Questions</name> 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>This section describes a preliminary categorization of the reseach questions, <section anchor="existing-solutions-8">
illustrated in <xref target="figureRQCategories"/>. <name>Existing Solutions</name>
A more comprehensive analysis has been initiated by members of the COINRG commun <t>Reasoning frameworks, such as TensorFlow, may be utilized for the
ity in <xref target="USECASEANALYSIS"/> but has not been completed at the time o realization of the (distributed) AI training logic, building on
f writing this memo.</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">
<figure title="Research Questions Categories" anchor="figureRQCategories"><artwo <name>Opportunities</name>
rk><![CDATA[ <ul spacing="normal">
<li>
<t>Supporting service-level routing of training requests (such as
service
routing in [APPCENTRES]) with AI services being exposed to the
network, and where COIN program instances may support the selec
tion
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 and scatter-gather, utilized by the (distributed) AI
workers may increase the overall network efficiency (e.g.,
through avoiding endpoint-based replication or even directly
performing 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">
<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., perform Reduce options 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 <t>The "Vision(s) for COIN" category is about defining and shaping the
pe of COIN. exact scope of COIN. In contrast to the "Enabling Technologies" category,
In contrast to the ENABLING TECHNOLOGIES category, these research questions look these research questions look at the problem from a more philosophical
at the problem from a more philosophical perspective. perspective. In particular, the questions center around where to
In particular, the questions center around where to perform computations, which perform computations, which tasks are suitable for COIN, for which tasks
tasks are suitable for COIN, for which tasks COIN is suitable, and which forms o COIN is suitable, and which forms of deploying COIN might be desirable.
f deploying COIN might be desirable. This category includes the research questions 3.1.8, 3.2.1, 3.3.5,
This category includes the research questions 3.1.8, 3.2.1, 3.3.5, 3.3.6, 3.3.7, 3.3.6, 3.3.7, 5.3.3, 6.1.1, and 6.1.3.</t>
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
<t>The *ENABLING TECHNOLOGIES for COIN* category digs into what technologies are technologies can be reused for COIN, and what might be needed to make
needed to enable COIN, which of the existing technologies can be reused for COI the "Vision(s) for COIN" a reality. In contrast to the "Vision(s) for COI
N, and what might be needed to make the VISION(S) for COIN a reality. N", these
In contrast to the VISION(S), these research questions look at the problem from research questions look at the problem from a practical perspective
a practical perspective, e.g., by considering how COIN can be incorporated in ex (e.g., by considering how COIN can be incorporated in existing systems or
isting systems or how the interoperability of COIN execution environments can be how the interoperability of COIN execution environments can be enhanced).
enhanced. This category includes the research questions 3.1.7, 3.1.8, 3.2.3,
This category includes the research questions 3.1.7, 3.1.8, 3.2.3, 4.2.7, 5.1.1, 4.2.7, 5.1.1, 5.1.2, 5.1.6, 5.3.1, 6.1.2, and 6.1.3.</t>
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
<t>The *Distributed Computing FRAMEWORKS and LANGUAGES to COIN* category focuses questions arise regarding the composition of COIN programs, the
on how COIN programs can be deployed and orchestrated. placement of COIN functions, the (dynamic) operation and integration of
Central questions arise regarding the composition of COIN programs, the placemen COIN systems as well as additional COIN system properties. Notably,
t of COIN functions, the (dynamic) operation and integration of COIN systems as COIN diversifies general distributed computing platforms such that many
well as additional COIN system properties. COIN-related research questions could also apply to general distributed
Notably, COIN diversifies general distributed computing platforms such that many computing frameworks. This category includes the research questions
COIN-related research questions could also apply to general distributed computi 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,
ng frameworks. 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,
This category includes the research questions 3.1.1, 3.2.4, 3.3.1, 3.3.2, 3.3.3, 5.3.2, 5.3.3, 5.3.4, 5.3.5, and 6.1.5.</t>
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. <t>In addition to these core categories, there are use case specific
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> research questions that are heavily influenced by the specific
constraints and objectives of the respective use cases. This
<t>In addition to these core categories, there are use-case-specific research qu "Applicability Areas" category can be further refined into the following
estions that are heavily influenced by the specific constraints and objectives o subgroups:</t>
f the respective use cases. <ul spacing="normal">
This *Applicability Areas* category can be further refined into the following su <li>
bgroups:</t> <t>The "Transport" subgroup addresses the need to adapt transport
protocols to handle dynamic deployment locations effectively. This
<t><list style="symbols"> subgroup includes the research question 3.1.2.</t>
<t>The *Transport* subgroup addresses the need to adapt transport protocols to </li>
handle dynamic deployment locations effectively. <li>
This subgroup includes the research question 3.1.2.</t> <t>The "App Design" subgroup relates to the design principles and
<t>The *App Design* subgroup relates to the design principles and consideratio considerations when developing COIN applications. This subgroup
ns when developing COIN applications. includes the research questions 4.1.2, 4.1.3, 4.1.7, 4.2.6, 5.1.1,
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>
5.1.3, and 5.1.5.</t> </li>
<t>The *Data Processing* subgroup relates to the handling, storage, analysis, <li>
and processing of data in COIN environments. <t>The "Data Processing" subgroup relates to the handling, storage,
This subgroup includes the research questions 3.2.4, 3.2.6, 4.2.2, 4.2.3, and 4. analysis, and processing of data in COIN environments. This
3.2.</t> subgroup includes the research questions 3.2.4, 3.2.6, 4.2.2, 4.2.3,
<t>The *Routing &amp; Forwarding* subgroup explores efficient routing and forw and 4.3.2.</t>
arding mechanisms in COIN, considering factors such as network topology, congest </li>
ion control, and quality of service. <li>
This subgroup includes the research questions 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.1.6, <t>The "Routing &amp; Forwarding" subgroup explores efficient
3.2.6, 5.1.2, 5.1.3, 5.1.4, and 6.1.4.</t> routing and forwarding mechanisms in COIN, considering factors such
<t>The *(Industrial) Control* subgroup relates to industrial control systems, as network topology, congestion control, and quality of service.
addressing issues like real-time control, automation, and fault tolerance. This subgroup includes the research questions 3.1.2, 3.1.3, 3.1.4,
This subgroup includes the research questions 3.1.9, 3.2.5, 3.3.1, 3.3.4, 4.1.1, 3.1.5, 3.1.6, 3.2.6, 5.1.2, 5.1.3, 5.1.4, and 6.1.4.</t>
4.1.6, 4.1.8, 4.2.3, 4.3.1, and 4.3.4.</t> </li>
</list></t> <li>
<t>The "(Industrial) Control" subgroup relates to industrial control
</section> systems, addressing issues like real-time control, automation, and
<section anchor="sec_considerations"><name>Security Considerations</name> 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
<t>COIN systems, like any other system using ``middleboxes'', can have different 4.3.4.</t>
security and privacy implications that strongly depend on the used platforms, t </li>
he provided functionality, and the deployment domain, with most if not all consi </ul>
derations for general middleboxes also applying for COIN systems.</t> </section>
<section anchor="sec_considerations">
<t>One critical aspect for early COIN systems is the use of early-generation PND <name>Security Considerations</name>
s, many of which do not have cryptography support and only have limited computat <t>COIN systems, like any other system using "middleboxes", can have
ional capabilities. different security and privacy implications that strongly depend on the
Hence, PND-based COIN systems typically work on unencrypted data and often custo used platforms, the provided functionality, and the deployment domain,
mize packet payload while concepts, such as homomorphic encryption, could serve with most if not all considerations for general middleboxes also
as workarounds, allowing PNDs to perform simple operations on the encrypted data applying to COIN systems.</t>
without having access to it. <t>One critical aspect for early COIN systems is the use of early
All these approaches introduce the same or very similar security implications as generation PNDs, many of which do not have cryptography support and only
any middlebox operating on unencrypted traffic or having access to encryption: have limited computational capabilities. Hence, PND-based COIN systems
a middlebox can itself have malicious intentions, e.g., because it got compromis typically work on unencrypted data and often customize packet payload,
ed, or the deployment of functionality offers new attack vectors to outsiders.</ while concepts such as homomorphic encryption could serve as
t> workarounds, allowing PNDs to perform simple operations on the encrypted
data without having access to it. All these approaches introduce the
<t>However, similar to middlebox deployments, risks for privacy and of data expo same or very similar security implications as any middlebox operating on
sure have to be carefully considered in the context of the concrete deployment. unencrypted traffic or having access to encryption: a middlebox can
For example, exposing data to an external operator for mobile application offloa itself have malicious intentions (e.g., because it got compromised or
ding leads to a significant privacy loss of the user in any case. the deployment of functionality offers new attack vectors to
In contrast, such privacy considerations are not as relevant for COIN systems wh outsiders).</t>
ere all involved entities are under the same control, such as in an industrial c <t>However, similar to middlebox deployments, risks for privacy and the ri
ontext. sk of data
Here, exposed data and functionality can instead lead to stolen business secrets exposure have to be carefully considered in the context of the concrete
or the enabling of, e.g., DoS attacks. deployment. For example, exposing data to an external operator for
Hence, even in fully controlled scenarios, COIN intermediaries, and middleboxes mobile application offloading leads to a significant privacy loss of the
in general, are ideally operated in a least-privilege mode, where they have exac user in any case. In contrast, such privacy considerations are not as
tly those permissions to read and alter payload that are necessary to fulfil the relevant for COIN systems where all involved entities are under the same
ir purpose.</t> control, such as in an industrial context. Here, exposed data and
functionality can instead lead to stolen business secrets or the
<t>Research on granting middleboxes access to secured traffic is only in its inf enabling of DoS attacks, for example. Hence, even in fully controlled
ancy and a variety of different approaches are proposed and analyzed <xref targe scenarios, COIN intermediaries, and middleboxes in general, are ideally
t="TLSSURVEY"/>. operated in a least-privilege mode, where they have exactly those
In a SplitTLS <xref target="SPLITTLS"/> deployment, e.g., middleboxes have diffe permissions to read and alter payload that are necessary to fulfill their
rent incoming and outgoing TLS channels, such that they have full read and write purpose.</t>
access to all intercepted traffic. <t>Research on granting middleboxes access to secured traffic is only in
More restrictive approaches for deploying middleboxes rely on searchable encrypt its infancy, and a variety of different approaches are proposed and
ion or zero-knowledge proofs to expose less data to intermediaries, but those on analyzed <xref target="TLSSURVEY"/>. In a SplitTLS <xref
ly offer limited functionality. target="SPLITTLS"/> deployment, for example, middleboxes have different
MADTLS<xref target="MADTLS"/> is tailored to the industrial domain and offers bi incoming and outgoing TLS channels, such that they have full read and
t-level read and write access to intermediaries with low latency and bandwidth o write access to all intercepted traffic. More restrictive approaches
verhead, at the cost of more complex key management. for deploying middleboxes rely on searchable encryption or
Overall, different proposals offer different advantages and disadvantages that m zero-knowledge proofs to expose less data to intermediaries, but those
ust be carefully considered in the context of concrete deployments. only offer limited functionality. MADTLS <xref target="MADTLS"/> is
Further research could pave the way for a more unified and configurable solution tailored to the industrial domain and offers bit-level read and write
that is easier to maintain and deploy.</t> access to intermediaries with low latency and bandwidth overhead, at the
cost of more complex key management. Overall, different proposals offer
<t>Finally, COIN systems and other middlebox deployments can also lead to securi different advantages and disadvantages that must be carefully considered
ty risks even if the attack stems from an outsider without direct access to any in the context of concrete deployments. Further research could pave the
devices. way for a more unified and configurable solution that is easier to
As such, metadata about the entailed processing (processing times, changes in in maintain and deploy.</t>
coming and outgoing data) can allow an attacker to extract valuable information <t>Finally, COIN systems and other middlebox deployments can also lead
about the process. to security risks even if the attack stems from an outsider without
Moreover, such deployments can become central entities that, if paralyzed (e.g., direct access to any devices. As such, metadata about the entailed
through extensive requests), can be responsible for large-scale outages. processing (processing times or changes in incoming and outgoing data) can
In particular, some deployments could be used to amplify DoS attacks. allow an attacker to extract valuable information about the process.
Similar to other middlebox deployments, these potential risks must be considered Moreover, such deployments can become central entities that, if
when deploying COIN functionality and may influence the selection of suitable s paralyzed (e.g., through extensive requests), can be responsible for
ecurity protocols.</t> large-scale outages. In particular, some deployments could be used to
amplify DoS attacks. Similar to other middlebox deployments, these
<t>Additional system-level security considerations may arise from regulatory req potential risks must be considered when deploying COIN functionality and
uirements imposed on COIN systems overall, stemming from regulation regarding, e may influence the selection of suitable security protocols.</t>
.g., lawful interception, data localization, or AI use. <t>Additional system-level security considerations may arise from
These requirements may impact, e.g., the manner in which (COIN) programs may be regulatory requirements imposed on COIN systems overall, stemming from
placed or executed in the overall system, who can invoke certain (COIN) programs regulation regarding lawful interception, data localization, or
in what PND or COIN device, and what type of (COIN) program can be run. AI use, for example. These requirements may impact, for example, the mann
These considerations will impact the design of the possible implementing protoco er in which COIN
ls but also the policies that govern the execution of (COIN) programs.</t> 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
</section> COIN program can be run. These considerations will impact the design
<section anchor="iana-considerations"><name>IANA Considerations</name> of the possible implementing protocols but also the policies that govern
<t>N/A</t> the execution of COIN programs.</t>
</section>
</section>
<section anchor="conclusion"><name>Conclusion</name>
<t>This document presented use cases gathered from several application domains t
hat can and could profit from capabilities that are provided by in-network and,
more generally, distributed compute platforms.
We distinguished between use cases in which COIN may enable new experiences (<xr
ef target="newExperiences"/>), expose new features (<xref target="newCapabilitie
s"/>), or improve on existing system capabilities (<xref target="existingCapabil
ities"/>), and other use cases where COIN capabilities enable totally new applic
ations, for example, in industrial networking (<xref target="newEnvironments"/>)
.</t>
<t>Beyond the mere description and characterization of those use cases, we ident
ified opportunities arising from utilizing COIN capabilities and formulated corr
esponding 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 us
e cases and is thus only a snapshot of what may be possible if COIN capabilities
existed.<br />
In fact, the decomposition of many current client-server applications into node
by node transit could identify other opportunities for adding computing to forwa
rding notably in supply-chain, health care, intelligent cities and transportatio
n and even financial services (among others).
The presented use cases were selected based on the expertise of the contributing
community members at the time of writing and are intended to cover a diverse ra
nge from immersive and interactive media, industrial networks, to AI with varyin
g characteristics, thus, providing the basis for a thorough subsequent analysis.
</t>
</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>The authors would like to thank Eric Wagner for providing text on the securit <section anchor="iana-considerations">
y considerations and Jungha Hong for her efforts in continuing the work on the u <name>IANA Considerations</name>
se case analysis document that has largely sourced the preliminary categorizatio <t>This document has no IANA actions.</t>
n section of this document. </section>
The authors would further like to thank Chathura Sarathchandra, David Oran, Phil
Eardley, Stuart Card, Jeffrey He, Toerless Eckert, and Jon Crowcroft for review
ing earlier versions of the document, Colin Perkins for his IRTF chair review, a
nd Jerome Francois for his thorough IRSG review.</t>
</section> <section anchor="conclusion">
<name>Conclusion</name>
<t>This document presents use cases gathered from several application
domains that can and could profit from capabilities that are provided by
in-network and, more generally, distributed compute platforms. We
distinguish between use cases in which COIN may enable new experiences
(<xref target="newExperiences"/>), expose new features (<xref
target="newCapabilities"/>), or improve on existing system capabilities
(<xref target="existingCapabilities"/>), and other use cases where COIN
capabilities enable totally new applications, for example, in industrial
networking (<xref target="newEnvironments"/>).</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>
</middle> </middle>
<back> <back>
<displayreference target="I-D.trossen-icnrg-internet-icn-5glan" to="ICN-5GLA
N"/>
<displayreference target="I-D.sarathchandra-coin-appcentres" to="APPCENTRES"
/>
<displayreference target="I-D.irtf-coinrg-use-case-analysis" to="USE-CASE-AN
"/>
<displayreference target="I-D.hsingh-coinrg-reqs-p4comp" to="P4-SPLIT"/>
<displayreference target="I-D.ravi-icnrg-5gc-icn" to="ICN-5GC"/>
<references>
<name>Informative References</name>
<references title='Informative References'> <!-- [APPCENTRES] draft-sarathchandra-coin-appcentres-04
IESG State: Expired as of 08/11/25. -->
<reference anchor='APPCENTRES'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.sa
<front> rathchandra-coin-appcentres.xml"/>
<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 &#x27;Internet&#x27; 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&#x27;s applications in existing smartphones.
We outline the key enabling technologies that needs to be provided
for such evolution to be realized, including references to ongoing
standardization efforts in key areas.
</t> <reference anchor="TIRPITZ-REDUCIO">
</abstract> <front>
</front> <title>Reducio: Data Aggregation and Stability Detection for Industria
<seriesInfo name='Internet-Draft' value='draft-sarathchandra-coin-appcentres- l Processes Using In-Network Computing</title>
04'/> <author fullname="Liam Tirpitz" initials="L." surname="Tirpitz"></autho
r>
<author fullname="Ike Kunze" initials="I." surname="Kunze"></author>
<author fullname="Philipp Niemietz" initials="P." surname="Niemietz"><
/author>
<author fullname="Anna Kathrin Gerhardus" initials="A. K." surname="Ge
rhardus"></author>
<author fullname="Thomas Bergs" initials="T." surname="Bergs"></author
>
<author fullname="Klaus Wehrle" initials="K." surname="Wehrle"></autho
r>
<author fullname="Sandra Geisler" initials="S." surname="Geisler"></au
thor>
<date month="June" year="2025"/>
</front>
<refcontent>DEBS '25: Proceedings of the 19th ACM International Conferen
ce on Distributed and Event-based Systems, pp. 98-109</refcontent>
<seriesInfo name="DOI" value="10.1145/3701717.3730547"/>
</reference>
</reference> <reference anchor="RÜTH">
<front>
<title>Towards In-Network Industrial Feedback Control</title>
<author fullname="Jan Rüth" initials="J." surname="Rüth">
<organization>RWTH Aachen University</organization>
</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>
<reference anchor='RUETH'> <reference anchor="VESTIN">
<front> <front>
<title>Towards In-Network Industrial Feedback Control</title> <title>FastReact: In-Network Control and Caching for Industrial Contro
<author fullname='Jan Rueth' initials='J.' surname='Rueth'> l Networks using Programmable Data Planes</title>
<organization>RWTH Aachen University</organization> <author fullname="Jonathan Vestin" initials="J." surname="Vestin">
</author> <organization/>
<author fullname='Rene Glebke' initials='R.' surname='Glebke'> </author>
<organization>RWTH Aachen University</organization> <author fullname="Andreas Kassler" initials="A." surname="Kassler">
</author> <organization/>
<author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'> </author>
<organization>RWTH Aachen University</organization> <author fullname="Johan Akerberg" initials="J." surname="Akerberg">
</author> <organization/>
<author fullname='Vedad Causevic' initials='V.' surname='Causevic'> </author>
<organization>Technical University of Munich</organization> <date month="September" year="2018"/>
</author> </front>
<author fullname='Sandra Hirche' initials='S.' surname='Hirche'> <refcontent>2018 IEEE 23rd International Conference on Emerging Technolo
<organization>Technical University of Munich</organization> gies and Factory Automation (ETFA), pp. 219-226</refcontent>
</author> <seriesInfo name="DOI" value="10.1109/etfa.2018.8502456"/>
<date month='August' year='2018'/> </reference>
</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="GLEBKE">
<front> <front>
<title>FastReact: In-Network Control and Caching for Industrial Control Netw <title>A Case for Integrated Data Processing in Large-Scale Cyber-Phys
orks using Programmable Data Planes</title> ical Systems</title>
<author fullname='Jonathan Vestin' initials='J.' surname='Vestin'> <author fullname="Rene Glebke" initials="R." surname="Glebke">
<organization/> <organization/>
</author> </author>
<author fullname='Andreas Kassler' initials='A.' surname='Kassler'> <author fullname="Martin Henze" initials="M." surname="Henze">
<organization/> <organization/>
</author> </author>
<author fullname='Johan Akerberg' initials='J.' surname='Akerberg'> <author fullname="Klaus Wehrle" initials="K." surname="Wehrle">
<organization/> <organization/>
</author> </author>
<date month='September' year='2018'/> <author fullname="Philipp Niemietz" initials="P." surname="Niemietz">
</front> <organization/>
<seriesInfo name='2018 IEEE 23rd International Conference on Emerging Technolo </author>
gies and Factory Automation (ETFA)' value='pp. 219-226'/> <author fullname="Daniel Trauth" initials="D." surname="Trauth">
<seriesInfo name='DOI' value='10.1109/etfa.2018.8502456'/> <organization/>
</reference> </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>
<reference anchor='GLEBKE'> <!-- draft-irtf-coinrg-use-case-analysis-02
<front> IESG State: Expired as of 08/11/25.
<title>A Case for Integrated Data Processing in Large-Scale Cyber-Physical S -->
ystems</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ir
<author fullname='Rene Glebke' initials='R.' surname='Glebke'> tf-coinrg-use-case-analysis.xml"/>
<organization/>
</author>
<author fullname='Martin Henze' initials='M.' surname='Henze'>
<organization/>
</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 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="P4">
<front> <front>
<title>Use Case Analysis for Computing in the Network</title> <title>P4: programming protocol-independent packet processors</title>
<author fullname='Ike Kunze' initials='I.' surname='Kunze'> <author fullname="Pat Bosshart" initials="P." surname="Bosshart">
<organization>RWTH Aachen University</organization> <organization>Barefoot Networks, Palo Alto, CA, USA</organization>
</author> </author>
<author fullname='Jungha Hong' initials='J.' surname='Hong'> <author fullname="Dan Daly" initials="D." surname="Daly">
<organization>ETRI</organization> <organization>Intel, Ann Arbor, MI, USA</organization>
</author> </author>
<author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'> <author fullname="Glen Gibb" initials="G." surname="Gibb">
<organization>RWTH Aachen University</organization> <organization>Barefoot Networks, Palo Alto, CA, USA</organization>
</author> </author>
<author fullname='Dirk Trossen' initials='D.' surname='Trossen'> <author fullname="Martin Izzard" initials="M." surname="Izzard">
<organization>Huawei Technologies Duesseldorf GmbH</organization> <organization>Barefoot Networks, Palo Alto, CA, USA</organization>
</author> </author>
<author fullname='Marie-Jose Montpetit' initials='M.' surname='Montpetit'> <author fullname="Nick McKeown" initials="N." surname="McKeown">
<organization>Concordia University</organization> <organization>Stanford University, Stanford, CA, USA</organization>
</author> </author>
<author fullname='Xavier de Foy' initials='X.' surname='de Foy'> <author fullname="Jennifer Rexford" initials="J." surname="Rexford">
<organization>InterDigital Communications, LLC</organization> <organization>Princeton University, Princeton, NJ, USA</organization
</author> >
<author fullname='David Griffin' initials='D.' surname='Griffin'> </author>
<organization>University College London</organization> <author fullname="Cole Schlesinger" initials="C." surname="Schlesinger
</author> ">
<author fullname='Miguel Rio' initials='M.' surname='Rio'> <organization>Princeton University, Princeton, NJ, USA</organization
<organization>University College London</organization> >
</author> </author>
<date day='4' month='December' year='2024'/> <author fullname="Dan Talayco" initials="D." surname="Talayco">
<abstract> <organization>Barefoot Networks, Palo Alto, CA, USA</organization>
<t> Computing in the Network (COIN) has the potential to enable a wide </author>
variety of use cases. The diversity in use cases makes challenges in <author fullname="Amin Vahdat" initials="A." surname="Vahdat">
defining general considerations. This document analyzes the use <organization>Google, Mountain View, CA, USA</organization>
cases described in a COINRG companion document and potentially </author>
explores additional settings, to identify general aspects of interest <author fullname="George Varghese" initials="G." surname="Varghese">
across all use cases. The insights gained from this analysis will <organization>Microsoft Research, Mountain View, CA, USA</organizati
guide future COIN discussions. 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>
</t> <reference anchor="GRPC" target="https://grpc.io/">
</abstract> <front>
</front> <title>High performance, open source universal RPC framework</title>
<seriesInfo name='Internet-Draft' value='draft-irtf-coinrg-use-case-analysis- <author>
02'/> <organization/>
</author>
<date/>
</front>
</reference>
</reference> <reference anchor="MPI" target="https://arxiv.org/pdf/1603.02339.pdf">
<front>
<title>Scaling Distributed Machine Learning with In-Network Aggregatio
n</title>
<author initials="A." surname="Vishnu">
<organization/>
</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>
<reference anchor='P4'> <reference anchor="FCDN" target="https://arxiv.org/pdf/1803.00876.pdf">
<front> <front>
<title>P4: programming protocol-independent packet processors</title> <title>fCDN: A Flexible and Efficient CDN Infrastructure without DNS R
<author fullname='Pat Bosshart' initials='P.' surname='Bosshart'> edirection of Content Reflection</title>
<organization>Barefoot Networks, Palo Alto, CA, USA</organization> <author initials="M." surname="Al-Naday">
</author> <organization/>
<author fullname='Dan Daly' initials='D.' surname='Daly'> </author>
<organization>Intel, Ann Arbor, MI, USA</organization> <author initials="M. J." surname="Reed">
</author> <organization/>
<author fullname='Glen Gibb' initials='G.' surname='Gibb'> </author>
<organization>Barefoot Networks, Palo Alto, CA, USA</organization> <author initials="J." surname="Riihijarvi">
</author> <organization/>
<author fullname='Martin Izzard' initials='M.' surname='Izzard'> </author>
<organization>Barefoot Networks, Palo Alto, CA, USA</organization> <author initials="D." surname="Trossen">
</author> <organization/>
<author fullname='Nick McKeown' initials='N.' surname='McKeown'> </author>
<organization>Stanford University, Stanford, CA, USA</organization> <author initials="N." surname="Thomos">
</author> <organization/>
<author fullname='Jennifer Rexford' initials='J.' surname='Rexford'> </author>
<organization>Princeton University, Princeton, NJ, USA</organization> <author initials="M." surname="Al-Khalidi">
</author> <organization/>
<author fullname='Cole Schlesinger' initials='C.' surname='Schlesinger'> </author>
<organization>Princeton University, Princeton, NJ, USA</organization> <date/>
</author> </front>
<author fullname='Dan Talayco' initials='D.' surname='Talayco'> <refcontent>arXiv:1803.00876v2</refcontent>
<organization>Barefoot Networks, Palo Alto, CA, USA</organization> </reference>
</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</organization>
</author>
<author fullname='David Walker' initials='D.' surname='Walker'>
<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/"> <!-- [I-D.ravi-icnrg-5gc-icn]
<front> draft-ravi-icnrg-5gc-icn-04
<title>High performance open source universal RPC framework</title> IESG State: Replaced by draft-irtf-icnrg-5gc-icn / Expired as of 08/11/25)
<author > -->
<organization></organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ra
</author> vi-icnrg-5gc-icn.xml"/>
<date />
</front>
</reference>
<reference anchor="MPI" target="https://arxiv.org/pdf/1603.02339.pdf">
<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'> <!-- [I-D.hsingh-coinrg-reqs-p4comp]
<front> draft-hsingh-coinrg-reqs-p4comp-03
<title>Enabling ICN in 3GPP&#x27;s 5G NextGen Core Architecture</title> IESG State: Expired as of 08/11/25.
<author fullname='Ravi Ravindran' initials='R.' surname='Ravindran'> -->
<organization>Futurewei Technologies</organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.hs
</author> ingh-coinrg-reqs-p4comp.xml"/>
<author fullname='Prakash Suthar' initials='P.' surname='Suthar'>
<organization>Cisco Systems</organization>
</author>
<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&#x27;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&#x27;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> <reference anchor="Stoyanov" target="https://dl.acm.org/doi/10.1145/342674
</abstract> 4.3431329">
</front> <front>
<seriesInfo name='Internet-Draft' value='draft-ravi-icnrg-5gc-icn-04'/> <title>MTPSA: Multi-Tenant Programmable Switches</title>
<author initials="R." surname="Stoyanov">
<organization/>
</author>
<author initials="N." surname="Zilberman">
<organization/>
</author>
<date month="December" year="2020"/>
</front>
<seriesInfo name="DOI" value="10.1145/3426744.3431329"/>
<refcontent>Proceedings of the 3rd P4 Workshop in Europe, pp. 43-48</ref
content>
</reference>
</reference> <reference anchor="TS23.501" target="https://www.3gpp.org/DynaReport/23501
.htm">
<front>
<title>System Architecture for the 5G System; Stage 2 (Rel.17)</title>
<author>
<organization>3GPP</organization>
</author>
<date year="2021"/>
</front>
<seriesInfo name="3GPP" value="TS 23.501"/>
</reference>
<reference anchor='I-D.hsingh-coinrg-reqs-p4comp'> <reference anchor="TS23.502" target="https://www.3gpp.org/DynaReport/23502
<front> .htm">
<title>Requirements for P4 Program Splitting for Heterogeneous Network Nod <front>
es</title> <title>Procedures for the 5G System; Stage 2 (Rel.17)</title>
<author fullname='Hemant Singh' initials='H.' surname='Singh'> <author>
<organization>MNK Labs and Consulting</organization> <organization>3GPP</organization>
</author> </author>
<author fullname='Marie-Jose Montpetit' initials='M.' surname='Montpetit'> <date year="2021"/>
<organization>Concordia Univeristy</organization> </front>
</author> <seriesInfo name="3GPP" value="TS 23.502"/>
<date day='18' month='February' year='2021'/> </reference>
<abstract>
<t> For distributed computing, the P4 research community has published
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> <reference anchor="SA2-5GLAN" target="https://www.3gpp.org/ftp/tsg_sa/TSG_
</abstract> SA/TSGS_82/Docs/SP-181120.zip">
</front> <front>
<seriesInfo name='Internet-Draft' value='draft-hsingh-coinrg-reqs-p4comp-03'/ <title>SP-181129, Work Item Description, Vertical_LAN(SA2), 5GS Enhanc
> ed Support of Vertical and LAN Services</title>
<author initials="" surname="3GPP-5glan" fullname="3GPP-5glan">
<organization/>
</author>
<date year="2021"/>
</front>
<seriesInfo name="3GPP" value=""/>
</reference>
</reference> <!-- [ID.trossen-icnrg-internet-icn-5glan-04]
IESG State: Expired as of 08/11/25) -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.trossen
-icnrg-internet-icn-5glan.xml"/>
<reference anchor="Stoyanov" target="https://eng.ox.ac.uk/media/6354/stoyanov202 <reference anchor="Sultana" target="https://flightplan.cis.upenn.edu/fligh
0mtpsa.pdf"> tplan.pdf">
<front> <front>
<title>MTPSA: Multi-Tenant Programmable Switches</title> <title>Flightplan: Dataplane Disaggregation and Placement for P4 Progr
<author initials="R." surname="Stoyanov"> ams</title>
<organization></organization> <author initials="N." surname="Sultana">
</author> <organization/>
<author initials="N." surname="Zilberman"> </author>
<organization></organization> <author initials="J." surname="Sonchack">
</author> <organization/>
<date year="2020"/> </author>
</front> <author initials="H." surname="Giesen">
<seriesInfo name="ACM P4 Workshop in Europe (EuroP4'20)" value=""/> <organization/>
</reference> </author>
<reference anchor="TS23.501" target="https://www.3gpp.org/DynaReport/23501.htm"> <author initials="I." surname="Pedisich">
<front> <organization/>
<title>Technical Specification Group Services and System Aspects; System Arc </author>
hitecture for the 5G System; Stage 2 (Rel.17)</title> <author initials="Z." surname="Han">
<author initials="" surname="3gpp-23.501" fullname="3gpp-23.501"> <organization/>
<organization></organization> </author>
</author> <author initials="N." surname="Shyamkumar">
<date year="2021"/> <organization/>
</front> </author>
<seriesInfo name="3GPP" value=""/> <author initials="S." surname="Burad">
</reference> <organization/>
<reference anchor="TS23.502" target="https://www.3gpp.org/DynaReport/23502.htm"> </author>
<front> <author initials="A." surname="DeHon">
<title>Technical Specification Group Services and System Aspects; Procedures <organization/>
for the 5G System; Stage 2 (Rel.17)</title> </author>
<author initials="" surname="3gpp-23.502" fullname="3gpp-23.502"> <author initials="B. T." surname="Loo">
<organization></organization> <organization/>
</author> </author>
<date year="2021"/> </front>
</front> </reference>
<seriesInfo name="3GPP" value=""/>
</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'> <reference anchor="ETSI" target="https://www.etsi.org/technologies/multi-a
<front> ccess-edge-computing">
<title>IP-based Services over ICN in 5G LAN Environments</title> <front>
<author fullname='Dirk Trossen' initials='D.' surname='Trossen'> <title>Multi-access Edge Computing (MEC)</title>
<organization>InterDigital Inc.</organization> <author initials="" surname="ETSI" fullname="ETSI">
</author> <organization/>
<author fullname='Chonggang Wang' initials='C.' surname='Wang'> </author>
<organization>InterDigital Inc.</organization> </front>
</author> </reference>
<author fullname='Sebastian Robitzsch' initials='S.' surname='Robitzsch'>
<organization>InterDigital Inc.</organization>
</author>
<author fullname='Martin Reed' initials='M.' surname='Reed'>
<organization>Essex University</organization>
</author>
<author fullname='Mays AL-Naday' initials='M.' surname='AL-Naday'>
<organization>Essex University</organization>
</author>
<author fullname='Janne Riihijarvi' initials='J.' surname='Riihijarvi'>
<organization>RWTH Aachen</organization>
</author>
<date day='6' month='June' year='2019'/>
<abstract>
<t> In this draft, we provide architecture and operations for enabling
IP
services over ICN over (5G-enabled) LAN environments. Operations
include ICN API to upper layers, HTTP over ICN, Service Proxy
Operations, ICN Flow Management, Name Resolution, Mobility Handling,
and Dual Stack Device Support.
</t> <reference anchor="Microservices" target="https://microservices.io/">
</abstract> <front>
</front> <title>What are microservices?</title>
<seriesInfo name='Internet-Draft' value='draft-trossen-icnrg-ip-icn-5glan-00' <author initials="C." surname="Richardson">
/> <organization/>
</author>
</front>
</reference>
</reference> <reference anchor="GSLB" target="https://www.cloudflare.com/learning/cdn/g
lossary/global-server-load-balancing-gslb/">
<front>
<title>What is global server load balancing (GSLB)?</title>
<author>
<organization>Cloudflare</organization>
</author>
</front>
</reference>
<reference anchor="Sultana" target="https://flightplan.cis.upenn.edu/flightplan. <reference anchor="L2Virt" target="https://blogs.oracle.com/cloud-infrastr
pdf"> ucture/post/first-principles-l2-network-virtualization-for-lift-and-shift">
<front> <front>
<title>Flightplan: Dataplane Disaggregation and Placement for P4 Programs</t <title>First principles: L2 network virtualization for lift and shift<
itle> /title>
<author initials="N." surname="Sultana"> <author initials="L." surname="Kreger-Stickles">
<organization></organization> <organization/>
</author> </author>
<author initials="J." surname="Sonchack"> <date day="9" month="February" year="2021"/>
<organization></organization> </front>
</author> <refcontent>Oracle Cloud Infrastructure Blog</refcontent>
<author initials="H." surname="Giesen"> </reference>
<organization></organization>
</author>
<author initials="I." surname="Pedisich">
<organization></organization>
</author>
<author initials="Z." surname="Han">
<organization></organization>
</author>
<author initials="N." surname="Shyamkumar">
<organization></organization>
</author>
<author initials="S." surname="Burad">
<organization></organization>
</author>
<author initials="A." surname="DeHon">
<organization></organization>
</author>
<author initials="B. T." surname="Loo">
<organization></organization>
</author>
<date year="2020"/>
</front>
</reference>
<reference anchor="ETSI" target="https://www.etsi.org/technologies/multi-access-
edge-computing">
<front>
<title>Multi-access Edge Computing (MEC)</title>
<author initials="" surname="ETSI" fullname="ETSI">
<organization></organization>
</author>
<date year="2022"/>
</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'> <reference anchor="TOSCA" target="https://docs.oasis-open.org/tosca/TOSCA-
<front> Simple-Profile-YAML/v1.3/os/TOSCA-Simple-Profile-YAML-v1.3-os.pdf">
<title>Investigating the Applicability of In-Network Computing to Industrial <front>
Scenarios</title> <title>TOSCA Simple Profile in YAML Version 1.3</title>
<author fullname='Ike Kunze' initials='I.' surname='Kunze'> <author fullname="Matt Rutkowski" role="editor"/>
<organization/> <author fullname="Chris Lauwers" role="editor"/>
</author> <author fullname="Claude Noshpitz" role="editor"/>
<author fullname='Rene Glebke' initials='R.' surname='Glebke'> <author fullname="Calin Curescu" role="editor"/>
<organization/> <date month="February" year="2020"/>
</author> </front>
<author fullname='Jan Scheiper' initials='J.' surname='Scheiper'> <refcontent>OASIS Standard</refcontent>
<organization/> </reference>
</author>
<author fullname='Matthias Bodenbenner' initials='M.' surname='Bodenbenner'>
<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>
<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'> <reference anchor="FLOWER" target="https://flower.ai/">
<front> <front>
<title>Detecting Out-Of-Control Sensor Signals in Sheet Metal Forming using <title>A Friendly Federated AI Framework</title>
In-Network Computing</title> <author initials="" surname="Flower Labs GmbH">
<author fullname='Ike Kunze' initials='I.' surname='Kunze'> <organization/>
<organization>Communication and Distributed Systems</organization> </author>
</author> </front>
<author fullname='Philipp Niemietz' initials='P.' surname='Niemietz'> </reference>
<organization>Laboratory for Machine Tools and Production Engineering (WZL
)</organization>
</author>
<author fullname='Liam Tirpitz' initials='L.' surname='Tirpitz'>
<organization>Communication and Distributed Systems</organization>
</author>
<author fullname='Rene Glebke' initials='R.' surname='Glebke'>
<organization>Communication and Distributed Systems</organization>
</author>
<author fullname='Daniel Trauth' initials='D.' surname='Trauth'>
<organization>Laboratory for Machine Tools and Production Engineering (WZL
)</organization>
</author>
<author fullname='Thomas Bergs' initials='T.' surname='Bergs'>
<organization>Laboratory for Machine Tools and Production Engineering (WZL
)</organization>
</author>
<author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'>
<organization>Communication and Distributed Systems</organization>
</author>
<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'> <reference anchor="KUNZE-APPLICABILITY">
<front> <front>
<title>Service-based Forwarding via Programmable Dataplanes</title> <title>Investigating the Applicability of In-Network Computing to Indu
<author fullname='Rene Glebke' initials='R.' surname='Glebke'> strial Scenarios</title>
<organization/> <author fullname="Ike Kunze" initials="I." surname="Kunze">
</author> <organization/>
<author fullname='Dirk Trossen' initials='D.' surname='Trossen'> </author>
<organization/> <author fullname="Rene Glebke" initials="R." surname="Glebke">
</author> <organization/>
<author fullname='Ike Kunze' initials='I.' surname='Kunze'> </author>
<organization/> <author fullname="Jan Scheiper" initials="J." surname="Scheiper">
</author> <organization/>
<author fullname='David Lou' initials='D.' surname='Lou'> </author>
<organization/> <author fullname="Matthias Bodenbenner" initials="M." surname="Bodenbe
</author> nner">
<author fullname='Jan Rueth' initials='J.' surname='Rueth'> <organization/>
<organization/> </author>
</author> <author fullname="Robert H. Schmitt" initials="R." surname="Schmitt">
<author fullname='Mirko Stoffers' initials='M.' surname='Stoffers'> <organization/>
<organization/> </author>
</author> <author fullname="Klaus Wehrle" initials="K." surname="Wehrle">
<author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'> <organization/>
<organization/> </author>
</author> <date month="May" year="2021"/>
<date month='June' year='2021'/> </front>
</front> <refcontent>2021 4th IEEE International Conference on Industrial Cyber-P
<seriesInfo name='2021 IEEE 22nd International Conference on High Performance hysical Systems (ICPS), pp. 334-340</refcontent>
Switching and Routing (HPSR)' value='pp. 1-8'/> <seriesInfo name="DOI" value="10.1109/icps49255.2021.9468247"/>
<seriesInfo name='DOI' value='10.1109/hpsr52026.2021.9481814'/> </reference>
</reference>
<reference anchor='Multi2020'> <reference anchor="KUNZE-SIGNAL">
<front> <front>
<title>Routing on Multiple Optimality Criteria</title> <title>Detecting Out-Of-Control Sensor Signals in Sheet Metal Forming
<author fullname='João Luís Sobrinho' initials='J.' surname='Sobrinho'> using In-Network Computing</title>
<organization>Instituto de Telecomunicações, Instituto Superior Tecnico, U <author fullname="Ike Kunze" initials="I." surname="Kunze">
niversidade de Lisboa</organization> <organization>Communication and Distributed Systems</organization>
</author> </author>
<author fullname='Miguel Alves Ferreira' initials='M.' surname='Ferreira'> <author fullname="Philipp Niemietz" initials="P." surname="Niemietz">
<organization>Instituto de Telecomunicações, Instituto Superior Tecnico, U <organization>Laboratory for Machine Tools and Production Engineerin
niversidade de Lisboa</organization> g (WZL)</organization>
</author> </author>
<date month='July' year='2020'/> <author fullname="Liam Tirpitz" initials="L." surname="Tirpitz">
</front> <organization>Communication and Distributed Systems</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="Rene Glebke" initials="R." surname="Glebke">
s, and protocols for computer communication' value='pp. 211-225'/> <organization>Communication and Distributed Systems</organization>
<seriesInfo name='DOI' value='10.1145/3387514.3405864'/> </author>
</reference> <author fullname="Daniel Trauth" initials="D." surname="Trauth">
<organization>Laboratory for Machine Tools and Production Engineerin
g (WZL)</organization>
</author>
<author fullname="Thomas Bergs" initials="T." surname="Bergs">
<organization>Laboratory for Machine Tools and Production Engineerin
g (WZL)</organization>
</author>
<author fullname="Klaus Wehrle" initials="K." surname="Wehrle">
<organization>Communication and Distributed Systems</organization>
</author>
<date month="June" year="2021"/>
</front>
<refcontent>2021 IEEE 30th International Symposium on Industrial Electro
nics (ISIE), pp. 1-6</refcontent>
<seriesInfo name="DOI" value="10.1109/isie45552.2021.9576221"/>
</reference>
<reference anchor='SILKROAD'> <reference anchor="SarNet2021">
<front> <front>
<title>SilkRoad: Making Stateful Layer-4 Load Balancing Fast and Cheap Using <title>Service-based Forwarding via Programmable Dataplanes</title>
Switching ASICs</title> <author fullname="Rene Glebke" initials="R." surname="Glebke">
<author fullname='Rui Miao' initials='R.' surname='Miao'> <organization/>
<organization>University of Southern California</organization> </author>
</author> <author fullname="Dirk Trossen" initials="D." surname="Trossen">
<author fullname='Hongyi Zeng' initials='H.' surname='Zeng'> <organization/>
<organization>Facebook</organization> </author>
</author> <author fullname="Ike Kunze" initials="I." surname="Kunze">
<author fullname='Changhoon Kim' initials='C.' surname='Kim'> <organization/>
<organization>Barefoot Networks</organization> </author>
</author> <author fullname="David Lou" initials="D." surname="Lou">
<author fullname='Jeongkeun Lee' initials='J.' surname='Lee'> <organization/>
<organization>Barefoot Networks</organization> </author>
</author> <author fullname="Jan Ruth" initials="J." surname="Ruth">
<author fullname='Minlan Yu' initials='M.' surname='Yu'> <organization/>
<organization>Yale University</organization> </author>
</author> <author fullname="Mirko Stoffers" initials="M." surname="Stoffers">
<date month='August' year='2017'/> <organization/>
</front> </author>
<seriesInfo name='Proceedings of the Conference of the ACM Special Interest Gr <author fullname="Klaus Wehrle" initials="K." surname="Wehrle">
oup on Data Communication' value='pp. 15-28'/> <organization/>
<seriesInfo name='DOI' value='10.1145/3098822.3098824'/> </author>
</reference> <date month="June" year="2021"/>
</front>
<refcontent>2021 IEEE 22nd International Conference on High Performance
Switching and Routing (HPSR), pp. 1-8</refcontent>
<seriesInfo name="DOI" value="10.1109/hpsr52026.2021.9481814"/>
</reference>
<reference anchor='GREENAI'> <reference anchor="Multi2020">
<front> <front>
<title>A Safe Genetic Algorithm Approach for Energy Efficient Federated Lear <title>Routing on Multiple Optimality Criteria</title>
ning in Wireless Communication Networks</title> <author fullname="João Luís Sobrinho" initials="J." surname="Sobrinho"
<author fullname='Lina Magoula' initials='L.' surname='Magoula'> >
<organization>National and Kapodistrian University of Athens,Dept. of Info <organization>Instituto de Telecomunicações, Instituto Superior Tecn
rmatics and Telecommunications,Greece</organization> ico, Universidade de Lisboa</organization>
</author> </author>
<author fullname='Nikolaos Koursioumpas' initials='N.' surname='Koursioumpas <author fullname="Miguel Alves Ferreira" initials="M." surname="Ferrei
'> ra">
<organization>National and Kapodistrian University of Athens,Dept. of Info <organization>Instituto de Telecomunicações, Instituto Superior Tecn
rmatics and Telecommunications,Greece</organization> ico, Universidade de Lisboa</organization>
</author> </author>
<author fullname='Alexandros-Ioannis Thanopoulos' initials='A.' surname='Tha <date month="July" year="2020"/>
nopoulos'> </front>
<organization>National and Kapodistrian University of Athens,Dept. of Info <refcontent>Proceedings of the Annual conference of the ACM Special Inte
rmatics and Telecommunications,Greece</organization> rest Group on Data Communication on the applications, technologies, architecture
</author> s, and protocols for computer communication, pp. 211-225</refcontent>
<author fullname='Theodora Panagea' initials='T.' surname='Panagea'> <seriesInfo name="DOI" value="10.1145/3387514.3405864"/>
<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'> <reference anchor="SILKROAD">
<front> <front>
<title>A Survey and Analysis of TLS Interception Mechanisms and Motivations: <title>SilkRoad: Making Stateful Layer-4 Load Balancing Fast and Cheap
Exploring how end-to-end TLS is made "end-to-me" for web traffic</title> Using Switching ASICs</title>
<author fullname='Xavier de Carne de Carnavalet' initials='X.' surname='de C <author fullname="Rui Miao" initials="R." surname="Miao">
arne de Carnavalet'> <organization>University of Southern California</organization>
<organization>The Hong Kong Polytechnic University, Hong Kong SAR</organiz </author>
ation> <author fullname="Hongyi Zeng" initials="H." surname="Zeng">
</author> <organization>Facebook</organization>
<author fullname='Paul C. van Oorschot' initials='P.' surname='van Oorschot' </author>
> <author fullname="Changhoon Kim" initials="C." surname="Kim">
<organization>Carleton University, Ontario, Canada</organization> <organization>Barefoot Networks</organization>
</author> </author>
<date month='July' year='2023'/> <author fullname="Jeongkeun Lee" initials="J." surname="Lee">
</front> <organization>Barefoot Networks</organization>
<seriesInfo name='ACM Computing Surveys' value='vol. 55, no. 13s, pp. 1-40'/> </author>
<seriesInfo name='DOI' value='10.1145/3580522'/> <author fullname="Minlan Yu" initials="M." surname="Yu">
</reference> <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='MADTLS'> <reference anchor="GREENAI">
<front> <front>
<title>Madtls: Fine-grained Middlebox-aware End-to-end Security for Industri <title>A Safe Genetic Algorithm Approach for Energy Efficient Federate
al Communication</title> d Learning in Wireless Communication Networks</title>
<author fullname='Eric Wagner' initials='E.' surname='Wagner'> <author fullname="Lina Magoula" initials="L." surname="Magoula">
<organization/> <organization>National and Kapodistrian University of Athens,Dept. o
</author> f Informatics and Telecommunications,Greece</organization>
<author fullname='David Heye' initials='D.' surname='Heye'> </author>
<organization/> <author fullname="Nikolaos Koursioumpas" initials="N." surname="Koursi
</author> oumpas">
<author fullname='Martin Serror' initials='M.' surname='Serror'> <organization>National and Kapodistrian University of Athens,Dept. o
<organization/> f Informatics and Telecommunications,Greece</organization>
</author> </author>
<author fullname='Ike Kunze' initials='I.' surname='Kunze'> <author fullname="Alexandros-Ioannis Thanopoulos" initials="A." surnam
<organization/> e="Thanopoulos">
</author> <organization>National and Kapodistrian University of Athens,Dept. o
<author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'> f Informatics and Telecommunications,Greece</organization>
<organization/> </author>
</author> <author fullname="Theodora Panagea" initials="T." surname="Panagea">
<author fullname='Martin Henze' initials='M.' surname='Henze'> <organization>National and Kapodistrian University of Athens,Dept. o
<organization/> f Informatics and Telecommunications,Greece</organization>
</author> </author>
<date year='2023'/> <author fullname="Nikolaos Petropouleas" initials="N." surname="Petrop
</front> ouleas">
<seriesInfo name='' value='arXiv'/> <organization>National and Kapodistrian University of Athens,Dept. o
<seriesInfo name='DOI' value='10.48550/ARXIV.2312.09650'/> f Informatics and Telecommunications,Greece</organization>
</reference> </author>
<author fullname="M. A. Gutierrez-Estevez" initials="M." surname="Guti
errez-Estevez">
<organization>Huawei Technologies Duesseldorf GmbH,Munich Research C
enter,Munich,Germany</organization>
</author>
<author fullname="Ramin Khalili" initials="R." surname="Khalili">
<organization>Huawei Technologies Duesseldorf GmbH,Munich Research C
enter,Munich,Germany</organization>
</author>
<date month="September" year="2023"/>
</front>
<refcontent>2023 IEEE 34th Annual International Symposium on Personal, I
ndoor and Mobile Radio Communications (PIMRC), pp. 1-6</refcontent>
<seriesInfo name="DOI" value="10.1109/pimrc56721.2023.10293863"/>
</reference>
<reference anchor='SPLITTLS'> <reference anchor="TLSSURVEY">
<front> <front>
<title>Multi-Context TLS (mcTLS): Enabling Secure In-Network Functionality i <title>A Survey and Analysis of TLS Interception Mechanisms and Motiva
n TLS</title> tions: Exploring how end-to-end TLS is made 'end-to-me' for web traffic</title>
<author fullname='David Naylor' initials='D.' surname='Naylor'> <author fullname="Xavier de Carné de Carnavalet" initials="X." surname
<organization>Carnegie Mellon University, Pittsburgh, PA, USA</organizatio ="de Carné de Carnavalet">
n> <organization>The Hong Kong Polytechnic University, Hong Kong SAR</o
</author> rganization>
<author fullname='Kyle Schomp' initials='K.' surname='Schomp'> </author>
<organization>Case Western Reserve University, Cleveland, OH, USA</organiz <author fullname="Paul C. van Oorschot" initials="P." surname="van Oor
ation> schot">
</author> <organization>Carleton University, Ontario, Canada</organization>
<author fullname='Matteo Varvello' initials='M.' surname='Varvello'> </author>
<organization>Telefonica Research, Barcelona, Spain</organization> <date month="July" year="2023"/>
</author> </front>
<author fullname='Ilias Leontiadis' initials='I.' surname='Leontiadis'> <refcontent>ACM Computing Surveys, vol. 55, no. 13s, pp. 1-40</refconten
<organization>Telefonica Research, Barcelona, Spain</organization> t>
</author> <seriesInfo name="DOI" value="10.1145/3580522"/>
<author fullname='Jeremy Blackburn' initials='J.' surname='Blackburn'> </reference>
<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'> <reference anchor="MADTLS">
<front> <front>
<title>Challenges in the Decentralised Web: The Mastodon Case</title> <title>Madtls: Fine-grained Middlebox-aware End-to-end Security for In
<author fullname='Aravindh Raman' initials='A.' surname='Raman'> dustrial Communication</title>
<organization>King's College London</organization> <author fullname="Eric Wagner" initials="E." surname="Wagner">
</author> <organization/>
<author fullname='Sagar Joglekar' initials='S.' surname='Joglekar'> </author>
<organization>King's College London</organization> <author fullname="David Heye" initials="D." surname="Heye">
</author> <organization/>
<author fullname='Emiliano De Cristofaro' initials='E.' surname='Cristofaro' </author>
> <author fullname="Martin Serror" initials="M." surname="Serror">
<organization>University College London</organization> <organization/>
</author> </author>
<author fullname='Nishanth Sastry' initials='N.' surname='Sastry'> <author fullname="Ike Kunze" initials="I." surname="Kunze">
<organization>King's College London</organization> <organization/>
</author> </author>
<author fullname='Gareth Tyson' initials='G.' surname='Tyson'> <author fullname="Klaus Wehrle" initials="K." surname="Wehrle">
<organization>Queen Mary University of London</organization> <organization/>
</author> </author>
<date month='October' year='2019'/> <author fullname="Martin Henze" initials="M." surname="Henze">
</front> <organization/>
<seriesInfo name='Proceedings of the Internet Measurement Conference' value='p </author>
p. 217-229'/> <date year="2023"/>
<seriesInfo name='DOI' value='10.1145/3355369.3355572'/> </front>
</reference> <seriesInfo name="DOI" value="10.48550/ARXIV.2312.09650"/>
<refcontent>arXiv:2312.09650</refcontent>
</reference>
<reference anchor='eCAR'> <reference anchor="SPLITTLS">
<front> <front>
<title>eCAR: edge-assisted Collaborative Augmented Reality Framework</title> <title>Multi-Context TLS (mcTLS): Enabling Secure In-Network Functiona
<author fullname='Jinwoo Jeon' initials='J.' surname='Jeon'> lity in TLS</title>
<organization/> <author fullname="David Naylor" initials="D." surname="Naylor">
</author> <organization>Carnegie Mellon University, Pittsburgh, PA, USA</organ
<author fullname='Woontack Woo' initials='W.' surname='Woo'> ization>
<organization/> </author>
</author> <author fullname="Kyle Schomp" initials="K." surname="Schomp">
<date year='2024'/> <organization>Case Western Reserve University, Cleveland, OH, USA</o
</front> rganization>
<seriesInfo name='arXiv' value='article'/> </author>
<seriesInfo name='DOI' value='10.48550/ARXIV.2405.06872'/> <author fullname="Matteo Varvello" initials="M." surname="Varvello">
</reference> <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="Pap
agiannaki">
<organization>Telefonica Research, Barcelona, Spain</organization>
</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='NetworkedVR'> <reference anchor="MASTODON">
<front> <front>
<title>Networked VR: State of the Art, Solutions, and Challenges</title> <title>Challenges in the Decentralised Web: The Mastodon Case</title>
<author fullname='Jinjia Ruan' initials='J.' surname='Ruan'> <author fullname="Aravindh Raman" initials="A." surname="Raman">
<organization>State Key Laboratory of Networking and Switching Technology, <organization>King's College London</organization>
Beijing University of Posts and Telecommunications, Beijing 100876, China</orga </author>
nization> <author fullname="Sagar Joglekar" initials="S." surname="Joglekar">
</author> <organization>King's College London</organization>
<author fullname='Dongliang Xie' initials='D.' surname='Xie'> </author>
<organization>State Key Laboratory of Networking and Switching Technology, <author fullname="Emiliano De Cristofaro" initials="E." surname="Crist
Beijing University of Posts and Telecommunications, Beijing 100876, China</orga ofaro">
nization> <organization>University College London</organization>
</author> </author>
<date month='January' year='2021'/> <author fullname="Nishanth Sastry" initials="N." surname="Sastry">
</front> <organization>King's College London</organization>
<seriesInfo name='Electronics' value='vol. 10, no. 2, pp. 166'/> </author>
<seriesInfo name='DOI' value='10.3390/electronics10020166'/> <author fullname="Gareth Tyson" initials="G." surname="Tyson">
</reference> <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='CompNet2021'> <reference anchor="eCAR">
<front> <front>
<title>Edge intelligence computing for mobile augmented reality with deep re <title>eCAR: edge-assisted Collaborative Augmented Reality Framework</
inforcement learning approach</title> title>
<author fullname='Miaojiang Chen' initials='M.' surname='Chen'> <author fullname="Jinwoo Jeon" initials="J." surname="Jeon">
<organization/> <organization/>
</author> </author>
<author fullname='Wei Liu' initials='W.' surname='Liu'> <author fullname="Woontack Woo" initials="W." surname="Woo">
<organization/> <organization/>
</author> </author>
<author fullname='Tian Wang' initials='T.' surname='Wang'> <date year="2024"/>
<organization/> </front>
</author> <refcontent>arXiv:2405.06872</refcontent>
<author fullname='Anfeng Liu' initials='A.' surname='Liu'> <seriesInfo name="DOI" value="10.48550/ARXIV.2405.06872"/>
<organization/> </reference>
</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'> <reference anchor="NetworkedVR">
<front> <front>
<title>Online delay optimization for MEC and RIS-assisted wireless VR networ <title>Networked VR: State of the Art, Solutions, and Challenges</titl
ks</title> e>
<author fullname='Jie Jia' initials='J.' surname='Jia'> <author fullname="Jinjia Ruan" initials="J." surname="Ruan">
<organization/> <organization>State Key Laboratory of Networking and Switching Techn
</author> ology, Beijing University of Posts and Telecommunications, Beijing 100876, China
<author fullname='Leyou Yang' initials='L.' surname='Yang'> </organization>
<organization/> </author>
</author> <author fullname="Dongliang Xie" initials="D." surname="Xie">
<author fullname='Jian Chen' initials='J.' surname='Chen'> <organization>State Key Laboratory of Networking and Switching Techn
<organization/> ology, Beijing University of Posts and Telecommunications, Beijing 100876, China
</author> </organization>
<author fullname='Lidao Ma' initials='L.' surname='Ma'> </author>
<organization/> <date month="January" year="2021"/>
</author> </front>
<author fullname='Xingwei Wang' initials='X.' surname='Wang'> <refcontent>Electronics, vol. 10, no. 2, p. 166</refcontent>
<organization/> <seriesInfo name="DOI" value="10.3390/electronics10020166"/>
</author> </reference>
<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'> <reference anchor="CompNet2021">
<front> <front>
<title>Inter-Destination Media Synchronization (IDMS) Using the RTP Control <title>Edge intelligence computing for mobile augmented reality with d
Protocol (RTCP)</title> eep reinforcement learning approach</title>
<author fullname='R. van Brandenburg' initials='R.' surname='van Brandenburg <author fullname="Miaojiang Chen" initials="M." surname="Chen">
'/> <organization/>
<author fullname='H. Stokking' initials='H.' surname='Stokking'/> </author>
<author fullname='O. van Deventer' initials='O.' surname='van Deventer'/> <author fullname="Wei Liu" initials="W." surname="Liu">
<author fullname='F. Boronat' initials='F.' surname='Boronat'/> <organization/>
<author fullname='M. Montagud' initials='M.' surname='Montagud'/> </author>
<author fullname='K. Gross' initials='K.' surname='Gross'/> <author fullname="Tian Wang" initials="T." surname="Wang">
<date month='June' year='2014'/> <organization/>
<abstract> </author>
<t>This document defines a new RTP Control Protocol (RTCP) Packet Type and <author fullname="Anfeng Liu" initials="A." surname="Liu">
an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destinat <organization/>
ion Media Synchronization (IDMS). IDMS is the process of synchronizing playout a </author>
cross multiple media receivers. Using the RTCP XR IDMS Report Block defined in t <author fullname="Zhiwen Zeng" initials="Z." surname="Zeng">
his document, media playout information from participants in a synchronization g <organization/>
roup can be collected. Based on the collected information, an RTCP IDMS Settings </author>
Packet can then be sent to distribute a common target playout point to which al <date month="August" year="2021"/>
l the distributed receivers, sharing a media experience, can synchronize.</t> </front>
<t>Typical use cases in which IDMS is useful are social TV, shared service <seriesInfo name="DOI" value="10.1016/j.comnet.2021.108186"/>
control (i.e., applications where two or more geographically separated users ar <refcontent>Computer Networks, vol. 195, p. 108186</refcontent>
e watching a media stream together), distance learning, networked video walls, n </reference>
etworked loudspeakers, etc.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='7272'/>
<seriesInfo name='DOI' value='10.17487/RFC7272'/>
</reference>
<reference anchor='RFC8039'> <reference anchor="WirelessNet2024">
<front> <front>
<title>Multipath Time Synchronization</title> <title>Online delay optimization for MEC and RIS-assisted wireless VR
<author fullname='A. Shpiner' initials='A.' surname='Shpiner'/> networks</title>
<author fullname='R. Tse' initials='R.' surname='Tse'/> <author fullname="Jie Jia" initials="J." surname="Jia">
<author fullname='C. Schelp' initials='C.' surname='Schelp'/> <organization/>
<author fullname='T. Mizrahi' initials='T.' surname='Mizrahi'/> </author>
<date month='December' year='2016'/> <author fullname="Leyou Yang" initials="L." surname="Yang">
<abstract> <organization/>
<t>Clock synchronization protocols are very widely used in IP-based networ </author>
ks. The Network Time Protocol (NTP) has been commonly deployed for many years, a <author fullname="Jian Chen" initials="J." surname="Chen">
nd the last few years have seen an increasingly rapid deployment of the Precisio <organization/>
n Time Protocol (PTP). As time-sensitive applications evolve, clock accuracy req </author>
uirements are becoming increasingly stringent, requiring the time synchronizatio <author fullname="Lidao Ma" initials="L." surname="Ma">
n protocols to provide high accuracy. This memo describes a multipath approach t <organization/>
o PTP and NTP over IP networks, allowing the protocols to run concurrently over </author>
multiple communication paths between the master and slave clocks, without modify <author fullname="Xingwei Wang" initials="X." surname="Wang">
ing these protocols. The multipath approach can significantly contribute to cloc <organization/>
k accuracy, security, and fault tolerance. The multipath approach that is presen </author>
ted in this document enables backward compatibility with nodes that do not suppo <date month="March" year="2024"/>
rt the multipath functionality.</t> </front>
</abstract> <refcontent>Wireless Networks, vol. 30, no. 4, pp. 2939-2959</refcontent
</front> >
<seriesInfo name='RFC' value='8039'/> <seriesInfo name="DOI" value="10.1007/s11276-024-03706-4"/>
<seriesInfo name='DOI' value='10.17487/RFC8039'/> </reference>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.727
2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.803
9.xml"/>
</references> </references>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Eric Wagner"/> for
providing text on the security considerations and <contact
fullname="Jungha Hong"/> for her efforts in continuing the work on the
use case analysis document that has largely sourced the preliminary
categorization section of this document.</t>
<t>The authors would further like to thank <contact fullname="Chathura
Sarathchandra"/>, <contact fullname="David Oran"/>, <contact
fullname="Phil Eardley"/>, <contact fullname="Stuart Card"/>, <contact
fullname="Jeffrey He"/>, <contact fullname="Toerless Eckert"/>, and
<contact fullname="Jon Crowcroft"/> for reviewing earlier versions of
the document, <contact fullname="Colin Perkins"/> for his IRTF chair
review, and <contact fullname="Jerome Francois"/> for his thorough IRSG
review.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAPYgUGcAA8y9e1cbWZYv+D+fIlbmWheolIQNxnZS9143CdhJp40pwM6q
np6pDqSQFGkpQhURAquw57PPfp99QiEyK6t7brtqJSDF4zz22e/92/1+f6vJ
m1l2lHyos+QkrbM6GZdVcl70L7Lmvqw+JSflfLFs8mKyld7eVtndUXLy/vwi
XL81KodFOodHjKp03PTzqhn3h2VeVJP+ss76Q7yo/+TF1iht4KKH0+Obs69b
Q/hjUlaroyQvxuVWvqiOkqZa1s3+kyffP9nfSqssPUreZEVWpbMtHMikKpcL
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==
</rfc> </rfc>
 End of changes. 119 change blocks. 
3307 lines changed or deleted 2831 lines changed or added

This html diff was produced by rfcdiff 1.48.