# drafts

name: draft-zeng-mcp-network-mgmt
rev: 01
title: Model Context Protocol (MCP) Extensions for Network Equipment Management
time: 2025-10-16T09:54:14Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-19T09:54:14Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.096119+00:00
source: ietf
abstract:
  The Model Context Protocol (MCP) provides a JSON-RPC 2.0 framework
     for interaction between AI applications and external context sources.
     This document specifies minimal extensions that allow network
     equipment (routers, switches, etc.) to act as MCP servers while
     controllers act as MCP clients.  New capability tokens, tools,
     resources, prompts, and error codes are defined without breaking
     existing MCP implementations.

full_text:
  Network Working Group                                        Z. Guanming
  Internet-Draft                                         Huawei Technology
  Intended status: Standards Track                         16 October 2025
  Expires: 19 April 2026


  Model Context Protocol (MCP) Extensions for Network Equipment Management
                       draft-zeng-mcp-network-mgmt-01

  Abstract

     The Model Context Protocol (MCP) provides a JSON-RPC 2.0 framework
     for interaction between AI applications and external context sources.
     This document specifies minimal extensions that allow network
     equipment (routers, switches, etc.) to act as MCP servers while
     controllers act as MCP clients.  New capability tokens, tools,
     resources, prompts, and error codes are defined without breaking
     existing MCP implementations.

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

  Copyright Notice

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











  Guanming                  Expires 19 April 2026                 [Page 1]


  Internet-Draft                   MCP-NET                    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
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Capability Advertisement  . . . . . . . . . . . . . . . . . .   3
       3.1.  Rationale for Each Field  . . . . . . . . . . . . . . . .   3
     4.  Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.  Resources . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.  Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.  Error Codes . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
       9.1.  MCP Capability Tokens Registry  . . . . . . . . . . . . .   6
       9.2.  JSON-RPC Error Codes Registry . . . . . . . . . . . . . .   6
     10. Normative References  . . . . . . . . . . . . . . . . . . . .   6
     11. Informative References  . . . . . . . . . . . . . . . . . . .   6
     Appendix A.  Appendix A.  JSON Schema Examples  . . . . . . . . .   7
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     Network controllers today need to speak CLI, YANG/NETCONF, SNMP,
     gNMI, and vendor-private APIs.  Implementing a separate adapter for
     each protocol is expensive and error-prone.

     The Model Context Protocol (MCP) already defines a JSON-RPC 2.0 based
     framing, capability negotiation, and extensible tool/resource model.
     By adding a small set of network-specific capability flags and tool
     names, a device can expose its CLI, YANG datastores, and event
     streams through the same MCP channel that AI applications use for
     retrieving context.

     This document specifies those extensions.  All new elements live in
     their own capability namespace and can be ignored by generic MCP
     clients, preserving backward compatibility.







  Guanming                  Expires 19 April 2026                 [Page 2]


  Internet-Draft                   MCP-NET                    October 2025


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

     MCP Model Context Protocol

     Server MCP server running on the network device

     Client MCP client running on the controller

     Datastore Conventional YANG datastore (running, candidate,
     operational)

  3.  Capability Advertisement

     Servers that implement this specification MUST include the following
     object inside serverCapabilities in the initialize response:

     "network": {
       "yangModules": ["ietf-interfaces", "openconfig-interfaces"],
       "cliDialect": "cisco-iosxr",
       "configDatastore": ["running", "candidate", "operational"],
       "notificationStream": ["syslog", "netconf-stream", "snmp-trap"],
       "maxBulkEdit": 1000,
       "supportsRollback": true,
       "rollbackTimeout": 300
     }

                                    Figure 1

  3.1.  Rationale for Each Field

     yangModules: Lists YANG modules the server can serve.  Clients use
     this to decide whether to invoke network.yang.* tools or fall back to
     CLI.

     cliDialect: Identifies CLI syntax (cisco-iosxr, huawei-vrp, etc.).
     Controllers can adjust prompt regex and command sequences
     accordingly.

     configDatastore: Bit-mask hint—running = editable live config;
     candidate = two-phase commit; operational = read-only state DB.
     Avoids unnecessary NETCONF hello round-trips.




  Guanming                  Expires 19 April 2026                 [Page 3]


  Internet-Draft                   MCP-NET                    October 2025


     notificationStream: Tells the client which async event streams the
     server can translate into MCP notifications.  Client can subscribe
     only to available types.

     maxBulkEdit: Device-level limit to avoid oversized edit-config
     requests.  Controllers can chunk large changes.

     supportsRollback / rollbackTimeout: Boolean plus numeric seconds.
     Lets client know a confirmed-commit can be rolled back automatically
     if not confirmed within the window.

  4.  Tools

     Seven new tool names are defined.  All reuse the standard MCP tools/
     call request and MUST be listed by tools/list.

       +=======================+=======================================+
       | Name                  | Description                           |
       +=======================+=======================================+
       | network.cli.exec      | Execute operational CLI show commands |
       +-----------------------+---------------------------------------+
       | network.cli.configure | Enter config mode and send commands   |
       +-----------------------+---------------------------------------+
       | network.yang.get      | Retrieve YANG data node               |
       +-----------------------+---------------------------------------+
       | network.yang.edit     | Edit candidate datastore              |
       +-----------------------+---------------------------------------+
       | network.commit        | Commit candidate to running           |
       +-----------------------+---------------------------------------+
       | network.rollback      | Rollback to previous commit           |
       +-----------------------+---------------------------------------+
       | network.file.pull     | Backup config file                    |
       +-----------------------+---------------------------------------+
       | network.file.push     | Restore config file                   |
       +-----------------------+---------------------------------------+

                                    Table 1

     Arguments are described by JSON Schema inside tool metadata, so SDKs
     can auto-generate bindings.  If a device only supports CLI, it
     advertises network.yang.* tools with available=false; controllers
     automatically downgrade.

  5.  Resources

     Network state is exposed as read-only resources with URI scheme
     network:///.  Examples:




  Guanming                  Expires 19 April 2026                 [Page 4]


  Internet-Draft                   MCP-NET                    October 2025


     network:///interface/TenGigE0/0/0/0
     network:///routing/ipv4/route-table
     network:///file/startup-config

     MIME type MUST match the encoding (application/yang-data+json, text/
     plain, etc.).  Large data can be paginated using the native MCP
     resource/subscribe cursor mechanism.

  6.  Prompts

     Interactive assistants MAY expose prompt templates such as

     network.troubleshoot.ping-fail, network.config.add-vlan,
     network.security.audit.

     Arguments are implementation specific but SHOULD use the same JSON
     Schema style as tools for consistency.

  7.  Error Codes

     New JSON-RPC error codes (registered in IANA section):

                  +========+================================+
                  |   Code | Message                        |
                  +========+================================+
                  | -32081 | Network.Timeout                |
                  +--------+--------------------------------+
                  | -32082 | Network.Unreachable            |
                  +--------+--------------------------------+
                  | -32083 | Network.AccessDenied           |
                  +--------+--------------------------------+
                  | -32084 | Network.ConfigIncompatible     |
                  +--------+--------------------------------+
                  | -32085 | Network.RollbackFailed         |
                  +--------+--------------------------------+
                  | -32086 | Network.ConfirmedCommitTimeout |
                  +--------+--------------------------------+

                                    Table 2

     These codes allow controllers to distinguish transport failures from
     authorization or device-level errors without parsing free-text
     messages.








  Guanming                  Expires 19 April 2026                 [Page 5]


  Internet-Draft                   MCP-NET                    October 2025


  8.  Security Considerations

     All operations run with the privileges of the authenticated MCP
     session.  Servers MUST enforce role-based access control for
     configuration commands.  Commit confirmed SHOULD be used for
     potentially disruptive changes.  Transport security is provided by
     the underlying MCP transport (TLS for HTTP, SSH port-forward for
     stdio).  Sensitive data (passwords, SNMP communities) MUST be
     redacted in logs and MCP traces.

  9.  IANA Considerations

  9.1.  MCP Capability Tokens Registry

     IANA is requested to register the following value:

     *  Token: network

     *  Description: Network equipment extensions for MCP

     *  Reference: this document

  9.2.  JSON-RPC Error Codes Registry

     IANA is requested to register the error codes -32081 to -32086 in the
     "JSON-RPC Application-Specific Error Codes" registry, all pointing to
     this document.

  10.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, 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, May 2017,
                <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC7950]  Bjorklund, M., "The YANG 1.1 Data Modeling Language",
                RFC 7950, August 2016,
                <https://www.rfc-editor.org/rfc/rfc7950>.

     [RFC8259]  Bray, T., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259, December 2017,
                <https://www.rfc-editor.org/rfc/rfc8259>.

  11.  Informative References




  Guanming                  Expires 19 April 2026                 [Page 6]


  Internet-Draft                   MCP-NET                    October 2025


     [MCP]      Anthropic, "Model Context Protocol Specification
                2025-06-18", URL https://modelcontextprotocol.io/
                specification/2025-06-18/basic, 2025.

  Appendix A.  Appendix A.  JSON Schema Examples

     Example tool metadata snippet (pretty printed):

     {
       "name": "network.yang.get",
       "description": "Retrieve a YANG data node",
       "inputSchema": {
         "type": "object",
         "properties": {
           "path": { "type": "string" },
           "datastore": { "enum": ["running", "operational"] }
         },
         "required": ["path"]
       }
     }

  Author's Address

     Zeng Guanming
     Huawei Technology
     Email: zengguanming@huawei.com

























  Guanming                  Expires 19 April 2026                 [Page 7]


name: draft-zm-rtgwg-mcp-network-measurement
rev: 01
time: 2025-11-02T12:06:33Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T12:06:33Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.100874+00:00
source: ietf
title:
  MCP-based Network Measurement Framework: Using Model Context Protocol for Intelligent Network Measurement

abstract:
  This document proposes a framework for intelligent network
     measurement using the Model Context Protocol (MCP).  By treating
     network devices as MCP servers, and treating network controllers,
     management systems, or network devices with LLM capability as MCP
     clients, this framework enables natural language-driven, AI-assisted
     network measurement operations.  The framework leverages MCP's
     standardized communication protocol to provide real-time network
     performance monitoring, intelligent fault diagnosis, topology
     discovery, and automated measurement workflows.  This document
     describes the architecture, use cases, and security considerations
     for implementing MCP-based network measurement systems.

full_text:
  Network Working Group                                            G. Zeng
  Internet-Draft                                                    J. Mao
  Intended status: Informational                                    B. Liu
  Expires: 6 May 2026                                              N. Geng
                                                                  X. Shang
                                                                    Q. Gao
                                                                     Z. Li
                                                                    Huawei
                                                           2 November 2025


   MCP-based Network Measurement Framework: Using Model Context Protocol
                    for Intelligent Network Measurement
                 draft-zm-rtgwg-mcp-network-measurement-01

  Abstract

     This document proposes a framework for intelligent network
     measurement using the Model Context Protocol (MCP).  By treating
     network devices as MCP servers, and treating network controllers,
     management systems, or network devices with LLM capability as MCP
     clients, this framework enables natural language-driven, AI-assisted
     network measurement operations.  The framework leverages MCP's
     standardized communication protocol to provide real-time network
     performance monitoring, intelligent fault diagnosis, topology
     discovery, and automated measurement workflows.  This document
     describes the architecture, use cases, and security considerations
     for implementing MCP-based network measurement systems.

  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.






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


  Internet-Draft                 MCP NetMeas                 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  MCP-Based Network Measurement Architecture  . . . . . . . . .   3
       3.1.  Architectural Components  . . . . . . . . . . . . . . . .   3
       3.2.  Communication Flow  . . . . . . . . . . . . . . . . . . .   4
       3.3.  MCP Server Capabilities . . . . . . . . . . . . . . . . .   4
       3.4.  MCP Client Capabilities . . . . . . . . . . . . . . . . .   5
     4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Real-time Network Performance Monitoring  . . . . . . . .   5
       4.2.  Intelligent Fault Diagnosis . . . . . . . . . . . . . . .   5
       4.3.  Network Topology Discovery  . . . . . . . . . . . . . . .   6
       4.4.  Capacity Planning and Trend Analysis  . . . . . . . . . .   6
       4.5.  Security Incident Response Measurement  . . . . . . . . .   6
     5.  Protocol Operations . . . . . . . . . . . . . . . . . . . . .   6
       5.1.  Measurement Request Format  . . . . . . . . . . . . . . .   6
       5.2.  Measurement Response Format . . . . . . . . . . . . . . .   7
       5.3.  Error Handling  . . . . . . . . . . . . . . . . . . . . .   7
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
       6.1.  Authentication and Authorization  . . . . . . . . . . . .   8
       6.2.  Data Privacy and Confidentiality  . . . . . . . . . . . .   8
       6.3.  Measurement Tool Security . . . . . . . . . . . . . . . .   8
       6.4.  AI/LLM Security Considerations  . . . . . . . . . . . . .   9
       6.5.  Network Device Security . . . . . . . . . . . . . . . . .   9
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     8.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
     9.  Informative References  . . . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10








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


  Internet-Draft                 MCP NetMeas                 November 2025


  1.  Introduction

     Traditional network measurement approaches often require specialized
     tools, complex configurations, and expert knowledge.  As networks
     grow in complexity and scale, there is an increasing need for more
     intelligent and automated measurement solutions.  The Model Context
     Protocol (MCP) provides a standardized framework for enabling
     communication between AI systems and external data sources.

     This document proposes leveraging MCP to create an intelligent
     network measurement framework where:

     *  Network devices (routers, switches, firewalls) act as MCP servers

     *  Network controllers, management systems, or network devices with
        LLM capability act as MCP clients

     *  Natural language queries drive measurement operations

     *  AI systems assist in analysis and decision-making

     The key benefits of this approach include:

     *  *Natural Language Interface*: Network operators can perform
        measurements using natural language queries

     *  *AI-Assisted Analysis*: Intelligent analysis of measurement
        results and anomaly detection

     *  *Standardized Communication*: Uniform protocol across different
        vendor devices

     *  *Automated Workflows*: Reduced manual intervention in measurement
        processes

  2.  Terminology

     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.  MCP-Based Network Measurement Architecture

  3.1.  Architectural Components





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


  Internet-Draft                 MCP NetMeas                 November 2025


   +------------------+          MCP Protocol         +------------------+
   |  MCP Client      |<----------------------------->|                  |
   | (Controller, or  |   JSON-RPC 2.0 over           |  MCP Server      |
   | network devices  |   TCP/HTTP/WebSocket          |  (Network Device)|
   | with LLM)        |                               |                  |
   +------------------+                               +------------------+
           |                                                  |
           |                                                  |
           v                                                  v
   +------------------+                               +------------------+
   |                  |                               |                  |
   |  AI/LLM System   |                               |  Network         |
   |                  |                               |  Hardware        |
   +------------------+                               +------------------+

               Figure 1: MCP Network Measurement Architecture

  3.2.  Communication Flow

     The communication process involves five phases:

     *  *Discovery Phase*: MCP client discovers available MCP servers and
        their capabilities

     *  *Capability Negotiation*: Client and server negotiate supported
        measurement features

     *  *Measurement Execution*: Client requests measurements using
        natural language or structured queries

     *  *Data Collection*: Server provides measurement data through
        resources or tool execution

     *  *Analysis and Response*: Client processes results, potentially
        with AI assistance

  3.3.  MCP Server Capabilities

     MCP servers MUST expose:

     Measurement Resources:

     *  Interface statistics (bandwidth, utilization, errors)

     *  Routing information (tables, protocols, neighbors)

     *  Device performance metrics (CPU, memory)




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


  Internet-Draft                 MCP NetMeas                 November 2025


     *  Network topology data (LLDP/CDP information)

     Measurement Tools:

     *  Connectivity tests (ping, traceroute)

     *  Performance measurements (throughput, latency)

     *  Protocol-specific diagnostics

     *  Configuration validation tools

  3.4.  MCP Client Capabilities

     MCP clients MAY provide:

     *  *Sampling capabilities*: For complex measurement scenarios

     *  *Root context*: Measurement scope and boundaries

     *  *User interaction*: For measurement confirmation and authorization

  4.  Use Cases

  4.1.  Real-time Network Performance Monitoring

     *Scenario*: Network operator wants to check link utilization across
     core routers.

     *MCP Interaction*:

  Operator: "Show me the current utilization of all core router interfaces"
  MCP Client: Discovers core routers and requests interface statistics
  MCP Server: Provides Resources containing interface utilization data
  MCP Client: Aggregates and presents data with AI-generated insights

  4.2.  Intelligent Fault Diagnosis

     *Scenario*: Troubleshooting connectivity issues between two sites.

     *MCP Interaction*:

  Operator: "Diagnose connectivity issues between Site A and Site B"
  MCP Client: Identifies relevant devices and requests diagnostic tools
  MCP Server: Provides Tools: [traceroute, ping, show interfaces, show route]
  MCP Client: Executes diagnostic sequence and analyzes results





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


  Internet-Draft                 MCP NetMeas                 November 2025


  4.3.  Network Topology Discovery

     *Scenario*: Automated mapping of network topology.

     *MCP Interaction*:

  Operator: "Discover and map the current network topology"
  MCP Client: Requests topology information from seed devices
  MCP Server: Provides Resources: [neighbors table, interface status, VLAN info]
  MCP Client: Builds topology graph using AI-assisted correlation

  4.4.  Capacity Planning and Trend Analysis

     *Scenario*: Predict future capacity needs based on current usage
     patterns.

     *MCP Interaction*:

   Operator: "Analyze capacity trends for all WAN links"
   MCP Client: Collects historical utilization data
   MCP Server: Provides Resources: [historical statistics, error counters]
   MCP Client: AI analysis generates capacity planning recommendations

  4.5.  Security Incident Response Measurement

     *Scenario*: Measure and analyze potential security threats.

     *MCP Interaction*:

  Operator: "Investigate unusual traffic patterns on border routers"
  MCP Client: Requests security-related measurements
  MCP Server: Provides Tools: [ACL hit counts, flow analysis, threat detection]
  MCP Client: Correlates security events with network measurements

  5.  Protocol Operations

  5.1.  Measurement Request Format

     Measurement requests MUST follow MCP protocol specifications with the
     following structure:











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


  Internet-Draft                 MCP NetMeas                 November 2025


     {
       "jsonrpc": "2.0",
       "method": "tools/call",
       "params": {
         "name": "network_measurement_tool",
         "arguments": {
           "target": "device_or_interface",
           "measurement_type": "ping_throughput_latency",
           "parameters": {
             "count": 10,
             "interval": 1,
             "timeout": 5
           }
         }
       },
       "id": "measurement_request_001"
     }

  5.2.  Measurement Response Format

     Measurement responses MUST include:

     {
       "jsonrpc": "2.0",
       "result": {
         "measurement_id": "measurement_request_001",
         "timestamp": "2025-10-18T10:30:00Z",
         "device_id": "router_core_01",
         "results": {
           "avg_latency_ms": 25.3,
           "min_latency_ms": 24.1,
           "max_latency_ms": 28.7,
           "packet_loss_percent": 0.0,
           "throughput_mbps": 987.2
         },
         "metadata": {
           "measurement_duration": 15,
           "path_taken": ["router1", "router2", "router3"]
         }
       },
       "id": "measurement_request_001"
     }

  5.3.  Error Handling

     MCP servers MUST implement appropriate error handling for:

     *  Unsupported measurement types



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


  Internet-Draft                 MCP NetMeas                 November 2025


     *  Device capability limitations

     *  Resource exhaustion scenarios

     *  Security policy violations

     Error responses MUST follow JSON-RPC 2.0 error format with MCP-
     specific error codes.

  6.  Security Considerations

     The Model Context Protocol enables powerful capabilities through
     arbitrary data access and code execution paths.  With this power
     comes important security and trust considerations that all
     implementers must carefully address.

  6.1.  Authentication and Authorization

     MCP-based network measurement systems MUST implement:

     *  *Strong Authentication*: All MCP communications MUST be
        authenticated using industry-standard mechanisms (TLS mutual
        authentication, OAuth 2.0, etc.)

     *  *Role-Based Access Control*: Different measurement capabilities
        MUST be restricted based on user roles and privileges

     *  *Device Authorization*: Network devices MUST verify client
        authorization before exposing sensitive measurement data

  6.2.  Data Privacy and Confidentiality

     *  *Encryption in Transit*: All MCP communications MUST use TLS 1.3
        or higher

     *  *Data Minimization*: Only necessary measurement data SHOULD be
        exposed

     *  *Access Logging*: All measurement requests and responses MUST be
        logged for audit purposes

  6.3.  Measurement Tool Security

     *  *Tool Validation*: All measurement tools exposed by MCP servers
        MUST be validated for security vulnerabilities

     *  *Resource Limits*: Measurement tools MUST implement appropriate
        resource limits to prevent DoS attacks



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


  Internet-Draft                 MCP NetMeas                 November 2025


     *  *Input Sanitization*: All measurement parameters MUST be validated
        and sanitized

  6.4.  AI/LLM Security Considerations

     *  *Prompt Injection Protection*: Natural language interfaces MUST
        implement protection against malicious prompt injection

     *  *Result Sanitization*: Measurement results MUST be sanitized
        before AI processing

     *  *Model Security*: AI models used for analysis MUST be protected
        against adversarial inputs

  6.5.  Network Device Security

     *  *Least Privilege*: Network devices MUST expose only necessary
        measurement capabilities

     *  *Rate Limiting*: Measurement requests MUST be rate-limited to
        prevent abuse

     *  *Network Segmentation*: MCP traffic SHOULD be isolated in
        management networks

  7.  IANA Considerations

     This document has no IANA actions.

  8.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, 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, 2017,
                <https://www.rfc-editor.org/info/rfc8174>.

     [RFC8259]  Bray, T., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259, 2017,
                <https://www.rfc-editor.org/info/rfc8259>.

  9.  Informative References

     [MCP-SPEC] Anthropic, "Model Context Protocol Specification
                2025-06-18", URL https://modelcontextprotocol.io/
                specification/2025-06-18/basic, 2025.



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


  Internet-Draft                 MCP NetMeas                 November 2025


     [RFC1157]  Case, J., Fedor, M., Schoffstall, M., and J. Davin,
                "Simple Network Management Protocol (SNMP)", RFC 1157,
                1990, <https://www.rfc-editor.org/info/rfc1157>.

     [RFC3954]  Claise, B., "Cisco Systems NetFlow Services Export Version
                9", RFC 3954, 2004,
                <https://www.rfc-editor.org/info/rfc3954>.

  Authors' Addresses

     Guanming Zeng
     Huawei
     Email: zengguanming@huawei.com


     Jianwei Mao
     Huawei
     Email: maojianwei@huawei.com


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


     Nan Geng
     Huawei
     Email: gengnan@huawei.com


     Xiaotong Shang
     Huawei
     Email: shangxiaotong@huawei.com


     Qiangzhou Gao
     Huawei
     Email: gaoqiangzhou@huawei.com


     Zhenbin Li
     Huawei
     Email: robinli314@163.com








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


name: draft-zw-nmrg-mcp-network-mgmt
rev: 00
title: Model Context Protocol (MCP) Extensions for Network Equipment Management
time: 2025-10-20T13:07:08Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T13:07:08Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.104069+00:00
source: ietf
abstract:
  The Model Context Protocol (MCP) provides a JSON-RPC 2.0 framework
     for interaction between AI applications and external context sources.
     This document specifies minimal extensions that allow network
     equipment (routers, switches, etc.) to act as MCP servers while
     controllers act as MCP clients.  New capability tokens, tools,
     resources, prompts, and error codes are defined without breaking
     existing MCP implementations.

