rfc9817v1.txt | rfc9817.txt | |||
---|---|---|---|---|
Internet Research Task Force (IRTF) I. Kunze | Internet Research Task Force (IRTF) I. Kunze | |||
Request for Comments: 9817 K. Wehrle | Request for Comments: 9817 K. Wehrle | |||
Category: Informational RWTH Aachen | Category: Informational RWTH Aachen | |||
ISSN: 2070-1721 D. Trossen | ISSN: 2070-1721 D. Trossen | |||
Huawei | DaPaDOT Tech | |||
M-J. Montpetit | M-J. Montpetit | |||
McGill | SLICES-RI | |||
X. de Foy | X. de Foy | |||
InterDigital Communications, LLC | InterDigital Communications, LLC | |||
D. Griffin | D. Griffin | |||
M. Rio | M. Rio | |||
UCL | UCL | |||
July 2025 | July 2025 | |||
Use Cases for In-Network Computing | Use Cases for In-Network Computing | |||
Abstract | Abstract | |||
skipping to change at line 159 ¶ | skipping to change at line 159 ¶ | |||
is another objective of the use case descriptions. To achieve this, | is another objective of the use case descriptions. To achieve this, | |||
the following taxonomy is proposed to describe each of the use cases: | the following taxonomy is proposed to describe each of the use cases: | |||
Description: A high-level presentation of the purpose of the use | Description: A high-level presentation of the purpose of the use | |||
case and a short explanation of the use case behavior. | case and a short explanation of the use case behavior. | |||
Characterization: An explanation of the services that are being | Characterization: An explanation of the services that are being | |||
utilized and realized as well as the semantics of interactions in | utilized and realized as well as the semantics of interactions in | |||
the use case. | the use case. | |||
Existing Solutions: A description of current methods that may | Existing solutions: A description of current methods that may | |||
realize the use case (if they exist), though not claiming to | realize the use case (if they exist), though not claiming to | |||
exhaustively review the landscape of solutions. | exhaustively review the landscape of solutions. | |||
Opportunities: An outline of how COIN capabilities may support or | Opportunities: An outline of how COIN capabilities may support or | |||
improve on the use case in terms of performance and other metrics. | improve on the use case in terms of performance and other metrics. | |||
Research questions: Essential questions that are suitable for | Research questions: Essential questions that are suitable for | |||
guiding research to achieve the identified opportunities. The | guiding research to achieve the identified opportunities. The | |||
research questions also capture immediate capabilities for any | research questions also capture immediate capabilities for any | |||
COIN solution addressing the particular use case whose development | COIN solution addressing the particular use case whose development | |||
skipping to change at line 269 ¶ | skipping to change at line 269 ¶ | |||
(e.g., more suitable) devices, including PNDs, which have exposed the | (e.g., more suitable) devices, including PNDs, which have exposed the | |||
corresponding (COIN) program as individual (COIN) program instances | corresponding (COIN) program as individual (COIN) program instances | |||
to the (COIN) system by means of a service identifier. The result is | to the (COIN) system by means of a service identifier. The result is | |||
the equivalent to mobile function offloading, for possible reduction | the equivalent to mobile function offloading, for possible reduction | |||
of power consumption (e.g., offloading CPU-intensive process | of power consumption (e.g., offloading CPU-intensive process | |||
functions to a remote server) or for improved end-user experience | functions to a remote server) or for improved end-user experience | |||
(e.g., moving display functions to a nearby smart TV) by selecting | (e.g., moving display functions to a nearby smart TV) by selecting | |||
more suitably placed (COIN) program instances in the overall (COIN) | more suitably placed (COIN) program instances in the overall (COIN) | |||
system. | system. | |||
We can already see a trend toward supporting such functionality with | We can already see a trend toward supporting such functionality that | |||
relyiccng on dedicated cloud hardware (e.g., gaming platforms | relies on dedicated cloud hardware (e.g., gaming platforms rendering | |||
rendering content externally). We envision, however, that such | content externally). We envision, however, that such functionality | |||
functionality is becoming more pervasive through specific facilities, | is becoming more pervasive through specific facilities, such as | |||
such as entertainment parks or even hotels, in order to deploy needed | entertainment parks or even hotels, in order to deploy needed edge | |||
edge computing capabilities to enable localized gaming as well as | computing capabilities to enable localized gaming as well as non- | |||
non-gaming scenarios. | gaming scenarios. | |||
Figure 1 shows one realization of the above scenario, where a "DPR | Figure 1 shows one realization of the above scenario, where a "DPR | |||
app" is running on a mobile device (containing the partitioned COIN | app" is running on a mobile device (containing the partitioned COIN | |||
programs Display (D), Process (P) and Receive (R)) over a | programs Display (D), Process (P) and Receive (R)) over a | |||
programmable switching network, e.g., a Software-Defined Network | programmable switching network, e.g., a Software-Defined Network | |||
(SDN) here. The packaged applications are made available through a | (SDN) here. The packaged applications are made available through a | |||
localized "playstore server". The mobile application installation is | localized "playstore server". The mobile application installation is | |||
realized as a service deployment process, combining the local app | realized as a service deployment process, combining the local app | |||
installation with a distributed deployment (and orchestration) of one | installation with a distributed deployment (and orchestration) of one | |||
or more (COIN) programs on most suitable end systems or PNDs (here, a | or more (COIN) programs on most suitable end systems or PNDs (here, a | |||
skipping to change at line 1018 ¶ | skipping to change at line 1018 ¶ | |||
* RQ 4.1.3: How to find suitable tradeoffs regarding simplicity of | * RQ 4.1.3: How to find suitable tradeoffs regarding simplicity of | |||
the control function ("accuracy of the control") and | the control function ("accuracy of the control") and | |||
implementation complexity ("implementability")? | implementation complexity ("implementability")? | |||
* RQ 4.1.4: How to (dynamically) distribute simplified versions of | * RQ 4.1.4: How to (dynamically) distribute simplified versions of | |||
the global (control) function among COIN execution environments? | the global (control) function among COIN execution environments? | |||
* RQ 4.1.5: How to (dynamically) compose or recompose the | * RQ 4.1.5: How to (dynamically) compose or recompose the | |||
distributed control functions? | distributed control functions? | |||
* RQ 4.1.6: Can there be different control levels, e.g., "quite | * RQ 4.1.6: Can there be different control levels? For example, | |||
inaccurate & very low latency" (PNDs, deep in the network), "more | "quite inaccurate & very low latency" for PNDs deep in the | |||
accurate & higher latency" (more powerful COIN execution | network; "more accurate & higher latency" for more powerful COIN | |||
environments, farther away), "very accurate & very high latency" | execution environments that are farther away; and "very accurate & | |||
(cloud environments, far away)? | very high latency" for cloud environments that are far away. | |||
* RQ 4.1.7: Who decides which control instance is executed and which | * RQ 4.1.7: Who decides which control instance is executed and which | |||
information can be used for this decision? | information can be used for this decision? | |||
* RQ 4.1.8: How do the different control instances interact and how | * RQ 4.1.8: How do the different control instances interact and how | |||
can we define their hierarchy? | can we define their hierarchy? | |||
4.1.6. Additional Desirable Capabilities | 4.1.6. Additional Desirable Capabilities | |||
In addition to the capabilities driven by the research questions | In addition to the capabilities driven by the research questions | |||
skipping to change at line 1106 ¶ | skipping to change at line 1106 ¶ | |||
or sampling frequency is often larger than required. Consequently, | or sampling frequency is often larger than required. Consequently, | |||
it is likely that more data is transmitted than is needed or desired, | it is likely that more data is transmitted than is needed or desired, | |||
prompting the deployment of filtering techniques. For example, COIN | prompting the deployment of filtering techniques. For example, COIN | |||
programs deployed in the on-premise network could filter out | programs deployed in the on-premise network could filter out | |||
redundant or undesired data before it leaves the premise using simple | redundant or undesired data before it leaves the premise using simple | |||
traffic filters, thus reducing the required (upload) bandwidths. The | traffic filters, thus reducing the required (upload) bandwidths. The | |||
available sensor data could be scaled down using standard statistical | available sensor data could be scaled down using standard statistical | |||
sampling, packet-based sub-sampling (i.e., only forwarding every n-th | sampling, packet-based sub-sampling (i.e., only forwarding every n-th | |||
packet), or using filtering as long as the sensor value is in an | packet), or using filtering as long as the sensor value is in an | |||
uninteresting range while forwarding with a higher resolution once | uninteresting range while forwarding with a higher resolution once | |||
the sensor value range becomes interesting (cf. [KUNZE-SIGNAL]). | the sensor value range becomes interesting (cf. [KUNZE-SIGNAL] and | |||
While the former variants are oblivious to the semantics of the | [TIRPITZ-REDUCIO]). While the former variants are oblivious to the | |||
sensor data, the latter variant requires an understanding of the | semantics of the sensor data, the latter variant requires an | |||
current sensor levels. In any case, it is important that end hosts | understanding of the current sensor levels. In any case, it is | |||
are informed about the filtering so that they can distinguish between | important that end hosts are informed about the filtering so that | |||
data loss and data filtered out on purpose. | they can distinguish between data loss and data filtered out on | |||
purpose. | ||||
In practice, the collected data is further processed using various | In practice, the collected data is further processed using various | |||
forms of computation. Some of them are very complex or need the | forms of computation. Some of them are very complex or need the | |||
complete sensor data during the computation, but there are also | complete sensor data during the computation, but there are also | |||
simpler operations that can already be done on subsets of the overall | simpler operations that can already be done on subsets of the overall | |||
dataset or earlier on the communication path as soon as all data is | dataset or earlier on the communication path as soon as all data is | |||
available. One example is finding the maximum of all sensor values, | available. One example is finding the maximum of all sensor values, | |||
which can either be done iteratively at each intermediate hop or at | which can either be done iteratively at each intermediate hop or at | |||
the first hop where all data is available. Using expert knowledge | the first hop where all data is available. Using expert knowledge | |||
about the exact computation steps and the concrete transmission path | about the exact computation steps and the concrete transmission path | |||
skipping to change at line 1163 ¶ | skipping to change at line 1164 ¶ | |||
context of general stream processing systems. | context of general stream processing systems. | |||
* RQ 4.2.1: How can the overall data processing pipeline be divided | * RQ 4.2.1: How can the overall data processing pipeline be divided | |||
into individual processing steps that could then be deployed as | into individual processing steps that could then be deployed as | |||
COIN functionality? | COIN functionality? | |||
* RQ 4.2.2: How to design COIN programs for (semantic) packet | * RQ 4.2.2: How to design COIN programs for (semantic) packet | |||
filtering and which filtering criteria make sense? | filtering and which filtering criteria make sense? | |||
* RQ 4.2.3: Which kinds of COIN programs can be leveraged for | * RQ 4.2.3: Which kinds of COIN programs can be leveraged for | |||
(pre)processing steps and what complexity can they have? | preprocessing and processing steps and what complexity can they | |||
have? | ||||
* RQ 4.2.4: How to distribute and coordinate COIN programs? | * RQ 4.2.4: How to distribute and coordinate COIN programs? | |||
* RQ 4.2.5: How to dynamically reconfigure and recompose COIN | * RQ 4.2.5: How to dynamically reconfigure and recompose COIN | |||
programs? | programs? | |||
* RQ 4.2.6: How to incorporate the (pre)processing and filtering | * RQ 4.2.6: How to incorporate the preprocessing, processing, and | |||
steps into the overall system? | filtering steps into the overall system? | |||
* RQ 4.2.7: How can changes to the data by COIN programs be signaled | * RQ 4.2.7: How can changes to the data by COIN programs be signaled | |||
to the end hosts? | to the end hosts? | |||
4.2.6. Additional Desirable Capabilities | 4.2.6. Additional Desirable Capabilities | |||
In addition to the capabilities driven by the research questions | In addition to the capabilities driven by the research questions | |||
above, there are a number of other features that such large-volume | above, there are a number of other features that such large-volume | |||
applications could benefit from. In particular, conforming to | applications could benefit from. In particular, conforming to | |||
standard application-level syntax and semantics likely simplifies | standard application-level syntax and semantics likely simplifies | |||
skipping to change at line 1596 ¶ | skipping to change at line 1598 ¶ | |||
network programming of individual virtual switches. To our | network programming of individual virtual switches. To our | |||
knowledge, no complete solution has been developed for deploying | knowledge, no complete solution has been developed for deploying | |||
virtual COIN programs over mobile or data center networks. | virtual COIN programs over mobile or data center networks. | |||
5.3.4. Opportunities | 5.3.4. Opportunities | |||
Virtual network programming by tenants could bring benefits such as: | Virtual network programming by tenants could bring benefits such as: | |||
* A unified programming model, which can facilitate porting COIN | * A unified programming model, which can facilitate porting COIN | |||
programs between data centers, 5G networks, and other fixed and | programs between data centers, 5G networks, and other fixed and | |||
wireless networks, as well as sharing controller, code and | wireless networks, as well as sharing controllers, code, and | |||
expertise. | expertise. | |||
* Increasing the level of customization available to customers/ | * Increasing the level of customization available to customers/ | |||
tenants of mobile networks or data centers compared to typical | tenants of mobile networks or data centers compared to typical | |||
configuration capabilities. For example, 5G network evolution | configuration capabilities. For example, 5G network evolution | |||
points to an ever-increasing specialization and customization of | points to an ever-increasing specialization and customization of | |||
private mobile networks, which could be handled by tenants using a | private mobile networks, which could be handled by tenants using a | |||
programming model similar to P4. | programming model similar to P4. | |||
* Using network programs to influence underlying network services | * Using network programs to influence underlying network services | |||
skipping to change at line 1869 ¶ | skipping to change at line 1871 ¶ | |||
systems typically work on unencrypted data and often customize packet | systems typically work on unencrypted data and often customize packet | |||
payload, while concepts such as homomorphic encryption could serve as | payload, while concepts such as homomorphic encryption could serve as | |||
workarounds, allowing PNDs to perform simple operations on the | workarounds, allowing PNDs to perform simple operations on the | |||
encrypted data without having access to it. All these approaches | encrypted data without having access to it. All these approaches | |||
introduce the same or very similar security implications as any | introduce the same or very similar security implications as any | |||
middlebox operating on unencrypted traffic or having access to | middlebox operating on unencrypted traffic or having access to | |||
encryption: a middlebox can itself have malicious intentions (e.g., | encryption: a middlebox can itself have malicious intentions (e.g., | |||
because it got compromised or the deployment of functionality offers | because it got compromised or the deployment of functionality offers | |||
new attack vectors to outsiders). | new attack vectors to outsiders). | |||
However, similar to middlebox deployments, risks for privacy and data | However, similar to middlebox deployments, risks for privacy and the | |||
exposure have to be carefully considered in the context of the | risk of data exposure have to be carefully considered in the context | |||
concrete deployment. For example, exposing data to an external | of the concrete deployment. For example, exposing data to an | |||
operator for mobile application offloading leads to a significant | external operator for mobile application offloading leads to a | |||
privacy loss of the user in any case. In contrast, such privacy | significant privacy loss of the user in any case. In contrast, such | |||
considerations are not as relevant for COIN systems where all | privacy considerations are not as relevant for COIN systems where all | |||
involved entities are under the same control, such as in an | involved entities are under the same control, such as in an | |||
industrial context. Here, exposed data and functionality can instead | industrial context. Here, exposed data and functionality can instead | |||
lead to stolen business secrets or the enabling of DoS attacks, for | lead to stolen business secrets or the enabling of DoS attacks, for | |||
example. Hence, even in fully controlled scenarios, COIN | example. Hence, even in fully controlled scenarios, COIN | |||
intermediaries, and middleboxes in general, are ideally operated in a | intermediaries, and middleboxes in general, are ideally operated in a | |||
least-privilege mode, where they have exactly those permissions to | least-privilege mode, where they have exactly those permissions to | |||
read and alter payload that are necessary to fulfill their purpose. | read and alter payload that are necessary to fulfill their purpose. | |||
Research on granting middleboxes access to secured traffic is only in | Research on granting middleboxes access to secured traffic is only in | |||
its infancy, and a variety of different approaches are proposed and | its infancy, and a variety of different approaches are proposed and | |||
skipping to change at line 1915 ¶ | skipping to change at line 1917 ¶ | |||
process. Moreover, such deployments can become central entities | process. Moreover, such deployments can become central entities | |||
that, if paralyzed (e.g., through extensive requests), can be | that, if paralyzed (e.g., through extensive requests), can be | |||
responsible for large-scale outages. In particular, some deployments | responsible for large-scale outages. In particular, some deployments | |||
could be used to amplify DoS attacks. Similar to other middlebox | could be used to amplify DoS attacks. Similar to other middlebox | |||
deployments, these potential risks must be considered when deploying | deployments, these potential risks must be considered when deploying | |||
COIN functionality and may influence the selection of suitable | COIN functionality and may influence the selection of suitable | |||
security protocols. | security protocols. | |||
Additional system-level security considerations may arise from | Additional system-level security considerations may arise from | |||
regulatory requirements imposed on COIN systems overall, stemming | regulatory requirements imposed on COIN systems overall, stemming | |||
from regulation regarding, lawful interception, data localization, or | from regulation regarding lawful interception, data localization, or | |||
AI use, for example. These requirements may impact, for example, the | AI use, for example. These requirements may impact, for example, the | |||
manner in which (COIN) programs may be placed or executed in the | manner in which (COIN) programs may be placed or executed in the | |||
overall system, who can invoke certain (COIN) programs in what PND or | overall system, who can invoke certain (COIN) programs in what PND or | |||
COIN device, and what type of (COIN) program can be run. These | COIN device, and what type of (COIN) program can be run. These | |||
considerations will impact the design of the possible implementing | considerations will impact the design of the possible implementing | |||
protocols but also the policies that govern the execution of (COIN) | protocols but also the policies that govern the execution of (COIN) | |||
programs. | programs. | |||
9. IANA Considerations | 9. IANA Considerations | |||
skipping to change at line 2129 ¶ | skipping to change at line 2131 ¶ | |||
[RÜTH] Rüth, J., Glebke, R., Wehrle, K., Causevic, V., and S. | [RÜTH] Rüth, J., Glebke, R., Wehrle, K., Causevic, V., and S. | |||
Hirche, "Towards In-Network Industrial Feedback Control", | Hirche, "Towards In-Network Industrial Feedback Control", | |||
Proceedings of the 2018 Morning Workshop on In-Network | Proceedings of the 2018 Morning Workshop on In-Network | |||
Computing, pp. 14-19, DOI 10.1145/3229591.3229592, August | Computing, pp. 14-19, DOI 10.1145/3229591.3229592, August | |||
2018, <https://doi.org/10.1145/3229591.3229592>. | 2018, <https://doi.org/10.1145/3229591.3229592>. | |||
[SA2-5GLAN] | [SA2-5GLAN] | |||
3GPP-5glan, "SP-181129, Work Item Description, | 3GPP-5glan, "SP-181129, Work Item Description, | |||
Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and | Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and | |||
LAN Services", 3GPP , 2021, | LAN Services", 3GPP , 2021, | |||
<http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP- | <https://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP- | |||
181120.zip>. | 181120.zip>. | |||
[SarNet2021] | [SarNet2021] | |||
Glebke, R., Trossen, D., Kunze, I., Lou, D., Ruth, J., | Glebke, R., Trossen, D., Kunze, I., Lou, D., Ruth, J., | |||
Stoffers, M., and K. Wehrle, "Service-based Forwarding via | Stoffers, M., and K. Wehrle, "Service-based Forwarding via | |||
Programmable Dataplanes", 2021 IEEE 22nd International | Programmable Dataplanes", 2021 IEEE 22nd International | |||
Conference on High Performance Switching and Routing | Conference on High Performance Switching and Routing | |||
(HPSR), pp. 1-8, DOI 10.1109/hpsr52026.2021.9481814, June | (HPSR), pp. 1-8, DOI 10.1109/hpsr52026.2021.9481814, June | |||
2021, <https://doi.org/10.1109/hpsr52026.2021.9481814>. | 2021, <https://doi.org/10.1109/hpsr52026.2021.9481814>. | |||
skipping to change at line 2159 ¶ | skipping to change at line 2161 ¶ | |||
Rodriguez, P., and P. Steenkiste, "Multi-Context TLS | Rodriguez, P., and P. Steenkiste, "Multi-Context TLS | |||
(mcTLS): Enabling Secure In-Network Functionality in TLS", | (mcTLS): Enabling Secure In-Network Functionality in TLS", | |||
ACM SIGCOMM Computer Communication Review, vol. 45, no. 4, | ACM SIGCOMM Computer Communication Review, vol. 45, no. 4, | |||
pp. 199-212, DOI 10.1145/2829988.2787482, August 2015, | pp. 199-212, DOI 10.1145/2829988.2787482, August 2015, | |||
<https://doi.org/10.1145/2829988.2787482>. | <https://doi.org/10.1145/2829988.2787482>. | |||
[Stoyanov] Stoyanov, R. and N. Zilberman, "MTPSA: Multi-Tenant | [Stoyanov] Stoyanov, R. and N. Zilberman, "MTPSA: Multi-Tenant | |||
Programmable Switches", Proceedings of the 3rd P4 Workshop | Programmable Switches", Proceedings of the 3rd P4 Workshop | |||
in Europe, pp. 43-48, DOI 10.1145/3426744.3431329, | in Europe, pp. 43-48, DOI 10.1145/3426744.3431329, | |||
December 2020, | December 2020, | |||
<https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf>. | <https://dl.acm.org/doi/10.1145/3426744.3431329>. | |||
[Sultana] Sultana, N., Sonchack, J., Giesen, H., Pedisich, I., Han, | [Sultana] Sultana, N., Sonchack, J., Giesen, H., Pedisich, I., Han, | |||
Z., Shyamkumar, N., Burad, S., DeHon, A., and B. T. Loo, | Z., Shyamkumar, N., Burad, S., DeHon, A., and B. T. Loo, | |||
"Flightplan: Dataplane Disaggregation and Placement for P4 | "Flightplan: Dataplane Disaggregation and Placement for P4 | |||
Programs", | Programs", | |||
<https://flightplan.cis.upenn.edu/flightplan.pdf>. | <https://flightplan.cis.upenn.edu/flightplan.pdf>. | |||
[TIRPITZ-REDUCIO] | ||||
Tirpitz, L., Kunze, I., Niemietz, P., Gerhardus, A. K., | ||||
Bergs, T., Wehrle, K., and S. Geisler, "Reducio: Data | ||||
Aggregation and Stability Detection for Industrial | ||||
Processes Using In-Network Computing", DEBS '25: | ||||
Proceedings of the 19th ACM International Conference on | ||||
Distributed and Event-based Systems, pp. 98-109, | ||||
DOI 10.1145/3701717.3730547, June 2025, | ||||
<https://doi.org/10.1145/3701717.3730547>. | ||||
[TLSSURVEY] | [TLSSURVEY] | |||
de Carné de Carnavalet, X. and P. van Oorschot, "A Survey | de Carné de Carnavalet, X. and P. van Oorschot, "A Survey | |||
and Analysis of TLS Interception Mechanisms and | and Analysis of TLS Interception Mechanisms and | |||
Motivations: Exploring how end-to-end TLS is made 'end-to- | Motivations: Exploring how end-to-end TLS is made 'end-to- | |||
me' for web traffic", ACM Computing Surveys, vol. 55, no. | me' for web traffic", ACM Computing Surveys, vol. 55, no. | |||
13s, pp. 1-40, DOI 10.1145/3580522, July 2023, | 13s, pp. 1-40, DOI 10.1145/3580522, July 2023, | |||
<https://doi.org/10.1145/3580522>. | <https://doi.org/10.1145/3580522>. | |||
[TOSCA] Rutkowski, M., Ed., Lauwers, C., Ed., Noshpitz, C., Ed., | [TOSCA] Rutkowski, M., Ed., Lauwers, C., Ed., Noshpitz, C., Ed., | |||
and C. Curescu, Ed., "TOSCA Simple Profile in YAML Version | and C. Curescu, Ed., "TOSCA Simple Profile in YAML Version | |||
skipping to change at line 2242 ¶ | skipping to change at line 2254 ¶ | |||
Email: kunze@comsys.rwth-aachen.de | Email: kunze@comsys.rwth-aachen.de | |||
Klaus Wehrle | Klaus Wehrle | |||
RWTH Aachen University | RWTH Aachen University | |||
Ahornstr. 55 | Ahornstr. 55 | |||
D-52074 Aachen | D-52074 Aachen | |||
Germany | Germany | |||
Email: wehrle@comsys.rwth-aachen.de | Email: wehrle@comsys.rwth-aachen.de | |||
Dirk Trossen | Dirk Trossen | |||
Huawei Technologies Duesseldorf GmbH | DaPaDOT Tech UG (haftungsbeschränkt) | |||
Riesstr. 25C | Palestrinastr. 7A | |||
D-80992 Munich | D-80639 Munich | |||
Germany | Germany | |||
Email: Dirk.Trossen@Huawei.com | Email: dirk@dapadot-tech.eu | |||
Marie-Jose Montpetit | Marie-Jose Montpetit | |||
McGill University | SLICES-RI | |||
680 Sherbrooke Street W. | Paris | |||
Montreal H3A 3R1 | France | |||
Canada | Email: marie-jose.montpetit@slices-ri.eu | |||
Email: marie-jose.montpetit@mcgill.ca | ||||
Xavier de Foy | Xavier de Foy | |||
InterDigital Communications, LLC | InterDigital Communications, LLC | |||
1000 Sherbrooke West | 1000 Sherbrooke West | |||
Montreal H3A 3G4 | Montreal H3A 3G4 | |||
Canada | Canada | |||
Email: xavier.defoy@interdigital.com | Email: xavier.defoy@interdigital.com | |||
David Griffin | David Griffin | |||
University College London | University College London | |||
End of changes. 17 change blocks. | ||||
43 lines changed or deleted | 54 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |