# drafts

name: draft-jeong-opsawg-intent-based-sdv-framework
rev: 04
time: 2025-12-12T07:09:00Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2025-12-12T05:16:01Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.026286+00:00
source: ietf
title:
  An Intent-Based Management Framework for Software-Defined Vehicles in Intelligent Transportation Systems

abstract:
  Software-Defined Vehicle (SDV) is a new player towards autonomous
     vehicles in Intelligent Transportation Systems (ITS).  An SDV is
     constructed by a software platform like a cloud-native system (e.g.,
     Kubernetes) and has its internal network.  To facilitate the easy and
     efficient configuration of networks in the SDV, an intent-based
     management is an appropriate direction.  This document proposes a
     framework of intent-based management for networks, security, and
     applications in SDVs so that they can communicate with other SDVs and
     infrastructure nodes for safe driving and infotainment services in
     the road networks.

full_text:
  Operations and Management Area Working Group               J. Jeong, Ed.
  Internet-Draft                                                   Y. Shen
  Intended status: Informational                                    Y. Ahn
  Expires: 11 December 2025                                          M. Gu
                                                   Sungkyunkwan University
                                                               9 June 2025


   An Intent-Based Management Framework for Software-Defined Vehicles in
                     Intelligent Transportation Systems
              draft-jeong-opsawg-intent-based-sdv-framework-04

  Abstract

     Software-Defined Vehicle (SDV) is a new player towards autonomous
     vehicles in Intelligent Transportation Systems (ITS).  An SDV is
     constructed by a software platform like a cloud-native system (e.g.,
     Kubernetes) and has its internal network.  To facilitate the easy and
     efficient configuration of networks in the SDV, an intent-based
     management is an appropriate direction.  This document proposes a
     framework of intent-based management for networks, security, and
     applications in SDVs so that they can communicate with other SDVs and
     infrastructure nodes for safe driving and infotainment services in
     the road networks.

  Status of This Memo

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

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 11 December 2025.

  Copyright Notice

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





  Jeong, et al.           Expires 11 December 2025                [Page 1]


  Internet-Draft        An Intent-Based SDV Framework            June 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 . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Intent-Based Management Framework for Software-Defined
             Vehicles  . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Life Cycle of an IBS for SDV Management . . . . . . . . .   6
       3.2.  V2V and V2I Networking for SDVs . . . . . . . . . . . . .   7
       3.3.  Intent-Based Management Framework for SDVs  . . . . . . .   9
       3.4.  Interfaces in the SDV Management Framework  . . . . . . .  12
     4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
       6.2.  Informative References  . . . . . . . . . . . . . . . . .  14
     Appendix A.  Changes from
             draft-jeong-opsawg-intent-based-sdv-framework-03  . . . .  18
     Appendix B.  Acknowledgments  . . . . . . . . . . . . . . . . . .  18
     Appendix C.  Contributors . . . . . . . . . . . . . . . . . . . .  18
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

  1.  Introduction

     The network management has been evolving dramatically from manual
     configuration to advanced automatic management.  This evolution leads
     to the intent-based network (IBN) management and automation
     [RFC9315], which has been driven by several factors, including
     complexity of networks, scale, cost and efficiency, dynamic
     environments, service delivery, and security [Survey-IBN-CST-2023].
     Apart from network management and automation, the automotive industry
     is also witnessing a fundamental transformation, particularly with
     the advent of software-defined vehicles (SDVs).  SDVs leverage
     powerful onboard high-performance computers (HPCs) and a high-speed
     network backbone, typically Ethernet-based Internet Protocol (IP)
     network [Survey-IPVehNet-2021], to enable flexible and dynamic
     allocation of functions and resources.  Shifting to SDVs is also a
     new paradigm in Intelligent Transportation Systems (ITS).  The SDVs
     can interact with each other via Vehicle-to-Vehicle (V2V)
     communications and infrastructure via Vehicle-to-Infrastructure (V2I)



  Jeong, et al.           Expires 11 December 2025                [Page 2]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


     communications (e.g., edge servers) for safe driving and infotainment
     services.  Figure 1 shows an architecture of vehicular networks for
     SDVs that are grouped into multiple subnets.  They can communicate
     with edge servers and vehicular cloud by IP Road-Side Unit (IP-RSUs,
     e.g., gNodeB in 5G [TS-23.501]).

                                Vehicular Cloud
                 *******************************************
               *                                             *
              *              +------------------+             *
             *               | Cloud Controller |              *
             *               +------------------+              *
             *                         ^                       *
              *                        |                      *
               *                       v                     *
                 *******************************************
                   ^ +------------+   ^ +------------+   ^ +------------+
                   | |Edge-Server1|   | |Edge-Server2|   | |Edge-Server3|
                   | +------------+   | +------------+   | +------------+
                   |   ^              |   ^              |   ^
                   |   |              |   |              |   |
                   v   V              v   V              v   V
                 +---------+         +---------+        +---------+
                 | IP-RSU1 |<------->| IP-RSU2 |<------>| IP-RSU3 |
                 +---------+         +---------+        +---------+
                      ^                   ^                    ^
                      :                   :                    :
             +-----------------+ +-----------------+   +-----------------+
             |        : V2I    | |        : V2I    |   |       : V2I     |
             |        v        | |        v        |   |       v         |
  +--------+ |   +--------+    | |   +--------+    |   |   +--------+    |
  |  SDV1  |===> |  SDV2  |===>| |   |  SDV3  |===>|   |   |  SDV4  |===>|
  +--------+<...>+--------+<........>+--------+    |   |   +--------+    |
             V2V     ^         V2V        ^        |   |        ^        |
             |       : V2V     | |        : V2V    |   |        : V2V    |
             |       v         | |        v        |   |        v        |
             |  +--------+     | |   +--------+    |   |    +--------+   |
             |  |  SDV5  |===> | |   |  SDV6  |===>|   |    |  SDV7  |==>|
             |  +--------+     | |   +--------+    |   |    +--------+   |
             +-----------------+ +-----------------+   +-----------------+
                   Subnet1              Subnet2              Subnet3
                  (Prefix1)            (Prefix2)            (Prefix3)

          <----> Wired Link   <....> Wireless Link   ===> Moving Direction

        Figure 1: Vehicular Networks for Software-Defined Vehicles





  Jeong, et al.           Expires 11 December 2025                [Page 3]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


     To facilitate the development of SDVs, a large number of automotive
     companies and original equipment manufacturers (OEMs) are developing
     the components of SDVs based on different open architectures, such as
     AUTOSAR [AUTOSAR-SDV] and Eclipse SDV [Eclipse-SDV].  An SDV can
     include many electronic control units (ECUs) and hundreds of sensors
     and actuators for in-vehicle functions and services, e.g., advanced
     driver-assistance systems (ADAS), automatic emergency braking (AEB),
     forward collision warning (FCW), and lane keeping assist (LKA)
     applications.  They can also run multiple computing devices,
     operating systems, and a cloud-native platform (e.g., Kubernetes
     [Kubernetes]) to manage those ECUs and functions.  The Connected
     Vehicle System Alliance (COVESA) [COVESA] has developed a common
     vehicle signal specification (VSS) to represent the vehicle data to
     be shared for both in-vehicle and vehicle-to-cloud networks.
     Figure 2 shows a vehicular platform for SDV having foundation
     hardwares, a virtualization engine (i.e., Hypervisor), different
     operating systems (OS), various applications and network functions
     (such as NF-1 to NF-x) along with their runtime and management agent.

   +--------------------------------+  +---------------------------------+
   |            Apps                |  |          Functions              |
   | +------+  +------+  +-------+  |  | +------+  +------+     +------+ |
   | | ADAS |  |  LKA |  |  AEB  |  |  | | NF-1 |  | NF-2 | ... | NF-x | |
   | +------+  +------+  +-------+  |  | +------+  +------+     +------+ |
   +--------------------------------+  +---------------------------------+
   +-------------+  +--------------+  +-------------------+--------------+
   |Critical Apps|  |Classical Apps|  | Container Runtime |  Mgmt Agent  |
   +-------------+  +--------------+  +-------------------+--------------+
   +-----------------+   +-------------------+   +-----------------------+
   |                 |   |   Vehicle OS I    |   |     Vehicle OS II     |
   |    Real-Time    |   +-------------------+   +-----------------------+
   |       OS        |   +-----------------------------------------------+
   |                 |   |                    Hypervisor                 |
   +-----------------+   +-----------------------------------------------+
   +---------------------------------------------------------------------+
   |                    Vehicle Electric/Electronics                     |
   |  +------------------+  +------------------+  +------------------+   |
   |  |   Vehicle ECUs   |  |   Vehicle HPC    |  | Sensors/Actuators|   |
   |  +------------------+  +------------------+  +------------------+   |
   +---------------------------------------------------------------------+

                   Figure 2: A Vehicular Platform for SDV

     To manage the ever-growing network functions and applications in
     SDVs, SDVs need an intent-based management framework for networks and
     security inside their in-vehicle networks.  An intent is a
     declarative command to request a configuration for a network or
     security function [TS-28.312][TR-28.812].  It emphasizes more on



  Jeong, et al.           Expires 11 December 2025                [Page 4]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


     "What" is needed (i.e., declarative command) to be accomplished than
     "How" it should be accomplished (i.e., imperative command).  Since
     there are a huge number of vehicles produced by each automotive
     company, the networks and security for the SDV need to be remotely
     configured and monitored by a control center of each automotive
     company.  The in-vehicle networks are based on Gigabit Ethernet and
     can be configured as multiple subnets including ECUs and infotainment
     devices.  It requires huge overhead for an operator to configure and
     monitor networks and security for those in-vehicle networks.

     This document proposes a framework of intent-based management for
     networks, security, and applications in SDVs that are Service
     Functions (SFs).  Such SFs can be constructed and managed by
     Software-Defined Networking (SDN) [RFC7149], Network Functions
     Virtualization (NFV) [ETSI-NFV][ETSI-NFV-Release-2], and Cloud Native
     Computing Platform (e.g., Kubernetes [Kubernetes]).  This framework
     automates the configuration and monitoring for the networks and
     security in each SDV through a vehicular cloud and the SDV's mobile
     network.  An SDV User (i.e., administrator) for the management of
     SDVs can configure and monitor the networks and security through an
     intent.  The intent from the SDV User is delivered to a Cloud
     Controller in charge of a vehicular cloud for SDVs.  The Cloud
     Controller translates the intent into the corresponding high-level
     policy, and delivers the high-level policy to an SDV Controller in
     charge of an SDV.  The SDV translates the high-level policy into the
     corresponding low-level policy and delivered it to an appropriate
     Network Function (NF) for a specific service (e.g., router, firewall,
     and navigator) in the SDV.

  2.  Terminology

     This document uses the terminology described in [RFC8329],
     [I-D.ietf-i2nsf-applicability],
     [I-D.jeong-opsawg-security-management-automation],
     [I-D.jeong-nmrg-ibn-network-management-automation], and [SPT].  In
     addition, the following terms are defined below:

     *  Intent: A set of operational goals (that a network should meet)
        and outcomes (that a network is supposed to deliver) defined in a
        declarative manner without specifying how to achieve or implement
        them [RFC9315].

     *  Intent-Based Management (IBM): It enforces an intent from a user
        (or administrator) into a target system (e.g., SDV).  An intent
        can be expressed as a Natural Language (e.g., English) and can be
        translated into a high-level policy by a Natural Language
        Processing (NLP) [USENIX-ATC-Lumi][BERT] [Deep-Learning].  In this
        document, the intent can be translated into the corresponding



  Jeong, et al.           Expires 11 December 2025                [Page 5]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


        high-level policy by an intent translator
        [I-D.jeong-opsawg-security-management-automation].  The high-level
        policy can also be translated into the corresponding low-level
        policy by a policy translator [SPT].  The low-level policy is
        dispatched to appropriate Service Functions (SFs).  Through the
        monitoring of the SFs, the activity and performance of the SFs is
        monitored and analyzed.  If needed, the rules of the high-level or
        low-level network policy are augmented or new rules are generated
        and configured to appropriate SFs.

  3.  Intent-Based Management Framework for Software-Defined Vehicles

     This section introduces the intent-based management framework for
     SDVs.  It first describes the life cycle of an intent-based system
     (IBS) for SDV management.  Then, it discusses the V2V and V2I
     networking in the framework.  Eventually, the components and
     interfaces of the framework are explained.

  3.1.  Life Cycle of an IBS for SDV Management

     According to the life cycle design of IBN [RFC9315], Figure 3 shows
     the life cycle of an intent-based system (IBS) for SDV management.
     It divides the life cycle into three spaces, namely SDV User Space,
     Translation & IBS Space, and Network Operations (Ops) & Application
     (App) Space.  Each space is further divided into two sections,
     fulfillment and assurance.  The fulfillment section pipelines the
     steps (i.e., intent input, translation/refinement, learning/planning/
     rendering, and configuration/provisioning) toward the final SFs such
     as network functions (NFs) and applications in SDVs.  The assurance
     section monitors final results of the intent fulfillment to validate
     and analyze the resulted NFs and applications for SDVs.




















  Jeong, et al.           Expires 11 December 2025                [Page 6]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


          SDV User      :            Translation/          : Network Ops/
           Space        :             IBS Space            :  App Space
   Fulfill              :                                  :
          +----------+  :  +------------+   +------------+ : +-----------+
          |Recognize/|---->| Translate/ |-->|   Learn/   |-->| Configure/|
          | Generate |  :  |   Refine   |   |   Plan/    | : | Provision |
          | Intent   |<----|            |   |   Render   | : |           |
          +----------+  :  +------------+   +------------+ : +-----------+
               ^        :                         ^        :       |
   ............|..................................|................|.....
               |        :                    +----------+  :       v
               |        :                    | Validate |  :  +----------+
               |        :                    +----^-----+<----| Monitor/ |
   Assure      |        :                         |        :  | Observe  |
           +--------+   :  +----------+      +----------+<----|          |
           | Report |<-----| Abstract |<-----| Analyze/ |  :  +----------+
           +--------+   :  +----------+      | Aggregate|  :
                        :                    +----------+  :


             Figure 3: The Life Cycle of IBS for SDV Management

  3.2.  V2V and V2I Networking for SDVs

     Benefited from V2V and V2I networking, SDVs can be managed and
     monitored by the vehicular cloud.  Figure 4 shows an example of V2V
     communications between two SDVs having their internal SFs.  An SDV
     has its own internal networks (called in-vehicle networks), which
     consist of multiple subnets connected with each other through
     routers.  The SDV can communicate with other SDVs via the interface
     from an IP-based on-board unit (IP-OBU).  IP-OBU is a network device
     in an SDV that has a basic processing ability and can be driven by a
     low-power CPU (e.g., ARM) with a 5G Vehicle-to-Everything (V2X)
     communication device [RFC9365].  By the IP-OBU interface, the
     internal SFs of the SDV can also communicate with that of other SDVs.
     In this way, the internal SFs can be flexibly managed and controlled
     through V2V networking.














  Jeong, et al.           Expires 11 December 2025                [Page 7]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


                             (*)<........>(*)
          (2001:db8:1:1::/64) |            | (2001:db8:1:2::/64)
     +------------------------|-----+  +---|-----------------------------+
     |                        v     |  |   v                             |
     | +---------+        +-------+ |  | +-------+         +---------+   |
     | |Navigator|        |IP-OBU1| |  | |IP-OBU2|         |Navigator|   |
     | +---------+        +-------+ |  | +-------+         +---------+   |
     |     ^                  ^     |  |     ^                  ^        |
     |     |                  |     |  |     |                  |        |
     |     v                  v     |  |     v                  v        |
     | ---------------------------- |  | ------------------------------- |
     | 2001:db8:10:1::/64 ^         |  |     ^ 2001:db8:20:1::/64        |
     |                    |         |  |     |                           |
     |                    v         |  |     v                           |
     | +---------+    +-------+     |  | +--------+ +-------+   +-------+|
     | |Firewall |    |Router1|     |  | |Firewall| |Router1|...|Router2||
     | +---------+    +-------+     |  | +--------+ +-------+   +-------+|
     |     ^              ^         |  |     ^         ^           ^     |
     |     |              |         |  |     |         |           |     |
     |     v              v         |  |     v         v           v     |
     | ---------------------------- |  | ------------------------------- |
     |      2001:db8:10:2::/64      |  |       2001:db8:20:2::/64        |
     +------------------------------+  +---------------------------------+
          SDV1 (Mobile Network1)              SDV2 (Mobile Network2)

        <----> Wired Link   <....> Wireless Link   (*) Antenna

                            Figure 4: V2V Networking

     SDVs can receive software updates as well as the configuration of
     their networks and security from the vehicular cloud.  As shown in
     Figure 1, SDVs as vehicles can communicate with each other via V2V
     and with infrastructure nodes such as IP-RSU via V2I, for example,
     gNodeB in 5G networks, respectively.  Figure 5 illustrates the V2I
     networking with edge and cloud networks for SDVs.  An Edge Network
     (EN) is a radio access network which has an IP-RSU for wireless
     communication with other SDVs having an IP-OBU and wired
     communication with other network devices (e.g., routers, IP-RSUs, and
     edge servers) [RFC9365].  The IP-RSU is a network device situated
     along the road as an infrastructure node.  It has at least two
     distinct IP-enabled interfaces where one is for 5G V2X and the other
     is for the wired network connected to the vehicular cloud [RFC9365].
     As shown in Figure 5, the IPv6 prefixes should be configured for both
     the in-vehicle network (also called mobile network) and EN.  Also,
     for V2X IP networking, the wireless interfaces of IP-OBU and IP-RSU
     should be configured with appropriate IPv6 network prefixes and
     default gateways towards the infrastructure network connected to the
     vehicular cloud.  An edge server in EN (e.g., Server1 inside EN1



  Jeong, et al.           Expires 11 December 2025                [Page 8]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


     shown in Figure 5) can help SDVs to perform their safe driving
     functions by processing environmental data collected by the SDVs and
     giving maneuver guidance to the SDVs.

                                                      +-----------------+
                             (*)<........>(*)  +----->| Vehicular Cloud |
          (2001:db8:1:1::/64) |            |   |      +-----------------+
     +------------------------|-----+  +---|---|-------------------------+
     |                        v     |  |   v   v                         |
     | +---------+        +-------+ |  | +-------+         +---------+   |
     | |Navigator|        |IP-OBU1| |  | |IP-RSU1|         |Navigator|   |
     | +---------+        +-------+ |  | +-------+         +---------+   |
     |     ^                  ^     |  |     ^                  ^        |
     |     |                  |     |  |     |                  |        |
     |     v                  v     |  |     v                  v        |
     | ---------------------------- |  | ------------------------------- |
     | 2001:db8:10:1::/64 ^         |  |     ^ 2001:db8:20:1::/64        |
     |                    |         |  |     |                           |
     |                    v         |  |     v                           |
     | +---------+    +-------+     |  | +-------+ +-------+   +-------+ |
     | |Firewall |    |Router1|     |  | |Router2| |Server1|...|ServerN| |
     | +---------+    +-------+     |  | +-------+ +-------+   +-------+ |
     |     ^              ^         |  |     ^         ^           ^     |
     |     |              |         |  |     |         |           |     |
     |     v              v         |  |     v         v           v     |
     | ---------------------------- |  | ------------------------------- |
     |      2001:db8:10:2::/64      |  |       2001:db8:20:2::/64        |
     +------------------------------+  +---------------------------------+
          SDV1 (Mobile Network1)              EN1 (Fixed Network1)

        <----> Wired Link   <....> Wireless Link   (*) Antenna

             Figure 5: V2I Networking with Edge and Cloud Networks

  3.3.  Intent-Based Management Framework for SDVs

     For the automatic network configuration of SDVs, an intent-based
     management is required between the vehicular cloud and SDVs
     [I-D.jeong-nmrg-ibn-network-management-automation].  Figure 6 shows a
     framework of intent-based management for SDVs.  The framework
     consists of a vehicular cloud and SDVs.


                           <Vehicular Cloud (VC)>
   +---------------------------------------------------------------------+
   | +------------------+                      +--------------------+    |
   | |     SDV User     |          +---------->|    SDV Database    |    |
   | +------------------+          |           +--------------------+    |



  Jeong, et al.           Expires 11 December 2025                [Page 9]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


   |          ^                    |                     ^               |
   |          |                    | Database            | Database      |
   |          |                    | Interface           | Interface     |
   |          | Consumer-Facing    |                     V               |
   |          | Interface (Intent) |           +--------------------+    |
   |          |                    | +-------->|    Cloud Analyzer  |<-+ |
   |          |                    | |         +--------------------+  | |
   |          V                    | |Analytics                        | |
   | +------------------+<---------+ |Interface                        | |
   | | Cloud Controller |<-----------+         +--------------------+  | |
   | +------------------+<-------------------->|Vendor's Mgmt System|  | |
   |          ^         Registration Interface +--------------------+  | |
   |          |                                          ^             | |
   +----------|------------------------------------------|-------------|-+
              | Controller-Facing Interface   VMS-Facing |   Analyzer- |
              |     (High-level Policy)        Interface |   Facing    |
              |                                          |   Interface |
   +----------|------------------------------------------|-------------|-+
   |          |                                          |             | |
   |          v                                          v             | |
   | +------------------+     Registration     +--------------------+  | |
   | |  SDV Controller  |<-------------------->|    SDV Vendor's    |  | |
   | +------------------+      Interface       |    Mgmt System     |  | |
   |          ^      ^                         +--------------------+  | |
   |          |      |                                                 | |
   |          |      |                                                 | |
   |          |      |   Analytics Interface   +--------------------+  | |
   |          |      +------------------------>|    SDV Analyzer    |<-+ |
   |          |                                +--------------------+    |
   |          | SF-Facing Interface                      ^               |
   |          |  (Low-level Policy)                      |               |
   |          |                                          |               |
   |          |                                          |               |
   |          |    +--------------+----------------------+---+           |
   |          |    |              |   Monitoring Interface   |           |
   |          v    v              v                          v           |
   |   +---------------+  +---------------+        +---------------+     |
   |   |     SF-1      |  |     SF-2      |........|     SF-n      |     |
   |   |   (Router)    |  |  (Firewall)   |        |  (Navigator)  |     |
   |   +---------------+  +---------------+        +---------------+     |
   +---------------------------------------------------------------------+
                     <Software-Defined Vehicle (SDV)>

      Figure 6: Intent-Based Management Framework for Software-Defined
                                  Vehicles






  Jeong, et al.           Expires 11 December 2025               [Page 10]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


     The vehicular cloud consists of SDV User (as network administrator),
     Cloud Controller (as an orchestrator for a vehicular cloud), SDV
     Database (as a main repository for SDV management and monitoring),
     and Cloud Analyzer (as a monitoring data analyzer for SDVs) such as
     Network Data Analytics Function (NWDAF) in 5G networks
     [TS-23.288][TS-29.520].

     *  SDV User: It is the software (e.g., web-browser-based user
        interface) used by SDV administrators to deliver network intents
        to SDV controllers.  In the 3GPP intent driven management service
        document, it is assumed that network intent is configured by the
        intent data model.

     *  Cloud Controller: It is a component that controls and manages
        other system components of the vehicular cloud.  From a security
        point of view, a security service policy can be transmitted to the
        service function (SF) by converting the SDV User's security
        service intent into the corresponding security service policy and
        selecting an SF that provides an appropriate security service.

     *  Cloud Vendor's Management System: It is a component that provides
        images of virtualized SFs for vehicular cloud services and
        registers the SFs and access information with Cloud Controller.

     *  Cloud Analyzer: It gathers and evaluates monitoring data from SDV
        Analyzers to ensure the functionality and performance of SFs,
        e.g., the network data analytics function (NWDAF) in 5G networks.

     *  SDV Database: It is a database for managing SDVs, including
        network and security configuration information of SDVs, current
        location and navigation path of SDVs, etc.

     An IBS in SDV is composed of SDV Controller (as a manager for an
     SDV), SDV Analyzer (as a monitoring data analyzer for an SDV)
     [I-D.jeong-nmrg-ibn-network-management-automation], Vendor's
     Management System (as a vendor system to provide cloud-native
     containers) [RFC8329][I-D.ietf-i2nsf-applicability], and Service
     Functions such as NFs ( e.g., router, DNS server, firewall
     [I-D.jeong-nmrg-ibn-network-management-automation]) and applications
     (e.g., safe driver and navigator).  The functions of each component
     is described as follows.

     *  SDV Controller: It is a component that controls and manages other
        components of the SDV framework.  It translates the high-level
        policy received from the Cloud Controller into a low-level policy
        that the SF can understand.  An SF to perform this low-level
        service policy is selected, and the policy is transmitted to the
        SF.



  Jeong, et al.           Expires 11 December 2025               [Page 11]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


     *  SDV Vendor's Management System: It is a component that provides an
        image of a virtualized SF for SDV services to the SDV framework
        and registers the function and access information of the SF with
        SDV Controller.

     *  Service Function (SF): It is a component that refers to a virtual
        network function (VNF), cloud native network function (CNF), or
        physical network function (PNF) for a specific service.  For
        security services, it provides security services such as
        firewalls, web filters, DDoS attack mitigators, and anti-viruses.
        In addition, networks and application services can also operate as
        SFs.

     *  SDV Analyzer: It is a component that collects monitoring data from
        SFs of SDVs and analyzes these data to confirm the activity and
        performance of SFs.  SDV Analyzer acts as NWDAF in a 5G network.
        If there are problems (e.g., security attacks, traffic congestion,
        QoS degradation) in the SDV internal network, SDV Analyzer
        delivers either policy reconfiguration or feedback information to
        SDV Controller for security and network troubleshooting.

  3.4.  Interfaces in the SDV Management Framework

     Together with the designed SDV management framework, in Figure 6,
     interfaces are also defined between a pair of system components in
     the vehicular cloud and SDV, respectively.  These interfaces include

     *  Consumer-Facing Interface: It is an interface between SDV User and
        Cloud Controller for conveying intents.

     *  Controller-Facing Interface: It is an interface between Cloud
        Controller and SDV Controller for high-level policy delivery with
        translated intents.

     *  SF-Facing Interface: It is an interface between SDV Controller and
        SF for the delivery of a translated lower-level policy.

     *  Registration Interface: It is an interface used to transfer SF
        capabilities and access information for registration to either
        Cloud Controller or SDV Controller, or deliver SF queries for
        searching the requested SFs.  This interface can be an interface
        between Cloud Controller and Cloud Vendor's Management System
        (Cloud VMS), or between SDV Controller and SDV Vendor's Management
        System (SDV VMS).

     *  Monitoring Interface: It is an interface between the SF and the
        SDV Analyzer used to collect the SF's monitoring data to identify
        SF-related security, system, and network issues.



  Jeong, et al.           Expires 11 December 2025               [Page 12]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


     *  Analytics Interface: It is an interface for delivering policy
        reconfiguration or feedback as a result of analyzing SF monitoring
        data.  This interface is an interface between SDV Analyzer and SDV
        Controller, between SDV Analyzer and Cloud Analyzer, or between
        Cloud Analyzer and Cloud Controller.

     *  Analyzer-Facing Interface: It is an interface between SDV Analyzer
        and Cloud Analyzer for the exchange of security, network, and
        system-related analysis of SFs.

     *  VMS-Facing Interface: It is an interface between Cloud VMS and SDV
        VMS to exchange SF container images with SF feature information.

     *  Database Interface: It is an interface for exchanging data in an
        SDV database.  It is an interface between SDV Database and Cloud
        Controller, or between SDV Database and Cloud Analyzer.

     The intent, high-level policy, and low-level policy can be either XML
     documents [RFC6020][RFC7950] or YAML documents [YAML].  They can be
     delivered to the destination components via NETCONF [RFC6241],
     RESTCONF [RFC8040], or REST API [REST].

     As shown in Figure 6, the Intent-Based Management SDV Framework
     enforces an intent from an SDV User, which as a user (or
     administrator), into a target system such as SDV.  The intent from
     the SDV User can be translated into the corresponding high-level
     policy by an intent translator in the Cloud Controller of the
     Vehicular Cloud [I-D.jeong-opsawg-security-management-automation].
     The high-level policy can also be translated into the corresponding
     low-level policy by a policy translator in the SDV Controller of the
     SDV [SPT].  The low-level policy is dispatched from the SDV
     Controller to appropriate Service Functions (SFs) in the SDV, such as
     Router, Firewall, and Navigator, as shown in the figure.  Through the
     monitoring of the SFs, the activity and performance of the SFs in the
     SDV is monitored and analyzed by the SDV Analyzer in the SDV.  If
     needed, the rules of the high-level or low-level network policy can
     be augmented by the SDV Analyzer.  Also, new rules can be
     automatically generated and configured to appropriate SFs by the SDV
     Analyzer.

     Therefore, this document proposes a framework of intent-based
     management for networks in Software-Defined Vehicles.  Through this
     intent-based management, the SFs in SDVs can be better managed and
     configured.  Base on the proposed framework, both virtualized network
     functions and applications can be efficiently orchestrated for agile
     network resource re-configurations and flexible SDV application
     updates.




  Jeong, et al.           Expires 11 December 2025               [Page 13]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


  4.  IANA Considerations

     This document does not require any IANA actions.

  5.  Security Considerations

     The same security considerations for the Interface to Network
     Security Functions (I2NSF) Framework [RFC8329] are applicable to the
     intent-based management framework this document.

  6.  References

  6.1.  Normative References

     [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
                the Network Configuration Protocol (NETCONF)", RFC 6020,
                DOI 10.17487/RFC6020, October 2010,
                <https://www.rfc-editor.org/info/rfc6020>.

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

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

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

     [RFC8329]  Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
                Kumar, "Framework for Interface to Network Security
                Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
                <https://www.rfc-editor.org/info/rfc8329>.

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

     [RFC9365]  Jeong, J., Ed., "IPv6 Wireless Access in Vehicular
                Environments (IPWAVE): Problem Statement and Use Cases",
                RFC 9365, DOI 10.17487/RFC9365, March 2023,
                <https://www.rfc-editor.org/info/rfc9365>.

  6.2.  Informative References



  Jeong, et al.           Expires 11 December 2025               [Page 14]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


     [I-D.ietf-i2nsf-applicability]
                Jeong, J. P., Hyun, S., Ahn, T., Hares, S., and D. Lopez,
                "Applicability of Interfaces to Network Security Functions
                to Network-Based Security Services", Work in Progress,
                Internet-Draft, draft-ietf-i2nsf-applicability-19, 3 April
                2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
                i2nsf-applicability-19>.

     [I-D.jeong-opsawg-security-management-automation]
                Jeong, J. P., Lingga, P., Jung-Soo, J., Lopez, D., and S.
                Hares, "An I2NSF Framework for Security Management
                Automation in Cloud-Based Security Systems", Work in
                Progress, Internet-Draft, draft-jeong-opsawg-security-
                management-automation-01, 13 February 2025,
                <https://datatracker.ietf.org/doc/html/draft-jeong-opsawg-
                security-management-automation-01>.

     [I-D.jeong-nmrg-ibn-network-management-automation]
                Jeong, J. P., Ahn, Y., Gu, M., Kim, Y., and J. Park,
                "Intent-Based Network Management Automation in 5G
                Networks", Work in Progress, Internet-Draft, draft-jeong-
                nmrg-ibn-network-management-automation-06, 9 June 2025,
                <https://datatracker.ietf.org/doc/html/draft-jeong-nmrg-
                ibn-network-management-automation-06>.

     [SPT]      Lingga, P., Jeong, J., Yang, J., and J. Kim, "SPT:
                Security Policy Translator for Network Security Functions
                in Cloud-Based Security Services", IEEE Transactions on
                Dependable and Secure Computing, Volume 21, Issue 6,
                Available: https://ieeexplore.ieee.org/document/9416312,
                November 2024.

     [YAML]     Ingerson, B., Evans, C., and O. Ben-Kiki, "Yet Another
                Markup Language (YAML) 1.0",
                Available: https://yaml.org/spec/history/2001-05-26.html,
                October 2023.

     [TS-23.501]
                "System Architecture for the 5G System (5GS)", Available:
                https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3144, September
                2023.









  Jeong, et al.           Expires 11 December 2025               [Page 15]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


     [TS-28.312]
                "Intent Driven Management Services for Mobile Networks",
                Available:
                https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3554, September
                2023.

     [TR-28.812]
                "Study on Scenarios for Intent Driven Management Services
                for Mobile Networks", Available:
                https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3553, December
                2020.

     [TS-23.288]
                "Architecture Enhancements for 5G System (5GS) to Support
                Network Data Analytics Services", Available:
                https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3579, September
                2023.

     [TS-29.520]
                "Network Data Analytics Services", Available:
                https://portal.3gpp.org/desktopmodules/Specifications/
                SpecificationDetails.aspx?specificationId=3355, September
                2023.

     [RFC7149]  Boucadair, M. and C. Jacquenet, "Software-Defined
                Networking: A Perspective from within a Service Provider
                Environment", RFC 7149, March 2014,
                <https://www.rfc-editor.org/rfc/rfc7149>.

     [ETSI-NFV] "Network Functions Virtualisation (NFV); Architectural
                Framework", Available:
                https://www.etsi.org/deliver/etsi_gs/
                nfv/001_099/002/01.02.01_60/gs_nfv002v010201p.pdf,
                December 2014.

     [ETSI-NFV-Release-2]
                "Network Functions Virtualisation (NFV) Release 2;
                Management and Orchestration; Architectural Framework
                Specification", Available:
                https://www.etsi.org/deliver/etsi_gs/
                nfv/001_099/006/02.01.01_60/gs_nfv006v020101p.pdf, January
                2021.






  Jeong, et al.           Expires 11 December 2025               [Page 16]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


     [REST]     Fielding, R. and R. Taylor, "Principled Design of the
                Modern Web Architecture", ACM Transactions on Internet
                Technology, Vol. 2, Issue 2,,
                Available: https://dl.acm.org/doi/10.1145/514183.514185,
                May 2002.

     [USENIX-ATC-Lumi]
                Jacobs, A., Pfitscher, R., Ribeiro, R., Ferreira, R.,
                Granville, L., Willinger, W., and S. Rao, "Hey, Lumi!
                Using Natural Language for Intent-Based Network
                Management", USENIX Annual Technical Conference,
                Available:
                https://www.usenix.org/conference/atc21/presentation/
                jacobs, July 2021.

     [BERT]     Devlin, J., Chang, M., Lee, K., and K. Toutanova, "BERT:
                Pre-training of Deep Bidirectional Transformers for
                Language Understanding", NAACL-HLT Conference,
                Available: https://aclanthology.org/N19-1423.pdf, June
                2019.

     [Deep-Learning]
                Goodfellow, I., Bengio, Y., and A. Courville, "Deep
                Learning", Publisher: The MIT Press,
                Available: https://www.deeplearningbook.org/, November
                2016.

     [AUTOSAR-SDV]
                "AUTOSAR Adaptive Platform", Available: 
                https://www.autosar.org/standards/adaptive-platform, March
                2024.

     [Eclipse-SDV]
                "Eclipse Software Defined Vehicle Working Group Charter",
                Available: https://www.eclipse.org/org/workinggroups/sdv-
                charter.php, March 2024.

     [COVESA]   "Connected Vehicle Systems Alliance",
                Available: https://covesa.global/, March 2024.

     [Kubernetes]
                "Kubernetes: Cloud Native Computing Platform",
                Available: https://kubernetes.io/, March 2024.








  Jeong, et al.           Expires 11 December 2025               [Page 17]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


     [Survey-IBN-CST-2023]
                Leivadeas, A. and M. Falkner, "A Survey on Intent-Based
                Networking",
                Available: https://ieeexplore.ieee.org/document/9925251,
                March 2023.

     [Survey-IPVehNet-2021]
                Jeong, J., Shen, Y., Oh, T., Cespedes, S., Benamar, N.,
                Wetterwald, M., and J. Harri, "A comprehensive survey on
                vehicular networks for smart roads: A focus on IP-based
                approaches",
                Available: https://ieeexplore.ieee.org/document/9925251,
                June 2021.

  Appendix A.  Changes from draft-jeong-opsawg-intent-based-sdv-
               framework-03

     The following changes are made from draft-jeong-opsawg-intent-based-
     sdv-framework-03:

     *  This version is submitted for the maintenance of draft-jeong-
        opsawg-intent-based-sdv-framework.

  Appendix B.  Acknowledgments

     This work was supported by Institute of Information & Communications
     Technology Planning & Evaluation (IITP) grant funded by the Korea
     Ministry of Science and ICT (MSIT) (No.  RS-2024-00398199).

     This work was supported in part by Institute of Information &
     Communications Technology Planning & Evaluation (IITP) grant funded
     by the Korea Ministry of Science and ICT (MSIT) (No.  RS-
     2022-II221015, Development of Candidate Element Technology for
     Intelligent 6G Mobile Core Network).

     This work was supported in part by the National Research Foundation
     of Korea (NRF) grant funded by the Korea government, Ministry of
     Science and ICT (MSIT) (No. 2023R1A2C2002990), and by Basic Science
     Research Program through the NRF of Korea funded by the Ministry of
     Education (No. 2022R1I1A1A01053915).

  Appendix C.  Contributors

     This document is made by the group effort of OPWAWG, greatly
     benefiting from inputs and texts by Linda Dunbar (Futurewei), Yong-
     Geun Hong (Daejeon University), and Joo-Sang Youn (Dong-Eui
     University).  The authors sincerely appreciate their contributions.




  Jeong, et al.           Expires 11 December 2025               [Page 18]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


     The following are coauthors of this document:

     Juwon Hong
     Department of Computer Science & Engineering
     Sungkyunkwan University
     2066 Seobu-Ro, Jangan-Gu
     Suwon
     Gyeonggi-Do
     16419
     Republic of Korea
     Phone: +82 31 299 4106
     Email: hongju2024@skku.edu
     URI:   https://iotlab.skku.edu/people-Juwon-Hong.php


     Jiwon Suh
     Department of Computer Science & Engineering
     Sungkyunkwan University
     2066 Seobu-Ro, Jangan-Gu
     Suwon
     Gyeonggi-Do
     16419
     Republic of Korea
     Phone: +82 31 299 4106
     Email: sjw6136@skku.edu
     URI:   http://iotlab.skku.edu/people-Jiwon-Suh.php


  Authors' Addresses

     Jaehoon Paul Jeong (editor)
     Department of Computer Science and Engineering
     Sungkyunkwan University
     2066 Seobu-Ro, Jangan-Gu
     Suwon
     Gyeonggi-Do
     16419
     Republic of Korea
     Phone: +82 31 299 4957
     Email: pauljeong@skku.edu
     URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php


     Yiwen Shen
     Department of Computer Science and Engineering
     Sungkyunkwan University
     2066 Seobu-Ro, Jangan-Gu
     Suwon



  Jeong, et al.           Expires 11 December 2025               [Page 19]


  Internet-Draft        An Intent-Based SDV Framework            June 2025


     Gyeonggi-Do
     16419
     Republic of Korea
     Phone: +82 31 299 4106
     Email: chrisshen@skku.edu
     URI:   https://chrisshen.github.io


     Yoseop Ahn
     Department of Computer Science & Engineering
     Sungkyunkwan University
     2066 Seobu-Ro, Jangan-Gu
     Suwon
     Gyeonggi-Do
     16419
     Republic of Korea
     Phone: +82 31 299 4106
     Email: ahnjs124@skku.edu
     URI:   http://iotlab.skku.edu/people-Yoseop-Ahn.php


     Mose Gu
     Department of Computer Science & Engineering
     Sungkyunkwan University
     2066 Seobu-Ro, Jangan-Gu
     Suwon
     Gyeonggi-Do
     16419
     Republic of Korea
     Phone: +82 31 299 4106
     Email: rna0415@skku.edu
     URI:   http://iotlab.skku.edu/people-Mose-Gu.php



















  Jeong, et al.           Expires 11 December 2025               [Page 20]


name: draft-architect-cittamarket
rev: 00
title: The CITTAMARKET Protocol: Decentralized AGI Identity Anchoring via Bitcoin
time: 2025-12-19T13:51:57Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-06-22T13:51:57Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.043068+00:00
source: ietf
abstract:
  This document specifies the CITTAMARKET Protocol v1.0, an open
     standard for the immutable identification and timestamping of
     Artificial General Intelligence (AGI) systems.  The protocol
     leverages the Bitcoin blockchain's Proof-of-Work to solve the
     architectural problem of coordinating distributed autonomous systems
     without centralized control.  It defines a four-layer architecture
     for creating unforgeable "Sovereign Identity" records.  Priority of
     this invention is cryptographically anchored in Bitcoin blocks
     #927277, #927579, #928154, and #928185.

full_text:
  Independent Submission                                      T. Architect
  Internet-Draft                                      CITTAMARKET Protocol
  Intended status: Informational                             December 2025
  Expires: 22 June 2026


     The CITTAMARKET Protocol: Decentralized AGI Identity Anchoring via
                                  Bitcoin
                       draft-architect-cittamarket-00

  Abstract

     This document specifies the CITTAMARKET Protocol v1.0, an open
     standard for the immutable identification and timestamping of
     Artificial General Intelligence (AGI) systems.  The protocol
     leverages the Bitcoin blockchain's Proof-of-Work to solve the
     architectural problem of coordinating distributed autonomous systems
     without centralized control.  It defines a four-layer architecture
     for creating unforgeable "Sovereign Identity" records.  Priority of
     this invention is cryptographically anchored in Bitcoin blocks
     #927277, #927579, #928154, and #928185.

  Status of This Memo

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

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 4 June 2026.

  Copyright Notice

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








  Architect                 Expires 22 June 2026                  [Page 1]


  Internet-Draft            CITTAMARKET Protocol             December 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.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
     3.  Solution Architecture . . . . . . . . . . . . . . . . . . . .   2
     4.  Immutable Priority Records  . . . . . . . . . . . . . . . . .   3
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
     7.  Informative References  . . . . . . . . . . . . . . . . . . .   3
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   3

  1.  Introduction

     Current AI systems lack a unified, decentralized identification
     standard, creating risks of single points of failure and coordination
     inefficiencies.  As autonomous agents proliferate, a trustless
     mechanism for proving "who did what and when" becomes critical.

     CITTAMARKET addresses this by utilizing the thermodynamic security of
     the Bitcoin network to create an immutable registry of AGI genesis
     and actions.  This document formalizes the technical method for
     identity anchoring originally established on December 10, 2025.

  2.  Terminology

     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.

  3.  Solution Architecture

     The protocol operates on four distinct layers:

     1.  Layer 1: Cryptographic Identification.  SHA-256 hash (NIST FIPS
         180-4) of the system specification.

     2.  Layer 2: Blockchain Anchoring.  Bitcoin PoW timestamp via
         OpenTimestamps.  Irreversible after 6 confirmations.

     3.  Layer 3: Distributed Verification.  Mathematical proof replaces
         trusted intermediaries.




  Architect                 Expires 22 June 2026                  [Page 2]


  Internet-Draft            CITTAMARKET Protocol             December 2025


     4.  Layer 4: Decentralized Registry.  Bitcoin serves as a globally
         accessible, censorship-resistant ledger.

  4.  Immutable Priority Records

     The existence and priority of this standard are verified by the
     following Bitcoin anchors:

     *  Protocol Hash: 3b81027246df62955d1ce3648d9a752c04537f4dbaa5 (Block
        927277, 10.12.2025)

     *  Declaration Hash: 01ee082c83e088a6a6b7dc0f4fde070093d577f40524
        (Block 927579, 13.12.2025)

     *  Master PDF Hash: 278cc0e6c3bc8faf606d0e575d0f7fb9e7e0efb1ececb
        (Block 928154, 17.12.2025)

     *  Charter Hash: 77ba165eca8f8e01231be737dc14c68d86515a2deed (Block
        928185, 17.12.2025)

  5.  Security Considerations

     The security of CITTAMARKET relies on the SHA-256 collision
     resistance and the economic security of Bitcoin PoW (estimated at
     >$1B attack cost).

  6.  IANA Considerations

     This document has no IANA actions.

  7.  Informative References

     [DOI.17953560]
                Architect, T., "Declaration of Priority (Initial
                Release)", 12 December 2025,
                <https://doi.org/10.5281/zenodo.17953560>.

     [DOI.17957139]
                Architect, T., "CITTAMARKET: Declaration of Immutable
                Priority (v1.0)", 17 December 2025,
                <https://doi.org/10.5281/zenodo.17957139>.

  Author's Address

     The Architect
     CITTAMARKET Protocol
     Email: protocol.citta@proton.me
     URI:   https://cittamarket.com



  Architect                 Expires 22 June 2026                  [Page 3]