full_text:
  Network Working Group                                            G. Zeng
  Internet-Draft                                                     Q. Wu
  Intended status: Standards Track                                  Huawei
  Expires: 23 April 2026                                   20 October 2025


  Model Context Protocol (MCP) Extensions for Network Equipment Management
                     draft-zw-nmrg-mcp-network-mgmt-00

  Abstract

     The Model Context Protocol (MCP) provides a JSON-RPC 2.0 framework
     for interaction between AI applications and external context sources.
     This document specifies minimal extensions that allow network
     equipment (routers, switches, etc.) to act as MCP servers while
     controllers act as MCP clients.  New capability tokens, tools,
     resources, prompts, and error codes are defined without breaking
     existing MCP implementations.

  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.











  Zeng & Wu                 Expires 23 April 2026                 [Page 1]


  Internet-Draft                   MCP-NET                    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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Capability Advertisement  . . . . . . . . . . . . . . . . . .   3
       3.1.  Rationale for Each Field  . . . . . . . . . . . . . . . .   4
     4.  Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.  Resources . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       5.1.  Standard URI Templates and MIME Types . . . . . . . . . .   5
       5.2.  Subscription and Pagination . . . . . . . . . . . . . . .   7
       5.3.  Read-Write Resources (Optional) . . . . . . . . . . . . .   7
       5.4.  Per-Resource Metadata . . . . . . . . . . . . . . . . . .   8
     6.  Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       6.1.  Standard Prompt Templates . . . . . . . . . . . . . . . .   8
       6.2.  Example: Ping-Failure Diagnosis Flow  . . . . . . . . . .   9
       6.3.  Prompt Metadata and Completion  . . . . . . . . . . . . .   9
       6.4.  Streaming and Human-in-the-Loop . . . . . . . . . . . . .  10
     7.  Error Codes . . . . . . . . . . . . . . . . . . . . . . . . .  10
       7.1.  Error Code Table  . . . . . . . . . . . . . . . . . . . .  11
       7.2.  Example Error Response  . . . . . . . . . . . . . . . . .  12
       7.3.  IANA Registration . . . . . . . . . . . . . . . . . . . .  13
     8.  Complete Interaction Example (Controller → Router)  . . . . .  13
       8.1.  Transport and Initialize  . . . . . . . . . . . . . . . .  13
       8.2.  Read Resource (Interface Status)  . . . . . . . . . . . .  14
       8.3.  Prompt Diagnosis (Ping Failure) . . . . . . . . . . . . .  14
       8.4.  YANG Edit + Confirmed Commit  . . . . . . . . . . . . . .  15
       8.5.  Event Stream (Syslog) . . . . . . . . . . . . . . . . . .  16
       8.6.  Graceful Shutdown . . . . . . . . . . . . . . . . . . . .  16
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
       10.1.  MCP Capability Tokens Registry . . . . . . . . . . . . .  17
       10.2.  JSON-RPC Error Codes Registry  . . . . . . . . . . . . .  17
     11. Normative References  . . . . . . . . . . . . . . . . . . . .  17
     12. Informative References  . . . . . . . . . . . . . . . . . . .  17
     Appendix A.  JSON Schema Examples . . . . . . . . . . . . . . . .  17
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18






  Zeng & Wu                 Expires 23 April 2026                 [Page 2]


  Internet-Draft                   MCP-NET                    October 2025


  1.  Introduction

     Network controllers today need to speak CLI, YANG/NETCONF, SNMP,
     gNMI, and vendor-private APIs.  Implementing a separate adapter for
     each protocol is expensive and error-prone.

     The Model Context Protocol (MCP) already defines a JSON-RPC 2.0 based
     framing, capability negotiation, and extensible tool/resource model.
     By adding a small set of network-specific capability flags and tool
     names, a device can expose its CLI, YANG datastores, and event
     streams through the same MCP channel that AI applications use for
     retrieving context.

     This document specifies those extensions.  All new elements live in
     their own capability namespace and can be ignored by generic MCP
     clients, preserving backward compatibility.

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

     MCP Model Context Protocol

     Server MCP server running on the network device

     Client MCP client running on the controller

     Datastore Conventional YANG datastore (running, candidate,
     operational)

  3.  Capability Advertisement

     Servers that implement this specification MUST include the following
     object inside serverCapabilities in the initialize response:

     "network": {
       "yangModules": ["ietf-interfaces", "openconfig-interfaces"],
       "cliDialect": "huawei-vrp",
       "configDatastore": ["running", "candidate", "operational"],
       "notificationStream": ["syslog", "netconf-stream", "snmp-trap"],
       "maxBulkEdit": 1000,
       "supportsRollback": true,
       "rollbackTimeout": 300
     }



  Zeng & Wu                 Expires 23 April 2026                 [Page 3]


  Internet-Draft                   MCP-NET                    October 2025


                                    Figure 1

  3.1.  Rationale for Each Field

     yangModules: Lists YANG modules the server can serve.  Clients use
     this to decide whether to invoke network.yang.* tools or fall back to
     CLI.

     cliDialect: Identifies CLI syntax (cisco-iosxr, huawei-vrp, etc.).
     Controllers can adjust prompt regex and command sequences
     accordingly.

     configDatastore: Bit-mask hint—running = editable live config;
     candidate = two-phase commit; operational = read-only state DB.
     Avoids unnecessary NETCONF hello round-trips.

     notificationStream: Tells the client which async event streams the
     server can translate into MCP notifications.  Client can subscribe
     only to available types.

     maxBulkEdit: Device-level limit to avoid oversized edit-config
     requests.  Controllers can chunk large changes.

     supportsRollback / rollbackTimeout: Boolean plus numeric seconds.
     Lets client know a confirmed-commit can be rolled back automatically
     if not confirmed within the window.

  4.  Tools

     Seven new tool names are defined.  All reuse the standard MCP tools/
     call request and MUST be listed by tools/list.




















  Zeng & Wu                 Expires 23 April 2026                 [Page 4]


  Internet-Draft                   MCP-NET                    October 2025


       +=======================+=======================================+
       | Name                  | Description                           |
       +=======================+=======================================+
       | network.cli.exec      | Execute operational CLI show commands |
       +-----------------------+---------------------------------------+
       | network.cli.configure | Enter config mode and send commands   |
       +-----------------------+---------------------------------------+
       | network.yang.get      | Retrieve YANG data node               |
       +-----------------------+---------------------------------------+
       | network.yang.edit     | Edit candidate datastore              |
       +-----------------------+---------------------------------------+
       | network.commit        | Commit candidate to running           |
       +-----------------------+---------------------------------------+
       | network.rollback      | Rollback to previous commit           |
       +-----------------------+---------------------------------------+
       | network.file.pull     | Backup config file                    |
       +-----------------------+---------------------------------------+
       | network.file.push     | Restore config file                   |
       +-----------------------+---------------------------------------+

                                    Table 1

     Arguments are described by JSON Schema inside tool metadata, so SDKs
     can auto-generate bindings.  If a device only supports CLI, it
     advertises network.yang.* tools with available=false; controllers
     automatically downgrade.

  5.  Resources

     Network equipment exposes configuration, operational and file data as
     MCP resources under the URI scheme network:///.  All resources
     described below are read-only unless explicitly marked "read-write".

     Servers MUST support resources/read and SHOULD support resources/
     subscribe for streaming resources.  Large responses MAY be paginated
     using the standard MCP nextCursor mechanism.

  5.1.  Standard URI Templates and MIME Types

     +================================+============+======+==============+
     |URI Template                    |MIME Type   |Access|Description   |
     +================================+============+======+==============+
     |network:///interface/{name}     |application/|read- |Single        |
     |                                |yang-       |only  |interface     |
     |                                |data+json   |      |YANG node     |
     |                                |            |      |(OpenConfig   |
     |                                |            |      |or IETF)      |
     +--------------------------------+------------+------+--------------+



  Zeng & Wu                 Expires 23 April 2026                 [Page 5]


  Internet-Draft                   MCP-NET                    October 2025


     |network:///interfaces           |application/|read- |Full          |
     |                                |yang-       |only  |interface     |
     |                                |data+json   |      |list;         |
     |                                |            |      |supports      |
     |                                |            |      |cursor        |
     |                                |            |      |pagination    |
     +--------------------------------+------------+------+--------------+
     |network:///routing/ipv4/route-  |application/|read- |IPv4 RIB      |
     |table                           |yang-       |only  |(operational  |
     |                                |data+json   |      |datastore)    |
     +--------------------------------+------------+------+--------------+
     |network:///routing/ipv6/route-  |application/|read- |IPv6 RIB      |
     |table                           |yang-       |only  |(operational  |
     |                                |data+json   |      |datastore)    |
     +--------------------------------+------------+------+--------------+
     |network:///system/cpu-          |application/|read- |CPU           |
     |utilization                     |json        |only  |percentage;   |
     |                                |            |      |updated every |
     |                                |            |      |30 s          |
     +--------------------------------+------------+------+--------------+
     |network:///system/memory-summary|application/|read- |Memory usage  |
     |                                |json        |only  |summary       |
     +--------------------------------+------------+------+--------------+
     |network:///log/syslog/          |text/plain; |read- |Most recent   |
     |last{count}                     |charset=utf-|only  |syslog lines  |
     |                                |8           |      |(max 10000)   |
     +--------------------------------+------------+------+--------------+
     |network:///file/running-config  |text/plain  |read- |Running       |
     |                                |            |only  |configuration |
     |                                |            |      |text          |
     +--------------------------------+------------+------+--------------+
     |network:///file/startup-config  |text/plain  |read- |Startup       |
     |                                |            |only  |configuration |
     |                                |            |      |text          |
     +--------------------------------+------------+------+--------------+
     |network:///file/{slot}/crashinfo|application/|read- |Crash         |
     |                                |json        |only  |information   |
     |                                |            |      |file (JSON    |
     |                                |            |      |array)        |
     +--------------------------------+------------+------+--------------+

                                    Table 2









  Zeng & Wu                 Expires 23 April 2026                 [Page 6]


  Internet-Draft                   MCP-NET                    October 2025


  5.2.  Subscription and Pagination

     Resources that change over time (CPU, memory, syslog, interface
     counters) SHOULD implement resources/subscribe.  The server sends
     unsolicited resources/updated notifications when the underlying data
     changes.

     For large lists (e.g., full IPv4 RIB) the server MAY insert
     nextCursor in the response:

     {
       "jsonrpc": "2.0",
       "id": 4,
       "result": {
         "contents": [
           {
             "uri": "network:///routing/ipv4/route-table",
             "mimeType": "application/yang-data+json",
             "data": { "ietf-routing:routes": [ … 1000 items … ] }
           }
         ],
         "nextCursor": "eyJzb3J0LWtleSI6IjEwLjAuMC4xLzI0In0="
       }
     }

     The client continues with:

     {
       "jsonrpc": "2.0",
       "id": 5,
       "method": "resources/read",
       "params": {
         "uri": "network:///routing/ipv4/route-table",
         "cursor": "eyJzb3J0LWtleSI6IjEwLjAuMC4xLzI0In0="
       }
     }

     until nextCursor is absent.

  5.3.  Read-Write Resources (Optional)

     If the device supports whole-config replace, the following URIs MAY
     be advertised with readOnly: false:

     *  network:///file/candidate-config (text/plain)

     *  network:///file/startup-config (text/plain)




  Zeng & Wu                 Expires 23 April 2026                 [Page 7]


  Internet-Draft                   MCP-NET                    October 2025


     Writing is done via the standard MCP resources/write method; the
     server MUST validate syntax before committing to candidate/running.

  5.4.  Per-Resource Metadata

     Each resource descriptor MAY include a _meta object (MCP reserved) to
     carry unit, precision, or hardware-specific attributes, e.g.:

     "_meta": {
       "unit": "percent",
       "precision": 0.1,
       "hardware-slot": "1/0"
     }

  6.  Prompts

     Interactive assistants (e.g., CLI copilot, chat-bot) MAY expose
     prompt templates whose names start with network..  Templates are
     listed by prompts/list and executed via prompts/get; both reuse the
     standard MCP prompt meta-data and JSON Schema for arguments.

     Each entry below includes:

     *  template name (prompts/list)

     *  one-line description

     *  input JSON Schema

     *  expected tool calls / steps

     *  return MIME type (text/markdown by default)

  6.1.  Standard Prompt Templates

     +================================+=============+===================+
     | Template Name                  |Description  |Input Schema       |
     +================================+=============+===================+
     | network.troubleshoot.ping-fail |Step-by-step |{src: string, dst: |
     |                                |ping failure |string, vrf?:      |
     |                                |diagnosis    |string}            |
     +--------------------------------+-------------+-------------------+
     | network.config.add-vlan        |Interactive  |{vlan_id: uint16,  |
     |                                |VLAN creation|name: string,      |
     |                                |wizard       |ports?: string[]}  |
     +--------------------------------+-------------+-------------------+
     | network.security.audit         |Generate and |{profile:          |
     |                                |run security |"basic"|"detailed"}|



  Zeng & Wu                 Expires 23 April 2026                 [Page 8]


  Internet-Draft                   MCP-NET                    October 2025


     |                                |compliance   |                   |
     |                                |checks       |                   |
     +--------------------------------+-------------+-------------------+

                                   Table 3

  6.2.  Example: Ping-Failure Diagnosis Flow

     The client calls prompts/get:

     {
       "jsonrpc": "2.0",
       "id": 10,
       "method": "prompts/get",
       "params": {
         "name": "network.troubleshoot.ping-fail",
         "arguments": {
           "src": "192.168.1.1",
           "dst": "10.0.0.5",
           "vrf": "mgmt"
         }
       }
     }

     Server returns a markdown prompt that embeds tool calls:

     ## Ping failure diagnosis: 192.168.1.1 → 10.0.0.5 (VRF mgmt)

     1. Check local ARP entry:
        `network.cli.exec {"cmd": "show ip arp vrf mgmt 10.0.0.5"}`

     2. Verify outbound interface status:
        `network.yang.get {"path": "/openconfig-interfaces:interfaces/interface[name='Vlan100']", "datastore": "operational"}`

     3. Run extended ping:
        `network.cli.exec {"cmd": "ping vrf mgmt 10.0.0.5 source 192.168.1.1 repeat 5"}`

     ... (interactive steps continue) ...

     The client MAY stream the markdown to the user and **inline-execute**
     each tool call, then feed results back into the same prompt context
     (follow-up prompts/get with previousContextId) until the template
     outputs "Diagnosis complete".

  6.3.  Prompt Metadata and Completion

     Prompt descriptors returned by prompts/list MAY include:




  Zeng & Wu                 Expires 23 April 2026                 [Page 9]


  Internet-Draft                   MCP-NET                    October 2025


     {
       "name": "network.config.add-vlan",
       "description": "Interactive VLAN creation wizard",
       "arguments": [
         {
           "name": "vlan_id",
           "description": "IEEE 802.1Q VLAN ID",
           "type": "integer",
           "minimum": 1,
           "maximum": 4094
         },
         {
           "name": "name",
           "description": "VLAN name (no spaces)",
           "type": "string",
           "pattern": "^[A-Za-z0-9-_]+$"
         },
         {
           "name": "ports",
           "description": "List of interface names to add to VLAN",
           "type": "array",
           "items": { "type": "string" }
         }
       ],
       "required": ["vlan_id", "name"]
     }

     Controllers can therefore auto-generate UI forms or CLI wizards
     without hard-coding any vendor logic.

  6.4.  Streaming and Human-in-the-Loop

     Templates MAY set "stream": true in their meta-data.  In this mode
     the server returns a prompts/stream handle and pushes incremental
     markdown + tool calls, allowing step-by-step confirmation by the
     user.

     When the template issues a network.commit step it MUST include a
     confirmation prompt; the client SHALL wait for explicit user approval
     before invoking the commit tool.

  7.  Error Codes

     This document registers six new JSON-RPC application-specific error
     codes in the range -32081 to -32086.  Servers that implement optional
     features MAY return additional codes -32087 to -32090 defined below.
     All codes point to this document as reference.




  Zeng & Wu                 Expires 23 April 2026                [Page 10]


  Internet-Draft                   MCP-NET                    October 2025


  7.1.  Error Code Table

     +======+================================+===========+===============+
     |  Code| Message                        |Typical    | Recommended   |
     |      |                                |Scenario   | Recovery      |
     +======+================================+===========+===============+
     |-32081| Network.Timeout                |CLI or     | Retry with    |
     |      |                                |NETCONF    | shorter       |
     |      |                                |RPC        | command or    |
     |      |                                |exceeded   | increase      |
     |      |                                |device     | timeout       |
     |      |                                |timeout    |               |
     +------+--------------------------------+-----------+---------------+
     |-32082| Network.Unreachable            |Transport  | Check IP      |
     |      |                                |session    | reachability, |
     |      |                                |(SSH/TLS)  | credentials,  |
     |      |                                |down       | routing       |
     +------+--------------------------------+-----------+---------------+
     |-32083| Network.AccessDenied           |User role  | Escalate role |
     |      |                                |lacks      | or use lower- |
     |      |                                |permission | privilege     |
     |      |                                |for        | account       |
     |      |                                |command/   |               |
     |      |                                |path       |               |
     +------+--------------------------------+-----------+---------------+
     |-32084| Network.ConfigIncompatible     |Command/   | Fall back to  |
     |      |                                |YANG node  | alternate     |
     |      |                                |not        | model or CLI  |
     |      |                                |supported  | dialect       |
     |      |                                |on this    |               |
     |      |                                |platform   |               |
     +------+--------------------------------+-----------+---------------+
     |-32085| Network.RollbackFailed         |Confirmed- | Manual        |
     |      |                                |commit     | intervention  |
     |      |                                |rollback   | required;     |
     |      |                                |could not  | check logs    |
     |      |                                |be applied |               |
     +------+--------------------------------+-----------+---------------+
     |-32086| Network.ConfirmedCommitTimeout |Confirmed  | Re-apply      |
     |      |                                |commit     | change with   |
     |      |                                |window     | longer timer  |
     |      |                                |expired;   | or fix root   |
     |      |                                |config     | cause         |
     |      |                                |auto-      |               |
     |      |                                |rolled     |               |
     |      |                                |back       |               |
     +------+--------------------------------+-----------+---------------+
     |-32087| Network.RollbackNotSupported   |Device     | Skip rollback |



  Zeng & Wu                 Expires 23 April 2026                [Page 11]


  Internet-Draft                   MCP-NET                    October 2025


     |      |                                |does not   | step or use   |
     |      |                                |support    | file-based    |
     |      |                                |rollback   | restore       |
     |      |                                |operation  |               |
     +------+--------------------------------+-----------+---------------+
     |-32088| Network.YangSyntaxError        |YANG       | Fix offending |
     |      |                                |payload    | node and re-  |
     |      |                                |failed     | submit        |
     |      |                                |server-    |               |
     |      |                                |side       |               |
     |      |                                |validation |               |
     +------+--------------------------------+-----------+---------------+
     |-32089| Network.HardwareFailure        |Hardware   | Reduce scale  |
     |      |                                |resource   | or upgrade    |
     |      |                                |exhausted  | hardware      |
     |      |                                |(TCAM,     |               |
     |      |                                |memory)    |               |
     +------+--------------------------------+-----------+---------------+
     |-32090| Network.SnmpFailure            |SNMP SET   | Map error-    |
     |      |                                |returned   | status to     |
     |      |                                |error-     | text and      |
     |      |                                |status ≠   | retry with    |
     |      |                                |noError    | correct value |
     +------+--------------------------------+-----------+---------------+

                                    Table 4

  7.2.  Example Error Response

     A device that rejects a VLAN because the ID is out of range would
     return:

     {
       "jsonrpc": "2.0",
       "id": 12,
       "error": {
         "code": -32084,
         "message": "Network.ConfigIncompatible",
         "data": {
           "detail": "VLAN 4095 > maximum 4094",
           "path": "/openconfig-vlan:vlans/vlan/config/vlan-id",
           "retryPossible": false
         }
       }
     }






  Zeng & Wu                 Expires 23 April 2026                [Page 12]


  Internet-Draft                   MCP-NET                    October 2025


     The data object is optional but SHOULD contain detail (human-
     readable), path (affected YANG path), and retryPossible boolean to
     help controllers decide whether to retry automatically.

  7.3.  IANA Registration

     This document requests IANA to register the following error codes in
     the "JSON-RPC Application-Specific Error Codes" registry:

     *  -32081 to -32086 (mandatory set)

     *  -32087 to -32090 (optional set)

     All codes reference this document and are reserved for network
     equipment implementing MCP.

  8.  Complete Interaction Example (Controller → Router)

     This example walks through a full MCP session between a controller
     (client) and a router (server).  Transport is TLS-over-TCP; frames
     are sent as length-prefixed JSON-RPC 2.0 objects per MCP spec.

  8.1.  Transport and Initialize

     Controller opens TCP 443 and performs TLS handshake with ALPN
     protocol mcp.  Then sends:

     -> {"jsonrpc":"2.0","id":1,"method":"initialize","params":{
          "protocolVersion":"2025-06-18",
          "capabilities":{
            "prompts":{"listChanged":true},
            "resources":{"subscribe":true},
            "tools":{"listChanged":true}
          },
          "clientInfo":{"name":"ACME-NetCtrl","version":"4.7.0"}
        }}

     Router replies:













  Zeng & Wu                 Expires 23 April 2026                [Page 13]


  Internet-Draft                   MCP-NET                    October 2025


     <- {"jsonrpc":"2.0","id":1,"result":{
          "protocolVersion":"2025-06-18",
          "capabilities":{
            "prompts":{"listChanged":false},
            "resources":{"subscribe":true},
            "tools":{"listChanged":false},
            "network":{
              "yangModules":["ietf-interfaces","openconfig-interfaces"],
              "cliDialect":"huawei-vrp",
              "configDatastore":["running","candidate","operational"],
              "notificationStream":["syslog","netconf-stream"],
              "maxBulkEdit":1000,
              "supportsRollback":true,
              "rollbackTimeout":300
            }
          },
          "serverInfo":{"name":"IOS-XR-MCP","version":"7.5.3"}
        }}

  8.2.  Read Resource (Interface Status)

     Controller fetches operational data:

     -> {"jsonrpc":"2.0","id":2,"method":"resources/read","params":{
          "uri":"network:///interface/TenGigE0/0/0/0"}}
     <- {"jsonrpc":"2.0","id":2,"result":{
          "contents":[{
            "uri":"network:///interface/TenGigE0/0/0/0",
            "mimeType":"application/yang-data+json",
            "data":{
              "openconfig-interfaces:interface":{
                "name":"TenGigE0/0/0/0",
                "state":{"admin-status":"UP","oper-status":"DOWN"}
              }
            }
          }]
        }}

  8.3.  Prompt Diagnosis (Ping Failure)

     Controller invokes the standardized prompt:










  Zeng & Wu                 Expires 23 April 2026                [Page 14]


  Internet-Draft                   MCP-NET                    October 2025


     -> {"jsonrpc":"2.0","id":3,"method":"prompts/get","params":{
          "name":"network.troubleshoot.ping-fail",
          "arguments":{"src":"192.168.1.1","dst":"10.0.0.5","vrf":"mgmt"}}}
     <- {"jsonrpc":"2.0","id":3,"result":{
          "description":"Step-by-step ping failure diagnosis",
          "messages":[{
            "role":"assistant",
            "content":"## Ping failure: 192.168.1.1 → 10.0.0.5 (VRF mgmt)\n\n1. Check local ARP:\n   `network.cli.exec {\"cmd\":\"show ip arp vrf mgmt 10.0.0.5\"}`"
          }],
          "_meta":{"toolCalls":[{"tool":"network.cli.exec","arguments":{"cmd":"show ip arp vrf mgmt 10.0.0.5"}}]}
        }}

     Client executes the embedded tool and sends follow-up:

     -> {"jsonrpc":"2.0","id":4,"method":"tools/call","params":{
          "name":"network.cli.exec","arguments":{"cmd":"show ip arp vrf mgmt 10.0.0.5"}}}
     <- {"jsonrpc":"2.0","id":4,"result":{"stdout":"10.0.0.5  00:50:56:ab:cd:ef  Vlan100"}}

     Prompt continues until root cause is found and printed to user.

  8.4.  YANG Edit + Confirmed Commit

     Controller adds a loopback interface:

     -> {"jsonrpc":"2.0","id":5,"method":"tools/call","params":{
          "name":"network.yang.edit","arguments":{
            "target":"candidate",
            "edit":[{
              "path":"/openconfig-interfaces:interfaces/interface[name='Loopback100']",
              "value":{
                "config":{"name":"Loopback100","type":"iana-if-type:softwareLoopback"},
                "subinterfaces":{"subinterface":[{"index":0,"config":{"index":0,"ipv4":{"addresses":{"address":[{"ip":"100.100.100.100","config":{"ip":"100.100.100.100","prefix-length":32}}]}}}}]}
              }
            }]
          }
        }}
     <- {"jsonrpc":"2.0","id":5,"result":{"commit-id":"2025-10-19-03-27-00"}}

     Confirmed commit with 120 s rollback window:

     -> {"jsonrpc":"2.0","id":6,"method":"tools/call","params":{
          "name":"network.commit","arguments":{"confirmed":120}}}
     <- {"jsonrpc":"2.0","id":6,"result":{"status":"committed","rollbackTimeout":120}}

     Controller verifies connectivity; if OK it sends final confirm:






  Zeng & Wu                 Expires 23 April 2026                [Page 15]


  Internet-Draft                   MCP-NET                    October 2025


     -> {"jsonrpc":"2.0","id":7,"method":"tools/call","params":{
          "name":"network.commit","arguments":{"confirm":true}}}
     <- {"jsonrpc":"2.0","id":7,"result":{"status":"confirmed"}}

  8.5.  Event Stream (Syslog)

     Controller subscribes to syslog stream:

     -> {"jsonrpc":"2.0","id":8,"method":"resources/subscribe","params":{
          "uri":"network:///log/syslog/last200"}}
     <- {"jsonrpc":"2.0","id":8,"result":{"subscriptionId":"syslog-42"}}

     Server later pushes:

     <- {"jsonrpc":"2.0","method":"resources/updated","params":{
          "subscriptionId":"syslog-42",
          "uri":"network:///log/syslog/last200",
          "contents":[{
            "mimeType":"text/plain",
            "data":"Oct 19 03:29:01.123: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback100, changed state to up\n"
          }]
        }}

  8.6.  Graceful Shutdown

     Controller unsubscribes and closes the session:

     -> {"jsonrpc":"2.0","id":9,"method":"resources/unsubscribe","params":{
          "subscriptionId":"syslog-42"}}
     <- {"jsonrpc":"2.0","id":9,"result":{}}

     -> {"jsonrpc":"2.0","id":10,"method":"close"}
     <- {"jsonrpc":"2.0","id":10,"result":{}}

     TCP connection is closed by controller.

  9.  Security Considerations

     All operations run with the privileges of the authenticated MCP
     session.  Servers MUST enforce role-based access control for
     configuration commands.  Commit confirmed SHOULD be used for
     potentially disruptive changes.  Transport security is provided by
     the underlying MCP transport (TLS for HTTP, SSH port-forward for
     stdio).  Sensitive data (passwords, SNMP communities) MUST be
     redacted in logs and MCP traces.

  10.  IANA Considerations




  Zeng & Wu                 Expires 23 April 2026                [Page 16]


  Internet-Draft                   MCP-NET                    October 2025


  10.1.  MCP Capability Tokens Registry

     IANA is requested to register the following value:

     *  Token: network

     *  Description: Network equipment extensions for MCP

     *  Reference: this document

  10.2.  JSON-RPC Error Codes Registry

     IANA is requested to register the error codes -32081 to -32086 in the
     "JSON-RPC Application-Specific Error Codes" registry, all pointing to
     this document.

  11.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, 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, May 2017,
                <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC7950]  Bjorklund, M., "The YANG 1.1 Data Modeling Language",
                RFC 7950, August 2016,
                <https://www.rfc-editor.org/rfc/rfc7950>.

     [RFC8259]  Bray, T., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259, December 2017,
                <https://www.rfc-editor.org/rfc/rfc8259>.

  12.  Informative References

     [MCP]      Anthropic, "Model Context Protocol Specification
                2025-06-18", URL https://modelcontextprotocol.io/
                specification/2025-06-18/basic, 2025.

  Appendix A.  JSON Schema Examples

     Example tool metadata snippet (pretty printed):








  Zeng & Wu                 Expires 23 April 2026                [Page 17]


  Internet-Draft                   MCP-NET                    October 2025


     {
       "name": "network.yang.get",
       "description": "Retrieve a YANG data node",
       "inputSchema": {
         "type": "object",
         "properties": {
           "path": { "type": "string" },
           "datastore": { "enum": ["running", "operational"] }
         },
         "required": ["path"]
       }
     }

  Authors' Addresses

     Zeng Guanming
     Huawei
     Email: zengguanming@huawei.com


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




























  Zeng & Wu                 Expires 23 April 2026                [Page 18]


name: draft-mcp-over-moqt
rev: 00
title: Model Context Protocol over Media over QUIC Transport
time: 2025-10-20T19:50:28Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T19:50:28Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.107311+00:00
source: ietf
abstract:
  This document defines how to use Media over QUIC Transport (MOQT) as
     the underlying transport protocol for the Model Context Protocol
     (MCP).  MCP is a protocol that enables seamless integration between
     language model applications and external data sources and tools.
     MOQT provides efficient, low-latency, publish-subscribe media
     delivery over QUIC and WebTransport.  This specification describes
     the mapping of MCP messages onto MOQT objects and defines the
     procedures for establishing and maintaining MCP sessions over MOQT.

