idnits 2.17.1 draft-irtf-nwcrg-network-coding-satellites-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8406]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 18, 2019) is 1621 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. Kuhn, Ed. 3 Internet-Draft CNES 4 Intended status: Informational E. Lochin, Ed. 5 Expires: May 21, 2020 ISAE-SUPAERO 6 November 18, 2019 8 Network coding for satellite systems 9 draft-irtf-nwcrg-network-coding-satellites-08 11 Abstract 13 This document is the product of the Coding for Efficient Network 14 Communications Research Group (NWCRG). This document follows the 15 taxonomy document [RFC8406] and considers coding as a linear 16 combination of packets that operate in and above the network layer. 17 In this context, this memo details a multi-gateway satellite system 18 to identify use-cases where network coding is relevant. As example, 19 network coding operating in and above the network layer can be 20 exploited to cope with residual losses or provide reliable multicast 21 services. The objective is to contribute to a larger deployment of 22 such techniques in SATCOM systems. This memo also identifies open 23 research issues related to the deployment of network coding in SATCOM 24 systems, such as the interaction between congestion control and 25 network coding techniques. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 21, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. A note on satellite topology . . . . . . . . . . . . . . . . 3 63 3. Use-cases for improving the SATCOM system performance with 64 network coding . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Two-way relay channel mode . . . . . . . . . . . . . . . 5 66 3.2. Reliable multicast . . . . . . . . . . . . . . . . . . . 5 67 3.3. Hybrid access . . . . . . . . . . . . . . . . . . . . . . 6 68 3.4. Dealing with LAN losses . . . . . . . . . . . . . . . . . 7 69 3.5. Dealing with varying channel conditions . . . . . . . . . 8 70 3.6. Improving the gateway handovers . . . . . . . . . . . . . 8 71 4. Research challenges . . . . . . . . . . . . . . . . . . . . . 9 72 4.1. On the joint-use of network coding and congestion control 73 in SATCOM systems . . . . . . . . . . . . . . . . . . . . 9 74 4.2. On the efficient usage of satellite resource . . . . . . 10 75 4.3. Interaction with virtualized satellite gateways and 76 terminals . . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.4. Delay/Disruption Tolerant Networks . . . . . . . . . . . 10 78 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 6. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 10. Informative References . . . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 This document is the product of and represents the collaborative work 89 and consensus of the Coding for Efficient Network Communications 90 Research Group (NWCRG); it is not an IETF product and is not a 91 standard. A glossary is proposed in Section 6. 93 Exploiting network coding techniques at application or transport 94 layers is an opportunity for improving the end-to-end performance of 95 SATCOM systems. Physical and link layers coding protection is 96 usually sufficient to guarranty Quasi-Error Free, with a negligeable 97 delay compared to the propagation time (e.g., with a GEO sat). When 98 the physical and link layers coding fails, retransmissions add 99 significant delays. Hence the use of network coding in upper layers 100 can improve the quality of experience of end users. 102 We notice an active research activity on network coding techniques 103 above the network layer and SATCOM. That being said, not much has 104 actually made it to industrial developments. In this context, this 105 document aims at identifying opportunities for further usage of 106 network coding in these systems. 108 The notations used in this document are based on the taxonomy 109 document [RFC8406]: 111 o Channel and link codings are gathered in the PHY layer coding and 112 are out of the scope of this document. 114 o FEC (also called Application-Level FEC) operates in and above the 115 network layer. 117 o This document considers coding (or coding techniques or coding 118 schemes) as a linear combination and not as a content coding 119 (e.g., to compress a video flow). 121 2. A note on satellite topology 123 There are multiple SATCOM systems, such as those dedicated to 124 broadcasting TV or to IoT applications: depending on the purpose of 125 the SATCOM system, the ground segments are different. This section 126 focuses on a satellite system that follows the ETSI DVB standards to 127 provide broadband Internet access. The capacity that is carried out 128 by one satellite may be higher than the capacity that one single 129 gateway can carry out: there are usually multiple gateways for one 130 unique satellite platform. 132 In this context, Figure 1 shows an example of a multi-gateway 133 satellite system. More information on a generic SATCOM ground 134 segment architecture for bidirectional Internet access can be found 135 in [SAT2017]. 137 +--------------------------+ 138 | application servers | 139 | (data, coding, multicast)| 140 +--------------------------+ 141 | ... | 142 ----------------------------------- 143 | | | | | | 144 +--------------------+ +--------------------+ 145 | network function | | network function | 146 |(firewall, PEP, etc)| |(firewall, PEP, etc)| 147 +--------------------+ +--------------------+ 148 | ... | IP packets | ... | 149 --- 150 +------------------+ +------------------+ | 151 | access gateway | | access gateway | | 152 +------------------+ +------------------+ | 153 | BBFRAME | | gateway 154 +------------------+ +------------------+ | 155 | physical gateway | | physical gateway | | 156 +------------------+ +------------------+ | 157 --- 158 | PLFRAME | 159 +------------------+ +------------------+ 160 | outdoor unit | | outdoor unit | 161 +------------------+ +------------------+ 162 | satellite link | 163 +------------------+ +------------------+ 164 | outdoor unit | | outdoor unit | 165 +------------------+ +------------------+ 166 | | 167 +------------------+ +------------------+ 168 | sat terminals | | sat terminals | 169 +------------------+ +------------------+ 170 | | | | 171 +----------+ | +----------+ | 172 |end user 1| | |end user 3| | 173 +----------+ | +----------+ | 174 +----------+ +----------+ 175 |end user 2| |end user 4| 176 +----------+ +----------+ 178 Figure 1: Data plane functions in a generic satellite multi-gateway 179 system. More details can be found in DVB standard documents. 181 3. Use-cases for improving the SATCOM system performance with network 182 coding 184 This section details use-cases where network coding techniques could 185 improve SATCOM systems. 187 3.1. Two-way relay channel mode 189 This use-case considers a two-way communication between end users, 190 through a satellite link. Figure 2 proposes an illustration of this 191 scenario. 193 Satellite terminal A sends a flow A and satellite terminal B sends a 194 flow B to a coding server. The coding server sends a combination of 195 both terminal flows. This results in non-negligible capacity savings 196 and has been demonstrated [ASMS2010]. In the proposed example, a 197 dedicated coding server is introduced (note that its location could 198 be different for another deployment use-case). The network coding 199 operations could also be done at the satellite level, although this 200 would require lots of computational ressource on-board and may not be 201 relevant with today's satellites. 203 -X}- : traffic from satellite terminal X to the server 204 ={X+Y= : traffic from X and Y combined sent from 205 the server to terminals X and Y 207 +-----------+ +-----+ 208 |Sat term A |--A}-+ | | 209 +-----------+ | | | +---------+ +------+ 210 ^^ +--| |--A}--| |--A}--|Coding| 211 || | SAT |--B}--| Gateway |--B}--|Server| 212 ===={A+B=========| |={A+B=| |={A+B=| | 213 || | | +---------+ +------+ 214 vv +--| | 215 +-----------+ | | | 216 |Sat term B |--B}-+ | | 217 +-----------+ +-----+ 219 Figure 2: Network architecture for two way relay channel with NC 221 3.2. Reliable multicast 223 Using multicast servers is a way to better exploit the satellite 224 broadcast capabilities. This approach is proposed in the SHINE ESA 225 project [I-D.vazquez-nfvrg-netcod-function-virtualization] [SHINE]. 226 This use-case considers adding redundancy to a multicast flow 227 depending on what has been received by different end-users, resulting 228 in non-negligible scarce resource saving. We propose an illustration 229 for this scenario in Figure 3. 231 -Li}- : packet indicating the loss of packet i of a multicast flow M 232 ={M== : multicast flow including the missing packets 234 +-----------+ +-----+ 235 |Sat term A |-Li}-+ | | 236 +-----------+ | | | +---------+ +------+ 237 ^^ +-| |-Li}--| | |Multi | 238 || | SAT |-Lj}--| Gateway |--|Cast | 239 ===={M==========| |={M===| | |Server| 240 || | | +---------+ +------+ 241 vv +-| | 242 +-----------+ | | | 243 |Sat term B |-Lj}-+ | | 244 +-----------+ +-----+ 246 Figure 3: Network architecture for a reliable multicast with NC 248 A multicast flow (M) is forwarded to both satellite terminals A and 249 B. However packet Ni (resp. Nj) gets lost at terminal A (resp. B), 250 and terminal A (resp. B) returns a negative acknowledgment Li (resp. 251 Lj), indicating that the packet is missing. Then either the access 252 gateway or the multicast server includes a repair packet (rather than 253 the individual Ni and Nj packets) in the multicast flow to let both 254 terminals recover from losses. 256 This could be achieved by using other multicast or broadcast systems, 257 such as NACK-Oriented Reliable Multicast (NORM) [RFC5740] or File 258 Delivery over Unidirectional Transport (FLUTE) [RFC6726]. Note that 259 both NORM and FLUTE are limited to block coding, none of them 260 supporting sliding window encoding schemes [RFC8406]. 262 3.3. Hybrid access 264 This use-case considers improving multiple path communications with 265 network coding at the transport layer. We propose an illustration 266 for this scenario in Figure 4. This use-case is inspired from the 267 Broadband Access via Integrated Terrestrial Satellite Systems (BATS) 268 project and has been published as an ETSI Technical Report 269 [ETSITR2017]. 271 To cope with packet loss (due to either end-user mobility or 272 physical-layer impairments), network coding could be introduced both 273 at the CPE and at the concentrator. Apart from packet losses, other 274 gains could be envisioned, such as a better tolerance to out-of-order 275 packets which occur when exploited links exhibit high asymetry in 276 terms of RTT. Depending on the ground architecture 277 [I-D.chin-nfvrg-cloud-5g-core-structure-yang] [SAT2017], some 278 equipments might be hosting both SATCOM and cellular functions. 280 -{}- : bidirectional link 282 +---+ +--------------+ 283 +-{}-|SAT|-{}-|BACKBONE | 284 +----+ +---+ | +---+ |+------------+| 285 |End |-{}-|CPE|-{}-| ||CONCENTRATOR|| 286 |User| +---+ | +---+ |+------------+| +-----------+ 287 +----+ |-{}-|DSL|-{}-| |-{}-|Application| 288 | +---+ | | |Server | 289 | | | +-----------+ 290 | +---+ | | 291 +-{}-|LTE|-{}-+--------------+ 292 +---+ 294 Figure 4: Network architecture for an hybrid access using network 295 coding 297 3.4. Dealing with LAN losses 299 This use-case considers the usage of network coding to cope with 300 cases where the end user connects to the satellite terminal with a 301 Wi-Fi link that exhibits losses. In the case of encrypted end-to-end 302 applications based on UDP, PEP cannot operate. The Wi-Fi losses 303 result in an end-to-end retransmission that would harm the quality of 304 experience of the end user. In this use-case, adding network coding 305 techniques could prevent the end-to-end retransmission from occuring. 307 The architecture is recalled in Figure 5. 309 -{}- : bidirectional link 310 -''- : Wi-Fi link 311 C : where network coding techniques could be introduced 313 +----+ +---------+ +---+ +--------+ +-------+ +--------+ 314 |End | |Satellite| |SAT| |Physical| |Access | |Network | 315 |user|-''-|Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function| 316 +----+ +---------+ +---+ +--------+ +-------+ +--------+ 317 C C C C 319 Figure 5: Network architecture for dealing with LAN losses 321 3.5. Dealing with varying channel conditions 323 This use-case considers the usage of network coding to cope with 324 cases where channel condition change in less than a second and the 325 mechanisms that are exploited to adapt the physical-layer codes 326 (Adaptative Coding and Modulation (ACM)) may not adapt the modulation 327 and coding in time: remaining errors could be recovered with higher 328 layer redundancy packets. This use-case is mostly relevant when 329 mobile users are considered or when the chosen band induces quick 330 changes in channel condition (Q/V bands, Ka band, etc.). Depending 331 on the use-case (e.g., very high frequency bands, mobile users) or 332 depending on the deployment use-cases (e.g., performance of the 333 network between each individual block), the relevance of adding 334 network coding is different. 336 The architecture is recalled in Figure 6. 338 -{}- : bidirectional link 339 C : where network coding techniques could be introduced 341 +---------+ +---+ +--------+ +-------+ +--------+ 342 |Satellite| |SAT| |Physical| |Access | |Network | 343 |Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function| 344 +---------+ +---+ +--------+ +-------+ +--------+ 345 C C C C 347 Figure 6: Network architecture for dealing with varying link 348 characteristics 350 3.6. Improving the gateway handovers 352 This use-case considers the recovery of packets that may be lost 353 during gateway handovers. Whether this is for off-loading one given 354 equipment or because the transmission quality is not the same on each 355 gateway, changing the transmission gateway may be relevant. However, 356 packet losses can occur if the gateways are not properly synchronized 357 or if the algorithm that is exploited to trigger gateway handovers is 358 not properly tuned. During these critical phases, network coding can 359 be added to improve the reliability of the transmission and allow a 360 seamless gateway handover. 362 Figure 7 illustrates this use-case. 364 -{}- : bidirectional link 365 ! : management interface 366 C : where network coding techniques could be introduced 367 C C 368 +--------+ +-------+ +--------+ 369 |Physical| |Access | |Network | 370 +-{}-|gateway |-{}-|gateway|-{}-|function| 371 | +--------+ +-------+ +--------+ 372 | ! ! 373 +---------+ +---+ +---------------+ 374 |Satellite| |SAT| | Control plane | 375 |Terminal |-{}-| | | manager | 376 +---------+ +---+ +---------------+ 377 | ! ! 378 | +--------+ +-------+ +--------+ 379 +-{}-|Physical|-{}-|Access |-{}-|Network | 380 |gateway | |gateway| |function| 381 +--------+ +-------+ +--------+ 382 C C 384 Figure 7: Network architecture for dealing with gateway handover 385 schemes 387 4. Research challenges 389 This section proposes a few potential approaches to introduce and use 390 network coding in SATCOM systems. 392 4.1. On the joint-use of network coding and congestion control in 393 SATCOM systems 395 SATCOM systems typically feature Performance Enhancing Proxy (PEP) 396 RFC 3135 [RFC3135]. PEPs usually split end-to-end connections and 397 forward transport or application layer packets to the satellite 398 baseband gateway that deals with layer-2 and layer-1 encapsulations. 399 PEP contributes to mitigate congestion in a SATCOM systems. PEP 400 could host network coding mechanisms and thus support use-cases that 401 have been discussed in this document. 403 Deploying network coding in the PEP could be relevant and independent 404 from the specific characteristics of a SATCOM link. This leads to 405 research questions on the interaction between network coding and 406 congestion control. 408 4.2. On the efficient usage of satellite resource 410 The recurrent trade-off in SATCOM systems remains: how much overhead 411 from redundant reliability packets can be introduced to guarantee a 412 better end-user QoE while optimizing capacity usage ? At which layer 413 this supplementary network coding should be added ? 415 This problem has been tackled in the past for physical-layer code, 416 but there remains questions on how to adapt the overhead for, e.g., 417 the quickly varying channel conditions use-case where ACM may not be 418 reacting quickly enough. 420 4.3. Interaction with virtualized satellite gateways and terminals 422 Related to the foreseen virtualized network infrastructure, network 423 coding could be easily deployed as VNF. Next generation of SATCOM 424 ground segments could rely on a virtualized environment. This trend 425 can also be seen in cellular networks, making these discussions 426 extendable to other deployment scenarios 427 [I-D.chin-nfvrg-cloud-5g-core-structure-yang]. As one example, the 428 network coding VNF deployment in a virtualized environment is 429 presented in [I-D.vazquez-nfvrg-netcod-function-virtualization]. 431 A research challenge would be the optimization of the NFV service 432 function chaining, considering a virtualized infrastructure and other 433 SATCOM specific functions, to guarantee efficient radio usage and 434 easy-to-deploy SATCOM services. Moreover, another challenge related 435 to a virtualized SATCOM equipment is the management of limited 436 buffered capacities. 438 4.4. Delay/Disruption Tolerant Networks 440 Communications among deep-space platforms and terrestrial gateways 441 can be a challenge. Reliable end-to-end (E2E) communications over 442 such paths must cope with long delay and frequent link disruptions; 443 indeed, E2E connectivity may be available only intermittently or 444 never. Delay/Disruption Tolerant Networking [RFC4838] is a solution 445 to enable reliable internetworking space communications where both 446 standard ad-hoc routing and E2E Internet protocols cannot be used. 447 Moreover, DTN can also be seen as an alternative solution to transfer 448 the data between a central PEP and a remote PEP. 450 Coding enables E2E reliable communication over DTN with adaptive re- 451 encoding, as proposed in [THAI15]. In this case, the use-cases 452 proposed in Section 3.5 would legitimize the usage of coding within 453 the DTN stack to improve the channel utilization and the E2E 454 transmission delay. In this context, the use of erasure coding 455 techniques inside a Consultative Committee for Space Data Systems 456 (CCSDS) architecture has been specified in [CCSDS-131.5-O-1]. A 457 research challenge would be on how such network coding can be 458 integrated in the IETF DTN stack. 460 5. Conclusion 462 This document discuses some opportunities to introduce network coding 463 techniques at a wider scale in satellite telecommunications systems. 465 Even though this document focuses on satellite systems, it is worth 466 pointing out that some scenarios proposed may be relevant to other 467 wireless telecommunication systems. As one example, the generic 468 architecture proposed in Figure 1 may be mapped to cellular networks 469 as follows: the 'network function' block gathers some of the 470 functions of the Evolved Packet Core subsystem, while the 'access 471 gateway' and 'physical gateway' blocks gather the same type of 472 functions as the Universal Mobile Terrestrial Radio Access Network. 473 This mapping extends the opportunities identified in this draft since 474 they may be also relevant for cellular networks. 476 6. Glossary 478 The glossary of this memo extends the glossary of the taxonomy 479 document [RFC8406] as follows: 481 o ACM : Adaptive Coding and Modulation; 483 o BBFRAME: Base-Band FRAME - satellite communication layer 2 484 encapsulation work as follows: (1) each layer 3 packet is 485 encapsulated with a Generic Stream Encapsulation (GSE) mechanism, 486 (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs 487 contain information related to how they have to be modulated (4) 488 BBFRAMEs are forwarded to the physical-layer; 490 o CPE: Customer Premises Equipment; 492 o COM: COMmunication; 494 o DSL: Digital Subscriber Line; 496 o DTN: Delay/Disruption Tolerant Network; 498 o DVB: Digital Video Broadcasting; 500 o E2E: End-to-end; 502 o ETSI: European Telecommunications Standards Institute; 503 o FEC: Forward Erasure Correction; 505 o FLUTE: File Delivery over Unidirectional Transport; 507 o IntraF: Intra-Flow Coding; 509 o InterF: Inter-Flow Coding; 511 o IoT: Internet of Things; 513 o LTE: Long Term Evolution; 515 o MPC: Multi-Path Coding; 517 o NC: Network Coding; 519 o NFV: Network Function Virtualization; 521 o NORM: NACK-Oriented Reliable Multicast; 523 o PEP: Performance Enhancing Proxy [RFC3135] - a typical PEP for 524 satellite communications include compression, caching and TCP 525 acceleration; 527 o PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME 528 with additional information (e.g., related to synchronization); 530 o QEF: Quasi-Error-Free; 532 o QoE: Quality-of-Experience; 534 o QoS: Quality-of-Service; 536 o SAT: SATellite; 538 o SATCOM: generic term related to all kinds of SATellite 539 COMmunication systems; 541 o SPC: Single-Path Coding; 543 o VNF: Virtual Network Function. 545 7. Acknowledgements 547 Many thanks to John Border, Stuart Card, Tomaso de Cola, Vincent 548 Roca, Lloyd Wood and Marie-Jose Montpetit for their help in writing 549 this document. 551 8. IANA Considerations 553 This memo includes no request to IANA. 555 9. Security Considerations 557 Security considerations are inherent to any access network, and in 558 particular SATCOM systems. The use of FEC or Network Coding in 559 SATCOM also comes with risks (e.g., a single corrupted redundant 560 packet may propagate to several flows when they are protected 561 together in an Inter-Flow coding approach, see section Section 3). 562 However this is not specific to the SATCOM use-case and this document 563 does not further elaborate on it. 565 10. Informative References 567 [ASMS2010] 568 De Cola, T. and et. al., "Demonstration at opening session 569 of ASMS 2010", Advanced Satellite Multimedia Systems 570 (ASMS) Conference , 2010. 572 [CCSDS-131.5-O-1] 573 "Erasure correcting codes for use in near-earth and deep- 574 space communications", CCSDS Experimental 575 specification 131.5-0-1, 2014. 577 [ETSITR2017] 578 "Satellite Earth Stations and Systems (SES); Multi-link 579 routing scheme in hybrid access network with heterogeneous 580 links", ETSI TR 103 351, 2017. 582 [I-D.chin-nfvrg-cloud-5g-core-structure-yang] 583 Chen, C. and Z. Pan, "Yang Data Model for Cloud Native 5G 584 Core structure", draft-chin-nfvrg-cloud-5g-core-structure- 585 yang-00 (work in progress), December 2017. 587 [I-D.vazquez-nfvrg-netcod-function-virtualization] 588 Vazquez-Castro, M., Do-Duy, T., Romano, S., and A. Tulino, 589 "Network Coding Function Virtualization", draft-vazquez- 590 nfvrg-netcod-function-virtualization-02 (work in 591 progress), November 2017. 593 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 594 Shelby, "Performance Enhancing Proxies Intended to 595 Mitigate Link-Related Degradations", RFC 3135, 596 DOI 10.17487/RFC3135, June 2001, 597 . 599 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 600 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 601 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 602 April 2007, . 604 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 605 "NACK-Oriented Reliable Multicast (NORM) Transport 606 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 607 . 609 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 610 "FLUTE - File Delivery over Unidirectional Transport", 611 RFC 6726, DOI 10.17487/RFC6726, November 2012, 612 . 614 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 615 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 616 Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and 617 S. Sivakumar, "Taxonomy of Coding Techniques for Efficient 618 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 619 June 2018, . 621 [SAT2017] Ahmed, T., Dubois, E., Dupe, JB., Ferrus, R., Gelard, P., 622 and N. Kuhn, "Software-defined satellite cloud RAN", 623 International Journal on Satellite Communnications and 624 Networking vol. 36 - https://doi.org/10.1002/sat.1206, 625 2017. 627 [SHINE] Pietro Romano, S. and et. al., "Secure Hybrid In Network 628 caching Environment (SHINE) ESA project", ESA project , 629 2017 on-going. 631 [THAI15] Thai, T., Chaganti, V., Lochin, E., Lacan, J., Dubois, E., 632 and P. Gelard, "Enabling E2E reliable communications with 633 adaptive re-encoding over delay tolerant networks", 634 Proceedings of the IEEE International Conference on 635 Communications http://dx.doi.org/10.1109/ICC.2015.7248441, 636 June 2015. 638 Authors' Addresses 640 Nicolas Kuhn (editor) 641 CNES 642 18 Avenue Edouard Belin 643 Toulouse 31400 644 France 646 Email: nicolas.kuhn@cnes.fr 647 Emmanuel Lochin (editor) 648 ISAE-SUPAERO 649 10 Avenue Edouard Belin 650 Toulouse 31400 651 France 653 Email: emmanuel.lochin@isae-supaero.fr