Network Working Group L. Dunbar
Internet Draft Futurewei
Intended status: Informational B. Zhang
Expires: April 15, 2027 Pengcheng Lab
October 15, 2026
Infrastructure-Assisted Discovery for AI Agents
draft-dunbar-dawn-infra-assisted-discovery-01
Abstract
This document describes an infrastructure-assisted approach
to AI-agent discovery. An orchestration, placement, or
hosting system can publish current deployment and
reachability information for available AI-agent services or
instances. Separately, network infrastructure can derive an
abstract Attachment Scope representing the network context
applicable to a requester. A discovery mechanism combines
requester intent, currently published AI-agent resources, and
the requester's Attachment Scope to identify applicable agent
instances.
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
xxx, et al. Expires April 15, 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 13, 2026 .
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.........................5
3. Problem Statement.........................................6
4. Gap Analysis: DNS-SD and AI-Agent Discovery...............8
4.1. Service Type Limitations.............................9
4.2. External Deployment State...........................10
4.3. Discovery Domain vs. Network Scope..................11
4.4. Hidden Network Context..............................12
4.5. Discovery vs. Selection.............................12
5. Infrastructure-Assisted Discovery Model..................13
5.1. Requester Criteria..................................14
5.2. Published Resource State............................14
5.3. Requester Scope.....................................15
5.4. Discovery Processing................................15
5.5. Metadata and Deployment State.......................16
5.6. Applicability Versus Selection......................17
5.7. Relationship to Specific Discovery Mechanisms.......17
6. Resource Publication and Update..........................18
6.1. Logical Service vs. Instance Publication............18
6.2. Cloud Deployment Example............................19
Dunbar, et al. Expires Dec 15, 2027 [Page 2]
Internet-Draft Infrastructure Assisted Discovery
6.3. 5G Edge Deployment Example..........................19
6.4. Publication Lifecycle...............................20
7. Attachment Scope Determination and Update................20
7.1. Policy-Based Mapping................................21
7.2. Requester Attachment Scope..........................21
7.3. Scope Policy........................................22
7.4. Mobility and Reassociation..........................23
8. Applying the Model to DNS-SD.............................23
8.1. DNS-SD Mapping......................................24
8.2. DNS-SD Publication..................................25
8.3. Applying Attachment Scope...........................26
8.3.1. Scope to Domain Mapping........................26
8.3.2. Filtering Resources After Enumeration..........27
8.4. Agent Metadata in DNS-SD............................28
8.5. Discovery Result....................................29
8.6. Caching and Freshness...............................30
8.7. No Match............................................31
9. Second-Stage Agent Metadata Retrieval....................32
10. Relationship to Resource Selection......................33
11. Alternative methods.....................................33
12. Security Considerations.................................34
13. IANA Considerations.....................................35
14. References..............................................35
14.1. Normative References...............................35
14.2. Informative References.............................35
15. Acknowledgments.........................................36
Appendix A:.................................................36
1. Introduction
AI-agent discovery is being explored in several DAWN
documents. The DAWN use-case work describes scenarios in
which clients need to discover AI resources and obtain
information required for subsequent interaction. Other DAWN
contributions examine gaps in existing discovery protocols,
identify information that may need to be discoverable,
describe local discovery using mDNS/DNS-SD, and propose
broader discovery architectures and frameworks.
This document complements those efforts by focusing on
managed enterprise, cloud, edge-computing, and communication-
network deployments in which infrastructure already maintains
information that can assist AI-agent discovery.
In such environments, orchestration, placement, hosting,
gateway, or management systems can provide current
Dunbar, et al. Expires Dec 15, 2027 [Page 3]
Internet-Draft Infrastructure Assisted Discovery
information about which AI-agent services or instances are
available and how they can be reached. Separately, network
infrastructure can provide an abstract "Attachment Scope"
representing the requester's current network applicability
context.
This document defines two infrastructure integration points:
o a "Resource Publication Hook", through which authorized
deployment infrastructure makes current AI-agent service or
instance information available to the discovery mechanism; and
o an "Attachment Context Hook", through which trusted network
infrastructure provides the requester's current Attachment
Scope.
The discovery mechanism combines these infrastructure-
provided inputs with requester-supplied discovery criteria
and relevant agent metadata to identify AI-agent resources
applicable to the request.
The proposed hooks are intended to assist existing discovery
mechanisms rather than replace them. For example, the local
discovery approach described in [DAWN-MDNS] reuses mDNS and
DNS-SD for AI-agent discovery. The infrastructure-assisted
model described here follows the same principle of reusing
existing discovery mechanisms, while adding support for
managed deployments in which agent deployment state and
requester network context are maintained by infrastructure.
Similarly, the Resource Publication Hook and Attachment
Context Hook can provide infrastructure-facing inputs to
broader DAWN discovery architectures, such as those described
in [DAWN-FRAMEWORK], without requiring those architectures to
depend on a particular access, cloud, or mobile-network
technology.
The infrastructure assistance described in this document uses
authorized control-plane or management information. It does
not require infrastructure to inspect, intercept, or
participate in agent-to-agent communications.
Dunbar, et al. Expires Dec 15, 2027 [Page 4]
Internet-Draft Infrastructure Assisted Discovery
This document does not define a new wire protocol. The model
can be applied to DNS-SD, registries, directories, federated
discovery systems, or other AI-agent discovery mechanisms.
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 BCP14 [RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown
here.
The following acronyms and terms are used in this document:
AI Agent: A software entity that uses artificial intelligence
techniques to interpret context, make decisions,
and take actions toward achieving one or more
goals, possibly by interacting with users and by
invoking other agents, tools, or services.
Attachment Context Hook: An infrastructure integration point
through which trusted network infrastructure
provides the requester's current Attachment Scope
to the discovery mechanism.
Attachment Scope: An abstract network-derived context
representing an attachment or reachability domain
applicable to a requester or discoverable
resource.
Discovery Mechanism: A mechanism that receives discovery
intent and returns one or more applicable AI-
agent resources. The mechanism may use DNS-SD, a
registry, a directory, a federated discovery
system, or another technique.
Logical AI-Agent Service: An AI-agent service whose
functional identity can remain stable while the
number, location, or endpoints of its runtime
instances change.
Dunbar, et al. Expires Dec 15, 2027 [Page 5]
Internet-Draft Infrastructure Assisted Discovery
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 Publication Hook: An infrastructure integration
point through which an authorized orchestration,
placement, hosting, gateway, or management system
makes current AI-agent service or instance
information 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 agent-specific
parameters.
A2A provides one example. An A2A Agent Card can describe an
agent's identity, supported interfaces, capabilities, skills,
security information, and other properties required for
interaction. Therefore, locating an AI-agent endpoint and
understanding how to interact with that agent can be separate
operations.
This creates an opportunity to use a lightweight discovery
stage to identify an applicable AI-agent service or instance
and then retrieve richer agent metadata through a subsequent
agent-specific mechanism.
Dunbar, et al. Expires Dec 15, 2027 [Page 6]
Internet-Draft Infrastructure Assisted Discovery
In managed deployments, information relevant to the
lightweight discovery stage may be distributed among several
infrastructure systems.
For example, an orchestration, placement, or hosting system
may know:
- which AI-agent services or instances currently exist;
- where an instance is deployed;
- which externally reachable endpoint corresponds to that
instance;
- whether multiple instances share a common service endpoint;
- when an instance is moved or replaced; and
- when an instance 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
useful for determining which AI-agent resources are
applicable to a requester. Such information can include:
- access-network attachment;
- enterprise or tenant context;
- VPN or routing context;
- DNN;
- network slice;
- serving UPF or UPF group;
- edge-computing domain; or
- another reachability-related network context.
Requiring the requester to understand and explicitly include
such network information can couple application-layer
Dunbar, et al. Expires Dec 15, 2027 [Page 7]
Internet-Draft Infrastructure Assisted Discovery
discovery to network-specific technologies. Conversely,
exposing detailed network topology or low-level identifiers
directly through an AI-agent discovery mechanism can create
unnecessary complexity and information exposure.
Deployment information and rich 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 skills, interfaces, authentication model,
and Agent Card. Changes to deployment location or endpoint do
not necessarily require changes to the agent's functional
metadata, such as its capabilities, skills, supported
interfaces, or Agent Card.
There is therefore value in separating:
- information describing what an AI agent is and how it can
be used;
- information describing where currently deployed instances
can be reached; and
- information describing the requester's current attachment
or reachability context.
There is therefore a need to combine requester-provided
discovery criteria and relevant agent metadata with current
deployment information and network-derived Attachment Scope,
without requiring the requester to understand network
specific attachment details.
The infrastructure-assisted discovery model described in this
document addresses this problem by allowing deployment and
network infrastructure to contribute this information to the
discovery process.
4. Gap Analysis: DNS-SD and AI-Agent Discovery
DNS-Based Service Discovery [RFC6763] provides a well-
established mechanism for discovering instances of a
particular service type within a discovery domain.
A client identifies a service type and domain and obtains
service instances. SRV records identify where an instance can
Dunbar, et al. Expires Dec 15, 2027 [Page 8]
Internet-Draft Infrastructure Assisted Discovery
be reached, while TXT records may provide a small amount of
additional service-specific information.
This model provides a useful foundation for AI-agent
discovery.
draft-jakab-dawn-agent-discovery-mdns applies this approach
to local AI-agent discovery and describes a two-stage model
in which DNS-SD performs lightweight enumeration and the
agent's native protocol subsequently provides the complete
agent description.
This document adopts that two-stage principle. However, DNS-
SD by itself does not address several deployment conditions
relevant to managed AI-agent environments.
4.1. Service Type Limitations
For many conventional services, knowing the service type,
host, port, and protocol can be sufficient to initiate
application-level communication.
AI-agent interaction may require additional information
before meaningful interaction can begin.
For example, an A2A requester may need to obtain an Agent
Card describing:
o supported interfaces;
o skills;
o capabilities;
o security requirements;
o interaction characteristics; and
o 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 in some deployments is to use lightweight
discovery to identify an applicable agent instance or
endpoint, and then retrieve richer agent-native metadata only
when needed before interaction:
Dunbar, et al. Expires Dec 15, 2027 [Page 9]
Internet-Draft Infrastructure Assisted Discovery
Lightweight discovery
|
v
Agent instance / endpoint
|
v
Retrieve agent-native metadata
|
v
Interaction
4.2. External Deployment State
Traditional DNS-SD commonly assumes that a service or the
system hosting it registers the appropriate service-discovery
information.
Managed AI-agent environments may involve additional
deployment abstraction.
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 capabilities
while having different endpoints or attachment contexts.
Alternatively, the three instances may sit behind one stable
service endpoint:
Vision Agent Service
|
Common Endpoint
|
+--------+--------+
| | |
A B C
Dunbar, et al. Expires Dec 15, 2027 [Page 10]
Internet-Draft Infrastructure Assisted Discovery
In this case, changes to the backend instances need not
change agent metadata or the externally published discovery
endpoint.
A discovery architecture therefore benefits from
distinguishing the logical AI-agent service from currently
deployed instances.
4.3. Discovery Domain vs. Network Scope
DNS-SD uses a discovery domain to determine where service
enumeration occurs.
In a managed communication network, however, the set of agent
instances applicable to a requester may depend on a network
context that is different from a DNS administrative domain.
For example, two requesters using the same DNS namespace may
be associated with:
o different enterprise VPNs;
o different DNNs;
o different network slices;
o different UPFs;
o different edge domains; or
o different tenant contexts.
Those requesters may therefore have access to different edge-
resident AI-agent instances even though they query the same
general service category.
Conversely, several underlying network states may belong to
the same discovery applicability domain.
For example:
UPF-A + DNN-X + Slice-1 ----+
|
UPF-B + DNN-X + Slice-1 ----+--> Attachment Scope X
|
VPN-X + Enterprise-A -------+
DNS-SD does not itself define such a mapping between
requester-side network state and discovery applicability.
Dunbar, et al. Expires Dec 15, 2027 [Page 11]
Internet-Draft Infrastructure Assisted Discovery
4.4. Hidden Network Context
A requester can reasonably know what type of AI-agent service
it seeks.
For example:
Service-Category: Vision-Inference
It should not necessarily need to know:
Serving-UPF
DNN
S-NSSAI
VRF
BNG
Access Circuit
Edge Domain
Those properties belong to the infrastructure.
Requiring an AI-agent application to understand them creates
unnecessary coupling between application discovery and
network architecture.
4.5. Discovery vs. Selection
Existing service-discovery and service-routing systems often
use region, zone, or locality information to steer a request
toward a preferred instance.
The Attachment Scope described in this document serves a
different initial purpose.
It identifies the network context within which an AI-agent
resource is applicable to a requester.
For example:
Requester Intent: Vision-Inference
Attachment Scope: AScope-A
Published Instances:
Agent-A -> AScope-A
Dunbar, et al. Expires Dec 15, 2027 [Page 12]
Internet-Draft Infrastructure Assisted Discovery
Agent-B -> AScope-B
Agent-C -> Shared-Cloud
The discovery mechanism may determine that Agent-A and Agent-
C are applicable.
A later selection mechanism can choose between them based on
latency, load, cost, GPU availability, or another dynamic
factor.
Thus:
Discovery: Which resources are applicable?
Selection: Which applicable resource should be used?
The two functions are intentionally separated.
5. Infrastructure-Assisted Discovery Model
The infrastructure-assisted discovery model combines
information from the requester, deployment infrastructure,
network infrastructure, and the discovery mechanism.
The purpose of the model is to allow infrastructure that
already maintains deployment and network state to contribute
that information to AI-agent discovery, without requiring the
requesting AI agent to understand the underlying deployment
or network-specific details.
The model uses three primary categories of information:
Requester Discovery Criteria
+
Published AI-Agent Resource State
+
Requester Attachment Scope
|
v
Discovery Mechanism
|
v
Applicable AI-Agent Resources
Dunbar, et al. Expires Dec 15, 2027 [Page 13]
Internet-Draft Infrastructure Assisted Discovery
5.1. Requester Criteria
The requester provides information describing what it wants
to discover.
The request may identify:
- a specific AI-agent resource;
- an AI-agent service category;
- a subtype;
- a supported interaction protocol;
- a capability or skill;
- or other agent-related discovery criteria supported by
the discovery mechanism.
The requester is not required to provide network-specific
information such as a serving UPF, DNN, network slice, VPN,
access point, or edge domain.
5.2. Published Resource State
Deployment infrastructure provides information describing the
AI-agent resources currently available for discovery.
This information can include:
o logical service identifier;
o instance identifier;
o reachable endpoint;
o communication protocol;
o current deployment state;
o Attachment Scope associated with the resource, when
applicable; and
o a reference to additional agent metadata.
The Resource Publication Hook described in Section 6 provides
this information to the discovery mechanism.
The published resource may represent either:
o a logical AI-agent service exposed through a stable
endpoint; or
Dunbar, et al. Expires Dec 15, 2027 [Page 14]
Internet-Draft Infrastructure Assisted Discovery
o an individually reachable runtime instance.
The choice depends on how the AI-agent service is deployed
and exposed.
Deployment infrastructure is responsible for keeping this
information consistent with the actual deployment state.
5.3. Requester Scope
Trusted network infrastructure determines the requester's
current Attachment Scope from network attachment or
reachability state.
The Attachment Scope abstracts network-specific information
such as:
o access attachment;
o VPN or routing context;
o DNN;
o network slice;
o serving UPF;
o tenant context; or
o edge domain.
The Attachment Context Hook described in Section 7 provides
the resulting Attachment Scope to the discovery mechanism.
The Attachment Scope is infrastructure-provided context. It
is not required to be supplied by the requester and does not
need to be exposed to the requester.
5.4. Discovery Processing
The discovery mechanism combines requester discovery criteria
with current published resource state and the requester's
Attachment Scope.
Dunbar, et al. Expires Dec 15, 2027 [Page 15]
Internet-Draft Infrastructure Assisted Discovery
The mechanism can also use agent metadata that it maintains,
indexes, or references.
Conceptually:
Agent Metadata
|
v
Requester Intent --> Candidate Identification
|
v
Candidate Resources
|
+------------------+
| |
v |
Attachment Scope |
| |
+--------+---------+
|
v
Applicability Processing
|
v
Applicable Resources
Agent-related criteria determine which resources can satisfy
the requester's functional intent.
Attachment Scope determines which of those candidate
resources are applicable from the requester's current network
context.
These two functions are complementary.
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, and security
requirements. The same logical agent service can be deployed
at several locations or moved between locations without
changing those properties.
Dunbar, et al. Expires Dec 15, 2027 [Page 16]
Internet-Draft Infrastructure Assisted Discovery
Conversely, deployment infrastructure can update an endpoint,
instance identifier, or associated Attachment Scope without
requiring the underlying functional description of the agent
to change.
The discovery mechanism may maintain or reference both kinds
of information, but they need not be represented or updated
in the same way.
5.6. Applicability Versus Selection
The result of infrastructure-assisted discovery is a set of
AI-agent resources that are applicable to the requester.
The discovery mechanism does not necessarily select the
optimal resource from that set.
For example, discovery may determine that two AI-agent
instances are both applicable:
Agent-A
Agent-B
A subsequent selection function can choose between them based
on factors such as latency, network condition, compute load,
accelerator availability, cost, or application policy.
The distinction between discovery applicability and resource
selection is described further in Section 10.
5.7. Relationship to Specific Discovery Mechanisms
The infrastructure-assisted model is independent of a
particular discovery protocol.
The Resource Publication Hook and Attachment Context Hook
provide inputs to the discovery process, while the underlying
discovery mechanism can use DNS-SD, a registry, a directory,
a federated discovery system, or another mechanism.
Section 8 describes how the model can be realized using DNS-
SD as an example.
Dunbar, et al. Expires Dec 15, 2027 [Page 17]
Internet-Draft Infrastructure Assisted Discovery
The model does not require changes to agent-to-agent
communication protocols and does not require infrastructure
to inspect the contents of agent communications.
6. Resource Publication and Update
The Resource Publication Hook allows deployment
infrastructure to maintain information about AI-agent
resources currently available for discovery.
The procedure can be illustrated using an A2A deployment.
An A2A Agent Card describes the agent's interaction-related
characteristics. The Resource Publication Hook instead
describes current deployment and reachability state.
For example:
Logical-Service-Identifier: Vision-Inference
Instance-Identifier: Vision-Agent-A
Service-Category: Vision-Inference
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
6.1. Logical Service vs. Instance Publication
Where multiple runtime instances share a stable service
endpoint:
Document-Analysis-Agent
|
v
Stable Service Endpoint
|
+----+----+----+
| | | |
A B C D
the discovery mechanism may publish only:
Logical-Service-Identifier: Document-Analysis-Agent
Endpoint: https://document-agent.example
Dunbar, et al. Expires Dec 15, 2027 [Page 18]
Internet-Draft Infrastructure Assisted Discovery
Protocol: A2A
Agent-Card-Reference:
https://document-agent.example/.well-known/agent-
card.json
Scaling from four instances to eight need not modify the
discovery publication.
If the instances are independently reachable or have
different Attachment Scopes, they may instead be published
individually.
6.2. Cloud Deployment Example
An A2A agent hosted on a Kubernetes-based cloud platform may
be exposed through a Kubernetes Service, ingress gateway, or
externally assigned endpoint.
When the common endpoint remains stable, backend Pod creation
or removal need not affect discovery.
If the externally visible endpoint changes because the
service is moved to another cluster:
Before:
Endpoint: cluster-a.example/agent
After:
Endpoint: cluster-b.example/agent
the orchestration infrastructure can update the publication
while the Agent Card remains unchanged.
6.3. 5G Edge Deployment Example
Consider two runtime instances of the same logical AI-agent
service:
Edge Orchestrator
/ \
v v
Edge-A Edge-B
Agent-A Agent-B
Dunbar, et al. Expires Dec 15, 2027 [Page 19]
Internet-Draft Infrastructure Assisted Discovery
| |
UPF-A UPF-B
The publications may be:
Agent-A
Logical-Service: Vision-Inference
Endpoint: vision-a.edge.example
Attachment-Scope: AScope-A
and:
Agent-B
Logical-Service: Vision-Inference
Endpoint: vision-b.edge.example
Attachment-Scope: AScope-B
If Agent-A moves to another edge environment, the
infrastructure can change its endpoint and scope or withdraw
the old instance and publish a new one.
6.4. Publication Lifecycle
Publication events can include:
- initial deployment;
- new instance creation;
- endpoint assignment;
- scale-out or scale-in;
- migration;
- gateway change;
- Attachment Scope change;
- failure or unavailability; and
- withdrawal.
The publication mechanism may be event-driven, controller-
driven, registry-based, DNS-based, or implemented through
another infrastructure interface.
7. Attachment Scope Determination and Update
Attachment Scope abstracts network state that is relevant to
discovery applicability.
Dunbar, et al. Expires Dec 15, 2027 [Page 20]
Internet-Draft Infrastructure Assisted Discovery
The network may derive Attachment Scope from one or more
constructs, including:
- access network;
- 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 state.
For example:
UPF: UPF-A
DNN: enterprise-ai
Slice: Slice-1
Enterprise: Enterprise-A
|
v
Attachment-Scope: AScope-A
The discovery mechanism does not need to understand how
AScope-A was derived.
7.1. Policy-Based Mapping
The mapping can be many-to-one:
UPF-A + DNN-X ----+
|
UPF-B + DNN-X ----+--> AScope-X
|
VPN-X ------------+
This enables a deployment to define discovery applicability
independently of a particular network technology.
7.2. Requester Attachment Scope
A requester may issue a discovery request such as:
Dunbar, et al. Expires Dec 15, 2027 [Page 21]
Internet-Draft Infrastructure Assisted Discovery
Service-Category: Vision-Inference
Separately, network infrastructure determines the requester's
current Attachment Scope based on network attachment state
and provides it to the discovery mechanism:
Attachment-Scope: AScope-A
The discovery mechanism combines the requester's discovery
criteria with the network-provided Attachment Scope when
determining applicable AI-agent resources.
The requester therefore does not need to know or supply
network-specific information such as its serving UPF, network
slice, DNN, VPN, or edge-domain association.
7.3. Scope Policy
Attachment Scope matching does not necessarily require the
requester and resource to have identical scope values. A
deployment may define relationships among scopes so that a
requester associated with one scope can discover resources
associated with the same scope or with other permitted
scopes.
For example, a requester associated with AScope-Edge-A may be
allowed to discover resources published for AScope-Edge-A, a
broader metropolitan scope, or a shared cloud scope:For
example:
Requester Attachment Scope:
AScope-Edge-A
Applicable Resource Scopes:
AScope-Edge-A
AScope-Metro
AScope-Shared-Cloud
A deployment may define policy that determines which resource
Attachment Scopes are applicable to a requester's Attachment
Scope. For example, a requester associated with AScope-Edge-A
Dunbar, et al. Expires Dec 15, 2027 [Page 22]
Internet-Draft Infrastructure Assisted Discovery
may be permitted to discover resources published for AScope-
Edge-A and AScope-Shared-Cloud.
7.4. Mobility and Reassociation
Attachment Scope can change when the requester:
- moves between access areas;
- changes serving UPF;
- changes DNN;
- changes slice;
- moves between VPN or tenant contexts;
- moves between Wi-Fi and cellular access; or
- enters another edge domain.
For example:
Before:
UPF-A -> AScope-A
After reassociation:
UPF-B -> AScope-B
Subsequent discovery can therefore return resources
applicable to the requester's new network context.
Attachment Scope may be updated through events, queried at
discovery time, or cached with an appropriate validity
period.
8. Applying the Model to DNS-SD
This section describes how the infrastructure-assisted
discovery model in Section 5 can be realized using DNS-SD
[RFC6763]. The general roles of requester criteria, published
resource state, Attachment Scope, and discovery processing
are defined in Section 5 and are not repeated here.
In the DNS-SD realization, the Resource Publication Hook maps
current AI-agent resource state into DNS-SD service
information, while the Attachment Context Hook provides
Dunbar, et al. Expires Dec 15, 2027 [Page 23]
Internet-Draft Infrastructure Assisted Discovery
network-derived context used to determine which DNS-SD
discovery domains or service instances are applicable to the
requester.
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, instance enumeration, and endpoint resolution. The
infrastructure-assisted model maps onto those mechanisms as
follows:
Published AI-Agent Resource State
|
v
DNS-SD Representation
PTR -> discoverable service instances
SRV -> reachable target and port
TXT -> selected discovery attributes
or references to agent metadata
For example, an AI-agent instance may be represented as:
Vision-Agent-A._example-agent._tcp.example.com.
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.
Dunbar, et al. Expires Dec 15, 2027 [Page 24]
Internet-Draft Infrastructure Assisted Discovery
8.2. DNS-SD Publication
When DNS-SD is used, the Resource Publication Hook described
in Section 6 can populate and update the DNS-SD
representation of currently available AI-agent resources.
The deployment or orchestration system provides the
information needed to create, update, or withdraw the
corresponding DNS-SD records as the published AI-agent
resource state changes.
Conceptually:
AI-Agent Deployment State
|
v
Resource Publication Hook
|
+--> PTR: service-instance enumeration
|
+--> SRV: reachable target and port
|
+--> TXT: selected discovery attributes
or metadata reference
A published resource may represent either a logical AI-agent
service or an individually reachable instance, as described
in Section 6.1.
When a published endpoint changes, the corresponding SRV
information can be updated without requiring unrelated agent
metadata to change. When a published resource is no longer
available, its corresponding DNS-SD information can be
withdrawn.
An authorized controller may populate and maintain these
records on behalf of the 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.
Dunbar, et al. Expires Dec 15, 2027 [Page 25]
Internet-Draft Infrastructure Assisted Discovery
The interface between the Resource Publication Hook and DNS
infrastructure is outside the scope of this document.
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 is not required to be carried in the DNS-SD
request itself.
When DNS-SD is used, Attachment Scope can be applied in at
least two ways:
o by mapping the requester's Attachment Scope to one or
more DNS-SD discovery domains; or
o by filtering enumerated resources according to the
requester's Attachment Scope and deployment policy.
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
A requester may issue only its application-level discovery
intent, such as:
Service-Category: Vision-Inference
The discovery function combines this request with the
network-provided Attachment Scope and determines which DNS-SD
domains are applicable.
For example:
Dunbar, et al. Expires Dec 15, 2027 [Page 26]
Internet-Draft Infrastructure Assisted Discovery
Requester Intent:
Vision-Inference
Attachment Scope:
AScope-Edge-A
Applicable Discovery Domains:
edge-a.agent.example
shared.agent.example
DNS-SD enumeration can then be performed within those domains
using the procedures defined in [RFC6763].
This approach allows the DNS-SD discovery domain to reflect
network applicability without requiring the requester to know
which domain corresponds to its current network attachment.
The mapping from Attachment Scope to discovery domains is
deployment policy.
8.3.2. Filtering Resources After Enumeration
Another deployment can use a common DNS-SD discovery domain
that contains AI-agent resources associated with multiple
Attachment Scopes.
For example:
Vision-Agent-A
Attachment-Scope: AScope-A
Vision-Agent-B
Attachment-Scope: AScope-B
Vision-Agent-C
Attachment-Scope: AScope-Shared
The discovery function can first identify resources matching
the requester's service-related criteria and then apply
policy based on the requester's Attachment Scope.
Dunbar, et al. Expires Dec 15, 2027 [Page 27]
Internet-Draft Infrastructure Assisted Discovery
For a requester associated with:
Attachment-Scope: AScope-A
the applicable resource scopes might be:
AScope-A
AScope-Shared
The resulting resources could therefore be:
Vision-Agent-A
Vision-Agent-C
The Attachment Scope associated with a resource does not need
to be exposed to the requester or encoded in a generally
visible DNS-SD TXT record. It can instead be maintained by a
trusted discovery component or associated infrastructure
database.
This approach is useful when resources associated with
multiple network contexts share a common DNS-SD namespace, or
when Attachment Scope information should remain internal to
the infrastructure.
In both approaches, DNS-SD continues to provide service-
instance enumeration and endpoint resolution. The
infrastructure-provided Attachment Scope determines which
DNS-SD discovery domains or enumerated service instances are
applicable to the requester's current network context.
8.4. Agent Metadata in DNS-SD
Agent metadata used for discovery matching may be represented
directly in DNS-SD, maintained separately by the discovery
system, or obtained through a reference to an agent-native
metadata mechanism.
A deployment may place selected discovery attributes in DNS-
SD TXT records, such as a supported protocol or a reference
to richer metadata. For example:
Dunbar, et al. Expires Dec 15, 2027 [Page 28]
Internet-Draft Infrastructure Assisted Discovery
protocol=A2A
metadata=
https://vision-a.edge.example/.well-known/agent-
card.json
Other attributes, such as skills, capabilities, supported
modalities, or authentication characteristics, may be indexed
by the discovery system without being encoded directly in
DNS-SD.
For an A2A deployment, some or all of this information may
originate from an Agent Card. The complete Agent Card does
not need to be duplicated in DNS-SD TXT records.
The choice of which attributes are represented directly in
DNS-SD and which are maintained or retrieved separately is
deployment-specific.
8.5. Discovery Result
The DNS-SD realization returns the service instances that
remain applicable after the processing described in Section
8.3 and, where applicable, the metadata matching described in
Section 8.4.
For an applicable resource, DNS-SD provides the information
needed to identify and resolve the published service
instance. For example, the resulting information may
correspond to:
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].
Dunbar, et al. Expires Dec 15, 2027 [Page 29]
Internet-Draft Infrastructure Assisted Discovery
The Attachment Scope used to determine applicability does not
need to be returned to the requester. It is infrastructure
context used during discovery rather than information
required for subsequent agent communication.
A DNS-SD result may contain multiple applicable service
instances. Where SRV records are used, the Priority and
Weight procedures defined by [RFC2782] continue to apply.
These procedures do not replace a separate resource-selection
function when additional criteria such as network condition,
compute load, accelerator availability, cost, or application
policy are required.
Additional agent-specific metadata, such as an A2A Agent
Card, may be provided by reference or retrieved subsequently
as described in Section 9.
This document does not change the DNS-SD response format.
8.6. Caching and Freshness
AI-agent deployment state can change after discovery
information has been published.
For example:
o an instance can be withdrawn;
o an endpoint can change;
o an agent can move to another edge site;
o an Attachment Scope associated with a resource can
change; or
o a requester can move to a different Attachment Scope.
The Resource Publication Hook is responsible for reflecting
changes to resource deployment state in the discovery system.
When DNS is used, normal DNS TTL semantics apply. [RFC1035]
specifies the interval for which a resource record can be
cached before the source of the information should be
consulted again.
Dunbar, et al. Expires Dec 15, 2027 [Page 30]
Internet-Draft Infrastructure Assisted Discovery
Deployments in which agent endpoints or placement change
frequently can therefore use TTL values appropriate to the
expected lifetime of the published information. Very dynamic
deployment information should not be treated as indefinitely
valid merely because it was previously returned by discovery.
Attachment Scope can have a lifetime that is independent of
the lifetime of DNS resource records. For example, a
requester may change from: AScope-A to AScope-B.
while previously discovered DNS information remains present
in a cache.
A new discovery operation should therefore use the
requester's current Attachment Scope rather than assuming
that a previously determined Attachment Scope remains valid.
Implementations should avoid treating cached resource
information and cached Attachment Scope as having the same
validity period unless deployment policy explicitly defines
them that way.
8.7. No Match
A discovery request can identify no resource that satisfies
both the agent-related discovery criteria and the applicable
Attachment Scope policy.
For example:
Requested:
Vision-Inference
Candidate:
Agent-B -> AScope-B
Requester:
AScope-A
Dunbar, et al. Expires Dec 15, 2027 [Page 31]
Internet-Draft Infrastructure Assisted Discovery
If policy does not permit AScope-A to use resources in
AScope-B, the discovery result contains no applicable
resource.
The discovery mechanism may return an empty result or use
mechanisms provided by the underlying discovery system to
indicate that no applicable resource was found.
A deployment can also define fallback policy. For example,
when no edge-local resource is applicable, the discovery
mechanism may consider an AI-agent resource published for a
shared cloud Attachment Scope.
Such fallback behavior is deployment policy and is not
mandated by this document.
9. Second-Stage Agent Metadata Retrieval
The lightweight discovery mechanism is intentionally not a
complete AI-agent description system.
Once an applicable resource has been identified, the
requester can retrieve richer information using the agent's
native mechanism.
For A2A:
Discovery Response
|
v
Agent Card Reference
|
v
Retrieve Agent Card
|
v
Identity, Capabilities, Skills, Interfaces, Security,
Interaction Requirements
Other AI-agent protocols may use different descriptors.
Dunbar, et al. Expires Dec 15, 2027 [Page 32]
Internet-Draft Infrastructure Assisted Discovery
This model avoids requiring one general discovery mechanism
to reproduce all protocol-specific agent metadata.
10. Relationship to Resource Selection
Attachment Scope determines applicability rather than
optimization.
For example:
Discovery Result:
Agent-A
Agent-B
means that both agents are usable within the applicable
discovery context.
A separate mechanism may select one based on:
- latency;
- network congestion;
- compute load;
- GPU availability;
- service cost;
- application policy; or
- another dynamic metric.
Mechanisms such as CATS may be applicable to such subsequent
network-aware selection.
11. Alternative methods
The infrastructure-assisted model does not depend on a
particular discovery protocol.
The discovery mechanism may use:
- DNS-SD;
- a centralized registry;
- a distributed directory;
- a federated discovery mechanism; or
- another service-discovery system.
The Resource Publication Hook may be implemented by:
Dunbar, et al. Expires Dec 15, 2027 [Page 33]
Internet-Draft Infrastructure Assisted Discovery
- 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/VRF state;
- Wi-Fi infrastructure;
- cloud networking;
- SD-WAN state;
- edge-controller state; or
- combinations of these.
Resource and Attachment Scope state may be updated through
events, queried dynamically, periodically refreshed, or
cached.
Agent-native metadata may be represented using an A2A Agent
Card, MCP metadata, another protocol-specific descriptor, or
a deployment-specific format.
12. Security Considerations
Attachment Scope may be derived from sensitive network
information.
The discovery mechanism should receive only the abstraction
needed for discovery and should not require unnecessary
exposure of:
- subscriber identity;
- physical access port;
- precise geographic location;
- internal topology;
- routing identifiers; or
- detailed network configuration.
Infrastructure providing Attachment Scope needs to be trusted
by the discovery mechanism.
Dunbar, et al. Expires Dec 15, 2027 [Page 34]
Internet-Draft Infrastructure Assisted Discovery
A requester should not be able to obtain unauthorized
resources merely by asserting an Attachment Scope in an
untrusted request.
Likewise, Resource Publication Hooks need authentication and
authorization so that unauthorized systems cannot publish,
alter, or withdraw AI-agent resource information.
Discovery information can reveal the existence and
reachability of AI resources. Deployments should therefore
apply appropriate visibility and access policies.
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
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery," RFC 6763, February 2013.
[A2A] Agent2Agent Protocol, "Agent2Agent Protocol
Documentation", https://a2a-protocol.org/.
[AGENT-ATTACHMENT] Dunbar, L., et al., "Agent Attachment
Protocol," Work in Progress.
[DAWN-MDNS] Jakab, L. and Brockners, F., "Zero-Configuration
Agent Discovery," draft-jakab-dawn-agent-discovery-
mdns, Work in Progress.
Dunbar, et al. Expires Dec 15, 2027 [Page 35]
Internet-Draft Infrastructure Assisted Discovery
[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.
[MCP] Model Context Protocol, "Model Context Protocol
Specification",
https://modelcontextprotocol.io/specification/
15. Acknowledgments
Acknowledgements to xxx for their extensive review and
suggestions.
This document was prepared using 2-Word-v2.0.template.dot.
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 Dec 15, 2027 [Page 36]