idnits 2.17.1 draft-irtf-nwcrg-network-coding-satellites-06.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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC8406]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 19, 2019) is 1709 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5326' is defined on line 673, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-tcpm-converters-10 Summary: 2 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: February 20, 2020 ISAE-SUPAERO 6 August 19, 2019 8 Coding techniques for satellite systems 9 draft-irtf-nwcrg-network-coding-satellites-06 11 Abstract 13 This document is the product of the Coding for Efficient Network 14 Communications Research Group (NWCRG). This document follows the 15 taxonomy document [RFC8406] and considers coding as a linear 16 combination of packets that operate in and above the network layer. 17 In this context, this memo details a multi-gateway satellite system 18 to identify use-cases where coding is relevant. As example, coding 19 operating in and above the network layer can be exploited to cope 20 with residual losses or provide reliable multicast services. The 21 objective is to contribute to a larger deployment of such techniques 22 in SATCOM systems. This memo also identifies open research issues 23 related to the deployment of coding in SATCOM systems, such as the 24 interaction between congestion controls and coding techniques. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 20, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. A note on satellite topology . . . . . . . . . . . . . . . . 5 62 3. Use-cases for improving the SATCOM system performance with 63 coding techniques . . . . . . . . . . . . . . . . . . . . . . 8 64 3.1. Two-way relay channel mode . . . . . . . . . . . . . . . 8 65 3.2. Reliable multicast . . . . . . . . . . . . . . . . . . . 9 66 3.3. Hybrid access . . . . . . . . . . . . . . . . . . . . . . 10 67 3.4. Dealing with LAN losses . . . . . . . . . . . . . . . . . 10 68 3.5. Dealing with varying channel conditions . . . . . . . . . 11 69 3.6. Improving the gateway handovers . . . . . . . . . . . . . 12 70 4. Research challenges . . . . . . . . . . . . . . . . . . . . . 12 71 4.1. On the joint-use of coding techniques and congestion 72 control in SATCOM systems . . . . . . . . . . . . . . . . 13 73 4.2. On the efficient usage of satellite resource . . . . . . 13 74 4.3. Interaction with virtualized satellite gateways and 75 terminals . . . . . . . . . . . . . . . . . . . . . . . . 13 76 4.4. Delay/Disruption Tolerant Networks . . . . . . . . . . . 14 77 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 9. Informative References . . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 Guaranteeing both physical-layer robustness and efficient usage of 87 the radio resource has been in the core design of SATellite 88 COMmunication (SATCOM) systems. The trade-off often resided in how 89 much redundancy a system adds to cope with link impairments, without 90 reducing the goodput when the channel quality is good. There is 91 usually enough redundancy to guarantee a Quasi-Error Free 92 transmission. The recovery time depends on the encoding block size. 93 Considering for instance geostationary satellite system (GEO), 94 physical or link layer erasure coding mechanisms recover transmission 95 losses within a negligible delay compared to link delay. However, 96 when retransmissions are triggered, this leads to a non-negligible 97 additional delay in particular over GEO link. Further exploiting 98 coding techniques at application or transport layers is an 99 opportunity for releasing constraints on the physical layer and 100 improving the performance of SATCOM systems. 102 The notations used in this document are based on the taxonomy 103 document [RFC8406]: 105 o Channel and link codings are gathered in the PHY layer coding and 106 are out of the scope of this document. 108 o FEC (also called Application-Level FEC) operates in and above the 109 network layer. 111 o This document considers coding (or coding techniques or coding 112 schemes) as a linear combination and not as a content coding 113 (e.g., to compress a video flow). 115 Figure 1 presents the status of the reliability schemes deployment in 116 satellite systems. 118 o X1 embodies the source coding techniques that could be used at 119 application level for instance within QUIC. This is not specific 120 to SATCOM systems since such deployment can be relevant for 121 broadband Internet access discussions. 123 o X2 embodies the physical-layer techniques exploited in SATCOM 124 systems (note that other coding techniques can be exploited). 125 This is out of the scope of the document. 127 +------+-------+---------+---------------+-------+ 128 | | Upper | Middle | Communication layers | 129 | | Appl. | ware | | 130 + +-------+---------+---------------+-------+ 131 | |Source | Network | Packetization | PHY | 132 | |coding | AL-FEC | UDP/IP | layer | 133 +------+-------+---------+---------------+-------+ 134 |E2E | X1 | | | | 135 |NC | | | | | 136 |IntraF| X1 | | | | 137 |InterF| | | | X2 | 138 |SPC | X1 | | | X2 | 139 |MPC | | | | | 140 +------+-------+---------+---------------+-------+ 142 Figure 1: Reliability schemes in current satellite systems 144 We notice an active research activity on coding techniques and 145 SATCOM. That being said, not much has actually made it to industrial 146 developments. In this context, this document aims at identifying 147 opportunities for further usage of coding in these systems. 149 The glossary of this memo extends the glossary of the taxonomy 150 document [RFC8406] as follows: 152 o ACM : Adaptive Coding and Modulation; 154 o BBFRAME: Base-Band FRAME - satellite communication layer 2 155 encapsulation work as follows: (1) each layer 3 packet is 156 encapsulated with a Generic Stream Encapsulation (GSE) mechanism, 157 (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs 158 contain information related to how they have to be modulated (4) 159 BBFRAMEs are forwarded to the physical-layer; 161 o CPE: Customer Premises Equipment; 163 o COM: COMmunication; 165 o DSL: Digital Subscriber Line; 167 o DTN: Delay/Disruption Tolerant Network; 169 o DVB: Digital Video Broadcasting; 171 o E2E: End-to-end; 173 o ETSI: European Telecommunications Standards Institute; 175 o FEC: Forward Error Correction; 177 o FLUTE: File Delivery over Unidirectional Transport; 179 o IntraF: Intra-Flow Coding; 181 o InterF: Inter-Flow Coding; 183 o IoT: Internet of Things; 185 o LTE: Long Term Evolution; 187 o MPC: Multi-Path Coding; 189 o NC: Network Coding; 191 o NFV: Network Function Virtualization; 192 o NORM: NACK-Oriented Reliable Multicast; 194 o PEP: Performance Enhancing Proxy [RFC3135] - a typical PEP for 195 satellite communications include compression, caching and TCP 196 acceleration; 198 o PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME 199 with additional information (e.g., related to synchronization); 201 o QEF: Quasi-Error-Free; 203 o QoE: Quality-of-Experience; 205 o QoS: Quality-of-Service; 207 o SAT: SATellite; 209 o SATCOM: generic term related to all kind of SATellite 210 COMmunication systems; 212 o SPC: Single-Path Coding; 214 o VNF: Virtual Network Function. 216 This document is the product of and represents the collaborative work 217 and consensus of the Coding for Efficient Network Communications 218 Research Group (NWCRG); it is not an IETF product and is not a 219 standard. 221 2. A note on satellite topology 223 This section describes a satellite system that follows the ETSI DVB 224 standards to provide broadband Internet access. A high-level 225 description of a multi-gateway satellite network is provided. There 226 are multiple SATCOM systems, such as those dedicated to broadcasting 227 TV or to IoT applications: depending on the purpose of the SATCOM 228 system, ground segments are specific. In this context, the increase 229 of the available capacity that is carried out to end users and 230 reliability requirements lead to multiple gateways for one unique 231 satellite platform. 233 In this context, Figure 2 shows an example of a multi-gateway 234 satellite system. In a multi-gateway system, some elements may be 235 centralized and/or gathered: the relevance of one approach compared 236 to another depends on the deployment scenario. More information on 237 these discussions and a generic SATCOM ground segment architecture 238 for bidirectional Internet access can be found in [SAT2017]. 240 Some functional blocks aggregate the traffic of multiple users. 242 +--------------------------+ 243 | application servers | 244 | (data, coding, multicast | 245 +--------------------------+ 246 ^ ^ 247 | ... | 248 ----------------------------------- 249 v v v v v v 250 +------------------+ +------------------+ 251 | network function | | network function | 252 | (firewall, PEP) | | (firewall, PEP) | 253 +------------------+ +------------------+ 254 ^ ^ ^ ^ 255 | ... | IP packets | ... | 256 v v v v --- 257 +------------------+ +------------------+ | 258 | access gateway | | access gateway | | 259 +------------------+ +------------------+ | 260 ^ ^ | 261 | BBFRAME | | gateway 262 v v | 263 +------------------+ +------------------+ | 264 | physical gateway | | physical gateway | | 265 +------------------+ +------------------+ | 266 ^ ^ --- 267 | PLFRAME | 268 v v 269 +------------------+ +------------------+ 270 | outdoor unit | | outdoor unit | 271 +------------------+ +------------------+ 272 ^ ^ 273 | satellite link | 274 v v 275 +------------------+ +------------------+ 276 | sat terminals | | sat terminals | 277 +------------------+ +------------------+ 278 ^ ^ ^ ^ 279 | | | | 280 v | v | 281 +----------+ | +----------+ | 282 | end user | | | end user | | 283 +----------+ v +----------+ v 284 +------------------+ +------------------+ 285 | end user | | end user | 286 +------------------+ +------------------+ 288 Figure 2: Data plane functions in a generic satellite multi-gateway 289 system 291 3. Use-cases for improving the SATCOM system performance with coding 292 techniques 294 This section details use-cases where coding techniques could provide 295 interesting features for SATCOM systems. Combination of the 296 presented use-cases could also be relevant. 298 It is worth noting that these use-cases mostly focus on the 299 middleware and packetization UDP/IP of Figure 1. There are already 300 lots of recovery mechanisms at the physical-layer in currently 301 deployed systems while E2E source coding is done at the application 302 level. In a multi-gateway SATCOM Internet access, the deployment 303 opportunities are more relevant in specific SATCOM components such as 304 the "network function" block or the "access gateway" of Figure 2. 306 3.1. Two-way relay channel mode 308 This use-case considers a two-way communication between end users, 309 through a satellite link. Figure 3 proposes an illustration of this 310 scenario. 312 Satellite terminal A sends a flow A and satellite terminal B sends a 313 flow B to a coding server. The coding server sends a combination of 314 both terminal flows. This results in non-negligible capacity savings 315 and has been demonstrated [ASMS2010]. In the proposed example, a 316 dedicated coding server is introduced. Its location could be changed 317 depending on the deployment use-case. With On-Board Processing 318 satellite payloads, the coding operations could be done at the 319 satellite level; although this would require lots of computational 320 ressource on-board and may not be relevant with today's payloads. 322 -X}- : traffic from satellite terminal X to the server 323 ={X+Y= : traffic from X and Y combined sent from 324 the server to terminals X and Y 326 +-----------+ +-----+ 327 |Sat term A |--A}-+ | | 328 +-----------+ | | | +---------+ +------+ 329 ^^ +--| |--A}--| |--A}--|Coding| 330 || | SAT |--B}--| Gateway |--B}--|Server| 331 ===={A+B=========| |={A+B=| |={A+B=| | 332 || | | +---------+ +------+ 333 vv +--| | 334 +-----------+ | | | 335 |Sat term B |--B}-+ | | 336 +-----------+ +-----+ 338 Figure 3: Network architecture for two way relay channel with NC 340 3.2. Reliable multicast 342 Using multicast servers is a way to better exploit the satellite 343 broadcast capabilities. This approach is proposed in the SHINE ESA 344 project [I-D.vazquez-nfvrg-netcod-function-virtualization] [SHINE]. 345 This use-case considers adding redundancy to a multicast flow 346 depending on what has been received by different end-users, resulting 347 in non-negligible scarce resource saving. We propose an illustration 348 for this scenario in Figure 4. 350 -Li}- : packet indicating the loss of packet i of a multicast flow M 351 ={M== : multicast flow including the missing packets 353 +-----------+ +-----+ 354 |Sat term A |-Li}-+ | | 355 +-----------+ | | | +---------+ +------+ 356 ^^ +-| |-Li}--| | |Multi | 357 || | SAT |-Lj}--| Gateway |--|Cast | 358 ===={M==========| |={M===| | |Server| 359 || | | +---------+ +------+ 360 vv +-| | 361 +-----------+ | | | 362 |Sat term B |-Lj}-+ | | 363 +-----------+ +-----+ 365 Figure 4: Network architecture for a reliable multicast with NC 367 A multicast flow (M) is forwarded to both satellite terminals A and 368 B. However packet Ni (resp. Nj) gets lost at terminal A (resp. B), 369 and terminal A (resp. B) returns a negative acknowledgment Li (resp. 370 Lj), indicating that the packet is missing. Then either the access 371 gateway or the multicast server includes a repair packet (rather than 372 the individual Ni and Nj packets) in the multicast flow to let both 373 terminals recover from losses. 375 This could be achieved by using other multicast or broadcast systems, 376 such as NACK-Oriented Reliable Multicast (NORM) [RFC5740] or File 377 Delivery over Unidirectional Transport (FLUTE) [RFC6726]. Note that 378 both NORM and FLUTE are limited to block coding, none of them 379 supporting sliding window encoding schemes [RFC8406]. Note that 380 although FLUTE is defined as an unidirectional protocol, the RFC 381 proposes a bidirectional communication method to enable full 382 reliability transfer and for security purposes. 384 3.3. Hybrid access 386 This use-case considers the use of multiple path management with 387 coding at the transport layer to increase the reliability and/or the 388 total capacity (using multiple paths does not guarantee an 389 improvement of both the reliability and the total capacity). We 390 propose an illustration for this scenario in Figure 5. This use-case 391 is inspired from the Broadband Access via Integrated Terrestrial 392 Satellite Systems (BATS) project and has been published as an ETSI 393 Technical Report [ETSITR2017]. This kind of architecture is also 394 discussed in the TCPM working group [I-D.ietf-tcpm-converters]. 396 To cope with packet loss (due to either end-user mobility or 397 physical-layer impairments), coding techniques could be introduced 398 both at the CPE and at the concentrator. Apart from packet losses, 399 other gains could be envisioned, such as a better tolerance to out- 400 of-order packets which occur when exploited links exhibit high 401 asymetry in terms of RTT. Depending on the ground architecture 402 [I-D.chin-nfvrg-cloud-5g-core-structure-yang] [SAT2017], some 403 equipments might be hosting both SATCOM and cellular functions. 405 -{}- : bidirectional link 407 +-----+ +----------------+ 408 +-{}-| SAT |-{}-| BACKBONE | 409 +------+ +------+ | +-----+ | +------------+ | 410 | End |-{}-| CPE |-{}-| | |CONCENTRATOR| | 411 | User | | | | +-----+ | +------------+ | +------------+ 412 +------+ +------+ |-{}-| DSL |-{}-| |-{}-|Application | 413 | +-----+ | | |Server | 414 | | | +------------+ 415 | +-----+ | | 416 +-{}-| LTE |-{}-| | 417 +-----+ +----------------+ 419 Figure 5: Network architecture for an hybrid access using coding 421 3.4. Dealing with LAN losses 423 This use-case considers the usage of coding techniques to cope with 424 cases where the end user connects to the satellite terminal with a 425 Wi-Fi link that exhibits losses. In the case of encrypted end-to-end 426 applications based on UDP, PEP cannot operate. The Wi-Fi losses 427 result in an end-to-end retransmission that would harm the quality of 428 experience of the end user. 430 The architecture is recalled in Figure 6. 432 In this use-case, adding coding techniques could prevent the end-to- 433 end retransmission from occuring. 435 -{}- : bidirectional link 436 -''- : Wi-Fi link 437 C : where coding techniques could be introduced 439 +---------+ +---------+ +---+ +--------+ +-------+ +--------+ 440 | | |Satellite| |SAT| |Physical| |Access | |Network | 441 |End user |-''-|Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function| 442 +---------+ +---------+ +---+ +--------+ +-------+ +--------+ 443 C C C C 445 Figure 6: Network architecture for dealing with LAN losses 447 3.5. Dealing with varying channel conditions 449 This use-case considers the usage of coding techniques to cope with 450 cases where channel condition can change in less than a second and 451 where the physical-layer codes could not efficiently guarantee a 452 Quasi-Error-Free (QEF) transmission. 454 The architecture is recalled in Figure 7. In these cases, the 455 mechanisms that are exploited to adapt the physical-layer codes 456 (Adaptative Coding and Modulation (ACM)) may adapt the modulation and 457 coding in time: remaining errors could be recovered with higher layer 458 redundancy packets. Coding may be applied on IP packets or on 459 layer-2 proprietary format packets. 461 This use-case is mostly relevant when mobile users are considered or 462 when the chosen band induces a required physical-layer coding that 463 may change over time (Q/V bands, Ka band, etc.). Depending on the 464 use-case (e.g., very high frequency bands, mobile users) or depending 465 on the deployment use-cases (e.g., performance of the network between 466 each individual block), the relevance of adding coding techniques is 467 different. 469 -{}- : bidirectional link 470 C : where coding techniques could be introduced 472 +---------+ +---+ +--------+ +-------+ +--------+ 473 |Satellite| |SAT| |Physical| |Access | |Network | 474 |Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function| 475 +---------+ +---+ +--------+ +-------+ +--------+ 476 C C C C 478 Figure 7: Network architecture for dealing with varying link 479 characteristics 481 3.6. Improving the gateway handovers 483 This use-case considers the recovery of packets that may be lost 484 during gateway handovers. Whether this is for off-loading one given 485 equipment or because the transmission quality is not the same on each 486 gateway, changing the transmission gateway may be relevant. However, 487 if gateways are not properly synchronized or if the algorithm that is 488 exploited to trigger gateway handovers shows a non negligible 489 probability of missed detection, this may result in packet losses. 490 During these critical phases, coding can be added to improve the 491 reliability of the transmission and allow a seamless gateway 492 handover. Coding could be applied at either the access gateway or 493 the network function block. A potential control plane is in charge 494 of taking the decision to change the communication gateway and the 495 consequent routes. 497 Figure 8 illustrates this use-case. 499 -{}- : bidirectional link 500 ! : management interface 501 C : where coding techniques could be introduced 502 C C 503 +--------+ +-------+ +--------+ 504 |Physical| |Access | |Network | 505 +-{}-|gateway |-{}-|gateway|-{}-|function| 506 | +--------+ +-------+ +--------+ 507 | ! ! 508 +---------+ +---+ +---------------+ 509 |Satellite| |SAT| | Control plane | 510 |Terminal |-{}-| | | manager | 511 +---------+ +---+ +---------------+ 512 | ! ! 513 | +--------+ +-------+ +--------+ 514 +-{}-|Physical|-{}-|Access |-{}-|Network | 515 |gateway | |gateway| |function| 516 +--------+ +-------+ +--------+ 517 C C 519 Figure 8: Network architecture for dealing with gateway handover 520 schemes 522 4. Research challenges 524 This section proposes a few potential approaches to introduce and use 525 coding techniques in SATCOM systems. 527 4.1. On the joint-use of coding techniques and congestion control in 528 SATCOM systems 530 SATCOM systems typically feature Performance Enhancement Proxy (PEP) 531 RFC 3135 [RFC3135]. PEP usually split TCP end-to-end connections and 532 forward TCP packets to the satellite baseband gateway that deals with 533 layer-2 and layer-1 encapsulations. PEP contributes to mitigate 534 congestion in a SATCOM systems. PEP could host coding mechanisms and 535 thus support use-cases that have been discussed in this document. 537 Deploying coding schemes at the TCP level in these equipment could be 538 relevant and independent from the specific characteristics of a 539 SATCOM link. This leads to research questions on the interaction 540 between coding schemes and TCP congestion controls. 542 4.2. On the efficient usage of satellite resource 544 The recurrent trade-off in SATCOM systems remains: how much overhead 545 from redundant reliability packets can be introduced to guarantee a 546 better end-user QoE while optimizing capacity usage ? At which layer 547 this supplementary coding could be added ? 549 This problem has been tackled in the past for physical-layer code, 550 but there remains questions on how to adapt the overhead for, e.g., 551 the quickly varying channel conditions use-case. 553 4.3. Interaction with virtualized satellite gateways and terminals 555 Related to the foreseen virtualized network infrastructure, coding 556 techniques could be easily deployed as VNF. Next generation of 557 SATCOM ground segments could rely on a virtualized environment. This 558 trend can also be seen in cellular networks, making these discussions 559 extendable to other deployment scenarios 560 [I-D.chin-nfvrg-cloud-5g-core-structure-yang]. As one example, the 561 coding VNF deployment in a virtualized environment is presented in 562 [I-D.vazquez-nfvrg-netcod-function-virtualization]. 564 A research challenge would be the optimization of the NFV service 565 function chaining, considering a virtualized infrastructure and other 566 SATCOM specific functions, to guarantee efficient radio usage and 567 easy-to-deploy SATCOM services. Moreover, another challenge related 568 to a virtualized SATCOM equipment is the management of limited 569 buffered capacities. 571 4.4. Delay/Disruption Tolerant Networks 573 Communications among deep-space platforms and terrestrial gateways 574 can be a challenge. Reliable end-to-end (E2E) communications over 575 such paths must cope with long delay and frequent link disruptions; 576 indeed, contemporaneous E2E connectivity may be available only 577 intermittently or never. Delay/Disruption Tolerant Networking 578 [RFC4838] is a solution to enable reliable internetworking space 579 communications where both standard ad-hoc routing and E2E Internet 580 protocols cannot be used. Moreover, DTN can also be seen as an 581 alternative solution to transfer the data between a central PEP and a 582 remote PEP. 584 Coding enables E2E reliable communication over DTN with adaptive re- 585 encoding, as proposed in [THAI15]. In this case, the use-cases 586 proposed in Section 3.5 would legitimize the usage of coding within 587 the DTN stack to improve the channel utilization and the E2E 588 transmission delay. In this context, the use of erasure coding 589 techniques inside a Consultative Committee for Space Data Systems 590 (CCSDS) architecture has been specified in [CCSDS-131.5-O-1]. A 591 research challenge would be on how such coding can be integrated in 592 the IETF DTN stack. 594 5. Conclusion 596 This document discuses some opportunities to introduce coding 597 techniques at a wider scale in satellite telecommunications systems. 599 Even though this document focuses on satellite systems, it is worth 600 pointing out that some scenarios proposed may be relevant to other 601 wireless telecommunication systems. As one example, the generic 602 architecture proposed in Figure 2 may be mapped to cellular networks 603 as follows: the 'network function' block gathers some of the 604 functions of the Evolved Packet Core subsystem, while the 'access 605 gateway' and 'physical gateway' blocks gather the same type of 606 functions as the Universal Mobile Terrestrial Radio Access Network. 607 This mapping extends the opportunities identified in this draft since 608 they may be also relevant for cellular networks. 610 6. Acknowledgements 612 Many thanks to John Border, Stuart Card, Tomaso de Cola, Vincent 613 Roca, Lloyd Wood and Marie-Jose Montpetit for their help in writing 614 this document. 616 7. IANA Considerations 618 This memo includes no request to IANA. 620 8. Security Considerations 622 Security considerations are inherent to any access network, and in 623 particular SATCOM systems. The use of FEC or Network Coding in 624 SATCOM also comes with risks (e.g., a single corrupted redundant 625 packet may propagate to several flows when they are protected 626 together in an Inter-Flow coding approach, see section Section 3). 627 However this is not specific to the SATCOM use-case and this document 628 does not further elaborate on it. 630 9. Informative References 632 [ASMS2010] 633 De Cola, T. and et. al., "Demonstration at opening session 634 of ASMS 2010", ASMS , 2010. 636 [CCSDS-131.5-O-1] 637 "Erasure correcting codes for use in near-earth and deep- 638 space communications", CCSDS Experimental 639 specification 131.5-0-1, 2014. 641 [ETSITR2017] 642 "Satellite Earth Stations and Systems (SES); Multi-link 643 routing scheme in hybrid access network with heterogeneous 644 links", ETSI TR 103 351, 2017. 646 [I-D.chin-nfvrg-cloud-5g-core-structure-yang] 647 Chen, C. and Z. Pan, "Yang Data Model for Cloud Native 5G 648 Core structure", draft-chin-nfvrg-cloud-5g-core-structure- 649 yang-00 (work in progress), December 2017. 651 [I-D.ietf-tcpm-converters] 652 Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., 653 and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- 654 tcpm-converters-10 (work in progress), August 2019. 656 [I-D.vazquez-nfvrg-netcod-function-virtualization] 657 Vazquez-Castro, M., Do-Duy, T., Romano, S., and A. Tulino, 658 "Network Coding Function Virtualization", draft-vazquez- 659 nfvrg-netcod-function-virtualization-02 (work in 660 progress), November 2017. 662 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 663 Shelby, "Performance Enhancing Proxies Intended to 664 Mitigate Link-Related Degradations", RFC 3135, 665 DOI 10.17487/RFC3135, June 2001, 666 . 668 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 669 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 670 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 671 April 2007, . 673 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 674 Transmission Protocol - Specification", RFC 5326, 675 DOI 10.17487/RFC5326, September 2008, 676 . 678 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 679 "NACK-Oriented Reliable Multicast (NORM) Transport 680 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 681 . 683 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 684 "FLUTE - File Delivery over Unidirectional Transport", 685 RFC 6726, DOI 10.17487/RFC6726, November 2012, 686 . 688 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 689 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 690 Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and 691 S. Sivakumar, "Taxonomy of Coding Techniques for Efficient 692 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 693 June 2018, . 695 [SAT2017] Ahmed, T., Dubois, E., Dupe, JB., Ferrus, R., Gelard, P., 696 and N. Kuhn, "Software-defined satellite cloud RAN", Int. 697 J. Satell. Commun. Network. vol. 36, 2017. 699 [SHINE] Pietro Romano, S. and et. al., "Secure Hybrid In Network 700 caching Environment (SHINE) ESA project", ESA project , 701 2017 on-going. 703 [THAI15] Thai, T., Chaganti, V., Lochin, E., Lacan, J., Dubois, E., 704 and P. Gelard, "Enabling E2E reliable communications with 705 adaptive re-encoding over delay tolerant networks", 706 Proceedings of the IEEE International Conference on 707 Communications , June 2015. 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