full_text:
  Model Context Protocol                                       C. Jennings
  Internet-Draft                                             Cisco Systems
  Intended status: Experimental                                   I. Swett
  Expires: 23 April 2026                                            Google
                                                              J. Rosenberg
                                                                     Five9
                                                             S. Nandakumar
                                                             Cisco Systems
                                                           20 October 2025


           Model Context Protocol over Media over QUIC Transport
                         draft-mcp-over-moqt-00

  Abstract

     This document defines how to use Media over QUIC Transport (MOQT) as
     the underlying transport protocol for the Model Context Protocol
     (MCP).  MCP is a protocol that enables seamless integration between
     language model applications and external data sources and tools.
     MOQT provides efficient, low-latency, publish-subscribe media
     delivery over QUIC and WebTransport.  This specification describes
     the mapping of MCP messages onto MOQT objects and defines the
     procedures for establishing and maintaining MCP sessions over MOQT.

  About This Document

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

     The latest revision of this draft can be found at
     https://example.org/mcp-moqt/.  Status information for this document
     may be found at https://datatracker.ietf.org/doc/draft-mcp-over-
     moqt/.

     Discussion of this document takes place on the Model Context Protocol
     Working Group mailing list (mailto:mcp@example.org), which is
     archived at https://example.org/mcp/.

     Source for this draft and an issue tracker can be found at
     https://github.com/example/mcp-moqt.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.






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


  Internet-Draft                MCP over MOQT                 October 2025


     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.

     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  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   4
         1.1.1.  Current Transport Challenges  . . . . . . . . . . . .   4
         1.1.2.  MCP over MOQT . . . . . . . . . . . . . . . . . . . .   5
         1.1.3.  Operational Advantages  . . . . . . . . . . . . . . .   5
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
       1.3.  Protocol Overview . . . . . . . . . . . . . . . . . . . .   6
         1.3.1.  MCP Lifecycle State Chart . . . . . . . . . . . . . .   7
         1.3.2.  System Components . . . . . . . . . . . . . . . . . .   8
     2.  MOQT Tracks for MCP . . . . . . . . . . . . . . . . . . . . .   9
       2.1.  Control Flow  . . . . . . . . . . . . . . . . . . . . . .   9
         2.1.1.  Client-to-Server Control Track  . . . . . . . . . . .   9
         2.1.2.  Server-to-Client Control Track  . . . . . . . . . . .   9
       2.2.  Track Types . . . . . . . . . . . . . . . . . . . . . . .  10
         2.2.1.  Control Tracks  . . . . . . . . . . . . . . . . . . .  10
         2.2.2.  Resource Tracks . . . . . . . . . . . . . . . . . . .  10
         2.2.3.  Tool Tracks . . . . . . . . . . . . . . . . . . . . .  11
         2.2.4.  Prompt Tracks . . . . . . . . . . . . . . . . . . . .  11
         2.2.5.  Notification Tracks . . . . . . . . . . . . . . . . .  12
         2.2.6.  Elicitation Tracks  . . . . . . . . . . . . . . . . .  13



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


  Internet-Draft                MCP over MOQT                 October 2025


         2.2.7.  Log Tracks  . . . . . . . . . . . . . . . . . . . . .  14
     3.  Protocol Operation  . . . . . . . . . . . . . . . . . . . . .  15
       3.1.  MOQT Session Establishment  . . . . . . . . . . . . . . .  15
       3.2.  Proposed Session ID Discovery . . . . . . . . . . . . . .  15
         3.2.1.  Well-Known Discovery Track  . . . . . . . . . . . . .  15
         3.2.2.  Discovery Flow  . . . . . . . . . . . . . . . . . . .  16
         3.2.3.  Discovery Request Format  . . . . . . . . . . . . . .  17
         3.2.4.  Discovery Response Format . . . . . . . . . . . . . .  19
         3.2.5.  Session Establishment Flow  . . . . . . . . . . . . .  22
       3.3.  Priority Management . . . . . . . . . . . . . . . . . . .  23
       3.4.  Error Handling  . . . . . . . . . . . . . . . . . . . . .  23
     4.  Relay Support . . . . . . . . . . . . . . . . . . . . . . . .  23
       4.1.  Subscription Aggregation  . . . . . . . . . . . . . . . .  23
         4.1.1.  Resource Subscription Aggregation . . . . . . . . . .  24
         4.1.2.  Tool Metadata Aggregation . . . . . . . . . . . . . .  24
       4.2.  Content Caching for MCP and AI Workflows  . . . . . . . .  24
         4.2.1.  Static Resources and Documentation  . . . . . . . . .  24
         4.2.2.  Tool Schema and Configuration Caching . . . . . . . .  25
         4.2.3.  Capability Information and Session Metadata . . . . .  25
         4.2.4.  Model Context and History Caching . . . . . . . . . .  25
       4.3.  Track Name Discovery and Dynamic Updates  . . . . . . . .  25
         4.3.1.  Discovery Track Implementation  . . . . . . . . . . .  26
         4.3.2.  Client Discovery via FETCH Operations . . . . . . . .  26
         4.3.3.  Asynchronous Updates via Subscriptions  . . . . . . .  27
     5.  Agent Skills and MCP Integration  . . . . . . . . . . . . . .  27
       5.1.  Skills Architecture Overview  . . . . . . . . . . . . . .  27
       5.2.  Skills Transport over MOQT  . . . . . . . . . . . . . . .  27
       5.3.  Skills Composition and Workflow Integration . . . . . . .  29
     6.  Shared Context Between One MCP Client and Multiple MCP
             Servers . . . . . . . . . . . . . . . . . . . . . . . . .  30
       6.1.  Context Sharing Architecture  . . . . . . . . . . . . . .  30
         6.1.1.  Session Isolation and Coordination  . . . . . . . . .  30
       6.2.  Context Synchronization Mechanisms  . . . . . . . . . . .  30
         6.2.1.  Resource Context Sharing  . . . . . . . . . . . . . .  30
         6.2.2.  Tool Execution Context  . . . . . . . . . . . . . . .  30
       6.3.  Context Synchronization Benefits  . . . . . . . . . . . .  30
         6.3.1.  Shared Subscription Management  . . . . . . . . . . .  31
         6.3.2.  Context Caching and Reuse . . . . . . . . . . . . . .  31
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  31
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  31
     9.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  31
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  31
       10.2.  Informative References . . . . . . . . . . . . . . . . .  32
     Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  32
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32





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


  Internet-Draft                MCP over MOQT                 October 2025


  1.  Introduction

     The Model Context Protocol (MCP) [MCP] is an open protocol that
     enables seamless integration between LLM applications and external
     data sources and tools.  MCP uses JSON-RPC 2.0 for message exchange
     and can operate over various transport protocols.

     Media over QUIC Transport (MOQT) [MOQT] is a protocol optimized for
     QUIC [QUIC] that provides efficient publish-subscribe media delivery
     with support for content distribution networks and low-latency
     requirements.

     This document outlines the use of MOQT as the transport layer for
     MCP, utilizing MOQT's object delivery and QUIC's multiplexed streams
     for low-latency communication.  Paired unidirectional tracks enable
     real-time interactions between language models and external systems.
     MOQT's object-based delivery allows efficient resource and tool
     sharing across clients without redundant transfers.  Relay networks
     support scalable content distribution, enabling global MCP deployment
     with optimized performance.  Native prioritization ensures critical
     operations like tool execution and user interactions receive
     sufficient bandwidth.  QUIC's connection migration and recovery
     provide reliable connectivity in mobile and unstable networks.

  1.1.  Motivation

     The Model Context Protocol (MCP) enables AI applications to integrate
     with external data sources and tools, but current transport
     mechanisms
     poses challenges that can hinder optimal performance and scalability.
     This specification addresses these challenges by leveraging Media
     over QUIC Transport (MOQT) as an alternate transport layer
     specifically optimized for MCP's operational requirements.

  1.1.1.  Current Transport Challenges

     WebSocket Transport lacks native prioritization mechanisms, causing
     critical control messages and urgent tool operations to compete
     equally with routine resource updates.  Head-of-line blocking occurs
     when large resource transfers delay time-sensitive operations, and
     the protocol provides no built-in caching or relay capabilities for
     scalable content distribution.

     HTTP Transport operates on a strict request-response model that
     conflicts with MCP's inherently event-driven architecture.  This
     mismatch forces artificial polling patterns for resource updates and
     prevents efficient server-initiated notifications.  While Server Side
     Streaming provides a mechanism for servers to send asynchronous



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


  Internet-Draft                MCP over MOQT                 October 2025


     events, it introduces significant challenges including connection
     complexity, limited browser support, proxy interference, and
     difficultly in handling bidirectional communication patterns
     essential for interactive MCP operations.  Additionally, HTTP/1.1's
     connection limitations and HTTP/2's stream dependencies create
     bottlenecks in high-throughput AI applications.

  1.1.2.  MCP over MOQT

     MOQT's publish-subscribe architecture provides an ideal foundation
     for MCP operations, where MCP servers naturally function as
     publishers of resources, tools, and capabilities, while clients
     subscribe to relevant content streams.  This alignment enables
     several key architectural benefits:

     *Semantic Mapping*: MCP's resource-centric model maps directly to
     MOQT's track-based content organization.  Each resource, tool, or
     capability becomes a dedicated track with independent lifecycle
     management, version control, and access policies.

     *Event-Driven Communication*: MOQT's native support for asynchronous
     object delivery matches MCP's notification-based architecture,
     eliminating the artificial request-response constraints imposed by
     HTTP transport.

     *Priority-Aware Delivery*: MOQT's built-in prioritization system
     enables sophisticated quality-of-service policies, ensuring that
     critical MCP operations like tool execution and user interactions
     receive appropriate bandwidth allocation and reduced latency.

  1.1.3.  Operational Advantages

     The combination of MCP and MOQT can offer operational improvements
     along the following dimensions:

     Low Latency Operations: MOQT's object-based delivery model eliminates
     traditional HTTP request-response overhead, enabling direct message
     passing with minimal protocol overhead.  Tool execution requests are
     sent as prioritized FETCH operations while control messages receive
     the highest priority (1-2), ensuring responsive interaction even
     under high system load.

     Bandwidth Efficiency: MOQT relays provide sophisticated caching
     mechanisms and subscription aggregations, that deduplicate frequently
     accessed resources across multiple clients.  Large documentation
     sets, configuration files, and static assets are cached at relay
     points, dramatically reducing origin server load while enabling
     selective updates through version-aware object delivery.



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


  Internet-Draft                MCP over MOQT                 October 2025


     Multiplexing and Concurrency: QUIC's multiplexing capabilities
     prevent head-of-line blocking between different MCP operations,
     allowing hundreds of concurrent tool executions, resource
     subscriptions, and notification streams to operate independently
     without mutual interference.

     Network Resilience and Mobility: QUIC's connection migration and
     0-RTT reconnection capabilities maintain session continuity across
     network changes, a critical requirement for mobile AI applications
     and long-running workflows that may experience network interruptions.

     Edge-Optimized Content Distribution: The relay infrastructure
     supports geographically distributed caching and intelligent content
     placement, enabling global MCP deployments with optimized performance
     characteristics tailored to regional access patterns and data
     locality requirements.

  1.2.  Terminology

     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.

     This document uses terminology from [MCP] and [MOQT].

  1.3.  Protocol Overview

     MCP uses MOQT to map its abstractions to MOQT's transport mechanisms.
     MCP messages, encoded as JSON-RPC 2.0, are embedded in MOQT payloads,
     ensuring compatibility with MCP formats and efficient transport over
     QUIC streams.

     MCP sessions use MOQT sessions for communication, starting with a
     handshake to negotiate capabilities.  This phase ensures clients and
     servers agree on features, resource types, and parameters.

     MCP Resources are server-controlled data sources exposed to clients
     for read access.  In MOQT, each resource is published over
     *resources* track.  Content is delivered via MOQT objects, supporting
     various data types like files, API responses, database results, and
     version control history.  Streaming enables efficient handling of
     large resources, while automatic updates use new objects with updated
     sequence numbers for incremental changes.  This supports advanced
     caching and efficient client synchronization.





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


  Internet-Draft                MCP over MOQT                 October 2025


     Tools enable servers to execute client-requested operations.  MOQT
     maps tools to dedicated *tools* tracks and uses FETCH for request-
     response patterns.  Supported operations include API calls, file
     tasks, computations, and service integrations.  Progress tracking
     uses notifications for real-time updates.  FETCH ensures robust
     execution with prioritization, multiplexing, error handling, and
     timeout management.

     Notifications about resource changes and events are published in
     specialized tracks, allowing clients to subscribe without affecting
     other channels.  User input is managed through interactive control
     tracks for consent and data collection.

  1.3.1.  MCP Lifecycle State Chart

                         ┌─────────────┐
                         │ DISCONNECTED│
                         └──────┬──────┘
                                │ QUIC Connect
                                ▼
                         ┌─────────────┐
                         │ TRANSPORT   │
                         │ CONNECTED   │
                         └──────┬──────┘
                                │ MOQT Setup
                                ▼
                         ┌─────────────┐
                         │ MOQT        │
                         │ ESTABLISHED │
                         └──────┬──────┘
                                │ Track Subscribe
                                ▼
                         ┌─────────────┐
                         │ TRACKS      │
                         │ SUBSCRIBED  │
                         └──────┬──────┘
                                │ MCP Initialize
                                ▼
                         ┌─────────────┐
                         │ MCP         │
                         │ INITIALIZING│
                         └──────┬──────┘
                                │ Capabilities Exchange
                                ▼
                         ┌─────────────┐
                         │ CAPABILITIES│
                         │ NEGOTIATED  │
                         └──────┬──────┘



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


  Internet-Draft                MCP over MOQT                 October 2025


                                │ Discovery Complete
                                ▼
                         ┌─────────────┐
             ┌──────────▶│ MCP ACTIVE  │◀──────────┐
             │           │             │           │
             │           └─────┬───┬───┘           │
             │                 │   │               │
             │ Tool Result     │   │ Notification  │ Resource Update
             │                 │   │               │
             ▼                 │   ▼               │
      ┌─────────────┐          │ ┌─────────────┐   │
      │ TOOL        │          │ │ ELICITATION │   │
      │ EXECUTING   │──────────┘ │ PENDING     │   │
      └─────────────┘            └─────────────┘   │
             │                         │           │
             └─────────────────────────┼───────────┘
                                       │
                                       ▼
                                ┌─────────────┐
                                │ SESSION     │
                                │ TERMINATING │
                                └──────┬──────┘
                                       │ Cleanup
                                       ▼
                                ┌─────────────┐
                                │ DISCONNECTED│
                                └─────────────┘

  1.3.2.  System Components

     Below figure shows system components proposed in this specification.

     ┌─────────────────┐    MOQT Session    ┌─────────────────┐
     │   MCP Client    │<==================>│   MCP Server    │
     │                 │                    │                 │
     │ ┌─────────────┐ │                    │ ┌─────────────┐ │
     │ │MCP Transport│ │                    │ │MCP Transport│ │
     │ │   Adapter   │ │                    │ │   Adapter   │ │
     │ └─────────────┘ │                    │ └─────────────┘ │
     │ ┌─────────────┐ │                    │ ┌─────────────┐ │
     │ │    MOQT     │ │                    │ │    MOQT     │ │
     │ │  Endpoint   │ │                    │ │  Endpoint   │ │
     │ └─────────────┘ │                    │ └─────────────┘ │
     └─────────────────┘                    └─────────────────┘

     The MCP client-host-server architecture maps to MOQT as follows:





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


  Internet-Draft                MCP over MOQT                 October 2025


     *  *MCP Host*: Acts as MOQT client, managing multiple server
        connections

     *  *MCP Client*: Implemented as MCP transport adapter within the host

     *  *MCP Server*: Acts as MOQT publisher, exposing resources, tools,
        and prompts

  2.  MOQT Tracks for MCP

  2.1.  Control Flow

     The control flow establishes the fundamental communication channels
     for MCP session management and coordination.  This specifcation
     prposes 2 unidirectional tracks for direction for performing session
     establishment, capability negotiation, and various control operations
     using the MOQT's publish-subscribe semantics.

  2.1.1.  Client-to-Server Control Track

     *  *Publisher*: MCP Client

     *  *Subscribers*: MCP Server, optional monitoring relays

     *  *Content*:

        -  MCP initialize requests

        -  Ping messages (client-initiated)

        -  Capability negotiation requests

        -  Session teardown requests

        -  Tool cancellation requests

  2.1.2.  Server-to-Client Control Track

     *  *Publisher*: MCP Server

     *  *Subscribers*: MCP Client, optional monitoring relays

     *  *Content*:

        -  MCP initialize responses

        -  Pong messages (server responses)




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


  Internet-Draft                MCP over MOQT                 October 2025


        -  Capability negotiation responses

        -  Session teardown confirmations

        -  Server-initiated status updates

  2.2.  Track Types

     The various sub-sections provides information on track naming design
     defined by this specification to map to MCP operations.

  2.2.1.  Control Tracks

     Control tracks map MCP session management and coordination messages
     including initialization, ping/pong heartbeats, and capability
     negotiation and 2 unidirectional tracks for server and client to
     carryout message exchanges.

     Track namespace:

     (mcp, <session-id>, control)

     Track name (Client-to-Server):

     (client-to-server)

     Track name (Server-to-Client):

     (server-to-client)

     Groups and objects are mapped as follows:

     Each MCP control message is encoded as a single MOQT object within a
     group.  Group IDs are assigned sequentially starting from 0,
     incrementing for each new control message.  Object IDs within each
     group are always 0 since each control message maps to exactly one
     object.  Objects contain JSON-encoded MCP control messages as defined
     in the MCP specification.

  2.2.2.  Resource Tracks

     Resource tracks map MCP resources, delivering server-published
     content and metadata that serve as the main data sources exposed by
     MCP servers to clients.

     Track namespace:

     (mcp, <session-id>, resources)



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


  Internet-Draft                MCP over MOQT                 October 2025


     Track name:

     (<resource-uri>)

     Groups and objects are mapped as follows:

     Each resource version is assigned a unique group ID, starting from 0
     and incrementing with each resource update.  Within each group,
     objects represent chunks or segments of the resource content.  Object
     IDs start at 0 and increment sequentially for each chunk.  Objects
     contain the actual resource data encoded according to the resource's
     declared content type (binary data, JSON, text, etc.).

  2.2.3.  Tool Tracks

     Tool tracks map MCP tool execution, facilitating tool invocation
     requests, responses, and progress updates using MOQT's FETCH
     operations.

     Track namespace:

     (mcp, <session-id&>, tools)

     Track name:

     (<tool-name>)

     Groups and objects are mapped as follows:

     Each tool invocation creates a new group with a unique group ID
     assigned by the requesting client.  Within each group, object ID 0
     contains the tool request (JSON-encoded MCP tool call), subsequent
     object IDs contain tool responses and progress updates.  Objects are
     JSON-encoded according to the MCP tool execution protocol.

  2.2.4.  Prompt Tracks

     Prompt tracks map MCP prompts, distributing pre-defined templates and
     instructions that standardize common operations across the MCP
     ecosystem.

     Track namespace:

     (mcp, <session-id>, prompts)

     Track name:

     (<prompt-name>)



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


  Internet-Draft                MCP over MOQT                 October 2025


     Groups and objects are mapped as follows:

     Each prompt version is assigned a unique group ID starting from 0,
     incrementing with each prompt update.  Within each group, object ID 0
     contains the prompt template and metadata.  Objects contain JSON-
     encoded prompt definitions including template text, parameter
     schemas, and versioning information.

  2.2.5.  Notification Tracks

     Notification tracks map MCP notifications, providing asynchronous
     event delivery for server-sent notifications, progress updates, and
     system events.

     Track namespace:

     (mcp, <session-id>, notifications)

     Track name:

     (<category>)

     The category parameter classifies notification types to enable
     efficient subscription management and routing.  Common category
     values include:

     *  progress - Tool execution progress updates and status reports

     *  resources - Resource change notifications (listChanged, updated)

     *  prompts - Prompt template updates and availability changes

     *  system - Server status updates, connection events, error
        conditions

     *  elicitation - User input request notifications and responses

     *  tools - Tool availability changes and capability updates

     Custom categories may be defined for application-specific
     notification types following the pattern <domain>/<type> (e.g., ai/
     model_updated, workspace/file_changed).

     Groups and objects are mapped as follows:







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


  Internet-Draft                MCP over MOQT                 October 2025


     Each notification event creates a new group with group IDs assigned
     sequentially starting from 0.  Within each group, object ID 0
     contains the notification payload.  Objects contain JSON-encoded
     notification messages as defined in the MCP specification, including
     event type, timestamp, and payload data.

  2.2.6.  Elicitation Tracks

     Elicitation tracks map MCP user input collection, handling
     interactive flows for gathering user consent and data through pairs
     of unidirectional tracks.  The elicitation flow uses a unidirectional
     track pair to collect user input efficiently while preserving
     privacy.  Each request creates isolated track pairs, allowing
     concurrent operations.  Servers request user consent and input, while
     clients retain control to reject or modify requests.

     Track namespace:

     (mcp, <session-id>, elicitation, <request-id>)

     Track name (Server-to-Client):

     (<server-to-client>)

     Track name (Client-to-Server):

     (<client-to-server>)

     The Server-to-Client elicitation track is published by the MCP Server
     and subscribed to by the MCP Client, carrying:

     *  Elicitation request initiation

     *  Input schema definitions

     *  Validation error messages

     *  Request timeout notifications

     *  Request cancellation notices

     The Client-to-Server elicitation track is published by the MCP Client
     and subscribed to by the MCP Server, carrying:

     *  User consent responses

     *  Input data submissions




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


  Internet-Draft                MCP over MOQT                 October 2025


     *  Request rejection notifications

     *  Request cancellation confirmations

     Groups and objects are mapped as follows:

     Each elicitation exchange creates new groups with group IDs starting
     from 0 and incrementing for each message in the exchange.  Within
     each group, object ID 0 contains the elicitation message (request,
     response, or status update).  Objects contain JSON-encoded
     elicitation messages including input schemas, validation
     requirements, and user responses.

  2.2.7.  Log Tracks

     Log tracks map MCP logging information, providing debugging and
     monitoring capabilities by carrying diagnostic information for system
     troubleshooting and performance optimization.

     Track namespace:

     (mcp, <session-id>, logs)

     Track name:

     (<category>)

     The category parameter organizes log entries by severity level and
     source component to enable selective monitoring and efficient log
     processing.  Standard category values include:

     *  error - Error conditions, exceptions, and critical failures

     *  warn - Warning messages and non-critical issues requiring
        attention

     *  info - General informational messages about system operations

     *  debug - Detailed debugging information for troubleshooting

     *  trace - Fine-grained execution tracing for performance analysis

     *  audit - Security and compliance audit trails

     *  metrics - Performance metrics and system statistics






  Jennings, et al.          Expires 23 April 2026                [Page 14]


  Internet-Draft                MCP over MOQT                 October 2025


     Component-specific categories may be defined using the pattern
     <level>/<component> (e.g., error/transport, debug/tools, info/
     resources) to provide granular filtering capabilities.

     Groups and objects are mapped as follows:

     Each log entry creates a new group with group IDs assigned
     sequentially starting from 0, ordered by log timestamp.  Within each
     group, object ID 0 contains the log entry.  Objects contain JSON-
     encoded log messages including severity level, timestamp, source
     component, and message content.

  3.  Protocol Operation

  3.1.  MOQT Session Establishment

     The session establishment process begins with establishing the
     underlying MOQT session, which can be either a direct QUIC connection
     or a WebTransport [WebTransport] session depending on the deployment
     environment.  QUIC connections provide optimal performance for
     server-to- server communication, while WebTransport enables browser-
     based clients to participate in MCP sessions.

     The MOQT handshake phase involves the exchange of CLIENT_SETUP (0x20)
     and SERVER_SETUP (0x21) messages that negotiate protocol versions,
     supported features, and operational parameters.

  3.2.  Proposed Session ID Discovery

     MCP sessions require unique identifiers to organize track namespaces
     and enable proper message routing.  This section defines a well-known
     track approach for session discovery that allows clients to
     dynamically discover available MCP services and obtain session
     identifiers through standardized FETCH operations.

  3.2.1.  Well-Known Discovery Track

     The discovery mechanism uses a well-known track namespace and name
     that all MCP servers must support.  This track serves as the entry
     point for clients to discover available MCP sessions and obtain the
     necessary session identifiers for subsequent operations.

     Track Namespace: mcp/discovery
     Track Name: sessions







  Jennings, et al.          Expires 23 April 2026                [Page 15]


  Internet-Draft                MCP over MOQT                 October 2025


     Clients initiate discovery by sending a FETCH request to this well-
     known track, providing a client-side nonce or identifier as a
     parameter.  The server responds with a JSON-encoded MOQT object
     containing server details, a newly minted session identifier, and
     information about available tracks on that server.

  3.2.2.  Discovery Flow

     The session discovery process follows this sequence:

  3.2.2.1.  Standard Discovery Flow

         Client                         Server
            │                             │
            │ FETCH mcp/discovery/sessions│
            │ (with client nonce)         │
            │────────────────────────────▶│
            │                             │
            │                             │ Generate session ID
            │                             │ Prepare track catalog
            │                             │
            │     FETCH_OK                │
            │◀────────────────────────────│
            │                             │
            │ Data stream: FETCH_HEADER   │
            │ + Object with session       │
            │ details                     │
            │◀────────────────────────────│
            │                             │
            │ Subscribe to control tracks │
            │────────────────────────────▶│
            │                             │
            │ MCP Initialize              │
            │────────────────────────────▶│
            │                             │
            │ Initialize Response         │
            │◀────────────────────────────│
            │                             │
            │ Begin MCP operations        │
            │────────────────────────────▶│

  3.2.2.2.  Optimized Discovery Flow (RTT Reduction)









  Jennings, et al.          Expires 23 April 2026                [Page 16]


  Internet-Draft                MCP over MOQT                 October 2025


         Client                         Server
            │                             │
            │ FETCH mcp/discovery/sessions│
            │ (with nonce + MCP init)     │
            │────────────────────────────▶│
            │                             │
            │                             │ Generate session ID
            │                             │ Process MCP initialize
            │                             │ Prepare track catalog
            │                             │
            │     FETCH_OK                │
            │◀────────────────────────────│
            │                             │
            │ Data stream: FETCH_HEADER   │
            │ + Object with session       │
            │ details + MCP init response │
            │◀────────────────────────────│
            │                             │
            │ Subscribe to control tracks │
            │────────────────────────────▶│
            │                             │
            │ Begin MCP operations        │
            │ (initialization complete)   │
            │────────────────────────────▶│

  3.2.3.  Discovery Request Format

     Clients send FETCH requests to the well-known discovery track with a
     client-generated nonce or identifier in the payload:






















  Jennings, et al.          Expires 23 April 2026                [Page 17]


  Internet-Draft                MCP over MOQT                 October 2025


     FETCH {
       Type (i) = 0x16,
       Length (16),
       Request ID (i) = 1,
       Subscriber Priority (8) = 30,
       Group Order (8) = 0,
       Fetch Type (i) = 0x1,  // Standalone
       Track Namespace (tuple) = (... "mcp", "discovery"),
       Track Name Length (i) = 8,
       Track Name = "sessions",
       Start Location = {Group: 0, Object: 0},
       End Location = {Group: 0, Object: 1},
       Number of Parameters (i) = 1,
       Parameters = {
         "mcp_payload": {
           "jsonrpc": "2.0",
           "id": 1,
           "method": "discovery/request_session",
           "params": {
             "client_nonce": "client-nonce-abc123",
             "client_info": {
               "name": "ExampleClient",
               "version": "1.0.0"
             },
             "requested_capabilities": ["resources", "tools", "prompts"]
           }
         }
       }
     }

  3.2.3.1.  RTT Optimization with Combined Initialize

     To reduce round-trip time, clients MAY include their MCP initialize
     request within the discovery FETCH payload.  This allows the server
     to perform both session discovery and MCP initialization in a single
     exchange:















  Jennings, et al.          Expires 23 April 2026                [Page 18]


  Internet-Draft                MCP over MOQT                 October 2025


     FETCH {
       Type (i) = 0x16,
       Length (16),
       Request ID (i) = 1,
       Subscriber Priority (8) = 30,
       Group Order (8) = 0,
       Fetch Type (i) = 0x1,  // Standalone
       Track Namespace (tuple) = ("mcp", "discovery"),
       Track Name Length (i) = 8,
       Track Name = "sessions",
       Start Location = {Group: 0, Object: 0},
       End Location = {Group: 0, Object: 1},
       Number of Parameters (i) = 1,
       Parameters = {
         "mcp_payload": {
           "jsonrpc": "2.0",
           "id": 1,
           "method": "discovery/request_session_with_init",
           "params": {
             "client_nonce": "client-nonce-abc123",
             "client_info": {
               "name": "ExampleClient",
               "version": "1.0.0"
             },
             "requested_capabilities": ["resources", "tools", "prompts"],
             "mcp_initialize": {
               "protocolVersion": "2025-06-18",
               "capabilities": {
                 "resources": { "subscribe": true },
                 "tools": { "progress": true },
                 "prompts": {},
                 "elicitation": {}
               },
               "clientInfo": {
                 "name": "ExampleClient",
                 "version": "1.0.0"
               }
             }
           }
         }
       }
     }

  3.2.4.  Discovery Response Format

     The server responds with a JSON-encoded MOQT object containing the
     newly minted session ID and available track information:




  Jennings, et al.          Expires 23 April 2026                [Page 19]


  Internet-Draft                MCP over MOQT                 October 2025


     {
       "jsonrpc": "2.0",
       "id": 1,
       "result": {
         "session_id": "session-uuid-456",
         "server_info": {
           "name": "ExampleServer",
           "version": "2.0.0",
           "protocol_version": "2025-06-18"
         },
         "available_tracks": {
           "control": {
             "client_to_server":
                "mcp/session-uuid-456/control/client-to-server",
             "server_to_client":
                "mcp/session-uuid-456/control/server-to-client"
           },
           "resources": [
             {
               "name": "documentation",
               "track": "mcp/session-uuid-456/resources/documentation",
               "content_type": "text/markdown",
               "description": "API documentation and guides"
             }
           ],
           "tools": [
             {
               "name": "file_operations",
               "track": "mcp/session-uuid-456/tools/file_operations",
               "description": "File system operations"
             }
           ],
           "prompts": [
             {
               "name": "code_review",
               "track": "mcp/session-uuid-456/prompts/code_review",
               "description": "Code review prompt templates"
             }
           ]
         },
         "session_expires": "2025-06-18T12:00:00Z"
       }
     }








  Jennings, et al.          Expires 23 April 2026                [Page 20]


  Internet-Draft                MCP over MOQT                 October 2025


  3.2.4.1.  Combined Discovery and Initialize Response

     When the client uses the RTT optimization by including MCP initialize
     in the discovery request, the server responds with both session
     discovery and MCP initialization results:

     {
       "jsonrpc": "2.0",
       "id": 1,
       "result": {
         "session_id": "session-uuid-456",
         "server_info": {
           "name": "ExampleServer",
           "version": "2.0.0",
           "protocol_version": "2025-06-18"
         },
         "available_tracks": {
           "control": {
             "client_to_server":
                "mcp/session-uuid-456/control/client-to-server",
             "server_to_client":
                "mcp/session-uuid-456/control/server-to-client"
           },
           "resources": [
             {
               "name": "documentation",
               "track": "mcp/session-uuid-456/resources/documentation",
               "content_type": "text/markdown",
               "description": "API documentation and guides"
             }
           ],
           "tools": [
             {
               "name": "file_operations",
               "track": "mcp/session-uuid-456/tools/file_operations",
               "description": "File system operations"
             }
           ],
           "prompts": [
             {
               "name": "code_review",
               "track": "mcp/session-uuid-456/prompts/code_review",
               "description": "Code review prompt templates"
             }
           ]
         },
         "session_expires": "2025-06-18T12:00:00Z",
         "mcp_initialize_response": {



  Jennings, et al.          Expires 23 April 2026                [Page 21]


  Internet-Draft                MCP over MOQT                 October 2025


           "protocolVersion": "2025-06-18",
           "capabilities": {
             "resources": { "subscribe": true, "listChanged": true },
             "tools": { "progress": true },
             "prompts": { "listChanged": true },
             "elicitation": {}
           },
           "serverInfo": {
             "name": "ExampleServer",
             "version": "2.0.0"
           }
         }
       }
     }

  3.2.5.  Session Establishment Flow

     After receiving the discovery response, clients proceed with MCP
     session establishment using the provided session ID.  The flow
     depends on whether the RTT optimization was used:

  3.2.5.1.  Standard Discovery Flow

     1.  Track Subscription: Client subscribes to the control tracks using
         the session ID from the discovery response

     2.  MCP Initialize: Client sends the standard MCP initialize message
         on the client-to-server control track

     3.  Capability Negotiation: Server responds with its capabilities on
         the server-to-client control track

     4.  Session Active: Client begins normal MCP operations using the
         discovered tracks and session ID

  3.2.5.2.  Optimized Discovery Flow (with combined initialize)

     1.  Track Subscription: Client subscribes to the control tracks using
         the session ID from the discovery response

     2.  Session Active: Since MCP initialization was completed during
         discovery, the client can immediately begin normal MCP operations
         using the discovered tracks and negotiated capabilities

     The RTT optimization reduces the session establishment from 4 round-
     trips to 2 round-trips by combining discovery and initialization
     operations.




  Jennings, et al.          Expires 23 April 2026                [Page 22]


  Internet-Draft                MCP over MOQT                 October 2025


  3.3.  Priority Management

     MOQT's object priorities optimize MCP message delivery by considering
     the importance of different track types specified.

     The following priority assignments are RECOMMENDED, but applications
     may adjust them as needed.

     1.  Control Messages: Highest priority (1-10)

     2.  Tool Operations: High priority (20-30)

     3.  Notifications: Medium priority (40-60)

     4.  Resource Operations: Lower priority (70-90)

     5.  Logs: Lowest priority (100+)

     Priorities can also be adjusted based on:

     *  User interaction urgency (elicitation requests get higher
        priority)

     *  Tool execution criticality (error handling gets priority boost)

     *  Resource size and frequency (large resources get lower priority)

     *  Server load conditions (adaptive priority scaling)

  3.4.  Error Handling

     TODO

  4.  Relay Support

     MOQT relays enable scalable MCP deployments by providing intelligent
     aggregation, caching, and distribution capabilities that optimize
     performance for AI workflows and reduce server load across multiple
     clients.

  4.1.  Subscription Aggregation

     MOQT relays provide significant efficiency gains by aggregating
     multiple client subscriptions to the same content into single
     upstream requests.  When multiple clients subscribe to identical MCP
     resources, tools metadata, or notification streams, the relay
     consolidates these into a single subscription to the origin server,
     dramatically reducing server load and network bandwidth consumption.



  Jennings, et al.          Expires 23 April 2026                [Page 23]


  Internet-Draft                MCP over MOQT                 October 2025


  4.1.1.  Resource Subscription Aggregation

     When multiple clients subscribe to the same resource track, the relay
     maintains a single upstream subscription and fans out content to all
     interested clients:

  Client A subscribes: mcp/{session-id}/resources/documentation
  Client B subscribes: mcp/{session-id}/resources/documentation
  Client C subscribes: mcp/{session-id}/resources/documentation

  Relay behavior:
  - Single upstream subscription: mcp/{session-id}/resources/documentation
  - Fan-out to 3 downstream clients
  - Bandwidth savings: 3x reduction in server load

     The relay tracks subscription interest levels and automatically
     establishes upstream subscriptions when the first client subscribes
     to a track, and tears down the upstream subscription when the last
     client unsubscribes.

  4.1.2.  Tool Metadata Aggregation

     Tool discovery operations benefit significantly from aggregation
     since multiple clients typically need access to the same tool schemas
     and capabilities

     TODO: Add an examples

  4.2.  Content Caching for MCP and AI Workflows

  4.2.1.  Static Resources and Documentation

     Large documentation sets, API references, and knowledge bases
     represent the most cache-friendly content in MCP deployments.  These
     resources are accessed frequently across multiple AI sessions but
     change infrequently, making them ideal candidates for aggressive
     caching.

     Static resources are delivered through dedicated tracks like
     mcp/{session-id}/resources/{resource-uri} and benefit significantly
     from relay caching since multiple clients often access the same
     content.









  Jennings, et al.          Expires 23 April 2026                [Page 24]


  Internet-Draft                MCP over MOQT                 October 2025


  4.2.2.  Tool Schema and Configuration Caching

     Tool schemas, parameter definitions, and configuration metadata are
     cached aggressively since they define the stable interface contracts
     between AI applications and external services.  This metadata is
     cached with high TTL values, allowing relays to serve tool discovery
     requests without repeatedly querying the origin server.  Schema
     definitions are published as MOQT objects that remain valid until
     tools are modified or removed, making them ideal candidates for
     aggressive aching policies.  In case of modifications, new updated
     schema definitions are published with updated versioning info,

  4.2.3.  Capability Information and Session Metadata

     Server capability announcements that define supported features,
     resource types, and operational parameters negotiated during session
     establishment are cached via mcp/{session-id}/control/capabilities
     tracks as one-time objects published after MCP initialization,
     enabling relays to quickly respond to capability queries without
     server involvement.  The caching strategy uses long-term storage with
     explicit invalidation only on server restart or capability changes.

     Session metadata comprises initialization parameters, connection
     preferences, and configuration data that define session
     characteristics and relay behavior.  This metadata is distributed
     through mcp/{session-id}/control/metadata tracks as cacheable
     objects, with relay configuration parameters embedded in SERVER_SETUP
     message extensions.  The cached metadata enables consistent session
     behavior across client reconnections and provides relays with the
     information needed for optimal routing and caching decisions.

  4.2.4.  Model Context and History Caching

     For AI workflows that involve multi-turn conversations or context
     building, relays can cache conversation contexts and interaction
     histories to support session resumption and context sharing:

  4.3.  Track Name Discovery and Dynamic Updates

     MOQT relays enhance the MCP experience by providing efficient
     service-level discovery mechanisms that help clients understand
     available resources, tools, and services within established MCP
     sessions without requiring prior configuration knowledge.








  Jennings, et al.          Expires 23 April 2026                [Page 25]


  Internet-Draft                MCP over MOQT                 October 2025


  4.3.1.  Discovery Track Implementation

     Relays implement service-level discovery tracks that catalog
     available MCP services and their associated track patterns within a
     specific session:

     Track namespace: mcp/<session-id>/discovery Track name: catalog

     {
       "server_catalog": {
         "mcp/{session-id}/resources": {
           "available_tracks": [
             "documentation", "api_schemas", "examples", "templates"
           ],
           "content_types": ["text/markdown",
                  "application/json", "text/plain"],
           "update_frequency": "daily",
           "cache_recommended": true
         },
         "mcp/{session-id}/tools/": {
           "available_tracks": [
             "file_operations", "database_query", "code_analysis"
           ],
           "execution_types": ["synchronous", "asynchronous"],
           "progress_tracking": true,
           "cache_recommended": false
         },
         "mcp/{session-id}/prompts/": {
           "available_tracks": [
             "code_review", "data_analysis", "content_generation"
           ],
           "template_versions": ["1.0", "1.1", "2.0"],
           "cache_recommended": true
         }
       },
       "discovery_timestamp": "2025-06-18T10:30:00Z"
     }

  4.3.2.  Client Discovery via FETCH Operations

     Clients can efficiently discover available services by issuing FETCH
     requests to discovery tracks, receiving comprehensive information
     about available MCP capabilities








  Jennings, et al.          Expires 23 April 2026                [Page 26]


  Internet-Draft                MCP over MOQT                 October 2025


  4.3.3.  Asynchronous Updates via Subscriptions

     Beyond one-time discovery, clients can subscribe to discovery tracks
     to receive real-time updates when new services become available or
     existing services change their characteristics

     This subscription-based discovery update mechanism ensures that AI
     applications can dynamically adapt to changing service availability
     without requiring configuration changes or manual intervention.

  5.  Agent Skills and MCP Integration

     Agent Skills represent a powerful extension to the MCP ecosystem,
     providing modular capabilities that can be efficiently delivered and
     managed through MOQT's transport mechanisms.  This section describes
     how Skills integrate with MCP over MOQT.

  5.1.  Skills Architecture Overview

     Agent Skills are filesystem-based resources that extend AI
     capabilities through three progressive loading levels, along the
     following dimensions:

     *  Always loading metadata Loading (~100 tokens) provides basic skill
        identification and capabilities

     *  Dynamicaly loading instructionns when triggered (under 5k tokens)
        containing skill logic and execution parameters

     *  Resources and Code are loaded as needed for actual skill execution
        and data processing

     This progressive disclosure model aligns naturally with MOQT's
     object-based delivery system, where each loading level can be mapped
     to separate MOQT objects or tracks for optimal bandwidth utilization.

  5.2.  Skills Transport over MOQT

     Skills metadata is distributed through dedicated discovery tracks
     that enable clients to understand available capabilities without
     loading full skill implementations:

     Track namespace: mcp/<session-id>/skills Track name: catalog

     The skills catalog provides comprehensive metadata about available
     skills, their capabilities, dependencies, and loading requirements:





  Jennings, et al.          Expires 23 April 2026                [Page 27]


  Internet-Draft                MCP over MOQT                 October 2025


     {
       "available_skills": [
         {
           "skill_id": "powerpoint-processor",
           "name": "PowerPoint Processing",
           "description": "Create and modify PowerPoint presentations",
           "metadata_size": 95,
           "instructions_size": 4200,
           "resource_dependencies": ["office-templates", "style-schemas"],
           "security_level": "trusted",
           "loading_priority": "on-demand"
         },
         {
           "skill_id": "pdf-analyzer",
           "name": "PDF Analysis",
           "description": "Extract and analyze content from PDF documents",
           "metadata_size": 87,
           "instructions_size": 3800,
           "resource_dependencies": ["pdf-schemas"],
           "security_level": "sandboxed",
           "loading_priority": "preload"
         }
       ],
       "catalog_version": "1.2.0",
       "last_updated": "2025-06-18T10:30:00Z"
     }

     Skills leverage MOQT's object-based delivery for efficient
     progressive loading:

     Each skill's metadata is delivered as a single MOQT object containing
     basic capability information, version data, and loading requirements.

     Track namespace: `mcp/<session-id>/skills/<skill-id>`
     Track name: `metadata`

     When a skill is activated, its instruction set is loaded through
     dedicated objects containing execution logic, parameter schemas, and
     operational guidelines.

     Track namespace: `mcp/<session-id>/skills/<skill-id>`
     Track name: `instructions`

     Skill resources such as templates, schemas, and code modules are
     loaded on-demand through separate resource tracks, enabling fine-
     grained loading control.





  Jennings, et al.          Expires 23 April 2026                [Page 28]


  Internet-Draft                MCP over MOQT                 October 2025


     Track namespace: `mcp/<session-id>/skills/<skill-id>`
     Track name: `resources/<resource-type>`

  5.3.  Skills Composition and Workflow Integration

     Complex workflows can compose multiple skills together, with MOQT
     providing efficient coordination:

     *  Dependency Resolution: Skills declare dependencies that are
        automatically resolved through catalog metadata

     *  Execution Orchestration: Workflow engines can preload skill sets
        based on anticipated execution patterns

     *  Resource Sharing: Common skill resources are shared across
        workflow steps to minimize loading overhead

     Skills can share context and state through dedicated context tracks:

     Track namespace: mcp/<session-id>/skills/context Track name:
     <workflow-id>

     This enables sophisticated multi-step workflows where skills build
     upon each other's outputs while maintaining clean separation of
     concerns.

     MOQT relays implement sophisticated caching for skill distribution:

     *  Metadata Caching: Skill catalogs cached with high TTL for quick
        discovery

     *  Instruction Caching: Frequently used skills cached at edge
        locations

     *  Resource Deduplication: Common skill resources shared across
        multiple skills

     *  Version Management: Skill updates distributed efficiently through
        version-aware object delivery

     AI applications can implement predictive skill loading based on user
     patterns and workflow analysis, using MOQT's subscription management
     to preload likely-needed skills while avoiding bandwidth waste.








  Jennings, et al.          Expires 23 April 2026                [Page 29]


  Internet-Draft                MCP over MOQT                 October 2025


  6.  Shared Context Between One MCP Client and Multiple MCP Servers

     When a single MCP client connects to multiple MCP servers
     simultaneously, shared context management becomes critical for
     maintaining consistency, efficiency, and proper resource allocation
     across all active sessions.  This section describes the mechanisms
     and considerations for managing shared context in multi-server MCP
     deployments over MOQT.

  6.1.  Context Sharing Architecture

     In a shared context scenario, the MCP client acts as a central
     coordinator that maintains relationships with multiple MCP servers,
     each providing different capabilities, resources, or specialized
     services.  The client must manage session state, resource
     subscriptions, and context information across all servers while
     ensuring proper isolation and security boundaries.

  6.1.1.  Session Isolation and Coordination

     Each MCP server connection maintains its own unique session ID and
     track namespace to ensure proper isolation:

     Server A: mcp/session-a-uuid/resources/documentation
     Server B: mcp/session-b-uuid/tools/code_analysis
     Server C: mcp/session-c-uuid/prompts/review_templates

     The client coordinates these separate sessions while maintaining a
     unified view of available capabilities across all connected servers.

  6.2.  Context Synchronization Mechanisms

  6.2.1.  Resource Context Sharing

     When multiple servers provide related resources, the client can
     implement context synchronization by subscribing to relevant resource
     tracks from multiple servers and maintaining a unified context state.

  6.2.2.  Tool Execution Context

     Tool executions across multiple servers may require shared context to
     maintain workflow consistency.  Tracking tool execution state across
     all severs help ensure proper sequencing of multi-server workflows.
     Similarly results from tools on one server can be automatically
     passed as parameters to tools on other servers, for example.

  6.3.  Context Synchronization Benefits




  Jennings, et al.          Expires 23 April 2026                [Page 30]


  Internet-Draft                MCP over MOQT                 October 2025


  6.3.1.  Shared Subscription Management

     The client optimizes network usage by implementing intelligent
     subscription management across multiple servers:

     *  When multiple servers offer similar resources, the client can
        subscribe to the most appropriate source based on performance,
        recency, or quality metrics

     *  Resource requests can be distributed across servers based on
        current load, response time, or geographic proximity

     *  If one server becomes unavailable, the client can seamlessly
        redirect subscriptions to alternative servers providing similar
        capabilities

  6.3.2.  Context Caching and Reuse

     The client implements sophisticated caching strategies that work
     across all connected servers:

     *  Context information cached from one server can be reused when
        working with other servers, where appropriate.

     *  The client tracks resource versions across all servers to ensure
        cache consistency

     *  Only changed context elements are synchronized across servers to
        minimize bandwidth usage

  7.  Security Considerations

     TODO

  8.  IANA Considerations

     TODO

  9.  Examples

  10.  References

  10.1.  Normative References

     [MCP]      Anthropic, "Model Context Protocol Specification", 18 June
                2025, <https://modelcontextprotocol.io/
                specification/2025-06-18>.




  Jennings, et al.          Expires 23 April 2026                [Page 31]


  Internet-Draft                MCP over MOQT                 October 2025


     [MOQT]     Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell,
                "Media over QUIC Transport", 23 June 2025,
                <https://www.ietf.org/archive/id/draft-ietf-moq-transport-
                13>.

     [QUIC]     Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
                and Secure Transport", May 2021,
                <https://www.rfc-editor.org/rfc/rfc9000.html>.

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

  10.2.  Informative References

     [WebTransport]
                Vasiliev, V., "The WebTransport Protocol Framework", June
                2023, <https://www.rfc-editor.org/rfc/rfc9297.html>.

  Appendix A.  Acknowledgments

     TODO

  Authors' Addresses

     Cullen Jennings
     Cisco Systems
     Email: fluffy@cisco.com


     Ian Swett
     Google
     Email: ianswett@google.com


     Jonathan Rosenberg
     Five9
     Email: jdrosen@jdrosen.net


     Suhas Nandakumar
     Cisco Systems
     Email: snandaku@cisco.com



  Jennings, et al.          Expires 23 April 2026                [Page 32]


name: draft-jennings-mcp-over-moqt
rev: 00
title: Model Context Protocol over Media over QUIC Transport
time: 2025-10-20T19:53:20Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T19:53:20Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.111166+00:00
source: ietf
abstract:
  This document defines how to use Media over QUIC Transport (MOQT) as
     the underlying transport protocol for the Model Context Protocol
     (MCP).  MCP is a protocol that enables seamless integration between
     language model applications and external data sources and tools.
     MOQT provides efficient, low-latency, publish-subscribe media
     delivery over QUIC and WebTransport.  This specification describes
     the mapping of MCP messages onto MOQT objects and defines the
     procedures for establishing and maintaining MCP sessions over MOQT.

