Requirements for Disruption-Aware Compute-Task Descriptors in Heterogeneous Space-Terrestrial-Maritime Edge Networks

Introduction Edge computing allows data to be processed near users and data sources. In many deployments, an application sends a request to a selected endpoint, waits for that endpoint to execute the requested function, and receives a response over the same or a continuously available path. This interaction model is effective when service instances and network paths remain stable for the duration of the transaction. Heterogeneous space-terrestrial-maritime edge systems can violate these assumptions. A sensor platform may reach a buoy gateway only intermittently. A maritime gateway may contact a low-Earth-orbit node during a finite visibility window. A task may then be forwarded to a terrestrial edge site or cloud service after a later contact. The execution site may not be known when the task is created, and the node carrying the task may not be the node that finally executes it. In such environments, a task needs a portable description that remains meaningful after forwarding, caching, replication, and delayed execution. The description needs to identify the requested logical service without binding the task to a temporary instance. It also needs to identify the input objects, parameters, acceptable execution context, timing constraints, security policy, and expected result. Because retransmission and multi-path forwarding can create duplicates, the description also needs an identity and idempotency semantics that allow safe duplicate detection. Information-Centric Networking (ICN) provides concepts for naming information independently of host location, caching named objects, and applying object-level integrity protection . IoT edge systems require resilience to intermittent services as well as privacy and security . Delay-tolerant networking provides store-carry-forward delivery when continuous end-to-end paths do not exist . These concepts motivate a task description that can be treated as a portable, verifiable object rather than only as transient application data on an established connection. This document is requirements-oriented. It identifies properties expected of a future compute-task descriptor, including:

a stable task identity and a stable binding to a logical computing service;
verifiable references to named input objects and expected output properties;
explicit creation time, expiration, deadline, freshness, and retry semantics;
operation during partitions and across store-carry-forward paths;
duplicate suppression and idempotent execution where applicable;
result-to-task binding, provenance, and execution receipts;
cross-domain authorization, confidentiality, and policy-controlled disclosure; and
incremental use over existing IP, ICN, and disruption-tolerant infrastructures.

The space-terrestrial-maritime scenario is used as a motivating example. The requirements may also apply to disaster-response networks, remote industrial systems, mobile edge deployments, and other environments in which execution cannot be coupled to a continuously reachable endpoint. This document does not define a universal serialization, a remote procedure call interface, a programming model, a task-placement algorithm, a traffic-steering mechanism, a transport protocol, or a general workflow language.

Terminology

Requirements Language 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 when, and only when, they appear in all capitals, as shown here. These key words describe requirements for a future task-description design. They do not require a particular syntax, transport, or implementation architecture.

Definitions

Computing Service:: A logical function that consumes one or more inputs and produces one or more outputs. The service may be implemented by multiple service instances at different sites.
Compute Task:: A request to apply a specified computing service, version, and parameter set to specified inputs under stated timing, policy, and result constraints.
Compute-Task Descriptor:: A portable description of a compute task. It binds the task identity to the requested service, inputs, parameters, timing constraints, authorization policy, and expected result properties without requiring a final execution locator.
Descriptor Core:: The integrity-protected portion of a compute-task descriptor whose semantics are established by the task originator and are not changed by transit nodes.
Transit Metadata:: Information added or updated while a task is forwarded, such as hop observations, custody state, local priority, or contact hints. Transit metadata is not part of the originator-defined task semantics unless explicitly incorporated by reference.
Task Originator:: The entity that creates and authorizes a compute task.
Task Carrier:: A node that stores, forwards, replicates, or otherwise transports a compute-task descriptor or its referenced objects.
Execution Site:: A site at which an eligible service instance executes a compute task.
Task Identifier:: A stable identifier for a compute task. It is used to correlate descriptor copies, execution receipts, failures, and result objects.
Idempotency Key:: A value used by an execution site to recognize requests that are intended to represent the same logical invocation and to suppress or safely handle duplicate execution.
Input Object:: A named data, model, configuration, or other object consumed by the requested service.
Result Object:: A named output generated by executing a compute task and bound to the task identifier, service version, input identities, and relevant execution context.
Execution Receipt:: An integrity-protected statement indicating that a task was accepted, completed, rejected, cancelled, or failed, together with sufficient information to correlate the statement with the task.
Deadline:: The latest time at which a result remains useful according to the task originator or application policy.
Descriptor Lifetime:: The period during which the descriptor may be stored, forwarded, or considered for execution. The descriptor lifetime can differ from the task deadline.

Problem Statement and Scope

Target Characteristics The target environment has one or more of the following characteristics:

