Network Working Group L. Dunbar
Internet Draft Futurewei
Intended status: Informational B. Zhang
Expires: April 29, 2027 Pengcheng Lab
October 29, 2026
Infrastructure-Assisted Discovery for AI Agents
draft-dunbar-dawn-infra-assisted-discovery-03
Abstract
This document describes an infrastructure-assisted approach
to the initial discovery of AI agents in managed enterprise,
cloud, edge-computing, and communication-network
environments. The approach treats infrastructure-provided
resource state and requester context as possible inputs to
the Minimum Viable Dataset (MVD) used by a discovery
mechanism. These inputs can help keep minimum public
discovery information current and can help determine the
appropriate discovery scope or entry point without requiring
the requester to understand deployment-specific network
details. The document does not define registration, catalog
search, semantic matchmaking, resource ranking, or selection,
and does not define a new discovery wire protocol.
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), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
Dunbar, et al. Expires April 29, 2027 [Page 1]
Internet-Draft Infrastructure Assisted Discovery
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 29, 2027.
Copyright Notice
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
(http://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 Simplified BSD
License text as described in Section 4.e of the Trust Legal
Provisions and are provided without warranty as described in
the Simplified BSD License.
Table of Contents
1. Introduction..............................................3
2. Conventions used in this document.........................4
3. Problem Statement.........................................5
4. Gap Analysis: DNS-SD and Managed AI-Agent Discovery.......7
4.1. Bootstrap Discovery and Rich Agent Metadata..........8
4.2. External Deployment State............................9
4.3. Discovery Domain vs. Network Scope..................10
4.4. Hidden Network Context..............................11
4.5. Discovery vs. Search and Selection..................12
5. Infrastructure-Assisted Discovery Model..................13
5.1. Requester Discovery Input...........................14
5.2. Current Resource State..............................14
5.3. Requester Context...................................15
5.4. Discovery Processing................................16
5.5. Metadata and Deployment State.......................19
5.6. Bootstrap Discovery Versus Resource Selection.......20
5.7. Relationship to Specific Discovery Mechanisms.......21
6. Resource State Contribution..............................22
6.1. Logical Service vs. Instance Exposure...............23
6.2. Cloud Deployment Example............................24
6.3. 5G Edge Deployment Example..........................25
6.4. Resource-State Changes..............................27
Dunbar, et al. Expires April 29, 2027 [Page 2]
Internet-Draft Infrastructure Assisted Discovery
7. Attachment Scope Determination and Update................28
7.1. Policy-Based Mapping................................29
7.2. Requester Attachment Scope..........................29
7.3. Scope Policy........................................30
7.4. Mobility and Reassociation..........................31
8. Applying the Model to DNS-SD.............................32
8.1. DNS-SD Mapping......................................32
8.2. DNS-SD Resource Representation......................33
8.3. Applying Attachment Scope...........................34
8.3.1. Scope-to-Domain Mapping........................34
8.3.2. Context-Specific Discovery Scope...............35
8.4. Agent Metadata in DNS-SD............................36
8.5. Discovery Result....................................36
8.6. Caching and Freshness...............................37
8.7. No Result...........................................39
9. Applying the Model to DNS-AID............................39
9.1. DNS-AID Mapping.....................................40
9.2. Applying Attachment Scope to DNS-AID................41
9.3. Relationship to DNS-AID Results.....................42
10. Second-Stage Agent Metadata Retrieval...................42
11. Alternative Realizations................................43
12. Security Considerations.................................45
13. IANA Considerations.....................................46
14. References..............................................46
14.1. Normative References...............................46
14.2. Informative References.............................46
15. Acknowledgments.........................................47
Appendix A:.................................................48
1. Introduction
AI-agent discovery is being explored in several DAWN
documents. The DAWN charter limits the initial work to
bootstrap discovery: a requester obtains the minimum public
discovery information needed to reach an AI resource and
continue with subsequent interaction. Rich catalog search,
semantic matchmaking, ranking, and resource selection are
outside this initial scope.
This document focuses on managed enterprise, cloud, edge-
computing, and communication-network deployments in which
infrastructure already maintains information that can assist
that bootstrap step.
Two kinds of infrastructure information are considered.
First, orchestration, hosting, gateway, or management systems
may know current resource deployment and reachability state.
Second, network infrastructure may know requester context,
Dunbar, et al. Expires April 29, 2027 [Page 3]
Internet-Draft Infrastructure Assisted Discovery
such as site, tenant, VPN, slice, or edge region. Either kind
of information may contribute to the Minimum Viable Dataset
(MVD) used by the discovery mechanism.
The model defines two logical integration points:
o a Resource State Hook, through which authorized deployment
infrastructure makes current resource state available to
the discovery mechanism; and
o an Attachment Context Hook, through which trusted network
infrastructure makes an abstract requester context
available to the discovery mechanism.
These hooks describe information flow into discovery. They do
not define registration procedures, orchestration APIs, DNS
administration, lifecycle-management protocols, or policy
configuration.
The infrastructure-assisted model is intended to complement
existing discovery mechanisms. For example, mDNS/DNS-SD can
provide local bootstrap discovery, while DNS-based mechanisms
can provide organization-level bootstrap discovery.
Infrastructure assistance can help identify the appropriate
discovery scope or keep the minimum public discovery
information aligned with current deployment state without
changing the underlying discovery protocol.
The infrastructure assistance described here uses authorized
control-plane or management information. It does not require
infrastructure to inspect, intercept, or participate in
subsequent agent-to-agent communications.
2. Conventions used in this document
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.
The following terms are used in this document:
Attachment Context Hook: A logical integration point through
which trusted network infrastructure makes an abstract
representation of the requester's current network or
administrative context available to the discovery mechanism.
Dunbar, et al. Expires April 29, 2027 [Page 4]
Internet-Draft Infrastructure Assisted Discovery
Attachment Scope: An abstract network-derived context that
can be used to identify an appropriate discovery scope,
domain, or entry point for a requester. The underlying
network-specific details need not be exposed to the
requester.
Minimum Discoverable Information (MDI): As defined in [DAWN-
TERMINOLOGY].
Minimum Viable Dataset (MVD): As defined in [DAWN-
TERMINOLOGY]. In the infrastructure-assisted model described
in this document, part of the MVD may be supplied by trusted
infrastructure rather than explicitly by the requester.
Requester: An entity initiating an AI-agent discovery
operation. The requester may itself be an AI agent or another
application acting on behalf of one.
Resource State Hook: A logical integration point through
which authorized orchestration, placement, hosting, gateway,
or management infrastructure makes current discovery-relevant
resource state available to the discovery mechanism.
3. Problem Statement
AI agents are increasingly deployed as software services in
enterprise networks, cloud environments, edge-computing
platforms, and communication networks. An AI agent may
provide functions such as reasoning, information retrieval,
translation, content generation, task execution, or
interaction with external tools and services.
Although AI agents may use conventional cloud-native
deployment techniques, their interaction model can be more
heterogeneous than that of many traditional software
services. A conventional service is often accessed through a
known API or interface contract once its endpoint is located.
Different AI agents, however, may support different
communication protocols, invocation methods, request or
response schemas, authentication procedures, supported
modalities, tools, task formats, or other agent-specific
parameters.
A2A provides one example. An A2A Agent Card can describe an
agent's supported interfaces, capabilities, skills, security
information, and other properties needed for subsequent
Dunbar, et al. Expires April 29, 2027 [Page 5]
Internet-Draft Infrastructure Assisted Discovery
interaction. Locating an AI-agent endpoint and obtaining this
richer agent-specific information can therefore be separate
operations.
This separation is consistent with the DAWN bootstrap model.
DAWN discovery can provide the minimum public discovery
information needed to reach the AI resource, after which the
requester can retrieve richer agent-specific information,
such as an A2A Agent Card, using the appropriate higher-layer
mechanism.
In managed deployments, information relevant to the bootstrap
discovery stage may already be maintained by infrastructure
systems.
For example, an orchestration, placement, or hosting system
may know:
- which externally visible AI-agent services or instances
currently exist;
- where a service endpoint is currently exposed;
- which communication protocol is associated with that
endpoint;
- whether multiple runtime instances share a common service
endpoint;
- when the externally visible endpoint changes; and
- when a service is withdrawn.
The AI-agent application itself need not maintain complete
knowledge of this deployment state, particularly when it
operates behind a load balancer, service mesh, reverse proxy,
gateway, or other hosting infrastructure.
Network infrastructure may separately possess information
relevant to determining the discovery scope or entry point
applicable to the requester. Such information can include:
- access-network attachment;
- enterprise or tenant context;
- VPN or routing context;
- DNN;
Dunbar, et al. Expires April 29, 2027 [Page 6]
Internet-Draft Infrastructure Assisted Discovery
- network slice;
- serving UPF or UPF group;
- edge-computing domain; or
- another deployment-specific network context.
Requiring the requester to understand and explicitly include
such information can couple application-layer discovery to
network-specific technologies. Conversely, exposing detailed
network topology or low-level identifiers through the
discovery protocol can create unnecessary complexity and
information exposure.
Deployment information and richer agent metadata may also
change at different rates. For example, an image-analysis
agent may move from one edge location to another while
retaining the same Agent Card, supported interfaces,
capabilities, and skills. A change in externally reachable
endpoint therefore does not necessarily require a
corresponding change to the richer agent-specific metadata.
There is consequently value in separating:
- the minimum public discovery information needed to
bootstrap communication;
- richer agent-specific information used after bootstrap;
and
- infrastructure-provided context that may contribute to
the MVD used by the discovery mechanism.
The infrastructure-assisted discovery model described in this
document focuses on the third item: allowing existing managed
infrastructure to contribute current resource state and
requester context to the MVD, without requiring the requester
to understand deployment-specific network details.
Registration, catalog search, semantic matchmaking, ranking,
and resource selection remain outside the scope of this
document.
4. Gap Analysis: DNS-SD and Managed AI-Agent Discovery
DNS-Based Service Discovery [RFC6763] provides a well-
established mechanism for discovering service instances
within a discovery domain. A client identifies a service type
Dunbar, et al. Expires April 29, 2027 [Page 7]
Internet-Draft Infrastructure Assisted Discovery
and domain and obtains service instances; SRV records
identify where an instance can be reached, while TXT records
may provide limited service-specific information.
This model provides a useful foundation for AI-agent
discovery.
[DAWN-MDNS] applies DNS-SD over mDNS to local AI-agent
discovery and describes a two-stage approach in which DNS-SD
provides lightweight bootstrap information and the agent's
native protocol subsequently provides richer agent-specific
information.
The infrastructure-assisted model described in this document
is compatible with that approach. It focuses on managed
deployments in which current resource state or requester
context may already be known by infrastructure and may
contribute to the MVD used by the discovery mechanism,
without changing the DNS-SD or mDNS protocol.
4.1. Bootstrap Discovery and Rich Agent Metadata
DAWN bootstrap discovery is limited to the minimum public
discovery information needed to reach an AI resource and
determine how to initiate subsequent communication.
AI-agent interaction may require richer information after
this initial discovery step. For example, an A2A requester
may subsequently obtain an Agent Card describing supported
interfaces, skills, capabilities, security requirements,
interaction characteristics, and other agent-specific
information.
Trying to represent all such information in DNS-SD TXT
records would duplicate metadata that is already available
through the agent's native description mechanism and could
make the discovery layer unnecessarily complex.
A more practical approach is to keep DAWN discovery
lightweight: obtain the minimum public discovery information
needed to reach the AI resource, and then retrieve richer
agent-native metadata through the appropriate higher-layer
mechanism when needed.
DAWN bootstrap discovery
|
v
Dunbar, et al. Expires April 29, 2027 [Page 8]
Internet-Draft Infrastructure Assisted Discovery
Minimum public discovery information
|
v
Retrieve agent-native metadata
|
v
Subsequent interaction
Richer information such as detailed capabilities, skills,
task schemas, runtime load, or application-specific semantics
is therefore not required to be represented in DNS-SD or
included in the DAWN discovery result.
4.2. External Deployment State
Managed AI-agent environments may introduce deployment
abstractions that are not visible to the requester.
For example, an orchestration system can create several
runtime instances of the same logical A2A service:
Vision Agent Service
|
+-----------+-----------+
| | |
v v v
Instance-A Instance-B Instance-C
The instances may share the same Agent Card and higher-layer
properties while having different deployment locations or
internal endpoints.
Alternatively, the instances may sit behind one stable
externally reachable service endpoint:
Vision Agent Service
|
Common Endpoint
|
+--------+--------+
| | |
A B C
Dunbar, et al. Expires April 29, 2027 [Page 9]
Internet-Draft Infrastructure Assisted Discovery
In this case, changes to the backend instances need not
change the Agent Card or the minimum public discovery
information exposed to the requester.
Conversely, if the externally reachable endpoint changes
because the service is moved or redeployed, the orchestration
or hosting infrastructure may already know the new endpoint
even though the agent's richer metadata remains unchanged.
A discovery mechanism can therefore benefit from
distinguishing:
- the logical AI-agent service;
- the current externally reachable endpoint used for
bootstrap discovery; and
- the internal runtime instances managed by the deployment
infrastructure.
The Resource State Hook described in this document allows
current externally relevant state to contribute to the MVD
used by discovery. How the orchestration system creates,
tracks, or updates the underlying instances is outside the
scope of DAWN.
4.3. Discovery Domain vs. Network Scope
DNS-SD uses a discovery domain to determine where service
discovery is performed.
In a managed communication network, however, the discovery
domain or bootstrap entry point appropriate for a requester
may depend on network or administrative context that is
different from a DNS administrative domain.
For example, two requesters using the same application or DNS
namespace may be associated with:
- different enterprise VPNs;
- different DNNs;
- different network slices;
- different UPFs;
- different edge domains; or
- different tenant contexts.
Dunbar, et al. Expires April 29, 2027 [Page 10]
Internet-Draft Infrastructure Assisted Discovery
Those requesters may therefore need to use different DAWN
discovery scopes or entry points even though they use the
same application-level discovery mechanism.
Conversely, several different underlying network states may
map to the same discovery scope.
For example:
UPF-A + DNN-X + Slice-1 ----+
|
UPF-B + DNN-X + Slice-1 ----+--> Attachment Scope X
|
VPN-X + Enterprise-A -------+
The Attachment Scope provides an abstraction between
deployment-specific network state and the discovery scope
used by the requester.
DNS-SD does not itself define such a mapping between
requester-side network state and the applicable discovery
domain or bootstrap entry point. In an infrastructure-
assisted deployment, that mapping can be supplied by trusted
infrastructure as part of the MVD used by the discovery
mechanism.
4.4. Hidden Network Context
A requester can reasonably know the organization, agent name,
local discovery context, or other bootstrap identifier used
by the applicable DAWN discovery mechanism.
It should not necessarily need to know deployment-specific
network information such as:
- Serving UPF;
- DNN;
- S-NSSAI;
- VRF;
- BNG;
- access circuit; or
- edge domain.
Dunbar, et al. Expires April 29, 2027 [Page 11]
Internet-Draft Infrastructure Assisted Discovery
Those properties belong to the managed infrastructure.
Requiring an AI-agent application to understand or explicitly
signal such information would create unnecessary coupling
between application-layer discovery and the underlying
network architecture.
Infrastructure assistance allows those details to remain
internal while still contributing to the MVD used by the
discovery mechanism. For example, trusted infrastructure can
derive an abstract Attachment Scope from this information and
use it to help determine the appropriate discovery scope or
bootstrap entry point, without exposing the underlying
network-specific identifiers to the requester.
4.5. Discovery vs. Search and Selection
This document distinguishes DAWN bootstrap discovery from
later search, matchmaking, ranking, or resource selection.
Existing service-discovery and service-routing systems may
use region, zone, locality, load, or other information to
steer traffic toward a preferred service instance. The
Attachment Scope described in this document serves a
different purpose: it represents requester context that may
contribute to the MVD used to determine the appropriate DAWN
discovery scope or bootstrap entry point.
For example:
Requester:
Attachment Scope: AScope-A
Deployment mapping:
AScope-A
|
+--> edge-a.agent.example
|
+--> shared.agent.example
Dunbar, et al. Expires April 29, 2027 [Page 12]
Internet-Draft Infrastructure Assisted Discovery
Infrastructure-provided context may therefore help determine
where DAWN bootstrap discovery should be performed. DAWN
discovery then returns the minimum public discovery
information needed to continue.
This document does not use Attachment Scope to rank agents by
capability, cost, load, latency, GPU availability, or similar
criteria.
If a subsequent service performs richer search or returns
multiple candidates, any matchmaking, ranking, or resource-
selection operation is outside the scope of this document.
Thus:
DAWN Discovery:
Determine the appropriate discovery scope or entry point
and obtain the minimum public discovery information.
Search / Selection:
Search, compare, rank, or choose among available
resources.
These functions are intentionally separated.
5. Infrastructure-Assisted Discovery Model
The infrastructure-assisted model treats the discovery
mechanism as a consumer of an MVD that can include requester-
supplied information and infrastructure-provided context.
Conceptually:
Dunbar, et al. Expires April 29, 2027 [Page 13]
Internet-Draft Infrastructure Assisted Discovery
Requester discovery input
+
Current resource state
+
Requester Attachment Scope
|
v
Discovery Mechanism
|
v
Minimum public discovery information
The model does not prescribe how the infrastructure obtains
or maintains these inputs. It only identifies where existing
managed state can assist the DAWN bootstrap process.
5.1. Requester Discovery Input
The requester supplies the discovery input defined by the
applicable DAWN mechanism. Depending on the mechanism, this
can be an organization FQDN, a known agent name, a local
service type, or another bootstrap identifier defined by that
mechanism.
The requester is not required to provide deployment-specific
network information such as serving UPF, DNN, network slice,
VPN, access point, or edge domain.
This document does not define open-ended natural-language
intent, semantic capability search, skill matching, or
ranking as part of DAWN discovery.
5.2. Current Resource State
Authorized deployment infrastructure may already maintain
current information about AI-agent resources that is relevant
to bootstrap discovery.
Such discovery-relevant state can include:
- a logical service identifier;
- an instance identifier, when the instance itself is
externally discoverable;
- the current externally reachable endpoint;
- the communication protocol;
- validity or availability state relevant to discovery;
Dunbar, et al. Expires April 29, 2027 [Page 14]
Internet-Draft Infrastructure Assisted Discovery
- deployment context used internally to determine the
appropriate discovery scope, when applicable; and
- a reference to additional agent-native metadata, where
the applicable DAWN mechanism permits such a reference.
The Resource State Hook described in Section 6 represents the
logical input through which this discovery-relevant subset of
current resource state is made available to the discovery
mechanism.
The resource represented through DAWN discovery may be
either:
- a logical AI-agent service exposed through a stable
endpoint; or
- an individually reachable runtime instance.
The choice depends on how the AI-agent service is deployed
and exposed. For example, multiple runtime instances behind a
common stable endpoint need not be represented individually
in DAWN discovery.
The information exposed to DAWN should be limited to what is
needed for bootstrap discovery. Internal placement details,
backend instance topology, load, accelerator state, or other
information used for resource selection are not required.
The deployment infrastructure may update its current resource
state as services are instantiated, moved, or withdrawn. How
that state is collected, maintained, registered, or reflected
in the underlying discovery mechanism is deployment-specific
and outside the scope of this document.
5.3. Requester Context
Trusted network infrastructure may determine the requester's
current Attachment Scope from network attachment,
reachability, or administrative state.
The Attachment Scope abstracts network-specific information
such as:
- access attachment;
Dunbar, et al. Expires April 29, 2027 [Page 15]
Internet-Draft Infrastructure Assisted Discovery
- VPN or routing context;
- DNN;
- network slice;
- serving UPF;
- tenant context; or
- edge domain.
The Attachment Context Hook described in Section 7 represents
the logical input through which the resulting Attachment
Scope is made available to the discovery mechanism.
The Attachment Scope is infrastructure-provided context that
may form part of the MVD used by the discovery mechanism. It
is not required to be supplied by the requester and does not
need to be exposed to the requester.
The discovery mechanism may use this context to determine the
appropriate discovery scope, domain, resolver view, or
bootstrap entry point for the requester. How the underlying
network state is mapped to an Attachment Scope, and how that
scope is mapped to a discovery scope, are deployment-specific
and outside the scope of this document.
5.4. Discovery Processing
The discovery mechanism processes the information available
in the MVD to perform DAWN bootstrap discovery.
In a managed deployment, the MVD may include three categories
of input:
- requester-supplied discovery input, such as an
organization FQDN, known agent name, local service type,
or other bootstrap identifier defined by the applicable
DAWN mechanism;
- current resource state supplied by authorized deployment
infrastructure; and
- requester Attachment Scope supplied by trusted network
infrastructure.
These inputs serve different purposes.
Dunbar, et al. Expires April 29, 2027 [Page 16]
Internet-Draft Infrastructure Assisted Discovery
Requester-supplied discovery input identifies the bootstrap
operation the requester wants to perform.
Current resource state helps ensure that the discovery
information exposed by the mechanism reflects the externally
reachable service or endpoint that is currently valid.
Requester Attachment Scope provides deployment context that
can help determine the discovery domain, local scope,
resolver view, or bootstrap entry point appropriate for the
requester.
Conceptually:
Requester Discovery Input
|
v
+----------------------+
| |
| DAWN Discovery |
| |
+----------------------+
^ ^
| |
| |
Resource State Attachment Scope
Hook Hook
| |
| |
Current externally Requester network /
relevant resource administrative context
state
The processing can be viewed as two related steps.
First, infrastructure-provided requester context may be used
to determine the appropriate discovery scope or entry point.
For example, an Attachment Scope derived from a requester's
VPN, tenant, slice, or edge location may map to a particular
organizational DNS namespace, DNS-SD discovery domain, local
discovery environment, or resolver view.
Second, within that discovery scope, current resource state
can help ensure that the Discovery Information returned to
the requester reflects the currently valid externally
reachable endpoint and communication protocol.
Dunbar, et al. Expires April 29, 2027 [Page 17]
Internet-Draft Infrastructure Assisted Discovery
For example:
Requester:
Organization: example.com
Infrastructure context:
Attachment Scope: AScope-Edge-A
Deployment policy:
AScope-Edge-A -> edge-a.agents.example.com
Current resource state:
Agent endpoint -> agent-a.edge.example.com
Protocol -> A2A
Result:
Minimum public discovery information needed
to reach the AI resource
The requester does not need to know the underlying network-
specific information used to derive `AScope-Edge-A`, nor does
it need to know how the deployment infrastructure obtained
the current endpoint information.
The discovery mechanism uses these inputs only for the
bootstrap function. It does not perform semantic capability
matching, catalog search, ranking, or optimization among
multiple AI resources.
If richer agent information is needed after bootstrap, such
as capabilities, skills, task schemas, or detailed security
requirements, that information can be obtained through the
agent's native protocol or another higher-layer mechanism.
Dunbar, et al. Expires April 29, 2027 [Page 18]
Internet-Draft Infrastructure Assisted Discovery
Thus, infrastructure-assisted discovery can be summarized as:
Requester bootstrap input
+
Infrastructure-provided MVD
|
v
Determine appropriate discovery scope
|
v
Obtain current minimum public
discovery information
|
v
Subsequent higher-layer interaction
The procedures used to derive Attachment Scope, maintain
deployment state, configure discovery policy, or update the
underlying DNS or discovery system are deployment-specific
and outside the scope of this document.
5.5. Metadata and Deployment State
Agent metadata and deployment state describe different
properties and can change independently.
For example, an A2A Agent Card can describe an agent's
capabilities, skills, supported interfaces, security
requirements, and other information needed for subsequent
interaction. The same logical AI-agent service can be
deployed at several locations or moved between locations
without changing those properties.
Conversely, deployment infrastructure can change the
externally reachable endpoint, instance identifier, or
associated Attachment Scope without requiring the underlying
functional description of the agent to change.
For example:
Agent Card:
Capabilities: Image Analysis
Protocol: A2A
Skills: Object Detection
|
Dunbar, et al. Expires April 29, 2027 [Page 19]
Internet-Draft Infrastructure Assisted Discovery
| unchanged
v
Deployment state:
Before:
Endpoint: agent.edge-a.example
Attachment Scope: AScope-A
After:
Endpoint: agent.edge-b.example
Attachment Scope: AScope-B
DAWN bootstrap discovery therefore does not need to reproduce
all of the richer agent metadata. It can return the minimum
public discovery information needed to reach the AI resource,
while richer information can be retrieved subsequently
through an agent-native mechanism such as the A2A Agent Card.
The discovery mechanism may reference both kinds of
information, but they need not be represented, maintained, or
updated in the same way.
This separation also allows infrastructure-provided
deployment state to contribute to the MVD without requiring
changes to the agent's richer functional metadata whenever
deployment conditions change.
5.6. Bootstrap Discovery Versus Resource Selection
Infrastructure-assisted discovery does not define a
candidate-ranking or optimization function.
Requester context can influence the discovery scope or entry
point from which bootstrap information is obtained.
Infrastructure-assisted DAWN discovery is therefore intended
to support the bootstrap step: determine the appropriate
discovery scope or entry point and obtain the minimum public
discovery information needed to reach an AI resource.
It does not select an optimal resource based on dynamic
factors such as:
Dunbar, et al. Expires April 29, 2027 [Page 20]
Internet-Draft Infrastructure Assisted Discovery
- latency;
- network congestion;
- compute load;
- accelerator or GPU availability;
- service cost;
- application policy; or
- another dynamic metric.
If multiple resources are subsequently available, any
operation that searches a catalog, compares capabilities,
ranks multiple agents, or chooses an optimal instance is
outside the scope of this document.
Such comparison, ranking, selection, or optimization can be
performed later by application logic or another mechanism.
For deployments requiring network-aware selection based on
service and network conditions, mechanisms such as CATS may
be applicable as a subsequent selection function. Such
mechanisms are separate from the DAWN bootstrap discovery
function described here.
Thus:
DAWN bootstrap discovery:
Determine where discovery should be performed and obtain
the minimum public discovery information.
Search / resource selection:
Search, compare, rank, or choose among available
resources.
These functions are intentionally separated.
5.7. Relationship to Specific Discovery Mechanisms
The infrastructure-assisted model is independent of a
particular DAWN discovery protocol.
The Resource State Hook and Attachment Context Hook provide
logical inputs to the discovery process, while the underlying
discovery mechanism can use DNS-SD/mDNS, DNS-based bootstrap
Dunbar, et al. Expires April 29, 2027 [Page 21]
Internet-Draft Infrastructure Assisted Discovery
discovery, or another mechanism defined within the DAWN
scope.
Sections 8 and 9 describe how the model can be applied to
DNS-SD/mDNS and DNS-based AI-agent discovery, respectively.
The model does not define a new discovery wire protocol. It
does not require changes to agent-to-agent communication
protocols and does not require infrastructure to inspect,
intercept, or participate in the contents of agent
communications.
The infrastructure assistance is applied around the discovery
mechanism: current resource state can help keep the minimum
public discovery information aligned with the deployed
service, while requester context can help determine the
appropriate discovery scope or bootstrap entry point.
How the underlying resource state is maintained, how network
context is derived, and how DNS or other discovery
information is provisioned are deployment-specific and
outside the scope of this document.
6. Resource State Contribution
The Resource State Hook is a logical input through which
authorized deployment infrastructure makes current discovery-
relevant resource state available to the discovery mechanism.
The concept can be illustrated using an A2A deployment.
An A2A Agent Card describes richer agent-specific information
used for subsequent interaction, such as supported
interfaces, capabilities, skills, and security requirements.
The Resource State Hook serves a different purpose: it
provides current externally relevant deployment and
reachability information that can contribute to the MVD used
for DAWN bootstrap discovery.
For example:
Logical-Service-Identifier: Vision-Agent
Instance-Identifier: Vision-Agent-A
Endpoint: https://vision-a.edge.example
Attachment-Scope: AScope-A
Protocol: A2A
Agent-Card-Reference:
https://vision-a.edge.example/.well-known/agent-card.json
Dunbar, et al. Expires April 29, 2027 [Page 22]
Internet-Draft Infrastructure Assisted Discovery
The externally reachable endpoint or associated Attachment
Scope may change while the Agent Card and the agent's
functional characteristics remain unchanged.
Conversely, multiple runtime instances may share one
externally visible service endpoint, in which case the
individual backend instances do not need to be represented
separately in DAWN discovery.
The key requirement for bootstrap discovery is that the
Discovery Information returned to the requester reflect the
current externally relevant endpoint, protocol, and other
information needed to continue.
Only the discovery-relevant subset of infrastructure state
needs to be exposed to DAWN. Internal placement details,
backend topology, load, accelerator state, and other
information used for resource optimization or selection are
not required.
The Resource State Hook does not specify registration,
record-management, or orchestration procedures. Those
procedures may already exist in the deployment and remain
outside the scope of DAWN.
6.1. Logical Service vs. Instance Exposure
Where multiple runtime instances share a stable external
service endpoint, DAWN discovery can expose the logical
service rather than individual backend instances.
For example:
Document-Analysis-Agent
|
v
Stable Service Endpoint
|
+----+----+----+
| | | |
A B C D
In this case, the discovery-relevant resource state may
correspond to the logical service:
Dunbar, et al. Expires April 29, 2027 [Page 23]
Internet-Draft Infrastructure Assisted Discovery
Logical-Service-Identifier: Document-Analysis-Agent
Endpoint: https://document-agent.example
Protocol: A2A
Agent-Card-Reference:
https://document-agent.example/.well-known/agent-card.json
Changes in the number of backend instances do not require the
DAWN discovery information to change as long as the
externally visible service endpoint and other discovery
information remain unchanged.
Where an individual instance itself has a distinct externally
reachable identity or endpoint, a deployment may expose that
instance instead.
Similarly, if different externally reachable instances are
associated with different Attachment Scopes or discovery
domains, the deployment may expose them through the
corresponding discovery scope or bootstrap entry point.
The choice between exposing a logical service or an
individual instance is a deployment property and does not
require DAWN to model the internal scaling topology.
DAWN bootstrap discovery only needs the externally relevant
information required to reach the discoverable resource;
internal scaling and backend-instance management remain
outside the scope of this document.
6.2. Cloud Deployment Example
An A2A agent hosted on a Kubernetes-based cloud platform may
be exposed through a stable Service, ingress gateway, or
other externally reachable endpoint.
When the common externally reachable endpoint remains stable,
backend Pod creation, removal, or rescheduling need not
affect DAWN discovery information.
For example:
A2A Agent Service
|
v
Kubernetes Service / Ingress
|
Dunbar, et al. Expires April 29, 2027 [Page 24]
Internet-Draft Infrastructure Assisted Discovery
v
Externally Reachable Endpoint
|
+---+---+---+
| | | |
Pod Pod Pod Pod
Changes in the number or placement of backend Pods do not
require the Discovery Information returned by DAWN discovery
to change as long as the externally visible endpoint and
other discovery-relevant information remain unchanged.
If the externally visible endpoint changes because the
service is moved to another cluster, the discovery-relevant
resource state may change accordingly.
For example:
Before:
Endpoint: https://cluster-a.example/agent
After:
Endpoint: https://cluster-b.example/agent
The orchestration or hosting infrastructure that already
manages the service can make the new endpoint available to
the discovery mechanism through the Resource State Hook.
The Agent Card and other richer agent-specific metadata may
remain unchanged because the agent's functional
characteristics have not changed.
How the orchestrator detects the change, maintains the
deployment state, or updates DNS or other discovery records
is deployment-specific and outside the scope of this
document.
6.3. 5G Edge Deployment Example
An AI-agent service may be available from several edge
environments associated with different access or routing
contexts.
Consider two runtime instances of the same logical AI-agent
service:
Dunbar, et al. Expires April 29, 2027 [Page 25]
Internet-Draft Infrastructure Assisted Discovery
Edge Orchestrator
/ \
v v
Edge-A Edge-B
Agent-A Agent-B
| |
UPF-A UPF-B
The deployment infrastructure may maintain current discovery-
relevant state for the two externally reachable instances,
for example:
Agent-A
Logical-Service: Vision-Inference
Endpoint: https://vision-a.edge.example
Attachment-Scope: AScope-A
Agent-B
Logical-Service: Vision-Inference
Endpoint: https://vision-b.edge.example
Attachment-Scope: AScope-B
The Attachment Scopes abstract deployment-specific
information associated with each edge environment. For
example, `AScope-A` may be derived from information such as
UPF-A, a DNN, network slice, tenant context, or edge domain.
Separately, network infrastructure can map the requester's
current access or routing context to an abstract Attachment
Scope. Deployment policy can then map that scope to the
appropriate DAWN discovery domain or bootstrap entry point.
The requester does not need to know or explicitly signal the
serving UPF, DNN, network slice, or edge-domain identifiers
used to derive this mapping.
If Agent-A moves to another edge environment, its externally
reachable endpoint or associated Attachment Scope may change
while the logical service and richer agent metadata remain
unchanged. The infrastructure that already manages the
deployment can make the updated discovery-relevant state
available through the Resource State Hook.
Dunbar, et al. Expires April 29, 2027 [Page 26]
Internet-Draft Infrastructure Assisted Discovery
For example:
Before:
Endpoint: https://vision-a.edge.example
Attachment-Scope: AScope-A
After:
Endpoint: https://vision-c.edge.example
Attachment-Scope: AScope-C
How the edge orchestrator detects the move, maintains
deployment state, or updates the underlying DNS or discovery
records is deployment-specific and outside the scope of this
document.
The DAWN result remains the minimum public discovery
information needed to reach the resource through the
applicable discovery scope. Infrastructure assistance does
not require the requester to understand the underlying 5G-
specific network context.
6.4. Resource-State Changes
Discovery-relevant resource state can change as a result of
events such as:
- initial service deployment;
- endpoint assignment or change;
- migration to another hosting or edge environment;
- gateway change;
- Attachment Scope change;
- failure or unavailability; or
- service withdrawal.
Backend scale-out or scale-in does not necessarily change the
discovery-relevant resource state when the externally visible
service endpoint remains unchanged.
A managed deployment may reflect relevant changes through DNS
management, orchestration APIs, controller-specific
mechanisms, or other existing operational procedures. These
procedures are outside DAWN; this document only assumes that
Dunbar, et al. Expires April 29, 2027 [Page 27]
Internet-Draft Infrastructure Assisted Discovery
sufficiently current discovery-relevant state can be made
available to the discovery mechanism through the Resource
State Hook.
7. Attachment Scope Determination and Update
Attachment Scope is an abstraction of requester-side network
or administrative context that may contribute to the MVD. It
can be used to determine the appropriate discovery scope or
bootstrap entry point without exposing the underlying
deployment-specific information to the requester or discovery
mechanism.
The network may derive Attachment Scope from one or more
constructs, including:
- access network;
- site, cell, or tracking area;
- serving UPF or UPF group;
- DNN;
- network slice;
- VPN or VRF;
- enterprise or tenant context;
- edge domain; or
- other network reachability or deployment-specific state.
For example:
UPF: UPF-A
DNN: enterprise-ai
Slice: Slice-1
Enterprise: Enterprise-A
|
v
Attachment-Scope: AScope-A
Dunbar, et al. Expires April 29, 2027 [Page 28]
Internet-Draft Infrastructure Assisted Discovery
The discovery mechanism does not need to understand the raw
inputs or how "AScope-A" was derived. It only needs the
resulting abstract scope when that information is used as
part of the MVD to determine the appropriate discovery
domain, resolver view, local discovery environment, or
bootstrap entry point.
7.1. Policy-Based Mapping
The mapping from deployment-specific network or
administrative state to Attachment Scope can be many-to-one.
For example:
UPF-A + DNN-X ----+
|
UPF-B + DNN-X ----+--> AScope-X
|
VPN-X ------------+
This allows different underlying network constructs to be
represented by the same abstract Attachment Scope.
A deployment can then map that Attachment Scope to one or
more DAWN discovery domains, local discovery scopes, or
bootstrap entry points.
This many-to-one abstraction avoids exposing network-specific
identifiers to the requester and enables the discovery
process to remain independent of any particular access,
routing, or cloud technology. The discovery mechanism does
not need to understand whether "AScope-X" was derived from a
UPF and DNN, a VPN, or another deployment-specific construct.
7.2. Requester Attachment Scope
The requester can issue an ordinary DAWN discovery request
using the bootstrap information supported by the discovery
mechanism, such as an organization FQDN, a known AI-resource
identifier, or a local service type.
Separately, trusted network infrastructure determines the
requester's current Attachment Scope based on network
attachment or administrative state and supplies it to the
discovery mechanism as part of the MVD:
Attachment-Scope: AScope-A
Dunbar, et al. Expires April 29, 2027 [Page 29]
Internet-Draft Infrastructure Assisted Discovery
The discovery mechanism can combine the requester-provided
bootstrap information with the network-provided Attachment
Scope when determining the appropriate discovery domain,
local discovery scope, resolver view, or bootstrap entry
point.
The requester therefore does not need to know or signal
network-specific information such as its serving UPF, network
slice, DNN, VPN, VRF, or edge-domain association.
7.3. Scope Policy
A requester Attachment Scope does not need to map to a single
discovery scope. Deployment policy may map an Attachment
Scope to one or more DAWN discovery domains, local discovery
scopes, resolver views, or bootstrap entry points.
For example, a requester associated with AScope-Edge-A may
first use an edge-local discovery domain and, where
deployment policy permits, may also use broader metropolitan
or shared-cloud discovery domains:
Requester Attachment Scope:
AScope-Edge-A
Deployment Mapping:
AScope-Edge-A
|
+--> edge-a.agent.example
|
+--> metro.agent.example
|
+--> shared.agent.example
The mapping allows the discovery process to reflect
deployment relationships among edge, regional, and shared
environments without exposing the network-specific
information from which the requester's Attachment Scope was
derived.
Deployment policy determines which discovery scope, domain,
resolver view, or bootstrap entry point may be used for DAWN
bootstrap discovery. It does not define capability matching,
candidate ranking, or selection among AI resources.
Dunbar, et al. Expires April 29, 2027 [Page 30]
Internet-Draft Infrastructure Assisted Discovery
7.4. Mobility and Reassociation
Attachment Scope can change when the requester:
- moves between access areas;
- changes serving UPF or serving gateway;
- changes DNN;
- changes network slice;
- moves between VPN or tenant contexts;
- moves between Wi-Fi and cellular access; or
- enters another edge domain or region.
For example:
Before:
UPF-A -> AScope-A
After reassociation:
UPF-B -> AScope-B
A subsequent DAWN discovery operation can use the requester's
current Attachment Scope to determine the appropriate
discovery scope, domain, resolver view, or bootstrap entry
point for the new network context.
Attachment Scope may be updated through infrastructure
events, determined at discovery time, or cached with an
appropriate validity period.
The mechanism used to detect mobility or reassociation, and
the policy used to map the resulting network state to an
Attachment Scope, are deployment-specific and outside the
scope of DAWN.
Dunbar, et al. Expires April 29, 2027 [Page 31]
Internet-Draft Infrastructure Assisted Discovery
8. Applying the Model to DNS-SD
This section illustrates how the infrastructure-assisted
discovery model described in Section 5 can be applied to DNS-
SD [RFC6763]. Infrastructure-provided information may
contribute to the MVD used for bootstrap discovery without
requiring changes to the DNS-SD protocol.
The Resource State Hook can keep the DNS-SD representation of
a discoverable AI resource aligned with its externally
visible endpoint. The Attachment Context Hook can help
determine which DNS-SD discovery domain, local discovery
scope, or resolver view is appropriate for the requester.
The general roles of requester-provided bootstrap
information, current resource state, Attachment Scope, and
discovery processing are defined in Section 5 and are not
repeated here.
No change to the DNS-SD query or response protocol is
required by this document.
8.1. DNS-SD Mapping
DNS-SD [RFC6763] represents service discovery using service
types, service-instance enumeration, and endpoint resolution.
The infrastructure-assisted model maps onto those mechanisms
as follows:
Current AI-Resource State
|
v
DNS-SD Representation
PTR -> discoverable service instances
SRV -> reachable target and port
TXT -> limited discovery information
or reference to agent metadata
For example, an AI-agent instance may be represented as:
Vision-Agent-A._example-agent._tcp.example.com.
Dunbar, et al. Expires April 29, 2027 [Page 32]
Internet-Draft Infrastructure Assisted Discovery
with an SRV record identifying:
vision-a.edge.example.com.:443
and TXT information such as:
protocol=A2A
metadata=https://vision-a.edge.example.com/
.well-known/agent-card.json
The service type, instance naming convention, and TXT
attributes shown above are illustrative. This document does
not define a new DNS-SD service type or new TXT keys.
For DAWN bootstrap discovery, deployments should avoid
placing rich agent capabilities, skills, ranking metrics, or
other information used for catalog search or resource
selection into DNS-SD merely for infrastructure assistance. A
protocol identifier or reference needed for subsequent
interaction may be carried when defined by the applicable
discovery specification.
8.2. DNS-SD Resource Representation
When DNS-SD is used, authorized deployment infrastructure can
make current discovery-relevant resource state available to
the DNS-SD publishing system.
Conceptually:
AI-Agent Deployment State
|
v
Resource State Hook
|
+--> PTR: service-instance enumeration
|
+--> SRV: reachable target and port
|
+--> TXT: limited discovery information
or metadata reference
A represented resource may correspond either to a logical AI-
agent service or to an individually reachable instance, as
described in Section 6.1.
Dunbar, et al. Expires April 29, 2027 [Page 33]
Internet-Draft Infrastructure Assisted Discovery
When an externally visible endpoint changes, the
corresponding DNS-SD information can be updated without
requiring unrelated agent metadata to change. When a resource
is no longer externally reachable, its DNS-SD representation
may be removed using the mechanisms already supported by the
deployment.
For example, an authorized controller may maintain DNS
records on behalf of an AI-agent service. Where Dynamic DNS
is used, DNS UPDATE [RFC2136] can be used to add, modify, or
remove DNS resource records. Other deployments may use
authoritative DNS management interfaces, orchestration APIs,
or controller-specific mechanisms.
The mechanisms by which DNS records are created, updated, or
withdrawn are existing DNS or operational procedures and are
outside the scope of this document. The Resource State Hook
does not define a new registration, record-management, or
DNS-update protocol.
8.3. Applying Attachment Scope
The requester's Attachment Scope is provided to the discovery
function through the Attachment Context Hook described in
Section 7. It does not need to be carried in the DNS-SD query
or exposed in the DNS-SD response.
A deployment can use Attachment Scope to determine the DNS-SD
discovery domain, local discovery scope, or managed resolver
view appropriate for the requester.
8.3.1. Scope-to-Domain Mapping
A deployment can associate an Attachment Scope with one or
more DNS-SD discovery domains.
For example:
Attachment-Scope: AScope-Edge-A
|
+--> edge-a.agent.example
|
+--> shared.agent.example
Dunbar, et al. Expires April 29, 2027 [Page 34]
Internet-Draft Infrastructure Assisted Discovery
The requester can issue an ordinary DAWN bootstrap discovery
request without knowing which DNS-SD domain corresponds to
its current network attachment.
The discovery function combines the requester-provided
bootstrap information with the infrastructure-provided
Attachment Scope and determines the appropriate DNS-SD
discovery domain or domains.
DNS-SD discovery can then be performed within those domains
using the procedures defined in [RFC6763].
This approach allows the DNS-SD discovery domain to reflect
requester context without requiring the requester to know the
network-specific information from which that context was
derived.
The mapping from Attachment Scope to DNS-SD discovery domain
is deployment policy.
8.3.2. Context-Specific Discovery Scope
Another deployment may provide a context-specific DNS view,
local discovery scope, or resolver view rather than exposing
a common namespace and subsequently filtering a catalog of
AI-agent instances.
For example, two requesters using the same DAWN discovery
mechanism but associated with different Attachment Scopes may
be directed to different DNS-SD discovery domains:
AScope-A --> edge-a.agent.example
AScope-B --> edge-b.agent.example
The important property is that infrastructure-provided
context influences where bootstrap discovery is performed,
while DNS-SD continues to provide the service-discovery
exchange defined by [RFC6763].
The Attachment Scope itself does not need to be encoded in a
generally visible DNS-SD TXT record or returned to the
requester.
Dunbar, et al. Expires April 29, 2027 [Page 35]
Internet-Draft Infrastructure Assisted Discovery
This document does not define post-enumeration semantic
filtering, capability matching, candidate ranking, or
resource selection.
8.4. Agent Metadata in DNS-SD
DAWN bootstrap discovery should carry only the minimum public
discovery information needed to reach the AI resource and
continue with subsequent interaction.
A deployment may place limited discovery information in DNS-
SD TXT records, such as a supported protocol or a reference
to richer agent-native metadata. For example:
protocol=A2A
metadata=https://vision-a.edge.example/
.well-known/agent-card.json
For an A2A deployment, richer information such as supported
interfaces, capabilities, skills, security requirements, or
other interaction characteristics may be obtained
subsequently from the Agent Card.
The complete Agent Card does not need to be duplicated in
DNS-SD TXT records.
The choice of which minimum discovery information is
represented directly in DNS-SD and which richer information
is retrieved subsequently is determined by the applicable
discovery specification and deployment.
8.5. Discovery Result
The DNS-SD realization returns the normal DNS-SD information
needed to identify and resolve the discovered service
instance within the applicable discovery scope.
For example, the resulting information may correspond to:
Dunbar, et al. Expires April 29, 2027 [Page 36]
Internet-Draft Infrastructure Assisted Discovery
Resource-Identifier: Vision-Agent-A
Endpoint: https://vision-a.edge.example
Protocol: A2A
Metadata-Reference:
https://vision-a.edge.example/.well-known/agent-card.json
For DNS-SD, the target host and port are resolved using the
normal SRV and address-resolution procedures defined by
[RFC6763] and [RFC2782].
The Attachment Scope used to determine the discovery scope
does not need to be returned to the requester. It is
infrastructure-provided context used during bootstrap rather
than information required for subsequent agent communication.
A DNS-SD result may contain multiple service instances. Where
SRV records are used, the Priority and Weight procedures
defined by [RFC2782] continue to apply according to their
defined semantics.
If multiple AI resources are subsequently available, any
semantic comparison, capability matching, ranking, or
resource-selection procedure is outside the scope of this
document.
Additional agent-specific metadata, such as an A2A Agent
Card, may be retrieved subsequently as described in Section
10.
This document does not change the DNS-SD response format.
8.6. Caching and Freshness
AI-resource connectivity information and requester context
can change independently and can therefore have different
validity periods.
For example:
- an externally reachable endpoint can change;
- an AI resource can move to another edge site;
- a resource can become unavailable;
Dunbar, et al. Expires April 29, 2027 [Page 37]
Internet-Draft Infrastructure Assisted Discovery
- an Attachment Scope associated with a deployment can
change; or
- a requester can move to a different Attachment Scope.
The infrastructure that maintains current resource state can
make such changes available to the discovery system through
the Resource State Hook.
When DNS is used, normal DNS TTL semantics apply. Deployments
in which agent endpoints or placement change frequently can
use TTL values appropriate to the expected lifetime of the
DNS information.
Very dynamic deployment information should not be treated as
indefinitely valid merely because it was returned by an
earlier discovery operation.
Attachment Scope can have a lifetime independent of the
lifetime of DNS resource records. For example:
Before:
AScope-A
After reassociation:
AScope-B
Previously obtained DNS information may still be present in a
cache when the requester's Attachment Scope changes.
A new discovery operation should therefore use the
requester's current context rather than assume that a
previously derived Attachment Scope remains valid
indefinitely.
Implementations should avoid treating cached DNS information
and cached Attachment Scope as having the same validity
period unless deployment policy explicitly defines them that
way.
Dunbar, et al. Expires April 29, 2027 [Page 38]
Internet-Draft Infrastructure Assisted Discovery
8.7. No Result
A bootstrap operation may fail to obtain discovery
information from the discovery scope identified for the
requester.
For example, a DNS-SD enumeration within the discovery domain
associated with the requester's current Attachment Scope may
return no service instance.
The underlying DNS-SD mechanism can return its normal no-
result or error indication.
A deployment may define policy that causes a subsequent
bootstrap operation to use another permitted discovery domain
or scope, for example moving from an edge-local discovery
scope to a broader organizational or shared-cloud discovery
scope.
Such fallback is deployment policy. This document does not
define fallback to a catalog search, semantic matchmaking
procedure, candidate-ranking function, or resource-selection
mechanism.
9. Applying the Model to DNS-AID
DNS for AI Discovery (DNS-AID) [DNS-AID] uses existing DNS
mechanisms to provide AI-agent connectivity and discovery
information. For a known agent, DNS-AID uses SVCB records to
provide information such as endpoint, transport, and agent
protocol. DNS-AID also defines an organization-level
_index._agents.<domain> entry point that can be used to
locate an organization-specific agent index.
This section uses DNS-AID as an example of a DNS-based
bootstrap mechanism. The infrastructure-assisted model in
Section 5 can complement DNS-AID in managed enterprise,
cloud, edge, and communication-network environments.
The Resource State Hook can help keep DNS-AID-visible
endpoint and protocol information aligned with current
deployment state. The Attachment Context Hook can provide
requester context that helps determine the DNS namespace,
resolver view, or bootstrap entry point appropriate for the
requester.
Dunbar, et al. Expires April 29, 2027 [Page 39]
Internet-Draft Infrastructure Assisted Discovery
Attachment Scope is not required to be encoded in DNS-AID
SVCB records or carried in DNS queries. Infrastructure
assistance is applied around the DNS-AID mechanism and does
not change the DNS-AID wire format.
The model does not depend on an organization-wide catalog
search being part of DAWN. Any catalog or index reached
through a DNS-AID bootstrap entry point that performs richer
search, matching, or resource selection is a subsequent
function outside the scope of this document.
9.1. DNS-AID Mapping
The Resource State Hook can make current AI-agent deployment
state available to the system that maintains the discovery
information exposed through DNS-AID.
Conceptually:
AI-Agent Deployment State
|
v
Resource State Hook
|
+--> Agent SVCB information
endpoint
transport
agent protocol
metadata reference, if applicable
For a known agent or organization-level bootstrap name,
current deployment state can therefore be reflected in the
DNS-AID information needed to locate the externally reachable
endpoint and identify the protocol used for subsequent
interaction.
For example, if an externally reachable endpoint changes
while the logical AI-agent service remains the same, the
corresponding DNS-AID-visible endpoint information can change
without requiring unrelated agent-native metadata to change.
Similarly, if an AI resource is no longer intended to be
externally reachable, the infrastructure that manages the
deployment can make that state available to the system
responsible for the corresponding DNS information.
The Resource State Hook describes only the logical
contribution of current discovery-relevant state. It does not
Dunbar, et al. Expires April 29, 2027 [Page 40]
Internet-Draft Infrastructure Assisted Discovery
define how DNS-AID records or associated DNS information are
created, updated, withdrawn, or otherwise managed. Those
procedures remain part of the underlying DNS or deployment
infrastructure and are outside the scope of this document.
Where DNS-AID uses an organization-level
`_index._agents.<domain>` bootstrap entry point,
infrastructure assistance can help keep the entry-point
information aligned with the current deployment. The
contents, synchronization, and search behavior of any
organization-specific catalog or index reached through that
entry point are outside the scope of this document.
9.2. Applying Attachment Scope to DNS-AID
In a managed environment, the Attachment Context Hook can
provide the requester's current Attachment Scope to the
discovery function before or while the DNS-based bootstrap
operation is performed.
Deployment policy can use this context to determine the DNS
namespace, resolver view, or bootstrap entry point
appropriate for the requester.
For example:
Requester Attachment Scope:
AScope-Edge-A
|
+--> edge-a.agents.example
|
+--> _index._agents.edge-a.example
Another requester associated with a different Attachment
Scope may be directed to a different DNS namespace, resolver
view, or bootstrap entry point.
The requester does not need to know the UPF, DNN, VPN,
network slice, tenant context, or edge-domain information
from which the Attachment Scope was derived.
Dunbar, et al. Expires April 29, 2027 [Page 41]
Internet-Draft Infrastructure Assisted Discovery
The Attachment Scope itself need not be encoded in DNS
records or DNS queries and does not need to be returned to
the requester.
This model uses Attachment Scope to determine where DNS-AID
bootstrap discovery is performed. It does not require DNS-AID
to filter a common organization-wide inventory of agents
according to Attachment Scope.
9.3. Relationship to DNS-AID Results
Infrastructure assistance does not change the DNS-AID result
format.
For a known-agent lookup, the requester receives the DNS-AID
information needed to locate and connect to the AI resource,
including the minimum public discovery information required
for subsequent interaction.
For an organization-level bootstrap, DNS-AID may provide an
entry point to another service, such as an organization-
specific index. The DAWN bootstrap operation ends once the
information needed to reach that subsequent service has been
obtained.
Any operation performed after that point to search an
organization catalog, compare capabilities, identify
candidate agents, rank multiple resources, or select an
optimal instance is outside the scope of this document.
Thus, infrastructure assistance affects the current endpoint
information and the DNS scope or bootstrap entry point used
by DNS-AID, but it does not turn DNS-AID into a catalog-
search or resource-selection mechanism.
10. Second-Stage Agent Metadata Retrieval
DAWN discovery is a bootstrap step. After obtaining the
minimum public discovery information needed to reach an AI
resource, the requester may retrieve richer protocol-specific
information using the agent's native mechanism when needed.
For A2A:
Dunbar, et al. Expires April 29, 2027 [Page 42]
Internet-Draft Infrastructure Assisted Discovery
DAWN Discovery Information
|
v
Agent Endpoint / Agent Card Reference
|
v
Retrieve Agent Card
|
v
Identity, Capabilities, Skills, Interfaces,
Security Information, Interaction Requirements
The Agent Card can provide richer information needed for
subsequent interaction without requiring that information to
be duplicated in the DAWN discovery mechanism.
Other AI-agent protocols may use different protocol-specific
descriptors or metadata mechanisms.
This separation allows DAWN discovery to remain lightweight
and focused on bootstrap information while avoiding the need
for one general discovery mechanism to reproduce all
protocol-specific agent metadata.
Any subsequent capability search, semantic matching,
authorization, or interaction based on the retrieved agent-
native metadata is outside the scope of this document.
11. Alternative Realizations
The infrastructure-assisted model is intended to be applied
around existing DAWN-compatible discovery mechanisms rather
than replace them.
Examples include:
- mDNS/DNS-SD for local discovery;
- DNS-based bootstrap discovery for an organization or known
agent;
- managed DNS resolver views or discovery-domain mappings
that already exist in a deployment; or
Dunbar, et al. Expires April 29, 2027 [Page 43]
Internet-Draft Infrastructure Assisted Discovery
- another DAWN-compatible bootstrap discovery mechanism.
The Resource State Hook and Attachment Context Hook describe
logical inputs to the discovery process. They do not define a
registry, catalog, federation protocol, orchestration API, or
new wire format.
The Resource State Hook may be implemented by infrastructure
such as:
- Kubernetes or cloud orchestration;
- serverless hosting infrastructure;
- MEC orchestration;
- an application gateway;
- a service mesh;
- an enterprise AI platform; or
- another deployment controller.
Attachment Scope may be derived from:
- 5G network state;
- enterprise VPN or VRF state;
- Wi-Fi infrastructure;
- cloud networking;
- SD-WAN state;
- edge-controller state; or
- combinations of these.
Resource state and Attachment Scope may have different
lifetimes and may be obtained or refreshed through different
mechanisms. They may be updated through infrastructure
events, queried dynamically, periodically refreshed, or
cached with an appropriate validity period.
Agent-native metadata may be represented using an A2A Agent
Card, MCP metadata, another protocol-specific descriptor, or
a deployment-specific format. Such richer metadata is
separate from the minimum public discovery information
returned by DAWN bootstrap discovery.
Where a deployment also uses a registry, directory, catalog,
or federated discovery system, that system may consume
infrastructure-maintained state, but its registration,
synchronization, search, federation, ranking, and resource-
selection procedures are outside the scope of this document.
Dunbar, et al. Expires April 29, 2027 [Page 44]
Internet-Draft Infrastructure Assisted Discovery
12. Security Considerations
Requester context, including Attachment Scope, may be derived
from sensitive network or administrative information.
The discovery mechanism should receive only the abstraction
needed for bootstrap discovery and should avoid unnecessary
exposure of information such as:
- subscriber or user identity;
- physical access port;
- precise geographic location;
- internal network topology;
- routing identifiers;
- detailed network configuration; or
- other deployment-specific information not required for
discovery.
Infrastructure that supplies resource state or requester
context must be authorized and trusted by the deployment.
A requester should not be able to obtain a different
discovery scope merely by asserting an untrusted Attachment
Scope. Attachment Scope used as part of the MVD should
therefore be obtained from trusted infrastructure or
otherwise validated according to deployment policy.
Similarly, the Resource State Hook requires appropriate
authentication and authorization so that unauthorized systems
cannot introduce, alter, or remove discovery-relevant
resource information.
Current resource state also requires appropriate integrity
and freshness protection so that bootstrap discovery does not
return stale or attacker-controlled endpoint, protocol, or
other connectivity information.
The Resource State Hook and Attachment Context Hook describe
logical inputs and do not define new authentication,
authorization, or trust-management mechanisms. Deployments
should use the security mechanisms associated with the
underlying discovery, DNS, orchestration, and network-
management systems.
Dunbar, et al. Expires April 29, 2027 [Page 45]
Internet-Draft Infrastructure Assisted Discovery
Discovery information can reveal the existence and
reachability of AI resources. Deployments should therefore
apply appropriate visibility and access policies to that
information.
Infrastructure assistance does not itself authorize use of a
discovered AI resource. Authentication, authorization, trust
evaluation, and subsequent communication follow the
mechanisms used by the discovered service and remain outside
the scope of this document, except where needed to protect
the discovery information and infrastructure inputs
themselves.
13. IANA Considerations
TBD
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS
UPDATE)", RFC 2136, April 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A
DNS RR for specifying the location of services (DNS
SRV)", RFC 2782, February 2000.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery," RFC 6763, February 2013.
[A2A] Agent2Agent Protocol, "Agent2Agent Protocol
Documentation", https://a2a-protocol.org/.
Dunbar, et al. Expires April 29, 2027 [Page 46]
Internet-Draft Infrastructure Assisted Discovery
[AGENT-ATTACHMENT] Dunbar, L., et al., "Agent Attachment
Protocol," Work in Progress.
[DAWN-FRAMEWORK] Zhang, B., Dunbar, L. and Y. Yang, "A
Framework for Agent Discovery in DAWN", draft-
zhang-dawn-agent-discovery-framework-07, Work in
Progress.
[DAWN-MDNS] Jakab, L. and Brockners, F., "Zero-Configuration
Agent Discovery," draft-jakab-dawn-agent-discovery-
mdns, Work in Progress.
[DAWN-USE-CASES] King, D., et al., "Use Cases and
Applicability for Discovery of Agents With Names,"
Work in Progress.
[DAWN-MDI] Cui, et al., "Minimum Discoverable Information for
DAWN," Work in Progress.
[DNS-AID] Mozley, Williams, Sarikaya, Schott, and Damick,
"DNS for AI Discovery," draft-mozleywilliams-dnsop-
dnsaid-02.
[MCP] Model Context Protocol, "Model Context Protocol
Specification",
https://modelcontextprotocol.io/specification/
[DAWN-TERMINOLOGY] Farrel, A., et al., "Terminology for
Discovery of Agents With Names (DAWN)", draft-
farrel-dawn-terminology, Work in Progress.
15. Acknowledgments
Acknowledgements to xxx for their extensive review and
suggestions.
This document was prepared using 2-Word-v2.0.template.dot.
Dunbar, et al. Expires April 29, 2027 [Page 47]
Internet-Draft Infrastructure Assisted Discovery
Appendix A:
Authors' Addresses
Linda Dunbar
Futurewei
Email: ldunbar@futurewei.com
Bin Zhang
Pengcheng Laboratory
Email: zhangb@pcl.ac.cn
Contributors' Addresses
Dunbar, et al. Expires April 29, 2027 [Page 48]