Network Support for Distributed Computing in Space Networks
draft-zhu-space-distributed-computing-requirements-00

Systems and Protocol Aspects for Circumstellar Environments       M. Zhu
Internet-Draft                                              China Mobile
Intended status: Informational                                     Q. Li
Expires: 11 March 2027Beijing University of Posts and Telecommunications
                                                        7 September 2026

      Network Support for Distributed Computing in Space Networks
         draft-zhu-space-distributed-computing-requirements-00

Abstract

   Distributed execution can be useful in space networks when one node
   lacks enough computing, storage, energy, or execution time, or when
   data is spread across multiple nodes.  It can also enable parallel
   processing or allow different execution stages to run on different
   space or terrestrial nodes.  A task may therefore create multiple
   communication relationships that appear, coexist, change, and end as
   execution progresses.  Because satellite motion changes connectivity
   over time, reachability alone is not enough to determine whether an
   execution endpoint can support the required communication.

   This document analyzes the network role in such distributed execution
   in the space network.  It considers how network information affects
   execution decisions, how those decisions create communication
   requirements and relationships, when communication over a
   relationship is ready for use, and how relationships change as
   execution and connectivity evolve.

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 11 March 2027.

Zhu & Li                  Expires 11 March 2027                 [Page 1]
Internet-Draft  Space Distributed Computing Requirements  September 2026

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.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Distributed Execution Creates Multiple Communication
           Relationships . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Reachability Does Not Ensure Communication Feasibility  .   5
     3.3.  Communication Requirements Need Network Realization . . .   5
     3.4.  Communication Relationships Change Over Time  . . . . . .   5
   4.  Representative Distributed Execution Scenarios  . . . . . . .   5
     4.1.  Multi-Source Data Aggregation . . . . . . . . . . . . . .   6
     4.2.  Multi-Node Parallel Processing  . . . . . . . . . . . . .   6
     4.3.  Multi-Stage Execution . . . . . . . . . . . . . . . . . .   6
     4.4.  Planned and Unplanned Relationship Changes  . . . . . . .   7
   5.  Design Considerations for Network Support of Distributed
           Execution . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Information Exposure and Abstraction  . . . . . . . . . .   8
     5.2.  Communication Requirement Expression  . . . . . . . . . .   9
     5.3.  Communication Relationship Realization and Readiness  . .   9
     5.4.  Planned and Unplanned Changes . . . . . . . . . . . . . .  10
     5.5.  State Management under Network Dynamics . . . . . . . . .  10
   6.  Network Requirements  . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Network Information for Execution Decisions . . . . . . .  11
     6.2.  Distributed Communication Requirement Expression  . . . .  11
     6.3.  Communication Relationship Realization and Readiness  . .  12
     6.4.  Communication Relationship Updates and Feedback . . . . .  12
     6.5.  State Locality, Consistency, and Lifecycle  . . . . . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   Appendix A.  Example of Network Support for an Evolving Distributed
           Execution . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

Zhu & Li                  Expires 11 March 2027                 [Page 2]
Internet-Draft  Space Distributed Computing Requirements  September 2026

1.  Introduction

   As satellites gain more computing, storage, and data-processing
   capability, some tasks can be completed by multiple space and
   terrestrial nodes.  A single node may lack enough computing, storage,
   energy, or execution time.  Data may also be produced at different
   locations, and parallel or multi-stage execution may reduce task
   completion time.

   Distributed execution changes what the network needs to support.
   Instead of communicating mainly through one fixed execution endpoint,
   a task may send input data to several endpoints and exchange
   intermediate results among them.  It may also pass results to a
   different endpoint between stages and finally deliver results to
   another node or the ground.  These patterns create communication
   relationships that may coexist and change over the lifetime of a
   task.  In space networks, changing connectivity may also make an
   endpoint reachable but not long enough to complete the required
   transfer.

   The compute side uses relevant network information when deciding how
   execution proceeds and which endpoints are used.  The network then
   establishes or updates the communication relationships required by
   those decisions, and the related network state may also change over
   time.  This document focuses on the network role in distributed
   execution and does not address task scheduling.  It describes the
   resulting network problems, representative scenarios, design
   considerations, and network requirements.  Appendix A gives a non-
   normative example.