Unknown execution location: The task is created before an eligible execution site is selected or reachable.
Intermittent connectivity: A continuous path from the task originator to an execution site and back cannot be assumed.
Multiple carriers: Gateways, mobile nodes, satellites, or caches may store and forward the task or its referenced inputs.
Distributed inputs: Input data, models, and configuration objects may reside at different locations and may become reachable at different times.
Dynamic service placement: Service instances can start, stop, move, or be replaced while the task is in transit.
Duplicate delivery: Retransmission, replication, or route convergence may deliver the same task to an execution site more than once.
Multiple administrative domains: Task metadata, inputs, and results can cross domains with different trust anchors and disclosure policies.
Resource constraints: Contacts, storage, energy, and processing resources may be limited.

Limitations of Endpoint-Bound Requests An endpoint-bound request normally identifies a destination before transmission. Connection state, transport-level request identifiers, and application session state may then be used to correlate the response. This model becomes fragile when the endpoint is not yet known, a connection cannot remain open, or an intermediate node must retain the task for later forwarding. Copying an ordinary application request into a store-carry-forward payload does not by itself define:

whether two copies represent the same logical task;
which parts of the request may be modified by transit nodes;
how named inputs and service versions are bound to the task;
whether the task may still be executed after a deadline or expiration;
whether duplicate execution is safe;
how a result is cryptographically bound to the original task; or
which domain is authorized to inspect, forward, execute, or retrieve the result.

A portable task descriptor addresses these semantic questions. It does not replace transport, service discovery, task placement, or traffic steering.

Scope This document focuses on the information carried by or referenced from a compute-task descriptor. It considers the following functions:

identifying a logical task and the requested computing service;
binding named inputs, parameters, and expected outputs;
expressing execution eligibility, timing, retry, and disclosure policy;
supporting storage and forwarding during disruption;
detecting duplicate task delivery and correlating task state;
binding results and execution receipts to the originating task; and
preserving integrity and provenance across gateways and caches.

Non-Goals The following topics are out of scope:

defining a wire encoding or media type;
standardizing a programming language, executable format, or container format;
selecting an execution site or ranking candidates;
defining traffic steering, routing, congestion control, or contact planning;
reserving computing, storage, energy, or bandwidth resources;
guaranteeing exactly-once execution in a partitioned distributed system;
defining application-specific equivalence among inputs or results; and
standardizing underwater, satellite, radio, acoustic, or optical link technologies.

Conceptual Model

Entities The conceptual model contains the following entities:

Task originators create descriptors and specify the requested service, inputs, constraints, and policy.
Discovery functions identify logical services, candidate instances, or reusable results. Discovery may occur before or after task creation.
Task carriers store, forward, replicate, or translate descriptors and referenced objects.
Execution sites evaluate eligibility, obtain required inputs, execute tasks, and produce results or failure receipts.
Result stores retain named results and execution receipts for later retrieval.
Trust services provide credentials, authorization information, revocation status, or trust anchors used to validate descriptors, inputs, and results.

Descriptor Structure A compute-task descriptor conceptually contains a descriptor core and optional transit metadata. The descriptor core contains some subset of the following information:

a task identifier and, where needed, an idempotency key;
the task originator and the authority under which the task is issued;
a stable logical service identifier and service or interface version;
immutable references or digests for required input objects;
invocation parameters and properties that affect result semantics;
expected output type, result naming information, or validation constraints;
creation time, descriptor lifetime, deadline, freshness bounds, and retry policy;
execution eligibility constraints, such as trusted domains or required capabilities;
authorization and disclosure policy; and
integrity-protection and provenance information.

Transit metadata may contain forwarding observations, local custody state, locally assigned priority, contact hints, or diagnostic information. A future design needs to distinguish transit metadata from originator-defined semantics so that forwarding nodes cannot silently alter the task.

Conceptual Task States A task may move through conceptual states such as created, in transit, accepted, executing, completed, failed, rejected, expired, or cancelled. These states are descriptive and do not mandate a state machine. A deployment may expose fewer states, but state reports need to be unambiguously correlated with the task identifier and the reporting authority. Different nodes can temporarily have different views of the same task. For example, a carrier may still retain a copy after another copy has completed elsewhere. Therefore, a state report is evidence from a particular source and time, not necessarily a globally synchronized truth.

Separation from Discovery, Placement, and Transport Service discovery determines which services, instances, or results exist. Task placement selects an execution site. Traffic steering and routing determine how data reaches a selected site. Transport or store-carry-forward mechanisms move descriptors and objects. The compute-task descriptor supplies portable task semantics to these functions but does not replace them. A descriptor may be created before discovery, after discovery of a logical service, or after selection of one or more candidate instances. Even when a candidate instance is included as a hint, the logical task identity and requested service remain independent of that temporary locator.

