| Internet-Draft | Cross-Domain Compute Discovery | June 2026 |
| Liu | Expires 28 December 2026 | [Page] |
Future edge systems may span terrestrial infrastructure, maritime gateways, and non-terrestrial nodes such as low-Earth-orbit satellites. In these environments, a computing service, its executable instances, input data, and reusable results may be distributed across intermittently connected and resource-constrained nodes. This document describes a problem statement, an illustrative network model, and requirements for name-based discovery of computing services and reusable results. The objective is to separate stable service identity from temporary execution location while supporting disruption awareness, metadata authenticity, controlled result reuse, and incremental deployment over existing IP and Information-Centric Networking infrastructures. This document does not define a wire protocol, a naming syntax, or a traffic-steering algorithm.¶
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 28 December 2026.¶
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 increasingly places computing and storage resources near data sources and users. In a conventional deployment, a client discovers a service endpoint, sends a request to that endpoint, and receives a result. This model works well when service instances have stable reachability and when the selected endpoint remains available for the duration of the transaction.¶
Future cross-domain edge systems can have substantially different properties. A maritime sensing system may include sensors, autonomous platforms, and buoy gateways. A non-terrestrial segment may provide intermittent connectivity and temporary computing or caching capacity through low-Earth-orbit satellites. Terrestrial gateways, edge sites, and cloud systems may host additional service instances and data repositories. The same logical service may therefore be deployed at several locations whose reachability, load, and administrative ownership change over time.¶
In such an environment, binding a service request directly to a host or a currently reachable endpoint can be fragile. A service identity may outlive any particular instance. A requested computation may be available at several instances, and an acceptable result may already exist as a cached object. Conversely, a currently advertised instance may become unreachable before the request is transferred or completed. Discovery therefore needs to describe not only where an endpoint is located, but also what service or result is available, under which version and policy, for how long the information is valid, and how its provenance can be verified.¶
Information-Centric Networking (ICN) provides concepts for naming and retrieving information independently of a particular host location, together with in-network caching and object-level security considerations [RFC7927] [RFC8793]. ICN deployment options include native, overlay, and gateway-assisted approaches [RFC8763]. IoT edge systems also face intermittent service availability, privacy, and security challenges [RFC9556]. These observations motivate examining whether stable naming and object-oriented discovery can be applied to computing services and reusable computation results in heterogeneous edge environments.¶
This document is a requirements-oriented contribution. It introduces a motivating network model and identifies requirements for:¶
The space-terrestrial-maritime scenario is used as a motivating example. The requirements may also be applicable to other challenged or intermittently connected edge environments, including remote industrial sites, disaster-response networks, and mobile edge systems.¶
This document does not define a new name format, discovery message, routing protocol, or resource-allocation algorithm. It also does not standardize underwater physical- or link-layer technologies. The intention is to provide a focused basis for discussion and experimentation before selecting any protocol realization.¶
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.¶
Because this document specifies requirements rather than a protocol, these key words describe properties expected of a future discovery design. They do not require a particular encoding or implementation architecture.¶
The target environment has one or more of the following characteristics:¶
These properties create a separation between logical service identity and temporary execution location. They also create a distinction between discovering a service and selecting a network path to a particular instance. Discovery identifies what services, instances, or results exist and whether they are eligible. Steering or routing determines how traffic reaches a selected candidate.¶
Endpoint-oriented discovery mechanisms can identify named instances and their locators. For example, DNS-Based Service Discovery (DNS-SD) discovers named service instances using DNS records [RFC6763]. Such mechanisms remain useful and can be part of an incremental solution.¶
However, an endpoint alone does not necessarily express the information needed in the target environment. A requester may need to determine:¶
A future design may extend an existing service-discovery mechanism, use an ICN name resolution service as considered in [RFC9236], or use name-based routing directly. This document does not select among these approaches.¶
This document focuses on the gateway and edge layer that interconnects maritime sensing domains, non-terrestrial systems, terrestrial edge sites, and cloud infrastructure. It considers discovery of:¶
The document considers both IP-based and ICN-capable deployments. It assumes that a separate mechanism performs final instance selection, routing, traffic steering, transport, or store-carry-forward delivery.¶
The following topics are out of scope for this version:¶
Figure 1 shows an illustrative deployment. The discovery function is logical and may be implemented by one or more components.¶
Maritime edge Non-terrestrial edge Terrestrial edge
+---------------+ +-------------------+ +----------------+
| sensor / buoy | | LEO service/cache | | edge / cloud |
| local cache |<-->| transient contact |<-->| service/result |
+---------------+ +-------------------+ +----------------+
\____________ logical discovery function ____________/
The model contains the following logical entities:¶
The model does not assume continuous end-to-end connectivity. A maritime gateway may contact a satellite only during a finite visibility window. A satellite or mobile edge node may advertise a service shortly before leaving contact. A terrestrial discovery repository may be temporarily unreachable from the maritime domain.¶
Store-carry-forward delivery, including Bundle Protocol mechanisms [RFC9171], may be used by a realization, but is not required by this document. Discovery information can be obtained proactively, cached locally, exchanged during contacts, or resolved on demand. A design needs to make the age and validity of cached information explicit.¶
A discovery record conceptually contains some subset of the following information:¶
This list is descriptive. A future protocol may separate static and dynamic information, use references to external manifests, or disclose only a policy-selected subset.¶
An autonomous underwater vehicle or sensor platform produces an observation that requires analysis. The requester uses a stable service name representing the required function, such as object detection, anomaly identification, or environmental-data compression. The function may be available at a buoy gateway, a passing satellite edge node, or a terrestrial edge site.¶
The requester does not need to know the final execution location when constructing the request. Discovery returns eligible service instances and validity information. A later steering or scheduling function selects an instance based on policy, current resources, contact duration, and network conditions.¶
If the buoy gateway has stale discovery information, it can determine that the record has expired rather than treating the advertised instance as currently reachable. If no current instance is reachable, the request may be deferred, forwarded using a delay-tolerant mechanism, or sent to a different service implementation.¶
A low-Earth-orbit node provides temporary computing or storage capacity. Before or during a contact opportunity, it advertises service instances and a validity interval. The advertisement may include a coarse indication of expected availability, supported service versions, input-size limits, and security requirements.¶
The requester needs to distinguish an advertisement that is valid for the current or next contact from one learned during an earlier orbit. The discovery design also needs to avoid assuming that a predicted contact is guaranteed. A service record therefore represents evidence and validity constraints, not a promise of successful completion.¶
Several requesters may ask for equivalent analysis of the same named data object or of inputs that satisfy a documented equivalence rule. A gateway or cache may already hold a recent result generated by an authorized service version.¶
The requester can accept the cached result only if the result's provenance, service version, input binding, parameter binding, freshness, and authorization conditions satisfy the request. A matching service name alone is insufficient. For example, two results produced by different model versions, confidence thresholds, geographic scopes, or data-preprocessing steps might not be interchangeable.¶
If the result is acceptable, retrieval can avoid repeated transfer and computation. Otherwise, the requester invokes an eligible service instance. The discovery mechanism does not decide semantic equivalence by itself; it exposes enough authenticated metadata for the requester or an application policy to make that decision.¶
A maritime domain becomes disconnected from a remote discovery repository. Local gateways continue to answer discovery requests using cached records, but mark the records with their source, age, and validity. New local services or results can be published locally and synchronized with other domains when connectivity returns.¶
This use case requires that the absence of a current remote response not be interpreted as proof that a service does not exist. It also requires conflict handling when independent domains update records during a partition.¶
R1 - Location independence: A discovery design MUST support a stable service name that does not change when a service instance moves, restarts, or is replicated at another site.¶
R2 - Identity separation: The design MUST distinguish the logical service identity from a service-instance identifier and from the locator used to reach that instance. The design SHOULD also distinguish service names, data-object names, and result-object names.¶
R3 - Version identification: The design MUST support identification of service and interface versions. When service behavior depends on an executable, model, configuration, or policy artifact, the design SHOULD support an immutable digest or equivalent version binding.¶
R4 - Administrative ownership: A name-management approach MUST provide a means to determine which authority is permitted to publish records for a namespace. It SHOULD support collision avoidance and delegation across administrative domains.¶
R5 - Technology neutrality: The abstract naming model SHOULD NOT require all participating domains to use the same forwarding plane. It SHOULD permit mapping to DNS names, URIs, ICN names, or other identifiers where appropriate.¶
R6 - Interface description: A service record MUST identify the service interface or provide a verifiable reference to an interface description. The description SHOULD include supported input and output types and any constraints required for interoperability.¶
R7 - Static and dynamic metadata: The design SHOULD distinguish relatively static attributes, such as service version and supported data types, from dynamic attributes, such as current queue state, available storage, or expected completion time. Dynamic information MUST carry a timestamp or validity indication.¶
R8 - Extensibility: Capability descriptions MUST be extensible so that new service-specific attributes can be introduced without invalidating existing records. Unknown optional attributes SHOULD be safely ignored.¶
R9 - Policy-controlled disclosure: A publisher MUST be able to restrict or reduce the capability and status information disclosed outside its administrative domain. A discovery design SHOULD support coarse-grained or policy-filtered descriptions when detailed resource information is sensitive.¶
R10 - No implicit comparability: The presence of two capability attributes with similar labels MUST NOT be assumed to make values comparable unless the attribute semantics and units are defined. Candidate ranking is outside the scope of discovery.¶
R11 - Explicit validity: Discovery records MUST include sufficient information to determine their age and validity. A consumer MUST NOT treat an expired record as evidence of current reachability.¶
R12 - Temporary unreachability: The design SHOULD distinguish, where information is available, between an unknown service, a known service with no currently reachable instance, and a service expected to become reachable during a future contact opportunity.¶
R13 - Cached operation: A domain SHOULD be able to resolve names from authenticated cached records when a remote discovery function is unreachable. The response MUST preserve the original record's source, age, and validity information.¶
R14 - Contact uncertainty: If predicted contact information is included, the record MUST identify the prediction time or validity interval. The design MUST NOT represent predicted reachability as guaranteed reachability.¶
R15 - Partition tolerance: The design SHOULD permit local publication and resolution during a network partition. It SHOULD define how conflicting or concurrent record versions can be detected after synchronization.¶
R16 - Bounded overhead: Discovery exchanges SHOULD support compact responses, selective attribute retrieval, or summary advertisements so that constrained contacts are not consumed by unnecessary metadata.¶
R17 - Result identity: A reusable result MUST be associated with a name or identifier that can be bound to the service identity, service version, input identity, and relevant invocation parameters.¶
R18 - Input binding: The design MUST support a cryptographic digest, immutable name, or equivalent mechanism that allows a requester to determine which input object or input set produced a result.¶
R19 - Execution context: When the validity of a result depends on model version, configuration, geographic scope, time interval, precision, or execution environment, the result metadata MUST bind the relevant context to the result or to a verifiable manifest.¶
R20 - Freshness: A result record MUST include creation time and an expiration, freshness, or revalidation indication. A requester MUST be able to express a freshness bound or reject a result that does not satisfy local policy.¶
R21 - Provenance: A result object MUST provide verifiable provenance identifying the producing service or authorized execution environment. Retrieval from a cache MUST NOT remove or replace the original provenance.¶
R22 - Reuse policy: A publisher or service operator MUST be able to indicate that a result is not reusable, is reusable only within a domain, or is reusable only by authorized requesters. Caches MUST enforce the applicable policy.¶
R23 - Safe fallback: If equivalence, integrity, freshness, or authorization cannot be established, the requester MUST NOT treat the cached result as a valid substitute. It may invoke a service instance or fail according to application policy.¶
R24 - Record integrity: Discovery records MUST be integrity protected and attributable to an authorized publisher. Protection SHOULD remain verifiable when a record is forwarded, replicated, or served from a cache.¶
R25 - Cross-domain trust: The design MUST support explicit trust decisions across administrative domains. Acceptance of one domain's identity MUST NOT automatically imply authorization to publish every service or result name.¶
R26 - Authorization: The design MUST support authorization for service invocation, discovery-record access, and result retrieval as separate decisions. Authorization metadata SHOULD support least-privilege disclosure.¶
R27 - Revocation and expiry: A design MUST support bounded validity and a method to reject compromised, revoked, or superseded publisher credentials or records. Operation during disconnection may limit access to current revocation state; that limitation MUST be visible to the relying party.¶
R28 - Confidentiality and privacy: The design SHOULD support confidentiality for sensitive discovery queries, records, and result metadata. It SHOULD minimize exposure of precise location, contact schedules, resource state, requester interests, and service inventories.¶
R29 - Replay resistance: A relying party MUST be able to detect or limit replay of stale records using validity intervals, sequence information, nonces, or equivalent mechanisms.¶
R30 - Existing infrastructure: A design SHOULD permit deployment over existing IP networks and applications. Native ICN forwarding MUST NOT be a prerequisite for every participating node.¶
R31 - Gateways: The design SHOULD support gateways that translate or proxy discovery between IP-based and ICN-capable domains while preserving identity, validity, and provenance information.¶
R32 - Partial participation: A deployment SHOULD continue to provide a useful subset of functionality when some nodes understand only endpoint discovery and others understand named services and results.¶
R33 - Separation from steering: The discovery interface SHOULD provide candidate and metadata information without mandating a particular traffic-steering or routing system. A realization may supply candidates to CATS, an application scheduler, an ICN forwarder, or a delay-tolerant routing function.¶
R34 - Local autonomy: Each administrative domain MUST retain control over which records it publishes, which external records it imports, and which service or result requests it accepts.¶
R35 - Observability: Implementations SHOULD expose sufficient diagnostics to determine the source, age, validation outcome, and selected version of a discovery record without revealing protected metadata.¶
ICN research has examined location-independent naming, name-based routing, caching, object security, mobility, and deployment considerations [RFC7476] [RFC7927] [RFC7945] [RFC8763]. CCNx defines Interest and Content Object semantics and a corresponding TLV message format [RFC8569] [RFC8609]. ICN terminology is documented in [RFC8793].¶
This document does not alter those architectures. It applies similar separation of identity from location to computing services and to the results generated by those services. A future realization could represent service descriptions and results as named content objects, but it could also use an IP-based discovery system with stable identifiers and signed manifests.¶
[RFC9236] discusses architectural implications of using a Name Resolution Service in ICN. Such a service is one possible realization of the logical discovery function described here. [RFC9344] defines CCNinfo for discovering path and cache information in CCN deployments. CCNinfo is an instrumentation protocol and does not provide the service and result semantics specified as requirements in this document.¶
[RFC9556] describes IoT edge challenges and functions, including time sensitivity, data volume, intermittent services, privacy, and security. This document focuses more narrowly on the discovery semantics needed when compute services and reusable results span intermittently connected domains.¶
DNS-SD [RFC6763] discovers named instances of a service type and returns information needed to contact them. Scalable and wide-area extensions have also been considered and standardized [RFC7558] [RFC8766]. DNS-SD could be used as part of an incremental realization. This document adds no DNS records and requests no DNS registry actions.¶
The requirements in this document extend beyond endpoint enumeration by considering service-version identity, intermittent validity, named result objects, provenance, and controlled result reuse. Whether those properties should be represented through DNS, ICN, manifests, or another protocol is left for future work.¶
CATS defines an architectural framework for steering service traffic using network and computing information [I-D.ietf-cats-framework]. Its service identifier represents a service independently of the particular service contact instance. The associated problem statement and requirements focus on selecting among distributed service sites and instances [I-D.ietf-cats-usecases-requirements].¶
This document is intended to be complementary. It focuses on discovery of named services and reusable result objects, operation across intermittently connected administrative domains, and preservation of object provenance. A future implementation could provide discovered candidate instances and metadata to a CATS path selector. This document does not redefine CATS identifiers, metrics, or steering procedures.¶
Bundle Protocol Version 7 [RFC9171] supports store-carry-forward communication in disruption-tolerant environments, and BPSec provides integrity and confidentiality services for Bundle Protocol exchanges [RFC9172]. A discovery realization may use these mechanisms to transport records or requests, but this document neither requires nor modifies Bundle Protocol.¶
Name-based discovery of computing services and results introduces security and privacy risks beyond ordinary endpoint lookup. A protocol realization needs to address at least the threats described in this section.¶
This document does not select cryptographic algorithms, credential formats, or trust models. Any protocol specification derived from these requirements will need a complete threat model and concrete security mechanisms.¶
An attacker could advertise a false service instance, replace a legitimate locator, or inject a forged result record. This can redirect sensitive inputs, cause incorrect computations, or waste constrained contacts. Discovery records therefore require integrity protection, publisher authentication, namespace authorization, bounded validity, and replay resistance. A cache or gateway must preserve the original publisher's verifiable information rather than replacing it with an unauthenticated assertion.¶
Old records can be harmful even when they were originally authentic. An expired satellite contact, migrated service instance, or obsolete model version can cause request failure or incorrect results. Implementations must validate record age and validity and should expose uncertainty in predicted contact information. Disconnected nodes may be unable to obtain current revocation information; applications need policy for this condition.¶
A validly signed result can still be unsuitable for a request. An attacker or faulty cache could substitute a result produced from different input data, parameters, service version, model version, geographic scope, or freshness interval. Result identifiers and manifests need to bind all properties that affect reuse. Applications must not infer semantic equivalence solely from a human-readable service name.¶
Discovery information can reveal service inventories, node location, satellite contact schedules, resource shortages, requester interests, sensor activity, and operational plans. Even coarse capability metadata can support traffic analysis. Deployments should minimize collected and disclosed attributes, use access control and confidentiality where appropriate, and avoid publishing precise dynamic resource information unless it is required.¶
Attackers can issue broad discovery queries, request expensive signature validation, advertise excessive records, or trigger repeated service execution when cached results are rejected. Implementations should support rate limits, query scoping, bounded response sizes, admission control, negative caching where safe, and inexpensive rejection of malformed or unauthorized requests. A protocol design should avoid responses significantly larger than unauthenticated requests unless return routability or authorization has been established.¶
A gateway translating between IP-based discovery and ICN naming can become a trust and downgrade boundary. Translation must not silently discard service-version, validity, provenance, or authorization information. When a property cannot be represented in the target system, the gateway should report that limitation rather than asserting an equivalent security level.¶
This document has no IANA actions.¶
The motivation for this document was informed by discussions and presentations observed in ICNRG and SPACE RG sessions. The author welcomes comments on scope, terminology, overlap with existing work, and suitable experimental directions.¶