2.  Scope

   This document considers network support for distributed computing in
   space networks, including multi-satellite cooperation, processing of
   data from multiple sources, multi-stage space-to-space-to-ground
   execution, and execution across space and terrestrial nodes.  It does
   not assume a particular execution model, such as pipelining, data
   parallelism, function parallelism, or sharding.

   A distributed execution uses multiple space or terrestrial execution
   endpoints, which are selected by the compute side for an execution
   stage.  A communication requirement describes the communication
   needed between selected execution endpoints.  A communication
   relationship is the network communication established or updated
   between selected endpoints to satisfy that requirement.  The compute
   side makes execution decisions, while the network side provides
   relevant network information and maintains the relationships required
   by those decisions.

Zhu & Li                  Expires 11 March 2027                 [Page 3]
Internet-Draft  Space Distributed Computing Requirements  September 2026

  +----------------------------+          +----------------------------+
  |        Compute Side        |          |        Network Side        |
  |                            |          |                            |
  | execution decision         |<---------| relevant network           |
  | endpoint selection         | network  | information                |
  |                            | info     |                            |
  |                            |--------->|                            |
  |                            | comm.    | communication              |
  |                            | req.     | relationships              |
  +----------------------------+          +----------------------------+

   This document does not specify how execution decisions are made.  The
   compute side may use centralized, distributed, hierarchical, hybrid,
   or other mechanisms to select participating nodes, choose execution
   endpoints, and change execution as needed.  Execution endpoints and
   communication requirements may be planned in advance or changed as
   execution progresses.

   This document covers:

   *  network information for evaluating whether the required
      communication can be supported;

   *  communication requirements created by execution decisions and the
      corresponding communication relationships;

   *  realization and readiness of communication relationships, their
      update under planned or unplanned changes, and limited
      continuation during temporary control loss; and

   *  locality, consistency, and lifecycle of network state.

   This document does not specify:

   *  compute-side task placement, splitting, scheduling, or
      optimization;

   *  routing, traffic engineering, connectivity prediction, or physical
      link establishment;

   *  migration or recovery of application execution state; or

   *  exposure of complete task or compute-platform interface to the
      network.

Zhu & Li                  Expires 11 March 2027                 [Page 4]
Internet-Draft  Space Distributed Computing Requirements  September 2026

3.  Problem Statement

3.1.  Distributed Execution Creates Multiple Communication Relationships

   Single-node execution usually communicates through one main execution
   endpoint.  Distributed execution replaces this pattern with multiple
   transfers and changing endpoints.  Input may be sent to several
   endpoints, intermediate results may transfer among them or to the
   next execution stage, and final results may go to another node or the
   ground.  The resulting communication relationships can be concurrent,
   sequential, or updated over time.  Some transfers may also share
   completion or timing requirements or depend on a specific order,
   which cannot always be represented by treating every flow
   independently.

3.2.  Reachability Does Not Ensure Communication Feasibility

   An execution endpoint may be reachable while the required
   communication is still infeasible.  The available connectivity time,
   bandwidth, latency, or reliability may not meet the requirement, or a
   known connectivity change may occur before the transfer can complete.
   Therefore, an execution decision needs more than reachability: it
   needs network information showing whether the communication can be
   supported over the relevant time period.

3.3.  Communication Requirements Need Network Realization

   An execution decision creates or changes a communication requirement,
   but the corresponding communication relationship still has to be
   realized by the network.  This may require changes to forwarding,
   resource allocation, protection, monitoring, or other network state,
   and the relationship may not be ready for use immediately.

