rfc8975xml2.original.xml   rfc8975.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc
category="info"
docName="draft-irtf-nwcrg-network-coding-satellites-15"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-nwcrg-networ
<!-- The abbreviated title is used in the page header - it is only necessary k-coding-satellites-15"
if the number="8975" ipr="trust200902" obsoletes="" updates="" submissionType="IRTF" ca
full title is longer than 39 characters --> tegory="info"
consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sor
tRefs="true"
version="3">
<title abbrev="Network coding for satellite systems">Network coding for sate llite systems</title> <!-- xml2rfc v2v3 conversion 3.5.0 -->
<front>
<title abbrev="Network Coding for Satellite Systems">Network Coding for Sate
llite Systems</title>
<seriesInfo name="RFC" value="8975"/>
<author role="editor" fullname="Nicolas Kuhn" initials="N" surname="Kuhn"> <author role="editor" fullname="Nicolas Kuhn" initials="N" surname="Kuhn">
<organization>CNES</organization> <organization>CNES</organization>
<address> <address>
<postal> <postal>
<street>18 avenue Edouard Belin</street> <street>18 avenue Edouard Belin</street>
<city>Toulouse</city> <city>Toulouse</city>
<region></region> <region/>
<code>31400</code> <code>31400</code>
<country>France</country> <country>France</country>
</postal> </postal>
<phone></phone> <phone/>
<email>nicolas.kuhn@cnes.fr</email> <email>nicolas.kuhn@cnes.fr</email>
</address> </address>
</author> </author>
<author role="editor" fullname="Emmanuel Lochin" initials="E" surname="Lochi n"> <author role="editor" fullname="Emmanuel Lochin" initials="E" surname="Lochi n">
<organization>ENAC</organization> <organization>ENAC</organization>
<address> <address>
<postal> <postal>
<street>7 avenue Edouard Belin</street> <street>7 avenue Edouard Belin</street>
<city>Toulouse</city> <city>Toulouse</city>
<region></region> <region/>
<code>31400</code> <code>31400</code>
<country>France</country> <country>France</country>
</postal> </postal>
<phone></phone> <phone/>
<email>emmanuel.lochin@enac.fr</email> <email>emmanuel.lochin@enac.fr</email>
</address> </address>
</author> </author>
<date year="2021" month="January" />
<date year="2020" />
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2
rfc will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Transport</area> <area>Transport</area>
<workgroup>Coding for Efficient Network Communications</workgroup>
<workgroup>NetWork Communications Research Group (NWCRG)</workgroup> <keyword>SATCOM</keyword>
<keyword>coding techniques</keyword>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. --
>
<keyword>SATCOM, coding techniques</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<!-- ######################################################-->
<!-- ######################################################-->
<!-- Head of the document -->
<!-- ######################################################-->
<!-- ######################################################-->
<abstract> <abstract>
<t>This document is one product of the Coding for Efficient Network C
ommunications Research Group (NWCRG). It conforms to the directions found in the <t>This document is a product of the Coding for Efficient Network Communic
NWCRG taxonomy.</t> ations Research Group (NWCRG). It conforms to the directions found in the NWCRG
<t>The objective is to contribute to a larger deployment of network c taxonomy (RFC 8406).</t>
oding techniques in and above the network layer in satellite communication syste <t>The objective is to contribute to a larger deployment of Network Coding
ms. The document also identifies open research issues related to the deployment techniques in and above the network layer in satellite communication systems. T
of network coding in satellite communication systems.</t> his document also identifies open research issues related to the deployment of N
etwork Coding in satellite communication systems.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sec_introduction" numbered="true" toc="default">
<section anchor="sec:introduction" title="Introduction"> <name>Introduction</name>
<t>This document is one product of and represents the collaborative work <t>This document is a product of and represents the collaborative work and
and consensus of the Coding for Efficient Network Communications Research Group consensus of the Coding for Efficient Network Communications Research Group (NW
(NWCRG); while it is not an IETF product and not a standard it intends to inform CRG); while it is not an IETF product and not a standard, it is intended to info
the SATellite COMmunication (SATCOM) and Internet research communities about re rm the SATellite COMmunication (SATCOM) and Internet research communities about
cent developments in Network Coding. A glossary is included in <xref target="sec recent developments in Network Coding. A glossary is included in <xref target="s
:glossary"></xref> to clarify the terminology use throughout the document.</t> ec_glossary" format="default"/> to clarify the terminology used throughout the d
<t>As will be shown in this document, the implementation of network codin ocument.</t>
g techniques above the network layer, at application or transport layers (as des <t>As will be shown in this document, the implementation of Network Coding
cribed in <xref target="RFC1122"></xref>), offers an opportunity for improving t techniques above the network layer, at application or transport layers (as desc
he end-to-end performance of SATCOM systems. While physical- and link-layer codi ribed in <xref target="RFC1122" format="default"/>), offers an opportunity for i
ng error protection is usually enough to provide Quasi-Error Free transmission t mproving the end-to-end performance of SATCOM systems. Physical- and link-layer
hus minimizing packet loss, when residual errors at those layers cause packet lo coding error protection is usually enough to provide quasi-error-free transmissi
sses, retransmissions add significant delays (in particular in geostationary sys on, thus minimizing packet loss. However, when residual errors at those layers c
tems with over 0.7 second round-trip delays). Hence the use of network coding at ause packet losses, retransmissions add significant delays (in particular, in ge
the upper layers can improve the quality of service in SATCOM subnetworks and e ostationary systems with over 0.7 second round-trip delays). Hence, the use of N
ventually favorably impact the experience of end users.</t> etwork Coding at the upper layers can improve the quality of service in SATCOM s
<t>While there is an active research community working on network coding ubnetworks and eventually favorably impact the experience of end users.</t>
techniques above the network layer in general and in SATCOM in particular, not m <t>While there is an active research community working on Network Coding t
uch of this work has been deployed in commercial systems. In this context, this echniques above the network layer in general and in SATCOM in particular, not mu
document identifies opportunities for further usage of network coding in commerc ch of this work has been deployed in commercial systems. In this context, this d
ial SATCOM networks.</t> ocument identifies opportunities for further usage of Network Coding in commerci
<t>The notation used in this document is based on the NWCRG taxonomy <xre al SATCOM networks.</t>
f target="RFC8406"> </xref>:<list style="symbols"> <t>The notation used in this document is based on the NWCRG taxonomy <xref
<t>Channel and link error correcting codes are considered part of target="RFC8406" format="default"> </xref>:</t>
the PHYsical (PHY) layer error protection and are out of the scope of this docu <ul spacing="normal">
ment.</t> <li>Channel and link error-correcting codes are considered part of the e
<t>Forward Erasure Correction (FEC) (also called Application-Leve rror protection for the PHYsical (PHY) layer and are out of the scope of this do
l FEC) operates above the link layer and targets packet loss recovery.</t> cument.</li>
<t>This document considers only coding (or coding techniques or c <li>Forward Erasure Correction (FEC) (also called "Application-Level FEC
oding schemes) that use a linear combination of packets and excludes for example ") operates above the link layer and targets packet-loss recovery.</li>
content coding (e.g., to compress a video flow) or other non-linear operation.< <li>This document considers only coding (or coding techniques or coding
/t> schemes) that uses a linear combination of packets; it excludes, for example, co
</list></t> ntent coding (e.g., to compress a video flow) or other non-linear operations.</l
i>
<!-- <t>Reliability is an inherent part of the physical-layer and usually </ul>
achieved by using coding techniques. Based on public information, coding does n
ot seem to be widely used at higher layers.</t> -->
<!-- <t>This memo presents use-cases where network coding schemes could i
mprove the overall performance of a SATCOM system (e.g. considering a more effic
ient usage of the satellite resource, delivery delay, delivery ratio).</t> -->
<!-- <section anchor="subsec:intro_requi" title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "S
HOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are
to be interpreted as described in <xref target="RFC2119">RFC&nbsp;2119</xref>.</
t>
</section> -->
</section> </section>
<!-- ######################################################--> <section anchor="sec_sat_topo" numbered="true" toc="default">
<!-- ######################################################--> <name>A Note on the Topology of Satellite Networks</name>
<!-- Body of the document --> <t>There are multiple SATCOM systems, for example, broadcast TV, point-to
<!-- ######################################################--> point-communication, and Internet of Things (IoT) monitoring. Therefore, dependi
<!-- ######################################################--> ng on the purpose of the system, the associated ground segment architecture will
be different. This section focuses on a satellite system that follows the Europ
<!-- ######################################################--> ean Telecommunications Standards Institute (ETSI) Digital Video Broadcasting (DV
<!-- New section --> B) standards to provide broadband Internet access via ground-based gateways <xre
<!-- ######################################################--> f target="ETSI-EN-2020" format="default"/>. One must note that the overall data
capacity of one satellite may be higher than the capacity that one single gatewa
y supports. Hence, there are usually multiple gateways for one unique satellite
platform.</t>
<section anchor="sec:sat_topo" title="A Note on Satellite Networks Topol <t>In this context, <xref target="fig_sat_gateway" format="default"/> show
ogy"> s an example of a multigateway satellite system, where BBFRAME stands for "Base-
<t>There are multiple SATCOM systems, for example broadcast TV, p Band FRAME", PLFRAME for "Physical Layer FRAME", and PEP for "Performance Enhanc
oint to point communication or IoT monitoring. Therefore, depending on the purpo ing Proxy". More information on a generic SATCOM ground segment architecture for
se of the system, the associated ground segment architecture will be different. bidirectional Internet access can be found in <xref target="SAT2017" format="de
This section focuses on a satellite system that follows the European Telecommuni fault"/> or in DVB standard documents.</t>
cations Standards Institute (ETSI) Digital Video Broadcasting (DVB) standards to <figure anchor="fig_sat_gateway">
provide broadband Internet access via ground-based gateways <xref target="ETSIE
N2014"></xref>. One must note that the overall data capacity of one satellite ma
y be higher than the capacity that one single gateway supports. Hence, there are
usually multiple gateways for one unique satellite platform.</t>
<t>In this context, <xref target="fig:sat_gateway"></xref> shows an exam
ple of a multi-gateway satellite system, where BBFRAME stands for Base-Band FRAM
E, PLFRAME for Physical Layer FRAME and PEP for Performance Enhancing Proxy. Mor
e information on a generic SATCOM ground segment architecture for bidirectional
Internet access can be found in <xref target="SAT2017"></xref>.</t>
<figure anchor="fig:sat_gateway" title="Data plane functions in a generic <name>Data-Plane Functions in a Generic Satellite Multigateway System</n
satellite multi-gateway system. More details can be found in DVB standard docum ame>
ents."> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
+--------------------------+ +--------------------------+
| application servers | | application servers |
| (data, coding, multicast)| | (data, coding, multicast)|
+--------------------------+ +--------------------------+
| ... | | ... |
----------------------------------- -----------------------------------
| | | | | | | | | | | |
+--------------------+ +--------------------+ +---------------------+ +---------------------+
| network function | | network function | | network function | | network function |
|(firewall, PEP, etc)| |(firewall, PEP, etc)| |(firewall, PEP, etc.)| |(firewall, PEP, etc.)|
+--------------------+ +--------------------+ +---------------------+ +---------------------+
| ... | IP packets | ... | | ... | IP packets | ... |
--- ---
+------------------+ +------------------+ | +------------------+ +------------------+ |
| access gateway | | access gateway | | | access gateway | | access gateway | |
+------------------+ +------------------+ | +------------------+ +------------------+ |
| BBFRAME | | gateway | BBFRAME | | gateway
+------------------+ +------------------+ | +------------------+ +------------------+ |
| physical gateway | | physical gateway | | | physical gateway | | physical gateway | |
+------------------+ +------------------+ | +------------------+ +------------------+ |
--- ---
skipping to change at line 175 skipping to change at line 120
+------------------+ +------------------+ +------------------+ +------------------+
| sat terminals | | sat terminals | | sat terminals | | sat terminals |
+------------------+ +------------------+ +------------------+ +------------------+
| | | | | | | |
+----------+ | +----------+ | +----------+ | +----------+ |
|end user 1| | |end user 3| | |end user 1| | |end user 3| |
+----------+ | +----------+ | +----------+ | +----------+ |
+----------+ +----------+ +----------+ +----------+
|end user 2| |end user 4| |end user 2| |end user 4|
+----------+ +----------+ +----------+ +----------+
</artwork> ]]></artwork>
</figure> </figure>
</section>
</section>
<!-- ######################################################-->
<!-- New section -->
<!-- ######################################################-->
<section anchor="sec:use_cases" title="Use-cases for Improving SATCOM Sy
stem Performance Using Network Coding">
<t>This section details use-cases where network coding techniques could
improve SATCOM system performance.</t>
<section anchor="subsec:two-way" title="Two-way Relay Channel Mod <section anchor="sec_use_cases" numbered="true" toc="default">
e"> <name>Use Cases for Improving SATCOM System Performance Using Network Codi
<t>This use-case considers two-way communication between end-users, throu ng</name>
gh a satellite link as seen in <xref target="fig:two_way"></xref>.</t> <t>This section details use cases where Network Coding techniques could im
<t>Satellite terminal A sends a packet flow A and satellite terminal B s prove SATCOM system performance.</t>
ends a packet flow B to a coding server. The coding server then sends a combinat <section anchor="subsec_two-way" numbered="true" toc="default">
ion of both flows instead of each individual flows. This results in non-negligib <name>Two-Way Relay Channel Mode</name>
le capacity savings that has been demonstrated in the past <xref target="ASMS201 <t>This use case considers two-way communication between end users throu
0"></xref>. In the example, a dedicated coding server is introduced (note that i gh a satellite link, as seen in <xref target="fig_two_way" format="default"/>.</
ts location could be different based on deployment use-case). The network coding t>
operations could also be done at the satellite level, although this would requi <t>Satellite terminal A sends a packet flow A, and satellite terminal B
re a lot of computational resources on-board and may not be supported by today's sends a packet flow B, to a coding server. The coding server then sends a combin
satellites.</t> ation of both flows instead of each individual flow. This results in non-negligi
<figure anchor="fig:two_way" title="Network Architecture for Two-way Rel ble capacity savings, which has been demonstrated in the past <xref target="ASMS
ay Channel using NC"> 2010" format="default"/>. In the example, a dedicated coding server is introduce
<artwork> d (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 th
is would require a lot of computational resources onboard and may not be support
ed by today's satellites.</t>
<figure anchor="fig_two_way">
<name>Network Architecture for Two-Way Relay Channel Using Network Cod
ing </name>
<artwork name="" type="" align="left" alt=""><![CDATA[
-X}- : traffic from satellite terminal X to the server -X}- : traffic from satellite terminal X to the server
={X+Y= : traffic from X and Y combined sent from ={X+Y= : traffic from X and Y combined sent from
the server to terminals X and Y the server to terminals X and Y
+-----------+ +-----+ +-----------+ +-----+
|Sat term A |--A}-+ | | |Sat term A |--A}-+ | |
+-----------+ | | | +---------+ +------+ +-----------+ | | | +---------+ +------+
^^ +--| |--A}--| |--A}--|Coding| ^^ +--| |--A}--| |--A}--|Coding|
|| | SAT |--B}--| Gateway |--B}--|Server| || | SAT |--B}--| Gateway |--B}--|Server|
===={A+B=========| |={A+B=| |={A+B=| | ===={A+B=========| |={A+B=| |={A+B=| |
|| | | +---------+ +------+ || | | +---------+ +------+
vv +--| | vv +--| |
+-----------+ | | | +-----------+ | | |
|Sat term B |--B}-+ | | |Sat term B |--B}-+ | |
+-----------+ +-----+ +-----------+ +-----+
</artwork> ]]></artwork>
</figure> </figure>
</section>
</section> <section anchor="subsec_rel-mul" numbered="true" toc="default">
<name>Reliable Multicast</name>
<section anchor="subsec:rel-mul" title="Reliable Multicast"> <t>The use of multicast servers is one way to better utilize satellite b
roadcast capabilities. As one example, satellite-based multicast is proposed in
<t>The use of multicast servers is one way to better utilize satellite br the Secure Hybrid In Network caching Environment (SHINE) project of the European
oadcast capabilities. As one example satellite-based multicast is proposed in th Space Agency (ESA) <xref target="I-D.vazquez-nfvrg-netcod-function-virtualizati
e SHINE ESA project <xref target="I-D.vazquez-nfvrg-netcod-function-virtualizati on" format="default"> </xref> <xref target="SHINE" format="default"> </xref>. Th
on"> </xref> <xref target="SHINE"> </xref>. This use-case considers adding redun is use case considers adding redundancy to a multicast flow depending on what ha
dancy to a multicast flow depending on what has been received by different end-u s been received by different end users, resulting in non-negligible savings of t
sers, resulting in non-negligible savings of the scarce SATCOM resources. This s he scarce SATCOM resources. This scenario is shown in <xref target="fig_rel_mult
cenario is shown in <xref target="fig:rel_multi"></xref>.</t> i" format="default"/>.</t>
<figure anchor="fig_rel_multi">
<figure anchor="fig:rel_multi" title="Network Architecture for a Reliabl <name>Network Architecture for a Reliable Multicast Using Network Codi
e Multicast using NC"> ng</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
-Li}- : packet indicating the loss of packet i of a multicast flow M -Li}- : packet indicating the loss of packet i of a multicast flow M
={M== : multicast flow including the missing packets ={M== : multicast flow including the missing packets
+-----------+ +-----+ +-----------+ +-----+
|Terminal A |-Li}-+ | | |Terminal A |-Li}-+ | |
+-----------+ | | | +---------+ +------+ +-----------+ | | | +---------+ +------+
^^ +-| |-Li}--| | |Multi | ^^ +-| |-Li}--| | |Multi |
|| | SAT |-Lj}--| Gateway |--|Cast | || | SAT |-Lj}--| Gateway |--|Cast |
===={M==========| |={M===| | |Server| ===={M==========| |={M===| | |Server|
|| | | +---------+ +------+ || | | +---------+ +------+
vv +-| | vv +-| |
+-----------+ | | | +-----------+ | | |
|Terminal B |-Lj}-+ | | |Terminal B |-Lj}-+ | |
+-----------+ +-----+ +-----------+ +-----+
</artwork> ]]></artwork>
</figure> </figure>
<t>A multicast flow (M) is forwarded to both satellite terminals A and B. <t>A multicast flow (M) is forwarded to both satellite terminals A and B
However packet Ni (respectively Nj) gets lost at terminal A (respectively B), a . M is composed of packets Nk (not shown in <xref target="fig_rel_multi" format=
nd terminal A (respectively B) returns a negative acknowledgment Li (respectivel "default"/>). Packet Ni (respectively Nj) gets lost at terminal A (respectively
y Lj), indicating that the packet is missing. Using coding, either the access ga B), and terminal A (respectively B) returns a negative acknowledgment Li (respec
teway or the multicast server can include a repair packet (rather than the indiv tively Lj), indicating that the packet is missing. Using coding, either the acce
idual Ni and Nj packets) in the multicast flow to let both terminals recover fro ss gateway or the multicast server can include a repair packet (rather than the
m losses.</t> individual Ni and Nj packets) in the multicast flow to let both terminals recove
<t>This could also be achieved by using other multicast or broadcast syst r from losses.</t>
ems, such as NACK-Oriented Reliable Multicast (NORM) <xref target="RFC5740"></xr
ef> or File Delivery over Unidirectional Transport (FLUTE) <xref target ="RFC672
6"></xref>. Both NORM and FLUTE are limited to block coding; neither of them sup
port more flexible sliding window encoding schemes that allow decoding before re
ceiving the whole block an added delay benefit <xref target="RFC8406"></xref><xr
ef target="RFC8681"></xref>.</t>
</section>
<section anchor="subsec:hybrid" title="Hybrid Access"> <t>This could also be achieved by using other multicast or broadcast sys
<t>This use-case considers improving multiple path communications with ne tems, such as NACK-Oriented Reliable Multicast (NORM) <xref target="RFC5740" for
twork coding at the transport layer (see <xref target="fig:hyb_access"></xref>, mat="default"/> or File Delivery over Unidirectional
where DSL stands for Digital Subscriber Line, LTE for Long Term Evolution and SA Transport (FLUTE) <xref target="RFC6726" format="default"/>. Both NORM and FLUTE
T for SATellite). This use-case is inspired by the Broadband Access via Integrat are limited to block coding; neither of them supports more flexible sliding win
ed Terrestrial Satellite Systems (BATS) project and has been published as an ETS dow encoding schemes that allow decoding before receiving the whole block, which
I Technical Report <xref target="ETSITR2017"></xref>.</t> is an added delay benefit <xref target="RFC8406" format="default"/> <xref targe
<t>To cope with packet loss (due to either end-user mobility or physical- t="RFC8681" format="default"/>.</t>
layer residual errors), network coding can be introduced. Depending on the proto </section>
col, network coding could be applied at each of the Customer Premises Equipment <section anchor="subsec_hybrid" numbered="true" toc="default">
(CPE) and at the concentrator or both. Apart from packet losses, other gains fro <name>Hybrid Access</name>
m this approach include a better tolerance to out-of-order packet delivery which <t>This use case considers improving multiple-path communications with N
occur when exploited links exhibit high asymmetry in terms of Round-Trip Time ( etwork Coding at the transport layer (see <xref target="fig_hyb_access" format="
RTT). Depending on the ground architecture <xref target="I-D.chin-nfvrg-cloud-5g default"/>, where DSL stands for "Digital Subscriber Line", LTE for "Long Term E
-core-structure-yang"></xref> <xref target="SAT2017"></xref>, some ground equipm volution", and SAT for "SATellite"). This use case is inspired by the Broadband
ent might be hosting both SATCOM and cellular network functionality.</t> Access via Integrated Terrestrial Satellite Systems (BATS) project and has been
published as an ETSI Technical Report <xref target="ETSI-TR-2017" format="defaul
t"/>.</t>
<t>To cope with packet loss (due to either end-user mobility or physical
-layer residual errors), Network Coding can be introduced. Depending on the prot
ocol, Network Coding could be applied at the Customer Premises Equipment (CPE),
the concentrator, or both.
<figure anchor="fig:hyb_access" title="Network Architecture for a Hybrid Apart from coping with packet loss, other benefits of this approach include a be
Access Using Network Coding"> tter tolerance for out-of-order packet delivery, which occurs when exploited lin
<artwork> ks exhibit high asymmetry in terms of Round-Trip Time (RTT). Depending on the gr
ound architecture <xref target="I-D.chin-nfvrg-cloud-5g-core-structure-yang" for
mat="default"/> <xref target="SAT2017" format="default"/>, some ground equipment
might be hosting both SATCOM and cellular network functionality.</t>
<figure anchor="fig_hyb_access">
<name>Network Architecture for Hybrid Access Using Network Coding</nam
e>
<artwork name="" type="" align="left" alt=""><![CDATA[
-{}- : bidirectional link -{}- : bidirectional link
+---+ +--------------+ +---+ +--------------+
+-{}-|SAT|-{}-|BACKBONE | +-{}-|SAT|-{}-|BACKBONE |
+----+ +---+ | +---+ |+------------+| +----+ +---+ | +---+ |+------------+|
|End |-{}-|CPE|-{}-| ||CONCENTRATOR|| |End |-{}-|CPE|-{}-| ||CONCENTRATOR||
|User| +---+ | +---+ |+------------+| +-----------+ |User| +---+ | +---+ |+------------+| +-----------+
+----+ |-{}-|DSL|-{}-| |-{}-|Application| +----+ |-{}-|DSL|-{}-| |-{}-|Application|
| +---+ | | |Server | | +---+ | | |Server |
| | | +-----------+ | | | +-----------+
| +---+ | | | +---+ | |
+-{}-|LTE|-{}-+--------------+ +-{}-|LTE|-{}-+--------------+
+---+ +---+
</artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="subsec_varying_wifi" numbered="true" toc="default">
<section anchor="subsec:varying_wifi" title="LAN Packet Losses"> <name>LAN Packet Losses</name>
<t>This use-case considers using network coding in the scenario where a l <t>This use case considers using Network Coding in the scenario where a
ossy WIFI link is used to connect to the SATCOM network. When encrypted end-to-e lossy WiFi link is used to connect to the SATCOM network. When encrypted end-to-
nd applications based on UDP are used, a Performance Enhancing Proxy (PEP) canno end applications based on UDP are used, a Performance Enhancing Proxy (PEP) cann
t operate hence other mechanism need to be used. The WIFI packet losses will res ot operate; hence, other mechanisms need to be used. The WiFi packet losses will
ult in an end-to-end retransmission that will harm the end-user quality of exper result in an end-to-end retransmission that will harm the quality of the end us
ience and poorly utilize SATCOM bottleneck resource for non-revenue generating t er's experience and poorly utilize SATCOM bottleneck resources for traffic that
raffic. In this use-case, adding network coding techniques will prevent the end- does not generate revenue. In this use case, adding Network Coding techniques wi
to-end retransmission from occurring since the packet losses would probably be r ll prevent the end-to-end retransmission from occurring since the packet losses
ecovered.</t> would probably be recovered.</t>
<t>The architecture is shown in <xref target="fig:varying_wifi-loss"></xr <t>The architecture is shown in <xref target="fig_varying_wifi-loss" for
ef>.</t> mat="default"/>.</t>
<figure anchor="fig_varying_wifi-loss">
<figure anchor="fig:varying_wifi-loss" title="Network Architecture for d <name>Network Architecture for Dealing with LAN Losses</name>
ealing with LAN Losses"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
-{}- : bidirectional link -{}- : bidirectional link
-''- : Wi-Fi link -''- : WiFi link
C : where network coding techniques could be introduced C : where Network Coding techniques could be introduced
+----+ +--------+ +---+ +-------+ +-------+ +--------+ +----+ +--------+ +---+ +-------+ +-------+ +--------+
|End | |Sat. | |SAT| |Phy | |Access | |Network | |End | |Sat. | |SAT| |Phy | |Access | |Network |
|user|-''-|Terminal|-{}-| |-{}-|Gateway|-{}-|Gateway|-{}-|Function| |user|-''-|Terminal|-{}-| |-{}-|Gateway|-{}-|Gateway|-{}-|Function|
+----+ +--------+ +---+ +-------+ +-------+ +--------+ +----+ +--------+ +---+ +-------+ +-------+ +--------+
C C C C C C C C
</artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="subsec_varying" numbered="true" toc="default">
<section anchor="subsec:varying" title="Varying Channel Condition <name>Varying Channel Conditions</name>
s"> <t>This use case considers the usage of Network Coding to cope with subs
<t>This use-case considers the usage of network coding to cope with sub s econd physical channel condition changes where the physical-layer mechanisms (Ad
econd physical channel condition changes where the physical-layer mechanisms (Ad aptive Coding and Modulation (ACM)) may not adapt the modulation and error-corre
aptive Coding and Modulation (ACM)) may not adapt the modulation and error-corre ction coding in time; the residual errors lead to higher-layer packet losses tha
ction coding in time: the residual errors lead to higher layer packet losses tha t can be recovered with Network Coding. This use case is mostly relevant when mo
t can be recovered with network coding. This use-case is mostly relevant when mo bile users are considered or when the satellite frequency band introduces quick
bile 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 ca
changes in channel condition (Q/V bands, Ka band, etc.). Depending on the use-ca se (e.g., bands with very high frequency, mobile users), the relevance of adding
se (e.g., very high frequency bands, mobile users), the relevance of adding netw Network Coding is different.</t>
ork coding is different.</t> <t>The system architecture is shown in <xref target="fig_varying_capa" f
<t>The system architecture is shown in <xref target="fig:varying_capa"></ ormat="default"/>.</t>
xref>.</t> <figure anchor="fig_varying_capa">
<name>Network Architecture for Dealing with Varying Link Characteristi
<figure anchor="fig:varying_capa" title="Network Architecture for dealin cs</name>
g with Varying Link Characteristics"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
-{}- : bidirectional link -{}- : bidirectional link
C : where network coding techniques could be introduced C : where Network Coding techniques could be introduced
+---------+ +---+ +--------+ +-------+ +--------+ +---------+ +---+ +--------+ +-------+ +--------+
|Satellite| |SAT| |Physical| |Access | |Network | |Satellite| |SAT| |Physical| |Access | |Network |
|Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function| |Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function|
+---------+ +---+ +--------+ +-------+ +--------+ +---------+ +---+ +--------+ +-------+ +--------+
C C C C C C C C
</artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="subsec_gat_hand" numbered="true" toc="default">
<section anchor="subsec:gat_hand" title="Improving Gateway Handov <name>Improving Gateway Handover</name>
er"> <t>This use case considers the recovery of packets that may be lost duri
<t>This use-case considers the recovery of packets that may be lost durin ng gateway handover. Whether for off-loading a given equipment or because the tr
g gateway handover. Whether for off-loading a given equipment or because the tra ansmission quality differs from gateway to gateway, switching the transmission g
nsmission quality differs from gateway to gateway, switching the transmission ga ateway may be beneficial. However, packet losses can occur if the gateways are n
teway may be beneficial. However, packet losses can occur if the gateways are no ot properly synchronized or if the algorithm used to trigger gateway handover is
t properly synchronized or if the algorithm used to trigger gateway handover is not properly tuned. During these critical phases, Network Coding can be added t
not properly tuned. During these critical phases, network coding can be added to o improve the reliability of the transmission and allow a seamless gateway hando
improve the reliability of the transmission and allow a seamless gateway handov ver.</t>
er.</t> <t><xref target="fig_gat_hand" format="default"/> illustrates this use c
<t><xref target="fig:gat_hand"></xref> illustrates this use-case.</t> ase.</t>
<figure anchor="fig_gat_hand">
<figure anchor="fig:gat_hand" title="Network Architecture for dealing wi <name>Network Architecture for Dealing with Gateway Handover</name>
th Gateway Handover"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
-{}- : bidirectional link -{}- : bidirectional link
! : management interface ! : management interface
C : where network coding techniques could be introduced C : where Network Coding techniques could be introduced
C C C C
+--------+ +-------+ +--------+ +--------+ +-------+ +--------+
|Physical| |Access | |Network | |Physical| |Access | |Network |
+-{}-|gateway |-{}-|gateway|-{}-|function| +-{}-|gateway |-{}-|gateway|-{}-|function|
| +--------+ +-------+ +--------+ | +--------+ +-------+ +--------+
| ! ! | ! !
+---------+ +---+ +---------------+ +---------+ +---+ +---------------+
|Satellite| |SAT| | Control plane | |Satellite| |SAT| | Control-plane |
|Terminal |-{}-| | | manager | |Terminal |-{}-| | | manager |
+---------+ +---+ +---------------+ +---------+ +---+ +---------------+
| ! ! | ! !
| +--------+ +-------+ +--------+ | +--------+ +-------+ +--------+
+-{}-|Physical|-{}-|Access |-{}-|Network | +-{}-|Physical|-{}-|Access |-{}-|Network |
|gateway | |gateway| |function| |gateway | |gateway| |function|
+--------+ +-------+ +--------+ +--------+ +-------+ +--------+
C C C C
</artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section>
</section>
<!-- ######################################################-->
<!-- New section -->
<!-- ######################################################-->
<section anchor="sec:deploy" title="Research Challenges">
<t>This section proposes a few potential approaches to introduce and use
network coding in SATCOM systems.</t>
<section anchor="sec:deploy_pep" title="Joint-use of Network Coding and C
ongestion Control in SATCOM Systems">
<t>Many SATCOM systems typically use Performance Enhancing Proxy (PEP) <x
ref target="RFC3135">RFC&nbsp;3135</xref>. PEPs usually split end-to-end connect
ions and forward transport or application layer packets to the satellite baseban
d gateway. PEPs contribute to mitigate congestion in a SATCOM systems by limitin
g the impact of long delays on Internet protocols. A PEP mechanism could also in
clude network coding operation and thus support the use-cases that have been dis
cussed in the <xref target="sec:use_cases"></xref> of this document.</t>
<t>Deploying network coding in the PEP could be relevant and be independe
nt from the specifics of a SATCOM link. This however leads to research questions
dealing with the potential interaction between network coding and congestion co
ntrol. This is discussed in <xref target="I-D.irtf-nwcrg-coding-and-congestion">
</xref>.</t>
</section>
<section anchor="sec:deploy_coding" title="Efficient Use of Satellite Res
ources">
<t>There is a recurrent trade-off in SATCOM systems: how much overhead fr
om redundant reliability packets can be introduced to guarantee a better end-use
r QoE while optimizing capacity usage? At which layer this supplementary redunda
ncy should be added?</t>
<t>This problem has been tackled in the past by the deployment of physica
l-layer error-correction codes, but there remains questions on adapting the codi
ng overhead and added delay for, e.g., the quickly varying channel conditions us
e-case where ACM may not be reacting quickly enough as was discussed in <xref ta
rget="subsec:varying"></xref>. The higher layer with network coding does not rea
ct more quickly than the physical layer, but may operate over a packet-based tim
e window that is larger than the physical one.</t>
</section>
<section anchor="sec:deploy_nfv" title="Interaction with Virtualized Sate
llite Gateways and Terminals">
<t>In the emerging virtualized network infrastructure, network coding cou
ld be easily deployed as Virtual Network Functions (VNF). The next generation of
SATCOM ground segments will rely on a virtualized environment to integrate to t
errestrial 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 <xref target="I-D.chin-nfvrg-cloud-5g-c
ore-structure-yang"> </xref>. As one example, the network coding VNF deployment
in a virtualized environment has been presented in <xref target="I-D.vazquez-nfv
rg-netcod-function-virtualization"> </xref>.</t>
<t>A research challenge would be the optimization of the NFV service func
tion chaining, considering a virtualized infrastructure and other SATCOM specifi
c functions, in order to guarantee efficient radio-link usage and provide easy-t
o-deploy SATCOM services. Moreover, another challenge related to a virtualized S
ATCOM equipment is the management of limited buffered capacities in large gatewa
ys.</t>
</section>
<section anchor="subsec:dtn" title="Delay/Disruption Tolerant Networking
(DTN)">
<!-- <t>In the context of deep-space communications, establishing communicatio
ns from terrestrial gateways to satellite platforms can be a challenge. Indeed,
reliable end-to-end (E2E) communications over such links must cope with long del
ay and frequent link disruptions. Delay/Disruption Tolerant Networking <xref tar
get="RFC4838"></xref> is a solution to enable reliable internetworking space com
munications where both standard ad-hoc routing and E2E Internet protocols cannot
be used. The transport of data over such networks requires the use of replicati
on, erasure codes and multipath protocol schemes <xref target="WANG05"></xref> <
xref target="ZHANG06"></xref> to improve the bundle delivery ratio and/or delive
ry delay. For instance, transport protocols such as LTP <xref target="RFC5326"><
/xref> for long delay links with connectivity disruptions, use Automatic Repeat-
reQuest (ARQ) and unequal error protection to reduce the amount of non-mandatory
re-transmissions. The work in <xref target="TOURNOUX10"></xref> proposed upon L
TP a robust streaming method based on an on-the-fly coding scheme, where encodin
g and decoding procedures are done at the source and destination nodes, respecti
vely. However, each link path loss rate may have various order of magnitude and
re-encoding at an intermediate node to adapt the redundancy can be mandatory to
prevent transmission wasting. This idea has been put forward in <xref target="I-
D.zinky-dtnrg-random-binary-fec-scheme"></xref> and <xref target="I-D.zinky-dtnr
g-erasure-coding-extension"></xref>, where the authors proposed an encoding proc
ess at intermediate DTN nodes to explore the possibilities of Forward Error Corr
ection (FEC) schemes inside the bundle protocol <xref target="RFC5050"></xref>.
In this context, the use of erasure coding inside a Consultative Committee for S
pace Data Systems (CCSDS) architecture has been specified in <xref target="CCSDS
-131.5-O-1"></xref>.</t> -->
<t>Communications among deep-space platforms and terrestrial gateways can
be a challenge. Reliable end-to-end (E2E) communications over such paths must c
ope with very long delays and frequent link disruptions; indeed, E2E connectivit
y may only be available intermittently, if at all. Delay/Disruption Tolerant Net
working (DTN) <xref target="RFC4838"></xref> is a solution to enable reliable in
ternetworking space communications where both standard ad-hoc routing and E2E In
ternet protocols cannot be used. Moreover, DTN can also be seen as an alternativ
e solution to transfer data between a central PEP and a remote PEP.</t>
<t>Network Coding enables E2E reliable communications over a DTN with pot
ential adaptive re-encoding, as proposed in <xref target="THAI15"></xref>. Here,
the use-cases proposed in <xref target="subsec:varying"></xref> would encourage
the usage of network coding within the DTN stack to improve the physical channe
l utilization and minimize the effects of the E2E transmission delays. In this c
ontext, the use of packet erasure coding techniques inside a Consultative Commit
tee for Space Data Systems (CCSDS) architecture has been specified in <xref targ
et="CCSDS-131.5-O-1"></xref>. One research challenge remains on how such network
coding can be integrated in the IETF DTN stack.</t>
<!-- The objective is to extend the CCSDS File Delivery Protocol (CFDP) <xref ta <section anchor="sec_deploy" numbered="true" toc="default">
rget="CCSDS-FDP"></xref> with erasure coding capabilities where a Low Density Pa <name>Research Challenges</name>
rity Check (LDPC) <xref target="RFC6816"></xref> code with a large block size is <t>This section proposes a few potential approaches to introducing and usi
chosen. Recently, on-the-fly erasure coding schemes <xref target="LACAN08"></xr ng Network Coding in SATCOM systems.</t>
ef> <xref target="SUNDARARAJAN08"></xref> <xref target="TOURNOUX11"></xref> have <section anchor="sec_deploy_pep" numbered="true" toc="default">
shown their benefits in terms of recovery capability and configuration complexi <name>Joint Use of Network Coding and Congestion Control in SATCOM Syste
ty compared to traditional FEC schemes. Using a feedback path when available, on ms</name>
-the-fly schemes can be used to enable E2E reliable communication over DTN with <t>Many SATCOM systems typically use Performance Enhancing Proxy (PEP) <
adaptive re-encoding as proposed in <xref target="THAI15"></xref>. --> xref target="RFC3135" format="default" />. PEPs usually split end-to-end connect
ions and forward transport or application-layer packets to the satellite baseban
d gateway. PEPs contribute to mitigating congestion in a SATCOM system by limiti
ng the impact of long delays on Internet protocols. A PEP mechanism could also i
nclude Network Coding operation and thus support the use cases that have been di
scussed in <xref target="sec_use_cases" format="default"/> of this document.</t>
<t>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 co
ntrol. This is discussed in <xref target="I-D.irtf-nwcrg-coding-and-congestion"
format="default"/>.</t>
</section>
<section anchor="sec_deploy_coding" numbered="true" toc="default">
<name>Efficient Use of Satellite Resources</name>
<t>There is a recurrent trade-off in SATCOM systems: how much overhead f
rom redundant reliability packets can be introduced to guarantee a better end-us
er Quality of Experience (QoE) while optimizing capacity usage? At which layer s
hould this supplementary redundancy be added?</t>
<t>This problem has been tackled in the past by the deployment of physic
al-layer error-correction codes, but questions remain on adapting the coding ove
rhead and added delay for, e.g., the quickly varying channel conditions use case
where ACM may not be reacting quickly enough, as discussed in <xref target="sub
sec_varying" format="default"/>. A higher layer with Network Coding does not rea
ct more quickly than the physical layer, but it may operate over a packet-based
time window that is larger than the physical one.</t>
</section>
<section anchor="sec_deploy_nfv" numbered="true" toc="default">
<name>Interaction with Virtualized Satellite Gateways and Terminals</nam
e>
</section> <t>In the emerging virtualized network infrastructure, Network Coding co
uld be easily deployed as Virtual Network Functions (VNFs). The next generation
of SATCOM ground segments will rely on a virtualized environment to integrate wi
th terrestrial networks. This trend towards Network Function Virtualization (NFV
) is also central to 5G and next-generation cellular networks, making this resea
rch applicable to other deployment scenarios <xref target="I-D.chin-nfvrg-cloud-
5g-core-structure-yang" format="default"> </xref>. As one example, Network Codin
g VNF deployment in a virtualized environment has been presented in <xref target
="I-D.vazquez-nfvrg-netcod-function-virtualization" format="default"> </xref>.</
t>
<t>A research challenge would be the optimization of the NFV service fun
ction chaining, considering a virtualized infrastructure and other SATCOM-specif
ic functions, in order to guarantee efficient radio-link usage and provide easy-
to-deploy SATCOM services. Moreover, another challenge related to virtualized SA
TCOM equipment is the management of limited buffered capacities in large gateway
s.</t>
</section>
<section anchor="subsec_dtn" numbered="true" toc="default">
<name>Delay/Disruption-Tolerant Networking (DTN)</name>
<t>Communications among deep-space platforms and terrestrial gateways can
be a challenge. Reliable end-to-end (E2E) communications over such paths must c
ope with very long delays and frequent link disruptions; indeed, E2E connectivit
y may only be available intermittently, if at all. Delay/Disruption-Tolerant Net
working (DTN) <xref target="RFC4838" format="default"/> is a solution to enable
reliable internetworking space communications where neither standard ad hoc rout
ing 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.</
t>
<t>Network Coding enables E2E reliable communications over a DTN with po
tential adaptive re-encoding, as proposed in <xref target="THAI15" format="defau
lt"/>. Here, the use case proposed in <xref target="subsec_varying" format="defa
ult"/> would encourage the usage of Network Coding within the DTN stack to impro
ve utilization of the physical channel and minimize the effects of the E2E trans
mission delays. In this context, the use of packet erasure coding techniques ins
ide a Consultative Committee for Space Data Systems (CCSDS) architecture has bee
n specified in <xref target="CCSDS-131.5-O-1" format="default"/>. One research c
hallenge remains: how such Network Coding can be integrated in the IETF DTN stac
k.</t>
</section> </section>
</section>
<!-- ######################################################--> <section anchor="sec_conclu" numbered="true" toc="default">
<!-- New section --> <name>Conclusion</name>
<!-- ######################################################--> <t>This document introduces some wide-scale Network Coding technique oppor
<section anchor="sec:conclu" title="Conclusion"> tunities in satellite telecommunications systems.</t>
<t>Even though this document focuses on satellite systems, it is worth poi
nting out that some scenarios proposed here may be relevant to other wireless te
lecommunication systems. As one example, the generic architecture proposed in <x
ref target="fig_sat_gateway" format="default"/> may be mapped onto cellular netw
orks as follows: the 'network function' block gathers some of the functions of t
he Evolved Packet Core subsystem, while the 'access gateway' and 'physical gatew
ay' 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.</t>
</section>
<t>This document introduces some wide-scale network coding technique opp <section anchor="sec_glossary" numbered="true" toc="default">
ortunities in satellite telecommunications systems.</t> <name>Glossary</name>
<t>Even though this document focuses on satellite systems, it is worth p ointing out that some scenarios proposed here may be relevant to other wireless telecommunication systems. As one example, the generic architecture proposed in <xref target="fig:sat_gateway"></xref> may be mapped onto cellular networks as f ollows: the 'network function' block gathers some of the functions of the Evolve d Packet Core subsystem, while the 'access gateway' and 'physical gateway' block s gather the same type of functions as the Universal Mobile Terrestrial Radio Ac cess Network. This mapping extends the opportunities identified in this document since they may also be relevant for cellular networks.</t> <t>The glossary of this memo extends the definitions of the taxonomy docum ent <xref target="RFC8406" format="default"> </xref> as follows:</t>
</section> <dl newline="false" indent="12">
<dt>ACM:</dt><dd>Adaptive Coding and Modulation</dd>
<dt>BBFRAME:</dt><dd>Base-Band FRAME -- satellite communication Layer 2
encapsulation works as follows: (1) each Layer 3 packet is encapsulated with a G
eneric Stream Encapsulation (GSE) mechanism, (2) GSE packets are gathered to cre
ate BBFRAMEs, (3) BBFRAMEs contain information related to how they have to be mo
dulated, and (4) BBFRAMEs are forwarded to the physical layer.</dd>
<dt>COM:</dt><dd>COMmunication</dd>
<dt>CPE:</dt><dd>Customer Premises Equipment</dd>
<dt>DSL:</dt><dd>Digital Subscriber Line</dd>
<dt>DTN:</dt><dd>Delay/Disruption-Tolerant Networking</dd>
<dt>DVB:</dt><dd>Digital Video Broadcasting</dd>
<dt>E2E:</dt><dd>End-to-End</dd>
<dt>ETSI:</dt><dd>European Telecommunications Standards Institute</dd>
<dt>FEC:</dt><dd>Forward Erasure Correction</dd>
<dt>FLUTE:</dt><dd>File Delivery over Unidirectional Transport <xref tar
get="RFC6726" format="default"/></dd>
<dt>IntraF:</dt><dd>Intra-Flow Coding</dd>
<dt>InterF:</dt><dd>Inter-Flow Coding</dd>
<dt>IoT:</dt><dd>Internet of Things</dd>
<dt>LTE:</dt><dd>Long Term Evolution</dd>
<dt>MPC:</dt><dd>Multi-Path Coding</dd>
<dt>NC:</dt><dd>Network Coding</dd>
<dt>NFV:</dt><dd>Network Function Virtualization -- concept of running s
oftware-defined network functions</dd>
<dt>NORM:</dt><dd>NACK-Oriented Reliable Multicast <xref target="RFC5740
" format="default"/></dd>
<dt>PEP:</dt><dd>Performance Enhancing Proxy <xref target="RFC3135" form
at="default"/> -- a typical PEP for satellite communications includes compressio
n, caching, TCP ACK spoofing, and specific congestion-control tuning.</dd>
<dt>PLFRAME:</dt><dd>Physical Layer FRAME -- modulated version of a BBFR
AME with additional information (e.g., related to synchronization)</dd>
<dt>QEF:</dt><dd>Quasi-Error-Free</dd>
<dt>QoE:</dt><dd>Quality of Experience</dd>
<dt>QoS:</dt><dd>Quality of Service</dd>
<dt>RTT:</dt><dd>Round-Trip Time</dd>
<dt>SAT:</dt><dd>SATellite</dd>
<dt>SATCOM:</dt><dd>Generic term related to all kinds of SATellite-COMmu
nication systems</dd>
<dt>SPC:</dt><dd>Single-Path Coding</dd>
<dt>VNF:</dt><dd>Virtual Network Function -- implementation of a network
function using software.</dd>
</dl>
</section>
<section anchor="sec_IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="sec_ecurity" numbered="true" toc="default">
<name>Security Considerations</name>
<!-- ######################################################--> <t>Security considerations are inherent to any access network, in particul
<!-- ######################################################--> ar SATCOM systems. As with cellular networks, over-the-air data can be encrypted
<!-- Tail of the document --> using, e.g., the algorithms in <xref target="ETSI-TS-2011" format="default"/>.
<!-- ######################################################--> Because the operator may not enable this <xref target="SSP-2020" format="default
<!-- ######################################################--> "/>, the applications should apply cryptographic protection. The use of FEC or N
etwork Coding in SATCOM comes with risks (e.g., a single corrupted redundant pac
ket may propagate to several flows when they are protected together in an interf
low coding approach; see <xref target="sec_use_cases" format="default"/>). While
this document does not further elaborate on this, the security considerations d
iscussed in <xref target="RFC6363" format="default"/> apply.</t>
</section>
</middle>
<section anchor="sec:glossary" title="Glossary"> <back>
<t>The glossary of this memo extends the glossary of the taxonomy
document <xref target="RFC8406"> </xref> as follows:<list style="symbols">
<t>ACM : Adaptive Coding and Modulation;</t>
<t>BBFRAME: Base-Band FRAME - satellite communication layer 2 encapsulati
on work as follows: (1) each layer 3 packet is encapsulated with a Generic Strea
m Encapsulation (GSE) mechanism, (2) GSE packets are gathered to create BBFRAMEs
, (3) BBFRAMEs contain information related to how they have to be modulated (4)
BBFRAMEs are forwarded to the physical-layer;</t>
<t>CPE: Customer Premises Equipment;</t>
<t>COM: COMmunication;</t>
<t>DSL: Digital Subscriber Line;</t>
<t>DTN: Delay/Disruption Tolerant Networking;</t>
<t>DVB: Digital Video Broadcasting;</t>
<t>E2E: End-to-end;</t>
<t>ETSI: European Telecommunications Standards Institute;</t>
<t>FEC: Forward Erasure Correction;</t>
<t>FLUTE: File Delivery over Unidirectional Transport <xref target="RFC67
26"></xref>;</t>
<t>IntraF: Intra-Flow Coding;</t>
<t>InterF: Inter-Flow Coding;</t>
<t>IoT: Internet of Things;</t>
<t>LTE: Long Term Evolution;</t>
<t>MPC: Multi-Path Coding;</t>
<t>NC: Network Coding;</t>
<t>NFV: Network Function Virtualization - concept of running software-de
fined network functions;</t>
<t>NORM: NACK-Oriented Reliable Multicast <xref target="RFC5740"></xref>;
</t>
<t>PEP: Performance Enhancing Proxy <xref target="RFC3135"></xref> - a t
ypical PEP for satellite communications include compression, caching and TCP ACK
spoofing and specific congestion control tuning;</t>
<t>PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME with ad
ditional information (e.g., related to synchronization);</t>
<t>QEF: Quasi-Error-Free;</t>
<t>QoE: Quality-of-Experience;</t>
<t>QoS: Quality-of-Service;</t>
<t>RTT: Round-Trip Time;</t>
<t>SAT: SATellite; </t>
<!--<t>EPC: Evolved Packet Core;</t>-->
<t>SATCOM: generic term related to all kinds of SATellite COMmunication
systems;</t>
<t>SPC: Single-Path Coding;</t>
<t>VNF: Virtual Network Function - implementation of a network function u
sing software.</t>
</list></t>
</section>
<section anchor="sec:acknowledgements" title="Acknowledgements"> <displayreference target="I-D.chin-nfvrg-cloud-5g-core-structure-yang" to="5G-CO
<t>Many thanks to John Border, Stuart Card, Tomaso de Cola, Vincent Roca, RE-YANG"/>
Lloyd Wood and Marie-Jose Montpetit for their help in writing this document.</t <displayreference target="I-D.irtf-nwcrg-coding-and-congestion" to="NWCRG-CODING
> "/>
</section> <displayreference target="I-D.vazquez-nfvrg-netcod-function-virtualization" to="
NETCOD-FUNCTION-VIRT"/>
<section anchor="sec:IANA" title="IANA Considerations"> <references>
<t>This memo includes no request to IANA.</t> <name>Informative References</name>
</section> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.1122.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.3135.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4838.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.5740.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6363.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6726.xml"/>
<section anchor="sec:ecurity" title="Security Considerations"> <xi:include
<t>Security considerations are inherent to any access network, an href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.chin-nfvrg-cloud-5g
d in particular SATCOM systems. Such as it is done in cellular networks, over-th -core-structure-yang.xml"/>
e-air data can be encrypted using e.g. <xref target="ETSITS2011"></xref>. Becaus
e the operator may not enable this <xref target="SSP-2020"></xref>, the applicat
ions 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 Inter-Flow coding appro
ach, see section <xref target="sec:use_cases"></xref>). While this document does
not further elaborate on this, the security considerations discussed in <xref t
arget="RFC6363"></xref> apply.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
<back> rtf-nwcrg-coding-and-congestion.xml"/>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libra
ries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; her
e (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.
xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x
ml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included
files in the same
directory as the including file. You can also define the XML_LIBRARY envi
ronment variable
with a value containing a set of directories to search. These can be eit
her in the local
filing system or remote ones accessed by http (http://domain/dir/... ).--
>
<!-- <references title="Normative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
&RFC2119; .8406.xml"/>
</references> --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8681.xml"/>
<references title="Informative References"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.v
<?rfc include="reference.RFC.1122.xml"?> azquez-nfvrg-netcod-function-virtualization.xml"/>
<?rfc include="reference.RFC.3135.xml"?>
<?rfc include="reference.RFC.4838.xml"?>
<!-- <?rfc include="reference.RFC.5050.xml"?> -->
<!-- <?rfc include="reference.RFC.5326.xml"?> -->
<?rfc include="reference.RFC.5740.xml"?>
<!-- <?rfc include="reference.RFC.5865.xml"?> -->
<!-- <?rfc include="reference.RFC.6816.xml"?> -->
<?rfc include="reference.RFC.6363.xml"?>
<?rfc include="reference.RFC.6726.xml"?>
<!-- <?rfc include="reference.I-D.ietf-tcpm-converters"?> -->
<?rfc include="reference.I-D.chin-nfvrg-cloud-5g-core-structure-y
ang.xml"?>
<?rfc include="reference.I-D.irtf-nwcrg-coding-and-congestion.xml
"?>
<?rfc include="reference.RFC.8406.xml"?>
<?rfc include="reference.RFC.8681.xml"?>
<?rfc include="reference.I-D.vazquez-nfvrg-netcod-function-virtua
lization.xml"?>
<!-- <?rfc include="reference.I-D.zinky-dtnrg-random-binary-fec-s
cheme.xml"?> -->
<!-- <?rfc include="reference.I-D.zinky-dtnrg-erasure-coding-exte
nsion.xml"?> -->
<reference anchor="SSP-2020"> <reference anchor="SSP-2020">
<front> <front>
<title>A Tale of Sea and SkyOn the Security of Mariti <title>A Tale of Sea and Sky On the Security of Maritime VSAT Communications
me VSAT Communications</title> </title>
<author initials="J" surname="Pavur (et al.)"> <author initials="J" surname="Pavur" />
</author> <author initials="D" surname="Moser" />
<date year="2020" /> <author initials="M" surname="Strohmeier" />
</front> <author initials="V" surname="Lenders" />
<seriesInfo name="IEEE Symposium on Security and Privacy" va <author initials="I" surname="Martinovic" />
lue="10.1109/SP40000.2020.00056" /> <date year="2020"/>
</reference> </front>
<refcontent>IEEE Symposium on Security and Privacy</refcontent>
<seriesInfo name="DOI" value="10.1109/SP40000.2020.00056"/>
</reference>
<reference anchor="ETSITS2011"> <reference anchor="ETSI-TS-2011">
<front> <front>
<title>Digital Video Broadcasting (DVB);Content Prote <title>Digital Video Broadcasting (DVB); Content Protection and Copy M
ction and Copy Management (DVB-CPCM);Part 5: CPCM Security Toolbox</title> anagement (DVB-CPCM); Part 5: CPCM Security Toolbox</title>
<author initials="" surname=""> <author initials="" surname="">
<organization>ETSI</organization>
</author> </author>
<date year="2011" /> <date year="2011" month="February"/>
</front> </front>
<seriesInfo name="ETSI TS" value="102 825-5" /> <seriesInfo name="ETSI TS" value="102 825-5 V1.2.1"/>
</reference> </reference>
<reference anchor="ETSITR2017"> <reference anchor="ETSI-TR-2017">
<front> <front>
<title>Satellite Earth Stations and Systems (SES); Multi-lin <title>Satellite Earth Stations and Systems (SES); Multi-link routing
k routing scheme in hybrid access network with heterogeneous links </title> scheme in hybrid access network with heterogeneous links </title>
<author initials="" surname=""> <author initials="" surname="">
<organization>ETSI</organization>
</author> </author>
<date year="2017" /> <date year="2017" month="July"/>
</front> </front>
<seriesInfo name="ETSI TR" value="103 351" /> <seriesInfo name="ETSI TR" value="103 351 V1.1.1"/>
</reference> </reference>
<reference anchor="ETSIEN2014"> <reference anchor="ETSI-EN-2020">
<front> <front>
<title> Digital Video Broadcasting (DVB); Second Generati <title> Digital Video Broadcasting (DVB); Second Generation DVB Intera
on DVB Interactive Satellite System (DVB-RCS2); Part 2: Lower Layers for Satelli ctive Satellite System (DVB-RCS2); Part 2: Lower Layers for Satellite standard</
te standard </title> title>
<author initials="" surname=""> <author initials="" surname="">
<organization>ETSI</organization>
</author> </author>
<date year="2014" /> <date year="2020" month="July"/>
</front> </front>
<seriesInfo name="ETSI EN" value="301 545-2" /> <seriesInfo name="ETSI EN" value="301 545-2 V1.3.1"/>
</reference> </reference>
<reference anchor="SHINE">
<front>
<title>Secure Hybrid In Network caching Environment (SHINE)
ESA project</title>
<author initials="S" surname="Pietro Romano">
</author>
<author initials="et" surname="al.">
</author>
<date year="2017 on-going" />
</front>
<seriesInfo name="ESA project" value="" />
</reference>
<reference anchor="ASMS2010"> <reference anchor="SHINE" target="https://ieeexplore.ieee.org/document/853
<front> 0996">
<title>Demonstration at opening session of ASMS 2010</title> <front>
<author initials="T" surname="De Cola"> <title>SHINE: Secure Hybrid In Network caching Environment
</author> </title>
<author initials="et" surname="al."> <author initials="S." surname="Romano" />
</author> <author initials="C." surname="Roseti" />
<date year="2010" /> <author initials="A" surname="Tulino" />
</front> <date month="June" year="2018"></date>
<seriesInfo name="Advanced Satellite Multimedia Systems (ASM </front>
S) Conference" value="" /> <refcontent>International Symposium on Networks, Computers and Communications (I
</reference> SNCC)</refcontent>
<!-- <reference anchor="IEEEVT2001"> <seriesInfo name='DOI' value='10.1109/ISNCC.2018.8530996' />
<front> </reference>
<title>Statistical modeling of the LMS channel</title>
<author initials="F.P" surname="Fontan">
</author>
<author initials="M" surname="Vazquez-Castro">
</author>
<author initials="C.E" surname="Cabado">
</author>
<author initials="J.P" surname="Garcia">
</author>
<author initials="E" surname="Kubista">
</author>
<date year="2001" />
</front>
<seriesInfo name="BEER Transactions on Vehicular Technology"
value="vol. 50 issue 6" />
</reference> -->
<reference anchor="CCSDS-131.5-O-1"> <reference anchor="ASMS2010">
<front> <front>
<title>Erasure correcting codes for use in near-earth and de <title>Demonstration at opening session of ASMS 2010</title>
ep-space communications</title> <author />
<author surname="CCSDS"> <date year="2010"/>
</author> </front>
<date year="2014" /> <refcontent>5th Advanced Satellite Multimedia Systems (ASMS) Conference<
</front> /refcontent>
<seriesInfo name="CCSDS Experimental specification" value="1 </reference>
31.5-0-1" />
</reference>
<reference anchor="SAT2017"> <reference anchor="CCSDS-131.5-O-1">
<front> <front>
<title>Software-defined satellite cloud RAN</title> <title>Erasure Correcting Codes for Use in Near-Earth and Deep-Space C
<author initials="T" surname="Ahmed"> ommunications</title>
</author> <author>
<author initials="E" surname="Dubois"> <organization>The Consultative Committee for Space Data Systems
</author> </organization>
<author initials="JB" surname="Dupe">
</author>
<author initials="R" surname="Ferrus">
</author>
<author initials="P" surname="Gelard">
</author> </author>
<author initials="N" surname="Kuhn"> <date year="2014" month="November"/>
</front>
<seriesInfo name="Experimental Specification CCSDS" value="131.5-0-1"/>
</reference>
<reference anchor="SAT2017">
<front>
<title>Software-defined satellite cloud RAN</title>
<author initials="T" surname="Ahmed">
</author> </author>
<date year="2017" /> <author initials="E" surname="Dubois">
</front>
<seriesInfo name="International Journal on Satellite Communn
ications and Networking" value="vol. 36 - https://doi.org/10.1002/sat.1206" />
</reference>
<!-- <reference anchor="WANG05">
<front>
<title>Erasure-coding based routing for opportunistic network
s</title>
<author initials="Y" surname="Wang">
</author>
<author initials="et" surname="al.">
</author>
<date year="2005" />
</front>
<seriesInfo name="Proceedings of the ACM SIGCOMM workshop on
Delay-tolerant networking" value=""/>
</reference> -->
<!-- <reference anchor="ZHANG06">
<front>
<title>On the benefits of random linear coding for unicast ap
plications in disruption tolerant networks</title>
<author initials="X" surname="Zhang">
</author>
<author initials="et" surname="al.">
</author>
<date year="2006" />
</front>
<seriesInfo name="Proceedings of the 4th International Sympo
sium on Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks" value
=""/>
</reference>
-->
<!-- <reference anchor="TOURNOUX10">
<front>
<title>On the benefits of random linear coding for unicast ap
plications in disruption tolerant networks</title>
<author initials="P" surname="Tournoux">
</author>
<author initials="E" surname="Lochin">
</author>
<author initials="J" surname="Leguay">
</author>
<author initials="J" surname="Lacan">
</author>
<date year="2010" />
</front>
<seriesInfo name="Proceedings of the IEEE International Conf
erence on Communications" value=""/>
</reference> -->
<!-- <reference anchor="COLA11">
<front>
<title>Reliability options for data communications in the fut
ure deep-space missions</title>
<author initials="T" surname="De Cola">
</author> </author>
<author initials="E" surname="Paolini"> <author initials="JB" surname="Dup&#233;">
</author> </author>
<author initials="G" surname="Liva"> <author initials="R" surname="Ferr&#250;s">
</author> </author>
<author initials="G" surname="Calzolari"> <author initials="P" surname="G&#233;lard">
</author> </author>
<date year="2011" /> <author initials="N" surname="Kuhn">
</front>
<seriesInfo name="Proceedings of the IEEE" value="vol. 99 is
sue 11"/>
</reference> -->
<!-- <reference anchor="CCSDS-FDP">
<front>
<title>CCSDS File Delivery Protocol, Recommendation for Spac
e Data System Standards</title>
<author initials="" surname="">
</author> </author>
<date year="2007" /> <date year="2017" month="February" day="2"/>
</front> </front>
<seriesInfo name="CCSDS 727.0-B-4, Blue Book" value="num. 3" <refcontent>International Journal of Satellite Communications and Networ
/> king, Vol. 36</refcontent>
</reference> --> <seriesInfo name="DOI" value="10.1002/sat.1206"/>
<!-- <reference anchor="LACAN08"> </reference>
<front>
<title>Rethinking reliability for long-delay networks</titl
e>
<author initials="J." surname="Lacan">
</author>
<author initials="E." surname="Lochin">
</author>
<date month="October" year="2008"/>
</front>
<seriesInfo name="International Workshop on Satellite and S
pace Communications" value=""/>
</reference> -->
<!-- <reference anchor="SUNDARARAJAN08">
<front>
<title>ARQ for network coding</title>
<author initials="J." surname="Sundararajan">
</author>
<author initials="D." surname="Shah">
</author>
<author initials="M." surname="Medard">
</author>
<date month="July" year="2008"/>
</front>
<seriesInfo name="IEEE Int. Symp. on Information Theory" va
lue=""/>
</reference> -->
<!-- <reference anchor="TOURNOUX11">
<front>
<title>On-the-fly erasure coding for real-time video applic
ations</title>
<author initials="P" surname="Tournoux">
</author>
<author initials="E." surname="Lochin">
</author>
<author initials="J." surname="Lacan">
</author>
<author initials="A." surname="Bouabdallah">
</author>
<author initials="V." surname="Roca">
</author>
<date month="August" year="2011"/>
</front>
<seriesInfo name="IEEE Trans. on Multimedia" value="vol. 13
issue 4"/>
</reference> -->
<reference anchor="THAI15"> <reference anchor="THAI15">
<front> <front>
<title>Enabling E2E reliable communications with adaptive r <title>Enabling E2E reliable communications with adaptive re-encoding
e-encoding over delay tolerant networks</title> over Delay Tolerant Networks</title>
<author initials="T" surname="Thai"> <author initials="T" surname="Thai">
</author> </author>
<author initials="V." surname="Chaganti"> <author initials="V." surname="Chaganti">
</author> </author>
<author initials="E." surname="Lochin"> <author initials="E." surname="Lochin">
</author> </author>
<author initials="J." surname="Lacan"> <author initials="J." surname="Lacan">
</author> </author>
<author initials="E." surname="Dubois"> <author initials="E." surname="Dubois">
</author> </author>
<author initials="P." surname="Gelard"> <author initials="P." surname="Gelard">
</author> </author>
<date month="June" year="2015"/> <date month="June" year="2015"/>
</front> </front>
<seriesInfo name="Proceedings of the IEEE International Con <refcontent>IEEE International Conference on Communications</refcontent>
ference on Communications" value="http://dx.doi.org/10.1109/ICC.2015.7248441"/> <seriesInfo name="DOI" value="10.1109/ICC.2015.7248441"/>
</reference> </reference>
</references>
<section anchor="sec_acknowledgements" numbered="false" toc="default">
</references> <name>Acknowledgements</name>
</back> <t>Many thanks to <contact fullname="John Border"/>, <contact fullname="St
uart Card"/>, <contact fullname="Tomaso de Cola"/>, <contact fullname="Marie-Jos
e Montpetit"/>, <contact fullname="Vincent Roca"/>, and <contact fullname="Lloyd
Wood"/> for their help in writing this document.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 82 change blocks. 
794 lines changed or deleted 548 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/