# drafts

name: draft-zl-agents-networking-architecture
rev: 00
title: Agents Networking Architecture for Enterprise and Broadband
time: 2025-10-20T15:40:43Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T15:40:43Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "A2A protocols", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:03.420438+00:00
abstract:
  This document introduces agents networking architecture and defines
     the core components of agent networking, as well as typical
     interactions among these key components.

full_text:
  network working group                                           L. Zhang
  Internet-Draft                                                    B. Liu
  Intended status: Informational                       Huawei Technologies
  Expires: 23 April 2026                                           N. Geng
                                                                    Huawei
                                                                   Z. Wang
                                                               Independent
                                                           20 October 2025


        Agents Networking Architecture for Enterprise and Broadband
                 draft-zl-agents-networking-architecture-00

  Abstract

     This document introduces agents networking architecture and defines
     the core components of agent networking, as well as typical
     interactions among these key components.

  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 23 April 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.











  Zhang, et al.             Expires 23 April 2026                 [Page 1]


  Internet-Draft       Agents Networking Architecture         October 2025


     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  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  IoA architecture and Components . . . . . . . . . . . . . . .   3
       2.1.  Overview of Agents Networking . . . . . . . . . . . . . .   3
       2.2.  Agent Certificate Authority . . . . . . . . . . . . . . .   4
       2.3.  Agent Registration Server . . . . . . . . . . . . . . . .   4
       2.4.  AI Agents . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.5.  Agent Gateway . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Interactions of Agents Networking Architecture  . . . . . . .   6
       3.1.  Interactions between Agents and ACAs  . . . . . . . . . .   6
         3.1.1.  Certificate Application . . . . . . . . . . . . . . .   6
         3.1.2.  Certificate Management  . . . . . . . . . . . . . . .   7
       3.2.  Interactions between Agents and ARSs  . . . . . . . . . .   8
         3.2.1.  Registration  . . . . . . . . . . . . . . . . . . . .   8
         3.2.2.  Information management  . . . . . . . . . . . . . . .   8
         3.2.3.  Agents Discovery  . . . . . . . . . . . . . . . . . .   9
       3.3.  Interactions between Agents and AGws  . . . . . . . . . .   9
         3.3.1.  Status Maintenance  . . . . . . . . . . . . . . . . .   9
         3.3.2.  Collaboration Support . . . . . . . . . . . . . . . .  10
       3.4.  Interactions between AGws and AGws  . . . . . . . . . . .  10
         3.4.1.  AGw Interconnection . . . . . . . . . . . . . . . . .  10
         3.4.2.  Resources Synchronization . . . . . . . . . . . . . .  11
         3.4.3.  Status Maintenance  . . . . . . . . . . . . . . . . .  11
         3.4.4.  Relay Forwarding  . . . . . . . . . . . . . . . . . .  12
       3.5.  Interactions between ARSs . . . . . . . . . . . . . . . .  12
     4.  Operational and Manageability Considerations  . . . . . . . .  12
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
     8.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13









  Zhang, et al.             Expires 23 April 2026                 [Page 2]


  Internet-Draft       Agents Networking Architecture         October 2025


  1.  Introduction

     With the rapid development of artificial intelligence, single-agent
     systems have gradually revealed their limitations in handling
     complex, multi-task, and cross-domain scenarios.  Agent networking,
     as a core paradigm for breaking through individual capabilities and
     achieving collective intelligence, has become a key trend in the
     future development of agents.

     This document introduces agents networking architecture and defines
     the core components of agent networking, as well as typical
     interactions among these key components.

  1.1.  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  IoA architecture and Components

  2.1.  Overview of Agents Networking

     The overall architecture of agents networking is shown in Figure 1.

         +-----+         +-----+         |       +-----+          +-----+
         |ACA 1|         | ARS1|-----------------| ARS2|          |ACA 2|
         +--+--+         +--+--+         |       +--+--+          +--+--+
            |               |            |          |                |
            +---+-----------+----+       |       +--+------------+---+
                |                |       |       |               |
            +---+---+        +---+---+   |   +---+---+       +---+---+
            |       |        |       |   |   |       |       |       |
            |Agent a|--------|Agent b|   |   |Agent x|-------|Agent y|
            |       |        |       |   |   |       |       |       |
            +---+---+        +---+---+   |   +---+---+       +---+---+
                |                |       |       |               |
                |            +---+---+   |   +---+---+           |
                +------------| AGw 1 |-------| AGw 2 |-----------+
                             +---+---+   |   +---+---+
                 Domain1                 |               Domain2

                    Figure 1: Agents Networking architecture






  Zhang, et al.             Expires 23 April 2026                 [Page 3]


  Internet-Draft       Agents Networking Architecture         October 2025


     The architecture of agents networking consists of four key
     components, the Agent Certificate Authority(ACA), the Agent
     Registration Server(ARS), the Agents, and the Agent Gateway(AGw).

  2.2.  Agent Certificate Authority

     An Agent Certificate Authority (ACA) is essentially a trusted third-
     party organization that issues and manages digital certificates for
     intelligent agents (Agents).  Its core function is to ensure the
     authenticity of Agent identities and the security of their
     interactions.  By issuing digital certificates that contain key data
     such as Agent identity information and public keys, it enables other
     Agents or systems to verify the identity of the Agent, preventing the
     access of counterfeit or malicious Agents.

     The major functions of ACA include Certificate Issuance and
     Certificate Management.

     *  Certificate Issuance: It verifies the real identity of an Agent
        (including developer information, affiliated organization,
        functional permissions, etc.).  After verification, a unique
        digital certificate is generated and issued.

     *  Certificate Management: It is responsible for the full-lifecycle
        management of certificates, including certificate renewal (renewal
        before the expiration of validity period) and revocation (when an
        Agent is deregistered or its key is leaked).

  2.3.  Agent Registration Server

     An Agent Registration Server(ARS) is specifically responsible for
     Agent identity registration, capability profiling, and accurate
     discovery-matching.  Acting as the "identity management center" and
     "resource directory library" in the Agent ecosystem.  The major
     functions of ARS include agent registration, agent information
     management, and agent discovery.  The ARS can be either centralized
     or distributed, but regardless of the form, information
     synchronization between different servers is essential.  For easily
     deployment, the ARS also can be integrities in the AGw.

     *  Agent registration: The agent sends a registration request with
        its information, upon the verification is passed, then the ARS
        generates a unique "resource ID" for the Agent, creates a profile
        in the "Agent Database" to record all the agent information.

     *  Information management: It is responsible for the full-lifecycle
        management of Agents profiles, including update (when a gent's
        information changes) and delete (when an Agent is discarded).



  Zhang, et al.             Expires 23 April 2026                 [Page 4]


  Internet-Draft       Agents Networking Architecture         October 2025


     *  Agent Discovery: The ARS maintains a dynamically updated "Agent
        Database" that records key information of all Agents registered at
        this ARS and synchronized from other ARSs.  An agent needs
        collaboration just need to send a capability request to the ARS,
        then the ARS will quickly filter out matching target Agents and
        return them information to the requested agent.

  2.4.  AI Agents

     The functions that should be supported for AI Agent interconnection
     include task orchestration, task management, and session management.

     *  Task orchestration: It breaks down complex tasks into subtasks,
        assigns them to Agents with corresponding capabilities, and
        clarifies the collaboration process.  Based on the capabilities of
        each Agent (e.g., a Flight Agent specializes in ticket booking, a
        Visa Agent specializes in visa processing), it plans the execution
        sequence and dependency relationships of tasks to ensure efficient
        resource utilization.

     *  Task Management: It tracks subtask progress, handles exceptions,
        and ensures the overall task progresses as planned.  It monitors
        the execution status of each subtask (e.g., "pending," "in
        progress," "completed," "failed"), records task output results
        (such as flight confirmation numbers and visa documents), and
        addresses issues during execution.

     *  Session Management: It maintains the continuity and integrity of
        interactive sessions, ensuring historical information is traceable
        and context is not disconnected.  It manages the lifecycle of
        conversations between Agents, records all interactive content
        (e.g., instructions, feedback, problem discussions), and provides
        contextual support for subsequent interactions to avoid repeated
        communication.

  2.5.  Agent Gateway

     An AGw essentially serves as a "Connection Hub" and "Security
     Steward" in the process of agent communication.  Its core role is to
     resolve interconnection issues between different Agents of different
     domains while ensuring secure, efficient, and orderly communication.
     The AGw should support the following functions:

     *  Route Management: When it comes to cross-domain agent
        communication, an agent or AGw may not be able to directly
        establish a connection with another agent in a different domain
        for some reasons.  In such cases, the AGw needs to have routing
        management function.  The routing management function generates



  Zhang, et al.             Expires 23 April 2026                 [Page 5]


  Internet-Draft       Agents Networking Architecture         October 2025


        dynamic routing entries based on Agent information advertised by
        other AGws, and guides message forwarding between cross-domain
        Agents—essentially acting as a "cross-domain traffic commander"
        for the Agent ecosystem.

     *  Security Protection: Agent communication may involve sensitive
        data (such as user privacy, core business data), and malicious
        external Agents may attempt to forge identities, steal data, or
        launch attacks.  The AGw serves as a core barrier for security
        protection.  The AGw should supports the identity verification of
        Agents, data encryption, and access control for agents.

     *  Traffic Control: If multiple Agents simultaneously send discovery
        requests to the AGw, or concentrate on initiating collaboration
        requests after finding target Agents, the AGw may become
        overloaded or the target Agents may crash.  The AGw should impose
        traffic limits on discovery requests.  For example, it sets a cap
        on the number of discovery queries per Agent per minute to prevent
        malicious Agents from occupying resources with frequent queries.

     *  Dual Translation (Protocol and Language): Agents may face two key
        obstacles to direct communication: inconsistent technical
        protocols and different natural language expressions.  The AGw's
        translation function addresses both issues simultaneously to
        ensure seamless information transmission.  On the one hand, it
        automatically identifies the communication protocol (e.g., HTTP,
        MQTT, gRPC, or custom protocols) and data format (e.g., JSON,
        Protobuf) used by the sending Agent, then converts them into the
        standard protocol/format supported by the receiving Agent.  On the
        other hand, it handles natural language differences between Agents
        (e.g., Agent X uses English to send "Book a twin room" while Agent
        Y only understands Chinese).  The AGw automatically translates the
        content into the target language, ensuring the receiving Agent
        accurately grasps the semantic intent without additional language
        adaptation.

  3.  Interactions of Agents Networking Architecture

  3.1.  Interactions between Agents and ACAs

  3.1.1.  Certificate Application

     This is the most fundamental first interaction between an agent and
     an ACA.  Its purpose is to enable the Agent to pass the ACA's
     verification and obtain a digital certificate that proves its
     legitimacy.  It includes three steps:





  Zhang, et al.             Expires 23 April 2026                 [Page 6]


  Internet-Draft       Agents Networking Architecture         October 2025


     *  Application request: The Agent sends a certificate application to
        the CA, along with key supporting materials.  These materials
        include identity-verifying information (such as the qualification
        documents of its affiliated organization, the identity of its
        developer), the Agent's own attributes (such as function type,
        permission scope, skills), and a public key for subsequent
        encrypted communication (the Agent retains the corresponding
        private key and does not disclose it to external parties).

     *  Application verification: After receiving the application, the ACA
        checks the authenticity and compliance of the materials.  For
        example, it verifies whether the organization's qualifications are
        valid, whether the public key meets encryption standards, and
        whether the Agent's functions fall within permitted scopes.  If no
        issues are identified, the application is approved.

     *  Certificate generation: Upon approval, the ACA generates a digital
        certificate containing specific information.  This information
        includes the Agent's identity details, public key, certificate
        validity period, and the ACA's digital signature (used to prove
        the certificate is legally issued by the CA).  The CA then sends
        this certificate to the applying Agent.

  3.1.2.  Certificate Management

     A certificate is not permanently valid.  The Agent must cooperate
     with the ACA to complete operations such as renewal and revocation,
     ensuring the "digital identity" remains valid and secure.

     *  Certificate status query: The Agent can send a query request to
        the ACA at any time to confirm the current status of its
        certificate—such as whether it is still within the validity period
        or has been revoked due to abnormal circumstances.  This allows
        the Agent to identify and resolve certificate-related issues
        promptly (e.g., applying to the CA for recovery if the certificate
        was incorrectly revoked).

     *  Certificate renewal: When the certificate is about to expire, the
        Agent proactively sends a renewal request to the ACA, along with
        the soon-to-expire old certificate.  If its identity information
        (such as affiliated organization, permissions) has not changed,
        the application materials can be simplified.  After the ACA
        approves the request, it generates a new certificate with an
        updated validity period and sends it to the Agent.  The Agent
        replaces the old certificate with the new one to ensure the
        identity credential remains valid.





  Zhang, et al.             Expires 23 April 2026                 [Page 7]


  Internet-Draft       Agents Networking Architecture         October 2025


     *  Certificate revocation application: If the Agent experiences
        issues such as private key leakage, permanent deactivation of
        functions, or deregistration of its affiliated organization, the
        Agent (or its administrator) sends a certificate revocation
        request to the ACA to invalidate the currently held certificate.
        After confirming the request's legitimacy, the ACA adds the
        certificate to the "Certificate Revocation List (CRL)" to prevent
        the invalid certificate from being misused by others.

  3.2.  Interactions between Agents and ARSs

  3.2.1.  Registration

     An Agent must first complete registration with the ARS before it can
     be discovered by other Agents and participate in collaboration.  This
     is the foundational interaction between the two parties.  It includes
     three steps:

     *  Registration request: The Agent sends a registration request to
        the ARS, accompanied by its information.  This includes its
        identifier (e.g., Agent name), description of core capabilities
        (e.g., "hotel booking," "data format conversion"), supported
        communication protocols/languages (e.g., HTTP, Chinese), and
        credentials for identity verification (e.g., a digital certificate
        issued by an ACA).

     *  Registration verification: The ARS verifies the legitimacy of the
        Agent's identity (e.g., checking if the CA certificate is valid)
        and confirms the completeness of the registration information.
        Upon successful verification, the ARS creates a profile for the
        Agent in its "Agent Database," recording key data such as the
        Agent's capabilities, online status, and communication address to
        complete the registration.

     *  Registration response: The ARS feeds back results ("registration
        successful" or "registration failed," e.g., due to failed identity
        verification or missing information) to the Agent.

  3.2.2.  Information management

     After registration, the Agent needs to continuously interact with the
     ARS to update its status and information, preventing the ARS's
     profile from becoming "outdated" and causing other Agents to match
     invalid resources.

     *  Information update: If an Agent upgrades its capabilities or
        changes its communication address (e.g., IP change due to server
        migration), it needs to proactively send an "information update



  Zhang, et al.             Expires 23 April 2026                 [Page 8]


  Internet-Draft       Agents Networking Architecture         October 2025


        request" to the ARS with the updated content.  After review, the
        ARS updates the corresponding profile information to ensure the
        accuracy of subsequent query results.

     *  Agent deregistration: When the Agent needs to go offline
        permanently (e.g., function deactivation, dissolution of the
        affiliated entity), it sends a "deregistration request" to the ARS
        with the resource ID.  Upon receipt, the ARS marks the Agent's
        profile as "deregistered" or deletes it from the "discoverable
        resource pool" to avoid invalid queries.

  3.2.3.  Agents Discovery

     This is the core service provided by ARS for agents, which helps them
     quickly identify target agents that can solve problems through multi-
     dimensional filtering, avoiding random searches, it includes two
     steps.

     *  Discovery request: If an Agent needs a collaborator with agents
        supporting specific capabilities, it sends a discovery request to
        the ARS, specifying the capabilities and associated other
        requirements.

     *  Discover response: Based on the request criteria, the ARS filters
        matching target Agents from the "Agent Database" and feeds back
        the agent information to Agent A, if the target Agents are in
        other domains, the returned communication address should be the
        AGw addresses of those domains.

  3.3.  Interactions between Agents and AGws

     When an agent needs to communicate with an agent in another domain,
     the Communication sessions need to go through the AGw (When the two
     agents are within a single domain, whether a communication session
     needs to go through a AGw can be determined as requirements).

     Interactions between an Agent and an AGw revolve around two core
     scenarios: status maintenance and collaboration support.

  3.3.1.  Status Maintenance

     During the Agent's operation, ongoing interactions between the two
     parties are required to ensure stable and secure collaboration,
     primarily involving status synchronization and exception handling.







  Zhang, et al.             Expires 23 April 2026                 [Page 9]


  Internet-Draft       Agents Networking Architecture         October 2025


     *  Agent access: An agent should send an access request to the AGw to
        make it reachable by agents in other domains.  The AGw reviews its
        information and verifies its signature.  If the verification
        passed, then the AGw will create a record for it and advertise the
        agent information to other AGws.

     *  Status synchronization: After accessed, the Agent regularly sends
        "heartbeats" (e.g., every 30 seconds) to the AGw to synchronize
        its online status (e.g., "running normally," "temporarily
        offline").  If the AGw does not receive a "heartbeat" for an
        extended period, it marks the Agent's status as "offline" and
        temporarily removes it from the collaborative list, and
        synchronizes this information to other potentially associated AGw
        to prevent other Agents from initiating invalid requests.

     *  Deregistration request: If an Agent needs to stop services, it
        proactively sends a deregistration request to the AGw.  After
        receiving the request, the AGw deletes the Agent's record, and
        synchronizes this information to other potentially associated AGws
        to complete the exit process.

  3.3.2.  Collaboration Support

     When an Agent needs to collaborate with other Agents, the AGw
     provides support for "removing communication barriers".  It is
     composed by two phases.

     *  Transformation: When the AGw receives the message send by the
        request agent with a translation request, the AGw first
        decapsulates the received packet, extracting the original content
        from the message.  Then, it performs necessary adaptations, such
        as translating the content into the target language or converting
        the data structure to match the target protocol.  Finally, the AGw
        re-encapsulates the adapted content into the target Agent's
        protocol format and forwards it.

  3.4.  Interactions between AGws and AGws

     Interactions between an AGw and an AGw revolve around four core
     phases: AGw interconnection, resources synchronization, status
     synchronization, and relay forwarding.

  3.4.1.  AGw Interconnection

     This phase completes mutual identity verification and initial status
     synchronization between AGws.





  Zhang, et al.             Expires 23 April 2026                [Page 10]


  Internet-Draft       Agents Networking Architecture         October 2025


     *  Interconnection request: The initiating AGw sends an
        interconnection request(the request and ) to the receiving AGw,
        enclosing core information: its unique AGw ID, supported
        protocols, identity certificate, and current basic operational
        status.

     *  Interconnection response: The receiving AGw verifies the
        initiating AGw's identity and protocol compatibility.  If valid,
        it feeds back its own basic information and records AGw A's
        initial information in its "AGw Neighbor List".  If the
        verification failed, then it rejects the request.

  3.4.2.  Resources Synchronization

     Resource synchronization and status maintenance focuses on sharing
     static/dynamic information of registered Agents, ensuring AGws can
     accurately locate potential collaboration partners across domains.

     *  Resource synchronization: AGws exchange the summary of registered
        agents' information, including Agent ID, core capabilities (e.g.,
        "flight booking", "real-time translation"), and supported
        communication protocols/languages (e.g., gRPC, Chinese).  The
        Synchronization take place whenever a new AGw peer is established
        or the registered agents' key information changes.

  3.4.3.  Status Maintenance

     The Status Maintenance of AGws is used to ensure the peer AGws are
     online and reachable.

     *  Status synchronization: When the interconnection is established,
        the AGws regularly sends "heartbeats" (e.g., every 30 seconds) to
        the peer AGws to synchronize its online status (e.g., "running
        normally," "temporarily offline").  If the AGw does not receive a
        "heartbeat" for an extended period, it marks the AGw's status as
        "offline" and temporarily removes it from the peer list, and set
        the "applicability" attribut of agents registered at that peer AGw
        as inapplicable.

     *  Disconnection request: If an AGw needs to stop services, it
        proactively sends a disconnection request to its peer AGw.  After
        receiving the request, the peer AGw deletes the AGw from its peer
        list, and remove the Agents registered at that peer AGw from the
        "Agent Database".







  Zhang, et al.             Expires 23 April 2026                [Page 11]


  Internet-Draft       Agents Networking Architecture         October 2025


  3.4.4.  Relay Forwarding

     Relay Forwarding leverages pre-synchronized resource and status data
     to enable seamless data transmission between cross-AGw Agents.

     *  When an AGw receives a packet from its agents to an agent in
        another domain, it will decapsulates the packet and get the "agent
        ID" of the target agent.  Then it looks up the routing table to
        get the target AGw and forward the packet to it (during the
        forwarding, the packet will be encapsulated to adapt to the target
        agent).

  3.5.  Interactions between ARSs

     Interactions between ARS focus on "breaking resource silos".  Through
     cross-ARS information synchronization, they enable Agent resources
     managed by different ARSs to be globally discoverable and
     collaborable in a trusted manner.  The detailed interactions between
     ARS can be quit different among different ARS forms, it depends on
     the implement manner of ARS.

     Editors' note: typical interactions between ARS will be provide in
     future.

  4.  Operational and Manageability Considerations

     TBD

  5.  Security Considerations

     TBD

  6.  IANA Considerations

     This document has no IANA actions.

  7.  Acknowledgements

     TBD

  8.  Normative References

     [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>.





  Zhang, et al.             Expires 23 April 2026                [Page 12]


  Internet-Draft       Agents Networking Architecture         October 2025


     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  Authors' Addresses

     Li Zhang
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: zhangli344@huawei.com


     Bing Liu
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: leo.liubing@huawei.com


     Nan Geng
     Huawei
     Beijing
     China
     Email: gengnan@huawei.com


     ZiHang Wang
     Independent
     Beijing
     China
     Email: 1639283202@qq.com

















  Zhang, et al.             Expires 23 April 2026                [Page 13]


name: draft-wmz-nmrg-agent-ndt-arch
rev: 03
title: Network Digital Twin and Agentic AI based Architecture for AI driven Network Operations
time: 2026-02-24T07:19:56Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-28T07:19:56Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Model serving/inference", "Policy/governance", "Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:03.420440+00:00
abstract:
  A Network Digital Twin (NDT) provides a network emulation tool usable
     for different purposes such as scenario planning, impact analysis,
     and change management.  Integrating a Network Digital Twin into
     network management together with Agentic AI, it allows the network
     management activities to take user intent or service requirements as
     input, automatically assess, model, and refine optimization
     strategies under realistic conditions but in a risk-free environment.
     Such environment that operates to meet these types of requirements is
     said to have AI driven Network Operations.

     AI driven Network Operations brings together existing technologies
     such as Agentic AI and Network Digital Twin which may be seen as the
     use of a toolbox of existing components enhanced with a few new
     elements.

     This document describes an architecture for AI driven network
     operations and shows how these components work together with network
     digital twin and Agentic AI capabilities.  It provides a cookbook of
     existing technologies to satisfy the architecture and realize intent-
     based network management to meet the needs of the network service.

full_text:
  Network Management                                                 Q. Wu
  Internet-Draft                                                    Huawei
  Intended status: Informational                                   C. Zhou
  Expires: 28 August 2026                                     China Mobile
                                                           L. M. Contreras
                                                                Telefonica
                                                                    S. Han
                                                              China Unicom
                                                                   Y. Hong
                                                        Daejeon University
                                                          24 February 2026


    Network Digital Twin and Agentic AI based Architecture for AI driven
                             Network Operations
                    draft-wmz-nmrg-agent-ndt-arch-03

  Abstract

     A Network Digital Twin (NDT) provides a network emulation tool usable
     for different purposes such as scenario planning, impact analysis,
     and change management.  Integrating a Network Digital Twin into
     network management together with Agentic AI, it allows the network
     management activities to take user intent or service requirements as
     input, automatically assess, model, and refine optimization
     strategies under realistic conditions but in a risk-free environment.
     Such environment that operates to meet these types of requirements is
     said to have AI driven Network Operations.

     AI driven Network Operations brings together existing technologies
     such as Agentic AI and Network Digital Twin which may be seen as the
     use of a toolbox of existing components enhanced with a few new
     elements.

     This document describes an architecture for AI driven network
     operations and shows how these components work together with network
     digital twin and Agentic AI capabilities.  It provides a cookbook of
     existing technologies to satisfy the architecture and realize intent-
     based network management to meet the needs of the network service.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Discussion of this document takes place on the Network Management
     mailing list (nmrg@irtf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/nmrg.

     Source for this draft and an issue tracker can be found at
     https://github.com/QiufangMa/Agent-architecture.

  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 28 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.

  Table of Contents

     1.  Introduction
     2.  Conventions and Definitions
     3.  Introduction of Concepts
       3.1.  Generative AI and Agentic AI
       3.2.  Network Digital Twin
     4.  Characteristics of AI driven Network Operations
     5.  Architecture Design
       5.1.  Overall Architecture
       5.2.  Functional Components
         5.2.1.  Network Applications
         5.2.2.  Autonomous Domain
       5.3.  Functional Interfaces
         5.3.1.  Human in the Loop
         5.3.2.  Application to Network AI Agent Interface
         5.3.3.  Network AI Agent to Task AI Agent Interface (Single
                 Autonomous Domain)
         5.3.4.  Network AI Agent to Network AI Agent Interface (Cross
                 Autonomous Domain)
         5.3.5.  Network AI Agent/Task AI Agent to Agent Gateway
                 Interface
         5.3.6.  Network AI Agent to Network Digital Twin Interface
         5.3.7.  Network AI Agent to Knowledge Base Interface
         5.3.8.  Task AI Agent to Physical Network Interface
         5.3.9.  Feedback-driven Improvement Interface
         5.3.10. Network Element AI Agent and Network AI Agent
                 Collaboration Interface
     6.  AI Driven Network Operations: Relationship Between
             Characteristics and Functional Components
     7.  AI Agent Registration and Team formation
     8.  Agent to Agent Communication Security
     9.  AI Driven Network Operations: A collection of Use Cases
       9.1.  Multi-Agent Collaboration on Network Configuration Change
       9.2.  Multi-Agent Collaboration on Network Troubleshooting
       9.3.  Multi-Agent Collaboration on Network Optimization
       9.4.  Network level Energy Efficiency Management in the
             IP+Optical network
       9.5.  Network Security Drills (Human in the Loop)
     10. Challenges of Integrating Network Digital Twin and Agentic AI
             into Network Management
       10.1.  Create domain specific language for agents and models
       10.2.  Trust and Security
       10.3.  Protocols between Agent and Agent/Human operator/Tools
         10.3.1.  High Risk Operations
         10.3.2.  The Timeliness Requirements of Collaboration
         10.3.3.  Collaboration Reliability
       10.4.  Benchmarking
         10.4.1.  Single Agent Benchmarking
         10.4.2.  Multi-Agent Benchmarking
     11. Security Considerations
     12. IANA Considerations
     13. Conclusion
     14. References
       14.1.  Normative References
       14.2.  Informative References
     Appendix A.  Acknowledgements
     Appendix B.  Changes between Revisions
     Contributors
     Authors' Addresses

  1.  Introduction

     The rapid expansion of network scale and the increasing demands on
     these networks necessitate of continuous network reconfiguration to
     better adapt to ever-changing service requirements.

     Since network changes are directly related to service operations, any
     successful change needs to not only ensure that new services are
     provisioned smoothly, but also that existing services are not
     affected and that no problems are introduced with the new
     configurations.  Network operators are, therefore, increasingly
     cautious about making network changes, given that they need to review
     the solution design as well as evaluate all change impacts, before
     making any change.  Then, after the change, they need to perform
     dialing tests, monitor traffic, and manually check table entries.

     The Network Digital Twin (NDT)
     [I-D.irtf-nmrg-network-digital-twin-arch] has been proposed as a mean
     to provide a network emulation tool for scenario planning, impact
     analysis, and change management.  Agentic AI introduces disruptive
     paradigm to the network management and allow declarative intent
     interpretation, multi-step action, multi-agent coordination.
     Integrating a Network Digital Twin into network management together
     with Agentic AI, it allows network management activities to
     dynamically adapt to customer needs, network changes, as well as to
     automatically assess, model, and refine optimization strategies under
     realistic conditions but in a risk-free environment.  An environment
     that operates to meet these types of requirements is said to have AI
     driven network operations.

     AI Driven network operations provide the following capabilities to
     applications by coordinating the components that operate and manage
     the network:

     *  Service intent and service assurance work together to ensure that
        the network change or network optimization aligns with business
        goals and that the services provided meet the agreed-upon Service
        Level Agreements (SLAs).

     *  Provide network capacity planning and ensure that the network has
        sufficient capacity , resources, and infrastructure to meet
        current and future demands.

     *  Provide simulation on fault scenarios, formulate recovery plans,
        and verify whether the plans are applicable and effective so that
        the service will not be affected during disaster recovery drill.

     *  Support fault and risk detection and provide network health check
        and network risk check.

     *  Model the network configuration change and use a virtual topology
        model to test network changes and assess the effect of the network
        configuration changes on the network.

     *  Model the protocol operations and interactions among devices in
        the network and simulate specific networking protocols such as IS-
        IS, OSPF, BGP, SR, etc to understand how they perform under
        different conditions.

     *  Model traffic flow across the network, including traffic
        generation, flow control, routing, and congestion control and
        evaluate traffic's impact on network performance.

     *  Support generation of rectification solutions for potential
        network risks and provide verification on the repair solution in
        seconds, including loop, address conflict, and security policy
        conflict.

     This document describes an architecture for AI Driven network
     operations, showing how these components work together with network
     digital and AI capabilities.  It provides a cookbook of existing
     technologies to satisfy the architecture and realize intent-based
     networking to meet the needs of applications.

  2.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

     The document uses the following definitions and acronyms defined in
     [I-D.irtf-nmrg-network-digital-twin-arch]:

     *  Network Digital Twin (NDT)

     *  Artificial Intelligence (AI)

     The following acronyms are used throughout this document:

     *  Generative Artificial Intelligence (Gen-AI)

     *  Large Language Model (LLM)

     *  Retrieval-Augmented Generation (RAG)

     *  Agentic AI [I-D.hong-nmrg-agenticai-ps]

     *  Multiple Agent System (MAS)

     *  Remote Code Execution (RCE)

     Besides, this document defines the following terminology:

     Network AI Agent:  Network AI Agent is an autonomous system or entity
        with awareness of its environment, capable of conducting analysis,
        making decisions, and executing actions with specific intent based
        on its knowledge representation to achieve a set of service goals
        [TMF-1251D].  In addition, it is able of planning the tasks and
        decompose the tasks into several sub-tasks and coordinate with
        Task agent for these sub-tasks.

     Task AI Agent:  Task AI Agent is responsible for coordinating with
        Network AI Agent in the multi-Agent System and executing specific
        task assigned by Network AI Agent.

  3.  Introduction of Concepts

  3.1.  Generative AI and Agentic AI

     The integration of AI into network operations has marked a
     significant leap forward in the pursuit of network automation and
     intelligence, while generative AI further enhances the role of AI
     driven network operations and management.  Generative AI is a
     subfield of AI that uses generative models such as Large Language
     Models (LLMs) to generate new and original content such as text,
     images, videos, or other forms of data with the capability to adapt
     and make decisions to achieve specific goals.

     Agentic AI refers to the broader category of AI systems that exhibit
     "agency"—the ability to act independently and iteratively to perform
     tasks without constant human prompting [I-D.hong-nmrg-agenticai-ps].
     In the context of network operations and management, Network AI
     agents are increasingly being designed to interact with physical
     world and act upon it based on tools [Google-Agents-Whitepaper] and
     perform network management tasks such as understanding user intent,
     generating network configurations, diagnosing and resolving network
     incidents [I-D.ietf-nmop-network-incident-yang].  Meanwhile, other
     SDOs also try to define terms related to Network AI agent in the
     context of network operations and management, e.g., TM Forum defines
     Autonomous Agent in [TMF-1251D] as one of AN (Autonomous Network)
     Terminologies.

  3.2.  Network Digital Twin

     The Network Digital Twin is a digital representation that is used in
     the context of network.  The concept and architecture of the Network
     Digital Twin are specified in
     [I-D.irtf-nmrg-network-digital-twin-arch].  Three core functional
     components which includes Data Repository component, a Service
     Mapping Models component, and an NDT Management component are
     introduced to characterize the Network Digital Twin and its reference
     architecture.

     The Network Digital Twin is widely recognized to be useful as an
     advanced platform for network emulation, serving as a tool for
     scenario planning, impact analysis, and change management.  By
     delivering applications requests to the Network Digital Twin through
     standardized interfaces (see Section 9.4 of
     [I-D.irtf-nmrg-network-digital-twin-arch]), the Network Digital Twin
     exposes the various capabilities to network applications.

  4.  Characteristics of AI driven Network Operations

     AIOPS was first defined by Gartner in 2016, combining "artificial
     intelligence" and "IT operations" to describe the application of AI
     and machine learning to enhance IT operations.  However there is no
     unified definition for characteristic of "AI driven network
     operations" within the networking industry.  Referring to the
     characteristics of AIOPS in IT field and the characteristics of
     networking itself, this document introduces six key elements (i.e.,
     awareness, decision, analysis, execution, intent and knowledge) to
     characterize the AI driven network operation and its use, as shown in
     Figure 1.  They together form a close-loop of network operation and
     management.

             +---------------------------------------------------+
             |                  +---------+                      |
             |                  |  Intent |                      |
             |                  +---------+                      |
             |                                                   |
             | +-----------+                       +-----------+ |
             | |  Analysis |                       | Decision  | |
             | +-----------+       --------        +-----------+ |
             |                 ////        \\\\                  |
             |                |AI Driven Network|                |
             |                |  Operations    |                 |
             |                 \\\\        ////                  |
             |                     --------                      |
             | +-----------+                      +------------+ |
             | |  Awareness|                      |  Execution | |
             | +-----------+                      +------------+ |
             |                                                   |
             |                 +-----------+                     |
             |                 | Knowledge |                     |
             |                 +-----------+                     |
             +---------------------------------------------------+

          Figure 1: Six Key Elements to Characterize AI driven network
                                   operation

     *  Intent:  Intent is defined as a set of operational goals and
           outcomes defined in a declarative manner without specifying how
           to achieve or implement them in [RFC9315].  The Network AI
           Agent must accurately interpret and understand the user's high-
           level business or operational objectives, this involves
           translating declarative requirements into specific network
           instructions, e.g., configurations.

     *  Knowledge:  The Network AI agent relies on a knowledge base that
           includes network policies, historical data, expert experience,
           extra-system experience (updates to LLMs/their implied
           ‘knowledge bases’) and Manually or semi-manually entered
           knowledge, e.g., new equipment spec sheets,best practices in
           product manual.  The knowledge is used to inform its analysis,
           decision-making, and execution processes.  Over time, the
           Network AI agent can expand its knowledge through machine
           learning, incorporating new data and experiences to improve its
           performance.  For example, it learns which configurations are
           optimal for specific scenarios or how to respond most
           effectively to particular types of network incidents
           [I-D.ietf-nmop-network-incident-yang].

     *  Analysis:  The Network AI agent continuously analyzes vast amounts
           of network data from various sources, including network
           telemetry [RFC9232] and external feeds, and identify the gap
           between user intent and the existing network status.  By
           integrating Network digital twin
           [I-D.irtf-nmrg-network-digital-twin-arch] with Network AI agent
           and leveraging machine learning and other data analytics
           techniques, it also identifies network fault, problem,
           incident, anomaly and perform data driven intelligent analysis
           such as service impact analysis, and so on.  Their distinction
           is further discussed in [I-D.ietf-nmop-terminology].

     *  Decision:  Based on the intent and network analysis, AI makes
           informed decisions.  By integrating network digital twin
           [I-D.irtf-nmrg-network-digital-twin-arch] and AI, the
           intelligence decisions making can be realized.  These decisions
           could involve dynamically adjusting network parameters, e.g.,
           rerouting traffic to avoid congestion.  The decision-making
           process is driven by predefined policies, real-time data
           analysis, and AI models (e.g., LLMs) that enable the Network AI
           agent to choose the best course of action to meet the specified
           intent.  Network AI agent may also verify the correctness of
           the decision outcome by performing some network simulation or
           validation process.

     *  Awareness:  Awareness is achieved through real-time monitoring and
           data collection.  The Network AI agent maintains a
           comprehensive visibility of the network, enabling it to make
           context-aware decisions.  Network operators can also use the
           awareness understand the exact cause of specific network issues
           and achieve closed-loop decision-making.

     *  Execution:  Once a decision is made, the Network AI agent executes
           the necessary actions to implement it.  This could involve,
           e.g., sending configuration to network controllers or network
           devices through NETCONF/RESTCONF protocols.  The execution is
           carried out in a controlled and precise manner to ensure that
           the network behaves as intended without causing disruptions.
           The Network AI agent also verifies that the executed actions
           have the desired effect and makes the proper adjustments if
           needed.

  5.  Architecture Design

  5.1.  Overall Architecture

     Figure 2 provides the overall architecture for integrating Network
     Digital Twin and Network AI Agent System.  The components and
     functional interfaces are discussed in Section 5.2 and Section 5.3,
     respectively.  The use cases described in Section 9 show how
     different components are used selectively to provide different
     services.  It is important to understand that the relationships and
     interfaces shown between components in this figure are illustrative
     of some of the common or likely interactions; however, this figure
     does not preclude other interfaces and relationships as necessary to
     realize specific functionality.

  +------------------------------------------------------------------------+
  |Network Applications                                                    |
  |            +-------+   +-------+          +-------+                    |
  |            | App 1 |   | App 2 |   ...    | App n |                    |
  |            +-------+   +-------+          +-------+                    |
  +-------------------------^----------------------------------------------+
                            | Intent
  +-------------------------+----------------------------------------------+
  |Autonomous Domain        |                                              |
  |+------------------------+-----------------------+   +----------------+ |
  ||Multi-Agent System      |                       |   |  Agent Gateway | |
  ||                +-------v--------+              |   |                | |
  ||                |Network AI Agent|              |   |+--------------+| |
  ||                +-------^--------+              |   || Registration || |
  ||                        |                       |   |+--------------+| |
  ||       +----------------+------------+--------+ <--->+--------------+| |
  ||       |                |            |        | |   ||   Security   || |
  ||+------v-----+ +--------v---+ +------v-----+  v |   |+--------------+| |
  |||Task Agent 1<->Task Agent 2<->Task Agent 3| ...<-+ |+--------------+| |
  ||+------------+ +------------+ +------------+    | | ||Observability || |
  |+-----------------------^------------------------+ | |+--------------+| |
  |                        |                          | |+--------------+| |
  |+-----------------------v------------------------+ | ||Knowledge Base|| |
  ||            Network Digital Twin                | | |+--------------+| |
  |+-----------------------^------------------------+ | +------^---------+ |
  |                        |                          |        |           |
  |+--------------------------------------------------v--------+---------+ |
  ||Physical Network                                           |         | |
  ||      +---------+    +------------------+             +----v----+    | |
  ||      |         |    |                  |             |  +-----+|    | |
  ||      |   NE    |    |NE(lightweight AI)|     ...     |NE|Agent||    | |
  ||      |         |    |                  |             |  +-----+|    | |
  ||      +---------+    +------------------+             +---------+    | |
  |+----------------+----------------------------------------------------+ |
  +------------------------------------------------------------------------+

     Figure 2: An Architecture for Integrating Network AI Agent with
                           Network Digital Twin

  5.2.  Functional Components

     This section describes the functional components shown as boxes in
     Figure 2.  The interactions between those components, the functional
     interfaces, are described in Section 5.3.

  5.2.1.  Network Applications

     Various network applications at the service level can effectively run
     over a AI driven Network operation platform to implement either
     conventional or innovative network operations, with low cost and less
     service impact on real networks.

     A network application may be a software tool that a user uses to make
     requests to the network to set up specific services such as end-to-
     end connections or scheduled bandwidth reservations or NOC
     Application /Service AI Agent Application that is responsible for
     monitoring, managing, and maintaining the health, performance, and
     availability of complex networks.

     Network applications make requests that need to be addressed by the
     AI driven network.  Such requests are exchanged through a northbound
     intent interface (e.g., Restful API, Natural Language Programming
     Interface(NLPI),A2A, A2A-T), so that they can be applied by multi-
     agent system at the appropriate twin instance(s).

  5.2.2.  Autonomous Domain

     An autonomous domain is a self-governing network that integrates NDT
     and AI driven capabilities to achieve autonomous network management.
     It comprises the following sub-components.

  5.2.2.1.  Multi-Agent System

     Multi-Agent system acts as the smart brain of the Autonomous Domain,
     which is responsible for conducting AI-based analysis and making
     decisions regarding network management operations.  It usually
     comprises a Network AI Agent and one or multiple task agents.

     The Network AI Agent coordinates cross-task-agent collaboration,
     aligns tasks with user intent, and supervises the task execution of
     each task agent.  And task agents are designed to perform specific
     functionalities, they could be scenario-oriented and classified
     according to the function they perform.  Task Agents can adapt to new
     circumstances through access to evolving knowledge and reasoning,
     planning.  It leverages the inference of LLM, the simulation of
     Network Digital Twin, and the contextual and domain-specific
     knowledge provided by Knowledge Base to accomplish specific network
     operation task.  Some ongoing efforts (MCP [MCP], A2A [A2A]) in the
     industry may help with multi-agents coordination.

  5.2.2.2.  Agent Gateway

     The Agent Gateway, which serves as a central management hub, provides
     essential services for the Multi-Agent System, including agent
     registration/discovery, authentication, observability, and knowledge
     base.

  5.2.2.2.1.  Registration

     AI Agents need to first discover each other and understand their
     capabilities to collaborate.  Agent Registration manages the process
     by which new agents could join the system, making them discoverable
     and available.  It supports the unified registration of all AI agents
     within the autonomous domain, including those residing on network
     devices.  Each Agent instance submits its own metadata information
     including URI, supported authentication methods, and capabilities to
     the Agent Registry.  And the consumer Agent (e.g., the Network AI
     Agent or task agent) could query or subscribe to the Agent Registry
     to find appropriate Agents for task execution.

     Agent skills [Agent-skills], introduced by Anthropic, provides a new
     way for Agents to improve how they perform specific tasks through
     folds that include instructions, scripts, and resources that are only
     loaded when needed.  Skills are folds containing a "skill.md" file,
     Registration component enables Agents to query directories for
     required skills.

     [A2A] implements Agent Registration by providing the Agent Card
     mechanism to ensure Agents from different vendors can register and
     discover other Agents they need.

  5.2.2.2.2.  Security

     The security component enforces trusted inter-Agent communication by
     verifying the identity of AI Agents and enforcing security policies
     throughout their interaction.  It provides unified security
     functionalities for all AI Agents within the autonomous domain,
     including those residing on network devices.  Some existing
     authentication methods such as OAuth 2.0, allow to issue each AI
     Agent its own authentication credentials to establish trusted
     communication.

     Standardized protocols like TLS (Transport Level Security) could be
     leveraged to protect sensitive data exchanged between AI Agents.

     It is also worth noting that once authenticated, authorization
     defines the specific tools and data an agent can access, which often
     using a Least Privilege access control method.  It is also
     recommended to log every Agent decision and tooling call to maintain
     audit trail.

  5.2.2.3.  Observability

     Observability component provides unified monitoring capabilities for
     all AI agents within the autonomous domain and enable network
     operators to gain deep insights into Agent behaviors.  It collects
     logs, metrics and traces for each Agent and provides end-to-end
     visibility into task progress, failures, and network performance such
     as latency.

     In addition, it can also make sure every action is governed by
     declarative policy, logged, and traceable for operational integrity,
     e.g., it can discern whether a human-in-the-loop approved an action
     or if the agent acted autonomously.

  5.2.2.3.1.  Knowledge Base

     The Knowledge Base serves as a crucial repository of information
     within the architecture.  It enables the injection of expert
     knowledge and chain of thoughts, provides the necessary knowledge and
     memory that helps Agents make more accurate and practive context-
     aware decisions.  It also helps mitigate the hallucination problems
     that can arise in large-scale models, which enhances the accuracy of
     task execution.  Additionally, the Knowledge Base plays a key role in
     providing the data needed for techniques like Retrieval-Augmented
     Generation (RAG), which further boosts the system's ability to
     generate reliable and relevant outputs.

     In case of coupling MCP [MCP] with the network management system, the
     new knowledge also can be used to support modification of the
     currently operating automation Closed Loop, such as: - Choice of
     tools (data, analytics, algorithms/decision processes, closed loops)
     - Orchestration of tools

  5.2.2.4.  Network Digital Twin

     A Network Digital Twin provides an enhanced and optimized solution in
     the face of increasing network and business types, scale, and
     complexity.  It simulates the behavior, performance, and
     characteristics of the actual network, which could help in validation
     and testing scenarios, analyzing and predicting network behavior
     without affecting the real physical network.

     As described in Section 7 of
     [I-D.irtf-nmrg-network-digital-twin-arch], the core functional
     components of an Network Digital Twin includes Data Repository,
     Service Mapping Models, and a Network Digital Twin Management
     component.  The Network Digital Twin collects the real-time
     operational and instrumentation data from network through the
     appropriate real network-facing input interfaces, and it delivers NDT
     services through appropriate application-facing output interfaces,
     which is the interfaces to Network AI Agent(s) in Figure 2.

  5.2.2.5.  Physical Network

     This is the actual hardware and infrastructure that makes up the
     network, which includes a set of network devices and wiring.  In a
     physical network, Network Elements (NEs) with Lightweight AI
     [I-D.irtf-nmrg-ai-challenges] or AI Agent may also achieve some local
     close loop without relying on human intervention.  It is also
     possible for Lightweight AI or AI Agent to coordinate with other AI
     Agent(s) to enhance the automation and efficiency of network
     operations.  The Network Lightweight AI models could be trained,
     validated, deployed, and executed on Network Elements, and further
     refined (e.g., model re-training) through monitoring and continuous
     optimization based on feedback from LLM.

  5.3.  Functional Interfaces

     This section describes the interfaces between functional components
     that might be externalized in an implementation allowing the
     components to be distributed across platforms.  Where existing
     protocols might provide all or most of the necessary capabilities,
     they are noted.

     As noted in Section 5.1, it is important to understand that the
     relationships and interfaces shown between components in Figure 2 are
     illustrative of some of the common or likely interactions; however,
     this figure and the descriptions in the subsections below do not
     preclude other interfaces and relationships as necessary to realize
     specific functionality.  Thus, some of the interfaces described below
     might not be visible as specific relationships in Figure 2, but they
     can nevertheless exist.

  5.3.1.  Human in the Loop

     The architecture allows human experts to monitor, guide, approve, or
     intervene in the AI driven network operations.  Human may provide
     guidance and make critical decisions when necessary.  By involving
     human in the process, the architecture can leverage their insights
     and experience, ensuring AI actions align with organizational goals.

     Human in the loop is also helpful to provide a safeguard for complex
     or sensitive decisions, where human judgement is essential to avoid
     potential errors or ethical dilemmas.

     This typically uses natural language as the primary mode of
     interaction, a chat platform that allows for conversational
     interaction with AI Agents can be leveraged.  In some scenarios,
     operators may use structured format for strategy injection via
     workflows.  Protocols like A2A [A2A], and RESTful API can be
     leveraged.

  5.3.2.  Application to Network AI Agent Interface

     Intent based Network Management helps in delivering application
     requests to the AI Driven network operation platform and exposing the
     various platform capabilities to network applications.

     Standardized protocols and interfaces facilitate smooth communication
     between applications and AI driven network operation platform and
     ensures different systems from various vendors can work together
     seamlessly.  The interfaces between Network applications and Network
     AI Agent can adopt IG1453 Agent to Agent Protocol for Telecoms (A2A-
     T) [A2A-T] specified by TM Forum.

  5.3.3.  Network AI Agent to Task AI Agent Interface (Single Autonomous
          Domain)

     This interface governs the coordination and task delegation within
     the Multi-Agent System of a single Autonomous Domain.  The Network AI
     Agent, acting as the principal coordinator, uses this interface to
     decompose high-level goals into specific tasks and assign them to
     specialized Task Agents (e.g., for configuration generation or fault
     diagnosis).  It facilitates communication for task assignment,
     progress monitoring, and result aggregation.  This coordination can
     be implemented using protocols like [A2A-T].

  5.3.4.  Network AI Agent to Network AI Agent Interface (Cross Autonomous
          Domain)

     This interface enables collaboration and information exchange between
     Network AI Agents residing in different Autonomous Domains.  It is
     essential for scenarios requiring end-to-end service assurance or
     coordinated optimization across multi-domain networks.  Through this
     interface, Network AI Agents can negotiate resource allocation, share
     summarized domain-specific insights (while preserving detail
     isolation for privacy and scalability), and coordinate actions to
     fulfill cross-domain objectives.  Standardized protocols like A2A-T
     [A2A-T], designed for agent interoperability in telecommunication
     area, are candidate technologies for implementing this cross-domain
     interface, ensuring secure and reliable interaction between
     autonomous systems from different administrative domains.

  5.3.5.  Network AI Agent/Task AI Agent to Agent Gateway Interface

     The interface between Multi-Agent System and Agent Gateway serves as
     the management bridge which encompasses a set of services designed to
     manage the lifecycle, security, and collaborative capabilities of the
     AI Agents.

     Registration handles Agent onboarding, lifecycle tracking (e.g.,
     heartbeat monitoring, status updates), and capability-based Agent
     discovery.  Interfaces like RESTful APIs with structural schema for
     AI Agents metadata description could be leveraged.  Protocols like
     A2A [A2A] Agent card mechanism may also be used to ensure
     interoperability among different Agent vendors.  It is also worth
     noting that message queue mechanisms such as Kafka could also be a
     candidate interface for asynchronous communications for agent
     registration and discovery.

     Authentication ensures trusted inter-Agent communication by verifying
     the identity of AI Agents and enforcing security policies throughout
     their interaction.  Protocols like Transport Layer Security (TLS)
     could be leveraged for in-transit data Protection.  While OAuth 2.0
     and OpenID Connect are increasingly used to authenticate AI Agents.

     The interface between AI Agent and Knowledge Base is specified in
     Section 5.3.7.

  5.3.6.  Network AI Agent to Network Digital Twin Interface

     The interface between Multi-Agent System and Network Digital Twin are
     the application-facing interface as defined in
     [I-D.irtf-nmrg-network-digital-twin-arch].  Furthermore, the Model
     Context Protocol (MCP) [MCP] can be leveraged to standardize this
     interaction, enabling the NDT to expose its simulation and analysis
     capabilities as a set of discoverable "tools" that the AI Agent can
     dynamically invoke.  This MCP-based approach facilitates seamless
     integration and richer contextual exchange between the Agent and the
     NDT.

  5.3.7.  Network AI Agent to Knowledge Base Interface

     Knowledge Base service provides contextual data and insights to
     enhance the decision-making accuracy of the Multi-Agent System.

     Interfaces such as Cypher or SPARQL with schema-defined data models
     (e.g., LPG or RDF for knowledge representation) allow efficient
     retrieval and updates.  Other high-throughput interfaces such as gRPC
     or RESTful API can be the candidate for synchronous semantic search
     queries.  For large-scale knowledge operations, asynchronous data
     message systems (e.g., Kafka) can also be employed for data ingestion
     and real-time knowledge synchronization across distributed Agents.

     Additionally, the Model Context Protocol (MCP) [MCP] could also serve
     as a standardized interface for AI Agents to dynamically access and
     utilize a wide range of tools and data sources provided by the
     Knowledge Base.  It enables the Knowledge Base to expose contextual
     information, expert rules, and external data as "tools" that Agents
     can invoke, significantly enhancing their reasoning and problem-
     solving capabilities.

  5.3.8.  Task AI Agent to Physical Network Interface

  5.3.8.1.  Data Collection

     Data Collection interface is responsible for gathering data from the
     physical network through various different tools and methods (e.g.,
     IPFIX [RFC7011], YANG-push [RFC8639],[RFC8641], BMP [RFC7854], and
     MCP [MCP]).  It collects various types of network data including
     configuration data, operational data, network topology, routing data,
     logs, and trace on management plane, control plane, and forwarding
     plane as needed.  The collected data is fed into the Network Digital
     Twin and Network AI Agent(s) to provide with up-to-date information
     about the current state of the physical network.

  5.3.8.2.  Configuration

     Once network decisions are made and confirmed, the Multi-Agent System
     performs specific actions to the physical network, e.g., modify
     specific configuration on network controllers or network devices
     through protocols like NETCONF [RFC6241] , RESTCONF [RFC8040], MCP
     [MCP].  It is the component that makes the planned control and
     management changes a reality in the real physical network.

  5.3.8.3.  Lightweight AI and Large AI Model Collaboration Interface

     Collaboration between small AI model and large AI model is also
     designed to be supported by this interface.

     In the past, we only support AI and machine learning technologies at
     the network level, e.g., we can use collected various different
     network data to provide network analysis and generate network
     insight.  With more intelligence introduced into the network element,
     more GPU/NPU resource can be allocated for AI inference, this make
     collaboration between large AI model and small AI model possible.

     Large AI models can provide basic logical reasoning and generalized
     analytical decision-making capabilities While specialized small AI
     models can provide efficient problem-solving capabilities in
     specialized areas.  The synergy between the two allows the AI agent
     to combine both multitasking generalization capabilities and domain
     expertise, thus minimizing the reliance on human intervention in the
     network management process.

     On one hand, we can use accumulated field engineering expertise to
     train large AI model into one foundation model for fault management
     AI agent, On the other hand, we can deploy small AI model, leverage
     hardware resource or chipset resource in the intelligent network
     element to collect more fine granularity data or provide local
     processing for Collected data and summary report generation, Trend
     prediction, etc.  When small AI model is outdated and unable to
     detect specific applications or security risk, these specific
     applications and security risk information can be collected by
     network analytics platform to retrain this small AI model and re-
     deploy it in the same network element when this small AI model has
     been trained to work correctly to detect applications or security
     risk.

     With collaboration between large AI model and small AI model, we can
     allow Network AI Agent within the Network controller interact with
     network element and has more quick response to network change.

     This collaboration, facilitated by APIs or agent communication
     protocols like A2A [A2A], combines the generalization power of large
     models with the efficiency and low-latency of specialized small
     models, leading to quicker and more context-aware responses to
     network change.

  5.3.9.  Feedback-driven Improvement Interface

     The architecture should incorporate mechanism for continuous
     improvement based on feedback.  This includes collecting data on AI
     decisions, network performance, and user feedback to identify areas
     for enhancement.  By analyzing the feedback, the system can adapt and
     optimize its operations over time, leading to better performance and
     more accurate decision-making.  For example, if a Network AI Agent
     fails to accurately identify the exact cause of a network incident,
     the relevant records can be submitted as negative samples to the LLM
     which provides inference services, this allows the LLM to be trained
     on these negative samples for optimization.

     This interface is implemented through a combination of system
     interfaces that collect, process, and apply feedback.  Operational
     feedback—including the outcomes of AI decisions, network state
     metrics—is collected as structured data via system logging streams
     (e.g., in JSON format) and message queues (e.g., Kafka).  This data
     is then consumed by analytics components and machine learning
     platforms through APIs (e.g., RESTful, gRPC) to refine AI models, for
     instance, by using failure records as negative samples for fine-
     tuning.  Subsequently, optimized models and updated knowledge are
     deployed back into the runtime system via model serving and
     configuration management interfaces, closing the improvement loop.

  5.3.10.  Network Element AI Agent and Network AI Agent Collaboration
           Interface

     Network devices collect information from multiple dimensions,
     including flow information, configuration, events, alarms, logs,
     dynamic topology and routes, and device status (including CPU,
     memory, and hardware health).  With large amount of data collected to
     the domain controller for analysis and processing, the data accuracy
     is very limited and therefore it is hard to determine the service
     impact within 1 minute.  In addition, it usually require multiple
     step interaction, complex task management with various different data
     types or data sources.

     To address those challenges, the network AI Agent can delegate
     massive data analysis and processing to distributed AI Agent in each
     network element, e.g., a) only allow distributed AI Agent export
     processed analytic data to help establish global view of network
     observability. b) or export key network fault information for Network
     AI Agent for further investigation the root cause of the problem.

     For the former case, routing protocol specific fault data such as BGP
     Status Changed, OSPF Neighbor state changes, IS-IS Adjacency Changed
     data or hardware related fault data such as Optical fail, Physical
     Port down can be collected and using pre-trained LLM model with
     expert experience to match fault pattern and invoke corresponding
     routing protocol troubleshooting MCP tools and finally root cause.
     In addition, it allows network maintenance engineer using nature
     language interface to look up troubleshooting information or it
     allows Network AI Agent or Task Agent at the network element using
     MCP interface to invoke tools from MCP server within the network
     element.

                                 +------------+     +------------+
                                 |  Network   |     |            |
                Human Operator   |  AI Agent  |     | Task Agent |
                     |           |            |     |            |
                     |           |+----------+|     |+----------+|
                     |           ||MCP Client||     ||MCP Client||
                     |           |+----------+|     |+----+-----+|
                   Intent        +------+-----+     +-----+------+
                     |                  |                 |
             +-------+------------------+-----------------+-------+
             |       |                  +------------+    |       |
             | +-----V-----------------+    +--------+----+------+|
             | |Protocol Fault Agent   |    |Protocol|Fault Agent||
             | |  +---------+ +------+ |    |  +-----V----V-+    ||
             | |  |  ONNOX  | | MCP  +-+----+-->    MCP     |    ||
             | |  |  Model  | |Client| |    |  |   Server   |    ||
             | |  +---------+ +------+ |    |  +------------+    ||
             | +-----------------------+    +--------------------+|
             |                                                    |
             +----------------------------------------------------+
                           Smart Network Element

            Figure 3: Network Element AI Agent and Network AI Agent
                          Collaboration Usage Example

  6.  AI Driven Network Operations: Relationship Between Characteristics
      and Functional Components

     The architecture in Figure 2 provides a concrete implementation
     framework to realize the six key characteristics of AI-driven network
     operations described in Section 4.  Each characteristic is directly
     supported by specific functional components within the Autonomous
     Domain.  The following clarifies how the architecture operationalizes
     these characteristics:

     *  Intent:  The Network Applications Layer conveys a high-level user
           intent via northbound interfaces.  The Network AI Agent
           interprets this intent and translates it into actionable
           network operation tasks to each task Agent.

     *  Knowledge:  The Knowledge Base in Agent Gateway serves as the
           central repository for domain-specific knowledge, expert rules,
           and historical data.  It provides the necessary context and
           long/short memory to support accurate decision-making by task
           Agents.

     *  Analysis:  The AI Agent in Multi-Agent System performs intelligent
           analysis using data and tools.  It leverages the Network
           Digital Twin to simulate and validate scenarios, enabling data-
           driven insights and gap analysis between intent and current
           network state.

     *  Decision:  The AI Agent in Multi-Agent System makes informed
           decisions based on its analysis results.  It utilizes the
           Network Digital Twin for risk-free validation before finalizing
           decisions.  The decision may be sent to human operators for
           confirmation before actions are taken.

     *  Awareness:  The AI Agent in Multi-Agent System gathers data from
           the Physical Network, it may also fetch data from the Network
           Digital Twin which maintains a dynamic, virtual representation
           of Physical Network.  Together, they provide comprehensive
           network visibility and context-aware awareness.

     *  Execution: ：The AI Agent in Multi-Agent System implements
        validated decisions by applying configurations or control actions
        to the Physical Network via southbound interfaces such as NETCONF,
        RESTCONF, or Model Context Protocol [MCP].

  7.  AI Agent Registration and Team formation

                                                       +----------------+
                                                       |Agent Gateway   |
                      +-----------+                    | +------------+ |
                      |  Network  |      Register      | |            | |
                      | AI Agent  +--------------------+->            | |
                      +-----------+                    | |Registration| |
            |---------------+----------------+---------+->            | |
           Register       Register         Register    | |  Center    | |
            |               |                |         | +------------+ |
     +------+----+   +------+-----+    +-----+----+    |                |
     |   Fault   |   |Optimization|    | Change   |    |                |
     | Task Agent|   |Task Agent  |    |Task Agent| ...|                |
     +-----------+   +------------+    +----------+    +----------------+


                      +-----------+
                      |  Incident |
                      |   Center  |                    +----------------+
                      +-----+-----+                    |Agent Gateway   |
                       Incident Notif                  | +------------+ |
                            |        Registry based    | |   Agent    | |
             Intent   +-----V-----+    Discovery       | |            | |
            Objective |  Network  +--------------------+->Registration| |
       Human ---------> AI Agent  |                    | |            | |
      Operator        |           |                    | |  Center    | |
                      +-----+-----+                    | +------------+ |
               Policy Definition(Obj+Incident+Action)  |                |
                      Task Planning                    |                |
                     Agent Team Formation              |                |
            +---------------+----------------+         +----------------+
            |               |                |
      +-----+-----+    +----+------+    +----+------+
      |           |    |           |    |           |
      |Task Agent1|    |Task Agent1|    |Task Agent1|
      +-----------+    +-----------+    +-----------+

        Figure 4: AI Agent Registration and Team formation Usage Example

     The Agent gateway at the network level provides agent registration
     for both embedded AI agent in each network element and network AI
     agent and associated task agents.  The following steps are performed
     to provide Event driven AI Agent Team formation within the Agentic AI
     network management architecture:

     Step 1:  Human Operator pre-provision user intent which comprises
        objective, incident list and corresponding action list.

     Step 2:  Network AI Agent receieves user intent and generate
        corresponding policies which comprise objective, incident list and
        corresponding action list.  In addition, Network AI Agent
        subscribe corresponding incidents from incident center.

     Step3:  Network AI agent generate task planning based on objective
        and then discover matched task agent lists based on planned task
        from registration center within the agent gateway.

     Step4:  Upon receiving incident from the incident center, network AI
        agent assign the tasks to task agents corresponding to specific
        incident received.

     Step 5:  Network AI Agent distribute task to corresponding task
        agents and complete task agent team formation.

  8.  Agent to Agent Communication Security

        Artifacts Delivery
      +-----------+
      |           |                                    +----------------+
      |           |                                     Agent Gateway   |
      |        +--V--------+  Agent Identity Discovery | +------------+ |
      |        |    Task   <---------------------------+->   Agent    | |
      |        |  AI Agent <---------------------+     | |            | |
      |        +-^------^--+  Authentication     |  +--+->Registration| |
      |          |      |       Handshake        |  |  | |            | |
      |   Secure |  Stateful                     |  |  | |  Center    | |
      |   Task   |   Monitoring                  |  |  | +------------+ |
      Negotiation|      |                        |  |  |                |
      |          |      |     Agent Identity     |  |  | +-------------+|
      |        +-V------V--+     Discoverey      +--+--+->   Agent     ||
      |        |    Task   +------------------------+  | |Authorization||
      +-------->  AI Agent <---------------------------+->   Server    ||
               +-----------+  Authentication           | |             ||
                               Handshake               | +-------------+|
                                                       +----------------+

         Figure 5: Agent to Agent Communication Security Usage Example

     The following steps are performed to provide Agent to Agent
     Communication Security within the Agentic AI network management
     architecture:

     Step 1.  Discovery via Agent Card:  The workflow begins when a client
        agent requests the Agent Card from the remote agent's /.well-
        known/agent.json endpoint.  This JSON file acts as a secure
        manifest, declaring the agent’s identity, capabilities, and
        required security schemes.

     Step 2.  Authentication Handshake:  Before any task is sent, the
        client must fulfill the authentication requirements listed in the
        Agent Card.  This typically involves an OAuth 2.0 flow where the
        client obtains a JSON Web Token (JWT) to prove its identity and
        permissions.

     Step 3.  Secure Task Initiation: :Communication is established over
     HTTPS/TLS.  The client sends a tasks/send request using JSON-RPC 2.0.
     The server validates the token and authorizes the specific task based
     on the client's role.

     Step 4.  Stateful Monitoring & Feedback: :The task moves through a
     strictly defined lifecycle (submitted → working → completed).
     Security is maintained throughout as updates are streamed via Server-
     Sent Events (SSE) or webhooks, each tied to the unique, authorized
     Task ID.

     Step 5.  Artifact Delivery:  Final results (Artifacts) are delivered
        only after the task reaches a completed state.  These are
        structured objects (text, files, or data) returned to the verified
        requester, ensuring data integrity and preventing unauthorized
        access to output.

  9.  AI Driven Network Operations: A collection of Use Cases

     Network AI Agent could help in the following phases which are usually
     mentioned in network management:

     *  Network Planning and Design: includes the understanding of user
        intent, generation of solutions, and simulation for decision-
        making.

     *  Service Deployment: includes the construction of the physical
        network, as well as intent understanding, pre-deployment
        simulation, automated configuration, post-deployment validation,
        and other capabilities to enhance the efficiency and accuracy of
        network configuration for service deployment.

     *  Network Monitoring and Troubleshooting: includes intent
        monitoring, issues identification, solution generation, evaluation
        and decision-making, solution implementation, and service
        validation.

     *  Network Change and Optimization: involves the design, evaluation,
        decision-making, implementation, and validation of network
        configuration changes or optimizations to improve network
        operation efficiency.

     In all phases and use cases, after the Agent performs specific
     action, it always continuously monitors the network by data
     collection.  Based on the result of network running analysis and user
     explicit feedback, it may adjust and optimize the management strategy
     if necessary.

  9.1.  Multi-Agent Collaboration on Network Configuration Change

     Network configuration changes are needed in scenarios such as
     optimizing network or service performance, provisioning new network
     services, or resolving network incidents/faults.

                         +------------+
           Network       |  Service   |
           Operator ----->  AI Agent  |
                         |            |
                         +-----+------+
                               |Configuration               +---------+
                               |Change Intent               |         |
                       +-------V---------+                  |         |
                       |Network AI Agent |                  |         |
                       |     Goal        |                  |         |
               +-------| Task-1,Task-2   +------------------>         |
               |       |   ... Task-n    +-------+          | Network |
               |       +-------+---------+       |          | Digital |
               |               |                 |          |  Twin   |
               |               |                 |          |  Task   |
         +-----V------+  +-----V-------+  +------V----+     |  Agent  |
         |   Config   |  |  Config     |  |  Config   <----->         |
         | Generation |  | Distribution|  |Validation |     |         |
         | Task Agent |  |  Task Agent |  | Task Agent|     |         |
         +------------+  +-------------+  +-----^-----+     +---------+
                                                |
                                         +------V------+
                                         |  Resource   |
                                         | Allocation  |
                                         | Task Agent  |
                                         +-------------+

       Figure 6: Intent Based Network Configuration Change Usage Example

     Network configuration change leveraging Network AI Agent and Network
     Digital Twin may experience the following typical steps:

     Step 1:  The network operator inputs the intent of network
        configuration change into the Network AI Agent using natural
        language.  The network operator may simply explain the objectives
        and requirements of the changes.

     Step 2:  Network AI Agent first verifies the identity of the user
        requesting the change and checks the user's permissions to make
        certain types of network changes against predefined rules or
        policies.  It then understands and parses the initial intent of
        the request, by leveraging the powerful knowledge and reasoning
        capabilities of LLM and decompose the tasks into configuration
        generation task, configuration distribution task, configuration
        validation task and assign to corresponding task agents.
        Configuration generation Task Agent first generates initial
        suggestions for specific network configuration update, which may
        include multiple possible network configuration change plans if
        possible.

     Step 3:  Network AI Agent further communicates with the Configuration
        Validation task agent and Network Digital Twin task agent to
        validate the suggested configuration change, including the syntax
        and semantics of the configuration, verification of effected
        application and resources.  The network digital Twin task agent
        may generate a report indicating the validation result, and
        suggested configuration fix when the validation fails after
        network simulation leveraging the current physical network
        operational state.

     Step 4:  Network AI Agent may generate a configuration change plan
        and submit to the network operator for approval.  Based on the
        feedback from the operator, Network AI Agent then further decides
        whether to optimize the change plan or deliver the plan to the
        Configuration Distribution task agent to conduct the physical
        network configuration change.  The configuration distribution task
        agent may further communicate with resource allocation task agent
        to obtain network resource (e.g.,vlan, IP subnet) allocated by
        resource allocation task agent.

  9.2.  Multi-Agent Collaboration on Network Troubleshooting

                                    |
                            Human   |Network Troubeshooting
                           Operator |Intent
                                    |                    +---------+
                           +--------V--------+           | Network |
                           | Network AI Agent|           | Digital |
                           |     Goal        |           |  Twin   |
                           | Task-1,Task-2   +----------->  Task   |
                           | ....Task-n      |           |  Agent  |
                           +--------+--------+           +---------+
                                    |
              |------------------+--+-----------+------------+
          +---+----------+ +-----+-----+  +-----+----+ +-----+------+
          |    Fault     | |   Fault   |  |   Fault  | |   Fault    |
          |Identification| | Diagnosis |  |  Repair  | | Prediction |
          | Task Agent   | |Task Agent |  |Task Agent| | Task Agent |
          +--------------+ +-----------+  +----------+ +------------+

          Figure 7: Intent based Network Troubleshooting Usage Example

     The network operator inputs the intent of network configuration
     change into the Network AI Agent using natural language.  Network AI
     Agent could plan and decompose network troubleshooting tasks and
     coordinate with fault identification task agent, fault diagnosis task
     agent, fault repair task agent and fault prediction task agent to
     assist in network troubleshooting in the following significant
     aspects:

     *  Fault Identification:  Network AI Agent coordinates with fault
           identification task agent continuously monitors and aggregates
           data from various sources, the comprehensive data collection
           provides a holistic view of the network operational state.  By
           analyzing the real-time data, fault identification task Agent
           could detect network anomalies swiftly, which enables the
           prompt identification of potential issues before they escalate
           into major faults, minimizing downtime or service disruptions.
           In some cases, the Lightweight AI located in the Network
           Element may handle some simple fault identification tasks
           (e.g., optical module fault automatic identification) to
           enhance the awareness, while the fault identification task
           agent and LLM could leverage their powerful processing
           capabilities to analyze the time-domain data collected from the
           optical module.

     *  Fault Diagnosis:  Once a fault is identified, Network AI Agent
           coordinate with fault diagnosis task agent to delve into
           diagnosing the exact cause, fault diagnosis task agent may also
           invoke some existing operations such as "incident-diagnose" RPC
           defined in [I-D.ietf-nmop-network-incident-yang].  By
           correlating symptoms and/or applying AI models trained on
           historical data, fault diagnosis task agent can narrow down the
           potential causes and pinpoint the exact cause, which
           accelerates the diagnosis process and reduces the time needed
           to address the issue.

     *  Fault Repair:  After diagnosing the fault, Network AI Agent can
           coordinate with fault repair task agent to generate targeted
           repair solutions.  These solutions range from specific
           configuration adjustments to more complex fixes (e.g., hardware
           replacement).  Fault Repair task Agent would also communicate
           with the Network Digital Twin task agent to simulate the
           proposed repair solutions and get feedback from the Network
           Digital Twin task agent.  In advanced setups, fault repair task
           agent may automatically execute these repairs, ensuring quick
           restoration of normal operations and enhancing the overall
           reliability and efficiency of network management.  But the
           fault repair task agent may also first present the fault
           details and repair advice to the network operator for review,
           and proceed to carry out the repair task once it is confirmed.

     *  Fault Prediction  As an advanced enhancement of fault management
           capabilities, fault prediction aims to reduce network risks
           through proactive management that prevents problems before they
           occur.  Before a fault actually occurs, the fault prediction
           task agent can coordinate with network digital twin task agent
           to construct a dynamic simulation model by collecting real-time
           multi-dimensional operational state data, including network
           topology, traffic load, and device performance indicators.
           Based on the network data, the fault predication task agent
           uses large models and machine learning algorithms (such as
           time-series prediction models and anomaly detection models) to
           reason and analyze potential faults—for example, predicting the
           risk of physical link interruption based on optical cable
           signal attenuation data.  Furthermore, the fault prediction
           task Agent generates recommended operations to avoid faults and
           validates them through simulation in the network digital twin
           task agent, thereby achieving predictive maintenance of the
           network.

  9.3.  Multi-Agent Collaboration on Network Optimization

                                  |
                                  |
                          Human   |Network Optimization
                         Operator |Intent
                                  |                    +---------+
                         +--------V--------+           | Network |
                         | Network AI Agent|           | Digital |
                         |     Goal        |           |  Twin   |
                         | Task-1,Task-2   +----------->  Task   |
                         | ....Task-n      |           |  Agent  |
                         +--------+--------+           +---------+
                                  |
                       +----------+----------------+
                       |                           |
               +-------+------+            +-------+-------+
               | Optimization |            |  Optimization |
               |  Generation  |            |  Distribution |
               | Task Agent   |            | Task Agent    |
               +--------------+            +---------------+

           Figure 8: Intent based Network Optimization Usage Example

     Network optimization is often introduced due to the Network AI
     Agent's awareness of some potential network faults or anomalies
     through continuously monitoring of network operational state, e.g.,
     AI models may predicts network congestion by analyzing historical and
     real-time network traffic data.  It may also be triggered by the
     network operator actively inputting the network optimization intent.

     Based on the analysis of network data and user's intent (if any),
     Network AI Agent collaborate with Optimization Solution Generation
     Task Agent to propose network optimization strategies.  For instance,
     once the network congestion sometime in the future is predicted, it
     may proactively optimize the network configuration, or suggest
     scaling up to meet specific demands.

     Before the network optimization is conducted, Network AI Agent
     coordinates with the network digital twin task agent to implement and
     evaluate the optimization solution using the Network Digital Twin
     platform.  This may need repeated trials and validations based on
     specific evaluation criteria, before the optimal strategy could be
     selected.  Network AI Agent may also first present the suggested
     network optimization solution to the network operator for review, and
     apply it to the physical network through optimization solution
     distribution task agent after obtaining approval from the network
     operator.

  9.4.  Network level Energy Efficiency Management in the IP+Optical
        network

                              +-----------------+
                              |  Multi-Domain   |
                              |    AI Agent     |
                              |  GREEN Goal     |
                              | Task-1,Task-2   |
                              | ....Task-n      |
                              +--------+--------+
                                       |
                         +-------------+--------------+
                         |                            |
                   +-----+------+              +------+-----+
                   |    IP      |              |   Optical  |
                   |   Domain   |              |   Domain   |
                   |   Network  |              |   Network  |
                   |   AI Agent |              |   AI Agent |
                   +------------+              +------------+

       Figure 9: Intent based Network level Energy Efficiency Management
                                 Usage Example

     Network level Energy Efficiency refer to a set of processes used to
     discover a inventory of capabilities, use specific metrics to monitor
     and assess energy consumption of the entire IP+Optical network ,
     operate, and control the use of available energy in an optimized
     manner while achieving the network’s functional and performance
     requirements by improving overall network utilization.

     Multi-Domain AI Agent can work together with network AI Agent in each
     autonomous domain to allow network operators not only see real time
     energy consumption in the network devices of large scale network
     through interaction with the GREEN Network AI Agent, but also allow
     them see

     o which network devices enable energy saving, which devices not,
     which are legacy ones,

     o The total energy consumption changing trend over the time of the
     day, for all network devices,

     o Energy efficiency changing trend over the time of the day for the
     whole network.

     On the other hand, With the end to end observability to energy
     consumption statistics data and energy efficiency statistics data,
     the Network AI Agent in each autonomous domain can collaborate with
     network digital twin to know which part of the network need to be
     adjusted or optimized based on network status change.

  9.5.  Network Security Drills (Human in the Loop)

                                   +----------------+   Human
                                   | Agent Gateway  |  Operator
              +-----------------+  |                | /---------\
              | Network AI Agent|  |+--------------+| | Analyze |
              |     Goal        |  ||              || | Define  |
              | Task-1,Task-2   <-->|Observability |<-> Inject  |
              | ....Task-n      |  ||              || \---------/
              +-------+---------+  |+--------------+|
                      |            |                |
                      |            +---------^------+
                      |                      |
              +-------V------ ---------------V----------------+
              | Dynamic Attack and Defense Verification System|
              |        Based on Network Digital Twin          |
              |      +---------+      +---------+             |
              |      | Dynamic |      | Dynamic |             |
              |      | Security|      |Security |             |
              |      | Attack  |      |Defense  |             |
              |      |  Task   |      |  Task   |             |
              |      |  Agent  |      |  Agent  |             |
              |      +---------+      +---------+             |
              +--------------------^--------------------------+
                                   |Data Collection
              +--------------------+--------------------------+
              |            Network Infrastructure             |
              +-----------------------------------------------+

          Figure 10: Intent based Network Security Drill Usage Example

     The human operator can work together with the Network AI Agent to
     conduct Network security Drill.  The human operator can instruct the
     Network AI Agent with specific injection policy to work with network
     digital twin help construct a dynamic attack-defense verification
     system in network security drills through NDT and AI reasoning
     capabilities.  The dynamic attack-defense verification system
     comprise dynamic security attack task agent and dynamic security
     defense task agent which are responsible security risk attack task
     and security risk defense task respectively assigned by the network
     AI agent.  The dynamic security attack task agent uses generative AI
     to automatically generate diversified attack paths, models network
     topologies with graph neural networks, covers attack stages such as
     reconnaissance and penetration, and dynamically adjusts strategies
     via reinforcement learning to simulate the adaptive characteristics
     of network attacks.  The virtual range built based on the NDT can 1:1
     map the production environment, supporting simulations of composite
     scenarios like ransomware chain attacks and supply chain attacks —
     such as simulating the entire process of Contivirus laterally
     penetrating to domain controllers through weak passwords.

     During drills, Human operator can instruct the Network AI Agent to
     work with the dynamic security defense task agent to automatically
     deploy virtual environments with vulnerabilities, collect defense
     response data in real time through NDT, and generate attack path
     heatmaps and repair suggestions.  This capability can further verify
     emergency response processes, inject real-time threat intelligence to
     dynamically update drill scenarios, and simulate end-to-end automated
     deployment, vulnerability injection, and real-time analysis of
     security drills, enhancing the proactive verification ability of
     defense systems against real-world threats.

  10.  Challenges of Integrating Network Digital Twin and Agentic AI into
       Network Management

     In addition to the research challenges in coupling AI and network
     management specified in [I-D.irtf-nmrg-ai-challenges], this document
     also identifies some challenges that need to be considered when
     integrating agentic AI together with network digital twin for network
     operations.

  10.1.  Create domain specific language for agents and models

     Feeding network data into machine-readable knowledge for autonomous
     AI agents involves transforming raw telemetry and metadata into a
     structured semantic format.  This process typically uses the Model
     Context Protocol (MCP) and Domain Specific Languages (DSLs) to bridge
     the gap between low-level network signals and high-level AI
     reasoning.

     o Semantic & Contextual

     Network data in the wire format is often low-fidelity and lacks the
     context for AI to "reason" about intent or impact.  AI agents may
     struggle to understand rigid structure for the interaction,e.g., a
     numerical value represents "Frame Delay" without explicit ontological
     mapping.  Multi-task collaboration and Agent operation involve some
     ambiguity and uncertainty.  The natural language interactions should
     be supported for understanding and handling uncertain or ambiguous
     tasks.  With the presence of existing standard of natural language
     interaction, the task of defining common functions for any agent to
     agent communications becomes that of defining the semantics of the
     information that should be transferred, as opposed to defining a
     rigid structure for the interaction.

     o Data Quality & Fragmentation

     Information is often fragmented across multiple vendor tools and
     legacy systems, preventing a unified knowledge model.  Processing
     high-velocity data and non-standardized formats makes it difficult
     for AI to generalize across different device types or data sources.

     o Technical & Computational

     Architectural Limits: Standard hardware often lacks the capacity for
     real-time AI operations at the data-plane level.

     Token/Memory Limits: Large AI models have finite "context windows",
     which restricts their ability to process long or complex network
     sequences.

     o Operational & Trust

     "Black Box" Problem: AI decisions can be opaque, making it hard for
     human operators to audit or trust automated actions.

     Skill Gap: There is a significant shortage of professionals with the
     cross-disciplinary expertise needed for both networking and AI
     development.

  10.2.  Trust and Security

     Multi-Agent Collaborations and interactions can be break down into 4
     typical scenarios:

     o Human operator-> AI Agent-> APIs/Tools/APIs/LLMs

     In a single-agent scenario, Human operators access services through
     the network management AI agent.  The network management AI agent has
     multiple functions (fault and optimization), and authentication is
     required to prevent users from Performing unauthorized actions by
     exploiting privilege vulnerabilities,e.g., accessing the optimization
     function interface when they only have fault agent permissions.

     o AI Agent -> API Services

     In a single-agent scenario, the network management AI agent triggers
     tasks automatically based on trace and log information.  In some
     cases, the logging or decision-making process cannot be traced.

     o Human operator-> AI Agent -> multiple AI Agent

     Multiple agents may call each other.  For example, if a faulty agent
     A calls an optimization agent B, authentication is required to
     prevent Manipulating communication channels of agents to influence
     decision-making processes.

     o External AI Agent ->AI Agent-> APIs/Tools/APIs/LLMs

     External AI agents can directly access the network management AI
     Agent by simulating human operation through interface protocols.  For
     example, a customer AI agent can access the Network AI Agent through
     a northbound interface protocol such as A2A, MCP.  In some case,
     there might have target flaws in protocols like MCP or A2A;
     e.g.,consent bypass, context hijacking, etc.

     Ensuring robust security throughout the entire AI-based network
     management architecture is essential to prevent unauthorized access
     and maintain the security of the network infrastructure.  The
     security risk can be break down into the following cases:

     o External system interacts with AI agent

     Human Operators or external systems bypass their privileges to
     operate the Network management AI agent

     *  Human operators operate through a network management AI agent, but
        the service scope that the AI agent can handle may exceed the
        user's authorized privileges, leading to unauthorized access.

     *  Human operators manipulate business operations using agent
        delegation and authorization.

     *  Human operators Coerce intelligent agents to manipulate users into
        performing covert operations.

     o AI Agent Interact with Tools/APIs/LLMs

     *  Interact with Tools/APIs/LLMs with Privilege Escalation

        Since network management AI agents rely on LLM for inference when
        accessing APIs and tools, there is a possibility of malicious
        injection scenarios where the APIs accessed by the agent exceed
        the expected scope,e.g.,Using AI to generate execution
        environments and inject malicious code.

     *  Interact with Tools/APIs/LLMs without audit

        When an agent interacts with an API or tool, the logs are
        currently recorded as system logs, which cannot distinguish
        between different agents, the logging or decision-making process
        for specific agent cannot be traced and pose a risk of
        repudiation.

     o Multiple Agent Collaboration and Communication

     *  Multi-Agent Communication with Privilege Escalation

        When agents communicate with each other via intent communication
        and understanding, there is a cascading permission amplification
        problem,e.g.,AI-generated false information disrupts the reasoning
        process , leading to Privilege Escalation.

     *  Interaction with internal AI Agent

        As a microservice, a network management AI agent can be accessed
        by other services or AI agents,e.g., Performing unauthorized
        operations by exploiting authentication vulnerabilities,which
        poses a risk of Privilege Escalation.

  10.3.  Protocols between Agent and Agent/Human operator/Tools

  10.3.1.  High Risk Operations

     "network change" in the network management field refers to the
     modification, adjustment, or configuration of physical or logical
     resources in the existing network.  Because these operations directly
     affect the continuity and stability of existing network services,
     even minor unauthorized access or errors can lead to large-scale
     network outages.  In case of high risk operation, the following
     measures should be taken into account.

     o Regardless of whether the initiator of the operation is a human or
     an agent, each network change request must be re-authenticated.

     o For operations involving "bulk deletion" or "core route changes",
     the system must require approval from a second high-privilege account
     before issuing the command or enforcing the policy.

     o High-risk configurations should be tested on a very small scale
     first.  The system should automatically monitor the indicators, and
     if any abnormalities are detected, the configuration should be
     automatically rolled back within milliseconds.

  10.3.2.  The Timeliness Requirements of Collaboration

     For real-time network operation and maintenance scenarios with high
     real-time requirements, such as scheduling strategy optimization and
     critical fault repair, the rapid generation of network optimization
     decisions is crucial.  However AI Agents based on large models adopt
     a "Token-based" generation and reasoning approach, which is limited
     by computing power and algorithms, resulting in generally slow
     reasoning speeds.  In addition, the simulation and verification
     process of Network Digital Twin (NDT) further increases decision
     latency, which leads to long end-to-end decision-making time in
     complex scenarios and is difficult to meet the real-time requirements
     of services.

     Also tasks such as fault diagnosis, complaint handling, and user
     experience improvement often have strict time constraints.  For
     example, if a fault is not resolved within a set time, it can trigger
     an escalation of the complaint, requiring efficient collaboration
     among multiple agents.  In addition, In a network management
     environment, you might need agents to subscribe to real-time network
     alarms or telemetry events.  However Google-initiated A2A protocol
     primarily follows a task-oriented "request-response" model and
     doesn't support a native pub/sub or event-driven architecture.

     To improve decision efficiency, continuous efforts are needed in
     lightweight NDT modeling algorithms, optimizing large model reasoning
     frameworks (such as quantization technology and parallel computing),
     and deploying high-performance AI acceleration hardware.

  10.3.3.  Collaboration Reliability

     Fault diagnosis and complaint handling in the network management
     field are complex tasks, typically involving 10 to 20+ fields for one
     single message exchange between two AI Agents and requiring a high
     level of expertise.  In addition, Reliable task collaboration is
     incomplete and not sufficient for network management field, e.g.,
     Google-initiated A2A protocol doesn't defined handling strategies for
     task rejection, missing information during task collaboration, and
     failure to achieve task objectives.

     also In network management area, data sources can be diverse and
     heterogeneous, leading to potential issues such as data
     inconsistencies, missing, or outdated data.  Poor-quality data may
     result in inaccurate AI predictions and decisions.  For example, if
     incorrect or outdated network configuration data is provided, the
     model may provide incorrect repair advice when diagnosing network
     incidents or faults, it may suggest checking an non-existing
     interface.  Ensuring that data is properly cleaned, validated, and
     maintained is a significant challenge in providing reliable inputs
     for AI-driven network management.

  10.4.  Benchmarking

  10.4.1.  Single Agent Benchmarking

     The core of Single Agents assessment lies in its "omnipotence" and
     the quality of its direct interaction with the environment.

     o Task complexity bottleneck

     When dealing with long-term, multi-step tasks, single agents are
     prone to hallucination accumulation and reasoning chain breaks.
     Benchmark tests need to evaluate their persistent logic capabilities
     under context window constraints.

     o Command compliance and control

     The challenge lies in whether the model can strictly follow complex
     system prompts, especially when there are many tool options, which
     can easily lead to tool invocation errors or the omission of some
     instructions.

     o Generalization and memory

     To evaluate how monolithic models can efficiently manage long-term
     memory to handle new tasks without relying on external collaborative
     support.

  10.4.2.  Multi-Agent Benchmarking

     The focus of collaborative assessment has shifted from "individual
     capabilities" to "system dynamics":

     o Coordination and communication overhead:

     Multi-agent systems (MAS) involve complex task decomposition and
     allocation (global planning).  Benchmarking needs to measure the
     communication efficiency between agents, alignment consistency, and
     the high latency and cost caused by multi-turn interactions.

     o Error tracing and attribution:

     When the final task fails, it is extremely challenging to accurately
     pinpoint which "role" went wrong or in which round of collaboration
     there was a deviation (failure attribution) due to the presence of
     multiple participants.

     o Swarm intelligence and social emergence:

     It is necessary to assess the dynamics of competition and cooperation
     among intelligent agents, including the existence of systemic risks
     such as information silos, resource waste, or vicious cycles.

  11.  Security Considerations

     The security consideration from
     [I-D.irtf-nmrg-network-digital-twin-arch] apply here.  In addition,
     the following architectural risks need to be considered:

     o Memory Poisoning：If the AI/ML models used by the network AI Agent
     or Network digital twin are compromised or poisoned with malicious/
     fake data,they could begin making incorrect or malicious decisions.
     Robust checks and validation are necessary to ensure the integrity of
     these models.  Session isolation or memory access authentication is
     also required to mitigate such risk.

     o Misuse of Tools： When network AI Agent interacts with tools,
     Deceptive prompts or commands can be introduced.  Tool access
     verification, tool monitoring, log tracking of AI tool usage are
     required to mitigate such risk.

     o Privilege Compromise：When human operators interact with Network AI
     Agent or Network AI Agent interact with tools/APIs/LLM, unauthorized
     actions might be performed by exploiting privilege vulnerabilities.
     Fine-grained permission control, dynamic access verification, and
     role change monitoring are required to mitigate such risk.

     o Resource Overload：When Network AI Agent interact with tools/APIs/
     LLMs, system failures might be caused by exploiting resource-
     intensive features.  Deployment of resource management controls to
     limit high-frequency task requests from agents is required to
     mitigate such risk.

     o Cascading Hallucinations：In case of multi-agent collaboration or
     communication, AI-generated false information might disrupt the
     reasoning process.Output verification, secondary verification of AI-
     generated knowledge are required to mitigate such risk.

     o Intent Breaking &Goal Manipulation：When external AI Agent or human
     operators interact with the network AI Agent, reasoning through agent
     planning capabilities might be manipulated.  Planning verification,
     managing reflection processes, goal consistency protection are
     required to mitigate such risk.

     o Misaligned & Deceptive Behaviors：When Network AI Agent interact
     with tools/APIs/LLMs, harmful operations might be performed by
     exploiting reasoning vulnerabilities.  Manual confirmation of high-
     risk operations, logging, monitoring, and deception detection are
     required to mitigate such risk.

     o Repudiation & Untraceability：In case of multi-agent collaboration
     or communication, the logging or decision-making process might not be
     traced.  Logging & cryptographic signature, cryptographic
     verification are required to mitigate such risk.

     o Identity Spoofing & Impersonation：When Human operators interact
     with the network AI Agent or in case of multi-agent collaboration or
     communication,unauthorized operations might be performed by
     exploiting authentication vulnerabilities.  Comprehensive identity
     verification, trust boundary control, and continuous monitoring are
     required to mitigate such risk.

     o Overwhelming HITL(Human In The Loop)：In case of multi-agent
     collaboration or communication,fatigue auditors attack might take
     place.  Developing advanced human-machine interaction frameworks and
     adaptive trust mechanisms are required to mitigate such risk.

     o Unexpected RCE & Code Attacks：When the network AI Agent interacts
     with tools/APIs/LLMs, Using AI to generate execution environments and
     inject malicious code might take place.  Restrict AI code generation
     permissions, sandbox isolation, and manual review of generated code
     are required to mitigate such risk.

     o Agent Communication Poisoning：In case of multi-agent collaboration
     or communication, communication channels of agents might be
     manipulated to influence decision-making processes.  Message
     authentication, communication verification, implementing multi-agent
     authentication mechanisms.

     o Rogue Agents in MAS：In case of multi-agent collaboration, there
     might be malicious or compromised agents.  Restricting the autonomy
     of agents and conducting regular AI testing are required to mitigate
     such risk.

     o Humans Attacks on MAS：In case of multi-agent collaboration,
     business operations might be manipulated using agent delegation and
     authorization.  Restricting the delegation mechanism, implementing AI
     agent identity authentication, and isolate tasks in segments are
     required to mitigate such risk.

     o Human Manipulation：When Human operators interact with the network
     AI Agent, AI agents might be coerced to manipulate users into
     performing covert operations.  Safety guardrails, content moderation,
     output content detection are required to mitigate such risk.

     o Insecure Inter-Agent Protocol Abuse：In case of multi-agent
     collaboration, there might be target flaws in protocols like MCP or
     A2A; e.g.,consent bypass, context hijacking, etc.  Strong
     authentication,data validation, restricting delegation to scoped
     function,logging agent and tool invocations and encrypting
     communications are required to mitigate such risk.

     o Supply Chain Compromise：In case of multi-agent collaboration,
     Vulnerable, malicious, outdated, harmful components might be included
     into the agent.  Digital signatures of SBOMs (AI_, Agent_),applying
     version control, chaining authentication, environment isolation are
     required to mitigate such risk.

     o Lifecycle security: The entire management lifecycle of the network
     AI agents and the network digital twin—from initial deployment and
     configuration to updates and decommissioning—must be secured against
     unauthorized access and manipulation.

  12.  IANA Considerations

     This document has no requests to IANA.

  13.  Conclusion

     The following items were felt to be good starting points for IETF
     work:

     *  Nature Language Interaction protocol to ensure both The accuracy
        and efficiency of structured data for deterministic tasks and
        natural language interactions for understanding and handling
        uncertain or ambiguous tasks.

     *  Translate Service Level YANG Data model and Network Level YANG
        Data model into DSL payloads and APIs which can be consumed by
        Agents and Models.

     *  Human and Agent Interaction to support explainable, observability
        and controllable capabilities.

     *  Define semantic information transfer or agent prompt language
        template for Agent to Agent Communication.

     *  Agent to Agent Protocol extensions for IP Network Agent and
        Network Element Agent Collaboration.

  14.  References

  14.1.  Normative References

     [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/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

  14.2.  Informative References

     [A2A]      "Agent2Agent (A2A) protocol", April 2025, <https://google-
                a2a.github.io/A2A/#/documentation?id=agent2agent-protocol-
                a2a>.

     [A2A-T]    "Agent to Agent Protocol for Telecoms (A2A-T)", 2025,
                <https://www.tmforum.org/resources/introductory-guide/
                ig1453-agent-to-agent-protocol-for-telecoms-a2a-
                t-v1-0-0/>.

     [Agent-skills]
                "Agent Skills", 2025, <https://agentskills.io/home>.

     [Google-Agents-Whitepaper]
                "Agents", 2024,
                <https://www.kaggle.com/whitepaper-agents>.

     [I-D.hong-nmrg-agenticai-ps]
                Hong, Y., Youn, J., Wu, Q., and B. Claise, "Motivations
                and Problem Statement of Agentic AI for network
                management", Work in Progress, Internet-Draft, draft-hong-
                nmrg-agenticai-ps-00, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-hong-nmrg-
                agenticai-ps-00>.

     [I-D.ietf-nmop-network-incident-yang]
                Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng,
                "A YANG Data Model for Network Incident Management", Work
                in Progress, Internet-Draft, draft-ietf-nmop-network-
                incident-yang-08, 13 February 2026,
                <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
                network-incident-yang-08>.

     [I-D.ietf-nmop-terminology]
                Davis, N., Farrel, A., Graf, T., Wu, Q., and C. Yu, "Some
                Key Terms for Network Fault and Problem Management", Work
                in Progress, Internet-Draft, draft-ietf-nmop-terminology-
                23, 18 August 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
                terminology-23>.

     [I-D.irtf-nmrg-ai-challenges]
                François, J., Clemm, A., Papadimitriou, D., Fernandes, S.,
                and S. Schneider, "Research Challenges in Coupling
                Artificial Intelligence and Network Management", Work in
                Progress, Internet-Draft, draft-irtf-nmrg-ai-challenges-
                05, 18 March 2025, <https://datatracker.ietf.org/doc/html/
                draft-irtf-nmrg-ai-challenges-05>.

     [I-D.irtf-nmrg-network-digital-twin-arch]
                Zhou, C., Yang, H., Duan, X., Lopez, D., Pastor, A., Wu,
                Q., Boucadair, M., and C. Jacquenet, "Network Digital
                Twin: Concepts and Reference Architecture", Work in
                Progress, Internet-Draft, draft-irtf-nmrg-network-digital-
                twin-arch-11, 6 July 2025,
                <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-
                network-digital-twin-arch-11>.

     [MCP]      "Model Context Protocol", November 2024,
                <https://modelcontextprotocol.io/>.

     [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
                and A. Bierman, Ed., "Network Configuration Protocol
                (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
                <https://www.rfc-editor.org/rfc/rfc6241>.

     [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
                "Specification of the IP Flow Information Export (IPFIX)
                Protocol for the Exchange of Flow Information", STD 77,
                RFC 7011, DOI 10.17487/RFC7011, September 2013,
                <https://www.rfc-editor.org/rfc/rfc7011>.

     [RFC7854]  Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
                Monitoring Protocol (BMP)", RFC 7854,
                DOI 10.17487/RFC7854, June 2016,
                <https://www.rfc-editor.org/rfc/rfc7854>.

     [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
                Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
                <https://www.rfc-editor.org/rfc/rfc8040>.

     [RFC8639]  Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
                E., and A. Tripathy, "Subscription to YANG Notifications",
                RFC 8639, DOI 10.17487/RFC8639, September 2019,
                <https://www.rfc-editor.org/rfc/rfc8639>.

     [RFC8641]  Clemm, A. and E. Voit, "Subscription to YANG Notifications
                for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
                September 2019, <https://www.rfc-editor.org/rfc/rfc8641>.

     [RFC9232]  Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and
                A. Wang, "Network Telemetry Framework", RFC 9232,
                DOI 10.17487/RFC9232, May 2022,
                <https://www.rfc-editor.org/rfc/rfc9232>.

     [RFC9315]  Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
                Tantsura, "Intent-Based Networking - Concepts and
                Definitions", RFC 9315, DOI 10.17487/RFC9315, October
                2022, <https://www.rfc-editor.org/rfc/rfc9315>.

     [TMF-1251D]
                "AN Agent Architecture v1.0.0", May 2025,
                <https://www.tmforum.org/resources/introductory-guide/
                ig1251d-an-agent-architecture-v1-0-0/>.

     [TMF-1258] "Autonomous Networks Glossary v1.2.0", May 2025,
                <https://projects.tmforum.org/wiki/display/PUB/
                IG1258+Autonomous+Networks+Glossary+v1.2.0>.

  Appendix A.  Acknowledgements

     This work has benefited from the discussions of NMRG interim meeting
     on Agentic AI.  Thanks Chris Janz for wonderful comments and
     discussion on proactive close loop.

  Appendix B.  Changes between Revisions

     v02 - v03

  * Agentic AI Architecture Update.
  * Rewrite Functional Interfaces section for user to agent, agent to agent, agent to tools communication.
  * Explore Relationship Between      Management      Characteristics and Functional Components in section 6.
  * Rewrite a collection of use cases to support multi-agent collaborations.
  * Rewrite Challenges section to cover Trust and Security, protocol and benchmarking.
  * Add workflows for Agent Registration, Discovery, team forming.
  * Add workflow for Agent to Agent Communciation Security.
  * Rewrite Security Consideration Section.
  * Add Conclusion Section.

     v00 - v01

  * Add Security Consideration Section;
  * Add Acknowledge Section;
  * Clarify the relation between knowlege and tools;
  * Clarify the souce of knowlege;
  * Clarify the key characteristics of Network AI Agent to adpat to the environment change.

  Contributors

     Qiufang Ma
     Huawei
     Email: maqiufang1@huawei.com


     Zhenqiang Li
     CMCC
     Email: lizhenqiang@chinamobile.com


     Lionel Tailhardat
     Orange Research
     Email: lionel.tailhardat@orange.com


  Authors' Addresses

     Qin Wu
     Huawei
     China
     Email: bill.wu@huawei.com


     Cheng Zhou
     China Mobile
     China
     Email: zhouchengyjy@chinamobile.com


     Luis M. Contreras
     Telefonica
     Email: luismiguel.contrerasmurillo@telefonica.com


     Sai Han
     China Unicom
     China
     Email: hans29@chinaunicom.cn


     Yong-Geun Hong
     Daejeon University
     Email: yonggeun.hong@gmail.com


name: draft-chuyi-nmrg-ai-agent-network
rev: 02
title: Large Model based Agents for Network Operation and Maintenance
time: 2025-10-20T15:48:08Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T15:48:08Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "ML traffic mgmt", "Model serving/inference", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:03.420443+00:00
abstract:
  Current advancements in AI technologies, particularly large models,
     have demonstrated immense potential in content generation, reasoning,
     analysis and so on, providing robust technical support for network
     automation and self-intelligence.  However, in practical network
     operations, challenges such as system isolation and fragmented data
     lead to extensive manual, repetitive, and inefficient tasks, the
     improvement of intelligence level is very necessary.  This document
     identifies typical scenarios requiring enhanced intelligence, and
     explains how AI Agents and large model technologies can empower
     networks to address operational pain points, reduce manual efforts,
     and explore impacts on network data, system architectures, and
     interfaces correspondingly.  It further explores and summarizes
     standardization efforts in implementation.

full_text:
  Network Management Research Group                                 C. Guo
  Internet-Draft                                              China Mobile
  Intended status: Informational                              October 2025
  Expires: 23 April 2026


       Large Model based Agents for Network Operation and Maintenance
                    draft-chuyi-nmrg-ai-agent-network-02

  Abstract

     Current advancements in AI technologies, particularly large models,
     have demonstrated immense potential in content generation, reasoning,
     analysis and so on, providing robust technical support for network
     automation and self-intelligence.  However, in practical network
     operations, challenges such as system isolation and fragmented data
     lead to extensive manual, repetitive, and inefficient tasks, the
     improvement of intelligence level is very necessary.  This document
     identifies typical scenarios requiring enhanced intelligence, and
     explains how AI Agents and large model technologies can empower
     networks to address operational pain points, reduce manual efforts,
     and explore impacts on network data, system architectures, and
     interfaces correspondingly.  It further explores and summarizes
     standardization efforts in implementation.

  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in RFC 2119 [RFC2119].

  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 4 April 2026.




  Guo                       Expires 23 April 2026                 [Page 1]


  Internet-Draft  Large Model based Agents for Network Ope    October 2025


  Copyright Notice

     Copyright (c) 2025 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
       1.1.  Large Models  . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  AI Agent  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Acronyms & Abbreviations  . . . . . . . . . . . . . . . . . .   5
     3.  Use case  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.  Scenario 1: Network Migration Operations  . . . . . . . .   5
       3.2.  Scenario 2: Network Fault Handling  . . . . . . . . . . .   6
       3.3.  Scenario 3: Intelligent Assistant of User Complaint
             Handling  . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.  Architecture and Functionality  . . . . . . . . . . . . . . .   8
     5.  Observed Requirements . . . . . . . . . . . . . . . . . . . .  10
       5.1.  Data Requirement  . . . . . . . . . . . . . . . . . . . .  10
       5.2.  Network Intent Recognition Requirement  . . . . . . . . .  12
       5.3.  Self Close Loop Requirement . . . . . . . . . . . . . . .  13
       5.4.  Resource Requirement  . . . . . . . . . . . . . . . . . .  13
       5.5.  Muti-Agent Collaboration Requirement  . . . . . . . . . .  14
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
       8.1.  Informative References  . . . . . . . . . . . . . . . . .  15
       8.2.  Normative References  . . . . . . . . . . . . . . . . . .  16
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

  1.  Introduction











  Guo                       Expires 23 April 2026                 [Page 2]


  Internet-Draft  Large Model based Agents for Network Ope    October 2025


  1.1.  Large Models

     Large models refer to AI systems based on deep learning techniques,
     containing massive parameters (typically billions to trillions).  It
     is trained on large-scale datasets, and is capable of capturing
     complex patterns and associations, demonstrating outstanding
     abilities in natural language processing, image generation, decision-
     making, and reasoning.

     Recent breakthroughs in models like GPT-4 and DeepSeek have
     continuously pushed technical boundaries and enhancing the
     performance of models.Users can use the capabilities of large models
     by accessing or deploying inference models, and combining with Fine
     tuning, Prompt Learning, etc.

     The big model has been empowered in multiple vertical domains, like:

     *  Research: AlphaFold for protein structure prediction, Galactica
        for scientific paper assistance.  Industry: Generative design
        (e.g., automotive/chip architecture optimization), automated code
        development (GitHub Copilot).

     *  Finance: Risk prediction, automated report generation.

     In the future, large models will also move towards embodied AI ,
     embedding model capabilities into physical terminals such as robots
     and autonomous driving, continuously building an open-source
     developer ecosystem, opening up some model capability interfaces, and
     promoting industry collaborative innovation.

  1.2.  AI Agent

     Intelligent agent, as an important concept in the field of artificial
     intelligence, refers to a system that can autonomously perceive the
     environment, make decisions, and execute actions.  It has basic
     characteristics such as autonomy, interactivity, reactivity, and
     adaptability, and can independently complete tasks in complex and
     changing environments.  Intelligent agents have the ability to learn
     and make decisions.  Through learning algorithms and data analysis,
     they can extract useful information from massive amounts of data and
     form their own knowledge base.  In the decision-making process,
     intelligent agents can comprehensively consider various factors and
     use methods such as logical reasoning and probability statistics to
     make the optimal decision.  This ability gives intelligent agents a
     significant advantage in solving complex problems.

     There are four design patterns for intelligent agent
     workflow[LLMbasedAgents]:



  Guo                       Expires 23 April 2026                 [Page 3]


  Internet-Draft  Large Model based Agents for Network Ope    October 2025


     *  Reflection: Let the agent review and revise the output generated
        by themselves;

     *  Tool Use: LLM generates code, calls APIs, and performs practical
        operations;

     *  Planning: Let the agent decompose complex tasks and execute them
        according to the plan;

     *  Multi-agent Collaboration: Multiple agents play different roles
        and collaborate to complete tasks.

     At present, intelligent agents have been used in the following
     scenarios:

     *  Personal assistant:

        -  Cross platform task agent: Automatically organize emails,
           schedule meetings, and manage schedules (such as Microsoft
           Copilot).

        -  Life Butler: Adjust smart homes according to user habits and
           recommend personalized health plans.

     *  Industry Intelligence:

        -  Financial advisory: Real time analysis of market data,
           generation of investment portfolio recommendations, and
           automatic execution of trades.

        -  Medical diagnosis: Provide dynamic treatment recommendations
           based on the patient's medical history and real-time monitoring
           data.  Industrial operation and maintenance: Predicting
           equipment failures and scheduling maintenance resources to
           optimize production line efficiency.

     *  Virtual world interaction:

     *  -  Game NPC: Intelligent characters with emotions and memories
           (such as AI driven open world NPCs).

        -  Metaverse Guide: Help users explore virtual spaces and provide
           personalized content recommendations.

     *  Scientific research:






  Guo                       Expires 23 April 2026                 [Page 4]


  Internet-Draft  Large Model based Agents for Network Ope    October 2025


     *  -  Laboratory assistant: Automatically design experiments, analyze
           data, and propose hypotheses (such as chemical synthesis
           agents).

        -  Climate simulation: Coordinating multidimensional data models
           to predict extreme weather and generate response plans.

  2.  Acronyms & Abbreviations

     Large model:  Machine learning models with large-scale parameters and
        computing power are typically constructed from deep neural
        networks, containing billions or even hundreds of billions of
        parameters, capable of understanding text, images, speech, and
        other content, and performing tasks such as text generation, image
        generation, inference question answering, and scientific
        prediction.

     AI Agent:  An AI agent is an intelligent entity with autonomous
        perception, decision-making, and execution capabilities, driven by
        goals in dynamic environments.

  3.  Use case

     This section list 3 typical use cases of how AI Agent can facilite
     network operation and maintenance, which have been proven to be the
     most effective combination in the practice.

  3.1.  Scenario 1: Network Migration Operations

     The current network undergoes a large number of service migration or
     device switchover every day/month, which have a high degree of
     similarity in steps and processes, involving querying and filling a
     large amount of data and configuration.  There are two typical types
     of migrations: service provisioning (for external service data
     configuration) and migration change (for internal tasks such as route
     publishing and network optimization).  Large models naturally have
     the ability to process and recognize massive amounts of data, and
     intelligent agents can guide the process of each step like
     experienced experts.

     Automation via large models and agents can reduce errors and free
     human resources.  Key tasks include:

     *  Migration Plan Generation: Designing workflows and deployment
        strategies.

     *  Plan Auditing: Checking configurations, compliance, and correcting
        errors (e.g., typos, hallucinations).



  Guo                       Expires 23 April 2026                 [Page 5]


  Internet-Draft  Large Model based Agents for Network Ope    October 2025


     *  Automated Execution: Replacing manual configurations with AI-
        generated scripts, call corresponding systems to finish tasks.

     Taking the service provisioning scenario as an example, typically,
     when doing migration, it was necessary to manually log in the device
     configuration parameters.  Now, through the interaction of the large
     model, the large model generates a script to distribute the device,
     also configure and audit it.  The agent can call other systems, such
     as digit twin platform for script testing, view the impact of the
     changed parameters, and return to the assigned system to reduce
     manual errors.  Finally, based on the analysis of the results, it can
     achieve automatic distribution when there shows no problem.

  3.2.  Scenario 2: Network Fault Handling

     Traditional fault handling is usually single domain autonomy.  When
     monitoring detects anomalies such as alarms, a fault ticket is
     generated and sent to the corresponding specialized network domain
     for solutions.  Generally speaking, one single fault point triggers
     alarms across multiple domains and locations, tickets will be
     assigned to each involved domain, this results in numerous tickets
     for each domian, which leads to low processing efficiency.

     Different network domains receiving fault tickets will conduct fault
     analysis, positioning, and report troubleshooting results to the
     upper monitoring layer for fault management.  Each network domain has
     its own troubleshooting process for different alarms.  Based on
     expert experience, data analysis, and tools, the positioning
     capability is very comprehensive and reliable, but it heavily relies
     on manual labor and may requires night duty to respond promptly when
     faults occur.  By training professional fault intelligent agents with
     fault cases and manually summarized experience, coupled with fine-
     tuning of professional domain knowledge, domain-specific fault
     handling agents can identify faults based on alarm types and other
     information, generate troubleshooting steps (such as data query and
     tool calling schemes), and call corresponding APIs to perform
     troubleshooting actions, finally obtaining fault positioning
     conclusions.

     Due to the chain reaction caused by alarms, which usually involve
     multiple specialties, top-level monitoring agents need to cooperate
     and coordinate with various domain agents, and positioning conclusion
     needs to be carried out across specialties.  In addition to replacing
     manual alarm preprocessing and ticket dispatching, agents also need
     to be connected to alarm systems, performance systems, etc., to
     perceive abnormal data in the network at any time, trigger fault
     analysis and positioning processes, and continuously interact with
     different domain agents for necessary information, find the root



  Guo                       Expires 23 April 2026                 [Page 6]


  Internet-Draft  Large Model based Agents for Network Ope    October 2025


     cause of the fault, and finally generate the fault handling report.
     The top-level monitoring agent can have the alarms, topology and
     other information of different domains.  And it can conduct cross-
     disciplinary joint consultations, which is more advantageous than
     traditional methods.

  3.3.  Scenario 3: Intelligent Assistant of User Complaint Handling

     In the past few years, there has been research and development of AI
     model capabilities in the field of complaints, such as complaint
     prediction, complaint problem positioning, and complaint warning, to
     improve complaint handling efficiency, reduce complaint ratios, and
     play an auxiliary role in various service complaint handling such as
     home broadband, 4/5G, and IoT.  However, this single funtion models
     lack natural language processing and content generation capabilities,
     and their role in improving efficiency is limited.

     The complaint handling faces challenges such as heavy workload and
     lack of pre-processing ability in the front-line customer service.
     Taking the scenario of home broadband as an example, traditional
     processes allow users to seek help from manual customer service by
     making phone calls when encountering problems.  Frontline customer
     service staff will answer the user's questions and provide guidance
     on simple handling.  If it cannot be quickly resolved through simple
     steps, a problem handling ticket will be generated, and the system
     will assign maintenance personnel to come to the site.  After the
     repair is completed, a dedicated person will call for satisfaction
     follow-up.  Traditional processes rely heavily on manual labor, and
     customer service responses have a high degree of repetition and
     structure.  It is necessary to introduce electronic means to
     systematically improve processing efficiency and replace manual
     labor.

     Introducing the intelligent assistant of user complaint handling can
     replace customer service staff in answering customer complaint calls,
     it can achieve the following process:

     *  Firstly, perform intent recognition on the voice content of the
        customer's phone call

     *  Intelligent diagnosis of identified problems, determining the
        category and attributes of the problem, and determining the next
        steps for operation

     *  Can provide direct response/prompt handling, dispatch, remote
        operation, and manual processing for user issues





  Guo                       Expires 23 April 2026                 [Page 7]


  Internet-Draft  Large Model based Agents for Network Ope    October 2025


     *  Intelligent quality inspection and automatic satisfaction follow-
        up

     Leveraging the complaint-handling intelligent agent and its AI-
     powered diagnostic engine and big data analytics capabilities, we
     have built an end-to-end service loop of "proactive perception -
     precise prediction - preemptive resolution".  This transforms
     complaint handling from passive acceptance to active intervention.

     Based on real-time network quality monitoring and a historical fault
     signature database, installation/maintenance technicians can now
     remotely automate issue resolution and generate solutions before on-
     site visits.  The complaint-handling process shifts from human-driven
     to AI-driven, task scheduling evolves from reliance on manual
     experience to autonomous planning and decision-making, and manual
     operations are upgraded to automated execution or human-machine
     collaboration.  This significantly reduces processing time and lowers
     repeat complaint rates, reshaping service experiences through
     intelligent solutions and substantially improving fault resolution
     efficiency.

     During user interactions or technician on-site visits, the system
     utilizes large model capabilities to call APIs or execute SQL queries
     for real-time device status and performance metrics, replacing fixed
     interfaces and manual queries with intelligent integrated access.
     For complex issues and workflows, the large model-based agent can
     also invoke small model capabilities (e.g., network traffic fault
     diagnosis models) mid-process.

     When handling complaints, the agent responsible for direct human-
     complaint interaction can collaborate with other specialized agents
     (e.g., a Home Broadband Troubleshooting Assistant) through multi-
     agent cooperation to achieve closed-loop resolution.

  4.  Architecture and Functionality

     Intelligent agents based on large models can automate network
     operations by coordinating system scheduling and leveraging diverse
     capabilities of large models.  This process involves multiple
     interactions with systems such as large models and network management
     systems.  Each agent has specialized functions, such as agents for
     intent understanding or agents dedicated to fault localization and
     demarcation in specific network scenarios.  Current operational
     systems already provide basic data support, foundational atomic
     capabilities, and well-defined orchestration workflows for task
     execution.  However, most processes are manually connected, involve
     repetitive mechanical work, and lack an intelligent coordination
     "brain".  See Figure 1.



  Guo                       Expires 23 April 2026                 [Page 8]


  Internet-Draft  Large Model based Agents for Network Ope    October 2025


                          Agents                                       Network
  +------------------------------------------------------+ +---------------------------+
  |                                                      | |                           |
  |                    +------------+                    | |Network Systems & Platforms|
  |                    | Perception |                    | |                           |
  |                    +------+-----+                    +->        AI Models          |
  |                           |                          | |                           |
  |                  +--------v--------+                 | |    Atomic Capabilities    |
  |  +----------+    |      Brain      |    +----------+ | |                           |
  |  | Planning <+-+-+                 +-+-+>  Action  | | |          Tools            |
  |  +----------+    | LLM | LVM | LSM |    +----------+ <-+                           |
  |                  +------+--^-------+                 | |           Data            |
  |                         |  |                         | |                           |
  |                    +----v--+----+                    | |                           |
  |                    |   Memory   |                    | |                           |
  |                    +------------+                    | |                           |
  +------------------------------------------------------+ +---------------------------+

            Figure 1: Architecture of Large Model based Agents

     Functions of Agents:

     *  Intent Recognition: Understand and interpret user input
        intentions.  Determine whether subsequent tasks require
        identifying suitable agents or multi-turn dialogues to complete
        intent recognition and parsing.

     *  Intent Classification and Analysis: Decompose tasks based on
        recognized user intent.Categorize tasks according to different
        functional requirements.

     *  Perception: Proactively receive alarms, threshold-exceeding
        notifications, or environmental change information, issuing
        warnings when necessary.Accept task requests from other systems,
        potentially involving multimodal data processing.

     *  Memory:

        -  Long-term memory: Stores user habits, domain-specific
           processing experiences (e.g., failure/success cases,
           encountered faults) in knowledge bases.

        -  Short-term memory: Caches temporary processing data (e.g.,
           context).

     *  Agents perform reflection and error correction by interacting with
        long-term memory and contextual information.




  Guo                       Expires 23 April 2026                 [Page 9]


  Internet-Draft  Large Model based Agents for Network Ope    October 2025


     *  Planning: Analyze and decompose intent based on task objectives
        and learned knowledge.  Orchestrate subtasks (e.g., breaking
        complex problems into simpler ones).  Identify required system
        components (other agents, large models, APIs, etc.).

     *  Decision-Making: Finalize execution plans and match workflows to
        current tasks.  Generate instantiated, executable solutions by
        aligning system components, data, and model strategies.

     *  Execution: Convert orchestrated results into network-
        understandable commands.  Execute tasks by mobilizing resources
        and dynamically adjusting based on feedback.

     *  Multi-Agent Collaboration:

        -  Team Collaboration: Enable coordinated teamwork among multiple
           agents.

        -  Competitive Collaboration: Manage competitive relationships to
           avoid efficiency loss.

  5.  Observed Requirements

     Based on the aforementioned practical use cases regarding the
     implementation of intelligent agent functional modules, this chapter
     will summarize and analyze the technologies, challenges and
     constraints encountered during the deployment and implementation of
     agents in network operations.  It will also propose potential
     requirements across different dimensions.

  5.1.  Data Requirement

     Data is the foundation of agents to take effect, which includes:

     *  Data used for training and inference: The data used for training
        and inference, which is typically used before the agent provides
        services to users, it can be expert knowledge in operation and
        maintenance processes, logs, configuration rules, policy
        knowledge, case manuals, alarms, network topologies, fault
        reports, and more.  The data here is used to teach big models how
        to do it, usually historical data.  The performance of the model
        based on data learning can be adjusted through reward functions,
        etc.  The actual implementation cases in the later stage can also
        be stored in long-term storage as reinforcement learning, which
        can be used as a reference for generating solutions later.






  Guo                       Expires 23 April 2026                [Page 10]


  Internet-Draft  Large Model based Agents for Network Ope    October 2025


     *  Dynamic data during task execution: Dynamic data can also be
        categorized into two types: User intent data (e.g., natural
        language task descriptions), operational data from systems.  For
        user-expressed intents, typically extracted during user
        interactions (which may include multimodal inputs like voice or
        images), agents expose dedicated interfaces for user input, and
        upon receiving it, performs intent recognition before executing
        subsequent steps.  The data used for system operation refers to
        the constantly collected data in the network, such as monitoring
        performance indicators, alarms and other data, as well as messages
        from other systems, such as device network access/upgrade
        information.

     Requirements:

     For training data:

     *  It mainly reflects integrity.  The training data of a large model
        not only needs to reach a certain number of parameter levels, but
        also needs to ensure comprehensive and accurate coverage, reducing
        interference data.

     *  In order to enable intelligent agents to trigger subsequent
        processing based on alarm and other data in the system, it is
        necessary to manually establish expert experience and rules, and
        even establish new interfaces to support the problem meanings
        represented by different data phenomena.  This part can be
        standardized.

     For dynamic data:

     *  Modal transformation.  For example, if it is an LLM based agent,
        users need to convert text before extracting intent when receiving
        images.

     *  How to extract intent.  This requires understanding the running
        data, knowing what the indicators represent, which type of
        analysis and processing should be triggered (consistent with the
        training data requirement 2 mentioned above), and extracting which
        type of features from the input for subsequent intent recognition.
        This process requires classifying the network's events, behaviors,
        etc. in advance.

     *  Align the formats of different input data.  The main solution is
        to solve the problem of not being able to directly understand and
        call each other when different APIs and tools are accessed or
        called with different formats.  The MCP protocol[MCP] in the
        industry can ease this problem.  MCP converts tool capabilities



  Guo                       Expires 23 April 2026                [Page 11]


  Internet-Draft  Large Model based Agents for Network Ope    October 2025


        into standardized function semantics through JSON Schema, enabling
        large models to implement zero sample calls based on tool
        descriptors without the need for prior learning or fine-tuning.
        This enables the integration of large language models with
        external data sources and tools, and is used to establish secure
        bidirectional connections between large models and data sources.
        MCP defines a set of universal communication protocols, data
        formats, and rules that can be simplified for development,
        flexible, real-time responsive, secure, compliant, and scalable.
        It processes both local resources (such as databases, files,
        services, etc.) and remote resources (such as APIs like Slack or
        GitHub) through the same protocol, hence it is known as the USB-C
        port for AI applications.  In addition to MCP, enterprises can
        also use their own agent protocols to call different systems and
        adopt and design unified format conversion standards.

  5.2.  Network Intent Recognition Requirement

     Network intent recognition refers to how to correctly understand the
     significance of various indicators for the network when receiving
     different data from the network, and how to analyze the collected
     indicators based on existing network operation and maintenance
     practices, extracted from human experience and knowledge manuals.  On
     the other hand, how human input is transformed into network goals and
     actions can also be a part of network intent recognition.  The
     current implementation.  This is where standardization is needed.

     To support the implementation of closed-loop, a knowledge graph model
     can be constructed to inject large models.  After receiving user or
     network intent, perform entity recognition, retrieve knowledge graph,
     complete entity linking, and output structured intent[CCSAKG].

     Graph Neural Network (GNN) refers to an algorithm that uses neural
     networks to learn graph structured data, extract and discover
     features and patterns from graph structured data, and meet the
     requirements of graph learning tasks such as clustering,
     classification, prediction, segmentation, and generation.  In the
     construction of network operation and maintenance knowledge, entities
     such as devices, links, and alarms can be abstracted into graph
     structures, and hidden relationships can be mined through message
     passing mechanisms to achieve the transformation of operation and
     maintenance problems from "passive response" to "active cognition".
     In the graph structure, physical devices can be nodes, connection
     relationships can be edges, and they can also be used to construct
     event correlation graphs.






  Guo                       Expires 23 April 2026                [Page 12]


  Internet-Draft  Large Model based Agents for Network Ope    October 2025


     Requirement: Establish a knowledge graph in the field of network
     management and operation, sort out the interrelationships and
     collaborative relationships between entities in different events or
     categories, and assist large models in understanding and inference by
     retrieving relevant entities and relationships from the knowledge
     graph.

  5.3.  Self Close Loop Requirement

     Intelligent agents need to have the ability to complete tasks on
     their own without human intervention.  In addition to the
     aforementioned requirements for data input and intent understanding,
     the operation and maintenance agent should also have execution
     capabilities, including generating task plans, calling APIs, and
     completing actions.  This process involves issues such as permission
     management and security confidentiality.

  5.4.  Resource Requirement

     The resource requirements for agent applications mainly include three
     aspects: storage, computing force, and network infrastructure.

     Storage should consider cloud edge coordination.  In the training and
     use of intelligent delivery, in addition to building a knowledge
     base, contextual information, user preferences, historical records,
     etc. also need to be continuously stored.  Some content may need to
     be stored on the user side, while others are more suitable for
     obtaining in the cloud.  Resource coordination and balance are key
     issues.  In addition, intelligent agents require a large amount of
     storage resources, and so much information requires efficient access
     solutions.

     The computing force part mainly considers the allocation of computing
     resources as needed based on the analysis of task complexity during
     the inference process.  The PD separation architecture can be adopted
     to improve inference efficiency.

     The network infrastructure mainly provides low latency and high
     bandwidth network support, which can use SRv6/G-SRv6 to compress
     packet headers, improve cross domain scheduling efficiency, and
     optimize long-distance data transmission throughput through RDMA.










  Guo                       Expires 23 April 2026                [Page 13]


  Internet-Draft  Large Model based Agents for Network Ope    October 2025


  5.5.  Muti-Agent Collaboration Requirement

     In order to complete specific tasks, some can be accomplished through
     self-closed-loop of agents, while others require collaboration among
     multiple agents.  This includes three communication modes:
     interaction between humans and agents, interaction between agents and
     the environment, and interaction between different agents.  The
     interaction between humans and agents is the input of human
     intentions, usually in the form of natural language, and the input
     content is multimodal (voice, text, images, etc.).  The interaction
     between agents and the environment is usually achieved through
     interface access, which can obtain data, and triggering subsequent
     actions.  The interaction between different agents is the input and
     output interaction among agents, which involves both multimodal
     information exchange and system interface level interaction.

     In order to enable different agents to cooperate with each other,
     complete tasks together, and achieve a large closed loop, the
     following requirements are observed:

     *  Agent discovery.  Unlike traditional communication, where
        connections are established based on known addresses,
        communication through agent collaboration is temporary and the
        objects completing tasks are not unique, requiring self discovery
        to determine the communication objects.  To support this, the
        communication network needs to establish an intelligent agent
        discovery mechanism.

     *  Agent authentication.  Agents need network authentication to
        access the network.  Unlike mobile devices, agents have many
        behaviors that cannot be distinguished from human behavior.
        Therefore, targeted agent authentication schemes need to be
        proposed.

     For the above two requirements, A2A[A2A], AGNTCY and others in the
     industry have proposed their own protocol implementations, but the
     complete solution that requires network adaptation involved in the
     above process is still blank.

     *  Unified Agents connection control and arrangement.  Due to the
        frequent team communication and partner searching required between
        intelligent agents to complete tasks, different vendors may
        provide intelligent agents with similar functions.  It is best to
        have a unified intelligent agent management platform for easier
        team building.  Additionally, it also includes the scheduling and
        allocation of underlying computing resources, as well as state
        management.




  Guo                       Expires 23 April 2026                [Page 14]


  Internet-Draft  Large Model based Agents for Network Ope    October 2025


     *  Standardized communication protocol between Agents for Network
        Operation and Maintenance at different levels.  There is a mutual
        calling relationship between agents at different levels in work
        Operation and Maintenance.  For example, the fault handling agent
        calls multiple network professional domain agents, and the network
        professional agent calls the underlying controller or network
        management system to complete the analysis and processing of
        faults.  Different agents need to communicate with each other, and
        the fundamental requirement is to agree on the information
        parameters and return content that need to be transmitted between
        the upper and lower layers for a certain event.  Therefore, the
        requirments are:

        -  A standard inter level protocol is needed, which is not related
           to the natures or functions of agents within the level, and
           standardizes the input and output of agents.

        -  A unified communication format is needed to ensure semantic
           consistency.

        .

  6.  IANA Considerations

     This document has no requests to IANA.

  7.  Security Considerations

     This document describes concepts and definitions of agent in network
     OAM.  As such, the following security considerations remain high
     level, i.e., in the form of principles, guidelines or requirements.

  8.  References

  8.1.  Informative References

     [A2A]      Google, "Agent2Agent(A2A)
                Protocol：https://google.github.io/A2A/#/", April 2025.

     [CCSAKG]   CCSA, "SR 460-2024 Study on building knowledge graph for
                network", January 2024.

     [LLMbasedAgents]
                Cheng, Y. Cheng., Zhang, C. Zhang., Zhang, Z. Zhang.,
                Meng, X. Meng., and S. Hong. Hong, "Exploring Large
                Language Model based Intelligent Agents: Definitions,
                Methods, and Prospects.", January 2024.




  Guo                       Expires 23 April 2026                [Page 15]


  Internet-Draft  Large Model based Agents for Network Ope    October 2025


     [MCP]      Anthropic, "Model Context Protocol
                (MCP)：https://www.anthropic.com/news/model-context-
                protocol", November 2024.

  8.2.  Normative References

     [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>.

  Author's Address

     Chuyi Guo
     China Mobile
     Beijing
     100053
     China
     Email: guochuyi@chinamobile.com
































  Guo                       Expires 23 April 2026                [Page 16]


name: draft-zl-agents-networking-scenarios
rev: 00
title: Agents Networking Scenarios in Enterprise and Broadband Networks
time: 2025-10-20T19:44:02Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T19:44:02Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-03T15:50:09.773507+00:00
abstract:
  This document describes agents networking scenarios in enterprise and
     home broadband networks.  These scenarios differ from 6G and Internet
     scenarios.  Since the agentic service is still at the emerging stage,
     especially in enterprise and home broadband networks, the scenarios
     are mostly based on reasonable assumptions.

full_text:
  network working group                                             B. Liu
  Internet-Draft                                                  L. Zhang
  Intended status: Informational                       Huawei Technologies
  Expires: 23 April 2026                                            Y. Liu
                                                               Independent
                                                           20 October 2025


      Agents Networking Scenarios in Enterprise and Broadband Networks
                  draft-zl-agents-networking-scenarios-00

  Abstract

     This document describes agents networking scenarios in enterprise and
     home broadband networks.  These scenarios differ from 6G and Internet
     scenarios.  Since the agentic service is still at the emerging stage,
     especially in enterprise and home broadband networks, the scenarios
     are mostly based on reasonable assumptions.

  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 23 April 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.











  Liu, et al.               Expires 23 April 2026                 [Page 1]


  Internet-Draft         Agents Networking Scenarios          October 2025


     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
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
     2.  Enterprise Scenarios  . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Smart Office  . . . . . . . . . . . . . . . . . . . . . .   3
       2.2.  Agentic Digitalization  . . . . . . . . . . . . . . . . .   3
       2.3.  Industrial Automation . . . . . . . . . . . . . . . . . .   4
     3.  Home Broadband Network Scenarios  . . . . . . . . . . . . . .   5
     4.  Operational Considerations  . . . . . . . . . . . . . . . . .   6
       4.1.  Self-contained Private Deployment . . . . . . . . . . . .   6
       4.2.  Economical Integrated Implementation  . . . . . . . . . .   6
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
     8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     With the rapid development of artificial intelligence, single-agent
     systems have gradually revealed their limitations in handling
     complex, multi-task, and cross-domain scenarios.  Agent networking,
     as a core paradigm for breaking through individual capabilities and
     achieving collective intelligence, has become a key trend in the
     future development of agents.

     This document describes agents networking scenarios in enterprise and
     home broadband networks.

  1.1.  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.





  Liu, et al.               Expires 23 April 2026                 [Page 2]


  Internet-Draft         Agents Networking Scenarios          October 2025


  2.  Enterprise Scenarios

     The AI Agent is progressively becoming the key technological unit
     supporting both internal enterprise process automation and cross-
     enterprise ecosystem collaboration.  Compared to the traditional API
     interface integration model, the AI Agent is capable of achieving
     more flexible and loosely coupled collaboration methods through
     abilities such as semantic perception, strategy-driven execution, and
     autonomous decision-making.  The essence of this change is an upgrade
     from "system integration" to an "Intranet of Agents."

  2.1.  Smart Office

     In the Smart Office scenario, AI Agents enhance daily productivity
     and collaboration.

     Agent Collaboration:

     *  Personal Assistant Coordination: A user's personal AI Agent
        (residing on a mobile or PC) coordinates with other specialized
        Agents, such as the Meeting Room Agent, IT Service Agent etc..
        This collaboration facilitates automated task execution, including
        scheduling meetings, reserving room resources, preparing necessary
        documents, and initiating video conference sessions.

     *  Team Task Alignment: Multiple project-related Agents, representing
        different team members or functions, engage in real-time data
        sharing, automatic summarization of meeting minutes, dynamic task
        prioritization, and collaborative document editing.

     Network Requirements:

     *  Low Latency and High Reliability: Crucial for seamless video
        conferencing and real-time collaborative applications.

     *  Unified Agent Discovery and Invocation: Agents must rely on
        standard protocols to locate and invoke the capabilities of other
        Agents within the enterprise network (e.g., printing or storage
        services).

     *  Secure Authentication and Authorization: to ensure Agent actions
        are strictly compliant with the authorized scope granted by the
        human user or project manager.

  2.2.  Agentic Digitalization

     This scenario focuses on automating and optimizing business processes
     using autonomous Agents.



  Liu, et al.               Expires 23 April 2026                 [Page 3]


  Internet-Draft         Agents Networking Scenarios          October 2025


     Agent Collaboration:

     *  Business Workflow Automation: A Process Management Agent
        collaborates with various Business System Agents (e.g., CRM Agent,
        ERP Agent).  It autonomously translates high-level business
        intents (e.g., "maximize customer retention") into executable
        plans, decomposes the overall task, and executes complex workflows
        across disparate business systems by invoking their respective
        Agents.

     *  Data-Driven Decision Making: Data Collection Agents aggregate
        information from various sources, feeding it to Data Analysis
        Agents.  The resulting insights guide Decision Agents, which
        autonomously take prescribed actions, such as dynamically
        adjusting cloud resource allocations.

     Networking and Communication Requirements:

     *  Heterogeneous Interoperability: Agent communication protocols must
        be designed to bridge communication gaps between legacy IT system
        APIs and modern AI Agent platforms.

     *  High Concurrency and Scalability: The network infrastructure must
        be capable of supporting numerous Agents engaged in frequent,
        complex, and high-volume interactions across the enterprise.

  2.3.  Industrial Automation

     This scenario applies Agents to the operational domain, demanding
     strict performance guarantees.

     Agent Collaboration:

     *  High Efficient Producing: On the production floor, Sensors,
        Robots, Controllers collaborate to continuously monitor
        environmental variables and production status.  This tight
        collaboration allows for dynamic optimization of manufacturing
        processes, maximizing efficiency and minimizing downtime.

     *  High Quality Producing: Remote Diagnostics Agents collaborate with
        local Equipment Agents to transmit high-definition video feeds and
        machine logs.  This enables sophisticated remote fault diagnosis
        and highly accurate predictive maintenance operations.

     Networking and Communication Requirements:






  Liu, et al.               Expires 23 April 2026                 [Page 4]


  Internet-Draft         Agents Networking Scenarios          October 2025


     *  Ultra-Low Latency and Jitter: Critical control loops require
        communication that adheres to industrial-grade standards,
        specifically Ultra-Reliable Low-Latency Communication.

     *  Deterministic Networking (DetNet): The underlying network may need
        to incorporate DetNet technologies to guarantee bounded and
        predictable latency for communications among critical control
        Agents.

     *  OT/IT Convergence: A key requirement is defining how Agents can
        securely and reliably communicate with gateway functions
        connecting the Operational Technology (OT) domain to the
        Information Technology (IT) domain.

     *  Mobility Management: the robots and AGVs are constently moving, it
        is critical to maintain the session for the moving nodes.

  3.  Home Broadband Network Scenarios

     The home network scenario is characterized by user experience
     optimization and device collaboration.

     Agent Collaboration:

     *  Home Security: For instance, a smart camera may stream footage to
        a NAS Agent for storage of anomalous events, while simultaneously
        alerting to the user's Mobile Agent.

     *  User Experience Guarantee: The Home Gateway (e.g., on the home
        router/ONT, or on the BNG) collaborates with Terminal Agents
        (e.g., on gaming consoles, smart TVs) to classify traffic.  This
        allows the Gateway to dynamically prioritize and allocate
        bandwidth to latency/bandwidth-sensitive applications (like online
        gaming or 4K streaming), ensuring a consistently high Quality of
        Experience (QoE).

     Networking and Communication Requirements:

     *  Lightweight and Efficient Protocols: Given the variety of
        resource-constrained consumer devices, the Agent communication
        protocol must be designed to be lightweight and computationally
        efficient.

     *  Mobility Management: The network architecture must provide
        mechanisms to maintain session persistence and support seamless
        handover for Agents when a user transitions between the home Wi-Fi
        network and a mobile cellular network.




  Liu, et al.               Expires 23 April 2026                 [Page 5]


  Internet-Draft         Agents Networking Scenarios          October 2025


  4.  Operational Considerations

     There are two primary operational paradigms in varying enterprise and
     home requirements: the fully isolated Self-contained Private
     Deployment and the resource-optimized Economical Integrated
     Implementation.

  4.1.  Self-contained Private Deployment

     This model emphasizes security, performance, and control, typically
     favored by large enterprises, industrial environments (Smart
     Manufacturing), or highly security-conscious users.

     *  Isolated Infrastructure: All core AI Agent components, including
        the Large Language Model (LLM) inference engines, Agent
        orchestrators, Agent naming/discovery services etc., are deployed
        entirely within the private network domain (e.g., enterprise LAN
        or private cloud).

     *  Data Sovereignty: No Agent communication data, task context, or
        locally sensitive information leaves the private network.  This is
        essential for scenarios involving proprietary data or compliance
        with strict regulatory requirements.

     *  On-Premises Compute Resources: Requires substantial dedicated
        compute and storage resources (e.g., GPUs for inference) within
        the private domain, which must be connected via high-speed
        interfaces.

     *  Controlled Network Egress: Strict policies are applied to prevent
        Agents from accessing unauthorized external services, minimizing
        the external attack surface.  The network needs mechanisms for
        precise monitoring of all egress traffic initiated by Agents.

  4.2.  Economical Integrated Implementation

     This model prioritizes cost-efficiency, and leverages existing cloud
     and public infrastructure, often seen in home networks (Home
     Broadband) and smaller Smart Office setups.

     *  Hybrid Architecture: The core intelligence (e.g., the LLM) and
        central coordination services (e.g., Agent discovery) are
        typically hosted in a public or operator cloud environment.  Local
        Agents (e.g., device Agents, edge Agents on the home gateway)
        handle sensing, local actuation, and interface with the cloud-
        based central Agent.





  Liu, et al.               Expires 23 April 2026                 [Page 6]


  Internet-Draft         Agents Networking Scenarios          October 2025


     *  Tool/API Delegation: Cloud-based Agents often delegate local tasks
        by invoking APIs exposed by local Agents, or by sending compressed
        instructions to the edge device.

     *  Cost Optimization: This model reduces the need for comprehensive
        system that combined by various components, but rather, some
        integrated model of providing the service (e.g. through an Agent
        Gateway).

  5.  Security Considerations

     TBD

  6.  IANA Considerations

     This document has no IANA actions.

  7.  Acknowledgements

     TBD

  8.  Normative References

     [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>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  Authors' Addresses

     Bing Liu
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: leo.liubing@huawei.com


     Li Zhang
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: zhangli344@huawei.com



  Liu, et al.               Expires 23 April 2026                 [Page 7]


  Internet-Draft         Agents Networking Scenarios          October 2025


     Yuxing Liu
     Independent
     Beijing
     China
     Email: 83772966@qq.com














































  Liu, et al.               Expires 23 April 2026                 [Page 8]


name: draft-stephan-ai-agent-6g
rev: 02
title: AI Agent protocols for 6G systems
time: 2025-10-20T23:23:58Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T23:23:58Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent discovery/reg", "Data formats/interop", "Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:03.420448+00:00
abstract:
  Communication between AI agents and between agent and tools is
     expected to be pivotal in 6G systems.  The 3GPP TR 22.870 outlines
     various use cases and potential service requirements for AI agent
     communication within 6G systems.  This document provides examples of
     use cases and service requirements contained in the 3GPP TR 22.870
     and extrapolates possible requirements related to agent communication
     protocols.

full_text:
  Network Working Group                                    E. Stephan, Ed.
  Internet-Draft                                                    Orange
  Intended status: Informational                                 R. Schott
  Expires: 23 April 2026                                  Deutsche Telekom
                                                                  D. Lopez
                                                                Telefonica
                                                                   X. Duan
                                                              China Mobile
                                                                 L. Morand
                                                                    Huawei
                                                           20 October 2025


                     AI Agent protocols for 6G systems
                        draft-stephan-ai-agent-6g-02

  Abstract

     Communication between AI agents and between agent and tools is
     expected to be pivotal in 6G systems.  The 3GPP TR 22.870 outlines
     various use cases and potential service requirements for AI agent
     communication within 6G systems.  This document provides examples of
     use cases and service requirements contained in the 3GPP TR 22.870
     and extrapolates possible requirements related to agent communication
     protocols.

  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 23 April 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.




  Stephan, et al.           Expires 23 April 2026                 [Page 1]


  Internet-Draft           Agent protocols for 6G             October 2025


     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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  AI Agent related use cases in the context of 6G . . . . . . .   4
       2.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.2.  Network Optimization and Management . . . . . . . . . . .   5
       2.3.  Immersive Communications  . . . . . . . . . . . . . . . .   5
       2.4.  Hyper-Reliable Low-Latency Communications . . . . . . . .   6
       2.5.  Massive IoT Device Communications . . . . . . . . . . . .   6
       2.6.  Security and Privacy  . . . . . . . . . . . . . . . . . .   6
       2.7.  Autonomous Systems  . . . . . . . . . . . . . . . . . . .   6
       2.8.  AI Agent Collaboration  . . . . . . . . . . . . . . . . .   7
     3.  Potential agent communications related requirements . . . . .   7
       3.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.2.  Interoperability  . . . . . . . . . . . . . . . . . . . .   7
         3.2.1.  Standardized Protocols  . . . . . . . . . . . . . . .   8
         3.2.2.  Multimodal Data Formats . . . . . . . . . . . . . . .   8
         3.2.3.  Agent Identity Management . . . . . . . . . . . . . .   8
       3.3.  Discovery Mechanisms  . . . . . . . . . . . . . . . . . .   8
       3.4.  Task Management . . . . . . . . . . . . . . . . . . . . .   9
       3.5.  Context Awareness . . . . . . . . . . . . . . . . . . . .   9
         3.5.1.  Contextual Understanding  . . . . . . . . . . . . . .   9
         3.5.2.  Adaptive Communication  . . . . . . . . . . . . . . .   9
       3.6.  Autonomy  . . . . . . . . . . . . . . . . . . . . . . . .   9
         3.6.1.  Decision Making . . . . . . . . . . . . . . . . . . .   9
         3.6.2.  Self-Management . . . . . . . . . . . . . . . . . . .   9
       3.7.  Security  . . . . . . . . . . . . . . . . . . . . . . . .   9
         3.7.1.  Authentication and Authorization  . . . . . . . . . .  10
         3.7.2.  Data Protection . . . . . . . . . . . . . . . . . . .  10
         3.7.3.  User Consent  . . . . . . . . . . . . . . . . . . . .  10
       3.8.  Low Latency Communication . . . . . . . . . . . . . . . .  10
       3.9.  Reliability . . . . . . . . . . . . . . . . . . . . . . .  10
         3.9.1.  Fault Tolerance . . . . . . . . . . . . . . . . . . .  10
         3.9.2.  Load Balancing  . . . . . . . . . . . . . . . . . . .  10
         3.9.3.  Redundancy  . . . . . . . . . . . . . . . . . . . . .  11
       3.10. Flexibility . . . . . . . . . . . . . . . . . . . . . . .  11
         3.10.1.  Scalability  . . . . . . . . . . . . . . . . . . . .  11
         3.10.2.  Adaptability . . . . . . . . . . . . . . . . . . . .  11
         3.10.3.  Extensibility  . . . . . . . . . . . . . . . . . . .  11



  Stephan, et al.           Expires 23 April 2026                 [Page 2]


  Internet-Draft           Agent protocols for 6G             October 2025


       3.11. Energy Efficiency . . . . . . . . . . . . . . . . . . . .  11
         3.11.1.  Optimized Communication  . . . . . . . . . . . . . .  11
         3.11.2.  Power Management . . . . . . . . . . . . . . . . . .  11
     4.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  12
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
       7.1.  Informative References  . . . . . . . . . . . . . . . . .  13
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

  1.  Introduction

     Since 1998, the 3rd Generation Partnership Project (3GPP) has been
     fundamental in the development of standards for various generations
     of mobile networks, including 3G, 4G (LTE), and 5G.

     5G has revolutionized the way we connect, offering unprecedented
     throughput, low latency, and the capacity to handle a vast number of
     connected devices, thus driving innovation in the consumer market and
     various verticals such as healthcare, automotive, industrial
     automation, satellite and smart cities.  Unlike traditional networks
     that rely on point-to-point interfaces, the 5G core network has been
     designed as a cloud-native service-based architecture with network
     functions communicating each other using RESTful APIs over HTTP/2.
     These network functions can be deployed and managed dynamically,
     leveraging cloud technologies such as virtualization,
     containerization, and microservices.  This modularity allows for more
     agile, scalable, and efficient network operations.

     Whereas these existing standards are still being enhanced to meet the
     growing demands of the telecommunications industry, the 3GPP has
     already undertaken a deep exploratory work on the use cases, service
     requirements and system architecture for 6G.  This study phase will
     be then followed by a normative work to be completed by 2030 to meet
     ITU-R IMT 2030 timeline [M.2160].

     6G aims to support societal advancements and to bring value to
     society in the 2030s and beyond in secure, resilient, environmentally
     and economically sustainable ways.  In addition to new 6G services,
     other considerations are needed, e.g. CAPEX/OPEX reduction,
     improvement of overall 3GPP system performance, and migration from
     and interworking with 5G aspects.

     A study on service requirements and use cases for 6G is documented in
     the 3GPP Technical Report (TR) 22.870 [TR22.870].  While at an early
     stage and the document being still a work in progress, the current
     content of the report already provides useful insights on the
     potential foundation pillars of the new 6G system.  One of them being



  Stephan, et al.           Expires 23 April 2026                 [Page 3]


  Internet-Draft           Agent protocols for 6G             October 2025


     the Artificial Intelligence (AI) and how 6G could leverage AI and
     machine learning to enhance mobile network capabilities, service
     offering and user experience.

  2.  AI Agent related use cases in the context of 6G

  2.1.  General

     The recommendation ITU-R Recommendation M.2160-0 [M.2160] provides a
     comprehensive framework for the development of 6G technologies,
     focusing on the capabilities and objectives that these technologies
     should achieve around 2030 and beyond.  In this document, the
     integration of AI in telecommunications is poised to be a cornerstone
     for the development of 6G systems.  AI is considered as a
     foundational element, supporting both the network infrastructure and
     devices in delivering 3GPP services, often referred to as "AI for 6G
     system".  Additionally, mobile network capabilities are aimed to be
     enhanced and optimized for supporting AI applications, termed "6G
     system for AI".

     AI is not a novel concept within 3GPP, which has been actively
     engaged in standardizing AI and machine learning (ML) capabilities
     within 5G systems.  These efforts span various domains, including
     management and orchestration, core networks, and next-generation
     radio access networks (NG-RAN).  The objective is to boost system
     performance, efficiency, and the overall end-user experience.  This
     ongoing work is crucial not only for current 5G advancements but also
     sets a solid foundation for future 6G technologies.

     Beyond traditional AI/ML capabilities, 3GPP is exploring the
     integration of AI agents in 6G systems.  According to 3GPP TR 22.870
     [TR22.870], an AI agent is defined as follows:

     Al Agent:
        an automated intelligent entity that achieves a specific goal
        (autonomously or not) on behalf of another entity, by e.g.
        interacting with its environment, acquiring contextual
        information, reasoning, self-learning, decision-making, executing
        tasks (independently or in collaboration with other AI Agents).












  Stephan, et al.           Expires 23 April 2026                 [Page 4]


  Internet-Draft           Agent protocols for 6G             October 2025


     AI agents are anticipated to enhance network efficiency by
     dynamically optimizing resources, predicting network conditions, and
     ensuring seamless communication between services.  By incorporating
     large language models (LLMs), AI agents could interpret complex
     requests, convert them into actionable insights, and orchestrate
     advanced 3GPP services such as immersive communication, sensing, and
     computing services.  It is also expected that these agents would be
     able to communicate, coordinate, and cooperate with other agents to
     tackle tasks that a single agent would struggle with.

     In this context, communication between AI agents is expected to be
     pivotal in the 6G system, by enabling advanced network
     functionalities to enhance the existing capabilities of 5G networks,
     providing more efficient, reliable, and secure communication
     services.

     The 3GPP TR 22.870 [TR22.870] outlines various use cases and
     potential service requirements for AI agent communication protocols
     within the 6G framework.  Some of these use cases are provided in the
     following sections.  They are only provided for information and are
     subject to change till the completion of the study.

  2.2.  Network Optimization and Management

     *  AI-Driven Network Performance Assurance: AI agents in the 6G
        system should be collaborate to ensure an efficient network
        configuration and resource allocation to provide on-demand 3GPP
        services at a given time and location area based on the authorized
        third party request by intent, e.g. such as for major sporting
        events or concerts in mega venues, etc.  See clause 6.43 of 3GPP
        TR 22.870 [TR22.870].

     *  Predictive Maintenance: AI agents deployed in the 6G systems
        should be able to share information to predict potential network
        failures and perform preventive maintenance, reducing downtime and
        enhancing network reliability.  See clause 11.13 of 3GPP TR 22.870
        [TR22.870].

  2.3.  Immersive Communications

     *  Traffic Management: AI agents should be able to communicate with
        other agents and tools to analyze and predict traffic patterns,
        optimizing bandwidth allocation and ensuring high-quality service
        for users, especially in densely populated areas.  See clause 6.52
        of 3GPP TR 22.870 [TR22.870].






  Stephan, et al.           Expires 23 April 2026                 [Page 5]


  Internet-Draft           Agent protocols for 6G             October 2025


     *  Quality of Experience (QoE) Optimization: AI agents should be able
        to collaborate to monitor and adjust network parameters in real-
        time, enhancing the user experience for high-bandwidth
        applications like video streaming and virtual reality.  See clause
        6.54 of 3GPP TR 22.870 [TR22.870].

  2.4.  Hyper-Reliable Low-Latency Communications

     *  Real-Time Decision Making: AI agents should be able to facilitate
        real-time decision-making processes in critical applications such
        as autonomous driving, industrial automation, and remote surgery,
        where ultra-low latency and high reliability are crucial.  See
        clause 6.3 of 3GPP TR 22.870 [TR22.870].

     *  Fault Detection and Recovery: AI agents should be able to quickly
        detect and recover from faults, maintaining the high reliability
        required for critical applications.  See clause 6.53 of 3GPP TR
        22.870 [TR22.870].

  2.5.  Massive IoT Device Communications

     *  Device Management: AI agents distributed in the network (terminal,
        edge, core, etc.) should be able to collaborate to manage a large
        number of IoT devices, optimizing their connectivity and power
        consumption to extend battery life and improve network efficiency.
        See clause 6.45 of 3GPP TR 22.870 [TR22.870].

     *  Data Analytics: AI agents should be able to collaborate to share
        and analyze data from IoT devices to provide insights and support
        decision-making processes in various applications, such as smart
        cities, agriculture, and healthcare.  See clause 6.45 of 3GPP TR
        22.870 [TR22.870].

  2.6.  Security and Privacy

     *  Anomaly Detection: AI agents should be able to exchange
        information about anomalous behavior detection and potential
        security threats in real-time, enhancing the overall security of
        the network.  See clause 6.41 of 3GPP TR 22.870 [TR22.870].

     *  Privacy Preservation: AI agents should be able to implement and
        share privacy-preserving techniques to protect user data, maintain
        sensitive data within individual networks, and ensure compliance
        with regulatory requirements.

  2.7.  Autonomous Systems





  Stephan, et al.           Expires 23 April 2026                 [Page 6]


  Internet-Draft           Agent protocols for 6G             October 2025


     *  Autonomous Vehicles: Embedded AI agents should be able to
        communicate inside the same vehicle, between vehicles, between
        vehicles and the network for decision making based on environment
        perception, trajectory planning, and complex real-time control.
        See clause 6.3 of 3GPP TR 22.870 [TR22.870].

     *  Industrial Automation: AI agents should be able to communicate to
        optimize and control industrial processes, improving efficiency
        and reducing operational costs.  See clause 6.53 of 3GPP TR 22.870
        [TR22.870].

  2.8.  AI Agent Collaboration

     *  AI agent communication groups: Groups of User AI agents (AI
        assistant, drone, intelligent vehicle, home robot, etc.) could be
        dynamically created to allow the communication between AI agents
        to complete complex tasks requested by a user and/or between
        multiple user AI agent groups, owned by different users, across
        diverse locations ranging from local wireless networks to the wide
        area networks.  See clause 6.7 of 3GPP TR 22.870 [TR22.870].

     *  Intelligent Communication Assistants: Operators can advantageously
        provide Intelligent Communication Assistant services to their
        subscribers.  Intelligent Communication Assistant could understand
        user intention by collecting multi-modal data of the user and
        execute the user instructions by invoking other AI assistants and
        services provided by the 3rd party service provider.  See clause
        6.11 of 3GPP TR 22.870 [TR22.870].

  3.  Potential agent communications related requirements

  3.1.  General

     Agent communication in the context of AI and 6G networks involves
     several common requirements to ensure effective, efficient, and
     secure interactions between users and agents, between agents and
     between agents and tools.  Here is a list of potential key
     requirements derived from the illustrative use cases provided in the
     previous sections.  They are not yet formally approved by 3GPP and
     only provided for information/discussion.

  3.2.  Interoperability









  Stephan, et al.           Expires 23 April 2026                 [Page 7]


  Internet-Draft           Agent protocols for 6G             October 2025


  3.2.1.  Standardized Protocols

     Agents should be able to use standardized communication protocols to
     ensure they can interact seamlessly across different platforms and
     systems.  Agents should also support a standard protocol to interact
     with external data sources (e.g. user data repository) and AI-powered
     tools (e.g. location services) to complete their tasks.

  3.2.2.  Multimodal Data Formats

     Agents should be able to support multimodal data formats (e.g., text,
     file, real-time audio stream, video streaming) to facilitate easy
     data exchange and interpretation.

  3.2.3.  Agent Identity Management

     To allow the communication between users and agents as well as
     between agents and/or tools across platforms/domains, the system
     should support secure mechanisms for identification, verification and
     governance of agents/tools identities.

  3.3.  Discovery Mechanisms

     Robust and efficient AI agent and tool discovery mechanisms to
     dynamically identify and locate AI agents/tools across different
     platforms and organizations.  It should be possible to combine
     multiple discovery mechanisms depending on specific requirements and
     constraints of the application domain, e.g. broadcasting/
     multicasting-based mechanisms for intra-domain discovery and use of
     centralized directories for cross-domain discovery.

     Currently Service-Based Architecture (SBA) defines discovery as the
     process by which Network Functions (NFs) locate and select other NFs
     that provide required services.  This process is mediated by the
     Network Repository Function (NRF), which stores and exposes NF
     profiles containing service names, versions, and operational states.

     The emergence of AI functions including autonomous agents, inference
     services, and retrieval-augmented generation (RAG) components, intend
     based exchanges, or training challenges this model.  AI functions
     behave as both clients and servers within this ecosystem (but in 5G,
     almost every NF both exposes and consumes services too).  These
     entities behave as application-layer servers that expose capabilities
     such as reasoning, summarization, optimization, or prediction, and as
     clients when they consume telemetry, policy, or contextual
     information from the network.





  Stephan, et al.           Expires 23 April 2026                 [Page 8]


  Internet-Draft           Agent protocols for 6G             October 2025


     Supporting discovery for the various types of AI functions requires a
     broader analysis to identify solution-independent requirements.

  3.4.  Task Management

     AI agent communication should provide a robust and efficient task
     management to enable seamless coordination and collaboration among
     agents.  Task management includes task decomposition (complex tasks
     broken down into smaller sub-tasks that can be executed by individual
     agents or groups of agents), task assignment (based on agent
     capabilities, availability, workload), task scheduling, task
     coordination among agents and task monitoring/tracking.

  3.5.  Context Awareness

  3.5.1.  Contextual Understanding

     Agents should be aware of the context in which they operate,
     including the state of other agents and the environment, to make
     informed decisions.

  3.5.2.  Adaptive Communication

     Agents should be able to adapt the communication based on the context
     and current needs of the system.

  3.6.  Autonomy

  3.6.1.  Decision Making

     Agents should be capable of making autonomous decisions based on data
     analysis and reinforcement learning but also making collaborative
     decisions based on dynamic interaction between agents.

  3.6.2.  Self-Management

     Capabilities for self-management, including self-configuration, self-
     optimization, and self-healing based on information received from
     other agents.

  3.7.  Security










  Stephan, et al.           Expires 23 April 2026                 [Page 9]


  Internet-Draft           Agent protocols for 6G             October 2025


  3.7.1.  Authentication and Authorization

     The agent communications should support authentication mechanisms for
     agent identity verification and authorization mechanisms to grant or
     deny access to specific resources based on the authenticated agent's
     permissions or roles.  These mechanisms should be applicable for
     intra-domain and cross-domain scenarios.

  3.7.2.  Data Protection

     The agent communications should support encryption mechanism to
     protect sensitive data from unauthorized access, ensuring privacy and
     confidentiality.

  3.7.3.  User Consent

     The agent communication should provide mechanism to collect the user
     consent for the secure exchange of personal sensitive data with an AI
     agent (e.g. AI assistant) inside the network or 3rd-party application
     domain and between AI agents.

  3.8.  Low Latency Communication

     The agent communication should enable minimal delay data
     transmission, especially critical for real-time applications like
     industrial automation, robotics, or real-time gaming, to reduce lag
     and improve service experience.

  3.9.  Reliability

  3.9.1.  Fault Tolerance

     The agent communication should support mechanisms to detect, mitigate
     and recover from communication anomalies that would undermine
     collective decision making between agents.  These anomalies include
     message storms, communication deadlocks, protocol violations, or
     content inconsistencies.

  3.9.2.  Load Balancing

     Agent communication protocols should be able support load-balancing
     among agents to prevent any single agent from becoming a bottleneck
     and maintain continuous operation.








  Stephan, et al.           Expires 23 April 2026                [Page 10]


  Internet-Draft           Agent protocols for 6G             October 2025


  3.9.3.  Redundancy

     Redundancy mechanisms (e.g. active/passive redundancy, data
     redundancy, georedundancy) should be implemented to ensure high-
     reliability, resilience and service continuity even if one or several
     agents fail.

  3.10.  Flexibility

  3.10.1.  Scalability

     Agent communication protocols should be designed to accommodate
     increasing network sizes and data volumes without significant
     performance degradation, even during peak load events.

  3.10.2.  Adaptability

     Agent communication protocols should be able to adjust to multiple
     contexts (including heterogeneous agent capabilities, service
     environment, system requirements), multiple ways of transmitting
     information, including verbal, non-verbal, written, and visual forms,
     used individually or in combination, as well as the location of the
     AI agents (in the user terminal, in the network, in the 3rd party
     service environment).

  3.10.3.  Extensibility

     For onward compatibility, agent communication protocols should be
     able to evolve and adapt to new technologies and service requirements
     without requiring major overhauls.

  3.11.  Energy Efficiency

  3.11.1.  Optimized Communication

     Agent communication should support mechanisms to optimize
     communication between embedded AI agents to reduce energy
     consumption, especially important for battery-powered devices (e.g.
     IoT devices).

  3.11.2.  Power Management

     Agent communication should support efficient power management
     strategies to extend the operational life of devices embedding AI
     agents.






  Stephan, et al.           Expires 23 April 2026                [Page 11]


  Internet-Draft           Agent protocols for 6G             October 2025


  4.  Conclusions

     AI agents are envisioned to enhance network efficiency by dynamically
     optimizing resources, predicting network conditions, and facilitating
     seamless communication between services.  The incorporation of large
     language models (LLMs) will enable AI agents to understand complex
     requests and orchestrate advanced services, further enhancing the
     capabilities of 6G networks.

     AI agent communication is expected to play a crucial role in enabling
     advanced network functionalities.  The use cases outlined in 3GPP TR
     22.870 [TR22.870] demonstrate the potential of AI agent communication
     to enhance the existing capabilities of 5G networks, providing more
     efficient, reliable, and secure communication services.

     In summary, the integration of AI in 6G systems represents a
     significant advancement in telecommunications technology.  The
     ongoing work by 3GPP in standardizing AI capabilities and exploring
     the potential of AI agents highlights the transformative impact that
     AI is expected to have on future network infrastructures and
     services.

     If a multi-AI agent-based system is formally adopted by 3GPP in the
     scope of 6G, standard solutions will be required to support secure
     and reliable communication between agents and between agents and
     external tools.  These solutions will be used inside the 3GPP system
     but also with 3rd-party platforms.  It is then required to have
     solutions developed by standard organizations that would be widely
     adopted by the AI development community.  It is foreseen that IETF
     could be the right place to develop and maintain such standard
     protocols.  If such standardization work is eventually endorsed by
     IETF, a close coordination between IETF and 3GPP will be essential to
     ensure that any AI agent communication protocols specified by IETF
     will support specific functional and service requirements defined by
     3GPP in the 6G context.  And it is also expected that this work will
     be completed in a timely manner to cope with the challenging workplan
     defined by 3GPP for the development of a 6G system in the ITU-R IMT
     2030 framework [M.2160].

  5.  IANA Considerations

     This memo includes no request to IANA.

  6.  Security Considerations

     This document should not affect the security of the Internet.

  7.  References



  Stephan, et al.           Expires 23 April 2026                [Page 12]


  Internet-Draft           Agent protocols for 6G             October 2025


  7.1.  Informative References

     [TR22.870] 3GPP, "3GPP TR 22.870: Study on 6G Use Cases and Service
                Requirements; Stage 1 (Release 20)",
                <https://www.3gpp.org/ftp/Specs/archive/22_series/22.870>.

     [M.2160]   ITU-R, "Recommendation ITU-R M.2160-0: Framework and
                overall objectives of the future development of IMT for
                2030 and beyond", <https://www.itu.int/dms_pubrec/itu-
                r/rec/m/R-REC-M.2160-0-202311-I!!PDF-E.pdf>.

  Authors' Addresses

     Emile Stephan (editor)
     Orange
     2, avenue Pierre Marzin
     22300 Lannion
     France
     Email: emile.stephan@orange.com


     Roland Schott
     Deutsche Telekom
     Deutsche-Telekom-Allee 9
     64295 Darmstadt
     Germany
     Email: Roland.Schott@telekom.de


     Diego Lopez
     Telefonica
     Email: diego.r.lopez@telefonica.com


     Xiaodong Duan
     China Mobile
     Email: duanxiaodong@chinamobile.com


     Lionel Morand
     Huawei
     18 QUAI DU POINT DU JOUR
     92100 BOULOGNE-BILLANCOURT
     France
     Email: lionel.morand@huawei.com






  Stephan, et al.           Expires 23 April 2026                [Page 13]


name: draft-ni-wimse-ai-agent-identity
rev: 01
title: WIMSE Applicability for AI Agents
time: 2025-10-20T23:48:05Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T23:48:05Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:03.420450+00:00
abstract:
  This document discusses WIMSE applicability to Agentic AI, so as to
     establish independent identities and credential management mechanisms
     for AI agents.

full_text:
  Workload Identity in Multi System Environments                     Y. Ni
  Internet-Draft                                                 C. P. Liu
  Intended status: Informational                                    Huawei
  Expires: 23 April 2026                                   20 October 2025


                     WIMSE Applicability for AI Agents
                    draft-ni-wimse-ai-agent-identity-01

  Abstract

     This document discusses WIMSE applicability to Agentic AI, so as to
     establish independent identities and credential management mechanisms
     for AI agents.

  About This Document

     This note is to be removed before publishing as an RFC.

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ni-wimse-ai-agent-identity/.

     Discussion of this document takes place on the Workload Identity in
     Multi System Environments Working Group mailing list
     (mailto:wimse@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/wimse/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/wimse/.

  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 23 April 2026.







  Ni & Liu                  Expires 23 April 2026                 [Page 1]


  Internet-Draft                wime-ai-agent                 October 2025


  Copyright Notice

     Copyright (c) 2025 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.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Bootstrapping AI Agent Identity and Credentials . . . . .   4
       3.2.  Attestation . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Extensions to the WIMSE Architecture-- Binding Workload/AI
             Agent Identity to Its User Identity . . . . . . . . . . .   5
     5.  Comparison with CHEQ  . . . . . . . . . . . . . . . . . . . .   7
     6.  Initial Trust Establishment . . . . . . . . . . . . . . . . .   8
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
       9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     AI agents are autonomous software entities that receive an intent,
     process contextual information, and execute decisions at machine
     speed with minimal human intervention.  Without appropriate
     guardrails, they may give rise to significant risks:

     1.  Blurred Network Boundaries: AI agents may operate across systems
         and platforms, which expands attack surface and amplifies
         security risks.

     2.  Arbitrary and Unpredictable Access Patterns: AI agents may
         perform unexpected actions or access sensitive resources
         susceptible to malicious manipulation or logical errors.




  Ni & Liu                  Expires 23 April 2026                 [Page 2]


  Internet-Draft                wime-ai-agent                 October 2025


     3.  Lack of Accountability: Tracing an AI agent's actions is
         inherently difficult, leading to difficulty to detect erroneous
         behaviors.

     4.  Context Rot: A gradual degradation of their ability to maintain
         relevant and coherent call contexts over time.  Therefore, for AI
         agents, the traditional perimeter-based security model has to
         transform into the identity-based security model, which is a
         prequisite to implementing precise access control and ensuring
         security visibility.

     To realize this goal, a mechanism should be designed considering the
     following requirements:

     1.  Independent, Trustworthy Identities: AI agents should have
         independent and trustworthy identities and credentials, distinct
         from those of devices and users.  This allows the AI agent to act
         either on its own behalf or as a delegation of a user, have its
         own access tokens and workflows.

     2.  Automated Credential Management: An automated mechanism is
         necessary for managing credentials with reduced validity period
         to minimize security exposure.

     3.  Minimal Privileged Access Tokens: AI agents should have task-
         oriented, fine-grained access tokens with short validity periods.

     4.  Explicit Workflows: AI agents need explicit workflow management
         in order to avoid random agentic access.  The workflow could be
         long-termed and static, or could be short-termed and task-
         triggered, but the call context must always be visible and
         preserved.

     This document discusses possibility of using WIMSE architecture to
     provide AI agent identities and credentials.  It accords with the
     original WIMSE use case in Section 3.3.1 Bootstrapping Workload
     Identifiers and Credentials of [I-D.ietf-wimse-arch-06].  We also
     discuss requirements of extending WIMSE architecture to bind
     workload/AI agent identity to its user identity.

  2.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.




  Ni & Liu                  Expires 23 April 2026                 [Page 3]


  Internet-Draft                wime-ai-agent                 October 2025


     This document uses terms and concepts defined by WIMSE architecture.
     For a complete glossary please refer to [I-D.ietf-wimse-arch-06].

     1.  Trust Domain: A logical grouping of systems that share a common
         set of security controls and policies.  Agent credentials are
         issued under the authority of a trust domain.

     2.  AI Agent: The autonomous software entity that initiates the
         credential request.  This document may refer to it as the
         "agent", but is is essentially the workload instead of the agent
         in the WIMSE architecture.

     3.  Identity Server: A trusted entity issuing agent identity and
         credentials.  For simplicity, this document may refer to this
         component as the "server".

     4.  Identity Proxy: An intermediary component that can request,
         inspect, replace or augment agent identity credentials.  It
         exposes an Agent API locally to agents.  For simplicity, this
         document may refer to this component as the "proxy".

  3.  Architecture

  3.1.  Bootstrapping AI Agent Identity and Credentials

     This document presumes that the identity server has already been
     issued a signing certificate which has set keyCertSign in the key
     usage extension.  The server and the proxy are assumed to have
     established a secure channel.  A basic workflow is shown in Figure 1.

     1.  As an intermediary between the server and the agents, the proxy
         provides an agent API that agents can use to initiate identity
         credential requests.

     2.  The proxy forwards these requests, along with the evidence for
         verifing the operational status of the agent, to the server for
         processing.

     3.  The server validates the evidence received from the proxy, and
         issues the corresponding identity credentials.

     4.  Once issued, the proxy forwards the agent identity credentials.









  Ni & Liu                  Expires 23 April 2026                 [Page 4]


  Internet-Draft                wime-ai-agent                 October 2025


       +----------------------------+
       |                            |
       |       Identity Server      |
       |                            |
       +-------------- ^ + ---------+
                       | |
           (2)identity | |(3)identity
           credential  | | credential
           request &   | |
           evidence    | |
     +-----------------+-+-----------------------------------+
     |                 | | Trust Domain                      |
     |                 | |            (1)identity            |
     |                 | |            credential             |
     | +--------------++ v ---------+ request      +-------+ |
     | |              |             <--------------+       | |
     | |Identity Proxy|  Agent API  +--------------> Agent | |
     | |              |             | (4)identity  |       | |
     | +--------------+----- ^ -----+ credential   +-------+ |
     |                       |                               |
     |              evidence |                               |
     |                       |                               |
     +-----------------------+-------------------------------+
     |                                                       |
     |          Hosting Operating Systems and Hardware       |
     |                                                       |
     +-------------------------------------------------------+

     _Figure 1: Basic Architecture and the Workflow_

  3.2.  Attestation

     During the request and issuance of identity credentials, the proxy
     should gather attestation evidence from the operating system and
     hardware to verify the operational status of the agent.  This
     information is used by a RATS Verifier (could be the server) to
     decide whether or not to issue the identity credential of an agent,
     whether it is a bootstrapping or a renewal request.

  4.  Extensions to the WIMSE Architecture-- Binding Workload/AI Agent
      Identity to Its User Identity

     AI Agent identity has the full complexity of user identity, since
     agents may act on behalf of human, organization, etc.  Therefore,
     agent should have a credential that both denotes its identity and its
     human owner identity, which will provide convenience for future
     access controls.  Cryptographic assurances must be provided that the
     user approves the credential request.



  Ni & Liu                  Expires 23 April 2026                 [Page 5]


  Internet-Draft                wime-ai-agent                 October 2025


     Figure 2 illustrates the extended architecture, which binds user
     identity to agent identity.  This architecture extends the basic
     workflow described in Section 2.2.

     The core process remains largely unchanged from steps 1 to 4.
     However, a critical enhancement is introduced between steps 2 and 3:

     4.1.  Upon receiving an identity credential request, the server
     forwards it to the user on whose behalf the requesting agent acts.
     This initiates the user confirmation flow.  4.2.  The user validates
     the received information.  Upon approval, the user should provide a
     cryptographic signature, binding the user's identity to the requested
     agent credential.

     *Open Question*: How can users effectively provide cryptographic
     signatures for agent credential requests?  Is leveraging hardware
     security features in user devices a viable and practical approach?


































  Ni & Liu                  Expires 23 April 2026                 [Page 6]


  Internet-Draft                wime-ai-agent                 October 2025


                                      (4.1)identity
                                      credential
       +----------------------------+ request      +------+
       |                            +-------------->      |
       |       Identity Server      <--------------+ user |
       |                            |(4.2)user     |      |
       +-------------- ^ +----------+confirmation &+------+
                       | |           signature
           (2)identity | | (3)identity
           credential  | |  credential
           request &   | |
           evidence    | |
     +-----------------+-+-----------------------------------+
     |                 | | Trust Domain                      |
     |                 | |            (1)identity            |
     |                 | |            credential             |
     | +--------------++ v ---------+ request      +-------+ |
     | |              |             <--------------+       | |
     | |Identity Proxy|  Agent API  +--------------> Agent | |
     | |              |             | (4)identity  |       | |
     | +--------------+----- ^ -----+ credential   +-------+ |
     |                       |                               |
     |              evidence |                               |
     |                       |                               |
     +-----------------------+-------------------------------+
     |                                                       |
     |          Hosting Operating Systems and Hardware       |
     |                                                       |
     +-------------------------------------------------------+

     _Figure 2: Extended Architecture and the Workflow_

  5.  Comparison with CHEQ

     While both this document and CHEQ [I-D.draft-rosenberg-cheq-00]
     introduce a human element to enhance security, their goals and the
     underlying mechanisms are different.

     CHEQ focuses primarily on controlling the actions of AI agents.  It
     requires user double confirmation when an AI Agent invokes an OAuth
     access token request, preventing possible deviation from user
     expectations.

     The purpose of this document is to provide distinct identity and
     credentials to AI agents, whether or not it is bound to an owner user
     of device's parent identity.  Whether or not the agent inherits
     access permission privileges from its user is out of scope of this
     document.



  Ni & Liu                  Expires 23 April 2026                 [Page 7]


  Internet-Draft                wime-ai-agent                 October 2025


  6.  Initial Trust Establishment

     AI agents may operate in cloud or campus.  In the cloud, the initial
     trust establishment between the proxy and the server has already been
     solved by solutions like SPIRE.  However, in campus scenarios, the
     heterogeneity and limited manageability of devices make credential
     provisioning challenging, complicating initial trust establishment.

     BRSKI [RFC8995] provides a feasible method by introducing a
     cryptographically signed artifact called “voucher”.

     In the BRSKI flow, the proxy (acting as a BRSKI pledge) discovers the
     server (acting as a BRSKI registrar), initiates a TLS handshake, and
     sends a voucher request including its immutable manufacturer
     credential—the IDevID (Initial Device Identifier).  The server uses
     this IDevID to contact the manufacturer's service (MASA).  After
     validating the request, the MASA issues a signed voucher.

     The proxy then verifies the manufacturer's signature on the voucher,
     which securely transferring trust from the manufacturer to the local
     domain.  This verified trust is a prerequisite for the server to
     issue a local domain device certificate (LDevID).  This certificate
     enrollment step essentially follows the standard EST mechanism
     [RFC7030].

     However, it should be noted that BRSKI is not necessarily the only
     way to achieve this secure integration.  The core goal is to bridge
     the initial trust gap.  If the proxy is pre-configured with the
     target server's public key or certificate and can securely locate it,
     the standard EST protocol alone may be sufficient to establish trust
     and obtain the LDevID certificate.

     *Open Question:* What are the precise conditions and mechanisms for
     determining the use of various bootstrap methods (including but not
     limited to BRSKI and EST)?

  7.  Security Considerations

     TODO Security

  8.  IANA Considerations

     This document has no IANA actions.

  9.  References

  9.1.  Normative References




  Ni & Liu                  Expires 23 April 2026                 [Page 8]


  Internet-Draft                wime-ai-agent                 October 2025


     [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
                and K. Watsen, "Bootstrapping Remote Secure Key
                Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
                May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.

     [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
                "Enrollment over Secure Transport", RFC 7030,
                DOI 10.17487/RFC7030, October 2013,
                <https://www.rfc-editor.org/rfc/rfc7030>.

     [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/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

  9.2.  Informative References

     [I-D.ietf-wimse-arch-06]
                Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
                "Workload Identity in a Multi System Environment (WIMSE)
                Architecture", Work in Progress, Internet-Draft, draft-
                ietf-wimse-arch-06, 30 September 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
                arch-06>.

     [I-D.draft-rosenberg-cheq-00]
                Rosenberg, J., White, P., and C. F. Jennings, "CHEQ: A
                Protocol for Confirmation AI Agent Decisions with Human in
                the Loop (HITL)", Work in Progress, Internet-Draft, draft-
                rosenberg-cheq-00, 24 July 2025,
                <https://datatracker.ietf.org/doc/html/draft-rosenberg-
                cheq-00>.

  Acknowledgments

     TODO acknowledge.

  Authors' Addresses

     Yuan Ni
     Huawei
     Email: niyuan1@huawei.com





  Ni & Liu                  Expires 23 April 2026                 [Page 9]


  Internet-Draft                wime-ai-agent                 October 2025


     Chunchi Peter Liu
     Huawei
     Email: liuchunchi@huawei.com
















































  Ni & Liu                  Expires 23 April 2026                [Page 10]


name: draft-mao-rtgwg-agent-comm-protocol-gap-analysis
rev: 00
title: Gap Analysis for the Cross-device Communication Protocol for AI Agents in Network Devices
time: 2025-11-02T04:04:19Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T04:04:19Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Autonomous netops"]
tags: []
fetched_at: 2026-02-27T22:56:03.420453+00:00
abstract:
  With the development of large language models (LLM), AI Agent
     software continues to emerge.  AI agents deployed on different
     network devices need to collaborate to accomplish some complex tasks,
     such as network measurement and network troubleshooting.  This
     collaboration requires cross-device communication between AI agents.
     The cross-device communication framework is defined in
     [I-D.mzsg-rtgwg-agent-cross-device-comm-framework].

     This document describes whether some classical protocols in
     networking area, and some popular ones in AI Agent area can be used
     for the cross-device interaction of the AI agents in network devices,
     and analyzes the gaps.

full_text:
  Network Working Group                                             J. Mao
  Internet-Draft                                                   G. Zeng
  Intended status: Standards Track                                  B. Liu
  Expires: 5 May 2026                                              N. Geng
                                                                  X. Shang
                                                                    Q. Gao
                                                                     Z. Li
                                                       Huawei Technologies
                                                           1 November 2025


   Gap Analysis for the Cross-device Communication Protocol for AI Agents
                             in Network Devices
            draft-mao-rtgwg-agent-comm-protocol-gap-analysis-00

  Abstract

     With the development of large language models (LLM), AI Agent
     software continues to emerge.  AI agents deployed on different
     network devices need to collaborate to accomplish some complex tasks,
     such as network measurement and network troubleshooting.  This
     collaboration requires cross-device communication between AI agents.
     The cross-device communication framework is defined in
     [I-D.mzsg-rtgwg-agent-cross-device-comm-framework].

     This document describes whether some classical protocols in
     networking area, and some popular ones in AI Agent area can be used
     for the cross-device interaction of the AI agents in network devices,
     and analyzes the gaps.

  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 5 May 2026.





  Mao, et al.                Expires 5 May 2026                   [Page 1]


  Internet-Draft       Gap Analysis for Agent Protocol       November 2025


  Copyright Notice

     Copyright (c) 2025 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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Existing Protocols Gap Analysis . . . . . . . . . . . . . . .   3
       4.1.  Gap Analysis for A2A Protocol . . . . . . . . . . . . . .   4
       4.2.  Gap Analysis for MCP Protocol . . . . . . . . . . . . . .   5
       4.3.  Gap Analysis for GRASP Protocol . . . . . . . . . . . . .   5
     5.  Other Protocols Gap Analysis  . . . . . . . . . . . . . . . .   6
       5.1.  Gap Analysis for BGP Protocol . . . . . . . . . . . . . .   6
       5.2.  Gap Analysis for IS-IS Protocol . . . . . . . . . . . . .   6
       5.3.  Gap Analysis for OSPF Protocol  . . . . . . . . . . . . .   6
       5.4.  Gap Analysis for NETCONF Protocol . . . . . . . . . . . .   6
       5.5.  Gap Analysis for RESTCONF Protocol  . . . . . . . . . . .   6
       5.6.  Gap Analysis for gRPC Protocol  . . . . . . . . . . . . .   6
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
       8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     With the development of large language models (LLM), AI Agent
     software continues to emerge.  AI agents deployed on different
     network devices need to collaborate to accomplish some complex tasks,
     such as network measurement and network troubleshooting.  This
     collaboration requires cross-device communication between AI agents.
     The cross-device communication framework is defined in
     [I-D.mzsg-rtgwg-agent-cross-device-comm-framework]





  Mao, et al.                Expires 5 May 2026                   [Page 2]


  Internet-Draft       Gap Analysis for Agent Protocol       November 2025


     This document describes whether some classical protocols in
     networking area, and some popular ones in AI Agent area can be used
     for the cross-device interaction of the AI agents in network devices,
     and analyzes the gaps.

     Currently, network devices are able to exchange message with each
     other by some routing protocols (e.g. BGP, IS-IS, OSPF), or some
     signaling protocol (e.g. GRASP).  In addition, they can interact with
     network controller by NETCONF, RESTCONF and gRPC.

     In AI Agent area, some popular protocol is worth considering, such as
     A2A and MCP.


  2.  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
     appear in all capitals, as shown here.

  3.  Terminology

     A2A: Agent2Agent Protocol [a2a-link]

     MCP: Model Context Protocol [mcp-link]

     Device agent: The AI agents deployed in a network device.

     GRASP: GeneRic Autonomic Signaling Protocol [RFC8990]

  4.  Existing Protocols Gap Analysis

     Currently, network devices are able to exchange message with each
     other by some routing protocols (e.g. BGP, IS-IS, OSPF), or some
     signaling protocol (e.g. GRASP).  In addition, they can interact with
     network controller by NETCONF, RESTCONF and gRPC.

     In AI Agent area, there are some popular protocols, such as A2A for
     interaction between agents and MCP for the interaction between agents
     and outer systems.









  Mao, et al.                Expires 5 May 2026                   [Page 3]


  Internet-Draft       Gap Analysis for Agent Protocol       November 2025


  4.1.  Gap Analysis for A2A Protocol

     *  [Gap A01] The content of tasks in A2A protocol is typically
        described in natural language, and Message and Part objects of the
        text type in A2A protocol usually carry natural language text.
        That may require the deployment of large language models on
        network devices to parse the content of A2A request messages.
        However, deploying large models requires substantial AI computing
        capability, which current network devices cannot provide.  This
        suggests that a structured or semi-structured message format or
        data model may need to be designed.

     *  [Gap A02] The asynchronous notification mechanism of A2A, which
        can be used by a server to notify a client that a long-running
        task has been completed, requires the client to provide a separate
        listening port or service path as a webhook.  This extends the
        exposure surface of network devices and raises security risks.

     *  [Gap A03] The first method for A2A service discovery requires an
        agent to provide a well-known URL to enable other agents to obtain
        its Agent Card.  This increases the exposure surface of network
        devices and raises security risks.  In addition, A2A does not
        require the retrieval requests for Agent Card to be authenticated,
        which means that the information of network devices could be
        accessed by unauthorized users.  This suggests that new security
        mechanisms or service discovery methods may need to be designed to
        address these security risks.

     *  [Gap A04] The second method for A2A service discovery requires
        deploying a registry in the network to store the Agent Cards of
        all network devices.  This means that some network devices need to
        be selected or newly deployed, and configured to function as
        registries, similar to the BGP RR.  This would lead to significant
        storage pressure on the device and increase deployment costs.
        Alternatively, this would require upgrading the network controller
        to function as a registry, which would cause frequent requests for
        Agent Cards from devices to the controller, putting additional
        load on the controller.  If the Agent Cards are cached on the
        devices, there would also be issues of out-of-date cached data and
        increased storage pressure on the devices.

     *  [Gap A05] The third method for A2A service discovery requires
        configuring the Agent Cards of all other devices that will be
        accessed on the device itself.  This would significantly increase
        the amount of configuration data and the maintenance workload of
        the network, and also greatly increase the storage pressure on
        network devices.




  Mao, et al.                Expires 5 May 2026                   [Page 4]


  Internet-Draft       Gap Analysis for Agent Protocol       November 2025


     *  [Gap A06] A2A currently does not mandate a common transport
        protocol, which allows any of HTTPS-JSON-RPC 2.0, gRPC, or HTTPS-
        JSON (restful API) to be used.  This could actually lead to a
        situation where the agents in different network devices cannot
        communicate with each other because of using different transport
        protocols.  This suggests that a standardized transport protocol
        that must be implemented may need to be specified, with other
        transport protocols being optional.

     *  [Gap A07] A2A requires that all messages be transmitted over HTTPS
        (citation: MUST be HTTPS).  This means that each message needs to
        be encrypted or decrypted in network devices, which imposes
        additional performance overhead on the devices.

  4.2.  Gap Analysis for MCP Protocol

     *  [Gap M01] MCP is typically used by agents to call external systems
        and is architecturally a north-south interface.  However, the
        relationship among device agents is more like a "peer", similar to
        BGP peer and IS-IS peer.  Their interaction may require an east-
        west interface.  Nevertheless, from the perspective of information
        transfer and function calling, MCP is also worth considering in
        the scenario of the interaction of device agents.

     *  [Gap M02] MCP only supports JSON text as the data encoding format,
        which is less efficient in terms of information transmission and
        parsing compared to binary data encoding formats.  This will
        consume more CPU time on devices for data serialization and
        deserialization, and occupy more bandwidth to exchange messages.

     *  [Gap M03] MCP allows the use of HTTP protocol stacks that support
        server-sent events (SSE) and streaming.  The protocol stacks of
        network devices may need to be upgraded accordingly.  If devices
        only support traditional request-response communication, some
        future functionalities may be limited or impossible to implement.

     *  [Gap M04] The names and descriptions of MCP tools are in natural
        language, which may require deploying large language models on
        network devices to understand the functions of each tool.
        Currently, the processing capabilities of network devices may be
        insufficient to meet this requirement.  It may be necessary to
        define a standardized, structured description format or define a
        standardized tool ID.

  4.3.  Gap Analysis for GRASP Protocol

     TBD




  Mao, et al.                Expires 5 May 2026                   [Page 5]


  Internet-Draft       Gap Analysis for Agent Protocol       November 2025


  5.  Other Protocols Gap Analysis

     There are some classical protocols which have been well supported by
     network devices.  If they are going to be used in the scenario of the
     interaction of device agents, their mechanisms may need to be
     enhanced, and some data schemas/models may need to be extended or
     newly defined.

     On the other hand, if network devices have basic natural language
     understanding capability, the data model may be designed as a semi-
     structured format.


  5.1.  Gap Analysis for BGP Protocol

     TBD

  5.2.  Gap Analysis for IS-IS Protocol

     TBD

  5.3.  Gap Analysis for OSPF Protocol

     TBD

  5.4.  Gap Analysis for NETCONF Protocol

     TBD

  5.5.  Gap Analysis for RESTCONF Protocol

     TBD

  5.6.  Gap Analysis for gRPC Protocol

     TBD

  6.  IANA Considerations

     This document does not include an IANA request.

  7.  Security Considerations

     TBD


  8.  References




  Mao, et al.                Expires 5 May 2026                   [Page 6]


  Internet-Draft       Gap Analysis for Agent Protocol       November 2025


  8.1.  Normative References

     [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>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/info/rfc8126>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  8.2.  Informative References

     [a2a-link] "Agent2Agent Protocol", 30 October 2025,
                <https://a2a-protocol.org/>.

     [I-D.mzsg-rtgwg-agent-cross-device-comm-framework]
                Mao, J., Zeng, G., Liu, B., Geng, N., Shang, X., Gao, Q.,
                and Z. Li, "Cross-device Communication Framework for AI
                Agents in Network Devices", Work in Progress, Internet-
                Draft, draft-mzsg-rtgwg-agent-cross-device-comm-framework-
                01, 1 November 2025,
                <https://datatracker.ietf.org/doc/html/draft-mzsg-rtgwg-
                agent-cross-device-comm-framework-01>.

     [mcp-link] "Model Context Protocol", 30 October 2025,
                <https://modelcontextprotocol.io/>.

     [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
                Autonomic Signaling Protocol (GRASP)", RFC 8990,
                DOI 10.17487/RFC8990, May 2021,
                <https://www.rfc-editor.org/info/rfc8990>.

  Authors' Addresses

     Jianwei Mao
     Huawei Technologies
     Beijing
     100095
     China
     Email: MaoJianwei@huawei.com





  Mao, et al.                Expires 5 May 2026                   [Page 7]


  Internet-Draft       Gap Analysis for Agent Protocol       November 2025


     Guanming Zeng
     Huawei Technologies
     Email: zengguanming@huawei.com


     Bing Liu
     Huawei Technologies
     Email: leo.liubing@huawei.com


     Nan Geng
     Huawei Technologies
     Email: gengnan@huawei.com


     Xiaotong Shang
     Huawei Technologies
     Email: shangxiaotong@huawei.com


     Qiangzhou Gao
     Huawei Technologies
     Email: gaoqiangzhou@huawei.com


     Zhenbin Li
     Huawei Technologies
     Email: robinli314@163.com























  Mao, et al.                Expires 5 May 2026                   [Page 8]


name: draft-zheng-agent-identity-management
rev: 00
title: Agent Identity Managenment
time: 2025-11-02T04:19:56Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T04:19:56Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:03.420455+00:00
abstract:
  This document specifies agent identity management in the Internet of
     Agents (IOA) system.  It defines the descriptive requirements for
     agent identities, the agent registration process, the structure and
     assignment of agent identifiers, and the basic and extended identity
     management functions performed by the agent gateway based on the
     agent's descriptive information.

full_text:
  artarea                                                         C. Zheng
  Internet-Draft                                                    B. Liu
  Intended status: Standards Track                     Huawei Technologies
  Expires: 6 May 2026                                              N. Geng
                                                                    Huawei
                                                                    Q. Gao
                                                                  X. Shang
                                                                     Z. Li
                                                       Huawei Technologies
                                                           2 November 2025


                         Agent Identity Managenment
                  draft-zheng-agent-identity-management-00

  Abstract

     This document specifies agent identity management in the Internet of
     Agents (IOA) system.  It defines the descriptive requirements for
     agent identities, the agent registration process, the structure and
     assignment of agent identifiers, and the basic and extended identity
     management functions performed by the agent gateway based on the
     agent's descriptive information.

  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 May 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.






  Zheng, et al.              Expires 6 May 2026                   [Page 1]


  Internet-Draft         Agent Identity Managenment          November 2025


     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
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  Overview of the Agent Identity Management . . . . . . . . . .   3
     3.  Agent description Requirements  . . . . . . . . . . . . . . .   4
       3.1.  Basic Information . . . . . . . . . . . . . . . . . . . .   4
       3.2.  Extended Information  . . . . . . . . . . . . . . . . . .   6
     4.  Agent Identity Registration . . . . . . . . . . . . . . . . .   7
     5.  Agent Identity management . . . . . . . . . . . . . . . . . .   7
       5.1.  Agent Identifier  . . . . . . . . . . . . . . . . . . . .   8
       5.2.  Agent Identity Basic Managenment  . . . . . . . . . . . .   9
       5.3.  Agent Identity Extended Management  . . . . . . . . . . .  10
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     8.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     As intelligent agents become increasingly prevalent in distributed
     and interoperable systems, robust identity management is essential to
     ensure secure, scalable, and policy-compliant operation.  In the
     Internet of Agents (IOA) system, agents—ranging from simple
     automation scripts to high-intelligence autonomous entities—must be
     uniquely identified, authenticated, and governed throughout their
     lifecycle.

     This document outlines the foundational framework for agent identity
     management in the IOA system.  It specifies the required descriptive
     attributes of an agent, the registration process with the agent
     gateway, the format and semantics of agent identifiers, and the basic
     and extended management capabilities enabled by the agent’s identity
     metadata.  While security mechanisms such as authentication protocols
     and cryptographic binding are acknowledged as critical, their
     detailed specification is considered out of scope for this document.






  Zheng, et al.              Expires 6 May 2026                   [Page 2]


  Internet-Draft         Agent Identity Managenment          November 2025


  1.1.  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  Overview of the Agent Identity Management

     The agent identity management architecture in the IOA system
     comprises four core functional modules: Agent Description, Agent
     Identity Registration, Agent Identity Management, and Security
     Considerations.  First, an agent's identity information MUST be
     represented in a normalized form.  The agent then registers this
     normalized identity description with an Agent Gateway.  Upon
     successful authentication of the registering agent, the Agent Gateway
     assigns a unique Agent ID to the agent and, using the Agent ID as a
     key, enforces identity management policies based on the agent's
     normalized identity description.































  Zheng, et al.              Expires 6 May 2026                   [Page 3]


  Internet-Draft         Agent Identity Managenment          November 2025


                    Agent Gateway
                    +-------------------------------------------+
                    |                                           |
                    | +-------------------------------------+   |
          /---------+-|          Identity Management        |<--+----------\
          |         | +++-----------------------------------+   |          |
          |         |  ||   +--------------------------+        |          |
          |         |  ||-->|Agent ID:Basic Managemnt  |        |          |
          |         |  |    +--------------------------+        |          |
          |         |  |   +---------------------------+        |          |
          |         |  |--->|Agent ID:Basic Managemnt  |        |          |
          |         |       +--------------------------+        |          |
          |         +-------------------------------------------+          |
          |                                                                |
          |<----------------Agent Identity Registion---------------------->|
          |                                                                |
          |        Agent                                                   |
          |         +----------------------------+                         |
          |         | +----------------------+   |                         |
          |         | |      Description     |---+-------------------------/
          |         | +++--------------------+   |
          |         |  ||  +-----------------+   |
          |         |  ||->|Basic Information|   |
          |         |  |   +-----------------+   |
          |         |  |   +------------------+  |
          |         |  |-->|Extend Information|  |
          |         |      +------------------+  |
          |         |                            |
          |         |      +-----------------+   |
          \---------+----->|    Agent ID     |   |
                    |      +-----------------+   |
                    +----------------------------+

             Figure 1: Agent identity management architecture

  3.  Agent description Requirements

     To enable accurate agent identity management on the agent gateway, it
     is necessary to define a set of essential information elements for
     describing an agent.

  3.1.  Basic Information

     The agent description MUST include the following base information
     elements:

     *  Agent name




  Zheng, et al.              Expires 6 May 2026                   [Page 4]


  Internet-Draft         Agent Identity Managenment          November 2025


     *  Agent capabilities/skills

     *  Agent author

     *  Agent version

     *  Agent creation time

     *  Agent description model version

     *  Agent location

     *  Agent communication protocol

     *  Agent description (human-readable)

     *  Agent signature

     In addition, the following attributes MUST also be included as part
     of the base information:

     *  Agent validity period

     *  Agent form factor

     *  Agent intelligence level

     *  Agent extended profile URI

     *  Agent role

     *  Translation enablement indicator

     Usecases

     *  Agent validity period: The validity period of an agent on the
        agent gateway specifies the time interval during which the agent
        is considered active and authorized for operation.  The agent
        gateway MAY use this field to enforce publication and maintenance
        policies, automatically deactivating or removing expired or stale
        ("zombie") agents to reduce operational overhead and minimize the
        burden of agent lifecycle management.









  Zheng, et al.              Expires 6 May 2026                   [Page 5]


  Internet-Draft         Agent Identity Managenment          November 2025


     *  Agent form factor: The form of the agent, such as digital agent or
        embodied agent.  The form field can support the interconnection of
        heterogeneous forms of agents in future IOA systems.  For example,
        agent gateways may have different requirements for access
        authentication and policy control for agents of different forms.
        Communication protocols between agents of different forms may also
        differ.

     *  Agent intelligence level: The intelligence level of an agent can
        be defined using mainstream AI agent intelligence classification
        standards in the future.  This will help application agents to
        select the final communication target among a group of candidate
        agents based on the required intelligence level.  For example,
        when agents have the same capabilities, the one with a higher
        intelligence level can be chosen.

     *  Agent extended profile URI: The address accessible for the
        extended version of the agent.  It helps to continuously and
        dynamically upgrade and update the agent during its online period
        on the extended version address.

     *  Agent role: The roles of agents include two types: consumer and
        producer.  An agent can also assume both roles.  This helps the
        agent gateway determine whether to establish a short connection or
        a long connection with the agent.  It also assists the gateway in
        formulating control strategies when publishing agent information
        on the network, for example, by not publishing information for
        consumers who do not provide services.

     *  Translation enablement indicator: This field describes whether the
        agent message allows the gateway to perform message translation.
        It helps the agent gateway to translate heterogeneous protocol
        communications between agents while respecting the agent's
        preferences.  For example, in scenarios where semantic translation
        might occur, the agent can use this field to protect its data
        privacy.

  3.2.  Extended Information

     The agent description SHOULD include the following extended
     information elements:

     *  Network requirements

     *  Trust level

     *  Extension




  Zheng, et al.              Expires 6 May 2026                   [Page 6]


  Internet-Draft         Agent Identity Managenment          November 2025


     Usecases

     *  Network requirements: The requirements of agents for the network
        include three aspects: experience, monitoring, and security.
        These help the agent gateway implement on-demand QoS guarantee
        strategies (e.g., low latency assurance or high bandwidth
        assurance), security assurance strategies (e.g., path security,
        quantum encryption for communication), and agent task monitoring
        and maintenance strategies (e.g., agent task flow measurements at
        the stream level, packet level, segment level, and etc.).

     *  Trust level: The agent's permission scope defines the boundaries
        of its authorized operations and data access.  This attribute
        enables the agent gateway to enforce fine-grained access control
        policies—for example, restricting agent data from leaving a
        specific administrative domain such as a campus or a
        country—thereby supporting regulatory compliance and data
        sovereignty requirements.

     *  Extension: An extensible information field is provided as a
        reserved mechanism to accommodate future dynamic attributes of the
        agent.

  4.  Agent Identity Registration

     The agent MUST register its descriptive information with the agent
     gateway to enable the gateway to perform identity management based on
     this description.  The specific registration interaction protocol
     between the agent and the gateway is outside the scope of this draft.

     Upon receiving an agent's registration information, the agent gateway
     MUST first perform identity authentication.  The specific
     authentication mechanism is outside the scope of this document.
     Following successful authentication, the gateway proceeds to the next
     step of agent identity management.

  5.  Agent Identity management

     The agent gateway MUST first assign a unique identifier to the agent.
     Using this identifier as a key, the gateway can perform both basic
     and extended identity management functions by correlating it with the
     agent's descriptive information.









  Zheng, et al.              Expires 6 May 2026                   [Page 7]


  Internet-Draft         Agent Identity Managenment          November 2025


  5.1.  Agent Identifier

     The agent identifier (agent ID) is used to uniquely represent an
     agent within the IOA system.  Specific approaches for constructing
     this identifier MAY employ a hierarchical string scheme (e.g.,
     incorporating domain, subdomain, and instance components) or
     alternatively use a standardized encoding of such a hierarchical
     string (e.g., via URI, UUID, or other IETF-recognized identifier
     formats) to ensure global uniqueness, interoperability, and ease of
     parsing.

     Below is an example definition of an agent identifier in the form of
     a hierarchical string:

     orgtype:org/internal enterprise namespace/client-id

     Where:

     *  orgtype indicates the standardized type or schema that the org
        field conforms to.  This enables consistent interpretation and
        validation of the organizational context associated with the
        agent, such as whether the organization is identified according to
        a public registry (e.g., PENs for orgnizations [RFC9371]), or
        another recognized naming authority.

     *  org field identifies the enterprise or organization to which the
        agent belongs, in accordance with the standard specified by the
        orgtype field.This ensures that the organizational identifier is
        interpreted consistently and unambiguously according to the
        referenced naming scheme or registry.

     *  internal enterprise namespace is defined and managed autonomously
        by the enterprise itself.  It provides a private, organization-
        specific naming scheme for identifying agents, organizational
        units, or other entities within the enterprise’s administrative
        domain, without reliance on external registries or global
        standards.

     *  client-id serves as a locally unique identifier for the agent
        within its administrative or operational domain.  It MAY be
        assigned by the agent gateway upon registration, or alternatively
        issued by a Certificate Authority (CA) during the agent identity
        signing process, ensuring uniqueness and cryptographic binding to
        the agent’s identity credentials.







  Zheng, et al.              Expires 6 May 2026                   [Page 8]


  Internet-Draft         Agent Identity Managenment          November 2025


  5.2.  Agent Identity Basic Managenment

     Based on the base information contained in the agent description, the
     agent gateway can perform fundamental identity management functions
     using the agent ID as the primary key.

     Agent ID : Basic Management functions

     These functions include, but are not limited to:

     *  Identity verification management: validating the authenticity and
        integrity of the agent using attributes such as name, signature,
        and author.

     *  Capability classification management: categorizing agents
        according to their declared skills/capabilities for policy-based
        routing or service matching.

     *  Communication protocol management: enforcing or negotiating
        supported communication protocols to ensure interoperability.

     *  Lifecycle management: tracking and controlling the agent’s
        operational state (e.g., creation, activation, expiration,
        revocation) based on attributes such as creation time and validity
        period.

     *  Form factor classification management: grouping agents by their
        form (e.g., embedded, digital) for resource allocation or policy
        application.

     *  Intelligence level management: applying differentiated handling
        policies based on the agent’s declared intelligence level.For
        example, the agent gateway MAY apply behavior monitoring policies
        of varying intensity based on the agent's declared intelligence
        level, thereby preventing high-intelligence agents from performing
        unauthorized or out-of-scope actions.

     *  Extended profile management: referencing and validating the
        agent’s extended profile URI for dynamic or context-specific
        attributes.

     *  Role-based classification management: assigning or enforcing
        permissions and behaviors according to the agent’s declared role.

     *  Communication translation management: enabling or disabling
        protocol or semantic translation based on the translation
        enablement indicator.




  Zheng, et al.              Expires 6 May 2026                   [Page 9]


  Internet-Draft         Agent Identity Managenment          November 2025


     These management functions collectively support scalable, secure, and
     policy-compliant operation of agents within the IOA system.

  5.3.  Agent Identity Extended Management

     By leveraging the extensible information included in the agent
     description, the agent gateway can perform enhanced identity
     management functions beyond the base set.

     Agent ID : Extended Management functions

     These extended management functions include:

     *  Agent network service management: dynamically provisioning,
        monitoring, or orchestrating network services associated with the
        agent (e.g., QoS requirements, connectivity policies, security
        assurance, and etc.).

     *  Agent permission management: enforcing fine-grained, context-aware
        access control policies based on extended permission scopes, such
        as data residency constraints (e.g., "data must not leave the
        campus or country").

     *  Future extensible identity management functions: supporting
        additional identity-related features that may be defined in future
        specifications, such as behavioral attestation, perfermence
        scoring, or integration with decentralized identity frameworks.

     The extensible information field is designed to be forward-
     compatible, enabling the agent gateway to adapt to evolving
     operational, regulatory, or architectural requirements without
     requiring changes to the core agent description model.

  6.  Security Considerations

     Security is a critical consideration in agent identity management.
     This includes authenticating and validating the agent’s identity
     during registration, ensuring the integrity and non-repudiation of
     the agent identifier (e.g., to prevent tampering or spoofing), and
     enforcing access control policies for agent onboarding and
     interaction.  However, the specific security mechanisms and detailed
     considerations related to these aspects are outside the scope of this
     document.

  7.  IANA Considerations

     TBD




  Zheng, et al.              Expires 6 May 2026                  [Page 10]


  Internet-Draft         Agent Identity Managenment          November 2025


  8.  Normative References

     [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>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  Authors' Addresses

     Chong Zheng
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: zhengchong6@huawei.com


     Bing Liu
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: leo.liubing@huawei.com


     Nan Geng
     Huawei
     Beijing
     China
     Email: gengnan@huawei.com


     Qiangzhou Gao
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: gaoqiangzhou@huawei.com









  Zheng, et al.              Expires 6 May 2026                  [Page 11]


  Internet-Draft         Agent Identity Managenment          November 2025


     Xiaotong Shang
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: shangxiaotong@huawei.com


     Zhenbin Li
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: robinli314@163.com





































  Zheng, et al.              Expires 6 May 2026                  [Page 12]


name: draft-ni-a2a-ai-agent-security-requirements
rev: 00
title: Security Requirements for AI Agents
time: 2025-11-02T04:27:53Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T04:27:53Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:03.420457+00:00
abstract:
  This document discusses security requirements for AI agents, covering
     different stages of security interactions.  These include
     provisioning, registration, cross-domain interconnection, and access
     control.

full_text:
  agent2agent                                                        Y. Ni
  Internet-Draft                                                 C. P. Liu
  Intended status: Informational                                   N. Geng
  Expires: 6 May 2026                                               Q. Gao
                                                                  Z. R. Li
                                                                    Huawei
                                                           2 November 2025


                    Security Requirements for AI Agents
               draft-ni-a2a-ai-agent-security-requirements-00

  Abstract

     This document discusses security requirements for AI agents, covering
     different stages of security interactions.  These include
     provisioning, registration, cross-domain interconnection, and access
     control.

  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 May 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.











  Ni, et al.                 Expires 6 May 2026                   [Page 1]


  Internet-Draft         agent-security-requirements         November 2025


     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.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Provisioning and Registration . . . . . . . . . . . . . . . .   4
       3.1.  Identity Provisioning and Management  . . . . . . . . . .   5
       3.2.  Agent Registration  . . . . . . . . . . . . . . . . . . .   6
       3.3.  Agent Onboarding  . . . . . . . . . . . . . . . . . . . .   6
     4.  Cross-Domain Interconnection  . . . . . . . . . . . . . . . .   6
       4.1.  Cross-Domain Identifier Interoperability  . . . . . . . .   6
       4.2.  Secure Cross-Domain Transmission  . . . . . . . . . . . .   7
       4.3.  Authenticating External Calls . . . . . . . . . . . . . .   7
       4.4.  IAM Integration . . . . . . . . . . . . . . . . . . . . .   7
     5.  Access Control  . . . . . . . . . . . . . . . . . . . . . . .   7
       5.1.  Authorization Handling  . . . . . . . . . . . . . . . . .   8
       5.2.  Authorization Chaining Across Domains . . . . . . . . . .   8
       5.3.  Converting to Internal Workflow . . . . . . . . . . . . .   8
       5.4.  Interoperability for Heterogeneous Systems  . . . . . . .   9
       5.5.  Zero Trust Analysis . . . . . . . . . . . . . . . . . . .   9
       5.6.  Microsegmentation . . . . . . . . . . . . . . . . . . . .  10
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     With the widespread application of agentic AI technology across
     various business scenarios, its security issues have become
     increasingly prominent.

     This document aims to provide an architecture addressing security
     requirements across different stages of interactions of Agentic AI
     use cases.  These includes provisioning, registration, cross-domain
     interconnection, and access control.  This document establishes a
     starting point to guide Agentic AI security design, development, and
     implementation consideration discussions.



  Ni, et al.                 Expires 6 May 2026                   [Page 2]


  Internet-Draft         agent-security-requirements         November 2025


  2.  Architecture

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

                      +----------------+
                      |  Master Agent  |
                      +-^--------------+
                      +-+--------------+
                      | |  Firewall    |
                      +-+--------------+
                        |
     -------------- (2) | Inter-domain--------------
                        |
     +------------------+---------------------------------+
     |                +-+--------------+   Intra-domain   |
     |                | |  Firewall    |                  |
     |                +-+--------------+                  |
     |                +-v--------------+                  |
     |        +-------+  Master Agent  |                  |
     |   (3)  |       +----------------+                  |
     |        |                              (1)          |
     |   +----v-----+    +----------+    +----------+     |
     |   |  Agent   +---->  Agent   +---->  Agent   |     |
     |   +----+-----+    +----------+    +----+-----+     |
     |        |                               |           |
     |     +--v---------+           +---------v---+       |
     |     |    DB      |           |     API     |       |
     |     +------------+           +-------------+       |
     +----------------------------------------------------+

     _Figure 1.  Architecture of Agent Security Control and Management_

     The architecture of agent security control and management is
     illustrated in Figure 1.  There are four types of security
     interactions, in a sequential order:

     1.  Provisioning and Registration: Creating agent identity,
         establishing initial trust, provisioning agent secrets and
         credentials.

     2.  Cross-domain Interconnection: Enabling secure, authenticated
         communication between agents across different trust domains.





  Ni, et al.                 Expires 6 May 2026                   [Page 3]


  Internet-Draft         agent-security-requirements         November 2025


     3.  Access Control: The Master Agent validates both intra-domain and
         inter-domain access tokens, creates internal workflow and manages
         different credentials for heterogeneous systems.

     Therefore, the architecture includes four components:

     1.  Firewall: A network security device designed to monitor, filter,
         and control incoming and outgoing network traffic based on
         predetermined security rules.

     2.  Master Agent: The central orchestrating entity that manages
         multi-agent operations, including cross-domain communication,
         workflow coordination, credential management, and security policy
         management.

     3.  Agents: Autonomous software entities deployed in various domains
         to perform specific tasks.

     4.  Heterogeneous systems: API endpoints, microservices, tools, and
         databases.

  3.  Provisioning and Registration

     Figure 2 shows the diagram of provisioning and registration, which
     includes Agent Certificate Authority(ACA) and Agent Registry
     Service(ARS):

     1.  ACA (Agent Certificate Authority): A trusted third party that
         issues and manages credentials for agents.

     2.  ARS (Agent Registry Service): A system responsible for agent
         identity registration and discovery-matching.



















  Ni, et al.                 Expires 6 May 2026                   [Page 4]


  Internet-Draft         agent-security-requirements         November 2025


     +-------------------------------------------+
     |                                           |
     | +-----------------+  +------------------+ |
     | |Agent Certificate|  |  Agent Registry  | |
     | |Authority(ACA)   |  |  Service(ARS)    | |
     | +--------^--------+  +---------^--------+ |
     |          |                     |          |
     |         ++---------------------++         |
     |         ||     +----------+    ||         |
     |         |+----->   Agent  +----+|         |
     |         |      +----------+     |         |
     |         |                       |         |
     |         |   device/container    |         |
     |         +-----------------------+         |
     |                                           |
     +-------------------------------------------+

     _Figure 2.  Diagram for Provisioning and Registration_

  3.1.  Identity Provisioning and Management

     Identity provisioning and management are the process of creating and
     assigning a verifiable digital identity to an agent.

     *  Initial Trust Establishment: Intial trust can be established
        through one or more of the following trust anchors, including, but
        are not limited to: a manufacturer-embedded immutable credential
        like an IDevID certificate; a hardware root of trust like a
        Trusted Platform Module (TPM) or Hardware Security Module (HSM);
        identity documents like an AWS Instance Identity Document or an
        Azure Managed Service Identity token.  This step verifies the
        agent's execution environment (device, container, etc.) as
        trustworthy, allows the device or container to join the network,
        thereby enabling secure operations for all subsequent steps.

     *  Credential Request: During a credential request, the agent must
        provide multiple proofs of its legitimacy, such as a Certificate
        Signing Request or a Proof of Possession by signing with the
        corresponding private key, as well as remote attestation by
        collecting and submitting evidence to a RATS (Remote Attestation
        Procedures) Verifier.  Additionally, to define the agent's
        operational scope, the request should incorporate user identity
        context, binding the credential to a specific human user or an
        organizational role.







  Ni, et al.                 Expires 6 May 2026                   [Page 5]


  Internet-Draft         agent-security-requirements         November 2025


     *  Credential Issuarance: The ACA validates proofs and requests from
        the above two steps, if passed, it issues an agent-specific
        credential that may include its owner or requester identity,
        capabilities, locator, acceptable validation methods for the ARS.

     *  Credential Lifecycle Mangement: The ACA not only issues
        credentials but also defines and enforces revocation policies.
        These policies are triggered by specific events, such as a
        detected security compromise, the agent's scheduled
        decommissioning, or a key rotation.

  3.2.  Agent Registration

     After receiving a credential from the ACA, the agent then sends it to
     the ARS to authenticate itself and start the registration process.

     *  Authentication: The ARS must verify the legitimacy of the
        credential submitted by the agent.  It must be signed or otherwise
        endorsed by the ACA.

     *  Registration: The ARS then checks if the information signed by the
        ACA, such as the agent's capabilities, exactly matches the
        registration request sent by the agent.  Upon successful
        validation, the ARS assigns the agent a unique identifier and
        establishes an agent record that links the identifier to its
        attributes.

     *  Record Management: This step automatically removes expired
        credentials and synchronizes with the ACA to ensure timely
        revocation of credentials, preventing the use of invalid or
        compromised credentials.

  3.3.  Agent Onboarding

     Agent onboarding differs between campus and cloud environments.  On
     campus, agents use protocols like EAP-TLS for network access.  In the
     cloud, the process involves injected sidecars, which register agents
     to the central service mesh registry automatically to enable
     communication and management.

  4.  Cross-Domain Interconnection

  4.1.  Cross-Domain Identifier Interoperability

     Different domains may use distinct identifier schemas.  Possible
     methods include:

     *  pre-configured schema translation



  Ni, et al.                 Expires 6 May 2026                   [Page 6]


  Internet-Draft         agent-security-requirements         November 2025


     *  cross-domain identifier synchronization

     *  a universal parsing framework or system

  4.2.  Secure Cross-Domain Transmission

     Mutual TLS (mTLS) connection starts from the external requesting
     agent to the master agent.  The master agent terminates the mTLS
     connection and parses the application layer requests.  In this case,
     the master agent functions as an OAuth resource server, and manages
     internal task orchestration.

  4.3.  Authenticating External Calls

     The master agent then verifies the identity of the requesting agent,
     and whether or not it has permission to the requested service or
     agent.  Different authentication methods might be possible:

     *  API keys

     *  Username-password

     *  Pre-shared secrets

     *  Assertions (for example, JWT Authorization
        Grant[I-D.draft-ietf-oauth-identity-chaining-06])

     which can even be combined with AND/OR logic.  During this process,
     the master agent might be able to identify the caller endpoint type:

     *  human user via browser or app

     *  human user via API

     *  AI agents

     *  Hardware or equipment via an IoT API

  4.4.  IAM Integration

     Since the agent may inherit its access rights from its owner or user,
     when authenticating requests, the validation might require
     integration of IAM systems for redirected verification.

  5.  Access Control






  Ni, et al.                 Expires 6 May 2026                   [Page 7]


  Internet-Draft         agent-security-requirements         November 2025


  5.1.  Authorization Handling

     The master agent acts as the role of OAuth 2.1 resource server.  It
     must validate access tokens as described in OAuth 2.1 Section 5.2.
     If validation fails, it must respond according to OAuth 2.1
     Section 5.3 error handling requirements.

  5.2.  Authorization Chaining Across Domains

     In an agentic AI use case, a request may traverse multiple resource
     servers in multiple trust domains before completing.  It will be
     common that the requesting agent from domain A needs to access the
     resource server (master agent) of domain B.  During this process, the
     following information should be preserved:

     *  Original requesting agent identity

     *  Authorization context

        -  Scope

        -  Resource

        -  Audience

        -  Grant type

        -  Assertion

     The current best practice is
     [I-D.draft-ietf-oauth-identity-chaining-06].

  5.3.  Converting to Internal Workflow

     *  Workflow Generation: Complex tasks often require multi-agent
        collaboration.  The master agent receives, parses, and extracts
        the original job request from the external requesting agent, then
        create sequential workflows or parallel calls.  This requires the
        master agent to have information of all callable internal API
        assets, agent capabilities, etc.

     *  Downscoping: If the master agent intends to use a workflow, it
        extracts the original caller's identity and authorization context,
        and initiates a new internal workflow.  It should follow the
        current least privilege best practice of downscoping-Transaction
        Tokens as specified in
        [I-D.draft-tulshibagwale-oauth-transaction-tokens-05].  The access
        rights to each downstream workload decrease.



  Ni, et al.                 Expires 6 May 2026                   [Page 8]


  Internet-Draft         agent-security-requirements         November 2025


  5.4.  Interoperability for Heterogeneous Systems

     Within a domain, there might exist different types of heterogeneous
     systems or legacy systems that require different authentication
     methods.  They could be API endpoints, microservices, tools or
     databases.  The exact authentication methods are determined by the
     service itself, for example,

     *  bearer tokens

     *  API keys

     *  pre-shared secrets

     *  username-passwords

     *  X.509 certificates, etc.

     As a result, the master agent also works as an intermediary
     credential manager that converts the formats, scopes, identity of the
     credential, bridging the gap between heterogeneous systems and
     platforms.

     Examples include:

     *  Static secrets (API keys) to be exchanged to short-lived, on
        demand credentials (bearer tokens)

  5.5.  Zero Trust Analysis

     The above information can be used as rich context that allow zero
     trust access control.  Remote attestation results of the requesting
     agent could also be part of access policy decision point's inputs.
     Remote attestation results of the requesting agent could include the
     following information:

     *  RoT and trust anchors

     *  Identifiers

     *  Affiliations

     *  Posture assessment results

     *  Capabilities

     The overall information will be used as input of Policy Engine (PE)
     and Policy Decision Point (PDP).



  Ni, et al.                 Expires 6 May 2026                   [Page 9]


  Internet-Draft         agent-security-requirements         November 2025


  5.6.  Microsegmentation

     Microsegmentation may be enforced to prevent lateral movement of
     security risks.  Possible granularity of microsegmentation includes:

     *  per IP segment/subnet

     *  per each workload

     *  per tags and attributes (of workload), etc.

     There should be policy enforcement points (PEP) at the perimeter of
     each segment.  Each PEP can receive software-defined security
     policies issued by PE/PDP.

  6.  IANA Considerations

     This document has no IANA actions.

  7.  References

  7.1.  Normative References

     [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/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

  7.2.  Informative References

     [I-D.draft-ietf-oauth-identity-chaining-06]
                Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins,
                M. J., and B. Campbell, "OAuth Identity and Authorization
                Chaining Across Domains", Work in Progress, Internet-
                Draft, draft-ietf-oauth-identity-chaining-06, 12 September
                2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
                oauth-identity-chaining-06>.

     [I-D.draft-tulshibagwale-oauth-transaction-tokens-05]
                Tulshibagwale, A., Fletcher, G., and P. Kasselman,
                "Transaction Tokens", Work in Progress, Internet-Draft,
                draft-tulshibagwale-oauth-transaction-tokens-05, 20
                October 2023, <https://datatracker.ietf.org/doc/html/
                draft-tulshibagwale-oauth-transaction-tokens-05>.



  Ni, et al.                 Expires 6 May 2026                  [Page 10]


  Internet-Draft         agent-security-requirements         November 2025


  Acknowledgments

     TODO acknowledge.

  Authors' Addresses

     Yuan Ni
     Huawei
     Email: niyuan1@huawei.com


     Chunchi Peter Liu
     Huawei
     Email: liuchunchi@huawei.com


     Nan Geng
     Huawei
     Email: gengnan@huawei.com


     Qiangzhou Gao
     Huawei
     Email: gaoqiangzhou@huawei.com


     Zhenbin Robin Li
     Huawei
     Email: robinli314@163.com






















  Ni, et al.                 Expires 6 May 2026                  [Page 11]


name: draft-yuan-rtgwg-traffic-agent-usecase
rev: 00
title: Use cases of the AI Network Traffic Optimization Agent
time: 2025-11-02T05:43:22Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T05:43:22Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Autonomous netops"]
tags: []
fetched_at: 2026-02-27T22:56:03.420460+00:00
abstract:
  This document introduces AI Network Traffic Optimization Agents as a
     dynamic alternative to traditional static network optimization
     methods.  These AI entities analyze real-time network status (e.g.,
     latency, node load) and adjust resources flexibly—deployed centrally
     or on devices—to enhance efficiency, ensure service quality, and cut
     operational costs.  It defines network traffic optimization
     (maximizing resource use, meeting QoS) and AI agents (autonomous,
     learning entities that reduce manual work), then details three key
     application scenarios: tunnel adjustment (adaptive routing,
     predictive bandwidth, fault recovery), traffic steering
     (classification, application-aware policies, pre-emptive load
     balancing), and network slice adjustment (lifecycle automation, SLA
     compliance, slice-specific fault fixes).  The document emphasizes the
     agents’ role in enabling SLA-compliant, autonomous optimization for
     complex networks.

full_text:
  Network Working Group                                            Q. Yuan
  Internet-Draft                                                    J. Mao
  Intended status: Standards Track                                  B. Liu
  Expires: 5 May 2026                                              N. Geng
                                                                  X. Shang
                                                                    Q. Gao
                                                                     Z. Li
                                                       Huawei Technologies
                                                           1 November 2025


           Use cases of the AI Network Traffic Optimization Agent
                 draft-yuan-rtgwg-traffic-agent-usecase-00

  Abstract

     This document introduces AI Network Traffic Optimization Agents as a
     dynamic alternative to traditional static network optimization
     methods.  These AI entities analyze real-time network status (e.g.,
     latency, node load) and adjust resources flexibly—deployed centrally
     or on devices—to enhance efficiency, ensure service quality, and cut
     operational costs.  It defines network traffic optimization
     (maximizing resource use, meeting QoS) and AI agents (autonomous,
     learning entities that reduce manual work), then details three key
     application scenarios: tunnel adjustment (adaptive routing,
     predictive bandwidth, fault recovery), traffic steering
     (classification, application-aware policies, pre-emptive load
     balancing), and network slice adjustment (lifecycle automation, SLA
     compliance, slice-specific fault fixes).  The document emphasizes the
     agents’ role in enabling SLA-compliant, autonomous optimization for
     complex networks.

  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 5 May 2026.



  Yuan, et al.               Expires 5 May 2026                   [Page 1]


  Internet-Draft            Traffic Agent Usecase            November 2025


  Copyright Notice

     Copyright (c) 2025 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
     3.  Network Traffic Optimization and AI Agent . . . . . . . . . .   3
       3.1.  Network Traffic Optimization  . . . . . . . . . . . . . .   4
       3.2.  AI Agent  . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Usage Scenarios of the AI Network Traffic Optimization
             Agent . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Tunnel Adjustment . . . . . . . . . . . . . . . . . . . .   5
         4.1.1.  Adaptive Tunnel Routing . . . . . . . . . . . . . . .   5
         4.1.2.  Predictive Bandwidth Allocation . . . . . . . . . . .   5
         4.1.3.  Autonomous Fault Detection and Recovery . . . . . . .   6
       4.2.  Traffic Steering into Tunnels . . . . . . . . . . . . . .   6
         4.2.1.  Traffic Classification and Priority Mapping . . . . .   6
         4.2.2.  Application-Aware Steering Policies . . . . . . . . .   6
         4.2.3.  Pre-emptive Traffic Load Balancing  . . . . . . . . .   6
       4.3.  Network Slice Adjustment  . . . . . . . . . . . . . . . .   7
         4.3.1.  NSI Lifecycle Automation  . . . . . . . . . . . . . .   7
         4.3.2.  Closed-Loop SLA Compliance  . . . . . . . . . . . . .   7
         4.3.3.  Slice-Specific Fault Remediation  . . . . . . . . . .   7
     5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8











  Yuan, et al.               Expires 5 May 2026                   [Page 2]


  Internet-Draft            Traffic Agent Usecase            November 2025


  1.  Introduction

     AI Network Traffic Optimization Agents are intelligent entities that
     analyze real-time network telemetry (e.g., bandwidth occupancy,
     latency, node load, packet loss) and dynamically adjust network
     resources on behalf of operators.  Their core goals are to boost
     network efficiency, guarantee service quality, and lower operational
     costs for end-users.  These agents offer flexible deployment: they
     can be implemented on centralized network management platforms to
     integrate global data for holistic optimization, or embedded in edge
     devices (e.g., routers, switches, IoT gateways) to respond in real
     time to local traffic fluctuations.

     This deployment flexibility not only integrates intelligent decision-
     making with network infrastructure but also breaks through the rigid
     interaction barriers of traditional networks.  Unlike conventional
     network devices, which rely on strict, fully standardized protocols
     for communication—often plagued by version incompatibility and format
     constraints—AI agents enable adaptive, context-aware inter-device
     collaboration.  They natively support semi-structured data exchange
     and natural language interaction, allowing seamless communication
     across heterogeneous devices and reducing friction from fragmented
     protocols.

     Traditional network optimization relies heavily on static
     configuration rules and manual adjustments, limiting it to coarse-
     grained issue resolution.  During traffic surges (e.g., peak
     e-commerce sales, large-scale video conferences), this approach fails
     to adapt promptly, leading to increased latency or packet
     loss—especially detrimental to mission-critical applications
     requiring stable transmission.  In contrast, AI Network Traffic
     Optimization Agents enable fine-grained, autonomous optimization:
     they steer traffic to underutilized paths that meet application-
     specific SLA requirements, or allocate exclusive resource channels
     for high-priority services, ensuring performance remains unaffected
     by non-critical traffic.  Their interactive capabilities further
     amplify these advantages, enabling faster cross-device coordination
     and more agile response to dynamic network changes.

  2.  Requirements Language

     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 RFC
     2119[RFC2119].

  3.  Network Traffic Optimization and AI Agent




  Yuan, et al.               Expires 5 May 2026                   [Page 3]


  Internet-Draft            Traffic Agent Usecase            November 2025


  3.1.  Network Traffic Optimization

     Network traffic optimization encompasses a suite of technologies,
     strategies, and practices focused on monitoring, managing, and
     dynamically adjusting data flows across a network.  Its core
     objectives are to maximize the efficiency of network resources (e.g.,
     bandwidth, node capacity), mitigate issues such as congestion,
     latency, and packet loss, and ensure critical applications (e.g.,
     online gaming, financial transactions, real-time video conferencing)
     meet their required Quality of Service (QoS) standards.

     By redistributing traffic to underutilized paths, prioritizing high-
     priority requests, and smoothing sudden traffic surges, it transforms
     passive network management into proactive adjustment.  This approach
     supports the stable operation of modern complex networks (including
     5G, edge computing, and multi-vendor hybrid environments) while
     minimizing unnecessary operational costs—with AI-driven interaction
     capabilities further enhancing its adaptability to heterogeneous
     network ecosystems.

  3.2.  AI Agent

     An AI Agent is an automated intelligent entity designed to act on
     behalf of users, systems, or organizations to achieve specific goals.
     Its core capabilities include:

     *  Perceiving contextual information (e.g., real-time network status,
        user behavior, environmental changes) through multi-source data
        collection;

     *  Analyzing data via advanced algorithms (e.g., machine learning,
        reinforcement learning) to derive actionable insights;

     *  Making autonomous decisions and executing tasks independently or
        in collaboration with other agents;

     *  Supporting semi-structured data exchange (e.g., schema-less
        telemetry metrics, partial configuration snippets) to break free
        from rigid format constraints;

     *  Enabling natural language interaction (NLI) for simplified human-
        device and inter-device communication.

     Unlike traditional static programs, AI Agents can self-learn and
     iterate based on historical data, adapting to dynamic scenarios
     (e.g., real-time traffic path adjustment, personalized policy
     execution).  Their key value lies in reducing manual intervention,
     improving task efficiency, and addressing complex problems requiring



  Yuan, et al.               Expires 5 May 2026                   [Page 4]


  Internet-Draft            Traffic Agent Usecase            November 2025


     real-time, data-driven decision-making.  Critically, their flexible
     interaction models reduce reliance on strict standardization,
     minimizing version compatibility issues and enabling seamless
     integration of new devices—laying the foundation for rapid network
     iteration and scalability.

  4.  Usage Scenarios of the AI Network Traffic Optimization Agent

     This section outlines typical application scenarios of AI Network
     Traffic Optimization Agents across three key network operation
     domains: tunnel adjustment, traffic steering into tunnels, and
     network slice adjustment.  Leveraging AI algorithms and real-time
     telemetry, the agents automate optimization, enhance service
     reliability, and ensure SLA compliance—while their interactive
     capabilities (semi-structured data support, natural language
     interaction) amplify efficiency and scalability.

  4.1.  Tunnel Adjustment

     AI Network Traffic Optimization Agents optimize tunnels (e.g., RSVP-
     TE tunnels, SRv6 tunnels) by dynamically adapting to network
     conditions, ensuring efficient data transmission and fault
     resilience.  Their interactive capabilities streamline cross-device
     coordination, accelerating decision-making and recovery.

  4.1.1.  Adaptive Tunnel Routing

     Agents collect real-time telemetry (e.g., link utilization, latency,
     packet loss) and network topology information (via protocols such as
     BGP-LS or IS-IS).  Using machine learning-based routing algorithms
     (e.g., reinforcement learning for path selection), they identify
     optimal tunnel paths.  When congestion or link degradation is
     detected, agents proactively recompute paths and share intent-driven
     instructions (via semi-structured data) with routers/switches to
     minimize end-to-end latency without relying on rigid protocol syntax.

  4.1.2.  Predictive Bandwidth Allocation

     Agents analyze historical traffic patterns (e.g., diurnal peaks for
     enterprise services) to predict future bandwidth demands for each
     tunnel.  Through tunnel signaling protocols (e.g., RSVP-TE), they
     implement dynamic adjustment: reducing allocation during off-peak
     periods to avoid waste, and scaling up bandwidth preemptively before
     traffic surges.  Operators can also fine-tune prediction parameters
     via natural language prompts (e.g., “Increase bandwidth buffer for
     weekday 9 AM video conferences”), simplifying policy updates.





  Yuan, et al.               Expires 5 May 2026                   [Page 5]


  Internet-Draft            Traffic Agent Usecase            November 2025


  4.1.3.  Autonomous Fault Detection and Recovery

     Agents monitor real-time tunnel KPIs (e.g., availability, jitter) and
     use anomaly detection models (e.g., autoencoders) to identify faults
     (e.g., link failures).  Upon detection, they automatically share
     fault details (via semi-structured data) with other agents and
     initiate recovery actions (e.g., switching traffic to pre-provisioned
     backups).  This cross-agent collaboration reduces Mean Time to
     Recovery (MTTR) by eliminating manual coordination delays.

  4.2.  Traffic Steering into Tunnels

     AI Network Traffic Optimization Agents enable fine-grained traffic
     steering, mapping flows to tunnels that align with their QoS
     requirements.  Their support for multi-format data and natural
     language interaction simplifies policy configuration and cross-device
     coordination.

  4.2.1.  Traffic Classification and Priority Mapping

     The agent can perform deep packet inspection (DPI) and flow analysis
     (via protocols such as NetFlow v9 or IPFIX) to classify traffic based
     on service type (e.g., VoIP, 4K video, bulk data), user priority
     (e.g., VIP users), and QoS class.Through policy-based routing (PBR)
     or segment routing policies, it maps classified traffic to tunnels
     with QoS capabilities that match the traffic’s needs—for example,
     low-latency tunnels for VoIP or high-bandwidth tunnels for bulk data.

  4.2.2.  Application-Aware Steering Policies

     Agents use application signature recognition (e.g., TLS SNI, DNS
     queries) to identify application-specific traffic (e.g., Zoom, AWS S3
     transfers).  They enforce application-specific rules: real-time
     applications are directed to tunnels with guaranteed latency (<50ms)
     and low packet loss (<0.1%), while non-critical traffic uses cost-
     efficient tunnels.  Operators can define these rules via natural
     language (e.g., “Route all IoT sensor data to shared low-cost
     tunnels”), with agents translating prompts into executable
     policies—reducing configuration complexity.

  4.2.3.  Pre-emptive Traffic Load Balancing

     Agents forecast traffic hotspots (e.g., regional surges from events)
     using time-series models (e.g., LSTM).  They implement pre-emptive
     steering to distribute predicted heavy traffic across parallel
     tunnels, preventing overload.  Agents share load distribution plans
     with edge devices via semi-structured data, ensuring uniform resource
     utilization across the network without strict protocol alignment.



  Yuan, et al.               Expires 5 May 2026                   [Page 6]


  Internet-Draft            Traffic Agent Usecase            November 2025


  4.3.  Network Slice Adjustment

     AI Network Traffic Optimization Agents support the lifecycle
     management and optimization of Network Slice Instances (NSIs),
     focusing on resource efficiency, SLA compliance, and fault
     resilience.  Their flexible interaction models enable seamless
     collaboration between slice-specific agents, accelerating slice
     deployment and adjustment.

  4.3.1.  NSI Lifecycle Automation

     Agents participate in NSI design by using slice requirements (e.g.,
     bandwidth, latency, isolation) to recommend optimal resource
     allocation (e.g., CPU, bandwidth, tunnel assignments) and topology
     configurations (e.g., dedicated vs. shared tunnels).  They automate
     instantiation and termination: during deployment, agents coordinate
     across devices to deploy required tunnels and steering rules (via
     semi-structured data exchange); upon termination, they release
     resources to prevent leakage.  This cross-agent collaboration reduces
     reliance on standardized interfaces, enabling faster slice
     deployment.

  4.3.2.  Closed-Loop SLA Compliance

     Agents monitor slice-level KPIs (e.g., throughput, latency) in real
     time and compare them against SLA thresholds (e.g., 100 Mbps minimum
     throughput, 100ms maximum latency).  When SLA violations are
     predicted or detected, they trigger closed-loop adjustments (e.g.,
     augmenting tunnel bandwidth, optimizing routing paths).  Operators
     can also set SLA thresholds via natural language (e.g., “Ensure
     industrial IoT slice latency stays below 80ms”), making policy
     updates intuitive and agile.

  4.3.3.  Slice-Specific Fault Remediation

     The agent can analyze multi-dimensional slice alarms (e.g., tunnel
     faults within the slice, resource shortages) via correlation models
     that integrate slice topology and historical fault data.  It enables
     slice-aware fault recovery: it identifies the root cause of slice
     degradation (e.g., a failed tunnel in the slice’s path) and executes
     slice-specific remediation (e.g., re-provisioning a dedicated backup
     tunnel for the slice), thereby minimizing impact on the slice’s
     services.








  Yuan, et al.               Expires 5 May 2026                   [Page 7]


  Internet-Draft            Traffic Agent Usecase            November 2025


  5.  Conclusion

     This document systematically elaborates on AI Network Traffic
     Optimization Agents, covering their role in addressing traditional
     network limitations, core definitions of network traffic optimization
     and AI agents, and practical application scenarios.  Beyond dynamic
     resource allocation and SLA-compliant optimization, these agents
     deliver transformative value through enhanced inter-device
     interaction capabilities.

     By supporting semi-structured data exchange, AI agents break free
     from the rigid format constraints of traditional network protocols,
     enabling seamless communication across heterogeneous devices and
     vendors.  Natural language interaction simplifies policy
     configuration and human-device collaboration, lowering operational
     barriers.  These features reduce reliance on strict standardization
     and mitigate version compatibility issues, fostering network
     scalability and enabling rapid iteration of optimization strategies.

     In complex environments such as 5G, edge computing, and multi-vendor
     hybrid networks, AI Network Traffic Optimization Agents serve as a
     cornerstone of next-generation intelligent networks.  They not only
     automate fine-grained optimization to enhance efficiency and service
     quality but also through flexible interaction models, enable agile
     response to dynamic traffic patterns and emerging service
     requirements—future-proofing networks against technological evolution
     while minimizing operational costs.  As network ecosystems grow more
     complex, the interactive and adaptive capabilities of these AI agents
     will become increasingly critical to unlocking the full potential of
     intelligent network management.

  6.  Security Considerations

     TBD.

  7.  IANA Considerations

     TBD.

  8.  Normative References

     [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




  Yuan, et al.               Expires 5 May 2026                   [Page 8]


  Internet-Draft            Traffic Agent Usecase            November 2025


     Quan Yuan
     Huawei Technologies
     Beijing
     100095
     China
     Email: yuanquan25@huawei.com


     Jianwei Mao
     Huawei Technologies
     Beijing
     100095
     China
     Email: maojianwei@huawei.com


     Bing Liu
     Huawei Technologies
     Beijing
     100095
     China
     Email: leo.liubing@huawei.com


     Nan Geng
     Huawei Technologies
     Beijing
     100095
     China
     Email: gengnan@huawei.com


     Xiaotong Shang
     Huawei Technologies
     Beijing
     100095
     China
     Email: shangxiaotong@huawei.com


     Qiangzhou Gao
     Huawei Technologies
     Beijing
     100095
     China
     Email: gaoqiangzhou@huawei.com





  Yuan, et al.               Expires 5 May 2026                   [Page 9]


  Internet-Draft            Traffic Agent Usecase            November 2025


     Zhenbin
     Huawei Technologies
     Beijing
     100095
     China
     Email: robinli314@163.com













































  Yuan, et al.               Expires 5 May 2026                  [Page 10]


name: draft-yuan-rtgwg-security-agent-usecase
rev: 00
title: Use cases of the AI Network Security Agent
time: 2025-11-02T05:48:02Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T05:48:02Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-03T15:50:12.944677+00:00
abstract:
  Core network devices like routers fulfill dual roles of data
     forwarding and security protection.  However, escalating threats
     (e.g., zero-day vulnerabilities, DDoS attacks) expose limitations of
     traditional security—relying on static ACLs, signature-based
     detection, and manual configuration—causing delayed responses, high
     false positives, and protection gaps.  This paper proposes AI Network
     Security Agents: intelligent software components leveraging machine
     learning, behavioral analysis, and real-time data fusion, with three
     core capabilities (adaptive learning, automation, distributed
     collaboration) to shift security from passive to intelligent.  Four
     key scenarios are outlined: dynamic defense against unknown threats
     via baselines and tracing; ACL optimization via intent parsing;
     configuration security via baseline checks and simulation; and
     collaborative defense via intelligence aggregation and linked
     responses.  AI Agents turn routers into active security
     orchestrators, enhancing threat protection and operational
     efficiency.

full_text:
  Network Working Group                                            Q. Yuan
  Internet-Draft                                                    J. Mao
  Intended status: Standards Track                                  B. Liu
  Expires: 5 May 2026                                              N. Geng
                                                                  X. Shang
                                                                    Q. Gao
                                                                     Z. Li
                                                       Huawei Technologies
                                                           1 November 2025


                 Use cases of the AI Network Security Agent
                 draft-yuan-rtgwg-security-agent-usecase-00

  Abstract

     Core network devices like routers fulfill dual roles of data
     forwarding and security protection.  However, escalating threats
     (e.g., zero-day vulnerabilities, DDoS attacks) expose limitations of
     traditional security—relying on static ACLs, signature-based
     detection, and manual configuration—causing delayed responses, high
     false positives, and protection gaps.  This paper proposes AI Network
     Security Agents: intelligent software components leveraging machine
     learning, behavioral analysis, and real-time data fusion, with three
     core capabilities (adaptive learning, automation, distributed
     collaboration) to shift security from passive to intelligent.  Four
     key scenarios are outlined: dynamic defense against unknown threats
     via baselines and tracing; ACL optimization via intent parsing;
     configuration security via baseline checks and simulation; and
     collaborative defense via intelligence aggregation and linked
     responses.  AI Agents turn routers into active security
     orchestrators, enhancing threat protection and operational
     efficiency.

  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."



  Yuan, et al.               Expires 5 May 2026                   [Page 1]


  Internet-Draft           Security Agent Usecase            November 2025


     This Internet-Draft will expire on 5 May 2026.

  Copyright Notice

     Copyright (c) 2025 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
     3.  Usage Scenarios of the AI Network Security Agent  . . . . . .   3
       3.1.  Dynamic Defense Against Zero-Day Vulnerabilities and
             Unknown Threats . . . . . . . . . . . . . . . . . . . . .   3
         3.1.1.  Behavioral Pattern Recognition  . . . . . . . . . . .   3
         3.1.2.  Attack Chain Tracing  . . . . . . . . . . . . . . . .   4
         3.1.3.  Zero-Day Vulnerability Prediction . . . . . . . . . .   4
       3.2.  Dynamic ACL Rule Optimization and Intelligent Policy
             Management  . . . . . . . . . . . . . . . . . . . . . . .   4
         3.2.1.  Policy Intent Translation . . . . . . . . . . . . . .   4
         3.2.2.  Traffic Behavior Learning . . . . . . . . . . . . . .   4
         3.2.3.  Policy Conflict Detection . . . . . . . . . . . . . .   4
       3.3.  Device Configuration Security . . . . . . . . . . . . . .   4
         3.3.1.  Configuration Baseline Verification . . . . . . . . .   5
         3.3.2.  Configuration Change Validation . . . . . . . . . . .   5
       3.4.  Threat Intelligence Sharing and Global Collaborative
             Defense . . . . . . . . . . . . . . . . . . . . . . . . .   5
         3.4.1.  Intelligence Aggregation  . . . . . . . . . . . . . .   5
         3.4.2.  Linked Attack Response  . . . . . . . . . . . . . . .   5
         3.4.3.  Security Posture Prediction . . . . . . . . . . . . .   5
     4.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6







  Yuan, et al.               Expires 5 May 2026                   [Page 2]


  Internet-Draft           Security Agent Usecase            November 2025


  1.  Introduction

     Routers and other core network devices serve as the foundational
     backbone of modern digital infrastructures, responsible for both data
     forwarding across network segments and the critical security
     functions of protecting traffic integrity, confidentiality, and
     availability.  However, the escalating sophistication of cyber
     threats—ranging from stealthy zero-day exploits and large-scale DDoS
     assaults to persistent APT infiltrations—has exposed inherent
     limitations in traditional network security mechanisms.  Dependent on
     static access control lists (ACLs), signature-based threat detection,
     and manual configuration workflows, legacy systems lack the agility
     to keep pace with dynamic threat landscapes, often leading to delayed
     threat responses, high false-positive rates, and unavoidable
     protection gaps.  This document explores how integrating AI Agents
     into network devices addresses these limitations, transforming
     passive defense into an intelligent, adaptive security framework.

  2.  Requirements Language

     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 RFC
     2119[RFC2119].

  3.  Usage Scenarios of the AI Network Security Agent

     After integrating AI Agents into network devices, their core security
     capabilities are upgraded from passive defense to an intelligent,
     adaptive protection system.  Below are the key usage scenarios,
     elaborated with technical details and practical use cases:

  3.1.  Dynamic Defense Against Zero-Day Vulnerabilities and Unknown
        Threats

     Traditional signature-based detection fails to address zero-day
     Vulnerabilities (e.g., new APT campaigns).  AI Agents enable real-
     time threat identification and mitigation through behavioral
     analytics and adaptive learning:

  3.1.1.  Behavioral Pattern Recognition

     Embedded AI Agents in network devices can analyze system calls,
     network traffic features, and file operations to establish a "normal
     behavior baseline."  For instance, if a device suddenly sends
     encrypted data to multiple unknown IPs (a sign of data exfiltration),
     the AI Agent triggers isolation within minutes to prevent lateral
     spread.



  Yuan, et al.               Expires 5 May 2026                   [Page 3]


  Internet-Draft           Security Agent Usecase            November 2025


  3.1.2.  Attack Chain Tracing

     Leveraging knowledge graphs, AI Agents can correlate multi-source
     logs (Syslog, traffic logs) to map attack paths.  For example, during
     a supply chain attack, the agent can identify abnormal ARP requests
     and failed SSH logins in device logs, pinpoint the attack pivot, and
     block further infiltration.

  3.1.3.  Zero-Day Vulnerability Prediction

     Trained on historical vulnerability data and code features, AI Agents
     can forecast potential attack surfaces.  For example, they scan
     device configurations to flag weak passwords or unclosed high-risk
     ports, generating actionable risk reports.

  3.2.  Dynamic ACL Rule Optimization and Intelligent Policy Management

     Manual ACL configuration is error-prone and rigid.  AI Agents
     automate policy creation and adjustment via intent-based parsing and
     reinforcement learning:

  3.2.1.  Policy Intent Translation

     Users describe security requirements in natural language (e.g.,
     "Block the Sales department from accessing finance servers"), and the
     AI Agent converts this into valid ACL rules.

  3.2.2.  Traffic Behavior Learning

     AI Agents can continuously analyze network traffic to optimize ACL
     rules dynamically.  For example, during peak video conference hours,
     the agent adjusts QoS policies to prioritize critical app bandwidth
     while identifying DDoS attacks disguised as video streams.

  3.2.3.  Policy Conflict Detection

     Using knowledge graphs, AI Agents can real-time validate logical
     conflicts in ACL rules.  If rules like "Allow all HTTP traffic" and
     "Block specific IPs" overlap, the agent flags the inconsistency and
     recommends priority adjustments.

  3.3.  Device Configuration Security

     Manual configuration audits are inefficient.  AI Agents boost network
     security via automated compliance checks and intelligent repairs:






  Yuan, et al.               Expires 5 May 2026                   [Page 4]


  Internet-Draft           Security Agent Usecase            November 2025


  3.3.1.  Configuration Baseline Verification

     AI Agents can use pre-defined security templates to scan device
     configurations, flagging risks like weak passwords or unencrypted
     management interfaces.

  3.3.2.  Configuration Change Validation

     After a user submits a configuration change (e.g., modifying NAT
     policies), the AI Agent simulates post-deployment network behavior to
     verify functionality—ensuring internal devices can still access the
     public network—and generates a validation report.

  3.4.  Threat Intelligence Sharing and Global Collaborative Defense

     Traditional security deployments operate in silos, limiting
     effectiveness against cross-network threats.  AI Agents enable cross-
     device/vendor protection via multi-source data fusion and automated
     response orchestration:

  3.4.1.  Intelligence Aggregation

     AI Agents integrate feeds from sources like CISA and VirusTotal to
     update threat signatures in real time.  If a malicious IP is flagged
     as a phishing source by multiple feeds, the agent automatically adds
     blocking rules across all routers in the network.

  3.4.2.  Linked Attack Response

     When one router detects an attack, the AI Agent notifies upstream/
     downstream devices for coordinated defense.  For example, if a branch
     router detects an APT attack, the agent coordinates with the
     headquarters firewall to block the attack IP and alerts endpoint
     security tools for virus scans.

  3.4.3.  Security Posture Prediction

     Using historical attack data and network topology, AI Agents forecast
     potential attack paths.  If a network faces cross-VLAN infiltration
     risks, the agent pre-deploys access control policies on core routers
     to block lateral movement.










  Yuan, et al.               Expires 5 May 2026                   [Page 5]


  Internet-Draft           Security Agent Usecase            November 2025


  4.  Conclusion

     The integration of AI Agents into core network devices represents a
     pivotal advancement in network security, addressing the inherent
     inflexibility of traditional defense mechanisms.  By enabling dynamic
     threat detection, intelligent policy management, automated
     configuration security, and collaborative defense, AI Agents
     transform routers from passive traffic handlers into proactive
     security orchestrators.  These capabilities not only enhance
     protection against emerging threats like zero-day vulnerabilities but
     also streamline operational efficiency by reducing manual
     intervention.  While challenges remain—such as optimizing AI model
     performance for resource-constrained devices and mitigating
     adversarial attacks—future developments in edge AI and self-healing
     algorithms will further strengthen this framework.  Ultimately, AI-
     enhanced network security devices provide organizations with a
     resilient, scalable foundation to navigate the evolving cyber threat
     landscape, ensuring the reliability and security of critical digital
     infrastructures.

  5.  Security Considerations

     TBD.

  6.  IANA Considerations

     TBD.

  7.  Normative References

     [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

     Quan Yuan
     Huawei Technologies
     Beijing
     100095
     China
     Email: yuanquan25@huawei.com








  Yuan, et al.               Expires 5 May 2026                   [Page 6]


  Internet-Draft           Security Agent Usecase            November 2025


     Jianwei Mao
     Huawei Technologies
     Beijing
     100095
     China
     Email: maojianwei@huawei.com


     Bing Liu
     Huawei Technologies
     Beijing
     100095
     China
     Email: leo.liubing@huawei.com


     Nan Geng
     Huawei Technologies
     Beijing
     100095
     China
     Email: gengnan@huawei.com


     Xiaotong Shang
     Huawei Technologies
     Beijing
     100095
     China
     Email: shangxiaotong@huawei.com


     Qiangzhou Gao
     Huawei Technologies
     Beijing
     100095
     China
     Email: gaoqiangzhou@huawei.com


     Zhenbin
     Huawei Technologies
     Beijing
     100095
     China
     Email: robinli314@163.com





  Yuan, et al.               Expires 5 May 2026                   [Page 7]


name: draft-men-rtgwg-agent-networking-digibank-scenario
rev: 00
title: Agents Networking Scenarios in Enterprise and Broadband Networks
time: 2025-11-02T13:01:29Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T13:01:29Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-03T15:50:09.773512+00:00
abstract:
  This document describes several typical digital banking scenarios,
     and discusses the trend of banking digitalization evolving to agentic
     service inteconnection.  Then, this document proposes an agent
     networking architecture based on the core component which is agent
     gateway.

full_text:
  rtgwg                                                             X. Men
  Internet-Draft                                                   Y. Fang
  Intended status: Informational                                  UnionPay
  Expires: 6 May 2026                                               B. Liu
                                                                    Q. Gao
                                                                   N. Geng
                                                                  X. Shang
                                                                     Z. Li
                                                       Huawei Technologies
                                                           2 November 2025


      Agents Networking Scenarios in Enterprise and Broadband Networks
           draft-men-rtgwg-agent-networking-digibank-scenario-00

  Abstract

     This document describes several typical digital banking scenarios,
     and discusses the trend of banking digitalization evolving to agentic
     service inteconnection.  Then, this document proposes an agent
     networking architecture based on the core component which is agent
     gateway.

  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 May 2026.

  Copyright Notice

     Copyright (c) 2025 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.



  Men, et al.                Expires 6 May 2026                   [Page 1]


  Internet-Draft         Agents Networking Scenarios         November 2025


     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
       1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   2
       1.2.  Agent Requirements in Digital Banking Scenarios . . . . .   3
       1.3.  Introduction of Agent Gateway and Networking
             Architecture  . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     3.  Modern Digitalization of Banking Services . . . . . . . . . .   4
       3.1.  Example Scenario 1: IPO Bank Statement Auditing . . . . .   4
       3.2.  Example Scenario 2: Retail Credit . . . . . . . . . . . .   5
       3.3.  Example Scenario 3: Bank Electronic Certificate
             Services  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Bank Union and Digital Interconnection  . . . . . . . . . . .   5
       4.1.  Bank Union Organization . . . . . . . . . . . . . . . . .   5
       4.2.  Digital Interconnection among Bank Union Members  . . . .   6
       4.3.  AS-IS: API-based Service Calling  . . . . . . . . . . . .   6
       4.4.  TO-BE: Agentic Service Interconnection  . . . . . . . . .   7
     5.  Proposed Agent Networking Architecture  . . . . . . . . . . .   7
       5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   7
       5.2.  Agent Gateway as a Key Enabler  . . . . . . . . . . . . .   8
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
     9.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

  1.1.  Background

     With the rapid development of FinTech (Financial Technology), the
     digital banking business is undergoing profound changes.  Traditional
     banking systems face performance bottlenecks and integration
     challenges when it comes to handling cumbersome corporate audits,
     high-frequency electronic transaction certificate, and deeply
     customized user experiences.  The maturity of Artificial Intelligence
     (AI) technology, especially the emergence of the AI Agent, provides a
     new paradigm for solving these challenges.  AI Agents, capable of
     autonomous decision-making and task execution, are becoming the core
     components for building the next generation of intelligent financial



  Men, et al.                Expires 6 May 2026                   [Page 2]


  Internet-Draft         Agents Networking Scenarios         November 2025


     services.

  1.2.  Agent Requirements in Digital Banking Scenarios

     In the digital banking business, the application scenarios for AI
     Agents cover customer service, fraud detection, personalized
     investment recommendations, smart contract management, and complex
     compliance checks etc.  These tasks often require the collaborative
     work of multiple Agents with different capabilities.  For instance, a
     loan application may require one Agent for identity verification, a
     second Agent for credit scoring, and a third Agent for compliance
     review.  This multi-Agent collaboration model necessitates a unified,
     efficient, and secure coordination mechanism.

  1.3.  Introduction of Agent Gateway and Networking Architecture

     To achieve efficient, reliable, and secure networking and interaction
     among Agents, this proposal introduces the concept of the Agent
     Gateway and a networking architecture based on it.  The Agent Gateway
     acts as a critical hub in the Agent ecosystem, responsible for:

     *  Agent Registration and Discovery: Allowing Agents to efficiently
        discover and invoke other Agents or external services.

     *  Efficient Agent Communication: Agents can delegate functions like
        message routing and group communication to the Gateway, allowing
        them to focus more on business-specific implementation.

     *  Security and Authentication: Providing a unified mechanism for
        authentication, authorization, and data encryption to ensure the
        security of financial data.

     The networking architecture built upon the Agent Gateway is designed
     to provide an open, interoperable framework, enabling Agents
     developed by different vendors to be securely and seamlessly
     integrated into the digital banking business process.  Furthermore,
     the gateway-based implementation method can greatly simplify an
     enterprise's deployment and operations.

  2.  Terms and Definitions

     *  Digital Banking: refers to the end-to-end digitization of
        traditional banking services.








  Men, et al.                Expires 6 May 2026                   [Page 3]


  Internet-Draft         Agents Networking Scenarios         November 2025


     *  Agent Gateway: a "Connection Hub" and "Security Steward" in the
        process of agent communication.  Its core role is to resolve
        interconnection issues between different Agents of different
        domains while ensuring secure, efficient, and orderly
        communication.

  2.1.  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  3.  Modern Digitalization of Banking Services

  3.1.  Example Scenario 1: IPO Bank Statement Auditing

     o Business Scenario:

     During the process of a company's Initial Public Offering (IPO), the
     Sponsor Institution (often an investment bank) is required to review
     the bank transaction records of the prospective listed company, its
     directors, supervisors, senior management (D&S&SM), and key
     personnel.  This is done to understand related party transactions and
     fund transfers, and to verify:

     *  Whether the disclosure of related parties and related party
        transactions is complete.

     *  Whether there is any suspicion of fictitious revenue through off-
        book fund cycling.

     *  Whether there is undue benefit transfer or other undisclosed
        benefit arrangements.

     o Traditional Offline Method:

     The above process traditionally required the Sponsor Institution to
     accompany the relevant subjects being investigated to major local
     bank branches to print the bank statements (flow records) in person.

     o Existing API Method (Digital Banking Approach):








  Men, et al.                Expires 6 May 2026                   [Page 4]


  Internet-Draft         Agents Networking Scenarios         November 2025


     Based on a Digital Banking Union Platform (i.e., China UionPay’s
     Platform), the original offline process is transitioned online.  With
     the full authorization of the subject, the Sponsor Institution sends
     a request to the bank via the digital platform.  The bank then
     returns the transaction record information to the Sponsor Institution
     through the digital platform.

  3.2.  Example Scenario 2: Retail Credit

     Leveraging the streamlined retail payment process flow as a
     foundational layer, the goal is to equip commercial banks with the
     capabilities to deliver standardized and highly accessible Inclusive
     Finance services to their retail customers.

     This strategic integration transcends simple transactional banking,
     culminating in a powerful, synergistic model that forms a
     comprehensive "Finance + Payment + Service" ecosystem capability.
     This integrated approach ensures consistent user experience,
     significantly lowers the barrier to financial access for underserved
     populations, and establishes the bank as a pivotal digital financial
     hub.

  3.3.  Example Scenario 3: Bank Electronic Certificate Services

     To significantly enhance the efficiency and transparency of the
     corporate client experience, we will deploy secure, automated
     services for the inquiry and compliant download of essential
     financial documents, including electronic receipts and electronic
     account statements.

     This digital transformation is not merely an operational upgrade but
     a strategic move to solidify the value proposition of the Banking
     Union's corporate business line, driving increased customer
     satisfaction, reducing operational friction, and accelerating the
     overall digitization of B2B financial services.

  4.  Bank Union and Digital Interconnection

  4.1.  Bank Union Organization

     A Banking Union Organization typically refers to a non-profit joint
     organization collectively initiated and established by numerous
     member financial institutions.  Its core objective is to build and
     operate a unified, efficient interbank transaction processing and
     clearing network.  Taking China UnionPay as an example, it connects
     disparate bank card payment systems across different banks and
     regions by establishing and implementing uniform business rules and
     technical standards.



  Men, et al.                Expires 6 May 2026                   [Page 5]


  Internet-Draft         Agents Networking Scenarios         November 2025


     In essence, a Banking Union Organization acts as the "Public
     Infrastructure" and "Rule-Setter" in the payment domain.  Through
     resource integration and collaboration, it constructs a vast,
     convenient, and secure financial payment ecosystem for its member
     institutions and the general public.

  4.2.  Digital Interconnection among Bank Union Members

     All member banks adhere to the unified technical standards and data
     formats established by the alliance, seamlessly integrating their
     core systems with the alliance's central clearing platform to achieve
     digital-level interconnection.

     Taking the aforementioned case of IPO auditing as an example: when a
     company applies for listing, underwriters and lawyers need to conduct
     a thorough review of the company's bank account transactions to
     verify the authenticity of its revenue and the compliance of its
     funds.  If the company holds accounts in dozens of different banks
     across the country, this review process becomes extremely cumbersome.
     At this point, the digital interconnection system established by the
     banking alliance (such as China UnionPay) plays a critical role.

     Although the company's accounts are dispersed across various member
     banks, these banks have achieved unified data standards and system
     interoperability through UnionPay's underlying financial network.
     Auditing institutions, with the company's authorization, can access a
     standardized data interface and initiate query requests to the
     alliance network.  These requests are instantly routed to the backend
     systems of each bank using a unified digital interface.
     Subsequently, the company's transaction records, scattered across
     different member institutions, can be securely, accurately, and
     efficiently aggregated and returned.

  4.3.  AS-IS: API-based Service Calling

     Traditional API calls demonstrate significant limitations when
     dealing with complex and ever-changing business environments.

     *  Firstly, there is the issue of Fragility and Rigidity.
        Traditional automation relies on hard-coded workflows and
        predefined logic.  In the banking sector, even minor changes in
        business logic or underlying system behavior can disrupt automated
        processes, requiring manual reconfiguration.  This fragility makes
        it difficult for systems to adapt to real-time changes.







  Men, et al.                Expires 6 May 2026                   [Page 6]


  Internet-Draft         Agents Networking Scenarios         November 2025


     *  Secondly, there is a lack of active decision.  Traditional APIs
        typically execute tasks only after receiving instructions,
        providing options or suggestions.  Unlike Agents, which could
        autonomously interpret complex input signals, decide on the
        necessary sequence of actions across multiple systems.

     *  Finally, in traditional architectures, connecting multiple
        enterprise systems—such as CRM, ERP, and payment systems—often
        requires a complex, centrally defined orchestration layer managed
        by developers.  This centralized control is prone to bottlenecks
        and limits flexible cross-functional collaboration.

  4.4.  TO-BE: Agentic Service Interconnection

     Agentic interconnection/orchestration fundamentally overturns the
     traditional models mentioned above by introducing goal-centric,
     adaptive execution capabilities.

     *  Agents treat APIs as dynamic building blocks rather than fixed
        execution paths.  Based on real-time context and shared memory,
        they flexibly select and invoke the most relevant APIs, enabling
        collaboration across various systems.  This "context-aware
        decision-making" capability allows Agents to achieve more
        efficient cross-system integration than rigid, hard-coded scripts.

     *  Agentic workflows tackle complex problems using a multi-step,
        iterative approach.  They are capable of dynamically adapting to
        real-time data and unexpected conditions, a feat that fixed-rule
        systems cannot easily achieve.

     In short, Agentic AI represents the next phase of enterprise digital
     transformation.  For digital banking, it is no longer optional but is
     the inevitable path to achieving operational excellence and strategic
     growth.

  5.  Proposed Agent Networking Architecture

  5.1.  Overview

     In the banking industry, Agentic systems could categorized into two
     deployment models:

     *  Single-Agent Systems: In these systems, a single AI Agent
        processes all tasks sequentially.  They are generally suitable for
        well-defined problems or processes requiring rapid resolution,
        such as dedicated fraud monitoring or automated report generation.





  Men, et al.                Expires 6 May 2026                   [Page 7]


  Internet-Draft         Agents Networking Scenarios         November 2025


     *  Multi-Agent Systems (MAS): MAS involve multiple AI Agents
        collaborating to break down complex workflows into smaller parts.
        MAS are crucial for handling sophisticated banking workflows, such
        as credit underwriting, which involves both risk scoring and
        treasury management.  MAS typically adopt a horizontal
        collaborative structure where each Agent focuses on a narrow skill
        (e.g., a Compliance Agent or a Risk Agent) and then integrates
        their respective analyses.  This model offers higher scalability
        and flexibility but places greater demands on the mechanisms for
        inter-Agent communication, coordination, and state sharing.

     The key challenge in realizing this vision lies in constructing an
     Agent networking architecture that supports decentralization, secure
     collaboration, and stateful communication.

  5.2.  Agent Gateway as a Key Enabler

     As the banking industry advances toward agentic digitization,
     securely efficiently integrating AI agents into internal banking
     systems has become a critical challenge.  In this context, the Agent
     Gateway could serve a core component for enabling this
     transformation.  Its importance is primarily reflected in the
     following three aspects:

     *  First, the Agent Gateway serves as a communication hub for
        intelligent collaboration.  It facilitates coordinated work among
        multiple AI agents by implementing unified communication protocols
        and context management, ensuring that different agents can execute
        complex business processes in an orderly and efficient manner.

     *  Second, the Agent Gateway acts as a foundation for security and
        compliance.  Functioning as a centralized access control node, it
        authenticates identities, checks permissions, and audits
        operations for all AI agents, ensuring that every action complies
        with financial regulatory requirements and safeguarding system
        security from the source.

     *  Lastly, the Agent Gateway can also serve as a simplification/
        adaptation layer for complex systems.  It encapsulates the
        intricate APIs, data sources, and business systems within banks
        into standardized services, allowing AI agents to directly invoke
        required functions without needing to understand backend technical
        details, thereby significantly reducing the complexity of system
        integration.







  Men, et al.                Expires 6 May 2026                   [Page 8]


  Internet-Draft         Agents Networking Scenarios         November 2025


  6.  Security Considerations

     TBD

  7.  IANA Considerations

     This document has no IANA requirements.

  8.  Acknowledgements

     TBD

  9.  Normative References

     [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>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  Authors' Addresses

     Xiaohua Men
     UnionPay
     Beijing
     China
     Email: menxiaohua@unionpay.com


     Yulun Fang
     UnionPay
     Beijing
     China
     Email: fangyulun@unionpay.com


     Bing Liu
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: leo.liubing@huawei.com






  Men, et al.                Expires 6 May 2026                   [Page 9]


  Internet-Draft         Agents Networking Scenarios         November 2025


     Qiangzhou Gao
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: gaoqiangzhou@huawei.com


     Nan Geng
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: gengnan@huawei.com


     Xiaotong Shang
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: shangxiaotong@huawei.com


     Zhenbin Li
     Huawei Technologies
     Beijing
     China
     Email: robinli314@163.com






















  Men, et al.                Expires 6 May 2026                  [Page 10]


name: draft-tong-network-agent-use-cases-in-6g
rev: 00
title: Network AI Agent Use Cases and Requirements in 6G
time: 2025-11-02T13:06:23Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T13:06:23Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "ML traffic mgmt", "Agent discovery/reg", "Model serving/inference"]
tags: []
fetched_at: 2026-02-27T22:56:03.420468+00:00
abstract:
  This draft introduces use cases related to network AI agents in 6G,
     with a focus on the interaction workflows of network AI agents in two
     distinct scenarios: connectivity services and third-party application
     services.  These use cases primarily draw upon 6G-related scenarios
     outlined in the 3GPP technical report [TR22.870].  Furthermore, the
     document elaborates on the integration of network AI agents within
     the 6G framework and discusses corresponding network requirements.

full_text:
  Network Working Group                                            Y. Tong
  Internet-Draft                                                    A. Sun
  Intended status: Informational                                   A. Wang
  Expires: 6 May 2026                                               Y. Liu
                                                                    Y. Xie
                                                             China Telecom
                                                           2 November 2025


             Network AI Agent Use Cases and Requirements in 6G
                draft-tong-network-agent-use-cases-in-6g-00

  Abstract

     This draft introduces use cases related to network AI agents in 6G,
     with a focus on the interaction workflows of network AI agents in two
     distinct scenarios: connectivity services and third-party application
     services.  These use cases primarily draw upon 6G-related scenarios
     outlined in the 3GPP technical report [TR22.870].  Furthermore, the
     document elaborates on the integration of network AI agents within
     the 6G framework and discusses corresponding network requirements.

  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 May 2026.

  Copyright Notice

     Copyright (c) 2025 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



  Tong, et al.               Expires 6 May 2026                   [Page 1]


  Internet-Draft  Network AI Agent Use Cases and Requireme   November 2025


     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
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Generative Network for Connectivity Services  . . . . . .   3
         2.1.1.  Process Flow  . . . . . . . . . . . . . . . . . . . .   3
         2.1.2.  Analysis of AI Agent Roles  . . . . . . . . . . . . .   5
       2.2.  Network Capability Exposure to Third-Party Services . . .   5
         2.2.1.  Process Flow  . . . . . . . . . . . . . . . . . . . .   5
         2.2.2.  Analysis of AI Agent Roles  . . . . . . . . . . . . .   6
     3.  Architecture and Potential Requirements of AI Agent-Integrated
             6G Network  . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.  AI Agent-Integrated 6G Network Framework  . . . . . . . .   7
       3.2.  Potential Network Requirements  . . . . . . . . . . . . .   8
     4.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
       7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     In the era of 6G network, the emergence of new services such as AI,
     computing, and sensing poses unprecedented challenges to network
     processing capabilities.  As autonomous decision-making entities, AI
     agents are poised to become a core driving force for innovation in
     network architecture.  Through capabilities such as intent
     understanding, environmental modeling, and cross-domain
     collaboration, they can dynamically adapt to user demands and network
     operating conditions, facilitating an intelligent leap toward
     "proactive optimization" in network.  Within the 3GPP R20 6G
     standardization research, AI agents have already been taken into
     consideration.  At the recent SA1#111 meeting, a total of 41
     proposals related to AI agents were submitted, including 18 new use
     cases, of which 6 were ultimately approved.  This paper primarily
     focuses on how network intelligence can enhance internal quality
     while simultaneously enabling external empowerment.  Specifically, AI
     agents play a dual role in 6G network: on the user and operator
     sides, they provide low-latency, high-reliability communication
     services based on real-time behavior prediction and resource



  Tong, et al.               Expires 6 May 2026                   [Page 2]


  Internet-Draft  Network AI Agent Use Cases and Requireme   November 2025


     scheduling, thereby improving network quality and user experience;
     for personalized requests from third-party applications, they expose
     network capabilities externally through AI agents, enabling external
     empowerment and fostering innovative scenarios such as smart
     healthcare IoT and immersive metaverse applications.  Section 2
     summarizes two categories of relevant cases, Section 3 describes the
     network framework and requirements, and Section 4 concludes this
     draft.

  1.1.  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  Use Cases

     In scenarios involving connectivity services, users or network
     administrators submit intent-based requests to the 6G network.  The
     network agent can perform accurate intent parsing, conduct task
     classification and planning, and delegate further strategy
     formulation and execution to hierarchical service agents, thereby
     completing network design in accordance with the service intent.  For
     new service scenarios such as AI, the network agent can provide AI
     capabilities from the network side based on the given intent.

  2.1.  Generative Network for Connectivity Services

     Based on service requirements or network status, users or network
     administrators can submit networking intents to the network.  These
     intents are then fulfilled by agents within the network, which
     perform cross-domain collaborative optimization and configuration of
     resources to achieve efficient generative networking.

  2.1.1.  Process Flow

     1.  David, a network administrator from a certain operator, submits
         the following request to the network: "A concert will be held at
         the downtown stadium tomorrow from 19:00 to 22:00.  Please design
         the network to smoothly handle the traffic surge while ensuring
         the fluency of key user services."

     2.  The 6G core network Task Orchestration Agent parses the
         networking intent requirement, performs an initial task
         breakdown, splits the task, and identifies the agents required
         for execution.  For example, the task is decomposed into multiple



  Tong, et al.               Expires 6 May 2026                   [Page 3]


  Internet-Draft  Network AI Agent Use Cases and Requireme   November 2025


         subtasks, including intelligent access, resource configuration,
         service identification, and service policy optimization,
         involving the Connectivity Agent and the QoS Assurance Agent.

     3.  The Task Orchestration Agent acquires the data necessary for task
         execution to support decision-making by the service agents.  For
         instance, it can invoke external tools to obtain historical data
         and predict the service scale for this networking task through
         intelligent forecasting and digital twin functionalities.  The
         subtask information is then distributed to the corresponding
         agents.  This information includes task descriptions, task
         identifiers, task requirements, and task data, supporting the
         delivery of structured data, intents, control commands, and other
         types of information to fully convey task instructions.

     4.  Upon receiving the intelligent access and resource configuration
         subtasks, the Connectivity Agent addresses user access requests
         within the area by employing intelligent access algorithms to
         schedule corresponding 6G network elements for efficient user
         access.  Based on the distribution of user types and services in
         the area, it utilizes a reinforcement-based generative policy
         model to allocate and optimize network resources.  During the
         decision-making process, in addition to using the data provided
         in the task information, the agent also interacts with network
         elements to obtain real-time data and performs enhanced data
         analysis.

     5.  The QoS Assurance Agent receives the subtasks for service
         identification and service policy optimization.  During the
         networking optimization task, the QoS agent activates the service
         identification function, providing a service basis for generating
         networking strategies through service recognition and quality
         degradation analysis.  According to the real-time status of
         services, it dynamically generates core network optimization
         strategies.  Meanwhile, leveraging its cross-domain coordination
         capability, it shares strategies with the RAN side to achieve
         refined resource allocation and optimize service quality.

     Based on the task agents' demand analysis and task planning, the
     Connectivity Agent and the QoS Assurance Agent, through intelligent
     access, dynamic resource configuration, precise service
     identification, quality degradation analysis, and leveraging policy
     generation capabilities, achieve efficient generative networking,
     thereby ensuring the highly effective execution of the task.







  Tong, et al.               Expires 6 May 2026                   [Page 4]


  Internet-Draft  Network AI Agent Use Cases and Requireme   November 2025


  2.1.2.  Analysis of AI Agent Roles

     This case involves two types of agents.  The first type is the
     central agent, which is responsible for receiving requests from users
     or network administrators, performing intent recognition, extracting
     detailed information, and decomposing tasks.  The second type of
     agent is oriented toward specific services and is responsible for
     task decomposition, policy generation, and execution.

     In this specific case:The role of the central agent is undertaken by
     the Task Orchestration Agent, which performs intent recognition on
     the network administrator's request, divides it into multiple
     subtasks, and extracts key task information to distribute to the
     corresponding second-type agents.

     The second-type agents are service agents, responsible for policy
     planning and execution of specific subtasks.  In this scenario, two
     service agents are involved: the QoS Assurance Agent and the
     Connectivity Agent.  Each agent, based on the subtask it receives,
     leverages its corresponding capabilities to collaboratively
     accomplish the networking task.

  2.2.  Network Capability Exposure to Third-Party Services

     The concert organizer initiates a high-value user recommendation
     request to the network via its official "AR Smart Interaction" app.
     The network then performs statistical analysis based on user contract
     data and service profiles, delivers the corresponding capability, and
     assists the third party in formulating a targeted push notification
     strategy for the app.

  2.2.1.  Process Flow

     1.  During the concert, the organizer provides an immersive
         interactive service through the official "AR Smart Interaction"
         app.  This third-party app platform sends an intent request to
         the Capability Exposure Agent to acquire user information for
         delivering customized services.  For example, a request may
         state: "Please provide me with relevant information for the users
         on the list, including user profiles, network quality, and
         service resource allocation, to facilitate customized services."
         Additionally, the Capability Exposure Agent also supports
         receiving specified data requests from the third-party app
         platform via standardized APIs.

     2.  The 6G core network Capability Exposure Agent parses the intent
         conveyed by the third-party app platform and decomposes it into
         tasks directed at the Service Customization Agent.  These tasks



  Tong, et al.               Expires 6 May 2026                   [Page 5]


  Internet-Draft  Network AI Agent Use Cases and Requireme   November 2025


         may include obtaining target user preferences, identifying high-
         demand users within the target group, and acquiring the network
         quality of target users.  The Capability Exposure Agent then
         dispatches these tasks to the Service Customization Agent.

     3.  Upon acquiring task information, the Service Customization Agent
         invokes data functions to retrieve the required analysis results.
         This retrieval is performed either from its internal data storage
         or by obtaining results from other agents and network elements.

     4.  If existing data cannot fully meet the application requirements,
         the Service Customization Agent can also retrieve raw data and
         utilize its built-in functions, such as user profiling and
         network quality assessment, to generate up-to-date analysis
         results.  For instance, it may interact with the Connectivity
         Agent to obtain network quality data for relevant users, which is
         then processed by its network quality assessment function to
         produce the required results.

     5.  After gathering all necessary information for the task, the
         Service Customization Agent reports the results back to the
         Capability Exposure Agent.

     6.  The Capability Exposure Agent then provides the requested
         information to the "Concert AR Smart Interaction" app platform
         via standardized APIs.

     7.  With the received data, the "Concert AR Smart Interaction" app
         platform can deliver customized services based on its own
         business logic.  Examples include selecting preferred interaction
         methods according to user profiles, recommending services likely
         to interest the user, and suggesting higher-quality service
         packages to high-value users.

  2.2.2.  Analysis of AI Agent Roles

     This case involves two categories of agents.  The first category is
     the central agent, responsible for receiving requests for third-party
     personalized services, performing intent recognition, extracting
     detailed information, and conducting task decomposition.  The second
     category comprises service agents, which are oriented toward specific
     services and handle task decomposition, policy generation, and
     execution.








  Tong, et al.               Expires 6 May 2026                   [Page 6]


  Internet-Draft  Network AI Agent Use Cases and Requireme   November 2025


     In this specific case:The role of the central agent is fulfilled by
     the Capability Exposure Agent, which performs intent recognition on
     requests from third-party applications and distributes subtasks to
     the Service Customization Agent.The Service Customization Agent is
     responsible for the analysis, execution, and feedback of the specific
     subtasks.

  3.  Architecture and Potential Requirements of AI Agent-Integrated 6G
      Network

  3.1.  AI Agent-Integrated 6G Network Framework

     The 6G network framework incorporating network AI agents is primarily
     structured into three layers:

     1.  The first layer is the Central Intelligence Layer, composed of
         the Task Orchestration Agent and the Capability Exposure Agent.
         The Task Orchestration Agent is responsible for receiving
         requests from the user side and the network management side.  The
         Capability Exposure Agent handles capability exposure requests
         from external applications.

     2.  The second layer is the Service Agent Layer, which consists of
         multiple service agents, including but not limited to the QoS
         Assurance Agent, Connectivity Agent, and Service Customization
         Agent.  Each service agent is responsible for the analysis,
         decision-making, and execution of its corresponding tasks.
         During operation, service agents need to communicate with network
         elements and external tools to collaboratively complete their
         assigned tasks.

         *  The functionalities of the QoS Assurance Agent may include
            service identification, quality degradation analysis, and
            dynamic parameter adjustment.

         *  The functionalities of the Connectivity Agent may include
            intelligent access, mobility management optimization, and
            resource configuration.

         *  The functionalities of the Service Customization Agent may
            include user profiling, network quality assessment, and
            service orchestration.

         By leveraging their respective capabilities, the service agents
         work in coordination to accomplish specific tasks.






  Tong, et al.               Expires 6 May 2026                   [Page 7]


  Internet-Draft  Network AI Agent Use Cases and Requireme   November 2025


     3.  The third layer is the Atomic Capability Layer, which comprises
         network elements and tools.  This layer provides the fundamental
         capabilities required for the service agents to execute their
         various tasks.

  3.2.  Potential Network Requirements

     Based on the above case studies and framework, the network side must
     possess the following capabilities:

     1.  The network must support the reception of intent-based requests,
         such as user-side intents, network management intents, and third-
         party requests for capability exposure.  The central-layer agents
         must be capable of identifying and parsing these intents.

     2.  The network must support communication protocols between AI
         agents, enabling direct interaction among network AI agents to
         collaboratively complete tasks.

     3.  The network must support communication protocols between AI
         agents and external tools or network elements.  During task
         execution, service agents need to invoke network elements or
         specific tools to fulfill their responsibilities.

     4.  The network must possess identity management capabilities for
         network AI agents.  For instance, the Task Orchestration Agent
         should manage the identities and capabilities of other agents to
         assign specific subtasks to the appropriate agents.  Similarly,
         the Connectivity Agent should be able to manage the identities of
         external AI agents, ensuring their secure access and supporting
         on-demand networking, among other requirements.

     5.  The network must enable the exposure of network AI agent
         capabilities to external parties, thereby supporting innovative
         third-party services.

  4.  Conclusion

     In 6G network, AI agents can function both as communication entities
     and as tools for empowering the network.  This chapter analyzes the
     potential benefits of introducing AI agents into 6G through two types
     of case studies.  It also examines how network AI agents can be
     integrated into the 6G architecture and identifies the corresponding
     network requirements.







  Tong, et al.               Expires 6 May 2026                   [Page 8]


  Internet-Draft  Network AI Agent Use Cases and Requireme   November 2025


  5.  IANA Considerations

     This memo includes no request to IANA.

  6.  Security Considerations

     This document should not affect the security of the Internet.

  7.  References

  7.1.  Normative References

     [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/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

  7.2.  Informative References

     [TR22.870] 3GPP TR 22.870, "Study on 6G Use Cases and Service
                Requirements", 2025.

  Authors' Addresses

     Ying Tong
     China Telecom
     Beiqijia Town, Changping District
     Beijing, 102209
     China
     Email: tongy@chinatelecom.cn


     Ao Sun
     China Telecom
     Beiqijia Town, Changping District
     Beijing, 102209
     China
     Email: suna1@chinatelecom.cn









  Tong, et al.               Expires 6 May 2026                   [Page 9]


  Internet-Draft  Network AI Agent Use Cases and Requireme   November 2025


     Aijun Wang
     China Telecom
     Beiqijia Town, Changping District
     Beijing, 102209
     China
     Email: wangaj3@chinatelecom.cn


     Yang Liu
     China Telecom
     Beiqijia Town, Changping District
     Beijing, 102209
     China
     Email: liuyang19@chinatelecom.cn


     Yuanbao Xie
     China Telecom
     Huajing NewTown，Tianhe District
     Guangzhou
     Guangdong, 510630
     China
     Email: xieyuanb@chinatelecom.cn




























  Tong, et al.               Expires 6 May 2026                  [Page 10]


name: draft-men-rtgwg-agent-networking-in-digibank
rev: 00
title: Agent Networking Scenarios of Digital Banking
time: 2025-11-02T13:17:37Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T13:17:37Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-03T15:50:09.773519+00:00
abstract:
  This document describes several typical digital banking scenarios,
     and discusses the trend of banking digitalization evolving to agentic
     service inteconnection.  Then, this document proposes an agent
     networking architecture based on the core component which is agent
     gateway.

full_text:
  rtgwg                                                             X. Men
  Internet-Draft                                                   Y. Fang
  Intended status: Informational                                  UnionPay
  Expires: 6 May 2026                                               B. Liu
                                                                    Q. Gao
                                                                   N. Geng
                                                                  X. Shang
                                                                     Z. Li
                                                       Huawei Technologies
                                                           2 November 2025


               Agent Networking Scenarios of Digital Banking
              draft-men-rtgwg-agent-networking-in-digibank-00

  Abstract

     This document describes several typical digital banking scenarios,
     and discusses the trend of banking digitalization evolving to agentic
     service inteconnection.  Then, this document proposes an agent
     networking architecture based on the core component which is agent
     gateway.

  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 May 2026.

  Copyright Notice

     Copyright (c) 2025 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.



  Men, et al.                Expires 6 May 2026                   [Page 1]


  Internet-Draft         Agents Networking Scenarios         November 2025


     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
       1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   2
       1.2.  Agent Requirements in Digital Banking Scenarios . . . . .   3
       1.3.  Introduction of Agent Gateway and Networking
             Architecture  . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     3.  Modern Digitalization of Banking Services . . . . . . . . . .   4
       3.1.  Example Scenario 1: IPO Bank Statement Auditing . . . . .   4
       3.2.  Example Scenario 2: Retail Credit . . . . . . . . . . . .   5
       3.3.  Example Scenario 3: Bank Electronic Certificate
             Services  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Bank Union and Digital Interconnection  . . . . . . . . . . .   5
       4.1.  Bank Union Organization . . . . . . . . . . . . . . . . .   5
       4.2.  Digital Interconnection among Bank Union Members  . . . .   6
       4.3.  AS-IS: API-based Service Calling  . . . . . . . . . . . .   6
       4.4.  TO-BE: Agentic Service Interconnection  . . . . . . . . .   7
     5.  Proposed Agent Networking Architecture  . . . . . . . . . . .   7
       5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   7
       5.2.  Agent Gateway as a Key Enabler  . . . . . . . . . . . . .   8
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
     9.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

  1.1.  Background

     With the rapid development of FinTech (Financial Technology), the
     digital banking business is undergoing profound changes.  Traditional
     banking systems face performance bottlenecks and integration
     challenges when it comes to handling cumbersome corporate audits,
     high-frequency electronic transaction certificate, and deeply
     customized user experiences.  The maturity of Artificial Intelligence
     (AI) technology, especially the emergence of the AI Agent, provides a
     new paradigm for solving these challenges.  AI Agents, capable of
     autonomous decision-making and task execution, are becoming the core
     components for building the next generation of intelligent financial



  Men, et al.                Expires 6 May 2026                   [Page 2]


  Internet-Draft         Agents Networking Scenarios         November 2025


     services.

  1.2.  Agent Requirements in Digital Banking Scenarios

     In the digital banking business, the application scenarios for AI
     Agents cover customer service, fraud detection, personalized
     investment recommendations, smart contract management, and complex
     compliance checks etc.  These tasks often require the collaborative
     work of multiple Agents with different capabilities.  For instance, a
     loan application may require one Agent for identity verification, a
     second Agent for credit scoring, and a third Agent for compliance
     review.  This multi-Agent collaboration model necessitates a unified,
     efficient, and secure coordination mechanism.

  1.3.  Introduction of Agent Gateway and Networking Architecture

     To achieve efficient, reliable, and secure networking and interaction
     among Agents, this proposal introduces the concept of the Agent
     Gateway and a networking architecture based on it.  The Agent Gateway
     acts as a critical hub in the Agent ecosystem, responsible for:

     *  Agent Registration and Discovery: Allowing Agents to efficiently
        discover and invoke other Agents or external services.

     *  Efficient Agent Communication: Agents can delegate functions like
        message routing and group communication to the Gateway, allowing
        them to focus more on business-specific implementation.

     *  Security and Authentication: Providing a unified mechanism for
        authentication, authorization, and data encryption to ensure the
        security of financial data.

     The networking architecture built upon the Agent Gateway is designed
     to provide an open, interoperable framework, enabling Agents
     developed by different vendors to be securely and seamlessly
     integrated into the digital banking business process.  Furthermore,
     the gateway-based implementation method can greatly simplify an
     enterprise's deployment and operations.

  2.  Terms and Definitions

     *  Digital Banking: refers to the end-to-end digitization of
        traditional banking services.








  Men, et al.                Expires 6 May 2026                   [Page 3]


  Internet-Draft         Agents Networking Scenarios         November 2025


     *  Agent Gateway: a "Connection Hub" and "Security Steward" in the
        process of agent communication.  Its core role is to resolve
        interconnection issues between different Agents of different
        domains while ensuring secure, efficient, and orderly
        communication.

  2.1.  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  3.  Modern Digitalization of Banking Services

  3.1.  Example Scenario 1: IPO Bank Statement Auditing

     o Business Scenario:

     During the process of a company's Initial Public Offering (IPO), the
     Sponsor Institution (often an investment bank) is required to review
     the bank transaction records of the prospective listed company, its
     directors, supervisors, senior management (D&S&SM), and key
     personnel.  This is done to understand related party transactions and
     fund transfers, and to verify:

     *  Whether the disclosure of related parties and related party
        transactions is complete.

     *  Whether there is any suspicion of fictitious revenue through off-
        book fund cycling.

     *  Whether there is undue benefit transfer or other undisclosed
        benefit arrangements.

     o Traditional Offline Method:

     The above process traditionally required the Sponsor Institution to
     accompany the relevant subjects being investigated to major local
     bank branches to print the bank statements (flow records) in person.

     o Existing API Method (Digital Banking Approach):








  Men, et al.                Expires 6 May 2026                   [Page 4]


  Internet-Draft         Agents Networking Scenarios         November 2025


     Based on a Digital Banking Union Platform (i.e., China UionPay’s
     Platform), the original offline process is transitioned online.  With
     the full authorization of the subject, the Sponsor Institution sends
     a request to the bank via the digital platform.  The bank then
     returns the transaction record information to the Sponsor Institution
     through the digital platform.

  3.2.  Example Scenario 2: Retail Credit

     Leveraging the streamlined retail payment process flow as a
     foundational layer, the goal is to equip commercial banks with the
     capabilities to deliver standardized and highly accessible Inclusive
     Finance services to their retail customers.

     This strategic integration transcends simple transactional banking,
     culminating in a powerful, synergistic model that forms a
     comprehensive "Finance + Payment + Service" ecosystem capability.
     This integrated approach ensures consistent user experience,
     significantly lowers the barrier to financial access for underserved
     populations, and establishes the bank as a pivotal digital financial
     hub.

  3.3.  Example Scenario 3: Bank Electronic Certificate Services

     To significantly enhance the efficiency and transparency of the
     corporate client experience, we will deploy secure, automated
     services for the inquiry and compliant download of essential
     financial documents, including electronic receipts and electronic
     account statements.

     This digital transformation is not merely an operational upgrade but
     a strategic move to solidify the value proposition of the Banking
     Union's corporate business line, driving increased customer
     satisfaction, reducing operational friction, and accelerating the
     overall digitization of B2B financial services.

  4.  Bank Union and Digital Interconnection

  4.1.  Bank Union Organization

     A Banking Union Organization typically refers to a non-profit joint
     organization collectively initiated and established by numerous
     member financial institutions.  Its core objective is to build and
     operate a unified, efficient interbank transaction processing and
     clearing network.  Taking China UnionPay as an example, it connects
     disparate bank card payment systems across different banks and
     regions by establishing and implementing uniform business rules and
     technical standards.



  Men, et al.                Expires 6 May 2026                   [Page 5]


  Internet-Draft         Agents Networking Scenarios         November 2025


     In essence, a Banking Union Organization acts as the "Public
     Infrastructure" and "Rule-Setter" in the payment domain.  Through
     resource integration and collaboration, it constructs a vast,
     convenient, and secure financial payment ecosystem for its member
     institutions and the general public.

  4.2.  Digital Interconnection among Bank Union Members

     All member banks adhere to the unified technical standards and data
     formats established by the alliance, seamlessly integrating their
     core systems with the alliance's central clearing platform to achieve
     digital-level interconnection.

     Taking the aforementioned case of IPO auditing as an example: when a
     company applies for listing, underwriters and lawyers need to conduct
     a thorough review of the company's bank account transactions to
     verify the authenticity of its revenue and the compliance of its
     funds.  If the company holds accounts in dozens of different banks
     across the country, this review process becomes extremely cumbersome.
     At this point, the digital interconnection system established by the
     banking alliance (such as China UnionPay) plays a critical role.

     Although the company's accounts are dispersed across various member
     banks, these banks have achieved unified data standards and system
     interoperability through UnionPay's underlying financial network.
     Auditing institutions, with the company's authorization, can access a
     standardized data interface and initiate query requests to the
     alliance network.  These requests are instantly routed to the backend
     systems of each bank using a unified digital interface.
     Subsequently, the company's transaction records, scattered across
     different member institutions, can be securely, accurately, and
     efficiently aggregated and returned.

  4.3.  AS-IS: API-based Service Calling

     Traditional API calls demonstrate significant limitations when
     dealing with complex and ever-changing business environments.

     *  Firstly, there is the issue of Fragility and Rigidity.
        Traditional automation relies on hard-coded workflows and
        predefined logic.  In the banking sector, even minor changes in
        business logic or underlying system behavior can disrupt automated
        processes, requiring manual reconfiguration.  This fragility makes
        it difficult for systems to adapt to real-time changes.







  Men, et al.                Expires 6 May 2026                   [Page 6]


  Internet-Draft         Agents Networking Scenarios         November 2025


     *  Secondly, there is a lack of active decision.  Traditional APIs
        typically execute tasks only after receiving instructions,
        providing options or suggestions.  Unlike Agents, which could
        autonomously interpret complex input signals, decide on the
        necessary sequence of actions across multiple systems.

     *  Finally, in traditional architectures, connecting multiple
        enterprise systems—such as CRM, ERP, and payment systems—often
        requires a complex, centrally defined orchestration layer managed
        by developers.  This centralized control is prone to bottlenecks
        and limits flexible cross-functional collaboration.

  4.4.  TO-BE: Agentic Service Interconnection

     Agentic interconnection/orchestration fundamentally overturns the
     traditional models mentioned above by introducing goal-centric,
     adaptive execution capabilities.

     *  Agents treat APIs as dynamic building blocks rather than fixed
        execution paths.  Based on real-time context and shared memory,
        they flexibly select and invoke the most relevant APIs, enabling
        collaboration across various systems.  This "context-aware
        decision-making" capability allows Agents to achieve more
        efficient cross-system integration than rigid, hard-coded scripts.

     *  Agentic workflows tackle complex problems using a multi-step,
        iterative approach.  They are capable of dynamically adapting to
        real-time data and unexpected conditions, a feat that fixed-rule
        systems cannot easily achieve.

     In short, Agentic AI represents the next phase of enterprise digital
     transformation.  For digital banking, it is no longer optional but is
     the inevitable path to achieving operational excellence and strategic
     growth.

  5.  Proposed Agent Networking Architecture

  5.1.  Overview

     In the banking industry, Agentic systems could categorized into two
     deployment models:

     *  Single-Agent Systems: In these systems, a single AI Agent
        processes all tasks sequentially.  They are generally suitable for
        well-defined problems or processes requiring rapid resolution,
        such as dedicated fraud monitoring or automated report generation.





  Men, et al.                Expires 6 May 2026                   [Page 7]


  Internet-Draft         Agents Networking Scenarios         November 2025


     *  Multi-Agent Systems (MAS): MAS involve multiple AI Agents
        collaborating to break down complex workflows into smaller parts.
        MAS are crucial for handling sophisticated banking workflows, such
        as credit underwriting, which involves both risk scoring and
        treasury management.  MAS typically adopt a horizontal
        collaborative structure where each Agent focuses on a narrow skill
        (e.g., a Compliance Agent or a Risk Agent) and then integrates
        their respective analyses.  This model offers higher scalability
        and flexibility but places greater demands on the mechanisms for
        inter-Agent communication, coordination, and state sharing.

     The key challenge in realizing this vision lies in constructing an
     Agent networking architecture that supports decentralization, secure
     collaboration, and stateful communication.

  5.2.  Agent Gateway as a Key Enabler

     As the banking industry advances toward agentic digitization,
     securely efficiently integrating AI agents into internal banking
     systems has become a critical challenge.  In this context, the Agent
     Gateway could serve a core component for enabling this
     transformation.  Its importance is primarily reflected in the
     following three aspects:

     *  First, the Agent Gateway serves as a communication hub for
        intelligent collaboration.  It facilitates coordinated work among
        multiple AI agents by implementing unified communication protocols
        and context management, ensuring that different agents can execute
        complex business processes in an orderly and efficient manner.

     *  Second, the Agent Gateway acts as a foundation for security and
        compliance.  Functioning as a centralized access control node, it
        authenticates identities, checks permissions, and audits
        operations for all AI agents, ensuring that every action complies
        with financial regulatory requirements and safeguarding system
        security from the source.

     *  Lastly, the Agent Gateway can also serve as a simplification/
        adaptation layer for complex systems.  It encapsulates the
        intricate APIs, data sources, and business systems within banks
        into standardized services, allowing AI agents to directly invoke
        required functions without needing to understand backend technical
        details, thereby significantly reducing the complexity of system
        integration.







  Men, et al.                Expires 6 May 2026                   [Page 8]


  Internet-Draft         Agents Networking Scenarios         November 2025


  6.  Security Considerations

     TBD

  7.  IANA Considerations

     This document has no IANA requirements.

  8.  Acknowledgements

     TBD

  9.  Normative References

     [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>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  Authors' Addresses

     Xiaohua Men
     UnionPay
     Beijing
     China
     Email: menxiaohua@unionpay.com


     Yulun Fang
     UnionPay
     Beijing
     China
     Email: fangyulun@unionpay.com


     Bing Liu
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: leo.liubing@huawei.com






  Men, et al.                Expires 6 May 2026                   [Page 9]


  Internet-Draft         Agents Networking Scenarios         November 2025


     Qiangzhou Gao
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: gaoqiangzhou@huawei.com


     Nan Geng
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: gengnan@huawei.com


     Xiaotong Shang
     Huawei Technologies
     No. 156 Beiqing Road
     Beijing
     China
     Email: shangxiaotong@huawei.com


     Zhenbin Li
     Huawei Technologies
     Beijing
     China
     Email: robinli314@163.com






















  Men, et al.                Expires 6 May 2026                  [Page 10]


