OpenSN: An Open Source Library for Emulating LEO Satellite Networks¶
(1) Background & Motivation
背景:
低地球轨道 (LEO) 卫星星座 (如 Starlink) 发展迅速, 不仅作为中继, 还开始配备星间链路 (ISLs) 形成空间网络
问题:
- 在真实卫星网络中进行大规模实验成本高且周期长
- 现有的仿真/模拟工具存在局限性:
- 离散事件模拟器 (如 ns3): 速度慢, 且无法运行真实的协议栈
- 基于 Mininet 的仿真器 (如 LeoEM): 采用轻量级虚拟化, 难以运行分布式路由软件, 且扩展性受限
- 基于容器的仿真器 (如 StarryNet): 虽然支持真实软件, 但由于直接与 Docker CLI 交互, 导致在大规模星座下的仿真效率低下
(2) Core Introduction
- 定义: OpenSN 是一个用于仿真大规模 LEO 卫星网络的开源库
- 技术路线: 采用基于容器的虚拟化技术, 支持运行真实的内核和未修改的应用程序 (如分布式路由软件)
- 主要优势: 相比现有的仿真器, OpenSN 在仿真效率, 系统可扩展性 (Scalability) 和功能可扩展性 (Extensibility) 方面表现更优
(3) System Architecture
OpenSN 采用了分离式架构, 主要包含三个组件:
-
用户定义配置器 (User-defined Configurator):
- 允许用户定义仿真参数 (星座, 拓扑) 和规则 (链路故障, 切换策略)
-
键值数据库 (Key-Value Database):
- 作为中间件, 存储仿真信息, 实现用户配置与底层容器管理的解耦, 增强了扩展性
-
容器网络管理器 (Container Network Manager):
- Container Runtime Manager: 负责容器的创建与资源管理
- Virtual Link Manager: 直接管理 Linux 虚拟设备, 构建 ISL 和 GSL 链路
- Message Forwarder: 在数据库与仿真环境间传递信息
(4) Key Improvements
-
提升仿真效率 (Efficiency Improvement):
- 摒弃 Docker Network Manager: OpenSN 发现 Docker 的网络管理器在处理频繁链路变动时会阻塞任务队列且开销大
- 直接链路管理: Virtual Link Manager 直接控制 Linux 虚拟网络设备 (veth-pair, bridge), 将创建链路的操作流程从多步简化为一步
- 优化 Docker 交互: Container Runtime Manager 使用官方 SDK 替代 CLI 命令行交互, 减少了进程开销
-
多机扩展能力
- 控制平面: 利用 etcd 实现多机之间的数据同步和状态监控, 保证低成本, 高灵活性的数据交换
- 数据平面: 利用 VXLAN 技术实现跨物理机的容器互联, 适应卫星网络点对点的链路结构
-
Extensibility
- 通过键值数据库将 "用户配置" 与 "底层实现" 分离, 用户可以动态修改仿真参数 (如切换策略, 故障模型) 而无需关心底层网络细节
(5) Performance Evaluation
作者将 OpenSN 与 StarryNet (base: Docker) 和 LeoEM (base: Mininet) 进行了对比实验:
- 网络构建速度: OpenSN 比 StarryNet 快 5到10倍
- 链路状态更新: OpenSN 比 Mininet 快 2到4倍
- 资源消耗: 在网络稳定运行阶段, OpenSN 的 CPU 占用率显著低于 StarryNet (因为 StarryNet 使用 ping 命令作为守护进程导致频繁软中断)
Introduction¶
1.1 Background & Motivation¶
In recent years, we have witnessed the rapid development of lowearth-orbit (LEO) constellations. Different from the geostationary satellites orbiting at the altitude 35768 km, the orbital altitude of LEO satellites is around 300-2000 km. The lower orbital altitude leads to a smaller latency for the ground-satellite links (GSLs), but also reduces the coverage area of a single satellite. Consequently, it is indispensable to deploy hundreds or thousands of LEO satellites to achieve global coverage. Many commercial enterprises have launched their mega-constellation plans. For example, Starlink Shell I consists of a total of 1584 satellites on 72 orbital planes. At the early stages, LEO satellites are only used as repeaters between two ground stations (GSes), which is also known as the bent-pipe architecture. Recently, many LEO constellations have been equipped with (or are deploying) inter-satellite links (ISLs). For example, Iridium Next has been using ISLs in L-band [13]. Starlink has launched satellites with laser-based ISLs way back in 2021 [30]. The adoption of ISLs creates the satellite network (SN) in space.
Although SN provides opportunities for extending Internet services to where the terrestrial networks cannot reach, it also leads to new challenges on satellite networking. Due to the mobility nature and the time-varying communication links, the topology characteristics of LEO satellite networks are quite different from those of terrestrial Internet. There have been increasing studies on LEO satellite networking, focusing on the low-latency advantages (e.g., [1, 11, 12]), topology design (e.g., [2, 20, 36]), intradomain routing (e.g., [18, 21, 29, 34, 35]), and inter-domain routing (e.g., [7, 10, 15]).
Despite the wide investigation, how to evaluate these new architectures, protocols, and algorithms in a systematic and reproducible manner has been an open problem. Different from terrestrial Internet, it is costly to carry out experiments in a real-world SN. Even for those giants like SpaceX and Amazon, it also takes a few years to deploy their LEO constellations. Therefore, most existing studies on SN still rely on simulation or emulation. The evaluation platforms for SN could be classified into three categories:
**(1) Orbit Analysis: ** The initial step of simulating SN is to obtain the trajectory data of LEO satellites. STK [32] is an orbit analysis tool, but does not support network simulation.
**(2) Discrete-Event Simulation: ** The discrete-event simulators of SN will construct the constellation topology based on the trajectory data obtained from STK, and then simulate the networking events at different levels. Flow-level SN simulators (e.g., StarPerf [17]) cannot capture the fine-grained packet forwarding behaviors. Packet-level SN simulators (e.g., [5, 14, 33]) usually rely on a third-party discrete-event simulation platforms (e.g., ns3 [25] and OMNeT++ [26]).
**(3) Virtual-Network Emulation: ** The virtual-network emulators of SN could run real protocol stack in Linux kernel and support unmodified applications on host OS. Existing virtual-network SN emulators either rely on Mininet [23] or Docker container [6]. For example, LeoEM [4] is developed upon Mininet. StarryNet [16] and the emulator in [27] adopt the container-based virtualization.
Among these solutions, virtual-network emulation provides the most realistic and meaningful results. However, existing virtualnetwork SN emulators either are not efficient enough to emulate mega-constellations or have limitation on system scalability and function extensibility. To address these drawbacks, this paper present OpenSN, i.e., an open source library for emulating largescale satellite networks. We believe that OpenSN could empower the research on LEO satellite networking in the future. OpenSN will be available at https://opensn-library.github.io.
近年来, 我们见证了低地球轨道 (LEO) 星座的迅猛发展. 不同于轨道高度为 35,768 公里的地球静止轨道卫星, LEO 卫星的轨道高度通常在 300 至 2,000 公里之间. 较低的轨道高度虽然降低了星地链路 (GSL) 的传输时延, 但也缩小了单颗卫星的覆盖范围. 因此, 为实现全球覆盖, 部署数百甚至数千颗 LEO 卫星已成必然. 许多商业企业已启动其巨型星座 (Mega-constellation) 计划. 例如, Starlink Shell I 包含分布在 72 个轨道面上的共计 1,584 颗卫星. 在早期阶段, LEO 卫星仅作为两个地面站 (GS) 之间的中继器, 这也被称为弯管 (Bent-pipe) 架构. 近年来, 许多 LEO 星座已配备 (或正在部署) 星间链路 (ISL). 例如, Iridium Next 采用了 L 波段的星间链路 [13]; Starlink 早在 2021 年便发射了搭载激光星间链路的卫星 [30]. 星间链路的应用促成了空间卫星网络 (SN) 的构建.
尽管卫星网络为将互联网服务扩展至地面网络无法覆盖的区域提供了契机, 但也给卫星组网技术带来了新的挑战. 由于节点的高动态性及通信链路的时变特性, LEO 卫星网络的拓扑特征与地面互联网存在显著差异. 目前关于 LEO 卫星组网的研究日益增多, 主要集中在低时延优势 (如 [1, 11, 12]), 拓扑设计 (如 [2, 20, 36]), 域内路由 (如 [18, 21, 29, 34, 35]) 以及域间路由 (如 [7, 10, 15]) 等方面.
尽管相关研究广泛, 但如何以系统化且可复现的方式评估 这些新型架构, 协议及算法, 仍是一个亟待解决的问题. 与地面互联网不同, 在真实卫星网络中进行实验成本高昂. 即便是 SpaceX 和 Amazon 这样的巨头企业, 其 LEO 星座的部署也需耗时数年.
因此, 大多数现有的卫星网络研究仍依赖于模拟 (Simulation) 或仿真 (Emulation). 卫星网络的评估平台主要可归为以下三类:
(1) 轨道分析 (Orbit Analysis): 模拟卫星网络的第一步是获取 LEO 卫星的轨迹数据. STK [32] 是一款轨道分析工具, 但其不支持网络模拟.
(2) 离散事件模拟 (Discrete-Event Simulation): 卫星网络的离散事件模拟器依据从 STK 获取的轨迹数据构建星座拓扑, 进而模拟不同层级的网络事件.
- 流级 (Flow-level) 卫星网络模拟器 (如 StarPerf [17]) 无法捕捉细粒度的数据包转发行为
- 包级 (Packet-level) 模拟器 (如 [5, 14, 33]) 通常依赖于第三方离散事件模拟平台 (如 ns-3 [25] 和 OMNeT++ [26])
(3) 虚拟网络仿真 (Virtual-Network Emulation): 卫星网络的虚拟网络仿真器能够运行真实的 Linux 内核协议栈, 并支持宿主操作系统上未经修改的应用程序.
现有的虚拟网络仿真器主要基于 Mininet [23] 或 Docker 容器 [6] 构建. 例如, LeoEM [4] 是基于 Mininet 开发的;
而 StarryNet [16] 及文献 [27] 中的仿真器则采用了基于容器的虚拟化技术.
在上述方案中, 虚拟网络仿真能够提供最接近真实且最具参考价值的结果. 然而, 现有的虚拟网络仿真器要么效率不足以支撑巨型星座的仿真, 要么在系统可扩展性和功能可扩展性方面存在局限. 为了解决这些弊端, 本文提出了 OpenSN, 即一个用于仿真大规模卫星网络的开源库. 我们相信 OpenSN 将有力推动未来 LEO 卫星组网技术的研究. OpenSN 的源代码可通过 https://opensn-library.github.io 获取.
1.2 Main Results and Key Contributions¶
This paper presents OpenSN, i.e., an open-source library for emulating LEO satellite networks. OpenSN is a virtual-network emulator, running real kernel and unmodified applications. Compared to other SN emulators, OpenSN achieves a better emulation efficiency, system scalability, and function extensibility. Next we introduce the key contributions, and leave the detailed comparison in Table 2.
**Container-based Emulation: ** OpenSN adopts container-based virtualization for emulating SN with two considerations. First, the container-based emulation achieves a good horizontal scalability via flexible multi-machine extension. Second, it allows for running distributed software (i.e., routing software, observation applications) in large-scale constellation without manual configuration. The two aspects above enable OpenSN to outperform LeoEM (adopting lightweight virtualization via Mininet) in terms of horizontal scalability and function extensibility, respectively.
**Separation Architecture: ** OpenSN mainly consists of Userdefined Configurator, Container Network Manager, and Key-Value Database. The key-value database records the necessary information for SN emulation, which acts as a data forwarder between User-defined Configurator and Container Network Manager. Compared to other container-based SN emulators (e.g., StarryNet), such a separation architecture enhances the function extensibility of OpenSN. For example, OpenSN allows users to dynamically change the emulation parameters and customize the emulation rules (e.g., GSL handover policy and ISL failure model).
**Efficiency Improvement: ** By investigating and comparing existing container-based SN emulators, we find that the emulation efficiency of the container network is mainly limited to the interaction with the Docker command line interface (CLI). To this end, OpenSN streamlines the interaction process with Docker. First, OpenSN's Container Runtime Manager replaces the CLI interaction with official SDK, and also adopts a distributed architecture to achieve better parallelism. Second, OpenSN's Virtual Link Manager skips Docker Network Manager, and directly controls Linux virtual devices, reducing the overhead of unnecessary operation. This way, OpenSN is capable of achieving almost the same emulation efficiency as the specialized network emulator Mininet.
The rest of this paper is as follows. We review existing SN emulators in Section 2. We then introduce OpenSN architecture in Section 3. We evaluate the performance of OpenSN in Section 4. Finally, we conclude this paper in Section 5.
本文提出了 OpenSN, 一个用于仿真 LEO 卫星网络的开源库. OpenSN 是一款虚拟网络仿真器, 支持运行真实的内核和未经修改的应用程序. 与其他卫星网络仿真器相比, OpenSN 实现了更高的仿真效率, 系统可扩展性和功能可扩展性. 接下来我们将介绍核心贡献, 详细的对比分析见表 2.
基于容器的仿真 (Container-based Emulation): OpenSN 采用基于容器的虚拟化技术来仿真卫星网络, 主要基于两点考虑. 首先, 基于容器的仿真通过灵活的多机扩展实现了良好的水平可扩展性 (Horizontal Scalability). 其次, 它允许在大规模星座中运行分布式软件 (如路由软件, 监测应用), 且无需手动配置. 上述两方面使得 OpenSN 在水平可扩展性和功能可扩展性方面分别优于 LeoEM (采用基于 Mininet 的轻量级虚拟化).
分离式架构 (Separation Architecture): OpenSN 主要由用户定义配置器 (User-defined Configurator), 容器网络管理器 (Container Network Manager) 和键值数据库 (Key-Value Database) 组成. 键值数据库记录了卫星网络仿真所需的信息, 充当配置器与管理器之间的数据转发器. 与其他基于容器的仿真器 (如 StarryNet) 相比, 这种分离式架构增强了 OpenSN 的功能可扩展性. 例如, OpenSN 允许用户动态更改仿真参数并自定义仿真规则 (如 GSL 切换策略和 ISL 故障模型).
效率提升 (Efficiency Improvement): 通过调研和比较现有的基于容器的卫星网络仿真器, 我们发现容器网络的仿真效率主要受限于与 Docker 命令行接口 (CLI) 的交互. 为此, OpenSN 精简了与 Docker 的交互流程. 首先, OpenSN 的容器运行时管理器 (Container Runtime Manager) 使用官方 SDK 替代了 CLI 交互, 并采用分布式架构以实现更好的并行性. 其次, OpenSN 的虚拟链路管理器 (Virtual Link Manager) 绕过了 Docker 网络管理器, 直接控制 Linux 虚拟设备, 减少了不必要操作的开销. 通过这种方式, OpenSN 能够实现与专用网络仿真器 Mininet 几乎相当的仿真效率.
本文其余部分安排如下: 第 2 节回顾现有的卫星网络仿真器; 第 3 节介绍 OpenSN 的架构; 第 4 节评估 OpenSN 的性能; 最后, 第 5 节总结全文.
Literature Review¶
Table 1 compares SN simulation/emulation platforms.
2.1 Discrete-Event Simulation for SN¶
The discrete-event simulation for SN captures the networking events at different levels:
Flow-level: The flow-level SN simulators could calculate some performance metrics given the constellation topology, but are not able to capture the fine-grained behaviours of each packet. Lai et al. in [17] present StarPerf, and evaluate the end-to-end latency under different LEO constellations.
Packet-Level: Existing packet-level SN simulators rely on the third-party discrete-event simulation platforms, e.g., ns3 [25] and OMNeT++ [26]. Kassing et al. in [14] propose Hypatia, i.e., a packetlevel SN simulator based on ns3. The authors use Hypatia to investigate the impact of latency and link utilization on congestion control and routing. Cheng et al. in [5] present a packet-level simulator for space-air-ground integrated network based on ns3, which supports various mobility traces of space and aerial networks. Both the two SN simulators above focus on the classic TCP/IP architecture in ns3. Yan et al. in [33] develop NDN architecture on OMNet++, and conduct a comparative study of host-centric and information-centric routing for SN.
The aforementioned packet-level SN simulators have two drawbacks. First, it takes long time to complete a simulation due to the complexity of scheduling discrete events. Second, they are not able to run real protocol stacks. Hence some studies explore the virtual-network emulation for SN.
卫星网络 (SN) 的离散事件模拟旨在捕获不同层级的网络事件:
流级 (Flow-level): 流级卫星网络模拟器能够在给定星座拓扑的情况下计算部分性能指标, 但无法捕捉单个数据包的细粒度行为.
Lai 等人 [17] 提出了 StarPerf, 并评估了不同 LEO 星座下的端到端时延.
包级 (Packet-Level): 现有的包级卫星网络模拟器依赖于第三方离散事件模拟平台, 例如 ns-3 [25] 和 OMNeT++ [26].
Kassing 等人 [14] 提出了 Hypatia, 即一种基于 ns-3 的包级卫星网络模拟器. 作者利用 Hypatia 研究了时延和链路利用率对拥塞控制及路由的影响.
Cheng 等人 [5] 提出了一种基于 ns-3 的空天地一体化网络包级模拟器, 支持空间和空中网络的多种移动轨迹.
上述两种卫星网络模拟器均侧重于 ns-3 中的经典 TCP/IP 架构.
Yan 等人 [33] 在 OMNeT++ 上开发了命名数据网络 (NDN) 架构, 并对比研究了卫星网络中以主机为中心和以信息为中心的路由机制.
上述包级卫星网络模拟器存在两点不足:
- 由于离散事件调度的复杂性, 完成一次模拟耗时较长
- 它们无法运行真实的协议栈
因此, 部分研究开始探索卫星网络的虚拟网络仿真技术
2.2 Virtual-Network Emulation for SN¶
The virtual-network emulators for SN either rely on Mininet (adopting lightweight virtualization) or adopt the container-based virtualization, thus enable us to run real applications over SN with real-time response.
Mininet-based: Mininet [23] enables users to create a realistic virtual network, running real kernel and applications code, but does not provide specific support for SN emulation. Furthermore, Mininet adopts lightweight virtualization (i.e., process-based), thus is not suitable to emulate large-scale SN running distributed software (e.g., routing software). Cao et al. in [4] develop LeoEM (available at [19]), which emulates SN via Mininet. Moreover, LeoEM adopts StarPerf's solution for constellation construction and dynamic route calculation. The authors leverage LeoEM to evaluate their proposed congestion control mechanisms.
Container-based: Mukerjee et al. in [24] present the design of Etalon (available at [8]), i.e., an open source reconfigurable datacenter network emulator developed upon Docker container. The authors establish a testbed on four servers to emulate a datacenter network, but Etalon does not support for SN emulation. Lai et al. in [16] develop StarryNet, i.e., a container-based emulator for SN. It is also implemented upon Docker, and emulates the distributed routing process by loading BIRD [3] on each node. Moreover, StarryNet incorporates some real orbital data, and is partially available at [31]. Pan et al. in [27] introduce a similar container-based SN emulator, using another routing software Quagga [28].
OpenSN is also a container-based emulator for SN, which exhibits advantages in emulation efficiency, system scalability, and function extensibility. We summarize the comparison in Table 2, and introduce the detailed design in Section 3.
卫星网络的虚拟网络仿真器要么依赖于 Mininet (采用轻量级虚拟化), 要么采用基于容器的虚拟化技术, 从而使我们能够以实时响应的方式在卫星网络上运行真实应用程序.
基于 Mininet (Mininet-based):
Mininet [23] 允许用户创建逼真的虚拟网络, 运行真实的内核和应用程序代码, 但未提供针对卫星网络仿真的特定支持.
此外, Mininet 采用轻量级虚拟化 (即基于进程), 因此不适合仿真运行分布式软件 (如路由软件) 的大规模卫星网络.
Cao 等人 [4] 开发了 LeoEM (可从 [19] 获取), 通过 Mininet 对卫星网络进行仿真.
此外, LeoEM 采用了 StarPerf 的星座构建和动态路由计算方案. 作者利用 LeoEM 评估了其提出的拥塞控制机制.
基于容器 (Container-based):
Mukerjee 等人 [24] 提出了 Etalon (可从 [8] 获取) 的设计, 即一种基于 Docker 容器开发的开源可重构数据中心网络仿真器. 作者在四台服务器上建立了一个测试床来仿真数据中心网络, 但 Etalon 不支持卫星网络仿真.
Lai 等人 [16] 开发了 StarryNet, 即一种基于容器的卫星网络仿真器. 它同样基于 Docker 实现, 并通过在每个节点上加载 BIRD [3] 来仿真分布式路由过程.
此外, StarryNet 结合了部分真实的轨道数据, 其部分代码可从 [31] 获取.
Pan 等人 [27] 介绍了一种类似的基于容器的卫星网络仿真器, 使用了另一种路由软件 Quagga [28].
OpenSN 同样是一种基于容器的卫星网络仿真器, 它在仿真效率, 系统可扩展性和功能可扩展性方面表现出显著优势. 我们在表 2 中总结了对比情况, 并在第 3 节中介绍了详细设计.
OpenSN Framework¶
This section presents the design of OpenSN. Specifically, we provide an overview in Section 3.1. We then introduce our improvements on emulation efficiency, system scalability, and function extensibility in Sections 3.2-3.4, respectively.
3.1 Overview and Architecture¶
OpenSN is a virtual-network emulator for LEO satellite networks, which leverages containers and virtual links to emulate SN. Figure 1 shows the architecture of OpenSN, including three key components: User-defined Configurator, Container Network Manager, and Keyvalue Database.
(1) User-defined Configurator allows user to specify the emulation parameters (e.g., constellation, connectivity, nodes, etc) and the emulation rules (e.g., ISL failure model, GSL handover policy, trajectory udpate, etc) in OpenSN. To enhance extensibility, the corresponding configuration data will not be directly pass to Container Network Manager, but is recorded in Key-value Database.
(2) Key-value Database records the necessary information of SN emulation. Some are user-specified emulation parameters and rules from User-defined Configurator. Some are the status data of SN emulation obtained from Container Network Manager in each emulation environment.
(3) Container Network Manager controls the major functionality of SN emulation, which is conducted on multiple machines connected by VXLAN. According to the information from Keyvalue Database, Container Runtime Manager is responsible for container creation/destruction and single-node resource management. Virtual Link Manager will construct the virtual links for each ISL and GSL in SN. Moreover, Message Forwarder is used to transfer necessary information (e.g., real-time topology, IP address of each interface, and user's command) between Key-value Database and Multi-Machine Emulation Environment.
OpenSN 是一款面向 LEO 卫星网络的虚拟网络仿真器, 它利用容器技术和虚拟链路来实现对卫星网络的仿真.
图 1 展示了 OpenSN 的架构, 主要包含三个核心组件: 用户定义配置器 (User-defined Configurator), 容器网络管理器 (Container Network Manager)和键值数据库 (Key-value Database)
(1) 用户定义配置器: 允许用户指定 OpenSN 中的仿真参数 (如星座, 连接性, 节点等)和仿真规则 (如 ISL 故障模型, GSL 切换策略, 轨迹更新等). 为增强可扩展性, 相应的配置数据不会直接传递给容器网络管理器, 而是记录在键值数据库中.
(2) 键值数据库: 记录卫星网络仿真所需的信息. 其中一部分是来自用户定义配置器的用户指定仿真参数和规则, 另一部分是从各仿真环境中的容器网络管理器获取的卫星网络仿真状态数据.
(3) 容器网络管理器: 控制卫星网络仿真的主要功能, 运行在通过 VXLAN 连接的多台机器上.
根据键值数据库中的信息, 容器运行时管理器 (Container Runtime Manager) 负责容器的创建/销毁和单节点资源管理;
虚拟链路管理器 (Virtual Link Manager) 负责构建卫星网络中的各条 ISL 和 GSL.
此外, 消息转发器 (Message Forwarder) 用于在键值数据库与多机仿真环境之间传输必要信息 (如实时拓扑, 各接口 IP 地址及用户指令).
3.2 Efficient Network Emulation¶
One of the major challenges and performance bottlenecks of emulating SN lies in the network emulation. On the one hand, the number of involved nodes, ISLs and GSLs is huge for LEO megaconstellations. On the other hand, the link state changes (e.g., ISL failure/recover and GSL handover) are quite frequent due to the mobility nature of LEO satellites. The two aspects above require an efficient network manager. Existing container-based SN emulators (e.g., StarryNet) rely on Docker Network Manager, and have two drawbacks. First, Docker network controller is not developed for emulating large-scale networks with frequently changing states. The concurrent network state changes may block the task queue, thus reduce the response speed of network emulation. Second, Docker network manager exhibits some unnecessary processes in container and link management (e.g., repeatedly interacting with data store). This will become a significant overhead when the constellation scales up. Based on the above observations, OpenSN's Container Network Manager tends to improve the emulation efficiency via Virtual Link Manager and Container Runtime Manager.
Virtual Link Manager of OpenSN is developed to directly manage the Linux virtual network devices and the network namespace. This manager has the highest priority. It will immediately create a coroutine to implement rapid response once the command of link-state change is detected. Furthermore, OpenSN's Virtual Link Manager streamlines the progress of creating a virtual link. Figure 2 shows the event sequence of creating a virtual link under Docker Network Manager and OpenSN's Virtual Link Manager. Note that our solution could establish a virtual link within a single call. However, Docker Network Manager establishes a virtual link via three actions, thus increases the operation overhead.
Container Runtime Manager of OpenSN leverages the official Docker SDK to connect with Docker daemon, instead of relying on Docker Command Line Interface (CLI) like StarryNet. This enables OpenSN to skip many unnecessary processes (e.g., starting sh and Docker-client) when creating containers or executing command inside containers, thus significantly reduces the operation overhead. Furthermore, the Container Runtime Managers of OpenSN are implemented on each machine in a distributed manner. Consequently, the efficiency of container management will be improved under a parallel architecture.
卫星网络仿真的主要挑战和性能瓶颈之一在于网络仿真本身. 一方面, LEO 巨型星座涉及的节点, ISL 和 GSL 数量巨大; 另一方面, 由于 LEO 卫星的移动特性, 链路状态变化 (如 ISL 故障/恢复和 GSL 切换)非常频繁.
上述两方面要求网络管理器必须具备高效率. 现有的基于容器的卫星网络仿真器 (如 StarryNet)依赖于 Docker 网络管理器, 存在两个缺陷.
首先, Docker 网络控制器并非为仿真状态频繁变化的大规模网络而设计. 并发的网络状态变更可能会阻塞任务队列, 从而降低网络仿真的响应速度.
其次, Docker 网络管理器在容器和链路管理中存在一些不必要的流程 (例如重复与数据存储交互), 当星座规模扩大时, 这将成为显著的开销. 基于以上观察, OpenSN 的容器网络管理器致力于通过虚拟链路管理器和容器运行时管理器来提升仿真效率.
OpenSN 的 虚拟链路管理器 旨在直接管理 Linux 虚拟网络设备和网络命名空间. 该管理器拥有最高优先级, 一旦检测到链路状态变更指令, 将立即创建一个协程以实现快速响应. 此外, OpenSN 的虚拟链路管理器精简了创建虚拟链路的流程.
图 2 展示了在 Docker 网络管理器和 OpenSN 虚拟链路管理器下创建虚拟链路的事件序列:
值得注意的是, 我们的方案可以通过单次调用建立一条虚拟链路, 而 Docker 网络管理器需通过三个动作来建立, 从而增加了操作开销
OpenSN 的 容器运行时管理器 利用官方 Docker SDK 与 Docker 守护进程 (daemon)连接, 而不是像 StarryNet 那样依赖 Docker 命令行接口 (CLI).
这使得 OpenSN 在创建容器或在容器内执行命令时能够跳过许多不必要的进程 (如启动 sh 和 Docker-client), 从而显著降低操作开销.
此外, OpenSN 的容器运行时管理器以分布式方式在每台机器上实现, 因此在并行架构下, 容器管理的效率将得到提升.
3.3 Multi-Machine Extension¶
The virtual-network emulation for LEO mega-constellation requires a lot of computing resources. Although OpenSN has made significant improvements for network emulation in Section 3.2, the single-machine deployment pattern still cannot afford to emulate satellites that run resource-consuming applications. Hence OpenSN provides the capability of multi-machine extension. Next we introduce how the control plane and data plane work.
Control Plane: To achieve multi-machine extension, each machine in the emulation cluster should deploy a Container Network Manager as the control plane. Moreover, these managers need to share their machine data (e.g., ingress address) and monitor the entity data change to create/destroy containers or links. OpenSN leverages etcd [9] to achieve data exchange on the control plane, which is the primary data exchange component of container management tools. Specifically, etcd enables client to watch the status data (e.g., link delay and container status) at a low cost and with high flexibility. It enables OpenSN daemon in multiple machines to respond as soon as a state-updating command is given.
Data Plane: To achieve multi-machine extension, the data plane of OpenSN should be able to emulate the ISLs or GSLs when the corresponding containers are deployed on different emulation machines. OpenSN leverages VXLAN technology [22] to achieve crossmachine data transfer. This is because most links of SN are point-to-point, and VXLAN naturally supports such a network structure and can flexibly connect containers cross machines.
LEO 巨型星座的虚拟网络仿真需要大量的计算资源. 尽管 OpenSN 在 3.2 节中对网络仿真进行了显著改进, 但单机部署模式仍无法支撑运行高资源消耗应用程序的卫星仿真. 因此, OpenSN 提供了多机扩展能力. 接下来我们介绍控制平面和数据平面是如何工作的.
控制平面: 为实现多机扩展, 仿真集群中的每台机器都应部署一个容器网络管理器作为控制平面.
此外, 这些管理器需要共享其机器数据 (如入口地址)并监控实体数据的变化以创建/销毁容器或链路
OpenSN ==利用 etcd [9] 实现控制平面上的数据交换, == 这是容器管理工具的主要数据交换组件
具体而言, etcd 使客户端能够以低成本和高灵活性监听状态数据 (如链路延迟和容器状态), 使多台机器中的 OpenSN 守护进程一旦收到状态更新指令即可立即响应
数据平面: 为实现多机扩展, 当相应容器部署在不同的仿真机器上时, OpenSN 的数据平面应能够仿真 ISL 或 GSL
OpenSN 利用 VXLAN 技术 [22] 实现跨机数据传输. 这是因为大多数卫星网络链路是点对点的, 而 VXLAN 天然支持这种网络结构, 并能灵活地连接跨机器的容器
3.4 Enhanced Extensibility¶
To facilitate systematic performance evaluation of new studies, the emulator of SN should exhibit good extensibility in terms of emulation functions. OpenSN achieves this goal via a separation architecture shown in Figure 1. Specifically, OpenSN separates the user-defined configuration from the container network management via a key-value database. Such a key-value database records the necessary information of SN emulation, and acts as a data forwarder between User-Defined Configurator and Container Network Manager. This way, users can specify and change their emulation configuration without being affected by the implementation details of the container network.
为促进对新研究进行系统性的性能评估, 卫星网络仿真器应在仿真功能方面表现出良好的可扩展性. OpenSN 通过图 1 所示的分离式架构实现了这一目标. 具体而言, OpenSN 通过键值数据库将用户定义配置与容器网络管理分离开来. 该键值数据库记录了卫星网络仿真的必要信息, 充当用户定义配置器与容器网络管理器之间的数据转发器. 通过这种方式, 用户可以指定和更改其仿真配置, 而无需受限于容器网络的底层实现细节.