Skip to main content

A typology of Space Research Infrastructures
draft-sastry-spacerg-space-research-infra-typology-01

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]