Distributed Registration and Information Synchronization of Agent Capabilities
draft-wang-dmsc-drisac-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yifei Wang , Aijun Wang | ||
| Last updated | 2026-08-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-dmsc-drisac-00
DMSC Working Group Y. Wang
Internet-Draft A. Wang
Intended status: Informational China Telecom
Expires: 6 February 2027 5 August 2026
Distributed Registration and Information Synchronization of Agent
Capabilities
draft-wang-dmsc-drisac-00
Abstract
The large-scale deployment of autonomous AI Agents introduces
challenges to capability description, registration, and discovery.
Existing agent communication protocols mainly focus on application-
layer interactions and typically rely on centralized registration and
discovery mechanisms, which limit scalability, robustness, and
semantic extensibility. This document proposes a distributed and
hierarchical capability registration and information synchronization
mechanism for AI Agents. The mechanism introduces a multi-level
capability taxonomy, capability vectors, and globally unique Service
Identifiers (Service IDs), and defines two functional entities: Agent
Capability Registration Server (ACRS) and Agent Capability Access
Server (ACAS). A capability table is constructed and synchronized
among ACRSs to enable semantic-based forwarding of capability-related
requests. Furthermore, capability registration and discovery
procedure are specified, enabling precise selection of agents based
on task requirements. The proposed mechanism provides a scalable
foundation for capability-aware routing and semantic collaboration in
the Internet of Agents (IoA).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 February 2027.
Wang & Wang Expires 6 February 2027 [Page 1]
Internet-Draft Abbreviated-Title August 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement and Design Goals . . . . . . . . . . . . . 3
4. Hierarchical Representation of Capability Classification . . 4
5. Core Entities and Data Structures . . . . . . . . . . . . . . 4
5.1. Capability Table . . . . . . . . . . . . . . . . . . . . 4
5.2. Access Mapping Table . . . . . . . . . . . . . . . . . . 5
6. Distributed Capability Registration Procedure . . . . . . . . 6
7. Intent-Driven Capability Discovery Procedure . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
11. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
AI systems are evolving from task-specific applications toward
autonomous agents capable of perception, reasoning, and action
execution. In this paradigm, agents are expected to communicate,
collaborate, and invoke each other's capabilities across network
administrative domains to accomplish complex tasks. Consequently,
capability registration and discovery become fundamental functions
for enabling agent interoperability.
Existing service registration mechanisms are primarily designed for
static service instances and are not intended to support highly
dynamic agent capabilities or large-scale collaborative agent
environments.
Wang & Wang Expires 6 February 2027 [Page 2]
Internet-Draft Abbreviated-Title August 2026
This document defines a distributed mechanism for hierarchical
capability registration and semantic-based capability discovery for
AI Agents. The mechanism provides a scalable foundation for
capability-aware request forwarding and agent selection without
modifying the underlying network infrastructure.
2. Terminology
The following terms are defined in this draft:s
* Agent Capability Type:The basic subdivision unit in the
hierarchical capability classification system, which identifies a
specific functional category that an agent is able to provide.
* Agent Capability Vector: A structured representation of the
capability types to indicate the agent's full capabilities
* Service ID: A globally unique identifier representing a callable
AI Agent instance.
* ACRS: Agent capability registration server that manage one or more
types of capabilities. ACRSs form an overlay network where
capability tables are exchanged and synchronized.
* ACAS: Agent capability access server that act as the direct
attachment anchor for AI agents.
* Capability Table: A table maintained by ACRSs that maps capability
vectors to next-hop capability servers.
* Access Mapping Table: A table maintained by ACASs that maps
connected agents to their Service IDs and capability types.
3. Problem Statement and Design Goals
AI systems are evolving from traditional service-oriented
applications toward autonomous agents capable of dynamically
providing, consuming, and composing capabilities. Unlike
conventional service instances, AI Agents continuously join and leave
the network, update their capabilities, and participate in dynamic
collaboration relationships. Existing registration and discovery
mechanisms are primarily designed for relatively static service
environments. Such mechanisms do not adequately address the
scalability, capability dynamics, and semantic diversity introduced
by large-scale AI Agent deployments. As the number of participating
agents increases, centralized registration architectures may become
bottlenecks for capability management and discovery.
Wang & Wang Expires 6 February 2027 [Page 3]
Internet-Draft Abbreviated-Title August 2026
Therefore, a capability registration mechanism is required to support
scalable capability registration, distributed information
synchronization, efficient capability discovery, and dynamic
management of AI Agent capabilities in open network environments.
4. Hierarchical Representation of Capability Classification
Agent capabilities are represented using a hierarchical
classification model as shown in Figure 1. The multi-level
capability tree organizes capabilities from coarse-grained capability
classes to progressively finer-grained subordinate capability
classes. The hierarchy is extensible and allows new capability
classes to be introduced without affecting existing classifications.
[ Agent Capabilities ]
|
+--------------+ . . .
| |
[ Parent Capability [ Parent Capability ------- (Parent Capability Class)
Class A ] Class B ] (Extensible as needed)
|
+--------+--------+ . . . +--------+
| | |
[ Subordinate [ Subordinate [ Subordinate ] --- (Level 1 Subordinate Class)
Class A1 ] Class A2 ] Class An ] (Extensible as needed)
|
+----+ . . . +------+ . . .
| |
[ Subordinate [ Subordinate ] ---------------- (Level 2 Subordinate Class)
Class A1-1 ] Class A1-n ] (Extensible as needed)
:
:
+--------+ . . . +--------+ . . .
| | | |
[ Subordinate [ Subordinate ] ---------------- (Level N Subordinate Class)
Class A1-1...1] Class A1-1...n] (Extensible as needed)
Figure 1 Multi-level Capability Tree Architechture
5. Core Entities and Data Structures
5.1. Capability Table
A Capability Table is maintained by each ACRS to determine the next-
hop ACRS for capability-related requests. Each table entry
associates a target capability type with one or more next-hop ACRSs.
Each entry consists of a target capability type and the corresponding
next-hop ACRS.
Wang & Wang Expires 6 February 2027 [Page 4]
Internet-Draft Abbreviated-Title August 2026
For illustration purposes, consider ACRS responsible for Capability
A.the capability table it maintains is presented in a similar form as
shown in Table 1:
Table 1 Capability Table of ACRS responsible for Capability A
| Target Capability Type | Next-Hop ACRS |
| A | - |
| B | B |
| C | B/D |
| D | D |
Capability tables are constructed based on inter-ACRS connectivity
and are synchronized dynamically. Capability Tables are constructed
as follows:
* ACRSs establish logical adjacencies with neighboring ACRSs.
* Each ACRS advertises the capability types for which it is
responsible.
* Capability routing entries are generated based on the exchanged
advertisements.
5.2. Access Mapping Table
An Access Mapping Table is maintained by each ACAS to record the
association between locally attached AI Agents and their
corresponding Service IDs. The table enables local capability
matching during the capability discovery procedure.Each entry
includes: service ID, capability types,and access link identifier.
For illustration purposes, consider a general ACAS maintains the
access mapping table as shown in Table 2:
Table 2 Access Mapping Table of general ACAS
| Agent | Access Link ID | Service ID | Agent Capability Type |
| 1 | Physical Port Number | SID-001 | D |
| 2 | VLAN ID | SID-002 | B2, A |
| 3 | VXLAN VNI | SID-003 | B2, C |
| 4 | MPLS Label | SID-004 | E |
| 5 | SRv6 SID | SID-005 | F |
The access link identifier distinguishes all available agents
directly connected to this access server, enabling efficient matching
of locally attached agents according to capability requirements in
the capability discovery process.
Wang & Wang Expires 6 February 2027 [Page 5]
Internet-Draft Abbreviated-Title August 2026
6. Distributed Capability Registration Procedure
A distributed and hierarchical capability registration mechanism is
defined. An AI Agent, based on its capability classification,
advertises its registration information toward the corresponding ACRS
by following capability-table-based routing.The capability
registration procedure consists of the following steps:
1. An AI Agent connects to an ACAS and sends a capability
registration request (capability types and service ID) to the
attached ACAS. The ACAS records the received information in its
Access Mapping Table
2. The ACAS aggregates registrations belonging to the same
capability type. The aggregated information is propagated toward
the responsible ACRS.
3. The ACAS forwards summarized information toward the target ACRS
according to the capability table.
4. The target ACRS authenticates and confirms registration.
5. A registration success response is returned.
The ACRS relays registration information based on the capability
table. When the ACAS directly connected to an agent happens to be
the agent's target ACRS, capability registration is completed
directly on that ACRS. Otherwise, the target registration server
have to be located according to the capability table.
7. Intent-Driven Capability Discovery Procedure
Capability discovery is initiated according to the capability
requirements derived from a task intent. An AI agent issues a
discovery query that is forwarded based on capability classification
using the capability table, enabling location and matching of agents
with required capability types. The intent-driven capability
discovery mechanism is as follows:
1. A requester submits a task intent to the service domain, and the
client-side AI Agent attaches to an ingress ACRS.
2. The ingress ACRS maps intent to capability vector and determines
the next-hop ACRS according to the capability table. It
initiates an agent query locally and determines whether the
destination ACAS is directly reachable; otherwise, the request is
forwarded according to the capability table.
Wang & Wang Expires 6 February 2027 [Page 6]
Internet-Draft Abbreviated-Title August 2026
3. The ACRS sends an agent query request to the target ACAS.
4. The target ACAS performs local matching according to the access
mapping table.
5. The ACAS returns the matching results (i.e., a list of Service
IDs of all available agents) to the requesting ACRS, which then
returns the matching Service IDs to the requesting entity.
8. IANA Considerations
This document makes no request of IANA.
9. Security Considerations
Authentication between agents, ACASs, and ACRSs is REQUIRED.
Capability advertisements SHOULD be integrity-protected. Access
control policies MUST be enforced at registration and discovery
stages.
10. Acknowledgements
TBD
11. Normative References
[draft-li-dmsc-macp-05]
L, B., "Gateway Requirements for Dynamic Multi-agents
Secured Collaboration. draft-liu-dmsc-gw-requirements.
<https://datatracker.ietf.org/doc/draft-liu-dmsc-gw-
requirements/>", 16 January 2026.
[draft-sz-dmsc-iaip]
S, S., "Intent-based Agent Interconnection Protocol at
Agent Gateway. draft-sz-dmsc-iaip.
<https://datatracker.ietf.org/doc/draft-sz-dmsc-iaip/>", 9
February 2026.
[draft-yang-dmsc-ioa-task-protocol]
Y, C., "Internet of Agents Task Protocol (IoA Task
Protocol) for Heterogeneous Agent Collaboration. draft-
yang-dmsc-ioa-task-protocol.
<https://datatracker.ietf.org/doc/draft-yang-dmsc-ioa-
task-protocol/>", 14 January 2026.
Wang & Wang Expires 6 February 2027 [Page 7]
Internet-Draft Abbreviated-Title August 2026
[draft-zhang-dmsc-gateway-directory-sync]
Z, L., "Gateway Capability Directory and Synchronization
for Internet of Agents. draft-zhang-dmsc-gateway-
directory-sync. <https://datatracker.ietf.org/doc/draft-
zhang-dmsc-gateway-directory-sync/>", 28 April 2026.
[draft-zhang-dmsc-ioa-semantic-interaction]
Z, L., "Ontology-based Semantic Interaction for Internet
of Agents. draft-zhang-dmsc-ioa-semantic-interaction.
<https://datatracker.ietf.org/doc/draft-zhang-dmsc-ioa-
semantic-interaction/>", 4 February 2026.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses
Yifei Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: 18691883185@163.com
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: wangaj3@chinatelecom.cn
Wang & Wang Expires 6 February 2027 [Page 8]