Network Working Group L. Dunbar
Internet Draft Futurewei
Intended status: Informational B. Zhang
Expires: April 16, 2027 Pengcheng Lab
October 16, 2026
Infrastructure-Assisted Discovery for AI Agents
draft-dunbar-dawn-infra-assisted-discovery-02
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 16, 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...............9
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................................16
5.5. Metadata and Deployment State.......................17
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 16, 2027 [Page 2]
Internet-Draft Infrastructure Assisted Discovery
6.3. 5G Edge Deployment Example..........................20
6.4. Publication Lifecycle...............................20
7. Attachment Scope Determination and Update................21
7.1. Policy-Based Mapping................................21
7.2. Requester Attachment Scope..........................22
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. Applying the Model to DNS-AID............................32
9.1. DNS-AID Mapping.....................................33
9.2. Applying Attachment Scope to DNS-AID................33
9.3. Relationship to DNS-AID Results.....................34
10. Second-Stage Agent Metadata Retrieval...................35
11. Relationship to Resource Selection......................35
12. Alternative methods.....................................36
13. Security Considerations.................................37
14. IANA Considerations.....................................37
15. References..............................................38
15.1. Normative References...............................38
15.2. Informative References.............................38
16. Acknowledgments.........................................39
Appendix A:.................................................39
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-
Dunbar, et al. Expires Dec 16, 2027 [Page 3]
Internet-Draft Infrastructure Assisted Discovery
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
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.
The model can similarly complement DNS-AID [DNS-AID] in
managed environments by using infrastructure-maintained
deployment state and network-derived Attachment Scope without
changing the DNS-AID wire format.
More generally, 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.
Dunbar, et al. Expires Dec 16, 2027 [Page 4]
Internet-Draft Infrastructure Assisted Discovery
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.
This document does not define a new wire protocol. The model
can be applied to DNS-SD, DNS-AID, 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,
Dunbar, et al. Expires Dec 16, 2027 [Page 5]
Internet-Draft Infrastructure Assisted Discovery
DNS-AID, 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.
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
Dunbar, et al. Expires Dec 16, 2027 [Page 6]
Internet-Draft Infrastructure Assisted Discovery
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.
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;
Dunbar, et al. Expires Dec 16, 2027 [Page 7]
Internet-Draft Infrastructure Assisted Discovery
- 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
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.
Dunbar, et al. Expires Dec 16, 2027 [Page 8]
Internet-Draft Infrastructure Assisted Discovery
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
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.
The model described in this document is compatible with that
two-stage approach. 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.
Dunbar, et al. Expires Dec 16, 2027 [Page 9]
Internet-Draft Infrastructure Assisted Discovery
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:
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:
Dunbar, et al. Expires Dec 16, 2027 [Page 10]
Internet-Draft Infrastructure Assisted Discovery
Vision Agent Service
|
Common Endpoint
|
+--------+--------+
| | |
A B C
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:
Dunbar, et al. Expires Dec 16, 2027 [Page 11]
Internet-Draft Infrastructure Assisted Discovery
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.
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.
Dunbar, et al. Expires Dec 16, 2027 [Page 12]
Internet-Draft Infrastructure Assisted Discovery
For example:
Requester Intent: Vision-Inference
Attachment Scope: AScope-A
Published Instances:
Agent-A -> AScope-A
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
Dunbar, et al. Expires Dec 16, 2027 [Page 13]
Internet-Draft Infrastructure Assisted Discovery
+
Published AI-Agent Resource State
+
Requester Attachment Scope
|
v
Discovery Mechanism
|
v
Applicable AI-Agent Resources
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.
Dunbar, et al. Expires Dec 16, 2027 [Page 14]
Internet-Draft Infrastructure Assisted Discovery
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
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.
Dunbar, et al. Expires Dec 16, 2027 [Page 15]
Internet-Draft Infrastructure Assisted Discovery
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.
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.
Dunbar, et al. Expires Dec 16, 2027 [Page 16]
Internet-Draft Infrastructure Assisted Discovery
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.
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 11.
5.7. Relationship to Specific Discovery Mechanisms
The infrastructure-assisted model is independent of a
particular discovery protocol.
Dunbar, et al. Expires Dec 16, 2027 [Page 17]
Internet-Draft Infrastructure Assisted Discovery
The Resource Publication Hook and Attachment Context Hook
provide inputs to the discovery process, while the underlying
discovery mechanism can use DNS-SD, DNS-AID, a registry, a
directory, a federated discovery system, or another
mechanism.
Section 8 and 9 describe how the model can be realized using
DNS-SD and DNS-AID respectively.
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
Dunbar, et al. Expires Dec 16, 2027 [Page 18]
Internet-Draft Infrastructure Assisted Discovery
|
+----+----+----+
| | | |
A B C D
the discovery mechanism may publish only:
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
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.
Dunbar, et al. Expires Dec 16, 2027 [Page 19]
Internet-Draft Infrastructure Assisted Discovery
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
| |
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.
Dunbar, et al. Expires Dec 16, 2027 [Page 20]
Internet-Draft Infrastructure Assisted Discovery
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.
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
|
Dunbar, et al. Expires Dec 16, 2027 [Page 21]
Internet-Draft Infrastructure Assisted Discovery
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:
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 require the requester and
resource to have identical scope values. 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 may be
permitted to discover resources published for the same edge
scope, a broader metropolitan scope, or a shared cloud scope:
Requester Attachment Scope:
AScope-Edge-A
Applicable Resource Scopes:
AScope-Edge-A
AScope-Metro
AScope-Shared-Cloud
Dunbar, et al. Expires Dec 16, 2027 [Page 22]
Internet-Draft Infrastructure Assisted Discovery
Such policy allows discovery applicability to reflect
deployment relationships among edge, regional, and shared
resources without exposing the underlying network-specific
information used to derive the requester's Attachment Scope.
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.
Dunbar, et al. Expires Dec 16, 2027 [Page 23]
Internet-Draft Infrastructure Assisted Discovery
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
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
Dunbar, et al. Expires Dec 16, 2027 [Page 24]
Internet-Draft Infrastructure Assisted Discovery
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.
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
Dunbar, et al. Expires Dec 16, 2027 [Page 25]
Internet-Draft Infrastructure Assisted Discovery
authoritative DNS management interfaces, orchestration APIs,
or controller-specific mechanisms.
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
Dunbar, et al. Expires Dec 16, 2027 [Page 26]
Internet-Draft Infrastructure Assisted Discovery
The discovery function combines this request with the
network-provided Attachment Scope and determines which DNS-SD
domains are applicable.
For example:
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
Dunbar, et al. Expires Dec 16, 2027 [Page 27]
Internet-Draft Infrastructure Assisted Discovery
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.
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.
Dunbar, et al. Expires Dec 16, 2027 [Page 28]
Internet-Draft Infrastructure Assisted Discovery
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:
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
Dunbar, et al. Expires Dec 16, 2027 [Page 29]
Internet-Draft Infrastructure Assisted Discovery
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 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 10.
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.
Dunbar, et al. Expires Dec 16, 2027 [Page 30]
Internet-Draft Infrastructure Assisted Discovery
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.
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
Dunbar, et al. Expires Dec 16, 2027 [Page 31]
Internet-Draft Infrastructure Assisted Discovery
Requester:
AScope-A
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. Applying the Model to DNS-AID
DNS for AI Discovery (DNS-AID) [DNS-AID] uses existing DNS
mechanisms to publish AI-agent connectivity and discovery
information. For a known agent, DNS-AID uses SVCB records to
provide endpoint, transport, agent-protocol, and capability-
related information. When the requester knows an organization
but not a specific agent, DNS-AID uses the well-known
_index._agents.<domain> entry point to locate an
organization-specific agent index.
The infrastructure-assisted model in Section 5 can complement
DNS-AID in managed enterprise, cloud, edge, and
communication-network environments. The Resource Publication
Hook can keep DNS-AID-visible agent information aligned with
current deployment state, while the Attachment Context Hook
can provide network-derived context used to determine which
published agents or discovery information are applicable to a
requester.
The Attachment Scope is not required to be encoded in DNS-AID
SVCB records or carried in DNS queries. Infrastructure
Dunbar, et al. Expires Dec 16, 2027 [Page 32]
Internet-Draft Infrastructure Assisted Discovery
assistance is applied around the DNS-AID mechanism and does
not change the DNS-AID wire format.
9.1. DNS-AID Mapping
The Resource Publication Hook can map current AI-agent
deployment state to the information exposed through DNS-AID.
Conceptually:
AI-Agent Deployment State
|
v
Resource Publication Hook
|
+--> Agent SVCB record
| endpoint / transport / agent protocol
| capability metadata or reference
|
+--> Organization agent index
discoverable agent inventory
For a known agent, changes to an externally reachable
endpoint, supported protocol, or referenced capability
information can result in corresponding updates to the
published DNS-AID information. When an agent is withdrawn,
its published information can likewise be removed or made
unavailable.
For organization-level discovery, deployment or management
infrastructure can keep the organization-specific agent index
synchronized with the set of AI-agent services or instances
that are currently intended to be discoverable. The exact
format and access protocol of that index remain outside the
scope of DNS-AID.
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
Dunbar, et al. Expires Dec 16, 2027 [Page 33]
Internet-Draft Infrastructure Assisted Discovery
discovery function before or while DNS-AID information is
used. The Attachment Scope can then be applied by deployment
policy to determine which DNS-AID-published agents or
organization-index results are applicable to the requester.
For example, an organization may publish agents reachable
from an enterprise edge environment as well as agents
reachable through a shared cloud environment. A requester
associated with AScope-Edge-A could be permitted to use both
edge-local and shared-cloud agents, while a requester
associated with another Attachment Scope could receive or use
a different applicable set.
A deployment can apply this policy when selecting an
organization index to consult, when presenting a managed view
of an organization index, or when filtering the agents
obtained from that index. These are deployment choices; this
document does not require Attachment Scope to be published in
DNS or returned to the requester.
In this way, DNS-AID continues to provide the DNS-based
bootstrap and agent connectivity information, while
infrastructure-provided Attachment Scope contributes
requester-specific applicability information.
9.3. Relationship to DNS-AID Results
Infrastructure assistance does not change the DNS-AID result
format. For a known-agent lookup, the requester can use the
SVCB information published by DNS-AID to locate and connect
to the applicable agent. For organization-level discovery,
the requester can follow the DNS-AID organization-index entry
point and use the resulting index information to identify
candidate agents.
Where several agents satisfy the requester's criteria and
Attachment Scope, the discovery result may contain multiple
applicable resources. Subsequent resource selection remains
separate, as described in Section 11.
Dunbar, et al. Expires Dec 16, 2027 [Page 34]
Internet-Draft Infrastructure Assisted Discovery
10. Second-Stage Agent Metadata Retrieval
A discovery mechanism may maintain sufficient agent metadata
to perform discovery matching. Once an applicable resource
has been identified, the requester can retrieve additional
protocol-specific information using the agent's native
mechanism when needed.
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.
This model avoids requiring one general discovery mechanism
to reproduce all protocol-specific agent metadata.
11. 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;
Dunbar, et al. Expires Dec 16, 2027 [Page 35]
Internet-Draft Infrastructure Assisted Discovery
- 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.
12. Alternative methods
The infrastructure-assisted model does not depend on a
particular discovery protocol.
The discovery mechanism may use:
- DNS-AID;
- 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:
- 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.
Dunbar, et al. Expires Dec 16, 2027 [Page 36]
Internet-Draft Infrastructure Assisted Discovery
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.
13. 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.
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.
14. IANA Considerations
TBD
Dunbar, et al. Expires Dec 16, 2027 [Page 37]
Internet-Draft Infrastructure Assisted Discovery
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
15.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/.
[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.
Dunbar, et al. Expires Dec 16, 2027 [Page 38]
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.
[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/
16. 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 16, 2027 [Page 39]