nmrg K. Xu Internet-Draft Tsinghua University & Zhongguancun Laboratory Intended status: Informational L. Zhu Expires: 1 December 2026 Zhongguancun Laboratory X. Gao Y. Zhang Tsinghua University 30 May 2026 Intelligent Data Plane (IDP): Framework and Protocol Considerations draft-xu-nmrg-idp-framework-00 Abstract This document describes a framework and protocol considerations for an Intelligent Data Plane (IDP). An IDP enables data-plane nodes to perform bounded, policy-constrained, and observable packet, flow, state, telemetry, or service processing based on standardized signals and locally executable decision functions. The document defines terminology, a reference architecture, signal and result models, decision function abstractions, and communication patterns for IDP systems. It focuses on the interfaces and data formats through which IDP nodes expose signals, features, and results to AI for Network Management (AI-NM) systems, and through which they receive models, policies, and configuration from control and management entities in a self-driving and self-managing network (SD/ MN) context. This document does not define a specific AI or ML algorithm, nor does it require data-plane nodes to perform model training. Instead, it focuses on the interoperable communication patterns and data representations required to integrate intelligent data-plane processing into AI-NM and self-managing network architectures. 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/. Xu, et al. Expires 1 December 2026 [Page 1] Internet-Draft idp-framework May 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 1 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relationship to Existing RFCs . . . . . . . . . . . . . . 4 1.2. AI Network Management and Self-Managing Networks Context . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 8 5. Relationship to AI Network Management and Self-Managing Networks . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. The AI-NM and SD/MN Closed Loop . . . . . . . . . . . . . 8 5.2. IDP as the Data-Plane Interface for AI Network Management . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Three IDP Interfaces in the AI-NM and SD/MN Context . . . 9 6. Reference Architecture . . . . . . . . . . . . . . . . . . . 11 7. IDP Signals, Features, and Results . . . . . . . . . . . . . 13 7.1. Signal Categories . . . . . . . . . . . . . . . . . . . . 13 7.2. Feature Representation . . . . . . . . . . . . . . . . . 13 7.3. Result Model . . . . . . . . . . . . . . . . . . . . . . 14 7.4. Signal Freshness and Confidence . . . . . . . . . . . . . 15 8. Decision Function Abstraction . . . . . . . . . . . . . . . . 15 8.1. Generalized Processing Primitives . . . . . . . . . . . . 15 8.2. Hardware Mapping Examples . . . . . . . . . . . . . . . . 16 8.3. Model Representation and Versioning . . . . . . . . . . . 16 9. IDP Communication Patterns . . . . . . . . . . . . . . . . . 17 9.1. Northbound Communication (IDP Node to AI-NM and Management Systems) . . . . . . . . . . . . . . . . . . . . . . . . 17 Xu, et al. Expires 1 December 2026 [Page 2] Internet-Draft idp-framework May 2026 9.2. East-West Communication (IDP to IDP) . . . . . . . . . . 18 9.3. Internal Communication (Forwarding Engine to Accelerator) . . . . . . . . . . . . . . . . . . . . . . 18 10. Collaborative and Escalated Processing . . . . . . . . . . . 18 10.1. Hybrid Local and Escalated Processing . . . . . . . . . 19 10.2. Collaboration with External Analytics Platforms . . . . 19 11. Data-Plane Processing Procedure . . . . . . . . . . . . . . . 20 12. State Management . . . . . . . . . . . . . . . . . . . . . . 20 13. Metadata and Protocol Mapping Considerations . . . . . . . . 21 14. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 22 14.1. Signal and Feature Requirements . . . . . . . . . . . . 22 14.2. Decision Function Requirements . . . . . . . . . . . . . 23 14.3. Communication and Collaboration Requirements . . . . . . 23 14.4. State Management Requirements . . . . . . . . . . . . . 24 14.5. Security and Privacy Requirements . . . . . . . . . . . 24 15. Manageability Considerations . . . . . . . . . . . . . . . . 25 16. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 25 17. Performance Considerations . . . . . . . . . . . . . . . . . 25 18. Security Considerations . . . . . . . . . . . . . . . . . . . 26 18.1. Signal Spoofing and Poisoning . . . . . . . . . . . . . 26 18.2. Model and Decision-Function Integrity . . . . . . . . . 26 18.3. Resource Exhaustion . . . . . . . . . . . . . . . . . . 26 18.4. Evasion and Adversarial Traffic . . . . . . . . . . . . 26 18.5. Policy Bypass . . . . . . . . . . . . . . . . . . . . . 26 18.6. Metadata Integrity . . . . . . . . . . . . . . . . . . . 27 18.7. Safe Mode . . . . . . . . . . . . . . . . . . . . . . . 27 19. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 21.1. Normative References . . . . . . . . . . . . . . . . . . 27 21.2. Informative References . . . . . . . . . . . . . . . . . 28 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction Network infrastructure is evolving from a model centered primarily on connectivity and forwarding toward a model that also includes in- network sensing, feature extraction, state maintenance, telemetry preprocessing, conditional triggering and classification, and coordination with controllers, management systems, and compute platforms. Programmable data planes, network telemetry, in-situ OAM, network service chaining, computing-aware networking, and switch-attached accelerators have enabled forwarding devices to perform increasingly sophisticated processing while packets traverse the network. Recent research systems have demonstrated multiple implementation Xu, et al. Expires 1 December 2026 [Page 3] Internet-Draft idp-framework May 2026 directions, including tree-based data-plane inference [NetBeacon], neural network traffic analysis in programmable switches [BoS], deep learning execution on match-action pipelines [Pegasus], and FPGA- enhanced programmable switches for in-network DNN inference [FENIX]. These systems demonstrate that intelligent data-plane processing is becoming technically feasible, while also revealing common issues around state management, resource limits, safety, fallback, capability exposure, metadata exchange, and operational control. 1.1. Relationship to Existing RFCs This document builds upon existing IETF and IRTF work. The relationship to relevant RFCs is summarized below. Xu, et al. Expires 1 December 2026 [Page 4] Internet-Draft idp-framework May 2026 +===========+====================+================================+ | RFC | Contribution | IDP Extension | +===========+====================+================================+ | [RFC7426] | SDN layers and | IDP defines internal data- | | | architecture | plane components for | | | terminology (data, | intelligent processing and | | | control, | their interfaces to control | | | management planes) | and management planes | +-----------+--------------------+--------------------------------+ | [RFC9232] | Network telemetry | IDP defines signal and result | | | framework with | models for telemetry | | | measurement, | preprocessing, online feature | | | export, and | extraction, and local decision | | | analysis modules | execution at the data plane | +-----------+--------------------+--------------------------------+ | [RFC9197] | In-situ OAM (IOAM) | IDP signals and results map | | | data fields for | onto IOAM, extending its | | | in-band telemetry | semantics to carry feature | | | collection | values, inference results, and | | | | confidence indicators | +-----------+--------------------+--------------------------------+ | [RFC8300] | Network Service | IDP metadata can be carried as | | | Header (NSH) for | NSH context; IDP extends NSH | | | service function | with new metadata types for | | | chaining metadata | feature and result exchange | +-----------+--------------------+--------------------------------+ | [RFC8402] | Segment Routing | IDP decision functions can be | | [RFC8986] | architecture and | triggered per-SR-hop; IDP | | | SRv6 network | processing can be encoded as | | | programming | SRv6 network program segments | +-----------+--------------------+--------------------------------+ | [RFC7011] | IPFIX protocol for | IDP results, telemetry | | | flow information | summaries, and decision traces | | | export | can be exported via IPFIX | +-----------+--------------------+--------------------------------+ | [RFC9637] | In-network | IDP provides a framework for | | | computing use | the intelligent data-plane | | | cases for the IRTF | subset of in-network computing | | | coinrg | use cases | +-----------+--------------------+--------------------------------+ Table 1 Xu, et al. Expires 1 December 2026 [Page 5] Internet-Draft idp-framework May 2026 1.2. AI Network Management and Self-Managing Networks Context The IRTF Network Management Research Group (NMRG) has identified three core research areas: Intent-Based Networking (IBN), AI for Network Management (AI-NM), and Self-Driving and Self-Managing Networks (SD/MN). This document positions the Intelligent Data Plane as a foundational enabler for both AI-NM and SD/MN: * *For AI-NM*: IDP nodes provide standardized signals, features, and telemetry that serve as inputs to AI management and analytics systems. Without a standardized interface at the data plane, AI- NM systems rely on ad-hoc data collection mechanisms that limit interoperability. * *For SD/MN*: IDP nodes provide bounded local decision execution, conditional triggering, and configurable fallback behavior that constitute the "act" and "enforce" components of the autonomous network control loop. This enables closed-loop operations at the data-plane level under management-plane policy. This document does not standardize AI-NM or SD/MN architectures themselves; it focuses on the data-plane interfaces, data formats, and communication patterns that make these architectures feasible. 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. 3. Terminology This document uses terminology from [RFC7426] for SDN architectural concepts, [RFC9232] for network telemetry concepts, and [RFC9637] for in-network computing use cases. It also uses the following terms. *Intelligent Data Plane (IDP):* A data plane that supports bounded, policy-constrained, and observable processing of packets, flows, states, telemetry, or service-related signals in order to assist forwarding, classification, monitoring, mitigation, steering, or coordination. *IDP Node:* A forwarding node that implements IDP capabilities. Examples include programmable switches, FPGA-enhanced switches, SmartNIC-based forwarding nodes, switch-attached accelerators, and other data-plane devices. Xu, et al. Expires 1 December 2026 [Page 6] Internet-Draft idp-framework May 2026 *IDP Domain:* An administrative domain in which IDP capabilities, policies, metadata, and decision behavior are configured, authorized, and managed under a common trust and policy model. *IDP Signal:* An input used by an IDP decision function or processing function. Signals can include packet header fields, metadata, flow statistics, queue state, link state, buffer state, telemetry, service state, compute state, model confidence, or operator-provided policy parameters. *Feature:* A derived value extracted from one or more IDP signals for use by a decision function, for export to a management or analytics system, or for collaborative processing between IDP nodes. *Decision Function:* A bounded function executed by an IDP node or an attached processing module that maps signals and policy to an output result. A decision function can use rules, thresholds, lookup tables, model inference, or hybrid methods. *Result:* The output of a decision function, which may include a classification label, anomaly indication, confidence value, action hint, telemetry summary, or decision trace identifier. *Online Sensing:* The ability of an IDP node to acquire and identify packet, flow, queue, buffer, link, event, or resource information while traffic is being forwarded. *Safe Mode:* A fallback operating mode in which an IDP node continues basic forwarding or a configured conservative action when an intelligent processing function, model, signal source, metadata channel, accelerator, or external system is unavailable or untrusted. *Decision Trace:* An observable record that describes the inputs, policy, decision function identifier, model version, confidence value, output result, and selected action associated with a decision, subject to security and privacy policy. 4. Scope 4.1. In Scope This document covers: * terminology for IDP systems in the context of AI-NM and SD/MN; * a reference architecture for IDP nodes and their interfaces to AI- NM and management systems; Xu, et al. Expires 1 December 2026 [Page 7] Internet-Draft idp-framework May 2026 * signal and result models, including feature representation and confidence encoding; * decision function abstractions that generalize across hardware platforms; * communication patterns for northbound, east-west, and internal IDP interactions; * requirements for IDP signaling, data representation, and protocol mappings. 4.2. Out of Scope This document does not: * define a specific AI, ML, neural network, decision tree, or inference algorithm; * require a forwarding node to train models; * define a new packet header, TLV, YANG model, or IANA registry; * require inspection or decryption of encrypted payloads; * define implementation details for ASICs, NPUs, FPGAs, P4, eBPF, SmartNICs, or vendor SDKs; * define AI-NM or SD/MN system architectures. 5. Relationship to AI Network Management and Self-Managing Networks This section describes how the Intelligent Data Plane framework relates to AI for Network Management (AI-NM) and self-managing networks (SD/MN), as defined by the IRTF NMRG. 5.1. The AI-NM and SD/MN Closed Loop An AI-enabled self-managing network operates as a closed control loop: 1. *Observe:* Collect telemetry, signals, and state from the network. 2. *Analyze:* Apply AI or ML models to detect patterns, anomalies, or optimization opportunities. 3. *Decide:* Determine the appropriate action or policy adjustment. Xu, et al. Expires 1 December 2026 [Page 8] Internet-Draft idp-framework May 2026 4. *Act:* Execute the decision through network configuration or data-plane control. IDP contributes to the *Observe* and *Act* phases by providing standardized interfaces at the data plane. 5.2. IDP as the Data-Plane Interface for AI Network Management In the Observe phase, an AI-NM system requires data from the network. Current deployments rely on device-specific telemetry, ad-hoc log collection, or external probe systems. IDP defines a standardized approach: * *Online Sensing:* IDP nodes acquire packet, flow, queue, and device-state signals during forwarding. * *Feature Extraction:* IDP nodes derive structured features from raw signals, producing data that AI models can consume directly. * *Result Export:* IDP nodes export inference results, telemetry summaries, and decision traces to AI-NM analyzers. In the Act phase, an SD/MN system requires the ability to enforce decisions at the data plane: * *Conditional Triggering:* IDP nodes execute local actions when configured conditions are met. * *Local Decision Functions:* IDP nodes perform bounded inference under management-plane policy. * *Safe Fallback:* IDP nodes revert to basic forwarding when intelligent functions are unavailable. 5.3. Three IDP Interfaces in the AI-NM and SD/MN Context Xu, et al. Expires 1 December 2026 [Page 9] Internet-Draft idp-framework May 2026 +-----------------------------------------------+ | AI-NM / Analytics / Management System | | - model training and lifecycle | | - policy generation and validation | | - anomaly correlation and visualization | +---------------------+-------------------------+ | +----------------+----------------+ | | (1) Northbound (1) Northbound Signals, Features, Models, Policies, Config Results, Decision Traces Capability Discovery | | v v +-----------------------------------------------+ | IDP Node | | - online sensing / feature extraction | | - decision function execution | | - state maintenance / conditional triggering | | - result output / action enforcement | +---------------------+-------------------------+ | +----------------+----------------+ | | (2) East-West (3) Internal State Sharing, Feature Transfer, Task Handoff, Accelerator Coor- Metadata Exchange dination Figure 1: IDP Interfaces in the AI-NM and SD/MN Context Three interface categories are identified: 1. *Northbound Interface (IDP with AI-NM and Management Systems):* Used for exporting signals, features, and results upward, and for receiving models, policies, and configuration downward. 2. *East-West Interface (IDP to IDP):* Used for sharing state, handing off tasks, and exchanging metadata between peer IDP nodes within the same IDP domain. 3. *Internal Interface (Forwarding Engine to Accelerator):* Used for feature vector transfer, model parameter loading, and resource coordination between the primary forwarding pipeline and an attached accelerator. Xu, et al. Expires 1 December 2026 [Page 10] Internet-Draft idp-framework May 2026 6. Reference Architecture The logical architecture of an IDP system is shown below. Xu, et al. Expires 1 December 2026 [Page 11] Internet-Draft idp-framework May 2026 +-----------------------------------------------+ | AI-NM / Management / Orchestration System | | - model lifecycle, policy, configuration | | - capability discovery, analytics, control | +----------------------+------------------------+ | northbound interface (signals, models, policy, results) | +-----------------------------------------------------------------+ | IDP Node | | | | +---------------------+ +--------------------------------+ | | | Control Component | | Management / OAM Component | | | | - policy loading | | - configuration, logs, alarms | | | | - model lifecycle | | - resource monitoring | | | | - capability model | | - diagnostics and fallback | | | +---------+-----------+ +---------------+----------------+ | | | | | | | control/state sync | telemetry/OAM | | v v | | +------------------------------------------------------------+ | | | Data-Plane Processing Component | | | | - parsing and matching | | | | - online sensing / feature extraction | | | | - state maintenance | | | | - decision function execution (Partition-Map-SumReduce) | | | | - conditional triggering / result output | | | +---------------------+--------------------------------------+ | | | | | | internal interface | | v | | +------------------------------------------------------------+ | | | Optional Accelerator / Co-Processor Component | | | | - model inference (DNN, ensemble, full-precision) | | | | - feature vector processing / escalated analysis | | | +------------------------------------------------------------+ | +-----------------------------------------------------------------+ east-west interface (state sharing, task handoff, metadata) +---------------------+ +---------------------+ | IDP Node | <-------------------> | IDP Node | +---------------------+ +---------------------+ Figure 2: IDP Reference Architecture Xu, et al. Expires 1 December 2026 [Page 12] Internet-Draft idp-framework May 2026 The architecture is logical. An implementation can combine components or distribute them across hardware and software elements. For example, a switch-only implementation can execute all decision functions in a match-action pipeline. A hybrid implementation can perform feature extraction in a switch ASIC and model inference in an attached FPGA or other accelerator. 7. IDP Signals, Features, and Results This section describes the data model for IDP signals, features, and results. These are the data units exchanged across the northbound, east-west, and internal interfaces defined in Section 5. 7.1. Signal Categories IDP signals can include: * *Packet signals:* header fields, packet length, labels, tunnel identifiers, ingress port, egress port, timestamp, metadata, or classification labels. * *Flow signals:* packet count, byte count, inter-packet delay, flow duration, windowed counters, flowlet information, or flow state. * *Queue and buffer signals:* queue depth, drop counters, ECN marks, buffer occupancy, scheduling state, or congestion indication. * *Link and path signals:* link utilization, delay, loss, failure indication, path identifier, or path quality. * *Device signals:* CPU, memory, table occupancy, accelerator load, chip resource pressure, temperature, or error counters. * *Service and compute signals:* service instance health, compute load, accelerator availability, job state, or service capacity. * *Model and decision signals:* model identifier, model version, confidence value, ambiguity indication, escalation state, or result age. 7.2. Feature Representation A feature is a derived value computed from one or more signals for use by a decision function or for export. An IDP feature representation SHOULD include: * *Feature identifier:* a unique identifier within the scope of the applicable IDP policy. Xu, et al. Expires 1 December 2026 [Page 13] Internet-Draft idp-framework May 2026 * *Feature type:* indicating the data type (e.g., uint8, uint32, float16, boolean, enumerated, counter, rate). * *Feature value:* the extracted value, encoded according to the feature type. * *Optional metadata:* feature name, derivation description, extraction timestamp, freshness interval. Feature extraction MUST NOT require decryption of encrypted payloads. Feature types SHOULD support the range and precision required by the configured decision function while respecting the resource limits of the IDP node. 7.3. Result Model An IDP result is the output of a decision function. A result SHOULD include: * *Result identifier:* a unique identifier within the scope of the applicable policy. * *Decision function identifier:* identifies the function that produced the result. * *Model version:* if the decision function uses a versioned model. * *Outcome:* classification label, anomaly indication, or action hint. * *Confidence value:* an optional indicator of result reliability, expressed as a value in a defined range (e.g., 0-100). * *Timestamp or age:* indicates when the result was produced. * *Decision trace identifier:* optional reference to a detailed decision trace. * *Scope:* indicates the packet, flow, session, or other entity to which the result applies. A result used for forwarding or filtering MUST be interpreted under the applicable IDP policy. Results SHOULD be treated as hints unless policy explicitly defines them as authoritative. Xu, et al. Expires 1 December 2026 [Page 14] Internet-Draft idp-framework May 2026 7.4. Signal Freshness and Confidence An IDP signal can become stale. A signal used for IDP processing SHOULD have an associated freshness rule, such as a timestamp, sequence number, age, timeout, or validity interval. An IDP node MUST NOT use a stale signal for a decision that affects forwarding, filtering, or service steering unless local policy explicitly permits such use. An IDP signal MAY have an associated confidence value or quality indicator. Confidence can be derived from measurement accuracy, sampling rate, model confidence, signal source trust, or freshness. If confidence is used to influence traffic treatment, the IDP node SHOULD expose the confidence semantics to the AI-NM or management system. 8. Decision Function Abstraction An IDP decision function maps signals and policy to an output result. This section describes a generalized abstraction for IDP decision functions, derived from published research systems but applicable across heterogeneous data-plane hardware. 8.1. Generalized Processing Primitives The processing performed by an IDP decision function can be modeled as a composition of three primitive operations: *Partition:* Divides the input space (signals, features, state) into manageable segments. Partitioning can be based on flow keys, time windows, packet classes, or policy-specified criteria. The result is a set of independent processing contexts that can be assigned to available compute resources. *Map:* Applies a processing function to each segment independently. The mapping function can use rules, thresholds, model inference, or other methods (e.g., lookup tables, match-action entries, comparisons against learned values). *SumReduce:* Aggregates results from multiple mapping operations into a consolidated output. Aggregation can include voting, averaging, confidence-weighted fusion, max-pooling, or policy-specified combination rules. This Partition-Map-SumReduce model is hardware-agnostic. The same logical decision function can be realized on different hardware platforms through different mappings of the three primitives. Xu, et al. Expires 1 December 2026 [Page 15] Internet-Draft idp-framework May 2026 8.2. Hardware Mapping Examples +============+================+==============+======================+ | Hardware | Partition | Map | SumReduce | | Platform | | | | +============+================+==============+======================+ | P4/Tofino | Pipeline | Match-action | Cross-stage register | | | stage | tables; | aggregation; | | | allocation; | register | control-plane | | | flow hashing | operations | readout | +------------+----------------+--------------+----------------------+ | FPGA | Parallel | Custom logic | BRAM/URAM | | (Xilinx | pipeline | blocks; DSP | accumulation trees | | ZU19EG) | partitions | slices | | +------------+----------------+--------------+----------------------+ | SmartNIC/ | ARM core or | ML inference | Shared memory or | | DPU | HW thread | via ONNX | inter-core | | (NVIDIA | assignment | Runtime | communication | | BlueField) | | | | +------------+----------------+--------------+----------------------+ | eBPF/XDP | CPU core | BPF map | BPF map value | | | affinity; | lookups; | aggregation | | | flow hashing | helper | | | | | functions | | +------------+----------------+--------------+----------------------+ | NPU | Hardware | Micro-engine | Distributed memory | | (Broadcom | thread | instructions | aggregation | | NetGNT) | scheduling | | | +------------+----------------+--------------+----------------------+ Table 2 The table above is illustrative. Specific product capabilities vary by generation and vendor. 8.3. Model Representation and Versioning An IDP node that supports model-based decision functions MUST provide a way to identify the active model, its version, its resource requirements, and its allowed output actions. A model identifier SHOULD include: * *Model name or identifier:* unique within the IDP domain. * *Version number:* monotonically increasing or semantically versioned. Xu, et al. Expires 1 December 2026 [Page 16] Internet-Draft idp-framework May 2026 * *Model type:* decision tree, random forest, neural network (MLP, RNN, CNN), support vector machine, or other type. * *Primitive mapping:* how the model maps onto Partition, Map, and SumReduce primitives on the target hardware. * *Input specification:* the expected feature vector format, size, and data types. * *Output specification:* the result format, action space, and confidence semantics. * *Resource profile:* estimated table entries, memory, processing stages, and latency impact. A decision function SHOULD be bounded in execution time, memory use, and data-plane side effects. 9. IDP Communication Patterns This section describes the communication patterns across the three interface categories defined in Section 5. 9.1. Northbound Communication (IDP Node to AI-NM and Management Systems) Northbound communication includes the following patterns: *Capability Advertisement (IDP to AI-NM):* An IDP node exposes its capabilities to the AI-NM or management system, including supported parsing, feature extraction types, state scopes and limits, decision function types, action types, result output methods, model versioning support, resource limits, and fallback modes. *Policy and Model Distribution (AI-NM to IDP):* The AI-NM or management system installs or updates IDP policies, decision function parameters, models, thresholds, and action maps on the IDP node. The IDP node SHOULD validate resource requirements before activation and MUST reject a task that cannot be safely installed. *Signal and Result Export (IDP to AI-NM):* The IDP node exports features, inference results, telemetry summaries, event reports, and decision traces to the AI-NM or analytics system. Export SHOULD be configurable by policy and MAY be filtered, sampled, or aggregated to respect bandwidth and resource limits. Xu, et al. Expires 1 December 2026 [Page 17] Internet-Draft idp-framework May 2026 *Fallback and Lifecycle Control (AI-NM to IDP):* The AI-NM or management system can disable specific IDP functions, enter safe mode, trigger model rollback, or initiate diagnostics. The IDP node MUST report fallback events and state changes to the management system. 9.2. East-West Communication (IDP to IDP) East-west communication includes the following patterns: *State Sharing:* An IDP node MAY share flow state, model context, or decision context with a peer IDP node to support flow affinity, state consistency, or multi-hop processing. *Task Handoff:* When a flow moves from one IDP node to another (e.g., due to routing changes or mobility), the first node MAY transfer relevant state, feature context, or partial results to the next node. *Metadata Exchange:* IDP nodes MAY exchange result metadata, confidence values, or telemetry summaries for collaborative processing or multi-node aggregation. East-west metadata MUST be scoped to an authorized IDP domain. A node that does not understand the metadata MUST have well-defined behavior, such as ignoring, forwarding unchanged, stripping, or dropping according to the protocol mapping. 9.3. Internal Communication (Forwarding Engine to Accelerator) When an IDP node includes an optional accelerator or co-processor: *Feature Vector Transfer:* The forwarding engine transfers extracted feature vectors to the accelerator for model inference or escalated analysis. The transfer MUST define format, size, rate limits, and timeout behavior. *Result Return:* The accelerator returns inference results, confidence values, or classification labels to the forwarding engine for action execution. The return path MUST define timeout, failure, and fallback behavior. *Resource Coordination:* The forwarding engine and accelerator coordinate on resource allocation, load balancing, and model loading. The IDP node MUST define behavior for accelerator overload, timeout, failure, restart, version mismatch, and result loss. 10. Collaborative and Escalated Processing Xu, et al. Expires 1 December 2026 [Page 18] Internet-Draft idp-framework May 2026 10.1. Hybrid Local and Escalated Processing Some IDP systems perform most processing locally and escalate a subset of traffic to an attached accelerator or external analysis module. Escalation can be triggered by: * low confidence in the local decision function result; * ambiguous results near a classification boundary; * resource shortage (e.g., state exhaustion, table overflow); * policy-specified traffic classes requiring full-precision analysis; * model update or version mismatch. An IDP node that supports escalation MUST provide: * an escalation policy specifying triggers and targets; * a maximum escalation rate or budget; * backpressure or rate limiting for escalated traffic; * timeout behavior for escalation responses; * result correlation with the original flow or packet context; * fallback behavior when escalation is unavailable; * counters for escalated packets and flows. Escalation MUST NOT cause unbounded delay or resource exhaustion for unrelated traffic. 10.2. Collaboration with External Analytics Platforms IDP nodes MAY collaborate with external AI-NM, telemetry, security, or analytics platforms. Such collaboration includes: * exporting feature vectors for model retraining or refinement; * exporting decision traces for audit, analysis, or explainability; * receiving updated model parameters or thresholds based on global analysis; Xu, et al. Expires 1 December 2026 [Page 19] Internet-Draft idp-framework May 2026 * participating in federated or distributed analytics workflows. All external collaboration MUST be subject to authorization, domain boundary, privacy, and policy constraints. 11. Data-Plane Processing Procedure For each eligible packet or flow, an IDP node follows a bounded procedure such as the following: 1. Identify the applicable IDP policy. 2. Validate traffic eligibility and policy scope. 3. Parse required headers and metadata. 4. Retrieve or create the required state context. 5. Extract configured features using Online Sensing and Feature Extraction. 6. Check signal freshness, confidence, and resource limits. 7. Execute the configured Decision Function using Partition-Map- SumReduce primitives. 8. Compute result, confidence, and action. 9. Apply flow affinity or state consistency rules if required. 10. Execute the authorized action. 11. Export result, telemetry, or decision trace if configured. 12. Enter fallback behavior (Safe Mode) if required state, signals, resources, accelerators, or decision functions are unavailable. The procedure above is logical. Implementations can realize it using tables, registers, counters, accelerators, software agents, or other mechanisms. 12. State Management Stateful processing is central to many IDP functions. State resources in forwarding devices are limited. An IDP node MUST provide predictable state management behavior. An IDP node SHOULD support: Xu, et al. Expires 1 December 2026 [Page 20] Internet-Draft idp-framework May 2026 * creation, update, lookup, aging, deletion, and query of state; * per-flow or per-session state where required; * state timeout and inactivity expiration; * collision detection when hash-based indexing is used; * safe eviction rules; * fallback behavior when state cannot be allocated; * counters for state allocation failures, collisions, overwrites, and evictions. If state collision or exhaustion occurs, the IDP node MUST NOT corrupt unrelated forwarding state. The node SHOULD fall back to a configured safe behavior, such as per-packet processing, default forwarding, conservative classification, or controlled escalation. 13. Metadata and Protocol Mapping Considerations This document does not define a new metadata encapsulation. Future protocol mapping documents can define how IDP signals, features, results, and metadata are carried using existing or new mechanisms. Possible mapping targets include: * *IOAM data fields or related OAM mechanisms [RFC9197]:* for in- band signal collection and feature export. * *Service function metadata such as NSH context metadata [RFC8300]:* for carrying classification results and action hints along a service path. * *Segment Routing or SRv6 policy-associated metadata [RFC8402][RFC8986]:* for per-hop IDP context and result propagation. * *IPFIX or telemetry export records [RFC7011]:* for out-of-band export of features, results, and decision traces. * *YANG-based configuration and operational state models:* for northbound capability advertisement, policy configuration, and model lifecycle management. Xu, et al. Expires 1 December 2026 [Page 21] Internet-Draft idp-framework May 2026 * *Controller-to-device programming protocols (e.g., P4Runtime, OpenConfig, NETCONF/YANG):* for model deployment and policy synchronization. A protocol mapping that claims consistency with this framework MUST define: * the metadata format and encoding; * scope and lifetime of IDP metadata; * processing behavior at capable and incapable nodes; * MTU and fragmentation considerations; * integrity and confidentiality protection; * domain boundary behavior; * privacy treatment; * IANA considerations if any; * failure and fallback behavior. 14. Requirements 14.1. Signal and Feature Requirements REQ-IDP-01: An IDP node MUST support a fallback behavior that does not depend on the availability of an intelligent decision function. REQ-IDP-02: An IDP node MUST support feature extraction based on packet headers, metadata, and flow-level state without requiring payload decryption. REQ-IDP-03: An IDP node SHOULD support queue, buffer, link, and device-state feature extraction when relevant to the configured policy. REQ-IDP-04: Feature representation SHOULD include a feature identifier, type, value, and optional freshness metadata for interoperability across IDP nodes and AI-NM systems. REQ-IDP-05: Xu, et al. Expires 1 December 2026 [Page 22] Internet-Draft idp-framework May 2026 A signal used for IDP processing SHOULD have an associated freshness rule. A stale signal MUST NOT be used for forwarding- affecting decisions unless policy explicitly permits it. 14.2. Decision Function Requirements REQ-IDP-06: A decision function MUST be identifiable by a stable identifier and version. REQ-IDP-07: A decision function SHOULD be bounded in execution time, memory use, and data-plane side effects. REQ-IDP-08: An IDP node SHOULD support result confidence when the decision function can produce confidence. The confidence semantics SHOULD be exposed to the AI-NM or management system. REQ-IDP-09: An IDP node MUST apply only actions authorized by the applicable policy. REQ-IDP-10: An IDP node SHOULD support dampening, hysteresis, or similar mechanisms when decisions can cause traffic oscillation. 14.3. Communication and Collaboration Requirements REQ-IDP-11: An IDP node MUST be able to describe its IDP capabilities to a management or AI-NM system, including supported parsing, feature types, state limits, decision function types, and resource constraints. REQ-IDP-12: An IDP node that supports collaboration with external systems MUST authenticate and authorize those systems. REQ-IDP-13: An IDP node that exports metadata to peer nodes MUST scope that metadata to an authorized IDP domain. REQ-IDP-14: An IDP node that supports escalation MUST support rate limiting or backpressure for escalated traffic. REQ-IDP-15: Xu, et al. Expires 1 December 2026 [Page 23] Internet-Draft idp-framework May 2026 An IDP node SHOULD support correlation between escalated results and the original traffic context. 14.4. State Management Requirements REQ-IDP-16: An IDP node that supports stateful processing MUST support state aging. REQ-IDP-17: An IDP node that uses hash-based state indexing MUST provide behavior for collision detection or collision mitigation. REQ-IDP-18: State exhaustion MUST NOT cause corruption of unrelated flows or forwarding behavior. REQ-IDP-19: An IDP node SHOULD provide counters for state allocation failure, state collision, state eviction, and fallback events. 14.5. Security and Privacy Requirements REQ-IDP-20: IDP control and management interfaces MUST provide authentication, authorization, and integrity protection. REQ-IDP-21: IDP metadata that can affect forwarding or filtering MUST be integrity protected within its trust domain. REQ-IDP-22: An IDP node MUST provide protection against excessive metadata export, escalation, or event generation. REQ-IDP-23: An IDP node MUST support policy controls to limit export of sensitive features, results, and decision traces. REQ-IDP-24: IDP metadata that is meaningful only inside an IDP domain MUST be removed, hidden, or protected at domain boundaries unless explicitly permitted by policy. Xu, et al. Expires 1 December 2026 [Page 24] Internet-Draft idp-framework May 2026 15. Manageability Considerations An IDP implementation SHOULD provide management functions for capability discovery, policy configuration, feature extraction configuration, state size and timeout configuration, model or decision-function lifecycle, threshold and confidence configuration, metadata export configuration, resource monitoring, logs and alarms, fallback and safe-mode control, version consistency checks, and configuration rollback. Management systems SHOULD be able to determine whether an IDP task can be installed without exceeding resource limits. An IDP node SHOULD reject or defer activation of a task that cannot be safely installed. 16. OAM Considerations IDP functions can affect forwarding, classification, steering, telemetry, and security operations. Therefore, OAM support is important. An IDP node SHOULD support OAM visibility for whether an IDP task is active, whether a packet or flow matched an IDP policy, whether a decision function was executed, whether a result was produced, whether fallback was used, whether metadata was exported, whether escalation occurred, and decision latency and resource pressure. OAM tools SHOULD avoid exposing sensitive features or results unless authorized by policy. 17. Performance Considerations IDP functions can consume table entries, memory, registers, counters, action bandwidth, accelerator bandwidth, export bandwidth, and processing stages. Implementations SHOULD provide explicit resource accounting. Operators SHOULD evaluate maximum supported throughput, additional processing latency, maximum number of concurrent flows or states, table and memory occupancy, accelerator throughput and queueing, metadata overhead, telemetry export rate, behavior under traffic bursts, and behavior under adversarial or malformed traffic. Accuracy metrics are application-specific and are not standardized by this document. Operators SHOULD evaluate accuracy, false positive rate, false negative rate, and confidence behavior for each deployment. Xu, et al. Expires 1 December 2026 [Page 25] Internet-Draft idp-framework May 2026 18. Security Considerations IDP introduces new security considerations because data-plane signals and decision results can influence forwarding, filtering, steering, telemetry, or mitigation. 18.1. Signal Spoofing and Poisoning An attacker can attempt to spoof, manipulate, or poison signals used by IDP functions. Examples include crafted traffic patterns, misleading metadata, forged service state, or manipulated telemetry. IDP nodes and controllers MUST validate the source and integrity of signals that can affect forwarding or filtering. Signals from untrusted sources SHOULD be treated as low confidence or ignored. 18.2. Model and Decision-Function Integrity If a model or decision function is installed on an IDP node, its origin and integrity MUST be verified. Implementations SHOULD support versioning, rollback, and consistency checks. Unauthorized model updates can result in traffic misclassification, policy bypass, or denial of service. 18.3. Resource Exhaustion IDP functions can be attacked by generating many flows, many state entries, excessive metadata, high escalation rates, or excessive event reports. IDP nodes MUST support resource limits and SHOULD support rate limiting, quotas, and fallback. 18.4. Evasion and Adversarial Traffic Attackers can craft traffic to evade classification, reduce confidence, escalate to slower processing paths, or exploit pre- analysis windows. Operators SHOULD use conservative actions for low- confidence results and SHOULD monitor abnormal changes in confidence, fallback, and escalation counters. 18.5. Policy Bypass Data-plane decisions MUST remain constrained by policy. An IDP node MUST NOT allow a decision function to perform an action that is not explicitly authorized. Policy consistency SHOULD be verifiable by the management system. Xu, et al. Expires 1 December 2026 [Page 26] Internet-Draft idp-framework May 2026 18.6. Metadata Integrity IDP metadata can influence downstream nodes. Metadata that affects forwarding, filtering, steering, or security actions MUST be protected against tampering within the IDP domain. 18.7. Safe Mode An IDP node MUST have a safe mode. Safe mode SHOULD preserve basic forwarding behavior or apply a configured conservative policy when signals, models, accelerators, or collaboration channels fail. 19. Privacy Considerations IDP systems can process packet metadata, flow behavior, timing patterns, application indicators, service identifiers, tenant context, or user-related traffic patterns. Such information can be sensitive even when payloads are encrypted. An IDP deployment SHOULD apply data minimization. It SHOULD export only the features and results necessary for the configured purpose. It SHOULD avoid exporting raw packet bytes unless explicitly authorized. It SHOULD limit retention of decision traces and feature records. It SHOULD remove or protect IDP metadata at administrative boundaries. If IDP results can be used to infer user behavior, application use, tenant identity, or sensitive service information, access to those results MUST be controlled. 20. IANA Considerations This document makes no request of IANA. Future documents that define IDP metadata, protocol extensions, TLVs, YANG modules, or registries MUST include their own IANA considerations. 21. References 21.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, . Xu, et al. Expires 1 December 2026 [Page 27] Internet-Draft idp-framework May 2026 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . [RFC9232] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Network Telemetry Framework", RFC 9232, DOI 10.17487/RFC9232, May 2022, . 21.2. Informative References [BoS] Yan, J., Xu, H., Liu, Z., Li, Q., Xu, K., Xu, M., and J. Wu, "Brain-on-Switch: Towards Advanced Intelligent Network Data Plane via NN-Driven Traffic Analysis at Line-Speed", Proceedings of the 21st USENIX Symposium on Networked Systems Design and Implementation , 2024. [FENIX] Gao, X., Li, T., Zhang, Y., Wang, Z., Zeng, X., Yao, S., and K. Xu, "FENIX: Enabling In-Network DNN Inference with FPGA-Enhanced Programmable Switches", Proceedings of the USENIX Symposium on Networked Systems Design and Implementation , 2026. [NetBeacon] Zhou, G., Liu, Z., Fu, C., Li, Q., and K. Xu, "An Efficient Design of Intelligent Network Data Plane", Proceedings of the 32nd USENIX Security Symposium , 2023. [Pegasus] Zhang, Y., Yao, S., Feng, Y., Chen, K., Li, T., Liu, Z., Zhao, Y., Zhang, L., Gao, X., Xiong, F., Li, Q., and K. Xu, "Pegasus: A Universal Framework for Scalable Deep Learning Inference on the Dataplane", Proceedings of ACM SIGCOMM , 2025. Xu, et al. Expires 1 December 2026 [Page 28] Internet-Draft idp-framework May 2026 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . [RFC9637] Welzl, M., Gjessing, S., Carrozzo, G., and A. Sathiaseelan, "Use Cases for In-Network Computing", RFC 9637 , 2024. Acknowledgments The authors would like to thank the IETF and IRTF community for their valuable feedback and insights during the development of this proposal. Authors' Addresses Ke Xu Tsinghua University & Zhongguancun Laboratory Beijing China Email: xuke@tsinghua.edu.cn Liang Zhu Zhongguancun Laboratory Beijing China Email: zhuliang-x@hotmail.com Xu, et al. Expires 1 December 2026 [Page 29] Internet-Draft idp-framework May 2026 Xiangyu Gao Tsinghua University Beijing China Email: gao-xy24@mails.tsinghua.edu.cn Yinchao Zhang Tsinghua University Beijing China Email: afireswallow@gmail.com Xu, et al. Expires 1 December 2026 [Page 30]