3.4.  Communication Relationships Change Over Time

   Communication relationships may change because the compute side
   changes an execution decision or because planned or unplanned network
   conditions affect an existing requirement.  A network-side change can
   remain internal to the network if routing, protection, or other
   mechanisms can still satisfy the current requirement; otherwise,
   updated network information is needed for the compute side to re-
   evaluate the execution decision.

4.  Representative Distributed Execution Scenarios

   This section gives representative scenarios; it does not define an
   exhaustive classification of distributed computing models.

Zhu & Li                  Expires 11 March 2027                 [Page 5]
Internet-Draft  Space Distributed Computing Requirements  September 2026

4.1.  Multi-Source Data Aggregation

   Space data may be produced at different satellites or observation
   locations.  Instead of sending all raw data to one node, each source
   may perform local filtering, compression, feature extraction, or
   partial analysis and send the result to a later aggregation endpoint.

   Satellite A ---\
   Satellite B ----+---> Aggregation Node / Ground
   Satellite C ---/

   Suppose the next stage needs results from several sources before it
   can proceed.  This creates several related communication
   relationships toward the same aggregation endpoint, often over shared
   links or limited contact windows.  Each source may be reachable on
   its own, yet the aggregation can miss its completion or performance
   condition if one transfer arrives too late or the concurrent
   transfers exceed the available network resources.

4.2.  Multi-Node Parallel Processing

   The compute side may select several endpoints to process different
   data partitions or parts of the computation at the same time.

           +---> B ---+
   A ------+          +---> D
           +---> C ---+

   This creates a fork-and-join pattern of communication relationships:
   A-B and A-C may be active during input distribution, while B-D and
   C-D appear as the parallel work completes.  The active relationships
   and their traffic demand can therefore change during the same task,
   rather than remain as one fixed relationship with stable demand.

4.3.  Multi-Stage Execution

   Different execution stages may be better suited to different
   endpoints; for example, Satellite A may perform preprocessing,
   Satellite B may perform later analysis, and Ground C may perform more
   complex computation or long-term storage.

   Satellite A ---> Satellite B ---> Ground C

Zhu & Li                  Expires 11 March 2027                 [Page 6]
Internet-Draft  Space Distributed Computing Requirements  September 2026

   The communication relationship changes when execution moves from one
   stage to the next.  After the compute side selects the next endpoint,
   it provides a new communication requirement and the network
   establishes or updates the corresponding relationship.  If the new
   relationship is not ready when the intermediate result must be
   transferred, the next stage is delayed even though endpoint selection
   is complete.

4.4.  Planned and Unplanned Relationship Changes

   Suppose a connection used by a current communication relationship is
   scheduled to end.  The network can expose this change before the
   relationship is affected, giving the compute side time to decide
   whether execution should change and, if a new requirement follows,
   giving the network time to prepare the next relationship.

   If the connection instead fails unexpectedly, routing, protection, or
   other internal mechanisms may keep the current requirement satisfied
   without changing execution.  If they cannot, the network reports the
   change to the compute side, and a later execution decision may
   produce a new communication requirement and relationship.

5.  Design Considerations for Network Support of Distributed Execution

   This section discusses what information crosses the compute-network
   boundary, how the network turns communication requirements into
   communication relationships, and how those relationships are
   maintained as execution and connectivity change.

   The overall interaction considered in this section is illustrated
   below.

Zhu & Li                  Expires 11 March 2027                 [Page 7]
Internet-Draft  Space Distributed Computing Requirements  September 2026

                    +----------------------+
                    |     Compute Side     |
                    |                      |
                    |  execution decision  |
                    +----^------------+----+
                         |            |
                         |            | communication
           network       |            | requirement
           information   |            |
                         |            v
                         |
   +---------------------+-----------------------------+
   |                   Network Side                    |
   |                                                   |
   |  information exposure                             |
   |  communication relationship                       |
   |  realization and readiness                        |
   +--------------------------+------------------------+
                              |
                        network change
                              |
                  can the requirement
                      still be met?
                        /        \
                      yes         no
                       |           |
             network-internal      |
                handling           |
                       |           |
             relationship       updated network
               continues          information
                                    |
                                    v
                                 Compute Side

   Relationship state: Locality | Consistency | Lifecycle

