SPACE RG — IETF 126 (Vienna)
Systems and Protocol Aspects for Circumstellar Environments (proposed Research Group)
Summary
The proposed SPACE Research Group met at IETF 126 to discuss long-term research challenges and architectures for space-based and non-terrestrial networks (NTNs).
The agenda comprised four invited talks and two group-work updates.
Topics covered the exponential growth of planned LEO constellations and its governance implications, real-world uplink constraints and neighbour contention on operational LEO networks, the communication and computing requirements of industrial NTN use cases, and routing-protocol scalability in highly dynamic space topologies.
The group also reviewed two draft updates: a standard code notation for describing satellite constellations, and a typology plus community registry of space research tools and infrastructures.
1. Welcome, Note Well and Agenda Bashing — Chairs
- Slides: Chairs — Introduction and Agenda
- The chairs opened the session and reviewed the IRTF Note Well: IPR disclosure rules (RFC 5378, RFC 8179, RFC 5743), the audio/video recording policy, the privacy policy, and the code of conduct (RFC 7154, RFC 7776, RFC 9775).
- The chairs recalled the goals of the IRTF (RFC 7418): the group works on longer-term research issues and does not develop standards, aiming instead to foster research collaboration on space-specific protocols and architectures.
- The agenda was presented and accepted without changes.
2. Beyond Starlink: Understanding the Coming Waves of LEO Satellite Deployments
Presentation
- Starlink currently dominates LEO, with roughly 12,600 satellites launched and close to 35,000 planned, plus about 1,600 Starshield satellites for government/military use.
- A large wave of further constellations is being filed and deployed worldwide:
- Active or imminent: Amazon LEO / Kuiper (~8,000 planned); Eutelsat OneWeb (660 launched, 528 further filed); AST SpaceMobile and Lynk Global (direct-to-cell, using very large satellites); Globalstar (1,946 filed, Apple partnership, being folded into Amazon LEO); Iridium (acquired by Rocket Lab, aiming at a vertically integrated launch-plus-constellation stack).
- China: state-backed Guowang (~14,000 planned, ~200 launched) and Shanghai-backed Qianfan / "Thousand Sails" (~16,000 planned), plus an additional filing of roughly 200,000 satellites.
- Russia: Rassvet (300–900 planned, ~22 launched).
- Filed or announced: Blue Origin (optical downlinks); the EU's IRIS²; Telesat Lightspeed (~1,600); Hanwha (~10,000); a ~1,200-satellite constellation intended to use SpinLaunch kinetic launch; India's Reliance Jio; Logos Space (~4,000).
- Orbital data centres: filings to host AI/compute infrastructure in orbit, including SpaceX (nearly 1.2 million satellites), Starcloud / Lumen Orbit (88,000), Blue Origin, Orbital Compute (100,000), Cowboy Space (20,000) and Google's Project Suncatcher.
- Aggregate scale across all filings tracked: more than 2.3 million planned satellites.
Discussion
- Launch capacity and sustainment (Dan York). Launch is the binding constraint: only SpaceX, and to a lesser degree one Chinese provider, launch consistently. Amazon signed the largest launch contract package ever (83 launches, across every provider except SpaceX), but the rockets are not flying at the required rate. With a 3–5 year orbital lifetime below 600 km, sustaining a constellation, let alone growing it, requires a continuous high launch cadence. The atmospheric effect of 50–100 satellites re-entering and burning up daily is not understood.
- Feasibility of the filed numbers (Nitinder Mohan). Many filings look like business positioning. Dan York declined to predict how much is real, noting that very large amounts of capital are flowing in, especially where AI is involved, and that apparent barriers keep being bought through.
- Regulatory authority and coordination (Carlos Martinez-Cagnazzo). National regulators approve filings and submit them to the ITU, which holds the list of filings rather than regulating directly: the FCC for SpaceX and Amazon, the Indian space agency for Reliance Jio, and so on. Spectrum and orbital coordination sits with ITU-R.
- Governance (Ali Rezaki, Sustain RG). Drawing a parallel with a recent workshop on AI data centres, where local communities were argued to deserve a say in siting, he questioned whether national regulation alone is adequate when the affected constituency is the whole world population. Dan York agreed that the ITU mechanism was designed for an era of roughly 1,800 GEO slots and a few launches a year, and does not fit a regime of millions of filed satellites, but saw little prospect of change given the money involved.
- Fewer, larger satellites (Gianpaolo Scalone). Asked whether larger satellites, as used by AST SpaceMobile, could deliver equivalent coverage with far fewer objects, or whether operators could share infrastructure. Dan York agreed that interoperation and shared constellations would be preferable, but saw no commercial incentive: every operator currently wants its own fleet.
- Levers for external actors (Kurtis Heimerl). Asked where researchers, engineers and policymakers can actually influence the trajectory of a set of highly commercial systems. Dan York pointed to the questions not being asked during the current rush to launch: space debris, climate and upper-atmosphere effects, economic sustainability, centralisation of connectivity under a few operators, and what happens to the hardware in orbit when an operator goes bankrupt. Research and public communication on those questions is the lever, against considerable commercial momentum.
- Role of the IETF/IRTF (Rick Taylor). Large sums are being spent on communication systems that will interconnect with the Internet, and that interconnection is the point of leverage: the IETF/IRTF community knows how the Internet works and should engage actively with these operators, many of whom are present directly or by proxy, to keep what is built compatible and interoperable.
- Follow-up (chairs). The chairs proposed collecting the sources, filings and pointers behind the talk into a single shared resource for the group, seeded by the additional constellations raised in the chat, rather than having everyone rebuild the survey independently.
3. The Limitations of LEO Uplink
Presentation
- LEO uplink matters for video conferencing, large file upload and cloud backup, live video contribution, remote sensing and interactive edge applications, yet it is a limited, shared and dynamic resource: ISPs allocate roughly 10% of capacity to uplink against 90% downlink.
- Measurement setup: five Starlink Business Priority dishes on a single rooftop in Los Gatos, CA (downlink 130–300 Mbps, uplink 20–40 Mbps), sending UDP with iperf3 at 100 ms granularity.
- Findings:
- A single dish sending at 30 Mb/s experiences multi-second bursts of sustained loss, aligned with Starlink's 15-second topology reconfiguration interval; loss rates grow superlinearly with sending rate.
- Nearby dishes contending for the same satellite increase packet loss materially.
- Distributing an aggregate sending rate across several dishes lowers aggregate loss and lets bonded capacity scale to about 100 Mbps, but does not remove the shared loss events that occur when all local dishes are served by the same satellite.
- Generating heavy downlink traffic (around 200 Mb/s) causes the traffic-engineering logic to grant the user substantially more uplink capacity.
- Conclusion: the community needs transport protocols that recover from high loss, application-layer algorithms that adapt to fluctuation, and better LEO-wide traffic engineering. Most real users have only one dish and cannot bond.
Discussion
- Measurement location and incentives (Warren Kumari). Confirmed the deployment is in the San Francisco Bay Area. He observed that the uplink-for-downlink behaviour creates a perverse incentive for users to run constant high-rate downloads purely to secure uplink capacity, at least until the operator adapts. Liz Izhikevich noted the user still pays for that traffic, so it becomes a cost trade-off.
- Dish–satellite association (Tony Li). Asked whether the association between dishes and uplink satellites was observable. It was: during the shared loss bursts (for example seconds 30–45) all five dishes were on the same satellite, whereas when one dish performed well while the others suffered, it was on a satellite of its own. Association can be inferred from open-source obstruction-map techniques.
- Gateway congestion (Tony Li). The losses were confirmed not to be gateway congestion, though via operator contacts rather than open data; no straightforward public measurement technique to separate the two was identified.
- Neighbour contention, fairness and recourse (Nalini Elkins). Asked whether a heavy or deliberately disruptive neighbour degrades everyone else, and what recourse exists. Liz Izhikevich confirmed the effect: uplink is a constrained shared resource, the advertised uplink rate is an approximation rather than a guarantee, and a persistent nearby heavy uploader will simply contend with you. She saw no legal issue, but pointed to the need for better protocols and fairness/load-balancing algorithms. Remote locations with few neighbouring dishes perform significantly better than urban ones, and existing theoretical work shows LEO capacity cannot serve the whole world population given the surface-area and per-satellite capacity bottleneck.
- Reconfiguration duration (Daniel Gultsch). Asked how long the link reconfiguration actually takes and whether SpaceX plans to shorten it. The radio repointing itself is on the order of 10 ms or less; the visible cost is the burst of loss around that event. Whether future satellite generations will shorten the reconfiguration period is unknown.
4. Industrial Communication Services via Non-Terrestrial Networks: Requirements and Challenges
Presentation
- Siemens is examining NTNs for critical industrial infrastructure: railways (fleet management, train control), maritime, mining, smart grids and remote plant operation.
- Industrial traffic classes have distinct requirements: bulk telemetry (delay-tolerant, high volume), remote monitoring, supervisory control (sub-second delay, loss-sensitive) and closed-loop control (tens of milliseconds, strict ordering, low jitter).
- Demonstrated an experiment running a closed-loop control application (balancing a ball on a plate over PROFINET) across an emulated LEO network, with virtualised PLCs migrating between satellites.
- Argued for "compute awareness" and joint optimisation of communication, computing and control: when degradation is predicted, the application should degrade gracefully, for example by slowing the robot's motion rather than losing the control loop.
Discussion
- Exposing network state to applications (Dirk Kutscher). Asked whether APIs that expose predicted network behaviour to the application, so local control loops can adapt, would be a suitable topic for this group. Florian Zeiger agreed the experiment had not addressed it and that it is an interesting direction, closely related to how an industrial service expresses its intent, what it needs from the network, to a dynamic system. The two agreed to continue the discussion offline and potentially bring it to the group.
5. Towards Standardized Routing for LEO Satellite Networks: A Comparative Study
Presentation
- Context: routing proposals are scattered across drafts and three side meetings, with no consensus on forming a working group and no standards-track routing protocol (RFC 9717 is not standards track; RFC 9657 covers TVR use cases).
- Compared four families of proposals: SDN (easy central control, but limited controller footprint, distributed-controller synchronisation issues), reactive routing (adapts to dynamics, but on-demand and CPU-bound, hard to reach line rate above 100 Gb/s), proactive routing (hardware pre-programmed forwarding, best performance, but poor fit to dynamic topologies) and emerging AI-driven approaches (no deployment experience).
- Concluded that proactive routing is the most viable candidate for the carrier/transport function of a LEO network, where performance, scalability and reliability dominate, particularly in a 3GPP NTN regenerative-payload architecture with the gNB on the satellite.
- Existing proactive protocols (OSPF, IS-IS) cannot be applied directly: they assume a relatively stable, hierarchical topology of order 1,000 nodes, whereas a LEO network is flat, highly dynamic, and reaches 10,000+ nodes with millions of ground devices.
- What can be kept: the architecture (LSDB, adjacency establishment, SPF, routing and forwarding tables, LSA flooding) and the message set. What needs work: partitioning, convergence dependency, flooding reduction, source routing and data-plane handling, static satellite/ISL addressing, fast network-state detection, and scalable simulation environments.
Discussion
- Where is the interoperability requirement? (Rick Taylor). Raised as a process question: if operators such as Starlink deploy proprietary single-vendor systems, why standardise? Lin Han answered that the 3GPP architecture already forces standard protocols at the access and backhaul boundary, because the satellite operator and the communication modules typically come from different vendors, so open API and protocol definitions are needed. Rick Taylor remained sceptical that vendors are thinking that way today, while agreeing the topic is appropriate for the IRTF.
- Lin Han noted the same argument had been made earlier against his proposals, and that Starlink's move into 3GPP direct-to-cell access illustrates the pattern: interoperability is not wanted at an early stage and becomes necessary later.
- Medium-sized constellations (Maxime Piraux). Spoke in favour of continuing the work from the perspective of medium-sized constellations rather than Starlink, since those operators cannot build a fully vertical proprietary stack and will need multi-vendor routing.
- Lin Han closed by noting this remains a research topic: 3GPP work is still concentrated on the radio path, and the traditional approach of forwarding everything to the core network while ignoring the lower-layer topology does not work here.
6. Group work: A Code to Describe Satellite Constellations (draft update)
Presentation
- Goal: a common notation for describing satellite constellations, to establish reference scenarios and support reproducible research on shared assumptions. It targets Earth deployments but stays simple enough to be reused for interplanetary networks.
- Draft history: -00 defined the compact mission-parameter code (
Type:Altitude:Inclination:T/P/F, e.g. D:550:53.0:1584/22/17 for a Starlink shell) with a full ABNF grammar; -01 added patterns for establishing inter-satellite links within a shell; -02 replaced the YAML definitions with CDDL schemas and added a CDDL schema for ground-station location and capabilities (latitude/longitude/altitude, minimum elevation, number of antennas) to establish feeder links. Coverage is restricted in elevation only, not azimuth, and satellites are assumed to impose no further constraint.
- Two tools consuming the notation were demonstrated:
- Aerospacelab Constellationlab, which generates a Containerlab networking lab from a constellation specification, computes the active ISLs and feeder links and their one-way delays at any time, and emulates real networking stacks over the resulting topology.
- Contact Plan Designer (open source, MIT, Python + web, https://contact-plan-designer.space/), which runs the I-D end to end with the draft's examples pre-loaded, computes, visualises, designs and exports contact plans, and composes up to deep-space and cislunar scenarios.
- Future work: whether to describe further capabilities while staying generic, in particular RF link budgets for feeder links and optical head capabilities.
Discussion
- Data model versus serialisation (Erik Kline). Suggested separating the abstract data model from the compact string encoding: express the constellation elements in CDDL as the data model, and treat the string code as one particular encoding, leaving room for other encodings in other applications. Maxime Piraux agreed the encoding is secondary and that the substance of the work is the taxonomy and agreement on the elements themselves.
- Routing in the core versus bent pipe (Ali Rezaki). Asked, from a sustainability standpoint, whether a routed satellite core network is the right design, given that the historical paradigm was to reach the ground segment as quickly as possible: resource and energy efficiency might favour pulling the ground network back into the equation. Maxime Piraux acknowledged that bent-pipe is more energy efficient, but it is less service-rich, and there are now customers who specifically want connectivity that does not depend on transiting a terrestrial network.
7. Group work: A Typology of Space Research Infrastructures (draft update)
Presentation
- The work started as a call to arms at the TAGS workshop and has grown into a typology and registry of tools and infrastructures for LEO measurement and evaluation.
- The taxonomy defines ten classes: simulator, emulator, testbed, in-orbit platform, dataset, measurement tools, (reference) implementation, library, visualiser and research platform. It remained robust as the collection grew from 60 to 110 tools, and is explicitly open for discussion: new categories may emerge and it is not intended to be frozen.
- A community registry is published as a living document at https://irtf-spacerg.github.io/id-leo-tools/registry/. Each resource is one machine-readable record in one class; additions and corrections are made by pull request.
- Registry entries are point-in-time observations: each carries a last-verified date and is periodically re-verified. Failing verification does not remove an entry, since these are historical records of the baselines from which published results were obtained.
- No questions were raised in the room.
8. Wrap-up and Next Steps — Chairs
- Constellation code draft: the authors invite feedback on the CDDL schemas and the taxonomy, either on the SPACE mailing list or as pull requests / issues at https://github.com/mpiraux/draft-piraux-space-constellation-code, and encourage participants to use the code in their own tools.
- Typology draft and registry: participants are invited to review the draft and to submit pull requests adding or correcting entries in the community registry.
- Constellation-filings resource: following the discussion after Dan York's talk, the chairs will follow up on collecting the filings, sources and pointers into a shared group resource.
- Meetings: no SPACE RG session is currently planned for IETF 127 (San Francisco); the chairs intend to hold a virtual interim or side meeting in the autumn instead. Details will be announced on the mailing list.
Action Items
| # |
Item |
Owner |
| 1 |
Announce and organise the autumn virtual interim / side meeting |
Chairs |
| 2 |
Follow up on a shared group resource collecting constellation filings and sources |
Chairs, Dan York |
| 3 |
Collect feedback on draft-piraux-space-constellation-code-02 (CDDL schemas, taxonomy) via the list and GitHub |
Maxime Piraux, Juan A. Fraire |
| 4 |
Progress draft-sastry-spacerg-space-research-infra-typology and grow the community registry through pull requests |
Nishanth Sastry, Juan A. Fraire |