Use Cases

Maritime Event Analysis An autonomous underwater vehicle records an observation that requires anomaly analysis. It creates, or asks a buoy gateway to create, a task descriptor referencing the named observation, the requested analysis service, the model or service version, a deadline, and an authorization policy. No eligible execution site is continuously reachable. The descriptor and observation are transferred to a buoy during a short contact. The buoy later forwards them to a satellite or terrestrial edge site. An eligible site executes the task and stores a named result. The result can be returned during a later contact because it is bound to the original task identifier and inputs rather than to the connection over which the request was first sent.

Opportunistic Non-Terrestrial Execution A maritime gateway knows that a low-Earth-orbit node may become available during an upcoming visibility window but cannot assume that the contact will occur or last long enough. The gateway forwards a task descriptor that identifies an acceptable service version, input-size limit, deadline, and result policy. If the satellite accepts and completes the task, it returns an execution receipt and result reference. If the contact ends before execution or result transfer, another carrier may later forward the same descriptor. The idempotency information allows an execution site to determine whether the task has already been accepted or completed.

Delayed Batch Preprocessing A remote sensing site generates many low-priority preprocessing tasks. The tasks can be executed locally, on a visiting mobile edge node, or after bulk transfer to a terrestrial site. Each descriptor expresses a lifetime, a deadline, permitted execution domains, and references to the relevant input objects. Carriers can retain the descriptors during a partition and forward them when capacity is available. Expired tasks are not executed merely because a stale copy remains in a cache. Completed results are correlated with the original tasks even when they return along a different path.

Duplicate Delivery after a Partition Two gateways obtain copies of the same task before their domains become partitioned. Each forwards its copy toward a different execution site. One site completes the task while the other receives a delayed duplicate. The delayed site uses the task identifier and idempotency policy to avoid an unsafe second execution or to return a previously generated result reference. This use case illustrates why transport-level request identifiers are insufficient: the duplicate may arrive over a different protocol, path, or administrative domain.

Requirements

Task Identity and Service Binding R1 - Stable task identity: A descriptor design MUST provide a stable task identifier that remains unchanged when the descriptor is copied, cached, forwarded, or transported by different protocols. R2 - Service and location separation: The descriptor MUST identify the requested logical computing service separately from any service-instance identifier or locator. R3 - Immutable originator semantics: The design MUST distinguish an integrity-protected descriptor core from metadata that may be added or changed by transit nodes. R4 - Version binding: The descriptor MUST identify the service and interface version. When execution semantics depend on a model, executable, configuration, or policy artifact, the descriptor SHOULD bind an immutable identifier or digest for that artifact. R5 - Origin authority: A relying party MUST be able to determine which authority created or authorized the task and whether that authority is permitted to request the named service.

Inputs, Outputs, and Execution Context R6 - Named inputs: Required input objects MUST be identified by immutable names, cryptographic digests, or an equivalent mechanism that permits verification of the exact inputs used. R7 - Input roles: The descriptor SHOULD distinguish required, optional, and alternative inputs and identify the role of each input in the invocation. R8 - Parameters: Parameters that affect result semantics MUST be included in the descriptor core or bound through a verifiable manifest. R9 - Output expectations: The descriptor SHOULD identify the expected output type, validation constraints, result naming rule, or a verifiable reference to such information. R10 - Execution context: When result validity depends on geographic scope, observation time, precision, hardware class, trusted execution environment, or other execution context, the descriptor MUST express the relevant requirement or bind it through a verifiable reference. R11 - Defined resource semantics: Resource requirements or preferences MUST NOT be compared across domains unless their semantics, units, and measurement scope are defined. Candidate ranking remains outside the descriptor.

Timing and Disruption Awareness R12 - Creation and validity: A descriptor MUST include sufficient information to determine its creation time and descriptor lifetime. R13 - Deadline separation: The design MUST distinguish the time until which the descriptor may be forwarded from the deadline after which executing or returning the result is no longer useful. R14 - Freshness bounds: When input or result age affects usefulness, the descriptor MUST support an explicit freshness bound or revalidation policy. R15 - Store-carry-forward eligibility: The descriptor SHOULD indicate whether it may be stored, carried, replicated, or forwarded after immediate delivery fails. R16 - Contact uncertainty: Contact or reachability hints, when included, MUST carry a source and validity indication and MUST NOT be represented as a guarantee of execution. R17 - Offline evaluation: An execution site SHOULD be able to evaluate basic task eligibility, expiration, integrity, and authorization from locally available information when a remote control service is unreachable. R18 - Bounded descriptor size: The design SHOULD support references, manifests, selective disclosure, or compact representations so that constrained contacts are not consumed by unnecessary inline metadata.

