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