]> China Mobile

zhumengfei@cmdi.chinamobile.com

Beijing University of Posts and Telecommunications

qingli@bupt.edu.cn

IRTF Systems and Protocol Aspects for Circumstellar Environments distributed computing space network satellite network communication relationship network requirements 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.

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.

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. | | | | 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.

Problem Statement

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.

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.

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.

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.

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

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. 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.

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.

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 B ---> Ground C ]]> 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.

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.

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.

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 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.

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.

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 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.

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.

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 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.

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

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.

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.

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.

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.

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.
• 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.

Security Considerations This document does not define a security protocol. TBD

IANA Considerations This document makes no requests of IANA.

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. 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 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: 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.