5.1.  Information Exposure and Abstraction

   Network information for an execution decision can come from current
   observations, known planned connectivity, or information derived from
   them.  This information should be available when the compute side
   evaluates candidate execution endpoints or assesses whether the
   required communication is feasible.  It may be provided through pull,
   push, subscription, or other mechanisms.  The information should also
   be updated proactively when a known or detected change may affect
   current or candidate communication.  The information can be raw, such
   as link conditions or contact schedules; aggregated, such as the

Zhu & Li                  Expires 11 March 2027                 [Page 8]
Internet-Draft  Space Distributed Computing Requirements  September 2026

   usable interval or path conditions between two endpoints; or
   requirement-specific, such as whether a requested transfer can be
   supported.  This document does not define a particular metric,
   representation, or information model.

   The information should be detailed enough to evaluate the
   communication requirement, but no more detailed than needed.  A
   transfer may depend on data volume, completion time, bandwidth,
   latency, reliability, or remaining connectivity time, so the decision
   may need more than just a reachability result.  Besides, the compute
   side does not need the complete network topology, routing state, all
   link measurements, or future connectivity outside the relevant time
   range.  The network likewise does not need the complete task graph,
   all execution stages, or application state.  When timing matters,
   network information should cover the relevant time period and be
   updated when later network changes make information no longer
   applicable.

5.2.  Communication Requirement Expression

   Network information can influence an execution decision; the compute
   side decides which endpoints are used and whether execution changes.
   The resulting communication is then expressed to the network as a
   communication requirement.  A communication requirement can describe
   the selected endpoints, the data or results to be transferred, the
   data volume when relevant, and the timing and performance
   requirements.  Distributed execution may create several related
   transfers, and their relation only needs to be expressed when it
   affects network feasibility or handling, for example when the
   transfers must complete together, follow a certain order, or allow
   alternative completion.  Otherwise, these execution semantics can
   remain inside the compute side.

5.3.  Communication Relationship Realization and Readiness

   The network uses a communication requirement to establish or update
   the corresponding communication relationship.  Depending on the
   requirement, the relationship may involve forwarding, resource
   allocation, protection, monitoring, or other network state.  An
   execution change does not necessarily require all of these mechanisms
   or state to change.

   An execution decision does not mean that the required communication
   is immediately ready for use.  In a space network, the required
   connectivity may only become available during a later contact window,
   and the network may also need to install or adjust the state needed
   for the relationship.  Even after communication becomes ready,
   satellite motion may change the available connectivity time, path

Zhu & Li                  Expires 11 March 2027                 [Page 9]
Internet-Draft  Space Distributed Computing Requirements  September 2026

   conditions, or link availability.  The compute side therefore needs
   to know when the communication is ready and when later network
   changes prevent the current communication requirement from being met.

5.4.  Planned and Unplanned Changes

   Communication relationships can change because of compute-side
   execution changes or network-side connectivity changes, and either
   type can be planned or unplanned.  When the compute side changes an
   execution endpoint, it provides the resulting communication
   requirement to the network, which establishes or updates the
   corresponding relationship.

   For a planned network change, the network can provide relevant
   information before the current relationship is affected.  The compute
   side decides whether execution should change; if it provides a new
   communication requirement, the network can prepare the new
   relationship in advance.  For an unplanned network change, the
   network should first use routing, protection, or other internal
   mechanisms if they can still satisfy the existing requirement.  A
   path or topology change alone does not require execution re-
   evaluation.  If the requirement can no longer be met, the network
   reports the change to the compute side, which can make a new
   execution decision and provide a new requirement if needed.

   Connectivity to a ground-based or central decision mechanism may also
   be lost temporarily.  Existing authorized communication relationships
   can continue when installed network state and available connectivity
   allow it, but the network does not make a new execution decision for
   the compute side.  When control connectivity returns, relevant
   network and relationship state may need to be synchronized before
   later decisions use it.