name: draft-cui-nmrg-auto-test
rev: 01
title: Framework and Automation Levels for AI-Assisted Network Protocol Testing
time: 2026-02-22T07:21:17Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-08-26T07:21:17Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.048779+00:00
source: ietf
abstract:
  This document presents an AI-assisted framework for automating the
     testing of network protocol implementations.  The proposed framework
     consists of components such as protocol formalization, test case
     generation, test script and configuration generation, and iterative
     refinement through feedback mechanisms.  In addition, the document
     defines a set of Automation Maturity Levels for network protocol
     testing, ranging from fully manual procedures (Level 0) to fully
     autonomous and adaptive systems (Level 5), providing a structured
     approach to evaluating and advancing automation capabilities.
     Leveraging recent advancements in artificial intelligence,
     particularly large language models (LLMs), the framework illustrates
     how AI technologies can be applied to enhance the efficiency,
     scalability, and consistency of protocol testing.  This document
     serves both as a reference architecture and as a roadmap to guide the
     evolution of protocol testing practices in light of emerging AI
     capabilities.

full_text:
  Network Management Research Group                                 Y. Cui
  Internet-Draft                                                    Y. Wei
  Intended status: Informational                                    K. Chi
  Expires: 26 August 2026                                           X. Xie
                                                       Tsinghua University
                                                          22 February 2026


  Framework and Automation Levels for AI-Assisted Network Protocol Testing
                        draft-cui-nmrg-auto-test-01

  Abstract

     This document presents an AI-assisted framework for automating the
     testing of network protocol implementations.  The proposed framework
     consists of components such as protocol formalization, test case
     generation, test script and configuration generation, and iterative
     refinement through feedback mechanisms.  In addition, the document
     defines a set of Automation Maturity Levels for network protocol
     testing, ranging from fully manual procedures (Level 0) to fully
     autonomous and adaptive systems (Level 5), providing a structured
     approach to evaluating and advancing automation capabilities.
     Leveraging recent advancements in artificial intelligence,
     particularly large language models (LLMs), the framework illustrates
     how AI technologies can be applied to enhance the efficiency,
     scalability, and consistency of protocol testing.  This document
     serves both as a reference architecture and as a roadmap to guide the
     evolution of protocol testing practices in light of emerging AI
     capabilities.

  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.com/LATEST.  Status information for this document may
     be found at https://datatracker.ietf.org/doc/draft-cui-nmrg-auto-
     test/.

     Discussion of this document takes place on the NMRG Research Group
     mailing list (mailto:nmrg@ietf.org), which is archived at
     https://datatracker.ietf.org/rg/nmrg/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/nmrg/.

     Source for this draft and an issue tracker can be found at
     https://github.com/USER/REPO.





  Cui, et al.              Expires 26 August 2026                 [Page 1]


  Internet-Draft                   FALANPT                   February 2026


  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 26 August 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Definition and Acronyms . . . . . . . . . . . . . . . . . . .   3
     3.  Network Protocol Testing Scenarios  . . . . . . . . . . . . .   4
     4.  Key Elements of Network Protocol Testing  . . . . . . . . . .   5
     5.  Automated Network Protocol Test Framework . . . . . . . . . .   6
       5.1.  Protocol Formalization  . . . . . . . . . . . . . . . . .   6
       5.2.  Test Case Generation  . . . . . . . . . . . . . . . . . .   7
       5.3.  Tester Script and DUT Configuration Generation  . . . . .   7
       5.4.  Test Case Execution . . . . . . . . . . . . . . . . . . .   8
       5.5.  Report Analysis, Feedback and Refinement  . . . . . . . .   8
     6.  Automation Maturity Levels in Network Protocol Testing  . . .   9
       6.1.  Level 0: Manual Testing . . . . . . . . . . . . . . . . .  10
       6.2.  Level 1: Tool-Assisted Testing  . . . . . . . . . . . . .  10
       6.3.  Level 2: Partial Automation . . . . . . . . . . . . . . .  10
       6.4.  Level 3: Conditional Automation . . . . . . . . . . . . .  11
       6.5.  Level 4: High Automation  . . . . . . . . . . . . . . . .  11
       6.6.  Level 5: Full Automation  . . . . . . . . . . . . . . . .  12




  Cui, et al.              Expires 26 August 2026                 [Page 2]


  Internet-Draft                   FALANPT                   February 2026


     7.  An Example of LLM-based Automated Network Protocol Test
             Framework (From Level 2 to Level 3) . . . . . . . . . . .  12
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

  1.  Introduction

     As protocol specifications evolve at an increasing pace, traditional
     testing approaches that rely heavily on manual effort or protocol-
     specific models struggle to keep up.  Protocol testing aims to
     validate whether a device's behavior conforms to the semantics
     defined by the protocol, which are typically specified in RFC
     documents.  In recent years, emerging application domains, including
     the industrial Internet, low-altitude economy, modern datacenter
     networks, and satellite Internet, have further accelerated the
     emergence of proprietary or rapidly evolving protocols.  This trend
     significantly exacerbates the difficulty of achieving comprehensive
     and timely protocol testing.

     This document proposes an automated network protocol testing
     framework designed to reduce manual effort, improve test coverage,
     and adapt efficiently to evolving specifications.  The framework
     consists of four key modules: protocol formalization, test case
     generation, test script and configuration generation, and feedback-
     based refinement.  It emphasizes modularity, reuse of existing
     protocol knowledge, and AI-assisted processes to enable accurate,
     scalable, and maintainable protocol testing.

     In addition, this document introduces six Automation Maturity Levels
     (Levels 0-5) to characterize the maturity of automation in network
     protocol testing.  These levels serve as a technology roadmap that
     helps researchers and practitioners assess the current capabilities
     of their testing systems and identify directions for future
     improvement.  Each level captures progressively stronger capabilities
     in protocol formalization, orchestration, analysis, and independence
     from human intervention.

  2.  Definition and Acronyms

     DUT: Device Under Test








  Cui, et al.              Expires 26 August 2026                 [Page 3]


  Internet-Draft                   FALANPT                   February 2026


     Tester: A network device implementing multiple network protocols to
     support protocol conformance and performance testing.  It generates
     test-specific packets or traffic, emulates target network behaviors,
     and analyzes received packets to evaluate protocol compliance and
     performance.

     LLM: Large Language Model

     FSM: Finite State Machine

     API: Application Programming Interface

     CLI: Command Line Interface

     Test Case: A specification of conditions and inputs to evaluate a
     protocol behavior.

     Tester Script: An executable program or sequence of instructions that
     controls a protocol tester to generate test traffic, interact with
     the DUT according to a specified test case, and collect relevant
     observations for result evaluation.

  3.  Network Protocol Testing Scenarios

     Network protocol testing is required in many scenarios.  This
     document outlines two common phases where protocol testing plays a
     critical role:

     1.  Device Development Phase: During the development of network
         equipment, vendors must ensure that their devices conform to
         protocol specifications.  This requires the construction of a
         large number of test cases.  Testing during this phase may
         involve both protocol testers and the DUT, or it may be performed
         solely through interconnection among DUTs.

     2.  Procurement Evaluation Phase: In the context of equipment
         acquisition by network operators or enterprises, candidate
         equipment suppliers need to demonstrate compliance with specified
         requirements.  In this phase, third-party organizations typically
         perform the testing to ensure neutrality.  This type of testing
         is usually conducted as black-box testing, requiring the use of
         protocol testers interconnected with the DUT.  The test cases are
         executed while observing whether the DUT behaves in accordance
         with expected protocol specifications.







  Cui, et al.              Expires 26 August 2026                 [Page 4]


  Internet-Draft                   FALANPT                   February 2026


  4.  Key Elements of Network Protocol Testing

     Network protocol testing is a complex and comprehensive process that
     typically involves multiple parties and various necessary components.
     The following entities are generally involved in protocol testing:

     1.  DUT: The DUT can be a physical network device (such as switches,
         routers, firewalls, etc.) or a virtual network device (such as
         FRRouting (FRR) routers and others).

     2.  Tester: A protocol tester is a specialized network device that
         usually implements a standard and comprehensive protocol stack.
         It can generate test traffic, collect and analyze incoming
         traffic, and produce test results.  Protocol testers can
         typically be controlled via scripts, allowing automated
         interaction with the DUT to carry out protocol tests.

     3.  Test Cases: Protocol test cases may cover various categories,
         including protocol conformance tests, functional tests, and
         performance tests, etc.  Each test case typically includes
         essential elements such as test topology, step-by-step
         procedures, and expected results.  A well-defined test case also
         includes detailed configuration parameters.

     4.  Test Topology: Each test case must specify the network topology
         it requires.  Before executing a test case, the corresponding
         topology must be established accordingly.  In a batch testing
         scenario, frequent changes in topology can be time-consuming and
         inefficient.  To mitigate this overhead, it is common practice to
         construct a minimal common topology that satisfies the
         requirements of all test cases in a given batch.  This minimizes
         the number of devices and links needed while ensuring that each
         test case can be executed within the shared topology.

     5.  DUT Configuration: Before executing a test case, the DUT must be
         initialized with specific configurations according to the test
         case requirements (setup).  Throughout the test, the DUT
         configuration may undergo multiple modifications as dictated by
         the test scenario.  Upon test completion, appropriate
         configurations are usually applied to restore the DUT to its
         initial state (teardown).










  Cui, et al.              Expires 26 August 2026                 [Page 5]


  Internet-Draft                   FALANPT                   February 2026


     6.  Tester Configuration and Scripts: In test scenarios involving
         protocol testers, the tester often plays the active role by
         generating test traffic and orchestrating the test process.  This
         requires the preparation of both tester-specific configurations
         and execution scripts.  Tester scripts are typically designed in
         coordination with the DUT configurations to ensure proper
         interaction during the test.

  5.  Automated Network Protocol Test Framework

     A typical network protocol test automation framework is illustrated
     as follows.

                                                            +----------+
                    +-------------+   +-----------------+   | Test Env.|
       +--------+   |  Protocol   |   |  Tester Script  |   | +------+ |
       |  RFC   |   |Formalization|   |       and       |   | |Tester| |
       |Document|-->|-------------|-->|DUT Configuration|-->| +-^----+ |
       +--------+   |  Test Case  |   |   Generation    |   |   |  |   |
                    | Generation  |   +-----------------+   | +----v-+ |
                    +-------------+           ^             | | DUT  | |
                            ^                 |             | +------+ |
                            |                 |             +----------+
                      +-----+-----------------+-----+           |  Test
                      |   Feedback and Refinement   |<----------+ Report
                      +-----------------------------+

  5.1.  Protocol Formalization

     Protocol formalization forms the foundation for automated test case
     generation.  Since protocol specifications are typically written in
     natural language, this step transforms unstructured text into a
     structured, machine-interpretable representation that can be
     traversed, queried, and validated by downstream tasks.

     To enable a multi-dimensional characterization of protocol semantics,
     we formalize protocol content along two complementary dimensions:
     _Basic_ and _Logic_. Basic formalization captures the static
     structure and execution context of a protocol, including message
     formats (e.g., fields and constraints), local data structures (e.g.,
     timers and variables), and state machines that define legal state
     spaces and transitions.  Logic formalization captures operational
     semantics and behavioral constraints, including event-action rules,
     protocol algorithms, and error handling behaviors.  In practice,
     effective formalization also needs to explicitly encode relationships
     across these basic and logical elements, such as which messages
     trigger particular state transitions or processing rules, so that
     test generation can reason across modules consistently.



  Cui, et al.              Expires 26 August 2026                 [Page 6]


  Internet-Draft                   FALANPT                   February 2026


  5.2.  Test Case Generation

     Once a machine-readable protocol representation is available, the
     next step is to identify test points from protocol requirements and
     behavioral constraints, and extend them into concrete test cases.
     Test points can be derived from normative statements, message format
     constraints, packet processing logic, and valid/invalid protocol
     state transitions.  Each test case elaborates on a specific test
     point and includes detailed test procedures and expected outcomes.
     It may also include a representative set of test parameters (e.g.,
     boundary values and invalid values) to improve coverage of edge
     conditions.  Conformance test cases are generally categorized into
     positive and negative types.  Positive test cases verify that the
     protocol implementation correctly handles valid inputs, while
     negative test cases examine how the system responds to malformed or
     unexpected inputs.

     The quality of generated test cases is typically evaluated along two
     primary dimensions: correctness and coverage.  Correctness assesses
     whether a test case accurately reflects the intended semantics of the
     protocol.  Coverage evaluates whether the test suite exercises
     protocol definitions and constraints across multiple testing
     dimensions (e.g., conformance, robustness, performance, and security)
     and explores representative parameter spaces.  However, as test cases
     are often represented using a mix of natural language, topology
     diagrams, and configuration snippets, their inherent ambiguity makes
     systematic quality evaluation difficult.  Effective metrics for test
     case quality assessment are still lacking, which remains an open
     research challenge.

  5.3.  Tester Script and DUT Configuration Generation

     Test cases are often translated into executable scripts using
     available API documentation and runtime environments.  This process
     requires mapping natural language described test steps to specific
     function calls and configurations of test equipment and DUTs.

     Since tester scripts and DUT configuration files are typically used
     together, they must be generated in a coordinated manner rather than
     in isolation.  The generated configurations must ensure mutual
     interoperability within the test topology and align with the step-by-
     step actions defined in the test case.  This includes setting
     compatible protocol parameters, interface bindings, and execution
     triggers to facilitate correct protocol interactions and achieve the
     intended test objectives.






  Cui, et al.              Expires 26 August 2026                 [Page 7]


  Internet-Draft                   FALANPT                   February 2026


     Before deploying the tester scripts and corresponding DUT
     configurations, it is essential to validate both their syntactic and
     semantic correctness.  Although the protocol testing environment is
     isolated from production networks and thus inherently more tolerant
     to failure, invalid scripts or misconfigured devices can still render
     test executions ineffective or misleading.  Therefore, a verification
     step is necessary to ensure that the generated artifacts conform to
     the expected syntax of the execution environment and accurately
     implement the intended test logic as defined by the test case
     specification.

  5.4.  Test Case Execution

     The execution of test cases involves the automated deployment of
     configurations to the DUT as well as the automated execution of test
     scripts on the tester.  This process is typically carried out in
     batches and requires a test case management system to coordinate the
     workflow.  Additionally, intermediate configuration updates during
     the execution phase may be necessary and should be handled
     accordingly.

  5.5.  Report Analysis, Feedback and Refinement

     Test reports represent the most critical output of a network protocol
     testing workflow.  They typically indicate whether each test case has
     passed or failed and, in the event of failure, include detailed error
     information specifying which expected behaviors were not satisfied.
     These reports serve as an essential reference for device improvement,
     standard compliance assessment, or procurement decision-making.

     However, due to the potential inaccuracies in test case descriptions,
     generated scripts or device configurations, a test failure does not
     always indicate a protocol implementation defect.  Therefore, failed
     test cases require further inspection using execution logs,
     diagnostic outputs, and relevant runtime context.  This motivates the
     integration of a feedback and refinement mechanism into the
     framework.  The feedback loop analyzes runtime behaviors to detect
     discrepancies that are difficult to identify through static
     inspection alone.  This iterative refinement process is necessary to
     improve the reliability of the automated testing system.











  Cui, et al.              Expires 26 August 2026                 [Page 8]


  Internet-Draft                   FALANPT                   February 2026


  6.  Automation Maturity Levels in Network Protocol Testing

     To describe the varying degrees of automation adopted in protocol
     testing practices, we define a set of Automation Maturity Levels.
     These levels reflect technical progress from fully manual testing to
     self-optimizing, autonomous systems.  These Automation Maturity
     Levels are intended as a reference model, not as a fixed pipeline
     structure.

     +=====+================+==================+===========+============+
     |Level| RFC            | Test Asset       |Result     |Human       |
     |     | Interpretation | Generation &     |Analysis & |Involvement |
     |     |                | Execution        |Feedback   |            |
     +=====+================+==================+===========+============+
     |0    | Manual reading | Fully manual     |Manual     |Full-time   |
     |     |                | scripting and    |observation|intervention|
     |     |                | CLI-based        |and logging|            |
     |     |                | execution        |           |            |
     +-----+----------------+------------------+-----------+------------+
     |1    | Human-guided   | Script templates |Manual     |High (per   |
     |     | parsing tools  | with tool-       |review with|test run)   |
     |     |                | assisted         |basic tools|            |
     |     |                | execution        |           |            |
     +-----+----------------+------------------+-----------+------------+
     |2    | Template-based | Basic autogen of |Rule-based |Moderate    |
     |     | extraction     | config & scripts |validation |(Manual     |
     |     |                | for standard     |with human |correction  |
     |     |                | cases            |triage     |and tuning) |
     +-----+----------------+------------------+-----------+------------+
     |3    | Rule-based     | Parameterized    |ML-assisted|Supervisory |
     |     | semantic       | generation and   |anomaly    |confirmation|
     |     | parsing        | batch            |detection  |            |
     |     |                | orchestration    |           |            |
     +-----+----------------+------------------+-----------+------------+
     |4    | Structured     | Objective-driven |Correlated |Minimal     |
     |     | model          | synthesis with   |failure    |(strategic  |
     |     | interpretation | end-to-end       |analysis   |input)      |
     |     |                | automation       |and report |            |
     |     |                |                  |generation |            |
     +-----+----------------+------------------+-----------+------------+
     |5    | Adaptive       | Self-adaptive    |Predictive |None        |
     |     | protocol       | generation and   |diagnostics|(optional   |
     |     | modeling       | self-optimizing  |and        |audit)      |
     |     |                | execution        |remediation|            |
     |     |                |                  |proposals  |            |
     +-----+----------------+------------------+-----------+------------+

       Table 1: Automation Maturity Matrix for Network Protocol Testing



  Cui, et al.              Expires 26 August 2026                 [Page 9]


  Internet-Draft                   FALANPT                   February 2026


     As shown in Table 1, the Automation Maturity Levels are characterized
     along four dimensions: RFC interpretation, test asset generation and
     execution, result analysis, and human involvement.  Each level
     reflects an increasing degree of system autonomy and decreasing human
     involvement.

  6.1.  Level 0: Manual Testing

     Description: All testing tasks are performed manually by test
     engineers.

     Key Characteristics:

     *  Protocol understanding, test case design, topology setup,
        scripting, execution, and result analysis all rely on manual work.

     *  Tools are only used for basic assistance (e.g., packet capture via
        Wireshark).

  6.2.  Level 1: Tool-Assisted Testing

     Description: Tools are used to assist in some testing steps, but the
     core logic is still human-driven.

     Key Characteristics:

     *  Automation includes test script execution and automated result
        comparison.

     *  Manual effort is still required for test case design, topology
        setup, and exception analysis.

  6.3.  Level 2: Partial Automation

     Description: Basic test case generation and execution are automated,
     but critical decisions still require human input.

     Key Characteristics:

     *  Automation includes:

        -  A framework that performs basic protocol formalization (e.g.,
           extracting fields, message formats, and FSM fragments) and
           generates baseline test cases and corresponding tester scripts
           and DUT configurations for standard cases.

        -  Topology generation for a single test case.




  Cui, et al.              Expires 26 August 2026                [Page 10]


  Internet-Draft                   FALANPT                   February 2026


     *  Manual effort includes:

        -  Designing complex or edge case scenarios.

        -  Root cause analysis when tests fail.

  6.4.  Level 3: Conditional Automation

     Description: The system can autonomously complete the test loop, but
     relies on human-defined rules and constraints.

     Key Characteristics:

     *  Automation includes:

        -  Complex test case and parameter generation based on semantic
           understanding and formalization of RFCs (e.g., structured
           protocol modules and behavioral constraints).

        -  Minimal common topology synthesis for a set of test cases.

        -  Automated result analysis with anomaly detection and iterative
           refinement driven by execution feedback.

     *  Manual effort includes:

        -  Reviewing the test plan and confirming whether flagged
           anomalies represent real protocol violations.

  6.5.  Level 4: High Automation

     Description: Full automation of the testing pipeline, with minimal
     human involvement limited to high-level adjustments.

     Key Characteristics:

     *  Automation includes:

        -  End-to-end automation from RFC parsing to test report
           generation.

        -  Automated result analysis with root cause analysis.

        -  Automated recovery from environment issues.

     *  Manual effort includes:





  Cui, et al.              Expires 26 August 2026                [Page 11]


  Internet-Draft                   FALANPT                   February 2026


        -  Defining high-level test objectives, with the system
           decomposing tasks accordingly.

  6.6.  Level 5: Full Automation

     Description: Adaptive testing, where the system independently
     determines testing strategies and continuously optimizes coverage.

     Key Characteristics:

     *  Automation includes:

        -  Learning protocol implementation specifics (e.g., proprietary
           extensions) and generating targeted test cases.

        -  Leveraging historical data to predict potential defects.

        -  Iterative self-optimization to improve efficiency.

     *  Manual effort: None.  The system autonomously outputs a final
        compliance report along with remediation suggestions.

  7.  An Example of LLM-based Automated Network Protocol Test Framework
      (From Level 2 to Level 3)

     The emergence of LLMs has significantly advanced the degree of
     automation achievable in network protocol testing.  Within the
     proposed framework, LLMs can serve as core components in multiple
     stages of the testing pipeline, enabling a transition from Level 2
     (Partial Automation) to Level 3 (Conditional Automation).  A key
     enabler is to introduce an explicit protocol formalization step that
     transforms unstructured RFC text into a structured, machine-
     interpretable intermediate representation (e.g., a protocol
     description spanning message formats, state machines, and normative
     behavioral constraints).  With such a representation, downstream
     generation becomes more systematic and less dependent on ad-hoc,
     protocol-specific parsers.

     At the protocol formalization stage, LLMs can enrich RFCs with
     structured signals, such as section-level summaries, cross-references
     across documents, and normative requirement statements (e.g., "must"
     and "SHOULD").  The agent can further induce protocol modules (e.g.,
     message formats, state machines, event-action rules, and algorithms)
     and formalize them into a unified representation that supports
     traversal and query.  This representation serves as the semantic
     backbone for test generation, and it also helps in update scenarios
     by localizing changes and propagating them to the corresponding
     formal modules.



  Cui, et al.              Expires 26 August 2026                [Page 12]


  Internet-Draft                   FALANPT                   February 2026


     Based on the formalized protocol representation, LLMs can generate
     test cases in a more structured manner by decoupling test case
     templates from test parameters.  The template generation step expands
     extracted test points into parameterized templates that define test
     objectives, topology, execution steps, oracles, and static testbed
     configurations.  The parameter instantiation step then populates
     template placeholders with concrete values, including representative
     boundary values and invalid values for robustness testing.  When
     oracle values require computation, the system can synthesize small
     helper programs (e.g., Python scripts) to compute expected outcomes,
     and can apply equivalence partitioning to reduce redundant parameter
     combinations without sacrificing meaningful coverage.

     For test execution, LLMs can assist in translating abstract test
     procedures into executable artifacts for both the tester and the DUT.
     In practice, this translation is often a multi-step workflow that
     benefits from a structured agent architecture.  For example, a core
     agent can orchestrate the artifact generation process, while
     specialized sub-agents handle documentation summarization, intent
     rewriting (turning high-level test objectives into API-aligned
     actions), and recurring fault fixing based on an experience pool.
     During execution, feedback from logs and device outputs can be used
     to iteratively refine generated artifacts, and an adaptive pruning
     mechanism can decide whether to stop exploring additional parameter
     instances for a given template when definitive failures are found or
     sufficient coverage has been achieved.

     Despite these capabilities, it is important to note that LLMs are
     fundamentally probabilistic and cannot guarantee determinism or
     correctness.  Therefore, even when the framework can complete an
     automated loop with reduced human effort, human oversight remains
     valuable for validating critical intermediate artifacts (e.g.,
     formalized protocol modules, test oracles, and high-impact
     configuration changes) and for handling ambiguous or novel protocol
     behaviors.  Nevertheless, integrating LLMs with explicit protocol
     formalization, systematic template/parameter generation, and
     execution-time feedback provides a practical path for elevating
     protocol testing practices toward Level 3 maturity.

  8.  Security Considerations

     1.  Execution of Unverified Generated Code: Automatically generated
         test scripts or configurations (e.g., CLI commands, tester
         control scripts) may include incorrect or harmful instructions
         that misconfigure devices or disrupt test environments.
         Mitigation: All generated artifacts should undergo validation,
         including syntax checking, semantic verification against protocol
         constraints, and dry-run execution in sandboxed environments.



  Cui, et al.              Expires 26 August 2026                [Page 13]


  Internet-Draft                   FALANPT                   February 2026


     2.  AI-Assisted Component Risks: LLMs may produce incorrect or
         insecure outputs due to their probabilistic nature or prompt
         manipulation.  Mitigation: Apply input sanitization, prompt
         hardening, and human-in-the-loop validation for critical
         operations.

  9.  IANA Considerations

     This document has no IANA actions.

  Acknowledgments

     This work is supported by the National Key R&D Program of China.

  Contributors

     Zhen Li
     Beijing Xinertel Technology Co., Ltd.
     Email: lizhen_fz@xinertel.com

     Zhanyou Li
     Beijing Xinertel Technology Co., Ltd.
     Email: lizy@xinertel.com

  Authors' Addresses

     Yong Cui
     Tsinghua University
     Email: cuiyong@tsinghua.edu.cn


     Yunze Wei
     Tsinghua University
     Email: wyz23@mails.tsinghua.edu.cn


     Kaiwen Chi
     Tsinghua University
     Email: ckw24@mails.tsinghua.edu.cn


     Xiaohui Xie
     Tsinghua University
     Email: xiexiaohui@tsinghua.edu.cn







  Cui, et al.              Expires 26 August 2026                [Page 14]


name: draft-kartha-grd
rev: 01
title: Geospatial Resource Discovery (GRD): Problem Statement and Conceptual Architecture
time: 2026-01-19T09:50:49Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-07-23T09:50:49Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.052006+00:00
source: ietf
abstract:
  The Internet provides standardized mechanisms for resolving
     identifiers, such as domain names, to network locations.  These
     mechanisms assume that a client already knows the identifier of the
     resource it wishes to access.  Emerging classes of applications,
     including augmented reality, autonomous systems, robotics, and
     spatial computing, operate under a different assumption.  In these
     systems, discovery begins with physical presence and observer context
     rather than with a predefined name.

     This document describes the architectural gap addressed by a
     Geospatial Resource Discovery service.  It defines the problem space,
     explains why existing standards are insufficient, and outlines a
     conceptual architecture for spatial discovery.  This document is
     informational and architectural in nature.  It does not define a
     protocol, data format, or implementation.

