A typology of Space Research Infrastructures
draft-sastry-spacerg-space-research-infra-typology-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Nishanth Sastry , Juan A. Fraire | ||
| Last updated | 2026-08-07 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sastry-spacerg-space-research-infra-typology-01
Systems and Protocol Aspects for Circumstellar Environments N. Sastry
Internet-Draft University of Surrey
Intended status: Informational J. A. Fraire
Expires: 7 February 2027 Inria
6 August 2026
A typology of Space Research Infrastructures
draft-sastry-spacerg-space-research-infra-typology-01
Abstract
Space networking research increasingly relies on a heterogeneous
ecosystem of software, datasets, experimental platforms, reference
implementations, and operational research assets. These resources
have historically been developed independently by different research
groups, agencies, and projects, making discovery, comparison,
interoperability, and reuse difficult. Existing registries typically
catalogue tools individually but provide limited guidance on their
functional role within the research lifecycle.
This document proposes a typology for research infrastructures
relevant to the Space Research Group (SPACERG). The proposed
taxonomy groups resources by the research function they serve,
independently of their implementation technology or project origin.
The typology provides a common vocabulary for describing software and
non-software research assets, supports the organization of community
registries, and facilitates interoperability, reproducibility, and
long-term maintenance of research infrastructures. The
classification is intended to evolve as new classes of research
resources emerge. The typology is implemented by a machine-readable
registry of research resources maintained by the research group.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://irtf-
spacerg.github.io/id-leo-tools/draft-sastry-spacerg-space-research-
infra-typology.html. Status information for this document may be
found at https://datatracker.ietf.org/doc/draft-sastry-spacerg-space-
research-infra-typology/.
Discussion of this document takes place on the Systems and Protocol
Aspects for Circumstellar Environments Research Group mailing list
(mailto:space@irtf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/space/. Subscribe at
https://www.ietf.org/mailman/listinfo/space/.
Sastry & Fraire Expires 7 February 2027 [Page 1]
Internet-Draft SpaceRG-Infra August 2026
Source for this draft and an issue tracker can be found at
https://github.com/irtf-spacerg/id-leo-tools.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The typology . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. What resisted classification . . . . . . . . . . . . . . 5
3. The SPACERG Registry . . . . . . . . . . . . . . . . . . . . 6
4. Relationship to other SPACERG work . . . . . . . . . . . . . 6
5. Conventions and Definitions . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Sastry & Fraire Expires 7 February 2027 [Page 2]
Internet-Draft SpaceRG-Infra August 2026
1. Introduction
Research in space networking depends upon a broad collection of
complementary research infrastructures. These include simulation
environments, network emulators, protocol implementations, datasets,
browser-based experimentation environments, visualization tools,
experimental testbeds, satellite constellations, and software
supporting data collection and analysis. While many of these
resources have become widely adopted within individual research
communities, they are often documented independently, use
inconsistent terminology, and overlap in functionality.
As the Space Research Group (SPACERG) develops a shared registry of
research infrastructures, it has become apparent that simply
maintaining a list of available tools is insufficient. Users require
a consistent method of understanding _what role_ a resource plays
within the research ecosystem, how it complements other resources,
and where it fits within an experimental workflow. A common typology
also improves discoverability, assists researchers in selecting
appropriate infrastructures, and enables more consistent metadata
across independently maintained registries.
The purpose of this document is to establish a common vocabulary that
lets researchers classify and discover research infrastructures
relevant to space networking consistently. It does not prescribe a
fixed ontology. The taxonomy is intended to support the SPACERG
registry, facilitate interoperability with other research
infrastructure catalogues, and provide a foundation for future
standardization efforts within the IRTF and IETF research
communities.
2. The typology
The typology described in this document was developed by analysing
the verified research resources collected from the community and
curated in the SPACERG registry. The categories emerged from the
primary research purpose each resource serves. Software architecture
and implementation language proved to be poor discriminators: two
resources built on the same framework and written in the same
language may occupy entirely different positions in an experimental
workflow. This functional approach accommodates both software and
non-software research assets and remains applicable as new
technologies are introduced.
The initial categories identified include, under the names used by
the registry:
Sastry & Fraire Expires 7 February 2027 [Page 3]
Internet-Draft SpaceRG-Infra August 2026
* *Simulator*, modelling network behaviour using abstract
representations (flow-level, packet-level, or discrete-event) to
support scalable experimentation without executing real protocol
stacks.
* *Emulator*, reproducing the timing and topology of target systems
while executing real protocol implementations and operating-system
network stacks.
* *Testbed*, offering physical, virtual, or hybrid environments with
real links, such as terminal deployments and ground stations, for
integrated experimental evaluation.
* *In-orbit platform*, representing operational or experimental
space assets (research satellites, constellations, and hosted
payloads) that provide real-world experimentation opportunities.
* *Dataset / data*, including curated measurement datasets and live
data services such as orbital-element feeds.
* *Measurement*, providing tools and methodologies that produce new
measurements, including browser-integrated extensions, terminal-
telemetry collectors, Internet-scanning methodologies, and
benchmarking frameworks.
* *Implementation*, providing runnable protocol stacks, proxies, and
flight software deployed in experiments, such as Bundle Protocol
implementations, non-terrestrial-network radio access stacks, and
performance-enhancing proxies.
* *Library*, providing reusable building blocks embedded by other
resources, such as orbit propagators, contact-plan generators, and
routing libraries.
* *Visualizer*, supporting analysis, interpretation, and
presentation of orbital and network state.
* *Research platform*, offering orchestration and service
environments for experimentation, such as satellite edge-computing
and serverless frameworks.
The registry vocabulary additionally reserves a small set of
auxiliary labels (Meta-resource, Commercial / service, Unresolved,
Other) for resources that fall outside these research categories or
that await classification.
Sastry & Fraire Expires 7 February 2027 [Page 4]
Internet-Draft SpaceRG-Infra August 2026
Although these categories provide broad coverage of the current
SPACERG registry, they are not intended to be exhaustive. New
categories may emerge as the community develops additional research
infrastructures, including digital twins, AI-assisted experimentation
platforms, workflow management systems, and cloud-based
experimentation environments.
2.1. What resisted classification
Applying the typology to the collected resources exposed four
boundaries that a single class label cannot carry on its own. They
are recorded here because they shape the registry schema, and because
they are the places where two curators are most likely to disagree.
The first is the boundary between simulation and emulation. Whether
a resource executes real protocol stacks is the property researchers
most often want to know, and it does not align cleanly with either
class. Some emulators run unmodified containers over shaped links,
some simulators embed a real transport implementation, and some
resources do either depending on how they are configured. The
registry therefore carries execution fidelity on its own axis, and
the class label alone does not imply it.
The second is that a project and a resource are different units. A
testbed and the measurement traces it publishes have different
licences, contacts, maintenance states and lifecycles, so they are
described by separate records under different classes even when one
produces the other. Several projects in the registry appear this
way, spanning three or four classes between them.
The third is that the distinction between a library and an
implementation depends on how a resource is used. The same codebase
can be a standalone protocol stack in one deployment and an embedded
component in another, and the class records the role in which it is
most commonly encountered.
The fourth is that in-orbit platforms and testbeds share an access
model. Both are typically reached through an experimenter programme
rather than a download, and the class records where the asset is
while the access model is described separately.
None of the collected resources have so far required the Unresolved
or Other labels. That the categories held is a weak result: the
collection comes from a community with shared assumptions about what
counts as a research resource, and a sweep across adjacent fields
would likely surface cases that do not fit.
Sastry & Fraire Expires 7 February 2027 [Page 5]
Internet-Draft SpaceRG-Infra August 2026
3. The SPACERG Registry
The typology in this document is implemented by a community registry
maintained by SPACERG in the repository that also hosts this
document, and published as a searchable page with JSON and CSV
exports [REGISTRY]. Each resource is described by one machine-
readable record carrying its class under this typology, functional
metadata (how orbital dynamics are defined, which layers are covered,
whether real protocol stacks are exercised, the largest scale
demonstrated in a publication, and input and output formats), and
provenance metadata (license, a named contact, how the entry was
collected, and when it was last verified).
Additions and corrections are made by pull request, one file per
resource, and are validated automatically against the registry
schema. To be included, a resource should be specific to space or
satellite networking, usable by others through a public artifact or a
documented access program, and verifiable through a working URL and,
where claims matter, a publication.
Registry entries are point-in-time observations: tools are abandoned,
URLs move, and maintenance states go stale. Each record therefore
carries a last-verified date and entries are re-verified
periodically. Entries that fail verification are marked as historic
rather than deleted, because unmaintained resources remain relevant
as baselines against which published results were obtained.
4. Relationship to other SPACERG work
This typology and the registry that implements it are complementary
to the registry of announced, filed and deployed satellite
constellations maintained by the research group [CONSTELLATIONS].
This work catalogues what researchers can experiment with; that one
catalogues what is being built and what has been claimed. The two
use the same contribution model, the same validation approach and the
same publication mechanics, and are intended to be usable together.
One design choice is shared between them. A record describes a
single resource, under this typology, or a single authorisation, in
the constellation registry, and a project-level or operator-level
view is composed from the records by whoever needs one. Both
registries also treat their entries as observations at a date and
carry the date with the claim.
Sastry & Fraire Expires 7 February 2027 [Page 6]
Internet-Draft SpaceRG-Infra August 2026
5. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
6. Security Considerations
This document defines a vocabulary for describing research
infrastructures and introduces no protocol mechanisms. The registry
that implements it records public information about publicly
available resources.
Entries link to third-party code, data and services. Inclusion in
the registry carries no security assessment of what a link points to,
and readers running registry-listed software should evaluate it as
they would any other third-party dependency.
7. IANA Considerations
This document has no IANA actions.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
8.2. Informative References
[CONSTELLATIONS]
IRTF Space Research Group, "SPACERG Satellite
Constellation Registry", <https://irtf-spacerg.github.io/
id-leo-constellations/registry/>.
Sastry & Fraire Expires 7 February 2027 [Page 7]
Internet-Draft SpaceRG-Infra August 2026
[DAGSTUHL] Schloss Dagstuhl, Leibniz Center for Informatics,
"Dagstuhl Seminar 26062: Connected Space: Challenges and
Opportunities in Satellite Computing and Networking",
February 2026, <https://www.dagstuhl.de/seminars/seminar-
calendar/seminar-details/26062>.
[REGISTRY] IRTF Space Research Group, "SPACERG Space Networking Tools
Registry",
<https://irtf-spacerg.github.io/id-leo-tools/registry/>.
Acknowledgments
The initial collection of research resources was assembled by the
participants of Dagstuhl Seminar 26062, "Connected Space: Challenges
and Opportunities in Satellite Computing and Networking", held from 1
to 4 February 2026. The seminar page lists its organizers and
participants [DAGSTUHL], and the authors thank all of them. The
collection was extended by a systematic literature and web sweep in
July 2026, and the typology described in this document was derived
from it.
Authors' Addresses
Nishanth Sastry
University of Surrey
Email: n.sastry@surrey.ac.uk
Juan A. Fraire
Inria
Email: juan.fraire@inria.fr
Sastry & Fraire Expires 7 February 2027 [Page 8]