idnits 2.17.1 draft-kuhn-nwcrg-network-coding-satellites-05.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 (July 2, 2018) is 2124 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: January 3, 2019 ISAE-SUPAERO 6 July 2, 2018 8 Network coding and satellites 9 draft-kuhn-nwcrg-network-coding-satellites-05 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 January 3, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. A note on satellite topology . . . . . . . . . . . . . . . . 4 56 3. Status of network coding in actually deployed satellite 57 systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4. Details on the use cases . . . . . . . . . . . . . . . . . . 6 59 4.1. Two way relay channel mode . . . . . . . . . . . . . . . 7 60 4.2. Reliable multicast . . . . . . . . . . . . . . . . . . . 7 61 4.3. Hybrid access . . . . . . . . . . . . . . . . . . . . . . 8 62 4.4. Dealing with varying capacity . . . . . . . . . . . . . . 9 63 4.5. Improving the gateway handovers . . . . . . . . . . . . . 10 64 4.6. Delay/Disruption Tolerant Networks . . . . . . . . . . . 10 65 5. Discussion on the deployability . . . . . . . . . . . . . . . 11 66 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 68 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 73 11.2. Informative References . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 Guaranteeing both physical layer robustness and efficient usage of 79 the radio resource has been in the core design of SATellite 80 COMmunication (SATCOM) systems. The trade-off often resided in how 81 much redundancy a system had to add to cope from link impairments, 82 without reducing the good-put when the channel quality is high. 83 Generally speaking, enough redundancy is added so as to guarantee a 84 Quasi-Error Free transmission; however, there are cases where the 85 physical layer could hardly recover the transmission losses (e.g. 86 with a mobile user) and layer 2 (or above) re-transmissions induce an 87 at least 500 ms delay with a geostationary satellite. Further 88 exploiting network coding schemes at higher OSI-layers is an 89 opportunity for releasing constraints on the physical layer and 90 improve the performance of SATCOM systems when the physical layer is 91 challenged. We have noticed an active research activity on how 92 network coding and SATCOM in the past. That being said, not much has 93 actually made it to industrial developments. In this context, this 94 memo aims at: 96 o summing up the current deployment of network coding schemes over 97 LEO and GEO satellite systems; 99 o identifying opportunities for further usage of network coding in 100 these systems. 102 1.1. Glossary 104 The glossary of this memo is related to the network coding taxonomy 105 document [I-D.irtf-nwcrg-network-coding-taxonomy]. 107 The glossary is extended as follows: 109 o BBFRAME: Base-Band FRAME - satellite communication layer 2 110 encapsulation work as follows: (1) each layer 3 packet is 111 encapsulated with a Generic Stream Encapsulation (GSE) mechanism, 112 (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs 113 contain information related to how they have to be modulated (4) 114 BBFRAMEs are forwarded to the physical layer; 116 o CPE: Customer Premise Equipment; 118 o DTN: Delay/Disruption Tolerant Network; 120 o EPC: Evolved Packet Core; 122 o ETSI: European Telecommunications Standards Institute; 124 o PEP: Performance Enhanced Proxy - a typical PEP for satellite 125 communications include compression, caching and TCP acceleration; 127 o PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME 128 with additional information (e.g. related to synchronization); 130 o SATCOM: generic term related to all kind of SATellite 131 COMmunications systems; 133 o UMTRAN: Universal Mobile Terrestrial Radio Access Network; 135 o QoS: Quality-of-Service; 137 o QoE: Quality-of-Experience; 139 o VNF: Virtualized Network Function. 141 1.2. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 2. A note on satellite topology 149 The objective of this section is to provide both a generic 150 description of the components composing a generic satellite system 151 and their interaction. It provides a high level description of a 152 multi-gateway satellites network. There exist multiple SATCOM 153 systems, such as those dedicated to broadcasting TV or to IoT 154 applications: depending on the purpose of the SATCOM system, ground 155 segments are specific. This memo lays on SATCOM systems dedicated to 156 Internet access that follows the DVB-S2/RCS2 standards. 158 In this context, Figure 1 shows an example of a multi-gateway 159 satellite system. More details on a generic SATCOM ground segment 160 architecture for a bi-directional Internet access can be found in 161 [SAT2017]. We propose a multi-gateway system since some of the use- 162 cases described in this document require multiple gateways. In a 163 multi-gateway system, some elements may be centralized and/or 164 gathered: the relevance of one approach compared to another depends 165 on the deployment scenario. More information on these trade-off 166 discussions can be found in [SAT2017]. 168 It is worth noting that some functional blocks aggregate the traffic 169 coming from multiple users. Even if network coding schemes could be 170 applied to any individual traffic, it could also work on a aggregate. 172 +---------------------+ 173 | Application servers | 174 +---------------------+ 175 ^ ^ ^ 176 | | | 177 ----------------------------------- 178 v v v v v v 179 +------------------+ +------------------+ 180 | network function | | network function | 181 | (firewall, PEP) | | (firewall, PEP) | 182 +------------------+ +------------------+ 183 ^ ^ ^ ^ 184 | | IP packets | | 185 v v v v 186 +------------------+ +------------------+ 187 | access gateway | | access gateway | 188 +------------------+ +------------------+ 189 ^ ^ 190 | BBFRAMEs | 191 v v 192 +------------------+ +------------------+ 193 | physical gateway | | physical gateway | 194 +------------------+ +------------------+ 195 ^ ^ 196 | PLFRAMEs | 197 v v 198 +------------------+ +------------------+ 199 | outdoor unit | | outdoor unit | 200 +------------------+ +------------------+ 201 ^ ^ 202 | Satellite link | 203 v v 204 +------------------+ +------------------+ 205 | sat terminals | | sat terminals | 206 +------------------+ +------------------+ 207 ^ ^ 208 | | 209 v v 210 +------------------+ +------------------+ 211 | end user | | end user | 212 +------------------+ +------------------+ 214 Figure 1: Data plane functions in a generic satellite multi-gateway 215 system 217 3. Status of network coding in actually deployed satellite systems 219 Figure 2 presents the status of the network coding deployment in 220 satellite systems. The information is based on the taxonomy document 221 [I-D.irtf-nwcrg-network-coding-taxonomy] and the notations are the 222 following: End-to-End Coding (E2E), Network Coding (NC), Intra-Flow 223 Coding (IntraF), Inter-Flow Coding (InterF), Single-Path Coding (SP) 224 and Multi-Path Coding (MP). 226 X1 embodies the source coding that could be used at application level 227 for instance: for video streaming on a broadband access. X2 embodies 228 the physical layer, applied to the PLFRAME, to optimize the satellite 229 capacity usage. Furthermore, at the physical layer and when random 230 accesses are exploited, FEC mechanisms are exploited. 232 +------+-------+---------+---------------+-------+ 233 | | Upper | Middle | Communication layers | 234 | | Appl. | ware | | 235 + +-------+---------+---------------+-------+ 236 | |Source | Network | Packetization | PHY | 237 | |coding | AL-FEC | UDP/IP | layer | 238 +------+-------+---------+---------------+-------+ 239 |E2E | X1 | | | | 240 |NC | | | | | 241 |IntraF| X1 | | | | 242 |InterF| | | | X2 | 243 |SP | X1 | | | X2 | 244 |MP | | | | | 245 +------+-------+---------+---------------+-------+ 247 Figure 2: Network coding in current satellite systems 249 4. Details on the use cases 251 This section details use-cases where network coding schemes could 252 improve the overall performance of a SATCOM system (e.g. considering 253 a more efficient usage of the satellite resource, delivery delay, 254 delivery ratio). 256 It is worth noting that these use-cases focus more on the middleware 257 (e.g. aggregation nodes) and packetization UDP/IP of Figure 2. 258 Indeed, there are already lots of recovery mechanisms at the physical 259 and access layers in currently deployed systems while E2E source 260 coding are done at the application level. In a multi-gateway SATCOM 261 Internet access, the specific opportunities are more relevant in 262 specific SATCOM components such as the "network function" block or 263 the "access gateway" of Figure 1. 265 4.1. Two way relay channel mode 267 This use-case considers a two-way communication between end users, 268 through a satellite link. We propose an illustration of this 269 scenario in Figure 3. 271 Satellite terminal A (resp. B) transmits a flow A (resp. B) to a 272 server hosting NC capabilities, which forward a combination of the 273 two flows to both terminals. This results in non-negligible 274 bandwidth saving and has been demonstrated at ASMS 2010 in Cagliari 275 [ASMS2010]. Moreover, with On-Board Processing satellite payloads, 276 the network coding operations could be done at the satellite level, 277 thus reducing the end-to-end delay of the communication. 279 -X>- : traffic from satellite terminal X to the server 280 ={X+Y= : traffic from X and Y combined transmitted from 281 the server to terminals X and Y 283 +-----------+ +-----+ 284 |Sat term A |--A>-+ | | 285 +-----------+ | | | +---------+ +------+ 286 ^^ +--| |--A>--| |--A>--| | 287 || | SAT |--B>--| Gateway |--B>--|Server| 288 ===={A+B=========| |={A+B=| |={A+B=| | 289 || | | +---------+ +------+ 290 vv +--| | 291 +-----------+ | | | 292 |Sat term B |--B>-+ | | 293 +-----------+ +-----+ 295 Figure 3: Network architecture for two way relay channel with NC 297 4.2. Reliable multicast 299 This use-case considers adding redundancy to a multicast flow 300 depending on what has been received by different end-users, resulting 301 in non-negligible scarce resource saving. We propose an illustration 302 for this scenario in Figure 4. 304 A multicast flow (M) is forward to both satellite terminals A and B. 305 On the uplink, terminal A (resp. B) does not acknowledge the packet 306 Ni by sending a Li signal (resp. Nj, Lj) and either the access 307 gateway or the multicast server includes the missing packets in the 308 multicast flow so that the information transfer is reliable. This 309 could be achieved by using NACK-Oriented Reliable Multicast (NORM) 310 [RFC5740]. However, NORM does not consider other network coding 311 schemes such as sliding window encoding described in 312 [I-D.irtf-nwcrg-network-coding-taxonomy]. 314 -Li>- : packet indicated the loss of packet i of a multicast flow 315 ={M== : multicast flow including the missing packets 317 +-----------+ +-----+ 318 |Sat term A |-Li>-+ | | 319 +-----------+ | | | +---------+ +------+ 320 ^^ +-| |-Li>--| | |Multi | 321 || | SAT |-Lj>--| Gateway |--|Cast | 322 ===={M==========| |={M===| | |Server| 323 || | | +---------+ +------+ 324 vv +-| | 325 +-----------+ | | | 326 |Sat term B |-Lj>-+ | | 327 +-----------+ +-----+ 329 Figure 4: Network architecture for a reliable multicast with NC 331 4.3. Hybrid access 333 This use-case considers the use of multiple path management with 334 network coding at the transport level to increase the reliability 335 and/or the total bandwidth (using multiple path does not guarantee an 336 improvement of both the reliability and the total bandwidth). We 337 propose an illustration for this scenario in Figure 5. This use-case 338 is inspired from the Broadband Access via Integrated Terrestrial 339 Satellite Systems (BATS) project and has been published as an ETSI 340 Technical Report [ETSITR2017]. It is worth nothing that this kind of 341 architecture is also discussed in the MPTCP working group 342 [I-D.boucadair-mptcp-dhc]. 344 To cope from packet loss (due to either end-user movements or 345 physical layer impairments), network coding could be introduced in 346 both the CPE and at the concentrator. 348 ->- : bidirectional link 350 +-----+ +----------------+ 351 +->| SAT |->-| BACKBONE | 352 +------+ +------+ | +-----+ | +------------+ | 353 | End |->-| CPE |->-| | |CONCENTRATOR| | 354 | User | | | | +-----+ | +------------+ | +------+ 355 +------+ +------+ |->| DSL |->-| |->-|Data | 356 | +-----+ | | |Server| 357 | | | +------+ 358 | +-----+ | | 359 +->| LTE |->-| | 360 +-----+ +----------------+ 362 Figure 5: Network architecture for an hybrid access using NC 364 4.4. Dealing with varying capacity 366 This use-case considers the usage of network coding to overcome cases 367 where the wireless link characteristics quickly change overtime and 368 where the physical layer codes could not be made robust in time. 369 This is particularly relevant when end users are moving and the 370 channel shows important variations [IEEEVT2001]. 372 The architecture is recalled in Figure 6. The network coding schemes 373 could be applied at the access gateway or the network function block 374 levels to increase the reliability of the transmission. This use- 375 case is mostly relevant for when mobile users are considered or when 376 the chosen band induce a required physical layer coding that may 377 change over time (Q/V bands, Ka band, etc.). Depending on the use- 378 case (e.g. very high frequency bands, mobile users) or depending on 379 the deployment use-cases (e.g. performance of the network between 380 each individual block), the relevance of adding network coding is 381 different. Then, depending on the OSI level at which network coding 382 is applied, the impact on the satellite terminal is different: 383 network coding may be applied on IP packets or on layer-2 proprietary 384 format packets. 386 ->- : bidirectional link 388 +------------+ +-----+ +---------+ +--------+ +---------+ 389 | Satellite | | SAT | | Physical| | Access | | Network | 390 | Terminal |->-| |->-| gateway |->-| gateway|->-| function| 391 +------------+ +-----+ +---------+ +--------+ +---------+ 392 NC NC NC NC 394 Figure 6: Network architecture for dealing with varying link 395 characteristics with NC 397 4.5. Improving the gateway handovers 399 This use-case considers the recovery of packets that may be lost 400 during gateway handovers. Whether this is for off-loading one given 401 equipment or because the transmission quality is not the same on each 402 gateway, changing the transmission gateway may be relevant. However, 403 if gateways are not properly synchronized, this may result in packet 404 loss. During these critical phases, network coding can be added to 405 improve the reliability of the transmission and propose a seamless 406 gateway handover. In this case, the network coding could be applied 407 at either the access gateway or the network function block. The 408 entity responsible for taking the decision to change the 409 communication gateway and changing the routes is the control plane 410 manager; this entity exploits a management interface. 412 An example architecture for this use-case is showed in Figure 7. It 413 is worth noting that depending on the ground architecture 414 [I-D.chin-nfvrg-cloud-5g-core-structure-yang] [SAT2017], some 415 equipment might be communalised. 417 ->- : bidirectional link 418 ! : management interface 419 NC NC 420 +---------+ +--------+ +---------+ 421 | Physical| | Access | | Network | 422 +->-| gateway |->-| gateway|->-| function| 423 | +---------+ +--------+ +---------+ 424 | ! ! 425 +------------+ +-----+ +---------------+ 426 | Satellite | | SAT | | Control plane | 427 | Terminal |->-| | | manager | 428 +------------+ +-----+ +---------------+ 429 | ! ! 430 | +---------+ +--------+ +---------+ 431 +->-| Physical|->-| Access |->-| Network | 432 | gateway | | gateway| | function| 433 +---------+ +--------+ +---------+ 434 NC NC 436 Figure 7: Network architecture for dealing with gateway handover 437 schemes with NC 439 4.6. Delay/Disruption Tolerant Networks 441 Establishing communications from terrestrial gateways to aerospace 442 components is a challenge due to the distances involved. As a matter 443 of fact, reliable end-to-end (E2E) communications over such links 444 must cope with long delay and frequent link disruptions. Delay/ 445 Disruption Tolerant Networking [RFC4838] is a solution to enable 446 reliable internetworking space communications where both standard ad- 447 hoc routing and E2E Internet protocols cannot be used. DTN can also 448 be seen as an alternative solution to cope with satellite 449 communications usually managed by PEP. Therefore, the transport of 450 data over such networks requires the use of replication, erasure 451 codes and multipath protocol schemes [WANG05] [ZHANG06] to improve 452 the bundle delivery ratio and/or delivery delay. For instance, 453 transport protocols such as LTP [RFC5326] for long delay links with 454 connectivity disruptions, use Automatic Repeat-reQuest (ARQ) and 455 unequal error protection to reduce the amount of non-mandatory re- 456 transmissions. The work in [TOURNOUX10] proposed upon LTP a robust 457 streaming method based on an on-the-fly coding scheme, where encoding 458 and decoding procedures are done at the source and destination nodes, 459 respectively. However, each link path loss rate may have various 460 order of magnitude and re-encoding at an intermediate node to adapt 461 the redundancy can be mandatory to prevent transmission wasting. 462 This idea has been put forward in 463 [I-D.zinky-dtnrg-random-binary-fec-scheme] and 464 [I-D.zinky-dtnrg-erasure-coding-extension], where the authors 465 proposed an encoding process at intermediate DTN nodes to explore the 466 possibilities of Forward Error Correction (FEC) schemes inside the 467 bundle protocol [RFC5050]. Another proposal is the use of erasure 468 coding inside the CCSDS (Consultative Committee for Space Data 469 Systems) architecture [COLA11]. The objective is to extend the CCSDS 470 File Delivery Protocol (CFDP) [CCSDS-FDP] with erasure coding 471 capabilities where a Low Density Parity Check (LDPC) [RFC6816] code 472 with a large block size is chosen. Recently, on-the-fly erasure 473 coding schemes [LACAN08] [SUNDARARAJAN08] [TOURNOUX11] have shown 474 their benefits in terms of recovery capability and configuration 475 complexity compared to traditional FEC schemes. Using a feedback 476 path when available, on-the-fly schemes can be used to enable E2E 477 reliable communication over DTN with adaptive re-encoding as proposed 478 in [THAI15]. 480 5. Discussion on the deployability 482 This section discusses the deployability of the use-cases detailed in 483 Section 4. 485 SATCOM systems typically feature Performance Enhancement Proxy 486 RFC 3135 [RFC3135] which could be relevant to host network coding 487 mechanisms and thus support the use-cases that have been discussed in 488 Section 4. In particular the discussion on how network coding can be 489 integrated inside a PEP with QoS scheduler has been proposed in 490 RFC 5865 [RFC5865]. 492 Related to the foreseen virtualized network infrastructure, the 493 network coding schemes could be proposed as VNF and their 494 deployability enhanced. The architecture for the next generation of 495 SATCOM ground segments would rely on a virtualized environment. This 496 trend can also be seen, making the discussions on the deployability 497 of network coding in SATCOM extendable to other deployment scenarios 498 [I-D.chin-nfvrg-cloud-5g-core-structure-yang]. As one example, the 499 network coding VNF functions deployment in a virtualized environment 500 is presented in [I-D.vazquez-nfvrg-netcod-function-virtualization]. 502 6. Conclusion 504 This document presents presents the current deployment of network 505 coding in some satellite telecommunications systems along with a 506 discussion on the multiple opportunities to introduce these 507 techniques at a wider scale. 509 Even if this document focuses on satellite systems, it is worth 510 pointing out that the some scenarios proposed may be relevant to 511 other wireless telecommunication systems. As one example, the 512 generic architecture proposed in Figure 1 may be mapped to cellular 513 networks as follows: the 'network function' block gather some of the 514 functions of the Evolved Packet Core subsystem, while the 'access 515 gateway' and 'physical gateway' blocks gather the same type of 516 functions as the Universal Mobile Terrestrial Radio Access Network. 517 This mapping extends the opportunities identified in this draft since 518 they may be also relevant for cellular networks. 520 7. Acknowledgements 522 Many thanks to Tomaso de Cola, Vincent Roca and Marie-Jose Montpetit. 524 8. Contributors 526 Tomaso de Cola, Marie-Jose Montpetit. 528 9. IANA Considerations 530 This memo includes no request to IANA. 532 10. Security Considerations 534 This document, by itself, presents no new privacy nor security 535 issues. 537 11. References 539 11.1. Normative References 541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", BCP 14, RFC 2119, 543 DOI 10.17487/RFC2119, March 1997, 544 . 546 11.2. Informative References 548 [ASMS2010] 549 De Cola, T. and et. al., "Demonstration at opening session 550 of ASMS 2010", ASMS , 2010. 552 [CCSDS-FDP] 553 "CCSDS File Delivery Protocol, Recommendation for Space 554 Data System Standards", CCSDS 727.0-B-4, Blue Book num. 3, 555 2007. 557 [COLA11] De Cola, T., Paolini, E., Liva, G., and G. Calzolari, 558 "Reliability options for data communications in the future 559 deep-space missions", Proceedings of the IEEE vol. 99 560 issue 11, 2011. 562 [ETSITR2017] 563 "Satellite Earth Stations and Systems (SES); Multi-link 564 routing scheme in hybrid access network with heterogeneous 565 links", ETSI TR 103 351, 2017. 567 [I-D.boucadair-mptcp-dhc] 568 Boucadair, M., Jacquenet, C., and T. Reddy, "DHCP Options 569 for Network-Assisted Multipath TCP (MPTCP)", draft- 570 boucadair-mptcp-dhc-08 (work in progress), October 2017. 572 [I-D.chin-nfvrg-cloud-5g-core-structure-yang] 573 Chen, C. and Z. Pan, "Yang Data Model for Cloud Native 5G 574 Core structure", draft-chin-nfvrg-cloud-5g-core-structure- 575 yang-00 (work in progress), December 2017. 577 [I-D.irtf-nwcrg-network-coding-taxonomy] 578 Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 579 F., samah.ghanem@gmail.com, s., Lochin, E., Masucci, A., 580 Montpetit, M., Pedersen, M., Peralta, G., Roca, V., 581 Saxena, P., and S. Sivakumar, "Taxonomy of Coding 582 Techniques for Efficient Network Communications", draft- 583 irtf-nwcrg-network-coding-taxonomy-08 (work in progress), 584 March 2018. 586 [I-D.vazquez-nfvrg-netcod-function-virtualization] 587 Vazquez-Castro, M., Do-Duy, T., Romano, S., and A. Tulino, 588 "Network Coding Function Virtualization", draft-vazquez- 589 nfvrg-netcod-function-virtualization-02 (work in 590 progress), November 2017. 592 [I-D.zinky-dtnrg-erasure-coding-extension] 593 Zinky, J., Caro, A., and G. Stein, "Bundle Protocol 594 Erasure Coding Extension", draft-zinky-dtnrg-erasure- 595 coding-extension-00 (work in progress), August 2012. 597 [I-D.zinky-dtnrg-random-binary-fec-scheme] 598 Zinky, J., Caro, A., and G. Stein, "Random Binary FEC 599 Scheme for Bundle Protocol", draft-zinky-dtnrg-random- 600 binary-fec-scheme-00 (work in progress), August 2012. 602 [IEEEVT2001] 603 Fontan, F., Vazquez-Castro, M., Cabado, C., Garcia, J., 604 and E. Kubista, "Statistical modeling of the LMS channel", 605 BEER Transactions on Vehicular Technology vol. 50 issue 6, 606 2001. 608 [LACAN08] Lacan, J. and E. Lochin, "Rethinking reliability for long- 609 delay networks", International Workshop on Satellite and 610 Space Communications , October 2008. 612 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 613 Shelby, "Performance Enhancing Proxies Intended to 614 Mitigate Link-Related Degradations", RFC 3135, 615 DOI 10.17487/RFC3135, June 2001, 616 . 618 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 619 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 620 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 621 April 2007, . 623 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 624 Specification", RFC 5050, DOI 10.17487/RFC5050, November 625 2007, . 627 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 628 Transmission Protocol - Specification", RFC 5326, 629 DOI 10.17487/RFC5326, September 2008, 630 . 632 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 633 "NACK-Oriented Reliable Multicast (NORM) Transport 634 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 635 . 637 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 638 Services Code Point (DSCP) for Capacity-Admitted Traffic", 639 RFC 5865, DOI 10.17487/RFC5865, May 2010, 640 . 642 [RFC6816] Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density 643 Parity Check (LDPC) Staircase Forward Error Correction 644 (FEC) Scheme for FECFRAME", RFC 6816, 645 DOI 10.17487/RFC6816, December 2012, 646 . 648 [SAT2017] Ahmed, T., Dubois, E., Dupe, JB., Ferrus, R., Gelard, P., 649 and N. Kuhn, "Software-defined satellite cloud RAN", Int. 650 J. Satell. Commun. Network. vol. 36, 2017. 652 [SUNDARARAJAN08] 653 Sundararajan, J., Shah, D., and M. Medard, "ARQ for 654 network coding", IEEE Int. Symp. on Information Theory , 655 July 2008. 657 [THAI15] Thai, T., Chaganti, V., Lochin, E., Lacan, J., Dubois, E., 658 and P. Gelard, "Enabling E2E reliable communications with 659 adaptive re-encoding over delay tolerant networks", 660 Proceedings of the IEEE International Conference on 661 Communications , June 2015. 663 [TOURNOUX10] 664 Tournoux, P., Lochin, E., Leguay, J., and J. Lacan, "On 665 the benefits of random linear coding for unicast 666 applications in disruption tolerant networks", Proceedings 667 of the IEEE International Conference on Communications , 668 2010. 670 [TOURNOUX11] 671 Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and 672 V. Roca, "On-the-fly erasure coding for real-time video 673 applications", IEEE Trans. on Multimedia vol. 13 issue 4, 674 August 2011. 676 [WANG05] Wang, Y. and et. al., "Erasure-coding based routing for 677 opportunistic networks", Proceedings of the ACM SIGCOMM 678 workshop on Delay-tolerant networking , 2005. 680 [ZHANG06] Zhang, X. and et. al., "On the benefits of random linear 681 coding for unicast applications in disruption tolerant 682 networks", Proceedings of the 4th International Symposium 683 on Modeling and Optimization in Mobile, Ad Hoc and 684 Wireless Networks , 2006. 686 Authors' Addresses 688 Nicolas Kuhn (editor) 689 CNES 690 18 Avenue Edouard Belin 691 Toulouse 31400 692 France 694 Email: nicolas.kuhn@cnes.fr 696 Emmanuel Lochin (editor) 697 ISAE-SUPAERO 698 10 Avenue Edouard Belin 699 Toulouse 31400 700 France 702 Email: emmanuel.lochin@isae-supaero.fr