idnits 2.17.1 draft-irtf-nwcrg-network-coding-satellites-07.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 (October 29, 2019) is 1640 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5326' is defined on line 674, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-tcpm-converters-13 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: May 1, 2020 ISAE-SUPAERO 6 October 29, 2019 8 Coding techniques for satellite systems 9 draft-irtf-nwcrg-network-coding-satellites-07 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 May 1, 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 . . . . . . . . . . . . . . . . 4 62 3. Use-cases for improving the SATCOM system performance with 63 coding techniques . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Two-way relay channel mode . . . . . . . . . . . . . . . 6 65 3.2. Reliable multicast . . . . . . . . . . . . . . . . . . . 7 66 3.3. Hybrid access . . . . . . . . . . . . . . . . . . . . . . 8 67 3.4. Dealing with LAN losses . . . . . . . . . . . . . . . . . 8 68 3.5. Dealing with varying channel conditions . . . . . . . . . 9 69 3.6. Improving the gateway handovers . . . . . . . . . . . . . 10 70 4. Research challenges . . . . . . . . . . . . . . . . . . . . . 10 71 4.1. On the joint-use of coding techniques and congestion 72 control in SATCOM systems . . . . . . . . . . . . . . . . 11 73 4.2. On the efficient usage of satellite resource . . . . . . 11 74 4.3. Interaction with virtualized satellite gateways and 75 terminals . . . . . . . . . . . . . . . . . . . . . . . . 11 76 4.4. Delay/Disruption Tolerant Networks . . . . . . . . . . . 12 77 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 6. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 10. Informative References . . . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 This document is the product of and represents the collaborative work 88 and consensus of the Coding for Efficient Network Communications 89 Research Group (NWCRG); it is not an IETF product and is not a 90 standard. A glossary is proposed in Section 6. 92 Guaranteeing both physical-layer robustness and efficient usage of 93 the radio resource has been in the core design of SATellite 94 COMmunication (SATCOM) systems. The trade-off often resided in how 95 much redundancy a system adds to cope with link impairments, without 96 reducing the goodput when the channel quality is good. There is 97 usually enough redundancy to guarantee a Quasi-Error Free 98 transmission. The recovery time depends on the encoding block size. 99 Considering for instance geostationary satellite system (GEO), 100 physical or link layer erasure coding mechanisms recover transmission 101 losses within a negligible delay compared to link delay. However, 102 when retransmissions are triggered, this leads to a non-negligible 103 additional delay in particular over GEO link. Further exploiting 104 coding techniques at application or transport layers is an 105 opportunity for releasing constraints on the physical layer and 106 improving the performance of SATCOM systems. 108 The notations used in this document are based on the taxonomy 109 document [RFC8406]: 111 o Channel and link codings are gathered in the PHY layer coding and 112 are out of the scope of this document. It focuses on situations 113 where coding is not widely deployed in current SATCOM systems. 115 o FEC (also called Application-Level FEC) operates in and above the 116 network layer. 118 o This document considers coding (or coding techniques or coding 119 schemes) as a linear combination and not as a content coding 120 (e.g., to compress a video flow). 122 Figure 1 presents the status of the reliability schemes deployment in 123 satellite systems. 125 o X1 embodies the source coding techniques that could be used at 126 application level for instance within QUIC. This is not specific 127 to SATCOM systems since such deployment can be relevant for 128 broadband Internet access discussions. 130 o X2 embodies the physical-layer techniques exploited in SATCOM 131 systems (note that other coding techniques can be exploited). 132 This is out of the scope of the document. 134 +------+-------+---------+---------------+-------+ 135 | | Upper | Middle | Communication layers | 136 | | Appl. | ware | | 137 + +-------+---------+---------------+-------+ 138 | |Source | Network | Packetization | PHY | 139 | |coding | AL-FEC | UDP/IP | layer | 140 +------+-------+---------+---------------+-------+ 141 |E2E | X1 | | | | 142 |NC | | | | | 143 |IntraF| X1 | | | | 144 |InterF| | | | X2 | 145 |SPC | X1 | | | X2 | 146 |MPC | | | | | 147 +------+-------+---------+---------------+-------+ 149 Figure 1: Reliability schemes in current satellite systems 151 We notice an active research activity on coding techniques and 152 SATCOM. That being said, not much has actually made it to industrial 153 developments. In this context, this document aims at identifying 154 opportunities for further usage of coding in these systems. 156 2. A note on satellite topology 158 This section describes a satellite system that follows the ETSI DVB 159 standards to provide broadband Internet access. A high-level 160 description of a multi-gateway satellite network is provided. There 161 are multiple SATCOM systems, such as those dedicated to broadcasting 162 TV or to IoT applications: depending on the purpose of the SATCOM 163 system, ground segments are specific. In this context, the increase 164 of the available capacity that is carried out to end users and 165 reliability requirements lead to multiple gateways for one unique 166 satellite platform. 168 In this context, Figure 2 shows an example of a multi-gateway 169 satellite system. In a multi-gateway system, some elements may be 170 centralized and/or gathered: the relevance of one approach compared 171 to another depends on the deployment scenario. More information on 172 these discussions and a generic SATCOM ground segment architecture 173 for bidirectional Internet access can be found in [SAT2017]. 175 Some functional blocks aggregate the traffic of multiple users. 177 +--------------------------+ 178 | application servers | 179 | (data, coding, multicast | 180 +--------------------------+ 181 | ... | 182 ----------------------------------- 183 | | | | | | 184 +--------------------+ +--------------------+ 185 | network function | | network function | 186 |(firewall, PEP, etc)| |(firewall, PEP, etc)| 187 +--------------------+ +--------------------+ 188 | ... | IP packets | ... | 189 --- 190 +------------------+ +------------------+ | 191 | access gateway | | access gateway | | 192 +------------------+ +------------------+ | 193 | BBFRAME | | gateway 194 +------------------+ +------------------+ | 195 | physical gateway | | physical gateway | | 196 +------------------+ +------------------+ | 197 --- 198 | PLFRAME | 199 +------------------+ +------------------+ 200 | outdoor unit | | outdoor unit | 201 +------------------+ +------------------+ 202 | satellite link | 203 +------------------+ +------------------+ 204 | outdoor unit | | out door unit | 205 +------------------+ +------------------+ 206 | | 207 +------------------+ +------------------+ 208 | sat terminals | | sat terminals | 209 +------------------+ +------------------+ 210 | | | | 211 +----------+ | +----------+ | 212 |end user 1| | |end user 3| | 213 +----------+ | +----------+ | 214 +----------+ +----------+ 215 |end user 2| |end user 4| 216 +----------+ +----------+ 218 Figure 2: Data plane functions in a generic satellite multi-gateway 219 system. More details can be found in DVB standard documents. 221 3. Use-cases for improving the SATCOM system performance with coding 222 techniques 224 This section details use-cases where coding techniques could provide 225 interesting features for SATCOM systems. Combination of the 226 presented use-cases could also be relevant. 228 It is worth noting that these use-cases mostly focus on the 229 middleware and packetization UDP/IP of Figure 1. There are already 230 lots of recovery mechanisms at the physical-layer in currently 231 deployed systems while E2E source coding is done at the application 232 level. In a multi-gateway SATCOM Internet access, the deployment 233 opportunities are more relevant in specific SATCOM components such as 234 the "network function" block or the "access gateway" of Figure 2. 236 3.1. Two-way relay channel mode 238 This use-case considers a two-way communication between end users, 239 through a satellite link. Figure 3 proposes an illustration of this 240 scenario. 242 Satellite terminal A sends a flow A and satellite terminal B sends a 243 flow B to a coding server. The coding server sends a combination of 244 both terminal flows. This results in non-negligible capacity savings 245 and has been demonstrated [ASMS2010]. In the proposed example, a 246 dedicated coding server is introduced. Its location could be changed 247 depending on the deployment use-case. With On-Board Processing 248 satellite payloads, the coding operations could be done at the 249 satellite level; although this would require lots of computational 250 ressource on-board and may not be relevant with today's payloads. 252 -X}- : traffic from satellite terminal X to the server 253 ={X+Y= : traffic from X and Y combined sent from 254 the server to terminals X and Y 256 +-----------+ +-----+ 257 |Sat term A |--A}-+ | | 258 +-----------+ | | | +---------+ +------+ 259 ^^ +--| |--A}--| |--A}--|Coding| 260 || | SAT |--B}--| Gateway |--B}--|Server| 261 ===={A+B=========| |={A+B=| |={A+B=| | 262 || | | +---------+ +------+ 263 vv +--| | 264 +-----------+ | | | 265 |Sat term B |--B}-+ | | 266 +-----------+ +-----+ 268 Figure 3: Network architecture for two way relay channel with NC 270 3.2. Reliable multicast 272 Using multicast servers is a way to better exploit the satellite 273 broadcast capabilities. This approach is proposed in the SHINE ESA 274 project [I-D.vazquez-nfvrg-netcod-function-virtualization] [SHINE]. 275 This use-case considers adding redundancy to a multicast flow 276 depending on what has been received by different end-users, resulting 277 in non-negligible scarce resource saving. We propose an illustration 278 for this scenario in Figure 4. 280 -Li}- : packet indicating the loss of packet i of a multicast flow M 281 ={M== : multicast flow including the missing packets 283 +-----------+ +-----+ 284 |Sat term A |-Li}-+ | | 285 +-----------+ | | | +---------+ +------+ 286 ^^ +-| |-Li}--| | |Multi | 287 || | SAT |-Lj}--| Gateway |--|Cast | 288 ===={M==========| |={M===| | |Server| 289 || | | +---------+ +------+ 290 vv +-| | 291 +-----------+ | | | 292 |Sat term B |-Lj}-+ | | 293 +-----------+ +-----+ 295 Figure 4: Network architecture for a reliable multicast with NC 297 A multicast flow (M) is forwarded to both satellite terminals A and 298 B. However packet Ni (resp. Nj) gets lost at terminal A (resp. B), 299 and terminal A (resp. B) returns a negative acknowledgment Li (resp. 300 Lj), indicating that the packet is missing. Then either the access 301 gateway or the multicast server includes a repair packet (rather than 302 the individual Ni and Nj packets) in the multicast flow to let both 303 terminals recover from losses. 305 This could be achieved by using other multicast or broadcast systems, 306 such as NACK-Oriented Reliable Multicast (NORM) [RFC5740] or File 307 Delivery over Unidirectional Transport (FLUTE) [RFC6726]. Note that 308 both NORM and FLUTE are limited to block coding, none of them 309 supporting sliding window encoding schemes [RFC8406]. Note that 310 although FLUTE is defined as an unidirectional protocol, the RFC 311 proposes a bidirectional communication method to enable full 312 reliability transfer and for security purposes. 314 3.3. Hybrid access 316 This use-case considers the use of multiple path management with 317 coding at the transport layer to increase the reliability and/or the 318 total capacity (using multiple paths does not guarantee an 319 improvement of both the reliability and the total capacity). We 320 propose an illustration for this scenario in Figure 5. This use-case 321 is inspired from the Broadband Access via Integrated Terrestrial 322 Satellite Systems (BATS) project and has been published as an ETSI 323 Technical Report [ETSITR2017]. This kind of architecture is also 324 discussed in the TCPM working group [I-D.ietf-tcpm-converters]. 326 To cope with packet loss (due to either end-user mobility or 327 physical-layer impairments), coding techniques could be introduced 328 both at the CPE and at the concentrator. Apart from packet losses, 329 other gains could be envisioned, such as a better tolerance to out- 330 of-order packets which occur when exploited links exhibit high 331 asymetry in terms of RTT. Depending on the ground architecture 332 [I-D.chin-nfvrg-cloud-5g-core-structure-yang] [SAT2017], some 333 equipments might be hosting both SATCOM and cellular functions. 335 -{}- : bidirectional link 337 +-----+ +----------------+ 338 +-{}-| SAT |-{}-| BACKBONE | 339 +------+ +------+ | +-----+ | +------------+ | 340 | End |-{}-| CPE |-{}-| | |CONCENTRATOR| | 341 | User | | | | +-----+ | +------------+ | +------------+ 342 +------+ +------+ |-{}-| DSL |-{}-| |-{}-|Application | 343 | +-----+ | | |Server | 344 | | | +------------+ 345 | +-----+ | | 346 +-{}-| LTE |-{}-| | 347 +-----+ +----------------+ 349 Figure 5: Network architecture for an hybrid access using coding 351 3.4. Dealing with LAN losses 353 This use-case considers the usage of coding techniques to cope with 354 cases where the end user connects to the satellite terminal with a 355 Wi-Fi link that exhibits losses. In the case of encrypted end-to-end 356 applications based on UDP, PEP cannot operate. The Wi-Fi losses 357 result in an end-to-end retransmission that would harm the quality of 358 experience of the end user. 360 The architecture is recalled in Figure 6. 362 In this use-case, adding coding techniques could prevent the end-to- 363 end retransmission from occuring. 365 -{}- : bidirectional link 366 -''- : Wi-Fi link 367 C : where coding techniques could be introduced 369 +---------+ +---------+ +---+ +--------+ +-------+ +--------+ 370 | | |Satellite| |SAT| |Physical| |Access | |Network | 371 |End user |-''-|Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function| 372 +---------+ +---------+ +---+ +--------+ +-------+ +--------+ 373 C C C C 375 Figure 6: Network architecture for dealing with LAN losses 377 3.5. Dealing with varying channel conditions 379 This use-case considers the usage of coding techniques to cope with 380 cases where channel condition can change in less than a second and 381 where the physical-layer codes could not efficiently guarantee a 382 Quasi-Error-Free (QEF) transmission. 384 The architecture is recalled in Figure 7. In these cases, the 385 mechanisms that are exploited to adapt the physical-layer codes 386 (Adaptative Coding and Modulation (ACM)) may adapt the modulation and 387 coding in time: remaining errors could be recovered with higher layer 388 redundancy packets. Coding may be applied on IP packets or on 389 layer-2 proprietary format packets. 391 This use-case is mostly relevant when mobile users are considered or 392 when the chosen band induces a required physical-layer coding that 393 may change over time (Q/V bands, Ka band, etc.). Depending on the 394 use-case (e.g., very high frequency bands, mobile users) or depending 395 on the deployment use-cases (e.g., performance of the network between 396 each individual block), the relevance of adding coding techniques is 397 different. 399 -{}- : bidirectional link 400 C : where coding techniques could be introduced 402 +---------+ +---+ +--------+ +-------+ +--------+ 403 |Satellite| |SAT| |Physical| |Access | |Network | 404 |Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function| 405 +---------+ +---+ +--------+ +-------+ +--------+ 406 C C C C 408 Figure 7: Network architecture for dealing with varying link 409 characteristics 411 3.6. Improving the gateway handovers 413 This use-case considers the recovery of packets that may be lost 414 during gateway handovers. Whether this is for off-loading one given 415 equipment or because the transmission quality is not the same on each 416 gateway, changing the transmission gateway may be relevant. However, 417 if gateways are not properly synchronized or if the algorithm that is 418 exploited to trigger gateway handovers shows a non negligible 419 probability of missed detection, this may result in packet losses. 420 During these critical phases, coding can be added to improve the 421 reliability of the transmission and allow a seamless gateway 422 handover. Coding could be applied at either the access gateway or 423 the network function block. A potential control plane is in charge 424 of taking the decision to change the communication gateway and the 425 consequent routes. 427 Figure 8 illustrates this use-case. 429 -{}- : bidirectional link 430 ! : management interface 431 C : where coding techniques could be introduced 432 C C 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 C C 449 Figure 8: Network architecture for dealing with gateway handover 450 schemes 452 4. Research challenges 454 This section proposes a few potential approaches to introduce and use 455 coding techniques in SATCOM systems. 457 4.1. On the joint-use of coding techniques and congestion control in 458 SATCOM systems 460 SATCOM systems typically feature Performance Enhancing Proxy (PEP) 461 RFC 3135 [RFC3135]. PEPs usually split TCP end-to-end connections 462 and forward TCP packets to the satellite baseband gateway that deals 463 with layer-2 and layer-1 encapsulations. PEP contributes to mitigate 464 congestion in a SATCOM systems. PEP could host coding mechanisms and 465 thus support use-cases that have been discussed in this document. 467 Deploying coding schemes at the TCP level in these equipment could be 468 relevant and independent from the specific characteristics of a 469 SATCOM link. This leads to research questions on the interaction 470 between coding schemes and TCP congestion controls. 472 4.2. On the efficient usage of satellite resource 474 The recurrent trade-off in SATCOM systems remains: how much overhead 475 from redundant reliability packets can be introduced to guarantee a 476 better end-user QoE while optimizing capacity usage ? At which layer 477 this supplementary coding could be added ? 479 This problem has been tackled in the past for physical-layer code, 480 but there remains questions on how to adapt the overhead for, e.g., 481 the quickly varying channel conditions use-case where ACM may not be 482 reacting quickly enough. 484 4.3. Interaction with virtualized satellite gateways and terminals 486 Related to the foreseen virtualized network infrastructure, coding 487 techniques could be easily deployed as VNF. Next generation of 488 SATCOM ground segments could rely on a virtualized environment. This 489 trend can also be seen in cellular networks, making these discussions 490 extendable to other deployment scenarios 491 [I-D.chin-nfvrg-cloud-5g-core-structure-yang]. As one example, the 492 coding VNF deployment in a virtualized environment is presented in 493 [I-D.vazquez-nfvrg-netcod-function-virtualization]. 495 A research challenge would be the optimization of the NFV service 496 function chaining, considering a virtualized infrastructure and other 497 SATCOM specific functions, to guarantee efficient radio usage and 498 easy-to-deploy SATCOM services. Moreover, another challenge related 499 to a virtualized SATCOM equipment is the management of limited 500 buffered capacities. 502 4.4. Delay/Disruption Tolerant Networks 504 Communications among deep-space platforms and terrestrial gateways 505 can be a challenge. Reliable end-to-end (E2E) communications over 506 such paths must cope with long delay and frequent link disruptions; 507 indeed, contemporaneous E2E connectivity may be available only 508 intermittently or never. Delay/Disruption Tolerant Networking 509 [RFC4838] is a solution to enable reliable internetworking space 510 communications where both standard ad-hoc routing and E2E Internet 511 protocols cannot be used. Moreover, DTN can also be seen as an 512 alternative solution to transfer the data between a central PEP and a 513 remote PEP. 515 Coding enables E2E reliable communication over DTN with adaptive re- 516 encoding, as proposed in [THAI15]. In this case, the use-cases 517 proposed in Section 3.5 would legitimize the usage of coding within 518 the DTN stack to improve the channel utilization and the E2E 519 transmission delay. In this context, the use of erasure coding 520 techniques inside a Consultative Committee for Space Data Systems 521 (CCSDS) architecture has been specified in [CCSDS-131.5-O-1]. A 522 research challenge would be on how such coding can be integrated in 523 the IETF DTN stack. 525 5. Conclusion 527 This document discuses some opportunities to introduce coding 528 techniques at a wider scale in satellite telecommunications systems. 530 Even though this document focuses on satellite systems, it is worth 531 pointing out that some scenarios proposed may be relevant to other 532 wireless telecommunication systems. As one example, the generic 533 architecture proposed in Figure 2 may be mapped to cellular networks 534 as follows: the 'network function' block gathers some of the 535 functions of the Evolved Packet Core subsystem, while the 'access 536 gateway' and 'physical gateway' blocks gather the same type of 537 functions as the Universal Mobile Terrestrial Radio Access Network. 538 This mapping extends the opportunities identified in this draft since 539 they may be also relevant for cellular networks. 541 6. Glossary 543 The glossary of this memo extends the glossary of the taxonomy 544 document [RFC8406] as follows: 546 o ACM : Adaptive Coding and Modulation; 548 o BBFRAME: Base-Band FRAME - satellite communication layer 2 549 encapsulation work as follows: (1) each layer 3 packet is 550 encapsulated with a Generic Stream Encapsulation (GSE) mechanism, 551 (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs 552 contain information related to how they have to be modulated (4) 553 BBFRAMEs are forwarded to the physical-layer; 555 o CPE: Customer Premises Equipment; 557 o COM: COMmunication; 559 o DSL: Digital Subscriber Line; 561 o DTN: Delay/Disruption Tolerant Network; 563 o DVB: Digital Video Broadcasting; 565 o E2E: End-to-end; 567 o ETSI: European Telecommunications Standards Institute; 569 o FEC: Forward Error Correction; 571 o FLUTE: File Delivery over Unidirectional Transport; 573 o IntraF: Intra-Flow Coding; 575 o InterF: Inter-Flow Coding; 577 o IoT: Internet of Things; 579 o LTE: Long Term Evolution; 581 o MPC: Multi-Path Coding; 583 o NC: Network Coding; 585 o NFV: Network Function Virtualization; 587 o NORM: NACK-Oriented Reliable Multicast; 589 o PEP: Performance Enhancing Proxy [RFC3135] - a typical PEP for 590 satellite communications include compression, caching and TCP 591 acceleration; 593 o PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME 594 with additional information (e.g., related to synchronization); 596 o QEF: Quasi-Error-Free; 597 o QoE: Quality-of-Experience; 599 o QoS: Quality-of-Service; 601 o SAT: SATellite; 603 o SATCOM: generic term related to all kind of SATellite 604 COMmunication systems; 606 o SPC: Single-Path Coding; 608 o VNF: Virtual Network Function. 610 7. 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 8. IANA Considerations 618 This memo includes no request to IANA. 620 9. 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 10. Informative References 632 [ASMS2010] 633 De Cola, T. and et. al., "Demonstration at opening session 634 of ASMS 2010", Advanced Satellite Multimedia Systems 635 (ASMS) Conference , 2010. 637 [CCSDS-131.5-O-1] 638 "Erasure correcting codes for use in near-earth and deep- 639 space communications", CCSDS Experimental 640 specification 131.5-0-1, 2014. 642 [ETSITR2017] 643 "Satellite Earth Stations and Systems (SES); Multi-link 644 routing scheme in hybrid access network with heterogeneous 645 links", ETSI TR 103 351, 2017. 647 [I-D.chin-nfvrg-cloud-5g-core-structure-yang] 648 Chen, C. and Z. Pan, "Yang Data Model for Cloud Native 5G 649 Core structure", draft-chin-nfvrg-cloud-5g-core-structure- 650 yang-00 (work in progress), December 2017. 652 [I-D.ietf-tcpm-converters] 653 Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., 654 and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- 655 tcpm-converters-13 (work in progress), October 2019. 657 [I-D.vazquez-nfvrg-netcod-function-virtualization] 658 Vazquez-Castro, M., Do-Duy, T., Romano, S., and A. Tulino, 659 "Network Coding Function Virtualization", draft-vazquez- 660 nfvrg-netcod-function-virtualization-02 (work in 661 progress), November 2017. 663 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 664 Shelby, "Performance Enhancing Proxies Intended to 665 Mitigate Link-Related Degradations", RFC 3135, 666 DOI 10.17487/RFC3135, June 2001, 667 . 669 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 670 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 671 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 672 April 2007, . 674 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 675 Transmission Protocol - Specification", RFC 5326, 676 DOI 10.17487/RFC5326, September 2008, 677 . 679 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 680 "NACK-Oriented Reliable Multicast (NORM) Transport 681 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 682 . 684 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 685 "FLUTE - File Delivery over Unidirectional Transport", 686 RFC 6726, DOI 10.17487/RFC6726, November 2012, 687 . 689 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 690 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 691 Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and 692 S. Sivakumar, "Taxonomy of Coding Techniques for Efficient 693 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 694 June 2018, . 696 [SAT2017] Ahmed, T., Dubois, E., Dupe, JB., Ferrus, R., Gelard, P., 697 and N. Kuhn, "Software-defined satellite cloud RAN", 698 International Journal on Satellite Communnications and 699 Networking vol. 36 - https://doi.org/10.1002/sat.1206, 700 2017. 702 [SHINE] Pietro Romano, S. and et. al., "Secure Hybrid In Network 703 caching Environment (SHINE) ESA project", ESA project , 704 2017 on-going. 706 [THAI15] Thai, T., Chaganti, V., Lochin, E., Lacan, J., Dubois, E., 707 and P. Gelard, "Enabling E2E reliable communications with 708 adaptive re-encoding over delay tolerant networks", 709 Proceedings of the IEEE International Conference on 710 Communications http://dx.doi.org/10.1109/ICC.2015.7248441, 711 June 2015. 713 Authors' Addresses 715 Nicolas Kuhn (editor) 716 CNES 717 18 Avenue Edouard Belin 718 Toulouse 31400 719 France 721 Email: nicolas.kuhn@cnes.fr 723 Emmanuel Lochin (editor) 724 ISAE-SUPAERO 725 10 Avenue Edouard Belin 726 Toulouse 31400 727 France 729 Email: emmanuel.lochin@isae-supaero.fr