5.5.  State Management under Network Dynamics

   Relationship-related state may be distributed across multiple network
   locations and may change as execution and connectivity evolve.
   Requiring every change to be synchronized immediately across the
   whole network would create substantial signaling and state-management
   overhead, especially when many communication relationships change
   independently.  In a space network, intermittent and time-varying
   connectivity can also prevent all locations from receiving the same
   update at the same time.  Updates may therefore be delayed,
   reordered, missed, or applied against different state versions.  The
   resulting problem is not simply how to synchronize state, but which
   network scope needs each update, how consistent distributed state
   needs to be for the current communication relationship, and how long
   old and new state may coexist before obsolete state affects

Zhu & Li                  Expires 11 March 2027                [Page 10]
Internet-Draft  Space Distributed Computing Requirements  September 2026

   operation.

   These conditions create three design concerns.  *Locality* limits
   state propagation to the part of the network that needs the state.
   *Consistency* prevents stale or conflicting versions from affecting
   an active relationship.  *Lifecycle* ensures that state is created,
   updated, and removed with the relationship, including temporary
   coexistence during planned transitions.

6.  Network Requirements

   This section derives the network requirements from the preceding
   design considerations.  It does not define a protocol, information
   model, or control architecture.

6.1.  Network Information for Execution Decisions

   The network should make relevant observed, planned, or derived
   information available to the compute side.  The information should be
   available when needed for a decision and updated when a network
   change makes earlier information no longer applicable.  It may be
   raw, aggregated, or requirement-specific.  It should be sufficient to
   evaluate reachability, path conditions, bandwidth, latency,
   reliability, usable connectivity time, and relevant current or
   planned changes.  When timing affects feasibility, it should also
   cover the relevant time period without exposing complete network
   state.

6.2.  Distributed Communication Requirement Expression

   After an execution decision creates or changes the required
   communication, the compute side should provide the corresponding
   communication requirement to the network.  The requirement can
   describe the selected endpoints, the data or results to be
   transferred, data volume, and timing or performance needs.  It can
   also describe relations among multiple transfers when network
   feasibility or handling depends on whether they complete together,
   follow an order, or allow alternatives.  The network does not need
   the complete task graph, execution logic, or application state and
   should not have to infer these relations from individual flows.

Zhu & Li                  Expires 11 March 2027                [Page 11]
Internet-Draft  Space Distributed Computing Requirements  September 2026

6.3.  Communication Relationship Realization and Readiness

   The network should establish or update the communication relationship
   described by the requirement.  It should install or adjust the
   forwarding, resource, protection, monitoring, or other state needed
   by that relationship.  The compute side should know when
   communication is ready for use and whether current network conditions
   still satisfy the communication requirement.

6.4.  Communication Relationship Updates and Feedback

   When a compute-side decision changes the communication requirement,
   the network should establish, modify, or end the corresponding
   communication relationship.  For a planned network change, relevant
   information should be available before the current relationship is
   affected.  If a new requirement arrives early enough and connectivity
   allows, the network should be able to prepare the next relationship
   in advance.

   An unplanned network change should not trigger execution re-
   evaluation if network-internal mechanisms can still satisfy the
   current communication requirement.  If they cannot, the network
   should report the change to the compute side and update the
   relationship after any new communication requirement is received.

   Existing authorized communication relationships should be able to
   continue during temporary loss of ground or central control
   connectivity when installed state and available connectivity permit.
   Relevant state should be synchronized after control connectivity
   returns.  This continuation concerns network communication only and
   does not guarantee application execution continuity, checkpoint
   recovery, or task-scheduling continuity.