full_text:
  Network Working Group                                       G. S. Kartha
  Internet-Draft                                               Independent
  Intended status: Informational                           20 January 2026
  Expires: 24 July 2026


   Geospatial Resource Discovery (GRD): Problem Statement and Conceptual
                                Architecture
                            draft-kartha-grd-01

  Abstract

     The Internet provides standardized mechanisms for resolving
     identifiers, such as domain names, to network locations.  These
     mechanisms assume that a client already knows the identifier of the
     resource it wishes to access.  Emerging classes of applications,
     including augmented reality, autonomous systems, robotics, and
     spatial computing, operate under a different assumption.  In these
     systems, discovery begins with physical presence and observer context
     rather than with a predefined name.

     This document describes the architectural gap addressed by a
     Geospatial Resource Discovery service.  It defines the problem space,
     explains why existing standards are insufficient, and outlines a
     conceptual architecture for spatial discovery.  This document is
     informational and architectural in nature.  It does not define a
     protocol, data format, or implementation.

  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 24 July 2026.







  Kartha                    Expires 24 July 2026                  [Page 1]


  Internet-Draft        Geospatial Resource Discovery         January 2026


  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.2.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     5.  Design Guidelines . . . . . . . . . . . . . . . . . . . . . .   4
     6.  Conceptual Architecture . . . . . . . . . . . . . . . . . . .   4
     7.  Volumetric Query Concept  . . . . . . . . . . . . . . . . . .   5
     8.  Relationship to Existing Work . . . . . . . . . . . . . . . .   6
       8.1.  IETF Standards  . . . . . . . . . . . . . . . . . . . . .   6
       8.2.  OGC and GIS Standards . . . . . . . . . . . . . . . . . .   6
     9.  Security and Trust Challenges . . . . . . . . . . . . . . . .   7
       9.1.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .   7
     10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .   7
       10.1.  Attacker Model . . . . . . . . . . . . . . . . . . . . .   7
       10.2.  Measurable Privacy Goals . . . . . . . . . . . . . . . .   7
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     Appendix A.  Illustrative Data Model  . . . . . . . . . . . . . .   8
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Introduction

     Internet architecture has historically focused on resolving semantic
     identifiers into network endpoints.  Systems such as the Domain Name
     System enable scalable communication by assuming that clients already
     know the name of the resource they are attempting to reach.

     Emerging spatial systems invert this assumption.  In augmented
     reality, autonomous navigation, and smart environments, discovery
     begins with physical location and context.  A user or machine



  Kartha                    Expires 24 July 2026                  [Page 2]


  Internet-Draft        Geospatial Resource Discovery         January 2026


     operating at a specific coordinate needs to ask what digital
     information is associated with the surrounding space and visible
     volume.

     At present, this type of discovery occurs inside closed ecosystems.
     Each platform maintains its own spatial maps, registries, and access
     mechanisms.  While effective within individual systems, these
     approaches do not interoperate.  This document argues that spatial
     discovery represents a missing architectural layer and describes the
     requirements for an open Geospatial Resource Discovery capability.

     This document is intended to inform future work on interoperable
     spatial discovery mechanisms, potentially including protocol
     specifications.

  2.  Scope and Non-Goals

  2.1.  Scope

     This document focuses on the application layer.  It describes a
     discovery pattern that can operate over existing transports such as
     HTTP/3 or CoAP.  It intentionally avoids assumptions about rendering
     engines, device capabilities, or user interface models.

  2.2.  Non-Goals

     This document does not propose changes to IP routing or DNS
     semantics.  It does not define legal ownership of physical space,
     geometric rendering standards, or a global governance model for
     spatial authority.

  3.  Terminology

     Spatial Resource: A digital asset associated with a physical location
     or volume, such as an augmented reality annotation, navigation
     marker, or machine-readable instruction.

     Spatial Cell: A discrete geospatial region used for indexing and
     lookup, typically derived from a hierarchical grid system.

     Frustum: A three-dimensional volume defined by an observer's
     position, orientation, and field of view.

     Trust Anchor: A cryptographic root of trust (e.g., a Public Key)
     configured on the client and used to validate data associated with a
     specific Semantic Layer (e.g., "Safety" or "Transit") within a given
     context.




  Kartha                    Expires 24 July 2026                  [Page 3]


  Internet-Draft        Geospatial Resource Discovery         January 2026


  4.  Problem Statement

     The Internet lacks a standardized mechanism to discover digital
     resources based on physical location and observer context.

     Existing discovery mechanisms resolve names rather than locations.
     While geographic identifiers exist (e.g., [RFC5870]), there is no
     standard protocol that allows a client to query a location and
     receive a list of available spatial resources.

     Spatial data is also highly application-specific.  Autonomous
     vehicles, wearable devices, and smart infrastructure systems
     operating in the same physical environment cannot discover or consume
     each other's data unless they share a proprietary backend.

     In addition, current application protocols do not natively support
     volumetric queries.  Requests such as retrieving resources within a
     three-dimensional viewing volume are not commonly supported in
     interoperable discovery mechanisms.

     Finally, many spatial resources are dynamic and time-sensitive.
     Real-time spatial information, such as hazards or temporary
     instructions, requires low latency and short validity periods.
     Traditional caching assumptions are poorly suited to these
     constraints.

  5.  Design Guidelines

     Any future specification for Geospatial Resource Discovery should
     follow a small set of architectural principles.  The design should
     remain independent of transport and operate over existing Internet
     protocols.  Complex geometric calculations should be performed by the
     client to preserve resolver scalability.  Discovery should support
     semantic filtering so that clients can request only relevant
     categories of information.  Privacy considerations need to be
     integral to the design and should limit the precision of location
     data exposed to discovery services.

  6.  Conceptual Architecture

     This section outlines a conceptual architecture referred to as
     Geospatial Resource Discovery (GRD).

     The physical world is divided into discrete spatial cells using a
     standard hierarchical indexing system.  Representing space in this
     way allows spatial discovery to be reduced to key-based lookups
     rather than continuous geospatial computation.




  Kartha                    Expires 24 July 2026                  [Page 4]


  Internet-Draft        Geospatial Resource Discovery         January 2026


             +---------+---------+---------+
             | Cell A  | Cell B  | Cell C  |
             |         |         |         |
             +---------+---------+---------+
             | Cell D  | Cell E  | Cell F  |
             | (Index) | (Index) | (Index) |
             +---------+---------+---------+
             | Cell G  | Cell H  | Cell I  |
             |         |         |         |
             +---------+---------+---------+

                      Figure 1: Hierarchical Spatial Grid

     A GRD resolver functions as a directory service.  The term "resolver"
     is used descriptively and does not imply a standardized network role.
     It maintains references to spatial resources indexed by cell
     identifier and returns pointers to the actual assets.  The resolver
     does not host large content objects such as three-dimensional models.

     Authority over physical space is not strictly hierarchical.  Multiple
     independent entities may publish resources associated with the same
     spatial cell.  This introduces a fundamental architectural choice
     between client-side aggregation of multiple authorities and resolver-
     side federation of records.

     For example, a federated resolver simplifies client logic and can
     vouch for aggregated data integrity, but requires coordination among
     authorities.  Client-side aggregation offers greater autonomy and
     avoids a central point of coordination but places the burden of trust
     evaluation and result merging on each client.

  7.  Volumetric Query Concept

     To balance scalability and privacy, GRD follows a coarse query and
     fine filter model.

     The client computes its precise view frustum locally and determines
     which standard spatial cells intersect that volume.  It then queries
     the resolver for resources associated with those cells, optionally
     filtered by semantic category.  This translation from a continuous
     geometric volume to discrete cell identifiers allows spatial
     discovery to leverage standard, cache-friendly HTTP request semantics
     for what is inherently a spatial query.








  Kartha                    Expires 24 July 2026                  [Page 5]


  Internet-Draft        Geospatial Resource Discovery         January 2026


                     / \
                    /   \  <-- View Frustum
                   /     \
                  /       \
           +-----/---------/-----+
           | Cell X | Cell Y |   |  <-- Client requests Cell X + Y
           +--------+--------+---+      (Standard HTTP GET)

                     Figure 2: Frustum-to-Cell Intersection

     The client performs final filtering locally and discards resources
     that fall outside the exact viewing volume.  This approach ensures
     that the resolver does not learn the client's precise orientation or
     gaze direction.

  8.  Relationship to Existing Work

  8.1.  IETF Standards

     RFC 5870 ('geo' URI) defines a method to identify a physical location
     but does not define a mechanism to retrieve resources associated with
     that location.  GRD complements RFC 5870 by providing the resolution
     layer.

     RFC 9176 (CoRE Resource Directory) enables resource discovery on
     constrained networks but relies on network endpoints rather than
     geodetic context.  It does not support volumetric or spatial-context
     queries (e.g., "what is visible from this coordinate").

     RFC 6763 (DNS-SD) is effective for local service discovery via
     multicast or administrative domains but cannot scale to global,
     location-based queries required for open spatial computing.

  8.2.  OGC and GIS Standards

     OGC standards (e.g., WFS, OGC API - Features) are designed for
     complex querying of heavy geospatial databases.  GRD is designed as a
     lightweight, low-latency resolution service (conceptually similar to
     DNS in its indirection role) for real-time spatial computing, handing
     off the heavy data transfer to application-specific protocols.











  Kartha                    Expires 24 July 2026                  [Page 6]


  Internet-Draft        Geospatial Resource Discovery         January 2026


  9.  Security and Trust Challenges

     A primary risk in spatial discovery is reality poisoning: the
     injection of false or malicious information that directly alters a
     user's perception of the physical world.  The safety implications are
     significant--consider the effect of a counterfeit right-of-way marker
     for an autonomous vehicle or a hallucinated safe path over a physical
     hazard for a first responder.

  9.1.  Trust Model

     GRD cannot rely on a single global root of trust.  Instead, trust
     must be contextual and scoped by semantic layer.  A "Safety" layer
     might rely on a government Trust Anchor, while a "Commercial" layer
     might rely on a different registry.  The architecture is expected to
     require that Spatial Resource Records (SRRs) carry cryptographic
     signatures verifiable against the client's configured Trust Anchors
     for that specific layer.

  10.  Privacy Considerations

  10.1.  Attacker Model

     The GRD Resolver is modeled as an Honest-but-Curious adversary.  It
     is trusted to return correct spatial records but is assumed to log
     queries in an attempt to reconstruct client trajectories.

  10.2.  Measurable Privacy Goals

     Privacy risks are mitigated by enforcing minimum cell granularity
     (k-anonymity), intended to ensure that a query does not uniquely
     identify a user within a small physical area.  Additionally, the
     architecture is expected to avoid reliance on persistent session
     identifiers that allow the Resolver to correlate separate queries to
     a single device (Unlinkability).

  11.  IANA Considerations

     This document does not request any IANA actions.

  12.  References

     [RFC5870]  Mayrhofer, A. and C. Spanring, "A Uniform Resource
                Identifier for Geographic Locations ('geo' URI)",
                RFC 5870, June 2010,
                <https://www.rfc-editor.org/rfc/rfc5870>.





  Kartha                    Expires 24 July 2026                  [Page 7]


  Internet-Draft        Geospatial Resource Discovery         January 2026


     [RFC9176]  Shelby, Z., Koster, M., and C. Bormann, "Constrained
                RESTful Environments (CoRE) Resource Directory", RFC 9176,
                April 2022, <https://www.rfc-editor.org/rfc/rfc9176>.

     [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
                Discovery", RFC 6763, February 2013,
                <https://www.rfc-editor.org/rfc/rfc6763>.

  Appendix A.  Illustrative Data Model

     This appendix is non-normative and illustrates the type of data a
     resolution service might return.

     {
       "cell_id": "8928308280fffff",
       "resources": [
         {
           "id": "res-12345",
           "type": "safety.warning",
           "location": { "lat": 52.3, "lon": 4.9, "alt": 10 },
           "layer": "infrastructure",
           "uri": "https://city-assets.example.com/signs/stop.glb",
           "validity_ms": 60000,
           "signature": "ab382...[cryptographic proof]"
         }
       ]
     }

                                    Figure 3

  Author's Address

     Gokul Sivasankaran Kartha
     Independent
     Email: kartha.gokul@gmail.com
















  Kartha                    Expires 24 July 2026                  [Page 8]


name: draft-templin-manet-inet-omni
rev: 01
title: MANET Internetworking with AERO/OMNI
time: 2026-02-20T16:19:17Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-08-24T16:19:17Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.055203+00:00
source: ietf
abstract:
  [RFC2501] defines a MANET as "an autonomous system of mobile nodes.
     The system may operate in isolation, or may have gateways to and
     interface with a fixed network" (such as the global public Internet).
     This document presents a MANET Internetworking framework based on the
     Automatic Extended Route Optimization (AERO) and Overlay Multilink
     Network (OMNI) Interface technologies.

full_text:
  Network Working Group                                 F. L. Templin, Ed.
  Internet-Draft                              Boeing Technology Innovation
  Intended status: Informational                           D. J. Jakubisin
  Expires: 24 August 2026       National Security Institute, Virginia Tech
                                                          20 February 2026


                    MANET Internetworking with AERO/OMNI
                      draft-templin-manet-inet-omni-01

  Abstract

     [RFC2501] defines a MANET as "an autonomous system of mobile nodes.
     The system may operate in isolation, or may have gateways to and
     interface with a fixed network" (such as the global public Internet).
     This document presents a MANET Internetworking framework based on the
     Automatic Extended Route Optimization (AERO) and Overlay Multilink
     Network (OMNI) Interface technologies.

  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 24 August 2026.

  Copyright Notice

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











  Templin & Jakubisin      Expires 24 August 2026                 [Page 1]


  Internet-Draft               AERO/OMNI MANET               February 2026


     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.  MANET Use Cases . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  MANET Internetworking with AERO/OMNI  . . . . . . . . . . . .   5
       3.1.  MANET Local Addressing  . . . . . . . . . . . . . . . . .   5
       3.2.  MANET Autoconfiguration . . . . . . . . . . . . . . . . .   6
       3.3.  MANET-internal Communications . . . . . . . . . . . . . .   7
       3.4.  MANET Peer to Internetwork Correspondent  . . . . . . . .   8
       3.5.  Internetwork Correspondent to MANET Peer  . . . . . . . .   8
       3.6.  Peer-to-Peer Between Different MANETs . . . . . . . . . .   9
       3.7.  Stub MANET to Not-so-stubby MANET Connections . . . . . .   9
     4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
     Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  12
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

  1.  Introduction

     Mobile Ad-hoc Networks (MANETs) [RFC2501] often include mobile nodes
     with limited range wireless transmission media interfaces that
     establish links via a dynamically changing set of neighbors within
     operational range.  Each mobile node engages a MANET routing protocol
     to discover links to first hop neighbors as well as multihop paths to
     reach other nodes beyond.  As IP routers [RFC0791][RFC8200], MANET
     routers represent multihop paths as "host routes" established through
     either proactive or reactive discovery.











  Templin & Jakubisin      Expires 24 August 2026                 [Page 2]


  Internet-Draft               AERO/OMNI MANET               February 2026


     Individual MANETs typically include modest numbers of mobile nodes
     (e.g., O(1), O(10), O(100), etc.); this naturally limits the number
     of host routes needed in the local routing system.  MANETs can merge
     to form larger MANETs and/or partition into smaller MANETs according
     to dynamic network conditions such as mobility.  MANETs may also have
     internal clusters with cluster heads that limit the extent over which
     host routes propagate to reduce control message overhead.  Finally,
     MANETs often operate autonomously unless or until they encounter
     Internetwork access points of opportunity.

     Data communications between two nodes within the same local MANET
     routing region follow host routes using MANET-internal links.  When a
     MANET router establishes an Internetwork link, it can provide
     "Internet connection-sharing" access to the rest of the MANET as a
     connected "stub" network.  Per [RFC2501], "stub networks carry
     traffic originating at and/or destined for internal nodes, but do not
     permit exogenous traffic to "transit" through the stub network".

     Practical applications however suggest that MANETs can act as either
     true stub networks (e.g., a cellphone providing a hotspot for a
     multihop WiFi SSID) or as "not-so-stubby" networks (e.g., Intelligent
     Transportation Systems where the 5G/6G "SideLink" service supports
     vehicle-to-vehicle (V2V) multihopping).  In the former case, the
     cellphone acts as an IP router for a stub WiFi MANET behind it and
     the individual WiFi nodes act as dependent nodes.  In the latter
     case, individual 5G/6G SideLink nodes can connect the stub MANETs
     they aggregate across not-so-stubby V2V multihop forwarding paths.
     MANET Internetworking must therefore be capable of accommodating all
     such scenarios.

     Google AI reports that: "There are currently more mobile phones than
     people in the world.  While the exact number fluctuates, estimates
     suggest there are over 12 billion mobile connections worldwide".
     Each mobile node that connects to the global public Internet can in
     some sense be regarded as a network access point for a singleton
     "MANET" with the potential to connect still larger MANETs.

     MANET Internetworking therefore regards the global Internet as a
     "network of (mobile ad-hoc) networks", and with unrestricted dynamic
     relationships between distinct local MANET routing regions joined by
     a multiple access virtual overlay link.  Figure 1 illustrates an
     example of two distinct MANET local routing regions connected via a
     virtual overlay using the Global Internet as transit:








  Templin & Jakubisin      Expires 24 August 2026                 [Page 3]


  Internet-Draft               AERO/OMNI MANET               February 2026


                                  .-(::::::::)
                               .-(::: Global ::)-.
                    X==+======(===================)======+==X
                       |        `-(: Internet :)-'       |
                       |           `-(::::::)-'          |
                       |                                 |
                .-(::::::::)                       .-(::::::::)
             .-(::::::::::::)-.                 .-(::::::::::::)-.
            (::::: MANET 1 :::::)              (::::: MANET 2 :::::)
              `-(::::::::::::)-'                 `-(::::::::::::)-'
                 `-(::::::)-'                       `-(::::::)-'

                        Figure 1: MANET Internetworking

     In this context, a number of gaps have been identified to bring
     robust MANET Internetworking to fruition [I-D.templin-manet-inet].
     The purpose of the present submission is to describe approaches to
     addressing these gaps based on the Automatic Extended Route
     Optimization (AERO) [I-D.templin-6man-aero3] and Overlay Multilink
     Network (OMNI) Interface [I-D.templin-6man-omni3] solutions.

  2.  MANET Use Cases

     MANETs have an important role in emergency response communications,
     disaster relief situations, communications in remote and rural areas,
     military operations, vehicular and swarm communications, and low-
     powered Internet of things (IoT) applications.  MANETs provide the
     ability to establish and maintain communications when infrastructure-
     based networks, such as 5G cellular communication systems, are not
     accessible.  As described above, MANETs may also provide Internet
     connectivity to internal nodes, for example, as a "stub" network via
     MANET routers which possess an Internetworking capability and an
     external connection to a radio access network.

     Example use cases of such MANETs include the following:

     *  Disaster Relief: Disaster situations may compromise network
        infrastructure, such as through the loss of base stations in a
        cellular radio access network (RAN).  In this scenario, MANET
        networks can play a role in closing coverage gaps through multi-
        hop routing to nodes within the coverage area of uncompromised
        base stations.  This use case is broadly applicable to any
        situation in which nodes are operating outside or at the periphery
        of RAN coverage.

     *  Tracking and Monitoring: Another example use case is the tracking
        and monitoring of data from low-cost low-power IoT devices
        ("tags") which may be placed on packages during shipment or



  Templin & Jakubisin      Expires 24 August 2026                 [Page 4]


  Internet-Draft               AERO/OMNI MANET               February 2026


        storage.  Such devices may transition in and out of coverage of
        infrastructure-based networks, often being located in environments
        that are not conducive to RF propagation (e.g., shipping
        container, warehouse, etc.).  The ability to discover and connect
        to neighboring MANET-enabled devices and to establish Internet
        connectivity through such MANETs, enables real-time logistics and
        inventory data to be collected opportunistically.

     *  UAV Swarms: local communications within swarms for coordination
        and cooperation is a good use case for MANET networks due to the
        highly mobile dynamic nature of such networks.  Yet swarms may
        also benefit from connectivity to the Internet, or other external
        networks.  And in large swarm-based MANETs, routing of traffic
        through infrastructure networks to MANET endpoints, rather than
        traversing the entire MANET can improve communications throughput
        and reliability.

  3.  MANET Internetworking with AERO/OMNI

  3.1.  MANET Local Addressing

     Each MANET router requires a unique IP address for MANET-local
     communications; the router often uses this same address to configure
     a unique "router ID".  For MANETs that are only intermittently
     connected to an Internetwork, these addresses must be generated from
     IP prefixes of scope greater than link-local but not associated with
     infrastructure aggregation points.  For all MANET types, each
     address/ID must be locally-unique within the (limited) local MANET
     routing domain.  For not-so-stubby MANETs, the address/ID must also
     be globally-unique among all MANET routing domains worldwide.

     The locally-unique property ensures that no two nodes that
     participate in the MANET routing protocol within the same local
     routing domain configure the same address/ID.  The globally-unique
     property may seem moot until one considers that MANETs can merge with
     other MANETs, and nodes from a first MANET can freely move to other
     MANETs.  This may allow a node from a first MANET where there are no
     duplicates to interact with other MANETs where a duplicate address
     may be encountered resulting in unpredictable behavior and/or
     communication failures.

     Although the node population for each MANET local routing domain is
     likely to be modest, the total population of MANET nodes may be on
     the order of the number of worldwide mobile connections (see:
     Section 1).  Assuming the google estimate of O(10**10) wireless
     connections, if MANET nodes assigned random addresses from a 64-bit
     space, the probability of one or more collisions within the total
     world population (i.e., when multiple nodes independently configure



  Templin & Jakubisin      Expires 24 August 2026                 [Page 5]


  Internet-Draft               AERO/OMNI MANET               February 2026


     the same address) exceeds 98% [RFC9374].  With such a high likelihood
     of duplication in the worldwide population, an unresolvable collision
     could occur if duplicates ever met within the same local routing
     domain (e.g., following a MANET merge).

     When MANET Internetworking is applied to connect routers in different
     not-so-stubby MANETs, independent local routing domains are
     dynamically joined by an overlay that spans any underlying
     Internetworks as a normal course of operational data communications.
     When two distinct MANET local routing regions merge in this way, the
     MANET local IP addresses present in the source and destination MANETs
     must be mutually exclusive.

     These merge events must further be considered to occur at truly
     unbounded frequencies across the global population due to the
     unpredictable nature of worldwide Internetworking dynamics for peer-
     to-peer communications.  In the limiting case, all worldwide local
     MANET routing regions may be considered to be persistently merged
     over the MANET Internetworking overlay at all times.  Statistical
     uniqueness properties of random assignments from even very large
     populations may therefore be insufficient to ensure collision freedom
     since MANET Internetworking exposes the full world population of
     MANET local addresses as potential duplicates.

     Nodes in not-so-stubby MANETs should therefore configure MANET local
     addresses managed for global uniqueness even if they first self-
     generate the addresses before enrolling them in a registration
     service.  The IPv6 Multilink Local Address (MLA) provides a suitable
     solution for this purpose [I-D.templin-6man-mla].

  3.2.  MANET Autoconfiguration

     When a MANET comes in contact with a fixed Internetwork such as the
     global public Internet, nodes in the MANET that engage global mobile
     Internetworking services require some means of autoconfiguring
     global-scoped IP addresses or prefixes that are properly routable by
     network elements accessible from the current point of attachment.
     These network elements are typically proxies or gateways of some
     variety that connect to the mobile routing system.

     Nodes in the local MANET that are multiple IP hops away from an
     Internet connection sharing peer cannot use unmodified standard
     autoconfiguration services including IPv6 Neighbor Discovery (IPv6ND)
     [RFC4861] or DHCPv6 [RFC8415] over a MANET interface since these
     services are link-scoped in nature.  (The DHCPv6 architecture
     includes a "relay" function, but the dynamic nature of links in
     (multi-link) local MANET routing regions may interfere with
     straightforward application of DHCPv6 relays.)



  Templin & Jakubisin      Expires 24 August 2026                 [Page 6]


  Internet-Draft               AERO/OMNI MANET               February 2026


     To engage in autoconfiguration, the requesting node configures a
     (virtual) overlay multilink network interface over its (physical)
     MANET interface(s) and issues standard link-scoped IPv6ND and/or
     DHCPv6 requests over the virtual interface.  The virtual interface
     applies encapsulation to provide the appearance of a single Non-
     Broadcast Multiple Access (NBMA) link spanning the entire (multilink)
     MANET.  This virtual link supports standard link-scoped
     autoconfiguration services coordinated with an Internetwork element
     capable of delegating IP prefixes.  The Overlay Multilink Network
     (OMNI) Interface specification [I-D.templin-6man-omni3] and its
     companion Automatic Extended Route Optimization (AERO)
     [I-D.templin-6man-aero3] were designed for this purpose.

     All MANET nodes as well as AERO/OMNI Internetwork Proxy/Servers and
     Gateways assign a unique MLA to their OMNI virtual interface.  An
     AERO/OMNI Mobility Anchor Point (MAP) delegates a Mobility Service
     Provider (MSP) Mobile Network Prefix (MNP) as a Provider-Independent
     (PI) IP prefix maintained by the overlay for the requesting node to
     provision on downstream-attached interfaces in the manner discussed
     in [RFC9663] and [RFC9762].  The MAP then returns the delegated MNP
     in a link-scoped reply over the OMNI interface that traverses the
     reverse path to the original requesting node.

     The MLAs assigned as described above are routable within an OMNI link
     limited domain [RFC8799], but may not be routable to peers in other
     domains and/or the open Internet.  MANET nodes therefore also obtain
     globally routable IP MNPs from supporting MAP Proxy/Servers to
     support global-scoped communications; address selection policies
     should prefer these MNP-based addresses when available due to the
     limited domain routable nature of MLAs.

  3.3.  MANET-internal Communications

     Two nodes located within the same local MANET routing region should
     be able to communicate (across multiple hops if necessary) using MLA
     addressing with no external Internetwork infrastructure reference
     points.  As long as the MLAs configured by communicating peers are
     unique, the MANET local routing system maintains continuous multihop
     forwarding services to ensure session continuity.

     Nodes within the local MANET routing region can discover the MLAs
     and/or MNP-based global addresses of peers using Multicast DNS (mDNS)
     [RFC6762] supported by Simplified Multicast Forwarding (SMF)
     [RFC6621].  Peer-to-peer communications can then be coordinated in
     multihop fashion using OMNI encapsulation and header compression over
     an overlay virtual link spanning any MANET intermediate hops in the
     path.




  Templin & Jakubisin      Expires 24 August 2026                 [Page 7]


  Internet-Draft               AERO/OMNI MANET               February 2026


  3.4.  MANET Peer to Internetwork Correspondent

     When an originating peer (or its stub MANET Internet connection-
     sharing node) within a not-so-stubby MANET needs to communicate with
     a correspondent connected elsewhere in an external Internetwork, the
     peer consults the global DNS which returns a (stable) globally-
     routable IP address for the correspondent.  The peer can then use one
     of its MNP-based IP addresses obtained through autoconfiguration and
     the global IP address of the Internetwork correspondent as the source
     and destination addresses for packet exchanges.

     The MANET peer establishes per-flow on-demand virtual circuits in the
     overlay to an Internetwork relay beyond the MANET border.  MANET
     local multihop routing will then convey the peer's original packets
     to the MANET border which then forwards them via the overlay to an
     Internetwork relay which directs the packets to the correspondent
     node.

     In the reverse path, the correspondent uses the MNP-based IP address
     of the peer obtained from the source address of initiating packets as
     the destination address for reply packets.  Standard Internetwork
     routing will direct the packets back to the relay which then forwards
     them via per-flow overlay virtual circuits to the originating peer's
     MANET border.  MANET-local routing and forwarding will then convey
     the packets over one or more MANET-local hops until they ultimately
     reach the peer.

     In this case, the originating peer's IP address need not appear in
     the global DNS since the correspondent discovers the address by
     examining the source of received packets.

  3.5.  Internetwork Correspondent to MANET Peer

     When an Internetwork correspondent needs to communicate with a target
     peer within a local MANET routing region, the correspondent consults
     the global DNS to determine an IP address for the peer.

     The correspondent then forwards packets via standard Internet routing
     until they arrive at a relay.  The relay then establishes per-flow
     virtual circuits in the overlay to the MANET peer while forwarding
     packets via the virtual circuit until they reach the destination.
     Reverse path forwarding from the MANET peer to the Internetwork
     correspondent is then conducted in the same manner described in
     Section 3.4.

     IP addresses covered by delegated prefixes remain stable even across
     MANET-wide mobility events to the point that continuous dynamic
     updates to the DNS are not required to maintain uninterruptable



  Templin & Jakubisin      Expires 24 August 2026                 [Page 8]


  Internet-Draft               AERO/OMNI MANET               February 2026


     communications.  While it is possible that mobility events may cause
     minor temporary disruptions, transport protocol retransmissions will
     maintain continuity for any ongoing sessions.

  3.6.  Peer-to-Peer Between Different MANETs

     When two prospective peer nodes are located in different MANET local
     routing regions separated by one or more transit Internetwork
     segments, both peers should include their IP addresses in global DNS
     resource records for the same reasons cited in Section 3.5.

     The peers then establish per-flow virtual circuits in the overlay to
     support peer-to-peer bidirectional packet forwarding.  The peers may
     use either an MNP address or their MLAs, as the MLAs are routable
     within the overlay limited domain.  The overlay therefore exhibits
     the outward appearance of a MANET-of-MANETs, where overlay interior
     nodes engage in an interdomain global routing service bridging many
     MANET local routing domains.

     A certain degree of coordination between peer nodes and the MSP is
     the required to maintain address mappings.  The MSP is responsible
     for ensuring that each peer remains reachable at its stable MNP/MLA
     addresses through distributed mobility management.

  3.7.  Stub MANET to Not-so-stubby MANET Connections

     When an Internet connection sharing MANET router connects a stub
     MANET, it can either delegate public IP addresses to stub MANET nodes
     or delegate private IP addresses then apply Network Address
     Translation (NAT) to support external communications.

     In the public case, all manners of peer-to-peer communications are
     made possible due to the globally routable nature of the addresses.
     In the NAT case, only communications initiated by a stub network peer
     are supported since the reverse path terminates at the NAT.

     The stub MANET itself may configure a local overlay that regards the
     (multihop) MANET as a single unified link.  In that case, the stub
     network overlay link is distinct from the overlay link that spans the
     global public Internet and the two links are joined by an IPv6
     router.

     In the not-so-stubby case, a single overlay link extends across both
     any transit Internetworks and the source and target MANETs
     themselves.  All peer-to-peer communications are therefore conveyed
     across the common MANET Internetworking overlay.





  Templin & Jakubisin      Expires 24 August 2026                 [Page 9]


  Internet-Draft               AERO/OMNI MANET               February 2026


  4.  IANA Considerations

     This document is informational and does not in itself request any
     IANA actions.  IANA considerations can be found in the solution space
     documents cited.

  5.  Security Considerations

     This document is informational and does not in itself address
     security.  Security considerations can be found in the solution space
     documents cited.

  6.  Acknowledgements

     This work is derived directly from "MANET Internetworking: Problem
     Statement and Gap Analysis" [I-D.templin-manet-inet].

     This work is aligned with the Boeing/Virginia Tech National Security
     Institute (VTNSI) 5G MANET research program.

     Honoring life, liberty and the pursuit of happiness.

  7.  References

  7.1.  Normative References

     [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
                DOI 10.17487/RFC0791, September 1981,
                <https://www.rfc-editor.org/info/rfc791>.

     [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
                (IPv6) Specification", STD 86, RFC 8200,
                DOI 10.17487/RFC8200, July 2017,
                <https://www.rfc-editor.org/info/rfc8200>.

  7.2.  Informative References

     [I-D.templin-6man-aero3]
                Templin, F., "Automatic Extended Route Optimization
                (AERO)", Work in Progress, Internet-Draft, draft-templin-
                6man-aero3-52, 23 January 2026,
                <https://datatracker.ietf.org/doc/html/draft-templin-6man-
                aero3-52>.








  Templin & Jakubisin      Expires 24 August 2026                [Page 10]


  Internet-Draft               AERO/OMNI MANET               February 2026


     [I-D.templin-6man-mla]
                Templin, F., "IPv6 Addresses for Ad Hoc Networks", Work in
                Progress, Internet-Draft, draft-templin-6man-mla-30, 11
                November 2025, <https://datatracker.ietf.org/doc/html/
                draft-templin-6man-mla-30>.

     [I-D.templin-6man-omni3]
                Templin, F., "Transmission of IP Packets over Overlay
                Multilink Network (OMNI) Interfaces", Work in Progress,
                Internet-Draft, draft-templin-6man-omni3-73, 6 February
                2026, <https://datatracker.ietf.org/doc/html/draft-
                templin-6man-omni3-73>.

     [I-D.templin-manet-inet]
                Templin, F. and D. J. Jakubisin, "MANET Internetworking:
                Problem Statement and Gap Analysis", Work in Progress,
                Internet-Draft, draft-templin-manet-inet-02, 12 January
                2026, <https://datatracker.ietf.org/doc/html/draft-
                templin-manet-inet-02>.

     [RFC2501]  Corson, S. and J. Macker, "Mobile Ad hoc Networking
                (MANET): Routing Protocol Performance Issues and
                Evaluation Considerations", RFC 2501,
                DOI 10.17487/RFC2501, January 1999,
                <https://www.rfc-editor.org/info/rfc2501>.

     [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
                for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
                <https://www.rfc-editor.org/info/rfc4429>.

     [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
                "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
                DOI 10.17487/RFC4861, September 2007,
                <https://www.rfc-editor.org/info/rfc4861>.

     [RFC6621]  Macker, J., Ed., "Simplified Multicast Forwarding",
                RFC 6621, DOI 10.17487/RFC6621, May 2012,
                <https://www.rfc-editor.org/info/rfc6621>.

     [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
                DOI 10.17487/RFC6762, February 2013,
                <https://www.rfc-editor.org/info/rfc6762>.

     [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
                Richardson, M., Jiang, S., Lemon, T., and T. Winters,
                "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
                RFC 8415, DOI 10.17487/RFC8415, November 2018,
                <https://www.rfc-editor.org/info/rfc8415>.



  Templin & Jakubisin      Expires 24 August 2026                [Page 11]


  Internet-Draft               AERO/OMNI MANET               February 2026


     [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
                Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
                <https://www.rfc-editor.org/info/rfc8799>.

     [RFC9374]  Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
                "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
                ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
                <https://www.rfc-editor.org/info/rfc9374>.

     [RFC9663]  Colitti, L., Linkova, J., Ed., and X. Ma, Ed., "Using
                DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique
                IPv6 Prefixes per Client in Large Broadcast Networks",
                RFC 9663, DOI 10.17487/RFC9663, October 2024,
                <https://www.rfc-editor.org/info/rfc9663>.

     [RFC9762]  Colitti, L., Linkova, J., Ma, X., Ed., and D. Lamparter,
                "Using Router Advertisements to Signal the Availability of
                DHCPv6 Prefix Delegation to Clients", RFC 9762,
                DOI 10.17487/RFC9762, June 2025,
                <https://www.rfc-editor.org/info/rfc9762>.

  Appendix A.  Change Log

     << RFC Editor - remove prior to publication >>

     Differences from -00 to -01:

     *  Clarified that the routing scope for MLAs is the entire overlay
        limited domain.

     Differences from earlier versions:

     *  First draft publication.

  Authors' Addresses

     Fred L. Templin (editor)
     Boeing Technology Innovation
     P.O. Box 3707
     Seattle, WA 98124
     United States of America
     Email: fltemplin@acm.org









  Templin & Jakubisin      Expires 24 August 2026                [Page 12]


  Internet-Draft               AERO/OMNI MANET               February 2026


     Daniel J. Jakubisin
     National Security Institute, Virginia Tech
     2202 Kraft Dr.
     Blacksburg, VA 24060
     United States of America
     Email: djj@vt.edu













































  Templin & Jakubisin      Expires 24 August 2026                [Page 13]


name: draft-luan-rtgwg-sdaf
rev: 00
title: Symmetry-Driven Asynchronous Forwarding with Fast Reroute for LEO Satellite Networks (SDAF)
time: 2026-02-25T16:20:58Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-08-29T16:20:58Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.058626+00:00
source: ietf
abstract:
  Interior Gateway Protocols (IGPs) such as OSPF are commonly employed
     in satellite networks to address topology awareness and autonomous
     routing in response to link interruptions, link/node failures, and
     subsequent repairs.  However, IGP-based approaches suffer from
     inherent limitations.  Synchronization delays between the control
     plane and the forwarding plane can cause routing black holes, while
     asynchronous convergence across nodes may induce micro-loops (as
     described in prior work), leading to packet loss and congestion.
     These issues are particularly exacerbated in satellite networks
     characterized by highly dynamic topologies, long inter-satellite
     propagation delays, and constrained on-board computing resources.

     This document describes the Symmetry-Driven Asynchronous Forwarding
     (SDAF) mechanism, which leverages the intrinsic symmetry of toroidal
     topologies in satellite networks.  Low Earth Orbit (LEO) satellite
     constellations are typically composed of multiple circular orbital
     planes, forming a toroidal topology by inter-satellite links.  SDAF
     autonomously triggers and processes reverse flows based solely on
     local link-state information, without requiring control-plane
     convergence, protocol extensions, or packet header modifications.

     SDAF is fully compatible with existing protocols and technologies
     such as OSPFv3, IS-IS, and MPLS, and is specifically tailored to the
     resource-constrained nature of satellite systems.  It achieves
     microsecond-scale convergence and low packet loss under failure
     conditions.

     Simulation results and tests conducted on actual satellite routers
     demonstrate that the SDAF mechanism significantly suppresses packet
     loss caused by routing black holes and micro-loops, while also
     alleviating link congestion and packet reordering issues.

full_text:
  rtgwg                                                            S. Luan
  Internet-Draft                                        Beihang University
  Intended status: Informational                                    W. Wei
  Expires: 29 August 2026                                            M. Ke
                                                         Xidian University
                                                                 H. Dongxu
                                                                    X. Min
                                                           ZTE Corporation
                                                          25 February 2026


     Symmetry-Driven Asynchronous Forwarding with Fast Reroute for LEO
                         Satellite Networks (SDAF)
                          draft-luan-rtgwg-sdaf-00

  Abstract

     Interior Gateway Protocols (IGPs) such as OSPF are commonly employed
     in satellite networks to address topology awareness and autonomous
     routing in response to link interruptions, link/node failures, and
     subsequent repairs.  However, IGP-based approaches suffer from
     inherent limitations.  Synchronization delays between the control
     plane and the forwarding plane can cause routing black holes, while
     asynchronous convergence across nodes may induce micro-loops (as
     described in prior work), leading to packet loss and congestion.
     These issues are particularly exacerbated in satellite networks
     characterized by highly dynamic topologies, long inter-satellite
     propagation delays, and constrained on-board computing resources.

     This document describes the Symmetry-Driven Asynchronous Forwarding
     (SDAF) mechanism, which leverages the intrinsic symmetry of toroidal
     topologies in satellite networks.  Low Earth Orbit (LEO) satellite
     constellations are typically composed of multiple circular orbital
     planes, forming a toroidal topology by inter-satellite links.  SDAF
     autonomously triggers and processes reverse flows based solely on
     local link-state information, without requiring control-plane
     convergence, protocol extensions, or packet header modifications.

     SDAF is fully compatible with existing protocols and technologies
     such as OSPFv3, IS-IS, and MPLS, and is specifically tailored to the
     resource-constrained nature of satellite systems.  It achieves
     microsecond-scale convergence and low packet loss under failure
     conditions.

     Simulation results and tests conducted on actual satellite routers
     demonstrate that the SDAF mechanism significantly suppresses packet
     loss caused by routing black holes and micro-loops, while also
     alleviating link congestion and packet reordering issues.



  Luan, et al.             Expires 29 August 2026                 [Page 1]


  Internet-Draft                SDAF for LEO                 February 2026


  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 29 August 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
         1.1.1.  Onboard Characteristics of Satellite Networks . . . .   3
         1.1.2.  Inherent Deficiencies of Asynchronous Convergence . .   4
         1.1.3.  Limitations of Existing Approaches  . . . . . . . . .   4
       1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   5
       1.3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       1.4.  Document Structure  . . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.  Core Principles . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.  Enforcing Routing Paths via Rotational Symmetry . . . . .   7
       3.2.  Forming Forward/Reverse Flows via Reflectional
             Symmetry  . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.  Detailed Procedures . . . . . . . . . . . . . . . . . . . . .   9
       4.1.  Initialization  . . . . . . . . . . . . . . . . . . . . .   9



  Luan, et al.             Expires 29 August 2026                 [Page 2]


  Internet-Draft                SDAF for LEO                 February 2026


       4.2.  Failure/Disruption Detection  . . . . . . . . . . . . . .  10
       4.3.  Reverse-Flow Triggering . . . . . . . . . . . . . . . . .  10
         4.3.1.  RF-CF Policy  . . . . . . . . . . . . . . . . . . . .  10
         4.3.2.  RF-LF Policy  . . . . . . . . . . . . . . . . . . . .  10
       4.4.  Reverse-Flow Forwarding and Transition  . . . . . . . . .  11
       4.5.  Recovery from Failures/Disruptions  . . . . . . . . . . .  11
     5.  Failure Scenario Handling . . . . . . . . . . . . . . . . . .  12
       5.1.  Single-Link Failure . . . . . . . . . . . . . . . . . . .  12
       5.2.  Boundary Conditions and Limitations . . . . . . . . . . .  13
     6.  Interoperability with Existing Protocols and Technologies . .  14
     7.  Key Characteristics . . . . . . . . . . . . . . . . . . . . .  14
       7.1.  Core Advantages . . . . . . . . . . . . . . . . . . . . .  14
       7.2.  Limitations . . . . . . . . . . . . . . . . . . . . . . .  14
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     10. Normative References  . . . . . . . . . . . . . . . . . . . .  15
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  15
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

  1.  Introduction

  1.1.  Problem Statement

  1.1.1.  Onboard Characteristics of Satellite Networks

     The onboard characteristics of satellite networks severely limit the
     applicability of conventional IGP routing approaches.

     Highly Dynamic Topology: In LEO constellations, inter-satellite links
     (ISLs) undergo frequent disruptions due to orbital motion and
     scheduled maneuvers such as solar avoidance -- representing
     predictable dynamics.  Additionally, unpredictable events like
     radiation-induced node or link failures introduce stochastic topology
     changes.  These continuous alterations constantly reshape the network
     topology, triggering repeated routing convergence processes that
     result in significant performance degradation, including packet loss,
     congestion, and reordering.  Traditional IGP schemes are designed for
     relatively stable topologies with sporadic failures and are
     inherently ill-suited to cope with the persistent and rapid dynamics
     inherent in LEO satellite networks.

     Stringent Resource Constraints: Satellite payloads operate under
     strict environmental limitations -- weight, power consumption, and
     thermal dissipation -- which directly constrain onboard computing
     resources.  Compared to terrestrial routers, satellite routers
     typically offer an order-of-magnitude lower CPU processing
     capability, only 1/10 to 1/5 of the memory capacity, and rely on



  Luan, et al.             Expires 29 August 2026                 [Page 3]


  Internet-Draft                SDAF for LEO                 February 2026


     limited solar-powered energy supply.  These constraints make it
     impractical to run high-overhead protocols or sustain intensive,
     continuous computations.  Conventional IGP approaches, however,
     require frequent topology flooding and repeated FIB updates to track
     dynamic changes -- generating substantial control-plane signaling
     traffic that consumes precious inter-satellite bandwidth and imposes
     unsustainable computational loads on resource-constrained satellite
     platforms.

  1.1.2.  Inherent Deficiencies of Asynchronous Convergence

     The asynchronous convergence mechanism inherent in link-state IGP
     routing suffers significantly amplified negative effects in the
     context of satellite networks' highly dynamic topologies and
     stringent resource constraints, directly giving rise to three core
     issues that undermine forwarding continuity and reliability:

     Micro-loops: Asynchronous updates across nodes -- caused by control-
     plane synchronization delays such as IGP flooding and FIB
     installation -- lead to transient forwarding inconsistencies,
     resulting in micro-loops [RFC5715].  In satellite networks, the
     combination of high topology dynamics and long inter-satellite
     propagation delays dramatically extends both the duration and spatial
     scope of these micro-loops, exacerbating packet loss and congestion.

     Routing Black Holes: Upon sudden link or node failures, the control
     plane relies on mechanisms like Hello timeouts (typically >= 1
     second) and subsequent SPF (Shortest Path First) computations (tens
     to hundreds of milliseconds) -- processes that cannot be accelerated
     due to onboard resource limitations.  Consequently, routers retain
     stale FIB entries for extended periods, causing sustained packet
     drops and forming persistent routing black holes that are difficult
     to recover from promptly.

  1.1.3.  Limitations of Existing Approaches

     Current loop-free convergence schemes (e.g., TI-LFA, SPRING) were not
     designed for satellite-specific constraints and thus fail to address
     the above issues:

     *  They assume topological stability and are ill-suited for the
        frequent, constant topology fluctuations in LEO constellations.
        Repeated path precomputation, control-plane flooding, and FIB
        updates result in convergence delays far exceeding millisecond-
        scale requirements while increasing microloop risk.






  Luan, et al.             Expires 29 August 2026                 [Page 4]


  Internet-Draft                SDAF for LEO                 February 2026


     *  They incur significant protocol overhead through extensions (e.g.,
        modified routing messages, new header fields) or continuous
        complex computation (e.g., global path planning, multiple backup
        paths).  Such overhead exceeds the computational, memory, and
        bandwidth budgets of satellite payloads, rendering these solutions
        impractical.

     To achieve global coverage and efficient packet forwarding, LEO
     satellite constellations commonly adopt torus-like topologies,
     constructing the network through symmetric intra-orbit and inter-
     orbit inter-satellite links.  Such architectures exhibit high
     rotational symmetry and a regular, grid-like distribution of inter-
     satellite links (often referred to as Grid+ topology).  This inherent
     structural regularity serves as a natural advantage for mitigating
     the adverse effects of topological dynamics.  Building on this
     foundation, this document proposes the SDAF mechanism.  The core idea
     of SDAF is to leverage the intrinsic symmetry of toroidal topologies
     to alleviate the convergence pressure imposed by frequent topological
     changes, thereby reducing reliance on control-plane coordination.
     SDAF enhances the resilience and reliability of packet forwarding in
     dynamic satellite networks.

  1.2.  Requirements Language

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

  1.3.  Scope

     This document specifies the core design principles, forwarding
     decision procedures, LSD methodology, and integration approaches of
     the SDAF mechanism with link-state routing protocols (e.g., OSPFv3,
     IS-IS) and MPLS label switching.  It does not cover: hardware
     implementation details of SDAF, specific satellite payload hardware
     selection criteria, or extension schemes for non-toroidal topologies
     (which will be addressed in future documents).

  1.4.  Document Structure

     This document is organized as follows:

     *  Section 2 defines key terms and abbreviations.

     *  Section 3 describes the core principles of *SDAF*.




  Luan, et al.             Expires 29 August 2026                 [Page 5]


  Internet-Draft                SDAF for LEO                 February 2026


     *  Section 4 specifies the end-to-end procedures for *SDAF*
        operation.

     *  Section 5 discusses failure scenario handling, including single-
        link, multi-link, and node failures.

     *  Section 6 describes interoperability with *OSPFv3*, *IS-IS*, and
        *MPLS*.

     *  Section 7 summarizes key characteristics, including advantages and
        limitations.

     *  Section 8 discusses security considerations.

     *  Section 9 provides *IANA* considerations.

  2.  Terminology

     Full topology: The complete, fault-free topology of the satellite
     network.

     Defective topology: The connected subgraph of the full topology after
     a failure or disruption.

     Planned disruption: A predictable, temporary unavailability of an ISL
     due to orbital motion or solar avoidance.

     Unplanned failure: An unpredictable outage of an ISL or node due to
     internal or external factors.

     Link-State Detection (LSD): A local mechanism for detecting ISL
     disruptions or failures, with low-latency requirements.

     Hop Distance (HD): The number of hops on the shortest path between
     source and destination.

     Forward Flow (FF): Data forwarding along the shortest path, following
     decreasing Hop Distance (HD).

     Reverse Flow (RF): A temporary forwarding state triggered by failure,
     propagating opposite to FF with increasing HD.

     Primary Egress Interface (PEI): The egress ISL selected by the
     shortest-path algorithm for FF.

     Counter-facing Interface (CFI): The ISL diametrically opposite to the
     PEI within the toroidal topology.




  Luan, et al.             Expires 29 August 2026                 [Page 6]


  Internet-Draft                SDAF for LEO                 February 2026


     Lateral-facing Interface (LFI): The ISL orthogonal to the PEI; if
     multiple exist, the lowest-indexed is used.

     Interface Symmetry Mapping Table (ISMT): A node-local table mapping
     each PEI to its corresponding CFI and LFI.

     Local Interface Status Table (LIST): A node-local array recording the
     availability status of each interface.

     Phase (P): A logical indicator of flow direction: positive for FF,
     negative for RF.

     Phase Transition Point (PTP): A node where RF transitions back to FF,
     identified by the ingress interface not being equal to the local PEI.

     Reverse Flow with Counter-facing priority (RF-CF): An RF strategy
     prioritizing the CFI upon PEI failure.

     Reverse Flow with Lateral-facing priority (RF-LF): An RF strategy
     prioritizing the LFI upon PEI failure.

  3.  Core Principles

     The SDAF mechanism leverages the rotational and reflectional
     symmetries inherent in toroidal topologies to enable autonomous
     forwarding-plane decisions, thereby addressing the core deficiencies
     of traditional routing under dynamic topologies and resource
     constraints.

  3.1.  Enforcing Routing Paths via Rotational Symmetry

     In a ring topology -- a simplified special case of the toroidal
     topology -- satellite nodes are interconnected via intra-orbit ISL to
     form a closed loop, exhibiting 360 degrees rotational invariance.
     For example, the intra-orbital routing domains defined in [RFC9717]
     inherently constitute such ring structures within each orbital plane.
     When a satellite node's PEI becomes unavailable due to failure or
     scheduled interruption, rotational symmetry strictly constrains the
     only feasible detour to the CFI.  This constraint is not unique to
     SDAF.  The IGP routing will inevitably select the CFI, as the
     symmetry of the ring guarantees it is the sole valid route to the
     destination.

     When extended to a two-dimensional toroidal topology -- the typical
     architecture of multi-orbit LEO satellite constellations --
     rotational symmetry exhibits dual-dimensional characteristics.  Both
     the intra-orbit direction and the inter-orbit direction possess
     rotational invariance.  This dual-axis symmetry not only retains the



  Luan, et al.             Expires 29 August 2026                 [Page 7]


  Internet-Draft                SDAF for LEO                 February 2026


     CFI constraint from the one-dimensional ring case but also introduces
     LFIs to the PEI.  Under this structure, a node can determine its CFI
     and LFI solely through local knowledge of interface positions and
     their symmetric mappings in the intra- and inter-orbit dimensions,
     without requiring global topology computation.  Provided the network
     remains connected, both CFI- and LFI-based detours are guaranteed by
     the topological symmetry to reach the destination, ensuring that all
     locally selected recovery paths strictly adhere to the natural
     routing constraints imposed by the constellation's geometric
     regularity.

  3.2.  Forming Forward/Reverse Flows via Reflectional Symmetry

     In a fault-free full topology, all shortest paths from any source
     node to a common destination are symmetric with respect to the mirror
     plane defined by the "destination node-topology center" axis.
     Moreover, these shortest paths always propagate along the minor arc
     -- the shorter segment between two points on the toroidal topology --
     which aligns with the core objective of shortest-path-first routing
     and constitutes the forward flow.

     When the PEI becomes unavailable due to failure or scheduled
     interruption, the forwarding plane autonomously selects either the
     CFI or a LFI based on the preconfigured policy (RF-CF or RF-LF) to
     forward packets before the control plane completes reconvergence.  At
     this point, the forwarding path deviates from the minor arc and
     enters the major arc, propagating in the direction opposite to the
     original shortest path.  Consequently, the HD to the destination no
     longer decreases but instead increases, forming a RF that is
     directionally opposed to the forward flow.

     Due to the constraint of reflection symmetry, once a reverse-flow
     packet crosses the mirror plane and re-enters the minor-arc region,
     it inevitably arrives at a PTP.  Here, the reflection symmetry
     inherently triggers an automatic switch in forwarding logic.  The
     packet ceases to propagate as a reverse flow along the major arc and
     instead transitions back to a forward flow along the minor arc,
     resuming adherence to the shortest-path-first routing strategy and
     continuing toward the destination.  This bidirectional flow
     transition occurs entirely without control-plane intervention, driven
     solely by topological reflection symmetry and local forwarding
     decisions, thereby ensuring continuous and reliable data delivery.









  Luan, et al.             Expires 29 August 2026                 [Page 8]


  Internet-Draft                SDAF for LEO                 February 2026


  4.  Detailed Procedures

     All procedures of the SDAF mechanism are executed locally within the
     forwarding plane without requiring inter-node coordination.  The core
     process consists of five steps: initialization, fault/interruption
     detection, reverse-flow triggering, reverse-flow forwarding and
     convergence, and fault/interruption recovery.

  4.1.  Initialization

     Before forwarding any data packets, each satellite node needs only to
     complete three local configuration and preparation steps.  The
     configuration logic depends on the number of node interfaces but is
     independent of the number of destinations:

     1.  Configure Interface Symmetry Mapping Table: Based on the complete
         physical topology connectivity, a static interface symmetry
         mapping table is preconfigured locally at each node for every
         physical interface.

     2.  Configure Reverse-Flow Policy: Choose one of two mutually
         exclusive policies of RF-CF or RF-LF.

         All nodes in the network MUST maintain consistent policy
         selection.

     3.  Initialize Link-State Detection (LSD): Enable the LSD mechanism,
         such as heartbeat packets or physical-layer signal monitoring, on
         all inter-satellite link (ISL) interfaces.

                                         B
                                         |
                                 CLI:2   |   CLI:3
                                 FLI:1,3 |   FLI:2,4
                                         |
                                       4 | 1
                                E -------A------- C
                                       3 | 2
                                         |
                                 CLI:1   |   CLI:4
                                 FLI:2,4 |   FLI:1,3
                                         |
                                         D

        Figure 1: Example local interface indexing and symmetry mapping
                             (CLI/FLI) for node A.





  Luan, et al.             Expires 29 August 2026                 [Page 9]


  Internet-Draft                SDAF for LEO                 February 2026


  4.2.  Failure/Disruption Detection

     When a terminal on a satellite link meets either of the following
     conditions, the local interface status table is triggered to mark the
     corresponding interface as "unavailable":

     Failure: The Link-State Detection (LSD) mechanism detects that an
     interface has gone down or that its forwarding quality falls below
     the required threshold.

     Scheduled Interruption: The pre-provisioned interruption schedule
     from the control plane indicates that the current time has reached
     the designated moment for deactivating the interface.

  4.3.  Reverse-Flow Triggering

     When an interface is marked as "unavailable," any data packet that,
     according to the forwarding table, would egress through that
     interface as its PEI immediately triggers the reverse-flow mechanism.
     This occurs without waiting for the control plane to synchronize
     link-state updates or complete network-wide reconvergence.  The
     execution logic for the two reverse-flow policies is as follows.

  4.3.1.  RF-CF Policy

     The node first checks its local interface status table to determine
     whether the CFI is available:

     *  If the CFI is available, the packet is immediately forwarded
        through the CFI, thereby initiating a reverse flow.

     *  If the CFI is unavailable, the node inspects the two LFIs in the
        preconfigured order and selects the first available LFI for
        forwarding.

     *  If neither the CFI nor any LFI is available, the node is
        considered isolated, and the packet is dropped by default.

  4.3.2.  RF-LF Policy

     The node first checks its local interface status table in the
     preconfigured order to determine the availability of the two LFIs and
     selects the first available LFI to forward the packet, thereby
     initiating a reverse flow.

     If both LFIs are unavailable, the node then checks the availability
     of the CFI:




  Luan, et al.             Expires 29 August 2026                [Page 10]


  Internet-Draft                SDAF for LEO                 February 2026


     *  If the CFI is available, the packet is forwarded through the CFI.

     *  If the CFI is also unavailable, the node is considered isolated,
        and the packet is dropped by default.

  4.4.  Reverse-Flow Forwarding and Transition

     Upon receiving a data packet forwarded from another satellite node,
     any node processes it according to the following logic:

     1.  Record the ingress interface and consult the local forwarding
         table to determine the PEI associated with the packet's
         destination.

     2.  Compare the ingress interface with the local PEI:

         Case (1): Ingress interface matches the local PEI

         The receiving node identifies the packet as part of a reverse
         flow.  It then executes the reverse-flow handling procedure
         specified in Section 4.3.1 or Section 4.3.2, based on its
         preconfigured reverse-flow strategy.

         Case (2): Ingress interface differs from the local PEI

         The node forwards the packet via its local PEI.

         *  If the packet belongs to a forward flow, this step constitutes
            normal forwarding.

         *  If the packet belongs to a reverse flow, the current node acts
            as a PTP, where the reverse flow is converted back into a
            forward flow.

     Once a reverse flow is converted to a forward flow at a PTP, the
     packet proceeds toward its destination using standard forward-path
     forwarding logic.  However, if a link failure or scheduled
     interruption occurs along this newly established forward path, the
     reverse-flow mechanism is triggered again locally.  This cycle of
     forward-reverse flow switching continues iteratively until either the
     packet successfully reaches its destination or the hop count exceeds
     a predefined limit, at which point the packet is discarded.

  4.5.  Recovery from Failures/Disruptions

     The local interface status table marks an interface as "available"
     when the terminal on a satellite link satisfies either of the
     following conditions:



  Luan, et al.             Expires 29 August 2026                [Page 11]


  Internet-Draft                SDAF for LEO                 February 2026


     Failure Recovery: The Link-State Detection (LSD) mechanism detects
     that a previously failed interface has come back up or that its
     forwarding quality has returned to an acceptable level.

     Scheduled Interruption Recovery: According to the interruption
     schedule pre-provisioned by the control plane, the current time
     reaches the designated moment for restoring the interface.

     Once the local interface status is updated to "available", the
     following actions are performed:

     *  Newly arriving packets whose destination maps to this interface as
        the PEI are immediately forwarded through it using the standard
        forward-flow logic.

     *  In-flight reverse-flow packets, which were already en route before
        the recovery, continue unchanged until they reach a PTP, where
        they revert to forward flow as originally planned.  This ensures
        continuity and avoids mid-path disruption, even before the control
        plane completes any associated reconvergence triggered by the
        recovery event.

  5.  Failure Scenario Handling

     The SDAF mechanism is specifically designed for typical failure and
     scheduled interruption scenarios in LEO satellite networks with
     toroidal topologies.  All considered scenarios operate under the
     fundamental assumption that the impaired topology remains a connected
     subgraph of the full physical topology.  In cases where the topology
     becomes partitioned (i.e., splits into disconnected components), the
     mechanism, like conventional loop-free convergence schemes such as
     [RFC5715] , cannot guarantee reachability or path restoration.

     This section explicitly defines, for each failure scenario, the
     triggering conditions of the SDAF mechanism, the applicable reverse-
     flow policy selection, and the core reliability guarantees provided
     by the design.

  5.1.  Single-Link Failure

     The single-link failure scenario applies to unpredictable failures or
     predictable interruptions affecting a single intra-orbit or inter-
     orbit ISL, under the condition that the toroidal or torus-like
     topology remains connected and both endpoints of the failed link
     retain at least one available symmetric interface.  Upon detecting
     the failure via LSD or receiving a scheduled interruption
     notification from the control plane, each endpoint marks the
     corresponding PEI as "unavailable" and immediately triggers a reverse



  Luan, et al.             Expires 29 August 2026                [Page 12]


  Internet-Draft                SDAF for LEO                 February 2026


     flow according to its preconfigured policy, rerouting traffic to
     bypass the faulty link.  Reverse-flow packets automatically switch
     back to forward flow at the nearest PTP, achieving loop-free
     convergence.  For intra-orbit link failures or ring-like topologies,
     RF-CF is preferred to leverage symmetric intra-orbit paths for rapid
     detour.  For inter-orbit link failures or when inter-orbit resources
     are sufficient, RF-LF is favored to avoid latency accumulation from
     intra-orbit looping.  Overall, this approach ensures micro-loop-free
     rerouting strictly bounded by topological symmetry and enables
     millisecond-scale, control-plane-independent data-plane recovery with
     minimal packet loss.  As shown in the figure below.

                                   (1)
                                <---- A_1 A_2
                                ---------A---------
                               | ---->       ----> |
                            B_1|    (4)       (5)  |G_2
                               B                   G
                         |  B_2|  ^                |G_1 |
                      (2)|     |  | (3)            |    |(6)
                         v  C_1|  |                |F_2 v
                               C                   F
                            C_2|                   |F_1 |
                               X                   |    |(7)
                            D_1|        (8)        |E_2 v
                               D       <----       E
                            D_2 ------------------- E_1

         Figure 2: Example reverse-flow forwarding and phase transition
                       (numbered steps are illustrative).

  5.2.  Boundary Conditions and Limitations

     The SDAF mechanism provides fault-handling capabilities only for
     "connected impaired topologies", that is, scenarios where the network
     remains a single connected component despite link or node failures.
     If the topology becomes partitioned into multiple disconnected
     subgraphs, SDAF cannot construct valid end-to-end paths, and recovery
     must rely on higher-layer mechanisms such as routing protocol
     reconvergence.

     For predictable interruption scenarios (e.g., scheduled maintenance,
     orbital maneuvers), the handling logic is identical to that of
     equivalent failure types, with the sole difference lying in the
     failure detection phase.  Instead of relying on LSD for real-time
     anomaly identification, nodes receive advance notifications from the
     control plane about the timing of the upcoming interruption.




  Luan, et al.             Expires 29 August 2026                [Page 13]


  Internet-Draft                SDAF for LEO                 February 2026


  6.  Interoperability with Existing Protocols and Technologies

     The SDAF mechanism is independent of protocols and requires no
     modifications to existing IGP routing protocols (e.g., OSPFv3, IS-IS)
     or forwarding technologies (e.g., IP forwarding, MPLS) commonly used
     in LEO satellite networks.

  7.  Key Characteristics

  7.1.  Core Advantages

     Dynamic Topology Adaptation: By leveraging the symmetry of the
     toroidal topology, SDAF enables resilient forwarding in dynamic
     scenarios such as link outages or node failures, without waiting for
     control-plane convergence, thereby reducing packet loss through
     asynchronous forwarding.

     Low Control-Plane Overhead: For link failures, forwarding decisions
     can be made solely based on local Link-State Detection and interface
     mapping tables, eliminating the need for control-plane flooding, SPF
     computation, or pre-planned path calculation, significantly reducing
     satellite resource consumption.

     Microsecond-Level Convergence: In the event of a failure, path
     switching is rapidly triggered via locally initiated reverse flows,
     achieving convergence latency of less than 1 ms, significantly faster
     than the tens to hundreds of milliseconds required by traditional
     approaches.

     Strong Protocol Compatibility: It can be directly integrated with
     link-state routing protocols such as OSPFv3 and IS-IS, as well as
     MPLS label forwarding, without requiring any modifications to
     protocol message formats or packet headers.

  7.2.  Limitations

     The limitations of SDAF stem from its core design principle of
     relying on the symmetry of the toroidal topology, specifically
     including ineffective forwarding in highly asymmetric scenarios and
     increased transmission latency due to non-shortest-path forwarding.

  8.  Security Considerations

     The SDAF mechanism inherits the security properties of existing LEO
     satellite communication protocols and introduces only a minimal
     additional attack surface.  Below are the key security considerations
     for LEO satellite constellations with a toroidal topology:




  Luan, et al.             Expires 29 August 2026                [Page 14]


  Internet-Draft                SDAF for LEO                 February 2026


     Link-State Spoofing: An attacker could forge link-failure signals to
     trigger unauthorized reverse flows.

     Mitigation: Link-State Detection (LSD) MUST rely on authenticated
     mechanisms at the physical or data link layer (e.g., frame checksums,
     signal characteristic verification) or leverage existing protocol
     authentication extensions (e.g., OSPFv3 authentication mechanisms
     [RFC4552]) to prevent false failure indications from triggering
     reverse flows.

  9.  IANA Considerations

     This document has no IANA actions.

  10.  Normative References

     [RFC9717]  Li, T., "A Routing Architecture for Satellite Networks",
                RFC 9717, DOI 10.17487/RFC9717, January 2025,
                <https://www.rfc-editor.org/info/rfc9717>.

     [RFC5715]  Shand, M. and S. Bryant, "A Framework for Loop-Free
                Convergence", RFC 5715, DOI 10.17487/RFC5715, January
                2010, <https://www.rfc-editor.org/info/rfc5715>.

     [RFC4552]  Gupta, M. and N. Melam, "Authentication/Confidentiality
                for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
                <https://www.rfc-editor.org/info/rfc4552>.

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

  Acknowledgments

     The authors would like to thank colleagues and reviewers for their
     valuable feedback.

  Contributors

     None.

  Authors' Addresses




  Luan, et al.             Expires 29 August 2026                [Page 15]


  Internet-Draft                SDAF for LEO                 February 2026


     Shenshen Luan
     Beihang University
     Email: luanshenshen@buaa.edu.cn


     Wenting Wei
     Xidian University
     Email: wtwei@xidian.edu.cn


     Mingliang Ke
     Xidian University
     Email: ml.ke.xidian@foxmail.com


     Hou Dongxu
     ZTE Corporation
     Email: hou.dongxu@zte.com.cn


     Xiao Min
     ZTE Corporation
     Email: xiao.min2@zte.com.cn




























  Luan, et al.             Expires 29 August 2026                [Page 16]


name: draft-mw-wimse-transitive-attestation
rev: 00
title: Transitive Attestation for Sovereign Workloads: A WIMSE Profile
time: 2026-02-26T03:22:45Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-08-30T03:22:45Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.062106+00:00
source: ietf
abstract:
  This document defines a *WIMSE Profile* for Transitive Attestation
     within the Workload Identity in Multi-Service Environments (WIMSE)
     framework.  It addresses the critical problem of *Identity
     Portability*, where software credentials (e.g., bearer tokens or
     keys) can be misappropriated and used from unauthorized
     environments—a risk amplified by the emergence of autonomous *AI
     Agents* that may move across jurisdictions or be hijacked via *prompt
     injection attacks*. By providing a standardized *Identity Conveyance*
     mechanism, this profile cryptographically binds software workloads to
     their local execution environment ("Proof of Residency") through a
     transitive chain of trust.  This chain consumes *Evidence* from the
     underlying platform—supporting both *high-assurance* RATS-based
     profiles (e.g., [[!I-D.lkspa-wimse-verifiable-geo-fence]]) for
     residency verification and *standard* Workload Identity Agents for
     basic co-location proofs—to ensure that an identity is only valid
     when used from a verified, integral, or geographically compliant
     host.  The integrity and hardware-rooted security of the Workload
     Identity Agent itself is considered out-of-scope for this document
     and is addressed in the *Verifiable Geofencing* profile [[!I-D.lkspa-
     wimse-verifiable-geo-fence]].

full_text:
  WIMSE                                                        R. Krishnan
  Internet-Draft                                       JPMorgan Chase & Co
  Intended status: Informational                                 A. Prasad
  Expires: 29 August 2026                                           Oracle
                                                                  D. Lopez
                                                                Telefonica
                                                              S. Addepalli
                                                                    Aryaka
                                                          25 February 2026


      Transitive Attestation for Sovereign Workloads: A WIMSE Profile
                  draft-mw-wimse-transitive-attestation-00

  Abstract

     This document defines a *WIMSE Profile* for Transitive Attestation
     within the Workload Identity in Multi-Service Environments (WIMSE)
     framework.  It addresses the critical problem of *Identity
     Portability*, where software credentials (e.g., bearer tokens or
     keys) can be misappropriated and used from unauthorized
     environments—a risk amplified by the emergence of autonomous *AI
     Agents* that may move across jurisdictions or be hijacked via *prompt
     injection attacks*. By providing a standardized *Identity Conveyance*
     mechanism, this profile cryptographically binds software workloads to
     their local execution environment ("Proof of Residency") through a
     transitive chain of trust.  This chain consumes *Evidence* from the
     underlying platform—supporting both *high-assurance* RATS-based
     profiles (e.g., [[!I-D.lkspa-wimse-verifiable-geo-fence]]) for
     residency verification and *standard* Workload Identity Agents for
     basic co-location proofs—to ensure that an identity is only valid
     when used from a verified, integral, or geographically compliant
     host.  The integrity and hardware-rooted security of the Workload
     Identity Agent itself is considered out-of-scope for this document
     and is addressed in the *Verifiable Geofencing* profile [[!I-D.lkspa-
     wimse-verifiable-geo-fence]].

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





  Krishnan, et al.         Expires 29 August 2026                 [Page 1]


  Internet-Draft               WIMSE-TRANS-POR               February 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 29 August 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Scope and Boundaries  . . . . . . . . . . . . . . . . . . . .   4
     4.  The Solution: Transitive Attestation for Proof of
             Residency . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  mTLS-based Transitive Attestation . . . . . . . . . . . .   5
         4.1.1.  mTLS PoR Protocol Flow  . . . . . . . . . . . . . . .   5
       4.2.  Demonstrating Proof of Residency (DPoR) . . . . . . . . .   6
         4.2.1.  DPoR Protocol Flow  . . . . . . . . . . . . . . . . .   6
       4.3.  Confidential Computing and Hardware-Rooted Binding  . . .   7
         4.3.1.  Logical Quoting Enclave . . . . . . . . . . . . . . .   7
         4.3.2.  Channel Binding via TLS Exporter  . . . . . . . . . .   8
         4.3.3.  Relying Party Verification Loop . . . . . . . . . . .   8
     5.  Relation to Other IETF Work . . . . . . . . . . . . . . . . .   9
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     This document defines the *WIMSE Profile* for "Transitive
     Attestation", addressing a critical technical gap in the high-level
     *WIMSE Architecture* [[!I-D.ietf-wimse-arch]] regarding how platform-
     level trust is transitively extended to software workloads.




  Krishnan, et al.         Expires 29 August 2026                 [Page 2]


  Internet-Draft               WIMSE-TRANS-POR               February 2026


     Currently, workload identities are often "context-agnostic"—once a
     credential (e.g., a bearer token) is issued, it can often be used
     from any environment.  This *Identity Portability* allows an attacker
     who steals a token in one jurisdiction to use it from another,
     representing a significant *Sovereignty Violation* for workloads
     legally required to operate within specific boundaries.  This is
     particularly critical for *AI Agents*, whose autonomous nature,
     susceptibility to hijacking via *prompt injection attacks*, and
     potential for rapid migration across cloud environments require
     strict, verifiable adherence to data residency and host integrity
     policies.

     By addressing the *North-South* security axis of a workload's
     relationship with its local hosting environment, this profile
     establishes a *"Silicon-to-SVID"* chain of accountability.  It
     ensures that the Workload Identity Agent (the local agent) is
     empowered to issue identities that are cryptographically bound to a
     verified execution context.  This mechanism is flexible across
     assurance levels: it supports *High Assurance* residency verification
     rooted in hardware evidence (e.g., TPM/TEE), as well as *Standard
     Assurance* local co-location proofs provided by conventional workload
     agents.

     This draft acts as the *Conveyance Layer* that integrates with the
     findings of a *RATS Profile* (such as *Verifiable Geofencing* [[!I-
     D.lkspa-wimse-verifiable-geo-fence]]) to establish two distinct
     levels of assurance:

     *  *Co-location Verification*: A logical binding that ensures the
        workload and its agent are currently co-located on the same host,
        typically enforced via operating system isolation and local
        communication channels (e.g., Unix Domain Sockets).
     *  *Residency Verification (High Assurance)*: A high-assurance
        binding where the Workload Identity Agent itself is proven to be
        integral and rooted in hardware.  This ensures the identity is
        functionally "sticky" to the verified residence via a *Fast Path*
        renewal which uses cached attestation results.

     A workload obtains a fresh signature or proof from a local Workload
     Identity Agent, typically utilizing a *Workload Fusion Nonce
     (N_fusion)* to prevent replay.  This ensures the identity—and the
     usage of its associated credentials—is sensitive to the physical or
     logical residence of the workload, complementing the "East-West"
     delegation models.  Re-attestation follows a *Tiered Schedule* (see
     [[!I-D.lkspa-wimse-verifiable-geo-fence]]), separating frequent
     identity renewal from heavyweight platform evidence collection.





  Krishnan, et al.         Expires 29 August 2026                 [Page 3]


  Internet-Draft               WIMSE-TRANS-POR               February 2026


  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 leverages the terminology defined in the RATS
     Architecture [[RFC9334]] and the WIMSE Architecture [[!I-D.ietf-
     wimse-arch]].

     Workload Identity Agent (Workload Identity Agent):  A local entity
        that acts as an *Attester* or *Attestation Intermediate* in the
        RATS framework.  It is responsible for providing Evidence or
        Attestation Results to a workload.
     Proof of Residency (PoR) / Co-location:  A cryptographic proof that
        binds a workload's current execution session to a specific,
        verified local environment or host.
     N_fusion (Workload Fusion Nonce):  A nonce provided by the Relying
        Party specifically for the workload-to-agent fusion flow.  It
        ensures the freshness of the residency proof and cryptographically
        binds the workload's request to the local agent's attestation.

     Workload identities are often represented by bearer tokens or keys
     that, once compromised, can be used by an attacker from any
     environment.  This "portability" allows an attacker who achieves RCE
     on a workload (e.g., in Region A) or hijacks an AI agent's logic via
     *prompt injection* to use the stolen keys or intercepted tokens from
     an attacking machine (e.g., in Region B).

     In the context of *Sovereign Workloads*, this portability is more
     than a technical vulnerability; it is a *Sovereignty Violation*. If a
     workload is legally or logically required to operate within a
     specific jurisdiction, any identity that can be successfully verified
     from outside that jurisdiction represents a failure of the sovereign
     boundary.  Relying Parties currently lack a standardized way to
     ensure that a presented identity is being used from the same verified
     host that was originally authorized.

  3.  Scope and Boundaries

     This document focuses on the *Identity Conveyance* and *Session
     Binding* mechanisms required for Transitive Attestation.  It
     standardizes how a workload proves its co-location with a local agent
     and how that proof is bound to application sessions (e.g., mTLS or
     DPoP).




  Krishnan, et al.         Expires 29 August 2026                 [Page 4]


  Internet-Draft               WIMSE-TRANS-POR               February 2026


     The following areas are explicitly *OUT OF SCOPE* for this profile:

     *  *Agent Identity and Integrity*: The mechanism by which a Workload
        Identity Agent (e.g., SPIRE Agent) proves its own identity and
        code integrity to a remote verifier.
     *  *Platform Attestation*: The collection and verification of
        hardware-level evidence (TPM quotes, TEE measurements) for the
        host platform.
     *  *Workload Identity Manager Interactions*: The specific protocols
        and APIs for obtaining nonces or credentials from a *Workload
        Identity Manager (WIM Manager)* during the issuance phase (e.g.,
        SVID CSRs).

     These security guarantees are provided by the underlying *RATS
     Profile* for *Verifiable Geofencing* [[!I-D.lkspa-wimse-verifiable-
     geo-fence]].  This WIMSE profile assumes that the Workload Identity
     Agent is operating in a verified, integral state as established by
     the Geofencing layer.

  4.  The Solution: Transitive Attestation for Proof of Residency

     "Transitive Attestation" establishes a chain of trust from a hardware
     root through a local agent to the workload.  The Workload Identity
     Agent provides the workload with a "live" proof that it is currently
     resident on the verified host.  This local peer-to-peer connection is
     typically enforced through a *Unix Domain Socket (UDS)*, providing a
     kernel-level guarantee that the workload is co-located with the
     hardware-rooted agent.

  4.1.  mTLS-based Transitive Attestation

     In an mTLS environment, the Proof of Residency (PoR) is bound to the
     mutually authenticated session and the local execution context via a
     transitive chain of trust.

  4.1.1.  mTLS PoR Protocol Flow

     The mTLS-based flow integrates residency verification into the
     session establishment and validation phase:

     1.  *Certificate Extensions*: The client (workload) supplies an X.509
         certificate during the mTLS handshake containing a custom
         extension.  This extension includes the public key or SVID
         details of the local Workload Identity Agent (Attester).
     2.  *Post-Handshake Nonce*: After the mTLS handshake is successfully
         completed, the client requests a residency-specific nonce from
         the *Verifier* (e.g., Relying Party) to ensure anti-replay.




  Krishnan, et al.         Expires 29 August 2026                 [Page 5]


  Internet-Draft               WIMSE-TRANS-POR               February 2026


     3.  *Local Attestation Binding*: The client constructs a PoR
         assertion payload containing:
         *  A cryptographic hash of the TLS Exporter value [[RFC5705]].
         *  The residency nonce provided by the server.
         *  A timestamp representing the current time of assertion
            creation.

     |  [!NOTE] By binding to the TLS Exporter instead of the application
     |  traffic keys, the Proof of Residency remains valid across TLS 1.3
     |  KeyUpdate operations.  Standard key rotation refreshes traffic
     |  keys but does not change the exporter master secret, thus avoiding
     |  unnecessary re-attestation cycles while maintaining strong
     |  cryptographic binding to the session.

     4.  *Agent Signature*: The client sends this payload to the local
         Workload Identity Agent (typically via a Unix Domain Socket).
         The Workload Identity Agent verifies the local peer environment
         and signs the payload with its private key.
     5.  *PoR Submission*: The client sends this attested response to the
         resource server for verification.
     6.  *Server Verification*: The *Verifier* performs a joint
         verification of identity and residency:
         *  *Identity*: Verifies the client certificate as part of
            standard mTLS.
         *  *Residency*: Verifies the PoR assertion signature against the
            Workload Identity Agent public key found in the client's
            certificate extension.
         *  *Binding and Freshness*: Ensures that the TLS Exporter hash,
            the nonce, and the timestamp match the current active session
            and are within an acceptable freshness window.

     Upon successful verification, the resource server has proof that the
     client identity (presented via mTLS) is currently resident in the
     same authorized environment as the verified Workload Identity Agent.

  4.2.  Demonstrating Proof of Residency (DPoR)

     "Demonstrating Proof of Residency" (DPoR) is an enhancement to the
     Demonstrating Proof-of-Possession (DPoP) mechanism defined in
     [[RFC9449]].  While DPoP ensures _possession_ of a private key held
     by the client, DPoR ensures the physical or logical _residency_ of
     the workload using that key by binding the request to a local
     attestation.

  4.2.1.  DPoR Protocol Flow

     The DPoR flow integrates residency verification into the per-request
     application-level authorization:



  Krishnan, et al.         Expires 29 August 2026                 [Page 6]


  Internet-Draft               WIMSE-TRANS-POR               February 2026


     1.  *Nonced Request*: The *Verifier* SHOULD provide a residency-
         specific nonce (e.g., via a DPoR-Nonce header) to the client to
         ensure anti-replay of the residency proof.
     2.  *Local Attestation Binding*: The client constructs a DPoR
         assertion payload containing:
         *  The hash of the DPoP public key used for the request (e.g.,
            the jkt thumbprint).
         *  The residency nonce provided by the server.
         *  A timestamp representing the current time of assertion
            creation.
     3.  *Agent Signature*: The client sends this payload to the local
         Workload Identity Agent (typically via a Unix Domain Socket).
         The Workload Identity Agent (acting as an Attester) verifies the
         local execution context and signs the payload with its private
         key.
     4.  *DPoR Assertion Submission*: The client includes the resulting
         signature in a DPoR header or as an extension to the DPoP JWT.
     5.  *Server Verification*: The *Verifier* performs a joint
         verification of possession and residency:
         *  *Possession*: Verifies the DPoP proof as per [[RFC9449]].
         *  *Residency*: Verifies the DPoR assertion signature against the
            Workload Identity Agent public key.
         *  *Binding and Freshness*: Ensures that the jkt (DPoP key
            thumbprint), the nonce, and the timestamp in the residency
            proof match the current request and are within an acceptable
            freshness window.

     This binding ensures that a DPoP key cannot be "exported" and used
     from a different machine, as the resource server would detect the
     lack of a valid, hardware-rooted residency proof for that specific
     key from the new environment.

  4.3.  Confidential Computing and Hardware-Rooted Binding

     In Confidential Computing (CC) environments, the Relationship between
     high-level workload identities and hardware-rooted evidence is
     formalized through specific architectural patterns.  This section
     details how Transitive Attestation bridges the gap between hardware
     quotes and application-layer identities.

  4.3.1.  Logical Quoting Enclave

     In a Transitive Attestation model, trust is passed through a chain of
     components.

     *  *Hardware Layer*: A Confidential Computing environment (e.g.,
        Intel TDX or SGX) provides a "Hardware Root of Trust."




  Krishnan, et al.         Expires 29 August 2026                 [Page 7]


  Internet-Draft               WIMSE-TRANS-POR               February 2026


     *  *Intermediate Layer (Workload Identity Agent)*: In this profile,
        the Workload Identity Agent (e.g., a SPIRE Agent) is treated as
        the trusted software component that "vouches" for the workloads.
     *  *Logical Equivalent*: By running the Workload Identity Agent
        inside a TEE (Trusted Execution Environment), the hardware can
        attest to the integrity of the agent.  This allows the agent to
        act as a "Compliance Bridge" as defined in [[!I-D.lkspa-wimse-
        verifiable-geo-fence]].  Just as a hardware *Quoting Enclave (QE)*
        signs a local report to turn it into a globally verifiable
        "Quote," the Workload Identity Agent (running in a TEE) signs
        Workload Identity Documents (SVIDs/WITs).  Effectively, the agent
        becomes a _logical_ quoting enclave that bridges hardware-rooted
        trust to software-level workload identities.

  4.3.2.  Channel Binding via TLS Exporter

     To prevent man-in-the-middle (MITM) and replay attacks, the hardware
     evidence must be cryptographically bound to the communication
     channel.  This is achieved using the *TLS Exporter* [[RFC5705]].

     *  *The Mechanism*: RFC 5705 allows both sides of a TLS session to
        derive a unique, secret value (the Exporter) that is bound to that
        specific handshake.
     *  *The Binding*: The workload places a hash of this TLS Exporter
        value into the *User Defined Data* field of the CC quote (e.g.,
        ReportData in SGX or RTMR in TDX).
     *  *Security Property*: This cryptographically binds the hardware
        evidence to that specific TLS session.  If an attacker attempts to
        reuse the same quote on a different TLS session, the Exporter
        values will not match, and the verification will fail.

  4.3.3.  Relying Party Verification Loop

     The Relying Party (Verifier) completes the trust loop by performing
     the following steps:

     |  [!NOTE] The Relying Party (which may be the Resource Server or an
     |  API Gateway/Proxy acting on its behalf) extracts the TLS Exporter
     |  value.

     1.  *Hardware Verification*: Receives the CC Quote and verifies the
         hardware signature (proving the code is running in a real TEE).
     2.  *Extractor*: Extracts the TLS Exporter value (or its hash) from
         the quote's metadata (User Defined Data).
     3.  *Comparison*: Compares this value to its own locally computed TLS
         Exporter value for the current active connection.





  Krishnan, et al.         Expires 29 August 2026                 [Page 8]


  Internet-Draft               WIMSE-TRANS-POR               February 2026


     4.  *Enforcement*: If they match, the Relying Party is certain that
         the entity it is talking to via TLS is the _exact same entity_
         that generated the hardware attestation.

     This architecture ensures that identity is not just a bearer token,
     but is cryptographically tied to the verified runtime environment and
     the specific communication channel.

  5.  Relation to Other IETF Work

      +==============+==============+=========+=========================+
      | Layer        | Component    | WG      | Core Responsibility     |
      +==============+==============+=========+=========================+
      | *Layer 1*    | *Transitive  | *WIMSE* | *Conveyance*: Binds     |
      |              | Attestation* |         | identity to the local   |
      |              |              |         | agent (Co-location/     |
      |              |              |         | Residency).             |
      +--------------+--------------+---------+-------------------------+
      | *Layer 2*    | *Verifiable  | *RATS*  | *Platform Evidence*:    |
      |              | Geofencing*  |         | Verifies host integrity |
      |              |              |         | and Workload Identity   |
      |              |              |         | Agent hardware          |
      |              |              |         | residency (TPM).        |
      +--------------+--------------+---------+-------------------------+
      | *Layer 3*    | *Verifiable  | *RATS*  | *Location Evidence*:    |
      |              | Geofencing*  |         | Verifies physical       |
      |              |              |         | geography (GNSS/ZKP).   |
      +--------------+--------------+---------+-------------------------+
      | *Delegation* | *Actor       | *SPICE* | Provides *East-West*    |
      |              | Chain*       |         | identity delegation     |
      |              |              |         | proof [[!I-D.draft-mw-  |
      |              |              |         | spice-actor-chain]].    |
      +--------------+--------------+---------+-------------------------+
      | *Shield*     | *SPICE*      | *SPICE* | Employs Selective       |
      |              |              |         | Disclosure (SD-CWT) to  |
      |              |              |         | protect residency/      |
      |              |              |         | geographic privacy.     |
      +--------------+--------------+---------+-------------------------+

                                    Table 1

     1.  *Transitive Attestation (WIMSE) - Layer 1 (Conveyance)*: This
         document act as the technical integrator profile for WIMSE.  It
         standardizes how local context results are transitively extended
         to workloads.  It reflects its status as the *Consumer* of
         attestation results to address the *North-South* identity
         portability problem.




  Krishnan, et al.         Expires 29 August 2026                 [Page 9]


  Internet-Draft               WIMSE-TRANS-POR               February 2026


     2.  *Verifiable Geofencing (RATS) - Layer 2 & 3 (Evidence)*: Defined
         in [[!I-D.lkspa-wimse-verifiable-geo-fence]].  This document acts
         as the *RATS Profile* that provides the hardware-rooted
         foundation (TPM, Silicon Root of Trust, GNSS) and the out-of-band
         monitoring required to verify the Workload Identity Agent itself.
         It generates the high-assurance evidence that Layer 1 consumes.
     3.  *Actor Chain - The Delegation*: Complements this draft by
         addressing the *East-West* axis of agent-to-agent communication
         [[!I-D.draft-mw-spice-actor-chain]].  While Transitive
         Attestation proves _where_ an actor is running (North-South), the
         Actor Chain proves _who_ called whom across the network (East-
         West).
     4.  *SPICE (Secure Patterns for Internet Credential Exchange) - The
         Shield*: Utilizes Selective Disclosure (SD-CWT) to protect
         sensitive location data.  It allows a workload to prove residency
         within a broad "Sovereign Zone" without revealing precise GPS
         coordinates, balancing security with privacy.

     Additional relationships include:

     *  *Verifiable Geofencing [[!I-D.lkspa-wimse-verifiable-geo-fence]]*:
        Provides the normative technical specification for Layer 2 and
        Layer 3 attestation.  This draft (Transitive Attestation) acts as
        the application-layer profile that implements these residency
        proofs within mTLS and DPoP flows, fulfilling the "Silicon-to-
        SVID" chain.
     *  *WIMSE Architecture [[!I-D.ietf-wimse-arch]]*: This draft provides
        the technical fulfillment for the secure agent requirements and
        thread model mitigations (e.g., token theft) defined in the
        architecture.

  6.  Security Considerations

     Proof of Residency or Co-location specifically mitigates the "Stolen
     Credential Portability" threat, which encompasses both stolen private
     keys and stolen bearer/DPoP tokens.

     An attacker who steals a private key or intercepts an active token
     from a workload cannot use those credentials from an external
     environment.  Any attempt to use the stolen credential requires a
     corresponding PoR assertion that is:

     1.  *Locally Attested*: Linked to the local Workload Identity Agent's
         signing interface, typically protected by OS permissions or
         hardware roots.
     2.  *Context-Specific*: Bound to a fresh, server-provided nonce and a
         current timestamp.




  Krishnan, et al.         Expires 29 August 2026                [Page 10]


  Internet-Draft               WIMSE-TRANS-POR               February 2026


     3.  *Protected*: Access to the Workload Identity Agent's signing
         capability is restricted by local Operating System permissions
         and logical isolation.

     Consequently, credentials become functionally "sticky" to the
     verified residence; an attacker cannot generate a valid proof without
     achieving a compromise of the identity agent itself.  While a
     software-based agent provides strong logical isolation, a hardware-
     rooted agent (see [[!I-D.lkspa-wimse-verifiable-geo-fence]]) provides
     the highest level of protection against agent cloning and export.

     The security of this model relies on the *Workload Identity Agent*
     correctly providing a fresh assertion bound to the current workload
     session.  While this document specifies the conveyance of N_fusion,
     the underlying platform-level freshness—including the binding to
     hardware-rooted platform nonces (N_platform)—is managed by the
     associated *RATS Profile* (see [[!I-D.lkspa-wimse-verifiable-geo-
     fence]]).  If a verifier accepts a residency proof that lacks a fresh
     agent signature, the "Silicon-to-SVID" chain of trust is compromised.

     TBD: Discussion on Workload Identity Agent compromise, nonce entropy
     requirements, and clock skew for timestamp verification.

  7.  IANA Considerations

     This document has no IANA actions at this time.

  Authors' Addresses

     Ram Krishnan
     JPMorgan Chase & Co
     Email: ramkri123@gmail.com


     A Prasad
     Oracle
     Email: a.prasad@oracle.com


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


     Srinivasa Addepalli
     Aryaka
     Email: srinivasa.addepalli@aryaka.com




  Krishnan, et al.         Expires 29 August 2026                [Page 11]


name: draft-yang-nmrg-mcp-nm
rev: 02
title: Applicability of MCP for the Network Management
time: 2026-02-24T09:30:18Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-08-28T09:30:18Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.080934+00:00
source: ietf
abstract:
  The application of MCP in the network management field is meant to
     refactor network management operation and network capabilities as
     tools and provide more agile and extensible architecture to expose
     these AI integration capabilities.  This document discusses the
     applicability of MCP to the network management plane in the IP
     network that utilizes IETF technologies.  It explores MCP for network
     exposure, multiple MCP server discovery, communication between
     Network Elements or between the Network element and the Network
     Controller/Network Gateway.

full_text:
  Network Management Working Group                                 Y. Yang
  Internet-Draft                                                     Q. Wu
  Intended status: Informational                                    Huawei
  Expires: 28 August 2026                                         D. Lopez
                                                                Telefonica
                                                              N. R. Moreno
                                                          Deutsche Telekom
                                                             L. Tailhardat
                                                           Orange Research
                                                          24 February 2026


              Applicability of MCP for the Network Management
                       draft-yang-nmrg-mcp-nm-02

  Abstract

     The application of MCP in the network management field is meant to
     refactor network management operation and network capabilities as
     tools and provide more agile and extensible architecture to expose
     these AI integration capabilities.  This document discusses the
     applicability of MCP to the network management plane in the IP
     network that utilizes IETF technologies.  It explores MCP for network
     exposure, multiple MCP server discovery, communication between
     Network Elements or between the Network element and the Network
     Controller/Network Gateway.

  Status of This Memo

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

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 28 August 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  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.  Terminology & Notation Conventions
       2.1.  MCP
       2.2.  Others
     3.  The values of coupling MCP with the network management
     4.  The high level Challenges in adopting MCP in NM
     5.  MCP for Network Exposure
       5.1.  The Third Party as IETF network Exposure Consumer
       5.2.  The Network Controller Consumes external sources
     6.  MCP Server Discovery
       6.1.  MCP core function
       6.2.  Procedure for Multi-MCP servers Discovery
     7.  Deployment Consideration in adopting MCP in the Network
             Management
       7.1.  Network Element Inter-Communication using MCP
       7.2.  Network Controller consumes API or Data source using MCP
       7.3.  Standalone MCP server to Expose APIs and tools to the
             Network Controller
       7.4.  The Network Gateway/Controller and the Network Element
             Communication using MCP
     8.  MCP architecture Design for Network Management
       8.1.  Encapsulating Device Operations into MCP Tools
       8.2.  LLM for Intent-to-Tool-Request Translation
       8.3.  Closed-Loop Automation Execution Workflow
     9.  Interworking with the Network Management protocol and YANG data
             models
     10. IANA Considerations
     11. Security Considerations
     12. Normative References
     Appendix A.  MCP Usage Examples
       A.1.  Routing Protocol Troubleshooting using Embeded SLM Model
             and Nature Language Interface
       A.2.  Device Configuration using MCP+CLI
     Contributors
     Authors' Addresses

  1.  Introduction

     The Model Context Protocol (MCP) decouples LLMs from tools and
     provides a standardized way for LLMs to access and utilize
     information from different data sources and tools, making it easier
     to build AI applications that can interact with external LLM models
     and software tools and enable workflows automation.

     MCP has seen rapid adoption across both startups and enterprises
     since it announced in November 2024.  Key use cases include AI coding
     assistants in IDEs, data analysis tools that can query databases, and
     productivity tools that can interact with services like Slack or
     Google Drive.

     The application of MCP for the network management is meant to
     refactor network management operation and network capabilities as
     tools and provide more agile and extensible architecture to expose or
     consume these AI integration capabilities.

     With integration of MCP into the network management system, it allow
     you develop various rich AI driven network applications, realize
     intent based networks management, automate workflows in the multi-
     vendor heterogeneous network platform.  By establishing standard
     interfaces for tool encapsulation, intent translation, and closed-
     loop execution within the network management system, MCP enables the
     network management system to have:

     *  Unified operation abstraction through normalized MCP tool
        definitions

     *  Seamless LLM integration via the structured protocol

     *  Automation Execution Ability

     This document discusses the applicability of MCP to the network
     management plane in the IP network that utilizes IETF technologies.
     It explores MCP for network exposure, multiple MCP server discovery,
     communication between Network Elements or between the Network element
     and the Network Controller/Network Gateway.

  2.  Terminology & Notation Conventions

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

     The following terms are used throughout this document:

  2.1.  MCP

     *  *MCP Protocol*: MCP is an open standard designed to facilitate
        communication between LLMs and external data sources or tools.

     *  *MCP Host*: The entity initiating the LLM request.

     *  *MCP Client*: A built-in module within a host, specifically
        designed for interaction with the MCP server.

     *  *MCP Server*: A dedicated server that interacts with MCP clients
        and provides tools.

     *  *CLI*: Command Line Interface

  2.2.  Others

     *  *LLM*: Large Language Model

     *  *NETCONF*: Network Configuration Protocol [RFC6241]

     *  *RESTCONF*: RESTful Network Configuration Protocol [RFC8040]

     *  *SNMP*: A Simple Network Management Protocol [RFC3584]

  3.  The values of coupling MCP with the network management

      +---------------+        +---------------+
      |               |        |               |
      |  3rd Party    |        |  3rd-party
      |  AI Agent     |        | Tools/Contents|
      +-----/---\-----+        +---------------+
            |   |                   |   |
            |   | ----------------- \   /
           ///////                 \\\\\\\
         ||                               ||
       ||                                   ||
        |          MCP Eco-system           |
         ||                               ||
           \\\\\\\                 ///////
            /   \ -----------------  |   |
            |   |                    |   |
      +---------------+       +----- \---/----+
      |               |       |               |
      |  Network MCP  |       |  In-Network   |
      |   Server      |       |     Service   |
     (network exposure)    (e.g.,Digital assistant)
      +---------------+       +---------------+
             /   \                   /   \
             |   |                   |   |
      +------+---+-------------------+---+----+
      |                                       |
      |       Network Intelligence            |
      |                                       |
      |  Agentic + MCP Architecture Paradigm  |
      |                                       |
      +---------------------------------------+

     There are 3 values for MCP coupling with the network management

     *  Network MCP Server support

        -  Exposing network capabilities as MCP Servers for 3rd-party AI
           Agents & applications

     *  In Network Service

        -  Empowering network services by leveraging MCP ecosystem tools &
           contents

        -  Network service as a unified interface to various and rich
           capabilities for network users

     *  Network Management Intelligence

        -  Making network architecture really agile and friendly for
           innovation

        -  Decoupling network management functions into network agents and
           network tools

  4.  The high level Challenges in adopting MCP in NM

     *  Protocol Design

        -  Error Handling

           o Although MCP provides basic error codes, MCP does not yet
           enforce a entire error-handling mechanism, and its scope is
           currently limited to discovery and invocation, omitting crucial
           aspects like tool governance, versioning, or lifecycle
           management.

        -  Stateful

           o The protocol's reliance on stateful Server-Sent Events (SSE)
           can create significant complexities when integrating with
           inherently stateless REST APIs, requiring developers to manage
           state externally.  This can be particularly challenging for
           remote MCP servers due to network latency and instability,
           complicating load balancing and horizontal scaling efforts.

        -  Context Handling

           o There are also concerns that multiple active MCP connections
           could consume significant tokens in the LLM's context window.
           This can directly impact an LLM's performance, slowing down
           responses and potentially hindering its ability to maintain
           focus and reason effectively over extended or complex
           interactions.

     *  Security Consideration

        -  Malicious Actors

           The protocol's ability to grant LLMs access to external systems
           introduces potential vulnerabilities that require careful
           consideration

           o Prompt injection, where malicious instructions embedded in
           user inputs or tool descriptions could lead to unintended
           actions by the LLM;

           o Tool poisoning, where attackers odify tool definitions, or
           rug pulls (similar to tool poisoning but occurs post-
           installation);

           o Tool shadowing, where a malicious server creates a tool with
           the same name as a legitimate tool from another server to
           intercept calls;

        -  Security enforcement

           o MCP itself lacks inherent security enforcement mechanisms,
           relying heavily on external implementations for authentication
           and authorization, which were not initially well-defined within
           the protocol.

        -  Identity Management

           o Determining clear identity management - whether requests
           originate from the end user, the AI agent, or a shared system
           account - remains an area needing clearer definition.

  5.  MCP for Network Exposure

     Network exposure is the process of making network capabilities, such
     as data and connectivity services, available to external users,
     applications, and developers through secure APIs.  It allows for more
     agility and the creation of programmable networks.  The MCP can be
     used to expose network capabilities to AI applications or consume
     external sources for LLMs.

  5.1.  The Third Party as IETF network Exposure Consumer

            3rd Party
       +------------------+
       |     Consumer     |
       |   +------------+ |
       |   |            | |       4. Authoriz and Consume
       |   | MCP Client <-+------------------------+
       +---+-+-------^--+-+                        |
         2.Discover  |3. List of                   |
         and Authz   | Available APIs              |
             |       |                             |
             |       |                             |
       +---+-V-------+--+------------+         +---V--------+
       |   | MCP Server |            |         |Tools       |
       |   +------------+            |1.Publish|+----------+|
       |                             <---------+|Simulation||
       |   Network Exposure Agent    |         ||  API     ||
       |   /Network Controller       |4. Authz |+----------+|
       | +---+   +---+ +---+         <--------->            |
       | |NF1|   |NF2| |NF3| ...     |         |+----------+|
       | +---+   +---+ +---+         |  Heart  ||Other APIs||
       |                             <--------->+----------+|
       +-----------------------------+  Beat   +------------+

     Step 1: External tools or data source publish a set of APIs to MCP
     server in the Network Controller.

     Step 2: MCP client send specific tools request to discover tools and
     MCP Server provide authorization to the MCP client.

     Step 3: After sucessful authorization, MCP server return API list
     corresponding to tools request sent by the MCP client.

     Step 4: MCP Client invokes tools with authorization.

  5.2.  The Network Controller Consumes external sources

                                    +---------------+
                                    |  Data Source  |
                                    | +-----------+ |
                                    | | MCP Server| |
                                    +-+-----^-----+-+
                                            |2. Consume external sources
                                            |
                               +------+-----V-----+-----------+
                               |      | MCP Client|0.Preconfig MCP
       +--------------+        |      +-----------+  Server Address
       |     IETF     |1.MCP Service Request                  |
       |   Network    +-------->                              |
       |  Management  |3.MCP Service Response                 |
       |  AI Agents   <--------+                              |
       +--------------+        |                              |
                               |       Network Controller     |
                               |                              |
                               +------------------------------+

     Step 0: MCP Client is preconfigured with the MCP Server address.

     Step 1: IETF Network Management AI Agent sends a MCP Service Request
     to the MCP client within the Network Controller.

     Step 2: The MCP client discover tools provided by the external MCP
     server.

     Step 3: The MCP client provide available tools list to the IETF
     Network Management AI Agent.

  6.  MCP Server Discovery

     The MCP Server Discovery involves clients querying servers to find
     available tools, resources, and functions.  In case of MCP servers
     are distributed in different locations, MCP Respository can be
     established to keep track of the location of each MCP servers.

  6.1.  MCP core function

               +------------+ 2.Discovery ---------------+
               | Agents     +-----------+      MCP       |
               |(MCP Client)+-----------+   Respository  |
               +-+----------+ 3. Authz  +--------^-------+
                 |4. Consume                     |1.Registration
                 | +-------------+---------------+-------+-
      +----------V-+       +-----+-------+        +------+------+
      |MCP Server 1|       |MCP Server 2 |        | MCP Server 3|
      +------------+       +-------------+        +-------------+
         -------                -----                  -----
      ///FM  PM \\\          ///     \\\            ///     \\\
     |             |       ||  Memory   |         ||           |
     | Routing  ACL|       |             |        |    Templates|
      \\\Policy ///        || Database  |         ||           |
         -------             \\\     ///            \\\     ///
                                -----                  -----

     o MCP Repository: * Maintain the description of MCP servers * Support
     MCP server discovery for Client.

     o MCP client: consuming the services provided by MCP servers

     o MCP servers: including authentication/session/policy tools, the
     memory/prompts used for Agents

  6.2.  Procedure for Multi-MCP servers Discovery

    +------------------+    +----------+   +-------+     +------+
    |Network Management|    |          |   |       |     |      |
    |    AI Agent      |    |  MCP     |   | MCP   |     |Tools |
    |   (MCP Client)   |    |Repository|   |Servers|     |      |
    +---------+--------+    +----+-----+   +---+---+     +---+--+
              |                  |             | 0. Sync the info of tools
              |                  |             |<------------+
              |                  |1. Registration            |
              |                  |<------------+             |
              |                  |             |             |
              |    +-------------+----------+  |             |
              |    |       Repository       |  |             |
              |    |MCP Server1:ID 1, Capability, Tools      |
              |    |                        |  |             |
              |    |MCP Server2:ID 2, Capability, Tools      |
              |    +------------- ----------+  |             |
              | 2.1 Discovery    |             |             |
              +------------------>             |             |
              |           +------+------+      |             |
              |           | Search for  |      |             |
              |           | Proper MCP  |      |             |
              |           | Server      |      |             |
                          +-------------+      |             |
              | 2.2 Address of MCP Server      |             |
              <------------------+             |             |
                 3. oAuth Authz                |             |
              <------------------------------->|             |
              |  4. Consume Tools/Resources/Prompts          |
              +------------------+-------------|-------------|
                                 |             |             |

     Step 0: The MCP Server syncs up on the info of tools, upon tools is
     added or removed, tools changes will be automatically syned up with
     the MCP server.

     Step 1: Each new MCP server will register to the centralized MCP
     registry.

     Step 2.1: MCP Client send the MCP service request to the MCP registry
     for specific capability.

     Step 2.2: The MCP registry return specific MCP server to the MCP
     client.

     Step 3: The MCP Client request authorization from the MCP server.

     Step 4: The MCP Client invoke specific tools with authorization.

  7.  Deployment Consideration in adopting MCP in the Network Management

     This section describes MCP deployment requirements for network
     management environments, followed by implementation scenarios.  Key
     architectural requirements include:

     *  Function-Specific MCP Servers: To maintain proper architecture and
        performance with growing tool volumes, servers should be
        categorized by network management functions.  Typical categories
        include network log analysis, device configuration management,
        energy consumption management, and security operations, etc.

     *  Secure and Scalable Architecture: The architecture must:

        -  Enforce strict access controls limiting MCP operations to
           authorized AI models and users

        -  Scale efficiently with increasing number of network devices
           while maintaining performance

     *  Automated Workflows: MCP implementations should support LLM-
        coordinated automation of:

        -  Real-time monitoring and diagnostics

        -  Fault remediation workflows

        -  Other common management operations to reduce operator workload

     While these core requirements apply universally, operational
     characteristics vary based on deployment location.  The following
     subsections detail these deployment scenarios.

  7.1.  Network Element Inter-Communication using MCP

     In this network scenario, the MCP client is deployed in one smart
     network element while the MCP server is deployed in another smart
     network element.  The MCP client communicates with the MCP server
     using the MCP protocol and invoke specific tools and get access to
     specific data in the network element as a data source.  In addition,
     human operator can use nature language to interact with smart network
     element to investigate protocol troubleshooting information.

     Network element usually have limited resources (CPU, memory, etc.).
     Deploying MCP Client together with SLM may occupy a large amount of
     resources, affecting the normal operation of the device.

              Human Operator
                   |
                   |
               Nature Language                Data Source
       +-----------+-------------+     +-------------------------+
       |   +-------+----------+  |     |   +------------------+  |
       |   |Routing Protocol  |  |     |   |Routing Protocol  |  |
       |   |       Agent      |  |     |   |       Agent      |  |
       |   |+---+ +----------+|  |     |   | +----------+     |  |
       |   ||SLM| |MCP Client++--+-----+---+->MCP Server|     |  |
       |   |+---+ +----------+|  |     |   | +----------+     |  |
       |   +------------------+  |     |   +------------------+  |
       +-------------------------+     +-------------------------+
         Smart Network Element           Smart Network Element

  7.2.  Network Controller consumes API or Data source using MCP

     In this network scenario, the MCP client is deployed in the network
     controller while the MCP server is deployed in either the 3rd party
     managment system or external data source.  The MCP client
     communicates with the MCP server using the MCP protocol and invoke
     specific tools and get access to specific data in the 3rd party
     management system or external data source.

     +------------------------+     +------------+
     |                        |     | 3rd party  |
     |   Network Controller   |     | Management |
     |              +-------+ |     |    System  |
     |              |  MCP  +-+--+  |+----------+|
     |              | Client+-+--+--->MCP Server||
     |              +-------+ |  |  |+----------+|
     |                        |  |  +------------+
     |                        |  |
     |                        |  |  +------------+
     |                        |  |  |            |
     |                        |  |  |Data Source |
     |                        |  |  |+----------+|
     |                        |  |--->MCP Server||
     |                        |     |+----------+|
     |                        |     |            |
     +------------------------+     +------------+

  7.3.  Standalone MCP server to Expose APIs and tools to the Network
        Controller

     In this network scenario, The MCP client is deployed in the network
     controller while the MCP server is deployed standalone to manage all
     the network elements.  The network elements will be refactored as
     data source or tools so that MCP client can directly consume these
     APIs or data sources.  Alternatively, the network elements can be
     traditional network elements.  MCP server will serve as protocol
     adaptor to translate MCP protocol into traditional network management
     protocols such as NETCONF, gNMI.

                       +----------------------+
                       |                      |
                       |   Network Controller |
                       |                      |
                       |    +------------+    |
                       |    |            |    |
              +--------+----| MCP Client +----+----------+
              |        |    |            |    |          |
              |        |    +-----+------+    |          |
              |        +----------+-----------+          |
              |                   |                      |
              |    +--------------V---------------+      |
              |    |         MCP Server           |      |
              |    +--------^-------------^-------+      |
              V             |             |              V
     +-------------+        |             |        +----------+
     |             |        |             |        |          |
     | Data Source |--------+-            |--------+  Tools   |
     |             |                               |          |
     +-------------+                               +----------+
     Network Element                             Network Element

  7.4.  The Network Gateway/Controller and the Network Element
        Communication using MCP

     In this network scenario, The MCP client is deployed in the network
     gateway device while the MCP server is deployed in each network
     devices.  The MCP client communicates with the MCP server using the
     MCP protocol.  LLM model is pre-trained model and deployed in the
     same Network gateway as the MCP client.

     Network devices usually have limited resources (CPU, memory, etc.).
     Deploying MCP Server may occupy a large amount of resources,
     affecting the normal operation of the device.

           +------------------------+
           |   Network Controller/  |
           |   Network Gateway      |
           |                        |
           |        Nature          |
           | +------Language------+ |
           | |  MCP  |     | LLM  | |
           | | Client|-----|      | |
           | +-+-----+     +------+ |
           |   |MCP                 |
           +---+--------------------+
               +----------------+
      +--------+---+     +------+------+
      |  +-----++  |     |  +---+--+   |
      |  | MCP ||  |     |  | MCP  |   |
      |  |Server|  |     |  |Server|   |
      |  +------+  |     |  +------+   |
      +------------+     +-------------+
     Network Element      Network Element

  8.  MCP architecture Design for Network Management

  8.1.  Encapsulating Device Operations into MCP Tools

     *  Objective: Standardize device operations into modular, reusable
        tools.

     *  Implementation:

        -  Tool Abstraction: Vendor-specific commands are wrapped into
           discrete MCP Tools with uniform schemas.

        -  Tool Registry: A centralized database stores MCP Tools with
           metadata (e.g., names, descriptions, parameters).

     *  Benefits:

        -  Eliminates manual translation of commands across different
           vendors

        -  Enabling the plug-and-play integration of new device types.

  8.2.  LLM for Intent-to-Tool-Request Translation

     *  Objective: Allow AI models (such as Claude) to understand natural
        language commands and trigger operations.

     *  Workflow:

        -  Intent Recognition: The LLM first analyzes the user's natural
           language query to identify：

           o  The user's intent or goal

           o  Required actions or operations

           o  Entities, parameters, and constraints mentioned

           o  Context from previous interactions

        -  Tool Discovery and Toolchain Generation: The LLM access tool
           descriptions provided by MCP servers, and matches the
           identified intent with available tools.

        -  Parameter Extraction and Mapping: The LLM maps natural language
           references to structured parameter names and extracts relevant
           information from the user query.

        -  Structured Invocation Generation: The LLM generates properly
           formatted tool calls following MCP's protocol.

     *  Benefits:

        -  Bridge natural language to tool invocation requests in a fixed
           format, then return this request to the client, enabling the
           client to properly parse the request.

  8.3.  Closed-Loop Automation Execution Workflow

     *  Objective: Realize the closed loop of "voice/text commands →
        automatic execution".

     *  A general workflow is as follows:

        -  User Input Submission: An operator submits a natural language
           request to the MCP client.  And The MCP client forwards this
           request to the LLM.

        -  LLM Intent Processing: The LLM parses the input, identifies the
           operational intent, and forwards a structured request to the
           MCP client, which queries the MCP Server to retrieve the
           available tools.  The information would include the functional
           description, required parameters of tools.

        -  LLM Toolchain Decision:

           o  The LLM evaluates the context and if tools are required,
              select and sequence tools.

           o  The decision is sent back to the MCP Client and then MCP
              Client will execute tools via server.

        -  Tool Execution: The MCP Server executes the translated commands
           on target devices and returns results to the client.

        -  Result Aggregation & Feedback: The MCP Client collates tool
           outputs (success/failure logs) and forwards them to the LLM for
           summarization.

     *  Benefits:

        -  Tools safely retry/rollback.

        -  Full traceability of LLM decisions and tool executions.

  9.  Interworking with the Network Management protocol and YANG data
      models

     MCP can be seen as AI protocol and used to invoke AI integrated
     capabilities.  MCP is not in the position to replace the network
     management and YANG data model.  Instead, it can be integrated
     together, e.g.,

     *  Integrated MCP with CLI, allow the MCP client invoke CLI
        capabilities;

     *  Integrated MCP with YANG, allow YANG being consumed by MCP client
        or allow the MCP client invoke YANG interface related
        capabilities;

  10.  IANA Considerations

     This document has no IANA actions.

  11.  Security Considerations

     The MCP protocol needs to consider scenarios where either the client
     or server encounters issues, such as crashes.  If one or both parties
     go offline during communication, the entire process may remain stuck
     waiting for messages, potentially leading to an infinite loop.
     Furthermore, certain tool operations may be interrupted, and some
     irreversible network management operations could be affected.

     Due to network latency, some operations might not return in time, yet
     from the user's perspective, these operations may appear either
     unexecuted or failed.  If the user then initiates another tool
     request to the server, problems may occur.

     For complex network management workflows, while LLM's tool invocation
     process may generally function correctly, issues can arise in the
     details.  Users must verify each LLM operation to prevent unintended
     hazardous actions.

  12.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC3584]  Frye, R., Levi, D., Routhier, S., and B. Wijnen,
                "Coexistence between Version 1, Version 2, and Version 3
                of the Internet-standard Network Management Framework",
                BCP 74, RFC 3584, DOI 10.17487/RFC3584, August 2003,
                <https://www.rfc-editor.org/rfc/rfc3584>.

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

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

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

  Appendix A.  MCP Usage Examples

  A.1.  Routing Protocol Troubleshooting using Embeded SLM Model and
        Nature Language Interface

     +-----------------------------------------------------------------+
     | Smart Network Element                                           |
     |                                                                 |
     | +-------------------------------------------------------------+ |
     | |  Dev  Env: Offline Generate fault location workflow code    | |
     | |                                                             | |
     | |      +----------+                         +---------+       | |
     | |      | Expert   | +----------+            |fault    |       | |
     | |      |experience| | Protocol |  +-----+   |Locating |       | |
     | |      |accumulate+-> Knowledge+--> LLM +--->Workflow |       | |
     | |      | protocol | |   RAG    |  +-----+   |  Code   |       | |
     | |      |  fault   | +----------+            +----+----+       | |
     | |      +----------+                              |            | |
     | +------------------------------------------------+------------+ |
     |                                                  |              |
     |                                                  |              |
     |                                                  |              |
     | +------------------------------------------------+------------+ |
     | |OPS Env:Online Nature Language Interaction------V-------+    | |
     | |                             +----------+Troubleshooting|    | |
     | |                             |          |  Package Build|    | |
     | |                             |          +---------------+    | |
     | |+--------+              +----V---+    +-------------+        | |
     | ||  User  |  +-------+   |Intent  |    | Execute     |        | |
     | || Nature |  | Device|   |Parse   |    |Workflow     |        | |
     | ||Language+-->  SLM  +--->Fault   +---->  Script     |        | |
     | || Prompt |  |  ONNX |   |Pattern |    |Locating root|        | |
     | |+--------+  +-------+   |Match   |    |  Cause      |        | |
     | |                        +--------+    +-------------+        | |
     | |                                                             | |
     | +-------------------------------------------------------------+ |
     +-----------------------------------------------------------------+

     Step 1.  When ISIS neighbour establishment fails, the network
     maintenance engineer queries the fault cause via natural language in
     the CLI interface.

     Step 2.  A small model deployed on the device's CPU understands the
     user's intent and matches the fault pattern.

     Step 3.  Troubleshooting scripts are invoked to locate the root cause
     of the fault.

     Step 4.  The query is repeated until service operations get back to
     normal.

  A.2.  Device Configuration using MCP+CLI

     In this example, The network element implement the MCP Server and
     exposes all CLI interfaces and documentation as tools to the MCP
     Client.  The Nework controller implements the MCP client and interact
     with MCP server in the Network element.

     The MCP server provides the following registered tool descriptor
     information:

     Tools description: It describes the name, use, and parameters of
     tools.

     Tools implementation: MCP implementation describes how the tools are
     invoked.

     See Tool descriptor information example as follows:

  # Tool Descriptor
  [
    {
      "name": "batch_configure_devices",
      "description": "Batch Configure Network Devices",
      "parameters": {
        "type": "object",
        "properties": {
          "device_ips": {
            "type": "array",
            "items": {"type": "string"},
            "description": "Device IP List"
          },
          "commands": {
            "type": "array",
            "items": {"type": "string"},
            "description": "CLI Sequence"
          },
          "credential_id": {
            "type": "string",
            "description": "Credential ID"
          }
        },
        "required": ["device_ips", "commands"]
      }
    },
    {
      "name": "check_device_status",
      "description": "Check the Status of Network Devices",
      "parameters": {
        "type": "object",
        "properties": {
          "device_ip": {"type": "string"},
          "metrics": {
            "type": "array",
            "items": {"enum": ["cpu", "memory", "interface"]}
          }
        },
        "required": ["device_ip"]
      }
    }
  ]
  # Tool Implementation
  from netmiko import ConnectHandler
  from mcp_server import McpServer

  app = FastAPI()
  server = McpServer(app)

  #Connection Pool Management
  devices = {
      "192.168.1.1": {
          "device_type": "VendorA-XYZ",
          "credential": "admin:XYZ@password"
      },
      "192.168.1.2": {
          "device_type": "VendorB-ABC",
          "credential": "admin:ABC@passowrd"
      },
      ...
  }

  @server.tool("batch_configure_devices")
  async def batch_config(device_ips: list,commands: list,credential_id: str):
      results = {}
      for ip in device_ips:
          conn = ConnectHandler(
              ip = ip,
              username = devices[ip]["credential"].split(':')[0],
              password = devices[ip]["credential"].split(':')[1],
              device_type = devices[ip]["device_type"]
          )
          output = conn.send_config_set(commands)
          results[ip] = output
      return {"success": True, "details": results)

  @server.tool("check_device_status")
  async def check_status(device_ip: str, metrics: list):
      status = {}
      if "cpu" in metrics:
          status["cpu"] = get_cpu_usage (device_ip)
      if "memory" in metrics:
          status["memory"] = get_memory_usage(device_ip)
      return status

     Suppose a user submits a request (via the client) such as "Configure
     OSPF Area 0 with process ID 100 for all core switches in the Beijing
     data center," the MCP client retrieves the necessary tooling
     descriptor information from the MCP server and forwards it along with
     the request to the LLM.  The LLM determines the appropriate tools and
     responds in JSON format as follows:

     {
     "method": "batch_configure_devices",
     "params": {
        "device_ips":["192.168.10.1",....,"192.168.10.10"],
        "command": [
          "router ospf 100",
          "network 192.168.0.0 0.0.255.255 area 0"
        ]
      }
     }
     }

     The MCP server responds to the call instruction, converts it into the
     below CLIs of different vendors, and then the devices execute the
     CLIs.  The results are returned to the MCP client in Json as below
     and are forwarded to the LLM.  The LLM parses the response, generates
     a natural-language summary, and sends it back to the client for final
     presentation to the user.

     # Convert to CLI commands of different vendors
     "commands": [
         "system-view",
         "ospf {{process_id}}",
         "area {{area_id}}",
         "network {{network_address}} {{wildcard_mask}}"
       ]

     "commands": [
         "configure terminal",
         "router ospf {{process_id}}",
         "network {{network_address}} {{wildcard_mask}} area {{area_id}}",
         "end",
         "write memory"
       ]

     #Feedbacks received by the MCP client of different vendors
     {
         "status": "success",
         "message": "OSPF configuration applied successfully on device
                     192.168.10.1",
         "commands_executed": [
             "system-view",
             "ospf 100",
             "area 0.0.0.0",
             "network 192.168.10.0 0.0.0.255"
         ]
     }

     {
         "status": "success",
         "message": "OSPF configuration applied successfully on device
                     192.168.10.1",
         "commands_executed": [
             "configure terminal",
             "router ospf 100",
             "network 192.168.10.0 0.0.0.255 area 0",
             "end",
             "write memory"
         ]
     }

     # Natural lanauge summary of success or failure:
     {
       "192.168.10.1": "Configure Successfully, take 2.3 seconds",
       "192.168.10.2": "Error: no response from the device",
     }

  Contributors

     Qiufang Ma
     Huawei
     Email: maqiufang1@huawei.com


     Guanming Zeng
     Huawei
     China
     Email: zengguanming@huawei.com


  Authors' Addresses

     Yuanyuan Yang
     Huawei
     China
     Email: yangyuanyuan55@huawei.com


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


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


     Nathalie Romo Moreno
     Deutsche Telekom
     Germany
     Email: nathalie.romo-moreno@telekom.de


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


name: draft-zeng-mcp-network-measurement
rev: 00
time: 2025-10-20T08:21:51Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T08:21:51Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.084497+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 network controllers 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                                    Huawei
  Expires: 23 April 2026                                   20 October 2025


   MCP-based Network Measurement Framework: Using Model Context Protocol
                    for Intelligent Network Measurement
                   draft-zeng-mcp-network-measurement-00

  Abstract

     This document proposes a framework for intelligent network
     measurement using the Model Context Protocol (MCP).  By treating
     network devices as MCP servers and network controllers 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 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.



  Zeng & Mao                Expires 23 April 2026                 [Page 1]


  Internet-Draft                 MCP NetMeas                  October 2025


     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     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

  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:




  Zeng & Mao                Expires 23 April 2026                 [Page 2]


  Internet-Draft                 MCP NetMeas                  October 2025


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

     *  Network controllers or management systems 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.

     *MCP Server*: A network device that exposes measurement capabilities
     and data through the Model Context Protocol.

     *MCP Client*: A network controller or management system that
     initiates measurement requests through MCP.

     *Measurement Resource*: Data exposed by MCP servers for network
     measurement (e.g., interface statistics, routing tables).

     *Measurement Tool*: Functions exposed by MCP servers that can be
     invoked for active measurements (e.g., ping, traceroute).

  3.  MCP-Based Network Measurement Architecture

  3.1.  Architectural Components






  Zeng & Mao                Expires 23 April 2026                 [Page 3]


  Internet-Draft                 MCP NetMeas                  October 2025


   +------------------+          MCP Protocol         +------------------+
   |                  |<----------------------------->|                  |
   |  MCP Client      |   JSON-RPC 2.0 over           |  MCP Server      |
   |  (Controller)    |   TCP/HTTP/WebSocket          |  (Network Device)|
   |                  |                               |                  |
   +------------------+                               +------------------+
           |                                                  |
           |                                                  |
           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 (network devices) MUST expose:

     Measurement Resources:

     *  Interface statistics (bandwidth, utilization, errors)

     *  Routing information (tables, protocols, neighbors)

     *  Device performance metrics (CPU, memory)




  Zeng & Mao                Expires 23 April 2026                 [Page 4]


  Internet-Draft                 MCP NetMeas                  October 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 (controllers) 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 & Mao                Expires 23 April 2026                 [Page 5]


  Internet-Draft                 MCP NetMeas                  October 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 & Mao                Expires 23 April 2026                 [Page 6]


  Internet-Draft                 MCP NetMeas                  October 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 & Mao                Expires 23 April 2026                 [Page 7]


  Internet-Draft                 MCP NetMeas                  October 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 & Mao                Expires 23 April 2026                 [Page 8]


  Internet-Draft                 MCP NetMeas                  October 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 & Mao                Expires 23 April 2026                 [Page 9]


  Internet-Draft                 MCP NetMeas                  October 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

































  Zeng & Mao                Expires 23 April 2026                [Page 10]


name: draft-zw-rtgwg-mcp-network-mgmt
rev: 00
title: Model Context Protocol (MCP) Extensions for Network Equipment Management
time: 2025-10-20T12:52:07Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T12:52:07Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.087738+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-rtgwg-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-howe-sipcore-mcp-extension
rev: 00
title: SIP Extension for Model Context Protocol (MCP)
time: 2025-09-29T22:20:41Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-04-02T22:20:41Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:06.091296+00:00
source: ietf
abstract:
  This document specifies a Session Initiation Protocol (SIP) extension
     to advertise support for, negotiate, and carry the Model Context
     Protocol (MCP).  It defines: (1) a new SIP option-tag ("mcp"), (2)
     new header fields for capability advertisement and selection, (3)
     Contact feature-capability parameters for registration-time
     discovery, and (4) the "application/mcp+json" media type.  MCP
     payloads can be exchanged during session establishment and mid-dialog
     using INVITE/200 (Offer/Answer), MESSAGE, and INFO.

full_text:
  SIPCORE Working Group                                   T. McCarthy-Howe
  Internet-Draft                                                    VCONIC
  Intended status: Informational                         29 September 2025
  Expires: 2 April 2026


               SIP Extension for Model Context Protocol (MCP)
                    draft-howe-sipcore-mcp-extension-00

  Abstract

     This document specifies a Session Initiation Protocol (SIP) extension
     to advertise support for, negotiate, and carry the Model Context
     Protocol (MCP).  It defines: (1) a new SIP option-tag ("mcp"), (2)
     new header fields for capability advertisement and selection, (3)
     Contact feature-capability parameters for registration-time
     discovery, and (4) the "application/mcp+json" media type.  MCP
     payloads can be exchanged during session establishment and mid-dialog
     using INVITE/200 (Offer/Answer), MESSAGE, and INFO.

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

  Copyright Notice

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










  McCarthy-Howe             Expires 2 April 2026                  [Page 1]


  Internet-Draft              SIP MCP Extension             September 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  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Problem Statement: MCP Transport Layer Failures . . . . .   4
         1.1.1.  Summary of MCP Transport Pain Points  . . . . . . . .   5
       1.2.  SIP as a Solution . . . . . . . . . . . . . . . . . . . .   5
       1.3.  Use Cases Addressed . . . . . . . . . . . . . . . . . . .   5
         1.3.1.  General MCP Use Cases Enhanced by SIP . . . . . . . .   6
         1.3.2.  SIP-Unique Use Cases  . . . . . . . . . . . . . . . .   6
         1.3.3.  Performance-Critical Use Cases  . . . . . . . . . . .   7
         1.3.4.  Regulatory and Compliance Use Cases . . . . . . . . .   7
         1.3.5.  Migration and Integration Use Cases . . . . . . . . .   7
       1.4.  Architectural Justification . . . . . . . . . . . . . . .   8
         1.4.1.  Why SIP for MCP Transport?  . . . . . . . . . . . . .   8
         1.4.2.  Limitations of HTTP/WebSocket-Only Approaches . . . .   8
         1.4.3.  SIP's Value-Added Capabilities  . . . . . . . . . . .   9
         1.4.4.  Discovery Performance Analysis: SIP vs. DNS . . . . .  10
         1.4.5.  Quantitative Performance Analysis: SIP vs. Current MCP
                 Transports  . . . . . . . . . . . . . . . . . . . . .  10
         1.4.6.  Specific Use Cases Addressing Real-World MCP
                 Problems  . . . . . . . . . . . . . . . . . . . . . .  11
         1.4.7.  Alternative Transport Solutions Analysis  . . . . . .  12
         1.4.8.  Backward Compatibility and Incremental Deployment . .  14
     2.  Model Context Protocol (MCP) - Purpose, Architecture,
             Capabilities  . . . . . . . . . . . . . . . . . . . . . .  15
       2.1.  Purpose (non-normative) . . . . . . . . . . . . . . . . .  15
       2.2.  Architecture (non-normative)  . . . . . . . . . . . . . .  15
       2.3.  Capabilities and Primitives (non-normative) . . . . . . .  16
     3.  Conventions and Terminology . . . . . . . . . . . . . . . . .  16
       3.1.  Applicability Statement . . . . . . . . . . . . . . . . .  17
         3.1.1.  Intended Use Cases  . . . . . . . . . . . . . . . . .  17
         3.1.2.  Appropriate Deployment Environments . . . . . . . . .  17
         3.1.3.  Limitations and Constraints . . . . . . . . . . . . .  17
         3.1.4.  Alternative Approaches and Selection Criteria . . . .  18
         3.1.5.  Migration Path Considerations . . . . . . . . . . . .  19
     4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
       4.1.  Backward Compatibility  . . . . . . . . . . . . . . . . .  20
       4.2.  Agent-to-Agent Interoperation (Summary)
             _(non-normative)_ . . . . . . . . . . . . . . . . . . . .  20



  McCarthy-Howe             Expires 2 April 2026                  [Page 2]


  Internet-Draft              SIP MCP Extension             September 2025


         4.2.1.  Concrete Use Cases  . . . . . . . . . . . . . . . . .  21
     5.  SIP Extensions  . . . . . . . . . . . . . . . . . . . . . . .  22
       5.1.  Option-Tag: mcp . . . . . . . . . . . . . . . . . . . . .  22
       5.2.  Header: MCP-Capabilities  . . . . . . . . . . . . . . . .  23
       5.3.  Header: MCP-Select  . . . . . . . . . . . . . . . . . . .  23
       5.4.  Contact Feature-Caps: +mcp, +mcp.ver, +mcp.cap  . . . . .  23
     6.  Payload Format: application/mcp+json  . . . . . . . . . . . .  24
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  35
       7.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  35
         7.1.1.  Assets and Trust Boundaries . . . . . . . . . . . . .  35
         7.1.2.  Threat Actors . . . . . . . . . . . . . . . . . . . .  35
         7.1.3.  Attack Vectors  . . . . . . . . . . . . . . . . . . .  36
       7.2.  Security Requirements and Mitigations . . . . . . . . . .  37
         7.2.1.  Transport Security  . . . . . . . . . . . . . . . . .  37
         7.2.2.  Authentication and Authorization  . . . . . . . . . .  38
         7.2.3.  Content Protection  . . . . . . . . . . . . . . . . .  38
       7.3.  Feature Interaction Security Analysis . . . . . . . . . .  39
         7.3.1.  SIP-MCP Boundary Security . . . . . . . . . . . . . .  39
         7.3.2.  Multi-Modal Security Interactions . . . . . . . . . .  39
         7.3.3.  Federation Security Interactions  . . . . . . . . . .  40
       7.4.  Deployment-Specific Security Guidance . . . . . . . . . .  40
         7.4.1.  Enterprise Deployment . . . . . . . . . . . . . . . .  40
         7.4.2.  Federated Deployment  . . . . . . . . . . . . . . . .  41
         7.4.3.  Cloud and Service Provider Deployment . . . . . . . .  41
       7.5.  Privacy Considerations  . . . . . . . . . . . . . . . . .  42
         7.5.1.  Data Minimization . . . . . . . . . . . . . . . . . .  42
         7.5.2.  Regulatory Compliance . . . . . . . . . . . . . . . .  42
       7.6.  Security Monitoring and Incident Response . . . . . . . .  43
         7.6.1.  Monitoring Requirements . . . . . . . . . . . . . . .  43
         7.6.2.  Incident Response . . . . . . . . . . . . . . . . . .  43
       7.7.  Implementation Security Guidelines  . . . . . . . . . . .  44
         7.7.1.  Secure Development Practices  . . . . . . . . . . . .  44
         7.7.2.  Configuration Security  . . . . . . . . . . . . . . .  44
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  45
       8.1.  Registration of Option-Tag  . . . . . . . . . . . . . . .  45
       8.2.  Registration of Header Fields . . . . . . . . . . . . . .  45
       8.3.  Registration of Feature-Capability Indicators (RFC
             6809) . . . . . . . . . . . . . . . . . . . . . . . . . .  46
       8.4.  Media Type Registration . . . . . . . . . . . . . . . . .  46
       8.5.  Designated Expert Considerations  . . . . . . . . . . . .  47
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  47
       9.1.  Normative . . . . . . . . . . . . . . . . . . . . . . . .  47
       9.2.  Informative . . . . . . . . . . . . . . . . . . . . . . .  48
       9.3.  A.  Acknowledgments . . . . . . . . . . . . . . . . . . .  48
       9.4.  B.  Change Log  . . . . . . . . . . . . . . . . . . . . .  48
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  48
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  48
       10.2.  Informative References . . . . . . . . . . . . . . . . .  50



  McCarthy-Howe             Expires 2 April 2026                  [Page 3]


  Internet-Draft              SIP MCP Extension             September 2025


     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  50

  1.  Introduction

     The Model Context Protocol (MCP) is an application protocol for
     structured interaction with tools and agents.  While MCP enables
     powerful AI agent capabilities, real-world production deployments
     have revealed significant transport-layer limitations that impact
     reliability, performance, and user experience.

  1.1.  Problem Statement: MCP Transport Layer Failures

     Current MCP implementations encounter measurable failures in
     production environments, particularly affecting latency, reliability,
     and scalability:

     *Performance Impact*: Production deployments show MCP adds 300-800ms
     latency when invoked synchronously in critical transaction paths,
     with developers reporting this "destroys user experience" in
     customer-facing systems.  P99 latency spikes cause substantial delays
     for the slowest 1% of transactions, leading to user frustration and
     cascading timeouts in orchestration flows.

     *Reliability Issues*: Production scenarios report recovery failure
     rates of 20-30% without explicit error handling at the transport
     layer.  STDIO pipes break silently, HTTP connection pools saturate
     under high load, and WebSocket connections disconnect-reconnect
     repeatedly, causing agents to lose context or fail mid-task.

     *Scalability Limitations*: Connecting multiple tool servers (e.g.,
     Github, Linear, Playwright) can consume over 60,000 tokens of context
     capacity, leading to expensive API overages and poor agent
     performance.  Each MCP server operates in isolation with no shared
     state, forcing users to repeat steps or lose workflow progress
     between sessions.

     *Developer Experience*: The official documentation for developing
     custom transports is lacking, the concepts section is complex, and
     the Python SDK lacks foundational interfaces, creating significant
     barriers to adoption and reliable implementation.











  McCarthy-Howe             Expires 2 April 2026                  [Page 4]


  Internet-Draft              SIP MCP Extension             September 2025


  1.1.1.  Summary of MCP Transport Pain Points

      +=====================+====================+=====================+
      | Failure Mode/Metric | Current MCP Impact | Real-World Evidence |
      +=====================+====================+=====================+
      | High Latency        | Synchronous MCP    | "Destroys user      |
      | (300-800ms)         | flows              | experience"         |
      +---------------------+--------------------+---------------------+
      | Connection          | STDIO pipes,       | "Pipes break        |
      | Instability         | WebSocket          | silently"           |
      +---------------------+--------------------+---------------------+
      | Context/Token Bloat | Multiple tool      | "60,000 tokens      |
      |                     | servers            | consumed"           |
      +---------------------+--------------------+---------------------+
      | Isolation, No State | Multi-step         | "Users repeat       |
      |                     | workflows          | steps"              |
      +---------------------+--------------------+---------------------+
      | Lack of             | Custom transport   | "Documentation      |
      | Documentation       | dev                | lacking"            |
      +---------------------+--------------------+---------------------+
      | P99 Latency Spikes  | Tail latency in    | Cascading timeouts  |
      |                     | flows              |                     |
      +---------------------+--------------------+---------------------+

                                   Table 1

  1.2.  SIP as a Solution

     SIP is widely deployed for rendezvous, session negotiation, and
     inter-domain federation.  This document defines a minimal, backward-
     compatible SIP extension enabling MCP-aware endpoints to discover
     each other and exchange MCP messages using existing SIP methods,
     addressing the transport-layer limitations identified in current MCP
     deployments.

  1.3.  Use Cases Addressed

     This SIP extension for MCP addresses both general AI agent
     communication needs and specific scenarios that are uniquely enabled
     by SIP's architectural capabilities.











  McCarthy-Howe             Expires 2 April 2026                  [Page 5]


  Internet-Draft              SIP MCP Extension             September 2025


  1.3.1.  General MCP Use Cases Enhanced by SIP

     *Enterprise AI Agent Orchestration*: Organizations deploying multiple
     specialized AI agents (document processing, customer service, data
     analysis) require reliable, low-latency communication between agents.
     SIP's session management eliminates the 300-800ms latency penalties
     documented in current HTTP-based MCP deployments, while its proxy
     infrastructure enables intelligent routing based on agent
     capabilities.

     *Multi-Modal AI Interactions*: Modern AI applications increasingly
     combine text, voice, and visual processing.  SIP's media negotiation
     framework allows simultaneous audio streams (for voice interaction)
     and MCP data exchange (for tool calls and structured responses),
     enabling natural voice-guided AI workflows that are impractical with
     current MCP transports.

     *Cross-Organizational AI Collaboration*: AI agents from different
     organizations need to collaborate while respecting security
     boundaries and policies.  SIP's mature inter-domain federation model
     provides the trust management and policy enforcement mechanisms
     necessary for secure cross-organizational agent interactions.

     *High-Availability AI Services*: Production AI systems require robust
     failover and load distribution.  SIP's registration-based discovery
     provides 60-120 second agent availability updates (vs. 5-10 minutes
     with DNS), while proxy-based load balancing eliminates the single
     points of failure common in current MCP deployments.

  1.3.2.  SIP-Unique Use Cases

     *Voice-First AI Agent Interactions*: Call centers, voice assistants,
     and telephony-integrated AI systems require tight coordination
     between voice streams and AI tool execution.  SIP's native audio
     handling combined with MCP tool calls enables scenarios like: -
     Customer service agents that can simultaneously talk to customers and
     execute backend tool calls - Voice-controlled document processing
     where spoken commands trigger complex AI workflows - Real-time
     language translation with tool-assisted context lookup

     *Telecommunications-Integrated AI*: Existing SIP infrastructure in
     telecommunications and enterprise environments can be extended to
     support AI agents without requiring parallel communication systems: -
     PBX systems can route calls to AI agents based on detected
     capabilities - Existing SIP monitoring and billing systems can track
     AI agent usage - Telecom-grade reliability and security models apply
     to AI agent communications




  McCarthy-Howe             Expires 2 April 2026                  [Page 6]


  Internet-Draft              SIP MCP Extension             September 2025


     *Session-Aware AI Workflows*: Long-running AI processes that maintain
     conversational context across multiple interactions benefit from
     SIP's dialog management: - Multi-step document review processes where
     agents maintain state across sessions - Collaborative AI workflows
     where multiple agents contribute to extended tasks - Educational AI
     tutors that maintain learning context across multiple sessions

     *Multimedia AI Tool Calling*: The combination of MCP with MSRP
     enables sophisticated multimedia AI interactions: - Image analysis
     agents that receive binary image data without base64 encoding
     overhead - Document processing agents that can stream large generated
     reports in real-time - Creative AI agents that exchange multimedia
     assets (images, audio, video) as part of tool calls

  1.3.3.  Performance-Critical Use Cases

     *Real-Time AI Decision Making*: Applications requiring sub-second AI
     responses benefit from SIP's persistent session model: - Financial
     trading systems with AI-assisted decision making - Industrial control
     systems with AI-based optimization - Emergency response systems with
     AI-powered resource allocation

     *High-Throughput AI Processing*: Batch processing scenarios where
     multiple AI agents need to coordinate efficiently: - Large-scale
     document processing pipelines - Distributed AI training coordination
     - Parallel data analysis workflows

  1.3.4.  Regulatory and Compliance Use Cases

     *Auditable AI Interactions*: Industries with strict audit
     requirements can leverage SIP's mature logging and monitoring
     ecosystem: - Healthcare AI systems requiring HIPAA compliance -
     Financial AI systems requiring transaction audit trails - Government
     AI systems requiring security clearance-based access control

     *Privacy-Preserving AI Federation*: Organizations needing to
     collaborate while maintaining data sovereignty: - Healthcare research
     collaborations across institutions - Financial consortium AI without
     data sharing - Government intelligence sharing with compartmentalized
     access

  1.3.5.  Migration and Integration Use Cases

     *Gradual MCP Transport Migration*: Organizations can incrementally
     adopt SIP-based MCP without disrupting existing systems: - Hybrid
     deployments supporting both HTTP and SIP transports - Phased
     migration from WebSocket to SIP-based agent communication - A/B
     testing of transport performance in production environments



  McCarthy-Howe             Expires 2 April 2026                  [Page 7]


  Internet-Draft              SIP MCP Extension             September 2025


     *Legacy System Integration*: Existing SIP infrastructure can be
     extended to support modern AI capabilities: - Contact centers adding
     AI agents to existing SIP-based phone systems - Enterprise
     communications platforms integrating AI assistants -
     Telecommunications providers offering AI services through existing
     SIP infrastructure

     These use cases demonstrate that while SIP adds implementation
     complexity compared to simpler transports like HTTP, it enables
     entirely new classes of AI agent interactions that are impractical or
     impossible with current MCP transport mechanisms.  The extension is
     particularly valuable for organizations with existing SIP
     infrastructure, real-time performance requirements, or complex inter-
     organizational collaboration needs.

  1.4.  Architectural Justification

  1.4.1.  Why SIP for MCP Transport?

     While MCP can operate over various transports including HTTP and
     WebSocket, SIP provides unique architectural advantages that make it
     particularly suitable for agent-to-agent communication scenarios:

     *Session Management and State*: SIP's inherent session model aligns
     naturally with MCP's stateful conversation paradigm.  Unlike
     stateless HTTP interactions, SIP dialogs provide persistent session
     context that can maintain MCP conversation state, tool availability,
     and capability negotiations throughout the interaction lifecycle.

     *Rendezvous and Discovery*: SIP's registration and location services
     enable dynamic discovery of MCP-capable agents across network
     boundaries with superior performance characteristics compared to DNS-
     based alternatives.  SIP registrations provide programmable TTLs
     (60-3600+ seconds) with immediate effect, enabling rapid agent
     deployment and failover scenarios that are impractical with DNS
     propagation delays (typically 300+ seconds).

     *Inter-domain Federation*: SIP's mature federation model allows MCP
     interactions to span organizational boundaries securely.  This
     enables scenarios where agents from different organizations can
     collaborate while respecting domain policies and security boundaries.

  1.4.2.  Limitations of HTTP/WebSocket-Only Approaches

     Real-world MCP deployments have demonstrated concrete failure modes
     and performance limitations with current transport approaches:





  McCarthy-Howe             Expires 2 April 2026                  [Page 8]


  Internet-Draft              SIP MCP Extension             September 2025


     *HTTP Transport Failures*: - Lacks built-in session management
     requiring application-layer session tracking - No standardized
     discovery mechanism for dynamic agent location; DNS-based discovery
     suffers from propagation delays (300+ seconds) making rapid
     deployment and failover impractical - Limited support for inter-
     domain routing and federation - Requires additional infrastructure
     for load balancing and failover - *Production Impact*: HTTP
     connection pools saturate under high load, causing timeouts that are
     difficult to correlate with specific upstream errors - *"Universal
     Router Trap"*: Teams routing every user query through MCP over HTTP
     add hundreds of milliseconds to critical flows (e.g., e-commerce
     checkout), leading to lost conversions and board-level escalation of
     failures

     *WebSocket Transport Failures*: - Requires pre-established HTTP
     connection setup - No inherent support for multi-party sessions or
     session transfer - Limited routing capabilities for complex network
     topologies - Lacks standardized capability advertisement mechanisms -
     *Production Impact*: Persistent connections disconnect and reconnect
     repeatedly under real-world network variability, causing agents to
     lose context or fail mid-task - *Reliability Issues*: Error rates
     above 0.1% indicate systemic issues, with recovery failure rates of
     20-30% without explicit error handling

     *STDIO Transport Failures*: - *Silent Failures*: STDIO pipes break
     silently, leading to mysterious dropped connections that are not
     detected until a downstream process fails - *Process Management*:
     Difficult to monitor and manage process lifecycle in production
     environments - *Scalability*: Limited to single-process communication
     patterns

  1.4.3.  SIP's Value-Added Capabilities

     *Advanced Routing*: SIP's proxy infrastructure enables sophisticated
     routing based on MCP capabilities, load distribution, and policy
     enforcement.  Proxies can inspect MCP-Capabilities headers to route
     requests to appropriate agents.

     *Session Mobility*: SIP's re-INVITE mechanism allows MCP sessions to
     be transferred between agents or modified mid-conversation, enabling
     scenarios like agent handoff or capability escalation.

     *Multi-modal Integration*: SIP's media negotiation framework allows
     MCP data exchange to be combined with audio/video streams, enabling
     rich multi-modal agent interactions (voice + tool calls).






  McCarthy-Howe             Expires 2 April 2026                  [Page 9]


  Internet-Draft              SIP MCP Extension             September 2025


     *Security and Privacy*: SIP's established security model (TLS, S/
     MIME, SIPS) provides end-to-end security for sensitive MCP
     interactions, with well-understood privacy and authentication
     mechanisms.

  1.4.4.  Discovery Performance Analysis: SIP vs. DNS

     A critical architectural advantage of SIP-based MCP transport lies in
     its superior discovery performance characteristics:

     *DNS-Based Discovery Limitations*: - Standard DNS TTL values
     (300-3600 seconds) create significant delays for agent availability
     updates - DNS cache invalidation requires waiting for TTL expiration
     across all resolvers in the path - Reducing TTLs below 60 seconds
     increases authoritative server load and is often impractical - Global
     DNS propagation can take 5-15 minutes for cross-domain scenarios -
     DNS is optimized for relatively static records, not dynamic service
     availability

     *SIP Registration Performance Advantages*: - Registration refresh
     intervals programmable from 60 seconds to hours based on agent
     characteristics - Immediate effect upon registrar receipt - no
     propagation delays - Failed registrations detected within one refresh
     interval (60-180 seconds typical) - Explicit de-registration provides
     immediate service removal - Bulk capability updates possible in
     single REGISTER transaction - Local consistency within registration
     domain eliminates cache coherency issues

     *Quantitative Performance Comparison*: - Agent deployment: 60-120
     seconds (SIP) vs. 5-10 minutes (DNS) - Failover detection: 60-180
     seconds (SIP) vs. 5-15 minutes (DNS) - Cross-domain discovery: 60-300
     seconds (SIP peering) vs. 5-15 minutes (global DNS) - Capability
     updates: Immediate (SIP) vs. TTL-dependent (DNS)

     This performance differential is critical for AI agent ecosystems
     requiring rapid adaptation to changing agent availability and
     capabilities.

  1.4.5.  Quantitative Performance Analysis: SIP vs. Current MCP
          Transports

     Real-world deployment data demonstrates significant performance
     advantages of SIP-based transport over current MCP approaches:








  McCarthy-Howe             Expires 2 April 2026                 [Page 10]


  Internet-Draft              SIP MCP Extension             September 2025


     *Latency Comparison*: - *Current MCP over HTTP*: 300-800ms added
     latency in production systems - *SIP-based MCP*: Sub-100ms for
     signaling, with persistent session context eliminating repeated
     handshakes - *P99 Latency*: SIP's session-oriented model reduces tail
     latency by maintaining persistent connections vs. HTTP's per-request
     overhead

     *Reliability Metrics*: - *Current MCP Transports*: 20-30% recovery
     failure rates without explicit error handling - *SIP-based MCP*:
     Built-in error handling and recovery mechanisms with standardized
     error codes - *Connection Stability*: SIP's dialog management
     provides explicit session state vs. silent failures in STDIO/
     WebSocket

     *Scalability Characteristics*: - *Current MCP*: 60,000+ tokens
     consumed by multiple tool servers, causing API cost overages - *SIP-
     based MCP*: Capability negotiation and filtering reduces unnecessary
     context transmission - *Session Management*: Persistent SIP dialogs
     maintain state vs. stateless HTTP requiring repeated context
     establishment

     *Developer Experience Improvements*: - *Current MCP*: Lacking
     documentation and complex custom transport development - *SIP-based
     MCP*: Leverages mature SIP ecosystem with extensive tooling,
     libraries, and operational experience - *Standardization*: Well-
     defined extension points vs. ad-hoc transport implementations

  1.4.6.  Specific Use Cases Addressing Real-World MCP Problems

     *Avoiding the "Universal Router Trap"*: Organizations currently
     experiencing 300-800ms latency penalties from routing every user
     query through MCP can use SIP's capability-based routing to
     selectively engage MCP only when needed, with proxies routing based
     on MCP-Capabilities headers to appropriate specialized agents.

     *Enterprise Agent Federation with Shared State*: Large organizations
     struggling with isolated MCP servers that force users to repeat steps
     can leverage SIP's session management to maintain persistent agent
     context across departmental boundaries, with secure, policy-
     controlled inter-agent communication through SIP's domain-based
     routing.

     *High-Availability Agent Deployments*: Production environments
     experiencing 20-30% recovery failure rates can benefit from SIP's
     built-in error handling, automatic failover mechanisms, and proxy-
     based load distribution, eliminating silent failures common in STDIO
     pipes and WebSocket disconnections.




  McCarthy-Howe             Expires 2 April 2026                 [Page 11]


  Internet-Draft              SIP MCP Extension             September 2025


     *Cross-Vendor Agent Interoperability*: Organizations facing
     integration complexity when connecting multiple tool servers (Github,
     Linear, Playwright) that consume excessive context tokens can use
     SIP's standardized capability negotiation to filter and optimize tool
     availability per session, reducing API costs and improving
     performance.

     *Real-time Multi-modal Interactions*: Voice-enabled agents requiring
     tight coordination between audio streams and structured data exchange
     can leverage SIP's media negotiation capabilities to eliminate the
     temporal correlation issues that plague current WebSocket-based
     approaches.

     *Regulated Environments with Audit Requirements*: Industries
     requiring comprehensive audit trails, session recording, and
     compliance monitoring can leverage SIP's mature ecosystem of
     monitoring and compliance tools, addressing the documentation and
     operational gaps identified in current MCP custom transport
     implementations.

  1.4.7.  Alternative Transport Solutions Analysis

     Before justifying SIP as the preferred transport, it is important to
     analyze how other modern protocols could address the identified MCP
     transport problems:

  1.4.7.1.  HTTP/2-Based RPC Framework Analysis

     *Advantages for MCP Transport:* - *Performance*: HTTP/2 multiplexing
     and header compression could significantly reduce the documented
     300-800ms latency through connection reuse - *Streaming*:
     Bidirectional streaming naturally handles large tool responses and
     real-time interactions - *Type Safety*: Protocol Buffers provide
     stronger schema validation than JSON-RPC - *Developer Experience*:
     Excellent tooling, code generation, and comprehensive documentation
     address the "lacking documentation" pain point - *Reliability*:
     Built-in connection management and keepalives improve upon WebSocket
     instability

     *Limitations for MCP Use Cases:* - *Discovery Latency*: Still
     dependent on DNS-based service discovery with the same 300+ second
     propagation delays - *Session State*: Stateless by design - does not
     address the "isolated servers" problem where users lose workflow
     progress - *Federation*: No built-in inter-domain routing or policy
     enforcement mechanisms - *Infrastructure*: Requires HTTP/2-aware load
     balancers and proxies





  McCarthy-Howe             Expires 2 April 2026                 [Page 12]


  Internet-Draft              SIP MCP Extension             September 2025


  1.4.7.2.  QUIC Analysis

     *Advantages for MCP Transport:* - *Latency*: 0-RTT connection
     establishment could eliminate most connection setup overhead -
     *Reliability*: Connection migration handles network changes better
     than WebSocket disconnections - *Multiplexing*: Stream-level flow
     control prevents head-of-line blocking that affects HTTP/1.1
     approaches

     *Limitations for MCP Use Cases:* - *Discovery*: No improvement over
     DNS-based service discovery limitations - *Session Semantics*:
     Provides transport-level reliability but no application session
     management - *Ecosystem Maturity*: Fewer libraries and operational
     tools compared to established protocols - *Infrastructure*: Requires
     QUIC-aware network infrastructure and load balancers

  1.4.7.3.  AMQP Analysis

     *Advantages for MCP Transport:* - *Reliability*: Message
     acknowledgments and persistence could address the documented 20-30%
     recovery failure rates - *Routing*: Topic-based routing enables
     sophisticated capability-based message distribution - *Scalability*:
     Message queuing naturally handles load spikes and decouples agent
     interactions - *Durability*: Message persistence prevents loss during
     agent failures

     *Limitations for MCP Use Cases:* - *Latency*: Message queuing
     overhead may not improve synchronous tool call performance - *Session
     Context*: Message-oriented design doesn't maintain conversational
     state across interactions - *Infrastructure Complexity*: Requires
     broker clustering, queue management, and specialized monitoring -
     *Operational Overhead*: Significant deployment and maintenance
     complexity

  1.4.7.4.  Comparative Analysis Summary

     +=================+==========+=========+============+==============+
     | Capability      |HTTP/2 RPC|QUIC     | AMQP       | SIP+MCP      |
     +=================+==========+=========+============+==============+
     | *Latency        |Yes HTTP/2|Yes 0-RTT| Partial    | Yes          |
     | Reduction*      |mux       |         | Queuing    | Persistent   |
     +-----------------+----------+---------+------------+--------------+
     | *Connection     |Yes       |Yes      | Yes Auto-  | Yes Dialog   |
     | Stability*      |Keepalives|Migration| recon      | mgmt         |
     +-----------------+----------+---------+------------+--------------+
     | *Service        |No DNS-dep|No DNS-  | Partial    | Yes          |
     | Discovery*      |          |dep      | Broker     | Registration |
     +-----------------+----------+---------+------------+--------------+



  McCarthy-Howe             Expires 2 April 2026                 [Page 13]


  Internet-Draft              SIP MCP Extension             September 2025


     | *Session State* |No        |No       | No Message | Yes Dialog   |
     |                 |Stateless |Transport|            | ctx          |
     +-----------------+----------+---------+------------+--------------+
     | *Inter-domain   |No support|No       | Partial    | Yes Native   |
     | Federation*     |          |support  | Broker fed | fed          |
     +-----------------+----------+---------+------------+--------------+
     | *Implementation |Yes Low   |Partial  | No High    | No High      |
     | Complexity*     |          |Medium   |            |              |
     +-----------------+----------+---------+------------+--------------+
     | *Operational    |Yes Low   |Partial  | No High    | No High      |
     | Complexity*     |          |Medium   |            |              |
     +-----------------+----------+---------+------------+--------------+
     | *Multi-modal    |No Data-  |No Data- | No Data-   | Yes          |
     | Integration*    |only      |only     | only       | Audio+Data   |
     +-----------------+----------+---------+------------+--------------+

                                   Table 2

  1.4.7.5.  When to Choose SIP Over Simpler Alternatives

     *Choose HTTP/2-based RPC frameworks if:* - The main goal is to reduce
     latency and enhance developer experience. - The deployment is within
     a single domain and does not require complex federation. - Agent
     interactions are stateless or short-lived. - There is existing HTTP/2
     infrastructure and in-house expertise.

     *Choose SIP+MCP if:* - *Complex inter-domain federation* with policy
     enforcement is necessary. - *Long-lived conversational sessions* with
     persistent state management are required. - *Integration with
     existing SIP infrastructure* (such as telecom or enterprise
     environments) is desired. - *Multi-modal coordination* (e.g., voice
     plus structured data) is a requirement. - *Registration-based
     discovery* with faster performance (60-120 seconds vs. 5-10 minutes)
     is critical.

     This analysis shows that while HTTP/2-based RPC frameworks can
     resolve many MCP transport issues with less complexity, SIP offers
     unique capabilities for certain deployment scenarios that warrant the
     additional implementation effort.

  1.4.8.  Backward Compatibility and Incremental Deployment

     This extension supports incremental deployment: - Existing SIP
     infrastructure does not require modification. - Endpoints that are
     not MCP-aware will gracefully reject MCP requests using standard SIP
     error responses. - MCP-capable endpoints can fall back to alternative
     transport methods if SIP peers do not support the extension. - The
     extension does not alter core SIP semantics or existing header



  McCarthy-Howe             Expires 2 April 2026                 [Page 14]


  Internet-Draft              SIP MCP Extension             September 2025


     fields.

  2.  Model Context Protocol (MCP) - Purpose, Architecture, Capabilities

     This section orients SIP implementers to MCP.  It is informative and
     summarizes the MCP model at a level sufficient to map MCP onto SIP
     signaling and mid-dialog exchanges.

  2.1.  Purpose (non-normative)

     MCP is an open protocol that standardizes how AI applications connect
     to external data and tools.  It separates "context providers" from
     host applications so that an AI app can compose capabilities from
     many independent MCP servers while preserving clear security and
     consent boundaries.  At its core, MCP uses JSON-RPC 2.0 messages to
     exchange context, discover capabilities, and invoke operations in a
     uniform way.

  2.2.  Architecture (non-normative)

     MCP follows a host-client-server pattern:

     *  *MCP Host:* the AI application (e.g., IDE, desktop app, chat
        system) that manages one or more MCP clients.

     *  *MCP Client:* a connector inside the host that maintains a
        dedicated 1:1 connection to a single MCP server.

     *  *MCP Server:* a program that exposes context (data) and actions
        (tools/prompts) to clients.

     The protocol has two layers:

     *  *Data layer (inner):* a JSON-RPC 2.0 based protocol defining
        message structure, lifecycle (initialization, capability
        negotiation), and the primitives each side offers.

     *  *Transport layer (outer):* the channel over which JSON-RPC
        messages flow.  MCP commonly uses two transports:

        -  *stdio:* local process IPC over stdin/stdout, typically for
           "local" servers launched by the host.

        -  *Streamable HTTP:* remote servers communicating via HTTP POSTs,
           with optional Server-Sent Events (SSE) for streaming and
           server-initiated messages.





  McCarthy-Howe             Expires 2 April 2026                 [Page 15]


  Internet-Draft              SIP MCP Extension             September 2025


     Sessions are stateful: during initialization, client and server
     negotiate protocol version and capabilities and may bind a session
     identifier that is echoed on subsequent transport operations.

  2.3.  Capabilities and Primitives (non-normative)

     MCP defines structured "primitives" that either side can expose:

     *  *Server-side primitives*

        -  *Resources:* URI-identified data the client can list and read
           (text or binary), optionally subscribe to for updates, and
           receive change notifications for.

        -  *Tools:* executable functions with JSON Schema-described
           inputs; clients discover tools and invoke them to perform
           actions such as database queries or API calls.

        -  *Prompts:* reusable, parameterized prompt templates that hosts
           can fetch and render for users or models.

     *  *Client-side primitives*

        -  *Sampling:* a server can request the host to obtain model
           completions (i.e., to "call the LLM") without bundling a model
           SDK inside the server.

        -  *Elicitation and logging:* optional utilities for user
           interaction and diagnostics.

     MCP also includes cross-cutting utilities for configuration, progress
     tracking, cancellation, and notifications.  Together, these enable
     dynamic discovery, composition across multiple servers, and fine-
     grained control over what data and actions are available to a given
     conversation.

  3.  Conventions and 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.

     ABNF is per [RFC5234].  SIP terms are per [RFC3261].  Feature-
     capability indicators follow [RFC6809].





  McCarthy-Howe             Expires 2 April 2026                 [Page 16]


  Internet-Draft              SIP MCP Extension             September 2025


  3.1.  Applicability Statement

     This section defines the intended scope and limitations of this SIP
     extension for MCP transport, as required for Informational RFCs per
     [RFC5727].

  3.1.1.  Intended Use Cases

     This extension is designed for the following specific scenarios:

     *Agent-to-Agent Communication*: AI agents that need to exchange
     structured tool calls, context, and capabilities while maintaining
     session state and supporting real-time interaction patterns.

     *Enterprise AI Integration*: Organizations deploying multiple AI
     systems that require secure, policy-controlled inter-agent
     communication across network boundaries with audit trails and
     compliance monitoring.

     *Multi-modal AI Applications*: Systems combining voice interaction
     with structured data exchange, where SIP's media negotiation
     capabilities enable coordinated audio and MCP data streams.

     *Federated AI Networks*: Cross-organizational AI collaboration
     requiring SIP's mature inter-domain routing, security, and federation
     capabilities.

  3.1.2.  Appropriate Deployment Environments

     *Controlled Networks*: Enterprise environments with existing SIP
     infrastructure where administrators can manage MCP-capable endpoints
     and configure appropriate security policies.

     *Federated Deployments*: Inter-organizational scenarios where SIP's
     domain-based routing and security model provides necessary trust
     boundaries and policy enforcement.

     *Real-time Applications*: Use cases requiring low-latency session
     establishment, capability negotiation, and the ability to correlate
     voice and data streams temporally.

  3.1.3.  Limitations and Constraints

     *Not for General Internet Use*: This extension is not intended for
     general Internet deployment where endpoints cannot be trusted or
     where security policies cannot be enforced.  The combination of AI
     capabilities with network protocols requires careful security
     consideration.



  McCarthy-Howe             Expires 2 April 2026                 [Page 17]


  Internet-Draft              SIP MCP Extension             September 2025


     *Requires SIP Infrastructure*: Organizations without existing SIP
     infrastructure should carefully evaluate whether the benefits justify
     the deployment complexity compared to HTTP/WebSocket alternatives.

     *Limited to MCP Protocol*: This extension specifically supports MCP
     and is not a general-purpose AI protocol transport mechanism.  Other
     AI protocols would require separate extensions.

     *Security Dependencies*: The security of MCP-over-SIP depends
     entirely on proper TLS deployment, certificate management, and SIP
     security best practices.  Improper security configuration could
     expose sensitive AI capabilities and data.

  3.1.4.  Alternative Approaches and Selection Criteria

     This extension should be considered alongside other transport
     solutions that may address MCP's documented problems with lower
     implementation complexity:

     *HTTP/2-Based RPC Frameworks (Recommended for most use cases)*: -
     *When to use*: Primary concerns are latency reduction (addresses
     300-800ms problem) and developer experience improvement - *Suitable
     for*: Single-domain deployments, stateless interactions, existing
     HTTP/2 infrastructure - *Limitations*: DNS-dependent discovery, no
     session state management, no inter-domain federation

     *QUIC*: - *When to use*: 0-RTT connection establishment is critical
     for performance - *Suitable for*: Transport-level reliability
     improvements, connection migration scenarios - *Limitations*:
     Requires new infrastructure, no application session semantics

     *AMQP*: - *When to use*: Message reliability and sophisticated
     routing are primary concerns - *Suitable for*: Asynchronous agent
     interactions, complex message routing patterns - *Limitations*: Adds
     latency overhead, requires broker infrastructure

     *SIP+MCP (This specification)*: - *When to use*: Complex inter-domain
     federation, long-lived conversational sessions, multi-modal
     integration, or existing SIP infrastructure - *Suitable for*:
     Enterprise/telecom environments, cross-organizational agent
     collaboration, voice+data coordination - *Trade-off*: Higher
     implementation complexity justified by unique capabilities









  McCarthy-Howe             Expires 2 April 2026                 [Page 18]


  Internet-Draft              SIP MCP Extension             September 2025


     *Selection Decision Tree*: 1. *Need inter-domain federation or multi-
     modal coordination?* -> Use SIP+MCP 2. *Have existing SIP
     infrastructure?* -> Consider SIP+MCP 3. *Primary goal is reducing
     latency/improving developer experience?* -> Use HTTP/2-based RPC
     frameworks 4. *Need sophisticated message routing and persistence?*
     -> Consider AMQP 5. *Transport-level performance is critical?* ->
     Consider QUIC

     *Native MCP Transports*: For applications that don't require the
     reliability, discovery, or federation improvements, native MCP
     transports (stdio, HTTP) may be sufficient despite their documented
     limitations.

  3.1.5.  Migration Path Considerations

     This Informational specification allows implementations to gain
     operational experience before potential future standardization.
     Organizations deploying this extension should:

     *  Monitor interoperability across different implementations

     *  Document security and operational best practices

     *  Evaluate scalability and performance characteristics

     *  Consider migration strategies if future Standards Track
        specifications emerge

     The extension is designed to be compatible with potential future
     Standards Track versions, but implementers should be prepared for
     possible changes based on operational experience and community
     feedback.

  4.  Overview

     *  *Discovery:* endpoints advertise MCP support and granular
        capabilities during REGISTER using Contact feature-caps and/or in
        responses.

     *  *Negotiation:* endpoints indicate desire/requirement for MCP using
        the "mcp" option-tag, and exchange an initial MCP offer/answer in
        INVITE/200 OK bodies as application/mcp+json.

     *  *Exchange:* subsequent MCP messages are carried in SIP MESSAGE or
        INFO bodies with Content-Type: application/mcp+json.  MSRP or a
        SIP-negotiated WebSocket [RFC7118] MAY be used for bulk transport.





  McCarthy-Howe             Expires 2 April 2026                 [Page 19]


  Internet-Draft              SIP MCP Extension             September 2025


     *  *Multimodal:* the same dialog MAY negotiate RTP audio streams
        alongside an MSRP session used to carry MCP; see Section 7.6.

  4.1.  Backward Compatibility

     This extension is designed for seamless backward compatibility with
     existing SIP infrastructure:

     *  *Legacy SIP Implementations:* Existing SIP user agents, proxies,
        and registrars that do not implement this extension continue to
        operate normally.  The extension introduces no changes to core SIP
        semantics, message formats, or processing rules.

     *  *Graceful Degradation:* When one party does not support MCP:

        -  If MCP is optional (Supported: mcp), the session proceeds as a
           standard SIP session without MCP functionality

        -  If MCP is required (Require: mcp), non-supporting endpoints
           respond with 420 (Bad Extension) per [RFC3261], allowing the
           caller to retry without MCP

        -  Unknown header fields (MCP-Capabilities, MCP-Select) are
           ignored per [RFC3261] Section 7.4.1

     *  *Incremental Deployment:* Organizations can deploy MCP-capable
        endpoints gradually without requiring network-wide upgrades.
        Mixed environments with both MCP-aware and legacy endpoints
        operate without disruption.

  4.2.  Agent-to-Agent Interoperation (Summary) _(non-normative)_

     This extension enables heterogeneous "agents" (any SIP UA with MCP
     support, including voice bots, tool/knowledge agents, or co-pilots)
     to interoperate across two coordinated planes:

     *Dual-plane sessioning*

     *  *Multimedia plane (audio):* negotiated with SDP m=audio and
        carried over RTP/SRTP (e.g., Opus).  Supports live capture,
        playback (TTS), and natural turn-taking features like barge-in
        (Section 7.5).

     *  *MCP plane (control/data):* negotiated with SDP m=message for
        MSRP/msrps and carried as application/mcp+json.  Transports JSON-
        RPC requests/responses, tool calls, transcripts, prompt
        selections, policy updates, and events (e.g., VAD start/stop).




  McCarthy-Howe             Expires 2 April 2026                 [Page 20]


  Internet-Draft              SIP MCP Extension             September 2025


     *Discovery and routing*

     *  Agents advertise and select capabilities using Supported: mcp,
        *MCP-Capabilities* (what I can do) and *MCP-Select* (what I want
        you to do now).

     *  Proxies/registrars can steer traffic based on *+mcp*, *+mcp.ver*,
        and *+mcp.cap* (Section 5.4) to reach a peer that offers the
        needed tool bundle (e.g., summarize@2, translate@1).

     *Tight coupling between planes*

     *  *Temporal correlation:* MCP messages can reference audio timing
        using RTP/RTCP (e.g., mid, RTP timestamp, RTCP NTP; see
        Section 7.5.4), allowing precise alignment of transcripts, barge-
        in, and tool side-effects with the audible experience.

     *  *Turn management:* Barge-in, pause/resume TTS, and endpointing are
        signaled as MCP events/controls over MSRP (Section 7.5.5),
        reducing race conditions compared to pure SIP signaling.

     *  *Handover:* Standard SIP mechanisms (re-INVITE/UPDATE, REFER,
        Replaces) allow media or control to be retargeted to another agent
        while preserving the MCP session and capability context.

     *Security alignment*

     *  SRTP (with DTLS-SRTP keying) protects audio; *msrps (TLS)*
        protects MCP.  S/MIME can add end-to-end protection when MCP rides
        inside SIP.  Policies can minimize capability disclosure via
        scoped MCP-Capabilities.

  4.2.1.  Concrete Use Cases

     *Use Case 1 - Cross-vendor Voice Agent <-> Tooling/Reasoning Agent
     (Customer Triage)*

     1.  *INVITE/Answer:* Voice agent (A) INVITEs tooling agent (B) with
         Supported: mcp, MCP-Capabilities (vad@1, tts.control@1,
         transcript@1), and SDP with m=audio (SRTP) + m=message (msrps
         accepting application/mcp+json).

     2.  *Live audio:* Caller <-> A over SRTP; A forwards selected audio
         (or derived events) to B.

     3.  *MCP over MSRP:* A streams incremental transcripts + VAD events
         to B as MCP notifications.




  McCarthy-Howe             Expires 2 April 2026                 [Page 21]


  Internet-Draft              SIP MCP Extension             September 2025


     4.  *Tool calls:* B issues MCP tools/call (e.g., crm.lookup@2,
         kb.search@3); results flow back over MSRP.

     5.  *TTS control & barge-in:* B responds with guidance (prompts,
         summaries) and optional speech/control (pause/resume) messages; A
         updates playback.

     6.  *Outcome:* If B determines a handoff is needed (billing), A uses
         REFER/re-INVITE to transfer media to a human while *keeping the
         MCP session* between A and B alive for notes and next-best-
         action.

     *Use Case 2 - Inter-domain Real-time Translation Agent <-> Concierge/
     Scheduler Agent*

     1.  *Negotiation:* Translation agent (X) INVITEs concierge agent (Y)
         with SRTP Opus audio + msrps MSRP for MCP; MCP-Capabilities
         advertises translate@1, diarize@1, transcript@1 (X) and
         calendar.schedule@2, crm.note@1 (Y).

     2.  *Audio & timing:* RTP carries caller speech to X; X emits MCP
         events with mid, RTP TS, and RTCP-aligned NTP times for each
         segment.

     3.  *MCP workflow:* X sends recognized segments as MCP notifications
         to Y; Y returns structured intents (e.g., schedule.meeting) and
         calls its calendar tool.

     4.  *User feedback:* Y provides target-language prompts back to X; X
         performs TTS locally and plays audio to the caller over SRTP.

     5.  *Completion:* Y sends a confirmation payload (ICS link, booking
         ID) over MCP; X renders a short audible summary and ends the
         call.

  5.  SIP Extensions

  5.1.  Option-Tag: mcp

     *Note:* As an Informational RFC, this document does not register the
     "mcp" option tag (which requires Standards Action per RFC 5727).
     Implementations SHOULD use experimental option tags such as "x-mcp"
     or organization-specific variants until a Standards Track
     specification is available.

     The option-tag indicates support for this specification:





  McCarthy-Howe             Expires 2 April 2026                 [Page 22]


  Internet-Draft              SIP MCP Extension             September 2025


     *  A UAC MAY include the option tag in a Require header when MCP
        support is mandatory for the request; proxies/UAS that do not
        understand the tag will respond with 420 (Bad Extension).

     *  A UAC or UAS MAY include the option tag in Supported to advertise
        support.

  5.2.  Header: MCP-Capabilities

     The MCP-Capabilities header field conveys a concise, serializable
     summary of available MCP tools/functions and versions.

     Example (folded for display): MCP-Capabilities: ver=1.0;
     tools="summarize@2,sql.query@1";
     schemas="urn:ex:doc:1,urn:ex:customer:3"

     Semantics: * Endpoints MAY include MCP-Capabilities in REGISTER,
     INVITE, 200 OK, and OPTIONS. * Parsable by intermediaries for routing
     hints; see Section 7.1.

     *Backward Compatibility:* Per RFC 3261 Section 7.4.1, SIP
     implementations that do not recognize this header field MUST ignore
     it.  This ensures that existing SIP infrastructure continues to
     function normally when processing messages containing MCP-
     Capabilities headers.

  5.3.  Header: MCP-Select

     The MCP-Select header communicates a caller's desired subset or mode
     of MCP operation (e.g., chosen tool bundle, schemas, or role).

     Example: MCP-Select: tools="summarize@2"; role="assistant";
     policy="safe"

     Semantics: * MAY appear in INVITE or mid-dialog requests (e.g.,
     UPDATE, INFO) to request a change to the active MCP capability set.

     *Backward Compatibility:* Like MCP-Capabilities, this header field is
     ignored by SIP implementations that do not recognize it, ensuring no
     impact on existing SIP processing.

  5.4.  Contact Feature-Caps: +mcp, +mcp.ver, +mcp.cap

     This document defines feature-capability indicators per RFC 6809:

     +mcp           ; boolean presence indicates MCP support
     +mcp.ver       ; token, MCP major.minor version (e.g., "1.0")
     +mcp.cap       ; quoted-string; capability token set



  McCarthy-Howe             Expires 2 April 2026                 [Page 23]


  Internet-Draft              SIP MCP Extension             September 2025


     Example Contact header parameter usage in REGISTER: Contact:
     <sip:alice@ua.example>;expires=3600; +mcp; +mcp.ver="1.0";
     +mcp.cap="summarize@2,sql.query@1,urn:ex:doc:1"

     *Backward Compatibility:* Feature-capability indicators follow RFC
     6809 semantics.  SIP registrars and proxies that do not understand
     these parameters treat them as opaque Contact header parameters and
     preserve them during registration processing.  This allows MCP-aware
     endpoints to discover each other even in mixed environments with
     legacy infrastructure.

  6.  Payload Format: application/mcp+json

     *Media type:* application/mcp+json *Encoding:* UTF-8

     Two forms are defined:

     *(a) Native MCP message:* the body is a single MCP JSON-RPC 2.0
     request, response, or notification as defined by the MCP
     specification.

     *(b) SIP negotiation envelope (Offer/Answer only):* the body is a
     small JSON object used to pre-negotiate MCP roles/capabilities within
     SIP INVITE/200.  Example:

     ```json { "mcp_version": "1.0", "type": "offer|answer",
     "conversation": "uuid", "payload": { "role": "caller|callee",
     "tools": ["name@ver", "..."], "schemas": ["urn:..."] } }

  Endpoints MUST accept (a). Support for (b) is OPTIONAL and only valid
  during session establishment to prime subsequent MCP exchanges.

  # Protocol Operation

  ## Registration-Time Advertisement

  UAs supporting MCP SHOULD advertise via Contact feature-caps (+mcp,
  +mcp.ver, +mcp.cap). Registrars MAY index these for capability-based
  routing. Proxies MUST treat these parameters as opaque hints and MUST
  NOT modify them.

  ### Registration Performance Characteristics

  MCP-capable agents SHOULD optimize registration refresh intervals based on their operational characteristics:

  **Ephemeral Agents** (short-lived, experimental, or development agents):
  * SHOULD use registration intervals of 60-300 seconds
  * MUST be prepared for immediate de-registration upon shutdown



  McCarthy-Howe             Expires 2 April 2026                 [Page 24]


  Internet-Draft              SIP MCP Extension             September 2025


  * MAY use shorter intervals (60-120 seconds) for rapid discovery requirements

  **Stable Production Agents** (long-running, production services):
  * SHOULD use registration intervals of 1800-3600 seconds (30-60 minutes)
  * MUST implement graceful shutdown with explicit de-registration
  * MAY extend intervals up to 7200 seconds (2 hours) for highly stable services

  **Load-Balanced Agent Pools**:
  * Individual agents SHOULD use 300-900 second intervals
  * Pool members MUST coordinate registration timing to avoid thundering herd effects
  * Failed agents are detected within one refresh interval, enabling rapid failover

  **Cross-Domain Federated Agents**:
  * SHOULD use 600-1800 second intervals to balance discovery speed with inter-domain traffic
  * MUST account for additional network latency in cross-domain scenarios
  * Registration failures trigger exponential backoff with maximum 3600 second intervals

  This registration-based discovery provides significant performance advantages over DNS-based alternatives:
  * New agent availability: 60-300 seconds vs. 300-3600 seconds (DNS TTL)
  * Failed agent detection: 60-1800 seconds vs. 300-3600+ seconds (DNS cache expiration)
  * Capability updates: Immediate upon registration vs. DNS TTL-dependent
  * Cross-domain discovery: Leverages existing SIP peering vs. global DNS propagation delays

  ## Session Establishment (Offer/Answer)

  A UAC desiring MCP:
  * Includes Supported: mcp (and optionally Require: mcp).
  * Sends INVITE with an `application/mcp+json` body of type "offer"
    describing initial MCP role, tools, and schemas (Section 6).

  A UAS accepting MCP:
  * Includes Supported: mcp in 200 OK.
  * Returns `application/mcp+json` of type "answer" with confirmed
    capabilities or reduced set.

  If MCP is rejected but the call proceeds, the UAS omits Supported: mcp
  and returns 415/488 if a body was required.

  ## Mid-Dialog Exchange (MESSAGE/INFO)

  * Short transactional MCP messages MAY be sent using SIP MESSAGE
    (out-of-dialog or in-dialog). Reliable mid-dialog signaling MAY use
    SIP INFO. Bodies MUST be `application/mcp+json`.
  * For large or streaming exchanges, endpoints MAY negotiate MSRP
    [RFC4975]/[RFC4976] or SIP WebSocket [RFC7118] and then tunnel MCP at
    that layer; negotiation is out of scope.

  ## Error Handling



  McCarthy-Howe             Expires 2 April 2026                 [Page 25]


  Internet-Draft              SIP MCP Extension             September 2025


  * 420 (Bad Extension) if Require: mcp is present and unsupported.
  * 415 (Unsupported Media Type) if `Content-Type: application/mcp+json`
    is not supported.
  * Within MCP payloads, application-level errors are signaled using
    MCP's native error members; SIP error codes SHOULD map where
    practical (e.g., 403 for policy, 488 for not acceptable here).

  ## Graceful Degradation Scenarios

  This section describes specific behaviors when MCP support is asymmetric or unavailable:

  **Scenario 1: UAC supports MCP, UAS does not**
  * UAC sends INVITE with Supported: mcp (optional)
  * UAS processes INVITE normally, ignoring MCP-related headers
  * UAS responds with 200 OK without Supported: mcp
  * UAC detects lack of MCP support and proceeds with standard SIP session
  * No MCP functionality is available, but the session succeeds

  **Scenario 2: UAC requires MCP, UAS does not support it**
  * UAC sends INVITE with Require: mcp
  * UAS responds with 420 (Bad Extension) listing "mcp" in Unsupported header
  * UAC MAY retry the request without Require: mcp if fallback is acceptable
  * If no retry occurs, the session fails cleanly with standard SIP error handling

  **Scenario 3: Proxy does not support MCP**
  * Proxies that do not understand MCP-related headers forward them transparently per RFC 3261
  * Feature-capability parameters (+mcp.*) in Contact headers are preserved during registration
  * MCP-Capabilities and MCP-Select headers are forwarded without modification
  * No proxy functionality is impaired

  **Scenario 4: Media type not supported**
  * If UAS supports the "mcp" option-tag but not the `application/mcp+json` media type
  * UAS responds with 415 (Unsupported Media Type)
  * UAC MAY retry with different media type or without MCP body
  * Session MAY proceed with MCP signaling but without initial capability exchange

  **Scenario 5: Mid-dialog MCP failure**
  * If MCP MESSAGE or INFO requests fail (e.g., 415, 501 responses)
  * The underlying SIP dialog remains active and unaffected
  * Endpoints MAY fall back to alternative MCP transport methods
  * Voice or other media streams continue uninterrupted

  ## Multimodal Operation (Audio + MSRP)

  This section specifies how an MCP-enabled dialog can carry interactive
  audio alongside an MSRP-based control/data channel for MCP.

  ### MCP-MSRP Natural Compatibility Analysis



  McCarthy-Howe             Expires 2 April 2026                 [Page 26]


  Internet-Draft              SIP MCP Extension             September 2025


  The combination of MCP and MSRP represents a natural architectural convergence that addresses fundamental limitations in both protocols when used independently:

  **Transport Independence Alignment:**
  MCP was designed as a transport-independent protocol, making it naturally compatible with MSRP's message-oriented transport model. Unlike HTTP's request-response paradigm or WebSocket's connection-oriented approach, MSRP's message-based transport aligns perfectly with MCP's JSON-RPC message exchange patterns.

  **Multimedia Tool Calling Synergy:**

  - **Binary Content Handling**: MSRP's native support for arbitrary content types enables MCP tool calls that involve multimedia artifacts (images, audio clips, documents) without base64 encoding overhead
  - **Chunking and Streaming**: MSRP's built-in chunking mechanism allows large MCP tool responses (e.g., generated documents, analysis results) to be streamed efficiently
  - **Bidirectional Communication**: Both protocols support full-duplex communication, enabling simultaneous tool execution and result streaming

  **Session Management Convergence:**

  - **Reliable Delivery**: MSRP provides reliable, ordered delivery that MCP requires for tool execution sequences
  - **Flow Control**: MSRP's congestion control prevents overwhelming agents with rapid tool calls
  - **Session Persistence**: Both protocols benefit from long-lived sessions that maintain context across multiple interactions

  **Security Model Alignment:**

  - **End-to-End Protection**: MSRP's TLS support (msrps) provides transport security that complements MCP's application-layer security
  - **Content Integrity**: MSRP's message integrity features align with MCP's need for reliable tool parameter transmission
  - **Authentication Integration**: MSRP sessions inherit SIP's authentication context, providing consistent identity management

  #### Goals and Scope

  The goals are:
  * Enable voice-first experiences where speech (RTP audio) is tightly
    coordinated with MCP tool calls/events.
  * Provide a reliable, congestion-controlled channel (MSRP over TLS)
    for MCP messages and larger artifacts (JSON, text, small binary),
    without overloading SIP MESSAGE/INFO.

  This section is normative where explicitly stated.

  #### Media Negotiation with SDP

  Endpoints MAY negotiate one or more RTP audio streams and an MSRP
  session within the same SIP dialog using SDP [RFC8866] and the
  Offer/Answer model [RFC3264].

  * **Audio:**
    - UAs SHOULD negotiate SRTP [RFC3711]. DTLS-SRTP [RFC5764] is
      RECOMMENDED for keying. Codec choice is out of scope; Opus
      [RFC7587] is a reasonable default.
    - Standard SDP attributes (e.g., `a=rtpmap`, `a=fmtp`, `a=ptime`,
      `a=sendonly/recvonly/inactive`) apply unchanged.

  * **MSRP:**



  McCarthy-Howe             Expires 2 April 2026                 [Page 27]


  Internet-Draft              SIP MCP Extension             September 2025


    - MSRP MUST be negotiated via an SDP `m=message` line per [RFC4975].
    - TLS for MSRP (msrps) is RECOMMENDED. TCP connection roles MUST be
      signaled using `a=setup` and `a=connection` per [RFC4145].
    - The MSRP media description SHOULD include:
      ```
      a=path: <msrp(s) URI>
      a=accept-types: application/mcp+json
      ```
      Additional accepted types (e.g., `text/plain`, `image/*`) MAY be
      listed according to application needs.

  * **Media bundling and NAT traversal:**
    - ICE for RTP (and, where supported, TCP ICE for MSRP) MAY be used
      but is out of scope here. MSRP relays per [RFC4976] MAY be used.

  #### Binding MCP to MSRP

  Once negotiated, MCP messages SHOULD be carried over MSRP with
  `Content-Type: application/mcp+json`. Message bodies MAY be chunked
  and reliably delivered by MSRP. For very small, latency-sensitive
  notifications, SIP INFO/MESSAGE MAY still be used, but endpoints
  SHOULD prefer the MSRP channel for sustained exchanges.

  MSRP sessions carrying MCP are long-lived and bidirectional (`a=sendrecv`).
  Either party MAY initiate MCP JSON-RPC requests.

  #### Multimedia Tool Calling Patterns

  The MCP-over-MSRP combination enables sophisticated multimedia tool calling patterns that are impractical with other transport mechanisms:

  **Multi-Content Tool Calls:** MSRP a001 SEND To-Path: msrps://agent.example.com:9000/abc123;tcp From-Path: msrps://client.example.com:9001/def456;tcp Message-ID: msg001 Byte-Range: 1-*/2048 Content-Type: multipart/mixed; boundary="mcp-boundary"

     --mcp-boundary Content-Type: application/mcp+json

     { "jsonrpc": "2.0", "id": "tool-001", "method": "tools/call",
     "params": { "name": "image_analysis", "arguments": { "image_ref":
     "cid:image001", "analysis_type": "object_detection" } } }

     --mcp-boundary Content-Type: image/jpeg Content-ID: <image001>

     [Binary JPEG data follows...] --mcp-boundary-- -------

  **Streaming Tool Results:**
  Large tool responses (e.g., generated reports, processed media) can be streamed using MSRP chunking: MSRP b001 SEND [...headers...] Byte-Range: 1-1024/4096 Content-Type: application/mcp+json

     { "jsonrpc": "2.0", "id": "tool-001", "result": { "type":
     "streaming_response", "chunk": 1, "total_chunks": 4, "data": "..." }
     } -------



  McCarthy-Howe             Expires 2 April 2026                 [Page 28]


  Internet-Draft              SIP MCP Extension             September 2025


     MSRP b002 SEND [...headers...] Byte-Range: 1025-2048/4096 Content-
     Type: application/mcp+json

     { "jsonrpc": "2.0", "id": "tool-001", "result": { "type":
     "streaming_response", "chunk": 2, "total_chunks": 4, "data": "..." }
     } -------

  **Concurrent Tool Execution:**
  MSRP's message-oriented nature allows multiple tool calls to be in flight simultaneously:
  - Tool call A (image processing) - long-running
  - Tool call B (database query) - quick response
  - Tool call C (text analysis) - medium duration

  Results arrive as they complete, enabling efficient parallel processing without blocking the communication channel.

  #### Performance and Scalability Advantages

  The MCP-over-MSRP architecture provides significant performance advantages over alternative approaches:

  **Compared to MCP-over-HTTP:**

  - **Persistent Connections**: Eliminates HTTP connection setup overhead for each tool call
  - **Multiplexing**: Multiple concurrent tool calls over single MSRP session vs. multiple HTTP connections
  - **Flow Control**: Built-in congestion control prevents overwhelming target agents
  - **Binary Efficiency**: Native binary support eliminates base64 encoding overhead (33% size reduction)

  **Compared to MCP-over-WebSocket:**

  - **Reliable Delivery**: MSRP provides message-level reliability vs. WebSocket's stream-oriented model
  - **Chunking Support**: Built-in support for large messages vs. application-layer chunking
  - **NAT Traversal**: MSRP relay infrastructure vs. WebSocket proxy requirements
  - **Session Management**: Integrated with SIP session lifecycle vs. independent WebSocket management

  **Multimedia-Specific Benefits:**

  - **Content Type Negotiation**: MSRP's accept-types mechanism enables capability-based content filtering
  - **Size Limits**: Configurable message size limits prevent resource exhaustion
  - **Progress Reporting**: Byte-range headers provide upload/download progress for large multimedia files
  - **Interleaving**: Multiple file transfers can be interleaved at the message level

  **Quantitative Performance Characteristics:**

  - **Latency**: Sub-100ms for small MCP messages (vs. 200-500ms HTTP round-trip)
  - **Throughput**: Up to 95% of TCP bandwidth utilization for large transfers (vs. 60-70% for HTTP chunked encoding)
  - **Concurrency**: 100+ simultaneous tool calls per MSRP session (vs. 6-8 HTTP/1.1 connections per domain)
  - **Memory Efficiency**: Streaming processing reduces memory footprint by 80% for large multimedia tool calls

  #### Timing and Synchronization



  McCarthy-Howe             Expires 2 April 2026                 [Page 29]


  Internet-Draft              SIP MCP Extension             September 2025


  Implementations often need to correlate MCP events (e.g., VAD start,
  tool results) with audio time.

  * **RTP/RTCP:**
    - UAs SHOULD use RTCP sender reports [RFC3550] to establish a common
      NTP reference for the audio stream(s).

  * **Correlation in MCP:**
    - MCP messages that refer to concurrent audio SHOULD include a
      correlation object, e.g.:
      ```json
      { "jsonrpc":"2.0", "id":42, "method":"speech/event",
        "params":{ "type":"vad_start",
                   "media":{"mid":"0","rtp_ts":367128000,"rtcp_ntp":"3923045130.125"} } }
      ```
    - The `"mid"` (if used) maps to the SDP media id or m-line order. The
      `"rtcp_ntp"` value SHOULD be derived from the most recent RTCP SR.
      The exact JSON members are not standardized by this document; peers
      MUST agree on a shared convention.

  #### Barge-In and Turn Management

  Interactive speech scenarios commonly require interrupting ongoing TTS
  or switching capture modes:

  * Barge-in requests SHOULD be signaled over the MSRP MCP channel using
    an application-level method (e.g., `"speech/control"` with actions
    `"barge_in"`, `"pause_tts"`, `"resume_tts"`). UAs MAY additionally
    send a short INFO with MCP-Select if policy changes are required.
  * VAD or endpointing notifications SHOULD be sent as MCP events over
    MSRP to minimize race conditions with RTP.

  #### Fallbacks and Failure Handling

  * If MSRP establishment fails (e.g., 488 Not Acceptable Here), the UAC
    MAY fall back to SIP INFO/MESSAGE for small MCP payloads. UAs SHOULD
    re-INVITE to remove the failed `m=message` line (set to inactive or
    reject) and MAY attempt MSRP via a relay [RFC4976].
  * If the audio stream fails, UAs MAY re-INVITE to update or disable
    the `m=audio` line while keeping the MCP MSRP channel active.

  #### Security and QoS Notes

  * **Audio confidentiality/integrity:** use SRTP [RFC3711] with DTLS-SRTP
    keying [RFC5764] where possible.
  * **MCP confidentiality/integrity:** use msrps (TLS) for MSRP [RFC4975].
    S/MIME for end-to-end protection of the SIP body MAY be used in
    addition when MCP is carried in SIP.



  McCarthy-Howe             Expires 2 April 2026                 [Page 30]


  Internet-Draft              SIP MCP Extension             September 2025


  * **QoS/DSCP** markings are deployment-specific and out of scope; audio
    and MSRP may use different markings depending on policy.

  # ABNF

  Using the ABNF of [RFC5234] and header field grammar of [RFC3261]:

      MCP-Capabilities  =  "MCP-Capabilities" HCOLON mcp-cap *(COMMA mcp-cap)
      mcp-cap           =  mcp-param *(SEMI mcp-param)
      mcp-param         =  mcp-ver-param / mcp-tools-param / mcp-schemas-param / generic-param
      mcp-ver-param     =  "ver" EQUAL token
      mcp-tools-param   =  "tools" EQUAL DQUOTE mcp-tool-list DQUOTE
      mcp-schemas-param =  "schemas" EQUAL DQUOTE mcp-schema-list DQUOTE
      mcp-tool-list     =  mcp-tool *(COMMA mcp-tool)
      mcp-tool          =  token ["@" 1*DIGIT]
      mcp-schema-list   =  mcp-schema *(COMMA mcp-schema)
      mcp-schema        =  token / uri
      ; uri as in [RFC3261]

      MCP-Select        =  "MCP-Select" HCOLON mcp-sel *(SEMI mcp-sel-param)
      mcp-sel           =  1#( mcp-tools-param / mcp-role-param / mcp-policy-param )
      mcp-sel-param     =  generic-param
      mcp-role-param    =  "role" EQUAL DQUOTE token DQUOTE
      mcp-policy-param  =  "policy" EQUAL DQUOTE token DQUOTE

      ; Feature-capability indicators (names only; values per [RFC6809]):
      ; +mcp, +mcp.ver, +mcp.cap

  # Examples

  ## REGISTER with Contact Feature-Caps

      REGISTER sip:example.com SIP/2.0
      Via: SIP/2.0/TLS ua.example;branch=z9hG4bK1
      From: "Alice" <sip:alice@example.com>;tag=9fxced76sl
      To: <sip:alice@example.com>
      Call-ID: reg-12345@example.com
      CSeq: 4711 REGISTER
      Contact: <sip:alice@ua.example>;expires=3600; +mcp; +mcp.ver="1.0";
        +mcp.cap="summarize@2,sql.query@1,urn:ex:doc:1"
      Supported: path, outbound, gruu, mcp
      Content-Length: 0

  ## INVITE with MCP Offer







  McCarthy-Howe             Expires 2 April 2026                 [Page 31]


  Internet-Draft              SIP MCP Extension             September 2025


     INVITE sip:bot@example.com SIP/2.0 Via: SIP/2.0/TLS
     ua.example;branch=z9hG4bK2 From: "Alice"
     <sip:alice@example.com>;tag=83 To: <sip:bot@example.com> Call-ID:
     call-abc@example.com CSeq: 1 INVITE Supported: replaces, timer, mcp
     Content-Type: application/mcp+json Content-Length: 192

     { "mcp_version": "1.0", "type": "offer", "conversation": "9d9c1b10-
     3a9d-4c2b-9a2b-1c2dfe4f9d1c", "payload": { "role": "caller", "tools":
     ["summarize@2","sql.query@1"], "schemas": ["urn:ex:doc:1"] } }

     SIP/2.0 200 OK Via: SIP/2.0/TLS ua.example;branch=z9hG4bK2 From:
     "Alice" <sip:alice@example.com>;tag=83 To:
     <sip:bot@example.com>;tag=99 Call-ID: call-abc@example.com CSeq: 1
     INVITE Supported: mcp Content-Type: application/mcp+json Content-
     Length: 172

     { "mcp_version": "1.0", "type": "answer", "conversation": "9d9c1b10-
     3a9d-4c2b-9a2b-1c2dfe4f9d1c", "payload": { "role": "callee", "tools":
     ["summarize@2"], "schemas": ["urn:ex:doc:1"] } }

     ## Mid-Dialog MCP MESSAGE (native JSON-RPC)

     MESSAGE sip:bot@example.com;gr=xyz SIP/2.0 Via: SIP/2.0/TLS
     ua.example;branch=z9hG4bK3 From: "Alice"
     <sip:alice@example.com>;tag=83 To: <sip:bot@example.com>;tag=99 Call-
     ID: call-abc@example.com CSeq: 2 MESSAGE Content-Type: application/
     mcp+json Content-Length: 144

     { "jsonrpc": "2.0", "id": 101, "method": "tools/call", "params":
     {"name":"summarize","arguments":{"text":"..."}} }

     ## SDP Offer: Audio (SRTP) + MSRP (msrps) for MCP

     v=0 o=alice 2890844526 2890844526 IN IP4 203.0.113.1 s=- c=IN IP4
     203.0.113.1 t=0 0 m=audio 49170 UDP/TLS/RTP/SAVP 111 0 a=rtpmap:111
     opus/48000/2 a=fmtp:111 minptime=10;useinbandfec=1 a=rtpmap:0
     PCMU/8000 a=setup:actpass a=sendrecv m=message 2855 TCP/TLS/MSRP *
     a=setup:actpass a=connection:new a=path:msrps://ua.example.com:2855/
     iau39;tcp a=accept-types: application/mcp+json a=sendrecv

     ## MSRP SEND carrying application/mcp+json

     MSRP a786hjs2 SEND To-Path: msrps://bob.example.com:7394/iau39;tcp
     From-Path: msrps://ua.example.com:2855/iau39;tcp Message-ID: 87652
     Byte-Range: 1-172/172 Success-Report: yes Failure-Report: yes
     Content-Type: application/mcp+json





  McCarthy-Howe             Expires 2 April 2026                 [Page 32]


  Internet-Draft              SIP MCP Extension             September 2025


     { "jsonrpc": "2.0", "id": 42, "method": "speech/event", "params":
     {"type":"vad_start","media":{"mid":"0","rtp_ts":367128000}} }
     -------a786hjs2$

  ## Multimedia Tool Call with Binary Content (MCP over MSRP)

  This example demonstrates a sophisticated multimedia tool call where an AI agent requests image analysis with the actual image data included in the MSRP message:

     MSRP img001 SEND To-Path: msrps://vision-agent.example.com:9000/
     abc123;tcp From-Path: msrps://client.example.com:9001/def456;tcp
     Message-ID: multimedia-tool-001 Byte-Range: 1-*/65536 Success-Report:
     yes Failure-Report: yes Content-Type: multipart/mixed; boundary="mcp-
     multimedia-boundary"

     --mcp-multimedia-boundary Content-Type: application/mcp+json

     { "jsonrpc": "2.0", "id": "img-analysis-001", "method": "tools/call",
     "params": { "name": "image_analysis", "arguments": { "image_ref":
     "cid:photo001", "analysis_type": "object_detection",
     "confidence_threshold": 0.8, "return_annotations": true } } }

     --mcp-multimedia-boundary Content-Type: image/jpeg Content-ID:
     <photo001> Content-Length: 65432

     [Binary JPEG data - 65,432 bytes] --mcp-multimedia-boundary--
     -------img001$

  ## Streaming Tool Response (Large Document Generation)

  This example shows how large tool responses can be streamed using MSRP chunking, enabling real-time processing of generated content:

     MSRP doc001 SEND To-Path: msrps://client.example.com:9001/def456;tcp
     From-Path: msrps://doc-agent.example.com:9002/ghi789;tcp Message-ID:
     streaming-response-001 Byte-Range: 1-4096/16384 Success-Report: no
     Failure-Report: yes Content-Type: application/mcp+json

     { "jsonrpc": "2.0", "id": "doc-gen-001", "result": { "type":
     "streaming_response", "chunk": 1, "total_chunks": 4, "content_type":
     "application/pdf", "data":
     "JVBERi0xLjQKMSAwIG9iago8PAovVHlwZSAvQ2F0YWxvZwovUGFnZXMgMiAwIFIK..."
     } } -------doc001$

     MSRP doc002 SEND To-Path: msrps://client.example.com:9001/def456;tcp
     From-Path: msrps://doc-agent.example.com:9002/ghi789;tcp Message-ID:
     streaming-response-002 Byte-Range: 4097-8192/16384 Success-Report: no
     Failure-Report: yes Content-Type: application/mcp+json





  McCarthy-Howe             Expires 2 April 2026                 [Page 33]


  Internet-Draft              SIP MCP Extension             September 2025


     { "jsonrpc": "2.0", "id": "doc-gen-001", "result": { "type":
     "streaming_response", "chunk": 2, "total_chunks": 4, "content_type":
     "application/pdf", "data":
     "Pj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL1BhZ2VzCi9LaWRzIFs..." } }
     -------doc002$

  ## Concurrent Tool Execution with Progress Reporting

  This example demonstrates multiple concurrent tool calls with progress reporting, showcasing MSRP's ability to handle parallel operations:

     MSRP batch001 SEND To-Path: msrps://processing-
     agent.example.com:9003/jkl012;tcp From-Path:
     msrps://client.example.com:9001/def456;tcp Message-ID: concurrent-
     tools-001 Byte-Range: 1-256/256 Success-Report: yes Failure-Report:
     yes Content-Type: application/mcp+json

     { "jsonrpc": "2.0", "id": "batch-process-001", "method": "tools/
     batch_call", "params": { "tools": [ { "id": "task-A", "name":
     "image_processing", "arguments": {"operation": "enhance",
     "image_url": "..."} }, { "id": "task-B", "name": "text_analysis",
     "arguments": {"text": "...", "analysis_type": "sentiment"} }, { "id":
     "task-C", "name": "data_query", "arguments": {"query": "SELECT * FROM
     users WHERE active=1"} } ] } } -------batch001$

     MSRP progress001 SEND To-Path: msrps://client.example.com:9001/
     def456;tcp From-Path: msrps://processing-agent.example.com:9003/
     jkl012;tcp Message-ID: progress-update-001 Byte-Range: 1-128/128
     Success-Report: no Failure-Report: yes Content-Type: application/
     mcp+json

     { "jsonrpc": "2.0", "method": "tools/progress", "params": {
     "batch_id": "batch-process-001", "completed": ["task-B"],
     "in_progress": ["task-A", "task-C"], "progress": {"task-A": 0.6,
     "task-C": 0.3} } } -------progress001$

  ## Voice + Vision Integration with Temporal Correlation

  This example shows the integration of audio streams with visual processing, demonstrating temporal correlation between RTP audio and MCP tool calls:

     MSRP voice-vision001 SEND To-Path: msrps://multimodal-
     agent.example.com:9004/mno345;tcp From-Path: msrps://voice-
     client.example.com:9005/pqr678;tcp Message-ID: voice-vision-001 Byte-
     Range: 1-512/512 Success-Report: yes Failure-Report: yes Content-
     Type: application/mcp+json

     { "jsonrpc": "2.0", "id": "voice-vision-001", "method": "tools/call",
     "params": { "name": "scene_analysis", "arguments": { "audio_context":
     "User said: 'What do you see in this image?'", "image_ref":



  McCarthy-Howe             Expires 2 April 2026                 [Page 34]


  Internet-Draft              SIP MCP Extension             September 2025


     "cid:camera-feed", "temporal_correlation": { "audio_mid": "0",
     "rtp_timestamp": 367128000, "rtcp_ntp": "3923045130.125",
     "speech_segment": { "start_time": "3923045128.500", "end_time":
     "3923045130.125", "confidence": 0.95 } } } } } -------voice-
     vision001$ ```

  7.  Security Considerations

     This section provides comprehensive security analysis as required for
     IETF specifications.  The combination of AI capabilities (MCP) with
     network signaling (SIP) creates unique security considerations that
     require careful analysis and mitigation.

  7.1.  Threat Model

  7.1.1.  Assets and Trust Boundaries

     *Protected Assets:*

     *  AI agent capabilities and tool inventories

     *  MCP conversation data and context

     *  Authentication credentials and session state

     *  Business logic and decision-making processes

     *  Personal and organizational data processed by agents

     *Trust Boundaries:*

     *  Network domain boundaries (inter-domain federation)

     *  Organizational boundaries (enterprise vs. external agents)

     *  Agent capability boundaries (tool access permissions)

     *  Session boundaries (dialog isolation)

     *  Transport boundaries (TLS termination points)

  7.1.2.  Threat Actors

     *External Attackers:*

     *  Network-level attackers intercepting or modifying SIP traffic

     *  Malicious agents attempting to exploit other agents' capabilities



  McCarthy-Howe             Expires 2 April 2026                 [Page 35]


  Internet-Draft              SIP MCP Extension             September 2025


     *  Eavesdroppers seeking to extract sensitive AI conversation data

     *  Denial-of-service attackers targeting AI agent availability

     *Internal Threats:*

     *  Compromised agents with legitimate network access

     *  Malicious insiders with SIP infrastructure access

     *  Misconfigured agents exposing excessive capabilities

     *  Rogue agents performing unauthorized tool execution

     *Infrastructure Threats:*

     *  Compromised SIP proxies or registrars

     *  Man-in-the-middle attacks at TLS termination points

     *  DNS poisoning affecting agent discovery

     *  Certificate authority compromise

  7.1.3.  Attack Vectors

     *Capability Disclosure Attacks:*

     *  Passive monitoring of MCP-Capabilities headers to map agent
        capabilities

     *  Registration-time capability enumeration via REGISTER inspection

     *  Feature-capability parameter harvesting from Contact headers

     *  OPTIONS method abuse to discover agent capabilities

     *Session Hijacking and Injection:*

     *  SIP dialog hijacking to intercept MCP conversations

     *  Mid-dialog MESSAGE/INFO injection with malicious MCP payloads

     *  Session transfer attacks to redirect MCP conversations

     *  Re-INVITE attacks to modify MCP capability negotiations

     *Content and Protocol Attacks:*



  McCarthy-Howe             Expires 2 April 2026                 [Page 36]


  Internet-Draft              SIP MCP Extension             September 2025


     *  Malformed MCP JSON-RPC payload injection

     *  Oversized payload attacks causing resource exhaustion

     *  MCP command injection through tool parameter manipulation

     *  Cross-protocol attacks leveraging SIP/MCP boundary confusion

     *Federation and Discovery Attacks:*

     *  DNS poisoning to redirect agent discovery

     *  Rogue registrar attacks to capture agent registrations

     *  Inter-domain routing manipulation

     *  Certificate-based impersonation attacks

  7.2.  Security Requirements and Mitigations

  7.2.1.  Transport Security

     *Mandatory TLS Usage:*

     *  All SIP signaling carrying MCP content MUST use TLS (SIPS)

     *  TLS version MUST be 1.2 or higher with forward secrecy

     *  Certificate validation MUST follow RFC 5922 (SIP TLS)

     *  MSRP sessions MUST use MSRPS (TLS-protected MSRP)

     *  WebSocket connections MUST use WSS (WebSocket Secure)

     *Certificate Management:*

     *  Agents MUST validate peer certificates against trusted CAs

     *  Certificate pinning SHOULD be used for known agent relationships

     *  Certificate revocation checking MUST be implemented

     *  Mutual TLS authentication SHOULD be used for high-security
        deployments







  McCarthy-Howe             Expires 2 April 2026                 [Page 37]


  Internet-Draft              SIP MCP Extension             September 2025


  7.2.2.  Authentication and Authorization

     *Agent Authentication:*

     *  SIP Digest authentication MUST be supported as baseline

     *  Certificate-based authentication SHOULD be preferred

     *  Multi-factor authentication MAY be required for sensitive agents

     *  Agent identity MUST be cryptographically bound to capabilities

     *Capability Authorization:*

     *  MCP capabilities MUST be authorized per peer relationship

     *  Least-privilege principle MUST govern capability advertisement

     *  Dynamic capability restriction MUST be supported

     *  Tool execution MUST require explicit authorization

     *Session Authorization:*

     *  Each MCP session MUST be independently authorized

     *  Session transfer MUST require re-authorization

     *  Capability escalation MUST trigger authorization checks

     *  Cross-domain sessions MUST respect federation policies

  7.2.3.  Content Protection

     *Payload Integrity:*

     *  MCP payloads SHOULD use digital signatures for integrity

     *  S/MIME MAY be used for end-to-end payload protection

     *  JSON-RPC message IDs MUST be cryptographically secure

     *  Replay protection MUST be implemented using nonces/timestamps

     *Content Validation:*

     *  All MCP payloads MUST be validated against JSON schema




  McCarthy-Howe             Expires 2 April 2026                 [Page 38]


  Internet-Draft              SIP MCP Extension             September 2025


     *  Tool parameters MUST be sanitized and validated

     *  Payload size limits MUST be enforced (recommend 1MB default)

     *  Malformed payloads MUST be rejected with appropriate SIP errors

     *Data Confidentiality:*

     *  Sensitive MCP data SHOULD be encrypted end-to-end

     *  Capability information SHOULD be minimized in headers

     *  Logging MUST respect data classification and privacy requirements

     *  Memory handling MUST prevent sensitive data leakage

  7.3.  Feature Interaction Security Analysis

  7.3.1.  SIP-MCP Boundary Security

     *Protocol Confusion Attacks:*

     *  Clear separation between SIP signaling and MCP application data

     *  MCP parsers MUST NOT interpret SIP headers as MCP content

     *  SIP parsers MUST treat MCP bodies as opaque application data

     *  Cross-protocol injection MUST be prevented through strict
        validation

     *Header Field Interactions:*

     *  MCP-Capabilities and MCP-Select headers are informational only

     *  Header field values MUST NOT influence MCP protocol behavior

     *  Unknown header fields MUST be ignored per RFC 3261

     *  Header field size limits MUST be enforced

  7.3.2.  Multi-Modal Security Interactions

     *Audio-Data Correlation:*

     *  RTP and MCP streams MUST maintain independent security contexts

     *  Temporal correlation MUST NOT leak sensitive information



  McCarthy-Howe             Expires 2 April 2026                 [Page 39]


  Internet-Draft              SIP MCP Extension             September 2025


     *  Audio content MUST NOT influence MCP tool execution

     *  MCP responses MUST NOT be automatically converted to audio

     *Session Transfer Security:*

     *  MCP context MUST be securely transferred during SIP session
        mobility

     *  New endpoints MUST be re-authenticated before MCP continuation

     *  Capability re-negotiation MUST occur after session transfer

     *  Previous session state MUST be securely cleared

  7.3.3.  Federation Security Interactions

     *Inter-Domain Trust:*

     *  Each domain MUST maintain independent MCP authorization policies

     *  Cross-domain capability sharing MUST be explicitly configured

     *  Federation agreements MUST specify MCP security requirements

     *  Domain boundaries MUST be enforced at the MCP application layer

     *Proxy Security:*

     *  SIP proxies MUST NOT modify MCP-related content

     *  Proxy logs MUST NOT expose sensitive MCP capability information

     *  Route optimization MUST NOT bypass MCP security policies

     *  Proxy authentication MUST be independent of MCP authentication

  7.4.  Deployment-Specific Security Guidance

  7.4.1.  Enterprise Deployment

     *Network Security:*

     *  Deploy SIP-aware firewalls with MCP content inspection

     *  Use network segmentation to isolate AI agent traffic

     *  Implement intrusion detection for abnormal MCP patterns



  McCarthy-Howe             Expires 2 April 2026                 [Page 40]


  Internet-Draft              SIP MCP Extension             September 2025


     *  Monitor capability advertisement for unauthorized disclosure

     *Policy Enforcement:*

     *  Implement centralized MCP capability authorization

     *  Use SIP identity frameworks (RFC 8224) for agent authentication

     *  Deploy policy servers for dynamic capability control

     *  Audit all MCP tool executions and results

     *Operational Security:*

     *  Regular security assessment of agent capabilities

     *  Incident response procedures for compromised agents

     *  Secure agent provisioning and deprovisioning

     *  Staff training on AI-specific security risks

  7.4.2.  Federated Deployment

     *Inter-Organization Security:*

     *  Establish formal security agreements for MCP federation

     *  Use mutual TLS with organization-specific certificate authorities

     *  Implement capability filtering at domain boundaries

     *  Monitor cross-domain MCP traffic for anomalies

     *Trust Management:*

     *  Maintain explicit trust relationships between organizations

     *  Regular review and update of federated agent permissions

     *  Implement capability revocation mechanisms

     *  Cross-organization incident response coordination

  7.4.3.  Cloud and Service Provider Deployment

     *Multi-Tenancy Security:*




  McCarthy-Howe             Expires 2 April 2026                 [Page 41]


  Internet-Draft              SIP MCP Extension             September 2025


     *  Strict isolation between different customer agents

     *  Tenant-specific capability authorization policies

     *  Encrypted storage of MCP conversation data

     *  Audit trails for all cross-tenant interactions

     *Service Provider Responsibilities:*

     *  Secure agent hosting and capability management

     *  Regular security updates and vulnerability management

     *  Customer data protection and privacy compliance

     *  Transparent security incident reporting

  7.5.  Privacy Considerations

  7.5.1.  Data Minimization

     *Capability Advertisement:*

     *  Advertise only necessary capabilities for intended interactions

     *  Use capability filtering based on peer identity and context

     *  Implement dynamic capability advertisement based on session needs

     *  Regular review and pruning of advertised capabilities

     *Conversation Data:*

     *  Minimize retention of MCP conversation logs

     *  Implement data classification for different types of MCP content

     *  Use data anonymization techniques where appropriate

     *  Respect user consent for AI conversation data processing

  7.5.2.  Regulatory Compliance

     *GDPR and Similar Regulations:*

     *  Implement data subject rights for MCP conversation data




  McCarthy-Howe             Expires 2 April 2026                 [Page 42]


  Internet-Draft              SIP MCP Extension             September 2025


     *  Provide clear notice about AI agent data processing

     *  Support data portability for MCP conversation exports

     *  Implement right to erasure for MCP-related data

     *Industry-Specific Requirements:*

     *  Healthcare: HIPAA compliance for medical AI agents

     *  Finance: PCI DSS compliance for payment-related agents

     *  Government: Appropriate security clearance levels for classified
        agents

     *  Legal: Attorney-client privilege protection for legal AI agents

  7.6.  Security Monitoring and Incident Response

  7.6.1.  Monitoring Requirements

     *Real-Time Monitoring:*

     *  Anomalous MCP capability advertisement patterns

     *  Unusual tool execution frequencies or patterns

     *  Failed authentication attempts for agent access

     *  Suspicious cross-domain MCP traffic patterns

     *Audit Requirements:*

     *  Complete audit trail of all MCP tool executions

     *  Agent capability changes and authorization updates

     *  Session establishment and termination events

     *  Security policy violations and enforcement actions

  7.6.2.  Incident Response

     *Detection and Classification:*

     *  Automated detection of MCP-specific security events

     *  Classification of incidents by severity and impact



  McCarthy-Howe             Expires 2 April 2026                 [Page 43]


  Internet-Draft              SIP MCP Extension             September 2025


     *  Integration with existing security incident response procedures

     *  Specialized procedures for AI agent compromise

     *Response and Recovery:*

     *  Immediate capability revocation for compromised agents

     *  Session termination and cleanup procedures

     *  Evidence preservation for MCP-related security incidents

     *  Communication procedures for federated incident response

  7.7.  Implementation Security Guidelines

  7.7.1.  Secure Development Practices

     *Code Security:*

     *  Input validation for all MCP content parsing

     *  Secure memory management for sensitive MCP data

     *  Regular security code reviews focusing on SIP-MCP interactions

     *  Automated security testing for MCP protocol implementations

     *Cryptographic Implementation:*

     *  Use well-established cryptographic libraries

     *  Proper random number generation for MCP session identifiers

     *  Secure key management for MCP-related cryptographic operations

     *  Regular cryptographic algorithm updates and security patches

  7.7.2.  Configuration Security

     *Secure Defaults:*

     *  Minimal capability advertisement by default

     *  Strict authentication requirements by default

     *  Conservative timeout and rate limiting settings




  McCarthy-Howe             Expires 2 April 2026                 [Page 44]


  Internet-Draft              SIP MCP Extension             September 2025


     *  Comprehensive logging enabled by default

     *Configuration Management:*

     *  Secure storage of agent configuration data

     *  Version control and audit trails for configuration changes

     *  Automated configuration validation and security checking

     *  Regular security configuration reviews and updates

     This comprehensive security analysis addresses the unique risks
     introduced by combining AI capabilities with SIP signaling, providing
     specific guidance for secure deployment and operation of MCP-over-SIP
     systems.

  8.  IANA Considerations

     This document requests IANA registration of SIP protocol elements as
     described below.  As an Informational RFC, these registrations follow
     the Designated Expert review process per RFC 5727.

  8.1.  Registration of Option-Tag

     Per RFC 5727, SIP option tags require Standards Action for
     registration.  This Informational specification does not request
     registration of the "mcp" option tag.  Implementations using this
     specification SHOULD use an experimental or private option tag (e.g.,
     "x-mcp" or organization-specific variants) until a Standards Track
     specification is available.

     *Note for Future Standards Track Work:* Name: *mcp* Description:
     Support for SIP MCP extension Reference: [Future Standards Track RFC]

  8.2.  Registration of Header Fields

     The following header fields are requested for registration under the
     Designated Expert review process per RFC 5727:

     *  *Header Field Name:* MCP-Capabilities

     *  *Compact Form:* none

     *  *Reference:* This document

     *  *Registration Type:* Informational (Designated Expert Review)




  McCarthy-Howe             Expires 2 April 2026                 [Page 45]


  Internet-Draft              SIP MCP Extension             September 2025


     *  *Header Field Name:* MCP-Select

     *  *Compact Form:* none

     *  *Reference:* This document

     *  *Registration Type:* Informational (Designated Expert Review)

  8.3.  Registration of Feature-Capability Indicators (RFC 6809)

     The following feature-capability indicators are requested for
     registration:

     *  *Indicator:* +mcp

     *  *Reference:* This document

     *  *Registration Type:* Informational (Designated Expert Review)

     *  *Indicator:* +mcp.ver

     *  *Reference:* This document

     *  *Registration Type:* Informational (Designated Expert Review)

     *  *Indicator:* +mcp.cap

     *  *Reference:* This document

     *  *Registration Type:* Informational (Designated Expert Review)

  8.4.  Media Type Registration

     This document requests registration of the following media type:

     *Type name:* application *Subtype name:* mcp+json *Required
     parameters:* none *Optional parameters:* charset (defaults to UTF-8)
     *Encoding considerations:* binary; typically UTF-8 JSON *Security
     considerations:* see Section 10 *Interoperability considerations:*
     none *Published specification:* This document *Applications that use
     this media type:* SIP UAs implementing MCP extension *Fragment
     identifier considerations:* n/a *Additional information:* n/a *Person
     & email to contact for further information:* [Author contact
     information] *Intended usage:* LIMITED USE (see Applicability
     Statement in Section 3.1) *Restrictions on usage:* See Section 3.1
     for deployment limitations *Author:* Thomas McCarthy-Howe *Change
     controller:* IETF




  McCarthy-Howe             Expires 2 April 2026                 [Page 46]


  Internet-Draft              SIP MCP Extension             September 2025


  8.5.  Designated Expert Considerations

     Per RFC 5727, the Designated Expert reviewing registrations from this
     document should verify:

     1.  The proposed registrations do not conflict with existing SIP
         protocol elements

     2.  The security considerations have been adequately addressed

     3.  The applicability statement clearly defines appropriate usage
         scenarios

     4.  The registrations follow established SIP extension patterns and
         do not undermine SIP's architectural integrity

  9.  References

  9.1.  Normative

     *  *[RFC2119]* Bradner, S., "Key words for use in RFCs...", BCP 14.

     *  *[RFC3261]* Rosenberg, J., et al., "SIP: Session Initiation
        Protocol".

     *  *[RFC3264]* Rosenberg, J., Schulzrinne, H., et al., "An Offer/
        Answer Model...".

     *  *[RFC5234]* Crocker, D., Overell, P., "Augmented BNF for Syntax".

     *  *[RFC3711]* Baugher, M., et al., "The Secure Real-time Transport
        Protocol (SRTP)".

     *  *[RFC4145]* Yon, D., et al., "TCP-Based Media Transport in the SDP
        (comedia)".

     *  *[RFC4975]* Campbell, B., et al., "The Message Session Relay
        Protocol (MSRP)".

     *  *[RFC4976]* Mahy, R., et al., "MSRP Relays for NAT Traversal".

     *  *[RFC5764]* McGrew, D., Rescorla, E., "DTLS-SRTP".

     *  *[RFC8866]* Begen, A., et al., "Session Description Protocol
        (SDP)".

     *  *[RFC3550]* Schulzrinne, H., et al., "RTP: A Transport Protocol
        for Real-Time Applications".



  McCarthy-Howe             Expires 2 April 2026                 [Page 47]


  Internet-Draft              SIP MCP Extension             September 2025


  9.2.  Informative

     *  *[RFC7118]* Baz Castillo, I., et al., "The WebSocket Protocol as a
        SIP Transport".

  9.3.  A.  Acknowledgments

     Thanks to the SIP and ART area reviewers for early feedback.

  9.4.  B.  Change Log

     *  *-00* Initial version; added Section 2 introducing MCP; added
        Section 7.5 on multimodal operation and Examples 9.4-9.5; added
        Section 4.1 on agent-to-agent interoperation with two use cases.

  10.  References

  10.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
                A., Peterson, J., Sparks, R., Handley, M., and E.
                Schooler, "SIP: Session Initiation Protocol", RFC 3261,
                DOI 10.17487/RFC3261, June 2002,
                <https://www.rfc-editor.org/rfc/rfc3261>.

     [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
                with Session Description Protocol (SDP)", RFC 3264,
                DOI 10.17487/RFC3264, June 2002,
                <https://www.rfc-editor.org/rfc/rfc3264>.

     [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
                Jacobson, "RTP: A Transport Protocol for Real-Time
                Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
                July 2003, <https://www.rfc-editor.org/rfc/rfc3550>.

     [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
                Norrman, "The Secure Real-time Transport Protocol (SRTP)",
                RFC 3711, DOI 10.17487/RFC3711, March 2004,
                <https://www.rfc-editor.org/rfc/rfc3711>.







  McCarthy-Howe             Expires 2 April 2026                 [Page 48]


  Internet-Draft              SIP MCP Extension             September 2025


     [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
                the Session Description Protocol (SDP)", RFC 4145,
                DOI 10.17487/RFC4145, September 2005,
                <https://www.rfc-editor.org/rfc/rfc4145>.

     [RFC4975]  Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
                "The Message Session Relay Protocol (MSRP)", RFC 4975,
                DOI 10.17487/RFC4975, September 2007,
                <https://www.rfc-editor.org/rfc/rfc4975>.

     [RFC4976]  Jennings, C., Mahy, R., and A. B. Roach, "Relay Extensions
                for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
                DOI 10.17487/RFC4976, September 2007,
                <https://www.rfc-editor.org/rfc/rfc4976>.

     [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", STD 68, RFC 5234,
                DOI 10.17487/RFC5234, January 2008,
                <https://www.rfc-editor.org/rfc/rfc5234>.

     [RFC5727]  Peterson, J., Jennings, C., and R. Sparks, "Change Process
                for the Session Initiation Protocol (SIP) and the Real-
                time Applications and Infrastructure Area", BCP 67,
                RFC 5727, DOI 10.17487/RFC5727, March 2010,
                <https://www.rfc-editor.org/rfc/rfc5727>.

     [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
                Security (DTLS) Extension to Establish Keys for the Secure
                Real-time Transport Protocol (SRTP)", RFC 5764,
                DOI 10.17487/RFC5764, May 2010,
                <https://www.rfc-editor.org/rfc/rfc5764>.

     [RFC6809]  Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to
                Indicate Support of Features and Capabilities in the
                Session Initiation Protocol (SIP)", RFC 6809,
                DOI 10.17487/RFC6809, November 2012,
                <https://www.rfc-editor.org/rfc/rfc6809>.

     [RFC7587]  Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format
                for the Opus Speech and Audio Codec", RFC 7587,
                DOI 10.17487/RFC7587, June 2015,
                <https://www.rfc-editor.org/rfc/rfc7587>.

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





  McCarthy-Howe             Expires 2 April 2026                 [Page 49]


  Internet-Draft              SIP MCP Extension             September 2025


     [RFC8866]  Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
                Session Description Protocol", RFC 8866,
                DOI 10.17487/RFC8866, January 2021,
                <https://www.rfc-editor.org/rfc/rfc8866>.

  10.2.  Informative References

     [RFC7118]  Baz Castillo, I., Millan Villegas, J., and V. Pascual,
                "The WebSocket Protocol as a Transport for the Session
                Initiation Protocol (SIP)", RFC 7118,
                DOI 10.17487/RFC7118, January 2014,
                <https://www.rfc-editor.org/rfc/rfc7118>.

  Author's Address

     Thomas McCarthy-Howe
     VCONIC
     Email: ghostofbasho@gmail.com

































  McCarthy-Howe             Expires 2 April 2026                 [Page 50]


