<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-wang-dmsc-drisac-01" ipr="trust200902">
  <front>
    <title abbrev="Abbreviated-Title">Distributed Onboarding and Information
    Synchronization of Agent Capabilities</title>

    <author fullname="Yifei Wang" initials="Y" surname="Wang">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>102209</code>

          <country>China</country>
        </postal>

        <email>wangyf85@chinatelecom.cn</email>
      </address>
    </author>

    <author fullname="Aijun Wang" initials="A." surname="Wang">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region>Beijing</region>

          <code>102209</code>

          <country>China</country>
        </postal>

        <email>wangaj3@chinatelecom.cn</email>
      </address>
    </author>

    <date day="18" month="August" year="2026"/>

    <area>IETF Area</area>

    <workgroup>DMSC Working Group</workgroup>

    <keyword>Agent Capabilities, Agent Onoarding, Capability
    Discovery</keyword>

    <abstract>
      <t>AI Agents may dynamically join, leave, and update their capabilities
      while participating in interactions across administrative domains.
      Efficient capability discovery in such environments requires mechanisms
      to onboard agent capabilities and maintain consistent capability
      information across distributed management entities. Existing service
      registration and discovery mechanisms do not necessarily provide a
      capability-oriented mechanism for distributed synchronization and
      hierarchical forwarding of agent capability information.</t>

      <t>This document proposes a distributed and hierarchical mechanism for
      AI Agent capability onboarding, information synchronization, and
      capability-based discovery. The mechanism introduces a hierarchical
      capability classification model and defines two functional entities: the
      Agent Capability Management Server (ACMS), which maintains and
      synchronizes capability information, and the Agent Capability Access
      Server (ACAS), which manages locally attached agents. Capability
      information is aggregated and propagated among ACMSs, while access
      information for locally attached agents is maintained by ACASs. A
      capability table is used to determine forwarding toward relevant ACMSs,
      and an access mapping table is used for local agent matching. The
      document also describes onboarding and intent-driven capability
      discovery procedures. The mechanism is intended to provide a distributed
      control-plane foundation for capability-aware agent discovery and does
      not define agent-to-agent interaction or task execution protocols.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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 onboarding and discovery become fundamental functions for
      enabling agent interoperability.</t>

      <t>Existing service registration and discovery mechanisms provide
      mechanisms for publishing and locating service instances, but they do
      not necessarily provide a distributed, capability-oriented model for
      representing and synchronizing the dynamically changing capabilities of
      AI Agents across administrative domains.</t>

      <t>This document defines a distributed mechanism for hierarchical
      capability onboarding 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.</t>
    </section>

    <section title="Terminology">
      <t>The following terms are defined in this draft:s<list style="symbols">
          <t>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.</t>

          <t>Agent Capability Vector: A structured representation of one or
          more capability types associated with an AI Agent.</t>

          <t>Agent ID: A globally unique identifier representing a callable AI
          Agent instance.</t>

          <t>ACMS: Agent capability management server that manages one or more
          types of capabilities. ACMS forms the capabilities table via
          exchanging and synchronizing their summarized capabilities
          tables.</t>

          <t>ACAS: Agent capability access server that provides the attachment
          point for AI Agents and maintains information about locally attached
          agents and their capabilities.</t>

          <t>Capability Table: A table maintained by ACMSs that maps
          capability vectors to next-hop capability servers.</t>

          <t>Access Mapping Table: A table maintained by ACASs that maps
          connected agents to their Agent IDs and capability types.</t>
        </list></t>
    </section>

    <section title="Problem Statement and Design Goals">
      <t>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 onboarding architectures may become bottlenecks for
      capability management and discovery.</t>

      <t>Therefore, a capability onboarding mechanism is required to support
      scalable capability onboarding, distributed information synchronization,
      efficient capability discovery, and dynamic management of AI Agent
      capabilities in open network environments.</t>
    </section>

    <section title="Hierarchical Representation of Capability Classification">
      <t>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.</t>

      <t><figure>
          <artwork><![CDATA[                     [ 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 Architecture]]></artwork>
        </figure></t>
    </section>

    <section title="Core Entities and Data Structures">
      <section title="Capability Table">
        <t>A Capability Table is maintained by each ACMS to determine the
        next-hop ACMS for capability-related requests. Each table entry
        associates a target capability type with one or more next-hop ACMSs.
        Each entry consists of a target capability type and the corresponding
        next-hop ACMS.</t>

        <t>For illustration purposes, consider ACMS responsible for Capability
        A.the capability table it maintains is presented in a similar form as
        shown in Table 1:</t>

        <t><figure>
            <artwork><![CDATA[Table 1 Capability Table of ACMS responsible for Capability A
| Target Capability Type   | Next-Hop ACMS |
|             A            |       -       |
|             B            |       B       |
|             C            |      B/D      |
|             D            |       D       |]]></artwork>
          </figure></t>

        <t>Capability tables are constructed based on inter-ACMS connectivity
        and are synchronized dynamically. Capability Tables are constructed as
        follows:</t>

        <t><list style="symbols">
            <t>ACMSs may establish logical adjacencies through configured or
            otherwise established inter-ACMS relationships.</t>

            <t>Each ACMS advertises the capability types for which it is
            responsible.</t>

            <t>Capability entries are generated based on the exchanged
            advertisements.</t>
          </list></t>
      </section>

      <section title="Access Mapping Table">
        <t>An Access Mapping Table is maintained by each ACAS to record the
        association between locally attached AI Agents and their corresponding
        Agent IDs. The table enables local capability matching during the
        capability discovery procedure.Each entry includes: agent ID,
        capability types,and access link identifier.</t>

        <t>For illustration purposes, consider a general ACAS maintains the
        access mapping table as shown in Table 2:</t>

        <t><figure>
            <artwork><![CDATA[               Table 2 Access Mapping Table of general ACAS
| Agent |    Access Link ID    |  Agent ID  | Agent Capability Type |
|   1   | Physical Port Number |   AID-001  |            D          |
|   2   |        VLAN ID       |   AID-002  |          B2, A        |
|   3   |       VXLAN VNI      |   AID-003  |          B2, C        |
|   4   |       MPLS Label     |   AID-004  |            E          |
|   5   |       SRv6 SID       |   AID-005  |            F          |]]></artwork>
          </figure></t>

        <t>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.</t>
      </section>
    </section>

    <section title="Distributed Capability Onboarding Procedure">
      <t>A distributed and hierarchical capability onboarding mechanism is
      defined. An AI Agent onboards to an ACAS which aggregate and propagate
      agent information to distributed ACMSs based on its local Access Mapping
      Table. ACAS subsequently advertises its agent information toward the
      corresponding ACMS. The capability onboarding procedure consists of the
      following steps:<list style="numbers">
          <t>An AI Agent onboards to an ACAS and sends a capability onboarding
          request, including capability types and agent ID, to the attached
          ACAS. The ACAS records the received information in its Access
          Mapping Table</t>

          <t>The ACAS summarizes onboardings belonging to the same capability
          type. The summarized information is propagated toward the
          responsible ACMS.</t>

          <t>The ACAS forwards summarized information toward the target ACMS
          according to the capability table.</t>

          <t>The target ACMS authenticates and confirms the onboarding.</t>

          <t>An onboarding success response (or Onboarding ACK) is
          returned.</t>
        </list></t>

      <t>The ACMS relays onboarding information based on the capability table.
      When the ACAS directly connected to an agent happens to be the agent's
      target ACMS, capability onboarding is completed directly on that ACMS.
      Otherwise, the target management server have to be located according to
      the capability table.</t>
    </section>

    <section title="Intent-Driven Capability Discovery Procedure">
      <t>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. ACMSs synchronize summarized capability information
      and provide capability-based forwarding for discovery requests. The
      intent-driven capability discovery mechanism is as follows:<list
          style="numbers">
          <t>A requester submits a task intent to the service domain, and the
          client-side AI Agent attaches to an ingress ACMS.</t>

          <t>The ingress ACMS maps intent to capability vector and determines
          the next-hop ACMS 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.</t>

          <t>The ACMS sends an agent query request to the target ACAS.</t>

          <t>The target ACAS performs local matching according to the access
          mapping table.</t>

          <t>The ACAS returns the matching results (i.e., a list of Agent IDs
          of all available agents) to the requesting ACMS, which then returns
          the matching Agent IDs to the requesting entity.</t>
        </list></t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Authentication between agents, ACASs, and ACMSs is REQUIRED.
      Capability advertisements SHOULD be integrity-protected. Access control
      policies MUST be enforced at onboarding and discovery stages.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBD</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <reference anchor="draft-li-dmsc-macp-05">
        <front>
          <title>Gateway Requirements for Dynamic Multi-agents Secured
          Collaboration. draft-liu-dmsc-gw-requirements.
          &lt;https://datatracker.ietf.org/doc/draft-liu-dmsc-gw-requirements/&gt;</title>

          <author fullname="Bing Liu" initials="B" surname="L">
            <organization/>
          </author>

          <date day="16" month="January" year="2026"/>
        </front>
      </reference>

      <reference anchor="draft-yang-dmsc-ioa-task-protocol">
        <front>
          <title>Internet of Agents Task Protocol (IoA Task Protocol) for
          Heterogeneous Agent Collaboration.
          draft-yang-dmsc-ioa-task-protocol.
          &lt;https://datatracker.ietf.org/doc/draft-yang-dmsc-ioa-task-protocol/&gt;</title>

          <author fullname="Cheng Yang" initials="C" surname="Y">
            <organization/>
          </author>

          <date day="14" month="January" year="2026"/>
        </front>
      </reference>

      <reference anchor="draft-sz-dmsc-iaip">
        <front>
          <title>Intent-based Agent Interconnection Protocol at Agent Gateway.
          draft-sz-dmsc-iaip.
          &lt;https://datatracker.ietf.org/doc/draft-sz-dmsc-iaip/&gt;</title>

          <author fullname="ShengSun" initials="S" surname="S">
            <organization/>
          </author>

          <date day="9" month="February" year="2026"/>
        </front>
      </reference>

      <reference anchor="draft-zhang-dmsc-ioa-semantic-interaction">
        <front>
          <title>Ontology-based Semantic Interaction for Internet of Agents.
          draft-zhang-dmsc-ioa-semantic-interaction.
          &lt;https://datatracker.ietf.org/doc/draft-zhang-dmsc-ioa-semantic-interaction/&gt;</title>

          <author fullname="Lianhua Zhang" initials="L" surname="Z">
            <organization/>
          </author>

          <date day="4" month="February" year="2026"/>
        </front>
      </reference>

      <reference anchor="draft-zhang-dmsc-gateway-directory-sync">
        <front>
          <title>Gateway Capability Directory and Synchronization for Internet
          of Agents. draft-zhang-dmsc-gateway-directory-sync.
          &lt;https://datatracker.ietf.org/doc/draft-zhang-dmsc-gateway-directory-sync/&gt;</title>

          <author fullname="Lianhua Zhang" initials="L" surname="Z">
            <organization/>
          </author>

          <date day="28" month="April" year="2026"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