6.5.  State Locality, Consistency, and Lifecycle

   Relationship-related state, notifications, and updates should satisfy
   the following properties:

   *  *Locality:* State and updates should remain within the network
      scope affected by the communication relationship, while still
      reaching the endpoints and network mechanisms involved in its
      update or transition.

   *  *Consistency:* State maintained at multiple locations should
      remain consistent enough for the current communication
      relationship, and obsolete or conflicting state should not affect
      its operation.

Zhu & Li                  Expires 11 March 2027                [Page 12]
Internet-Draft  Space Distributed Computing Requirements  September 2026

   *  *Lifecycle:* State should be created, updated, and removed with
      the communication relationship.  Old and new state may coexist
      during a planned transition, but obsolete state should be removed
      after the relationship or transition ends.

7.  Security Considerations

   This document does not define a security protocol.

   TBD

8.  IANA Considerations

   This document makes no requests of IANA.

Appendix A.  Example of Network Support for an Evolving Distributed
             Execution

   This appendix gives a non-normative example of how the preceding
   network requirements may appear together during one distributed
   execution.  It does not define a protocol, message format, or control
   architecture.

   Assume that distributed execution E completes one processing stage at
   Satellite A, and the compute side is considering Satellite B and
   Satellite C as the next execution endpoint.  The network provides
   information for A-B and A-C.  The example uses an aggregated view,
   although raw network information could also be used.

   Execution E

   A -> B:
     reachable
     remaining connectivity time: 25 s

   A -> C:
     reachable
     remaining connectivity time: 80 s

   If the intermediate result requires about 40 seconds to transfer, A-B
   is reachable but does not remain available long enough.  A-C provides
   enough time.  The compute side combines this network information with
   information about computing resources, data location, and execution
   progress and selects C as the next execution endpoint.

   The compute side then provides the A-C communication requirement,
   including the selected endpoints and relevant transfer and timing
   requirements.  The network establishes the A-C communication

Zhu & Li                  Expires 11 March 2027                [Page 13]
Internet-Draft  Space Distributed Computing Requirements  September 2026

   relationship and installs the state needed for it.  Once the
   relationship is ready for use, the intermediate result can be
   transferred to C.

   Later, suppose planned network information shows that a connection
   used by C will become unavailable in 60 seconds.  The compute side
   can use this information when selecting the next execution endpoint.
   If it selects Satellite D, it provides a C-D communication
   requirement, and the network can prepare the C-D relationship before
   the current one becomes unusable.

   The relationships may therefore evolve as execution progresses:

   Execution E

   A -> C
      |
      | execution progresses
      v
   C -> D
      |
      | later stage
      v
   D -> Ground G

   The sequence can be planned in advance or changed as execution
   progresses.  The network does not need the complete task structure;
   it only needs the communication requirements for the relationships it
   maintains.

   If an unexpected network failure affects a current relationship, the
   network first tries routing, protection, or other internal
   mechanisms.  If they still satisfy the existing communication
   requirement, the relationship continues without a new execution
   decision.  Otherwise, the network reports the change to the compute
   side.  Any new execution decision can then produce a new
   communication requirement, and the network updates the corresponding
   relationship.

   In a large satellite network carrying many such executions, network
   state and updates should stay within the necessary scope.  The state
   should remain consistent enough for active relationships and be
   removed when those relationships end.

Authors' Addresses

   Mengfei Zhu
   China Mobile

Zhu & Li                  Expires 11 March 2027                [Page 14]
Internet-Draft  Space Distributed Computing Requirements  September 2026

   Email: zhumengfei@cmdi.chinamobile.com

   Qing Li
   Beijing University of Posts and Telecommunications
   Email: qingli@bupt.edu.cn

Zhu & Li                  Expires 11 March 2027                [Page 15]