Internet Research Task Force A. An, Ed.
Internet-Draft Korea Electronics Technology Institute
Intended status: Informational J. Jeong, Ed.
Expires: 12 December 2026 Sungkyunkwan University
B. Park
S. Jang
Korea Electronics Technology Institute
10 June 2026
Agentic Interface to In-Network Computing Functions for Software-Defined
Vehicles in Cooperative Intelligent Transportation Systems
draft-an-nmrg-i2icf-cits-02
Abstract
This document specifies a structured framework for orchestrating,
managing, and monitoring In-Network Computing Functions (ICFs) for
Software-Defined Vehicles (SDVs) in Cooperative Intelligent
Transportation Systems (C-ITS), with a first-class role given to the
Agent-to-Agent (A2A) communication paradigm. SDVs decouple vehicular
functions from underlying hardware and expose them as software-
driven, continuously updatable services; this architectural shift
makes them natural participants in an agentic control plane that
spans vehicles, roadside infrastructure, and mobile networks. AI
agents are co-located with each functional entity of the C-ITS
architecture (e.g., C-ITS Center, Government Public Center, C-ITS
Infra, Mobile Network Operator (MNO), Roadside Unit (RSU), SDV, and
Vulnerable Road User (VRU)) and interact over an A2A protocol overlay
to advertise capabilities, discover peers, negotiate resources, and
coordinate the placement and execution of ICFs across multi-domain
networks. In the context of Vehicle-to-Everything (V2X)
communications, this agentic overlay enables efficient management of
Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I)
communications and their integration with C-ITS by leveraging in-
network computing to optimize real-time communication, streamline
traffic management, and enhance data processing and security services
at the network edge. The framework aligns with ongoing IRTF NMRG
work on agentic AI and A2A applicability to network management, and
adapts these concepts to the specific operational and safety
requirements of SDV-centric C-ITS deployments.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
An, et al. Expires 12 December 2026 [Page 1]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 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 12 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Agentic I2ICF Framework and Interfaces for SDV in C-ITS . . . 5
2.1. I2ICF Framework for SDV, C-ITS, and MNO Networking . . . 6
2.2. I2ICF Interfaces . . . . . . . . . . . . . . . . . . . . 12
3. Use Cases for Agentic I2ICF in SDV and C-ITS . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. A2A Use Cases for SDV-Centric C-ITS Integration . . . . . . . 16
6. Agent Cards for SDVs and C-ITS Entities . . . . . . . . . . . 18
7. YANG-based Structured Data for A2A Communication in SDV and
C-ITS . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Operational Considerations . . . . . . . . . . . . . . . . . 28
8.1. Agent Skills as Expertise Expansion . . . . . . . . . . . 29
8.2. Knowledge Base as Ground Truth Data . . . . . . . . . . . 29
8.3. Event-driven A2A for Safety Signalling . . . . . . . . . 29
8.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 29
An, et al. Expires 12 December 2026 [Page 2]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
8.5. Latency and Performance Constraints . . . . . . . . . . . 30
8.6. Reliability and Failure Handling . . . . . . . . . . . . 30
8.7. Agent Lifecycle and Resource Management . . . . . . . . . 30
8.8. Inter-Domain Operational Challenges . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
In-network computing has recently gained significant attention and
has been extensively explored as a promising research area. This
growing interest stems from the increasing accessibility of data
plane programmability, which has opened new opportunities for both
application developers and network operators to optimize network
operations and application performance. Over the years, rigorous
research and numerous trials have validated the effectiveness of
certain in-network computing capabilities, collectively referred to
as In-Network Computing Functions (ICFs). These functions have
proven to be highly beneficial in various domains, such as machine
learning, real-time data processing, and large-scale distributed
systems. For instance, in-network aggregation techniques have been
shown to accelerate collective communication operations like
Allreduce and Broadcast, which are critical in training machine
learning models. These advancements have led to the gradual
commercialization of many in-network computing capabilities. Several
other works, such as
[I-D.jeong-nmrg-i2icf-problem-statement][I-D.yao-tsvwg-cco-problem-statement-and-usecases][I-D.irtf-coinrg-use-cases]also
provide additional use cases and scenarios for in-network computing
applications.
Despite these promising developments, a critical challenge remains:
the absence of a unified framework and standardized interfaces to
effectively register, configure, manage, and monitor ICFs. The
framework for Interface to Network Security Functions (I2NSF) defined
in [RFC8329] provides a solid foundation for managing and
orchestrating Network Security Functions (NSFs). However, these
frameworks fall short when it comes to supporting the unique
requirements of ICFs. Unlike NSFs, ICFs often require seamless
coordination between endpoint computing capabilities and in-network
nodes, such as Programmable Network Devices (PNDs), to accelerate
application performance collaboratively. This highlights the need
for a new framework that can integrate endpoint and in-network
functionalities while leveraging and adapting existing frameworks,
such as I2NSF, to define interfaces for ICFs effectively.
An, et al. Expires 12 December 2026 [Page 3]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
This document rigorously examines the applicability of ICFs within
constrained environments, particularly in data center networks, and
introduces a structured framework for their registration,
configuration, management, and monitoring. Additionally, it
evaluates extended use cases, including Vehicle-to-Everything (V2X)
communication, wherein ICFs facilitate the efficient orchestration of
vehicle-to-vehicle (V2V) networks, seamless integration with
Cooperative Intelligent Transport Systems (C-ITS), and
interoperability with Mobile Network Operators (MNOs). By leveraging
ICFs, these architectures can achieve enhanced communication
efficiency, improved traffic control, and secure data exchange.
Furthermore, this document underscores the pivotal role of ICFs in
strengthening cybersecurity measures for both private and public data
within such interconnected ecosystems, addressing the increasing
demand for resilient security mechanisms in contemporary networked
infrastructures.
A distinguishing focus of this document is the Software-Defined
Vehicle (SDV) as the primary endpoint of the I2ICF framework. In an
SDV, traditionally hardware-bound vehicular functions (perception,
planning, control, infotainment, diagnostics) are realized as
software components running on a consolidated, zonal compute platform
and are continuously updated over the air. This software-defined
nature aligns naturally with the agentic AI model: each SDV can host
one or more AI agents that expose vehicle capabilities (compute,
sensing, connectivity, safety classes) as A2A skills, negotiate ICF
placement with peer SDV, RSU, MNO, and Center agents, and dynamically
adapt to changing road, network, and mission contexts. Conversely,
the surrounding C-ITS and MNO infrastructure must evolve from static,
message-based V2X delivery toward an intent-driven, agent-mediated
control plane that can match the update cadence and behavioral
diversity of fleets of SDVs. The I2ICF framework defined here treats
SDVs as first-class agentic participants rather than passive V2X
clients.
In C-ITS, distributed agents across vehicles, Road-Side Units (RSUs),
and traffic management backends increasingly need to collaborate
directly in an _Agent-to-Agent (A2A)_ manner for capability
advertisement, peer discovery, task delegation, and state exchange.
Emerging IETF work on Artificial Intelligence (AI) agent protocols
formalizes such A2A interactions (e.g., messaging, capability
schemas, and discovery) [I-D.rosenberg-ai-protocols], while the IRTF
NMRG explores applicability of A2A to multi-domain network management
and automation [I-D.yang-nmrg-a2a-nm]. This approach provides a
standards-based application/control-plane overlay for ICFs: vehicle,
infrastructure, and cloud agents can discover and configure ICFs on
programmable network devices, coordinate V2V/V2I compute placement,
and exchange low-latency signals for admission control, safety
An, et al. Expires 12 December 2026 [Page 4]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
services, and analytics, thereby reducing end-to-end delay and
network overhead while improving interoperability and manageability
in C-ITS deployments.
The A2A paradigm itself has been actively discussed across recent
IRTF NMRG meetings (e.g., IETF 124 and IETF 125), where a body of
work on agentic AI, Large Language Model (LLM)-assisted operations,
and agent-mediated control planes for networks has emerged.
Representative directions include problem statements and motivations
for agentic AI in network management [I-D.hong-nmrg-agenticai-ps],
agentic AI architectural principles for autonomous networks
[I-D.jadoon-nmrg-agentic-ai-autonomous-networks], agentic network
architectures supporting agent interconnection and multi-level
inference [I-D.chuyi-nmrg-agentic-network-inference], agent-driven
Network Digital Twin (NDT) architectures
[I-D.wmz-nmrg-agent-ndt-arch], agentic sensing and network
optimization [I-D.bernardos-nmrg-agentic-network-optimization], and
the applicability of model and tool-access protocols such as the
Model Context Protocol (MCP) to network management
[I-D.yang-nmrg-mcp-nm]. In parallel, industry initiatives (e.g.,
Google's A2A protocol) have contributed reference patterns for agent
identity, capability cards (Agent Cards), task lifecycles, and secure
peer-to-peer messaging that can be adopted as the application-layer
substrate of an A2A overlay for C-ITS.
Building on these trends, this document positions A2A as the primary
coordination layer of the I2ICF framework for SDV-centric C-ITS.
Specifically, each major entity in the architecture (Center Cloud
agents, C-ITS Infra agent, MNO agent, RSU agent, SDV agents, and VRU
agent) hosts an AI agent that exposes standardized capability
descriptions and exchanges intent-based requests over A2A. SDV
agents in particular act as the bridge between in-vehicle software
stacks (zonal controllers, AI/ADAS workloads, IVN buses) and the
external A2A overlay, so that vehicle-side software updates and
capability changes are immediately reflected in the agent's
advertised Agent Card. The I2ICF interfaces (I1 to I10) defined in
this document are realized as A2A interactions between these agents,
while the underlying transport, security, and policy enforcement
continue to rely on existing C-ITS, V2X, and mobile network
mechanisms. This split keeps the agentic control plane aligned with
the NMRG agentic-AI direction while preserving compatibility with
deployed C-ITS, SDV, and MNO infrastructures.
2. Agentic I2ICF Framework and Interfaces for SDV in C-ITS
This section presents the detailed design of the agentic I2ICF
framework and interfaces for Software-Defined Vehicles (SDVs) in
C-ITS and MNO networking.
An, et al. Expires 12 December 2026 [Page 5]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
2.1. I2ICF Framework for SDV, C-ITS, and MNO Networking
Figure 1 shows the agentic I2ICF framework for SDV, C-ITS, and MNO
networking. In this framework, every major functional entity hosts
an AI _Agent_ that participates in an A2A overlay. SDV agents are
first-class peers of infrastructure and operator agents: they
advertise their in-vehicle software capabilities, sensing and compute
resources, supported autonomy levels, and ICF requirements through
signed Agent Cards. The A2A overlay provides capability
advertisement (e.g., Agent Cards), peer discovery, intent/task
delegation, and state exchange among agents, and is used to register,
configure, monitor, and coordinate ICFs across the architecture. The
A2A protocol runs as an application/control-plane overlay on top of
the existing I1 to I10 interfaces; wired interfaces are typically
depicted with solid links and wireless or A2A signalling with dashed
links.
* Central Cloud: A system that comprehensively controls the entire
C-ITS (Cooperative Intelligent Transport Systems) environment. It
manages information from various C-ITS centers, including regional
centers and highway centers, and facilitates and oversees the
connection between C-ITS data from the Government Public Center and
end users. Additionally, it provides security functions through an
integrated cybersecurity system. Within the Central Cloud, two
cooperating agents (a C-ITS Center Agent and a Government Public
Center Agent) participate in the A2A overlay to negotiate cross-
domain data sharing and to delegate ICF configuration requests
downward to the C-ITS Infra and MNO agents.
* C-ITS Center: The C-ITS Center is a comprehensive term that
encompasses both the Region Center and the Highway Center. It serves
as the central hub for managing and coordinating intelligent
transportation systems across various environments, including urban
regions and highways. By integrating data from Region Centers and
Highway Centers, the C-ITS Center ensures efficient traffic
management, real-time data processing, and seamless communication
between infrastructure and connected or autonomous vehicles.
* Region Center: The Region Center refers to local centers
established at key locations. These regional centers are connected
to Roadside Units (RSUs) and function as one of the C-ITS Centers.
Each regional C-ITS center collaborates with the Government Public
Center to share collected data, ensuring seamless integration and
data exchange between local infrastructure and centralized management
systems.
An, et al. Expires 12 December 2026 [Page 6]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
* Highway Center: The Highway Center operates similarly to the Region
Center but is managed separately due to the unique characteristics of
highways, which span multiple regions rather than being confined to a
single city. Given the higher traffic volume on highways compared to
regular roads, there is a significant increase in data generation,
necessitating dedicated network management for highway environments.
Highways are equipped with a greater number of RSUs than general
roads, enabling the delivery of critical information to autonomous
vehicles. As a result, the Highway Center focuses on managing areas
that require more real-time processing to support safe and efficient
autonomous driving.
* Government Public Center: The Government Public Center is a C-ITS
information provision system managed by the government. Due to the
nature of road traffic infrastructure, it is challenging for private
companies to manage this data effectively, and concerns over
reliability make it difficult for users to utilize privately managed
data. The Government Public Center ensures the delivery of highly
reliable, government-provided data to users, enabling them to
effectively utilize infrastructure-based information. It oversees
the provision and management of trustworthy data essential for safe
and efficient transportation systems.
* C-ITS Data Linkage System: The C-ITS Data Linkage System is a
platform designed to provide C-ITS data to external users. By
offering data through methods such as Open APIs, this system connects
C-ITS infrastructure information with users, enabling seamless access
to real-time traffic and transportation data. It facilitates the
integration of C-ITS data into various applications and services,
supporting the development of innovative mobility solutions and
enhancing the overall efficiency and safety of transportation
systems.
* Cyber Security System: The Cyber Security System is responsible for
managing the security of communications between Software-Defined
Vehicles (SDV), Vulnerable Road Users (VRU), RSU, Mobile Network
Operators (MNO), and C-ITS infrastructure. Security technologies are
fundamentally integrated into all communications to ensure encrypted
data transmission. Outgoing data is encrypted using a public key,
while receiving devices decrypt the data using a private key to
securely access the information. The Cyber Security System oversees
the protection of both private and public keys across all modules,
ensuring robust security against potential exposure and safeguarding
the integrity and confidentiality of transmitted data. In the A2A
overlay, the Cyber Security System provides agent identity issuance,
capability attestation, mutual authentication between agents, and
revocation/rotation of agent credentials, so that all A2A
interactions across I1 to I10 are cryptographically protected.
An, et al. Expires 12 December 2026 [Page 7]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
* C-ITS Infra: The C-ITS Infrastructure is a system designed to
collect and provide various types of information, including traffic
signal data, roadside environment information, VRU data, and RSU
data. The specific C-ITS information available may vary depending on
the devices and equipments installed on the road. This
infrastructure enables real-time data exchange between the
transportation system and connected or autonomous vehicles,
supporting safer and more efficient traffic management. A C-ITS
Infra Agent fronts this subsystem in the A2A overlay, brokering
interactions between Center Cloud agents (downstream policy and ICF
configuration) and RSU/SDV/MNO agents (upstream telemetry and
capability advertisement).
* RSU: The RSU is a device that connects the C-ITS Infrastructure
with SDVs. Through the RSU, SDVs can transmit and receive data
between vehicles via V2V and between vehicles and infrastructure via
V2I. RSUs play a critical role in enabling real-time communication,
providing essential information such as traffic signals, road
conditions, and safety alerts, thereby enhancing the safety and
efficiency of autonomous and connected vehicle operations. Each RSU
hosts a lightweight RSU Agent that participates in the A2A overlay to
publish locally available ICFs (e.g., aggregation, filtering,
perception offload), discover SDV/VRU agents within its coverage, and
accept intent-based tasks delegated by the C-ITS Infra Agent or by
neighboring SDV agents.
* SDV1 and SDV2: SDV1 and SDV2 are examples depicted in the diagram,
but in real-world scenarios, there can be an arbitrary number of
vehicles. A Software-Defined Vehicle (SDV) is a vehicle whose
functions (perception, planning, control, infotainment, diagnostics,
and connectivity) are realized as software components running on a
consolidated, zonal compute platform and are continuously updatable
over the air. An SDV exposes two main communication interfaces: an
External Communication Interface that enables communication with
external systems such as RSUs, other vehicles (V2V), and
infrastructure (V2I/V2N) for seamless interaction within the C-ITS
ecosystem; and an Internal Vehicle Network (IVN) Interface that
manages internal communication within the vehicle, connecting various
onboard systems and components to ensure smooth operation and
integration of vehicle functionalities. This dual-interface
structure allows SDVs to efficiently exchange data both externally
with the C-ITS infrastructure and internally for optimized vehicle
control. Because vehicle-side software, models, and skills evolve
continuously, an SDV's externally visible capabilities are
intentionally agentic: the SDV hosts an in-vehicle SDV Agent that
acts as the vehicle's representative in the A2A overlay, publishes a
signed Agent Card that reflects the currently installed software/
skills, autonomy level, and safety class, negotiates ICF placement
An, et al. Expires 12 December 2026 [Page 8]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
with RSU, MNO, and Center agents, and coordinates directly with other
SDV agents for cooperative perception, platooning, and safety tasks.
The SDV Agent also mediates between the IVN (zonal controllers,
sensors, actuators) and the external A2A overlay, ensuring that only
authorized, policy-bound intents reach in-vehicle subsystems.
* IVN-Network1 and IVN-Network2: IVN-Network1 and IVN-Network2 are
examples, but in practice, the internal communication system of a
vehicle can consist of N different networks. These networks are part
of the In-Vehicle Network (IVN), which facilitates communication
within the vehicle. In an SDV (Software-Defined Vehicles), the IVN
is designed based on a Zonal Architecture, where communication
interfaces connect various devices and components within specific
zones of the vehicle. This architecture improves data transmission
efficiency, reduces wiring complexity, and enhances the integration
of advanced systems for autonomous driving and vehicle control.
Through this zonal design, SDVs can effectively manage high-speed
data exchange between sensors, controllers, and actuators, supporting
real-time processing and safer driving operations.
* VRU: A VRU refers to users who can communicate either with an MNO
or directly with SDVs. VRUs typically include pedestrians, cyclists,
and motorcyclists who are more susceptible to traffic accidents due
to their limited protection. By connecting with MNO networks, VRUs
can receive real-time safety alerts and traffic information.
Additionally, direct communication with SDVs enables VRUs to exchange
critical safety data, such as location and movement intentions, which
helps autonomous and connected vehicles detect and respond to nearby
vulnerable users, ultimately enhancing road safety. A VRU Agent,
typically hosted on the VRU's personal device, participates in the
A2A overlay with a constrained capability profile, announcing
presence and intent (e.g., crossing, joining traffic) to nearby SDV
and MNO agents under privacy-preserving identifiers.
An, et al. Expires 12 December 2026 [Page 9]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
* MNO: An MNO is a service provider that owns and manages wireless
communication infrastructure, including network towers, core
networks, and data centers. In the context of C-ITS, MNOs play a
critical role in enabling real-time communication between vehicles,
infrastructure, and VRUs by providing seamless connectivity through
cellular networks (e.g., LTE, and 5G). MNOs facilitate the
transmission of safety messages, traffic updates, and vehicle data,
ensuring low-latency, high-reliability communication essential for
autonomous driving and connected vehicle ecosystems. Additionally,
MNOs collaborate with C-ITS infrastructure to enhance data security
and manage network resources for efficient traffic management and
mobility services. The MNO hosts an MNO Agent that exposes network-
side capabilities (e.g., slice selection, QoS modulation, edge
compute placement) over A2A, so that SDV, VRU, and Center agents can
request connectivity and ICF execution in an intent-based, cross-
domain manner.
An, et al. Expires 12 December 2026 [Page 10]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
Center Cloud
********************************************************************
* *
* +------------------+-----+ +-----+---------------------+ *
* | C-ITS Center | | | | Government Public | *
* |------------------| | I1 | | Center | *
* | Region Center |Agent+<....>+Agent|---------------------| *
* |------------------| | | | C-ITS Data Linkage | *
* | Highway Center | | | |---------------------| *
* | | | | | Cyber Security Sys | *
* +------------------+--+--+ +--+--+---------------------+ *
* ^ ^ *
**************************:************:****************************
: I2 : I3
v v
+------------+----+ +-+------------------------+
| Agent | | Agent |
|-----------------|I4 |--------------------------|
I7 +...>| C-ITS Infra |<...>| MNO |
: +--------+--------+ +----------------+---------+
: ^ ^ ^
: : I5 I6 : I6 :
: : : :
v v v v
+-----+-----+ I8 +-+--------------++ I9 +-----+---+-+
| RSU |Agent|<...>| Agent |<...>|Agent| VRU |
+-----+-----+ |-----------------| +-----+-----+
| SDV1 |
| IVN-Network1 |
+-------+---------+
^
: I10
:
v
+-----+-------+
| Agent |
|-------------|
| SDV2 |
| IVN-Network2|
+-------------+
<...> A2A Protocol
Figure 1: Agentic I2ICF Framework and Interfaces
An, et al. Expires 12 December 2026 [Page 11]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
2.2. I2ICF Interfaces
According to the framework described in the previous section, there
are major interfaces that I2ICF of C-ITS and MNO networking should
define. Each interface listed below is realized as an A2A
interaction between the two corresponding agents: the two agents
authenticate each other using credentials issued by the Cyber
Security System, exchange Agent Cards to learn each other's ICF-
related capabilities, and then use intent-based request/response or
publish/subscribe messages to register, configure, monitor, or invoke
ICFs. The interface descriptions below therefore cover both the
underlying data exchange and the A2A semantics layered on top.
Interface 1 (I1): This is the registration interface between the
C-ITS Center and the Government Public Center. It facilitates the
exchange of C-ITS infrastructure data, such as traffic information
and real-time road conditions, ensuring the Government Public Center
can provide accurate and trustworthy data to external users. This
interface also supports secure data sharing through standardized
protocols and encryption.
Interface 2 (I2): This interface connects the C-ITS Center with the
C-ITS Infra. It is responsible for distributing infrastructure data,
such as traffic signal information, road environment data, and RSU
status, from the C-ITS Center to the C-ITS Infra for real-time
processing and delivery to connected vehicles. It ensures continuous
data flow for effective traffic and infrastructure management.
Interface 3 (I3): This is the data exchange interface between the
Government Public Center and the MNO (Mobile Network Operator). It
enables the secure transmission of C-ITS data to MNOs, allowing
mobile networks to deliver critical traffic and safety information to
VRUs and vehicles. This interface must ensure data integrity and
security during transmission.
Interface 4 (I4): This interface connects the C-ITS Infra with the
MNO. It supports the sharing of network resources and real-time
communication between infrastructure components and mobile networks.
This connection allows for efficient distribution of data, such as
traffic alerts and safety notifications, to mobile users and
vehicles.
Interface 5 (I5): This is the communication interface between the
C-ITS Infra and SDVs. It enables bidirectional data exchange,
allowing SDVs to receive real-time infrastructure information (e.g.,
traffic signals, road hazards) and transmit vehicle status data back
to the infrastructure. This interface is critical for supporting V2I
communications.
An, et al. Expires 12 December 2026 [Page 12]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
Interface 6 (I6): This interface connects the MNO with both VRUs and
SDVs. It is used to deliver real-time safety messages, navigation
updates, and other critical data. It also allows VRUs and SDVs to
send status or emergency signals back to the network. This interface
must ensure low-latency and secure data transmission to prevent
accidents and improve traffic efficiency
Interface 7 (I7): This is the management interface between the RSU
and the C-ITS Infra. It facilitates the configuration, monitoring,
and management of RSUs to ensure stable communication between
roadside infrastructure and vehicles. It also handles firmware
updates and diagnostics for RSUs.
Interface 8 (I8): This interface supports V2I communication between
SDVs through the RSU. It allows SDVs to exchange critical
information such as speed, direction, and emergency signals, enabling
collision avoidance and cooperative driving. This interface must
provide real-time and reliable data exchange in dynamic traffic
environments.
Interface 9 (I9): This is the communication interface between SDVs
and VRUs. It ensures that vulnerable road users receive immediate
safety notifications from nearby vehicles and infrastructure. For
example, SDVs can warn pedestrians of approaching vehicles or detect
VRU movements in blind spots, enhancing road safety.
Interface 10 (I10): This is the external and internal communication
interface between multiple SDVs It enables secure and efficient
communication within the vehicle's zonal architecture, facilitating
seamless data exchange between various internal systems (e.g.,
sensors, controllers) and supporting autonomous driving functions.
3. Use Cases for Agentic I2ICF in SDV and C-ITS
This section introduces practical use cases of the agentic I2ICF
framework in the context of Software-Defined Vehicles (SDVs), C-ITS,
and MNO networking. These use cases focus on how the software-
defined and continuously updatable nature of SDVs, combined with the
A2A overlay, enables End-to-End (E2E) communication, cybersecurity,
and cooperative driving services that adapt to vehicle, road, and
network context in real time.
* Real-Time Data Processing for SDV: The I2ICF framework enables
seamless communication between SDVs and C-ITS infrastructure through
interfaces such as I5 (C-ITS Infra <-> SDV) and I8 (V2V Communication
via RSU). Real-time data such as traffic signals, road conditions,
and obstacle detection are transmitted to SDVs for immediate
processing. By offloading certain data processing tasks to network
An, et al. Expires 12 December 2026 [Page 13]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
devices (e.g., RSUs), SDVs can reduce internal computational load,
allowing faster decision-making for functions like emergency braking
or lane changes. This distributed data processing model improves the
overall safety and efficiency of autonomous driving.
* E2E Communication for Cooperative Driving: The integration of MNO
networks with C-ITS through interfaces like I4 (C-ITS Infra <-> MNO)
and I6 (MNO <-> VRU/SDV) allows for reliable and low-latency E2E
communication. This connectivity is essential for cooperative
driving scenarios, where multiple SDVs coordinate lane changes,
merging, or platooning in real time. The I2ICF framework ensures
that the network can dynamically manage traffic loads and prioritize
safety-critical data transmission, enabling vehicles to share and act
on real-time information seamlessly.
* Enhanced Cybersecurity for C-ITS and MNO Integration: Given the
extensive data exchange between vehicles, infrastructure, and network
operators, cybersecurity is a critical component. The Cyber Security
System within the I2ICF framework, managed through interfaces like I3
(Government Public Center <-> MNO) and I10 (Internal SDV
Communication), provides E2E encryption and secure key management.
Private keys are stored securely in the cloud and can be updated via
Over-The-Air (OTA) mechanisms if compromised. If a critical security
breach occurs, the system can initiate a global reset to reissue
encryption keys, ensuring system-wide security integrity. This
proactive approach minimizes the risk of cyberattacks on connected
vehicles and infrastructure.
* Dynamic Resource Allocation for High-Density Traffic Environments:
In high-traffic conditions such as highways or urban intersections,
efficient data management is crucial. The I2ICF framework, through
I7 (RSU <-> C-ITS Infra) and I9 (SDV <-> VRU), enables dynamic
resource allocation. For example, RSUs can prioritize data
transmission for emergency vehicles or redirect network resources to
manage traffic congestion. This adaptive data flow management
reduces latency and prevents network bottlenecks, ensuring that all
vehicles and infrastructure components receive critical information
in real time.
An, et al. Expires 12 December 2026 [Page 14]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
* Edge Computing for Latency-Sensitive Applications: Edge computing
capabilities are integrated into the I2ICF framework using RSUs and
Programmable Network Devices (PNDs) to handle latency-sensitive
tasks. Interfaces like I1 (C-ITS Center <-> Government Public
Center) and I8 (SDV <-> SDV via RSU) allow certain computational
tasks such as object detection or predictive path planning to be
processed at the network edge rather than relying on centralized
cloud servers. This significantly reduces response time for
autonomous driving actions and enhances road safety by enabling
faster vehicle reactions.
* These use cases demonstrate how the I2ICF framework can enhance the
performance, security, and reliability of intelligent transportation
systems by integrating C-ITS infrastructure with MNO networks. By
supporting real-time data processing, secure communication, and
dynamic resource management, the framework addresses the complex
demands of modern SDVs and connected mobility solutions.
4. Security Considerations
The I2ICF framework for C-ITS and MNO Networking offers numerous
advantages for various applications. However, due to the framework's
extensive connectivity between diverse vehicles, devices, centers,
clouds, and VRUs, a vast amount of information and functionalities
are exposed during network configuration, leading to potential
security risks. To ensure the overall security of the entire system,
the following measures are recommended: First, the application
development system should be controlled by the same service providers
(e.g., cloud service providers or network operators) that own the
network and computing infrastructure. Second, devices within the
cloud center should be pre-configured with security zones to isolate
traffic, preventing it from affecting other network traffic. Third,
encryption keys for each device should be centrally managed by the
cloud center. In the event of key exposure, the system should
support Over-The-Air (OTA) updates to promptly replace compromised
keys. Fourth, if a security breach occurs within the centralized
management system, exposing encryption keys, the entire system should
undergo a reset to perform a security initialization. This process
will generate and distribute new encryption keys to ensure the
continued protection of sensitive data.
Introducing an A2A overlay on top of I2ICF adds further security-
sensitive surfaces that need to be addressed. Each agent MUST have a
verifiable identity and a signed Agent Card whose contents (e.g.,
advertised ICFs, supported intents, authorization scopes) are
authenticated by the Cyber Security System. A2A messages between
agents MUST be mutually authenticated, integrity-protected, and
confidentiality-protected, and SHOULD carry replay protection
An, et al. Expires 12 December 2026 [Page 15]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
suitable for vehicular environments. Agents SHOULD operate under a
least-privilege capability model: an SDV Agent cannot reconfigure RSU
or MNO ICFs unless explicitly authorized, and a compromised agent's
credentials MUST be revocable through the same OTA mechanism used for
cryptographic key rotation. Finally, because A2A may carry LLM-
generated or LLM-influenced content, deployments SHOULD apply input
validation, prompt-injection mitigation, and human-in-the-loop
oversight for safety-critical decisions, consistent with the agentic-
AI principles discussed in
[I-D.jadoon-nmrg-agentic-ai-autonomous-networks] and
[I-D.hong-nmrg-agenticai-ps].
5. A2A Use Cases for SDV-Centric C-ITS Integration
In emerging SDV ecosystems, seamless coordination among vehicle
agents, C-ITS infrastructure agents, and MNO agents becomes essential
for achieving real-time awareness and adaptive network optimization.
The _A2A_ communication paradigm enables direct interaction among
these heterogeneous entities without relying solely on centralized
control mechanisms. For instance, SDV agents can dynamically
negotiate data offloading, perform network slicing, or compute
resource scheduling with MNO agents in response to vehicular mobility
and network conditions, while roadside infrastructure agents exchange
situational context such as congestion level, edge compute
availability, or safety alerts with SDV agents to support cooperative
perception and hazard prediction. These A2A interactions facilitate
distributed decision-making across application and network layers,
forming the basis for intelligent coordination and resilient service
continuity in connected mobility.
When integrated with the proposed I2ICF framework, such A2A-based
orchestration allows SDVs, RSUs, and MNO backends to jointly manage
ICFs, thereby ensuring low-latency, secure, and reliable service
delivery across multi-domain C-ITS environments. This approach
follows recognized architectures and standards used in C-ITS and V2X
systems, including frameworks for security management and network
data analytics. Leveraging these industry standards, A2A
coordination can extend beyond individual domains to enable intent-
driven, cross-layer management of communication, computation, and
data analytics among SDV, C-ITS, and MNO ecosystems.
The following use cases illustrate concrete A2A interaction patterns
on top of the I2ICF framework. They are intentionally aligned with
the agentic-AI direction discussed in the IRTF NMRG at IETF 124 and
IETF 125, and with the broader industry A2A reference patterns (e.g.,
Agent Cards, task lifecycles, and secure peer-to-peer messaging) so
that C-ITS deployments can interoperate with general-purpose AI agent
ecosystems.
An, et al. Expires 12 December 2026 [Page 16]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
* Capability Advertisement and Discovery (I2, I4, I5, I7): C-ITS
Infra Agent, MNO Agent, RSU Agents, and SDV Agents publish Agent
Cards describing the ICFs they host (e.g., perception offload,
message aggregation, slice selection, OTA key rotation). Center
Cloud agents index these cards via I2/I3 and use them to plan ICF
placement. Discovery is intent-driven: an SDV Agent requesting "low-
latency cooperative perception within 100 ms" is matched with nearby
RSU/MNO agents whose Agent Cards advertise compatible ICFs.
* Cooperative Perception via SDV-to-SDV and SDV-to-RSU A2A (I8, I10):
SDV agents directly negotiate sensor data exchange, fusion
responsibility, and confidence reporting with neighboring SDV agents
(I10) and RSU agents (I8). Heavy fusion ICFs can be delegated to the
RSU Agent when the SDV is compute-constrained, while the SDV Agent
retains decision authority. This pattern mirrors the agent-
interconnection and multi-level inference approach discussed in
[I-D.chuyi-nmrg-agentic-network-inference].
* Intent-Based Slice and Edge Negotiation with MNO (I4, I6): An SDV
Agent or a VRU Agent expresses a high-level intent (e.g., "platooning
session, 50 vehicles, end-to-end latency budget 20 ms, reliability
99.999 percent") to the MNO Agent via A2A. The MNO Agent translates
the intent into slice configuration and edge ICF placement,
consistent with the agentic network optimization patterns described
in [I-D.bernardos-nmrg-agentic-network-optimization].
* Cross-Domain Safety Coordination (I3, I6, I9): When a Government
Public Center Agent detects a hazardous event, it issues an A2A task
to the MNO Agent and C-ITS Infra Agent, which fan out the task to
local RSU and SDV agents. VRU agents in the affected area receive
targeted alerts via I6/I9 under privacy-preserving identifiers
provided by the Cyber Security System.
* Agentic Network Digital Twin for C-ITS (I1, I2, I4): Center Cloud
agents maintain an agentic NDT of the C-ITS network and use it to
simulate ICF placement before pushing configurations to C-ITS Infra
and MNO agents. This use case aligns with the agent-driven NDT
architecture in [I-D.wmz-nmrg-agent-ndt-arch] and with the problem
statement for agentic AI in network management in
[I-D.hong-nmrg-agenticai-ps].
* Tool-Augmented Agent Operations via MCP (all interfaces): Agents
may expose their local management tools (e.g., RSU firmware update,
SDV diagnostic, slice reconfiguration) as MCP-style tools, and other
agents may invoke them under A2A authorization. The applicability of
MCP to such network management tasks is discussed in
[I-D.yang-nmrg-mcp-nm]; the I2ICF framework reuses this pattern to
keep tool invocation auditable and policy-bound.
An, et al. Expires 12 December 2026 [Page 17]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
* Autonomous Reaction and Human-in-the-Loop Oversight: Following the
agentic-AI architectural principles in
[I-D.jadoon-nmrg-agentic-ai-autonomous-networks], I2ICF agents
operate within explicit autonomy levels. Routine ICF reconfiguration
(e.g., adjusting aggregation thresholds at an RSU) runs autonomously,
while safety-critical reconfiguration (e.g., revoking a compromised
agent or resetting cryptographic material) requires escalation to a
Center Cloud agent and, where appropriate, a human operator.
6. Agent Cards for SDVs and C-ITS Entities
Following the A2A protocol model adopted by [I-D.yang-nmrg-a2a-nm],
every agent in the I2ICF framework MUST publish an Agent Card: a JSON
metadata document that describes the agent's identity, endpoint,
advertised ICF-related capabilities, skills, and authentication
requirements. Agent Cards are the basis for capability discovery and
intent matching across I1 to I10. Agent Cards are signed and
attested by the Cyber Security System and SHOULD be discoverable by
peer agents either via a well-known URI on the hosting entity or via
a Center Cloud registry.
The following non-normative examples illustrate Agent Cards for
representative C-ITS entities. The "capabilities" field lists ICF
classes exposed by the agent, and "skills" enumerate concrete actions
invocable through A2A messages.
An, et al. Expires 12 December 2026 [Page 18]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
{
"name": "RSUAgent-01",
"description": "Agent for a roadside unit that exposes
perception offload and message aggregation ICFs.",
"url": "https://rsu-01.cits.example.net/a2a/tasks",
"capabilities": ["PerceptionOffload", "MessageAggregation",
"V2X-Relay"],
"skills": [
{
"id": "offload_perception",
"name": "Cooperative perception offload",
"description": "Run sensor fusion on behalf of an SDV
within RSU coverage.",
"inputModes": ["application/json", "text/structured"],
"outputModes": ["application/json", "text/status"]
},
{
"id": "aggregate_cam",
"name": "CAM/BSM aggregation",
"description": "Aggregate and forward V2X awareness
messages to the C-ITS Infra.",
"inputModes": ["application/json"],
"outputModes": ["text/status"]
}
]
}
Figure 2: Example Agent Card: RSU Agent
An, et al. Expires 12 December 2026 [Page 19]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
{
"name": "SDVAgent-VIN-XYZ",
"description": "In-vehicle agent representing an SDV in the
A2A overlay for cooperative driving.",
"url": "https://sdv-xyz.veh.example.net/a2a/tasks",
"capabilities": ["CooperativePerception", "Platooning",
"Telemetry", "OTA-KeyRotation"],
"skills": [
{
"id": "request_perception",
"name": "Request cooperative perception",
"description": "Request fused object lists from nearby
RSU or SDV agents.",
"inputModes": ["application/json"],
"outputModes": ["application/json"]
},
{
"id": "join_platoon",
"name": "Join platoon",
"description": "Negotiate joining an existing platoon
session with neighboring SDV agents.",
"inputModes": ["application/json"],
"outputModes": ["text/status"]
}
]
}
Figure 3: Example Agent Card: SDV Agent
An, et al. Expires 12 December 2026 [Page 20]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
{
"name": "MNOAgent-OpA",
"description": "Operator-side agent exposing slice selection
and edge ICF placement for C-ITS clients.",
"url": "https://mno-a.example.net/a2a/tasks",
"capabilities": ["NetworkSlicing", "EdgeICFPlacement",
"QoSModulation"],
"skills": [
{
"id": "select_slice",
"name": "Slice selection",
"description": "Select or instantiate a network slice
matching the requested intent.",
"inputModes": ["application/json"],
"outputModes": ["application/json"]
},
{
"id": "place_edge_icf",
"name": "Edge ICF placement",
"description": "Place an ICF on an MEC node close to the
requesting SDV/VRU agent.",
"inputModes": ["application/json"],
"outputModes": ["text/status"]
}
]
}
Figure 4: Example Agent Card: MNO Agent
7. YANG-based Structured Data for A2A Communication in SDV and C-ITS
While the A2A protocol natively supports unstructured textual content
for inter-agent exchange, the orchestration of ICFs in C-ITS demands
clarity, unambiguous intent transmission, and machine-interpretable
data, especially when safety-critical actuation (e.g., emergency
rerouting, key revocation, slice reconfiguration) is involved.
Natural-language-only payloads carry the inherent ambiguity of human
language and can lead to inconsistent ICF configuration or large-
scale service degradation, which is unacceptable for C-ITS.
This document adopts the approach of [I-D.yang-nmrg-a2a-nm], which
uses YANG [RFC7950] as the structured data layer for A2A payloads,
with NETCONF [RFC6241] and RESTCONF [RFC8040] as candidate underlying
management protocols when an agent needs to actuate an ICF on a
programmable network device. Building on that approach, this
document defines a non-normative YANG module, "ietf-cits-icf-intent",
whose data nodes are carried inside the "data" part of A2A messages
exchanged across I1 to I10. The module provides a machine-
An, et al. Expires 12 December 2026 [Page 21]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
interpretable representation of C-ITS ICF intents and supplements the
natural-language "text" parts that the same A2A message may carry.
The intent is that an SDV, RSU, MNO, or Center agent that receives an
A2A message can validate the "data" part against this YANG module
before acting upon it, and can use existing NETCONF or RESTCONF
tooling to persist or actuate the intent on a programmable network
device.
In the C-ITS context, YANG-modeled payloads carried as the "data"
part of A2A messages are RECOMMENDED for the following content
categories:
* ICF descriptors (capability schemas of RSU/MNO/SDV ICFs), modeled
by the "icf-descriptor" container of "ietf-cits-icf-intent".
* C-ITS intent objects (e.g., platooning, cooperative perception,
hazard alert) expressed as structured intents under the "cits-intent"
container of "ietf-cits-icf-intent".
* Telemetry and incident reports between RSU/SDV agents and Center
Cloud agents, reusing the YANG model in
[I-D.ietf-nmop-network-incident-yang] where applicable.
* Cryptographic material lifecycle events (rotation, revocation)
managed by the Cyber Security System.
The high-level tree structure of the "ietf-cits-icf-intent" module,
expressed using the YANG tree diagram notation, is shown in Figure 5.
The corresponding YANG module skeleton is shown in Figure 6. Both
artifacts are non-normative and are intended as a starting point for
a companion YANG document.
An, et al. Expires 12 December 2026 [Page 22]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
module: ietf-cits-icf-intent
+--rw cits-icf-intents
+--rw intent* [intent-id]
+--rw intent-id string
+--rw type identityref
+--rw requester string
+--rw target-icf identityref
+--rw safety-class? enumeration
+--rw priority? uint8
+--rw response-deadline? yang:date-and-time
+--rw interface? enumeration
+--rw constraints
| +--rw max-latency-ms? uint32
| +--rw min-reliability? decimal64
| +--rw min-confidence? decimal64
| +--rw region-of-interest? string
| +--rw bandwidth-mbps? uint32
+--rw participants* string
+--ro status? enumeration
+--ro last-updated? yang:date-and-time
notifications:
+---n icf-intent-event
+--ro intent-id -> /cits-icf-intents/intent/intent-id
+--ro event-type enumeration
+--ro details? string
Figure 5: YANG Tree Diagram of ietf-cits-icf-intent
module ietf-cits-icf-intent {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-cits-icf-intent";
prefix "cits-icf";
import ietf-yang-types {
prefix yang;
}
organization
"IETF NMRG (Network Management Research Group)";
contact
"WG Web:
Editor: Byoungman An
Editor: Jaehoon Paul Jeong ";
description
"This YANG module defines a data model for representing
Cooperative Intelligent Transportation System (C-ITS)
An, et al. Expires 12 December 2026 [Page 23]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
In-Network Computing Function (ICF) intents that are carried
as the 'data' part of Agent-to-Agent (A2A) messages between
SDV, RSU, MNO, VRU, and Center agents of the I2ICF framework.";
revision 2026-02-05 {
description "Initial revision.";
reference "draft-an-nmrg-i2icf-cits-02";
}
/* Identities for ICF intent types and target ICF classes */
identity intent-type {
description "Base identity for C-ITS ICF intent types.";
}
identity cooperative-perception {
base intent-type;
description "Cooperative perception intent (e.g., SDV-RSU).";
}
identity platooning {
base intent-type;
description "Platooning session intent among SDVs.";
}
identity hazard-alert {
base intent-type;
description "Hazard alert dissemination intent.";
}
identity slice-request {
base intent-type;
description "Network slice/edge ICF placement intent to MNO.";
}
identity ota-key-rotation {
base intent-type;
description "OTA key rotation intent managed by the Cyber
Security System.";
}
identity icf-class {
description "Base identity for ICF capability classes.";
}
identity PerceptionOffload { base icf-class; }
identity MessageAggregation { base icf-class; }
identity NetworkSlicing { base icf-class; }
identity EdgeICFPlacement { base icf-class; }
identity OTAKeyRotation { base icf-class; }
/* Top-level data tree */
container cits-icf-intents {
An, et al. Expires 12 December 2026 [Page 24]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
description
"Collection of C-ITS ICF intents currently known to the
hosting agent.";
list intent {
key "intent-id";
description "A single C-ITS ICF intent.";
leaf intent-id {
type string;
description "Globally unique intent identifier.";
}
leaf type {
type identityref { base intent-type; }
mandatory true;
description "Intent type (e.g., cooperative-perception).";
}
leaf requester {
type string;
mandatory true;
description "Agent name of the requesting agent.";
}
leaf target-icf {
type identityref { base icf-class; }
mandatory true;
description "Targeted ICF capability class.";
}
leaf safety-class {
type enumeration {
enum QM; enum ASIL-A; enum ASIL-B;
enum ASIL-C; enum ASIL-D;
}
description "ISO 26262 ASIL classification of the intent.";
}
leaf priority {
type uint8 { range "0..7"; }
description "Relative priority (0 = lowest).";
}
leaf response-deadline {
type yang:date-and-time;
description "Latest acceptable response time.";
}
leaf interface {
type enumeration {
enum I1; enum I2; enum I3; enum I4; enum I5;
enum I6; enum I7; enum I8; enum I9; enum I10;
}
description "I2ICF interface over which the intent flows.";
}
An, et al. Expires 12 December 2026 [Page 25]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
container constraints {
description "Operational constraints attached to the intent.";
leaf max-latency-ms { type uint32; units "milliseconds"; }
leaf min-reliability { type decimal64 { fraction-digits 5; } }
leaf min-confidence { type decimal64 { fraction-digits 2; } }
leaf region-of-interest { type string; }
leaf bandwidth-mbps { type uint32; units "Mbit/s"; }
}
leaf-list participants {
type string;
description "Other agents participating in this intent.";
}
leaf status {
type enumeration {
enum requested; enum accepted; enum running;
enum completed; enum failed; enum revoked;
}
config false;
description "Lifecycle status of the intent.";
}
leaf last-updated {
type yang:date-and-time;
config false;
description "Time of the last status update.";
}
}
}
/* Event-driven A2A notification */
notification icf-intent-event {
description
"Notification emitted when an intent changes state, used by
event-driven A2A pub/sub channels (see Section
'Event-driven A2A for Safety Signalling').";
leaf intent-id {
type leafref {
path "/cits-icf:cits-icf-intents/cits-icf:intent"
+ "/cits-icf:intent-id";
}
}
leaf event-type {
type enumeration {
enum accepted; enum rejected; enum progress;
enum completed; enum failed; enum revoked;
}
}
leaf details { type string; }
An, et al. Expires 12 December 2026 [Page 26]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
}
}
Figure 6: YANG Module Skeleton: ietf-cits-icf-intent
The following non-normative example illustrates an A2A message sent
from an SDV Agent to an RSU Agent over I8 to request a cooperative
perception ICF. The "data" part carries an instance of the "ietf-
cits-icf-intent" YANG module shown above, encoded as JSON per
[RFC8040] ("application/yang-data+json"), while the "text" part
preserves a human-readable summary.
POST /a2a/tasks HTTP/1.1
Host: rsu-01.cits.example.net
Content-Type: application/json
{
"jsonrpc": "2.0",
"method": "message/send",
"params": {
"message": {
"message_id": "c1ts-7f3e-4a21-9b12-0e2d6a8c4f10",
"context_id": "intersection-42:approach-east",
"role": "ROLE_USER",
"parts": [
{
"text": "Request cooperative perception within 100 ms
for intersection-42, eastbound approach.",
"media_type": "text/plain"
},
{
"data": {
"ietf-cits-icf-intent:cits-icf-intents": {
"intent": [
{
"intent-id": "intent-9921",
"type":
"ietf-cits-icf-intent:cooperative-perception",
"requester": "SDVAgent-VIN-XYZ",
"target-icf":
"ietf-cits-icf-intent:PerceptionOffload",
"safety-class": "ASIL-B",
"priority": 6,
"response-deadline": "2026-02-10T06:00:00Z",
"interface": "I8",
"constraints": {
"max-latency-ms": 100,
"min-confidence": 0.85,
"region-of-interest":
An, et al. Expires 12 December 2026 [Page 27]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
"intersection-42:east"
},
"participants": ["RSUAgent-01"]
}
]
}
},
"media_type": "application/yang-data+json",
"metadata": {
"yang_module": "ietf-cits-icf-intent",
"revision": "2026-02-05"
}
}
]
},
"configuration": {
"accepted_output_modes": ["application/yang-data+json",
"text/status"],
"blocking": false,
"history_length": 3
},
"metadata": {
"request_type": "icf_invocation",
"priority": "high",
"response_deadline": "2026-02-10T06:00:00Z"
}
}
}
Figure 7: A2A Message Example with YANG-structured Data (I8: SDV
to RSU)
The YANG module shown above is non-normative and is expected to be
refined in a companion YANG document, reusing IETF building blocks
for incident management [I-D.ietf-nmop-network-incident-yang] and
existing C-ITS/V2X data dictionaries.
8. Operational Considerations
The introduction of an A2A overlay on top of the I2ICF framework has
several operational implications that need to be considered when
deploying the architecture in large-scale, safety-critical C-ITS
environments. This section is aligned with the operational
considerations discussed in [I-D.yang-nmrg-a2a-nm] and adapts them to
C-ITS.
An, et al. Expires 12 December 2026 [Page 28]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
8.1. Agent Skills as Expertise Expansion
General-purpose AI agents do not natively possess C-ITS domain
expertise (e.g., V2X message semantics, RSU operational procedures,
MNO slice templates). C-ITS operators SHOULD package such expertise
as Agent Skills (e.g., the "diagnose_rsu_link_loss" or
"build_platoon_session" skill) so that a generic I2ICF agent can be
specialized for a given deployment without re-training the underlying
model. Skills SHOULD be versioned and signed so that the Cyber
Security System can attest the skill set advertised in an Agent Card.
8.2. Knowledge Base as Ground Truth Data
To mitigate hallucinations of LLM-based agents, deployments SHOULD
provide a shared, machine-interpretable knowledge base covering C-ITS
topology, RSU/SDV configuration baselines, MNO slice templates,
regulatory policies, and historical incident records. Agents
retrieve from this knowledge base when reasoning over A2A tasks. The
Model Context Protocol (MCP) [I-D.yang-nmrg-mcp-nm] is a candidate
substrate for standardized knowledge-base access in I2ICF.
8.3. Event-driven A2A for Safety Signalling
The task-based A2A request/response model is sufficient for slow-loop
ICF configuration but insufficient for safety-critical C-ITS events
(e.g., emergency electronic brake, hazard detection). For such
events, agents SHOULD also support an event-driven publish/subscribe
pattern, where a Hazard Agent publishes to a topic on a message
broker and interested SDV, RSU, MNO, and Center agents subscribe to
receive near-real-time notifications. This pattern reuses the event-
driven A2A architecture described in [I-D.yang-nmrg-a2a-nm].
8.4. Scalability
A national-scale C-ITS deployment may include thousands of RSUs,
millions of SDVs and VRUs, and multiple cooperating MNOs. A2A
messaging volume is therefore significantly higher than static RPC-
based interfaces. Operators SHOULD:
* Adopt hierarchical/federated agent structures so that local
decisions (e.g., intersection-level cooperative perception) remain
local to RSU and SDV agents.
* Apply rate-limiting, backoff, and prioritization on A2A messages,
with the highest priority reserved for safety signalling.
* Localize Agent Card registries per region (e.g., per Region Center
or Highway Center) to avoid global discovery hotspots.
An, et al. Expires 12 December 2026 [Page 29]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
8.5. Latency and Performance Constraints
Many C-ITS use cases (cooperative perception, platooning,
intersection management) impose tight end-to-end timing budgets (tens
of milliseconds). Implementations SHOULD define performance
envelopes for:
* Maximum A2A message processing latency for each interface (I1 to
I10).
* Timeout and retry behavior, with deterministic fallback to direct
controller APIs or pre-provisioned static ICF configurations when A2A
interactions cannot meet the deadline.
* Bounded LLM inference time when an agent relies on generative
reasoning; safety-critical paths SHOULD NOT depend on unbounded LLM
inference.
8.6. Reliability and Failure Handling
A2A workflows in C-ITS may span vehicles entering and leaving
coverage, intermittent wireless links, and partial cloud failures.
Implementations SHOULD provide:
* Workflow checkpointing so that long-lived tasks (e.g., a platoon
session) can survive agent restarts.
* Idempotent retry semantics for ICF invocations.
* Transactional ICF reconfiguration with confirmed-commit-like
semantics (analogous to NETCONF confirmed-commit) when multiple
devices must be updated atomically.
* Circuit breakers and automatic escalation to a human operator when
sustained failures threaten safety.
8.7. Agent Lifecycle and Resource Management
I2ICF agents are long-running production components and require
lifecycle management: onboarding and registration through the Cyber
Security System, controlled model/skill updates (with rollback),
decommissioning, and revocation of compromised agents through the
same OTA mechanism used for cryptographic key rotation. Operators
SHOULD monitor agent resource consumption (CPU, memory, inference
workload), especially on constrained RSU and SDV platforms.
An, et al. Expires 12 December 2026 [Page 30]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
8.8. Inter-Domain Operational Challenges
C-ITS is inherently multi-domain: Government Public Center, Region/
Highway Centers, multiple MNOs, vehicle OEMs, and third-party service
providers may each operate independent agent populations. Cross-
domain A2A interactions therefore require:
* Federated trust establishment among Cyber Security Systems of
different domains.
* Interoperable Agent Card schemas and YANG models for ICF intents.
* Policy reconciliation (e.g., differing privacy regulations for VRU
data) before sharing tasks across administrative boundaries.
* Auditing and accountability records for every cross-domain A2A
invocation, retained by the receiving domain.
9. IANA Considerations
TBD.
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,
.
[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,
.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
.
[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,
.
An, et al. Expires 12 December 2026 [Page 31]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
.
10.2. Informative References
[I-D.bernardos-nmrg-agentic-network-optimization]
Bernardos, C. J., Mourad, A., and M. A. Jadoon, "Solutions
for enabling agentic sensing with network optimization",
Work in Progress, Internet-Draft, draft-bernardos-nmrg-
agentic-network-optimization-00, 2 March 2026,
.
[I-D.chuyi-nmrg-agentic-network-inference]
Guo, C., "Agentic Network Architecture and Protocol for
Supporting Agent Interconnection Communication and Multi-
level Inference", Work in Progress, Internet-Draft, draft-
chuyi-nmrg-agentic-network-inference-00, 2 March 2026,
.
[I-D.hong-nmrg-agenticai-ps]
Hong, Y., Youn, J., Wu, Q., and B. Claise, "Motivations
and Problem Statement of Agentic AI for network
management", Work in Progress, Internet-Draft, draft-hong-
nmrg-agenticai-ps-01, 1 March 2026,
.
[I-D.ietf-nmop-network-incident-yang]
Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng,
"A YANG Data Model for Network Incident Management", Work
in Progress, Internet-Draft, draft-ietf-nmop-network-
incident-yang-08, 13 February 2026,
.
[I-D.irtf-coinrg-use-cases]
Kunze, I., Wehrle, K., Trossen, D., Montpetit, M., de Foy,
X., Griffin, D., and M. Rio, "Use Cases for In-Network
Computing", Work in Progress, Internet-Draft, draft-irtf-
coinrg-use-cases-07, 4 December 2024,
.
An, et al. Expires 12 December 2026 [Page 32]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
[I-D.jadoon-nmrg-agentic-ai-autonomous-networks]
Jadoon, M. A., Robitzsch, S., and C. J. Bernardos,
"Agentic AI Architectural Principles for Autonomous
Computer Networks", Work in Progress, Internet-Draft,
draft-jadoon-nmrg-agentic-ai-autonomous-networks-00, 2
March 2026, .
[I-D.jeong-nmrg-i2icf-problem-statement]
Jeong, J. P., Shen, Y. C., Ahn, Y., Kim, Y., Duarte, E.
P., and K. Yao, "Interface to In-Network Computing
Functions (I2ICF): Problem Statement", Work in Progress,
Internet-Draft, draft-jeong-nmrg-i2icf-problem-statement-
00, 20 October 2025,
.
[I-D.rosenberg-ai-protocols]
Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
and Requirements for AI Agent Protocols", Work in
Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
5 May 2025, .
[I-D.wmz-nmrg-agent-ndt-arch]
Wu, Q., Zhou, C., Contreras, L. M., Han, S., and Y. Hong,
"Network Digital Twin and Agentic AI based Architecture
for AI driven Network Operations", Work in Progress,
Internet-Draft, draft-wmz-nmrg-agent-ndt-arch-04, 21 May
2026, .
[I-D.yang-nmrg-a2a-nm]
Lopez, D., Moreno, N. R., Tailhardat, L., Ma, Q., Wu, Q.,
YUANYUANYANG, and S. Prabhu, "Applicability of A2A to the
Network Management", Work in Progress, Internet-Draft,
draft-yang-nmrg-a2a-nm-02, 26 February 2026,
.
[I-D.yang-nmrg-mcp-nm]
YUANYUANYANG, Wu, Q., Lopez, D., Moreno, N. R., and L.
Tailhardat, "Applicability of MCP for the Network
Management", Work in Progress, Internet-Draft, draft-yang-
nmrg-mcp-nm-02, 24 February 2026,
.
An, et al. Expires 12 December 2026 [Page 33]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
[I-D.yao-tsvwg-cco-problem-statement-and-usecases]
Yao, K., Shiping, X., Li, Y., Huang, H., and D. KUTSCHER,
"Collective Communication Optimization: Problem Statement
and Use cases", Work in Progress, Internet-Draft, draft-
yao-tsvwg-cco-problem-statement-and-usecases-00, 23
October 2023, .
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-00397615, Development
of an automotive software platform for Software-Defined-Vehicle (SDV)
integrated with an AI framework required for intelligent vehicles).
This work was in part 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 and RS-2022-II221015).
Authors' Addresses
Byoungman Robert An (editor)
Intelligent Information R and D Division Mobility Platform Research Center
Global R and D Center 6th floor
#22, Daewangpangyo-ro 712beon-gil
Seongnam
Gyeonggi-Do
13488
Republic of Korea
Phone: +82 31 739 7463
Email: bman@keti.re.kr
URI: https://www.keti.re.kr/eng/main/main.php
Jaehoon Paul Jeong (editor)
Department of Computer Science & 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
An, et al. Expires 12 December 2026 [Page 34]
Internet-Draft Agentic I2ICF for SDV in C-ITS June 2026
Pusik Park
Intelligent Information R and D Division Mobility Platform Research Center
Global R and D Center 6th floor
#22, Daewangpangyo-ro 712beon-gil
Seongnam
Gyeonggi-Do
13488
Republic of Korea
Phone: +82-31-739-7507
Email: pusik.park@keti.re.kr
URI: https://www.keti.re.kr/eng/main/main.php
Soohyun Jang
Intelligent Information R and D Division Mobility Platform Research Center
Global R and D Center 6th floor
#22, Daewangpangyo-ro 712beon-gil
Seongnam
Gyeonggi-Do
13488
Republic of Korea
Phone: +82-31-739-7436
Email: shjang@keti.re.kr
URI: https://www.keti.re.kr/eng/main/main.php
An, et al. Expires 12 December 2026 [Page 35]