full_text:
  Model Context Protocol                                       C. Jennings
  Internet-Draft                                             Cisco Systems
  Intended status: Experimental                                   I. Swett
  Expires: 23 April 2026                                            Google
                                                              J. Rosenberg
                                                                     Five9
                                                             S. Nandakumar
                                                             Cisco Systems
                                                           20 October 2025


           Model Context Protocol over Media over QUIC Transport
                         draft-jennings-mcp-over-moqt-00

  Abstract

     This document defines how to use Media over QUIC Transport (MOQT) as
     the underlying transport protocol for the Model Context Protocol
     (MCP).  MCP is a protocol that enables seamless integration between
     language model applications and external data sources and tools.
     MOQT provides efficient, low-latency, publish-subscribe media
     delivery over QUIC and WebTransport.  This specification describes
     the mapping of MCP messages onto MOQT objects and defines the
     procedures for establishing and maintaining MCP sessions over MOQT.

  About This Document

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

     The latest revision of this draft can be found at
     https://example.org/mcp-moqt/.  Status information for this document
     may be found at https://datatracker.ietf.org/doc/draft-mcp-over-
     moqt/.

     Discussion of this document takes place on the Model Context Protocol
     Working Group mailing list (mailto:mcp@example.org), which is
     archived at https://example.org/mcp/.

     Source for this draft and an issue tracker can be found at
     https://github.com/example/mcp-moqt.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.






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


  Internet-Draft                MCP over MOQT                 October 2025


     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.

     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  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   4
         1.1.1.  Current Transport Challenges  . . . . . . . . . . . .   4
         1.1.2.  MCP over MOQT . . . . . . . . . . . . . . . . . . . .   5
         1.1.3.  Operational Advantages  . . . . . . . . . . . . . . .   5
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
       1.3.  Protocol Overview . . . . . . . . . . . . . . . . . . . .   6
         1.3.1.  MCP Lifecycle State Chart . . . . . . . . . . . . . .   7
         1.3.2.  System Components . . . . . . . . . . . . . . . . . .   8
     2.  MOQT Tracks for MCP . . . . . . . . . . . . . . . . . . . . .   9
       2.1.  Control Flow  . . . . . . . . . . . . . . . . . . . . . .   9
         2.1.1.  Client-to-Server Control Track  . . . . . . . . . . .   9
         2.1.2.  Server-to-Client Control Track  . . . . . . . . . . .   9
       2.2.  Track Types . . . . . . . . . . . . . . . . . . . . . . .  10
         2.2.1.  Control Tracks  . . . . . . . . . . . . . . . . . . .  10
         2.2.2.  Resource Tracks . . . . . . . . . . . . . . . . . . .  10
         2.2.3.  Tool Tracks . . . . . . . . . . . . . . . . . . . . .  11
         2.2.4.  Prompt Tracks . . . . . . . . . . . . . . . . . . . .  11
         2.2.5.  Notification Tracks . . . . . . . . . . . . . . . . .  12
         2.2.6.  Elicitation Tracks  . . . . . . . . . . . . . . . . .  13



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


  Internet-Draft                MCP over MOQT                 October 2025


         2.2.7.  Log Tracks  . . . . . . . . . . . . . . . . . . . . .  14
     3.  Protocol Operation  . . . . . . . . . . . . . . . . . . . . .  15
       3.1.  MOQT Session Establishment  . . . . . . . . . . . . . . .  15
       3.2.  Proposed Session ID Discovery . . . . . . . . . . . . . .  15
         3.2.1.  Well-Known Discovery Track  . . . . . . . . . . . . .  15
         3.2.2.  Discovery Flow  . . . . . . . . . . . . . . . . . . .  16
         3.2.3.  Discovery Request Format  . . . . . . . . . . . . . .  17
         3.2.4.  Discovery Response Format . . . . . . . . . . . . . .  19
         3.2.5.  Session Establishment Flow  . . . . . . . . . . . . .  22
       3.3.  Priority Management . . . . . . . . . . . . . . . . . . .  23
       3.4.  Error Handling  . . . . . . . . . . . . . . . . . . . . .  23
     4.  Relay Support . . . . . . . . . . . . . . . . . . . . . . . .  23
       4.1.  Subscription Aggregation  . . . . . . . . . . . . . . . .  23
         4.1.1.  Resource Subscription Aggregation . . . . . . . . . .  24
         4.1.2.  Tool Metadata Aggregation . . . . . . . . . . . . . .  24
       4.2.  Content Caching for MCP and AI Workflows  . . . . . . . .  24
         4.2.1.  Static Resources and Documentation  . . . . . . . . .  24
         4.2.2.  Tool Schema and Configuration Caching . . . . . . . .  25
         4.2.3.  Capability Information and Session Metadata . . . . .  25
         4.2.4.  Model Context and History Caching . . . . . . . . . .  25
       4.3.  Track Name Discovery and Dynamic Updates  . . . . . . . .  25
         4.3.1.  Discovery Track Implementation  . . . . . . . . . . .  26
         4.3.2.  Client Discovery via FETCH Operations . . . . . . . .  26
         4.3.3.  Asynchronous Updates via Subscriptions  . . . . . . .  27
     5.  Agent Skills and MCP Integration  . . . . . . . . . . . . . .  27
       5.1.  Skills Architecture Overview  . . . . . . . . . . . . . .  27
       5.2.  Skills Transport over MOQT  . . . . . . . . . . . . . . .  27
       5.3.  Skills Composition and Workflow Integration . . . . . . .  29
     6.  Shared Context Between One MCP Client and Multiple MCP
             Servers . . . . . . . . . . . . . . . . . . . . . . . . .  30
       6.1.  Context Sharing Architecture  . . . . . . . . . . . . . .  30
         6.1.1.  Session Isolation and Coordination  . . . . . . . . .  30
       6.2.  Context Synchronization Mechanisms  . . . . . . . . . . .  30
         6.2.1.  Resource Context Sharing  . . . . . . . . . . . . . .  30
         6.2.2.  Tool Execution Context  . . . . . . . . . . . . . . .  30
       6.3.  Context Synchronization Benefits  . . . . . . . . . . . .  30
         6.3.1.  Shared Subscription Management  . . . . . . . . . . .  31
         6.3.2.  Context Caching and Reuse . . . . . . . . . . . . . .  31
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  31
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  31
     9.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  31
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  31
       10.2.  Informative References . . . . . . . . . . . . . . . . .  32
     Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  32
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32





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


  Internet-Draft                MCP over MOQT                 October 2025


  1.  Introduction

     The Model Context Protocol (MCP) [MCP] is an open protocol that
     enables seamless integration between LLM applications and external
     data sources and tools.  MCP uses JSON-RPC 2.0 for message exchange
     and can operate over various transport protocols.

     Media over QUIC Transport (MOQT) [MOQT] is a protocol optimized for
     QUIC [QUIC] that provides efficient publish-subscribe media delivery
     with support for content distribution networks and low-latency
     requirements.

     This document outlines the use of MOQT as the transport layer for
     MCP, utilizing MOQT's object delivery and QUIC's multiplexed streams
     for low-latency communication.  Paired unidirectional tracks enable
     real-time interactions between language models and external systems.
     MOQT's object-based delivery allows efficient resource and tool
     sharing across clients without redundant transfers.  Relay networks
     support scalable content distribution, enabling global MCP deployment
     with optimized performance.  Native prioritization ensures critical
     operations like tool execution and user interactions receive
     sufficient bandwidth.  QUIC's connection migration and recovery
     provide reliable connectivity in mobile and unstable networks.

  1.1.  Motivation

     The Model Context Protocol (MCP) enables AI applications to integrate
     with external data sources and tools, but current transport
     mechanisms
     poses challenges that can hinder optimal performance and scalability.
     This specification addresses these challenges by leveraging Media
     over QUIC Transport (MOQT) as an alternate transport layer
     specifically optimized for MCP's operational requirements.

  1.1.1.  Current Transport Challenges

     WebSocket Transport lacks native prioritization mechanisms, causing
     critical control messages and urgent tool operations to compete
     equally with routine resource updates.  Head-of-line blocking occurs
     when large resource transfers delay time-sensitive operations, and
     the protocol provides no built-in caching or relay capabilities for
     scalable content distribution.

     HTTP Transport operates on a strict request-response model that
     conflicts with MCP's inherently event-driven architecture.  This
     mismatch forces artificial polling patterns for resource updates and
     prevents efficient server-initiated notifications.  While Server Side
     Streaming provides a mechanism for servers to send asynchronous



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


  Internet-Draft                MCP over MOQT                 October 2025


     events, it introduces significant challenges including connection
     complexity, limited browser support, proxy interference, and
     difficultly in handling bidirectional communication patterns
     essential for interactive MCP operations.  Additionally, HTTP/1.1's
     connection limitations and HTTP/2's stream dependencies create
     bottlenecks in high-throughput AI applications.

  1.1.2.  MCP over MOQT

     MOQT's publish-subscribe architecture provides an ideal foundation
     for MCP operations, where MCP servers naturally function as
     publishers of resources, tools, and capabilities, while clients
     subscribe to relevant content streams.  This alignment enables
     several key architectural benefits:

     *Semantic Mapping*: MCP's resource-centric model maps directly to
     MOQT's track-based content organization.  Each resource, tool, or
     capability becomes a dedicated track with independent lifecycle
     management, version control, and access policies.

     *Event-Driven Communication*: MOQT's native support for asynchronous
     object delivery matches MCP's notification-based architecture,
     eliminating the artificial request-response constraints imposed by
     HTTP transport.

     *Priority-Aware Delivery*: MOQT's built-in prioritization system
     enables sophisticated quality-of-service policies, ensuring that
     critical MCP operations like tool execution and user interactions
     receive appropriate bandwidth allocation and reduced latency.

  1.1.3.  Operational Advantages

     The combination of MCP and MOQT can offer operational improvements
     along the following dimensions:

     Low Latency Operations: MOQT's object-based delivery model eliminates
     traditional HTTP request-response overhead, enabling direct message
     passing with minimal protocol overhead.  Tool execution requests are
     sent as prioritized FETCH operations while control messages receive
     the highest priority (1-2), ensuring responsive interaction even
     under high system load.

     Bandwidth Efficiency: MOQT relays provide sophisticated caching
     mechanisms and subscription aggregations, that deduplicate frequently
     accessed resources across multiple clients.  Large documentation
     sets, configuration files, and static assets are cached at relay
     points, dramatically reducing origin server load while enabling
     selective updates through version-aware object delivery.



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


  Internet-Draft                MCP over MOQT                 October 2025


     Multiplexing and Concurrency: QUIC's multiplexing capabilities
     prevent head-of-line blocking between different MCP operations,
     allowing hundreds of concurrent tool executions, resource
     subscriptions, and notification streams to operate independently
     without mutual interference.

     Network Resilience and Mobility: QUIC's connection migration and
     0-RTT reconnection capabilities maintain session continuity across
     network changes, a critical requirement for mobile AI applications
     and long-running workflows that may experience network interruptions.

     Edge-Optimized Content Distribution: The relay infrastructure
     supports geographically distributed caching and intelligent content
     placement, enabling global MCP deployments with optimized performance
     characteristics tailored to regional access patterns and data
     locality requirements.

  1.2.  Terminology

     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.

     This document uses terminology from [MCP] and [MOQT].

  1.3.  Protocol Overview

     MCP uses MOQT to map its abstractions to MOQT's transport mechanisms.
     MCP messages, encoded as JSON-RPC 2.0, are embedded in MOQT payloads,
     ensuring compatibility with MCP formats and efficient transport over
     QUIC streams.

     MCP sessions use MOQT sessions for communication, starting with a
     handshake to negotiate capabilities.  This phase ensures clients and
     servers agree on features, resource types, and parameters.

     MCP Resources are server-controlled data sources exposed to clients
     for read access.  In MOQT, each resource is published over
     *resources* track.  Content is delivered via MOQT objects, supporting
     various data types like files, API responses, database results, and
     version control history.  Streaming enables efficient handling of
     large resources, while automatic updates use new objects with updated
     sequence numbers for incremental changes.  This supports advanced
     caching and efficient client synchronization.





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


  Internet-Draft                MCP over MOQT                 October 2025


     Tools enable servers to execute client-requested operations.  MOQT
     maps tools to dedicated *tools* tracks and uses FETCH for request-
     response patterns.  Supported operations include API calls, file
     tasks, computations, and service integrations.  Progress tracking
     uses notifications for real-time updates.  FETCH ensures robust
     execution with prioritization, multiplexing, error handling, and
     timeout management.

     Notifications about resource changes and events are published in
     specialized tracks, allowing clients to subscribe without affecting
     other channels.  User input is managed through interactive control
     tracks for consent and data collection.

  1.3.1.  MCP Lifecycle State Chart

                         ┌─────────────┐
                         │ DISCONNECTED│
                         └──────┬──────┘
                                │ QUIC Connect
                                ▼
                         ┌─────────────┐
                         │ TRANSPORT   │
                         │ CONNECTED   │
                         └──────┬──────┘
                                │ MOQT Setup
                                ▼
                         ┌─────────────┐
                         │ MOQT        │
                         │ ESTABLISHED │
                         └──────┬──────┘
                                │ Track Subscribe
                                ▼
                         ┌─────────────┐
                         │ TRACKS      │
                         │ SUBSCRIBED  │
                         └──────┬──────┘
                                │ MCP Initialize
                                ▼
                         ┌─────────────┐
                         │ MCP         │
                         │ INITIALIZING│
                         └──────┬──────┘
                                │ Capabilities Exchange
                                ▼
                         ┌─────────────┐
                         │ CAPABILITIES│
                         │ NEGOTIATED  │
                         └──────┬──────┘



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


  Internet-Draft                MCP over MOQT                 October 2025


                                │ Discovery Complete
                                ▼
                         ┌─────────────┐
             ┌──────────▶│ MCP ACTIVE  │◀──────────┐
             │           │             │           │
             │           └─────┬───┬───┘           │
             │                 │   │               │
             │ Tool Result     │   │ Notification  │ Resource Update
             │                 │   │               │
             ▼                 │   ▼               │
      ┌─────────────┐          │ ┌─────────────┐   │
      │ TOOL        │          │ │ ELICITATION │   │
      │ EXECUTING   │──────────┘ │ PENDING     │   │
      └─────────────┘            └─────────────┘   │
             │                         │           │
             └─────────────────────────┼───────────┘
                                       │
                                       ▼
                                ┌─────────────┐
                                │ SESSION     │
                                │ TERMINATING │
                                └──────┬──────┘
                                       │ Cleanup
                                       ▼
                                ┌─────────────┐
                                │ DISCONNECTED│
                                └─────────────┘

  1.3.2.  System Components

     Below figure shows system components proposed in this specification.

     ┌─────────────────┐    MOQT Session    ┌─────────────────┐
     │   MCP Client    │<==================>│   MCP Server    │
     │                 │                    │                 │
     │ ┌─────────────┐ │                    │ ┌─────────────┐ │
     │ │MCP Transport│ │                    │ │MCP Transport│ │
     │ │   Adapter   │ │                    │ │   Adapter   │ │
     │ └─────────────┘ │                    │ └─────────────┘ │
     │ ┌─────────────┐ │                    │ ┌─────────────┐ │
     │ │    MOQT     │ │                    │ │    MOQT     │ │
     │ │  Endpoint   │ │                    │ │  Endpoint   │ │
     │ └─────────────┘ │                    │ └─────────────┘ │
     └─────────────────┘                    └─────────────────┘

     The MCP client-host-server architecture maps to MOQT as follows:





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


  Internet-Draft                MCP over MOQT                 October 2025


     *  *MCP Host*: Acts as MOQT client, managing multiple server
        connections

     *  *MCP Client*: Implemented as MCP transport adapter within the host

     *  *MCP Server*: Acts as MOQT publisher, exposing resources, tools,
        and prompts

  2.  MOQT Tracks for MCP

  2.1.  Control Flow

     The control flow establishes the fundamental communication channels
     for MCP session management and coordination.  This specifcation
     prposes 2 unidirectional tracks for direction for performing session
     establishment, capability negotiation, and various control operations
     using the MOQT's publish-subscribe semantics.

  2.1.1.  Client-to-Server Control Track

     *  *Publisher*: MCP Client

     *  *Subscribers*: MCP Server, optional monitoring relays

     *  *Content*:

        -  MCP initialize requests

        -  Ping messages (client-initiated)

        -  Capability negotiation requests

        -  Session teardown requests

        -  Tool cancellation requests

  2.1.2.  Server-to-Client Control Track

     *  *Publisher*: MCP Server

     *  *Subscribers*: MCP Client, optional monitoring relays

     *  *Content*:

        -  MCP initialize responses

        -  Pong messages (server responses)




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


  Internet-Draft                MCP over MOQT                 October 2025


        -  Capability negotiation responses

        -  Session teardown confirmations

        -  Server-initiated status updates

  2.2.  Track Types

     The various sub-sections provides information on track naming design
     defined by this specification to map to MCP operations.

  2.2.1.  Control Tracks

     Control tracks map MCP session management and coordination messages
     including initialization, ping/pong heartbeats, and capability
     negotiation and 2 unidirectional tracks for server and client to
     carryout message exchanges.

     Track namespace:

     (mcp, <session-id>, control)

     Track name (Client-to-Server):

     (client-to-server)

     Track name (Server-to-Client):

     (server-to-client)

     Groups and objects are mapped as follows:

     Each MCP control message is encoded as a single MOQT object within a
     group.  Group IDs are assigned sequentially starting from 0,
     incrementing for each new control message.  Object IDs within each
     group are always 0 since each control message maps to exactly one
     object.  Objects contain JSON-encoded MCP control messages as defined
     in the MCP specification.

  2.2.2.  Resource Tracks

     Resource tracks map MCP resources, delivering server-published
     content and metadata that serve as the main data sources exposed by
     MCP servers to clients.

     Track namespace:

     (mcp, <session-id>, resources)



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


  Internet-Draft                MCP over MOQT                 October 2025


     Track name:

     (<resource-uri>)

     Groups and objects are mapped as follows:

     Each resource version is assigned a unique group ID, starting from 0
     and incrementing with each resource update.  Within each group,
     objects represent chunks or segments of the resource content.  Object
     IDs start at 0 and increment sequentially for each chunk.  Objects
     contain the actual resource data encoded according to the resource's
     declared content type (binary data, JSON, text, etc.).

  2.2.3.  Tool Tracks

     Tool tracks map MCP tool execution, facilitating tool invocation
     requests, responses, and progress updates using MOQT's FETCH
     operations.

     Track namespace:

     (mcp, <session-id&>, tools)

     Track name:

     (<tool-name>)

     Groups and objects are mapped as follows:

     Each tool invocation creates a new group with a unique group ID
     assigned by the requesting client.  Within each group, object ID 0
     contains the tool request (JSON-encoded MCP tool call), subsequent
     object IDs contain tool responses and progress updates.  Objects are
     JSON-encoded according to the MCP tool execution protocol.

  2.2.4.  Prompt Tracks

     Prompt tracks map MCP prompts, distributing pre-defined templates and
     instructions that standardize common operations across the MCP
     ecosystem.

     Track namespace:

     (mcp, <session-id>, prompts)

     Track name:

     (<prompt-name>)



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


  Internet-Draft                MCP over MOQT                 October 2025


     Groups and objects are mapped as follows:

     Each prompt version is assigned a unique group ID starting from 0,
     incrementing with each prompt update.  Within each group, object ID 0
     contains the prompt template and metadata.  Objects contain JSON-
     encoded prompt definitions including template text, parameter
     schemas, and versioning information.

  2.2.5.  Notification Tracks

     Notification tracks map MCP notifications, providing asynchronous
     event delivery for server-sent notifications, progress updates, and
     system events.

     Track namespace:

     (mcp, <session-id>, notifications)

     Track name:

     (<category>)

     The category parameter classifies notification types to enable
     efficient subscription management and routing.  Common category
     values include:

     *  progress - Tool execution progress updates and status reports

     *  resources - Resource change notifications (listChanged, updated)

     *  prompts - Prompt template updates and availability changes

     *  system - Server status updates, connection events, error
        conditions

     *  elicitation - User input request notifications and responses

     *  tools - Tool availability changes and capability updates

     Custom categories may be defined for application-specific
     notification types following the pattern <domain>/<type> (e.g., ai/
     model_updated, workspace/file_changed).

     Groups and objects are mapped as follows:







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


  Internet-Draft                MCP over MOQT                 October 2025


     Each notification event creates a new group with group IDs assigned
     sequentially starting from 0.  Within each group, object ID 0
     contains the notification payload.  Objects contain JSON-encoded
     notification messages as defined in the MCP specification, including
     event type, timestamp, and payload data.

  2.2.6.  Elicitation Tracks

     Elicitation tracks map MCP user input collection, handling
     interactive flows for gathering user consent and data through pairs
     of unidirectional tracks.  The elicitation flow uses a unidirectional
     track pair to collect user input efficiently while preserving
     privacy.  Each request creates isolated track pairs, allowing
     concurrent operations.  Servers request user consent and input, while
     clients retain control to reject or modify requests.

     Track namespace:

     (mcp, <session-id>, elicitation, <request-id>)

     Track name (Server-to-Client):

     (<server-to-client>)

     Track name (Client-to-Server):

     (<client-to-server>)

     The Server-to-Client elicitation track is published by the MCP Server
     and subscribed to by the MCP Client, carrying:

     *  Elicitation request initiation

     *  Input schema definitions

     *  Validation error messages

     *  Request timeout notifications

     *  Request cancellation notices

     The Client-to-Server elicitation track is published by the MCP Client
     and subscribed to by the MCP Server, carrying:

     *  User consent responses

     *  Input data submissions




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


  Internet-Draft                MCP over MOQT                 October 2025


     *  Request rejection notifications

     *  Request cancellation confirmations

     Groups and objects are mapped as follows:

     Each elicitation exchange creates new groups with group IDs starting
     from 0 and incrementing for each message in the exchange.  Within
     each group, object ID 0 contains the elicitation message (request,
     response, or status update).  Objects contain JSON-encoded
     elicitation messages including input schemas, validation
     requirements, and user responses.

  2.2.7.  Log Tracks

     Log tracks map MCP logging information, providing debugging and
     monitoring capabilities by carrying diagnostic information for system
     troubleshooting and performance optimization.

     Track namespace:

     (mcp, <session-id>, logs)

     Track name:

     (<category>)

     The category parameter organizes log entries by severity level and
     source component to enable selective monitoring and efficient log
     processing.  Standard category values include:

     *  error - Error conditions, exceptions, and critical failures

     *  warn - Warning messages and non-critical issues requiring
        attention

     *  info - General informational messages about system operations

     *  debug - Detailed debugging information for troubleshooting

     *  trace - Fine-grained execution tracing for performance analysis

     *  audit - Security and compliance audit trails

     *  metrics - Performance metrics and system statistics






  Jennings, et al.          Expires 23 April 2026                [Page 14]


  Internet-Draft                MCP over MOQT                 October 2025


     Component-specific categories may be defined using the pattern
     <level>/<component> (e.g., error/transport, debug/tools, info/
     resources) to provide granular filtering capabilities.

     Groups and objects are mapped as follows:

     Each log entry creates a new group with group IDs assigned
     sequentially starting from 0, ordered by log timestamp.  Within each
     group, object ID 0 contains the log entry.  Objects contain JSON-
     encoded log messages including severity level, timestamp, source
     component, and message content.

  3.  Protocol Operation

  3.1.  MOQT Session Establishment

     The session establishment process begins with establishing the
     underlying MOQT session, which can be either a direct QUIC connection
     or a WebTransport [WebTransport] session depending on the deployment
     environment.  QUIC connections provide optimal performance for
     server-to- server communication, while WebTransport enables browser-
     based clients to participate in MCP sessions.

     The MOQT handshake phase involves the exchange of CLIENT_SETUP (0x20)
     and SERVER_SETUP (0x21) messages that negotiate protocol versions,
     supported features, and operational parameters.

  3.2.  Proposed Session ID Discovery

     MCP sessions require unique identifiers to organize track namespaces
     and enable proper message routing.  This section defines a well-known
     track approach for session discovery that allows clients to
     dynamically discover available MCP services and obtain session
     identifiers through standardized FETCH operations.

  3.2.1.  Well-Known Discovery Track

     The discovery mechanism uses a well-known track namespace and name
     that all MCP servers must support.  This track serves as the entry
     point for clients to discover available MCP sessions and obtain the
     necessary session identifiers for subsequent operations.

     Track Namespace: mcp/discovery
     Track Name: sessions







  Jennings, et al.          Expires 23 April 2026                [Page 15]


  Internet-Draft                MCP over MOQT                 October 2025


     Clients initiate discovery by sending a FETCH request to this well-
     known track, providing a client-side nonce or identifier as a
     parameter.  The server responds with a JSON-encoded MOQT object
     containing server details, a newly minted session identifier, and
     information about available tracks on that server.

  3.2.2.  Discovery Flow

     The session discovery process follows this sequence:

  3.2.2.1.  Standard Discovery Flow

         Client                         Server
            │                             │
            │ FETCH mcp/discovery/sessions│
            │ (with client nonce)         │
            │────────────────────────────▶│
            │                             │
            │                             │ Generate session ID
            │                             │ Prepare track catalog
            │                             │
            │     FETCH_OK                │
            │◀────────────────────────────│
            │                             │
            │ Data stream: FETCH_HEADER   │
            │ + Object with session       │
            │ details                     │
            │◀────────────────────────────│
            │                             │
            │ Subscribe to control tracks │
            │────────────────────────────▶│
            │                             │
            │ MCP Initialize              │
            │────────────────────────────▶│
            │                             │
            │ Initialize Response         │
            │◀────────────────────────────│
            │                             │
            │ Begin MCP operations        │
            │────────────────────────────▶│

  3.2.2.2.  Optimized Discovery Flow (RTT Reduction)









  Jennings, et al.          Expires 23 April 2026                [Page 16]


  Internet-Draft                MCP over MOQT                 October 2025


         Client                         Server
            │                             │
            │ FETCH mcp/discovery/sessions│
            │ (with nonce + MCP init)     │
            │────────────────────────────▶│
            │                             │
            │                             │ Generate session ID
            │                             │ Process MCP initialize
            │                             │ Prepare track catalog
            │                             │
            │     FETCH_OK                │
            │◀────────────────────────────│
            │                             │
            │ Data stream: FETCH_HEADER   │
            │ + Object with session       │
            │ details + MCP init response │
            │◀────────────────────────────│
            │                             │
            │ Subscribe to control tracks │
            │────────────────────────────▶│
            │                             │
            │ Begin MCP operations        │
            │ (initialization complete)   │
            │────────────────────────────▶│

  3.2.3.  Discovery Request Format

     Clients send FETCH requests to the well-known discovery track with a
     client-generated nonce or identifier in the payload:






















  Jennings, et al.          Expires 23 April 2026                [Page 17]


  Internet-Draft                MCP over MOQT                 October 2025


     FETCH {
       Type (i) = 0x16,
       Length (16),
       Request ID (i) = 1,
       Subscriber Priority (8) = 30,
       Group Order (8) = 0,
       Fetch Type (i) = 0x1,  // Standalone
       Track Namespace (tuple) = (... "mcp", "discovery"),
       Track Name Length (i) = 8,
       Track Name = "sessions",
       Start Location = {Group: 0, Object: 0},
       End Location = {Group: 0, Object: 1},
       Number of Parameters (i) = 1,
       Parameters = {
         "mcp_payload": {
           "jsonrpc": "2.0",
           "id": 1,
           "method": "discovery/request_session",
           "params": {
             "client_nonce": "client-nonce-abc123",
             "client_info": {
               "name": "ExampleClient",
               "version": "1.0.0"
             },
             "requested_capabilities": ["resources", "tools", "prompts"]
           }
         }
       }
     }

  3.2.3.1.  RTT Optimization with Combined Initialize

     To reduce round-trip time, clients MAY include their MCP initialize
     request within the discovery FETCH payload.  This allows the server
     to perform both session discovery and MCP initialization in a single
     exchange:















  Jennings, et al.          Expires 23 April 2026                [Page 18]


  Internet-Draft                MCP over MOQT                 October 2025


     FETCH {
       Type (i) = 0x16,
       Length (16),
       Request ID (i) = 1,
       Subscriber Priority (8) = 30,
       Group Order (8) = 0,
       Fetch Type (i) = 0x1,  // Standalone
       Track Namespace (tuple) = ("mcp", "discovery"),
       Track Name Length (i) = 8,
       Track Name = "sessions",
       Start Location = {Group: 0, Object: 0},
       End Location = {Group: 0, Object: 1},
       Number of Parameters (i) = 1,
       Parameters = {
         "mcp_payload": {
           "jsonrpc": "2.0",
           "id": 1,
           "method": "discovery/request_session_with_init",
           "params": {
             "client_nonce": "client-nonce-abc123",
             "client_info": {
               "name": "ExampleClient",
               "version": "1.0.0"
             },
             "requested_capabilities": ["resources", "tools", "prompts"],
             "mcp_initialize": {
               "protocolVersion": "2025-06-18",
               "capabilities": {
                 "resources": { "subscribe": true },
                 "tools": { "progress": true },
                 "prompts": {},
                 "elicitation": {}
               },
               "clientInfo": {
                 "name": "ExampleClient",
                 "version": "1.0.0"
               }
             }
           }
         }
       }
     }

  3.2.4.  Discovery Response Format

     The server responds with a JSON-encoded MOQT object containing the
     newly minted session ID and available track information:




  Jennings, et al.          Expires 23 April 2026                [Page 19]


  Internet-Draft                MCP over MOQT                 October 2025


     {
       "jsonrpc": "2.0",
       "id": 1,
       "result": {
         "session_id": "session-uuid-456",
         "server_info": {
           "name": "ExampleServer",
           "version": "2.0.0",
           "protocol_version": "2025-06-18"
         },
         "available_tracks": {
           "control": {
             "client_to_server":
                "mcp/session-uuid-456/control/client-to-server",
             "server_to_client":
                "mcp/session-uuid-456/control/server-to-client"
           },
           "resources": [
             {
               "name": "documentation",
               "track": "mcp/session-uuid-456/resources/documentation",
               "content_type": "text/markdown",
               "description": "API documentation and guides"
             }
           ],
           "tools": [
             {
               "name": "file_operations",
               "track": "mcp/session-uuid-456/tools/file_operations",
               "description": "File system operations"
             }
           ],
           "prompts": [
             {
               "name": "code_review",
               "track": "mcp/session-uuid-456/prompts/code_review",
               "description": "Code review prompt templates"
             }
           ]
         },
         "session_expires": "2025-06-18T12:00:00Z"
       }
     }








  Jennings, et al.          Expires 23 April 2026                [Page 20]


  Internet-Draft                MCP over MOQT                 October 2025


  3.2.4.1.  Combined Discovery and Initialize Response

     When the client uses the RTT optimization by including MCP initialize
     in the discovery request, the server responds with both session
     discovery and MCP initialization results:

     {
       "jsonrpc": "2.0",
       "id": 1,
       "result": {
         "session_id": "session-uuid-456",
         "server_info": {
           "name": "ExampleServer",
           "version": "2.0.0",
           "protocol_version": "2025-06-18"
         },
         "available_tracks": {
           "control": {
             "client_to_server":
                "mcp/session-uuid-456/control/client-to-server",
             "server_to_client":
                "mcp/session-uuid-456/control/server-to-client"
           },
           "resources": [
             {
               "name": "documentation",
               "track": "mcp/session-uuid-456/resources/documentation",
               "content_type": "text/markdown",
               "description": "API documentation and guides"
             }
           ],
           "tools": [
             {
               "name": "file_operations",
               "track": "mcp/session-uuid-456/tools/file_operations",
               "description": "File system operations"
             }
           ],
           "prompts": [
             {
               "name": "code_review",
               "track": "mcp/session-uuid-456/prompts/code_review",
               "description": "Code review prompt templates"
             }
           ]
         },
         "session_expires": "2025-06-18T12:00:00Z",
         "mcp_initialize_response": {



  Jennings, et al.          Expires 23 April 2026                [Page 21]


  Internet-Draft                MCP over MOQT                 October 2025


           "protocolVersion": "2025-06-18",
           "capabilities": {
             "resources": { "subscribe": true, "listChanged": true },
             "tools": { "progress": true },
             "prompts": { "listChanged": true },
             "elicitation": {}
           },
           "serverInfo": {
             "name": "ExampleServer",
             "version": "2.0.0"
           }
         }
       }
     }

  3.2.5.  Session Establishment Flow

     After receiving the discovery response, clients proceed with MCP
     session establishment using the provided session ID.  The flow
     depends on whether the RTT optimization was used:

  3.2.5.1.  Standard Discovery Flow

     1.  Track Subscription: Client subscribes to the control tracks using
         the session ID from the discovery response

     2.  MCP Initialize: Client sends the standard MCP initialize message
         on the client-to-server control track

     3.  Capability Negotiation: Server responds with its capabilities on
         the server-to-client control track

     4.  Session Active: Client begins normal MCP operations using the
         discovered tracks and session ID

  3.2.5.2.  Optimized Discovery Flow (with combined initialize)

     1.  Track Subscription: Client subscribes to the control tracks using
         the session ID from the discovery response

     2.  Session Active: Since MCP initialization was completed during
         discovery, the client can immediately begin normal MCP operations
         using the discovered tracks and negotiated capabilities

     The RTT optimization reduces the session establishment from 4 round-
     trips to 2 round-trips by combining discovery and initialization
     operations.




  Jennings, et al.          Expires 23 April 2026                [Page 22]


  Internet-Draft                MCP over MOQT                 October 2025


  3.3.  Priority Management

     MOQT's object priorities optimize MCP message delivery by considering
     the importance of different track types specified.

     The following priority assignments are RECOMMENDED, but applications
     may adjust them as needed.

     1.  Control Messages: Highest priority (1-10)

     2.  Tool Operations: High priority (20-30)

     3.  Notifications: Medium priority (40-60)

     4.  Resource Operations: Lower priority (70-90)

     5.  Logs: Lowest priority (100+)

     Priorities can also be adjusted based on:

     *  User interaction urgency (elicitation requests get higher
        priority)

     *  Tool execution criticality (error handling gets priority boost)

     *  Resource size and frequency (large resources get lower priority)

     *  Server load conditions (adaptive priority scaling)

  3.4.  Error Handling

     TODO

  4.  Relay Support

     MOQT relays enable scalable MCP deployments by providing intelligent
     aggregation, caching, and distribution capabilities that optimize
     performance for AI workflows and reduce server load across multiple
     clients.

  4.1.  Subscription Aggregation

     MOQT relays provide significant efficiency gains by aggregating
     multiple client subscriptions to the same content into single
     upstream requests.  When multiple clients subscribe to identical MCP
     resources, tools metadata, or notification streams, the relay
     consolidates these into a single subscription to the origin server,
     dramatically reducing server load and network bandwidth consumption.



  Jennings, et al.          Expires 23 April 2026                [Page 23]


  Internet-Draft                MCP over MOQT                 October 2025


  4.1.1.  Resource Subscription Aggregation

     When multiple clients subscribe to the same resource track, the relay
     maintains a single upstream subscription and fans out content to all
     interested clients:

  Client A subscribes: mcp/{session-id}/resources/documentation
  Client B subscribes: mcp/{session-id}/resources/documentation
  Client C subscribes: mcp/{session-id}/resources/documentation

  Relay behavior:
  - Single upstream subscription: mcp/{session-id}/resources/documentation
  - Fan-out to 3 downstream clients
  - Bandwidth savings: 3x reduction in server load

     The relay tracks subscription interest levels and automatically
     establishes upstream subscriptions when the first client subscribes
     to a track, and tears down the upstream subscription when the last
     client unsubscribes.

  4.1.2.  Tool Metadata Aggregation

     Tool discovery operations benefit significantly from aggregation
     since multiple clients typically need access to the same tool schemas
     and capabilities

     TODO: Add an examples

  4.2.  Content Caching for MCP and AI Workflows

  4.2.1.  Static Resources and Documentation

     Large documentation sets, API references, and knowledge bases
     represent the most cache-friendly content in MCP deployments.  These
     resources are accessed frequently across multiple AI sessions but
     change infrequently, making them ideal candidates for aggressive
     caching.

     Static resources are delivered through dedicated tracks like
     mcp/{session-id}/resources/{resource-uri} and benefit significantly
     from relay caching since multiple clients often access the same
     content.









  Jennings, et al.          Expires 23 April 2026                [Page 24]


  Internet-Draft                MCP over MOQT                 October 2025


  4.2.2.  Tool Schema and Configuration Caching

     Tool schemas, parameter definitions, and configuration metadata are
     cached aggressively since they define the stable interface contracts
     between AI applications and external services.  This metadata is
     cached with high TTL values, allowing relays to serve tool discovery
     requests without repeatedly querying the origin server.  Schema
     definitions are published as MOQT objects that remain valid until
     tools are modified or removed, making them ideal candidates for
     aggressive aching policies.  In case of modifications, new updated
     schema definitions are published with updated versioning info,

  4.2.3.  Capability Information and Session Metadata

     Server capability announcements that define supported features,
     resource types, and operational parameters negotiated during session
     establishment are cached via mcp/{session-id}/control/capabilities
     tracks as one-time objects published after MCP initialization,
     enabling relays to quickly respond to capability queries without
     server involvement.  The caching strategy uses long-term storage with
     explicit invalidation only on server restart or capability changes.

     Session metadata comprises initialization parameters, connection
     preferences, and configuration data that define session
     characteristics and relay behavior.  This metadata is distributed
     through mcp/{session-id}/control/metadata tracks as cacheable
     objects, with relay configuration parameters embedded in SERVER_SETUP
     message extensions.  The cached metadata enables consistent session
     behavior across client reconnections and provides relays with the
     information needed for optimal routing and caching decisions.

  4.2.4.  Model Context and History Caching

     For AI workflows that involve multi-turn conversations or context
     building, relays can cache conversation contexts and interaction
     histories to support session resumption and context sharing:

  4.3.  Track Name Discovery and Dynamic Updates

     MOQT relays enhance the MCP experience by providing efficient
     service-level discovery mechanisms that help clients understand
     available resources, tools, and services within established MCP
     sessions without requiring prior configuration knowledge.








  Jennings, et al.          Expires 23 April 2026                [Page 25]


  Internet-Draft                MCP over MOQT                 October 2025


  4.3.1.  Discovery Track Implementation

     Relays implement service-level discovery tracks that catalog
     available MCP services and their associated track patterns within a
     specific session:

     Track namespace: mcp/<session-id>/discovery Track name: catalog

     {
       "server_catalog": {
         "mcp/{session-id}/resources": {
           "available_tracks": [
             "documentation", "api_schemas", "examples", "templates"
           ],
           "content_types": ["text/markdown",
                  "application/json", "text/plain"],
           "update_frequency": "daily",
           "cache_recommended": true
         },
         "mcp/{session-id}/tools/": {
           "available_tracks": [
             "file_operations", "database_query", "code_analysis"
           ],
           "execution_types": ["synchronous", "asynchronous"],
           "progress_tracking": true,
           "cache_recommended": false
         },
         "mcp/{session-id}/prompts/": {
           "available_tracks": [
             "code_review", "data_analysis", "content_generation"
           ],
           "template_versions": ["1.0", "1.1", "2.0"],
           "cache_recommended": true
         }
       },
       "discovery_timestamp": "2025-06-18T10:30:00Z"
     }

  4.3.2.  Client Discovery via FETCH Operations

     Clients can efficiently discover available services by issuing FETCH
     requests to discovery tracks, receiving comprehensive information
     about available MCP capabilities








  Jennings, et al.          Expires 23 April 2026                [Page 26]


  Internet-Draft                MCP over MOQT                 October 2025


  4.3.3.  Asynchronous Updates via Subscriptions

     Beyond one-time discovery, clients can subscribe to discovery tracks
     to receive real-time updates when new services become available or
     existing services change their characteristics

     This subscription-based discovery update mechanism ensures that AI
     applications can dynamically adapt to changing service availability
     without requiring configuration changes or manual intervention.

  5.  Agent Skills and MCP Integration

     Agent Skills represent a powerful extension to the MCP ecosystem,
     providing modular capabilities that can be efficiently delivered and
     managed through MOQT's transport mechanisms.  This section describes
     how Skills integrate with MCP over MOQT.

  5.1.  Skills Architecture Overview

     Agent Skills are filesystem-based resources that extend AI
     capabilities through three progressive loading levels, along the
     following dimensions:

     *  Always loading metadata Loading (~100 tokens) provides basic skill
        identification and capabilities

     *  Dynamicaly loading instructionns when triggered (under 5k tokens)
        containing skill logic and execution parameters

     *  Resources and Code are loaded as needed for actual skill execution
        and data processing

     This progressive disclosure model aligns naturally with MOQT's
     object-based delivery system, where each loading level can be mapped
     to separate MOQT objects or tracks for optimal bandwidth utilization.

  5.2.  Skills Transport over MOQT

     Skills metadata is distributed through dedicated discovery tracks
     that enable clients to understand available capabilities without
     loading full skill implementations:

     Track namespace: mcp/<session-id>/skills Track name: catalog

     The skills catalog provides comprehensive metadata about available
     skills, their capabilities, dependencies, and loading requirements:





  Jennings, et al.          Expires 23 April 2026                [Page 27]


  Internet-Draft                MCP over MOQT                 October 2025


     {
       "available_skills": [
         {
           "skill_id": "powerpoint-processor",
           "name": "PowerPoint Processing",
           "description": "Create and modify PowerPoint presentations",
           "metadata_size": 95,
           "instructions_size": 4200,
           "resource_dependencies": ["office-templates", "style-schemas"],
           "security_level": "trusted",
           "loading_priority": "on-demand"
         },
         {
           "skill_id": "pdf-analyzer",
           "name": "PDF Analysis",
           "description": "Extract and analyze content from PDF documents",
           "metadata_size": 87,
           "instructions_size": 3800,
           "resource_dependencies": ["pdf-schemas"],
           "security_level": "sandboxed",
           "loading_priority": "preload"
         }
       ],
       "catalog_version": "1.2.0",
       "last_updated": "2025-06-18T10:30:00Z"
     }

     Skills leverage MOQT's object-based delivery for efficient
     progressive loading:

     Each skill's metadata is delivered as a single MOQT object containing
     basic capability information, version data, and loading requirements.

     Track namespace: `mcp/<session-id>/skills/<skill-id>`
     Track name: `metadata`

     When a skill is activated, its instruction set is loaded through
     dedicated objects containing execution logic, parameter schemas, and
     operational guidelines.

     Track namespace: `mcp/<session-id>/skills/<skill-id>`
     Track name: `instructions`

     Skill resources such as templates, schemas, and code modules are
     loaded on-demand through separate resource tracks, enabling fine-
     grained loading control.





  Jennings, et al.          Expires 23 April 2026                [Page 28]


  Internet-Draft                MCP over MOQT                 October 2025


     Track namespace: `mcp/<session-id>/skills/<skill-id>`
     Track name: `resources/<resource-type>`

  5.3.  Skills Composition and Workflow Integration

     Complex workflows can compose multiple skills together, with MOQT
     providing efficient coordination:

     *  Dependency Resolution: Skills declare dependencies that are
        automatically resolved through catalog metadata

     *  Execution Orchestration: Workflow engines can preload skill sets
        based on anticipated execution patterns

     *  Resource Sharing: Common skill resources are shared across
        workflow steps to minimize loading overhead

     Skills can share context and state through dedicated context tracks:

     Track namespace: mcp/<session-id>/skills/context Track name:
     <workflow-id>

     This enables sophisticated multi-step workflows where skills build
     upon each other's outputs while maintaining clean separation of
     concerns.

     MOQT relays implement sophisticated caching for skill distribution:

     *  Metadata Caching: Skill catalogs cached with high TTL for quick
        discovery

     *  Instruction Caching: Frequently used skills cached at edge
        locations

     *  Resource Deduplication: Common skill resources shared across
        multiple skills

     *  Version Management: Skill updates distributed efficiently through
        version-aware object delivery

     AI applications can implement predictive skill loading based on user
     patterns and workflow analysis, using MOQT's subscription management
     to preload likely-needed skills while avoiding bandwidth waste.








  Jennings, et al.          Expires 23 April 2026                [Page 29]


  Internet-Draft                MCP over MOQT                 October 2025


  6.  Shared Context Between One MCP Client and Multiple MCP Servers

     When a single MCP client connects to multiple MCP servers
     simultaneously, shared context management becomes critical for
     maintaining consistency, efficiency, and proper resource allocation
     across all active sessions.  This section describes the mechanisms
     and considerations for managing shared context in multi-server MCP
     deployments over MOQT.

  6.1.  Context Sharing Architecture

     In a shared context scenario, the MCP client acts as a central
     coordinator that maintains relationships with multiple MCP servers,
     each providing different capabilities, resources, or specialized
     services.  The client must manage session state, resource
     subscriptions, and context information across all servers while
     ensuring proper isolation and security boundaries.

  6.1.1.  Session Isolation and Coordination

     Each MCP server connection maintains its own unique session ID and
     track namespace to ensure proper isolation:

     Server A: mcp/session-a-uuid/resources/documentation
     Server B: mcp/session-b-uuid/tools/code_analysis
     Server C: mcp/session-c-uuid/prompts/review_templates

     The client coordinates these separate sessions while maintaining a
     unified view of available capabilities across all connected servers.

  6.2.  Context Synchronization Mechanisms

  6.2.1.  Resource Context Sharing

     When multiple servers provide related resources, the client can
     implement context synchronization by subscribing to relevant resource
     tracks from multiple servers and maintaining a unified context state.

  6.2.2.  Tool Execution Context

     Tool executions across multiple servers may require shared context to
     maintain workflow consistency.  Tracking tool execution state across
     all severs help ensure proper sequencing of multi-server workflows.
     Similarly results from tools on one server can be automatically
     passed as parameters to tools on other servers, for example.

  6.3.  Context Synchronization Benefits




  Jennings, et al.          Expires 23 April 2026                [Page 30]


  Internet-Draft                MCP over MOQT                 October 2025


  6.3.1.  Shared Subscription Management

     The client optimizes network usage by implementing intelligent
     subscription management across multiple servers:

     *  When multiple servers offer similar resources, the client can
        subscribe to the most appropriate source based on performance,
        recency, or quality metrics

     *  Resource requests can be distributed across servers based on
        current load, response time, or geographic proximity

     *  If one server becomes unavailable, the client can seamlessly
        redirect subscriptions to alternative servers providing similar
        capabilities

  6.3.2.  Context Caching and Reuse

     The client implements sophisticated caching strategies that work
     across all connected servers:

     *  Context information cached from one server can be reused when
        working with other servers, where appropriate.

     *  The client tracks resource versions across all servers to ensure
        cache consistency

     *  Only changed context elements are synchronized across servers to
        minimize bandwidth usage

  7.  Security Considerations

     TODO

  8.  IANA Considerations

     TODO

  9.  Examples

  10.  References

  10.1.  Normative References

     [MCP]      Anthropic, "Model Context Protocol Specification", 18 June
                2025, <https://modelcontextprotocol.io/
                specification/2025-06-18>.




  Jennings, et al.          Expires 23 April 2026                [Page 31]


  Internet-Draft                MCP over MOQT                 October 2025


     [MOQT]     Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell,
                "Media over QUIC Transport", 23 June 2025,
                <https://www.ietf.org/archive/id/draft-ietf-moq-transport-
                13>.

     [QUIC]     Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
                and Secure Transport", May 2021,
                <https://www.rfc-editor.org/rfc/rfc9000.html>.

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

  10.2.  Informative References

     [WebTransport]
                Vasiliev, V., "The WebTransport Protocol Framework", June
                2023, <https://www.rfc-editor.org/rfc/rfc9297.html>.

  Appendix A.  Acknowledgments

     TODO

  Authors' Addresses

     Cullen Jennings
     Cisco Systems
     Email: fluffy@cisco.com


     Ian Swett
     Google
     Email: ianswett@google.com


     Jonathan Rosenberg
     Five9
     Email: jdrosen@jdrosen.net


     Suhas Nandakumar
     Cisco Systems
     Email: snandaku@cisco.com



  Jennings, et al.          Expires 23 April 2026                [Page 32]


