Requirements for Name-Based Compute-Service Discovery in Heterogeneous Space-Terrestrial-Maritime Edge Networks

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 . ICN deployment options include native, overlay, and gateway-assisted approaches . IoT edge systems also face intermittent service availability, privacy, and security challenges . 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:

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.

Terminology

Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. 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.

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

Problem Statement and Scope

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.

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 . 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 , or use name-based routing directly. This document does not select among these approaches.

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

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.

Cross-Domain Network Model shows an illustrative deployment. The discovery function is logical and may be implemented by one or more components.

Illustrative Cross-Domain Edge Environment | transient contact |<-->| service/result | +---------------+ +-------------------+ +----------------+ \____________ logical discovery function ____________/ ]]>

Entities The model contains the following logical entities:

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.

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

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

Use Cases

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.

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.

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.

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.

Requirements

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.

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

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.

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

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

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.

Relationship with Existing Work

Information-Centric Networking ICN research has examined location-independent naming, name-based routing, caching, object security, mobility, and deployment considerations . CCNx defines Interest and Content Object semantics and a corresponding TLV message format . ICN terminology is documented in . 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. 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. 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.

IoT Edge Computing 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-Based Service Discovery DNS-SD 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 . 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.

Computing-Aware Traffic Steering CATS defines an architectural framework for steering service traffic using network and computing information . 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 . 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.

Delay-Tolerant Networking Bundle Protocol Version 7 supports store-carry-forward communication in disruption-tolerant environments, and BPSec provides integrity and confidentiality services for Bundle Protocol exchanges . A discovery realization may use these mechanisms to transport records or requests, but this document neither requires nor modifies Bundle Protocol.

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.

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.

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.

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.

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.

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.

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 unauthenticated requests unless return routability or authorization has been established.

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.

IANA Considerations This document has no IANA actions.

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.