idnits 2.17.1 draft-irtf-nwcrg-network-coding-satellites-01.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 (Nov 10, 2018) is 1991 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: May 14, 2019 ISAE-SUPAERO 6 Nov 10, 2018 8 Network coding and satellites 9 draft-irtf-nwcrg-network-coding-satellites-01 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 May 14, 2019. 34 Copyright Notice 36 Copyright (c) 2018 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 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. A note on satellite topology . . . . . . . . . . . . . . . . 4 55 3. Status of reliability schemes in actually deployed satellite 56 systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Details on the use cases . . . . . . . . . . . . . . . . . . 6 58 4.1. Two way relay channel mode . . . . . . . . . . . . . . . 7 59 4.2. Reliable multicast . . . . . . . . . . . . . . . . . . . 7 60 4.3. Hybrid access . . . . . . . . . . . . . . . . . . . . . . 8 61 4.4. Dealing with varying capacity . . . . . . . . . . . . . . 9 62 4.5. Improving the gateway handovers . . . . . . . . . . . . . 10 63 4.6. Delay/Disruption Tolerant Networks . . . . . . . . . . . 11 64 5. Research challenges . . . . . . . . . . . . . . . . . . . . . 12 65 5.1. Deployability in current SATCOM systems . . . . . . . . . 12 66 5.2. Interaction with virtualization . . . . . . . . . . . . . 12 67 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 73 10.2. Informative References . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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 adds to cope from link impairments, without 82 reducing the good-put when the channel quality is high. There is 83 usually enough redundancy to guarantee a Quasi-Error Free 84 transmission. However, physical layer reliability mechanisms may not 85 recover transmission losses (e.g. with a mobile user) and layer 2 (or 86 above) re-transmissions induce 500 ms one-way delay with a 87 geostationary satellite. Further exploiting coding schemes at higher 88 OSI-layers is an opportunity for releasing constraints on the 89 physical layer in such cases and improving the performance of SATCOM 90 systems. 92 We have noticed an active research activity on coding and SATCOM in 93 the past. That being said, not much has actually made it to 94 industrial developments. In this context, this document aims at 95 identifying opportunities for further usage of coding in these 96 systems. 98 This document follows the taxonomy of coding techniques for efficient 99 network communications [RFC8406]. 101 1.1. Glossary 103 The glossary of this memo extends the glossary of the taxonomy 104 document [RFC8406] as follows: 106 o ACM : Adaptative Coding and Modulation; 108 o BBFRAME: Base-Band FRAME - satellite communication layer 2 109 encapsulation work as follows: (1) each layer 3 packet is 110 encapsulated with a Generic Stream Encapsulation (GSE) mechanism, 111 (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs 112 contain information related to how they have to be modulated (4) 113 BBFRAMEs are forwarded to the physical layer; 115 o CPE: Customer Premise Equipment; 117 o DTN: Delay/Disruption Tolerant Network; 119 o EPC: Evolved Packet Core; 121 o ETSI: European Telecommunications Standards Institute; 123 o PEP: Performance Enhanced Proxy - a typical PEP for satellite 124 communications include compression, caching and TCP acceleration; 126 o PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME 127 with additional information (e.g. related to synchronization); 129 o SATCOM: generic term related to all kind of SATellite 130 COMmunications systems; 132 o QoS: Quality-of-Service; 134 o QoE: Quality-of-Experience; 136 o VNF: Virtualized Network Function. 138 1.2. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 2. A note on satellite topology 146 This section focuses on a generic description of the components 147 composing a generic satellite system and their interaction. A high 148 level description of a multi-gateway satellites network is provided. 149 There exist multiple SATCOM systems, such as those dedicated to 150 broadcasting TV or to IoT applications: depending on the purpose of 151 the SATCOM system, ground segments are specific. This memo lays on 152 SATCOM systems dedicated to Internet access that follows the DVB-S2/ 153 RCS2 standards. In this context, the increase of the available 154 capacity that is carried out to end users and the need for 155 reliability results in the need for multiple gateways for one unique 156 satellite platform. 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 coding schemes could be applied 170 to any individual traffic, it could also work on an 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 reliability schemes in actually deployed satellite systems 219 Figure 2 presents the status of the reliability schemes deployment in 220 satellite systems. The information is based on the taxonomy document 221 [RFC8406] and the notations are the following: End-to-End Coding 222 (E2E), Network Coding (NC), Intra-Flow Coding (IntraF), Inter-Flow 223 Coding (InterF), Single-Path Coding (SP) and Multi-Path Coding (MP). 225 X1 embodies the source coding that could be used at application level 226 for instance within QUIC or other video streaming applications: this 227 is not specific to SATCOM systems, but is relevant for broadband 228 Internet access discussions. 230 X2 embodies the physical layer, applied to the PLFRAME, to optimize 231 the satellite capacity usage: at the physical layer, FEC mechanisms 232 can be exploited. This aspect is not in the scope of the WG 233 according to the taxonomoy document [RFC8406]. 235 +------+-------+---------+---------------+-------+ 236 | | Upper | Middle | Communication layers | 237 | | Appl. | ware | | 238 + +-------+---------+---------------+-------+ 239 | |Source | Network | Packetization | PHY | 240 | |coding | AL-FEC | UDP/IP | layer | 241 +------+-------+---------+---------------+-------+ 242 |E2E | X1 | | | | 243 |NC | | | | | 244 |IntraF| X1 | | | | 245 |InterF| | | | X2 | 246 |SP | X1 | | | X2 | 247 |MP | | | | | 248 +------+-------+---------+---------------+-------+ 250 Figure 2: Reliability schemes in current satellite systems 252 Reliability is an inherent part of the physical layer and usually 253 achieved by using coding techniques. Based on public information, 254 coding does not seem to be widely used at higher OSI layers, other 255 than at the application layer. 257 4. Details on the use cases 259 This section details use-cases where coding schemes could improve the 260 overall performance of a SATCOM system (e.g. considering a more 261 efficient usage of the satellite resource, delivery delay, delivery 262 ratio). 264 It is worth noting that these use-cases focus more on the middleware 265 (e.g. aggregation nodes) and packetization UDP/IP of Figure 2. 266 Indeed, there are already lots of recovery mechanisms at the physical 267 layer in currently deployed systems while E2E source coding are done 268 at the application level. In a multi-gateway SATCOM Internet access, 269 the specific opportunities are more relevant in specific SATCOM 270 components such as the "network function" block or the "access 271 gateway" of Figure 1. 273 4.1. Two way relay channel mode 275 This use-case considers a two-way communication between end users, 276 through a satellite link. We propose an illustration of this 277 scenario in Figure 3. 279 Satellite terminal A (resp. B) transmits a flow A (resp. B) to a 280 server hosting NC capabilities, which forward a combination of the 281 two flows to both terminals. This results in non-negligible 282 bandwidth saving and has been demonstrated at ASMS 2010 in Cagliari 283 [ASMS2010]. Moreover, with On-Board Processing satellite payloads, 284 the coding operations could be done at the satellite level, thus 285 reducing the end-to-end delay of the communication. 287 -X}- : traffic from satellite terminal X to the server 288 ={X+Y= : traffic from X and Y combined transmitted from 289 the server to terminals X and Y 291 +-----------+ +-----+ 292 |Sat term A |--A}-+ | | 293 +-----------+ | | | +---------+ +------+ 294 ^^ +--| |--A}--| |--A}--| | 295 || | SAT |--B}--| Gateway |--B}--|Server| 296 ===={A+B=========| |={A+B=| |={A+B=| | 297 || | | +---------+ +------+ 298 vv +--| | 299 +-----------+ | | | 300 |Sat term B |--B}-+ | | 301 +-----------+ +-----+ 303 Figure 3: Network architecture for two way relay channel with NC 305 4.2. Reliable multicast 307 This use-case considers adding redundancy to a multicast flow 308 depending on what has been received by different end-users, resulting 309 in non-negligible scarce resource saving. We propose an illustration 310 for this scenario in Figure 4. 312 A multicast flow (M) is forwarded to both satellite terminals A and 313 B. However packet Ni (resp. Nj) get lost at terminal A (resp. B), 314 and terminal A (resp. B) returns a negative acknowledgement Li 315 (resp. Lj), indicating that the packet is missing. Then either the 316 access gateway or the multicast server includes a repair packet 317 (rather than the individual Ni and Nj packets) in the multicast flow 318 to let both terminals recover from losses. This could be achieved by 319 using NACK-Oriented Reliable Multicast (NORM) [RFC5740] in situations 320 where a feedback is possible and desirable, or FLUTE/ALC [RFC6726] 321 when it is not the case. Note that currently both NORM nor FLUTE/ALC 322 are limited to block coding, none of them supporting sliding window 323 encoding schemes [RFC8406]. 325 -Li}- : packet indicated the loss of packet i of a multicast flow 326 ={M== : multicast flow including the missing packets 328 +-----------+ +-----+ 329 |Sat term A |-Li}-+ | | 330 +-----------+ | | | +---------+ +------+ 331 ^^ +-| |-Li}--| | |Multi | 332 || | SAT |-Lj}--| Gateway |--|Cast | 333 ===={M==========| |={M===| | |Server| 334 || | | +---------+ +------+ 335 vv +-| | 336 +-----------+ | | | 337 |Sat term B |-Lj}-+ | | 338 +-----------+ +-----+ 340 Figure 4: Network architecture for a reliable multicast with NC 342 4.3. Hybrid access 344 This use-case considers the use of multiple path management with 345 coding at the transport level to increase the reliability and/or the 346 total capacity (using multiple path does not guarantee an improvement 347 of both the reliability and the total bandwidth). We propose an 348 illustration for this scenario in Figure 5. This use-case is 349 inspired from the Broadband Access via Integrated Terrestrial 350 Satellite Systems (BATS) project and has been published as an ETSI 351 Technical Report [ETSITR2017]. It is worth nothing that this kind of 352 architecture is also discussed in the MPTCP working group 353 [I-D.boucadair-mptcp-dhc]. 355 To cope with packet loss (due to either end-user mobility or physical 356 layer impairments), coding could be introduced in both the CPE and at 357 the concentrator. 359 -{}- : bidirectional link 361 +-----+ +----------------+ 362 +-{}-| SAT |-{}-| BACKBONE | 363 +------+ +------+ | +-----+ | +------------+ | 364 | End |-{}-| CPE |-{}-| | |CONCENTRATOR| | 365 | User | | | | +-----+ | +------------+ | +------+ 366 +------+ +------+ |-{}-| DSL |-{}-| |-{}-|Data | 367 | +-----+ | | |Server| 368 | | | +------+ 369 | +-----+ | | 370 +-{}-| LTE |-{}-| | 371 +-----+ +----------------+ 373 Figure 5: Network architecture for an hybrid access using NC 375 4.4. Dealing with varying capacity 377 This use-case considers the usage of coding to overcome cases where 378 the wireless link characteristics quickly change overtime and where 379 the physical layer codes could not be made robust in time. This is 380 particularly relevant when end users are moving and the channel shows 381 important variations [IEEEVT2001]. 383 The architecture is recalled in Figure 6. In these cases, Adaptative 384 Coding and Modulation (ACM) may not adapt the modulation and coding 385 accordingly and remaining errors could be recovered with higher 386 layers redundancy packets. The coding schemes could be applied at 387 the access gateway or the network function block levels to increase 388 the reliability of the transmission. This use-case is mostly 389 relevant for when mobile users are considered or when the chosen band 390 induce a required physical layer coding that may change over time (Q/ 391 V bands, Ka band, etc.). Depending on the use-case (e.g. very high 392 frequency bands, mobile users) or depending on the deployment use- 393 cases (e.g. performance of the network between each individual 394 block), the relevance of adding coding is different. Then, depending 395 on the OSI level at which coding is applied, the impact on the 396 satellite terminal is different: coding may be applied on IP packets 397 or on layer-2 proprietary format packets. 399 -{}- : bidirectional link 401 +---------+ +---+ +--------+ +-------+ +--------+ 402 |Satellite| |SAT| |Physical| |Access | |Network | 403 |Terminal |-{}-| |-{}-|gateway |-{}-|gateway|-{}-|function| 404 +---------+ +---+ +--------+ +-------+ +--------+ 405 NC NC NC NC 407 Figure 6: Network architecture for dealing with varying link 408 characteristics with NC 410 4.5. Improving the gateway handovers 412 This use-case considers the recovery of packets that may be lost 413 during gateway handovers. Whether this is for off-loading one given 414 equipment or because the transmission quality is not the same on each 415 gateway, changing the transmission gateway may be relevant. However, 416 if gateways are not properly synchronized, this may result in packet 417 loss. During these critical phases, coding can be added to improve 418 the reliability of the transmission and propose a seamless gateway 419 handover. In this case, the coding could be applied at either the 420 access gateway or the network function block. The entity responsible 421 for taking the decision to change the communication gateway and 422 changing the routes is the control plane manager; this entity 423 exploits a management interface. 425 An example architecture for this use-case is showed in Figure 7. It 426 is worth noting that depending on the ground architecture 427 [I-D.chin-nfvrg-cloud-5g-core-structure-yang] [SAT2017], some 428 equipment might be communalised. 430 -{}- : bidirectional link 431 ! : management interface 432 NC NC 433 +--------+ +-------+ +--------+ 434 |Physical| |Access | |Network | 435 +-{}-|gateway |-{}-|gateway|-{}-|function| 436 | +--------+ +-------+ +--------+ 437 | ! ! 438 +---------+ +---+ +---------------+ 439 |Satellite| |SAT| | Control plane | 440 |Terminal |-{}-| | | manager | 441 +---------+ +---+ +---------------+ 442 | ! ! 443 | +--------+ +-------+ +--------+ 444 +-{}-|Physical|-{}-|Access |-{}-|Network | 445 |gateway | |gateway| |function| 446 +--------+ +-------+ +--------+ 447 NC NC 449 Figure 7: Network architecture for dealing with gateway handover 450 schemes with NC 452 4.6. Delay/Disruption Tolerant Networks 454 Establishing communications from terrestrial gateways to aerospace 455 components is a challenge due to the distances involved. As a matter 456 of fact, reliable end-to-end (E2E) communications over such links 457 must cope with long delay and frequent link disruptions. Delay/ 458 Disruption Tolerant Networking [RFC4838] is a solution to enable 459 reliable internetworking space communications where both standard ad- 460 hoc routing and E2E Internet protocols cannot be used. DTN can also 461 be seen as an alternative solution to cope with satellite 462 communications usually managed by PEP. Therefore, the transport of 463 data over such networks requires the use of replication, erasure 464 codes and multipath protocol schemes [WANG05] [ZHANG06] to improve 465 the bundle delivery ratio and/or delivery delay. For instance, 466 transport protocols such as LTP [RFC5326] for long delay links with 467 connectivity disruptions, use Automatic Repeat-reQuest (ARQ) and 468 unequal error protection to reduce the amount of non-mandatory re- 469 transmissions. The work in [TOURNOUX10] proposed upon LTP a robust 470 streaming method based on an on-the-fly coding scheme, where encoding 471 and decoding procedures are done at the source and destination nodes, 472 respectively. However, each link path loss rate may have various 473 order of magnitude and re-encoding at an intermediate node to adapt 474 the redundancy can be mandatory to prevent transmission wasting. 475 This idea has been put forward in 476 [I-D.zinky-dtnrg-random-binary-fec-scheme] and 477 [I-D.zinky-dtnrg-erasure-coding-extension], where the authors 478 proposed an encoding process at intermediate DTN nodes to explore the 479 possibilities of Forward Error Correction (FEC) schemes inside the 480 bundle protocol [RFC5050]. Another proposal is the use of erasure 481 coding inside the CCSDS (Consultative Committee for Space Data 482 Systems) architecture [COLA11]. The objective is to extend the CCSDS 483 File Delivery Protocol (CFDP) [CCSDS-FDP] with erasure coding 484 capabilities where a Low Density Parity Check (LDPC) [RFC6816] code 485 with a large block size is chosen. Recently, on-the-fly erasure 486 coding schemes [LACAN08] [SUNDARARAJAN08] [TOURNOUX11] have shown 487 their benefits in terms of recovery capability and configuration 488 complexity compared to traditional FEC schemes. Using a feedback 489 path when available, on-the-fly schemes can be used to enable E2E 490 reliable communication over DTN with adaptive re-encoding as proposed 491 in [THAI15]. 493 5. Research challenges 495 5.1. Deployability in current SATCOM systems 497 SATCOM systems typically feature Performance Enhancement Proxy 498 RFC 3135 [RFC3135] which could be relevant to host coding mechanisms 499 and thus support the use-cases that have been discussed in Section 4. 500 PEP usually split TCP end-to-end connections and forward TCP packets 501 to the satellite baseband gateway that deals with layer 2 and layer 1 502 encapsulations. Deploying coding schemes at the TCP level in these 503 equipments could be relevant and independent from the specificities 504 of a SATCOM link. That being said, we can notice a research issue in 505 the recurrent trade-off in SATCOM systems that is related to the 506 amount of reliability that you introduce in the first transmission to 507 guarantee a better end-user QoE and the usage of the scarce resource. 509 5.2. Interaction with virtualization 511 Related to the foreseen virtualized network infrastructure, the 512 coding schemes could be proposed as Virtual Network Function (VNF) 513 and their deployability enhanced. The architecture for the next 514 generation of SATCOM ground segments would rely on a virtualized 515 environment. This trend can also be seen, making the discussions on 516 the deployability of coding in SATCOM extendable to other deployment 517 scenarios [I-D.chin-nfvrg-cloud-5g-core-structure-yang]. As one 518 example, the coding VNF functions deployment in a virtualized 519 environment is presented in 520 [I-D.vazquez-nfvrg-netcod-function-virtualization]. A research 521 challenge would be the optimization of the NFV service function 522 chaining, considering a virtualized infrastructure and other SATCOM 523 specific functions, to guarantee an efficient radio resource 524 utilization and easy to deploy SATCOM services. 526 6. Conclusion 528 This document presents the current deployment of coding in some 529 satellite telecommunications systems along with a discussion on the 530 multiple opportunities to introduce these techniques at a wider 531 scale. 533 Even if this document focuses on satellite systems, it is worth 534 pointing out that the some scenarios proposed may be relevant to 535 other wireless telecommunication systems. As one example, the 536 generic architecture proposed in Figure 1 may be mapped to cellular 537 networks as follows: the 'network function' block gather some of the 538 functions of the Evolved Packet Core subsystem, while the 'access 539 gateway' and 'physical gateway' blocks gather the same type of 540 functions as the Universal Mobile Terrestrial Radio Access Network. 541 This mapping extends the opportunities identified in this draft since 542 they may be also relevant for cellular networks. 544 7. Acknowledgements 546 Many thanks to Tomaso de Cola, Vincent Roca, Lloyd Wood and Marie- 547 Jose Montpetit for their help in writting this document. 549 8. IANA Considerations 551 This memo includes no request to IANA. 553 9. Security Considerations 555 Security considerations are inherent to any access network. SATCOM 556 systems introduce standard security mechanisms. In particular, there 557 are some specificities related to the fact that all users under the 558 coverage can record all the packets that are being transmitted, such 559 as in LTE networks. On the specific scenario of NC in SATCOM 560 systems, there are no specific security considerations. 562 10. References 564 10.1. Normative References 566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 567 Requirement Levels", BCP 14, RFC 2119, 568 DOI 10.17487/RFC2119, March 1997, 569 . 571 10.2. Informative References 573 [ASMS2010] 574 De Cola, T. and et. al., "Demonstration at opening session 575 of ASMS 2010", ASMS , 2010. 577 [CCSDS-FDP] 578 "CCSDS File Delivery Protocol, Recommendation for Space 579 Data System Standards", CCSDS 727.0-B-4, Blue Book num. 3, 580 2007. 582 [COLA11] De Cola, T., Paolini, E., Liva, G., and G. Calzolari, 583 "Reliability options for data communications in the future 584 deep-space missions", Proceedings of the IEEE vol. 99 585 issue 11, 2011. 587 [ETSITR2017] 588 "Satellite Earth Stations and Systems (SES); Multi-link 589 routing scheme in hybrid access network with heterogeneous 590 links", ETSI TR 103 351, 2017. 592 [I-D.boucadair-mptcp-dhc] 593 Boucadair, M., Jacquenet, C., and T. Reddy, "DHCP Options 594 for Network-Assisted Multipath TCP (MPTCP)", draft- 595 boucadair-mptcp-dhc-08 (work in progress), October 2017. 597 [I-D.chin-nfvrg-cloud-5g-core-structure-yang] 598 Chen, C. and Z. Pan, "Yang Data Model for Cloud Native 5G 599 Core structure", draft-chin-nfvrg-cloud-5g-core-structure- 600 yang-00 (work in progress), December 2017. 602 [I-D.vazquez-nfvrg-netcod-function-virtualization] 603 Vazquez-Castro, M., Do-Duy, T., Romano, S., and A. Tulino, 604 "Network Coding Function Virtualization", draft-vazquez- 605 nfvrg-netcod-function-virtualization-02 (work in 606 progress), November 2017. 608 [I-D.zinky-dtnrg-erasure-coding-extension] 609 Zinky, J., Caro, A., and G. Stein, "Bundle Protocol 610 Erasure Coding Extension", draft-zinky-dtnrg-erasure- 611 coding-extension-00 (work in progress), August 2012. 613 [I-D.zinky-dtnrg-random-binary-fec-scheme] 614 Zinky, J., Caro, A., and G. Stein, "Random Binary FEC 615 Scheme for Bundle Protocol", draft-zinky-dtnrg-random- 616 binary-fec-scheme-00 (work in progress), August 2012. 618 [IEEEVT2001] 619 Fontan, F., Vazquez-Castro, M., Cabado, C., Garcia, J., 620 and E. Kubista, "Statistical modeling of the LMS channel", 621 BEER Transactions on Vehicular Technology vol. 50 issue 6, 622 2001. 624 [LACAN08] Lacan, J. and E. Lochin, "Rethinking reliability for long- 625 delay networks", International Workshop on Satellite and 626 Space Communications , October 2008. 628 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 629 Shelby, "Performance Enhancing Proxies Intended to 630 Mitigate Link-Related Degradations", RFC 3135, 631 DOI 10.17487/RFC3135, June 2001, 632 . 634 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 635 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 636 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 637 April 2007, . 639 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 640 Specification", RFC 5050, DOI 10.17487/RFC5050, November 641 2007, . 643 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 644 Transmission Protocol - Specification", RFC 5326, 645 DOI 10.17487/RFC5326, September 2008, 646 . 648 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 649 "NACK-Oriented Reliable Multicast (NORM) Transport 650 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 651 . 653 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 654 "FLUTE - File Delivery over Unidirectional Transport", 655 RFC 6726, DOI 10.17487/RFC6726, November 2012, 656 . 658 [RFC6816] Roca, V., Cunche, M., and J. Lacan, "Simple Low-Density 659 Parity Check (LDPC) Staircase Forward Error Correction 660 (FEC) Scheme for FECFRAME", RFC 6816, 661 DOI 10.17487/RFC6816, December 2012, 662 . 664 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 665 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 666 Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and 667 S. Sivakumar, "Taxonomy of Coding Techniques for Efficient 668 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 669 June 2018, . 671 [SAT2017] Ahmed, T., Dubois, E., Dupe, JB., Ferrus, R., Gelard, P., 672 and N. Kuhn, "Software-defined satellite cloud RAN", Int. 673 J. Satell. Commun. Network. vol. 36, 2017. 675 [SUNDARARAJAN08] 676 Sundararajan, J., Shah, D., and M. Medard, "ARQ for 677 network coding", IEEE Int. Symp. on Information Theory , 678 July 2008. 680 [THAI15] Thai, T., Chaganti, V., Lochin, E., Lacan, J., Dubois, E., 681 and P. Gelard, "Enabling E2E reliable communications with 682 adaptive re-encoding over delay tolerant networks", 683 Proceedings of the IEEE International Conference on 684 Communications , June 2015. 686 [TOURNOUX10] 687 Tournoux, P., Lochin, E., Leguay, J., and J. Lacan, "On 688 the benefits of random linear coding for unicast 689 applications in disruption tolerant networks", Proceedings 690 of the IEEE International Conference on Communications , 691 2010. 693 [TOURNOUX11] 694 Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and 695 V. Roca, "On-the-fly erasure coding for real-time video 696 applications", IEEE Trans. on Multimedia vol. 13 issue 4, 697 August 2011. 699 [WANG05] Wang, Y. and et. al., "Erasure-coding based routing for 700 opportunistic networks", Proceedings of the ACM SIGCOMM 701 workshop on Delay-tolerant networking , 2005. 703 [ZHANG06] Zhang, X. and et. al., "On the benefits of random linear 704 coding for unicast applications in disruption tolerant 705 networks", Proceedings of the 4th International Symposium 706 on Modeling and Optimization in Mobile, Ad Hoc and 707 Wireless Networks , 2006. 709 Authors' Addresses 711 Nicolas Kuhn (editor) 712 CNES 713 18 Avenue Edouard Belin 714 Toulouse 31400 715 France 717 Email: nicolas.kuhn@cnes.fr 719 Emmanuel Lochin (editor) 720 ISAE-SUPAERO 721 10 Avenue Edouard Belin 722 Toulouse 31400 723 France 725 Email: emmanuel.lochin@isae-supaero.fr