name: draft-zw-opsawg-mcp-network-mgmt
rev: 00
title: Model Context Protocol (MCP) Extensions for Network Equipment Management
time: 2025-11-02T12:10:18Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T12:10:18Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.115200+00:00
source: ietf
abstract:
[cell repeats an earlier one in this file: 438 characters]

full_text:
  Network Working Group                                            G. Zeng
  Internet-Draft                                                    J. Mao
  Intended status: Standards Track                                  B. Liu
  Expires: 6 May 2026                                             X. Shang
                                                                    Q. Gao
                                                                     Z. Li
                                                                     Q. Wu
                                                                    Huawei
                                                           2 November 2025


  Model Context Protocol (MCP) Extensions for Network Equipment Management
                    draft-zw-opsawg-mcp-network-mgmt-00

  Abstract

     The Model Context Protocol (MCP) provides a JSON-RPC 2.0 framework
     for interaction between AI applications and external context sources.
     This document specifies minimal extensions that allow network
     equipment (routers, switches, etc.) to act as MCP servers while
     controllers act as MCP clients.  New capability tokens, tools,
     resources, prompts, and error codes are defined without breaking
     existing MCP implementations.

  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.






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


  Internet-Draft                   MCP-NET                   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Capability Advertisement  . . . . . . . . . . . . . . . . . .   3
       3.1.  Rationale for Each Field  . . . . . . . . . . . . . . . .   4
     4.  Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.  Resources . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       5.1.  Standard URI Templates and MIME Types . . . . . . . . . .   5
       5.2.  Subscription and Pagination . . . . . . . . . . . . . . .   7
       5.3.  Read-Write Resources (Optional) . . . . . . . . . . . . .   7
       5.4.  Per-Resource Metadata . . . . . . . . . . . . . . . . . .   8
     6.  Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       6.1.  Standard Prompt Templates . . . . . . . . . . . . . . . .   8
       6.2.  Example: Ping-Failure Diagnosis Flow  . . . . . . . . . .   9
       6.3.  Prompt Metadata and Completion  . . . . . . . . . . . . .   9
       6.4.  Streaming and Human-in-the-Loop . . . . . . . . . . . . .  10
     7.  Error Codes . . . . . . . . . . . . . . . . . . . . . . . . .  10
       7.1.  Error Code Table  . . . . . . . . . . . . . . . . . . . .  11
       7.2.  Example Error Response  . . . . . . . . . . . . . . . . .  12
       7.3.  IANA Registration . . . . . . . . . . . . . . . . . . . .  13
     8.  Complete Interaction Example (Controller → Router)  . . . . .  13
       8.1.  Transport and Initialize  . . . . . . . . . . . . . . . .  13
       8.2.  Read Resource (Interface Status)  . . . . . . . . . . . .  14
       8.3.  Prompt Diagnosis (Ping Failure) . . . . . . . . . . . . .  14
       8.4.  YANG Edit + Confirmed Commit  . . . . . . . . . . . . . .  15
       8.5.  Event Stream (Syslog) . . . . . . . . . . . . . . . . . .  16
       8.6.  Graceful Shutdown . . . . . . . . . . . . . . . . . . . .  16
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
       10.1.  MCP Capability Tokens Registry . . . . . . . . . . . . .  17
       10.2.  JSON-RPC Error Codes Registry  . . . . . . . . . . . . .  17
     11. Normative References  . . . . . . . . . . . . . . . . . . . .  17
     12. Informative References  . . . . . . . . . . . . . . . . . . .  17
     Appendix A.  JSON Schema Examples . . . . . . . . . . . . . . . .  17
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18






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


  Internet-Draft                   MCP-NET                   November 2025


  1.  Introduction

     Network controllers today need to speak CLI, YANG/NETCONF, SNMP,
     gNMI, and vendor-private APIs.  Implementing a separate adapter for
     each protocol is expensive and error-prone.

     The Model Context Protocol (MCP) already defines a JSON-RPC 2.0 based
     framing, capability negotiation, and extensible tool/resource model.
     By adding a small set of network-specific capability flags and tool
     names, a device can expose its CLI, YANG datastores, and event
     streams through the same MCP channel that AI applications use for
     retrieving context.

     This document specifies those extensions.  All new elements live in
     their own capability namespace and can be ignored by generic MCP
     clients, preserving backward compatibility.

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

     MCP Model Context Protocol

     Server MCP server running on the network device

     Client MCP client running on the controller

     Datastore Conventional YANG datastore (running, candidate,
     operational)

  3.  Capability Advertisement

     Servers that implement this specification MUST include the following
     object inside serverCapabilities in the initialize response:

     "network": {
       "yangModules": ["ietf-interfaces", "openconfig-interfaces"],
       "cliDialect": "huawei-vrp",
       "configDatastore": ["running", "candidate", "operational"],
       "notificationStream": ["syslog", "netconf-stream", "snmp-trap"],
       "maxBulkEdit": 1000,
       "supportsRollback": true,
       "rollbackTimeout": 300
     }



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


  Internet-Draft                   MCP-NET                   November 2025


                                    Figure 1

  3.1.  Rationale for Each Field

     yangModules: Lists YANG modules the server can serve.  Clients use
     this to decide whether to invoke network.yang.* tools or fall back to
     CLI.

     cliDialect: Identifies CLI syntax (cisco-iosxr, huawei-vrp, etc.).
     Controllers can adjust prompt regex and command sequences
     accordingly.

     configDatastore: Bit-mask hint—running = editable live config;
     candidate = two-phase commit; operational = read-only state DB.
     Avoids unnecessary NETCONF hello round-trips.

     notificationStream: Tells the client which async event streams the
     server can translate into MCP notifications.  Client can subscribe
     only to available types.

     maxBulkEdit: Device-level limit to avoid oversized edit-config
     requests.  Controllers can chunk large changes.

     supportsRollback / rollbackTimeout: Boolean plus numeric seconds.
     Lets client know a confirmed-commit can be rolled back automatically
     if not confirmed within the window.

  4.  Tools

     Seven new tool names are defined.  All reuse the standard MCP tools/
     call request and MUST be listed by tools/list.




















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


  Internet-Draft                   MCP-NET                   November 2025


       +=======================+=======================================+
       | Name                  | Description                           |
       +=======================+=======================================+
       | network.cli.exec      | Execute operational CLI show commands |
       +-----------------------+---------------------------------------+
       | network.cli.configure | Enter config mode and send commands   |
       +-----------------------+---------------------------------------+
       | network.yang.get      | Retrieve YANG data node               |
       +-----------------------+---------------------------------------+
       | network.yang.edit     | Edit candidate datastore              |
       +-----------------------+---------------------------------------+
       | network.commit        | Commit candidate to running           |
       +-----------------------+---------------------------------------+
       | network.rollback      | Rollback to previous commit           |
       +-----------------------+---------------------------------------+
       | network.file.pull     | Backup config file                    |
       +-----------------------+---------------------------------------+
       | network.file.push     | Restore config file                   |
       +-----------------------+---------------------------------------+

                                    Table 1

     Arguments are described by JSON Schema inside tool metadata, so SDKs
     can auto-generate bindings.  If a device only supports CLI, it
     advertises network.yang.* tools with available=false; controllers
     automatically downgrade.

  5.  Resources

     Network equipment exposes configuration, operational and file data as
     MCP resources under the URI scheme network:///.  All resources
     described below are read-only unless explicitly marked "read-write".

     Servers MUST support resources/read and SHOULD support resources/
     subscribe for streaming resources.  Large responses MAY be paginated
     using the standard MCP nextCursor mechanism.

  5.1.  Standard URI Templates and MIME Types

     +================================+============+======+==============+
     |URI Template                    |MIME Type   |Access|Description   |
     +================================+============+======+==============+
     |network:///interface/{name}     |application/|read- |Single        |
     |                                |yang-       |only  |interface     |
     |                                |data+json   |      |YANG node     |
     |                                |            |      |(OpenConfig   |
     |                                |            |      |or IETF)      |
     +--------------------------------+------------+------+--------------+



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


  Internet-Draft                   MCP-NET                   November 2025


     |network:///interfaces           |application/|read- |Full          |
     |                                |yang-       |only  |interface     |
     |                                |data+json   |      |list;         |
     |                                |            |      |supports      |
     |                                |            |      |cursor        |
     |                                |            |      |pagination    |
     +--------------------------------+------------+------+--------------+
     |network:///routing/ipv4/route-  |application/|read- |IPv4 RIB      |
     |table                           |yang-       |only  |(operational  |
     |                                |data+json   |      |datastore)    |
     +--------------------------------+------------+------+--------------+
     |network:///routing/ipv6/route-  |application/|read- |IPv6 RIB      |
     |table                           |yang-       |only  |(operational  |
     |                                |data+json   |      |datastore)    |
     +--------------------------------+------------+------+--------------+
     |network:///system/cpu-          |application/|read- |CPU           |
     |utilization                     |json        |only  |percentage;   |
     |                                |            |      |updated every |
     |                                |            |      |30 s          |
     +--------------------------------+------------+------+--------------+
     |network:///system/memory-summary|application/|read- |Memory usage  |
     |                                |json        |only  |summary       |
     +--------------------------------+------------+------+--------------+
     |network:///log/syslog/          |text/plain; |read- |Most recent   |
     |last{count}                     |charset=utf-|only  |syslog lines  |
     |                                |8           |      |(max 10000)   |
     +--------------------------------+------------+------+--------------+
     |network:///file/running-config  |text/plain  |read- |Running       |
     |                                |            |only  |configuration |
     |                                |            |      |text          |
     +--------------------------------+------------+------+--------------+
     |network:///file/startup-config  |text/plain  |read- |Startup       |
     |                                |            |only  |configuration |
     |                                |            |      |text          |
     +--------------------------------+------------+------+--------------+
     |network:///file/{slot}/crashinfo|application/|read- |Crash         |
     |                                |json        |only  |information   |
     |                                |            |      |file (JSON    |
     |                                |            |      |array)        |
     +--------------------------------+------------+------+--------------+

                                    Table 2









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


  Internet-Draft                   MCP-NET                   November 2025


  5.2.  Subscription and Pagination

     Resources that change over time (CPU, memory, syslog, interface
     counters) SHOULD implement resources/subscribe.  The server sends
     unsolicited resources/updated notifications when the underlying data
     changes.

     For large lists (e.g., full IPv4 RIB) the server MAY insert
     nextCursor in the response:

     {
       "jsonrpc": "2.0",
       "id": 4,
       "result": {
         "contents": [
           {
             "uri": "network:///routing/ipv4/route-table",
             "mimeType": "application/yang-data+json",
             "data": { "ietf-routing:routes": [ … 1000 items … ] }
           }
         ],
         "nextCursor": "eyJzb3J0LWtleSI6IjEwLjAuMC4xLzI0In0="
       }
     }

     The client continues with:

     {
       "jsonrpc": "2.0",
       "id": 5,
       "method": "resources/read",
       "params": {
         "uri": "network:///routing/ipv4/route-table",
         "cursor": "eyJzb3J0LWtleSI6IjEwLjAuMC4xLzI0In0="
       }
     }

     until nextCursor is absent.

  5.3.  Read-Write Resources (Optional)

     If the device supports whole-config replace, the following URIs MAY
     be advertised with readOnly: false:

     *  network:///file/candidate-config (text/plain)

     *  network:///file/startup-config (text/plain)




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


  Internet-Draft                   MCP-NET                   November 2025


     Writing is done via the standard MCP resources/write method; the
     server MUST validate syntax before committing to candidate/running.

  5.4.  Per-Resource Metadata

     Each resource descriptor MAY include a _meta object (MCP reserved) to
     carry unit, precision, or hardware-specific attributes, e.g.:

     "_meta": {
       "unit": "percent",
       "precision": 0.1,
       "hardware-slot": "1/0"
     }

  6.  Prompts

     Interactive assistants (e.g., CLI copilot, chat-bot) MAY expose
     prompt templates whose names start with network..  Templates are
     listed by prompts/list and executed via prompts/get; both reuse the
     standard MCP prompt meta-data and JSON Schema for arguments.

     Each entry below includes:

     *  template name (prompts/list)

     *  one-line description

     *  input JSON Schema

     *  expected tool calls / steps

     *  return MIME type (text/markdown by default)

  6.1.  Standard Prompt Templates

     +================================+=============+===================+
     | Template Name                  |Description  |Input Schema       |
     +================================+=============+===================+
     | network.troubleshoot.ping-fail |Step-by-step |{src: string, dst: |
     |                                |ping failure |string, vrf?:      |
     |                                |diagnosis    |string}            |
     +--------------------------------+-------------+-------------------+
     | network.config.add-vlan        |Interactive  |{vlan_id: uint16,  |
     |                                |VLAN creation|name: string,      |
     |                                |wizard       |ports?: string[]}  |
     +--------------------------------+-------------+-------------------+
     | network.security.audit         |Generate and |{profile:          |
     |                                |run security |"basic"|"detailed"}|



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


  Internet-Draft                   MCP-NET                   November 2025


     |                                |compliance   |                   |
     |                                |checks       |                   |
     +--------------------------------+-------------+-------------------+

                                   Table 3

  6.2.  Example: Ping-Failure Diagnosis Flow

     The client calls prompts/get:

     {
       "jsonrpc": "2.0",
       "id": 10,
       "method": "prompts/get",
       "params": {
         "name": "network.troubleshoot.ping-fail",
         "arguments": {
           "src": "192.168.1.1",
           "dst": "10.0.0.5",
           "vrf": "mgmt"
         }
       }
     }

     Server returns a markdown prompt that embeds tool calls:

     ## Ping failure diagnosis: 192.168.1.1 → 10.0.0.5 (VRF mgmt)

     1. Check local ARP entry:
        `network.cli.exec {"cmd": "show ip arp vrf mgmt 10.0.0.5"}`

     2. Verify outbound interface status:
        `network.yang.get {"path": "/openconfig-interfaces:interfaces/interface[name='Vlan100']", "datastore": "operational"}`

     3. Run extended ping:
        `network.cli.exec {"cmd": "ping vrf mgmt 10.0.0.5 source 192.168.1.1 repeat 5"}`

     ... (interactive steps continue) ...

     The client MAY stream the markdown to the user and **inline-execute**
     each tool call, then feed results back into the same prompt context
     (follow-up prompts/get with previousContextId) until the template
     outputs "Diagnosis complete".

  6.3.  Prompt Metadata and Completion

     Prompt descriptors returned by prompts/list MAY include:




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


  Internet-Draft                   MCP-NET                   November 2025


     {
       "name": "network.config.add-vlan",
       "description": "Interactive VLAN creation wizard",
       "arguments": [
         {
           "name": "vlan_id",
           "description": "IEEE 802.1Q VLAN ID",
           "type": "integer",
           "minimum": 1,
           "maximum": 4094
         },
         {
           "name": "name",
           "description": "VLAN name (no spaces)",
           "type": "string",
           "pattern": "^[A-Za-z0-9-_]+$"
         },
         {
           "name": "ports",
           "description": "List of interface names to add to VLAN",
           "type": "array",
           "items": { "type": "string" }
         }
       ],
       "required": ["vlan_id", "name"]
     }

     Controllers can therefore auto-generate UI forms or CLI wizards
     without hard-coding any vendor logic.

  6.4.  Streaming and Human-in-the-Loop

     Templates MAY set "stream": true in their meta-data.  In this mode
     the server returns a prompts/stream handle and pushes incremental
     markdown + tool calls, allowing step-by-step confirmation by the
     user.

     When the template issues a network.commit step it MUST include a
     confirmation prompt; the client SHALL wait for explicit user approval
     before invoking the commit tool.

  7.  Error Codes

     This document registers six new JSON-RPC application-specific error
     codes in the range -32081 to -32086.  Servers that implement optional
     features MAY return additional codes -32087 to -32090 defined below.
     All codes point to this document as reference.




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


  Internet-Draft                   MCP-NET                   November 2025


  7.1.  Error Code Table

     +======+================================+===========+===============+
     |  Code| Message                        |Typical    | Recommended   |
     |      |                                |Scenario   | Recovery      |
     +======+================================+===========+===============+
     |-32081| Network.Timeout                |CLI or     | Retry with    |
     |      |                                |NETCONF    | shorter       |
     |      |                                |RPC        | command or    |
     |      |                                |exceeded   | increase      |
     |      |                                |device     | timeout       |
     |      |                                |timeout    |               |
     +------+--------------------------------+-----------+---------------+
     |-32082| Network.Unreachable            |Transport  | Check IP      |
     |      |                                |session    | reachability, |
     |      |                                |(SSH/TLS)  | credentials,  |
     |      |                                |down       | routing       |
     +------+--------------------------------+-----------+---------------+
     |-32083| Network.AccessDenied           |User role  | Escalate role |
     |      |                                |lacks      | or use lower- |
     |      |                                |permission | privilege     |
     |      |                                |for        | account       |
     |      |                                |command/   |               |
     |      |                                |path       |               |
     +------+--------------------------------+-----------+---------------+
     |-32084| Network.ConfigIncompatible     |Command/   | Fall back to  |
     |      |                                |YANG node  | alternate     |
     |      |                                |not        | model or CLI  |
     |      |                                |supported  | dialect       |
     |      |                                |on this    |               |
     |      |                                |platform   |               |
     +------+--------------------------------+-----------+---------------+
     |-32085| Network.RollbackFailed         |Confirmed- | Manual        |
     |      |                                |commit     | intervention  |
     |      |                                |rollback   | required;     |
     |      |                                |could not  | check logs    |
     |      |                                |be applied |               |
     +------+--------------------------------+-----------+---------------+
     |-32086| Network.ConfirmedCommitTimeout |Confirmed  | Re-apply      |
     |      |                                |commit     | change with   |
     |      |                                |window     | longer timer  |
     |      |                                |expired;   | or fix root   |
     |      |                                |config     | cause         |
     |      |                                |auto-      |               |
     |      |                                |rolled     |               |
     |      |                                |back       |               |
     +------+--------------------------------+-----------+---------------+
     |-32087| Network.RollbackNotSupported   |Device     | Skip rollback |



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


  Internet-Draft                   MCP-NET                   November 2025


     |      |                                |does not   | step or use   |
     |      |                                |support    | file-based    |
     |      |                                |rollback   | restore       |
     |      |                                |operation  |               |
     +------+--------------------------------+-----------+---------------+
     |-32088| Network.YangSyntaxError        |YANG       | Fix offending |
     |      |                                |payload    | node and re-  |
     |      |                                |failed     | submit        |
     |      |                                |server-    |               |
     |      |                                |side       |               |
     |      |                                |validation |               |
     +------+--------------------------------+-----------+---------------+
     |-32089| Network.HardwareFailure        |Hardware   | Reduce scale  |
     |      |                                |resource   | or upgrade    |
     |      |                                |exhausted  | hardware      |
     |      |                                |(TCAM,     |               |
     |      |                                |memory)    |               |
     +------+--------------------------------+-----------+---------------+
     |-32090| Network.SnmpFailure            |SNMP SET   | Map error-    |
     |      |                                |returned   | status to     |
     |      |                                |error-     | text and      |
     |      |                                |status ≠   | retry with    |
     |      |                                |noError    | correct value |
     +------+--------------------------------+-----------+---------------+

                                    Table 4

  7.2.  Example Error Response

     A device that rejects a VLAN because the ID is out of range would
     return:

     {
       "jsonrpc": "2.0",
       "id": 12,
       "error": {
         "code": -32084,
         "message": "Network.ConfigIncompatible",
         "data": {
           "detail": "VLAN 4095 > maximum 4094",
           "path": "/openconfig-vlan:vlans/vlan/config/vlan-id",
           "retryPossible": false
         }
       }
     }






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


  Internet-Draft                   MCP-NET                   November 2025


     The data object is optional but SHOULD contain detail (human-
     readable), path (affected YANG path), and retryPossible boolean to
     help controllers decide whether to retry automatically.

  7.3.  IANA Registration

     This document requests IANA to register the following error codes in
     the "JSON-RPC Application-Specific Error Codes" registry:

     *  -32081 to -32086 (mandatory set)

     *  -32087 to -32090 (optional set)

     All codes reference this document and are reserved for network
     equipment implementing MCP.

  8.  Complete Interaction Example (Controller → Router)

     This example walks through a full MCP session between a controller
     (client) and a router (server).  Transport is TLS-over-TCP; frames
     are sent as length-prefixed JSON-RPC 2.0 objects per MCP spec.

  8.1.  Transport and Initialize

     Controller opens TCP 443 and performs TLS handshake with ALPN
     protocol mcp.  Then sends:

     -> {"jsonrpc":"2.0","id":1,"method":"initialize","params":{
          "protocolVersion":"2025-06-18",
          "capabilities":{
            "prompts":{"listChanged":true},
            "resources":{"subscribe":true},
            "tools":{"listChanged":true}
          },
          "clientInfo":{"name":"ACME-NetCtrl","version":"4.7.0"}
        }}

     Router replies:













  Zeng, et al.               Expires 6 May 2026                  [Page 13]


  Internet-Draft                   MCP-NET                   November 2025


     <- {"jsonrpc":"2.0","id":1,"result":{
          "protocolVersion":"2025-06-18",
          "capabilities":{
            "prompts":{"listChanged":false},
            "resources":{"subscribe":true},
            "tools":{"listChanged":false},
            "network":{
              "yangModules":["ietf-interfaces","openconfig-interfaces"],
              "cliDialect":"huawei-vrp",
              "configDatastore":["running","candidate","operational"],
              "notificationStream":["syslog","netconf-stream"],
              "maxBulkEdit":1000,
              "supportsRollback":true,
              "rollbackTimeout":300
            }
          },
          "serverInfo":{"name":"IOS-XR-MCP","version":"7.5.3"}
        }}

  8.2.  Read Resource (Interface Status)

     Controller fetches operational data:

     -> {"jsonrpc":"2.0","id":2,"method":"resources/read","params":{
          "uri":"network:///interface/TenGigE0/0/0/0"}}
     <- {"jsonrpc":"2.0","id":2,"result":{
          "contents":[{
            "uri":"network:///interface/TenGigE0/0/0/0",
            "mimeType":"application/yang-data+json",
            "data":{
              "openconfig-interfaces:interface":{
                "name":"TenGigE0/0/0/0",
                "state":{"admin-status":"UP","oper-status":"DOWN"}
              }
            }
          }]
        }}

  8.3.  Prompt Diagnosis (Ping Failure)

     Controller invokes the standardized prompt:










  Zeng, et al.               Expires 6 May 2026                  [Page 14]


  Internet-Draft                   MCP-NET                   November 2025


     -> {"jsonrpc":"2.0","id":3,"method":"prompts/get","params":{
          "name":"network.troubleshoot.ping-fail",
          "arguments":{"src":"192.168.1.1","dst":"10.0.0.5","vrf":"mgmt"}}}
     <- {"jsonrpc":"2.0","id":3,"result":{
          "description":"Step-by-step ping failure diagnosis",
          "messages":[{
            "role":"assistant",
            "content":"## Ping failure: 192.168.1.1 → 10.0.0.5 (VRF mgmt)\n\n1. Check local ARP:\n   `network.cli.exec {\"cmd\":\"show ip arp vrf mgmt 10.0.0.5\"}`"
          }],
          "_meta":{"toolCalls":[{"tool":"network.cli.exec","arguments":{"cmd":"show ip arp vrf mgmt 10.0.0.5"}}]}
        }}

     Client executes the embedded tool and sends follow-up:

     -> {"jsonrpc":"2.0","id":4,"method":"tools/call","params":{
          "name":"network.cli.exec","arguments":{"cmd":"show ip arp vrf mgmt 10.0.0.5"}}}
     <- {"jsonrpc":"2.0","id":4,"result":{"stdout":"10.0.0.5  00:50:56:ab:cd:ef  Vlan100"}}

     Prompt continues until root cause is found and printed to user.

  8.4.  YANG Edit + Confirmed Commit

     Controller adds a loopback interface:

     -> {"jsonrpc":"2.0","id":5,"method":"tools/call","params":{
          "name":"network.yang.edit","arguments":{
            "target":"candidate",
            "edit":[{
              "path":"/openconfig-interfaces:interfaces/interface[name='Loopback100']",
              "value":{
                "config":{"name":"Loopback100","type":"iana-if-type:softwareLoopback"},
                "subinterfaces":{"subinterface":[{"index":0,"config":{"index":0,"ipv4":{"addresses":{"address":[{"ip":"100.100.100.100","config":{"ip":"100.100.100.100","prefix-length":32}}]}}}}]}
              }
            }]
          }
        }}
     <- {"jsonrpc":"2.0","id":5,"result":{"commit-id":"2025-10-19-03-27-00"}}

     Confirmed commit with 120 s rollback window:

     -> {"jsonrpc":"2.0","id":6,"method":"tools/call","params":{
          "name":"network.commit","arguments":{"confirmed":120}}}
     <- {"jsonrpc":"2.0","id":6,"result":{"status":"committed","rollbackTimeout":120}}

     Controller verifies connectivity; if OK it sends final confirm:






  Zeng, et al.               Expires 6 May 2026                  [Page 15]


  Internet-Draft                   MCP-NET                   November 2025


     -> {"jsonrpc":"2.0","id":7,"method":"tools/call","params":{
          "name":"network.commit","arguments":{"confirm":true}}}
     <- {"jsonrpc":"2.0","id":7,"result":{"status":"confirmed"}}

  8.5.  Event Stream (Syslog)

     Controller subscribes to syslog stream:

     -> {"jsonrpc":"2.0","id":8,"method":"resources/subscribe","params":{
          "uri":"network:///log/syslog/last200"}}
     <- {"jsonrpc":"2.0","id":8,"result":{"subscriptionId":"syslog-42"}}

     Server later pushes:

     <- {"jsonrpc":"2.0","method":"resources/updated","params":{
          "subscriptionId":"syslog-42",
          "uri":"network:///log/syslog/last200",
          "contents":[{
            "mimeType":"text/plain",
            "data":"Oct 19 03:29:01.123: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback100, changed state to up\n"
          }]
        }}

  8.6.  Graceful Shutdown

     Controller unsubscribes and closes the session:

     -> {"jsonrpc":"2.0","id":9,"method":"resources/unsubscribe","params":{
          "subscriptionId":"syslog-42"}}
     <- {"jsonrpc":"2.0","id":9,"result":{}}

     -> {"jsonrpc":"2.0","id":10,"method":"close"}
     <- {"jsonrpc":"2.0","id":10,"result":{}}

     TCP connection is closed by controller.

  9.  Security Considerations

     All operations run with the privileges of the authenticated MCP
     session.  Servers MUST enforce role-based access control for
     configuration commands.  Commit confirmed SHOULD be used for
     potentially disruptive changes.  Transport security is provided by
     the underlying MCP transport (TLS for HTTP, SSH port-forward for
     stdio).  Sensitive data (passwords, SNMP communities) MUST be
     redacted in logs and MCP traces.

  10.  IANA Considerations




  Zeng, et al.               Expires 6 May 2026                  [Page 16]


  Internet-Draft                   MCP-NET                   November 2025


  10.1.  MCP Capability Tokens Registry

     IANA is requested to register the following value:

     *  Token: network

     *  Description: Network equipment extensions for MCP

     *  Reference: this document

  10.2.  JSON-RPC Error Codes Registry

     IANA is requested to register the error codes -32081 to -32086 in the
     "JSON-RPC Application-Specific Error Codes" registry, all pointing to
     this document.

  11.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, 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, May 2017,
                <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC7950]  Bjorklund, M., "The YANG 1.1 Data Modeling Language",
                RFC 7950, August 2016,
                <https://www.rfc-editor.org/rfc/rfc7950>.

     [RFC8259]  Bray, T., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259, December 2017,
                <https://www.rfc-editor.org/rfc/rfc8259>.

  12.  Informative References

     [MCP]      Anthropic, "Model Context Protocol Specification
                2025-06-18", URL https://modelcontextprotocol.io/
                specification/2025-06-18/basic, 2025.

  Appendix A.  JSON Schema Examples

     Example tool metadata snippet (pretty printed):








  Zeng, et al.               Expires 6 May 2026                  [Page 17]


  Internet-Draft                   MCP-NET                   November 2025


     {
       "name": "network.yang.get",
       "description": "Retrieve a YANG data node",
       "inputSchema": {
         "type": "object",
         "properties": {
           "path": { "type": "string" },
           "datastore": { "enum": ["running", "operational"] }
         },
         "required": ["path"]
       }
     }

  Authors' Addresses

     Zeng Guanming
     Huawei
     Email: zengguanming@huawei.com


     Jianwei Mao
     Huawei
     Email: maojianwei@huawei.com


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


     Xiaotong Shang
     Huawei
     Email: shangxiaotong@huawei.com


     Qiangzhou Gao
     Huawei
     Email: gaoqiangzhou@huawei.com


     Zhenbin Li
     Huawei
     Email: robinli314@163.com


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



  Zeng, et al.               Expires 6 May 2026                  [Page 18]


name: draft-jennings-ai-mcp-over-moq
rev: 00
title: Model Context Protocol and Agent Skills over Media over QUIC Transport
time: 2026-03-02T20:34:16Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T20:34:16Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.118822+00:00
source: ietf
abstract:
  This document defines how to use Media over QUIC Transport (MOQT) as
     the underlying transport protocol for the Model Context Protocol
     (MCP).  MCP is a protocol that enables seamless integration between
     language model applications and external data sources and tools.
     MOQT provides efficient, low-latency, publish-subscribe media
     delivery over QUIC and WebTransport.

     This specification describes the mapping of MCP messages onto MOQT
     objects and defines the procedures for establishing and maintaining
     MCP sessions over MOQT.  It covers transport of MCP's core primitives
     including resources, tools, prompts, and notifications through
     dedicated MOQT tracks with appropriate priority management and
     delivery guarantees.

     A key focus of this document is the delivery and execution of Agent
     Skills - composed instructions that extend AI capabilities beyond
     atomic tool operations.  Skills use progressive loading (metadata,
     instructions, resources) that aligns naturally with MOQT's object-
     based delivery, enabling efficient bandwidth utilization and
     aggressive caching strategies.

     The specification also describes relay support for scalable MCP
     deployments, including subscription aggregation, content caching, and
     multi-hop architectures that enable global distribution of MCP
     services with optimized performance.

