idnits 2.17.00 (12 Aug 2021) /tmp/idnits5631/draft-lai-bmwg-istn-methodology-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (27 April 2022) is 17 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Benchmarking Methodology Working Group Z. Lai 3 Internet-Draft H. Li 4 Intended status: Informational Y. Deng 5 Expires: 29 October 2022 Q. Wu 6 J. Liu 7 Tsinghua University 8 27 April 2022 10 Problems and Requirements of Evaluation Methodology for Integrated Space 11 and Terrestrial Networks 12 draft-lai-bmwg-istn-methodology-01 14 Abstract 16 With the rapid evolution of the aerospace industry, many "NewSpace" 17 upstarts are actively deploying their mega-constellations in low 18 earth orbits (LEO) and building integrated space and terrestrial 19 networks (ISTN), promising to provide pervasive, low-latency, and 20 high-throughput Internet service globally. Due to the high 21 manufacturing, launching, and updating cost of LEO mega- 22 constellations, it is expected that ISTNs can be well designed and 23 evaluated before the launch of satellites. However, the progress of 24 designing, assessing, and understanding new network functionalities 25 and protocols for futuristic ISTNs faces a substantial obstacle: lack 26 of standardized evaluation methodology with acceptable realism (e.g. 27 can involve the unique dynamic behaviors of ISTNs), flexibility, and 28 cost. This memo first reviews the unique characteristics of LEO 29 mega-constellations. Further, it analyzes the limitation of existing 30 evaluation and analysis methodologies under ISTN environments. 31 Finally, it outlines the key requirements of future evaluation 32 methodology tailored for ISTNs. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 29 October 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Notation and Terminology . . . . . . . . . . . . . . . . . . 4 68 3. Quick Primer for Integrated Space and Terrestrial Networks . 5 69 3.1. Mega-constellation . . . . . . . . . . . . . . . . . . . 5 70 3.2. Topological Dynamics . . . . . . . . . . . . . . . . . . 6 71 3.3. Limited Resources . . . . . . . . . . . . . . . . . . . . 7 72 3.4. Long Manufacturing and Deployment Duration . . . . . . . 8 73 4. Problem Statement: We Need the Right Evaluation 74 Methodology . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1. Live networks and platforms . . . . . . . . . . . . . . . 9 76 4.2. Network Simulators . . . . . . . . . . . . . . . . . . . 10 77 4.3. Network Emulators . . . . . . . . . . . . . . . . . . . . 11 78 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 5. Requirements: New Evaluation Methodology Tailored for 80 ISTNs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 5.1. Realism . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 5.2. Flexibility . . . . . . . . . . . . . . . . . . . . . . . 13 83 5.3. Low-cost and Easy-to-use . . . . . . . . . . . . . . . . 13 84 5.4. Cross-domain Dataset Support . . . . . . . . . . . . . . 13 85 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 91 10.2. Informative References . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 Integrated Space and Terrestrial Networks (ISTN), combining diverse 97 spacecrafts and ground infrastructures, are extending the frontier of 98 today's terrestrial network, promising to provide low-latency, high- 99 bandwidth Internet access with broader coverage globally. 101 Low earth orbit (LEO) satellites are the key building block for 102 constructing ISTNs. Recently, we have witnessed a renaissance in the 103 space industry, stimulating an exponential increase in constructing 104 mega-constellations. As compared with their predecessor, cutting- 105 edge satellites can be equipped with high-resolution sensors, space- 106 grade multi-core processors, high-data-rate communication links, and 107 multifunctional space software. 109 While ISTNs hold great promise, to completely unleash the network 110 potential of emerging ISTN, it still needs to address a series of new 111 technical issues. The unique characteristics of LEO satellites 112 (e.g., high-dynamics), not only impose new challenges at various 113 layers of the ISTN networking stack but also open the door to many 114 new technical problems. With many unexplored problems facing the 115 "NewSpace" industry, it is thus foreseen that in the near future, 116 there will be a surge of new efforts (e.g. topology, addressing, 117 routing, transport, etc.) to rethink and reshape the networking stack 118 in ISTNs. In addition, the cost/timeline of manufacturing, 119 launching, operating, and updating satellite constellations is 120 typically much higher/longer than that in traditional terrestrial 121 networks. Therefore, it is expected that new network functionalities 122 and protocols can be well evaluated before they are launched and 123 deployed in realistic satellite constellations. 125 However, the network community lacks the proper analysis tools and 126 evaluation methodologies that can mimic the unique dynamic behavior 127 to analyze many of the ISTN challenges that have been highlighted by 128 prior works. At high level, existing evaluation methodologies in the 129 network community can typically be grouped into three major 130 categories: live networks or platforms, simulation, and emulation. 131 However, the feasibility and flexibility of live satellite networks 132 are technically and economically limited. The abstraction level of 133 network simulation could be too high to capture low-level system 134 effects. Existing network emulators fail to characterize the high 135 dynamicity of LEO satellites and thus cannot accomplish an 136 environment with acceptable fidelity. The community hence needs a 137 reasonable and standardized evaluation methodology to build proper 138 experimental environments which can mimic the behavior of ISTNs, 139 supporting the community to deeply understand the problems, and to 140 evaluate new functionalities and protocols (e.g. for topology, 141 addressing, routing, transport, etc.) for ISTNs, before the mega- 142 constellation is completely deployed. In this memo, we first review 143 the unique characteristics of emerging LEO mega-constellations and 144 the key challenges of integrating satellites and terrestrial 145 Internet. Further, we analyze the limitation of existing network 146 analysis tools and evaluation methodologies in ISTNs. Finally, we 147 outline key requirements of evaluation methodologies tailored for 148 ISTNs. 150 2. Notation and Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 156 This document uses the following acronyms and terminologies: 158 Mega-constellation: A group of satellites working as a system. 160 LEO: Low Earth Orbit with an altitude no more than 2000 km. 162 MEO: Medium Earth Orbit with an altitude from 2000 km to 35786 km. 164 GEO: Geostationary Earth Orbit with an altitude of 35786 km. 166 NGSO: Non-Geostationary Orbit 168 LSN: LEO Satellite Networks 170 ISTN: Integrated Satellite and Terrestrial Network 172 ISL: Inter-satellite Links 174 EO: Earth Observation 176 GS: Ground Station 178 AS: Autonomous System 180 EOS: Earth Observation Satellite 182 BGP: Border Gateway Protocol [RFC4271] 184 OSPF: Open Shortest Path First [RFC2328] 186 VM: Virtual Machine 188 3. Quick Primer for Integrated Space and Terrestrial Networks 190 Emerging mega-constellations with inter-satellite links (ISLs) can 191 build a satellite network in outer space, and further be integrated 192 with terrestrial ground infrastructures to construct an integrated 193 space and terrestrial network (ISTN). 195 3.1. Mega-constellation 197 A constellation is a group of satellites working as a system to give 198 a coverage of the earth surface, among which satellites are 199 positioned in fixed orbital planes with regular trajectories. LEO 200 and MEO satellites often belong to a constellation, because a single 201 satellite only covers a small area with high angular velocity. Thus, 202 continuous coverage over an area could be maintained by the relay 203 within a constellation, as compared with GEO satellites that only 204 provides a permanent coverage over a target area. Walker Delta 205 constellation is the most common formation for constellations. It is 206 defined as a bunch of circular orbits with a fixed inclination, 207 satellite number, number of equally spaced planes and the relative 208 spacing between satellites in adjacent planes. The famous Ballard 209 rosette constellation is another name of Walker Delta constellation, 210 where it uses a different notation. Near-polar Walker Star is one of 211 this kind, initially used by Iridium [Iridium]. Constellations with 212 a higher inclination give the polar regions more chances to get 213 accessed. The well-known emerging commercial constellations are 214 Starlink [Starlink-Fcc], Kuiper [Kuiper-Fcc] and Telesat 215 [Telesat-Fcc], as shown in Table 1 below. And all of them contain 216 more than one shell. 218 +==========+==========+=============+========+=================+ 219 | Name and | Altitude | Inclination | # of | # of satellites | 220 | Shell | (km) | (degree) | orbits | per orbit | 221 +==========+==========+=============+========+=================+ 222 | Starlink | 550 | 53 | 72 | 22 | 223 | S1 | | | | | 224 +----------+----------+-------------+--------+-----------------+ 225 | Starlink | 1110 | 53.8 | 32 | 50 | 226 | S2 | | | | | 227 +----------+----------+-------------+--------+-----------------+ 228 | Starlink | 1130 | 74 | 8 | 50 | 229 | S3 | | | | | 230 +----------+----------+-------------+--------+-----------------+ 231 | Starlink | 1275 | 81 | 5 | 75 | 232 | S4 | | | | | 233 +----------+----------+-------------+--------+-----------------+ 234 | Starlink | 1325 | 70 | 6 | 75 | 235 | S5 | | | | | 236 +----------+----------+-------------+--------+-----------------+ 237 | Kuiper | 630 | 51.9 | 34 | 34 | 238 | K1 | | | | | 239 +----------+----------+-------------+--------+-----------------+ 240 | Kuiper | 610 | 42 | 36 | 36 | 241 | K2 | | | | | 242 +----------+----------+-------------+--------+-----------------+ 243 | Kuiper | 590 | 33 | 28 | 28 | 244 | K3 | | | | | 245 +----------+----------+-------------+--------+-----------------+ 246 | Telesat | 1015 | 98.98 | 27 | 13 | 247 | T1 | | | | | 248 +----------+----------+-------------+--------+-----------------+ 249 | Telesat | 1325 | 50.88 | 40 | 33 | 250 | T2 | | | | | 251 +----------+----------+-------------+--------+-----------------+ 253 Table 1: Mega-constellation information. 255 3.2. Topological Dynamics 257 Unlike geostationary satellite networks or terrestrial core 258 infrastructure that keep a stable topology, LEO satellite networks 259 suffer from high topological dynamics, since LEO satellites move 260 fast, causing short-lived coverage for fixed terrestrial users. For 261 example, considering the first shell of Starlink Phase-I, a fixed 262 user sees each satellite for only up to 3 minutes in one pass, after 263 which the satellite moves away from the user's perspective. Table 2 264 shows the medium space-ground link churn intervals 265 [link-churn-interval] between existing GS and constellations. If 266 each GS only uses one antenna to connect the satellite with the 267 shortest distance, the medium interval is no more than one minute. 268 This kind of high dynamic motion incurs frequent link changes between 269 LEO satellites and GS or users, thus causing frequent topology 270 changes. Moreover, inter-satellites visibility may also change if 271 LEO satellites move in different directions or in different shells, 272 resulting in connectivity change of ISLs. 274 Such high LEO dynamics can impose significant challenges in the 275 networking stack of ISTNs. The high dynamics make the logical 276 network and mega-constellations and physical ISTN inconsistent. One 277 big challenge is how to overcome the routing oscillation properly in 278 the high dynamic ISTN environment. Frequent satellite-GS link 279 changes make the inter-connectivity of space and ground segments in 280 ISTNs unstable. Thus, the routing have to be re-calculated every 281 time the link changes. In addition, the topological dynamics also 282 result in RTT fluctuations in end-to-end paths, involving new 283 challenges for congestion control in ISTNs, as a RTT variation 284 observed by end-host might not indicate congestions. 286 +==========+==============+ 287 | Name | Interval (s) | 288 +==========+==============+ 289 | Starlink | 3.0901 | 290 +----------+--------------+ 291 | Kuiper | 5.0562 | 292 +----------+--------------+ 293 | OneWeb | 10.6824 | 294 +----------+--------------+ 295 | Telesat | 45.5696 | 296 +----------+--------------+ 298 Table 2: Space-ground 299 link churn interval. 301 3.3. Limited Resources 303 Space resources (e.g. CPU, energy) on satellites are limited, as 304 compared with terrestrial network. Since resource-constrained 305 satellites such as nanosatellites are only able to carry certain 306 sennsing or transferring missions, energy-consuming or complex tasks 307 may not be achievable in these satellites. Such complicated tasks 308 include on-board target identification and instant and continuous 309 disaster monitoring. 311 For example, the CPU frequency of current spaceborne processors (e.g. 312 RAD5545 [RAD5545], RAD750 [RAD750]) is only up to 466MHz per core. 313 More recently, some low energy-consuming commodity processors are 314 used in space to complete certain remote sensing missions under a 315 limited CPU capacity. [raspberry-pi] With a constrained computation 316 ability and limited storage and energy, satellite functions and 317 lifetime are greatly repressed. 319 3.4. Long Manufacturing and Deployment Duration 321 Different from terrestrial network infrastructures, the timeline of 322 manufacturing and deploying satellite networks could be much longer 323 due to the high cost and complex process during the development and 324 launch period. Satellites, as well as the orbit and spectrum they 325 used, have to be regulated, and launches have to be carefully 326 scheduled (e.g. to avoid the impact of poor weather conditions). In 327 addition, the maintenance and update cost of a satellite network is 328 also typically much higher than that in a terrestrial network. 330 For example, a review of 24 Air Force and Navy space vehicle (SV) 331 development programs found that on average it took about 7.5 years 332 from contract start to launch a government satellite. 333 [Development-Timeline] Commercial satellite programs typically take 2 334 to 3 years from contract start to launch. [Production-Cycles] 335 SpaceX's Starlink constellation plan to launch about 42,000 336 satellites to construct a mega-constellation in outer space. On 15 337 October 2019, the United States Federal Communications Commission 338 (FCC) submitted filings to the International Telecommunication Union 339 (ITU) on SpaceX's behalf to arrange spectrum for 30,000 additional 340 Starlink satellites to supplement the 12,000 Starlink satellites 341 already approved by the FCC. As of the date of April 2022, SpaceX 342 has launched about 2,100 Starlink satellites, which is about 5% of 343 the ultimate constellation plan consisting of 42,000 satellites. 344 Foreseeably, it may take many years to complete the entire 345 constellation deployment. Even the first phase of Starlink which 346 consists of about 4400 satellites is not expected to be completed 347 until 2024. 349 4. Problem Statement: We Need the Right Evaluation Methodology 351 The unique characteristics of LEO mega-constellations involve new 352 challenges on various layers of the networking stack of ISTNs. On 353 one hand, it is foreseen that in the near future, there will be a 354 surge of new network functionalities and protocols designed or 355 optimized for ISTNs. On the other hand, because the cost/timeline of 356 manufacturing, launching, operating, and updating satellite 357 constellations is typically much higher/longer than that in 358 traditional terrestrial networks, it is expected that those new 359 network functionalities and protocols tailored for ISTNs should be 360 well evaluated before they are launched and deployed in realistic 361 satellite constellations. 363 Existing methodologies for testing, assessing, and understanding a 364 network functionality or protocol can typically be classified into 365 three categories: (1) live networks; (2) network simulators; and (3) 366 network emulators. The subsections discuss these three categories of 367 network evaluation methodologies, along with their using deficiencies 368 and possible remedies respectively. 370 4.1. Live networks and platforms 372 Representative platforms such as Emulab [Emulab] and Sparta [Sparta] 373 are successful pioneers that build a large-scale experimental network 374 environment. These test environments are originally designed to 375 provide special and exclusive test services for affiliated 376 universities, scientific research institutions or Internet business 377 companies. And for the resource competition, each independent 378 experiment needs to completely monopolize a part of the test bed, so 379 the researcher cannot deploy the experiment until being allocated 380 with enough nodes. PlanetLab [PlanetLab] is truly global ground 381 testbed prototype. Started from 2003, it consists of 1353 nodes at 382 717 sites spanning 48 countries. Together the nodes form a global 383 network system to support new design of network services. 385 The live platforms described above were initially proposed for 386 terrestrial networks and they are developed and repaired at the same 387 time. The key limitation of them in an ISTN environment is that they 388 are designed for terrestrial network experiments, and do not 389 incorporate the realistic characteristic of LEO mega-constellations 390 to support experiments and evaluations in ISTNs. 392 We may search for help from live satellites, but still there is only 393 limited help. It seems that with the help of live ISTN, researchers 394 are capable to assess, verify and evaluate their ideas and thoughts. 395 Live ISTN can give a real constellation-consistency and stack- 396 consistency testing environment. However, current satellites only 397 provide users a bent-pipe service, which is purely relaying the 398 transmission messages, such as the current deployment of Starlink 399 [Starlink]. The construction is far from a comprehensive ISTN, so 400 the research scope is limited. Even if there is a live ISTN, it 401 lacks flexibility, owning to the inconvenient control over 402 satellites. Besides, the access to satellites is also limited. 404 Therefore, live networks or platforms for terrestrial networks can 405 give us a large-scale experimental environment but they lack the 406 support for ISTN characteristics. On the other hand, live ISTN is 407 able to guarantee a real space environment, but it is not that 408 affordable and flexible. 410 4.2. Network Simulators 412 Simulators are tools that enable researchers to reproduce their 413 testing experiments by simulating a real-world process or system over 414 time. Simulators work by using discrete event simulation to 415 calculate the interactive states among all the network entities, 416 ranging from switches, routers, nodes, access points, links and so 417 on. While working fast and efficiently, the fidelity is only brought 418 by the state variable changes at discrete points. 420 Such tools like Systems Tool Kit (STK) [Systems-Tool-Kit] and General 421 Mission Analysis Tool (GMAT) [General-Mission-Analysis-Tool] are good 422 for orbit analysis. STK is a powerful tool to help researchers to 423 model the behavior of mission entities in aerospace, 424 telecommunications and so forth. It also provides visualization and 425 analysis functions. GMAT is a similar tool for space trajectory 426 optimization and mission modeling. Nevertheless, these tools do not 427 support networking simulations such as topology and protocol 428 simulations. ns-3 [ns-3] goes a step further with support for 429 Internet simulation, but on the contrary, it was not designed for 430 ISTN and lacks the support for high-dynamics of ISTN. StarPerf 431 [StarPerf] is a simulator that helps researchers to study network 432 performance under a range of constellation conditions. But still, it 433 lacks the ability to support interactive network traffic simulation 434 and system codes in the systems. 436 Overall, while flexible and low-cost, the realism of simulators is 437 not content enough, because they are difficult to describe the low- 438 level characteristics. In other words, simulators are being too 439 object-oriented to involve additional overhead in the actual 440 execution of programs. Besides, when accessing the network 441 performance, a number of recent emerging algorithms for congestion 442 control, reliable transmission or even protocols are not supported, 443 for example ns-3 [ns-3] only supports basic congestion control like 444 Reno [RFC6582] and so forth, so the need to work with some new 445 algorithms cannot be satisfied and the research to discover new 446 mechanisms, such as new routing algorithms and re-transmission 447 schemes, is extensively prohibited. Another problem of simulators, 448 such as ns-3 [ns-3], is that it difficult to trace or understand the 449 previous codes, without appropriate documentations. Simulators 450 usually face the additional compatibility problem, which means they 451 are not portable with other systems, or they do not support kernel 452 codes. Since there are multiple simulators developed by different 453 group of users, sometimes users are required to be familiar with the 454 writing language, scripting style and modelling technique. 456 4.3. Network Emulators 458 Emulators are another kind of paradigm for network evaluation over a 459 virtual network. The difference between a simulator and an emulator 460 is that emulators leverage VM or containers to keep the realism which 461 is close to actual performances. Therefore, in emulators, virtual 462 nodes. virtual network links, virtual models of traffic, and 463 protocols are all applied. Emulators are capable to run real kernel 464 and application code. Thus, emulators not only support diverse 465 topology design, but also protocol emulation in a synthetic network 466 environment. They emulate the network behavior in a more real way. 467 Mininet [Mininet] is commonly regarded as the most illustrious 468 emulator for networking with its strong ability to support 469 experiments with Software-Defined Networking (SDN) 470 [Software-defined-networking] systems. EstiNet [EstiNet] is another 471 emulator that supports evaluating and testing the performances of 472 software-defined networks. Based on containers, they can emulate 473 real TCP/IP protocol stack in the Linux kernel. However, existing 474 emulation tools lack the ability to construct the dynamic links and 475 orbits in ISTN like simulators. Thus, more problems could happen in 476 higher-level protocols such as routing protocols (e.g. OSPF and 477 BGP). Besides, since emulators run containers or virtual machines 478 which occupy more software overhead, as compared with simulators, it 479 will be hard to emulate the large-scale mega-constellations. 481 To conclude, emulators are relatively good methodologies for network 482 experiments, but emulators still have limitations when using them for 483 ISTN research. While keeping a moderate realism by using VM or 484 containers for entity emulation and flexibility, emulators still lack 485 the supports for ISTN characteristics, such as frequent link changes, 486 satellite network topology uncertainty, and so on. More 487 specifically, current emulators only support fixed network topology 488 emulation. It is not flexible to emulate the time-varying link 489 packet loss, bandwidth, and other traits. A possible way is to 490 frequently replace the link with a new one from time to time 491 sequentially for the entire ISTN. However, it is far from the real 492 situation. Besides, VM or containers are able to deploy a range of 493 network nodes in a physical server, but the actual CPU, memory and 494 other resources should not be shared in reality for each satellite. 495 In addition, it is still difficult to emulate thousands or ten 496 thousand of satellites for ISTN even with VM or containers, subject 497 to hardware limitations. For flexibility, some emulators do not 498 support a good network animator tool. Especially in ISTN emulation, 499 GUI is important for users to observe and analyze orbit trajectories 500 and real time satellite positions. 502 4.4. Summary 504 In this section, we explain the necessity of an evaluation 505 methodology specifically for ISTNs. Then we demonstrate the problems 506 with existing methodologies related to ISTNs. The performance 507 comparison result is shown in Table 3. Above all, ISTNs should be 508 designed first and then launched. Live satellites enable good 509 realism but they lack flexibility and require very high cost as well 510 as a very long deployment period. Other testing tools such as 511 simulators and emulators are either functional for merely aerospace 512 analysis or simply terrestrial networks. None of the existing 513 methodologies guarantees a practical and user-friendly methodology 514 while keeping the evaluation environment realism with low costs. 516 +================+=========+=============+======+=================+ 517 | Platform/Tool | Realism | Flexibility | Cost | Cross-domain | 518 | | | | | Dataset Support | 519 +================+=========+=============+======+=================+ 520 | Live satellite | Y | N | High | Y | 521 | network | | | | | 522 +----------------+---------+-------------+------+-----------------+ 523 | ns-3 [ns-3] | N | Y | Low | N | 524 +----------------+---------+-------------+------+-----------------+ 525 | Hypatia | N | Y | Low | N | 526 | [Hypatia] | | | | | 527 +----------------+---------+-------------+------+-----------------+ 528 | StarPerf | N | Y | Low | N | 529 | [StarPerf] | | | | | 530 +----------------+---------+-------------+------+-----------------+ 531 | Mininet | N | Y | Low | N | 532 | [Mininet] | | | | | 533 +----------------+---------+-------------+------+-----------------+ 535 Table 3: Existing platforms/tools for network analysis and 536 evaluation. (Y for yes/N for no) 538 5. Requirements: New Evaluation Methodology Tailored for ISTNs 540 A proper evaluation methodology tailored for ISTNs is expected to 541 help developers, researchers, engineers to explore various design- 542 space of the networking stack of ISTNs in a technically and 543 economically feasible manner. Based on the comparative analysis 544 results in the prior section, we sum up the following requirements 545 for the new evaluation methodology in ISTNs. 547 5.1. Realism 549 The first requirement is realism. Realism represents the testing 550 authenticity and fidelity. The evaluation methodology is expected to 551 keep the actual characteristics of mega-constellations. In other 552 words, the orbit-level information including the latitude, longitude, 553 and height of each satellite in any given time and the same 554 information for GS and elevation angles of antennas of each GS. Note 555 that the constellation information also determines the visibility, 556 links and even topology of ISTN.s Since the mega-constellations are 557 unstable, how the temporal satellite locations, visibility, link 558 propagation delays and so on should also be considered carefully. In 559 addition, it requires the network nodes to communicate and negotiate 560 their messages following the actual protocol process. For example, 561 when doing a test for OSPF in an ISTN, we would like the nodes to 562 send Hello packets, Link-State-Request (LSR) packets, Link-State- 563 Update (LSU) packets and so on. A real network stack is preferred to 564 provide researchers an opportunity to see the performance of 565 different protocols in ISTNs. 567 5.2. Flexibility 569 Another requirement is flexibility and feasibility. The testing 570 methodology should be technically easy to use and easy to learn. 571 Without extra modifications or process, the methodology should help 572 researchers learn and use it without much effort and can evaluate 573 their ideas as they wish, which means it should support flexible, 574 controllable environments for researchers. 576 5.3. Low-cost and Easy-to-use 578 Meanwhile, the evaluation methodology is expected to be low-cost. A 579 well-acceptable methodology should be economically feasible for users 580 to create an evaluation environment. Researchers do not want to 581 conduct their tests all in live ISTN, which is over-cumbersome and 582 unaffordable, let alone launching their own spacecraft. Even if 583 there are a number of orbiting satellites, whether users can easily 584 gain access to satellites is also a problem. 586 5.4. Cross-domain Dataset Support 588 The evaluation methodology is expected to be driven by realistic 589 datasets from multi-dimensions to support its realism. Multi- 590 dimension refers to multi-disciplinary research on ISTNs. Since a 591 standard ISTN evaluation methodology not only contains high-level 592 benchmarks from topology, routing to transmission, but also considers 593 the low-level traits such as wireless link conditions, weather 594 conditions and Earth rotations. To be more concrete, the former one 595 requires knowledge in networks while the latter one relies more on 596 aerospace. Hence, to build a high-fidelity methodology, we need 597 community efforts both from networks and aerospace. On the other 598 hand, an authentic dataset is an indispensable element for data 599 driven testing methodology. Actual data is the first step to obtain 600 a realistic emulation. with characteristics of a real ISTN. Thus, 601 the dataset is a collection of messages for testing, in which 602 geographical mega-constellation information (orbit number, satellite 603 number, height), orbital information (orbit inclination angle and 604 link strategies), weather information as well as ground station 605 information (positions, antenna angle and so forth) are involved. 607 6. Conclusion 609 To conclude, the emergence of mega-constellations brings us new 610 opportunities for the development of ISTN that extends the Internet 611 to the space era. Combined with terrestrial networks, ISTN is 612 expected to supply pervasive, low-latency and high-speed services to 613 users globally, which greatly enhances the current Internet. At the 614 same time, the unique characteristics (e.g. high-dynamics) of ISTN 615 impose challenges in topology, routing, transportation, application, 616 and security. However, we simply believe addressing the challenges 617 also gives us open opportunities for future research by our 618 community-driven effort. To accelerate the research speed and to 619 help make testing more feasible, new methodologies that satisfy user 620 requirements should be proposed. To this extent, this draft reviews 621 the limitation of existing network analysis tools in ISTNs, 622 considering the unique characteristics of emerging LSNs and the key 623 challenges. This draft further analyzes the limitation of existing 624 evaluation methodologies in ISTN environments. Finally, this draft 625 outlines key requirements of evaluation methodologies tailored for 626 future ISTNs. 628 7. Acknowledgements 630 8. IANA Considerations 632 This memo includes no request to IANA. 634 9. Security Considerations 636 This entire draft discusses security considerations from different 637 perspectives of ISTN in Section 3. 639 10. References 641 10.1. Normative References 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, 645 DOI 10.17487/RFC2119, March 1997, 646 . 648 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 649 DOI 10.17487/RFC2328, April 1998, 650 . 652 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 653 Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, 654 January 2006, . 656 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 657 NewReno Modification to TCP's Fast Recovery Algorithm", 658 RFC 6582, DOI 10.17487/RFC6582, April 2012, 659 . 661 10.2. Informative References 663 [Development-Timeline] 664 "Development-Timeline", . 668 [Emulab] "Emulab", . 670 [EstiNet] "EstiNet", . 673 [General-Mission-Analysis-Tool] 674 "General-Mission-Analysis-Tool", 675 . 678 [Hypatia] "Hypatia", . 681 [Iridium] "Iridium", . 683 [Kuiper-Fcc] 684 "Kuiper-Fcc", . 687 [link-churn-interval] 688 "link-churn-interval", 689 . 692 [Mininet] "Mininet", . 694 [ns-3] "ns-3", . 696 [PlanetLab] 697 "PlanetLab", . 700 [Production-Cycles] 701 "Production-Cycles", 702 . 706 [RAD5545] "RAD5545", . 709 [RAD750] "RAD750", . 712 [raspberry-pi] 713 "raspberry-pi", . 716 [Software-defined-networking] 717 "Software-defined-networking", 718 . 721 [Sparta] "Sparta", . 725 [Starlink] "Starlink", . 727 [Starlink-Fcc] 728 "Starlink-Fcc", 729 . 731 [StarPerf] "StarPerf", . 735 [Systems-Tool-Kit] 736 "Systems-Tool-Kit", . 738 [Telesat-Fcc] 739 "Telesat-Fcc", . 742 Authors' Addresses 744 Zeqi Lai 745 Tsinghua University 746 30 ShuangQing Ave 747 Beijing 748 100089 749 China 750 Email: zeqilai@tsinghua.edu.cn 752 Hewu Li 753 Tsinghua University 754 30 ShuangQing Ave 755 Beijing 756 100084 757 China 758 Email: lihewu@cernet.edu.cn 760 Yangtao Deng 761 Tsinghua University 762 30 ShuangQing Ave 763 Beijing 764 100084 765 China 766 Email: dengyt21@mails.tsinghua.edu.cn 768 Qian Wu 769 Tsinghua University 770 30 ShuangQing Ave 771 Beijing 772 100084 773 China 774 Email: wuqian@cernet.edu.cn 776 Jun Liu 777 Tsinghua University 778 30 ShuangQing Ave 779 Beijing 780 100084 781 China 782 Email: juneliu@mail.tsinghua.edu.cn