Research Direction
ReSpaN: Recursive Space Networking Architecture
ReSpaN is a unified space-networking architecture for challenged environments such as lunar, cislunar, and interplanetary communications. Instead of treating space networking as a flat end-to-end routing problem, ReSpaN builds networking recursively from scoped communication domains and combines durable service semantics, contact-aware planning, and fast forwarding inside one structured framework.
Overview
ReSpaN (Recursive Space Networking) is a proposal for a unified interplanetary networking framework inspired by Recursive InterNetwork Architecture (RINA). In RINA, networking is not organized as a fixed stack of different protocols, but as a recursive composition of Distributed IPC Facilities (DIFs), where each DIF is a scoped communication domain providing IPC services, and higher-level DIFs are realized by lower-level DIFs interconnected through relay processes. ReSpaN extends this idea to space networking through a recursive model of scoped DIFs, where each scope preserves the same conceptual communication structure while using policies suited to the region’s latency, bandwidth, continuity, and reliability.
At a high level, applications express service intent plus a destination, and each DIF implements the same three-plane architecture: a Control Plane for membership, naming, policy, and reachability guidance; a Service Plane for durable object semantics such as custody, persistence, contact-aware scheduling, and replication; and a Data Plane for fast in-contact transfer using scoped forwarding labels.
Why a New Space Networking Architecture Is Needed
- Connectivity is not continuous: links appear and disappear as scheduled contacts, propagation delays are large, and nodes move continuously.
- One global control truth is brittle: fine-grained routing state cannot remain fresh across an end-to-end path in a challenged space environment with high latency, intermittent connectivity, and low bandwidth.
- Space systems are heterogeneous: lunar surface operations, cislunar trunks, LEO meshes, and terrestrial infrastructure should not be forced into one fixed policy model.
- Durable delivery matters: persistence, custody, replication, and delayed scheduling are core service concerns, not optional afterthoughts.
Architectural Foundations
RINA-Inspired Recursion
ReSpaN adopts the idea that networking is repeated IPC across scopes. DIFs can be stacked recursively, and what changes across scopes is policy rather than the underlying architectural model.
DTN Semantics
ReSpaN internalizes store-carry-forward behavior, custody, and contact-aware scheduling into the service layer of each relevant scope instead of bolting them above a separate protocol stack.
SDN-Inspired Plane Separation
ReSpaN separates governance and planning from fast execution, but adds a third plane so that persistence and durable service semantics do not overload either control logic or the forwarding fast path.
Label-Based Fast Forwarding
The architecture uses ephemeral local forwarding identifiers, called labels, as scoped forwarding handles, allowing fast, predictable forwarding while keeping path selection and policy off the fast path.
Core Building Block: The DIF
A Distributed IPC Facility (DIF) is the primary architectural unit in ReSpaN. A DIF is a scoped distributed communication layer formed by cooperating members that jointly provide a bounded-scope communication service. A single node may participate in multiple DIFs through distinct members, and each DIF carries its own policy, administrative context, and live state.
Node
A physical or virtual execution substrate such as a spacecraft computer, relay processor, surface gateway, or ground station server.
DIF Member
A scoped IPC process executing on a node and enrolled in a specific DIF under that DIF’s policy and trust context.
Object
The service-level unit of transfer: a named payload plus delivery semantics such as service class, deadline, custody mode, and integrity requirements.
Boundary
The scoped interface where objects and control/trust context cross between DIFs. Boundaries enforce admission, validation, and handoff constraints.
The Three-Plane Architecture
Control Plane (CP)
- Membership, enrollment, and trust establishment
- Naming delegation and scoped reachability guidance
- Distribution and revocation of signed policy bundles
- Capability advertisements and contact summaries
- Governance over which mechanisms and policies are permitted in the DIF
Service Plane (SP)
- Durable object semantics across disruptions
- Persistence, custody, and receipt logging
- Feasibility-aware scheduling over contact opportunities
- Replication and deduplication policies
- Enforcement of class semantics independent of the underlying transport mechanism
Data Plane (DP)
- Ephemeral label-based next-hop execution with minimal lookup overhead
- Class-aware queueing, pacing, and fast forwarding
- Per-contact secure session and transfer realization
- Runtime policy and trust enforcement on the fast path
- Telemetry production for replanning and safety updates
Service Intent Classes
ReSpaN treats communication as an object with intent, not just as a stream of packets. Applications declare the service outcome they want, and each scope maps that intent to local mechanisms using current policy and contact context.
Class I — Interactive
Latency-sensitive exchanges such as teleoperation and interactive control, favoring minimal queueing and immediate forwarding.
Class B — Bulk
Asynchronous and delay-tolerant traffic such as large science downlinks, favoring efficient use of contact capacity, buffering, batching, and schedule-aware dispatch.
Class C — Critical
Mission-critical traffic such as command uplinks, trust updates, and safety directives, with strict priority and stronger assurance under disruption.
Recursive DIF Operation
ReSpaN uses recursion so that a higher DIF does not require the detailed topology of lower DIFs. A higher scope depends on conservative summaries of what lower scopes can currently justify, then delegates execution downward. This contains fast churn locally, reduces the need for global topology leakage, and lets each scope reason only over what it can legitimately know.
The architecture also uses explicit scope-local contract state: each scope tracks what remains to be done, what obligations are still active, and what next-hop commitment should be delegated downstream. This makes replanning controlled and auditable rather than ad hoc.
Space Geography in ReSpaN
ReSpaN introduces a coarse geography model to make routing understandable and stable in space environments. Here, geography does not mean raw coordinates, latitude/longitude, or rapidly changing orbital positions. Instead, it means a small set of stable operational containers that match how space networks are actually managed. This is important because in space, connectivity is often scheduled, paths may not exist at every moment, and nodes move continuously. A routing system based on constantly changing positions would create too much churn and would be difficult to maintain consistently.
To avoid that problem, ReSpaN describes destination locations using named geographic containers and performs routing by repeatedly deciding how to enter the next appropriate container. This gives the network a location model that is hierarchical, stable, and compatible with recursive routing across DIF scopes.
Body Vicinities
A body vicinity is the operational neighborhood around a major celestial body, such as Earth, Moon, or Mars. These regions are chosen so that communication conditions, trust assumptions, and planning models are relatively coherent inside the vicinity. For example, Earth vicinity and Moon vicinity are treated as separate stable routing containers rather than as constantly changing collections of satellite coordinates.
Corridors
A corridor is the space between major vicinities, such as the Earth–Moon corridor or Earth–Mars corridor. Corridors are modeled explicitly because they usually have different behavior from local vicinity networks: contacts are often sparse, scheduled, delay-dominated, and strongly tied to orbital dynamics. Relays in Lagrange regions or deep-space trunk paths naturally belong to such corridors.
Hierarchical Location Names
ReSpaN organizes these containers using a hierarchical naming style so that coarse locations are prefixes of more specific ones. This allows capability information to be summarized at a stable level and avoids rebinding every time a node moves locally within the same region. In effect, service names stay separate from locations, while routing uses these geographic prefixes to reason about reachability.
Why This Helps Routing
This geography model reduces churn because nodes do not constantly switch between high-level containers such as “Earth vicinity” and “cislunar corridor.” It also makes capability advertisements more meaningful: instead of advertising reachability to every moving node position, a DIF can advertise that it can reach a named container within certain bounds. That lets higher scopes reason using stable summaries while lower scopes handle local motion and contact details.
In practical terms, routing in ReSpaN becomes a repeated question: “Given the object’s current constraints, which ingress into the next geographic container should I choose?” A DIF does not need a complete, globally fresh view of the whole interplanetary path. It only needs enough local knowledge to decide the next safe step, after which the next scope repeats the same reasoning with its own policies and feasibility view.
This is what makes the geography model compatible with recursion: each scope reasons only about the next container boundary it can justify, while the internal mobility, contact timing, and multi-hop details are handled inside the DIF that owns that scope.
CGR and Local Feasibility
ReSpaN uses Contact Graph Routing (CGR) as a local feasibility engine rather than as one monolithic end-to-end route solver. Within a scope, CGR reasons about whether a viable next hop or boundary ingress exists using scheduled contacts, propagation delay, residual contact volume, and current object constraints such as deadline and class.
Each scope commits only to a safe next step. The downstream scope then repeats the same process using its own view and policies. This makes CGR recursive in ReSpaN.
LFIDs and Fast Forwarding
ReSpaN’s Data Plane uses Local Forwarding IDs (LFIDs), which are scoped forwarding handles analogous in spirit to MPLS labels or segment identifiers. LFIDs are not global addresses. They are local, often ephemeral, and bound to scope, class, security context, and expiry conditions.
- DIF-scoped: meaningful only within the current scope
- Often ephemeral: usable for a contact window or bounded policy epoch
- Policy-bound: associated with class, next-hop set, and security context
- Boundary-terminated: LFIDs are re-originated at scope boundaries to preserve recursion
Why This Architecture Matters
- It avoids forcing one global routing/control truth across delay-prone and heterogeneous space environments.
- It makes persistence, custody, replication, and scheduling first-class service concerns rather than overlay add-ons.
- It separates durable correctness from fast execution, which helps keep the forwarding path predictable.
- It provides a principled way to combine local autonomy with end-to-end semantic delivery guarantees.
Note: This page summarizes ongoing proposal-stage work on ReSpaN. It is meant to communicate the architecture and research direction clearly, rather than serve as a finalized publication page.