full_text:
  Model Context Protocol                                       C. Jennings
  Internet-Draft                                             Cisco Systems
  Intended status: Experimental                                   I. Swett
  Expires: 3 September 2026                                         Google
                                                              J. Rosenberg
                                                                     Five9
                                                             S. Nandakumar
                                                             Cisco Systems
                                                              2 March 2026


   Model Context Protocol and Agent Skills over Media over QUIC Transport
                        draft-jennings-ai-mcp-over-moq-00

  Abstract

     This document defines how to use Media over QUIC Transport (MOQT) as
     the underlying transport protocol for the Model Context Protocol
     (MCP).  MCP is a protocol that enables seamless integration between
     language model applications and external data sources and tools.
     MOQT provides efficient, low-latency, publish-subscribe media
     delivery over QUIC and WebTransport.

     This specification describes the mapping of MCP messages onto MOQT
     objects and defines the procedures for establishing and maintaining
     MCP sessions over MOQT.  It covers transport of MCP's core primitives
     including resources, tools, prompts, and notifications through
     dedicated MOQT tracks with appropriate priority management and
     delivery guarantees.

     A key focus of this document is the delivery and execution of Agent
     Skills - composed instructions that extend AI capabilities beyond
     atomic tool operations.  Skills use progressive loading (metadata,
     instructions, resources) that aligns naturally with MOQT's object-
     based delivery, enabling efficient bandwidth utilization and
     aggressive caching strategies.

     The specification also describes relay support for scalable MCP
     deployments, including subscription aggregation, content caching, and
     multi-hop architectures that enable global distribution of MCP
     services with optimized performance.

  About This Document

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






  Jennings, et al.        Expires 3 September 2026                [Page 1]


  Internet-Draft                MCP over MOQT                   March 2026


     The latest revision of this draft can be found at
     https://example.org/mcp-moqt/.  Status information for this document
     may be found at https://datatracker.ietf.org/doc/draft-mcp-over-
     moqt/.

     Discussion of this document takes place on the Model Context Protocol
     Working Group mailing list (mailto:mcp@example.org), which is
     archived at https://example.org/mcp/.

     Source for this draft and an issue tracker can be found at
     https://github.com/example/mcp-moqt.

  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 3 September 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Protocol Overview . . . . . . . . . . . . . . . . . . . .   5



  Jennings, et al.        Expires 3 September 2026                [Page 2]


  Internet-Draft                MCP over MOQT                   March 2026


         1.2.1.  MCP Lifecycle State Chart . . . . . . . . . . . . . .   5
         1.2.2.  System Components . . . . . . . . . . . . . . . . . .   6
     2.  MOQT Tracks for MCP . . . . . . . . . . . . . . . . . . . . .   7
       2.1.  Track Types . . . . . . . . . . . . . . . . . . . . . . .   7
         2.1.1.  Control Tracks  . . . . . . . . . . . . . . . . . . .   7
         2.1.2.  Resource Tracks . . . . . . . . . . . . . . . . . . .   7
         2.1.3.  Tool Tracks . . . . . . . . . . . . . . . . . . . . .   8
         2.1.4.  Prompt Tracks . . . . . . . . . . . . . . . . . . . .   8
         2.1.5.  Notification Tracks . . . . . . . . . . . . . . . . .   9
         2.1.6.  Elicitation Tracks  . . . . . . . . . . . . . . . . .  10
         2.1.7.  Log Tracks  . . . . . . . . . . . . . . . . . . . . .  11
     3.  Protocol Operation  . . . . . . . . . . . . . . . . . . . . .  12
       3.1.  MOQT Session Establishment  . . . . . . . . . . . . . . .  12
       3.2.  Proposed Session ID Discovery . . . . . . . . . . . . . .  12
         3.2.1.  Well-Known Discovery Track  . . . . . . . . . . . . .  12
         3.2.2.  Discovery Flow  . . . . . . . . . . . . . . . . . . .  13
         3.2.3.  Discovery Request Format  . . . . . . . . . . . . . .  14
         3.2.4.  Discovery Response Format . . . . . . . . . . . . . .  16
       3.3.  Priority Management . . . . . . . . . . . . . . . . . . .  18
       3.4.  Error Handling  . . . . . . . . . . . . . . . . . . . . .  19
         3.4.1.  Transport-Level Errors  . . . . . . . . . . . . . . .  20
         3.4.2.  MCP-Level Errors  . . . . . . . . . . . . . . . . . .  20
         3.4.3.  Skills-Specific Errors  . . . . . . . . . . . . . . .  20
         3.4.4.  Error Recovery  . . . . . . . . . . . . . . . . . . .  21
     4.  Relay Support . . . . . . . . . . . . . . . . . . . . . . . .  21
       4.1.  Subscription Aggregation and Caching  . . . . . . . . . .  21
       4.2.  Capability Discovery  . . . . . . . . . . . . . . . . . .  22
         4.2.1.  Capability Catalog  . . . . . . . . . . . . . . . . .  22
         4.2.2.  Namespace-Based Discovery . . . . . . . . . . . . . .  23
         4.2.3.  Dynamic Capability Updates  . . . . . . . . . . . . .  24
         4.2.4.  Choosing a Discovery Mechanism  . . . . . . . . . . .  25
         4.2.5.  Relay Namespace Aggregation . . . . . . . . . . . . .  25
     5.  Agent Skills and MCP Integration  . . . . . . . . . . . . . .  26
       5.1.  Skills Overview . . . . . . . . . . . . . . . . . . . . .  27
       5.2.  Skills Track Structure and Data Formats . . . . . . . . .  27
       5.3.  Skills Invocation Protocol  . . . . . . . . . . . . . . .  28
         5.3.1.  Invocation Flow . . . . . . . . . . . . . . . . . . .  28
         5.3.2.  Streaming Skill Execution with Progress . . . . . . .  30
         5.3.3.  Skills Execution Request Format . . . . . . . . . . .  31
         5.3.4.  Skills Execution Response Stream  . . . . . . . . . .  32
     6.  Multi-Server Context Sharing  . . . . . . . . . . . . . . . .  33
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  34
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
     9.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  34
       9.1.  Basic Session Establishment . . . . . . . . . . . . . . .  34
       9.2.  Tool Execution Example  . . . . . . . . . . . . . . . . .  34
       9.3.  Skill Invocation Example  . . . . . . . . . . . . . . . .  35
       9.4.  Multi-Server Skill Workflow . . . . . . . . . . . . . . .  36



  Jennings, et al.        Expires 3 September 2026                [Page 3]


  Internet-Draft                MCP over MOQT                   March 2026


     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  36
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  36
       10.2.  Informative References . . . . . . . . . . . . . . . . .  36
     Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  37
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37

  1.  Introduction

     The Model Context Protocol (MCP) [MCP] enables integration between
     LLM applications and external data sources using JSON-RPC 2.0.  Media
     over QUIC Transport (MOQT) [MOQT] provides efficient publish-
     subscribe delivery over QUIC [QUIC] with CDN support.

     This document specifies MCP transport over MOQT, addressing
     limitations of existing transports:

     *  *WebSocket*: No prioritization, head-of-line blocking, no caching/
        relay

     *  *HTTP*: Request-response model conflicts with event-driven
        architecture, SSE has limited bidirectional support

     MOQT provides:

     *  *Native publish-subscribe*: MCP resources, tools, and capabilities
        map to tracks with independent lifecycle and versioning

     *  *Priority-aware delivery*: Critical operations receive appropriate
        bandwidth

     *  *Multiplexing*: QUIC prevents head-of-line blocking between
        operations

     *  *Relay infrastructure*: Caching and subscription aggregation at
        edge

     *  *Network resilience*: QUIC connection migration for mobile
        applications

  1.1.  Terminology

     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.

     This document uses terminology from [MCP] and [MOQT].



  Jennings, et al.        Expires 3 September 2026                [Page 4]


  Internet-Draft                MCP over MOQT                   March 2026


  1.2.  Protocol Overview

     MCP messages (JSON-RPC 2.0) are embedded in MOQT payloads.  Each MCP
     primitive maps to dedicated tracks: resources, tools, prompts,
     notifications, and skills.  Sessions begin with capability
     negotiation, then clients subscribe to relevant tracks for ongoing
     communication.

  1.2.1.  MCP Lifecycle State Chart

                         ┌─────────────┐
                         │ DISCONNECTED│
                         └──────┬──────┘
                                │ QUIC Connect
                                ▼
                         ┌─────────────┐
                         │ TRANSPORT   │
                         │ CONNECTED   │
                         └──────┬──────┘
                                │ MOQT Setup
                                ▼
                         ┌─────────────┐
                         │ MOQT        │
                         │ ESTABLISHED │
                         └──────┬──────┘
                                │ Track Subscribe
                                ▼
                         ┌─────────────┐
                         │ TRACKS      │
                         │ SUBSCRIBED  │
                         └──────┬──────┘
                                │ MCP Initialize
                                ▼
                         ┌─────────────┐
                         │ MCP         │
                         │ INITIALIZING│
                         └──────┬──────┘
                                │ Capabilities Exchange
                                ▼
                         ┌─────────────┐
                         │ CAPABILITIES│
                         │ NEGOTIATED  │
                         └──────┬──────┘
                                │ Discovery Complete
                                ▼
                         ┌─────────────┐
             ┌──────────▶│ MCP ACTIVE  │◀──────────┬──────────┐
             │           │             │           │          │



  Jennings, et al.        Expires 3 September 2026                [Page 5]


  Internet-Draft                MCP over MOQT                   March 2026


             │           └──┬───┬───┬──┘           │          │
             │              │   │   │              │          │
             │ Tool Result  │   │   │ Notification │          │ Resource
             │              │   │   │              │          │ Update
             ▼              │   │   ▼              │          │
      ┌─────────────┐       │   │ ┌─────────────┐  │   ┌──────┴──────┐
      │ TOOL        │       │   │ │ ELICITATION │  │   │ SKILL       │
      │ EXECUTING   │───────┘   │ │ PENDING     │  │   │ EXECUTING   │
      └─────────────┘           │ └─────────────┘  │   └─────────────┘
             │                  │       │          │          │
             │                  │       │          │          │ Skill
             │                  │       │          │          │ Complete
             └──────────────────┼───────┴──────────┴──────────┘
                                │
                                ▼
                         ┌─────────────┐
                         │ SESSION     │
                         │ TERMINATING │
                         └──────┬──────┘
                                │ Cleanup
                                ▼
                         ┌─────────────┐
                         │ DISCONNECTED│
                         └─────────────┘

  1.2.2.  System Components

     Below figure shows system components proposed in this specification.

     ┌─────────────────┐    MOQT Session    ┌─────────────────┐
     │   MCP Client    │<==================>│   MCP Server    │
     │                 │                    │                 │
     │ ┌─────────────┐ │                    │ ┌─────────────┐ │
     │ │MCP Transport│ │                    │ │MCP Transport│ │
     │ │   Adapter   │ │                    │ │   Adapter   │ │
     │ └─────────────┘ │                    │ └─────────────┘ │
     │ ┌─────────────┐ │                    │ ┌─────────────┐ │
     │ │    MOQT     │ │                    │ │    MOQT     │ │
     │ │  Endpoint   │ │                    │ │  Endpoint   │ │
     │ └─────────────┘ │                    │ └─────────────┘ │
     └─────────────────┘                    └─────────────────┘

     The MCP client-host-server architecture maps to MOQT as follows:

     *  *MCP Host*: Acts as MOQT client, managing multiple server
        connections

     *  *MCP Client*: Implemented as MCP transport adapter within the host



  Jennings, et al.        Expires 3 September 2026                [Page 6]


  Internet-Draft                MCP over MOQT                   March 2026


     *  *MCP Server*: Acts as MOQT publisher, exposing resources, tools,
        and prompts

  2.  MOQT Tracks for MCP

  2.1.  Track Types

     This section defines the track naming conventions and mappings for
     MCP operations.

  2.1.1.  Control Tracks

     Control tracks handle MCP session management using two unidirectional
     tracks for bidirectional communication.  The client-to-server track
     carries initialize requests, ping messages, capability negotiations,
     session teardown, and tool cancellations.  The server-to-client track
     carries responses, pong messages, status updates, and teardown
     confirmations.

     Track namespace:

     (mcp, <session-id>, control)

     Track name (Client-to-Server):

     (client-to-server)

     Track name (Server-to-Client):

     (server-to-client)

     Groups and objects are mapped as follows:

     Each MCP control message is encoded as a single MOQT object within a
     group.  Group IDs are assigned sequentially starting from 0,
     incrementing for each new control message.  Object IDs within each
     group are always 0 since each control message maps to exactly one
     object.  Objects contain JSON-encoded MCP control messages as defined
     in the MCP specification.

  2.1.2.  Resource Tracks

     Resource tracks map MCP resources, delivering server-published
     content and metadata that serve as the main data sources exposed by
     MCP servers to clients.

     Track namespace:




  Jennings, et al.        Expires 3 September 2026                [Page 7]


  Internet-Draft                MCP over MOQT                   March 2026


     (mcp, <session-id>, resources)

     Track name:

     (<resource-uri>)

     Groups and objects are mapped as follows:

     Each resource version is assigned a unique group ID, starting from 0
     and incrementing with each resource update.  Within each group,
     objects represent chunks or segments of the resource content.  Object
     IDs start at 0 and increment sequentially for each chunk.  Objects
     contain the actual resource data encoded according to the resource's
     declared content type (binary data, JSON, text, etc.).

  2.1.3.  Tool Tracks

     Tool tracks map MCP tool execution, facilitating tool invocation
     requests, responses, and progress updates using MOQT's FETCH
     operations.

     Track namespace:

     (mcp, <session-id>, tools)

     Track name:

     (<tool-name>)

     Groups and objects are mapped as follows:

     Each tool invocation creates a new group with a unique group ID
     assigned by the requesting client.  Within each group, object ID 0
     contains the tool request (JSON-encoded MCP tool call), subsequent
     object IDs contain tool responses and progress updates.  Objects are
     JSON-encoded according to the MCP tool execution protocol.

  2.1.4.  Prompt Tracks

     Prompt tracks map MCP prompts, distributing pre-defined templates and
     instructions that standardize common operations across the MCP
     ecosystem.

     Track namespace:

     (mcp, <session-id>, prompts)

     Track name:



  Jennings, et al.        Expires 3 September 2026                [Page 8]


  Internet-Draft                MCP over MOQT                   March 2026


     (<prompt-name>)

     Groups and objects are mapped as follows:

     Each prompt version is assigned a unique group ID starting from 0,
     incrementing with each prompt update.  Within each group, object ID 0
     contains the prompt template and metadata.  Objects contain JSON-
     encoded prompt definitions including template text, parameter
     schemas, and versioning information.

  2.1.5.  Notification Tracks

     Notification tracks map MCP notifications, providing asynchronous
     event delivery for server-sent notifications, progress updates, and
     system events.

     Track namespace:

     (mcp, <session-id>, notifications)

     Track name:

     (<category>)

     The category parameter classifies notification types to enable
     efficient subscription management and routing.  Common category
     values include:

     *  progress - Tool execution progress updates and status reports

     *  resources - Resource change notifications (listChanged, updated)

     *  prompts - Prompt template updates and availability changes

     *  system - Server status updates, connection events, error
        conditions

     *  elicitation - User input request notifications and responses

     *  tools - Tool availability changes and capability updates

     Custom categories may be defined for application-specific
     notification types following the pattern <domain>/<type> (e.g., ai/
     model_updated, workspace/file_changed).

     Groups and objects are mapped as follows:





  Jennings, et al.        Expires 3 September 2026                [Page 9]


  Internet-Draft                MCP over MOQT                   March 2026


     Each notification event creates a new group with group IDs assigned
     sequentially starting from 0.  Within each group, object ID 0
     contains the notification payload.  Objects contain JSON-encoded
     notification messages as defined in the MCP specification, including
     event type, timestamp, and payload data.

  2.1.6.  Elicitation Tracks

     Elicitation tracks map MCP user input collection, handling
     interactive flows for gathering user consent and data through pairs
     of unidirectional tracks.  The elicitation flow uses a unidirectional
     track pair to collect user input efficiently while preserving
     privacy.  Each request creates isolated track pairs, allowing
     concurrent operations.  Servers request user consent and input, while
     clients retain control to reject or modify requests.

     Track namespace:

     (mcp, <session-id>, elicitation, <request-id>)

     Track name (Server-to-Client):

     (<server-to-client>)

     Track name (Client-to-Server):

     (<client-to-server>)

     The Server-to-Client elicitation track is published by the MCP Server
     and subscribed to by the MCP Client, carrying:

     *  Elicitation request initiation

     *  Input schema definitions

     *  Validation error messages

     *  Request timeout notifications

     *  Request cancellation notices

     The Client-to-Server elicitation track is published by the MCP Client
     and subscribed to by the MCP Server, carrying:

     *  User consent responses

     *  Input data submissions




  Jennings, et al.        Expires 3 September 2026               [Page 10]


  Internet-Draft                MCP over MOQT                   March 2026


     *  Request rejection notifications

     *  Request cancellation confirmations

     Groups and objects are mapped as follows:

     Each elicitation exchange creates new groups with group IDs starting
     from 0 and incrementing for each message in the exchange.  Within
     each group, object ID 0 contains the elicitation message (request,
     response, or status update).  Objects contain JSON-encoded
     elicitation messages including input schemas, validation
     requirements, and user responses.

  2.1.7.  Log Tracks

     Log tracks map MCP logging information, providing debugging and
     monitoring capabilities by carrying diagnostic information for system
     troubleshooting and performance optimization.

     Track namespace:

     (mcp, <session-id>, logs)

     Track name:

     (<category>)

     The category parameter organizes log entries by severity level and
     source component to enable selective monitoring and efficient log
     processing.  Standard category values include:

     *  error - Error conditions, exceptions, and critical failures

     *  warn - Warning messages and non-critical issues requiring
        attention

     *  info - General informational messages about system operations

     *  debug - Detailed debugging information for troubleshooting

     *  trace - Fine-grained execution tracing for performance analysis

     *  audit - Security and compliance audit trails

     *  metrics - Performance metrics and system statistics






  Jennings, et al.        Expires 3 September 2026               [Page 11]


  Internet-Draft                MCP over MOQT                   March 2026


     Component-specific categories may be defined using the pattern
     <level>/<component> (e.g., error/transport, debug/tools, info/
     resources) to provide granular filtering capabilities.

     Groups and objects are mapped as follows:

     Each log entry creates a new group with group IDs assigned
     sequentially starting from 0, ordered by log timestamp.  Within each
     group, object ID 0 contains the log entry.  Objects contain JSON-
     encoded log messages including severity level, timestamp, source
     component, and message content.

  3.  Protocol Operation

  3.1.  MOQT Session Establishment

     The session establishment process begins with establishing the
     underlying MOQT session, which can be either a direct QUIC connection
     or a WebTransport [WebTransport] session depending on the deployment
     environment.  QUIC connections provide optimal performance for
     server-to- server communication, while WebTransport enables browser-
     based clients to participate in MCP sessions.

     The MOQT handshake phase involves the exchange of CLIENT_SETUP (0x20)
     and SERVER_SETUP (0x21) messages that negotiate protocol versions,
     supported features, and operational parameters.

  3.2.  Proposed Session ID Discovery

     MCP sessions require unique identifiers to organize track namespaces
     and enable proper message routing.  This section defines a well-known
     track approach for session discovery that allows clients to
     dynamically discover available MCP services and obtain session
     identifiers through standardized FETCH operations.

  3.2.1.  Well-Known Discovery Track

     The discovery mechanism uses a well-known track namespace and name
     that all MCP servers must support.  This track serves as the entry
     point for clients to discover available MCP sessions and obtain the
     necessary session identifiers for subsequent operations.

     Track Namespace: mcp/discovery
     Track Name: sessions







  Jennings, et al.        Expires 3 September 2026               [Page 12]


  Internet-Draft                MCP over MOQT                   March 2026


     Clients initiate discovery by sending a FETCH request to this well-
     known track, providing a client-side nonce or identifier as a
     parameter.  The server responds with a JSON-encoded MOQT object
     containing server details, a newly minted session identifier, and
     information about available tracks on that server.

  3.2.2.  Discovery Flow

     The session discovery process follows this sequence:

  3.2.2.1.  Standard Discovery Flow

         Client                         Server
            │                             │
            │ FETCH mcp/discovery/sessions│
            │ (with client nonce)         │
            │────────────────────────────▶│
            │                             │
            │                             │ Generate session ID
            │                             │ Prepare track catalog
            │                             │
            │     FETCH_OK                │
            │◀────────────────────────────│
            │                             │
            │ Data stream: FETCH_HEADER   │
            │ + Object with session       │
            │ details                     │
            │◀────────────────────────────│
            │                             │
            │ Subscribe to control tracks │
            │────────────────────────────▶│
            │                             │
            │ MCP Initialize              │
            │────────────────────────────▶│
            │                             │
            │ Initialize Response         │
            │◀────────────────────────────│
            │                             │
            │ Begin MCP operations        │
            │────────────────────────────▶│

  3.2.2.2.  Optimized Discovery Flow (RTT Reduction)









  Jennings, et al.        Expires 3 September 2026               [Page 13]


  Internet-Draft                MCP over MOQT                   March 2026


         Client                         Server
            │                             │
            │ FETCH mcp/discovery/sessions│
            │ (with nonce + MCP init)     │
            │────────────────────────────▶│
            │                             │
            │                             │ Generate session ID
            │                             │ Process MCP initialize
            │                             │ Prepare track catalog
            │                             │
            │     FETCH_OK                │
            │◀────────────────────────────│
            │                             │
            │ Data stream: FETCH_HEADER   │
            │ + Object with session       │
            │ details + MCP init response │
            │◀────────────────────────────│
            │                             │
            │ Subscribe to control tracks │
            │────────────────────────────▶│
            │                             │
            │ Begin MCP operations        │
            │ (initialization complete)   │
            │────────────────────────────▶│

     The optimized flow reduces session establishment from 4 round-trips
     to 2 by combining discovery and MCP initialization into a single
     exchange.

  3.2.3.  Discovery Request Format

     Clients send FETCH requests to the well-known discovery track with a
     client-generated nonce or identifier in the payload:


















  Jennings, et al.        Expires 3 September 2026               [Page 14]


  Internet-Draft                MCP over MOQT                   March 2026


  FETCH {
    Type (i) = 0x16,
    Length (16),
    Request ID (i) = 1,
    Subscriber Priority (8) = 30,
    Group Order (8) = 0,
    Fetch Type (i) = 0x1,  // Standalone
    Track Namespace (tuple) = (... "mcp", "discovery"),
    Track Name Length (i) = 8,
    Track Name = "sessions",
    Start Location = {Group: 0, Object: 0},
    End Location = {Group: 0, Object: 1},
    Number of Parameters (i) = 1,
    Parameters = {
      "mcp_payload": {
        "jsonrpc": "2.0",
        "id": 1,
        "method": "discovery/request_session",
        "params": {
          "client_nonce": "client-nonce-abc123",
          "client_info": {
            "name": "ExampleClient",
            "version": "1.0.0"
          },
          "requested_capabilities": ["resources", "tools", "prompts", "skills"]
        }
      }
    }
  }

  3.2.3.1.  RTT Optimization with Combined Initialize

     To reduce round-trip time, clients MAY include their MCP initialize
     request within the discovery FETCH payload.  This allows the server
     to perform both session discovery and MCP initialization in a single
     exchange:















  Jennings, et al.        Expires 3 September 2026               [Page 15]


  Internet-Draft                MCP over MOQT                   March 2026


  FETCH {
    Type (i) = 0x16,
    Length (16),
    Request ID (i) = 1,
    Subscriber Priority (8) = 30,
    Group Order (8) = 0,
    Fetch Type (i) = 0x1,  // Standalone
    Track Namespace (tuple) = ("mcp", "discovery"),
    Track Name Length (i) = 8,
    Track Name = "sessions",
    Start Location = {Group: 0, Object: 0},
    End Location = {Group: 0, Object: 1},
    Number of Parameters (i) = 1,
    Parameters = {
      "mcp_payload": {
        "jsonrpc": "2.0",
        "id": 1,
        "method": "discovery/request_session_with_init",
        "params": {
          "client_nonce": "client-nonce-abc123",
          "client_info": {
            "name": "ExampleClient",
            "version": "1.0.0"
          },
          "requested_capabilities": ["resources", "tools", "prompts", "skills"],
          "mcp_initialize": {
            "protocolVersion": "2025-06-18",
            "capabilities": {
              "resources": { "subscribe": true },
              "tools": { "progress": true },
              "prompts": {},
              "elicitation": {},
              "skills": { "progressive_loading": true, "streaming": true }
            },
            "clientInfo": {
              "name": "ExampleClient",
              "version": "1.0.0"
            }
          }
        }
      }
    }
  }

  3.2.4.  Discovery Response Format

     The server responds with a JSON-encoded MOQT object containing the
     newly minted session ID and control track information:



  Jennings, et al.        Expires 3 September 2026               [Page 16]


  Internet-Draft                MCP over MOQT                   March 2026


     {
       "jsonrpc": "2.0",
       "id": 1,
       "result": {
         "session_id": "session-uuid-456",
         "server_info": {
           "name": "ExampleServer",
           "version": "2.0.0",
           "protocol_version": "2025-06-18"
         },
         "control_tracks": {
           "client_to_server":
              "mcp/session-uuid-456/control/client-to-server",
           "server_to_client":
              "mcp/session-uuid-456/control/server-to-client"
         },
         "session_namespace": "mcp/session-uuid-456",
         "session_expires": "2025-06-18T12:00:00Z"
       }
     }

  3.2.4.1.  Combined Discovery and Initialize Response

     When the client uses the RTT optimization by including MCP initialize
     in the discovery request, the server responds with both session
     discovery and MCP initialization results:

























  Jennings, et al.        Expires 3 September 2026               [Page 17]


  Internet-Draft                MCP over MOQT                   March 2026


     {
       "jsonrpc": "2.0",
       "id": 1,
       "result": {
         "session_id": "session-uuid-456",
         "server_info": {
           "name": "ExampleServer",
           "version": "2.0.0",
           "protocol_version": "2025-06-18"
         },
         "control_tracks": {
           "client_to_server":
              "mcp/session-uuid-456/control/client-to-server",
           "server_to_client":
              "mcp/session-uuid-456/control/server-to-client"
         },
         "session_namespace": "mcp/session-uuid-456",
         "session_expires": "2025-06-18T12:00:00Z",
         "mcp_initialize_response": {
           "protocolVersion": "2025-06-18",
           "capabilities": {
             "resources": { "subscribe": true, "listChanged": true },
             "tools": { "progress": true },
             "prompts": { "listChanged": true },
             "elicitation": {},
             "skills": { "progressive_loading": true, "streaming": true }
           },
           "serverInfo": {
             "name": "ExampleServer",
             "version": "2.0.0"
           }
         }
       }
     }

     After establishing a session, clients discover available capabilities
     (resources, tools, prompts, and skills) using the mechanisms
     described in Section 4.2.

     After receiving the discovery response, clients subscribe to control
     tracks and proceed with capability discovery (see Section 4.2).

  3.3.  Priority Management

     MOQT's object priorities optimize MCP message delivery by considering
     the importance of different track types specified.





  Jennings, et al.        Expires 3 September 2026               [Page 18]


  Internet-Draft                MCP over MOQT                   March 2026


     The following priority assignments are RECOMMENDED, but applications
     MAY adjust them as needed:

       +===========+========+==================+=======================+
       | Priority  | Range  | Track Type       | Example               |
       +===========+========+==================+=======================+
       | CRITICAL  | 1-5    | Session Control  | initialize, terminate |
       +-----------+--------+------------------+-----------------------+
       | HIGHEST   | 6-15   | User Elicitation | permission prompts    |
       +-----------+--------+------------------+-----------------------+
       | HIGH      | 16-30  | Skills/Tool      | /commit, git          |
       |           |        | Execution        | operations            |
       +-----------+--------+------------------+-----------------------+
       | MEDIUM-HI | 31-45  | Notifications    | resource changes      |
       +-----------+--------+------------------+-----------------------+
       | MEDIUM    | 46-60  | Skill            | prompt loading        |
       |           |        | Instructions     |                       |
       +-----------+--------+------------------+-----------------------+
       | MEDIUM-LO | 61-75  | Resources        | documentation         |
       +-----------+--------+------------------+-----------------------+
       | LOW       | 76-90  | Tool Schemas     | capability metadata   |
       +-----------+--------+------------------+-----------------------+
       | LOWEST    | 91-127 | Logs             | debug, trace          |
       +-----------+--------+------------------+-----------------------+

                                    Table 1

     Priorities can also be dynamically adjusted based on:

     *  User interaction urgency (elicitation requests get higher
        priority)

     *  Skill/tool execution criticality (error handling gets priority
        boost)

     *  Resource size and frequency (large resources get lower priority)

     *  Server load conditions (adaptive priority scaling)

     *  Active user engagement (boost skill loading when user is waiting)

  3.4.  Error Handling

     Error handling in MCP over MOQT leverages both MOQT's native error
     mechanisms and MCP's JSON-RPC error responses.






  Jennings, et al.        Expires 3 September 2026               [Page 19]


  Internet-Draft                MCP over MOQT                   March 2026


  3.4.1.  Transport-Level Errors

     MOQT provides several error handling mechanisms that apply to MCP
     operations:

     *  *SUBSCRIBE_ERROR*: Returned when a client cannot subscribe to an
        MCP track.  Common causes include invalid session IDs,
        unauthorized access, or non-existent resources.

     *  *FETCH_ERROR*: Returned when a FETCH operation fails.  For tool
        execution, this indicates the tool request could not be processed
        at the transport level.

     *  *GOAWAY*: Indicates the server is terminating the session.
        Clients SHOULD attempt to reconnect and re-establish the MCP
        session.

  3.4.2.  MCP-Level Errors

     MCP errors are returned as JSON-RPC error responses within MOQT
     objects:

     {
       "jsonrpc": "2.0",
       "id": 1,
       "error": {
         "code": -32600,
         "message": "Invalid Request",
         "data": {
           "details": "Tool 'unknown_tool' not found"
         }
       }
     }

     Standard MCP error codes apply: - -32700: Parse error - -32600:
     Invalid request - -32601: Method not found - -32602: Invalid params -
     -32603: Internal error

  3.4.3.  Skills-Specific Errors

     Skills execution may encounter additional error conditions:










  Jennings, et al.        Expires 3 September 2026               [Page 20]


  Internet-Draft                MCP over MOQT                   March 2026


      +============+===================+===============================+
      | Error Code | Description       | Recovery Action               |
      +============+===================+===============================+
      | -33001     | Skill not found   | Check registry, refresh cache |
      +------------+-------------------+-------------------------------+
      | -33002     | Required tool     | Verify tool server            |
      |            | unavailable       | connectivity                  |
      +------------+-------------------+-------------------------------+
      | -33003     | Dependency        | Check skill dependencies      |
      |            | resolution failed |                               |
      +------------+-------------------+-------------------------------+
      | -33004     | Instruction load  | Retry with higher priority    |
      |            | timeout           |                               |
      +------------+-------------------+-------------------------------+
      | -33005     | Context sharing   | Resolve context state         |
      |            | conflict          |                               |
      +------------+-------------------+-------------------------------+

                                   Table 2

  3.4.4.  Error Recovery

     Clients SHOULD implement the following recovery strategies:

     1.  *Transient errors*: Retry with exponential backoff

     2.  *Session errors*: Re-establish MCP session via discovery

     3.  *Resource errors*: Invalidate cache and re-fetch

     4.  *Skill errors*: Fall back to individual tool operations if
         possible

  4.  Relay Support

     MOQT relays enable scalable MCP deployments by providing intelligent
     aggregation, caching, and distribution capabilities that optimize
     performance for AI workflows and reduce server load across multiple
     clients.

  4.1.  Subscription Aggregation and Caching

     MOQT relays aggregate multiple client subscriptions to the same
     content into single upstream requests, reducing server load and
     bandwidth.  When clients subscribe to identical resources, tool
     metadata, or notification streams, the relay maintains one upstream
     subscription and fans out content to all clients.




  Jennings, et al.        Expires 3 September 2026               [Page 21]


  Internet-Draft                MCP over MOQT                   March 2026


     Relays also cache content aggressively:

     *  *Static resources* (documentation, API references): Cached with
        long TTLs since they change infrequently but are accessed
        frequently

     *  *Tool schemas*: Cached until explicitly invalidated, as they
        define stable interface contracts

     *  *Capability metadata*: Cached as one-time objects after session
        initialization

     *  *Skills registry and instructions*: Cached by version with push-
        based invalidation

  4.2.  Capability Discovery

     After establishing a session (Section 3.2), clients discover
     available capabilities (resources, tools, prompts, and skills) using
     two complementary mechanisms:

     1.  *Capability Catalog*: Application-level catalog with rich
         metadata

     2.  *Namespace-Based Discovery*: Protocol-level discovery using
         native MOQT messages

     Implementations MAY support either or both mechanisms depending on
     their needs.

  4.2.1.  Capability Catalog

     Servers implement capability catalog tracks that enumerate available
     MCP capabilities and their associated track patterns within a
     specific session:

     Track namespace: mcp/<session-id>/discovery Track name: catalog














  Jennings, et al.        Expires 3 September 2026               [Page 22]


  Internet-Draft                MCP over MOQT                   March 2026


     {
       "server_catalog": {
         "mcp/{session-id}/resources": {
           "available_tracks": [
             "documentation", "api_schemas", "examples", "templates"
           ],
           "content_types": ["text/markdown",
                  "application/json", "text/plain"],
           "update_frequency": "daily",
           "cache_recommended": true
         },
         "mcp/{session-id}/tools/": {
           "available_tracks": [
             "file_operations", "database_query", "code_analysis"
           ],
           "execution_types": ["synchronous", "asynchronous"],
           "progress_tracking": true,
           "cache_recommended": false
         },
         "mcp/{session-id}/prompts/": {
           "available_tracks": [
             "code_review", "data_analysis", "content_generation"
           ],
           "template_versions": ["1.0", "1.1", "2.0"],
           "cache_recommended": true
         }
       },
       "discovery_timestamp": "2025-06-18T10:30:00Z"
     }

     Clients discover available capabilities by issuing FETCH requests to
     the catalog track for initial discovery, or SUBSCRIBE for real-time
     updates when capabilities change.

  4.2.2.  Namespace-Based Discovery

     MOQT draft-16 introduces SUBSCRIBE_NAMESPACE and PUBLISH_NAMESPACE
     messages that enable protocol-level discovery of available tracks
     under specific namespace prefixes.

  4.2.2.1.  SUBSCRIBE_NAMESPACE for Track Discovery

     Clients use SUBSCRIBE_NAMESPACE to discover all available tracks
     under an MCP namespace prefix without prior knowledge of specific
     track names:






  Jennings, et al.        Expires 3 September 2026               [Page 23]


  Internet-Draft                MCP over MOQT                   March 2026


     SUBSCRIBE_NAMESPACE {
       Request ID (i) = 1,
       Track Namespace = ("mcp", "<session-id>", "resources")
     }

     The server responds with NAMESPACE messages for each available track:

  NAMESPACE {
    Request ID (i) = 1,
    Track Namespace = ("mcp", "<session-id>", "resources", "documentation")
  }

  NAMESPACE {
    Request ID (i) = 1,
    Track Namespace = ("mcp", "<session-id>", "resources", "api-schemas")
  }

  NAMESPACE_DONE {
    Request ID (i) = 1,
    Status Code (i) = 0,
    Reason Phrase = ""
  }

  4.2.2.2.  PUBLISH_NAMESPACE for Server Announcements

     MCP servers use PUBLISH_NAMESPACE to proactively announce track
     namespace availability to connected clients and relays:

     PUBLISH_NAMESPACE {
       Request ID (i) = 1,
       Track Namespace = ("mcp", "<session-id>", "tools")
     }

     Relays receiving PUBLISH_NAMESPACE forward these announcements to
     interested subscribers, enabling efficient fan-out of capability
     updates.

  4.2.3.  Dynamic Capability Updates

     Both discovery mechanisms support real-time updates when capabilities
     change during a session.

     *Capability Catalog Updates*: Clients subscribed to the capability
     catalog track receive new catalog objects when capabilities are
     added, removed, or modified.

     *Namespace Updates*: Servers publish PUBLISH_NAMESPACE announcements
     that relays forward to clients with active namespace subscriptions:



  Jennings, et al.        Expires 3 September 2026               [Page 24]


  Internet-Draft                MCP over MOQT                   March 2026


         Client                    Relay                     Server
            │                        │                         │
            │ (Existing subscription │                         │
            │  to namespace)         │                         │
            │                        │                         │
            │                        │                         │ New tool added
            │                        │                         │
            │                        │   PUBLISH_NAMESPACE     │
            │                        │ ("mcp", "sess-123",     │
            │                        │  "tools", "new-tool")   │
            │                        │◀───────────────────────│
            │                        │                         │
            │         NAMESPACE      │                         │
            │ ("mcp", "sess-123",    │                         │
            │  "tools", "new-tool")  │                         │
            │◀───────────────────────│                         │
            │                        │                         │
            │ (Client discovers new  │                         │
            │  tool availability)    │                         │

  4.2.4.  Choosing a Discovery Mechanism

           +===============================+======================+
           | Use Case                      | Recommended Approach |
           +===============================+======================+
           | Rich metadata needed (content | Capability Catalog   |
           | types, caching hints)         |                      |
           +-------------------------------+----------------------+
           | Simple track enumeration      | Namespace-Based      |
           +-------------------------------+----------------------+
           | Relay aggregation scenarios   | Namespace-Based      |
           +-------------------------------+----------------------+
           | Legacy MOQT implementations   | Capability Catalog   |
           | (pre-draft-16)                |                      |
           +-------------------------------+----------------------+
           | Minimal protocol overhead     | Namespace-Based      |
           +-------------------------------+----------------------+

                                   Table 3

  4.2.5.  Relay Namespace Aggregation

     Relays can aggregate namespace information from multiple upstream
     servers and present a unified namespace view to downstream clients:







  Jennings, et al.        Expires 3 September 2026               [Page 25]


  Internet-Draft                MCP over MOQT                   March 2026


         Client                    Relay               Server A         Server B
            │                        │                     │                │
            │ SUBSCRIBE_NAMESPACE    │                     │                │
            │ ("mcp", "unified",     │                     │                │
            │  "tools")              │                     │                │
            │───────────────────────▶│                     │                │
            │                        │                     │                │
            │                        │ SUBSCRIBE_NAMESPACE │                │
            │                        │ ("mcp", "sess-a",   │                │
            │                        │  "tools")           │                │
            │                        │────────────────────▶│                │
            │                        │                     │                │
            │                        │ SUBSCRIBE_NAMESPACE │                │
            │                        │ ("mcp", "sess-b",   │                │
            │                        │  "tools")           │                │
            │                        │───────────────────────────────────▶│
            │                        │                     │                │
            │                        │ NAMESPACE responses │                │
            │                        │ from both servers   │                │
            │                        │◀────────────────────│                │
            │                        │◀───────────────────────────────────│
            │                        │                     │                │
            │                        │ (Relay aggregates   │                │
            │                        │  and deduplicates)  │                │
            │                        │                     │                │
            │ NAMESPACE              │                     │                │
            │ (aggregated responses) │                     │                │
            │◀───────────────────────│                     │                │
            │                        │                     │                │
            │ NAMESPACE_DONE         │                     │                │
            │◀───────────────────────│                     │                │

  5.  Agent Skills and MCP Integration

     Agent Skills represent a paradigm shift in how AI capabilities are
     extended and distributed.  Unlike atomic tools that perform single
     operations, Skills provide composed instructions for complex tasks
     that may orchestrate multiple tools.  This section describes the
     comprehensive architecture for Skills delivery and execution over
     MOQT.











  Jennings, et al.        Expires 3 September 2026               [Page 26]


  Internet-Draft                MCP over MOQT                   March 2026


  5.1.  Skills Overview

     Skills and Tools serve complementary roles in MCP.  Tools provide
     atomic capabilities invoked via direct RPC calls, while Skills
     provide composed instructions for complex tasks through prompt
     expansion and orchestration.  Tools are stateless with schemas always
     available; Skills are context-aware with progressive loading
     (metadata, then instructions, then resources).

     Support for Skills is OPTIONAL.  Servers advertising the skills
     capability MUST implement the skills registry track and support FETCH
     operations for skill metadata and instructions.  Clients SHOULD cache
     skill content by version.  When Skills are not supported, clients
     fall back to direct tool operations.

     Skills use three progressive loading levels optimized for MOQT
     delivery:

     *  *Metadata* (~100 tokens): Skill identification, triggers,
        dependencies

     *  *Instructions* (<5k tokens): Full prompt text and execution logic

     *  *Resources*: Templates, schemas, and examples loaded during
        execution

  5.2.  Skills Track Structure and Data Formats

     Skills use a hierarchical track namespace under mcp/<session-
     id>/skills/:





















  Jennings, et al.        Expires 3 September 2026               [Page 27]


  Internet-Draft                MCP over MOQT                   March 2026


     +==============+===============+=================+=================+
     | Track        | Namespace     | Name            | Purpose         |
     +==============+===============+=================+=================+
     | Registry     | (mcp,         | registry        | Complete skill  |
     |              | <session-id>, |                 | catalog for     |
     |              | skills)       |                 | trigger         |
     |              |               |                 | matching        |
     +--------------+---------------+-----------------+-----------------+
     | Metadata     | (mcp,         | metadata        | Skill           |
     |              | <session-id>, |                 | identification, |
     |              | skills,       |                 | triggers,       |
     |              | <skill-id>)   |                 | dependencies    |
     +--------------+---------------+-----------------+-----------------+
     | Instructions | (mcp,         | instructions    | Full prompt     |
     |              | <session-id>, |                 | text and        |
     |              | skills,       |                 | execution logic |
     |              | <skill-id>)   |                 |                 |
     +--------------+---------------+-----------------+-----------------+
     | Execution    | (mcp,         | <invocation-id> | Bidirectional   |
     |              | <session-id>, |                 | streaming for   |
     |              | skills,       |                 | active          |
     |              | <skill-id>,   |                 | invocations     |
     |              | execution)    |                 |                 |
     +--------------+---------------+-----------------+-----------------+

                                   Table 4

     The registry track contains an array of skill entries, each
     specifying: id, name, version, description, triggers (commands and
     patterns), loading hints (token sizes, preload preferences),
     required/optional tools and permissions, and composition
     relationships (which skills can invoke each other).

     Individual metadata objects provide detailed capability information
     including content hashes for integrity verification, activation
     context requirements, tool and resource dependencies, permission
     requirements, and execution characteristics (streaming support,
     cancellation, timeouts).

     Instructions objects contain the complete prompt text with step-by-
     step execution logic, parameter schemas with types and defaults, and
     output format specifications for success and error cases.

  5.3.  Skills Invocation Protocol

  5.3.1.  Invocation Flow





  Jennings, et al.        Expires 3 September 2026               [Page 28]


  Internet-Draft                MCP over MOQT                   March 2026


         Client                    Relay                     Origin
            │                        │                         │
            │  User types: "/commit" │                         │
            │                        │                         │
            │  (Match against        │                         │
            │   cached registry)     │                         │
            │                        │                         │
            ├────────────────────────┼─────────────────────────┤
            │     PHASE 1: LOAD SKILL METADATA                 │
            ├────────────────────────┼─────────────────────────┤
            │                        │                         │
            │ FETCH                  │                         │
            │ mcp/sess/skills/       │                         │
            │   commit/metadata      │                         │
            │───────────────────────▶│                         │
            │                        │                         │
            │                        │ [CACHE HIT]             │
            │                        │                         │
            │ FETCH_OK + OBJECT      │                         │
            │ {                      │                         │
            │   skill_id: "commit",  │                         │
            │   version: "2.1.0",    │                         │
            │   requires: [          │                         │
            │     "tools/git/*"      │                         │
            │   ]                    │                         │
            │ }                      │                         │
            │◀───────────────────────│                         │
            │                        │                         │
            ├────────────────────────┼─────────────────────────┤
            │     PHASE 2: LOAD SKILL INSTRUCTIONS             │
            ├────────────────────────┼─────────────────────────┤
            │                        │                         │
            │ FETCH                  │                         │
            │ mcp/sess/skills/       │                         │
            │   commit/instructions  │                         │
            │───────────────────────▶│                         │
            │                        │                         │
            │                        │ [CACHE HIT - v2.1.0]    │
            │                        │                         │
            │ FETCH_OK + OBJECT      │                         │
            │ {                      │                         │
            │   instructions: "..."  │                         │
            │ }                      │                         │
            │◀───────────────────────│                         │
            │                        │                         │
            ├────────────────────────┼─────────────────────────┤
            │     PHASE 3: EXECUTE SKILL (TOOL CALLS)          │
            ├────────────────────────┼─────────────────────────┤



  Jennings, et al.        Expires 3 September 2026               [Page 29]


  Internet-Draft                MCP over MOQT                   March 2026


            │                        │                         │
            │  (AI processes         │                         │
            │   instructions)        │                         │
            │                        │                         │
            │ FETCH tools/git/status │                         │
            │───────────────────────▶│───────────────────────▶│
            │                        │                         │
            │ FETCH_OK + OBJECT      │                         │
            │◀───────────────────────│◀───────────────────────│
            │                        │                         │
            │ FETCH tools/git/diff   │                         │
            │───────────────────────▶│───────────────────────▶│
            │                        │                         │
            │ FETCH_OK + OBJECT      │                         │
            │◀───────────────────────│◀───────────────────────│
            │                        │                         │
            │ FETCH tools/git/commit │                         │
            │───────────────────────▶│───────────────────────▶│
            │                        │                         │
            │ FETCH_OK + OBJECT      │                         │
            │ {commit_sha: "abc123"} │                         │
            │◀───────────────────────│◀───────────────────────│
            │                        │                         │

  5.3.2.  Streaming Skill Execution with Progress


























  Jennings, et al.        Expires 3 September 2026               [Page 30]


  Internet-Draft                MCP over MOQT                   March 2026


         Client                    Relay                     Origin
            │                        │                         │
            │ SUBSCRIBE              │                         │
            │ skills/deploy/         │                         │
            │   execution/inv-xyz    │                         │
            │───────────────────────▶│ SUBSCRIBE               │
            │                        │───────────────────────▶│
            │                        │                         │
            │ SUBSCRIBE_OK           │ SUBSCRIBE_OK            │
            │◀───────────────────────│◀───────────────────────│
            │                        │                         │
            │ Publish request        │                         │
            │ {action: "invoke",     │                         │
            │  params: {env: "prod"}}│                         │
            │───────────────────────▶│───────────────────────▶│
            │                        │                         │
            │                        │ Object (progress)       │
            │                        │ {status: "started"}     │
            │                        │◀───────────────────────│
            │ Object                 │                         │
            │◀───────────────────────│                         │
            │                        │                         │
            │                        │ Object (progress)       │
            │                        │ {step: "building",      │
            │                        │  progress: 25}          │
            │                        │◀───────────────────────│
            │ Object                 │                         │
            │◀───────────────────────│                         │
            │                        │                         │
            │                        │ Object (progress)       │
            │                        │ {step: "deploying",     │
            │                        │  progress: 75}          │
            │                        │◀───────────────────────│
            │ Object                 │                         │
            │◀───────────────────────│                         │
            │                        │                         │
            │                        │ Object (complete)       │
            │                        │ {status: "completed",   │
            │                        │  result: {url: "..."}}  │
            │                        │◀───────────────────────│
            │ Object                 │                         │
            │◀───────────────────────│                         │
            │                        │                         │

  5.3.3.  Skills Execution Request Format






  Jennings, et al.        Expires 3 September 2026               [Page 31]


  Internet-Draft                MCP over MOQT                   March 2026


     {
       "jsonrpc": "2.0",
       "id": "exec-001",
       "method": "skills/invoke",
       "params": {
         "skill_id": "commit",
         "invocation_id": "inv-xyz789",
         "parameters": {
           "push": false
         },
         "context": {
           "working_directory": "/home/user/project",
           "git_state": {
             "branch": "feature/new-feature",
             "has_staged": true
           }
         },
         "options": {
           "stream_progress": true,
           "timeout_ms": 60000
         }
       }
     }

  5.3.4.  Skills Execution Response Stream

     // Object 0: Acknowledgment
     {
       "jsonrpc": "2.0",
       "id": "exec-001",
       "result": {
         "status": "accepted",
         "invocation_id": "inv-xyz789"
       }
     }

     // Object 1: Progress
     {
       "jsonrpc": "2.0",
       "method": "skills/progress",
       "params": {
         "invocation_id": "inv-xyz789",
         "step": 1,
         "total_steps": 4,
         "message": "Checking repository status...",
         "tool_call": {"tool": "git/status", "status": "in_progress"}
       }
     }



  Jennings, et al.        Expires 3 September 2026               [Page 32]


  Internet-Draft                MCP over MOQT                   March 2026


     // Object 2: Progress
     {
       "jsonrpc": "2.0",
       "method": "skills/progress",
       "params": {
         "invocation_id": "inv-xyz789",
         "step": 2,
         "message": "Analyzing changes...",
         "tool_call": {"tool": "git/diff", "status": "completed"}
       }
     }

     // Object 3: Completion
     {
       "jsonrpc": "2.0",
       "id": "exec-001",
       "result": {
         "status": "completed",
         "output": {
           "commit_sha": "abc123def456",
           "message": "Add user authentication flow",
           "files_committed": ["src/auth.ts", "src/middleware/jwt.ts"]
         }
       }
     }

  6.  Multi-Server Context Sharing

     When an MCP client connects to multiple servers simultaneously, each
     connection maintains its own session ID and track namespace for
     isolation:

     Server A: mcp/session-a-uuid/resources/documentation
     Server B: mcp/session-b-uuid/tools/code_analysis
     Server C: mcp/session-c-uuid/prompts/review_templates

     The client coordinates these sessions while presenting a unified
     capability view.  Key considerations include:

     *  *Resource synchronization*: Subscribe to related tracks across
        servers, selecting sources based on performance, recency, or
        availability

     *  *Tool execution context*: Track execution state across servers for
        proper workflow sequencing; pass results between servers as needed

     *  *Cache coordination*: Reuse cached context across servers where
        appropriate, tracking versions for consistency



  Jennings, et al.        Expires 3 September 2026               [Page 33]


  Internet-Draft                MCP over MOQT                   March 2026


  7.  Security Considerations

     TODO

  8.  IANA Considerations

     TODO

  9.  Examples

  9.1.  Basic Session Establishment

     This example shows a minimal MCP session establishment over MOQT:

    1. Client establishes QUIC connection to server
    2. Client sends CLIENT_SETUP, server responds with SERVER_SETUP
    3. Client sends FETCH to mcp/discovery/sessions with client info
    4. Server responds with session_id and available tracks
    5. Client subscribes to control tracks
    6. Client sends MCP initialize on client-to-server control track
    7. Server responds with capabilities on server-to-client control track
    8. Session is now active

  9.2.  Tool Execution Example

     Executing a file read tool:

























  Jennings, et al.        Expires 3 September 2026               [Page 34]


  Internet-Draft                MCP over MOQT                   March 2026


     Client → Server:
     FETCH mcp/{session-id}/tools/filesystem
     {
       "jsonrpc": "2.0",
       "id": 1,
       "method": "tools/call",
       "params": {
         "name": "read_file",
         "arguments": {"path": "/project/README.md"}
       }
     }

     Server → Client:
     FETCH_OK + OBJECT
     {
       "jsonrpc": "2.0",
       "id": 1,
       "result": {
         "content": [
           {"type": "text", "text": "# Project README\n..."}
         ]
       }
     }

  9.3.  Skill Invocation Example

     Invoking the /commit skill with progressive loading:

     1. User types: "/commit"

     2. Client checks cached registry, finds "commit" skill

     3. Client FETCHes skill metadata (if not cached):
        FETCH mcp/{session-id}/skills/commit/metadata
        → Returns: version, dependencies, required tools

     4. Client FETCHes skill instructions:
        FETCH mcp/{session-id}/skills/commit/instructions
        → Returns: full prompt with execution steps

     5. AI processes instructions, calls required tools:
        FETCH mcp/{session-id}/tools/git {method: "status"}
        FETCH mcp/{session-id}/tools/git {method: "diff"}
        FETCH mcp/{session-id}/tools/git {method: "commit", args: {...}}

     6. Skill completes, returns result to user





  Jennings, et al.        Expires 3 September 2026               [Page 35]


  Internet-Draft                MCP over MOQT                   March 2026


  9.4.  Multi-Server Skill Workflow

     A deployment workflow using skills from multiple servers:

     User: "/deploy to production"

     1. Load /deploy skill from Enterprise Server B
     2. /deploy instructions: "First ensure changes committed"
     3. Invoke /commit skill from Anthropic Server A
     4. /commit executes using GitHub Tools Server
     5. Return to /deploy, execute deployment tools
     6. Stream progress updates to client
     7. Return deployment result with URL

  10.  References

  10.1.  Normative References

     [MCP]      Anthropic, "Model Context Protocol Specification", 18 June
                2025, <https://modelcontextprotocol.io/
                specification/2025-06-18>.

     [MOQT]     Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell,
                "Media over QUIC Transport", 16 December 2025,
                <https://www.ietf.org/archive/id/draft-ietf-moq-transport-
                16>.

     [QUIC]     Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
                and Secure Transport", May 2021,
                <https://www.rfc-editor.org/rfc/rfc9000.html>.

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

  10.2.  Informative References

     [WebTransport]
                Vasiliev, V., "The WebTransport Protocol Framework", June
                2023, <https://www.rfc-editor.org/rfc/rfc9297.html>.






  Jennings, et al.        Expires 3 September 2026               [Page 36]


  Internet-Draft                MCP over MOQT                   March 2026


  Appendix A.  Acknowledgments

     TODO

  Authors' Addresses

     Cullen Jennings
     Cisco Systems
     Email: fluffy@cisco.com


     Ian Swett
     Google
     Email: ianswett@google.com


     Jonathan Rosenberg
     Five9
     Email: jdrosen@jdrosen.net


     Suhas Nandakumar
     Cisco Systems
     Email: snandaku@cisco.com



























  Jennings, et al.        Expires 3 September 2026               [Page 37]


