Dynamic Multi-agent Secured Collaboration Infrastructure Architecture
draft-li-dmsc-inf-architecture-07
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Xueting Li , Aijun Wang , Bing Liu , Changwang Lin | ||
| Last updated | 2026-05-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-dmsc-inf-architecture-07
DMSC Working Group X. Li
Internet-Draft A. Wang
Intended status: Standards Track China Telecom
Expires: 23 November 2026 B. Liu
Huawei Technologies
C. Lin
New H3C Technologies
22 May 2026
Dynamic Multi-agent Secured Collaboration Infrastructure Architecture
draft-li-dmsc-inf-architecture-07
Abstract
This document presents an architectural framework for dynamic multi-
agent collaboration from an infrastructure perspective. It outlines
the network requirements introduced by large-scale agents
collaboration, and proposes a systematic approach to enabling Dynamic
Multi-agent Secured Collaboration (DMSC) through infrastructure
capabilities. The architecture focuses on how network control and
forwarding functions can actively participate in agent collaboration.
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 November 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.
Li, et al. Expires 23 November 2026 [Page 1]
Internet-Draft DMSC Architecture May 2026
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 used in this document . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Network Requirements . . . . . . . . . . . . . . . . . . . . 4
5. DMSC Architecture Overview . . . . . . . . . . . . . . . . . 5
5.1. DMSC Infrastructure Architecture . . . . . . . . . . . . 5
6. Infrastructure Functions Enabling Active Network
Participation . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Agent Identification and Capability Directory . . . . . . 8
6.2. Infrastructure-Level Agent Discovery . . . . . . . . . . 8
6.3. Semantic Routing . . . . . . . . . . . . . . . . . . . . 8
6.4. Secure Collaboration Capability and Policy . . . . . . . 9
6.5. Operational Visibility . . . . . . . . . . . . . . . . . 9
7. Deployment Usecases . . . . . . . . . . . . . . . . . . . . . 10
7.1. Fixed Network . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Mobile Operator Network . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14
11. Normative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Intelligent agents have evolved rapidly in recent years, driven by
advances in artificial intelligence models, computing platforms, and
network connectivity. Early forms of agents were typically embedded
within isolated systems and designed to perform narrowly defined
tasks under predefined conditions. Their interactions with external
entities were limited and often mediated by tightly coupled
application logic [IoA].
Li, et al. Expires 23 November 2026 [Page 2]
Internet-Draft DMSC Architecture May 2026
With the increasing availability of large-scale AI models, edge
computing resources, and programmable network infrastructures, agents
are becoming more autonomous, adaptive, and capable of operating
across distributed environments. Modern agents can perceive changes
in their environment, make decisions based on local or shared
information, and interact with other agents and tools in order to
achieve complex objectives. These interactions are no longer
confined to static configurations or single administrative domains,
but increasingly span devices, networks, and application platforms.
As agents continue to proliferate, they are forming large-scale
collaborative systems in which multiple agents dynamically discover
each other, exchange information, and coordinate actions. Such
systems exhibit highly dynamic behavior, including frequent changes
in agent population, roles, and interaction patterns. The resulting
agent ecosystems resemble an open, interconnected environment rather
than a collection of isolated applications.
The evolution toward large-scale, dynamic agent ecosystems introduces
new challenges for the underlying network infrastructure. While
agents are capable of sophisticated reasoning and decision-making,
their ability to collaborate effectively depends on the availability
of common, scalable, and interoperable networking support.
This document focuses on the architectural aspects of enabling
dynamic multi-agent collaboration from a network and infrastructure
perspective. It examines how network control and forwarding
functions can be extended to recognize agents as first-class entities
and provide generic support for agent identification, discovery,
semantic routing, and coordination. The architecture is intended to
support a wide range of agent types, including on-device agents,
network-resident agents, and third-party agents, without imposing
assumptions about their internal implementation.
The scope of this document is limited to architectural concepts and
functional building blocks. It does not define specific protocols,
data models, or security mechanisms, nor does it prescribe particular
deployment scenarios or application workflows. Instead, it provides
a foundational framework upon which more detailed specifications,
including protocol designs and security architectures, can be
developed in subsequent documents.
2. Conventions used in this document
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 [RFC2119] .
Li, et al. Expires 23 November 2026 [Page 3]
Internet-Draft DMSC Architecture May 2026
3. Terminology
The following terms are defined in this draft:
* DMSC: Dynamic Multi-agent Secured Collaboration. The framework
and infrastructure enabling secure and efficient collaboration
among dynamic agents.
* Agent: An automated intelligent entity capable of e.g interacting
with its environment, acquiring contextual information, reasoning,
self-learning, decision-making, executing tasks (autonomously or
in collaboration with other Al Agents) to achieve a specific goal.
* Agent Gateway: The Agent Gateway is a functional entity that
serves as the infrastructure for enabling interconnection and
collaboration among agents. While its core role remains
consistent, it is inherently flexible in deployment and can be
realized in various forms—ranging from a network service to a
dedicated gateway—depending on the architectural and operational
requirements of different network environments.
* Agent Management Center (AMC): It is the trusted infrastructure
service responsible for agent identity lifecycle management and
credential issuance.
4. Network Requirements
The proliferation of intelligent agents fundamentally reshapes
interaction patterns and control dynamics in future networks. Agent
interactions are typically short-lived, context-dependent, and driven
by task semantics rather than static endpoints. Moreover, agents may
dynamically join or leave collaborative groups, migrate across
administrative domains, or change roles over time. These
characteristics introduce new requirements for network
infrastructures, including agent-level identity management,
capability-aware communication, scalable registration and discovery,
cross-domain collaboration support, and adaptive routing, as also
reflected in [draft-yu-ai-agent-use-cases-in-6g].[usecase]
Collectively, these requirements indicate that future networks must
go beyond passive connectivity and actively support dynamic multi-
agent collaboration. The core idea of Dynamic Multi-agent Secured
Collaboration (DMSC) is to elevate key collaboration-related
functions into the network infrastructure. Instead of embedding all
coordination logic within applications or agent frameworks, DMSC
leverages infrastructure-level capabilities exposed through control-
plane and forwarding-plane functions. This approach enables the
network to recognize agents as first-class entities, maintain high-
Li, et al. Expires 23 November 2026 [Page 4]
Internet-Draft DMSC Architecture May 2026
level collaboration context, and make informed decisions on
discovery, routing, and coordination support in a scalable and
interoperable manner.
5. DMSC Architecture Overview
5.1. DMSC Infrastructure Architecture
Figure 1 illustrates the overall architecture for dynamic multi-agent
collaboration from an infrastructure-centric perspective. The
architecture positions the network infrastructure as an active
participant in agent collaboration, while preserving the autonomy and
task-level reasoning of individual agents. In this architecture, the
network does not execute agent logic or interpret task semantics.
Instead, it provides generic support functions that enable agents to
collaborate more efficiently and reliably. Agents remain autonomous,
while the network supplies shared infrastructure capabilities.
From an infrastructure perspective, the architecture is organized
into three logical layers:
* Management Plane: governs authentication, capability taxonomy,
observability and policy aspects.
* Control Plane: Manages agent registration, discovery, invocation,
lifecycle, and capability information maintenance and so on.
* Forwarding Plane: Supports semantic routing for agent
interactions.
Li, et al. Expires 23 November 2026 [Page 5]
Internet-Draft DMSC Architecture May 2026
+------------------------------------------------------------------------------------+
| Management & Orchestration Plane |
| +--------------+ +-------------------+ +-----------------+ +--------------+ |
| | Agent | |Capability Taxonomy| | Observability & | |Policy Manager| |
| |Authentication| |(Agent,Capability) | | Analytics | | (Rules...) | |
| +--------------+ +-------------------+ +-----------------+ +--------------+ |
+------------------------------------------------------------------------------------+
| ^
v |
+-------------------------------------------------------------------------------------------+
| Network Infrastructure |
| +---------------------------------------------------------------------------------------+ |
| | AGW 1 AGW 2 AGW 3 ... | |
| | +-------------------------+ +-------------------------+ +--------------------+ | |
| | | Control Plane | | Control Plane | | Control Plane | | |
| | |-------------------------| |-------------------------| |--------------------| | |
| | | - Agent Registration |<-->| - Agent Registration |<--> | ... | | |
| | | - Agent Invocation | | - Agent Invocation | | | | |
| | | - Agent Discovery | | - Agent Discovery | | | | |
| | | - Capability Directory | | - Capability Directory | | | | |
| | +-------------------------+ +-------------------------+ +--------------------+ | |
| | | Control & Policy | Control | Control | |
| | v v & Policy v & Policy | |
| | +------------------------+ +-------------------------+ +-------------------+ | |
| | | Forwarding Plane | | Forwarding Plane | | Forwarding Plane | | |
| | |------------------------+ +-------------------------+ +-------------------+ | |
| | | - Semantic Routing | | ... | | ... | | |
| | | - ... | | | | | | |
| | +------------------------+ +-------------------------+ +-------------------+ | |
| +---------------------------------------------------------------------------------------+ |
+------------------^ ------------------------^ ------------------------------^ ------------+
|Registration | Registration |Registration
| | |
+--------------------+ +--------------------+ +--------------------+
| Agent A | | Agent B | | Agent C |
|--------------------| |--------------------| |--------------------|
| - Capabilities | | - Capabilities | | - Capabilities | ...
| - Local Reasoning | | - Local Reasoning | | - Local Reasoning |
+--------------------+ +--------------------+ +--------------------+
Figure 1 The infrastructure architecture of dynamic multi-agent collaboration
On top of this architecture, agents engage in collaborative
activities driven by task intents, shared goals, and capability
information. Agents are responsible for local reasoning, decision-
making, and execution of task-specific logic. The network does not
interpret agent semantics or execute agent logic; instead, it
provides common infrastructure capabilities that support efficient
and scalable collaboration among agents. Above the network
Li, et al. Expires 23 November 2026 [Page 6]
Internet-Draft DMSC Architecture May 2026
infrastructure, a Management and Orchestration Plane provides non-
real-time management functions, including agent authentication, agent
capability taxonomy management, policy management, observability and
analytics. This plane supplies policy, trust, and state-related
inputs to the network infrastructure.
The network infrastructure itself is composed of multiple agent
gateways, each implementing a common set of logical functions, and
the gateways support hierarchical deployment. Within each gateway,
the Control Plane provides agent-aware control functions, including
agent identity management, capability directory maintenance,
registration, and discovery control. These functions enable the
network to recognize agents as first-class entities and maintain a
consistent view of agent-related information across the
infrastructure. By decoupling agent identity from physical location
through capability identifiers, the control plane supports dynamic
agent lifecycle events such as mobility, instantiation, and
termination.
The Forwarding Plane supports semantic routing by forwarding requests
based on capability identifiers—such as /capability/ocr—rather than
static IP addresses. When multiple instances of a capability are
available, the forwarding plane may select a target based on real-
time health and availability information—such as liveness or
load—provided by the control plane. In the event of failure, it can
perform fast failover to an alternative instance within the same
capability group, ensuring continuity of service.
When an agent joins the network, it authenticates and obtains trusted
authorization through network controller; only verified agents may
register their capabilities—such as “supports high-precision OCR” or
“performs GDPR-compliant de-identification”—which are stored locally
to form a capability directory. When another agent issues a
capability-based discovery request (e.g., “find an OCR agent”), the
local agent gateway either responds directly or securely synchronizes
capability information with other agent gateways—including across
domains or clouds—to locate eligible candidates. Once a target is
identified, the request is forwarded via semantic routing (e.g.,
using /capability/ocr) to the appropriate instance.
Overall, this architecture establishes a clear division of
responsibilities: agents focus on intelligent behavior and task
execution, while the network infrastructure provides capability-based
control, semantic forwarding, and secure coordination mechanisms.
This separation enables dynamic multi-agent collaboration to scale
across heterogeneous environments—on-premises, at the edge, or in the
cloud—while allowing agents and the network to evolve independently.
Li, et al. Expires 23 November 2026 [Page 7]
Internet-Draft DMSC Architecture May 2026
6. Infrastructure Functions Enabling Active Network Participation
6.1. Agent Identification and Capability Directory
In large-scale dynamic multi-agent environments, agents cannot be
effectively supported using traditional host- or service-based
identifiers alone. Agents may be instantiated dynamically, migrate
across network locations, or operate concurrently on the same
physical node. As a result, the network requires a mechanism to
identify agents as logical entities that are decoupled from network
topology.
The proposed architecture introduces network-visible agent
identifiers that represent agents independently of their physical
location or hosting environment. These identifiers enable the
network to consistently recognize agents across control and
forwarding functions, even as underlying network bindings change.
Beyond basic identification, the architecture supports forming an
agent capability directory on agent gateways.
6.2. Infrastructure-Level Agent Discovery
Agent discovery is a fundamental prerequisite for collaboration, yet
traditional discovery mechanisms are typically designed for
relatively static services or tightly scoped environments. In
contrast, multi-agent collaboration requires discovery mechanisms
that can operate across heterogeneous platforms, adapt to dynamic
agent populations, and respect administrative boundaries.
In DMSC architecture, agent discovery is provided as an
infrastructure-level function, rather than being entirely implemented
within agent frameworks. The network supports discovery queries
based on agent identifiers, advertised capabilities. This allows
agents to locate suitable collaborators without requiring global
knowledge or centralized coordination.
6.3. Semantic Routing
Traditional routing mechanisms forward packets based on destination
addresses without awareness of application intent. In dynamic multi-
agent collaboration, however, interactions are driven by *what* is
needed—such as a specific capability—rather than *where* a fixed
endpoint resides. The DMSC architecture addresses this by
introducing semantic routing: requests are expressed in terms of
agent capabilities (e.g., "/capability/ocr").
Li, et al. Expires 23 November 2026 [Page 8]
Internet-Draft DMSC Architecture May 2026
Semantic routing enables flexible agent invocation without hard-coded
endpoints. A request for a given capability can be routed to any
authorized and available instance that has declared that capability.
If the selected instance becomes unavailable, the network may fail
over to another instance within the same capability group, provided
such redundancy exists.
6.4. Secure Collaboration Capability and Policy
Effective collaboration among dynamic agents requires consistent
handling of capabilities and policies, especially when interactions
span multiple domains or network segments. The DMSC architecture
supports secure synchronization of capability declarations and policy
constraints at the infrastructure level.
Capability information associated with an agent—such as its declared
functions (e.g., OCR, payment validation) and security attributes
(e.g., GDPR compliance, authentication requirements)—can be
registered with the control plane and synchronized across domains.
Where appropriate, these capability descriptions may be bound to
policy rules that govern access and interaction. Security-related
attributes, such as authorization scope or domain-specific
constraints, can be attached to capability entries to ensure that
interactions remain compliant with local regulations and trust
boundaries. In cross-domain scenarios, policy abstraction mechanisms
support controlled translation or normalization to enable
interoperability while respecting local governance.
6.5. Operational Visibility
As multi-agent systems scale, gaining visibility into collaboration-
level behavior becomes essential for effective operation and
troubleshooting. Traditional network observability focuses on flows
and endpoints, offering limited insight into agent interactions and
coordination dynamics. The DMSC architecture introduces operational
visibility at the collaboration level by enabling controlled
observation of key interaction events.
Observable entities may include:
* Agent registration and abstract capability advertisements.
* Capability-based discovery activities and outcomes.
* Semantic routing decisions and high-level invocation outcomes.
* Association with network resources and applied policy controls.
Li, et al. Expires 23 November 2026 [Page 9]
Internet-Draft DMSC Architecture May 2026
This visibility is not intended to expose agent internals or infer
application logic, but to provide sufficient information for
monitoring, auditing, root cause analysis, and performance
optimization. The collected telemetry can be used by management and
orchestration systems to support long-term optimization—such as
identifying underutilized capabilities or detecting policy
violations. It may also inform policy refinement and infrastructure
planning, but does not drive real-time control-plane decisions or
forwarding-plane behavior. To address privacy and security concerns,
exposure of observable data is controlled through policy mechanisms,
ensuring that only authorized parties can access relevant
information.
7. Deployment Usecases
This section presents two deployment cases for fixed network and
mobile network environments respectively, illustrating the practical
implementation of the proposed architecture. This is not intended to
restrict implementation solutions, but to demonstrate how network
infrastructure defined in the architecture can be deployed by
leveraging existing or upgraded network elements.
7.1. Fixed Network
In a fixed broadband network, gateways can be implemented as enhanced
agent gateways deployed at aggregation layers or service edge nodes.
These AGWs are positioned logically between access networks and
service domains, enabling them to perform registration, authorization
mediation, capability abstraction, and semantic routing functions
without requiring changes to end-user access infrastructure.
In such deployments as shown in figure 6:
* Agent registration and authentication are performed via the AGW
and Agent Management Center (AMC).
* Capability digest exchange occurs between AGWs.
* Semantic resolution is handled hop-by-hop across AGWs.
* Agents establish peer-to-peer semantic sessions after gateway-
mediated coordination.
This example shows that agent gateways in fixed network can be
equipped with logical coordination functions to serve as functional
gateways, enabling agent registration, synchronization, scheduling
and other related operations.
Li, et al. Expires 23 November 2026 [Page 10]
Internet-Draft DMSC Architecture May 2026
+------------------------------+
+----| Agent Management Center |------+
| +------------------------------+ |
| |
+----------+ +---------+ +---------+ +---------+
| Agent A | ---- | AGW 1 |<-------------+ +------------->| AGW 2 |---| Agent B |
+----------+ +---------+ | | +---------+ +---------+
| |
+------------+
| Routers |
+------------+
Figure 2 Deployment Example: Fixed Network with Agent Gateway Realization
7.2. Mobile Operator Network
In a mobile operator network (e.g., a 6G network), AI capabilities
and technologies are expected to be leveraged subject to operator
policies and configurations. AI Agents, which refer generally to
agents that autonomously perform tasks on behalf of users, systems,
and/or applications, can understand complex requests and improve
network efficiency. In addition, capabilities and services such as
sensing, real-time data processing, telemetry, analytics, and others
within a 6G network may also be provided as “Tools” to third-party
applications.
Below figure shows an example of AI agents, an Agent Management
Center and an Agent Gateway deployed in the mobile operator network.
The architecture of 6G is still in discussion, thus some
functionalities are described by using some 5G NFs as typical
examples.
User initiates intent in nature language and receive human-readable
result. Intent analysis takes place at two stages:
* (Optional, based on UE capabilities) The UE converts natural-
language intent to operator-defined intent and also translates
operator-defined results to human-readable results based on
internal implementation.
* (Mandatory) The network function (NF) with agent capability in the
mobile operator core network comprehends and analyzes the intent.
Based on the analyzed intent, a subsequent workflow is generated.
Typically, the NF that terminates NAS messages (e.g., AMF in 5G)
can either comprehend the intent (when the AMF includes agent
capability) or forward the intent to an agent-enabled NF in the
core network (when the AMF does not include agent capability).
Li, et al. Expires 23 November 2026 [Page 11]
Internet-Draft DMSC Architecture May 2026
Agent-enabled NFs request AIC allocation from the Agent Gateway. The
NF (e.g., AMF in 5G) that terminates NAS messages and manages UE
registration may request AIC from the Agent Gateway on behalf of the
agent in the UE. The Agent Management Center is responsible for
agent authentication and authorization. The authentication and
authorization procedure for agents (Agents ↔ Agent Gateway ↔ Agent
Management Center) may reference the authentication and authorization
procedure for UEs (e.g., UEs <-> AMF <-> UDM <-> AUSF in 5G).
Agent-enabled NFs register with the Agent Gateway and discover each
other by querying the Agent Gateway. The registration and discovery
mechanism is similar to the functionality provided by the NRF in 5G
networks. However, standardization of agent capabilities is
essential for the accuracy and efficiency of agent discovery. The NF
(e.g., AMF in 5G) that terminates NAS messages and manages UE
registration may interact with the Agent Gateway on behalf of the
agent in the UE. However, the discovery of the agent on the UE takes
the UE connection state into account.
Service-based interfaces may be enhanced to support agent
communication, or agent-based interfaces may be introduced to support
AI traffic carrying Agent-to-Agent semantic data. The AI
capabilities supported by the mobile operator network may be exposed
as agent tools and invoked by third-party AI agents via the Agent
Gateway, which performs protocol conversion for different agent
communication protocols if necessary, while AI traffic transmitted
through the mobile operator network may be identified to guarantee
performance requirements.
The NF supporting session management (e.g., SMF in 5G) can be
enhanced, or a new NF may be introduced to support the management of
Agent-to-Agent semantic sessions between the agent residing in the UE
and the agent residing in the operator core network.
Li, et al. Expires 23 November 2026 [Page 12]
Internet-Draft DMSC Architecture May 2026
+-------+
| Uesr |
+-+-----+
| ^
| |
| |
+------+--+-------+ +----------------------------------------------------------------------+ +------------+
| | | | | Mobile Operator | | Third Party|
| v | | | Corenetwork | | |
| +------+----+ | Operator-defined| | | |
| | UE APP | | <-------------> | +--------+ +-----------+ +----------+ |<-------------> | +------+ |
| +--+--------+ | | | NF | | NF with | | Agent | | | | Agent| |
| | ^ | | | | | Agent | | Gateway | | | +------+ |
| v | | | +---+----+ +-----+-----+ +-----+----+ | | |
| +------+----+ | | | | | | | +------+ |
| | UE OS Layer | | | | | | | | Agent| |
| | Agent | | | | | | Service Based Interface| | +------+ |
| +--+--------+ | Intent Execution| | | | (Agent Enhancement) | | |
| | ^ | <-------------> |--------+----+----------+----+-----------+----+------------------ | <------------->| . |
| | | | Result | | | | | | . |
| | | | | | | | | | . |
| v | | | | | | | | . |
| +------+----+ | | +------+----+ +----+---+ +-------+-----+ | | . |
| | UE Modem | | | | NF with | | NF | | Agent | | | |
| | | | | | Agent | | | | Management | | | +------+ |
| +-----------+ | AI traffic | +-----------+ +--------+ | Center | | AI Traffic | | Agent| |
| | <-------------> | +-------------+ | <------------->| +------+ |
| | Transfer | | Transfer | |
| UE | | | | |
+-----------------+ +----------------------------------------------------------------------+ +------------+
Figure 3 Deployment Example: Mobile Operator Network
8. Security Considerations
This architecture introduces several security considerations,
including risks related to agent identity spoofing, capability
misrepresentation, semantic routing manipulation, cross-domain trust
inconsistencies, and information leakage through enhanced
observability. Detailed security mechanisms are outside the scope of
this document.
9. IANA Considerations
TBD
Li, et al. Expires 23 November 2026 [Page 13]
Internet-Draft DMSC Architecture May 2026
10. Acknowledgement
TBD
11. Normative References
[IoA] L, J., "Internet of Agents – Definition, Architecture and
Applications.
https://aip.openatom.tech/explore/journalism/
detail/501037383572131840", October 2025.
[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>.
[usecase] Y, M., "AI Agent Use Cases and Requirements in 6G Network.
draft-yu-ai-agent-use-cases-in-6g.
<https://datatracker.ietf.org/doc/html/draft-yu-dmsc-ai-
agent-use-cases-in-6g>", July 2025.
Authors' Addresses
Xueting Li
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: lixt2@foxmail.com
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: wangaj3@chinatelecom.cn
Bing Liu
Huawei Technologies
No. 156 Beiqing Road
Beijing
China
Email: leo.liubing@huawei.com
Li, et al. Expires 23 November 2026 [Page 14]
Internet-Draft DMSC Architecture May 2026
Changwang Lin
New H3C Technologies
8 Yongjia North Road
Beijing
Haidian District, 100094
China
Email: linchangwang.04414@h3c.com
Li, et al. Expires 23 November 2026 [Page 15]