Duplicate Handling and Lifecycle R19 - Duplicate correlation: A receiving node MUST be able to determine whether two descriptor copies refer to the same task identity. R20 - Idempotency semantics: The design MUST support an idempotency key or equivalent policy when duplicate execution could cause inconsistent state, repeated side effects, or unnecessary resource consumption. R21 - No implicit exactly-once guarantee: A descriptor design MUST NOT claim exactly-once execution solely from duplicate suppression. The application or service needs to define the consequences of retries and uncertain completion. R22 - State correlation: Acceptance, progress, completion, rejection, cancellation, expiration, and failure reports MUST be unambiguously correlated with the task identifier and reporting authority. R23 - Retry policy: The descriptor SHOULD support a bounded retry policy or a reference to application policy, including whether retries may occur at another execution site. R24 - Cancellation and supersession: A design SHOULD support an authenticated indication that a task is cancelled, superseded, or no longer eligible. Disconnected nodes may not receive the indication immediately; that limitation MUST be visible to the relying party.

Results and Execution Receipts R25 - Result-to-task binding: A result object MUST be bound to the task identifier, requested service version, input identities, and parameters that affect result semantics. R26 - Result provenance: A requester MUST be able to verify which service or authorized execution environment produced a result. R27 - Completion receipt: A design SHOULD support an integrity-protected completion receipt containing the task identifier, result reference or digest, completion time, and producing authority. R28 - Failure receipt: A design SHOULD support an integrity-protected rejection or failure receipt that distinguishes policy rejection, invalid input, expiration, unsupported service version, unavailable resources, and execution failure where disclosure policy permits. R29 - Path independence: Retrieval of a result or receipt MUST NOT require use of the same path, connection, carrier, or protocol over which the task was submitted.

Trust, Authorization, and Privacy R30 - Descriptor integrity: The descriptor core MUST be integrity protected and attributable to the task originator or an authorized delegate. R31 - Separate authorization decisions: Authorization to inspect a descriptor, retrieve an input, forward a task, execute a service, and retrieve a result MUST be expressible as separate decisions. R32 - Confidentiality: A design SHOULD support confidentiality for sensitive task parameters, input references, policies, and result references. R33 - Disclosure minimization: The descriptor SHOULD permit policy-controlled or selective disclosure so that a carrier does not receive execution details that it does not need. R34 - Replay resistance: A relying party MUST be able to detect or limit replay of expired, cancelled, superseded, or already completed tasks. R35 - Delegation: When an intermediary creates, modifies, or submits a task on behalf of another entity, the design MUST make the delegation and resulting authority verifiable. R36 - Auditability: Implementations SHOULD expose sufficient diagnostics to determine the descriptor source, validation outcome, state-report source, selected service version, and result binding without revealing protected metadata.

Incremental Deployment and Extensibility R37 - Infrastructure independence: The abstract descriptor model SHOULD NOT require every participating node to use native ICN forwarding or a disruption-tolerant transport. R38 - Gateway preservation: A gateway translating among IP application protocols, ICN objects, and store-carry-forward transports MUST NOT silently discard task identity, validity, input binding, authorization, or provenance information. R39 - Partial participation: A deployment SHOULD provide useful operation when only gateways and execution sites understand the complete descriptor and constrained originators use a reduced profile. R40 - Functional separation: The descriptor interface SHOULD supply portable task semantics without mandating a particular service-discovery, placement, scheduling, routing, or traffic-steering system. R41 - Extensibility: The descriptor model MUST support new optional attributes and service-specific extensions. Unknown optional attributes SHOULD be safely ignored, while unknown critical attributes MUST cause the task to be rejected or left unexecuted.

Illustrative Workflow The following workflow is illustrative and does not specify a protocol:

The originator creates a task identifier and descriptor core, binds the requested service, inputs, parameters, timing constraints, and policy, and applies integrity protection.
A local discovery function may return candidate service instances or reusable results. The descriptor remains valid even if no candidate is currently reachable.
A carrier stores and forwards the descriptor and required objects. The carrier may add separately protected transit metadata but does not alter the descriptor core.
An execution site validates the task, checks expiration and authorization, resolves required inputs, and evaluates whether its service version and capabilities satisfy the descriptor.
The execution site checks the task identifier and idempotency policy against local or synchronized task state.
The site accepts, rejects, or executes the task. It produces an execution receipt and, on completion, a result object bound to the task and inputs.
The result or receipt is stored and returned over any available path. The originator verifies provenance and task binding before accepting it.

