diff options
Diffstat (limited to 'doc/rfc/rfc8975.txt')
| -rw-r--r-- | doc/rfc/rfc8975.txt | 740 |
1 files changed, 740 insertions, 0 deletions
diff --git a/doc/rfc/rfc8975.txt b/doc/rfc/rfc8975.txt new file mode 100644 index 0000000..911ab33 --- /dev/null +++ b/doc/rfc/rfc8975.txt @@ -0,0 +1,740 @@ + + + + +Internet Research Task Force (IRTF) N. Kuhn, Ed. +Request for Comments: 8975 CNES +Category: Informational E. Lochin, Ed. +ISSN: 2070-1721 ENAC + January 2021 + + + Network Coding for Satellite Systems + +Abstract + + This document is a product of the Coding for Efficient Network + Communications Research Group (NWCRG). It conforms to the directions + found in the NWCRG taxonomy (RFC 8406). + + The objective is to contribute to a larger deployment of Network + Coding techniques in and above the network layer in satellite + communication systems. This document also identifies open research + issues related to the deployment of Network Coding in satellite + communication systems. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Research Task Force + (IRTF). The IRTF publishes the results of Internet-related research + and development activities. These results might not be suitable for + deployment. This RFC represents the consensus of the Coding for + Efficient Network Communications Research Group of the Internet + Research Task Force (IRTF). Documents approved for publication by + the IRSG are not a candidate for any level of Internet Standard; see + Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8975. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction + 2. A Note on the Topology of Satellite Networks + 3. Use Cases for Improving SATCOM System Performance Using Network + Coding + 3.1. Two-Way Relay Channel Mode + 3.2. Reliable Multicast + 3.3. Hybrid Access + 3.4. LAN Packet Losses + 3.5. Varying Channel Conditions + 3.6. Improving Gateway Handover + 4. Research Challenges + 4.1. Joint Use of Network Coding and Congestion Control in + SATCOM Systems + 4.2. Efficient Use of Satellite Resources + 4.3. Interaction with Virtualized Satellite Gateways and + Terminals + 4.4. Delay/Disruption-Tolerant Networking (DTN) + 5. Conclusion + 6. Glossary + 7. IANA Considerations + 8. Security Considerations + 9. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + This document is a product of and represents the collaborative work + and consensus of the Coding for Efficient Network Communications + Research Group (NWCRG); while it is not an IETF product and not a + standard, it is intended to inform the SATellite COMmunication + (SATCOM) and Internet research communities about recent developments + in Network Coding. A glossary is included in Section 6 to clarify + the terminology used throughout the document. + + As will be shown in this document, the implementation of Network + Coding techniques above the network layer, at application or + transport layers (as described in [RFC1122]), offers an opportunity + for improving the end-to-end performance of SATCOM systems. + Physical- and link-layer coding error protection is usually enough to + provide quasi-error-free transmission, thus minimizing packet loss. + However, when residual errors at those layers cause packet losses, + retransmissions add significant delays (in particular, in + geostationary systems with over 0.7 second round-trip delays). + Hence, the use of Network Coding at the upper layers can improve the + quality of service in SATCOM subnetworks and eventually favorably + impact the experience of end users. + + While there is an active research community working on Network Coding + techniques above the network layer in general and in SATCOM in + particular, not much of this work has been deployed in commercial + systems. In this context, this document identifies opportunities for + further usage of Network Coding in commercial SATCOM networks. + + The notation used in this document is based on the NWCRG taxonomy + [RFC8406]: + + * Channel and link error-correcting codes are considered part of the + error protection for the PHYsical (PHY) layer and are out of the + scope of this document. + + * Forward Erasure Correction (FEC) (also called "Application-Level + FEC") operates above the link layer and targets packet-loss + recovery. + + * This document considers only coding (or coding techniques or + coding schemes) that uses a linear combination of packets; it + excludes, for example, content coding (e.g., to compress a video + flow) or other non-linear operations. + +2. A Note on the Topology of Satellite Networks + + There are multiple SATCOM systems, for example, broadcast TV, point- + to point-communication, and Internet of Things (IoT) monitoring. + Therefore, depending on the purpose of the system, the associated + ground segment architecture will be different. This section focuses + on a satellite system that follows the European Telecommunications + Standards Institute (ETSI) Digital Video Broadcasting (DVB) standards + to provide broadband Internet access via ground-based gateways + [ETSI-EN-2020]. One must note that the overall data capacity of one + satellite may be higher than the capacity that one single gateway + supports. Hence, there are usually multiple gateways for one unique + satellite platform. + + In this context, Figure 1 shows an example of a multigateway + satellite system, where BBFRAME stands for "Base-Band FRAME", PLFRAME + for "Physical Layer FRAME", and PEP for "Performance Enhancing + Proxy". More information on a generic SATCOM ground segment + architecture for bidirectional Internet access can be found in + [SAT2017] or in DVB standard documents. + + +--------------------------+ + | application servers | + | (data, coding, multicast)| + +--------------------------+ + | ... | + ----------------------------------- + | | | | | | + +---------------------+ +---------------------+ + | network function | | network function | + |(firewall, PEP, etc.)| |(firewall, PEP, etc.)| + +---------------------+ +---------------------+ + | ... | IP packets | ... | + --- + +------------------+ +------------------+ | + | access gateway | | access gateway | | + +------------------+ +------------------+ | + | BBFRAME | | gateway + +------------------+ +------------------+ | + | physical gateway | | physical gateway | | + +------------------+ +------------------+ | + --- + | PLFRAME | + +------------------+ +------------------+ + | outdoor unit | | outdoor unit | + +------------------+ +------------------+ + | satellite link | + +------------------+ +------------------+ + | outdoor unit | | outdoor unit | + +------------------+ +------------------+ + | | + +------------------+ +------------------+ + | sat terminals | | sat terminals | + +------------------+ +------------------+ + | | | | + +----------+ | +----------+ | + |end user 1| | |end user 3| | + +----------+ | +----------+ | + +----------+ +----------+ + |end user 2| |end user 4| + +----------+ +----------+ + + Figure 1: Data-Plane Functions in a Generic Satellite + Multigateway System + +3. Use Cases for Improving SATCOM System Performance Using Network + Coding + + This section details use cases where Network Coding techniques could + improve SATCOM system performance. + +3.1. Two-Way Relay Channel Mode + + This use case considers two-way communication between end users + through a satellite link, as seen in Figure 2. + + Satellite terminal A sends a packet flow A, and satellite terminal B + sends a packet flow B, to a coding server. The coding server then + sends a combination of both flows instead of each individual flow. + This results in non-negligible capacity savings, which has been + demonstrated in the past [ASMS2010]. In the example, a dedicated + coding server is introduced (note that its location could be + different based on deployment use case). The Network Coding + operations could also be done at the satellite level, although this + would require a lot of computational resources onboard and may not be + supported by today's satellites. + + -X}- : traffic from satellite terminal X to the server + ={X+Y= : traffic from X and Y combined sent from + the server to terminals X and Y + + +-----------+ +-----+ + |Sat term A |--A}-+ | | + +-----------+ | | | +---------+ +------+ + ^^ +--| |--A}--| |--A}--|Coding| + || | SAT |--B}--| Gateway |--B}--|Server| + ===={A+B=========| |={A+B=| |={A+B=| | + || | | +---------+ +------+ + vv +--| | + +-----------+ | | | + |Sat term B |--B}-+ | | + +-----------+ +-----+ + + Figure 2: Network Architecture for Two-Way Relay Channel Using + Network Coding + +3.2. Reliable Multicast + + The use of multicast servers is one way to better utilize satellite + broadcast capabilities. As one example, satellite-based multicast is + proposed in the Secure Hybrid In Network caching Environment (SHINE) + project of the European Space Agency (ESA) [NETCOD-FUNCTION-VIRT] + [SHINE]. This use case considers adding redundancy to a multicast + flow depending on what has been received by different end users, + resulting in non-negligible savings of the scarce SATCOM resources. + This scenario is shown in Figure 3. + + -Li}- : packet indicating the loss of packet i of a multicast flow M + ={M== : multicast flow including the missing packets + + +-----------+ +-----+ + |Terminal A |-Li}-+ | | + +-----------+ | | | +---------+ +------+ + ^^ +-| |-Li}--| | |Multi | + || | SAT |-Lj}--| Gateway |--|Cast | + ===={M==========| |={M===| | |Server| + || | | +---------+ +------+ + vv +-| | + +-----------+ | | | + |Terminal B |-Lj}-+ | | + +-----------+ +-----+ + + Figure 3: Network Architecture for a Reliable Multicast Using + Network Coding + + A multicast flow (M) is forwarded to both satellite terminals A and + B. M is composed of packets Nk (not shown in Figure 3). Packet Ni + (respectively Nj) gets lost at terminal A (respectively B), and + terminal A (respectively B) returns a negative acknowledgment Li + (respectively Lj), indicating that the packet is missing. Using + coding, either the access gateway or the multicast server can include + a repair packet (rather than the individual Ni and Nj packets) in the + multicast flow to let both terminals recover from losses. + + This could also be achieved by using other multicast or broadcast + systems, such as NACK-Oriented Reliable Multicast (NORM) [RFC5740] or + File Delivery over Unidirectional Transport (FLUTE) [RFC6726]. Both + NORM and FLUTE are limited to block coding; neither of them supports + more flexible sliding window encoding schemes that allow decoding + before receiving the whole block, which is an added delay benefit + [RFC8406] [RFC8681]. + +3.3. Hybrid Access + + This use case considers improving multiple-path communications with + Network Coding at the transport layer (see Figure 4, where DSL stands + for "Digital Subscriber Line", LTE for "Long Term Evolution", and SAT + for "SATellite"). This use case is inspired by the Broadband Access + via Integrated Terrestrial Satellite Systems (BATS) project and has + been published as an ETSI Technical Report [ETSI-TR-2017]. + + To cope with packet loss (due to either end-user mobility or + physical-layer residual errors), Network Coding can be introduced. + Depending on the protocol, Network Coding could be applied at the + Customer Premises Equipment (CPE), the concentrator, or both. Apart + from coping with packet loss, other benefits of this approach include + a better tolerance for out-of-order packet delivery, which occurs + when exploited links exhibit high asymmetry in terms of Round-Trip + Time (RTT). Depending on the ground architecture [5G-CORE-YANG] + [SAT2017], some ground equipment might be hosting both SATCOM and + cellular network functionality. + + -{}- : bidirectional link + + +---+ +--------------+ + +-{}-|SAT|-{}-|BACKBONE | + +----+ +---+ | +---+ |+------------+| + |End |-{}-|CPE|-{}-| ||CONCENTRATOR|| + |User| +---+ | +---+ |+------------+| +-----------+ + +----+ |-{}-|DSL|-{}-| |-{}-|Application| + | +---+ | | |Server | + | | | +-----------+ + | +---+ | | + +-{}-|LTE|-{}-+--------------+ + +---+ + + Figure 4: Network Architecture for Hybrid Access Using Network Coding + +3.4. LAN Packet Losses + + This use case considers using Network Coding in the scenario where a + lossy WiFi link is used to connect to the SATCOM network. When + encrypted end-to-end applications based on UDP are used, a + Performance Enhancing Proxy (PEP) cannot operate; hence, other + mechanisms need to be used. The WiFi packet losses will result in an + end-to-end retransmission that will harm the quality of the end + user's experience and poorly utilize SATCOM bottleneck resources for + traffic that does not generate revenue. In this use case, adding + Network Coding techniques will prevent the end-to-end retransmission + from occurring since the packet losses would probably be recovered. + + The architecture is shown in Figure 5. + + -{}- : bidirectional link + -''- : WiFi link + C : where Network Coding techniques could be introduced + + +----+ +--------+ +---+ +-------+ +-------+ +--------+ + |End | |Sat. | |SAT| |Phy | |Access | |Network | + |user|-''-|Terminal|-{}-| |-{}-|Gateway|-{}-|Gateway|-{}-|Function| + +----+ +--------+ +---+ +-------+ +-------+ +--------+ + C C C C + + Figure 5: Network Architecture for Dealing with LAN Losses + +3.5. Varying Channel Conditions + + This use case considers the usage of Network Coding to cope with + subsecond physical channel condition changes where the physical-layer + mechanisms (Adaptive Coding and Modulation (ACM)) may not adapt the + modulation and error-correction coding in time; the residual errors + lead to higher-layer packet losses that can be recovered with Network + Coding. This use case is mostly relevant when mobile users are + considered or when the satellite frequency band introduces quick + changes in channel condition (Q/V bands, Ka band, etc.). Depending + on the use case (e.g., bands with very high frequency, mobile users), + the relevance of adding Network Coding is different. + + The system architecture is shown in Figure 6. + + -{}- : bidirectional link + C : where Network Coding techniques could be introduced + + +---------+ +---+ +--------+ +-------+ +--------+ + |Satellite| |SAT| |Physical| |Access | |Network | + |Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function| + +---------+ +---+ +--------+ +-------+ +--------+ + C C C C + + Figure 6: Network Architecture for Dealing with Varying Link + Characteristics + +3.6. Improving Gateway Handover + + This use case considers the recovery of packets that may be lost + during gateway handover. Whether for off-loading a given equipment + or because the transmission quality differs from gateway to gateway, + switching the transmission gateway may be beneficial. However, + packet losses can occur if the gateways are not properly synchronized + or if the algorithm used to trigger gateway handover is not properly + tuned. During these critical phases, Network Coding can be added to + improve the reliability of the transmission and allow a seamless + gateway handover. + + Figure 7 illustrates this use case. + + -{}- : bidirectional link + ! : management interface + C : where Network Coding techniques could be introduced + C C + +--------+ +-------+ +--------+ + |Physical| |Access | |Network | + +-{}-|gateway |-{}-|gateway|-{}-|function| + | +--------+ +-------+ +--------+ + | ! ! + +---------+ +---+ +---------------+ + |Satellite| |SAT| | Control-plane | + |Terminal |-{}-| | | manager | + +---------+ +---+ +---------------+ + | ! ! + | +--------+ +-------+ +--------+ + +-{}-|Physical|-{}-|Access |-{}-|Network | + |gateway | |gateway| |function| + +--------+ +-------+ +--------+ + C C + + Figure 7: Network Architecture for Dealing with Gateway Handover + +4. Research Challenges + + This section proposes a few potential approaches to introducing and + using Network Coding in SATCOM systems. + +4.1. Joint Use of Network Coding and Congestion Control in SATCOM + Systems + + Many SATCOM systems typically use Performance Enhancing Proxy (PEP) + [RFC3135]. PEPs usually split end-to-end connections and forward + transport or application-layer packets to the satellite baseband + gateway. PEPs contribute to mitigating congestion in a SATCOM system + by limiting the impact of long delays on Internet protocols. A PEP + mechanism could also include Network Coding operation and thus + support the use cases that have been discussed in Section 3 of this + document. + + Deploying Network Coding in the PEP could be relevant and independent + from the specifics of a SATCOM link. This, however, leads to + research questions dealing with the potential interaction between + Network Coding and congestion control. This is discussed in + [NWCRG-CODING]. + +4.2. Efficient Use of Satellite Resources + + There is a recurrent trade-off in SATCOM systems: how much overhead + from redundant reliability packets can be introduced to guarantee a + better end-user Quality of Experience (QoE) while optimizing capacity + usage? At which layer should this supplementary redundancy be added? + + This problem has been tackled in the past by the deployment of + physical-layer error-correction codes, but questions remain on + adapting the coding overhead and added delay for, e.g., the quickly + varying channel conditions use case where ACM may not be reacting + quickly enough, as discussed in Section 3.5. A higher layer with + Network Coding does not react more quickly than the physical layer, + but it may operate over a packet-based time window that is larger + than the physical one. + +4.3. Interaction with Virtualized Satellite Gateways and Terminals + + In the emerging virtualized network infrastructure, Network Coding + could be easily deployed as Virtual Network Functions (VNFs). The + next generation of SATCOM ground segments will rely on a virtualized + environment to integrate with terrestrial networks. This trend + towards Network Function Virtualization (NFV) is also central to 5G + and next-generation cellular networks, making this research + applicable to other deployment scenarios [5G-CORE-YANG]. As one + example, Network Coding VNF deployment in a virtualized environment + has been presented in [NETCOD-FUNCTION-VIRT]. + + A research challenge would be the optimization of the NFV service + function chaining, considering a virtualized infrastructure and other + SATCOM-specific functions, in order to guarantee efficient radio-link + usage and provide easy-to-deploy SATCOM services. Moreover, another + challenge related to virtualized SATCOM equipment is the management + of limited buffered capacities in large gateways. + +4.4. Delay/Disruption-Tolerant Networking (DTN) + + Communications among deep-space platforms and terrestrial gateways + can be a challenge. Reliable end-to-end (E2E) communications over + such paths must cope with very long delays and frequent link + disruptions; indeed, E2E connectivity may only be available + intermittently, if at all. Delay/Disruption-Tolerant Networking + (DTN) [RFC4838] is a solution to enable reliable internetworking + space communications where neither standard ad hoc routing nor E2E + Internet protocols can be used. Moreover, DTN can also be seen as an + alternative solution to transfer data between a central PEP and a + remote PEP. + + Network Coding enables E2E reliable communications over a DTN with + potential adaptive re-encoding, as proposed in [THAI15]. Here, the + use case proposed in Section 3.5 would encourage the usage of Network + Coding within the DTN stack to improve utilization of the physical + channel and minimize the effects of the E2E transmission delays. In + this context, the use of packet erasure coding techniques inside a + Consultative Committee for Space Data Systems (CCSDS) architecture + has been specified in [CCSDS-131.5-O-1]. One research challenge + remains: how such Network Coding can be integrated in the IETF DTN + stack. + +5. Conclusion + + This document introduces some wide-scale Network Coding technique + opportunities in satellite telecommunications systems. + + Even though this document focuses on satellite systems, it is worth + pointing out that some scenarios proposed here may be relevant to + other wireless telecommunication systems. As one example, the + generic architecture proposed in Figure 1 may be mapped onto cellular + networks as follows: the 'network function' block gathers some of the + functions of the Evolved Packet Core subsystem, while the 'access + gateway' and 'physical gateway' blocks gather the same type of + functions as the Universal Mobile Terrestrial Radio Access Network. + This mapping extends the opportunities identified in this document, + since they may also be relevant for cellular networks. + +6. Glossary + + The glossary of this memo extends the definitions of the taxonomy + document [RFC8406] as follows: + + ACM: Adaptive Coding and Modulation + + BBFRAME: Base-Band FRAME -- satellite communication Layer 2 + encapsulation works as follows: (1) each Layer 3 packet + is encapsulated with a Generic Stream Encapsulation (GSE) + mechanism, (2) GSE packets are gathered to create + BBFRAMEs, (3) BBFRAMEs contain information related to how + they have to be modulated, and (4) BBFRAMEs are forwarded + to the physical layer. + + COM: COMmunication + + CPE: Customer Premises Equipment + + DSL: Digital Subscriber Line + + DTN: Delay/Disruption-Tolerant Networking + + DVB: Digital Video Broadcasting + + E2E: End-to-End + + ETSI: European Telecommunications Standards Institute + + FEC: Forward Erasure Correction + + FLUTE: File Delivery over Unidirectional Transport [RFC6726] + + IntraF: Intra-Flow Coding + + InterF: Inter-Flow Coding + + IoT: Internet of Things + + LTE: Long Term Evolution + + MPC: Multi-Path Coding + + NC: Network Coding + + NFV: Network Function Virtualization -- concept of running + software-defined network functions + + NORM: NACK-Oriented Reliable Multicast [RFC5740] + + PEP: Performance Enhancing Proxy [RFC3135] -- a typical PEP + for satellite communications includes compression, + caching, TCP ACK spoofing, and specific congestion- + control tuning. + + PLFRAME: Physical Layer FRAME -- modulated version of a BBFRAME + with additional information (e.g., related to + synchronization) + + QEF: Quasi-Error-Free + + QoE: Quality of Experience + + QoS: Quality of Service + + RTT: Round-Trip Time + + SAT: SATellite + + SATCOM: Generic term related to all kinds of SATellite- + COMmunication systems + + SPC: Single-Path Coding + + VNF: Virtual Network Function -- implementation of a network + function using software. + +7. IANA Considerations + + This document has no IANA actions. + +8. Security Considerations + + Security considerations are inherent to any access network, in + particular SATCOM systems. As with cellular networks, over-the-air + data can be encrypted using, e.g., the algorithms in [ETSI-TS-2011]. + Because the operator may not enable this [SSP-2020], the applications + should apply cryptographic protection. The use of FEC or Network + Coding in SATCOM comes with risks (e.g., a single corrupted redundant + packet may propagate to several flows when they are protected + together in an interflow coding approach; see Section 3). While this + document does not further elaborate on this, the security + considerations discussed in [RFC6363] apply. + +9. Informative References + + [5G-CORE-YANG] + Chen, C. and A. Pan, "Yang Data Model for Cloud Native 5G + Core structure", Work in Progress, Internet-Draft, draft- + chin-nfvrg-cloud-5g-core-structure-yang-00, 28 December + 2017, <https://tools.ietf.org/html/draft-chin-nfvrg-cloud- + 5g-core-structure-yang-00>. + + [ASMS2010] "Demonstration at opening session of ASMS 2010", 5th + Advanced Satellite Multimedia Systems (ASMS) Conference, + 2010. + + [CCSDS-131.5-O-1] + The Consultative Committee for Space Data Systems, + "Erasure Correcting Codes for Use in Near-Earth and Deep- + Space Communications", Experimental Specification + CCSDS 131.5-0-1, November 2014. + + [ETSI-EN-2020] + ETSI, "Digital Video Broadcasting (DVB); Second Generation + DVB Interactive Satellite System (DVB-RCS2); Part 2: Lower + Layers for Satellite standard", ETSI EN 301 545-2 V1.3.1, + July 2020. + + [ETSI-TR-2017] + ETSI, "Satellite Earth Stations and Systems (SES); Multi- + link routing scheme in hybrid access network with + heterogeneous links", ETSI TR 103 351 V1.1.1, July 2017. + + [ETSI-TS-2011] + ETSI, "Digital Video Broadcasting (DVB); Content + Protection and Copy Management (DVB-CPCM); Part 5: CPCM + Security Toolbox", ETSI TS 102 825-5 V1.2.1, February + 2011. + + [NETCOD-FUNCTION-VIRT] + Vazquez-Castro, M., Do-Duy, T., Romano, S. P., and A. M. + Tulino, "Network Coding Function Virtualization", Work in + Progress, Internet-Draft, draft-vazquez-nfvrg-netcod- + function-virtualization-02, 16 November 2017, + <https://tools.ietf.org/html/draft-vazquez-nfvrg-netcod- + function-virtualization-02>. + + [NWCRG-CODING] + Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Coding + and congestion control in transport", Work in Progress, + Internet-Draft, draft-irtf-nwcrg-coding-and-congestion-04, + 30 October 2020, <https://tools.ietf.org/html/draft-irtf- + nwcrg-coding-and-congestion-04>. + + [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, + DOI 10.17487/RFC1122, October 1989, + <https://www.rfc-editor.org/info/rfc1122>. + + [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. + Shelby, "Performance Enhancing Proxies Intended to + Mitigate Link-Related Degradations", RFC 3135, + DOI 10.17487/RFC3135, June 2001, + <https://www.rfc-editor.org/info/rfc3135>. + + [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, + R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant + Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, + April 2007, <https://www.rfc-editor.org/info/rfc4838>. + + [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, + "NACK-Oriented Reliable Multicast (NORM) Transport + Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, + <https://www.rfc-editor.org/info/rfc5740>. + + [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error + Correction (FEC) Framework", RFC 6363, + DOI 10.17487/RFC6363, October 2011, + <https://www.rfc-editor.org/info/rfc6363>. + + [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, + "FLUTE - File Delivery over Unidirectional Transport", + RFC 6726, DOI 10.17487/RFC6726, November 2012, + <https://www.rfc-editor.org/info/rfc6726>. + + [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, + F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., + Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and + S. Sivakumar, "Taxonomy of Coding Techniques for Efficient + Network Communications", RFC 8406, DOI 10.17487/RFC8406, + June 2018, <https://www.rfc-editor.org/info/rfc8406>. + + [RFC8681] Roca, V. and B. Teibi, "Sliding Window Random Linear Code + (RLC) Forward Erasure Correction (FEC) Schemes for + FECFRAME", RFC 8681, DOI 10.17487/RFC8681, January 2020, + <https://www.rfc-editor.org/info/rfc8681>. + + [SAT2017] Ahmed, T., Dubois, E., Dupé, JB., Ferrús, R., Gélard, P., + and N. Kuhn, "Software-defined satellite cloud RAN", + International Journal of Satellite Communications and + Networking, Vol. 36, DOI 10.1002/sat.1206, 2 February + 2017, <https://doi.org/10.1002/sat.1206>. + + [SHINE] Romano, S., Roseti, C., and A. Tulino, "SHINE: Secure + Hybrid In Network caching Environment", International + Symposium on Networks, Computers and Communications + (ISNCC), DOI 10.1109/ISNCC.2018.8530996, June 2018, + <https://ieeexplore.ieee.org/document/8530996>. + + [SSP-2020] Pavur, J., Moser, D., Strohmeier, M., Lenders, V., and I. + Martinovic, "A Tale of Sea and Sky On the Security of + Maritime VSAT Communications", IEEE Symposium on Security + and Privacy, DOI 10.1109/SP40000.2020.00056, 2020, + <https://doi.org/10.1109/SP40000.2020.00056>. + + [THAI15] Thai, T., Chaganti, V., Lochin, E., Lacan, J., Dubois, E., + and P. Gelard, "Enabling E2E reliable communications with + adaptive re-encoding over Delay Tolerant Networks", IEEE + International Conference on Communications, + DOI 10.1109/ICC.2015.7248441, June 2015, + <https://doi.org/10.1109/ICC.2015.7248441>. + +Acknowledgements + + Many thanks to John Border, Stuart Card, Tomaso de Cola, Marie-Jose + Montpetit, Vincent Roca, and Lloyd Wood for their help in writing + this document. + +Authors' Addresses + + Nicolas Kuhn (editor) + CNES + 18 avenue Edouard Belin + 31400 Toulouse + France + + Email: nicolas.kuhn@cnes.fr + + + Emmanuel Lochin (editor) + ENAC + 7 avenue Edouard Belin + 31400 Toulouse + France + + Email: emmanuel.lochin@enac.fr |