Requirements for Name-Based Compute-Service Discovery in Heterogeneous Space-Terrestrial-Maritime Edge Networks
draft-liu-icnrg-cross-domain-compute-discovery-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | 刘帅 | ||
| Last updated | 2026-06-26 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| On agenda | icnrg at IETF-126 | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-icnrg-cross-domain-compute-discovery-00
Information-Centric Networking Research Group S. Liu
Internet-Draft Nanjing University
Intended status: Informational 26 June 2026
Expires: 28 December 2026
Requirements for Name-Based Compute-Service Discovery in Heterogeneous
Space-Terrestrial-Maritime Edge Networks
draft-liu-icnrg-cross-domain-compute-discovery-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Liu Expires 28 December 2026 [Page 1]
Internet-Draft Cross-Domain Compute Discovery June 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement and Scope . . . . . . . . . . . . . . . . . 6
3.1. Problem Characteristics . . . . . . . . . . . . . . . . . 6
3.2. Limitations of Endpoint-Only Discovery . . . . . . . . . 7
3.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Cross-Domain Network Model . . . . . . . . . . . . . . . . . 8
4.1. Entities . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Connectivity Assumptions . . . . . . . . . . . . . . . . 9
4.3. Conceptual Discovery Record . . . . . . . . . . . . . . . 9
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Maritime Environmental Analysis . . . . . . . . . . . . . 10
5.2. Opportunistic Non-Terrestrial Service Access . . . . . . 11
5.3. Reuse of a Cached Computation Result . . . . . . . . . . 11
5.4. Operation During Discovery-Service Partition . . . . . . 11
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Stable Service Naming . . . . . . . . . . . . . . . . . . 12
6.2. Capability Description . . . . . . . . . . . . . . . . . 12
6.3. Disruption-Aware Discovery . . . . . . . . . . . . . . . 13
6.4. Cache and Result Reuse . . . . . . . . . . . . . . . . . 13
6.5. Trust and Authorization . . . . . . . . . . . . . . . . . 14
6.6. Incremental Deployment . . . . . . . . . . . . . . . . . 15
7. Relationship with Existing Work . . . . . . . . . . . . . . . 15
7.1. Information-Centric Networking . . . . . . . . . . . . . 16
7.2. IoT Edge Computing . . . . . . . . . . . . . . . . . . . 16
7.3. DNS-Based Service Discovery . . . . . . . . . . . . . . . 16
7.4. Computing-Aware Traffic Steering . . . . . . . . . . . . 17
7.5. Delay-Tolerant Networking . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Forged and Poisoned Discovery Records . . . . . . . . . . 17
8.2. Stale Reachability and Contact Information . . . . . . . 18
8.3. Result Substitution and Semantic Mismatch . . . . . . . . 18
8.4. Authorization and Multi-Domain Trust . . . . . . . . . . 18
8.5. Privacy and Operational Confidentiality . . . . . . . . . 18
Liu Expires 28 December 2026 [Page 2]
Internet-Draft Cross-Domain Compute Discovery June 2026
8.6. Denial of Service and Amplification . . . . . . . . . . . 18
8.7. Gateway Translation . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
11. Normative References . . . . . . . . . . . . . . . . . . . . 19
12. Informative References . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
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.
Liu Expires 28 December 2026 [Page 3]
Internet-Draft Cross-Domain Compute Discovery June 2026
This document is a requirements-oriented contribution. It introduces
a motivating network model and identifies requirements for:
* stable naming of services, instances, data, and results;
* describing service capabilities and result properties;
* operating when links and discovery functions are intermittently
reachable;
* determining whether a cached computation result is acceptable for
reuse;
* protecting the integrity, provenance, authorization, and
confidentiality of discovery information; and
* deploying the approach incrementally over existing IP and ICN
infrastructures.
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.
2. Terminology
2.1. 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 [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.
Liu Expires 28 December 2026 [Page 4]
Internet-Draft Cross-Domain Compute Discovery June 2026
2.2. Definitions
Administrative Domain: A set of nodes, services, and policies
operated under common administrative control. A cross-domain
system contains two or more administrative domains with
potentially different trust anchors, naming practices, and
disclosure policies.
Computing Service: An offering that processes input according to
defined service logic and produces an output. A computing service
may be implemented by one or more service instances. This
definition is consistent with the service concepts used by
Computing-Aware Traffic Steering (CATS) [I-D.ietf-cats-framework].
Service Name: A stable identifier for the logical identity of a
computing service. It is independent of the current network
locator of any particular service instance.
Service Instance: A running realization of a computing service at a
particular service site. A service instance has temporary
execution state and one or more locators or contact points.
Service Instance Locator: Information used to reach a service
instance or a service contact function. Examples include an IP
address and port, a URI, an ICN name prefix, or a delay-tolerant
networking endpoint identifier.
Data Object: A named input, model artifact, configuration object, or
other information object that can be supplied to or consumed by a
computing service.
Result Object: A named output produced by invoking a specified
service version with specified inputs and parameters. A result
object includes, or is associated with, metadata sufficient to
evaluate freshness, provenance, and reuse eligibility.
Discovery Record: A signed or otherwise integrity-protected binding
between a service or result name and descriptive metadata. A
discovery record may identify candidate instances, result
locations, validity intervals, capabilities, policies, and trust
information.
Discovery Function: A logical function that publishes, stores,
resolves, forwards, or aggregates discovery records. It may be
centralized, distributed, replicated, embedded in gateways, or
realized using name-based routing.
Requester: A node or application seeking to invoke a computing
Liu Expires 28 December 2026 [Page 5]
Internet-Draft Cross-Domain Compute Discovery June 2026
service or retrieve a reusable result object.
Contact Opportunity: A time interval during which communication
between two nodes or domains is expected to be possible. A
contact opportunity may be predicted, scheduled, observed, or
opportunistic.
Freshness Bound: A requester-defined or policy-defined limit on the
age of a discovery record, input object, or result object.
3. Problem Statement and Scope
3.1. Problem Characteristics
The target environment has one or more of the following
characteristics:
* *Replicated services:* The same logical service is deployed at
terrestrial, maritime, or non-terrestrial sites.
* *Dynamic placement:* Instances can start, stop, migrate, or be
replaced as resources and connectivity change.
* *Intermittent connectivity:* End-to-end paths may not exist
continuously, and a contact may terminate before a transaction
completes.
* *Resource constraints:* Some sites have limited energy, storage,
bandwidth, or processing capacity.
* *Multiple administrative domains:* Service descriptions and
results may cross organizational boundaries with different trust
and authorization policies.
* *Reusable information:* A previously generated result can
sometimes satisfy a later request without repeating data transfer
and computation.
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.
Liu Expires 28 December 2026 [Page 6]
Internet-Draft Cross-Domain Compute Discovery June 2026
3.2. Limitations of Endpoint-Only Discovery
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:
* whether multiple endpoints implement the same service semantics
and version;
* whether an endpoint is expected to remain reachable long enough to
complete the request;
* whether a cached result can satisfy the request without invoking
an endpoint;
* whether service metadata or a result was produced by an authorized
party;
* whether the record is still valid under rapidly changing contact
conditions; and
* whether cross-domain policy permits disclosure, execution, or
result reuse.
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.
3.3. Scope
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:
* logical computing services;
* available or predicted service instances;
* named input data and executable or model artifacts; and
Liu Expires 28 December 2026 [Page 7]
Internet-Draft Cross-Domain Compute Discovery June 2026
* previously generated result objects that may be reused.
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.
3.4. Non-Goals
The following topics are out of scope for this version:
* specifying a universal naming syntax or assigning name components;
* defining discovery protocol messages or a registry schema;
* defining computing or network metrics;
* specifying traffic steering, routing, congestion control, or task
scheduling;
* standardizing an optimization or machine-learning algorithm;
* standardizing underwater acoustic or optical communication
protocols; and
* asserting that arbitrary computation results are semantically
interchangeable.
4. Cross-Domain Network Model
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 ____________/
Figure 1: Illustrative Cross-Domain Edge Environment
4.1. Entities
The model contains the following logical entities:
Liu Expires 28 December 2026 [Page 8]
Internet-Draft Cross-Domain Compute Discovery June 2026
* *Requesters* generate service requests and express acceptance
constraints, such as service version, freshness, latency class,
trust domain, or confidentiality policy.
* *Domain gateways* connect local sensing or edge networks to other
domains. A gateway may translate between naming or transport
technologies, cache discovery records, or hold result objects.
* *Service sites* host one or more service instances. Sites may be
terrestrial, maritime, airborne, or space-based.
* *Result stores* retain named results and associated provenance. A
result store may be co-located with a service instance, gateway,
or cache.
* *Discovery functions* publish or resolve discovery records. A
deployment may use local repositories, distributed name
resolution, ICN routing, or synchronization among gateways.
* *Trust services* provide trust anchors, credentials, authorization
information, revocation status, or evidence needed to evaluate
discovery records and result objects.
4.2. Connectivity Assumptions
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.
4.3. Conceptual Discovery Record
A discovery record conceptually contains some subset of the following
information:
* a stable service or result name;
* a service version, interface version, model version, or immutable
artifact digest;
* one or more instance identifiers or locators;
Liu Expires 28 December 2026 [Page 9]
Internet-Draft Cross-Domain Compute Discovery June 2026
* supported input and output types;
* static capability attributes and selected dynamic status
information;
* a creation time, validity interval, freshness indication, and
sequence or version information;
* contact or reachability hints, when policy permits their
disclosure;
* authorization requirements and administrative-domain information;
* provenance and integrity-verification information; and
* for a result object, a binding to the service, inputs, parameters,
and execution context that produced it.
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.
5. Use Cases
5.1. Maritime Environmental Analysis
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.
Liu Expires 28 December 2026 [Page 10]
Internet-Draft Cross-Domain Compute Discovery June 2026
5.2. Opportunistic Non-Terrestrial Service Access
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.
5.3. Reuse of a Cached Computation Result
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.
5.4. Operation During Discovery-Service Partition
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.
Liu Expires 28 December 2026 [Page 11]
Internet-Draft Cross-Domain Compute Discovery June 2026
6. Requirements
6.1. Stable Service Naming
*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.
6.2. Capability Description
*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.
Liu Expires 28 December 2026 [Page 12]
Internet-Draft Cross-Domain Compute Discovery June 2026
*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.
6.3. Disruption-Aware 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.
6.4. Cache and Result Reuse
*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.
Liu Expires 28 December 2026 [Page 13]
Internet-Draft Cross-Domain Compute Discovery June 2026
*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.
6.5. Trust and Authorization
*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.
Liu Expires 28 December 2026 [Page 14]
Internet-Draft Cross-Domain Compute Discovery June 2026
*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.
6.6. Incremental Deployment
*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.
7. Relationship with Existing Work
Liu Expires 28 December 2026 [Page 15]
Internet-Draft Cross-Domain Compute Discovery June 2026
7.1. Information-Centric Networking
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.
7.2. IoT Edge Computing
[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.
7.3. DNS-Based Service Discovery
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.
Liu Expires 28 December 2026 [Page 16]
Internet-Draft Cross-Domain Compute Discovery June 2026
7.4. Computing-Aware Traffic Steering
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.
7.5. Delay-Tolerant Networking
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.
8. Security Considerations
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.
8.1. Forged and Poisoned Discovery Records
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.
Liu Expires 28 December 2026 [Page 17]
Internet-Draft Cross-Domain Compute Discovery June 2026
8.2. Stale Reachability and Contact Information
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.
8.3. Result Substitution and Semantic Mismatch
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.
8.4. Authorization and Multi-Domain Trust
Authorization to publish a service name, invoke a service, access
discovery metadata, and retrieve a result are distinct permissions.
Trust anchors and authorization policies may differ among maritime
operators, satellite providers, and terrestrial service providers. A
design must not assume transitive trust across domains. Policy
conflicts and failures to obtain authorization should fail safely.
8.5. Privacy and Operational Confidentiality
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.
8.6. Denial of Service and Amplification
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
Liu Expires 28 December 2026 [Page 18]
Internet-Draft Cross-Domain Compute Discovery June 2026
unauthenticated requests unless return routability or authorization
has been established.
8.7. Gateway Translation
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.
9. IANA Considerations
This document has no IANA actions.
10. Acknowledgements
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.
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12. Informative References
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[RFC7476] Pentikousis, K., Ohlman, B., Corujo, D., Boggia, G.,
Tyson, G., Davies, E., Molinaro, A., and S. Eum,
"Information-Centric Networking: Baseline Scenarios",
RFC 7476, DOI 10.17487/RFC7476, March 2015,
<https://www.rfc-editor.org/info/rfc7476>.
Liu Expires 28 December 2026 [Page 19]
Internet-Draft Cross-Domain Compute Discovery June 2026
[RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault,
"Requirements for Scalable DNS-Based Service Discovery
(DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558,
DOI 10.17487/RFC7558, July 2015,
<https://www.rfc-editor.org/info/rfc7558>.
[RFC7927] Kutscher, D., Eum, S., Pentikousis, K., Psaras, I.,
Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
"Information-Centric Networking (ICN) Research
Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
<https://www.rfc-editor.org/info/rfc7927>.
[RFC7945] Pentikousis, K., Ohlman, B., Davies, E., Spirou, S., and
G. Boggia, "Information-Centric Networking: Evaluation and
Security Considerations", RFC 7945, DOI 10.17487/RFC7945,
September 2016, <https://www.rfc-editor.org/info/rfc7945>.
[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Semantics", RFC 8569,
DOI 10.17487/RFC8569, July 2019,
<https://www.rfc-editor.org/info/rfc8569>.
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Messages in TLV Format", RFC 8609,
DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/info/rfc8609>.
[RFC8763] Rahman, A., Trossen, D., Kutscher, D., and R. Ravindran,
"Deployment Considerations for Information-Centric
Networking (ICN)", RFC 8763, DOI 10.17487/RFC8763, April
2020, <https://www.rfc-editor.org/info/rfc8763>.
[RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based
Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June
2020, <https://www.rfc-editor.org/info/rfc8766>.
[RFC8793] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran,
D., and C. Tschudin, "Information-Centric Networking
(ICN): Content-Centric Networking (CCNx) and Named Data
Networking (NDN) Terminology", RFC 8793,
DOI 10.17487/RFC8793, June 2020,
<https://www.rfc-editor.org/info/rfc8793>.
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022,
<https://www.rfc-editor.org/info/rfc9171>.
Liu Expires 28 December 2026 [Page 20]
Internet-Draft Cross-Domain Compute Discovery June 2026
[RFC9172] Birrane, E. and K. McKeever, "Bundle Protocol Security
(BPSec)", RFC 9172, DOI 10.17487/RFC9172, January 2022,
<https://www.rfc-editor.org/info/rfc9172>.
[RFC9236] Hong, J., You, T., and V. Kafle, "Architectural
Considerations of Information-Centric Networking (ICN)
Using a Name Resolution Service", RFC 9236,
DOI 10.17487/RFC9236, April 2022,
<https://www.rfc-editor.org/info/rfc9236>.
[RFC9344] Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering
Content and Network Information in Content-Centric
Networks", RFC 9344, DOI 10.17487/RFC9344, February 2023,
<https://www.rfc-editor.org/info/rfc9344>.
[RFC9556] Hong, J., Hong, Y-G., de Foy, X., Kovatsch, M., Schooler,
E., and D. Kutscher, "Internet of Things (IoT) Edge
Challenges and Functions", RFC 9556, DOI 10.17487/RFC9556,
April 2024, <https://www.rfc-editor.org/info/rfc9556>.
[I-D.ietf-cats-framework]
Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J.
Drake, "A Framework for Computing-Aware Traffic Steering
(CATS)", Work in Progress, Internet-Draft, draft-ietf-
cats-framework-24, 2 April 2026,
<https://datatracker.ietf.org/doc/draft-ietf-cats-
framework/>.
[I-D.ietf-cats-usecases-requirements]
Yao, K., Contreras, L. M., Shi, H., Zhang, S., and Q. An,
"Computing-Aware Traffic Steering (CATS) Problem
Statement, Use Cases, and Requirements", Work in Progress,
Internet-Draft, draft-ietf-cats-usecases-requirements-14,
3 February 2026, <https://datatracker.ietf.org/doc/draft-
ietf-cats-usecases-requirements/>.
Author's Address
Shuai Liu
Nanjing University
School of Electronic Science and Engineering
Nanjing
210023
China
Email: shuai_liu@smail.nju.edu.cn
Liu Expires 28 December 2026 [Page 21]