| Internet-Draft | Disruption-Aware Task Descriptors | July 2026 |
| Liu & Liu | Expires 19 January 2027 | [Page] |
Compute tasks in heterogeneous edge environments may traverse terrestrial, maritime, airborne, and non-terrestrial domains before an eligible execution site becomes reachable. Conventional request formats often assume an immediately selected endpoint and a continuously available request-response path. Those assumptions are fragile when connectivity is intermittent, service instances move, inputs are named and distributed, and duplicate delivery can occur.¶
This document describes a problem statement, a conceptual compute-task descriptor, and requirements for carrying a portable task description across disruption-prone edge networks. The descriptor separates the identity and semantics of a task from a particular execution location. It binds the requested service, named inputs, relevant parameters, timing constraints, authorization policy, and expected result properties while supporting store-carry-forward operation, duplicate suppression, verifiable execution receipts, and result provenance. This document does not define a wire encoding, task-placement algorithm, traffic-steering protocol, or execution runtime.¶
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 19 January 2027.¶
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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC7927] [RFC8793]. IoT edge systems require resilience to intermittent services as well as privacy and security [RFC9556]. Delay-tolerant networking provides store-carry-forward delivery when continuous end-to-end paths do not exist [RFC9171]. 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:¶
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.¶
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
These key words describe requirements for a future task-description design. They do not require a particular syntax, transport, or implementation architecture.¶
The target environment has one or more of the following characteristics:¶
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:¶
A portable task descriptor addresses these semantic questions. It does not replace transport, service discovery, task placement, or traffic steering.¶
This document focuses on the information carried by or referenced from a compute-task descriptor. It considers the following functions:¶
The following topics are out of scope:¶
The conceptual model contains the following entities:¶
A compute-task descriptor conceptually contains a descriptor core and optional transit metadata.¶
The descriptor core contains some subset of the following 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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
The following workflow is illustrative and does not specify a protocol:¶
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.¶
ICN research has examined location-independent naming, caching, object security, mobility, and deployment considerations [RFC7927] [RFC8763]. CCNx defines Interest and Content Object semantics and a TLV message format [RFC8569] [RFC8609]. ICN terminology is documented in [RFC8793].¶
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.¶
[RFC9556] 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.¶
CATS defines a framework for selecting a suitable service contact instance using network and computing information [I-D.ietf-cats-framework]. Its problem statement and requirements focus on steering service traffic among distributed service sites [I-D.ietf-cats-usecases-requirements].¶
The Compute-Aware Task Placement and Traffic Steering framework jointly considers execution location and input/output traffic under compute and network constraints [I-D.luan-cats-catpts]. 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.¶
Bundle Protocol Version 7 supports store-carry-forward communication in disruption-tolerant environments [RFC9171], and BPSec provides integrity and confidentiality services for Bundle Protocol exchanges [RFC9172]. 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.¶
[I-D.liu-icnrg-cross-domain-compute-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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
This document has no IANA actions.¶
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.¶