-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-irtf-nwcrg-network-coding-satellites-09.xml
672 lines (591 loc) · 44.4 KB
/
draft-irtf-nwcrg-network-coding-satellites-09.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
<?xml version="1.0" encoding="US-ASCII"?>
<!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-09"
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 ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Network coding for satellite systems">Network coding for satellite systems</title>
<author role="editor" fullname="Nicolas Kuhn" initials="N" surname="Kuhn">
<organization>CNES</organization>
<address>
<postal>
<street>18 Avenue Edouard Belin</street>
<city>Toulouse</city>
<region></region>
<code>31400</code>
<country>France</country>
</postal>
<phone></phone>
<email>[email protected]</email>
</address>
</author>
<author role="editor" fullname="Emmanuel Lochin" initials="E" surname="Lochin">
<organization>ISAE-SUPAERO</organization>
<address>
<postal>
<street>10 Avenue Edouard Belin</street>
<city>Toulouse</city>
<region></region>
<code>31400</code>
<country>France</country>
</postal>
<phone></phone>
<email>[email protected]</email>
</address>
</author>
<date year="2019" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc 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 specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- 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>
<t>This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG). It conforms to the directions found in the NWCRG taxonomy <xref target="RFC8406"> </xref>. Thus, the scope of the document is network coding as a linear combination of packets in and above the network layer. Physical and MAC layer coding are beyond the scope of the document. The draft focuses on a multi-gateway satellite system and identifies the use-cases where network coding provides significant performance improvements. The objective is to contribute to a larger deployment of network coding techniques in SATCOM to complement already implemented loss recovery mechanisms. The draft also identifies open research issues related to the deployment of network coding in SATCOM systems.</t>
</abstract>
</front>
<middle>
<section anchor="sec:introduction" title="Introduction">
<t>This document is the 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 intends to inform the SATCOM and Internet research communities about recent developments in Network Coding. A glossary is proposed in <xref target="sec:glossary"></xref> to clarify the terminology use throughout the document.</t>
<t>As will be shown in this draft, the implementation of network coding techniques above the network layer of the ISO model, at application or transport layers, offers an opportunity for improving the end-to-end performance of SATCOM systems. While physical- and link-layer coding error protection is usually enough to provide Quasi-Error Free transmission thus minimizing packet loss, when the physical and link layers coding fail or that residual errors create packet losses that greatly interfere with Internet protocols, retransmissions add significant delays because especially in geostationary system 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.</t>
<t>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 made it to commercial systems in the satellite industry. In this context, this document aims at identifying opportunities for further usage of network coding in commercial SATCOM networks.</t>
<t>The notation used in this document is based on the NWCRG taxonomy <xref target="RFC8406"> </xref>:<list style="symbols">
<t>Channel and link error correcting codes are considered part of the PHY layer error protection and are out of the scope of this document.</t>
<t>FEC (also called Application-Level FEC) operates in and above the network layer and targets packet loss recovery.</t>
<t>This document considers only coding (or coding techniques or coding schemes) that use a linear combination of packets and excludes for example content coding (e.g., to compress a video flow) or other non-linear operation.</t>
</list></t>
<!-- <t>Reliability is an inherent part of the physical-layer and usually achieved by using coding techniques. Based on public information, coding does not seem to be widely used at higher layers.</t> -->
<!-- <t>This memo presents use-cases where network coding schemes could improve the overall performance of a SATCOM system (e.g. considering a more efficient 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
</section> -->
</section>
<!-- ######################################################-->
<!-- ######################################################-->
<!-- Body of the document -->
<!-- ######################################################-->
<!-- ######################################################-->
<!-- ######################################################-->
<!-- New section -->
<!-- ######################################################-->
<section anchor="sec:sat_topo" title="A Note on Satellite Networks Topology">
<t>There are multiple SATCOM systems, for example broadcast TV, point to point communication or IoT and monitoring. Therefore, depending on the purpose of the system, the associated ground segments architecture will be different. This section focuses on a satellite system that follows the ETSI DVB standards to provide broadband Internet access via ground-based gateways. One must note that the overall data capacity of one satellite may be higher than the capacity that one single gateway support. Hence, there are usually multiple gateways for one unique satellite platform.</t>
<t>In this context, <xref target="fig:sat_gateway"></xref> shows an example of a multi-gateway satellite system. More 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 satellite multi-gateway system. More details can be found in DVB standard documents.">
<artwork>
+--------------------------+
| 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|
+----------+ +----------+
</artwork>
</figure>
</section>
<!-- ######################################################-->
<!-- New section -->
<!-- ######################################################-->
<section anchor="sec:use_cases" title="Use-cases for Improving SATCOM System 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 Mode">
<t>This use-case considers two-way communication between end-users, through a satellite link as seen in <xref target="fig:two_way"></xref>.</t>
<t>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 flows. This results in non-negligible capacity savings that has been demonstrated in the past <xref target="ASMS2010"></xref>. 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 resource on-board and may not be supported by today's satellites.</t>
<figure anchor="fig:two_way" title="Network Architecture for Two-way Relay Channel using NC">
<artwork>
-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}-+ | |
+-----------+ +-----+
</artwork>
</figure>
</section>
<section anchor="subsec:rel-mul" title="Reliable Multicast">
<t>The use of multicast servers is one way to better utilize a satellite broadcast capabilities. Multicast is proposed in the SHINE ESA project <xref target="I-D.vazquez-nfvrg-netcod-function-virtualization"> </xref> <xref target="SHINE"> </xref>. 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 <xref target="fig:rel_multi"></xref>.</t>
<figure anchor="fig:rel_multi" title="Network Architecture for a Reliable Multicast using NC">
<artwork>
-Li}- : packet indicating the loss of packet i of a multicast flow M
={M== : multicast flow including the missing packets
+-----------+ +-----+
|Sat term A |-Li}-+ | |
+-----------+ | | | +---------+ +------+
^^ +-| |-Li}--| | |Multi |
|| | SAT |-Lj}--| Gateway |--|Cast |
===={M==========| |={M===| | |Server|
|| | | +---------+ +------+
vv +-| |
+-----------+ | | |
|Sat term B |-Lj}-+ | |
+-----------+ +-----+
</artwork>
</figure>
<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), and terminal A (respectively B) returns a negative acknowledgment Li (respectively Lj), indicating that the packet is missing. Using NC, 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.</t>
<t>This could also be achieved by using other multicast or broadcast systems, such as NACK-Oriented Reliable Multicast (NORM) <xref target="RFC5740"></xref> or File Delivery over Unidirectional Transport (FLUTE) <xref target ="RFC6726"></xref>. Both NORM and FLUTE are limited to block coding, none of them supporting more flexible sliding window encoding schemes that allow decoding before receiving the whole block an added delay benefit <xref target="RFC8406"></xref>.</t>
</section>
<section anchor="subsec:hybrid" title="Hybrid Access">
<t>This use-case considers improving multiple path communications with network coding at the transport layer (see <xref target="fig:hyb_access"></xref>). 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 <xref target="ETSITR2017"></xref>.</t>
<t>To cope with packet loss (due to either end-user mobility or physical-layer residual errors), network coding can be introduced both at the CPE and at the concentrator. Apart from packet losses, other gains from this approach include a better tolerance to out-of-order packet delivery which occur when exploited links exhibit high asymmetry in terms of RTT. Depending on the ground architecture <xref target="I-D.chin-nfvrg-cloud-5g-core-structure-yang"></xref> <xref target="SAT2017"></xref>, some ground equipment might be hosting both SATCOM and cellular network functionality.</t>
<figure anchor="fig:hyb_access" title="Network Architecture for a Hybrid Access Using Network Coding">
<artwork>
-{}- : bidirectional link
+---+ +--------------+
+-{}-|SAT|-{}-|BACKBONE |
+----+ +---+ | +---+ |+------------+|
|End |-{}-|CPE|-{}-| ||CONCENTRATOR||
|User| +---+ | +---+ |+------------+| +-----------+
+----+ |-{}-|DSL|-{}-| |-{}-|Application|
| +---+ | | |Server |
| | | +-----------+
| +---+ | |
+-{}-|LTE|-{}-+--------------+
+---+
</artwork>
</figure>
</section>
<section anchor="subsec:varying_wifi" title="LAN Packet Losses">
<t>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 PEP cannot operate hence other mechanism need to be used. The WIFI packet losses will result in an end-to-end retransmission that will harm the end-user quality of experience and poorly utilize SATCOM bottleneck resource for non-revenue generating traffic. In this use-case, adding network coding techniques will prevent the end-to-end retransmission from occurring since the packet losses will be recovered.</t>
<t>The architecture is shown in <xref target="fig:varying_wifi-loss"></xref>.</t>
<figure anchor="fig:varying_wifi-loss" title="Network Architecture for dealing with LAN Losses">
<artwork>
-{}- : bidirectional link
-''- : Wi-Fi link
C : where network coding techniques could be introduced
+----+ +---------+ +---+ +--------+ +-------+ +--------+
|End | |Satellite| |SAT| |Physical| |Access | |Network |
|user|-''-|Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function|
+----+ +---------+ +---+ +--------+ +-------+ +--------+
C C C C
</artwork>
</figure>
</section>
<section anchor="subsec:varying" title="Varying Channel Conditions">
<t>This use-case considers the usage of network coding to cope with sub second 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., very high frequency bands, mobile users) or depending on the deployment use-cases (e.g., performance of the network between each individual data block), the relevance of adding network coding is different.</t>
<t>The system architecture is shown in <xref target="fig:varying_capa"></xref>.</t>
<figure anchor="fig:varying_capa" title="Network Architecture for dealing with Varying Link Characteristics">
<artwork>
-{}- : bidirectional link
C : where network coding techniques could be introduced
+---------+ +---+ +--------+ +-------+ +--------+
|Satellite| |SAT| |Physical| |Access | |Network |
|Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function|
+---------+ +---+ +--------+ +-------+ +--------+
C C C C
</artwork>
</figure>
</section>
<section anchor="subsec:gat_hand" title="Improving Gateway Handover">
<t>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.</t>
<t><xref target="fig:gat_hand"></xref> illustrates this use-case.</t>
<figure anchor="fig:gat_hand" title="Network Architecture for dealing with Gateway Handover">
<artwork>
-{}- : 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
</artwork>
</figure>
</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 Congestion Control in SATCOM Systems">
<t>Many SATCOM systems typically use Performance Enhancing Proxy (PEP) <xref target="RFC3135">RFC 3135</xref>. PEPs usually split end-to-end connections and forward transport or application layer packets to the satellite baseband gateway that deals with layer-2 and layer-1 encapsulation. PEPs contribute to mitigate congestion in a SATCOM systems 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 the <xref target="sec:use_cases"></xref> of this document.</t>
<t>Deploying network coding in the PEP could be relevant and be 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.</t>
</section>
<section anchor="sec:deploy_coding" title="Efficient Use of Satellite Resources">
<t>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 QoE while optimizing capacity usage ? At which layer this supplementary redundancy should be added ?</t>
<t>This problem has been tackled in the past by the deployment of physical-layer error-correction codes, but there remains questions 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 was discussed on the previous section.</t>
</section>
<section anchor="sec:deploy_nfv" title="Interaction with Virtualized Satellite Gateways and Terminals">
<t>In the emerging virtualized network infrastructure, network coding could be easily deployed as a VNF. The next generation of SATCOM ground segments will rely on a virtualized environment to integrate to terrestrial networks. This trend towards 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-core-structure-yang"> </xref>. As one example, the network coding VNF deployment in a virtualized environment has been presented in <xref target="I-D.vazquez-nfvrg-netcod-function-virtualization"> </xref>.</t>
<t>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 a virtualized SATCOM equipment is the management of limited buffered capacities in large gateways.</t>
</section>
<section anchor="subsec:dtn" title="Delay/Disruption Tolerant Networks">
<!-- <t>In the context of deep-space communications, establishing communications from terrestrial gateways to satellite platforms can be a challenge. Indeed, reliable end-to-end (E2E) communications over such links must cope with long delay and frequent link disruptions. Delay/Disruption Tolerant Networking <xref target="RFC4838"></xref> is a solution to enable reliable internetworking space communications where both standard ad-hoc routing and E2E Internet protocols cannot be used. The transport of data over such networks requires the use of replication, erasure codes and multipath protocol schemes <xref target="WANG05"></xref> <xref target="ZHANG06"></xref> to improve the bundle delivery ratio and/or delivery 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 LTP a robust streaming method based on an on-the-fly coding scheme, where encoding and decoding procedures are done at the source and destination nodes, respectively. 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-dtnrg-erasure-coding-extension"></xref>, where the authors proposed an encoding process at intermediate DTN nodes to explore the possibilities of Forward Error Correction (FEC) schemes inside the bundle protocol <xref target="RFC5050"></xref>. In this context, the use of erasure coding inside a Consultative Committee for Space 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 cope with very long delays and frequent link disruptions; indeed, E2E connectivity may be available only intermittently. Delay/Disruption Tolerant Networking <xref target="RFC4838"></xref> is a solution to enable reliable internetworking space communications where both standard ad-hoc routing and E2E Internet protocols cannot 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 potential adaptive re-encoding, as proposed in <xref target="THAI15"></xref>. Here, the use-cases proposed in <xref target="subsec:varying"></xref> would legitimize the usage of network coding within the DTN stack to improve the physical channel utilization 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 <xref target="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 target="CCSDS-FDP"></xref> with erasure coding capabilities where a Low Density Parity Check (LDPC) <xref target="RFC6816"></xref> code with a large block size is chosen. Recently, on-the-fly erasure coding schemes <xref target="LACAN08"></xref> <xref target="SUNDARARAJAN08"></xref> <xref target="TOURNOUX11"></xref> have shown their benefits in terms of recovery capability and configuration complexity compared to traditional FEC schemes. Using a feedback path when available, on-the-fly schemes can be used to enable E2E reliable communication over DTN with adaptive re-encoding as proposed in <xref target="THAI15"></xref>. -->
</section>
</section>
<!-- ######################################################-->
<!-- New section -->
<!-- ######################################################-->
<section anchor="sec:conclu" title="Conclusion">
<t>This document introduces some wide-scale network coding techniques opportunities in satellite telecommunications systems.</t>
<t>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 <xref target="fig:sat_gateway"></xref> 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 draft since they may also be relevant for cellular networks.</t>
</section>
<!-- ######################################################-->
<!-- ######################################################-->
<!-- Tail of the document -->
<!-- ######################################################-->
<!-- ######################################################-->
<section anchor="sec:glossary" title="Glossary">
<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 encapsulation work 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 (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 Network;</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;</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;</t>
<t>NORM: NACK-Oriented Reliable Multicast;</t>
<t>PEP: Performance Enhancing Proxy <xref target="RFC3135"></xref> - a typical PEP for satellite communications include compression, caching and TCP acceleration;</t>
<t>PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME with additional 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>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.</t>
</list></t>
</section>
<section anchor="sec:acknowledgements" title="Acknowledgements">
<t>Many thanks to John Border, Stuart Card, Tomaso de Cola, Vincent Roca, Lloyd Wood and Marie-Jose Montpetit for their help in writing this document.</t>
</section>
<section anchor="sec:IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="sec:ecurity" title="Security Considerations">
<t>Security considerations are inherent to any access network, and in particular SATCOM systems. The use of FEC or Network Coding in SATCOM also 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 approach, see section <xref target="sec:use_cases"></xref>). However, this is not specific to the SATCOM use-case and this document does not further elaborate on it.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (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.xml")
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 environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<!-- <references title="Normative References">
&RFC2119;
</references> -->
<references title="Informative References">
<?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.6726.xml"?>
<!-- <?rfc include="reference.I-D.ietf-tcpm-converters"?> -->
<?rfc include="reference.I-D.chin-nfvrg-cloud-5g-core-structure-yang.xml"?>
<?rfc include="reference.RFC.8406.xml"?>
<?rfc include="reference.I-D.vazquez-nfvrg-netcod-function-virtualization.xml"?>
<!-- <?rfc include="reference.I-D.zinky-dtnrg-random-binary-fec-scheme.xml"?> -->
<!-- <?rfc include="reference.I-D.zinky-dtnrg-erasure-coding-extension.xml"?> -->
<reference anchor="ETSITR2017">
<front>
<title>Satellite Earth Stations and Systems (SES); Multi-link routing scheme in hybrid access network with heterogeneous links </title>
<author initials="" surname="">
</author>
<date year="2017" />
</front>
<seriesInfo name="ETSI TR" value="103 351" />
</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">
<front>
<title>Demonstration at opening session of ASMS 2010</title>
<author initials="T" surname="De Cola">
</author>
<author initials="et" surname="al.">
</author>
<date year="2010" />
</front>
<seriesInfo name="Advanced Satellite Multimedia Systems (ASMS) Conference" value="" />
</reference>
<!-- <reference anchor="IEEEVT2001">
<front>
<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">
<front>
<title>Erasure correcting codes for use in near-earth and deep-space communications</title>
<author surname="CCSDS">
</author>
<date year="2014" />
</front>
<seriesInfo name="CCSDS Experimental specification" value="131.5-0-1" />
</reference>
<reference anchor="SAT2017">
<front>
<title>Software-defined satellite cloud RAN</title>
<author initials="T" surname="Ahmed">
</author>
<author initials="E" surname="Dubois">
</author>
<author initials="JB" surname="Dupe">
</author>
<author initials="R" surname="Ferrus">
</author>
<author initials="P" surname="Gelard">
</author>
<author initials="N" surname="Kuhn">
</author>
<date year="2017" />
</front>
<seriesInfo name="International Journal on Satellite Communnications and Networking" value="vol. 36 - https://doi.org/10.1002/sat.1206" />
</reference>
<!-- <reference anchor="WANG05">
<front>
<title>Erasure-coding based routing for opportunistic networks</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 applications 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 Symposium 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 applications 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 Conference on Communications" value=""/>
</reference> -->
<!-- <reference anchor="COLA11">
<front>
<title>Reliability options for data communications in the future deep-space missions</title>
<author initials="T" surname="De Cola">
</author>
<author initials="E" surname="Paolini">
</author>
<author initials="G" surname="Liva">
</author>
<author initials="G" surname="Calzolari">
</author>
<date year="2011" />
</front>
<seriesInfo name="Proceedings of the IEEE" value="vol. 99 issue 11"/>
</reference> -->
<!-- <reference anchor="CCSDS-FDP">
<front>
<title>CCSDS File Delivery Protocol, Recommendation for Space Data System Standards</title>
<author initials="" surname="">
</author>
<date year="2007" />
</front>
<seriesInfo name="CCSDS 727.0-B-4, Blue Book" value="num. 3" />
</reference> -->
<!-- <reference anchor="LACAN08">
<front>
<title>Rethinking reliability for long-delay networks</title>
<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 Space 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" value=""/>
</reference> -->
<!-- <reference anchor="TOURNOUX11">
<front>
<title>On-the-fly erasure coding for real-time video applications</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">
<front>
<title>Enabling E2E reliable communications with adaptive re-encoding over delay tolerant networks</title>
<author initials="T" surname="Thai">
</author>
<author initials="V." surname="Chaganti">
</author>
<author initials="E." surname="Lochin">
</author>
<author initials="J." surname="Lacan">
</author>
<author initials="E." surname="Dubois">
</author>
<author initials="P." surname="Gelard">
</author>
<date month="June" year="2015"/>
</front>
<seriesInfo name="Proceedings of the IEEE International Conference on Communications" value="http://dx.doi.org/10.1109/ICC.2015.7248441"/>
</reference>
</references>
</back>
</rfc>