idnits 2.17.1 draft-kuhn-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 8, 2018) is 2180 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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: November 9, 2018 ISAE-SUPAERO 6 May 8, 2018 8 Network coding and satellites 9 draft-kuhn-nwcrg-network-coding-satellites-04 11 Abstract 13 This memo presents the current deployment of network coding in some 14 satellite telecommunications systems along with a discussion on the 15 multiple opportunities to introduce these techniques at a wider 16 scale. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 9, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. A note on satellite topology . . . . . . . . . . . . . . . . 3 56 3. Status of network coding in actually deployed satellite 57 systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Details on the use cases . . . . . . . . . . . . . . . . . . 5 59 4.1. Two way relay channel mode . . . . . . . . . . . . . . . 5 60 4.2. Reliable multi-cast . . . . . . . . . . . . . . . . . . . 6 61 4.3. Hybrid access . . . . . . . . . . . . . . . . . . . . . . 7 62 4.4. Dealing with varying capacity . . . . . . . . . . . . . . 7 63 4.5. Improving the gateway handovers . . . . . . . . . . . . . 8 64 4.6. Delay/Disruption Tolerant Networks . . . . . . . . . . . 9 65 5. Discussion on the deployability . . . . . . . . . . . . . . . 10 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 67 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 10.2. Informative References . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 Network coding schemes are inherent part of the satellite systems as 78 the physical layer requires specific robustness to guarantee an 79 efficient usage of the expensive radio resource. Further exploiting 80 these schemes is an opportunity for a better end-user experience 81 along with a better exploitation of the scarce resource. 83 In this context, this memo aims at: 85 o summing up the current deployment of network coding schemes over 86 LEO and GEO satellite systems; 88 o identifying opportunities for further usage of network coding in 89 these systems. 91 1.1. Glossary 93 The glossary of this memo is related to the network coding taxonomy 94 document [I-D.irtf-nwcrg-network-coding-taxonomy]. 96 The glossary is extended as follows: 98 o BBFRAME: Base-Band FRAME; 100 o CPE: Customer Premise Equipment; 102 o DTN: Delay/Disruption Tolerant Network; 104 o EPC: Evolved Packet Core; 106 o ETSI: European Telecommunications Standards Institute; 108 o PEP: Performance Enhanced Proxy; 110 o PLFRAME: Physical Layer FRAME; 112 o SATCOM: SATellite COMmunications; 114 o UMTRAN: Universal Mobile Terrestrial Radio Access Network; 116 o QoS: Quality-of-Service; 118 o QoE: Quality-of-Experience; 120 o VNF: Virtualized Network Function. 122 1.2. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 2. A note on satellite topology 130 The objective of this section is to provide both a generic 131 description of the components composing a generic satellite system 132 and their interaction. It provides a high level description of a 133 multi-gateway satellites network. There exist multiple SATCOM 134 systems, such as those dedicated to broadcasting TV or to IoT 135 applications: depending on the purpose of the SATCOM system, ground 136 segments are specific. This memo lays on SATCOM systems dedicated to 137 Internet access that follows the DVB-S2/RCS2 standards. 139 In this context, Figure 1 shows an example of a multigateway 140 satellite system. More details on a generic SATCOM ground segment 141 architecture for a bi-directional Internet access can be found in 142 [SAT2017]. 144 It is worth noting that some functional blocks aggregate the traffic 145 coming from multiple users, allowing the deployment of network coding 146 schemes. 148 +---------------------+ 149 | Application servers | 150 +---------------------+ 151 | | | 152 | | | 153 ----------------------------------- 154 v v v v v v 155 +------------------+ +------------------+ 156 | network function | | network function | 157 | (firewall, PEP) | | (firewall, PEP) | 158 +------------------+ +------------------+ 159 | | | | 160 | | IP packets | | 161 v v v v 162 +------------------+ +------------------+ 163 | access gateway | | access gateway | 164 +------------------+ +------------------+ 165 | | 166 | BBFrames | 167 v v 168 +------------------+ +------------------+ 169 | physical gateway | | physical gateway | 170 +------------------+ +------------------+ 171 | | 172 | PLFrames | 173 v v 174 +------------------+ +------------------+ 175 | outdoor unit | | outdoor unit | 176 +------------------+ +------------------+ 177 | | | | 178 | | Satellite link | | 179 v v v v 180 +------------------+ +------------------+ 181 | sat terminals | | sat terminals | 182 +------------------+ +------------------+ 184 Figure 1: Data plane functions in a generic satellite multi-gateway 185 system 187 3. Status of network coding in actually deployed satellite systems 189 Figure 2 presents the status of the network coding deployment in 190 satellite systems. The information is based on the taxonomy document 191 [I-D.irtf-nwcrg-network-coding-taxonomy] and the notations are the 192 following: End-to-End Coding (E2E), Network Coding (NC), Intra-Flow 193 Coding (IntraF), Inter-Flow Coding (InterF), Single-Path Coding (SP) 194 and Multi-Path Coding (MP). 196 X1 embodies the source coding that could be used at application level 197 for instance: for video streaming on a broadband access. X2 embodies 198 the physical layer, applied to the PLFRAME, to optimize the satellite 199 capacity usage. Furthermore, at the physical layer and when random 200 accesses are exploited, FEC mechanisms are exploited. 202 +------+-------+---------+---------------+-------+ 203 | | Upper | Middle | Communication layers | 204 | | Appl. | ware | | 205 + +-------+---------+---------------+-------+ 206 | |Source | Network | Packetization | PHY | 207 | |coding | AL-FEC | UDP/IP | layer | 208 +------+-------+---------+---------------+-------+ 209 |E2E | X1 | | | | 210 |NC | | | | | 211 |IntraF| X1 | | | | 212 |InterF| | | | X2 | 213 |SP | X1 | | | X2 | 214 |MP | | | | | 215 +------+-------+---------+---------------+-------+ 217 Figure 2: Network coding and satellite systems 219 4. Details on the use cases 221 This section details use-cases where network coding schemes could 222 improve the overall performance of a SATCOM system (e.g. considering 223 a more efficient usage of the satellite resource, delivery delay, 224 delivery ratio). 226 It is worth noting that these use-cases focus more on the middle ware 227 (e.g. aggregation nodes) and packetization UDP/IP of Figure 2. 228 Indeed, there are already lots of recovery mechanisms at the physical 229 and access layers in currently deployed systems while E2E source 230 coding are done at the application level. In a multigateway SATCOM 231 Internet access, the specific opportunities are more relevant in 232 specific SATCOM components such as the "network function" block or 233 the "access gateway" of Figure 1. 235 4.1. Two way relay channel mode 237 This use-case considers a two-way communication between end users, 238 through a satellite link. We propose an illustration of this 239 scenario in Figure 3. 241 Satellite terminal A (resp. B) transmits a flow A (resp. B) to a 242 server hosting NC capabilities, which forward a combination of the 243 two flows to both terminals. This results in non-negligible 244 bandwidth saving and has been demonstrated at ASMS 2010 in Cagliari 245 [ASMS2010]. Moreover, with On-Board Processing satellite payloads, 246 the network coding operations could be done at the satellite level, 247 thus reducing the end-to-end delay of the communication. 249 +------------+ +-----+ +---------+ 250 | Satellite | A | | A | | 251 | Terminal A |-->--| | |->---| | +------+ 252 +------------+ | | |->---| | | | 253 || A+B ->-| SAT | B | Gateway | | | 254 ==================| | | |--|Server| 255 || ->-| | | | | | 256 +------------+ B |>-| |=====| | | | 257 | Satellite |-->--| | | A+B | | +------+ 258 | Terminal B | | | | | 259 +------------+ +-----+ +---------+ 261 Figure 3: Network architecture for two way relay channel with NC 263 4.2. Reliable multi-cast 265 This use-case considers adding redundancy to a multi-cast flow 266 depending on what has been received by different end-users, resulting 267 in non-negligible scarce resource saving. We propose an illustration 268 for this scenario in Figure 4. 270 A multi-cast flow (M) is forward to both satellite terminals A and B. 271 On the uplink, terminal A (resp. B) does not acknowledge the packet 272 Ni (resp. Nj) and either the access gateway or the multi-cast server 273 includes the missing packets in the multi-cast flow so that the 274 information transfer is reliable. This could be achieved by using 275 NACK-Oriented Reliable Multicast (NORM) [RFC5740]. However, NORM 276 does not consider other network coding schemes such as sliding window 277 encoding described in [I-D.irtf-nwcrg-network-coding-taxonomy]. 279 +------------+ +-----+ +---------+ 280 | Satellite |NACK Ni | |NACK Ni| | 281 | Terminal A |-->--| | |->-----| | +------+ 282 +------------+ | | |->-----| | | | 283 || M ->-| SAT |NACK Nj| | |Multi | 284 ==================| | | Gateway |--|Cast | 285 || ->-| | | | |Server| 286 +------------+ |>-| |=======| | | | 287 | Satellite |-->--| | | M | | +------+ 288 | Terminal B |NACK Nj | | | | 289 +------------+ +-----+ +---------+ 291 Figure 4: Network architecture for a reliable multi-cast with NC 293 4.3. Hybrid access 295 This use-case considers the use of multiple path management with 296 network coding at the transport level to either increase the 297 reliability or the total bandwidth. We propose an illustration for 298 this scenario in Figure 5. This use-case is inspired from the 299 Broadband Access via Integrated Terrestrial Satellite Systems (BATS) 300 project and has been published as an ETSI Technical Report 301 [ETSITR2017]. It is worth nothing that this kind of architecture is 302 also discussed in the MPTCP working group [I-D.boucadair-mptcp-dhc]. 304 To cope from packet loss (due to either end-user movements or 305 physical layer impairments), network coding could be introduced in 306 both the CPE and at the concentrator. 308 +-------------+ +----------------+ 309 |->| SAT NETWORK |---| BACKBONE | 310 | +-------------+ | +------------+ | 311 +------+ | | |CONCENTRATOR| | 312 | CPE |-->-| +-----+ | +------------+ | 313 +------+ |->| DSL |-----------| | 314 | +-----+ | | 315 | | | 316 | +-----+ | | 317 |->| LTE |-----------| | 318 +-----+ +----------------+ 320 Figure 5: Network architecture for an hybrid access using NC 322 4.4. Dealing with varying capacity 324 This use-case considers the usage of network coding to overcome cases 325 where the wireless link characteristics quickly change overtime and 326 where the physical layer codes could not be made robust in time. 328 This is particularly relevant when end users are moving and the 329 channel shows important variations [IEEEVT2001]. 331 The architecture is recalled in Figure 6. The network coding schemes 332 could be applied at the access gateway or the network function block 333 levels to increase the reliability of the transmission. This use- 334 case is mostly relevant for when mobile users are considered or when 335 the chosen band induce a required physical layer coding that may 336 change over time (Q/V bands, Ka band, etc.). 338 +------------+ +-----+ +---------+ +--------+ +---------+ 339 | Satellite | | SAT | | Physical| | Access | | Network | 340 | Terminal |->| |->| gateway |->| gateway|->| function| 341 +------------+ +-----+ +---------+ +--------+ +---------+ 342 NC? NC NC? NC? 344 Figure 6: Network architecture for dealing with varying link 345 characteristics with NC 347 4.5. Improving the gateway handovers 349 This use-case considers the recovery of packets that may be lost 350 during gateway handovers. Whether this is for off-loading one given 351 equipment or because the transmission quality is not the same on each 352 gateway, changing the transmission gateway may be relevant. However, 353 if gateways are not properly synchronized, this may result in packet 354 loss. During these critical phases, network coding can be added to 355 improve the reliability of the transmission and propose a seamless 356 gateway handover. 358 An example architecture for this use-case is showed in Figure 7. It 359 is worth noting that depending on the ground architecture 360 [I-D.chin-nfvrg-cloud-5g-core-structure-yang] [SAT2017], some 361 equipments might be communalised. 363 +---------+ +--------+ +---------+ 364 | Physical| | Access | | Network | 365 ----->| gateway |->| gateway|->| function| 366 | +---------+ +--------+ +---------+ 367 v | | 368 +------------+ +-----+ +-------------+ 369 | Satellite | | SAT | | Switching | 370 | Terminal |->| | | Entity | 371 +------------+ +-----+ +-------------+ 372 ^ | | 373 | +---------+ +--------+ +---------+ 374 ----->| Physical| | Access | | Network | 375 | gateway |->| gateway|->| function| 376 +---------+ +--------+ +---------+ 378 Figure 7: Network architecture for dealing with gateway handover 379 schemes with NC 381 4.6. Delay/Disruption Tolerant Networks 383 Establishing communications from terrestrial gateways to aerospace 384 components is a challenge due to the distances involved. As a matter 385 of fact, reliable end-to-end (E2E) communications over such links 386 must cope with long delay and frequent link disruptions. Delay/ 387 Disruption Tolerant Networking [RFC4838] is a solution to enable 388 reliable internetworking space communications where both standard ad- 389 hoc routing and E2E Internet protocols cannot be used. DTN can also 390 be seen as an alternative solution to cope with satellite 391 communications usually managed by PEP. Therefore, the transport of 392 data over such networks requires the use of replication, erasure 393 codes and multipath protocol schemes [WANG05] [ZHANG06] to improve 394 the bundle delivery ratio and/or delivery delay. For instance, 395 transport protocols such as LTP [RFC5326] for long delay links with 396 connectivity disruptions, use Automatic Repeat-reQuest (ARQ) and 397 unequal error protection to reduce the amount of non-mandatory 398 retransmissions. The work in [TOURNOUX10] proposed upon LTP a robust 399 streaming method based on an on-the-fly coding scheme, where encoding 400 and decoding procedures are done at the source and destination nodes, 401 respectively. However, each link path loss rate may have various 402 order of magnitude and re-encoding at an intermediate node to adapt 403 the redundancy can be mandatory to prevent transmission wasting. 404 This idea has been put forward in 405 [I-D.zinky-dtnrg-random-binary-fec-scheme] and 406 [I-D.zinky-dtnrg-erasure-coding-extension], where the authors 407 proposed an encoding process at intermediate DTN nodes to explore the 408 possibilities of Forward Error Correction (FEC) schemes inside the 409 bundle protocol [RFC5050]. Another proposal is the use of erasure 410 coding inside the CCSDS (Consultative Committee for Space Data 411 Systems) architecture [COLA11]. The objective is to extend the CCSDS 412 File Delivery Protocol (CFDP) [CCSDS-FDP] with erasure coding 413 capabilities where a Low Density Parity Check (LDPC) [RFC6816] code 414 with a large block size is chosen. Recently, on-the-fly erasure 415 coding schemes [LACAN08] [SUNDARARAJAN08] [TOURNOUX11] have shown 416 their benefits in terms of recovery capability and configuration 417 complexity compared to traditional FEC schemes. Using a feedback 418 path when available, on-the-fly schemes can be used to enable E2E 419 reliable communication over DTN with adaptive re-encoding as proposed 420 in [THAI15]. 422 5. Discussion on the deployability 424 This section discusses the deployability of the use-cases detailed in 425 Section 4. 427 SATCOM systems typically feature Proxy-Enhanced-Proxy RFC 3135 428 [RFC3135] which could be relevant to host network coding mechanisms 429 and thus support the use-cases that have been discussed in Section 4. 430 In particular the discussion on how network coding can be integrated 431 inside a PEP with QoS scheduler has been proposed in RFC 5865 432 [RFC5865]. 434 The generic architecture proposed in Figure 1 may be mapped to 435 cellular networks as follows: the 'network function' block gather 436 some of the functions of the Evolved Packet Core subsystem, while the 437 'access gateway' and 'physical gateway' blocks gather the same type 438 of functions as the Universal Mobile Terrestrial Radio Access 439 Network. This mapping extends the opportunities identified in this 440 draft since they may be also relevant for cellular networks. 442 Related to the foreseen virtualized network infrastructure, the 443 network coding schemes could be proposed as VNF and their 444 deployability enhanced. The architecture for the next generation of 445 SATCOM ground segments would rely on a virtualized environment. This 446 trend can also be seen, making the discussions on the deployability 447 of network coding in SATCOM extendable to other deployment scenarios 448 [I-D.chin-nfvrg-cloud-5g-core-structure-yang]. As one example, the 449 network coding VNF functions deployment in a virtualized environment 450 is presented in [I-D.vazquez-nfvrg-netcod-function-virtualization]. 452 6. Acknowledgements 454 Many thanks to Tomaso de Cola, Vincent Roca and Marie-Jose Montpetit. 456 7. Contributors 458 Tomaso de Cola, Vincent Roca, Marie-Jose Montpetit. 460 8. IANA Considerations 462 This memo includes no request to IANA. 464 9. Security Considerations 466 This document, by itself, presents no new privacy nor security 467 issues. 469 10. References 471 10.1. Normative References 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, 475 DOI 10.17487/RFC2119, March 1997, 476 . 478 10.2. Informative References 480 [ASMS2010] 481 De Cola, T. and et. al., "Demonstration at opening session 482 of ASMS 2010", ASMS , 2010. 484 [CCSDS-FDP] 485 "CCSDS File Delivery Protocol, Recommendation for Space 486 Data System Standards", CCSDS 727.0-B-4, Blue Book num. 3, 487 2007. 489 [COLA11] De Cola, T., Paolini, E., Liva, G., and G. Calzolari, 490 "Reliability options for data communications in the future 491 deep-space missions", Proceedings of the IEEE vol. 99 492 issue 11, 2011. 494 [ETSITR2017] 495 "Satellite Earth Stations and Systems (SES); Multi-link 496 routing scheme in hybrid access network with heterogeneous 497 links", ETSI TR 103 351, 2017. 499 [I-D.boucadair-mptcp-dhc] 500 Boucadair, M., Jacquenet, C., and T. Reddy, "DHCP Options 501 for Network-Assisted Multipath TCP (MPTCP)", draft- 502 boucadair-mptcp-dhc-08 (work in progress), October 2017. 504 [I-D.chin-nfvrg-cloud-5g-core-structure-yang] 505 Chen, C. and Z. Pan, "Yang Data Model for Cloud Native 5G 506 Core structure", draft-chin-nfvrg-cloud-5g-core-structure- 507 yang-00 (work in progress), December 2017. 509 [I-D.irtf-nwcrg-network-coding-taxonomy] 510 Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 511 F., samah.ghanem@gmail.com, s., Lochin, E., Masucci, A., 512 Montpetit, M., Pedersen, M., Peralta, G., Roca, V., 513 Saxena, P., and S. Sivakumar, "Taxonomy of Coding 514 Techniques for Efficient Network Communications", draft- 515 irtf-nwcrg-network-coding-taxonomy-08 (work in progress), 516 March 2018. 518 [I-D.vazquez-nfvrg-netcod-function-virtualization] 519 Vazquez-Castro, M., Do-Duy, T., Romano, S., and A. Tulino, 520 "Network Coding Function Virtualization", draft-vazquez- 521 nfvrg-netcod-function-virtualization-02 (work in 522 progress), November 2017. 524 [I-D.zinky-dtnrg-erasure-coding-extension] 525 Zinky, J., Caro, A., and G. Stein, "Bundle Protocol 526 Erasure Coding Extension", draft-zinky-dtnrg-erasure- 527 coding-extension-00 (work in progress), August 2012. 529 [I-D.zinky-dtnrg-random-binary-fec-scheme] 530 Zinky, J., Caro, A., and G. Stein, "Random Binary FEC 531 Scheme for Bundle Protocol", draft-zinky-dtnrg-random- 532 binary-fec-scheme-00 (work in progress), August 2012. 534 [IEEEVT2001] 535 Fontan, F., Vazquez-Castro, M., Cabado, C., Garcia, J., 536 and E. Kubista, "Statistical modeling of the LMS channel", 537 IEEE Transactions on Vehicular Technology vol. 50 issue 6, 538 2001. 540 [LACAN08] Lacan, J. and E. Lochin, "Rethinking reliability for long- 541 delay networks", International Workshop on Satellite and 542 Space Communications , October 2008. 544 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 545 Shelby, "Performance Enhancing Proxies Intended to 546 Mitigate Link-Related Degradations", RFC 3135, 547 DOI 10.17487/RFC3135, June 2001, 548 . 550 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 551 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 552 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 553 April 2007, . 555 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 556 Specification", RFC 5050, DOI 10.17487/RFC5050, November 557 2007, . 559 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 560 Transmission Protocol - Specification", RFC 5326, 561 DOI 10.17487/RFC5326, September 2008, 562 . 564 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 565 "NACK-Oriented Reliable Multicast (NORM) Transport 566 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 567 . 569 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 570 Services Code Point (DSCP) for Capacity-Admitted Traffic", 571 RFC 5865, DOI 10.17487/RFC5865, May 2010, 572 . 574 [RFC6816] Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density 575 Parity Check (LDPC) Staircase Forward Error Correction 576 (FEC) Scheme for FECFRAME", RFC 6816, 577 DOI 10.17487/RFC6816, December 2012, 578 . 580 [SAT2017] Ahmed, T., Dubois, E., Dupe, JB., Ferrus, R., Gelard, P., 581 and N. Kuhn, "Software-defined satellite cloud RAN", Int. 582 J. Satell. Commun. Network. vol. 36, 2017. 584 [SUNDARARAJAN08] 585 Sundararajan, J., Shah, D., and M. Medard, "ARQ for 586 network coding", IEEE Int. Symp. on Information Theory , 587 July 2008. 589 [THAI15] Thai, T., Chaganti, V., Lochin, E., Lacan, J., Dubois, E., 590 and P. Gelard, "Enabling E2E reliable communications with 591 adaptive re-encoding over delay tolerant networks", 592 Proceedings of the IEEE International Conference on 593 Communications , June 2015. 595 [TOURNOUX10] 596 Tournoux, P., Lochin, E., Leguay, J., and J. Lacan, "On 597 the benefits of random linear coding for unicast 598 applications in disruption tolerant networks", Proceedings 599 of the IEEE International Conference on Communications , 600 2010. 602 [TOURNOUX11] 603 Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and 604 V. Roca, "On-the-fly erasure coding for real-time video 605 applications", IEEE Trans. on Multimedia vol. 13 issue 4, 606 August 2011. 608 [WANG05] Wang, Y. and et. al., "Erasure-coding based routing for 609 opportunistic networks", Proceedings of the ACM SIGCOMM 610 workshop on Delay-tolerant networking , 2005. 612 [ZHANG06] Zhang, X. and et. al., "On the benefits of random linear 613 coding for unicast applications in disruption tolerant 614 networks", Proceedings of the 4th International Symposium 615 on Modeling and Optimization in Mobile, Ad Hoc and 616 Wireless Networks , 2006. 618 Authors' Addresses 620 Nicolas Kuhn (editor) 621 CNES 622 18 Avenue Edouard Belin 623 Toulouse 31400 624 France 626 Email: nicolas.kuhn@cnes.fr 628 Emmanuel Lochin (editor) 629 ISAE-SUPAERO 630 10 Avenue Edouard Belin 631 Toulouse 31400 632 France 634 Email: emmanuel.lochin@isae-supaero.fr