name: draft-chuyi-nmrg-agentic-network-inference
rev: 00
time: 2026-03-02T12:47:15Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T12:47:15Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:04.970141+00:00
source: ietf
title:
  Agentic Network Architecture and Protocol for Supporting Agent Interconnection Communication and Multi-level Inference

abstract:
  With the advent of the era of AI large models and intelligent agents,
     more and more scenarios about agent interconnection have emerged,
     such as collaboration among multiple agents within a household,
     intelligent robots cooperating to complete pipeline tasks in
     different operations of the industrial Internet, drone groups,
     intelligent vehicle networking, etc.  These scenarios not only
     require low latency and high bandwidth, but also demand efficient
     information exchange and cross-domain coordination and scheduling
     capabilities in complex collaborative tasks.  Therefore, new
     orchestration and management technologies and frameworks are needed
     in existing networks to address this.  The interconnection of
     different agents also brings about an emergence of inference, with a
     large number of inference requests being processed from the mobile
     phone side to the cloud.  In order to improve inference efficiency,
     in a cloud-edge-end multi-layer inference architecture, large models
     and agents at different levels cooperate to complete tasks, resulting
     in a complex intelligent agent interconnection network.  Gateways and
     routers serve as forwarding entries on the network road highways,
     responsible for building communication channels for the agents spread
     throughout the network, which requiring function upgrades to support
     the continuously evolving inference service in the future.

full_text:
  Network Management Research Group                                 C. Guo
  Internet-Draft                                              China Mobile
  Intended status: Informational                                March 2026
  Expires: 3 September 2026


       Agentic Network Architecture and Protocol for Supporting Agent
          Interconnection Communication and Multi-level Inference
               draft-chuyi-nmrg-agentic-network-inference-00

  Abstract

     With the advent of the era of AI large models and intelligent agents,
     more and more scenarios about agent interconnection have emerged,
     such as collaboration among multiple agents within a household,
     intelligent robots cooperating to complete pipeline tasks in
     different operations of the industrial Internet, drone groups,
     intelligent vehicle networking, etc.  These scenarios not only
     require low latency and high bandwidth, but also demand efficient
     information exchange and cross-domain coordination and scheduling
     capabilities in complex collaborative tasks.  Therefore, new
     orchestration and management technologies and frameworks are needed
     in existing networks to address this.  The interconnection of
     different agents also brings about an emergence of inference, with a
     large number of inference requests being processed from the mobile
     phone side to the cloud.  In order to improve inference efficiency,
     in a cloud-edge-end multi-layer inference architecture, large models
     and agents at different levels cooperate to complete tasks, resulting
     in a complex intelligent agent interconnection network.  Gateways and
     routers serve as forwarding entries on the network road highways,
     responsible for building communication channels for the agents spread
     throughout the network, which requiring function upgrades to support
     the continuously evolving inference service in the future.

  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.







  Guo                     Expires 3 September 2026                [Page 1]


  Internet-Draft  Agentic Network Architecture and Protoco      March 2026


     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 2 September 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Abbreviations and Definitions . . . . . . . . . . . . . . . .   3
     3.  Use Case  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Industrial Internet . . . . . . . . . . . . . . . . . . .   4
       3.2.  Smart Home  . . . . . . . . . . . . . . . . . . . . . . .   4
       3.3.  Cloud-edge-end Collaboration Scenario of Intelligent
             Vehicle Networking  . . . . . . . . . . . . . . . . . . .   4
     4.  Definition and Functions of Agentic Gateway . . . . . . . . .   4
       4.1.  Introduction and Definition . . . . . . . . . . . . . . .   4
       4.2.  Intelligent Forwarding and Routing  . . . . . . . . . . .   5
       4.3.  Intent and Network Environment Perception . . . . . . . .   6
       4.4.  Protocol Compatibility and Conversion . . . . . . . . . .   6
       4.5.  Support Multi-level Inference . . . . . . . . . . . . . .   6
       4.6.  Information Management and Control  . . . . . . . . . . .   7
       4.7.  Equipment-level Operation and Maintenance Autonomy  . . .   7
       4.8.  Safety  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.  Architecture of Agentic Network for Multi-level Inference . .   8
       5.1.  Architecture and Functions  . . . . . . . . . . . . . . .   8
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8



  Guo                     Expires 3 September 2026                [Page 2]


  Internet-Draft  Agentic Network Architecture and Protoco      March 2026


     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
       8.1.  Informative References  . . . . . . . . . . . . . . . . .   9
       8.2.  Normative References  . . . . . . . . . . . . . . . . . .   9
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     Agentic Network refers to a network composed of ubiquitous agents,
     intelligent network elements, and network resources.  It addresses
     the issue of multi-agent collaboration across network domains,
     leveraging network capabilities to meet the interconnected
     communication and management needs of various forms of agents.  It
     connects edge communication networks and devices, completing network
     intelligence upgrades.  Toward the future, the Agentic (IP) Network
     will become a new generation of intelligent IP network, building a
     high-speed pathway for intelligent agent interconnection and serving
     as the core brain and transit station for agent interconnection and
     collaboration.

     In this background, intelligent and autonomous network routing
     management &control will enter a new stage characterized by
     "intention-driven, autonomous collaboration, and inherent security".
     With intelligent agents as the core, the routing architecture will be
     restructured, achieving a qualitative change from "passive
     adaptation" to "active prediction" and from "single-point
     optimization" to "global collaboration".

  2.  Abbreviations and Definitions

     Agentic (IP) network:  A novel network architecture composed of
        ubiquitous ubiquitous agents, intelligent and non-intelligent
        network elements, computing resources, and network link resources,
        which supports agent interconnection technologies and functions
        such as intention transfer, semantic communication, knowledge and
        context-driven mechanisms, implementing agent interconnection
        protocols, and enables efficient collaboration among multiple
        agents as well as distributed multi-level inference.

     Agentic gateway:  Agentic gateway is the intelligent network element,
        capable of autonomously perceiving information and taking
        corresponding actions.  It can perform all the functions of a
        gateway while integrating AI capabilities to execute planning,
        analysis, decision-making, and action execution for specific
        functions (such as intelligent route recommendation) or autonomous
        events.

     (To be added)




  Guo                     Expires 3 September 2026                [Page 3]


  Internet-Draft  Agentic Network Architecture and Protoco      March 2026


  3.  Use Case

     This chapter lists three typical application scenarios of agent
     interconnection, describing the capabilities and requirements of the
     agentic network and gateway needed.

  3.1.  Industrial Internet

     Industrial Internet involves collaboration among smart manufacturing
     robots.  In the production line, they cooperate to complete tasks,
     conduct multimodal data sensing, and fulfill their missions under the
     coordination and control of edge gateways.  Edge gateways aggregate
     data from various device agents, perform local preprocessing
     (filtering invalid data, extracting key features), and avoid network
     congestion caused by directly connecting massive data to the cloud.
     At the same time, they can issue some control instructions (such as
     regional collaborative control instructions to achieve device linkage
     operation).  Different agent devices within the gateway can share
     data, identify anomalies, and provide collaborative early warning and
     handling of faults.

  3.2.  Smart Home

     (To be expanded)

  3.3.  Cloud-edge-end Collaboration Scenario of Intelligent Vehicle
        Networking

     (To be expanded)

  4.  Definition and Functions of Agentic Gateway

  4.1.  Introduction and Definition

     Intelligent network elements refer to network equipment hardware that
     integrates AI technology to fulfill network functions.  Intelligent
     gateways leverage the analysis and generation capabilities of AI
     large or small models to accomplish new forwarding, control,
     management, and other functions in the context of the development in
     the AI era.  These functions include but are not limited to
     intelligent traffic identification, intelligent route recommendation,
     intelligent forwarding, user-level/service-level service
     identification, autonomous operation and maintenance, achieving
     triple perception and tuning of themselves, the network, and
     services, while autonomously allocating resources, realizing event
     self-looping, supporting emerging inference services, and enhancing
     user service experience.




  Guo                     Expires 3 September 2026                [Page 4]


  Internet-Draft  Agentic Network Architecture and Protoco      March 2026


     Each intelligent network element (NE) itself is an agent capable of
     performing all the functions of a NE.  It has evolved from passive
     execution of single rules to active perception, discovery, and
     intelligent processing.  Equipped with intelligent agent capabilities
     such as perception, planning, analysis, decision-making, and
     execution, it can do more than traditional NEs.  As a "neuron" in the
     interconnected intelligent agent network, it can participate in
     higher-level decision-making and regulation.

     Agentic gateway can support:

     *  The original gateway/router network elements were mostly passively
        responsive, executing a single rule function.  The upgraded
        network elements can automatically complete functions in a closed
        loop, leveraging the capabilities of AI models, both large and
        small, to enhance automation and intelligence levels, reducing
        manual intervention.

     *  For agent interconnection, in order to face the complex agent
        interconnection scenarios in the future, it is necessary to
        enhance network capabilities, and the analysis, generation, and
        decision-making abilities of intelligent agents can be improved.

     *  The interconnection and management scheduling of multiple
        intelligent network elements.  The advent of the agent era demands
        closer cooperation and interconnectivity among networks.  The
        intelligence of network elements signifies the flexibility in
        supporting service operations.

  4.2.  Intelligent Forwarding and Routing

     Unlike traditional address-based peer-to-peer information routing and
     forwarding, in the era of agent communication, tasks are first
     decomposed and grouped, followed by necessary communication for task
     execution or inference.  After task triggering, agents and routing
     protocols in appropriate domains are matched based on service
     characteristics and requirements, enabling intelligent agent routing
     decisions and addressing.

     Service characteristics can be based on the current task
     classification (such as ordering, navigation, etc.), or can be
     classified according to time-delay sensitivity, data without loss,
     high bandwidth, etc.

     The capability graph can be used to search for an appropriate list of
     agents during addressing.  This process can be combined with the
     capabilities of agents, application intents, real-time loads, and
     link quality for dynamic addressing.  Based on the characteristics of



  Guo                     Expires 3 September 2026                [Page 5]


  Internet-Draft  Agentic Network Architecture and Protoco      March 2026


     the agents, targeted traffic distribution can be implemented.
     Furthermore, through self-learning, the selection of the optimal path
     can be reinforced.

  4.3.  Intent and Network Environment Perception

     Agentic gateway should achieve autonomous event detection and
     handling, perceive and forward information intentions, and sense the
     state of the intelligent agent (online/offline), load, link quality,
     computing power, and other environmental states.  Based on this, it
     should search for the next hop/destination.  At the same time, it
     must also perceive abnormal signals, understand the significance of
     collected data signals, trigger corresponding actions, possess key
     technologies such as strategy translation and generation, achieve
     triple perception and tuning of itself, the network, and the
     business, autonomously allocate resources, and realize an event self-
     loop.

  4.4.  Protocol Compatibility and Conversion

     *  Regardless of whether the devices come from the same manufacturer,
        a unified protocol must be adopted to facilitate routing to nearby
        or edge large model servers within the same gateway.  The gateway
        can automatically identify the protocol, align fields, semantics
        and capability descriptions, then generate adaptations.

     *  Supports semantic communication, supports the conversion of
        modalities between different agents, and supports the conversion
        of context content (such as MCP result conversion).

  4.5.  Support Multi-level Inference

     In a cloud-edge-end multi-tier inference architecture, the gateway
     connects end-side agents, edge nodes, backbone routers, and the
     cloud.  The edge resource pool typically deploys lightweight or
     specialized large models and agents, while the central cloud can host
     super agents and full-scale large models.  Before cross-domain
     interconnection, the gateway performs edge analysis and processing to
     determine which tasks should be sent to edge nodes for inference and
     which should be forwarded to central nodes.  This enables
     hierarchical forwarding of service flows and data pre-processing,
     avoiding the upload of massive amounts of raw redundant data to the
     cloud.  This analysis process can leverage large and small model
     capabilities to complete the tasks.







  Guo                     Expires 3 September 2026                [Page 6]


  Internet-Draft  Agentic Network Architecture and Protoco      March 2026


  4.6.  Information Management and Control

     Discovering newly online agents and reporting this information to
     higher-level management, allowing registration and reporting through
     the edge gateway.  It manages intra-domain agent addresses,
     synchronizes and maintains teaming information, and ensures
     consistency between routing identifiers and networking relationships.

     Acting as an execution entity for upper-layer orchestration and
     management, it possesses information reporting capabilities, executes
     management instructions from higher layers, and implements cross-
     domain access control.  The information reported by network elements
     is aggregated at the management layer, where it is uniformly invoked
     and analyzed by the super agents in the orchestration layer.

  4.7.  Equipment-level Operation and Maintenance Autonomy

     Equipment-level operation and maintenance autonomy can achieve
     autonomous and fully automated Operation and Maintenance through
     agentic network elements:

     *  Capabilities of Autonomous Perception and Problem Handling:
        Equipped with the ability to autonomously perceive the environment
        and detect data issues, identify problems, and handle network
        events.  It can independently complete fault diagnosis and problem
        localization, support automatic duty reporting, and enable
        automatic configuration distribution along with self-inspection
        before service deployment.

     *  Autonomous Event Handling: Capable of real-time perception of the
        network environment and business data, automatically completing
        data reporting to achieve 24/7 unattended autonomous operation.
        It proactively discovers, identifies, and processes network
        events, accurately determines the type of issue, and autonomously
        completes the analysis and resolution of network events

     *  Interoperation with Other Intelligent Elements: To meet specific
        operation and maintenance requirements for users, it can
        autonomously initiate mutual recognition, interconnection, mutual
        inspection, and information exchange with other intelligent
        network elements.  It supports interconnection and interoperation
        with other agents, mutual status verification, and efficient
        exchange of fault information.








  Guo                     Expires 3 September 2026                [Page 7]


  Internet-Draft  Agentic Network Architecture and Protoco      March 2026


  4.8.  Safety

     *  Conducting network security status monitoring, with intelligent
        threat tracing and full lifecycle auditing capabilities,
        leveraging AI-driven situational awareness and anomaly detection
        to identify covert attacks.

     *  Access control (blacklists, etc.)

     *  Data security

     (To be expanded)

  5.  Architecture of Agentic Network for Multi-level Inference

  5.1.  Architecture and Functions

     Agentic (IP) network refers to a network composed of software and
     hardware designed for ubiquitous agent interconnection.  It primarily
     consists of underlying connectivity resources, computing resources
     (computing nodes, data centers, etc.), intelligent agent-enabled
     network elements in the middle, an upper-layer coordination
     management system, as well as the applications at the edge and in the
     center.  It is deployed in a master-slave distributed mode and
     supports cross-domain collaboration.

     The architecture can include the application layer, orchestration
     layer, management and control layer, device and network layer,
     computing resource layer, and data layer.  The application layer
     primarily targets agent applications and scenarios.  The capabilities
     of the management & control layer and orchestration layer can be
     realized through a unified platform.  The device and network layer
     focuses on existing network devices.  The computing resource layer
     refers to the distribution of computing resources that facilitate
     agent interconnection and inference.  The data layer provides a
     unified shared storage for data.

     (To be expanded)

  6.  IANA Considerations

     This document has no requests to IANA.

  7.  Security Considerations

     This document describes architecture and protocol of agentic network.
     As such, the following security considerations remain high level,
     i.e., in the form of principles, guidelines or requirements.



  Guo                     Expires 3 September 2026                [Page 8]


  Internet-Draft  Agentic Network Architecture and Protoco      March 2026


  8.  References

  8.1.  Informative References

     [CCSA-AIWan]
                CCSA, "Research Report on Artificial Intelligence Wide
                Area Network (AI WAN) (2025)", June 2025.

  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 3 September 2026                [Page 9]


name: draft-bernardos-nmrg-agentic-network-optimization
rev: 00
title: Solutions for enabling agentic sensing with network optimization
time: 2026-03-02T14:22:24Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T14:22:24Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:04.973529+00:00
source: ietf
abstract:
  Integrated Sensing and Communications (ISAC) represents a paradigm
     shift in wireless networks, where sensing and communication functions
     are jointly designed and optimized.  By leveraging the same spectral
     and hardware resources, ISAC enables advanced capabilities such as
     environment perception, object tracking, and situational awareness,
     while maintaining efficient and reliable data transmission.  There
     are sensing scenarios and use cases that involve a distributed
     sensing task, in which multiple sensors participate and contribute
     with (raw or pre-processed) sensing data, which is processed by a
     sensing service (e.g., fusing sensing measurements from the different
     sensors).  This sensing service needs to be executed on some kind of
     sensing processing/computing function which receives raw (or
     preprocessed) data from multiple sources, potentially of different
     (heterogeneous) kinds (e.g., RF and non-RF sensing, or RF from
     different radio technologies).  This processing might impose time
     synchronization constraints on the reception of the different parts
     of data, as well as potentially specific computing and/or AI/ML
     capabilities on the processing node.

     The joint selection of sensing entities, processing locations, and
     network configuration under time-varying conditions results in a
     large, coupled, and non-stationary decision space.  These
     characteristics motivate the use of agentic AI to enable distributed,
     closed-loop configuration and reconfiguration of sensing and
     networking resources.

     This document presents initial considerations and potential solution
     directions for an architecture that enables the use of agentic AI for
     sensing (as an exemplary use case) supporting network optimization.