A realization may combine, omit, or reorder these steps. For example, input objects may be transferred before the descriptor, and result discovery may locate a previously completed equivalent task. The requirements in this document focus on preserving semantics across such variations.

Relationship with Existing Work

Information-Centric Networking ICN research has examined location-independent naming, caching, object security, mobility, and deployment considerations . CCNx defines Interest and Content Object semantics and a TLV message format . ICN terminology is documented in . A future realization could represent a task descriptor, its inputs, execution receipts, and results as named content objects. This document does not modify ICN forwarding semantics or define a new name syntax.

IoT Edge Computing describes IoT edge challenges and functions, including time sensitivity, data volume, connectivity cost, resilience to intermittent services, privacy, and security. This document focuses more narrowly on the portable description and lifecycle semantics of an individual compute task.

Computing-Aware Traffic Steering and Task Placement CATS defines a framework for selecting a suitable service contact instance using network and computing information . Its problem statement and requirements focus on steering service traffic among distributed service sites . The Compute-Aware Task Placement and Traffic Steering framework jointly considers execution location and input/output traffic under compute and network constraints . This document is complementary: it does not select a site or optimize a path. It specifies requirements for the task information that remains meaningful before, during, and after such selection, including during disruption.

Delay-Tolerant Networking Bundle Protocol Version 7 supports store-carry-forward communication in disruption-tolerant environments , and BPSec provides integrity and confidentiality services for Bundle Protocol exchanges . A compute-task descriptor may be carried as a Bundle Protocol payload, but this document neither requires nor modifies Bundle Protocol. Transporting a task through a disruption-tolerant network does not by itself define task identity, duplicate execution behavior, input binding, or result provenance. Those are the descriptor semantics addressed here.

Cross-Domain Compute-Service Discovery identifies requirements for name-based discovery of logical services, service instances, and reusable results in heterogeneous space-terrestrial-maritime edge networks. That work asks what service or result is available. This document asks how a specific task is described and carried when the execution location and return path may not yet be known.

Security Considerations A portable compute-task descriptor can cause processing, data access, and state changes across multiple domains. A protocol realization needs a complete threat model and concrete mechanisms for integrity, confidentiality, authentication, authorization, replay resistance, and resource control.

Forged or Modified Tasks An attacker could change the requested service, inputs, parameters, deadline, or result destination. The descriptor core therefore needs end-to-end integrity protection and origin authorization. A gateway must not replace the originator's protection with an unauthenticated local assertion.

Replay and Duplicate Execution Replaying a valid task can waste scarce resources or repeat side effects. Task identifiers, lifetimes, idempotency policy, completion state, and authenticated cancellation or supersession information can limit replay. Duplicate suppression does not prove that exactly one execution occurred, especially during partitions. Applications with non-idempotent effects require stronger transactional or compensating mechanisms outside this document.

Resource Exhaustion Attackers can submit expensive tasks, excessively large descriptors, unresolved input references, or tasks designed to trigger repeated validation and forwarding. Implementations should apply admission control, quotas, bounded descriptor and manifest sizes, rate limits, inexpensive rejection of malformed tasks, and policy limits on storage, replication, retries, and execution cost.

Input and Artifact Substitution A valid task can produce an incorrect result if a carrier or execution site substitutes input data, model artifacts, configuration objects, or service versions. Immutable names, cryptographic digests, and result manifests need to bind all properties that affect execution semantics.

Forged Results and Receipts An attacker could claim completion, fabricate a failure, or substitute an unrelated result. Results and receipts require integrity protection, producing-authority authentication, task correlation, and binding to inputs and service version. A requester must not accept a result based only on a human-readable task or service name.

Privacy and Operational Confidentiality Descriptors can reveal sensor activity, locations, mission timing, requested algorithms, input identities, model versions, resource needs, and operational priorities. Even when input content is encrypted, names and metadata can enable traffic analysis. Deployments should minimize disclosed attributes and use confidentiality, access control, pseudonymous identifiers, or selective disclosure where appropriate.

Cross-Domain Trust and Gateways Authorization to forward a task does not imply authorization to inspect inputs or execute the task. Trust in one domain's identity does not automatically authorize every service request. Gateways are potential downgrade and policy-confusion points. When a target protocol cannot preserve a descriptor property, the gateway should report the limitation rather than silently claiming equivalent semantics.

IANA Considerations This document has no IANA actions.

Acknowledgements The authors welcome discussion on the scope of a portable compute-task descriptor, its relationship to service discovery and task placement, and suitable experimental realizations over IP, ICN, and disruption-tolerant infrastructures.