idnits 2.17.1 draft-irtf-nwcrg-network-coding-satellites-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Jan 3, 2019) is 1911 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5326' is defined on line 590, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-tcpm-converters-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 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: July 7, 2019 ISAE-SUPAERO 6 Jan 3, 2019 8 Network coding and satellites 9 draft-irtf-nwcrg-network-coding-satellites-04 11 Abstract 13 This memo details a multi-gateway satellite system to identify 14 multiple opportunities on how coding techniques could be deployed at 15 a wider scale. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 7, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. A note on satellite topology . . . . . . . . . . . . . . . . 4 54 3. Actual deployment of reliability schemes in satellite systems 6 55 4. Details on the use cases . . . . . . . . . . . . . . . . . . 7 56 4.1. Two-way relay channel mode . . . . . . . . . . . . . . . 7 57 4.2. Reliable multicast . . . . . . . . . . . . . . . . . . . 8 58 4.3. Hybrid access . . . . . . . . . . . . . . . . . . . . . . 8 59 4.4. Dealing with varying capacity . . . . . . . . . . . . . . 9 60 4.5. Improving the gateway handovers . . . . . . . . . . . . . 10 61 5. Research challenges . . . . . . . . . . . . . . . . . . . . . 11 62 5.1. Towards an increased deployability in SATCOM systems . . 11 63 5.2. Interaction with virtualization . . . . . . . . . . . . . 11 64 5.3. Delay/Disruption Tolerant Networks . . . . . . . . . . . 12 65 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 10. Informative References . . . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 72 1. Introduction 74 Guaranteeing both physical-layer robustness and efficient usage of 75 the radio resource has been in the core design of SATellite 76 COMmunication (SATCOM) systems. The trade-off often resided in how 77 much redundancy a system adds to cope from link impairments, without 78 reducing the good-put when the channel quality is high. There is 79 usually enough redundancy to guarantee a Quasi-Error Free 80 transmission. However, physical layer reliability mechanisms may not 81 recover transmission losses (e.g. with a mobile user) and layer 2 (or 82 above) re-transmissions induce 500 ms one-way delay with a 83 geostationary satellite. Further exploiting coding schemes at higher 84 OSI-layers is an opportunity for releasing constraints on the 85 physical layer in such cases and improving the performance of SATCOM 86 systems. 88 We have noticed an active research activity on coding and SATCOM in 89 the past. That being said, not much has actually made it to 90 industrial developments. In this context, this document aims at 91 identifying opportunities for further usage of coding in these 92 systems. 94 This document follows the taxonomy of coding techniques for efficient 95 network communications [RFC8406]. 97 1.1. Glossary 99 The glossary of this memo extends the glossary of the taxonomy 100 document [RFC8406] as follows: 102 o ACM : Adaptative Coding and Modulation; 104 o BBFRAME: Base-Band FRAME - satellite communication layer 2 105 encapsulation work as follows: (1) each layer 3 packet is 106 encapsulated with a Generic Stream Encapsulation (GSE) mechanism, 107 (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs 108 contain information related to how they have to be modulated (4) 109 BBFRAMEs are forwarded to the physical-layer; 111 o CPE: Customer Premise Equipment; 113 o COM: COMmunication; 115 o DSL: Digital Subscriber Line; 117 o DTN: Delay/Disruption Tolerant Network; 119 o ETSI: European Telecommunications Standards Institute; 121 o FEC: Forward Erasure Correction; 123 o FLUTE: File Delivery over Unidirectional Transport; 125 o IoT: Internet of Things; 127 o LTE: Long Term Evolution; 129 o NFV: Network Function Virtualization; 131 o NORM: NACK-Oriented Reliable Multicast; 133 o PEP: Performance Enhanced Proxy [RFC3135] - a typical PEP for 134 satellite communications include compression, caching and TCP 135 acceleration; 137 o PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME 138 with additional information (e.g. related to synchronization); 140 o QEF: Quasi-Error-Free; 142 o QoE: Quality-of-Experience; 144 o QoS: Quality-of-Service; 145 o SAT: SATellite; 147 o SATCOM: generic term related to all kind of SATellite 148 COMmunication systems; 150 o VNF: Virtual Network Function. 152 2. A note on satellite topology 154 This section describes the components in satellite system that lays 155 on SATCOM systems dedicated to broadband Internet access that follows 156 the DVB standards. A high-level description of a multi-gateway 157 satellites network is provided. There are multiple SATCOM systems, 158 such as those dedicated to broadcasting TV or to IoT applications: 159 depending on the purpose of the SATCOM system, ground segments are 160 specific. In this context, the increase of the available capacity 161 that is carried out to end users and reliability requirements lead to 162 multiple gateways for one unique satellite platform. 164 In this context, Figure 1 shows an example of a multi-gateway 165 satellite system. In a multi-gateway system, some elements may be 166 centralized and/or gathered: the relevance of one approach compared 167 to another depends on the deployment scenario. More information on 168 these discussions and a generic SATCOM ground segment architecture 169 for a bi-directional Internet access can be found in [SAT2017]. 171 Some functional blocks aggregate the traffic of multiple users. 172 Coding schemes could be applied on both single and aggregated 173 traffic. 175 +---------------------+ 176 | application servers | 177 +---------------------+ 178 ^ ^ 179 | ... | 180 ----------------------------------- 181 v v v v v v 182 +------------------+ +------------------+ 183 | network function | | network function | 184 | (firewall, PEP) | | (firewall, PEP) | 185 +------------------+ +------------------+ 186 ^ ^ ^ ^ 187 | ... | IP packets | ... | 188 v v v v 189 +------------------+ +------------------+ 190 | access gateway | | access gateway | 191 +------------------+ +------------------+ 192 ^ ^ 193 | BBFRAME | 194 v v 195 +------------------+ +------------------+ 196 | physical gateway | | physical gateway | 197 +------------------+ +------------------+ 198 ^ ^ 199 | PLFRAME | 200 v v 201 +------------------+ +------------------+ 202 | outdoor unit | | outdoor unit | 203 +------------------+ +------------------+ 204 ^ ^ 205 | satellite link | 206 v v 207 +------------------+ +------------------+ 208 | sat terminals | | sat terminals | 209 +------------------+ +------------------+ 210 ^ ^ ^ ^ 211 | ... | | ... | 212 v v v v 213 +------------------+ +------------------+ 214 | end user | | end user | 215 +------------------+ +------------------+ 217 Figure 1: Data plane functions in a generic satellite multi-gateway 218 system 220 3. Actual deployment of reliability schemes in satellite systems 222 The notations used in this section are based on the taxonomy document 223 [RFC8406]: End-to-End Coding (E2E), Network Coding (NC), Intra-Flow 224 Coding (IntraF), Inter-Flow Coding (InterF), Single-Path Coding (SPC) 225 and Multi-Path Coding (MPC). This document refers to coding as both 226 End-to-End Coding and Network Coding, to cover cases where where 227 recoding operation at intermediate nodes are or not. From the UDP/IP 228 packetization to the channel coding, link layer coding is required so 229 that the physical-layer knows what coding scheme to use. Following 230 the taxonomy document [RFC8406], channel and link codings are 231 gathered in the PHY layer coding and are out of the scope of this 232 document. 234 Figure 2 presents the status of the reliability schemes deployment in 235 satellite systems. 237 o X1 embodies the source coding that could be used at application 238 level for instance within QUIC or other video streaming 239 applications. This is not specific to SATCOM systems since such 240 deployment can be relevant for broadband Internet access 241 discussions. 243 o X2 embodies the physical-layer, applied to the PLFRAME, to 244 optimize the satellite capacity usage. At the physical layer, FEC 245 mechanisms can be exploited. 247 +------+-------+---------+---------------+-------+ 248 | | Upper | Middle | Communication layers | 249 | | Appl. | ware | | 250 + +-------+---------+---------------+-------+ 251 | |Source | Network | Packetization | PHY | 252 | |coding | AL-FEC | UDP/IP | layer | 253 +------+-------+---------+---------------+-------+ 254 |E2E | X1 | | | | 255 |NC | | | | | 256 |IntraF| X1 | | | | 257 |InterF| | | | X2 | 258 |SPC | X1 | | | X2 | 259 |MPC | | | | | 260 +------+-------+---------+---------------+-------+ 262 Figure 2: Reliability schemes in current satellite systems 264 Reliability is an inherent part of the physical-layer and usually 265 achieved by using coding techniques. Based on public information, 266 coding does not seem to be widely used at higher layers. 268 4. Details on the use cases 270 This section details use-cases where coding schemes could improve the 271 overall performance of a SATCOM system (e.g. considering a more 272 efficient usage of the satellite resource, delivery delay, delivery 273 ratio). 275 It is worth noting that these use-cases mostly focus on the 276 middleware and packetization UDP/IP of Figure 2. There are already 277 lots of recovery mechanisms at the physical-layer in currently 278 deployed systems while E2E source coding is done at the application 279 level. In a multi-gateway SATCOM Internet access, the deployment 280 opportunities are more relevant in specific SATCOM components such as 281 the "network function" block or the "access gateway" of Figure 1. 283 4.1. Two-way relay channel mode 285 This use-case considers a two-way communication between end users, 286 through a satellite link. Figure 3 proposes an illustration of this 287 scenario. 289 Satellite terminal A sends a flow A and satellite terminal B sends a 290 flow B to a NC server. The NC server sends a combination of both 291 terminal flows. This results in non-negligible capacity savings and 292 has been demonstrated [ASMS2010]. Moreover, with On-Board Processing 293 satellite payloads, the coding operations could be done at the 294 satellite level. 296 -X}- : traffic from satellite terminal X to the server 297 ={X+Y= : traffic from X and Y combined sent from 298 the server to terminals X and Y 300 +-----------+ +-----+ 301 |Sat term A |--A}-+ | | 302 +-----------+ | | | +---------+ +------+ 303 ^^ +--| |--A}--| |--A}--| | 304 || | SAT |--B}--| Gateway |--B}--|Server| 305 ===={A+B=========| |={A+B=| |={A+B=| | 306 || | | +---------+ +------+ 307 vv +--| | 308 +-----------+ | | | 309 |Sat term B |--B}-+ | | 310 +-----------+ +-----+ 312 Figure 3: Network architecture for two way relay channel with NC 314 4.2. Reliable multicast 316 Using multicast servers is a way to better exploit the satellite 317 broadcast capabilities. This approach is proposed in the SHINE ESA 318 project [I-D.vazquez-nfvrg-netcod-function-virtualization] [SHINE]. 319 This use-case considers adding redundancy to a multicast flow 320 depending on what has been received by different end-users, resulting 321 in non-negligible scarce resource saving. We propose an illustration 322 for this scenario in Figure 4. 324 A multicast flow (M) is forwarded to both satellite terminals A and 325 B. However packet Ni (resp. Nj) get lost at terminal A (resp. B), 326 and terminal A (resp. B) returns a negative acknowledgment Li (resp. 327 Lj), indicating that the packet is missing. Then either the access 328 gateway or the multicast server includes a repair packet (rather than 329 the individual Ni and Nj packets) in the multicast flow to let both 330 terminals recover from losses. This could be achieved by using NACK- 331 Oriented Reliable Multicast (NORM) [RFC5740] in situations where a 332 feedback link is available, or File Delivery over Unidirectional 333 Transport (FLUTE) [RFC6726] otherwise. Note that both NORM and FLUTE 334 are limited to block coding, none of them supporting sliding window 335 encoding schemes [RFC8406]. 337 -Li}- : packet indicating the loss of packet i of a multicast flow M 338 ={M== : multicast flow including the missing packets 340 +-----------+ +-----+ 341 |Sat term A |-Li}-+ | | 342 +-----------+ | | | +---------+ +------+ 343 ^^ +-| |-Li}--| | |Multi | 344 || | SAT |-Lj}--| Gateway |--|Cast | 345 ===={M==========| |={M===| | |Server| 346 || | | +---------+ +------+ 347 vv +-| | 348 +-----------+ | | | 349 |Sat term B |-Lj}-+ | | 350 +-----------+ +-----+ 352 Figure 4: Network architecture for a reliable multicast with NC 354 4.3. Hybrid access 356 This use-case considers the use of multiple path management with 357 coding at the transport level to increase the reliability and/or the 358 total capacity (using multiple path does not guarantee an improvement 359 of both the reliability and the total capacity). We propose an 360 illustration for this scenario in Figure 5. This use-case is 361 inspired from the Broadband Access via Integrated Terrestrial 362 Satellite Systems (BATS) project and has been published as an ETSI 363 Technical Report [ETSITR2017]. This kind of architecture is also 364 discussed in the TCPM working group [I-D.ietf-tcpm-converters]. 366 To cope with packet loss (due to either end-user mobility or 367 physical-layer impairments), coding could be introduced in both the 368 CPE and at the concentrator. 370 -{}- : bidirectional link 372 +-----+ +----------------+ 373 +-{}-| SAT |-{}-| BACKBONE | 374 +------+ +------+ | +-----+ | +------------+ | 375 | End |-{}-| CPE |-{}-| | |CONCENTRATOR| | 376 | User | | | | +-----+ | +------------+ | +------+ 377 +------+ +------+ |-{}-| DSL |-{}-| |-{}-|Data | 378 | +-----+ | | |Server| 379 | | | +------+ 380 | +-----+ | | 381 +-{}-| LTE |-{}-| | 382 +-----+ +----------------+ 384 Figure 5: Network architecture for an hybrid access using NC 386 4.4. Dealing with varying capacity 388 This use-case considers the usage of coding to cope with cases where 389 channel condition can change in less than a second and where the 390 physical-layer codes could not guarantee a Quasi-Error-Free (QEF) 391 transmission. 393 The architecture is recalled in Figure 6. In these cases, Adaptative 394 Coding and Modulation (ACM) may not adapt the modulation and coding 395 accordingly and remaining errors could be recovered with higher 396 layers redundancy packets. The coding schemes could be applied at 397 the access gateway or the network function block levels to increase 398 the reliability of the transmission. Coding may be applied on IP 399 packets or on layer-2 proprietary format packets. 401 This use-case is mostly relevant for when mobile users are considered 402 or when the chosen band induce a required physical-layer coding that 403 may change over time (Q/V bands, Ka band, etc.). Depending on the 404 use-case (e.g. very high frequency bands, mobile users) or depending 405 on the deployment use-cases (e.g. performance of the network between 406 each individual block), the relevance of adding coding is different. 408 -{}- : bidirectional link 410 +---------+ +---+ +--------+ +-------+ +--------+ 411 |Satellite| |SAT| |Physical| |Access | |Network | 412 |Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function| 413 +---------+ +---+ +--------+ +-------+ +--------+ 414 NC NC NC NC 416 Figure 6: Network architecture for dealing with varying link 417 characteristics with NC 419 4.5. Improving the gateway handovers 421 This use-case considers the recovery of packets that may be lost 422 during gateway handovers. Whether this is for off-loading one given 423 equipment or because the transmission quality is not the same on each 424 gateway, changing the transmission gateway may be relevant. However, 425 if gateways are not properly synchronized, this may result in packet 426 loss. During these critical phases, coding can be added to improve 427 the reliability of the transmission and allow a seamless gateway 428 handover. Coding could be applied at either the access gateway or 429 the network function block. The control plane manager is in charge 430 of taking the decision to change the communication gateway and the 431 consequent routes. 433 Figure 7 illustrates this use-case. Depending on the ground 434 architecture [I-D.chin-nfvrg-cloud-5g-core-structure-yang] [SAT2017], 435 some equipment might be communalised. 437 -{}- : bidirectional link 438 ! : management interface 439 NC NC 440 +--------+ +-------+ +--------+ 441 |Physical| |Access | |Network | 442 +-{}-|gateway |-{}-|gateway|-{}-|function| 443 | +--------+ +-------+ +--------+ 444 | ! ! 445 +---------+ +---+ +---------------+ 446 |Satellite| |SAT| | Control plane | 447 |Terminal |-{}-| | | manager | 448 +---------+ +---+ +---------------+ 449 | ! ! 450 | +--------+ +-------+ +--------+ 451 +-{}-|Physical|-{}-|Access |-{}-|Network | 452 |gateway | |gateway| |function| 453 +--------+ +-------+ +--------+ 454 NC NC 456 Figure 7: Network architecture for dealing with gateway handover 457 schemes with NC 459 5. Research challenges 461 5.1. Towards an increased deployability in SATCOM systems 463 SATCOM systems typically feature Performance Enhancement Proxy (PEP) 464 RFC 3135 [RFC3135]. PEP usually split TCP end-to-end connections and 465 forward TCP packets to the satellite baseband gateway that deals with 466 layer-2 and layer-1 encapsulations. PEP could host coding mechanisms 467 and thus support the use-cases that have been discussed in this 468 document. 470 Deploying coding schemes at the TCP level in these equipment could be 471 relevant and independent from the specific characteristics of a 472 SATCOM link. However, there is a research issue in the recurrent 473 trade-off in SATCOM systems: how much overhead from redundant 474 reliability packets can be introduced to guarantee a better end-user 475 QoE while optimizing capacity usage ? 477 5.2. Interaction with virtualization 479 Related to the foreseen virtualized network infrastructure, coding 480 schemes could be easily deployed as VNF. Next generation of SATCOM 481 ground segments could rely on a virtualized environment. This trend 482 can also be seen in cellular networks, making these discussions 483 extendable to other deployment scenarios 484 [I-D.chin-nfvrg-cloud-5g-core-structure-yang]. As one example, the 485 coding VNF functions deployment in a virtualized environment is 486 presented in [I-D.vazquez-nfvrg-netcod-function-virtualization]. 488 A research challenge would be the optimization of the NFV service 489 function chaining, considering a virtualized infrastructure and other 490 SATCOM specific functions, to guarantee an efficient radio usage and 491 easy-to-deploy SATCOM services. 493 5.3. Delay/Disruption Tolerant Networks 495 In the context of the deep-space communications, establishing 496 communications from terrestrial gateways to satellite platforms can 497 be a challenge. Reliable end-to-end (E2E) communications over such 498 links must cope with long delay and frequent link disruptions. 499 Delay/Disruption Tolerant Networking [RFC4838] is a solution to 500 enable reliable internetworking space communications where both 501 standard ad-hoc routing and E2E Internet protocols cannot be used. 502 Moreover, DTN can also be seen as an alternative solution to transfer 503 the data between a central PEP and a remote PEP. 505 Coding enables E2E reliable communication over DTN with adaptive re- 506 encoding, as proposed in [THAI15]. In this case, the use-cases 507 proposed in Section 4.4 would legitimate the usage of coding within 508 the DTN stack to improve the channel utilization and the E2E 509 transmission delay. In this context, the use of erasure coding 510 inside a Consultative Committee for Space Data Systems (CCSDS) 511 architecture has been specified in [CCSDS-131.5-O-1]. A research 512 challenge would be on how such coding can be integrated in the IETF 513 DTN stack. 515 6. Conclusion 517 This document discuses some opportunities to introduce these 518 techniques at a wider scale in satellite telecommunications systems. 520 Even though this document focuses on satellite systems, it is worth 521 pointing out that the some scenarios proposed may be relevant to 522 other wireless telecommunication systems. As one example, the 523 generic architecture proposed in Figure 1 may be mapped to cellular 524 networks as follows: the 'network function' block gather some of the 525 functions of the Evolved Packet Core subsystem, while the 'access 526 gateway' and 'physical gateway' blocks gather the same type of 527 functions as the Universal Mobile Terrestrial Radio Access Network. 528 This mapping extends the opportunities identified in this draft since 529 they may be also relevant for cellular networks. 531 7. Acknowledgements 533 Many thanks to Tomaso de Cola, Vincent Roca, Lloyd Wood and Marie- 534 Jose Montpetit for their help in writing this document. 536 8. IANA Considerations 538 This memo includes no request to IANA. 540 9. Security Considerations 542 Security considerations are inherent to any access network. SATCOM 543 systems introduce standard security mechanisms. On the specific 544 scenario of NC in SATCOM systems, there are no specific security 545 considerations. 547 10. Informative References 549 [ASMS2010] 550 De Cola, T. and et. al., "Demonstration at opening session 551 of ASMS 2010", ASMS , 2010. 553 [CCSDS-131.5-O-1] 554 CCSDS, "Erasure correcting codes for use in near-earth and 555 deep-space communications", CCSDS Experimental 556 specification 131.5-0-1, 2014. 558 [ETSITR2017] 559 "Satellite Earth Stations and Systems (SES); Multi-link 560 routing scheme in hybrid access network with heterogeneous 561 links", ETSI TR 103 351, 2017. 563 [I-D.chin-nfvrg-cloud-5g-core-structure-yang] 564 Chen, C. and Z. Pan, "Yang Data Model for Cloud Native 5G 565 Core structure", draft-chin-nfvrg-cloud-5g-core-structure- 566 yang-00 (work in progress), December 2017. 568 [I-D.ietf-tcpm-converters] 569 Bonaventure, O., Boucadair, M., Gundavelli, S., and S. 570 Seo, "0-RTT TCP Convert Protocol", draft-ietf-tcpm- 571 converters-04 (work in progress), October 2018. 573 [I-D.vazquez-nfvrg-netcod-function-virtualization] 574 Vazquez-Castro, M., Do-Duy, T., Romano, S., and A. Tulino, 575 "Network Coding Function Virtualization", draft-vazquez- 576 nfvrg-netcod-function-virtualization-02 (work in 577 progress), November 2017. 579 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 580 Shelby, "Performance Enhancing Proxies Intended to 581 Mitigate Link-Related Degradations", RFC 3135, 582 DOI 10.17487/RFC3135, June 2001, 583 . 585 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 586 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 587 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 588 April 2007, . 590 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 591 Transmission Protocol - Specification", RFC 5326, 592 DOI 10.17487/RFC5326, September 2008, 593 . 595 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 596 "NACK-Oriented Reliable Multicast (NORM) Transport 597 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 598 . 600 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 601 "FLUTE - File Delivery over Unidirectional Transport", 602 RFC 6726, DOI 10.17487/RFC6726, November 2012, 603 . 605 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 606 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 607 Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and 608 S. Sivakumar, "Taxonomy of Coding Techniques for Efficient 609 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 610 June 2018, . 612 [SAT2017] Ahmed, T., Dubois, E., Dupe, JB., Ferrus, R., Gelard, P., 613 and N. Kuhn, "Software-defined satellite cloud RAN", Int. 614 J. Satell. Commun. Network. vol. 36, 2017. 616 [SHINE] Pietro Romano, S. and et. al., "Secure Hybrid In Network 617 caching Environment (SHINE) ESA project", ESA project , 618 2017 on-going. 620 [THAI15] Thai, T., Chaganti, V., Lochin, E., Lacan, J., Dubois, E., 621 and P. Gelard, "Enabling E2E reliable communications with 622 adaptive re-encoding over delay tolerant networks", 623 Proceedings of the IEEE International Conference on 624 Communications , June 2015. 626 Authors' Addresses 628 Nicolas Kuhn (editor) 629 CNES 630 18 Avenue Edouard Belin 631 Toulouse 31400 632 France 634 Email: nicolas.kuhn@cnes.fr 636 Emmanuel Lochin (editor) 637 ISAE-SUPAERO 638 10 Avenue Edouard Belin 639 Toulouse 31400 640 France 642 Email: emmanuel.lochin@isae-supaero.fr