full_text:
  NMRG                                                       CJ. Bernardos
  Internet-Draft                                                      UC3M
  Intended status: Experimental                                  A. Mourad
  Expires: 3 September 2026                                   InterDigital
                                                              M. A. Jadoon
                                                   InterDigital Europe Ltd
                                                              2 March 2026


      Solutions for enabling agentic sensing with network optimization
            draft-bernardos-nmrg-agentic-network-optimization-00

  Abstract

     Integrated Sensing and Communications (ISAC) represents a paradigm
     shift in wireless networks, where sensing and communication functions
     are jointly designed and optimized.  By leveraging the same spectral
     and hardware resources, ISAC enables advanced capabilities such as
     environment perception, object tracking, and situational awareness,
     while maintaining efficient and reliable data transmission.  There
     are sensing scenarios and use cases that involve a distributed
     sensing task, in which multiple sensors participate and contribute
     with (raw or pre-processed) sensing data, which is processed by a
     sensing service (e.g., fusing sensing measurements from the different
     sensors).  This sensing service needs to be executed on some kind of
     sensing processing/computing function which receives raw (or
     preprocessed) data from multiple sources, potentially of different
     (heterogeneous) kinds (e.g., RF and non-RF sensing, or RF from
     different radio technologies).  This processing might impose time
     synchronization constraints on the reception of the different parts
     of data, as well as potentially specific computing and/or AI/ML
     capabilities on the processing node.

     The joint selection of sensing entities, processing locations, and
     network configuration under time-varying conditions results in a
     large, coupled, and non-stationary decision space.  These
     characteristics motivate the use of agentic AI to enable distributed,
     closed-loop configuration and reconfiguration of sensing and
     networking resources.

     This document presents initial considerations and potential solution
     directions for an architecture that enables the use of agentic AI for
     sensing (as an exemplary use case) supporting network optimization.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.



  Bernardos, et al.       Expires 3 September 2026                [Page 1]


  Internet-Draft    Agentic AI with network optimization        March 2026


     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 3 September 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
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Enabling agentic AI distributed sensing with network
             optimization  . . . . . . . . . . . . . . . . . . . . . .   5
     4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
     7.  Informative References  . . . . . . . . . . . . . . . . . . .  13
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

  1.  Introduction

     Integrated Sensing and Communications (ISAC) is emerging as a key
     enabler for next-generation wireless networks, integrating sensing
     and communication functionalities within a unified system.  By
     leveraging the same spectral, hardware, and computational resources,
     ISAC enhances network efficiency while enabling new capabilities such
     as high-resolution environment perception, object detection, and
     situational awareness.  This paradigm shift is particularly relevant
     for applications requiring both reliable connectivity and precise
     sensing, such as autonomous vehicles, industrial automation, and
     smart city deployments.  Given its strategic importance, ISAC has
     gained significant traction in standardization efforts.  The ETSI



  Bernardos, et al.       Expires 3 September 2026                [Page 2]


  Internet-Draft    Agentic AI with network optimization        March 2026


     Industry Specification Group (ISG) on ISAC has been established to
     explore technical requirements and use cases, while 3GPP has
     initiated discussions on ISAC-related features within its ongoing
     research on future 6G systems.  Furthermore, research initiatives
     within the IEEE and IETF are investigating how ISAC can be integrated
     into network architectures [I-D.ietf-green-use-cases], spectrum
     management, and protocol design, making it a critical area of
     development in the evolution of wireless networks.

     There are sensing scenarios and use cases that involve a distributed
     sensing task, in which multiple sensors participate and contribute
     with (raw or pre-processed) sensing data, which is processed by a
     sensing service (e.g., fusing sensing measurements from the different
     sensors).  This sensing service needs to be executed on some kind of
     sensing processing/computing function which receives raw (or
     preprocessed) data from multiple sources, potentially of different
     (heterogeneous) kinds (e.g., RF and non-RF sensing, or RF from
     different radio technologies).  This processing might impose time
     synchronization constraints on the reception of the different parts
     of data, as well as potentially specific computing and/or AI/ML
     capabilities on the processing node.

     The selection of the nodes that participate as sensors and sensing
     processing functions in a given distributed sensing task and the
     configuration of the network to facilitate the sensing task, and
     optimize both the sensing and the network operation, are not
     independent.  However, achieving an overall optimal configuration is
     not a trivial task, especially when multiple optimization metrics
     and/or constraints are considered.

     In distributed sensing, sensing KPIs (e.g., accuracy, refresh rate,
     confidence level, latency) are tightly coupled with radio, compute,
     and transport configurations.  Moreover, mobility, traffic load, and
     environmental dynamics continuously alter the relationship between
     configuration and achieved sensing performance.  Static or centrally
     pre-computed deterministic configurations can therefore become
     suboptimal or infeasible at run time.  An agentic AI approach enables
     distributed decision-making, coordination among sensing and
     networking entities, and adaptive reconfiguration to sustain sensing
     KPIs under dynamic conditions

     We assume a generic network architecture, where IETF CATS and GREEN
     architectural considerations and solutions can be of application,
     though the solution can be generalized to scenarios based on
     different architectures.






  Bernardos, et al.       Expires 3 September 2026                [Page 3]


  Internet-Draft    Agentic AI with network optimization        March 2026


     We assume that there is a network function in charge of the
     coordination and configuration of the distributed sensing task, aware
     of which nodes in the network can participate as sensor nodes, and
     potentially of the capabilities of potential sensing processing
     nodes.  This network function can be, for example, the Gateway
     Sensing Function (GSF)/ the Sensing Control Function (SCF) as
     introduced by 3GPP.

     We also assume that there is a network function in charge of managing
     the network configuration of the network, such as an SMF/AMF in a
     3GPP 5G architecture.

     We assume that there are AI agents, which might run on network nodes
     (such as terminals, radio access nodes or infrastructure nodes), of
     two types: AI agents for Sensing (AIaS) and AI agents for Network
     (AIaN).  These agents can run tasks aimed at finding an optimal
     configuration for sensing and connectivity, respectively and can
     interact among them to pursue these goals.

     A given network function or application function might request a
     specific sensing task (with associated requirements, e.g., in terms
     of accuracy) to the SCF directly or indirectly via the NEF and/or
     GSF, which can then request several AI agents for Sensing to select a
     sensing configuration and interact with the AI network agents to
     ensure the network is configured as needed.  Note that the sensing
     task request might have some associated requirements, specific to the
     task (such as accuracy, or privacy) but also global ones, such as
     energy consumption, etc.

  2.  Terminology

     The following terms are used in this document:

        AIaS: AI agent for Sensing.

        ISAC: Integrated Sensing and Communications.

        SCF: Sensing Control Function, responsible of configuring and
        triggering distributed sensing performed by a group of sensors.

        SF: Sensing Function, participates in a distributed sensing
        function as a sensor.

        SPF: Sensing Processing Function, participates in a distributed
        sensing function processing raw (or pre-processed) sensing data.






  Bernardos, et al.       Expires 3 September 2026                [Page 4]


  Internet-Draft    Agentic AI with network optimization        March 2026


  3.  Enabling agentic AI distributed sensing with network optimization

     We describe next an example of operation and signaling for a
     distributed sensing task to be configured and dynamically optimized
     based on agentic AI for sensing and networking.  An AI agent for
     Sensing and an AI agent for Networking run on several network nodes
     (terminals, access nodes and processing nodes) and might interact to
     agree on a sensing and networking configuration that overall meets
     the sensing requirements while optimizing other metrics (such as
     privacy and energy consumption).

  /_\ AI agent for Sensing
   _
  |_| AI agent for Networking
                         _________
                        |  _      |
                        | |_| /_\ +-----\
                        |_________|      \   ____________________________
                      Access Network #1   \ |                            |
           _________                       \|  _________                 |
          |  _      |                       | |  _      |                |
          | |_| /_\ |                       | | |_| /_\ |                |
          |_________|                       | |_________|    _________   |
          terminal #1                       |  Processing   |  _      |  |
                         ______________     |   node #1     | |_| /_\ |  |
                        (              )    |               |_________|  |
   _________           (     object     )   |                  SCF       |
  |  _      |           (______________)    |                            |
  | |_| /_\ |                               |  _________                 |
  |_________|                               | |  _      |                |
  terminal #2                               | | |_| /_\ |                |
                                           /| |_________|                |
                              _________   / |  Processing                |
           _________         |  _      | /  |  node #2                   |
          |  _      |        | |_| /_\ +-   |____________________________|
          | |_| /_\ |        |_________|
          |_________|      Access Network #2
          terminal #3

              Figure 1: Exemplary scenario and architecture

     Figure 1 shows a high-level picture of the architecture.

     In the following, we describe an exemplary procedure showing how
     different agents can interact to configure a distributed sensing
     task.  The focus is on the interactions, the information exchanged
     and what actions might be triggered.




  Bernardos, et al.       Expires 3 September 2026                [Page 5]


  Internet-Draft    Agentic AI with network optimization        March 2026


     _________   _________   _________      _________   _____   _____
    |  _      | |  _      | |  _      |    |  _      | |  _  | |     |
    | |_| /_\ | | |_| /_\ | | |_| /_\ |    | |_| /_\ | | |_| | | /_\ |
    |_________| |_________| |_________|    |_________| |_____| |_____|
    terminal #1 terminal #2    AN #1         SPF #1     netw.    SCF
       |   |       |   |       |   |          |   |     ctrl.     |
       |   |  (0.AI agents discovery and registration)    | 1.Sensing task
       |   |       |   |       |   |          |   |       |     request
       |   | 3.Agentic sensing |   |       2.Sensing task request |<---
       |   |     task request  |   |<-----------------------------|
       |   |<----------------------|          |   |       |       |
    4a.Agentic net req.  4b.Agentic net req.  4c.Agentic net req. |
       |<--|       |   |       |<--|          |<--|       |       |
    4a.Connectivity request    |   |          |   |       |       |
       |------------------------------------------------->|       |
       |   |       |   |       |4b.Connectivity request   |       |
       |   |       |   |       |------------------------->|       |
       |   |       |   |       |   |          |4c.Connectivity request
       |   |       |   |       |   |          |---------->|       |
       |   |       |   |       |   |          |   |   (network    |
       |   |       |   |       |   |          |   |    config.)   |
       |   |       |   |       | 5b.Connectivity response |       |
       |   |       |   |       |<-------------------------|       |
       |   |       |   |       |   |  5c.Connectivity response    |
    6a.Agentic net resp.       |   |          |<----------|       |
       |-->|       |   6b.Agentic net resp.  6c.Agentic net resp. |
       |   |       |   |       |-->|          |-->|       |       |
       |   |       |   |       |   |7.Agentic sensing task resp.  |
      7.Agentic sensing task resp. |<-------------|       |       |
       |   |---------------------->|          |   |       |       |
       7.Agentic sensing task resp.|          |   |       |       |
       |   |       |   |---------->| 8.Sensing task response      |
       |   |       |   |       |   |----------------------------->|
       |   |       |   |       |   |          |   |       |       |
       |  (9.Monitoring actions to trigger reconfig. if needed)   |
       |   |       |   |       |   |          |   |       |       |

         Figure 2: Exemplary signaling of agentic AI interactions for
                        optimized distributed sensing

     Figure 2 shows the message sequence chart of an agentic AI-enabled
     multi-sensor distributed sensing which is explained next:









  Bernardos, et al.       Expires 3 September 2026                [Page 6]


  Internet-Draft    Agentic AI with network optimization        March 2026


     0.   We assume AI agents for Sensing have been trained with some
          data, possibly based on their own local knowledge and
          potentially enriched with additional data.  We also assume they
          have some knowledge about other neighboring agents and that
          there could be some type of centralized/distributed repository
          where they are registered.

     1.   The network receives a sensing request.  A sensing managing
          entity, such as the SCF, receives this request and decides to
          delegate that request, or part of that request to some AI agents
          for Sensing running in the network.  For example, the initial
          request received by the network may be for a XR/multi-media
          service (which explicitly or implicitly require sensing
          services), while the sensing request that is delegated to AI
          Agents may be created to meet the sensing requirements of the
          initial request.  SCF would decide which specific sensing
          request should be processed via AI agents and which part of the
          sensing could be done using sensing "traditional" (i.e., not
          using agentic AI) methods.

     2.   Based on the information and metadata associated to the sensing
          request (e.g., location of the intended sensing), the SCF
          determines to use AI Agents for executing the sensing task, and
          sends a request to the AI agent for Sensing at the chosen
          sensing entity (Access Node #1 [AN#1], in our example).  In this
          step the SCF may determine to use AI Agents based on any
          combination of:

          a.  an indication received in the initial request that AI Agents
              can/must be used.

          b.  Received policy information, indicates that AI Agents can/
              must be used.

          c.  Fast reactions to changes in contextual information and
              availability of resources is required.

          d.  The overall service requirements allow for delays and errors
              incurred due to potential conflicts among agents and
              performance oscillations.  These may be specified as
              threshold values.

          This request might include the following information:








  Bernardos, et al.       Expires 3 September 2026                [Page 7]


  Internet-Draft    Agentic AI with network optimization        March 2026


          a.  Sensing task description: metadata indicating what is the
              sensing task, sensing accuracy (spatial and temporal),
              whether the sensing task involves stationary or mobile
              targets, Time information associated with the sensing task
              (e.g., a time period), etc.

          b.  Sensing data governance requirements about privacy, security
              and trustworthiness such as for example what sensing data
              can be processed where in the system and what pre-processing
              and processing might be allowed to happen with the data, its
              fusion framework with other data and its exposure to
              application function or network function.  Examples (non-
              limiting) of encoding of this are:

              i.    Processing of raw sensing data: only local at the
                    originating node / local or remote processing allowed
                    / partial processing allowed remotely.

              ii.   Trustworthiness of data: any generated data is trusted
                    / only data from a list of explicit sources is trusted
                    / data has to be signed by a trusted source to be
                    trusted.

              iii.  Confidentiality of exchanged data: all data (processed
                    or not) must be encrypted (specifying the mechanism to
                    be used to encrypt it), data (raw/partially processed/
                    processed) must be encrypted, all data can be sent in
                    clear.

              iv.   List of trusted generating entities/administrative
                    domains.

              Allowed types of sensing fusion, e.g., a combination of the
              following possible options: only with raw data of some kind,
              mixing data partially processed with raw data, mixing
              different types of sensing technologies, mixing different
              levels of trustworthiness, etc.  If the nodes involved in
              the sensing task belong to different administrative domains,
              additional mechanisms might need to be used to guarantee/
              prove that the processing and/or confidentiality of the
              sensing data is enforced.  An example would be the use of a
              private or public blockchain.

          c.  Allowed level of agentic AI interactions.  This parameter,
              which might be expressed in different ways, indicates how
              different agents are allowed to interact towards completion
              of the intended task.  For example, the requester may
              indicate that the agent receiving the request has to perform



  Bernardos, et al.       Expires 3 September 2026                [Page 8]


  Internet-Draft    Agentic AI with network optimization        March 2026


              the required actions without interacting with other sensing
              agents, or without interacting with networking agents, or
              which limitations to apply in regards of other agentic
              interactions (e.g., agent ownership limitations).  It also
              includes whether the involved agents are responsible for
              monitoring the sensing task to trigger alerts and propose
              reconfiguration actions if needed.  This parameter may also
              indicate the maximum size of the agent-to-agent
              communication hops, or tiers or number of worker Agents used
              for executing part of a task or in whole.  This may be seen
              as the maximum size or depth of the agent-to-agent network
              (graph).  When this parameter is sent from one agent to
              another agent (as in step 3.d), it may adjust the value to
              be the (maximum size) relative to that specific agent node/
              hop (for example, allowed_level_of_agentic_AI_interactions =
              allowed_level_of_agentic_AI_interactions - 1).

          d.  Additional network requirements, such as energy consumption
              metrics.

          e.  List of AI agents available (optional, as this might be
              known by the receiving AI agent based on its local context
              and/or other AI agent discovery mechanisms).

     3.   The receiving AI agent for Sensing (in this example AIaS@AN#1)
          processes the request and based on the parameters received and
          its knowledge of the local context and prior training, decides
          whether it can honor the received request and whether it can
          interact with other agents.  In this example, the agent decides
          to interact with three additional AI agents for sensing
          (@terminal#1 and @terminal#2, @processing node/SPF #1) to
          basically configure a multistatic active sensing (involving
          terminals #1 and #2 and AN#1) with the sensing processing done
          at processing node/SPF #1.  AIaS@AN#1 sends an Agentic sensing
          task request, which includes the following parameters:

          a.  Sensing task description: metadata indicating what is the
              intended sensing task, sensing accuracy (spatial and
              temporal), whether the sensing task involves stationary or
              mobile targets, etc.

          b.  Intended sensing task configuration, including parameters
              such as:

              i.    Static/Multi-static.

              ii.   Active/passive sensing.




  Bernardos, et al.       Expires 3 September 2026                [Page 9]


  Internet-Draft    Agentic AI with network optimization        March 2026


              iii.  Sensing technology (e.g., WiFi, 5G).

              iv.   Other participant node's IDs.

          c.  Sensing data governance requirements about privacy, security
              and trustworthiness such as for example what sensing data
              can be processed where in the system and what pre-processing
              and processing might be allowed to happen with the data, its
              fusion framework with other data and its exposure to
              application function or network function.  Examples (non-
              limiting) of encoding of this are:

              i.    Processing of raw sensing data: only local at the
                    originating node / local or remote processing allowed
                    / partial processing allowed remotely.

              ii.   Trustworthiness of data: any generated data is trusted
                    / only data from a list of explicit sources is trusted
                    / data has to be signed by a trusted source to be
                    trusted.

              iii.  Confidentiality of exchanged data: all data (processed
                    or not) must be encrypted (specifying the mechanism to
                    be used to encrypt it), data (raw/partially processed/
                    processed) must be encrypted, all data can be sent in
                    clear.

              iv.   List of trusted generating entities/administrative
                    domains.

              Allowed types of sensing fusion, e.g., a combination of the
              following possible options (non limiting): only with raw
              data of some kind, mixing data partially processed with raw
              data, mixing different types of sensing technologies, mixing
              different levels of trustworthiness, etc.  If the nodes
              involved in the sensing task belong to different
              administrative domains, additional mechanisms might need to
              be used to guarantee/prove that the processing and/or
              confidentiality of the sensing data is enforced.  An example
              would be the use of a private or public blockchain.

          d.  Allowed level of agentic AI interactions.  This parameter,
              which might be expressed in different ways, indicates how
              different agents are allowed to interact towards completion
              of the intended task.  For example, the requester may
              indicate that the agent receiving the request has to perform
              the required actions without interacting with other sensing
              agents, or without interacting with networking agents, or



  Bernardos, et al.       Expires 3 September 2026               [Page 10]


  Internet-Draft    Agentic AI with network optimization        March 2026


              which limitations to apply in regards of other agentic
              interactions (e.g., agent ownership limitations).  It also
              includes whether the involved agents are responsible for
              monitoring the sensing task to trigger alerts and propose
              reconfiguration actions if needed.  An example of a possible
              encoding of the allowed level of agentinf AI interaction is
              the following:

              0.  no delegation,

              1.  local AIaS may interact with local AIaN,

              2.  local AIaS may delegate/talk to other sensing nodes, but
                  those cannot delegate it further,

              3.  local AIaS may delegate/talk to other sensing nodes,
                  which can delegate it to N-2 levels.

          e.  Additional network requirements, such as energy consumption
              metrics.

          How an agent decides that additional sensing tasks need to be
          performed in order to honor/complete the received sensing task
          is out of the scope of this document.  It is up to the specific
          agents' implementation and the knowledge they have of the local
          context.

     4.   The receiving agents process the request, and similarly to what
          was done in the previous step, decide whether they need to do
          additional agent interactions (this can only happen if the
          received "allowed level of agentic AI interactions" is > 1, on
          each level the "allowed level of agentic AI interactions" is
          decreased by 1).  (Non-limiting) examples of these sub-tasks
          are:

          *  Perform an isolated sensing task targeting a specific goal
             (i.e., track an object in a given geographic area, with an
             intended accuracy, sensing technology and energy contraints).

          *  Configure the network and/or specific network elements to
             support a given connectivity level to transport the data
             generated by another agents.

          *  Find out which types of sensing, and with which level of
             trustworthiness/security/privacy are allowed to be used by
             certain nodes and/or in a given geographic area.

          *  Etc.



  Bernardos, et al.       Expires 3 September 2026               [Page 11]


  Internet-Draft    Agentic AI with network optimization        March 2026


          Let's assume for the sake of this example, that the following
          actions are required:

          i.    AIaS@terminal#1 needs to interact with its local AI agent
                for Networking (AIaN@terminal#1) to ensure that the radio
                interface of terminal#1 is configured as required by the
                sensing task.

          ii.   AIaS@AN#1 needs to interact with its local AI agent for
                Networking@AN#1 to request a guaranteed communication path
                to the processing node#1.  As a result of this, AIaN@AN#1
                sends the required request to the networking control
                entity (in this example SMF/AMF), which then performs the
                required configuration.

          iii.  AIaS@processing-node#1 needs to interact with its local AI
                agent for Networking@processing-node#1 to request a
                guaranteed communication path to AN#1 and terminals #1 and
                #2.  As a result of this, AIaN@processing-node#1 sends the
                required request to the networking control entity (in this
                example SMF/AMF), which then performs the required
                configuration.

          Note that it might also be possible that the request for
          guaranteed communication paths (e.g., between the processing
          node #1 and terminals #1 and #2, could also be triggered by AI
          agents running on the terminals.

     5.   As a result of the requests (4b and 4c) for guaranteed
          communication paths to the AMF/SMF, the AMF/SMF performs the
          required configurations and responds back to the AI agents for
          networking (5b and 5c).

     6.   The AI agents for networking respond back to the AI agents for
          sensing, after completing their tasks.

     7.   Each involved AI agent that was tasked a given action responds
          back to the initiating AI agent.  In this example,
          AIaS@terminal#1, AIaS@terminal#2 and AIaS@processing-node#1
          responds to AIaS@AN#1, including the result of the operation.











  Bernardos, et al.       Expires 3 September 2026               [Page 12]


  Internet-Draft    Agentic AI with network optimization        March 2026


     8.   Once all the required configurations are completed, the initial
          agent (AIaS@AN#1) responds back to the SCF with a sensing task
          response, providing the result of the sensing task request
          (success/failure) and about the resulting sensing (and
          networking) configuration.  At this point, the distributed
          sensing task is ongoing.  This may also include information of
          the established Agent Network, e.g., a graph of agents and their
          capabilities.

     9.   SENSING and CONNECTIVITY MONITORING.  Depending on whether the
          agents were instructed to perform continuous monitoring or not,
          different options are possible:

          a.  Monitoring performed by the agents.  In this case, agents
              monitor the activity and local context for variations that,
              according to its previous training and knowledge, might
              require corrections.  If that is the case, the conducted
              actions are notified back to the SCF, through the chain of
              involved agents.  Examples of monitoring include: (i)
              Measuring (passively or actively) connectivity between
              sensing sources and processing node, (ii) Measuring
              estimated sensing precision, (iii) Measuring energy
              consumption associated with the sensing task.  The
              monitoring can include additional parameters, such as: (i)
              specific thresholds for each/some monitored parameters and
              associated actions if those threshold are passed, (ii)
              Frequency of monitoring.

          b.  Monitoring performed by the network.  In this case, "legacy"
              monitoring mechanisms are used, which might trigger
              reconfiguration actions (in a similar fashion to the initial
              sensing task request).

  4.  IANA Considerations

     N/A.

  5.  Security Considerations

     TBD.

  6.  Acknowledgments

     The work of Carlos J.  Bernardos in this document has been partially
     supported by the Horizon Europe MultiX (Grant Agreement No.
     101192521) and DISCO6G-CM.

  7.  Informative References



  Bernardos, et al.       Expires 3 September 2026               [Page 13]


  Internet-Draft    Agentic AI with network optimization        March 2026


     [I-D.ietf-green-use-cases]
                Stephan, E., Palmero, M. P., Claise, B., Wu, Q.,
                Contreras, L. M., Bernardos, C. J., and X. Chen, "Use
                Cases for Energy Efficiency Management", Work in Progress,
                Internet-Draft, draft-ietf-green-use-cases-01, 22 January
                2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
                green-use-cases-01>.

  Authors' Addresses

     Carlos J. Bernardos
     Universidad Carlos III de Madrid
     Av. Universidad, 30
     28911 Leganes, Madrid
     Spain
     Phone: +34 91624 6236
     Email: cjbc@it.uc3m.es
     URI:   http://www.it.uc3m.es/cjbc/


     Alain Mourad
     InterDigital Europe Ltd
     London
     United Kingdom
     Email: Alain.Mourad@InterDigital.com
     URI:   http://www.InterDigital.com/


     Muhammad Awais Jadoon
     InterDigital Europe Ltd
     London
     United Kingdom
     Email: muhammad.awaisjadoon@interdigital.com


















  Bernardos, et al.       Expires 3 September 2026               [Page 14]


name: draft-jadoon-nmrg-agentic-ai-autonomous-networks
rev: 00
title: Agentic AI Architectural Principles for Autonomous Computer Networks
time: 2026-03-02T20:15:38Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T20:15:38Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:04.982629+00:00
source: ietf
abstract:
  Agentic AI systems combine planning, reasoning, tool invocation, and
     feedback loops to pursue system-defined goals with a controlled
     degree of autonomy.  In networking, this enables an evolution from
     statically configured automation toward goal-driven closed-loop
     operations spanning multiple protocol layers and administrative
     domains.

     This document introduces architectural principles for "agentic
     augmentation" of the existing layered protocol stack as represented
     by the Internet protocol suite (IP suite).  The key concept of the
     proposed principles is that deterministic protocol layering remains
     intact for interoperability, while AI Agents are introduced as first-
     class entities at each IP suite layer and are coordinated by one or
     more agent controllers via agentic methods and procedures.

     The purpose of this document is to initiate discussion within the
     research community on agentic networking.  It identifies
     architectural research challenges that should be discussed to enable
     the addition of one or more AI Agents at one or more IP suite layers
     with the goal to allow AI Agents to improve the behaviour of a layer
     through reasoning with AI Agents at the same or other IP suite
     layers.

full_text:
  NMRG                                                        M. A. Jadoon
  Internet-Draft                                              S. Robitzsch
  Intended status: Informational                   InterDigital Europe Ltd
  Expires: 3 September 2026                                C. J. Bernardos
                                          Universidad Carlos III de Madrid
                                                              2 March 2026


    Agentic AI Architectural Principles for Autonomous Computer Networks
            draft-jadoon-nmrg-agentic-ai-autonomous-networks-00

  Abstract

     Agentic AI systems combine planning, reasoning, tool invocation, and
     feedback loops to pursue system-defined goals with a controlled
     degree of autonomy.  In networking, this enables an evolution from
     statically configured automation toward goal-driven closed-loop
     operations spanning multiple protocol layers and administrative
     domains.

     This document introduces architectural principles for "agentic
     augmentation" of the existing layered protocol stack as represented
     by the Internet protocol suite (IP suite).  The key concept of the
     proposed principles is that deterministic protocol layering remains
     intact for interoperability, while AI Agents are introduced as first-
     class entities at each IP suite layer and are coordinated by one or
     more agent controllers via agentic methods and procedures.

     The purpose of this document is to initiate discussion within the
     research community on agentic networking.  It identifies
     architectural research challenges that should be discussed to enable
     the addition of one or more AI Agents at one or more IP suite layers
     with the goal to allow AI Agents to improve the behaviour of a layer
     through reasoning with AI Agents at the same or other IP suite
     layers.

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






  Jadoon, et al.          Expires 3 September 2026                [Page 1]


  Internet-Draft             Agentic-AI-Arch-ACN                March 2026


     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 3 September 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
     2.  Terminology and Conventions . . . . . . . . . . . . . . . . .   3
     3.  Baseline: IP Suite Layered Protocol Stack . . . . . . . . . .   4
     4.  Proposed Agentic Augmentation at to Layered Approach  . . . .   4
       4.1.  5.1.  Per-Layer Agent Nets and Per-Layer Controllers  . .   5
       4.2.  5.3.  Relationship to the Deterministic Stack . . . . . .   5
     5.  Functional Workflow and Reference Points  . . . . . . . . . .   6
       5.1.  6.1.  Controller and Agent Functional Blocks  . . . . . .   6
       5.2.  6.2.  Reference Points (Interfaces) . . . . . . . . . . .   6
     6.  Challenges Motivating Interoperable Work  . . . . . . . . . .   9
     7.  Security, Safety, Determinism, and Accountability
             Considerations  . . . . . . . . . . . . . . . . . . . . .   9
     8.  Relationship to Existing IETF/IRTF Work . . . . . . . . . . .  11
     9.  Recommendations and Next Steps for IETF Discussion  . . . . .  11
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
     12. Normative References  . . . . . . . . . . . . . . . . . . . .  11
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

  1.  Introduction

     Computer networks have long pursued higher automation for self-
     configuration, self-healing, self-optimization, and self-protection.
     Recent advances in AI, including agentic AI systems, enable a shift
     from isolated automation approaches toward distributed, goal-driven
     closed-loops that can plan multi-step actions, invoke tools, adapt to
     feedback, and coordinate with peers to improve the behaviour of
     existing or new protocols.



  Jadoon, et al.          Expires 3 September 2026                [Page 2]


  Internet-Draft             Agentic-AI-Arch-ACN                March 2026


     However, multi-agent deployments are typically proprietary: there is
     no widely adopted, vendor-independent approach for naming, reaching,
     discovering, and coordinating AI Agents that act on network state
     across multiple protocol layers and domains.

     This document is intended to seed IETF discussion by proposing a
     architectural principles and an interface model for "agentic
     augmentation" of the existing layered OSI stack.  The objective is
     not to replace the deterministic behavior of protocols used for
     interoperability and packet transport.  Instead, the architecture
     introduces AI Agents at each layer, coordinated by orchestrators, so
     that closed-loop automation can be pursued in a structured and
     governable way.

  2.  Terminology and Conventions

     AI Agent (AIA): A software entity capable of pursuing goals by
     reasoning and planning, and by invoking tools (APIs, protocols,
     controllers, knowledge bases) to observe state and perform actions.

     Agentic AI System: A system composed of one or more AI Agents and
     optional controller(s) that performs goal-directed operations over
     time by using available tools and feedback loops.

     Agent Controller: A logical function that accepts an input request/
     goal, performs task decomposition and assignment, coordinates one or
     more AI Agents, and produces outputs or verified actuation outcomes.
     Controllers may be per-layer (distributed) or centralized.

     Agent Net: A set of AI Agents associated with a specific layer of the
     stack, together with their coordination logic and tools for that
     layer.

     IP Suite Stack Interfaces: The conventional (non-agentic) interfaces
     between adjacent layers (e.g., a transport interface exposed to
     applications), and the conventional control/management interfaces
     that configure or observe a layer (e.g., socket APIs, YANG/NETCONF/
     RESTCONF, routing protocol configuration, telemetry streams).

     Tool: Any callable capability used by an AI Agent to ground reasoning
     or execute actions (e.g., retrieve telemetry, push configuration,
     initiate diagnostics, query a digital twin, call a controller).









  Jadoon, et al.          Expires 3 September 2026                [Page 3]


  Internet-Draft             Agentic-AI-Arch-ACN                March 2026


  3.  Baseline: IP Suite Layered Protocol Stack

     Layering is central to interoperability.  In a conventional layered
     stack, upper layers invoke services from lower layers using static,
     well-defined interfaces.  In practice, deployed systems follow the
     Internet protocol suite as shown in Figure 1, commonly represented by
     Application, Transport, Internet, and Link/Access and physical
     layers.  Nevertheless, the layered abstraction remains a useful
     conceptual baseline for discussing where automation and closed-loop
     decision functions are inserted.

                +------------------+
                |   Application    |
                +------------------+
                |    Transport     |
                +------------------+
                |     Internet     |
                +------------------+
                |   Link / Access  |
                +------------------+
                |     Physical     |
                +------------------+

              Figure 1: IP Suite Layered Stack

  4.  Proposed Agentic Augmentation at to Layered Approach

     The proposed approach is hybrid: the deterministic layered protocol
     stack remains the baseline for interoperability and packet transport,
     while agentic functions are introduced alongside each layer.

     In the proposed architecture, each layer contains:

     *  An Agent Net that can interpret intents relevant to that layer,
        gather context (telemetry/state), reason, propose actions, and
        execute actions through the layer's tools.  Agent Net may have one
        or more AIAs for different purposes within in the layer.  For
        example, a layer may have different agents for congestion control,
        QoS adaptation, policy and compliance and intent-parsing.

     *  An agent controller or simply controller manages task
        decomposition, assignment, guardrails and governance.  A
        controller may or may not be an AIA.

     The proposed model targets a "structured autonomy" property:
     autonomous actions are possible, but are constrained through explicit
     reference points, policies, authentication/authorization, and
     auditable workflows.



  Jadoon, et al.          Expires 3 September 2026                [Page 4]


  Internet-Draft             Agentic-AI-Arch-ACN                March 2026


  4.1.  5.1.  Per-Layer Agent Nets and Per-Layer Controllers

     In this option, each layer has its own Agent Net and its own
     controller.  This aligns with operational decomposition (e.g.,
     separate ownership or tooling per layer), and supports scaling and
     fault isolation.

     Figure 2a illustrates the concept.

       +------------------+    +-------------------------+    +---------------------+
       |   Application    |<-->|  Agent Net (App)        |<-->|  Controller (App)   |
       +------------------+    +-------------------------+    +---------------------+
       |    Transport     |<-->|  Agent Net (Transport)  |<-->|  Controller (Trans) |
       +------------------+    +-------------------------+    +---------------------+
       |     Internet     |<-->|  Agent Net (Internet)   |<-->|  Controller (Int)   |
       +------------------+    +-------------------------+    +---------------------+
       |  Link / Access   |<-->|  Agent Net (Link)       |<-->|  Controller (Link)  |
       +------------------+    +-------------------------+    +---------------------+
       |    Physical*     |<-->|  Agent Net (Phy)*       |<-->|  Controller (Link)* |
       +------------------+    +-------------------------+    +---------------------+

       Figure 2a: Proposed Stack with Per-Layer Agent Nets and Per-Layer Controllers

     The Physical layer is shown for completeness and includes data-link
     and access technologies.  Some aspects of access technologies may be
     outside IETF scope and would typically be accessed as external tools/
     controllers rather than specified by IETF protocols.

  4.2.  5.3.  Relationship to the Deterministic Stack

     The hybrid architecture is intended to preserve deterministic
     interoperability of the underlying stack:

     *  Deterministic inter-layer service interfaces (e.g., a transport
        service offered to applications) remain unchanged.

     *  AI Agents do not replace protocols; they invoke tools that already
        exist (or will be defined) to observe and actuate layer behavior.

     *  The architecture explicitly separates (a) packet transport and
        protocol interoperability, from (b) goal-driven automation logic.

     This separation is central to making agentic automation governable,
     testable, and incrementally deployable.







  Jadoon, et al.          Expires 3 September 2026                [Page 5]


  Internet-Draft             Agentic-AI-Arch-ACN                March 2026


  5.  Functional Workflow and Reference Points

  5.1.  6.1.  Controller and Agent Functional Blocks

     A generic agentic workflow can be represented by the following
     functional blocks:

     Controller:

     *  I/O Engine: handles intent/goal/request intake and output
        formatting.

     *  Discovery: finds relevant agents, tools and capabilities.

     *  Task Assignments: decomposes tasks and assigns them to agents
        (planning).

     AI Agent:

     *  Reasoning: interprets tasks, plans steps, and maintains context.

     *  Synthesis: composes intermediate results into coherent outputs.

     *  Execution: invokes tools and performs actions.

     *  Reinforcement: learns/adapts from feedback.

     *  Conflict Resolution: resolves competing proposals/actions among
        agents or across layers.

     Figure 3 illustrates this functional view and explicitly labels
     reference points that are candidates for interoperable definition.

  5.2.  6.2.  Reference Points (Interfaces)

     The following reference points are identified:

     C_I (Controller Input): Input request/goal interface into the
     controller.

     C_O (Controller Output): Output response (including action
     confirmation, explanation, or result summary) from the controller.

     C_E (Controller Execution Feedback): Interface for execution-related
     status and feedback flow between controller and agent reasoning
     context (e.g., progress, intermediate outcomes, updated constraints).





  Jadoon, et al.          Expires 3 September 2026                [Page 6]


  Internet-Draft             Agentic-AI-Arch-ACN                March 2026


     AIA_E (Agent Execution / Task Assignment): Task assignment and
     execution coordination between controller and AI Agent execution
     function.

     AIA_R (Inter-AI-Agent Reasoning/Context Exchange): Interface for AI
     Agents to exchange context, negotiate, and coordinate during
     reasoning and planning.

     AIA_CR (Inter-AI-Agent Conflict Resolution): Interface supporting
     detection, signaling, and resolution of conflicts among AI Agents
     (including conflicts spanning layers).








































  Jadoon, et al.          Expires 3 September 2026                [Page 7]


  Internet-Draft             Agentic-AI-Arch-ACN                March 2026


          +------------------+   C_I   +--------------------------------------+
          |   Input Request  |-------> |              Controller              |
          +------------------+         |                                      |
                                       |   +----------+   +----------+        |
          +------------------+   C_O   |   | I/O      |-->| Discovery |----+  |
          | Output Response  |<------- |   | Engine   |   +----------+    |   |
          +------------------+         |   +----------+                   |   |
                                       |        ^ C_E                     |   |
                                       |        |                         v   |
                                       |   +----------------+     +-----------+
                                       |   | Task           |     | Task      |
                                       |   | Assignments    |---->| Assignment|
                                       |   +----------------+     +-----------+
                                       +----------------------------------|---+
                                                                          |
                                                                         AIA_E
                                                                          |
                                       +----------------------------------v---+
                                       |                 AI Agent              |
                                       |                                       |
                                       |   +-----------+    +-----------+      |
                         AIA_R  <----> |   | Reasoning |<-->| Synthesis  |      |
                                       |   +-----------+    +-----------+      |
                                       |        ^                 ^            |
                                       |        |                 |            |
                                       |   +------------------+   |            |
                         AIA_CR <----> |   | Conflict          |---+            |
                                       |   | Resolution        |                |
                                       |   +------------------+                |
                                       |                                       |
                                       |   +-----------+    +----------------+ |
                                       |   | Execution |<-->| Reinforcement  | |
                                       |   +-----------+    +----------------+ |
                                       |           |                           |
                                       |           v                           |
                                       |        Tools / Controllers            |
                                       +---------------------------------------+

            Figure 3: Functional Workflow of Agentic AI Systems with Reference Points (Conceptual)

     The intent is not to prescribe a single protocol, but to establish
     common reference points so that multiple protocol proposals (e.g.,
     agent-to-agent, agent discovery, tool invocation) can be evaluated
     against a consistent architectural model.







  Jadoon, et al.          Expires 3 September 2026                [Page 8]


  Internet-Draft             Agentic-AI-Arch-ACN                March 2026


     In this document, the term "CX interface" refers to the controller
     external interfaces (primarily C_I and C_O), and the term "AIAX
     interfaces" refers to the agent-related interfaces (C_E, AIA_E,
     AIA_R, AIA_CR) shown above.

  6.  Challenges Motivating Interoperable Work

     This section summarizes key challenges observed in multi-layer,
     multi-agent deployments that motivate IETF discussion:

     *  *Lack of a common way for AIAs to identify and reach each other*:
        Agents operate at different technical layers and environments.
        There is no consistent way to name, locate, and address agents
        across networks and platforms.  This may results in fragile
        interoperability, high integration cost, and limited scaling in
        multi-vendor environments.

     *  *Limited service discoverability and failure signaling for AIAs*:
        Agents need to discover other agents, determine if a service
        exists, and understand why communication failed.  This may result
        in silent failures, unbounded retries, incorrect decisions from
        incomplete information, and reduced trust in automation.

     *  *Insufficient data provisioning for training and adaptation*:
        Agents need data not only for initial training but also during
        operation or for updates.  Agents need consistent approaches for
        accessing additional data and exchanging learning-relevant
        information in consistent formats.

     *  *Distributed security token and access control management*:
        Agents require credentials to prove identity, access resources,
        and act on behalf of users/systems.  Token creation, scoping,
        renewal, and revocation are not unified across agent types and
        layers, complicating audit and compliance.

     These challenges are compounded by multi-domain operation, different
     trust boundaries, and heterogeneous tooling.

  7.  Security, Safety, Determinism, and Accountability Considerations

     Agentic AI systems introduce architectural risks beyond those
     associated with traditional automation or centralized controllers.

     *  *Sustainability*:
        Continuous inference, multi-agent coordination, and expanded
        telemetry exchange may increase energy consumption and management-
        plane load.  Architectural mechanisms prefer bounding control-
        plane amplification and computational overhead.



  Jadoon, et al.          Expires 3 September 2026                [Page 9]


  Internet-Draft             Agentic-AI-Arch-ACN                March 2026


     *  *Security*:
        Agentic systems expand the attack surface through:

        -  Tool invocation chains that can enable privilege escalation.

        -  Cross-agent coordination interfaces that can propagate
           compromise.

        -  Persistent memory and context that can be subject to poisoning.

        -  Model-driven reasoning that can be influenced by malicious or
           malformed inputs.

        Compromise of a single agent can have cascading impact across
        layers if coordination boundaries are not explicitly constrained.

     *  *Deterministic Guardrails*:
        Networking environments require bounded and predictable behavior.
        Agentic augmentation is intended to preserve deterministic
        protocol invariants and stability properties of the underlying
        stack.  Guardrail mechanisms can include:

        -  Policy-constrained action spaces.

        -  Pre-execution validation against safety envelopes.

        -  Transactional rollback and state checkpointing.

        -  Rate-limited reconfiguration to prevent oscillation.

        -  Deterministic conflict resolution hierarchies.

        -  Human override and escalation triggers.

        These mechanisms ensure that autonomy remains structured and does
        not undermine protocol correctness or service guarantees.

     *  *Accountability*:
        Autonomous decisions are expected to be traceable to inputs,
        policies, and authorization context.  Auditable execution logs and
        explainability hooks are required to support compliance,
        debugging, and operational trust.

     This document does not define specific mechanisms but asserts that
     structured autonomy and deterministic safety envelopes are
     foundational architectural requirements for agentic networking.





  Jadoon, et al.          Expires 3 September 2026               [Page 10]


  Internet-Draft             Agentic-AI-Arch-ACN                March 2026


  8.  Relationship to Existing IETF/IRTF Work

     This document is complementary to multiple ongoing efforts in the
     IETF and IRTF that touch on autonomic networking, AI agents for
     network management, and agent communication.  These efforts can be
     used as inputs when refining protocols that realize the reference
     points in this draft.

  9.  Recommendations and Next Steps for IETF Discussion

     The following near-term discussion items are proposed:

     1.  Discuss an agree on the terminology for the agentic AI
         architecture

     2.  Orchestration reference framework and reference points: Refine
         the CX and AIAX reference points and their semantics.  Determine
         what "minimum interoperability" means for each reference point in
         a multi-vendor environment.

     3.  Agent registration, discovery, and lifecycle: Identify
         interoperable mechanisms for agent discovery and capability
         advertisement, including failure signaling and versioning.

     4.  Security tokens, authorization, and auditability: Identify how
         agents authenticate, obtain scoped authorization, and produce
         auditable action traces when acting on network state.

     5.  Layer-by-layer automation building blocks: Use the architecture
         to guide follow-on documents that focus on automation and closed-
         loop control within specific layers (e.g., routing layer,
         transport layer, service layer), without conflating those with
         the inter-agent interface problem.

  10.  IANA Considerations

     TBD

  11.  Acknowledgements

     TBD

  12.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", RFC 2119 , 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.




  Jadoon, et al.          Expires 3 September 2026               [Page 11]


  Internet-Draft             Agentic-AI-Arch-ACN                March 2026


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

  Authors' Addresses

     Muhammad Awais Jadoon
     InterDigital Europe Ltd
     London
     United Kingdom
     Email: muhammad.awaisjadoon@interdigital.com


     Sebastian Robitzsch
     InterDigital Europe Ltd
     London
     United Kingdom
     Email: sebastian.robitzsch@interdigital.com


     Carlos J. Bernardos
     Universidad Carlos III de Madrid
     Madrid
     Spain
     Email: cjbc@it.uc3m.es


























  Jadoon, et al.          Expires 3 September 2026               [Page 12]


