idnits 2.17.1 draft-irtf-nwcrg-network-coding-satellites-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (June 4, 2019) is 1789 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5326' is defined on line 651, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-tcpm-converters-06 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: December 6, 2019 ISAE-SUPAERO 6 June 4, 2019 8 Coding techniques for satellite systems 9 draft-irtf-nwcrg-network-coding-satellites-05 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 above the network layer. In this 17 context, this memo details a multi-gateway satellite system to 18 identify use-cases where coding is relevant. As example, coding 19 operating above the network layer can be exploited to cope from 20 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 December 6, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . 7 64 3.1. Two-way relay channel mode . . . . . . . . . . . . . . . 7 65 3.2. Reliable multicast . . . . . . . . . . . . . . . . . . . 8 66 3.3. Hybrid access . . . . . . . . . . . . . . . . . . . . . . 9 67 3.4. Dealing with LAN losses . . . . . . . . . . . . . . . . . 9 68 3.5. Dealing with varying channel conditions . . . . . . . . . 10 69 3.6. Improving the gateway handovers . . . . . . . . . . . . . 11 70 4. Research challenges . . . . . . . . . . . . . . . . . . . . . 11 71 4.1. On the joint-use of coding techniques and congestion 72 control in SATCOM systems . . . . . . . . . . . . . . . . 12 73 4.2. On the efficient usage of satellite ressource . . . . . . 12 74 4.3. Interaction with virtualized satellite gateways and 75 terminals . . . . . . . . . . . . . . . . . . . . . . . . 12 76 4.4. Delay/Disruption Tolerant Networks . . . . . . . . . . . 12 77 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 9. Informative References . . . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 from 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 layers erasure coding mechanisms recover 95 transmission losses within a negligible delay compared to link delay. 97 However, when retransmissions are triggered, this leads to an non- 98 negligible additional delay in particular over GEO link. Further 99 exploiting coding techniques at application or transport layers is an 100 opportunity for releasing constraints on the physical layer and 101 improving the performance of SATCOM systems. 103 The notations used in this document are based on the taxonomy 104 document [RFC8406]: 106 o Channel and link codings are gathered in the PHY layer coding and 107 are out of the scope of this document. 109 o FEC (also called Application-Level FEC) operate above the network 110 layer. 112 o This document considers coding (or coding techniques or coding 113 schemes) as a linear combination and not as a content coding 114 (e.g., to compress a video flow). 116 Figure 1 presents the status of the reliability schemes deployment in 117 satellite systems. 119 o X1 embodies the source coding techniques that could be used at 120 application level for instance within QUIC. This is not specific 121 to SATCOM systems since such deployment can be relevant for 122 broadband Internet access discussions. 124 o X2 embodies the physical-layer techniques exploited in SATCOM 125 systems (note that other coding techniques can be exploited). 126 This is out of the scope of the document. 128 +------+-------+---------+---------------+-------+ 129 | | Upper | Middle | Communication layers | 130 | | Appl. | ware | | 131 + +-------+---------+---------------+-------+ 132 | |Source | Network | Packetization | PHY | 133 | |coding | AL-FEC | UDP/IP | layer | 134 +------+-------+---------+---------------+-------+ 135 |E2E | X1 | | | | 136 |NC | | | | | 137 |IntraF| X1 | | | | 138 |InterF| | | | X2 | 139 |SPC | X1 | | | X2 | 140 |MPC | | | | | 141 +------+-------+---------+---------------+-------+ 143 Figure 1: Reliability schemes in current satellite systems 145 We notice an active research activity on coding techniques and 146 SATCOM. That being said, not much has actually made it to industrial 147 developments. In this context, this document aims at identifying 148 opportunities for further usage of coding in these systems. 150 The glossary of this memo extends the glossary of the taxonomy 151 document [RFC8406] as follows: 153 o ACM : Adaptive Coding and Modulation; 155 o BBFRAME: Base-Band FRAME - satellite communication layer 2 156 encapsulation work as follows: (1) each layer 3 packet is 157 encapsulated with a Generic Stream Encapsulation (GSE) mechanism, 158 (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs 159 contain information related to how they have to be modulated (4) 160 BBFRAMEs are forwarded to the physical-layer; 162 o CPE: Customer Premises Equipment; 164 o COM: COMmunication; 166 o DSL: Digital Subscriber Line; 168 o DTN: Delay/Disruption Tolerant Network; 170 o ETSI: European Telecommunications Standards Institute; 172 o FEC: Forward Error Correction; 174 o FLUTE: File Delivery over Unidirectional Transport; 176 o IoT: Internet of Things; 178 o LTE: Long Term Evolution; 180 o NFV: Network Function Virtualization; 182 o NORM: NACK-Oriented Reliable Multicast; 184 o PEP: Performance Enhancing Proxy [RFC3135] - a typical PEP for 185 satellite communications include compression, caching and TCP 186 acceleration; 188 o PLFRAME: Physical Layer FRAME - modulated version of a BBFRAME 189 with additional information (e.g., related to synchronization); 191 o QEF: Quasi-Error-Free; 192 o QoE: Quality-of-Experience; 194 o QoS: Quality-of-Service; 196 o SAT: SATellite; 198 o SATCOM: generic term related to all kind of SATellite 199 COMmunication systems; 201 o VNF: Virtual Network Function. 203 This document is the product of and represents the collaborative work 204 and consensus of the Coding for Efficient Network Communications 205 Research Group (NWCRG); it is not an IETF product and is not a 206 standard. 208 2. A note on satellite topology 210 This section describes a satellite system that follows the ETSI DVB 211 standards to provide broadband Internet access. A high-level 212 description of a multi-gateway satellite network is provided. There 213 are multiple SATCOM systems, such as those dedicated to broadcasting 214 TV or to IoT applications: depending on the purpose of the SATCOM 215 system, ground segments are specific. In this context, the increase 216 of the available capacity that is carried out to end users and 217 reliability requirements lead to multiple gateways for one unique 218 satellite platform. 220 In this context, Figure 2 shows an example of a multi-gateway 221 satellite system. In a multi-gateway system, some elements may be 222 centralized and/or gathered: the relevance of one approach compared 223 to another depends on the deployment scenario. More information on 224 these discussions and a generic SATCOM ground segment architecture 225 for bidirectional Internet access can be found in [SAT2017]. 227 Some functional blocks aggregate the traffic of multiple users. 229 +--------------------------+ 230 | application servers | 231 | (data, coding, multicast | 232 +--------------------------+ 233 ^ ^ 234 | ... | 235 ----------------------------------- 236 v v v v v v 237 +------------------+ +------------------+ 238 | network function | | network function | 239 | (firewall, PEP) | | (firewall, PEP) | 240 +------------------+ +------------------+ 241 ^ ^ ^ ^ 242 | ... | IP packets | ... | 243 v v v v --- 244 +------------------+ +------------------+ | 245 | access gateway | | access gateway | | 246 +------------------+ +------------------+ | 247 ^ ^ | 248 | BBFRAME | | gateway 249 v v | 250 +------------------+ +------------------+ | 251 | physical gateway | | physical gateway | | 252 +------------------+ +------------------+ | 253 ^ ^ --- 254 | PLFRAME | 255 v v 256 +------------------+ +------------------+ 257 | outdoor unit | | outdoor unit | 258 +------------------+ +------------------+ 259 ^ ^ 260 | satellite link | 261 v v 262 +------------------+ +------------------+ 263 | sat terminals | | sat terminals | 264 +------------------+ +------------------+ 265 ^ ^ ^ ^ 266 | ... | | ... | 267 v v v v 268 +------------------+ +------------------+ 269 | end user | | end user | 270 +------------------+ +------------------+ 272 Figure 2: Data plane functions in a generic satellite multi-gateway 273 system 275 3. Use-cases for improving the SATCOM system performance with coding 276 techniques 278 This section details use-cases where coding techniques could provide 279 interesting features for SATCOM systems. 281 It is worth noting that these use-cases mostly focus on the 282 middleware and packetization UDP/IP of Figure 1. There are already 283 lots of recovery mechanisms at the physical-layer in currently 284 deployed systems while E2E source coding is done at the application 285 level. In a multi-gateway SATCOM Internet access, the deployment 286 opportunities are more relevant in specific SATCOM components such as 287 the "network function" block or the "access gateway" of Figure 2. 289 3.1. Two-way relay channel mode 291 This use-case considers a two-way communication between end users, 292 through a satellite link. Figure 3 proposes an illustration of this 293 scenario. 295 Satellite terminal A sends a flow A and satellite terminal B sends a 296 flow B to a coding server. The coding server sends a combination of 297 both terminal flows. This results in non-negligible capacity savings 298 and has been demonstrated [ASMS2010]. In the proposed example, a 299 dedicated coding server is introduced. Its location could be changed 300 depending on the deployment use-case. With On-Board Processing 301 satellite payloads, the coding operations could be done at the 302 satellite level; although this would require lots of computationnal 303 ressource on-board and may not be relevant with today's payloads. 305 -X}- : traffic from satellite terminal X to the server 306 ={X+Y= : traffic from X and Y combined sent from 307 the server to terminals X and Y 309 +-----------+ +-----+ 310 |Sat term A |--A}-+ | | 311 +-----------+ | | | +---------+ +------+ 312 ^^ +--| |--A}--| |--A}--|Coding| 313 || | SAT |--B}--| Gateway |--B}--|Server| 314 ===={A+B=========| |={A+B=| |={A+B=| | 315 || | | +---------+ +------+ 316 vv +--| | 317 +-----------+ | | | 318 |Sat term B |--B}-+ | | 319 +-----------+ +-----+ 321 Figure 3: Network architecture for two way relay channel with NC 323 3.2. Reliable multicast 325 Using multicast servers is a way to better exploit the satellite 326 broadcast capabilities. This approach is proposed in the SHINE ESA 327 project [I-D.vazquez-nfvrg-netcod-function-virtualization] [SHINE]. 328 This use-case considers adding redundancy to a multicast flow 329 depending on what has been received by different end-users, resulting 330 in non-negligible scarce resource saving. We propose an illustration 331 for this scenario in Figure 4. 333 -Li}- : packet indicating the loss of packet i of a multicast flow M 334 ={M== : multicast flow including the missing packets 336 +-----------+ +-----+ 337 |Sat term A |-Li}-+ | | 338 +-----------+ | | | +---------+ +------+ 339 ^^ +-| |-Li}--| | |Multi | 340 || | SAT |-Lj}--| Gateway |--|Cast | 341 ===={M==========| |={M===| | |Server| 342 || | | +---------+ +------+ 343 vv +-| | 344 +-----------+ | | | 345 |Sat term B |-Lj}-+ | | 346 +-----------+ +-----+ 348 Figure 4: Network architecture for a reliable multicast with NC 350 A multicast flow (M) is forwarded to both satellite terminals A and 351 B. However packet Ni (resp. Nj) gets lost at terminal A (resp. B), 352 and terminal A (resp. B) returns a negative acknowledgment Li (resp. 353 Lj), indicating that the packet is missing. Then either the access 354 gateway or the multicast server includes a repair packet (rather than 355 the individual Ni and Nj packets) in the multicast flow to let both 356 terminals recover from losses. 358 This could be achieved by using other multicast or broadcast systems, 359 such as NACK-Oriented Reliable Multicast (NORM) [RFC5740] in 360 situations where a feedback link is available, or File Delivery over 361 Unidirectional Transport (FLUTE) [RFC6726] otherwise. Note that both 362 NORM and FLUTE are limited to block coding, none of them supporting 363 sliding window encoding schemes [RFC8406]. Note that although FLUTE 364 is defined as an unidirectional protocol, the RFC proposes a 365 bidirectional communication method to enable full reliability 366 transfer and for security purpose. 368 3.3. Hybrid access 370 This use-case considers the use of multiple path management with 371 coding at the transport level to increase the reliability and/or the 372 total capacity (using multiple path does not guarantee an improvement 373 of both the reliability and the total capacity). We propose an 374 illustration for this scenario in Figure 5. This use-case is 375 inspired from the Broadband Access via Integrated Terrestrial 376 Satellite Systems (BATS) project and has been published as an ETSI 377 Technical Report [ETSITR2017]. This kind of architecture is also 378 discussed in the TCPM working group [I-D.ietf-tcpm-converters]. 380 To cope with packet loss (due to either end-user mobility or 381 physical-layer impairments), coding techniques could be introduced 382 both at the CPE and at the concentrator. Appart from packet losses, 383 other gains could be envisionned, such as a better tolerance to out- 384 of-order packets which occur when exploited links exhibit high 385 asymetry in terms of RTT. Depending on the ground architecture 386 [I-D.chin-nfvrg-cloud-5g-core-structure-yang] [SAT2017], some 387 equipments might be hosting both SATCOM and cellular functions. 389 -{}- : bidirectional link 391 +-----+ +----------------+ 392 +-{}-| SAT |-{}-| BACKBONE | 393 +------+ +------+ | +-----+ | +------------+ | 394 | End |-{}-| CPE |-{}-| | |CONCENTRATOR| | 395 | User | | | | +-----+ | +------------+ | +------------+ 396 +------+ +------+ |-{}-| DSL |-{}-| |-{}-|Application | 397 | +-----+ | | |Server | 398 | | | +------------+ 399 | +-----+ | | 400 +-{}-| LTE |-{}-| | 401 +-----+ +----------------+ 403 Figure 5: Network architecture for an hybrid access using coding 405 3.4. Dealing with LAN losses 407 This use-case considers the usage of coding techniques to cope from 408 cases where the end user connects to the satellite terminal with a 409 Wi-Fi link that exhibits losses. In the case of encrypted end-to-end 410 applications based on UDP, PEP cannot operate. The Wi-Fi losses 411 result in an end-to-end retransmission that would harm the quality of 412 experience of the end user. 414 The architecture is recalled in Figure 6. 416 In this use-case, adding coding techniques could prevent the end-to- 417 end retransmission from occuring. 419 -{}- : bidirectional link 420 -''- : Wi-Fi link 422 +---------+ +---------+ +---+ +--------+ +-------+ +--------+ 423 | | |Satellite| |SAT| |Physical| |Access | |Network | 424 |End user |-''-|Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function| 425 +---------+ +---------+ +---+ +--------+ +-------+ +--------+ 426 C C C C 428 Figure 6: Network architecture for dealing with LAN losses 430 3.5. Dealing with varying channel conditions 432 This use-case considers the usage of coding techniques to cope from 433 cases where channel condition can change in less than a second and 434 where the physical-layer codes could not guarantee a Quasi-Error-Free 435 (QEF) transmission. 437 The architecture is recalled in Figure 7. In these cases, the 438 mechanisms that is exploited to adapt the physical-layer codes 439 (Adaptative Coding and Modulation (ACM)) may adapt the modulation and 440 coding in time: remaining errors could be recovered with higher 441 layers redundancy packets. Coding may be applied on IP packets or on 442 layer-2 proprietary format packets. 444 This use-case is mostly relevant when mobile users are considered or 445 when the chosen band induce a required physical-layer coding that may 446 change over time (Q/V bands, Ka band, etc.). Depending on the use- 447 case (e.g., very high frequency bands, mobile users) or depending on 448 the deployment use-cases (e.g., performance of the network between 449 each individual block), the relevance of adding coding techniques is 450 different. 452 -{}- : bidirectional link 454 +---------+ +---+ +--------+ +-------+ +--------+ 455 |Satellite| |SAT| |Physical| |Access | |Network | 456 |Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function| 457 +---------+ +---+ +--------+ +-------+ +--------+ 458 C C C C 460 Figure 7: Network architecture for dealing with varying link 461 characteristics 463 3.6. Improving the gateway handovers 465 This use-case considers the recovery of packets that may be lost 466 during gateway handovers. Whether this is for off-loading one given 467 equipment or because the transmission quality is not the same on each 468 gateway, changing the transmission gateway may be relevant. However, 469 if gateways are not properly synchronized or if the algorithm that is 470 exploited to trigger gateway handovers shows a non negligible 471 probability of missed detection, this may result in packet losses. 472 During these critical phases, coding can be added to improve the 473 reliability of the transmission and allow a seamless gateway 474 handover. Coding could be applied at either the access gateway or 475 the network function block. The control plane manager is in charge 476 of taking the decision to change the communication gateway and the 477 consequent routes. 479 Figure 8 illustrates this use-case. 481 -{}- : bidirectional link 482 ! : management interface 483 C C 484 +--------+ +-------+ +--------+ 485 |Physical| |Access | |Network | 486 +-{}-|gateway |-{}-|gateway|-{}-|function| 487 | +--------+ +-------+ +--------+ 488 | ! ! 489 +---------+ +---+ +---------------+ 490 |Satellite| |SAT| | Control plane | 491 |Terminal |-{}-| | | manager | 492 +---------+ +---+ +---------------+ 493 | ! ! 494 | +--------+ +-------+ +--------+ 495 +-{}-|Physical|-{}-|Access |-{}-|Network | 496 |gateway | |gateway| |function| 497 +--------+ +-------+ +--------+ 498 C C 500 Figure 8: Network architecture for dealing with gateway handover 501 schemes 503 4. Research challenges 505 This section proposes to discuss few research challenges related to 506 the introduction and the use of coding techniques in SATCOM systems. 508 4.1. On the joint-use of coding techniques and congestion control in 509 SATCOM systems 511 SATCOM systems typically feature Performance Enhancement Proxy (PEP) 512 RFC 3135 [RFC3135]. PEP usually split TCP end-to-end connections and 513 forward TCP packets to the satellite baseband gateway that deals with 514 layer-2 and layer-1 encapsulations. PEP contributes to mitigate 515 congestion in a SATCOM systems. PEP could host coding mechanisms and 516 thus support use-cases that have been discussed in this document. 518 Deploying coding schemes at the TCP level in these equipment could be 519 relevant and independent from the specific characteristics of a 520 SATCOM link. This leads to research question on the interaction 521 between coding schemes and TCP congestion controls. 523 4.2. On the efficient usage of satellite ressource 525 The recurrent trade-off in SATCOM systems remains: how much overhead 526 from redundant reliability packets can be introduced to guarantee a 527 better end-user QoE while optimizing capacity usage ? 529 This problem has been tackled in the past for physical-layer code, 530 but there remains questions on how to adapt the overhead for, e.g., 531 the quickly varying channel conditions use-case. 533 4.3. Interaction with virtualized satellite gateways and terminals 535 Related to the foreseen virtualized network infrastructure, coding 536 techniques could be easily deployed as VNF. Next generation of 537 SATCOM ground segments could rely on a virtualized environment. This 538 trend can also be seen in cellular networks, making these discussions 539 extendable to other deployment scenarios 540 [I-D.chin-nfvrg-cloud-5g-core-structure-yang]. As one example, the 541 coding VNF functions deployment in a virtualized environment is 542 presented in [I-D.vazquez-nfvrg-netcod-function-virtualization]. 544 A research challenge would be the optimization of the NFV service 545 function chaining, considering a virtualized infrastructure and other 546 SATCOM specific functions, to guarantee an efficient radio usage and 547 easy-to-deploy SATCOM services. Moreover, another challenge related 548 to a virtualized SATCOM terminals is the management of limited 549 buffered equipments. 551 4.4. Delay/Disruption Tolerant Networks 553 In the context of the deep-space communications, establishing 554 communications from terrestrial gateways to satellite platforms can 555 be a challenge. Reliable end-to-end (E2E) communications over such 556 links must cope with long delay and frequent link disruptions. 557 Delay/Disruption Tolerant Networking [RFC4838] is a solution to 558 enable reliable internetworking space communications where both 559 standard ad-hoc routing and E2E Internet protocols cannot be used. 560 Moreover, DTN can also be seen as an alternative solution to transfer 561 the data between a central PEP and a remote PEP. 563 Coding enables E2E reliable communication over DTN with adaptive re- 564 encoding, as proposed in [THAI15]. In this case, the use-cases 565 proposed in Section 3.5 would legitimize the usage of coding within 566 the DTN stack to improve the channel utilization and the E2E 567 transmission delay. In this context, the use of erasure coding 568 techniques inside a Consultative Committee for Space Data Systems 569 (CCSDS) architecture has been specified in [CCSDS-131.5-O-1]. A 570 research challenge would be on how such coding can be integrated in 571 the IETF DTN stack. 573 5. Conclusion 575 This document discuses some opportunities to introduce coding 576 techniques at a wider scale in satellite telecommunications systems. 578 Even though this document focuses on satellite systems, it is worth 579 pointing out that some scenarios proposed may be relevant to other 580 wireless telecommunication systems. As one example, the generic 581 architecture proposed in Figure 2 may be mapped to cellular networks 582 as follows: the 'network function' block gather some of the functions 583 of the Evolved Packet Core subsystem, while the 'access gateway' and 584 'physical gateway' blocks gather the same type of functions as the 585 Universal Mobile Terrestrial Radio Access Network. This mapping 586 extends the opportunities identified in this draft since they may be 587 also relevant for cellular networks. 589 6. Acknowledgements 591 Many thanks to Tomaso de Cola, Vincent Roca, Lloyd Wood and Marie- 592 Jose Montpetit for their help in writing this document. 594 7. IANA Considerations 596 This memo includes no request to IANA. 598 8. Security Considerations 600 Security considerations are inherent to any access network, and in 601 particular SATCOM systems. The use of FEC or Network Coding in 602 SATCOM also comes with risks (e.g., a single corrupted redundant 603 packet may propagate to several flows when they are protected 604 togething in an Inter-Flow coding approach, see section Section 3). 605 However this is not specific to the SATCOM use-case and this document 606 does not further elaborate on it. 608 9. Informative References 610 [ASMS2010] 611 De Cola, T. and et. al., "Demonstration at opening session 612 of ASMS 2010", ASMS , 2010. 614 [CCSDS-131.5-O-1] 615 "Erasure correcting codes for use in near-earth and deep- 616 space communications", CCSDS Experimental 617 specification 131.5-0-1, 2014. 619 [ETSITR2017] 620 "Satellite Earth Stations and Systems (SES); Multi-link 621 routing scheme in hybrid access network with heterogeneous 622 links", ETSI TR 103 351, 2017. 624 [I-D.chin-nfvrg-cloud-5g-core-structure-yang] 625 Chen, C. and Z. Pan, "Yang Data Model for Cloud Native 5G 626 Core structure", draft-chin-nfvrg-cloud-5g-core-structure- 627 yang-00 (work in progress), December 2017. 629 [I-D.ietf-tcpm-converters] 630 Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., 631 and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- 632 tcpm-converters-06 (work in progress), March 2019. 634 [I-D.vazquez-nfvrg-netcod-function-virtualization] 635 Vazquez-Castro, M., Do-Duy, T., Romano, S., and A. Tulino, 636 "Network Coding Function Virtualization", draft-vazquez- 637 nfvrg-netcod-function-virtualization-02 (work in 638 progress), November 2017. 640 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 641 Shelby, "Performance Enhancing Proxies Intended to 642 Mitigate Link-Related Degradations", RFC 3135, 643 DOI 10.17487/RFC3135, June 2001, 644 . 646 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 647 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 648 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 649 April 2007, . 651 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 652 Transmission Protocol - Specification", RFC 5326, 653 DOI 10.17487/RFC5326, September 2008, 654 . 656 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 657 "NACK-Oriented Reliable Multicast (NORM) Transport 658 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 659 . 661 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 662 "FLUTE - File Delivery over Unidirectional Transport", 663 RFC 6726, DOI 10.17487/RFC6726, November 2012, 664 . 666 [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 667 F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., 668 Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and 669 S. Sivakumar, "Taxonomy of Coding Techniques for Efficient 670 Network Communications", RFC 8406, DOI 10.17487/RFC8406, 671 June 2018, . 673 [SAT2017] Ahmed, T., Dubois, E., Dupe, JB., Ferrus, R., Gelard, P., 674 and N. Kuhn, "Software-defined satellite cloud RAN", Int. 675 J. Satell. Commun. Network. vol. 36, 2017. 677 [SHINE] Pietro Romano, S. and et. al., "Secure Hybrid In Network 678 caching Environment (SHINE) ESA project", ESA project , 679 2017 on-going. 681 [THAI15] Thai, T., Chaganti, V., Lochin, E., Lacan, J., Dubois, E., 682 and P. Gelard, "Enabling E2E reliable communications with 683 adaptive re-encoding over delay tolerant networks", 684 Proceedings of the IEEE International Conference on 685 Communications , June 2015. 687 Authors' Addresses 689 Nicolas Kuhn (editor) 690 CNES 691 18 Avenue Edouard Belin 692 Toulouse 31400 693 France 695 Email: nicolas.kuhn@cnes.fr 696 Emmanuel Lochin (editor) 697 ISAE-SUPAERO 698 10 Avenue Edouard Belin 699 Toulouse 31400 700 France 702 Email: emmanuel.lochin@isae-supaero.fr