doc: Add RFC documents

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